18.2. Guarantees of Non Transactional Message Sends

If messages are sent to a server using a non-transacted session, HornetQ can block sending until the message has definitely reached the server, and a response has been sent back to the client. This can be configured individually for durable and non-durable messages, and is determined by the following two parameters:
BlockOnDurableSend
If this is set to true then all calls to send for durable messages on non transacted sessions will block until the message has reached the server, and a response has been sent back. The default value is true.
BlockOnNonDurableSend
If this is set to true then all calls to send for non-durable messages on non-transacted sessions will be blocked until the message has reached the server, and a response has been sent back. The default value is false.
Setting the send block to true can reduce performance since each send requires a network round trip before the next send can be performed. This means the performance of sending messages will be limited by the network round trip time (RTT) of your network, rather than the bandwidth of your network. For better performance it is recommended that you either batch many message sends together in a transaction (since with a transactional session, only the commit/rollback does not block every send), or use the asynchronous send acknowledgments feature described in Section 18.4, “Asynchronous Send Acknowledgments”.
If you are using JMS and the JMS service on the server to load your JMS connection factory instances into JNDI then these parameters can be configured in JBOSS_DIST/jboss-as/server/<PROFILE>/deploy/hornetq/hornetq-jms.xml using the elements block-on-durable-send and block-on-non-durable-send. If you are using JMS but not using JNDI then you can set these values directly on the HornetQConnectionFactory instance using the appropriate setter methods.
If you are using core you can set these values directly on the ClientSessionFactory instance using the appropriate setter methods.
When the server receives a message sent from a non transactional session, and that message is durable and the message is routed to at least one durable queue, then the server will persist the message in permanent storage. If the journal parameter journal-sync-non-transactional is set to true the server will not send a response back to the client until the message has been persisted and the server has a guarantee that the data has been persisted to disk. The default value for this parameter is true.