Is it possible to do a dynamic subscription with spring WebSocket?
We have a multi-tenancy application and the need is to send messages to a group of users within the tenant. I am currently achieving his with a user-specific queue, but this is not effective as we are adding the same message to all the user's queues. The problem with using a tenant-specific topic is from the client any one case subscribe to the same topic once the topic name is known.
Any ideas or help will be appreciated.
You could use a Topic and subscribe it from every user (frontend).
Then you send the Messages for a group of Users to this Topic.
So every subscribed user get Updates broadcasted.
Perhaps this Tutorial would help.
https://www.dariawan.com/tutorials/spring/spring-boot-websocket-stomp-tutorial/
To make it more secure, you can add the SessionIDs to virtual groups, so its safe only specific users are allowed to subscribe the Topic.
Related
It is possible to get notify when another client was connected to same topic which is subscribed by same topic in mqtt.
ex: a client subscribed to : app/id another client also subscribed to app/id then both clients will get a message about number of clients subscribed to this particular topic.
if it is possible then please let me know.
The whole point of a pub/sub architecture is to unlink the producer of information (publisher) from the consumer (subscriber). Producers just publish to a topic and the broker deals with routing that message to any consumers that may have a matching topic pattern subscription.
There is no way to count how many clients may receive a given message at any particular time for the following reasons:
A subscriber may be using a wildcard topic pattern that happens to match the topic of the published message.
A subscriber may have a persistent session with a matching topic pattern but if currently off line and will receive the queued message when it next connects
With shared subscriptions there could be any number of clients pooled together subscribed to a given topic pattern, but only one of them will receive any given message as they are load balanced round the group.
There is no guarantee that there are ever any subscribers, in the same way there is no end to end delivery guarantee only between a single client and the broker.
In a sensibly implemented broker, subscription topic pattern matches are only evaluated when a new message is published, so the best you could ever get is how many clients the last message with a given topic was delivered to, as there is no efficient way to calculate the number in advance.
In the same way as your last question about topics, if you think knowing this is required then you need to rethink your design or your use of MQTT.
I have an SNS topic called onboard-user. A lot of microservices subscribe to this topic
for ex:
Emai microservice - to send the email
System preferences microservice -To set the defaults
There is a queue in these microservices that subscribes to the onboard-user SNS topic.
Now, if the email to the user needs to be resent, how should it be handled? onboard-user should not get a new message in that case as that has its own purpose and we would not want all of the microservices listening to it to be notified.
Having an alternate SNS topic for send emails doesn't sound like such a good idea and an overkill. what's the right way to handle it?
Why would an email need to be resent? Due to a transient error or due to some business logic initiated by an end user? The solution depends on the problem. I would argue that if you detect the case where a message needs to be recent that you either: (A) maintain separate resend email SQS queue OR (B) put a new message on the existing email queue with a field indicating that this is a resend.
Since SQS is pretty cheap, I could lean towards (A).
If my understanding is correct, you have single SNS topic to do multiple processing and that's why multiple microservices are listening to it. Please correct, if that is incorrect.
If that is the case, the better option is to:
a. Segregate email processing - keep a separate SNS topic for email purpose e.g. 'inform-user' and use it for retrying
b. If you can't segregate, then the only option in above scenario is to have "state" in the message itself. That means having an attribute in the message to indicate that it is for "retrying" and then the listener microservice should process accordingly.
Zendesk Support is a world-class site full of useful information. But after searching for, and reading, lots of articles I still have some very basic questions:
We run a travel site that takes bookings. We have a need to organise our emails so that everyone can easily find every email regarding an individual booking, both incoming and outgoing. (And later we would add other channels like chat and WhatsApp).
It seems to me that Zendesk Support would do this job well. But throughout the Zendesk site there only seems to be talk of using Support for problems.
1) I assume that it would also be good for bookings, is that right?
Ok, so we set up Zendesk and start using it. A client then writes to our chosen email address (we will retain and use one of our domain email addresses) and Zendesk Support automatically starts a thread and sends us an email to tell us about the new thread. We then open the Zendesk console, and find the thread.
2) To reply by email to the client we then write a comment in the Zendesk console - is that right?
3) And presumably our email system gets a copy of the comment?
4) What happens to our actual email system? - We will be doing everything in Zendesk, so all the usual maintenance of our email inbox is not being done - marking as read, cancelling stuff, moving to other folders and so on. How do people manage the inbox on the original email server?
Thanks for any help on this.
Zendesk Support is a world-class site full of useful information. But
after searching for, and reading, lots of articles I still have some
very basic questions:
We run a travel site that takes bookings. We have a need to organise
our emails so that everyone can easily find every email regarding an
individual booking, both incoming and outgoing. (And later we would
add other channels like chat and WhatsApp).
It seems to me that Zendesk Support would do this job well. But
throughout the Zendesk site there only seems to be talk of using
Support for problems.
You are correct in that a plurality if not majority of use cases are
for customer contact centers which usually focus on addressing issues
after they arise. At the same time, I know Zendesk is used for a
variety of other use cases including in your space.
1) I assume that it would also be good for bookings, is that right?
Ok, so we set up Zendesk and start using it. A client then writes to
our chosen email address (we will retain and use one of our domain
email addresses) and Zendesk Support automatically starts a thread and
sends us an email to tell us about the new thread. We then open the
Zendesk console, and find the thread.
Yep, that sounds correct. Details on the mechanism for configuring
the Support Address and redirecting messages to Zendesk can be found
here.
2) To reply by email to the client we then write a comment in the Zendesk > console - is that right?
While it is possible to work from an inbox, Yes, the main emphasis is
on working in the Zendesk agent console.
3) And presumably our email system gets a copy of the comment?
I would suggest to check out some of the articles provided by Zendesk
about email. forwarding, SPF, email archiving
4) What happens to our actual email system? - We will be doing
everything in Zendesk, so all the usual maintenance of our email inbox
is not being done - marking as read, cancelling stuff, moving to other
folders and so on. How do people manage the inbox on the original
email server? Thanks for any help on this.
Basically, Zendesk will be used by agents to respond to communications
and guide the interactions, and the email box can be considered as
operational in directing emails as needed. Separately you can
configure email archiving as linked above.
Depending on what system you're using, Gmail has a built in connector
described here, details on Exchange here, or something else here.
What do you want the interaction to look like between it and Zendesk
and what does your current operation look like compared to motivation
for using something like Zendesk?
From the xep-0045: http://xmpp.org/extensions/xep-0045.html#enter-history
It seems that user can only get room history messages when he is joining the room. For example, user can get 20 messages when joining the room.
But after joined the room, If user want more history messages, there seems no way achieve this.
Any ideas?
I have resolve this issue. There are two solutions:
1. Current ejabberd MAM does not support MAM MUC. But there is a branch that you can use for testing. Remember it is not public released yet.
https://github.com/processone/ejabberd/blob/master/src/mod_mam.erl
write a module to hook the user_send_packet, in the hook, store the MUC messagess in SQL. Then provide a http API to request the MUC messages. From the client side point of view, I use the HTTP API to query the MUC history messages.
refer to this thread:
ejabberd MAM does not work for MUC
I have an API where users can create, what I call, orders.
I enqueue those orders and process them via Sidekiq gem. When the process is done, I currently send an email to the user. However, I am looking on how to notify him programatically.
So, sending the user a POST request to a particular endpoint, telling him that the order has been processed.
I am wondering which kind of security or other technical things I should take into account when doing this, or if there is any kind of gem that would help me on developing this.
you can check pub/sub pattern to do this...
when sidekiq finish processing then you publish an event... and you register the browser to listen to this event... which is better than sending the user a POST request to a particular endpoint, telling him that the order has been processed.
there are many libraries out there that can help you implementing the pub/sub pattern check the following...
PubNub
Pusher
Bunny
RabbitMQ
Redis
please note that you will have to use the rails app as the publisher and the front end as the subscriber ( you can check equivalent libs for JS )
and if you are interested in implementing the pub/sub within the same rails app... i've looked a lot and found that only those are the working solutions ( for app to publish and listen to his published events without getting locked in the process )
EventBus
Event_BG_Bus
Wisper
this is a post on how to use those gems to implement pub/sub pattern