I was able to duplicate the JHS random 5 second delays with IE9 on several different PCs. I was not able to duplicate the delays in other browsers.
I noticed that core.ijs used 5000 ms timeouts for several common timeout values, so I changed them to different values to see if the IE9 delay problem was related to these timeouts: PC_RECVTIMEOUT=: 3000 PC_SENDTIMEOUT=: 4000 After the changes, all the random timeouts were now 3 seconds, tracking the PC_RECVTIMEOUT setting. I used IE9's F12 debugger to display more information about the delay: http://www.jsoftware.com/jwiki/DavidMitchell?action=AttachFile&do=get&target=IE9delay1.png I was curious to see what JHS was doing, so I enabled PC_LOG and got information similar to this: 2012 1 18 23 37 7 810 jhs : jhs sentence: jev_jijx_ 0 URL=jijx 2012 1 18 23 37 7 811 jhs : output type : 3 2012 1 18 23 37 7 812 jhs : output type : 6 2012 1 18 23 37 7 814 jhs : output type : 3 2012 1 18 23 37 7 816 jhs : output type : 1 2012 1 18 23 37 7 818 jhs : output type : 3 2012 1 18 23 37 7 819 jhs : output type : 3 2012 1 18 23 37 7 821 jhs : output type : 1 2012 1 18 23 37 7 823 jhs : output type : 3 2012 1 18 23 37 7 824 jhs : jhs input prompt: 3 2012 1 18 23 37 7 826 jijx : htmlresponse 2012 1 18 23 37 7 827 jijx : putdata 2012 1 18 23 37 7 829 jhs : getdata loop 2012 1 18 23 37 7 830 jhs : sdaccept in 2012 1 18 23 37 8 358 jhs : sdaccept out: SKSERVER=208 SKLISTEN=392 2012 1 18 23 37 8 360 jhs : getpeer in 2012 1 18 23 37 8 361 jhs : getpeer out 2012 1 18 23 37 8 361 jhs : recv1 loop 2012 1 18 23 37 11 362 jhs : recv timeout But, that was only 1/2 the story. I could not see what IE9 was doing. I looked at several different methods to find out what IE9 was doing and settled on using the MS built-in winsock tracing. This gave me XML format results that were quite large. I used Oleg's X2J great XML->J tool to boil it down to entries like this (truncated for email): 2012-01-21T17:23:38.698988400Z Stream socket socket: 0: Process 0xFFFFFA800476F0 2012-01-21T17:23:38.699603800Z Stream socket socket: 0: Process 0xFFFFFA800476F0 2012-01-21T17:23:38.699649100Z Stream socket socket: 1: Process 0xFFFFFA800476F0 2012-01-21T17:23:38.699987700Z Stream socket bind: 0: Process 0xFFFFFA800476F060 2012-01-21T17:23:38.700139900Z Stream socket bind: 1: Process 0xFFFFFA800476F060 2012-01-21T17:23:38.700245200Z Stream socket Listen: 0: Process 0xFFFFFA800476F0 2012-01-21T17:23:38.703119100Z Stream socket Listen: 1: Process 0xFFFFFA800476F0 2012-01-21T17:23:38.705405400Z Stream socket Wait for listen: 0: Process 0xFFFFF 2012-01-21T17:23:56.709605600Z Stream socket socket cleanup: 0: Process 0xFFFFFA 2012-01-21T17:23:56.709609800Z Stream socket socket cleanup: 1: Process 0xFFFFFA Now, I was hoping to merge the J log with the socket log to see how exactly the events landed. But, there was one immediate issue: The J log had 3 digits of fractional seconds. The socket log had 7 digits of fractional seconds. The J log was just too coarse to be sequenced reliably. So, I modified the J log to use MS logging and used MFTRACE to capture and format the J logs. This got me logs like this: __M_F_T_R_A_C_E___LOG__ PID, TID Time (UTC) TraceMessage --------- -------------- ------------ 5868,A98 22:23:38.70601 2012 1 21 17 23 38 698 jhs : jhs input prompt: 3 5868,A98 22:23:38.70611 2012 1 21 17 23 38 698 jhs : getdata loop 5868,A98 22:23:38.70618 2012 1 21 17 23 38 698 jhs : sdaccept in 5868,A98 22:24:13.05954 2012 1 21 17 24 13 62 jhs : sdaccept out: SKSERVER=208 SKLISTEN=392 5868,A98 22:24:13.05962 2012 1 21 17 24 13 62 jhs : getpeer in 5868,A98 22:24:13.05984 2012 1 21 17 24 13 62 jhs : getpeer out 5868,A98 22:24:13.05992 2012 1 21 17 24 13 62 jhs : recv1 loop 5868,A98 22:24:13.06035 2012 1 21 17 24 13 62 jhs : get This was better. MFTRACE was formatting the logs with 5 digits of fractional seconds. Now, I could reformat both logs to use the same time resolution and merge them with some hope of realistic sequencing. 24 13 19178 send: 1: Process 0xFFFFFA800476F060, Endpoint 0xFFFFFA8001A9A290, Bu 24 13 19482 recv: 0: Process 0xFFFFFA8004CEB950, Endpoint 0xFFFFFA8004C9DA20, Bu 24 13 19483 recv: 1: Process 0xFFFFFA8004CEB950, Endpoint 0xFFFFFA8004C9DA20, Bu 24 13 29400 recv: 0: Process 0xFFFFFA8004CEB950, Endpoint 0xFFFFFA8004C9DA20, Bu 24 13 29401 recv: 1: Process 0xFFFFFA8004CEB950, Endpoint 0xFFFFFA8004C9DA20, Bu 24 13 29415 recv: 0: Process 0xFFFFFA8004CEB950, Endpoint 0xFFFFFA8004C9DA20, Bu 24 13 29415 recv: 1: Process 0xFFFFFA8004CEB950, Endpoint 0xFFFFFA8004C9DA20, Bu 24 13 29420 socket cleanup: 0: Process 0xFFFFFA8004CEB950, Endpoint 0xFFFFFA8004 24 13 29428 disconnect indicated: 3: Process 0xFFFFFA800476F060, Endpoint 0xFFFF 24 13 29508 socket cleanup: 1: Process 0xFFFFFA8004CEB950, Endpoint 0xFFFFFA8004 24 13 29509 closesocket: 0: Process 0xFFFFFA8004CEB950, Endpoint 0xFFFFFA8004C9D 24 13 29572 closesocket: 1: Process 0xFFFFFA8004CEB950, Endpoint 0xFFFFFA8004C9D 24 16 17985 socket cleanup: 0: Process 0xFFFFFA800476F060, Endpoint 0xFFFFFA8002 24 16 17990 disconnect indicated: 3: Process 0xFFFFFA8004CEB950, Endpoint 0xFFFF 24 16 17993 socket cleanup: 1: Process 0xFFFFFA800476F060, Endpoint 0xFFFFFA8002 24 16 17993 closesocket: 0: Process 0xFFFFFA800476F060, Endpoint 0xFFFFFA80024B7 24 16 17993 closesocket: 1: Process 0xFFFFFA800476F060, Endpoint 0xFFFFFA80024B7 24 16 18037 Wait for listen: 0: Process 0xFFFFFA800476F060, Endpoint 0xFFFFFA800 24 16 18091 2012 1 21 17 24 16 183 jhs : recv timeout 24 16 18102 2012 1 21 17 24 16 183 jhs : getdata error: 24 16 18109 2012 1 21 17 24 16 183 jhs : getdata loop 24 16 18117 2012 1 21 17 24 16 183 jhs : sdaccept in I left in the 6!:0 '' J timestamps and I found it interesting that the MS log timestamp was always earlier than the J timestamp. That may just be caused by the 15ms granularity of my Win7 clock. -- David Mitchell On 1/4/2012 11:36, Eric Iverson wrote: > I have observed and heard that IE9 is slow and uneven in its use with JHS. > But nothing near as bad as you report. On the machine you describe JHS > response should be immediate. Is there any chance you could try chrome or > firefox on that machine to verify that they are responsive and that the > problem is with IE and not something else? > > On Wed, Jan 4, 2012 at 10:11 AM, Raul Miller<[email protected]> wrote: > >> Part 1: I need help >> >> I am not sure which forum this belongs in... >> >> I had the opportunity to use jhs on a reasonably fast machine. Not >> super fast, maybe, but 6 cores, each 3.5GHz, 12gb ram, terrabyte hard >> disk... >> >> Anyways, on this machine, jhs would often take 5 seconds to respond, >> after I hit enter. The machine was practically unloaded, and some >> responses were quick, but many took five seconds. >> >> This was using IE for the web browser (other browsers were not an >> option). This was a current jhs (updated to current versions of all >> packages a few days ago). >> >> Has anyone seen anything like this before? Does anyone know what I >> might do to isolate the issue? >> >> ---------------- >> >> Part 2: notes related to ui design >> >> Also, I should note that the jhs browser implementation does not >> provide very good feedback about whether it's waiting or not, in this >> situation. For example, when using r to save and run a script: >> >> 1. It's not clear when the focus is proper so that r can be sent, and >> 2. After the first save and run instance, it's not clear whether the >> message being displayed is current or historic and it's not clear when >> it's done. >> >> I can tell if the browser is waiting by looking at the upper right >> hand corner of the browser, but this is a very subtle effect. >> >> I can sometimes get a "please wait" message by repeating my attempts. >> >> -- >> Raul >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm >> > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
