I have an BizTalk environment, where I am using the MSMQT adapter to process
queue based messages.

When I send in a message, HAT retains multiple receive entries for the
receive with a status of Delivered not consumed and a service status of
either Active or Dehydrated. Why is this?

Of far more concern, the messages are then sent out again via CBR to another
box (not BizTalk). Here, I consume the messages using a conventional MSMQ
app. However in the HAT, there are still multiple enties for the outbound
queue with a status of Delivered not consumed with a service status of
Active. Can anyone know what can be going on here?

Should I be worried about this behavior?

[ Post a follow-up to this message ]

MSMQT uses internal messages to track its state and as a reminder to do
certain things like cleanup, resend, etc... Those messages will appear in
HAT as delivered, not consumed. This is doesn't mean you have an error.

[ Post a follow-up to this message ]

Thanks Iuliu, that clears up at least why the HAT entries are there.

However, I have continued experementing with MSMQT and have also found the
following:

1. Orphan receive entries in HAT. When you receive via MSMQT,  you see
multiple entries created in HAT for each queue. The message status is always
Delivered not Consumed and the service status is either Active or Dehydrated
.
As time goes on, the retry count goes up and up whether you are sending
messages in or not. I am not convinced this is a problem, but normally any
instance that shows delivered not consumed is of concern. Other than looking
at the WMI snap in for MSMQ from the clients (at Outgoing Queues) it seems
impossible to tell if BizTalk is actually picking the messages up. Is there
any way of doing this?

2. Orphan send entries in HAT. Similar to the issue above. Each queue
generates multiple entries with a message status of Delivered not Consumed
and a service status of active. Once again the retry count goes up an up, bu
t
if you add up all the instances of the queue, equates roughly to the number
of messages that actually are sent. Even when all of the messages have been
consumed by the client, the entries stay there, so how can I tell if the
destination queue has received the message?

3. Load balancing. In my two node scenario, it seems that only one is ever
consuming messages. I can tell this by stopping the host instance on the box
that I think is consuming. At this stage, the client sending the messages in
is not getting ack’s, so the outbound queue is building up. Only if I
actually reboot the server that has the stopped host, do messages start to
get picked up by the other server. How can I see that MSMQT is actually load
balancing requests?

4. Failover. As above, server that seems to be processing the queue stops
working, then the queue becomes blocked. At the moment I am having to
physically reboot it before things pick up. There are no event logs being
generated on either server, so I do not even have a hook that I can use yo
get the server rebooted. Is there a documented way to do failover of MSMQT?

5.. Failure to retransmit messages after the client has gone down. On the
send side, if the client becomes unavailable, entries are generated in HAT
with a Message Status of Consumed and Service Status of Active. Even when th
e
client becomes available again, there is no change, the messages just sit
there. Subsequent messages to the client (even if it is now available) also
just sit there in the same state. Once again, there are no event log entries
,
no retries. If I stop and restart the host instance, the messages are finall
y
transmitted successfully.
I would appreciate feedback from anyone else who has come across this and/or
resolved any of these issues. Is this the expected behaviour? I would have
expected the sends to occur as soon as the client becomes available

Thanks

Andy

[ Post a follow-up to this message ]

Sorry for late answer. Again, for 1 and 2 orphan entries are internal MSMQT
messages. MSMQT needs these and you shouldn't terminate them. You can tell
if a queue is picking up or sending messages by watching the "incomming
messages" and "acknoweledged messages" numbers in the service details page
for MSMQT instances.

3. Only one box is ever goint to consume messages and this is documented.
You will get benefits from NLB if you have more than one client sending
messages to MSMQT. NLB is at the session-level and all the messages sent by
one box will end up processed by the same MSMQT host. If a MSMQT host is
stopped the other should pick up the load after a delay of maximum 10-15
minutes. If it doesn't happen, make sure that you are running on a
supported NLB configuration (MSMQT and MSMQ do not support NAT- network
address transalation).

4. See above.
5. If the client goes down, MSMQT and MSMQ will not re-transmit the
messages imediately. Instead, they will wait 5, 15, 30 minutes or even 6
hours before retrying. The wait time is chosen depending on the actual time
the client was down/unreachable. Wait a while, and MSMQT will re-transmit
the messages.

[ Post a follow-up to this message ]

Iuliu,

Thanks for your very complete reply, I will test to see that I am getting
the behaviour you describe.

Another question if I may. Is there any table or query that I can look at
that will give me the queue depth of receiving and sending queues. I am
looking for something that will give me at least some of the information tha
t
is avalible in the MSMQ MMC snap-in?

Thanks

Andy Norris

[ Post a follow-up to this message ]

Hey Andy, 

Did you get this information?
I'm having serious problems with MSMQT and i can't find information about it
. 
Can you help me?

[ Post a follow-up to this message ]