Hello, all. I thought I would spawn this subject into a separate thread as it is a very serious issue. To summarize, when using firefox/iceweasel in X2Go, the browser frequently hangs for between 16 and 20 seconds. All other applications work perfectly fine, accept input, and display output, but the browser window remains frozen. Once it unfreezes, all input and output is processed, e.g., typed letters are displayed and tab clicks are executed. It appears to happen in AJAX intensive sites (Zimbra, GMail, GLPI) but this is not definitive.
We initially thought it was a Windows only problem but Phil has confirmed he experiences this regularly in Linux using client 3.0.1.18. I confirm it on Windows 3.99.
I wondered if it was because our servers are still using 3.0.1-5 as this smells like it could be an NXAgent problem. I connected to an X2Go server using the latest X2GoAgent (3.5.0.2-0~x2go1 +squeeze~heuler~201107) and experienced the same problem. I have backleveled my Windows system to 3.0.1-4 to see if the problem goes away but do not have enough data yet to report. Thanks - John
On Tue, Aug 2, 2011 at 11:09 AM, John A. Sullivan III <jsullivan@opensourcedevel.com> wrote:
I wondered if it was because our servers are still using 3.0.1-5 as this smells like it could be an NXAgent problem. I connected to an X2Go server using the latest X2GoAgent (3.5.0.2-0~x2go1 +squeeze~heuler~201107) and experienced the same problem. I have backleveled my Windows system to 3.0.1-4 to see if the problem goes away but do not have enough data yet to report. Thanks - John
I am also using server 3.0.1-5.
Here is a summary of whether I have seen this bug with different windows client versions (64-bit Windows 7 OS) on server 3.01-5:
windows client version bug occurs?
3.01-13 NO 3.01-18 YES 3.99 YES
On Tue, 2011-08-02 at 11:15 -0700, John Williams wrote:
On Tue, Aug 2, 2011 at 11:09 AM, John A. Sullivan III <jsullivan@opensourcedevel.com> wrote:
I wondered if it was because our servers are still using 3.0.1-5 as this smells like it could be an NXAgent problem. I connected to an X2Go server using the latest X2GoAgent (3.5.0.2-0~x2go1 +squeeze~heuler~201107) and experienced the same problem. I have backleveled my Windows system to 3.0.1-4 to see if the problem goes away but do not have enough data yet to report. Thanks - John
I am also using server 3.0.1-5.
Here is a summary of whether I have seen this bug with different windows client versions (64-bit Windows 7 OS) on server 3.01-5:
windows client version bug occurs?
3.01-13 NO 3.01-18 YES 3.99 YES <snip> I should add I am testing from Windows XP - John
On Tue, 2011-08-02 at 14:21 -0400, John A. Sullivan III wrote:
On Tue, 2011-08-02 at 11:15 -0700, John Williams wrote:
On Tue, Aug 2, 2011 at 11:09 AM, John A. Sullivan III <jsullivan@opensourcedevel.com> wrote:
I wondered if it was because our servers are still using 3.0.1-5 as this smells like it could be an NXAgent problem. I connected to an X2Go server using the latest X2GoAgent (3.5.0.2-0~x2go1 +squeeze~heuler~201107) and experienced the same problem. I have backleveled my Windows system to 3.0.1-4 to see if the problem goes away but do not have enough data yet to report. Thanks - John
I am also using server 3.0.1-5.
Here is a summary of whether I have seen this bug with different windows client versions (64-bit Windows 7 OS) on server 3.01-5:
windows client version bug occurs?
3.01-13 NO 3.01-18 YES 3.99 YES <snip> I should add I am testing from Windows XP - John <snip> I was able to gain some interesting, confounding, and possibly important data on this problem today. I still haven't hooked up xkbwatch but I did try a number of different combinations of clients and servers with astoundingly different results.
The above results posted by John Williams, my results on a XP platform, and Phil's results with 3.0.18 in Linux all have the 16-20 second delay when speaking to either 3.0.1-5 or 3.99.0.0 servers with both X2GoAgents 3.4 and 3.5.
However, I tried two new combinations today:
3.0.1-4 Windows client to 3.0.1-5 server: frequent delay but 3 - 4 seconds - much, much shorter. This explains why our clients are upset but not throwing us out the door as they are all using this combination.
3.0.1-4 Windows client to 3.99.0.0 server with X2GoAgent 3.5: No delay whatsoever - and that's after pounding it for a long time.
I know nothing about NX internals so I am just speculating here. The problem only seems to be with heavy AJAX applications as far as I can tell. Could it be related to how AJAX only paints part of the screen? Could it be that NX does not pick up the screen change because if is only a subportion of the application Window and done in a way different from, for example, OpenOffice updates the area being typed? Could it be that every certain number of seconds, NX checks the entire screen for updates and that this timer is different in the various configurations and maybe non existent with two mismatched Agents?
I have no idea but I would consider this a blocking bug. I'll try to squeeze some xkbwatch in this week - John
Hi John, hi all,
On Mi 03 Aug 2011 16:18:48 CEST "John A. Sullivan III" wrote:
3.0.1-4 Windows client to 3.99.0.0 server with X2GoAgent 3.5: No delay whatsoever - and that's after pounding it for a long time.
This basically _very_ good new as it tells us that we have to look on
the client side (I hope).
I know nothing about NX internals so I am just speculating here. The problem only seems to be with heavy AJAX applications as far as I can tell. Could it be related to how AJAX only paints part of the screen? Could it be that NX does not pick up the screen change because if is only a subportion of the application Window and done in a way different from, for example, OpenOffice updates the area being typed? Could it be that every certain number of seconds, NX checks the entire screen for updates and that this timer is different in the various configurations and maybe non existent with two mismatched Agents?
So we should list up the differences between x2goclient 3.0.1-4
(Windows and 3.99.0.x (also on Windows).
There are many... Who can do this?
I have no idea but I would consider this a blocking bug. I'll try to squeeze some xkbwatch in this week - John
Can you, John, or anyone else give a howto that explains how to
reproduce this problem on a fresh server install (Debian squeeze) and
a fresh client install (Windows, what version?, what arch? what
Xserver? Etc.). We have to try to address this issue in a very generic
way if we/you want it solved.
Expecting a debugging recipe to trace this bug... THANKS!
Greets, Mike
--
DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419
GnuPG Key ID 0xB588399B mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...
On Sun, 2011-08-14 at 18:44 +0200, Mike Gabriel wrote:
Hi John, hi all,
On Mi 03 Aug 2011 16:18:48 CEST "John A. Sullivan III" wrote:
3.0.1-4 Windows client to 3.99.0.0 server with X2GoAgent 3.5: No delay whatsoever - and that's after pounding it for a long time.
This basically _very_ good new as it tells us that we have to look on
the client side (I hope).I know nothing about NX internals so I am just speculating here. The problem only seems to be with heavy AJAX applications as far as I can tell. Could it be related to how AJAX only paints part of the screen? Could it be that NX does not pick up the screen change because if is only a subportion of the application Window and done in a way different from, for example, OpenOffice updates the area being typed? Could it be that every certain number of seconds, NX checks the entire screen for updates and that this timer is different in the various configurations and maybe non existent with two mismatched Agents?
So we should list up the differences between x2goclient 3.0.1-4
(Windows and 3.99.0.x (also on Windows).There are many... Who can do this?
I have no idea but I would consider this a blocking bug. I'll try to squeeze some xkbwatch in this week - John
Can you, John, or anyone else give a howto that explains how to
reproduce this problem on a fresh server install (Debian squeeze) and
a fresh client install (Windows, what version?, what arch? what
Xserver? Etc.). We have to try to address this issue in a very generic
way if we/you want it solved.Expecting a debugging recipe to trace this bug... THANKS!
We can produce this without fail in our Zimbra environment. There is an Zimbra live demo at http://www.zimbra.com/products/hosted_demo.php I would think you could run this from any X2Go server although the reliable problem for us is chat and I do not know if the Zimbra demo has chat.
I think John Williams and others had readily reproducible non-Zimbra procedures to produce this error including GMail (I do not know which functions).
As I mentioned. the problem should be reproducible from any X2Go server but, if you'd like, I can give you the credentials to login to one of our demo systems. Let me know if you prefer to go that route.
This and the printing crash are the two blocking bugs in my assessment. Thanks - John
On 2011-08-15 19:55, John A. Sullivan III wrote:
We can produce this without fail in our Zimbra environment. There is an Zimbra live demo at http://www.zimbra.com/products/hosted_demo.php I would think you could run this from any X2Go server although the reliable problem for us is chat and I do not know if the Zimbra demo has chat.
I just tested FF6. To me it seems to much more responsive on js-intensive sites (in my case google maps). Could you give that a try? I know it's poking in the dark, but to me the whole issue seems odd as it was not yet possible to put a finger onto the reason. (Probably it's some bug in the server that gets hidden by most applications or something on the client doing something odd ;) )
Morty
-- Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter) Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstr. 1 91058 Erlangen
Tel : +49 9131 85-25419 Fax : +49 9131 85-28732 eMail : struebe@informatik.uni-erlangen.de WWW : http://www4.informatik.uni-erlangen.de/~morty
On Tue, 2011-08-16 at 18:16 +0200, Moritz Struebe wrote:
On 2011-08-15 19:55, John A. Sullivan III wrote:
We can produce this without fail in our Zimbra environment. There is an Zimbra live demo at http://www.zimbra.com/products/hosted_demo.php I would think you could run this from any X2Go server although the reliable problem for us is chat and I do not know if the Zimbra demo has chat.
I just tested FF6. To me it seems to much more responsive on js-intensive sites (in my case google maps). Could you give that a try? I know it's poking in the dark, but to me the whole issue seems odd as it was not yet possible to put a finger onto the reason. (Probably it's some bug in the server that gets hidden by most applications or something on the client doing something odd ;) )
Hmm.. . I'm not sure FF6 will be an option for us. I'll have a look and see what I can do. I don't know if that is an option for John Williams. On the other hand, I don't think we can say to folks X2Go works only for users with FF6 or newer :( Thanks - John
On 2011-08-02 20:09, John A. Sullivan III wrote:
To summarize, when using firefox/iceweasel in X2Go, the browser frequently hangs for between 16 and 20 seconds. All other applications work perfectly fine, accept input, and display output, but the browser window remains frozen. Once it unfreezes, all input and output is processed, e.g., typed letters are displayed and tab clicks are executed. It appears to happen in AJAX intensive sites (Zimbra, GMail, GLPI) but this is not definitive.
The smells like Nagle, but who knows.... Can you give information on your connection parameters. For example: I'm in a LAN and noticed that I get the best results using no compression (rgb) - but one in a while there are small errors in the disply (e.g. an immage not being updated correctly) - opposed to png. I also have the gnome-system-monitor-applet running, therefore data is sent continuously. I would also be interested whether the whole screen hangs (e.g. including the system monitor) or only the single Applicaiton. Maby you cold start xkbwatch and see, whether the keystrokes (e.g. shift ) still arrive at the server.
Cheers Morty
-- Dipl.-Ing. Moritz 'Morty' Struebe (Wissenschaftlicher Mitarbeiter) Lehrstuhl für Informatik 4 (Verteilte Systeme und Betriebssysteme) Friedrich-Alexander-Universität Erlangen-Nürnberg Martensstr. 1 91058 Erlangen
Tel : +49 9131 85-25419 Fax : +49 9131 85-28732 eMail : struebe@informatik.uni-erlangen.de WWW : http://www4.informatik.uni-erlangen.de/~morty
On Tue, Aug 2, 2011 at 11:39 AM, Moritz Struebe <Moritz.Struebe@informatik.uni-erlangen.de> wrote:
The smells like Nagle,
What is Nagle?
Can you give information on your connection parameters.
I have the connection set to WAN 16m-jpeg-9
I would also be interested whether the whole screen hangs (e.g. including the system monitor) or only the single Applicaiton.
Usually only Firefox hangs for me. I can usually switch to another window like gnome-terminal and it works normally. However, once or twice I have had everything freeze (that seemed to happen when I kept messing with the firefox process, kill -9 and so forth).
On Tue, 2011-08-02 at 12:49 -0700, John Williams wrote:
On Tue, Aug 2, 2011 at 11:39 AM, Moritz Struebe <Moritz.Struebe@informatik.uni-erlangen.de> wrote:
The smells like Nagle,
What is Nagle?
<snip> Nagle is an algorithm which coalesces small TCP responses into larger ones to improve throughput at the expense of latency. In X2Go, we generally want the lowest latency possible - John
On Tue, 2011-08-02 at 20:39 +0200, Moritz Struebe wrote:
On 2011-08-02 20:09, John A. Sullivan III wrote:
To summarize, when using firefox/iceweasel in X2Go, the browser frequently hangs for between 16 and 20 seconds. All other applications work perfectly fine, accept input, and display output, but the browser window remains frozen. Once it unfreezes, all input and output is processed, e.g., typed letters are displayed and tab clicks are executed. It appears to happen in AJAX intensive sites (Zimbra, GMail, GLPI) but this is not definitive.
The smells like Nagle, but who knows.... Can you give information on your connection parameters. For example: I'm in a LAN and noticed that I get the best results using no compression (rgb) - but one in a while there are small errors in the disply (e.g. an immage not being updated correctly) - opposed to png. I also have the gnome-system-monitor-applet running, therefore data is sent continuously. I would also be interested whether the whole screen hangs (e.g. including the system monitor) or only the single Applicaiton. Maby you cold start xkbwatch and see, whether the keystrokes (e.g. shift ) still arrive at the server.
<snip> I believe we can rule out Nagle or anything on the network layer because it only affects the single application. If it were Nagle, the entire connection would freeze while it buffered responses and this would typically appear as a slight lag I believe - not a 20 second delay.
The single application feature is the strange part. This is a WAN environment using 16m-png-jpeg. While the browser is hung, all other applications interact appropriate so data is being transmitted.
xkbwatch sounds like an interesting idea. I have never used it but will find out how. Thanks - John
-
John A. Sullivan III -
John Williams -
Mike Gabriel -
Moritz Struebe