GPARS in the web service tier

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

GPARS in the web service tier

Jeff Gortatowsky
Well I did it. But I am not yet sure it's right. Not by a long shot. I need to run some pretty heavy integration / load testing to convince myself all my database reads are isolated in each actor and that it's all threadsafe. Which I have not done yet. I did put in sleep() delays to convince myself that all were in parallel. They were as the total time was the longest sleep delay.

As I wrote earlier I am not even sure actors were the right implementation as my actors single use stateful actors (I made them so). So for each client call the normal grails thread /service instantiates 4 actors, each with a specific task and a specific instance of a domain object. I then tell all four to hit the DB and fulfill their part in reading their assigned domain object. I then join on all four, read the results, and send that back via CXF. It all seems to work. But I can't help but wonder if actors were the right paradigm.

Looks like:
service() {
        def userActor = new FindUserActor()
        def entitlementActor = new FindUserEntitlementsActor()
        def expirationActor = new FindUserExpirationInfoActor()
        def questionnaireInfoActor = new FindUserQuestionnaireInfoActor()
        def actors = [userActor, entitlementActor, expirationActor, questionnaireInfoActor]
        actors*.start()
        actors*.send(userid)
        actors*.join()
        return new UserPricingInfoDto(user: userActor.user,
                userEntitlementDto: new UserEntitlementDto(list: entitlementActor.finalList),
                userExpirationInfo: expirationActor.userExpirationInfo,
                userQuestionnaireInfo: questionnaireInfoActor.questionnaireInfo)
}

Interesting, each gets it's own hibernate session (ThreadLocal). I only do reads. :)

I have to admit threading can give one a headache, but GPARS if it is being used right, could change my mind. :D


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: GPARS in the web service tier

Jeff Gortatowsky
I neglected to mention the actors are not using loop but are using react

--------------------
Sent from someone elses iPhone.  Go figure.  
Jeff

On Dec 22, 2009, at 5:41 PM, Jeff Gortatowsky <[hidden email]> wrote:

Well I did it. But I am not yet sure it's right. Not by a long shot. I need to run some pretty heavy integration / load testing to convince myself all my database reads are isolated in each actor and that it's all threadsafe. Which I have not done yet. I did put in sleep() delays to convince myself that all were in parallel. They were as the total time was the longest sleep delay.

As I wrote earlier I am not even sure actors were the right implementation as my actors single use stateful actors (I made them so). So for each client call the normal grails thread /service instantiates 4 actors, each with a specific task and a specific instance of a domain object. I then tell all four to hit the DB and fulfill their part in reading their assigned domain object. I then join on all four, read the results, and send that back via CXF. It all seems to work. But I can't help but wonder if actors were the right paradigm.

Looks like:
service() {
       def userActor = new FindUserActor()
       def entitlementActor = new FindUserEntitlementsActor()
       def expirationActor = new FindUserExpirationInfoActor()
       def questionnaireInfoActor = new FindUserQuestionnaireInfoActor()
       def actors = [userActor, entitlementActor, expirationActor, questionnaireInfoActor]
       actors*.start()
       actors*.send(userid)
       actors*.join()
       return new UserPricingInfoDto(user: userActor.user,
               userEntitlementDto: new UserEntitlementDto(list: entitlementActor.finalList),
               userExpirationInfo: expirationActor.userExpirationInfo,
               userQuestionnaireInfo: questionnaireInfoActor.questionnaireInfo)
}

Interesting, each gets it's own hibernate session (ThreadLocal). I only do reads. :)

I have to admit threading can give one a headache, but GPARS if it is being used right, could change my mind. :D


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: GPARS in the web service tier

Vaclav
Administrator
Hi Jeff,

this is a very interesting example and in my opinion a valid use case for GPars. Using actors here looks quite natural to me and is a good choice.
Since each of your actors consumes just one message and then exits, you might also consider using Parallelizer instead:

service() {
    Parallelizer.doParallel(4) {
        def results = [
            new FindUserCommand(),
            new FindUserEntitlementsCommand(),
            new FindUserExpirationInfoCommand(),
            new FindUserQuestionnaireInfoCommand()
        ].collectParallel{it.call userid}

       return new UserPricingInfoDto(user: results[0],
               userEntitlementDto: new UserEntitlementDto(list: results[1]),
               userExpirationInfo: results[2],
               userQuestionnaireInfo: results[3])
    }
}

Cheers,

Vaclav


On Wed, Dec 23, 2009 at 5:27 AM, Jeff Gortatowsky <[hidden email]> wrote:
I neglected to mention the actors are not using loop but are using react

--------------------
Sent from someone elses iPhone.  Go figure.
Jeff

On Dec 22, 2009, at 5:41 PM, Jeff Gortatowsky <[hidden email]> wrote:

Well I did it. But I am not yet sure it's right. Not by a long shot. I need to run some pretty heavy integration / load testing to convince myself all my database reads are isolated in each actor and that it's all threadsafe. Which I have not done yet. I did put in sleep() delays to convince myself that all were in parallel. They were as the total time was the longest sleep delay.

As I wrote earlier I am not even sure actors were the right implementation as my actors single use stateful actors (I made them so). So for each client call the normal grails thread /service instantiates 4 actors, each with a specific task and a specific instance of a domain object. I then tell all four to hit the DB and fulfill their part in reading their assigned domain object. I then join on all four, read the results, and send that back via CXF. It all seems to work. But I can't help but wonder if actors were the right paradigm.

Looks like:
service() {
      def userActor = new FindUserActor()
      def entitlementActor = new FindUserEntitlementsActor()
      def expirationActor = new FindUserExpirationInfoActor()
      def questionnaireInfoActor = new FindUserQuestionnaireInfoActor()
      def actors = [userActor, entitlementActor, expirationActor, questionnaireInfoActor]
      actors*.start()
      actors*.send(userid)
      actors*.join()
      return new UserPricingInfoDto(user: userActor.user,
              userEntitlementDto: new UserEntitlementDto(list: entitlementActor.finalList),
              userExpirationInfo: expirationActor.userExpirationInfo,
              userQuestionnaireInfo: questionnaireInfoActor.questionnaireInfo)
}

Interesting, each gets it's own hibernate session (ThreadLocal). I only do reads. :)

I have to admit threading can give one a headache, but GPARS if it is being used right, could change my mind. :D


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





--
E-mail: [hidden email]
Blog: http://www.jroller.com/vaclav
Linkedin page: http://www.linkedin.com/in/vaclavpech
Reply | Threaded
Open this post in threaded view
|

Re: GPARS in the web service tier

Russel Winder-2
On Wed, 2009-12-23 at 09:06 +0100, Vaclav Pech wrote:
>
> this is a very interesting example and in my opinion a valid use case
> for GPars. Using actors here looks quite natural to me and is a good
> choice.
> Since each of your actors consumes just one message and then exits,
> you might also consider using Parallelizer instead:
>
I think there is a general issue here in terms of mapping the algorithms
of solutions to problems to the right tools from the library.  I think
Actors have been to emphasized recently throughout the field.  Data
parallelism and asynchronous function call with futures are tools that
people are not being made aware of enough.

I think we need to make use of all these examples people are coming up
with in order to make a taxonomy that can provide idioms of solution for
people.

So in the new year, I propose we take examples like the Sleeping Barber
(and as many others as we can) and systematically create solutions using
all the different tools and write short commentaries -- we need to avoid
bias but not be averse to adverse criticism.


--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: [hidden email]
Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,   f: +44 8700 516 084   voip: sip:[hidden email]
London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder

signature.asc (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GPARS in the web service tier

Vaclav
Administrator
Hi Russel,

what you're proposing  makes a lot of sense (as usual). Actors are just one way to do concurrency and for many problems not necessarily the most intuitive and straightforward one. While Scala or perhaps Erlang concurrency story is all about actors, Clojure on the other hand doesn't include actors at all.

I agree, we need to propagate the various concepts that live under the GPars roof and on examples show the typical use cases of each them.
I've created a dedicated JIRA - http://jira.codehaus.org/browse/GPARS-63 which is now looking for volunteers.

Regards,

Vaclav




On Wed, Dec 23, 2009 at 9:33 AM, Russel Winder <[hidden email]> wrote:
On Wed, 2009-12-23 at 09:06 +0100, Vaclav Pech wrote:
>
> this is a very interesting example and in my opinion a valid use case
> for GPars. Using actors here looks quite natural to me and is a good
> choice.
> Since each of your actors consumes just one message and then exits,
> you might also consider using Parallelizer instead:
>
I think there is a general issue here in terms of mapping the algorithms
of solutions to problems to the right tools from the library.  I think
Actors have been to emphasized recently throughout the field.  Data
parallelism and asynchronous function call with futures are tools that
people are not being made aware of enough.

I think we need to make use of all these examples people are coming up
with in order to make a taxonomy that can provide idioms of solution for
people.

So in the new year, I propose we take examples like the Sleeping Barber
(and as many others as we can) and systematically create solutions using
all the different tools and write short commentaries -- we need to avoid
bias but not be averse to adverse criticism.


--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                           xmpp: [hidden email]
Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,   f: +44 8700 516 084   voip: [hidden email]
London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder



--
E-mail: [hidden email]
Blog: http://www.jroller.com/vaclav
Linkedin page: http://www.linkedin.com/in/vaclavpech
Reply | Threaded
Open this post in threaded view
|

Re: GPARS in the web service tier

Jeff Gortatowsky
In reply to this post by Jeff Gortatowsky
Dr Windor your proposal would be a welcome addition indeed.  I chose actors because I did not see a fit with other paradigms. I have four units of work to get done. None depend on the outcome of the others and are separate. Only the client cares about the aggregated result. So I saw this as four actors 'acting' on behalf of the client. Nothing else made much sense. Yes my use case is 'splitter / combiner'
 
Again if there is a more appropriate implementation I am all 'eyes' :)

Best wishes 

--------------------
Sent from someone elses iPhone.  Go figure.  
Jeff

On Dec 23, 2009, at 12:59 AM, Vaclav Pech <[hidden email]> wrote:

Hi Russel,

what you're proposing  makes a lot of sense (as usual). Actors are just one way to do concurrency and for many problems not necessarily the most intuitive and straightforward one. While Scala or perhaps Erlang concurrency story is all about actors, Clojure on the other hand doesn't include actors at all.

I agree, we need to propagate the various concepts that live under the GPars roof and on examples show the typical use cases of each them.
I've created a dedicated JIRA - http://jira.codehaus.org/browse/GPARS-63 which is now looking for volunteers.

Regards,

Vaclav




On Wed, Dec 23, 2009 at 9:33 AM, Russel Winder <[hidden email]> wrote:
On Wed, 2009-12-23 at 09:06 +0100, Vaclav Pech wrote:
>
> this is a very interesting example and in my opinion a valid use case
> for GPars. Using actors here looks quite natural to me and is a good
> choice.
> Since each of your actors consumes just one message and then exits,
> you might also consider using Parallelizer instead:
>
I think there is a general issue here in terms of mapping the algorithms
of solutions to problems to the right tools from the library.  I think
Actors have been to emphasized recently throughout the field.  Data
parallelism and asynchronous function call with futures are tools that
people are not being made aware of enough.

I think we need to make use of all these examples people are coming up
with in order to make a taxonomy that can provide idioms of solution for
people.

So in the new year, I propose we take examples like the Sleeping Barber
(and as many others as we can) and systematically create solutions using
all the different tools and write short commentaries -- we need to avoid
bias but not be averse to adverse criticism.


--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                           xmpp: [hidden email]
Concertant LLP        t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,   f: +44 8700 516 084   voip: [hidden email]
London SW11 1EN, UK   m: +44 7770 465 077   skype: russel_winder



