Huge one Rainer ;)
Rainer Jung wrote:
We have three busy counters:
a) one for the lb in total
b) one for each lb sub
c) one for each ajp worker
In status worker we use only a) and c). In lb we use a) and b). Your
comment to BZ 46808 seems to indicate, that using c) instead ob b) in lb
would be better. We could then again remove b).
Right?
So we could drop the rec->s->busy++ and --, because that's done for the
ajp busyness alredy in jk_ajp_common.c and we would test against
aw->s->busy instead of rec->s->busy.
OK?
No because rec->s->busy is per-lb info,
and aw->s-busy >= res->s->busy if aw is member
of multiple lb's
2) Local states vs. global states
=================================
I went through all places were we use and set states in lb. I have some
comments:
a) Setting local states and global states to different values
-------------------------------------------------------------
First the easier cases (I think)
(i) JK_CLIENT_ERROR
(ii) JK_STATUS_FATAL_ERROR
(iii) JK_REPLY_TIMEOUT
All this should never touch the global state
if there are live connections.
Let the live connection decides for itself when it gets serviced.
Anything else is just plain 'guessing'
That was my general rule of thumb,
because the point is to be robust as much as possible
Now the more difficult cases:
(iv) JK_SERVER_ERROR
We only get this, if a memory allocation fails.
I'm fine with what you decided, although actually I see no reason why
allocation should work better or worse for one of the lb members.
We can leave it, to keep track of the differences it would be easier to
set local state to OK too.
Well, again I disagree. Actually in worker or prefork the child
will simply die without setting the global error in shm.
If we set here the global error it will again kill all the
sessions if one child had some memory issues.
For the rest it's simply too much to cope in a single email ;)
Cheers
--
^(TM)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
