SOAP Server takes a long time to respond which can cause timeout problems
|Date:||28 January 2009|
|Abstract:||SOAP Server can take a long time to respond because it needs to reload classes. This can cause connection timeout problems.|
|Submitted By:||LANSA Technical Support|
SOAP Server randomly takes a long time to respond, sometimes causing the requesting Agent Function to timeout.
As an example, a SOAP Server that normally takes about 7 seconds to complete, in certain situations may take much longer. Take the following 2 scenarios:
- The very first time that an Order Request is made often adds approximately 15-25 seconds to the process because it has to load the classes.
- The "agent" stops waiting for a response from the Web Service after 30 seconds.
- The "agent" receives a timeout message.
- The connection is no longer there, so the OK message is not received and the second request to consume the Web Service is not made.
- LANSA Integrator and Apache jobs sit idle for 1 hour due to no incoming requests.
- An XML Order Request was then sent.
- The request takes more than 30 seconds to complete.
- The connection iss no longer there, so the OK message is not received.
The same JVM behaviour is causing both problems 1 and 2.
The problem is the time it takes for the JVM to load classes from the disk ( IFS ) into memory and do bytecode verification.
When Java Classes have not been used for 20 minutes the JVM reclaims these Class objects.
So after one hour there are no Classes in memory, so the JVM needs to reload the Classes from disk (IFS) again.
The solution is to add a simple operation to the SOAPServer service and call this operation every 15-20 minutes.
For example, add an operation to the SOAPServerWizard project called NoOp. ( NoOp stands for No operation ).
Generate the WSDL after changing the SOAPServer.
Create an RDML function using the SOAPAgentWizard + WSDL to generate our own SOAPAgent code.
Call the NoOp operation via SOAPAgent RDML function
- once when the JSM starts and
- then once every 15minutes to keep the necessary Classes in memory, so they will not be Garbage Collected.
Basically, when calling the NoOp operation, the necessary classes to support all other operations in the service are loaded into the JVM. The service classes, the apache classes and the custom bean classes are loaded.
You could code an Agent program to periodically call the NoOp operation in each Web service to keep them loaded in the JVM.
You could have a standard practice of having a NoOp operation in each LANSA SOAP Server service.]
From EPC835, the STUDIO SOAPServer Wizard has been enhanced to create a NoOp operation for a new project. - void noop ()
Note: With V6R1, the IBM Technology for Java JDK's can load the Classes a lot faster than the Classic JDK's, so Java Class loading will no longer be a problem.
Also no optimized Java programs are created, so disk space is saved.