Re: [akka-user] Improving Akka Persistence wrt CQRS/ES/DDD

[Martin Krasser]

On 28.07.14 23:40, Konrad Malawski wrote:
Rephrasing my ordering question actually (it started out as something 
else and ended up as weirdly worded):
I was thinking if the guarantees should be "time in system" or happens 
before as known by sequence numbers in concreten ids's (A-1 before 
A-2, but B-1 before B-2, but I don't care about A and B relation).


- a total order per persistenceId based on sequence numbers (= partial 
ordering in the "all events" stream) is a must have IMO.
- ordering based on timestamps should be an application level concern (= 
timestamps in application-defined events and (re-)ordering done by 
application)
- mid/long-term goal: causal ordering (allows moving from eventual 
consistency to causal consistency). See also Don't Settle For Eventual 
Consistency .



Curious about your real world use cases in other words.
Less caring about ordering makes way for faster replays of course - so 
that's what I'm after here (perhaps thinking to far ahead though).


-- k

W dniu poniedziałek, 28 lipca 2014 22:49:00 UTC+2 użytkownik Konrad 
Malawski napisał:


Hi everyone,
thanks for your feedback and ideas.

So the stream / view on multiple persistentIds (or “tags” - would
solve Greg’s example case) is coming, we just have not yet have
had the time to work on it.
One thing that ties in into them is reactive streams. We would
like to expose these event streams as akka streams.
Esp. since they provide they provide things like merge / filter /
tee which I believe would help a lot in these kinds of event
streams :-)

From the streams point of view abstracting if it’s polling or
DB-side initiated events the APIs won’t have to change.
I do agree / like Martin’s suggestion that in “normal dbs” (no
events when someone does an insert) we should be able to implement
this with some housekeeping done by the plugins.

One question about EventStore, in the case of reading from
multiple replication groups is the ordering based simply on
write-timestramp not-descending order?
The timestamp is obviously skewed a bit (multiple servers/clocks
do writes) but in the apps you work with would this be ok as
source of ordering in case of the “all events” stream?


PS: Most of the team is on holiday this week, it’s reasonable to
expect they’ll chime in some time next week.

-- 


Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

--
>> 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.


--
Martin Krasser

blog:http://krasserm.blogspot.com
code:http://github.com/krasserm
twitter: http://twitter.com/mrt1nz

--

 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Improving Akka Persistence wrt CQRS/ES/DDD

[Konrad Malawski]

Rephrasing my ordering question actually (it started out as something else 
and ended up as weirdly worded):
I was thinking if the guarantees should be "time in system" or happens 
before as known by sequence numbers in concreten ids's (A-1 before A-2, but 
B-1 before B-2, but I don't care about A and B relation).
Curious about your real world use cases in other words.
Less caring about ordering makes way for faster replays of course - so 
that's what I'm after here (perhaps thinking to far ahead though).

-- k

W dniu poniedziałek, 28 lipca 2014 22:49:00 UTC+2 użytkownik Konrad 
Malawski napisał:
>
> Hi everyone,
> thanks for your feedback and ideas.
>
> So the stream / view on multiple persistentIds (or “tags” - would solve 
> Greg’s example case) is coming, we just have not yet have had the time to 
> work on it.
> One thing that ties in into them is reactive streams. We would like to 
> expose these event streams as akka streams.
> Esp. since they provide they provide things like merge / filter / tee 
> which I believe would help a lot in these kinds of event streams :-)
>
> From the streams point of view abstracting if it’s polling or DB-side 
> initiated events the APIs won’t have to change.
> I do agree / like Martin’s suggestion that in “normal dbs” (no events when 
> someone does an insert) we should be able to implement this with some 
> housekeeping done by the plugins.
>
> One question about EventStore, in the case of reading from multiple 
> replication groups is the ordering based simply on write-timestramp 
> not-descending order?
> The timestamp is obviously skewed a bit (multiple servers/clocks do 
> writes) but in the apps you work with would this be ok as source of 
> ordering in case of the “all events” stream?
>
>
> PS: Most of the team is on holiday this week, it’s reasonable to expect 
> they’ll chime in some time next week.
>
> -- 
> Konrad 'ktoso' Malawski
> hAkker @ typesafe
> http://akka.io
>

-- 
>>  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Best practices using Akka Persistence with long-running projects?

[Konrad Malawski]

Hello Martin,
yeah, that looks like what I had in mind.

And yeah, translating to/from proto is always a bit of verboseness
somewhere, here's how we try to minimise the verboseness (serializer impl):
https://github.com/akka/akka/blob/release-2.3/akka-persistence/src/main/scala/akka/persistence/serialization/MessageSerializer.scala#L51

