From mario.e.carbajal at gmail.com  Wed Feb  1 13:43:56 2017
From: mario.e.carbajal at gmail.com (Mario Carbajal)
Date: Wed, 1 Feb 2017 15:43:56 -0300
Subject: [undertow-dev] WebSockets static sendBinary methods.and
	PooledByteBuffers
In-Reply-To: <CAD+L2cyry2yWjLS3miR16KzHrdxxNmu08QGEYweD8v+bKMftHQ@mail.gmail.com>
References: <CAPKf56o4p4bsrWRnPpSCXc3tho0L_MXdfW+uevHe_nTbULgdDw@mail.gmail.com>
	<CAD+L2cyry2yWjLS3miR16KzHrdxxNmu08QGEYweD8v+bKMftHQ@mail.gmail.com>
Message-ID: <CAPKf56qf0qvN3COAWMGsZeSbiOzyiEp792k3F34nZf0qCAMvLg@mail.gmail.com>

Thanks for the reply Stuart, I've made the modifications I mentioned to the
WebSockets class in my project by creating a copy of it and it's working
great.
I'm wondering if it would be possible to have the PooledByteBuffer versions
added into official undertow source.

Here's a gist of how it looks like:
https://gist.github.com/anonymous/cbb6004adb1a30d4274622814a69284c

if it makes sense I can make a fork and pull request, also add
PooledByteBuffer versions for all the send methods.

On Thu, Jan 26, 2017 at 8:36 PM, Stuart Douglas <sdouglas at redhat.com> wrote:

> On Fri, Jan 27, 2017 at 6:50 AM, Mario Carbajal
> <mario.e.carbajal at gmail.com> wrote:
> > From looking at the source it seems that the WebSockets.sendBinary
> methods
> > that take ByteBuffer will take ownership of the buffer, meaning I
> shouldn't
> > modify (or return it to a pool) after I pass it to these methods. Is this
> > correct?
>
> Yes, you need to wait for the callback to be called before you can do
> anything with it.
>
> >
> > Looking at sendInternal, the buffer passed is then wrapped in a dummy
> > ImmediatePooledByteBuffer. I could make alternative versions of these
> > sendBinary methods that take PooledByteBuffer. Allowing me to use pooled
> > buffers.
>
> Sounds good.
>
> >
> > Since this functionality is missing it makes me think that there may be a
> > reason why it shouldn't be done.
>
> Mostly because nobody has asked for it yet.
>
> Stuart
>
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170201/f3ca5113/attachment.html 

From sdouglas at redhat.com  Wed Feb  1 17:20:45 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Thu, 2 Feb 2017 09:20:45 +1100
Subject: [undertow-dev] WebSockets static sendBinary methods.and
	PooledByteBuffers
In-Reply-To: <CAPKf56qf0qvN3COAWMGsZeSbiOzyiEp792k3F34nZf0qCAMvLg@mail.gmail.com>
References: <CAPKf56o4p4bsrWRnPpSCXc3tho0L_MXdfW+uevHe_nTbULgdDw@mail.gmail.com>
	<CAD+L2cyry2yWjLS3miR16KzHrdxxNmu08QGEYweD8v+bKMftHQ@mail.gmail.com>
	<CAPKf56qf0qvN3COAWMGsZeSbiOzyiEp792k3F34nZf0qCAMvLg@mail.gmail.com>
Message-ID: <CAD+L2czLG9vxnApUZTC98=JfpzfLz__j4=+46DQq5A3qc4b_rA@mail.gmail.com>

Sounds good

Stuart

On Thu, Feb 2, 2017 at 5:43 AM, Mario Carbajal
<mario.e.carbajal at gmail.com> wrote:
> Thanks for the reply Stuart, I've made the modifications I mentioned to the
> WebSockets class in my project by creating a copy of it and it's working
> great.
> I'm wondering if it would be possible to have the PooledByteBuffer versions
> added into official undertow source.
>
> Here's a gist of how it looks like:
> https://gist.github.com/anonymous/cbb6004adb1a30d4274622814a69284c
>
> if it makes sense I can make a fork and pull request, also add
> PooledByteBuffer versions for all the send methods.
>
> On Thu, Jan 26, 2017 at 8:36 PM, Stuart Douglas <sdouglas at redhat.com> wrote:
>>
>> On Fri, Jan 27, 2017 at 6:50 AM, Mario Carbajal
>> <mario.e.carbajal at gmail.com> wrote:
>> > From looking at the source it seems that the WebSockets.sendBinary
>> > methods
>> > that take ByteBuffer will take ownership of the buffer, meaning I
>> > shouldn't
>> > modify (or return it to a pool) after I pass it to these methods. Is
>> > this
>> > correct?
>>
>> Yes, you need to wait for the callback to be called before you can do
>> anything with it.
>>
>> >
>> > Looking at sendInternal, the buffer passed is then wrapped in a dummy
>> > ImmediatePooledByteBuffer. I could make alternative versions of these
>> > sendBinary methods that take PooledByteBuffer. Allowing me to use pooled
>> > buffers.
>>
>> Sounds good.
>>
>> >
>> > Since this functionality is missing it makes me think that there may be
>> > a
>> > reason why it shouldn't be done.
>>
>> Mostly because nobody has asked for it yet.
>>
>> Stuart
>>
>> >
>> > _______________________________________________
>> > undertow-dev mailing list
>> > undertow-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>

