|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
On a later test when the client was available again, I did more debugging.
At initial launch, the problem occurred within a minute. Too quick. No chance that many sockets had been made yet. I did a heap dump with VisualVM, and looked at it. Only 36 sockets in memory. But I was already getting socket closed exceptions. Heap wasn't "full" either...14MB in use.
This error only occurs on OSX Java 7. When I changed to Java 6, it worked, no socket closed exceptions, and apparently is continuing to work as the client has not complained yet...
No one using Windows has complained about this either...OS X Java 7 is the first time this scenario has come up.
So it can't be too many sockets...the other lsof listing showing 240 sockets was from a longer running instance when it had occurred. But since we made it occur right at app launch basically, its not related to timing or amount of sockets used.
I also thought that the limit -n doesn't apply to Java? The "sysctl -a | grep files" was what is affecting java I thought...no? The java app has 4300 open file handles (intentionally). So that is more than 256...
This isn't new code either, so I am quite confident the sockets are being closed as I have disconnect routines in all my finally clauses around the socket usage. But if there were too many sockets (which I have seen when I have a leak), then the issue is too many files open, and everything starts failing. In this case everything seems fine, except network connections with sockets using direct sockets, or HTTPUrlConnections.
I also saw in the java console of the jblp file that it was getting exceptions for its RMI while I had VisualVM attached.
WARNING: RMI TCP Accept-0: accept loop for ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=51074] throws java.net.SocketException: Socket closed at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:398) at java.net.ServerSocket.implAccept(ServerSocket.java:522) at java.net.ServerSocket.accept(ServerSocket.java:490) at sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(LocalRMIServerSocketFactory.java:52) at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:387) at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:359) at java.lang.Thread.run(Thread.java:722)
So that shows this isn't anything related to connecting outbound even as it was unable to accept a socket.
So I am thinking this is more of a OSX Java 7 bug...
So for now my only solution is to use Java 6...but how do I identify this bug and get something filed? This seems like a fairly easy DOS attack vector of getting a server too full on handles and then everything shuts down. For me, my product can't function at all in Java 7, and with Apple killing off Java 6 on everyones machine whether they wanted that done or not, its quite a pain to work around using java6 launch methods.
On Jun 5, 2013, at 4:22 AM, Moises Lejter <email@hidden> wrote:
_______________________________________________ Do not post admin requests to the list. They will be ignored. Java-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
|>Re: Java7 Socket Closed Exception (From: Ben Spink <email@hidden>)|
|>Re: Java7 Socket Closed Exception (From: Moises Lejter <email@hidden>)|
Visit the Apple Store online or at retail locations.
Copyright © 2011 Apple Inc. All rights reserved.