Mostly IO, non-blocking workload best practice
by Chris Back
I am writing a server that will need to respond to lots of small web
requests. Most of the requests will come with a small POST payload. Based
on the contents of the payload, the server will either a) respond
immediately, or b) forward the request as is to one of a pool of backend
servers, waiting for a response and forwarding the response back to the
client.
It looks like given the existing undertow code, I have good examples of how
to forward requests to the backend. What isn't as clear is how to handle
the getting the POST data. Is there a way of doing that without blocking?
Ideally, my handler flow would be:
1. Non-blocking request handler that makes sure all POST data is in.
2. A non-blocking handler that decisions based on content of POST data to
3a. Immediately return a response to the client (non-blocking).
or
3b. Dispatch to the worker pool to forward request to backend server and
await response.
90% of my requests will go through path 3a, and I'd like that to be as
quick as possible. When the server decides a request should go through 3b,
only then should it go to the blocking worker pool.
Am I viewing this correctly? What are my options? Based on this thread
http://lists.jboss.org/pipermail/undertow-dev/2015-January/001082.html
it seems like an option could be to get the request channel in step 1
above? Its not clear to me how that would work.
Thanks,
Chris
11 years
ServerSentEventConnection
by Fabian Mager
Hi all,
is there a way to access the queryParameters of an HttpServerExchange
object via a ServerSentEventConnection object? As far as I can see,
there is only access to certain members of the exchange object. In
case it is not possible, would it be problematic in some ways to
implement it?
Thanks in advance,
Fabian
11 years, 1 month
Changing proxy response
by ralf.battenfeld＠bluewin.ch
Hi
I am looking for a way to use the LoadBalancingProxyClient that changes the response received from the backend server. I came up with configuring a ResponseCommitListener. Is this the correct way of manipulating the response within the beforeCommit() call?
If yes, how can I change the response with the given HttpServerExchange instance? If not, what would be the best way to achieve this?
Thanks a lot for any help.
Ralf
11 years, 1 month
Forwarding request's parameters to error servlet
by Mohammed ElGhaouat
Hello,
I am working on few application's migration from Jonas which is based on
tomcat to Wildfly 8.2, some of theses applications are using the
<error-page> section of web.xml to forward the request to a specific
servlet.
if the user type something like:
localhost:8080/someunmappedurl/?param=elghaoua
the next error-page section force a forward to a specific servlet
<error-page>
<error-code>404</error-code>
<location>/specificServlet</location>
</error-page>
with tomcat this specific servlet receives the parameters of the initial
request but with Wildfly/Undertow these paramters are lost. tryed on the
Wildfly 8.2 and 9.0.1
Any idea how to fix this ?
Thank you !
11 years, 1 month
SSL Client Certificate Request
by Devl Devel
Hi group
I'm trying to get a client to present its certificate when it hits the
first request to my server
e.g. http://localhost/run
I want undertow to "ask" for client certificate.
I have an undertow server with an https listener and valid sslcontext with
trust and keystore. What steps are required to get a client to present the
certificate. Does any one have a basic hello world example?
I've tried to get hints from DefaultServer but maybe this is too much
detail for what I need and I can't find a good example in the docs.
Thanks in advance,
Devl
11 years, 2 months
InSessionMemoryManager synchronized methods
by Eric Peters
Chasing after another problem I found several blocked task threads, best as I can determine:
InMemorySessionmanager$SessionImpl.invalidate() is invoked.
This method is synchronized, and the call blocks inside SesssionListeners.sessionDestroyed() (separate issue there...)
Later, InMemorySessionmanager$SessionImpl.bumpTimeout() is invoked from another thread.
This method is also synchronized, and blocks waiting for invalidate() to complete. As the first thread is indefinitely blocked inside invalidate(), this second thread also remains blocked indefinitely.
In my environment it appears to make an existing problem slightly more severe.
Found in 1.1.0, but it looks like it's in both 1.1.7 and the master branch as well.
Using RHEL, Java 7, Wildfly 8.2
invalidate() Thread trace (excerpt):
* (blocked) - sun.misc.Unsafe.park(boolean, long)
* ...
* org.jboss.seam.contexts.ServletLifecycle.endSession(javax.servlet.http.HttpSession) (line: 187)
* org.jboss.seam.servlet.SeamListener.sessionDestroyed(javax.servlet.http.HttpSessionEvent) (line: 59)
* io.undertow.servlet.core.ApplicationListeners.sessionDestroyed(javax.servlet.http.HttpSession) (line: 264)
* io.undertow.servlet.core.SessionListenerBridge.sessionDestroyed(io.undertow.server.session.Session, io.undertow.server.HttpServerExchange, io.undertow.server.session.SessionListener$SessionDestroyedReason) (line: 67)
* io.undertow.server.session.SessionListeners.sessionDestroyed(io.undertow.server.session.Session, io.undertow.server.HttpServerExchange, io.undertow.server.session.SessionListener$SessionDestroyedReason) (line: 61)
* io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(io.undertow.server.HttpServerExchange, io.undertow.server.session.SessionListener$SessionDestroyedReason) (line: 413)
* io.undertow.server.session.InMemorySessionManager$SessionImpl.invalidate(io.undertow.server.HttpServerExchange) (line: 399)
* io.undertow.servlet.spec.HttpSessionImpl.invalidate() (line: 197)
* ...
bumpTimeout() Thread trace:
* io.undertow.server.session.InMemorySessionManager$SessionImpl.bumpTimeout() (line: 271)
* io.undertow.server.session.InMemorySessionManager$SessionImpl.getAttribute(java.lang.String) (line: 355)
* io.undertow.servlet.util.SavedRequest.tryRestoreRequest(io.undertow.server.HttpServerExchange, javax.servlet.http.HttpSession) (line: 124)
* io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(io.undertow.server.HttpServerExchange) (line: 67)
* io.undertow.security.handlers.SecurityInitialHandler.handleRequest(io.undertow.server.HttpServerExchange) (line: 76)
* io.undertow.server.handlers.PredicateHandler.handleRequest(io.undertow.server.HttpServerExchange) (line: 43)
* org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(io.undertow.server.HttpServerExchange) (line: 61)
* io.undertow.server.handlers.PredicateHandler.handleRequest(io.undertow.server.HttpServerExchange) (line: 43)
* io.undertow.server.handlers.PredicateHandler.handleRequest(io.undertow.server.HttpServerExchange) (line: 43)
* io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(io.undertow.server.HttpServerExchange, io.undertow.servlet.handlers.ServletChain, io.undertow.servlet.handlers.ServletRequestContext, javax.servlet.ServletRequest, javax.servlet.ServletResponse) (line: 261)
* io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(io.undertow.server.HttpServerExchange, io.undertow.servlet.handlers.ServletRequestContext, io.undertow.servlet.handlers.ServletChain, javax.servlet.DispatcherType) (line: 247)
* io.undertow.servlet.handlers.ServletInitialHandler.access$000(io.undertow.servlet.handlers.ServletInitialHandler, io.undertow.server.HttpServerExchange, io.undertow.servlet.handlers.ServletRequestContext, io.undertow.servlet.handlers.ServletChain, javax.servlet.DispatcherType)
* io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(io.undertow.server.HttpServerExchange) (line: 166)
* io.undertow.server.Connectors.executeRootHandler(io.undertow.server.HttpHandler, io.undertow.server.HttpServerExchange) (line: 197)
* io.undertow.server.HttpServerExchange$1.run() (line: 759)
* java.util.concurrent.ThreadPoolExecutor.runWorker(java.util.concurrent.ThreadPoolExecutor$Worker) (line: 1145)
* java.util.concurrent.ThreadPoolExecutor$Worker.run() (line: 615)
* java.lang.Thread.run() (line: 745)
//EricP
This message has been scanned for malware by Websense. www.websense.com
11 years, 2 months
