Ernest Friedman-Hill wrote:Can you maybe not use so many file descriptors? Are you closing all your socket, streams, files, etc, as soon as possible after you no longer need them?
Yes I do.
Now I got a temporary fix.
I am setting when ever I'm starting the server in the server startup script. ulimit -n 65536
I used below program and checked the open file limit and saw that thought ulimit -aH shows 65536 its able to open only 1020 number of files after that it gives a openfile error but once i put ulimit -n 65536 and run the program it open 65535 number of file with out problem. I dont know why this weird stuff comming but for now I added it in my startup script.
I tried to answer a couple of days back and the server sent it to Coventry. Let me try again.
My ex-boss and I had been persuaded that Java "automatic garbage collection meant that you didn't need to explicitly close files. After doing a thorough post-mortem on a frequent blow-up, we were horrified to learn otherwise. I had to go back in and explicitly close things - and add "finally" clauses so that open files wouldn't leak when exceptions were thrown.
There's some confusion on what to close and when, however, since In Java, you can build one file construct on top of another - especially with streams. In the case of a jdbc Statement, the Statement close() will cascade to all of its ResultSets, so I normally only close ResultSets when I need to free up resources while still keeping the Statement. In the case of things like a PrintWriter build on a FileOutputStream, I never really worked out the rules, other than it's always a good idea to explicitly flush.
Keeping lots of files/network connections open is expensive. It's not something you should do frivolously, and you should be very careful that if you intended to do so for performance reasons that you're not causing more problems than you solve. There are reasons to do so - like when you're a database. But it's not something to do without careful planing.
An IDE is no substitute for an Intelligent Developer.