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]
