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

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

2016-12-02 Thread 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] Unit test for Persistent Actor Replay

2016-12-02 Thread 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,

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

2016-12-02 Thread 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

2016-12-02 Thread 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

2016-12-02 Thread 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

2016-12-02 Thread 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

2016-12-02 Thread 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] Unit test for Persistent Actor Replay

2016-12-02 Thread 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.

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

2016-12-01 Thread Roland Kuhn

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 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

2016-12-01 Thread Viktor Klang

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.

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

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

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

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

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

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

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

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

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

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

10 matches

Site Navigation

Mail list logo

Footer information