-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Peeking message on subscriptions with sessions enabled fails when using NEXT_AVAILABLE_SESSION #30907
Comments
Thank you for the feedback @ManuelEibl . We will investigate and get back to you Just a few follow ups
|
Hi @ManuelEibl. Thank you for opening this issue and giving us the opportunity to assist. To help our team better understand your issue and the details of your scenario please provide a response to the question asked above or the information requested above. This will help us more accurately address your issue. |
No you are right. When there are messages I get the messages. So this means this is intended behavior? I sort of expected that it would not wait at all TBH but simply peek and if there is nothing just return and empty list. Is there another method which I could use to achieve this? Guessing a timeout so that I would not cut off the receiving of a message but still not wait unnecessarily long seems a bit awkward. |
Hi @ManuelEibl, yes this is expected behavior. When there are no messages in a topic subscription and session_id is set to NEXT_AVAILABLE_SESSION, you attempt to connect to the next available session (however since there are no messages there is no available session) this will cause a TimeoutError from the service as the target for the receiving link cannot be established and the peek operation times out. On the other hand if you set a specific session_id (i.e session_id="0") you are specifying the target you are trying to reach and you will receive an empty list because the link is established and the session is shown to have no messages. For the alternate method to use to not have to wait, at the present time there is nothing in our code that supports that but we will investigate and get back to you. |
Thanks for your clarifications. So I wonder what the best flow would be in such a scenario. |
I have now tried passing a timeout to the peek_messages call (e.g. Surely this is not intended is it? I would need to forcefully kill the peek process if I wanted to avoid this. |
Hi @ManuelEibl, sorry for the delayed response. For your second point
This timeout in the peek_messages here works on the operation , where the AMQPLinkError is coming from is from when we are attempting to open the receiver link to the I am currently working on a PR that will add in a timeout that allows you to control how long you want to wait for a session (allowing for a less than 65 second wait time), and I am optimistic that this will help with your issue you described above. |
Hi @l0lawrence ,
Is there a way to handle this exception and monitor 24*7 for session-enabled messages?
|
Hi @sudharsan2020, there is nothing in the SDK that would allow for periodic lookup of sessions. In your own code you could try to receive and except the OperationTimeoutError if any appear and try again. With the PR that is in progress you will be able to specify a smaller timeout and therefore try to receive again sooner. |
Hi @ManuelEibl. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text "/unresolve" to remove the "issue-addressed" label and continue the conversation. |
Hi @ManuelEibl, since you haven’t asked that we |
Describe the bug
When trying to peek a message on a service bus subscriptions where sessions are enabled fails.
The received error is
azure.servicebus._pyamqp.error.AMQPLinkError: Error condition: com.microsoft:timeout
.To Reproduce
Steps to reproduce the behavior:
get_subscription_receiver
on the client instance to get a receiver and pass NEXT_AVAILABLE_SESSION as the sesion_idExpected behavior
Expecting to receive a list of messages on the subscription for the next available session
Additional context
On first glance it sounds like a simple connection issue caused by Azure. However, in a related .Net project we can work with the same sessions by using the Azure.Messaging.ServiceBus.ServiceBusSessionProcessor Class. Therefore, I don't expect it to be a simple temporary connection issue. It also works if using a hard coded session_id such as "abc" which immediately returns a result (e.g. empty list if it does not exist or has no waiting messages).
Therefore, I assume that the usage of NEXT_AVAILABLE_SESSION as session_id causes this issue in some way.
Complete stack trace:
The text was updated successfully, but these errors were encountered: