|
»
Best practice to run threads from processElement
|
View:
New views
8 Messages
—
Rating Filter:
Alert me
|
 |
Best practice to run threads from processElement
by Matthias Barmeier-2
::
Rate this Message:
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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "rife-users" group. To post to this group, send email to rife-users@... To unsubscribe from this group, send email to rife-users+unsubscribe@... For more options, visit this group at http://groups.google.com/group/rife-users?hl=en -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: Best practice to run threads from processElement
by Huibert Gill-2
::
Rate this Message:
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.barmeier@...>
--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "rife-users" group. To post to this group, send email to rife-users@... To unsubscribe from this group, send email to rife-users+unsubscribe@... For more options, visit this group at http://groups.google.com/group/rife-users?hl=en -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: Best practice to run threads from processElement
by Matthias Barmeier-2
::
Rate this Message:
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.barmeier@... > <mailto: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 > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "rife-users" group. To post to this group, send email to rife-users@... To unsubscribe from this group, send email to rife-users+unsubscribe@... For more options, visit this group at http://groups.google.com/group/rife-users?hl=en -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: Best practice to run threads from processElement
by Geert Bevin
::
Rate this Message:
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 On 29 May 2009, at 16:24, Matthias Barmeier wrote: > > 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.barmeier@... >> <mailto: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 >> >> >> >> >> >>> > > > -- 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "rife-users" group. To post to this group, send email to rife-users@... To unsubscribe from this group, send email to rife-users+unsubscribe@... For more options, visit this group at http://groups.google.com/group/rife-users?hl=en -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: Best practice to run threads from processElement
by Matthias Barmeier-2
::
Rate this Message:
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: > 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 > > > On 29 May 2009, at 16:24, Matthias Barmeier wrote: > > >> 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.barmeier@... >>> <mailto: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 >>> >>> >>> >>> >>> >>> > > -- > 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 > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "rife-users" group. To post to this group, send email to rife-users@... To unsubscribe from this group, send email to rife-users+unsubscribe@... For more options, visit this group at http://groups.google.com/group/rife-users?hl=en -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: Best practice to run threads from processElement
by Geert Bevin
::
Rate this Message:
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 ? -- 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "rife-users" group. To post to this group, send email to rife-users@... To unsubscribe from this group, send email to rife-users+unsubscribe@... For more options, visit this group at http://groups.google.com/group/rife-users?hl=en -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: Best practice to run threads from processElement
by Matthias Barmeier-2
::
Rate this Message:
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: > 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 ? >> > > -- > 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 > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "rife-users" group. To post to this group, send email to rife-users@... To unsubscribe from this group, send email to rife-users+unsubscribe@... For more options, visit this group at http://groups.google.com/group/rife-users?hl=en -~----------~----~----~----~------~----~------~--~--- |
|
|
Re: Best practice to run threads from processElement
by Geert Bevin
::
Rate this Message:
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/ On 01 Jun 2009, at 20:03, Matthias Barmeier wrote: > > 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: >> 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 ? >>> >> >> -- >> 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 >> >> >>> >> > > > -- 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "rife-users" group. To post to this group, send email to rife-users@... To unsubscribe from this group, send email to rife-users+unsubscribe@... For more options, visit this group at http://groups.google.com/group/rife-users?hl=en -~----------~----~----~----~------~----~------~--~--- |
| Free embeddable forum powered by Nabble | Forum Help |
