Discussion :

[hhfr]

Bonjour,
J'essaye de faire des traitements parallèles avec des EJBs, mais je suis confronté à un problème incompréhensible, j'ai besoin des lumières d'une personne calé en JMS.

Voici un exemple simple qui illustre parfaitement mon cas d'utilisation, et surtout le problème rencontré.

Une servlet demande à un EJB de génèrer 100 messages
Un EJB génère les 100 messages dans une Queue.
Des MDBs gérés par le conteneur consomment les messages.

Hélas, avec le code qui suit, la consommation des messages ne commence qu'a la fin de la génération des 100 messages.
Ou est le hic ?

J'utilise Netbeans 6.9.1 et Glassfish 3.01
Et la servlet le producteur et le consommateur sont au sein du même ear
servlet dans war
ejb et mdb dans jar
le tout dans ear

Merci d'avance



L'essentiel code de la servlet PostMessages

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
	@EJB
	private MessagesProducerRemote messagesProducer;
 
	protected void processRequest(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
		messagesProducer.sendMessage("msg bidon", 100);
//....

]L'essentiel code de MessagesProducer

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
 
@Stateless
public class MessagesProducer implements MessagesProducerRemote {
 
	@Resource(mappedName = "jms/NewMessageFactory")
	private ConnectionFactory connectionFactory;
	@Resource(mappedName = "jms/NewMessage")
	private Queue queue;
 
	@Override
	public void sendMessage(String body, int nb) {
		try {
			Connection connection = connectionFactory.createConnection();
			while (nb > 0) {
				Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
				MessageProducer messageProducer = session.createProducer(queue);
				TextMessage message = session.createTextMessage(body);
				messageProducer.send(message);
				System.out.println("Send message : " + (nb--));
				messageProducer.close();
				session.close();
			}
			connection.close();
		} catch (JMSException ex) {
			ex.printStackTrace();
		}
	}

L'essentiel code de MessageConsumer

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
 
@MessageDriven(mappedName = "jms/NewMessage", activationConfig = {
	@ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"),
	@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue")
})
public class MessageConsumer implements MessageListener {
 
	@Resource
	private MessageDrivenContext mdc;
	@PersistenceContext
	private EntityManager em;
	private static int nb = 0;
	private int num = 0;
 
	public MessageConsumer() {
		nb++;
		num = nb;
	}
 
	@Override
	public void onMessage(Message message) {
		TextMessage msg = null;
		try {
			if (message instanceof TextMessage) {
				msg = (TextMessage) message;
				System.out.println("body = " + msg.getText() + " mdb "+num);
			}
		} catch (JMSException e) {
			e.printStackTrace();
			mdc.setRollbackOnly();
		} catch (Throwable te) {
			te.printStackTrace();
		}
	}
}

LE fichier sun-resource.xml definissant la queue

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE resources PUBLIC "-//Sun Microsystems, Inc.//DTD Application Server 9.0 Resource Definitions //EN" "http://www.sun.com/software/appserver/dtds/sun-resources_1_3.dtd">
<resources>
  <admin-object-resource enabled="true" jndi-name="jms/NewMessage" object-type="user" res-adapter="jmsra" res-type="javax.jms.Queue">
    <description/>
    <property name="Name" value="PhysicalQueue"/>
  </admin-object-resource>
  <connector-resource enabled="true" jndi-name="jms/NewMessageFactory" object-type="user" pool-name="jms/NewMessageFactoryPool">
    <description/>
  </connector-resource>
  <connector-connection-pool associate-with-thread="false" connection-creation-retry-attempts="0" connection-creation-retry-interval-in-seconds="10" connection-definition-name="javax.jms.QueueConnectionFactory" connection-leak-reclaim="false" connection-leak-timeout-in-seconds="0" fail-all-connections="false" idle-timeout-in-seconds="300" is-connection-validation-required="false" lazy-connection-association="false" lazy-connection-enlistment="false" match-connections="true" max-connection-usage-count="0" max-pool-size="32" max-wait-time-in-millis="60000" name="jms/NewMessageFactoryPool" pool-resize-quantity="2" resource-adapter-name="jmsra" steady-pool-size="8" validate-atmost-once-period-in-seconds="0"/>
</resources>

[tchize_]

a vue de pifomètre, et sans etre expert dans le domaine, je pense que c'est ta transaction EJB qui se prolonge, du coup, les 100 messages produits ne sont visible au consommateur qu'au moment du commit par le conteneur EJB.

Maintenant, quand à désactiver la Tx, j'ignore

[hhfr]

a vue de pifomètre, et sans etre expert dans le domaine, je pense que c'est ta transaction EJB qui se prolonge, du coup, les 100 messages produits ne sont visible au consommateur qu'au moment du commit par le conteneur EJB.

Maintenant, quand à désactiver la Tx, j'ignore

Exactement, n'attendant pas la réponse ci tot, je continuais l'investiguation, et effectivement, je viens de comprendre la raison, c'est tout à fait ca. J'avais bien tenté de faire un commit sur l'objet session, mais la transaction étant gérer par le conteneur, celui me remonté une erreur.

En fait, par défaut la transaction est géré entièrement par le conteneur. Donc celle ci commençant dans la servlet, le commit n'est fait que à la fin de l'exécution de la servlet, à savoir, la fin de la génération des 100 messages. Enfin en tous cas c'est l'interprétation que j'en fait.

un simple rajout de l'annotation

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
@TransactionManagement(TransactionManagementType.BEAN)

Sur la classe MessageProducer résout le problème. Plus qu'a faire ca au taf lundi... :-D

En tous cas merci pour ta réactivité

[longbeach]

Merci de penser à utiliser le tag Résolu.