Hi Jon,
in Grizzly 2.0 trunk we're solving this but limiting the async write
queue size per connection, in case, if queue is getting overloaded -
Grizzly will throw an exception.
You can experiment with the Grizzly 2.0 code we have on the trunk.
Module you'd be interested in is grizzly-webcontainer. The code will
look like [1].
Otherwise, if we use Grizzly 1.9.19 code, it's possible to set the
write timeout interval: OutputWriter.setDefaultTimeout...(), so it
will throw an exception, if write takes too long, but here we talk
about sync writes.
As for async writes in Grizzly 1.9.19 - currently it's not possible to
limit or check the write queue size. If you're interested in that -
please file an issue, we'll try to resolve it ASAP.
Thanks.
WBR,
Alexey.
[1]
final GrizzlyWebServer server = new GrizzlyWebServer();
final GrizzlyListener listener =
new GrizzlyListener("Grizzly",
GrizzlyListener.DEFAULT_NETWORK_HOST,
PORT);
final AsyncQueueWriter asyncQueueWriter =
listener.getTransport().getAsyncQueueIO().getWriter();
final int MAX_ASYNC_QUEUE_SIZE = ...;
asyncQueueWriter.setMaxPendingBytesPerConnection(MAX_LENGTH);
server.addListener(listener);
final GrizzlyAdapter ga = new GrizzlyAdapter() {
@Override
public void service(final GrizzlyRequest request, final
GrizzlyResponse response) throws Exception {
// Adapter code
}
};
server.getServerConfiguration().addGrizzlyAdapter(ga, "/path");
try {
server.start();
...........
> I am trying to write a very simple motion JPEG server: one user
> POSTs JPEG images, and those images get distributed to everyone who
> has made a long-running GET request. I initially tried using
> Glassfish and Atmosphere, but ran into some issues [1]. Now I am
> looking at a pure Grizzly 2.0 version based on the Grizzly http
> server.
>
> The one problem I have is figuring out if a client is getting
> behind. If a client isn't reading data quickly enough, I would like
> to skip sending frames to them. Looking at GrizzlyResponse, it looks
> like I can get the current GrizzlyOutputBuffer, but I don't see a
> way to figure out how full that buffer is. Is there a way to do
> this? The only thing I can see is to add a method to
> GrizzlyOuputBuffer to return bb.getLength(). I'm assuming that if
> the output buffer for a client is large, that client is behind and
> should be skipped.
>
> Thanks,
> -Jon
>
> [1] I wrote a very simple atmosphere handler linked below. The
> problem is that with asynchronous writers enabled, the client never
> gets more that about 12k of data. The bug seems to be around line
> 275 of SelectorHandlerRunner -- the Catalina Response object
> implements SelectedKeyAttachmentLogic without actually writing data,
> so the "return true" means the data is never written. Even with that
> issue worked around (by commenting out the return) I still have the
> same issue as above with clients getting behind.
> https://sites.google.com/site/openwonderland/source/ScreenShareAtmosphereHandler.java