2 Replies Latest reply on Jan 8, 2014 4:54 AM by ataylor

    HornetQ, Mule ESB and large text (xml) messages: how to configure HornetQ

    user_22
    user_22 Jan 7, 2014 5:54 AM

      Hi,

       

      I was wondering if there were any kind of recommended HornetQ config “profile” for different kinds of usage, to help to get started with HornetQ . In our case the profile would help dealing with large text (XML) messages.

      We have problems (obviously related to incorrect configuration) when using HornetQ with Mule ESB. Mule as JMS-client keeps dropping JMS connection and can’t restore / reset connections.

      Mule and HornetQ are running in the same host. They are used to implement messaging interface (integration) for sending and receiving text (xml) messages, that can be up to 10 M of size. At peak times integration receives messages more than app server can handle, so they “routed” to hard drive to wait.

      This error message (below) in Mules log (from “org.hornetq.core.client”)  seems to indicate that something in HornetQ client connection has been broken and will not be recovered, so you better restart servers as soon as possible.

      ERROR 2013-10-31 03:01:46,014 [Thread-659 (HornetQ-client-global-threads-758605809)] org.hornetq.core.client: HQ214005: Failed to handle failover

      HornetQException[errorType=CONNECTION_TIMEDOUT message=HQ119033: Timed out waiting for response when sending packet 32]


      Parts of config files


      hornetq-configuration.xml:

       

         <journal-file-size>20971520</journal-file-size>

        

         <!-- rule 22: journal size > journal buffer size > large message size -->  

         <journal-buffer-size>11534336</journal-buffer-size>       


         <address-settings>

            <!--default for catch all-->

            <address-setting match="#">

           

              <expiry-address>jms.queue.ExpiryQueue</expiry-address>

              <dead-letter-address>jms.queue.DLQ</dead-letter-address>

              <max-delivery-attempts>3</max-delivery-attempts>        

              <redelivery-delay>1000</redelivery-delay>

                       

              <page-size-bytes>15728640</page-size-bytes>

             

              <message-counter-history-day-limit>10</message-counter-history-day-limit>

       

              <max-size-bytes>20971520</max-size-bytes>

              <address-full-policy>PAGE</address-full-policy>

            </address-setting>

       

         </address-settings>

       

      hornetq-jms.xml:

       

              <min-large-message-size>10485760</min-large-message-size>     

             

              <!-- client ack with no client side cache -->

              <pre-acknowledge>false</pre-acknowledge>       

       

              <!-- Set the consumer window size to 0 to have *no* buffer on the client side -->

              <consumer-window-size>0</consumer-window-size>   

       

              <!-- reconnect-attempts : This optional parameter determines the total number of reconnect attempts to make before giving up and shutting down. A value of -1 signifies an unlimited number of attempts. The default value is 0. -->

              <!- wonder what does "shut down" mean here from Mules perspective -->

              <!-- 2 s * 100 times : but : why wouldn't mule just create a new connection if old connection corrupts or something ??? -->

       

              <retry-interval>2000</retry-interval>

              <retry-interval-multiplier>1</retry-interval-multiplier>

              <max-retry-interval>1001</max-retry-interval>

              <reconnect-attempts>180</reconnect-attempts>

       

             

       

             

             

              <!-- Setting this parameter to -1 disables any buffering and prevents any re-attachment from occurring, forcing reconnect instead.

              The default value for this parameter is -1. (Which means by default no auto re-attachment will occur) -->

              <confirmation-window-size>-1</confirmation-window-size>

       

             

              <block-on-durable-send>false</block-on-durable-send>

              <block-on-non-durable-send>true</block-on-non-durable-send>

              <block-on-acknowledge>false</block-on-acknowledge>

              <connection-ttl>10000</connection-ttl>

              <call-timeout>180000</call-timeout>

              <cache-large-message-client>true</cache-large-message-client>

              <client-failure-check-period>5000</client-failure-check-period>

             

              <thread-pool-max-size>-1</thread-pool-max-size>


       

      • 675 Views
      • Tags: