I made TenantProcessorModule and TenantProcessor Serializable because they're getting pulled into the serialization. (I don't intend to stick w Java serialization -- was planning to explore Thrift or protobuf as next step.)
I understand I'll likely need to be explicit regarding my AuditContext and define these message classes in a top-level object. It's probably a better path to follow to handle message enveloping through another means rather than via my module / cake pattern. (I already have this implemented adapting something like http://derekwyatt.org/2014/01/01/using-scala-implicits-to-implement-a-messaging-protocol.html but if there's an alternative library people recommend I'd love to try that out as well.) Before my post got through curation, I resolved my immediate issue. I am trying to consolidate configuration of "deployment" concerns within an interface. Part of that interface defines Snapshot scheduling. If I define a specific instance as val in my concrete actor, I get the error, however if I define it as a def it's okay. I am scheduling against self. Thanks! On Tuesday, June 10, 2014 2:06:01 PM UTC-7, Patrik Nordwall wrote: > > Hi Damon, > > How do you schedule things? When scheduling in an actor it is highly > recommended that you schedule a message to the actor (self). > There might be more problems than the scheduled task. For example, why did > you add Serializable to the TenantProcessorModule and TenantProcessor? You > should define the message classes in a top level object instead of inside > the trait, since that will close over the outer instance and try to > serialize that with the messages. > > I would also recommend against using java serialization for persistent > messagse. Use protobuf, or similar, that is possible to evolve. > > Regards, > Patrik > > > On Tue, Jun 10, 2014 at 2:33 AM, Damon Rolfs <[email protected] > <javascript:>> wrote: > >> While persisting my state update, I am getting a PersistenceFailure error >> that suggests to me that path-dependent types may be problematic for Akka >> Persistence. The error message I get is: >> >> [ERROR] [06/09/2014 16:56:23.668] [Tests-akka.actor.default-dispatcher-5] >>> [akka://Tests/user/Tenants/jb0oz-ke6UmozLqg8DER4w] >>> PersistenceFailure(TenantAdded(Tenant(id-jb0oz-ke6UmozLqg8DER4w:TestOrg)),1,*java.io.NotSerializableException: >>> >>> akka.actor.LightArrayRevolverScheduler$TaskHolder*) (of class >>> akka.persistence.PersistenceFailure) >> >> >> Somehow the akka-internal >> akka.actor.LightArrayRevolverScheduler#TaskHolder is getting pulled into >> serialization of my event (TenantAdded). I have not been able to determine >> why this internal akka class is being serialized in conjunction with my >> event. Any insight and suggestions to investigate or correct is greatly >> appreciated! >> >> In order to support some generalization, I've defined the Processor and >> associated classes within a module trait. (I suspect the resulting >> path-dependent type may be causing some wonkiness, however I haven't been >> able to find any concrete connection to validate this hypothesis.) >> >> The structure of the classes is as follows (Hopefully I'm not filtering >> out something relevant, but trying to avoid dumping a whole class. :-)): >> >> trait TenantProcessorModule extends Serializable { outer: AuditedModule => >>> >>> abstract override def start( ctx: Option[AnyRef] = None ): Unit = >>> trace.block("start") { >>> super.start( ctx ) >>> model registerAggregateType { Props( new TenantProcessor with >>> LocalPublisher ) } >>> } >>> object TenantProcessor extends Serializable { >>> sealed trait Command { >>> def auditContext: AuditContext >>> } >>> case class AddTenant( tenant: Tenant )( implicit override val >>> auditContext: AuditContext ) extends Command >>> //... >>> sealed trait Event extends Serializable >>> case class TenantAdded( tenant: Tenant ) extends Event >>> //... >>> } >>> >>> class TenantProcessor extends EventsourcedProcessor { outer: >>> EventPublisher => >>> //... >>> } >>> } >> >> >> >> There's obviously some complexity I could take out in order to align with >> other examples, but there's an amount of desired generalization and >> encapsulation I was hoping to support via the Module design. >> >> Thanks, Damon >> >> -- >> >>>>>>>>>> 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 [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at http://groups.google.com/group/akka-user. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > > Patrik Nordwall > Typesafe <http://typesafe.com/> - Reactive apps on the JVM > Twitter: @patriknw > > <http://www.scaladays.org/> > > -- >>>>>>>>>> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
