Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
De listener en speler werken samen om met gifberichten om te gaan. Als een transactie die wordt afgespeeld, mislukt, Message Queuing het invoerbericht weer naar de invoerwachtrij verplaatst. De speler ontbreekt de transactie als deze een mislukte HRESULT ontvangt van het serveronderdeel of als er een uitzondering wordt onderschept. Als het probleem zich blijft voordoen, kan de listener continu herhalen in het volgende patroon:
- Het bericht uit de wachtrij verwijderen
- Het object instantiëren
- Lijdt aan een terugdraaiactie
- Hiermee wordt het bericht weer boven aan de wachtrij geplaatst
De service onderdelen in de wachtrij verwerkt deze fout met behulp van een reeks toepassingsspecifieke wachtrijen voor opnieuw proberen. Wanneer het onderdeel is geïnstalleerd, zijn er zeven wachtrijen voor elke toepassing, als volgt:
De normale invoerwachtrij. De naam van deze wachtrij is de com+-toepassingsnaam. Dit is een openbare wachtrij voor Message Queuing.
De eerste wachtrij voor opnieuw proberen. Berichten worden hier verplaatst als de transactie herhaaldelijk mislukt bij het verwerken van berichten uit de normale invoerwachtrij. Berichten in deze wachtrij worden na één minuut verwerkt. Een bericht kan drie keer opnieuw worden geprobeerd in deze wachtrij voordat het wordt verplaatst naar de achterkant van de tweede wachtrij voor opnieuw proberen. Deze wachtrij heet ApplicationName_0. Deze wachtrij is een persoonlijke Message Queuing-wachtrij.
De tweede wachtrij voor opnieuw proberen. Berichten worden hier verplaatst als de transactie herhaaldelijk mislukt bij het verwerken van berichten uit de eerste wachtrij voor opnieuw proberen. Berichten in deze wachtrij worden na twee minuten verwerkt. Een bericht kan drie keer opnieuw worden geprobeerd in deze wachtrij voordat het wordt verplaatst naar de achterkant van de derde wachtrij voor opnieuw proberen. Deze wachtrij heet ApplicationName_1. Deze wachtrij is een persoonlijke Message Queuing-wachtrij.
De derde wachtrij voor opnieuw proberen. Berichten worden hier verplaatst als de transactie herhaaldelijk mislukt bij het verwerken van berichten uit de tweede wachtrij voor opnieuw proberen. Berichten in deze wachtrij worden na vier minuten verwerkt. Een bericht kan drie keer opnieuw worden geprobeerd in deze wachtrij voordat het wordt verplaatst naar de achterkant van de vierde wachtrij voor opnieuw proberen. Deze wachtrij heet ApplicationName_2. Deze wachtrij is een persoonlijke Message Queuing-wachtrij.
De vierde wachtrij voor opnieuw proberen. Berichten worden hier verplaatst als de transactie herhaaldelijk mislukt bij het verwerken van berichten uit de derde wachtrij voor opnieuw proberen. Berichten in deze wachtrij worden na acht minuten verwerkt. Een bericht kan drie keer opnieuw worden geprobeerd in deze wachtrij voordat het wordt verplaatst naar de vijfde wachtrij voor opnieuw proberen. Deze wachtrij heet ApplicationName_3. Deze wachtrij is een persoonlijke Message Queuing-wachtrij.
De vijfde wachtrij voor opnieuw proberen. Berichten worden hier verplaatst als de transactie herhaaldelijk mislukt bij het verwerken van berichten uit de vierde wachtrij voor opnieuw proberen. Berichten in deze wachtrij worden na zestien minuten verwerkt. Een bericht kan drie keer in deze wachtrij worden geprobeerd voordat het wordt verplaatst naar de uiteindelijke rustwachtrij. Deze wachtrij heet ApplicationName_4. Dit is een persoonlijke Message Queuing-wachtrij.
Een toepassingsspecifieke laatste rustwachtrij. Berichten worden hier verplaatst als de transactie herhaaldelijk wordt afgebroken bij een poging in de vijfde wachtrij voor opnieuw proberen. Deze wachtrij heet ApplicationName_DeadQueue. Dit is een persoonlijke Message Queuing-wachtrij. De laatste rustwachtrij wordt niet onderhouden door een wachtrijlistener. Berichten blijven hier totdat ze handmatig worden verplaatst (mogelijk door het hulpprogramma berichten mover van berichten in de wachtrij) of worden verwijderd door Message Queuing Explorer.
Berichten die niet kunnen worden afgespeeld, omdat het duidelijk is dat elke nieuwe poging mislukt, rechtstreeks naar de toepassingsspecifieke laatste rustwachtrij kan worden verplaatst zonder dat alle niveaus voor opnieuw proberen zijn gevorderd.
De speler geeft een COM+ gebeurtenis uit om belanghebbenden op de hoogte te stellen dat berichten niet kunnen worden afgespeeld. COM+-gebeurtenissen worden uitgegeven in de volgende situaties:
- Wanneer een transactie wordt afgebroken
- Wanneer een bericht van de ene wachtrij naar de andere wordt verplaatst
- Wanneer een bericht wordt opgeslagen in de uiteindelijke rustwachtrij
Berichten kunnen worden gewijzigd voordat u van de ene wachtrij naar de andere gaat. Met het beveiligingsmechanisme voor com+-onderdelen in de wachtrij kan een bericht worden verplaatst naar wachtrijen voor opnieuw proberen en vervolgens opnieuw worden geplaatst in de eerste invoerwachtrij van de toepassing. Zie SecurityVoor meer informatie over de beveiliging van in wachtrij geplaatste onderdelen.
Wachtrijen voor opnieuw proberen worden gemaakt samen met de hoofdtoepassingswachtrij wanneer de toepassing is gemarkeerd als in de wachtrij door het beheerprogramma Component Services of met behulp van de COM+ Administrative SDK-functies. De service onderdelen in de wachtrij biedt flexibiliteit in het mechanisme voor opnieuw proberen door toe te staan dat wachtrijen voor opnieuw proberen worden verwijderd. Als bijvoorbeeld alle wachtrijen voor opnieuw proberen worden verwijderd, wordt een bericht dat permanent wordt afgebroken, rechtstreeks van de toepassingswachtrij naar de toepassingsspecifieke laatste rustwachtrij verplaatst. Door een of meer van de wachtrijen voor opnieuw proberen te verwijderen, kan het aantal en de lengte van de nieuwe pogingen worden verminderd. Als wachtrijen worden verwijderd uit de reeks nieuwe pogingen, komt de timing van de resterende wachtrijen overeen met de positie in de volgorde van wachtrijen voor opnieuw proberen. Als u bijvoorbeeld de wachtrij voor opnieuw proberen verwijdert ApplicationName_1, ApplicationName_2 en ApplicationName_3, worden de berichten op ApplicationName_4 verwerkt alsof de wachtrij de tweede wachtrij voor opnieuw proberen was.
Het mechanisme voor opnieuw proberen is ontworpen om een bericht te voltooien, indien mogelijk. In sommige gevallen is het mogelijk dat het bericht niet slaagt. Een klant probeert bijvoorbeeld geld in te trekken van een rekening met onvoldoende geld. In deze omstandigheden kunt u de fout op verschillende manieren afhandelen, waaronder de volgende:
- Een diagnose genereren en een waarschuwing geven
- Een compenserende transactie maken
- Het probleem negeren en het bericht sluiten
Net als permanente fouten aan de clientzijde kan de service onderdelen in de wachtrij een uitzonderingsklasse aan een onderdeel koppelen. De uitzonderingsklasse is gekoppeld aan het onderdeel met behulp van het tabblad Geavanceerd op de pagina met onderdeeleigenschappen van het beheerprogramma Component Services of met behulp van de com+ beheerfuncties. Met de uitzonderingsklasse kan de ontwikkelaar controle hebben nadat een bericht opnieuw is geprobeerd en voordat dat bericht wordt verplaatst naar de toepassingsspecifieke laatste rustwachtrij. Zie Permanente Client-Side foutenvoor meer informatie over de uitzonderingsklasse.
Hier volgt een reeks gebeurtenissen voor het verwerken van uitzonderingen aan de serverzijde:
- Het bericht wordt verplaatst via de beschikbare toepassingsspecifieke wachtrijen voor opnieuw proberen.
- De laatste nieuwe poging voor de laatste wachtrij voor opnieuw proberen mislukt.
- De runtime van de service onderdelen in de wachtrij haalt het doelonderdeel op uit het bericht en controleert op een uitzonderingsklasse.
- Met de runtime wordt de uitzonderingsklasse geïnstitueert.
- De runtimequery's IPlaybackControl op de uitzonderingsklasse.
- De runtimeaanroepen IPlaybackControl::FinalServerRetry in de uitzonderingsklasse.
- De runtime speelt alle eigenschaps- en methode-aanroepen van het bericht af naar de uitzonderingsklasse.
- Als stap 4 tot en met 6 niet slaagt, verplaatst de runtime het bericht naar de toepassingsspecifieke laatste rustwachtrij.
Als u moet ingrijpen in het hierboven beschreven proces of als u een gifbericht uit de uiteindelijke rustwachtrij wilt verplaatsen, gebruikt u het hulpprogramma voor berichtmover. Zie Fouten afhandelenvoor meer informatie over het hulpprogramma voor berichtmover.
Verwante onderwerpen