Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-dev] Websocket in Jetty-10?


Guillaume,

there is a similar class in the new core API:



Examples of client/server usage of core are:

So porting to the core would give you the fastest possible implementation.

Currently my thinking is that we should drop the old jetty websocket API from jetty 10,  just for a bit of simplicity while getting that release stable.... but I don't think it is right to drop that API without adequate notice... so I think we will re-implement it on top of core and included as a deprecated API in 10 before it goes GA.

cheers






On Sun, 30 Sep 2018 at 01:35, Guillaume Maillard <guillaume.maillard@xxxxxxxxx> wrote:
WebSocketAdapter is what we are intensively using.
If nothing comparable (performance/memory wise) will be available in next release, it will be a real issue.
But if your JSR websocket API implementation offers the same level of performance, I see no reason to keep the old API and embrace the JSR one.

Regards,

Guillaume



Le sam. 29 sept. 2018 à 13:41, Joakim Erdfelt <joakim@xxxxxxxxxxx> a écrit :
In Jetty 9.4.x, the most efficient API for performance and memory is the Native Jetty WebSocket API.

If performance and memory are a concern to you, then the following decisions impact negatively.
From absolute worst decision to least worst.

* Streaming APIs usage (JSR356 InputStream, OutputStream, Reader, Writer)
* Encoders and Decoder usage (JSR356 again)
* permessage-deflate extension use (JSR356 and Native Jetty API, it improves network utilization at expense of memory and cpu)
* Large, whole message, delivery choices. (Use partial message delivery if you can, it will lower your memory usage)
* Large message buffer configurations.

Joakim Erdfelt / joakim@xxxxxxxxxxx


On Sat, Sep 29, 2018 at 3:28 AM Guillaume Maillard <guillaume.maillard@xxxxxxxxx> wrote:
Hi,

From the API point of view, even if the JSR API is quite different,
the websocket handling is simple (just 4 callbacks : connect,close,error, message).
The switch will not require a  lot of work.

My concern is more about performance and memory allocations,
what's the most efficient API ?

Regards,

Guillaume



Le sam. 29 sept. 2018 à 06:50, Greg Wilkins <gregw@xxxxxxxxxxx> a écrit :

I've taken this discussion to jetty-dev as it would be good to get wider feedback on the next steps.

We have a new implementation of the websocket protocol ready to be integrated into Jetty-10.  It is pretty much a total rewrite that applies a few years of experience with the protocol, current best practises from other protocols, plus knowledge of the demands of the JSR API and interest in a reactive streams API as well.

This implementation is in https://github.com/webtide/jetty.collaboration/tree/jetty-10.0.x-websocket/jetty-websocket/websocket-core and it is passing it's own extensive tests plus the autobahn test suite.

So next steps are to get it integrated back into the main branch of jetty-10.0.x and there are a number of challenges and choices for that:

The websocket core is currently in a single maven sub-project with top level package of org.eclipse.jetty.websocket.core.  It has been structured to be JPMS ready so that implementation classes are in 'internal' sub packages..   It also includes client and server sub packages with the client and server specifics (only a few classes for each).  The server and client dependencies are brought into the sub-project as provided dependencies, so they will not be included as transitive dependencies - so a client need not have server dependencies and versa vice.       However, it has been suggested that split into core, core.server and core.client sub-projects and matching jpms modules.     To me, that feels like a little bit of overkill, but unless there is a loud shout of "don't bother" I will go ahead as I think it will tie in well with the JPMS work we have been doing and will provide good JPMS modules that will provide a websocket client or server.

The JSR websocket API implementation has been taken on the refactor ride using jetty-core as it's protocol layer, but it has been a bit neglected, so that while it current compiles, but has a few failing tests.  Thus we need to focus on cleaning up this API layer and passing all it's tests.  We also need to check recent changes to jetty-9.4 JSR implementation and make sure we have all the needed updates.  That's just a bit of work and we'll get on with it in the next few weeks...   There is also probably similar packaging questions to core that need to be considered and resolved.

The next big question is what to do with the current jetty websocket API  https://github.com/eclipse/jetty.project/tree/jetty-9.4.x/jetty-websocket/websocket-ap:i ? This too was taken on the refactor journey with the development of the websocket-core, which is precisely the wrong thing to have done... as this has changed the API and will break backwards compatibility.   So there is a choice of which way to go forward:
  1. Just dump the old jetty websocket API and it will not be available in jetty-10.  Users can use either the JSR API if they want the standard, or program directly to the public parts of the websocket-core module, which effectively become the new  jetty websocket API.       This spares a lot of effort, which can be redirected into creating a reactive stream based API on top of websocket-core.
  2. Revert the websocket-api in the development branch to exactly the same as what is in jetty-9.4, and then write a new implementation of it using websocket-core.  This is a bit of work.
  3. Advance with jetty-10 development based on option 1 above.... it the screaming becomes too loud then switch to option 2.
Once we get some feedback and decide the direction, we will prepare some pull requests to get this work back into the main jetty repository.

cheers






--
_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev
_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev
_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev
_______________________________________________
jetty-dev mailing list
jetty-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev


--

Back to the top