Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

A way to flush/deliver messages before disconnecting

See original GitHub issue

Issue Description

Hey folks,

We are currently sending some messages, and based on a flag disconnect the clients if the conversation/process is finished. If so, we call client.disconnect() on it to make sure the client no longer keeps the connection open.

However, this is causing client to disconnect even before receiving the messages. I was hoping to have a client.disconnect(flushBeforeDisconnectBoolean) or a simple method as client.flush that sends all messages by blocking the call.

Is there a way to send messages and then wait for it to be delivered before disconnecting the client ?

Issue Analytics

State:
Created 4 years ago
Comments:6 (3 by maintainers)

Top GitHub Comments

1reaction

sbordetcommented, Dec 4, 2018

@jaypatel512 this is already possible in CometD 4:

serverChannel.publish(null, data, Promise.complete((r, x) -> serverSession.disconnect()));

If you like Java’s CompletableFuture, use Promise.Completable (a subclass of Java’s CompletableFuture):

Promise.Completable<Boolean> completable = new Promise.Completable<>();
serverSession.deliver(null, "/channel", data, completable);
completable.thenAccept(b -> serverSession.disconnect());

0reactions

sbordetcommented, Dec 11, 2018

You have to clarify what you mean exactly by “disconnect”. CometD disconnect message? TCP disconnect?

The server side promise cannot wait for the browser. The server side promise is completed as soon as the TCP write succeeds (or fails). Whether the message will arrive to the client, that is unknown to the server, and the server cannot wait. It may still happen, however, that the messages and the disconnect message (from server to client) travel onto 2 different TCP connections and therefore there is no guarantee of ordering between the messages and the disconnect message.

The ack extension guarantees ordered delivery.