Concurrent workunit "status = processing" limit?

Name	Points
Greg Moeller	4184
David Williams	3349
JonA	3291
Kat V	2984
Woozy	1973
Jimmy Chiu	1883
Kwane McNeal	1437
Ragu Raghavan	1369
Roger French	1315
mark.cook	1244

Lyle Zaehringer

Basic Member

Posts: 8

3/24/2016 2:12 PM

Hi there,

PF newbie here.

I have two workunits in status = processing, loading huge (10K+ records) files into Infor 10 via LawsonTxn node. There are three more workunits in status = ready, presumably waiting for system resources. Since the workunits have initiated the limitation isn't on the file channel receivers. Is there some sort of system setting that we can tweak to allow greater concurrency and any insights you might have into making such changes?

I found the thread linked below but I'm still struggling to understand why only two workunits could max out concurrent processing. The workunit detail doesn't show anything related to number of "threads" being used. If there is some documentation on this topic please point me in the right direction. I found the section on "Thread pool properties" in the Admin guide but it's not giving me a conceptual understanding of the relationship between workunits, processing threads, and thread pools.

https://www.lawsonguru.co...ft/8102/Default.aspx

Thanks,

Lyle

Tim Cochrane

Veteran Member

Posts: 154

3/29/2016 1:16 PM

Lyle,
Workunits (WU) are the instance of work...whether it's a requisition, termination, etc; a thread is what enables the instance to actively process. if you only have 1 IPA grid node (the installed default) and 2 threads running within that grid node (again, the installed default)...then only 2 WUs can actively process at any one time. When a WU gets to a User Action or Completes the WU releases the thread. When this happens the next queued WU grabs the open thread and takes off. This is why you can dump 50 WUs into your system, 2 will process and the other 48 go to Ready. Watch them long enough and you'll see them eventually go to Processing/Complete.

Additionally - WUs that contain User Actions will have an impact also. if while you're dumping 50 WUs in the system...and 50 from yesterday get approved by approvers at the same time...those 50 will get inter-queued with your 50. So depending on one of the 100 WUs gets queued up first...THAT is the order of processing.

You can add additional IPA grid nodes and up the thread count within the grid nodes, but unless you’re processing a large amount of WUs daily…and by large I’m talking more than 1 WU/second…I wouldn’t change settings unless you consult with an experienced Sys Admin. I’ve worked clients that generate 12,000+ WUs/business day, and we HAD to super-size out install…otherwise we could kill the system.

Lyle Zaehringer

Basic Member

Posts: 8

3/29/2016 1:29 PM

Thanks, Tim, for your explanation of how WUs relate to grid nodes and threads.

What should I do when I have a few WU processing a batch files that results in thousands LawsonTxns being executed, taking sometimes over a day to process a single WU? In the meantime, any other WU cannot process. Is there a way to limit the threads used by a IPA process flow? So my batch processing could be limited to only one thread, leaving another open for things that need to process "real time".

Thanks again!

Tim Cochrane

Veteran Member

Posts: 154

3/30/2016 3:19 PM

NP Lyle,
IPA is good for many things, bad for other things...like processing thousands of records in one WU. I would seriously look at other options...COBOL (if an S3 app), perl script...ANYTHING other than a flow.

Using a flow creates other potential issues:
1. how are you going to handle restarts if the WU dies midstream or the server crashes. You're 5 hours into an 11 hour run and the grid crashes or the WU dies. if you restart, now a 11 hour run becomes a 16 hour run.
2. Is this WU resumable from within the WU??

I thought I remembered an option within the grid to steer a flow (by Service or Process) to another IPA grid node, but I must have dreamt it since I can't find any documentation on that.

I think these are your only options:
1. don't use IPA
2. only run one of these beast flows at a time...freeing up the remaining thread for other actions to use
3. don't use IPA, if at all possible
4. run the beast flow on a specific day, freeing the remaining days for other flows.
5. create a separate data area where the beast flow can run, which would be the worst option

Seriously though, I would consider something other than IPA...Sorry