On Wed, Aug 21, 2002 at 07:35:35PM -0400, Peter Chen wrote:
> 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?
You're right that I'm trying to preserve the existing behavior. I
really hate changing the public interface, even in braindead spots.
How about $session->option("auto_shutdown" => 0)? The default value
would be 1, which enables the current behavior.
Along those lines, I'd like to deprecate the current session options
(which are debug, trace, and default), and instead use _debug, _trace,
and _default. This matches the underscores for events supplied by
POE, and it guarantees that new options supplied by POE don't clobber
anything others are using for it.
The usual deprecation schedule would apply.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sf.net