Sadly, the serializers that are slick and nice to work with, don't usually
have versioning/evolution built in from what I see available...
Kryo is fast and using it is great, but no versioning / anything built in
=> no-go for this use case (IMO at least).


On Fri, Jul 25, 2014 at 6:42 PM, Martin Simons  wrote:

>
>
> Am Donnerstag, 24. Juli 2014 11:51:57 UTC+2 schrieb Konrad Malawski:
>
>>
>> I know I’ve just grown your to-read list by quite a bit, but I hope this
>> helps! :-)
>>
>>
> Glad you did ;-)
>
> I at least skimmed all the articles you posted and decided that Protobuf
> is probably the most common thing to use. I went on to hack together a
> small example project, trying to keep the amount of boilerplate code per
> class as low as possible as it will be required for each and every event
> and state class that might be added in the future. No matter how one does
> it, it will always look more or less messy when translating Protobuf Java
> objects to Scala case classes, I'm afraid.
>
> The result of my humble attempts can be found here:
> https://github.com/lunikon/akka-persistence-serialization The code is
> still a mess, obviously, but do you see a general problem with this
> approach (the approach being that one defines an "adapter" for every case
> class and registers it with a static registry which is then used by the
> Akka Serializer implementation)?
>
>
>
> --
> >> 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 http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe



-- 
>>  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Improving Akka Persistence wrt CQRS/ES/DDD

[Konrad 'ktoso' Malawski]

Hi everyone,
thanks for your feedback and ideas.

So the stream / view on multiple persistentIds (or “tags” - would solve Greg’s 
example case) is coming, we just have not yet have had the time to work on it.
One thing that ties in into them is reactive streams. We would like to expose 
these event streams as akka streams.
Esp. since they provide they provide things like merge / filter / tee which I 
believe would help a lot in these kinds of event streams :-)

>From the streams point of view abstracting if it’s polling or DB-side 
>initiated events the APIs won’t have to change.
I do agree / like Martin’s suggestion that in “normal dbs” (no events when 
someone does an insert) we should be able to implement this with some 
housekeeping done by the plugins.

One question about EventStore, in the case of reading from multiple replication 
groups is the ordering based simply on write-timestramp not-descending order?
The timestamp is obviously skewed a bit (multiple servers/clocks do writes) but 
in the apps you work with would this be ok as source of ordering in case of the 
“all events” stream?


PS: Most of the team is on holiday this week, it’s reasonable to expect they’ll 
chime in some time next week.
-- 

Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

-- 
>>  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: akka persistence cleanup old snapshots files

[Konrad 'ktoso' Malawski]

Please open an issue on our github issue tracker, 
https://github.com/akka/akka/issues
Thanks a lot!

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

-- 
>>  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: akka persistence cleanup old snapshots files

[Rohit Kumar Gupta]

>
> Johannessen and Konard,
>

Thanks for your replies. Can you get me the link where I can raise the 
issue ?


Thanks,
Rohit 

-- 
>>  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Pooled router initialisation

[Jabbar Azam]

Hello,

I want to create a pooled router but I want to pass an database session 
object to each routee. How  do I do this? Do I need to create my own 
routees and pass their path to the router?

-- 
>>  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: akka persistence cleanup old snapshots files

[Konrad 'ktoso' Malawski]

That’s another nice to have improvement, please create an issue Rohit.
Currently you would have to implement this on your own.

— k

On 26 July 2014 at 19:41:10, ahjohannessen (ahjohannes...@gmail.com) wrote:

I think it would be useful to have a setting a la "keep-at-most-nr-snapshots". 
I believe that is beneficial for all users, you should create an issue at 
github :)

On Saturday, July 26, 2014 9:08:39 AM UTC+1, Rohit Kumar Gupta wrote:
Hello,

I am using akka persistence (akka 2.3.4 & play 2.3.1) in my akka based 
ProductCluster. I am taking snapshot every 10 secs in the master process. What 
I notice is that, the snapshot folder keep growing and becomes huge. As I 
understand that once I take a snapshot I don't need the older snapshots (except 
for later debugging/postmortem). How can I configure akka to do this 
automatically. I know that PersistentActor has api deleteMessages that takes a 
selection criteria.

Any pointers will be helpful.

Thanks,
Rohit
--
>> 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

-- 
>>  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Akka Actor Per Request Java Sample

[John Haigh]

Further to this I created a sample at 
https://github.com/haighis/java-jersey-akka-backend-actor. This is written 
entirely in Java and is based on the sample at 
https://github.com/pofallon/jersey2-akka-java. 

This sample demonstrates:

- using actor selection - see 
below. 
https://github.com/haighis/java-jersey-akka-backend-actor/blob/master/src/main/java/com/paulsamiq/jersey2akka/ExampleService.java
- a backend actor that will contain jdbc data access code to save to a 
database

@Context ActorSystem actorSystem;
LoggingAdapter log;

@POST
@Path("/post")
@Consumes(MediaType.APPLICATION_JSON)
@Produces(MediaType.APPLICATION_JSON)
public Response save(LogMessage message)
{
ActorSelection selection = 
actorSystem.actorSelection("akka://ExampleSystem/user/frontend");

selection.tell(new LogMessage(message.getTitle()), 
ActorRef.noSender());

String result = "done " + message;
return Response.status(201).entity(result).build();
}


On Friday, July 25, 2014 5:23:06 AM UTC-4, Akka Team wrote:
>
> Hi John,
>
>
>> // Here a reference to the backend actor is created
>>   ActorRef backend = 
>> getContext().actorOf(FromConfig.getInstance().props(),
>>   "factorialBackendRouter");
>>
>
> No, in the above code the actual actor is created and you get back its 
> reference. It is different from looking up the ActorRef of an existing 
> actor. You should probably take a look at the following pages from the 
> documentation: 
>
>   Addressing in general: 
> http://doc.akka.io/docs/akka/2.3.4/general/addressing.html especially 
> the section 
> http://doc.akka.io/docs/akka/2.3.4/general/addressing.html#How_are_Actor_References_obtained_
>   Lifecycle of an Actor and its relation to ActorRefs and ActorPaths: 
> http://doc.akka.io/docs/akka/2.3.4/java/untyped-actors.html#Actor_Lifecycle
>   Looking up actor references via path: 
> http://doc.akka.io/docs/akka/2.3.4/java/untyped-actors.html#Identifying_Actors_via_Actor_Selection
>
>
> -Endre 
>  
>
>>
>>   public FactorialFrontend(int upToN, boolean repeat) {
>> this.upToN = upToN;
>> this.repeat = repeat;
>>   }
>>
>>   @Override
>>   public void preStart() {
>> sendJobs();
>> getContext().setReceiveTimeout(Duration.create(10, TimeUnit.SECONDS));
>>   }
>>
>>   @Override
>>   public void onReceive(Object message) {
>> if (message instanceof FactorialResult) {
>>   FactorialResult result = (FactorialResult) message;
>>   if (result.n == upToN) {
>> log.debug("{}! = {}", result.n, result.factorial);
>> if (repeat)
>>   sendJobs();
>> else
>>   getContext().stop(getSelf());
>>   }
>>
>> } else if (message instanceof ReceiveTimeout) {
>>   log.info("Timeout");
>>   sendJobs();
>>
>> } else {
>>   unhandled(message);
>> }
>>   }
>>
>>   void sendJobs() {
>> log.info("Starting batch of factorials up to [{}]", upToN);
>> for (int n = 1; n <= upToN; n++) {
>>
>> // here a message is sent to akka via tell in fire and forget fashion
>>
>>   backend.tell(n, getSelf());
>> }
>>   }
>>
>>
>>
>> Endre
>>
>>
>> On Thursday, July 24, 2014 4:43:21 AM UTC-4, Akka Team wrote:
>>>
>>> Hi John,
>>>
>>>
>>>
>>> My question is this.

 - In a front end actor is the sending of a message as simple as 
 attaining a reference (in frontend actor onreceive) to the backend actor 
 via an ActorRef and then sending a message to the backend actor?

>>>
>>> Yes, once you have the ActorRef of an actor you can send a message to it:
>>>
>>>   ref ! msg
>>>
>>> ... and it looks like the same whether "ref" is remote or not (although 
>>> you need to enable remoting to be able to communicate with remote actors, 
>>> but that does not change the way you send messages).
>>>
>>> -Endre
>>>  
>>>

 Thanks,

 John

 On Tuesday, July 22, 2014 4:16:09 AM UTC-4, Akka Team wrote:

> Hi John,
>
> I was looking to know how to write an actor per request. I want to 
>> understand this pattern so I could create a sample similar to the one at 
>> https://github.com/muuki88/activator-play-cluster-sample that 
>> creates a frontend for an akka cluster in Java. 
>>
>> I'm struggling with how to have a frontend actor send a send a 
>> message to an akka cluster. At this point hearing how this would be 
>> implemented would be great so I could write this in simple form even 
>> using 
>> a basic Java console application just to understand the basics of to 
>> have a 
>> frontend send a message to an akka cluster.
>>
>
> We need a bit more information about what you want to achieve. Sending 
> a message from an actor to another actor (irregardless whether it is in a 
> cluster or not) is just like an ordinary message send. Is your problem 
> how 
> to aquir

Re: [akka-user] akka scheduler with long delays

[Greg Flanagan]

