Both the Solace queue and my program are subscribing to #LOG/INFO/SUB_ADD/DEVICE/ID/123.
When a new device which connects and subscribe to DEVICE/ID/123, both of them can successfully receive the subscribe event.
But, if I set subscription as #LOG/INFO/SUB_ADD/DEVICE/ID/>, only the solace queue receives the event.
Why can't my program receive the subscription event?
The problem persists even after my program sets it's subscription to #LOG/>.
One possible problem here is that there is an ACL rule preventing your application to subscribe to one or more topics in #LOG/INFO/SUB_ADD/DEVICE/ID/>. This can be easily verified with show log acl subscribe-topic.
If this is not the case, please revert back with the CLI outputs of show client <client-name> stats detail and show client <client-name> subscriptions to look further into the issue.
Related
I'm trying to build a React Native chatting app using Pusher and Laravel as the backend. I want to know more about this environment, do I need to queue each message sent and receive by the user on my backend or just let Pusher do the job? Or it doesn't need a queue at all?? Which is the most suitable in this case?
You don't need to queue the messages, you can just send them and let Pusher broadcast them to the necessary subscribed clients. However, you should consider queuing or other solutions if you need sequential delivery or to retrieve messages that were not received correctly.
Check out their help page for a discussion on how to do this.
I'm evaluating NATS for migrating an existing msg based software
I did not find documentation about msg timeout exception and overload.
For Example:
After Subscriber has been chosen , Is it aware of timeout settings posted by Publisher ? Is it possible to notify an additional time extension ?
If the elected subscriber is aware that some DBMS connection is missing and cannot complete It could be possible to bounce the message
NATS server will pickup another subscriber and will re-post the same message ?
Ciao
Diego
For your first question: It seems to me that you are trying to publish a request message with a timeout (using the nc.Request). If so, the timeout is managed by the client. Effectively the client publishes the request message and creates a subscription on the reply subject. If the subscription doesn't get any messages within the timeout it will notify you of the timeout condition and unsubscribe from the reply subject.
On your second question - are you using a queue group? A queue group in NATS is a subscription that specifies a queue group name. All subscriptions having the same queue group name are treated specially by the server. The server will select one of the queue group subscriptions to send the message to rotating between them as messages arrive. However the responsibility of the server is simply to deliver the message.
To do what you describe, implement your functionality using request/reply using a timeout and a max number of messages equal to 1. If no responses are received after the timeout your client can then resend the request message after some delay or perform some other type of recovery logic. The reply message should be your 'protocol' to know that the message was handled properly. Note that this gets into the design of your messaging architecture. For example, it is possible for the timeout to trigger after the request recipient received the message and handled it but before the client or server was able to publish the response. In that case the request sender wouldn't be able to tell the difference and would eventually republish. This hints that such type of interactions need to make the requests idempotent to prevent duplicate side effects.
Is there any way we can know when a consumer disconnects from a queue or when a queue is deleted?
The requirement is as follows:
I'm building a system in which multiple clients can subscribe to certain events from the system. All clients create their own queue and registers themselves with the system using some sort of authentication. The system, as the events are generated, filters the events and forwards them to clients who are eligible for them.
I have implemented a POC for most part of it and it works well. An issue that I'm not able to fix is that, if a client just disconnects from the queue (due to program termination or so), the registration still exists and the system keeps trying to push messages to that client.
So we would like to be notified when a client disconnects or a queue gets deleted so that we can remove that client's registration data and no longer push messages to him.
Let your publisher utilize Confirms (aka Publisher Acknowledgements) and make client queue be exclusive and transient, so only one client at a time will be consuming from one queue and after it disconnection it will be deleted.
If you publish message that get routed to only one queue and that queue gone (assume you utilize publisher confirms and publish message with mandatory flag set) publisher will be notified that message cannot be routed with that message returned back to it, so you can stop publishing messages.
For details see How Confirms Work section in RabbitMQ blog post "Introducing Publisher Confirms" and Confirms (aka Publisher Acknowledgements) official docs.
I have a single publisher application (PUB) which has N number of subscribers (SUB)
These subscribers need to be able to catch up if they are restarted, or fall down and miss messages.
We have implemented a simple event store that the publisher writes to.
We have implemented a CatchupService which can query the event store and send missed messages to the subscriber.
We have implemented in the subscriber a PUSH socket which sends a request for missed messages.
The subscriber also has a PULL socket which listens for missed messages on a seperate port.
The subscriber will:
Detect a gap
Send a request for missed messages to our CatchupService, the request also contains the address on which to send the results to.
The catchup service has a PULL socket on which it listens for requests
When the CatchupService receives a request it starts a worker thread which:
Gets the missed messages
Opens a PUSH socket connecting to the subscribers PULL socket
Sends the missed messages to the subscriber.
This seems to work quite well however we are unsure if we are using the right socket types for this sort of application. Are these correct or should be using a different pattern.
Sounds okay. Otherwise 0MQ is able to recovery from message loss when peers go offline for a short time. Take a look at the Socket Options and specifically option ZMQ_SNDHWM.
I don't know just how guaranteed the 0MQ recovery mechanisms are so maybe you're best to stay with what you've got, but it is something to be aware of.
I'm trying to create new subscriber with 'Destination name' as local-queue-name, but for that I need non-durable subscriber.
When creating new subscriber in MQ, using MQSC or MQ-Explorer, how do I make it non-durable?
Is there any way to change it (alter) after it has been created?
Thanks.
Non-durable subscriptions are active as long as the application that created them is active. Once the application ends or application closes connection to queue manager, these subscriptions are removed. What this means is non-durable subscriptions can only be created programmatically using MQSUB(in C language) or it's equivalent method in Java/C#.
Non-durable subscriptions can not be created using MQSC or MQExplorer. You can create durable subscriptions using MQSC/MQExplorer.
Non-durable subscriptions exist only as long as the subscribing application's connection to the queue manager remains open. The subscription is removed when the subscribing application disconnects from the queue manager either deliberately or by loss of connection. When the connection is closed, the information about the subscription is removed from the queue manager, and will no longer be shown if you display subscriptions using the DISPLAY SBSTATUS command. No more messages will be put to the subscriber queue.
For more information, see Subscription durability