On 06.03.2009 13:32, Mladen Turk wrote:
Huge one Rainer ;)
I know, but I went through it in depth.
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
But isn't the whole purpose of your changes to give the backend still a
chance, if it is processing requests? Why does it then matter, whether
those requests come from the same lb??
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
JK_CLIENT_ERROR: it does not touch the global state (well it sets it to
OK), but you do touch the local state. I argued, why I would set the
local state also to OK. Any answer?
JK_STATUS_FATAL_ERROR: The whole purpose of the fail_on_status
configuration item is to tell something else. E.g. there is a status if
the context is not available, or the app could have a filter returning a
special status. For me it does not make sense to simply ignore, what the
admin configured using fail_on_status.
JK_REPLY_TIMEOUT: Again I'm talking about the situation we have more
timeouts than max_reply_timeouts. By default we do not have any reply
timeout set, so the admin instructed us to react on reply timeouts.
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.
I didn't suggest setting global to ERROR, I suggested setting local to
OK, because I don't get, hwat local ERROR helps here, and keeping both
equal is easier to understand.
For the rest it's simply too much to cope in a single email ;)
Right!
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
