|
Replies:
6
-
Last Post:
Jun 24, 2009 8:00 AM
by: Stephen Connolly
|
|
|
|
|
|
|
File Descriptor Leak
Posted:
Nov 4, 2008 9:01 AM
|
|
|
|
|
We have an EJB application running inside a glassfish app server (9.1_02, build b04-fcs) on linux CentOS (5.2). The application consists of a number of stateless session beans and entity beans. Persistence and DB connections are handled via Oracle toplink. The stateless session beans are accessed via remote clients running a swing desktop GUI application (non ACC client).
We have noticed that the glassfish app server process "leaks" file descriptors when the system is being used (i.e., daytime hours). When the app server first starts, it has 250-300 fd's and after about 7 days up time we get up over 1000 fd's. The number of fd's oscillate during light usage times but then climbs dramatically during periods of higher usage.
We've already been down all the usual and obvious trails including looking for unclosed sockets and DB connections in our application. No luck there.
I've attached a dump of the current glassfish file handles in /proc/PID/fd in the attached file (fd.txt). There are a LOT of sockets and fifo's there (over 1400). I've also attached a MS-Excel file which has a plot of the descriptor behavior over a week or so (fdcount.xlsx). Look at "series 3" on the chart. The other two series are other java daemon app's running outside of the glassfish container.
Is there a bug in Glassfish or is there some app server or client config parameter that needs tweaking? Any thoughts would be appreciated.
|
|
|
|
|
|
|
Re: File Descriptor Leak
Posted:
Nov 5, 2008 6:43 AM
in response to: snewbold
|
|
|
Did you add a timeout to your sockets?
If the remote end of a socket *silently* disconnects, your local socket will block indefinitely on a read(...) - a write(...) however will throw an IOException and force the read(...) out of blocking.
So to prevent these runaway sockets, add a timeout.
|
|
|
|
|
|
|
|
|
Re: File Descriptor Leak
Posted:
Nov 5, 2008 11:44 AM
in response to: riven
|
|
|
I can't say anything about the Sockets used in the app server code itself. Which is the main reason for my post.
Our code does use some non-blocking sockets (java.nio.channels package). We do detect when the remote ends just disconnects and we do clean up after ourselves.
We've watched the file descriptor directory as our sockets are created and then destroyed and have been able to prove to ourselves that its not our application sockets causing the leak.
We think the app server is the culprit somewhere down in the "bowels" of the CORBA protocol stack. We're getting ready to try our app on Apache Geronimo to see if its any different.
|
|
|
|
|
|
|
|
|
Re: File Descriptor Leak
Posted:
Apr 19, 2009 10:35 PM
in response to: snewbold
|
|
|
So, what was the end of this ? Did you find the reason for your leak ?
|
|
|
|
|
|
|
|
|
Re: File Descriptor Leak
Posted:
Jun 24, 2009 7:23 AM
in response to: maalov
|
|
|
Yeh...
I also intersting in result.
Any progress?
|
|
|
|
|
|
|
|
|
Re: File Descriptor Leak
Posted:
Jun 24, 2009 8:00 AM
in response to: snewbold
|
|
|
|
|
I'm wondering if this is the great
FileUrlConnection.getLastModified()
leak?
Or in fact any of the FileUrlConnection related leaks
-Stephen
2008/11/5 <glassfish@javadesktop.org>
> I can't say anything about the Sockets used in the app server code itself.
> Which is the main reason for my post.
>
> Our code does use some non-blocking sockets (java.nio.channels package).
> We do detect when the remote ends just disconnects and we do clean up after
> ourselves.
>
> We've watched the file descriptor directory as our sockets are created and
> then destroyed and have been able to prove to ourselves that its not our
> application sockets causing the leak.
>
> We think the app server is the culprit somewhere down in the "bowels" of
> the CORBA protocol stack. We're getting ready to try our app on Apache
> Geronimo to see if its any different.
> [Message sent by forum member 'snewbold' (snewbold)]
>
> http://forums.java.net/jive/thread.jspa?messageID=315101
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
[att1.html]
|
|
|
|
|
|
|
|
|
Re: File Descriptor Leak
Posted:
Jun 24, 2009 8:00 AM
in response to: Stephen Connolly
|
|
|
|
|
If you switch to an incremental or concurrent garbage collector, do the file
handles get released?
2009/6/24 Stephen Connolly <stephen.alan.connolly@gmail.com>
> I'm wondering if this is the great
>
> FileUrlConnection.getLastModified()
>
> leak?
>
> Or in fact any of the FileUrlConnection related leaks
>
> -Stephen
>
> 2008/11/5 <glassfish@javadesktop.org>
>
> I can't say anything about the Sockets used in the app server code itself.
>> Which is the main reason for my post.
>>
>> Our code does use some non-blocking sockets (java.nio.channels package).
>> We do detect when the remote ends just disconnects and we do clean up after
>> ourselves.
>>
>> We've watched the file descriptor directory as our sockets are created and
>> then destroyed and have been able to prove to ourselves that its not our
>> application sockets causing the leak.
>>
>> We think the app server is the culprit somewhere down in the "bowels" of
>> the CORBA protocol stack. We're getting ready to try our app on Apache
>> Geronimo to see if its any different.
>> [Message sent by forum member 'snewbold' (snewbold)]
>>
>> http://forums.java.net/jive/thread.jspa?messageID=315101
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
>> For additional commands, e-mail: users-help@glassfish.dev.java.net
>>
>>
>
[att1.html]
|
|
|
|
|
java.net RSS
