Заявитель приложения не может установить соединение. (Слишком много открытых файлов) - PullRequest
Новая
       9

Заявитель приложения не может установить соединение. (Слишком много открытых файлов)

1 голос
/ 02 августа 2010

Я разрабатываю приложение, запускаемое в Websphere work manager.Диспетчер работы используется для запуска потока в приложениях webpshere.

Каждые 5 минут мой поток пытается получить данные из базы данных MySQL с другого хоста с компьютера сервера приложений.

КогдаХост базы данных MySql выключен. Диспетчер работ всегда пытается подключиться к базе данных MySQL, и я знаю, что моя программа всегда получит ошибку соединения исключительной ситуации.это исключение: com.mysql.jdbc.CommunicationsException: 

Communications link failure due to underlying exception

Но со временем моя программа получает следующее исключение: 

java.sql.SQLException: The application requester cannot establish the connection. (Too many open files)

, и это исключение вызывает сбой сервера приложений: 

[8/2/10 9:07:21:613 ICT] 00000d54 prefs         W   Could not lock User prefs. Unix error code 24.
[8/2/10 9:07:21:613 ICT] 00000d54 prefs         W   Couldn't flush user prefs: java.util.prefs.BackingStoreException: Couldn't get file lock.

Мне нужно предложение, как исправить эту проблему и предотвратить сбой моего приложения ????

Рабочая среда: 

Operation System AIX
Application Server Webpshere 7.0

Ответы [ 3 ]

5 голосов
/ 05 августа 2010

Похоже, у вас утечка файлового дескриптора.

Некоторая часть вашего кода (или другой код, выполняющийся на компьютере) создает все больше и больше файловых дескрипторов, включая сокеты, и не закрывает их,Исходя из вашего описания, похоже, что это ваш код, который делает это.

Я подозреваю, что когда вы создаете сокет, вы не закрываете его чисто, когда выдается исключение.Если вы этого не сделаете, сокет останется открытым, и со временем у вас закончатся файлы.Любой ресурс, который должен быть закрыт после использования, должен всегда быть закрыт в блоке try-finally , чтобы обеспечить закрытие ресурса независимо от пути через метод.

Если вы не думаете, что у вас есть утечка файлов, воспользуйтесь утилитой lsof на хосте, чтобы увидеть, какие дескрипторы файлов остаются открытыми вашим процессом, и убедитесь, что все они на законных основаниях нужны.Я считаю маловероятным, что у вас есть законная причина для превышения предела FD системы по умолчанию.

2 голосов
/ 02 августа 2010

Вообще говоря, когда вы подключаетесь к базе данных, у вас есть какой-то открытый вызов для открытия соединения, затем вы выполняете некоторую работу с соединением, а затем закрываете соединение.Если вы забыли закрыть соединение, вы можете быстро исчерпать ресурсы и получить ошибку, подобную той, которую вы видите.Однако, даже если вы не забыли закрыть соединение, при выполнении работы вы можете столкнуться с исключением, которое заставит поток выполнения обойти вызов close.По этой причине вы всегда хотите, чтобы работа была заключена в блок try, а вызов close был в блок finally.Может ли это быть вашей проблемой?

1 голос
/ 02 августа 2010

Я столкнулся с подобной проблемой. Я исправил это, увеличив ulimit моего пользователя на ОС. Это происходит потому, что в большинстве операционных систем существует ограничение на количество открытых файлов.

На linux box вы можете сделать это, выполнив следующую команду. Здесь я установил его на неограниченное количество. 

ulimit -u unlimited

Вы также можете проверить текущие ограничения, запустив: 

>ulimit -a       
      core file size (blocks)   1000000
      data seg size (kbytes)    unlimited
      file size (blocks)            unlimited
      max memory size (kbytes)  unlimited
      stack size (kbytes)           8192
      cpu time (seconds)            unlimited
      max user processes            unlimited  
      pipe size (512 bytes)         8
      open files                    1024
      virtual memory (kbytes)   2105343
...