Not really, the reason why you are only allowed to call it once is
because in general a single handler should 'own' the action of reading
from the request (because after the first handler has read from the
request channel there will generally be nothing left to read).
If you really need two handlers to look at the request you can read
the full body in an early handler, and attach it to the exchange, and
then have the later handlers just examine the buffered data. Obviously
if the requests are large this can cause memory exhaustion issues, so
you need to make sure you have some kind of limit in place.
Stuart
On Wed, Sep 21, 2016 at 6:10 PM, paroczizs . <paroczizs(a)gmail.com> wrote:
Hi,
we are implementing a proxy solution based on Wildfly/Undertow.
There are a couple of custom handler configured in a row. Two of the
handlers are deal with the incoming request – message validator and message
log.
The message validator use the solution form this class to read the incoming
request:
core/src/main/java/io/undertow/server/handlers/RequestBufferingHandler.java
The message log based on conduits and logs on the exchange complete event.
It works almost perfectly however the first request fails with this when the
log handler registers the conduit:
2016-09-21 10:05:02,034 INFO [hu.telekom.lwi.plugin.log.LwiLogHandler]
(default task-1) [lwiId-lpx1474445101966] LwiLogHandler > start
request/response log handling (FULL)...
2016-09-21 10:05:02,039 ERROR [io.undertow.request] (default task-1)
UT005071: Undertow request failed HttpServerExchange{ POST
/lwi/cnr/getMsisdn request {X-MT-UserId=[pzs], SOAPAction=[""],
X-MT-CorrelationId=[123], Accept-Encoding=[gzip,deflate],
X-Lwi-RequestId=[lwiId-lpx1474445101966],
User-Agent=[Apache-HttpClient/4.1.1 (java 1.5)],
X-SSL-Client-CN=[lwitester1], X-MT-RequestId=[12345],
Content-Type=[text/xml;charset=UTF-8], Content-Length=[798],
Host=[localhost:444]} response {}}: java.lang.IllegalStateException:
UT000005: getRequestChannel() has already been called
at
io.undertow.server.HttpServerExchange.addRequestWrapper(HttpServerExchange.java:1406)
at
hu.telekom.lwi.plugin.log.LwiConduitWrapper.applyConduits(LwiConduitWrapper.java:50)
at
hu.telekom.lwi.plugin.log.LwiLogHandler.handleRequest(LwiLogHandler.java:38)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
hu.telekom.lwi.plugin.validation.ValidationHandler.handleRequest(ValidationHandler.java:78)
at
io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at
io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
at
io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at
io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:805)
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)
After the first call everything work perfectly there is no error, however it
is true that the exchange.getRequestChannel() was called in the message
validation handler.
Is it any work around for this?
Regards, Zsolt
_______________________________________________
undertow-dev mailing list
undertow-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/undertow-dev