Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 33
  1. #11
    Senior Member
    Join Date
    Dec 2019
    Posts
    66
    Dear Dario,


    Would you please take a look on the following log records?

    I didn't receive anything as a client????

    log4j:WARN No appenders could be found for logger (io.netty.util.internal.logging.InternalLoggerFact ory).
    log4j:WARN Please initialize the log4j system properly.
    06.أبر.23 10:14:37,141|DEBUG|lightstreamer.protocol|Session Thread <1>|New protocol oid=1
    06.أبر.23 10:14:37,147|DEBUG|lightstreamer.heartbeat|Session Thread <1>|rhb max interval 0
    06.أبر.23 10:14:37,148|DEBUG|lightstreamer.heartbeat|Session Thread <1>|rhb current interval 0
    06.أبر.23 10:14:37,154|DEBUG|lightstreamer.session|Session Thread <1>|New session oid=1
    Client property changed: sessionId
    06.أبر.23 10:14:37,171|INFO |lightstreamer.actions|Session Thread <1>|Session ID value changed to null
    Client property changed: serverSocketName
    06.أبر.23 10:14:37,171|INFO |lightstreamer.actions|Session Thread <1>|Server Socket Name value changed to null
    Client property changed: clientIp
    06.أبر.23 10:14:37,171|INFO |lightstreamer.actions|Session Thread <1>|Client IP value changed to null
    Client property changed: serverInstanceAddress
    06.أبر.23 10:14:37,171|INFO |lightstreamer.actions|Session Thread <1>|Server Instance Address value changed to null
    Client property changed: realMaxBandwidth
    06.أبر.23 10:14:37,171|INFO |lightstreamer.session|Session Thread <1>|Opening new session
    06.أبر.23 10:14:37,273|INFO |lightstreamer.utils|Session Thread <1>|Setting up custom CookieHandler: java.net.CookieManager@b6ed092
    06.أبر.23 10:14:37,274|INFO |lightstreamer.utils|Session Thread <1>|Default CookieStore type: java.net.InMemoryCookieStore
    06.أبر.23 10:14:37,274|DEBUG|lightstreamer.utils|Session Thread <1>|While getting cookies for http://etrdwebs02:8282/lightstreamer...col=TLCP-2.1.0
    06.أبر.23 10:14:37,274|DEBUG|lightstreamer.utils|Session Thread <1>|Result of getting cookies for http://etrdwebs02:8282/lightstreamer...col=TLCP-2.1.0
    06.أبر.23 10:14:37,274|INFO |lightstreamer.utils|Session Thread <1>|Cookies to be inserted for http://etrdwebs02:8282/lightstreamer...ol=TLCP-2.1.0: <none>
    06.أبر.23 10:14:37,323|DEBUG|lightstreamer.stream|Session Thread <1>|HTTP transport connection establishing (oid=1): http://etrdwebs02:8282
    /lightstreamer/create_session.txt?LS_protocol=TLCP-2.1.0
    LS_polling=true&LS_cause=new.api&LS_polling_millis =0&LS_idle_millis=0&LS_cid=pcYgxptg4pkpW39AN3R4hwL ri8L7R7q&LS_adapter_set=FEEDERSERVER&LS_user=40252 9&LS_password=PT1239129115&


    06.أبر.23 10:14:37,323|DEBUG|lightstreamer.netty.pool|Sessio n Thread <1>|Creating new HTTP channel pool map
    06.أبر.23 10:14:37,746|DEBUG|lightstreamer.netty.pool|Sessio n Thread <1>|HTTP channel pool map [1] created and initialized
    06.أبر.23 10:14:37,747|DEBUG|lightstreamer.netty.pool|Sessio n Thread <1>|New HTTP channel pool created. Remote address: etrdwebs02:8282
    06.أبر.23 10:14:37,961|DEBUG|lightstreamer.session|Session Thread <1>|Session state change (1): OFF -> CREATING
    06.أبر.23 10:14:37,962|DEBUG|lightstreamer.session|Session Thread <1>|Status timeout in 4000 [currentConnectTimeout]
    Connection status changed to CONNECTING
    06.أبر.23 10:14:37,992|DEBUG|lightstreamer.netty.pool|Netty Thread 1|HTTP channel created [e4e58556]
    06.أبر.23 10:14:38,006|DEBUG|lightstreamer.netty.pool|Netty Thread 1|HTTP channel active [e4e58556]
    06.أبر.23 10:14:38,007|DEBUG|lightstreamer.stream|Netty Thread 2|HTTP transport connection established (oid=1): http://etrdwebs02:8282
    /lightstreamer/create_session.txt?LS_protocol=TLCP-2.1.0
    LS_polling=true&LS_cause=new.api&LS_polling_millis =0&LS_idle_millis=0&LS_cid=pcYgxptg4pkpW39AN3R4hwL ri8L7R7q&LS_adapter_set=FEEDERSERVER&LS_user=40252 9&LS_password=PT1239129115&


    06.أبر.23 10:14:38,009|DEBUG|lightstreamer.stream|Netty Thread 2|HTTP transport sending [e4e58556]: /lightstreamer/create_session.txt?LS_protocol=TLCP-2.1.0
    LS_polling=true&LS_cause=new.api&LS_polling_millis =0&LS_idle_millis=0&LS_cid=pcYgxptg4pkpW39AN3R4hwL ri8L7R7q&LS_adapter_set=FEEDERSERVER&LS_user=40252 9&LS_password=PT1239129115&


    06.أبر.23 10:14:39,045|DEBUG|lightstreamer.stream|Netty Thread 1|Response status: 200
    06.أبر.23 10:14:39,049|DEBUG|lightstreamer.stream|Netty Thread 1|HTTP transport receiving [e4e58556]:
    CONOK,S22dfab6342ca12c1M160T1438774,50000,0,*
    SERVNAME,Lightstreamer HTTP Server
    CLIENTIP,10.254.94.75
    LOOP,0

  2. #12
    Senior Member
    Join Date
    Dec 2019
    Posts
    66
    here's the next lines

    06.أبر.23 10:14:39,050|DEBUG|lightstreamer.protocol|Session Thread <1>|New message (1): CONOK,S22dfab6342ca12c1M160T1438774,50000,0,*
    06.أبر.23 10:14:39,051|DEBUG|lightstreamer.session|Session Thread <1>|OK event while CREATING
    06.أبر.23 10:14:39,051|INFO |lightstreamer.actions|Session Thread <1>|Session ID value changed to S22dfab6342ca12c1M160T1438774
    06.أبر.23 10:14:39,051|DEBUG|lightstreamer.netty.pool|Netty Thread 1|HTTP channel released [e4e58556]
    06.أبر.23 10:14:39,051|INFO |lightstreamer.actions|Session Thread <1>|Server Instance Address value changed to http://etrdwebs02:8282/
    06.أبر.23 10:14:39,051|DEBUG|lightstreamer.session|Session Thread <1>|Data event while CREATING
    06.أبر.23 10:14:39,051|DEBUG|lightstreamer.session|Session Thread <1>|Session state change (1): CREATING -> CREATED
    06.أبر.23 10:14:39,051|DEBUG|lightstreamer.session|Session Thread <1>|Status timeout in 2000 [executionTimeout]
    Client property changed: sessionId
    06.أبر.23 10:14:39,052|DEBUG|lightstreamer.actions|Session Thread <1>|Subscription 1 ready to be sent to server
    06.أبر.23 10:14:39,052|INFO |lightstreamer.subscribe|Session Thread <1>|Preparing subscription: 1
    Client property changed: serverInstanceAddress
    Connection status changed to CONNECTED:STREAM-SENSING
    06.أبر.23 10:14:39,052|INFO |lightstreamer.protocol|Session Thread <1>|Sending subscription request
    06.أبر.23 10:14:39,053|DEBUG|lightstreamer.protocol|Session Thread <1>|subscription parameters: LS_reqId=1&LS_op=add&LS_subId=1&LS_mode=MERGE&LS_g roup=LSTOCKS&LS_schema=key command Data&LS_data_adapter=FEEDER_ADAPTER&LS_snapshot=tr ue&LS_requested_max_frequency=1&LS_session=S22dfab 6342ca12c1M160T1438774&
    06.أبر.23 10:14:39,054|INFO |lightstreamer.subscribe|Session Thread <1>|Start message handler
    06.أبر.23 10:14:39,054|DEBUG|lightstreamer.subscribe|Session Thread <1>|Sending queued messages
    06.أبر.23 10:14:39,057|DEBUG|lightstreamer.protocol|Session Thread <1>|New message (1): SERVNAME,Lightstreamer HTTP Server
    Client property changed: serverSocketName
    06.أبر.23 10:14:39,057|INFO |lightstreamer.actions|Session Thread <1>|Server Socket Name value changed to Lightstreamer HTTP Server
    06.أبر.23 10:14:39,057|DEBUG|lightstreamer.protocol|Session Thread <1>|New message (1): CLIENTIP,10.254.94.75
    Client property changed: clientIp
    06.أبر.23 10:14:39,058|INFO |lightstreamer.actions|Session Thread <1>|Client IP value changed to 10.254.94.75
    06.أبر.23 10:14:39,058|DEBUG|lightstreamer.protocol|Session Thread <1>|New message (1): LOOP,0
    06.أبر.23 10:14:39,058|DEBUG|lightstreamer.session|Session Thread <1>|Loop event while CREATED
    06.أبر.23 10:14:39,058|DEBUG|lightstreamer.session|Session Thread <1>|Session state change (1): CREATED -> FIRST_PAUSE
    06.أبر.23 10:14:39,058|DEBUG|lightstreamer.session|Session Thread <1>|Timeout event [noPause] while FIRST_PAUSE cause=null startRecovery=false
    06.أبر.23 10:14:39,058|INFO |lightstreamer.session|Session Thread <1>|Binding session
    06.أبر.23 10:14:39,058|DEBUG|lightstreamer.session|Session Thread <1>|SessionWS state change (1) (sendBind): WS_NOT_CONNECTED -> WS_CONNECTING
    06.أبر.23 10:14:39,058|DEBUG|lightstreamer.session|Session Thread <1>|WS connection: opening
    06.أبر.23 10:14:39,060|DEBUG|lightstreamer.utils|Session Thread <1>|While getting cookies for http://etrdwebs02:8282/lightstreamer
    06.أبر.23 10:14:39,060|DEBUG|lightstreamer.utils|Session Thread <1>|Result of getting cookies for http://etrdwebs02:8282/lightstreamer
    06.أبر.23 10:14:39,060|INFO |lightstreamer.utils|Session Thread <1>|Cookies to be inserted for http://etrdwebs02:8282/lightstreamer: <none>
    06.أبر.23 10:14:39,064|DEBUG|lightstreamer.netty.pool|Sessio n Thread <1>|New WS channel pool created. Remote address: etrdwebs02:8282
    06.أبر.23 10:14:39,065|DEBUG|lightstreamer.netty.pool|Netty Thread 1|HTTP channel acquired [e4e58556]
    06.أبر.23 10:14:39,067|DEBUG|lightstreamer.netty.pool|Netty Thread 3|ChannelUpgradeFuture state change [e4e58556]: CONNECTING -> CONNECTION_OK
    06.أبر.23 10:14:39,068|DEBUG|lightstreamer.stream|Session Thread <1>|WebSocket transport: CONNECTING
    06.أبر.23 10:14:39,068|DEBUG|lightstreamer.stream|Session Thread <1>|WebSocket transport: CONNECTING
    06.أبر.23 10:14:39,069|DEBUG|lightstreamer.session|Session Thread <1>|Status timeout in 4000 [currentConnectTimeoutWS]
    06.أبر.23 10:14:39,086|DEBUG|lightstreamer.netty.pool|Netty Thread 1|WS channel handshake [e4e58556]
    06.أبر.23 10:14:39,132|DEBUG|lightstreamer.netty.pool|Netty Thread 1|ChannelUpgradeFuture state change [e4e58556]: CONNECTION_OK -> UPGRADE_OK
    06.أبر.23 10:14:39,133|DEBUG|lightstreamer.netty.pool|Netty Thread 1|WS channel created [e4e58556]
    06.أبر.23 10:14:39,136|DEBUG|lightstreamer.netty|Netty Thread 1|WebSocket handler added [e4e58556]
    06.أبر.23 10:14:39,137|DEBUG|lightstreamer.stream|Session Thread <1>|WebSocket transport: CONNECTED
    06.أبر.23 10:14:39,137|DEBUG|lightstreamer.session|Session Thread <1>|WS connection: open
    06.أبر.23 10:14:39,137|DEBUG|lightstreamer.session|Session Thread <1>|SessionWS state change (1) (ok): WS_CONNECTING -> WS_CONNECTED
    06.أبر.23 10:14:39,138|DEBUG|lightstreamer.stream|Session Thread <1>|WS transport sending [e4e58556]: bind_session
    LS_cause=loop1&LS_session=S22dfab6342ca12c1M160T14 38774&
    06.أبر.23 10:14:39,140|DEBUG|lightstreamer.session|Session Thread <1>|Session state change (1): FIRST_PAUSE -> FIRST_BINDING
    06.أبر.23 10:14:39,141|DEBUG|lightstreamer.session|Session Thread <1>|Status timeout in 4000 [bindTimeout]
    06.أبر.23 10:14:39,142|DEBUG|lightstreamer.stream|Session Thread <1>|WS transport sending [e4e58556]: control
    LS_reqId=1&LS_op=add&LS_subId=1&LS_mode=MERGE&LS_g roup=LSTOCKS&LS_schema=key command Data&LS_data_adapter=FEEDER_ADAPTER&LS_snapshot=tr ue&LS_requested_max_frequency=1&LS_session=S22dfab 6342ca12c1M160T1438774&
    06.أبر.23 10:14:39,143|DEBUG|lightstreamer.actions|Session Thread <1>|Subscription 1 sent to server
    06.أبر.23 10:14:39,143|DEBUG|lightstreamer.heartbeat|Session Thread <1>|rhb updated
    06.أبر.23 10:14:39,254|DEBUG|lightstreamer.stream|Netty Thread 1|WS transport receiving [e4e58556]:
    CONOK,S22dfab6342ca12c1M160T1438774,50000,5000,*


    06.أبر.23 10:14:39,255|DEBUG|lightstreamer.protocol|Session Thread <1>|New message (1): CONOK,S22dfab6342ca12c1M160T1438774,50000,5000,*
    06.أبر.23 10:14:39,255|DEBUG|lightstreamer.session|Session Thread <1>|OK event while FIRST_BINDING
    06.أبر.23 10:14:39,255|INFO |lightstreamer.actions|Session Thread <1>|Keepalive Interval value changed to 5000
    06.أبر.23 10:14:39,256|INFO |lightstreamer.actions|Session Thread <1>|Session ID value changed to S22dfab6342ca12c1M160T1438774
    06.أبر.23 10:14:39,256|INFO |lightstreamer.actions|Session Thread <1>|Server Instance Address value changed to http://etrdwebs02:8282/
    06.أبر.23 10:14:39,256|DEBUG|lightstreamer.session|Session Thread <1>|Data event while FIRST_BINDING
    06.أبر.23 10:14:39,256|DEBUG|lightstreamer.session|Session Thread <1>|Session state change (1): FIRST_BINDING -> RECEIVING
    06.أبر.23 10:14:39,256|DEBUG|lightstreamer.session|Session Thread <1>|Status timeout in 5000 [keepaliveInterval]
    Client property changed: keepaliveInterval
    Client property changed: sessionId
    Client property changed: serverInstanceAddress
    Connection status changed to CONNECTED:WS-STREAMING
    06.أبر.23 10:14:39,257|DEBUG|lightstreamer.mpn|Session Thread <1>|MpnManager state change (null) on 'onSessionStart': NoSessionState -> SessionOkState
    06.أبر.23 10:14:39,259|DEBUG|lightstreamer.session|Session Thread <1>|Reset currentRetryDelay: 4000
    06.أبر.23 10:14:39,259|DEBUG|lightstreamer.session|Session Thread <1>|Reset currentConnectTimeout: 4000
    06.أبر.23 10:14:39,264|DEBUG|lightstreamer.stream|Netty Thread 1|WS transport receiving [e4e58556]:
    CONS,unlimited

  3. #13
    Administrator
    Join Date
    Jul 2006
    Location
    Milan
    Posts
    1,090
    The log seems truncated before any data could be received.
    Really this is the only log collected and after 10:14:39,264 nothing else is logged?
    In this case the whole application would be frozen.

  4. #14
    Senior Member
    Join Date
    Dec 2019
    Posts
    66
    Hi giuseppe,

    Unfortunately, the accumulated delay problem back again.

    Some clients face this issue too much and they're big customers.

    the delay keep accumulated, starting from seconds up to minutes.

    In the code we:

    setRequestedMaxFrequency("unlimited");
    setRequestedSnapshot("yes");

    Could this cause that issue? this adapter works in MERGE mode.

    How can I eliminate queueing in case there's a queue of messages for that customer.

    Is there's a way to enable the pumps log on PRODUCTION for specific users ?
    Your help is appreciated..

  5. #15
    Administrator
    Join Date
    Feb 2012
    Location
    Milano
    Posts
    716
    Hi ManKeer,

    Delays can have two different origins, either on the server-side or on the client-side.

    If the origin is on the server-side, it would affect all clients indiscriminately first and should be relatively easily traceable in the server log.
    Could you please send us (support@lightstreamer.com) an excerpt from the lightstreamer.log of a server to which these clients who experienced the issue were connected?
    A portion covering approximately one hour of time should be ok.

    If the issue is on the client-side, the right way to avoid data queuing is to use the MERGE mode.
    In this way, the server does not maintain a data buffer, and for each user subscription, only the most recent image is retained.
    However, this mechanism does not exclude the possibility that the client itself, in its TCP buffer, may accumulate some data, assuming it is slow in processing and presenting this data delays can still occur in this case.
    In this scenario, it may be useful to reduce the update frequency on the client side, by replacing setRequestedMaxFrequency("unlimited"); with a lower frequency setting. For example, you can request only 1 or 2 updates per second and check if the problem is mitigated.

    setRequestedMaxFrequency(1);

    or

    setRequestedMaxFrequency(2);

    On the other hand, requesting the snapshot should not make any difference during the data streaming unless it is an extremely large amount of data that triggers a delay in the application from the beginning. However, I would tend to exclude this.

  6. #16
    Senior Member
    Join Date
    Dec 2019
    Posts
    66
    Thanks giuseppe,

    Does the queueing happen per user session on the server side?

  7. #17
    Administrator
    Join Date
    Feb 2012
    Location
    Milano
    Posts
    716
    Hi ManKeer,

    Yes, server-side queuing occurs independently for each individual subscription of each user session. But as I mentioned, for MERGE-mode subscriptions, there is no server-side queuing unless the 'unfiltered' mode is explicitly requested.

    Regards,
    Giuseppe

  8. #18
    Senior Member
    Join Date
    Dec 2019
    Posts
    66
    Hi giuseppe,

    I have sent you an email on support@lightstreamer.com

    the email contains two attachments of the server logs [I have enabled the DEBUG mode for the pump], one for an accumulated delay customer and the other for normal customer.

    I hope we can solve this issue ASAP.

    Regards

  9. #19
    Administrator
    Join Date
    Feb 2012
    Location
    Milano
    Posts
    716
    Hi ManKeer,

    Thank you for the logs.
    We have analyzed them and it appears evident that for the client experiencing delays, there are duplicate subscriptions.
    In fact, the difference in the data volume between the two scenarios can only be explained this way.
    In the case with delays, we have the same subscription repeated six times:

    Line 739: 08-Oct-23 09:43:14,553|INFO |L.requests |SERVER POOLED THREAD 69 |Serving request: control -> LS_reqId=7 &LS_op=add&LS_subId=3&LS_mode=MERGE&LS_group=tad.m arket_status tad.indices.TASI tad.list_prices&LS_schema=prices&LS_snapshot=true& LS_requested_max_frequency=unlimited&LS_session=S9 c405df8ade4eebeMa4dT4314240& on "Lightstreamer HTTP Server" from 10.244.210.1:9819
    Line 740: 08-Oct-23 09:43:14,553|INFO |L.requests |SERVER POOLED THREAD 50 |Serving request: control -> LS_reqId=8 &LS_op=add&LS_subId=5&LS_mode=MERGE&LS_group=tad.m arket_status tad.indices.TASI tad.list_prices&LS_schema=prices&LS_snapshot=true& LS_requested_max_frequency=unlimited&LS_session=S9 c405df8ade4eebeMa4dT4314240& on "Lightstreamer HTTP Server" from 10.244.210.1:9819
    Line 741: 08-Oct-23 09:43:14,553|INFO |L.requests |SERVER POOLED THREAD 35 |Serving request: control -> LS_reqId=9 &LS_op=add&LS_subId=6&LS_mode=MERGE&LS_group=tad.m arket_status tad.indices.TASI tad.list_prices&LS_schema=prices&LS_snapshot=true& LS_requested_max_frequency=unlimited&LS_session=S9 c405df8ade4eebeMa4dT4314240& on "Lightstreamer HTTP Server" from 10.244.210.1:9819
    Line 743: 08-Oct-23 09:43:14,553|INFO |L.requests |SERVER POOLED THREAD 50 |Serving request: control -> LS_reqId=12&LS_op=add&LS_subId=9&LS_mode=MERGE&LS_ group=tad.market_status tad.indices.TASI tad.list_prices&LS_schema=prices&LS_snapshot=true& LS_requested_max_frequency=unlimited&LS_session=S9 c405df8ade4eebeMa4dT4314240& on "Lightstreamer HTTP Server" from 10.244.210.1:9819
    Line 746: 08-Oct-23 09:43:14,553|INFO |L.requests |SERVER POOLED THREAD 39 |Serving request: control -> LS_reqId=10&LS_op=add&LS_subId=7&LS_mode=MERGE&LS_ group=tad.market_status tad.indices.TASI tad.list_prices&LS_schema=prices&LS_snapshot=true& LS_requested_max_frequency=unlimited&LS_session=S9 c405df8ade4eebeMa4dT4314240& on "Lightstreamer HTTP Server" from 10.244.210.1:9819
    Line 747: 08-Oct-23 09:43:14,553|INFO |L.requests |SERVER POOLED THREAD 71 |Serving request: control -> LS_reqId=11&LS_op=add&LS_subId=8&LS_mode=MERGE&LS_ group=tad.market_status tad.indices.TASI tad.list_prices&LS_schema=prices&LS_snapshot=true& LS_requested_max_frequency=unlimited&LS_session=S9 c405df8ade4eebeMa4dT4314240& on "Lightstreamer HTTP Server" from 10.244.210.1:9819

    instead the 'no delay' case only one:

    Line 227577: 08-Oct-23 09:44:54,768|INFO |L.requests |SERVER POOLED THREAD 159 |Serving request: control -> LS_reqId=3 &LS_op=add&LS_subId=2&LS_mode=MERGE&LS_group=tad.m arket_status tad.indices.TASI tad.list_prices&LS_schema=prices&LS_snapshot=true& LS_requested_max_frequency=unlimited&LS_session=S5 2e4fe9b5763e735Ma4dT4454753& on "Lightstreamer HTTP Server" from 10.244.210.1:9526

    That, for example, causes the number of snapshot images sent immediately after the subscriptions to be around 70 for the 'no delay' case compared to approximately 430.

    I cannot know whether this repetition is something normal and perhaps handled during the processing of getItems, or if it simply generates subscriptions for duplicate items. Looking at the logs, I also noticed identical updates twice.

    To address this issue, you can take action on the client side by ensuring that your application does not generate duplicate subscriptions, especially during disconnection and reconnection.
    Alternatively, you can also handle it on the adapter side by enforcing, in your metadata, the rejection of subscriptions to the same group if a user already has an active subscription for the same.

    That being said, The message frequency doesn't seem to be that high, approximately 10 updates per second, but we fear that you performed a grep for the session ID, and this way, many updates sent might have been missed. And so, we are unable to establish with certainty the data repetition rate.
    Could you provide us with a snippet, even just 10 seconds, of the complete log within the same interval as the ones you sent us, say around 08-Oct-23 10:02:00?

    Regards,
    Giuseppe

  10. #20
    Senior Member
    Join Date
    Dec 2019
    Posts
    66
    Thanks giuseppe,

    I will try to send you the log by tomorrow morning.

    Now, how can I detect if this user already subscribed in this group from adapter side?

    Regards

 

 

Similar Threads

  1. delay and strange behavior
    By ahmedsmart4tech in forum Adapter SDKs
    Replies: 7
    Last Post: August 19th, 2014, 03:11 PM
  2. Delay in retrieving data
    By New Soft in forum Client SDKs
    Replies: 3
    Last Post: July 7th, 2014, 10:57 AM
  3. Current delay in log file
    By faa666 in forum General
    Replies: 1
    Last Post: February 15th, 2012, 09:54 AM
  4. Unexpected Delay
    By omidqrose in forum General
    Replies: 2
    Last Post: May 23rd, 2011, 01:44 PM
  5. Delay in notifyUser() causes erratic create_session behavior
    By brianjohnson in forum Adapter SDKs
    Replies: 2
    Last Post: April 5th, 2010, 01:02 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 06:07 PM.