Re: PoCo-SOAP and PoCo-Server-TCP buffer flushing
On Tue, 2002-08-20 at 16:34, Rocco Caputo wrote: On Mon, Jul 15, 2002 at 04:27:26PM -0400, Peter Chen wrote: Thank you for confirming this, and fixing it. Please let me know when you have a release, and I will roll out another RPM. I seem to have fixed it, but I don't remember when. The fix isn't the same as your code, but it seems equivalent. Could you test it to make sure that it fixes your SOAP server and doesn't break anything else? Will do. Is there going to be another release? I probably ought to make another rpm with the fix. Mandrake has accepted quite a few of the POE related rpm's that I contributed. So far there are perl-POE, perl-POE-Component-Logger, perl-Log-Dispatch, perl-Log-Dispatch-Config, etc. Pete
Re: PoCo-SOAP and PoCo-Server-TCP buffer flushing
On Wed, Aug 21, 2002 at 01:52:59PM -0400, Peter Chen wrote: On Tue, 2002-08-20 at 16:34, Rocco Caputo wrote: On Mon, Jul 15, 2002 at 04:27:26PM -0400, Peter Chen wrote: Thank you for confirming this, and fixing it. Please let me know when you have a release, and I will roll out another RPM. I seem to have fixed it, but I don't remember when. The fix isn't the same as your code, but it seems equivalent. Could you test it to make sure that it fixes your SOAP server and doesn't break anything else? Will do. Is there going to be another release? I probably ought to make another rpm with the fix. Mandrake has accepted quite a few of the POE related rpm's that I contributed. So far there are perl-POE, perl-POE-Component-Logger, perl-Log-Dispatch, perl-Log-Dispatch-Config, etc. Thanks. Not quite yet. I'd like to at least nail down Cristiano's latest Cygwin problem. Has anyone else noticed socket weirdness on Cygwin? Specifically, a socket's not being closed until a session completely goes away. We were able to track it down through POE::Kernel to where the sockets are destroyed. We even close()'d the sockets manually, but the client connection still does not break. -- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sf.net
Re: PoCo-SOAP and PoCo-Server-TCP buffer flushing
On Wed, 2002-08-21 at 13:52, Peter Chen wrote: On Tue, 2002-08-20 at 16:34, Rocco Caputo wrote: I seem to have fixed it, but I don't remember when. The fix isn't the same as your code, but it seems equivalent. Could you test it to make sure that it fixes your SOAP server and doesn't break anything else? Will do. I just tested this with some of the simplest cases. After 6 clients connecting to the PoCo::SOAP server concurrently making a total of 2000 requests, every thing seems to work. The next step is to test this in a bigger application. I do have a question regarding the change in PoCo::Server::TCP (revision 1.24 from CVS server) though. It appears that if it gets a read error 0 (the client stops writing to the socket), it will shut down the handler session. I am not sure whether this is the desired behavior. I can imagine situations where the user may want to have more control over when the handler session is shutdown. For example, what happens when a read error 0 is received by the server before the server completes handling the request? In several instances, upon ClientInput, I use POE::Wheel::Run to handle some long running commands. If the server shuts down the handler session upon a read error 0, it will never have a chance to send back a response. If this a behavior that we wish to preserve for backward compatibility, perhaps it can be achieved by adding an additional option to indicate whether the handler session should automatically shutdown upon a read error? Pete
Re: PoCo-SOAP and PoCo-Server-TCP buffer flushing
On Fri, Jul 12, 2002 at 12:10:23PM -0400, Peter Chen wrote:
On Thu, 2002-07-11 at 20:18, Peter Chen wrote:
With Fletch's blessing, I have adapted POE-Component-SOAP to use
POE-Component-Server-TCP. However, I am seeing some strange socket
behavior that causes the SOAP server to fail sporadically, which I
believe is related to output buffer flushing.
After more debugging, I found out what the problem was. The key is the
interpretation of a read error 0 on a socket. Here is the original code
in PoCo-Server-TCP 1.22, dated 6/18/2002:
[code that deletes the wheel on error 0]
Note that a read error 0 on the socket is interpreted as a disconnect,
and POE::Wheel::ReadWrite stored in $heap-{client} is deleted
afterward. Consequently if the output buffer is not empty at the time,
the buffer content may never get flushed.
Changing the code for tcp_server_got_error callback, and
_default_client_error to the following seems to fix this.
[code that does a shutdown on error 0]
So the question is how does one interpret a read error 0 on a socket?
Read error 0 signals an EOF on a socket. It means the socket will not
provide more data to be read. I have been interpreting that as a
disconnect, but it's clear I've been wrong to do it.
Read error 0 can be triggered without a disconnect when the remote end
calls shutdown(SOCK,1) (see perldoc -f shutdown). That signals no
more data to be read, but it does not (and should not) imply that the
caller is done receiving.
From the behavior I observe, where a read error 0 could occur while the
client is still waiting for a response from the server, it seems to
indicate it's possible for the server to get a read error 0, which is
usually interpreted as the file handle being closed, and still be able
to write. So it seems to be premature to delete the wheel upon such an
error.
You are correct. I will apply your fix to the TCP client and server
components. I also need to stop recommending that wheels be deleted
on read error 0.
Attached is a program I wrote to test shutdown() behavior on sockets.
Another idiosyncrasy I noticed is that the Acceptor parameter seems to
be a noop, and replaced by ClientConnected? Is this correct, Rocco?
When Acceptor is supplied, all the /Client.*/ callbacks are disabled.
It becomes the programmer's responsibility to define every detail of
how a client connection is handled. This was the old Server::TCP
behavior, and Acceptor was left in the component to ensure backward
compatibility.
You've noticed that it's broken, though. I'm surprised nobody noticed
it; maybe it doesn't need to be backward compatible after all?
Anyway, it will be fixed in CVS this weekend.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sf.net
