#grpc

hi

regarding proxies; it appears that grpc doesn't look at the "no_proxy" environment variable (although it will look at "http_proxy")

since the default for no_proxy includes localhost; the end result is that any user with an http_proxy configured will never be able to connect to localhost

sjepsy: Please file an issue

sure, do i need an account?

nm, got it

Thank you.

hmm, on a totally unrelated note; is there a way for the server to unilaterally send a message to the client? i.e. an unrelated event which occurs on the server that must be sent to the client

a notification perhaps

You can do something like that with server-streaming/bidi-streaming.

But the client must initiate the RPC.

yes, but that's dependent on the client being connected and staying connected

If the client isn't connected, how would the server send something?

i was thinking more of a permanent 2-way link between client and server on which the server can autonomously send a message without first getting a request from the user

No, there isn't anything like that. And I'm not sure how you envision that working.

well, you'd connect with client initially at start of world, it would keep tcp connection open, and any point later, the server could send any message it wanted

the other way i can think of is making a listening server on the client end; i.e. 2 sockets

In client/server model, the client must always connect first.

i've been reading about DuplexStreaming, but as far as i can understand, the server is at the mercy of a client request coming in to respond

yes, the client connects first, but the connection is then maintained

there's a distinction between connecting first, and sending a message?; maybe my understanding isnt good on the topic; the server can only respond to a message from the client (i'm not talking about initial tcp connect, but a message instance)

Using a server-streaming RPC, the client could issue the RPC and it just sit there until the server has something to send.

my required scenario: client connects to server, server says hello. handshake done. connection is kept open. later on server gets a connection from another client and needs to tell the first client that another one has connected

but in your suggestion, the clienet can't make additional requests in the meantime?

Oh, no. The client can totally make additional requests in the mean time.

We multiplex many RPCs onto the same connection.

for example, the client might want to ask the server to get a the size of it's hdd; while the server is then calculating that (could take minutes), the client can't request anything else?

The client would be free to do other RPCs using the same connection while the server is processing.

ok, but then in the case of an event created by the server which it needs to push to all clients, how would that work?

When each client starts it issues a long-lived RPC to the server. When the server has an event, it sends it via that RPC. This is somewhat similar to long polling in HTTP, but with server (or bidi) streaming the same RPC can be used over-and-over for events.

perhaps an rpc from the client for which the server returns a stream response, but that response doesn't ever end

Right.

yes that's what you said :)

I think that means we're on the same page :)

stranger things have happened

i will try it out tomorrow

The client does need to have logic to re-create the RPC if it is cancelled/fails.

im sure i can handle that

Are your clients/servers going to be communicating directly, or through a proxy?

direct through localhost

Ah, okay.

Makes sense given the proxy issue you raised this morning :)

:)

@ejona, how bad is JDK8 CompletableFuture, and why shouldn't I use them?

You say in https://github.com/grpc/grpc-java/issues/2688 "I'm very disappointed in it and the more I talk to people the more it seems the community has decided that CompletableFuture is horrible."

rmichela_: Opinion time!

I don't have an exhaustive list nearby, but:

Can you point me to the community?

No split like SettableFuture/ListenableFuture. You must return exactly CompletableFuture.

That means that _anyone_ can complete the future.

The value returned by get() can change, via obtrude*. Because of the earlier problem, that means anyone can change the value.

It is a huge, huge, huge API. All I wanted was a single addListener method.

Umm... I'm forgetting stuff.

sounds reasonable, but their lack in the generated stubs forces Guava onto grpc-java consumers

It used to have a leak issue, where listeners wouldn't be unregistered. ListenableFuture also had the same problem, but it sounded a bit easier to get into with CompletableFuture. I sort of assume that's been solved, but I've not circled back to it.

Well, we can't support Java 8 in generated stubs either.

Err.. *require*

you can't, but if the stubs had @@protoc_insertion_point markers, the community could :)

Ah.

That's about equivalent to writing your own codegen that just uses the Grpc-generated one.

i'd rather extend the vanilla java generator than rewrite it entirely

It's the same difficuilty. You would use the MethodDescriptors generated by the standard one.

Each RPC method would be a single line, just like our current generated stubs.

sounds about right, but i can reuse some of the generated code, rather than have to re-create it

there is a lot of finesse translating protoc to java that you all have already gotten right

why duplicate the effort and the bugs?

Uhhh... then maybe I don't understand. It seems to me you have to do that in either case. Maybe I don't understand the insertion points well enough.

@@protoc_insertion_point lets me write a generator that splices into the output of your generator

rather than writing my own output files from scratch

Right. And I'm saying that if you have a snippet to insert at such a point, if you put it in its own file, it will work the same.

since i'm writing "inside your class", i can do things with my generator output I couldn't normally do with java composition

the generated API also looks consistent with stock gRPC

Yes, the last point is true; it would have to be outside of the *Grpc class. That's minor in my mind, but true.

If you were going to add special bestToString() or similar, I'd agree. But if you are changing the stub's arguments/return for the RPC methods, then it doesn't really change anything. You wouldn't need to extend the generated code; you just need the MethodDescriptors.

Anyway, I'm going offline for the day.

k

If you want, you can open an issue about supported CompletableFuture where it can be discussed. My view of the class doesn't kill the possibility of having support for it, but it does diminish the number of issues I'd actively try to solve (like the JDK 8 problem).

I'd be much more interested in having real RxJava Observables, for example. But if we got one, we could probably do the other.