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

Unacknowledged messages

402 views
Skip to first unread message

Meinken

unread,
Oct 1, 2007, 4:31:01 PM10/1/07
to
I have an app that consists of a remote computer a recording server and a
main computer. When a request to start recording is entered in the remote
computer, it sends an msmq message to a private queue to the recording server
to start recording. When the recording server starts the recording or fails,
it send a message about its state to the main computer. The main computer
then sends a message to the remote computer that the recording has started.
(there are actually several remotes and recording servers, in various
locations.)

The remote computer and the recording server are at the same location and
there is no problem with the remote sending the message to the recording
server.
However, when the recording server sends its message to the main computer in
another location, the outgoing queue shows the message as unacknowledged and
the main computer never receives it.

The system is XP using Workgroups, and Novell. Any help would be
appreciated and any questions that would help you or I understand the
situation will be quickly answered.

Thank You
Meinken

Frank Boyne

unread,
Oct 2, 2007, 3:27:07 PM10/2/07
to
"Meinken" <Mei...@discussions.microsoft.com> wrote in message
news:221C9408-501D-41E5...@microsoft.com...

> However, when the recording server sends its message to the main
> computer in
> another location, the outgoing queue shows the message as
> unacknowledged and
> the main computer never receives it.

The only KB article that is similar to your symptoms is 902951 but it
only applies to Windows Server 2003 not XP so it isn't much help.
http://support.microsoft.com/kb/902951/en-us

Are you using the OS:<name> or the TCP:<ipaddress> form of direct format
name to address each queue? Or are you using MSMQ over HTTP? Also, it
may not be relevant but are your queues transactional?

One thing that might help you explore this problem further would be to
download Netmon 3.1 and install it on both your Recording Server and on
your Main computer. Monitoring both ends of the interaction while you
try to send a message from Recording Server to Main would at least tell
you if the original message is getting through and if the Main is trying
to send an acknowledgement. To monitor MSMQ you want to look at port
1801 (unless you are using MSMQ over HTTP).
https://www.microsoft.com/downloads/details.aspx?familyid=18B1D59D-F4D8-4213-8D17-2F6DDE7D7AAC&displaylang=en

Mark.B...@comcast.net

unread,
Oct 12, 2007, 1:53:20 PM10/12/07
to
On Oct 2, 3:27 pm, "Frank Boyne" <frank.bo...@unisys.com> wrote:
> "Meinken" <Mein...@discussions.microsoft.com> wrote in message

>
> news:221C9408-501D-41E5...@microsoft.com...
>
> > However, when the recording server sends its message to the main
> > computer in
> > another location, the outgoing queue shows the message as
> > unacknowledged and
> > the main computer never receives it.
>
> The only KB article that is similar to your symptoms is 902951 but it
> only applies to Windows Server 2003 not XP so it isn't much help.http://support.microsoft.com/kb/902951/en-us

>
> Are you using the OS:<name> or the TCP:<ipaddress> form of direct format
> name to address each queue? Or are you using MSMQ over HTTP? Also, it
> may not be relevant but are your queues transactional?
>
> One thing that might help you explore this problem further would be to
> download Netmon 3.1 and install it on both your Recording Server and on
> your Main computer. Monitoring both ends of the interaction while you
> try to send a message from Recording Server to Main would at least tell
> you if the original message is getting through and if the Main is trying
> to send an acknowledgement. To monitor MSMQ you want to look at port
> 1801 (unless you are using MSMQ over HTTP).https://www.microsoft.com/downloads/details.aspx?familyid=18B1D59D-F4...

More information, since my first message. Sometimes the
communications work...

Let me describe the configuration a bit more.
A central machine, called main, is on ip, 10..22.5.1 It has an
incomming queue called inq.
2 remote machines on ip 10.5.40.1 and 10.5.40.2 both have outgoing
queues, called out1 and out 2 that send messages to main's inq

