Azure-sdk-for-python: An execption during lock renew

Created on 18 Sep 2019  路  35Comments  路  Source: Azure/azure-sdk-for-python

We are reading messages from a Service Bus topic with a variant of the
following code block:

client = SubscriptionClient.from_connection_string(
    connection_string, subscription, loop=loop)
receiver = client.get_receiver()
batch = receiver.fetch_next(max_batch_size=1, timeout=30)
...

but during message renew done in an async loop with
message.renew_lock we are getting the following exception:

Traceback (most recent call last):
  File "/usr/lib/python3.6/site-packages/azure/servicebus/aio/async_base_handler.py", line 90, in _mgmt_request_response
    callback=callback)
  File "/usr/lib/python3.6/site-packages/uamqp/async_ops/client_async.py", line 333, in mgmt_request_async
    **kwargs))
  File "/usr/lib/python3.6/site-packages/uamqp/async_ops/session_async.py", line 114, in mgmt_request_async
    return parse_response(status, response, description)
  File "/usr/lib/python3.6/site-packages/azure/servicebus/common/mgmt_handlers.py", line 28, in lock_renew_op
    status_code, description, message.get_data()))
azure.servicebus.common.errors.ServiceBusError: Management request returned status code: 500. Description: b'Unsupported type 0x40 for array. TrackingId:de1b2df6-7cf4-4c7b-a741-ff6d9e310f71_G24, SystemTracker:NoSystemTracker, Timestamp:2019-09-18T11:41:00', Data: None
Client Service Bus customer-reported
Source
picture Indy2222

Most helpful comment

Actually that is correct - or it least, partially correct.
On the one hand it's strange that deliver_annotations is None - this implies that something has changed in the service. However it would be less of an issue if #4598 was supported.

picture annatisch on 19 Sep 2019
👍2

All 35 comments

@Indy2222 thanks for letting us know, we will take a look at it

kaerm picture kaerm on 18 Sep 2019

I had the same error:

`Failed to complete mgmt operation.
Status code: 500
Message: b'Unsupported type 0x40 for array. TrackingId:7bdddf69-a511-4246-8413-4094e9994a0c_G25, SystemTracker:NoSystemTracker, Timestamp:2019-09-18T16:12:44'
2019-09-18 16:12:44,138 MainThread captura ERROR: Traceback (most recent call last):
File "/usr/local/lib/python3.6/site-packages/azure/servicebus/base_handler.py", line 91, in _mgmt_request_response
callback=callback)
File "/usr/local/lib64/python3.6/site-packages/uamqp/client.py", line 328, in mgmt_request
**kwargs)
File "/usr/local/lib64/python3.6/site-packages/uamqp/session.py", line 126, in mgmt_request
return parse_response(status, response, description)
File "/usr/local/lib/python3.6/site-packages/azure/servicebus/common/mgmt_handlers.py", line 28, in lock_renew_op
status_code, description, message.get_data()))
azure.servicebus.common.errors.ServiceBusError: Management request returned status code: 500. Description: b'Unsupported type 0x40 for array. TrackingId:7bdddf69-a511-4246-8413-4094e9994a0c_G25, SystemTracker:NoSystemTracker, Timestamp:2019-09-18T16:12:44', Data: None

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "/home/primarecaptura/primare_orchestrator/tools/captura_roudtrip/captura-roundtrip.py", line 212, in main
primareMessage.startManaging()
File "/home/primarecaptura/primare_orchestrator/tools/captura_roudtrip/primare_message.py", line 101, in startManaging
self.renewLock()
File "/home/primarecaptura/primare_orchestrator/tools/captura_roudtrip/primare_message.py", line 106, in renewLock
self.queueManager.renewLockMessage(message=self.message)
File "/home/primarecaptura/primare_orchestrator/azure_queue_manager.py", line 246, in renewLockMessage
message.renew_lock()
File "/usr/local/lib/python3.6/site-packages/azure/servicebus/common/message.py", line 303, in renew_lock
expiry = self._receiver._renew_locks(self.lock_token) # pylint: disable=protected-access
File "/usr/local/lib/python3.6/site-packages/azure/servicebus/receive_handler.py", line 141, in _renew_locks
mgmt_handlers.lock_renew_op)
File "/usr/local/lib/python3.6/site-packages/azure/servicebus/base_handler.py", line 93, in _mgmt_request_response
raise ServiceBusError("Management request failed: {}".format(exp), exp)
azure.servicebus.common.errors.ServiceBusError: Management request failed: Management request returned status code: 500. Description: b'Unsupported type 0x40 for array. TrackingId:7bdddf69-a511-4246-8413-4094e9994a0c_G25, SystemTracker:NoSystemTracker, Timestamp:2019-09-18T16:12:44', Data: None`

luipir picture luipir on 18 Sep 2019

this is almost new... the same code worked correctly yesterday. No idea is something changed server side

luipir picture luipir on 18 Sep 2019

Hi @nemakam - can you confirm whether any service updates/changes have been rolled out recently?

annatisch picture annatisch on 18 Sep 2019

In my case the parameter arrived here:
https://github.com/Azure/azure-sdk-for-python/blob/master/sdk/servicebus/azure-servicebus/azure/servicebus/receive_handler.py#L138

are, in order:
b'com.microsoft:renew-lock'
b'entity-mgmt'
{b'lock-tokens': [None]} <<<<--- is it this the problem. would [ ] or none (json encoding) ?
5000

luipir picture luipir on 19 Sep 2019

Thanks @luipir - yeah it looks like an empty array is being sent (0x40 indicates a NULL value).
If we work back up the strack trace you posted above (thank you!) we can see that the messages lock_token attribute appears to be empty...
https://github.com/Azure/azure-sdk-for-python/blob/master/sdk/servicebus/azure-servicebus/azure/servicebus/common/message.py#L237
This would indicate that it's not being returned in the annotation.
My understanding is that there's more than one way to collect a lock token for a message - so maybe we need to investigate the alternative if the delivery annotations are unreliable.
Thoughts @nemakam ?

annatisch picture annatisch on 19 Sep 2019
👍1

setting None as token instead of [None] override the Array error, but obviously can't lock the token returning:
Message: b'The service was unable to process the request; please retry the operation. For more information on exception types and proper exception handling, please refer to http://go.microsoft.com/fwlink/?LinkId=761101 Reference:**, TrackingId:*****, SystemTracker:primare-desa-service-bus:Topic:primare_desa_topic_initplanification|proyestegal_initplanification_suscriber, Timestamp:2019-09-19T14:06:29'

luipir picture luipir on 19 Sep 2019

My understanding is that there's more than one way to collect a lock token for a message - so maybe we need to investigate the alternative if the delivery annotations are unreliable.

how to set the lock token of the message again? I'll check if it's empty before to call renew_lock!

luipir picture luipir on 19 Sep 2019

BTW is token is None, the raised error is not a correct message to understand it. Should be managed

luipir picture luipir on 19 Sep 2019

I think that the bug is related to https://github.com/Azure/azure-sdk-for-python/issues/4598.

Note that the docs say:

Lock tokens are the DeliveryTag property on received messages. See the following example in the .NET SDK which retrieves these. The token may also appear in the 'DeliveryAnnotations' as 'x-opt-lock-token' however, this is not guaranteed and the DeliveryTag should be preferred.

Indy2222 picture Indy2222 on 19 Sep 2019

in my case the token property is None only in these cases:

@property
def lock_token(self):
    if self.settled:
        return None
    delivery_annotations = self.message.delivery_annotations
    if delivery_annotations:
        return delivery_annotations.get(self._x_OPT_LOCK_TOKEN)
    return None
luipir picture luipir on 19 Sep 2019

sorry my mistake, It's not a DeferredMessage but a base class Message => lock_token property is:

@property
def lock_token(self):
    if hasattr(self._receiver, 'locked_until') or self.settled:
        return None
    delivery_annotations = self.message.delivery_annotations
    if delivery_annotations:
        return delivery_annotations.get(self._x_OPT_LOCK_TOKEN)
    return None
luipir picture luipir on 19 Sep 2019

In this:
if hasattr(self._receiver, 'locked_until') or self.settled:
I can understand self.settled for a message in sending stat (for my undestand of communication) but I can't figure out the reason of hasattr(self._receiver, 'locked_until') check

luipir picture luipir on 19 Sep 2019

Absolutely it should be a reasonable error - however the Service has never sent us empty values before - so we didn't know this was something that needed an appropriate error message ;)

Unfortunately the alternative means of getting a lock token is not yet exposed in the underlying library. I have opened a PR for that here - so hopefully we can get the update out pretty quick:
https://github.com/Azure/azure-uamqp-python/pull/94

The reason for the receiver.locked_until check is for Session-ful messages. In this scenario (i.e. when you receive from a Session), an individual message does not have a lock - rather the entire link has the lock and therefore the link lock must be renewed in order to keep the messages active.

annatisch picture annatisch on 19 Sep 2019
👍2

The reason for the receiver.locked_until check is for Session-ful messages. In this scenario (i.e. when you receive from a Session), an individual message does not have a lock - rather the entire link has the lock and therefore the link lock must be renewed in order to keep the messages active.

clear, tnx

BTW I can confirm that bypassing "if hasattr(self._receiver, 'locked_until') or self.settled:" still retunr None

luipir picture luipir on 19 Sep 2019

and delivery_annotations is None!

luipir picture luipir on 19 Sep 2019

@Indy2222

I think that the bug is related to #4598.

I do not think so, because delivery_annotations are empty in my message (or I didn't well understand you suggestion)

luipir picture luipir on 19 Sep 2019
👎1

Actually that is correct - or it least, partially correct.
On the one hand it's strange that deliver_annotations is None - this implies that something has changed in the service. However it would be less of an issue if #4598 was supported.

annatisch picture annatisch on 19 Sep 2019
👍2

On the one hand it's strange that deliver_annotations is None - this implies that something has changed in the service.

Note that we are using Service Bus topics extensively and we experience this issue only on one topic but not the others. However, it seems that the lock token is not present on any message on the affected topic.

However it would be less of an issue if #4598 was supported.

Yes. IMHO it is dangerous to depend on a header which is explicitly documented as not being guaranteed. But I don't see under the hood, i.e. how you coordinate between the server side and client side development.

Indy2222 picture Indy2222 on 20 Sep 2019

Note that we are using Service Bus topics extensively and we experience this issue only on one topic but not the others. However, it seems that the lock token is not present on any message on the affected topic.

I did tests on different queue on a different computer (not the same point release version of Azure sdk) and worked fine. I'll check on the same message.
BTW with ServiceBusExplorer I can see a lock token in the metadata of the message where metadata are not transmitted.

luipir picture luipir on 20 Sep 2019

confirmed, it happens only on a specific queue (from a testing code that workd on a different queue)
this is the uamqp debug log:
https://gist.github.com/luipir/01775bef48732af9b2a6e1e7a71645ce

luipir picture luipir on 20 Sep 2019

I checked queue parameters with a working queue and there is no difference. I test also creating a new subscriber in the broken queue, and the error is still present.

luipir picture luipir on 20 Sep 2019

Hi,
got the same error running a small piece of code:

from azure.servicebus import AutoLockRenew, ServiceBusClient, Message
import os
from time import sleep, time
import logging
import datetime

logging.basicConfig(level=logging.DEBUG)

sbs = ServiceBusClient(os.environ['AZURE_BUS_NAMESPACE'],
                        shared_access_key_name=os.environ['AZURE_BUS_KEY_NAME'],
                        shared_access_key_value=os.environ['AZURE_BUS_KEY_VALUE'])
queue = sbs.get_queue(os.environ['AZURE_BUS_QUEUE'])

lock_time = 60
lock_renewal = AutoLockRenew(max_workers=4)
while True:
    with queue.get_receiver(idle_timeout=3) as queue_receiver:
        for message in queue_receiver:
            print(f'Got message: {message}')
            lock_renewal.register(message, timeout=lock_time)
            print(f'Sleeping {lock_time * 0.9} seconds...')
            sleep(lock_time * 0.9)
            print(f'Wake up!')
            message.complete()

Posting a message to a queue, I got the following:

Got message: 5d86a0a5ff09a39ab244655e
DEBUG:azure.servicebus.common.utils:Running lock auto-renew thread for 60 seconds
Sleeping 54.0 seconds...
DEBUG:azure.servicebus.common.utils:10 seconds or less until lock expires - auto renewing.
DEBUG:uamqp.c_uamqp:Deallocating 'AMQPValue'
DEBUG:uamqp.c_uamqp:Destroying 'AMQPValue'
DEBUG:uamqp.c_uamqp:Deallocating 'StringValue'
DEBUG:uamqp.c_uamqp:Destroying 'StringValue'
DEBUG:uamqp.c_uamqp:Deallocating 'DictValue'
DEBUG:uamqp.c_uamqp:Destroying 'DictValue'
DEBUG:uamqp.message:Parsing received message 2.
DEBUG:uamqp.c_uamqp:Destroying cProperties
DEBUG:uamqp.message:Parsing received message properties 2.
DEBUG:uamqp.c_uamqp:Wrapping value type: <AMQPType.StringValue: 16>
DEBUG:uamqp.c_uamqp:Destroying cHeader
DEBUG:uamqp.message:Parsing received message header 2.
DEBUG:uamqp.message:Parsing received message application properties 2.
DEBUG:uamqp.c_uamqp:Wrapping value type: <AMQPType.DictValue: 19>
DEBUG:uamqp.c_uamqp:Wrapping value type: <AMQPType.StringValue: 16>
DEBUG:uamqp.c_uamqp:Wrapping value type: <AMQPType.StringValue: 16>
DEBUG:uamqp.c_uamqp:Deallocating 'StringValue'
DEBUG:uamqp.c_uamqp:Destroying 'StringValue'
DEBUG:uamqp.c_uamqp:Deallocating 'StringValue'
DEBUG:uamqp.c_uamqp:Destroying 'StringValue'
DEBUG:uamqp.c_uamqp:Deallocating 'DictValue'
DEBUG:uamqp.c_uamqp:Destroying 'DictValue'
DEBUG:uamqp.message:Parsing received message annotations 2.
DEBUG:uamqp.c_uamqp:Wrapping value type: <AMQPType.DictValue: 19>
DEBUG:uamqp.c_uamqp:Wrapping value type: <AMQPType.SymbolValue: 17>
DEBUG:uamqp.c_uamqp:Wrapping value type: <AMQPType.TimestampValue: 13>
DEBUG:uamqp.c_uamqp:Wrapping value type: <AMQPType.SymbolValue: 17>
DEBUG:uamqp.c_uamqp:Wrapping value type: <AMQPType.LongValue: 9>
DEBUG:uamqp.c_uamqp:Deallocating 'SymbolValue'
DEBUG:uamqp.c_uamqp:Destroying 'SymbolValue'
DEBUG:uamqp.c_uamqp:Deallocating 'TimestampValue'
DEBUG:uamqp.c_uamqp:Destroying 'TimestampValue'
DEBUG:uamqp.c_uamqp:Wrapping value type: <AMQPType.SymbolValue: 17>
DEBUG:uamqp.c_uamqp:Wrapping value type: <AMQPType.LongValue: 9>
DEBUG:uamqp.c_uamqp:Deallocating 'SymbolValue'
DEBUG:uamqp.c_uamqp:Destroying 'SymbolValue'
DEBUG:uamqp.c_uamqp:Deallocating 'LongValue'
DEBUG:uamqp.c_uamqp:Destroying 'LongValue'
DEBUG:uamqp.c_uamqp:Wrapping value type: <AMQPType.SymbolValue: 17>
DEBUG:uamqp.c_uamqp:Wrapping value type: <AMQPType.TimestampValue: 13>
DEBUG:uamqp.c_uamqp:Deallocating 'SymbolValue'
DEBUG:uamqp.c_uamqp:Destroying 'SymbolValue'
DEBUG:uamqp.c_uamqp:Deallocating 'LongValue'
DEBUG:uamqp.c_uamqp:Destroying 'LongValue'
DEBUG:uamqp.c_uamqp:Deallocating 'SymbolValue'
DEBUG:uamqp.c_uamqp:Destroying 'SymbolValue'
DEBUG:uamqp.c_uamqp:Deallocating 'TimestampValue'
DEBUG:uamqp.c_uamqp:Destroying 'TimestampValue'
DEBUG:uamqp.c_uamqp:Deallocating 'DictValue'
DEBUG:uamqp.c_uamqp:Destroying 'DictValue'
DEBUG:uamqp.c_uamqp:Deallocating cProperties
DEBUG:uamqp.c_uamqp:Destroying cProperties
DEBUG:uamqp.c_uamqp:Deallocating cHeader
DEBUG:uamqp.c_uamqp:Destroying cHeader
DEBUG:uamqp.c_uamqp:Deallocating 'cApplicationProperties'
DEBUG:uamqp.c_uamqp:Destroying 'cApplicationProperties'
DEBUG:uamqp.c_uamqp:Deallocating 'cMessageAnnotations'
DEBUG:uamqp.c_uamqp:Destroying 'cMessageAnnotations'
DEBUG:uamqp.c_uamqp:Destroying cSource
DEBUG:uamqp.c_uamqp:Destroying cTarget
DEBUG:uamqp.c_uamqp:Deallocating cSource
DEBUG:uamqp.c_uamqp:Destroying cSource
DEBUG:uamqp.c_uamqp:Deallocating cTarget
DEBUG:uamqp.c_uamqp:Destroying cTarget
DEBUG:uamqp.c_uamqp:Destroying cSource
DEBUG:uamqp.c_uamqp:Destroying cTarget
DEBUG:uamqp.c_uamqp:Deallocating cSource
DEBUG:uamqp.c_uamqp:Destroying cSource
DEBUG:uamqp.c_uamqp:Deallocating cTarget
DEBUG:uamqp.c_uamqp:Destroying cTarget
DEBUG:uamqp.c_uamqp:Management link open: 0
DEBUG:uamqp.message:Parsing received message 3.
DEBUG:uamqp.c_uamqp:Destroying cProperties
DEBUG:uamqp.message:Parsing received message properties 3.
DEBUG:uamqp.c_uamqp:Wrapping value type: <AMQPType.StringValue: 16>
DEBUG:uamqp.c_uamqp:Destroying cHeader
DEBUG:uamqp.message:Parsing received message header 3.
DEBUG:uamqp.message:Parsing received message application properties 3.
DEBUG:uamqp.c_uamqp:Wrapping value type: <AMQPType.DictValue: 19>
DEBUG:uamqp.c_uamqp:Wrapping value type: <AMQPType.StringValue: 16>
DEBUG:uamqp.c_uamqp:Wrapping value type: <AMQPType.StringValue: 16>
DEBUG:uamqp.c_uamqp:Deallocating 'StringValue'
DEBUG:uamqp.c_uamqp:Destroying 'StringValue'
DEBUG:uamqp.c_uamqp:Deallocating 'StringValue'
DEBUG:uamqp.c_uamqp:Destroying 'StringValue'
DEBUG:uamqp.c_uamqp:Deallocating 'DictValue'
DEBUG:uamqp.c_uamqp:Destroying 'DictValue'
DEBUG:uamqp.message:Parsing received message annotations 3.
DEBUG:uamqp.c_uamqp:Wrapping value type: <AMQPType.DictValue: 19>
DEBUG:uamqp.c_uamqp:Wrapping value type: <AMQPType.SymbolValue: 17>
DEBUG:uamqp.c_uamqp:Wrapping value type: <AMQPType.TimestampValue: 13>
DEBUG:uamqp.c_uamqp:Wrapping value type: <AMQPType.SymbolValue: 17>
DEBUG:uamqp.c_uamqp:Wrapping value type: <AMQPType.LongValue: 9>
DEBUG:uamqp.c_uamqp:Deallocating 'SymbolValue'
DEBUG:uamqp.c_uamqp:Destroying 'SymbolValue'
DEBUG:uamqp.c_uamqp:Deallocating 'TimestampValue'
DEBUG:uamqp.c_uamqp:Destroying 'TimestampValue'
DEBUG:uamqp.c_uamqp:Wrapping value type: <AMQPType.SymbolValue: 17>
DEBUG:uamqp.c_uamqp:Wrapping value type: <AMQPType.LongValue: 9>
DEBUG:uamqp.c_uamqp:Deallocating 'SymbolValue'
DEBUG:uamqp.c_uamqp:Destroying 'SymbolValue'
DEBUG:uamqp.c_uamqp:Deallocating 'LongValue'
DEBUG:uamqp.c_uamqp:Destroying 'LongValue'
DEBUG:uamqp.c_uamqp:Wrapping value type: <AMQPType.SymbolValue: 17>
DEBUG:uamqp.c_uamqp:Wrapping value type: <AMQPType.TimestampValue: 13>
DEBUG:uamqp.c_uamqp:Deallocating 'SymbolValue'
DEBUG:uamqp.c_uamqp:Destroying 'SymbolValue'
DEBUG:uamqp.c_uamqp:Deallocating 'LongValue'
DEBUG:uamqp.c_uamqp:Destroying 'LongValue'
DEBUG:uamqp.c_uamqp:Deallocating 'SymbolValue'
DEBUG:uamqp.c_uamqp:Destroying 'SymbolValue'
DEBUG:uamqp.c_uamqp:Deallocating 'TimestampValue'
DEBUG:uamqp.c_uamqp:Destroying 'TimestampValue'
DEBUG:uamqp.c_uamqp:Deallocating 'DictValue'
DEBUG:uamqp.c_uamqp:Destroying 'DictValue'
DEBUG:uamqp.c_uamqp:Deallocating cProperties
DEBUG:uamqp.c_uamqp:Destroying cProperties
DEBUG:uamqp.c_uamqp:Deallocating cHeader
DEBUG:uamqp.c_uamqp:Destroying cHeader
DEBUG:uamqp.c_uamqp:Deallocating 'cApplicationProperties'
DEBUG:uamqp.c_uamqp:Destroying 'cApplicationProperties'
DEBUG:uamqp.c_uamqp:Deallocating 'cMessageAnnotations'
DEBUG:uamqp.c_uamqp:Destroying 'cMessageAnnotations'
DEBUG:uamqp.c_uamqp:Deallocating cProperties
DEBUG:uamqp.c_uamqp:Destroying cProperties
DEBUG:uamqp.c_uamqp:Management op complete: 2, status code: 500, description: b'Unsupported type 0x40 for array. TrackingId:0c3a2fd3-d846-4de7-aecc-29cf420726dd_G21, SystemTracker:NoSystemTracker, Timestamp:2019-09-21T22:26:12'
ERROR:uamqp.mgmt_operation:Failed to complete mgmt operation.
Status code: 500
Message: b'Unsupported type 0x40 for array. TrackingId:0c3a2fd3-d846-4de7-aecc-29cf420726dd_G21, SystemTracker:NoSystemTracker, Timestamp:2019-09-21T22:26:12'
DEBUG:uamqp.message:Parsing received message None.
andreacassioli picture andreacassioli on 22 Sep 2019

@andreacassioli @Indy2222 @annatisch I've discovered the origin of the problem... it is how ServiceBusExplorer send messages to the queue! at least in my case!
If a message is sent via ServiceBusexplorer => no lock_token info and/or some mentadata are missing.
If I send the same message to the same queue via a normal client this error is not present.
BTW the issue still remain for at least two aspects:
1) the error message is totally unuseful to understand the origin of the problem
2) there is no recovery action. e.g. setup a lock token if not available for a specific session or user.

I'll notify this effect to ServiceBusExplorer tracker

luipir picture luipir on 23 Sep 2019

Thanks @luipir - that's a very interesting observation!
I'm still hoping this can be resolved through supporting of the delivery tag - however if we can also get a temporary fix in place in SBExplorer that would be great :)

Edit: I guess you discovered that this wasn't the case and closed the issue?

annatisch picture annatisch on 23 Sep 2019

Edit: I guess you discovered that this wasn't the case and closed the issue?

no, they closed the issue assuming it's not "their" responsability... I't not my way to manage a OS project, but I assume the decision especially because none of the other in this thread have mentioned if they have serviceBusExplorer involved in the message generation.

Their assumption is that ServiceBusExplorer is creating the message correctly and the python SDK is missing reading some metadata (in my case no metadata at all, not only lock).

luipir picture luipir on 23 Sep 2019

Ug... okay - well I'll try to get the other patch through as quick as I can.
If I were to get a test build of an updated uAMQP release - would you be open to testing it out?

annatisch picture annatisch on 23 Sep 2019

If I were to get a test build of an updated uAMQP release - would you be open to testing it out?

@annatisch for a OS project I'm always open to contribute :) do you need a specific platform or a linux is enough? I do not know uAMQP and project details but would make sense to have a unit test about this fix? eg here https://github.com/Azure/azure-uamqp-python/tree/master/tests

