× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



(This is my first JAVA app that runs on an AS/400.)

I have a JAVA app on our AS/400 (JVM 1.4 / OS V5R1) that accepts
requests from an outside source and spawns a thread to handle each
request.  (Typically a max of 5, average around 3 at a time.)  Each
thread creates an AS/400 object and a JDBC Connection object.  The
command services are disconnected and the connection statements closed
after each use.  The JDBC Connection is closed at the end of the thread.
The threads are kept in a home grown thread pool that periodically goes
through and sets unused threads to null so they can be GC'd.  

The weird thing is after MANY requests (Over 500, plus the AS/400
command & JDBC calls) it seems the app stops spawning any new threads.
If I end the job the app is running in and restart it, it will go on as
it should.  I've looked, but can not find any thing that says an AS/400
job is limited to a maximum number of thread starts.  I get no JAVA
exceptions thrown, and nothing shows in the JOBLOG.  Should I explicitly
call the GC?  Am I missing something obvious?  (A *JOBD setting or
something?  Allow multiple threads - "ALWMLTTHD" does not seem to affect
it.) 

NOTE:  I have not let this app run long enough on the PC to see if it
has the same issue there.

I am calling the app via a command/CL that starts the JVM thusly:

CHGCURDIR DIR('/XXXX') 

JAVA  CLASS(JJJJ.jar) + 
      PARM('-config' '/XXXX/JJJJ.properties')     +

      INTERPRET(*JIT)                             +

      PROP((java.version 1.4)                     +

           (java.util.logging.config.file '/XXXX/JJJJLog.properties') +

           (java.endorsed.dirs
'/QIBM/UserData/Java400/ext/xml-apis.jar:+        
 
/QIBM/UserData/Java400/ext/xercesImpl.jar:+       
 
/QIBM/UserData/Java400/ext/lib/jt400Native.jar:'))

Another thing:  If it does bomb and gives me a stack trace, the line
number is ALWAYS the first executable line of the method even though I
know from the type of exception that it was somewhere farther down when
it blew.  Is there a way to alter that?  (Only on the iSeries, not when
running on a PC.) 

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.