MDBs and durability

For durability to make sense, should the app server in which an MDB is deployed to be separated from the JMS Provider (server), so tha开发者_开发百科t if the app server shuts down and is restarted later, the MDB can be sent the messages that it had missed while the app server was down?

---

But if the server never accepted the message (because it too was down) the client can not think everything is okay and so no messages will be mysteriously missed.

More practically though, the durability property indeed assumes a single topic to which multiple remote clients are listening. If your setup is such that you already had multiple listeners on different remote servers for a topic, I guess you wouldn't be asking this question. So I assume you have your MDB(s) all deployed on a single server.

In that case, separating the JMS provider could improve your robustness, as the server running just this provider might have a lower risk to crash (smaller more dedicated system, especially without your own code = less likely to crash) and could function as a buffer for those situations where you have to restart your application server. On the other hand, with each server you add the chance that at least one of them crashes increases and the possibility that you make a configuration error somewhere increases as well. This is a tradeoff you have to make your self.

---

I would say yes. One option could be deploying HornetQ standalone:

http://docs.jboss.org/hornetq/2.2.5.Final/user-manual/en/html/architecture.html#d0e636

This way you don't need to deploy a fully featured JBoss server, saving some money by reducing your hosts specs. The memory footprint of HornetQ in standalone mode can be very low.

If splitting jms broker and MDB client is not an option, the way I did it once was developing a cache in the client that keeps unsent messages, so that if the server is down it stores messages until JBoss is up again.

---

The durability property is more intended for those situations where the client thinks everything is okay since the server's topic has accepted the message, but then it can not actually be delivered to all intended recipients, since one or more of them were down.

But if the server never accepted the message (because it too was down) the client can not think everything is okay and so no messages will be mysteriously missed.

More practically though, the durability property indeed assumes a single topic to which multiple remote clients are listening. If your setup is such that you already had multiple listeners on different remote servers for a topic, I guess you wouldn't be asking this question. So I assume you have your MDB(s) all deployed on a single server.

In that case, separating the JMS provider could improve your robustness, as the server running just this provider might have a lower risk to crash (smaller more dedicated system, especially without your own code = less likely to crash) and could function as a buffer for those situations where you have to restart your application server. On the other hand, with each server you add the chance that at least one of them crashes increases and the possibility that you make a configuration error somewhere increases as well. This is a tradeoff you have to make your self.