Azure client message receiver not thread safe ?

[boly38]

Hi all
When using azure java SDK ServiceBus client (version 0.9.3), sometime I receive no message when the queue (or topic) is not empty.
(I'm not 100% sure that this issue is the same as issue #644 so that's why I created this new issue).

I try to reproduce this behavior multiple times without success but I finally find a way to reproduce it by applying a parallel procedure.

I have created a dedicated project to reproduce the issue. feel free to clone, build, start and comment the following project : https://github.com/boly38/azurejavasdk-queue-test

This project main class demonstrates that sending and receiving messages on a azure bus queue works well in sequence but not in parallel.

#### test_client_sequence
(...)
ERROR COUNT=0
#### test_client_parallel
(...)
ERROR COUNT=5

Could you tell me if I'm wrong somewhere or else when do you plan to fix it ?
Maybe there is a more recent version than 0.9.3 but I am not able to find it on search.maven.org ?

[jianghaolu]

Adding owner of the service bus library: @djrosanova

[boly38]

Summary of discussion with Microsoft Azure support

• That part of the SDK (azure-sdk-for-java 0.9.3 that use http) is not maintained anymore

• Microsoft is creating a supported Java SDK created and owned by the Service bus team that foots on AMQP.

  The Event Hub client version is already available, we have no firm ETA for the Service Bus Messaging version.

  • https://github.com/Azure/azure-event-hubs/tree/master/java

  AMQP related links :

  • https://qpid.apache.org/documentation.html
  • https://azure.microsoft.com/en-us/documentation/articles/service-bus-java-how-to-use-jms-api-amqp/

• new SDK announce will be on this blog (like event hub announce) :

  • https://azure.microsoft.com/en-us/blog/have-some-java-with-your-event-hub/

In my case performance issue were due to "partitioning" feature.
I didn't reproduce the issue with a non partitioned entity.

Details about partitioned entities : https://azure.microsoft.com/en-us/documentation/articles/service-bus-partitioning/

Partitioned entities could be the reason why you are seeing the slow receive, 
because of the way partitioned entities work internally. 
When you call receive on a partitioned queue all fragments get queried for messages, 
then the first message that is obtained from any of the messaging stores is returned to the receiver. 
Service Bus caches the other messages and returns them when it receives additional receive requests 
but they also have a lock.
So when another thread tries to receive a message it could happen that it simply waits for the lock to timeout.
If you increase the inflow of messages this should not happen, or if you test with only one thread.

(That behavior is so strange for me: I have to wait a lock time for message that I have never heard about before.)

I asked about "batch mode":

does this flag set to true fix that (partitioning-related lock) behavior ?

Answer:

client side batching is currently not supported for HTTP, however the AMQP java based SDK should support this.

From my point of view, this information is enough to close this issue.
Regards

[alvadb]

the service bus client library is not in this repo anymore, so if this is still an issue, it should go there:
https://github.com/azure/azure-service-bus-java