Risoluzione dei problemi relativi ai messaggi in coda

Questa sezione contiene domande comuni e informazioni sulla risoluzione dei problemi per l'uso delle code in Windows Communication Foundation (WCF).

Domande frequenti

D: Ho usato WCF Beta 1 e ho installato l'hotfix MSMQ. È necessario rimuovere l'hotfix?

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

D: Esistono due associazioni per MSMQ: NetMsmqBinding e MsmqIntegrationBinding. Quando è opportuno utilizzare l'una o l'altra?

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

D: È necessario aggiornare MSMQ per usare le NetMsmqBinding associazioni e MsmqIntegration ?

A: 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?

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

• Le code di messaggi non recapitabili personalizzate sono supportate solo in MSMQ 4.0.

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

• La lettura transazionale remota è supportata solo in MSMQ 4.0.

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?

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

Risoluzione dei problemi

Contenuto della sezione sono contenute risposte per la risoluzione della maggior parte dei problemi frequenti. Alcuni problemi costituiti da limitazioni note sono descritti anche nelle note sulla versione.

D: Si sta tentando di usare una coda privata e si ottiene l'eccezione seguente: System.InvalidOperationExceptionl'URL non è valido. L'URL per la coda non può contenere il carattere '$'. Utilizzare la sintassi in net.msmq://machine/private/queueName per indirizzare una coda privata.

Un: Controllare l'URI (Uniform Resource Identifier) della coda nella configurazione e nel codice. Non utilizzare il carattere "$" nell'URI. Ad esempio, per affrontare 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. Perché?

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

D: L'invio ha avuto esito positivo, ma non viene richiamata alcuna operazione di servizio sul ricevitore. Perché?

Un: Per determinare la risposta, usare l'elenco di controllo seguente:

• Controllare che i requisiti della coda transazionale siano compatibili con le garanzie specificate. Tenere presenti 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 assicurazioni "una sola volta".

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

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

• Controllare la coda dei messaggi non recapitabili. Se sono presenti messaggi, determinare perché non sono stati recapitati.

• Verificare la connettività o eventuali problemi di indirizzamento delle code in uscita.

D: È stata specificata una coda di messaggi non recapitabili personalizzata, ma quando si avvia l'applicazione del mittente, si ottiene un'eccezione che la coda di lettere non recapitabili non viene trovata oppure l'applicazione di invio non ha autorizzazioni per la coda di messaggi non recapitabili. Perché accade?

Un: L'URI della coda di lettere non recapitabili personalizzato 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 oppure è presente una coda di messaggi non recapitabili predefinita?

Un: Se le garanzie sono "esattamente una volta" (ExactlyOnce = true) e se non si specifica una coda di messaggi non recapitabili personalizzata, l'impostazione predefinita è una coda di messaggi non recapitabili a livello di sistema.

Se le garanzie non sono (ExactlyOnce = false), il valore predefinito non è una coda di messaggi non recapitabili.

D: Il servizio viene generata in SvcHost.Open con un messaggio "I requisiti endpointListener non possono essere soddisfatti dal listenerFactory". Perché?

A. Controllare il contratto di servizio. Potrebbe essere stato dimenticato di inserire "IsOneWay=true" in tutte le operazioni del servizio. Le code supportano solo operazioni del servizio unidirezionali.

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

Un: Determinare se l'host del servizio è difettoso. È possibile eseguire questo controllo analizzando la traccia o implementando IErrorHandler. L'host del servizio, per impostazione predefinita, entra in stato di errore se viene rilevato un messaggio non elaborabile.

D: Nella coda sono presenti messaggi, ma il servizio accodato web non viene attivato. Perché?

Un: Il motivo più comune è le autorizzazioni.

1. Assicurarsi che il processo NetMsmqActivator sia in esecuzione e che all'identità del processo NetMsmqActivator sia concessa l'autorizzazione alla lettura e alla scrittura sulla coda.

2. Se NetMsmqActivator sta controllando le code in un computer remoto, assicurarsi che NetMsmqActivator non sia in esecuzione con un token di accesso con restrizioni. Per eseguire NetMsmqActivator con un token di accesso senza restrizioni:

   sc sidtype NetMsmqActivator unrestricted
   

Per i problemi relativi all'host Web non di sicurezza, vedere: Web Hosting di un'applicazione in coda.

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

Un: Impostare Completamento automatico=true nell'operazione corrispondente all'ultimo messaggio della sessione e impostare Completamento automatico=false in tutte le operazioni rimanenti del servizio.

D: Perché il servizio genera un ProtocolException oggetto durante la lettura da una coda che contiene sia messaggi di sessione in coda che messaggi di datagram in coda?

