1

I have an IIS/WAS hosted service running as myself in the development environment. It is activated using net.msmq binding. It is configured to use BufferedReceive (it is a WF service), which involves locking the queue. (Sub queues prefixed lock_ are created).

After some time and after the app pool is terminated, the lock queues are automatically removed.

After moving the system to production, with the environment AFAIK identical, but with the service running as a dedicated account, the lock queues are no longer cleaned up. If I stop the app pool, the lock queue remains, with messages.

The most obvious difference is the accounts under which the service runs but I can't find what kind of permissions are affecting this. Alternatively, is there some other configuration difference I am overlooking. Thanks for help.

Sentinel
  • 3,582
  • 1
  • 30
  • 44
  • What operating system? Also how many characters does the queue name contain? (not full address just name) – tom redfern Nov 30 '12 at 11:13
  • Windows Server 2008 R2 Standard SP1 Also....for some reason on the new server, three lock queues are created and messages moved in to them all. It's strange – Sentinel Nov 30 '12 at 15:27
  • How long is the queue name? Is it longer than 124 chars? – tom redfern Nov 30 '12 at 15:35
  • The queue name is about 60chars long and same on both machines – Sentinel Nov 30 '12 at 15:47
  • Was the server cloned from another one with msmq on? – tom redfern Nov 30 '12 at 16:11
  • No, it wasn't, not as far as I know, but that's a good point...one is Hyper-V (the test one) and the other is VMWare....I wonder if the VMWare machine is a clone...(I could find out...) appreciating the help UPDATE: the main problem now seems to be that there are two separate lock queues being created (on the test only one), and processing the backlog of correlating messages seems to be really slow - I am guessing because some messages go the 'right' queue and the others the 'wrong' queue...I wonder why there are 2 (or more) lock queues with messages in them – Sentinel Nov 30 '12 at 17:53
  • 1
    Msmq doesn't like being cloned it should always be installed from scratch. – tom redfern Nov 30 '12 at 18:05
  • Hugh, it's a good idea, I will check it tomorrow, but I have another idea...I realised that there are two or three other app pools with the same identity and this corresponds with the number of 'false' lock queues being created. What I think might be happening is that the msmq activator is creating a lock queue per channel, but somehow incorrectly treating each app pool as the same consumer.... http://support.microsoft.com/kb/983484 – Sentinel Dec 01 '12 at 23:00
  • I believe this is a problem with the server. Somehow the server is missing necessary hotfixes I think, and I believe what is happening that multiple app pools are being treated as consumers of the message queue. Hence multiple lock sub queues, in which messages fail to get processed by the main channel, and of which lock queues fail to get released when the primary channel closes – Sentinel Dec 01 '12 at 23:03

1 Answers1

1

OK this turns out to be a bug in IIS/WAS.

I had 3 app pools , 2 of which were auto-starting, one of them consuming the msmq. All shared the same AD domain identity, which was shared with the NetMsmqListenerActivator. That netmsmqlistener service was originally stopped, but after I had started it, the symptoms appeared.

Somehow IIS/WAS was creating multiple channels, sending messages to the wrong processes. I have worked around this by creating a separate identity, used now by the mq consuming web service and the netmsmqlistener, followed by a server reboote.

This was a painful problem that only occured on the production server. The lesson learned is to make sure that the production server shares the same hotfixes and patches as the test server .

UPDATE: Hotfix for Win 2k8 R2 SP1: http://support.microsoft.com/kb/2672277

Sentinel
  • 3,582
  • 1
  • 30
  • 44