Re: Random Grizzly IOException
Jerome Louvel jerome.louvel at noelios.com writes:
Hi Bruce,
Great news!
Regarding the 40s delay I'm puzzled... Did you monitor the state of
sockets?
Are they all closed in a timely manner?
Did you try using a profiler to detect which part of the code actually
causes the delay?
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
Hi Jerome,
Sorry I finally got some time to dig into this problem again and I think
I've found the cause of the round time delay in 1.1.3.
In the ByteUtils, there's a SelectorFactory which is used when NIO
selectablechannel is used. Notice that the factory limits the total
number of active selectors to 20, and if the pool ever runs empty, it'll
wait maximum of 2 periods of timeout (5s) before giving up. So the
blocking we are seeing is coming from this piece of code. (10s, 20s, 30s
etc..)
The fix is relatively simple, since the selector (and selectionKey) is
only acquired in the NbChannelOutputStream when the channel is not
available, the code should release the selector at the finally block of
the doWrite method instead of waiting for the channel.close(). This will
ensure that the limited number of selector is never kept for a long
period of time.
Ex:
} finally {
this.bb.clear();
release(this.selector, this.selectionKey);
}
With this piece of code change, I was able to run the following test
code with
100 burst request at the same time without any problem.
import java.io.BufferedReader;
import java.io.InputStreamReader;
import org.restlet.Component;
import org.restlet.Restlet;
import org.restlet.data.MediaType;
import org.restlet.data.Protocol;
import org.restlet.data.Request;
import org.restlet.data.Response;
public class Test2 {
private static Component component = new Component();
public static void main(String[] args) throws Exception {
// Create a new Restlet component and add a HTTP server
// connector to it
component.getServers().add(Protocol.HTTP, 1234);
// Print the requested URI path
StringBuffer message = new StringBuffer();
// setup a response with 80k
int size = 8;
char c = 'c';
for (int i = 0; i size; i++) {
message.append(c);
}
final String s = message.toString();
// Create a new tracing Restlet
Restlet restlet = new Restlet() {
@Override
public void handle(Request request, Response response) {
response.setEntity(s, MediaType.TEXT_PLAIN);
}
};
// Then attach it to the local host
component.getDefaultHost().attach(/, restlet);
// Now, let's start the component!
// Note that the HTTP server connector is also automatically
// started.
component.start();
BufferedReader in = null;
String line;
in = new BufferedReader(new InputStreamReader(System.in));
while (true) {
System.out.print( );
System.out.flush();
line = in.readLine();
if (line.startsWith(quit) || line.startsWith(exit))
{
// quits the test client
break;
}
}
component.stop();
}
}
Regards,
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1274309
Re: Random Grizzly IOException
Hi Jerome,
Sorry I finally got some time to dig into this problem again and I think
I've
found the cause of the round time delay.
In the ByteUtils, there's a SelectorFactory which is used when NIO
selectablechannel is used. Notice that the factory limits the total
number of
active selectors to 20, and if the pool ever runs empty, it'll wait
maximum of 2
periods of timeout before giving up. So the blocking we are seeing is coming
from this piece of code. (10s, 20s, 30s etc..)
The fix is relatively simple, since the selector (and selectionKey) is only
acquired in the NbChannelOutputStream when the channel is not available, the
code should release the selector at the finally block of the doWrite method
instead of waiting for the channel.close(). This will ensure that the
limited
number of selector is never kept for a long period of time.
Ex:
} finally {
this.bb.clear();
release(this.selector, this.selectionKey);
}
With this piece of code change, I was able to run the following test
code with
100 burst request at the same time without any problem.
import java.io.BufferedReader;
import java.io.InputStreamReader;
import org.restlet.Component;
import org.restlet.Restlet;
import org.restlet.data.MediaType;
import org.restlet.data.Protocol;
import org.restlet.data.Request;
import org.restlet.data.Response;
public class Test2 {
private static Component component = new Component();
public static void main(String[] args) throws Exception {
// Create a new Restlet component and add a HTTP server
// connector to it
component.getServers().add(Protocol.HTTP, 1234);
// Print the requested URI path
StringBuffer message = new StringBuffer();
// setup a response with 80k
int size = 8;
char c = 'c';
for (int i = 0; i size; i++) {
message.append(c);
}
final String s = message.toString();
// Create a new tracing Restlet
Restlet restlet = new Restlet() {
@Override
public void handle(Request request, Response response) {
response.setEntity(s, MediaType.TEXT_PLAIN);
}
};
// Then attach it to the local host
component.getDefaultHost().attach(/, restlet);
// Now, let's start the component!
// Note that the HTTP server connector is also automatically
// started.
component.start();
BufferedReader in = null;
String line;
in = new BufferedReader(new InputStreamReader(System.in));
while (true) {
System.out.print( );
System.out.flush();
line = in.readLine();
if (line.startsWith(quit) || line.startsWith(exit))
{
// quits the test client
break;
}
}
component.stop();
}
}
Regards,
Jerome Louvel wrote:
Hi Bruce,
Great news!
Regarding the 40s delay I'm puzzled... Did you monitor the state of sockets?
Are they all closed in a timely manner?
Did you try using a profiler to detect which part of the code actually
causes the delay?
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : news [mailto:n...@ger.gmane.org] De la part de Bruce Lee
Envoyé : jeudi 2 octobre 2008 02:42
À : discuss@restlet.tigris.org
Objet : Re: Random Grizzly IOException
Hi Jerome,
Thanks for the speedy fix yet again, all seems well (no more exceptions)
except that sometimes some request takes a long time to return. I have
yet to determine the cause though but here's the load test result using
JMeter.
Label,# Samples,Average,Median,90% Line,Min,Max,Error%,Throughput,KB/sec
Restlet Grizzly Load Test,1000,1115,5,22,4,40004,0.0,3.24859,253.796
Notice the maximum response time is 4ms (40s) but the
average/median/90% are less than 25ms. The test is done on the
previously stated system. Your dedication to this and timely response is
greatly appreciated.
Regards,
Jerome Louvel wrote:
Hi Bruce,
Thanks for the env details.
It seems to be due to a null selector passed as a parameter to the
register() method in ByteUtils. I've added an extra test in ByteUtils. It
might either fully fix the problem or move it somewhere else.
Could you test again with a recent snapshot?
http://www.restlet.org/downloads/snapshot.zip
Best regards,
Jérôme Louvel
--
Restlet
Re: Random Grizzly IOException
Hi Jerome,
My environment is as follows:
OS: Windows XP Pro SP2
JVM:
Java(TM) SE Runtime Environment (build 1.6.0_07-b06)
Java HotSpot(TM) Client VM (build 10.0-b23, mixed mode, sharing)
Regards,
Jerome Louvel wrote:
Hi Bruce,
Thanks for the reporting this new issue. I've entered a formal report:
NPE during NIO SelectableChannel.register
http://restlet.tigris.org/issues/show_bug.cgi?id=603
As it looks like a JVM bug, it would be very useful if you could indicate
your OS, JVM version on the report.
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : news [mailto:[EMAIL PROTECTED] De la part de Bruce Lee
Envoyé : vendredi 26 septembre 2008 18:39
À : discuss@restlet.tigris.org
Objet : Re: Random Grizzly IOException
Hi Jerome,
I downloaded the Restlet 1.1 RC2 and although it seems to be much better
than before, under running the test with Jmeter, there is still
exceptions being thrown. The exception is as follows:
SEVERE: An exception occured writing the response entity
java.lang.NullPointerException
at
java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableC
hannel.java:180)
at
java.nio.channels.SelectableChannel.register(SelectableChannel.java:254)
at
org.restlet.util.ByteUtils$NbChannelOutputStream.doWrite(ByteUtils.java:261)
at
org.restlet.util.ByteUtils$NbChannelOutputStream.write(ByteUtils.java:294)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202)
at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:263)
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:106)
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:116)
at java.io.OutputStreamWriter.write(OutputStreamWriter.java:203)
at java.io.Writer.write(Writer.java:140)
at
org.restlet.resource.StringRepresentation.write(StringRepresentation.java:21
0)
at
org.restlet.resource.StreamRepresentation.write(StreamRepresentation.java:68
)
at
com.noelios.restlet.http.HttpServerCall.writeResponseBody(HttpServerCall.jav
a:491)
at
com.noelios.restlet.http.HttpServerCall.sendResponse(HttpServerCall.java:429
)
at
com.noelios.restlet.http.HttpServerConverter.commit(HttpServerConverter.java
:388)
at
com.noelios.restlet.http.HttpServerHelper.handle(HttpServerHelper.java:148)
at
com.noelios.restlet.ext.grizzly.HttpParserFilter.execute(HttpParserFilter.ja
va:78)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolCh
ain.java:137)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.jav
a:67)
at
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56
)
at
com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:169)
Sep 26, 2008 12:35:53 PM com.noelios.restlet.LogFilter afterHandle
Regards,
Bruce Lee wrote:
Hi Jerome,
Thanks a lot for the timely fix! I'll be looking forward to test out the
1.1RC2.
Regards,
Jerome Louvel wrote:
Hi Bruce,
Thanks a lot for sharing this test class. It helped me to fix the
remaining NIO exception that occured when the main selector was
exhausted. Now a new temporary selector is properly registered and
selected. Your test class works flawlessly!
Please check in the upcoming 1.1 RC2.
Best,
Jerome
Jerome Louvel a écrit :
Hi Bruce,
I've just fixed the Grizzly/NIO exception that occurred on Linux
Resource
temporarily unavailable). This solves an issue that was reported by
several
persons and that we were experiencing as well.
I suggest that you try again when 1.1 RC2 is released. Hopefully soon
now.
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : news [mailto:[EMAIL PROTECTED] De la part de Bruce Lee
Envoyé : vendredi 19 septembre 2008 20:43
À : discuss@restlet.tigris.org
Objet : Re: Random Grizzly IOException
Hi Jerome,
Sorry to took so long to reply as I got side tracked with other tasks
at hand, but I have tried my test case with the latest Restlet 1.1
RC1 and the same problem still exists. I've attached my test code
with simple http server that simply tries to write 80k chars into the
response. If the client repeatedly request the page, then eventually
bytesWritten on the channel would be 0 (line 248 in ByteUtils.java)
and then it'll wait for 10 seconds with line 249
if (SelectorFactory.getSelector().select(1) == 0) {
Finally an exception will be logged. Interesting though, if you
remove the select line and allow it to spin on the channel write, the
correct data still gets written to the response. However, that is far
from the correct way
Re: Random Grizzly IOException
Hi Jerome,
I downloaded the Restlet 1.1 RC2 and although it seems to be much better
than before, under running the test with Jmeter, there is still
exceptions being thrown. The exception is as follows:
SEVERE: An exception occured writing the response entity
java.lang.NullPointerException
at
java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:180)
at
java.nio.channels.SelectableChannel.register(SelectableChannel.java:254)
at
org.restlet.util.ByteUtils$NbChannelOutputStream.doWrite(ByteUtils.java:261)
at
org.restlet.util.ByteUtils$NbChannelOutputStream.write(ByteUtils.java:294)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202)
at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:263)
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:106)
at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:116)
at java.io.OutputStreamWriter.write(OutputStreamWriter.java:203)
at java.io.Writer.write(Writer.java:140)
at
org.restlet.resource.StringRepresentation.write(StringRepresentation.java:210)
at
org.restlet.resource.StreamRepresentation.write(StreamRepresentation.java:68)
at
com.noelios.restlet.http.HttpServerCall.writeResponseBody(HttpServerCall.java:491)
at
com.noelios.restlet.http.HttpServerCall.sendResponse(HttpServerCall.java:429)
at
com.noelios.restlet.http.HttpServerConverter.commit(HttpServerConverter.java:388)
at
com.noelios.restlet.http.HttpServerHelper.handle(HttpServerHelper.java:148)
at
com.noelios.restlet.ext.grizzly.HttpParserFilter.execute(HttpParserFilter.java:78)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67)
at
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56)
at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:169)
Sep 26, 2008 12:35:53 PM com.noelios.restlet.LogFilter afterHandle
Regards,
Bruce Lee wrote:
Hi Jerome,
Thanks a lot for the timely fix! I'll be looking forward to test out the
1.1RC2.
Regards,
Jerome Louvel wrote:
Hi Bruce,
Thanks a lot for sharing this test class. It helped me to fix the
remaining NIO exception that occured when the main selector was
exhausted. Now a new temporary selector is properly registered and
selected. Your test class works flawlessly!
Please check in the upcoming 1.1 RC2.
Best,
Jerome
Jerome Louvel a écrit :
Hi Bruce,
I've just fixed the Grizzly/NIO exception that occurred on Linux
Resource
temporarily unavailable). This solves an issue that was reported by
several
persons and that we were experiencing as well.
I suggest that you try again when 1.1 RC2 is released. Hopefully soon
now.
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : news [mailto:[EMAIL PROTECTED] De la part de Bruce Lee
Envoyé : vendredi 19 septembre 2008 20:43
À : discuss@restlet.tigris.org
Objet : Re: Random Grizzly IOException
Hi Jerome,
Sorry to took so long to reply as I got side tracked with other tasks
at hand, but I have tried my test case with the latest Restlet 1.1
RC1 and the same problem still exists. I've attached my test code
with simple http server that simply tries to write 80k chars into the
response. If the client repeatedly request the page, then eventually
bytesWritten on the channel would be 0 (line 248 in ByteUtils.java)
and then it'll wait for 10 seconds with line 249
if (SelectorFactory.getSelector().select(1) == 0) {
Finally an exception will be logged. Interesting though, if you
remove the select line and allow it to spin on the channel write, the
correct data still gets written to the response. However, that is far
from the correct way to implement NIO so I've also tried replacing
the select with the following code.
Selector writeSelector = SelectorFactory
.getSelector();
if (writeSelector == null) {
// Continue using the main one.
continue;
}
((SelectableChannel) this.channel).register(
writeSelector, SelectionKey.OP_WRITE);
if (writeSelector.select(1) == 0) {
throw new IOException(Client disconnected);
}
But another set of exceptions occurs after a few requests:
java.io.IOException: An established connection was aborted by the
software in your host machine
at sun.nio.ch.SocketDispatcher.write0(Native Method)
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:33)
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:104)
at sun.nio.ch.IOUtil.write(IOUtil.java:75)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334
Re: Random Grizzly IOException
Hi Jerome,
Thanks a lot for the timely fix! I'll be looking forward to test out the
1.1RC2.
Regards,
Jerome Louvel wrote:
Hi Bruce,
Thanks a lot for sharing this test class. It helped me to fix the
remaining NIO exception that occured when the main selector was
exhausted. Now a new temporary selector is properly registered and
selected. Your test class works flawlessly!
Please check in the upcoming 1.1 RC2.
Best,
Jerome
Jerome Louvel a écrit :
Hi Bruce,
I've just fixed the Grizzly/NIO exception that occurred on Linux Resource
temporarily unavailable). This solves an issue that was reported by several
persons and that we were experiencing as well.
I suggest that you try again when 1.1 RC2 is released. Hopefully soon now.
Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : news [mailto:[EMAIL PROTECTED] De la part de Bruce Lee
Envoyé : vendredi 19 septembre 2008 20:43
À : discuss@restlet.tigris.org
Objet : Re: Random Grizzly IOException
Hi Jerome,
Sorry to took so long to reply as I got side tracked with other tasks at
hand, but I have tried my test case with the latest Restlet 1.1 RC1 and
the same problem still exists. I've attached my test code with simple
http server that simply tries to write 80k chars into the response. If
the client repeatedly request the page, then eventually bytesWritten on
the channel would be 0 (line 248 in ByteUtils.java) and then it'll wait
for 10 seconds with line 249
if (SelectorFactory.getSelector().select(1) == 0) {
Finally an exception will be logged. Interesting though, if you remove
the select line and allow it to spin on the channel write, the correct
data still gets written to the response. However, that is far from the
correct way to implement NIO so I've also tried replacing the select
with the following code.
Selector writeSelector = SelectorFactory
.getSelector();
if (writeSelector == null) {
// Continue using the main one.
continue;
}
((SelectableChannel) this.channel).register(
writeSelector, SelectionKey.OP_WRITE);
if (writeSelector.select(1) == 0) {
throw new IOException(Client disconnected);
}
But another set of exceptions occurs after a few requests:
java.io.IOException: An established connection was aborted by the
software in your host machine
at sun.nio.ch.SocketDispatcher.write0(Native Method)
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:33)
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:104)
at sun.nio.ch.IOUtil.write(IOUtil.java:75)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334)
at
org.restlet.util.ByteUtils$NbChannelOutputStream.doWrite(ByteUtils.java:243)
at
org.restlet.util.ByteUtils$NbChannelOutputStream.write(ByteUtils.java:291)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202)
at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:272)
at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:276)
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:122)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:212)
at
org.restlet.resource.StringRepresentation.write(StringRepresentation.java:21
2)
at
org.restlet.resource.StreamRepresentation.write(StreamRepresentation.java:68
)
at
com.noelios.restlet.http.HttpServerCall.writeResponseBody(HttpServerCall.jav
a:491)
at
com.noelios.restlet.http.HttpServerCall.sendResponse(HttpServerCall.java:429
)
at
com.noelios.restlet.http.HttpServerConverter.commit(HttpServerConverter.java
:388)
at
com.noelios.restlet.http.HttpServerHelper.handle(HttpServerHelper.java:148)
at
com.noelios.restlet.ext.grizzly.HttpParserFilter.execute(HttpParserFilter.ja
va:78)
at
com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolCh
ain.java:137)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.jav
a:67)
at
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56
)
at
com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:169)
Sep 19, 2008 2:29:40 PM com.noelios.restlet.http.HttpServerConverter commit
SEVERE: An exception occured writing the response entity
java.io.IOException: Unable to write to the non-blocking channel. An
established connection was aborted by the software in your host machine
at
org.restlet.util.ByteUtils$NbChannelOutputStream.doWrite(ByteUtils.java:274)
at
org.restlet.util.ByteUtils$NbChannelOutputStream.write(ByteUtils.java:291)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202)
at sun.nio.cs.StreamEncoder.implFlushBuffer
Re: Random Grizzly IOException
) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56) at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:169) Sep 19, 2008 2:29:40 PM com.noelios.restlet.http.HttpServerConverter commit WARNING: Unable to send error response java.io.IOException: An established connection was aborted by the software in your host machine at sun.nio.ch.SocketDispatcher.write0(Native Method) at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:33) at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:104) at sun.nio.ch.IOUtil.write(IOUtil.java:75) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:334) at com.sun.grizzly.util.OutputWriter.flushChannel(OutputWriter.java:105) at com.sun.grizzly.util.OutputWriter.flushChannel(OutputWriter.java:73) at com.noelios.restlet.ext.grizzly.GrizzlyServerCall.writeResponseHead(GrizzlyServerCall.java:269) at com.noelios.restlet.http.HttpServerCall.sendResponse(HttpServerCall.java:416) at com.noelios.restlet.http.HttpServerConverter.commit(HttpServerConverter.java:407) at com.noelios.restlet.http.HttpServerHelper.handle(HttpServerHelper.java:148) at com.noelios.restlet.ext.grizzly.HttpParserFilter.execute(HttpParserFilter.java:78) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:137) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:104) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:67) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:56) at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:169) Regards Jerome Louvel wrote: Hi Bruce, There is an existing bug report covering this exception: File transfer exception on Linux http://restlet.tigris.org/issues/show_bug.cgi?id=502 It would help if you could attach a simple reproducible test case and maybe dig into Grizzly extension code if you are more adventurous! Best regards, Jerome -Message d'origine- De : news [mailto:[EMAIL PROTECTED] De la part de Bruce Lee Envoye : mercredi 2 juillet 2008 22:02 A : discuss@restlet.tigris.org Objet : Random Grizzly IOException Hi, I'm testing out grizzly connector with the 1.1M4 built and I noticed that for requests takes a bit longer to generate the report, sometimes the following exceptions occurs: Jul 2, 2008 4:01:11 PM com.noelios.restlet.http.HttpServerConverter commit INFO: Exception intercepted java.io.IOException: Unable to write to the non-blocking channel. Unable to sele ct the channel to write to it. Selection timed out. at org.restlet.util.ByteUtils$NbChannelOutputStream.write(ByteUtils.java:219) at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202) at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:263) at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:106) at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:116) at java.io.OutputStreamWriter.write(OutputStreamWriter.java:203) at java.io.Writer.write(Writer.java:140) at org.restlet.resource.StringRepresentation.write(StringRepresentation.java:19 9) at org.restlet.resource.StreamRepresentation.write(StreamRepresentation.java:59 ) at com.noelios.restlet.http.HttpServerCall.writeResponseBody(HttpServerCall.jav a:545) at com.noelios.restlet.http.HttpServerCall.sendResponse(HttpServerCall.java:484 ) at com.noelios.restlet.http.HttpServerConverter.commit(HttpServerConverter.java :394) at com.noelios.restlet.http.HttpServerHelper.handle(HttpServerHelper.java:96) at com.noelios.restlet.ext.grizzly.HttpParserFilter.execute(HttpParserFilter.ja va:68) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolCh ain.java:124) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:75) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.jav a:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57 ) at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:154) This happens maybe every few other requests and hence renders the extension unusable. I'm wondering if this is a known issue with the extension or there is something I need to configure to avoid hitting this error. My environment is as follows: jdk1.6.0_06 restlet 1.1m4 grizzly 1.7.3 (also tried 1.8.0, the same error) The output is a XML file converted to String object, stored with StringRepresentation. Regards, import java.io.BufferedReader; import java.io.InputStreamReader; import org.restlet.Component; import
Re: How to create multiple https connector with different certificates?
Hi, Thanks for the information, I guess we will have to wait until Restlet 1.1 becomes stable so we can try out the feature. Regards,
Random Grizzly IOException
Hi, I'm testing out grizzly connector with the 1.1M4 built and I noticed that for requests takes a bit longer to generate the report, sometimes the following exceptions occurs: Jul 2, 2008 4:01:11 PM com.noelios.restlet.http.HttpServerConverter commit INFO: Exception intercepted java.io.IOException: Unable to write to the non-blocking channel. Unable to sele ct the channel to write to it. Selection timed out. at org.restlet.util.ByteUtils$NbChannelOutputStream.write(ByteUtils.java:219) at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202) at sun.nio.cs.StreamEncoder.implWrite(StreamEncoder.java:263) at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:106) at sun.nio.cs.StreamEncoder.write(StreamEncoder.java:116) at java.io.OutputStreamWriter.write(OutputStreamWriter.java:203) at java.io.Writer.write(Writer.java:140) at org.restlet.resource.StringRepresentation.write(StringRepresentation.java:19 9) at org.restlet.resource.StreamRepresentation.write(StreamRepresentation.java:59 ) at com.noelios.restlet.http.HttpServerCall.writeResponseBody(HttpServerCall.jav a:545) at com.noelios.restlet.http.HttpServerCall.sendResponse(HttpServerCall.java:484 ) at com.noelios.restlet.http.HttpServerConverter.commit(HttpServerConverter.java :394) at com.noelios.restlet.http.HttpServerHelper.handle(HttpServerHelper.java:96) at com.noelios.restlet.ext.grizzly.HttpParserFilter.execute(HttpParserFilter.ja va:68) at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolCh ain.java:124) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:90) at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:75) at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.jav a:54) at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57 ) at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:154) This happens maybe every few other requests and hence renders the extension unusable. I'm wondering if this is a known issue with the extension or there is something I need to configure to avoid hitting this error. My environment is as follows: jdk1.6.0_06 restlet 1.1m4 grizzly 1.7.3 (also tried 1.8.0, the same error) The output is a XML file converted to String object, stored with StringRepresentation. Regards,
Re: Using Grizzly adapter with Restlet
Jerome Louvel contact at noelios.com writes: Also, the way the Jetty connector for Restlet works doesn't require the costly Servlet container layer, it's using a lower level Jetty API. So performance are very good and could be compared to those of the Grizzly connector for Restlet. Hi Jerome, I was able to port my application directly to use the Jetty http connector by following http://www.restlet.org/documentation/1.1/connectors. However, such approach utilizes Jetty's Servlet container layer, which we would like to avoid. Can you provide a simple example of using Jetty connector for Restlet directly without the Servlet container? Regards,
Using Grizzly adapter with Restlet
Hi, Currently my application is designed as a servlet inside Tomcat, which was working fine but we would like to move away from Tomcat to have better control on on the application life cycle is managed. I have tried using the latest Restlet (1.1M4) with the Grizzly and the migration was easy as swapping in the restlet extension jars. However I am not so sure on how to create an HTTPS server instead of HTTP server. Right now I'm using the following code to start up an HTTP server: component = new Component(); component.getServers().add(Protocol.HTTP, port); // initialize the Service ServiceContext context = new ServiceContext(component.getContext(), configuration); // Attach the application to the context root and start it component.getDefaultHost().attach(ServiceContext.CONTEXT_ROOT, context); component.start(); So for starting a HTTPS server, do I just change the protocol to HTTPS? Where would I specify the keystorePath, keystorePassword etc? Also, I'm also wondering if the Grizzly extension will be production ready for 1.1 release of Restlet? Regards,
Re: Using Grizzly adapter with Restlet
Hi Bruce, Currently, the Grizzly connector is not ready for production. There are a couple of outstanding bugs that we need to fix. We'd like to run some benchmarks as well before final 1.1 release. However, even if 1.1 release should be ready for production, it would still be marked as testing in our download page: http://www.restlet.org/downloads/ It's only a couple of months after, when we release 1.2 M1, that 1.1 release will become the stable official release instead of 1.0. We try to follow a release cycle similar to Debian. Now, if stability matters the most, I would recommend using the Jetty connector instead, which we have since Restlet 1.0. Regarding connectors configuration, check this page: http://www.restlet.org/documentation/1.1/connectors Best regards, Jerome Hi Jerome, Thanks for the detailed response. The main reason we want to use Grizzly directly is because we simply want a high performance http/https connector without any web server capabilities. Embedding Jetty seems like a reasonable approach but we are concerning about the extra processing overhead. Also since Jetty can use Grizzly connector as well, would you recommend using the Jetty extension with Grizzly connector instead of their default connector? P.S. Is there an existing example of setting up HTTPS using Grizzly connector? Regards,
