Silverlight Client Connection problem in IE

kkrisjoy

Hi,

I tried the SilverLight Client with Presto version of Lightstreamer but am stuck with a problem in IE.

The first time I open the browser, I Click on a button which opens a Silverlight window that displays the prices / values come across from the adapter and everything works fine.

When I close the Window, I issue client.closeconnection. However, when I click the button again, when the window opens it throws the error:

Listener Error ... Subscription Failed: No Session is active
Lightstreamer.Dotnet.Client.SubscrException: Connection Closed
at Lightstreamer.Dotnet.Client.LSClient.get_ConnManager()
at Lightstreamer.Dotnet.Client.LSClient.SubscribeTable(ExtendedTableInfo table, IHandyTableListener list)

The Problem only occurs in Internet Explorer (IE)

when I open the URL in other browsers (Google Chrome / Mozilla Firefox), it works fine - how many ever times you open and close the window.

Looking forward to your suggestions.

Dario Crivelli

You have to ensure that OpenConnection, SubscribeTableand CloseConnection are invoked in the correct sequence.

According to your description, it seems that IE, upon a window restart, does not invoke, towards the Silverlight runtime, the same methods as other browsers
and that some different event has to be intercepted in order to call OpenConnection.

A different possibility is that you call OpenConnectionand SubscribeTable from different threads, related with different events
and, for some reason:
- upon the first opening of the window OpenConnection gets called first,
- whereas, upon the second opening, SubscribeTable gets called first.

In any case, you should trace your calls to OpenConnection.
Unfortunately, we haven't got much expertise about how events are triggered in Silverlight.

kkrisjoy

Thanks Dario,

Will look into what you said -
also will try lightstreamer 3.6 and see if it resolves the issue
will get back to you with the results

Cheers

kishornpatil

Hey, we are having same problem intermittently. API issues unsubscription on it's own and connection gets lost. did you get any resolution?

Mone

Did you try to trace OpenConnection, SubscribeTableand CloseConnection callsas Dario suggests?

API issues unsubscription on it's own and connection gets lost.

Please can you clarify? Do you see unsubscription requests being sent to the server (can you attach a server log?) and after that the client closes the connection?

Please do not get confused by the unsubscription calls on the DataAdapter as those are not an evidence of the client sending an unsubscription request.

Mone

Hi,

I'm sorry, I forgot to mention that there is a known bug in the current library that, if the stream-sense is active (see http://lightstreamer.com/docs/client_silverlight_doc/Lightstreamer_DotNet_Client_ConnectionInfo_EnableStreamSense1.html ) can lead to refused subscriptions (this only happens if subscriptions are performed soon after the openConnection method exits due to a race condition).

We may provide you with a fixed library if you can't wait for the official release expected in Q1 2011. If that's the case please write to support@lightstreamer.com.

kishornpatil

Hi Mone,

We are attempting streaming connection with lightstreamer :
connectionInfo.Polling = false;
connectionInfo.User = Guid.NewGuid().ToString();

We dont set the stream sense defaulting it to "true"

We did more debugging and found that, We made create session request "17:37:31", made binding request "17:37:36". Server waited for 5 second and issued session close / destory. It seems for some reason the client api didnt make binding request for long 5 second resulting into session closure. This is resulting in subscription exception (SubscrException) in the application code.

We are attempting to fix this by handling this connection and attempting a reconnect? Is this right thing to do or you think this is the issue you were refereing in your previous post and getting latest version of silverlight client api will fix this?

Mone

Hi,

I suggest going on this way:

disable the stream sense and try to reproduce the issue.
(with stream sense enabled) place a sleep of a couple of seconds between the openConnection and the subscribe call and try to reproduce the issue

if none of the above reproduced the issue, then you're probably experiencing our bug, otherwise the issue should be somewhere else.

In any case, if possible, attach here the server log showing one of the sessions that had the issue.