I've confirmed that session.getContainer().setDefaultMaxBinaryMessageBufferSize(...) has the desired effect of increasing the deflate extension's max buffer size. Tracing the code a bit, it looks like extensions are getting built to be session-specific, but they must somehow be getting handed the default policy instead of the one specific to the session.
On Wed, Nov 6, 2013 at 4:26 PM, Joakim Erdfelt <[email protected]> wrote: > The fact that the extensions have a different value in their policy seems > like a bug, please file it at bugs.eclipse.org. > > But for the other part of the question, the extensions should have their > own configuration really. > Read up about extension parameters in RFC6455 to see how that is done. > Most extensions should not care about frame size limits, message limits, > or buffer limits, that's seems out of scope for an Extension. > They should deal with the frames as they get them. If they choose to > refragment the frames, then they should document that behavior. (as other > extensions might forbid that) > > > -- > Joakim Erdfelt <[email protected]> > webtide.com <http://www.webtide.com/> - intalio.com/jetty > Expert advice, services and support from from the Jetty & CometD experts > eclipse.org/jetty - cometd.org > > > On Wed, Nov 6, 2013 at 4:38 PM, Brandon Mintern <[email protected]>wrote: > >> In my JSR WebSocket's @OnOpen method, I'm calling >> javax.websocket.Session.setMaxBinaryMessageBufferSize to increase the >> buffer size. I have verified that >> WebSocketPolicy.setMaxBinaryMessageBufferSize is getting called and >> correctly changing a policy's buffer size. >> >> In line 86 of DeflateFrameExtension, however, the policy returned by the >> call to getPolicy() is apparently a different WebSocketPolicy, as its >> binaryMessageBufferSize remains at the default value of 32KB. >> >> Should extensions share the WebSocketPolicy object of the Session itself? >> Or is there some other way that I should be configuring these maximums >> specific to extensions. >> >> Tangentially, I found in extensive testing that binary messages of 128KB >> were the ideal size for Google Chrome for streaming binary data. Firefox >> kept improving as the binary message size got larger. Other devs who have >> noticed this may be using message sizes of 128KB for streaming large >> amounts of data, so a default size of 32KB may not be ideal. >> >> _______________________________________________ >> jetty-users mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/jetty-users >> >> > > _______________________________________________ > jetty-users mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/jetty-users > >
_______________________________________________ jetty-users mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/jetty-users