From bill at dartalley.com  Thu Feb  2 11:57:48 2017
From: bill at dartalley.com (Bill O'Neil)
Date: Thu, 2 Feb 2017 11:57:48 -0500
Subject: [undertow-dev] Testing custom HttpHandlers
In-Reply-To: <CANd+gFzqn9uq8Jje9GYw9=JAk6rvyZA6fX45hWzXBOBq-gOdyg@mail.gmail.com>
References: <CANd+gFzTVSMzvPwXDABSwwfG4hy-EAzzGPSvn3CtBx+2XG4R6A@mail.gmail.com>
	<CAD+L2cy67YedGYRfg71mmazjbGTJUFUXN=XyZvCCTSKs53B=Lw@mail.gmail.com>
	<CANd+gFzqn9uq8Jje9GYw9=JAk6rvyZA6fX45hWzXBOBq-gOdyg@mail.gmail.com>
Message-ID: <CANd+gFzBc=gnx5xH7m_UsPTV3idtMM1YOc2fJ1mozQ+8+-3nxQ@mail.gmail.com>

Just to follow up on this would it need a separate git repo or could it
just be a new maven sub project?

I don't know much about extending JUnit runners but it sounds like the
DefaultServer class can be renamed to UndertowRunner and moved to a new sub
project. Each other project could then add it as a test dependency and
update imports accordingly.

Is that all that would be required? Maybe it could be split up a bit or
move more testing related utils as well.

Bill

On Mon, Jan 16, 2017 at 8:59 PM, Bill O'Neil <bill at dartalley.com> wrote:

> Whatever you think is best. I'm fine following Steve's approach. Undertow
> starts up and shuts down pretty quick.
>
> On Sun, Jan 15, 2017 at 5:32 PM, Stuart Douglas <sdouglas at redhat.com>
> wrote:
>
>> We do publish tests-jars, so you can actually use DefaultServer,
>> however I agree that this is not really ideal.
>>
>> I think the ideal solution would be to take the core functionality
>> from DefaultServer and create a new repo (undertow-test-runner) and
>> create some kind of UndertowRunner class that is based on
>> DefaultServer. Does this sound reasonable?
>>
>>
>> Stuart
>>
>> On Sun, Jan 15, 2017 at 7:22 AM, Bill O'Neil <bill at dartalley.com> wrote:
>> > Hello,
>> >
>> > How would you recommend testing custom HttpHanders? The DefaultServer
>> class
>> > in core part of the test code so it is not included in the jar for
>> reuse.
>> > Would it be reasonable to pull testing utils into their own project so
>> it
>> > can be reused? Or would you recommend just mocking a HttpServerExchange
>> and
>> > passing that to the HttpHandler?
>> >
>> > Thanks,
>> > Bill
>> >
>> > _______________________________________________
>> > undertow-dev mailing list
>> > undertow-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170202/3b7eb9cf/attachment.html 

From sdouglas at redhat.com  Thu Feb  2 19:10:55 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 3 Feb 2017 11:10:55 +1100
Subject: [undertow-dev] Testing custom HttpHandlers
In-Reply-To: <CANd+gFzBc=gnx5xH7m_UsPTV3idtMM1YOc2fJ1mozQ+8+-3nxQ@mail.gmail.com>
References: <CANd+gFzTVSMzvPwXDABSwwfG4hy-EAzzGPSvn3CtBx+2XG4R6A@mail.gmail.com>
	<CAD+L2cy67YedGYRfg71mmazjbGTJUFUXN=XyZvCCTSKs53B=Lw@mail.gmail.com>
	<CANd+gFzqn9uq8Jje9GYw9=JAk6rvyZA6fX45hWzXBOBq-gOdyg@mail.gmail.com>
	<CANd+gFzBc=gnx5xH7m_UsPTV3idtMM1YOc2fJ1mozQ+8+-3nxQ@mail.gmail.com>
Message-ID: <CAD+L2czuO_sVQ88+OW9ydWBLi59_bt8OsO6YaErH3iz7g8zOHQ@mail.gmail.com>

I think it would be better as a different repo, so it can have its own
release cycle. We can't really use it in the Undertow test suite
itself, due to dependency issues (the runner needs to depend on core,
and core needs to depend on the runner. We could split the tests into
a different modules but that is a pain because then you need to build
multiple modules to test changes).

Stuart

On Fri, Feb 3, 2017 at 3:57 AM, Bill O'Neil <bill at dartalley.com> wrote:
> Just to follow up on this would it need a separate git repo or could it just
> be a new maven sub project?
>
> I don't know much about extending JUnit runners but it sounds like the
> DefaultServer class can be renamed to UndertowRunner and moved to a new sub
> project. Each other project could then add it as a test dependency and
> update imports accordingly.
>
> Is that all that would be required? Maybe it could be split up a bit or move
> more testing related utils as well.
>
> Bill
>
> On Mon, Jan 16, 2017 at 8:59 PM, Bill O'Neil <bill at dartalley.com> wrote:
>>
>> Whatever you think is best. I'm fine following Steve's approach. Undertow
>> starts up and shuts down pretty quick.
>>
>> On Sun, Jan 15, 2017 at 5:32 PM, Stuart Douglas <sdouglas at redhat.com>
>> wrote:
>>>
>>> We do publish tests-jars, so you can actually use DefaultServer,
>>> however I agree that this is not really ideal.
>>>
>>> I think the ideal solution would be to take the core functionality
>>> from DefaultServer and create a new repo (undertow-test-runner) and
>>> create some kind of UndertowRunner class that is based on
>>> DefaultServer. Does this sound reasonable?
>>>
>>>
>>> Stuart
>>>
>>> On Sun, Jan 15, 2017 at 7:22 AM, Bill O'Neil <bill at dartalley.com> wrote:
>>> > Hello,
>>> >
>>> > How would you recommend testing custom HttpHanders? The DefaultServer
>>> > class
>>> > in core part of the test code so it is not included in the jar for
>>> > reuse.
>>> > Would it be reasonable to pull testing utils into their own project so
>>> > it
>>> > can be reused? Or would you recommend just mocking a HttpServerExchange
>>> > and
>>> > passing that to the HttpHandler?
>>> >
>>> > Thanks,
>>> > Bill
>>> >
>>> > _______________________________________________
>>> > undertow-dev mailing list
>>> > undertow-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>>
>

From stevehu at gmail.com  Mon Feb  6 18:08:46 2017
From: stevehu at gmail.com (Steve Hu)
Date: Mon, 6 Feb 2017 18:08:46 -0500
Subject: [undertow-dev] Undertow jboss logging redirect to logback log file
	and console
Message-ID: <CAGjN9KVFVpTdr5+6pt2MLPm55cfEH02=nJ5EGT9cxu+8VrRyLQ@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170206/4de17643/attachment-0001.html 

From miere.teixeira at gmail.com  Tue Feb  7 05:55:05 2017
From: miere.teixeira at gmail.com (Miere Teixeira)
Date: Tue, 07 Feb 2017 10:55:05 +0000
Subject: [undertow-dev] Undertow jboss logging redirect to logback log
 file and console
In-Reply-To: <CAGjN9KVFVpTdr5+6pt2MLPm55cfEH02=nJ5EGT9cxu+8VrRyLQ@mail.gmail.com>
References: <CAGjN9KVFVpTdr5+6pt2MLPm55cfEH02=nJ5EGT9cxu+8VrRyLQ@mail.gmail.com>
Message-ID: <CAHezjrQbTs0uCncjyGajXdGKBpBy7z3Gej+q_6_uOAzc=Ng5eQ@mail.gmail.com>

Hi Steve,

I've found myself on the same situation couple of years ago and to solve my
problem I've configured the LoggerProvider to point to Slf4JLoggerProvider.
Basically, this can be reproduced by declaring a
META-INF/services/org.jboss.logging.LoggerProvider file with
org.jboss.logging.Slf4jLoggerProvider as a value.

I hope it helps.

Cheers!


On Mon, Feb 6, 2017 at 9:09 PM Steve Hu <stevehu at gmail.com> wrote:

> 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
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

-- 

Miere Teixeira
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170207/ceee1c59/attachment.html 

From sven at kubiak.me  Tue Feb  7 10:17:04 2017
From: sven at kubiak.me (Sven Kubiak)
Date: Tue, 7 Feb 2017 15:17:04 +0000
Subject: [undertow-dev] FormDataProcessor ending exchange prematurely
In-Reply-To: <1485356315871.31300@kubiak.me>
References: <CACSC6EXCw+m9W09jgYKhsq1=bAz4R_1R_3mfM9o1b4df1B7VVw@mail.gmail.com>
	<CAD+L2cxa36LM+WaewyPaXrqA2t770TCuE1BAJLrxDErgkA4z6A@mail.gmail.com>,
	<CANd+gFxo4177h9X4h=x=gY8SYzRFONdfbr3wEvNHGSOPF3439g@mail.gmail.com>,
	<1485356315871.31300@kubiak.me>
Message-ID: <1486480624530.84123@kubiak.me>

?Anyone?


Cheers,

Sven


________________________________
Von: Sven Kubiak
Gesendet: Mittwoch, 25. Januar 2017 15:58
An: Bill O'Neil; Stuart Douglas
Cc: Oliver Dain; undertow-dev at lists.jboss.org
Betreff: AW: [undertow-dev] FormDataProcessor ending exchange prematurely


Hi,


sorry, for a kind of off-topic question, but as the FormDataProcessor is the topic here, I was wondering if there is already some kind of data sanitization? in the core form handling of Undertow. If not, which handler is a good starting point to hook into for this?


Best regards,

Sven


________________________________
Von: undertow-dev-bounces at lists.jboss.org <undertow-dev-bounces at lists.jboss.org> im Auftrag von Bill O'Neil <bill at dartalley.com>
Gesendet: Mittwoch, 25. Januar 2017 14:53
An: Stuart Douglas
Cc: Oliver Dain; undertow-dev at lists.jboss.org
Betreff: Re: [undertow-dev] FormDataProcessor ending exchange prematurely

Hey Stuart, your last response reminded me of of a question I had hopefully its not unrelated. I was curious how and when you should dispatch back to the IO thread. For example lets say we have a simple handler that does a SQL query that is composed with the AccessLogHandler.

AccessLogHandler -> BlockingHandler -> CustomSqlHandler In this approach I believe the final access log statement will be logged from the worker thread not the initial IO thread.

Is it possible / recommended to kick back to an IO thread once blocking is complete?

AccessLogHandler -> BlockingHandler -> CustomSqlHandler -> DispatchBackToIOThread? This way the final logging of AccessLogHandler is handled in the IO thread.

I'm not very familiar with the best ways to mix the nonblocking and blocking handlers.



On Wed, Jan 25, 2017 at 12:24 AM, Stuart Douglas <sdouglas at redhat.com<mailto:sdouglas at redhat.com>> wrote:
The handler is executed
io.undertow.server.Connectors#executeRootHandler, which means that
when the call stack returns the exchange will be ended.

Conceptually this is similar to how dispatching to a thread pool
works, when you call dispatch(HttpHandler) the exchange will be ended
when the call stack returns, even though you are no longer on the IO
thread (unless you call dispatch again).

Stuart


On Wed, Jan 25, 2017 at 3:57 PM, Oliver Dain <oliver at analyticspot.com<mailto:oliver at analyticspot.com>> wrote:
> I have some code for handling file uploads. It uses FormDataProcessor and
> tries to do everything asynchronously. I call "FormDataParser.parse" passing
> in another handler. I'll call that handler the OnFormDataAvailable. The
> OnFormDataAvailable handler checks to see if it's on the IO thread. If it
> is, it calls dispatch. Either way, once we're sure we're dispatched that
> handler calls yet another handler.
>
> What I've seen is that my OnFormDataAvailable handler (the one called by
> parse()) is not on the IO thread so it doesn't need to call dispatch. And
> yet, the exchange gets ended before the handler it calls is even close to
> complete.
>
> I've found a fix, but I don't understand why it's necessary. Specifically,
> if OnFormDataAvailable is not on the IO thread when its invoked it calls the
> 0-argument version of "HttpServerExchange.dispatch()" (which you've told me
> in another conversation shouldn't ever be necessary). If I do that,
> everything is fine.
>
> For completeness, here's the complete code:
>
> public class FormDataParsingHandler {
>   private static final Logger log =
> LoggerFactory.getLogger(FormDataParsingHandler.class);
>   private static final FormParserFactory formParserFactory =
> FormParserFactory.builder().build();
>   public static final AttachmentKey<FormData> FORM_DATA_ATTACHMENT_KEY =
> AttachmentKey.create(FormData.class);
>
>   /**
>    * The only public method - this is what gets exposed as the HttpHandler.
>    */
>   public CompletableFuture<FormData> parseForm(HttpServerExchange exchange)
> {
>     log.info<http://log.info>("audio file upload request received.");
>     FormDataParser parser = formParserFactory.createParser(exchange);
>     if (parser == null) {
>       log.warn("No parser found that can handle this content type. Headers
> were: {}", exchange.getRequestHeaders());
>       throw new UserVisibleException("No parser for the given content
> type.", ResponseCodes.BAD_REQUEST);
>     }
>
>     CompletableFuture<FormData> toComplete = new CompletableFuture<>();
>     try {
>       parser.parse(new OnFormDataAvailable(toComplete));
>     } catch (Exception e) {
>       log.error("Error parsing form data:", e);
>       throw wrapAsUnchecked(e);
>     }
>
>     exchange.addExchangeCompleteListener((ex, nextListener) -> {
>       // Must close the parser so it can free any temporary files that were
> created.
>       try {
>         parser.close();
>       } catch (IOException e) {
>         log.error("Error closing the FormDataParser. Request was handled
> successfully but temporary files may not "
>             + "have been cleaned up.", e);
>       }
>       nextListener.proceed();
>     });
>
>     return toComplete;
>   }
>
>   // The FormDataParser calls an HttpHandler when it's complete so we add a
> silly handler here that does nothing but
>   // complete this method's future when the form data is available.
>   private static class OnFormDataAvailable implements HttpHandler {
>     private final CompletableFuture<FormData> toComplete;
>
>     private OnFormDataAvailable(CompletableFuture<FormData> toComplete) {
>       this.toComplete = toComplete;
>     }
>
>     @Override
>     public void handleRequest(HttpServerExchange exchange) throws Exception
> {
>       // Before we complete the future we have to re-dispatch or we'll fall
> off the end of this method and Undertow
>       // will complete the exchange on our behalf.
>       FormData data = exchange.getAttachment(FormDataParser.FORM_DATA);
>       if (exchange.isInIoThread()) {
>         log.debug("Was on the IO thread. Re-dispatching.");
>         exchange.dispatch(SameThreadExecutor.INSTANCE, () ->
> afterDistpach(data));
>       } else {
>         // THIS THE MYSTERY LINE. WHY IS THIS NEEDED?
>         exchange.dispatch();
>         afterDistpach(data);
>       }
>     }
>
>     private void afterDistpach(FormData data) {
>       if (data == null) {
>         toComplete.completeExceptionally(
>             new UserVisibleException("Parsing of data failed.",
> ResponseCodes.BAD_REQUEST));
>       } else {
>         toComplete.complete(data);
>       }
>     }
>   }
> }
>
> --
> CTO, Analytic Spot
> 44 West Broadway #222
> Eugene, OR 97401
> analyticspot.com<http://analyticspot.com> ? 425-296-6556<tel:425-296-6556>
> www.linkedin.com/in/oliverdain<http://www.linkedin.com/in/oliverdain>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org<mailto:undertow-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/undertow-dev

_______________________________________________
undertow-dev mailing list
undertow-dev at lists.jboss.org<mailto:undertow-dev at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/undertow-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170207/8487b5a2/attachment-0001.html 

From sven at kubiak.me  Tue Feb  7 10:17:38 2017
From: sven at kubiak.me (Sven Kubiak)
Date: Tue, 7 Feb 2017 15:17:38 +0000
Subject: [undertow-dev] FormDataProcessor ending exchange prematurely
In-Reply-To: <1485356315871.31300@kubiak.me>
References: <CACSC6EXCw+m9W09jgYKhsq1=bAz4R_1R_3mfM9o1b4df1B7VVw@mail.gmail.com>
	<CAD+L2cxa36LM+WaewyPaXrqA2t770TCuE1BAJLrxDErgkA4z6A@mail.gmail.com>,
	<CANd+gFxo4177h9X4h=x=gY8SYzRFONdfbr3wEvNHGSOPF3439g@mail.gmail.com>,
	<1485356315871.31300@kubiak.me>
Message-ID: <1486480658082.41360@kubiak.me>

??Anyone?


Cheers,

Sven


________________________________
Von: Sven Kubiak
Gesendet: Mittwoch, 25. Januar 2017 15:58
An: Bill O'Neil; Stuart Douglas
Cc: Oliver Dain; undertow-dev at lists.jboss.org
Betreff: AW: [undertow-dev] FormDataProcessor ending exchange prematurely


Hi,


sorry, for a kind of off-topic question, but as the FormDataProcessor is the topic here, I was wondering if there is already some kind of data sanitization? in the core form handling of Undertow. If not, which handler is a good starting point to hook into for this?


Best regards,

Sven


________________________________
Von: undertow-dev-bounces at lists.jboss.org <undertow-dev-bounces at lists.jboss.org> im Auftrag von Bill O'Neil <bill at dartalley.com>
Gesendet: Mittwoch, 25. Januar 2017 14:53
An: Stuart Douglas
Cc: Oliver Dain; undertow-dev at lists.jboss.org
Betreff: Re: [undertow-dev] FormDataProcessor ending exchange prematurely

Hey Stuart, your last response reminded me of of a question I had hopefully its not unrelated. I was curious how and when you should dispatch back to the IO thread. For example lets say we have a simple handler that does a SQL query that is composed with the AccessLogHandler.

AccessLogHandler -> BlockingHandler -> CustomSqlHandler In this approach I believe the final access log statement will be logged from the worker thread not the initial IO thread.

Is it possible / recommended to kick back to an IO thread once blocking is complete?

AccessLogHandler -> BlockingHandler -> CustomSqlHandler -> DispatchBackToIOThread? This way the final logging of AccessLogHandler is handled in the IO thread.

I'm not very familiar with the best ways to mix the nonblocking and blocking handlers.



On Wed, Jan 25, 2017 at 12:24 AM, Stuart Douglas <sdouglas at redhat.com<mailto:sdouglas at redhat.com>> wrote:
The handler is executed
io.undertow.server.Connectors#executeRootHandler, which means that
when the call stack returns the exchange will be ended.

Conceptually this is similar to how dispatching to a thread pool
works, when you call dispatch(HttpHandler) the exchange will be ended
when the call stack returns, even though you are no longer on the IO
thread (unless you call dispatch again).

Stuart


On Wed, Jan 25, 2017 at 3:57 PM, Oliver Dain <oliver at analyticspot.com<mailto:oliver at analyticspot.com>> wrote:
> I have some code for handling file uploads. It uses FormDataProcessor and
> tries to do everything asynchronously. I call "FormDataParser.parse" passing
> in another handler. I'll call that handler the OnFormDataAvailable. The
> OnFormDataAvailable handler checks to see if it's on the IO thread. If it
> is, it calls dispatch. Either way, once we're sure we're dispatched that
> handler calls yet another handler.
>
> What I've seen is that my OnFormDataAvailable handler (the one called by
> parse()) is not on the IO thread so it doesn't need to call dispatch. And
> yet, the exchange gets ended before the handler it calls is even close to
> complete.
>
> I've found a fix, but I don't understand why it's necessary. Specifically,
> if OnFormDataAvailable is not on the IO thread when its invoked it calls the
> 0-argument version of "HttpServerExchange.dispatch()" (which you've told me
> in another conversation shouldn't ever be necessary). If I do that,
> everything is fine.
>
> For completeness, here's the complete code:
>
> public class FormDataParsingHandler {
>   private static final Logger log =
> LoggerFactory.getLogger(FormDataParsingHandler.class);
>   private static final FormParserFactory formParserFactory =
> FormParserFactory.builder().build();
>   public static final AttachmentKey<FormData> FORM_DATA_ATTACHMENT_KEY =
> AttachmentKey.create(FormData.class);
>
>   /**
>    * The only public method - this is what gets exposed as the HttpHandler.
>    */
>   public CompletableFuture<FormData> parseForm(HttpServerExchange exchange)
> {
>     log.info<http://log.info>("audio file upload request received.");
>     FormDataParser parser = formParserFactory.createParser(exchange);
>     if (parser == null) {
>       log.warn("No parser found that can handle this content type. Headers
> were: {}", exchange.getRequestHeaders());
>       throw new UserVisibleException("No parser for the given content
> type.", ResponseCodes.BAD_REQUEST);
>     }
>
>     CompletableFuture<FormData> toComplete = new CompletableFuture<>();
>     try {
>       parser.parse(new OnFormDataAvailable(toComplete));
>     } catch (Exception e) {
>       log.error("Error parsing form data:", e);
>       throw wrapAsUnchecked(e);
>     }
>
>     exchange.addExchangeCompleteListener((ex, nextListener) -> {
>       // Must close the parser so it can free any temporary files that were
> created.
>       try {
>         parser.close();
>       } catch (IOException e) {
>         log.error("Error closing the FormDataParser. Request was handled
> successfully but temporary files may not "
>             + "have been cleaned up.", e);
>       }
>       nextListener.proceed();
>     });
>
>     return toComplete;
>   }
>
>   // The FormDataParser calls an HttpHandler when it's complete so we add a
> silly handler here that does nothing but
>   // complete this method's future when the form data is available.
>   private static class OnFormDataAvailable implements HttpHandler {
>     private final CompletableFuture<FormData> toComplete;
>
>     private OnFormDataAvailable(CompletableFuture<FormData> toComplete) {
>       this.toComplete = toComplete;
>     }
>
>     @Override
>     public void handleRequest(HttpServerExchange exchange) throws Exception
> {
>       // Before we complete the future we have to re-dispatch or we'll fall
> off the end of this method and Undertow
>       // will complete the exchange on our behalf.
>       FormData data = exchange.getAttachment(FormDataParser.FORM_DATA);
>       if (exchange.isInIoThread()) {
>         log.debug("Was on the IO thread. Re-dispatching.");
>         exchange.dispatch(SameThreadExecutor.INSTANCE, () ->
> afterDistpach(data));
>       } else {
>         // THIS THE MYSTERY LINE. WHY IS THIS NEEDED?
>         exchange.dispatch();
>         afterDistpach(data);
>       }
>     }
>
>     private void afterDistpach(FormData data) {
>       if (data == null) {
>         toComplete.completeExceptionally(
>             new UserVisibleException("Parsing of data failed.",
> ResponseCodes.BAD_REQUEST));
>       } else {
>         toComplete.complete(data);
>       }
>     }
>   }
> }
>
> --
> CTO, Analytic Spot
> 44 West Broadway #222
> Eugene, OR 97401
> analyticspot.com<http://analyticspot.com> ? 425-296-6556<tel:425-296-6556>
> www.linkedin.com/in/oliverdain<http://www.linkedin.com/in/oliverdain>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org<mailto:undertow-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/undertow-dev

_______________________________________________
undertow-dev mailing list
undertow-dev at lists.jboss.org<mailto:undertow-dev at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/undertow-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170207/8f6fa563/attachment.html 

From sven at kubiak.me  Tue Feb  7 10:17:57 2017
From: sven at kubiak.me (Sven Kubiak)
Date: Tue, 7 Feb 2017 15:17:57 +0000
Subject: [undertow-dev] FormDataProcessor ending exchange prematurely
In-Reply-To: <1485356315871.31300@kubiak.me>
References: <CACSC6EXCw+m9W09jgYKhsq1=bAz4R_1R_3mfM9o1b4df1B7VVw@mail.gmail.com>
	<CAD+L2cxa36LM+WaewyPaXrqA2t770TCuE1BAJLrxDErgkA4z6A@mail.gmail.com>,
	<CANd+gFxo4177h9X4h=x=gY8SYzRFONdfbr3wEvNHGSOPF3439g@mail.gmail.com>,
	<1485356315871.31300@kubiak.me>
Message-ID: <1486480677369.68972@kubiak.me>

???Anyone?


Cheers,

Sven


________________________________
Von: Sven Kubiak
Gesendet: Mittwoch, 25. Januar 2017 15:58
An: Bill O'Neil; Stuart Douglas
Cc: Oliver Dain; undertow-dev at lists.jboss.org
Betreff: AW: [undertow-dev] FormDataProcessor ending exchange prematurely


Hi,


sorry, for a kind of off-topic question, but as the FormDataProcessor is the topic here, I was wondering if there is already some kind of data sanitization? in the core form handling of Undertow. If not, which handler is a good starting point to hook into for this?


Best regards,

Sven


________________________________
Von: undertow-dev-bounces at lists.jboss.org <undertow-dev-bounces at lists.jboss.org> im Auftrag von Bill O'Neil <bill at dartalley.com>
Gesendet: Mittwoch, 25. Januar 2017 14:53
An: Stuart Douglas
Cc: Oliver Dain; undertow-dev at lists.jboss.org
Betreff: Re: [undertow-dev] FormDataProcessor ending exchange prematurely

Hey Stuart, your last response reminded me of of a question I had hopefully its not unrelated. I was curious how and when you should dispatch back to the IO thread. For example lets say we have a simple handler that does a SQL query that is composed with the AccessLogHandler.

AccessLogHandler -> BlockingHandler -> CustomSqlHandler In this approach I believe the final access log statement will be logged from the worker thread not the initial IO thread.

Is it possible / recommended to kick back to an IO thread once blocking is complete?

AccessLogHandler -> BlockingHandler -> CustomSqlHandler -> DispatchBackToIOThread? This way the final logging of AccessLogHandler is handled in the IO thread.

I'm not very familiar with the best ways to mix the nonblocking and blocking handlers.



On Wed, Jan 25, 2017 at 12:24 AM, Stuart Douglas <sdouglas at redhat.com<mailto:sdouglas at redhat.com>> wrote:
The handler is executed
io.undertow.server.Connectors#executeRootHandler, which means that
when the call stack returns the exchange will be ended.

Conceptually this is similar to how dispatching to a thread pool
works, when you call dispatch(HttpHandler) the exchange will be ended
when the call stack returns, even though you are no longer on the IO
thread (unless you call dispatch again).

Stuart


On Wed, Jan 25, 2017 at 3:57 PM, Oliver Dain <oliver at analyticspot.com<mailto:oliver at analyticspot.com>> wrote:
> I have some code for handling file uploads. It uses FormDataProcessor and
> tries to do everything asynchronously. I call "FormDataParser.parse" passing
> in another handler. I'll call that handler the OnFormDataAvailable. The
> OnFormDataAvailable handler checks to see if it's on the IO thread. If it
> is, it calls dispatch. Either way, once we're sure we're dispatched that
> handler calls yet another handler.
>
> What I've seen is that my OnFormDataAvailable handler (the one called by
> parse()) is not on the IO thread so it doesn't need to call dispatch. And
> yet, the exchange gets ended before the handler it calls is even close to
> complete.
>
> I've found a fix, but I don't understand why it's necessary. Specifically,
> if OnFormDataAvailable is not on the IO thread when its invoked it calls the
> 0-argument version of "HttpServerExchange.dispatch()" (which you've told me
> in another conversation shouldn't ever be necessary). If I do that,
> everything is fine.
>
> For completeness, here's the complete code:
>
> public class FormDataParsingHandler {
>   private static final Logger log =
> LoggerFactory.getLogger(FormDataParsingHandler.class);
>   private static final FormParserFactory formParserFactory =
> FormParserFactory.builder().build();
>   public static final AttachmentKey<FormData> FORM_DATA_ATTACHMENT_KEY =
> AttachmentKey.create(FormData.class);
>
>   /**
>    * The only public method - this is what gets exposed as the HttpHandler.
>    */
>   public CompletableFuture<FormData> parseForm(HttpServerExchange exchange)
> {
>     log.info<http://log.info>("audio file upload request received.");
>     FormDataParser parser = formParserFactory.createParser(exchange);
>     if (parser == null) {
>       log.warn("No parser found that can handle this content type. Headers
> were: {}", exchange.getRequestHeaders());
>       throw new UserVisibleException("No parser for the given content
> type.", ResponseCodes.BAD_REQUEST);
>     }
>
>     CompletableFuture<FormData> toComplete = new CompletableFuture<>();
>     try {
>       parser.parse(new OnFormDataAvailable(toComplete));
>     } catch (Exception e) {
>       log.error("Error parsing form data:", e);
>       throw wrapAsUnchecked(e);
>     }
>
>     exchange.addExchangeCompleteListener((ex, nextListener) -> {
>       // Must close the parser so it can free any temporary files that were
> created.
>       try {
>         parser.close();
>       } catch (IOException e) {
>         log.error("Error closing the FormDataParser. Request was handled
> successfully but temporary files may not "
>             + "have been cleaned up.", e);
>       }
>       nextListener.proceed();
>     });
>
>     return toComplete;
>   }
>
>   // The FormDataParser calls an HttpHandler when it's complete so we add a
> silly handler here that does nothing but
>   // complete this method's future when the form data is available.
>   private static class OnFormDataAvailable implements HttpHandler {
>     private final CompletableFuture<FormData> toComplete;
>
>     private OnFormDataAvailable(CompletableFuture<FormData> toComplete) {
>       this.toComplete = toComplete;
>     }
>
>     @Override
>     public void handleRequest(HttpServerExchange exchange) throws Exception
> {
>       // Before we complete the future we have to re-dispatch or we'll fall
> off the end of this method and Undertow
>       // will complete the exchange on our behalf.
>       FormData data = exchange.getAttachment(FormDataParser.FORM_DATA);
>       if (exchange.isInIoThread()) {
>         log.debug("Was on the IO thread. Re-dispatching.");
>         exchange.dispatch(SameThreadExecutor.INSTANCE, () ->
> afterDistpach(data));
>       } else {
>         // THIS THE MYSTERY LINE. WHY IS THIS NEEDED?
>         exchange.dispatch();
>         afterDistpach(data);
>       }
>     }
>
>     private void afterDistpach(FormData data) {
>       if (data == null) {
>         toComplete.completeExceptionally(
>             new UserVisibleException("Parsing of data failed.",
> ResponseCodes.BAD_REQUEST));
>       } else {
>         toComplete.complete(data);
>       }
>     }
>   }
> }
>
> --
> CTO, Analytic Spot
> 44 West Broadway #222
> Eugene, OR 97401
> analyticspot.com<http://analyticspot.com> ? 425-296-6556<tel:425-296-6556>
> www.linkedin.com/in/oliverdain<http://www.linkedin.com/in/oliverdain>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org<mailto:undertow-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/undertow-dev

_______________________________________________
undertow-dev mailing list
undertow-dev at lists.jboss.org<mailto:undertow-dev at lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/undertow-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170207/b8533517/attachment-0001.html 

From bill at dartalley.com  Tue Feb  7 11:11:31 2017
From: bill at dartalley.com (Bill O'Neil)
Date: Tue, 7 Feb 2017 11:11:31 -0500
Subject: [undertow-dev] FormDataProcessor ending exchange prematurely
In-Reply-To: <1486480677369.68972@kubiak.me>
References: <CACSC6EXCw+m9W09jgYKhsq1=bAz4R_1R_3mfM9o1b4df1B7VVw@mail.gmail.com>
	<CAD+L2cxa36LM+WaewyPaXrqA2t770TCuE1BAJLrxDErgkA4z6A@mail.gmail.com>
	<CANd+gFxo4177h9X4h=x=gY8SYzRFONdfbr3wEvNHGSOPF3439g@mail.gmail.com>
	<1485356315871.31300@kubiak.me> <1486480677369.68972@kubiak.me>
Message-ID: <CANd+gFxvrwJ8LTisoNBPXYD=fPKEpNZnFPUHDG0jL3jXTUaKbA@mail.gmail.com>

Hey Sven,

What kind of sanitization are you looking for? It should be handling form
encoding for you but I don't think any other type of sanitization.

On Tue, Feb 7, 2017 at 10:17 AM, Sven Kubiak <sven at kubiak.me> wrote:

> ???Anyone?
>
>
> Cheers,
>
> Sven
>
>
> ------------------------------
> *Von:* Sven Kubiak
> *Gesendet:* Mittwoch, 25. Januar 2017 15:58
> *An:* Bill O'Neil; Stuart Douglas
> *Cc:* Oliver Dain; undertow-dev at lists.jboss.org
> *Betreff:* AW: [undertow-dev] FormDataProcessor ending exchange
> prematurely
>
>
> Hi,
>
>
> sorry, for a kind of off-topic question, but as the FormDataProcessor is
> the topic here, I was wondering if there is already some kind of data
> sanitization? in the core form handling of Undertow. If not, which handler
> is a good starting point to hook into for this?
>
>
> Best regards,
>
> Sven
>
>
> ------------------------------
> *Von:* undertow-dev-bounces at lists.jboss.org <undertow-dev-bounces at lists.
> jboss.org> im Auftrag von Bill O'Neil <bill at dartalley.com>
> *Gesendet:* Mittwoch, 25. Januar 2017 14:53
> *An:* Stuart Douglas
> *Cc:* Oliver Dain; undertow-dev at lists.jboss.org
> *Betreff:* Re: [undertow-dev] FormDataProcessor ending exchange
> prematurely
>
> Hey Stuart, your last response reminded me of of a question I had
> hopefully its not unrelated. I was curious how and when you should dispatch
> back to the IO thread. For example lets say we have a simple handler that
> does a SQL query that is composed with the AccessLogHandler.
>
> AccessLogHandler -> BlockingHandler -> CustomSqlHandler In this approach I
> believe the final access log statement will be logged from the worker
> thread not the initial IO thread.
>
> Is it possible / recommended to kick back to an IO thread once blocking is
> complete?
>
> AccessLogHandler -> BlockingHandler -> CustomSqlHandler ->
> DispatchBackToIOThread? This way the final logging of AccessLogHandler is
> handled in the IO thread.
>
> I'm not very familiar with the best ways to mix the nonblocking and
> blocking handlers.
>
>
>
> On Wed, Jan 25, 2017 at 12:24 AM, Stuart Douglas <sdouglas at redhat.com>
> wrote:
>
>> The handler is executed
>> io.undertow.server.Connectors#executeRootHandler, which means that
>> when the call stack returns the exchange will be ended.
>>
>> Conceptually this is similar to how dispatching to a thread pool
>> works, when you call dispatch(HttpHandler) the exchange will be ended
>> when the call stack returns, even though you are no longer on the IO
>> thread (unless you call dispatch again).
>>
>> Stuart
>>
>>
>> On Wed, Jan 25, 2017 at 3:57 PM, Oliver Dain <oliver at analyticspot.com>
>> wrote:
>> > I have some code for handling file uploads. It uses FormDataProcessor
>> and
>> > tries to do everything asynchronously. I call "FormDataParser.parse"
>> passing
>> > in another handler. I'll call that handler the OnFormDataAvailable. The
>> > OnFormDataAvailable handler checks to see if it's on the IO thread. If
>> it
>> > is, it calls dispatch. Either way, once we're sure we're dispatched that
>> > handler calls yet another handler.
>> >
>> > What I've seen is that my OnFormDataAvailable handler (the one called by
>> > parse()) is not on the IO thread so it doesn't need to call dispatch.
>> And
>> > yet, the exchange gets ended before the handler it calls is even close
>> to
>> > complete.
>> >
>> > I've found a fix, but I don't understand why it's necessary.
>> Specifically,
>> > if OnFormDataAvailable is not on the IO thread when its invoked it
>> calls the
>> > 0-argument version of "HttpServerExchange.dispatch()" (which you've
>> told me
>> > in another conversation shouldn't ever be necessary). If I do that,
>> > everything is fine.
>> >
>> > For completeness, here's the complete code:
>> >
>> > public class FormDataParsingHandler {
>> >   private static final Logger log =
>> > LoggerFactory.getLogger(FormDataParsingHandler.class);
>> >   private static final FormParserFactory formParserFactory =
>> > FormParserFactory.builder().build();
>> >   public static final AttachmentKey<FormData> FORM_DATA_ATTACHMENT_KEY =
>> > AttachmentKey.create(FormData.class);
>> >
>> >   /**
>> >    * The only public method - this is what gets exposed as the
>> HttpHandler.
>> >    */
>> >   public CompletableFuture<FormData> parseForm(HttpServerExchange
>> exchange)
>> > {
>> >     log.info("audio file upload request received.");
>> >     FormDataParser parser = formParserFactory.createParser(exchange);
>> >     if (parser == null) {
>> >       log.warn("No parser found that can handle this content type.
>> Headers
>> > were: {}", exchange.getRequestHeaders());
>> >       throw new UserVisibleException("No parser for the given content
>> > type.", ResponseCodes.BAD_REQUEST);
>> >     }
>> >
>> >     CompletableFuture<FormData> toComplete = new CompletableFuture<>();
>> >     try {
>> >       parser.parse(new OnFormDataAvailable(toComplete));
>> >     } catch (Exception e) {
>> >       log.error("Error parsing form data:", e);
>> >       throw wrapAsUnchecked(e);
>> >     }
>> >
>> >     exchange.addExchangeCompleteListener((ex, nextListener) -> {
>> >       // Must close the parser so it can free any temporary files that
>> were
>> > created.
>> >       try {
>> >         parser.close();
>> >       } catch (IOException e) {
>> >         log.error("Error closing the FormDataParser. Request was handled
>> > successfully but temporary files may not "
>> >             + "have been cleaned up.", e);
>> >       }
>> >       nextListener.proceed();
>> >     });
>> >
>> >     return toComplete;
>> >   }
>> >
>> >   // The FormDataParser calls an HttpHandler when it's complete so we
>> add a
>> > silly handler here that does nothing but
>> >   // complete this method's future when the form data is available.
>> >   private static class OnFormDataAvailable implements HttpHandler {
>> >     private final CompletableFuture<FormData> toComplete;
>> >
>> >     private OnFormDataAvailable(CompletableFuture<FormData>
>> toComplete) {
>> >       this.toComplete = toComplete;
>> >     }
>> >
>> >     @Override
>> >     public void handleRequest(HttpServerExchange exchange) throws
>> Exception
>> > {
>> >       // Before we complete the future we have to re-dispatch or we'll
>> fall
>> > off the end of this method and Undertow
>> >       // will complete the exchange on our behalf.
>> >       FormData data = exchange.getAttachment(FormDataParser.FORM_DATA);
>> >       if (exchange.isInIoThread()) {
>> >         log.debug("Was on the IO thread. Re-dispatching.");
>> >         exchange.dispatch(SameThreadExecutor.INSTANCE, () ->
>> > afterDistpach(data));
>> >       } else {
>> >         // THIS THE MYSTERY LINE. WHY IS THIS NEEDED?
>> >         exchange.dispatch();
>> >         afterDistpach(data);
>> >       }
>> >     }
>> >
>> >     private void afterDistpach(FormData data) {
>> >       if (data == null) {
>> >         toComplete.completeExceptionally(
>> >             new UserVisibleException("Parsing of data failed.",
>> > ResponseCodes.BAD_REQUEST));
>> >       } else {
>> >         toComplete.complete(data);
>> >       }
>> >     }
>> >   }
>> > }
>> >
>> > --
>> > CTO, Analytic Spot
>> > 44 West Broadway #222
>> > Eugene, OR 97401
>> > analyticspot.com ? 425-296-6556
>> > www.linkedin.com/in/oliverdain
>> >
>> > _______________________________________________
>> > undertow-dev mailing list
>> > undertow-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170207/40d2e481/attachment.html 

From kr at asseco.dk  Tue Feb  7 13:48:05 2017
From: kr at asseco.dk (Kim Rasmussen)
Date: Tue, 7 Feb 2017 19:48:05 +0100
Subject: [undertow-dev] Undertow jboss logging redirect to logback log
 file and console
In-Reply-To: <CAHezjrQbTs0uCncjyGajXdGKBpBy7z3Gej+q_6_uOAzc=Ng5eQ@mail.gmail.com>
References: <CAGjN9KVFVpTdr5+6pt2MLPm55cfEH02=nJ5EGT9cxu+8VrRyLQ@mail.gmail.com>
	<CAHezjrQbTs0uCncjyGajXdGKBpBy7z3Gej+q_6_uOAzc=Ng5eQ@mail.gmail.com>
Message-ID: <CAGX6Y=1ydCyhi=KwiVtVi9LQvCbtep1TQm3BBUVSm3KrvgTGoA@mail.gmail.com>

Hi,

I have had success with adding the system property:

-Dorg.jboss.logging.provider=slf4j

A random search for this on the net revelated this page which does a good
job of explaining various ways of getting it working with WildFly - I
myself use Undertow embedded, so the system property is enough for me.

/Kim

2017-02-07 11:55 GMT+01:00 Miere Teixeira <miere.teixeira at gmail.com>:

> Hi Steve,
>
> I've found myself on the same situation couple of years ago and to solve
> my problem I've configured the LoggerProvider to point to
> Slf4JLoggerProvider. Basically, this can be reproduced by declaring a
> META-INF/services/org.jboss.logging.LoggerProvider file with
> org.jboss.logging.Slf4jLoggerProvider as a value.
>
> I hope it helps.
>
> Cheers!
>
>
> On Mon, Feb 6, 2017 at 9:09 PM Steve Hu <stevehu at gmail.com> wrote:
>
>> 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
>>
>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
> --
>
> Miere Teixeira
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>



-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170207/f0834b77/attachment-0001.html 

From bill at dartalley.com  Tue Feb  7 14:22:21 2017
From: bill at dartalley.com (Bill O'Neil)
Date: Tue, 7 Feb 2017 14:22:21 -0500
Subject: [undertow-dev] Undertow jboss logging redirect to logback log
 file and console
In-Reply-To: <CAGX6Y=1ydCyhi=KwiVtVi9LQvCbtep1TQm3BBUVSm3KrvgTGoA@mail.gmail.com>
References: <CAGjN9KVFVpTdr5+6pt2MLPm55cfEH02=nJ5EGT9cxu+8VrRyLQ@mail.gmail.com>
	<CAHezjrQbTs0uCncjyGajXdGKBpBy7z3Gej+q_6_uOAzc=Ng5eQ@mail.gmail.com>
	<CAGX6Y=1ydCyhi=KwiVtVi9LQvCbtep1TQm3BBUVSm3KrvgTGoA@mail.gmail.com>
Message-ID: <CANd+gFzhWr0ejYMytzRQ6C49t+AgKOEbCmFyovJHQrEJt=hBtg@mail.gmail.com>

@Steve - If your exception handler is in the handler chain before calling
dispatch then an exception is thrown it might not be handled properly (I
think I ran into this). If you make sure you add an exception handler after
calling dispatch that handles Throwable.class but before your logic, you
should be able to catch all Exceptions. I'm not 100% positive here but this
seemed to work for me.


On Tue, Feb 7, 2017 at 1:48 PM, Kim Rasmussen <kr at asseco.dk> wrote:

> Hi,
>
> I have had success with adding the system property:
>
> -Dorg.jboss.logging.provider=slf4j
>
> A random search for this on the net revelated this page which does a good
> job of explaining various ways of getting it working with WildFly - I
> myself use Undertow embedded, so the system property is enough for me.
>
> /Kim
>
> 2017-02-07 11:55 GMT+01:00 Miere Teixeira <miere.teixeira at gmail.com>:
>
>> Hi Steve,
>>
>> I've found myself on the same situation couple of years ago and to solve
>> my problem I've configured the LoggerProvider to point to
>> Slf4JLoggerProvider. Basically, this can be reproduced by declaring a
>> META-INF/services/org.jboss.logging.LoggerProvider file with
>> org.jboss.logging.Slf4jLoggerProvider as a value.
>>
>> I hope it helps.
>>
>> Cheers!
>>
>>
>> On Mon, Feb 6, 2017 at 9:09 PM Steve Hu <stevehu at gmail.com> wrote:
>>
>>> 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
>>>
>>>
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>> --
>>
>> Miere Teixeira
>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>
>
>
> --
> 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 <+45%2026%2016%2040%2023>
> Ph.: +45 33 36 46 60 <+45%2033%2036%2046%2060>
> Fax: +45 33 36 46 61 <+45%2033%2036%2046%2061>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170207/ffe85136/attachment.html 

From stevehu at gmail.com  Tue Feb  7 15:26:11 2017
From: stevehu at gmail.com (Steve Hu)
Date: Tue, 7 Feb 2017 15:26:11 -0500
Subject: [undertow-dev] Undertow jboss logging redirect to logback log
 file and console
In-Reply-To: <CANd+gFzhWr0ejYMytzRQ6C49t+AgKOEbCmFyovJHQrEJt=hBtg@mail.gmail.com>
References: <CAGjN9KVFVpTdr5+6pt2MLPm55cfEH02=nJ5EGT9cxu+8VrRyLQ@mail.gmail.com>
	<CAHezjrQbTs0uCncjyGajXdGKBpBy7z3Gej+q_6_uOAzc=Ng5eQ@mail.gmail.com>
	<CAGX6Y=1ydCyhi=KwiVtVi9LQvCbtep1TQm3BBUVSm3KrvgTGoA@mail.gmail.com>
	<CANd+gFzhWr0ejYMytzRQ6C49t+AgKOEbCmFyovJHQrEJt=hBtg@mail.gmail.com>
Message-ID: <CAGjN9KWVOJV2L28YS_7AMFvbsE6jTeNfXEYojs+OobLy8wddNQ@mail.gmail.com>

Hi Bill,

My exception handler is the first in the chain and it captures majority of
exceptions but this one. It is basically a try/catch block to wrap all
handler calls and you can find the source code at
https://github.com/networknt/light-java/blob/master/exception/src/main/java/com/networknt/exception/ExceptionHandler.java

I will try to dispatch in this handler first tonight and see if it works
based on your recommendation.

Hi Miere/Kim,

I am in the office now and will try both your approaches tonight on my home
computer.

Thanks a lot for your help.

Steve

On Tue, Feb 7, 2017 at 2:22 PM, Bill O'Neil <bill at dartalley.com> wrote:

> @Steve - If your exception handler is in the handler chain before calling
> dispatch then an exception is thrown it might not be handled properly (I
> think I ran into this). If you make sure you add an exception handler after
> calling dispatch that handles Throwable.class but before your logic, you
> should be able to catch all Exceptions. I'm not 100% positive here but this
> seemed to work for me.
>
>
> On Tue, Feb 7, 2017 at 1:48 PM, Kim Rasmussen <kr at asseco.dk> wrote:
>
>> Hi,
>>
>> I have had success with adding the system property:
>>
>> -Dorg.jboss.logging.provider=slf4j
>>
>> A random search for this on the net revelated this page which does a good
>> job of explaining various ways of getting it working with WildFly - I
>> myself use Undertow embedded, so the system property is enough for me.
>>
>> /Kim
>>
>> 2017-02-07 11:55 GMT+01:00 Miere Teixeira <miere.teixeira at gmail.com>:
>>
>>> Hi Steve,
>>>
>>> I've found myself on the same situation couple of years ago and to solve
>>> my problem I've configured the LoggerProvider to point to
>>> Slf4JLoggerProvider. Basically, this can be reproduced by declaring a
>>> META-INF/services/org.jboss.logging.LoggerProvider file with
>>> org.jboss.logging.Slf4jLoggerProvider as a value.
>>>
>>> I hope it helps.
>>>
>>> Cheers!
>>>
>>>
>>> On Mon, Feb 6, 2017 at 9:09 PM Steve Hu <stevehu at gmail.com> wrote:
>>>
>>>> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> undertow-dev mailing list
>>>> undertow-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>>> --
>>>
>>> Miere Teixeira
>>>
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>>
>>
>>
>> --
>> 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 <+45%2026%2016%2040%2023>
>> Ph.: +45 33 36 46 60 <+45%2033%2036%2046%2060>
>> Fax: +45 33 36 46 61 <+45%2033%2036%2046%2061>
>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170207/955f4b46/attachment-0001.html 

From sdouglas at redhat.com  Tue Feb  7 17:26:20 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Wed, 8 Feb 2017 09:26:20 +1100
Subject: [undertow-dev] Undertow jboss logging redirect to logback log
 file and console
In-Reply-To: <CAGjN9KWVOJV2L28YS_7AMFvbsE6jTeNfXEYojs+OobLy8wddNQ@mail.gmail.com>
References: <CAGjN9KVFVpTdr5+6pt2MLPm55cfEH02=nJ5EGT9cxu+8VrRyLQ@mail.gmail.com>
	<CAHezjrQbTs0uCncjyGajXdGKBpBy7z3Gej+q_6_uOAzc=Ng5eQ@mail.gmail.com>
	<CAGX6Y=1ydCyhi=KwiVtVi9LQvCbtep1TQm3BBUVSm3KrvgTGoA@mail.gmail.com>
	<CANd+gFzhWr0ejYMytzRQ6C49t+AgKOEbCmFyovJHQrEJt=hBtg@mail.gmail.com>
	<CAGjN9KWVOJV2L28YS_7AMFvbsE6jTeNfXEYojs+OobLy8wddNQ@mail.gmail.com>
Message-ID: <CAD+L2cxU98_5WMNa-cbZygxzRsDCCKRgyev_dAkDW8Gaacvm-Q@mail.gmail.com>

I think this is something I should address in Undertow Core (Servlet
already has io.undertow.servlet.api.ExceptionHandler), to allow you to
register a handler that will be called if an exception propagates
outside of the handler chain.

I think there are two options:

1) HttpServerExchange.setExceptionHandler(HttpHandler handler), and
then make the exception available as an attachment on the Exchange.
2) HttpServerExchange.setExceptionHandler(ExceptionHandler handler),
where ExceptionHandler has a single method that takes the exchange and
the exception.

Thoughts?

Stuart

On Wed, Feb 8, 2017 at 7:26 AM, Steve Hu <stevehu at gmail.com> wrote:
> Hi Bill,
>
> My exception handler is the first in the chain and it captures majority of
> exceptions but this one. It is basically a try/catch block to wrap all
> handler calls and you can find the source code at
> https://github.com/networknt/light-java/blob/master/exception/src/main/java/com/networknt/exception/ExceptionHandler.java
>
> I will try to dispatch in this handler first tonight and see if it works
> based on your recommendation.
>
> Hi Miere/Kim,
>
> I am in the office now and will try both your approaches tonight on my home
> computer.
>
> Thanks a lot for your help.
>
> Steve
>
> On Tue, Feb 7, 2017 at 2:22 PM, Bill O'Neil <bill at dartalley.com> wrote:
>>
>> @Steve - If your exception handler is in the handler chain before calling
>> dispatch then an exception is thrown it might not be handled properly (I
>> think I ran into this). If you make sure you add an exception handler after
>> calling dispatch that handles Throwable.class but before your logic, you
>> should be able to catch all Exceptions. I'm not 100% positive here but this
>> seemed to work for me.
>>
>>
>> On Tue, Feb 7, 2017 at 1:48 PM, Kim Rasmussen <kr at asseco.dk> wrote:
>>>
>>> Hi,
>>>
>>> I have had success with adding the system property:
>>>
>>> -Dorg.jboss.logging.provider=slf4j
>>>
>>> A random search for this on the net revelated this page which does a good
>>> job of explaining various ways of getting it working with WildFly - I myself
>>> use Undertow embedded, so the system property is enough for me.
>>>
>>> /Kim
>>>
>>> 2017-02-07 11:55 GMT+01:00 Miere Teixeira <miere.teixeira at gmail.com>:
>>>>
>>>> Hi Steve,
>>>>
>>>> I've found myself on the same situation couple of years ago and to solve
>>>> my problem I've configured the LoggerProvider to point to
>>>> Slf4JLoggerProvider. Basically, this can be reproduced by declaring a
>>>> META-INF/services/org.jboss.logging.LoggerProvider file with
>>>> org.jboss.logging.Slf4jLoggerProvider as a value.
>>>>
>>>> I hope it helps.
>>>>
>>>> Cheers!
>>>>
>>>>
>>>> On Mon, Feb 6, 2017 at 9:09 PM Steve Hu <stevehu at gmail.com> wrote:
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> undertow-dev mailing list
>>>>> undertow-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>
>>>> --
>>>>
>>>> Miere Teixeira
>>>>
>>>>
>>>> _______________________________________________
>>>> undertow-dev mailing list
>>>> undertow-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>>
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>>
>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From bill at dartalley.com  Tue Feb  7 18:01:12 2017
From: bill at dartalley.com (Bill O'Neil)
Date: Tue, 7 Feb 2017 18:01:12 -0500
Subject: [undertow-dev] Undertow jboss logging redirect to logback log
 file and console
In-Reply-To: <CAD+L2cxU98_5WMNa-cbZygxzRsDCCKRgyev_dAkDW8Gaacvm-Q@mail.gmail.com>
References: <CAGjN9KVFVpTdr5+6pt2MLPm55cfEH02=nJ5EGT9cxu+8VrRyLQ@mail.gmail.com>
	<CAHezjrQbTs0uCncjyGajXdGKBpBy7z3Gej+q_6_uOAzc=Ng5eQ@mail.gmail.com>
	<CAGX6Y=1ydCyhi=KwiVtVi9LQvCbtep1TQm3BBUVSm3KrvgTGoA@mail.gmail.com>
	<CANd+gFzhWr0ejYMytzRQ6C49t+AgKOEbCmFyovJHQrEJt=hBtg@mail.gmail.com>
	<CAGjN9KWVOJV2L28YS_7AMFvbsE6jTeNfXEYojs+OobLy8wddNQ@mail.gmail.com>
	<CAD+L2cxU98_5WMNa-cbZygxzRsDCCKRgyev_dAkDW8Gaacvm-Q@mail.gmail.com>
Message-ID: <CANd+gFz7MZ6EjmQPW3D3vUEFaYCjY90czzbr4anoCzs_aacDyg@mail.gmail.com>

I think I added this a long time ago not sure if anyone other than me uses
it.
https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/server/handlers/ExceptionHandler.java
It does add the exception to the exchange as an attachment. However in the
above scenario it still might not be handled.

I prefer the first option I think its pretty clean when all the handlers
follow the same interface. Using attachments is already a common pattern.

I was thinking of a way to modify the existing ExceptionHandler to call
your proposed setExceptionHandler or even set it as an attachment but
realized it might infinite loop. Would it instead need to be split to a
handler responsible for setting the attachment and one for handling it?
Ideally my ExceptionHandler in the handler chain as well as the registered
handler for exceptions that propagate outside the chain could be one and
the same.


On Tue, Feb 7, 2017 at 5:26 PM, Stuart Douglas <sdouglas at redhat.com> wrote:

> I think this is something I should address in Undertow Core (Servlet
> already has io.undertow.servlet.api.ExceptionHandler), to allow you to
> register a handler that will be called if an exception propagates
> outside of the handler chain.
>
> I think there are two options:
>
> 1) HttpServerExchange.setExceptionHandler(HttpHandler handler), and
> then make the exception available as an attachment on the Exchange.
> 2) HttpServerExchange.setExceptionHandler(ExceptionHandler handler),
> where ExceptionHandler has a single method that takes the exchange and
> the exception.
>
> Thoughts?
>
> Stuart
>
> On Wed, Feb 8, 2017 at 7:26 AM, Steve Hu <stevehu at gmail.com> wrote:
> > Hi Bill,
> >
> > My exception handler is the first in the chain and it captures majority
> of
> > exceptions but this one. It is basically a try/catch block to wrap all
> > handler calls and you can find the source code at
> > https://github.com/networknt/light-java/blob/master/
> exception/src/main/java/com/networknt/exception/ExceptionHandler.java
> >
> > I will try to dispatch in this handler first tonight and see if it works
> > based on your recommendation.
> >
> > Hi Miere/Kim,
> >
> > I am in the office now and will try both your approaches tonight on my
> home
> > computer.
> >
> > Thanks a lot for your help.
> >
> > Steve
> >
> > On Tue, Feb 7, 2017 at 2:22 PM, Bill O'Neil <bill at dartalley.com> wrote:
> >>
> >> @Steve - If your exception handler is in the handler chain before
> calling
> >> dispatch then an exception is thrown it might not be handled properly (I
> >> think I ran into this). If you make sure you add an exception handler
> after
> >> calling dispatch that handles Throwable.class but before your logic, you
> >> should be able to catch all Exceptions. I'm not 100% positive here but
> this
> >> seemed to work for me.
> >>
> >>
> >> On Tue, Feb 7, 2017 at 1:48 PM, Kim Rasmussen <kr at asseco.dk> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I have had success with adding the system property:
> >>>
> >>> -Dorg.jboss.logging.provider=slf4j
> >>>
> >>> A random search for this on the net revelated this page which does a
> good
> >>> job of explaining various ways of getting it working with WildFly - I
> myself
> >>> use Undertow embedded, so the system property is enough for me.
> >>>
> >>> /Kim
> >>>
> >>> 2017-02-07 11:55 GMT+01:00 Miere Teixeira <miere.teixeira at gmail.com>:
> >>>>
> >>>> Hi Steve,
> >>>>
> >>>> I've found myself on the same situation couple of years ago and to
> solve
> >>>> my problem I've configured the LoggerProvider to point to
> >>>> Slf4JLoggerProvider. Basically, this can be reproduced by declaring a
> >>>> META-INF/services/org.jboss.logging.LoggerProvider file with
> >>>> org.jboss.logging.Slf4jLoggerProvider as a value.
> >>>>
> >>>> I hope it helps.
> >>>>
> >>>> Cheers!
> >>>>
> >>>>
> >>>> On Mon, Feb 6, 2017 at 9:09 PM Steve Hu <stevehu at gmail.com> wrote:
> >>>>>
> >>>>> 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
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> undertow-dev mailing list
> >>>>> undertow-dev at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>>>
> >>>> --
> >>>>
> >>>> Miere Teixeira
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> undertow-dev mailing list
> >>>> undertow-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> 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
> >>>
> >>>
> >>> _______________________________________________
> >>> undertow-dev mailing list
> >>> undertow-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>
> >>
> >>
> >> _______________________________________________
> >> undertow-dev mailing list
> >> undertow-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >
> >
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170207/1c05fed7/attachment.html 

From stevehu at gmail.com  Tue Feb  7 21:06:41 2017
From: stevehu at gmail.com (Steve Hu)
Date: Tue, 7 Feb 2017 21:06:41 -0500
Subject: [undertow-dev] Undertow jboss logging redirect to logback log
 file and console
In-Reply-To: <CANd+gFz7MZ6EjmQPW3D3vUEFaYCjY90czzbr4anoCzs_aacDyg@mail.gmail.com>
References: <CAGjN9KVFVpTdr5+6pt2MLPm55cfEH02=nJ5EGT9cxu+8VrRyLQ@mail.gmail.com>
	<CAHezjrQbTs0uCncjyGajXdGKBpBy7z3Gej+q_6_uOAzc=Ng5eQ@mail.gmail.com>
	<CAGX6Y=1ydCyhi=KwiVtVi9LQvCbtep1TQm3BBUVSm3KrvgTGoA@mail.gmail.com>
	<CANd+gFzhWr0ejYMytzRQ6C49t+AgKOEbCmFyovJHQrEJt=hBtg@mail.gmail.com>
	<CAGjN9KWVOJV2L28YS_7AMFvbsE6jTeNfXEYojs+OobLy8wddNQ@mail.gmail.com>
	<CAD+L2cxU98_5WMNa-cbZygxzRsDCCKRgyev_dAkDW8Gaacvm-Q@mail.gmail.com>
	<CANd+gFz7MZ6EjmQPW3D3vUEFaYCjY90czzbr4anoCzs_aacDyg@mail.gmail.com>
Message-ID: <CAGjN9KUG4pe8U-jCxOE8VAveKyop44dWAcb__0gUA+qotzqavA@mail.gmail.com>

Stuart,

I would prefer the second signature as it limits only Handlers that
implement the interface to be passed in.

Bill,

I missed your ExceptionHandler and implemented a customized one similar
like yours in handleRequest:(

Thanks,

Steve

On Tue, Feb 7, 2017 at 6:01 PM, Bill O'Neil <bill at dartalley.com> wrote:

> I think I added this a long time ago not sure if anyone other than me uses
> it. https://github.com/undertow-io/undertow/blob/
> master/core/src/main/java/io/undertow/server/handlers/
> ExceptionHandler.java
> It does add the exception to the exchange as an attachment. However in the
> above scenario it still might not be handled.
>
> I prefer the first option I think its pretty clean when all the handlers
> follow the same interface. Using attachments is already a common pattern.
>
> I was thinking of a way to modify the existing ExceptionHandler to call
> your proposed setExceptionHandler or even set it as an attachment but
> realized it might infinite loop. Would it instead need to be split to a
> handler responsible for setting the attachment and one for handling it?
> Ideally my ExceptionHandler in the handler chain as well as the registered
> handler for exceptions that propagate outside the chain could be one and
> the same.
>
>
> On Tue, Feb 7, 2017 at 5:26 PM, Stuart Douglas <sdouglas at redhat.com>
> wrote:
>
>> I think this is something I should address in Undertow Core (Servlet
>> already has io.undertow.servlet.api.ExceptionHandler), to allow you to
>> register a handler that will be called if an exception propagates
>> outside of the handler chain.
>>
>> I think there are two options:
>>
>> 1) HttpServerExchange.setExceptionHandler(HttpHandler handler), and
>> then make the exception available as an attachment on the Exchange.
>> 2) HttpServerExchange.setExceptionHandler(ExceptionHandler handler),
>> where ExceptionHandler has a single method that takes the exchange and
>> the exception.
>>
>> Thoughts?
>>
>> Stuart
>>
>> On Wed, Feb 8, 2017 at 7:26 AM, Steve Hu <stevehu at gmail.com> wrote:
>> > Hi Bill,
>> >
>> > My exception handler is the first in the chain and it captures majority
>> of
>> > exceptions but this one. It is basically a try/catch block to wrap all
>> > handler calls and you can find the source code at
>> > https://github.com/networknt/light-java/blob/master/exceptio
>> n/src/main/java/com/networknt/exception/ExceptionHandler.java
>> >
>> > I will try to dispatch in this handler first tonight and see if it works
>> > based on your recommendation.
>> >
>> > Hi Miere/Kim,
>> >
>> > I am in the office now and will try both your approaches tonight on my
>> home
>> > computer.
>> >
>> > Thanks a lot for your help.
>> >
>> > Steve
>> >
>> > On Tue, Feb 7, 2017 at 2:22 PM, Bill O'Neil <bill at dartalley.com> wrote:
>> >>
>> >> @Steve - If your exception handler is in the handler chain before
>> calling
>> >> dispatch then an exception is thrown it might not be handled properly
>> (I
>> >> think I ran into this). If you make sure you add an exception handler
>> after
>> >> calling dispatch that handles Throwable.class but before your logic,
>> you
>> >> should be able to catch all Exceptions. I'm not 100% positive here but
>> this
>> >> seemed to work for me.
>> >>
>> >>
>> >> On Tue, Feb 7, 2017 at 1:48 PM, Kim Rasmussen <kr at asseco.dk> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> I have had success with adding the system property:
>> >>>
>> >>> -Dorg.jboss.logging.provider=slf4j
>> >>>
>> >>> A random search for this on the net revelated this page which does a
>> good
>> >>> job of explaining various ways of getting it working with WildFly - I
>> myself
>> >>> use Undertow embedded, so the system property is enough for me.
>> >>>
>> >>> /Kim
>> >>>
>> >>> 2017-02-07 11:55 GMT+01:00 Miere Teixeira <miere.teixeira at gmail.com>:
>> >>>>
>> >>>> Hi Steve,
>> >>>>
>> >>>> I've found myself on the same situation couple of years ago and to
>> solve
>> >>>> my problem I've configured the LoggerProvider to point to
>> >>>> Slf4JLoggerProvider. Basically, this can be reproduced by declaring a
>> >>>> META-INF/services/org.jboss.logging.LoggerProvider file with
>> >>>> org.jboss.logging.Slf4jLoggerProvider as a value.
>> >>>>
>> >>>> I hope it helps.
>> >>>>
>> >>>> Cheers!
>> >>>>
>> >>>>
>> >>>> On Mon, Feb 6, 2017 at 9:09 PM Steve Hu <stevehu at gmail.com> wrote:
>> >>>>>
>> >>>>> 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
>> >>>>>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> undertow-dev mailing list
>> >>>>> undertow-dev at lists.jboss.org
>> >>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>> >>>>
>> >>>> --
>> >>>>
>> >>>> Miere Teixeira
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> undertow-dev mailing list
>> >>>> undertow-dev at lists.jboss.org
>> >>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> 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
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> undertow-dev mailing list
>> >>> undertow-dev at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> undertow-dev mailing list
>> >> undertow-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/undertow-dev
>> >
>> >
>> >
>> > _______________________________________________
>> > undertow-dev mailing list
>> > undertow-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170207/380c1c8d/attachment-0001.html 

From stevehu at gmail.com  Tue Feb  7 21:48:44 2017
From: stevehu at gmail.com (Steve Hu)
Date: Tue, 7 Feb 2017 21:48:44 -0500
Subject: [undertow-dev] Undertow jboss logging redirect to logback log
 file and console
In-Reply-To: <CAGX6Y=1ydCyhi=KwiVtVi9LQvCbtep1TQm3BBUVSm3KrvgTGoA@mail.gmail.com>
References: <CAGjN9KVFVpTdr5+6pt2MLPm55cfEH02=nJ5EGT9cxu+8VrRyLQ@mail.gmail.com>
	<CAHezjrQbTs0uCncjyGajXdGKBpBy7z3Gej+q_6_uOAzc=Ng5eQ@mail.gmail.com>
	<CAGX6Y=1ydCyhi=KwiVtVi9LQvCbtep1TQm3BBUVSm3KrvgTGoA@mail.gmail.com>
Message-ID: <CAGjN9KWeObc-mq_yOQ58fV84YmH4OqWeEoBqXHN=x4QKdz_dog@mail.gmail.com>

Hi Kim/Miere,

As a temp solution, I have tried both approaches and I can confirm that the
system property works. Somehow, I cannot make the SPI work. I even tried to
include jboss-logging, jboss-logging-processor and jboss-logmanager.

Thanks,

Steve

On Tue, Feb 7, 2017 at 1:48 PM, Kim Rasmussen <kr at asseco.dk> wrote:

> Hi,
>
> I have had success with adding the system property:
>
> -Dorg.jboss.logging.provider=slf4j
>
> A random search for this on the net revelated this page which does a good
> job of explaining various ways of getting it working with WildFly - I
> myself use Undertow embedded, so the system property is enough for me.
>
> /Kim
>
> 2017-02-07 11:55 GMT+01:00 Miere Teixeira <miere.teixeira at gmail.com>:
>
>> Hi Steve,
>>
>> I've found myself on the same situation couple of years ago and to solve
>> my problem I've configured the LoggerProvider to point to
>> Slf4JLoggerProvider. Basically, this can be reproduced by declaring a
>> META-INF/services/org.jboss.logging.LoggerProvider file with
>> org.jboss.logging.Slf4jLoggerProvider as a value.
>>
>> I hope it helps.
>>
>> Cheers!
>>
>>
>> On Mon, Feb 6, 2017 at 9:09 PM Steve Hu <stevehu at gmail.com> wrote:
>>
>>> 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
>>>
>>>
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>> --
>>
>> Miere Teixeira
>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>
>
>
> --
> 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 <+45%2026%2016%2040%2023>
> Ph.: +45 33 36 46 60 <+45%2033%2036%2046%2060>
> Fax: +45 33 36 46 61 <+45%2033%2036%2046%2061>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170207/607bc927/attachment.html 

From matthieu at brouillard.fr  Wed Feb  8 04:29:53 2017
From: matthieu at brouillard.fr (Matthieu BROUILLARD)
Date: Wed, 8 Feb 2017 10:29:53 +0100
Subject: [undertow-dev] ChangeSessionIdOnLogin unexpected behavior during
	SPA initialization
Message-ID: <CADsuJr9w=mXFhyUvq3=MMB+yxTJ9bAuMfKR7BuiSV96gVw6Tjw@mail.gmail.com>

Hi all,

first of all sorry if some of you already answered on my IRC request on
freenode but due to network policy in my company I could only connect via
web and have been disconnected without access to channel history.
I apologize if you already took time to answer on the channel but I could
not see your answer.

The problem I have is around the 'ChangeSessionIdOnLogin' feature
implemented in undertow. I understand that the feature is there in order to
avoid attacks via session reuse (exposing a link with an already provided
JSESSIONID for example).

In one of our application, a SPA application with some server side
HttpSession caching, during initialization a bunch of asynchronous calls
are performed. Due to the 'ChangeSessionIdOnLogin' feature several of them
are failing.
I have implemented a simple reproducer application exposing the problem and
possible workarounds (examples are self runnable using maven :
https://github.com/McFoggy/jsessionid-concurrency).

In the provided reproducer app we workaround the JSESSIONID regeneration by
either:
  - making a fake call before the asynchronous calls are performed
(changing the JSESSIONID before parallel calls occure)
  - disabling the 'ChangeSessionIdOnLogin' feature using an undertow
ServletExtension

The real question I have is why the created session is not trusted (see
https://github.com/undertow-io/undertow/blob/master/servlet/src/main/java/io/undertow/servlet/handlers/security/CachedAuthenticatedSessionHandler.java#L93)
when the HttpSession is created by an authenticated call without incoming
JSESSIONID?

Is this a bug? I'll fill an issue if so.
Is this a feature? In this case what is the recommendation to avoid this
when several calls are issued before JSESSIONID stabilization like in the
demo project?

Thanks for any hint & answer.

Matthieu
- - - - - - - - - - - - - - - -
http://blog.matthieu.brouillard.fr/
http://oss.brouillard.fr/
https://github.com/McFoggy
https://twitter.com/alightinthefog
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170208/46ba3db2/attachment.html 

From stevehu at gmail.com  Wed Feb  8 05:53:49 2017
From: stevehu at gmail.com (Steve Hu)
Date: Wed, 8 Feb 2017 05:53:49 -0500
Subject: [undertow-dev] Undertow jboss logging redirect to logback log
 file and console
In-Reply-To: <CAGjN9KWeObc-mq_yOQ58fV84YmH4OqWeEoBqXHN=x4QKdz_dog@mail.gmail.com>
References: <CAGjN9KVFVpTdr5+6pt2MLPm55cfEH02=nJ5EGT9cxu+8VrRyLQ@mail.gmail.com>
	<CAHezjrQbTs0uCncjyGajXdGKBpBy7z3Gej+q_6_uOAzc=Ng5eQ@mail.gmail.com>
	<CAGX6Y=1ydCyhi=KwiVtVi9LQvCbtep1TQm3BBUVSm3KrvgTGoA@mail.gmail.com>
	<CAGjN9KWeObc-mq_yOQ58fV84YmH4OqWeEoBqXHN=x4QKdz_dog@mail.gmail.com>
Message-ID: <CAGjN9KXNCRnpQ-fsN4L_Z7Cuj5R4GWQYfgVDMrfOVhZLRvx+GA@mail.gmail.com>

Just summarize what I have done and I think this is working for me very
well.

1. I have put a line in my server during server start up to redirect
Undertow logs to slf4j. -D in command line works but I think it impact the
DevOps flow.

System.setProperty("org.jboss.logging.provider", "slf4j");

2. I have put the following lines to dispatch in the beginning of
ExceptionHandler.handleRequest. I think this is fine as most handlers
shouldn't be executed in IO thread anyway. This will make sure that
all exceptions will be captured by my handler instead of Connectors.

if (exchange.isInIoThread()) {
    exchange.dispatch(this);
    return;
}

Thanks everyone for your help.

Steve



On Tue, Feb 7, 2017 at 9:48 PM, Steve Hu <stevehu at gmail.com> wrote:

> Hi Kim/Miere,
>
> As a temp solution, I have tried both approaches and I can confirm that
> the system property works. Somehow, I cannot make the SPI work. I even
> tried to include jboss-logging, jboss-logging-processor and
> jboss-logmanager.
>
> Thanks,
>
> Steve
>
> On Tue, Feb 7, 2017 at 1:48 PM, Kim Rasmussen <kr at asseco.dk> wrote:
>
>> Hi,
>>
>> I have had success with adding the system property:
>>
>> -Dorg.jboss.logging.provider=slf4j
>>
>> A random search for this on the net revelated this page which does a good
>> job of explaining various ways of getting it working with WildFly - I
>> myself use Undertow embedded, so the system property is enough for me.
>>
>> /Kim
>>
>> 2017-02-07 11:55 GMT+01:00 Miere Teixeira <miere.teixeira at gmail.com>:
>>
>>> Hi Steve,
>>>
>>> I've found myself on the same situation couple of years ago and to solve
>>> my problem I've configured the LoggerProvider to point to
>>> Slf4JLoggerProvider. Basically, this can be reproduced by declaring a
>>> META-INF/services/org.jboss.logging.LoggerProvider file with
>>> org.jboss.logging.Slf4jLoggerProvider as a value.
>>>
>>> I hope it helps.
>>>
>>> Cheers!
>>>
>>>
>>> On Mon, Feb 6, 2017 at 9:09 PM Steve Hu <stevehu at gmail.com> wrote:
>>>
>>>> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> undertow-dev mailing list
>>>> undertow-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>>> --
>>>
>>> Miere Teixeira
>>>
>>> _______________________________________________
>>> undertow-dev mailing list
>>> undertow-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>>
>>
>>
>> --
>> 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 <+45%2026%2016%2040%2023>
>> Ph.: +45 33 36 46 60 <+45%2033%2036%2046%2060>
>> Fax: +45 33 36 46 61 <+45%2033%2036%2046%2061>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170208/62a3c0c1/attachment-0001.html 

From bill at dartalley.com  Wed Feb  8 06:22:51 2017
From: bill at dartalley.com (Bill O'Neil)
Date: Wed, 8 Feb 2017 06:22:51 -0500
Subject: [undertow-dev] Undertow jboss logging redirect to logback log
 file and console
In-Reply-To: <CAGjN9KXNCRnpQ-fsN4L_Z7Cuj5R4GWQYfgVDMrfOVhZLRvx+GA@mail.gmail.com>
References: <CAGjN9KVFVpTdr5+6pt2MLPm55cfEH02=nJ5EGT9cxu+8VrRyLQ@mail.gmail.com>
	<CAHezjrQbTs0uCncjyGajXdGKBpBy7z3Gej+q_6_uOAzc=Ng5eQ@mail.gmail.com>
	<CAGX6Y=1ydCyhi=KwiVtVi9LQvCbtep1TQm3BBUVSm3KrvgTGoA@mail.gmail.com>
	<CAGjN9KWeObc-mq_yOQ58fV84YmH4OqWeEoBqXHN=x4QKdz_dog@mail.gmail.com>
	<CAGjN9KXNCRnpQ-fsN4L_Z7Cuj5R4GWQYfgVDMrfOVhZLRvx+GA@mail.gmail.com>
Message-ID: <CANd+gFwN6ro5ERq39z4dxLKwLANuqdgPot141BX3pdp2_6QiBw@mail.gmail.com>

2. As long as you are ok with making every route a blocking route that
should be fine. I did the same thing.

https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/server/handlers/BlockingHandler.java#L52

I use the blocking handler above before passing to the exception handler.
Your return seems out of place and it also never calls startBlocking(). I'm
not sure how important that is.

On Wed, Feb 8, 2017 at 5:53 AM, Steve Hu <stevehu at gmail.com> wrote:

> Just summarize what I have done and I think this is working for me very
> well.
>
> 1. I have put a line in my server during server start up to redirect
> Undertow logs to slf4j. -D in command line works but I think it impact the
> DevOps flow.
>
> System.setProperty("org.jboss.logging.provider", "slf4j");
>
> 2. I have put the following lines to dispatch in the beginning of ExceptionHandler.handleRequest. I think this is fine as most handlers shouldn't be executed in IO thread anyway. This will make sure that all exceptions will be captured by my handler instead of Connectors.
>
> if (exchange.isInIoThread()) {
>     exchange.dispatch(this);
>     return;
> }
>
> Thanks everyone for your help.
>
> Steve
>
>
>
> On Tue, Feb 7, 2017 at 9:48 PM, Steve Hu <stevehu at gmail.com> wrote:
>
>> Hi Kim/Miere,
>>
>> As a temp solution, I have tried both approaches and I can confirm that
>> the system property works. Somehow, I cannot make the SPI work. I even
>> tried to include jboss-logging, jboss-logging-processor and
>> jboss-logmanager.
>>
>> Thanks,
>>
>> Steve
>>
>> On Tue, Feb 7, 2017 at 1:48 PM, Kim Rasmussen <kr at asseco.dk> wrote:
>>
>>> Hi,
>>>
>>> I have had success with adding the system property:
>>>
>>> -Dorg.jboss.logging.provider=slf4j
>>>
>>> A random search for this on the net revelated this page which does a
>>> good job of explaining various ways of getting it working with WildFly - I
>>> myself use Undertow embedded, so the system property is enough for me.
>>>
>>> /Kim
>>>
>>> 2017-02-07 11:55 GMT+01:00 Miere Teixeira <miere.teixeira at gmail.com>:
>>>
>>>> Hi Steve,
>>>>
>>>> I've found myself on the same situation couple of years ago and to
>>>> solve my problem I've configured the LoggerProvider to point to
>>>> Slf4JLoggerProvider. Basically, this can be reproduced by declaring a
>>>> META-INF/services/org.jboss.logging.LoggerProvider file with
>>>> org.jboss.logging.Slf4jLoggerProvider as a value.
>>>>
>>>> I hope it helps.
>>>>
>>>> Cheers!
>>>>
>>>>
>>>> On Mon, Feb 6, 2017 at 9:09 PM Steve Hu <stevehu at gmail.com> wrote:
>>>>
>>>>> 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
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> undertow-dev mailing list
>>>>> undertow-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>
>>>> --
>>>>
>>>> Miere Teixeira
>>>>
>>>> _______________________________________________
>>>> undertow-dev mailing list
>>>> undertow-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>
>>>
>>>
>>>
>>> --
>>> 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 <+45%2026%2016%2040%2023>
>>> Ph.: +45 33 36 46 60 <+45%2033%2036%2046%2060>
>>> Fax: +45 33 36 46 61 <+45%2033%2036%2046%2061>
>>>
>>
>>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170208/e35042c3/attachment.html 

From bill at dartalley.com  Wed Feb  8 06:23:50 2017
From: bill at dartalley.com (Bill O'Neil)
Date: Wed, 8 Feb 2017 06:23:50 -0500
Subject: [undertow-dev] Undertow jboss logging redirect to logback log
 file and console
In-Reply-To: <CANd+gFwN6ro5ERq39z4dxLKwLANuqdgPot141BX3pdp2_6QiBw@mail.gmail.com>
References: <CAGjN9KVFVpTdr5+6pt2MLPm55cfEH02=nJ5EGT9cxu+8VrRyLQ@mail.gmail.com>
	<CAHezjrQbTs0uCncjyGajXdGKBpBy7z3Gej+q_6_uOAzc=Ng5eQ@mail.gmail.com>
	<CAGX6Y=1ydCyhi=KwiVtVi9LQvCbtep1TQm3BBUVSm3KrvgTGoA@mail.gmail.com>
	<CAGjN9KWeObc-mq_yOQ58fV84YmH4OqWeEoBqXHN=x4QKdz_dog@mail.gmail.com>
	<CAGjN9KXNCRnpQ-fsN4L_Z7Cuj5R4GWQYfgVDMrfOVhZLRvx+GA@mail.gmail.com>
	<CANd+gFwN6ro5ERq39z4dxLKwLANuqdgPot141BX3pdp2_6QiBw@mail.gmail.com>
Message-ID: <CANd+gFzeJwb53MUtfMQJBpoJtzDA7ysHhEDNZMBuyU0aKte0Pg@mail.gmail.com>

Never mind I think the return is ok. I forgot it executes handle again once
the other thread gets the exchange.

On Wed, Feb 8, 2017 at 6:22 AM, Bill O'Neil <bill at dartalley.com> wrote:

> 2. As long as you are ok with making every route a blocking route that
> should be fine. I did the same thing.
>
> https://github.com/undertow-io/undertow/blob/master/core/
> src/main/java/io/undertow/server/handlers/BlockingHandler.java#L52
>
> I use the blocking handler above before passing to the exception handler.
> Your return seems out of place and it also never calls startBlocking(). I'm
> not sure how important that is.
>
> On Wed, Feb 8, 2017 at 5:53 AM, Steve Hu <stevehu at gmail.com> wrote:
>
>> Just summarize what I have done and I think this is working for me very
>> well.
>>
>> 1. I have put a line in my server during server start up to redirect
>> Undertow logs to slf4j. -D in command line works but I think it impact the
>> DevOps flow.
>>
>> System.setProperty("org.jboss.logging.provider", "slf4j");
>>
>> 2. I have put the following lines to dispatch in the beginning of ExceptionHandler.handleRequest. I think this is fine as most handlers shouldn't be executed in IO thread anyway. This will make sure that all exceptions will be captured by my handler instead of Connectors.
>>
>> if (exchange.isInIoThread()) {
>>     exchange.dispatch(this);
>>     return;
>> }
>>
>> Thanks everyone for your help.
>>
>> Steve
>>
>>
>>
>> On Tue, Feb 7, 2017 at 9:48 PM, Steve Hu <stevehu at gmail.com> wrote:
>>
>>> Hi Kim/Miere,
>>>
>>> As a temp solution, I have tried both approaches and I can confirm that
>>> the system property works. Somehow, I cannot make the SPI work. I even
>>> tried to include jboss-logging, jboss-logging-processor and
>>> jboss-logmanager.
>>>
>>> Thanks,
>>>
>>> Steve
>>>
>>> On Tue, Feb 7, 2017 at 1:48 PM, Kim Rasmussen <kr at asseco.dk> wrote:
>>>
>>>> Hi,
>>>>
>>>> I have had success with adding the system property:
>>>>
>>>> -Dorg.jboss.logging.provider=slf4j
>>>>
>>>> A random search for this on the net revelated this page which does a
>>>> good job of explaining various ways of getting it working with WildFly - I
>>>> myself use Undertow embedded, so the system property is enough for me.
>>>>
>>>> /Kim
>>>>
>>>> 2017-02-07 11:55 GMT+01:00 Miere Teixeira <miere.teixeira at gmail.com>:
>>>>
>>>>> Hi Steve,
>>>>>
>>>>> I've found myself on the same situation couple of years ago and to
>>>>> solve my problem I've configured the LoggerProvider to point to
>>>>> Slf4JLoggerProvider. Basically, this can be reproduced by declaring a
>>>>> META-INF/services/org.jboss.logging.LoggerProvider file with
>>>>> org.jboss.logging.Slf4jLoggerProvider as a value.
>>>>>
>>>>> I hope it helps.
>>>>>
>>>>> Cheers!
>>>>>
>>>>>
>>>>> On Mon, Feb 6, 2017 at 9:09 PM Steve Hu <stevehu at gmail.com> wrote:
>>>>>
>>>>>> 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
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> undertow-dev mailing list
>>>>>> undertow-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>
>>>>> --
>>>>>
>>>>> Miere Teixeira
>>>>>
>>>>> _______________________________________________
>>>>> undertow-dev mailing list
>>>>> undertow-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> 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 <+45%2026%2016%2040%2023>
>>>> Ph.: +45 33 36 46 60 <+45%2033%2036%2046%2060>
>>>> Fax: +45 33 36 46 61 <+45%2033%2036%2046%2061>
>>>>
>>>
>>>
>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170208/7a4b22ef/attachment-0001.html 

From matt at matthicks.com  Wed Feb  8 11:35:57 2017
From: matt at matthicks.com (Hicks, Matt)
Date: Wed, 08 Feb 2017 16:35:57 +0000
Subject: [undertow-dev] exchange.getResponseSender().send issues
Message-ID: <CAFeDf1--BXV-RAc0PpZrJFbUSH0yaTdf--k0J7EUFWRPTLCtXg@mail.gmail.com>

I'm having a very strange problem sending a generated HTML file back to the
browser using `exchange.getResponseSender().send(s)`.  It seems to work
fine if the content is a short bit of text like "Hello World", but the
content is 144,772 bytes and if I use Curl to test it I get a 200 OK, but
it says the Content-Length is 0 and no content comes back.  If I set the
content to a short String like I said, then the Content-Length is properly
set and the content comes back like expected.

Should I not be using `exchange.getResponseSender().send` for large amounts
of text?

I just updated to 1.4.10.Final hoping that it was a bug that was fixed
since 1.4.8.Final, but it's still happening.

Any insights would be greatly appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170208/3628a1a2/attachment.html 

From matt at matthicks.com  Wed Feb  8 11:41:28 2017
From: matt at matthicks.com (Hicks, Matt)
Date: Wed, 08 Feb 2017 16:41:28 +0000
Subject: [undertow-dev] exchange.getResponseSender().send issues
In-Reply-To: <CAFeDf1--BXV-RAc0PpZrJFbUSH0yaTdf--k0J7EUFWRPTLCtXg@mail.gmail.com>
References: <CAFeDf1--BXV-RAc0PpZrJFbUSH0yaTdf--k0J7EUFWRPTLCtXg@mail.gmail.com>
Message-ID: <CAFeDf1-+w5jw4Db1yQL2U1xD4HjaoCjW+T6eb_Ja9xXP+kSfmA@mail.gmail.com>

Well, I just added an IoCallback and now I'm getting an error: Attempted to
write 144780 bytes however content-length has been set to 144772

This, I think, raises both a question and an issue:

Question: Should I not be setting the Content-Length myself even when using
exchange.getResponseSender().send?
Issue: Seems like a bug that without an IoCallback the error is just
absorbed and never logged anywhere.

On Wed, Feb 8, 2017 at 10:35 AM Hicks, Matt <matt at matthicks.com> wrote:

> I'm having a very strange problem sending a generated HTML file back to
> the browser using `exchange.getResponseSender().send(s)`.  It seems to work
> fine if the content is a short bit of text like "Hello World", but the
> content is 144,772 bytes and if I use Curl to test it I get a 200 OK, but
> it says the Content-Length is 0 and no content comes back.  If I set the
> content to a short String like I said, then the Content-Length is properly
> set and the content comes back like expected.
>
> Should I not be using `exchange.getResponseSender().send` for large
> amounts of text?
>
> I just updated to 1.4.10.Final hoping that it was a bug that was fixed
> since 1.4.8.Final, but it's still happening.
>
> Any insights would be greatly appreciated.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170208/bc4d446d/attachment.html 

From peter.royal at pobox.com  Wed Feb  8 11:44:13 2017
From: peter.royal at pobox.com (peter royal)
Date: Wed, 08 Feb 2017 10:44:13 -0600
Subject: [undertow-dev] exchange.getResponseSender().send issues
In-Reply-To: <CAFeDf1-+w5jw4Db1yQL2U1xD4HjaoCjW+T6eb_Ja9xXP+kSfmA@mail.gmail.com>
References: <CAFeDf1--BXV-RAc0PpZrJFbUSH0yaTdf--k0J7EUFWRPTLCtXg@mail.gmail.com>
	<CAFeDf1-+w5jw4Db1yQL2U1xD4HjaoCjW+T6eb_Ja9xXP+kSfmA@mail.gmail.com>
Message-ID: <1486572253.735174.874572488.256E7718@webmail.messagingengine.com>

I don't set a content-length myself when using that method to send text
(or binary) data.


-pete



--

(peter.royal|osi)@pobox.com - http://fotap.org/~osi





On Wed, Feb 8, 2017, at 10:41 AM, Hicks, Matt wrote:

> Well, I just added an IoCallback and now I'm getting an error:
> Attempted to write 144780 bytes however content-length has been set
> to 144772
> 

> This, I think, raises both a question and an issue:

> 

> Question: Should I not be setting the Content-Length myself even when
> using exchange.getResponseSender().send?
> Issue: Seems like a bug that without an IoCallback the error is just
> absorbed and never logged anywhere.
> 

> On Wed, Feb 8, 2017 at 10:35 AM Hicks, Matt
> <matt at matthicks.com> wrote:
>> I'm having a very strange problem sending a generated HTML file back
>> to the browser using `exchange.getResponseSender().send(s)`.  It
>> seems to work fine if the content is a short bit of text like "Hello
>> World", but the content is 144,772 bytes and if I use Curl to test it
>> I get a 200 OK, but it says the Content-Length is 0 and no content
>> comes back.  If I set the content to a short String like I said, then
>> the Content-Length is properly set and the content comes back like
>> expected.
>> 

>> Should I not be using `exchange.getResponseSender().send` for large
>> amounts of text?
>> 

>> I just updated to 1.4.10.Final hoping that it was a bug that was
>> fixed since 1.4.8.Final, but it's still happening.
>> 

>> Any insights would be greatly appreciated.

> _________________________________________________

> undertow-dev mailing list

> undertow-dev at lists.jboss.org

> https://lists.jboss.org/mailman/listinfo/undertow-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170208/5be466fd/attachment.html 

From bill at dartalley.com  Wed Feb  8 11:46:30 2017
From: bill at dartalley.com (Bill O'Neil)
Date: Wed, 8 Feb 2017 11:46:30 -0500
Subject: [undertow-dev] exchange.getResponseSender().send issues
In-Reply-To: <1486572253.735174.874572488.256E7718@webmail.messagingengine.com>
References: <CAFeDf1--BXV-RAc0PpZrJFbUSH0yaTdf--k0J7EUFWRPTLCtXg@mail.gmail.com>
	<CAFeDf1-+w5jw4Db1yQL2U1xD4HjaoCjW+T6eb_Ja9xXP+kSfmA@mail.gmail.com>
	<1486572253.735174.874572488.256E7718@webmail.messagingengine.com>
Message-ID: <CANd+gFwP3mzpkG=6YJ_jpeF_LwfSG1SPZt5zfOJkm6HBeSMPLg@mail.gmail.com>

Are you manually setting the Content-Length? Someone had that issue before.
If you are using the send api it should be calculating that for you. The
different numbers make me thing its an encoding issue since bytes != length
of the string.

On Wed, Feb 8, 2017 at 11:44 AM, peter royal <peter.royal at pobox.com> wrote:

> I don't set a content-length myself when using that method to send text
> (or binary) data.
>
> -pete
>
> --
> (peter.royal|osi)@pobox.com - http://fotap.org/~osi
>
>
> On Wed, Feb 8, 2017, at 10:41 AM, Hicks, Matt wrote:
>
> Well, I just added an IoCallback and now I'm getting an error: Attempted
> to write 144780 bytes however content-length has been set to 144772
>
> This, I think, raises both a question and an issue:
>
> Question: Should I not be setting the Content-Length myself even when
> using exchange.getResponseSender().send?
> Issue: Seems like a bug that without an IoCallback the error is just
> absorbed and never logged anywhere.
>
> On Wed, Feb 8, 2017 at 10:35 AM Hicks, Matt <matt at matthicks.com> wrote:
>
> I'm having a very strange problem sending a generated HTML file back to
> the browser using `exchange.getResponseSender().send(s)`.  It seems to
> work fine if the content is a short bit of text like "Hello World", but the
> content is 144,772 bytes and if I use Curl to test it I get a 200 OK, but
> it says the Content-Length is 0 and no content comes back.  If I set the
> content to a short String like I said, then the Content-Length is properly
> set and the content comes back like expected.
>
> Should I not be using `exchange.getResponseSender().send` for large
> amounts of text?
>
> I just updated to 1.4.10.Final hoping that it was a bug that was fixed
> since 1.4.8.Final, but it's still happening.
>
> Any insights would be greatly appreciated.
>
> *_______________________________________________*
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170208/c34f979c/attachment.html 

From matt at matthicks.com  Wed Feb  8 12:01:07 2017
From: matt at matthicks.com (Hicks, Matt)
Date: Wed, 08 Feb 2017 17:01:07 +0000
Subject: [undertow-dev] exchange.getResponseSender().send issues
In-Reply-To: <CAFeDf1-+w5jw4Db1yQL2U1xD4HjaoCjW+T6eb_Ja9xXP+kSfmA@mail.gmail.com>
References: <CAFeDf1--BXV-RAc0PpZrJFbUSH0yaTdf--k0J7EUFWRPTLCtXg@mail.gmail.com>
	<CAFeDf1-+w5jw4Db1yQL2U1xD4HjaoCjW+T6eb_Ja9xXP+kSfmA@mail.gmail.com>
Message-ID: <CAFeDf1_Qz=4skxobvwWyZaNs8tHt6UJU-2EX1a5g5A62VJDKOg@mail.gmail.com>

Well, modifying my computation to do myString.getBytes("UTF-8").length
instead of myString.length resolved the issue.  The silent failing still
has me concerned though.

On Wed, Feb 8, 2017 at 10:41 AM Hicks, Matt <matt at matthicks.com> wrote:

> Well, I just added an IoCallback and now I'm getting an error: Attempted
> to write 144780 bytes however content-length has been set to 144772
>
> This, I think, raises both a question and an issue:
>
> Question: Should I not be setting the Content-Length myself even when
> using exchange.getResponseSender().send?
> Issue: Seems like a bug that without an IoCallback the error is just
> absorbed and never logged anywhere.
>
> On Wed, Feb 8, 2017 at 10:35 AM Hicks, Matt <matt at matthicks.com> wrote:
>
> I'm having a very strange problem sending a generated HTML file back to
> the browser using `exchange.getResponseSender().send(s)`.  It seems to work
> fine if the content is a short bit of text like "Hello World", but the
> content is 144,772 bytes and if I use Curl to test it I get a 200 OK, but
> it says the Content-Length is 0 and no content comes back.  If I set the
> content to a short String like I said, then the Content-Length is properly
> set and the content comes back like expected.
>
> Should I not be using `exchange.getResponseSender().send` for large
> amounts of text?
>
> I just updated to 1.4.10.Final hoping that it was a bug that was fixed
> since 1.4.8.Final, but it's still happening.
>
> Any insights would be greatly appreciated.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170208/1287304d/attachment-0001.html 

From bill at dartalley.com  Wed Feb  8 12:05:16 2017
From: bill at dartalley.com (Bill O'Neil)
Date: Wed, 8 Feb 2017 12:05:16 -0500
Subject: [undertow-dev] exchange.getResponseSender().send issues
In-Reply-To: <CAFeDf1_Qz=4skxobvwWyZaNs8tHt6UJU-2EX1a5g5A62VJDKOg@mail.gmail.com>
References: <CAFeDf1--BXV-RAc0PpZrJFbUSH0yaTdf--k0J7EUFWRPTLCtXg@mail.gmail.com>
	<CAFeDf1-+w5jw4Db1yQL2U1xD4HjaoCjW+T6eb_Ja9xXP+kSfmA@mail.gmail.com>
	<CAFeDf1_Qz=4skxobvwWyZaNs8tHt6UJU-2EX1a5g5A62VJDKOg@mail.gmail.com>
Message-ID: <CANd+gFwRand3oHFZx549hBBRV+5smWzZzVPDjpcTX0E-Uhm3ow@mail.gmail.com>

You shouldn't need to be setting the content length manually with that API.

I agree with the exception, Stuart might have some thoughts on that. There
was another discussion about hooking in different loggers to the default
exception handler as well as an easier way to override it. This issue could
be related to that?

On Wed, Feb 8, 2017 at 12:01 PM, Hicks, Matt <matt at matthicks.com> wrote:

> Well, modifying my computation to do myString.getBytes("UTF-8").length
> instead of myString.length resolved the issue.  The silent failing still
> has me concerned though.
>
> On Wed, Feb 8, 2017 at 10:41 AM Hicks, Matt <matt at matthicks.com> wrote:
>
>> Well, I just added an IoCallback and now I'm getting an error: Attempted
>> to write 144780 bytes however content-length has been set to 144772
>>
>> This, I think, raises both a question and an issue:
>>
>> Question: Should I not be setting the Content-Length myself even when
>> using exchange.getResponseSender().send?
>> Issue: Seems like a bug that without an IoCallback the error is just
>> absorbed and never logged anywhere.
>>
>> On Wed, Feb 8, 2017 at 10:35 AM Hicks, Matt <matt at matthicks.com> wrote:
>>
>> I'm having a very strange problem sending a generated HTML file back to
>> the browser using `exchange.getResponseSender().send(s)`.  It seems to
>> work fine if the content is a short bit of text like "Hello World", but the
>> content is 144,772 bytes and if I use Curl to test it I get a 200 OK, but
>> it says the Content-Length is 0 and no content comes back.  If I set the
>> content to a short String like I said, then the Content-Length is properly
>> set and the content comes back like expected.
>>
>> Should I not be using `exchange.getResponseSender().send` for large
>> amounts of text?
>>
>> I just updated to 1.4.10.Final hoping that it was a bug that was fixed
>> since 1.4.8.Final, but it's still happening.
>>
>> Any insights would be greatly appreciated.
>>
>>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170208/c480bcf9/attachment.html 

From sdouglas at redhat.com  Wed Feb  8 19:42:09 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Thu, 9 Feb 2017 11:42:09 +1100
Subject: [undertow-dev] exchange.getResponseSender().send issues
In-Reply-To: <CAFeDf1--BXV-RAc0PpZrJFbUSH0yaTdf--k0J7EUFWRPTLCtXg@mail.gmail.com>
References: <CAFeDf1--BXV-RAc0PpZrJFbUSH0yaTdf--k0J7EUFWRPTLCtXg@mail.gmail.com>
Message-ID: <CAD+L2cx6EQe0yzg91SwTqEUux7JJSey+QYnThgcYeKV20fGYXg@mail.gmail.com>

If you call send() with no arguments it will calculate the content
length for you. Otherwise it will not, as it is possible to generate a
response through multiple send() invocations.

If you have not provided a callback
io.undertow.io.DefaultIoCallback#CALLBACK is used, which should have
been logging exceptions at debug level, however it appears not to be.
I have filed https://issues.jboss.org/browse/UNDERTOW-988 and fixed
the issue upstream. The logging is only at DEBUG level though, so you
still won't see it by default. The reason for this is that in general
IoException's are caused by the remote client closing the connection
(or the connection getting broken somehow). If this is logged at a
higher level then it is trivial for a malicious remote client to
generate massive amounts of logging (by simply sending a request and
then closing the connection). This can be used to DOS a server by
filling up its disks with logs, and also causing massive amounts of
disk IO.

Stuart

On Thu, Feb 9, 2017 at 3:35 AM, Hicks, Matt <matt at matthicks.com> wrote:
> I'm having a very strange problem sending a generated HTML file back to the
> browser using `exchange.getResponseSender().send(s)`.  It seems to work fine
> if the content is a short bit of text like "Hello World", but the content is
> 144,772 bytes and if I use Curl to test it I get a 200 OK, but it says the
> Content-Length is 0 and no content comes back.  If I set the content to a
> short String like I said, then the Content-Length is properly set and the
> content comes back like expected.
>
> Should I not be using `exchange.getResponseSender().send` for large amounts
> of text?
>
> I just updated to 1.4.10.Final hoping that it was a bug that was fixed since
> 1.4.8.Final, but it's still happening.
>
> Any insights would be greatly appreciated.
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From sdouglas at redhat.com  Wed Feb  8 19:44:25 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Thu, 9 Feb 2017 11:44:25 +1100
Subject: [undertow-dev] exchange.getResponseSender().send issues
In-Reply-To: <CAFeDf1_Qz=4skxobvwWyZaNs8tHt6UJU-2EX1a5g5A62VJDKOg@mail.gmail.com>
References: <CAFeDf1--BXV-RAc0PpZrJFbUSH0yaTdf--k0J7EUFWRPTLCtXg@mail.gmail.com>
	<CAFeDf1-+w5jw4Db1yQL2U1xD4HjaoCjW+T6eb_Ja9xXP+kSfmA@mail.gmail.com>
	<CAFeDf1_Qz=4skxobvwWyZaNs8tHt6UJU-2EX1a5g5A62VJDKOg@mail.gmail.com>
Message-ID: <CAD+L2cxq72FCNNrnt3PDm1bDa66omooVL=yDYDptdLA14FhT6w@mail.gmail.com>

On Thu, Feb 9, 2017 at 4:01 AM, Hicks, Matt <matt at matthicks.com> wrote:
> Well, modifying my computation to do myString.getBytes("UTF-8").length
> instead of myString.length resolved the issue.  The silent failing still has
> me concerned though.

You are much better off just letting undertow do it. If you do it like
that then you will end up turning the String into a byte array twice,
which is very expensive for large payloads (of course you could just
send the resulting byte array).

Stuart

>
> On Wed, Feb 8, 2017 at 10:41 AM Hicks, Matt <matt at matthicks.com> wrote:
>>
>> Well, I just added an IoCallback and now I'm getting an error: Attempted
>> to write 144780 bytes however content-length has been set to 144772
>>
>> This, I think, raises both a question and an issue:
>>
>> Question: Should I not be setting the Content-Length myself even when
>> using exchange.getResponseSender().send?
>> Issue: Seems like a bug that without an IoCallback the error is just
>> absorbed and never logged anywhere.
>>
>> On Wed, Feb 8, 2017 at 10:35 AM Hicks, Matt <matt at matthicks.com> wrote:
>>>
>>> I'm having a very strange problem sending a generated HTML file back to
>>> the browser using `exchange.getResponseSender().send(s)`.  It seems to work
>>> fine if the content is a short bit of text like "Hello World", but the
>>> content is 144,772 bytes and if I use Curl to test it I get a 200 OK, but it
>>> says the Content-Length is 0 and no content comes back.  If I set the
>>> content to a short String like I said, then the Content-Length is properly
>>> set and the content comes back like expected.
>>>
>>> Should I not be using `exchange.getResponseSender().send` for large
>>> amounts of text?
>>>
>>> I just updated to 1.4.10.Final hoping that it was a bug that was fixed
>>> since 1.4.8.Final, but it's still happening.
>>>
>>> Any insights would be greatly appreciated.
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From angelo.salvade at gmail.com  Thu Feb  9 12:09:27 2017
From: angelo.salvade at gmail.com (Angelo Salvade)
Date: Thu, 9 Feb 2017 18:09:27 +0100
Subject: [undertow-dev] How to access the http headers in Endpoint.onOpen ?
Message-ID: <CAL9qcdx3NUFjK2M9GJnSCuQ4fw16UsWs6Q5LwSAkKCKX9pgN+Q@mail.gmail.com>

Hi

If I understand the Java API for WebSocket Spec (JSR 356) correctly,
the only way to access the http headers and the http session is by
the parameter 'HandshakeRequest request' of
ServerEndpointConfig.Configurator.modifyHandshake
with the methods HandshakeRequest.getHeaders and
HandshakeRequest.getHttpSession.

>From there, the only way to pass this data to Endpoint.onOpen seems to
be by EndpointConfig.getUserProperties
because 'EndpointConfig config' is a parameter of Endpoint.onOpen.

The problem is, that according to the documentation, EndpointConfig is
shared with all sessions and therefore this won't work.
See also https://java.net/jira/browse/WEBSOCKET_SPEC-218 and
https://java.net/jira/browse/WEBSOCKET_SPEC-235.
However, I did some testing with Undertow and Jetty.

Please have a look at the following test code:

static ServerEndpointConfig.Configurator SERVER_CONFIGURATOR = new
ServerEndpointConfig.Configurator() {
    @Override public <T> T getEndpointInstance(Class<T> endpointClass) {
        return endpointClass.cast(new Endpoint() {
            @Override public void onOpen(Session session,
EndpointConfig config) {
                System.out.printf(
                    "onOpen - config: %s, session: %s%n",

config.getUserProperties().keySet().stream().filter(k ->
k.startsWith("Header")).collect(Collectors.toSet()),

session.getUserProperties().keySet().stream().filter(k ->
k.startsWith("Header")).collect(Collectors.toSet())
                );
            }
            @Override public void onClose(Session session, CloseReason
closeReason) {
            }
            @Override public void onError(Session session, Throwable
throwable) {
            }
        });
    }
    @Override public void modifyHandshake(ServerEndpointConfig sec,
HandshakeRequest request, HandshakeResponse response) {
        sec.getUserProperties().putAll(request.getHeaders());
    }
    @Override public String getNegotiatedSubprotocol(List<String>
supported, List<String> requested) {
        return "";
    }
    @Override public List<Extension>
getNegotiatedExtensions(List<Extension> installed, List<Extension>
requested) {
        return new ArrayList<>();
    }
    @Override public boolean checkOrigin(String originHeaderValue) {
        return true;
    }
};

static void clientConnect(WebSocketContainer container) throws Exception {
    for (String header : Arrays.asList("Header1", "Header2")) {
        container.connectToServer(
            new Endpoint() {
                @Override public void onOpen(Session session,
EndpointConfig config) {
                }
            },
            ClientEndpointConfig.Builder.create().configurator(new
ClientEndpointConfig.Configurator() {
                @Override public void beforeRequest(Map<String,
List<String>> headers) {
                    headers.put(header, Collections.singletonList("foo"));
                }
            }).build(),
            URI.create("ws://localhost:" + PORT + PATH)
        );
        TimeUnit.SECONDS.sleep(1L);
    }
}

You'll find the source code in the attachments and under:
https://github.com/softappeal/yass/blob/master/java/test/ch/softappeal/yass/transport/ws/test/up/UserPropertiesTest.java
https://github.com/softappeal/yass/blob/master/java/test/ch/softappeal/yass/transport/ws/test/up/UndertowUserPropertiesTest.java
https://github.com/softappeal/yass/blob/master/java/test/ch/softappeal/yass/transport/ws/test/up/JettyUserPropertiesTest.java

These are the outputs of the tests:

UndertowUserPropertiesTest (io.undertow:undertow-websockets-jsr:1.4.8.Final)
onOpen - config: [Header1], session: [Header1]
onOpen - config: [Header1, Header2], session: [Header1, Header2]

JettyUserPropertiesTest
(org.eclipse.jetty.websocket:javax-websocket-server-impl:9.4.1.v20170120)
onOpen - config: [Header1], session: [Header1]
onOpen - config: [Header2], session: [Header2]

So the questions are:

Jetty and Undertow seem to copy EndpointConfig.getUserProperties to
Session.getUserProperties.
Is this behaviour guaranteed? Where does it say so in the spec?

Jetty seems to make a new EndpointConfig.getUserProperties for each session.
This seems NOT to be according to the spec.
This behaviour would be THE SOLUTION to my problem.

Undertow seems to share EndpointConfig.getUserProperties over all sessions.
This seems to be according to the spec.
But so it's not possible to pass the headers to Endpoint.onOpen.

So can we say the WebSocket API should behave like Jetty?

Regards,
Angelo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UserPropertiesTest.java
Type: application/octet-stream
Size: 3189 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20170209/fa9bd8d0/attachment-0003.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: UndertowUserPropertiesTest.java
Type: application/octet-stream
Size: 2288 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20170209/fa9bd8d0/attachment-0004.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JettyUserPropertiesTest.java
Type: application/octet-stream
Size: 1468 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/undertow-dev/attachments/20170209/fa9bd8d0/attachment-0005.obj 

From sdouglas at redhat.com  Thu Feb  9 16:55:37 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 10 Feb 2017 08:55:37 +1100
Subject: [undertow-dev] How to access the http headers in
	Endpoint.onOpen ?
In-Reply-To: <CAL9qcdx3NUFjK2M9GJnSCuQ4fw16UsWs6Q5LwSAkKCKX9pgN+Q@mail.gmail.com>
References: <CAL9qcdx3NUFjK2M9GJnSCuQ4fw16UsWs6Q5LwSAkKCKX9pgN+Q@mail.gmail.com>
Message-ID: <CAD+L2cwtpZ8BAWTOvg+kSusRCvoBj7pbA2SjMajbFAVkGnfkxQ@mail.gmail.com>

I think you will need to take this up with the Websocket EG, I think
Undertow follows the spec as it is currently implemented, so I don't
really want to change it.

Stuart

On Fri, Feb 10, 2017 at 4:09 AM, Angelo Salvade
<angelo.salvade at gmail.com> wrote:
> Hi
>
> If I understand the Java API for WebSocket Spec (JSR 356) correctly,
> the only way to access the http headers and the http session is by
> the parameter 'HandshakeRequest request' of
> ServerEndpointConfig.Configurator.modifyHandshake
> with the methods HandshakeRequest.getHeaders and
> HandshakeRequest.getHttpSession.
>
> >From there, the only way to pass this data to Endpoint.onOpen seems to
> be by EndpointConfig.getUserProperties
> because 'EndpointConfig config' is a parameter of Endpoint.onOpen.
>
> The problem is, that according to the documentation, EndpointConfig is
> shared with all sessions and therefore this won't work.
> See also https://java.net/jira/browse/WEBSOCKET_SPEC-218 and
> https://java.net/jira/browse/WEBSOCKET_SPEC-235.
> However, I did some testing with Undertow and Jetty.
>
> Please have a look at the following test code:
>
> static ServerEndpointConfig.Configurator SERVER_CONFIGURATOR = new
> ServerEndpointConfig.Configurator() {
>     @Override public <T> T getEndpointInstance(Class<T> endpointClass) {
>         return endpointClass.cast(new Endpoint() {
>             @Override public void onOpen(Session session,
> EndpointConfig config) {
>                 System.out.printf(
>                     "onOpen - config: %s, session: %s%n",
>
> config.getUserProperties().keySet().stream().filter(k ->
> k.startsWith("Header")).collect(Collectors.toSet()),
>
> session.getUserProperties().keySet().stream().filter(k ->
> k.startsWith("Header")).collect(Collectors.toSet())
>                 );
>             }
>             @Override public void onClose(Session session, CloseReason
> closeReason) {
>             }
>             @Override public void onError(Session session, Throwable
> throwable) {
>             }
>         });
>     }
>     @Override public void modifyHandshake(ServerEndpointConfig sec,
> HandshakeRequest request, HandshakeResponse response) {
>         sec.getUserProperties().putAll(request.getHeaders());
>     }
>     @Override public String getNegotiatedSubprotocol(List<String>
> supported, List<String> requested) {
>         return "";
>     }
>     @Override public List<Extension>
> getNegotiatedExtensions(List<Extension> installed, List<Extension>
> requested) {
>         return new ArrayList<>();
>     }
>     @Override public boolean checkOrigin(String originHeaderValue) {
>         return true;
>     }
> };
>
> static void clientConnect(WebSocketContainer container) throws Exception {
>     for (String header : Arrays.asList("Header1", "Header2")) {
>         container.connectToServer(
>             new Endpoint() {
>                 @Override public void onOpen(Session session,
> EndpointConfig config) {
>                 }
>             },
>             ClientEndpointConfig.Builder.create().configurator(new
> ClientEndpointConfig.Configurator() {
>                 @Override public void beforeRequest(Map<String,
> List<String>> headers) {
>                     headers.put(header, Collections.singletonList("foo"));
>                 }
>             }).build(),
>             URI.create("ws://localhost:" + PORT + PATH)
>         );
>         TimeUnit.SECONDS.sleep(1L);
>     }
> }
>
> You'll find the source code in the attachments and under:
> https://github.com/softappeal/yass/blob/master/java/test/ch/softappeal/yass/transport/ws/test/up/UserPropertiesTest.java
> https://github.com/softappeal/yass/blob/master/java/test/ch/softappeal/yass/transport/ws/test/up/UndertowUserPropertiesTest.java
> https://github.com/softappeal/yass/blob/master/java/test/ch/softappeal/yass/transport/ws/test/up/JettyUserPropertiesTest.java
>
> These are the outputs of the tests:
>
> UndertowUserPropertiesTest (io.undertow:undertow-websockets-jsr:1.4.8.Final)
> onOpen - config: [Header1], session: [Header1]
> onOpen - config: [Header1, Header2], session: [Header1, Header2]
>
> JettyUserPropertiesTest
> (org.eclipse.jetty.websocket:javax-websocket-server-impl:9.4.1.v20170120)
> onOpen - config: [Header1], session: [Header1]
> onOpen - config: [Header2], session: [Header2]
>
> So the questions are:
>
> Jetty and Undertow seem to copy EndpointConfig.getUserProperties to
> Session.getUserProperties.
> Is this behaviour guaranteed? Where does it say so in the spec?
>
> Jetty seems to make a new EndpointConfig.getUserProperties for each session.
> This seems NOT to be according to the spec.
> This behaviour would be THE SOLUTION to my problem.
>
> Undertow seems to share EndpointConfig.getUserProperties over all sessions.
> This seems to be according to the spec.
> But so it's not possible to pass the headers to Endpoint.onOpen.
>
> So can we say the WebSocket API should behave like Jetty?
>
> Regards,
> Angelo
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From angelo.salvade at gmail.com  Fri Feb 10 02:10:01 2017
From: angelo.salvade at gmail.com (Angelo Salvade)
Date: Fri, 10 Feb 2017 08:10:01 +0100
Subject: [undertow-dev] How to access the http headers in
	Endpoint.onOpen ?
In-Reply-To: <CAD+L2cwtpZ8BAWTOvg+kSusRCvoBj7pbA2SjMajbFAVkGnfkxQ@mail.gmail.com>
References: <CAL9qcdx3NUFjK2M9GJnSCuQ4fw16UsWs6Q5LwSAkKCKX9pgN+Q@mail.gmail.com>
	<CAD+L2cwtpZ8BAWTOvg+kSusRCvoBj7pbA2SjMajbFAVkGnfkxQ@mail.gmail.com>
Message-ID: <CAL9qcdxOg_fZyOuxUZUFRdB=UpaFAu0_FO=WSqOs6C7mxnTmjA@mail.gmail.com>

Hi Stuart

Thanks for the answer.

Just to be sure:
Does it mean you agree with my assumption, that according to the spec,
it won't be possible to pass headers safely (due to multi-threading)
to Endpoint.onOpen?

FYI:
I also posted this issue to the mailing list jetty-users.
They are telling Tomcat also seems to implement the Jetty behavior.
This is against the spec but would be a more useful implementation and
it would solve the problem.
Please see http://dev.eclipse.org/mhonarc/lists/jetty-users/msg07615.html

Regards,
Angelo


On Thu, Feb 9, 2017 at 10:55 PM, Stuart Douglas <sdouglas at redhat.com> wrote:
> I think you will need to take this up with the Websocket EG, I think
> Undertow follows the spec as it is currently implemented, so I don't
> really want to change it.
>
> Stuart
>
> On Fri, Feb 10, 2017 at 4:09 AM, Angelo Salvade
> <angelo.salvade at gmail.com> wrote:
>> Hi
>>
>> If I understand the Java API for WebSocket Spec (JSR 356) correctly,
>> the only way to access the http headers and the http session is by
>> the parameter 'HandshakeRequest request' of
>> ServerEndpointConfig.Configurator.modifyHandshake
>> with the methods HandshakeRequest.getHeaders and
>> HandshakeRequest.getHttpSession.
>>
>> >From there, the only way to pass this data to Endpoint.onOpen seems to
>> be by EndpointConfig.getUserProperties
>> because 'EndpointConfig config' is a parameter of Endpoint.onOpen.
>>
>> The problem is, that according to the documentation, EndpointConfig is
>> shared with all sessions and therefore this won't work.
>> See also https://java.net/jira/browse/WEBSOCKET_SPEC-218 and
>> https://java.net/jira/browse/WEBSOCKET_SPEC-235.
>> However, I did some testing with Undertow and Jetty.
>>
>> Please have a look at the following test code:
>>
>> static ServerEndpointConfig.Configurator SERVER_CONFIGURATOR = new
>> ServerEndpointConfig.Configurator() {
>>     @Override public <T> T getEndpointInstance(Class<T> endpointClass) {
>>         return endpointClass.cast(new Endpoint() {
>>             @Override public void onOpen(Session session,
>> EndpointConfig config) {
>>                 System.out.printf(
>>                     "onOpen - config: %s, session: %s%n",
>>
>> config.getUserProperties().keySet().stream().filter(k ->
>> k.startsWith("Header")).collect(Collectors.toSet()),
>>
>> session.getUserProperties().keySet().stream().filter(k ->
>> k.startsWith("Header")).collect(Collectors.toSet())
>>                 );
>>             }
>>             @Override public void onClose(Session session, CloseReason
>> closeReason) {
>>             }
>>             @Override public void onError(Session session, Throwable
>> throwable) {
>>             }
>>         });
>>     }
>>     @Override public void modifyHandshake(ServerEndpointConfig sec,
>> HandshakeRequest request, HandshakeResponse response) {
>>         sec.getUserProperties().putAll(request.getHeaders());
>>     }
>>     @Override public String getNegotiatedSubprotocol(List<String>
>> supported, List<String> requested) {
>>         return "";
>>     }
>>     @Override public List<Extension>
>> getNegotiatedExtensions(List<Extension> installed, List<Extension>
>> requested) {
>>         return new ArrayList<>();
>>     }
>>     @Override public boolean checkOrigin(String originHeaderValue) {
>>         return true;
>>     }
>> };
>>
>> static void clientConnect(WebSocketContainer container) throws Exception {
>>     for (String header : Arrays.asList("Header1", "Header2")) {
>>         container.connectToServer(
>>             new Endpoint() {
>>                 @Override public void onOpen(Session session,
>> EndpointConfig config) {
>>                 }
>>             },
>>             ClientEndpointConfig.Builder.create().configurator(new
>> ClientEndpointConfig.Configurator() {
>>                 @Override public void beforeRequest(Map<String,
>> List<String>> headers) {
>>                     headers.put(header, Collections.singletonList("foo"));
>>                 }
>>             }).build(),
>>             URI.create("ws://localhost:" + PORT + PATH)
>>         );
>>         TimeUnit.SECONDS.sleep(1L);
>>     }
>> }
>>
>> You'll find the source code in the attachments and under:
>> https://github.com/softappeal/yass/blob/master/java/test/ch/softappeal/yass/transport/ws/test/up/UserPropertiesTest.java
>> https://github.com/softappeal/yass/blob/master/java/test/ch/softappeal/yass/transport/ws/test/up/UndertowUserPropertiesTest.java
>> https://github.com/softappeal/yass/blob/master/java/test/ch/softappeal/yass/transport/ws/test/up/JettyUserPropertiesTest.java
>>
>> These are the outputs of the tests:
>>
>> UndertowUserPropertiesTest (io.undertow:undertow-websockets-jsr:1.4.8.Final)
>> onOpen - config: [Header1], session: [Header1]
>> onOpen - config: [Header1, Header2], session: [Header1, Header2]
>>
>> JettyUserPropertiesTest
>> (org.eclipse.jetty.websocket:javax-websocket-server-impl:9.4.1.v20170120)
>> onOpen - config: [Header1], session: [Header1]
>> onOpen - config: [Header2], session: [Header2]
>>
>> So the questions are:
>>
>> Jetty and Undertow seem to copy EndpointConfig.getUserProperties to
>> Session.getUserProperties.
>> Is this behaviour guaranteed? Where does it say so in the spec?
>>
>> Jetty seems to make a new EndpointConfig.getUserProperties for each session.
>> This seems NOT to be according to the spec.
>> This behaviour would be THE SOLUTION to my problem.
>>
>> Undertow seems to share EndpointConfig.getUserProperties over all sessions.
>> This seems to be according to the spec.
>> But so it's not possible to pass the headers to Endpoint.onOpen.
>>
>> So can we say the WebSocket API should behave like Jetty?
>>
>> Regards,
>> Angelo
>>
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev

From mario.e.carbajal at gmail.com  Fri Feb 10 10:04:25 2017
From: mario.e.carbajal at gmail.com (Mario Carbajal)
Date: Fri, 10 Feb 2017 12:04:25 -0300
Subject: [undertow-dev] WebSocketChannel getPeerConnections() unnecesary
	cost?
Message-ID: <CAPKf56q3ZHoTk6d8192c8X9R3kUgNn1m2hkTzQC7h=x4vty+Yw@mail.gmail.com>

Undertow websockets mantain a peer connections set
per WebSocketProtocolHandshakeHandler instance. From the looks of it, it's
there only for undertow users convinience.

The application I'm building doesn't make use of the peer connections set
at all and it feels kinda bad to have to pay for the feature despite not
using it.

It would be great if there was a way to disable this functionality. Perhaps
with an overload of the WebSocketProtocolHandshakeHandler constructor that
initializes that set to null. (and adding null checks whenever the set is
used.)
Or maybe some global undertow setting?

This kind of functionality could be provided optionally as a convinience
abstract class that implements WebSocketConnectionCallback and maintains
the set, exposing it to the users by an overrideable overload of the
onConnect method.
Users that want the functionality could inherit from it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170210/9d3a227c/attachment.html 

From stevehu at gmail.com  Sun Feb 12 08:10:48 2017
From: stevehu at gmail.com (Steve Hu)
Date: Sun, 12 Feb 2017 08:10:48 -0500
Subject: [undertow-dev] java.lang.OutOfMemoryError: Direct buffer memory
Message-ID: <CAGjN9KV7R-GHzGxoP41DtF0cqeqCzUWETWSnMeXPs98WdqOpcA@mail.gmail.com>

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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170212/e5cd4aa2/attachment-0001.html 

From kr at asseco.dk  Sun Feb 12 15:15:46 2017
From: kr at asseco.dk (Kim Rasmussen)
Date: Sun, 12 Feb 2017 21:15:46 +0100
Subject: [undertow-dev] OpenSSL
Message-ID: <CAGX6Y=0GqV6Xf7QhUmzVjv2XxhypR+bocjh_cU0YX_pLKz8Osg@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170212/ed76b5d0/attachment.html 

From sdouglas at redhat.com  Sun Feb 12 18:02:47 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 13 Feb 2017 10:02:47 +1100
Subject: [undertow-dev] java.lang.OutOfMemoryError: Direct buffer memory
In-Reply-To: <CAGjN9KV7R-GHzGxoP41DtF0cqeqCzUWETWSnMeXPs98WdqOpcA@mail.gmail.com>
References: <CAGjN9KV7R-GHzGxoP41DtF0cqeqCzUWETWSnMeXPs98WdqOpcA@mail.gmail.com>
Message-ID: <CAD+L2czT0JCbP6XHjGZygrLp5dzBUjFDM-RcfxXNb4Hb6JL4fQ@mail.gmail.com>

I just had a quick look and I don't seem to be able to reproduce this.

What memory settings are you using? If you increase the available
memory does the problem go away (i.e. is it a leak or is there just
not enough direct buffer space to meet the servers needs)?

One of the changes is that buffers in 1.4.x are allocated in an
individual basis, rather than a large buffer being allocated and then
sliced. This does make initial allocation into the pool slightly more
expensive, however it means that if an application accidentally leaks
a buffer the garbage collector can take care of it. Its possible this
change in allocation behavior may be behind it if memory is
constrained.

Stuart

On Mon, Feb 13, 2017 at 12:10 AM, Steve Hu <stevehu at gmail.com> wrote:
> 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)
>
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From sdouglas at redhat.com  Sun Feb 12 21:41:44 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 13 Feb 2017 13:41:44 +1100
Subject: [undertow-dev] OpenSSL
In-Reply-To: <CAGX6Y=0GqV6Xf7QhUmzVjv2XxhypR+bocjh_cU0YX_pLKz8Osg@mail.gmail.com>
References: <CAGX6Y=0GqV6Xf7QhUmzVjv2XxhypR+bocjh_cU0YX_pLKz8Osg@mail.gmail.com>
Message-ID: <CAD+L2czC4JMT3WbQ0V0K03rsxYdJ8gyLqxd_YcH31h1xC0UwOw@mail.gmail.com>

Looks like a bug came in with a recent refactor. I just pushed a fix
upstream if you want to try it.

One thing that is still not working is client cert renegotiation. I am
still working on it, but OpenSSL does not seem to be requesting the
client certificate when renegotiating, so you need to ask for the
client ceritificate in the initial handshake.

Stuart

On Mon, Feb 13, 2017 at 7:15 AM, Kim Rasmussen <kr at asseco.dk> wrote:
> 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
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From kr at asseco.dk  Mon Feb 13 01:26:02 2017
From: kr at asseco.dk (Kim Rasmussen)
Date: Mon, 13 Feb 2017 07:26:02 +0100
Subject: [undertow-dev] OpenSSL
In-Reply-To: <CAD+L2czC4JMT3WbQ0V0K03rsxYdJ8gyLqxd_YcH31h1xC0UwOw@mail.gmail.com>
References: <CAGX6Y=0GqV6Xf7QhUmzVjv2XxhypR+bocjh_cU0YX_pLKz8Osg@mail.gmail.com>
	<CAD+L2czC4JMT3WbQ0V0K03rsxYdJ8gyLqxd_YcH31h1xC0UwOw@mail.gmail.com>
Message-ID: <CAGX6Y=08-uadXnEnArcyTtmnrezRaix2+mJ5qAFom2BQoxHtDA@mail.gmail.com>

Awesome thanks.
Is there a snapshot repository available somewhere if I prefer to avoid
doing the native builds ?

No worries regarding renegotiating the client certificate - I have always
found that the only truly reliable way of asking for client cert, is to set
"need/wantClientAuth" to true at the start - that gives fewest problems
with various clients.
It is in my opinion only in the last few years that wantClientAuth have
started to work reliably with the browsers without various side-effects in
the client GUI.

Great work again, thanks
/Kim

2017-02-13 3:41 GMT+01:00 Stuart Douglas <sdouglas at redhat.com>:

> Looks like a bug came in with a recent refactor. I just pushed a fix
> upstream if you want to try it.
>
> One thing that is still not working is client cert renegotiation. I am
> still working on it, but OpenSSL does not seem to be requesting the
> client certificate when renegotiating, so you need to ask for the
> client ceritificate in the initial handshake.
>
> Stuart
>
> On Mon, Feb 13, 2017 at 7:15 AM, Kim Rasmussen <kr at asseco.dk> wrote:
> > 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
> >
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>



-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170213/ce614af5/attachment.html 

From rohan.emmanuel07 at gmail.com  Wed Feb 15 05:34:31 2017
From: rohan.emmanuel07 at gmail.com (Rohan Emmanuel)
Date: Wed, 15 Feb 2017 16:04:31 +0530
Subject: [undertow-dev] Undertow servlet context
Message-ID: <CALCKA0oLcrarsSVvmp1c0eLir=jdjPYkr7Uo_JzBMMD3Xgpxvg@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170215/44c8d3c4/attachment-0001.html 

From rohan.294435294435 at gmail.com  Wed Feb 15 05:36:16 2017
From: rohan.294435294435 at gmail.com (Rohan Emmanuel)
Date: Wed, 15 Feb 2017 16:06:16 +0530
Subject: [undertow-dev] Undertow servlet context
Message-ID: <CALCKA0pWuRxA8PkKXAnNBMhwk55amBHE2xrZmGfxLGXzSgiWKw@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170215/ddcf9094/attachment.html 

From karm at redhat.com  Wed Feb 15 12:19:10 2017
From: karm at redhat.com (Karm Michal Babacek)
Date: Wed, 15 Feb 2017 12:19:10 -0500 (EST)
Subject: [undertow-dev] OpenSSL
In-Reply-To: <CAGX6Y=08-uadXnEnArcyTtmnrezRaix2+mJ5qAFom2BQoxHtDA@mail.gmail.com>
References: <CAGX6Y=0GqV6Xf7QhUmzVjv2XxhypR+bocjh_cU0YX_pLKz8Osg@mail.gmail.com>
	<CAD+L2czC4JMT3WbQ0V0K03rsxYdJ8gyLqxd_YcH31h1xC0UwOw@mail.gmail.com>
	<CAGX6Y=08-uadXnEnArcyTtmnrezRaix2+mJ5qAFom2BQoxHtDA@mail.gmail.com>
Message-ID: <636522070.5240552.1487179150893.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Kim Rasmussen" <kr at asseco.dk>
> To: "Stuart Douglas" <sdouglas at redhat.com>
> Cc: "Undertow Developers" <undertow-dev at lists.jboss.org>
> Sent: Monday, February 13, 2017 7:26:02 AM
> Subject: Re: [undertow-dev] OpenSSL
> 
> Awesome thanks.
> Is there a snapshot repository available somewhere if I prefer to avoid
> doing the native builds ?
> 

Best regards from mod_cluster community :-)

wildfly-openssl https://ci.modcluster.io/job/wildfly-openssl-windows/2/

openssl 1.0.2h https://ci.modcluster.io/job/openssl-windows/

Have fun

-K-


> No worries regarding renegotiating the client certificate - I have always
> found that the only truly reliable way of asking for client cert, is to set
> "need/wantClientAuth" to true at the start - that gives fewest problems
> with various clients.
> It is in my opinion only in the last few years that wantClientAuth have
> started to work reliably with the browsers without various side-effects in
> the client GUI.
> 
> Great work again, thanks
> /Kim
> 
> 2017-02-13 3:41 GMT+01:00 Stuart Douglas <sdouglas at redhat.com>:
> 
> > Looks like a bug came in with a recent refactor. I just pushed a fix
> > upstream if you want to try it.
> >
> > One thing that is still not working is client cert renegotiation. I am
> > still working on it, but OpenSSL does not seem to be requesting the
> > client certificate when renegotiating, so you need to ask for the
> > client ceritificate in the initial handshake.
> >
> > Stuart
> >
> > On Mon, Feb 13, 2017 at 7:15 AM, Kim Rasmussen <kr at asseco.dk> wrote:
> > > 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
> > >
> > >
> > > _______________________________________________
> > > undertow-dev mailing list
> > > undertow-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/undertow-dev
> >
> 
> 
> 
> --
> 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
> 
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

-- 
Sent from my Hosaka Ono-Sendai Cyberspace 7

--
Michal Karm Babacek
    ? JBoss QE    
Red Hat Czech | GMT+1

? +420 737 778 560 (cell)
? +420 532 294 547 (?forwarded?)
freenode: #wildfly #mod_cluster #fedora-devel
? http://modcluster.io ? karm at redhat.com


From sdouglas at redhat.com  Wed Feb 15 18:18:53 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Thu, 16 Feb 2017 10:18:53 +1100
Subject: [undertow-dev] Undertow servlet context
In-Reply-To: <CALCKA0oLcrarsSVvmp1c0eLir=jdjPYkr7Uo_JzBMMD3Xgpxvg@mail.gmail.com>
References: <CALCKA0oLcrarsSVvmp1c0eLir=jdjPYkr7Uo_JzBMMD3Xgpxvg@mail.gmail.com>
Message-ID: <CAD+L2cxrVWdMrHFS0ach9fRERRotQKLy-kgJO67UpQ9JYxnnQQ@mail.gmail.com>

Where is your handler running? It sounds like it is running outside
the ServletInitialHandler, which is what sets the attachment key.

If that is the case you can either move the handler to be run after
the ServletInitialHandler, or save the ServletContext somewhere
static.

Stuart

On Wed, Feb 15, 2017 at 9:34 PM, Rohan Emmanuel
<rohan.emmanuel07 at gmail.com> wrote:
> 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
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From rohan.emmanuel07 at gmail.com  Thu Feb 16 01:04:47 2017
From: rohan.emmanuel07 at gmail.com (Rohan Emmanuel)
Date: Thu, 16 Feb 2017 11:34:47 +0530
Subject: [undertow-dev] Undertow servlet context
In-Reply-To: <CAD+L2cxrVWdMrHFS0ach9fRERRotQKLy-kgJO67UpQ9JYxnnQQ@mail.gmail.com>
References: <CALCKA0oLcrarsSVvmp1c0eLir=jdjPYkr7Uo_JzBMMD3Xgpxvg@mail.gmail.com>
	<CAD+L2cxrVWdMrHFS0ach9fRERRotQKLy-kgJO67UpQ9JYxnnQQ@mail.gmail.com>
Message-ID: <CALCKA0rLDsUd7YSXC3J8KowyiMRyK+F9WO_9A+70Mn4H=XLnjw@mail.gmail.com>

Thanks for your reply Stuart,
i have the handler "HAHandler" configured as filter in the undertow
subsystem of wildfly.
I also have eager filter initialization on filter enabled.And the Filter
init() method is getting called while application deployment and it had set
the servletContext.


  <filters>
                    <response-header name="server-header"
header-name="Server" header-value="WildFly/10"/>
                    <response-header name="x-powered-by-header"
header-name="X-Powered-By" header-value="Undertow/1"/>
                    <error-page name="500Handler"
path="${jboss.home.dir}/welcome-content/ErrorPage.html" code="506"/>
                    <error-page name="404Handler"
path="${jboss.home.dir}/welcome-content/ErrorPage.html" code="404"/>
                    <filter name="HAHandler" module="com.haHandler"
class-name="com.HAHandler"/>
                </filters>


You were correct, by adding some logs,  the sevletInitalHandler hadn't
added the attachment when my handler was called.
any suggestions how to move my handler in the chain after a specific
handler (ServletInitailHandler)?

On Thu, Feb 16, 2017 at 4:48 AM, Stuart Douglas <sdouglas at redhat.com> wrote:

> Where is your handler running? It sounds like it is running outside
> the ServletInitialHandler, which is what sets the attachment key.
>
> If that is the case you can either move the handler to be run after
> the ServletInitialHandler, or save the ServletContext somewhere
> static.
>
> Stuart
>
> On Wed, Feb 15, 2017 at 9:34 PM, Rohan Emmanuel
> <rohan.emmanuel07 at gmail.com> wrote:
> > 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
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>



-- 
Regards,
Rohan Emmanuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170216/1d9cd5ef/attachment.html 

From espina.edgar at gmail.com  Thu Feb 16 07:52:40 2017
From: espina.edgar at gmail.com (Edgar Espina)
Date: Thu, 16 Feb 2017 12:52:40 +0000
Subject: [undertow-dev] SSL error: java.lang.NoSuchFieldError: DEFAULT
Message-ID: <CAGWJpGYCBpyLaCs46PC9a3v0VaXEcthecr2oRWe2fV+Fi9ecVQ@mail.gmail.com>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170216/3512818d/attachment-0001.html 

From sdouglas at redhat.com  Thu Feb 16 15:06:43 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 17 Feb 2017 07:06:43 +1100
Subject: [undertow-dev] SSL error: java.lang.NoSuchFieldError: DEFAULT
In-Reply-To: <CAGWJpGYCBpyLaCs46PC9a3v0VaXEcthecr2oRWe2fV+Fi9ecVQ@mail.gmail.com>
References: <CAGWJpGYCBpyLaCs46PC9a3v0VaXEcthecr2oRWe2fV+Fi9ecVQ@mail.gmail.com>
Message-ID: <CAD+L2cw8fN2xyC+1VobiD=8HVnRtvjCzqg0kdkgJFFZc0KhCjQ@mail.gmail.com>

Are you using Jetty ALPN?

Stuart

On Thu, Feb 16, 2017 at 11:52 PM, Edgar Espina <espina.edgar at gmail.com> wrote:
> 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.
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From sdouglas at redhat.com  Thu Feb 16 15:09:05 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 17 Feb 2017 07:09:05 +1100
Subject: [undertow-dev] Undertow servlet context
In-Reply-To: <CALCKA0rLDsUd7YSXC3J8KowyiMRyK+F9WO_9A+70Mn4H=XLnjw@mail.gmail.com>
References: <CALCKA0oLcrarsSVvmp1c0eLir=jdjPYkr7Uo_JzBMMD3Xgpxvg@mail.gmail.com>
	<CAD+L2cxrVWdMrHFS0ach9fRERRotQKLy-kgJO67UpQ9JYxnnQQ@mail.gmail.com>
	<CALCKA0rLDsUd7YSXC3J8KowyiMRyK+F9WO_9A+70Mn4H=XLnjw@mail.gmail.com>
Message-ID: <CAD+L2cwHDpZ55dM13od+sVsbYe=BL3SMDEq+yFy-zn6juiSXCQ@mail.gmail.com>

If you add it via a ServletExtension you can control where it is
executed. io.undertow.servlet.api.DeploymentInfo#addOuterHandlerChainWrapper
will allow you to add it so that it is run after the servlet initial
handler, but before any other handlers.

Stuart

On Thu, Feb 16, 2017 at 5:04 PM, Rohan Emmanuel
<rohan.emmanuel07 at gmail.com> wrote:
> Thanks for your reply Stuart,
> i have the handler "HAHandler" configured as filter in the undertow
> subsystem of wildfly.
> I also have eager filter initialization on filter enabled.And the Filter
> init() method is getting called while application deployment and it had set
> the servletContext.
>
>
>   <filters>
>                     <response-header name="server-header"
> header-name="Server" header-value="WildFly/10"/>
>                     <response-header name="x-powered-by-header"
> header-name="X-Powered-By" header-value="Undertow/1"/>
>                     <error-page name="500Handler"
> path="${jboss.home.dir}/welcome-content/ErrorPage.html" code="506"/>
>                     <error-page name="404Handler"
> path="${jboss.home.dir}/welcome-content/ErrorPage.html" code="404"/>
>                     <filter name="HAHandler" module="com.haHandler"
> class-name="com.HAHandler"/>
>                 </filters>
>
>
> You were correct, by adding some logs,  the sevletInitalHandler hadn't added
> the attachment when my handler was called.
> any suggestions how to move my handler in the chain after a specific handler
> (ServletInitailHandler)?
>
> On Thu, Feb 16, 2017 at 4:48 AM, Stuart Douglas <sdouglas at redhat.com> wrote:
>>
>> Where is your handler running? It sounds like it is running outside
>> the ServletInitialHandler, which is what sets the attachment key.
>>
>> If that is the case you can either move the handler to be run after
>> the ServletInitialHandler, or save the ServletContext somewhere
>> static.
>>
>> Stuart
>>
>> On Wed, Feb 15, 2017 at 9:34 PM, Rohan Emmanuel
>> <rohan.emmanuel07 at gmail.com> wrote:
>> > 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
>> >
>> > _______________________________________________
>> > undertow-dev mailing list
>> > undertow-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>
>
>
> --
> Regards,
> Rohan Emmanuel

From espina.edgar at gmail.com  Thu Feb 16 15:33:26 2017
From: espina.edgar at gmail.com (Edgar Espina)
Date: Thu, 16 Feb 2017 20:33:26 +0000
Subject: [undertow-dev] SSL error: java.lang.NoSuchFieldError: DEFAULT
In-Reply-To: <CAD+L2cw8fN2xyC+1VobiD=8HVnRtvjCzqg0kdkgJFFZc0KhCjQ@mail.gmail.com>
References: <CAGWJpGYCBpyLaCs46PC9a3v0VaXEcthecr2oRWe2fV+Fi9ecVQ@mail.gmail.com>
	<CAD+L2cw8fN2xyC+1VobiD=8HVnRtvjCzqg0kdkgJFFZc0KhCjQ@mail.gmail.com>
Message-ID: <CAGWJpGbrN6ZCZNego+g61xv_fJYZWn-M9A8iJeLBvvk=s5a1Rw@mail.gmail.com>

I thought Undertow used the Jdk8 SSL Hack but yes the Jetty ALPN jar is in
the boot classpath.

I need ALPN to run integration tests. Those integration tests run against
undertow, netty and jetty.

Local tests work perfectly on OSX, but not in Travis CI (ubuntu).

Do you think this is an alpn issue?

Thanks.

On Thu, Feb 16, 2017 at 5:06 PM Stuart Douglas <sdouglas at redhat.com> wrote:

> Are you using Jetty ALPN?
>
> Stuart
>
> On Thu, Feb 16, 2017 at 11:52 PM, Edgar Espina <espina.edgar at gmail.com>
> wrote:
> > 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.
> >
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170216/65cfebba/attachment.html 

From sdouglas at redhat.com  Thu Feb 16 15:41:46 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Fri, 17 Feb 2017 07:41:46 +1100
Subject: [undertow-dev] SSL error: java.lang.NoSuchFieldError: DEFAULT
In-Reply-To: <CAGWJpGbrN6ZCZNego+g61xv_fJYZWn-M9A8iJeLBvvk=s5a1Rw@mail.gmail.com>
References: <CAGWJpGYCBpyLaCs46PC9a3v0VaXEcthecr2oRWe2fV+Fi9ecVQ@mail.gmail.com>
	<CAD+L2cw8fN2xyC+1VobiD=8HVnRtvjCzqg0kdkgJFFZc0KhCjQ@mail.gmail.com>
	<CAGWJpGbrN6ZCZNego+g61xv_fJYZWn-M9A8iJeLBvvk=s5a1Rw@mail.gmail.com>
Message-ID: <CAD+L2cxrbAV3i+qJUOeX4h-aLVqX0KtWDPnJaKeB6PuoPC44qw@mail.gmail.com>

Undertow can use the Jetty provider, but it will use its own built in
approach by default. A big problem with the Jetty provider is that you
need to use the correct version for the version of the JDK you are
using. If the version is incorrect you will get errors like you are
seeing.

Stuart

On Fri, Feb 17, 2017 at 7:33 AM, Edgar Espina <espina.edgar at gmail.com> wrote:
> I thought Undertow used the Jdk8 SSL Hack but yes the Jetty ALPN jar is in
> the boot classpath.
>
> I need ALPN to run integration tests. Those integration tests run against
> undertow, netty and jetty.
>
> Local tests work perfectly on OSX, but not in Travis CI (ubuntu).
>
> Do you think this is an alpn issue?
>
> Thanks.
>
> On Thu, Feb 16, 2017 at 5:06 PM Stuart Douglas <sdouglas at redhat.com> wrote:
>>
>> Are you using Jetty ALPN?
>>
>> Stuart
>>
>> On Thu, Feb 16, 2017 at 11:52 PM, Edgar Espina <espina.edgar at gmail.com>
>> wrote:
>> > 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.
>> >
>> >
>> > _______________________________________________
>> > undertow-dev mailing list
>> > undertow-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/undertow-dev

From karm at redhat.com  Fri Feb 17 05:57:59 2017
From: karm at redhat.com (Karm Michal Babacek)
Date: Fri, 17 Feb 2017 05:57:59 -0500 (EST)
Subject: [undertow-dev] SSL error: java.lang.NoSuchFieldError: DEFAULT
In-Reply-To: <CAD+L2cxrbAV3i+qJUOeX4h-aLVqX0KtWDPnJaKeB6PuoPC44qw@mail.gmail.com>
References: <CAGWJpGYCBpyLaCs46PC9a3v0VaXEcthecr2oRWe2fV+Fi9ecVQ@mail.gmail.com>
	<CAD+L2cw8fN2xyC+1VobiD=8HVnRtvjCzqg0kdkgJFFZc0KhCjQ@mail.gmail.com>
	<CAGWJpGbrN6ZCZNego+g61xv_fJYZWn-M9A8iJeLBvvk=s5a1Rw@mail.gmail.com>
	<CAD+L2cxrbAV3i+qJUOeX4h-aLVqX0KtWDPnJaKeB6PuoPC44qw@mail.gmail.com>
Message-ID: <1329498721.6560824.1487329079445.JavaMail.zimbra@redhat.com>

----- Original Message -----
> From: "Stuart Douglas" <sdouglas at redhat.com>
> To: "Edgar Espina" <espina.edgar at gmail.com>
> Cc: undertow-dev at lists.jboss.org
> Sent: Thursday, February 16, 2017 9:41:46 PM
> Subject: Re: [undertow-dev] SSL error: java.lang.NoSuchFieldError: DEFAULT
> 
> Undertow can use the Jetty provider, but it will use its own built in
> approach by default. A big problem with the Jetty provider is that you
> need to use the correct version for the version of the JDK you are

I have some systems that need ALPN Jetty hack to run
tests using OKHttp client. I have this in my pom's surefire:

https://gist.github.com/Karm/ec00f490b7318a62be76bc6120f052a6

and then this nasty groovy oneliner determines which version to use
with the particular JDK before Maven is started:

https://gist.github.com/Karm/b1f89653966a10349d9d89e7d0c33472

HTH
K.

> using. If the version is incorrect you will get errors like you are
> seeing.
> 
> Stuart
> 
> On Fri, Feb 17, 2017 at 7:33 AM, Edgar Espina <espina.edgar at gmail.com> wrote:
> > I thought Undertow used the Jdk8 SSL Hack but yes the Jetty ALPN jar is in
> > the boot classpath.
> >
> > I need ALPN to run integration tests. Those integration tests run against
> > undertow, netty and jetty.
> >
> > Local tests work perfectly on OSX, but not in Travis CI (ubuntu).
> >
> > Do you think this is an alpn issue?
> >
> > Thanks.
> >
> > On Thu, Feb 16, 2017 at 5:06 PM Stuart Douglas <sdouglas at redhat.com> wrote:
> >>
> >> Are you using Jetty ALPN?
> >>
> >> Stuart
> >>
> >> On Thu, Feb 16, 2017 at 11:52 PM, Edgar Espina <espina.edgar at gmail.com>
> >> wrote:
> >> > 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.
> >> >
> >> >
> >> > _______________________________________________
> >> > undertow-dev mailing list
> >> > undertow-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
> 

-- 
Sent from my Hosaka Ono-Sendai Cyberspace 7

--
Michal Karm Babacek
    ? JBoss QE    
Red Hat Czech | GMT+1

? +420 737 778 560 (cell)
? +420 532 294 547 (?forwarded?)
freenode: #wildfly #mod_cluster #fedora-devel
? http://modcluster.io ? karm at redhat.com


From espina.edgar at gmail.com  Mon Feb 20 08:11:17 2017
From: espina.edgar at gmail.com (Edgar Espina)
Date: Mon, 20 Feb 2017 13:11:17 +0000
Subject: [undertow-dev] SSL error: java.lang.NoSuchFieldError: DEFAULT
In-Reply-To: <1329498721.6560824.1487329079445.JavaMail.zimbra@redhat.com>
References: <CAGWJpGYCBpyLaCs46PC9a3v0VaXEcthecr2oRWe2fV+Fi9ecVQ@mail.gmail.com>
	<CAD+L2cw8fN2xyC+1VobiD=8HVnRtvjCzqg0kdkgJFFZc0KhCjQ@mail.gmail.com>
	<CAGWJpGbrN6ZCZNego+g61xv_fJYZWn-M9A8iJeLBvvk=s5a1Rw@mail.gmail.com>
	<CAD+L2cxrbAV3i+qJUOeX4h-aLVqX0KtWDPnJaKeB6PuoPC44qw@mail.gmail.com>
	<1329498721.6560824.1487329079445.JavaMail.zimbra@redhat.com>
Message-ID: <CAGWJpGaXrR412ugD8-KrEZuBDXmd4i4MeTGkLgwveSmDs9YQWw@mail.gmail.com>

Your groovy script is really helpful.

Thank you.

On Fri, Feb 17, 2017 at 7:57 AM Karm Michal Babacek <karm at redhat.com> wrote:

> ----- Original Message -----
> > From: "Stuart Douglas" <sdouglas at redhat.com>
> > To: "Edgar Espina" <espina.edgar at gmail.com>
> > Cc: undertow-dev at lists.jboss.org
> > Sent: Thursday, February 16, 2017 9:41:46 PM
> > Subject: Re: [undertow-dev] SSL error: java.lang.NoSuchFieldError:
> DEFAULT
> >
> > Undertow can use the Jetty provider, but it will use its own built in
> > approach by default. A big problem with the Jetty provider is that you
> > need to use the correct version for the version of the JDK you are
>
> I have some systems that need ALPN Jetty hack to run
> tests using OKHttp client. I have this in my pom's surefire:
>
> https://gist.github.com/Karm/ec00f490b7318a62be76bc6120f052a6
>
> and then this nasty groovy oneliner determines which version to use
> with the particular JDK before Maven is started:
>
> https://gist.github.com/Karm/b1f89653966a10349d9d89e7d0c33472
>
> HTH
> K.
>
> > using. If the version is incorrect you will get errors like you are
> > seeing.
> >
> > Stuart
> >
> > On Fri, Feb 17, 2017 at 7:33 AM, Edgar Espina <espina.edgar at gmail.com>
> wrote:
> > > I thought Undertow used the Jdk8 SSL Hack but yes the Jetty ALPN jar
> is in
> > > the boot classpath.
> > >
> > > I need ALPN to run integration tests. Those integration tests run
> against
> > > undertow, netty and jetty.
> > >
> > > Local tests work perfectly on OSX, but not in Travis CI (ubuntu).
> > >
> > > Do you think this is an alpn issue?
> > >
> > > Thanks.
> > >
> > > On Thu, Feb 16, 2017 at 5:06 PM Stuart Douglas <sdouglas at redhat.com>
> wrote:
> > >>
> > >> Are you using Jetty ALPN?
> > >>
> > >> Stuart
> > >>
> > >> On Thu, Feb 16, 2017 at 11:52 PM, Edgar Espina <
> espina.edgar at gmail.com>
> > >> wrote:
> > >> > 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.
> > >> >
> > >> >
> > >> > _______________________________________________
> > >> > undertow-dev mailing list
> > >> > undertow-dev at lists.jboss.org
> > >> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> >
>
> --
> Sent from my Hosaka Ono-Sendai Cyberspace 7
>
> --
> Michal Karm Babacek
>     ? JBoss QE
> Red Hat Czech | GMT+1
>
> ? +420 737 778 560 <+420%20737%20778%20560> (cell)
> ? +420 532 294 547 <+420%20532%20294%20547> (?forwarded?)
> freenode: #wildfly #mod_cluster #fedora-devel
> ? http://modcluster.io ? karm at redhat.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170220/1de1b0f5/attachment-0001.html 

From rohan.emmanuel07 at gmail.com  Wed Feb 22 01:35:37 2017
From: rohan.emmanuel07 at gmail.com (Rohan Emmanuel)
Date: Wed, 22 Feb 2017 12:05:37 +0530
Subject: [undertow-dev] The reason for removing reference to exchange object
	in HttpResponseConduit
Message-ID: <CALCKA0ozCFvHFW3=MKVZ4cQMMMuBUX3vN_rckpbGxJooUVA3TQ@mail.gmail.com>

As part of the below commit, i see that the reference to exchange object is
removed after a call to processWrite which will generate the headers.

https://github.com/undertow-io/undertow/commit/d0151d67a88bc34f61895bc6d131a0dbc95243c5

 When this is done, there could be still data which has to be written. Can
you please help me understand why this reference to exchange is being made
explicitly made to null?



-- 
Regards,
Rohan Emmanuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170222/059e57f9/attachment.html 

From rohan.emmanuel07 at gmail.com  Fri Feb 24 01:31:28 2017
From: rohan.emmanuel07 at gmail.com (Rohan Emmanuel)
Date: Fri, 24 Feb 2017 12:01:28 +0530
Subject: [undertow-dev] Tracing HTTP Response content
Message-ID: <CALCKA0oUj0entvpKDpeds66U88Wc3z9bAg_21f_+001vF-UDOA@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170224/5ddd683a/attachment.html 

From matt at matthicks.com  Fri Feb 24 17:14:20 2017
From: matt at matthicks.com (Hicks, Matt)
Date: Fri, 24 Feb 2017 22:14:20 +0000
Subject: [undertow-dev] FormParserFactory getting stuck
Message-ID: <CAFeDf1-b+uC-zeAO9f5h96P+TO8Td=CPGhka6gYU6hYQfQ_Vsg@mail.gmail.com>

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170224/6eb66b55/attachment.html 

From sdouglas at redhat.com  Fri Feb 24 18:10:22 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Sat, 25 Feb 2017 10:10:22 +1100
Subject: [undertow-dev] FormParserFactory getting stuck
In-Reply-To: <CAFeDf1-b+uC-zeAO9f5h96P+TO8Td=CPGhka6gYU6hYQfQ_Vsg@mail.gmail.com>
References: <CAFeDf1-b+uC-zeAO9f5h96P+TO8Td=CPGhka6gYU6hYQfQ_Vsg@mail.gmail.com>
Message-ID: <CAD+L2cxZ50ofYx1eoxvQeqpqTs8Ke+fcSQAYxEoxCfqZQasCpA@mail.gmail.com>

- What version of Undertow?
- Is SSL in use?
- Does the server enter some kind of spin loop (i.e. 100% CPU usage)?
- What does the stack trace look like when this happens?

Stuart

On Sat, Feb 25, 2017 at 9:14 AM, Hicks, Matt <matt at matthicks.com> wrote:
> 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?
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From matt at matthicks.com  Fri Feb 24 18:15:15 2017
From: matt at matthicks.com (Hicks, Matt)
Date: Fri, 24 Feb 2017 23:15:15 +0000
Subject: [undertow-dev] FormParserFactory getting stuck
In-Reply-To: <CAD+L2cxZ50ofYx1eoxvQeqpqTs8Ke+fcSQAYxEoxCfqZQasCpA@mail.gmail.com>
References: <CAFeDf1-b+uC-zeAO9f5h96P+TO8Td=CPGhka6gYU6hYQfQ_Vsg@mail.gmail.com>
	<CAD+L2cxZ50ofYx1eoxvQeqpqTs8Ke+fcSQAYxEoxCfqZQasCpA@mail.gmail.com>
Message-ID: <CAFeDf1_=tmemc6sJWVR5+2rO7Zcv1163-L8idCLf2uq4E2JWVw@mail.gmail.com>

1.) I was running 1.4.10.Final, but I upgraded to 1.4.11.Final hoping it
was a bug that was fixed, but it didn't make any difference.
2.) Yes
3.) No, of the 8 virtual CPUs none of them are maxed out.
4.) I'll have to get back to you...

On Fri, Feb 24, 2017 at 5:10 PM Stuart Douglas <sdouglas at redhat.com> wrote:

> - What version of Undertow?
> - Is SSL in use?
> - Does the server enter some kind of spin loop (i.e. 100% CPU usage)?
> - What does the stack trace look like when this happens?
>
> Stuart
>
> On Sat, Feb 25, 2017 at 9:14 AM, Hicks, Matt <matt at matthicks.com> wrote:
> > 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?
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170224/46daeb6f/attachment.html 

From matt at matthicks.com  Fri Feb 24 18:18:30 2017
From: matt at matthicks.com (Hicks, Matt)
Date: Fri, 24 Feb 2017 23:18:30 +0000
Subject: [undertow-dev] FormParserFactory getting stuck
In-Reply-To: <CAFeDf1_=tmemc6sJWVR5+2rO7Zcv1163-L8idCLf2uq4E2JWVw@mail.gmail.com>
References: <CAFeDf1-b+uC-zeAO9f5h96P+TO8Td=CPGhka6gYU6hYQfQ_Vsg@mail.gmail.com>
	<CAD+L2cxZ50ofYx1eoxvQeqpqTs8Ke+fcSQAYxEoxCfqZQasCpA@mail.gmail.com>
	<CAFeDf1_=tmemc6sJWVR5+2rO7Zcv1163-L8idCLf2uq4E2JWVw@mail.gmail.com>
Message-ID: <CAFeDf1_FoY4Y+ouDz3LUB3+_uy8vokMH1tiDaF8sAks9-Ww1HA@mail.gmail.com>

4.) I have three threads "runnable":

"XNIO-1 Accept at 6446" prio=5 tid=0x21 nid=NA runnable
  java.lang.Thread.State: RUNNABLE
 at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
 at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
 at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
 at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
 - locked <merged>(a sun.nio.ch.EPollSelectorImpl)
 - locked <merged>(a java.util.Collections$UnmodifiableSet)
 - locked <merged>(a sun.nio.ch.Util$3)
 at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
 at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
 at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)

"XNIO-1 I/O-7 at 6448" prio=5 tid=0x1f nid=NA runnable
  java.lang.Thread.State: RUNNABLE
 at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
 at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
 at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
 at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
 - locked <merged>(a sun.nio.ch.EPollSelectorImpl)
 - locked <merged>(a java.util.Collections$UnmodifiableSet)
 - locked <merged>(a sun.nio.ch.Util$3)
 at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
 at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
 at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)

"XNIO-1 I/O-3 at 6452" prio=5 tid=0x1b nid=NA runnable
  java.lang.Thread.State: RUNNABLE
 at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
 at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
 at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
 at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
 - locked <0x1953> (a sun.nio.ch.EPollSelectorImpl)
 - locked <0x1954> (a java.util.Collections$UnmodifiableSet)
 - locked <0x1955> (a sun.nio.ch.Util$3)
 at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
 at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
 at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)



On Fri, Feb 24, 2017 at 5:15 PM Hicks, Matt <matt at matthicks.com> wrote:

> 1.) I was running 1.4.10.Final, but I upgraded to 1.4.11.Final hoping it
> was a bug that was fixed, but it didn't make any difference.
> 2.) Yes
> 3.) No, of the 8 virtual CPUs none of them are maxed out.
> 4.) I'll have to get back to you...
>
> On Fri, Feb 24, 2017 at 5:10 PM Stuart Douglas <sdouglas at redhat.com>
> wrote:
>
> - What version of Undertow?
> - Is SSL in use?
> - Does the server enter some kind of spin loop (i.e. 100% CPU usage)?
> - What does the stack trace look like when this happens?
>
> Stuart
>
> On Sat, Feb 25, 2017 at 9:14 AM, Hicks, Matt <matt at matthicks.com> wrote:
> > 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?
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170224/ab7872b1/attachment-0001.html 

