You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Rajith Attapattu (JIRA)" <qp...@incubator.apache.org> on 2010/04/29 19:21:53 UTC
[jira] Created: (QPID-2559) When a subscription is created, message
credits should only be set if the session is active.
When a subscription is created, message credits should only be set if the session is active.
--------------------------------------------------------------------------------------------
Key: QPID-2559
URL: https://issues.apache.org/jira/browse/QPID-2559
Project: Qpid
Issue Type: Bug
Components: C++ Client
Affects Versions: 0.6
Reporter: Rajith Attapattu
Assignee: Rajith Attapattu
Fix For: 0.7
When a subscription is created, message credits should only be set if the session is active.
If not when the session is unsuspended message credits will be set again, resulting in granting more credits than intended.
Steps To Reproduce
----------------------------
1. create a session with client ack
2. send 20 messages to a queue
3. create receiver with capacity (prefetch) as 10.
4. receive 10 messages
5. try to receive the 11th message
The 11th message should be null, if it isn't it means that we have received more than 10 messages.
We should only receive the next set of messages if we ack the previous batch.
Ex. If we acked the 5th message, then we should get another 5.
Expected Result.
------------------------
At any given time we should only receive n messages, where n == maxprefetch (capacity as defined for the destination)
Actual Result
-------------------
For the above conditions, we get double than what we want (provided the broker has enough messages on the queue).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2559) When a subscription is created,
message credits should only be set if the dispatcher is not null.
Posted by "Rajith Attapattu (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868770#action_12868770 ]
Rajith Attapattu commented on QPID-2559:
----------------------------------------
Martin,
I checked in a fix for AMQConnectionTest#testPrefetchSystemProperty() to work with both the 0-8 and 0-10 codepaths.
I think it's best if we leave that as a test for testing the system prop instead of using as a test for the issue raised in this JIRA.
I think we should write some specialized test cases around capacity (aka prefetch. aka consumer flow control) to test this issue and QPID-2604
Actually I have some test cases in my local and these issues were identified as a result of running those test cases.
I don't think we have any existing tests around capacity. So I am hoping to add some today.
If you have any further ideas please feel free to add more tests.
I will use your patch when creating the new test cases.
Rajith
> When a subscription is created, message credits should only be set if the dispatcher is not null.
> -------------------------------------------------------------------------------------------------
>
> Key: QPID-2559
> URL: https://issues.apache.org/jira/browse/QPID-2559
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
> Affects Versions: 0.6
> Reporter: Rajith Attapattu
> Assignee: Rajith Attapattu
> Fix For: 0.7
>
> Attachments: QPID-2559.test
>
>
> When a subscription is created, message credits should only be set if the dispatcher is not null.
> If the dispatcher is null, the session is suspended temporarily until a dispatcher is created.
> And then when the session is unsuspended, message credits will be set again, resulting in granting more credits than intended.
> Please note in order for this error condition to happen the dispatcher should be null and the broker should have enough messages.
> If the connection is not started and the message consumer is the very first to be created for that session, then the dispatcher thread for that session is null.
> Steps To Reproduce
> ----------------------------
> 1. create connection, but not start it
> 1. create a session with client ack
> 2. send 20 messages to a queue
> 3. create receiver with capacity (prefetch) as 10.
> 4. start connection.
> 5. receive 10 messages
> Look at the client and broker logs and observe that the broker sends more messages than needed.
> Expected Result.
> ------------------------
> At any given time we should only receive n messages, where n == maxprefetch (capacity as defined for the destination)
> Actual Result
> -------------------
> For the above conditions, we get double than what we want (provided the broker has enough messages on the queue).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Updated: (QPID-2559) When a subscription is created, message
credits should only be set if the dispatcher is not null.
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie updated QPID-2559:
---------------------------------
Attachment: QPID-2559.test
Hi Rajith,
The AMQConnectionTest is still failing. Not sure if you noticed your actually using transacted sessions on your consumers.
I've attached an updated test that tests your example client ack scenario.
I have included the transacted scenario you were testing.
The client-ack test case works on all java profiles.(default,java,java.0.10)
The transacted case failes on 0.10, it appears that MAX_PREFTECH is being ignored by the java broker.
The cpp doesn't currently build on my desktop. Do attached tests accurately represent your problem?
Would be good to exclude the current test as it fails on on 0.10 code paths. Client A is not guaranteed to get 2 messages. But one of them A or B will.
> When a subscription is created, message credits should only be set if the dispatcher is not null.
> -------------------------------------------------------------------------------------------------
>
> Key: QPID-2559
> URL: https://issues.apache.org/jira/browse/QPID-2559
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
> Affects Versions: 0.6
> Reporter: Rajith Attapattu
> Assignee: Rajith Attapattu
> Fix For: 0.7
>
> Attachments: QPID-2559.test
>
>
> When a subscription is created, message credits should only be set if the dispatcher is not null.
> If the dispatcher is null, the session is suspended temporarily until a dispatcher is created.
> And then when the session is unsuspended, message credits will be set again, resulting in granting more credits than intended.
> Please note in order for this error condition to happen the dispatcher should be null and the broker should have enough messages.
> If the connection is not started and the message consumer is the very first to be created for that session, then the dispatcher thread for that session is null.
> Steps To Reproduce
> ----------------------------
> 1. create connection, but not start it
> 1. create a session with client ack
> 2. send 20 messages to a queue
> 3. create receiver with capacity (prefetch) as 10.
> 4. start connection.
> 5. receive 10 messages
> Look at the client and broker logs and observe that the broker sends more messages than needed.
> Expected Result.
> ------------------------
> At any given time we should only receive n messages, where n == maxprefetch (capacity as defined for the destination)
> Actual Result
> -------------------
> For the above conditions, we get double than what we want (provided the broker has enough messages on the queue).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2559) When a subscription is created,
message credits should only be set if the dispatcher is not null.
Posted by "Rajith Attapattu (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868707#action_12868707 ]
Rajith Attapattu commented on QPID-2559:
----------------------------------------
Minor correction.
The current AMQConnectionTest is working properly with the java.0.10.testprofile.
> When a subscription is created, message credits should only be set if the dispatcher is not null.
> -------------------------------------------------------------------------------------------------
>
> Key: QPID-2559
> URL: https://issues.apache.org/jira/browse/QPID-2559
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
> Affects Versions: 0.6
> Reporter: Rajith Attapattu
> Assignee: Rajith Attapattu
> Fix For: 0.7
>
> Attachments: QPID-2559.test
>
>
> When a subscription is created, message credits should only be set if the dispatcher is not null.
> If the dispatcher is null, the session is suspended temporarily until a dispatcher is created.
> And then when the session is unsuspended, message credits will be set again, resulting in granting more credits than intended.
> Please note in order for this error condition to happen the dispatcher should be null and the broker should have enough messages.
> If the connection is not started and the message consumer is the very first to be created for that session, then the dispatcher thread for that session is null.
> Steps To Reproduce
> ----------------------------
> 1. create connection, but not start it
> 1. create a session with client ack
> 2. send 20 messages to a queue
> 3. create receiver with capacity (prefetch) as 10.
> 4. start connection.
> 5. receive 10 messages
> Look at the client and broker logs and observe that the broker sends more messages than needed.
> Expected Result.
> ------------------------
> At any given time we should only receive n messages, where n == maxprefetch (capacity as defined for the destination)
> Actual Result
> -------------------
> For the above conditions, we get double than what we want (provided the broker has enough messages on the queue).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2559) When a subscription is created,
message credits should only be set if the dispatcher is not null.
Posted by "Rajith Attapattu (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868791#action_12868791 ]
Rajith Attapattu commented on QPID-2559:
----------------------------------------
I was as blind as a bat there. I completely missed that !
I will fix the code to set it to "false".
I think I need to investigate why the original test didn't work when the ack mode was transacted.
Th credits should not have been replenished unless session.commit() was called.
> When a subscription is created, message credits should only be set if the dispatcher is not null.
> -------------------------------------------------------------------------------------------------
>
> Key: QPID-2559
> URL: https://issues.apache.org/jira/browse/QPID-2559
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
> Affects Versions: 0.6
> Reporter: Rajith Attapattu
> Assignee: Rajith Attapattu
> Fix For: 0.7
>
> Attachments: QPID-2559.test
>
>
> When a subscription is created, message credits should only be set if the dispatcher is not null.
> If the dispatcher is null, the session is suspended temporarily until a dispatcher is created.
> And then when the session is unsuspended, message credits will be set again, resulting in granting more credits than intended.
> Please note in order for this error condition to happen the dispatcher should be null and the broker should have enough messages.
> If the connection is not started and the message consumer is the very first to be created for that session, then the dispatcher thread for that session is null.
> Steps To Reproduce
> ----------------------------
> 1. create connection, but not start it
> 1. create a session with client ack
> 2. send 20 messages to a queue
> 3. create receiver with capacity (prefetch) as 10.
> 4. start connection.
> 5. receive 10 messages
> Look at the client and broker logs and observe that the broker sends more messages than needed.
> Expected Result.
> ------------------------
> At any given time we should only receive n messages, where n == maxprefetch (capacity as defined for the destination)
> Actual Result
> -------------------
> For the above conditions, we get double than what we want (provided the broker has enough messages on the queue).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2559) When a subscription is created,
message credits should only be set if the dispatcher is not null.
Posted by "Robbie Gemmell (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868781#action_12868781 ]
Robbie Gemmell commented on QPID-2559:
--------------------------------------
>Hi Martin,
>I am a little confused about your comment - "Not sure if you noticed your actually using transacted sessions on your consumers." .
>The consumer session is using AUTO_ACK and now both consumers are created off the same session.
I believe Martin would have been referencing the fact that the test you are modifying uses consumer sessions which are created with the code below, which has transacted = true and thereby ignores the acknowledgeMode parameter as per the JMS spec:
connection.createSession(true, Session.AUTO_ACKNOWLEDGE);
> When a subscription is created, message credits should only be set if the dispatcher is not null.
> -------------------------------------------------------------------------------------------------
>
> Key: QPID-2559
> URL: https://issues.apache.org/jira/browse/QPID-2559
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
> Affects Versions: 0.6
> Reporter: Rajith Attapattu
> Assignee: Rajith Attapattu
> Fix For: 0.7
>
> Attachments: QPID-2559.test
>
>
> When a subscription is created, message credits should only be set if the dispatcher is not null.
> If the dispatcher is null, the session is suspended temporarily until a dispatcher is created.
> And then when the session is unsuspended, message credits will be set again, resulting in granting more credits than intended.
> Please note in order for this error condition to happen the dispatcher should be null and the broker should have enough messages.
> If the connection is not started and the message consumer is the very first to be created for that session, then the dispatcher thread for that session is null.
> Steps To Reproduce
> ----------------------------
> 1. create connection, but not start it
> 1. create a session with client ack
> 2. send 20 messages to a queue
> 3. create receiver with capacity (prefetch) as 10.
> 4. start connection.
> 5. receive 10 messages
> Look at the client and broker logs and observe that the broker sends more messages than needed.
> Expected Result.
> ------------------------
> At any given time we should only receive n messages, where n == maxprefetch (capacity as defined for the destination)
> Actual Result
> -------------------
> For the above conditions, we get double than what we want (provided the broker has enough messages on the queue).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2559) When a subscription is created,
message credits should only be set if the dispatcher is not null.
Posted by "Rajith Attapattu (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868834#action_12868834 ]
Rajith Attapattu commented on QPID-2559:
----------------------------------------
>I think I need to investigate why the original test didn't work when the ack mode was transacted.
>The credits should not have been replenished unless session.commit() was called.
I found the reason. If the session is transacted, we use the "addDeliveredMessage" method in AMQSession_0_10.java to record the non committed messages.
However we use the following heuristic to send completions to replenish credits.
if (_connection.getMaxPrefetch() == 1 ||
_connection.getMaxPrefetch() != 0 && _txSize % (_connection.getMaxPrefetch() / 2) == 0)
{
// send completed so consumer credits don't dry up
messageAcknowledge(_txRangeSet, false);
}
Since we use a prefetch of just 2 messages, we easily triggered the condition, hence we acked after just consuming one message.
That is the reason why consumerA got the other two messages as well (even though the session wasn't committed) before consumerB who was on a different session was able to get those two messages.
> When a subscription is created, message credits should only be set if the dispatcher is not null.
> -------------------------------------------------------------------------------------------------
>
> Key: QPID-2559
> URL: https://issues.apache.org/jira/browse/QPID-2559
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
> Affects Versions: 0.6
> Reporter: Rajith Attapattu
> Assignee: Rajith Attapattu
> Fix For: 0.7
>
> Attachments: QPID-2559.test
>
>
> When a subscription is created, message credits should only be set if the dispatcher is not null.
> If the dispatcher is null, the session is suspended temporarily until a dispatcher is created.
> And then when the session is unsuspended, message credits will be set again, resulting in granting more credits than intended.
> Please note in order for this error condition to happen the dispatcher should be null and the broker should have enough messages.
> If the connection is not started and the message consumer is the very first to be created for that session, then the dispatcher thread for that session is null.
> Steps To Reproduce
> ----------------------------
> 1. create connection, but not start it
> 1. create a session with client ack
> 2. send 20 messages to a queue
> 3. create receiver with capacity (prefetch) as 10.
> 4. start connection.
> 5. receive 10 messages
> Look at the client and broker logs and observe that the broker sends more messages than needed.
> Expected Result.
> ------------------------
> At any given time we should only receive n messages, where n == maxprefetch (capacity as defined for the destination)
> Actual Result
> -------------------
> For the above conditions, we get double than what we want (provided the broker has enough messages on the queue).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Commented: (QPID-2559) When a subscription is created,
message credits should only be set if the dispatcher is not null.
Posted by "Rajith Attapattu (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868696#action_12868696 ]
Rajith Attapattu commented on QPID-2559:
----------------------------------------
Hi Martin,
I am a little confused about your comment - "Not sure if you noticed your actually using transacted sessions on your consumers." .
The consumer session is using AUTO_ACK and now both consumers are created off the same session.
Also I have modified the test in rev 945444 with a detailed explanation (check the svn commits tab on this JIRA) to make sure it works after the change I made in rev 942293.
However this test is now failing when I run it against the java test profile.
This is probably bcos the flow control semantics are different in 0-8 ?
(I also noticed that even when I used java.0.10.testprofile the test output was still using 0-8 - so maybe there is a bug? )
I think the original test case (before my modification in rev 945444) would have been a good test for this bug if CLIENT-ACK or TRANSACTED is used.
As in that case the completions would have only being sent when acked or the transaction committed.
But the original test would fail for AUTO-ACK due to reasons mentioned in commit log for rev 945444.
So perhaps we could have a switch in the test code to create both consumers using the same session if AUTO-ACK and each on it's own session otherwise.
Let me use the code you attached to create the test. Please have a look and see if I have missed anything.
> When a subscription is created, message credits should only be set if the dispatcher is not null.
> -------------------------------------------------------------------------------------------------
>
> Key: QPID-2559
> URL: https://issues.apache.org/jira/browse/QPID-2559
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
> Affects Versions: 0.6
> Reporter: Rajith Attapattu
> Assignee: Rajith Attapattu
> Fix For: 0.7
>
> Attachments: QPID-2559.test
>
>
> When a subscription is created, message credits should only be set if the dispatcher is not null.
> If the dispatcher is null, the session is suspended temporarily until a dispatcher is created.
> And then when the session is unsuspended, message credits will be set again, resulting in granting more credits than intended.
> Please note in order for this error condition to happen the dispatcher should be null and the broker should have enough messages.
> If the connection is not started and the message consumer is the very first to be created for that session, then the dispatcher thread for that session is null.
> Steps To Reproduce
> ----------------------------
> 1. create connection, but not start it
> 1. create a session with client ack
> 2. send 20 messages to a queue
> 3. create receiver with capacity (prefetch) as 10.
> 4. start connection.
> 5. receive 10 messages
> Look at the client and broker logs and observe that the broker sends more messages than needed.
> Expected Result.
> ------------------------
> At any given time we should only receive n messages, where n == maxprefetch (capacity as defined for the destination)
> Actual Result
> -------------------
> For the above conditions, we get double than what we want (provided the broker has enough messages on the queue).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
[jira] Updated: (QPID-2559) When a subscription is created, message
credits should only be set if the dispatcher is not null.
Posted by "Rajith Attapattu (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rajith Attapattu updated QPID-2559:
-----------------------------------
Summary: When a subscription is created, message credits should only be set if the dispatcher is not null. (was: When a subscription is created, message credits should only be set if the session is active.)
Description:
When a subscription is created, message credits should only be set if the dispatcher is not null.
If the dispatcher is null, the session is suspended temporarily until a dispatcher is created.
And then when the session is unsuspended, message credits will be set again, resulting in granting more credits than intended.
Please note in order for this error condition to happen the dispatcher should be null and the broker should have enough messages.
If the connection is not started and the message consumer is the very first to be created for that session, then the dispatcher thread for that session is null.
Steps To Reproduce
----------------------------
1. create connection, but not start it
1. create a session with client ack
2. send 20 messages to a queue
3. create receiver with capacity (prefetch) as 10.
4. start connection.
5. receive 10 messages
Look at the client and broker logs and observe that the broker sends more messages than needed.
Expected Result.
------------------------
At any given time we should only receive n messages, where n == maxprefetch (capacity as defined for the destination)
Actual Result
-------------------
For the above conditions, we get double than what we want (provided the broker has enough messages on the queue).
was:
When a subscription is created, message credits should only be set if the session is active.
If not when the session is unsuspended message credits will be set again, resulting in granting more credits than intended.
Steps To Reproduce
----------------------------
1. create a session with client ack
2. send 20 messages to a queue
3. create receiver with capacity (prefetch) as 10.
4. receive 10 messages
5. try to receive the 11th message
The 11th message should be null, if it isn't it means that we have received more than 10 messages.
We should only receive the next set of messages if we ack the previous batch.
Ex. If we acked the 5th message, then we should get another 5.
Expected Result.
------------------------
At any given time we should only receive n messages, where n == maxprefetch (capacity as defined for the destination)
Actual Result
-------------------
For the above conditions, we get double than what we want (provided the broker has enough messages on the queue).
> When a subscription is created, message credits should only be set if the dispatcher is not null.
> -------------------------------------------------------------------------------------------------
>
> Key: QPID-2559
> URL: https://issues.apache.org/jira/browse/QPID-2559
> Project: Qpid
> Issue Type: Bug
> Components: C++ Client
> Affects Versions: 0.6
> Reporter: Rajith Attapattu
> Assignee: Rajith Attapattu
> Fix For: 0.7
>
>
> When a subscription is created, message credits should only be set if the dispatcher is not null.
> If the dispatcher is null, the session is suspended temporarily until a dispatcher is created.
> And then when the session is unsuspended, message credits will be set again, resulting in granting more credits than intended.
> Please note in order for this error condition to happen the dispatcher should be null and the broker should have enough messages.
> If the connection is not started and the message consumer is the very first to be created for that session, then the dispatcher thread for that session is null.
> Steps To Reproduce
> ----------------------------
> 1. create connection, but not start it
> 1. create a session with client ack
> 2. send 20 messages to a queue
> 3. create receiver with capacity (prefetch) as 10.
> 4. start connection.
> 5. receive 10 messages
> Look at the client and broker logs and observe that the broker sends more messages than needed.
> Expected Result.
> ------------------------
> At any given time we should only receive n messages, where n == maxprefetch (capacity as defined for the destination)
> Actual Result
> -------------------
> For the above conditions, we get double than what we want (provided the broker has enough messages on the queue).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org