[
https://issues.apache.org/jira/browse/ARTEMIS-908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15867891#comment-15867891
]
Ulf Lilleengen edited comment on ARTEMIS-908 at 2/15/17 2:14 PM:
-----------------------------------------------------------------
After some more testing, I'm still seeing the block/unblock issue even with
this patch, so seems to be some flow control issues left.. The broker says
there is 1 consumer attached and 0 messages in the queue. And even if I
reattach the receiver, the sender is still blocked. If I reattach the sender,
it is working again until the next time the issue occurs.
was (Author: lulf):
After some more testing, I'm still seeing the block/unblock issue even with
this patch. The broker says there is 1 consumer attached and 0 messages in the
queue. And even if I reattach the receiver, the sender is still blocked. If I
reattach the sender, it is working again.
> AMQP flow control misses unblock during heavy load
> --------------------------------------------------
>
> Key: ARTEMIS-908
> URL: https://issues.apache.org/jira/browse/ARTEMIS-908
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP
> Reporter: Ulf Lilleengen
> Assignee: Justin Bertram
> Fix For: 2.0.0
>
>
> I have a benchmarking setup with 1 sender and 1 receiver attached to a
> broker. The broker is configured with BLOCK policy when queue is full, and
> I've deliberately set a low global-max-size to trigger this bug.
> While sending messages, I get tons of these in the Artemis log, due to the
> flow control kicking in:
> 10:46:53,673 WARN [org.apache.activemq.artemis.core.server] AMQ222183:
> Blocking message production on address 'myqueue'; size is currently: 105,456
> bytes; max-size-bytes: -1
> 10:46:53,674 INFO [org.apache.activemq.artemis.core.server] AMQ221046:
> Unblocking message production on address 'myqueue'; size is currently:
> 105,456 bytes; max-size-bytes: -1
> However, usually after running the test for 10-30 seconds, the sender is
> suddenly never unblocked and I have to restart the sender to send more
> messages. Every time I attach the sender, I am able to send messages for
> 10~30 seconds until it stops.
> This happens with different clients, and triggers only if it can send
> messages really fast.
> After inspecting the flow control logic in the AMQP implementation, I noticed
> that there is a missing synchronized block when issuing credits in
> AMQPSessionCallback#offerProducerCredit, which is present in
> ProtonServerReceiverContext#flow (if sessionSPI is null).
> Adding a synchronized block with the connection lock to the function passed
> to store.checkMemory() in AMQPSessionCallback#offerProducerCredit (in the
> same way as in ProtonServerReceiverContext#flow), the sender seems to be
> unblocked correctly. I've been able to run the sender and receiver for 5
> minutes without issues so far.
> I'll submit the patch as a github PR.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
