I'm having an intermittent problem where
jobs that start from a file trigger are
receiving the message

semaphore file is ignored because the
job is already queued.

The jobs that receive this error are all
run async (their BAT files),
using the default queue.

Most of the time it works fine (and it never
fails except at one customer site) . Once
it fails , it takes a restart of the 24x7
service to get things running again.

can you shed any light on this problem?
thanks

Let's say you setup a file watch job to check for certain files every 3 minutes.

When 24x7 finds that file it submits the job to the queue; 3 minutes later it checks for the file again and finds it again, but the submitted job is still waiting in the queue. To avoid multiple instances of the same job 24x7 ignores this event and simply writes a warning to the job log.

: I'm having an intermittent problem where
: jobs that start from a file trigger are
: receiving the message

: semaphore file is ignored because the
: job is already queued.

: The jobs that receive this error are all
: run async (their BAT files),
: using the default queue.

: Most of the time it works fine (and it never
: fails except at one customer site) . Once
: it fails , it takes a restart of the 24x7
: service to get things running again.

: can you shed any light on this problem?
: thanks

: Let's say you setup a file watch job to check for certain files every 3
: minutes.

: When 24x7 finds that file it submits the job to the queue; 3 minutes later it
: checks for the file again and finds it again, but the submitted job is
: still waiting in the queue. To avoid multiple instances of the same job
: 24x7 ignores this event and simply writes a warning to the job log.

Ok, I understand that. I guess I'm wondering why in this instance the
jobs don't just start. Most of the time the job starts running right
after the trigger file is found. In this case , the jobs don't start
and I get the already queued message but there isn't an instance of the
job currently running.

Could it be the queue size is being exceeded. Would changing the
queue size help prevent this?

The default queue size normally can fit hundreds and hundres of jobs.

I still think you have other jobs running at that time that cause delays.

You can simply create another queue (Tools/Job Queues menu) and put those file watch jobs into the new queue if you don't want them to be delayed by other jobs.

: Ok, I understand that. I guess I'm wondering why in this instance the
: jobs don't just start. Most of the time the job starts running right
: after the trigger file is found. In this case , the jobs don't start
: and I get the already queued message but there isn't an instance of the
: job currently running.

: Could it be the queue size is being exceeded. Would changing the
: queue size help prevent this?

I started 24x7 on the desktop and left the queue monitor
open so I could monitor this situation. What I found is this:
periodically a job completes but its status is still listed as
"RUNNING". All other jobs in that queue are left waiting.
Can you tell me why a completed job would be left in a "RUNNING"
state?
This problem:
a) doesn't happen at other customers sites running the same
application and 24x7 setup;
b) only started happening when this one customer moved

24x7 to its own server

Thanks for any help.

: The default queue size normally can fit hundreds and hundres of jobs.

: I still think you have other jobs running at that time that cause delays.

: You can simply create another queue (Tools/Job Queues menu) and put those
: file watch jobs into the new queue if you don't want them to be delayed by
: other jobs.