[jira] [Commented] (ARTEMIS-4472) Diverts block when target address is not blocked

2023-10-25 Thread Josh Reagan (Jira) 


[ 
https://issues.apache.org/jira/browse/ARTEMIS-4472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17779587#comment-17779587
 ] 

Josh Reagan commented on ARTEMIS-4472:
--

Thanks for taking a look [~jbertram]. I think documenting would be acceptable 
solution. Certainly preferred over anything that would negatively impact 
performance. That said, can you think of any way to modify a message's routing 
before it hits an address? The only thing I could think of was an interceptor. 
But I'm not crazy about that solution as they're protocol dependent.

> Diverts block when target address is not blocked
> 
>
> Key: ARTEMIS-4472
> URL: https://issues.apache.org/jira/browse/ARTEMIS-4472
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: Broker
>Affects Versions: 2.31.0
>Reporter: Josh Reagan
>Priority: Minor
>
> When using an exclusive divert with an {{address-full-policy}} set to 
> {{BLOCK}}, the divert will become blocked when the source address reaches its 
> limit. This happens even if the target address has space and is not blocked. 
> For instance, if I have an address {{app.source-addr}}, and a divert picking 
> up select messages from that source address and routing them to 
> {{app.target-addr}}. If the address {{app.source-addr}} becomes full and 
> blocks, producers are no longer able to send messages. Even though the 
> messages they sent would be routed to the {{app.target-addr}}, and that 
> address still has space available.
> Sample config:
> {code:xml}
> 
>   
>     5
>     BLOCK
>   
> 
> 
>   
>     
>   
> 
> 
>   
>     app.source-addr
>     app.target-addr
>     true
>   
> 
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (ARTEMIS-4473) Diverts do not block when target address is full

2023-10-24 Thread Josh Reagan (Jira) 
Josh Reagan created ARTEMIS-4473:


 Summary: Diverts do not block when target address is full
 Key: ARTEMIS-4473
 URL: https://issues.apache.org/jira/browse/ARTEMIS-4473
 Project: ActiveMQ Artemis
  Issue Type: Bug
  Components: Broker
Affects Versions: 2.31.0
Reporter: Josh Reagan


When a message arrives on a source address, and is diverted to a target 
address, the message will be routed to the target address even if that target 
address is full and its address-full-policy is set to BLOCK. So if I have an 
address "app.source-addr" which has space available. I can send messages to it 
without issue. If that address has a divert configured to route the messages to 
"app.target-addr", they will be routed to that target address without issue. 
Even if "app.target-addr" is full and is blocked.

 

Sample config:

  
    5
    BLOCK
  



  
    
  



  
    app.source-addr
    app.target-addr
    true
  




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (ARTEMIS-4472) Diverts block when target address is not blocked

2023-10-24 Thread Josh Reagan (Jira) 
Josh Reagan created ARTEMIS-4472:


 Summary: Diverts block when target address is not blocked
 Key: ARTEMIS-4472
 URL: https://issues.apache.org/jira/browse/ARTEMIS-4472
 Project: ActiveMQ Artemis
  Issue Type: Bug
  Components: Broker
Affects Versions: 2.31.0
Reporter: Josh Reagan


When using an exclusive divert with an address-full-policy set to BLOCK, the 
divert will become blocked when the source address reaches its limit. This 
happens even if the target address has space and is not blocked. For instance, 
if I have an address "app.source-addr", and a divert picking up select messages 
from that source address and routing them to "app.target-addr". If the address 
"app.source-addr" becomes full and blocks, producers are no longer able to send 
messages. Even though the messages they sent would be routed to the 
"app.target-addr", and that address still has space available.

 

Sample config:

 
{code:java}

  
    5
    BLOCK
  



  
    
  



  
    app.source-addr
    app.target-addr
    true
  

{code}
 

 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (ARTEMIS-450) Deadlocked broker

2016-09-14 Thread Josh Reagan (JIRA) 

[ 
https://issues.apache.org/jira/browse/ARTEMIS-450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15490696#comment-15490696
 ] 

