>.......getting knowledge 
> from implementations (other tomcats from your second Apache server)
>  will break those abstractions

You may be right about this. However as I add Apache servers to the 
Apache layer without some kind of colaboration between the servers
it would seem that the problem will escalate. Effectively the hardware
load balancing at the front maintains sticky sessions and ``knows''
about all the servers loading.



> Peter Anning wrote:
> 
> >Hi,
> >
> >I am trying to implement the following configuration:
> >
> >
> >+++++++++++++++++++++++++++++++++++++++++++++++
> >              Cisco Load Balancer
> >+++++++++++++++++++++++++++++++++++++++++++++++
> >                        |
> >                        | (http)
> >                        |
> >+++++++++++++++++++++++++++++++++++++++++++++++
> >   Apache A                        Apache B         Apache Cluster Layer
> >    mod_jk                          mod_jk
> >+++++++++++++++++++++++++++++++++++++++++++++++
> >                        |
> >                        | (ajp13)
> >                        |
> >+++++++++++++++++++++++++++++++++++++++++++++++
> >TomcatI.myhost.com           TomcatII.myhost.com    JBoss Cluster Layer
> >+++++++++++++++++++++++++++++++++++++++++++++++
> >
> >
> >I can configure mod_jk in each of the Apache instances to
> >know about the two tomcat instances. So loadbalancing and
> >failover would work with one instance of apache.
> >
> >Is there any way to have the Apache ``cluster'' layer
> >know about other ``members'' in the layer and the 
> >current servlet connection status?
> >
> >Rgds
> >Peter
> >  
> >
> Hi peter,
> i'm in a context near from yours
> my opinion is that it isn't very logic because you introduce 
> abstraction layers (like in a OO environment) & getting knowledge 
> from implementations (other tomcats from your second Apache server)
>  will break those abstractions.... Moreover I think you could 
> encounter network security problems with such things isn't it ? my 2 
> pieces... Jerome
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]




---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to