[akka-user] Re: akka-persistance - nested persist

[Aditya Prasad]

Now that nested persist works, is it still strongly suggested not to nest 
persists? The way I see it, there are a few approaches:

   1. Nested persists. In this model, my handler does (a) applyEvent (state 
   change) and (b) postApply (take action, including more persisting). This 
   allows me to structure my postApply handler in a readable fashion, so it's 
   clear what's triggering what.
   2. Send myself a command. The drawback is that state could change in 
   between and so I have to handle failure cases which are sort of spurious.
   3. Simulate all downstream effects before persisting. The benefit 
   (versus both #1 and #2) is that it prevents some weird intermediate states 
   (e.g., on replay), and the drawback is that I have to simulate an arbitrary 
   number of steps, which can become very unreadable.

What are the main drawbacks of nesting?

Cheers,
A

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] akka networking for thousands of small messages

[Patrik Nordwall]

A few 100 microseconds is a reasonable expectation for delivery of a a
message to a remote actor.

/Patrik
fre 2 dec. 2016 kl. 21:22 skrev 'Konstantinos Kougios' via Akka User List <
akka-user@googlegroups.com>:

> Hi Konrad,
>
> Thanks for the reply, thats good enough volume of messages :)
>
> What if, say per 1 operation of mine, I will need say 30 messages to
> complete it? But messages will be sequential, that is they won't be fired
> in 1 go but the 1st msg will be send to the 1st actor who in turn will send
> the 2nd message and so on.
>
> Do you have any timings (or a best guess) for a similar scenario? How long
> before the 30th actor replies to the original request?
>
>
>
>
> On 02/12/16 16:24, Konrad Malawski wrote:
>
>
> Hi, anyone knows if say I got 2 actors which send very quickly thousands
> of small messages between them.
>
> Millions of small messages is the happy case for Akka - this is exactly
> what Actors love :-)
>
> We've reached 700k+ 100byte sized messages per second on the new remoting
> recently, and aim to still improve there.
>
>
> Will akka do any groupping of the messages and send them in batches in
> order to reduce network traffic?
>
> Grouping would not reduce traffic, you still need to carry the same amount
> of information. It would even hurt latency to do grouping actually, so no,
> we don't do that.
>
> We do smart things in the new remoting (Artery), which we're about to
> publish a blog post series about - please watch akka.io/blog
>
> For example, each remote actor message needs to carry around the address
> of the sender and recipient (it's a string basically), and we compress
> these huge strings into single integer values etc. We do things like that
> in Artery: doc.akka.io/docs/akka/2.4/scala/remoting-artery.html
>
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
>
> You received this message because you are subscribed to a topic in the
> Google Groups "Akka User List" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/akka-user/eF2X8BxwuoE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> akka-user+unsubscr...@googlegroups.com.
>
>
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Unit test for Persistent Actor Replay

[Patrik Nordwall]

Yup, and you don't need the null check, it will retry for any exception,
which here will be thrown by actorOf

fre 2 dec. 2016 kl. 21:17 skrev Richard Rodseth :

> Thank you! I was not aware of awaitAssert. I think the following should do
> the trick.
>
> watch(definitionReader)
>
> system.stop(definitionReader)
>
> expectTerminated(definitionReader)
>
> var definitionReader2: ActorRef = null
>
> awaitAssert {
>
>   definitionReader2 = system.actorOf(actorProps, actorName)
>
>   definitionReader2 should not be (null)
>
> }
>
> definitionReader2 ! DefinitionReader.GetState
>
> On Fri, Dec 2, 2016 at 11:25 AM, Patrik Nordwall <
> patrik.nordw...@gmail.com> wrote:
>
> For testing purposes you might need to optionally override that way of
> defining the persistenceId by passing it in as constructor parameter.
>
> Another way is to retry the actorOf in the test until it is successful.
> awaitAssert in testkit can be useful for that.
>
> fre 2 dec. 2016 kl. 20:16 skrev Richard Rodseth :
>
> I see now that
>
>
> https://github.com/akka/akka/blob/release-2.4/akka-persistence/src/test/scala/akka/persistence/PersistentActorSpec.scala
>
> works by generating a unique id in beforeEach().
>
> But I wonder how all your customers test recovery of their persistent
> sharded entities when they follow your example of using self.path.name in
> the persistenceId ?
>
> http://doc.akka.io/docs/akka/2.4/scala/cluster-sharding.html#An_Example
>
>   override val persistenceId: String = "XYZ-" + self.path.name
>
>
> On Fri, Dec 2, 2016 at 10:59 AM, Richard Rodseth 
> wrote:
>
> I wondered about that, but the persistence id is derived from the name
> (it's an aggregate root)
>
>   override val persistenceId: String = "XYZ-" + self.path.name
>
> On Fri, Dec 2, 2016 at 10:53 AM, Patrik Nordwall <
> patrik.nordw...@gmail.com> wrote:
>
> You can start the second actor with a different actor name but with the
> same persistenceId.
>
> If you don't specify the actor name a unique name will be used.
>
> /Patrik
>
> fre 2 dec. 2016 kl. 19:43 skrev Richard Rodseth :
>
> I'm also looking here:
>
> https://github.com/akka/akka/blob/release-2.4/akka-persistence/src/test/scala/akka/persistence/PersistentActorSpec.scala
>
> There's a lot of inherited code in these tests, and it's unclear to me how
> the issue is avoided here:
>
> abstract class PersistentActorSpec(config: Config) extends
> PersistenceSpec(config) with ImplicitSender {
> import PersistentActorSpec._
> override protected def beforeEach() {
> super.beforeEach()
> val persistentActor = namedPersistentActor[Behavior1PersistentActor]
> persistentActor ! Cmd("a")
> persistentActor ! GetState
> expectMsg(List("a-1", "a-2"))
> }
> "A persistent actor" must {
> "recover from persisted events" in {
> val persistentActor = namedPersistentActor[Behavior1PersistentActor]
> persistentActor ! GetState
> expectMsg(List("a-1", "a-2"))
> }
>
>
>
> On Fri, Dec 2, 2016 at 7:42 AM, Richard Rodseth 
> wrote:
>
> I see that TestActorRef is not an option with PersistentActor
>
>
> http://doc.akka.io/docs/akka/2.4.1/scala/testing.html#Synchronous_Unit_Testing_with_TestActorRef
>
> This is not the clearest paragraph, but perhaps provides an option:
>
> "It may also be required during testing, when the test subject depends on
> being instantiated at a specific path. In that case it is best to mock its
> supervisor so that it will forward the Terminated message to the
> appropriate point in the test procedure, enabling the latter to await
> proper deregistration of the name."
>
> http://doc.akka.io/docs/akka/current/general/addressing.html#Reusing_Actor_Paths
>
> Only other thing I can think of is to use akka-persistence-query APIs to
> check the event store, but that's not exactly testing recover.
>
> Thanks for any other ideas.
>
>
>
> On Thu, Dec 1, 2016 at 11:24 PM, Roland Kuhn  wrote:
>
> Well, it is solved in Akka Typed: removing system.actorOf() and
> system.stop() is the only way to "solve" this. The reason is that the
> semantics of these methods are incompatible with the distributed nature of
> the ActorSystem.
>
> Regards, Roland
>
> Sent from my iPhone
>
> On 2 Dec 2016, at 08:12, Viktor Klang  wrote:
>
> Good question!
>
> The notification of its death hadn't reached the closest of kin (its
> parent) so they hadn't even put it in the ground when you proposed to
> create a new one and call it the same thing, so they (rightfully so)
> objected to that suggestion.
>
> This trips people up every now and then, but I've never seen a proposal to
> solve it.
>
> --
> Cheers,
> √
>
> On Dec 2, 2016 02:44, "Richard Rodseth"  wrote:
>
> We have a unit test for a persistent actor, which instantiates a second
> instance after waiting for termination of the first.
>
> watch(definitionReader)
>
> system.stop(definitionReader)
>
> 

Re: [akka-user] akka networking for thousands of small messages

['Konstantinos Kougios' via Akka User List]

Hi Konrad,

Thanks for the reply, thats good enough volume of messages :)

What if, say per 1 operation of mine, I will need say 30 messages to 
complete it? But messages will be sequential, that is they won't be 
fired in 1 go but the 1st msg will be send to the 1st actor who in turn 
will send the 2nd message and so on.


Do you have any timings (or a best guess) for a similar scenario? How 
long before the 30th actor replies to the original request?




On 02/12/16 16:24, Konrad Malawski wrote:


Hi, anyone knows if say I got 2 actors which send very quickly 
thousands of small messages between them.


Millions of small messages is the happy case for Akka - this is 
exactly what Actors love :-)


We've reached 700k+ 100byte sized messages per second on the new 
remoting recently, and aim to still improve there.



Will akka do any groupping of the messages and send them in batches 
in order to reduce network traffic?


Grouping would not reduce traffic, you still need to carry the same 
amount of information. It would even hurt latency to do grouping 
actually, so no, we don't do that.


We do smart things in the new remoting (Artery), which we're about to 
publish a blog post series about - please watch akka.io/blog 



For example, each remote actor message needs to carry around the 
address of the sender and recipient (it's a string basically), and we 
compress these huge strings into single integer values etc. We do 
things like that in Artery: 
doc.akka.io/docs/akka/2.4/scala/remoting-artery.html 




--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ: 
http://doc.akka.io/docs/akka/current/additional/faq.html

>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to a topic in the 
Google Groups "Akka User List" group.
To unsubscribe from this topic, visit 
https://groups.google.com/d/topic/akka-user/eF2X8BxwuoE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to 
akka-user+unsubscr...@googlegroups.com 
.
To post to this group, send email to akka-user@googlegroups.com 
.

Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.



--

 Read the docs: http://akka.io/docs/
 Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
 Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka User List" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Unit test for Persistent Actor Replay

[Richard Rodseth]

Thank you! I was not aware of awaitAssert. I think the following should do
the trick.

watch(definitionReader)

system.stop(definitionReader)

expectTerminated(definitionReader)

var definitionReader2: ActorRef = null

awaitAssert {

  definitionReader2 = system.actorOf(actorProps, actorName)

  definitionReader2 should not be (null)

}

definitionReader2 ! DefinitionReader.GetState

On Fri, Dec 2, 2016 at 11:25 AM, Patrik Nordwall 
wrote:

> For testing purposes you might need to optionally override that way of
> defining the persistenceId by passing it in as constructor parameter.
>
> Another way is to retry the actorOf in the test until it is successful.
> awaitAssert in testkit can be useful for that.
>
> fre 2 dec. 2016 kl. 20:16 skrev Richard Rodseth :
>
>> I see now that
>>
>> https://github.com/akka/akka/blob/release-2.4/akka-
>> persistence/src/test/scala/akka/persistence/PersistentActorSpec.scala
>>
>> works by generating a unique id in beforeEach().
>>
>> But I wonder how all your customers test recovery of their persistent
>> sharded entities when they follow your example of using self.path.name
>> in the persistenceId ?
>>
>> http://doc.akka.io/docs/akka/2.4/scala/cluster-sharding.html#An_Example
>>
>>   override val persistenceId: String = "XYZ-" + self.path.name
>>
>>
>> On Fri, Dec 2, 2016 at 10:59 AM, Richard Rodseth 
>> wrote:
>>
>> I wondered about that, but the persistence id is derived from the name
>> (it's an aggregate root)
>>
>>   override val persistenceId: String = "XYZ-" + self.path.name
>>
>> On Fri, Dec 2, 2016 at 10:53 AM, Patrik Nordwall <
>> patrik.nordw...@gmail.com> wrote:
>>
>> You can start the second actor with a different actor name but with the
>> same persistenceId.
>>
>> If you don't specify the actor name a unique name will be used.
>>
>> /Patrik
>>
>> fre 2 dec. 2016 kl. 19:43 skrev Richard Rodseth :
>>
>> I'm also looking here:
>> https://github.com/akka/akka/blob/release-2.4/akka-
>> persistence/src/test/scala/akka/persistence/PersistentActorSpec.scala
>>
>> There's a lot of inherited code in these tests, and it's unclear to me
>> how the issue is avoided here:
>>
>> abstract class PersistentActorSpec(config: Config) extends
>> PersistenceSpec(config) with ImplicitSender {
>> import PersistentActorSpec._
>> override protected def beforeEach() {
>> super.beforeEach()
>> val persistentActor = namedPersistentActor[Behavior1PersistentActor]
>> persistentActor ! Cmd("a")
>> persistentActor ! GetState
>> expectMsg(List("a-1", "a-2"))
>> }
>> "A persistent actor" must {
>> "recover from persisted events" in {
>> val persistentActor = namedPersistentActor[Behavior1PersistentActor]
>> persistentActor ! GetState
>> expectMsg(List("a-1", "a-2"))
>> }
>>
>>
>>
>> On Fri, Dec 2, 2016 at 7:42 AM, Richard Rodseth 
>> wrote:
>>
>> I see that TestActorRef is not an option with PersistentActor
>>
>> http://doc.akka.io/docs/akka/2.4.1/scala/testing.html#
>> Synchronous_Unit_Testing_with_TestActorRef
>>
>> This is not the clearest paragraph, but perhaps provides an option:
>>
>> "It may also be required during testing, when the test subject depends
>> on being instantiated at a specific path. In that case it is best to mock
>> its supervisor so that it will forward the Terminated message to the
>> appropriate point in the test procedure, enabling the latter to await
>> proper deregistration of the name."
>> http://doc.akka.io/docs/akka/current/general/addressing.
>> html#Reusing_Actor_Paths
>>
>> Only other thing I can think of is to use akka-persistence-query APIs to
>> check the event store, but that's not exactly testing recover.
>>
>> Thanks for any other ideas.
>>
>>
>>
>> On Thu, Dec 1, 2016 at 11:24 PM, Roland Kuhn  wrote:
>>
>> Well, it is solved in Akka Typed: removing system.actorOf() and
>> system.stop() is the only way to "solve" this. The reason is that the
>> semantics of these methods are incompatible with the distributed nature of
>> the ActorSystem.
>>
>> Regards, Roland
>>
>> Sent from my iPhone
>>
>> On 2 Dec 2016, at 08:12, Viktor Klang  wrote:
>>
>> Good question!
>>
>> The notification of its death hadn't reached the closest of kin (its
>> parent) so they hadn't even put it in the ground when you proposed to
>> create a new one and call it the same thing, so they (rightfully so)
>> objected to that suggestion.
>>
>> This trips people up every now and then, but I've never seen a proposal
>> to solve it.
>>
>> --
>> Cheers,
>> √
>>
>> On Dec 2, 2016 02:44, "Richard Rodseth"  wrote:
>>
>> We have a unit test for a persistent actor, which instantiates a second
>> instance after waiting for termination of the first.
>>
>> watch(definitionReader)
>>
>> system.stop(definitionReader)
>>
>> expectTerminated(definitionReader)
>>
>> val notificationDefinitionReader2 = system.actorOf(actorProps, 

[akka-user] Re: Installing Akka in Textmate 2 on macOS Sierra

[Daniel Martin]

*for Scala

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Installing Akka in Textmate 2 on macOS Sierra

[Daniel Martin]

Hello,

I do have big troubles installing akka in Textmate 2 on my macOS Sierra 
MacBook.
Can someone help me out and give me a step by step instruction?
How am I doing this? :/ 

Thanks in advance!

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Unit test for Persistent Actor Replay

[Patrik Nordwall]

For testing purposes you might need to optionally override that way of
defining the persistenceId by passing it in as constructor parameter.

Another way is to retry the actorOf in the test until it is successful.
awaitAssert in testkit can be useful for that.

fre 2 dec. 2016 kl. 20:16 skrev Richard Rodseth :

> I see now that
>
>
> https://github.com/akka/akka/blob/release-2.4/akka-persistence/src/test/scala/akka/persistence/PersistentActorSpec.scala
>
> works by generating a unique id in beforeEach().
>
> But I wonder how all your customers test recovery of their persistent
> sharded entities when they follow your example of using self.path.name in
> the persistenceId ?
>
> http://doc.akka.io/docs/akka/2.4/scala/cluster-sharding.html#An_Example
>
>   override val persistenceId: String = "XYZ-" + self.path.name
>
>
> On Fri, Dec 2, 2016 at 10:59 AM, Richard Rodseth 
> wrote:
>
> I wondered about that, but the persistence id is derived from the name
> (it's an aggregate root)
>
>   override val persistenceId: String = "XYZ-" + self.path.name
>
> On Fri, Dec 2, 2016 at 10:53 AM, Patrik Nordwall <
> patrik.nordw...@gmail.com> wrote:
>
> You can start the second actor with a different actor name but with the
> same persistenceId.
>
> If you don't specify the actor name a unique name will be used.
>
> /Patrik
>
> fre 2 dec. 2016 kl. 19:43 skrev Richard Rodseth :
>
> I'm also looking here:
>
> https://github.com/akka/akka/blob/release-2.4/akka-persistence/src/test/scala/akka/persistence/PersistentActorSpec.scala
>
> There's a lot of inherited code in these tests, and it's unclear to me how
> the issue is avoided here:
>
> abstract class PersistentActorSpec(config: Config) extends
> PersistenceSpec(config) with ImplicitSender {
> import PersistentActorSpec._
> override protected def beforeEach() {
> super.beforeEach()
> val persistentActor = namedPersistentActor[Behavior1PersistentActor]
> persistentActor ! Cmd("a")
> persistentActor ! GetState
> expectMsg(List("a-1", "a-2"))
> }
> "A persistent actor" must {
> "recover from persisted events" in {
> val persistentActor = namedPersistentActor[Behavior1PersistentActor]
> persistentActor ! GetState
> expectMsg(List("a-1", "a-2"))
> }
>
>
>
> On Fri, Dec 2, 2016 at 7:42 AM, Richard Rodseth 
> wrote:
>
> I see that TestActorRef is not an option with PersistentActor
>
>
> http://doc.akka.io/docs/akka/2.4.1/scala/testing.html#Synchronous_Unit_Testing_with_TestActorRef
>
> This is not the clearest paragraph, but perhaps provides an option:
>
> "It may also be required during testing, when the test subject depends on
> being instantiated at a specific path. In that case it is best to mock its
> supervisor so that it will forward the Terminated message to the
> appropriate point in the test procedure, enabling the latter to await
> proper deregistration of the name."
>
> http://doc.akka.io/docs/akka/current/general/addressing.html#Reusing_Actor_Paths
>
> Only other thing I can think of is to use akka-persistence-query APIs to
> check the event store, but that's not exactly testing recover.
>
> Thanks for any other ideas.
>
>
>
> On Thu, Dec 1, 2016 at 11:24 PM, Roland Kuhn  wrote:
>
> Well, it is solved in Akka Typed: removing system.actorOf() and
> system.stop() is the only way to "solve" this. The reason is that the
> semantics of these methods are incompatible with the distributed nature of
> the ActorSystem.
>
> Regards, Roland
>
> Sent from my iPhone
>
> On 2 Dec 2016, at 08:12, Viktor Klang  wrote:
>
> Good question!
>
> The notification of its death hadn't reached the closest of kin (its
> parent) so they hadn't even put it in the ground when you proposed to
> create a new one and call it the same thing, so they (rightfully so)
> objected to that suggestion.
>
> This trips people up every now and then, but I've never seen a proposal to
> solve it.
>
> --
> Cheers,
> √
>
> On Dec 2, 2016 02:44, "Richard Rodseth"  wrote:
>
> We have a unit test for a persistent actor, which instantiates a second
> instance after waiting for termination of the first.
>
> watch(definitionReader)
>
> system.stop(definitionReader)
>
> expectTerminated(definitionReader)
>
> val notificationDefinitionReader2 = system.actorOf(actorProps, actorName)
>
> This test fails intermittently on Bamboo
>
> actor name [name1] is not unique!
>
> Any ideas?
>
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to 

Re: [akka-user] Unit test for Persistent Actor Replay

[Richard Rodseth]

I see now that

https://github.com/akka/akka/blob/release-2.4/akka-persistence/src/test/scala/akka/persistence/PersistentActorSpec.scala

works by generating a unique id in beforeEach().

But I wonder how all your customers test recovery of their persistent
sharded entities when they follow your example of using self.path.name in
the persistenceId ?

http://doc.akka.io/docs/akka/2.4/scala/cluster-sharding.html#An_Example

  override val persistenceId: String = "XYZ-" + self.path.name


On Fri, Dec 2, 2016 at 10:59 AM, Richard Rodseth  wrote:

> I wondered about that, but the persistence id is derived from the name
> (it's an aggregate root)
>
>   override val persistenceId: String = "XYZ-" + self.path.name
>
> On Fri, Dec 2, 2016 at 10:53 AM, Patrik Nordwall <
> patrik.nordw...@gmail.com> wrote:
>
>> You can start the second actor with a different actor name but with the
>> same persistenceId.
>>
>> If you don't specify the actor name a unique name will be used.
>>
>> /Patrik
>>
>> fre 2 dec. 2016 kl. 19:43 skrev Richard Rodseth :
>>
>>> I'm also looking here:
>>> https://github.com/akka/akka/blob/release-2.4/akka-persisten
>>> ce/src/test/scala/akka/persistence/PersistentActorSpec.scala
>>>
>>> There's a lot of inherited code in these tests, and it's unclear to me
>>> how the issue is avoided here:
>>>
>>> abstract class PersistentActorSpec(config: Config) extends
>>> PersistenceSpec(config) with ImplicitSender {
>>> import PersistentActorSpec._
>>> override protected def beforeEach() {
>>> super.beforeEach()
>>> val persistentActor = namedPersistentActor[Behavior1PersistentActor]
>>> persistentActor ! Cmd("a")
>>> persistentActor ! GetState
>>> expectMsg(List("a-1", "a-2"))
>>> }
>>> "A persistent actor" must {
>>> "recover from persisted events" in {
>>> val persistentActor = namedPersistentActor[Behavior1PersistentActor]
>>> persistentActor ! GetState
>>> expectMsg(List("a-1", "a-2"))
>>> }
>>>
>>>
>>>
>>> On Fri, Dec 2, 2016 at 7:42 AM, Richard Rodseth 
>>> wrote:
>>>
>>> I see that TestActorRef is not an option with PersistentActor
>>>
>>> http://doc.akka.io/docs/akka/2.4.1/scala/testing.html#Synchr
>>> onous_Unit_Testing_with_TestActorRef
>>>
>>> This is not the clearest paragraph, but perhaps provides an option:
>>>
>>> "It may also be required during testing, when the test subject depends
>>> on being instantiated at a specific path. In that case it is best to mock
>>> its supervisor so that it will forward the Terminated message to the
>>> appropriate point in the test procedure, enabling the latter to await
>>> proper deregistration of the name."
>>> http://doc.akka.io/docs/akka/current/general/addressing.html
>>> #Reusing_Actor_Paths
>>>
>>> Only other thing I can think of is to use akka-persistence-query APIs to
>>> check the event store, but that's not exactly testing recover.
>>>
>>> Thanks for any other ideas.
>>>
>>>
>>>
>>> On Thu, Dec 1, 2016 at 11:24 PM, Roland Kuhn  wrote:
>>>
>>> Well, it is solved in Akka Typed: removing system.actorOf() and
>>> system.stop() is the only way to "solve" this. The reason is that the
>>> semantics of these methods are incompatible with the distributed nature of
>>> the ActorSystem.
>>>
>>> Regards, Roland
>>>
>>> Sent from my iPhone
>>>
>>> On 2 Dec 2016, at 08:12, Viktor Klang  wrote:
>>>
>>> Good question!
>>>
>>> The notification of its death hadn't reached the closest of kin (its
>>> parent) so they hadn't even put it in the ground when you proposed to
>>> create a new one and call it the same thing, so they (rightfully so)
>>> objected to that suggestion.
>>>
>>> This trips people up every now and then, but I've never seen a proposal
>>> to solve it.
>>>
>>> --
>>> Cheers,
>>> √
>>>
>>> On Dec 2, 2016 02:44, "Richard Rodseth"  wrote:
>>>
>>> We have a unit test for a persistent actor, which instantiates a second
>>> instance after waiting for termination of the first.
>>>
>>> watch(definitionReader)
>>>
>>> system.stop(definitionReader)
>>>
>>> expectTerminated(definitionReader)
>>>
>>> val notificationDefinitionReader2 = system.actorOf(actorProps, actorName
>>> )
>>>
>>> This test fails intermittently on Bamboo
>>>
>>> actor name [name1] is not unique!
>>>
>>> Any ideas?
>>>
>>>
>>> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >> Search the archives: https://groups.google.com/grou
>>> p/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+unsubscr...@googlegroups.com.
>>> To post to this group, send email to akka-user@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit 

Re: [akka-user] Unit test for Persistent Actor Replay

[Richard Rodseth]

I wondered about that, but the persistence id is derived from the name
(it's an aggregate root)

  override val persistenceId: String = "XYZ-" + self.path.name

On Fri, Dec 2, 2016 at 10:53 AM, Patrik Nordwall 
wrote:

> You can start the second actor with a different actor name but with the
> same persistenceId.
>
> If you don't specify the actor name a unique name will be used.
>
> /Patrik
>
> fre 2 dec. 2016 kl. 19:43 skrev Richard Rodseth :
>
>> I'm also looking here:
>> https://github.com/akka/akka/blob/release-2.4/akka-
>> persistence/src/test/scala/akka/persistence/PersistentActorSpec.scala
>>
>> There's a lot of inherited code in these tests, and it's unclear to me
>> how the issue is avoided here:
>>
>> abstract class PersistentActorSpec(config: Config) extends
>> PersistenceSpec(config) with ImplicitSender {
>> import PersistentActorSpec._
>> override protected def beforeEach() {
>> super.beforeEach()
>> val persistentActor = namedPersistentActor[Behavior1PersistentActor]
>> persistentActor ! Cmd("a")
>> persistentActor ! GetState
>> expectMsg(List("a-1", "a-2"))
>> }
>> "A persistent actor" must {
>> "recover from persisted events" in {
>> val persistentActor = namedPersistentActor[Behavior1PersistentActor]
>> persistentActor ! GetState
>> expectMsg(List("a-1", "a-2"))
>> }
>>
>>
>>
>> On Fri, Dec 2, 2016 at 7:42 AM, Richard Rodseth 
>> wrote:
>>
>> I see that TestActorRef is not an option with PersistentActor
>>
>> http://doc.akka.io/docs/akka/2.4.1/scala/testing.html#
>> Synchronous_Unit_Testing_with_TestActorRef
>>
>> This is not the clearest paragraph, but perhaps provides an option:
>>
>> "It may also be required during testing, when the test subject depends
>> on being instantiated at a specific path. In that case it is best to mock
>> its supervisor so that it will forward the Terminated message to the
>> appropriate point in the test procedure, enabling the latter to await
>> proper deregistration of the name."
>> http://doc.akka.io/docs/akka/current/general/addressing.
>> html#Reusing_Actor_Paths
>>
>> Only other thing I can think of is to use akka-persistence-query APIs to
>> check the event store, but that's not exactly testing recover.
>>
>> Thanks for any other ideas.
>>
>>
>>
>> On Thu, Dec 1, 2016 at 11:24 PM, Roland Kuhn  wrote:
>>
>> Well, it is solved in Akka Typed: removing system.actorOf() and
>> system.stop() is the only way to "solve" this. The reason is that the
>> semantics of these methods are incompatible with the distributed nature of
>> the ActorSystem.
>>
>> Regards, Roland
>>
>> Sent from my iPhone
>>
>> On 2 Dec 2016, at 08:12, Viktor Klang  wrote:
>>
>> Good question!
>>
>> The notification of its death hadn't reached the closest of kin (its
>> parent) so they hadn't even put it in the ground when you proposed to
>> create a new one and call it the same thing, so they (rightfully so)
>> objected to that suggestion.
>>
>> This trips people up every now and then, but I've never seen a proposal
>> to solve it.
>>
>> --
>> Cheers,
>> √
>>
>> On Dec 2, 2016 02:44, "Richard Rodseth"  wrote:
>>
>> We have a unit test for a persistent actor, which instantiates a second
>> instance after waiting for termination of the first.
>>
>> watch(definitionReader)
>>
>> system.stop(definitionReader)
>>
>> expectTerminated(definitionReader)
>>
>> val notificationDefinitionReader2 = system.actorOf(actorProps, actorName)
>>
>> This test fails intermittently on Bamboo
>>
>> actor name [name1] is not unique!
>>
>> Any ideas?
>>
>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: http://doc.akka.io/docs/akka/
>> current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: http://doc.akka.io/docs/akka/
>> current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> >> Read the 

Re: [akka-user] Unit test for Persistent Actor Replay

[Patrik Nordwall]

You can start the second actor with a different actor name but with the
same persistenceId.

If you don't specify the actor name a unique name will be used.

/Patrik
fre 2 dec. 2016 kl. 19:43 skrev Richard Rodseth :

> I'm also looking here:
>
> https://github.com/akka/akka/blob/release-2.4/akka-persistence/src/test/scala/akka/persistence/PersistentActorSpec.scala
>
> There's a lot of inherited code in these tests, and it's unclear to me how
> the issue is avoided here:
>
> abstract class PersistentActorSpec(config: Config) extends
> PersistenceSpec(config) with ImplicitSender {
> import PersistentActorSpec._
> override protected def beforeEach() {
> super.beforeEach()
> val persistentActor = namedPersistentActor[Behavior1PersistentActor]
> persistentActor ! Cmd("a")
> persistentActor ! GetState
> expectMsg(List("a-1", "a-2"))
> }
> "A persistent actor" must {
> "recover from persisted events" in {
> val persistentActor = namedPersistentActor[Behavior1PersistentActor]
> persistentActor ! GetState
> expectMsg(List("a-1", "a-2"))
> }
>
>
>
> On Fri, Dec 2, 2016 at 7:42 AM, Richard Rodseth 
> wrote:
>
> I see that TestActorRef is not an option with PersistentActor
>
>
> http://doc.akka.io/docs/akka/2.4.1/scala/testing.html#Synchronous_Unit_Testing_with_TestActorRef
>
> This is not the clearest paragraph, but perhaps provides an option:
>
> "It may also be required during testing, when the test subject depends on
> being instantiated at a specific path. In that case it is best to mock its
> supervisor so that it will forward the Terminated message to the
> appropriate point in the test procedure, enabling the latter to await
> proper deregistration of the name."
>
> http://doc.akka.io/docs/akka/current/general/addressing.html#Reusing_Actor_Paths
>
> Only other thing I can think of is to use akka-persistence-query APIs to
> check the event store, but that's not exactly testing recover.
>
> Thanks for any other ideas.
>
>
>
> On Thu, Dec 1, 2016 at 11:24 PM, Roland Kuhn  wrote:
>
> Well, it is solved in Akka Typed: removing system.actorOf() and
> system.stop() is the only way to "solve" this. The reason is that the
> semantics of these methods are incompatible with the distributed nature of
> the ActorSystem.
>
> Regards, Roland
>
> Sent from my iPhone
>
> On 2 Dec 2016, at 08:12, Viktor Klang  wrote:
>
> Good question!
>
> The notification of its death hadn't reached the closest of kin (its
> parent) so they hadn't even put it in the ground when you proposed to
> create a new one and call it the same thing, so they (rightfully so)
> objected to that suggestion.
>
> This trips people up every now and then, but I've never seen a proposal to
> solve it.
>
> --
> Cheers,
> √
>
> On Dec 2, 2016 02:44, "Richard Rodseth"  wrote:
>
> We have a unit test for a persistent actor, which instantiates a second
> instance after waiting for termination of the first.
>
> watch(definitionReader)
>
> system.stop(definitionReader)
>
> expectTerminated(definitionReader)
>
> val notificationDefinitionReader2 = system.actorOf(actorProps, actorName)
>
> This test fails intermittently on Bamboo
>
> actor name [name1] is not unique!
>
> Any ideas?
>
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to 

Re: [akka-user] Unit test for Persistent Actor Replay

[Richard Rodseth]

I'm also looking here:
https://github.com/akka/akka/blob/release-2.4/akka-persistence/src/test/scala/akka/persistence/PersistentActorSpec.scala

There's a lot of inherited code in these tests, and it's unclear to me how
the issue is avoided here:

abstract class PersistentActorSpec(config: Config) extends
PersistenceSpec(config) with ImplicitSender {
import PersistentActorSpec._
override protected def beforeEach() {
super.beforeEach()
val persistentActor = namedPersistentActor[Behavior1PersistentActor]
persistentActor ! Cmd("a")
persistentActor ! GetState
expectMsg(List("a-1", "a-2"))
}
"A persistent actor" must {
"recover from persisted events" in {
val persistentActor = namedPersistentActor[Behavior1PersistentActor]
persistentActor ! GetState
expectMsg(List("a-1", "a-2"))
}



On Fri, Dec 2, 2016 at 7:42 AM, Richard Rodseth  wrote:

> I see that TestActorRef is not an option with PersistentActor
>
> http://doc.akka.io/docs/akka/2.4.1/scala/testing.html#
> Synchronous_Unit_Testing_with_TestActorRef
>
> This is not the clearest paragraph, but perhaps provides an option:
>
> "It may also be required during testing, when the test subject depends on
> being instantiated at a specific path. In that case it is best to mock its
> supervisor so that it will forward the Terminated message to the
> appropriate point in the test procedure, enabling the latter to await
> proper deregistration of the name."
> http://doc.akka.io/docs/akka/current/general/addressing.
> html#Reusing_Actor_Paths
>
> Only other thing I can think of is to use akka-persistence-query APIs to
> check the event store, but that's not exactly testing recover.
>
> Thanks for any other ideas.
>
>
>
> On Thu, Dec 1, 2016 at 11:24 PM, Roland Kuhn  wrote:
>
>> Well, it is solved in Akka Typed: removing system.actorOf() and
>> system.stop() is the only way to "solve" this. The reason is that the
>> semantics of these methods are incompatible with the distributed nature of
>> the ActorSystem.
>>
>> Regards, Roland
>>
>> Sent from my iPhone
>>
>> On 2 Dec 2016, at 08:12, Viktor Klang  wrote:
>>
>> Good question!
>>
>> The notification of its death hadn't reached the closest of kin (its
>> parent) so they hadn't even put it in the ground when you proposed to
>> create a new one and call it the same thing, so they (rightfully so)
>> objected to that suggestion.
>>
>> This trips people up every now and then, but I've never seen a proposal
>> to solve it.
>>
>> --
>> Cheers,
>> √
>>
>> On Dec 2, 2016 02:44, "Richard Rodseth"  wrote:
>>
>>> We have a unit test for a persistent actor, which instantiates a second
>>> instance after waiting for termination of the first.
>>>
>>> watch(definitionReader)
>>>
>>> system.stop(definitionReader)
>>>
>>> expectTerminated(definitionReader)
>>>
>>> val notificationDefinitionReader2 = system.actorOf(actorProps, actorName
>>> )
>>>
>>> This test fails intermittently on Bamboo
>>>
>>> actor name [name1] is not unique!
>>>
>>> Any ideas?
>>>
>>>
>>> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >> Search the archives: https://groups.google.com/grou
>>> p/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+unsubscr...@googlegroups.com.
>>> To post to this group, send email to akka-user@googlegroups.com.
>>> Visit this group at https://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: http://doc.akka.io/docs/akka/c
>> urrent/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: http://doc.akka.io/docs/akka/c
>> urrent/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at 

Re: [akka-user] akka networking for thousands of small messages

[Konrad Malawski]

Hi, anyone knows if say I got 2 actors which send very quickly thousands of
small messages between them.

Millions of small messages is the happy case for Akka - this is exactly
what Actors love :-)

We've reached 700k+ 100byte sized messages per second on the new remoting
recently, and aim to still improve there.


Will akka do any groupping of the messages and send them in batches in
order to reduce network traffic?

Grouping would not reduce traffic, you still need to carry the same amount
of information. It would even hurt latency to do grouping actually, so no,
we don't do that.

We do smart things in the new remoting (Artery), which we're about to
publish a blog post series about - please watch akka.io/blog

For example, each remote actor message needs to carry around the address of
the sender and recipient (it's a string basically), and we compress these
huge strings into single integer values etc. We do things like that in
Artery: doc.akka.io/docs/akka/2.4/scala/remoting-artery.html

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Unit test for Persistent Actor Replay

[Richard Rodseth]

I see that TestActorRef is not an option with PersistentActor

http://doc.akka.io/docs/akka/2.4.1/scala/testing.html#Synchronous_Unit_Testing_with_TestActorRef

This is not the clearest paragraph, but perhaps provides an option:

"It may also be required during testing, when the test subject depends on
being instantiated at a specific path. In that case it is best to mock its
supervisor so that it will forward the Terminated message to the
appropriate point in the test procedure, enabling the latter to await
proper deregistration of the name."
http://doc.akka.io/docs/akka/current/general/addressing.html#Reusing_Actor_Paths

Only other thing I can think of is to use akka-persistence-query APIs to
check the event store, but that's not exactly testing recover.

Thanks for any other ideas.



On Thu, Dec 1, 2016 at 11:24 PM, Roland Kuhn  wrote:

> Well, it is solved in Akka Typed: removing system.actorOf() and
> system.stop() is the only way to "solve" this. The reason is that the
> semantics of these methods are incompatible with the distributed nature of
> the ActorSystem.
>
> Regards, Roland
>
> Sent from my iPhone
>
> On 2 Dec 2016, at 08:12, Viktor Klang  wrote:
>
> Good question!
>
> The notification of its death hadn't reached the closest of kin (its
> parent) so they hadn't even put it in the ground when you proposed to
> create a new one and call it the same thing, so they (rightfully so)
> objected to that suggestion.
>
> This trips people up every now and then, but I've never seen a proposal to
> solve it.
>
> --
> Cheers,
> √
>
> On Dec 2, 2016 02:44, "Richard Rodseth"  wrote:
>
>> We have a unit test for a persistent actor, which instantiates a second
>> instance after waiting for termination of the first.
>>
>> watch(definitionReader)
>>
>> system.stop(definitionReader)
>>
>> expectTerminated(definitionReader)
>>
>> val notificationDefinitionReader2 = system.actorOf(actorProps, actorName)
>>
>> This test fails intermittently on Bamboo
>>
>> actor name [name1] is not unique!
>>
>> Any ideas?
>>
>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: http://doc.akka.io/docs/akka/c
>> urrent/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] akka networking for thousands of small messages

['Kostas kougios' via Akka User List]

Hi, anyone knows if say I got 2 actors which send very quickly thousands of 
small messages between them. Will akka do any groupping of the messages and 
send them in batches in order to reduce network traffic?

Thanks

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: EntityStreamingSupport for two content types

[James Matlik]

Martynas,

Thank you for the pointer. There is a lot of good example code to digest
there, if not just for understanding how people think in the context of
marshallers. I was about to resort to creating my own entity to ByteString
flows, but hopefully i can figure out a reasonable solution based on this.

- James

On Dec 2, 2016 8:27 AM, "Martynas Mickevičius" <
martynas.mickevic...@lightbend.com> wrote:

> James, have you seen this ticket: https://github.com/
> akka/akka-http/issues/424
>
> There is an example there, which might help you.
>
> On Tue, Nov 29, 2016 at 1:43 PM, James Matlik 
> wrote:
>
>> Would any one have suggestions on how to support content negotiation with
>> a steaming Akka-HTTP response? I know i can create content type specific
>> URIs, but that doesn't lend itself to a well designed API.
>>
>> I've still not been able to find how EntityStreamingSupport can support
>> content negotiation.  Am I missing something obvious?
>>
>> Much thanks,
>> James
>>
>> On Nov 26, 2016 4:14 PM, "James Matlik"  wrote:
>>
>>> I am trying to create an Akka-HTTP streaming service that supports both
>>> JSON and protobuf.
>>>
>>> I am able to support both formats without streaming using
>>> Marshaller.oneOf(...) composition. However, I cannot seem to find something
>>> similar for EntityStreamingSupport.
>>>
>>> Would anyone have pointers on how best to handle this?
>>>
>>> Thank you,
>>> James
>>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: http://doc.akka.io/docs/akka/c
>> urrent/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: EntityStreamingSupport for two content types

[Martynas Mickevičius]

James, have you seen this ticket:
https://github.com/akka/akka-http/issues/424

There is an example there, which might help you.

On Tue, Nov 29, 2016 at 1:43 PM, James Matlik 
wrote:

> Would any one have suggestions on how to support content negotiation with
> a steaming Akka-HTTP response? I know i can create content type specific
> URIs, but that doesn't lend itself to a well designed API.
>
> I've still not been able to find how EntityStreamingSupport can support
> content negotiation.  Am I missing something obvious?
>
> Much thanks,
> James
>
> On Nov 26, 2016 4:14 PM, "James Matlik"  wrote:
>
>> I am trying to create an Akka-HTTP streaming service that supports both
>> JSON and protobuf.
>>
>> I am able to support both formats without streaming using
>> Marshaller.oneOf(...) composition. However, I cannot seem to find something
>> similar for EntityStreamingSupport.
>>
>> Would anyone have pointers on how best to handle this?
>>
>> Thank you,
>> James
>>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at https://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Balancing pool with bounded mailbox

[Sudeep Khemka]

Hi

How can I create a balancing pool with bounded mailbox? 
I tried doing as below, but seems like it ignores the value and uses its 
default unbounded mailbox

actorSystem.actorOf(BalancingPool(2
).props(Props(classOf[Test1])).withMailbox("custom-bounded-mailbox"), 
"Actor1")


custom-bounded-mailbox {

  mailbox-type = "akka.dispatch.BoundedMailbox"

  mailbox-capacity = 100

  mailbox-push-timeout-time = 5s

  

}

Thanks in Advance

-Sudeep

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.