--
E-mail: [hidden email]
Blog: http://www.jroller.com/vaclav
Linkedin page: http://www.linkedin.com/in/vaclavpech
Reply | Threaded
Open this post in threaded view
|

Re: GPARS in the web service tier

Jeff Gortatowsky
In reply to this post by Vaclav

Thank you Vaclav for that example!  You have given me more to think about. Perhaps your solution is cleaner as it requires no actors to hold 'state'? Unless I can make the actors more 'functional' style and stateless. :)

Thank you... having fun with GPARS because it's so easy to experiment with. Lets me concentrate more on the solving the problems rather than the all the Java mechanics involving coding the details of thread lifecycle management. Plus it is more expressive. However GAPRS has a lot of choices! 

I have no real 'parallel' algorithms to solve. I am not simulating the state of matter as it falls into a gravitation well, or protein folding, or anything like that.  I simply want to make better use of multiple cores and I/O wait times in 'normal' coding to achieve better response times/SLAs. :)

Best wishes!
Jeff

---------------------------------------
Jeff Gortatowsky, Fullerton, CA | Twitter: JeffGortatowsky | Yahoo: indanapt


From: Vaclav Pech <[hidden email]>
To: [hidden email]
Sent: Wed, December 23, 2009 12:06:51 AM
Subject: Re: [gpars-user] GPARS in the web service tier

Hi Jeff,

this is a very interesting example and in my opinion a valid use case for GPars. Using actors here looks quite natural to me and is a good choice.
Since each of your actors consumes just one message and then exits, you might also consider using Parallelizer instead:

service() {
    Parallelizer.doParallel(4) {
        def results = [
            new FindUserCommand(),
            new FindUserEntitlementsCommand(),
            new FindUserExpirationInfoCommand(),
            new FindUserQuestionnaireInfoCommand()
        ].collectParallel{it.call userid}

       return new UserPricingInfoDto(user: results[0],
               userEntitlementDto: new UserEntitlementDto(list: results[1]),
               userExpirationInfo: results[2],
               userQuestionnaireInfo: results[3])
    }
}

Cheers,

Vaclav


On Wed, Dec 23, 2009 at 5:27 AM, Jeff Gortatowsky <[hidden email]> wrote:
I neglected to mention the actors are not using loop but are using react

--------------------
Sent from someone elses iPhone.  Go figure.
Jeff

On Dec 22, 2009, at 5:41 PM, Jeff Gortatowsky <[hidden email]> wrote:

Well I did it. But I am not yet sure it's right. Not by a long shot. I need to run some pretty heavy integration / load testing to convince myself all my database reads are isolated in each actor and that it's all threadsafe. Which I have not done yet. I did put in sleep() delays to convince myself that all were in parallel. They were as the total time was the longest sleep delay.

As I wrote earlier I am not even sure actors were the right implementation as my actors single use stateful actors (I made them so). So for each client call the normal grails thread /service instantiates 4 actors, each with a specific task and a specific instance of a domain object. I then tell all four to hit the DB and fulfill their part in reading their assigned domain object. I then join on all four, read the results, and send that back via CXF. It all seems to work. But I can't help but wonder if actors were the right paradigm.

Looks like:
service() {
      def userActor = new FindUserActor()
      def entitlementActor = new FindUserEntitlementsActor()
      def expirationActor = new FindUserExpirationInfoActor()
      def questionnaireInfoActor = new FindUserQuestionnaireInfoActor()
      def actors = [userActor, entitlementActor, expirationActor, questionnaireInfoActor]
      actors*.start()
      actors*.send(userid)
      actors*.join()
      return new UserPricingInfoDto(user: userActor.user,
              userEntitlementDto: new UserEntitlementDto(list: entitlementActor.finalList),
              userExpirationInfo: expirationActor.userExpirationInfo,
              userQuestionnaireInfo: questionnaireInfoActor.questionnaireInfo)
}

