Waiting for the subscriptions before sending queue data

[Lexanius]

Hi,

nice project. It is possible to wait for the subscriptions after reconnect before sending the queued data. I think it is better to implement reaction (bi direction channels). In your new implementation, it seems that resubscription and sending are at the same time. Or i dint see the point?

Lexanius

[kum-deepak]

I am not sure if I entirely understand your question.

I have certain assumptions regarding typical usage pattern:

• In real life the publish and subscribe will happen in separate queues.
• If STOMP was connected the published message will get published immediately.

So, I assumed that it will best to publish the messages as soon as possible.

It will be great if you can explain the scenario, that will allow me to carry out necessary re-modelling.

[Lexanius]

If i understand the code right: every reconnect is a new session on stomp with new SocketId or new Websocket. The point is, if the server unsubscribe a channel if the connection is lost, u must resubscribe the channel.

So if your application create a subscription on the server and it will use to answer you, if you write a specific message, the server will not answer you. The subscription is not ready before the message send. Example: Ping/Pong. I will await for a Pong from the server, if I send a Ping. There is an old message: Ping and a subscription to Pong In the current implementation, there could be the possibility that never get the pong, because the subscription is not ready. The server send it, but the client not receive it.

In the application that use the service, i can say hey: subscribe first and then send. In the reconnect it is not possible.

Maybe it is a special case, but it is possible.

[kum-deepak]

This is definitely interesting. I have following proposal:

• Already there are state indicators - an Observable that indicates when STOMP has connected (https://stomp-js.github.io/ng2-stompjs/classes/stompservice.html#connectobservable), another that emits all state changes (https://stomp-js.github.io/ng2-stompjs/classes/stompservice.html#state).
• Additionally there is a method that indicates whether currently it is connected (https://stomp-js.github.io/ng2-stompjs/classes/stompservice.html#connected).
• [TODO] A means to queue subscription will be added that does not automatically reconnect.

Using the above:

• On every connect (by subscribing to Observable https://stomp-js.github.io/ng2-stompjs/classes/stompservice.html#connectobservable), one can subscribe to the STOMP queue (or may be a different queue based on some logic). At this phase any custom destination or source name can be saved locally which may be used during send.
• Additionally before publishing a message, one would check whether STOMP is connected (using https://stomp-js.github.io/ng2-stompjs/classes/stompservice.html#connected). The destination can be fixed or picked from variables set during subscription.

What do you think?

[sjmf]

If I'm understanding this correctly, the issue lies in the fact that ng2-stompjs does not maintain any list of the currently subscribed queues. If stored, this could be used as part of the reconnection logic to subscribe again to the user-specified queues.

I guess it's as much about whether you think the library should take responsibility for that functionality, or whether it should be up to the caller to maintain this list.

@Lexanius did I understand correctly?

[Lexanius]

I think it is better to have an option that the subscribtions will done before the send. All other will be to much work^^

[kum-deepak]

Subscribing before sending may not actually solve the problem reliably. Several gaps:

• Process of subscribing is asynchronous, the function call returns even before the broker sets it up completely.
• The publish may be carried out by some other client.
• What if the message was published and STOMP disconnects before the reply was received.

I think, if reliability of messages is needed one will need to use appropriate patterns (predeclared durable queues, manual ack etc.).

This issue is not unique to this library, it is faced by any message queuing library. By very nature it is not easy to guarantee order of messages and non-duplication of messages.

In some cases, however, the user code handling of queue re-subscription may cover some specific cases. Before actual implementation, in my opinion, we should wait until there is someone who needs it. :)

[Lexanius]

I have found the solution and this make the request unnecessary. The code is ok like it is. The Problem is easy solved with server side subscription handling. This mean: if there is a subscribtion, the server send the data instead of waiting for a message.