Documentation on MessageSession doesn't elaborate on how long message session lives and if it's purged or not. A remark could help to clarify if session state has to be cleared out explicitly by setting it to null and wherever it's evicted by the service or not.

As of today, there're only options to get and set the state.

Current documentation doesn't elaborate what's the maximum allowed size.

@sethmanheim is that something that could be extracted easily? Thanks.

Actual Behavior

• Transaction support is provided for Service Bus messaging protocol, but not for AMQP.

QueueDescription.SupportOrdering documentation says:

Gets or sets a value that indicates whether the queue supports ordering.

As far as the general documentation goes, order of messages is only guaranteed with message sessions. So what is the purpose of this property?

The old Service Bus API supports implementing your own message loop via Receive / ReceiveAsync. (https://docs.microsoft.com/en-us/dotnet/api/microsoft.servicebus.messaging.subscriptionclient.receiveasync?view=azureservicebus-4.1.1).

Is this API coming back? If so, is there an estimated target version or ETA? Surely users implementing their own message loop is a valid use case?

Documentation doesn't specify what value disables AutoRenewTimeout (my tryouts led me to TimeSpan.Zero) or what's the default value (5 mins).

docs page

sample page

I am using service bus queue; I have this setting for the OnMessageOptions

var onMessageOptions = new OnMessageOptions
            {
                MaxConcurrentCalls = 10,
                AutoRenewTimeout = TimeSpan.FromMinutes(100),
                AutoComplete = false
            };

and i set the Lock Duration for the queue to 1 min, so i assume that the lock will not expire untill either i complete the message or the lock is renewed more 100 times. is that correct?

What actually happens the lock is expired after 1 minute, and I get the message delivered again while the old message is still in processing!

Description

There's some discrepancy with the documentation about the number of concurrent connections on a queues/topics/subscription.

One source states

Capped by the limit of concurrent connections per namespace.

Another source says

The number of concurrent TCP connections on a queue/topic/subscription is limited to 100.

Required actions

1. Clarify and update the doco
2. Should FAQ document provide quota details or rather redirect to the quotas document?

Thank you.

Logically portal is correct, but technically it's wrong and should respect what the client API & Broker support.

@jtaubensee

Related to the issue Azure/azure-service-bus-dotnet#160 that might require broker side changes (this issue).

Description

• .NET

1. With Pull Request 199 at the link below, the RegisterMessageHandler and RegisterSessionHandlers were updated. Update the samples also to reflect the change
   Azure/azure-service-bus-dotnet#199

From @corneliutusnea on March 14, 2017 7:29

Actual Behavior

1. Create a QueueClient via QueueClient.CreateFromConnectionString
2. Accept a session using AcceptMessageSession( "sessionId" )
3. If the computer looses connection to the SB (e.g. Disable Network Card or any other network event), the connection to the ASB is lost. The Queue still is marked as IsClosed=false but no messages are received anymore. There is no way to "test" if the connection is still up but no messages are received ever.

Note: AcceptMessageSession() seems to behave nicely and correctly reconnects and continues whatever sessions it had before and keeps receiving messages.

Expected Behavior

1. IsClosed should be false if the session is not really connected.
2. Have some other way to probe that the connection is still alive and force close/release/re-open.
3. During reconnect I can see lots of SessionLockLostException (in the Output window) but I can't receive those in user code so I can't handle them. Attempting to re-open the same session generates exception
   "The requested session '.....' cannot be accepted. It may be locked by another receiver." - I AM that receiver that I lost connection. I'd like to recover ASAP.
4. Manually attempting to .Close() the last session I created closes the session but does not seem to release it (maybe because connection was lost earlier).

Versions

• OS platform and version: Windows 10
• .NET Version: ASP.Net Core 1.1.1 on .Net full 4.5.1
• NuGet: 3.4.6

Copied from original issue: Azure/azure-service-bus-dotnet#104

Partitioning

Documentation doesn't explicitly state what seems to be the behavior - Premium tier entities are always partitioned.

Having two partitions ensures availability and is a more appropriate number for the Premium runtime environment.

Is sort of hinting at that, but documentation should be explicit and clear.

Individual queue size

With Standard tier partitioning is required to have more than 5GB queue. With Premium entities, despite having only 2 partitions, one can set the size up to 80GB.

Summary

It would be nice to have these kind of things documented.

Description

Microsoft.ServiceBus.Messaging.QuotaExceededException is documented with an emphasis on entity filled up with messages. This exception is also thrown when number of connections to a namespace is exceeding the maximum.

Microsoft.ServiceBus.Messaging.QuotaExceededException: ConnectionsQuotaExceeded for namespace xxx.
<tracking-id-guid>_G12 ---> 
System.ServiceModel.FaultException`1[System.ServiceModel.ExceptionDetail]: 
ConnectionsQuotaExceeded for namespace xxx.

Expected

Update documentation to reflect this scenario

I've failed to locate any information for how long a session state is kept on the broker.

From my testing it appears that messages for a session can be all consumed, but the session state will continue for some time.`

I was looking at the sample for the Topic Get Started and it uses the brokeredmessage.

That class is no longer available. When are we going to update the samples with the right classes?

This issue comes from Azure/azure-sdk-for-node#2019, which asks for defer functionality using the REST API.

System.OperationCanceledException is documented as an exception under "User coding error" category.

Here's an example of this exception raised when it's a server internal error.

Exception System.OperationCanceledException: The operation cannot be performed because the entity has been closed or aborted. --->
 System.ServiceModel.CommunicationObjectAbortedException: Internal Server Error: 
The server did not provide a meaningful reply; this might be caused by a premature session shutdown.

The "The server did not provide a meaningful reply" part makes me wonder how is this user coding error? Clarification will be greatly appreciated.

Documentation says:

A maximum of 12 such rules can be configured on a Service Bus namespace, queue, or topic. Rules that are configured on a Service Bus namespace apply to all entities in that namespace.

Does it mean that 12 rules in total or 12 rules per entity/global?

The sample in the documentation has 6 rules allocated. Does it mean another 6 rules are available and that's it? Or for the namespace another 9 rules are available, for the topic T1 another 11 rules are available, and for the queue Q1 another 10 rules can be used? Thank you.

Quoting the sole source of documentation on this event handler:

Occurs when an exception is received. Enables you to be notified of any errors encountered by the message pump. When errors are received calls will automatically be retried, so this is informational.

While it's clear that exceptions are received, it doesn't actually go into explaining what exceptions should or should not be handled.

For example, when there's a TimeoutException, which cannot be determined as transient or not since it's not of the MessagingException, but it's happening as a result of a failing lock renewal operation. Such a failing operation can be considered a transient error and exception can be swallowed. For other cases of TimeoutException it might be a bad idea to swallow exception. Unfortunately, in addition to lacking documentation/guidance on this event handler, Exception​Received​Event​Args.Action has no documentation whatsoever. Separate issue raised, #27.

Give the fact that one cannot mimic all the exceptions raised by the broker, this API should have a better documentation to help developers handle exceptions that will be happening in production.

Sorry, this is probably a generic issue which is not specific to azure-service-bus, but I'm not sure why I'm getting this error.

When I compile azure-service-bus from the git source, then copy the resulting DLLs to my project and add a reference to them via "Browse", I get the following error at runtime (it compiles fine):

System.IO.FileNotFoundException occurred
  HResult=0x80070002
  Message=Could not load file or assembly 'Microsoft.Azure.ServiceBus, Version=0.0.6.0, Culture=neutral, PublicKeyToken=7e34167dcc6d6d8c'. The system cannot find the file specified.
  Source=<Cannot evaluate the exception source>
  StackTrace:
   at MyApp.DomainEvents.Tester.<Exec>d__4.MoveNext() in C:\Visual Studio 2017\Projects\MyApp\src\Profiles\DomainEvents\Tester.cs:line 43
   at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[TStateMachine](TStateMachine& stateMachine)
   at ProfileManager.DomainEvents.Tester.Exec()
   at Api.Controllers.CurrentProfileController.<Get>d__3.MoveNext() in 
C:\Visual Studio 2017\Projects\MyApp\src\Api\Controllers\CurrentProfileController.cs:line 39

However, when I include the whole project in my solution, add the azure-service-bus project as a "Project" reference, and compile the whole thing together it works fine.

More description here.

I can see Java sample code for Service Bus queues. Please provide sample code for topics and subscriptions.

Topic names are currently limited to 50 characters, which causes issues when using client frameworks like NServiceBus. While this can be addressed by the NServiceBus team by generating a hash or a deterministic GUID, both of those options result in unfriendly topic names. Therefore, I would prefer to have the current 50 character restriction on topic names increased.

I've had this issue in the past, and based on the links below, it seems that others are having similar problems.

https://feedback.azure.com/forums/216926-service-bus/suggestions/18552391-increase-the-maximum-length-of-the-name-of-a-topic

Particular/NServiceBus.Azure#19 (comment)

Description

ASB Client supports perf counters. There's no documentation on how to install and use those. There's an outdated Cloud Service sample that is no longer maintained.

Expected Behavior

Provide documentation on how to enable ASB client perf counters and what those counters represent w/o mixing a hosting concern (without any specific hosting technology such as CSes).

In the new client (Microsoft.Azure.ServiceBus) identical issue was raised and fixed.

The fix should be backported to the old client. Given the change, might be considered for a new major.

From @SeanFeldman on December 20, 2016 5:25

There are scenarios where purging a queue is necessary

• Testing scenarios
• Removing all messages because they are no longer needed
• Clearing out deferred messages when sequence numbers are no longer retained by an app

Similar functionality: ASQ`s CloudQueue.ClearAsync().

This would apply to both queue/subscription and associated DLQs.

Copied from original issue: Azure/azure-service-bus-dotnet#46

Description

Running into some odd behavior with ASB (WindowsAzure.ServiceBus) and NUnit where ASB seems to affect System.Remoting.Messaging.CallContext expected by NUnit to be in place.

• NUnit issue nunit/nunit#2275
• Repro code

Actual Behavior

NUnit is throwing NullReferenceException as it fails to read from CallContext. Preliminary execution points at ASB client (no source available) to cause it.

Expected Behavior

The expected to be found CallContext data for NUnit should not be touched and NRE exception should not be triggered.

Current version of NamespaceManager does not allow to discover namespace capabilities (tier, max entity size, etc).

/cc @djrosanova

Description

Feature request to provide a default "catch all" subscription for Service Bus that will match any messages that are not matched by other subscriptions. This is different than the default true filter which will match all messages. Instead this will only catch messages that aren't matched by anything else.

Exception​Received​Event​Args.​Action received when On​Message​Options.​Exception​Received event is raised, supposed to provide a clue what action has caused an exception.

Today, there's no way to discover what's the list of those actions, except running in production and logging all the actions. This is far from ideal. Needs to be documented properly to allow better guidance on how to deal with these exceptions (see issue #28).

@jtaubensee could not find the stuff related to manage the broken connections. Please share some practice related to this concern (how to reconnect, events that should be attached to monitor etc.)...

Samples are using a preview version of the library. Update the samples to use the release version of the library and when making the change, see if the change can be made such that it always uses the latest version of the library.

From @jpda on Apr 13
Copied from original issue: Azure/azure-service-bus-dotnet#131

Actual Behavior

1. If rule doesn't exist when calling DeleteRuleAsync, throw exception and catch/handle
2. Next call to AddRuleAsync fails with 500 from Service Bus

Expected Behavior

1. If rule doesn't exist, throw exception and catch/handle
2. Subsequent call to AddRuleAsync shouldn't fail

Versions

• OS platform and version: Windows 10 16170 .net core 1.1
• .NET Version: core 1.1
• NuGet package version or commit ID: 0.0.2-preview

sample code

client.RemoveRuleAsync() on rules that don’t exist followed by client.AddRuleAsync() causes the 500/ISE to get returned. Removing the RemoveRuleAsync() call entirely and just creating rules works all day (first image below).

However, as soon as you call Remove and it throws an exception, as would be the case if the rule doesn’t exist, it’s as if the client is now dead and unusable.

In this case, there was no exception because the rule names exist, so RemoveRuleAsync ran correctly and the subsequent calls to CreateRuleAsync also succeeded:

Here we do get an exception, because the rule names don’t exist – however now the client is useless and subsequent calls will fail.

I’ve attempted closing the clients and creating new ones, letting them fall out of scope and manually garbage collecting them, but no dice. Putting a 45 second delay in between when the client blows up and recreating it works, but not consistently (see below) – I haven’t tried on longer delay times yet.

Problem

I am using event based message receiving. I have attached my event handler on OnMessage event of MessageReceiver class. After receiving the message, I need to acknowledge it by calling Complete method of BrokeredMessage class. I am calling this method in another thread and receiving the exception: 'BrokeredMessage has been disposed'.
I have verified following points:

1. Lock has not been expired
2. Object has not been disposed
3. Connection has not been closed

Complete cannot be called from any other thread? I am not able to find any answer...

Versions

• OS platform and version: Windows 10 Pro
• .NET Version: 4.6.1
• NuGet package version or commit ID: 3.4.4 (WindowsAzure.ServiceBus)

Steps to Reproduce

1. Create 'MessageReceiver' class from messaging factory with the 'ReceiveMode.PeekLock'
2. Register the event handler with 'OnMessage' event of receiver class created in step 1 with auto complete set to false
3. Once any message received, try to acknowledge from other thread (using Task library for example)

var messageReceiver = queueClient.MessagingFactory.CreateMessageReceiver("QueueName", ReceiveMode.PeekLock);
// Registering event.
messageReceiver.OnMessage(ReceiveReady, new OnMessageOptions { AutoComplete = false, MaxConcurrentCalls = sbSettings.MaxConcurrentReceiveCallback });

// ReceiveReady Implementation
private async void ReceiveReady(BrokeredMessage brokeredMessage)
{
    try
    {
        if (brokeredMessage != null)
        {
            Console.WriteLine("Received by {0}", Thread.CurrentThread.ManagedThreadId);

            await Task.Delay(TimeSpan.FromSeconds(3)); // To simulate some async work...

            Console.WriteLine("Acknowledged by {0}", Thread.CurrentThread.ManagedThreadId);

            await brokeredMessage.CompleteAsync();
        }
    }
    catch (Exception ex)
    {                
    }
}

@jtaubensee can have a look please? It is very urgent kind of issue.

Not sure if this is the right place. Please excuse if not and mote to the appropriate repo if needed.

When creating a queue on a premium tier, size can go up to 80GB. Assuming 80GB queue is created,

reviewing the property doesn't indicate the size and drop down is only goes as much as 5GB.

When sending a JSON-serialised object inside a Message with the TopicClient using SendAsync(...), the message's content is prepended with @ base64Binary�3http://schemas.microsoft.com/2003/10/Serialization/�. General workaround for this is to pass a Stream into a BrokeredMessage but the TopicClient doesn't support it.

Released version is 4.0.0.
Release notes reference "build" 3.0.50870.2.

Hi

I'm just playing around with this new library and I know it's in pre-release. But I thought I'd let you know anyway...

My code is as simple as it gets:

        static void Main(string[] args)
        {
            var queueClient =
                new QueueClient("...", "GreetingsQueue");

            if (args.Length > 0 && args[0] == "publish") {
                queueClient.SendAsync(new Message(Encoding.UTF8.GetBytes(args[2])) {
                    SessionId = args[1]
                }).Wait();

                return;
            }

            queueClient.RegisterSessionHandler(async (session, message, cancel) => {
                var greeting = Encoding.UTF8.GetString(message.Body);
                Console.WriteLine(greeting);
                await queueClient.CompleteAsync(message.SystemProperties.LockToken);
            });

            Console.ReadKey(true);
        }

First I run on instance of the program without any argument, whichs starts listen for new sessions. Then I run another instans with arguments "publish 5 Hello" which sends the message Hello with statusid 5 to the queue. However, now the first instance prints out "Hello" 10 times, which about a second in between each.

John

DLQ documentation lists the reasons why a message can end up in a DLQ.
One of the reasons is MaxTransferHopCountExceeded ("Maximum transfer hop count is exceeded.").

There's also a "Dead-lettering in ForwardTo or SendVia scenarios" section states that

A message passes through more than 3 queues or topics that are chained together.

will be sent to the TDLQ, not the DLQ.

So what is the number of maximum allowed hops when forwarding between queues?

Description

Documentation of NamespaceManager.GetRulesAsync(string, string, string) is explaining the 3rd argument, filter as

The string used to filter the rules to be retrieved.

But doesn't elaborate on how the filtering is working.
Is it filtering the name? The Filter expression? Both?
What is the syntax for filtering?

I've tried various things but can't guess how it works and getting an exception:

The remote server returned an error: (400) Bad Request. Invalid Filter.
There was an error parsing the filter expression.
[Token line=1, column=1, Token in error= =, Additional details= Unrecognized character. '=']...

Would be nice to document what the filter exactly filters and what's the proper syntax.

Related to #15.

Currently, there's zero documentation out there. The syntax for filters is not documented and seem to vary between entity types:

manager.GetQueuesAsync("startswith(path, '$#_') eq true")

works for a queue, but an expression

"startswith(name, 'rule1') eq true"

would not work for Rules.

Description

I can't create topics or queue that contain slash in their name from the portal. Although the portal allow me to add the / to the name in the create form, when I click create button it goes away without any error or success message

Actual Behavior

1. The portal allows me to add the / to the name in the create form when I click create button it goes away without any error or success message
2. in the notification it just show message saying "Service Bus queue creation"
3. When using Masstransit library in the code it creates those topics and queue automatically containing slash in the names. But in that case, I couldn't control them from the portal

Expected Behavior

1. To allow slash when adding topics or queue either programming or from the portal
2. To allow control over the created topics or queues which created by Masstransit that have slash in their names

As the new client Microsoft.Azure.ServiceBus is progressing, something has to be done with the documentation to address the issue with 2 similar clients, yet different in some APIs and details.

Hi

I've basically just followed the examples and created a console app that runs inside a docker container on one of my azure vm's:

queueClient.RegisterSessionHandler(async (session, message, cancel) =>
            {
                var greeting = message.Body.As<Greeting>();
                Console.WriteLine($"Saving greeting with message {greeting.Message}");
                await SaveGreeting(greeting);
                await session.CompleteAsync(message.SystemProperties.LockToken);
            });

            Console.ReadKey(true);

SaveGreeting will just put store the message in a database.

Now what I do is, every couple of days, I just publish a message on the queue, and check to see that it's been persisted to the database. During the first couple of days after starting the program that listens for messages, everything works. But after 5-6 days, it seems to loose connection or something, because the messages stay on the queue. Then, as soon as I restart the program, the messages gets consumed and stored to the db. It always seems to be 5-6 days of inactivity that triggers the "connection loss" or whatever it is.

Could it be that I somehow misunderstood how to use this library, or might it be a bug in there?

Thanks

Description

Per @SeanFeldman:
We need to update our code documentation to show that we automatically set AutoDeleteOnIdle to the maximum value when you set the ForwardTo. We do this so that there will always be a listener to forward the message (when the property is set). We decided to set this value to the max, rather than throwing an exception, as we didn’t want to break previous customers’ implementation.

MessageReceivePump and SessionReceivePump both raise Exception​Received​Event​Args with Action, but the values are not consistent.

• UserCallback vs User Callback Exception
• Receive vs Receive Message

Values should be identical.

Related to #27 and Azure/azure-service-bus-dotnet#174

Description

This is a feature proposal for an active locked message count to be returned in MessageCountDetails.

Description

According to documentation, auto-forwarded messages exceeding max number of hops should end up in TDLQ. This is not what's happening.

Also, auto-forwarding of these messages from DLQ to a centralized queue is broken as well. So it's a 2 bugs in 1 😃 Replaced with #249

Actual Behavior

Message ends up in DLQ

Expected Behavior

Message should go to TDLQ and if not, auto-forwarding to another queue should be respected.

From @SeanFeldman on February 23, 2017 6:38

There are 3 types of messages that can be found on a queue

1. Ready for processing
2. Delayed (ScheduleEnqueueTimeUtc set in future)
3. Deferred (only can be received by SequenceNumber)

When messages are enqueued in the future, they cannot be received.
When messages are peeked, future messages are fully returned (headers & body).
For scenarios when there are many future messages, peek becomes too heavy of an operation.

When peeking for messages, I should be able to choose what am I interested in. If I need to evaluate all, then current behavior is fine. But otherwise, I'm not sure the current behavior is good.

Question: Should the default behavior be only to return what's ready for processing?

An override could then return what's ready for processing and enqueued for the future.

Note: this potentially might require some changed on the broker side. I'll raise a separate issue for that.

Copied from original issue: Azure/azure-service-bus-dotnet#89

Description

SendVia doesn't have corresponding sample.

Actual Behavior

N/A

Expected Behavior

A sample should be created.