Results 1 to 3 of 3
  1. #1
    Join Date
    Oct 2009

    Exclamation Delay in notifyUser() causes erratic create_session behavior

    I am currently using TIBCO's AMS 1.3 product, which is Lightstreamer 3.5.1 rebranded. Hopefully you all can help me out with some strange client/Metadata adapter behavior I am seeing. It is difficult for me to share code, logs, etc. because they are stored on my company's intranet which is not directly accessible, but I will do my best to answer any questions.

    I have a basic Metadata adapter, which extends LiteralBasedProvider. I am using the Flex/ActionScript client to connect to the Lightstreamer server. I recently added some code to notifyUser() which retrieves and caches the user's authorization information. This process takes several seconds to complete; however, based on the documentation I have read it is OK for calls to notifyUser() to perform this type of caching for use by the later notify methods. During this delay in notifyUser(), the LS client appears to send a duplicate request to the AMS server after approximately five seconds--perhaps a timeout of some sort is being reached? The second request is identical to the first except that LS_idle_millis=30000 instead of 0. The first request will eventually return, as will the second request. Once the second request returns the client immediately calls create_session again with LS_idle_millis=0, repeating the above behavior, and creating multiple sessions in the process. To verify this problem, I removed all code from notifyUser() and added a Thread.sleep(5000) to simulate the blocking delay. Below is a pseudo log which tries to show the order of events on the LS server-

    [REQUEST 1] Serving request: .../create_session.txt?...LS_idle_millis=0
    [REQUEST 1] notifyUser()
    [REQUEST 1] Thread.sleep(5000) STARTED
    [REQUEST 2] Serving request: .../create_session.txt?...LS_idle_millis=30000
    [REQUEST 2] notifyUser()
    [REQUEST 2] Thread.sleep(5000) STARTED
    [REQUEST 1] Thread.sleep(5000) COMPLETED
    [REQUEST 1] wantsTableNotification()
    [REQUEST 1] notifyNewSession() SESSION 1 CREATED
    [REQUEST 1] Thread.sleep(5000) COMPLETED
    [REQUEST 2] wantsTableNotification()
    [REQUEST 2] notifyNewSession() SESSION 2 CREATED
    REQUEST 3 begins immediately after REQUEST 2 returns to the client.
    This is where the looping begins.
    [REQUEST 3] Serving request: .../create_session.txt?...LS_idle_millis=0
    [REQUEST 3] notifyUser()
    [REQUEST 3] Thread.sleep(5000) STARTED
    [REQUEST 4] Serving request: .../create_session.txt?...LS_idle_millis=30000
    [REQUEST 4] notifyUser()
    [REQUEST 4] Thread.sleep(5000) STARTED
    [REQUEST 3] Thread.sleep(5000) COMPLETED
    [REQUEST 3] wantsTableNotification()
    [REQUEST 3] notifyNewSession() SESSION 1 CREATED
    [REQUEST 3] Thread.sleep(5000) COMPLETED
    [REQUEST 4] wantsTableNotification()
    [REQUEST 4] notifyNewSession() SESSION 2 CREATED
    Repeat loop infinitely...
    Any assistance you can provide is much appreciated. Thanks.

  2. #2
    Join Date
    Jul 2006
    Indeed, though notifyUser cannot be disallowed to take some time to gather profile information, a block of several seconds would cause conflicts with the client mechanisms of recovery against unresponsive connections (which involves the reconnection attempts you noticed).

    Your example with fixed pauses, however, may be misleading, because we should expect that user profile data, once obtained and cached, can be retrieved instantly by subsequent calls of notifyUser.

    Hence, the connection request might fail the first few times, but eventually succeed.
    From the application point of view, this is not much different from a connection request that stays pending for long time until it gets an answer.

    One important difference is that the Stream-sense mechanism is triggered and polling requests may be mixed to streaming requests (which may involve the different parameters you noticed).
    If the first fast execution of notifyUser should correspond to a polling attempt, then a polling session might be established where a streaming session could have been possible.
    You could prevent the case by enabling the recovery of slow-starting streaming connections; see setBufferedStreamingHandled.

    Another important difference is, as you noticed, that multiple sessions are created.
    However, all those session (but for the last one) are short lived and do not yield any data.
    Unfortunately, this sort of handshaking phase consumes some resources and some log space.

    Is there any aspect of the matter that causes blocking problems in your scenario?

  3. #3
    Join Date
    Oct 2009
    Dario, thanks for the response.

    You are right that my example (with fixed pauses) does not accurately simulate the caching of the user's authorization credentials. I updated the test to better simulate this and it appears that the Lightstreamer client is able to establish its streaming connection after 4-5 connection attempts. I'll wire in the real authorization code and ensure that subsequent calls to notifyUser() return as quickly as possible. I will let you know if the problem persists.



Similar Threads

  1. Current delay in log file
    By faa666 in forum General
    Replies: 1
    Last Post: February 15th, 2012, 08:54 AM
  2. Unexpected Delay
    By omidqrose in forum General
    Replies: 2
    Last Post: May 23rd, 2011, 12:44 PM
  3. create_session related issue.
    By Sathyaayyanar in forum Adapter SDKs
    Replies: 5
    Last Post: August 24th, 2010, 09:32 AM


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 01:12 PM.