Multiple Batch Queue Setup

Hello everyone. I'm currently in the process of setting up multiple single-threaded queues for OneWorld. Ideally, what I'd like to do is to set up a single threaded queue for each system code and its UBEs that have to run single-threaded for that system code. Does anyone see any potential problems with this? One of my main concerns is regarding any jobs belonging to one system code that may have a dependency or update the same information/tables that a job that's in another system code does. Has anyone else attempted to set up their queues this way? Any help would be appreciated.

TIA.

Hi Ralph!

Yep there will be a few application problems with this e.g. sales order
update r42800 and the financial update after it r09801. There are a lot
of similar dependencies. Going down the queue by system code will
likely mean that the gl update finishes with no records to process, and
so the sales update will not be complete until the next nightly run.

I would recommend that all dependent jobs run through the same single
thread queue, scheduled to run one after another.

This will need the apps consultants to tell you what is to run through
and what has to happen afterwards.

From experience 2-3 job queues are usually enough unless you are a very
large site, then some time considerations may come into play.

I am an apps consultant so if you need any advice in that area let me
know.

Best regards

Peter

Peter Bannister

1st Consulting Ltd
www.1stconsulting.biz

Mobile : +(44)-7711-649358

In addition to the advice already given, each jobqueue process uses a bit of server memory and polls the F986110 table a lot. If you ran one for every system code, you would use too much memory and speand WAY too much time polling F986110 which would cause poor performance for anyone accessing it, from the queues to the users trying to view their jobs.

So, I wouldn't do this for performance reasons alone.

I am afraid that I must respecfully disagree with Segfault. Each jobqueue process should use very little memory. If one has a reasonably sized Enterprise Server, job queue memory should not be an issue. I will agree that polling the F986110 table does have its costs but I do not think that adding queues on an NT system increases table scans of that table. However, for those who are having issues with short QueueDelay settings, I have heard that eliminating database statistics for that table helps.

On a side note, no more than two UBE’s per NT CPU should be run concurrently for maximum throughput.