Currently I discover micronauts and regarding websockets, I am looking for a solution. Let me describe the idea and the issue:
A Browser connects to a microservice with a websocket endpoint
A session-ID may be send to the websocket endpoint to identify the client
On a different http request a long term async work has been started (e.g. with a message queue)
The process finishes and needs to tell the right websocket endpoint-thread to give this update to the browser.
But what would be a good way to tell the correct websocket thread, connected to the browser, an update is available?
What if there are more than one websocket microservices, called by a balancer? I think then they can not share any "Session" with an http server?
Can the exact websocket endpoint subscribe to a message service like Kafka?
I just found people asking the same with no answer. But it seems to be a typical issue.
Related
I want to run a Java based message broker that will route messages to web clients. Web client connections are handled on our server using our custom Java websocket code, which authenticates users against the user database.
I think my server side websocket handler code would connect to ActiveMQ and perform subscription management via AQMP.
I have a specific requirement however:
route messages for a topic specifically to one or more web clients
Note that I don't need to retain messages if a client is not connected. Messages are being used to inform the web client applications of actions they need to take.
I'm considering ActiveMQ but I was hoping people with experience of the product could clarify if it supports this requirement?
If ActiveMQ isn't the best option, could you recommend something else?
Thanks
Yes, ActiveMQ is a great choice for this.
As far as specific approach goes, it depends on your data model and message flow.
You have several options, including:
Produce and consume to a topic-per-client
a. Messages for Client ABC go to topic://CLIENTS.ABC, for Client XYZ go to topic://CLIENTS.XYZ, and the subscribers connect accordingly.
Produce a message with a header and use a consumer-side selector (aka 'filters' in AMQP) to filter messages on a per-client basis. (abc client subscribes to-- ClientId = ABC, xyz client subscribe to-- ClientId = XYZ)
When using WebSockets, you might also look to STOMP which is text-based protocol. (Just depends on your programming language and available libraries that you had in mind)
I'm developing a Java API for an Adndroid app in Spring. Right now my API is 100% REST and stateless. For the client to receive data, it must send a request first.
However, what I need is the server to send data to the to the client /not the client to the server fisrt/ whenever it is ready with it's task.
I think that some kind of session must be created between the two parties.
My question is: How can I achieve this functionality of the SERVER sending data to the CLIENT when it's ready with it's task? /It is unknown how long the task will take./
What kind of API should I develop for this purpose?
One idiotic workaround is sending a request to the server every n seconds but I'm seeking for a more intelligent approach.
There are multiple options available. You can choose what suits best for you.
Http Long Polling - In this, server holds the request until it's ready with its task (in your case). Here, you don't have to make multiple requests every few seconds (Which is Http Polling).
Server Sent Events - In this, server sends update to the client without long-polling. It is a standardized part of HTML 5 - https://www.w3.org/TR/eventsource/
Websockets - Well, websockets work in duplex mode and in this a persistent TCP connection is established. Once TCP connection is established, both server and client sends data to and fro. Supported by most modern browsers. You can check for Android Websocket Library like autobahn and Java websocket.
SockJs - I would recommend to go with this option instead of plain WebSocket. http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/#websocket-fallback-sockjs-enable
I use microservice architecture in my project. And for interservice communication I use message queue NATS. I wrote a gateway, that handle all http requests and put it to queue. All end point services are subscribed to this queue.
At endpoint services I use Xitrum based on Netty IO. When I get request from queue, I deserialise it to FullHttpRequest. But I don't know how to send it to my netty server, that can handle it according to business logic (without using external httpclient, for example, that can send it to localhost)
Is there any possibility to send FullHttpRequest instance to netty server (listening localhost:8000) using netty api? Or may be another solution. What is the common approach?
Please see the netty examples which has everything you need:
https://github.com/netty/netty/tree/4.1/example/src/main/java/io/netty/example/http/snoop
I am not as familiar with web services and I'm having a hard time finding information about a question regarding the way clients interact with a RESTful web service.
I've implemented a REST web interface to interact with clients using Java and the Jersey JAX-RS library, however I need to limit the number of connected clients to 6. If I have 6 clients connected and a 7th tries to connect, I need to know if one of the other 6 has disconnected at some point so I can give the new client a connection. Is there a simple way to tell on the server side if a client is still connected? Do clients maintain connection in a REST web service after they complete a request to the server? Normally the clients I'm dealing with make HTTP POST and GET requests to the server at least one a second.
The only thing I can think of would be to ping each connected client and wait for a response in the event of another client trying to connect. If one ping times out then I could replace that client with the new one. But I'm not really sure how that would impact server performance. If anyone has any input on a way too accomplish this, I would greatly appreciate it. Thanks!
I have a problem where I have several servers sending HttpRequests (using round robin to decide which server to send to) to several servers that process the requests and return the response.
I would like to have a broker in the middle that examines the request and decides which server to forward it to but the responses can be very big so I would like the response to only be sent to the original requester and not be passed back through the broker. Kind of like a proxy but the way I understand a proxy is that all data is sent back through the proxy. Is this possible?
I'm working with legacy code and would rather not change the way the requests and responses are processed but only put something in the middle that can do some smarter routing of the requests.
All this is currently done using HttpServletRequest/Response and Servlets running on embedded Jetty web servers.
Thank you!
What you're after is that the broker component is using the client's IP address when connecting to the target server. That is called IP spoofing.
Are you sure that you want to implement this yourself? Intricacies of network implementation of such a solution are quite daunting. Consider using software that has this option builtin, such as HAProxy. See these blog posts.