应用程序请求者无法建立连接。 (打开的文件太多)

发布于 2024-09-12 01:37:55 字数 906 浏览 9 评论 0原文

我开发在 Websphere 工作管理器中运行的应用程序。工作管理器用于在 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

I develop application run in Websphere work manager. work manager is used to run thread in the webpshere applications erver.

Every 5 minutes my thread try to get some data from MySQL database from the different host from the application server machine.

When the Host of MySql database turned off, The work manager always try to connect to MySQL database and I know my program will always get exception connection failure. this is the exception: com.mysql.jdbc.CommunicationsException:

Communications link failure due to underlying exception

But, over time my program get exception as follows:

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

and this exception make my application server crash:

[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.

I need suggestion how to fix this problem and prevent my application being crash ????

WorkEnvironment:

Operation System AIX
Application Server Webpshere 7.0

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

苏佲洛 2024-09-19 01:37:55

听起来您有文件描述符泄漏。

您的代码的某些部分(或计算机上运行的其他一些代码)正在创建越来越多的文件句柄(包括套接字),并且不会关闭它们。根据您的描述,听起来好像是您的代码在执行此操作。

我怀疑当您创建套接字时,当抛出异常时您没有完全关闭它。如果您不这样做,那么套接字将保持打开状态,随着时间的推移,您将耗尽文件。使用后需要关闭的任何资源都应始终try-finally 块,以确保无论通过该方法的路径如何,资源都会被关闭。

如果您认为自己没有泄漏文件,请使用主机上的 lsof 实用程序来查看您的进程打开了哪些文件句柄,并检查您是否确实需要所有这些文件句柄。我发现您不太可能有正当理由超出系统的默认 FD 限制。

It sounds like you have a file descriptor leak.

Some part of your code (or some other code running on the machine) is creating more and more file handles, including sockets, and is not closing them. Based on your description, it sounds like it's your code that's doing this.

I suspect that when you create the socket, you're not closing it cleanly when an exception is thrown. If you don't do this, then the socket will stay open and over time you'll run out of files. Any resource that needs to be closed after use should always be closed in a try-finally block, to ensure that the resource will be closed regardless of the path through the method.

If you don't think you're leaking files, use the lsof utility on the host to see what file handles are being held open by your process, and check that you do legitimately need all of them. I find it unlikely that you have a legitimate reason to exceed the default FD limit of the system.

墨离汐 2024-09-19 01:37:55

一般来说,当您连接到数据库时,您会进行某种 open 调用来打开连接,然后对连接进行一些操作,然后关闭连接。如果您忘记关闭连接,您可能会很快耗尽资源并出现类似您所看到的错误。但是,即使您确实记得关闭连接,您也可能在执行工作时遇到异常,从而导致执行流绕过关闭调用。因此,您总是希望将工作包装在 try 块中,并将 close 调用放在 finally 块中。这可能是你的问题吗?

Generally speaking, when you connect to a database, you have some sort of open call to open the connection, then you do some work with the connection, and then you close the connection. If you've forgotten to close the connection, you can run out of resources quickly and get an error like the one you're seeing. However, even if you did remember to close the connection, you might hit an exception while doing the work that would cause flow of execution to bypass the close call. For that reason, you always want the work to be wrapped in a try block, and the close call to be in a finally block. Could that be your problem?

一曲爱恨情仇 2024-09-19 01:37:55

我也遇到过类似的问题。我通过增加操作系统上用户的 ulimit 来修复它。
发生这种情况是因为大多数操作系统中打开文件的数量都有限制。

在linux机器上你可以通过以下命令来完成。这里我把它设置为无限制。

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

I had faced similar problem. I fixed it by increasing ulimit of my user on OS.
This occurs because there’s a limit to the number of open files in most of the operating systems.

On linux box you can do it by following command. Here I have set it to unlimited.

ulimit -u unlimited

You can also check current limits by running :

>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
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文