You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Lukasz Lenart <lu...@apache.org> on 2017/08/01 10:08:37 UTC
Re: Would we need to achieve better place in trends ranking?
2017-07-18 12:03 GMT+02:00 Yasser Zamani <ya...@live.com>:
> Are we, volunteers, allowed to help/contribute with such structural
> changes? I hope yes. If so, I have passion in `support for
> actors/asynchronous request handling`. Could you please register an
> issue with a few directive details? then we can pick and start work on
> that :) same ones for `less static util classes and coupled code` step
> by step. (`make JSON plugin more configurable` is simple to pick, while
> already has issues; `improve the framework's security` is also clear
> enough to being considered by us).
I do not have any directives how to implement actor/async support in
Struts2 - I thought about using http://jumi.fi/actors.html as it uses
Apache License and it's small & fast library. I wouldn't go with Akka
as this is a huge system by itself.
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Support for actors/asynchronous request handling
Posted by Yasser Zamani <ya...@live.com>.
On 10/9/2017 12:56 PM, Christoph Nenning wrote:
> 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.
Yes I see. However, it seems execAndWait interceptor already can do a
similar work. I think the lack of support is at result side and upload
side. I thought If I define three phases: upload, action and result, and
define S as short time and L as long time (spends process), then we have
8 states from SSS to LLL. For example:
LLL: a lot of users want to upload video and download converted one
SSL: a lot of users want to download specific files (download server)
SLS: seems execAndWait interceptor can handle this one
I even thought I can have 16 states by defining if result is dependent
to action or not :)
Moreover, maybe this is not as simple as it appears too, I guess. Struts
is a filter and user may use other filters before or after. To satisfy
servlet3, we should immediately release current thread back to container
when async action reached, so, what we should pass as result to back
interceptors and filters now? maybe null result and save original result
somewhere waiting for action back but we lose thread local attached data
:( and currently I'm not sure what happens when we execute a result in
separate empty thread!
If @dev agree I have an idea. For first step, what do you think to
level-up it to filter level (as it already is)? When I was playing I had
developed a modified filter below and saw it works! (except a few
special cases like when user has request scope spring bean). User can
put async actions in a specific namespace then map those to this filter
instead setting async-support to true. Below is some simple codes of
this filter (all params can be changed to get by a filter-param):
public class StrutsExecuteFilter {
public final int REQUEST_TIMEOUT = 240000;
private ExecutorService exe;
@Override
public void init(FilterConfig filterConfig) throws ServletException {
if(async-supported && async){
int size = 41;
exe = Executors.newFixedThreadPool(
size,
new ThreadFactory() {
public Thread newThread(Runnable r) {
return new Thread(r, "Struts Async Processor");
}
}
);
}
//Strut's current init codes
}
@Override
public void doFilter(final ServletRequest req, final
ServletResponse res, final FilterChain chain) throws IOException,
ServletException {
//Strut's current codes
if (mapping == null || recursionCounter > 1) {
boolean handled =
execute.executeStaticResourceRequest(request, response);
if (!handled) {
chain.doFilter(request, response);
}
} else {
//I ADDED THESE
final AsyncContext context = req.startAsync();
context.setTimeout(REQUEST_TIMEOUT);
context.addListener(new AsyncListener() {
public void onComplete(AsyncEvent asyncEvent) throws
IOException {
}
public void onTimeout(AsyncEvent asyncEvent) throws
IOException {
context
.getResponse()
.getWriter().write("Request Timeout");
}
public void onError(AsyncEvent asyncEvent) throws
IOException {
context
.getResponse()
.getWriter().write("Processing Error");
}
public void onStartAsync(AsyncEvent asyncEvent) throws
IOException {
}
});
exe.execute(new ContextExecution(context, mapping));
}
}
@Override
public void destroy() {
exe.shutdown();
//Strut's current destroy
}
class ContextExecution implements Runnable {
final AsyncContext context;
ActionMapping mapping;
public ContextExecution(AsyncContext context, ActionMapping
mapping) {
this.context = context;
this.mapping=mapping;
}
public void run() {
try {
execute.executeAction((HttpServletRequest)
context.getRequest(),
(HttpServletResponse) context.getResponse(),
mapping);
context.complete();
} catch (Exception e) {
e.printStackTrace();
}
}
}
}
:) I love it
Sincerely Yours,
Yasser.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Support for actors/asynchronous request handling
Posted by Yasser Zamani <ya...@live.com>.
On 10/23/2017 4:07 PM, Christoph Nenning wrote:
> YAY!
> Congrats :)
Thank you :) I became very excited when I saw it works. I would like to
say it works as you wished before. Do you remember you wished a
mechanism to wake up Struts for resuming? That is
AsyncContext.dispatch() which wakes up Strut's servlet to resume :)
> Would it be possible to have servlet-api 3 as optional dependency?
It seems a good idea! I'll try and I think it should be possible
theoretically. Thanks a lot, Christoph!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Support for actors/asynchronous request handling
Posted by Yasser Zamani <ya...@live.com>.
On 10/23/2017 4:07 PM, Christoph Nenning wrote:
> Would it be possible to have servlet-api 3 as optional dependency?
I tried but cannot work. Currently javac cannot union same classes in
same paths ;) Maven says I pick first found class (i.e. cannot pick
union of classes).
> I'm not so happy with reflection but it is ok to get it working initially.
With thanks to Łukasz, he pointed out a good thing, abstraction by a
plugin. I thought more and saw reflection maybe makes core somehow
rough-and-tumble. Now I'm going to go with a plugin named
struts-servlet3-plugin. I'll improve the core side-by-side when needed
but carefully I'll keep modularity. The positive point is in future we
are able to import further supports of Servlet3 into that plugin :)
Re: Support for actors/asynchronous request handling
Posted by Yasser Zamani <ya...@live.com>.
On 10/26/2017 12:09 PM, Yasser Zamani wrote:
> With thanks to Łukasz, he pointed out a good thing, abstraction by a
> plugin. I thought more and saw reflection maybe makes core somehow
> rough-and-tumble. Now I'm going to go with a plugin named
> struts-servlet3-plugin. I'll improve the core side-by-side when needed
> but carefully I'll keep modularity. The positive point is in future we
> are able to import further supports of Servlet3 into that plugin :)
With thanks to Strut's amazing design, I could add a partial support for
Servlet3's Async API, clean and with a few changes :) It's at [1]. It's
helpful for SLS (Short upload, Long action, Short result). Now, further
supports could be added to struts2-servlet3-plugin in future.
With special thanks to Łukasz and Christoph,
Yasser.
[1] https://github.com/apache/struts/pull/179
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Support for actors/asynchronous request handling
Posted by Christoph Nenning <Ch...@lex-com.net>.
> > I would add an abstraction to cover direct need for Servlet 3.0 Async
> > API. I don't know how do you want to implement this (directly in the
> > Core or via a plugin) but having such abstraction give us flexibility
> > and allows use different implementations.
>
> Today I successfully got an async result from my local branch of Struts
> :) In this branch I did not change and keep Servlet 2.4 dependency but
> created a wrapper which invokes Servlet 3's API via reflection. Works as
> WW-4874's description.
>
YAY!
Congrats :)
> That works but somehow is not awesome so I decided not pull requesting
> it now. I should do one thing before this. I discovered, currently,
> action invocation and result execution are hardly coupled in Struts. For
> example DefaultActionInvocation not only invokes action but also calls
> pre-result listeners and executes result!
>
> So, at first, I will be working on separating coupled action invocation
> and result execution while keeping same functionality as before.
>
+1
> Then, after merge of above as a PR, if I could have robust
> implementation (e.g. timeout and etc listeners) via reflection, then I
> will PR against core, else against plugins.
>
> wdyt?
>
I'm not so happy with reflection but it is ok to get it working initially.
Would it be possible to have servlet-api 3 as optional dependency?
Regards,
Christoph
This Email was scanned by proofpoint
Re: Support for actors/asynchronous request handling
Posted by Yasser Zamani <ya...@live.com>.
After some studies on Strut's internals, Servlet 3's spec, other
framework's internals and a few blog posts, I think I'm good to go for
SLS case (Short request processing, Long action execution, Short
response processing) :)
I putted this on monitor at [1].
[1] https://issues.apache.org/jira/browse/WW-4874
On 10/9/2017 12:56 PM, Christoph Nenning wrote:
> 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)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Support for actors/asynchronous request handling
Posted by Lukasz Lenart <lu...@apache.org>.
Nice :)
2017-10-18 13:26 GMT+02:00 Yasser Zamani <ya...@live.com>:
> Interestingly, I spotted a user request for this support at [1] :)
>
> [1]
> https://stackoverflow.com/questions/46808518/struts-send-response-from-asynccontext
>
> On 10/10/2017 1:23 PM, Yasser Zamani wrote:
>> If @dev agree I have an idea. For first step, what do you think to
>> level-up it to filter level (as it already is)? When I was playing I had
>> developed a modified filter below and saw it works! (except a few
>> special cases like when user has request scope spring bean). User can
>> put async actions in a specific namespace then map those to this filter
>> instead setting async-support to true. Below is some simple codes of
>> this filter (all params can be changed to get by a filter-param):
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Support for actors/asynchronous request handling
Posted by Yasser Zamani <ya...@live.com>.
Interestingly, I spotted a user request for this support at [1] :)
[1]
https://stackoverflow.com/questions/46808518/struts-send-response-from-asynccontext
On 10/10/2017 1:23 PM, Yasser Zamani wrote:
> If @dev agree I have an idea. For first step, what do you think to
> level-up it to filter level (as it already is)? When I was playing I had
> developed a modified filter below and saw it works! (except a few
> special cases like when user has request scope spring bean). User can
> put async actions in a specific namespace then map those to this filter
> instead setting async-support to true. Below is some simple codes of
> this filter (all params can be changed to get by a filter-param):
Re: Support for actors/asynchronous request handling
Posted by Yasser Zamani <ya...@live.com>.
On 10/23/2017 12:54 PM, Lukasz Lenart wrote:
> I would add an abstraction to cover direct need for Servlet 3.0 Async
> API. I don't know how do you want to implement this (directly in the
> Core or via a plugin) but having such abstraction give us flexibility
> and allows use different implementations.
Today I successfully got an async result from my local branch of Struts
:) In this branch I did not change and keep Servlet 2.4 dependency but
created a wrapper which invokes Servlet 3's API via reflection. Works as
WW-4874's description.
That works but somehow is not awesome so I decided not pull requesting
it now. I should do one thing before this. I discovered, currently,
action invocation and result execution are hardly coupled in Struts. For
example DefaultActionInvocation not only invokes action but also calls
pre-result listeners and executes result!
So, at first, I will be working on separating coupled action invocation
and result execution while keeping same functionality as before.
Then, after merge of above as a PR, if I could have robust
implementation (e.g. timeout and etc listeners) via reflection, then I
will PR against core, else against plugins.
wdyt?
With Best Regards,
Yasser.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Support for actors/asynchronous request handling
Posted by Lukasz Lenart <lu...@apache.org>.
2017-10-21 14:51 GMT+02:00 Yasser Zamani <ya...@live.com>:
> Just one blocking problem :( Currently Struts is on servlet-api 2.4. I
> remember Struts 2.6 will have servlet 2.5. And so so ... As I need
> servlet 3, I have to wait for Struts 3 ?! :/
>
> I thought about keep Struts dependencies unchanged and doing my needed
> calls via reflection which enables user to use async actions if
> underlying container supports.
>
> Any solution, objections or idea please?
I would add an abstraction to cover direct need for Servlet 3.0 Async
API. I don't know how do you want to implement this (directly in the
Core or via a plugin) but having such abstraction give us flexibility
and allows use different implementations.
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Support for actors/asynchronous request handling
Posted by Lukasz Lenart <lu...@apache.org>.
2017-10-22 10:08 GMT+02:00 info@flyingfischer.ch <in...@flyingfischer.ch>:
> Servlet API 3.0 is needs Java 6. As far as I remember Struts minimal
> requirements are also Java 6. I do not see anything hindering us in
> upgrading Struts officially to Servlet API 3.0?
This isn't a case with Java 7 but rather how many users are still
using Servlet containers running Servlet API 2.4 - switching to
Servlet API 3.0 requires not only migrate an app but the whole
container as well.
> Am I wrong? Would this need a considerable rework of Struts? If not, I
> feel we definitively should upgrade.
>
> Will Struts be able to cope with http2? Does it already or what needs to
> be adapted?
It's a container duty in this case, I don't think we need to worry too much.
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Support for actors/asynchronous request handling
Posted by Christoph Nenning <Ch...@lex-com.net>.
Hi,
According to wiki it was intended to switch to servlet-api 3 with struts
3:
https://cwiki.apache.org/confluence/display/WW/Struts+Next
But IMHO we could use servlet api 3 already for struts 2.6.
Regards,
Christoph
> > After some studies on Strut's internals, Servlet 3's spec, other
>
> > framework's internals and a few blog posts, I think I'm good to go for
>
> > SLS case (Short request processing, Long action execution, Short
>
> > response processing) :)
>
> >
>
> > I putted this on monitor at [1].
>
> >
>
> > [1] https://urldefense.proofpoint.com/v2/url?
>
u=https-3A__issues.apache.org_jira_browse_WW-2D4874&d=DwIGaQ&c=Fge86U5Za1d7PUAcaTHoag0MToOH_fWpqWSEoP8Euxo&r=bhwpU3tY8LKDHlRyFCdvxI7HbJ1xsDcYiAovW3HVyCQ&m=K3AcqGd_Nely2wsJK-
>
ujtMJOkPUtRPmz2FLPbfrFUVQ&s=3FkJEwzIKyXn7tA06-iBPJcci_a9Ea0IIhzbQOWuEH0&e=
>
>
>
> With thanks to Struts good design, fortunately, it was not as hard as I
>
> thought and I almost finished :)
>
>
>
> Just one blocking problem :( Currently Struts is on servlet-api 2.4. I
>
> remember Struts 2.6 will have servlet 2.5. And so so ... As I need
>
> servlet 3, I have to wait for Struts 3 ?! :/
>
>
>
> I thought about keep Struts dependencies unchanged and doing my needed
>
> calls via reflection which enables user to use async actions if
>
> underlying container supports.
>
>
>
> Any solution, objections or idea please?
>
>
This Email was scanned by proofpoint
Re: Support for actors/asynchronous request handling
Posted by "info@flyingfischer.ch" <in...@flyingfischer.ch>.
Am 21.10.2017 um 14:51 schrieb Yasser Zamani:
> With thanks to Struts good design, fortunately, it was not as hard as I
> thought and I almost finished :)
>
> Just one blocking problem :( Currently Struts is on servlet-api 2.4. I
> remember Struts 2.6 will have servlet 2.5. And so so ... As I need
> servlet 3, I have to wait for Struts 3 ?! :/
>
> I thought about keep Struts dependencies unchanged and doing my needed
> calls via reflection which enables user to use async actions if
> underlying container supports.
>
> Any solution, objections or idea please?
Servlet API 3.0 is needs Java 6. As far as I remember Struts minimal
requirements are also Java 6. I do not see anything hindering us in
upgrading Struts officially to Servlet API 3.0?
Am I wrong? Would this need a considerable rework of Struts? If not, I
feel we definitively should upgrade.
Will Struts be able to cope with http2? Does it already or what needs to
be adapted?
Markus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Support for actors/asynchronous request handling
Posted by Yasser Zamani <ya...@live.com>.
On 10/19/2017 4:12 PM, Yasser Zamani wrote:
> After some studies on Strut's internals, Servlet 3's spec, other
> framework's internals and a few blog posts, I think I'm good to go for
> SLS case (Short request processing, Long action execution, Short
> response processing) :)
>
> I putted this on monitor at [1].
>
> [1] https://issues.apache.org/jira/browse/WW-4874
With thanks to Struts good design, fortunately, it was not as hard as I
thought and I almost finished :)
Just one blocking problem :( Currently Struts is on servlet-api 2.4. I
remember Struts 2.6 will have servlet 2.5. And so so ... As I need
servlet 3, I have to wait for Struts 3 ?! :/
I thought about keep Struts dependencies unchanged and doing my needed
calls via reflection which enables user to use async actions if
underlying container supports.
Any solution, objections or idea please?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Support for actors/asynchronous request handling
Posted by Christoph Nenning <Ch...@lex-com.net>.
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 <ya...@live.com>
> To: "dev@struts.apache.org" <de...@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 <ya...@live.com>
>
> >> To: "dev@struts.apache.org" <de...@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 <ya...@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
Re: Support for actors/asynchronous request handling
Posted by Yasser Zamani <ya...@live.com>.
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 <ya...@live.com>
>> To: "dev@struts.apache.org" <de...@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 <ya...@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
>
Re: Support for actors/asynchronous request handling
Posted by Christoph Nenning <Ch...@lex-com.net>.
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 <ya...@live.com>
> To: "dev@struts.apache.org" <de...@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 <ya...@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
Re: Support for actors/asynchronous request handling
Posted by Yasser Zamani <ya...@live.com>.
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 <ya...@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
>
Re: Support for actors/asynchronous request handling
Posted by Lukasz Lenart <lu...@apache.org>.
2017-08-21 19:03 GMT+02:00 Yasser Zamani <ya...@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
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Support for actors/asynchronous request handling
Posted by Yasser Zamani <ya...@live.com>.
Hello guys, thanks all for your writings, these days I studied more and
please see below:
On 8/21/2017 12:26 PM, Lukasz Lenart wrote:
> 2017-08-18 10:19 GMT+02:00 Christoph Nenning <Ch...@lex-com.net>:
>> I think of it like async servlets. Execution of action could be delegated
>> to some executor thread pool and execution of result (which requires tcp
>> connection / http response stream) must be done with some callback.
>>
>> It is up to application to decide if they use async actions and which of
>> their actions shall be async. So if they have usecases like Dave described
>> (e.g. reading data from multiple backends) that would be candidates for
>> async actions.
>
> Jumi Actors sounds like a good way to get started with async.
>
> Later I could imagine to have integration with akka as struts already
has
> integration with big frameworks (spring). Also struts provides
integration
> with different frameworks for same task (e.g. tiles and sitemesh, ...).
>
> One step after another :)
@Christoph, good clue, I studied Servlet 3.0 and I'm going to try if I
can implement same mechanism in action level using akka.
I'm going to use akka as Lukasz suggested because Struts has also
internal computations (hidden from user point of view e.g. conversions,
interceptors, etc) which I'm going to try if I can extract computation
units could be executed in parallel. However, for now, I'm not sure if
it will be a great gain for Struts according to it's huge changes in
code and structure?! wdyt?
>
> I see it the same way, as an action level mechanism to allow
> parallelise execution of the same action.
>
@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?
>
> Regards
>
On 8/17/2017 7:32 PM, Dave Newton wrote:
> On Thu, Aug 17, 2017 at 10:44 AM, Yasser Zamani
<ya...@live.com> wrote:
>> Or if for example we can run interceptors in parallel.
>
> That would require developer knowledge since some interceptors are
strictly
> order-dependent. Not impossible, but would require explicit
configuration.
>
> The only real place I can see actors being helpful (without thinking hard
> about it) is once the request has hit an action and the action is
doing multiple
> things that would be easily parallelizable, e.g., if it's hitting a
> bunch of endpoints
> or doing mutually-exclusive DB lookups etc.
>
@Dave, thank you, I'm going to try it then I'll try for Struts internal
computations if I can do it in nice way.
> Running requests in parallel to actors is fine, but there are already
solutions
> for spreading requests over cores/processes.
>
As I said above, According to my studies, it seems we already have
parallel action execution. What we don't have in ASYNC PROCESSING to not
block http threads.
> Shoveling off stuff like logging/analytics etc. into actors is also
> fine, but I'm
> not sure we'd want to put that into Struts Proper, and don't we
already have
> a logging layer that would allow async logging? (I don't recall.)
>
We have an internal logging layer but should be removed to log4j2 all.
Fortunately I saw that log4j2 has async loggers if we would like to use?
> Dave
>
Thanks all in advance,
Sincerely Yours,
Yasser.
Re: Support for actors/asynchronous request handling
Posted by Lukasz Lenart <lu...@apache.org>.
2017-08-18 10:19 GMT+02:00 Christoph Nenning <Ch...@lex-com.net>:
> I think of it like async servlets. Execution of action could be delegated
> to some executor thread pool and execution of result (which requires tcp
> connection / http response stream) must be done with some callback.
>
> It is up to application to decide if they use async actions and which of
> their actions shall be async. So if they have usecases like Dave described
> (e.g. reading data from multiple backends) that would be candidates for
> async actions.
I see it the same way, as an action level mechanism to allow
parallelise execution of the same action.
Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Support for actors/asynchronous request handling
Posted by Christoph Nenning <Ch...@lex-com.net>.
>
> To find out why and how actor model can help Struts2, I searched a lot
> but just found following [1] at [2].
>
> I wonder if you @dev have anything in your mind about: Why and how actor
> model can help specifically Struts2 ? I don't mean in detail but if for
> example there is a general issue exists reported by users which reminds
> us the actor model. Or if for example we can run interceptors in
> parallel. Or if for example we need sticky sessions in Struts2 and so so
> any thought?.
>
> Thanks in advance!
> Yasser.
>
Hi,
I am not aware of specific issues or user requests.
I think of it like async servlets. Execution of action could be delegated
to some executor thread pool and execution of result (which requires tcp
connection / http response stream) must be done with some callback.
It is up to application to decide if they use async actions and which of
their actions shall be async. So if they have usecases like Dave described
(e.g. reading data from multiple backends) that would be candidates for
async actions.
Regards,
Christoph
This Email was scanned by Sophos Anti Virus
Re: Support for actors/asynchronous request handling
Posted by Dave Newton <da...@gmail.com>.
On Thu, Aug 17, 2017 at 10:44 AM, Yasser Zamani <ya...@live.com> wrote:
> Or if for example we can run interceptors in parallel.
That would require developer knowledge since some interceptors are strictly
order-dependent. Not impossible, but would require explicit configuration.
The only real place I can see actors being helpful (without thinking hard
about it) is once the request has hit an action and the action is doing multiple
things that would be easily parallelizable, e.g., if it's hitting a
bunch of endpoints
or doing mutually-exclusive DB lookups etc.
Running requests in parallel to actors is fine, but there are already solutions
for spreading requests over cores/processes.
Shoveling off stuff like logging/analytics etc. into actors is also
fine, but I'm
not sure we'd want to put that into Struts Proper, and don't we already have
a logging layer that would allow async logging? (I don't recall.)
Dave
--
e: davelnewton@gmail.com
m: 908-380-8699
s: davelnewton_skype
t: @dave_newton
b: Bucky Bits
g: davelnewton
so: Dave Newton
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Support for actors/asynchronous request handling
Posted by Yasser Zamani <ya...@live.com>.
To find out why and how actor model can help Struts2, I searched a lot
but just found following [1] at [2].
I wonder if you @dev have anything in your mind about: Why and how actor
model can help specifically Struts2 ? I don't mean in detail but if for
example there is a general issue exists reported by users which reminds
us the actor model. Or if for example we can run interceptors in
parallel. Or if for example we need sticky sessions in Struts2 and so so
any thought?.
Thanks in advance!
Yasser.
[1]
Stop me if you’ve heard this one. You just got off the phone with your
boss, who is getting frantic phone calls about your application throwing
errors all over the place, running extremely slowly, and in general
causing massive headaches. You check your pool of app servers, and find
that all of the threads are blocked on I/O. It’s 6am, and you haven’t
even fired up the coffee maker, and already existential dread is filling
your brain.
Java web app developers know all about this scenario— Java web
frameworks have, historically, been extremely poor at concurrency. The
number one cry of Struts or JSF developers is “just turn on sticky
sessions”, and then only a percentage of your users will get hosed when
things start going wrong at the controller level. Want to write a
controller that connects to a third-party REST service which happens to
reject a connection from time to time? Beati pauperes spiritu.
Want to asynchronously log some action to a database? Send a message to
Akka and forget about it. Want to fail gracefully when that REST service
refuses your connection? Have your Akka actor schedule the original
message to be placed back into the mailbox, and you’re done. Want to
share sessions between application servers? Ask an Akka actor to
retrieve a key from a cache, and you’re done. Want to recreate the
Quartz functionality of JBoss? Schedule an Akka actor to run every so
often with one line of code. Want to resize an image as a background
task? Send an Akka actor a message containing the bytes of the image,
return a Future containing the bytes of the resized image, and you’re done.
[2]
https://medium.com/21st-century-web-application-development/akka-the-most-important-middleware-youve-never-heard-of-dc19e386026d
On 8/1/2017 2:38 PM, Lukasz Lenart wrote:
> I do not have any directives how to implement actor/async support in
> Struts2 - I thought about using http://jumi.fi/actors.html as it uses
> Apache License and it's small & fast library. I wouldn't go with Akka
> as this is a huge system by itself.
Re: Would we need to achieve better place in trends ranking?
Posted by Christoph Nenning <Ch...@lex-com.net>.
> > Are we, volunteers, allowed to help/contribute with such structural
> > changes? I hope yes. If so, I have passion in `support for
> > actors/asynchronous request handling`. Could you please register an
> > issue with a few directive details? then we can pick and start work on
> > that :) same ones for `less static util classes and coupled code` step
> > by step. (`make JSON plugin more configurable` is simple to pick,
while
> > already has issues; `improve the framework's security` is also clear
> > enough to being considered by us).
>
> I do not have any directives how to implement actor/async support in
> Struts2 - I thought about using http://jumi.fi/actors.html as it uses
> Apache License and it's small & fast library. I wouldn't go with Akka
> as this is a huge system by itself.
>
>
Jumi Actors sounds like a good way to get started with async.
Later I could imagine to have integration with akka as struts already has
integration with big frameworks (spring). Also struts provides integration
with different frameworks for same task (e.g. tiles and sitemesh, ...).
One step after another :)
Regards,
Christoph
This Email was scanned by Sophos Anti Virus