Maximo Open Forum

The system property to control the idle timeout is mxe.oslc.idleexpiry but it's a timeout per page, not for the overall request. Provided you continuously get a page within the 5 minute threshold (the default), you shouldn't hit this. Stable pagination depends on your session staying active and the request routing to the same JVM so you may have something else impacting you. 

@Steven Shull Thank you for your response. Could you please help us understand which configuration files or settings we should review in MAS for this behavior?

Also, we are passing the enablesession=1 parameter in the API call—please let us know if there are any specific considerations or prerequisites related to this in MAS.

Appreciate your guidance.

The first step you need to do is determine if more than 5 minutes are passing between requests. Larger tables (like workorder) with enough attributes, especially if there are child objects through relationships, can easily exceed 5 minutes for 2000 records. If that's the bottleneck changing the idle timeout could potentially solve your issue, though you probably want to spend the time understanding why and how to improve the download times. 

If you know the maximum time between requests is 2 minutes for example, your traffic is potentially routing between JVMs. You should try to confirm this is happening by reviewing which pods are processing your request. I don't remember which version of MAS it was added in but there's a new system property (mxe.oslc.addpodnameheader) you can enable. When you enable it, there's a new header called Podname in the response that will tell you which pod handled the request. If the pod name is changing, you need to make sure you're providing the relevant cookies on the request in addition to the enablesession query parameter. 

If you ever accidentally make a request to Maximo with the cookies without the enablesession it will kill your session. I have seen some multithreaded applications run into this before where it wasn't provided on a request like whoami and invalidated the session.

Steven is right that you need to find the confirm that the root is related to timeout and not requests moving between jvms.

Alternatively, I suggest using Delta Load approach whenever you syncing data from Maximo.

Full load should be done in more one shot approach as you need to ensure all the data is moved to the target system. I would recommend using MIF to extract and Load or SQL /PLSQL for full load problems.

Once Full load is done then you should use rowstamp to do delta sync.

If you have to use REST APi for Full load then keep track of the rowstamps processed and When an issue happens then you you use rowstamp last processed to continue your full load process. I would not recommend using REST API for Full Load.