Josh Reagan commented on ARTEMIS-450:
-

This also seems to happen when consuming a large number of messages. Once the 
broker starts spitting out the "AMQ222174: Queue jms.queue.TEST.FOO, on 
address=jms.queue.TEST.FOO, is taking too long to flush deliveries. Watch out 
for frozen clients." message, it has to be restarted to get back to an 
operational state.

> Deadlocked broker
> -
>
> Key: ARTEMIS-450
> URL: https://issues.apache.org/jira/browse/ARTEMIS-450
> Project: ActiveMQ Artemis
>  Issue Type: Bug
>  Components: AMQP, Broker
>Affects Versions: 1.2.0
>Reporter: Gordon Sim
> Attachments: stack-dump.txt, thread-dump-1.3.txt
>
>
> Not sure exactly how it came about, I noticed it on trying to shutdown the 
> broker. The log has:
> {noformat}
> 21:43:17,985 WARN  [org.apache.activemq.artemis.core.server] AMQ222174: Queue 
> examples, on address=myqueue, is taking too long to flush deliveries. Watch 
> out for frozen clients.
> 21:43:18,986 WARN  [org.apache.activemq.artemis.core.server] AMQ222174: Queue 
> examples, on address=myqueue, is taking too long to flush deliveries. Watch 
> out for frozen clients.
> 21:43:19,986 WARN  [org.apache.activemq.artemis.core.server] AMQ222174: Queue 
> examples, on address=myqueue, is taking too long to flush deliveries. Watch 
> out for frozen clients.
> 21:43:20,986 WARN  [org.apache.activemq.artemis.core.server] AMQ222174: Queue 
> examples, on address=myqueue, is taking too long to flush deliveries. Watch 
> out for frozen clients.
> 21:43:28,928 WARN  [org.apache.activemq.artemis.core.server] AMQ222174: Queue 
> examples, on address=myqueue, is taking too long to flush deliveries. Watch 
> out for frozen clients.
> 21:43:45,937 WARN  [org.apache.activemq.artemis.core.server] AMQ222174: Queue 
> examples, on address=myqueue, is taking too long to flush deliveries. Watch 
> out for frozen clients.
> 21:44:18,698 WARN  [org.apache.activemq.artemis.core.client] AMQ212037: 
> Connection failure has been detected: AMQ119014: Did not receive data from 
> /127.0.0.1:51232. It is likely the client has exited or crashed without 
> closing its connection, or the network between the server and client has 
> failed. You also might have configured connection-ttl and 
> client-failure-check-period incorrectly. Please check user manual for more 
> information. The connection will now be closed. [code=CONNECTION_TIMEDOUT]
> 21:44:18,698 WARN  [org.apache.activemq.artemis.core.server] AMQ222061: 
> Client connection failed, clearing up resources for session 
> ebd714e5-efad-11e5-83fc-fe540024bf8d
> Exception in thread "Thread-0 
> (ActiveMQ-AIO-poller-pool2081191879-2061347276)" java.lang.Error: 
> java.io.IOException: Error while submitting IO: Interrupted system call
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1148)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: Error while submitting IO: Interrupted system 
> call
>   at org.apache.activemq.artemis.jlibaio.LibaioContext.blockedPoll(Native 
> Method)
>   at 
> org.apache.activemq.artemis.jlibaio.LibaioContext.poll(LibaioContext.java:360)
>   at 
> org.apache.activemq.artemis.core.io.aio.AIOSequentialFileFactory$PollerRunnable.run(AIOSequentialFileFactory.java:355)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   ... 2 more
> {noformat}
> I'll attach a thread dump in which you will see Thread-10 has locked the 
> handler lock in AbstractConnectionContext
> (part of the 'proton plug'), and is itself blocked on the lock in
> ServerConsumerImpl, which is held by Thread-21. Thread-21 is waiting
> for a write lock on the deliveryLock in ServerConsumerImpl. However
> Thread-20 already has a read lock on this, and is blocked (while
> holding the read lock) on the same handler lock within the proton plug
> (object 0xf3d2bd90) that Thread-10 has locked.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)