[jetty-dev] Websocket in Jetty-10?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[jetty-dev] Websocket in Jetty-10?

Greg Wilkins

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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] Websocket in Jetty-10?

Guillaume Maillard
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 <[hidden email]> 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
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] Websocket in Jetty-10?

Joakim Erdfelt-8
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 / [hidden email]


On Sat, Sep 29, 2018 at 3:28 AM Guillaume Maillard <[hidden email]> 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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] Websocket in Jetty-10?

Joakim Erdfelt-8
In reply to this post by Greg Wilkins
Greg,

In your proposal to dump the Native Jetty WebSocket API and using the websocket-core instead.
Can you detail what this means?  
What would we gain?  
What would we lose?
What will the changed API look like?

Joakim Erdfelt / [hidden email]


On Fri, Sep 28, 2018 at 11:50 PM Greg Wilkins <[hidden email]> wrote:

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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] Websocket in Jetty-10?

Greg Wilkins


On Sat., 29 Sep. 2018, 21:43 Joakim Erdfelt, <[hidden email]> wrote:
Greg,

In your proposal to dump the Native Jetty WebSocket API and using the websocket-core instead.
Can you detail what this means?  
What would we gain?  

We would save a bit of effort as we would not need to port and maintain the old API.

We would have a new API that is more up to date and without legacy stuff.

What would we lose?

We would lose backwards compatibility for all those who have implemented against the current API.

The new core API is simpler but offers less features.  This may result in pressure to add features to core... which is kind of against the while idea of core.


What will the changed API look like?

Basically just what is in the current collaboration core package... Perhaps split to client and server sub projects. There is a chat room example in tests that shows basic usage.


Another option is that we do port the old API into core, but deprecate it so that we don't need to maintain long term. If timing was different we could have done this in 9.4 so 10 could drop it.

Note that I'm undecided and had thought we'd support the existing API as is or with minor modifications. But the suggestion was made to drop it, so I'm sounding out that option... But deprecating first would be better practise.

Cheers


Joakim Erdfelt / [hidden email]


On Fri, Sep 28, 2018 at 11:50 PM Greg Wilkins <[hidden email]> wrote:

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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] Websocket in Jetty-10?

Guillaume Maillard
In reply to this post by Joakim Erdfelt-8
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 <[hidden email]> 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 / [hidden email]


On Sat, Sep 29, 2018 at 3:28 AM Guillaume Maillard <[hidden email]> 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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] Websocket in Jetty-10?

Greg Wilkins

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 <[hidden email]> 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 <[hidden email]> 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 / [hidden email]


On Sat, Sep 29, 2018 at 3:28 AM Guillaume Maillard <[hidden email]> 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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev
Reply | Threaded
Open this post in threaded view
|

Re: [jetty-dev] Websocket in Jetty-10?

Greg Wilkins
All,

I'm having a change of mind.  While the new websocket-core API if good, it is very much a creature of jetty internals. It thus can't be used by  a webapp without punching a big hole in the webapp classloader.   This is not something we want to do in jetty-10 (which has tighter control of that classloading boundary).    As we have already solved this issue for the existing API, then we should continue to support it (albeit deprecated) and instead work on a new API layer on top of core based entirely on JVM classes (eg Flow.Publisher<String>) that will not need classpath adjustments.

So this means a bit more work before the new websockets is available in 10.





On Mon, 1 Oct 2018 at 14:52, Greg Wilkins <[hidden email]> wrote:

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 <[hidden email]> 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 <[hidden email]> 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 / [hidden email]


On Sat, Sep 29, 2018 at 3:28 AM Guillaume Maillard <[hidden email]> 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 <[hidden email]> 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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
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
[hidden email]
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev