java.net.SocketException: trop de fichiers ouverts

J’ai une application java qui fonctionne très bien (sous Ubuntu 10.04) pendant quelques heures jusqu’à l’apparition de “java.net.SocketException: trop de fichiers ouverts”. Le code pour Sender.java peut être trouvé ici

Est-ce parce que je crée une nouvelle instance de HttpPut et HttpPost pour chaque thread? J’utilise HTTPClient 4 apache-commons.

Voici le journal des exceptions:

 java.net.SocketException: Too many open files at java.net.Socket.createImpl(Socket.java:414) at java.net.Socket.connect(Socket.java:544) at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:123) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:133) at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149) at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:108) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:415) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:641) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:576) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:554) at com.marketplace.io.Sender.doBasicHttpPost(Sender.java:434) at com.marketplace.io.Sender.appVisualExists(Sender.java:223) at com.marketplace.io.Sender.addVisualToCollection(Sender.java:350) at com.marketplace.service.ImageThread.run(ImageThread.java:136) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) 

Sur la ligne 438, vous obtenez la réponse sous forme de stream et vous la convertissez en tableau d’octets. InputStream renvoyé par entity.getContent () n’est pas fermé. Cela pourrait consortingbuer au problème. En outre, HttpEntity.consumeContent () est obsolète pour des raisons connexes.

“java.net.SocketException: trop de fichiers ouverts” est visible dans toutes les applications Java Server, telles que Tomcat, Weblogic, WebSphere, etc., le client se connectant et se déconnectant fréquemment.

Veuillez noter que les connexions de socket sont traitées comme des fichiers et utilisent un descripteur de fichier, qui est une ressource limitée.

Les systèmes d’exploitation différents ont des limites différentes quant au nombre de descripteurs de fichiers qu’ils peuvent gérer.

En bref, cette erreur survient car les clients se connectent et se déconnectent fréquemment. Si vous souhaitez vous en occuper, vous avez deux options:

1) Augmentez le nombre de descripteurs de fichier ou de descripteurs de fichier ouverts par processus.

Dans les systèmes d’exploitation basés sur UNIX, par exemple Ubuntu ou Solaris, vous pouvez utiliser la commande ulimit -a pour savoir combien de descripteurs de fichiers ouverts sont autorisés par processus.

 $ ulimit -a core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited file size (blocks, -f) unlimited open files (-n) 256 pipe size (512 bytes, -p) 10 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 2048 virtual memory (kbytes, -v) unlimited 

Vous pouvez voir que les fichiers ouverts (-n) 256, ce qui signifie que seuls 256 descripteurs de fichiers ouverts par processus sont autorisés. Si votre programme Java, souvenez-vous de Tomcat, weblogic ou tout autre serveur d’applications sont des programmes Java et qu’ils s’exécutent sur la machine virtuelle Java (JVM), si cette limite est dépassée, il y aura une erreur java.net.SocketException: Trop de fichiers ouverts.

Vous pouvez modifier cette limite en utilisant ulimit -n pour un nombre plus important, par exemple 4096, mais informez-le de l’administrateur système UNIX et si vous avez une équipe de support UNIX distincte, faites-leur mieux.

2) Réduisez le délai d’expiration de l’état TIME_WAIT dans votre système d’exploitation

Sur les systèmes UNIX, vous pouvez voir la configuration actuelle dans le fichier / proc / sys / net / ipv4 / tcp_fin_timeout .

Dans les systèmes Windows, vous pouvez voir ces informations dans le registre Windows. Vous pouvez modifier le délai TCPTIME_WAIT dans Windows en procédant comme suit:

 1) Open Windows Registry Editor, by typing regedit in run command window 2) Find the key HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\tcpip\Parameters 3) Add a new key value pair TcpTimedWaitDelay asa decimal and set the desired timeout in seconds (60-240) 4) Restart your windows machine. 

Vous pouvez également vouloir vérifier la limite maximale de fichiers ouverts sous Linux. Ce lien associé est destiné à un produit sur mesure java, mais il explique bien les étapes nécessaires à la résolution du problème.

(RÉSOLU)

J’ai récemment eu la même erreur parce que le var / log sur DataBase Server est Full.

 #df -h S.ficheros Size Used Avail Use% Montado en /dev/cciss/c0d0p3 126G 126G 0G 100% /var #echo "">/var/log/postgresql/postgresql.log 

Maintenant, l’erreur est partie !!!

important: voyez ce qu’il faut connecter postgresql.log, examinez votre postgresql.conf

au revoir
@_jpgo

Je résous le problème en fermant la connexion dans le bloc finally

 public static Ssortingng postMethod(Ssortingng jsonStr,Ssortingng sendUrl){ Ssortingng resultJson = ""; HttpClient httpClient = new HttpClient(); PostMethod post = new PostMethod(sendUrl); post.setRequestHeader("Content-Type","application/x-www-form-urlencoded;charset=utf-8"); NameValuePair[] param = { new NameValuePair("message",jsonStr)} ; post.setRequestBody(param); try { httpClient.executeMethod(post); resultJson = post.getResponseBodyAsSsortingng(); } catch (HttpException e) { e.printStackTrace(); } catch (IOException e) { e.printStackTrace(); }finally{ post.releaseConnection(); ((SimpleHttpConnectionManager)httpClient.getHttpConnectionManager()).shutdown(); } return resultJson; }