Using Stomp WebSockets to connect to an ActiveMQ server, my extjs5 browser webapp has numerous topic subscriptions scoped to panels.
Here is an example of a topic subscription with headers:
var sub = this.mqClient.subscribe('/topic/Status', this.onStatusMsg,
{"ack":"auto","persistent":true,"activemq.retroactive":true,"selector":"TaskId = 1531","activemq.subscriptionName":"status-1531"} );
When the user is done with a topic subscription, she closes the panel which triggers an this.mqClient.unsubscribe( sub ) call.
Reopening that panel creates a subscription with an identical activemq.subscriptionName which triggers this error response:
javax.jms.JMSException: Durable consumer is in use for client: 2015-05-28 15:29:32-0700.0.9276173142716289 and subscriptionName: status-1531
at org.apache.activemq.broker.region.TopicRegion.addConsumer(TopicRegion.java:127)
at org.apache.activemq.broker.region.RegionBroker.addConsumer(RegionBroker.java:427)
at org.apache.activemq.broker.jmx.ManagedRegionBroker.addConsumer(ManagedRegionBroker.java:244)
at org.apache.activemq.broker.BrokerFilter.addConsumer(BrokerFilter.java:102)
at org.apache.activemq.advisory.AdvisoryBroker.addConsumer(AdvisoryBroker.java:104)
at org.apache.activemq.broker.BrokerFilter.addConsumer(BrokerFilter.java:102)
at org.apache.activemq.broker.BrokerFilter.addConsumer(BrokerFilter.java:102)
at org.apache.activemq.broker.MutableBrokerFilter.addConsumer(MutableBrokerFilter.java:107)
at org.apache.activemq.broker.TransportConnection.processAddConsumer(TransportConnection.java:667)
at org.apache.activemq.command.ConsumerInfo.visit(ConsumerInfo.java:348)
at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:335)
at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:189)
at org.apache.activemq.transport.AbstractInactivityMonitor.onCommand(AbstractInactivityMonitor.java:270)
at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)
at org.apache.activemq.transport.ws.jetty8.StompSocket.sendToActiveMQ(StompSocket.java:125)
at org.apache.activemq.transport.stomp.ProtocolConverter.sendToActiveMQ(ProtocolConverter.java:199)
at org.apache.activemq.transport.stomp.ProtocolConverter.onStompSubscribe(ProtocolConverter.java:663)
at org.apache.activemq.transport.stomp.ProtocolConverter.onStompCommand(ProtocolConverter.java:257)
at org.apache.activemq.transport.ws.jetty8.StompSocket.onMessage(StompSocket.java:82)
at org.eclipse.jetty.websocket.WebSocketConnectionRFC6455$WSFrameHandler.onFrame(WebSocketConnectionRFC6455.java:850)
at org.eclipse.jetty.websocket.WebSocketParserRFC6455.parseNext(WebSocketParserRFC6455.java:349)
at org.eclipse.jetty.websocket.WebSocketConnectionRFC6455.handle(WebSocketConnectionRFC6455.java:225)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:696)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:53)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:745)
How do I close a durable topic subscription?
Removing a durable subscription in STOMP is a two step process if the subscription is currently active (meaning the subscriber is connected and subscribed currently).
First the client must unsubscribe so that the subscription becomes inactive:
String frame = "UNSUBSCRIBE\n" + "destination:/topic/MyTopic" + "\n\n" + Stomp.NULL;
Now that the subscription is inactive it can be removed permanently by issuing an unsubscribe with the subscription name originally used to create it as follows:
String frame = "UNSUBSCRIBE\n" + "destination:/topic/MyTopic" + "\n" + "activemq.subscriptionName:MySubscriptionName\n\n" + Stomp.NULL;
This will remove the subscription and all stored messages that it held from the ActiveMQ message store.
Related
I have an API that will call Azure Topic to schedule a message. Is there a way to receive that message before the schedule time? For example in my code below, I schedule a message to azure topic and it will be queue after 60mins/1hr. Is there a way to received that message before 1hr?
string queueName = "topic";
var client = new ServiceBusClient("", new ServiceBusClientOptions()
{
TransportType = ServiceBusTransportType.AmqpWebSockets
});
// create the sender
ServiceBusSender sender = client.CreateSender(queueName);
// create a message that we can send. UTF-8 encoding is used when providing a string.
ServiceBusMessage message = new ServiceBusMessage($"Hello world cancel 13 {DateTime.Now}");
// add 5 minutes delay
long seq = await sender.ScheduleMessageAsync(message,
DateTimeOffset.Now.AddMinutes(60)
);
The message sequence number you get back when scheduling is suitable for cancelling but doesn't allow receiving that message earlier. The service doesn't allow early receiving, as anything that gets the messages to get the active messages (not in the future). For this scenario, I would suggest keeping the data in a database and not leveraging the queue as the database.
I am working with an azure service bus queue configured to be FIFO (First input first output). I work on an order application with the following states "Pending", "Received" and "Sent". therefore I have grouped the messages by the "SessionId" service bus option, setting the orderId as sessionId so that it processes the messages in order in case of horizontal scaling.
So far it works perfectly, the problem I have found is when a message in "pending" or "Received" status fails due to a timeout and goes to the dead letter queue. The message in "sent" status is processed correctly and then when the support team re-sends the "Pending" or "Received" status message to the queue it is processed correctly marking the order in a previous status instead of "sent" ".
I can think of several ways to control this, for example that the support team looks at the status of the order before reprocessing the message from the dead letter queue :) but I would like to know if service bus offers the possibility that if there is a message in the dead letter queu all the messages in the session queue that have the same sessionId go to the dead letter queu. Finallly, my question is:
Is there a way to configure azure service bus so that if there are any messages in the dead letter queue it sends all messages with the same sessionId to the dead letter queue?
Thank you very much!!!
I would like to know if service bus offers the possibility that if there is a message in the dead letter queue all the messages in the session queue that have the same sessionId go to the dead letter queue.
No, there is no such offering by Service Bus by default.
Is there a way to configure azure service bus so that if there are any messages in the dead letter queue it sends all messages with the same sessionId to the dead letter queue?
Yes, you can do that. You can first peek the messages in your dead-letter queue to fetch all the session ids. Then you can receive the messages in your main queue whose session id is in the DLQ, and then move those messages to DLQ. Here's one such logic I've implemented in dot net using the latest version of Service Bus SDK.
var queueName = "<queue>";
var connectionString = "<connection-string>";
var client = new ServiceBusClient(connectionString);
var sessionIdInDLQList = new List<string>();
var receiver = client.CreateReceiver(queueName, new ServiceBusReceiverOptions { SubQueue = SubQueue.DeadLetter });
var message = await receiver.PeekMessageAsync();
while (message != null)
{
if (!sessionIdInDLQList.Contains(message.SessionId))
sessionIdInDLQList.Add(message.SessionId);
message = await receiver.PeekMessageAsync();
}
foreach (var sessionId in sessionIdInDLQList)
{
var session = await client.AcceptSessionAsync(queueName, sessionId);
message = await session.ReceiveMessageAsync(TimeSpan.FromSeconds(20));
while (message != null)
{
await session.DeadLetterMessageAsync(message, "Message with this session is to be dead-lettered!");
message = await session.ReceiveMessageAsync(TimeSpan.FromSeconds(20));
}
}
In your case, you need to do this before your consumers start reading the messages, probably you can write this in your consumer application or any trigger application like Azure Function or worker role. That’s upto your method of handling.
You can try this code to read Dead Letter from Queue.
public static async Task GetMessage()
{
string topic = "myqueue1";
string connectionString = "Endpoint = sb://xxx.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=xxx";
var servicebusclient = new ServiceBusClient(connectionString);
var reciveroptions = new ServiceBusReceiverOptions { SubQueue = SubQueue.DeadLetter };
var reciver = servicebusclient.CreateReceiver(topic, reciveroptions);
// 10 number of message read from Queue
await receiver.PeekMessageAsync(10);
}
after receiving message from Dead Letter you can send to queue.
As per Microsoft official documents
There's no automatic cleanup of the DLQ. Messages remain in the DLQ
until you explicitly retrieve them from the DLQ and call Complete() on
the dead-letter message.
These following document help you.
Thanks Casually Coding for posting post on Read Message from the Dead Letter Queue
Microsoft Documents Using Dead-Letter Queues to Handle Message Transfer Failures , Receive Message from Dead letter queue
I am trying a sample code of Azure Event Hub Producer and trying to send some message to Azure Event Hub.
The eventhub and its policy is correctly configured for sending and listening messages. I am using Dotnet core 3.1 console application. However, the code doesn't move beyond CreateBatchAsync() call. I tried debugging and the breakpoint doesn't go to next line. Tried Try-catch-finally and still no progress. Please guide what I am doing wrong here. The Event hub on Azure is shows some number of successful incoming requests.
class Program
{
private const string connectionString = "<event_hub_connection_string>";
private const string eventHubName = "<event_hub_name>";
static async Task Main()
{
// Create a producer client that you can use to send events to an event hub
await using (var producerClient = new EventHubProducerClient(connectionString, eventHubName))
{
// Create a batch of events
using EventDataBatch eventBatch = await producerClient.CreateBatchAsync();
// Add events to the batch. An event is a represented by a collection of bytes and metadata.
eventBatch.TryAdd(new EventData(Encoding.UTF8.GetBytes("First event")));
eventBatch.TryAdd(new EventData(Encoding.UTF8.GetBytes("Second event")));
eventBatch.TryAdd(new EventData(Encoding.UTF8.GetBytes("Third event")));
// Use the producer client to send the batch of events to the event hub
await producerClient.SendAsync(eventBatch);
Console.WriteLine("A batch of 3 events has been published.");
}
}
}
The call to CreateBatchAsync would be the first need to create a connection to Event Hubs. This indicates that you're likely experiencing a connectivity or authorization issue.
In the default configuration you're using, the default network timeout is 60 seconds and up to 3 retries are possible, with some back-off between them.
Because of this, a failure to connect or authorize may take up to roughly 5 minutes before it manifests. That said, the majority of connection errors are not eligible for retries, so the failure would normally surface after roughly 1 minute.
To aid in your debugging, I'd suggest tweaking the default retry policy to speed things up and surface an exception more quickly so that you have the information needed to troubleshoot and make adjustments. The options to do so are discussed in this sample and would look something like:
var connectionString = "<< CONNECTION STRING FOR THE EVENT HUBS NAMESPACE >>";
var eventHubName = "<< NAME OF THE EVENT HUB >>";
var options = new EventHubProducerClientOptions
{
RetryOptions = new EventHubsRetryOptions
{
// Allow the network operation only 15 seconds to complete.
TryTimeout = TimeSpan.FromSeconds(15),
// Turn off retries
MaximumRetries = 0,
Mode = EventHubsRetryMode.Fixed,
Delay = TimeSpan.FromMilliseconds(10),
MaximumDelay = TimeSpan.FromSeconds(1)
}
};
await using var producer = new EventHubProducerClient(
connectionString,
eventHubName,
options);
I have a azure function that is triggered every 1 minute. The function creates a MessageReceiver like this
var messageReceiver = new MessageReceiver(serviceBusConnectionString, entityPath, ReceiveMode.PeekLock, null, 0);
The subscription has a lock duration of 1 minute.
It then tries to fetch up to 100 messages from the subscription like this:
var allMessages = new List<Message>();
Message message;
do {
message = await messageReceiver.ReceiveAsync(TimeSpan.FromSeconds(2));
if (message != null) allMessages.Add(message);
} while (message != null && allMessages.Count() < 100);
After processing the messages are completed using messageReceiver.CompleteAsync and the messageReceiver is closed using messageReceiver.CloseAsync().
The first time the function runs it fetches up to 100 messages from the subscription, but on the next runs it only fetches 0 or 1 message no matter the number of messages available in the subscription (Service Bus Explorer shows that there > 10 messages in the subscription). So it seems that ReceiveAsync returns null even when there is messages available.
Increasing the timeout for ReceiveAsync doesn't seem to help.
Why does ReceiveAsync return null when there is messages available?
I found a solution or workaround. If I change the the service bus topic to not allow partitioning (it requires deleting the topic and creating it again), ReceiveAsync always returns a message when there is a message available.
The problems seems related to this issue Odd Behavior of Azure Service Bus ReceiveBatch()
For my app I need to organize a circular (ring) queue. It means that any processed message immediately goes to the end of the queue for continuous processing.
For example:
Queue: A, B, C.
Receiver processes A.
Queue: B, C, A.
2 and 3 should be performed atomically. So we never lose A or any other message.
Another requirement is to ignore duplicates. So there should be always a single A in the queue. Even if a sender pushes another A item. A refers to some unique (primary) key of the message here.
I looked for using Azure Service Bus, but I cannot find how to meet both requirements with it. Is it possible to implement the scenario with Service Bus? If not, what are best alternatives?
This kind of queue can be implemented with Service Bus sessions. Sessions provide "group by" mechanics, so we can assign our unique key to SessionId of the message and then receive messages in groups ignoring all messages in a group except the first one.
Implementation
1) Create a queue with RequiresSession set to true:
var queueDescription = new QueueDescription("CircularQueue")
{
RequiresSession = true,
};
await namespaceManager.CreateQueueAsync(queueDescription);
2) When sending message to the queue, set SessionId to your unique key value:
var message = new BrokeredMessage($"Message body")
{
MessageId = "MESSAGE_UNIQUE_KEY",
SessionId = "MESSAGE_UNIQUE_KEY"
};
await queueClient.SendAsync(message);
3) Receive messages using sessions:
while (true)
{
var session = await queueClient.AcceptMessageSessionAsync(TimeSpan.FromSeconds(10));
if (session == null)
continue;
try
{
var messages = (await session.ReceiveBatchAsync(100)).ToList();
if (messages.Count == 0)
continue;
var message = messages[0];
ProcessMessage(message);
await queueClient.SendAsync(message.Clone());
await session.CompleteBatchAsync(messages.Select(msg => msg.LockToken));
}
finally
{
await session.CloseAsync();
}
}
Based on the little I know about Azure Service Bus, I believe both of these requirements can be fulfilled with it individually, though I am not sure how both of them can be fulfilled together.
Message Cycling
It is my understanding that Azure Service Bus supports First-In-First-Out (FIFO) behavior. What you could do is fetch the message (say A) from the top of the queue in Receive and Delete mode and then reinsert the message back in the queue. Since you're creating a new message, it will be posted to the end of the queue.
Avoid Duplicate Messages
Service Bus Queues has a boolean property called RequiresDuplicateDetection and setting this value accordingly will prevent duplicate messages being inserted. A simple search for Azure Service Bus Duplicate Detection will lead you to many examples.