In front I have nothing, it's not an application that has to manage thousand of user, it's an interface for an embedded system.
Still the user is able to close the browser while a modal dialog is shown like: "quit without saving?". G. On Wed, Sep 21, 2011 at 1:06 AM, Matthew Sherborne <msherbo...@gmail.com> wrote: > hoepfully this helps. > With my mutli-threaded, single process deployment, not behind any proxies > deployment, I can handle 1000 concurrent users using 'siege' and at the same > time use the application quickly in both chrome and firefox. I haven't run > siege for more than 5 minutes at a time, but the process doesn't get above > 35 MB of RAM usage, then after siege goes away, drops back down to like 28 > MB. It handled 648.5 req/s from siege. The process is still running .. > hasn't locked up yet. http://barcamp.supa.ws (you can log in with 'admin' > 'admin' and play around if you like. > I wonder if the proxies in front of the deployment are the things causing > the trouble ? What do you have in front ? ha-proxy ? > Kind Regards, > Matthew Sherborne > On Wed, Sep 21, 2011 at 7:51 AM, Wim Dumon <w...@emweb.be> wrote: >> >> The proper solution is not to use recursive event loops. You can avoid >> them even when you use modal dialogs, and it's only a little more >> programming work. It will eliminate this 'exhausted thread pool' >> problem completely. Recursive event loops don't really scale with >> concurrent sessions. >> >> Is there someting special in your system that guarantees that you >> shouldn't have concurrent users? (e.g. it only makes sense to have one >> session?) If that is the case, we should maybe provide an API that >> allows to kill existing session... but I'm not sure if that's a good >> idea. >> >> BR, >> Wim. >> >> 2011/9/19 Gaetano Mendola <mend...@gmail.com>: >> > Koen, >> > the most annoying aspect is that when the sessions are all taken then >> > the first modal dialog >> > deadlocks the entire application, is there a way to detect that >> > sessions are over and then >> > give an error or at least make force all ajax connections to be check? >> > >> > >> > On Mon, Sep 19, 2011 at 2:54 PM, Antonio Mancina <amanc...@mbigroup.it> >> > wrote: >> >> Hey Koen, >> >> >> >> >> [...] >> >>>> shown on screen: as soon as the user closes the tab, the >> >>>> wt server detects this event and properly deallocates the >> >>>> session without waiting for the timeout to expire. >> >>> >> >>> You actually see a difference in the same browser with a dialog open >> >>> or not for the session to be released? Then that is a bug. >> >> >> >> yes, that is definitely the case! Hope you have the chance to >> >> reproduce and fix it. >> >> >> >>>> 3) Also, would it be possible to detect thread pool exhaustion at >> >>>> code-level, avoiding the user being stuck waiting for a timeout >> >>>> to happen? >> >>> >> >>> Actually, there is no reason to lock a thread while showing modal >> >>> dialogs. You can also show a modal dialog by using show(), and binding >> >>> listeners to its accept(), reject() or done() methods. The behavior is >> >>> the same, but it is a bit less convenient to implement. >> >> >> >> Yes, agreed. Just a matter of convenience, indeed. >> >> >> >>> Regards, >> >>> koen >> >> >> >> Thanks for your explanations. >> >> >> >> Bye, >> >> Antonio >> >> >> >> >> >> ------------------------------------------------------------------------------ >> >> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA >> >> Learn about the latest advances in developing for the >> >> BlackBerry® mobile platform with sessions, labs & more. >> >> See new tools and technologies. Register for BlackBerry® DevCon >> >> today! >> >> http://p.sf.net/sfu/rim-devcon-copy1 >> >> _______________________________________________ >> >> witty-interest mailing list >> >> witty-interest@lists.sourceforge.net >> >> https://lists.sourceforge.net/lists/listinfo/witty-interest >> >> >> > >> > >> > >> > -- >> > cpp-today.blogspot.com >> > >> > >> > ------------------------------------------------------------------------------ >> > All the data continuously generated in your IT infrastructure contains a >> > definitive record of customers, application performance, security >> > threats, fraudulent activity and more. Splunk takes this data and makes >> > sense of it. Business sense. IT sense. Common sense. >> > http://p.sf.net/sfu/splunk-d2dcopy1 >> > _______________________________________________ >> > witty-interest mailing list >> > witty-interest@lists.sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/witty-interest >> > >> >> >> ------------------------------------------------------------------------------ >> All the data continuously generated in your IT infrastructure contains a >> definitive record of customers, application performance, security >> threats, fraudulent activity and more. Splunk takes this data and makes >> sense of it. Business sense. IT sense. Common sense. >> http://p.sf.net/sfu/splunk-d2dcopy1 >> _______________________________________________ >> witty-interest mailing list >> witty-interest@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/witty-interest > > > ------------------------------------------------------------------------------ > All the data continuously generated in your IT infrastructure contains a > definitive record of customers, application performance, security > threats, fraudulent activity and more. Splunk takes this data and makes > sense of it. Business sense. IT sense. Common sense. > http://p.sf.net/sfu/splunk-d2dcopy1 > _______________________________________________ > witty-interest mailing list > witty-interest@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/witty-interest > > -- cpp-today.blogspot.com ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ witty-interest mailing list witty-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/witty-interest
