2.0(.1) feedback requested

[√iktor Ҡlang]

Dear hAkkers,

Now it's almost been 3 months since we released Akka 2.0, and we, the committers would really appreciate

getting some feedback on what your experiences have been during the past months.

If you cannot share this publically, please feel free to send the feedback to me personally and I'll keep it confidential.

Elicitinguser feedback is the key ingredient in making sure that Akka evolves in the right direction and that problems are

taken care of.

Looking forward to hearing about your Akka 2.0 experiences!

Cheers,

√

--
Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Christer Sandberg]

Hi!

We've used Akka 2.0 since its release and it's been a pure pleasure so
say the least. The only thing I can complain a little about
is the actor naming part which I wish could be replaced by some
strategy. I can understand the reasoning to restrict the available
characters to those in URL (or was it URI?), but I think we would be
able to change that if we now what we're doing. I don't remember
exactly if this would have an impact on the remoting stuff, but it
would be like "If you change this you're on your own". We have a lot
of actors that need to be looked up by name, and we can't change that
naming part. They contain the characters åäö sometimes, and
now I'm using a murmur hash of the strings to name the actors. It's
kind of tedious to do this in every place where needed, and it's much
harder to follow what's happening in the log files without passing on
the "real" name everywhere.

This is my only complaint and it's a small one. But important for us
in our system.

Cheers,
Christer

> --
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To post to this group, send email to akka...@googlegroups.com.
> To unsubscribe from this group, send email to
> akka-user+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/akka-user?hl=en.

[Christer Sandberg]

On Thu, May 24, 2012 at 2:14 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:
> Wow, impressive response time! :-)

>
> On Thu, May 24, 2012 at 2:08 PM, Christer Sandberg <chr...@gmail.com> wrote:
>>
>> Hi!
>>
>> We've used Akka 2.0 since its release and it's been a pure pleasure so
>> say the least. The only thing I can complain a little about
>> is the actor naming part which I wish could be replaced by some
>> strategy. I can understand the reasoning to restrict the available
>> characters to those in URL (or was it URI?), but I think we would be
>> able to change that if we now what we're doing. I don't remember
>> exactly if this would have an impact on the remoting stuff, but it
>> would be like "If you change this you're on your own".
>
>

> This is going to be core to Akka in the future, using URIs enables us to
> reuse a lot of existing plumbing,
> talking to actors via REST etc.

>
>>
>> We have a lot
>> of actors that need to be looked up by name, and we can't change that
>> naming part. They contain the characters åäö sometimes, and
>> now I'm using a murmur hash of the strings to name the actors. It's
>> kind of tedious to do this in every place where needed, and it's much
>> harder to follow what's happening in the log files without passing on
>> the "real" name everywhere.
>
>

> Technically you could create your own ActorRefProvider, and do the
> translation in the actorFor call.

>
>>
>>
>> This is my only complaint and it's a small one. But important for us
>> in our system.
>
>

> We could also investigate if it's viable to use escapes in the names (%20
> etc)

That would be awesome! Not all of us speak english you know ;)

>
> Cheers,
> √

[√iktor Ҡlang]

Wow, impressive response time! :-)

On Thu, May 24, 2012 at 2:08 PM, Christer Sandberg <chr...@gmail.com> wrote:

Hi!

We've used Akka 2.0 since its release and it's been a pure pleasure so
say the least. The only thing I can complain a little about
is the actor naming part which I wish could be replaced by some
strategy. I can understand the reasoning to restrict the available
characters to those in URL (or was it URI?), but I think we would be
able to change that if we now what we're doing. I don't remember
exactly if this would have an impact on the remoting stuff, but it
would be like "If you change this you're on your own".

This is going to be core to Akka in the future, using URIs enables us to reuse a lot of existing plumbing,

talking to actors via REST etc.

 

We have a lot

of actors that need to be looked up by name, and we can't change that
naming part. They contain the characters åäö sometimes, and
now I'm using a murmur hash of the strings to name the actors. It's
kind of tedious to do this in every place where needed, and it's much
harder to follow what's happening in the log files without passing on
the "real" name everywhere.

Technically you could create your own ActorRefProvider, and do the translation in the actorFor call.

 

This is my only complaint and it's a small one. But important for us
in our system.

We could also investigate if it's viable to use escapes in the names (%20 etc)

Cheers,

√

[Roland Kuhn]

Yes, that would indeed be possible, it is explicitly allowed by RFC2396, I only have not put it in yet because it would be some work (simple regex will not be sufficient anymore). Created a ticket now, so we can prioritize: http://www.assembla.com/spaces/akka/tickets/2123

Regards,

Roland

Roland Kuhn
Typesafe – The software stack for applications that scale.
twitter: @rolandkuhn

[Christer Sandberg]

Glad to hear that Roland! Thanks a lot.

[Derek Wyatt]

Before I start griping, it needs to be said that Akka 2.0 is a major step forward.  It's a great piece of software and the team should be commended.

I think the biggest stumbling block is the imposed Actor hierarchy.  All in all it's a good thing, don't get me wrong, but it's the first real thing that Akka has done that "gets in my way", and in a round-about way it seems to be what Christer has hit as well.

- I wanted to use Deploy because it's such a great and easy way to launch Actors remotely, but I didn't want it in the same ActorSystem.  I had to cook up my own way of doing it.  Can we see the Guardian code exposed some how to make this easier to do?

- Some examples regarding the layout of Actors in the ActorSystem would also be nice.  "Bushy" trees are bad, but how bushy is too bushy?  Is it only lookup that is hurt by the bushiness or is it something else?

- Can we get a fast lookup tool for Actors?  Further to Christer's issue on naming, if the user is diligent and uses unique names for everything, then from their point of view the path isn't relevant for uniqueness.  Lookup is a simple hash table in that case.

- We've heard that many ActorSystems is "bad".  Specifically knowing "why" would be a good thing, I think.

- Given that the hierarchy is there, and we have some restrictions on how the hierarchy is built up, we may find that we have to insert a number of "invisible" nodes to satisfy that hierarchy - e.g. when something becomes too bushy, we need to insert a layer of artificial parent nodes that increase the depth of the tree.  It would be nice if Akka supplied some of these.  For example, "Supervisor-only".

- The structure of the hierarchy can make applications brittle as the hierarchy gets shuffled around - assuming you're looking up by path.  If we insert nodes into the hierarchy then the paths change.  Can we get a more flexible lookup scheme?  For example, I posted a piece of code a while back that was called "FindAncestor".  This helps when, what was the parent, becomes the grandparent due to a supervisor that was put in the middle.  FindAncestor finds the "parent" either way.

- Actor tests tend to be "slow" compared to standard unit tests, where a hundred or so should run in about a second.  Parallelizing Actor tests isn't possible using the examples placed in the documentation.  It would be nice to see some strategies for speeding up these tests with some parallelism.  I've done a bit of work here and it works out well, but it does it by using many ActorSystems.  It might be nice to have the TestKit expose the different "systems" to each test (but obviously not all different ActorSystems) that have a specific User Guardian.  Generally this is where we hit problems with parallelism because we have multiple tests working with the same Actor path.  If we could make the paths unique within the same system by introducing test-specific guardians, that might help (?).

I think that's it for now :)

[√iktor Ҡlang]

Hi Derek!

On Thu, May 24, 2012 at 2:38 PM, Derek Wyatt <de...@derekwyatt.org> wrote:

Before I start griping, it needs to be said that Akka 2.0 is a major step forward.  It's a great piece of software and the team should be commended.

I think the biggest stumbling block is the imposed Actor hierarchy.  All in all it's a good thing, don't get me wrong, but it's the first real thing that Akka has done that "gets in my way", and in a round-about way it seems to be what Christer has hit as well.

- I wanted to use Deploy because it's such a great and easy way to launch Actors remotely, but I didn't want it in the same ActorSystem.  I had to cook up my own way of doing it.  Can we see the Guardian code exposed some how to make this easier to do?

WDYM?

 

- Some examples regarding the layout of Actors in the ActorSystem would also be nice.  "Bushy" trees are bad, but how bushy is too bushy?  Is it only lookup that is hurt by the bushiness or is it something else?

The only thing I've ever stated clearly is "do not create too many top level actors" this is mainly due to the fact that the fault-tolreance part is shot to shit since any malfunctioning piece risks taking everything down.

 

- Can we get a fast lookup tool for Actors?  Further to Christer's issue on naming, if the user is diligent and uses unique names for everything, then from their point of view the path isn't relevant for uniqueness.  Lookup is a simple hash table in that case.

WDYM?

 

- We've heard that many ActorSystems is "bad".  Specifically knowing "why" would be a good thing, I think.

It's bad because it's a heavyweight structure, it will allocate threads for the scheduler, the dispatchers etc, and as you all know, you can't create infinite threads.

