struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yasser Zamani <yasser.zam...@live.com>
Subject Re: Support for actors/asynchronous request handling
Date Sun, 08 Oct 2017 06:31:47 GMT


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] http://www.byteslounge.com/tutorials/asynchronous-servlets-in-java

> 
> 
> 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
View raw message