1

We are using jersey SSE for pushing events to the client.

We are using the following code to register for an event in the javascript side,

var source = new EventSource(<URL>);
source.onmessage = notifyEvent;

URL ==> on each URL different event registrations will be there which takes care of registering for that event. Eg:

http://localhost:8080/testapp/notification/comment/{userID} ==> used to register for comment notification for a specific user.

http://localhost:8080/testapp/notification/like/{userID} ==> used to register for like event for a specific user

notifyEvent ==> is the method defined which will be called when we receive any event.

The registrations and notifying of the events works perfect, until a client tries to register for 6 events, if its 5 events, registration and notification works perfectly alright.

When we try to register for 6th event, on the server side EventOutput data is returned successfully, but on the client side the jsp file keeps loading.

Why is it hanging exactly at the 6th event registration?

If there are 2 different client application running, each register for 5 events, during such situation all the event notification stuffs(register and notifying) works perfectly fine.

Gokul Kulkarni
  • 2,069
  • 3
  • 26
  • 42

2 Answers2

1

only six connection can be used at any point of time in a browser. that is a limitation in a browser.

Refer this link for more information SSE(EventSource): why no more than 6 connections?

Community
  • 1
  • 1
Sadanand
  • 1,080
  • 3
  • 13
  • 30
  • 1
    6 is the most common limitation, but it is arbitrary, and customizable in most browsers. (So bear in mind it may even be less than 6 for a given client.) – Darren Cook Jun 17 '14 at 18:50
1

As already answered, the 6 is a typical browser limit.

I'm not familiar with the Jersey framework, but what you should be doing is using a single connection for all your events: SSE keeps a socket open and those sockets will become a scarce resource as you try to scale.

There are two ways to do that. My personal preference (justified in chapter 8 of my book) is to just add a field, called "event" or something like that, to the JSON object you are sending to clients. Then use a simple switch in your event handler to call the actual function you want to handle each event. The alternative is to use a feature built-in to SSE, whereby you precede each data: line with an event: line.

So your clients would just connect to http://localhost:8080/testapp/notification/comment+like (where the last part of the URL could be how they specify which events they want to subscribe to) and then when there is a new comment the server would send:

event:comment
data:{"msg":"What a smashing StackOverflow answer!"}
    <-- Blank line

And when there is a new like it sends:

event:like
data:{"from":234552,"to":4733}
    <-- Blank line
Darren Cook
  • 27,837
  • 13
  • 117
  • 217
  • We followed something like this, All the requests will come to one resource(WebService) for registering for any kinda events, in that class a Map will be maintained abt what clients are registered for what events, so whenever any event occurs, corresponding clients will be notified about the same. In the response we will be sending the type of notification we are sending for, client side will handle it accordingly. – Gokul Kulkarni Jun 24 '14 at 09:42