How to invoke a service on IS in Thread.run()?

[Gordon_Dong]

Hello,
We will get some service instances hanging on the IS, such as WmDB operation, ftp, etc. So I want use a java thread to invoke the services, and stop the thread using Thread.stop() when the invoked service still not end after the specified timeOut. Here is my approach to do it:

I difined a class “MyThread” which extends the “java.lang.Thread”, and I called the “Server.doInvoke()” in MyThread.run(); But as I tried, the step “service.doInvoke()” could be reached, but it seems the service to be invoked didn’t triggered. So any one has the similar experience? Or is there some other way to carry out the function? Any suggestions will be appreciated.Thanks in advance!

final IDataCursor idcPipeline = pipeline.getCursor();
IData inputData = null;
String serviceName = null;
String threadID = “Test Thread A”;
class MyThread extends Thread{
String threadID = null;
String service = null;
IData iData = null;
MyThread(String threadID,String service,IData iData){
this.threadID = threadID;
this.service = service;
this.iData = iData;
idcPipeline.insertAfter(“message”,“MyThread init”);
}
public void run(){
try
{
idcPipeline.insertAfter(“message”,“MyThread bigin”);
NSName nsName = NSName.create(service);
idcPipeline.insertAfter(“message”,“MyThread create service”+service);
iData=Service.doInvoke(nsName, iData);
idcPipeline.insertAfter(“message”,“MyThread end”);
}
catch(Exception e)
{
idcPipeline.insertAfter(“sucFlag”,“false”);
idcPipeline.insertAfter(“message”,e.toString());
}
}
}
if (idcPipeline.first(“serviceName”))
{
serviceName = (String)idcPipeline.getValue();
}
else
{
throw new ServiceException(“Missing service name”);
}
if (serviceName.length() == 0 )
throw new ServiceException(“Invalid service name”);

if (idcPipeline.first(“input”))
inputData = (IData)idcPipeline.getValue();
try
{
MyThread myThread = new MyThread(threadID,serviceName,inputData);
idcPipeline.insertAfter(“message”,“Current Thread running”);
myThread.start();
// myThread.run();
// myThread.stop();
idcPipeline.insertAfter(“message”,“Current Thread stop”);
}
catch(Exception e)
{
idcPipeline.insertAfter(“message”,e.toString());
}
idcPipeline.destroy();

[system]

What version of Java are you using? Thread.Stop() was deprecated a while back. Plus I don’t think it is going to fix what you are trying to fix.

You can try using Service.doThreadInvoke() and age out the child flow service. If it doesn’t respond within the time limit then you can continue processing or exit. The child thread will run in the background.

The WmDB hang up issue usually can’t be cured with this. The issue is in how it allocates connection objects from the connection pool. Once it gets corrupted, it’s usually restart time. Best to get off WmDB when you can.

good luck

[Gordon_Dong]

Thank you Mark. If using the Service.doThreadInvoke() to trigger a child thread, and when the father thread waiting timeout, the child thread will be hanging in the JVM, right? And in this case, there will be some unusable threads in the JVM before reboot it. So is there a better way can stop the child thread? Thanks a lot.

[system]

you got it. The child thread will be left out there. I think everyone who has used the IS server at some point has tried to figure out how to deal with hung threads.

Killing a thread is really not a good or viable option. You should probably look at what is causing things to hang and go from there. This child thread can help with somethings like a hung ftp services but not always others like a connect spawn via a WmDB call.

A couple of orphaned threads in the background will not hurt the server and then you can restart it during a maintenance window or something. If it is a lot of threads then I would go back to why so many are hanging to start with because that is not normal operation.

[sekay]

Not being able to kill a thread is sometimes very frustrating with the webMethods Integration Server(because of the JVM though).

Though i agree that killing a thread is not a good option, often threads do hang, waiting on other systems or I/O - which have already orphaned the request. This tends to happen more with Integration tools as there are so many variables, ftp, http, smtp, disk i/o, ldap, jdbc and what not. Timeouts can be configured on most of these, but it usually is a great challenge to atleast identify half of these variables.

In these cases, i prefer to have an option to kill the offending thread and let the normal business continue, than having to kill the server and start it again. Ofcourse, in either cases, the root cause for a hanging thread must be and can be resolved accordingly.