Would we need to achieve better place in trends ranking?

classic Classic list List threaded Threaded
43 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Would we need to achieve better place in trends ranking?

Yasser Zamani
Hi there,

This is a 2016 trend of Web Framework Usages from [1].
java-web-frameworks-usage-trends

I would like to know if we need an analysis of why S2 is number 4 in
ranking? If so, then we can plan for enhancements and new features to
achieve better place in ranking, right? What's your idea please?

Thanks in advance!

[1]: Java Tools and Technologies Landscape Report 2016: Trends and
Historical data
https://zeroturnaround.com/rebellabs/java-tools-and-technologies-landscape-2016-trends/ 


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Would we need to achieve better place in trends ranking?

Lukasz Lenart
2017-07-15 15:55 GMT+02:00 Yasser Zamani <[hidden email]>:
> Hi there,
>
> This is a 2016 trend of Web Framework Usages from [1].
> java-web-frameworks-usage-trends
>
> I would like to know if we need an analysis of why S2 is number 4 in
> ranking? If so, then we can plan for enhancements and new features to
> achieve better place in ranking, right? What's your idea please?

From my point of view, Spring MVC is mostly used to create a JSON API
to be used with Single Page Apps, i.e. Angular - the most (over?)used
approach to create web apps these days. If you want to use Struts to
do the same you are getting a lot of overhead (support for JSPs,
Freemarker, EL, etc) bundled into a one jar.

Also Struts still isn't so well structured as Spring (but I'm working
hard on that ;-) and isn't supported by a company that makes money on
it ;-)

Anyway, I don't think we can compete with Spring, we should focus on
what should be done and fixed - that's all. I'm also curious how hard
is to migrate between each major release of Spring?


Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Would we need to achieve better place in trends ranking?

Yasser Zamani
Thank you very much!

I have no experience with Spring MVC and JSF so far. So unfortunately I
do not know about it's major release migrations. I also have no idea why
it is in more usage :/

Absolutely, I did not mean you yourself should do or did something :) I
just asked these to know if me/we, contributors, should just wait for
user's demands in jira. or no, it's needed to analysis, study and discus
competitors here, for new applicable (not all) features or improvements
in Struts (e.g. you informed me that JSON and Angular are reasons so I
can study them if any applicable feature could be added to S2).

Sincerely Yours,
Yasser.

On 7/17/2017 11:42 AM, Lukasz Lenart wrote:

> 2017-07-15 15:55 GMT+02:00 Yasser Zamani <[hidden email]>:
>> Hi there,
>>
>> This is a 2016 trend of Web Framework Usages from [1].
>> java-web-frameworks-usage-trends
>>
>> I would like to know if we need an analysis of why S2 is number 4 in
>> ranking? If so, then we can plan for enhancements and new features to
>> achieve better place in ranking, right? What's your idea please?
>
> From my point of view, Spring MVC is mostly used to create a JSON API
> to be used with Single Page Apps, i.e. Angular - the most (over?)used
> approach to create web apps these days. If you want to use Struts to
> do the same you are getting a lot of overhead (support for JSPs,
> Freemarker, EL, etc) bundled into a one jar.
>
> Also Struts still isn't so well structured as Spring (but I'm working
> hard on that ;-) and isn't supported by a company that makes money on
> it ;-)
>
> Anyway, I don't think we can compete with Spring, we should focus on
> what should be done and fixed - that's all. I'm also curious how hard
> is to migrate between each major release of Spring?
>
>
> Regards
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Would we need to achieve better place in trends ranking?

Lukasz Lenart
2017-07-17 10:49 GMT+02:00 Yasser Zamani <[hidden email]>:
> Absolutely, I did not mean you yourself should do or did something :) I
> just asked these to know if me/we, contributors, should just wait for
> user's demands in jira. or no, it's needed to analysis, study and discus
> competitors here, for new applicable (not all) features or improvements
> in Struts (e.g. you informed me that JSON and Angular are reasons so I
> can study them if any applicable feature could be added to S2).

