[akka-user] Serialization: Prioritize custom over built in?

[Russell Cohen]

I recently ran into a pretty surprising behavior in akka serialization -- 
if your parent class does *not* inherit from java.io.Serializable, akka 
will choose arbitrarily between the two! This "feature" is documented 
 but it's 
pretty odd, and definitely not what I would expect as a user.

A much more reasonable behavior seems like it would be always picking a 
user defined serializer if appropriate and falling back on Serializable 
only if no user defined serializers match. It's very counterintuitive that 
to _disable_ the java serializers, you must inherit from them. The random 
choice behavior seems like the right thing to do if two user defined 
serializers both apply.

Thoughts?

Russell

-- 
>>  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] using actors with db queries

[Avi Levi]

Thank you very much for your replay .
actually  I am using a sort of scatter gather pattern to fetch data . each
actor should fetch part of data according to param (e.d customer ID) . and
an actor that aggregates the results applying some business logic and
stores the result in the db .

so what is the best practice to achieve that  ? should I send the
repository to each actor constructor  ? or using cake pattern or other
abstraction
  ?

Best
AL




On Fri, Apr 17, 2015 at 4:14 PM Martynas Mickevičius <
martynas.mickevic...@typesafe.com> wrote:

> Hi,
>
> On Sun, Apr 5, 2015 at 5:10 PM, AL <123...@gmail.com> wrote:
>
>> Hi
>> Just want to consult if this make sense .
>> I have an actor that uses as a service to fetch data from the db .
>> for accessing the DB we have a Java Spring project with hibernate and Jpa
>> Repository
>> what is the best participate for testings :
>> the actor should receive as a parameter the repository something like
>> this :
>> class FooService(invoicesRepo:InvoicesRepository,...more repositories
>> goes here ... ) extends Actor 
>> and while testing to send mock[InvoicesRepository]
>>
>> two questions :
>> is that make sense to use an actor to fetch/update data from the db
>> (tried to find examples at typesafe activator templates but couldn't really
>> find actors )?
>>
>
> Do you have a particular reason you started to think about encapsulating
> DB access to an actor? Actors are about distribution and about
> encapsulating state that can be safely accessed concurrently. There are
> situations where one could choose to put all the code that accesses the DB
> to an actor so access to DB is only from a one thread at a time, but that
> is a very specific requirement.
>
>
>> if the answer is yes - is it a good practice to send the repository to
>> actor ? or is it better use dependency injection
>>
>
> When sending dependencies in a message you need to make sure that your
> actor does not start handling business messages until dependencies are sent
> in. Also you will have to take care of actor restarts. Therefore passing in
> dependencies as constructor arguments require less management.
>
>
>>
>> any examples will be appreciated
>>
>> Thanks
>>
>>
>>
>>  --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>>
> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+unsubscr...@googlegroups.com.
>
>
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Martynas Mickevičius
> Typesafe  – Reactive
>  Apps on the JVM
>
> --
> >> 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/e75kStFFdVQ/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 http://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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: Akka Persistence Batch Write

[Patrik Nordwall]

Somewhere it is documented as: "All events that are persisted in context of
a single command are written as a single batch to the journal (even if
persist is called multiple times per command). The recovery of a
PersistentActor will therefore never be done partially (with only a subset
of events persisted by a single command)."

However, I'm not sure that all journals implement it like that. It is not
verified by the TCK. We have also discussed this in issue
https://github.com/akka/akka/issues/15377, and we might want to improve
things in this area.

/Patrik

On Tue, Apr 14, 2015 at 9:09 PM, Aditya Devisetty  wrote:

> any one please give some help
>
>
> On Tuesday, April 14, 2015 at 11:20:33 AM UTC+5:30, Aditya Devisetty wrote:
>>
>> Hi,
>>
>>In Akka Persistence(here
>> ),
>> It's specified that, the batches are used to ensure atomic writes of even.
>> Can any one please give an example on, how
>>
>> to write batch writes in persistence with atomicity?.
>>
>  --
> >> 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.
>



-- 

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

Re: [akka-user] Re: Akka Persistence on the Query Side: The Conclusion

[Patrik Nordwall]

On Thu, Apr 16, 2015 at 10:32 AM, Magnus Andersson <
magnus.anders...@mollyware.se> wrote:

