JSM jobs and threads explained
|Date:||17 July 2014|
|Product/Release:||LANSA Integrator - All Versions|
|Abstract:||An overview of how threads and requests work in LANSA Integrator|
|Submitted By:||LANSA Technical Support|
- Suppose that 3 Java Classes are simultaneously running, as LANSA Integrator accepted 3 different requests for 3 different services it provides (for example, PdfSpoolFileService, PDFDocumentService and ExcelReadService)
Q: How are these 3 requests handled?
A: Each JSM_OPEN to run a service class has its own thread.
So there are 3 Threads running.
One thread for PDFSpoolFileService
One thread for PDFDocumentService
One thread for ExcelReadService
Q: Does LANSA Integrator handles these 3 simultaneous requests in the same job (JSMJOB01) and in the same JVM?
- Suppose that 1000 concurrent users use a Java class, either from a LANSA program or from an external source.
Q: How many JAVA Virtual Machine's (JVM's) does LANSA Integrator use in that case ?
Q: How many sessions are simultaneously open?
A: For 1000 requests, 1000 threads are spawned.
Q: Our customer is planning to use LANSA Integrator for the handling a lot of requests in our Applications.
We would like to know how LANSA Integrator handles load balancing and how it interacts with the resources provided.
A: You can configure a POOL server and start JSM (STRJSM) in multiple JVM jobs.
JSMJOB01 QOTHPRDOWN BCH .0 CMD-RUNJSM TIMW <== STRJSM/RUNJSM CL program
JSMJOB01 QOTHPRDOWN BCI .0 JVM-com.lansa. TIMW <== One Java Virtual Machine
JSMJOB02 QOTHPRDOWN BCH .0 CMD-RUNJSM TIMW <== STRJSM/RUNJSM CL program
JSMJOB02 QOTHPRDOWN BCI .0 JVM-com.lansa. TIMW <== One Java Virtual Machine
JSMJOB03 QOTHPRDOWN BCH .0 CMD-RUNJSM TIMW <== STRJSM/RUNJSM CL program
JSMJOB03 QOTHPRDOWN BCI .0 JVM-com.lansa. TIMW <== One Java Virtual Machine
JSM_OPEN BIF call to the pool server will round-robin the request to one of the multiple JVM jobs.
Using a POOL server, the service threads and the GC work load is spread across multiple JVM jobs.
Q: Can one JSM instance (One JSM subsystem with one JSMJOB and one JSMJOB01) handle 1000 concurrent requests?
A: Yes, but this is not recommended for reasons of performance and load.
Spreading the load across multiple JVM means that you have multiple Garbage Collectors (GC) running.
Each JVM has one Garbage Collector.
If you have 1000 threads running in one JVM, you only have one GC working.
If you have 333 threads running in each JVM, you have three GC working.
Therefore, the load on each JVM is reduced.
When considering this topic, the areas of processors, memory and other IBM work management considerations, ie private memory pools, should be included.
- Some other considerations
- In 32-bit mode, the Java object heap cannot grow much larger than 3 gigabytes. You will also be limited to running approximately 1000 threads.
- If your application requires more than 1000 threads or a Java object heap larger than 3 gigabytes use the 64-bit version of IBM Technology for Java.