You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Massimo Lusetti <ml...@gmail.com> on 2010/05/06 12:05:57 UTC
Heavy and long background process
Hi all,
I need to process a big chunk on data uploaded from users. The whole
process takes up to 2-4 hours as involve a big change in the database.
I've implemented this as a series of Invokable from ParallelExecutor
and a "controller" service which hold a weak references to the client
responsible for the data submitted.
With a progresiveDisplay I keep the user informed of the progress of
the operation (and possibly of the errors involved), my reference is
kept in a cookie so users could still log out and come back later.
Now the Futures from my Invokables are within a MAP keyed to my
cookie-key and stored in the Service implementation.
May I ask if this solution sound reasonable to you?
I already know this doesn't fit very well in a clustered environment
but it's not a problem right now... perhaps within 6-8 months.
Thanks
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Heavy and long background process
Posted by Andreas Andreou <an...@di.uoa.gr>.
I've done similarly to how Kristian described with one small addition
- i had the
background thread check a cancel flag every once in a while so that
it's possible
to cancel it manually from the UI.
On Fri, May 7, 2010 at 11:25, Massimo Lusetti <ml...@gmail.com> wrote:
> On Fri, May 7, 2010 at 3:58 AM, Alex Kotchnev <ak...@gmail.com> wrote:
>
>> We've used Spring Batch quite a bit to handle situations like this. Lots of
>> good infrastructure that we didn't have to reinvent
>
> I really don't want to put more deps on the app that are not actually needed.
>
> My question was more about how to orchestrate the batch processing
> with the interactive GUI then how to do batch processing itself.
>
> Cheers
> --
> Massimo
> http://meridio.blogspot.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
Andreas Andreou - andyhot@apache.org - http://blog.andyhot.gr
Tapestry / Tacos developer
Open Source / JEE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Heavy and long background process
Posted by Massimo Lusetti <ml...@gmail.com>.
On Fri, May 7, 2010 at 3:58 AM, Alex Kotchnev <ak...@gmail.com> wrote:
> We've used Spring Batch quite a bit to handle situations like this. Lots of
> good infrastructure that we didn't have to reinvent
I really don't want to put more deps on the app that are not actually needed.
My question was more about how to orchestrate the batch processing
with the interactive GUI then how to do batch processing itself.
Cheers
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Heavy and long background process
Posted by Alex Kotchnev <ak...@gmail.com>.
We've used Spring Batch quite a bit to handle situations like this. Lots of
good infrastructure that we didn't have to reinvent
Regards,
Alex K
On Thu, May 6, 2010 at 6:16 AM, Kristian Marinkovic <
kristian.marinkovic@porsche.co.at> wrote:
> hi massimo,
>
> i had a similar problem a while back.
>
> i solved this problem by letting the long running thread
> log its current state and failures into a db table (you could
> also use a service and store it in memory). all the view
> needs to know is the job id to query the correct state and
> display it with an ajax updater.
>
> the downside is that it is not that simple anymore to cancel
> the thread manually... but this was needed in my case.
>
> i guess you should always decouple the view from a long
> running process anyways. especially in a web environment
> that is stateless by nature.
>
> g,
> kris
>
>
>
> Von: Massimo Lusetti <ml...@gmail.com>
> An: Tapestry users <us...@tapestry.apache.org>
> Datum: 06.05.2010 12:06
> Betreff: Heavy and long background process
>
>
>
> Hi all,
> I need to process a big chunk on data uploaded from users. The whole
> process takes up to 2-4 hours as involve a big change in the database.
>
> I've implemented this as a series of Invokable from ParallelExecutor
> and a "controller" service which hold a weak references to the client
> responsible for the data submitted.
>
> With a progresiveDisplay I keep the user informed of the progress of
> the operation (and possibly of the errors involved), my reference is
> kept in a cookie so users could still log out and come back later.
>
> Now the Futures from my Invokables are within a MAP keyed to my
> cookie-key and stored in the Service implementation.
>
> May I ask if this solution sound reasonable to you?
>
> I already know this doesn't fit very well in a clustered environment
> but it's not a problem right now... perhaps within 6-8 months.
>
> Thanks
> --
> Massimo
> http://meridio.blogspot.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
Re: Heavy and long background process
Posted by Kristian Marinkovic <kr...@porsche.co.at>.
hi massimo,
i had a similar problem a while back.
i solved this problem by letting the long running thread
log its current state and failures into a db table (you could
also use a service and store it in memory). all the view
needs to know is the job id to query the correct state and
display it with an ajax updater.
the downside is that it is not that simple anymore to cancel
the thread manually... but this was needed in my case.
i guess you should always decouple the view from a long
running process anyways. especially in a web environment
that is stateless by nature.
g,
kris
Von: Massimo Lusetti <ml...@gmail.com>
An: Tapestry users <us...@tapestry.apache.org>
Datum: 06.05.2010 12:06
Betreff: Heavy and long background process
Hi all,
I need to process a big chunk on data uploaded from users. The whole
process takes up to 2-4 hours as involve a big change in the database.
I've implemented this as a series of Invokable from ParallelExecutor
and a "controller" service which hold a weak references to the client
responsible for the data submitted.
With a progresiveDisplay I keep the user informed of the progress of
the operation (and possibly of the errors involved), my reference is
kept in a cookie so users could still log out and come back later.
Now the Futures from my Invokables are within a MAP keyed to my
cookie-key and stored in the Service implementation.
May I ask if this solution sound reasonable to you?
I already know this doesn't fit very well in a clustered environment
but it's not a problem right now... perhaps within 6-8 months.
Thanks
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: Heavy and long background process
Posted by Josh Canfield <jo...@gmail.com>.
> Hi all,
Hi,
> I need to process a big chunk on data uploaded from users. The whole
> process takes up to 2-4 hours as involve a big change in the database.
>
> I've implemented this as a series of Invokable from ParallelExecutor
> and a "controller" service which hold a weak references to the client
> responsible for the data submitted.
>
Lots of things to consider, especially if the operation needs to be
robust. For instance, are you only keeping the jobs in memory? Are you
worried about the system going down mid-operation?
> With a progresiveDisplay I keep the user informed of the progress of
> the operation (and possibly of the errors involved), my reference is
> kept in a cookie so users could still log out and come back later.
How important is it that this status is accessible? If your users
"MUST" have access to it then I wouldn't stick it in a cookie. Can you
stick the reference in the database? This also makes it so that the
user can pull up the progress from another computer, say on the bus on
the way home using their mobile device.
> Now the Futures from my Invokables are within a MAP keyed to my
> cookie-key and stored in the Service implementation.
What happens when the processing is done? How long are you keeping the
objects in the Map? If you restart the server all this information is
lost so depending on your requirements you might want to keep some
status info in the database.
> May I ask if this solution sound reasonable to you?
>
> I already know this doesn't fit very well in a clustered environment
> but it's not a problem right now... perhaps within 6-8 months.
>
> Thanks
> --
> Massimo
> http://meridio.blogspot.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
--
http://www.bodylabgym.com - a private, by appointment only, one-on-one
health and fitness facility.
--
http://www.ectransition.com - Quality Electronic Cigarettes at a
reasonable price!
--
TheDailyTube.com. Sign up and get the best new videos on the internet
delivered fresh to your inbox.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org