pubsub: create experimental message dispatcher

[pongad]

EXPERIMENTAL
I pulled it into a separate class so it may coexist with the original.
We can submit this, but it needs more testing before production use.

We emphasize simplicity, not optimal performance.
Of course, performance is still important,
hence the many concurrent data structures used here.

Major differences from the original and some justifications:

• It modacks immediately after receiving messages
  to take advantage of server-side duplicate-mitigation
  feature that should soon be available.
• In the original impl, we create many dispatchers.
  They share some data structures and keep others separate.
  I find this too confusing.
  The new impl creates only one dispatcher, to be shared
  among all connections. This obviously increases contention
  but should be at least partially alleviated by some lock-free
  algorithms used here.
• It makes deadline a constant of 1 minute.
  With the dup-mitigation feature, the server might need to
  wait on the order of minutes before it could redeliver messages.
  I opine that setting the deadline to 1 minute shouldn't drastically
  worsen the redelivery latency.
  Also unlike the original, it does not periodically adjust deadline.
  I have some ideas on how this could be simply implemented;
  we can add this feature back if necessary.
• Modack time is also set to 1 minute and doesn't exponentially back
  off. Since the deadline is already 1 minute, it seems silly to
  bicker over a few extra seconds. [1]
• Modacks run on fixed schedule, giving 15 seconds padding,
  and modacks all pending messages, not just the ones about to expire.
  While clearly suboptimal, it's not very expensive since it only
  happens once every 45 seconds.

[1] This caused a bug. If the padding is set too large, we'd
schedule modacks to occur in the past, creating a modack storm.

I believe the benefits of reduced complexity outweighs the cost.
Load test shows the current implementation still has no trouble
catching up with the publisher.

[mdietz94]

It's unfortunately much more expensive server side to process messages from a different stream. We do support it so users can continue to process messages after a stream dies, but we won't be able to scale if every stream is doing this.

…

On Nov 2, 2017 9:36 PM, "Michael Darakananda" ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In google-cloud-pubsub/src/main/java/com/google/cloud/pubsub/ v1/MessageDispatcher2.java <#2572 (comment)> : > + @OverRide + public void run() { + try { + receiver.receiveMessage(item.message.getMessage(), consumer); + } catch (Exception e) { + consumer.throwException(e); + } + } + }); + } + } + + private void sendRequest(StreamingPullRequest request) { + Connection connection = null; + try { + connection = connections.take(); I thought I was being smart round-robin-ing the connections :( Could you provide some context here? The current logic seems to work fine on both desktop and loadtest. Might it not work in the future? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2572 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABvXakDzdWgDcEiKQLPS_-_XbJD2sSxNks5sym4MgaJpZM4QPKmh> .

[pongad]

superseded by #2580