Open bosegeorge1212 opened 1 week ago
Thank you for your feedback. Tagging and routing to the team member best able to assist.
Hi @bosegeorge1212 ,
I am seeing this line in your logs which shows up after retries are done.
2024-07-02 17:57:17,883 - azure.servicebus.aio._base_handler_async - INFO - 'servicebus.pysdk-22e5f6be' operation has exhausted retry. Last exception: ServiceBusConnectionError('Can not read frame due to exception: [Errno 104] Connection reset by peer Error condition: amqp:socket-error.').
It seems like the connection is dropping. Are you able to provide us debug logging with frames turned on please?
logging_enable=True
is also key here for us to see the exchange of information between client and sdk
import logging
import sys
handler = logging.StreamHandler(stream=sys.stdout)
logger = logging.getLogger('azure.servicebus')
logger.setLevel(logging.DEBUG)
logger.addHandler(handler)
...
from azure.servicebus import ServiceBusClient
client = ServiceBusClient(..., logging_enable=True)
Hi @kashifkhan
i have already added it and the above logs are with that. Thanks in advance
logger.setLevel(logging.DEBUG)
ServiceBusClient.from_connection_string(conn_str=connection_string, logging_enable=True)
Hi @bosegeorge1212 - It looks like all retries have been exhausted as per:
2024-07-02 17:57:17,883 - azure.servicebus.aio._base_handler_async - INFO - 'servicebus.pysdk-22e5f6be' operation has exhausted retry. Last exception: ServiceBusConnectionError('Can not read frame due to exception: [Errno 104] Connection reset by peer Error condition: amqp:socket-error.').
The last retry raised an exception due to connection drop as @kashifkhan mentioned, which is expected behavior. By default, the operation is retried 3 times. The first couple of retries are not included in the log snippet above. To confirm that all retries failed due to connection dropping, would you be able to provide logs beginning from before this exception started occurring?
If you'd like to modify default retry behavior, you can adjust retry configs, listed [here].
Hi @bosegeorge1212. 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.
@swathipil
Is there any way to identify the root cause of the connection loss? It appears to be a recurring pattern where the connection is lost every 10-15 hours of no messages.
We are hosting the application in Azure Container Apps and utilizing a VNET as well.
@bosegeorge1212 ServiceBusConnectionErrors are caused by transient network issues or service problems. However, this error is not returned by the service, as they would provide more information such as a tracking ID or a message to retry. This is an error raised by the OS to indicate that the connection dropped. Given that it's not able to reconnect on retry, it seems that it was disconnected for a while.
Is there other activity happening on your VNET (heavier than usual) that could be causing issues?
In order to provide more assistance, we would also need the full logs including all retries.
Hi @bosegeorge1212. 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.
@swathipil I have added the logs. I tried to color the start and end of the error in yellow.
Is there any other activity happening on your VNET (heavier than usual) that could be causing issues? -> Nothing as far as we know.
Thanks @bosegeorge1212. We'll investigate and get back to you asap.
Describe the bug We are getting the following error while receiving messages from Service Bus: azure.servicebus.exceptions.ServiceBusConnectionError: Cannot read frame due to exception: [Errno 104] Connection reset by peer. Error condition: amqp:socket-error.
We observe this behavior when there are no messages in the subscription and you keep the app running.
To Reproduce There are no exact steps to reproduce this issue. It happens inconsistently. We observe this happening when there are no messages in the subscription, and the app has been running for a long duration.
Expected behavior The SDK should retry with some delay.
Logs
this is the code snippet inside a package
and this is code snippet inside our API that invoke the above