Un: Esiste una differenza fondamentale nel modo in cui i messaggi di sessione in coda e i messaggi di datagrammi in coda sono costituiti. Per questo motivo, un servizio che prevede di leggere un messaggio della sessione in coda non può ricevere un messaggio del datagramma in coda e un servizio che prevede di leggere un messaggio del datagramma in coda non può ricevere un messaggio della sessione. Eseguendo il tentativo di leggere entrambi tipi di messaggi dalla stessa coda viene generata 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 dei messaggi non recapitabili di sistema, così come quella personalizzata, è particolarmente interessata dal problema se un'applicazione invia sia messaggi della sessione sia messaggi del datagramma in coda dallo stesso computer. Se non è possibile inviare correttamente un messaggio, questo viene spostato nella coda dei messaggi non recapitabili. In queste circostanze è possibile che nella coda dei messaggi non recapitabili siano presenti sia messaggi della sessione sia messaggi del datagramma. Non è possibile separare entrambi i tipi di messaggi in fase di esecuzione quando si legge da una coda, pertanto le applicazioni non devono inviare messaggi di sessione in coda e messaggi di datagram in coda dallo stesso computer.

Risoluzione dei problemi specifici dell'integrazione con MSMQ

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

Un: Quando si usa l'associazione di integrazione MSMQ, è necessario usare lo schema msmq.formatname. Ad esempio, msmq.formatname:DIRECT=OS:.\private$\OrdersQueue. Ma quando si specifica la coda dei messaggi non recapitabili personalizzata è necessario utilizzare 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. Perché?

Un: Il canale di integrazione WCF in Windows Vista verifica se è possibile aprire una sottoqueue per la coda dell'applicazione principale per la gestione dei messaggi non elaborati. Il nome della sottoqueue deriva da un URI msmq.formatname passato al listener. Il nome della sottoqueue in MSMQ può essere solo un nome di formato diretto. Per questo motivo viene generato l'errore. Modificare l'URI della coda in modo che il nome sia in un 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. Perché?

Un: Verificare se il messaggio ha un corpo. Se è privo di corpo viene ignorato dal canale di integrazione con MSMQ. Implementare IErrorHandler per ricevere notifica delle eccezioni e controllare le tracce.

Risoluzione dei problemi correlati alla protezione

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.

Un: Per impostazione predefinita, i messaggi vengono firmati usando un certificato interno MSMQ che richiede il servizio directory di Active Directory. In modalità gruppo di lavoro, poiché Active Directory non è disponibile, viene generato un errore nella firma del messaggio. Viene quindi indicato il messaggio nella coda dei messaggi non recapitabili e nella causa dell'errore, 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 è ottenere MsmqTransportSecurity dalla proprietà Transport e impostarlo su Certificate, quindi impostare il certificato client.

Un'ulteriore soluzione alternativa consiste nell'installare MSMQ unitamente all'integrazione con 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?

Un: 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?

Un: Non è possibile usare un archivio certificati del computer locale con la modalità certificato. È necessario copiare il certificato dall'archivio dei certificati del computer all'archivio dell'utente corrente utilizzando lo snap-in Certificati. Per ottenere lo snap-in Certificati:

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 Account utente personale e fare clic su Fine.

6. Aggiungere quindi un secondo snap-in Certificati usando 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 del computer all'archivio dell'utente corrente.

D: Quando il servizio legge da una coda in un altro computer in modalità gruppo di lavoro, viene visualizzata un'eccezione di 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" all'elenco di controllo di accesso (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 ha esito negativo con un certificato non valido. Com'è possibile risolvere il problema?

Un: Controllare la configurazione dell'associazione. Per l'associazione predefinita è attivata la protezione del trasporto MSMQ per la firma del messaggio. Disattivarla.

Ricezioni transazionali remote

D: Quando si dispone di una coda nel computer A e di un servizio WCF che legge i messaggi da una coda nel computer B (scenario di ricezione transazionata remota), 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 è possibile fare per risolvere il problema?

Un: Esistono tre possibili motivi per questo:

• In modalità di dominio per la ricezione transazionale remota è necessario l'accesso alla rete di Microsoft Distributed Transaction Coordinator (MSDTC). È possibile abilitare questa opzione usando Componenti aggiuntivi/rimuovi.

  

• Verificare la modalità di autenticazione per la comunicazione con il gestore 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 in Windows Vista supporta la lettura transazionata remota. MSMQ con le 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é viene generata un'eccezione di accesso negato durante la lettura dalla coda?

Un: L'accesso in lettura al servizio di rete deve essere aggiunto all'ACL della coda per garantire che un servizio di rete possa 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 questo scopo, è necessario configurare il servizio di attivazione MSMQ in modo che venga eseguito come servizio di rete e aggiungere l'accesso al servizio di rete alla coda nel computer remoto.

Utilizzo di associazioni MSMQ personalizzate con ReceiveContext abilitato

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