Currently the Jersey SSE is implemented on top of blocking I/O, which is the reason why each new event source starts its own event processing thread. Until we implement NIO support in the core Jersey client module, we may not be able to change this approach, unfortunately.
As for the performance - yes, spawning a huge number of threads is certainly a potential performance problem, but the actual impact varies from use case to use case and environment to environment and as such it needs to be measured on the particular environment for a particular implemented solution. Perhaps you will find out that for your use case it works. If not, you may want to look for a different SSE client solution or consider replacing SSE with WebSocket.
In general, the SSE is a good technology for the job.
Cheers,
Marek
> On 04 Mar 2015, at 10:35, Svilen Genchev <svileng_at_gmail.com> wrote:
>
> No one has an opinion on this?
>
> Isn't there at least some documentation resource I could have a look at?
>
> Thanks,
> Svilen
>
> On 18 February 2015 at 16:17, Svilen Genchev <svileng_at_gmail.com <mailto:svileng_at_gmail.com>> wrote:
> Hi All,
>
> I am looking into using Jersey SSE to replace current polling mechanics of thousands of REST resources.The polling approach does not scale very well with increasing the number of registered nodes.
>
> I have a single client which manages a lot of servers in the sense that using the client one can register up to 10 000 nodes/servers, whereas each node has a set of REST resources.
> Some of those resources are polled lets say on a 30 second interval currently in order to keep the client up-to-date with information obtained from the REST resources. The information is usually in the form of free memory, disk space, cpu usage, etc.
> Think monitoring of some JVM process (with a servlet container and Jersey) running on a disparate hosts over HTTP/REST.
> While since it is mostly a monitoring data,It is not that critical to the client to be on par with the servers state down to the second (currently the polling is using 30 seconds interval), however on the other hand, some very important functionality of the client depends on whether a particular REST server is online and in what state it is.
>
> The data that is being polled itself is not supposed to change very often, so I started looking into SSE with the idea that the client/server are using some smart NIO approach in order not to keep the process busy if there is no data/events currently to be transmitted on the wire.
>
>
> So I've downloaded the latest jersey distro (2.18 I think) and started looking at it. I quickly got the basic SSE example running.
>
>
> The SSE resource is exactly as from the example, while the client is something like this. COUNT_EVENT_SOURCE can be as much as 10 000:
>
> public static void main(String[] args) {
> Client client = ClientBuilder.newBuilder().register(SseFeature.class)
> .build();
>
> for (int i = 0; i < COUNT_EVENT_SOURCE; i++) {
>
> WebTarget target = client.target(Constants.ENDPOINT);
>
> EventSource eventSource = EventSource.target(target).build();
>
> final int count = i;
> EventListener listener = new EventListener() {
> @Override
> public void onEvent(InboundEvent inboundEvent) {
> System.out.println("listener no. " + count + " event name: " + inboundEvent.getName()
> + "; " + inboundEvent.readData(String.class));
> }
> };
> eventSource.register(listener, "message-to-client");
>
> eventSource.open();
>
> }
> }
>
> I fired up a jvisualvm and observed that for each client a new thread is being created which is kept alive as long as the connection to the SSE resource is fine.
>
> So if I have a client that wants to use SSE for communication with as much as 10 000 SSE resources residing on different hosts/ports this would mean that I would have 10 000 long living threads for each of the SSE resources constantly taking up CPU time and 10 000 long living client sockets as well right?
>
> Which again does not seem like a very scalable approach...
>
> Can a Thread Pool with some reasonable size be used instead?
> In general, do you think that SSE is a good solution for a use case like this one?
>
> Thanks for reading this! :)
>
> Regards,
> Svilen
>
>
>