We're making some progress regarding this for 2.1 where you'll be able to reuse the same EC for many ActorSystems (with the downside that they'll be stepping on eachotehrs toes if you are not careful), but I don't see how we'll ever get away from having one thread per scheduler.

 

- Given that the hierarchy is there, and we have some restrictions on how the hierarchy is built up, we may find that we have to insert a number of "invisible" nodes to satisfy that hierarchy - e.g. when something becomes too bushy, we need to insert a layer of artificial parent nodes that increase the depth of the tree.  It would be nice if Akka supplied some of these.  For example, "Supervisor-only".

No, you don't need to do that, just keep the root clean so you have a reasonable fault tolerance strategy. Also, creating top-level actors is currently a blocking operation since it's done from outside the guardian, there is a ticket to work around this by cheating, but it has yet to be implemented, but is slated for Mingus.

 

- The structure of the hierarchy can make applications brittle as the hierarchy gets shuffled around - assuming you're looking up by path.  If we insert nodes into the hierarchy then the paths change.  Can we get a more flexible lookup scheme?  For example, I posted a piece of code a while back that was called "FindAncestor".  This helps when, what was the parent, becomes the grandparent due to a supervisor that was put in the middle.  FindAncestor finds the "parent" either way.

This is already possible using relative lookups in actorFor, no?

 

- Actor tests tend to be "slow" compared to standard unit tests, where a hundred or so should run in about a second.  Parallelizing Actor tests isn't possible using the examples placed in the documentation.  It would be nice to see some strategies for speeding up these tests with some parallelism.  I've done a bit of work here and it works out well, but it does it by using many ActorSystems.  It might be nice to have the TestKit expose the different "systems" to each test (but obviously not all different ActorSystems) that have a specific User Guardian.  Generally this is where we hit problems with parallelism because we have multiple tests working with the same Actor path.  If we could make the paths unique within the same system by introducing test-specific guardians, that might help (?).

There's no real reason why actor tests should be slow, but if you create an ActorSystem for every test, and use Thread.sleep and/or Await.result everywhere, then of course it'll be slower. This is mainly due to the silly structure imposed by testing frameworks that expect a test to be synchronous, would be much better if you could return a Future[TestResult].

 

I think that's it for now :)

Excellent feedback, thanks!

Cheers,

√

 

On 2012-05-24, at 8:00 AM, √iktor Ҡlang wrote:

Dear hAkkers,

Now it's almost been 3 months since we released Akka 2.0, and we, the committers would really appreciate

getting some feedback on what your experiences have been during the past months.

If you cannot share this publically, please feel free to send the feedback to me personally and I'll keep it confidential.

Elicitinguser feedback is the key ingredient in making sure that Akka evolves in the right direction and that problems are

taken care of.

Looking forward to hearing about your Akka 2.0 experiences!

Cheers,

√

--
Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

[Jonas Bonér]

On Thu, May 24, 2012 at 2:48 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:

Hi Derek!

On Thu, May 24, 2012 at 2:38 PM, Derek Wyatt <de...@derekwyatt.org> wrote:

Before I start griping, it needs to be said that Akka 2.0 is a major step forward.  It's a great piece of software and the team should be commended.

I think the biggest stumbling block is the imposed Actor hierarchy.  All in all it's a good thing, don't get me wrong, but it's the first real thing that Akka has done that "gets in my way", and in a round-about way it seems to be what Christer has hit as well.

- I wanted to use Deploy because it's such a great and easy way to launch Actors remotely, but I didn't want it in the same ActorSystem.  I had to cook up my own way of doing it.  Can we see the Guardian code exposed some how to make this easier to do?

WDYM?

 

- Some examples regarding the layout of Actors in the ActorSystem would also be nice.  "Bushy" trees are bad, but how bushy is too bushy?  Is it only lookup that is hurt by the bushiness or is it something else?

The only thing I've ever stated clearly is "do not create too many top level actors" this is mainly due to the fact that the fault-tolreance part is shot to shit since any malfunctioning piece risks taking everything down.

 

- Can we get a fast lookup tool for Actors?  Further to Christer's issue on naming, if the user is diligent and uses unique names for everything, then from their point of view the path isn't relevant for uniqueness.  Lookup is a simple hash table in that case.

You can easily do this yourself by having each actor register themselves in a global registry (actor/object/or so). Don't think we want to do this as default since it will be quite costly to do. 

--
Jonas Bonér
CTO

Typesafe - The software stack for applications that scale

Phone: +46 733 777 123
Twitter: @jboner

[√iktor Ҡlang]

On Thu, May 24, 2012 at 4:00 PM, Derek Wyatt <de...@derekwyatt.org> wrote:

On Thu, May 24, 2012 at 2:48 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:

Hi Derek!

On Thu, May 24, 2012 at 2:38 PM, Derek Wyatt <de...@derekwyatt.org> wrote:

Before I start griping, it needs to be said that Akka 2.0 is a major step forward.  It's a great piece of software and the team should be commended.

I think the biggest stumbling block is the imposed Actor hierarchy.  All in all it's a good thing, don't get me wrong, but it's the first real thing that Akka has done that "gets in my way", and in a round-about way it seems to be what Christer has hit as well.

- I wanted to use Deploy because it's such a great and easy way to launch Actors remotely, but I didn't want it in the same ActorSystem.  I had to cook up my own way of doing it.  Can we see the Guardian code exposed some how to make this easier to do?

WDYM?

If I want to create an Actor on machine "X" outside of my ActorSystem, then I have to send a message to "something" on machine "X" that makes the Actor and sends me the reference.  Obviously something already does this (since it has to for Deploy).  All I'm suggesting is that we get access to that, already correct, functionality.

The idea is to avoid creating actors from the outside, since that is by natura a racy operation, which is also why system.actorOf is problematic

 

 

- Some examples regarding the layout of Actors in the ActorSystem would also be nice.  "Bushy" trees are bad, but how bushy is too bushy?  Is it only lookup that is hurt by the bushiness or is it something else?

The only thing I've ever stated clearly is "do not create too many top level actors" this is mainly due to the fact that the fault-tolreance part is shot to shit since any malfunctioning piece risks taking everything down.

Ah, I was under the impression that it made for slower functionality. Bushiness makes for big "children" structures and thus increases the searching time.  So what you're saying is that I can create a /user/MobileDevices and then create 2 million children of that and everything's cool?

It's backed by a tree, so you have O(log N) access to kids

 

  That would be awesome.  In many cases I am not concerned with hierarchy at all.  I just need to represent a ton of "stuff" out there in the world and the "world" doesn't have a natural hierarchy that I can use to make a non-busy tree.

The tree is for fault-tolerance, thinking about the failure hierarchy of your system makes it a lot easier to structure it.

 

  Thus, if I want to spread things down the tree I have to make an artificial set of inner nodes.

But again, if you're saying that's cool, then I'm a happy dood.

You shouldn't optimize prematurely. We're doing that for you. All we ask is that you keep root actors to a minimum, think about your failure hierarchy and try to create Actors and have them stopped when they are obsolete.

 

 

- Can we get a fast lookup tool for Actors?  Further to Christer's issue on naming, if the user is diligent and uses unique names for everything, then from their point of view the path isn't relevant for uniqueness.  Lookup is a simple hash table in that case.

You can easily do this yourself by having each actor register themselves in a global registry (actor/object/or so). Don't think we want to do this as default since it will be quite costly to do.

And my claim is that many people might want this.  If we could get it by a simple mixin of our Actor, then that might be a nice feature.

Create an Extension and I'll reference it in the docs!

 

 

WDYM?

 

- We've heard that many ActorSystems is "bad".  Specifically knowing "why" would be a good thing, I think.

It's bad because it's a heavyweight structure, it will allocate threads for the scheduler, the dispatchers etc, and as you all know, you can't create infinite threads.

We're making some progress regarding this for 2.1 where you'll be able to reuse the same EC for many ActorSystems (with the downside that they'll be stepping on eachotehrs toes if you are not careful), but I don't see how we'll ever get away from having one thread per scheduler.

OK, can this maybe go in the docs?

Sure, will land in master ASAP.

 

 

- Given that the hierarchy is there, and we have some restrictions on how the hierarchy is built up, we may find that we have to insert a number of "invisible" nodes to satisfy that hierarchy - e.g. when something becomes too bushy, we need to insert a layer of artificial parent nodes that increase the depth of the tree.  It would be nice if Akka supplied some of these.  For example, "Supervisor-only".

No, you don't need to do that, just keep the root clean so you have a reasonable fault tolerance strategy. Also, creating top-level actors is currently a blocking operation since it's done from outside the guardian, there is a ticket to work around this by cheating, but it has yet to be implemented, but is slated for Mingus.

See above.  I think I'm happy, assuming /user/MobileDevices can be the parent of a couple of million children.

Please try and report back!

 

 

- The structure of the hierarchy can make applications brittle as the hierarchy gets shuffled around - assuming you're looking up by path.  If we insert nodes into the hierarchy then the paths change.  Can we get a more flexible lookup scheme?  For example, I posted a piece of code a while back that was called "FindAncestor".  This helps when, what was the parent, becomes the grandparent due to a supervisor that was put in the middle.  FindAncestor finds the "parent" either way.

This is already possible using relative lookups in actorFor, no?

Not that I'm aware of.  "context.actorFor(../../)" is different than "context.actorFor(../../../)".  When I insert something in the tree, my actor should be doing ../../../ instead of ../../, but it doesn't know that, and since it's getting only an ActorRef, clearly the compiler can't help me.  I claim it might be better to have "context.actorForAncesestorNamed(guy above me)".

What if you change the ancestors name?

 

 

- Actor tests tend to be "slow" compared to standard unit tests, where a hundred or so should run in about a second.  Parallelizing Actor tests isn't possible using the examples placed in the documentation.  It would be nice to see some strategies for speeding up these tests with some parallelism.  I've done a bit of work here and it works out well, but it does it by using many ActorSystems.  It might be nice to have the TestKit expose the different "systems" to each test (but obviously not all different ActorSystems) that have a specific User Guardian.  Generally this is where we hit problems with parallelism because we have multiple tests working with the same Actor path.  If we could make the paths unique within the same system by introducing test-specific guardians, that might help (?).

There's no real reason why actor tests should be slow, but if you create an ActorSystem for every test, and use Thread.sleep and/or Await.result everywhere, then of course it'll be slower. This is mainly due to the silly structure imposed by testing frameworks that expect a test to be synchronous, would be much better if you could return a Future[TestResult].

They're absolutely slower when you have message passing.  It can be one or two orders of magnitude slower.  If you have "addTen(5) must be (15)" then this is way faster than "expectMsg(AddTenResult(15))".  Now multiply that by 100 tests.  The time to compile and test is now getting to be far longer than it takes me to make code changes to be tested.  It hurts the edit-compile-test cycle.

Since an Actor can do approx 3million messages per second on my machine, the difference in time, even if you have hundreds of tests, should be negligible, unless you're ceating ActorSystems & do blocking ops (or other potentially costly initialization logic)

Cheers,

√

 

 

I think that's it for now :)

Excellent feedback, thanks!

Cheers,
Derek
 

[Derek Wyatt]

On 24 May 2012 10:12, √iktor Ҡlang <viktor...@gmail.com> wrote:

On Thu, May 24, 2012 at 4:00 PM, Derek Wyatt <de...@derekwyatt.org> wrote:

On Thu, May 24, 2012 at 2:48 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:

Hi Derek!

On Thu, May 24, 2012 at 2:38 PM, Derek Wyatt <de...@derekwyatt.org> wrote:

Before I start griping, it needs to be said that Akka 2.0 is a major step forward.  It's a great piece of software and the team should be commended.

I think the biggest stumbling block is the imposed Actor hierarchy.  All in all it's a good thing, don't get me wrong, but it's the first real thing that Akka has done that "gets in my way", and in a round-about way it seems to be what Christer has hit as well.

- I wanted to use Deploy because it's such a great and easy way to launch Actors remotely, but I didn't want it in the same ActorSystem.  I had to cook up my own way of doing it.  Can we see the Guardian code exposed some how to make this easier to do?

WDYM?

If I want to create an Actor on machine "X" outside of my ActorSystem, then I have to send a message to "something" on machine "X" that makes the Actor and sends me the reference.  Obviously something already does this (since it has to for Deploy).  All I'm suggesting is that we get access to that, already correct, functionality.

The idea is to avoid creating actors from the outside, since that is by natura a racy operation, which is also why system.actorOf is problematic

Well, I couldn't avoid it :)  And yes, it was tricky and not 100% correct, I'm sure.  This is why I'm saying that the imposed hierarchy is the biggest impact (or so it would seem).  If it's problematic, and I can't avoid it, then I'm probably going to screw it up.  I was hoping that the experts could help me not screw it up.
 

 

- Some examples regarding the layout of Actors in the ActorSystem would also be nice.  "Bushy" trees are bad, but how bushy is too bushy?  Is it only lookup that is hurt by the bushiness or is it something else?

The only thing I've ever stated clearly is "do not create too many top level actors" this is mainly due to the fact that the fault-tolreance part is shot to shit since any malfunctioning piece risks taking everything down.

Ah, I was under the impression that it made for slower functionality. Bushiness makes for big "children" structures and thus increases the searching time.  So what you're saying is that I can create a /user/MobileDevices and then create 2 million children of that and everything's cool?

It's backed by a tree, so you have O(log N) access to kids

 

  That would be awesome.  In many cases I am not concerned with hierarchy at all.  I just need to represent a ton of "stuff" out there in the world and the "world" doesn't have a natural hierarchy that I can use to make a non-busy tree.

The tree is for fault-tolerance, thinking about the failure hierarchy of your system makes it a lot easier to structure it.

 

  Thus, if I want to spread things down the tree I have to make an artificial set of inner nodes.

But again, if you're saying that's cool, then I'm a happy dood.

You shouldn't optimize prematurely. We're doing that for you. All we ask is that you keep root actors to a minimum, think about your failure hierarchy and try to create Actors and have them stopped when they are obsolete.

Well, I wasn't trying to optimize prematurely.  I was reacting to, what I thought was, an issue with bushy trees that already existed.
 

- Can we get a fast lookup tool for Actors?  Further to Christer's issue on naming, if the user is diligent and uses unique names for everything, then from their point of view the path isn't relevant for uniqueness.  Lookup is a simple hash table in that case.

You can easily do this yourself by having each actor register themselves in a global registry (actor/object/or so). Don't think we want to do this as default since it will be quite costly to do.

And my claim is that many people might want this.  If we could get it by a simple mixin of our Actor, then that might be a nice feature.

Create an Extension and I'll reference it in the docs!

 

 

WDYM?

 

- We've heard that many ActorSystems is "bad".  Specifically knowing "why" would be a good thing, I think.

It's bad because it's a heavyweight structure, it will allocate threads for the scheduler, the dispatchers etc, and as you all know, you can't create infinite threads.

We're making some progress regarding this for 2.1 where you'll be able to reuse the same EC for many ActorSystems (with the downside that they'll be stepping on eachotehrs toes if you are not careful), but I don't see how we'll ever get away from having one thread per scheduler.

OK, can this maybe go in the docs?

Sure, will land in master ASAP.

 

 

- Given that the hierarchy is there, and we have some restrictions on how the hierarchy is built up, we may find that we have to insert a number of "invisible" nodes to satisfy that hierarchy - e.g. when something becomes too bushy, we need to insert a layer of artificial parent nodes that increase the depth of the tree.  It would be nice if Akka supplied some of these.  For example, "Supervisor-only".

No, you don't need to do that, just keep the root clean so you have a reasonable fault tolerance strategy. Also, creating top-level actors is currently a blocking operation since it's done from outside the guardian, there is a ticket to work around this by cheating, but it has yet to be implemented, but is slated for Mingus.

See above.  I think I'm happy, assuming /user/MobileDevices can be the parent of a couple of million children.

Please try and report back!

 

 

- The structure of the hierarchy can make applications brittle as the hierarchy gets shuffled around - assuming you're looking up by path.  If we insert nodes into the hierarchy then the paths change.  Can we get a more flexible lookup scheme?  For example, I posted a piece of code a while back that was called "FindAncestor".  This helps when, what was the parent, becomes the grandparent due to a supervisor that was put in the middle.  FindAncestor finds the "parent" either way.

This is already possible using relative lookups in actorFor, no?

Not that I'm aware of.  "context.actorFor(../../)" is different than "context.actorFor(../../../)".  When I insert something in the tree, my actor should be doing ../../../ instead of ../../, but it doesn't know that, and since it's getting only an ActorRef, clearly the compiler can't help me.  I claim it might be better to have "context.actorForAncesestorNamed(guy above me)".

What if you change the ancestors name?

I wasn't.  The point is moot.  I changed the hierarchy, not the name.
 

 

 

- Actor tests tend to be "slow" compared to standard unit tests, where a hundred or so should run in about a second.  Parallelizing Actor tests isn't possible using the examples placed in the documentation.  It would be nice to see some strategies for speeding up these tests with some parallelism.  I've done a bit of work here and it works out well, but it does it by using many ActorSystems.  It might be nice to have the TestKit expose the different "systems" to each test (but obviously not all different ActorSystems) that have a specific User Guardian.  Generally this is where we hit problems with parallelism because we have multiple tests working with the same Actor path.  If we could make the paths unique within the same system by introducing test-specific guardians, that might help (?).

There's no real reason why actor tests should be slow, but if you create an ActorSystem for every test, and use Thread.sleep and/or Await.result everywhere, then of course it'll be slower. This is mainly due to the silly structure imposed by testing frameworks that expect a test to be synchronous, would be much better if you could return a Future[TestResult].

They're absolutely slower when you have message passing.  It can be one or two orders of magnitude slower.  If you have "addTen(5) must be (15)" then this is way faster than "expectMsg(AddTenResult(15))".  Now multiply that by 100 tests.  The time to compile and test is now getting to be far longer than it takes me to make code changes to be tested.  It hurts the edit-compile-test cycle.

Since an Actor can do approx 3million messages per second on my machine, the difference in time, even if you have hundreds of tests, should be negligible, unless you're ceating ActorSystems & do blocking ops (or other potentially costly initialization logic)

Well, I'm telling you that I saw an increase when I went parallel.  You asked for feedback, I'm giving it to you :)
 

[Roland Kuhn]

Hi Derek,

24 maj 2012 kl. 14:48 skrev √iktor Ҡlang:

On Thu, May 24, 2012 at 2:38 PM, Derek Wyatt <de...@derekwyatt.org> wrote:

Before I start griping, it needs to be said that Akka 2.0 is a major step forward.  It's a great piece of software and the team should be commended.

I think the biggest stumbling block is the imposed Actor hierarchy.  All in all it's a good thing, don't get me wrong, but it's the first real thing that Akka has done that "gets in my way", and in a round-about way it seems to be what Christer has hit as well.

- I wanted to use Deploy because it's such a great and easy way to launch Actors remotely, but I didn't want it in the same ActorSystem.  I had to cook up my own way of doing it.  Can we see the Guardian code exposed some how to make this easier to do?

WDYM?

Perhaps sharing your “own way” would help us understand which problem you are getting at.

 

- Some examples regarding the layout of Actors in the ActorSystem would also be nice.  "Bushy" trees are bad, but how bushy is too bushy?  Is it only lookup that is hurt by the bushiness or is it something else?

The only thing I've ever stated clearly is "do not create too many top level actors" this is mainly due to the fact that the fault-tolreance part is shot to shit since any malfunctioning piece risks taking everything down.

 

- Can we get a fast lookup tool for Actors?  Further to Christer's issue on naming, if the user is diligent and uses unique names for everything, then from their point of view the path isn't relevant for uniqueness.  Lookup is a simple hash table in that case.

WDYM?

 

- We've heard that many ActorSystems is "bad".  Specifically knowing "why" would be a good thing, I think.

It's bad because it's a heavyweight structure, it will allocate threads for the scheduler, the dispatchers etc, and as you all know, you can't create infinite threads.

We're making some progress regarding this for 2.1 where you'll be able to reuse the same EC for many ActorSystems (with the downside that they'll be stepping on eachotehrs toes if you are not careful), but I don't see how we'll ever get away from having one thread per scheduler.

 

- Given that the hierarchy is there, and we have some restrictions on how the hierarchy is built up, we may find that we have to insert a number of "invisible" nodes to satisfy that hierarchy - e.g. when something becomes too bushy, we need to insert a layer of artificial parent nodes that increase the depth of the tree.  It would be nice if Akka supplied some of these.  For example, "Supervisor-only".

No, you don't need to do that, just keep the root clean so you have a reasonable fault tolerance strategy. Also, creating top-level actors is currently a blocking operation since it's done from outside the guardian, there is a ticket to work around this by cheating, but it has yet to be implemented, but is slated for Mingus.

He’s not talking about top-level actors, but about intermediary supervisors whose only job is supervision. Since the Akka 2.0 way is still shiny and new and people are just starting to try out the quality of the black-top, there is no collection of common use patterns, yet. The simplest one—injecting a supervision level—could be provided in some kind of DSL, but you can already achieve this effect today:

context.actorOf(Props[MyChild].withRouter(RoundRobinRouter(1).withSupervisorStrategy(…)))

It’s a little circumspect but it does the job. Pull requests for improved DSLs are always welcome ;-)

 

- The structure of the hierarchy can make applications brittle as the hierarchy gets shuffled around - assuming you're looking up by path.  If we insert nodes into the hierarchy then the paths change.  Can we get a more flexible lookup scheme?  For example, I posted a piece of code a while back that was called "FindAncestor".  This helps when, what was the parent, becomes the grandparent due to a supervisor that was put in the middle.  FindAncestor finds the "parent" either way.

This is already possible using relative lookups in actorFor, no?

Yes, unless you changed the structure of the tree by adding/removing levels. But I think that such changes cannot be ignored in the general case, i.e. if you are tying things together so closely that they look one another up using relative paths, then changing the tree will likely break the whole setup also in other ways.

 

- Actor tests tend to be "slow" compared to standard unit tests, where a hundred or so should run in about a second.  Parallelizing Actor tests isn't possible using the examples placed in the documentation.  It would be nice to see some strategies for speeding up these tests with some parallelism.  I've done a bit of work here and it works out well, but it does it by using many ActorSystems.  It might be nice to have the TestKit expose the different "systems" to each test (but obviously not all different ActorSystems) that have a specific User Guardian.  Generally this is where we hit problems with parallelism because we have multiple tests working with the same Actor path.  If we could make the paths unique within the same system by introducing test-specific guardians, that might help (?).

There's no real reason why actor tests should be slow, but if you create an ActorSystem for every test, and use Thread.sleep and/or Await.result everywhere, then of course it'll be slower. This is mainly due to the silly structure imposed by testing frameworks that expect a test to be synchronous, would be much better if you could return a Future[TestResult].

What do you mean by parallelizing being impossible? Our test suite is run in parallel (takes less then half a minute on a beefy box, compared to 10 minutes for sequential execution). And we create one ActorSystem per test class. The only thing to watch out for is not to bind to hard-coded ports in the tests, i.e. always configure remoting on port zero.

I don’t get the comment about exposing specific guardians, could you please explain?

Regards,

Roland

Roland Kuhn
Typesafe – The software stack for applications that scale.
twitter: @rolandkuhn

[√iktor Ҡlang]

For any of the casual readers of this discussion,

this is exactly the sort of feedback that is needed since this really shows what painpoints people have,

so feel free to chime in, there is no "wrongs" here.

On Thu, May 24, 2012 at 4:29 PM, Derek Wyatt <de...@derekwyatt.org> wrote:

On 24 May 2012 10:12, √iktor Ҡlang <viktor...@gmail.com> wrote:

On Thu, May 24, 2012 at 4:00 PM, Derek Wyatt <de...@derekwyatt.org> wrote:

On Thu, May 24, 2012 at 2:48 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:

Hi Derek!

On Thu, May 24, 2012 at 2:38 PM, Derek Wyatt <de...@derekwyatt.org> wrote:

Before I start griping, it needs to be said that Akka 2.0 is a major step forward.  It's a great piece of software and the team should be commended.

I think the biggest stumbling block is the imposed Actor hierarchy.  All in all it's a good thing, don't get me wrong, but it's the first real thing that Akka has done that "gets in my way", and in a round-about way it seems to be what Christer has hit as well.

- I wanted to use Deploy because it's such a great and easy way to launch Actors remotely, but I didn't want it in the same ActorSystem.  I had to cook up my own way of doing it.  Can we see the Guardian code exposed some how to make this easier to do?

WDYM?

If I want to create an Actor on machine "X" outside of my ActorSystem, then I have to send a message to "something" on machine "X" that makes the Actor and sends me the reference.  Obviously something already does this (since it has to for Deploy).  All I'm suggesting is that we get access to that, already correct, functionality.

The idea is to avoid creating actors from the outside, since that is by natura a racy operation, which is also why system.actorOf is problematic

Well, I couldn't avoid it :)  And yes, it was tricky and not 100% correct, I'm sure.  This is why I'm saying that the imposed hierarchy is the biggest impact (or so it would seem).  If it's problematic, and I can't avoid it, then I'm probably going to screw it up.  I was hoping that the experts could help me not screw it up.

Comparing the imposed structure with what we had before, when very few would ever use a supervisor I think we've greatly improved on the default quality of Actor code,

of course there is more work to be done!

 

 

 

- Some examples regarding the layout of Actors in the ActorSystem would also be nice.  "Bushy" trees are bad, but how bushy is too bushy?  Is it only lookup that is hurt by the bushiness or is it something else?

The only thing I've ever stated clearly is "do not create too many top level actors" this is mainly due to the fact that the fault-tolreance part is shot to shit since any malfunctioning piece risks taking everything down.

Ah, I was under the impression that it made for slower functionality. Bushiness makes for big "children" structures and thus increases the searching time.  So what you're saying is that I can create a /user/MobileDevices and then create 2 million children of that and everything's cool?

It's backed by a tree, so you have O(log N) access to kids

 

  That would be awesome.  In many cases I am not concerned with hierarchy at all.  I just need to represent a ton of "stuff" out there in the world and the "world" doesn't have a natural hierarchy that I can use to make a non-busy tree.

The tree is for fault-tolerance, thinking about the failure hierarchy of your system makes it a lot easier to structure it.

 

  Thus, if I want to spread things down the tree I have to make an artificial set of inner nodes.

But again, if you're saying that's cool, then I'm a happy dood.

You shouldn't optimize prematurely. We're doing that for you. All we ask is that you keep root actors to a minimum, think about your failure hierarchy and try to create Actors and have them stopped when they are obsolete.

Well, I wasn't trying to optimize prematurely.  I was reacting to, what I thought was, an issue with bushy trees that already existed.

Would you mind doing a quick test to verify if it's a problem or not? (trying to wrap up the binary compat work I've been doing the past week)

 

 

- Can we get a fast lookup tool for Actors?  Further to Christer's issue on naming, if the user is diligent and uses unique names for everything, then from their point of view the path isn't relevant for uniqueness.  Lookup is a simple hash table in that case.

You can easily do this yourself by having each actor register themselves in a global registry (actor/object/or so). Don't think we want to do this as default since it will be quite costly to do.

And my claim is that many people might want this.  If we could get it by a simple mixin of our Actor, then that might be a nice feature.

Create an Extension and I'll reference it in the docs!

 

 

WDYM?

 

- We've heard that many ActorSystems is "bad".  Specifically knowing "why" would be a good thing, I think.

It's bad because it's a heavyweight structure, it will allocate threads for the scheduler, the dispatchers etc, and as you all know, you can't create infinite threads.

We're making some progress regarding this for 2.1 where you'll be able to reuse the same EC for many ActorSystems (with the downside that they'll be stepping on eachotehrs toes if you are not careful), but I don't see how we'll ever get away from having one thread per scheduler.

OK, can this maybe go in the docs?

Sure, will land in master ASAP.

 

 

- Given that the hierarchy is there, and we have some restrictions on how the hierarchy is built up, we may find that we have to insert a number of "invisible" nodes to satisfy that hierarchy - e.g. when something becomes too bushy, we need to insert a layer of artificial parent nodes that increase the depth of the tree.  It would be nice if Akka supplied some of these.  For example, "Supervisor-only".

No, you don't need to do that, just keep the root clean so you have a reasonable fault tolerance strategy. Also, creating top-level actors is currently a blocking operation since it's done from outside the guardian, there is a ticket to work around this by cheating, but it has yet to be implemented, but is slated for Mingus.

See above.  I think I'm happy, assuming /user/MobileDevices can be the parent of a couple of million children.

Please try and report back!

 

 

- The structure of the hierarchy can make applications brittle as the hierarchy gets shuffled around - assuming you're looking up by path.  If we insert nodes into the hierarchy then the paths change.  Can we get a more flexible lookup scheme?  For example, I posted a piece of code a while back that was called "FindAncestor".  This helps when, what was the parent, becomes the grandparent due to a supervisor that was put in the middle.  FindAncestor finds the "parent" either way.

This is already possible using relative lookups in actorFor, no?

Not that I'm aware of.  "context.actorFor(../../)" is different than "context.actorFor(../../../)".  When I insert something in the tree, my actor should be doing ../../../ instead of ../../, but it doesn't know that, and since it's getting only an ActorRef, clearly the compiler can't help me.  I claim it might be better to have "context.actorForAncesestorNamed(guy above me)".

What if you change the ancestors name?

I wasn't.  The point is moot.  I changed the hierarchy, not the name.

But if you change the hierarchy you might as well change names, right? I'm just saying that if you change stuff, you'll have to change stuff :-)

 

 

 

 

- Actor tests tend to be "slow" compared to standard unit tests, where a hundred or so should run in about a second.  Parallelizing Actor tests isn't possible using the examples placed in the documentation.  It would be nice to see some strategies for speeding up these tests with some parallelism.  I've done a bit of work here and it works out well, but it does it by using many ActorSystems.  It might be nice to have the TestKit expose the different "systems" to each test (but obviously not all different ActorSystems) that have a specific User Guardian.  Generally this is where we hit problems with parallelism because we have multiple tests working with the same Actor path.  If we could make the paths unique within the same system by introducing test-specific guardians, that might help (?).

There's no real reason why actor tests should be slow, but if you create an ActorSystem for every test, and use Thread.sleep and/or Await.result everywhere, then of course it'll be slower. This is mainly due to the silly structure imposed by testing frameworks that expect a test to be synchronous, would be much better if you could return a Future[TestResult].

They're absolutely slower when you have message passing.  It can be one or two orders of magnitude slower.  If you have "addTen(5) must be (15)" then this is way faster than "expectMsg(AddTenResult(15))".  Now multiply that by 100 tests.  The time to compile and test is now getting to be far longer than it takes me to make code changes to be tested.  It hurts the edit-compile-test cycle.

Since an Actor can do approx 3million messages per second on my machine, the difference in time, even if you have hundreds of tests, should be negligible, unless you're ceating ActorSystems & do blocking ops (or other potentially costly initialization logic)

Well, I'm telling you that I saw an increase when I went parallel.  You asked for feedback, I'm giving it to you :)

