Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Accessing a private queue from another machine

643 views
Skip to first unread message

Joe

unread,
Sep 4, 2002, 3:32:30 PM9/4/02
to
Is this possibly and (if Yes) how do I do it?

I have web site (.NET) that need to put messages on another machines Queue
and I haven't been able to solve this!

JoE


Tam

unread,
Sep 4, 2002, 5:52:15 PM9/4/02
to

Hi,
If you have a Active Directory (AD) Environment and MSMQ is installed in
Directory mode then you can send the message using Pathnames.
The syntax will be
MEssageQueue.Pathname = "Servername\Queuename"

If you don't have AD the you need to use direct format names.
MEssageQueue.Pathname = "Formatname:Direct=OS:Servername\Queuename"


Thanks,

Gautam

This posting is provided "AS IS" with no warranties, and confers no rights.

christoraj

unread,
Sep 5, 2002, 6:42:33 AM9/5/02
to
oups... (we forgot something)

Gautam wanted to say:

...Servername\PRIVATE$\Queuename

and

...Direct=OS:Servername\PRIVATE$\Queuename


(when MSMQ sees a Direct format name, it uses the
information provided in the format name to locate the
queue, not information in the MSMQ information store)

>.
>

Joe

unread,
Sep 5, 2002, 4:14:55 PM9/5/02
to
I have tried with:
"Formatname:Direct=OS:Servername\PRIVATE$\Queuename" - syntax since I do not
have an Active directory environment but I can't get it to work. Can it be a
Security/Authentication issue?

I'm calling the queue from a class from an ASP.NET application and I have
setup the the webb application component to run under a domian account and
given that account permission to the Queue but it doesn't seem to help.

I have also tried the above syntax on my local private queue and get the
following error
Run-time exception thrown : System.InvalidOperationException - Cannot
determine whether a queue with the specified format name exists.

I get this error when executing the parh with MessageQueue.Exists(XXXX)

Thanks

JoE


"christoraj" <chri...@microsoft.com> wrote in message
news:d90701c254c8$f12aedb0$b1e62ecf@tkmsftngxa04...

Joe

unread,
Sep 5, 2002, 6:57:55 PM9/5/02
to
I skipped the exists check and I don't get an error when I send the message
to the Queue but I never get anything in the Queue. What's the problem. I
have also checked that security setting is logging in as the account that I
had set up for this task.

Thanks

JoE

"Joe" <j...@nowhere.zzz> wrote in message
news:eKbWcjRVCHA.1716@tkmsftngp08...

Joe

unread,
Sep 5, 2002, 11:15:14 PM9/5/02
to
I'm also able to read the Queue remotly (very slow) but I'm still not able
to put a message on the queue remotly. Any ideas?

Thanks

JoE

"Joe" <j...@nowhere.zzz> wrote in message
news:eKbWcjRVCHA.1716@tkmsftngp08...

Joe

unread,
Sep 6, 2002, 4:49:05 PM9/6/02
to
The Queue on the server was setup as Transactional, but the message wasn't
transactional and hence ignored!


"Joe" <j...@nowhere.zzz> wrote in message
news:eKbWcjRVCHA.1716@tkmsftngp08...

Frank Boyne

unread,
Sep 11, 2002, 1:02:55 PM9/11/02
to
"Joe" <j...@nowhere.zzz> wrote in message
news:epKkf#SVCHA.2904@tkmsftngp11...

> I skipped the exists check and I don't get an error when I send the
message
> to the Queue but I never get anything in the Queue.

Remember that MSMQ is an asynchronous medium - delivery happens
separaely from transmission. Sometimes just milliseconds later, but
still separately. That means that when you get no error from Send all
you know is that the transmission worked - you know nothing about how
successful (or unsuccessful) delivery may be when it finally happens.

There are two possible explainations for your symptoms (no messages in
queue). Either the messages are never transferred to the destination
system, or they are transferred and the destination system elects not to
place the message in the queue for some reason.

A quick and dirty test for the first case is to run Computer Management
and look in the Outgoing Queues folder. If there is a queue for your
remote system, and your messages are in that outgoing queue, then for
some reason the messages are not being transferred to the system
identified by your Direct Format Name - for example because the host
name is wrong, or can't be resolved by the sending system's DNS server,
or because some firewall prevents connection between the two systems,
etc., etc.

To explore the second case, you really need to capture some record of
the non-delivery. Two options for this are Journalling and Delivery
Acknowledgement.

To use Journalling from the System.Messaging namespace set the
UseDeadLetterQueue property to true on the message before you send it.
With this property set to true, any delivery failure will cause a copy
of the message to be placed in the system's Dead Letter Queue along with
an indication of the type of delivery failure. Actually there are two
DLQs, one for transactional messages and one for non-transactional
messages. You can view the DLQ contents using Computer Management, the
message class of each message copy will tell you what sort of delivery
failure occurred.

The downside to Journalling is that the message copy is placed in the
DLQ of the system where the failure occurred. In your case you only
have two DLQs to check, the sending system and the destination system.
In the more general case, you could have several systems involved,
possibly with multiple routes. This can make checking all the different
DLQs time consuming.

As an alternative, message acknowledgement can be used to deliver a
delivery indication (positive or negative) to a specifically identified
queue. To use this from the System.Messaging namespace, set the
AcknowledgeType to NotAcknowledgeReachQueue (or some other suitable
combination of values) and set the AdministrationQueue property to point
at the queue you want acknoweldgements to be placed into. Remember to
identify the queue in a way that is meaningful to both the sending
system and the receiving system (since the receiving system may have to
send messages to that queue). In your case that means using a Direct
Format Name meaningful to your receiving system.


0 new messages