J'ai évalué ActiveMQ en tant que courtier de message de candidat. J'ai écrit un code de test pour essayer de comprendre les limitations de performances d'ActiveMQ.Est-ce une attente réaliste d'un mécanisme distribué?
Je peux produire un état d'échec dans le courtier en envoyant des messages aussi vite que possible comme ceci:
try {
while(true) {
byte[] payload = new byte[(int) (Math.random() * 16384)];
BytesMessage message = session.createBytesMessage();
message.writeBytes(payload);
producer.send(message);
} catch (JMSException ex) { ... }
J'ai été surpris que la ligne
producer.send(message);
bloque lorsque le courtier entre dans une Failed Etat. J'espérais qu'une exception serait lancée, donc il y aurait une indication que le courtier a échoué. Je me rends compte que mon code de test est en train de spammer le courtier, et je m'attends à ce que le courtier échoue. Cependant, je préférerais que le courtier échoue "fort" au lieu de simplement bloquer.
Est-ce une attente irréaliste?
Mise à jour:
réponse Uri fait référence à un rapport de bogue ActiveMQ qui a été déposé en Mars. La description du bug inclut une proposition qui ressemble à ce que je cherche: "si la requête sur le transport avait un timeout (ceci est pour attraper des scénarios d'échecs, donc quelque chose qui ne devrait raisonnablement pas arriver), les choses auraient plutôt que de construire des fils d'attente. "
Cependant, après 8 mois, le bug est actuellement non attribué avec un seul vote. Donc je suppose que la question est toujours là, est-ce quelque chose qu'ActiveMQ devrait mettre en œuvre?
Chris, merci pour votre réponse . Il semble que je pourrais augmenter la mémoire, mais le blocage est inévitable: http://activemq.apache.org/my-producer-blocks.html –