Absolutely! This feedback is great, but without proof that this is an issue, it's hard for me to fix anything, I just know that our internal tests are highly parallel and benefit greatly from beefier hardware, so it's working out really well for us. If you have an example to show I'd love to have a stab at it!

Cheers,

√

[Derek Wyatt]

On 24 May 2012 09:56, Roland Kuhn <goo...@rkuhn.info> wrote:

Hi Derek,

24 maj 2012 kl. 14:48 skrev √iktor Ҡlang:

On Thu, May 24, 2012 at 2:38 PM, Derek Wyatt <de...@derekwyatt.org> wrote:

Before I start griping, it needs to be said that Akka 2.0 is a major step forward.  It's a great piece of software and the team should be commended.

I think the biggest stumbling block is the imposed Actor hierarchy.  All in all it's a good thing, don't get me wrong, but it's the first real thing that Akka has done that "gets in my way", and in a round-about way it seems to be what Christer has hit as well.

- I wanted to use Deploy because it's such a great and easy way to launch Actors remotely, but I didn't want it in the same ActorSystem.  I had to cook up my own way of doing it.  Can we see the Guardian code exposed some how to make this easier to do?

WDYM?

Perhaps sharing your “own way” would help us understand which problem you are getting at.

I can't share code at the moment - in the middle of a hundred things :)  I posted it in a thread a long while ago, though... I wanted three redundant Actors around my system, and the primary would spawn the secondary.  But if I make the secondary a child of the primary, then that kind of defeats the purpose, if the primary dies.

