struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Nenning <Christoph.Nenn...@lex-com.net>
Subject Re: Support for actors/asynchronous request handling
Date Fri, 06 Oct 2017 09:40:24 GMT
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.zamani@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.zamani@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
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message