Angular Frondend app with multiple 'decoupled' modules

[Megabyzus]

Excellent. Multiple subscriptions clears a lot for us. Many thanks. A few related questions:

1. In terms of performance, since there are TWO particular pages that are interested in their separate subscriptions, once a client connection is established, is it ok to keep it and merely subscribe and unsubscribe on page entry and exit when needed or should the connection be cut too?
2. In terms of performance, since there are TWO particular pages that are interested in their separate subscriptions, should we subscribe and unsubscribe on page entry and exit or can we keep the subscriptions open?
3. We are subscribing using the 'RAW" mode. However, the data comes back in a particular key 'Pd' where we extract it. Is there a more elegant way we can receive data and not rely on an esoteric key ('Pd')?

[giuseppe.corti]

Hi Megabyzus,

1. I can confirm that generally it is a good practice to keep the LightstreamerClient object connected to the server and subscribe and unsubscribe dynamically accordingly with the user navigation.
A possible scenario in which disconnecting the LightstreamerClient may make sense, is if you are aware that the client has entered a state where no communication at all is expected with the server for a long time (several minutes or more).

2. Again it depends on the application scenario, it is generally advisable to unsubscribe when you exit the page and the data is no longer displayed (otherwise you would continue to receive useless data).
But you could choose the opposite behavior if for example there are not so many real-time updates instead the initial image (the snapshot) is very large.

3. The RAW mode is quite particular and implies giving up some optimizations and features of the others.
But unfortunately I didn't understand enough about your data model, to give you any further suggestions.
Do you mean that your subscriptions have only one field called 'Pd' which contains the whole message?
Could you expand a bit more on what the messages received from the client contain?

Regards,
Giuseppe

[Megabyzus]

Thanks. Very helpful. As for:

3. The RAW mode is quite particular and implies giving up some optimizations and features of the others.
But unfortunately I didn't understand enough about your data model, to give you any further suggestions.
Do you mean that your subscriptions have only one field called 'Pd' which contains the whole message?
Could you expand a bit more on what the messages received from the client contain?

I'm not sure if this is our construct. I thought it was yours. However, it seems from your response it is ours. I'll look into it.

Other questions:

I noticed if I try to subscribe while the client is connecting the connection status message listener ceases. So:

1. Does this mean the client has ceased connecting?
2. If so, are ALL the messages that include the text 'CONNECTED:' a valid client connection or just the ones like 'WS STREAMING', ''HTTP STREAMING'? Are the 'POLLING' messages considered connected and can I subscribe or no? NOTE: I'd rather just check for a string containing 'CONNECTED' than be specific. Or is there a specific connected message I can listen for sent by the client object?

Thanks!

[giuseppe.corti]

Hi Megabyzus,

1. No, the subscribe requests should not interfere in any way with connection operations.
If a valid client session with the server is not established yet at the moment of the subscribe the requests are queued and sent to the server as soon as a good one is started.

2. No, the 'CONNECTED' prefix is no guarantee that there is an actually active session with the server, for example when status is CONNECTED:STREAM-SENSING the client session is not actually ready.
I can confirm to you that 'POLLING' is considered a well established session.
But as said in 1. you can call subscribe regardless of client status.

Regards,
Giuseppe

[Megabyzus]

Hmmm.

1. If i attempt a subscribe before a 'CONNECT: XXXX' the listener that spits out the connection status stops. I can olny make it work if indeed there is a connection.

2. I'm confused now about the CONNECTED prefix. What should I look for if at all for a guaranteed connection? I am currently unable to subscribe until there's a connection.

[giuseppe.corti]

Hi Megabyzus,

As I said before it is not the expected behavior.
It is very strange that a subscribe call causes the failure of the connection attempt.

I think you need to investigate further with the client library debug log.
To enable the logging, you should add to your code the following lines:

var log = new SimpleLoggerProvider();
log.addLoggerAppender(new ConsoleAppender("DEBUG", "*"));
LightstreamerClient.setLoggerProvider(log);

For instance, you can add them before the initial creation of the instance of LightstreamerClient.

Regards,
Giuseppe

[Megabyzus]

Thanks. And thoughts on '2'?:

2. I'm confused now about the CONNECTED prefix. What should I look for if at all for a guaranteed connection? Shouldn't I care if there's a connection anyway before doing anything else like subscribing?.