Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jetty-users] Reprioritization of Jetty


On Sun, Sep 27, 2015 at 5:39 PM, Muhui Jiang <jiangmuhui@xxxxxxxxx> wrote:
> Hi
> Simone. Another thing I want to ask you(sorry for so many questions). I set
> the key 4 to 100 in the settings to enable the window size I got for every
> frame.
>         int key1 = 4;
>         Integer value1 = 100;
>         settings1.put(key1, value1);
>         SettingsFrame settingsFrame = new SettingsFrame(settings1, false);
> But I didn't send any window update frame. I was wondering whether Jetty did
> this in the background.
> And when I tried to send window_update frame to the server. I find Jetty
> only supports the method for Http2Session. Session doesn't have this
> function. But you know I use this
>         FuturePromise<Session> sessionPromise = new FuturePromise<>();
>         client.connect(sslContextFactory, new InetSocketAddress(host, port),
>         new ServerSessionListener.Adapter(), sessionPromise);
>         Session session = sessionPromise.get(5, TimeUnit.SECONDS);
> to open the session. I don't know how to send window_update_frame. Could you
> please give me a hint? Thank you so much.

Applications do not need to send WINDOW_UPDATE frames.
This is taken care by the implementation, exactly like when using
sockets (that use TCP) you don't have to send TCP ACK packets or
retransmit packets.

That's the reason why there is no API to directly send WINDOW_UPDATE frames.

You can interact with the flow control mechanism by providing your own
FlowControlStrategy, but overriding the factory methods in

Unless you want to really mess up with the protocol, I suggest you
leave the FlowControl mechanism to Jetty.

Simone Bordet
Developer advice, training, services and support
from the Jetty & CometD experts.

Back to the top