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?
Btw, I also got answer from WM Support named Jimmy :
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.
While executing the generic service, do WM use the same pipeline for package A and B at the same time?
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.
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.
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.
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.