Risoluzione dei problemi relativi alla messaggistica in coda

Questa sezione contiene domande frequenti e informazioni sulla risoluzione dei problemi relativi all'uso delle code in Windows Communication Foundation (WCF).

Domande frequenti

D: È stato usato WCF Beta 1 ed è stato installato l'hotfix MSMQ. È necessario rimuovere l'hotfix?

R: Sì. Questo hotfix non è più supportato. WCF ora funziona in MSMQ senza un requisito di hotfix.

D: Esistono due associazioni per MSMQ: NetMsmqBinding e MsmqIntegrationBinding. Cosa devo usare e quando?

Un: Usare il NetMsmqBinding quando si vuole usare MSMQ come trasporto per la comunicazione in coda tra due applicazioni WCF. Quando si desidera utilizzare applicazioni MSMQ esistenti per comunicare con le nuove applicazioni WCF, utilizzare MsmqIntegrationBinding.

D: È necessario aggiornare MSMQ per usare i NetMsmqBinding binding e MsmqIntegration?

R: No. Entrambe le associazioni funzionano con MSMQ 3.0 in Windows XP e Windows Server 2003. Alcune funzionalità delle associazioni diventano disponibili quando si esegue l'aggiornamento a MSMQ 4.0 in Windows Vista.

D: Quali funzionalità delle NetMsmqBinding associazioni e MsmqIntegrationBinding sono disponibili in MSMQ 4.0 ma non in MSMQ 3.0?

A: Le seguenti funzionalità sono disponibili in MSMQ 4.0 ma non in MSMQ 3.0:

• La coda dei messaggi non recapitati personalizzata è supportata solo in MSMQ 4.0.

• MSMQ 3.0 e 4.0 gestiscono i messaggi velenosi in modo diverso.

• Solo MSMQ 4.0 supporta la lettura transazionata remota.

D: È possibile usare MSMQ 3.0 su un lato di una comunicazione in coda e MSMQ 4.0 sull'altro lato?

R: Sì.

D: Si desidera integrare applicazioni MSMQ esistenti con nuovi client o server WCF. È necessario aggiornare entrambi i lati dell'infrastruttura MSMQ?

R: No. Non è necessario eseguire l'aggiornamento a MSMQ 4.0 su entrambi i lati.

Risoluzione dei problemi

Questa sezione contiene le risposte ai problemi più comuni di risoluzione dei problemi. Alcuni problemi che sono limitazioni note sono descritti anche nelle note sulla versione.

D: Sto provando ad usare una coda privata e viene visualizzata l'eccezione seguente: System.InvalidOperationExceptionL'URL non è valido. L'URL della coda non può contenere il carattere '$'. Utilizzare la sintassi net.msmq://machine/private/queueName per indirizzare una coda privata.

A: Controllare l'URI (Uniform Resource Identifier) della coda nella configurazione e nel codice. Non usare il carattere "$" nell'URI. Ad esempio, per gestire una coda privata denominata OrdersQueue, specificare l'URI come net.msmq://localhost/private/ordersQueue.

D: La chiamata ServiceHost.Open() all'applicazione in coda genera l'eccezione seguente: System.ArgumentExceptionun indirizzo di base non può contenere una stringa di query URI. Why?

A: Controllare l'URI della coda nel file di configurazione e nel codice. Mentre le code MSMQ supportano l'uso del carattere '?', gli URI interpretano questo carattere come inizio di una query string. Per evitare questo problema, usare nomi di coda che non contengono caratteri '?'.

D: L'invio è riuscito, ma non viene richiamata alcuna operazione di servizio sul ricevitore. Why?

A: Per determinare la risposta, seguire la lista di controllo seguente:

• Verificare che i requisiti della coda transazionale siano compatibili con le garanzie specificate. Si notino i principi seguenti:

  • È possibile inviare messaggi durevoli (datagrammi e sessioni) con garanzie "esattamente una volta" (ExactlyOnce = true) solo a una coda transazionale.

  • È possibile inviare sessioni solo con garanzie "esattamente una volta".

  • Una transazione è necessaria per ricevere messaggi in una sessione da una coda transazionale.

  • È possibile inviare o ricevere messaggi volatili o durevoli (solo datagrammi) senza garanzie (ExactlyOnce = false) solo a una coda non transazionale.

• Verificare la coda della posta non consegnata. Se si trovano i messaggi lì, determinare il motivo per cui non sono stati recapitati.

• Controllare le code in uscita per individuare la connettività o risolvere i problemi.

D: È stata specificata una coda di messaggi non recapitabili personalizzata, ma quando si avvia l'applicazione mittente si ottiene un'eccezione che la coda dei messaggi non recapitabili non viene trovata oppure l'applicazione di invio non dispone dell'autorizzazione per la coda di messaggi non recapitabili. Perché succede?

A: L'URI personalizzato della coda messaggi non recapitabili deve includere un "localhost" o il nome del computer nel primo segmento, ad esempio net.msmq://localhost/private/myAppdead-letter queue.

D: È sempre necessario definire una coda di messaggi non recapitabili personalizzata o è presente una coda di messaggi non recapitabili predefinita?

A: Se le garanzie sono "esattamente una volta" (ExactlyOnce = true) e se non si specifica una coda di messaggi morti personalizzata, il valore predefinito è una coda di messaggi morti transazionali a livello di sistema.

Se non ci sono garanzie (ExactlyOnce = false), l'impostazione predefinita è l'assenza di funzionalità della coda di messaggi non recapitabili.

D: Il servizio genera un'eccezione in SvcHost.Open con il messaggio "I requisiti di EndpointListener non possono essere soddisfatti da ListenerFactory". Why?

A. Controllare il contratto di servizio. È possibile che si sia dimenticato di inserire "IsOneWay=true" in tutte le operazioni del servizio. Le code supportano solo operazioni di servizio unidirezionali.

D: Nella coda sono presenti messaggi, ma non viene richiamata alcuna operazione del servizio. Qual è il problema?

A: Determinare se l'host del servizio è in errore. È possibile controllare esaminando la traccia o implementando IErrorHandler. L'host del servizio si arresta, per impostazione predefinita, se viene rilevato un messaggio avvelenato.

D: Ci sono messaggi nella coda, ma il mio servizio in coda ospitato sul Web non si attiva. Why?

A: Il motivo più comune sono le autorizzazioni.

1. Assicurarsi che il NetMsmqActivator processo sia in esecuzione e che all'identità del NetMsmqActivator processo venga assegnata l'autorizzazione di lettura e ricerca per la coda.

2. NetMsmqActivator Se si sta monitorando le code in una macchina remota, assicurarsi che NetMsmqActivator non venga eseguito sotto un token limitato. Per eseguire NetMsmqActivator con un token senza restrizioni:

   sc sidtype NetMsmqActivator unrestricted
   

Per i problemi dell'host Web non legati alla sicurezza, fare riferimento a: Web Hosting di un'applicazione in coda.

D: Qual è il modo più semplice per accedere alle sessioni?

A: Imposta AutoComplete=true sull'operazione che corrisponde all'ultimo messaggio nella sessione e imposta AutoComplete=false su tutte le operazioni di servizio rimanenti.

D: Perché il mio servizio genera un'eccezione ProtocolException durante la lettura da una coda che contiene sia messaggi di sessione in coda sia messaggi di datagramma in coda?

A: Esiste una differenza fondamentale nel modo in cui i messaggi di sessione in coda e i messaggi datagrammi in coda sono composti. Per questo motivo, un servizio che prevede di leggere un messaggio di sessione in coda non può ricevere un messaggio di datagramma in coda e un servizio che prevede di leggere un messaggio di datagram in coda non può ricevere un messaggio di sessione. Il tentativo di leggere entrambi i tipi di messaggi dalla stessa coda genera l'eccezione seguente:

System.ServiceModel.MsmqPoisonMessageException: The transport channel detected a poison message. This occurred because the message exceeded the maximum number of delivery attempts or because the channel detected a fundamental problem with the message. The inner exception may contain additional information.
---> System.ServiceModel.ProtocolException: An incoming MSMQ message contained invalid or unexpected .NET Message Framing information in its body. The message cannot be received. Ensure that the sender is using a compatible service contract with a matching SessionMode.

La coda di messaggi non recapitabili di sistema, nonché qualsiasi coda di messaggi non recapitabili personalizzata, è particolarmente soggetta a questo problema se un'applicazione invia messaggi di sessione in coda e messaggi di datagram in coda dallo stesso computer. Se non è possibile inviare correttamente un messaggio, viene spostato nella coda di messaggi non recapitabili. In queste circostanze, è possibile che nella coda dei messaggi non recapitabili ci siano sia messaggi di sessione che di datagrammi. Non è possibile separare entrambi i tipi di messaggi in fase di esecuzione durante la lettura da una coda, pertanto le applicazioni non devono inviare messaggi di sessione in coda e messaggi di datagram in coda dallo stesso computer.

Integrazione MSMQ: risoluzione dei problemi specifici

D: Quando si invia un messaggio o quando si apre l'host del servizio, viene visualizzato un errore che indica che lo schema è errato. Why?

A: Quando si utilizza l'integrazione MSMQ, è necessario usare lo schema msmq.formatname. Ad esempio, msmq.formatname:DIRECT=OS:.\private$\OrdersQueue. Tuttavia, quando si specifica la coda di messaggi non recapitabili personalizzata, è necessario usare lo schema net.msmq.

D: Quando si usa un nome di formato pubblico o privato e si apre l'host del servizio in Windows Vista, viene visualizzato un errore. Why?

A: Il canale di integrazione WCF in Windows Vista verifica se è possibile aprire una coda secondaria per la coda principale dell'applicazione per la gestione dei messaggi non elaborabili. Il nome della coda secondaria è derivato da un URI msmq.formatname passato al listener. Il nome della coda secondaria in MSMQ può essere solo un nome di formato diretto. Quindi viene visualizzato l'errore. Modificare l'URI della coda in un nome di formato diretto.

D: Quando si riceve un messaggio da un'applicazione MSMQ, il messaggio si trova nella coda e non viene letto dall'applicazione WCF ricevente. Why?

A: Verificare se il messaggio ha un contenuto. Se il messaggio non ha corpo, il canale di integrazione MSMQ ignora il messaggio. Implementare IErrorHandler per ricevere una notifica delle eccezioni e controllare le tracce.

risoluzione dei problemi relativi alla sicurezza

D: Quando si esegue l'esempio che usa un'associazione predefinita in modalità gruppo di lavoro, i messaggi sembrano essere inviati ma non vengono mai ricevuti dal ricevitore.

A: Per impostazione predefinita, i messaggi vengono firmati usando un certificato interno MSMQ che richiede il servizio di directory Active Directory. In modalità gruppo di lavoro, poiché Active Directory non è disponibile, la firma del messaggio ha esito negativo. Il messaggio viene quindi inserito nella coda dei messaggi non recapitabili e viene indicata la causa del fallimento, come ad esempio "Firma non valida".

La soluzione alternativa consiste nel disattivare la sicurezza. Questa operazione viene eseguita impostando Mode = None per renderlo funzionante in modalità gruppo di lavoro.

Un'altra soluzione alternativa consiste nell'ottenere MsmqTransportSecurity dalla Transport proprietà e impostarlo su Certificatee impostare il certificato client.

Un'altra soluzione alternativa consiste nell'installare MSMQ con l'integrazione di Active Directory.

D: Quando si invia un messaggio con associazione predefinita (sicurezza del trasporto attivata) in Active Directory a una coda, viene visualizzato un messaggio "certificato interno non trovato". Com'è possibile risolvere il problema?

A: Ciò significa che il certificato in Active Directory per il mittente deve essere rinnovato. A tale scopo, aprire Pannello di controllo, Strumenti di amministrazione, Gestione computer, fare clic con il pulsante destro del mouse su MSMQ e scegliere Proprietà. Selezionare la scheda Certificato utente e fare clic sul pulsante Rinnova .

D: Quando si invia un messaggio usando Certificate e si specifica il certificato da usare, viene visualizzato un messaggio "Certificato non valido". Com'è possibile risolvere il problema?

A: Non è possibile usare un archivio certificati del computer locale nella modalità certificato. È necessario copiare il certificato dall'archivio certificati del computer nell'archivio utente corrente usando lo snap-in Certificato. Per ottenere lo snap-in Certificato:

1. Fare clic su Start, selezionare Esegui, digitare mmce fare clic su OK.

