Subscribers don't reconnect to the subscription when there is no traffic #2599

Question

I am using StreamingPull mechanism to receive messages from the Pub/Sub.

Here is only 2 overriding for default SubscriberFactory settings:

@Bean
    public SubscriberFactory subscriberFactory(
            GcpProjectIdProvider id,
            TransportChannelProvider channelProvider,
            CredentialsProvider credentialsProvider) throws IOException {
        PubSubConfiguration config = new PubSubConfiguration();
        config.initialize(id.getProjectId());
        config.getSubscriber().setParallelPullCount(2); //overriding1
        config.getSubscriber().setMaxDurationPerAckExtension(0); //overriding2
        DefaultSubscriberFactory factory = new DefaultSubscriberFactory(id, config);
        factory.setChannelProvider(channelProvider);
        factory.setPullEndpoint(url());
        factory.setCredentialsProvider(credentialsProvider);
        return factory;
    }

The second overriding helps me to resolve this issue: My subscriber receive a message from GCP subscription with exactly 60 seconds delay sometimes

I don't have any other overriding, but when there is no trafic I get this picute of number_of_open_streaming_pull subscription metric: number_of_open_streaming_pull

I know that Pub/Sub prefers to avoid a long-running sticky connection and client library should reopens a StreamingPull connection. It works well when there is an active traffic. Any advice I can achive a stable reopens even when there is no traffic?

I found some issues about this:

• https://github.com/spring-attic/spring-cloud-gcp/issues/1005 resolved as internal pub/sub issue
• https://github.com/spring-attic/spring-cloud-gcp/issues/2552 adviced to use Synchronous Pull, but I want to go further with Asynchronous pull because for my app lower latency and higher throughput are very important.

We are using google-cloud-pubsub, spring-cloud-gcp-pubsub, proto-google-cloud-pubsub-v1 and spring-integrations client libraries to StreamingPull messages. We use gRPC protocol for this.

I expect that client library reopens connection even if there is no traffic.