Hi,
> there is no gain (with current modern containers e.g. tomcat) the whole async topic seems to cycle around this issue :) > Overall I think it's not as simple as it appears and needs advanced > knowledge in http, servlets, filters and Strut's internals. Oh yes, think so too! I also think that all this complicated stuff is of no use to anyone. I'd rather have just a very thin wrapper around servlet api, like so: - actions might be declared async, this causes struts to call request.startAsync() - applications using that must use their own threads to do work (as with servlet api) - it should still be possible to use all struts results - we need some mechanism for the action to trigger result execution and cleanup of async context (result may run in application managed thread as well) This would mean there is not too much and not too complicated code in struts. Applications which would like to use servlet api async context could do so and still use struts concepts like interceptors, results or ognl. It is up to the application to gain something of async, as it is with servlet api. Regards, Christoph > From: Yasser Zamani <yasser.zam...@live.com> > To: "dev@struts.apache.org" <dev@struts.apache.org>, > Date: 08.10.2017 08:32 > Subject: Re: Support for actors/asynchronous request handling > > > > > > 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] 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=KgPxjmeVndyxKa_NFD9huA_6FZr2Wcoz43ZQ2LS0qq8&s=Wc2UOKbE8W0rHgz15Zk4VeqilB5RSR- > PvxV4knWE4bQ&e= > > > > > > > > > > > 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 > > > > This Email was scanned by proofpoint