From matt at matthicks.com  Fri Feb 24 20:18:29 2017
From: matt at matthicks.com (Hicks, Matt)
Date: Sat, 25 Feb 2017 01:18:29 +0000
Subject: [undertow-dev] FormParserFactory getting stuck
In-Reply-To: <CAFeDf1_FoY4Y+ouDz3LUB3+_uy8vokMH1tiDaF8sAks9-Ww1HA@mail.gmail.com>
References: <CAFeDf1-b+uC-zeAO9f5h96P+TO8Td=CPGhka6gYU6hYQfQ_Vsg@mail.gmail.com>
	<CAD+L2cxZ50ofYx1eoxvQeqpqTs8Ke+fcSQAYxEoxCfqZQasCpA@mail.gmail.com>
	<CAFeDf1_=tmemc6sJWVR5+2rO7Zcv1163-L8idCLf2uq4E2JWVw@mail.gmail.com>
	<CAFeDf1_FoY4Y+ouDz3LUB3+_uy8vokMH1tiDaF8sAks9-Ww1HA@mail.gmail.com>
Message-ID: <CAFeDf18o92Vt7YwsR-XQnBqwVfjzanhHHfBR0QuaBD5WsASZvw@mail.gmail.com>

I gave it several minutes to run and finally just forcibly reloaded the
page and it spun for a few seconds like it normally does, but I waited and
eventually it threw this exception:

appJVM[ERROR] Feb 24, 2017 7:15:45 PM org.xnio.ChannelListeners
invokeChannelListener
appJVM[ERROR] ERROR: XNIO001007: A channel event listener threw an exception
appJVM[ERROR] java.lang.IllegalStateException
appJVM[ERROR]   at
io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.getBuffer(AbstractFramedStreamSinkChannel.java:574)
appJVM[ERROR]   at
io.undertow.server.protocol.framed.AbstractFramedChannel.flushSenders(AbstractFramedChannel.java:629)
appJVM[ERROR]   at
io.undertow.server.protocol.framed.AbstractFramedChannel$FrameWriteListener.handleEvent(AbstractFramedChannel.java:951)
appJVM[ERROR]   at
io.undertow.server.protocol.framed.AbstractFramedChannel$FrameWriteListener.handleEvent(AbstractFramedChannel.java:948)
appJVM[ERROR]   at
org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
appJVM[ERROR]   at
org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
appJVM[ERROR]   at
io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1225)
appJVM[ERROR]   at
io.undertow.protocols.ssl.SslConduit$3.run(SslConduit.java:275)
appJVM[ERROR]   at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580)
appJVM[ERROR]   at org.xnio.nio.WorkerThread.run(WorkerThread.java:464)

I don't know if it's relevant to the problem or not, but at this point I'm
just grasping for any straw.

On Fri, Feb 24, 2017 at 5:18 PM Hicks, Matt <matt at matthicks.com> wrote:

> 4.) I have three threads "runnable":
>
> "XNIO-1 Accept at 6446" prio=5 tid=0x21 nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>  at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
>  at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>  at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>  at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>  - locked <merged>(a sun.nio.ch.EPollSelectorImpl)
>  - locked <merged>(a java.util.Collections$UnmodifiableSet)
>  - locked <merged>(a sun.nio.ch.Util$3)
>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>  at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>
> "XNIO-1 I/O-7 at 6448" prio=5 tid=0x1f nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>  at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
>  at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>  at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>  at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>  - locked <merged>(a sun.nio.ch.EPollSelectorImpl)
>  - locked <merged>(a java.util.Collections$UnmodifiableSet)
>  - locked <merged>(a sun.nio.ch.Util$3)
>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>  at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>
> "XNIO-1 I/O-3 at 6452" prio=5 tid=0x1b nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>  at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
>  at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>  at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>  at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>  - locked <0x1953> (a sun.nio.ch.EPollSelectorImpl)
>  - locked <0x1954> (a java.util.Collections$UnmodifiableSet)
>  - locked <0x1955> (a sun.nio.ch.Util$3)
>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>  at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>
>
>
> On Fri, Feb 24, 2017 at 5:15 PM Hicks, Matt <matt at matthicks.com> wrote:
>
> 1.) I was running 1.4.10.Final, but I upgraded to 1.4.11.Final hoping it
> was a bug that was fixed, but it didn't make any difference.
> 2.) Yes
> 3.) No, of the 8 virtual CPUs none of them are maxed out.
> 4.) I'll have to get back to you...
>
> On Fri, Feb 24, 2017 at 5:10 PM Stuart Douglas <sdouglas at redhat.com>
> wrote:
>
> - What version of Undertow?
> - Is SSL in use?
> - Does the server enter some kind of spin loop (i.e. 100% CPU usage)?
> - What does the stack trace look like when this happens?
>
> Stuart
>
> On Sat, Feb 25, 2017 at 9:14 AM, Hicks, Matt <matt at matthicks.com> wrote:
> > 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?
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170225/f025812f/attachment.html 

From rohan.emmanuel07 at gmail.com  Sat Feb 25 08:40:21 2017
From: rohan.emmanuel07 at gmail.com (Rohan Emmanuel)
Date: Sat, 25 Feb 2017 19:10:21 +0530
Subject: [undertow-dev] Undertow-handlers.conf parse error
Message-ID: <CALCKA0q0DDvafAaUu-DpG0N1pjC30ERPaTTrT4pLiJ3m+yWefw@mail.gmail.com>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170225/4cee4fd1/attachment.html 

From matt at matthicks.com  Sat Feb 25 11:01:55 2017
From: matt at matthicks.com (Hicks, Matt)
Date: Sat, 25 Feb 2017 16:01:55 +0000
Subject: [undertow-dev] FormParserFactory getting stuck
In-Reply-To: <CAFeDf18o92Vt7YwsR-XQnBqwVfjzanhHHfBR0QuaBD5WsASZvw@mail.gmail.com>
References: <CAFeDf1-b+uC-zeAO9f5h96P+TO8Td=CPGhka6gYU6hYQfQ_Vsg@mail.gmail.com>
	<CAD+L2cxZ50ofYx1eoxvQeqpqTs8Ke+fcSQAYxEoxCfqZQasCpA@mail.gmail.com>
	<CAFeDf1_=tmemc6sJWVR5+2rO7Zcv1163-L8idCLf2uq4E2JWVw@mail.gmail.com>
	<CAFeDf1_FoY4Y+ouDz3LUB3+_uy8vokMH1tiDaF8sAks9-Ww1HA@mail.gmail.com>
	<CAFeDf18o92Vt7YwsR-XQnBqwVfjzanhHHfBR0QuaBD5WsASZvw@mail.gmail.com>
Message-ID: <CAFeDf1-5k_sVkc64E3ZbvAqmAfM4Vmb2Qcpjzc1_sndXgyQ7eQ@mail.gmail.com>

Well, it appears I fixed the problem.  After switching to the following
code everything is working fine now:

if (exchange.isInIoThread()) {
  exchange.dispatch(this);
} else {
  exchange.startBlocking();
  formParserBuilder.build().createParser(exchange).parseBlocking();
  ...
}

It's unfortunately that the non-blocking approach seems to be unreliable.

On Fri, Feb 24, 2017 at 7:18 PM Hicks, Matt <matt at matthicks.com> wrote:

> I gave it several minutes to run and finally just forcibly reloaded the
> page and it spun for a few seconds like it normally does, but I waited and
> eventually it threw this exception:
>
> appJVM[ERROR] Feb 24, 2017 7:15:45 PM org.xnio.ChannelListeners
> invokeChannelListener
> appJVM[ERROR] ERROR: XNIO001007: A channel event listener threw an
> exception
> appJVM[ERROR] java.lang.IllegalStateException
> appJVM[ERROR]   at
> io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.getBuffer(AbstractFramedStreamSinkChannel.java:574)
> appJVM[ERROR]   at
> io.undertow.server.protocol.framed.AbstractFramedChannel.flushSenders(AbstractFramedChannel.java:629)
> appJVM[ERROR]   at
> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameWriteListener.handleEvent(AbstractFramedChannel.java:951)
> appJVM[ERROR]   at
> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameWriteListener.handleEvent(AbstractFramedChannel.java:948)
> appJVM[ERROR]   at
> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> appJVM[ERROR]   at
> org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
> appJVM[ERROR]   at
> io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1225)
> appJVM[ERROR]   at
> io.undertow.protocols.ssl.SslConduit$3.run(SslConduit.java:275)
> appJVM[ERROR]   at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580)
> appJVM[ERROR]   at org.xnio.nio.WorkerThread.run(WorkerThread.java:464)
>
> I don't know if it's relevant to the problem or not, but at this point I'm
> just grasping for any straw.
>
> On Fri, Feb 24, 2017 at 5:18 PM Hicks, Matt <matt at matthicks.com> wrote:
>
> 4.) I have three threads "runnable":
>
> "XNIO-1 Accept at 6446" prio=5 tid=0x21 nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>  at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
>  at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>  at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>  at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>  - locked <merged>(a sun.nio.ch.EPollSelectorImpl)
>  - locked <merged>(a java.util.Collections$UnmodifiableSet)
>  - locked <merged>(a sun.nio.ch.Util$3)
>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>  at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>
> "XNIO-1 I/O-7 at 6448" prio=5 tid=0x1f nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>  at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
>  at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>  at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>  at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>  - locked <merged>(a sun.nio.ch.EPollSelectorImpl)
>  - locked <merged>(a java.util.Collections$UnmodifiableSet)
>  - locked <merged>(a sun.nio.ch.Util$3)
>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>  at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>
> "XNIO-1 I/O-3 at 6452" prio=5 tid=0x1b nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>  at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
>  at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>  at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>  at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>  - locked <0x1953> (a sun.nio.ch.EPollSelectorImpl)
>  - locked <0x1954> (a java.util.Collections$UnmodifiableSet)
>  - locked <0x1955> (a sun.nio.ch.Util$3)
>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>  at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>
>
>
> On Fri, Feb 24, 2017 at 5:15 PM Hicks, Matt <matt at matthicks.com> wrote:
>
> 1.) I was running 1.4.10.Final, but I upgraded to 1.4.11.Final hoping it
> was a bug that was fixed, but it didn't make any difference.
> 2.) Yes
> 3.) No, of the 8 virtual CPUs none of them are maxed out.
> 4.) I'll have to get back to you...
>
> On Fri, Feb 24, 2017 at 5:10 PM Stuart Douglas <sdouglas at redhat.com>
> wrote:
>
> - What version of Undertow?
> - Is SSL in use?
> - Does the server enter some kind of spin loop (i.e. 100% CPU usage)?
> - What does the stack trace look like when this happens?
>
> Stuart
>
> On Sat, Feb 25, 2017 at 9:14 AM, Hicks, Matt <matt at matthicks.com> wrote:
> > 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?
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170225/86b361d0/attachment-0001.html 

From bill at dartalley.com  Sat Feb 25 11:13:32 2017
From: bill at dartalley.com (Bill O'Neil)
Date: Sat, 25 Feb 2017 11:13:32 -0500
Subject: [undertow-dev] FormParserFactory getting stuck
In-Reply-To: <CAFeDf1-5k_sVkc64E3ZbvAqmAfM4Vmb2Qcpjzc1_sndXgyQ7eQ@mail.gmail.com>
References: <CAFeDf1-b+uC-zeAO9f5h96P+TO8Td=CPGhka6gYU6hYQfQ_Vsg@mail.gmail.com>
	<CAD+L2cxZ50ofYx1eoxvQeqpqTs8Ke+fcSQAYxEoxCfqZQasCpA@mail.gmail.com>
	<CAFeDf1_=tmemc6sJWVR5+2rO7Zcv1163-L8idCLf2uq4E2JWVw@mail.gmail.com>
	<CAFeDf1_FoY4Y+ouDz3LUB3+_uy8vokMH1tiDaF8sAks9-Ww1HA@mail.gmail.com>
	<CAFeDf18o92Vt7YwsR-XQnBqwVfjzanhHHfBR0QuaBD5WsASZvw@mail.gmail.com>
	<CAFeDf1-5k_sVkc64E3ZbvAqmAfM4Vmb2Qcpjzc1_sndXgyQ7eQ@mail.gmail.com>
Message-ID: <CANd+gFxQoc4g2MStxANy+6+cMNbvvnxc=A2Lt8u9CFfSZ65Vzg@mail.gmail.com>

Have you looked into the EagerFormParsingHandler
<https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/server/handlers/form/EagerFormParsingHandler.java>
?

On Sat, Feb 25, 2017 at 11:01 AM, Hicks, Matt <matt at matthicks.com> wrote:

> Well, it appears I fixed the problem.  After switching to the following
> code everything is working fine now:
>
> if (exchange.isInIoThread()) {
>   exchange.dispatch(this);
> } else {
>   exchange.startBlocking();
>   formParserBuilder.build().createParser(exchange).parseBlocking();
>   ...
> }
>
> It's unfortunately that the non-blocking approach seems to be unreliable.
>
> On Fri, Feb 24, 2017 at 7:18 PM Hicks, Matt <matt at matthicks.com> wrote:
>
>> I gave it several minutes to run and finally just forcibly reloaded the
>> page and it spun for a few seconds like it normally does, but I waited and
>> eventually it threw this exception:
>>
>> appJVM[ERROR] Feb 24, 2017 7:15:45 PM org.xnio.ChannelListeners
>> invokeChannelListener
>> appJVM[ERROR] ERROR: XNIO001007: A channel event listener threw an
>> exception
>> appJVM[ERROR] java.lang.IllegalStateException
>> appJVM[ERROR]   at io.undertow.server.protocol.framed.
>> AbstractFramedStreamSinkChannel.getBuffer(AbstractFramedStreamSinkChanne
>> l.java:574)
>> appJVM[ERROR]   at io.undertow.server.protocol.
>> framed.AbstractFramedChannel.flushSenders(AbstractFramedChannel.java:629)
>> appJVM[ERROR]   at io.undertow.server.protocol.
>> framed.AbstractFramedChannel$FrameWriteListener.handleEvent(
>> AbstractFramedChannel.java:951)
>> appJVM[ERROR]   at io.undertow.server.protocol.
>> framed.AbstractFramedChannel$FrameWriteListener.handleEvent(
>> AbstractFramedChannel.java:948)
>> appJVM[ERROR]   at org.xnio.ChannelListeners.invokeChannelListener(
>> ChannelListeners.java:92)
>> appJVM[ERROR]   at org.xnio.conduits.WriteReadyHandler$
>> ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
>> appJVM[ERROR]   at io.undertow.protocols.ssl.SslConduit$
>> SslWriteReadyHandler.writeReady(SslConduit.java:1225)
>> appJVM[ERROR]   at io.undertow.protocols.ssl.SslConduit$3.run(SslConduit.
>> java:275)
>> appJVM[ERROR]   at org.xnio.nio.WorkerThread.
>> safeRun(WorkerThread.java:580)
>> appJVM[ERROR]   at org.xnio.nio.WorkerThread.run(WorkerThread.java:464)
>>
>> I don't know if it's relevant to the problem or not, but at this point
>> I'm just grasping for any straw.
>>
>> On Fri, Feb 24, 2017 at 5:18 PM Hicks, Matt <matt at matthicks.com> wrote:
>>
>> 4.) I have three threads "runnable":
>>
>> "XNIO-1 Accept at 6446" prio=5 tid=0x21 nid=NA runnable
>>   java.lang.Thread.State: RUNNABLE
>>  at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
>>  at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>>  at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>>  at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>>  - locked <merged>(a sun.nio.ch.EPollSelectorImpl)
>>  - locked <merged>(a java.util.Collections$UnmodifiableSet)
>>  - locked <merged>(a sun.nio.ch.Util$3)
>>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>>  at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>>
>> "XNIO-1 I/O-7 at 6448" prio=5 tid=0x1f nid=NA runnable
>>   java.lang.Thread.State: RUNNABLE
>>  at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
>>  at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>>  at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>>  at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>>  - locked <merged>(a sun.nio.ch.EPollSelectorImpl)
>>  - locked <merged>(a java.util.Collections$UnmodifiableSet)
>>  - locked <merged>(a sun.nio.ch.Util$3)
>>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>>  at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>>
>> "XNIO-1 I/O-3 at 6452" prio=5 tid=0x1b nid=NA runnable
>>   java.lang.Thread.State: RUNNABLE
>>  at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
>>  at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>>  at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>>  at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>>  - locked <0x1953> (a sun.nio.ch.EPollSelectorImpl)
>>  - locked <0x1954> (a java.util.Collections$UnmodifiableSet)
>>  - locked <0x1955> (a sun.nio.ch.Util$3)
>>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>>  at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>>
>>
>>
>> On Fri, Feb 24, 2017 at 5:15 PM Hicks, Matt <matt at matthicks.com> wrote:
>>
>> 1.) I was running 1.4.10.Final, but I upgraded to 1.4.11.Final hoping it
>> was a bug that was fixed, but it didn't make any difference.
>> 2.) Yes
>> 3.) No, of the 8 virtual CPUs none of them are maxed out.
>> 4.) I'll have to get back to you...
>>
>> On Fri, Feb 24, 2017 at 5:10 PM Stuart Douglas <sdouglas at redhat.com>
>> wrote:
>>
>> - What version of Undertow?
>> - Is SSL in use?
>> - Does the server enter some kind of spin loop (i.e. 100% CPU usage)?
>> - What does the stack trace look like when this happens?
>>
>> Stuart
>>
>> On Sat, Feb 25, 2017 at 9:14 AM, Hicks, Matt <matt at matthicks.com> wrote:
>> > 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?
>> >
>> > _______________________________________________
>> > undertow-dev mailing list
>> > undertow-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>>
>>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170225/3be46ccb/attachment.html 

From matt at matthicks.com  Sat Feb 25 12:06:54 2017
From: matt at matthicks.com (Hicks, Matt)
Date: Sat, 25 Feb 2017 17:06:54 +0000
Subject: [undertow-dev] FormParserFactory getting stuck
In-Reply-To: <CANd+gFxQoc4g2MStxANy+6+cMNbvvnxc=A2Lt8u9CFfSZ65Vzg@mail.gmail.com>
References: <CAFeDf1-b+uC-zeAO9f5h96P+TO8Td=CPGhka6gYU6hYQfQ_Vsg@mail.gmail.com>
	<CAD+L2cxZ50ofYx1eoxvQeqpqTs8Ke+fcSQAYxEoxCfqZQasCpA@mail.gmail.com>
	<CAFeDf1_=tmemc6sJWVR5+2rO7Zcv1163-L8idCLf2uq4E2JWVw@mail.gmail.com>
	<CAFeDf1_FoY4Y+ouDz3LUB3+_uy8vokMH1tiDaF8sAks9-Ww1HA@mail.gmail.com>
	<CAFeDf18o92Vt7YwsR-XQnBqwVfjzanhHHfBR0QuaBD5WsASZvw@mail.gmail.com>
	<CAFeDf1-5k_sVkc64E3ZbvAqmAfM4Vmb2Qcpjzc1_sndXgyQ7eQ@mail.gmail.com>
	<CANd+gFxQoc4g2MStxANy+6+cMNbvvnxc=A2Lt8u9CFfSZ65Vzg@mail.gmail.com>
Message-ID: <CAFeDf18jpZJccBSjjFcg9wkkRRnshk33Rogbcw87-kt+cF-fqw@mail.gmail.com>

Thanks for the response Bill, but that's almost verbatim what I was already
doing and it was sometimes not working and getting stuck.

On Sat, Feb 25, 2017 at 10:13 AM Bill O'Neil <bill at dartalley.com> wrote:

> Have you looked into the EagerFormParsingHandler
> <https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/server/handlers/form/EagerFormParsingHandler.java>
> ?
>
> On Sat, Feb 25, 2017 at 11:01 AM, Hicks, Matt <matt at matthicks.com> wrote:
>
> Well, it appears I fixed the problem.  After switching to the following
> code everything is working fine now:
>
> if (exchange.isInIoThread()) {
>   exchange.dispatch(this);
> } else {
>   exchange.startBlocking();
>   formParserBuilder.build().createParser(exchange).parseBlocking();
>   ...
> }
>
> It's unfortunately that the non-blocking approach seems to be unreliable.
>
> On Fri, Feb 24, 2017 at 7:18 PM Hicks, Matt <matt at matthicks.com> wrote:
>
> I gave it several minutes to run and finally just forcibly reloaded the
> page and it spun for a few seconds like it normally does, but I waited and
> eventually it threw this exception:
>
> appJVM[ERROR] Feb 24, 2017 7:15:45 PM org.xnio.ChannelListeners
> invokeChannelListener
> appJVM[ERROR] ERROR: XNIO001007: A channel event listener threw an
> exception
> appJVM[ERROR] java.lang.IllegalStateException
> appJVM[ERROR]   at
> io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.getBuffer(AbstractFramedStreamSinkChannel.java:574)
> appJVM[ERROR]   at
> io.undertow.server.protocol.framed.AbstractFramedChannel.flushSenders(AbstractFramedChannel.java:629)
> appJVM[ERROR]   at
> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameWriteListener.handleEvent(AbstractFramedChannel.java:951)
> appJVM[ERROR]   at
> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameWriteListener.handleEvent(AbstractFramedChannel.java:948)
> appJVM[ERROR]   at
> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> appJVM[ERROR]   at
> org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
> appJVM[ERROR]   at
> io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1225)
> appJVM[ERROR]   at
> io.undertow.protocols.ssl.SslConduit$3.run(SslConduit.java:275)
> appJVM[ERROR]   at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580)
> appJVM[ERROR]   at org.xnio.nio.WorkerThread.run(WorkerThread.java:464)
>
> I don't know if it's relevant to the problem or not, but at this point I'm
> just grasping for any straw.
>
> On Fri, Feb 24, 2017 at 5:18 PM Hicks, Matt <matt at matthicks.com> wrote:
>
> 4.) I have three threads "runnable":
>
> "XNIO-1 Accept at 6446" prio=5 tid=0x21 nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>  at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
>  at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>  at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>  at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>  - locked <merged>(a sun.nio.ch.EPollSelectorImpl)
>  - locked <merged>(a java.util.Collections$UnmodifiableSet)
>  - locked <merged>(a sun.nio.ch.Util$3)
>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>  at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>
> "XNIO-1 I/O-7 at 6448" prio=5 tid=0x1f nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>  at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
>  at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>  at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>  at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>  - locked <merged>(a sun.nio.ch.EPollSelectorImpl)
>  - locked <merged>(a java.util.Collections$UnmodifiableSet)
>  - locked <merged>(a sun.nio.ch.Util$3)
>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>  at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>
> "XNIO-1 I/O-3 at 6452" prio=5 tid=0x1b nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>  at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
>  at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>  at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>  at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>  - locked <0x1953> (a sun.nio.ch.EPollSelectorImpl)
>  - locked <0x1954> (a java.util.Collections$UnmodifiableSet)
>  - locked <0x1955> (a sun.nio.ch.Util$3)
>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>  at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>
>
>
> On Fri, Feb 24, 2017 at 5:15 PM Hicks, Matt <matt at matthicks.com> wrote:
>
> 1.) I was running 1.4.10.Final, but I upgraded to 1.4.11.Final hoping it
> was a bug that was fixed, but it didn't make any difference.
> 2.) Yes
> 3.) No, of the 8 virtual CPUs none of them are maxed out.
> 4.) I'll have to get back to you...
>
> On Fri, Feb 24, 2017 at 5:10 PM Stuart Douglas <sdouglas at redhat.com>
> wrote:
>
> - What version of Undertow?
> - Is SSL in use?
> - Does the server enter some kind of spin loop (i.e. 100% CPU usage)?
> - What does the stack trace look like when this happens?
>
> Stuart
>
> On Sat, Feb 25, 2017 at 9:14 AM, Hicks, Matt <matt at matthicks.com> wrote:
> > 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?
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170225/697e06bb/attachment-0001.html 

From matt at matthicks.com  Sat Feb 25 13:12:29 2017
From: matt at matthicks.com (Hicks, Matt)
Date: Sat, 25 Feb 2017 18:12:29 +0000
Subject: [undertow-dev] FormParserFactory getting stuck
In-Reply-To: <CAFeDf18jpZJccBSjjFcg9wkkRRnshk33Rogbcw87-kt+cF-fqw@mail.gmail.com>
References: <CAFeDf1-b+uC-zeAO9f5h96P+TO8Td=CPGhka6gYU6hYQfQ_Vsg@mail.gmail.com>
	<CAD+L2cxZ50ofYx1eoxvQeqpqTs8Ke+fcSQAYxEoxCfqZQasCpA@mail.gmail.com>
	<CAFeDf1_=tmemc6sJWVR5+2rO7Zcv1163-L8idCLf2uq4E2JWVw@mail.gmail.com>
	<CAFeDf1_FoY4Y+ouDz3LUB3+_uy8vokMH1tiDaF8sAks9-Ww1HA@mail.gmail.com>
	<CAFeDf18o92Vt7YwsR-XQnBqwVfjzanhHHfBR0QuaBD5WsASZvw@mail.gmail.com>
	<CAFeDf1-5k_sVkc64E3ZbvAqmAfM4Vmb2Qcpjzc1_sndXgyQ7eQ@mail.gmail.com>
	<CANd+gFxQoc4g2MStxANy+6+cMNbvvnxc=A2Lt8u9CFfSZ65Vzg@mail.gmail.com>
	<CAFeDf18jpZJccBSjjFcg9wkkRRnshk33Rogbcw87-kt+cF-fqw@mail.gmail.com>
Message-ID: <CAFeDf18ygh_eLWWCtmzW6LC3UWcCxDoPEn_PJRDuNJy+fKQtUQ@mail.gmail.com>

It just occurred to me this might be related to me using HTTP2.  I was also
experiencing both client and server errors loading resources (audio and
video).  I just turned off HTTP2 and now I'm not experiencing any errors at
all.  I haven't tried switching back to asynchronous parsing of
multipart/form-data yet though.

On Sat, Feb 25, 2017 at 11:06 AM Hicks, Matt <matt at matthicks.com> wrote:

> Thanks for the response Bill, but that's almost verbatim what I was
> already doing and it was sometimes not working and getting stuck.
>
> On Sat, Feb 25, 2017 at 10:13 AM Bill O'Neil <bill at dartalley.com> wrote:
>
> Have you looked into the EagerFormParsingHandler
> <https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/server/handlers/form/EagerFormParsingHandler.java>
> ?
>
> On Sat, Feb 25, 2017 at 11:01 AM, Hicks, Matt <matt at matthicks.com> wrote:
>
> Well, it appears I fixed the problem.  After switching to the following
> code everything is working fine now:
>
> if (exchange.isInIoThread()) {
>   exchange.dispatch(this);
> } else {
>   exchange.startBlocking();
>   formParserBuilder.build().createParser(exchange).parseBlocking();
>   ...
> }
>
> It's unfortunately that the non-blocking approach seems to be unreliable.
>
> On Fri, Feb 24, 2017 at 7:18 PM Hicks, Matt <matt at matthicks.com> wrote:
>
> I gave it several minutes to run and finally just forcibly reloaded the
> page and it spun for a few seconds like it normally does, but I waited and
> eventually it threw this exception:
>
> appJVM[ERROR] Feb 24, 2017 7:15:45 PM org.xnio.ChannelListeners
> invokeChannelListener
> appJVM[ERROR] ERROR: XNIO001007: A channel event listener threw an
> exception
> appJVM[ERROR] java.lang.IllegalStateException
> appJVM[ERROR]   at
> io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.getBuffer(AbstractFramedStreamSinkChannel.java:574)
> appJVM[ERROR]   at
> io.undertow.server.protocol.framed.AbstractFramedChannel.flushSenders(AbstractFramedChannel.java:629)
> appJVM[ERROR]   at
> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameWriteListener.handleEvent(AbstractFramedChannel.java:951)
> appJVM[ERROR]   at
> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameWriteListener.handleEvent(AbstractFramedChannel.java:948)
> appJVM[ERROR]   at
> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> appJVM[ERROR]   at
> org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
> appJVM[ERROR]   at
> io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1225)
> appJVM[ERROR]   at
> io.undertow.protocols.ssl.SslConduit$3.run(SslConduit.java:275)
> appJVM[ERROR]   at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580)
> appJVM[ERROR]   at org.xnio.nio.WorkerThread.run(WorkerThread.java:464)
>
> I don't know if it's relevant to the problem or not, but at this point I'm
> just grasping for any straw.
>
> On Fri, Feb 24, 2017 at 5:18 PM Hicks, Matt <matt at matthicks.com> wrote:
>
> 4.) I have three threads "runnable":
>
> "XNIO-1 Accept at 6446" prio=5 tid=0x21 nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>  at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
>  at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>  at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>  at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>  - locked <merged>(a sun.nio.ch.EPollSelectorImpl)
>  - locked <merged>(a java.util.Collections$UnmodifiableSet)
>  - locked <merged>(a sun.nio.ch.Util$3)
>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>  at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>
> "XNIO-1 I/O-7 at 6448" prio=5 tid=0x1f nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>  at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
>  at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>  at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>  at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>  - locked <merged>(a sun.nio.ch.EPollSelectorImpl)
>  - locked <merged>(a java.util.Collections$UnmodifiableSet)
>  - locked <merged>(a sun.nio.ch.Util$3)
>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>  at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>
> "XNIO-1 I/O-3 at 6452" prio=5 tid=0x1b nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>  at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
>  at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>  at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>  at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>  - locked <0x1953> (a sun.nio.ch.EPollSelectorImpl)
>  - locked <0x1954> (a java.util.Collections$UnmodifiableSet)
>  - locked <0x1955> (a sun.nio.ch.Util$3)
>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>  at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>
>
>
> On Fri, Feb 24, 2017 at 5:15 PM Hicks, Matt <matt at matthicks.com> wrote:
>
> 1.) I was running 1.4.10.Final, but I upgraded to 1.4.11.Final hoping it
> was a bug that was fixed, but it didn't make any difference.
> 2.) Yes
> 3.) No, of the 8 virtual CPUs none of them are maxed out.
> 4.) I'll have to get back to you...
>
> On Fri, Feb 24, 2017 at 5:10 PM Stuart Douglas <sdouglas at redhat.com>
> wrote:
>
> - What version of Undertow?
> - Is SSL in use?
> - Does the server enter some kind of spin loop (i.e. 100% CPU usage)?
> - What does the stack trace look like when this happens?
>
> Stuart
>
> On Sat, Feb 25, 2017 at 9:14 AM, Hicks, Matt <matt at matthicks.com> wrote:
> > 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?
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170225/09d58ab7/attachment-0001.html 

From sdouglas at redhat.com  Sun Feb 26 16:31:30 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 27 Feb 2017 08:31:30 +1100
Subject: [undertow-dev] Undertow-handlers.conf parse error
In-Reply-To: <CALCKA0q0DDvafAaUu-DpG0N1pjC30ERPaTTrT4pLiJ3m+yWefw@mail.gmail.com>
References: <CALCKA0q0DDvafAaUu-DpG0N1pjC30ERPaTTrT4pLiJ3m+yWefw@mail.gmail.com>
Message-ID: <CAD+L2cz-sD7UAWud014ESe203nNCahZX+9oYzRw1d=ZFfuFa7A@mail.gmail.com>

What does the contents of the file look like? This should work.

Stuart

On Sun, Feb 26, 2017 at 12:40 AM, Rohan Emmanuel
<rohan.emmanuel07 at gmail.com> wrote:
> 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
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From sdouglas at redhat.com  Sun Feb 26 16:33:31 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 27 Feb 2017 08:33:31 +1100
Subject: [undertow-dev] FormParserFactory getting stuck
In-Reply-To: <CAFeDf18ygh_eLWWCtmzW6LC3UWcCxDoPEn_PJRDuNJy+fKQtUQ@mail.gmail.com>
References: <CAFeDf1-b+uC-zeAO9f5h96P+TO8Td=CPGhka6gYU6hYQfQ_Vsg@mail.gmail.com>
	<CAD+L2cxZ50ofYx1eoxvQeqpqTs8Ke+fcSQAYxEoxCfqZQasCpA@mail.gmail.com>
	<CAFeDf1_=tmemc6sJWVR5+2rO7Zcv1163-L8idCLf2uq4E2JWVw@mail.gmail.com>
	<CAFeDf1_FoY4Y+ouDz3LUB3+_uy8vokMH1tiDaF8sAks9-Ww1HA@mail.gmail.com>
	<CAFeDf18o92Vt7YwsR-XQnBqwVfjzanhHHfBR0QuaBD5WsASZvw@mail.gmail.com>
	<CAFeDf1-5k_sVkc64E3ZbvAqmAfM4Vmb2Qcpjzc1_sndXgyQ7eQ@mail.gmail.com>
	<CANd+gFxQoc4g2MStxANy+6+cMNbvvnxc=A2Lt8u9CFfSZ65Vzg@mail.gmail.com>
	<CAFeDf18jpZJccBSjjFcg9wkkRRnshk33Rogbcw87-kt+cF-fqw@mail.gmail.com>
	<CAFeDf18ygh_eLWWCtmzW6LC3UWcCxDoPEn_PJRDuNJy+fKQtUQ@mail.gmail.com>
Message-ID: <CAD+L2cyV2NAd_OnHKAPkusBYQnJoa59mMAAfC6J_2xwgtNprpQ@mail.gmail.com>

This does sound like a h2 issue. Do you have a reliable way or
reproducing it that I can debug?

Stuart

On Sun, Feb 26, 2017 at 5:12 AM, Hicks, Matt <matt at matthicks.com> wrote:
> It just occurred to me this might be related to me using HTTP2.  I was also
> experiencing both client and server errors loading resources (audio and
> video).  I just turned off HTTP2 and now I'm not experiencing any errors at
> all.  I haven't tried switching back to asynchronous parsing of
> multipart/form-data yet though.
>
> On Sat, Feb 25, 2017 at 11:06 AM Hicks, Matt <matt at matthicks.com> wrote:
>>
>> Thanks for the response Bill, but that's almost verbatim what I was
>> already doing and it was sometimes not working and getting stuck.
>>
>> On Sat, Feb 25, 2017 at 10:13 AM Bill O'Neil <bill at dartalley.com> wrote:
>>>
>>> Have you looked into the EagerFormParsingHandler?
>>>
>>> On Sat, Feb 25, 2017 at 11:01 AM, Hicks, Matt <matt at matthicks.com> wrote:
>>>>
>>>> Well, it appears I fixed the problem.  After switching to the following
>>>> code everything is working fine now:
>>>>
>>>> if (exchange.isInIoThread()) {
>>>>   exchange.dispatch(this);
>>>> } else {
>>>>   exchange.startBlocking();
>>>>   formParserBuilder.build().createParser(exchange).parseBlocking();
>>>>   ...
>>>> }
>>>>
>>>> It's unfortunately that the non-blocking approach seems to be
>>>> unreliable.
>>>>
>>>> On Fri, Feb 24, 2017 at 7:18 PM Hicks, Matt <matt at matthicks.com> wrote:
>>>>>
>>>>> I gave it several minutes to run and finally just forcibly reloaded the
>>>>> page and it spun for a few seconds like it normally does, but I waited and
>>>>> eventually it threw this exception:
>>>>>
>>>>> appJVM[ERROR] Feb 24, 2017 7:15:45 PM org.xnio.ChannelListeners
>>>>> invokeChannelListener
>>>>> appJVM[ERROR] ERROR: XNIO001007: A channel event listener threw an
>>>>> exception
>>>>> appJVM[ERROR] java.lang.IllegalStateException
>>>>> appJVM[ERROR]   at
>>>>> io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.getBuffer(AbstractFramedStreamSinkChannel.java:574)
>>>>> appJVM[ERROR]   at
>>>>> io.undertow.server.protocol.framed.AbstractFramedChannel.flushSenders(AbstractFramedChannel.java:629)
>>>>> appJVM[ERROR]   at
>>>>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameWriteListener.handleEvent(AbstractFramedChannel.java:951)
>>>>> appJVM[ERROR]   at
>>>>> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameWriteListener.handleEvent(AbstractFramedChannel.java:948)
>>>>> appJVM[ERROR]   at
>>>>> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
>>>>> appJVM[ERROR]   at
>>>>> org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
>>>>> appJVM[ERROR]   at
>>>>> io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1225)
>>>>> appJVM[ERROR]   at
>>>>> io.undertow.protocols.ssl.SslConduit$3.run(SslConduit.java:275)
>>>>> appJVM[ERROR]   at
>>>>> org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580)
>>>>> appJVM[ERROR]   at org.xnio.nio.WorkerThread.run(WorkerThread.java:464)
>>>>>
>>>>> I don't know if it's relevant to the problem or not, but at this point
>>>>> I'm just grasping for any straw.
>>>>>
>>>>> On Fri, Feb 24, 2017 at 5:18 PM Hicks, Matt <matt at matthicks.com> wrote:
>>>>>>
>>>>>> 4.) I have three threads "runnable":
>>>>>>
>>>>>> "XNIO-1 Accept at 6446" prio=5 tid=0x21 nid=NA runnable
>>>>>>   java.lang.Thread.State: RUNNABLE
>>>>>>  at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
>>>>>>  at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>>>>>>  at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>>>>>>  at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>>>>>>  - locked <merged>(a sun.nio.ch.EPollSelectorImpl)
>>>>>>  - locked <merged>(a java.util.Collections$UnmodifiableSet)
>>>>>>  - locked <merged>(a sun.nio.ch.Util$3)
>>>>>>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>>>>>>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>>>>>>  at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>>>>>>
>>>>>> "XNIO-1 I/O-7 at 6448" prio=5 tid=0x1f nid=NA runnable
>>>>>>   java.lang.Thread.State: RUNNABLE
>>>>>>  at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
>>>>>>  at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>>>>>>  at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>>>>>>  at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>>>>>>  - locked <merged>(a sun.nio.ch.EPollSelectorImpl)
>>>>>>  - locked <merged>(a java.util.Collections$UnmodifiableSet)
>>>>>>  - locked <merged>(a sun.nio.ch.Util$3)
>>>>>>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>>>>>>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>>>>>>  at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>>>>>>
>>>>>> "XNIO-1 I/O-3 at 6452" prio=5 tid=0x1b nid=NA runnable
>>>>>>   java.lang.Thread.State: RUNNABLE
>>>>>>  at sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
>>>>>>  at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
>>>>>>  at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
>>>>>>  at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
>>>>>>  - locked <0x1953> (a sun.nio.ch.EPollSelectorImpl)
>>>>>>  - locked <0x1954> (a java.util.Collections$UnmodifiableSet)
>>>>>>  - locked <0x1955> (a sun.nio.ch.Util$3)
>>>>>>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
>>>>>>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
>>>>>>  at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Feb 24, 2017 at 5:15 PM Hicks, Matt <matt at matthicks.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> 1.) I was running 1.4.10.Final, but I upgraded to 1.4.11.Final hoping
>>>>>>> it was a bug that was fixed, but it didn't make any difference.
>>>>>>> 2.) Yes
>>>>>>> 3.) No, of the 8 virtual CPUs none of them are maxed out.
>>>>>>> 4.) I'll have to get back to you...
>>>>>>>
>>>>>>> On Fri, Feb 24, 2017 at 5:10 PM Stuart Douglas <sdouglas at redhat.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> - What version of Undertow?
>>>>>>>> - Is SSL in use?
>>>>>>>> - Does the server enter some kind of spin loop (i.e. 100% CPU
>>>>>>>> usage)?
>>>>>>>> - What does the stack trace look like when this happens?
>>>>>>>>
>>>>>>>> Stuart
>>>>>>>>
>>>>>>>> On Sat, Feb 25, 2017 at 9:14 AM, Hicks, Matt <matt at matthicks.com>
>>>>>>>> wrote:
>>>>>>>> > 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?
>>>>>>>> >
>>>>>>>> > _______________________________________________
>>>>>>>> > undertow-dev mailing list
>>>>>>>> > undertow-dev at lists.jboss.org
>>>>>>>> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>>
>>>>
>>>> _______________________________________________
>>>> undertow-dev mailing list
>>>> undertow-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>>>
>>>
>

From sdouglas at redhat.com  Sun Feb 26 21:33:25 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 27 Feb 2017 13:33:25 +1100
Subject: [undertow-dev] Tracing HTTP Response content
In-Reply-To: <CALCKA0oUj0entvpKDpeds66U88Wc3z9bAg_21f_+001vF-UDOA@mail.gmail.com>
References: <CALCKA0oUj0entvpKDpeds66U88Wc3z9bAg_21f_+001vF-UDOA@mail.gmail.com>
Message-ID: <CAD+L2cwH_7csDG9V9_=zmr9hX1uV1Gbp4aU7yCNWG5Pzm-ZG3w@mail.gmail.com>

Whatever code is writing to the cache needs to just hold onto the
exchange and send an error response as required.

Stuart

On Fri, Feb 24, 2017 at 5:31 PM, Rohan Emmanuel
<rohan.emmanuel07 at gmail.com> wrote:
> 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
>
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev

From rohan.emmanuel07 at gmail.com  Sun Feb 26 23:59:08 2017
From: rohan.emmanuel07 at gmail.com (Rohan Emmanuel)
Date: Mon, 27 Feb 2017 10:29:08 +0530
Subject: [undertow-dev] Undertow-handlers.conf parse error
In-Reply-To: <CAD+L2cz-sD7UAWud014ESe203nNCahZX+9oYzRw1d=ZFfuFa7A@mail.gmail.com>
References: <CALCKA0q0DDvafAaUu-DpG0N1pjC30ERPaTTrT4pLiJ3m+yWefw@mail.gmail.com>
	<CAD+L2cz-sD7UAWud014ESe203nNCahZX+9oYzRw1d=ZFfuFa7A@mail.gmail.com>
Message-ID: <CALCKA0phDq1fKjxWgGVUkjx-W92GiHb4o+EcknsWDMQz06sjbw@mail.gmail.com>

The contents of the file looks as below,
dump-request
ha-handler

(ha-handler is a handler which i have introduced)

I also saw the same error when there is a carriage return in the file after
i specify dump-request handler.
the contents of the file looked like below(here i have written <CRLF> here
just to represents EOL),
dump-request<CRLF>




On Mon, Feb 27, 2017 at 3:01 AM, Stuart Douglas <sdouglas at redhat.com> wrote:

> What does the contents of the file look like? This should work.
>
> Stuart
>
> On Sun, Feb 26, 2017 at 12:40 AM, Rohan Emmanuel
> <rohan.emmanuel07 at gmail.com> wrote:
> > 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
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>



-- 
Regards,
Rohan Emmanuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170227/d1f510f8/attachment.html 

From rohan.emmanuel07 at gmail.com  Mon Feb 27 00:25:23 2017
From: rohan.emmanuel07 at gmail.com (Rohan Emmanuel)
Date: Mon, 27 Feb 2017 10:55:23 +0530
Subject: [undertow-dev] Tracing HTTP Response content
In-Reply-To: <CAD+L2cwH_7csDG9V9_=zmr9hX1uV1Gbp4aU7yCNWG5Pzm-ZG3w@mail.gmail.com>
References: <CALCKA0oUj0entvpKDpeds66U88Wc3z9bAg_21f_+001vF-UDOA@mail.gmail.com>
	<CAD+L2cwH_7csDG9V9_=zmr9hX1uV1Gbp4aU7yCNWG5Pzm-ZG3w@mail.gmail.com>
Message-ID: <CALCKA0ogd15BCZAFXtkeZD1a1+wEy0gk5s2k307Qep3xb2J3Fw@mail.gmail.com>

hi Stuart,
I have a ResponseCommitListener added to my handler, I want this to write
to the cache, so that my reponseWrapper will take of the error handling if
the ResponsecommitListener faces any error while storing the response to
cache.

I understand HttpResponseConduit constructs the headers and then pushes the
response.
But the confusion is, how will i get a access to response Headers and body
in the my ResponseCommitListener?


My approach is valid? if not ,any suggestion?


On Mon, Feb 27, 2017 at 8:03 AM, Stuart Douglas <sdouglas at redhat.com> wrote:

> Whatever code is writing to the cache needs to just hold onto the
> exchange and send an error response as required.
>
> Stuart
>
> On Fri, Feb 24, 2017 at 5:31 PM, Rohan Emmanuel
> <rohan.emmanuel07 at gmail.com> wrote:
> > 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
> >
> > _______________________________________________
> > undertow-dev mailing list
> > undertow-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>



-- 
Regards,
Rohan Emmanuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170227/6917116f/attachment-0001.html 

From sdouglas at redhat.com  Mon Feb 27 05:19:40 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 27 Feb 2017 21:19:40 +1100
Subject: [undertow-dev] Undertow-handlers.conf parse error
In-Reply-To: <CALCKA0phDq1fKjxWgGVUkjx-W92GiHb4o+EcknsWDMQz06sjbw@mail.gmail.com>
References: <CALCKA0q0DDvafAaUu-DpG0N1pjC30ERPaTTrT4pLiJ3m+yWefw@mail.gmail.com>
	<CAD+L2cz-sD7UAWud014ESe203nNCahZX+9oYzRw1d=ZFfuFa7A@mail.gmail.com>
	<CALCKA0phDq1fKjxWgGVUkjx-W92GiHb4o+EcknsWDMQz06sjbw@mail.gmail.com>
Message-ID: <CAD+L2cyn8FxgGxQtF-2YiT3mWF9huigfmhGnvpMYj77yLBDypw@mail.gmail.com>

Is it possible you are running into
https://issues.jboss.org/browse/UNDERTOW-656 ?

On Mon, Feb 27, 2017 at 3:59 PM, Rohan Emmanuel
<rohan.emmanuel07 at gmail.com> wrote:
> The contents of the file looks as below,
> dump-request
> ha-handler
>
> (ha-handler is a handler which i have introduced)
>
> I also saw the same error when there is a carriage return in the file after
> i specify dump-request handler.
> the contents of the file looked like below(here i have written <CRLF> here
> just to represents EOL),
> dump-request<CRLF>
>
>
>
>
> On Mon, Feb 27, 2017 at 3:01 AM, Stuart Douglas <sdouglas at redhat.com> wrote:
>>
>> What does the contents of the file look like? This should work.
>>
>> Stuart
>>
>> On Sun, Feb 26, 2017 at 12:40 AM, Rohan Emmanuel
>> <rohan.emmanuel07 at gmail.com> wrote:
>> > 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
>> >
>> > _______________________________________________
>> > undertow-dev mailing list
>> > undertow-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>
>
>
> --
> Regards,
> Rohan Emmanuel

From sdouglas at redhat.com  Mon Feb 27 05:20:38 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Mon, 27 Feb 2017 21:20:38 +1100
Subject: [undertow-dev] Tracing HTTP Response content
In-Reply-To: <CALCKA0ogd15BCZAFXtkeZD1a1+wEy0gk5s2k307Qep3xb2J3Fw@mail.gmail.com>
References: <CALCKA0oUj0entvpKDpeds66U88Wc3z9bAg_21f_+001vF-UDOA@mail.gmail.com>
	<CAD+L2cwH_7csDG9V9_=zmr9hX1uV1Gbp4aU7yCNWG5Pzm-ZG3w@mail.gmail.com>
	<CALCKA0ogd15BCZAFXtkeZD1a1+wEy0gk5s2k307Qep3xb2J3Fw@mail.gmail.com>
Message-ID: <CAD+L2czM=JRXEMo=MeXXm+p=A9eZbKDrxYxugLA_KW03NmsWQA@mail.gmail.com>

You have access to the exchange, it is passed into the ResponseCommitListener.

Stuart

On Mon, Feb 27, 2017 at 4:25 PM, Rohan Emmanuel
<rohan.emmanuel07 at gmail.com> wrote:
> hi Stuart,
> I have a ResponseCommitListener added to my handler, I want this to write to
> the cache, so that my reponseWrapper will take of the error handling if the
> ResponsecommitListener faces any error while storing the response to cache.
>
> I understand HttpResponseConduit constructs the headers and then pushes the
> response.
> But the confusion is, how will i get a access to response Headers and body
> in the my ResponseCommitListener?
>
>
> My approach is valid? if not ,any suggestion?
>
>
> On Mon, Feb 27, 2017 at 8:03 AM, Stuart Douglas <sdouglas at redhat.com> wrote:
>>
>> Whatever code is writing to the cache needs to just hold onto the
>> exchange and send an error response as required.
>>
>> Stuart
>>
>> On Fri, Feb 24, 2017 at 5:31 PM, Rohan Emmanuel
>> <rohan.emmanuel07 at gmail.com> wrote:
>> > 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
>> >
>> > _______________________________________________
>> > undertow-dev mailing list
>> > undertow-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>
>
>
> --
> Regards,
> Rohan Emmanuel

From rohan.emmanuel07 at gmail.com  Mon Feb 27 05:47:00 2017
From: rohan.emmanuel07 at gmail.com (Rohan Emmanuel)
Date: Mon, 27 Feb 2017 16:17:00 +0530
Subject: [undertow-dev] Undertow-handlers.conf parse error
In-Reply-To: <CAD+L2cyn8FxgGxQtF-2YiT3mWF9huigfmhGnvpMYj77yLBDypw@mail.gmail.com>
References: <CALCKA0q0DDvafAaUu-DpG0N1pjC30ERPaTTrT4pLiJ3m+yWefw@mail.gmail.com>
	<CAD+L2cz-sD7UAWud014ESe203nNCahZX+9oYzRw1d=ZFfuFa7A@mail.gmail.com>
	<CALCKA0phDq1fKjxWgGVUkjx-W92GiHb4o+EcknsWDMQz06sjbw@mail.gmail.com>
	<CAD+L2cyn8FxgGxQtF-2YiT3mWF9huigfmhGnvpMYj77yLBDypw@mail.gmail.com>
Message-ID: <CALCKA0o9OaZynYo=U25Zc5wbfzqQnqe7zNXETYQQ0enYgBLFAg@mail.gmail.com>

yes, looks similar.I see that the fix is in 1.3.19.Final.
I am using comparatively older version undertow 1.3.15.Final which comes in
Wildfly 10.0.0.Final.
Thanks

On Mon, Feb 27, 2017 at 3:49 PM, Stuart Douglas <sdouglas at redhat.com> wrote:

> Is it possible you are running into
> https://issues.jboss.org/browse/UNDERTOW-656 ?
>
> On Mon, Feb 27, 2017 at 3:59 PM, Rohan Emmanuel
> <rohan.emmanuel07 at gmail.com> wrote:
> > The contents of the file looks as below,
> > dump-request
> > ha-handler
> >
> > (ha-handler is a handler which i have introduced)
> >
> > I also saw the same error when there is a carriage return in the file
> after
> > i specify dump-request handler.
> > the contents of the file looked like below(here i have written <CRLF>
> here
> > just to represents EOL),
> > dump-request<CRLF>
> >
> >
> >
> >
> > On Mon, Feb 27, 2017 at 3:01 AM, Stuart Douglas <sdouglas at redhat.com>
> wrote:
> >>
> >> What does the contents of the file look like? This should work.
> >>
> >> Stuart
> >>
> >> On Sun, Feb 26, 2017 at 12:40 AM, Rohan Emmanuel
> >> <rohan.emmanuel07 at gmail.com> wrote:
> >> > 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
> >> >
> >> > _______________________________________________
> >> > undertow-dev mailing list
> >> > undertow-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> >> _______________________________________________
> >> undertow-dev mailing list
> >> undertow-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >
> >
> >
> >
> > --
> > Regards,
> > Rohan Emmanuel
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>



-- 
Regards,
Rohan Emmanuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170227/74ebd0fd/attachment.html 

From rohan.emmanuel07 at gmail.com  Mon Feb 27 08:43:04 2017
From: rohan.emmanuel07 at gmail.com (Rohan Emmanuel)
Date: Mon, 27 Feb 2017 19:13:04 +0530
Subject: [undertow-dev] Tracing HTTP Response content
In-Reply-To: <CAD+L2czM=JRXEMo=MeXXm+p=A9eZbKDrxYxugLA_KW03NmsWQA@mail.gmail.com>
References: <CALCKA0oUj0entvpKDpeds66U88Wc3z9bAg_21f_+001vF-UDOA@mail.gmail.com>
	<CAD+L2cwH_7csDG9V9_=zmr9hX1uV1Gbp4aU7yCNWG5Pzm-ZG3w@mail.gmail.com>
	<CALCKA0ogd15BCZAFXtkeZD1a1+wEy0gk5s2k307Qep3xb2J3Fw@mail.gmail.com>
	<CAD+L2czM=JRXEMo=MeXXm+p=A9eZbKDrxYxugLA_KW03NmsWQA@mail.gmail.com>
Message-ID: <CALCKA0rzN3XOuwePQVqtfyt5-9enbeht0HRXkV5NY7x7RNxA2Q@mail.gmail.com>

Hi Stuart,

i am new to Undertow code, Can you please elaborate.

yes, The exchange will be passed to the ResponseCommitListener, but From
exchange i cannot get the response content directly ,correct? as there is
no method to get the Response body like getResponseHeaders.

so i would need something like  a conduit inside my ResponseCommitListener
to get a handle on the response content?
Any other straight forward way to get the response content using exchange
object?

Thanks for all the help.


On Mon, Feb 27, 2017 at 3:50 PM, Stuart Douglas <sdouglas at redhat.com> wrote:

> You have access to the exchange, it is passed into the
> ResponseCommitListener.
>
> Stuart
>
> On Mon, Feb 27, 2017 at 4:25 PM, Rohan Emmanuel
> <rohan.emmanuel07 at gmail.com> wrote:
> > hi Stuart,
> > I have a ResponseCommitListener added to my handler, I want this to
> write to
> > the cache, so that my reponseWrapper will take of the error handling if
> the
> > ResponsecommitListener faces any error while storing the response to
> cache.
> >
> > I understand HttpResponseConduit constructs the headers and then pushes
> the
> > response.
> > But the confusion is, how will i get a access to response Headers and
> body
> > in the my ResponseCommitListener?
> >
> >
> > My approach is valid? if not ,any suggestion?
> >
> >
> > On Mon, Feb 27, 2017 at 8:03 AM, Stuart Douglas <sdouglas at redhat.com>
> wrote:
> >>
> >> Whatever code is writing to the cache needs to just hold onto the
> >> exchange and send an error response as required.
> >>
> >> Stuart
> >>
> >> On Fri, Feb 24, 2017 at 5:31 PM, Rohan Emmanuel
> >> <rohan.emmanuel07 at gmail.com> wrote:
> >> > 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
> >> >
> >> > _______________________________________________
> >> > undertow-dev mailing list
> >> > undertow-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> >> _______________________________________________
> >> undertow-dev mailing list
> >> undertow-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >
> >
> >
> >
> > --
> > Regards,
> > Rohan Emmanuel
> _______________________________________________
> undertow-dev mailing list
> undertow-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/undertow-dev
>



-- 
Regards,
Rohan Emmanuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170227/8a61c0df/attachment-0001.html 

From matt at matthicks.com  Mon Feb 27 10:51:42 2017
From: matt at matthicks.com (Hicks, Matt)
Date: Mon, 27 Feb 2017 15:51:42 +0000
Subject: [undertow-dev] FormParserFactory getting stuck
In-Reply-To: <CAD+L2cyV2NAd_OnHKAPkusBYQnJoa59mMAAfC6J_2xwgtNprpQ@mail.gmail.com>
References: <CAFeDf1-b+uC-zeAO9f5h96P+TO8Td=CPGhka6gYU6hYQfQ_Vsg@mail.gmail.com>
	<CAD+L2cxZ50ofYx1eoxvQeqpqTs8Ke+fcSQAYxEoxCfqZQasCpA@mail.gmail.com>
	<CAFeDf1_=tmemc6sJWVR5+2rO7Zcv1163-L8idCLf2uq4E2JWVw@mail.gmail.com>
	<CAFeDf1_FoY4Y+ouDz3LUB3+_uy8vokMH1tiDaF8sAks9-Ww1HA@mail.gmail.com>
	<CAFeDf18o92Vt7YwsR-XQnBqwVfjzanhHHfBR0QuaBD5WsASZvw@mail.gmail.com>
	<CAFeDf1-5k_sVkc64E3ZbvAqmAfM4Vmb2Qcpjzc1_sndXgyQ7eQ@mail.gmail.com>
	<CANd+gFxQoc4g2MStxANy+6+cMNbvvnxc=A2Lt8u9CFfSZ65Vzg@mail.gmail.com>
	<CAFeDf18jpZJccBSjjFcg9wkkRRnshk33Rogbcw87-kt+cF-fqw@mail.gmail.com>
	<CAFeDf18ygh_eLWWCtmzW6LC3UWcCxDoPEn_PJRDuNJy+fKQtUQ@mail.gmail.com>
	<CAD+L2cyV2NAd_OnHKAPkusBYQnJoa59mMAAfC6J_2xwgtNprpQ@mail.gmail.com>
Message-ID: <CAFeDf1_QKLqEBh7m=xt1eFi4ZXJm8woe_M5WE3xTk6_oJdCy=A@mail.gmail.com>

Unfortunately not, but my scenario itself was fairly simple.  I was just
creating a FormData instance in JavaScript that had a few values including
a file and then sending it via AJAX POST to the server as
multipart/form-data.

On Sun, Feb 26, 2017 at 3:33 PM Stuart Douglas <sdouglas at redhat.com> wrote:

> This does sound like a h2 issue. Do you have a reliable way or
> reproducing it that I can debug?
>
> Stuart
>
> On Sun, Feb 26, 2017 at 5:12 AM, Hicks, Matt <matt at matthicks.com> wrote:
> > It just occurred to me this might be related to me using HTTP2.  I was
> also
> > experiencing both client and server errors loading resources (audio and
> > video).  I just turned off HTTP2 and now I'm not experiencing any errors
> at
> > all.  I haven't tried switching back to asynchronous parsing of
> > multipart/form-data yet though.
> >
> > On Sat, Feb 25, 2017 at 11:06 AM Hicks, Matt <matt at matthicks.com> wrote:
> >>
> >> Thanks for the response Bill, but that's almost verbatim what I was
> >> already doing and it was sometimes not working and getting stuck.
> >>
> >> On Sat, Feb 25, 2017 at 10:13 AM Bill O'Neil <bill at dartalley.com>
> wrote:
> >>>
> >>> Have you looked into the EagerFormParsingHandler?
> >>>
> >>> On Sat, Feb 25, 2017 at 11:01 AM, Hicks, Matt <matt at matthicks.com>
> wrote:
> >>>>
> >>>> Well, it appears I fixed the problem.  After switching to the
> following
> >>>> code everything is working fine now:
> >>>>
> >>>> if (exchange.isInIoThread()) {
> >>>>   exchange.dispatch(this);
> >>>> } else {
> >>>>   exchange.startBlocking();
> >>>>   formParserBuilder.build().createParser(exchange).parseBlocking();
> >>>>   ...
> >>>> }
> >>>>
> >>>> It's unfortunately that the non-blocking approach seems to be
> >>>> unreliable.
> >>>>
> >>>> On Fri, Feb 24, 2017 at 7:18 PM Hicks, Matt <matt at matthicks.com>
> wrote:
> >>>>>
> >>>>> I gave it several minutes to run and finally just forcibly reloaded
> the
> >>>>> page and it spun for a few seconds like it normally does, but I
> waited and
> >>>>> eventually it threw this exception:
> >>>>>
> >>>>> appJVM[ERROR] Feb 24, 2017 7:15:45 PM org.xnio.ChannelListeners
> >>>>> invokeChannelListener
> >>>>> appJVM[ERROR] ERROR: XNIO001007: A channel event listener threw an
> >>>>> exception
> >>>>> appJVM[ERROR] java.lang.IllegalStateException
> >>>>> appJVM[ERROR]   at
> >>>>>
> io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.getBuffer(AbstractFramedStreamSinkChannel.java:574)
> >>>>> appJVM[ERROR]   at
> >>>>>
> io.undertow.server.protocol.framed.AbstractFramedChannel.flushSenders(AbstractFramedChannel.java:629)
> >>>>> appJVM[ERROR]   at
> >>>>>
> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameWriteListener.handleEvent(AbstractFramedChannel.java:951)
> >>>>> appJVM[ERROR]   at
> >>>>>
> io.undertow.server.protocol.framed.AbstractFramedChannel$FrameWriteListener.handleEvent(AbstractFramedChannel.java:948)
> >>>>> appJVM[ERROR]   at
> >>>>>
> org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> >>>>> appJVM[ERROR]   at
> >>>>>
> org.xnio.conduits.WriteReadyHandler$ChannelListenerHandler.writeReady(WriteReadyHandler.java:65)
> >>>>> appJVM[ERROR]   at
> >>>>>
> io.undertow.protocols.ssl.SslConduit$SslWriteReadyHandler.writeReady(SslConduit.java:1225)
> >>>>> appJVM[ERROR]   at
> >>>>> io.undertow.protocols.ssl.SslConduit$3.run(SslConduit.java:275)
> >>>>> appJVM[ERROR]   at
> >>>>> org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580)
> >>>>> appJVM[ERROR]   at
> org.xnio.nio.WorkerThread.run(WorkerThread.java:464)
> >>>>>
> >>>>> I don't know if it's relevant to the problem or not, but at this
> point
> >>>>> I'm just grasping for any straw.
> >>>>>
> >>>>> On Fri, Feb 24, 2017 at 5:18 PM Hicks, Matt <matt at matthicks.com>
> wrote:
> >>>>>>
> >>>>>> 4.) I have three threads "runnable":
> >>>>>>
> >>>>>> "XNIO-1 Accept at 6446" prio=5 tid=0x21 nid=NA runnable
> >>>>>>   java.lang.Thread.State: RUNNABLE
> >>>>>>  at
> sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
> >>>>>>  at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> >>>>>>  at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> >>>>>>  at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> >>>>>>  - locked <merged>(a sun.nio.ch.EPollSelectorImpl)
> >>>>>>  - locked <merged>(a java.util.Collections$UnmodifiableSet)
> >>>>>>  - locked <merged>(a sun.nio.ch.Util$3)
> >>>>>>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> >>>>>>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> >>>>>>  at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
> >>>>>>
> >>>>>> "XNIO-1 I/O-7 at 6448" prio=5 tid=0x1f nid=NA runnable
> >>>>>>   java.lang.Thread.State: RUNNABLE
> >>>>>>  at
> sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
> >>>>>>  at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> >>>>>>  at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> >>>>>>  at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> >>>>>>  - locked <merged>(a sun.nio.ch.EPollSelectorImpl)
> >>>>>>  - locked <merged>(a java.util.Collections$UnmodifiableSet)
> >>>>>>  - locked <merged>(a sun.nio.ch.Util$3)
> >>>>>>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> >>>>>>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> >>>>>>  at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
> >>>>>>
> >>>>>> "XNIO-1 I/O-3 at 6452" prio=5 tid=0x1b nid=NA runnable
> >>>>>>   java.lang.Thread.State: RUNNABLE
> >>>>>>  at
> sun.nio.ch.EPollArrayWrapper.epollWait(EPollArrayWrapper.java:-1)
> >>>>>>  at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> >>>>>>  at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:93)
> >>>>>>  at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
> >>>>>>  - locked <0x1953> (a sun.nio.ch.EPollSelectorImpl)
> >>>>>>  - locked <0x1954> (a java.util.Collections$UnmodifiableSet)
> >>>>>>  - locked <0x1955> (a sun.nio.ch.Util$3)
> >>>>>>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
> >>>>>>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
> >>>>>>  at org.xnio.nio.WorkerThread.run(WorkerThread.java:509)
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Feb 24, 2017 at 5:15 PM Hicks, Matt <matt at matthicks.com>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> 1.) I was running 1.4.10.Final, but I upgraded to 1.4.11.Final
> hoping
> >>>>>>> it was a bug that was fixed, but it didn't make any difference.
> >>>>>>> 2.) Yes
> >>>>>>> 3.) No, of the 8 virtual CPUs none of them are maxed out.
> >>>>>>> 4.) I'll have to get back to you...
> >>>>>>>
> >>>>>>> On Fri, Feb 24, 2017 at 5:10 PM Stuart Douglas <
> sdouglas at redhat.com>
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> - What version of Undertow?
> >>>>>>>> - Is SSL in use?
> >>>>>>>> - Does the server enter some kind of spin loop (i.e. 100% CPU
> >>>>>>>> usage)?
> >>>>>>>> - What does the stack trace look like when this happens?
> >>>>>>>>
> >>>>>>>> Stuart
> >>>>>>>>
> >>>>>>>> On Sat, Feb 25, 2017 at 9:14 AM, Hicks, Matt <matt at matthicks.com>
> >>>>>>>> wrote:
> >>>>>>>> > 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?
> >>>>>>>> >
> >>>>>>>> > _______________________________________________
> >>>>>>>> > undertow-dev mailing list
> >>>>>>>> > undertow-dev at lists.jboss.org
> >>>>>>>> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> undertow-dev mailing list
> >>>> undertow-dev at lists.jboss.org
> >>>> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >>>
> >>>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170227/32de1906/attachment.html 

From sdouglas at redhat.com  Mon Feb 27 15:16:18 2017
From: sdouglas at redhat.com (Stuart Douglas)
Date: Tue, 28 Feb 2017 07:16:18 +1100
Subject: [undertow-dev] Tracing HTTP Response content
In-Reply-To: <CALCKA0rzN3XOuwePQVqtfyt5-9enbeht0HRXkV5NY7x7RNxA2Q@mail.gmail.com>
References: <CALCKA0oUj0entvpKDpeds66U88Wc3z9bAg_21f_+001vF-UDOA@mail.gmail.com>
	<CAD+L2cwH_7csDG9V9_=zmr9hX1uV1Gbp4aU7yCNWG5Pzm-ZG3w@mail.gmail.com>
	<CALCKA0ogd15BCZAFXtkeZD1a1+wEy0gk5s2k307Qep3xb2J3Fw@mail.gmail.com>
	<CAD+L2czM=JRXEMo=MeXXm+p=A9eZbKDrxYxugLA_KW03NmsWQA@mail.gmail.com>
	<CALCKA0rzN3XOuwePQVqtfyt5-9enbeht0HRXkV5NY7x7RNxA2Q@mail.gmail.com>
Message-ID: <CAD+L2cxfofKRkeAwk7XPD1wWGa6sq5xZ8qG+J=x6_zQ70-7Usg@mail.gmail.com>

You can use the newish
io.undertow.conduits.StoredResponseStreamSinkConduit, however you will
need to be on a very recent version of Undertow (or you can just copy
the code into your project).

It won't be available in ResponseCommitListener though, as this is
called before any content is written. To be honest I am not really
sure what you are trying to do. In general if you can an IOException
when writing the response there is nothing much you can do other than
terminate the connection.

Stuart

On Tue, Feb 28, 2017 at 12:43 AM, Rohan Emmanuel
<rohan.emmanuel07 at gmail.com> wrote:
> Hi Stuart,
>
> i am new to Undertow code, Can you please elaborate.
>
> yes, The exchange will be passed to the ResponseCommitListener, but From
> exchange i cannot get the response content directly ,correct? as there is no
> method to get the Response body like getResponseHeaders.
>
> so i would need something like  a conduit inside my ResponseCommitListener
> to get a handle on the response content?
> Any other straight forward way to get the response content using exchange
> object?
>
> Thanks for all the help.
>
>
> On Mon, Feb 27, 2017 at 3:50 PM, Stuart Douglas <sdouglas at redhat.com> wrote:
>>
>> You have access to the exchange, it is passed into the
>> ResponseCommitListener.
>>
>> Stuart
>>
>> On Mon, Feb 27, 2017 at 4:25 PM, Rohan Emmanuel
>> <rohan.emmanuel07 at gmail.com> wrote:
>> > hi Stuart,
>> > I have a ResponseCommitListener added to my handler, I want this to
>> > write to
>> > the cache, so that my reponseWrapper will take of the error handling if
>> > the
>> > ResponsecommitListener faces any error while storing the response to
>> > cache.
>> >
>> > I understand HttpResponseConduit constructs the headers and then pushes
>> > the
>> > response.
>> > But the confusion is, how will i get a access to response Headers and
>> > body
>> > in the my ResponseCommitListener?
>> >
>> >
>> > My approach is valid? if not ,any suggestion?
>> >
>> >
>> > On Mon, Feb 27, 2017 at 8:03 AM, Stuart Douglas <sdouglas at redhat.com>
>> > wrote:
>> >>
>> >> Whatever code is writing to the cache needs to just hold onto the
>> >> exchange and send an error response as required.
>> >>
>> >> Stuart
>> >>
>> >> On Fri, Feb 24, 2017 at 5:31 PM, Rohan Emmanuel
>> >> <rohan.emmanuel07 at gmail.com> wrote:
>> >> > 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
>> >> >
>> >> > _______________________________________________
>> >> > undertow-dev mailing list
>> >> > undertow-dev at lists.jboss.org
>> >> > https://lists.jboss.org/mailman/listinfo/undertow-dev
>> >> _______________________________________________
>> >> undertow-dev mailing list
>> >> undertow-dev at lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/undertow-dev
>> >
>> >
>> >
>> >
>> > --
>> > Regards,
>> > Rohan Emmanuel
>> _______________________________________________
>> undertow-dev mailing list
>> undertow-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/undertow-dev
>
>
>
>
> --
> Regards,
> Rohan Emmanuel

From rohan.emmanuel07 at gmail.com  Tue Feb 28 01:18:15 2017
From: rohan.emmanuel07 at gmail.com (Rohan Emmanuel)
Date: Tue, 28 Feb 2017 11:48:15 +0530
Subject: [undertow-dev] Tracing HTTP Response content
In-Reply-To: <CAD+L2cxfofKRkeAwk7XPD1wWGa6sq5xZ8qG+J=x6_zQ70-7Usg@mail.gmail.com>
References: <CALCKA0oUj0entvpKDpeds66U88Wc3z9bAg_21f_+001vF-UDOA@mail.gmail.com>
	<CAD+L2cwH_7csDG9V9_=zmr9hX1uV1Gbp4aU7yCNWG5Pzm-ZG3w@mail.gmail.com>
	<CALCKA0ogd15BCZAFXtkeZD1a1+wEy0gk5s2k307Qep3xb2J3Fw@mail.gmail.com>
	<CAD+L2czM=JRXEMo=MeXXm+p=A9eZbKDrxYxugLA_KW03NmsWQA@mail.gmail.com>
	<CALCKA0rzN3XOuwePQVqtfyt5-9enbeht0HRXkV5NY7x7RNxA2Q@mail.gmail.com>
	<CAD+L2cxfofKRkeAwk7XPD1wWGa6sq5xZ8qG+J=x6_zQ70-7Usg@mail.gmail.com>
Message-ID: <CALCKA0rsz=9A-+ioFG1pb1r0WkbW-meN+hrMxkQDF8p8x90viw@mail.gmail.com>

Thanks for suggestion.

To put it into simple terms ,what i am trying to do is,
a). I want to store all the response(headers+body) into cache,
     i.)if this is successful ,then begin writing the response to client.
     ii.)if store to cache fails, then write failure message(maybe 500
error message) to client.
b.) if while writing the response(failure message or success actual
response) to client there is an IO exception, then Undertow already has the
mechanism of terminating the connection, which is fine.

basically, i want to store the entire response to the cache before the
first byte is written on the socket.

Ultimately, The Cache will contain all the responses which are processed
successfully, which can be used for book-keeping.


Will StoredResponseStreamSinckConduit help me achieve the above?




On Tue, Feb 28, 2017 at 1:46 AM, Stuart Douglas <sdouglas at redhat.com> wrote:

> You can use the newish
> io.undertow.conduits.StoredResponseStreamSinkConduit, however you will
> need to be on a very recent version of Undertow (or you can just copy
> the code into your project).
>
> It won't be available in ResponseCommitListener though, as this is
> called before any content is written. To be honest I am not really
> sure what you are trying to do. In general if you can an IOException
> when writing the response there is nothing much you can do other than
> terminate the connection.
>
> Stuart
>
> On Tue, Feb 28, 2017 at 12:43 AM, Rohan Emmanuel
> <rohan.emmanuel07 at gmail.com> wrote:
> > Hi Stuart,
> >
> > i am new to Undertow code, Can you please elaborate.
> >
> > yes, The exchange will be passed to the ResponseCommitListener, but From
> > exchange i cannot get the response content directly ,correct? as there
> is no
> > method to get the Response body like getResponseHeaders.
> >
> > so i would need something like  a conduit inside my
> ResponseCommitListener
> > to get a handle on the response content?
> > Any other straight forward way to get the response content using exchange
> > object?
> >
> > Thanks for all the help.
> >
> >
> > On Mon, Feb 27, 2017 at 3:50 PM, Stuart Douglas <sdouglas at redhat.com>
> wrote:
> >>
> >> You have access to the exchange, it is passed into the
> >> ResponseCommitListener.
> >>
> >> Stuart
> >>
> >> On Mon, Feb 27, 2017 at 4:25 PM, Rohan Emmanuel
> >> <rohan.emmanuel07 at gmail.com> wrote:
> >> > hi Stuart,
> >> > I have a ResponseCommitListener added to my handler, I want this to
> >> > write to
> >> > the cache, so that my reponseWrapper will take of the error handling
> if
> >> > the
> >> > ResponsecommitListener faces any error while storing the response to
> >> > cache.
> >> >
> >> > I understand HttpResponseConduit constructs the headers and then
> pushes
> >> > the
> >> > response.
> >> > But the confusion is, how will i get a access to response Headers and
> >> > body
> >> > in the my ResponseCommitListener?
> >> >
> >> >
> >> > My approach is valid? if not ,any suggestion?
> >> >
> >> >
> >> > On Mon, Feb 27, 2017 at 8:03 AM, Stuart Douglas <sdouglas at redhat.com>
> >> > wrote:
> >> >>
> >> >> Whatever code is writing to the cache needs to just hold onto the
> >> >> exchange and send an error response as required.
> >> >>
> >> >> Stuart
> >> >>
> >> >> On Fri, Feb 24, 2017 at 5:31 PM, Rohan Emmanuel
> >> >> <rohan.emmanuel07 at gmail.com> wrote:
> >> >> > 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
> >> >> >
> >> >> > _______________________________________________
> >> >> > undertow-dev mailing list
> >> >> > undertow-dev at lists.jboss.org
> >> >> > https://lists.jboss.org/mailman/listinfo/undertow-dev
> >> >> _______________________________________________
> >> >> undertow-dev mailing list
> >> >> undertow-dev at lists.jboss.org
> >> >> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Regards,
> >> > Rohan Emmanuel
> >> _______________________________________________
> >> undertow-dev mailing list
> >> undertow-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/undertow-dev
> >
> >
> >
> >
> > --
> > Regards,
> > Rohan Emmanuel
>



-- 
Regards,
Rohan Emmanuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20170228/f33be3a7/attachment.html