Jersey 2 վերբեռնման բուֆերավորում պրոքսի նույնականացման կրկնակի փորձերի համար

Պրոքսիի մարտահրավերից հետո կրկնվող վերբեռնումը կրկին պահանջում է իր մարմինը։ Jersey 2-ի Apache connector-ի համար այն կոնֆիգուրացիայում, որով կառուցվում է այդ հաճախորդը, ընտրեք բուֆերացված սուբյեկտի մշակումը՝

ClientConfig config = new ClientConfig();
config.connectorProvider(new ApacheConnectorProvider());
config.property(ClientProperties.PROXY_URI,
                "http://proxy.example.net:8080");
config.property(ClientProperties.REQUEST_ENTITY_PROCESSING,
                RequestEntityProcessing.BUFFERED);

Կատարեք վերբեռնումը ստացված հաճախորդի միջոցով։ Այս տիպերը գալիս են Jersey client և Apache-connector փաթեթներից. չօգտագործվող կոնֆիգուրացիա սահմանելը չէր ազդի հարցման վրա։

Connector-ը բուֆերացված սուբյեկտը փաթաթում է Apache-ի BufferedHttpEntity-ի մեջ։ Նրա չբուֆերացված հոսքային սուբյեկտը կրկնվող չէ։ Բուֆերավորումը նույնականացման հոսքին տալիս է բայթեր, որոնք այն կարող է նորից ուղարկել՝ սպառված արտադրողին նորից կարդալու փոխարեն։

Այն չի երաշխավորում, որ նույնականացումը կավարտվի մեկ 407-ից հետո։ Որոշ սխեմաներ օրինականորեն պահանջում են մի քանի փոխանակում, ուստի ամբողջ բանակցությունը ստուգեք նախքան հաջորդ մարտահրավերը կորած վիճակ համարելը։

Մարմնի չափը պահեք հիշողության բյուջեի սահմաններում։ Մեծ հոսքային վերբեռնմանը պետք է այդ ծանրաբեռնվածությանը համապատասխան կրկնարկման ռազմավարություն. բոլոր հարցումների համար բուֆերավորումը միացնելը կարող է բանակցության ձախողումը փոխանակել հիշողության սպառման հետ։