-
April 16th, 2010, 05:28 PM
#1
Indeed, the log reports a normal long polling session.
In a normal case, this happens when the isPolling attribute of ConnectionInfo is set as true. Please check that on the source code first.
Note that, even with no proxy, it is always possible that some intermediate node (an antivirus, for instance) causes the Stream-sense mechanism to come into play.
This can be checked in the previous part of the log.
-
June 2nd, 2010, 04:42 PM
#2
another strange behavior
The same application I noticed another strange behavior and the developer claims it's not from the application code but from the Silverlight client library. Here is the logs
25-May-10 14:05:08,022 |INFO |LightstreamerLogger.requests |SERVER POOLED THREAD 2 |Serving request: /lightstreamer/create_session.txt?LS_user=LSUser&LS_adapter_set=A dapter&LS_content_length=50000000&LS_polling=true& LS_polling_millis=0&LS_idle_millis=0&LS_report_inf o=true from 10.35.185.113:52531
(No Bind session request)
25-May-10 14:05:08,070 |INFO |LightstreamerLogger.requests |SERVER POOLED THREAD 9 |Serving request: /lightstreamer/control.txt?LS_session=S737de3212f2fbeeeT0416469&L S_op=destroy from 10.35.185.113:52531
Why the library sent a DESTROY request 50ms after the create session?
Thanks
-
June 3rd, 2010, 11:02 AM
#3
The Silverlight library may issue DESTROY requests simply to ensure that a session that is no longer needed is closed as soon as possible on the Server side.
In fact, just closing the connection stream on the client side, sometimes is not enough to ensure that.
Hence, if the session mentioned in DESTROY request (i.e. S737de3212f2fbeeeT0416469) is being closed by the client together with the opening of a new session at 14:05:08,022 then the log pattern is correct.
If the session being destroyed were the same opened at 14:05:08,022 there would be something unusual happening.
A full log snippet would be needed to shed full light on the case.
-
August 11th, 2010, 08:56 PM
#4
detail log
On the client side here is the HttpWatch log;
1. <entry method="POST" URL="https://*******.com/lightstreamer/create_session.txt">
<started>00:00:09.860</started>
<startedDateTime>2010-08-11T09:10:58.756</startedDateTime>
<time>1.718</time>
<result>200</result>
<response><content>
<contentLength>149</contentLength>
<text><![CDATA[ OK SessionId:S4abfa93fa2681585T1101270 KeepaliveMillis:0 MaxBandwidth:0.0 RequestLimit:50000 ServerName:AMS3 HTTP Server PROBE LOOP ]]></text>
<mimeType>text/plain; charset=iso-8859-1</mimeType>
</content>
</response>
2. <entry method="GET" URL="https://*******.com/lightstreamer/bind_session.txt?LS_session=S4abfa93fa2681585T1101 270&LS_content_length=50000000&LS_report_i nfo=true&LS_silverlight_version=1.0">
<started>00:00:15.250</started>
<startedDateTime>2010-08-11T09:11:04.146</startedDateTime>
<time>4.238</time>
<result>200</result>
<summary>
<response><content>
<contentLength>2074</contentLength>
<text><![CDATA[ OK SessionId:S4abfa93fa2681585T1101270 KeepaliveMillis:2000 MaxBandwidth:0.0 RequestLimit:50000 Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push PROBE PROBE END ]]></text>
<mimeType>text/plain; charset=iso-8859-1</mimeType>
</content>
</response>
3. <entry method="POST" URL="https://*******.com/lightstreamer/create_session.txt">
<started>00:00:18.031</started>
<startedDateTime>2010-08-11T09:11:06.927</startedDateTime>
<time>0.529</time>
<result>200</result>
<response><content>
<contentLength>146</contentLength>
<text><![CDATA[ OK SessionId:S92957313c3dc0a6eT1108268 KeepaliveMillis:30000 MaxBandwidth:0.0 RequestLimit:50000 ServerName:AMSATBTP3 HTTP Server LOOP ]]></text>
4. <entry method="POST" URL="https://ecaalerts.fidelity.com/lightstreamer/control.txt">
<started>00:00:18.047</started>
<startedDateTime>2010-08-11T09:11:06.943</startedDateTime>
<time>1.436</time>
<result>200</result>
<summary>
5. <entry method="POST" URL="https://*****.com/lightstreamer/bind_session.txt">
<started>00:00:19.610</started>
<startedDateTime>2010-08-11T09:11:08.506</startedDateTime>
<time>31.093</time>
<result>200</result>
<summary>
<response><content>
<contentLength>119</contentLength>
<text><![CDATA[ OK SessionId:S92957313c3dc0a6eT1108268 KeepaliveMillis:30000 MaxBandwidth:0.0 RequestLimit:50000 PROBE LOOP ]]></text>
<mimeType>text/plain; charset=iso-8859-1</mimeType>
</content>
</response>
(#5 repeats until the app was closed)
Eric
-
August 11th, 2010, 09:09 PM
#5
log on server
continued from above thread
09:11:01,270 |DEBUG|Logger.METADATA |SERVER POOLED THREAD 10 |New Session S4abfa93fa2681585T1101270 for user ad04d127-55a3-454a-a628-cd00fe3408be from 10.41.220.7
09:11:01,270 |INFO |Logger.METADATA |SERVER POOLED THREAD 10 |User ad04d127-55a3-454a-a628-cd00fe3408be has 1 concurrent session(s) after this new session S4abfa93fa2681585T1101270 added.
09:11:09,195 |DEBUG|Logger.METADATA |SERVER POOLED THREAD 8 |notifySessionClose: session id is S4abfa93fa2681585T1101270
server-3.log:09:11:01,272 |INFO |LightstreamerLogger.requests |SERVER POOLED THREAD 10 |Starting new session: S4abfa93fa2681585T1101270 from 10.41.220.7:44852
server-3.log:11-Aug-10 09:11:05,188 |INFO |LightstreamerLogger.requests |SERVER POOLED THREAD 9 |Serving request: /lightstreamer/bind_session.txt?LS_session=S4abfa93fa2681585T1101 270&LS_content_length=50000000&LS_report_info=true &LS_silverlight_version=1.0 from 10.41.220.7:44852
server-3.log:11-Aug-10 09:11:05,190 |INFO |LightstreamerLogger.requests |SERVER POOLED THREAD 9 |Attaching session: S4abfa93fa2681585T1101270 from 10.41.220.7:44852
server-3.log:11-Aug-10 09:11:09,194 |INFO |LightstreamerLogger.requests |SERVER POOLED THREAD 8 |Serving request: /lightstreamer/control.txt?LS_session=S4abfa93fa2681585T1101270&L S_op=destroy from 10.41.220.7:44878
atbt-ams-server-3.log:11-Aug-10 09:11:09,194 |INFO |LightstreamerLogger.requests |SERVER POOLED THREAD 8 |Destroying session: S4abfa93fa2681585T1101270 from 10.41.220.7:44878
second session started
09:11:08,268 |DEBUG|ATBTLogger.METADATA
|SERVER POOLED THREAD 5 |New Session S92957313c3dc0a6eT1108268 for user
ad04d127-55a3-454a-a628-cd00fe3408be from 10.41.220.7
server-3.log:11-Aug-10 09:11:08,268 |INFO |LightstreamerLogger.requests
|SERVER POOLED THREAD 5 |Starting new session: S92957313c3dc0a6eT110826
8 from 10.41.220.7:44878
server-3.log:11-Aug-10 09:11:11,136 |INFO |LightstreamerLogger.requests
|SERVER POOLED THREAD 6 |Serving request: /lightstreamer/control.txt?LS
_session=S92957313c3dc0a6eT1108268&LS_op=add&LS_ta ble=1&LS_id=ADAPTER&L
S_mode=RAW&LS_schema=MESSAGEID+DATA+MESSAGE_TS&LS_ data_adapter=ADAPTER from 10.41.220.7:44889
server-3.log:11-Aug-10 09:11:11,137 |INFO |LightstreamerLogger.requests
|SERVER POOLED THREAD 6 |Controlling session: S92957313c3dc0a6eT1108268
from 10.41.220.7:44889
server-3.log:11-Aug-10 09:11:40,461 |INFO |LightstreamerLogger.requests
|SERVER POOLED THREAD 9 |Polling (2) to session: S92957313c3dc0a6eT1108
268 from 10.41.220.7:44878
-server-3.log:11-Aug-10 09:12:10,702 |INFO |LightstreamerLogger.requests
|SERVER POOLED THREAD 9 |Polling (3) to session: S92957313c3dc0a6eT1108
268 from 10.41.220.7:44878
server-3.log:11-Aug-10 09:12:40,880 |INFO |LightstreamerLogger.requests
|SERVER POOLED THREAD 9 |Polling (4) to session: S92957313c3dc0a6eT1108
268 from 10.41.220.7:44878
.....
So this is what confused me.
1. Why the client issued the second create_session even the first session was still valid on server?
2. Why the second bind_session request submittd as POST and in POLLING mode?
3. Will lightstream automatically subscriber the same items for second session or the application needs to make the call?
Thanks
Eric
-
August 12th, 2010, 09:52 AM
#6
The pattern is the typical one when the Stream-sense mechanism comes into action.
1. Even though the first session goes on well on the Server, the answer of the first bind_session, which is in streaming, doesn't reach the client, because of some intermediate node which does not support streaming.
Eventually, the client library detects that and opens a new session in smart polling.
You may notice that the client, just in case, also sends a "destroy" request related to the first session.
2. Note that, in general, all requests are in POST; only streaming requests, in Silverlight, have to be issued in GET (note that those requests don't carry user credentials).
3. About subscriptions, note that in LS Silverlight library all the connection phase is atomic and blocking. Hence, if the Stream-sense needs to perform a second connection attempt, until it has finished and openConnection has returned, you are not allowed to perform subscription requests.
Hence, the first session cannot receive subscription requests and all you requests pertain to the second one.
Nevertheless, if you, then, explicitly open a new session by invoking openConnection, the subscription requests must be reissued.
-
August 12th, 2010, 08:16 PM
#7
For #1, the client received the response based on HttpWatch "OK SessionId:S4abfa93fa2681585T1101270 KeepaliveMillis:2000 MaxBandwidth:0.0 RequestLimit:50000 Preamble: preparing push Preamble: preparing push Preamble: preparing push
.......
Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push Preamble: preparing push PROBE PROBE END" . So why the client API thought this is not streaming?
One more question, how does Lightstreamer handles the messages between POLLING requests? Will client receive them?
Thanks
Eric
Similar Threads
-
By chanro4 in forum Client SDKs
Replies: 1
Last Post: January 19th, 2011, 10:23 AM
-
By GoatHunter in forum Client SDKs
Replies: 3
Last Post: August 31st, 2009, 08:57 AM
-
By riwang in forum Client SDKs
Replies: 9
Last Post: March 31st, 2009, 01:16 PM
-
By rsouissi in forum Client SDKs
Replies: 3
Last Post: February 1st, 2008, 08:49 AM
-
By ddhanis in forum General
Replies: 1
Last Post: December 14th, 2007, 04:39 PM
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
All times are GMT +1. The time now is 03:39 AM.
Bookmarks