Felsöka köade meddelanden
Det här avsnittet innehåller vanliga frågor och felsökningshjälp för att använda köer i Windows Communication Foundation (WCF).
Vanliga frågor
F: Jag använde WCF Beta 1 och jag installerade MSMQ-snabbkorrigeringen. Behöver jag ta bort snabbkorrigeringen?
S: Ja. Snabbkorrigeringen stöds inte längre. WCF fungerar nu på MSMQ utan krav på snabbkorrigering.
F: Det finns två bindningar för MSMQ: NetMsmqBinding och MsmqIntegrationBinding. Vad ska jag använda och när?
A:NetMsmqBinding Använd när du vill använda MSMQ som transport för köad kommunikation mellan två WCF-program. MsmqIntegrationBinding Använd när du vill använda befintliga MSMQ-program för att kommunicera med nya WCF-program.
F: Måste jag uppgradera MSMQ för att använda NetMsmqBinding bindningarna och MsmqIntegration ?
S: Nej. Båda bindningarna fungerar med MSMQ 3.0 på Windows XP och Windows Server 2003. Vissa funktioner i bindningarna blir tillgängliga när du uppgraderar till MSMQ 4.0 i Windows Vista.
F: Vilka funktioner i NetMsmqBinding bindningarna och MsmqIntegrationBinding är tillgängliga i MSMQ 4.0 men inte i MSMQ 3.0?
A: Följande funktioner är tillgängliga i MSMQ 4.0 men inte i MSMQ 3.0:
Anpassad kö med obeställbara meddelanden stöds endast på MSMQ 4.0.
MSMQ 3.0 och 4.0 hanterar giftmeddelanden på olika sätt.
Endast MSMQ 4.0 stöder fjärrstyrd läsning.
F: Kan jag använda MSMQ 3.0 på ena sidan av en köad kommunikation och MSMQ 4.0 på den andra sidan?
S: Ja.
F: Jag vill integrera befintliga MSMQ-program med nya WCF-klienter eller -servrar. Behöver jag uppgradera båda sidor av min MSMQ-infrastruktur?
S: Nej. Du behöver inte uppgradera till MSMQ 4.0 på någon sida.
Felsökning
Det här avsnittet innehåller svar på de vanligaste felsökningsproblemen. Vissa problem som är kända begränsningar beskrivs också i viktig information.
F: Jag försöker använda en privat kö och får följande undantag: System.InvalidOperationException: URL:en är ogiltig. URL:en för kön får inte innehålla $-tecknet. Använd syntaxen i net.msmq://machine/private/queueName för att adressera en privat kö.
A: Kontrollera kön URI (Uniform Resource Identifier) i konfigurationen och koden. Använd inte $-tecknet i URI:n. Om du till exempel vill adressera en privat kö med namnet OrdersQueue anger du URI:n som net.msmq://localhost/private/ordersQueue.
F: När jag anropar ServiceHost.Open() i mitt köade program genereras följande undantag: System.ArgumentException: En basadress får inte innehålla en URI-frågesträng. Varför?
A: Kontrollera kö-URI:n i konfigurationsfilen och i koden. Även om MSMQ-köer stöder användningen av tecknet ?, tolkar URI:er det här tecknet som början på en strängfråga. Undvik det här problemet genom att använda könamn som inte innehåller "?"-tecken.
F: Min sändning lyckades men ingen tjänståtgärd anropas på mottagaren. Varför?
A: Ta reda på svaret genom att gå igenom följande kontrolllista:
Kontrollera att kraven för transaktionskön är kompatibla med de angivna garantierna. Observera följande principer:
Du kan skicka varaktiga meddelanden (datagram och sessioner) med "exakt en gång"-garantier (ExactlyOnce =
true) endast till en transaktionskö.Du kan bara skicka sessioner med "exakt en gång"-garantier.
En transaktion krävs för att ta emot meddelanden i en session från en transaktionskö.
Du kan skicka eller ta emot ej beständiga eller varaktiga meddelanden (endast datagram) utan garantier (ExactlyOnce =
false) endast till en icke-transaktionell kö.
Kontrollera kön med obeställbara meddelanden. Om du hittar meddelandena där avgör du varför de inte levererades.
Kontrollera de utgående köerna för anslutning eller åtgärda problem.
F: Jag har angett en anpassad kö för obeställbara meddelanden, men när jag startar avsändarprogrammet får jag ett undantag om att kön med obeställbara meddelanden inte hittas eller att det sändande programmet inte har behörighet till kön med obeställbara meddelanden. Varför händer det här?
A: Den anpassade kö-URI:n för obeställbara meddelanden måste innehålla en "localhost" eller datornamnet i det första segmentet, till exempel net.msmq://localhost/private/myAppdead-letter.
F: Är det alltid nödvändigt att definiera en anpassad kö med obeställbara meddelanden eller finns det en standardkö med obeställbara meddelanden?
A: Om garantierna är "exakt en gång" (ExactlyOnce = true), och om du inte anger en anpassad kö med obeställbara meddelanden, är standardvärdet en systemomfattande transaktionskö med obeställbara meddelanden.
Om försäkringarna inte är några (ExactlyOnce = false) är standardinställningen ingen köfunktion med obeställbara meddelanden.
F: Min tjänst genererar SvcHost.Open med meddelandet "EndpointListener-krav kan inte uppfyllas av ListenerFactory". Varför?
A. Kontrollera ditt servicekontrakt. Du kanske har glömt att sätta "IsOneWay=true" på alla tjänståtgärder. Köer stöder endast envägstjänståtgärder.
F: Det finns meddelanden i kön men ingen tjänståtgärd anropas. Vad är problemet?
A: Kontrollera om tjänstvärden har fel. Du kan kontrollera genom att titta på spårningen eller implementera IErrorHandler. Tjänstvärdfel, som standard, om ett giftmeddelande identifieras.
F: Det finns meddelanden i kön men min webbaserade köade tjänst aktiveras inte. Varför?
A: Den vanligaste orsaken är behörigheter.
Kontrollera att processen körs och att
NetMsmqActivatorprocessensNetMsmqActivatoridentitet får läs- och sökbehörighet i kön.NetMsmqActivatorOm är övervakningsköer på en fjärrdator kontrollerar du attNetMsmqActivatorinte körs under en begränsad token. Så här körNetMsmqActivatordu med en obegränsad token:sc sidtype NetMsmqActivator unrestricted
För icke-säkerhetsrelaterade problem med webbvärdar, se: Webbvärd för ett köat program.
F: Vilket är det enklaste sättet att komma åt sessioner?
A: Ange AutoComplete=true för den åtgärd som motsvarar det sista meddelandet i sessionen och ange AutoComplete=false för alla återstående tjänståtgärder.
F: Varför genererar min tjänst en ProtocolException när jag läser från en kö som innehåller både köade sessionsmeddelanden och köade datagrammeddelanden?
A: Det finns en grundläggande skillnad i hur köade sessionsmeddelanden och köade datagrammeddelanden skapas. Därför kan en tjänst som förväntar sig att läsa ett i köat sessionsmeddelande inte ta emot ett köat datagrammeddelande och en tjänst som förväntar sig att läsa ett köat datagrammeddelande kan inte ta emot ett sessionsmeddelande. Om du försöker läsa båda typerna av meddelanden från samma kö genereras följande undantag:
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.
Systemets kö för obeställbara meddelanden samt eventuella anpassade köer med obeställbara meddelanden är särskilt mottagliga för det här problemet om ett program skickar både köade sessionsmeddelanden och köade datagrammeddelanden från samma dator. Om det inte går att skicka ett meddelande flyttas det till kön med obeställbara meddelanden. Under dessa omständigheter är det möjligt att ha både sessions- och datagrammeddelanden i kön med obeställbara meddelanden. Det finns inget sätt att separera båda typerna av meddelanden vid körning när de läser från en kö. Därför bör program inte skicka både köade sessionsmeddelanden och köade datagrammeddelanden från samma dator.
MSMQ-integrering: Specifik felsökning
F: När jag skickar ett meddelande, eller när jag öppnar tjänstvärden, får jag ett felmeddelande som anger att schemat är fel. Varför?
A: När du använder MSMQ-integreringsbindningen måste du använda msmq.formatname-schemat. Till exempel msmq.formatname:DIRECT=OS:.\private$\OrdersQueue. Men när du anger den anpassade kön för obeställbara meddelanden måste du använda net.msmq-schemat.
F: När jag använder ett offentligt eller privat formatnamn och öppnar tjänstvärden i Windows Vista får jag ett felmeddelande. Varför?
A: WCF-integreringskanalen i Windows Vista kontrollerar om en underfråga kan öppnas för huvudprogramkön för hantering av giftmeddelanden. Underfrågans namn härleds från en URI för msmq.formatname som skickas till lyssnaren. Underfrågans namn i MSMQ kan bara vara ett direkt formatnamn. Så du ser felet. Ändra kö-URI:n till ett direkt formatnamn.
F: När du tar emot ett meddelande från ett MSMQ-program finns meddelandet i kön och läss inte av det mottagande WCF-programmet. Varför?
A: Kontrollera om meddelandet har en brödtext. Om meddelandet inte innehåller någon brödtext ignorerar MSMQ-integreringskanalen meddelandet. Implementera IErrorHandler för att meddelas om undantag och kontrollera spårningarna.
Security-Related felsökning
F: När jag kör exemplet som använder en standardbindning i arbetsgruppsläge verkar meddelanden skickas men tas aldrig emot av mottagaren.
A: Som standard signeras meddelanden med ett internt MSMQ-certifikat som kräver Active Directory-katalogtjänsten. Det går inte att signera meddelandet eftersom Active Directory inte är tillgängligt i arbetsgruppsläge. Meddelandet hamnar alltså i kön med obeställbara meddelanden och orsaken till felet, till exempel "Felaktig signatur", anges.
Lösningen är att stänga av säkerheten. Detta görs genom att ställa in Mode = None så att det fungerar i arbetsgruppsläge.
En annan lösning är att hämta MsmqTransportSecurity från Transport -egenskapen och ställa in den på Certificate, och ange klientcertifikatet.
En annan lösning är att installera MSMQ med Active Directory-integrering.
F: När jag skickar ett meddelande med standardbindning (transportsäkerhet aktiverat) i Active Directory till en kö får jag ett meddelande om att det inte gick att hitta ett internt certifikat. Hur gör jag för att åtgärda det här?
A: Det innebär att certifikatet i Active Directory för avsändaren måste förnyas. Det gör du genom att öppna Kontrollpanelen, Administrationsverktyg, Datorhantering, högerklicka på MSMQ och välja Egenskaper. Välj fliken Användarcertifikat och klicka på knappen Förnya .
F: När jag skickar ett meddelande med Certificate och anger vilket certifikat som ska användas får jag meddelandet "Ogiltigt certifikat". Hur gör jag för att åtgärda det här?
A: Du kan inte använda ett lokalt certifikatarkiv med certifikatläge. Du måste kopiera certifikatet från datorns certifikatarkiv till det aktuella användararkivet med hjälp av snapin-modulen Certifikat. Så här hämtar du snapin-modulen certifikat:
Klicka på Start, välj Kör, skriv
mmcoch klicka på OK.I Microsoft Management Console öppnar du menyn Arkiv och väljer Lägg till/ta bort snapin-modul.
I dialogrutan Lägg till/ta bort snapin-modul klickar du på knappen Lägg till .
I dialogrutan Lägg till fristående snapin-modul väljer du Certifikat och klickar på Lägg till.
I dialogrutan Snapin-modul för certifikat väljer du Mitt användarkonto och klickar på Slutför.
Lägg sedan till en andra snapin-modul för certifikat med hjälp av föregående steg, men den här gången väljer du Datorkonto och klickar på Nästa.
Välj Lokal dator och klicka på Slutför. Nu kan du dra och släppa certifikat från datorns certifikatarkiv till det aktuella användararkivet.
F: När min tjänst läser från en kö på en annan dator i arbetsgruppsläge får jag ett undantag om nekad åtkomst.
A: För att ett fjärrprogram ska få åtkomst till kön i arbetsgruppsläge måste programmet ha behörighet att komma åt kön. Lägg till "Anonym inloggning" i köns åtkomstkontrollista (ACL) och ge den läsbehörighet.
F: När en nätverkstjänstklient (eller en klient som inte har ett domänkonto) skickar ett köat meddelande misslyckas sändningen med ett ogiltigt certifikat. Hur gör jag för att åtgärda det här?
A: Kontrollera bindningskonfigurationen. Standardbindningen har MSMQ-transportsäkerhet aktiverat för att signera meddelandet. Stäng av den.
Fjärrtransakterade mottagningar
F: När jag har en kö på dator A och en WCF-tjänst som läser meddelanden från en kö på dator B (det fjärrstyrda mottagningsscenariot) läss inte meddelanden från kön. Spårningsinformation anger att mottagningen misslyckades med meddelandet "Transaktionen kan inte importeras". Vad kan jag göra för att åtgärda detta?
A: Det finns tre möjliga orsaker till detta:
Om du är i domänläge kräver fjärrtransacted receive nätverksåtkomst för Microsoft Distributed Transaction Coordinator (MSDTC). Du kan aktivera detta med hjälp av Lägg till/ta bort komponenter.
Kontrollera autentiseringsläget för kommunikation med transaktionshanteraren. Om du är i arbetsgruppsläge måste "Ingen autentisering krävs" väljas. Om du är i domänläge måste du välja "Ömsesidig autentisering krävs".
Kontrollera att MSDTC finns i listan över undantag i brandväggsinställningarna för Internetanslutning .
Kontrollera att du använder Windows Vista. MSMQ i Windows Vista stöder fjärrstyrd läsning. MSMQ i tidigare Windows-versioner stöder inte fjärrstyrd läsning.
F: När tjänsten som läser från kön är en nätverkstjänst, till exempel på en webbvärd, varför aktiveras ett undantag för nekad åtkomst när jag läser från kön?
A: Läsåtkomst för nätverkstjänsten måste läggas till i köns ACL för att säkerställa att en nätverkstjänst kan läsa från kön.
F: Kan jag använda MSMQ-aktiveringstjänsten för att aktivera program baserat på meddelanden i en kö på en fjärrdator?
S: Ja. För att göra detta måste du konfigurera MSMQ-aktiveringstjänsten så att den körs som en nätverkstjänst och lägga till nätverkstjänståtkomst till kön på fjärrdatorn.
Använda anpassade MSMQ-bindningar med ReceiveContext aktiverat
När du använder en anpassad MSMQ-bindning med ReceiveContext aktiverad använder bearbetning av ett inkommande meddelande en trådpoolstråd eftersom intern MSMQ inte stöder I/O-slutförande för asynkrona ReceiveContext mottagningar. Det beror på att bearbetningen av ett sådant meddelande använder interna transaktioner för ReceiveContext och MSMQ inte stöder asynkron bearbetning. Du kan undvika det här problemet genom att lägga till en SynchronousReceiveBehavior i slutpunkten för att framtvinga synkron bearbetning eller ange MaxPendingReceives till 1.