No, we should definitely not sit and wait :) Rather figure out what
should be improved and what new features would be nice to have - and
then code and implement them :)

My two new features on the radar:
- make JSON plugin more configurable, there are few issues related to it [1]
- add support for actors/asynchronous request handling

Besides these, my main goal is to improve the framework's security and
flexibility (less static util classes and coupled code).

[1] https://issues.apache.org/jira/issues/?jql=component%20%3D%20%22Plugin%20-%20JSON%22%20AND%20project%20%3D%20WW%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC


Regards
--
Łukasz
+ 48 606 323 122 http://www.lenart.org.pl/

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Would we need to achieve better place in trends ranking?

Yasser Zamani
Great! Happy that I know these now!

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).

Ton of thanks for your time and writing for us!

On 7/18/2017 10:37 AM, Lukasz Lenart wrote:

> 2017-07-17 10:49 GMT+02:00 Yasser Zamani <[hidden email]>:
>> Absolutely, I did not mean you yourself should do or did something :) I
>> just asked these to know if me/we, contributors, should just wait for
>> user's demands in jira. or no, it's needed to analysis, study and discus
>> competitors here, for new applicable (not all) features or improvements
>> in Struts (e.g. you informed me that JSON and Angular are reasons so I
>> can study them if any applicable feature could be added to S2).
>
> No, we should definitely not sit and wait :) Rather figure out what
> should be improved and what new features would be nice to have - and
> then code and implement them :)
>
> My two new features on the radar:
> - make JSON plugin more configurable, there are few issues related to it [1]
> - add support for actors/asynchronous request handling
>
> Besides these, my main goal is to improve the framework's security and
> flexibility (less static util classes and coupled code).
>
> [1] https://issues.apache.org/jira/issues/?jql=component%20%3D%20%22Plugin%20-%20JSON%22%20AND%20project%20%3D%20WW%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC
>
>
> Regards
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Would we need to achieve better place in trends ranking?

Ken McWilliams
Lukasz it's good to hear the JSON plugin is on the horizon. For my own work
I created a new JSON Result type using FlexJson, for some reason I liked it
better when serializing JPA Entities, it will by default serialize
primitive types on the object but will not travel the graph unless you
explicitly tell it the collections to traverse. Because it was the business
of the action to fetch what was needed (so it knew what needed to be
returned) there was no issue specifying these strings. Each action had an
instance of the JSON Serializer, along with a getter for it. After setting
it the way I wanted, the result just fetched the configured instance from
the action it self. It didn't have any pretty annotations or anything but
it was mindlessly simple to configure and using the object that performed
the Json serialization directly was very convenient.

Yasser get the code and start making changes... no harm in doing that. I've
never seen anything but reasonableness from the struts developers if they
like the change and it won't break things for others I'm sure they'll be
happy to have more people on team struts.

MORE LESS OFF TOPIC
Regarding keeping up with the competition: I've started a project with
Spark framework [sparkjava.com]. It is a pretty cool framework. Struts and
Spring and many others are in a certain vein, this thing feels a lot more
like development in Python, PHP, having a functional/imperative programming
feel rather than an OO one... It is pretty refreshing to hardly be required
to create any objects. My motivation was to use Dagger2 for DI, which does
not work well with JEE (in a container environment). Dagger2 needs to be
able to travel the whole graph so it can't tolerate any "magic", other
systems performing DI/reflective magic or even using external
configuration, like an xml file to determine what to instantiate, so that
eliminates a lot of web frameworks. It could still be made to work, but it
would have to start over at each point it couldn't trace, and _you_ would
have to identify those points and work around that. All in all, not very
practical.

Any ways this thing is very different from the Java frameworks I've seen,
it's really simple, it really seems like what is going on in a lot of other
languages. Really at this point I don't know what it could bring to
struts2... like adding a whole functional API to struts would probably be
too radical.




On Tue, Jul 18, 2017 at 4:03 AM, Yasser Zamani <[hidden email]>
wrote:

