Undertow jboss logging redirect to logback log file and console
by Steve Hu
Hi,
Undertow is using jboss logger to log errors and my application is using
slf4j/logback with logback.xml config file in the classpath with Undertow
core http server embedded. I handles most exceptions in my own handlers but
sometimes uncaught exceptions reaches Connectors class - executeRootHandler
method which logs the error and return 500 response code.
My first question: Is there a way to redirect the logs from Undertow to
logback logs and controlled by logback.xml? I've found some discussions
about replacing logger in WildFly but I am using embedded Undertow core
only.
Second question: When Connectors.executeRootHandler will be called? Is it
called when you have the following line in your handler?
if (exchange.isInIoThread()) {
exchange.dispatch(this);
return;
}
Is there any way we can by pass this so that I can handle uncaught
exceptions in my ExceptionHandler in the handler chain?
Thanks,
Steve
3 years, 8 months
Re: [undertow-dev] Tracing HTTP Response content
by Rohan Emmanuel
Hi,
i had a similar query, i want to store the entire response for my book
keeping , before it is flush out on to socket connection.
if while storing the response(using a cache to store) any IO error occurs ,
i want to send out 500 error instead.
Any thoughts on how can this be achieved?
--
Regards,
Rohan Emmanuel
3 years, 9 months
FormParserFactory getting stuck
by Hicks, Matt
I'm uploading files as "multipart/form-data" and using the FormParser as
follows:
FormParserFactory.builder().build().createParser(exchange).parse(nextHandler)
Sometimes this works fine, but very often my client shows progress up to a
certain percentage complete (monitoring the AJAX request) and then just
stops and never kicks to `nextHandler`, leaves the connection just sitting
there forever, and the server seems to stop accepting any future
connections.
Any idea what might be causing this?
3 years, 9 months
Undertow-handlers.conf parse error
by Rohan Emmanuel
I was using the Undertow-handlers.conf file to specify a request dumping
handler(dump-request). This works fine.
But when i add another handler to this file in the next line, i am getting
parse error as below. This file cannot take more than one handler? or am i
doing something wrong?
i was specifying two handlers in this file in two different lines.
[Server:server-one] Caused by: java.lang.IllegalArgumentException:
UT000045: Error parsing predicated handler string no handler named
dump-request
[Server:server-one] known handlers are [disallowed-methods,
allowed-methods, buffer-request, access-log, mark-secure,
response-rate-limit, canonical-path, response-code, disable-cache,
ssl-headers, trace, blocking, url-decoding, error-file, redirect, set,
ip-access-control, request-limit, resource, compress, restart,
haretry-handler, byte-range, done, rewrite, stuck-thread-detector,
reverse-proxy
, jvm-route, learning-push, dump-request, proxy-peer-address, header,
path-separator, resolve-peer-name]:
[Server:server-one] dump-request
[Server:server-one] ^"}}
[Server:server-one] 18:49:51,418 INFO [org.jboss.as.server.deployment]
(MSC service thread 1-4) WFLYSRV0028: Stopped deployment
image_servlet_req_dump.war (runtime-name: image_servlet_req_dump.war) in
140ms
[Server:server-one] 18:49:51,418 INFO [org.jboss.as.controller]
(ServerService Thread Pool -- 69) WFLYCTL0183: Service status report
[Server:server-one] WFLYCTL0186: Services which failed to start:
service jboss.deployment.unit."image_servlet_req_dump.war".POST_MODULE
[Server:server-one]
--
Regards,
Rohan Emmanuel
3 years, 9 months
SSL error: java.lang.NoSuchFieldError: DEFAULT
by Edgar Espina
Hi,
Got this error using undertow 1.4.9.Final. on jre 1.8.0_121:
Exception in thread "utow task-1" java.lang.NoSuchFieldError: DEFAULT
at
sun.security.ssl.ServerHandshaker.setupEphemeralECDHKeys(ServerHandshaker.java:1482)
at
sun.security.ssl.ServerHandshaker.trySetCipherSuite(ServerHandshaker.java:1272)
at
sun.security.ssl.ServerHandshaker.chooseCipherSuite(ServerHandshaker.java:1076)
at sun.security.ssl.ServerHandshaker.clientHello(ServerHandshaker.java:742)
at
sun.security.ssl.ServerHandshaker.processMessage(ServerHandshaker.java:225)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1026)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:966)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:963)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1416)
at io.undertow.protocols.ssl.SslConduit$5.run(SslConduit.java:1034)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
Thanks.
3 years, 9 months
Undertow servlet context
by Rohan Emmanuel
I am using wildfly 10 and have a filter in my web application which will
set a attribute in the servlet context.
public void init(FilterConfig arg0)
throws ServletException
{
ServletContext sc = arg0.getServletContext();
System.out.println("setting the servlet context");
sc.setAttribute("ha","ha is enabled for this application");
}
I want to get this attribute in one of my httphandler.
ServletRequestContext servletreqcontext =
exchange.getAttachment(ServletRequestContext.ATTACHMENT_KEY);
System.out.println("servletreqcontext-="+servletreqcontext);
the above code is returing NULL.
Any idea how can i get a handle on the servletContext in httphandler to
get this attribute?
--
Regards,
Rohan Emmanuel
3 years, 9 months
OpenSSL
by Kim Rasmussen
Hi,
I am trying to play around with the beta of the OpenSSL native engine at:
https://github.com/wildfly/wildfly-openssl together with undertow 1.4.10 -
running on windows with openssl 1.0.2k libraries.
But, I am not having a whole lot of luck.... meaning in general it seems to
work fine, but there is no SSLSession available, and thus no client
certificates, info about ciphers etc. - also since the session is not
present, Undertow sets the request scheme to "http" and not "https".
I have looked at it a bit, and I can see that the OpenSSLEngine seems to
always return null when calling getSession(), so it does look like the
engine is at fault.
The SSL engine has a ConcurrentHashMap of sessions, which is initialized
when OpenSSLSessionContext.sessionCreatedCallback() is called - but it
looks like it never is.
Do anyone else have it working with SSL sessions being available ? or know
of something obvious that I am doing wrong ?
Thanks.
/Kim
--
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
3 years, 9 months
Undertow servlet context
by Rohan Emmanuel
I am using wildfly 10 and have a filter in my web application which will
set a attribute in the servlet context.
public void init(FilterConfig arg0)
throws ServletException
{
ServletContext sc = arg0.getServletContext();
System.out.println("setting the servlet context");
sc.setAttribute("ha","ha is enabled for this application");
}
I want to get this attribute in one of my httphandler.
ServletRequestContext servletreqcontext =
exchange.getAttachment(ServletRequestContext.ATTACHMENT_KEY);
System.out.println("servletreqcontext-="+servletreqcontext);
the above code is returing NULL.
Any idea how can i get a handle on the servletContext in httphandler to
get this attribute?
--
Regards,
Rohan Emmanuel
3 years, 9 months
java.lang.OutOfMemoryError: Direct buffer memory
by Steve Hu
Hi,
I am working on the benchmark tests for TechEmpower and the following
handler got OutOfMemoryError. The tricky thing is 1.2.5.Final works fine
but 1.4.4.Final/1.4.10.Final fails with the error.
I am wondering what has been changed between 1.2 and 1.4 might cause the
problem. The application is running within a vagrant environment and memory
might be constraint.
Thanks,
Steve
public class PlaintextGetHandler implements HttpHandler {
private static final String MESSAGE = "Hello, World!";
@Override
public void handleRequest(HttpServerExchange exchange) throws Exception {
exchange.getResponseHeaders().put(Headers.CONTENT_TYPE, "text/plain");
exchange.getResponseSender().send(MESSAGE);
}
}
and the stacktrace
Server light-java: java.lang.OutOfMemoryError: Direct buffer memory
Server light-java: at java.nio.Bits.reserveMemory(Bits.java:693)
Server light-java: at
java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:123)
Server light-java: at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
Server light-java: at
io.undertow.server.DefaultByteBufferPool.allocate(DefaultByteBufferPool.java:146)
Server light-java: at
io.undertow.server.protocol.http.PipeliningBufferingStreamSinkConduit.write(PipeliningBufferingStreamSinkConduit.java:98)
Server light-java: at
io.undertow.server.protocol.http.HttpResponseConduit.processWrite(HttpResponseConduit.java:250)
Server light-java: at
io.undertow.server.protocol.http.HttpResponseConduit.write(HttpResponseConduit.java:596)
Server light-java: at
io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.write(AbstractFixedLengthStreamSinkConduit.java:106)
Server light-java: at
io.undertow.conduits.AbstractFixedLengthStreamSinkConduit.write(AbstractFixedLengthStreamSinkConduit.java:120)
Server light-java: at
org.xnio.conduits.ConduitStreamSinkChannel.write(ConduitStreamSinkChannel.java:154)
Server light-java: at
io.undertow.channels.DetachableStreamSinkChannel.write(DetachableStreamSinkChannel.java:187)
Server light-java: at
io.undertow.server.HttpServerExchange$WriteDispatchChannel.write(HttpServerExchange.java:2021)
Server light-java: at
io.undertow.io.AsyncSenderImpl.send(AsyncSenderImpl.java:219)
Server light-java: at
io.undertow.io.AsyncSenderImpl.send(AsyncSenderImpl.java:310)
Server light-java: at
io.undertow.io.AsyncSenderImpl.send(AsyncSenderImpl.java:282)
Server light-java: at
io.undertow.io.AsyncSenderImpl.send(AsyncSenderImpl.java:316)
Server light-java: at
com.networknt.techempower.handler.PlaintextGetHandler.handleRequest(PlaintextGetHandler.java:20)
Server light-java: at
io.undertow.server.RoutingHandler.handleRequest(RoutingHandler.java:93)
Server light-java: at
io.undertow.server.handlers.SetHeaderHandler.handleRequest(SetHeaderHandler.java:90)
Server light-java: at
io.undertow.server.Connectors.executeRootHandler(Connectors.java:211)
Server light-java: at
io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:243)
Server light-java: at
io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:134)
Server light-java: at
io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:58)
Server light-java: at
org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
Server light-java: at
org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
Server light-java: at
org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:88)
Server light-java: at org.xnio.nio.WorkerThread.run(WorkerThread.java:559)
3 years, 9 months
