Issue with Undertow Client and SSL
by Thomas Segismont
Hi,
Openshift Origin uses Hawkular Metrics to store node and container data. In
this scenario, Hawkular Metrics calls the Kubernetes master server over
HTTPS to validate the client identity. This is implemented with Undertow
Client, as part of a ServletExtension (inside Wildfly 10) [1]. Works fine
in development and testing.
Now the Openshit team sees errors in the logs [2][3]. I couldn't reproduce
yet. Errors come in pair, first the "UT005001: An exception occurred
processing the request: java.lang.IllegalStateException: XNIO000017: Buffer
was already freed", and just after "XNIO001007: A channel event listener
threw an exception: java.lang.NullPointerException".
Does that ring a bell? I haven't been able to find a starting point by
looking into the source the code.
Thanks
--
Thomas Segismont
JBoss ON Engineering Team
[1] https://git.io/vrNyP
[2] https://issues.jboss.org/browse/HWKMETRICS-408
[3] https://issues.jboss.org/secure/attachment/12405779/hawkular.log
1 week, 4 days
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
2 years, 5 months
Unable to concurrently use all available IO Threads under load on Red Hat
by R. Matt Barnett
Hello,
I'm experiencing an Undertow performance issue I fail to understand. I
am able to reproduce the issue with the code linked bellow. The problem
is that on Red Hat (and not Windows) I'm unable to concurrently process
more than 4 overlapping requests even with 8 configured IO Threads.
For example, if I run the following program (1 file, 55 lines):
https://gist.github.com/rmbarnett-rice/668db6b4e9f8f8da7093a3659b6ae2b5
... on Red Hat and then send requests to the server using Apache
Benchmark...
> ab -n 1000 -c 8 localhost:8080/
I see the following output from the Undertow process:
Server started on port 8080
1
2
3
4
I believe this demonstrates that only 4 requests are ever processed in
parallel. I would expect 8. In fact, when I run the same experiment on
Windows I see the expected output of
Server started on port 8080
1
2
3
4
5
6
7
8
Any thoughts as to what might explain this behavior?
Best,
Matt
7 years, 6 months
Re: [undertow-dev] Unable to concurrently use all available IO Threads under load on Red Hat
by R. Matt Barnett
Quoting Carter Kozak <c4kofony(a)gmail.com>:
> When I run the test case locally I immediately see 1-8 printed.
> Perhaps there aren't many cores available on your test machine?
The test machine is an 8 core machine.
>
> Also note that writing the response is handled asynchronously, so it's
> likely not a very large percentage of the total request handling time
> spent inside your HttpHandler implementation.
>
Do you think the 1 second sleep in the body is not sufficient?
-- Matt
7 years, 7 months
Re: [undertow-dev] how to implement request processing timeout
by Stuart Douglas
On Mon, Jul 16, 2018 at 12:16 PM Stan Rosenberg <stan.rosenberg(a)gmail.com>
wrote:
> On Sun, Jul 15, 2018 at 9:48 PM, Stuart Douglas <sdouglas(a)redhat.com>
> wrote:
>
>> If all you want to do is drop the connection then just scheduling a task
>> that does exchange.getConnection().close() is fine, no HTTP response will
>> be returned to the client.
>>
>
> That would imply exchange.getConnection().close() is thread-safe; just
> double-checking.
>
Yes.
>
>
>>
>> If you want to actually send a response to the client then you are going
>> to have to have some kind of lock/CAS that prevents your application from
>> writing once the timeout has taken effect.
>>
>>
> Makes sense, but that's custom logic; i.e., not available in the API,
> right?
>
Yes. The issue with including something like this in the core API is that
every request has to pay the thread safety price even if they don't use it.
>
> Are you using the Servlet API or the HttpServerExchange API? The best way
>> to approach this is a bit different depending on what you are doing.
>>
>
> HttpServerExchange API
> . Thanks!
>
This is a bit harder to do in the general case. With Servlet you could just
create a thread safe wrapper, where the wrapper basically disconnects from
the underlying request on timeout. The Undertow native API is not designed
around wrapping though, so it needs cooperation from the application to
manage this.
If you know the application is only going to be writing data (and not
setting headers) then you should be able to make this work via a
ConduitFactory implementation that handles the locking, although if this is
not the case then you are going to need some kind of external lock.
Stuart
7 years, 7 months
how to implement request processing timeout
by Stan Rosenberg
Apologies if this question has already been answered elsewhere; closest I
could find is this thread:
http://lists.jboss.org/pipermail/undertow-dev/2014-August/000898.html
HttpServerExchange cannot be manipulated from multiple threads (without
locking). Thus, dispatch and executeAfter wouldn't work if the goal is to
end the exchange after the max. time to process (request) has been exceeded.
I can implement this timeout mechanism using out-of-band thread executor
but was hoping there is a more efficient way provided by the framework.
Thanks.
Best,
stan
7 years, 7 months
[1.4.23.Final] Invalid character | in request-target
by Brad Wood
I just had a user who updated to the latest version of my Undertow-powered
server report an error when his query string contained unencoded pipe
characters. (error at the bottom) This didn't happen in older versions but
appears to be a valid check. In this case, my user has no control over the
URL that's being sent to his site as it comes from a Microsoft Office365
app that opens a popup window to one of his URLs for authentication. It
looks like this:
https://127.0.0.1:1443/index.cfm/login:main/index?_host_Info=outlook|web|...
I have a feeling this is "working as designed" but is there a way to relax
the validation here as he has no control over this URL and it is a hard
stop for him?
[DEBUG] io.undertow.request.io: UT005014: Failed to parse request
io.undertow.util.BadRequestException: UT000165: Invalid character | in
request-target
at
io.undertow.server.protocol.http.HttpRequestParser.handleQueryParameters(HttpRequestParser.java:523)
at
io.undertow.server.protocol.http.HttpRequestParser.beginQueryParameters(HttpRequestParser.java:486)
at
io.undertow.server.protocol.http.HttpRequestParser.handlePath(HttpRequestParser.java:410)
at
io.undertow.server.protocol.http.HttpRequestParser.handle(HttpRequestParser.java:248)
at
io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:187)
at
io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:136)
at
io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:151)
at
io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
at
io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
at
org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at
org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
at
org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
at
org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
at
org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:129)
at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:582)
at org.xnio.nio.WorkerThread.run(WorkerThread.java:466)
Thanks!
~Brad
*Developer Advocate*
*Ortus Solutions, Corp *
E-mail: brad(a)coldbox.org
ColdBox Platform: http://www.coldbox.org
Blog: http://www.codersrevolution.com
7 years, 8 months
Re: [undertow-dev] Microprofile-OpenTracing Async issues in TCK when running on Wildfly
by Pavol Loffay
Adding this also to undertow-dev ML.
On Wed, Jul 11, 2018 at 7:09 PM Pavol Loffay <ploffay(a)redhat.com> wrote:
>
>
> On Wed, Jul 11, 2018 at 6:51 PM Alessio Soldano <asoldano(a)redhat.com>
> wrote:
>
>> I've pushed a fix for the ResteasyServletInitializer to master
>> https://github.com/resteasy/Resteasy/commit/1b3870b0b7210a8b4ab70eb51fc90...
>> ; we'll double check it with tck before next release, anyway.
>>
>> Going back to the issue, 3.0.24 basically removes any doubt I had
>> regarding recent asyn changes, it's quite an old version.
>> The AsyncListener ... is this
>> https://github.com/pavolloffay/smallrye-opentracing/blob/00f6c4dced4990b4...
>> what you're referring to and which you believe is not working? it's really
>> a servlet/undertow thing btw...
>>
>
> Yes the AsyncListener is added in the filter which your link references.
>
> Martin also commented here
> https://issues.jboss.org/browse/UNDERTOW-1258?focusedCommentId=13603809&p...
> on this issues.
>
>
>>
>> On Wed, Jul 11, 2018 at 2:40 PM, Martin Kouba <mkouba(a)redhat.com> wrote:
>>
>>> Also note that we use a modified ResteasyServletInitializer to init
>>> resteasy in the TCK:
>>> https://github.com/smallrye/smallrye-opentracing/pull/4/files#diff-ec8fa5...
>>>
>>> M
>>>
>>> Dne 11.7.2018 v 13:29 Martin Kouba napsal(a):
>>>
>>> You're right, 3.0.24.Final.
>>>>
>>>> Dne 11.7.2018 v 13:09 Pavol Loffay napsal(a):
>>>>
>>>>> Hi Alessio,
>>>>>
>>>>> resteasy version in Thorntail and SmallRye should be the same -
>>>>> 3.0.24.Final. I have added Ken and Martin in case I am wrong.
>>>>>
>>>>> Regards,
>>>>>
>>>>> On Wed, Jul 11, 2018 at 11:30 AM Alessio Soldano <asoldano(a)redhat.com
>>>>> <mailto:asoldano@redhat.com>> wrote:
>>>>>
>>>>> CC-ing Pavol, not sure he's subscribed to the list
>>>>>
>>>>> On Wed, Jul 11, 2018 at 11:29 AM, Alessio Soldano
>>>>> <asoldano(a)redhat.com <mailto:asoldano@redhat.com>> wrote:
>>>>>
>>>>> Hi Pavol,
>>>>> I'm forwarding this to the dev-list, so that the whole team can
>>>>> read and help.
>>>>> Can you start by telling which version of RESTEasy was used in
>>>>> the previous and current integration?
>>>>> There's been a bunch of changes around async lately, which
>>>>> might
>>>>> possibly be related to the issue you're seeing.
>>>>>
>>>>> Cheers
>>>>>
>>>>> ---------- Forwarded message ----------
>>>>> From: *Pavol Loffay* <ploffay(a)redhat.com
>>>>> <mailto:ploffay@redhat.com>>
>>>>> Date: Tue, Jul 10, 2018 at 6:15 PM
>>>>> Subject: Microprofile-OpenTracing Async issues in TCK when
>>>>> running on Wildfly
>>>>> To: Alessio Soldano <asoldano(a)redhat.com
>>>>> <mailto:asoldano@redhat.com>>
>>>>> Cc: jean-frederic clere <jclere(a)redhat.com
>>>>> <mailto:jclere@redhat.com>>
>>>>>
>>>>>
>>>>> Hi Alessio,
>>>>>
>>>>> Jean Frederic pointed me to you as the contact for issues
>>>>> related to Resteasy/undertow in Wildfly.
>>>>>
>>>>> I am migrating Microprofile-OpenTracing implementation from
>>>>> Thorntail [1] to SmallRye [2]. TCK in Thorntail was passing
>>>>> fine. Now when it's deployed on Wildfly a test for async
>>>>> endpoint is failing. Basically, the AsyncListener (added in
>>>>> filter) which reports some data is never called.
>>>>>
>>>>> The issue is described on the PR
>>>>>
>>>>> https://github.com/smallrye/smallrye-opentracing/pull/4#issuecomment-4038....
>>>>>
>>>>>
>>>>>
>>>>> Could you please have a look and comment on the PR? Is it safe
>>>>> to rely on AsyncListener. Can it happen that the listener added
>>>>> in the filter will not be invoked?
>>>>>
>>>>> [1]:
>>>>>
>>>>> https://github.com/thorntail/thorntail/tree/master/fractions/microprofile...
>>>>> [2]: https://github.com/smallrye/smallrye-opentracing/pull/4
>>>>>
>>>>> Regards,
>>>>> --
>>>>> PAVOL LOFFAY
>>>>>
>>>>> SOFTWARE ENGINEER
>>>>>
>>>>> Red Hat<https://www.redhat.com/>
>>>>>
>>>>> M: +41791562647
>>>>>
>>>>> <https://red.ht/sig>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Alessio Soldano
>>>>>
>>>>> Associate Manager
>>>>>
>>>>> Red Hat
>>>>>
>>>>> <https://www.redhat.com>
>>>>>
>>>>> <https://red.ht/sig>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Alessio Soldano
>>>>>
>>>>> Associate Manager
>>>>>
>>>>> Red Hat
>>>>>
>>>>> <https://www.redhat.com>
>>>>>
>>>>> <https://red.ht/sig>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> PAVOL LOFFAY
>>>>>
>>>>> SOFTWARE ENGINEER
>>>>>
>>>>> Red Hat<https://www.redhat.com/>
>>>>>
>>>>> M: +41791562647 <javascript:void(0);>
>>>>>
>>>>> <https://red.ht/sig>
>>>>>
>>>>>
>>>>
>>> --
>>> Martin Kouba
>>> Senior Software Engineer
>>> Red Hat, Czech Republic
>>>
>>
>>
>>
>> --
>>
>> Alessio Soldano
>>
>> Associate Manager
>>
>> Red Hat
>>
>> <https://www.redhat.com>
>> <https://red.ht/sig>
>>
>
>
> --
>
> PAVOL LOFFAY
>
> SOFTWARE ENGINEER
>
> Red Hat <https://www.redhat.com/>
>
> M: +41791562647
> <https://red.ht/sig>
>
--
PAVOL LOFFAY
SOFTWARE ENGINEER
Red Hat <https://www.redhat.com/>
M: +41791562647 <javascript:void(0);>
<https://red.ht/sig>
7 years, 8 months
UTF8 characters in response headers when using HTTP/2
by Kim Rasmussen
Hi,
I have a setup where I have my own variant of a ProxyHandler within
undertow.
In one case, I proxy requests towards an IIS running MailEnable - if I try
to download a webmail attachment where the filename contains non-ascii
characters, MailEnable sends the filename in UTF-8 characters in the HTTP
header.
I guess this is kinda a violation of the HTTP protocol, but thats how it is.
When I run my undertow proxy using HTTP1.1 between the browser and
undertow, everything works as expected - the browser detects and supports
UTF-8 characters in the filename in the HTTP headers.
But, if I run HTTP/2 between the browser and undertow, using Chrome I am
getting an SPDY_PROTOCOL_ERROR displayed within chrome.
So, I guess that it is because Chrome chokes on the UTF-8 characters in the
HTTP/2 headers - I tried digging into the spec but I cannot really find
anything mentioned there regarding restrictions on header content - just on
header naming.
Any suggestions ? I could of course strip the invalid characters from the
response header before forwarding them but wanted to check if there is a
better way first....
--
Med venlig hilsen / Best regards
*Kim Rasmussen*
Partner, IT Architect
*Asseco Denmark A/S*
Kronprinsessegade 54
DK-1306 Copenhagen K
Mobile: +45 26 16 40 23
Ph.: +45 33 36 46 60
Fax: +45 33 36 46 61
https://ceptor.io
https://asseco.dk
7 years, 8 months
