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 <christoph.nenn...@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 <yasser.zam...@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.