> Hi
>
> Sorry for being late to the party. I hope you don't mind a question around
> the PersistentView part:
>
> The way I read it the default interaction would be the following:
>
>>
>
>> case class QueryByPersistenceId(id: String, fromSeqNr: Long, toSeqNr:
>> Long)
>> case class EventStreamOffer(metadata: Metadata, stream:
>> Flow[PersistentMsg])
>>
>
> This query would be handled by the Journal. Today we don't interact
> directly with the underlying Journal, instead it is done through
> PersistentActors and PersistentViews.
>
> Since PersistentView seems to be going away ("...any Actor can obtain the
> ActorRef for a given Journal..."), does that mean that the PersistentActor
> will be the one to provide an actor ref for the journal or will the journal
> be available separately in read mode?
>

We have not designed this in detail, so there is no answer to your question
at the moment.
/Patrik


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



-- 

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

Re: [akka-user] using actors with db queries

[Martynas Mickevičius]

Hi,

On Sun, Apr 5, 2015 at 5:10 PM, AL <123...@gmail.com> wrote:

> Hi
> Just want to consult if this make sense .
> I have an actor that uses as a service to fetch data from the db .
> for accessing the DB we have a Java Spring project with hibernate and Jpa
> Repository
> what is the best participate for testings :
> the actor should receive as a parameter the repository something like this
> :
> class FooService(invoicesRepo:InvoicesRepository,...more repositories goes
> here ... ) extends Actor 
> and while testing to send mock[InvoicesRepository]
>
> two questions :
> is that make sense to use an actor to fetch/update data from the db (tried
> to find examples at typesafe activator templates but couldn't really find
> actors )?
>

Do you have a particular reason you started to think about encapsulating DB
access to an actor? Actors are about distribution and about encapsulating
state that can be safely accessed concurrently. There are situations where
one could choose to put all the code that accesses the DB to an actor so
access to DB is only from a one thread at a time, but that is a very
specific requirement.


> if the answer is yes - is it a good practice to send the repository to
> actor ? or is it better use dependency injection
>

When sending dependencies in a message you need to make sure that your
actor does not start handling business messages until dependencies are sent
in. Also you will have to take care of actor restarts. Therefore passing in
dependencies as constructor arguments require less management.


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



-- 
Martynas Mickevičius
Typesafe  – Reactive
 Apps on the JVM

-- 
>>  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] ActorSystem terminates when restarted remote ActorSystem has associated after being quarantined

[Endre Varga]

Hi Rick

On Fri, Apr 17, 2015 at 1:01 PM, Rick Latrine 
wrote:

> Yes, it  sounds like the same issue.
>
> The important point is the log message:
> 04:12:24.833 DEBUG Associated [akka.tcp://OurProgrammhostname.com:3552
> ] <- [akka.tcp://GatlingSystem@
> gatlinghostname:9044]
>
> The re-connect is going to be associated, but as the internal state of the
> EndpointManager becomes incosistent, an AssertionError will be thrown.
>
> As a workaround I wrote an Auto-Restarter which restarts an ActorSystem in
> case of unexpected shutdown.
> But the Netty-NIO stuff was not shutdown orderly. The TCP-Port was still
> bound and restarts fail.
>
> Finally I investigated a little bit more and found a few things I wouldn't
> do (maybe I have not enough insight):
>

Well, remoting deserves the critique. I wrote most of it and I am happy to
criticize it myself. We will redesign this subsystem soon.


>
> - the death of an EndpointManager should not kill the entire ActorSystem
> (why not restart this subsystem?)
>

This is one of the core subsystems and it is is involved in the startup and
shutdown of the whole system. It is not easy to restart this part also
because most of its state must be preserved. I agree, in the future we
should compartmentalize it more though, but that needs redesign.


> - as theEndpointManager is doing a lot of things, I would move the
> EndpointManager beyond an EndpointSupervisor who ensures aliveness
>
- Resources (like TCP-Channels) should be closed (at least) automatically
> in postStop
>

Yeah, it is handled in the ordinary shutdown, but not in postStop, because
the ordinary shutdown is a two-phase async process. We should really add
extra cleanup to postStop that does not attempt flushing just terminates
everything. Good point.


