Client only in polling mode

[DarioCrivelli]

Ok, sorry, the first log was taken on the client machine, so no intermediate nodes could be involved.
It is still possible that the response did not reach LS library, though this is not the normal case and some additional element has to be identified.
Can you make any hypothesis on a possible cause based on your environment?

For instance, as found in this thread, if the Silverlight application code forces the use of ClientHttp in place of BrowserHttp, streaming is no longer supported by the Silverlight runtime.

Another possibility is the presence of an antivirus tightly integrated with the browser; some antiviruses may buffer the response wholly or in blocks; I don't know if https can also be handled in this way.

Your client-side sniffer might block streaming. Can you ensure that the client-side behavior with and without the sniffer are exactly the same?

Unfortunately, LS Silverlight Client library offers no log support, so we can't check and confirm in a clear way that the streaming answer is not read by the library.
Would it be feasible for you setting up a test in your application, by performing a request to LS Server?
Can you see our online Silverlight demo in https in streaming? (Use this url).

Once the library has recovered with polling, it uses smart polling, hence the client does not wait between subsequent requests: it always reissues polls immediately and it is the Server which may hold the request until events are available.
Anyway, no events are lost; events that reach the Server while the new request has not come yet are queued and may be merged, depending on the configuration.

[EWANG]

Sorry, I forgot to clarify the issue more clearly.
The issue was first reported that the user was always in polling mode. We found out it was caused by infrastructure configuration issue and was fixed. Now majority users were in streaming mode.
The same user was in streaming mode most of the time, with or without HtppWatch. But if polling happened it is alsways the same pattern, with or without HttpWatch. The pattern is like this. On client side, create_session, bind_session, 4-5 seconds later create_session, control_session (to kill the previous session), bind_session (polling). On the server side, first bind_session seems fine.

Thanks

Eric

[DarioCrivelli]

If the client can usually work in streaming, then clearly none of the suggested possible constraints applies.
I confirm that the described pattern corresponds to the Stream-sense mechanism, which opens a polling session when the first bind_session yields no answer to the application for more than 5 seconds.

Now, the most likely explaination is that there are delays either in the client machine or in the network.
In fact, the request times reported in your logs are quite separated; by the way, do you know if the server and client clocks were in sync when you took the logs?
Can you see the exact times of the single outbound and inbound packets of the requests to the Server on the client machine? They could help discriminating where the delays are produced.

[EWANG]

Is it possible to config the client wait for more than 4 seconds? Thanks

[DarioCrivelli]

I have to correct myself, as the default timeout is 5 seconds rather than 4 seconds (I have also fixed my post above).
Anyway, the StreamingTimeoutMillis property of the ConnectionInfo instance allows you to change the setting.
If you are not using the latest version of the Silverlight API, the setting may be different.