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) ? 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
