RE: AW: AW: AW: Sockets vs Event Queue on WinXP

-----Original Message-----
From: Glazier, Sean [mailto:[hidden email]]
Sent: 27. elokuuta 2007 16:35
To: Cham Püschel; VWNC
Subject: RE: AW: AW: AW: Sockets vs Event Queue on WinXP

This is an issue getting socket events correctly and I am working on the problem as well as a number of other issues. It is a hard to track down issue and we are working on solving it. Anything that will generate events will keep the socket alive. We are either missing a socket event or are not getting it in the first place. The socket layer was refactored in 7.5 so we don’t need an invisible window in the background to get socket event through.

 

Sean

 

From: Cham Püschel [mailto:[hidden email]]
Sent: Monday, August 27, 2007 5:33 AM
To: VWNC
Subject: Re: AW: AW: AW: Sockets vs Event Queue on WinXP

 

Hi Klaus,

you're correct: Just the Delay will do the trick.

Cham

Mülheims wrote:

Hi,

 

in the meantime we found the same workaround, but without the call of Screen default flush. In our environment it's enough to loop after the Delay wait.

Any statements from cincom?

 

Greeting

 

Klaus

 

Collogia AG

Ubierring 11

 

50678 Köln

Germany

+49 221 336080

http://www.collogia.de

 

 

---

Von: Cham Püschel [[hidden email]]
Gesendet: Montag, 27. August 2007 12:09
An: VWNC
Cc: Mülheims, Klaus
Betreff: Re: AW: AW: Sockets vs Event Queue on WinXP

Hi,

we are probably having the same problem on our system. We have two images on the same machine using opentalk to communicate. These images are running on Windows2003 R2. From time to time we will get a RemoteInvocationTimeout. Doing the tests described below on a XP machine will stop quite soon ( a few seconds). We haven't been able to reproduce the problem on Windows2003, but it might be possible that it occurs there only after a certain amount of time. We are going to implement the following workaround:

[[Screen default flush. (Delay forMilliseconds: 100) wait] repeat ] forkAt: Processor systemRockBottomPriority

Starting this process will keep Opentalk running without any significant load.

Regards,

Cham

Mülheims wrote:

Hi,

We are having the same problem, perhaps after updating from 7.4 to 7.5.

Has anybody got any ideas to solve the problem?

Greetings

Klaus Mülheims

Collogia AG

Ubierring 11

50678 Köln

Germany

+49 221 336080

http://www.collogia.de

-----Ursprüngliche Nachricht-----

Von: Martin Kobetic [[hidden email]] 

Gesendet: Montag, 28. Mai 2007 18:25

An: Christian Haider

Cc: VWNC

Betreff: Re: AW: Sockets vs Event Queue on WinXP

Thanks for trying Christian!

The setup is pretty simple. The server must be an XP (possibly SP2 as well, I don't have any other XP setup available). Just start an image, load Opentalk-STST and start a broker:

        broker := (RequestBroker newStstTcpAtPort: 42424) start.

Then on any other machine (I've been using Linux mostly, but I don't think that matters) start a broker as well:

        broker := (RequestBroker newStstTcpAtPort: 0) start.

And run the following script (adjusting the server name to the name of the first host):

        server := broker activeBrokerAtHost: 'servername' port: 42424.

        [ Transcript show: (server echo: '*'). (Delay forMilliseconds: 500) wait ] repeat.

This will print a * for each successful echo. It should get stuck after a short while. Wiggling a mouse over the VW windows on the server should revive it. The key seems to be that the VW windows on the XP server must have focus. Without it it doesn't seem to happen (That's why it took a while to reproduce). Actually you may need to get the mouse off the VW windows as well, I'm not sure (I've been mostly using rdesktop to drive the XP machine, so my mouse is off those windows most of the time).

Cheers,

Martin

Christian Haider wrote:

Sorry, tried to find the reference ... again with no luck (did I dream this?).

But great news that you can reproduce the problem! 

I tried and couldnt reproduce it reliably... Would you mind posting your setup?

Good luck,

  Christian

-----Ursprüngliche Nachricht-----

Von: Martin Kobetic [[hidden email]] 

Gesendet: Montag, 28. Mai 2007 17:31

An: VWNC; Christian Haider

Betreff: Sockets vs Event Queue on WinXP

Hi All,

I have some questions about an issue that Christian Heider 

brought up on this list back in march 