2. In Microsoft Management Console aprire il menu File e selezionare Aggiungi/Rimuovi snap-in.

3. Nella finestra di dialogo Aggiungi/Rimuovi snap-in fare clic sul pulsante Aggiungi .

4. Nella finestra di dialogo Aggiungi snap-in autonomo selezionare Certificati e fare clic su Aggiungi.

5. Nella finestra di dialogo Snap-in Certificati, selezionare Il mio account utente e fare clic su Fine.

6. Quindi, aggiungere un secondo snap-in Certificati utilizzando i passaggi precedenti, ma questa volta selezionare Account computer e fare clic su Avanti.

7. Selezionare Computer locale e fare clic su Fine. È ora possibile trascinare i certificati dall'archivio certificati del computer all'archivio utenti corrente.

D: Quando il mio servizio legge da una coda su un altro computer in modalità gruppo di lavoro, viene generata un'eccezione "accesso negato".

Un: In modalità gruppo di lavoro, affinché un'applicazione remota ottenga l'accesso alla coda, l'applicazione deve disporre dell'autorizzazione per accedere alla coda. Aggiungere "Accesso anonimo" alla lista di controllo degli accessi (ACL) della coda e concedere l'autorizzazione di lettura.

D: Quando un client del servizio di rete (o un client che non dispone di un account di dominio) invia un messaggio in coda, l'invio non riesce con un certificato non valido. Com'è possibile risolvere il problema?

A: Controllare la configurazione dell'associazione. L'associazione predefinita ha la sicurezza di trasporto MSMQ attivata per firmare il messaggio. Disattivarlo.

Ricezioni remote transazionate

D: Quando ho una coda sul computer A e un servizio WCF che legge i messaggi da una coda sul computer B (scenario di ricezione transazionato remoto), i messaggi non vengono letti dalla coda. Le informazioni di traccia indicano che la ricezione non è riuscita con il messaggio "Impossibile importare la transazione". Cosa posso fare per risolvere questo problema?

A: Esistono tre possibili motivi per questo:

• Se si è in modalità di dominio, la ricezione transazionale remota richiede l'accesso alla rete microsoft Distributed Transaction Coordinator (MSDTC). È possibile abilitare questa opzione usando Componenti aggiuntivi/rimuovi.

  

• Controllare la modalità di autenticazione per la comunicazione con gestione transazioni. Se si è in modalità gruppo di lavoro, è necessario selezionare "Nessuna autenticazione richiesta". Se si è in modalità di dominio, è necessario selezionare "Autenticazione reciproca obbligatoria".

  

• Assicurarsi che MSDTC sia incluso nell'elenco delle eccezioni nelle impostazioni del firewall di connessione Internet .

• Assicurarsi di usare Windows Vista. MSMQ su Windows Vista supporta la lettura transazionale remota. MSMQ nelle versioni precedenti di Windows non supporta la lettura transazionale remota.

D: Quando il servizio che legge dalla coda è un servizio di rete, ad esempio in un host Web, perché ottengo un'eccezione di accesso negato quando leggo dalla coda?

Un: L'accesso in lettura del servizio di rete deve essere aggiunto all'ACL della coda per permettere a un servizio di rete di leggere dalla coda.

D: È possibile usare il servizio di attivazione MSMQ per attivare le applicazioni in base ai messaggi in una coda in un computer remoto?

R: Sì. A tale scopo, è necessario configurare il servizio di attivazione MSMQ per l'esecuzione come servizio di rete e aggiungere l'accesso al servizio di rete alla coda nel computer remoto.

Uso di associazioni MSMQ personalizzate con ReceiveContext abilitato

Quando si utilizza un binding MSMQ personalizzato con ReceiveContext abilitato, l'elaborazione di un messaggio in ingresso utilizza un thread dal pool di thread perché il MSMQ nativo non supporta il completamento di I/O per le ricezioni asincrone ReceiveContext. Ciò è dovuto al fatto che l'elaborazione di un messaggio di questo tipo usa transazioni interne per ReceiveContext e MSMQ non supporta l'elaborazione asincrona. Per risolvere questo problema, è possibile aggiungere un SynchronousReceiveBehavior oggetto all'endpoint per forzare l'elaborazione sincrona o impostare su MaxPendingReceives 1.