• Client API

  • Internet Explorer 9 constantly disconnects

I am testing my application with Internet Explorer 9 and I find that it constantly disconnects. Is this expected? The cycle of status updates looks like this:

CONNECTING
CONNECTED:STREAM-SENSING
CONNECTED:HTTP-STREAMING
CONNECTED:HTTP-POLLING
DISCONNECTED:WILL-RETRY
CONNECTING
CONNECTED:STREAM-SENSING
CONNECTED:HTTP-STREAMING
CONNECTED:HTTP-POLLING
DISCONNECTED:WILL-RETRY
CONNECTING
CONNECTED:STREAM-SENSING
CONNECTED:HTTP-STREAMING
CONNECTED:HTTP-POLLING
DISCONNECTED:WILL-RETRY



When I subscribe I use getItems to transform the item to include the session id. I then make use of the session passed to my sendMessage() method to retrieve the handler object and return the smartUpdate. However, since it is constantly disconnecting and reconnecting (and therefore getting a new session each time) more often than not my request/response cycle is broken.

The cycle is quite long running (500-600ms) so by the time my adapter is ready for the smartUpdate the session that originated the request has gone.

This cycle of connect/disconnect is evident with the Lightstreamer demos also.

The only thing that does not exhibit this behaviour (that I have) is the "Hello World" example. With this there is a constant process of updates going on between the server and client, and in this instance the client does not keep disconnecting.
  • Mone replied to this.
    Obviously this is not the intended behavior.

    kpturner This cycle of connect/disconnect is evident with the Lightstreamer demos also.



    Do you have the same cycle connecting to our online demos? (e.g.: http://www.lightstreamer.com/demo/ChatDemo)

    I would like to see the server log to start investigation on the issue.
      Sorry Mone - I did not mean to sound facetious.

      Yes, I see this behaviour while accessing http://www.lightstreamer.com/demo/ChatDemo
      Also when connecting to Lightstreamer running on my PC (localhost) and also when connected to Lightstreamer running on my IBMi partition.

      I have left my IE 9 session on the http://www.lightstreamer.com/demo/ChatDemo just in case it is of any use in helping diagnosis.

      On my server I keep seeing this repeated over and over again: 
      7-Dec-12 22:00:54,190|INFO |LightstreamerLogger.requests     |FOR PUMPS PARKING DESTROYER|Closed session S9d6e7904bbdfe76T0039271 with internal cause code: 38 (Interrupted)
      Can I stop my IE9 session now? Hopefully you have plenty of information in the log.
      That "Interrupted" message means that the connection was broken somehow client-side (or somewhere in the middle).

      I confirm from our logs that the connection is unexpectedly closed.

      Are you able to capture the traffic on the client machine? I would start with a fiddler log and then proceed with a network snoop if necessary.

      PS: no need to keep your IE running, sorry
      I will kick it off again with Fiddler enabled and send you what I get. It should take too long.
      I have tested it on five PCs now. Only one exhibits this problem. So, although I need to resolve it (I have disabled all the add-ons just in case), it is not quite as serious as I first thought.
      From fiddler everything looks ok, so is probably something on the client/broweser/pc

      I have uploaded a simple test on our web server, can you please try it with the problematic IE9 and tell me what you see?
      DISCLAIMER: the code is from the microsoft documentation, I have only changed the target address. Open it and click GET: http://www.lightstreamer.com/temp/ietest.html
      I clicked GET and after a longish delay I got a popup window saying "XDR ontimeout"
      I suppose that other IEs show "XDR onprogress" at least once, is that right?
      Anyway, this looks different from what you got in the library (I was expecting a "XDR onerror")

      Sorry to bother you, but before coding a work-around I want to correctly understand why IE behaves like this.

      Please do the following:
      • reload and try again the test clicking stream
      • reload and try again the test clicking poll
      With this test I can verify if the class gives the error because of the long wait or if there's something else triggering the issue.

      Another question, are you using InPrivate Browsing?
      7 days later
      No - not InPrivate browsing.

      Oddly enough, I cannot seem to repeat the problem now. The Chat demo is remaining steadily connected in HTTP Polling mode.

      With the test URL you provided, when I click "Stream" nothing seems to happen.

      When I click "Poll" nothing seemed to happen for about 20 seconds - then I get an "XDR onload" alert followed by an alert saying "Got: blah blah blah". On subsequent tests, the "XDR onload" alert comes up after two or three seconds.....it was only my first attempt that seemed to take a while.

      I have 5.1 (1622) installed now.