- 
    
Bug
 - 
    Resolution: Done
 - 
    
Major
 - 
    None
 - 
    None
 
I have a qpid dispatch router connected to an artemis broker. The broker has a queue defined on it and the router is configured to forward incoming messages through this and to pull messages out of the queue when needed for receivers. I have a sender and receiver connected to the router and am sending messsages as fast as possible.
My broker config includes:
      <address-settings>
         <!--default for catch all-->
         <address-setting match="#">
            <dead-letter-address>jms.queue.DLQ</dead-letter-address>
            <expiry-address>jms.queue.ExpiryQueue</expiry-address>
            <redelivery-delay>0</redelivery-delay>
            <max-size-bytes>10485760</max-size-bytes>
            <message-counter-history-day-limit>10</message-counter-history-day-limit>
            <address-full-policy>BLOCK</address-full-policy>
         </address-setting>
      </address-settings>
      <queues>
          <queue name="examples">
             <address>examples</address>
          </queue>
          <queue name="queue">
             <address>queue</address>
          </queue>
      </queues>
   </core>
Running with the default profile, -Xms512M -Xmx1024M, I get an OutOfMemoryError (with an odd stack trace to my eye):
Exception in thread "Thread-27 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@140e5a13-1032000752)" java.lang.OutOfMemoryError: GC overhead limit exceeded at java.util.Arrays.copyOfRange(Arrays.java:3664) at java.lang.String.<init>(String.java:207) at java.lang.StringBuilder.toString(StringBuilder.java:407) at java.net.URLStreamHandler.parseURL(URLStreamHandler.java:249) at sun.net.www.protocol.file.Handler.parseURL(Handler.java:67) at java.net.URL.<init>(URL.java:622) Exception: java.lang.OutOfMemoryError thrown from the UncaughtExceptionHandler in thread "Thread-27 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2@140e5a13-1032000752)"
My expectation was that the size limit and full-policy in the address-settings would apply to 'queue' and so the sender (which would be the router) would be flow controlled. This seems not to be the case.
- is blocked by
 - 
                    
ENTMQBR-419 Release 7.0.0.ER9 with Hand Off document
-         
 - Closed
 
 -         
 
- is duplicated by
 - 
                    
ENTMQBR-160 '<address-full-policy>BLOCK</...> doesn't work with non core protocols
-         
 - Closed
 
 -