You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jess Holle <je...@ptc.com> on 2008/08/26 01:44:47 UTC
mod_proxy_balancer issue
I want to use mod_proxy_balancer to load balance over a set of ports
that potentially have Tomcats running on them.
Unfortunately there will generally be a good number of ports where no
Tomcat is running. Every 'retry' seconds I have a request that takes
about an extra second for each Tomcat-less port, which is not acceptable.
Has there been any thought or effort to provide an option to retry
dead/unresponsive members in a periodic background thread instead of
with normal, "live" requests? I am currently very interested in adding
such an option if none exists, so I'd appreciate any thoughts on the matter.
I also need to support the mod_jk-based IIS/Tomcat connector in the same
scenario, but have not yet investigated how this will work out.
Thoughts would be appreciated here as well.
If mod_jk would work better than mod_proxy_ajp this presents me with a
couple of issues:
1. The ability that mod_proxy_ajp has to queue/backlog requests when
all workers are busy rather than returning an immediate 503 is
highly desirable here.
2. As an integrated part of Apache, mod_proxy_ajp is in many respects
the future here and I'd rather improve mod_proxy_ajp and/or
mod_proxy_balancer than deal with mod_jk across all the platforms
I have to worry about (various UNIXes and Windows).
Also, yes, I know that I could enable status workers and have each
Tomcat notify Apache that it is alive and present. That's interesting,
but adds end-administrator complexity in that Tomcat must be configured
with an appropriate URL for Apache, access to the status worker must be
protected via further configuration based on the hosts of the target
Tomcats, Tomcat must know if it is being served via mod_proxy_ajp or the
IIS/Tomcat connector, etc. Further if Apache must be taken down it will
lose track of which members are alive. If other approaches truly seem
untenable I can consider this further, but it currently does not seem as
attractive.
Finally, if this should be addressed to the Apache dev list instead,
please let me know. I'm avoiding the temptation to cross-post here :-)
--
Jess Holle
Re: mod_proxy_balancer issue
Posted by Jess Holle <je...@ptc.com>.
Mladen Turk wrote:
> Jess Holle wrote:
>>
>> I'm quite willing to help, but you're clearly much more familiar with
>> both mod_jk and APR/MPM than I am, so I suspect I'd just get in the
>> way except at the testing level.
> Well, I plan to create mpm watchdog hook system first.
> I'll also create a small callback in mod_proxy, just
> to maintain the connection pool so you are free to implement
> any additional mod_proxy interval operations (like heath checking)
> from there.
Ideally I'd like to attempt to re-establish connections to dead servers
occasionally there instead of during normal request time.
Any pointers and foundation code (as described above) would be greatly
appreciated.
Thanks.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: mod_proxy_balancer issue
Posted by Jess Holle <je...@ptc.com>.
Jess Holle wrote:
> Jess Holle wrote:
>> Mladen Turk wrote:
>>> Jess Holle wrote:
>>>> Mladen Turk wrote:
>>>>
>>>> Is there a means of achieving background-only (or nearly so)
>>>> testing of dead workers with mod_jk? That's what I'm looking for
>>>> in both jk and mod_proxy_ajp connectors. I guess I was
>>>> hoping/assuming it was there in mod_jk from reading the docs.
>>> There is in the mod_jk (SVN trunk).
> I've been reading this code now...
>
> The watchdog thread looks very useful. If I understand it correctly,
> the watchdog thread can do whatever it feels like but currently mainly
> calls wc_maintain, which will only do work at most every
> worker.maintain seconds, right?
>
> connection_keepalive does not look like it really my bill, though.
> I'm most worried about workers in an error state and ensuring that
> they are rechecked every recover_wait_time -- but only by the watchdog
> thread and ideally via a ping/pong. Currently recover_workers appears
> to just put workers into a recovery state where they'll be elligible
> to be tried again on a future request -- without checking whether the
> worker is actually accessible. That's fine for some use cases, but
> explicitly what I want to avoid.
>
> Are there any thoughts to have an option to have recover_workers() do
> a ping prior to returning a working to a non-error state?
>
> And, yes, a watchdog thread in mod_proxy_balancer /and /a reasonable
> means of balancer invoking a ping via mod_proxy_ajp would be really
> helpful as far as mod_proxy_ajp is concerned.
P.S. As far as my other questions go, I noticed that you covered the
IIS/isapi base as well. I assume this new option is configured via the
registry then. Are you planning to modify the vbs configuration script
be extended to cover this?
Re: mod_proxy_balancer issue
Posted by Jess Holle <je...@ptc.com>.
Mladen Turk wrote:
> Jess Holle wrote:
>> P.S. I'd also like to quiet attempts to recover workers from errors
>> to a lower (and by default unlogged) logging level. The transition
>> of a worker into an error state should certainly be logged, but
>> logging every time we find it to still be in an error state seems to
>> be excessive -- at least for a sparsely populated port bank use case.
> Everything you said is fine with me. I just did a functional
> logic via watchdog thread and two basic use cases (maintain
> and keepalive). The keepalive is meant to deal with firewalls
> that tends to cut inactive connections.
> As far as I'm concerned feel free to extend the logic so
> it can deal with error states more intelligently.
>
> ... and of course, the plan is to implement something or
> all of this to mod_proxy, but using a different mechanism.
> Many modules needs some sort of out of the request cycle
> detached maintenance, so I'll add a common mpm maintenance
> thread to lower down the resource usage.
Do you have any /rough/ ideas of the timeframe in which you might get
such a thread into mod_proxy?
Obviously I can start on mod_jk first.
--
Jess Holle
Re: mod_proxy_balancer issue
Posted by Jess Holle <je...@ptc.com>.
Jess Holle wrote:
> Agreed, but this is concerning *both* mod_jk and mod_proxy and I've
> been scolded for cross posting...
>
> At the core, I'm looking for 2 things:
>
> 1. Something to limit the maximum impact of having many dead
> workers under a load balancer on normal requests
> * Assuming there are live workers available, of course, i.e.
> the process of discovering that dead workers are still
> dead shouldn't overtly impact any normal request.
> * Sample situation: load balancing over 9 ports, many of
> which do not have an active Tomcat associated at the
> time. If there is only one Tomcat alive every 'retry'
> seconds (in the mod_proxy case, same thing, but different
> parameters for mod_jk), a normal request is delayed by a
> period of 8*dead-connection-latency. That's neither
> necessary nor acceptable.
> * Possible solutions include having a background thread ping
> the health of workers rather than allowing normal requests
> to do so or limiting the number of workers any normal
> request will attempt to recover.
>
Clearly if we take the approach of a backgroung ping solution, it would
be ideal to use cping rather than any sort of real request.
>
> 1. Something to reduce the severity of log messages when
> discovering that a dead worker is still dead.
> * There is no need to fill the error logs with notices that
> a worker that has been dead is still dead. This is good
> troubleshooting info and should be logged, but at a lower
> severity level that does not show up in the logs by default.
> * Depending on the solution to (1), this might just fall out
> of that.
>
> If you believe we should start up a discussion on httpd dev as to how
> to solve these issues at this point that sounds great to me -- though
> we also need to solve them in mod_jk (as our current plan is to use
> mod_proxy_ajp for Apache 2.2 and we have no alternative but the
> jk/isapi connector for IIS).
Also to be clear I need solutions to these problems one way or another,
so if nothing else I'll have to hack in something into our own fork of
the code.
I have a fair amount of time to solve these problems, however, so I'd
much rather see them solved in a good, general way that can be a
value-add part of mod_jk and mod_proxy -- rather than a one-off fork.
--
Jess Holle
Re: *SPAM* Re: mod_proxy_balancer issue
Posted by Mladen Turk <mt...@apache.org>.
Jim Jagielski wrote:
>
>
> As Mladen said, there is some very prelim discussions regarding
> key aspects of these issue on the httpd-dev list. But it is hardly
> unique to mod_proxy (mod_dbd could also use a nice robust watchdog
> hook implementation).
Correct. The bottom line is like you said to move discussion
to correct list. I just noted to Jess how it's done in mod_jk.
mod_proxy would need slightly ;) different approach.
But at least the core (watchdog hook) functionality is
under development, and the final goal is to implement at least
connection pool recycling. Jess is free to propose any
other meaningful addition for a better error detection
and failover as far as I'm concerned (on the correct list)
Regards
--
^(TM)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: *SPAM* Re: mod_proxy_balancer issue
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Aug 28, 2008, at 9:47 AM, Jess Holle wrote:
> Agreed, but this is concerning *both* mod_jk and mod_proxy and I've
> been scolded for cross posting...
>
Well, I would say that both mod_jk and mod_proxy are affected by the
"same phenomenon" but proposed fixes for mod_proxy shouldn't be
discussed on the TC list, and more that proposed fixes for mod_jk
would likely be entertained well on httpd-dev :)
> At the core, I'm looking for 2 things:
>
> If you believe we should start up a discussion on httpd dev as to
> how to solve these issues at this point that sounds great to me --
> though we also need to solve them in mod_jk (as our current plan is
> to use mod_proxy_ajp for Apache 2.2 and we have no alternative but
> the jk/isapi connector for IIS).
As Mladen said, there is some very prelim discussions regarding
key aspects of these issue on the httpd-dev list. But it is hardly
unique to mod_proxy (mod_dbd could also use a nice robust watchdog
hook implementation).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: mod_proxy_balancer issue
Posted by Jess Holle <je...@ptc.com>.
Jim Jagielski wrote:
>
> On Aug 28, 2008, at 12:41 AM, Mladen Turk wrote:
>
>> Jess Holle wrote:
>>> P.S. I'd also like to quiet attempts to recover workers from errors
>>> to a lower (and by default unlogged) logging level. The transition
>>> of a worker into an error state should certainly be logged, but
>>> logging every time we find it to still be in an error state seems to
>>> be excessive -- at least for a sparsely populated port bank use case.
>>
>> Everything you said is fine with me. I just did a functional
>> logic via watchdog thread and two basic use cases (maintain
>> and keepalive). The keepalive is meant to deal with firewalls
>> that tends to cut inactive connections.
>> As far as I'm concerned feel free to extend the logic so
>> it can deal with error states more intelligently.
>>
>> ... and of course, the plan is to implement something or
>> all of this to mod_proxy, but using a different mechanism.
>> Many modules needs some sort of out of the request cycle
>> detached maintenance, so I'll add a common mpm maintenance
>> thread to lower down the resource usage.
> Ummm... since this is regarding mod_proxy, all this should be on
> the httpd-dev list, and not on the Tomcat dev list...
>
> What is, or is not, included in mod_proxy is what the httpd dev
> community decides :) :)
Agreed, but this is concerning *both* mod_jk and mod_proxy and I've been
scolded for cross posting...
At the core, I'm looking for 2 things:
1. Something to limit the maximum impact of having many dead workers
under a load balancer on normal requests
* Assuming there are live workers available, of course, i.e.
the process of discovering that dead workers are still dead
shouldn't overtly impact any normal request.
* Sample situation: load balancing over 9 ports, many of which
do not have an active Tomcat associated at the time. If
there is only one Tomcat alive every 'retry' seconds (in the
mod_proxy case, same thing, but different parameters for
mod_jk), a normal request is delayed by a period of
8*dead-connection-latency. That's neither necessary nor
acceptable.
* Possible solutions include having a background thread ping
the health of workers rather than allowing normal requests
to do so or limiting the number of workers any normal
request will attempt to recover.
2. Something to reduce the severity of log messages when discovering
that a dead worker is still dead.
* There is no need to fill the error logs with notices that a
worker that has been dead is still dead. This is good
troubleshooting info and should be logged, but at a lower
severity level that does not show up in the logs by default.
* Depending on the solution to (1), this might just fall out
of that.
If you believe we should start up a discussion on httpd dev as to how to
solve these issues at this point that sounds great to me -- though we
also need to solve them in mod_jk (as our current plan is to use
mod_proxy_ajp for Apache 2.2 and we have no alternative but the jk/isapi
connector for IIS).
--
Jess Holle
Re: mod_proxy_balancer issue
Posted by Jim Jagielski <ji...@jaguNET.com>.
On Aug 28, 2008, at 12:41 AM, Mladen Turk wrote:
> Jess Holle wrote:
>> P.S. I'd also like to quiet attempts to recover workers from errors
>> to a lower (and by default unlogged) logging level. The transition
>> of a worker into an error state should certainly be logged, but
>> logging every time we find it to still be in an error state seems
>> to be excessive -- at least for a sparsely populated port bank use
>> case.
>
> Everything you said is fine with me. I just did a functional
> logic via watchdog thread and two basic use cases (maintain
> and keepalive). The keepalive is meant to deal with firewalls
> that tends to cut inactive connections.
> As far as I'm concerned feel free to extend the logic so
> it can deal with error states more intelligently.
>
> ... and of course, the plan is to implement something or
> all of this to mod_proxy, but using a different mechanism.
> Many modules needs some sort of out of the request cycle
> detached maintenance, so I'll add a common mpm maintenance
> thread to lower down the resource usage.
>
Ummm... since this is regarding mod_proxy, all this should be on
the httpd-dev list, and not on the Tomcat dev list...
What is, or is not, included in mod_proxy is what the httpd dev
community decides :) :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: mod_proxy_balancer issue
Posted by Mladen Turk <mt...@apache.org>.
Jess Holle wrote:
> P.S. I'd also like to quiet attempts to recover workers from errors to a
> lower (and by default unlogged) logging level. The transition of a
> worker into an error state should certainly be logged, but logging every
> time we find it to still be in an error state seems to be excessive --
> at least for a sparsely populated port bank use case.
>
Everything you said is fine with me. I just did a functional
logic via watchdog thread and two basic use cases (maintain
and keepalive). The keepalive is meant to deal with firewalls
that tends to cut inactive connections.
As far as I'm concerned feel free to extend the logic so
it can deal with error states more intelligently.
... and of course, the plan is to implement something or
all of this to mod_proxy, but using a different mechanism.
Many modules needs some sort of out of the request cycle
detached maintenance, so I'll add a common mpm maintenance
thread to lower down the resource usage.
Regards
--
^(TM)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: mod_proxy_balancer issue
Posted by Jess Holle <je...@ptc.com>.
P.S. I'd also like to quiet attempts to recover workers from errors to a
lower (and by default unlogged) logging level. The transition of a
worker into an error state should certainly be logged, but logging every
time we find it to still be in an error state seems to be excessive --
at least for a sparsely populated port bank use case.
Jess Holle wrote:
> Jess Holle wrote:
>> Jess Holle wrote:
>>> Mladen Turk wrote:
>>>> Jess Holle wrote:
>>>>> Mladen Turk wrote:
>>>>>
>>>>> Is there a means of achieving background-only (or nearly so)
>>>>> testing of dead workers with mod_jk? That's what I'm looking for
>>>>> in both jk and mod_proxy_ajp connectors. I guess I was
>>>>> hoping/assuming it was there in mod_jk from reading the docs.
>>>>>
>>>> There is in the mod_jk (SVN trunk).
>> I've been reading this code now...
>>
>> The watchdog thread looks very useful. If I understand it correctly,
>> the watchdog thread can do whatever it feels like but currently
>> mainly calls wc_maintain, which will only do work at most every
>> worker.maintain seconds, right?
>>
>> connection_keepalive does not look like it really my bill, though.
>> I'm most worried about workers in an error state and ensuring that
>> they are rechecked every recover_wait_time -- but only by the
>> watchdog thread and ideally via a ping/pong. Currently
>> recover_workers appears to just put workers into a recovery state
>> where they'll be elligible to be tried again on a future request --
>> without checking whether the worker is actually accessible. That's
>> fine for some use cases, but explicitly what I want to avoid.
>>
>> Are there any thoughts to have an option to have recover_workers() do
>> a ping prior to returning a working to a non-error state?
>>
>> And, yes, a watchdog thread in mod_proxy_balancer /and /a reasonable
>> means of balancer invoking a ping via mod_proxy_ajp would be really
>> helpful as far as mod_proxy_ajp is concerned.
> Another possibly simpler alternative: we could introduce a limit as to
> how many workers we attempt to do (unforced) recoveries on for any
> given request. Any request could likely tolerate a recovery attempt
> or two. None should have to tolerate 6-12 recovery attempts just
> because of a currently sparsely populated port range.
>
> Thoughts?
>
> --
> Jess Holle
Re: mod_proxy_balancer issue
Posted by Jess Holle <je...@ptc.com>.
Jess Holle wrote:
> Jess Holle wrote:
>> Mladen Turk wrote:
>>> Jess Holle wrote:
>>>> Mladen Turk wrote:
>>>>
>>>> Is there a means of achieving background-only (or nearly so)
>>>> testing of dead workers with mod_jk? That's what I'm looking for
>>>> in both jk and mod_proxy_ajp connectors. I guess I was
>>>> hoping/assuming it was there in mod_jk from reading the docs.
>>>>
>>> There is in the mod_jk (SVN trunk).
> I've been reading this code now...
>
> The watchdog thread looks very useful. If I understand it correctly,
> the watchdog thread can do whatever it feels like but currently mainly
> calls wc_maintain, which will only do work at most every
> worker.maintain seconds, right?
>
> connection_keepalive does not look like it really my bill, though.
> I'm most worried about workers in an error state and ensuring that
> they are rechecked every recover_wait_time -- but only by the watchdog
> thread and ideally via a ping/pong. Currently recover_workers appears
> to just put workers into a recovery state where they'll be elligible
> to be tried again on a future request -- without checking whether the
> worker is actually accessible. That's fine for some use cases, but
> explicitly what I want to avoid.
>
> Are there any thoughts to have an option to have recover_workers() do
> a ping prior to returning a working to a non-error state?
>
> And, yes, a watchdog thread in mod_proxy_balancer /and /a reasonable
> means of balancer invoking a ping via mod_proxy_ajp would be really
> helpful as far as mod_proxy_ajp is concerned.
Another possibly simpler alternative: we could introduce a limit as to
how many workers we attempt to do (unforced) recoveries on for any given
request. Any request could likely tolerate a recovery attempt or two.
None should have to tolerate 6-12 recovery attempts just because of a
currently sparsely populated port range.
Thoughts?
--
Jess Holle
Re: mod_proxy_balancer issue
Posted by Jess Holle <je...@ptc.com>.
Jess Holle wrote:
> Mladen Turk wrote:
>> Jess Holle wrote:
>>> Mladen Turk wrote:
>>>
>>> Is there a means of achieving background-only (or nearly so) testing
>>> of dead workers with mod_jk? That's what I'm looking for in both jk
>>> and mod_proxy_ajp connectors. I guess I was hoping/assuming it was
>>> there in mod_jk from reading the docs.
>>>
>> There is in the mod_jk (SVN trunk).
I've been reading this code now...
The watchdog thread looks very useful. If I understand it correctly,
the watchdog thread can do whatever it feels like but currently mainly
calls wc_maintain, which will only do work at most every worker.maintain
seconds, right?
connection_keepalive does not look like it really my bill, though. I'm
most worried about workers in an error state and ensuring that they are
rechecked every recover_wait_time -- but only by the watchdog thread and
ideally via a ping/pong. Currently recover_workers appears to just put
workers into a recovery state where they'll be elligible to be tried
again on a future request -- without checking whether the worker is
actually accessible. That's fine for some use cases, but explicitly
what I want to avoid.
Are there any thoughts to have an option to have recover_workers() do a
ping prior to returning a working to a non-error state?
And, yes, a watchdog thread in mod_proxy_balancer /and /a reasonable
means of balancer invoking a ping via mod_proxy_ajp would be really
helpful as far as mod_proxy_ajp is concerned.
--
Jess Holle
Re: mod_proxy_balancer issue
Posted by Jess Holle <je...@ptc.com>.
Jess Holle wrote:
>> Add JkWatchdogInterval 60
Also how/where would one specify this for the IIS/Tomcat connector?
[I need such a capability for IIS and Apache 2.2, specifically.]
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: mod_proxy_balancer issue
Posted by Jess Holle <je...@ptc.com>.
Mladen Turk wrote:
> Jess Holle wrote:
>> Mladen Turk wrote:
>>
>> Is there a means of achieving background-only (or nearly so) testing
>> of dead workers with mod_jk? That's what I'm looking for in both jk
>> and mod_proxy_ajp connectors. I guess I was hoping/assuming it was
>> there in mod_jk from reading the docs.
>>
> There is in the mod_jk (SVN trunk).
Ah... I'd been looking in 1.2.26.
> Add JkWatchdogInterval 60
> This will create thread calling maintain each 60 seconds.
How does this differ from worker.maintain?
> If you add
> worker.xxx.connection_keepalive=60
> it will fire a cping/cpong on all connections
> in connection pool that were not used more then 60 seconds
What about for load balance members with no established connections? My
primary case here is a fairly large bank of ports which will be sparsely
populated with Tomcats. I do not want normal request threads to spend
time seeing if the ports have "come to life", but I want a background
thread to do so periodically.
I'm thinking I'd want most of the workers being load balanced over to
start in a presumed dead state until the background thread discovered
they were alive.
Does this sound close?
I will take a look at the SVN code. I take it there's no such code in
Apache SVN yet for mod_proxy_ajp? [I did look there.]
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: mod_proxy_balancer issue
Posted by Mladen Turk <mt...@apache.org>.
Jess Holle wrote:
> Mladen Turk wrote:
>
> Is there a means of achieving background-only (or nearly so) testing of
> dead workers with mod_jk? That's what I'm looking for in both jk and
> mod_proxy_ajp connectors. I guess I was hoping/assuming it was there in
> mod_jk from reading the docs.
>
There is in the mod_jk (SVN trunk).
Add JkWatchdogInterval 60
This will create thread calling maintain each 60 seconds.
If you add
worker.xxx.connection_keepalive=60
it will fire a cping/cpong on all connections
in connection pool that were not used more then 60 seconds
Regards
--
^(TM)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: mod_proxy_balancer issue
Posted by Jess Holle <je...@ptc.com>.
Mladen Turk wrote:
> Jess Holle wrote:
>>
>> I'm quite willing to help, but you're clearly much more familiar with
>> both mod_jk and APR/MPM than I am, so I suspect I'd just get in the
>> way except at the testing level.
> Well, I plan to create mpm watchdog hook system first.
> I'll also create a small callback in mod_proxy, just
> to maintain the connection pool so you are free to implement
> any additional mod_proxy interval operations (like heath checking)
> from there.
Is there already something along these lines in mod_jk (or more
specifically the IIS connector)?
I did a little simplistic testing and haven't gotten down and dirty to
debug this, but I have no managed to figure out any configuration of
mod_jk where the load balancers' "dead" workers will be tested in the
background and avoid testing this with foreground requests. I have a
simple "ping" request that takes many seconds all too often, presumably
delayed by re-checking all the dead workers.
I have a worker.maintain of 15 and a recover_time for my balanced worker
of 30 -- under the theory that background maintenance should be able to
test any "dead" connections and mark them as recently tested without any
request threads ever checking the workers. This assumes that the
recover_time is only observed by request threads, though.
Is there a means of achieving background-only (or nearly so) testing of
dead workers with mod_jk? That's what I'm looking for in both jk and
mod_proxy_ajp connectors. I guess I was hoping/assuming it was there in
mod_jk from reading the docs.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: mod_proxy_balancer issue
Posted by Mladen Turk <mt...@apache.org>.
Jess Holle wrote:
>
> I'm quite willing to help, but you're clearly much more familiar with
> both mod_jk and APR/MPM than I am, so I suspect I'd just get in the way
> except at the testing level.
>
Well, I plan to create mpm watchdog hook system first.
I'll also create a small callback in mod_proxy, just
to maintain the connection pool so you are free to implement
any additional mod_proxy interval operations (like heath checking)
from there.
Cheers
--
^(TM)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: mod_proxy_balancer issue
Posted by Jess Holle <je...@ptc.com>.
Mladen Turk wrote:
> Jess Holle wrote:
>> I want to use mod_proxy_balancer to load balance over a set of ports
>> that potentially have Tomcats running on them.
>>
>> Unfortunately there will generally be a good number of ports where no
>> Tomcat is running. Every 'retry' seconds I have a request that takes
>> about an extra second for each Tomcat-less port, which is not
>> acceptable.
>>
>> Has there been any thought or effort to provide an option to retry
>> dead/unresponsive members in a periodic background thread instead of
>> with normal, "live" requests? I am currently very interested in
>> adding such an option if none exists, so I'd appreciate any thoughts
>> on the matter.
> See the August thread on httpd-dev
> (Mpm maintenance thread hook) where I proposed
> exactly that. Among other things it will be
> potentially used with mod_proxy for out-of-the-request
> maintenance (Status checks, connection recycle, etc)
>
> No major objections, so I'm actively working on that.
> Also mod_jk in trunk has the watchdog thread
> (Apache 2+ only via JkWatchdogInterval) that allows
> to maintain the connection pool, and together with
> worker.xxx.connection_keepalive it can send CPING/CPONG
> packets on regular intervals thus checking the connection
> validity unbound from request frequency.
> My plan is to add this logic to mod_proxy, but using
> mpm hooks.
I am quite interested in any progress you make here. Do you have any
idea when you might have something testable in the mod_proxy area?
I'm quite willing to help, but you're clearly much more familiar with
both mod_jk and APR/MPM than I am, so I suspect I'd just get in the way
except at the testing level.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: mod_proxy_balancer issue
Posted by Mladen Turk <mt...@apache.org>.
Jess Holle wrote:
> I want to use mod_proxy_balancer to load balance over a set of ports
> that potentially have Tomcats running on them.
>
> Unfortunately there will generally be a good number of ports where no
> Tomcat is running. Every 'retry' seconds I have a request that takes
> about an extra second for each Tomcat-less port, which is not acceptable.
>
> Has there been any thought or effort to provide an option to retry
> dead/unresponsive members in a periodic background thread instead of
> with normal, "live" requests? I am currently very interested in adding
> such an option if none exists, so I'd appreciate any thoughts on the
> matter.
>
See the August thread on httpd-dev
(Mpm maintenance thread hook) where I proposed
exactly that. Among other things it will be
potentially used with mod_proxy for out-of-the-request
maintenance (Status checks, connection recycle, etc)
No major objections, so I'm actively working on that.
Also mod_jk in trunk has the watchdog thread
(Apache 2+ only via JkWatchdogInterval) that allows
to maintain the connection pool, and together with
worker.xxx.connection_keepalive it can send CPING/CPONG
packets on regular intervals thus checking the connection
validity unbound from request frequency.
My plan is to add this logic to mod_proxy, but using
mpm hooks.
Regards
--
^(TM)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org