From scrapmachines at gmail.com Tue Jun 5 10:44:28 2018 From: scrapmachines at gmail.com (Girish Sharma) Date: Tue, 5 Jun 2018 20:14:28 +0530 Subject: [undertow-dev] When to call HttpServerExchange#endExchange explicitly? Message-ID: Hi there, I was wondering when to call the endExchange method on the exchange manually? Is it required to call it if we have called startBlocking() on the exchange? How is the getResponseSender().sen("SOME TEXT") behavior if we call endExchange() with and without a prior startBlocking() call *tldr;* I have been using Undertow for a while now. We were originally only using request parameters from the incoming request and thus, we never had to start the blocking exchange. Recently we started consuming the payload of a POST call and thus, we started blocking the exchange. Post this we observed memory leaks. While we were trying to figure out the cause of the memory leaks, we made a few changes. While the memory leaks got fixes, we started observing incomplete responses from some of the API. Basically, the exchange was being ended before the async, multi part, response was completely sent off. While trying to fix the issue, should I completely remove the explicit endExchange call or leave it there for the startBlocking() branch of code and only remove for non blocking exchange? Regards -- Girish Sharma -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20180605/db1edd73/attachment-0001.html From sdouglas at redhat.com Tue Jun 5 22:56:12 2018 From: sdouglas at redhat.com (Stuart Douglas) Date: Wed, 6 Jun 2018 12:56:12 +1000 Subject: [undertow-dev] When to call HttpServerExchange#endExchange explicitly? In-Reply-To: References: Message-ID: If is basically just an convenience method that will close both the request and the response for you, so you never *have* to call it. It also has nothing to do with blocking exchanges, it will do the same thing either way. >From your TLDR it sounds like you are doing something wrong thread safety wise. In particular it sounds like you may not be using dispatch() correctly to make sure that only one thread 'owns' the exchange at a time. Stuart On Wed, Jun 6, 2018 at 12:44 AM, Girish Sharma wrote: > Hi there, > > I was wondering when to call the endExchange method on the exchange > manually? Is it required to call it if we have called startBlocking() on > the exchange? > > How is the getResponseSender().sen("SOME TEXT") behavior if we call > endExchange() with and without a prior startBlocking() call > > *tldr;* > I have been using Undertow for a while now. We were originally only using > request parameters from the incoming request and thus, we never had to > start the blocking exchange. Recently we started consuming the payload of a > POST call and thus, we started blocking the exchange. Post this we observed > memory leaks. While we were trying to figure out the cause of the memory > leaks, we made a few changes. While the memory leaks got fixes, we started > observing incomplete responses from some of the API. Basically, the > exchange was being ended before the async, multi part, response was > completely sent off. While trying to fix the issue, should I completely > remove the explicit endExchange call or leave it there for the > startBlocking() branch of code and only remove for non blocking exchange? > > Regards > -- > Girish Sharma > > _______________________________________________ > 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/20180606/e3bd115e/attachment.html From scrapmachines at gmail.com Wed Jun 6 10:29:15 2018 From: scrapmachines at gmail.com (Girish Sharma) Date: Wed, 6 Jun 2018 19:59:15 +0530 Subject: [undertow-dev] When to call HttpServerExchange#endExchange explicitly? In-Reply-To: References:

Message-ID: (Forgot to reply all) One correction in my previous mail. The issue (connection being closed before response is transferred fully) caused by calling endExchange only happens in non-blocking exchange calls. In case exchange.startBlocking is called, then the issue is not reproducible with or without endExchange call. Regards On Wed, Jun 6, 2018 at 6:27 PM Girish Sharma wrote: > Thanks for the response, Stuart. Based on your reply with respect to > endExchange, it looks like it should not be cause of any incomplete > response issue. > > With respect to thread safety and exchange, the exchange is always handled > in a single thread. The only thing we do to exchange is the following > (apart from reading/writing headers): > > public void handleRequest(HttpServerExchange exchange) throws Exception { >> if (exchange.isInIoThread()) { >> exchange.dispatch(this); >> return; >> } >> >> // and then later on (with or without calling exchange.startBlocking() ): >> >> exchange.getResponseSender().send(response.toString()); >> >> > Also, I have personally verified that without the explicit endExchange call, the full response is rendered with 100% certainty. While using the endExchange, the connection exits early sometimes. > > > On Wed, Jun 6, 2018 at 8:26 AM Stuart Douglas wrote: > >> If is basically just an convenience method that will close both the >> request and the response for you, so you never *have* to call it. It also >> has nothing to do with blocking exchanges, it will do the same thing either >> way. >> >> From your TLDR it sounds like you are doing something wrong thread safety >> wise. In particular it sounds like you may not be using dispatch() >> correctly to make sure that only one thread 'owns' the exchange at a time. >> >> Stuart >> >> >> On Wed, Jun 6, 2018 at 12:44 AM, Girish Sharma >> wrote: >> >>> Hi there, >>> >>> I was wondering when to call the endExchange method on the exchange >>> manually? Is it required to call it if we have called startBlocking() on >>> the exchange? >>> >>> How is the getResponseSender().sen("SOME TEXT") behavior if we call >>> endExchange() with and without a prior startBlocking() call >>> >>> *tldr;* >>> I have been using Undertow for a while now. We were originally only >>> using request parameters from the incoming request and thus, we never had >>> to start the blocking exchange. Recently we started consuming the payload >>> of a POST call and thus, we started blocking the exchange. Post this we >>> observed memory leaks. While we were trying to figure out the cause of the >>> memory leaks, we made a few changes. While the memory leaks got fixes, we >>> started observing incomplete responses from some of the API. Basically, the >>> exchange was being ended before the async, multi part, response was >>> completely sent off. While trying to fix the issue, should I completely >>> remove the explicit endExchange call or leave it there for the >>> startBlocking() branch of code and only remove for non blocking exchange? >>> >>> Regards >>> -- >>> Girish Sharma >>> >>> _______________________________________________ >>> undertow-dev mailing list >>> undertow-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>> >> >> > > -- > Girish Sharma > B.Tech(H), Civil Engineering, > Indian Institute of Technology, Kharagpur > -- Girish Sharma B.Tech(H), Civil Engineering, Indian Institute of Technology, Kharagpur -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20180606/5bf8e192/attachment.html From sdouglas at redhat.com Wed Jun 6 21:50:44 2018 From: sdouglas at redhat.com (Stuart Douglas) Date: Thu, 7 Jun 2018 08:50:44 +0700 Subject: [undertow-dev] When to call HttpServerExchange#endExchange explicitly? In-Reply-To: References:

Message-ID: That is expected. For asynchronous io send() is not guaranteed to have finished sending by the time it returns, if you want to do more processing after calling send() you need to provide a callback. If no callback is supplied then endExchange will be called automatically when sending is complete. Stuart On Wed, 6 Jun. 2018, 9:29 pm Girish Sharma, wrote: > (Forgot to reply all) > > One correction in my previous mail. The issue (connection being closed > before response is transferred fully) caused by calling endExchange only > happens in non-blocking exchange calls. In case exchange.startBlocking is > called, then the issue is not reproducible with or without endExchange call. > > Regards > > On Wed, Jun 6, 2018 at 6:27 PM Girish Sharma > wrote: > >> Thanks for the response, Stuart. Based on your reply with respect to >> endExchange, it looks like it should not be cause of any incomplete >> response issue. >> >> With respect to thread safety and exchange, the exchange is always >> handled in a single thread. The only thing we do to exchange is the >> following (apart from reading/writing headers): >> >> public void handleRequest(HttpServerExchange exchange) throws Exception { >>> if (exchange.isInIoThread()) { >>> exchange.dispatch(this); >>> return; >>> } >>> >>> // and then later on (with or without calling exchange.startBlocking() ): >>> >>> exchange.getResponseSender().send(response.toString()); >>> >>> >> Also, I have personally verified that without the explicit endExchange call, the full response is rendered with 100% certainty. While using the endExchange, the connection exits early sometimes. >> >> >> On Wed, Jun 6, 2018 at 8:26 AM Stuart Douglas >> wrote: >> >>> If is basically just an convenience method that will close both the >>> request and the response for you, so you never *have* to call it. It also >>> has nothing to do with blocking exchanges, it will do the same thing either >>> way. >>> >>> From your TLDR it sounds like you are doing something wrong thread >>> safety wise. In particular it sounds like you may not be using dispatch() >>> correctly to make sure that only one thread 'owns' the exchange at a time. >>> >>> Stuart >>> >>> >>> On Wed, Jun 6, 2018 at 12:44 AM, Girish Sharma >>> wrote: >>> >>>> Hi there, >>>> >>>> I was wondering when to call the endExchange method on the exchange >>>> manually? Is it required to call it if we have called startBlocking() on >>>> the exchange? >>>> >>>> How is the getResponseSender().sen("SOME TEXT") behavior if we call >>>> endExchange() with and without a prior startBlocking() call >>>> >>>> *tldr;* >>>> I have been using Undertow for a while now. We were originally only >>>> using request parameters from the incoming request and thus, we never had >>>> to start the blocking exchange. Recently we started consuming the payload >>>> of a POST call and thus, we started blocking the exchange. Post this we >>>> observed memory leaks. While we were trying to figure out the cause of the >>>> memory leaks, we made a few changes. While the memory leaks got fixes, we >>>> started observing incomplete responses from some of the API. Basically, the >>>> exchange was being ended before the async, multi part, response was >>>> completely sent off. While trying to fix the issue, should I completely >>>> remove the explicit endExchange call or leave it there for the >>>> startBlocking() branch of code and only remove for non blocking exchange? >>>> >>>> Regards >>>> -- >>>> Girish Sharma >>>> >>>> _______________________________________________ >>>> undertow-dev mailing list >>>> undertow-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>>> >>> >>> >> >> -- >> Girish Sharma >> B.Tech(H), Civil Engineering, >> Indian Institute of Technology, Kharagpur >> > > > -- > Girish Sharma > B.Tech(H), Civil Engineering, > Indian Institute of Technology, Kharagpur > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20180607/ac346251/attachment-0001.html From scrapmachines at gmail.com Thu Jun 7 08:59:36 2018 From: scrapmachines at gmail.com (Girish Sharma) Date: Thu, 7 Jun 2018 18:29:36 +0530 Subject: [undertow-dev] When to call HttpServerExchange#endExchange explicitly? In-Reply-To: References:

Message-ID: Cool, thanks! It makes sense. On Thu, Jun 7, 2018 at 7:20 AM Stuart Douglas wrote: > That is expected. For asynchronous io send() is not guaranteed to have > finished sending by the time it returns, if you want to do more processing > after calling send() you need to provide a callback. > > If no callback is supplied then endExchange will be called automatically > when sending is complete. > > Stuart > > On Wed, 6 Jun. 2018, 9:29 pm Girish Sharma, > wrote: > >> (Forgot to reply all) >> >> One correction in my previous mail. The issue (connection being closed >> before response is transferred fully) caused by calling endExchange only >> happens in non-blocking exchange calls. In case exchange.startBlocking is >> called, then the issue is not reproducible with or without endExchange call. >> >> Regards >> >> On Wed, Jun 6, 2018 at 6:27 PM Girish Sharma >> wrote: >> >>> Thanks for the response, Stuart. Based on your reply with respect to >>> endExchange, it looks like it should not be cause of any incomplete >>> response issue. >>> >>> With respect to thread safety and exchange, the exchange is always >>> handled in a single thread. The only thing we do to exchange is the >>> following (apart from reading/writing headers): >>> >>> public void handleRequest(HttpServerExchange exchange) throws Exception { >>>> if (exchange.isInIoThread()) { >>>> exchange.dispatch(this); >>>> return; >>>> } >>>> >>>> // and then later on (with or without calling exchange.startBlocking() ): >>>> >>>> exchange.getResponseSender().send(response.toString()); >>>> >>>> >>> Also, I have personally verified that without the explicit endExchange call, the full response is rendered with 100% certainty. While using the endExchange, the connection exits early sometimes. >>> >>> >>> On Wed, Jun 6, 2018 at 8:26 AM Stuart Douglas >>> wrote: >>> >>>> If is basically just an convenience method that will close both the >>>> request and the response for you, so you never *have* to call it. It also >>>> has nothing to do with blocking exchanges, it will do the same thing either >>>> way. >>>> >>>> From your TLDR it sounds like you are doing something wrong thread >>>> safety wise. In particular it sounds like you may not be using dispatch() >>>> correctly to make sure that only one thread 'owns' the exchange at a time. >>>> >>>> Stuart >>>> >>>> >>>> On Wed, Jun 6, 2018 at 12:44 AM, Girish Sharma >>> > wrote: >>>> >>>>> Hi there, >>>>> >>>>> I was wondering when to call the endExchange method on the exchange >>>>> manually? Is it required to call it if we have called startBlocking() on >>>>> the exchange? >>>>> >>>>> How is the getResponseSender().sen("SOME TEXT") behavior if we call >>>>> endExchange() with and without a prior startBlocking() call >>>>> >>>>> *tldr;* >>>>> I have been using Undertow for a while now. We were originally only >>>>> using request parameters from the incoming request and thus, we never had >>>>> to start the blocking exchange. Recently we started consuming the payload >>>>> of a POST call and thus, we started blocking the exchange. Post this we >>>>> observed memory leaks. While we were trying to figure out the cause of the >>>>> memory leaks, we made a few changes. While the memory leaks got fixes, we >>>>> started observing incomplete responses from some of the API. Basically, the >>>>> exchange was being ended before the async, multi part, response was >>>>> completely sent off. While trying to fix the issue, should I completely >>>>> remove the explicit endExchange call or leave it there for the >>>>> startBlocking() branch of code and only remove for non blocking exchange? >>>>> >>>>> Regards >>>>> -- >>>>> Girish Sharma >>>>> >>>>> _______________________________________________ >>>>> undertow-dev mailing list >>>>> undertow-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/undertow-dev >>>>> >>>> >>>> >>> >>> -- >>> Girish Sharma >>> B.Tech(H), Civil Engineering, >>> Indian Institute of Technology, Kharagpur >>> >> >> >> -- >> Girish Sharma >> B.Tech(H), Civil Engineering, >> Indian Institute of Technology, Kharagpur >> > -- Girish Sharma B.Tech(H), Civil Engineering, Indian Institute of Technology, Kharagpur -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/undertow-dev/attachments/20180607/671c6c56/attachment.html From marc.boorshtein at tremolosecurity.com Fri Jun 22 13:23:26 2018 From: marc.boorshtein at tremolosecurity.com (Marc Boorshtein) Date: Fri, 22 Jun 2018 13:23:26 -0400 Subject: [undertow-dev] Possible to make context roots case insesnitive? Message-ID: If I create a DepoymentInfo and set the context path, can I make that case-insensitive? I know its possible for the FileManager but i don't see an option on the DeploymentInfo. Thanks Marc