> Great! Happy that I know these now!
>
> 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).
>
> Ton of thanks for your time and writing for us!
>
> On 7/18/2017 10:37 AM, Lukasz Lenart wrote:
> > 2017-07-17 10:49 GMT+02:00 Yasser Zamani <[hidden email]>:
> >> Absolutely, I did not mean you yourself should do or did something :) I
> >> just asked these to know if me/we, contributors, should just wait for
> >> user's demands in jira. or no, it's needed to analysis, study and discus
> >> competitors here, for new applicable (not all) features or improvements
> >> in Struts (e.g. you informed me that JSON and Angular are reasons so I
> >> can study them if any applicable feature could be added to S2).
> >
> > No, we should definitely not sit and wait :) Rather figure out what
> > should be improved and what new features would be nice to have - and
> > then code and implement them :)
> >
> > My two new features on the radar:
> > - make JSON plugin more configurable, there are few issues related to it
> [1]
> > - add support for actors/asynchronous request handling
> >
> > Besides these, my main goal is to improve the framework's security and
> > flexibility (less static util classes and coupled code).
> >
> > [1] <a href="https://issues.apache.org/jira/issues/?jql=component%20%">https://issues.apache.org/jira/issues/?jql=component%20%
> 3D%20%22Plugin%20-%20JSON%22%20AND%20project%20%3D%20WW%
> 20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC
> >
> >
> > Regards
> >
>



--
Sent from my C64 using a 300 baud modem
Reply | Threaded
Open this post in threaded view
|

Re: Would we need to achieve better place in trends ranking?

Yasser Zamani
Thanks a lot for your share of experience (I have read it several times
these days).

As I understand, you mention sparkjava because of it's DI (Dagger2),
right? To understand deeper, I'll study them as soon as I had time to
understand `what make the difference` and if Struts has a chance to
being improved.

I also do same for FlexJson.

However, as I understand, like Lukasz, you also believe we have not much
chance for the competition, but I think Struts will have it's users
because of it's simple to use while powerful enough. wdyt?

On 7/19/2017 5:55 AM, Ken McWilliams wrote:

> Lukasz it's good to hear the JSON plugin is on the horizon. For my own work
> I created a new JSON Result type using FlexJson, for some reason I liked it
> better when serializing JPA Entities, it will by default serialize
> primitive types on the object but will not travel the graph unless you
> explicitly tell it the collections to traverse. Because it was the business
> of the action to fetch what was needed (so it knew what needed to be
> returned) there was no issue specifying these strings. Each action had an
> instance of the JSON Serializer, along with a getter for it. After setting
> it the way I wanted, the result just fetched the configured instance from
> the action it self. It didn't have any pretty annotations or anything but
> it was mindlessly simple to configure and using the object that performed
> the Json serialization directly was very convenient.
>
> Yasser get the code and start making changes... no harm in doing that. I've
> never seen anything but reasonableness from the struts developers if they
> like the change and it won't break things for others I'm sure they'll be
> happy to have more people on team struts.
>
> MORE LESS OFF TOPIC
> Regarding keeping up with the competition: I've started a project with
> Spark framework [sparkjava.com]. It is a pretty cool framework. Struts and
> Spring and many others are in a certain vein, this thing feels a lot more
> like development in Python, PHP, having a functional/imperative programming
> feel rather than an OO one... It is pretty refreshing to hardly be required
> to create any objects. My motivation was to use Dagger2 for DI, which does
> not work well with JEE (in a container environment). Dagger2 needs to be
> able to travel the whole graph so it can't tolerate any "magic", other
> systems performing DI/reflective magic or even using external
> configuration, like an xml file to determine what to instantiate, so that
> eliminates a lot of web frameworks. It could still be made to work, but it
> would have to start over at each point it couldn't trace, and _you_ would
> have to identify those points and work around that. All in all, not very
> practical.
>
> Any ways this thing is very different from the Java frameworks I've seen,
> it's really simple, it really seems like what is going on in a lot of other
> languages. Really at this point I don't know what it could bring to
> struts2... like adding a whole functional API to struts would probably be
> too radical.
>
>
>
>
> On Tue, Jul 18, 2017 at 4:03 AM, Yasser Zamani <[hidden email]>
> wrote:
>
>> Great! Happy that I know these now!
>>
>> 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).
>>
>> Ton of thanks for your time and writing for us!
>>
>> On 7/18/2017 10:37 AM, Lukasz Lenart wrote:
>>> 2017-07-17 10:49 GMT+02:00 Yasser Zamani <[hidden email]>:
>>>> Absolutely, I did not mean you yourself should do or did something :) I
>>>> just asked these to know if me/we, contributors, should just wait for
>>>> user's demands in jira. or no, it's needed to analysis, study and discus
>>>> competitors here, for new applicable (not all) features or improvements
>>>> in Struts (e.g. you informed me that JSON and Angular are reasons so I
>>>> can study them if any applicable feature could be added to S2).
>>>
>>> No, we should definitely not sit and wait :) Rather figure out what
>>> should be improved and what new features would be nice to have - and
>>> then code and implement them :)
>>>
>>> My two new features on the radar:
>>> - make JSON plugin more configurable, there are few issues related to it
>> [1]
>>> - add support for actors/asynchronous request handling
>>>
>>> Besides these, my main goal is to improve the framework's security and
>>> flexibility (less static util classes and coupled code).
>>>
>>> [1] <a href="https://issues.apache.org/jira/issues/?jql=component%20%">https://issues.apache.org/jira/issues/?jql=component%20%
>> 3D%20%22Plugin%20-%20JSON%22%20AND%20project%20%3D%20WW%
>> 20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC
>>>
>>>
>>> Regards
>>>
>>
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Would we need to achieve better place in trends ranking?

