2013-07-19 13 views
5

Ho un servizio Windows scritto in .NET 4 che crea più thread che contengono cicli infiniti mentre si esegue (in esecuzione). Quando interrompo il servizio, il booleano in esecuzione diventa falso e interrompiamo il ciclo while e una volta che ciascun thread lo fa, il servizio si interrompe definitivamente.Come posso cancellare un messaggio Microsoft ServiceBus MessageReceiver?

Nel frattempo, chiama oMessageReceiver.Receive (TimeSpan.FromSeconds (30)). così a volte quando provo a interrompere il servizio, devo aspettare fino a 30 secondi affinché il processo Receive() vada in timeout.

Un'opzione potrebbe essere quella di ridurre il timeout da 30 secondi a qualcosa di più piccolo. Non sono sicuro di quali penalizzazioni dovessero comportare, ma dal momento che il processo non funziona senza un BrokeredMessage, vorrei davvero mantenere l'ascoltatore aperto il più spesso e il più a lungo possibile.

Vedo che c'è un metodo .BeginReceive() sul MessageReceiver. Credo che ci sarebbe un modello di programmazione che potrei usare qui per evitare che il mio servizio si blocchi mentre attendevo il timeout di Receive. Qualcuno può descrivere come utilizzare le funzioni APM Begin/End in un servizio Windows che funziona all'infinito?

risposta

2

Chiudere MessageFactory da cui è stato creato il MessageReceiver per annullare l'operazione di ricezione. Ho avuto lo stesso problema quando ho chiamato Abort o Close sul MessageReceiver prima di chiudere il factory dei messaggi.

L'utilizzo dell'inizio/fine asincrono non fa alcuna differenza. Come nota a margine se si desidera eseguire in modo asincrono la possibilità di creare wrapper di attività utilizzando TaskFactory.FromAsync per sfruttare le nuove funzionalità asincrone.

vedere anche la mia risposta a questo domanda per quanto riguarda lo stesso problema:

Cancel an Azure Service Bus QueueClient long running Receive?

4

Nel nuovo SDK di Windows Azure 2.1 hanno modificato il modello di ruolo del bus di servizio per utilizzare OnMessage introdotto recentemente nell'SDK 2.0. Puoi dare un'occhiata a quel modello per vedere quale codice usa per iniziare. In questo approccio si imposta un'azione da eseguire quando arriva un messaggio. In effetti, puoi anche impostare una proprietà MaxConcurrentCalls su OnMessageOptions durante la configurazione che gestirà i tuoi thread aggiuntivi per te. Se hai utilizzato l'approccio OnMessage, avresti fatto qualcosa di simile in cui il servizio avrebbe chiuso il QueueClient in modo che non potesse più elaborarlo. È inoltre possibile tenere traccia con un indicatore sincronizzato attivo se un messaggio su QUALSIASI thread si stava elaborando e attendere solo il completamento dell'elaborazione.

Per quanto riguarda il modo migliore per utilizzare i metodi asincroni (inizio/fine), controllare "Best Practices for Leveraging Windows Azure Service Bus Brokered Messaging" che ha diversi esempi.

Problemi correlati