activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (ARTEMIS-908) AMQP flow control misses unblock during heavy load
Date Wed, 15 Feb 2017 13:36:42 GMT


ASF subversion and git services commented on ARTEMIS-908:

Commit 5f6a390b6098dca1cfda09af4c0af096dfe736c0 in activemq-artemis's branch refs/heads/master
from [~lulf]
[;h=5f6a390 ]

ARTEMIS-908: Ensure that connection lock is held when flushing

> AMQP flow control misses unblock during heavy load
> --------------------------------------------------
>                 Key: ARTEMIS-908
>                 URL:
>             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
> 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

View raw message