Lukasz Lenart
In reply to this post by Yasser Zamani
2017-07-18 12:03 GMT+02:00 Yasser Zamani <[hidden email]>:
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Would we need to achieve better place in trends ranking?

Christoph Nenning
> > 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
Reply | Threaded
Open this post in threaded view
|

Support for actors/asynchronous request handling

Yasser Zamani
In reply to this post by Lukasz Lenart
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.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Support for actors/asynchronous request handling

Dave Newton-6
On Thu, Aug 17, 2017 at 10:44 AM, Yasser Zamani <[hidden email]> 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: [hidden email]
m: 908-380-8699
s: davelnewton_skype
t: @dave_newton
b: Bucky Bits
g: davelnewton
so: Dave Newton

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Support for actors/asynchronous request handling

Christoph Nenning
In reply to this post by Yasser Zamani
>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Support for actors/asynchronous request handling

Lukasz Lenart
2017-08-18 10:19 GMT+02:00 Christoph Nenning <[hidden email]>:
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Support for actors/asynchronous request handling

Yasser Zamani
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 <[hidden email]>:
>> 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
<[hidden email]> 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.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Support for actors/asynchronous request handling

Lukasz Lenart
2017-08-21 19:03 GMT+02:00 Yasser Zamani <[hidden email]>:
> @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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Support for actors/asynchronous request handling

Yasser Zamani
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@.../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 <[hidden email]>:
>> @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
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Support for actors/asynchronous request handling

Christoph Nenning
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 <[hidden email]>
> To: "[hidden email]" <[hidden email]>,
> 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 <[hidden email]>:
>
> >> @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
Reply | Threaded
Open this post in threaded view
|

Re: Support for actors/asynchronous request handling

Yasser Zamani


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 <[hidden email]>
>> To: "[hidden email]" <[hidden email]>,
>> 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 <[hidden email]>:
>>
>>>> @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
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Support for actors/asynchronous request handling

Christoph Nenning
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 <[hidden email]>
> To: "[hidden email]" <[hidden email]>,
> 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 <[hidden email]>
>
> >> To: "[hidden email]" <[hidden email]>,
>
> >> 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 <[hidden email]>:
>
> >>
>
> >>>> @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
Reply | Threaded
Open this post in threaded view
|

Re: Support for actors/asynchronous request handling

Yasser Zamani


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: [hidden email]
For additional commands, e-mail: [hidden email]

123