Re: Multiple Jobs reading from same data queue-who's turn is it? -- MIDRANGE-L

Job swapping.

If a job is sitting and waiting and gets no activity it is going to swap out
to disk and when the request comes in it goes to the job and the job is not
available so it swaps it back in memory which takes time. Same problem you
run into with Client Access SQL jobs. User stops to take check a figure and
when they come back and make another call, the job has been swapped and now
they have to wait for it to get swapped back. On a very heavily load system,
it is a really big problem.

What you want ideally is that the smallest subset of jobs process all the
requests but it doesn't work that way. It will go to B even if B has been
swapped to disk and A is available because B got there first.

On Thu, Mar 12, 2009 at 11:29 AM, Albert York <albertyork@xxxxxxxxx> wrote:

Why does it make a difference which job processes the request?

Albert

----- Original Message -----
From: "Alan Campin" <alan0307d@xxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Subject: Re: Multiple Jobs reading from same data queue-who's turn is it?
Date: Thu, 12 Mar 2009 11:17:33 -0600

Just went through this. Wrote a test program to prove it.

Given 3 jobs running. A B C requests will always be processed A B C.

Based

on which job gets to the queue first.

What I wanted was A to always get the request if it was available but it
doesn't work that way. Even if A is available B will be the next one to

get

the work and then C and back to A. That order could change based on how

long

a request took a job. I wanted a way to keep A as busy as possible but

could

find no way to make it happen.

On Thu, Mar 12, 2009 at 10:41 AM, <rob@xxxxxxxxx> wrote:

Eric,

I wouldn't assume that. The user would have to take care of that
manually. Although I did hear something at the February meeting of our
LUG about using prestart jobs to do just exactly what you are saying

and

prestart jobs would stop and start as needed to handle the data queue.

Rob Berendt
--
Group Dekko Services, LLC
Dept 01.073
Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com

From:
"DeLong, Eric" <EDeLong@xxxxxxxxxxxxxxx>
To:
"Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Date:
03/12/2009 12:34 PM
Subject:
RE: Multiple Jobs reading from same data queue-who's turn is it?
Sent by:
midrange-l-bounces@xxxxxxxxxxxx

My understanding of this is that your servers read queue entries on a
first-come-first-served basis. I would assume there is some sort of
monitor on the data-queue that will spawn additional server jobs to
process entries, whenever there appears to be a backlog of requests.
This way, your processes can scale to heavier workloads...

As always, it really depends on the requirements of the application.

Eric

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Dave Murvin
Sent: Thursday, March 12, 2009 10:53 AM
To: Midrange Systems Technical Discussion
Subject: Multiple Jobs reading from same data queue-who's turn is it?

Hello,

We have three server jobs, running at interactive priority, that all
read from the same data queue to do a specific task. What I do not

know

is how the system decides who gets to read the next data queue entry.
Does is just go in sequence (job 1, then job2, job 3, then back to job
1) or is it some kind of first come first served process? If job 2 is
currently processing a request and it is normally job 2s "turn" when
another request arrives at the data queue, does the request wait for

job

2 or does it go to the first job that is ready to receive the request?

I am concerned that since these jobs are part of an interactive

process,

that we might get hung up waiting for one of the server jobs to finish
when there are other server jobs available to process the request.
Previously, each job called the server process directly, so each
interactive job had their own copy of the processing programs.

Thanks

Dave
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take

a

moment to review the archives at

http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing

list

To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.