Correctly shutting down a websocket handler
by Robin Anil
When a client disconnects, I see that onClose is not being fired. The only
way this seems to be firing if client sents a close frame.
Is there any way to detect disconnection and immediately close all the
opened resources.
Robin
Robin Anil | Software Engineer
1 year, 3 months
Undertow 3.0 Announcement
by Stuart Douglas
The Java network programming world has come a long way since Undertow was
first started. Netty has emerged as the de-facto standard for network
programming in Java, and the Undertow team has decided that the benefits of
utilising Netty outweigh any benefits in keeping our XNIO based transport
layer.
Undertow 3.0 will keep Undertow’s programming model, however the underlying
transport will be changed from XNIO to Netty. We will also use the Netty
HTTP/1, HTTP/2 and Websocket implementations. We believe this change will
have a number of advantages:
-
It will allow other Netty based services (e.g GRPC) to share the same
HTTP port
-
It allows sharing of threads between Undertow and other Netty based
services, resulting in services using less resources
-
The underlying transport implementation are the most complex part of
Undertow, delegating this to Netty will significantly reduce the work
needed to maintain Undertow
As part of this Flavia Rainone will be taking over as project lead from
Stuart Douglas so he can focus on the recently announced Quarkus project,
however Stuart will continue to be heavily involved in Undertow for the
foreseeable future.
Flavia Rainone has been involved in JBoss community since 2002 and has an
extensive background on Remoting and Xnio. In the past years, she acted as
EJB component lead for WildFly, besides contributing to several projects
in WildFly, such as IronJacamar, JBoss MSC and XNIO, and also Byteman. All
this makes her a good fit for taking over Undertow leadership.
What does this mean for me?
What this means for you will depend on which parts of Undertow you are
using:
-
If you are using the Servlet API then you will likely not notice any
change. You will need some different dependencies (Netty instead of XNIO),
however the rest of the experience should be mostly identical
-
If you are using the low level Undertow HttpHandler and
HttpServerExchange and you want to use Undertow 3.0 then you will need to
migrate your application. For the most part this migration should be
straightforward, as most concepts from the old API directly map to the new
API.
Road Map
2.x
The existing Undertow 2.x branch will continue to be maintained for the
foreseeable future. It will receive bug and security fixes, and some
features, however it is unlikely to receive any more low level transport
oriented features (e.g. HTTP/3 support). For now it is a perfectly valid
choice to stay on Undertow 2 while the new Netty based implementation
matures.
3.x
A 3.0 final version should be released in the next few months, however in
the short term the 3.x branch will not provide the same level of API
compatibility that Undertow has traditionally provided. As the Netty
implementation is new this will allow us to potentially fix any issues we
find with our approach without being locked in to supporting an API that is
not ideal.
This is a great time to try out the new API and report and problems or
suggestions. Note that this is explicitly referring to the core
HttpServerExchange based API, no major plans are expected to the Servlet
API (i.e. ServletExtension and DeploymentInfo).
4.x
After a short 3.x cycle we are planning on releasing a 4.x that will
provide API stability, in the same way that Undertow 1.x and 2.x have.
How can I contribute
You can contribute to Undertow in the same way it has always been done.
We have an email list open for discussion here: undertow-dev(a)lists.jboss.org
Jira issues can be accessed here:
https://issues.jboss.org/projects/UNDERTOW/issues
And source code for 3.x is here:
https://github.com/undertow-io/undertow/tree/3.0.x
Also, with the move from HipChat to Zulip in Wildfly team, you can now
access Undertow stream via Zulip at https://wildfly.zulipchat.com/
5 years, 6 months
JWT implementation
by Goutham Muppala (gomuppal)
Hi All,
I am trying to implement JWT token based authentication on wildfly 10.1.0.11. I don’t see any documentation related jwt token support for this version.
Can anyone provide pointers on this?
Thanks,
Goutham
5 years, 8 months
[3.x] HttpString migration
by Carter Kozak
Greetings,
I'm curious what the plan is for HttpString in undertow 3.x, since this will potentially be the most frequent migration for components which don't implement custom xnio mechanisms. At the moment, the 3.x branch has replaced most uses of HttpString with String, however netty provides a similar AsciiString type which may provide similar performance characteristics to HttpString. Have we considered using the Netty type directly where HttpString is currently used, or using CharSequence instead of string since AsciiString already implements CharSequence, and HttpString may be updated to support it? Based on UNDERTOW-147 [1] I suppose there's some question as to whether or not a non-string type is desirable for Servlet uses.
Thanks,
Carter
1. https://issues.jboss.org/browse/UNDERTOW-147
5 years, 8 months
wildfly:microprofile-metrics + Undertow
by paroczizs
Hi Undertow Dev,
I am using Wildfly 15.0.1, the microprofile metrics are enabled:
<subsystem xmlns="urn:wildfly:microprofile-metrics-smallrye:1.0"
security-enabled="false" exposed-subsystems="*"/>
the undertow module statistics is enavbled:
<subsystem xmlns="urn:jboss:domain:undertow:8.0" ...
statistics-enabled="true">
however the /metrics page does not contains any http related statistics.
Do I have to set any other configuration to see the undertow related
statistics?
Regards, Zsolt
5 years, 8 months
(no subject)
by paroczizs
Hi Undertow Dev,
I am using Wildfly 15.0.1, the microprofile metrics are enabled:
5 years, 8 months
Undertow 3 API Migration
by Darran Lofthouse
I have been looking at the steps required to migrate the WildFly Elytron
integration to Undertow 3 from Undertow 2.
Overall it seems minimal changes are required but I was thinking if there
could be an opportunity to evolve the API within Undertow 2 making
migration to 3 easier in the future.
One example being on SSSessionInfo we make use of the following method: -
void renegotiate(HttpServerExchange exchange, SslClientAuthMode
sslClientAuthMode) throws IOException;
which has now been changed to: -
void renegotiate(HttpServerExchange exchange, ClientAuth sslClientAuthMode)
throws IOException;
The first form is making use of Xnio API and the second is using Netty API.
If this was deprecated in Undertow 2 and a pure Undertow variant added it
could be usable both in 2 and 3.
I suspect a number of the other changes breaking API compatibility could be
handled in a similar way.
Regards,
Darran Lofthouse.
5 years, 8 months
Re: [undertow-dev] Lightweight integration tests
by Robin Anil
Hi Undertow-dev
Could you see this request. Apologies for pinging Stuart directly. But I am
looking for ways to write tests that exercise the undertow handler chain
tests going through the network.
Robin
On Wed, Mar 20, 2019 at 6:11 PM Stuart Douglas <sdouglas(a)redhat.com> wrote:
> Not in the near future. I have mostly been working on Quarkus for the
> moment, and Flavia has taken over as Undertow lead (I am still involved in
> the project, I just don't have as much time to spend on it).
>
> Stuart
>
> On Thu, Mar 21, 2019 at 2:02 AM Robin Anil <robin.anil(a)gmail.com> wrote:
>
>> Stuart, just checking in again, is doing a local invocation of handlers
>> without involving network on your radar?
>>
>> Robin
>>
>> On Thu, Mar 15, 2018 at 4:44 PM Robin Anil <robin.anil(a)gmail.com> wrote:
>>
>>> Not a lot of data. But most of our handlers are very fast and out test
>>> suite is in the 2000 range and increasing
>>>
>>> - from a phone, xquz typoz
>>>
>>> On Mar 15, 2018 4:35 PM, "Stuart Douglas" <sdouglas(a)redhat.com> wrote:
>>>
>>> For servlet there
>>> is io.undertow.servlet.handlers.ServletInitialHandler#dispatchMockRequest,
>>> however it is Servlet only at the moment and it pretty basic.
>>>
>>> That said though I am currently looking at adding support for a new
>>> client+proxy implementation, and one of the things I want to support is
>>> local invocation without involving the network, so doing a more general
>>> version of this was on my radar.
>>>
>>> I am still surprised that the network is causing issues for your
>>> integration tests though. How much data are these tests sending?
>>>
>>> Stuart
>>>
>>> On Fri, Mar 16, 2018 at 6:14 AM, Robin Anil <robin.anil(a)gmail.com>
>>> wrote:
>>>
>>>> Hi Stuart,
>>>>
>>>> Is there a way to bring up undertow programmatically where the
>>>> underlying HTTP/https transport is removed in favor or direction function
>>>> calls
>>>>
>>>> Effectively, we have accumulated a lot of integration tests and are
>>>> looking for ways to speed them up and at the moment, 80% of CPU time in the
>>>> test is pretty data copies back and forth at the HTTP client and HTTP
>>>> server.
>>>>
>>>> Before I start refactoring our HTTP-handler chains to fake-undertow, I
>>>> thought it might be good to ask.
>>>>
>>>>
>>>> Robin
>>>>
>>>
>>>
>>>
>>
>> --
>>
>> [image: Tock]
>> <https://www.exploretock.com/?utm_source=email&utm_medium=signature>
>>
>> Robin Anil
>> Director of Engineering
>>
>> Tock / exploretock.com
>> <https://www.exploretock.com/?utm_source=email&utm_medium=signature>
>>
>
--
[image: Tock]
<https://www.exploretock.com/?utm_source=email&utm_medium=signature>
Robin Anil
Director of Engineering
Tock / exploretock.com
<https://www.exploretock.com/?utm_source=email&utm_medium=signature>
5 years, 8 months
How to feed data to websockets from an external source
by Mátyás Bene
Hi all,
I would appreciate any kind of guidance and information about how to use undertow in a scenario where we'd like to poll an external source for messages (e.g. kafka) and feed those messages to all the connected websocket sessions.
So far the only examples I've found were about mirroring the messages received from http/websockets back to other websocket sessions or write those messages to Kafka. What we'd ideally need is READ from kafka (e.g. using a dedicated thread, busy-spinning and polling) and pass the retrieved data to undertow (ideally within the JVM without going through HTTP / REST) that would then send them over websockets to the connected clients.
A separate, but related question is, assuming that we were to use the websocket-JSR interface, that is it safe to assume that undertow ensures that at any given time only a single thread is writing to a specific websocket session, especially when using the asyncremote.send() method? Would undertow be able to paralellize all the async send operations using multiple threads to speed up sending?
M.
5 years, 8 months
