Thread starvation problem: 1) the Velocity servlet is deployed at /velocity 2) the REST API is in another app deployed at /rest 3) the JS client makes a call to /velocity - this acquires one worker thread 4) the Velocity servlet by using some HTTP client Java library makes a call to /rest - this acquires a second worker thread So now we have one request from the end user (the JS call) but it needs two worker threads to do the job. When the REST call returns it releases the second thread and then the velocity request is processed and releases the first acquired thread. This is the starvation part.
The deadlock case: let's say your worker thread pool has MAX value - 100 threads. This means that if you have 100 simultaneous requests from the JS clients you will acquire all the 100 worker threads at once. In this corner case none of these threads could make its call to the REST API because there is no free worker thread to process it, so all 100 will hang waiting for resources/threads. In Tomcat thread pools are per HTTPConnector so you can "solve" this problem by making the calls to the REST APIs on a second http port (second http connector) but this will mean that you have to configure Tomcat before deploying the app and use some kind of firewall to hide the REST APIs from end clients (JS ones). If this additional admin setup is OK for your app then it will work. I'm not trying to convince you to use Wicket. The same problem is valid if your Wicket code makes these additional http requests to the REST APIs. In any case, I'll be glad to know which direction you and your colleagues at OpenMeetings will choose. On Sun, Aug 26, 2012 at 8:12 PM, seba.wag...@gmail.com <seba.wag...@gmail.com> wrote: > The security aspect is true. I don't see a problem in the worker > threads yet, however you might be right. > > We might try a Wicket example to see how we can integrate all our > existing code into it. > > Thanks! > Sebastian > > 2012/8/26 Martin Grigorov <mgrigo...@apache.org>: >> Hi Sebastian, >> >> I see a little problem in your architecture - the jQuery client will >> make a request to the Velocity servlet, then if you use >> the REST API you'll need to make another http request. If both the >> servlet app and the REST app are deployed on the same >> web container instance/node then you will face thread starvation >> problem for http worker threads, possible deadlock too. So you may >> need to deploy the different parts on different nodes. >> >> Also think early how you will implement the security part of the application. >> >> Sometimes classics are much easier ;-) >> >> On Sun, Aug 26, 2012 at 5:36 PM, seba.wag...@gmail.com >> <seba.wag...@gmail.com> wrote: >>> Thanks for the detailed answer Martin! >>> >>> You are right in my description I missed one part, for generating the >>> HTML my plan was to use Apache Velocity. The REST interface will only >>> generate data to fill that HTML. >>> >>> I've created a MockUp of the architecture proposal that should cover it all: >>> https://cwiki.apache.org/confluence/display/OPENMEETINGS/DHTML+Proposal >>> >>> Wicket seems to be more likely to be a classic >>> web-application-framework. From my point of view we are more looking >>> for a UI framework. >>> >>> Thanks! >>> Sebastian >>> >>> 2012/8/26 Martin Grigorov <mgrigo...@apache.org>: >>>> Hi, >>>> >>>> You didn't say what your web service response's type is. >>>> By referring to jQuery's #load() method it seems like your WS returns >>>> ready to render HTML, but later you say that you will create the >>>> content with pure JavaScript (JQuery) which makes me think that the >>>> returned response is plain data (JSON, XML, ...) which you will use to >>>> generate the HTML. >>>> >>>> Wicket is (mostly) server side framework, i.e. it generates the HTML >>>> at the server and sends it to the browser for rendering. For single >>>> page applications (SPA) you start with rendering a whole Page and then >>>> by using Wicket Ajax components just need to update your components' >>>> models (pure Java code executed at the server) and Wicket will >>>> generate the HTML and send it to the browser to update the part(s) of >>>> the page. Wicket 6.0 also provides integrations with Atmosphere >>>> framework and Native WebSocket so you can use newer (HTML5) >>>> technologies for updating the view at the client side. Again you'll >>>> have to write mostly Java code to implement this. >>>> The benefit is that you can test all this very easily with >>>> unit/functional tests written in Java. >>>> >>>> If you want to use JavaScript to render the returned plain data from >>>> your web service then there is no need to include Wicket in the >>>> technology stack. But in this case you will need to use some >>>> JavaScript testing library. The JS testing libs became better last >>>> year but still not that good as Java ones. >>>> >>>> In both cases using Selenium for more complicated test scenaria will be >>>> needed. >>>> >>>> HTH >>>> martin-g >>>> >>>> On Sun, Aug 26, 2012 at 2:24 PM, seba.wag...@gmail.com >>>> <seba.wag...@gmail.com> wrote: >>>>> Hi, >>>>> >>>>> we are developers from the Apache project "Apache OpenMeetings", we >>>>> provide a Web-Conferencing application that is currently Flash-based >>>>> on the client side. >>>>> We already have a server side stack with Spring + openJPA + Axis2 that >>>>> provides us with a SOAP/REST API and ORM. >>>>> >>>>> We are currently discussing an HTML5 alternative for our Flash based >>>>> client and have to decide some basic framework questions. >>>>> Apache Wicket is one option. >>>>> >>>>> Our HTML client is likely to be a single HTML page that loads content >>>>> / components dynamically into the website. >>>>> My idea was first to use http://api.jquery.com/load/ to load >>>>> components dynamically, however maybe Wicket has a similar mechanism? >>>>> It seems like the combination of jQuery + Wicket is the most widespreaded. >>>>> But if we create our content with pure jQuery, why adding Wicket to it? >>>>> I was told that Wicket's strength is to provide a Non-JavaScript >>>>> version of the website if JavaScript is not available. However as our >>>>> basic features will be collaboration tools that really make no sense >>>>> without JavaScript, we don't need a Non-JavaScript version. >>>>> And we have already a REST interface, we don't need to duplicate one >>>>> with Wicket that provides yet another API. >>>>> >>>>> Maybe there are other arguments positive for using Wicket that I have >>>>> overseen? >>>>> >>>>> Thanks for sharing! >>>>> Sebastian >>>>> -- >>>>> Sebastian Wagner >>>>> https://twitter.com/#!/dead_lock >>>>> http://www.webbase-design.de >>>>> http://www.wagner-sebastian.com >>>>> seba.wag...@gmail.com >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>>> >>>> >>>> >>>> >>>> -- >>>> Martin Grigorov >>>> jWeekend >>>> Training, Consulting, Development >>>> http://jWeekend.com >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>>> For additional commands, e-mail: users-h...@wicket.apache.org >>>> >>> >>> >>> >>> -- >>> Sebastian Wagner >>> https://twitter.com/#!/dead_lock >>> http://www.webbase-design.de >>> http://www.wagner-sebastian.com >>> seba.wag...@gmail.com >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >> >> >> >> -- >> Martin Grigorov >> jWeekend >> Training, Consulting, Development >> http://jWeekend.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> > > > > -- > Sebastian Wagner > https://twitter.com/#!/dead_lock > http://www.webbase-design.de > http://www.wagner-sebastian.com > seba.wag...@gmail.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
