qx.io.remote.Request queued but not queued and qooxdoo hangs

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

qx.io.remote.Request queued but not queued and qooxdoo hangs

Kenneth Tilton-3
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

@tiltonsalgebra

<a href="tel:646-269-1077" value="+16462691077" target="_blank">646-269-1077

"In a class by itself." -Macworld



------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qx.io.remote.Request queued but not queued and qooxdoo hangs

Kenneth Tilton-3
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. :)

-kt

On Tue, Oct 20, 2015 at 9:55 AM, Kenneth Tilton <[hidden email]> 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

@tiltonsalgebra

<a href="tel:646-269-1077" value="+16462691077" target="_blank">646-269-1077

"In a class by itself." -Macworld





--
Kenneth Tilton
54 Isle of Venice Dr
Fort Lauderdale, FL 33301

@tiltonsalgebra

646-269-1077

"In a class by itself." -Macworld



------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qx.io.remote.Request queued but not queued and qooxdoo hangs

Kenneth Tilton-3


On Tue, Oct 20, 2015 at 12:16 PM, Kenneth Tilton <[hidden email]> 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 <[hidden email]> 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

@tiltonsalgebra

<a href="tel:646-269-1077" value="+16462691077" target="_blank">646-269-1077

"In a class by itself." -Macworld





--
Kenneth Tilton
54 Isle of Venice Dr
Fort Lauderdale, FL 33301

@tiltonsalgebra

<a href="tel:646-269-1077" value="+16462691077" target="_blank">646-269-1077

"In a class by itself." -Macworld





--
Kenneth Tilton
54 Isle of Venice Dr
Fort Lauderdale, FL 33301

@tiltonsalgebra

646-269-1077

"In a class by itself." -Macworld



------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qx.io.remote.Request queued but not queued and qooxdoo hangs

Kenneth Tilton-3


On Wed, Oct 21, 2015 at 10:28 AM, Kenneth Tilton <[hidden email]> wrote:


On Tue, Oct 20, 2015 at 12:16 PM, Kenneth Tilton <[hidden email]> 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 <[hidden email]> 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

@tiltonsalgebra

<a href="tel:646-269-1077" value="+16462691077" target="_blank">646-269-1077

"In a class by itself." -Macworld





--
Kenneth Tilton
54 Isle of Venice Dr
Fort Lauderdale, FL 33301

@tiltonsalgebra

<a href="tel:646-269-1077" value="+16462691077" target="_blank">646-269-1077

"In a class by itself." -Macworld





--
Kenneth Tilton
54 Isle of Venice Dr
Fort Lauderdale, FL 33301

@tiltonsalgebra

<a href="tel:646-269-1077" value="+16462691077" target="_blank">646-269-1077

"In a class by itself." -Macworld





--
Kenneth Tilton
54 Isle of Venice Dr
Fort Lauderdale, FL 33301

@tiltonsalgebra

646-269-1077

"In a class by itself." -Macworld



------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qx.io.remote.Request queued but not queued and qooxdoo hangs

Kenneth Tilton-3
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 <[hidden email]> wrote:


On Wed, Oct 21, 2015 at 10:28 AM, Kenneth Tilton <[hidden email]> wrote:


On Tue, Oct 20, 2015 at 12:16 PM, Kenneth Tilton <[hidden email]> 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 <[hidden email]> 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

@tiltonsalgebra

<a href="tel:646-269-1077" value="+16462691077" target="_blank">646-269-1077

"In a class by itself." -Macworld





--
Kenneth Tilton
54 Isle of Venice Dr
Fort Lauderdale, FL 33301

@tiltonsalgebra

<a href="tel:646-269-1077" value="+16462691077" target="_blank">646-269-1077

"In a class by itself." -Macworld





--
Kenneth Tilton
54 Isle of Venice Dr
Fort Lauderdale, FL 33301

@tiltonsalgebra

<a href="tel:646-269-1077" value="+16462691077" target="_blank">646-269-1077

"In a class by itself." -Macworld





--
Kenneth Tilton
54 Isle of Venice Dr
Fort Lauderdale, FL 33301

@tiltonsalgebra

<a href="tel:646-269-1077" value="+16462691077" target="_blank">646-269-1077

"In a class by itself." -Macworld





--
Kenneth Tilton
54 Isle of Venice Dr
Fort Lauderdale, FL 33301

@tiltonsalgebra

646-269-1077

"In a class by itself." -Macworld



------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qx.io.remote.Request queued but not queued and qooxdoo hangs

John Spackman-3
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 <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Wednesday, 21 October 2015 at 20:12
To: qooxdoo Development <[hidden email]>
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qx.io.remote.Request queued but not queued and qooxdoo hangs

Dietrich Streifert
In reply to this post by Kenneth Tilton-3
Hi Kenneth,

would you mind sending you (asuming) qx.ui.table.model.Remote based
class to the list, so we can study what might be the problem?

Am 21.10.2015 um 21:12 schrieb Kenneth Tilton:

> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qx.io.remote.Request queued but not queued and qooxdoo hangs

Kenneth Tilton-3
In reply to this post by John Spackman-3
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 <[hidden email]> 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 <[hidden email]>
Reply-To: qooxdoo Development <[hidden email]>
Date: Wednesday, 21 October 2015 at 20:12
To: qooxdoo Development <[hidden email]>
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel




--
Kenneth Tilton
54 Isle of Venice Dr
Fort Lauderdale, FL 33301

@tiltonsalgebra

646-269-1077

"In a class by itself." -Macworld



------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
Reply | Threaded
Open this post in threaded view
|

Re: qx.io.remote.Request queued but not queued and qooxdoo hangs

Kenneth Tilton-3
In reply to this post by Dietrich Streifert
Hi, Dietrich.

On Thu, Oct 22, 2015 at 2:48 AM, Dietrich Streifert <[hidden email]> wrote:
Hi Kenneth,

would you mind sending you (asuming) qx.ui.table.model.Remote based
class to the list, so we can study what might be the problem?

Thx. Attached. Here is the code for clog:

var clogo = new Date();
function clog (s) {
  var now = new Date();
  console.log((now.getTime()-clogo.getTime()) + '>' + s );
}

I think I must be abusing the Remote widget somehow. I found that ugly hack blocking the one value that in one use of this code hangs on a row count of 17, but if this comes up again I will start with the way I am using this code.

For now I have punted.

Thx for jumping in.

-kenneth
 
 

Am 21.10.2015 um 21:12 schrieb Kenneth Tilton:
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel



--
Kenneth Tilton
54 Isle of Venice Dr
Fort Lauderdale, FL 33301

@tiltonsalgebra

646-269-1077

"In a class by itself." -Macworld



------------------------------------------------------------------------------

_______________________________________________
qooxdoo-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel