Re: [akka-user] Debugging postStop cause within a custom stage

2017-11-02 Thread Christopher Hunt
I’m wondering if I'm seeing a problem related to 
https://github.com/akka/akka/issues/23111 
. 

My `Source.single` completes quite quickly. I also have a custom stage with an 
async callback. I have observed that the stage registers as being completed 
while the async callback hasn't been serviced. It could absolutely be something 
wrong with my test case. I'm still not clear on why my custom stage is 
registered as being completed, although I don’t see it being because of the 
materialiser shutting down.

If I concat an extra ByteString onto the Source.single then I don’t see the 
issue. Perhaps some race condition then…

Here’s my (uncomfortable) workaround: 
https://github.com/huntc/landlord/blob/3785b47a2f770ede44351b588e3b53a7cdf7d013/landlordd/daemon/src/test/scala/com/github/huntc/landlord/JvmExecutorSpec.scala#L53-L60
 


Thanks for helping me gain further insight into what’s going on.

-- 
>>  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] Debugging postStop cause within a custom stage

2017-11-02 Thread Christopher Hunt

> On 3 Nov 2017, at 8:30 am, Patrik Nordwall  wrote:
> 
> Could it be that the materializer is shutting down?
> “Abrupt termination”
> /Patrik
I don’t *think* so, as I should see that exception manifest itself in the test: 
https://github.com/huntc/landlord/blob/8671d90dba7247db517ef21b64b84d659084a02f/landlordd/daemon/src/test/scala/com/github/huntc/landlord/JvmExecutorSpec.scala#L29
 


Interestingly, if I change the Source.single to a Source.apply with a one 
element list of the byte string then I don’t see the problem… so it appears to 
be a race condition of some kind… and probably to do with the test.

I’m suspicious of this test though and so shall look further. Thanks for the 
suggestion.

-- 
>>  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 Persistance NullPointerException during actor start up

2017-11-02 Thread Prashanth Ayyavu
Thanks Patrick.
Yes it is. During recovery - One of the event persisted in (possibly)
having a null field.
This thread can be closed.

On Thu, Nov 2, 2017 at 2:37 PM, Patrik Nordwall 
wrote:

> Isn’t it thrown from PersistentDeviceActor.scala:183 ?
>
> /Patrik
>
> tis 31 okt. 2017 kl. 20:34 skrev :
>
>> Hi Akka gurus,
>>
>>1. We use Akka in a production setup
>>2. We use Cassandra as a back up for akka-persistence.
>>3. One of the PersistentActors throwed NullPointerException during
>>startup.
>>
>> *The Akka libraries used :*
>>
>> "com.typesafe.akka" %% "akka-actor" % "2.4.17",
>> "com.typesafe.akka" %% "akka-slf4j" % "2.4.17",
>> "com.typesafe.akka" %% "akka-remote" % "2.4.17",
>> "com.typesafe.akka" %% "akka-cluster" % "2.4.17",
>> "com.typesafe.akka" %% "akka-cluster-sharding" % "2.4.17",
>> "com.typesafe.akka" %% "akka-persistence" % v,
>> "com.typesafe.akka" %% "akka-persistence-cassandra" % "0.23",
>> "com.typesafe.akka" %% "akka-http-core" % "10.0.1",
>> "com.typesafe.akka" %% "akka-stream" % "2.4.17",
>> "com.typesafe.akka" %% "akka-cluster-tools" % "2.4.17"
>>
>>
>> *The receive recover method of my Actor is as follows.*
>>
>>
>>
>> override def receiveRecover: Receive = {
>>
>>  case SnapshotOffer(_, snapshot: DeviceActorReset) =>
>>  isProcessing = false
>>  task = null
>>  context.become(receiveIdleCommand())
>>
>>  case TaskParsed(parsedTask) =>
>>  isProcessing = true
>>  task = parsedTask
>>  context.become(receiveValidateCommand())
>>
>>  case TaskValidated => context.become(receiveProcessCommand)
>>
>>  case RecoveryCompleted => {
>>  logger.debug(s"Recovery completed successfully for device actor : ${
>> self.path.name}")
>>  self ! Continue
>>  }
>> }
>>
>>
>>
>> When one of the PersistentActors is started, we got 
>> java.lang.NullPointerException
>>
>>
>> *The logs are as follows*
>>
>>
>> DEBUG [com.sam.sami.argus.tasks.PersistentDeviceActor] 
>> (argus-akka.actor.default-dispatcher-5) 5643266d56c44415bc65ab7301ef938a 
>> Starting a deviceActor
>> ERROR [akka.actor.OneForOneStrategy] 
>> (argus-akka.actor.default-dispatcher-16) null
>> -java.lang.NullPointerException: null
>> :at 
>> com.sam.sami.argus.tasks.PersistentDeviceActor$$anonfun$receiveProcessCommand$1.applyOrElse(PersistentDeviceActor.scala:183)
>> -at akka.actor.Actor$class.aroundReceive(Actor.scala:497)
>> -at 
>> com.sam.sami.argus.tasks.PersistentDeviceActor.akka$persistence$Eventsourced$$super$aroundReceive(PersistentDeviceActor.scala:29)
>> -at 
>> akka.persistence.Eventsourced$$anon$1.stateReceive(Eventsourced.scala:664)
>> -at 
>> akka.persistence.Eventsourced$class.aroundReceive(Eventsourced.scala:183)
>> -at 
>> com.sam.sami.argus.tasks.PersistentDeviceActor.aroundReceive(PersistentDeviceActor.scala:29)
>> -at akka.actor.ActorCell.receiveMessage(ActorCell.scala:526)
>> -at akka.actor.ActorCell.invoke(ActorCell.scala:495)
>> -at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:257)
>> -at akka.dispatch.Mailbox.run(Mailbox.scala:224)
>> -at akka.dispatch.Mailbox.exec(Mailbox.scala:234)
>> -at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
>> -at 
>> scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
>> -at 
>> scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
>> -at 
>> scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
>> DEBUG [com.sam.sami.argus.tasks.PersistentDeviceActor] 
>> (argus-akka.actor.default-dispatcher-16) Snapshot recovery : 
>> DeviceActorReset(5643266d56c44415bc65ab7301ef938a)
>> DEBUG [com.sam.sami.argus.tasks.PersistentDeviceActor] 
>> (argus-akka.actor.default-dispatcher-5) Recovery completed successfully for 
>> device actor : 5643266d56c44415bc65ab7301ef938a
>>
>>
>> *Actor behavior or States*
>>
>> We have the following different behavior aka states for this. (I want to 
>> mention this because the state names are occurring in the above logs)
>>
>>
>>- receiveIdleCommand
>>- receiveValidateCommand
>>- receiveProcessCommand
>>
>> 5643266d56c44415bc65ab7301ef938a is just an ID we use to create actor names.
>>
>>
>> I am trying to understand what caused this.
>>
>>
>>
>> --
>> >> 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] Akka Persistance NullPointerException during actor start up

2017-11-02 Thread Patrik Nordwall
Isn’t it thrown from PersistentDeviceActor.scala:183 ?

/Patrik

tis 31 okt. 2017 kl. 20:34 skrev :

> Hi Akka gurus,
>
>1. We use Akka in a production setup
>2. We use Cassandra as a back up for akka-persistence.
>3. One of the PersistentActors throwed NullPointerException during
>startup.
>
> *The Akka libraries used :*
>
> "com.typesafe.akka" %% "akka-actor" % "2.4.17",
> "com.typesafe.akka" %% "akka-slf4j" % "2.4.17",
> "com.typesafe.akka" %% "akka-remote" % "2.4.17",
> "com.typesafe.akka" %% "akka-cluster" % "2.4.17",
> "com.typesafe.akka" %% "akka-cluster-sharding" % "2.4.17",
> "com.typesafe.akka" %% "akka-persistence" % v,
> "com.typesafe.akka" %% "akka-persistence-cassandra" % "0.23",
> "com.typesafe.akka" %% "akka-http-core" % "10.0.1",
> "com.typesafe.akka" %% "akka-stream" % "2.4.17",
> "com.typesafe.akka" %% "akka-cluster-tools" % "2.4.17"
>
>
> *The receive recover method of my Actor is as follows.*
>
>
>
> override def receiveRecover: Receive = {
>
>  case SnapshotOffer(_, snapshot: DeviceActorReset) =>
>  isProcessing = false
>  task = null
>  context.become(receiveIdleCommand())
>
>  case TaskParsed(parsedTask) =>
>  isProcessing = true
>  task = parsedTask
>  context.become(receiveValidateCommand())
>
>  case TaskValidated => context.become(receiveProcessCommand)
>
>  case RecoveryCompleted => {
>  logger.debug(s"Recovery completed successfully for device actor : ${
> self.path.name}")
>  self ! Continue
>  }
> }
>
>
>
> When one of the PersistentActors is started, we got 
> java.lang.NullPointerException
>
>
> *The logs are as follows*
>
>
> DEBUG [com.sam.sami.argus.tasks.PersistentDeviceActor] 
> (argus-akka.actor.default-dispatcher-5) 5643266d56c44415bc65ab7301ef938a 
> Starting a deviceActor
> ERROR [akka.actor.OneForOneStrategy] (argus-akka.actor.default-dispatcher-16) 
> null
> -java.lang.NullPointerException: null
> : at 
> com.sam.sami.argus.tasks.PersistentDeviceActor$$anonfun$receiveProcessCommand$1.applyOrElse(PersistentDeviceActor.scala:183)
> - at akka.actor.Actor$class.aroundReceive(Actor.scala:497)
> - at 
> com.sam.sami.argus.tasks.PersistentDeviceActor.akka$persistence$Eventsourced$$super$aroundReceive(PersistentDeviceActor.scala:29)
> - at 
> akka.persistence.Eventsourced$$anon$1.stateReceive(Eventsourced.scala:664)
> - at 
> akka.persistence.Eventsourced$class.aroundReceive(Eventsourced.scala:183)
> - at 
> com.sam.sami.argus.tasks.PersistentDeviceActor.aroundReceive(PersistentDeviceActor.scala:29)
> - at akka.actor.ActorCell.receiveMessage(ActorCell.scala:526)
> - at akka.actor.ActorCell.invoke(ActorCell.scala:495)
> - at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:257)
> - at akka.dispatch.Mailbox.run(Mailbox.scala:224)
> - at akka.dispatch.Mailbox.exec(Mailbox.scala:234)
> - at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
> - at 
> scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
> - at 
> scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
> - at 
> scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
> DEBUG [com.sam.sami.argus.tasks.PersistentDeviceActor] 
> (argus-akka.actor.default-dispatcher-16) Snapshot recovery : 
> DeviceActorReset(5643266d56c44415bc65ab7301ef938a)
> DEBUG [com.sam.sami.argus.tasks.PersistentDeviceActor] 
> (argus-akka.actor.default-dispatcher-5) Recovery completed successfully for 
> device actor : 5643266d56c44415bc65ab7301ef938a
>
>
> *Actor behavior or States*
>
> We have the following different behavior aka states for this. (I want to 
> mention this because the state names are occurring in the above logs)
>
>
>- receiveIdleCommand
>- receiveValidateCommand
>- receiveProcessCommand
>
> 5643266d56c44415bc65ab7301ef938a is just an ID we use to create actor names.
>
>
> I am trying to understand what caused this.
>
>
>
> --
> >> 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 

Re: [akka-user] Debugging postStop cause within a custom stage

2017-11-02 Thread Patrik Nordwall
Could it be that the materializer is shutting down?
“Abrupt termination”
/Patrik

tors 2 nov. 2017 kl. 04:29 skrev Christopher Hunt :

> Hi there,
>
> I've got a situation where I observe a postStop being called within my
> custom GraphStage prior to when I'd expect. I'm sure Akka is doing the
> right thing but, what's the best way to debug what is causing the postStop?
> My understanding is that the input and output connections should all have
> closed in order for postStop to be invoked. I'm not expecting the output
> connection to have been closed though.
>
> Thanks for any pointers.
>
> Cheers,
> -C
>
> --
> >> 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: Contribution to simplify FSM testing?

2017-11-02 Thread Joost den Boer
Alexandr,

I'm not familiar with PersistentFSM, but I think it should be possible.
Unfortunately it appears we are the only ones who think this is useful.
Therefore I do not know if I'm going to spend more time on it.

Cheers,
Joost


On Thu, Nov 2, 2017 at 5:28 PM, Alexandr Sova 
wrote:

> Looks really good. I'm not a framework maintainer, it's just my opinion,
> but it could be very helpful for me to have such a toolkit. Do you consider
> to make something similar for PersistentFSM?
>
>
> On Monday, March 13, 2017 at 10:58:08 AM UTC+2, Joost den Boer wrote:
>>
>> Hi,
>>
>> We are using FSM actors and I was kind of missing handy features in Akka
>> to more easily test these state machines.
>> What I wanted was a way to verify events are properly handled when FSM is
>> in a certain state, I also want to verify the behaviour of the FSM is all
>> other possible states.
>>
>> So, to support this more event driven testing, I created a simple DSL
>> which *generates ScalaTest cases* to verify the handing of an event in
>> all possible states.
>> In it's simplest version it looks like this:
>>
>> handleEvent(AnEvent()).inStates(*State1, State2*).verify { fsm =>
>>   fsm.stateName should be(State3)
>> }.otherwiseKeepCurrentState
>>
>>
>> This tests whether the handling of AnEvent in both State1 and State2
>> results in a state transition to State3. And in all other states it is
>> expected that the events does not cause a state change.
>>
>> It is also possible to setup states with a specific data value, or
>> receive not only the fsm actor, but also the event and the start state in
>> the verify function, or do a more comprehensive verification for  the other
>> states:
>>
>> handleEvent(AnotherEvent(30)).inStatesWithData(Map(
>>   State1 -> defaultData,
>>   State2 -> deviceData.copy(progress = Option(20))
>> )).verifyAll { case (fsm, event, startState) =>
>>   fsm.stateName should be (DownloadInProgress)
>>   fsm.stateData.progress.value should be (30)
>> }.otherwise { case (fsm, event, startState) =>
>>
>>   // do a more comprehensive verification. E.g. based on the startState.
>>
>> }
>>
>>
>> Using this simple DSL, I was able to very quickly define test cases for
>> all events supported by the state machines.
>> This was very helpful in to then, as a proper TDD developer ;-),
>> implement the FSM actors.
>>
>> Another 'problem' I encountered while writing test cases for FSM, was
>> that in certain end-states, I want to verify the FSM chanced into the
>> end-state and that actor is also stopped.
>> With the current TestFSMRef this is not possible, since the 'stateName'
>> and 'stateData' properties are not available anymore after the has stopped.
>>
>> To overcome this issue, I created a extension of the TestFSMRef which
>> monitors the state transitions of the FSM actor under test. This allows us
>> not only to verify the latest state of the FSM and whether the actor was
>> properly stopped, but this also allows more easy testing of complex FSMs
>> with automatic state transitions since this extension gives access to the
>> full transition log, including the data at each state.
>>
>> I am more than happy to share these features?
>> Would this DSL and TestFSMRef extension be a nice addition to the Akka
>> framework?
>> Any chance this would be accepted it I would make this into a
>> contribution to the Akka framework? Just would like to know whether
>> spending time on that would not be wasted time.
>>
>> Regards,
>> Joost
>>
> --
> >> 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/pmowYVxu0pw/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.


[akka-user] Re: Contribution to simplify FSM testing?

2017-11-02 Thread Alexandr Sova
Looks really good. I'm not a framework maintainer, it's just my opinion, 
but it could be very helpful for me to have such a toolkit. Do you consider 
to make something similar for PersistentFSM?

On Monday, March 13, 2017 at 10:58:08 AM UTC+2, Joost den Boer wrote:
>
> Hi,
>
> We are using FSM actors and I was kind of missing handy features in Akka 
> to more easily test these state machines.
> What I wanted was a way to verify events are properly handled when FSM is 
> in a certain state, I also want to verify the behaviour of the FSM is all 
> other possible states.
>
> So, to support this more event driven testing, I created a simple DSL 
> which *generates ScalaTest cases* to verify the handing of an event in 
> all possible states.
> In it's simplest version it looks like this:
>
> handleEvent(AnEvent()).inStates(*State1, State2*).verify { fsm =>
>   fsm.stateName should be(State3)
> }.otherwiseKeepCurrentState
>
>
> This tests whether the handling of AnEvent in both State1 and State2 
> results in a state transition to State3. And in all other states it is 
> expected that the events does not cause a state change.
>
> It is also possible to setup states with a specific data value, or receive 
> not only the fsm actor, but also the event and the start state in the 
> verify function, or do a more comprehensive verification for  the other 
> states:
>
> handleEvent(AnotherEvent(30)).inStatesWithData(Map(
>   State1 -> defaultData,
>   State2 -> deviceData.copy(progress = Option(20))
> )).verifyAll { case (fsm, event, startState) =>
>   fsm.stateName should be (DownloadInProgress)
>   fsm.stateData.progress.value should be (30)
> }.otherwise { case (fsm, event, startState) =>
>
>   // do a more comprehensive verification. E.g. based on the startState.
>
> }
>
>
> Using this simple DSL, I was able to very quickly define test cases for 
> all events supported by the state machines.
> This was very helpful in to then, as a proper TDD developer ;-), implement 
> the FSM actors.
>
> Another 'problem' I encountered while writing test cases for FSM, was that 
> in certain end-states, I want to verify the FSM chanced into the end-state 
> and that actor is also stopped.
> With the current TestFSMRef this is not possible, since the 'stateName' 
> and 'stateData' properties are not available anymore after the has stopped.
>
> To overcome this issue, I created a extension of the TestFSMRef which 
> monitors the state transitions of the FSM actor under test. This allows us 
> not only to verify the latest state of the FSM and whether the actor was 
> properly stopped, but this also allows more easy testing of complex FSMs 
> with automatic state transitions since this extension gives access to the 
> full transition log, including the data at each state.
>
> I am more than happy to share these features?
> Would this DSL and TestFSMRef extension be a nice addition to the Akka 
> framework?
> Any chance this would be accepted it I would make this into a contribution 
> to the Akka framework? Just would like to know whether spending time on 
> that would not be wasted time. 
>
> Regards,
> Joost
>

-- 
>>  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] Re: FSM, how to make stateTimeout relative?

2017-11-02 Thread Alexandr Sova
Should be pointed to RTFM. There is a method `forMax` that can set 
different timeout for particular state changes. I knew I'm missing 
something.
Now I have different problem: how can I test that timeout occur with 
PersistentFSM? I can't use TestFSMRef because it's not FSM, it's 
PersistentFSM (not extends akka.actor.FSM), I should use Asynchronous 
Testing: TestKit 

 and 
I can't rely on expectMsgClass(classOf[PersistentFSM.TimeoutMarker]) 
because PersistentFSM.TimeoutMarker is private[persistence].

Maybe anyone have already solved it?

On Thursday, November 2, 2017 at 1:43:30 PM UTC+2, Alexandr Sova wrote:
>
> Yeah, I'm doing such thing at system.dispatcher.scheduleOnce but if I'd 
> use this at when(state, duration) wouldn't duration be computed only at 
> Actor start/creation? Even lazy may not be helpful because it'll compute 
> only once and will return the same value again and again.
>
> On Thursday, November 2, 2017 at 5:44:55 AM UTC+2, Christopher Hunt wrote:
>>
>> Perhaps something like this in order to get your FiniteDuration:
>>
>> Duration.ofMillis(
>>   ChronoUnit.MILLIS.between(
>> ZonedDateTime.parse("2007-12-03T10:15:30+01:00[Europe/Paris]"), 
>> ZonedDateTime.now
>>   )
>> )
>>
>>

-- 
>>  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] missing serialization-bindings for ClusterSingletonProxy$TryToIdentifySingleton$ [akka-cluster-2.5.3]

2017-11-02 Thread Patrik Nordwall
You are probably running with config akka.actor.serialize-messages = on
It could be fixed by TryToIdentifySingleton extends
NoSerializationVerificationNeeded, please open a pull request if you like.

/Patrik

On Thu, Nov 2, 2017 at 1:11 PM, Christophe Pache  wrote:

> Hello everyone!
>
> I notice in our logs the following exception and would like to understand
> what is really happening:
>
> java.io.NotSerializableException: No configured serialization-bindings
>> for class [akka.cluster.singleton.ClusterSingletonProxy$TryToIde
>> ntifySingleton$]
>
>
> In my opinion, this message should not be sent remotely anyway, this is an
> internal message the ClusterSingletonProxy schedules to himself.  Might
> this be when ClusterSingletonProxy stops (doesn't seam to have graceful
> shutdown not scheduled message handling in case of MemberRemoved)?
>
> I'm pretty sure it's just a log issue as the whole system looks like
> working find, but would be really interested into getting a bit what's
> happening. Many thanks in advance!
>
> Cheers,
> Christophe
>
> here is the complete stack trace:
>
>>
>> java.io.NotSerializableException: No configured serialization-bindings
>> for class [akka.cluster.singleton.ClusterSingletonProxy$TryToIde
>> ntifySingleton$] at 
>> akka.serialization.Serialization.serializerFor(Serialization.scala:236)
>> at 
>> akka.serialization.Serialization.findSerializerFor(Serialization.scala:212)
>> at akka.remote.MessageSerializer$.serialize(MessageSerializer.scala:44)
>> at akka.remote.EndpointWriter.$anonfun$serializeMessage$1(Endpoint.scala:889)
>> at scala.util.DynamicVariable.withValue(DynamicVariable.scala:58) at
>> akka.remote.EndpointWriter.serializeMessage(Endpoint.scala:889) at
>> akka.remote.EndpointWriter.writeSend(Endpoint.scala:780) at
>> akka.remote.EndpointWriter$$anonfun$4.applyOrElse(Endpoint.scala:755) at
>> akka.actor.Actor.aroundReceive(Actor.scala:513) at akka.actor.Actor.
>> aroundReceive$(Actor.scala:511) at akka.remote.EndpointActor.
>> aroundReceive(Endpoint.scala:446) at akka.actor.ActorCell.
>> receiveMessage(ActorCell.scala:527) at akka.actor.ActorCell.invoke_
>> aroundBody0(ActorCell.scala:496) at akka.actor.ActorCell$
>> AjcClosure1.run(ActorCell.scala:1) at org.aspectj.runtime.reflect.
>> JoinPointImpl.proceed(JoinPointImpl.java:149) at
>> akka.kamon.instrumentation.ActorMonitors$$anon$1.$
>> anonfun$processMessage$1(ActorMonitor.scala:63) at kamon.trace.Tracer$.
>> withContext(TracerModule.scala:58) at akka.kamon.instrumentation.
>> ActorMonitors$$anon$1.processMessage(ActorMonitor.scala:63) at
>> akka.kamon.instrumentation.ActorCellInstrumentation.
>> aroundBehaviourInvoke(ActorInstrumentation.scala:45) at
>> akka.actor.ActorCell.invoke(ActorCell.scala:489) at
>> akka.dispatch.Mailbox.processMailbox(Mailbox.scala:257) at
>> akka.dispatch.Mailbox.run(Mailbox.scala:224) at
>> akka.dispatch.Mailbox.exec(Mailbox.scala:234) at akka.dispatch.forkjoin.
>> ForkJoinTask.doExec(ForkJoinTask.java:260) at akka.dispatch.forkjoin.
>> ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339) at
>> akka.dispatch.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979) at
>> akka.dispatch.forkjoin.ForkJoinWorkerThread.run(
>> ForkJoinWorkerThread.java:107)
>>
>
> see how it is used here: https://github.com/akka/akka/
> search?utf8=%E2%9C%93=TryToIdentifySingleton=
>
>
>
> --
> >> 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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend  -  Reactive apps on the JVM
Twitter: @patriknw

-- 
>>  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] ActorSystem FatalError Handling

2017-11-02 Thread Konrad “ktoso” Malawski
When such errors are thrown all bets are off basically, in any app, not
just akka.

You can turn off the system automatically terminating — check
reference.conf, though as I said — all bets are off then anyway because
runtime is in potentially “bad state"

-- 
Cheers,
Konrad 'ktoso ' Malawski
Akka  @ Lightbend 

On November 2, 2017 at 22:08:39, Mücahit Kantepe (mucahitkant...@gmail.com)
wrote:

If any Actor in ActorSystem throws a fatal error(StackOverFlowError,
OutOfMemoryError etc.) akka.actor.ActorSystemImpl shutdowns JVM or
shutdowns only ActorSystem. In configuration we can only change the
shutdown JVM behavior but I want to do some custom things before shutting
down the JVM, like pushing memory dump to somewhere when fatal error
occurs. As far as I see there is no option like onFatalErrorHook.

Configuring as not to shutdown JVM when fatal error occurs, only shutdowns
ActorSystem but since there is no flag for termination reason(I do shutdown
ActorSystem for some reasons), I could not found any way to trigger some
procedure after fatal error occurs.

Am I missing something?
--
>> 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] ActorSystem FatalError Handling

2017-11-02 Thread Mücahit Kantepe
If any Actor in ActorSystem throws a fatal error(StackOverFlowError, 
OutOfMemoryError etc.) akka.actor.ActorSystemImpl shutdowns JVM or 
shutdowns only ActorSystem. In configuration we can only change the 
shutdown JVM behavior but I want to do some custom things before shutting 
down the JVM, like pushing memory dump to somewhere when fatal error 
occurs. As far as I see there is no option like onFatalErrorHook. 

Configuring as not to shutdown JVM when fatal error occurs, only shutdowns 
ActorSystem but since there is no flag for termination reason(I do shutdown 
ActorSystem for some reasons), I could not found any way to trigger some 
procedure after fatal error occurs.

Am I missing something?

-- 
>>  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] missing serialization-bindings for ClusterSingletonProxy$TryToIdentifySingleton$ [akka-cluster-2.5.3]

2017-11-02 Thread Christophe Pache
Hello everyone! 

I notice in our logs the following exception and would like to understand 
what is really happening:

java.io.NotSerializableException: No configured serialization-bindings for 
> class [akka.cluster.singleton.ClusterSingletonProxy$TryToIdentifySingleton
> $]


In my opinion, this message should not be sent remotely anyway, this is an 
internal message the ClusterSingletonProxy schedules to himself.  Might 
this be when ClusterSingletonProxy stops (doesn't seam to have graceful 
shutdown not scheduled message handling in case of MemberRemoved)? 

I'm pretty sure it's just a log issue as the whole system looks like 
working find, but would be really interested into getting a bit what's 
happening. Many thanks in advance!

Cheers,
Christophe

here is the complete stack trace:

>
> java.io.NotSerializableException: No configured serialization-bindings for 
> class 
> [akka.cluster.singleton.ClusterSingletonProxy$TryToIdentifySingleton$] at 
> akka.serialization.Serialization.serializerFor(Serialization.scala:236) at 
> akka.serialization.Serialization.findSerializerFor(Serialization.scala:212) 
> at akka.remote.MessageSerializer$.serialize(MessageSerializer.scala:44) at 
> akka.remote.EndpointWriter.$anonfun$serializeMessage$1(Endpoint.scala:889) 
> at scala.util.DynamicVariable.withValue(DynamicVariable.scala:58) at 
> akka.remote.EndpointWriter.serializeMessage(Endpoint.scala:889) at 
> akka.remote.EndpointWriter.writeSend(Endpoint.scala:780) at 
> akka.remote.EndpointWriter$$anonfun$4.applyOrElse(Endpoint.scala:755) at 
> akka.actor.Actor.aroundReceive(Actor.scala:513) at 
> akka.actor.Actor.aroundReceive$(Actor.scala:511) at 
> akka.remote.EndpointActor.aroundReceive(Endpoint.scala:446) at 
> akka.actor.ActorCell.receiveMessage(ActorCell.scala:527) at 
> akka.actor.ActorCell.invoke_aroundBody0(ActorCell.scala:496) at 
> akka.actor.ActorCell$AjcClosure1.run(ActorCell.scala:1) at 
> org.aspectj.runtime.reflect.JoinPointImpl.proceed(JoinPointImpl.java:149) 
> at 
> akka.kamon.instrumentation.ActorMonitors$$anon$1.$anonfun$processMessage$1(ActorMonitor.scala:63)
>  
> at kamon.trace.Tracer$.withContext(TracerModule.scala:58) at 
> akka.kamon.instrumentation.ActorMonitors$$anon$1.processMessage(ActorMonitor.scala:63)
>  
> at 
> akka.kamon.instrumentation.ActorCellInstrumentation.aroundBehaviourInvoke(ActorInstrumentation.scala:45)
>  
> at akka.actor.ActorCell.invoke(ActorCell.scala:489) at 
> akka.dispatch.Mailbox.processMailbox(Mailbox.scala:257) at 
> akka.dispatch.Mailbox.run(Mailbox.scala:224) at 
> akka.dispatch.Mailbox.exec(Mailbox.scala:234) at 
> akka.dispatch.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260) at 
> akka.dispatch.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339) 
> at akka.dispatch.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979) at 
> akka.dispatch.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
>

see how it is used here: 
https://github.com/akka/akka/search?utf8=%E2%9C%93=TryToIdentifySingleton=



-- 
>>  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] Re: FSM, how to make stateTimeout relative?

2017-11-02 Thread Alexandr Sova
Yeah, I'm doing such thing at system.dispatcher.scheduleOnce but if I'd use 
this at when(state, duration) wouldn't duration be computed only at Actor 
start/creation? Even lazy may not be helpful because it'll compute only 
once and will return the same value again and again.

On Thursday, November 2, 2017 at 5:44:55 AM UTC+2, Christopher Hunt wrote:
>
> Perhaps something like this in order to get your FiniteDuration:
>
> Duration.ofMillis(
>   ChronoUnit.MILLIS.between(
> ZonedDateTime.parse("2007-12-03T10:15:30+01:00[Europe/Paris]"), 
> ZonedDateTime.now
>   )
> )
>
>

-- 
>>  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: PersistentActor + akka streams

2017-11-02 Thread Yaroslav Klymko
Hi, 
I've already implemented this with help of mapAsync calls and some tricks 
for sharding to not loose enqueued messages during rebalance. In then end 
this improved our throughput.
 

On Thursday, November 2, 2017 at 10:03:36 AM UTC+1, Akka Team wrote:
>
> No current plans about anything specifically related to interacting with 
> persistent actors, couldn't batch + mapAsync(1)(ask-persistent-actor) do 
> what you want?
>
> --
> Johan
> Akka Team
>
> On Wed, Sep 13, 2017 at 3:50 PM,  
> wrote:
>
>> I have the same question ? 
>>
>> On Wednesday, September 13, 2017 at 1:32:13 AM UTC+4:30, Yaroslav Klymko 
>> wrote:
>>>
>>> Hi guys, 
>>>
>>> I'm wondering are there any plans to provide integration between akka 
>>> streams and PersistentActor ?
>>> The feature I'm interested in particular is `FlowOps.batch`, so I could 
>>> batch commands, while events are being persisted, and then persist all 
>>> events produced by stashed commands atomically. This will significantly 
>>> increase throughout.
>>>
>>> Best regards.
>>>
>> -- 
>> >> 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+...@googlegroups.com .
>> To post to this group, send email to akka...@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] Akka Stream Tcp Messaging Server POC

2017-11-02 Thread Akka Team
What is happening when you run the code and how is that different from what
you expect?

--
Johan
Akka Team

On Mon, Aug 7, 2017 at 2:16 PM, G J  wrote:

> I'm new Akka stream, I have to build on poc on Akka stream for instant
> messaging. So I need a help to understand what I'm missing here.
>
>
> import java.net.InetSocketAddress;
> import java.util.concurrent.CompletionStage;
>
> import akka.Done;
> import akka.actor.ActorRef;
> import akka.actor.Props;
> import akka.actor.UntypedActor;
> import akka.stream.javadsl.Sink;
> import akka.stream.javadsl.Tcp;
>
> /**
>  * Created by gaurav on 28/7/17.
>  */
> public class Server {
>public static void main(String[] args) {
>   InetSocketAddress serverAddress = new InetSocketAddress("127.0.0.1", 
> 6000);
>   final Sink handler = 
> Sink.foreach(conn -> {
>  System.out.println("Client connected from: " + conn.remoteAddress());
>  conn.handleWith(ActorFlow.actorRef(out -> 
> MyWebSocketActor.props(out)), InternalWebSocketHelper.actorMaterializer());
>   });
>   final CompletionStage bindingFuture = 
> Tcp.get(InternalWebSocketHelper.actorSystem())
> .bind(serverAddress.getHostString(), 
> serverAddress.getPort()).to(handler).run(InternalWebSocketHelper.actorMaterializer());
>
>   bindingFuture.whenComplete((binding, throwable) -> {
>  System.out.println("Server started, listening on: " + 
> binding.localAddress());
>   });
>
>   bindingFuture.exceptionally(e -> {
>  System.err.println("Server could not bind to " + serverAddress + " : 
> " + e.getMessage());
>  InternalWebSocketHelper.actorSystem().terminate();
>  return null;
>   });
>
>}
>
>private static class MyWebSocketActor extends UntypedActor {
>
>   private final ActorRef out;
>
>   public MyWebSocketActor(ActorRef out) {
>  this.out = out;
>   }
>
>   public static Props props(ActorRef out) {
>  return Props.create(MyWebSocketActor.class, () -> new 
> MyWebSocketActor(out));
>   }
>
>   public void onReceive(Object message) throws Exception {
>  out.tell(message, ActorRef.noSender());
>   }
>}
> }
>
>
>
>
>
>
>
>
> /**
>  * Created by gaurav on 1/8/17.
>  */
>
> import java.util.function.Function;
>
> import org.reactivestreams.Publisher;
>
> import akka.NotUsed;
> import akka.actor.*;
> import akka.japi.Pair;
> import akka.stream.Materializer;
> import akka.stream.OverflowStrategy;
> import akka.stream.javadsl.*;
>
> public class ActorFlow {
>
>public static  Flow actorRef(Function Props> props) {
>   return actorRef(props, 1000, OverflowStrategy.dropNew(), 
> InternalWebSocketHelper.actorSystem(), 
> InternalWebSocketHelper.actorMaterializer());
>}
>
>public static  Flow actorRef(Function Props> props, int bufferSize, OverflowStrategy overflowStrategy,
>  ActorRefFactory factory, Materializer mat) {
>
>   Pair pair = Source. actorRef(bufferSize, 
> overflowStrategy)
> .toMat(Sink.asPublisher(AsPublisher.WITHOUT_FANOUT), 
> Keep.both()).run(mat);
>
>   return Flow.fromSinkAndSource(
> 
> Sink.actorRef(factory.actorOf(Props.create(WebSocketFlowActor.class, () -> 
> new WebSocketFlowActor(props, pair.first(,
>   new Status.Success(new Object())),
> Source.fromPublisher(pair.second()));
>}
>
>private static class WebSocketFlowActor extends UntypedActor {
>
>   private final ActorRef flowActor;
>
>   public WebSocketFlowActor(Function props, ActorRef 
> ref) {
>  flowActor = context().watch(context().actorOf(props.apply(ref), 
> "flowActor"));
>   }
>
>   @Override
>   public void onReceive(Object message) throws Throwable {
>  if (message instanceof Status.Success) {
> flowActor.tell(PoisonPill.getInstance(), getSelf());
>  } else if (message instanceof Terminated) {
> context().stop(getSelf());
>  } else {
> flowActor.tell(message, getSelf());
>  }
>   }
>
>   @Override
>   public SupervisorStrategy supervisorStrategy() {
>  return SupervisorStrategy.stoppingStrategy();
>   }
>}
> }
>
>
>
>
>
>
> import akka.actor.ActorSystem;
> import akka.stream.ActorMaterializer;
>
> public class InternalWebSocketHelper {
>
>static ActorSystem actorSystem = ActorSystem.create();
>static ActorMaterializer actorMaterializer = 
> ActorMaterializer.create(actorSystem);
>
>static ActorSystem actorSystem() {
>   return actorSystem;
>}
>
>static ActorMaterializer actorMaterializer() {
>   return actorMaterializer;
>}
> }
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> 

Re: [akka-user] Re: PersistentActor + akka streams

2017-11-02 Thread Akka Team
No current plans about anything specifically related to interacting with
persistent actors, couldn't batch + mapAsync(1)(ask-persistent-actor) do
what you want?

--
Johan
Akka Team

On Wed, Sep 13, 2017 at 3:50 PM,  wrote:

> I have the same question ?
>
> On Wednesday, September 13, 2017 at 1:32:13 AM UTC+4:30, Yaroslav Klymko
> wrote:
>>
>> Hi guys,
>>
>> I'm wondering are there any plans to provide integration between akka
>> streams and PersistentActor ?
>> The feature I'm interested in particular is `FlowOps.batch`, so I could
>> batch commands, while events are being persisted, and then persist all
>> events produced by stashed commands atomically. This will significantly
>> increase throughout.
>>
>> Best regards.
>>
> --
> >> 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] Get future response with non blocking the current thread

2017-11-02 Thread Tim Moore
Hi,

I'm afraid what you're asking for isn't possible. Blocking means stopping
and waiting for the result. To avoid blocking, you can't wait until you
have the result, instead you need to chain actions onto the Future to
perform asynchronously once the result is available.

In your case, the getContactList() method will need to return
Future instead of List (or, the more common way to
do this in Java is to use CompletionStage

and
PatternsCS.ask
 instead
of Patterns.ask, so the method would return CompletionStage).
Then the caller of that method would need to continue to use asynchronous
methods to perform further actions with the results.

This blog post provides a decent introduction to the concepts
http://millross-consultants.com/completion-stage-future-introduction.html

Best,
Tim

On Thu, Nov 2, 2017 at 4:30 PM, soumya nagamalla <
nagamallasoumy...@gmail.com> wrote:

> Hi,
> I got  response from ask command but  i don't want to send that future
> response to another actor,I converted (Typecast) that future response as
> List and i return that list, for that i  used *await.result* but it is
> *blocking* the current thread .Can you help me to find the way to get
> future response *without blocking* and that can be *typecast to List*.
>
> My java code is like:
>
>   public List getContactList(){
> List result = new ArrayList<>();
> Timeout timeout = new Timeout(Duration.create(5, "seconds"));
> String msg="hello";
> Future future = Patterns.ask(contactActor, msg,
> timeout);
> try{
>  result = (List ) Await.result(future,
> timeout.duration());
> }catch (Exception e){
> e.printStackTrace();
> }
> return result;
>
> }
>
>
>
> --
> >> 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.
>



-- 
Tim Moore
*Senior Engineer, Lagom, Lightbend, Inc.*
tim.mo...@lightbend.com
+61 420 981 589
Skype: timothy.m.moore



-- 
>>  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] Get future response with non blocking the current thread

2017-11-02 Thread soumya nagamalla
Hi,
I got  response from ask command but  i don't want to send that future 
response to another actor,I converted (Typecast) that future response as 
List and i return that list, for that i  used *await.result* but it is 
*blocking* the current thread .Can you help me to find the way to get 
future response *without blocking* and that can be *typecast to List*.

My java code is like:

  public List getContactList(){
List result = new ArrayList<>();
Timeout timeout = new Timeout(Duration.create(5, "seconds"));
String msg="hello";
Future future = Patterns.ask(contactActor, msg, 
timeout);
try{
 result = (List ) Await.result(future, 
timeout.duration());
}catch (Exception e){
e.printStackTrace();
}
return result;

}

 

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