Hi Etienne,
yes Grizzly 2.0 covers that usecase and provides support for NIO Input
and Output streams, so you won't block the thread by waiting for more
data to be read/written.
You can checkout the latest Grizzly webcontainer code [1] and use NIO
streams like in echo sample [2].
Using GrizzlyInput/Output Stream it's possible to check wether the
next read/write operation will be blocked or not and it's also
possible to register the listener, which will be notified when next
non-blocking read/write could be executed.
Thanks.
WBR,
Alexey.
[1] svn checkout
https://www.dev.java.net/svn/grizzly/branches/2dot0/code/modules/webcontainer
[2]
//========================= Init code
final GrizzlyWebServer server = new GrizzlyWebServer();
final GrizzlyListener listener =
new GrizzlyListener("grizzly",
GrizzlyListener.DEFAULT_NETWORK_HOST,
PORT);
listener.setKeepAliveTimeoutInSeconds(0);
server.addListener(listener);
server.getServerConfiguration().addGrizzlyAdapter(adapter, "/
path/*");
//========================= Adapter code
private static class EchoAdapter extends GrizzlyAdapter {
private final FutureImpl<String> testResult;
private final int readSize;
// --------------------------------------------------------
Constructors
EchoAdapter(final FutureImpl<String> testResult, final int
readSize) {
this.testResult = testResult;
this.readSize = readSize;
}
// ----------------------------------------- Methods from
GrizzlyAdapter
@Override
public void service(final GrizzlyRequest req,
final GrizzlyResponse res)
throws Exception {
try {
final GrizzlyInputStream reader =
req.getInputStream(false);
int available = reader.readyData();
if (available > 0) {
byte[] b = new byte[available];
reader.read(b);
res.getOutputStream().write(b);
}
if (reader.isFinished()) {
return;
}
final StringBuffer sb = new StringBuffer();
reader.notifyAvailable(new ReadHandler() {
@Override
public void onDataAvailable() {
try {
buffer(reader, sb);
} catch (IOException ioe) {
testResult.failure(ioe);
}
//reader.notifyAvailable(this, readSize);
}
@Override
public void onAllDataRead() {
try {
buffer(reader, sb);
} catch (IOException ioe) {
testResult.failure(ioe);
}
try {
res.getOutputStream().write(sb.toString().getBytes());
} catch (Exception e) {
testResult.failure(e);
}
res.resume();
}
@Override
public void onError(Throwable t) {
res.resume();
throw new RuntimeException(t);
}
}, readSize);
res.suspend();
} catch (Throwable t) {
testResult.failure(t);
}
}
private static void buffer(GrizzlyInputStream reader,
StringBuffer sb) throws IOException {
byte[] b = new byte[reader.readyData()];
try {
reader.read(b);
} catch (IOException ioe) {
throw new RuntimeException(ioe);
}
try {
sb.append(new String(b));
} catch (Throwable ioe) {
throw new RuntimeException(ioe);
}
}
} // END EchoAdapter
On Aug 20, 2010, at 15:01 , Vrignaud Etienne wrote:
>
> Hi,
>
> Thanks for your information.
> I am disappointed. I understand that for you this kind of use case
> is not
> supported by default by Grizzly.
>
> Using Grizzly, I except that this kind of feature would be a grizzly
> option.
>
> Can someone tell me if there is a solution provided by Grizzly?
> Are there some plans regarding that?
> Is the 2.0 of Grizzly designed to fix that?
>
> Kind regards,
> /Etienne
>
> --
> View this message in context: http://old.nabble.com/Grizzly-no-more-responding-when-clients-are-doing-many-big-files-upload-and-download-tp29482040p29491590.html
> Sent from the Grizzly - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>