HI, John. I finally concluded that the apparent request issue was just a consequence of the client hanging* after being supplied the particular row count 17 (which is strange, but I pass 18 when it is 17 and got on with more pressing production matters.)
* Indeed, at first I had seen two requests stuck in the pending state, one just relaying an onappear event to the server app. That was not doing much so to simplify things I eliminated it, but in hindsight it would have helped me realize the request mechanics themselves were fine. Chrome did not interrupt the page so i had time to look around and saw one of its processes at 25%, killed that, and...hmmm, the page finished loading the data. Makes me wonder what process had hung and was also holding up the page! Anyway, I really do not think the request logic is a problem. Thx for jumping in. If this comes up again I will stare at my remote table code to see what I am doing to break it -- 17 is not the problem (I checked a different remote table I have) <g>. Thx again, ken On Thu, Oct 22, 2015 at 2:35 AM, John Spackman <john-li...@zenesis.com> wrote: > Hi Kenneth > > Can you reproduce this if you stubbed out the remote call, simulating the > callback with a setTimeout()? From your descriptions I’m not clear on > whether there is a problem in the request handling or the UI code, and if > you could show that it has nothing to do with the server request then you > could create a playground example to reproduce the problem (which would > make it much easier to help) > > Also, are you saying that he students with the problem have the _same_ > code (client and server) but just their machine hangs? Or functionally > similar code written by different people? > > Regards > John. > > From: Kenneth Tilton <k...@tiltontec.com> > Reply-To: qooxdoo Development <qooxdoo-devel@lists.sourceforge.net> > Date: Wednesday, 21 October 2015 at 20:12 > To: qooxdoo Development <qooxdoo-devel@lists.sourceforge.net> > Subject: Re: [qooxdoo-devel] qx.io.remote.Request queued but not queued > and qooxdoo hangs > > 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 > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > qooxdoo-devel mailing list > qooxdoo-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > -- 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