you're right, my dislike for quartz should cloud my judgement. sorry for 
the double post :)

On Monday, July 28, 2014 3:59:02 AM UTC-7, Konrad Malawski wrote:
>
> Hello Greg,
> This question is basically the same as last week: 
> https://groups.google.com/forum/#!topicsearchin/akka-user/combining$20Akka$20Persistence$20with$20Akka$20Scheduling/akka-user/CLRF6LP2G18
>
> Suggestions have not changed since then :-)
> Try akka-quartz-scheduler or write a large scheduling system on your own.
> Not liking quartz shouldn’t really be the reason of avoiding a library 
> that solves the problem you need to be solved… :-)
>
> —  k
>
> On 28 July 2014 at 04:05:55, Greg Flanagan (vent...@gmail.com 
> ) wrote:
>  I'm building a reporting backend where users can schedule a report to be 
> run weeks / months in advanced. I've used Quartz in the past for this kind 
> of things but my use case isn't that complex and I think I can get away 
> with just using the akka scheduler (plus I just don't like Quartz and would 
> like to avoid the dependency if I can). My only requirement is that the 
> user gives me a date time instant that they want the report to run, so I 
> can easily figure out the delay to give the akka scheduler in seconds. Also 
> I don't need need any guarantees about the report running at exactly the 
> correct instant, it could be off by even an hour and I would be fine. My 
> concerns are if the akka scheduler can even handle scheduling something 
> this far in advanced, I imagine that it has a hard limit on whatever the 
> max integer is. Also, I'm not sure what the best approach would be to 
> handle jvm restarts or crashes. In this case I would need to have some sort 
> of persistence so that the scheduler could be restarted. Is this something 
> that akka persistence could help me with or have to roll something myself?
>
> Cheers,
> Greg
> --
> >> 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 http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>  -- 
> Konrad 'ktoso' Malawski
> hAkker @ typesafe
> http://akka.io
>

-- 
>>  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: Passivate

[ahjohannessen]

Ashley, perhaps this might be useful for you.

import scala.concurrent.duration._
import akka.actor._
import benefits.configuration.Settings

/* Message used by `Child` to signal `Parent` it should
 * be passivated by way of PoisonPill after a configurable
 * idle time.
 * */
case object Passivate

trait Parent extends Actor with Stash with ActorLogging {
  import Parent._
  import context._

  private val settings =
Settings(system).Support.Passivation

  def withPassivation(receive: Receive): Receive =
receive orElse passivation

  private[support] def passivation: Receive = {
case Passivate   ⇒ passivate(sender())
case Terminated(ref) ⇒ logUnexpected(ref)
case WaitTick(ref)   ⇒ // no-op
  }

  private def passivate(entry: ActorRef) = {
log.debug(s"Passivation start: $entry")
watch(entry)
entry ! PoisonPill
val tick = scheduleTick(entry)
val await = awaiting(entry, tick)
become(await, discardOld = false)
  }

  private def awaiting(ref: ActorRef, tick: Cancellable): Receive = {
case Terminated(`ref`) ⇒ terminated(ref, tick)
case WaitTick(`ref`)   ⇒ waitTick(ref)
case _ ⇒ stash()
  }

  private def terminated(ref: ActorRef, tick: Cancellable) = {
tick.cancel()
previousBehavior(ref)
log.debug(s"Passivation end: $ref")
  }

  private def waitTick(ref: ActorRef) = {
previousBehavior(ref)
log.warning(s"Giving up waiting for Terminated($ref)")
  }

  private def previousBehavior(ref: ActorRef) = {
unwatch(ref)
unbecome()
unstashAll()
  }

  private def logUnexpected(ref: ActorRef) =
log.warning(s"Unexpected terminated for $ref")

  private def scheduleTick(entry: ActorRef) = {
system.scheduler.scheduleOnce(
  waitTime, self, WaitTick(entry)
)
  }

  def waitTime: FiniteDuration =
settings.parentWaitTime
}

object Parent {
  private[support] case class WaitTick(
entry: ActorRef
  )
}

trait Child extends Actor with ActorLogging {
  import Child._
  import context._

  private val settings =
Settings(system).Support.Passivation

  override def preStart() = {
super.preStart()
self ! StartTimingOut
  }

  def passivator: ActorRef = parent

  def withPassivation(receive: Receive): Receive =
receive orElse passivation

  private[support] def passivation: Receive = {
case ReceiveTimeout ⇒ issuePassivate()
case StartTimingOut ⇒ startTimeout()
  }

  private def startTimeout() = {
log.debug(s"Setting receive timeout to $idleTime")
setReceiveTimeout(idleTime)
  }

  private def issuePassivate() = {
log.debug(s"Sending Passivate to $passivator")
setReceiveTimeout(Duration.Inf)
passivator ! Passivate
  }

  def idleTime: FiniteDuration =
settings.childIdleTime
}

object Child {
  private[support] case object StartTimingOut
}


On Wednesday, July 16, 2014 4:00:44 AM UTC+1, Ashley Aitken wrote:
>
>
> Thank you Michael and Konrad for your posts.
>
> I was somewhat confused as to whether the manager was something special or 
> it referred to a processors' usual supervisor / parent.
>
> I also thought passivate was a part of akka-persistence but Konrad's post 
> makes it clear it is a part of cluster sharding (no wonder I couldn't find 
> anything about it in the docs for akka-persistence) and the Manager in 
> Patrik's post is a part of the cluster sharding infrastructure.
>
> Cheers,
> Ashley.
>
>
>
>
>
>

-- 
>>  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Improving Akka Persistence wrt CQRS/ES/DDD

[ahjohannessen]

Greg, exactly. I think Akka Persistence having such capabilities would make 
it even more awesome and useful. 
Thanks for chiming in, your opinion on this is very much appreciated.

Ashley, thanks for the kind words. Glad to learn that my worries are not 
completely mental and just my own nitpicking :)

On Saturday, July 26, 2014 5:03:13 PM UTC+1, Greg Young wrote:
>
> I think whats being missed here is that Event Store doesn't only support 
> this on a single stream/topic.
>
> Its very useful when building read models as example to be able to read 
> events from many streams (or all streams) joined in a way that gives global 
> ordering (if on a single replication group) or deterministic ordering 
> (historical) if on multiple replication groups.
>
> As example you can imagine when writing you have 500,000 streams (one per 
> inventory item). 
> When building a projection you are interested in 5 event types:
>
> InventoryItemCreated
> InventoryItemAuditted
> InventoryItemRenamed
> InventoryCheckedIn
> InvnetoryCheckedOut
>
> Regardless of the initial stream they were written to. This is very common 
> in these types of systems.
>
> Cheers,
>
> Greg
>
> On Friday, July 25, 2014 7:20:02 PM UTC+3, Konrad Malawski wrote:
>>
>> Hello there,
>> Ah, much better when able to communicate in full sentences without 140 
>> chars limit! ;-)
>> ( https://twitter.com/mrt1nz/status/492676432410447872 ) 
>>
>> So, now that it’s spelled out as full sentences, I’ll gladly dig into 
>> your points:
>>
>> 1) 
>> Has been already* proposed and accepted* in 
>> https://github.com/akka/akka/issues/15004,
>> including your +1, so I guess you’re aware that it’s in our backlog.
>>
>> The module is experimental and published “early” exactly in order to 
>> gather,
>> and implement these features before stabilising the APIs.
>>
>> So it’s coming, we simply have not yet gotten to implementing it - it’s 
>> holiday season, which isn’t helping development speed :-)
>>
>> 2) 
>> For the benefit of the discussion, example in EventStore: 
>> http://geteventstore.com/blog/20130707/catch-up-subscriptions-with-the-event-store/
>>
>> One thing to keep in mind here is that some Journals would have no 
>> problem implementing this, such as Kafka or EventStore - because it’s a 
>> built in mechanism to “subscribe to something” in them… See Martin’s Kafka 
>> journal and how one can subscribe to a event stream there: 
>> https://github.com/krasserm/akka-persistence-kafka#journal-topics On the 
>> other hand implementing this in other Journals would be pretty painful / 
>> inefficient (cassandra, hbase, …).
>>
>> We were playing around with some ideas to expose optional db specific 
>> journal functionalities. This would be a good candidate for this.
>>
>> This request seems to depend on these things by the way: 
>> * changes in the journal plugins (we some changes there anyway 
>> https://github.com/krasserm/akka-persistence-kafka#journal-topics ),
>> * views over “tags" (as this would essentially be a view over “all”),
>> * and lastly reactive-streams (views exposed as streams of events).
>>
>>
>> Thanks for your feedback and keep in mind that no-one said that this 
>> module is “done”.
>> It’s still experimental and this kind of feature requests are exacly what 
>> we need and will have to provide to make it stable and usable in all kinds 
>> of apps.
>>
>> Lastly, would you mind creating a ticket for the 2) feature?
>> Thanks in advance, have a nice weekend :-)
>>
>> 
>>
>> -- 
>> Konrad 'ktoso' Malawski
>> hAkker @ typesafe
>> http://akka.io
>>
>

-- 
>>  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Improving Akka Persistence wrt CQRS/ES/DDD

[ahjohannessen]

>
>
> Lastly, would you mind creating a ticket for the 2) feature?
> Thanks in advance, have a nice weekend :-)
>

