Hi, Dan,
I may not understand all of the issues here. But I really
don't think we should close all connections when we
detect one ECONNRESET. In my opinion, it is not necessary
to close all connections, since the next ECONNRESET
will close the proper dead socket, anyway. It's not
needed to add all of those complexity.
In the mean time, I have taken Henri's changes and back
port it to 3.2.1 (because I need it on 3.2.1). Everything
seems to work well. I've tested it in the normal scenarios
(one Apache, one Tomcat) and in the load-balanced scenarios.
In the load-balanced scenarios, when I restart TC worker 1,
the code properly close the dead sockets and re-establish
new ones to the same worker (TC worker 1). The good
connections to TC worker 2 are untouched. They stay
connected.
I did notice something wierd. But this is un-related
to the code edits. This happens with or without Henri's
changes. When I restart TC worker 1, but shut down TC
worker 2, requests that supposed to go to TC worker 2
(because they belong to the same session, thus the load
balancer try to foward it to the same TC worker 2) took
sometime to get forwarded to TC worker 1. This maybe
another one of those "improvements" that can be done
to the load balancer worker.
Anyway, I'm pretty happy with Henri's changes. (Thanks
Henri!). Henri, are you going to check in the changes?
Let me know if I can do something else to help for
this case.
shinta
> -----Original Message-----
> From: Dan Milstein [mailto:[EMAIL PROTECTED]]
> Sent: Friday, March 09, 2001 3:08 PM
> To: [EMAIL PROTECTED]
> Subject: Re: FW: problem w/ ajp13 - if Tomcat is shutdown
>
>
> In terms of invalidating the cache:
>
> The jk_ajp13_worker objects hold onto a cache of endpoints --
> ep_cache. It
> would be relatively simple to loop through this cache and
> close all the
> connections in case of ECONNRESET (you do have to call a
> macro to enter a
> critical section -- take a look at reuse_connection()).
>
> However, this cache only holds onto endpoints which are *not*
> being used.
> When an endpoint is checked out of the cache (by
> get_endpoint), or if the
> open socket descriptor is transfered to another endpoint (in
> reuse_connection), that connection is replaced by NULL in the cache.
>
> So if we shut down all the connections in the cache, we won't
> shut down the
> other connections which are handling requests at that moment.
> My only fear
> then is that, when those connections get their own ECONNRESET
> errors, they,
> too, will try to shutdown all the connections in the cache.
> If TC hasn't
> come back up yet, this won't be a problem, because there won't be any
> connections in the cache. But it does make me a bit nervous.
>
> Hope that's helpful...
>
> -Dan
>
>
>
> GOMEZ Henri wrote:
> >
> > La prise de conscience de votre propre ignorance est un
> grand pas vers la
> > connaissance.
> > -- Benjamin Disraeli
> >
> >
> > >-----Original Message-----
> > >From: Dan Milstein [mailto:[EMAIL PROTECTED]]
> > >Sent: Friday, March 09, 2001 6:34 AM
> > >To: [EMAIL PROTECTED]
> > >Subject: Re: FW: problem w/ ajp13 - if Tomcat is shutdown
> > >
> > >
> > >Henri,
> > >
> > >You say that checking errno isn't safe in a multithreaded env
> > >(which would
> > >certainly makes sense to me, since it looks like a global var).
> > >
> > >However, after searching online, and reading up in
> > >"Programming Threads", by
> > >Kleiman, Shah and Smaalders, I find on p. 47:
> > >
> > >"Each thread has its own independent version of the errno
> > >variable. This
> > >allows different threads to make system calls that may change
> > >the value of errno without interfering with each other."
> > >They are describing Posix threads. "errno" is actually a
> > >macro, apparently, which accesses the correct,
> thread-specific errno
> > variable.
> >
> > Right, I checked in Linux errno.h for pthread
> >
> > >Now, I am the first to admit that I don't understand all the weird
> > >intersections between threads and sockets in C, but this looks
> > >to me like checking errno against ECONNRESET may be fine.
> >
> > More generally when you got a read error on TCP/IP stream
> > you could consider that the link to your server (tomcat) is broken :
> >
> > - no more route to tomcat (broken lan or routers)
> > - server not working (tomcat was stopped or server restarted)
> >
> > >Are there platforms where that's not true?
> >
> > I've no idea but we migth have problems in differents interpretation
> > of platform.
> >
> > >The nice thing about getting that ECONNRESET error, is it lets
> > >us go ahead and close out that connection, and try another one.
> >
> > Done.
> >
> > >We could even close out a whole cache of connections,
> > >which would most likely be the right thing to do.
> >
> > Good idea, I'll find how to do that.
> >
> > >If we loop/retry, than how do we know to close the connection?
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, email: [EMAIL PROTECTED]
>
> --
>
> Dan Milstein // [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