(http://www.parcplace.net/list/vwnc-archive/0703/msg00036.html

). Here's a quick quote:

"We were getting lots of timeouts or server-not-responding 

errors on the clients. First we tried WLAN and switched to 

LAN later. LAN was much better but still quite bad. Then I 

remembered that a long time ago, I read something about 

Windows no reacting to socket events when there are no window 

events on the machine. So, I instructed the groups to always 

shake the mouse when sending requests to the server. At the 

same time I was moving the mouse on the server. This helped! 

(I think)."

We're looking into this problem now (AR#52279: "[STST] 

Opentalk hangs on server side if there is no GUI activity in 

VW." for reference) and we can reproduce it reliably on 

XP/SP2. We can't seem to get it to happen on W2K or W2K3 

server. The key prerequisite seems to be that a VW window 

must have focus, if that's not the case the problem doesn't 

occur (might help as an alternative workaround, instead of 

generating UI events somehow, until we figure this out). The 

impact of network latencies seems to be negligible, we can 

reproduce this on both WLAN and ethernet LANs without much trouble.

Anyway, while we're getting ready to debug this at the VM 

level I tried to search for the reference that Christian 

mentioned above, but had no luck. Christian, or anyone, can 

you still find that information about the socket dependecy on 

the event queue ? Anything on this topic might help us nail this down.

Thanks,

Martin

Diese Nachricht ist vertraulich. Wenn Sie nicht der beabsichtigte Empfänger sind, informieren Sie bitte den Absender. Das unbefugte Kopieren oder Weiterleiten ist nicht gestattet. Wegen der Manipulierbarkeit von E-Mails übernehmen wir keine Haftung für den Inhalt.

PENSIONS-SICHERUNGS-VEREIN Versicherungsverein auf Gegenseitigkeit

Vorsitzender des Aufsichtsrats: Dr. Dieter Hundt

Vorstand: Martin Hoppenrath (Vors.), Dr. Hermann Peter Wohlleben

Registergericht: AG Köln Nr. HRB 6821   Sitz: Köln

 

---

Diese Nachricht ist vertraulich. Wenn Sie nicht der beabsichtigte Empfänger sind, informieren Sie bitte den Absender. Das unbefugte Kopieren oder Weiterleiten ist nicht gestattet. Wegen der Manipulierbarkeit von E-Mails übernehmen wir keine Haftung für den Inhalt.

PENSIONS-SICHERUNGS-VEREIN Versicherungsverein auf Gegenseitigkeit
Vorsitzender des Aufsichtsrats: Dr. Dieter Hundt
Vorstand: Martin Hoppenrath (Vors.), Dr. Hermann Peter Wohlleben
Registergericht: AG Köln Nr. HRB 6821 Sitz: Köln

---

Von: Steven Kelly [mailto:[hidden email]]
Gesendet: Mittwoch, 20. Februar 2008 14:01
An: vwnc-list
Cc: Cham Püschel; Mülheims, Klaus
Betreff: RE: AW: AW: AW: Sockets vs Event Queue on WinXP

We've started seeing the "socket delay" problem quoted below, on one PC out of six tested (all Windows XP SP2, VW 7.4.1 with 7.4d VM). Wiggling the mouse or using the workaround background process help for us. Does anyone have experience with the workaround background process below, or a modified version or different workaround that has worked better?

 

[[(Delay forMilliseconds: 100) wait] repeat] forkAt: Processor systemRockBottomPriority

We have a yearly release due on Friday, so upgrading to a newer VW or VM version is not an option for us at the moment.

 

Many thanks to those who have already worked on this,

Steve

-----Original Message-----
From: Glazier, Sean [mailto:[hidden email]]
Sent: 27. elokuuta 2007 16:35
To: Cham Püschel; VWNC
Subject: RE: AW: AW: AW: Sockets vs Event Queue on WinXP

This is an issue getting socket events correctly and I am working on the problem as well as a number of other issues. It is a hard to track down issue and we are working on solving it. Anything that will generate events will keep the socket alive. We are either missing a socket event or are not getting it in the first place. The socket layer was refactored in 7.5 so we don’t need an invisible window in the background to get socket event through.

 

Sean

 

From: Cham Püschel [mailto:[hidden email]]
Sent: Monday, August 27, 2007 5:33 AM
To: VWNC
Subject: Re: AW: AW: AW: Sockets vs Event Queue on WinXP

 

