IS hangs dialy, due to number threads used by Scheduler

, ,
1

Hi Guys, We have couple of issues with wM scheduler. As per out requirements, we configured the scheduler every 120 sec based on the repeated interval. The functionality of the scheduler invoking flow service is, it gets the file from the Internal directory and push the file into the target FTPS directory. The currently flow service functionality is working fine. But we have face problem, If the FTPS server is not available. In such cases, the webMethods scheduler service thread is keep on running. Same like this, Daily the number of scheduler service threads are keep on running and going out of configured scheduler threads. And IS hangs regularly. When we restart the IS, the problem is sort it out, but the problem is come again and again. And need to restart the servers daily. We are using the wM6.1 version. Could please help us to resolve the issue? Thanks in Advance! Regards, Srini

2

IS the hung only happening to TN batch jobs or your custom schedule services affected too?

You can try increase thread count Settings–>Resources–> Available Threads (depends on the activity you have say 500 or 1000) and if the issur related to TN scheduler services (batch etc…) you can try increase TN JDBC Pool max connections and restart Alias:

HTH,
RMG

3

It is likely your service causing the problem, not the scheduler. Your service is either waiting forever for a response from the FTPS server or otherwise not exiting properly. You can confirm this by reviewing the Service Usage within IS Administrator. If you know a thread is hung, look in the Service Usage to find out where it is stuck. Then change your service so that it doesn’t hang.

4

Hi RMG / REAMON,

Thanks for your reply.

Actually, the functionality of the scheduler service is below,

It initially calls the getSession in built service, and checks the any ftp session key is available already, if any session key is available and log-out the session by calling the ftp:logout inbuilt service,

Then it creates the session with FTP server by calling login service.

set the session key with getsession inbuilt service.

calls the cd service, by changing the directory. if return code was wrong, then come out of the parent and calls the catch block.

If cd service service is successful, calls the ls service and get the directorylist,

then call the ftp:get inbuilt service and get the files from the FTP directory location.

and then closes the session with FTP server using the ftp:logout service. and then drop the session key from the getsession in built service.

after call the move customer flow service, to move the files to target location.

In the catch block, There is no ftp:logout.

If any chances the session-key exists in the flow, then the next invocation of the scheduler closes that session initially. and then flow is executed as above process.

The process is already implemented in yrs back.

Thanks and Regards,
Srini

The session is set to the getSession in built service.

create the directory using the cd inbuilt service.

and call the ls inbuilt service

5

I’ve found that it usually doesn’t matter how long a service has been in use when it comes to new issues popping up. I’ve seen services that have been in use for years function without issue that suddenly start misbehaving (for one reason or another).

The steps I suggested still apply–when you see threads are hung, check the Service Usage page to find which service is hung. Then you can make adjustments as needed to avoid the hang.

You should modify the service so that it always calls logout. There are couple of ways to get the sessionKey within the catch block so that logout can be called. Please post if you need info on those options.

6

“In the catch block, There is no ftp:logout”

you always need to have logout inside the catch block to close the sessions properly.

So extract sessionKey from (getlastError output -->%error/pipleline/sessionKey% variable)

Also as Rob pointed out check the Service Usage page and check which server is hung state and dig that service for the root cause analysis.

HTH,
RMG

7

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.