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
Re: [undertow-dev] Delay execution of a HttpHandler
by Bill O'Neil
Thanks for the suggestions Carter this is what I came up with let me know
if anything stands out as being incorrect. I was getting an error if I did
not call unDispatch and this seems to work.
*public* *void* handleRequest(HttpServerExchange exchange) *throws*
Exception {
Duration duration = durationFunc.apply(exchange);
*final* HttpHandler delegate;
*if* (exchange.isBlocking()) {
// We want to undispatch here so that we are not blocking
// a worker thread. We will spin on the IO thread using the
// built in executeAfter.
exchange.unDispatch();
delegate = *new* BlockingHandler(next);
} *else* {
delegate = next;
}
exchange.dispatch(exchange.getIoThread(), () -> {
exchange.getIoThread().executeAfter(() ->
Connectors.*executeRootHandler*(delegate, exchange),
duration.toMillis(),
TimeUnit.*MILLISECONDS*);
});
}
https://www.stubbornjava.com/posts/creating-a-non-blocking-delay-in-the-u...
Thanks,
Bill
On Fri, Jan 4, 2019 at 9:33 AM Carter Kozak <c4kofony(a)gmail.com> wrote:
> Perhaps some thing along these lines:
>
> public void handleRequest(HttpServerExchange exchange) throws Exception {
> exchange.dispatch(SameThreadExecutor.INSTANCE, () -> {
> exchange.getIoThread().executeAfter(() ->
> Connectors.executeRootHandler(handler, exchange),
> duration, unit);
> });
> }
>
>
>
> On Fri, Jan 4, 2019 at 12:53 AM Bill O'Neil <bill(a)dartalley.com> wrote:
> >
> > Hello,
> >
> > I'm looking for a way to add artificial latency to requests and I'm
> having trouble finding a way that wouldn't require a blocking pool with 1
> thread per request.
> >
> > What I would like to happen if possible.
> >
> > handler marks exchange as not ready (yield / pause)
> > async runnable from another thread marks it ready to resume after some
> time
> > next iteration of IO loop catches that it is ready and actually executes
> it now.
> >
> >
> > public void handle(HttpServerExchange exchange) {
> > if (firstExecution) {
> > scheduledExec.schedule(() -> exchange.resume(), duration, unit);
> > return;
> > }
> > next.handle(exchange);
> > }
> >
> > Is something like this possible while staying on the IO threads the
> whole time other than the ScheduledExecutorService? I was thinking of using
> dispatch and dispatching back to the IO executor but I don't think that
> will do what I intend.
> >
> > The end goal would be a way to handle N requests with various delays
> built in to simulate latency without blocking connections. For instance if
> the worker pool has 30 threads and I submit 100 requests with a 1 minute
> delay followed by 1 request with a 10 second delay the final request should
> come back first.
> >
> > Thanks,
> > Bill
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
6 years, 12 months
Configuring log levels
by Sugat Poudel
Hello all,
I noticed that the UndertowLogger is using the jboss logging classes. What is the best
way to configure log levels as it seems to be defaulting to DEBUG. I couldn’t find any specific documentation online and most were suggesting using a properties file.
Ideally, I would like to configure the levels in code so that we can change log levels in production without having to restart the server.
— Sugat
7 years