It was pretty obvious code... send a command to a remote Actor and it spawns a child, returns that child reference to the original requester, so he can put a watch() on it.

- Some examples regarding the layout of Actors in the ActorSystem would also be nice.  "Bushy" trees are bad, but how bushy is too bushy?  Is it only lookup that is hurt by the bushiness or is it something else?

The only thing I've ever stated clearly is "do not create too many top level actors" this is mainly due to the fact that the fault-tolreance part is shot to shit since any malfunctioning piece risks taking everything down.

 

- Can we get a fast lookup tool for Actors?  Further to Christer's issue on naming, if the user is diligent and uses unique names for everything, then from their point of view the path isn't relevant for uniqueness.  Lookup is a simple hash table in that case.

WDYM?

 

- We've heard that many ActorSystems is "bad".  Specifically knowing "why" would be a good thing, I think.

It's bad because it's a heavyweight structure, it will allocate threads for the scheduler, the dispatchers etc, and as you all know, you can't create infinite threads.

We're making some progress regarding this for 2.1 where you'll be able to reuse the same EC for many ActorSystems (with the downside that they'll be stepping on eachotehrs toes if you are not careful), but I don't see how we'll ever get away from having one thread per scheduler.

 

- Given that the hierarchy is there, and we have some restrictions on how the hierarchy is built up, we may find that we have to insert a number of "invisible" nodes to satisfy that hierarchy - e.g. when something becomes too bushy, we need to insert a layer of artificial parent nodes that increase the depth of the tree.  It would be nice if Akka supplied some of these.  For example, "Supervisor-only".

No, you don't need to do that, just keep the root clean so you have a reasonable fault tolerance strategy. Also, creating top-level actors is currently a blocking operation since it's done from outside the guardian, there is a ticket to work around this by cheating, but it has yet to be implemented, but is slated for Mingus.

He’s not talking about top-level actors, but about intermediary supervisors whose only job is supervision. Since the Akka 2.0 way is still shiny and new and people are just starting to try out the quality of the black-top, there is no collection of common use patterns, yet. The simplest one—injecting a supervision level—could be provided in some kind of DSL, but you can already achieve this effect today:

context.actorOf(Props[MyChild].withRouter(RoundRobinRouter(1).withSupervisorStrategy(…)))

It’s a little circumspect but it does the job. Pull requests for improved DSLs are always welcome ;-)

I'll see if I can come up with something.  Thx :)
 

- The structure of the hierarchy can make applications brittle as the hierarchy gets shuffled around - assuming you're looking up by path.  If we insert nodes into the hierarchy then the paths change.  Can we get a more flexible lookup scheme?  For example, I posted a piece of code a while back that was called "FindAncestor".  This helps when, what was the parent, becomes the grandparent due to a supervisor that was put in the middle.  FindAncestor finds the "parent" either way.

This is already possible using relative lookups in actorFor, no?

Yes, unless you changed the structure of the tree by adding/removing levels. But I think that such changes cannot be ignored in the general case, i.e. if you are tying things together so closely that they look one another up using relative paths, then changing the tree will likely break the whole setup also in other ways.

How so?  You might need to look at my previous reply (this thread is forking, unfortunately)
 

- Actor tests tend to be "slow" compared to standard unit tests, where a hundred or so should run in about a second.  Parallelizing Actor tests isn't possible using the examples placed in the documentation.  It would be nice to see some strategies for speeding up these tests with some parallelism.  I've done a bit of work here and it works out well, but it does it by using many ActorSystems.  It might be nice to have the TestKit expose the different "systems" to each test (but obviously not all different ActorSystems) that have a specific User Guardian.  Generally this is where we hit problems with parallelism because we have multiple tests working with the same Actor path.  If we could make the paths unique within the same system by introducing test-specific guardians, that might help (?).

There's no real reason why actor tests should be slow, but if you create an ActorSystem for every test, and use Thread.sleep and/or Await.result everywhere, then of course it'll be slower. This is mainly due to the silly structure imposed by testing frameworks that expect a test to be synchronous, would be much better if you could return a Future[TestResult].

What do you mean by parallelizing being impossible? Our test suite is run in parallel (takes less then half a minute on a beefy box, compared to 10 minutes for sequential execution). And we create one ActorSystem per test class. The only thing to watch out for is not to bind to hard-coded ports in the tests, i.e. always configure remoting on port zero.

You're running the suites in parallel.  A single suite will run sequentially, no?  When we're focusing on a single class, and are doing test-only, it's a sequential test.
 

I don’t get the comment about exposing specific guardians, could you please explain?

Something like:

"test1" in {
  val a = system.actorOf(..., "name")
  // creates in /user/guardian1/name
}
"test2" in {
  val a = system.actorOf(..., "name")
  // creates in /user/guardian2/name
}

I understand the problems when people look up via "/user/name", of course... this isn't a real solution :)

[Derek Wyatt]

On Thu, May 24, 2012 at 2:48 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:

Hi Derek!

On Thu, May 24, 2012 at 2:38 PM, Derek Wyatt <de...@derekwyatt.org> wrote:

Before I start griping, it needs to be said that Akka 2.0 is a major step forward.  It's a great piece of software and the team should be commended.

I think the biggest stumbling block is the imposed Actor hierarchy.  All in all it's a good thing, don't get me wrong, but it's the first real thing that Akka has done that "gets in my way", and in a round-about way it seems to be what Christer has hit as well.

- I wanted to use Deploy because it's such a great and easy way to launch Actors remotely, but I didn't want it in the same ActorSystem.  I had to cook up my own way of doing it.  Can we see the Guardian code exposed some how to make this easier to do?

WDYM?

If I want to create an Actor on machine "X" outside of my ActorSystem, then I have to send a message to "something" on machine "X" that makes the Actor and sends me the reference.  Obviously something already does this (since it has to for Deploy).  All I'm suggesting is that we get access to that, already correct, functionality.
 

- Some examples regarding the layout of Actors in the ActorSystem would also be nice.  "Bushy" trees are bad, but how bushy is too bushy?  Is it only lookup that is hurt by the bushiness or is it something else?

The only thing I've ever stated clearly is "do not create too many top level actors" this is mainly due to the fact that the fault-tolreance part is shot to shit since any malfunctioning piece risks taking everything down.

Ah, I was under the impression that it made for slower functionality. Bushiness makes for big "children" structures and thus increases the searching time.  So what you're saying is that I can create a /user/MobileDevices and then create 2 million children of that and everything's cool?  That would be awesome.  In many cases I am not concerned with hierarchy at all.  I just need to represent a ton of "stuff" out there in the world and the "world" doesn't have a natural hierarchy that I can use to make a non-busy tree.  Thus, if I want to spread things down the tree I have to make an artificial set of inner nodes.

But again, if you're saying that's cool, then I'm a happy dood.
 

- Can we get a fast lookup tool for Actors?  Further to Christer's issue on naming, if the user is diligent and uses unique names for everything, then from their point of view the path isn't relevant for uniqueness.  Lookup is a simple hash table in that case.

You can easily do this yourself by having each actor register themselves in a global registry (actor/object/or so). Don't think we want to do this as default since it will be quite costly to do.

And my claim is that many people might want this.  If we could get it by a simple mixin of our Actor, then that might be a nice feature.
 

WDYM?

 

- We've heard that many ActorSystems is "bad".  Specifically knowing "why" would be a good thing, I think.

It's bad because it's a heavyweight structure, it will allocate threads for the scheduler, the dispatchers etc, and as you all know, you can't create infinite threads.

