[EMAIL PROTECTED]">How did you solve your problem?the loadbalancer.jar does sticky ip by default itself and we have had to turn it off when because of the above issues.
Looking for thoughts on my problem; 2 boxes available for clustering.
I have a Cisco Director (SP?). But I don't have a 3rd box in production to run the loadbalancer.jar on.
It would be a single point of failure anyway so???? How would a resilient architecture be assembled
from what I have available?
One option that I see is to NOT cluster, and deploy several instances of Orion across 2 boxes. Use
my Cisco Director HW loadbalancer to direct requests across the Orion instances. If an instance failes
or locks up, Director is smart enough to stop routing requests to that Orion instance.
This config just drops the customer's requests on that box or instance, and delivers scalability across
two boxes. To me, this is preferable to a single box where if it fails customers won't get service until
support comes in the next morning... :\
thanks, curt
[EMAIL PROTECTED]">
