Help with actor threads

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

Help with actor threads

Vinicius Carvalho
Hi there! I'm testing Actor support on GPars. I'm really in love with GPars now, it saved me so much boilerplate code.

But I think I really did not get the Actor way of GPars. I have a small exposure to Akka, I've used it in the past. So here's my problem:

I have two actors, XMLActor and HttpActor. XMLActor will send one or more messages to HttpActor. 

I'm trying to get my mind to understand how actors and the threadpool should work together. I thought that by creating a StatelessActor, for every message sent to it, a new thread would process it.

But from my code [https://gist.github.com/5014818.git] Here's what I notice from jconsole:

I set the number of threads to 32, but what really happens is that a lot of new threads (more than the 32 limit) are created for the XMLActor

After XMLActor finishes (he's the faster producer, httpActor is the slow consumer here), I'm left with only one single thread for httpActor handling all the messages (not enjoying much of parallelism here)

I wonder if my construct:

final XMLActor xmlActor = new XMLActor(httpActor:httpActor).start()

is the cause of that, since I'm passing a reference to httpActor, but if this is the case, I then wonder how could I avoid the fact that after xmlActor stops my main thread waits for httpActor to finish


I'd love to hear any suggestions or pointers on how to properly use actor communication here.

Regards
--
The intuitive mind is a sacred gift and the
rational mind is a faithful servant. We have
created a society that honors the servant and
has forgotten the gift.
Reply | Threaded
Open this post in threaded view
|

Re: Help with actor threads

Vaclav
Administrator
Hi Vinicius,

unfortunately, I don't seem to be able to see the linked gist, so the only comment I can make is about the possible confusion regarding stateless actors. These are stateless in a sense that they do not preserve the state of the computation (stack) while waiting for a message. With each message they invoke one of the message handlers. Stateful actors, on the other hand, simulate continuations in that your computation will continue after next message arrival exactly where you left it by calling react().
Stateless actors still keep state (meaning data) acccross subsequent message arrivals and thus at most one thread can be running the actor at any moment.

Václav



On Fri, Feb 22, 2013 at 5:50 PM, Vinicius Carvalho <[hidden email]> wrote:
Hi there! I'm testing Actor support on GPars. I'm really in love with GPars now, it saved me so much boilerplate code.

But I think I really did not get the Actor way of GPars. I have a small exposure to Akka, I've used it in the past. So here's my problem:

I have two actors, XMLActor and HttpActor. XMLActor will send one or more messages to HttpActor. 

I'm trying to get my mind to understand how actors and the threadpool should work together. I thought that by creating a StatelessActor, for every message sent to it, a new thread would process it.

But from my code [https://gist.github.com/5014818.git] Here's what I notice from jconsole:

I set the number of threads to 32, but what really happens is that a lot of new threads (more than the 32 limit) are created for the XMLActor

After XMLActor finishes (he's the faster producer, httpActor is the slow consumer here), I'm left with only one single thread for httpActor handling all the messages (not enjoying much of parallelism here)

I wonder if my construct:

final XMLActor xmlActor = new XMLActor(httpActor:httpActor).start()

is the cause of that, since I'm passing a reference to httpActor, but if this is the case, I then wonder how could I avoid the fact that after xmlActor stops my main thread waits for httpActor to finish


I'd love to hear any suggestions or pointers on how to properly use actor communication here.

Regards
--
The intuitive mind is a sacred gift and the
rational mind is a faithful servant. We have
created a society that honors the servant and
has forgotten the gift.



--
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: Help with actor threads

Vinicius Carvalho

Hi Vaclav, thanks for your quick response. I've paste the wrong link :) https://gist.github.com/viniciusccarvalho/5014818

Well, that explains a lot :), I'm pretty sure that's where the confusion came from, I was thinking in stateless in a different way :)

I think it also explains why I was getting "The thread pool executor cannot run the task. The upper limit of the thread pool size has probably been reached. Current pool size: 1000 Maximum pool size: 1000" errors after I changed a bit the code.

If you don't mind, I would like to pick your brain for a few more seconds.

So considering my flow: XMLActor sends messages to HttpActor, and HttpActor being the slow consumer. From my main thread I could just set HttpActor pool to be a nonDaemon and I should be ok right?

Another question would be: Do I need to create several XMLActors from a loop or just one and fire tons of messages would work, for instance:

def filesToBeParsed = new File(....)

filesToBeParsed.eachLine { line -> 
     def xmlActor = new XmlActor().start()
     xmlActor << line
}


OR

    def xmlActor = new XmlActor().start()
filesToBeParsed.eachLine { line -> 
      xmlActor << line
}


I'm a bit confused on this one :)

Thanks a lot for the help, and for giving us this fantastic framework :D





On Fri, Feb 22, 2013 at 12:46 PM, Václav Pech <[hidden email]> wrote:
Hi Vinicius,

unfortunately, I don't seem to be able to see the linked gist, so the only comment I can make is about the possible confusion regarding stateless actors. These are stateless in a sense that they do not preserve the state of the computation (stack) while waiting for a message. With each message they invoke one of the message handlers. Stateful actors, on the other hand, simulate continuations in that your computation will continue after next message arrival exactly where you left it by calling react().
Stateless actors still keep state (meaning data) acccross subsequent message arrivals and thus at most one thread can be running the actor at any moment.

Václav



On Fri, Feb 22, 2013 at 5:50 PM, Vinicius Carvalho <[hidden email]> wrote:
Hi there! I'm testing Actor support on GPars. I'm really in love with GPars now, it saved me so much boilerplate code.

But I think I really did not get the Actor way of GPars. I have a small exposure to Akka, I've used it in the past. So here's my problem:

I have two actors, XMLActor and HttpActor. XMLActor will send one or more messages to HttpActor. 

I'm trying to get my mind to understand how actors and the threadpool should work together. I thought that by creating a StatelessActor, for every message sent to it, a new thread would process it.

But from my code [https://gist.github.com/5014818.git] Here's what I notice from jconsole:

I set the number of threads to 32, but what really happens is that a lot of new threads (more than the 32 limit) are created for the XMLActor

After XMLActor finishes (he's the faster producer, httpActor is the slow consumer here), I'm left with only one single thread for httpActor handling all the messages (not enjoying much of parallelism here)

I wonder if my construct:

final XMLActor xmlActor = new XMLActor(httpActor:httpActor).start()

is the cause of that, since I'm passing a reference to httpActor, but if this is the case, I then wonder how could I avoid the fact that after xmlActor stops my main thread waits for httpActor to finish


I'd love to hear any suggestions or pointers on how to properly use actor communication here.

Regards
--
The intuitive mind is a sacred gift and the
rational mind is a faithful servant. We have
created a society that honors the servant and
has forgotten the gift.



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



--
The intuitive mind is a sacred gift and the
rational mind is a faithful servant. We have
created a society that honors the servant and
has forgotten the gift.
Reply | Threaded
Open this post in threaded view
|

Re: Help with actor threads

Vaclav
Administrator
Hi Vinicius,

I'm happy to hear you enjoy GPars!


So considering my flow: XMLActor sends messages to HttpActor, and HttpActor being the slow consumer. From my main thread I could just set HttpActor pool to be a nonDaemon and I should be ok right?


Setting the pool to nonDeamon will prevent the JVM from exiting until you call shutdown() on that pool. Since your code has full control over the lifecycle of the two actors, I think it may not be necessary to use nonDaemon pools.
Did I understand correctly your question here?
 
Another question would be: Do I need to create several XMLActors from a loop or just one and fire tons of messages would work, for instance:

def filesToBeParsed = new File(....)

filesToBeParsed.eachLine { line -> 
     def xmlActor = new XmlActor().start()
     xmlActor << line
}


OR

    def xmlActor = new XmlActor().start()
filesToBeParsed.eachLine { line -> 
      xmlActor << line
}



Since the work on one line is independant of the other lines, I'd in general prefer the former approach with a new actor per line. However, in your case producers are not the bottleneck, so unless consumers become faster both producer approaches would perform similarly, I think.
For further speedup, I would even consider passing the line as an argument to the constructor, instead of sending it as a message, since each actor now only handles one message anyway:

filesToBeParsed.eachLine { line -> 
     def xmlActor = new XmlActor(line).start()
}


Cheers,

Vaclav



 




On Fri, Feb 22, 2013 at 12:46 PM, Václav Pech <[hidden email]> wrote:
Hi Vinicius,

unfortunately, I don't seem to be able to see the linked gist, so the only comment I can make is about the possible confusion regarding stateless actors. These are stateless in a sense that they do not preserve the state of the computation (stack) while waiting for a message. With each message they invoke one of the message handlers. Stateful actors, on the other hand, simulate continuations in that your computation will continue after next message arrival exactly where you left it by calling react().
Stateless actors still keep state (meaning data) acccross subsequent message arrivals and thus at most one thread can be running the actor at any moment.

Václav



On Fri, Feb 22, 2013 at 5:50 PM, Vinicius Carvalho <[hidden email]> wrote:
Hi there! I'm testing Actor support on GPars. I'm really in love with GPars now, it saved me so much boilerplate code.

But I think I really did not get the Actor way of GPars. I have a small exposure to Akka, I've used it in the past. So here's my problem:

I have two actors, XMLActor and HttpActor. XMLActor will send one or more messages to HttpActor. 

I'm trying to get my mind to understand how actors and the threadpool should work together. I thought that by creating a StatelessActor, for every message sent to it, a new thread would process it.

But from my code [https://gist.github.com/5014818.git] Here's what I notice from jconsole:

I set the number of threads to 32, but what really happens is that a lot of new threads (more than the 32 limit) are created for the XMLActor

After XMLActor finishes (he's the faster producer, httpActor is the slow consumer here), I'm left with only one single thread for httpActor handling all the messages (not enjoying much of parallelism here)

I wonder if my construct:

final XMLActor xmlActor = new XMLActor(httpActor:httpActor).start()

is the cause of that, since I'm passing a reference to httpActor, but if this is the case, I then wonder how could I avoid the fact that after xmlActor stops my main thread waits for httpActor to finish


I'd love to hear any suggestions or pointers on how to properly use actor communication here.

Regards
--
The intuitive mind is a sacred gift and the
rational mind is a faithful servant. We have
created a society that honors the servant and
has forgotten the gift.



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



--
The intuitive mind is a sacred gift and the
rational mind is a faithful servant. We have
created a society that honors the servant and
has forgotten the gift.



--
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: Help with actor threads

Vinicius Carvalho
Hi Vaclav, using the first approach, I'm limited to a single actor running at each time. This is what is really spinning my head at the moment.

I was expecting that each invocation of an actor << message would run on a separate thread

but its not what is happening. If xmlActor has a reference to httpActor, only one thread at the moment is executed. This is what I'm really not getting. If I have a simple code where the producer sends 100 messages, and the actor that consumes just have a simple method like
Thread.sleep(10), it actually takes 1 second for the code to be executed. I mean, its being executed in a serial manner.

On the other hand, creating a new actor for each line (I'm reading 250k lines) and using a nonDaemonGroup, I exceed  the number of threads (1000) very quickly.

I probably understood the actor concept on GPars wrong, but I thought that:

Each actor internal react closure would be executed by a Runnable worker inside a pool

Messages would be queued inside some sort of mailbox (ArrayBlockingQueue??) and several workers would fetch one message pass to the actor reference (not instance) and execute it.

But I'm running either in a situation where I only have 2 active actors on the system (not benefiting from concurrency) or, if I create a new actor for each message that I'm sending I ran out of resources (1000 threads)

I'm positive that I'm doing something wrong here, would you mine help me with this a little further? 

Please find this small snippet that demonstrate what I'm talking
:

Thanks a lot


On Fri, Feb 22, 2013 at 2:13 PM, Václav Pech <[hidden email]> wrote:
Hi Vinicius,

I'm happy to hear you enjoy GPars!


So considering my flow: XMLActor sends messages to HttpActor, and HttpActor being the slow consumer. From my main thread I could just set HttpActor pool to be a nonDaemon and I should be ok right?


Setting the pool to nonDeamon will prevent the JVM from exiting until you call shutdown() on that pool. Since your code has full control over the lifecycle of the two actors, I think it may not be necessary to use nonDaemon pools.
Did I understand correctly your question here?
 
Another question would be: Do I need to create several XMLActors from a loop or just one and fire tons of messages would work, for instance:

def filesToBeParsed = new File(....)

filesToBeParsed.eachLine { line -> 
     def xmlActor = new XmlActor().start()
     xmlActor << line
}


OR

    def xmlActor = new XmlActor().start()
filesToBeParsed.eachLine { line -> 
      xmlActor << line
}



Since the work on one line is independant of the other lines, I'd in general prefer the former approach with a new actor per line. However, in your case producers are not the bottleneck, so unless consumers become faster both producer approaches would perform similarly, I think.
For further speedup, I would even consider passing the line as an argument to the constructor, instead of sending it as a message, since each actor now only handles one message anyway:

filesToBeParsed.eachLine { line -> 
     def xmlActor = new XmlActor(line).start()
}


Cheers,

Vaclav



 




On Fri, Feb 22, 2013 at 12:46 PM, Václav Pech <[hidden email]> wrote:
Hi Vinicius,

unfortunately, I don't seem to be able to see the linked gist, so the only comment I can make is about the possible confusion regarding stateless actors. These are stateless in a sense that they do not preserve the state of the computation (stack) while waiting for a message. With each message they invoke one of the message handlers. Stateful actors, on the other hand, simulate continuations in that your computation will continue after next message arrival exactly where you left it by calling react().
Stateless actors still keep state (meaning data) acccross subsequent message arrivals and thus at most one thread can be running the actor at any moment.

Václav



On Fri, Feb 22, 2013 at 5:50 PM, Vinicius Carvalho <[hidden email]> wrote:
Hi there! I'm testing Actor support on GPars. I'm really in love with GPars now, it saved me so much boilerplate code.

But I think I really did not get the Actor way of GPars. I have a small exposure to Akka, I've used it in the past. So here's my problem:

I have two actors, XMLActor and HttpActor. XMLActor will send one or more messages to HttpActor. 

I'm trying to get my mind to understand how actors and the threadpool should work together. I thought that by creating a StatelessActor, for every message sent to it, a new thread would process it.

But from my code [https://gist.github.com/5014818.git] Here's what I notice from jconsole:

I set the number of threads to 32, but what really happens is that a lot of new threads (more than the 32 limit) are created for the XMLActor

After XMLActor finishes (he's the faster producer, httpActor is the slow consumer here), I'm left with only one single thread for httpActor handling all the messages (not enjoying much of parallelism here)

I wonder if my construct:

final XMLActor xmlActor = new XMLActor(httpActor:httpActor).start()

is the cause of that, since I'm passing a reference to httpActor, but if this is the case, I then wonder how could I avoid the fact that after xmlActor stops my main thread waits for httpActor to finish


I'd love to hear any suggestions or pointers on how to properly use actor communication here.

Regards
--
The intuitive mind is a sacred gift and the
rational mind is a faithful servant. We have
created a society that honors the servant and
has forgotten the gift.



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



--
The intuitive mind is a sacred gift and the
rational mind is a faithful servant. We have
created a society that honors the servant and
has forgotten the gift.



--
The intuitive mind is a sacred gift and the
rational mind is a faithful servant. We have
created a society that honors the servant and
has forgotten the gift.
Reply | Threaded
Open this post in threaded view
|

Re: Help with actor threads

Vaclav
Administrator
Hi Vinicius,

it indeed seems like a misunderstanding. Actors give you an abstraction of asynchronously communicating objects. Since they in general may hold state (e.g. in private fields), you may never get more than one thread running the actor's body in order to preserve thread-safety. Thus you only get two threads busy for two active actors.

On the other hand, the default thread pool that your actors are using is resizeable and so may easily grow beyond the 1000 thread boundary, when using the actor-per-line approach. I'd recommend you used custom PGroups to asign fixed-sized thread-pools to your actors (the actor's parallelGroup property). This will allow you to have many more actors than threads.


I probably understood the actor concept on GPars wrong, but I thought that:

Each actor internal react closure would be executed by a Runnable worker inside a pool

Messages would be queued inside some sort of mailbox (ArrayBlockingQueue??) and several workers would fetch one message pass to the actor reference (not instance) and execute it.



Such a model would indeed be the most suitable abstraction for your producer-consumer problem. In GPars we offer dataflow operators, which work exactly as you describe - stateless parallel workers sharing a single data stream (queue). Dataflow is usually a better match for producer-consumer scenarios than actors, since it allows for indirect addressing and controlling the level of parallelism.


Cheers,

Vaclav




 
But I'm running either in a situation where I only have 2 active actors on the system (not benefiting from concurrency) or, if I create a new actor for each message that I'm sending I ran out of resources (1000 threads)

I'm positive that I'm doing something wrong here, would you mine help me with this a little further? 

Please find this small snippet that demonstrate what I'm talking
:

Thanks a lot


On Fri, Feb 22, 2013 at 2:13 PM, Václav Pech <[hidden email]> wrote:
Hi Vinicius,

I'm happy to hear you enjoy GPars!


So considering my flow: XMLActor sends messages to HttpActor, and HttpActor being the slow consumer. From my main thread I could just set HttpActor pool to be a nonDaemon and I should be ok right?


Setting the pool to nonDeamon will prevent the JVM from exiting until you call shutdown() on that pool. Since your code has full control over the lifecycle of the two actors, I think it may not be necessary to use nonDaemon pools.
Did I understand correctly your question here?
 
Another question would be: Do I need to create several XMLActors from a loop or just one and fire tons of messages would work, for instance:

def filesToBeParsed = new File(....)

filesToBeParsed.eachLine { line -> 
     def xmlActor = new XmlActor().start()
     xmlActor << line
}


OR

    def xmlActor = new XmlActor().start()
filesToBeParsed.eachLine { line -> 
      xmlActor << line
}



Since the work on one line is independant of the other lines, I'd in general prefer the former approach with a new actor per line. However, in your case producers are not the bottleneck, so unless consumers become faster both producer approaches would perform similarly, I think.
For further speedup, I would even consider passing the line as an argument to the constructor, instead of sending it as a message, since each actor now only handles one message anyway:

filesToBeParsed.eachLine { line -> 
     def xmlActor = new XmlActor(line).start()
}


Cheers,

Vaclav



 




On Fri, Feb 22, 2013 at 12:46 PM, Václav Pech <[hidden email]> wrote:
Hi Vinicius,

unfortunately, I don't seem to be able to see the linked gist, so the only comment I can make is about the possible confusion regarding stateless actors. These are stateless in a sense that they do not preserve the state of the computation (stack) while waiting for a message. With each message they invoke one of the message handlers. Stateful actors, on the other hand, simulate continuations in that your computation will continue after next message arrival exactly where you left it by calling react().
Stateless actors still keep state (meaning data) acccross subsequent message arrivals and thus at most one thread can be running the actor at any moment.

Václav



On Fri, Feb 22, 2013 at 5:50 PM, Vinicius Carvalho <[hidden email]> wrote:
Hi there! I'm testing Actor support on GPars. I'm really in love with GPars now, it saved me so much boilerplate code.

But I think I really did not get the Actor way of GPars. I have a small exposure to Akka, I've used it in the past. So here's my problem:

I have two actors, XMLActor and HttpActor. XMLActor will send one or more messages to HttpActor. 

I'm trying to get my mind to understand how actors and the threadpool should work together. I thought that by creating a StatelessActor, for every message sent to it, a new thread would process it.

But from my code [https://gist.github.com/5014818.git] Here's what I notice from jconsole:

I set the number of threads to 32, but what really happens is that a lot of new threads (more than the 32 limit) are created for the XMLActor

After XMLActor finishes (he's the faster producer, httpActor is the slow consumer here), I'm left with only one single thread for httpActor handling all the messages (not enjoying much of parallelism here)

I wonder if my construct:

final XMLActor xmlActor = new XMLActor(httpActor:httpActor).start()

is the cause of that, since I'm passing a reference to httpActor, but if this is the case, I then wonder how could I avoid the fact that after xmlActor stops my main thread waits for httpActor to finish


I'd love to hear any suggestions or pointers on how to properly use actor communication here.

Regards
--
The intuitive mind is a sacred gift and the
rational mind is a faithful servant. We have
created a society that honors the servant and
has forgotten the gift.



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



--
The intuitive mind is a sacred gift and the
rational mind is a faithful servant. We have
created a society that honors the servant and
has forgotten the gift.



--
The intuitive mind is a sacred gift and the
rational mind is a faithful servant. We have
created a society that honors the servant and
has forgotten the gift.



--
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: Help with actor threads

Vinicius Carvalho
Thanks, I'll take a look at dataflows, I'm probably using the wrong approach. Thanks for all the help.

Regards


On Fri, Feb 22, 2013 at 3:23 PM, Václav Pech <[hidden email]> wrote:
Hi Vinicius,

it indeed seems like a misunderstanding. Actors give you an abstraction of asynchronously communicating objects. Since they in general may hold state (e.g. in private fields), you may never get more than one thread running the actor's body in order to preserve thread-safety. Thus you only get two threads busy for two active actors.

On the other hand, the default thread pool that your actors are using is resizeable and so may easily grow beyond the 1000 thread boundary, when using the actor-per-line approach. I'd recommend you used custom PGroups to asign fixed-sized thread-pools to your actors (the actor's parallelGroup property). This will allow you to have many more actors than threads.


I probably understood the actor concept on GPars wrong, but I thought that:

Each actor internal react closure would be executed by a Runnable worker inside a pool

Messages would be queued inside some sort of mailbox (ArrayBlockingQueue??) and several workers would fetch one message pass to the actor reference (not instance) and execute it.



Such a model would indeed be the most suitable abstraction for your producer-consumer problem. In GPars we offer dataflow operators, which work exactly as you describe - stateless parallel workers sharing a single data stream (queue). Dataflow is usually a better match for producer-consumer scenarios than actors, since it allows for indirect addressing and controlling the level of parallelism.


Cheers,

Vaclav




 
But I'm running either in a situation where I only have 2 active actors on the system (not benefiting from concurrency) or, if I create a new actor for each message that I'm sending I ran out of resources (1000 threads)

I'm positive that I'm doing something wrong here, would you mine help me with this a little further? 

Please find this small snippet that demonstrate what I'm talking
:

Thanks a lot


On Fri, Feb 22, 2013 at 2:13 PM, Václav Pech <[hidden email]> wrote:
Hi Vinicius,

I'm happy to hear you enjoy GPars!


So considering my flow: XMLActor sends messages to HttpActor, and HttpActor being the slow consumer. From my main thread I could just set HttpActor pool to be a nonDaemon and I should be ok right?


Setting the pool to nonDeamon will prevent the JVM from exiting until you call shutdown() on that pool. Since your code has full control over the lifecycle of the two actors, I think it may not be necessary to use nonDaemon pools.
Did I understand correctly your question here?
 
Another question would be: Do I need to create several XMLActors from a loop or just one and fire tons of messages would work, for instance:

def filesToBeParsed = new File(....)

filesToBeParsed.eachLine { line -> 
     def xmlActor = new XmlActor().start()
     xmlActor << line
}


OR

    def xmlActor = new XmlActor().start()
filesToBeParsed.eachLine { line -> 
      xmlActor << line
}



Since the work on one line is independant of the other lines, I'd in general prefer the former approach with a new actor per line. However, in your case producers are not the bottleneck, so unless consumers become faster both producer approaches would perform similarly, I think.
For further speedup, I would even consider passing the line as an argument to the constructor, instead of sending it as a message, since each actor now only handles one message anyway:

filesToBeParsed.eachLine { line -> 
     def xmlActor = new XmlActor(line).start()
}


Cheers,

Vaclav



 




On Fri, Feb 22, 2013 at 12:46 PM, Václav Pech <[hidden email]> wrote:
Hi Vinicius,

unfortunately, I don't seem to be able to see the linked gist, so the only comment I can make is about the possible confusion regarding stateless actors. These are stateless in a sense that they do not preserve the state of the computation (stack) while waiting for a message. With each message they invoke one of the message handlers. Stateful actors, on the other hand, simulate continuations in that your computation will continue after next message arrival exactly where you left it by calling react().
Stateless actors still keep state (meaning data) acccross subsequent message arrivals and thus at most one thread can be running the actor at any moment.

Václav



On Fri, Feb 22, 2013 at 5:50 PM, Vinicius Carvalho <[hidden email]> wrote:
Hi there! I'm testing Actor support on GPars. I'm really in love with GPars now, it saved me so much boilerplate code.

But I think I really did not get the Actor way of GPars. I have a small exposure to Akka, I've used it in the past. So here's my problem:

I have two actors, XMLActor and HttpActor. XMLActor will send one or more messages to HttpActor. 

I'm trying to get my mind to understand how actors and the threadpool should work together. I thought that by creating a StatelessActor, for every message sent to it, a new thread would process it.

But from my code [https://gist.github.com/5014818.git] Here's what I notice from jconsole:

I set the number of threads to 32, but what really happens is that a lot of new threads (more than the 32 limit) are created for the XMLActor

After XMLActor finishes (he's the faster producer, httpActor is the slow consumer here), I'm left with only one single thread for httpActor handling all the messages (not enjoying much of parallelism here)

I wonder if my construct:

final XMLActor xmlActor = new XMLActor(httpActor:httpActor).start()

is the cause of that, since I'm passing a reference to httpActor, but if this is the case, I then wonder how could I avoid the fact that after xmlActor stops my main thread waits for httpActor to finish


I'd love to hear any suggestions or pointers on how to properly use actor communication here.

Regards
--
The intuitive mind is a sacred gift and the
rational mind is a faithful servant. We have
created a society that honors the servant and
has forgotten the gift.



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



--
The intuitive mind is a sacred gift and the
rational mind is a faithful servant. We have
created a society that honors the servant and
has forgotten the gift.



--
The intuitive mind is a sacred gift and the
rational mind is a faithful servant. We have
created a society that honors the servant and
has forgotten the gift.



--
The intuitive mind is a sacred gift and the
rational mind is a faithful servant. We have
created a society that honors the servant and
has forgotten the gift.