luipir picture luipir on 24 Sep 2019

Update - the changes are now ready for testing:
The uAMQP wheels with the changes can be download here:
https://dev.azure.com/azure-sdk/public/_build/results?buildId=118233

The updates to the service bus SDK are in PR here:
https://github.com/Azure/azure-sdk-for-python/pull/7453

The PR also includes a better error message for the case where no lock token is present.

annatisch picture annatisch on 26 Sep 2019
❤1

@luipir

I've discovered the origin of the problem... it is how ServiceBusExplorer send messages to the queue! at least in my case!
If a message is sent via ServiceBusexplorer => no lock_token info and/or some mentadata are missing.
If I send the same message to the same queue via a normal client this error is not present.

Could you check if ServiceBusExplorer is connecting using NetMessaging transport or Amqp? Could you try with the other protocol and see if you observe anything differently?

FYI: The default for SBExplorer is NetMessaging and the python and .net OS clients are written using AMQP protocol. Other than the protocol differences, I do not generally expect any special handling done by SBExplorer.

nemakam picture nemakam on 5 Oct 2019

i'm late testing because I've to fix other stuff in OpenSFM, sorry... any suggestion to know how SBExplorer is using .net or AMPQ? SBExplorer guys seem sure they use .net.

luipir picture luipir on 6 Oct 2019

