On Mon, 2010-11-01 at 13:25 -0700, swatkatz wrote:
> We are using HttpCore 4.0.1
>
> Also in particular in DefaultConnectingIOReactor -
>
> SocketChannel socketChannel;
> try {
> socketChannel = SocketChannel.open();
> socketChannel.configureBlocking(f
gt;
> Oleg
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org
> For additional commands, e-mail: dev-h...@hc.apache.org
>
>
>
--
View this message in context:
http:
On Mon, 2010-11-01 at 13:13 -0700, swatkatz wrote:
> It looks like we can consistently reproduce this whenever there is a failed
> connection. There seems to be a file descriptor leak everytime there is a
> failed connection.
>
> We registered a SessionRequestCallback and each time public void
> f
; >
>>>> >> To be safe, I think
>>>> >> we need to close every registered SelectorKey and then call
>>>> >> selector.selectNow() to flush them. Then we can create a new
>>>> >> SelectorKey for each and reregister them. The only
to close every registered SelectorKey and then call
>>> >> selector.selectNow() to flush them. Then we can create a new
>>> >> SelectorKey for each and reregister them. The only way to make it less
>>> >> common, I think, is to use a long selectTimeout value so
think, is to use a long selectTimeout value so that the odds
>> >> of a timeout are low. Ugly, but I hope it will work.
>> >>
>> >
>> > This will unfortunately screw up handling of new / closed channels as
>> > well timeout logic.
>> >
>> > The work-around looks butt ugly and would re
Is that the original 1.6.0 release? I thought all later releases had a
version number of the form 1.6.0_xx, where you could tie the 'xx' to a minor
update listed here [1].
Cheers,
James
[1] http://www.oracle.com/technetwork/java/javase/releasenotes-136954.html
On 3 August 2010 06:00, Supun Kamb
Hi Harold,
We are having the same problem and we are interested to know how you get
this exact Java version. Is there a link to this particular Java version?
Thanks,
Supun..
On Tue, Aug 3, 2010 at 1:57 AM, Harold Lee wrote:
> This seems to be fixed by a newer version of the JRE, i.e.
>
> java
This seems to be fixed by a newer version of the JRE, i.e.
java version "1.6.0"
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0-b105, mixed mode)
So I think that you can avoid the tricky workaround. Thank you for
your time and attention.
Harold
On Thu, 2010-07-15 at 12:50 -0700, Harold Lee wrote:
> I've put together a simple HTTP server that resets the connection
> after sending part of the response back to the client. I'm going to
> try to recreate the bug (leaking sockets) by making many requests
> against that server from a Linux box.
I've put together a simple HTTP server that resets the connection
after sending part of the response back to the client. I'm going to
try to recreate the bug (leaking sockets) by making many requests
against that server from a Linux box. I'll let you know what I find.
Harold
On Wed, Jul 14, 2010
On Tue, 2010-07-13 at 13:32 -0700, Harold Lee wrote:
> Regarding this JDK bug:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6403933
>
> I think we are experiencing this using HttpCore on Linux with Java
> 1.6. We wind up leaking socket descriptors until the JVM process runs
> out. We also
Regarding this JDK bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6403933
I think we are experiencing this using HttpCore on Linux with Java
1.6. We wind up leaking socket descriptors until the JVM process runs
out. We also wind up having to start a new reactor thread, which
creates a new
13 matches
Mail list logo
