-1

I have installed one J2EE application in Websphere ND 8.5.5.9 on a IBM AIX 7.2 server. While installing application, I have skipped the Queue setup by giving the dummy values to it. Then, Listener port issue came up, as the queue was trying to connect to dummy setup. This way the connection pool was full and system started giving exceptions. So, I re-installed the application and kept the Listener port in STOP mode. First few hours application ran as expected. Now, it is giving below exceptions:

    [5/23/18 17:29:53:609 CEST] 000000a9 FreePool      E   J2CA0045E: Connection not available while invoking method createOrWaitForConnection for resource jdbc/"". 
[5/23/18 17:31:12:899 CEST] 00000055 FreePool      E   J2CA0045E: Connection not available while invoking method createOrWaitForConnection for resource jdbc/"". 
[5/23/18 17:31:12:900 CEST] 00000055 AlarmThreadMo W   UTLS0009W: Alarm Thread "Non-deferrable Alarm : 0" (00000055) previously reported to be delayed has now completed.  It was active for approximately 180004 milliseconds. 
[5/23/18 17:32:11:191 CEST] 00000029 AlarmThreadMo W   UTLS0008W: The return of alarm thread "Non-deferrable Alarm : 2" (00000057) to the alarm thread pool has been delayed for 18271 milliseconds. This may be preventing normal alarm function within the application server. The alarm listener stack trace is as follows:
            at java.lang.Object.wait(Native Method)
            at java.lang.Object.wait(Object.java:201)
            at com.ibm.ejs.j2c.FreePool.queueRequest(FreePool.java:438)
            at com.ibm.ejs.j2c.FreePool.createOrWaitForConnection(FreePool.java:1344)
            at com.ibm.ejs.j2c.PoolManager.reserve(PoolManager.java:3898)
            at com.ibm.ejs.j2c.PoolManager.reserve(PoolManager.java:3118)
            at com.ibm.ejs.j2c.ConnectionManager.allocateMCWrapper(ConnectionManager.java:1548)
            at com.ibm.ejs.j2c.ConnectionManager.allocateConnection(ConnectionManager.java:1031)
            at com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource.getConnection(WSJdbcDataSource.java:646)
            at com.ibm.ws.rsadapter.jdbc.WSJdbcDataSource.getConnection(WSJdbcDataSource.java:924)
            at com.ibm.ws.extensionhelper.db.impl.DatabaseHelperImpl$DSWrapper.getConnection(DatabaseHelperImpl.java:1595)
            at com.ibm.ws.extensionhelper.db.impl.DatabaseHelperImpl.getConnection(DatabaseHelperImpl.java:750)
            at com.ibm.ws.leasemanager.impl.LeaseManagerDBHelper.getConnection(LeaseManagerDBHelper.java:213)
            at com.ibm.ws.leasemanager.impl.LeaseStoreImpl.renew(LeaseStoreImpl.java:452)
            at com.ibm.ws.leasemanager.impl.LeaseImpl.renew(LeaseImpl.java:141)
            at com.ibm.ws.scheduler.LeaseAlarm.alarm(LeaseAlarm.java:173)
            at com.ibm.ejs.util.am._Alarm.runImpl(_Alarm.java:151)
            at com.ibm.ejs.util.am._Alarm.run(_Alarm.java:136)
            at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1892).

Please suggest what can be done to free the connection pool without making any code changes. Is it possible to handle it on OS level or Websphere level?

Crosstalk22
  • 377
  • 3
  • 8
Manpreet
  • 125
  • 3
  • 11

1 Answers1

0

The last of the warnings with the 18 second wait is for a connection attempt that is made by the WAS scheduler. You should look in your configuration to see if the scheduler is configured to use the same data source, jdbc/"" (which is an unusual name - is this data source configured properly?) as the prior errors. There are a couple of possibilities for the cause behind theses errors/warnings. You could have a connection pool that is insufficiently sized to handle the load that your application requires, or you could have code that is holding onto connections for too long, starving out the other users of the data source.

njr
  • 3,399
  • 9
  • 7
  • datasource name is properly configured and connection pool size is kept as 65. Same configuration is working very fine in production environment. Is there anything else I can try with Scheduler? Please be sure that I have kept all configuration correct, same has been cross checked multiple times. – Manpreet May 23 '18 at 13:49
  • Rather than focusing on the scheduler that is not being allocated the connection that it needs, I would recommend focusing on whatever is using up/holding on to the connections and stopping any from being available. The following link has good instructions for enabling and debugging ConnLeakLogic=all trace, http://www-01.ibm.com/support/docview.wss?uid=swg21385033 This should help to you debug what is keeping the connections open and starving out the scheduler and other resources. – njr May 23 '18 at 15:37