Interesting, each gets it's own hibernate session (ThreadLocal). I only do reads. :)

I have to admit threading can give one a headache, but GPARS if it is being used right, could change my mind. :D


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





--
E-mail: [hidden email]
Blog: http://www.jroller.com/vaclav
Linkedin page: http://www.linkedin.com/in/vaclavpech
Reply | Threaded
Open this post in threaded view
|

Re: GPARS in the web service tier

Vaclav
Administrator
Thank you Jeff for your nice words. I'm glad you like GPars.
Would you give me permission to add your opinion to the project website? - http://gpars.codehaus.org/User+Voices

Cheers,

Vaclav


On Wed, Dec 23, 2009 at 4:52 PM, Jeff Gortatowsky <[hidden email]> wrote:

Thank you Vaclav for that example!  You have given me more to think about. Perhaps your solution is cleaner as it requires no actors to hold 'state'? Unless I can make the actors more 'functional' style and stateless. :)

Thank you... having fun with GPARS because it's so easy to experiment with. Lets me concentrate more on the solving the problems rather than the all the Java mechanics involving coding the details of thread lifecycle management. Plus it is more expressive. However GAPRS has a lot of choices! 

I have no real 'parallel' algorithms to solve. I am not simulating the state of matter as it falls into a gravitation well, or protein folding, or anything like that.  I simply want to make better use of multiple cores and I/O wait times in 'normal' coding to achieve better response times/SLAs. :)

Best wishes!
Jeff

---------------------------------------
Jeff Gortatowsky, Fullerton, CA | Twitter: JeffGortatowsky | Yahoo: indanapt


From: Vaclav Pech <[hidden email]>
To: [hidden email]
Sent: Wed, December 23, 2009 12:06:51 AM
Subject: Re: [gpars-user] GPARS in the web service tier

Hi Jeff,

this is a very interesting example and in my opinion a valid use case for GPars. Using actors here looks quite natural to me and is a good choice.
Since each of your actors consumes just one message and then exits, you might also consider using Parallelizer instead:

service() {
    Parallelizer.doParallel(4) {
        def results = [
            new FindUserCommand(),
            new FindUserEntitlementsCommand(),
            new FindUserExpirationInfoCommand(),
            new FindUserQuestionnaireInfoCommand()
        ].collectParallel{it.call userid}

       return new UserPricingInfoDto(user: results[0],
               userEntitlementDto: new UserEntitlementDto(list: results[1]),
               userExpirationInfo: results[2],
               userQuestionnaireInfo: results[3])
    }
}

Cheers,

Vaclav


On Wed, Dec 23, 2009 at 5:27 AM, Jeff Gortatowsky <[hidden email]> wrote:
I neglected to mention the actors are not using loop but are using react

--------------------
Sent from someone elses iPhone.  Go figure.
Jeff

On Dec 22, 2009, at 5:41 PM, Jeff Gortatowsky <[hidden email]> wrote:

Well I did it. But I am not yet sure it's right. Not by a long shot. I need to run some pretty heavy integration / load testing to convince myself all my database reads are isolated in each actor and that it's all threadsafe. Which I have not done yet. I did put in sleep() delays to convince myself that all were in parallel. They were as the total time was the longest sleep delay.

As I wrote earlier I am not even sure actors were the right implementation as my actors single use stateful actors (I made them so). So for each client call the normal grails thread /service instantiates 4 actors, each with a specific task and a specific instance of a domain object. I then tell all four to hit the DB and fulfill their part in reading their assigned domain object. I then join on all four, read the results, and send that back via CXF. It all seems to work. But I can't help but wonder if actors were the right paradigm.

