Een kanaal programmatisch in Netty doorspoelen

Ik heb een Netty-app die HTTP-verbindingen neemt en intermitterende gegevens streamt naar terwijl de verbinding open blijft totdat de client de verbinding verbreekt. Ik kan ervoor zorgen dat de app werkt, behalve dat de verzendbuffer niet vaak genoeg naar de client pusht (en vaak over samengevoegde schrijfgebeurtenissen die onvolledige gegevensontvangst veroorzaken aan de andere kant totdat de volgende buffer wordt ingedrukt, wat een lange tijd kan duren) komt eraan). Ik zou graag willen weten of er een manier voor mij is om in de verzendbuffer te schrijven en een flush te forceren om een ​​compleet stuk gegevens naar de client te duwen zonder de socket te hoeven sluiten.

Ik heb de bootstrap eigenschappen tcpNoDelay , writeBufferHighWaterMark en writeBufferLowWaterMark (allemaal met en zonder "child.") Zonder effect bekeken.

Suggesties? Bedankt!

0
Ik heb ook de optie "sendBufferSize" ook op 0 geprobeerd, zonder verandering.
toegevoegd de auteur Ryan Shelley, de bron
Door de binding van de server socket heen, zie ik dat bufferFactory, receiveBufferSize, reuseAddress en backlog de enige eigenschappen zijn die kunnen worden ingesteld op de server socket kant van dingen. Ik veronderstel dat ik volgende keer naar de bufferFactory zal moeten kijken.
toegevoegd de auteur Ryan Shelley, de bron

3 antwoord

Voor het geval dat het niet duidelijk is, heeft Netty geen flush() operatie. Het schrijft zo snel mogelijk.

2
toegevoegd

Ik denk dat je een BufferedWriteHandler aan de ChannelPipeline kunt toevoegen om de gebufferde schrijfbewerking te emuleren.

Webdocument BufferedWriteHandler

Zolang u een verwijzing naar de pijplijninstantie van de BufferedWriteHandler kunt behouden of verkrijgen,

public void messageReceived(ChannelHandlerContext ctx, MessageEvent e) {
        BufferedWriteHandler bufferedWriter 
                = e.getChannel().getPipeline().get("buffer");

dan kun je programmatisch spoelen zoals je wilt:

bufferedWriter.flush();
1
toegevoegd

Ik denk dat ik mijn eigen vraag heb beantwoord en dat dit niet te wijten is aan het feit dat de socketbuffer de gegevens niet verzendt. Ik gebruikte "krullen" om de reactie te testen en krullen heeft een interne buffer die verhinderde dat de gegevens naar het scherm werden afgedrukt. Dit kan worden uitgeschakeld met "-N." Helemaal mijn eigen schuld, maar het duurde nog een tijdje om de code door te nemen en het terug te traceren naar mijn klant.

0
toegevoegd