Garanteed Subscriber problem: "Emitter rejects listener for no-name event: undefined"
Hello everybody,
I hope I am posting this on the correct Category, correct me otherwise.
I am trying to subscribe a Solace Queue in order to get it's messages and redirect them to a specific endpoint which will later process it's information.
For that, i've made a NODE JS service which uses the GaranteedSubscriber example.
After developing the Queue Subscriber it was tested on a local environment and successfully processed the Messages as intended and the data flow worked fine. However, after deploying it to a production environment some troubles appeared.
[Session initializer]
[Active running logs on development local environment: success]
After initializing the subscriber on productive environment, I am getting the following error: OperationError: Emitter rejects listener for no-name event: undefined.
[Error]
I never got this error on development environment and I can't get what's wrong since the code and configuration data is literally the same between the two.
I haven't encountered this problem while on my development environment with the same exact code and config data.
Do you have any clue on what's wrong given that the code is the same between my local and productive environments?
I've created this post as I can't find any thread that mentions the given error.
Answers
-
Hi there @AngeloCoelho, welcome to the Community! And thanks for such a thoughtful first post... a lot of people just come on here and dump their question and say "what's wrong?"..!
Anyhow, at first glance, the error text you've provided doesn't appear to be a Solace error message. I may be wrong, I don't know our NodeJS API super well, but ...
checking...
Nope,
OperationError
could definitely be a Solace issue..? Can you check if there's a message, reason, or subcode associated with it?And can you explain a bit of your flow? Bind to a queue --> receive a message off it --> send it somewhere? How? REST POST? Publish to a topic? What is the "specific endpoint" you mentioned?
If I had to guess, your app is still probably pulling the message off the queue, but is having issues sending it to the downstream system. You sure you have access to it (username/pw, credentials, etc.) in your production environment?
But yeah, let us know how/where this message is supposed to go.
0 -
Hi there, @Aaron ,
Firstly, than you for your reply to my question.
In response to the question "Can you check if there's a message, reason, or subcode associated with it?"
R: {"message":"Emitter rejects listener for no-name event: undefined","name":"OperationError","subcode":18}
I checked it on documentation and gotten this description.
In response to "And can you explain a bit of your flow? Bind to a queue --> receive a message off it --> send it somewhere? How? REST POST? Publish to a topic? What is the "specific endpoint" you mentioned?"
I listen to the Queue messages and then send it to a private network server to process and store the data (and yes, using REST POST). The problem here is that I was having the error before I could even parse and send the data, so it's not on that part of the process, but before.
After this analysis, I looked in more detail to the binding of the solaceSubscriber.MessageConsumerEventName events and began to comment certain bindings and completed them with 3 logs to each binding (before, on and after binding). After this I noticed a weird pattern: OperationError occured after I tried to bind to the MessageConsumerEventName.SUBSCRIPTION_ERROR and MessageConsumerEventName.SUBSCRIPTION_OK events.
[Error with bindings on]
Therefore, I commented this two specific bindings mentioned before (I kept the MESSAGE, DOWN, DOWN_ERROR, CONNECT_FAILED_ERROR and UP listeners) and I got it to work! 😁
I can't understand why the service runs without problems with the 7 bindings on my localhost but gives me an error on the same scenario on production environment, only working with the other 5 listeners.
The documentation mentions this events.
[Success on productive environment]
I can't consider this a permanent fix as the behavior is non deterministic and it would be nice to have further details on how can this happen when binding events.
Anyway, thank you for your support! 😁
0 -
Hopefully someone that knows our JS/Node API better than me will comment on this.
Is the production broker version the same as your local one?
Can you show your snippet of code for what you mean by: "the binding of the solaceSubscriber.MessageConsumerEventName events and began to comment certain bindings and completed." And where it's throwing the error for
MessageConsumerEventName.SUBSCRIPTION_ERROR
?0 -
That is definitely an interesting observation... One thing you can do to have more verbose logs is you can set the log lever to
DEBUG
instead ofWARN
over heresolace.SolclientFactory.setLogLevel(solace.LogLevel.DEBUG);
Hopefully that would give you/us more insight on what's going on and potentially explain the behaviour you are seeing..
0 -
Hello @Aaron ,
This is the way I got it to work:
// Create a message subscriber console.log(JSON.stringify('messageSubscriber before createMessageConsumer: '+this.messageSubscriber)); this.messageSubscriber = this.session.createMessageConsumer({ // solaceSubscriber.MessageConsumerProperties queueDescriptor: { name: this.queueName, type: solaceSubscriber.QueueType.QUEUE }, acknowledgeMode: solaceSubscriber.MessageConsumerAcknowledgeMode.CLIENT, // Enabling Client ack createIfMissing: true // Create queue if not exists }); console.log(JSON.stringify('messageSubscriber after createMessageConsumer: '+this.messageSubscriber)); // Define message subscriber event listeners console.log('before MessageConsumerEventName.UP '); this.messageSubscriber.on(solaceSubscriber.MessageConsumerEventName.UP, function () { console.log('on MessageConsumerEventName.UP '); //Logic of UP }); console.log('after MessageConsumerEventName.UP '); console.log('before MessageConsumerEventName.CONNECT_FAILED_ERROR') this.messageSubscriber.on(solaceSubscriber.MessageConsumerEventName.CONNECT_FAILED_ERROR, function () { console.log('on MessageConsumerEventName.CONNECT_FAILED_ERROR') // Logic of CONNECT_FAILED_ERROR }); console.log('after MessageConsumerEventName.CONNECT_FAILED_ERROR') console.log('before MessageConsumerEventName.DOWN'); this.messageSubscriber.on(solaceSubscriber.MessageConsumerEventName.DOWN, function () { console.log('on MessageConsumerEventName.DOWN'); // Logic of DOWN }); console.log('after MessageConsumerEventName.DOWN'); console.log('before MessageConsumerEventName.DOWN_ERROR'); this.messageSubscriber.on(solaceSubscriber.MessageConsumerEventName.DOWN_ERROR, function () { console.log('on MessageConsumerEventName.DOWN_ERROR'); // Logic of DOWN_ERROR }); console.log('after MessageConsumerEventName.DOWN_ERROR'); // console.log('before MessageConsumerEventName.SUBSCRIPTION_ERROR'); // this.messageSubscriber.on(solaceSubscriber.MessageConsumerEventName.SUBSCRIPTION_ERROR, function (sessionEvent) { // console.log('on MessageConsumerEventName.SUBSCRIPTION_ERROR'); // // Logic of SUBSCRIPTION_ERROR // }); // console.log('after MessageConsumerEventName.SUBSCRIPTION_ERROR'); // // console.log('before MessageConsumerEventName.SUBSCRIPTION_OK'); // this.messageSubscriber.on(solaceSubscriber.MessageConsumerEventName.SUBSCRIPTION_OK, function (sessionEvent) { // console.log('on MessageConsumerEventName.SUBSCRIPTION_OK'); // // Logic of SUBSCRIPTION_OK // }); // console.log('after MessageConsumerEventName.SUBSCRIPTION_OK'); // Define message received event listener console.log('before MessageConsumerEventName.MESSAGE'); this.messageSubscriber.on(solaceSubscriber.MessageConsumerEventName.MESSAGE, function (message) { console.log('on MessageConsumerEventName.MESSAGE'); // Logic after receiving Queue message } console.log('after MessageConsumerEventName.MESSAGE'); If I uncommented those 2 commented bindings, I couldn't subscribe successfully. I proceeded with this approach as I have other Topic (from which the queue was slit from) which also logs these events. Thank you for your support.
0 -
Hello, @Tamimi ,
Unfortunately, I am not able to make those changes anymore as I already proceeded with the publication of this feature in development environment. Since this queue is splited from a specific Topic (which has LOGs on these events) I guess I could rely on those (since the Queue is consumption-exclusive).
Thank you for your support 😀
0 -
I don't know JS that well, I have no idea why those two particular event handlers would cause your app to crash.
For that, i've made a NODE JS service which uses the GaranteedSubscriber example.
You said you based your code on this sample. It has those same blocks of code. Did you try running this in your production environment as a test?
0 -
Hello, @Aaron ,
I haven't tried the exact code of the example but, on another point of view, I only changed the parameters and the callback code on the listeners, everything else is the same as the example code.
I guess it may be a NODE.js version issue since I am using v14.21.1 on my local instance and v12.20.0 on the productive instance.
The problem is that I have other services (Solace Publisher for example) running on this NODE.js environment and for that I am reluctant to upgrade it now since it is a critical server for the business. Since I got to a certain resolution I may wait for this development to be validated by the client as it is and after that try to upgrade the version and see if it's really that.
1 -
Thanks Angelo - have you tried running v12.20 on your local machine and see if you were able to replicate the same issue? It's good that you have a workaround for now, but if you have any further observations perhaps updating here would be a great!
0