Dela via

Server-Side fel

Lyssnaren och spelaren arbetar tillsammans för att hantera giftmeddelanden. Om en transaktion som spelas upp misslyckas Message Queuing flyttar tillbaka indatameddelandet till indatakön. Spelaren avbryter transaktionen om den tar emot en misslyckad HRESULT från serverkomponenten eller om den fångar upp ett undantag. Om problemet kvarstår kan lyssnaren loopa kontinuerligt i följande mönster:

  • Avqueues meddelandet
  • Instansierar objektet
  • Drabbas av en återställning
  • Placerar meddelandet överst i kön igen

Tjänsten för köade komponenter hanterar det här felet med hjälp av en serie programspecifika återförsöksköer. Det skapas när komponenten installeras och det finns sju köer för varje program, enligt följande:

  1. Den normala indatakön. Namnet på den här kön är COM+-programnamnet. Det här är en offentlig Meddelandekö.

  2. Den första återförsökskö. Meddelanden flyttas hit om transaktionen upprepade gånger misslyckas när meddelanden bearbetas från den normala indatakön. Meddelanden i den här kön bearbetas efter en minut. Ett meddelande kan göras om tre gånger i den här kön innan det flyttas till baksidan av den andra återförsökskön. Den här kön heter ApplicationName_0. Den här kön är en privat Meddelandekö.

  3. Den andra kön för återförsök. Meddelanden flyttas hit om transaktionen upprepade gånger misslyckas när meddelanden bearbetas från den första återförsökskön. Meddelanden i den här kön bearbetas efter två minuter. Ett meddelande kan göras om tre gånger i den här kön innan det flyttas till baksidan av den tredje återförsökskön. Den här kön heter ApplicationName_1. Den här kön är en privat Meddelandekö.

  4. Den tredje kön för återförsök. Meddelanden flyttas hit om transaktionen upprepade gånger misslyckas när meddelanden bearbetas från den andra återförsökskön. Meddelanden i den här kön bearbetas efter fyra minuter. Ett meddelande kan göras om tre gånger i den här kön innan det flyttas till baksidan av den fjärde återförsökskön. Den här kön heter ApplicationName_2. Den här kön är en privat Meddelandekö.

  5. Den fjärde återförsökskö. Meddelanden flyttas hit om transaktionen upprepade gånger misslyckas när meddelanden bearbetas från den tredje återförsökskön. Meddelanden i den här kön bearbetas efter åtta minuter. Ett meddelande kan göras om tre gånger i den här kön innan det flyttas till den femte återförsökskön. Den här kön heter ApplicationName_3. Den här kön är en privat Meddelandekö.

  6. Den femte återförsökskön. Meddelanden flyttas hit om transaktionen upprepade gånger misslyckas när meddelanden bearbetas från den fjärde återförsökskön. Meddelanden i den här kön bearbetas efter sexton minuter. Ett meddelande kan göras om tre gånger i den här kön innan det flyttas till den sista vilande kön. Den här kön heter ApplicationName_4. Det här är en privat Meddelandekö.

  7. En programspecifik slutlig vilokö. Meddelanden flyttas hit om transaktionen upprepade gånger avbryts vid försök i den femte återförsökskön. Den här kön heter ApplicationName_DeadQueue. Det här är en privat Meddelandekö. Den sista vilokön hanteras inte av en kölyssnare. Meddelanden stannar här tills de flyttas manuellt (kanske av verktyget meddelandeflyttare för köade komponenter) eller rensas av Message Queuing Explorer.

Meddelanden som inte kan spelas upp eftersom det är uppenbart att varje återförsök misslyckas kan flyttas direkt till den programspecifika sista vilokön utan att gå igenom alla återförsöksnivåer.

Spelaren utfärdar en COM+-händelse för att meddela berörda parter att meddelanden inte kan spelas upp. COM+-händelser utfärdas i följande situationer:

  • När en transaktion avbryts
  • När ett meddelande flyttas från en kö till en annan
  • När ett meddelande deponeras i den sista vilande kön

Meddelanden kan ändras innan du flyttar från en kö till en annan. Säkerhetsmekanismen COM+-köade komponenter gör att ett meddelande kan flyttas för att försöka köer igen och sedan sättas in i programmets första indatakö igen. Mer information om säkerhet för köade komponenter finns i Säkerhet för köade komponenter.

Återförsöksköer skapas tillsammans med huvudprogramkön när programmet antingen markeras som i kö av administrationsverktyget för Komponenttjänster eller med hjälp av com+ administrations-SDK-funktionerna. Tjänsten för köade komponenter ger flexibilitet i återförsöksmekanismen genom att tillåta att återförsöksköer tas bort. Om till exempel alla köer för återförsök tas bort, flyttas ett meddelande som beständigt avbryter direkt från programkön till den programspecifika sista vilokön. Genom att ta bort en eller flera av återförsöksköerna kan antalet och längden på återförsöken minskas. Om köer tas bort från återförsökssekvensen motsvarar tidpunkten för de återstående köerna positionen i sekvensen för återförsöksköer. Om du till exempel tar bort kön för återförsök ApplicationName_1, ApplicationName_2 och ApplicationName_3 bearbetas meddelandena på ApplicationName_4 som om kön var den andra omförsökskön.

Mekanismen för återförsök är utformad för att slutföra ett meddelande om det alls är möjligt. I vissa fall kanske det inte är möjligt att meddelandet lyckas. En kund kan till exempel försöka ta ut pengar från ett konto som inte har tillräckligt med pengar. Under dessa omständigheter kan du hantera felet på flera olika sätt, inklusive följande:

  • Generera en diagnostik och utfärda en varning
  • Skapa en kompenserande transaktion
  • Ignorera problemet och stäng meddelandet

Precis som beständiga fel på klientsidan tillåter tjänsten för köade komponenter att en undantagsklass associeras med en komponent. Undantagsklassen är associerad med komponenten med hjälp av fliken Avancerat på sidan komponentegenskaper i administrationsverktyget för Komponenttjänster eller med hjälp av COM+ Administrativa funktioner. Med undantagsklassen kan utvecklaren ha kontroll när ett meddelande har gjorts om och innan meddelandet flyttas till den programspecifika sista vilokön. Mer information om undantagsklassen finns i Beständiga Client-Side fel.

Följande är händelsesekvensen för undantagshantering på serversidan:

  1. Meddelandet flyttas via de tillgängliga programspecifika återförsöksköerna.
  2. Det sista återförsöket i den senaste återförsökskön misslyckas.
  3. Körningstiden för tjänsten köade komponenter hämtar målkomponenten från meddelandet och söker efter en undantagsklass.
  4. Körningen instansierar undantagsklassen.
  5. Körningsfrågorna IPlaybackControl i undantagsklassen.
  6. Körningsanropen IPlaybackControl::FinalServerRetry i undantagsklassen.
  7. Körningen spelar upp alla egenskaps- och metodanrop från meddelandet till undantagsklassen.
  8. Om steg 4 till och med 6 inte lyckas flyttas meddelandet till den programspecifika sista vilokön.

Om du behöver ingripa i processen som beskrivs ovan eller om du behöver flytta ett giftmeddelande från den sista vilande kön använder du verktyget meddelandeflyttare. Mer information om verktyget meddelandeflyttare finns i Hantera fel.

Client-Side fel

beständiga Client-Side fel

 

 

  • Last updated on