[vwnc] SocketAccessor>>accept blocks image?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

[vwnc] SocketAccessor>>accept blocks image?

Philippe Demaecker

Hello list,

 

One of our customers is reporting a problem where working with web services/SOAP blocks the image (more particularly when a SOAP proxy is trying to accept connections. This hanging seems to last forever until a ctrl-y is performed. This seems to ‘kick-start’ the image, and the application will run smoothly again for a while.

 

1.       Our setup is as follows…

 

We have our own application acting as a SOAP client which sends SOAP calls to a (non-Smalltalk) web service somewhere on a local network.

 

We make a SOAP call from a class named ABCService, so first we create and start proxy ABCInterfaceSoapProxy  (a WSOpentalkClient subclass). To this proxy we send the message getABCInformation:forDomain: which forwards this message to the web service. A new proxy is created each time we make a soap call.

 

While tracing I noticed that:

. BasicObjectAdapto>>sendRequest: creates a new connection with the server and exchanges information through this connection: ok, works as expected.

. BUT: for some reason, when starting the proxy (WSOpentalkClient>>start), it prepares itself to act as a server and accept incoming connections (ConnectionListener>>doStart) on IP 0.0.0.0:PORT (Why is this necessary?)

 

 

2.       I suspect that the hanging starts once the proxy starts to listen to incoming connects, more specifically, when SocketAccessor>>primAccept encounters a EWOULDBLOCK, which I think, raises a OSErrorHolder notReadySignal.

 

I can reproduce this hanging by having SocketAccessor>>primAccept raise  an OSErrorHolder notReadySignal explicitely:

 

primAccept

 

OSErrorHolder notReadySignal raise.

 

but I could not find a scenario where this EWOULDBLOCK is thrown by the primitive call.

 

You can experience the blocking it yourself starting a WSOpentalkClient client (.st file attached), overwriting primAccept with:

 

primAccept

 

OSErrorHolder notReadySignal raise.

 

and then trying to connecting to the OT client with:

 

ws := WSOpentalkTestClient new start.

 

sktClient1 := SocketAccessor newTCPclientToHost: 'localhost' port: WSOpentalkTestClient port.

sktClient1 close.

ws stop.

 

3.       Below you can find 2 stack traces created by a ctrl-y at a moment the image was blocking.

 

Stack 1: it seems that SocketAccessor>>primAccept runs into an (EWouldBlock) error trying to report it, but blocking the image.

Stack 2: the proxy setting up its listener process

 

So, I have a few questions:

1.       Why is the proxy starting a listener process? I don’t understand we this is necessary when communication between Client and server happens using the sendRequest:? What am I missing?

2.       How can I create a situation where primAccept would return a EWOULDBLOCK error?

3.       Why is raising a EWOULDBLOCK in primAccept blocking the image?

 

My network knowledge is limited, so please be forgiving if I made mistakes in my assumptions above.

 

Thanks in advance for your advice,

Philippe

 

 

 

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

Active Process

Context Stack:

[1]          Dictionary(Set)>>initialIndexFor:boundedBy:

[2]          Dictionary>>findKeyOrNil:

[3]          Dictionary>>at:ifAbsent:

[4]          SocketAccessor class(OSErrorHolder class)>>reportProceedingOn:

[5]          SocketAccessor(OSErrorHolder)>>reportError

[6]          SocketAccessor>>primAccept

[7]          optimized [] in SocketAccessor>>accept

[8]          optimized [] in OSHandle class>>handleValue:

[9]          optimized [] in HandleRegistry>>registerValueOf:

[10]        BlockClosure>>ensure:

[11]        optimized [] in RecursionLock>>critical:

[12]        BlockClosure>>ensure:

[13]        Semaphore>>critical:

[14]        RecursionLock>>critical:

[15]        optimized [] in HandleRegistry>>evaluateWithFullProtection:

[16]        BlockClosure>>on:do:

[17]        HandleRegistry>>evaluateWithFullProtection:

[18]        HandleRegistry>>registerValueOf:

[19]        SocketAccessor class(OSHandle class)>>handleValue:

[20]        SocketAccessor>>accept

[21]        optimized [] in Opentalk.ConnectionListener>>listenerProcessBody

[22]        BlockClosure>>on:do:

[23]        Opentalk.ConnectionListener>>listenerProcessBody

[24]        optimized [] in [] in Opentalk.ConnectionListener>>startListenerProcess

[25]        BlockClosure>>on:do:

[26]        optimized [] in Process class>>forBlock:priority:

 

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

Quiescent Processes

 

Process priority: 30 (id=8615)

Context Stack:

[1]          Process>>resume

[2]          BlockClosure>>forkAt:

[3]          optimized [] in Opentalk.ConnectionListener>>startListenerProcess

[4]          UndefinedObject(MediaGeniX.BLABLABLAClass class)>>ifNotAssigned:

[5]          Opentalk.ConnectionListener>>startListenerProcess

[6]          optimized [] in Opentalk.ConnectionListener>>doStart

[7]          BlockClosure>>ifCurtailed:

[8]          Opentalk.ConnectionListener>>doStart

[9]          Opentalk.ConnectionListener(Opentalk.GenericProtocol)>>start

[10]        Opentalk.AsymmetricConnectionAdaptor(Opentalk.ConnectionAdaptor)>>startServer

[11]        Opentalk.AsymmetricConnectionAdaptor(Opentalk.BasicObjectAdaptor)>>doStart

[12]        Opentalk.AsymmetricConnectionAdaptor(Opentalk.GenericProtocol)>>start

[13]        Opentalk.BasicRequestBroker>>doStart

[14]        Opentalk.BasicRequestBroker(Opentalk.GenericProtocol)>>start

[15]        MediaGeniX.ABCInterfaceSoapProxy(Opentalk.WSOpentalkClient)>>start

[23]        MediaGeniX. ABCService (Smalltalk.UI.Model)>>getABCInformation:forDomain:


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] SocketAccessor>>accept blocks image?