> - the map to find quarantined UID's should be a 1 [Address] to N list and
> not 1:1 (have a look in akka.remote.EndpointManager.EndpointRegistry)
>

The idea was that on the same address (IP:port) there can be exactly one
UID active and therefore you need to track exactly one quarantined UID. I
still think this is valid assumption, but let's see what debugging will
show.

All in all, this part needs a better design. The original design evolved
too much and finally it deviated from initial assumptions and became too
tangled. Now we know this problem space well enough, and we already have
streams that simplifies many of the issues we faced -- I hope we can start
improving remoting quite soon.

Thank you very much for finding out the root cause, it saves us quite a bit
of time.

-Endre


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

-- 
>>  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] ActorSystem terminates when restarted remote ActorSystem has associated after being quarantined

[Rick Latrine]

Yes, it  sounds like the same issue.

The important point is the log message:
04:12:24.833 DEBUG Associated [akka.tcp://OurProgrammhostname.com:3552 
] <- [akka.tcp://GatlingSystem@
gatlinghostname:9044]

The re-connect is going to be associated, but as the internal state of the 
EndpointManager becomes incosistent, an AssertionError will be thrown.

As a workaround I wrote an Auto-Restarter which restarts an ActorSystem in 
case of unexpected shutdown.
But the Netty-NIO stuff was not shutdown orderly. The TCP-Port was still 
bound and restarts fail.

Finally I investigated a little bit more and found a few things I wouldn't 
do (maybe I have not enough insight):

- the death of an EndpointManager should not kill the entire ActorSystem 
(why not restart this subsystem?)
- as theEndpointManager is doing a lot of things, I would move the 
EndpointManager beyond an EndpointSupervisor who ensures aliveness
- Resources (like TCP-Channels) should be closed (at least) automatically 
in postStop
- the map to find quarantined UID's should be a 1 [Address] to N list and 
not 1:1 (have a look in akka.remote.EndpointManager.EndpointRegistry)

-- 
>>  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] ActorSystem terminates when restarted remote ActorSystem has associated after being quarantined

[Wolfgang Friedl]

Even-so on our crashes (
https://groups.google.com/forum/#!searchin/akka-user/disapear/akka-user/QZhDFmrXZaY/_NgOM9O0wmkJ)
 
no quarantine was involved. 


-- 
>>  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] ActorSystem terminates when restarted remote ActorSystem has associated after being quarantined

[schoefts]

Any chance that this is related 
to 
https://groups.google.com/forum/#!searchin/akka-user/disapear/akka-user/QZhDFmrXZaY/_NgOM9O0wmkJ
 
?


Am Donnerstag, 16. April 2015 20:31:56 UTC+2 schrieb rkuhn:
>
> Great detective work, Rick, thanks a lot!
>
> 16 apr 2015 kl. 15:37 skrev Rick Latrine  >:
>
> I've found the cause of sudden termination.
>
> The method akka.remote.EndpointManager#createEndpoint contains an 
> assertion:
> assert(writing || refuseUid.isEmpty)
>
> If an endpoint which was previously quarantined reconnects, refuseUid is 
> existing.
> As the remote endpoint sends a message it a reading endpoint must be 
> created - writing is false.
>
> The resulting AssertionError smashes through all supervising parents until 
> the ActorSystem terminates.
>
> This is the stacktrace right before the AssertionError is thrown:
>
> "Node-A-akka.remote.default-remote-dispatcher-6@1930" prio=5 tid=0x10 
> nid=NA runnable
>   java.lang.Thread.State: RUNNABLE
>   at 
> akka.remote.EndpointManager.akka$remote$EndpointManager$$createEndpoint(Remoting.scala:759)
>   at 
> akka.remote.EndpointManager.createAndRegisterEndpoint(Remoting.scala:665)
>   at 
> akka.remote.EndpointManager.handleInboundAssociation(Remoting.scala:644)
>   at 
> akka.remote.EndpointManager$$anonfun$handleStashedInbound$1.apply(Remoting.scala:424)
>   at 
> akka.remote.EndpointManager$$anonfun$handleStashedInbound$1.apply(Remoting.scala:424)
>   at scala.collection.Iterator$class.foreach(Iterator.scala:727)
>   at scala.collection.AbstractIterator.foreach(Iterator.scala:1157)
>   at scala.collection.IterableLike$class.foreach(IterableLike.scala:72)
>   at scala.collection.AbstractIterable.foreach(Iterable.scala:54)
>   at 
> akka.remote.EndpointManager.handleStashedInbound(Remoting.scala:424)
>   at 
> akka.remote.EndpointManager$$anonfun$1.applyOrElse(Remoting.scala:596)
>   at akka.actor.Actor$class.aroundReceive(Actor.scala:465)
>   at akka.remote.EndpointManager.aroundReceive(Remoting.scala:394)
>   at akka.actor.ActorCell.receiveMessage(ActorCell.scala:516)
>   at akka.actor.ActorCell.invoke(ActorCell.scala:487)
>   at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:254)
>   at akka.dispatch.Mailbox.run(Mailbox.scala:221)
>   at akka.dispatch.Mailbox.exec(Mailbox.scala:231)
>   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)
>
>
> It seems to be a bug, shall I file a ticket?
>
>
> -- 
> >> 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.
>
>
>
>
> *Dr. Roland Kuhn*
> *Akka Tech Lead*
> Typesafe  – Reactive apps on the JVM.
> twitter: @rolandkuhn
> 
>  
>