@luipir, my bad. I meant, when you use SBExplorer, what settings do you use? On the screen when you provide your connection details in the tool, there is an option to choose your transport type. The default value there is NetMessaging.
The .net SDK that SBExplorer uses supports both the transport types, whereas the python library supports only one transport type, i.e., AMQP,
So what I am intrigued with is whether the problem lies in cross-protocol support. i.e, sending messages using NetMessaging protocol and receiving with AMQP protocol, wherein the service is responsible for converting the message format from one protocol to another.

nemakam picture nemakam on 7 Oct 2019

When can we expect the fix to be released in a new version?

Indy2222 picture Indy2222 on 25 Oct 2019

https://github.com/Azure/azure-sdk-for-python/pull/7453 seems already merged in track2 branch.. no idea what is the release roadmap of the package. You were able to test the wheels as suggested by https://github.com/Azure/azure-sdk-for-python/issues/7336#issuecomment-535618145 ? I hadn't time (mainly because I found the workaround so I do not have it as an emergency and I'm focused on complementary deadlines)

luipir picture luipir on 25 Oct 2019

Hey folks,

Resurrecting this discussion as it seems to be the root for #9010 and #8707 as well, to throw a wider net echoing if individuals are still seeing issues in this path. (Given UAMQP 1.2.6 / SB 0.50.2 releases made in December)

Don't hesitate to shout if there's another repro, in testing the code from AndreaCassioli I was not able to reproduce the failure with latest versions, so "cautiously optimistic."

KieranBrantnerMagee picture KieranBrantnerMagee on 24 Feb 2020
Was this page helpful?
0 / 5 - 0 ratings

Related issues

jmlero picture jmlero  路  3Comments
Fajkowsky picture Fajkowsky  路  4Comments
smereczynski picture smereczynski  路  4Comments
ghost picture ghost  路  4Comments
shreyasmoolya09 picture shreyasmoolya09  路  3Comments