Hi Klaus,

you're correct: Just the Delay will do the trick.

Cham

Mülheims wrote:

Hi,

 

in the meantime we found the same workaround, but without the call of Screen default flush. In our environment it's enough to loop after the Delay wait.

Any statements from cincom?

 

Greeting

 

Klaus

 

Collogia AG

Ubierring 11

 

50678 Köln

Germany

+49 221 336080

http://www.collogia.de

 

 

---

Von: Cham Püschel [[hidden email]]
Gesendet: Montag, 27. August 2007 12:09
An: VWNC
Cc: Mülheims, Klaus
Betreff: Re: AW: AW: Sockets vs Event Queue on WinXP

Hi,

we are probably having the same problem on our system. We have two images on the same machine using opentalk to communicate. These images are running on Windows2003 R2. From time to time we will get a RemoteInvocationTimeout. Doing the tests described below on a XP machine will stop quite soon ( a few seconds). We haven't been able to reproduce the problem on Windows2003, but it might be possible that it occurs there only after a certain amount of time. We are going to implement the following workaround:

[[Screen default flush. (Delay forMilliseconds: 100) wait] repeat ] forkAt: Processor systemRockBottomPriority

Starting this process will keep Opentalk running without any significant load.

Regards,

Cham

Mülheims wrote:

Hi,

We are having the same problem, perhaps after updating from 7.4 to 7.5.

Has anybody got any ideas to solve the problem?

Greetings

Klaus Mülheims

Collogia AG

Ubierring 11

50678 Köln

Germany

+49 221 336080

http://www.collogia.de

-----Ursprüngliche Nachricht-----

Von: Martin Kobetic [[hidden email]] 

Gesendet: Montag, 28. Mai 2007 18:25

An: Christian Haider

Cc: VWNC

Betreff: Re: AW: Sockets vs Event Queue on WinXP

Thanks for trying Christian!

The setup is pretty simple. The server must be an XP (possibly SP2 as well, I don't have any other XP setup available). Just start an image, load Opentalk-STST and start a broker:

        broker := (RequestBroker newStstTcpAtPort: 42424) start.

Then on any other machine (I've been using Linux mostly, but I don't think that matters) start a broker as well:

        broker := (RequestBroker newStstTcpAtPort: 0) start.

And run the following script (adjusting the server name to the name of the first host):

        server := broker activeBrokerAtHost: 'servername' port: 42424.

        [ Transcript show: (server echo: '*'). (Delay forMilliseconds: 500) wait ] repeat.

This will print a * for each successful echo. It should get stuck after a short while. Wiggling a mouse over the VW windows on the server should revive it. The key seems to be that the VW windows on the XP server must have focus. Without it it doesn't seem to happen (That's why it took a while to reproduce). Actually you may need to get the mouse off the VW windows as well, I'm not sure (I've been mostly using rdesktop to drive the XP machine, so my mouse is off those windows most of the time).

Cheers,

Martin

Christian Haider wrote:

Sorry, tried to find the reference ... again with no luck (did I dream this?).

But great news that you can reproduce the problem! 

I tried and couldnt reproduce it reliably... Would you mind posting your setup?

Good luck,

  Christian

-----Ursprüngliche Nachricht-----

Von: Martin Kobetic [[hidden email]] 

Gesendet: Montag, 28. Mai 2007 17:31

An: VWNC; Christian Haider

Betreff: Sockets vs Event Queue on WinXP

Hi All,

I have some questions about an issue that Christian Heider 

brought up on this list back in march 

(http://www.parcplace.net/list/vwnc-archive/0703/msg00036.html

). Here's a quick quote:

"We were getting lots of timeouts or server-not-responding 

errors on the clients. First we tried WLAN and switched to 

LAN later. LAN was much better but still quite bad. Then I 

remembered that a long time ago, I read something about 

Windows no reacting to socket events when there are no window 

events on the machine. So, I instructed the groups to always 

shake the mouse when sending requests to the server. At the 

same time I was moving the mouse on the server. This helped! 

(I think)."

We're looking into this problem now (AR#52279: "[STST] 

Opentalk hangs on server side if there is no GUI activity in 

VW." for reference) and we can reproduce it reliably on 

XP/SP2. We can't seem to get it to happen on W2K or W2K3 

server. The key prerequisite seems to be that a VW window 

must have focus, if that's not the case the problem doesn't 

