Rainer Jung wrote:
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?
Well you said:
"It doesn't matter for the logic, but makes keeping track of the
differences easier."
I think opposite. Marking local as error and global as ok makes
things track easier. local error means that this worker won't
be tested in next lb loop, global error means it won't be tested
until retry timeout. Explicitly setting global to OK reads as
'It wasn't our fault, it was client's fault, we are still in
contact with backend'
But I agree, setting anything here is irrelevant, but like
you said "It makes things easier to track and read"
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.
OK, this should probably be set to global as well if configured
explicitly. It will mean that all the sessions will be lost however.
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.
JkMount /foo aw
JkMount /bar aw
Now, if /bar is slow and gets timeout it would mean that
/foo will be banned as well (although it might work perfectly)
But I see your point. Since configured it should be banned
immediately. However this requires that admins behave 'smart'
and deploy their applications to different instances and use
different workers.
Ideal would be for us to have per JkMount status in shared
memory. This is something for the future definitely.
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.
Hmm, right, but setting local to OK won't probably help.
It might end up in some garbage send to Tomcat, so it's
better to mark it as local error.
Regards
--
^(TM)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