-- 
>>  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: PoisonPill and message ordering

[Anders Båtstrand]

Thank you for your reply!

If I understand correctly, TerminatePlease should make the actor use 
context().stop(self()), and I can not persist anything while receiving it.

Anders

torsdag 16. april 2015 16.00.26 UTC+2 skrev Anders Båtstrand følgende:
>
> I am having some troubles understanding the finer details of the 
> PoisonPill.
>
> As I understand it, it is a normal message, and will be processed AFTER 
> the persist-callback is executed.
>
> I have the following code in my onReceiveCommand:
>
> System.out.println("About to persist: " + message);
> persist(message, o -> System.out.println("Persisted: " + o));
>
>
> When I run the following against this actor 8not using TestActorRef):
>
> actorRef.tell("Test message", getTestActor());
> Thread.sleep(1000L);
> actorRef.tell(PoisonPill.getInstance(), getTestActor());
>
> Thread.sleep(1000L);
>
>
> I get the expected output:
>
> About to persist: Test message
> Persisted: Test message
>
>
> If I remove the sleep between the messages, I sometimes get the following:
>
> [INFO] [04/16/2015 15:50:11.183] [Test-System-akka.actor.default-
> dispatcher-5] [akka://Test-System/user/my-actor] Message 
> [akka.persistence.Recover] from 
> Actor[akka://Test-System/user/my-actor#867538471] to 
> Actor[akka://Test-System/user/my-actor#867538471] was not delivered. [1] 
> dead letters encountered. [...]
>
> How is this possible? It seems the PoisonPill arrived first... But message 
> ordering should be guaranteed between sender (testActor) and my actor, 
> right?
>
> If I add a short sleep between the two tell, I sometimes get different 
> (internal) messages in deadletters.
>
> Best regards,
>
> Anders
>
>
>
>

-- 
>>  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] CPU spikes using fork-join-executor

[Viktor Klang]

I'd bet on this explanation too.

Having looked at the code I think it should be possible to switch
implementations to something without spinlocking.

On Fri, Apr 17, 2015 at 8:20 AM, Roland Kuhn  wrote:

> Hi Akara,
>
> thanks for all the detailed information, I am 95% certain that I know what
> happens—and I’d call it a bug. To the casual observer the code in
> DirectByteBufferPool looks like a CAS loop, but it actually is an
> open-coded primitive spinlock. If you have more threads competing for this
> lock than you have CPUs it might well happen that the kernel decides to
> schedule out a thread that was holding this lock, and since it is not a
> normal, honest lock, the kernel has no idea why the other threads now all
> are spinning like mad. It probably takes some server-type hardware and a
> bit of patience and good monitoring to actually notice, which is why you
> are the first person to report it :-)
>
> I created a ticket  to track
> this.
>
> Regards,
>
> Roland
>
> 17 apr 2015 kl. 05:20 skrev Akara Sucharitakul <
> akara.sucharita...@gmail.com>:
>
> Nope, this is actually Ubuntu 10.10 on a 4vCPU VM (likely ESX but I can't
> tell for sure). Couple more pieces of information:
>
>- Further experiments with parallelism-factor lowered to 1.0 no longer
>shows the spikes.
>- Trying to profile the spikes with JMC would cause the spikes not to
>happen. The sampling somehow changed the timing characteristics.
>- Switching the ForkJoinExecutor to Java8, the initial experiments
>show similar spikes. Since this was quick implementation of
>ExecutorServiceConfigurator to get Java 8 ForkJoinPool to work, there is
>still a bit of refinement we need to do before we can conclude on this 
> fact.
>
> I'll keep updating this thread as we find out more. Expect it to be a long
> process, though.
>
> Thanks!
> -Akara
>
> On Thursday, April 16, 2015 at 5:03:48 AM UTC-7, Martynas Mickevičius
> wrote:
>>
>> Hi,
>>
>> are you running this application on Windows? There is a known situation
>>  where high CPU usage might
>> occur when using TCP with akka IO.
>>
>> On Tue, Apr 14, 2015 at 7:28 AM, Akara Sucharitakul <
>> akara.suc...@gmail.com> wrote:
>>
>>> Scala 2.11.6, Akka 2.3.9, Spray 1.3.2.
>>>
>>> When testing a particular workload, we ran into CPU spikes. The avg CPU
>>> load is less than 5% but about 6-7 minutes into the run, we start to see
>>> CPU spiking to near 100% lasting for several seconds. This repeats itself
>>> every 6-7 minutes. We can't correlate this with a particular GC activity
>>> just yet. We tested against Java 7_45 but tried Java 8 without much change.
>>>
>>> Spray is configured on the default-dispatcher (Spray default).
>>>
>>> Trying to capture thread dumps at the time spikes happening reveal 9
>>> threads spinning on the followings:
>>>
>>> "default-akka.actor.default-dispatcher-11" prio=10
>>> tid=0x01b2b800 nid=0x3752 runnable [0x7f1191d4]
>>>java.lang.Thread.State: RUNNABLE
>>> at
>>> akka.io.DirectByteBufferPool.takeBufferFromPool(DirectByteBufferPool.scala:41)
>>> at akka.io.DirectByteBufferPool.acquire(DirectByteBufferPool.scala:31)
>>> at akka.io.TcpConnection.doRead(TcpConnection.scala:231)
>>> at
>>> akka.io.TcpConnection$$anonfun$connected$1.applyOrElse(TcpConnection.scala:87)
>>> at scala.PartialFunction$OrElse.applyOrElse(PartialFunction.scala:171)
>>> at akka.actor.Actor$class.aroundReceive(Actor.scala:465)
>>> at akka.io.TcpConnection.aroundReceive(TcpConnection.scala:28)
>>> at akka.actor.ActorCell.receiveMessage(ActorCell.scala:516)
>>> at akka.actor.ActorCell.invoke(ActorCell.scala:487)
>>> at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:254)
>>> at akka.dispatch.Mailbox.run(Mailbox.scala:221)
>>> at akka.dispatch.Mailbox.exec(Mailbox.scala:231)
>>> 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)
>>>
>>> 2 threads show this spinning:
>>>
>>> "default-akka.actor.default-dispatcher-8" prio=10 tid=0x01d6f000
>>> nid=0x374f runnable [0x7f11928d2000]
>>>java.lang.Thread.State: RUNNABLE
>>> at
>>> akka.io.DirectByteBufferPool.offerBufferToPool(DirectByteBufferPool.scala:66)
>>> at akka.io.DirectByteBufferPool.release(DirectByteBufferPool.scala:34)
>>> at akka.io.TcpConnection.doRead(TcpConnection.scala:245)
>>> at
>>> akka.io.TcpConnection$$anonfun$connected$1.applyOrElse(TcpConnection.scala:87)
>>> at scala.PartialFunction$OrElse.applyOrElse(PartialFunction.scala:171)
>>> at akka.actor.Actor$class.aroundReceive(Actor.scala:465)
>>> at akka.io.TcpConnection.aroundReceive(TcpConnection.scala:28)
>>> at akka.actor.ActorCell.receiveMessage