On 03/05/2011 18:07, Filip Hanik - Dev Lists wrote:
> I'm confused about what you are trying to do or achieve. What problems
> are you trying to solve?
> This email thread started with two missing attributes.
> I'd start a new thread describing the problem you are having.
OK. I'll pull out the BIO
On 5/3/2011 10:50 AM, Mark Thomas wrote:
On 21/04/2011 20:21, Mark Thomas wrote:
On 06/04/2011 22:51, Tim Whittington wrote:
On Wed, Apr 6, 2011 at 11:16 PM, Mark Thomas wrote:
On 05/04/2011 10:50, Tim Whittington wrote:
Is what's actually going on more like:
APR: use maxConnections == poll
On 21/04/2011 20:21, Mark Thomas wrote:
> On 06/04/2011 22:51, Tim Whittington wrote:
>> On Wed, Apr 6, 2011 at 11:16 PM, Mark Thomas wrote:
>>> On 05/04/2011 10:50, Tim Whittington wrote:
Is what's actually going on more like:
APR: use maxConnections == pollerSize (smallest will li
On 06/04/2011 22:51, Tim Whittington wrote:
> On Wed, Apr 6, 2011 at 11:16 PM, Mark Thomas wrote:
>> On 05/04/2011 10:50, Tim Whittington wrote:
>>> Is what's actually going on more like:
>>>
>>> APR: use maxConnections == pollerSize (smallest will limit, but if
>>> pollerSize < maxConnections the
On 05/04/2011 09:51, Tim Whittington wrote:
> In the AJP standard implementation docs, the following are not
> mentioned, although they're properties of AbstractEndpoint and
> probably should work:
> - bindOnInit
> - maxConnections
> Am I right in assuming these should be possible in the AJP connec
> 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
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
---
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
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 recycle it until the socket is closed.
> - Increases memory requiremen
On Wed, Apr 6, 2011 at 11:16 PM, Mark Thomas wrote:
> On 05/04/2011 10:50, Tim Whittington wrote:
>> Is what's actually going on more like:
>>
>> APR: use maxConnections == pollerSize (smallest will limit, but if
>> pollerSize < maxConnections then the socket backlog effectively won't
>> be used a
On 05/04/2011 10:50, Tim Whittington wrote:
> Is what's actually going on more like:
>
> APR: use maxConnections == pollerSize (smallest will limit, but if
> pollerSize < maxConnections then the socket backlog effectively won't
> be used as the poller will keep killing connections as they come in)
On 05/04/2011 19:42, Sylvain Laurent wrote:
>
> On 5 avr. 2011, at 11:50, Tim Whittington wrote:
>>
>> HTTP: use maxConnections. For keep alive situations, reduce
>> maxConnections to something closer to maxThreads (the default config
>> is 10,000 keepalive connections serviced by 200 threads with
On 5 avr. 2011, at 11:50, Tim Whittington wrote:
>
> HTTP: use maxConnections. For keep alive situations, reduce
> maxConnections to something closer to maxThreads (the default config
> is 10,000 keepalive connections serviced by 200 threads with a 60
> second keepalive timeout, which could lead
Further to this, the docs for maxConnections currently state:
"This setting is currently only applicable to the blocking Java
connectors (AJP/HTTP)."
But both the NIO and APR connectors use this setting in their Acceptor
implementations, limiting the number of concurrent connections before
they'r
16 matches
Mail list logo
