Best practice to run threads from processElement

[Matthias Barmeier]

Hi out there,

I wonder if there is a best practice available to solve the following
problem:

I want to initiate several background tasks that tars a huge file set
200GB+. This takes a while and I would like to move this processing in a
thread, triggered from a submission handler. The thread/s will run for
several hours and they should report a progress that another Element
should render.

My "naive" approach would be:

Start the thread from the submission handler and write something to
disk/database to store the state. The Element that renders the state of
the threads reads the states from the disk and renders the progress.

Drawbacks: loosing the thread handle, synchronization problems.

Is there something to make it better/more stable/ more rife ?

Ciao
Matthias

[Huibert Gill]

Look into to Rife participants and create a simple one.
Use it to create, start and monitor you threads from there.
Should be pretty easy.

Also using the participant, your threads could use callbacks to the participant to report progress.

Your element can then safly read teh reported statuses.


happy hacking!

Huibert Gill

2009/5/29 Matthias Barmeier <matthias...@sourcepark.de>

[Matthias Barmeier]

Hi,

OK sounds cool. I will try it over the holidays.

Thanx.

Ciao
Matthias

Huibert Gill schrieb:

> Look into to Rife participants and create a simple one.
> Use it to create, start and monitor you threads from there.
> Should be pretty easy.
>
> Also using the participant, your threads could use callbacks to the
> participant to report progress.
>
> Your element can then safly read teh reported statuses.
>
>
> happy hacking!
>
> Huibert Gill
>
> 2009/5/29 Matthias Barmeier <matthias...@sourcepark.de

> <mailto:matthias...@sourcepark.de>>

[Geert Bevin]

You can use participants, or regular threads as inner classes. Drone
is using something like that when reindexing through the admin
interface:
http://svn.rifers.org/drone/trunk/src/implementations/com/uwyn/drone/webui/elements/admin/ReindexSearch.java

--
Geert Bevin
Terracotta - http://www.terracotta.org
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Flytecase Band - http://flytecase.be
Music and words - http://gbevin.com

[Matthias Barmeier]

Hi Geert,

I need a dispatcher thread that collects packaging orders and than
starts for everey order a packing thread.
The Queue/Processing skeleton is already implemented. Though, I think I
will give a try for the participant or do you think that this
have some disadvantages that your approach does not have ?

Ciao
Matze

Geert Bevin schrieb:

[Geert Bevin]

Hi Matze,

Participants give you an application-wide thread that you can easily
access from a single repository. For there rest, there are other
advantages, like exposing results and waiting for objects from other
participants to create a kind of automating dependency management, but
I don't think this would benefit you.

I don't think I'd use participants for your use case.

HTH,

Geert

On 29 May 2009, at 16:48, Matthias Barmeier wrote:

>
> Hi Geert,
>
> I need a dispatcher thread that collects packaging orders and than
> starts for everey order a packing thread.
> The Queue/Processing skeleton is already implemented. Though, I
> think I
> will give a try for the participant or do you think that this
> have some disadvantages that your approach does not have ?

--

[Matthias Barmeier]

Hi Geert,

Maybe I should implement one just for exercising rife ;).

Are there any docs available on how to implement and use participants ?

Ciao
Matze

Geert Bevin schrieb:

[Geert Bevin]

I think the users guide has some examples and you'll definitely find
some in the open-source projects that are built on top of RIFE, like
Drone:
http://svn.rifers.org/