To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project tomcat-trunk-validate has an issue affecting its community integration.
Th
Author: slaurent
Date: Fri Apr 8 22:12:47 2011
New Revision: 1090470
URL: http://svn.apache.org/viewvc?rev=1090470&view=rev
Log:
proposed backport of bug 50306: Detect stuck threads
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.o
On 8 avr. 2011, at 22:58, Konstantin Kolinko wrote:
>
>> +
>> +50306: New StuckThreadDetectionValve to detect requests
>> that take a
>> +long time to process, which might indicate that their processing
>> threads are
>> +stuck. (slaurent)
>
> "Based on a patch pr
Author: slaurent
Date: Fri Apr 8 22:10:37 2011
New Revision: 1090468
URL: http://svn.apache.org/viewvc?rev=1090468&view=rev
Log:
bug 50306: Detect stuck threads
complement to changelog
Modified:
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/webapps/docs/changelog.xml
URL:
https://issues.apache.org/bugzilla/show_bug.cgi?id=34868
Mark Thomas changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
https://issues.apache.org/bugzilla/show_bug.cgi?id=34805
Mark Thomas changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
https://issues.apache.org/bugzilla/show_bug.cgi?id=34801
Mark Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
Konstantin,
On 4/8/2011 3:56 PM, Konstantin Kolinko wrote:
> This one (combined with yours):
> http://svn.apache.org/viewvc?view=revision&revision=1073393
Aah, I didn't realize that the code I was updating had actually just
been written.
>> but there is only one file to delete in each case:
>
>
2011/4/9 :
> Author: slaurent
> Date: Fri Apr 8 20:51:37 2011
> New Revision: 1090441
>
> URL: http://svn.apache.org/viewvc?rev=1090441&view=rev
> Log:
> changelog for r1090003 / StuckThreadDetectionValve
>
> Modified:
> tomcat/trunk/webapps/docs/changelog.xml
>
> +
> + 50306: Ne
Author: slaurent
Date: Fri Apr 8 20:51:37 2011
New Revision: 1090441
URL: http://svn.apache.org/viewvc?rev=1090441&view=rev
Log:
changelog for r1090003 / StuckThreadDetectionValve
Modified:
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/webapps/docs/changelog.xml
URL:
http:
2011/4/8 Christopher Schultz :
> Konatantin,
>
> On 4/7/2011 9:08 PM, Konstantin Kolinko wrote:
>> 2011/4/8 :
>>> Author: schultz
>>> Date: Fri Apr 8 00:41:29 2011
>>> New Revision: 1090072
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1090072&view=rev
>>> Log:
>>> Updated.
>>>
>>> Modified:
>>>
> Are those buffers ever discarded? I guess it comes down to whether the
> 8k buffer "belongs" to the connection or to the request. It looks like
> the bug arises from the buffer being treated like it belongs to the
> request when it really belongs to the connection.
>
> I agree, switching to a req
On 4/6/2011 3:51 PM, Tim Whittington wrote:
> b) Check the input buffer at the end of the loop in
> Http11Processor#process() and process the next request if there is any
> data in the input buffer.
> - No Increase in memory requirements.
> - Fixes issue 3
> - Pipelined requests will get pr
Tim,
On 4/8/2011 4:50 AM, Tim Whittington wrote:
> On Fri, Apr 8, 2011 at 2:40 AM, Christopher Schultz
> wrote:
>> Mark,
>>
>> I understand that a fix has already been applied, but...
>>
>> On 4/6/2011 7:16 AM, Mark Thomas wrote:
>>> I thought of two options for issue 3:
>>> a) Assign a processor
Konatantin,
On 4/7/2011 9:08 PM, Konstantin Kolinko wrote:
> 2011/4/8 :
>> Author: schultz
>> Date: Fri Apr 8 00:41:29 2011
>> New Revision: 1090072
>>
>> URL: http://svn.apache.org/viewvc?rev=1090072&view=rev
>> Log:
>> Updated.
>>
>> Modified:
>>tomcat/tc6.0.x/trunk/STATUS.txt
>>
>
>> +
>
On 4/8/2011 2:50 AM, Tim Whittington wrote:
The input buffer is 8k by default (max header size), so this could be
significant with a large maxConnections.
significant in 1990 maybe :) even with 20k connections, this be a drop in the
ocean compared to memory usage for today's applications
---
https://issues.apache.org/bugzilla/show_bug.cgi?id=51042
--- Comment #2 from Joachim Sauer 2011-04-08 05:57:14 EDT
---
(In reply to comment #1)
> By the way, the change that introduced this issue was the fix for bug #47774.
Oops, wrong bug number: #45255 is the correct one!
--
Configure bugma
https://issues.apache.org/bugzilla/show_bug.cgi?id=51042
--- Comment #1 from Joachim Sauer 2011-04-08 05:56:27 EDT
---
By the way, the change that introduced this issue was the fix for bug #47774.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are
https://issues.apache.org/bugzilla/show_bug.cgi?id=51042
Summary: HttpSessionListener.sessionCreated() is called a
second time when user is authenticated with no
matching sessionDestroyed() call.
Product: Tomcat 7
Version: 7.
The Http11Protocol and Http11NioProtocol connectors set processorCache
to 200 by default, which matches the docs ([2]).
The Http11AprProtocol sets it to -1 (unlimited) - is this
intentional/desired or accidental?
This appears to have been introduced in [1] during some refactoring by Mladen.
[1] h
On Fri, Apr 8, 2011 at 2:40 AM, Christopher Schultz
wrote:
> Mark,
>
> I understand that a fix has already been applied, but...
>
> On 4/6/2011 7:16 AM, Mark Thomas wrote:
>> I thought of two options for issue 3:
>> a) Assign a processor (+ inputbuffer, output buffer etc.) to a socket
>> and don't
21 matches
Mail list logo