Looks like:
service() {
      def userActor = new FindUserActor()
      def entitlementActor = new FindUserEntitlementsActor()
      def expirationActor = new FindUserExpirationInfoActor()
      def questionnaireInfoActor = new FindUserQuestionnaireInfoActor()
      def actors = [userActor, entitlementActor, expirationActor, questionnaireInfoActor]
      actors*.start()
      actors*.send(userid)
      actors*.join()
      return new UserPricingInfoDto(user: userActor.user,
              userEntitlementDto: new UserEntitlementDto(list: entitlementActor.finalList),
              userExpirationInfo: expirationActor.userExpirationInfo,
              userQuestionnaireInfo: questionnaireInfoActor.questionnaireInfo)
}

Interesting, each gets it's own hibernate session (ThreadLocal). I only do reads. :)

I have to admit threading can give one a headache, but GPARS if it is being used right, could change my mind. :D


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





--
E-mail: [hidden email]
Blog: http://www.jroller.com/vaclav
Linkedin page: http://www.linkedin.com/in/vaclavpech



--
E-mail: [hidden email]
Blog: http://www.jroller.com/vaclav
Linkedin page: http://www.linkedin.com/in/vaclavpech
Reply | Threaded
Open this post in threaded view
|

Re: GPARS in the web service tier

Jeff Gortatowsky
Comments are done. 

Vaclev your solution worked fine and requires no state in the worker threads. 
There are many many options in GPARS. Maybe too many!? If course one can never have too many options (or layers of abstraction aye?). ;^)

Now to figure out a load test! :) Been trying to use Faban but the XFORM stuff in Faban is arduous! ... oy vieh... 
Maybe a Griffon app? But I need to seed the DB and no GORM in Griffon... I think...

---------------------------------------
Jeff Gortatowsky, Fullerton, CA | Twitter: JeffGortatowsky | Yahoo: indanapt


From: Vaclav Pech <[hidden email]>
To: [hidden email]
Sent: Wed, December 23, 2009 8:25:55 AM
Subject: Re: [gpars-user] GPARS in the web service tier

Thank you Jeff for your nice words. I'm glad you like GPars.
Would you give me permission to add your opinion to the project website? - http://gpars.codehaus.org/User+Voices

Cheers,

Vaclav


On Wed, Dec 23, 2009 at 4:52 PM, Jeff Gortatowsky <[hidden email]> wrote:

Thank you Vaclav for that example!  You have given me more to think about. Perhaps your solution is cleaner as it requires no actors to hold 'state'? Unless I can make the actors more 'functional' style and stateless. :)

Thank you... having fun with GPARS because it's so easy to experiment with. Lets me concentrate more on the solving the problems rather than the all the Java mechanics involving coding the details of thread lifecycle management. Plus it is more expressive. However GAPRS has a lot of choices! 

I have no real 'parallel' algorithms to solve. I am not simulating the state of matter as it falls into a gravitation well, or protein folding, or anything like that.  I simply want to make better use of multiple cores and I/O wait times in 'normal' coding to achieve better response times/SLAs. :)

Best wishes!
Jeff

---------------------------------------
Jeff Gortatowsky, Fullerton, CA | Twitter: JeffGortatowsky | Yahoo: indanapt


From: Vaclav Pech <[hidden email]>
To: [hidden email]
Sent: Wed, December 23, 2009 12:06:51 AM
Subject: Re: [gpars-user] GPARS in the web service tier

Hi Jeff,

this is a very interesting example and in my opinion a valid use case for GPars. Using actors here looks quite natural to me and is a good choice.
Since each of your actors consumes just one message and then exits, you might also consider using Parallelizer instead:

service() {
    Parallelizer.doParallel(4) {
        def results = [
            new FindUserCommand(),
            new FindUserEntitlementsCommand(),
            new FindUserExpirationInfoCommand(),
            new FindUserQuestionnaireInfoCommand()
        ].collectParallel{it.call userid}

       return new UserPricingInfoDto(user: results[0],
               userEntitlementDto: new UserEntitlementDto(list: results[1]),
               userExpirationInfo: results[2],
               userQuestionnaireInfo: results[3])
    }
}

Cheers,

Vaclav


On Wed, Dec 23, 2009 at 5:27 AM, Jeff Gortatowsky <[hidden email]> wrote:
I neglected to mention the actors are not using loop but are using react

