I am attempting to make use of the queue manager. Upon saving a record I am trying to put about four things into the queue. It does actually work and it does work through the queue and generate the required output. However it also generates the above error message about three times. It also generates about the same number of "OpenInsight boot up failed" error messages.

I have the basic two licence system so am thinking that one engine is processing the O4W request and the other engine is busy working through the queue.

I have tried setting field 2 of the CFG_AUTOEXEC record to both 0 and 1 with a similar result.

I am attempting to make use of the queue manager. Upon saving a record I am trying to put about four things into the queue. It does actually work and it does work through the queue and generate the required output. However it also generates the above error message about three times. It also generates about the same number of "OpenInsight boot up failed" error messages.

I have the basic two licence system so am thinking that one engine is processing the O4W request and the other engine is busy working through the queue.

I have tried setting field 2 of the CFG_AUTOEXEC record to both 0 and 1 with a similar result.

Hi, Robert. Sorry, can you provide a bit more detail? Since the category of this post is O4W, are you queuing these items from inside O4W? That would mean you've got an engine server running, and you're using one oengine for the O4W process and one engine for the "queue manager", and you've got a two license system, so it sounds like you might indeed have too many attempts to connect. Or, if you're not actually using a queue manager, then each request will try to spin up its _own_ OInsight, which (again) will soon exceed the 2 licenses.

Or am I misunderstanding the situation?

Thanks,

- Bryan Shumsky

Revelation Software, Inc.

Hi Bryan

a bit more detail…

The following line is inside a for/next loop that loops though 4 times in this case:

TaskID = RTI_TASK_SUBMIT(1, 'MY_PROGRAM_ID', ...

"are you queuing these items from inside O4W? That would mean you're using one engine for the O4W Process"

Yeah, I am doing everything via O4W.

"and one engine for the queue manager". Perhaps this is where I lost count. I didn't expect the queue manager to use up an engine. So if I understand you correctly;

1 x Engine to process the initial request (submit event in this case).

1 x Engine for the queue manager

1 x Engine to run "MY_PROGRAM_ID"

Hi Bryan

a bit more detail…

The following line is inside a for/next loop that loops though 4 times in this case:

TaskID = RTI_TASK_SUBMIT(1, 'MY_PROGRAM_ID', ...

"are you queuing these items from inside O4W? That would mean you're using one engine for the O4W Process"

Yeah, I am doing everything via O4W.

"and one engine for the queue manager". Perhaps this is where I lost count. I didn't expect the queue manager to use up an engine. So if I understand you correctly;

1 x Engine to process the initial request (submit event in this case).

1 x Engine for the queue manager

1 x Engine to run "MY_PROGRAM_ID"

Hi, Robert. The "queueing system" can work one of two ways:

- There's a single "queue manager", and it dispatches the requests to additional OInsight instances for processing, or

- There's no "queue manager", and then each request gets serviced individually

In either way, it's easy to see that 2 licenses are probably not going to be enough…

Hope that helps,

- Bryan Shumsky

Revelation Software, Inc.

I am happy to report that with three engines available it all works perfectly now. I am queueing a number of "jobs" and the third engine (apparently controlled by the second engine) just works through them beautifully.

Thanks.

Well, that wasn't quite the end of the story…

Further testing found I continued to get bogus "attempt to log in too many users" error messages. Eventually we tracked the problem down, but first some background…

I was attempting to place 7 jobs into the Queue Manager in quick succession. In other words I had a call to RTI_TASK_SUBMIT(1, …) inside a for / next loop. What was happening was the first time through it realised there wasn't a queue manager running and _began_ the process of getting a Queue Manager going. However it didn't wait until the Queue Manager actually started before moving onto the second job. So when the second attempt at queueing a job happened, it looked to see whether or not if a Queue Manager was already running. It wasn't yet up and running so it attempted to start another Queue Manager instead of putting the job into the queue. And so on and so on for all seven jobs.

Happliy, the solution is simple. The first call should use RTI_TASK_SUBMIT(1, ….) which starts up a Queue Manager _if required_ while subsequent calls should use RTI_TASK_SUBMIT(0, …) which makes sure the job is placed into the Queue and a second Queue Manager isn't accidentally started.

What confused me was the second time I tried all this it worked perfectly - because the Queue Manager was left running - so all the jobs got correctly put into the Queue and they were dispatched properly.

View this thread on the Works forum...