Est-ce une bonne pratique à utiliser JMS File d'attente Temporaire synchrone utiliser?

Fait intéressant, l'évolutivité de cette peut-être en fait le contraire de ce que les autres réponses ont décrit.

WebSphere MQ enregistre et réutilise dynamique de la file d'attente des objets lorsque cela est possible. Donc, bien que l'utilisation d'une dynamique de la file d'attente n'est pas libre, il n'est bien parce que les files d'attente sont libérés, tout ce qui WMQ besoin de faire est de passer la poignée pour le prochain thread qui demande une nouvelle file d'attente de l'instance. Dans une longue QMgr, le nombre de dynamique des files d'attente restera relativement statique, tandis que les poignées sont passés de filet. Strictement parlant, il n'est pas aussi rapide que la réutilisation d'une seule file d'attente, mais il n'est pas mauvais.

D'autre part, même si l'indexation sur CORRELID est rapide, la performance est l'inverse pour le nombre de messages dans l'index. Il a également fait une différence si la profondeur de file d'attente commence à se construire. Lorsque l'application va un GET avec WAIT sur une zone vide de la file d'attente il n'y a pas de retard. Mais sur une profondeur de file d'attente, le QMgr est à rechercher dans l'index des messages existants pour déterminer que le message de réponse n'est pas parmi eux. Dans votre exemple, c'est la différence entre la recherche dans un index vide par rapport à un grand indice de 1 000 s de fois par seconde.

Le résultat est que 1000 dynamique des files d'attente avec un message à chaque peut effectivement être plus rapide qu'une seule file d'attente avec 1000 threads arriver par CORRELID, selon les caractéristiques de l'application et de la charge. Je recommande de tester ce à l'échelle avant de s'engager à un design particulier.

La création de files d'attente temporaires n'est pas gratuit. Après tout, c'est l'allocation des ressources sur le courtier(s). Cela dit, si vous avez un inconnu (avant de la main) potentiellement indépendant du nombre de clients (plusieurs machines virtuelles, plusieurs threads simultanés par la JVM, etc) vous ne pouvez pas avoir un choix. Par l'allocation de client files d'attente et de les affecter aux clients de sortir de la main rapide.

Certainement ce que vous avez esquissé est la plus simple solution possible. Et si vous pouvez obtenir des nombres réels pour un volume de transactions, et s'adapte assez bien.

Avant que je le regarde en évitant les files d'attente temporaires, j'aurais l'air plus à limiter le nombre de clients et de rendre les clients de longue durée. C'est-à-dire créer un pool de client sur le côté client, et ont les clients dans la piscine créer la file d'attente temporaire, session de connexion, etc. au démarrage, de les réutiliser sur les demandes ultérieures, et la larme à l'arrêt. Ensuite, le réglage d'un problème devenu l'un des max/min de la taille de la piscine, ce que le temps d'inactivité est de nettoyer la piscine, et ce que le comportement est (échec vs bloquer) lorsque la piscine est au maximum. Sauf si vous êtes en train de créer un nombre arbitrairement grand de transitoire de la Jvm (dans ce cas, vous avez plus des questions d'échelle juste à partir de la JVM de démarrage de frais généraux), qui devrait échelle ainsi que quoi que ce soit. Après tout, au point que les ressources que vous allouez de refléter l'utilisation réelle du système. Il n'y a vraiment pas de possibilité d'utiliser moins.

La chose à éviter est de la création et de la destruction d'un grand gratuite nombre de de files d'attente, les sessions, les connexions, etc. La conception du serveur, afin d'autoriser la diffusion de l'aller. Puis la piscine si/quand vous en avez besoin. Comme pas, pour rien, non négligeable, vous aurez besoin d'.

