Code for Issues #301 & #112 (dev pull) #327
Conversation
retrieving Message on Empty Queue Add test cases when Retrieving from Empty Queue in both RECEIVE/DELETE and PEEK/LOCK modes. Update existing test to be compatible with receiving null BrokeredMessage instead of uninitialized one.
|
new pull request from dev (instead of master) |
|
@BillAtPros have u signed the CLA? |
|
YES. See guangyang's last comment here |
|
gr8! |
| @@ -183,6 +183,11 @@ else if (options.isPeekLock()) { | |||
| throw new RuntimeException("Unknown ReceiveMode"); | |||
| } | |||
|
|
|||
| //Empty Queue scenario | |||
There was a problem hiding this comment.
According to MSDN, 204 means "No messages available within the specified timeout period.". If we document, it will be good to use this text. 204 could mean the queue is empty, but it can also mean there are message in the queue but locked. http://msdn.microsoft.com/en-us/library/windowsazure/hh780735.aspx
There was a problem hiding this comment.
Good point and agreed.How bout...
\No Messages Available scenario
This covers Empty as well as Messages Present but Locked.
We may also want to add a unit test to cover the Messages Present but Locked case.
|
One comment left, the rest LGTM. |
|
Responded to your comment. Let me know if you want me to make the changes and resubmit the pull. |
|
Thanks @BillAtPros , I think you can just made the change, push the change to BillAtPros:dev, afterwards, the pull request will be updated magically by github. |
retrieving Message on Empty Queue Add test cases when Retrieving from Empty Queue in both RECEIVE/DELETE and PEEK/LOCK modes. Update existing test to be compatible with receiving null BrokeredMessage instead of uninitialized one.
https://github.com/BillAtPros/azure-sdk-for-java.git into dev Conflicts: microsoft-azure-api/src/main/java/com/microsoft/windowsazure/services/serviceBus/implementation/ServiceBusRestProxy.java
|
I've really jacked up my repository during a merge (which I can't understand why it was required). cf7b4b6 looks good. Pull ASAP so I can kill my fork. I've spent way too much time jacking with this. Thanks |
|
Hi @BillAtPros , it seems you are also changling line endings of a lot of files. Those need to be reverted. It seems now 675 files are changed. Sorry about that, but otherwise it will make other developers to revert those unexpected changes. Thanks for understanding. |
|
can we revert e81332d? |
|
I've been trying off and on for hours. I'm a git newbie and have a day job. If you can revert it, go crazy. Otherwise, I'll probably end up deleting my fork and doing the changes AGAIN, rather than struggling with git for another 5 hours. |
|
I can help with reverting if you'd like. |
|
it would be much appreciated |
|
No worry, I will take care of it this time. |
|
Much appreciate. I'll do better next time, I promise. |
|
@BillAtPros, I just sent you a PR against your branch which should detangle your repo and fix this PR. Please let me know if it works. You should be able to merge it and then this PR will be automatically updated. You should probably test it first though in case I grabbed the wrong side of the merge. |
|
@christav I am taking care of it. |
|
a separated pull request from me had addressed this issue. close this one. 2fe266a |
API returns HTTP Status Code 204 when Queue is empty. In this case
calling getValue() on the ReceiveQueueMessageResult will return null.
Changed ServiceBusRestProxy:receiveMessage() now returns a null BrokeredMessage from the getValue() call in cases where the REST call returns a 204 Status Code, which indicates the Queue is empty and remained empty until recieveMessage() call times out.
Tests added in ServiceBusIntegrationTest to test empty Queues in both Receive/Delete and Peek/Lock scenarios. Updated peekLockedMessageCanBeDeleted() to function with null BrokeredMessage returned in empty Queue scenario.