0 Replies Latest reply on Mar 13, 2012 9:33 AM by gksbadal

    Forwarding Messages Using HornetQ Core Bridge is Very Slow

    gksbadal

      We are trying to use the HornetQ store and forward mechanism ... however forwarding messages from one standalone hornetq instance to another using the core bridge is very slow. We have not been able to increase the throughput rate above 200 messages per second.

       

      The surprising fact is that if we point the same clinet (that was publishing messages to the forwarding hornetq instance) directly at the destination hornetq instance, we start observing a throughput rate of over 1000 messages per second (this client is JMS based). This basically means that the core bridge that's been configured between the Forwarding HornetQ instance and the Destination HornetQ instance is problematic.

       

      The following are the relevant sections for configuring the core bridge on the Forwarding HornetQ:

      {code:xml}

      <connectors>

                  <connector name="netty-bridge">

                       <factory-class>org.hornetq.core.remoting.impl.netty.NettyConnectorFactory</factory-class>

                       <param key="host" value="destination.xxx.com"/>

                       <param key="port" value="5445"/>

                       <param key="batch-delay" value="50"/>

                       <param key="tcp-send-buffer-size" value="1048576"/>

                       <param key="tcp-receive-buffer-size" value="1048576"/>

                       <param key="use-nio" value="true"/>

                 </connector>

      </connectors>

      <address-settings>

            <address-setting match="jms.queue.Record">

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

                      <max-size-bytes>262144000</max-size-bytes>

                      <page-size-bytes>10485760</page-size-bytes>

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

              </address-setting>

      </address-settings>

      <queues>

               <queue name="jms.queue.Record">

                        <address>jms.queue.Record</address>

               </queue>

      </queues>

      <bridges>

              <bridge name="core-bridge">

                      <queue-name>jms.queue.Record</queue-name>

                      <forwarding-address>jms.queue.Record</forwarding-address>

                      <retry-interval>1000</retry-interval>

                      <retry-interval-multiplier>1.0</retry-interval-multiplier>

                      <reconnect-attempts>-1</reconnect-attempts>

                      <confirmation-window-size>10485760</confirmation-window-size>

                      <static-connectors>

                              <connector-ref>netty-bridge</connector-ref>

                      </static-connectors>

              </bridge>

      </bridges>

      {code}

       

      The following are the relevant sections for configuring the core bridge on the Destination HornetQ:

      {code:xml}

      <acceptors>

            <acceptor name="netty">

               <factory-class>org.hornetq.core.remoting.impl.netty.NettyAcceptorFactory</factory-class>

               <param key="host"  value="${hornetq.remoting.netty.host:192.168.2.231}"/>

               <param key="port"  value="${hornetq.remoting.netty.port:5445}"/>

               <param key="tcp-send-buffer-size"  value="1048576"/>

               <param key="tcp-receive-buffer-size"  value="1048576"/>

               <param key="use-nio"  value="true"/>

               <param key="batch-delay"  value="50"/>

               <param key="use-nio"  value="true"/>

            </acceptor>

      <address-settings>

              <address-setting match="jms.queue.Record">

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

                      <max-size-bytes>524288000</max-size-bytes>

                      <page-size-bytes>10485760</page-size-bytes>

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

              </address-setting>

      </address-settings>

      {code}

      All system variables (CPU / Memory / Disk IO / Network etc.) are underutilized and there are no errors in the logs.

       

      Note: We have tried with both NIO as well as the legacy / old IO. This has been tried both with HornetQ-2.2.5-Final and HornetQ-2.2.5-GA (this was built from source)

       

      Any idea as to what might be causing this issue and what the resolution might be?

       

      Other observations: It looks like the messages are being sent through the core bridge are transactional ... so is it possible to batch these transactions and have the communication between the two HornetQ instances happen asynchronously?