load-balancing support ?

[Jean-Luc Rochat <jn...@cybercable.fr>]

hi,

I have a patch to support both JServ 1.0, JServ1.1 & Tomcat
load-balancing in mod_jserv.

As far as I can understand, the "routing" information sent by the
connector is ignored in Tomcat: The session value doesn't incorporate
it.
Does that mean that another solution has been used to identify a target,
or that nobody implemented it ? (I could maybe help here)

Jean-Luc

Re: ContextInterceptors & Interceptor configuration

[Costin Manolache <Co...@eng.sun.com>]

> I would like to be able to add and remove application wide components
> (singletons per web app/context) on context startup and correspondingly on
> context shutdown. This would allow all servlets running in the context to
> retrieve handles to these singletons in the standard manner. If I understand
> Costin correctly I should do this via the ContextInterceptor mechanism.
> Having looked at the code I have observed:
>
> The Context class has an addInitInterceptor(LifeCycleInterceptor li) and
> addDestroyInterceptor(LifeCycleInterceptor li). Should these take a
> ContextInterceptor or a LifeCycleInterceptor?

Both methods are deprecated.
Setting per-context interceptors is not implemented in 3.1 - it's easy to do
that, and most of the code is in, but I don't think anyone tested the code.
After this release - any contribution in this area is wellcome.

( LifeCycleInterceptor was used in J2EE integration, it's better to use the
ContextInterceptor instead )


> Moving on to the ContextManager, on context initialisation we need to add
> code to getInitIntercepors and call the corresponding Intercepor methods,
> likewise on context shutdown/destroy.

init/destroyInterceptor is no longer used - there are callbacks in
ContextInterceptor
that provide the same functionality ( and more )

> Next we need to be able to specify the Interceptor configurations. For
> context interceptors, I think this should be in the web.xml file as it
> represents all the other context configuration and we would need a list of
> context interceptors. Likewise for serviceInterceptors this should be done
> in the servlet definition DTD. Having added the Interceptor concept
> (excellent), how are we being constrained by the fact that the configuration
> DTD i.e. web.dtd is specified as part of the Sevlet 2.2 spec? therfore not
> open to change.

You can only use tomcat-specific config file, and your code will be tomcat
specific - I don't think the interceptors will be standardized very soon.
( at least we need to have some experience and more knowledge )


> I would like to contribute this functionality to the codebase, however I
> would like to do it in the right manner.

Take a look at ContextInterceptor interface - I think it's the right starting
point.

One very interesting idea is to use Event/Listener model - that will allow
us to generalize the interceptor model ( including the ability to add new
"events"
without changing existing interfaces ).

Costin

ContextInterceptors & Interceptor configuration

[Serle Shuman <se...@creator.co.za>]

I would like to be able to add and remove application wide components
(singletons per web app/context) on context startup and correspondingly on
context shutdown. This would allow all servlets running in the context to
retrieve handles to these singletons in the standard manner. If I understand
Costin correctly I should do this via the ContextInterceptor mechanism.
Having looked at the code I have observed:

The Context class has an addInitInterceptor(LifeCycleInterceptor li) and
addDestroyInterceptor(LifeCycleInterceptor li). Should these take a
ContextInterceptor or a LifeCycleInterceptor?

Moving on to the ContextManager, on context initialisation we need to add
code to getInitIntercepors and call the corresponding Intercepor methods,
likewise on context shutdown/destroy.

Next we need to be able to specify the Interceptor configurations. For
context interceptors, I think this should be in the web.xml file as it
represents all the other context configuration and we would need a list of
context interceptors. Likewise for serviceInterceptors this should be done
in the servlet definition DTD. Having added the Interceptor concept
(excellent), how are we being constrained by the fact that the configuration
DTD i.e. web.dtd is specified as part of the Sevlet 2.2 spec? therfore not
open to change.

I would like to contribute this functionality to the codebase, however I
would like to do it in the right manner.

Serle

Re: load-balancing support ?

[Costin Manolache <co...@eng.sun.com>]

Gal did some work, and from my reading of the code it seems he is doing
somethig with the routing info. From his comments it seems it's working -
and he's using the same mechanism as mod_jserv.

How big is the patch? If  it's just a fix it can probably go into 3.1,
otherwise I think we should wait one more week.

Can you take a look at the iis and netscape plugins - it seems much easier
to make it work with Apache 2.0 and to also add 1.3 module support - IMHO we
should make it the default for tomcat 3.2 - but we need some more eyes
looking at the code. Gal said it works fine with load-balancing ( and the
code seems designed with that in mind ).

Costin

Jean-Luc Rochat wrote:

> hi,
>
> I have a patch to support both JServ 1.0, JServ1.1 & Tomcat
> load-balancing in mod_jserv.
>
> As far as I can understand, the "routing" information sent by the
> connector is ignored in Tomcat: The session value doesn't incorporate
> it.
> Does that mean that another solution has been used to identify a target,
> or that nobody implemented it ? (I could maybe help here)
>
> Jean-Luc

Re: load-balancing support ?

[Jean-Luc Rochat <jn...@cybercable.fr>]

Shachor Gal wrote:
> 
> Jean,
> 
> >
> > I have a patch to support both JServ 1.0, JServ1.1 & Tomcat
> > load-balancing in mod_jserv.

I must explain what this patch is :
I just added in jserv_balance.c the knowledge of what a Tomcat session
id looks like (JSESSIONID/jsessionid), and code to route it. The goal is
to allow people using JServ to start using Tomcat at the same time,
without breaking everything.
This IMO does not have to be added in other Tomcat connectors (but
mod_jserv), as there is no need to start another "640K limit backwards"
compatiblity requirement.
But I hope that people using mod_jserv will still be able to use the
original one ;-)
This patch is in JServ's CVS (jserv_balance.c).
What about copying it in Tomcat's CVS ?

> >
> I actually made this code working on Tomcat, look into:
> org.apache.tomcat.request.SessionInterceptor code...
Ooops ! got it ...

> 
> The one differences is that you where using multiple cookies (one for each
> zone). We can not do that with Tomcat (the Servlet APIs mandate the name
> JSESSIONISD or something like that) so instead of multiple cookies I am
> using the path attributes of the cookie.
Yes, that is a better solution.
> 
> >
> > As far as I can understand, the "routing" information sent by the
> > connector is ignored in Tomcat: The session value doesn't incorporate
> > it.
> Again, no, and I actually made it working also for IIS + Netscape (found
> in jk_lb_worker.c)

Sorry to have messed it. very good work & design.
> 
>     Gal Shachor

Jean-Luc Rochat

PS: Gal, have you seen the RFV I made for updating ajpv12 to JServ's
last one ?
Costin was for it, is there a problem on your side ? (needs
recompilation of C connectors).

I didn't committed it yet because CVS talked to me about "not enough
Karma" to do it.

Re: load-balancing support ?

[Shachor Gal <sh...@techunix.technion.ac.il>]

Jean,

>
> I have a patch to support both JServ 1.0, JServ1.1 & Tomcat
> load-balancing in mod_jserv.
>
I actually made this code working on Tomcat, look into:
org.apache.tomcat.request.SessionInterceptor code...

The one differences is that you where using multiple cookies (one for each
zone). We can not do that with Tomcat (the Servlet APIs mandate the name
JSESSIONISD or something like that) so instead of multiple cookies I am
using the path attributes of the cookie.

>
> As far as I can understand, the "routing" information sent by the
> connector is ignored in Tomcat: The session value doesn't incorporate
> it.
Again, no, and I actually made it working also for IIS + Netscape (found
in jk_lb_worker.c)

    Gal Shachor