We have a AS/400 with webmethods.we have one scheduler service which runs after every one minute to take orders from AS/400.Yesterday we rebooted the AS/400 server.Today when I checked the scheduler the next run parameter of that service is showing the negative value.I have no idea why.My scheduler is not running because the next run parameter is always increasing with -ve values.For example -20.3…-35.7…-90.66…I have a repeate value of 60 sec only.Do anyone have any idea why I am getting negative value in next run parameter.
Thanks in Advance
This might be due to the fact that server is running out of threads. Typically its 10 threads available for a scheduler. you might want to increase by editing the value of watt.server.scheduler.maxThreads in the server.cnf file.
Hope this helps.
I already set this value to 25.Anyway I resolved that problem.Thanks a lot.
we at Abbott Labs are also facing the performance problem on AS/400 with IS . Major problem is overhead on CPU. IT consume all the resources and through out of memory error.
Can you suggest us some tips with your experience on AS/400.
a) Try calling a java service instead of the actual service in your scheduler. This java service will be responisble for creating a new Context(localhost, username, pass) and invoking your actual service by doing Context.invoke();
A webmethods scheduled service does not have a session associated with it if invoke it directly.
b)Make sure that the flow that is being invoked by the scheduler, in all circumstances reaches an end state (by having an explicit exit/correct sequence properties (EXIT ON) etc, wherever appripriate).
Can you explain little more detail, the point B. You mean exit step in the schedule service?
Can you tell us how you actually fixed your problem?
I have seen problem with schedule service been called from a Java service using context, Is that schedule service is expiring based on the watt.net.Timeout value set. Did you face any problem like this or how you have configured.
Ajay Batra ,
Please let us know how you solved the negative values scheduler problem.
Try these 2 settings it seem to worked in my case:
If you use Cluster and repository with it change maxlockduration=-1
to 10000 value in Repository.ini file in your reposerver directory.
In server.cnf config file increase default value watt.server.scheduler.maxThreads=10 to say 20 or more
Lets see if it also works for you let us know the results.
This problem started occuring when we upgraded our JVM to 1.3.1_10. now it is switched back to the old JVM and the problem doesn’t seem to occur. We did increase the number of scheduler threads to 30 with JVM 1.3.1_10 but it did not help. we are not using clustering but ee do use repository to store information, do you think changing maxlockduration to 10000 would resolve the problemn with JVM1.3.1_10? I don’t know if we can try this also. Thanks for your help.
I am not sure if a valid solution is proposed for this particular problem as yet. I had been struggling with this one for the last one week with our 6.0.1 (sp2) running on Redhat enterprise. I was just about to call wm tech support when we were able to nail down the issue. Here are my observations:
Yes…JDK1.3.X has issues, especially with threading model. webMethods recommends 1.3.09 for these reasons. I have been, however using 1.3.07. Ideally if your license supports, you should upgrade it to 1.4.X which is said to be 30% faster with much better garbage collection mechanism. The thread spawning for process (at least for Linux) is lot efficient with 1.4.X with the elimination of green threads in favor of native ones.
The negative scheduler times are not the cause but rather symptoms of some other problem happening in the process. Threads are generally assigned on one to one basis to scheduler services; therefore simply increasing the number of threads is not the solution.
Try to look for an unusual number of sessions open through the admin console. The is usually indicative of processes queuing up for some reason. In my case it was SQL server connection (JDBC pool) used by Trading Network which was by default set to 10 max. Due to high frequency of files that get posted to TN there was a queue building up , which eventually started to eat up all the available threads and finally led to showing up negative times in the scheduler services. Escalating the jdbc pool size (x2) fixed the problem. The problem could be different for you. Special attention should be given to all the processes talking to external systems (ftp, smtp, jdbc, file polling etc).
Note: The same issue has been mentioned for 4.6 as well in one of the threads.
This is my experience with this particular problem which I wanted to share. Would appreciate if someone could confirm these observations and probably add more to that.