Delweddau anghyflawn drwy brocsi: gwirio cwblhau ysgrifennu Netty
Pan fydd delweddau'n cyrraedd yn anghyflawn drwy brocsi, archwiliwch a yw'r tarddiad yn cau ei sianel Netty cyn i'r ysgrifennu asyncronaidd o'r ymateb gael ei gwblhau.
Mae delwedd yn gweithio dros gysylltiad uniongyrchol cyflym, ond mae'n anghyflawn drwy brocsi ymlaen arafach. Un achos posibl yw bod y tarddiad yn cau'r cysylltiad tra bod ei ymateb yn dal i gael ei ysgrifennu.
Mae I/O Netty yn asyncronaidd. Nid yw dychwelyd o writeAndFlush yn golygu bod y llawdriniaeth honno wedi cwblhau. Felly mae'r drefn hon yn anniogel ar gyfer ymateb sydd â beitiau'n dal yn y ciw:
ctx.writeAndFlush(response);
ctx.close();
Pan fydd y cyfnewid HTTP yn cau'n fwriadol ar ôl ei neges ymateb olaf, atodwch y cau i future yr ysgrifennu hwnnw:
ctx.writeAndFlush(finalResponseMessage)
.addListener(ChannelFutureListener.CLOSE);
Mae'r darn yn rhagdybio bod yr ymateb eisoes wedi'i adeiladu a'i ffrâmio'n gywir. Ar gyfer corff wedi'i ffrydio, defnyddiwch gwblhau ei neges olaf yn hytrach nag ysgrifennu ei benawdau. Ar gyfer cysylltiad HTTP parhaus, peidiwch ag ychwanegu cau dim ond oherwydd bod ymateb wedi gorffen.
Archwiliwch fethiant y future fel rhan o driniaeth arferol gwallau'r cymhwysiad. Mae cwblhau'n cynnwys methiant a chanslo, felly nid yw cwblhau ar ei ben ei hun yn dystysgrif cyflenwi gan y porwr.
Y gymhariaeth ddefnyddiol yw hyd llawn yr ymateb a chanlyniad yr ysgrifennu ar bob llwybr. Gall procsi newid amseru digon i ddatgelu gwall cylch bywyd sy'n bodoli eisoes; nid yw ei bresenoldeb yn profi bod ei gywasgydd neu ei storfa wedi taflu'r beitiau.