--------------------
Sent from someone elses iPhone.  Go figure.
Jeff

On Dec 22, 2009, at 5:41 PM, Jeff Gortatowsky <[hidden email]> wrote:

Well I did it. But I am not yet sure it's right. Not by a long shot. I need to run some pretty heavy integration / load testing to convince myself all my database reads are isolated in each actor and that it's all threadsafe. Which I have not done yet. I did put in sleep() delays to convince myself that all were in parallel. They were as the total time was the longest sleep delay.

As I wrote earlier I am not even sure actors were the right implementation as my actors single use stateful actors (I made them so). So for each client call the normal grails thread /service instantiates 4 actors, each with a specific task and a specific instance of a domain object. I then tell all four to hit the DB and fulfill their part in reading their assigned domain object. I then join on all four, read the results, and send that back via CXF. It all seems to work. But I can't help but wonder if actors were the right paradigm.

Looks like:
service() {
      def userActor = new FindUserActor()
      def entitlementActor = new FindUserEntitlementsActor()
      def expirationActor = new FindUserExpirationInfoActor()
      def questionnaireInfoActor = new FindUserQuestionnaireInfoActor()
      def actors = [userActor, entitlementActor, expirationActor, questionnaireInfoActor]
      actors*.start()
      actors*.send(userid)
      actors*.join()
      return new UserPricingInfoDto(user: userActor.user,
              userEntitlementDto: new UserEntitlementDto(list: entitlementActor.finalList),
              userExpirationInfo: expirationActor.userExpirationInfo,
              userQuestionnaireInfo: questionnaireInfoActor.questionnaireInfo)
}

Interesting, each gets it's own hibernate session (ThreadLocal). I only do reads. :)

I have to admit threading can give one a headache, but GPARS if it is being used right, could change my mind. :D


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





--
E-mail: [hidden email]
Blog: http://www.jroller.com/vaclav
Linkedin page: http://www.linkedin.com/in/vaclavpech



--
E-mail: [hidden email]
Blog: http://www.jroller.com/vaclav
Linkedin page: http://www.linkedin.com/in/vaclavpech
Reply | Threaded
Open this post in threaded view
|

Re: GPARS in the web service tier

Vaclav
Administrator
Jeff, thanks a lot for your comment.
Yes, we definitely need to make sure people do not get swamped by too many options. I think we'll need to document typical use scenarios in the user guide.
Good luck with your experiments!

Cheers,

Vaclav



On Thu, Dec 24, 2009 at 3:06 AM, Jeff Gortatowsky <[hidden email]> wrote:
Comments are done. 

Vaclev your solution worked fine and requires no state in the worker threads. 
There are many many options in GPARS. Maybe too many!? If course one can never have too many options (or layers of abstraction aye?). ;^)

Now to figure out a load test! :) Been trying to use Faban but the XFORM stuff in Faban is arduous! ... oy vieh... 
Maybe a Griffon app? But I need to seed the DB and no GORM in Griffon... I think...

---------------------------------------
Jeff Gortatowsky, Fullerton, CA | Twitter: JeffGortatowsky | Yahoo: indanapt


From: Vaclav Pech <[hidden email]>
To: [hidden email]
Sent: Wed, December 23, 2009 8:25:55 AM

Subject: Re: [gpars-user] GPARS in the web service tier

Thank you Jeff for your nice words. I'm glad you like GPars.
Would you give me permission to add your opinion to the project website? - http://gpars.codehaus.org/User+Voices

Cheers,

Vaclav


On Wed, Dec 23, 2009 at 4:52 PM, Jeff Gortatowsky <[hidden email]> wrote:

Thank you Vaclav for that example!  You have given me more to think about. Perhaps your solution is cleaner as it requires no actors to hold 'state'? Unless I can make the actors more 'functional' style and stateless. :)

