Uploaded image for project: 'AMQ Broker'
  1. AMQ Broker
  2. ENTMQBR-1023

Address settings should not apply to internal broker queues/addresses

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Major Major
    • None
    • AMQ 7.0.3.GA
    • clustering
    • None
    • Workaround Exists
    • Hide

      Broker 1 and Broker 2 are clustered, say with jgroups or udp (tested with both).

      Set the following on each:

             <address-setting match="#">
            <dead-letter-address>DLQ</dead-letter-address>
            <expiry-address>ExpiryQueue</expiry-address>
            <redelivery-delay>0</redelivery-delay>
            <redistribution-delay>0</redistribution-delay>
            <!-- with -1 only the global-max-size is in use for limiting -->
            <max-size-bytes>-1</max-size-bytes>
            <message-counter-history-day-limit>10</message-counter-history-day-limit>
            <address-full-policy>PAGE</address-full-policy>
            <auto-create-queues>false</auto-create-queues>
            <auto-create-addresses>false</auto-create-addresses>
         </address-setting>

      Start up both brokers.
      Noticed no clustered bridge logging
      Notice constant logging like above, may take 30 seconds to 1 min to start. However, there after it does not stop.

      Show
      Broker 1 and Broker 2 are clustered, say with jgroups or udp (tested with both). Set the following on each: <address-setting match= "#" > <dead-letter-address> DLQ </dead-letter-address> <expiry-address> ExpiryQueue </expiry-address> <redelivery-delay> 0 </redelivery-delay> <redistribution-delay> 0 </redistribution-delay> <!-- with -1 only the global-max-size is in use for limiting --> <max-size-bytes> -1 </max-size-bytes> <message-counter-history-day-limit> 10 </message-counter-history-day-limit> <address-full-policy> PAGE </address-full-policy> <auto-create-queues> false </auto-create-queues> <auto-create-addresses> false </auto-create-addresses> </address-setting> Start up both brokers. Noticed no clustered bridge logging Notice constant logging like above, may take 30 seconds to 1 min to start. However, there after it does not stop.

      Brokers that are clusterd with address setting match='#' with auto create for queues and topics to false results in no clustering and constant logging of this sort:

      12:25:50,530 WARN [org.apache.activemq.artemis.core.client] AMQ212037: Connection failure has been detected: AMQ119014: Did not receive data from /127.0.0.1:42562 within the 60,000ms connection TTL. The connection will now be closed. [code=CONNECTION_TIMEDOUT]
      12:25:50,531 WARN [org.apache.activemq.artemis.core.server] AMQ222061: Client connection failed, clearing up resources for session a2a6542c-0b62-11e8-a683-185e0fcdacdf
      12:25:50,531 WARN [org.apache.activemq.artemis.core.server] AMQ222107: Cleared up resources for session a2a6542c-0b62-11e8-a683-185e0fcdacdf
      12:25:50,531 WARN [org.apache.activemq.artemis.core.server] AMQ222061: Client connection failed, clearing up resources for session a2a67b3d-0b62-11e8-a683-185e0fcdacdf
      12:25:50,531 WARN [org.apache.activemq.artemis.core.server] AMQ222107: Cleared up resources for session a2a67b3d-0b62-11e8-a683-185e0fcdacdf

              rh-ee-ataylor Andy Taylor
              rhn-gps-mcochran Mary Cochran (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

                Created:
                Updated:
                Resolved: