Are you adding the listener before dispatching to the next handler or afterwards?
On Tue, 7 Jul 2020 at 06:32, Brad Wood <bdw429s@gmail.com> wrote:I hate asking generic questions, but I'm looking for a little understanding or clarification on request lifecycles. If you haven't noticed, I've had several recent threads that touch on this. Before anyone asks,
- Yes, I have read all the docs I can find on this Ex
http://undertow.io/undertow-docs/undertow-docs-2.0.0/undertow-request-lifecycle.html
http://undertow.io/undertow-docs/undertow-docs-2.0.0/#listeners-2
http://undertow.io/undertow-docs/undertow-docs-2.0.0/servlet-using-non-blocking-handlers.html- Yes, I have Google and read 3rd party docs and guides on Undertow. Ex:
https://www.oreilly.com/library/view/jboss-developers-guide/9781788296199/6f28737f-3374-49f9-8a68-f3a233285aae.xhtml- Yes, I have spent hours reviewing the code and experimenting
I've learned a lot, but there's a couple elusive things that all the docs and guides I see don't quite seem to satisfactorily explain for me.I'm trying to get some clarification on exactly what part of the request happens inside the xnio worker thread and which part runs inside the ThreadPoolExecutor. My server bootstrap wraps a number of various HttpHandlers around the handler that I set into the server builder and I had originally assumed that those handlers were part of the same handler chain that invoked the servlet. This appears to not be the case. The handler chain I pass to the server builder appears to execute as part of the org.xnio.nio.WorkerThread.run() thread, while my servlet code executes inside a thread pool executor.Both stack traces show that there is a chain of handler.handleRequest() calls, but this duality causes some confusion and troubles for me. It also seems to explain to an extent why Stuart's previous messages treated the "servlet" as a concept so far removed from the initial handler chain.Even docs like the last link I provided above that contain this image...make it sound like there is a single "root handler". However, executeRootHandler appears in the stack traces of both the XNIO worker as well as during the servlet chain in the thread pool executor.at io.undertow.server.handlers.SSLHeaderHandler.handleRequest(SSLHeaderHandler.java:105)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:255)at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:99)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:376)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)This has proved to create difficulty in trying to accomplish seemingly very simple tasks with Undertow. For example, an example I gave in a previous thread was a simple task of logging every HTTP request that returned a non-successful status code. Seems easy enough, right? However...
- I can't use an exchange complete listener because it doesn't fire with handlers like response-code that end the exchange
If you add the listener before the response code then it will work fine. Basically if you want to look at the result of a request you should do it in a listener, and you should add the listener as early as possible.
- I can't wrap the servlet handler chain because that chain is never invoked if the exchange is ended first by my predicates
- I can't wrap the handler chain being run in the XNIO listener because it doesn't wrap the servlet chain so my "before" and "after" code all runs before the servlet chain starts.
I would love any help and insight both on my general question for documentation regarding the two separate handler chains as well as my more specific question above about implementing something as simple as a handler/listener that always runs at the end of an exchange.You can actually have more than 2, you can have any number, as Servlet requests can go async and then get re-dispatched back, and you can do similar things in core Undertow as well (e.g. BufferedRequestHandler will read the full request using buffered IO, which may cause the stack to return and then start again in the IO thread once all data has been read). If you want to act at certain points in the request you need to do it in a listener.With regard to listeners not being fired after the exchange has ended generally once the exchange has ended nothing else is exected to happen, so it seems a bit odd that you are still doing processing. Are you adding the listener before dispatching to the next handler or afterwards?Stuart_______________________________________________Thanks!~BradDeveloper AdvocateOrtus Solutions, CorpE-mail: brad@coldbox.orgColdBox Platform: http://www.coldbox.org
undertow-dev mailing list
undertow-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev