SmartClient Version: v9.0p_2013-12-19/PowerEdition Deployment (built 2013-12-19)
Firefox 17.0.9
JBoss EAP 6.1 with Hornetq
Using the RTM JMSMessageDispatcher
server.properties configuration:
Note that in JNDI, the JMS ConnectionFactory is located at "java:/ConnectionFactory". This is NOT the JCA (pooled) connection factory. (I tried that, but that results in errors in JBoss about using the JCA connection factory in the wrong context, probably when the MessagingServlet tried to call javax.jms.Session.setMessageListener()).
(BTW, what does the messaging.jms.context property do? I could not find documentation for it.)
A JMS Queue is defined in JBoss named "/webapp/events".
I am using RTM to send events to a SmartGWT web application. In particular, a message driven bean listening on a JMS queue for externally generated events, is converting and dispatching those events using ISCMessageDispatcher..send(). More precisely:
The SmartGWT client application is calling:
The client is receiving the messages as expected. (And I must say, RTM and Data Sources makes it possible to do some really cool stuff!)
The first problem are the following warnings in the JBoss log file:
(I've omitted the rest of the stack trace which just leads up the the call to onMessage()). Hornetq keeps track of when a Connection is obtained from the ConnectionFactory, and if that Connection is GC'd (finalize) without being closed, it you get this warning. If a lot of messages are processed in succession (say several thousand) the log is full of these warnings.
From this it appears that ISCMessageDispatcher.instance() is creating a new instance of ISCMessageDispatcher each time, each instance opening a new JMS Connection, and that it is not closing the Connection. At first I assumed that ISCMessageDispatcher.instance() was returning a (thread safe) singleton, but these warnings suggest otherwise. So my questions are:
- does ISCMessageDispatcher.instance() return a new instance with each invocation? If so, is that instance thread safe?
- Does each ISCMessageDispatcher instance open a new JMS Connection using the connection factory?
- How do you close the underlying JMS Connection that the ISCMessageDispatcher instance is using ? There does not seem to be a close() method, etc.
My second question is regarding com.isomorphic.messaging.MessagingServlet. If I try to stop the JBoss server while there are active client sessions (active subscriptions), the server will hang, presumably because the MessagingServlet still has an open JMS Connection and Session, listening on the "/webapp/events" Queue. If I close the client sessions, then this hang does not occur. What is the recommended way of handling this?
Thanks.
Firefox 17.0.9
JBoss EAP 6.1 with Hornetq
Using the RTM JMSMessageDispatcher
server.properties configuration:
Code:
messaging.dispatcherImplementer: com.isomorphic.messaging.JMSMessageDispatcher messaging.jms.context: _container_ messaging.jms.jndiPrefix: messaging.jms.topicConnectionFactory = ConnectionFactory
(BTW, what does the messaging.jms.context property do? I could not find documentation for it.)
A JMS Queue is defined in JBoss named "/webapp/events".
I am using RTM to send events to a SmartGWT web application. In particular, a message driven bean listening on a JMS queue for externally generated events, is converting and dispatching those events using ISCMessageDispatcher..send(). More precisely:
Code:
public void onMessage(Message message) {
try {
// Process incoming JMS message to produce an "event" to send to SmartGWT client
Map event = ....
ISCDispatcher.instance().send("/webapp/events", event);
} catch(Exception e) {
//...
}
}
Code:
Messaging.subscribe("/webapp/events", ..)
The first problem are the following warnings in the JBoss log file:
Code:
15:06:15,097 WARN [org.hornetq.core.client] (Finalizer) HQ212016: I am closing a core ClientSession you left open. Please make sure you close all ClientSessions explicitly before letting them go out of scope! 126,844,628: java.lang.Exception
at org.hornetq.core.client.impl.DelegatingSession.<init>(DelegatingSession.java:91)
at org.hornetq.core.client.impl.ClientSessionFactoryImpl.createSessionInternal(ClientSessionFactoryImpl.java:912)
at org.hornetq.core.client.impl.ClientSessionFactoryImpl.createSession(ClientSessionFactoryImpl.java:317)
at org.hornetq.jms.client.HornetQConnection.authorize(HornetQConnection.java:648)
at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:676)
at org.hornetq.jms.client.HornetQConnectionFactory.createTopicConnection(HornetQConnectionFactory.java:131)
at org.hornetq.jms.client.HornetQConnectionFactory.createTopicConnection(HornetQConnectionFactory.java:126)
at com.isomorphic.messaging.JMSMessageDispatcher.reconnect(JMSMessageDispatcher.java:79)
at com.isomorphic.messaging.JMSMessageDispatcher.ensureConnected(JMSMessageDispatcher.java:98)
at com.isomorphic.messaging.JMSMessageDispatcher.deliver(JMSMessageDispatcher.java:199)
at com.isomorphic.messaging.ISCMessageDispatcher.send(ISCMessageDispatcher.java:236)
at xxxx.webapp.server.messaging.RequestCreatedListener.onMessage(RequestCreatedListener.java:58)
...
From this it appears that ISCMessageDispatcher.instance() is creating a new instance of ISCMessageDispatcher each time, each instance opening a new JMS Connection, and that it is not closing the Connection. At first I assumed that ISCMessageDispatcher.instance() was returning a (thread safe) singleton, but these warnings suggest otherwise. So my questions are:
- does ISCMessageDispatcher.instance() return a new instance with each invocation? If so, is that instance thread safe?
- Does each ISCMessageDispatcher instance open a new JMS Connection using the connection factory?
- How do you close the underlying JMS Connection that the ISCMessageDispatcher instance is using ? There does not seem to be a close() method, etc.
My second question is regarding com.isomorphic.messaging.MessagingServlet. If I try to stop the JBoss server while there are active client sessions (active subscriptions), the server will hang, presumably because the MessagingServlet still has an open JMS Connection and Session, listening on the "/webapp/events" Queue. If I close the client sessions, then this hang does not occur. What is the recommended way of handling this?
Thanks.
Comment