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://techblog.bozho.net/why-non-blocking/ [2] https://www.mail-archive.com/users@tomcat.apache.org/msg127134.html [3] http://www.byteslounge.com/tutorials/asynchronous-servlets-in-java 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 >
