Come evitare la limitazione delle richieste dei messaggi correlati

I messaggi accodati in BizTalk Server, ad esempio tramite un indirizzo di ricezione o da orchestrazioni, possono essere elaborati in uno dei modi seguenti:

• Possono attivare nuove istanze di sottoscrittori, ad esempio orchestrazioni o porte di trasmissione.

• Possono essere instradate all'istanza di un sottoscrittore esistente tramite correlazione. Per altre informazioni sulla correlazione, vedere Uso delle correlazioni nelle orchestrazioni.

  Molti sviluppatori ritengono che gli indirizzi di ricezione per una soluzione possano essere utilizzati per la ricezione di messaggi sia di attivazione che di correlazione attraverso la stessa porta. Si tratta di un comportamento naturale in quanto tale funzionamento riduce il numero di indirizzi di cui i mittenti devono tenere traccia. Tuttavia, con la limitazione in BizTalk Server, possono esserci vantaggi a pensare al flusso di messaggi di attivazione e al flusso di messaggi correlati separatamente quando si tratta di limitazione.

  Quando entrambi i messaggi di attivazione e di correlazione giungono tramite lo stesso indirizzo di ricezione, sono soggetti allo stesso stato di limitazione delle richieste poiché la limitazione delle richieste viene applicata a livello di host. Ne consegue che tutti i messaggi che giungono a indirizzi di ricezione nell'host sono soggetti a limitazione delle richieste in quanto unità. Ciò non costituisce un problema in molti scenari ma in alcuni casi la limitazione delle richieste delle correlazioni e delle attivazioni può sfociare in un certo tipo di deadlock del sistema.

Esempio

Si pensi, ad esempio, a uno scenario in cui un'orchestrazione riceve un'attivazione, la utilizza per inizializzare un set correlazioni, quindi riceve una serie di altri 10 messaggi successivi al set correlazioni. Si supponga inoltre che, sotto carico, si verifichi un backlog nello spooler man mano che giunge il gruppo misto di messaggi di attivazione e di correlazione e che questo backlog sfoci nella limitazione della quantità di messaggi che può essere ricevuta. Le richieste dei messaggi di correlazione vengono limitate analogamente ai messaggi di attivazione e ciò rallenta il completamento delle orchestrazioni, provocando ulteriori condizioni di backlog e ulteriore limitazione delle richieste. Se questa condizione permane, è in grado di limitare il sistema quasi azzerandone la velocità effettiva.

Suddividendo l'indirizzo di ricezione in due, un indirizzo per le attivazioni e l'altro per le correlazioni, e configurando gli indirizzi in host separati, è possibile abbassare la soglia di limitazione delle dimensioni del database per le attivazioni rispetto alla soglia per le correlazioni, con conseguente riduzione delle condizioni di backlog globali e continuazione del flusso dei messaggi.

Quindi, si potrebbe chiedere: "Perché non è possibile aumentare solo la soglia delle dimensioni del database per la posizione di ricezione singola per risolvere il problema?" La risposta è che è possibile, ma non sempre comporta il comportamento desiderato. La limitazione delle richieste consente essenzialmente di proteggere il sistema dal sovraccarico e se si aumentano troppo le soglie oppure se le si disattivano del tutto, si elimina questa protezione.

Recommendation

La procedura ottimale per scenari come quello descritto sopra, in cui è rilevante la limitazione delle richieste di messaggi di correlazione, consiste nel separare gli indirizzi di ricezione in host distinti in cui la limitazione delle richieste possa essere impostata indipendentemente.

Quando gli indirizzi di ricezione sono configurati in host separati, impostare la soglia di limitazione delle dimensioni del database per l'host utilizzato dagli indirizzi di ricezione su un valore inferiore rispetto alla soglia di limitazione delle dimensioni del database per gli host utilizzati da orchestrazioni o correlazioni.

Se si ha la certezza che il carico non sarà mai superiore alla velocità effettiva massima sostenibile (MST, Maximum Sustainable Throughput) del sistema o che i picchi di velocità effettiva sono recuperabili tra i picchi, aumentare le soglie della limitazione delle richieste è una buona soluzione che tuttavia non sarà mai in grado di competere con la velocità effettiva ottenibile utilizzando host separati per attivazioni e correlazioni.