Question

Im trying to implement a hot sparing method for availability, I have it in mind as follows:

1. The client sends 3 identical requests, one for each server (we have 3, actually virtual machines)
2. Each server receives the request and processes it
3. When the server finishes, it pings the other servers if they have finished.
4. If he is the first to finish, the he will reply and the others wont.

So I’m having trouble with making the 3 simultaneous requests. This is what I would normally do to call a Remote interface from a servlet

class Servlet_JSP_or_Something extends HttpServlet
{
     doGet(HttpReq...)
     {
          @EJB
          RemoteInterfaceEJB ejbclass;
          ejbclass.doSomething()
     }
}

But, now I guess I would have to do something like this

class Servlet_JSP_or_Something extends HttpServlet
{
     doGet(HttpReq...)
     {
          @EJB(name="Server1")
          RemoteInterfaceEJB ejbclass;
          ejbclass.doSomething()

          @EJB(name="server2")
          RemoteInterfaceEJB ejbclass;
          ejbclass.doSomething()

          @EJB(name="server3")
          RemoteInterfaceEJB ejbclass;
          ejbclass.doSomething()
     }
}

But I’m not so shure if that would work. I dont even know if @EJB(name=”…”) is enough
or how to set the name for each different ejb running on the different vitual machines.

So the question is:
¿How can I simultaneously call 3 identicall EJBs from the same servlet/jsp being that the EJBs are running on different machines?

Answer 1

Stick the request on a queue, have the 3 machines listen on the queue, and wait for the result. If any of them fail during the processing, the request will go back on the queue and be handled by one of the other two. Having 3 systems running simultaneously on the same request, and “racing” to succeed sounds just wildly fraught with danger and craziness.

I mean, it makes sense for avionics with voting systems to help ensure jetliners don’t spontaneously plunge in to the sea, but most systems don’t really have that burden of reliability. They also tend to have really big engineering budgets.

So, I would go with the JMS queue.

Addenda:

The queue is managed by a cluster, then the EJBs can be deployed in their own cluster (or simply independent workers, they don’t even have to be EJBs, they can be anything). The EJBs are all subscribed to the same queue. Each bean takes a message off the queue and runs with it. The taking of the message is transactional. If the EJB fails for whatever reason, the message becomes available on queue again, ready for another EJB to take it.

Both the JMS queue and the EJB servers are redundant so that neither are a single point of failure.

Many of the EJB servers today can be clustered, so it’s just a matter of configuring your server in to a cluster, and calling it. Your client code wouldn’t change.

If you’re not happy with this arrangement, then you can instead of using remote EJB calls, you can switch to Web Services, and front the service handler servers (i.e. the EJB servers) with a (clustered) load balancer to distribute traffic.

None of this addresses all of the issues that occur when taking a single stack process redundant in terms of state sharing, race conditions, session affinity, etc. etc.

There is no “simple” annotation to do this. Using out of the box clustering specific to your container is probably as close as you’re going to get.