I have a topicClient created from messagingfactory using connectionString
MessagingFactory.CreateFromConnectionString(connectionString)
MessagingFactory.CreateQueueClient(topicName).
In low band networks i get a timeout exception when sending messages to Azure Topic. Is there a way to change the timeout property?
I know there is a way when we use MessagingFactory.Create() method.
Thanks in advance
Here's the Code Snippet:
MessagingFactorySettings settings = new MessagingFactorySettings {
settings.OperationTimeout = TimeSpan.FromSeconds(120)
};
MessagingFactory messagingFactory = MessagingFactory.Create(connection, settings);
and more over - if you need performance critical messaging - ServiceBus also supports the standard Protocol for Messaging - AMQP.
settings.TransportType = TransportType.Amqp;
BTW, I guess a typo, but just in case - in your code snippet use : CreateTopicClient (not createQueueClient)
Hope it helps!
Sree
For those of you who stumbled here through google. I got a similar problem while using the 'Microsoft.Azure.ServiceBus' package in .NET core. I got a time out error when trying
await client.SendAsync(message);
In my case the problem was that my company was blocking port 5671.
Switching to AmqpWebSockets resolved my issue.
Put this after your connection string.
;TransportType=AmqpWebSockets
Related
InvokeDeviceMethodAsync is intermittently (and only recently) returning a status code of 501 within the responses (the response body is null).
I understand this means Not Implemented. However, the method IS implemented - in fact, it's the only method that is. The device is using Microsoft.Azure.Devices.Client (1.32.0-preview-001 since we're also previewing the Device Streams feature).
Setup, device side
This is all called at startup. After this, some invocations succeed, some fail.
var deviceClient = DeviceClient.CreateFromConnectionString(connectionDetails.ConnectionString, TransportType.Mqtt);
await deviceClient.SetMethodHandlerAsync("RedactedMethodName", RedactedMethodHandler, myObj, cancel).ConfigureAwait(true);
Call, server side
var methodInvocation = new CloudToDeviceMethod("RedactedMethodName")
{
ResponseTimeout = TimeSpan.FromSeconds(60),
ConnectionTimeout = TimeSpan.FromSeconds(60)
};
var invokeResponse = await _serviceClient.InvokeDeviceMethodAsync(iotHubDeviceId, methodInvocation, CancellationToken.None);
What have I tried?
Check code, method registration
Looking for documentation about 501: can't find any
Looking through the source for the libraries (https://github.com/Azure/azure-iot-sdk-csharp/search?q=501). Just looks like "not implemented", i.e. nothing registered
Turning on Distributed Tracing from the Azure portal, with sampling rate 100%. Waited a long time, but still says "Device is not synchronised with desired settings"
Exploring intellisense on the DeviceClient object. Not much there!
What next?
Well, I'd like to diagnose.
What possible reasons are there for the 501 response?
Are there and diagnostic tools, e.g. logging, I have access to?
It looks like, there is no response from the method within the responseTimeoutInSeconds value, so for test purpose (and the real response error) try to use a REST API to invoke the device method.
You should received a http status code described here.
I am reading events from an Azure EventHub cluster synchronously via the receiveFromPartition method on the EventHubConsumerClient class.
I create the client once like so:
EventHubConsumerClient eventHubConsumerClient = new EventHubClientBuilder()
.connectionString(eventHubConnectionString)
.consumerGroup(consumerGroup)
.buildConsumerClient());
I then just use a ScheduledExecutorService to retrieve events every 1.5s via:
IterableStream<PartitionEvent> receivedEvents = eventHubConsumerClient.receiveFromPartition(
partitionId, 1, eventPosition);
The equivalent logic in V3 of the SDK worked fine (using PartitionReceivers), but now I am seeing OOMs in my JVM.
Running a profiler against a local version of the logic I see the majority of the heap (90%, mainly in OG) is being taken up by byte[]s, referenced by org.apache.qpid.proton.codex.CompositeReadableBuffer. This pattern is not present when I profile the V3 logic.
What could be causing a leak of the AMQP messages here, do I need to interact with the SDK further, for example close a connection that I'm not aware of after each call?
Any advise would be very appreciated, thanks!
Turns out it was a bug, solved here: https://github.com/Azure/azure-sdk-for-java/issues/13775
I'm not sure of the proper way to manage the lifespans of the various clients necessary to interact with the Azure Service Bus. From my understanding there are three different but similar clients to manage: ServiceBusClient, a Topic/Queue/Subscription Service, and then a Sender of some sort. In my case, its TopicService and a Sender. Should I close the sender after every message? After a certain amount of downtime? And same with all the others? I feel like I should keep the ServiceBusClient open until the function is entirely complete, so that probably carries over to the Topic Client as well. There's just so many ways to skin this one, I'm not sure where to start to draw the line. I'm pretty sure it's not this extreme:
function sendMessage(message: SendableMessageInfo) {
let client=createServiceBusClientFromConnectionString(connectionString)
let tClient = createTopicClient(client);
const sender = tClient.createSender();
sender.send(message);
sender.close();
tClient.close();
client.close();
}
But leaving everything open all the time seems like a memory leak waiting to happen. Should I handle this all through error handling? Try-catch, then close everything in a finally block?
I could also just use the Azure Function binding, correct me if I'm wrong:
const productChanges: AzureFunction = async function (context: Context, products: product[]): Promise<void> {
context.bindings.product_changes = []
for (let product of product) {
if(product.updated) {
let message = this.createMessage(product)
context.bindings.product_changes.push(message)
}
}
context.done();
}
I can't work out from the docs or source which would be better (both in terms of performance and finances) for an extremely high throughput Topic (at surge, ~100,000 requests/sec).
Any advice would be appreciated!
In my opinion, we'd better use Azure binding or set the client static but not create the client every time. If use Azure binding, we will not consider the problem about close the sender, if set the client static, it's ok too. Both of the solutions have good performance and there is no difference in cost (you can refer to this tutorial for servicebus price: https://azure.microsoft.com/en-us/pricing/details/service-bus/) between these twos. Hope it would be helpful to your question.
I know this is a late reply, but I'll try to explain the concepts behind the clients below in case someone lands here looking for answers.
Version 1
_ ServiceBusClient (maintains the connection)
|_ TopicClient
|_ Sender (sender link)
Version 7
_ ServiceBusClient (maintains the connection)
|_ ServiceBusSender (sender link)
In both version 1 and version 7 of #azure/service-bus SDK, when you use the sendMessages method or the equivalent send method for the first time, a connection is created on the ServiceBusClient if there was none and the new sender link is created.
The sender link remains active for a while and is cleared on its own(by the SDK) if there is no activity. Even if it is closed by inactivity, the subsequent send call even after waiting for a long duration would work just fine since it creates a new sender link.
Once you're done using the ServiceBusClient, you can close the client and all the internal senders, receivers are also closed with this if they are not already closed individually.
The latest version 7.0.0 of #azure/service-bus has been released recently.
#azure/service-bus - 7.0.0
Samples for 7.0.0
Guide to migrate from #azure/service-bus v1 to v7
Having some trouble processing messages created in the Azure IoT Hub.
Getting the following eror: Exception thrown: 'Microsoft.ServiceBus.Messaging.Amqp.AmqpException' in Microsoft.ServiceBus.dll ("An AMQP error occurred (condition='amqp:link:redirect').")
Can anyone point me in the right direction?
Regards,
Jonas
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using Microsoft.ServiceBus.Messaging;
namespace IOTHubMessageProcessor
{
class Program
{
static string connectionString = "HostName=yaddaaaa.azure-devices.net;SharedAccessKeyName=iothubowner;SharedAccessKey=keydataasdss+tacsCxwkWQeUm9sMCc2GHnQkIZHM=";
static string iotHubD2cEndpoint = "messages/events";
static EventHubClient eventHubClient;
static void Main(string[] args)
{
Console.WriteLine("Receive messages\n");
eventHubClient = EventHubClient.CreateFromConnectionString(connectionString, iotHubD2cEndpoint);
var d2cPartitions = eventHubClient.GetRuntimeInformation().PartitionIds;
foreach (string partition in d2cPartitions)
{
ReceiveMessagesFromDeviceAsync(partition);
}
Console.ReadLine();
}
private async static Task ReceiveMessagesFromDeviceAsync(string partition)
{
var eventHubReceiver = eventHubClient.GetDefaultConsumerGroup().CreateReceiver(partition, DateTime.UtcNow);
while (true)
{
EventData eventData = await eventHubReceiver.ReceiveAsync();
if (eventData == null) continue;
string data = Encoding.UTF8.GetString(eventData.GetBytes());
Console.WriteLine(string.Format("Message received. Partition: {0} Data: '{1}'", partition, data));
}
}
}
}
I don't encounter this issue when testing with your code, so it might be related to something else. I find the duplicate thread Azure IoT hub basic receiving example, AMQP error, it suggests check on block port or proxy settings, you can try it.
Your iotHubD2cEndpoint has an incorrect format. You can find your compatible endpoint in your azure portal -> messages -> device to cloud settings.
I found this a very helpful example: https://github.com/ppatierno/codesamples/tree/master/IoTHubAmqp/IoTHubAmqp
Code looks fine to me. Mine is identical and works well.
Your best bet is to create a new IoT hub in Azure and replace the strings.
While building the connectionstring, can you try "Endpoint=" instead of "HostName=" on line 12?
Hope this helps!
Mert
A couple of comments:
Please ensure that you are using the latest version of the Service Bus dll. i.e., 3.1.7 (as of today).
Please do not mix async and sync method calls in your code.
Let us know if you are still encountering this issue.
Sometimes I see that the proxy filters amqp packets. Changing the transport type to http probably will solve the problem.
Now I don't have access to Visual Studio but I seem to remember that it is possible to set the transport under the client properties.
If you try it you can easily find if the problem is in the proxy or in the program.
My computer is connected to a domain, but when I go to create a public queue:
MessageQueue.Create(#".\testqueue");
I get this error:
A workgroup installation computer does
not support the operation.
Why might MSMQ think I'm on a workgroup computer?
I know this is late, and there is already an accepted answer, but I just had this issue and it was resolved by changing the format of the queue string.
When my queue name was this, I got the workgroup error:
".\QueueName"
When I changed it to a more formal version, there was no error and sending to the queue worked:
"FormatName:DIRECT=OS:ComputerName\private$\QueueName"
Just in case someone else comes across this post, now they have something else to try...
I got the same problem and solved it by changing it to #".\private$\QueueName"
Being part of a domain is a pre-cursor for installing MSMQ in AD-integrated mode.
It doesn't guarantee MSMQ IS installed in AD-integrated mode.
MSMQ will install in workgroup mode if:
AD integration was not selected as a setup option
AD integration was selected but failed to initialise; check event logs
Yes, the workgroup name is confusing in a domain member situation.
I was facing the same problem, take a look at solution below. I don't know the reason but creating queue in this manner works perfectly.
private MessageQueue messageQueue;
public const string DEFAULT_QUEUE_NAME = "newQueue";
public const string QUEUENAME_PREFIX = ".\\Private$\\";
public static string QueueName
{
get
{
string result = string.Format("{0}{1}", QUEUENAME_PREFIX, DEFAULT_QUEUE_NAME);
return result;
}
}
public void SendMessage()
{
string queuePath = QueueName;
MessageQueue messageQueue = MessageQueue.Create(queuePath);
messageQueue.Send("msg");
}
you can create queue for receiving message in the same manner.
Adding for documentation purpose... I was getting error "A workgroup installation computer does not support the operation" while trying to access transactional dead letter queue and it was due to not specifying the machine name. I was using period to denote computer name. e.g. "FORMATNAME:DIRECT=OS:.\SYSTEM$;DEADXACT". It does not work even with using complete format name. Problem solved after replacing the period with computer name. Below is the working code.
using (var queue = new MessageQueue($#"FORMATNAME:DIRECT=OS:{Environment.MachineName}\SYSTEM$;DEADXACT"))
{
queue.Purge();
}
It is possible that MSMQ installed in your machine as a guest user or another user so remove it from machine and install it with administrative permission.
On the server I was having trouble running MSMQ and getting different kinds of errors, including the error asked in the question.
A workgroup installation computer does not support the operation
What worked for me was not fiddling with Server Manager, but reinstalling MSMQ using Powershell.
Remove-WindowsFeature Msmq; Add-WindowsFeature MsMq
These two cmdlets can be run in a Powershell console running as Administrator. At least it fixed the error for me, but this will install the entire Msmq feature, including subfeatures.
i got this error while debugging a web site from visual studio (2015).
restarting the iisexpress solved this...