Очень низкая пропускная способность при использовании основного моста HornetQ

Мы пытаемся использовать механизм хранения и пересылки HornetQ... однако пересылка сообщений от одного автономного экземпляра HornetQ к другому с использованием основного моста происходит очень медленно. Нам не удалось увеличить пропускную способность выше 200 сообщений в секунду.

Удивительным фактом является то, что если мы направляем того же клиента (который публиковал сообщения на пересылающий экземпляр HornetQ) непосредственно на целевой экземпляр HornetQ, мы начинаем наблюдать пропускную способность более 1000 сообщений в секунду (этот клиент основан на JMS). ). В основном это означает, что основной мост, который был настроен между экземпляром Forwarding HornetQ и экземпляром HornetQ назначения, проблематичен.

Ниже приведены соответствующие разделы для настройки основного моста на Forwarding HornetQ:

<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>

Ниже приведены соответствующие разделы для настройки основного моста на Destination HornetQ:

<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.xxx}"/>
         <param key="port"  value="${hornetq.remoting.netty.port:xxxx}"/>
         <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>
<acceptors>
<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>

Все системные переменные (ЦП/Память/Диск) IO/Network/и т. д.) используются недостаточно, и в журналах нет ошибок.

Примечание: Мы пробовали использовать как NIO, так и устаревший/старый IO. Это было опробовано как с HornetQ-2.2.5-Final, так и с HornetQ-2.2.8-GA (2.2.8-GA был создан из исходного кода)

Любые идеи относительно того, что может быть причиной этой проблемы и какое решение может быть?

Другие наблюдения: похоже, что сообщения, отправляемые через основной мост, являются транзакционными... так можно ли группировать эти транзакции и обеспечить асинхронную связь между двумя экземплярами HornetQ?