Queue with computer-based name not found

[pwaszkewitz]

Hi,

I create a queue to be used for communication with a Remote Engine as follows:

In an expression:

   Locals.Queuename = "MyQueue"

    StationGlobals.RemoteQueueName = "\\\\" + Locals.Computername + "\\" + Locals.Queuename

where I get Locals.Computername from the %COMPUTERNAME% environment variable.

Then I do a Queue-Step with the Create option and StationGlobals.RemoteQueueName as the name parameter.

When afterwards I do a Queue-Step with the "GetStatus" option on a variable

    Locals.Queuename = "\\\\Computername\\MyQueue"

it works. When I do it on StationGlobals.RemoteQueueName, the entire execution hangs. Usually I actually have to restart SeqEdit.

I am running TestStand 4.1.0 on Windows XP.

Any ideas what can cause this behavior?

Best regards,

Peter

[dug9000]

Does it always hang? Are other threads running at the same time (i.e. you might have a race condition with accesing the globals)? How long are you leaving it hung? Are you accessing it from the same machine that you are specifying or a different machine? Did you make the changes to DCOM permissions as described in the user manual?

-Doug

[pwaszkewitz]

Thank you for the quick reaction.

The creation happens during ProcessSetup. At that point, the execution has started two other threads which do not touch this queue at all and as to my knowledge do not need any of the involved globals. But I will check that.

The queue will later be accessed by another machine, therefore the computername in the queue name, but not at this point of the execution. The Remote sequences are started later in the process.

As far as I can tell, the thread hangs indefinitely, but I will do more tests tomorrow.

We made the DCOM settings as described in the manual (and the forum). Remote sequence execution has been tested (using a simple sequence which does not require queues) and works, so I assume the DCOM permissions are correct.

Peter

[dug9000]

Remote sequence execution is separate from remote synchronization objects. Remote synchronization objects require changing dcom permissions on tsautomgr.exe, while remote executions need changes for rengine.exe. Have you tested that a remote machine can access the syncronization objects.

Either way you should not get a hang, you should get an error, though you might have to wait for a timeout to expire. That is why I asked how long you waited. If you wait a couple of minutes the hang might turn into an error if it is a dcom configuration issue.

-Doug

[pwaszkewitz]

Thanks to Doug for the clarification. I created two simple test sequences to test for remote sequence execution AND queue communication. This worked fine.

Next we will investigate whether these are issues with hardware drivers or other components. We have noticed in the past, that system level exceptions in certain DLLs sometimes lead to subsequent problems in OLE functions.

I will get back as soon as I have new information.

Peter

[pwaszkewitz]

Now I have another piece of information. My colleagues found an interesting effect.

We are dequeuing from an array of queues. One of the queues had a computer-based name, the other had a local name, i.e., symbolically:

Dequeue["\\\\Computername\\Queue0", "Queue1"]

Both queues are actually created on the same machine, but only Queue0 is used for communicating with a remote engine, so we figured that only Queue0 needed the computer-based name. As soon as we changed to

Dequeue["\\\\Computername\\Queue0", "\\\\Computername\\Queue1"]

the problem went away. Is there possibly a problem with "mixed" queue arrays?

Peter

[dug9000]

There is no known issue like that that I am aware of. It is supposed to work even if the queues aren't all computer-name based. Can you reproduce this in a simple case and attach the sequence files to this forum topic? What kind of data is in the queue and what settings are you using to dequeue it? Is either queue empty?

Thanks for any info to help reproduce this problem.

-Doug

[pwaszkewitz]

Hello,

attached is a sequence file which detects the computer name, creates one queue with, one without the name; their existence is tested, strings enqueued, then both are waited for.

Everything runs fine in my TestStand 4.1 up to the step "Wait for both" which does not run through. When I abort the execution, usually already the first step fails (a simple call to kernel32.dll>GetEnvironmentVariableA which should be fairly safe:-). It does not matter whether there is a timeout set for "Wait for both" or not.

Hope that helps. Perhaps I am doing something wrong.

Peter

[dug9000 · Accepted solution]

Thank you for providing us with a sequence to reproduce this problem. I was able to reproduce it by running your sequence. What you are doing is supported and supposed to work. I have created an issue in our tracking database to look into this more thoroughly, and it will likely be fixed in a future version of TestStand.

The issue can occur whenever you do a Dequeue on multiple queues at once where two or more queues are on the same machine where at least one is specified with a simple name, as a local queue to the process, while at least one other queue is specified either with a machine name or an asterisk causing it to be created as global to the machine. You can workaround the problem in one of the following ways:

1) make the queues all global to the machine instead of using local queues (as long as the consequences of this are otherwise ok for you). For example you could call your "Queue1", "*Queue1" instead, which will make it global to your current machine, but will also keep the hang from occurring.

Or

2) Put the remote queue on a machine that you are not also using to dequeue local queues with in the same operation.

1) is probably the most practical workaround. Let me know if this workaround is sufficient for you, or if you need more help or have any additional questions related to this.

Hope this helps,

-Doug

[dug9000]

Note regarding workaround 1):

If you do have multiple teststand processes on the machine and are worried about potential conflicts from making the queue global when you really want it to be local, you could add the process id to the name, for example, "*Queue1 - ProcessId 0x3523".

-Doug