We're making some progress regarding this for 2.1 where you'll be able to reuse the same EC for many ActorSystems (with the downside that they'll be stepping on eachotehrs toes if you are not careful), but I don't see how we'll ever get away from having one thread per scheduler.

OK, can this maybe go in the docs?
 

- Given that the hierarchy is there, and we have some restrictions on how the hierarchy is built up, we may find that we have to insert a number of "invisible" nodes to satisfy that hierarchy - e.g. when something becomes too bushy, we need to insert a layer of artificial parent nodes that increase the depth of the tree.  It would be nice if Akka supplied some of these.  For example, "Supervisor-only".

No, you don't need to do that, just keep the root clean so you have a reasonable fault tolerance strategy. Also, creating top-level actors is currently a blocking operation since it's done from outside the guardian, there is a ticket to work around this by cheating, but it has yet to be implemented, but is slated for Mingus.

See above.  I think I'm happy, assuming /user/MobileDevices can be the parent of a couple of million children.
 

- The structure of the hierarchy can make applications brittle as the hierarchy gets shuffled around - assuming you're looking up by path.  If we insert nodes into the hierarchy then the paths change.  Can we get a more flexible lookup scheme?  For example, I posted a piece of code a while back that was called "FindAncestor".  This helps when, what was the parent, becomes the grandparent due to a supervisor that was put in the middle.  FindAncestor finds the "parent" either way.

This is already possible using relative lookups in actorFor, no?

Not that I'm aware of.  "context.actorFor(../../)" is different than "context.actorFor(../../../)".  When I insert something in the tree, my actor should be doing ../../../ instead of ../../, but it doesn't know that, and since it's getting only an ActorRef, clearly the compiler can't help me.  I claim it might be better to have "context.actorForAncesestorNamed(guy above me)".
 

- Actor tests tend to be "slow" compared to standard unit tests, where a hundred or so should run in about a second.  Parallelizing Actor tests isn't possible using the examples placed in the documentation.  It would be nice to see some strategies for speeding up these tests with some parallelism.  I've done a bit of work here and it works out well, but it does it by using many ActorSystems.  It might be nice to have the TestKit expose the different "systems" to each test (but obviously not all different ActorSystems) that have a specific User Guardian.  Generally this is where we hit problems with parallelism because we have multiple tests working with the same Actor path.  If we could make the paths unique within the same system by introducing test-specific guardians, that might help (?).

There's no real reason why actor tests should be slow, but if you create an ActorSystem for every test, and use Thread.sleep and/or Await.result everywhere, then of course it'll be slower. This is mainly due to the silly structure imposed by testing frameworks that expect a test to be synchronous, would be much better if you could return a Future[TestResult].

They're absolutely slower when you have message passing.  It can be one or two orders of magnitude slower.  If you have "addTen(5) must be (15)" then this is way faster than "expectMsg(AddTenResult(15))".  Now multiply that by 100 tests.  The time to compile and test is now getting to be far longer than it takes me to make code changes to be tested.  It hurts the edit-compile-test cycle.
 

I think that's it for now :)

Excellent feedback, thanks!

Cheers,
Derek
 

[Derek Wyatt]

On 24 May 2012 10:40, √iktor Ҡlang <viktor...@gmail.com> wrote:

For any of the casual readers of this discussion,

this is exactly the sort of feedback that is needed since this really shows what painpoints people have,

so feel free to chime in, there is no "wrongs" here.

On Thu, May 24, 2012 at 4:29 PM, Derek Wyatt <de...@derekwyatt.org> wrote:

On 24 May 2012 10:12, √iktor Ҡlang <viktor...@gmail.com> wrote:

On Thu, May 24, 2012 at 4:00 PM, Derek Wyatt <de...@derekwyatt.org> wrote:

On Thu, May 24, 2012 at 2:48 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:

Hi Derek!

On Thu, May 24, 2012 at 2:38 PM, Derek Wyatt <de...@derekwyatt.org> wrote:

Before I start griping, it needs to be said that Akka 2.0 is a major step forward.  It's a great piece of software and the team should be commended.

I think the biggest stumbling block is the imposed Actor hierarchy.  All in all it's a good thing, don't get me wrong, but it's the first real thing that Akka has done that "gets in my way", and in a round-about way it seems to be what Christer has hit as well.

- I wanted to use Deploy because it's such a great and easy way to launch Actors remotely, but I didn't want it in the same ActorSystem.  I had to cook up my own way of doing it.  Can we see the Guardian code exposed some how to make this easier to do?

WDYM?

If I want to create an Actor on machine "X" outside of my ActorSystem, then I have to send a message to "something" on machine "X" that makes the Actor and sends me the reference.  Obviously something already does this (since it has to for Deploy).  All I'm suggesting is that we get access to that, already correct, functionality.

The idea is to avoid creating actors from the outside, since that is by natura a racy operation, which is also why system.actorOf is problematic

Well, I couldn't avoid it :)  And yes, it was tricky and not 100% correct, I'm sure.  This is why I'm saying that the imposed hierarchy is the biggest impact (or so it would seem).  If it's problematic, and I can't avoid it, then I'm probably going to screw it up.  I was hoping that the experts could help me not screw it up.

Comparing the imposed structure with what we had before, when very few would ever use a supervisor I think we've greatly improved on the default quality of Actor code,

of course there is more work to be done!

Like I said in the beginning... it's a good thing, all things considered.  But it really is the first time I've thought that Akka "gets in my way".  Done.
 

 

 

 

- Some examples regarding the layout of Actors in the ActorSystem would also be nice.  "Bushy" trees are bad, but how bushy is too bushy?  Is it only lookup that is hurt by the bushiness or is it something else?

The only thing I've ever stated clearly is "do not create too many top level actors" this is mainly due to the fact that the fault-tolreance part is shot to shit since any malfunctioning piece risks taking everything down.

Ah, I was under the impression that it made for slower functionality. Bushiness makes for big "children" structures and thus increases the searching time.  So what you're saying is that I can create a /user/MobileDevices and then create 2 million children of that and everything's cool?

It's backed by a tree, so you have O(log N) access to kids

 

  That would be awesome.  In many cases I am not concerned with hierarchy at all.  I just need to represent a ton of "stuff" out there in the world and the "world" doesn't have a natural hierarchy that I can use to make a non-busy tree.

The tree is for fault-tolerance, thinking about the failure hierarchy of your system makes it a lot easier to structure it.

 

  Thus, if I want to spread things down the tree I have to make an artificial set of inner nodes.

But again, if you're saying that's cool, then I'm a happy dood.

You shouldn't optimize prematurely. We're doing that for you. All we ask is that you keep root actors to a minimum, think about your failure hierarchy and try to create Actors and have them stopped when they are obsolete.

Well, I wasn't trying to optimize prematurely.  I was reacting to, what I thought was, an issue with bushy trees that already existed.

Would you mind doing a quick test to verify if it's a problem or not? (trying to wrap up the binary compat work I've been doing the past week)

Sure.  I'll have to get back to my decent machine before I can get any reasonable feel for it though... it'll take a while as I'm nowhere near it now.  Next week.
 

 

 

- Can we get a fast lookup tool for Actors?  Further to Christer's issue on naming, if the user is diligent and uses unique names for everything, then from their point of view the path isn't relevant for uniqueness.  Lookup is a simple hash table in that case.

You can easily do this yourself by having each actor register themselves in a global registry (actor/object/or so). Don't think we want to do this as default since it will be quite costly to do.

And my claim is that many people might want this.  If we could get it by a simple mixin of our Actor, then that might be a nice feature.

Create an Extension and I'll reference it in the docs!

 

 

WDYM?

 

- We've heard that many ActorSystems is "bad".  Specifically knowing "why" would be a good thing, I think.

It's bad because it's a heavyweight structure, it will allocate threads for the scheduler, the dispatchers etc, and as you all know, you can't create infinite threads.

We're making some progress regarding this for 2.1 where you'll be able to reuse the same EC for many ActorSystems (with the downside that they'll be stepping on eachotehrs toes if you are not careful), but I don't see how we'll ever get away from having one thread per scheduler.

OK, can this maybe go in the docs?

Sure, will land in master ASAP.

 

 

- Given that the hierarchy is there, and we have some restrictions on how the hierarchy is built up, we may find that we have to insert a number of "invisible" nodes to satisfy that hierarchy - e.g. when something becomes too bushy, we need to insert a layer of artificial parent nodes that increase the depth of the tree.  It would be nice if Akka supplied some of these.  For example, "Supervisor-only".

No, you don't need to do that, just keep the root clean so you have a reasonable fault tolerance strategy. Also, creating top-level actors is currently a blocking operation since it's done from outside the guardian, there is a ticket to work around this by cheating, but it has yet to be implemented, but is slated for Mingus.

See above.  I think I'm happy, assuming /user/MobileDevices can be the parent of a couple of million children.

Please try and report back!

 

 

- The structure of the hierarchy can make applications brittle as the hierarchy gets shuffled around - assuming you're looking up by path.  If we insert nodes into the hierarchy then the paths change.  Can we get a more flexible lookup scheme?  For example, I posted a piece of code a while back that was called "FindAncestor".  This helps when, what was the parent, becomes the grandparent due to a supervisor that was put in the middle.  FindAncestor finds the "parent" either way.

This is already possible using relative lookups in actorFor, no?

Not that I'm aware of.  "context.actorFor(../../)" is different than "context.actorFor(../../../)".  When I insert something in the tree, my actor should be doing ../../../ instead of ../../, but it doesn't know that, and since it's getting only an ActorRef, clearly the compiler can't help me.  I claim it might be better to have "context.actorForAncesestorNamed(guy above me)".

What if you change the ancestors name?

I wasn't.  The point is moot.  I changed the hierarchy, not the name.

But if you change the hierarchy you might as well change names, right? I'm just saying that if you change stuff, you'll have to change stuff :-)

No, I wouldn't change the names.  I'm not interested in "where" this thing is... I'm interested in the "the thing".  You have to remember that names are really all we have.  We can't use types (and I don't want types here... I want the ActorRef since typing is death for Actors), so names are critical.  Position in the hierarchy is an Akka-imposed thing that I might want to ignore.
 

 

 

 

 

- Actor tests tend to be "slow" compared to standard unit tests, where a hundred or so should run in about a second.  Parallelizing Actor tests isn't possible using the examples placed in the documentation.  It would be nice to see some strategies for speeding up these tests with some parallelism.  I've done a bit of work here and it works out well, but it does it by using many ActorSystems.  It might be nice to have the TestKit expose the different "systems" to each test (but obviously not all different ActorSystems) that have a specific User Guardian.  Generally this is where we hit problems with parallelism because we have multiple tests working with the same Actor path.  If we could make the paths unique within the same system by introducing test-specific guardians, that might help (?).

There's no real reason why actor tests should be slow, but if you create an ActorSystem for every test, and use Thread.sleep and/or Await.result everywhere, then of course it'll be slower. This is mainly due to the silly structure imposed by testing frameworks that expect a test to be synchronous, would be much better if you could return a Future[TestResult].

They're absolutely slower when you have message passing.  It can be one or two orders of magnitude slower.  If you have "addTen(5) must be (15)" then this is way faster than "expectMsg(AddTenResult(15))".  Now multiply that by 100 tests.  The time to compile and test is now getting to be far longer than it takes me to make code changes to be tested.  It hurts the edit-compile-test cycle.

Since an Actor can do approx 3million messages per second on my machine, the difference in time, even if you have hundreds of tests, should be negligible, unless you're ceating ActorSystems & do blocking ops (or other potentially costly initialization logic)

Well, I'm telling you that I saw an increase when I went parallel.  You asked for feedback, I'm giving it to you :)

Absolutely! This feedback is great, but without proof that this is an issue, it's hard for me to fix anything, I just know that our internal tests are highly parallel and benefit greatly from beefier hardware, so it's working out really well for us. If you have an example to show I'd love to have a stab at it!

I'll try to throw something together soon and put it on github.

You have to remember the testing philosophy - FAST.  And fast means milliseconds, not seconds.  I can code fast - seconds between writes at times - and if it takes longer to get feedback on my changes than it takes me to code those changes, then something's wrong.  In those cases, I want to parallelize.  It's not all the time, and it's very targeted stuff.  ScalaTest lets me do it, and so does Akka, since I can pus the TestKit down from the suite to the test, thus isolating it completely.  The weight of the ActorSystem, however, makes it go a little slower than it would otherwise.
 

[Jonas Bonér]

On Thu, May 24, 2012 at 4:00 PM, Derek Wyatt <de...@derekwyatt.org> wrote:

On Thu, May 24, 2012 at 2:48 PM, √iktor Ҡlang <viktor...@gmail.com> wrote:

Hi Derek!

On Thu, May 24, 2012 at 2:38 PM, Derek Wyatt <de...@derekwyatt.org> wrote:

Before I start griping, it needs to be said that Akka 2.0 is a major step forward.  It's a great piece of software and the team should be commended.

I think the biggest stumbling block is the imposed Actor hierarchy.  All in all it's a good thing, don't get me wrong, but it's the first real thing that Akka has done that "gets in my way", and in a round-about way it seems to be what Christer has hit as well.

- I wanted to use Deploy because it's such a great and easy way to launch Actors remotely, but I didn't want it in the same ActorSystem.  I had to cook up my own way of doing it.  Can we see the Guardian code exposed some how to make this easier to do?

WDYM?

If I want to create an Actor on machine "X" outside of my ActorSystem, then I have to send a message to "something" on machine "X" that makes the Actor and sends me the reference.  Obviously something already does this (since it has to for Deploy).  All I'm suggesting is that we get access to that, already correct, functionality.
 

- Some examples regarding the layout of Actors in the ActorSystem would also be nice.  "Bushy" trees are bad, but how bushy is too bushy?  Is it only lookup that is hurt by the bushiness or is it something else?

The only thing I've ever stated clearly is "do not create too many top level actors" this is mainly due to the fact that the fault-tolreance part is shot to shit since any malfunctioning piece risks taking everything down.

