Announcement

Collapse
No announcement yet.
X
  • Filter
  • Time
Clear All
new posts

    Messaging causes problem in IE 6.0.3790.3959

    Hi,
    We have included messaging support in our project. The following code has been included in .jsp file.
    Code:
     <isomorphic:loadISC  includeModules="RealtimeMessaging"   skin="SmartClient"/>
    The jsp file works fine in the Mozilla and all versions of IE except IE 6.0.3790.3959. At first, the jsp page loads without any problem. When i switch from one menu to another, i will load that jsp file again. In that case, the screen hangs saying 'Loading data' in the listgrid. And the menus are not popped up just like freezed. No component is working in that screen after that. But when i remove the messaging support (i.e. includeModules ="RealtimeMessaging"), everything works fine. This problem occurs only in
    IE version 6.0.3790.3959
    Update versions: SP2
    Copyright 1995-2004 Microsoft corp.
    not in other versions of IE including IE 6.0 previous version. The above mentioned is latest IE 6.0.
    Can you help us to solve this?

    Thanks

    #2
    What about the basics: is there a JavaScript error, if so what's in the stack trace? Is there anything in the Developer Console? What do you see in Fiddler?

    Comment


      #3
      Hi
      There is no script error and there is no exception in developer console.
      We tested with Fiddler as you said. It says the following.

      Code:
      #	Result	Protocol	Host	URL	Body	Caching	Content-Type	Process	User-defined	
      47	200	HTTP	192.168.27.225	/alarm.do?&isc_rpc=1&isc_v=6.0&isc_xhr=1&isc_tnum=4	147	no-cache  Expires: Fri, 06 Jun 2008 10:37:30 GMT	text/plain;charset=UTF-8	iexplore:5868		
      48	200	HTTP	192.168.27.225	/home.do?meshbhindex=true	442,940		text/html;charset=ISO-8859-1	iexplore:5868		
      49	200	HTTP	192.168.27.225	/isomorphic/messaging?ts=1212747699828	332,741	no-cache  Expires: Fri, 06 Jun 2008 10:37:31 GMT	text/html;charset=ISO-8859-1	iexplore:5868		
      50	404	HTTP	192.168.27.225	/isomorphic/system/modules/ISC_FileLoader.js?isc_version=5.6.js	952		text/html;charset=utf-8	iexplore:5868		
      51	200	HTTP	192.168.27.225	/isomorphic/messaging?ts=1212747703453	332,741	no-cache  Expires: Fri, 06 Jun 2008 10:37:33 GMT	text/html;charset=ISO-8859-1	iexplore:5868		
      52	200	HTTP	192.168.27.225	/provisioningUtility.do?&isc_rpc=1&isc_v=6.0&isc_xhr=1&isc_tnum=0	79	no-cache  Expires: Fri, 06 Jun 2008 10:37:38 GMT	text/plain;charset=UTF-8	iexplore:5868		
      53	200	HTTP	192.168.27.225	/isomorphic/IDACall?isc_rpc=1&isc_v=6.0&isc_xhr=1&isc_tnum=1	2,985	no-cache  Expires: Fri, 06 Jun 2008 10:37:38 GMT	text/plain;charset=UTF-8	iexplore:5868		
      54	200	HTTP	192.168.27.225	/alarm.do?&isc_rpc=1&isc_v=6.0&isc_xhr=1&isc_tnum=2	147	no-cache  Expires: Fri, 06 Jun 2008 10:37:38 GMT	text/plain;charset=UTF-8	iexplore:5868		
      55	200	HTTP	192.168.27.225	/isomorphic/messaging?ts=1212747707812	332,741	no-cache  Expires: Fri, 06 Jun 2008 10:37:38 GMT	text/html;charset=ISO-8859-1	iexplore:5868		
      56	200	HTTP	192.168.27.225	/isomorphic/IDACall?isc_rpc=1&isc_v=6.0&isc_xhr=1&isc_tnum=3	19,276	no-cache  Expires: Fri, 06 Jun 2008 10:37:39 GMT	text/plain;charset=UTF-8	iexplore:5868		
      57	200	HTTP	192.168.27.225	/isomorphic/messaging?ts=1212747711859	332,741	no-cache  Expires: Fri, 06 Jun 2008 10:37:42 GMT	text/html;charset=ISO-8859-1	iexplore:5868		
      58	200	HTTP	192.168.27.225	/isomorphic/messaging?ts=1212747715906	332,741	no-cache  Expires: Fri, 06 Jun 2008 10:37:46 GMT	text/html;charset=ISO-8859-1	iexplore:5868		
      59	200	HTTP	192.168.27.225	/alarm.do?&isc_rpc=1&isc_v=6.0&isc_xhr=1&isc_tnum=4	147	no-cache  Expires: Fri, 06 Jun 2008 10:37:48 GMT	text/plain;charset=UTF-8	iexplore:5868		
      60	200	HTTP	192.168.27.225	/isomorphic/messaging?ts=1212747719953	332,741	no-cache  Expires: Fri, 06 Jun 2008 10:37:50 GMT	text/html;charset=ISO-8859-1	iexplore:5868		
      61	200	HTTP	192.168.27.225	/isomorphic/messaging?ts=1212747724000	332,741	no-cache  Expires: Fri, 06 Jun 2008 10:37:54 GMT	text/html;charset=ISO-8859-1	iexplore:5868		
      62	200	HTTP	192.168.27.225	/isomorphic/messaging?ts=1212747728046	332,741	no-cache  Expires: Fri, 06 Jun 2008 10:37:58 GMT	text/html;charset=ISO-8859-1	iexplore:5868		
      63	200	HTTP	192.168.27.225	/isomorphic/messaging?ts=1212747732093	332,741	no-cache  Expires: Fri, 06 Jun 2008 10:38:02 GMT	text/html;charset=ISO-8859-1	iexplore:5868		
      64	200	HTTP	192.168.27.225	/alarm.do?&isc_rpc=1&isc_v=6.0&isc_xhr=1&isc_tnum=5	147	no-cache  Expires: Fri, 06 Jun 2008 10:38:03 GMT	text/plain;charset=UTF-8	iexplore:5868		
      65	200	HTTP	192.168.27.225	/isomorphic/messaging?ts=1212747736140	332,741	no-cache  Expires: Fri, 06 Jun 2008 10:38:06 GMT	text/html;charset=ISO-8859-1	iexplore:5868		
      66	200	HTTP	192.168.27.225	/isomorphic/messaging?ts=1212747740171	332,741	no-cache  Expires: Fri, 06 Jun 2008 10:38:10 GMT	text/html;charset=ISO-8859-1	iexplore:5868		
      67	200	HTTP	192.168.27.225	/isomorphic/messaging?ts=1212747744218	332,741	no-cache  Expires: Fri, 06 Jun 2008 10:38:14 GMT	text/html;charset=ISO-8859-1	iexplore:5868		
      68	200	HTTP	192.168.27.225	/alarm.do?&isc_rpc=1&isc_v=6.0&isc_xhr=1&isc_tnum=6	147	no-cache  Expires: Fri, 06 Jun 2008 10:38:18 GMT	text/plain;charset=UTF-8	iexplore:5868		
      69	200	HTTP	192.168.27.225	/isomorphic/messaging?ts=1212747748312	332,741	no-cache  Expires: Fri, 06 Jun 2008 10:38:18 GMT	text/html;charset=ISO-8859-1	iexplore:5868		
      70	200	HTTP	192.168.27.225	/isomorphic/messaging?ts=1212747752343	332,741	no-cache  Expires: Fri, 06 Jun 2008 10:38:23 GMT	text/html;charset=ISO-8859-1	iexplore:5868		
      71	200	HTTP	192.168.27.225	/isomorphic/messaging?ts=1212747756390	332,741	no-cache  Expires: Fri, 06 Jun 2008 10:38:27 GMT	text/html;charset=ISO-8859-1	iexplore:5868
      We tested that .jsp file having some alerts in between them. In that case, it worked fine without any problem. So what we found is, the reason could be mismatch between the speed of browser and server sending the messages. The server may be sending the messages very fast that the browser(previously mentioned IE browser only) may not be able to cope up with.
      Also we found that while fiddler is running, there is no problem in that .jsp file.
      If it is the real case for the problem, what should we do? Can you help us?

      Thanks

      Comment


        #4
        This may require over-the-should debugging via web conference. But a couple more questions first:

        1) this message log appears to indicate 332k of downstream message traffic every 4 seconds. Is this expected?

        2) what are your settings for connection TTL? This log also appear to indicate connection teardown and re-establish happening every 4 seconds

        3) did you notice you have a 404 not found for the FileLoader module? This slows down page load and isn't a cacheable response, and can have other consequences

        4) you mentioned the possibility of the browser not being fast enough (not sure why), but to test this theory, does the problem disappear if you disable the code that actually takes action when the browser receives messages?

        5) have you reproduced this on more than one machine?

        6) have you reproduced this on a clean install (not set up with any special developer tools you usually install)?

        Comment


          #5
          Hi

          1)332k of downstream message traffic is expected.

          2) Our connection TTL settings in server.properties file are

          Code:
          # how often do we send keepalives to the client (ms)
                 messaging.keepaliveInterval: 3000
          # how long the client waits after the keepaliveInterval before re-establishing
          # the connection (ms)
                 messaging.keepaliveReestablishDelay: 1000
          # how long the client waits for the connect handshake to complete before
          # retrying
                messaging.connectTimeout: 4000
          # connection time to live - the maximum amount of time a persistent connection
          # is allowed to stay open before being re-established (ms)
                messaging.connectionTTL: 120000
          # total response size to pad out to in order to defeat intervening
          # bufferring by proxies (bytes)
                messaging.flushBufferSize: 8096
          Can you tell where we can find more information about these parameters? If these parameters causes the problem, then what are right values?. And How can we find that connection teardown and re-establish are happening every 4 seconds?

          3) we fixed 404 problem. But there is no difference.

          4) The problem disappears when we have some alerts in between the code.

          5) Yes. We reproduced on more than one machine having exactly the same IE version.

          6) Not Sure.

          Comment


            #6
            Hello Mahen,

            Please take another crack at some of these questions - the answers were incomplete:

            1) this message log appears to indicate 332k of downstream message traffic every 4 seconds. Is this volume of traffic expected every 4 seconds?

            4) you mentioned the possibility of the browser not being fast enough (not sure why), but to test this theory, does the problem disappear if you disable the code that actually takes action when the browser receives messages? The fact that problem disappears with alert()s does not answer this question. alert()s have many bizarre consequences and adding periodic alert()s does not clarify whether your application code is struggling to process all the data.

            Your settings appear to be fine.

            Can you also add a log category called "Messaging" in the Developer Console and set the priority to DEBUG. You should then see various logs such as "connection to server lost, re-establishing" which may help troubleshoot the issue.

            Comment

            Working...
            X