On 8/9/06, Ning Li <[EMAIL PROTECTED]> wrote:
We have backend servers which host ActiveMQ brokers, and we have a web
application, running on a Web Server, which is the ActiveMQ client
talking to the brokers, it will use failover transport talk to the
brokers.
In the near future, we are going to use Web Clustering (or Web Farm),
i.e. several Web Servers running at the same time, if one Web Server is
down, another web server will replace it transparently. In order to do
that, the web application shouldn't have any state information in memory
that other Web Servers cannot access, which prevents them from taking
over the job. We are thinking maybe we can make all those
ConnectionState etc. objects serializable, so they can be persisted and
accessed by another Web Server to reconnect to a broker and continue the
work. But we are not sure if they are not other issues we didn't seee
and if this is a feasible solution.
If a web server fails your load balancer will failover to another web
server fine.
If a web server fails during a servlet request - the entire servlet
request is discarded by your load balancer and the request will be
performed again in another web server. So you probably don't want to
try replicate in-flight operations to another box as you will get the
entire operation repeated in another web server anyway.
So I'd just make sure that you complete all JMS operations before
completing the HTTP request (e.g. don't use async send). If your web
servers have a habit of going down in the middle of processing
requests then you might want to look at duplicate detection to filter
out duplicate JMS messages
Also we'd like to know ActiveMQ
community's thoughts on using ActiveMQ for Web Clustering (Web Farm)
case.
See above - or are you talking about implementing distributed HTTP
session state? If the latter you might wanna take a look at WADI
http://wadi.codehaus.org/
--
James
-------
http://radio.weblogs.com/0112098/