Sure Konrad, however I think I'll wait a little bit because getting input 
from the likes of Greg and Martin helps formulate the issue more clearly. 
It would be awesome to get the opinion from people like Vaughn, Roland, 
Patrik, Viktor and so on, as well, please share your thoughts guys :).
I believe this "missing link" is very important for Akka Persistence being 
*generally* useful for CQRS/DDD/ES.

Martin, your suggestion makes very much sense in my book, clever and 
creative as usual.

-- 
>>  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka LoggingReceive and stackable traits - strange behaviour

[Andrzej Dębski]

Thanks!

I was browsing through the code of the but my mind somehow did not register 
that if I will not use isDefinedAt there will not be any logging.

W dniu poniedziałek, 28 lipca 2014 13:21:50 UTC+2 użytkownik Martynas 
Mickevičius napisał:
>
> Hi Andrzej,
>
> the answer is in the code. :) Code says 
> 
>  
> that LogginReceive logs message not in the apply but in the isDefinedAt 
> function. Therefore you need to chain partial functions correctly using 
> orElse. So In your case you need to change the StackableActorTracing to 
> handle that.
>
> trait StackableActorTracing extends ActorStack {
>
>   var currentMessage: Traced[Any] = Traced("tracing turned off")
>
>   val receivePf: PartialFunction[Any, Unit] = {
> case msg @ Traced(inner) => {
>
>   currentMessage = msg
>   super.receive(inner)
> }
>   }
>
>   override def receive = receivePf.orElse(super.receive)
>
> }
>
>
>
> On Thu, Jul 24, 2014 at 4:58 PM, Andrzej Dębski  > wrote:
>
>> Hello
>>
>> "Inspired" by the presentation 
>> http://www.slideshare.net/EvanChan2/akka-inproductionpnw-scala2013 I 
>> wanted to introduce stackable traits pattern to my Akka application. For 
>> now I wanted to add logging of messages using LoggingReceive and basic 
>> tracing with akka-tracing.
>>
>> Following the presentation I created:
>>
>> trait ActorStack extends Actor {
>>   def wrappedReceive: Receive
>>
>>   def receive: Receive = {
>> case x => if (wrappedReceive.isDefinedAt(x)) wrappedReceive(x) else 
>> unhandled(x)
>>   }
>> }
>>
>> and two traits:
>>
>> trait LoggingReceiveActor extends ActorStack {
>>   override def receive: Receive = LoggingReceive {
>> case x => {
>>   println("+++" + x) // added for debugging 
>>   super.receive(x)
>> }
>>   }
>> }
>>
>> trait StackableActorTracing extends ActorStack with ActorTracing {
>>   var currentMessage: Traced[Any] = Traced("tracing turned off")
>>
>>   override def receive: Receive = {
>> case msg @ Traced(inner) => {
>>   trace.sample(msg, this.getClass.getSimpleName)
>>   currentMessage = msg
>>   super.receive(inner)
>> }
>>
>> case msg => {
>>   currentMessage = Traced("tracing turned off")
>>   super.receive(msg)
>> }
>>   }
>>
>>   def msg = {
>> currentMessage
>>   }
>> }
>>
>> also I created one utility trait that gathers those two traits:
>>
>> trait BaseActor extends ActorStack with ActorLogging
>>   with LoggingReceiveActor with StackableActorTracing
>>
>> Now when I take my example actor:
>>
>> class RotationService(rotationRepository: ActorRef) extends BaseActor 
>> with DefaultAskTimeout {
>>   implicit val dispatcher = context.dispatcher
>>
>>   def wrappedReceive: Receive = {
>> case createCommand @ CreateRotation() => {
>> ...
>> }
>>
>> When I execute unit test that sends *CreateRotation *message to 
>> *RotationService 
>> *actor I am getting:
>>
>> Testing started at 3:41 PM ...
>> Connected to the target VM, address: '127.0.0.1:51978', transport: 
>> 'socket'
>> 15:41:36.520 
>> [TestActorSystem-9dc08bc090f2416bbf369947fd64908b-akka.actor.default-dispatcher-2]
>>  
>> INFO  akka.event.slf4j.Slf4jLogger - Slf4jLogger started
>> 15:41:36.565 
>> [TestActorSystem-9dc08bc090f2416bbf369947fd64908b-akka.actor.default-dispatcher-2]
>>  
>> DEBUG akka.event.EventStream - logger log1-Slf4jLogger started
>> 15:41:36.584 
>> [TestActorSystem-9dc08bc090f2416bbf369947fd64908b-akka.actor.default-dispatcher-2]
>>  
>> DEBUG akka.event.EventStream - Default Loggers started
>> 15:41:36.586 
>> [TestActorSystem-9dc08bc090f2416bbf369947fd64908b-akka.actor.default-dispatcher-2]
>>  
>> DEBUG a.a.LocalActorRefProvider$SystemGuardian - now supervising 
>> Actor[akka://TestActorSystem-9dc08bc090f2416bbf369947fd64908b/system/deadLetterListener#-162762200]
>> 15:41:36.588 
>> [TestActorSystem-9dc08bc090f2416bbf369947fd64908b-akka.actor.default-dispatcher-2]
>>  
>> DEBUG akka.event.DeadLetterListener - started 
>> (akka.event.DeadLetterListener@2025eae4)
>> 15:41:36.627 
>> [TestActorSystem-9dc08bc090f2416bbf369947fd64908b-akka.actor.default-dispatcher-5]
>>  
>> INFO  kamon.statsd.StatsDExtension - Starting the Kamon(StatsD) extension
>> 15:41:36.652 
>> [TestActorSystem-9dc08bc090f2416bbf369947fd64908b-akka.actor.default-dispatcher-5]
>>  
>> DEBUG a.a.LocalActorRefProvider$Guardian - now supervising 
>> Actor[akka://TestActorSystem-9dc08bc090f2416bbf369947fd64908b/user/statsd-metrics-sender#-609019730]
>> 15:41:36.688 
>> [TestActorSystem-9dc08bc090f2416bbf369947fd64908b-akka.actor.default-dispatcher-4]
>>  
>> DEBUG a.a.LocalActorRefProvider$SystemGuardian - now supervising 
>> Actor[akka://TestActorSystem-9dc08bc090f2416bbf369947fd64908b/system/IO-UDP-FF#221802495]
>> 15:41:36.707 
>> [TestActorSystem-9dc08bc090f2416bbf369947fd64908b-akka.actor.default-dispatcher-3]
>>  
>> DEB

Re: [akka-user] Akka LoggingReceive and stackable traits - strange behaviour

[Martynas Mickevičius]

Hi Andrzej,

the answer is in the code. :) Code says

that LogginReceive logs message not in the apply but in the isDefinedAt
function. Therefore you need to chain partial functions correctly using
orElse. So In your case you need to change the StackableActorTracing to
handle that.

trait StackableActorTracing extends ActorStack {
  var currentMessage: Traced[Any] = Traced("tracing turned off")

  val receivePf: PartialFunction[Any, Unit] = {
case msg @ Traced(inner) => {
  currentMessage = msg
  super.receive(inner)
}
  }

  override def receive = receivePf.orElse(super.receive)
}



On Thu, Jul 24, 2014 at 4:58 PM, Andrzej Dębski 
wrote:

> Hello
>
> "Inspired" by the presentation
> http://www.slideshare.net/EvanChan2/akka-inproductionpnw-scala2013 I
> wanted to introduce stackable traits pattern to my Akka application. For
> now I wanted to add logging of messages using LoggingReceive and basic
> tracing with akka-tracing.
>
> Following the presentation I created:
>
> trait ActorStack extends Actor {
>   def wrappedReceive: Receive
>
>   def receive: Receive = {
> case x => if (wrappedReceive.isDefinedAt(x)) wrappedReceive(x) else
> unhandled(x)
>   }
> }
>
> and two traits:
>
> trait LoggingReceiveActor extends ActorStack {
>   override def receive: Receive = LoggingReceive {
> case x => {
>   println("+++" + x) // added for debugging
>   super.receive(x)
> }
>   }
> }
>
> trait StackableActorTracing extends ActorStack with ActorTracing {
>   var currentMessage: Traced[Any] = Traced("tracing turned off")
>
>   override def receive: Receive = {
> case msg @ Traced(inner) => {
>   trace.sample(msg, this.getClass.getSimpleName)
>   currentMessage = msg
>   super.receive(inner)
> }
>
> case msg => {
>   currentMessage = Traced("tracing turned off")
>   super.receive(msg)
> }
>   }
>
>   def msg = {
> currentMessage
>   }
> }
>
> also I created one utility trait that gathers those two traits:
>
> trait BaseActor extends ActorStack with ActorLogging
>   with LoggingReceiveActor with StackableActorTracing
>
> Now when I take my example actor:
>
> class RotationService(rotationRepository: ActorRef) extends BaseActor with
> DefaultAskTimeout {
>   implicit val dispatcher = context.dispatcher
>
>   def wrappedReceive: Receive = {
> case createCommand @ CreateRotation() => {
> ...
> }
>
> When I execute unit test that sends *CreateRotation *message to 
> *RotationService
> *actor I am getting:
>
> Testing started at 3:41 PM ...
> Connected to the target VM, address: '127.0.0.1:51978', transport:
> 'socket'
> 15:41:36.520
> [TestActorSystem-9dc08bc090f2416bbf369947fd64908b-akka.actor.default-dispatcher-2]
> INFO  akka.event.slf4j.Slf4jLogger - Slf4jLogger started
> 15:41:36.565
> [TestActorSystem-9dc08bc090f2416bbf369947fd64908b-akka.actor.default-dispatcher-2]
> DEBUG akka.event.EventStream - logger log1-Slf4jLogger started
> 15:41:36.584
> [TestActorSystem-9dc08bc090f2416bbf369947fd64908b-akka.actor.default-dispatcher-2]
> DEBUG akka.event.EventStream - Default Loggers started
> 15:41:36.586
> [TestActorSystem-9dc08bc090f2416bbf369947fd64908b-akka.actor.default-dispatcher-2]
> DEBUG a.a.LocalActorRefProvider$SystemGuardian - now supervising
> Actor[akka://TestActorSystem-9dc08bc090f2416bbf369947fd64908b/system/deadLetterListener#-162762200]
> 15:41:36.588
> [TestActorSystem-9dc08bc090f2416bbf369947fd64908b-akka.actor.default-dispatcher-2]
> DEBUG akka.event.DeadLetterListener - started
> (akka.event.DeadLetterListener@2025eae4)
> 15:41:36.627
> [TestActorSystem-9dc08bc090f2416bbf369947fd64908b-akka.actor.default-dispatcher-5]
> INFO  kamon.statsd.StatsDExtension - Starting the Kamon(StatsD) extension
> 15:41:36.652
> [TestActorSystem-9dc08bc090f2416bbf369947fd64908b-akka.actor.default-dispatcher-5]
> DEBUG a.a.LocalActorRefProvider$Guardian - now supervising
> Actor[akka://TestActorSystem-9dc08bc090f2416bbf369947fd64908b/user/statsd-metrics-sender#-609019730]
> 15:41:36.688
> [TestActorSystem-9dc08bc090f2416bbf369947fd64908b-akka.actor.default-dispatcher-4]
> DEBUG a.a.LocalActorRefProvider$SystemGuardian - now supervising
> Actor[akka://TestActorSystem-9dc08bc090f2416bbf369947fd64908b/system/IO-UDP-FF#221802495]
> 15:41:36.707
> [TestActorSystem-9dc08bc090f2416bbf369947fd64908b-akka.actor.default-dispatcher-3]
> DEBUG kamon.statsd.StatsDMetricsSender - started
> (kamon.statsd.StatsDMetricsSender@1f06d526)
> 15:41:36.747
> [TestActorSystem-9dc08bc090f2416bbf369947fd64908b-akka.actor.default-dispatcher-4]
> DEBUG a.a.LocalActorRefProvider$Guardian - now supervising
> Actor[akka://TestActorSystem-9dc08bc090f2416bbf369947fd64908b/user/kamon-metrics-subscriptions#-992962374]
> 15:41:36.770
> [TestActorSystem-9dc08bc090f2416bbf369947fd64908b-akka.actor.default-dispatcher-4]
> DEBUG kamon.met

Re: [akka-user] akka scheduler with long delays

[Konrad 'ktoso' Malawski]

Hello Greg,
This question is basically the same as last week: 
https://groups.google.com/forum/#!topicsearchin/akka-user/combining$20Akka$20Persistence$20with$20Akka$20Scheduling/akka-user/CLRF6LP2G18

Suggestions have not changed since then :-)
Try akka-quartz-scheduler or write a large scheduling system on your own.
Not liking quartz shouldn’t really be the reason of avoiding a library that 
solves the problem you need to be solved… :-)

—  k
On 28 July 2014 at 04:05:55, Greg Flanagan (ventis...@gmail.com) wrote:

I'm building a reporting backend where users can schedule a report to be run 
weeks / months in advanced. I've used Quartz in the past for this kind of 
things but my use case isn't that complex and I think I can get away with just 
using the akka scheduler (plus I just don't like Quartz and would like to avoid 
the dependency if I can). My only requirement is that the user gives me a date 
time instant that they want the report to run, so I can easily figure out the 
delay to give the akka scheduler in seconds. Also I don't need need any 
guarantees about the report running at exactly the correct instant, it could be 
off by even an hour and I would be fine. My concerns are if the akka scheduler 
can even handle scheduling something this far in advanced, I imagine that it 
has a hard limit on whatever the max integer is. Also, I'm not sure what the 
best approach would be to handle jvm restarts or crashes. In this case I would 
need to have some sort of persistence so that the scheduler could be restarted. 
Is this something that akka persistence could help me with or have to roll 
something myself?

Cheers,
Greg
--
>> 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

-- 
>>  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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.