struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yasser Zamani <>
Subject Re: Support for actors/asynchronous request handling
Date Wed, 04 Oct 2017 09:09:11 GMT
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 
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,


On 8/22/2017 11:55 AM, Lukasz Lenart wrote:
> 2017-08-21 19:03 GMT+02:00 Yasser Zamani <>:
>> @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
View raw message