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 requ
2010/2/12 Mark Thomas :
> 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 invo
On 02/15/2010 04:38 AM, Henri Gomez wrote:
2010/2/12 Mark Thomas:
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 abou
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:
>>
>>> 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 us
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
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
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 t
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
>
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
On Tue, Feb 16, 2010 at 1:38 AM, Mladen Turk 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 ar
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
On Wed, Feb 17, 2010 at 12:38 AM, Mladen Turk 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.
>>
On 02/17/2010 07:37 PM, Costin Manolache wrote:
On Wed, Feb 17, 2010 at 12:38 AM, Mladen Turk 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
On Wed, Feb 17, 2010 at 11:58 AM, Mladen Turk wrote:
> On 02/17/2010 07:37 PM, Costin Manolache wrote:
>
>> On Wed, Feb 17, 2010 at 12:38 AM, Mladen Turk wrote:
>>
>>
>> The reasons I suggest using SPDY as a replacement for AJP - and supporting
>> SPDY
>>
>
> I have nothing against SPDY and it r
On 02/17/2010 10:46 PM, Costin Manolache wrote:
> On Wed, Feb 17, 2010 at 11:58 AM, Mladen Turk wrote:
>
>> On 02/17/2010 07:37 PM, Costin Manolache wrote:
>>
>>> On Wed, Feb 17, 2010 at 12:38 AM, Mladen Turk wrote:
>>>
>>>
>>> The reasons I suggest using SPDY as a replacement for AJP - and supp
On Thu, Feb 18, 2010 at 12:00 AM, jean-frederic clere wrote:
> On 02/17/2010 10:46 PM, Costin Manolache wrote:
> > On Wed, Feb 17, 2010 at 11:58 AM, Mladen Turk wrote:
> >
> >> On 02/17/2010 07:37 PM, Costin Manolache wrote:
> >>
> >>> On Wed, Feb 17, 2010 at 12:38 AM, Mladen Turk
> wrote:
> >>>
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
On Thu, Feb 18, 2010 at 10:57 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.
There are some problems with making sure thi
>> 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 th
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 :)
> 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 b
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 c
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 s
On Fri, Feb 19, 2010 at 8:51 AM, jean-frederic clere 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.
>> 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.
>
> Ad
> 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.
> 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
27 matches
Mail list logo