J'ai été confrontée au même problème et a décidé de pool de connexions de moi-même à l'intérieur d'un stateless bean. Un client de connexion a un tempQueue et la pose à l'intérieur de JMSMessageExchanger objet (qui contient connectionFactory,la File d'attente et tempQueue), qui est de se lier à une instance de bean. J'ai testé dans la JSE/EE environnements. Mais je ne suis pas vraiment sûr de Glassfish JMS piscine comportement.
Il fait fermer les connexions JMS, obtenu "à la main" après bean méthode se termine?Suis-je en train de faire quelque chose de mal?

Également Ive éteint transaction client bean (TransactionAttributeType.NOT_SUPPORTED) pour envoyer des messages de demande immédiatement à la demande de la file d'attente.

package net.sf.selibs.utils.amq;
import javax.jms.Connection;
import javax.jms.ConnectionFactory;
import javax.jms.DeliveryMode;
import javax.jms.Message;
import javax.jms.MessageConsumer;
import javax.jms.MessageProducer;
import javax.jms.Queue;
import javax.jms.Session;
import javax.jms.TemporaryQueue;
import lombok.Getter;
import lombok.Setter;
import net.sf.selibs.utils.misc.UHelper;
public class JMSMessageExchanger {
@Setter
@Getter
protected long timeout = 60 * 1000;
public JMSMessageExchanger(ConnectionFactory cf) {
this.cf = cf;
}
public JMSMessageExchanger(ConnectionFactory cf, Queue queue) {
this.cf = cf;
this.queue = queue;
}
//work
protected ConnectionFactory cf;
protected Queue queue;
protected TemporaryQueue tempQueue;
protected Connection connection;
protected Session session;
protected MessageProducer producer;
protected MessageConsumer consumer;
//status
protected boolean started = false;
protected int mid = 0;
public Message makeRequest(RequestProducer producer) throws Exception {
try {
if (!this.started) {
this.init();
this.tempQueue = this.session.createTemporaryQueue();
this.consumer = this.session.createConsumer(tempQueue);
}
//send request
Message requestM = producer.produce(this.session);
mid++;
requestM.setJMSCorrelationID(String.valueOf(mid));
requestM.setJMSReplyTo(this.tempQueue);
this.producer.send(this.queue, requestM);
//get response
while (true) {
Message responseM = this.consumer.receive(this.timeout);
if (responseM == null) {
return null;
}
int midResp = Integer.parseInt(responseM.getJMSCorrelationID());
if (mid == midResp) {
return responseM;
} else {
//just get other message
}
}
} catch (Exception ex) {
this.close();
throw ex;
}
}
public void makeResponse(ResponseProducer producer) throws Exception {
try {
if (!this.started) {
this.init();
}
Message response = producer.produce(this.session);
response.setJMSCorrelationID(producer.getRequest().getJMSCorrelationID());
this.producer.send(producer.getRequest().getJMSReplyTo(), response);
} catch (Exception ex) {
this.close();
throw ex;
}
}
protected void init() throws Exception {
this.connection = cf.createConnection();
this.session = this.connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
this.producer = this.session.createProducer(null);
this.producer.setDeliveryMode(DeliveryMode.NON_PERSISTENT);
this.connection.start();
this.started = true;
}
public void close() {
UHelper.close(producer);
UHelper.close(consumer);
UHelper.close(session);
UHelper.close(connection);
this.started = false;
}
}

La même classe est utilisé dans le client (stateless bean) et le serveur (@MessageDriven).
RequestProducer et ResponseProducer sont des interfaces:

package net.sf.selibs.utils.amq;
import javax.jms.Message;
import javax.jms.Session;
public interface RequestProducer {
Message produce(Session session) throws Exception;
}
package net.sf.selibs.utils.amq;
import javax.jms.Message;
public interface  ResponseProducer extends RequestProducer{
void setRequest(Message request);
Message getRequest();
}

Aussi j'ai lu AMQ article sur requête-réponse en œuvre au cours de AMQ:
http://activemq.apache.org/how-should-i-implement-request-response-with-jms.html