[jetty-dev] Websocket in Jetty-10?

Discussion:

Greg Wilkins

2018-09-29 04:50:21 UTC

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

--
Greg Wilkins <***@webtide.com> CTO http://webtide.com

Guillaume Maillard

2018-09-29 08:28:26 UTC

Permalink

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

Post by 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
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
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
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev

Joakim Erdfelt

2018-09-29 11:41:12 UTC

Permalink

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 / ***@webtide.com

On Sat, Sep 29, 2018 at 3:28 AM Guillaume Maillard <

Post by 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

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

Guillaume Maillard

2018-09-29 15:35:29 UTC

Permalink

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

Post by Joakim Erdfelt
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.
On Sat, Sep 29, 2018 at 3:28 AM Guillaume Maillard <

Post by 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
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
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
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev

Greg Wilkins

2018-10-01 04:52:27 UTC

Permalink

Guillaume,

there is a similar class in the new core API:

https://github.com/webtide/jetty.collaboration/blob/jetty-10.0.x-websocket/jetty-websocket/websocket-core/src/main/java/org/eclipse/jetty/websocket/core/TextMessageHandler.java

which extends the primary interface for core:
https://github.com/webtide/jetty.collaboration/blob/jetty-10.0.x-websocket/jetty-websocket/websocket-core/src/main/java/org/eclipse/jetty/websocket/core/FrameHandler.java

Examples of client/server usage of core are:

-
https://github.com/webtide/jetty.collaboration/blob/jetty-10.0.x-websocket/jetty-websocket/websocket-core/src/test/java/org/eclipse/jetty/websocket/core/chat/ChatWebSocketClient.java
-
https://github.com/webtide/jetty.collaboration/blob/jetty-10.0.x-websocket/jetty-websocket/websocket-core/src/test/java/org/eclipse/jetty/websocket/core/chat/ChatWebSocketServer.java

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 <

Post by Guillaume Maillard
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

Post by Joakim Erdfelt
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.
On Sat, Sep 29, 2018 at 3:28 AM Guillaume Maillard <

Post by Guillaume Maillard
Hi,
From the API point of view, even if the JSR API is quite different,
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

Post by 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
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
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
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev

--
Greg Wilkins <***@webtide.com> CTO http://webtide.com

Greg Wilkins

2018-10-01 21:25:49 UTC

Permalink

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.

Post by Greg Wilkins
Guillaume,
https://github.com/webtide/jetty.collaboration/blob/jetty-10.0.x-websocket/jetty-websocket/websocket-core/src/main/java/org/eclipse/jetty/websocket/core/TextMessageHandler.java
https://github.com/webtide/jetty.collaboration/blob/jetty-10.0.x-websocket/jetty-websocket/websocket-core/src/main/java/org/eclipse/jetty/websocket/core/FrameHandler.java
-
https://github.com/webtide/jetty.collaboration/blob/jetty-10.0.x-websocket/jetty-websocket/websocket-core/src/test/java/org/eclipse/jetty/websocket/core/chat/ChatWebSocketClient.java
-
https://github.com/webtide/jetty.collaboration/blob/jetty-10.0.x-websocket/jetty-websocket/websocket-core/src/test/java/org/eclipse/jetty/websocket/core/chat/ChatWebSocketServer.java
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 <

Post by Joakim Erdfelt
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.
On Sat, Sep 29, 2018 at 3:28 AM Guillaume Maillard <

Post by 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
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
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
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-dev

--
Greg Wilkins <***@webtide.com> CTO http://webtide.com

Joakim Erdfelt

2018-09-29 11:43:10 UTC

Permalink

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?

Greg Wilkins

2018-09-29 12:12:55 UTC

Permalink

Post by Joakim Erdfelt
Greg,
In your proposal to dump the Native Jetty WebSocket API and using the
websocket-core instead.

Can you detail what this means?

Post by Joakim Erdfelt
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

Post by Joakim Erdfelt