[
https://issues.apache.org/jira/browse/QPID-7012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15126235#comment-15126235
]
Keith Wall edited comment on QPID-7012 at 4/14/16 1:36 PM:
-----------------------------------------------------------
In the long term, the connection should stop reading if a connection has built
up a backlog of asynchronous transactions that exceeds a certain size. This
will allow the asynchronous work to catch up and (if the client is using
publish confirms) exert back pressure on the producing application. Once the
asynchronous work is caught up the Broker will recommence reading.
For the moment, will will change the Broker to force a sync after completing
the current work for a connection, if non-transaction persistent work was
included in the work. This would have the affect of limiting the amount of
non-transactional persistent work that can accumulate and will mean that
transactions are never delayed too much. This approach will have the
disadvantage that a connection thread is tied up.
was (Author: k-wall):
One possibility is that the Broker should force a sync after completing the
current work for a connection, if non-transaction persistent work was included
in the work. This would have the affect of limiting the amount of
non-transactional persistent work that can accumulate and will mean that
transactions are never delayed too much.
> Connections producing lots of non-transactional persistent messages can cause
> other transactions to be delayed/time out
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: QPID-7012
> URL: https://issues.apache.org/jira/browse/QPID-7012
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Reporter: Keith Wall
> Fix For: qpid-java-6.1
>
>
> Work mixes that include
> * connection producing large numbers of persistent messages *without*
> transactions
> * transactional work
> may see timeouts in some situations.
> In the HA case, the non-transaction messages are sent to the replicas lazily,
> so all replicas may get behind. This means the a transaction will need to
> wait for the replicas catch up before its transaction completes.
> In the non-HA (and HA on the master), the commit related to the transactional
> work may queue behind the commit jobs related to the non-transactional work.
> This problem affects only publishes using unconfirmed publishes, currently
> the defect for AMQP 0-8..0-91 on in the Java Client.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
