Lawson 10.0.X on prem Server restarts and IPA performance

Is there a recommended server restart procedure that will not impact IPA performance? After certain instances when the Lawson and Landmark servers are restarted the performance degrades by a factor of 10. As an example we have a set of IPA's that process text files dropped in a specific locations. These process run once an hour. Typically when the folders are empty the workunit takes less than 3 seconds, but after the restarts it now takes 23 seconds for these blank runs. And of course runs with data perform at the same reduced rate. Files that once took 10 minutes to load now take 100 minutes.

We have yet to understand which server restart order keeps this from happening.

Thanks,

Nathan

Find more posts tagged with

Process Automation (IPA) - General Discussions

Accepted answers

lrjurgen

Our process is as follows and we do not seem to see any performance degradation:

1. Shutdown Landmark

2. Shutdown LSF

3. Tasks needed to be performed (backup etc)

4. Start LSF

5. Start Landmark

All comments

lrjurgen

Our process is as follows and we do not seem to see any performance degradation:

1. Shutdown Landmark

2. Shutdown LSF

3. Tasks needed to be performed (backup etc)

4. Start LSF

5. Start Landmark

unknown

Nathan,

if reboot was an issue, you should see jobs failing. you can verify that by looking at async, lase, lads and LPA nodes in Landmark Grid

we had this happen where we had file channels picking up files in 100s and 1000s at a time when server gets rebooted. not sure if that's your issue. you can confirm this by going to landmark>GRID>LPA>LPA>Local Management Pages (Process Server Status) this where it should show you live threads, queued, processed etc.. if you see lots of them queued up -- that's your issue and you may have to break up the LPA to multiple data areas. also check to see what your max load is, if your maximum load and maximum threads the same it means you are maxing out number of processes it can process simultaneously. you can increase the max threads. but do need to make sure that you have available cpu and memory..

bhillz

Are you getting any errors in the flows or are they just running slower? What logging do you have?

Nathan Baker

Thanks Lance,

We were performing restarts in a similar fashion with the caveat that the startup task(s) were performed concurrently. We performed the steps again, explicitly waiting for LSF to come up fully before starting Landmark. This corrected the performance hit. I'm happy to have a solution and I can surmise that Landmark was referencing something at startup that was not available, but I wish it was clear this might be.

Nathan

Nathan Baker

We were/are logging to the work unit level. We weren't getting errors, just running slower. I tried turning the logging off completely but that didn't correct this. Explicitly letting LSF come up before starting landmark seemed to do the trick. I'll keep my fingers crossed as we've had to perform quite a few restarts as we correct issues from our initial implementation back in 2016. (FYI these issues almost all relate to how LSF and Landmark communicate. Can't wait to upgrade to 11 to get on only Landmark).

russel-cornelson

Just throwing in my two cents...

The only code between the two systems that establishes a connection at startup of the system is LSF making a connection to Landmark. For this reason, it is important that when you cycle servers, that you ensure Landmark Grid is up and running before you start LSF. With Grid down when RMI/EM start in LSF, no connection will be made, no workunits will trigger, no bookmark links will render.

After this, how the system restarts best for you will depend on how you use the system. If you have scheduled flows, that could all fire and trigger work when Landmark is started, and those flows call LSF data you may want to ensure LSF is up fully before Landmark. If you have jobs running in LSF that need Landmark, the reverse could be true.

Copyright © 2025 Infor. All rights reserved.