3

I have a spring application running on a Tomcat 8.0 server the following error when either Stopping the server or Redeploying the app on the server.

INFO: Closing Spring root WebApplicationContext
Jul 25, 2016 10:18:40 AM org.apache.catalina.loader.WebappClassLoaderBase clearReferencesThreads
WARNING: The web application [APP_NAME] appears to have started a thread named [AS400 Read Daemon [system:*connectionurl*;job:768339/QUSER/QZDASOINIT]] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:
 java.net.SocketInputStream.socketRead0(Native Method)
 java.net.SocketInputStream.socketRead(Unknown Source)
 java.net.SocketInputStream.read(Unknown Source)
 java.net.SocketInputStream.read(Unknown Source)
 com.ibm.as400.access.DataStream.readFromStream(DataStream.java:52)
 com.ibm.as400.access.ClientAccessDataStream.construct(ClientAccessDataStream.java:58)
 com.ibm.as400.access.AS400ThreadedServer.run(AS400ThreadedServer.java:357)
 java.lang.Thread.run(Unknown Source)

I am connecting to an AS400 db with the JT400 maven dependency (version 9.0, though I've tried others), so the AS400JDBCDriver. Here is how my connection is set up in my app's context.xml

  <Resource name="jdbc/test_name"  
auth="Container" 
driverClassName="com.ibm.as400.access.AS400JDBCDriver" 
factory="org.apache.tomcat.jdbc.pool.DataSourceFactory" 
initialSize="3" 
logAbandoned="true" 
maxActive="100" 
maxIdle="40" 
maxWait="30000" 
minEvictableIdleTimeMillis="60000" 
minIdle="10" 
password="*password*" 
removeAbandoned="true" 
removeAbandonedTimeout="60" 
testOnBorrow="true" 
testOnReturn="false" 
testWhileIdle="true" 
timeBetweenEvictionRunsMillis="30000" 
type="javax.sql.DataSource" 
url="jdbc:as400:*connection url*;date format=iso;time format=iso;" 
username="*username*" 
validationInterval="30000" 
validationQuery="SELECT current date FROM sysibm.sysdummy1"
/>

The datasource is then declared in a spring configuration file:

  <bean id="dataSourceTester" class="org.springframework.jndi.JndiObjectFactoryBean">
      <property name="jndiName" value="java:comp/env/jdbc/test_name"/>
  </bean>

And then I have dozens of beans using that datasource.

  <bean id="testTesterDAO" class="*class  url*" scope="request">
<property name="dataSource" ref="dataSourceTester" />

So the problem is, when I stop my Tomcat or redeploy, I am greeted with a number of these messages about threads that have failed to stop. I know that it specifically comes from this connection source because when I change the "initialSize" attribute (like from 3 to 5), I get that many messages when the server stops. So it's clear that all of these connections being opened by the connection pool are not getting terminated.

When the server shuts down, the threads do dissappear (obviously, the server doesn't exist anymore), but when its just a redeploy, these threads definitely stay open. I know this because I can go on the as400 machine and find the open job, and they dont really seem to time out.

I've tried a bunch of things, I have a ServletContextListener which deregisters the driver (which got rid of that warning, but not these), I have tried moving the jt400.jar to the tomcat/lib folder (but I can't really tell if its working off of there or not when I run it), and I've tried tweaking the settings and trying different versions of the jt400.jar. No luck.

Any advice or help would be greatly appreciated.

Michael Watson
  • 308
  • 2
  • 11
  • The QZDASOINIT jobs on the IBM i will process 200 transactions (by default, this can be changed) and then die, your code shouldn't be able to end those jobs. See this question and [my answer](http://stackoverflow.com/questions/20569635/why-arent-connections-being-reused-in-my-iseries-asp-net-mvc-4-app/21092268#21092268) for some more insight into these jobs. – Benny Hill Jul 26 '16 at 01:38
  • The thread mentioned is used by a JDBC connection. I suspect the application is using a connection pool which keeps the connections open. When the server shuts down, I suspect that nothing is closing the connections in the connection pool before checking for extra running threads. I suspect this can only be remedied if the connection pool has a means to close all the connections in the pool. This method would need to be called when the application is shutting down. – jweberhard Jul 26 '16 at 01:55
  • And note that even if connections end, it shouldn't be expected that the QZDASOINIT jobs themselves will end. They can remain available for other users to open connections through them to DB2. Other than the message, is there any indication that the system itself suffers a problem? – user2338816 Jul 26 '16 at 14:45
  • I have seen crashes before due to out of memory errors, but to be fair I just tried to replicate it through successive rapid redeploys and couldn't force one. So I guess I'm not sure if the jobs are an issue. To follow up with Benny and user2338816, the olds Jobs in the warning message disappear when the server is Shut down. The jobs stay when the app is redeployed. This to me is indicative of an issue. If they always stayed or always left I'd believe that behavior was intended, but as it is, I'm not sure. I think JWEBERHARD is on the right track but i dont know how I would implement it – Michael Watson Jul 26 '16 at 15:36
  • Just a minor note that the QZDASOINIT jobs are completely separate as far as memory usage is counted for Tomcat. They might or might not go away when Tomcat processes are ended, but memory assigned to Tomcat is unrelated to them. – user2338816 Jul 29 '16 at 05:41
  • The jobs **should** stay when you redeploy - your application and it's redeployment are _completely separate_ from the IBM i server. And naturally the jobs on the IBM i will go away when you reboot/shut down that server - they would also go away if someone ended the relevant subsystem on the i. – Benny Hill Aug 01 '16 at 11:55

0 Answers0