Ah, I was under the impression that it made for slower functionality. Bushiness makes for big "children" structures and thus increases the searching time.  So what you're saying is that I can create a /user/MobileDevices and then create 2 million children of that and everything's cool?  That would be awesome.  In many cases I am not concerned with hierarchy at all.  I just need to represent a ton of "stuff" out there in the world and the "world" doesn't have a natural hierarchy that I can use to make a non-busy tree.  Thus, if I want to spread things down the tree I have to make an artificial set of inner nodes.

But again, if you're saying that's cool, then I'm a happy dood.

Sure. If you create actors with 'context.actorOf' then it is all fine. Create as many as you like.

 

 

- Can we get a fast lookup tool for Actors?  Further to Christer's issue on naming, if the user is diligent and uses unique names for everything, then from their point of view the path isn't relevant for uniqueness.  Lookup is a simple hash table in that case.

You can easily do this yourself by having each actor register themselves in a global registry (actor/object/or so). Don't think we want to do this as default since it will be quite costly to do.

And my claim is that many people might want this.  If we could get it by a simple mixin of our Actor, then that might be a nice feature.

Sure. A mixin could solve this easily. Could be useful. Perhaps something for akka.patterns. Feel free to provide an implementation. Add a ticket and we can discuss there. 

  

 

WDYM?

 

- We've heard that many ActorSystems is "bad".  Specifically knowing "why" would be a good thing, I think.

It's bad because it's a heavyweight structure, it will allocate threads for the scheduler, the dispatchers etc, and as you all know, you can't create infinite threads.

We're making some progress regarding this for 2.1 where you'll be able to reuse the same EC for many ActorSystems (with the downside that they'll be stepping on eachotehrs toes if you are not careful), but I don't see how we'll ever get away from having one thread per scheduler.

OK, can this maybe go in the docs?

Is it not already well documented? 

 

 

- Given that the hierarchy is there, and we have some restrictions on how the hierarchy is built up, we may find that we have to insert a number of "invisible" nodes to satisfy that hierarchy - e.g. when something becomes too bushy, we need to insert a layer of artificial parent nodes that increase the depth of the tree.  It would be nice if Akka supplied some of these.  For example, "Supervisor-only".

No, you don't need to do that, just keep the root clean so you have a reasonable fault tolerance strategy. Also, creating top-level actors is currently a blocking operation since it's done from outside the guardian, there is a ticket to work around this by cheating, but it has yet to be implemented, but is slated for Mingus.

See above.  I think I'm happy, assuming /user/MobileDevices can be the parent of a couple of million children.
 

- The structure of the hierarchy can make applications brittle as the hierarchy gets shuffled around - assuming you're looking up by path.  If we insert nodes into the hierarchy then the paths change.  Can we get a more flexible lookup scheme?  For example, I posted a piece of code a while back that was called "FindAncestor".  This helps when, what was the parent, becomes the grandparent due to a supervisor that was put in the middle.  FindAncestor finds the "parent" either way.

This is already possible using relative lookups in actorFor, no?

Not that I'm aware of.  "context.actorFor(../../)" is different than "context.actorFor(../../../)".  When I insert something in the tree, my actor should be doing ../../../ instead of ../../, but it doesn't know that, and since it's getting only an ActorRef, clearly the compiler can't help me.  I claim it might be better to have "context.actorForAncesestorNamed(guy above me)".

I agree that it could be useful to layer some richer query functionality on top of the current API. 

Suggestions welcome. Perhaps even search. Add a ticket and we can discuss there. 

[Jonas Bonér]

Discuss here: http://www.assembla.com/spaces/akka/tickets/2127-create-a-dsl-for-creating-middle-man-supervisors-in-an-actor-hierarchy

--
Jonas Bonér
CTO

Typesafe - The software stack for applications that scale

[Jonas Bonér]

...and brainstorm richer actor querying/selection/navigation here: http://www.assembla.com/spaces/akka/tickets/2128-research-richer-querying-api-for-navigating-finding-actors-in-a-hierarchy
(no promise anything will get implemented though :-) 

[srparish]

+ always having to wrap my actors in 'Props()' even though i've never needed to change a prop seems arbitrary and annoying

+ keep forgetting it log.warning() instead of log.warn() like most other loggers i've used

+ it took me an embarrassingly long time to realize that if i run system.shutdown() i can ctrl-d back to sbt rather then having to killall -9 java

+ ByteString seems too slow for my needs, sad because i love the IO api (Vector.apply() shows up a lot under jvisualvm)

+ having an exponential backoff option for OneForOne and AllForOne would be really handy

[Jason Mason]

2.0.x has been a big improvement over 1.x, thank you! 

the most prominent suggestion i'd have is:

a registry (or section in the documentation or samples) of common usage patterns. 

i'd venture to say actor based programming is a paradigm shift for many looking at akka, such a registry can only aid adoption. 

[Jonas Bonér]

On Fri, May 25, 2012 at 7:18 AM, Jason Mason <jason....@gmail.com> wrote:

2.0.x has been a big improvement over 1.x, thank you! 

the most prominent suggestion i'd have is:

a registry (or section in the documentation or samples) of common usage patterns. 

I agree. We have completed some patterns already and have some tickets for more. 

Help out define common patterns and idioms. Both ideas and code.

http://www.assembla.com/spaces/akka/search?utf8=%E2%9C%93&object_scope=60&q=patterns

 

i'd venture to say actor based programming is a paradigm shift for many looking at akka, such a registry can only aid adoption. 

--

You received this message because you are subscribed to the Google Groups "Akka User List" group.

To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/3ZLTkQheXd8J.

To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

--
Jonas Bonér
CTO

Typesafe - The software stack for applications that scale

[Jonas Boner]

On Fri, May 25, 2012 at 6:13 AM, srparish <srpa...@gmail.com> wrote:
> + always having to wrap my actors in 'Props()' even though i've never needed
> to change a prop seems arbitrary and annoying

The idea is that you have the possibility to reuse and extend Props.
It is just 7 chars more don't think it is that bad:

actorOf[T]
actorOf(Props[T])

Not sure that justifies a special case.

> + keep forgetting it log.warning() instead of log.warn() like most other
> loggers i've used
> + it took me an embarrassingly long time to realize that if i run
> system.shutdown() i can ctrl-d back to sbt rather then having to killall -9
> java

Could be documented. Write up a snippet and we'll add it to the docs. Thanks.

> + ByteString seems too slow for my needs, sad because i love the IO api
> (Vector.apply() shows up a lot under jvisualvm)

Well, safety has a (small) price. You can of course send Array[Byte]
around if you like.

> + having an exponential backoff option for OneForOne and AllForOne would be
> really handy

I agree it would be nice. The strategy is pluggable. If you have time:
contribute it. Or add a ticket with your ideas.

Good feedback. Thank you.

> --
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/akka-user/-/VxiowC5cZS8J.

>
> To post to this group, send email to akka...@googlegroups.com.
> To unsubscribe from this group, send email to
> akka-user+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/akka-user?hl=en.



--
Jonas Bonér
CTO

Typesafe - The software stack for applications that scale

[Jonas Boner]

http://www.assembla.com/spaces/akka/tickets/2132-investigate-in-an-exponential-backoff-policy-for-the-supervisor-strategies

[Roland Kuhn]

25 maj 2012 kl. 10:10 skrev Jonas Boner:

> On Fri, May 25, 2012 at 6:13 AM, srparish <srpa...@gmail.com> wrote:
>> + always having to wrap my actors in 'Props()' even though i've never needed
>> to change a prop seems arbitrary and annoying
>
> The idea is that you have the possibility to reuse and extend Props.
> It is just 7 chars more don't think it is that bad:
>
> actorOf[T]
> actorOf(Props[T])
>
> Not sure that justifies a special case.
>

We used to have lots of overloaded variants of one of the most important methods in the toolkit, which was causing quite some grief. Reducing that to two (i.e. with or without an explicit name) has been an improvement, I would say. Also, if you hate dots you can say

context actorOf Props[T]

which even is shorter than the otherwise required

context actorOf manifest[T]

(if you are into that sort of thing ;-) )

>> + keep forgetting it log.warning() instead of log.warn() like most other
>> loggers i've used
>> + it took me an embarrassingly long time to realize that if i run
>> system.shutdown() i can ctrl-d back to sbt rather then having to killall -9
>> java
>
> Could be documented. Write up a snippet and we'll add it to the docs. Thanks.
>
>> + ByteString seems too slow for my needs, sad because i love the IO api
>> (Vector.apply() shows up a lot under jvisualvm)
>
> Well, safety has a (small) price. You can of course send Array[Byte]
> around if you like.
>

Wasn’t there an improvement under way? https://github.com/akka/akka/pull/462

>> + having an exponential backoff option for OneForOne and AllForOne would be
>> really handy
>
> I agree it would be nice. The strategy is pluggable. If you have time:
> contribute it. Or add a ticket with your ideas.
>

Yes, would be interesting to see what can be done here. But don’t use Thread.sleep(), please!

Regards,

Roland

Roland Kuhn
Typesafe – The software stack for applications that scale.
twitter: @rolandkuhn

[√iktor Ҡlang]

Hi,

On Fri, May 25, 2012 at 6:13 AM, srparish <srpa...@gmail.com> wrote:

+ always having to wrap my actors in 'Props()' even though i've never needed to change a prop seems arbitrary and annoying

That I can understand, however, the alternative is to use overloading, which Scala really doesn't shine at. With Props we can add new stuff in the future without risking to break user code. (actorOf should be quite frequently used)

 

+ keep forgetting it log.warning() instead of log.warn() like most other loggers i've used

Ah, good one! Happens to me at times as well. Sort of seems a bit unintuitive considering "info" is not "inform"/"information"

 

+ it took me an embarrassingly long time to realize that if i run system.shutdown() i can ctrl-d back to sbt rather then having to killall -9 java

That's a good tip, we should add that to the ActorSystem docs.

 

+ ByteString seems too slow for my needs, sad because i love the IO api (Vector.apply() shows up a lot under jvisualvm)

Work has been done there, in two steps. First step is already in master, second step is in a Pull Request, so that'll improve shortly.

 

+ having an exponential backoff option for OneForOne and AllForOne would be really handy

Yeah, there's a ticket for that, please feel encouraged to take a stab at it!

Cheers,

√

 

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.

To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/VxiowC5cZS8J.

To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

[Scott Parish]

On Fri, May 25, 2012 at 3:10 AM, Jonas Boner <jo...@jonasboner.com> wrote:

On Fri, May 25, 2012 at 6:13 AM, srparish <srpa...@gmail.com> wrote:
> + always having to wrap my actors in 'Props()' even though i've never needed
> to change a prop seems arbitrary and annoying

The idea is that you have the possibility to reuse and extend Props.
It is just 7 chars more don't think it is that bad:

actorOf[T]
actorOf(Props[T])

Not sure that justifies a special case.

I keep forgetting to import it. Not a big deal, i'm getting use to it.

By the way, most of the things i listed feel fairly whiny. For the most park akka 2 is extremely well thought out, so it's hard to think of flaws that aren't petty or bike sheds.

[Scott Parish]

Also, if you hate dots you can say

context actorOf Props[T]

which even is shorter than the otherwise required

context actorOf manifest[T]

(if you are into that sort of thing ;-) )

I haven't gotten into that too much. I think it's because it's so close to being haskell, without actually having point-free style. ;) 

[Scott Parish]

>> + ByteString seems too slow for my needs, sad because i love the IO api
>> (Vector.apply() shows up a lot under jvisualvm)
>
> Well, safety has a (small) price. You can of course send Array[Byte]
> around if you like.
>

Wasn’t there an improvement under way? https://github.com/akka/akka/pull/462

Awesome, that exactly describes what i was trying to do: parse large chunks of binary data being streamed in.

[Jonas Bonér]

No worries. We asked for whining. You provided it. Everyone is happy. Thank you. 

 

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.

To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

[√iktor Ҡlang]

On Fri, May 25, 2012 at 2:32 PM, Jonas Bonér <jo...@jonasboner.com> wrote:

On Fri, May 25, 2012 at 2:18 PM, Scott Parish <srpa...@gmail.com> wrote:

On Fri, May 25, 2012 at 3:10 AM, Jonas Boner <jo...@jonasboner.com> wrote:

On Fri, May 25, 2012 at 6:13 AM, srparish <srpa...@gmail.com> wrote:
> + always having to wrap my actors in 'Props()' even though i've never needed
> to change a prop seems arbitrary and annoying

The idea is that you have the possibility to reuse and extend Props.
It is just 7 chars more don't think it is that bad:

actorOf[T]
actorOf(Props[T])

Not sure that justifies a special case.