Thank you... having fun with GPARS because it's so easy to experiment with. Lets me concentrate more on the solving the problems rather than the all the Java mechanics involving coding the details of thread lifecycle management. Plus it is more expressive. However GAPRS has a lot of choices! 

I have no real 'parallel' algorithms to solve. I am not simulating the state of matter as it falls into a gravitation well, or protein folding, or anything like that.  I simply want to make better use of multiple cores and I/O wait times in 'normal' coding to achieve better response times/SLAs. :)

Best wishes!
Jeff

---------------------------------------
Jeff Gortatowsky, Fullerton, CA | Twitter: JeffGortatowsky | Yahoo: indanapt


From: Vaclav Pech <[hidden email]>
To: [hidden email]
Sent: Wed, December 23, 2009 12:06:51 AM
Subject: Re: [gpars-user] GPARS in the web service tier

Hi Jeff,

this is a very interesting example and in my opinion a valid use case for GPars. Using actors here looks quite natural to me and is a good choice.
Since each of your actors consumes just one message and then exits, you might also consider using Parallelizer instead:

service() {
    Parallelizer.doParallel(4) {
        def results = [
            new FindUserCommand(),
            new FindUserEntitlementsCommand(),
            new FindUserExpirationInfoCommand(),
            new FindUserQuestionnaireInfoCommand()
        ].collectParallel{it.call userid}

       return new UserPricingInfoDto(user: results[0],
               userEntitlementDto: new UserEntitlementDto(list: results[1]),
               userExpirationInfo: results[2],
               userQuestionnaireInfo: results[3])
    }
}

Cheers,

Vaclav


On Wed, Dec 23, 2009 at 5:27 AM, Jeff Gortatowsky <[hidden email]> wrote:
I neglected to mention the actors are not using loop but are using react

--------------------
Sent from someone elses iPhone.  Go figure.
Jeff

On Dec 22, 2009, at 5:41 PM, Jeff Gortatowsky <[hidden email]> wrote:

Well I did it. But I am not yet sure it's right. Not by a long shot. I need to run some pretty heavy integration / load testing to convince myself all my database reads are isolated in each actor and that it's all threadsafe. Which I have not done yet. I did put in sleep() delays to convince myself that all were in parallel. They were as the total time was the longest sleep delay.

As I wrote earlier I am not even sure actors were the right implementation as my actors single use stateful actors (I made them so). So for each client call the normal grails thread /service instantiates 4 actors, each with a specific task and a specific instance of a domain object. I then tell all four to hit the DB and fulfill their part in reading their assigned domain object. I then join on all four, read the results, and send that back via CXF. It all seems to work. But I can't help but wonder if actors were the right paradigm.

Looks like:
service() {
      def userActor = new FindUserActor()
      def entitlementActor = new FindUserEntitlementsActor()
      def expirationActor = new FindUserExpirationInfoActor()
      def questionnaireInfoActor = new FindUserQuestionnaireInfoActor()
      def actors = [userActor, entitlementActor, expirationActor, questionnaireInfoActor]
      actors*.start()
      actors*.send(userid)
      actors*.join()
      return new UserPricingInfoDto(user: userActor.user,
              userEntitlementDto: new UserEntitlementDto(list: entitlementActor.finalList),
              userExpirationInfo: expirationActor.userExpirationInfo,
              userQuestionnaireInfo: questionnaireInfoActor.questionnaireInfo)
}

Interesting, each gets it's own hibernate session (ThreadLocal). I only do reads. :)

I have to admit threading can give one a headache, but GPARS if it is being used right, could change my mind. :D


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email




---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email





--
E-mail: [hidden email]
Blog: http://www.jroller.com/vaclav
Linkedin page: http://www.linkedin.com/in/vaclavpech



--
E-mail: [hidden email]
Blog: http://www.jroller.com/vaclav
Linkedin page: http://www.linkedin.com/in/vaclavpech



--
E-mail: [hidden email]
Blog: http://www.jroller.com/vaclav
Linkedin page: http://www.linkedin.com/in/vaclavpech