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
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 connector
(my reading of the code indicates they are - just wa
17 matches
Mail list logo