I keep forgetting to import it. Not a big deal, i'm getting use to it.

By the way, most of the things i listed feel fairly whiny. For the most park akka 2 is extremely well thought out, so it's hard to think of flaws that aren't petty or bike sheds.

No worries. We asked for whining. You provided it. Everyone is happy. Thank you. 

 

+1

And also, one should always be able to reason about why things are as they are.

Cheers,

√

 

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

--
Jonas Bonér
CTO
Typesafe - The software stack for applications that scale
Phone: +46 733 777 123
Twitter: @jboner

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

--

Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Scott Parish]

Scheduler returns Cancellable. Cancellable isn't thread-safe, and only tells you if it's already been canceled or not. It would be much nicer if it could tell you if it is too late to cancel. This is fine for best effort, but for some situations one needs to know if you successfully canceled the action or not. I worked around this by "pure evil": I passed an AtomicBoolean in the message and held onto it locally so the remote and local actors could race to cancel or perform the action. Would be much nicer if that was built into Cancellable.

Thanks

sRp

[√iktor Ҡlang]

On Fri, May 25, 2012 at 3:17 PM, Scott Parish <srpa...@gmail.com> wrote:

Scheduler returns Cancellable. Cancellable isn't thread-safe, and only tells you if it's already been canceled or not. It would be much nicer if it could tell you if it is too late to cancel. This is fine for best effort, but for some situations one needs to know if you successfully canceled the action or not. I worked around this by "pure evil": I passed an AtomicBoolean in the message and held onto it locally so the remote and local actors could race to cancel or perform the action. Would be much nicer if that was built into Cancellable.

Cancellable is only for signalling, essentially just giving you access to avoid work being done. It's deliberately as it is to avoid having to do roundtrips if the scheduler is clustered/remote.

(The impl is also changed in master)

Cheers,
√

 

Thanks

sRp

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

[Scott Parish]

Even if the job was remote, it seems it should be possible to have a form of cancel() that would return a Future[Boolean] of if you successfully cancelled or if it already fired. I'd gladly take the extra round trips for the cases i need it (if it were optional)

[√iktor Ҡlang]

On Fri, May 25, 2012 at 3:24 PM, Scott Parish <srpa...@gmail.com> wrote:

Even if the job was remote, it seems it should be possible to have a form of cancel() that would return a Future[Boolean] of if you successfully cancelled or if it already fired. I'd gladly take the extra round trips for the cases i need it (if it were optional)

Scott, yes, I'm not saying it's impossible, I'm just saying it's that sort of consensus operations that make systems scale poorly, so we avoid it.

You can always create a Scheduler that has stricter guarantees.

Cheers,

√

[Scott Parish]

On Fri, May 25, 2012 at 8:31 AM, √iktor Ҡlang <viktor...@gmail.com> wrote:

On Fri, May 25, 2012 at 3:24 PM, Scott Parish <srpa...@gmail.com> wrote:

Even if the job was remote, it seems it should be possible to have a form of cancel() that would return a Future[Boolean] of if you successfully cancelled or if it already fired. I'd gladly take the extra round trips for the cases i need it (if it were optional)

Scott, yes, I'm not saying it's impossible, I'm just saying it's that sort of consensus operations that make systems scale poorly, so we avoid it.

You can always create a Scheduler that has stricter guarantees.

True, i've also been wanting to make a scheduler that's more tuned for lower volume, higher precision events. Just a matter of time and priorities... ;) 

[√iktor Ҡlang]

That's dead easy, just do an Akka Extension. No need to replace the builtin one, it's optimized for what it's mostly used for, then people can choose to run higher priority, exact firing stuff through the Extension.

Cheers,

√

 

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

[Jason Mason]

the logging API is a bit strange, why not mirror the SLF4J API ?

for instance if you neglect to read the API docs and use the customary log.error(string, throwable), you will get your string and some cryptic message: "WARNING arguments left: 1". 

log.error(throwable, string) is not intuitive. also, why are there no exception logging at other log levels? 

</whine> :)

[Veebs]

Hi,

This is a very minor comment.

I got confused with dispatchers and thread pools.

Would it be possible to have the dispatcher name somehow be placed in the thread name to which it belongs?

Regards

Vibul

On Thursday, 24 May 2012 22:00:07 UTC+10, √ wrote:

Dear hAkkers,

Now it's almost been 3 months since we released Akka 2.0, and we, the committers would really appreciate

getting some feedback on what your experiences have been during the past months.

If you cannot share this publically, please feel free to send the feedback to me personally and I'll keep it confidential.

Elicitinguser feedback is the key ingredient in making sure that Akka evolves in the right direction and that problems are

taken care of.

Looking forward to hearing about your Akka 2.0 experiences!

Cheers,

√

[Roland Kuhn]

Hi Vibul,

seems to work fine:

Welcome to Scala version 2.9.2 (Java HotSpot(TM) 64-Bit Server VM, Java 1.7.0_04).

Type in expressions to have them evaluated.

Type :help for more information.

scala> import akka.actor._

import akka.actor._

scala> import com.typesafe.config._

import com.typesafe.config._

scala> ConfigFactory.parseString("myPreciouss.type=Dispatcher")

res0: com.typesafe.config.Config = Config(SimpleConfigObject({"myPreciouss" : {"type" : "Dispatcher"}}))

scala> val sys = ActorSystem("skynet", res0)

sys: akka.actor.ActorSystem = akka://skynet

scala> val one = sys.actorOf(Props(new Actor with ActorLogging { def receive = { case x => log.warning("received {}", x) }}), "one")

one: akka.actor.ActorRef = Actor[akka://skynet/user/one]

scala> val two = sys.actorOf(Props(new Actor with ActorLogging { def receive = { case x => log.warning("received {}", x) }}).withDispatcher("myPreciouss"), "two")

two: akka.actor.ActorRef = Actor[akka://skynet/user/two]

scala> one ! 42

scala> [WARN] [05/26/2012 09:37:24.608] [skynet-akka.actor.default-dispatcher-6] [akka://skynet/user/one] received 42

scala> two ! 23

scala> [WARN] [05/26/2012 09:37:29.797] [skynet-myPreciouss-1] [akka://skynet/user/two] received 23

Regards,

Roland

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.

To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/RPJ0HgMbQtoJ.

To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

Roland Kuhn
Typesafe – The software stack for applications that scale.
twitter: @rolandkuhn

[Roland Kuhn]

Hi Jason,

the reason is consistency (within Akka’s logging API, I mean) and caution (wrt. staying away from the “grey area” around overload resolution). The String argument is always required and may contain "{}" markers, which are satisfied by supplying additional Any arguments, which would happily also match a Throwable. So to be completely safe, put the Throwable first, so that it cannot be mistaken for a String. That is also more consistent because otherwise it would be interjected between the format string and its arguments, which does not happen for the non-error levels.

You can still log exceptions at WarningLevel, you only have to transform them to strings yourself. It would be possible to add a log.warning(Throwable, String) variant, though, but isn’t an exception which you deem important enough to log not always an error? We could continue the philosophical discussions over a pull request ;-)

Regards,

Roland

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.

To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/yfdFZ4mFJ74J.

To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

[Roland Kuhn]

25 maj 2012 kl. 10:45 skrev √iktor Ҡlang:

 

+ keep forgetting it log.warning() instead of log.warn() like most other loggers i've used

Ah, good one! Happens to me at times as well. Sort of seems a bit unintuitive considering "info" is not "inform"/"information"

Well, using verbs would mean

debug, inform, warn, err?

Using nouns would be

glitch, incident, warning, error

and the log levels are

DEBUG, INFO, WARN, ERROR

where WARN sounds like the odd one out, and I only went for it to save three letters in the output. I agree that it is not fully consistent currently, so what shall we do?

Regards,

Roland Kuhn
Typesafe – The software stack for applications that scale.
twitter: @rolandkuhn

[tim8dev]

Hi, first of all: Akka 2.0 is awesome!

After heart about Stash "by accident" here on the mailing list. I would like to ask for more documentation in Akka. If somebody quickly points me to the place where I would be able to write, I would be happy to do that.

Actually, I was trying to implement Stash by myself, before I used it. But of course, I didn't used the Dequeue Mailbox so I actually tried to process the messages directly by invoking receive(msg), but then I had to mess around with sender. So great that there is Stash and you/we should point it out in the doc.

One small question, though: Why use Vector and not List or ListBuffer. The Stash is a stack, so we don't need random access but only need fast append xor prepend, so why not List?

Regards
Tim

[√iktor Ҡlang]

List is more expensive for nontrivial uses.

Cheers,
V

>
> Regards
> Tim

>
> --
> You received this message because you are subscribed to the Google Groups "Akka User List" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/YcU9SBBDSkwJ.

[Joa Ebert]

Hey,

a little bit late to the party but since I did not work with Akka 1.0 and started using 2.0 without any prior experience with the framework here are my findings.

First of all I must say that not only Akka is awesome but the documentation is fantastic. Most of the time all my questions are answered via the docs and it is not necessary to ask on the mailing list.

There are only smaller issues that I currently face using Akka:

- Best practices

It would be really nice to have some more real world examples and best practices. In particular I would love to see more strategies for handling failure.  For instance I have two actors, A sends a message to B and does something when B replies back to A. Of course I could use a Future but since there is some overhead involved I do not want to use it and rather go with the more lightweight fire-and-forget approach. However the question is when should I go for a Future, when is fire-and-forget better. Should A start a timer and dispatch a message to itself to consider B dead if no message is received within x amount of time?

I know that this needs to be answered on a case by case basis but a general hint and how to approach those issues would be nice.

Another problem I have is the code structure. Maybe it is a question of taste but it would be great to have some kind of standard on how to organize actors and their messages. For instance a) put messages in a companion object or b) put actor and messages in the same package. What happens if multiple actors share the same message type?

- Get or Create

The main issue I currently face and without a solution is: how do I get or create an actor, especially when it happens in a cluster. This is mostly again an issue with the first statement about best practices and failure handling. I could send a message to a possibly dead actor and await a reply, if it does not happen I will create the actor myself but this would lead to a race condition (for multiple nodes) so I am currently expecting that you guys will solve this for me in the meantime ;)  I can imagine ZooKeeper comes in place with a lock that would need to be exposed but only internal to Akka.

- Cluster Definition

I was quite surprised when I learned that EventBus will not send messages to other nodes of a cluster. It would be nice to have a list of things that are expected to be clusterable and others that are not. 

Keep up the great work,

Joa

On Saturday, May 26, 2012 12:11:11 PM UTC+2, √ wrote:

On May 26, 2012 11:49 AM, "tim8dev" wrote:
>
> Hi, first of all: Akka 2.0 is awesome!
>
> After heart about Stash "by accident" here on the mailing list. I would like to ask for more documentation in Akka. If somebody quickly points me to the place where I would be able to write, I would be happy to do that.
>
> Actually, I was trying to implement Stash by myself, before I used it. But of course, I didn't used the Dequeue Mailbox so I actually tried to process the messages directly by invoking receive(msg), but then I had to mess around with sender. So great that there is Stash and you/we should point it out in the doc.
>
> One small question, though: Why use Vector and not List or ListBuffer. The Stash is a stack, so we don't need random access but only need fast append xor prepend, so why not List?

List is more expensive for nontrivial uses.

Cheers,
V

>
> Regards
> Tim
>
> --
> You received this message because you are subscribed to the Google Groups "Akka User List" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/YcU9SBBDSkwJ.
>
> To post to this group, send email to

> To unsubscribe from this group, send email to

[√iktor Ҡlang]

Hey Joa,

On Fri, Jun 1, 2012 at 11:26 AM, Joa Ebert <joae...@gmail.com> wrote:

Hey,

a little bit late to the party but since I did not work with Akka 1.0 and started using 2.0 without any prior experience with the framework here are my findings.

First of all I must say that not only Akka is awesome but the documentation is fantastic. Most of the time all my questions are answered via the docs and it is not necessary to ask on the mailing list.

That's music to our ears! :-)

 

There are only smaller issues that I currently face using Akka:

- Best practices

It would be really nice to have some more real world examples and best practices. In particular I would love to see more strategies for handling failure.  For instance I have two actors, A sends a message to B and does something when B replies back to A. Of course I could use a Future but since there is some overhead involved I do not want to use it and rather go with the more lightweight fire-and-forget approach. However the question is when should I go for a Future, when is fire-and-forget better. Should A start a timer and dispatch a message to itself to consider B dead if no message is received within x amount of time?

I agree, such material is however best presented in books, and unfortunately we're already working more hours than recommended…

 

I know that this needs to be answered on a case by case basis but a general hint and how to approach those issues would be nice.

