Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Clustered Jetty WebSockets: accessing session in other servers

Hi,

On Mon, Apr 18, 2016 at 7:34 PM, Tickling Contest
<tickling.contest@xxxxxxxxx> wrote:
> Thanks for your response, Simone. It is not clear if you meant I have to
> rewrite my Jetty WebSockets-based application to a CometD based application
> (that's a lot of work, and I am not sure we can do that),

I don't know how much work would be to port your application logic to CometD.
Typically it's not a huge work to port only the application logic.

By using CometD you would be able to drop a lot of "infrastructure"
code that handles the WebSocket details.
For example, message relaying among nodes (solved by CometD), node
discovery (CometD), node crash detection (CometD), high level API
independent from transport (CometD), data distribution (CometD),
service forwarding (CometD), and a ton of other features.

> or if I can some how add CometD for just the specific problem I am facing on my Jetty-based
> WebSocket application.

>From what you describe you seem a bit out of path, as HTTP session
clustering is typically not a problem that you need to solve.
There is no HTTP if you're using WebSocket, and furthermore even if
you rely on that bit of HTTP during the WebSocket upgrade, it won't
solve your load balancing issue.
You certainly need load balancing sticking based on client IP
(connections) for WebSocket.

> How do I integrate CometD into my Jetty WebSocket
> based webapp? Are there examples out there?

That I cannot tell, since you don't describe what your application does.
There are plenty of examples in the CometD examples shipped with the
distribution (like 4 different chat implementations), or you can
borrow from the test suite or, for the distributed chat, the GitHub
repository that I linked in an earlier message.

The advantage of using CometD is that if WebSocket is not going to
work for you (e.g. mobile networks, antiviruses, firewalls,
transparent proxies, etc.), you can transparently fallback to HTTP
without changing a single line of code.

-- 
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.


Back to the top