You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Henri Gomez <he...@gmail.com> on 2010/02/12 16:20:14 UTC
jk/cluster - intelligent systems load
Hi to all,
Some times ago, we discuss about mod_jk/cluster and more intelligent
strategy to be use for the dispatching system.
One point was to get system load informations about the various Tomcat
instances involved in a cluster, to send request to the lowest loaded
Tomcat.
Hyperic Sigar, http://www.hyperic.com/products/sigar.html, seems to
provide such informations for various OS.
Could it be interesting to add such 'extension' to Tomcat, so it could
be able to send back to jk/cluster so they could get the best
decisions ?
New commands could be added to AJP13, as done previously with
cping/cpong, http://tomcat.apache.org/connectors-doc/ajp/ajpv13ext.html.
What do you think about ?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: jk/cluster - intelligent systems load
Posted by Henri Gomez <he...@gmail.com>.
> Tomcat Native already has some capabilities that
> can provide system not JVM options like CPU and Memory
> load on the box itself. For loadbalancing stuff
> this is all that is needed thought.
> Some of those are even displayed on status page
> when it's loaded in inside the Tomcat.
Well it's a good candidate :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: jk/cluster - intelligent systems load
Posted by Henri Gomez <he...@gmail.com>.
> My preference would be to use the servlet - maybe enhance the
> JMXProxyServlet, which dumps all
> JMX information. The current format is relatively easy to parse - but can be
> made simpler, and you
> could add some parameter to select a subset of the mbeans.
JMXProxyServlet, I'll look at it.
> On Linux you can also grab a lot of stuff from /proc, and wrap it in a mbean
> or the servlet.
Linux yes, but there is many others OS to support :(
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: jk/cluster - intelligent systems load
Posted by Costin Manolache <co...@gmail.com>.
On Fri, Feb 19, 2010 at 8:51 AM, jean-frederic clere <jf...@gmail.com>wrote:
> On 02/19/2010 05:19 PM, Mladen Turk wrote:
> > On 02/19/2010 05:06 PM, Henri Gomez wrote:
> >>> Not a mod_proxy guru, but filtering X-header from responses should be
> >>> near
> >>> trivial based on past experience with the proxy code.
> >>
> >>
> >> There is the GPL licence 'problem' of the Hyperic lib which should be
> >> 'solved' isn't ?
> >>
> >
> > Tomcat Native already has some capabilities that
> > can provide system not JVM options like CPU and Memory
> > load on the box itself. For loadbalancing stuff
> > this is all that is needed thought.
> > Some of those are even displayed on status page
> > when it's loaded in inside the Tomcat.
>
> Additionally JAVA6 provide stats information on the JVM.
>
>
My preference would be to use the servlet - maybe enhance the
JMXProxyServlet, which dumps all
JMX information. The current format is relatively easy to parse - but can be
made simpler, and you
could add some parameter to select a subset of the mbeans.
On Linux you can also grab a lot of stuff from /proc, and wrap it in a mbean
or the servlet.
Costin
Re: jk/cluster - intelligent systems load
Posted by Henri Gomez <he...@gmail.com>.
>> Tomcat Native already has some capabilities that
>> can provide system not JVM options like CPU and Memory
>> load on the box itself. For loadbalancing stuff
>> this is all that is needed thought.
>> Some of those are even displayed on status page
>> when it's loaded in inside the Tomcat.
>
> Additionally JAVA6 provide stats information on the JVM.
It should but the IBM Java 6 didn't report it correctly for example ;(
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: jk/cluster - intelligent systems load
Posted by jean-frederic clere <jf...@gmail.com>.
On 02/19/2010 05:19 PM, Mladen Turk wrote:
> On 02/19/2010 05:06 PM, Henri Gomez wrote:
>>> Not a mod_proxy guru, but filtering X-header from responses should be
>>> near
>>> trivial based on past experience with the proxy code.
>>
>>
>> There is the GPL licence 'problem' of the Hyperic lib which should be
>> 'solved' isn't ?
>>
>
> Tomcat Native already has some capabilities that
> can provide system not JVM options like CPU and Memory
> load on the box itself. For loadbalancing stuff
> this is all that is needed thought.
> Some of those are even displayed on status page
> when it's loaded in inside the Tomcat.
Additionally JAVA6 provide stats information on the JVM.
Cheers
Jean-Frederic
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: jk/cluster - intelligent systems load
Posted by Mladen Turk <mt...@apache.org>.
On 02/19/2010 05:06 PM, Henri Gomez wrote:
>> Not a mod_proxy guru, but filtering X-header from responses should be near
>> trivial based on past experience with the proxy code.
>
>
> There is the GPL licence 'problem' of the Hyperic lib which should be
> 'solved' isn't ?
>
Tomcat Native already has some capabilities that
can provide system not JVM options like CPU and Memory
load on the box itself. For loadbalancing stuff
this is all that is needed thought.
Some of those are even displayed on status page
when it's loaded in inside the Tomcat.
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: jk/cluster - intelligent systems load
Posted by Henri Gomez <he...@gmail.com>.
> Not a mod_proxy guru, but filtering X-header from responses should be near
> trivial based on past experience with the proxy code.
> Nice discussion btw. This is a topic I've long been interested in.
You're not alone ;)
Two options (not incompatible) to provide servlet engine information
to back end (cluster system).
- a filter add this information in a X-header, each Y requests, or Z seconds.
- a servlet called explicitly by the back-end.
There is the GPL licence 'problem' of the Hyperic lib which should be
'solved' isn't ?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: jk/cluster - intelligent systems load
Posted by Bill Stoddard <wg...@gmail.com>.
On 2/19/10 8:24 AM, Henri Gomez wrote:
>>> If we goes back to the original thread and using Hyperic stuff in a
>>> servlet filter or whatever Tomcat extension ?
>>>
>>>
>>>
>> Absolutely - a filter would be perfect and will work with any servlet
>> engine.
>>
> Jetty users will thanks Tomcat community :)
>
>
>> There are some problems with making sure this doesn't leak out - i.e.
>> an X-header inserted by mod_proxy and make sure it filters X-headers
>> from the response.
>>
> mod_proxy guru around ?
>
>
Not a mod_proxy guru, but filtering X-header from responses should be
near trivial based on past experience with the proxy code.
Nice discussion btw. This is a topic I've long been interested in.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: jk/cluster - intelligent systems load
Posted by Henri Gomez <he...@gmail.com>.
>> If we goes back to the original thread and using Hyperic stuff in a
>> servlet filter or whatever Tomcat extension ?
>>
>>
> Absolutely - a filter would be perfect and will work with any servlet
> engine.
Jetty users will thanks Tomcat community :)
> There are some problems with making sure this doesn't leak out - i.e.
> an X-header inserted by mod_proxy and make sure it filters X-headers
> from the response.
mod_proxy guru around ?
>> Could it be usefull for jk, mod_proxy, mod_cluster ?
>>
>> Or a specific servlet should/could be provided for such collect
>> purpose and it Will be called by remote at it's own rate ?
>>
>
> That would work too, even better - a status servlet, which may provide
> additional data, like number of sessions, java memory, etc. Don't we have
> one already - dumping all jmx data ? Probably need to output data
> in an easier to parse format, and I guess mod_proxy configuration would
> be a bit tricky if you want to use multiple variables, but doable.
a status servlet could be better, since it could also report
informations about Tomcat engine, like number of ajp/http threads.
A basic format for simple decoding of course :)
BTW, since there is VMWare/SpringSourcer around, could the Hyperic
stuff turned into ASL or BSD licence ?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: jk/cluster - intelligent systems load
Posted by Costin Manolache <co...@gmail.com>.
On Thu, Feb 18, 2010 at 10:57 AM, Henri Gomez <he...@gmail.com> wrote:
> If we goes back to the original thread and using Hyperic stuff in a
> servlet filter or whatever Tomcat extension ?
>
>
Absolutely - a filter would be perfect and will work with any servlet
engine.
There are some problems with making sure this doesn't leak out - i.e.
an X-header inserted by mod_proxy and make sure it filters X-headers
from the response.
> Could it be usefull for jk, mod_proxy, mod_cluster ?
>
> Or a specific servlet should/could be provided for such collect
> purpose and it Will be called by remote at it's own rate ?
>
That would work too, even better - a status servlet, which may provide
additional data, like number of sessions, java memory, etc. Don't we have
one already - dumping all jmx data ? Probably need to output data
in an easier to parse format, and I guess mod_proxy configuration would
be a bit tricky if you want to use multiple variables, but doable.
Costin
>
> 2010/2/18, Costin Manolache <co...@gmail.com>:
> > On Thu, Feb 18, 2010 at 12:00 AM, jean-frederic clere
> > <jf...@gmail.com>wrote:
> >
> >> On 02/17/2010 10:46 PM, Costin Manolache wrote:
> >> > On Wed, Feb 17, 2010 at 11:58 AM, Mladen Turk <mt...@apache.org>
> wrote:
> >> >
> >> >> On 02/17/2010 07:37 PM, Costin Manolache wrote:
> >> >>
> >> >>> On Wed, Feb 17, 2010 at 12:38 AM, Mladen Turk<mt...@apache.org>
> >> wrote:
> >> >>>
> >> >>>
> >> >>> The reasons I suggest using SPDY as a replacement for AJP - and
> >> supporting
> >> >>> SPDY
> >> >>>
> >> >>
> >> >> I have nothing against SPDY and it really looks cool,
> >> >> but IMHO it's doesn't look and feel like the rest of RFC
> >> >> protocol specifications.
> >> >> If you can push those guys to create a well known RFC-like
> >> >> doc, I'm sure that overall internet community will benefit
> >> >> from it.
> >> >>
> >> >
> >> > SPDY is still in development - there is an open mailing list and
> >> > quite a few proposals/changes/discussions. I would guess
> >> > the end result will end up as a RFC-like. Feel free to join the
> >> > mailing list and push or volunteer for anything :-)
> >> >
> >> > The implementations - chrome, mod_spdy are also open source
> >> > and with ASF-like license.
> >> >
> >> >
> >> >
> >> >>
> >> >> OTOH we are discussing this 'protocol thing' for years instead like
> >> >> you noticed we concentrate on the tasks we wish to do.
> >> >> Think if we start from the protocol side we will stay there (nowhere)
> >> >> for few more years (although SPDY might be even more then we need).
> >> >
> >> >
> >> > I think what matters is having a working SPDY implementation in
> tomcat,
> >> > inter-operable
> >> > with chrome/mod_spdy/google. If we start with this we'll probably make
> >> > more progress than by discussing protocols :-)
> >>
> >> Yep, I have noted that people are preparing an implementation for httpd
> >> so at some point it will just "porting" that code to TC.
> >>
> >>
> > http://code.google.com/p/mod-spdy/
> >
> > Costin
> >
> >
> >
> >> Cheers
> >>
> >> Jean-Frederic
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: jk/cluster - intelligent systems load
Posted by Henri Gomez <he...@gmail.com>.
If we goes back to the original thread and using Hyperic stuff in a
servlet filter or whatever Tomcat extension ?
Could it be usefull for jk, mod_proxy, mod_cluster ?
Or a specific servlet should/could be provided for such collect
purpose and it Will be called by remote at it's own rate ?
2010/2/18, Costin Manolache <co...@gmail.com>:
> On Thu, Feb 18, 2010 at 12:00 AM, jean-frederic clere
> <jf...@gmail.com>wrote:
>
>> On 02/17/2010 10:46 PM, Costin Manolache wrote:
>> > On Wed, Feb 17, 2010 at 11:58 AM, Mladen Turk <mt...@apache.org> wrote:
>> >
>> >> On 02/17/2010 07:37 PM, Costin Manolache wrote:
>> >>
>> >>> On Wed, Feb 17, 2010 at 12:38 AM, Mladen Turk<mt...@apache.org>
>> wrote:
>> >>>
>> >>>
>> >>> The reasons I suggest using SPDY as a replacement for AJP - and
>> supporting
>> >>> SPDY
>> >>>
>> >>
>> >> I have nothing against SPDY and it really looks cool,
>> >> but IMHO it's doesn't look and feel like the rest of RFC
>> >> protocol specifications.
>> >> If you can push those guys to create a well known RFC-like
>> >> doc, I'm sure that overall internet community will benefit
>> >> from it.
>> >>
>> >
>> > SPDY is still in development - there is an open mailing list and
>> > quite a few proposals/changes/discussions. I would guess
>> > the end result will end up as a RFC-like. Feel free to join the
>> > mailing list and push or volunteer for anything :-)
>> >
>> > The implementations - chrome, mod_spdy are also open source
>> > and with ASF-like license.
>> >
>> >
>> >
>> >>
>> >> OTOH we are discussing this 'protocol thing' for years instead like
>> >> you noticed we concentrate on the tasks we wish to do.
>> >> Think if we start from the protocol side we will stay there (nowhere)
>> >> for few more years (although SPDY might be even more then we need).
>> >
>> >
>> > I think what matters is having a working SPDY implementation in tomcat,
>> > inter-operable
>> > with chrome/mod_spdy/google. If we start with this we'll probably make
>> > more progress than by discussing protocols :-)
>>
>> Yep, I have noted that people are preparing an implementation for httpd
>> so at some point it will just "porting" that code to TC.
>>
>>
> http://code.google.com/p/mod-spdy/
>
> Costin
>
>
>
>> Cheers
>>
>> Jean-Frederic
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: jk/cluster - intelligent systems load
Posted by Costin Manolache <co...@gmail.com>.
On Thu, Feb 18, 2010 at 12:00 AM, jean-frederic clere <jf...@gmail.com>wrote:
> On 02/17/2010 10:46 PM, Costin Manolache wrote:
> > On Wed, Feb 17, 2010 at 11:58 AM, Mladen Turk <mt...@apache.org> wrote:
> >
> >> On 02/17/2010 07:37 PM, Costin Manolache wrote:
> >>
> >>> On Wed, Feb 17, 2010 at 12:38 AM, Mladen Turk<mt...@apache.org>
> wrote:
> >>>
> >>>
> >>> The reasons I suggest using SPDY as a replacement for AJP - and
> supporting
> >>> SPDY
> >>>
> >>
> >> I have nothing against SPDY and it really looks cool,
> >> but IMHO it's doesn't look and feel like the rest of RFC
> >> protocol specifications.
> >> If you can push those guys to create a well known RFC-like
> >> doc, I'm sure that overall internet community will benefit
> >> from it.
> >>
> >
> > SPDY is still in development - there is an open mailing list and
> > quite a few proposals/changes/discussions. I would guess
> > the end result will end up as a RFC-like. Feel free to join the
> > mailing list and push or volunteer for anything :-)
> >
> > The implementations - chrome, mod_spdy are also open source
> > and with ASF-like license.
> >
> >
> >
> >>
> >> OTOH we are discussing this 'protocol thing' for years instead like
> >> you noticed we concentrate on the tasks we wish to do.
> >> Think if we start from the protocol side we will stay there (nowhere)
> >> for few more years (although SPDY might be even more then we need).
> >
> >
> > I think what matters is having a working SPDY implementation in tomcat,
> > inter-operable
> > with chrome/mod_spdy/google. If we start with this we'll probably make
> > more progress than by discussing protocols :-)
>
> Yep, I have noted that people are preparing an implementation for httpd
> so at some point it will just "porting" that code to TC.
>
>
http://code.google.com/p/mod-spdy/
Costin
> Cheers
>
> Jean-Frederic
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: jk/cluster - intelligent systems load
Posted by jean-frederic clere <jf...@gmail.com>.
On 02/17/2010 10:46 PM, Costin Manolache wrote:
> On Wed, Feb 17, 2010 at 11:58 AM, Mladen Turk <mt...@apache.org> wrote:
>
>> On 02/17/2010 07:37 PM, Costin Manolache wrote:
>>
>>> On Wed, Feb 17, 2010 at 12:38 AM, Mladen Turk<mt...@apache.org> wrote:
>>>
>>>
>>> The reasons I suggest using SPDY as a replacement for AJP - and supporting
>>> SPDY
>>>
>>
>> I have nothing against SPDY and it really looks cool,
>> but IMHO it's doesn't look and feel like the rest of RFC
>> protocol specifications.
>> If you can push those guys to create a well known RFC-like
>> doc, I'm sure that overall internet community will benefit
>> from it.
>>
>
> SPDY is still in development - there is an open mailing list and
> quite a few proposals/changes/discussions. I would guess
> the end result will end up as a RFC-like. Feel free to join the
> mailing list and push or volunteer for anything :-)
>
> The implementations - chrome, mod_spdy are also open source
> and with ASF-like license.
>
>
>
>>
>> OTOH we are discussing this 'protocol thing' for years instead like
>> you noticed we concentrate on the tasks we wish to do.
>> Think if we start from the protocol side we will stay there (nowhere)
>> for few more years (although SPDY might be even more then we need).
>
>
> I think what matters is having a working SPDY implementation in tomcat,
> inter-operable
> with chrome/mod_spdy/google. If we start with this we'll probably make
> more progress than by discussing protocols :-)
Yep, I have noted that people are preparing an implementation for httpd
so at some point it will just "porting" that code to TC.
Cheers
Jean-Frederic
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: jk/cluster - intelligent systems load
Posted by Costin Manolache <co...@gmail.com>.
On Wed, Feb 17, 2010 at 11:58 AM, Mladen Turk <mt...@apache.org> wrote:
> On 02/17/2010 07:37 PM, Costin Manolache wrote:
>
>> On Wed, Feb 17, 2010 at 12:38 AM, Mladen Turk<mt...@apache.org> wrote:
>>
>>
>> The reasons I suggest using SPDY as a replacement for AJP - and supporting
>> SPDY
>>
>
> I have nothing against SPDY and it really looks cool,
> but IMHO it's doesn't look and feel like the rest of RFC
> protocol specifications.
> If you can push those guys to create a well known RFC-like
> doc, I'm sure that overall internet community will benefit
> from it.
>
SPDY is still in development - there is an open mailing list and
quite a few proposals/changes/discussions. I would guess
the end result will end up as a RFC-like. Feel free to join the
mailing list and push or volunteer for anything :-)
The implementations - chrome, mod_spdy are also open source
and with ASF-like license.
>
> OTOH we are discussing this 'protocol thing' for years instead like
> you noticed we concentrate on the tasks we wish to do.
> Think if we start from the protocol side we will stay there (nowhere)
> for few more years (although SPDY might be even more then we need).
I think what matters is having a working SPDY implementation in tomcat,
inter-operable
with chrome/mod_spdy/google. If we start with this we'll probably make
more progress than by discussing protocols :-)
Costin
> Regards
> --
> ^TM
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: jk/cluster - intelligent systems load
Posted by Mladen Turk <mt...@apache.org>.
On 02/17/2010 07:37 PM, Costin Manolache wrote:
> On Wed, Feb 17, 2010 at 12:38 AM, Mladen Turk<mt...@apache.org> wrote:
>
>
> The reasons I suggest using SPDY as a replacement for AJP - and supporting
> SPDY
I have nothing against SPDY and it really looks cool,
but IMHO it's doesn't look and feel like the rest of RFC
protocol specifications.
If you can push those guys to create a well known RFC-like
doc, I'm sure that overall internet community will benefit
from it.
OTOH we are discussing this 'protocol thing' for years instead like
you noticed we concentrate on the tasks we wish to do.
Think if we start from the protocol side we will stay there (nowhere)
for few more years (although SPDY might be even more then we need).
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: jk/cluster - intelligent systems load
Posted by Costin Manolache <co...@gmail.com>.
On Wed, Feb 17, 2010 at 12:38 AM, Mladen Turk <mt...@apache.org> wrote:
> On 02/16/2010 06:57 PM, Costin Manolache wrote:
>
>>
>> I think the main driver for replacing ajp is the 2-directional protocols -
>> and if we
>> replace it, why invent a new protocol and not just adopt SPDY, which has
>> all
>> we need.
>>
>>
> Totally agree.
> Both JK and AJP originate from days when the single server behind
> web server was the common topology and when there was no async processing.
> Beside SPDY, which some ASF folks that made a significant contribution
> to the original HTTP specs consider as unperfect, there is BWTP proposal
> (http://bwtp.wikidot.com/)
>
>
SPDY has quite a few problems - but it's still an improvement over AJP and
adds
2-directional and mulitplexing to HTTP - which is what we need. The main
problem with a protocol is getting enough critical mass to overcome it's
problems -
HTTP is not perfect either.
The reasons I suggest using SPDY as a replacement for AJP - and supporting
SPDY
out-of-box in tomcat:
- it does what we need
- there is one browser supporting it - and likely to take advantage of it
- probably there will be at least one large domain using it :-)
- There is also a mod_spdy for apache, and I'm sure there will be more.
Regarding problems, my list is not very big:
- requirements for compression and SSL - we don't need this for
apache-tomcat communication.
But it's easy to extend or configure the protocol to skip it / negotiate.
- right now they only want to do it over 443 ( i.e. use CONNECT method ) to
make sure proxies won't
get in the way. Apparently UPDATE doesn't work in some places. That's also
something we can
extend - and seems to be due more to the desire to get something deployed.
- of course - the current next-protocol SSL extension is out of question for
java - which has problems
even with the SSL session ticket. We might be able to support it with
APR/openssl.
- some cosmetic issues - I would prefer protobufs or thrift instead of
yet-another binary format,
sending the url as a header seems strange, binary header could be smaller,
the server push is also
a bit more complex than it should be. I don't think any matters, working
around http is much worse.
- I'm waiting for the flow control to be finalized - but seems reasonable.
> Extending exiting protocols or just doing a 'quick hacks' like I
> see with many projects trying to address those issues will not
> work in the long run. At the end you will be faced with the
> clean drawing board.
There is never a 'clean drawing board', or a perfect protocol. Any new
protocol needs
to be adopted and needs to deal with existing infrastructure - proxies,
blocked ports,
timeouts in NATs, etc.
BWTP doesn't seem so much better - mostly cosmetics. It's also more focused
as a
websocket - not as a browser-proxy-server protocol. And the list of
implementations and
potential adoption matters a lot for protocols.
( BTW: I write this wearing my own hat, my work on tomcat-lite and spdy is
on my own time, etc )
Costin
>
>
>
>
> Regards
> --
> ^TM
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: jk/cluster - intelligent systems load
Posted by Mladen Turk <mt...@apache.org>.
On 02/16/2010 06:57 PM, Costin Manolache wrote:
>
> I think the main driver for replacing ajp is the 2-directional protocols -
> and if we
> replace it, why invent a new protocol and not just adopt SPDY, which has all
> we need.
>
Totally agree.
Both JK and AJP originate from days when the single server behind
web server was the common topology and when there was no async processing.
Beside SPDY, which some ASF folks that made a significant contribution
to the original HTTP specs consider as unperfect, there is BWTP proposal
(http://bwtp.wikidot.com/)
Extending exiting protocols or just doing a 'quick hacks' like I
see with many projects trying to address those issues will not
work in the long run. At the end you will be faced with the
clean drawing board.
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: jk/cluster - intelligent systems load
Posted by Costin Manolache <co...@gmail.com>.
On Tue, Feb 16, 2010 at 1:38 AM, Mladen Turk <mt...@apache.org> wrote:
> On 02/16/2010 10:21 AM, Mark Thomas wrote:
>
>> On 16/02/2010 09:08, Mladen Turk wrote:
>>
>>> On 02/16/2010 09:56 AM, Mark Thomas wrote:
>>>
>>>> The other thing it potentially allows is the cluster to tell the proxy
>>>> about which nodes are in the cluster, allowing a more dynamic
>>>> configuration. Not sure I'd want to use that in production, but in dev
>>>> that could be useful.
>>>>
>>>>
>>> Hmm, the zero conf is actually more desired in production then in
>>> dev environments since it allows single point of admin and no need
>>> for webserver reconfig.
>>>
>>
>> Its just a personal opinion. I don't like any form of auto-configuration
>> in production because I always feel I never quite know what it is doing
>> or, more importantly, what it might do.
>>
>
> Well it's zero conf inside web server only, so its conf is passed from
> Tomcat, and that is certainly something strictly defined inside .xml or
> via some manager app.
>
> There was attempt for creating AJP14 protocol, since the current one
> lacks some IPC capabilities with the limited packed size being the major
> problem. However I'd rather see mod_jk/isapi with http protocol then
> creating
> some AJP extensions or even completely new protocol. Network and processing
> speed changed a lot since 90's so now there's almost no performance
> difference
> between AJP and HTTP implementations. With some new HTTP proposals for
> connection reusing even that factor could be eliminated in the future.
>
>
IMHO bi-directional communication is quite important - there are all kind of
new
protocols ( web socket, SPDY ) that requires it. You can have apache as a
frontend
for those protocols - but than you need AJP or mod_proxy to support it as
well.
I think the main driver for replacing ajp is the 2-directional protocols -
and if we
replace it, why invent a new protocol and not just adopt SPDY, which has all
we need.
There are some issues with SPDY - like the requirement to compress and do
SSL,
but we can easily tweak it.
Regarding auto-conf , smarter load balancing and the other features enabled
by 2-directional
communication - in a large enough cluster they become quite important.
Costin
Re: jk/cluster - intelligent systems load
Posted by Mladen Turk <mt...@apache.org>.
On 02/16/2010 10:21 AM, Mark Thomas wrote:
> On 16/02/2010 09:08, Mladen Turk wrote:
>> On 02/16/2010 09:56 AM, Mark Thomas wrote:
>>> The other thing it potentially allows is the cluster to tell the proxy
>>> about which nodes are in the cluster, allowing a more dynamic
>>> configuration. Not sure I'd want to use that in production, but in dev
>>> that could be useful.
>>>
>>
>> Hmm, the zero conf is actually more desired in production then in
>> dev environments since it allows single point of admin and no need
>> for webserver reconfig.
>
> Its just a personal opinion. I don't like any form of auto-configuration
> in production because I always feel I never quite know what it is doing
> or, more importantly, what it might do.
Well it's zero conf inside web server only, so its conf is passed from
Tomcat, and that is certainly something strictly defined inside .xml or
via some manager app.
There was attempt for creating AJP14 protocol, since the current one
lacks some IPC capabilities with the limited packed size being the major
problem. However I'd rather see mod_jk/isapi with http protocol then creating
some AJP extensions or even completely new protocol. Network and processing
speed changed a lot since 90's so now there's almost no performance difference
between AJP and HTTP implementations. With some new HTTP proposals for
connection reusing even that factor could be eliminated in the future.
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: jk/cluster - intelligent systems load
Posted by Mark Thomas <ma...@apache.org>.
On 16/02/2010 09:08, Mladen Turk wrote:
> On 02/16/2010 09:56 AM, Mark Thomas wrote:
>> The other thing it potentially allows is the cluster to tell the proxy
>> about which nodes are in the cluster, allowing a more dynamic
>> configuration. Not sure I'd want to use that in production, but in dev
>> that could be useful.
>>
>
> Hmm, the zero conf is actually more desired in production then in
> dev environments since it allows single point of admin and no need
> for webserver reconfig.
Its just a personal opinion. I don't like any form of auto-configuration
in production because I always feel I never quite know what it is doing
or, more importantly, what it might do. If folks want to use it in
production then there would obviously be nothing stopping them.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: jk/cluster - intelligent systems load
Posted by Mladen Turk <mt...@apache.org>.
On 02/16/2010 09:56 AM, Mark Thomas wrote:
>
> I don't see why the current set of valid cluster nodes could not be
> passed back via a header.
>
Exactly.
> That raises the interesting question of if a node goes down, which
> component will notice first? The proxy or the cluster? With long
> timeouts in the proxy, there is a good chance the cluster will notice
> quite some time earlier so there is a definite advantage to this.
>
Both mod_jk and isapi_redirect have now watchdog logic that can
ping backends on regular intervals without user intervetion so
the latency will be around 60 seconds which is IMO acceptable for
node maintenance.
Httpd 2.3+ has mod_hartbeat and mod_watchdog so this can easily
be ported to mod_proxy_ajp/http
> The other thing it potentially allows is the cluster to tell the proxy
> about which nodes are in the cluster, allowing a more dynamic
> configuration. Not sure I'd want to use that in production, but in dev
> that could be useful.
>
Hmm, the zero conf is actually more desired in production then in
dev environments since it allows single point of admin and no need
for webserver reconfig.
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: jk/cluster - intelligent systems load
Posted by Mark Thomas <ma...@apache.org>.
On 16/02/2010 07:01, Mladen Turk wrote:
> On 02/16/2010 12:24 AM, Mark Thomas wrote:
>> On 15/02/2010 21:52, Filip Hanik - Dev Lists wrote:
>>>>
>>> why not just a servlet filter?
>>
>> +1. I was going to suggest the same thing.
>>
>
> Why not reusing the clustering code for that.
> It would allow to pre-redirect the requests
> without doing the actual ping for undeployed
> applications or for the instances going down.
> Just having filter would be enough to get the
> info about the single node, but the highest
> latency in mod_jk comes from detecting the failed
> node not the busiest one.
I don't see why the current set of valid cluster nodes could not be
passed back via a header.
That raises the interesting question of if a node goes down, which
component will notice first? The proxy or the cluster? With long
timeouts in the proxy, there is a good chance the cluster will notice
quite some time earlier so there is a definite advantage to this.
The other thing it potentially allows is the cluster to tell the proxy
about which nodes are in the cluster, allowing a more dynamic
configuration. Not sure I'd want to use that in production, but in dev
that could be useful.
All of this / some of this could make a great GSOC project.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: jk/cluster - intelligent systems load
Posted by Mladen Turk <mt...@apache.org>.
On 02/16/2010 12:24 AM, Mark Thomas wrote:
> On 15/02/2010 21:52, Filip Hanik - Dev Lists wrote:
>>>
>> why not just a servlet filter?
>
> +1. I was going to suggest the same thing.
>
Why not reusing the clustering code for that.
It would allow to pre-redirect the requests
without doing the actual ping for undeployed
applications or for the instances going down.
Just having filter would be enough to get the
info about the single node, but the highest
latency in mod_jk comes from detecting the failed
node not the busiest one.
Regards
--
^TM
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: jk/cluster - intelligent systems load
Posted by Mark Thomas <ma...@apache.org>.
On 15/02/2010 21:52, Filip Hanik - Dev Lists wrote:
> On 02/15/2010 04:38 AM, Henri Gomez wrote:
>> 2010/2/12 Mark Thomas<ma...@apache.org>:
>>
>>> On 12/02/2010 15:20, Henri Gomez wrote:
>>>
>>>> Hi to all,
>>>>
>>>> Some times ago, we discuss about mod_jk/cluster and more intelligent
>>>> strategy to be use for the dispatching system.
>>>>
>>>> One point was to get system load informations about the various Tomcat
>>>> instances involved in a cluster, to send request to the lowest loaded
>>>> Tomcat.
>>>>
>>>> Hyperic Sigar, http://www.hyperic.com/products/sigar.html, seems to
>>>> provide such informations for various OS.
>>>>
>>>> Could it be interesting to add such 'extension' to Tomcat, so it could
>>>> be able to send back to jk/cluster so they could get the best
>>>> decisions ?
>>>>
>>>> New commands could be added to AJP13, as done previously with
>>>> cping/cpong,
>>>> http://tomcat.apache.org/connectors-doc/ajp/ajpv13ext.html.
>>>>
>>>> What do you think about ?
>>>>
>>> I like the general idea.
>>>
>> Thanks
>>
>>
>>> My personal favourite in terms of implementation is to pass the
>>> information via response headers as it allows interoperability with the
>>> widest possible range of front-end load balancers. The info can be
>>> passed back with every request or only for requests to a particular URL.
>>>
>> Why not in response headers if it's discarded by the jk side.
>> These informations shouldn't be send back to the browser (security
>> concerns).
>>
>>
>>> Then you get into how you measure load. I don't think that there will be
>>> a one size fits all solution. I imagine that it would need to be fairly
>>> easy for folks to implement their own load measurements. Using response
>>> headers makes that simple to do providing we get the definition of that
>>> header format right.
>>>
>> In response header it will allow both mod_jk (ajp), or mod_proxy
>> (http) to get such decision.
>>
>> Question, how to add such informations in Tomcat ?
>> Extension ?
>>
> why not just a servlet filter?
+1. I was going to suggest the same thing.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: jk/cluster - intelligent systems load
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
On 02/15/2010 04:38 AM, Henri Gomez wrote:
> 2010/2/12 Mark Thomas<ma...@apache.org>:
>
>> On 12/02/2010 15:20, Henri Gomez wrote:
>>
>>> Hi to all,
>>>
>>> Some times ago, we discuss about mod_jk/cluster and more intelligent
>>> strategy to be use for the dispatching system.
>>>
>>> One point was to get system load informations about the various Tomcat
>>> instances involved in a cluster, to send request to the lowest loaded
>>> Tomcat.
>>>
>>> Hyperic Sigar, http://www.hyperic.com/products/sigar.html, seems to
>>> provide such informations for various OS.
>>>
>>> Could it be interesting to add such 'extension' to Tomcat, so it could
>>> be able to send back to jk/cluster so they could get the best
>>> decisions ?
>>>
>>> New commands could be added to AJP13, as done previously with
>>> cping/cpong, http://tomcat.apache.org/connectors-doc/ajp/ajpv13ext.html.
>>>
>>> What do you think about ?
>>>
>> I like the general idea.
>>
> Thanks
>
>
>> My personal favourite in terms of implementation is to pass the
>> information via response headers as it allows interoperability with the
>> widest possible range of front-end load balancers. The info can be
>> passed back with every request or only for requests to a particular URL.
>>
> Why not in response headers if it's discarded by the jk side.
> These informations shouldn't be send back to the browser (security concerns).
>
>
>> Then you get into how you measure load. I don't think that there will be
>> a one size fits all solution. I imagine that it would need to be fairly
>> easy for folks to implement their own load measurements. Using response
>> headers makes that simple to do providing we get the definition of that
>> header format right.
>>
> In response header it will allow both mod_jk (ajp), or mod_proxy
> (http) to get such decision.
>
> Question, how to add such informations in Tomcat ?
> Extension ?
>
why not just a servlet filter?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: jk/cluster - intelligent systems load
Posted by Henri Gomez <he...@gmail.com>.
2010/2/12 Mark Thomas <ma...@apache.org>:
> On 12/02/2010 15:20, Henri Gomez wrote:
>> Hi to all,
>>
>> Some times ago, we discuss about mod_jk/cluster and more intelligent
>> strategy to be use for the dispatching system.
>>
>> One point was to get system load informations about the various Tomcat
>> instances involved in a cluster, to send request to the lowest loaded
>> Tomcat.
>>
>> Hyperic Sigar, http://www.hyperic.com/products/sigar.html, seems to
>> provide such informations for various OS.
>>
>> Could it be interesting to add such 'extension' to Tomcat, so it could
>> be able to send back to jk/cluster so they could get the best
>> decisions ?
>>
>> New commands could be added to AJP13, as done previously with
>> cping/cpong, http://tomcat.apache.org/connectors-doc/ajp/ajpv13ext.html.
>>
>> What do you think about ?
>
> I like the general idea.
Thanks
> My personal favourite in terms of implementation is to pass the
> information via response headers as it allows interoperability with the
> widest possible range of front-end load balancers. The info can be
> passed back with every request or only for requests to a particular URL.
Why not in response headers if it's discarded by the jk side.
These informations shouldn't be send back to the browser (security concerns).
> Then you get into how you measure load. I don't think that there will be
> a one size fits all solution. I imagine that it would need to be fairly
> easy for folks to implement their own load measurements. Using response
> headers makes that simple to do providing we get the definition of that
> header format right.
In response header it will allow both mod_jk (ajp), or mod_proxy
(http) to get such decision.
Question, how to add such informations in Tomcat ?
Extension ?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: jk/cluster - intelligent systems load
Posted by Mark Thomas <ma...@apache.org>.
On 12/02/2010 15:20, Henri Gomez wrote:
> Hi to all,
>
> Some times ago, we discuss about mod_jk/cluster and more intelligent
> strategy to be use for the dispatching system.
>
> One point was to get system load informations about the various Tomcat
> instances involved in a cluster, to send request to the lowest loaded
> Tomcat.
>
> Hyperic Sigar, http://www.hyperic.com/products/sigar.html, seems to
> provide such informations for various OS.
>
> Could it be interesting to add such 'extension' to Tomcat, so it could
> be able to send back to jk/cluster so they could get the best
> decisions ?
>
> New commands could be added to AJP13, as done previously with
> cping/cpong, http://tomcat.apache.org/connectors-doc/ajp/ajpv13ext.html.
>
> What do you think about ?
I like the general idea.
My personal favourite in terms of implementation is to pass the
information via response headers as it allows interoperability with the
widest possible range of front-end load balancers. The info can be
passed back with every request or only for requests to a particular URL.
Then you get into how you measure load. I don't think that there will be
a one size fits all solution. I imagine that it would need to be fairly
easy for folks to implement their own load measurements. Using response
headers makes that simple to do providing we get the definition of that
header format right.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org