I totally agree.

 

Another problem I have is the code structure. Maybe it is a question of taste but it would be great to have some kind of standard on how to organize actors and their messages. For instance a) put messages in a companion object or b) put actor and messages in the same package. What happens if multiple actors share the same message type?

That's a good question. Either declare the Actors in the same object or the same package and put the message definitions inside that scope.

 

- Get or Create

The main issue I currently face and without a solution is: how do I get or create an actor, especially when it happens in a cluster. This is mostly again an issue with the first statement about best practices and failure handling. I could send a message to a possibly dead actor and await a reply, if it does not happen I will create the actor myself but this would lead to a race condition (for multiple nodes) so I am currently expecting that you guys will solve this for me in the meantime ;)  I can imagine ZooKeeper comes in place with a lock that would need to be exposed but only internal to Akka.

getOrCreate seems essential at first, but then you realize that you don't know if you created it or not, and therefor not if you're responsible for stopping it.

 

- Cluster Definition

I was quite surprised when I learned that EventBus will not send messages to other nodes of a cluster. It would be nice to have a list of things that are expected to be clusterable and others that are not. 

That's sort of hard to do _Before_ we have actually built the clustering and decided what works and doesn't work.

Assume that it doesn't work unless stated otherwise.

 

Keep up the great work,

Thanks! And thank you for this excellent feedback!

Cheers,

√

 

Joa

On Saturday, May 26, 2012 12:11:11 PM UTC+2, √ wrote:

On May 26, 2012 11:49 AM, "tim8dev" wrote:
>
> Hi, first of all: Akka 2.0 is awesome!
>
> After heart about Stash "by accident" here on the mailing list. I would like to ask for more documentation in Akka. If somebody quickly points me to the place where I would be able to write, I would be happy to do that.
>
> Actually, I was trying to implement Stash by myself, before I used it. But of course, I didn't used the Dequeue Mailbox so I actually tried to process the messages directly by invoking receive(msg), but then I had to mess around with sender. So great that there is Stash and you/we should point it out in the doc.
>
> One small question, though: Why use Vector and not List or ListBuffer. The Stash is a stack, so we don't need random access but only need fast append xor prepend, so why not List?

List is more expensive for nontrivial uses.

Cheers,
V

>
> Regards
> Tim
>
> --
> You received this message because you are subscribed to the Google Groups "Akka User List" group.
> To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/YcU9SBBDSkwJ.
>
> To post to this group, send email to

> To unsubscribe from this group, send email to

> For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.

To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/axR39ZPnEqYJ.

To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

--

Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Brian]

On Thursday, May 24, 2012 8:00:07 AM UTC-4, √ wrote:

Dear hAkkers,

Now it's almost been 3 months since we released Akka 2.0, and we, the committers would really appreciate

getting some feedback on what your experiences have been during the past months.

If you cannot share this publically, please feel free to send the feedback to me personally and I'll keep it confidential.

Elicitinguser feedback is the key ingredient in making sure that Akka evolves in the right direction and that problems are

taken care of.

Looking forward to hearing about your Akka 2.0 experiences!

Cheers,

√

--
Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

...

 

+ having an exponential backoff option for OneForOne and AllForOne would be really handy

Very much +1 on this.  We have external systems that go down for sometimes short, sometimes long maintenance windows.  An exponential back-off gives the flexibility for both without trading off a quick initial response for something more transient than a maintenance window.  I think when this came up before on the ML there was a question of running out of memory because the downed actor's mailbox fills up while the supervisor is waiting to restart, so there's some component of backpressure needed.

We're still using Akka 1.3, and I know we didn't correctly set up our supervisors initially.  Based on that experience, IMO the addition of structure - the move to an Actor hierarchy is a big plus.  We've got a migration to 2.x on the roadmap, will have more feedback then.  I guess one person's getting in the way is another's framework, 2 sides - same coin.

 

[√iktor Ҡlang]

On Fri, Jun 1, 2012 at 5:05 PM, Brian <sculld...@gmail.com> wrote:

On Thursday, May 24, 2012 8:00:07 AM UTC-4, √ wrote:

Dear hAkkers,

Now it's almost been 3 months since we released Akka 2.0, and we, the committers would really appreciate

getting some feedback on what your experiences have been during the past months.

If you cannot share this publically, please feel free to send the feedback to me personally and I'll keep it confidential.

Elicitinguser feedback is the key ingredient in making sure that Akka evolves in the right direction and that problems are

taken care of.

Looking forward to hearing about your Akka 2.0 experiences!

Cheers,

√

--
Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

...

 

+ having an exponential backoff option for OneForOne and AllForOne would be really handy

Very much +1 on this.  

See "Community Involvement Requested" milestone in the Akka Issue tracker:

http://www.assembla.com/spaces/akka/tickets/2132

 

We have external systems that go down for sometimes short, sometimes long maintenance windows.  An exponential back-off gives the flexibility for both without trading off a quick initial response for something more transient than a maintenance window.  I think when this came up before on the ML there was a question of running out of memory because the downed actor's mailbox fills up while the supervisor is waiting to restart, so there's some component of backpressure needed.

That doesn't work across nodes. applying backpressure to messages that come in over remoting requires either explicit acking to apply it across nodes, and it also increases the risk of system freezes. I think the most sensible solution is to start dropping messages over a certain threshold.

 

We're still using Akka 1.3, and I know we didn't correctly set up our supervisors initially.  Based on that experience, IMO the addition of structure - the move to an Actor hierarchy is a big plus.  We've got a migration to 2.x on the roadmap, will have more feedback then.  

Excellent, looking forward to getting the feedback after the migration!

 

I guess one person's getting in the way is another's framework, 2 sides - same coin.

Thanks for the feedback,

Cheers,

√

 

 

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.

To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/-Ro3_SBJawUJ.

To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

[Veebs]

Sorry for the late reply Roland,

Yes we can get it in the logging but from memory, when I was profiling the JVM, I only get thread names.  I was using jvisualvm at the time.

Vibul

To unsubscribe from this group, send email to akka-user+unsubscribe@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

[Roland Kuhn]

Hi Vibul,

hmm, we’re using Thread.getName in the logging …

Regards,

Roland

To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/B6Kab09BRXYJ.

To post to this group, send email to akka...@googlegroups.com.

To unsubscribe from this group, send email to akka-user+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

[Sean W]

It's working out great for us. We have been using akka for over a
year and we currently have 3 modules of our software platform in akka
2. Thanks for all the hard work and innovation, looking forward to
seamless cloud integration.

Sean

On May 24, 8:00 am, √iktor Ҡlang <viktor.kl...@gmail.com> wrote:
> Dear hAkkers,
>
> Now it's almost been 3 months since we released Akka 2.0, and we, the
> committers would really appreciate
> getting some feedback on what your experiences have been during the past
> months.
> If you cannot share this publically, please feel free to send the feedback
> to me personally and I'll keep it confidential.
>
> Elicitinguser feedback is the key ingredient in making sure that Akka
> evolves in the right direction and that problems are
> taken care of.
>
> Looking forward to hearing about your Akka 2.0 experiences!
>
> Cheers,
> √
>
> --
> Viktor Klang
>
> Akka Tech Lead

> Typesafe <http://www.typesafe.com/> - The software stack for applications
> that scale
>
> Twitter: @viktorklang

[√iktor Ҡlang]

On Thu, Jun 7, 2012 at 4:18 PM, Sean W <swa...@viridityenergy.com> wrote:

It's working out great for us.  We have been using akka for over a
year and we currently have 3 modules of our software platform in akka
2.  Thanks for all the hard work and innovation, looking forward to
seamless cloud integration.

Music to my ears!

Happy hAkking!

Cheers,

√

 

Sean

On May 24, 8:00 am, √iktor Ҡlang <viktor.kl...@gmail.com> wrote:
> Dear hAkkers,
>
> Now it's almost been 3 months since we released Akka 2.0, and we, the
> committers would really appreciate
> getting some feedback on what your experiences have been during the past
> months.
> If you cannot share this publically, please feel free to send the feedback
> to me personally and I'll keep it confidential.
>
> Elicitinguser feedback is the key ingredient in making sure that Akka
> evolves in the right direction and that problems are
> taken care of.
>
> Looking forward to hearing about your Akka 2.0 experiences!
>
> Cheers,
> √
>
> --
> Viktor Klang
>
> Akka Tech Lead

> Typesafe <http://www.typesafe.com/> - The software stack for applications
> that scale
>
> Twitter: @viktorklang

--
You received this message because you are subscribed to the Google Groups "Akka User List" group.

To post to this group, send email to akka...@googlegroups.com.
To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

--

Viktor Klang

Akka Tech Lead

Typesafe - The software stack for applications that scale

Twitter: @viktorklang

[Jonas Bonér]

On Thu, Jun 7, 2012 at 4:18 PM, Sean W <swa...@viridityenergy.com> wrote:

> It's working out great for us.  We have been using akka for over a
> year and we currently have 3 modules of our software platform in akka
> 2.  Thanks for all the hard work and innovation, looking forward to
> seamless cloud integration.
>

Great news. Thanks for sharing.

> Sean
>
> On May 24, 8:00 am, √iktor Ҡlang <viktor.kl...@gmail.com> wrote:
>> Dear hAkkers,
>>
>> Now it's almost been 3 months since we released Akka 2.0, and we, the
>> committers would really appreciate
>> getting some feedback on what your experiences have been during the past
>> months.
>> If you cannot share this publically, please feel free to send the feedback
>> to me personally and I'll keep it confidential.
>>
>> Elicitinguser feedback is the key ingredient in making sure that Akka
>> evolves in the right direction and that problems are
>> taken care of.
>>
>> Looking forward to hearing about your Akka 2.0 experiences!
>>
>> Cheers,
>> √
>>
>> --
>> Viktor Klang
>>
>> Akka Tech Lead
>> Typesafe <http://www.typesafe.com/> - The software stack for applications
>> that scale
>>
>> Twitter: @viktorklang
>

> --
> You received this message because you are subscribed to the Google Groups "Akka User List" group.
> To post to this group, send email to akka...@googlegroups.com.
> To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.
>



--

Jonas Bonér
CTO
Typesafe - The software stack for applications that scale

[Veebs]

Hi Roland,

Sorry, my newbie mistake.  You are correct.  You do get the dispatcher name in the thread.

Vibul

[Roland Kuhn]

Hi Vibul,

good to hear, hAkk on!

Roland

To view this discussion on the web visit https://groups.google.com/d/msg/akka-user/-/pZiPbBcVxikJ.

To post to this group, send email to akka...@googlegroups.com.

To unsubscribe from this group, send email to akka-user+...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.

[Jonas Boner]

On Fri, Jun 8, 2012 at 3:09 AM, beagledude <jim...@gmail.com> wrote:
> more ZeroMQ docs would be good. They've said more docs and examples coming
> soon for a while
> http://doc.akka.io/docs/akka/2.0.1/scala/zeromq.html
>
>

Just "more docs" is hard to work with. What *exactly* needs to be
improved? What kind of samples etc?

> On Thursday, May 24, 2012 5:00:07 AM UTC-7, √ wrote:
>>
>> Dear hAkkers,
>>
>> Now it's almost been 3 months since we released Akka 2.0, and we, the
>> committers would really appreciate
>> getting some feedback on what your experiences have been during the past
>> months.
>> If you cannot share this publically, please feel free to send the feedback
>> to me personally and I'll keep it confidential.
>>
>> Elicitinguser feedback is the key ingredient in making sure that Akka
>> evolves in the right direction and that problems are
>> taken care of.
>>
>> Looking forward to hearing about your Akka 2.0 experiences!
>>
>> Cheers,
>> √
>>
>> --
>> Viktor Klang
>>
>> Akka Tech Lead
>> Typesafe - The software stack for applications that scale
>>
>> Twitter: @viktorklang
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/akka-user/-/WEbA5_NThg4J.

>
> To post to this group, send email to akka...@googlegroups.com.
> To unsubscribe from this group, send email to
> akka-user+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/akka-user?hl=en.

--
Jonas Bonér
CTO

Typesafe - The software stack for applications that scale

[Michael Slinn]

I put some work into ZeroMQ docs, with a working project

https://github.com/mslinn/zeromq-demo 

Mike

[Jonas Bonér]

On Fri, Jun 8, 2012 at 2:40 PM, Michael Slinn <msl...@gmail.com> wrote:
> I put some work into ZeroMQ docs, with a working project
> https://github.com/mslinn/zeromq-demo
>

Nice.

> Mike

>
> --
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To view this discussion on the web visit

> https://groups.google.com/d/msg/akka-user/-/7XnNoTu986UJ.