I’m using webMethods 10.3, when I was using the scheduler the service wouldn’t run instead it came out error just like this “java.io.IOException: java.net.ConnectException: Connection timed out: connect” and then suspended. But when I tried to run it on ag designer it succeed.
Does anyone know how to deal with this matter?
can you share a screenshot of the config of the scheduled task in IS Admin, please?
What are you trying to implement with this scheduled task?
Please provide an outline of the service.
Which version of wM are you running on?
i’m using the 10.3
the service is basically:
- insert adapter to sql server database
AFAIK, Schedulers gets suspended when the scheduler service fails. This is by design.
yes, but before it got suspended the error shows that connection timed out, meanwhile on ag designer the service running smoothly without error
it looked like based on the error that appeared, the error came from pub.client:http. but when tried to run it through softwareAG or postman, it ran smoothly. only when i tried to run it from scheduler, it always came back with this error.
can you share the inputs for pub.client:http step please, exluding the url/auth-section, but keep the method etc.?
Additionally you can add pub.flow:debugLog steps before, between and after each of your steps, which will write some markers to the server.log.
Or you can wrap all these steps in a try-catch block using pub.flow.getLastError as the first step in the catch sequence and the write this information to the server.log with pub.flow:debugLog.
The method that I used is get.
As you can see on the picture, I already put try-catch block but the error did not appear on the log server tab. The only error that I get is from scheduler row.
hopefully you have mapped some outputs from getLastError to the following pub.flow:debugLog.
But even the error message seen in scheduler page should make it to either server.log and/or error log somehow.
You might want to experiment with the values for timeout and connectTimeout for the pub.client:http invocation.
Another option might be to use the old try-catch implementation instead of the new try-catch-template you are currently using:
SEQ (exit on SUCCESS)
SEQ (exit on FAILURE, the Try-Part)
SEQ (exit on DONE, the Catch-Part)
Have you checked the error logs at the same time of the IOException? There should be some clues there.
A note on terminology – there is just one scheduler. And it manages tasks. We define tasks not “schedulers”. The task gets suspended, not the (system) scheduler.
it turns out the problems laid on the server. the production IS somehow connected to developer IS. if the scheduler stopped on developer IS, it affected to production IS and made the scheduler on production IS also stopped.
do you happen to know how to solve this kind of problem?
Scheduler details are stored in the ISInternal JDBC Pool. Please check your ISInternal DB Pool configuration and make sure that you are not sharing the same DB configuration for your DEV and PROD.