Hi Akara,
The ForkJoinPool is a high-throughput executor pool and therefore has been
designed with the assumption that most of the time threads will be busy. If
you see the scan() method popping up as using the most CPU time then it
means that your threads are mostly idle. This is quite likely
On Fri, Apr 17, 2015 at 8:20 AM, Roland Kuhn goo...@rkuhn.info 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
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
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
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 goo...@rkuhn.info wrote:
Hi Akara,
thanks for all the detailed information, I am 95% certain that
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
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
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
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
http://ourprogr...@hostname.com:3552] - [akka.tcp://GatlingSystem@
gatlinghostname:9044]
The re-connect is going to be associated, but as the
Hi Rick
On Fri, Apr 17, 2015 at 1:01 PM, Rick Latrine rick.latr...@gmail.com
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
http://ourprogr...@hostname.com:3552] -
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
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
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
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
http://doc.akka.io/docs/akka/snapshot/scala/serialization.html but it's
pretty
14 matches
Mail list logo