Philippe Demaecker

Oops,I forgot to include the attachment. Here it is.

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Philippe Demaecker
Sent: donderdag 12 november 2009 15:21
To: [hidden email]
Subject: [vwnc] SocketAccessor>>accept blocks image?

 

Hello list,

 

One of our customers is reporting a problem where working with web services/SOAP blocks the image (more particularly when a SOAP proxy is trying to accept connections. This hanging seems to last forever until a ctrl-y is performed. This seems to ‘kick-start’ the image, and the application will run smoothly again for a while.

 

1.       Our setup is as follows…

 

We have our own application acting as a SOAP client which sends SOAP calls to a (non-Smalltalk) web service somewhere on a local network.

 

We make a SOAP call from a class named ABCService, so first we create and start proxy ABCInterfaceSoapProxy  (a WSOpentalkClient subclass). To this proxy we send the message getABCInformation:forDomain: which forwards this message to the web service. A new proxy is created each time we make a soap call.

 

While tracing I noticed that:

. BasicObjectAdapto>>sendRequest: creates a new connection with the server and exchanges information through this connection: ok, works as expected.

. BUT: for some reason, when starting the proxy (WSOpentalkClient>>start), it prepares itself to act as a server and accept incoming connections (ConnectionListener>>doStart) on IP 0.0.0.0:PORT (Why is this necessary?)

 

 

2.       I suspect that the hanging starts once the proxy starts to listen to incoming connects, more specifically, when SocketAccessor>>primAccept encounters a EWOULDBLOCK, which I think, raises a OSErrorHolder notReadySignal.

 

I can reproduce this hanging by having SocketAccessor>>primAccept raise  an OSErrorHolder notReadySignal explicitely:

 

primAccept

 

OSErrorHolder notReadySignal raise.

 

but I could not find a scenario where this EWOULDBLOCK is thrown by the primitive call.

 

You can experience the blocking it yourself starting a WSOpentalkClient client (.st file attached), overwriting primAccept with:

 

primAccept

 

OSErrorHolder notReadySignal raise.

 

and then trying to connecting to the OT client with:

 

ws := WSOpentalkTestClient new start.

 

sktClient1 := SocketAccessor newTCPclientToHost: 'localhost' port: WSOpentalkTestClient port.

sktClient1 close.

ws stop.

 

3.       Below you can find 2 stack traces created by a ctrl-y at a moment the image was blocking.

 

Stack 1: it seems that SocketAccessor>>primAccept runs into an (EWouldBlock) error trying to report it, but blocking the image.

Stack 2: the proxy setting up its listener process

 

So, I have a few questions:

1.       Why is the proxy starting a listener process? I don’t understand we this is necessary when communication between Client and server happens using the sendRequest:? What am I missing?

2.       How can I create a situation where primAccept would return a EWOULDBLOCK error?

3.       Why is raising a EWOULDBLOCK in primAccept blocking the image?

 

My network knowledge is limited, so please be forgiving if I made mistakes in my assumptions above.

 

Thanks in advance for your advice,

Philippe

 

 

 

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

Active Process

Context Stack:

[1]          Dictionary(Set)>>initialIndexFor:boundedBy:

[2]          Dictionary>>findKeyOrNil:

[3]          Dictionary>>at:ifAbsent:

[4]          SocketAccessor class(OSErrorHolder class)>>reportProceedingOn:

[5]          SocketAccessor(OSErrorHolder)>>reportError

[6]          SocketAccessor>>primAccept

[7]          optimized [] in SocketAccessor>>accept

[8]          optimized [] in OSHandle class>>handleValue:

[9]          optimized [] in HandleRegistry>>registerValueOf:

[10]        BlockClosure>>ensure:

[11]        optimized [] in RecursionLock>>critical:

[12]        BlockClosure>>ensure:

[13]        Semaphore>>critical:

[14]        RecursionLock>>critical:

[15]        optimized [] in HandleRegistry>>evaluateWithFullProtection:

[16]        BlockClosure>>on:do:

[17]        HandleRegistry>>evaluateWithFullProtection:

[18]        HandleRegistry>>registerValueOf:

[19]        SocketAccessor class(OSHandle class)>>handleValue:

[20]        SocketAccessor>>accept

[21]        optimized [] in Opentalk.ConnectionListener>>listenerProcessBody

[22]        BlockClosure>>on:do:

[23]        Opentalk.ConnectionListener>>listenerProcessBody

[24]        optimized [] in [] in Opentalk.ConnectionListener>>startListenerProcess

[25]        BlockClosure>>on:do:

[26]        optimized [] in Process class>>forBlock:priority:

 

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

Quiescent Processes

 

Process priority: 30 (id=8615)

Context Stack:

[1]          Process>>resume

[2]          BlockClosure>>forkAt:

[3]          optimized [] in Opentalk.ConnectionListener>>startListenerProcess

[4]          UndefinedObject(MediaGeniX.BLABLABLAClass class)>>ifNotAssigned:

[5]          Opentalk.ConnectionListener>>startListenerProcess

[6]          optimized [] in Opentalk.ConnectionListener>>doStart

[7]          BlockClosure>>ifCurtailed:

[8]          Opentalk.ConnectionListener>>doStart

[9]          Opentalk.ConnectionListener(Opentalk.GenericProtocol)>>start

[10]        Opentalk.AsymmetricConnectionAdaptor(Opentalk.ConnectionAdaptor)>>startServer

[11]        Opentalk.AsymmetricConnectionAdaptor(Opentalk.BasicObjectAdaptor)>>doStart

[12]        Opentalk.AsymmetricConnectionAdaptor(Opentalk.GenericProtocol)>>start

[13]        Opentalk.BasicRequestBroker>>doStart

[14]        Opentalk.BasicRequestBroker(Opentalk.GenericProtocol)>>start

[15]        MediaGeniX.ABCInterfaceSoapProxy(Opentalk.WSOpentalkClient)>>start

[23]        MediaGeniX. ABCService (Smalltalk.UI.Model)>>getABCInformation:forDomain:


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

WSOpentalkTestClient.st (2K) Download Attachment