setReturnImmediately is not configurable in this version of pubsub api

[robin-anil]

setReturnImmediately(true). This causes latency issues for us. We would like to go back to the long poll. Please expose a way for that

[mziccard]

Hi @r-tock, thanks for your report. This is a duplicate of #1157.

Did you consider using MessageConsumer pullAsync(String, MessageProcessor, PullOption...)?

 String subscriptionName = "my_subscription_name";
 MessageProcessor callback = new MessageProcessor() {
   public void process(Message message) throws Exception {
     // Ack deadline is renewed until this method returns
     // Message is acked if this method returns successfully
     // Message is nacked if this method throws an exception
   }
 };
 PubSub.MessageConsumer consumer = pubsub.pullAsync(subscriptionName, callback);
 // ...
 // Stop pulling
 consumer.close();

This method implements continuous pulling and uses setReturnImmediately(false) under the hood.

We are considering exposing an option to setReturnImmediately(false) also in pullAsync(String, int). If we do that you will have to take care of handling possible timeout exceptions in your application code. Such timeout exceptions come from the fact that with setReturnImmediately(false) it's more likely that the RPC might take more than the maxTimeout() value you set in PubSubOption. Using the MessageConsumer takes care of this for you.

[robin-anil]

I tried this however I couldn't get our existing tests to work. the callback was not receiving any data and secondly having this run in a server, I have to now expose all the consumers to the shutdown handler for graceful shutdown of the server. This was a lot harder which pushed me just use the GRPC Stubs directly. Everything worked well for us by doing that.

[mziccard]

the callback was not receiving any data

This is strange. We have integration tests in place and customers using the MessageConsumer. It would be nice if you could file a proper bug report for this.

Anyway I am closing this as duplicate of #1157