So, I assume this relates to any Node.js and Active MQ installation but I am using Amazon MQ with Node.js Lambda...
Kind of a noob on ActiveMQ so please correct me where I am wrong!
After reading a message from a queue using stompit I continue processing the message and it shall then be sent over HTTPS to another server.
There is some message validation and enrichment happening on the way to the HTTPS POST, and of course the POST itself can result in an error.
How would I (best) handle a roll-back of the message in case of an error:
1) Keep the connection open and not send client.ack() until I finally got a HTTP 200 back from remote server?
2) Keep the message in a variable and put it back in case of error (sequence doesn't matter?
3) Use something other than stomp?
It is apparently not possible using STOMP so I've changed the code to use the library ampq10 instead.
import amqp10 from 'amqp10';
const AMQPClient = amqp10.Client;
const amqpClient = new AMQPClient({
receiverLink: {
attach: {
rcvSettleMode: amqp10.Constants.receiverSettleMode.settleOnDisposition
},
creditQuantum: 1
}
});
This will allow you to do a receiver.accept(message); if successfully handling the message. If you just .disconnect() whitout an .accept() the message will not be removed from the queue.
Related
I try to use EventHub Go client to send a simple "hello world" event but got this error message:
*Error{Condition: amqp:internal-error, Description: 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 TrackingId:be0c66437a1447b7accdc113c84955dd_G5, SystemTracker:gateway5, Timestamp:2021-07-10T21:28:48, Info: map[]}
The code is exactly the same as this sample code here: https://github.com/Azure/azure-event-hubs-go
The SO thread I found which somehow has similar error message is here Getting "amqp:internal-error" when peeking messages from Azure Service Bus Queue using AMQP, rhea and Node, but it is for Service Bus and Node client.
Any idea why this issue occured?
This error is pretty non-descriptive.
One way to trigger is to specify an EventHubs connection string without an EntityPath=<event hub name> in it.
So if you're using a broker level connection string you'll need to specify the EventHub you're attempting to connect to by adding EntityPath=eventHubName. The readme snippet does list this, but the error is admittedly not great in that situation.
I've filed this issue to at least improve the error message in that case, as it doesn't really lead you to what's wrong.
https://github.com/Azure/azure-event-hubs-go/issues/222
I have an address "pubsub.foo" already configured as multicast in broker.xml.
<address name="pubsub.foo">
<multicast/>
</address>
As per the Artemis documentation:
When clients connect to an address with the multicast element, a subscription queue for the client will be automatically created for the client.
I am creating a simple utility using rhea AMQP Node.js npm to publish messages to the address.
var connection = require('rhea').connect({ port: args.port, host: args.host, username:'admin', password:'xxxx' });
var sender = connection.open_sender('pubsub.foo');
sender.on('sendable', function(context) {
var m = 'Hii test'
console.log('sent ' + m);
sender.send({body:m});
connection.close();
});
I enabled debug log and while running the client code I see the message like this.
2020-02-03 22:43:25,071 DEBUG [org.apache.activemq.artemis.core.postoffice.impl.PostOfficeImpl] Message org.apache.activemq.artemis.protocol.amqp.broker.AMQPMessage#68933e4b is not going anywhere as it didn't have a binding on address:pubsub.foo
I also tried different variations of the topic, for example, client1.pubsub.foo, pubsub.foo::client1 however no luck from the client code. Please share your thoughts. I am new to ActiveMQ Artemis.
What you're observing actually is the expected behavior.
Unfortunately, the documentation you cited isn't as clear as it could be. When it says a subscription queue will be created in response to a client connecting it really means a subscriber not a producer. That's why it creates a subscription queue. The semantics for a multicast address (and publish/subscribe in general) dictate that a message sent when there are no subscribers will be dropped. Therefore, you need to create a subscriber and then send a message.
If you want different semantics then I recommend you use anycast.
How can I send message to deadletter queue?
serviceBusService.receiveQueueMessage(MESSAGE_QUEUE, {isPeekLock: true}, (error, message) => {
...... // want to put message to deadletter queue if there is exception
serviceBusService.deleteMessage(message, error => {
});
});
Mostly, you'd want to rely on the system to decide when to move a message to DLQ and make it the messaging engine's responsibility as much as possible (and not explicitly put a message on DLQ.) It also appears that the guidance in this scenario was provided via documentation here: How to handle application crashes and unreadable messages
Looks like you are using the older azure-sb package that relies on the HTTP REST apis. If you instead use the newer #azure/service-bus package which uses the faster AMQP implementation, there is a deadletter() method on the message you receive that you can use to send the message to the dead letter queue.
I have a website and and a webjob, where the website is a oneway client and the webjob is worker.
I use the Azure ServiceBus transport for the queue.
I get the following error:
InvalidOperationException: Cannot use ourselves as timeout manager
because we're a one-way client
when I try to send Bus.Defer from the website bus.
Since Azure Servicebus have built in support for timeoutmanager should not this work event from a oneway client?
The documentation on Bus.Defer says: Defers the delivery of the message by attaching a header to it and delivering it to the configured timeout manager endpoint
/// (defaults to be ourselves). When the time is right, the deferred message is returned to the address indicated by the header."
Could I fix this by setting the ReturnAddress like this:
headers.Add(Rebus.Messages.Headers.ReturnAddress, "webjob-worker");
Could I fix this by setting the ReturnAddress like this: headers.Add(Rebus.Messages.Headers.ReturnAddress, "webjob-worker");
Yes :)
The problem is this: When you await bus.Defer a message with Rebus, it defaults to return the message to the input queue of the sender.
When you're a one-way client, you don't have an input queue, and thus there is no way for you to receive the message after the timeout has elapsed.
Setting the return address fixes this, although I admit the solution does not exactly reek of elegance. A nicer API would be if Rebus had a Defer method on its routing API, which could be called like this:
var routingApi = bus.Advanced.Routing;
await routingApi.Defer(recipient, TimeSpan.FromSeconds(10), message);
but unfortunately it does not have that method at the moment.
To sum it up: Yes, setting the return address explicitly on the deferred message makes a one-way client capable of deferring messages.
I am subscribing to a channel in Pusher on my local machine using the Javascript SDK, and I don't get any error.
However, when I publish an event to that channel it is not received by the subscriber.
I've looked at Pusher's debug console and saw that the message is indeed sent but the subscription never occurs, as the connection is somehow interrupted, apparently prior to the subscription request (i.e I get a disconnection message, as shown in the console screenshot below).
the code is pretty boilerplate:
var pusher = new Pusher('PUSHER_KEY');
channel = pusher.subscribe('game' + game.gameId);
channel.bind('statusChange', function(game) {
console.log("GOT PUSHER - STATUS " + game.status);
$scope.game.status = game.status;
});
Examining the channel.subscribed property shows that the subscription failed as it equals false. I am at the sandbox plan (max 20 connections) and am only using 2 connections.
What can disrupt the connection?
The channel object:
Console screenshot:
I don't know what's the issue exactly but enabling the logs on the client side might help your find it:
Pusher.log = function(message) {
if (window.console && window.console.log) {
window.console.log(message);
}
};
There's some resources on the website to debug that kind of problem too: http://pusher.com/docs/debugging