The timing metrics are measured internally by the EJB that contains the method to send the message to JMS. A message is generated by our application. This message is passed to the method above. A JMS producer is initialised. A message correlation ID is generated from the message. A JMS consumer is initialised. The message is sent to the jms provider (jbm), flagged as non-persistent. stomp connect is running (bisocket) and a native app (C) receives the message, performs some actions, and then sends a response back to JMS via stompconnect, where the EJB that initially sent the message receives the response. The response message contains the timing of the native app, and the EJB then subtracts this time from the total timing. So the results posted are basically for initalising the producer, generating / getting the correlation ID, sending the message until the message hits the app, and then from the message being sent back to JMS until it is received by the EJB. The results basically are showing the timing differences between JBM 1.4.0-SP3 configured with mysql-persistence (even though messages are sent as non-persistent), JBM 1.4.2-SP1 with mysql-persistence and JBM 1.4.2-SP1 configured with null-persistence. Trying to understand why null persistence configuration consistently has significantly higher latency than mysql persistence configuration, even though messages are always marked as non-persistent. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4219839#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...