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
3 months, 1 week
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, 8 months
Possible to make context roots case insesnitive?
by Marc Boorshtein
If I create a DepoymentInfo and set the context path, can I make that
case-insensitive? I know its possible for the FileManager but i don't
see an option on the DeploymentInfo.
Thanks
Marc
7 years, 11 months
Re: [undertow-dev] When to call HttpServerExchange#endExchange explicitly?
by Girish Sharma
(Forgot to reply all)
One correction in my previous mail. The issue (connection being closed
before response is transferred fully) caused by calling endExchange only
happens in non-blocking exchange calls. In case exchange.startBlocking is
called, then the issue is not reproducible with or without endExchange call.
Regards
On Wed, Jun 6, 2018 at 6:27 PM Girish Sharma <scrapmachines(a)gmail.com>
wrote:
> Thanks for the response, Stuart. Based on your reply with respect to
> endExchange, it looks like it should not be cause of any incomplete
> response issue.
>
> With respect to thread safety and exchange, the exchange is always handled
> in a single thread. The only thing we do to exchange is the following
> (apart from reading/writing headers):
>
> public void handleRequest(HttpServerExchange exchange) throws Exception {
>> if (exchange.isInIoThread()) {
>> exchange.dispatch(this);
>> return;
>> }
>>
>> // and then later on (with or without calling exchange.startBlocking() ):
>>
>> exchange.getResponseSender().send(response.toString());
>>
>>
> Also, I have personally verified that without the explicit endExchange call, the full response is rendered with 100% certainty. While using the endExchange, the connection exits early sometimes.
>
>
> On Wed, Jun 6, 2018 at 8:26 AM Stuart Douglas <sdouglas(a)redhat.com> wrote:
>
>> If is basically just an convenience method that will close both the
>> request and the response for you, so you never *have* to call it. It also
>> has nothing to do with blocking exchanges, it will do the same thing either
>> way.
>>
>> From your TLDR it sounds like you are doing something wrong thread safety
>> wise. In particular it sounds like you may not be using dispatch()
>> correctly to make sure that only one thread 'owns' the exchange at a time.
>>
>> Stuart
>>
>>
>> On Wed, Jun 6, 2018 at 12:44 AM, Girish Sharma <scrapmachines(a)gmail.com>
>> wrote:
>>
>>> Hi there,
>>>
>>> I was wondering when to call the endExchange method on the exchange
>>> manually? Is it required to call it if we have called startBlocking() on
>>> the exchange?
>>>
>>> How is the getResponseSender().sen("SOME TEXT") behavior if we call
>>> endExchange() with and without a prior startBlocking() call
>>>
>>> *tldr;*
>>> I have been using Undertow for a while now. We were originally only
>>> using request parameters from the incoming request and thus, we never had
>>> to start the blocking exchange. Recently we started consuming the payload
>>> of a POST call and thus, we started blocking the exchange. Post this we
>>> observed memory leaks. While we were trying to figure out the cause of the
>>> memory leaks, we made a few changes. While the memory leaks got fixes, we
>>> started observing incomplete responses from some of the API. Basically, the
>>> exchange was being ended before the async, multi part, response was
>>> completely sent off. While trying to fix the issue, should I completely
>>> remove the explicit endExchange call or leave it there for the
>>> startBlocking() branch of code and only remove for non blocking exchange?
>>>
>>> Regards
>>> --
>>> Girish Sharma
>>>
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>>
>>
>
> --
> Girish Sharma
> B.Tech(H), Civil Engineering,
> Indian Institute of Technology, Kharagpur
>
--
Girish Sharma
B.Tech(H), Civil Engineering,
Indian Institute of Technology, Kharagpur
7 years, 12 months
When to call HttpServerExchange#endExchange explicitly?
by Girish Sharma
Hi there,
I was wondering when to call the endExchange method on the exchange
manually? Is it required to call it if we have called startBlocking() on
the exchange?
How is the getResponseSender().sen("SOME TEXT") behavior if we call
endExchange() with and without a prior startBlocking() call
*tldr;*
I have been using Undertow for a while now. We were originally only using
request parameters from the incoming request and thus, we never had to
start the blocking exchange. Recently we started consuming the payload of a
POST call and thus, we started blocking the exchange. Post this we observed
memory leaks. While we were trying to figure out the cause of the memory
leaks, we made a few changes. While the memory leaks got fixes, we started
observing incomplete responses from some of the API. Basically, the
exchange was being ended before the async, multi part, response was
completely sent off. While trying to fix the issue, should I completely
remove the explicit endExchange call or leave it there for the
startBlocking() branch of code and only remove for non blocking exchange?
Regards
--
Girish Sharma
8 years
