I am curious to know if this leak is related to unix sockets, or the IPv6
file handles. I have seen a similar issue with the NIO HTTP handler, where
it does not close some connections properly and they incarnate as file
handles corresponding to unix sockets (all pointing to same inode number).
Even
Has a bug been logged for this issue (what seems to be a file descriptor leak)?
On Tue, Jan 3, 2012 at 1:17 PM, Mark Thomas wrote:
> I am trying to bring together all the information I have gleaned on this
> so far from the multiple threads to try and find the common factors.
>
> So far I have:
>
2012/1/7 Mark Thomas :
> On 06/01/2012 20:13, Konstantin Kolinko wrote:
>> 2012/1/6 Mark Thomas :
So it looks that not only the if(), but the whole r944518 change in
AprEndpoint has to be reverted.
>>>
>>> That looks OK to me. I'll do that but run the TCKs as a double check.
>>>
>>
>> I a
On 06/01/2012 20:13, Konstantin Kolinko wrote:
> 2012/1/6 Mark Thomas :
>>> So it looks that not only the if(), but the whole r944518 change in
>>> AprEndpoint has to be reverted.
>>
>> That looks OK to me. I'll do that but run the TCKs as a double check.
>>
>
> I am running TestCometProcessor tes
2012/1/6 Mark Thomas :
>> So it looks that not only the if(), but the whole r944518 change in
>> AprEndpoint has to be reverted.
>
> That looks OK to me. I'll do that but run the TCKs as a double check.
>
I am running TestCometProcessor tests with this very change just now. ;)
(My plan is to reen
On 04/01/2012 13:59, Konstantin Kolinko wrote:
> 2012/1/4 Konstantin Kolinko :
>>
>> 2. The
>> processSocket(desc[n*2+1], SocketStatus.DISCONNECT);
>> call just above the fixed line.
>>
>> It looks like a NOOP, because processSocket(long,SocketStatus) has an
>> if() that does not mention SocketStat
On Tue, Jan 3, 2012 at 1:17 PM, Mark Thomas wrote:
> I am trying to bring together all the information I have gleaned on this
> so far from the multiple threads to try and find the common factors.
>
> So far I have:
> - 7.0.21 is OK
> - 7.0.22 has an fd leak
> - 7.0.23 has an fd leak and may leak
2012/1/4 Konstantin Kolinko :
>
> 2. The
> processSocket(desc[n*2+1], SocketStatus.DISCONNECT);
> call just above the fixed line.
>
> It looks like a NOOP, because processSocket(long,SocketStatus) has an
> if() that does not mention SocketStatus.DISCONNECT.
>
> I think it is one more way to leak so
2012/1/4 Mark Thomas :
> On 03/01/2012 21:32, Mark Thomas wrote:
>> On 03/01/2012 21:26, André Warnier wrote:
>>> Mark Thomas wrote:
I am trying to bring together all the information I have gleaned on this
so far from the multiple threads to try and find the common factors.
>>
>>
>>
>>>
On 03/01/2012 21:32, Mark Thomas wrote:
> On 03/01/2012 21:26, André Warnier wrote:
>> Mark Thomas wrote:
>>> I am trying to bring together all the information I have gleaned on this
>>> so far from the multiple threads to try and find the common factors.
>
>
>
>> Suggestion: the "large POST req
On 03/01/2012 21:26, André Warnier wrote:
> Mark Thomas wrote:
>> I am trying to bring together all the information I have gleaned on this
>> so far from the multiple threads to try and find the common factors.
> Suggestion: the "large POST requests" mentioned by a couple of posters
> suggest fi
Mark Thomas wrote:
I am trying to bring together all the information I have gleaned on this
so far from the multiple threads to try and find the common factors.
So far I have:
- 7.0.21 is OK
- 7.0.22 has an fd leak
- 7.0.23 has an fd leak and may leak faster than 7.0.22
- occurs with APR/native
I am trying to bring together all the information I have gleaned on this
so far from the multiple threads to try and find the common factors.
So far I have:
- 7.0.21 is OK
- 7.0.22 has an fd leak
- 7.0.23 has an fd leak and may leak faster than 7.0.22
- occurs with APR/native
- does not occur with
13 matches
Mail list logo
