Mga Retry

Ang Glasswall Halo ay binubuo ng maraming service na nakikipag-ugnayan gamit ang mga asynchronous na mensahe sa halip na HTTP. Para sa mga service na ito, nagsagawa kami ng mga konsiderasyon tungkol sa kung paano hinahawakan ng platform ang failure kapag may error sa pagproseso ng isang mensahe.

Synchronous API at Asynchronous API​

Ang mga API ay nagsu-subscribe sa mga response queue mula sa Glasswall Engine, ngunit kapag nagkaroon ng failure, isang error response ang ibabalik sa http client.

Engine service​

Ang architecture ay request/response gamit ang RabbitMQ reply-to queues. Ibig sabihin nito na kapag may failure, habang hinahawakan ang isang message ay nagpapadala pa rin kami ng response message na naglalaman ng dahilan ng failure.

Report aggregator​

Ang report aggregator ay kumikilos bilang isang standard message consumer at nagdagdag ng karagdagang functionality upang paganahin ang message retrying. May dalawang configuration options sa service.

Ang Retrymessages ay isang bool na ang default ay true na nagpapagana sa functionality para i-retry ang mga message. Kapag naka-off, lahat ng failed messages ay agad na inilalagay sa dead letter queue.

Ang Messagettl ay isang integer na kumakatawan sa bilang ng segundo na maaaring manatili ang isang message sa queue. Ito ay para maiwasan ang pag-ipon ng mga message dahil sa isang failed message na walang katapusang nire-retry. Kapag lumipas na ang time to live para sa isang message, inilalagay ito sa dead letter queue. Ang code default ay 30 segundo.

Ang functionality ng report aggregator ay hindi kritikal para matanggap ng mga client ang kanilang mga file at ginagamit ito upang gumawa ng aggregated report data. Dahil dito, ang dead lettering ng isang report aggregator message ay hindi itinuturing na kritikal na failure at ang dead letters ay tinatanggap (sa mga matitinding kaso lamang).