Hi Bora, The benefit can be at two levels:
1) By leveraging NIO while handling the socket IO, Grizzly doesn't need to dedicate one thread per accepted request, therefore potentially increasing the scalability of your component. Note that the Jetty connector can also use NIO in a similar way. 2) By using direct disk to socket transfer. This is a feature of NIO that allows you to transfer content directly from the disk IO layer to the network IO layer, without having to go through the JVM memory space. This potentially allows better performance and reduced CPU load. Regarding 1), the best is to do some benchmarks to determine which connectors scales the best for your own application loads. Note that the advantage 2) doesn't work if you generate your representation dynamically. Only if you return, directly or indirectly (such as via Directory) a FileRepresentation. Now, from what you describe, it seems that you are looking for asynchronous call processing, in order to be able to release the processing thread while waiting for some external event to arrive (ec: connection to a third-party system). This isn't available yet, but there is a RFE: "Support asynchronous processing" http://restlet.tigris.org/issues/show_bug.cgi?id=143 Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -----Message d'origine----- De : bora [mailto:boraozt...@hotmail.com] Envoyé : mardi 10 mars 2009 19:55 À : discuss@restlet.tigris.org; stephan.ko...@web.de Objet : Re: Grizzly NIO examples I am having a little hard time understanding the real benefit of using the Grizzly NIO with Restlet. (or the way I am suppose to use, to be more precise) Lets assume I have a Resource that does a long I/O (that talks to an external server through a socket connection) and process what returns from external server so that the Resource returns some StringRepresentation as a result. Assuming a fresh new thread is created for each Resource and for the socket connection to the external server. What would be the real benefit of switching to Grizzly I/O Server and how should this be accomplished. Should only using the Grizzly Connector improve performance since the server will handle the NIO or should I change the current code to implement some Reactor pattern? Any help is highly appreciated. Bora -------------------------------------------------- From: "Stephan Koops" <stephan.ko...@web.de> Sent: Wednesday, February 25, 2009 5:35 PM To: <discuss@restlet.tigris.org> Subject: Re: Grizzly NIO examples > Hi Bora, > > normaly just put the connector in the classpath and everything is done ... > > best regards > Stephan > > bora schrieb: >> Being also new to Grizzly, >> I couldn't even came across any unit tests on the usage of Grizzly >> NIO Connector. >> Is there any documentation on how to use the connector. >> Thanks in advance >> Bora > > ------------------------------------------------------ > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId > =1228992 > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=13043 78 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=1333423
