NEW QZRCSRVS jobs starting when there are existing ones available to handle requests
smally
appears that new jobs are getting started but the old ones are not ending
and the new requests are not being serviced by the existing jobs running. We
are running WAS3.5 and using pcml to call legacy programs which is the
reason for these jobs to be starting. Does anyone have any idea how I can
get these requests to use the existing QZRCRVS jobs that are running or have
them end after use.
thanks for assistance,
smally
John Clark
I have seen this kind of behaviour before and it was generally related
to an application that was not closing the connection. As long as the
connection was open, the prestart job would not get reused. It can be
a real performance killer depending on how the prestart jobs are setup
and how often they are getting called.... hope this helps, JC
smally
pcml? I will check it out.
thanks,
smally
"John Clark" <jcl...@1stoption.com> wrote in message
news:4e3beb01.0302...@posting.google.com...
Paul Allen
> Does anyone have any idea how I can
> get these requests to use the existing QZRCRVS jobs that are running or have
> them end after use.
I believe the QZRCSRVS prestart job entry is shipped with:
Initial number of jobs . . . . . . . . . . . . . : 1
Threshold . . . . . . . . . . . . . . . . . . . : 1
Additional number of jobs . . . . . . . . . . . : 2
Maximum number of jobs . . . . . . . . . . . . . : *NOMAX
Maximum number of uses . . . . . . . . . . . . . : 1
You can do DSPSBSD QUSRWRK, then "Prestart Job Entries" option, then
display the entry for QZRCSRVS.
The remote command server does not support "Maximum number of uses"
greater than 1, so the pool size should not grow due to active jobs
being put back in the pool.
It sounds like your problem may be a large number of active or signed on
jobs, not a large number of available jobs. In a Java environment, this
can be caused by references to AS400 or ProgramCallDocument objects
being held beyond the scope they are needed. This causes the objects not
to be garbage collected and, consequently, the QZRCSRVS job not to be
released. (The job can be released explicitly without garbage collection
by calling AS400.disconnectService() when the QZRCSRVS job is no longer
needed.)
The most common cause (that I have seen) of keeping these objects around
longer than necessary is due to either a servlet holding references to
the pcml or AS400 objects or a servlet putting these objects in the
HttpSession. In the former case I am refering to servlet instance or
static variables, not variables scoped to doPost() or doGet().
Good Luck.
Paul Allen
> Does anyone have any idea how I can
> get these requests to use the existing QZRCRVS jobs that are running or have
> them end after use.
I realized that I might have answered the wrong question. I was trying
to explain why the jobs may hang around longer than they are needed.
But the answer to your question is that if all pcml requests use the
same instance of com.ibm.as400.access.AS400 they will reuse the same
job. This assumes AS400.diconnectService() is not called between each
pcml request.
You have to be careful with this in a servlet environment (my assumption
based on your reference to WAS 3.5). Each servlet request should use its
own instance of AS400 object. So, at the top of doPost() or doGet() you
new up an AS400 or get one from a pool. You use that instance for all
pcml and cl command requests needed to service that http request. When
finished you either put the AS400 back in a pool for use by a subsequent
http request, or you let the AS400 object be garbage collected after the
http requst completes.
One mistake I have seen is to use the same instance of AS400 object for
all http requests (i.e. all servlet threads). This results in all pcml
calls for all http users running serially in a single job. This results
in unacceptable user response times and possibly corruption of user data
due to co-mingling requests in a single job. This is obviously not you
problem because you have a plethora of server remote command jobs.
Paul