Hello Jerome, Thnx for explanation. Fortunately we accepted thread-per-request model finally :) So for now this problem is solved, In out case we also laveraged grizzly comet extension to prototype non-blocking long request processing.
> Hi Evgeny, > > Regarding the Grizzly connector, there is an existing RFE to support its > configuration via properties. For now you would have to subclass it an > override the "configure(Controller)" method: > > "Improve Grizzly connector" > http://restlet.tigris.org/issues/show_bug.cgi?id=563 > > Now, your requirement implies that you need as many worker threads as > there > are clients connected because one thread would be blocked in each > write(OutputStream) method... > > If you can't support 500 threads at the same time in your JVM or can't do > load-balancing, then I don't think the current level of NIO support in > Restlet will help. NIO connectors such as Grizzly and Jetty reduce the > number of IO threads used so you can accept more connections that the > actual > number of worker threads available. But in the case of long-lived > connections that doesn't help. > > What you are looking requires fully asynchronous processing support in > Restlet which isn't available yet. See the related RFE: > > "Support asynchronous processing" > http://restlet.tigris.org/issues/show_bug.cgi?id=143 > > Even though we did make progress in this front thanks to our GWT edition > (client-side), we still have work to do to port this logic to other > edition > and support asynchronicity on the server-side. > > As a workaround, you might want to directly explore Jetty and Grizzly > asynchronous features. > > 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 : news [mailto:n...@ger.gmane.org] De la part de Evgeny Shepelyuk > Envoyé : jeudi 30 juillet 2009 16:16 > À : discuss@restlet.tigris.org > Objet : Scalable media server in restlet - HOW TO ? > > Hello, > > I need some advices on building scalable media server with restlet. > The idea is to buld application that serves media to relative big number > clients (about >500). > The spec,ific features of clients' request are HTTP long-living nature. > So > once connected client permanently fetches content from server. > Because simultaneous number of clients is high the blocking > thread-per-request model is not appropriate (maybe im wrong ?). > > My current approach consist of following steps > > 1. restlet that returns HTTP OK and custom representaion (extending > OutputRepresentation) > 2. representation has blocking queue inside it and in write() method > register that queue inside media manager > to be notified about media events that should be streamed to underlying > client. > 3. HTTP connection should not break and be permanent -> client should not > reconnect after it got connected to server. > 4. inside write() method of representation i'm performing blocking get > from blockign queue to receive event from media manager > that should be written to client's stream. > > So now i'm playing with jetty NIO connector paramters and can server > about > 200-250 requests but its no less thatn required. > Can anyone give me some advice on designing the project to achieve > requred > scalability ? > > PS: I was trying to use Grizzly connector with approach described above > but it was serving about 10 clients and not more. > Also the Grizzly connector seems not having parameters to configure > > PPS: Im using restlet 2.0m3 > -- Regards, Evgeny Shepelyuk ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2384267
