On 10/6/2017 1:10 PM, Christoph Nenning wrote: > Hi, > > > >> ## My elementary idea >> >> >> >> I would like to try if I can implement following and if it works: I will > >> >> define a new Interface named AsyncResult which has a method named >> >> clock() which returns false if the Result has finished the whole job. >> >> Whenever Struts saw an AsyncResult, it starts an async request via >> >> Servlet 3's async API, then passes that to an internal thread pool named > >> >> StrutsAsyncResultsThreadPool (SARTP), then executes a null result >> >> instead. From that side, SARTP always round-robins among AsyncResults >> >> and calls their clock()s and completes async and removes them from list >> >> if clock() returned false :) >> > > > Basically this sounds good to me. > > As far as I understand that means that async work would not be done by > actions but by results? > > I don't like the idea of calling clock() in a timely manner. I would > prefer if AsyncResult could notify struts when it is finished or when more > data arrived. > > > What about executing actions in StrutsAsyncThreadPool (SATP) and having a > more general AsyncResult to call AsyncContext.complete() (that general > AsyncResult would be executed in SATP, too) ? >
Hello Christoph, Yes we can but as far as I could understand, there is no gain (with current modern containers e.g. tomcat). For example, if SATP pool size is n and it's queue size is q and the os only can handle less than N concurrent threads, then you can get better results e.g. in tomcat by increasing it's MaxThreads by n and it's AcceptCount by q! and you will get best result by setting it's MaxThreads to N. So I think we just made it harder with no gain. But when is there a gain? I could find when we are able to round-robin CPU among current connected clients which their count is very bigger than N; This improves the number of required threads to handle the requests and the system will scale under heavy load [1]. So, as it seems that java does not enable us to "time slicing" CPU between those threads, I had to invent the clock() method :) and if we define such interface for actions also, then yes, I think we will have gain. Overall I think it's not as simple as it appears and needs advanced knowledge in http, servlets, filters and Strut's internals. Sincerely Yours, Yasser. [1] http://www.byteslounge.com/tutorials/asynchronous-servlets-in-java > > > Regards, > Christoph > > > >> From: Yasser Zamani <yasser.zam...@live.com> >> To: "dev@struts.apache.org" <dev@struts.apache.org>, >> Date: 04.10.2017 11:09 >> Subject: Re: Support for actors/asynchronous request handling >> >> Dave, Christoph, Łukasz, hello, Eureka! >> >> >> >> I think I have good news :) I think, now, I have good info which are >> >> helpful for Struts structural decisions and what and how we can do in >> >> Struts about asynchronous! >> >> >> >> After about one month fooling my computer ;) I think I can update this >> >> thread as below (you may skip to "## My elementary idea" if not >> >> interested in details): >> >> >> >> # Why not doing Strut's internal processes asynchronously e.g. via akka? >> >> >> >> because ... "Hardware is cheap", Bozho says. Bozho has one year >> >> experience and his article at [1] convinced me. He says: "...given the >> >> unclear benefits (if any), I would say that programming, testing and >> >> supporting the code is the main distinguishing feature. Whether you are >> >> going to be able to serve 10000 or 11000 concurrent users from a single >> >> machine doesn’t really matter. Hardware is cheap. (unless it’s 1000 vs >> >> 10000, of course) ... But why is the non-blocking, asynchronous, >> >> event/message-driven programming paradigm harder? For me, at least, even > >> >> after a year of writing in that paradigm, it’s still messier. First, it >> >> is way harder to trace the programming flow. With a synchronous code you > >> >> would just tell your IDE to fetch the call hierarchy (or find the usage >> >> of a given method if your language is not IDE-friendly), and see where >> >> everything comes and goes. With events it’s not that trivial. Who >> >> constructs this message? Where is it sent to / who consumes it? How is >> >> the response obtained – via callback, via another message? When is the >> >> response message constructed and who actually consumes it? And no, >> >> that’s not “loose coupling”, because your code is still pretty logically > >> >> (and compilation-wise) coupled, it’s just harder to read". >> >> >> >> # So, what can we do in Struts about asynchronous? >> >> >> >> This was my main question! I was wondering how does Servlet 3's Async >> >> API make sense ever?! I played with tomcat and I made Strut's filter >> >> completely async and played a lot with them but could not sense any >> >> improvement! ACTUALLY I THOUGHT THERE IS NO NEED FOR SERVLET 3'S ASYNC >> >> API AT ALL because I saw I can increase container (e.g. tomcats)'s >> >> thread pool size and get same results!! so I started a discussion with >> >> tomcat's team ended at [2]. Then I found out I should search for a use >> >> case which is not implementable at all without Servlet's async api and >> >> yes, I found one at [3]. >> >> >> >> ## The sample use case >> >> >> >> Special thanks to Gonçalo Marques who has introduced an "Effective usage > >> >> of Asynchronous Servlets" at [3]. Suppose I have a site developed by >> >> Struts and then I want to stream a big file (e.g. an one hour movie) to >> >> remote clients. In this one hour, the site may have thousands of clients > >> >> in a given time so I cannot solve this by increasing tomcat's thread >> >> pool size to thousands (e.g. my os cannot handle this lot of threads)! >> >> Instead, I would like round-robin among current connected clients and >> >> send chunks of n bytes one by one in each round; this is where Struts >> >> crys :) >> >> >> >> ## My elementary idea >> >> >> >> I would like to try if I can implement following and if it works: I will > >> >> define a new Interface named AsyncResult which has a method named >> >> clock() which returns false if the Result has finished the whole job. >> >> Whenever Struts saw an AsyncResult, it starts an async request via >> >> Servlet 3's async API, then passes that to an internal thread pool named > >> >> StrutsAsyncResultsThreadPool (SARTP), then executes a null result >> >> instead. From that side, SARTP always round-robins among AsyncResults >> >> and calls their clock()s and completes async and removes them from list >> >> if clock() returned false :) >> >> >> >> With Best Regards, >> >> Yasser. >> >> >> >> [1] https://urldefense.proofpoint.com/v2/url? >> > u=https-3A__techblog.bozho.net_why-2Dnon-2Dblocking_&d=DwIGaQ&c=Fge86U5Za1d7PUAcaTHoag0MToOH_fWpqWSEoP8Euxo&r=bhwpU3tY8LKDHlRyFCdvxI7HbJ1xsDcYiAovW3HVyCQ&m=UymdpIJhi9JlVdJ3Q5PXM4fmf04chnC2k_zmm_e3c34&s=KZYyvDyyRISY5wtEiFbldFeYvsJqkJCIxZ7STi6- >> fUE&e= >> >> [2] https://urldefense.proofpoint.com/v2/url? >> > u=https-3A__www.mail-2Darchive.com_users-40tomcat.apache.org_msg127134.html&d=DwIGaQ&c=Fge86U5Za1d7PUAcaTHoag0MToOH_fWpqWSEoP8Euxo&r=bhwpU3tY8LKDHlRyFCdvxI7HbJ1xsDcYiAovW3HVyCQ&m=UymdpIJhi9JlVdJ3Q5PXM4fmf04chnC2k_zmm_e3c34&s=EMp9cbtU1NzCax8ek6dFya1Q6JTvg4aMHqDzbrA0Tb4&e= >> >> [3] https://urldefense.proofpoint.com/v2/url? >> > u=http-3A__www.byteslounge.com_tutorials_asynchronous-2Dservlets-2Din-2Djava&d=DwIGaQ&c=Fge86U5Za1d7PUAcaTHoag0MToOH_fWpqWSEoP8Euxo&r=bhwpU3tY8LKDHlRyFCdvxI7HbJ1xsDcYiAovW3HVyCQ&m=UymdpIJhi9JlVdJ3Q5PXM4fmf04chnC2k_zmm_e3c34&s=pAFnD6Ifkg5N8refQEScIgY8n- >> hO30jsDMaGj2icKNo&e= >> >> >> >> On 8/22/2017 11:55 AM, Lukasz Lenart wrote: >> >>> 2017-08-21 19:03 GMT+02:00 Yasser Zamani <yasser.zam...@live.com>: >> >>>> @Lukasz, maybe I did not understand well but I studied and saw Struts >> >>>> already allows calling same action in same time in parallel. What > Struts >> >>>> does not have now is SERVER SIDE ASYNC REQUEST PROCESSING. My studies >> >>>> show async servlets don't mean client receives the response > immediately >> >>>> (async servlets do not make any sense in client point of view) but > they >> >>>> are all about server side. i.e. they back the thread immediately to >> >>>> thread pool and when processing finished, they pool a thread to send >> >>>> response to client (i.e. threadS-per-request). Did you mean such >> >>>> mechanism in action level? >> >>> >> >>> Yes, but it's a Servlet's mechanism not Struts' - I thought about >> >>> something similar to ExecAndWait result we have now or async servlets >> >>> in Servlet 3.0 >> >>> >> >>> >> >>> Regards >> >>> >> > > > This Email was scanned by Sophos Anti Virus >
