Lately I have noticed for a triggered event in NestJS EventEmitter, only few listener methods were being called. Rest of the listeners just don't get executed at all. This doesn't happen for all events for me to reproduce this bug. This occurs now and then.
How do we make sure that the event has been listened successfully by it's subscribers?
Is there a way for us to persist this data and apply a retry mechanism for the failed event listeners?
Related
I'm working on standing up the Azure Service Bus messaging infrastructure for my team, and I'm trying to establish best practices for developing Service Bus message receivers. We are standing up a new service to consume the Service Bus messages; the start up script will instantiate the message receivers and start their message reception.
The pattern I'm setting up for my team is to extend a base receiver class and implement an abstract function that will starts the message receiver in the stream fashion.
I'm curious if there are any notable differences between receiving messages using ServiceBusReceiver::subscribe vs ServiceBusReceiver::receiveMessages (stream vs loop)? I'm suggesting that my team uses ServiceBusReceiver::subscribe since it registers the reception forever and it seems to handle errors more gracefully.
I've noticed two differences between the stream vs loop:
ServiceBusReceiver::receiveMessages is asynchronous. This means that in my script I would need to run Promise.all or Promise.allSettled to start the receivers in parallel. Because of the limited error handling with the loop message reception, I noticed that if the receiver hits an error, it will halt messaging processing. This scenario would require our team to restart the service if any of the receivers hits an error which is a con for our team.
The streaming method is synchronous so my start up script can register the subscriptions, save the return values, and close the subscriptions on shutdown.
If I refer to this object's properties in the ServiceBusReceiver::subscribe callback functions, I get an error that the property is undefined. It seems like the callback functions lose context of the object?
Thanks in advance
The intended way of receiving messages is definitely streaming for the messaging services though both the ways of receiving work just fine with the ServiceBus JS SDK.
receiveMessages (loop) is more for the convenience of the users who just want to receive the messages simply and don't want to deal with the callbacks, handlers, etc.
Internally, receiveMessages also does streaming to receive the messages and waits for the given duration before returning the array of messages.
Hope that might clarify your doubts.
If I refer to this object's properties in the ServiceBusReceiver::subscribe callback functions, I get an error that the property is undefined. It seems like the callback functions lose context of the object?
You can perhaps use arrow functions. For reference, please check this part of an unrelated subscribe test...
https://github.com/Azure/azure-sdk-for-js/blob/d417e93b53450b2660c34965ffa177f3d4d2f947/sdk/servicebus/perf-tests/service-bus/test/subscribe.spec.ts#L72
My app is an API that stores log events of the requests that it receives. The custom logger object periodically writes the log events to a database, based on a timer or when the queue size reaches the max size. I want to flush this object's event log queue when the app is shut down, either because of a fatal error or redeployment. I'm using express and the native https modules to create the API server. I think I can flush the log in the server's error listener and the server's close callback, but how do I reference the logger object that is scoped to a different script in the project? I've looked into using global variables, but this seems to be highly discouraged, so is there a better alternative for my use case?
You can set up an event listener on the process object, which is available globally in node. You will need to experiment with which event event to listen for to make sure it's consistently triggered and you're able to perform the work you want to do. The signal events are likely your best bet since the exit event doesn't allow you to perform async tasks like flushing a
I have an event grid which publishes a lot of events, and a logic app which needs to consume some of them. These events aren't guaranteed to be in order, and events which require another event to be processed first, might end up in the logic app prematurely, causing them to fail.
From the documentation, I can see that event grid supports a retry policy, with an increasing time interval. This would solve my problem.
However, it seems like the logic app in question, always acknowledges events from the event grid, even though the process is stopped early with the Terminate action in the failure state and with an error code.
From the logic app overview, the runs are shown as failed. But the event grid never attempts a retry, and seems to consider the events successful. What can I do to make the event grid retry failed logic app runs?
It seems that once the Azure logic app is triggered, the event in the Azure event grid is considered to be processed.
I think you can configure retry policy at the step where your Azure logic app failed, please refer to Retry policies.
Take the example of Httpaction：
You can click ··· in the upper right corner of the Http action, then click Settings, and select the type you want under Retry Policy：
Event Grid will retry depending on how you terminate your Logic App. If you terminate using http response action (status code 500) then event grid will attempt retries.
Now, depending on what is going on in your Logic app, handle the failures in a way that it terminates on http response action with status code 500.
I am using stompit package of node.js to connect to AMQ queue to subscribe message. I used ConnectFailover class to create connection and channelPool class to create pool.
Problem I am facing is that once connection is made and if there is no message in the queue then it stay connected.
What I need a way to disconnect if there is no message to read from the queue. I don't see any option in stompit documentation.
There is no way to do that with STOMP as per this issue. As a general rule, brokers like AMQ rarely allow consumers to inspect queue properties like message count.
Unless you can somehow leverage JMX from your node.js code, the easiest way would be to create a timer with client.disconnect() as a callback and wait for an amount of time suitable for your system. Whenever a message is consumed, reset the timer.
Can somebody please explain the difference between synchronous and Asynchronous ways of event processing in hybris platform?
I was just going through event system provided by hybris service layer and got stuck at this concept as I couldn't proceed without knowing exactly what happens during events processing (synchronous or asynchronous )? In face what does the term "event processing" ?
Hybris's Event System is based on the Spring Event System, and provide an EventService and wrappers for Events and EventListeners (AbstractEvent and AbstractEventListener). So, under the hood, you deal with Spring's ApplicationEvent and ApplicationListener.
The goal of "event processing" is to provide a pass-through functionality between platform components, in the way, when "interested" components subscribe for an events, and receive notifications when certain event occured (published).
Hybris allow events to be published in a clustered environment, between cluster nodes, by implementing ClusterAwareEvent interface. These events are processed asynchronously. All other events processed synchronously, but it is possible to publish them asynchronously too, by overriding spring definition of PlatformClusterEventSender bean, with injection of thread pool.