Share Websocket Session between Spring Micro Service - spring-boot

I've a Spring boot Application for Web sockets. I'm not using Stomp Web socket.
Is there way we can share web socket sessions across multiple instance of micro service.
Is there a way we can save websocket session in Redis or cassandra?
My use case is, i've multiple instance of my micro service is running, which is listening a kafka queue, so when a message received, i need to send it to the client using web socket session.I'm saving the session in the micro service as a MAP. My problem is any one of my micro service is getting the message, if the session is not available with that micro service the message is not going to the client.
If i'm able to save the websocket sesssion in REDIS or Cassandra, i can query the session and sent to the client.
I can't use Stomp web socket as per the requirement, it has to be normal websocket.

You can't. You have to implement some sort of routing from whatever receives the kafka message, to your micro service.
One simple way to do it would be to store in any datastore (mongo, redis, etc) the IP of the service instance for a given client. That way when you get the message from kafka, an you know who is it for, you lookup which machine has the websocket session for that client. Then you call some http endpoint on that IP that you implement to relay a message for a session it's handling.

Related

Building realtime messaging app with websockets in spring boot

I want to build a messaging backend service (similar to whatsapp) using spring boot and websockets.
I have look online at the examples of spring boot websockets.
I see how I would send a message to the server from client 1 using the #MessageMapping annotation.
However assuming client 2 (recipient of the message) is also connected to the server with websockets how would I send a message to them.
I have seen the sendToUser annotation however it seems to me that that sends the message to client 1 (the sender of the message).
Is there a map of client ids to websocket sessions or something so that if I know the message should go to (client 2). I can gethis active websocket session and then send him the message?

How to dynamically create queues in Springboot for websocket messaging

I'm using websockets to build a chat server in springboot. Now my application lacks any kind of Spring Security information since it is intended to only act as a channel between two desktop clients.
So currently I'm able to broadcast messages to all clients, however, I would like to know, is it possible to create dynamic queues when a client connects to other user, (a queue is created and they both subscribe to same queue). The queue exists until one of the client disconnects.
I'm using SimpleMessageBroker priovided with Spring.

Microservice synchronous communication - service to service or message broker

I am developing a series of microservices using Spring Boot and Kafka. For asynchronous communication, I am using Kafka which is working well.
I have a use case where I require synchronous communication between two microservices (a user registers a profile via the user profile service which needs to create an auth account in the auth microservice).
Should I just call the auth service directly (service to service communication) or should I use Kafka?
Any examples or best practise advice would be appreciated.
There are multiple factors that can drive your decision:
Required any acknowledgement from your Auth Service?
if yes:
For Immediate acknowledgement, use http
For not so immediate acknowledgement, Callback pattern can be implemented.
In your case, user profile sends request via Kafka to auth service and it calls
endpoint of user-profile to report status of the job.
if no:
Use queue one for better resiliency.
Error Handling
Think of auth service failure? What should be the reaction of user service ?
if on auth-service failure, user-service should also fail
Use http
if on auth-service failure, user service should not fails.
Use queue
Ideally in user creation and authentication realtime response is given to the client side but if it involves complex process or tasks post user creation queue should be preferred.
For multiple microservices synchronous interaction and to work on their API responses you can build a aggregator service which could serve as a communication medium between different services and work alongside your kafka queue consumer service.

Spring without views

I am new to spring and so not sure if what I intend to do is possible.
I need to create an asynchronous webservice and a worker server (broker), both using the model & controller aspects of spring.
The webservice needs to send it's client's requests on to the broker via JMS and then instantly send a response back to the client indicating the request has been queued.
The broker is intended to remain live, processing messages from multiple webservice instances and sending back the results via an output JMS queue. The reason the broker needs to remain live is because the work to process each webservice message involves calling other webservices, some of which may be asynchronous and which may take a lot of time to process.
Additionally I do not want to spawn multiple instances of the broker as it is designed to handle multiple concurrent messages.
Is it possible to create both the webservice and broker within the same spring project, with both running in a web container such as tomcat or do I need to code them in separate projects, with perhaps the broker as a traditional standalone server rather than a web container servlet?
If so could someone point me in the right direction to creating a stay-alive broker within spring/tomcat.
I understand the webservice and JMS side of things, so do not need any help with that.

A webapp that uses Spring AMQP is that consired to be 1 client?

Hi there i am wondering if i create a webapp that uses Spring AMQP. Is that single webapp 1 AMQP client? Or is every request made by a user that results into an AMQP call a client, so potentially x numbers of clients?
I don't know AMQP much, but I suspect it has the same terminology as jms. In that sense your application is probably pooling connections to AMQP broker for better performance. Each connection in a pool is treated as a separate client (competing consumer).
Thus each request is not really creating a new connection (client), but your application isn't a single client as well. In fact, when your application tries to access AMQP broker, it picks any connection from the pool and puts it back once it's done. Another request can reuse the same connection (client) or use a different, idle one.

Resources