AW: AW: Sockets vs Event Queue on WinXP

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 [mailto:[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:


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

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
  


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
  

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

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