2

We have been tumbling, for more than a month now, with an issue where a wcf msmq service hosted in IIS7.5 (WAS) will stop processing messages from the queue.

We have been unable to narrow it down more than "at some point" it will stop processing messages from the queue. Calling the svc through a http browser call will start the processing again.

After reading really many articles, blogs and forum posts about this issue we have ensured the following: Security settings, protocol bindings and msmq/service naming, but alas: the service will still stop processing messages (at some point).

Encouraged by this article http://www.daczkowski.net/2010/11/19/leveraging-msmq-in-asp-net-application-through-wcf-service/ we seem to have now finally (almost) eliminated the problem for windows server 2008 r2 sp1 64 bit, but it still seems to appear on Windows 7 32 bit.

Now to get to my question: Can anyone tell me if there actually exists a guarentee (documentation on this would be appreciated) that a msmq WAS hosted wcf service will actually restart (under all conditions) on a IIS7.5 NOT running the AppFabric extension?

I am aware that this question is very compounded, but I'm hard pressed for documentation on why we should extend our OTS package with AppFabric to resolve this restart problem.

Best regards,

Casper Leon Nielsen
  • 2,528
  • 1
  • 28
  • 37

1 Answers1

0

Are you're net.msmq endpoints actually using addresses that IIS can bind to a queue name? It's possible to use non-IIS compatible names in the config and WAS won't really ever be able to wake your application up because WAS will only ever register to queues following a path name it can resolve. In that case you need something like AppFabric or a "startup" script to actually activate your services so that they will bind to the queues in their own.

Drew Marsh
  • 33,111
  • 3
  • 82
  • 100
  • Do you know if Microsoft ever documented this bit of information anywhere? I've searched in MSDN and with all the major search engines and haven't be able to find it. We follow a convention for queue naming of "ServiceFolderName/ServiceName.svc" so that http://hostName/ServiceFolderName/ServiceName.svc is the service endpoint address and private$\ServiceFolderName/ServiceName.svc is the queue name. – Sixto Saez May 27 '11 at 15:35
  • The problem is more compunded than this Im afraid: The service CAN be activated by IIS WAS alone, but will just sometimes(!) stop processing. This is not directly connected with events such as restart of process, server etc, recycle etc. This we have eliminated by now. The service WILL start processing, but will just stop at some point in time. Our services are named "correctly" with matching queue names. – Casper Leon Nielsen May 27 '11 at 15:57
  • @Casper Leon Nielson Hmm, that's very strange indeed. I have never seen that. And there's absolute nothing in the event logs from IIS/WAS? – Drew Marsh May 27 '11 at 17:07
  • 2
    @Sixto Saez Yup, documented pretty clearly here on MSDN: http://msdn.microsoft.com/en-us/library/ms789042.aspx – Drew Marsh May 27 '11 at 17:10
  • Thanks a ton!! I definitely wasn't using the right search terms. That'll be great addition to our service configuration documentation. – Sixto Saez May 27 '11 at 17:24