registration reply handler not working with SockJS Bridge

[actorGeek]

Folks,

Running into an issue .... I am registering a handler through a SockJS client (java) with the SockJS bridge (vertx 3.2). 

The message being sent to the bridge is:

{

  "type" : "register",

  "address" : "/Ping",

  "replyAddress" : "/Ping.54e94576-fba3-4a6d-a7a2-86fc29ca696a"

}

On the client side, I am using the standard reply handler syntax:

register ("/Ping", <some handler>, new Handler<AsyncResult<Void>() ................etc etc

But the problem the bridge never sends a reply back. The registration is actually successful ..... just no reply to the reply address.

I am printing out all bridge events ..... the register comes through .... gets registered successfully ... but bridge never acknowledges the registration with a reply.

Does the bridge support registration replies ? Any ideas what I may be doing wrong ? 

Thanks

[Paulo Lopes]

Could you provide the java client code you're using (no need for the full application, just a small example that shows the problem)? and the library + version?

[actorGeek]

Hi Paulo:

Appreciate your getting back to me. The code is complicated. I will try and extract the relevant pieces and post.

In the meantime .... just from a conceptual standpoint .....

1. Is the Bridge expected to send an ACK on incoming registration request ?

2. If the bridge client websocket connection drops (not proactive close by client) ... will the bridge automatically deregister all registrations or is this the responsibility

of the application ?

3. In a high throughput scenario, the previous messages sent over the bridge may be sitting in the readstream associated with the recipient ..... and the client was awaiting a reply .... and now the websocket connection drops .............I presume the readstream will continue to get flushed and messages delivered, but when the replys would fail. Is my understanding correct ?

Thanks

[Paulo Lopes]

On Sunday, October 23, 2016 at 8:08:42 PM UTC+2, actorGeek wrote:

Hi Paulo:

Appreciate your getting back to me. The code is complicated. I will try and extract the relevant pieces and post.

In the meantime .... just from a conceptual standpoint .....

1. Is the Bridge expected to send an ACK on incoming registration request ?

No.
 

2. If the bridge client websocket connection drops (not proactive close by client) ... will the bridge automatically deregister all registrations or is this the responsibility

of the application ?

Yes on socket closed all resources are removed from the bridge.
 

3. In a high throughput scenario, the previous messages sent over the bridge may be sitting in the readstream associated with the recipient ..... and the client was awaiting a reply .... and now the websocket connection drops .............I presume the readstream will continue to get flushed and messages delivered, but when the replys would fail. Is my understanding correct ?

Yes.
 

[actorGeek]

Thanks again Paulo. Appreciate it.

If I may bug you a bit more ....

I am trying to understand the causal relationship between a endHandler and unregister for the case of a *graceful* shutdown with no message loss ...... In a high volume messaging environment .... and assuming that there is a way to turn off *new* messages being sent to the event bus once the shutdown is started ..... should one wait for the endHandler to be called to make sure there is no more data in the stream and then call unregister ?

The sequence is that a graceful shutdown is kicked off ..... all new messages are prevented from going on the event bus .... vertx.close (with asyncresult handler) is called .... and now this starts the undeploy .....my question above is in context of best practices in implementing the stop() method of the verticle.

Thanks

[Paulo Lopes]

end handler and unregister are not linked. When a user unregisters an address the socket remains open this means that if other channels were registered they would still be able to travel back and forth to the client. the end handler is called once the socket is closed and this case there is no proper cleaning, all resouces are clean from the bridge and if there were messages still travelling around or buffered they will be permanently lost. I'd say if one needs some clean shutdown, the procedure would be first call unregister to all registered handlers and after that call close to the socket so the end handler is invoked.