On 11/29/12 11:34 AM, Danny Coward wrote:
Not quite. It's more like auto-flush false means "I'm batching messages; don't bother sending if you don't have to." I don't think the wording should be "never", because of things like mux, or other server heuristics. It's more like "start the process of sending."
setBatching(true) might be a better name, if that's clearer.
When setBatching(false) [autoFlush=true] -- the default -- and an app calls sendString(), the message will be delivered (with possible buffering, delays, mux, optimizations, etc, depending on the implementation, but it will be delivered without further intervention from the app.)
When setBatching(true) [autoFlush=false], and an app calls sendString(), the message might sit in the buffer forever until the application calls flush().
sendPartialString would be unaffected by the flag; the WS implementation is free to do whatever it wants with partial messages.
Basically, it's a hint: setBatching(true) [autoFlush=false] means "I'm batching a bunch of messages, so don't bother sending the data if you don't need to until I call flush."
Does that make sense? I don't want to over-constrain implementations with autoFlush(true) either option. Maybe "batching" is the better name to avoid confusion. (But even batching=true doesn't require buffering. Implementations can still send fragments early if they want or even ignore batching=true.)
I think it's on the RemoteEndpoint, like setAutoCommit for JDBC. It's easy to set in @WebSocketOpen, and the application might want to start and stop batching mode while processing.
[jsr356-experts] Re: RemoteEndpoint setAutoFlush() and flush()