Skip to main content

Server experienced logjam - how can I avoid that?

David Paras

After we were able to recover the server, it tried very hard to catch up - there are a large number of processes that it hadn't been running for almost 3 days. Some of them failed because the ran out of memory, which is a balancing act we usually manage by simply scheduling them at different times.

So my question is, can you please help me try to avoid logjams like this on recovery from future outages? I know before we have changed some of the triggers wrt Action on Misfire, and I do not know if this is a related thing (we changed that because it was triggering the action when the event was activitated). I am just thinking general plans we can implement, and then I may have specific questions as I apply any such plans to our processes.

0

Comments

3 comments

Date Votes
  • David Paras

    A quick way to prevent a log jam on recovery would be to modify your queue processor settings. If you don't have the queue processor enabled, you can enable it temporarily to limit the number of concurrent process flows executing. If you do have it enabled, you can temporarily lower the number of concurrent processes.

    For more information on the queue processor, you can refer to the Admin Guide (Help > Admin Guide)

    0
  • David Paras

    I am afraid I need a little more guidance on this. I already have Queue Processing enabled, and my concurrent processes is set to 20. Because most of the processes that tend to pile up are very fast, I am going to move that down to 10, restart the server, and watch general usage tomorrow.

    To watch over it, though, I need a little more information. How can I see how the queue is managed? Is there a way to see the current queue? Or any other tools to help with this?

    Also, I am not clear on the setting for reload factor (abpm.queue.processor.reload.factor). It is set to 20 on our system. From reading the description and the Admin Guide, I think this means that when there are fewer than 20 processes in the queue, that another processes can then be added to the queue. But if that is the case, what is the setting on the actual queue for? Or is there a way to use them together to achieve some other goal I am not seeing?

    0
  • David Paras

    The concurrent process property defines many flows are able to run simultaneously. If this property is set to 10 and 15 flows are triggered, 10 flows will be executed simultaneously while 5 flows are queued.

    The queue is managed internally, but you can view the current queue by querying the backend and log databases as below

    To get the information of the queued process flows from table AU_PROCESSQUEUE try executing the below query on your backend database:

    SELECT * FROM au_processqueue WHERE au_status = 'Queued'

    To get the information of the queued process flows from table AU_TRANSACTIONDATA try executing the below query on your Log database:

    SELECT * FROM au_transactiondata WHERE au_activitystatus = 'Queued'

    The reload factor and reload count are options which determine how the queue is held in memory. The Reload count is how many queued flows are held in memory as opposed to the database. The reload count is the threshold by which the queue determines when to grab more queued flows from the database to place into memory.

    0

Post is closed for comments.

Didn't find what you were looking for?

New post