2015-01-08 3 views
1

У меня есть определенная служба, которая работает через WCF и MSMQ. Все работает нормально, но у нас есть это требование, в котором говорится, что если что-то неожиданное происходит при обработке одной работы, это не должно затрагивать никого другого. Услуга спроектирована так, чтобы быть надежной, и она есть. Мы никогда не сталкивались с этим сбой за два дня операций, однако в последнее время наши клиенты любят убивать процесс обслуживания и жалуются, что потеряно больше одной работы.Несколько сообщений, удаленных из MSMQ

Чтобы исследовать, я добавил таймер, который отслеживает содержимое очереди каждые 200 мс и обнаружил что-то неожиданное. При обработке запросов WCF удаляет из очереди более одного сообщения. Вот smartinspec следа соответствующих событий (числа в центральной колонке резьба ида):

enter image description here

Всегда кажется, держать одно сообщение буферизованного где-то в процессе обслуживания. Я просматривал документацию WCF, и я не нашел ссылки на это поведение Есть ли что-нибудь, что я могу сделать, чтобы предотвратить эту буферизацию, или вы могли бы сослаться на некоторые соответствующие статьи?

Вот класс обслуживания:

[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Single)] 
public class TheService : ITheService 
{ 
    private readonly ITraceFacade trace = TraceFactory.Resolve();//for tracing 

    public ClientCodeWrapper clientCodeWrapper { get; set; }// a wrapper for libraries written by our client. it's instantiated and set in the OnStart method of the service host class 

    public void ProcessJob(long jobId) 
    { 
     using (this.trace.ActivityScope(string.Format(CultureInfo.InvariantCulture, "The Service.ProcessJob({0})", jobId))) 
     {   
     this.clientCodeWrapper.ProcessJob(jobId);   
     } 
    }  
} 

и это мой конфиг

<system.serviceModel> 
    <bindings> 
    <netMsmqBinding> 
     <binding name="MsmqBindingNonTransactionalNoSecurity" exactlyOnce="false"> 
     <security mode="None"/> 
     </binding> 
    </netMsmqBinding> 
    </bindings> 

    <services> 
    <service name="TheService"> 
     <host> 
     <baseAddresses> 
      <add baseAddress="http://localhost:8080/TheServiceIn" />   
     </baseAddresses> 
     </host>   
     <endpoint address="net.msmq://localhost/private/TheServiceIn" 
       binding="netMsmqBinding" 
       bindingConfiguration="MsmqBindingNonTransactionalNoSecurity" 
       contract="ITheService">   
     <identity> 
      <dns value="localhost"/> 
     </identity> 
     </endpoint>  

     <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/> 
    </service> 
    </services> 
</system.serviceModel> 
+0

Я уже сталкивался с этим поведением. Вы ничего не можете с этим поделать. Именно так работает стек netMsmqBinding. –

ответ

2

обслуживание Что вы видите, кажется, как раз ожидали меня. Верно, что WCF может читать несколько сообщений очереди для обработки. Как правило, это не проблема, и с транзакционными очередями это определенно не будет проблемой (поскольку каждая отдельная транзакция будет выполняться только после завершения обработки сообщения, в противном случае транзакция будет прервана и сообщение будет возвращено в очередь) ,

Таким образом, вы отказались от обработки сообщений таким образом, чтобы избежать утерянных сообщений путем отключения транзакций и использования очередей без транзакций. В основном вы сказали MSMQ и WCF, что вполне нормально время от времени терять сообщения.

Рассмотрите, что произойдет, если ваша машина (или MSMQservice) разбилась: вы не потеряете только одно задание; вы потеряете все из них, так как сообщения не будут сохраняться.

+0

Согласовано, хотя включение транзакционной очереди имеет тот недостаток, что его клиенты больше не смогут * убить службу *, чтобы удалить сообщение, которое задерживает обработку. –

+0

@TomRedfern Я не верю, что это будет проблемой, но спасибо за то, что разделили проблему. –

+0

Я отметил это как официальный ответ, потому что на самом деле работают транснациональные очереди. Однако мы решили оставить программное обеспечение без изменений, поскольку область транзакций мешает нашим транзакциям sql. –

 Смежные вопросы

  • Нет связанных вопросов^_^