If 1 remote machine is started, it will send messages to inq just
fine. If that machine is stopped and the other remote machine is
started, it will sen messages to main's inq just fine

If both machines are started thent the first one to send a message
will work fine, but the second one will accumulate unacks and its
messages will not reach main's inq.

All 3 machines are running windows xp,Workgroups, and msmq 2.0. on a
novell network

Any suggestions what would cause this situration


Mark.B...@comcast.net

unread,
Oct 12, 2007, 3:18:37 PM10/12/07
to
I didn't answer some of your questions in your note.

The queues are transactional.
OS:<machine name>
not using msmq over http.

Thanks


Mark.B...@comcast.net

unread,
Oct 12, 2007, 3:43:12 PM10/12/07
to

Also if it matters.... We have 40+ installs of this application on all
sorts of windows networks and they work as expected. with up to 30
recording servers, on multiple subnets sending to singl main
computers.

This is our first install on a novell network. I have no idea if that
should matter, but...I'm grasping at straws now.

John Breakwell (MSFT)

unread,
Oct 15, 2007, 7:49:51 AM10/15/07
to
The part you wrote below is the key!
The machines are - I assume - clones.

When you send a message, the sender's Queue Manager ID (QMID) is sent with
it.
The destination builds a cache table mapping QMID to IP address of sender.
This is to speed up sending acknowledgements back.
If two sending machines have the same QMID then the destination machine will
have only one cache entry for both of them so acknowledgements with either
all be sent to sender1 or all be sent to sender2. Any acknowledgements sent
to the wrong machine will be discarded.

More info:
http://blogs.msdn.com/johnbreakwell/archive/2007/02/06/msmq-prefers-to-be-unique.aspx

If this is NOT the cause then I recommend opening a support case with
Microsoft.

Cheers
John

<Mark.B...@comcast.net> wrote in message
news:1192211600.5...@t8g2000prg.googlegroups.com...


> On Oct 2, 3:27 pm, "Frank Boyne" <frank.bo...@unisys.com> wrote:
>> "Meinken" <Mein...@discussions.microsoft.com> wrote in message
>

Mark.B...@comcast.net

unread,
Oct 15, 2007, 10:31:23 AM10/15/07
to
On Oct 15, 7:49 am, "John Breakwell \(MSFT\)" <GreenGob...@msn.com>
wrote:

> The part you wrote below is the key!
> The machines are - I assume - clones.
>
> When you send a message, the sender's Queue Manager ID (QMID) is sent with
> it.
> The destination builds a cache table mapping QMID to IP address of sender.
> This is to speed up sending acknowledgements back.
> If two sending machines have the same QMID then the destination machine will
> have only one cache entry for both of them so acknowledgements with either
> all be sent to sender1 or all be sent to sender2. Any acknowledgements sent
> to the wrong machine will be discarded.
>
> More info:http://blogs.msdn.com/johnbreakwell/archive/2007/02/06/msmq-prefers-t...

>
> If this is NOT the cause then I recommend opening a support case with
> Microsoft.
>
> Cheers
> John
>
> <Mark.Brow...@comcast.net> wrote in message

>
> news:1192211600.5...@t8g2000prg.googlegroups.com...
>
>
>
> > On Oct 2, 3:27 pm, "Frank Boyne" <frank.bo...@unisys.com> wrote:
> >> "Meinken" <Mein...@discussions.microsoft.com> wrote in message
>
> > If 1 remote machine is started, it will send messages to inq just
> > fine. If that machine is stopped and the other remote machine is
> > started, it will sen messages to main's inq just fine
>
> > If both machines are started thent the first one to send a message
> > will work fine, but the second one will accumulate unacks and its
> > messages will not reach main's inq.- Hide quoted text -
>
> - Show quoted text -

Thank you, thank you, thank you.

Yes they were clones and that worked.
I didn't know that our customer had set them up that way, but, I still
wouldn't have known about the QMID.

I now have a happy customer and I can go on to bigger and better
problems.

Thank you again
Mark

0 new messages