occur (might help as an alternative workaround, instead of 

generating UI events somehow, until we figure this out). The 

impact of network latencies seems to be negligible, we can 

reproduce this on both WLAN and ethernet LANs without much trouble.

Anyway, while we're getting ready to debug this at the VM 

level I tried to search for the reference that Christian 

mentioned above, but had no luck. Christian, or anyone, can 

you still find that information about the socket dependecy on 

the event queue ? Anything on this topic might help us nail this down.

Thanks,

Martin

Diese Nachricht ist vertraulich. Wenn Sie nicht der beabsichtigte Empfänger sind, informieren Sie bitte den Absender. Das unbefugte Kopieren oder Weiterleiten ist nicht gestattet. Wegen der Manipulierbarkeit von E-Mails übernehmen wir keine Haftung für den Inhalt.

PENSIONS-SICHERUNGS-VEREIN Versicherungsverein auf Gegenseitigkeit

Vorsitzender des Aufsichtsrats: Dr. Dieter Hundt

Vorstand: Martin Hoppenrath (Vors.), Dr. Hermann Peter Wohlleben

Registergericht: AG Köln Nr. HRB 6821   Sitz: Köln

 

---

Diese Nachricht ist vertraulich. Wenn Sie nicht der beabsichtigte Empfänger sind, informieren Sie bitte den Absender. Das unbefugte Kopieren oder Weiterleiten ist nicht gestattet. Wegen der Manipulierbarkeit von E-Mails übernehmen wir keine Haftung für den Inhalt.

PENSIONS-SICHERUNGS-VEREIN Versicherungsverein auf Gegenseitigkeit
Vorsitzender des Aufsichtsrats: Dr. Dieter Hundt
Vorstand: Martin Hoppenrath (Vors.), Dr. Hermann Peter Wohlleben
Registergericht: AG Köln Nr. HRB 6821 Sitz: Köln

Steven Kelly wrote:

-- Make sure you assign the background process to a variable, otherwise
you run the risk of it getting garbage collected.

-- The background loop helps a lot, but we still have observed some
cases where even the background loop does *not* fix this problem. We are
not sure, but this seems to be dependent on some unknown specifics of
the hardware configuration (chipset?). If you can tabularize the
hardware differences between the machines that would be interesting.

-- Ping Peter Hatch, he has spent some time on this issue and might have
some more guesstimates on which variables affect the occurrence of this
problem.

-- You 'should' have been using the vw7.5 VM for this release cycle: in
general always use the latest  available VM with the same major version
number (7).



HTH,

Reinout
-------

From: Reinout Heeck [mailto:[hidden email]]
Thanks Reinout and Christian! The advice and feedback is really useful
to me in this situation.

We used to upgrade to the latest VM within a given major version pretty
much as a matter of course. Since 7.1, that advice hasn't been as valid.
There have been differences in behavior with new VMs on old 7.x images,
e.g. double-click stops working. I don't recall seeing big warnings on
these new VMs that the principle of the major version number was being
broken. We now upgrade as a matter of course only within the same major
version, e.g. 7.4, 7.4.1, 7.4d.

We also had a policy of only releasing 7.x.1 versions. At the point
where we could have upgraded to 7.5, we believed there would be a 7.5.1,
so were waiting for that. When we heard there was no 7.5.1 (30.10.2007),
it was already too late for this release to move to 7.5.

Of course, if anyone knows of any serious flaws in 7.4d which are fixed
in 7.5, that would be interesting information (as would any bugs in 7.5
which mean we shouldn't use it). Currently it's hard to tell based on
the 7.5 fixed_ars.txt, which seems to include all changes since the
original 7.4.1 VM. The "socket delay" bug wasn't fixed until after 7.5,
and the socket bugs in the 7.5 fixed_ars.txt are all in 7.4c or 7.4d,
except for the following, which doesn't show up in any of the vw-dev-ann
change lists:

46680 Socket problems on 2.8GHz dual processor Xeons running WinXP

Thanks again,
Steve

Steven,
If memory serves me right there might be potential problem with running
7.4 image on the 7.5 VM.  IT was some discussion a while ago on how UI
events are handled between VM and VI and t some point the changes were
made to VM  of the VW7.5,  so some of the event handling was moved up
from the VM to VI...

Steven Kelly wrote:
This AR is marked closed as of lulu jan07.1, possibly retroactively.

HTH,

Martin

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc