And now we descend into the rabbit hole: The students on which the request hangs are the only ones with 17 rows of data. It is the count that corrupts things, not the data, and I can unhang the student by adding or removing data or just by lying when I call _onLoadRowCount and passing 18 if the true count is 17. (16 also works but would hide data from the user.)
I did change the block size to see if that flushed the bug, but no luck. Can't wait to see what this is about, but I am no longer worrying about request handling -- from what I have seen it is just that qooxdoo hangs and so the code that would grab the queued request and dispatch it just never runs. Getting close. -kt On Wed, Oct 21, 2015 at 12:15 PM, Kenneth Tilton <k...@tiltontec.com> wrote: > > > On Wed, Oct 21, 2015 at 10:28 AM, Kenneth Tilton <k...@tiltontec.com> > wrote: > >> >> >> 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. >>>> >>> > This last suspicion seems to be supported: just to stir things up I made > the hanging loadrowdata request synchronous, and it did not get stuck in > the queued state. But the next one did. > > So now the question is little more precise: why would an asynchronous > request get stuck as queued (until FireFox interrupts things)? > > Thx for any ruminations at all. > > btw, it continues to be just the same three data rows, which is bizarre > but then bugs are like that, :) > > -kt > > >>>> 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* >> >> >> > > > -- > 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
