On Tue, Oct 20, 2015 at 12:16 PM, Kenneth Tilton <k...@tiltontec.com> wrote:
> Never mind. It finally occurred to me to try FireFox, and that still hangs > but manages to output the last console logging and indeed I see the > expected messages. Now exploring much further downstream. :) > No, I was right the first time. I went back and added timestamps to the logging and now can see the request being queued and just sitting there for eleven seconds (I have timeout at 6). FireFox then puts up the alert that lets me stop the script and this actually gets qooxdoo rolling and I see the expected processing, which actually completes nicely filling up the table with the correct data. And yes, on the server side nothing happens until FireFox steps in. I have started adding logging to qooxdoo, but if anyone can guess why a request would get stuck as queued (with the CPU busy at 25%) I would appreciate some directions in which to explore. Thx! -kt > -kt > > On Tue, Oct 20, 2015 at 9:55 AM, Kenneth Tilton <k...@tiltontec.com> wrote: > >> Stack: >> >> 1. Windows 7, server and client, client talking to server as localhost >> 2. qooxdoo dsktop 5.0.1 just now downloaded >> 3. Chrome browser just updated >> 4. AllegroServe (Lisp) server >> >> Problem synopsis: remote table load request (and everything else) works >> for 98% of (it so happens) students. On three we get a puzzle: >> >> 1. all events are logged, and the only thing the log shows for these >> three cases is a changestate from configured to queued; but... >> 2. the request is in fact received by the server and successfully >> process and returned with a 200 status; but... >> 3. the page is hung and cannot even be interrupted. I have to use the >> task manager to kill it, easily identified as the one using 25% CPU >> 4. I dummied the data to hardcoded strings and digits and that >> appears for all other students. >> >> >> Note that for the 98% of working cases the logging shows state proceeding >> as expected from queued to sending to receiving. >> >> My thinking (confirmed by dummy data not helping) is that qooxdoo is >> already broken when this sequence begins, such that a request gets >> successfully and correctly sent without qooxdoo logging the corresponding >> events. Thus my suspect is the preceding loadrowcount request, which might >> have left qooxdoo in a broken state. >> >> I will continue tinkering with the three failing cases to see how they >> differ, stare at the loadrowcount request, and later start hacking qooxdoo >> internals. >> >> Any thoughts are welcome! >> >> Thanks, Kenneth >> >> -- >> Kenneth Tilton >> 54 Isle of Venice Dr >> Fort Lauderdale, FL 33301 >> >> k...@tiltontec.com >> http://tiltontec.com >> @tiltonsalgebra >> >> 646-269-1077 >> >> "In a class by itself." *-Macworld* >> >> >> > > > -- > Kenneth Tilton > 54 Isle of Venice Dr > Fort Lauderdale, FL 33301 > > k...@tiltontec.com > http://tiltontec.com > @tiltonsalgebra > > 646-269-1077 > > "In a class by itself." *-Macworld* > > > -- Kenneth Tilton 54 Isle of Venice Dr Fort Lauderdale, FL 33301 k...@tiltontec.com http://tiltontec.com @tiltonsalgebra 646-269-1077 "In a class by itself." *-Macworld*
------------------------------------------------------------------------------
_______________________________________________ qooxdoo-devel mailing list qooxdoo-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
