Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 21
  1. #11
    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')?

  2. #12
    Administrator
    Join Date
    Feb 2012
    Location
    Milano
    Posts
    662
    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

  3. #13
    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!
    Last edited by Megabyzus; April 20th, 2022 at 11:27 AM.

  4. #14
    Administrator
    Join Date
    Feb 2012
    Location
    Milano
    Posts
    662
    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

  5. #15
    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.
    Last edited by Megabyzus; April 21st, 2022 at 07:05 PM.

  6. #16
    Administrator
    Join Date
    Feb 2012
    Location
    Milano
    Posts
    662
    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

  7. #17
    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?.

  8. #18
    Administrator
    Join Date
    Feb 2012
    Location
    Milano
    Posts
    662
    Hi Megabyzus,

    The 'CONNECTED' prefix actually guarantees that a physical connection with the server has already been established.
    Only in the 'CONNECTED: STREAM-SENSING' case, which should be a quick transient, the client library is still evaluating the most suitable transport (Websocket, HTTP-Streaming, or polling) to use for the client session depending on the network conditions of the client.
    Anyway please double check the documentation for all the casistics: https://sdk.lightstreamer.com/ls-web...onStatusChange

    Finally, please let me stress out again that for subscribe requests you should not care about the status of the LightstreamerClient.

    Regards,
    Giuseppe

  9. #19
    Thanks. I'll look into that further. I have all this working nicely and in the final optimization steps of the code. So:

    1. Given we get a subscription object via
    let subscription = new Subscription(subscriptionMode, items, fields)
    is there a way to do a reverse look up to get a subscription based on a given item? I.e.:
    let subscription = new GetSubscription(item)
    (see NOTE 1 below for my solution)
    2. Similarly, if I RE-subscribe to the same EXACT 'items' array above do I get the same subscription reference or a new one?

    The reason for this, as always, is decoupling. In this case, I've already decoupled various modules of the app to use the same Client instance (vertical decoupling) and if no CLIENT exists to create their own.
    Similarly, I'm also decoupling the UI components inside the module to not be concerned with their stream or subscription source (in this case Lightstreamer and Subscription) which is 'horizontal decoupling' within the module. The most the UI components know about is a string (we internally call a 'topic') where a separate decoupled service can construct an 'item' from that 'topic' to pass to a
    let subscription = new Subscription(subscriptionMode, createItem('topic'), fields).
    Similarly when the UI component is destroyed it will unsubscribe('topic') as its last act--it knows nothing of Clients or Subscriptions or Lightstreamer and only knows the 'topic' string. I ideally do not want to manage my own Map<topic, subscription> internally OR pass the subscription handle or any other LS artifacts to the UI components.

    NOTE 1: Given the documentation, reverse look-up can be done by the following psuedocode;
    let subscriptions = _lightstreamerClient.getSubscriptions()
    for (subscription in subscriptions) {
    let items = subscription.getItems()
    for (item in items) {
    if item.includes('topic') exit both loops with found subscription object...
    }
    }
    NOTE 2: For your reference, I'm managing that decoupled service using an NgRx state machine.

    Thanks.
    Last edited by Megabyzus; April 25th, 2022 at 04:39 PM.

  10. #20
    Administrator
    Join Date
    Feb 2012
    Location
    Milano
    Posts
    662
    Hi Megabyzus,

    Thank you for the feedback about your integration process.

    About your questions:

    1. I can confirm that the combination of getSubscriptions and then getItems, as per your pseudocode of NOTE 1, is a good solution since there is no direct method that returns the set of active subscriptions for a given list of Items.

    2. No, if you call subscribe with the same parameters (mode, items list and fields list) of a previous one the LightstreamerClient will create a brand new subscription in addition to the old one.
    Basically you will receive the same data twice.

    Regards,
    Giuseppe

 

 

Similar Threads

  1. Replies: 27
    Last Post: October 21st, 2020, 10:30 AM
  2. Replies: 6
    Last Post: July 11th, 2016, 09:27 AM
  3. Replies: 3
    Last Post: August 16th, 2011, 10:39 AM
  4. J2EE app to push message via LS w/o JMS
    By atamel in forum General
    Replies: 3
    Last Post: August 9th, 2010, 02:09 PM
  5. Replies: 1
    Last Post: November 18th, 2009, 09:44 PM

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
All times are GMT +1. The time now is 12:33 PM.