Dear All,

Is it true that webMethods service is a multi threaded?
Let say if we have 1 generic service that used by 2 different package, will WM will create an instant of this service for package A and other instant for package B?

Can WM guarantee that this generic service will not be mixed while used closely by package A and B?

Does anybody know which documentation explain about this?

Thank you in advanced.

IS is multi-threaded. A service is executed within a thread.

More or less. The IS run-time manages the execution of services such that multiple invocations of the same service by different threads do not interfere with each other.

Yes.

Hi Rob,

Many thanks for your asnwer.

Btw, I also got answer from WM Support named Jimmy :
"
Hi Fanny,

Thank you for your support request. We are tracking this as SR 1-102246211. I own this request and I will be contacting you shortly after reviewing the issue in detail.

webMethods is running on top of JVM (Java Virtual Machine) , which is multi thread platform. However we can’t guarantee that generic service will not be mixed while used closely by package A and B as your example. However, if it happened, it is not the product expected behaviour and can be deemed as a defect.

For documentation, it didn’t directly explain “multiple thread”, but it is through functions we can know it is multi thread. Eg, in broker Admin Guide, we can set the maximum thread limit to a specific number of thread runnable on a time. And in IS Admin Guide, we can set the min/max of server thread pool.

Hope I have answer your question.
"

Seems they also can’t guarantee that the generic service will not be mixed while used closely by two packages.
Btw,
While executing the generic service, do WM use the same pipeline for package A and B at the same time?

Please correct me if i was wrong.

Thank you,.

Legally, they’ll never “guarantee” anything. But as they pointed out, it would be considered a bug if invocations of a single service from multiple threads caused problems. Such bugs have been very rare.

No.

Hi Rob,

Many thanks for your explanation.

Seems I need to continue my research on mixing pipeline for my generic flow service.

Really appreciate your help.

Thank you.

I don’t think that you need to worry about this. Multiple threads using the same service is not a problem. Their pipelines will not interfere with each other in any way.

Hi Rob,

Finally I got the root cause of my prob. Yes, you are right, it is not because the mixing pipeline.
We tried to post some file in the FTP and got the error of the previous process. And we realized that after the error, the process still not logout yet so the next posting file will got the error of the previous one.

Thank you.

Thanks for posting what you found.

This is a classic case of where posting in a way to maximize useful responses would have been more helpful to you–you would have received a the right advice far more quickly.

In this case, you posted what you thought was the cause of your problem. But you should have posted your symptoms. If you had, we would have very quickly pointed out that the FTP services in 6.1 and prior try to reuse sessions–which can cause exactly the issue you ran into. For 6.1, there is a fix available. For 6.5, FTP sessions are never reused (at least that is what wM support has indicated when a queried about the disappearance of the newSession input to the ftp and login services).

This info isn’t intended to give you a hard time. Rather, the intent is to help us all remember that describing the end goal and the specific symptoms, not our guesses as to the root cause, is the way to go.

Java/Flow/adapter services are running in a session. Session is a one thread. IS spans up to about 1000 session on start (I have got at least 1000 java processes started in Linux old threading model).

Top level (i.e. when somebody run service from Developer) service is taking the free one session from pool on start of its execution, and invoking another services within the same session !

Services have only static methods (Java) or declarative structure of permanent objects (Flow) - there is no context of service object - only context of current service within current session.

Session (instance of com.wm.app.b2b.server.Session) != thread (instance of com.wm.app.b2b.server.ServiceThread)
Services do not run in a session, they run in a thread
Sessions are not in a pool
There is a pool of threads
A session can be associated with one or more threads (as evidenced by the doThreadInvoke that accepts a Session object as a parameter)
The number of threads created at startup is configurable
The number of threads available is independent from the number of sessions

Session != thread - it’s understood (it was a shortcut), but maintained by IS thread is by default initialized and have session object injected also when context of invocation is crystallizing. Any other threads need to be initialized in custom manners.

Sessions are not in pool because may contain some not wanted data from previous invocations and must be destroyed, when context of top level service invocation ends.

Am I right ? I’m just returning to real webMethods developing after the long break.