qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Rudyy (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (QPID-7505) [Java Client,0-10] The subsequenct synchronous #recieve(long) might return null even when there are messages on the queue
Date Thu, 25 May 2017 12:58:04 GMT

     [ https://issues.apache.org/jira/browse/QPID-7505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Alex Rudyy updated QPID-7505:
-----------------------------
    Description: 
As part of changes made for QPID-1642 the functionality of BasicMessageConsumer_0_10#receive(long)
was changed to force message delivery by sending message.flush when there is no message present
locally in a consumer queue. The message.flush is followed by the message.flow to restore
the credit as  message.flush forces the broker to exhaust its credit supply making it zero
when message.flush command completes. However, no sync is sent after sending message flow.
As result, in some cases the credit is not restored promptly impacting various messaging scenarios
when message is published immediately after receive() is called but the published message
is delivered to another consumer because credits are not restored after message.flush

This problem was detected by the sporadic failure of ConsumerPriorityTest on the 0-10 path.

  was:
As part of changes made for QPID-1642 the functionality of BasicMessageConsumer_0_10#receive(long)
was changed to force message delivery by sending message.flush when there is no message present
locally in a consumer queue. The message.flush is followed by the message.flow to restore
the credit as  message.flush forces the sender to exhaust his credit supply making it zero
when message.flush command completes. However, no sync is sent after sending message flow.
As result, in some cases the credit is not restored promptly impacting various messaging scenarios
when message is published immediately after receive() is called but the published message
is delivered to another consumer because credits are not restored after message.flush

This problem was detected by the sporadic failure of ConsumerPriorityTest on the 0-10 path.


> [Java Client,0-10] The subsequenct synchronous #recieve(long) might return null even
when there are messages on the queue
> -------------------------------------------------------------------------------------------------------------------------
>
>                 Key: QPID-7505
>                 URL: https://issues.apache.org/jira/browse/QPID-7505
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Client
>    Affects Versions: 0.18, 0.20, 0.22, 0.24, 0.26, 0.28, 0.30, 0.32, qpid-java-6.0, qpid-java-6.0.1,
qpid-java-6.0.2, qpid-java-6.0.3, qpid-java-6.0.4, qpid-java-6.0.5, qpid-java-6.1
>            Reporter: Alex Rudyy
>            Assignee: Keith Wall
>             Fix For: qpid-java-6.0.7, qpid-java-client-0-x-6.3.0, qpid-java-6.1.3
>
>
> As part of changes made for QPID-1642 the functionality of BasicMessageConsumer_0_10#receive(long)
was changed to force message delivery by sending message.flush when there is no message present
locally in a consumer queue. The message.flush is followed by the message.flow to restore
the credit as  message.flush forces the broker to exhaust its credit supply making it zero
when message.flush command completes. However, no sync is sent after sending message flow.
As result, in some cases the credit is not restored promptly impacting various messaging scenarios
when message is published immediately after receive() is called but the published message
is delivered to another consumer because credits are not restored after message.flush
> This problem was detected by the sporadic failure of ConsumerPriorityTest on the 0-10
path.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org


Mime
View raw message