[akka-user] Re: How to handle zero (almost) downtime deployments of sharded persistent system.

[Marek Żebrowski]

We use sharding, but with own persistence, but no rembember-entities 
feature.
we do rolling-restarts (yes, not advised, lot's of pain when akka cluster 
goes crazy during restart)
so we just shut down shard nodes one by one, and start new ones. Ususally 
it works.
In theory it should be possible to start new cluster in 'read-only' mode, 
reading data for persistent entities from old cluster and somehow to do the 
`switch` but there is no tools for such scenario, and it would be 
extremeally hard to guarantee that writes from 'old' cluster are persisted 
and read by 'new' cluster for the switch. So we struggle with rolling 
restarts, with all the pains 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: Ideomatic way to do local pubsub in akka

[Matt Edge]

Option 2 is what I normally use since you're taking advantage of what Akka 
already has built in. I have a couple apps in prod that use this technique 
and it works fine for our needs

On Friday, May 6, 2016 at 6:42:33 AM UTC-4, scala solist wrote:
>
> I'm started to work with akka as scala actors become deprecated in favour 
> of akka. So I'm intrested only in local actor systems for now. What is 
> intended way to implement publisher subscriber template in akka?
>
> Akka gives multiple choice, I found three already:
>
>- Store subscribers manually in a publisher actor and sends them 
>messages
>- Send messages to system eventbus and let subscribers to lookup for 
>corresponding messages
>- Create new eventbus for every publisher actor and let subscribers 
>receive all messages without filtering.
>
> Which one is more suitable for local pubsub?
>

-- 
>>  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: Akka and RDBMS?

[Matt Edge]

I'll echo the answer Justin provided. I normally taken existing DB access 
code and wrapped it in an Actor with Futures without issues. Was there any 
specific use case outside of your typical DB interactions (such as trying 
to take advantage of Event Sourcing)?

On Friday, May 13, 2016 at 10:13:57 PM UTC-4, kraythe wrote:
>
> Greetings, 
>
> I have a legacy app with an existing RDBMS and I would like to convert it 
> to be an actor system. I have been researching this and came across Akka 
> persistence but the documentation is thin on how to wire this into legacy 
> backends. Furthermore, because of the high volume of legacy analytics code 
> outside my influence, rewriting the system to not use that database, or 
> making radical schema changes, would be politically impossible so that 
> rules out going to something like a journaled persistence mechanism for 
> Akka persistence. That leaves me in a bit of a quandary. So I was 
> interested in people who have had success integrating an actor system with 
> RDBMS and how they went about the process. Any help would be useful. 
>
> -- Robert
>

-- 
>>  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] Akka Spring integration seems to slowly leak memory

[Mark Kaberman]

I have Akka application which is essentially traverses a very large tree 
where each vertex processing is done by an individual  actor. Different 
kinds of vertices are processed by different actors. The actors are 
implemented as prototype Spring beans (they are derived from the same 
abstract class) and I am using Akka/Spring integration from Akka Spring 
integration . 
The only two differences between the githib example and my code is that I 
use configuration file to configure the routers and the way I get actor 
references. 
Since the example only uses one actor it creates it like 

system.actorOf(SpringExtProvider.get(system).props("CountingActor"), 
"counter");

My actor system is hierarchical and I create my actors differently

public ActorRef createActorRef(String actorBeanName, String 
actorRouterName) {
ActorRef actor = null;
final scala.Option child = context().child(actorRouterName);
if (child != null && child.isDefined()) {
actor = child.get();
} else {
actor = 
getContext().actorOf(SpringExtProvider.get(system).props(actorBeanName).withRouter(new
 
FromConfig()), actorRouterName);
}
}


When my system is running for few days it runs out of memory. I ran the 
profiler and discovered that there is a huge number of actor's Spring beans 
being instantiated. So I instrumented my actors with the instance counters:

public abstract class MyActor extends UntypedActor {


private static AtomicInteger instantiationCount = new AtomicInteger(0);

public MyActor() {
logger.info("ACTOR CREATED. Instantiation count {}", 
instantiationCount.getAndIncrement());

}

@Override
protected void finalize() {
logger.info("ACTOR FINALIZED. Instantiation count {}", 
instantiationCount.getAndDecrement());
}
}


When I run  my application I see constant flow of "ACTOR CREATED" log 
entries with ever incrementing counter with the finalize() method never 
called. Eventually after few days of running the system runs out of memory. 
I am wondering if I am doing something wrong with obtaining the actor 
references or there is some issues with Akka/Spring integration


-- 
>>  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] Message ordering after Akka actor restart

[David Joyce]

The following code example (which you can copy and run) shows a 
MyParentActor that creates a MyChildActor.


The MyChildActor throws an exception for its first message which causes it 
to be restarted.


However, what I want to achieve is for "Message 1" to still be processed 
before "Message 2" on restart of the MyChildActor.

Instead, what is happening is that Message 1 is added to the tail of the 
mailbox queue, and so Message 2 is processed first.


How do I achieve ordering of the original messages on restart of an actor, 
without having to create my own mailbox etc?


http://stackoverflow.com/questions/37683586/akka-message-ordering-after-akka-restart


object TestApp extends App {
  var count = 0
  val actorSystem = ActorSystem()


  val parentActor =  actorSystem.actorOf(Props(classOf[MyParentActor]))
  parentActor ! "Message 1"
  parentActor ! "Message 2"

  class MyParentActor extends Actor with ActorLogging{
var childActor: ActorRef = null

@throws[Exception](classOf[Exception])
override def preStart(): Unit = {
  childActor = context.actorOf(Props(classOf[MyChildActor]))
}

override def receive = {
  case message: Any  => {
childActor ! message
  }
}

override def supervisorStrategy: SupervisorStrategy = {
  OneForOneStrategy() {
  case _: CustomException  => Restart
  case _: Exception => Restart
}
}
  }

  class MyChildActor extends Actor with ActorLogging{


override def preRestart(reason: Throwable, message: Option[Any]): Unit = {
  message match {
case Some(e) => self ! e
  }
}

override def receive = {
  case message: String  => {
if (count == 0) {
  count += 1
  throw new CustomException("Exception occurred")
}
log.info("Received message {}", message)
  }
}
  }

  class CustomException(message: String) extends RuntimeException(message)
}

-- 
>>  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 Spring integration seems to slowly leak memory

[Viktor Klang]

Hi Mark,

Where are you stopping your actors?

-- 
Cheers,
√
On Jun 10, 2016 2:55 PM, "Mark Kaberman"  wrote:

> I have Akka application which is essentially traverses a very large tree
> where each vertex processing is done by an individual  actor. Different
> kinds of vertices are processed by different actors. The actors are
> implemented as prototype Spring beans (they are derived from the same
> abstract class) and I am using Akka/Spring integration from Akka Spring
> integration .
> The only two differences between the githib example and my code is that I
> use configuration file to configure the routers and the way I get actor
> references.
> Since the example only uses one actor it creates it like
>
> system.actorOf(SpringExtProvider.get(system).props("CountingActor"),
> "counter");
>
> My actor system is hierarchical and I create my actors differently
>
> public ActorRef createActorRef(String actorBeanName, String
> actorRouterName) {
> ActorRef actor = null;
> final scala.Option child = context().child(actorRouterName);
> if (child != null && child.isDefined()) {
> actor = child.get();
> } else {
> actor =
> getContext().actorOf(SpringExtProvider.get(system).props(actorBeanName).withRouter(new
> FromConfig()), actorRouterName);
> }
> }
>
>
> When my system is running for few days it runs out of memory. I ran the
> profiler and discovered that there is a huge number of actor's Spring beans
> being instantiated. So I instrumented my actors with the instance counters:
>
> public abstract class MyActor extends UntypedActor {
>
>
> private static AtomicInteger instantiationCount = new AtomicInteger(0);
>
> public MyActor() {
> logger.info("ACTOR CREATED. Instantiation count {}",
> instantiationCount.getAndIncrement());
>
> }
>
> @Override
> protected void finalize() {
> logger.info("ACTOR FINALIZED. Instantiation count {}",
> instantiationCount.getAndDecrement());
> }
> }
>
>
> When I run  my application I see constant flow of "ACTOR CREATED" log
> entries with ever incrementing counter with the finalize() method never
> called. Eventually after few days of running the system runs out of memory.
> I am wondering if I am doing something wrong with obtaining the actor
> references or there is some issues with Akka/Spring integration
>
>
> --
> >> 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] Akka Spring integration seems to slowly leak memory

[Mark Kaberman]

Hi Viktor,

I never stop my actors explicitly (except as reaction to failure in 
supervision strategy). All actors process the vertex data in onReceive() 
method, determine if a vertex has children, get the children actor by 
calling my createActorRef, send the message to a child via tell (never ask) 
and exit onReceive.

Regards,

Mark


On Friday, June 10, 2016 at 10:27:25 AM UTC-4, √ wrote:
>
> Hi Mark,
>
> Where are you stopping your actors?
>
> -- 
> Cheers,
> √
> On Jun 10, 2016 2:55 PM, "Mark Kaberman" > 
> wrote:
>
>> I have Akka application which is essentially traverses a very large tree 
>> where each vertex processing is done by an individual  actor. Different 
>> kinds of vertices are processed by different actors. The actors are 
>> implemented as prototype Spring beans (they are derived from the same 
>> abstract class) and I am using Akka/Spring integration from Akka Spring 
>> integration . 
>> The only two differences between the githib example and my code is that I 
>> use configuration file to configure the routers and the way I get actor 
>> references. 
>> Since the example only uses one actor it creates it like 
>>
>> system.actorOf(SpringExtProvider.get(system).props("CountingActor"), 
>> "counter");
>>
>> My actor system is hierarchical and I create my actors differently
>>
>> public ActorRef createActorRef(String actorBeanName, String 
>> actorRouterName) {
>> ActorRef actor = null;
>> final scala.Option child = context().child(actorRouterName);
>> if (child != null && child.isDefined()) {
>> actor = child.get();
>> } else {
>> actor = 
>> getContext().actorOf(SpringExtProvider.get(system).props(actorBeanName).withRouter(new
>>  
>> FromConfig()), actorRouterName);
>> }
>> }
>>
>>
>> When my system is running for few days it runs out of memory. I ran the 
>> profiler and discovered that there is a huge number of actor's Spring beans 
>> being instantiated. So I instrumented my actors with the instance counters:
>>
>> public abstract class MyActor extends UntypedActor {
>>
>>
>> private static AtomicInteger instantiationCount = new 
>> AtomicInteger(0);
>>
>> public MyActor() {
>> logger.info("ACTOR CREATED. Instantiation count {}", 
>> instantiationCount.getAndIncrement());
>>
>> }
>>
>> @Override
>> protected void finalize() {
>> logger.info("ACTOR FINALIZED. Instantiation count {}", 
>> instantiationCount.getAndDecrement());
>> }
>> }
>>
>>
>> When I run  my application I see constant flow of "ACTOR CREATED" log 
>> entries with ever incrementing counter with the finalize() method never 
>> called. Eventually after few days of running the system runs out of memory. 
>> I am wondering if I am doing something wrong with obtaining the actor 
>> references or there is some issues with Akka/Spring integration
>>
>>
>> -- 
>> >> 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 Spring integration seems to slowly leak memory

[Viktor Klang]

If you create new actors continually and never stop any of them then you
have by design got a leak.

-- 
Cheers,
√
On Jun 10, 2016 4:35 PM, "Mark Kaberman"  wrote:

> Hi Viktor,
>
> I never stop my actors explicitly (except as reaction to failure in
> supervision strategy). All actors process the vertex data in onReceive()
> method, determine if a vertex has children, get the children actor by
> calling my createActorRef, send the message to a child via tell (never ask)
> and exit onReceive.
>
> Regards,
>
> Mark
>
>
> On Friday, June 10, 2016 at 10:27:25 AM UTC-4, √ wrote:
>>
>> Hi Mark,
>>
>> Where are you stopping your actors?
>>
>> --
>> Cheers,
>> √
>> On Jun 10, 2016 2:55 PM, "Mark Kaberman"  wrote:
>>
>>> I have Akka application which is essentially traverses a very large tree
>>> where each vertex processing is done by an individual  actor. Different
>>> kinds of vertices are processed by different actors. The actors are
>>> implemented as prototype Spring beans (they are derived from the same
>>> abstract class) and I am using Akka/Spring integration from Akka Spring
>>> integration .
>>> The only two differences between the githib example and my code is that I
>>> use configuration file to configure the routers and the way I get actor
>>> references.
>>> Since the example only uses one actor it creates it like
>>>
>>> system.actorOf(SpringExtProvider.get(system).props("CountingActor"),
>>> "counter");
>>>
>>> My actor system is hierarchical and I create my actors differently
>>>
>>> public ActorRef createActorRef(String actorBeanName, String
>>> actorRouterName) {
>>> ActorRef actor = null;
>>> final scala.Option child =
>>> context().child(actorRouterName);
>>> if (child != null && child.isDefined()) {
>>> actor = child.get();
>>> } else {
>>> actor =
>>> getContext().actorOf(SpringExtProvider.get(system).props(actorBeanName).withRouter(new
>>> FromConfig()), actorRouterName);
>>> }
>>> }
>>>
>>>
>>> When my system is running for few days it runs out of memory. I ran the
>>> profiler and discovered that there is a huge number of actor's Spring beans
>>> being instantiated. So I instrumented my actors with the instance counters:
>>>
>>> public abstract class MyActor extends UntypedActor {
>>>
>>>
>>> private static AtomicInteger instantiationCount = new
>>> AtomicInteger(0);
>>>
>>> public MyActor() {
>>> logger.info("ACTOR CREATED. Instantiation count {}",
>>> instantiationCount.getAndIncrement());
>>>
>>> }
>>>
>>> @Override
>>> protected void finalize() {
>>> logger.info("ACTOR FINALIZED. Instantiation count {}",
>>> instantiationCount.getAndDecrement());
>>> }
>>> }
>>>
>>>
>>> When I run  my application I see constant flow of "ACTOR CREATED" log
>>> entries with ever incrementing counter with the finalize() method never
>>> called. Eventually after few days of running the system runs out of memory.
>>> I am wondering if I am doing something wrong with obtaining the actor
>>> references or there is some issues with Akka/Spring integration
>>>
>>>
>>> --
>>> >> 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.
>

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

[akka-user] ANNOUNCE: New Remoting Milestone 2

[Patrik Nordwall]

Dear hakkers,

We’re excited to announce that we have released the second development
milestone of the new Akka Remoting, which has the code named Artery. It’s
an early development preview and we encourage you to try it out and give us
feedback, but it’s not intended for production usage yet.

The version number is 2.4-ARTERY-M2 with same artifacts as usual.

It is enabled with the following configuration:

akka.remote.artery {

 enabled = on

 # The hostname or ip clients should connect to.

 hostname = localhost

 # use 0 if you want a random available port

 port = 20200

}

The protocol part of the actor system address is artery (*), so you need to
change previous akka.tcp to artery in for example configuration of cluster
seed-nodes.

A summary of what is included in M2 compared to M1
:


   -

   performance improvements
   -

   initial flight recorder to capture low and high frequency events in
   memory mapped files for debugging (also production issues) and testing
   -

   make it possible to use efficient serialization with ByteBuffers directly
   -

   various bug fixes, including issues with remote deployment
   -

   test coverage by porting most of the old remoting tests


The full list of changes since the last milestone is available under the
2.4-ARTERY-M2

milestone on github for your reference.

We are using Aeron  as the underlying
transport and are implementing the layers on top using Akka Streams. You
find more details in the design document
.

The development branch is artery-dev
, in case you want to take a
look or contribute. Issues are labeled with t:remoting:artery

.

(*) The protocol name is not final and may change before the new remoting
infrastructure goes stable.

-- 

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] Akka Spring integration seems to slowly leak memory

[Mark Kaberman]

Isn't the code:

if (child != null && child.isDefined()) {
   actor = child.get();
} 

supposed to fetch existing actor actor reference instead of creating a new 
one?

If I call stop() at the end of onReceive() what happens to other instances 
of the same actor which could be processing different vertices? Will they 
be shut down as well?



On Friday, June 10, 2016 at 10:48:48 AM UTC-4, √ wrote:
>
> If you create new actors continually and never stop any of them then you 
> have by design got a leak.
>
> -- 
> Cheers,
> √
> On Jun 10, 2016 4:35 PM, "Mark Kaberman" > 
> wrote:
>
>> Hi Viktor,
>>
>> I never stop my actors explicitly (except as reaction to failure in 
>> supervision strategy). All actors process the vertex data in onReceive() 
>> method, determine if a vertex has children, get the children actor by 
>> calling my createActorRef, send the message to a child via tell (never ask) 
>> and exit onReceive.
>>
>> Regards,
>>
>> Mark
>>
>>
>> On Friday, June 10, 2016 at 10:27:25 AM UTC-4, √ wrote:
>>>
>>> Hi Mark,
>>>
>>> Where are you stopping your actors?
>>>
>>> -- 
>>> Cheers,
>>> √
>>> On Jun 10, 2016 2:55 PM, "Mark Kaberman"  wrote:
>>>
 I have Akka application which is essentially traverses a very large 
 tree where each vertex processing is done by an individual  actor. 
 Different kinds of vertices are processed by different actors. The actors 
 are implemented as prototype Spring beans (they are derived from the same 
 abstract class) and I am using Akka/Spring integration from Akka 
 Spring integration 
 . The only 
 two differences between the githib example and my code is that I use 
 configuration file to configure the routers and the way I get actor 
 references. 
 Since the example only uses one actor it creates it like 

 system.actorOf(SpringExtProvider.get(system).props("CountingActor"), 
 "counter");

 My actor system is hierarchical and I create my actors differently

 public ActorRef createActorRef(String actorBeanName, String 
 actorRouterName) {
 ActorRef actor = null;
 final scala.Option child = 
 context().child(actorRouterName);
 if (child != null && child.isDefined()) {
 actor = child.get();
 } else {
 actor = 
 getContext().actorOf(SpringExtProvider.get(system).props(actorBeanName).withRouter(new
  
 FromConfig()), actorRouterName);
 }
 }


 When my system is running for few days it runs out of memory. I ran the 
 profiler and discovered that there is a huge number of actor's Spring 
 beans 
 being instantiated. So I instrumented my actors with the instance counters:

 public abstract class MyActor extends UntypedActor {


 private static AtomicInteger instantiationCount = new 
 AtomicInteger(0);

 public MyActor() {
 logger.info("ACTOR CREATED. Instantiation count {}", 
 instantiationCount.getAndIncrement());

 }

 @Override
 protected void finalize() {
 logger.info("ACTOR FINALIZED. Instantiation count {}", 
 instantiationCount.getAndDecrement());
 }
 }


 When I run  my application I see constant flow of "ACTOR CREATED" log 
 entries with ever incrementing counter with the finalize() method never 
 called. Eventually after few days of running the system runs out of 
 memory. 
 I am wondering if I am doing something wrong with obtaining the actor 
 references or there is some issues with Akka/Spring integration


 -- 
 >> 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+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at https://groups.google.com/group/akka-u

[akka-user] Re: ANNOUNCE: New Remoting Milestone 2

[Andrew Gaydenko]

Patrik,

In the Aeron-as-a-transport context (UDP) what is the akka-http's transport 
(TCP) planned future?

On Friday, June 10, 2016 at 6:46:09 PM UTC+3, Patrik Nordwall wrote:
>
> Dear hakkers,
>
> We’re excited to announce that we have released the second development 
> milestone of the new Akka Remoting, which has the code named Artery. It’s 
> an early development preview and we encourage you to try it out and give us 
> feedback, but it’s not intended for production usage yet.
>
> The version number is 2.4-ARTERY-M2 with same artifacts as usual. 
>
> It is enabled with the following configuration:
>
> akka.remote.artery {
>
>  enabled = on
>
>  # The hostname or ip clients should connect to.
>
>  hostname = localhost
>
>  # use 0 if you want a random available port
>
>  port = 20200
>
> }
>
> The protocol part of the actor system address is artery (*), so you need 
> to change previous akka.tcp to artery in for example configuration of 
> cluster seed-nodes.
>
> A summary of what is included in M2 compared to M1 
> :
>
>
>- 
>
>performance improvements
>- 
>
>initial flight recorder to capture low and high frequency events in 
>memory mapped files for debugging (also production issues) and testing
>- 
>
>make it possible to use efficient serialization with ByteBuffers 
>directly
>- 
>
>various bug fixes, including issues with remote deployment
>- 
>
>test coverage by porting most of the old remoting tests
>
>
> The full list of changes since the last milestone is available under the 
> 2.4-ARTERY-M2 
>  
> milestone on github for your reference.
>
> We are using Aeron  as the 
> underlying transport and are implementing the layers on top using Akka 
> Streams. You find more details in the design document 
> .
>
> The development branch is artery-dev 
> , in case you want to take 
> a look or contribute. Issues are labeled with t:remoting:artery 
> 
> .
>
> (*) The protocol name is not final and may change before the new remoting 
> infrastructure goes stable.
>
> -- 
>
> 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] Akka Spring integration seems to slowly leak memory

[Viktor Klang]

I don't know how your app works or what router config you are using so it
is impossible for me to know what's happening.

Perhaps you have Restarts happening which will create new MyActor instances
but the old instances are still reachable by something else. Spring perhaps?

Use a memory debugger and trace the reachability of those MyActor instances.

-- 
Cheers,
√
On Jun 10, 2016 6:03 PM, "Mark Kaberman"  wrote:

> Isn't the code:
>
> if (child != null && child.isDefined()) {
>actor = child.get();
> }
>
> supposed to fetch existing actor actor reference instead of creating a new
> one?
>
> If I call stop() at the end of onReceive() what happens to other instances
> of the same actor which could be processing different vertices? Will they
> be shut down as well?
>
>
>
> On Friday, June 10, 2016 at 10:48:48 AM UTC-4, √ wrote:
>>
>> If you create new actors continually and never stop any of them then you
>> have by design got a leak.
>>
>> --
>> Cheers,
>> √
>> On Jun 10, 2016 4:35 PM, "Mark Kaberman"  wrote:
>>
>>> Hi Viktor,
>>>
>>> I never stop my actors explicitly (except as reaction to failure in
>>> supervision strategy). All actors process the vertex data in onReceive()
>>> method, determine if a vertex has children, get the children actor by
>>> calling my createActorRef, send the message to a child via tell (never ask)
>>> and exit onReceive.
>>>
>>> Regards,
>>>
>>> Mark
>>>
>>>
>>> On Friday, June 10, 2016 at 10:27:25 AM UTC-4, √ wrote:

 Hi Mark,

 Where are you stopping your actors?

 --
 Cheers,
 √
 On Jun 10, 2016 2:55 PM, "Mark Kaberman"  wrote:

> I have Akka application which is essentially traverses a very large
> tree where each vertex processing is done by an individual  actor.
> Different kinds of vertices are processed by different actors. The actors
> are implemented as prototype Spring beans (they are derived from the same
> abstract class) and I am using Akka/Spring integration from Akka
> Spring integration
> . The only
> two differences between the githib example and my code is that I use
> configuration file to configure the routers and the way I get actor
> references.
> Since the example only uses one actor it creates it like
>
> system.actorOf(SpringExtProvider.get(system).props("CountingActor"),
> "counter");
>
> My actor system is hierarchical and I create my actors differently
>
> public ActorRef createActorRef(String actorBeanName, String
> actorRouterName) {
> ActorRef actor = null;
> final scala.Option child =
> context().child(actorRouterName);
> if (child != null && child.isDefined()) {
> actor = child.get();
> } else {
> actor =
> getContext().actorOf(SpringExtProvider.get(system).props(actorBeanName).withRouter(new
> FromConfig()), actorRouterName);
> }
> }
>
>
> When my system is running for few days it runs out of memory. I ran
> the profiler and discovered that there is a huge number of actor's Spring
> beans being instantiated. So I instrumented my actors with the instance
> counters:
>
> public abstract class MyActor extends UntypedActor {
>
>
> private static AtomicInteger instantiationCount = new
> AtomicInteger(0);
>
> public MyActor() {
> logger.info("ACTOR CREATED. Instantiation count {}",
> instantiationCount.getAndIncrement());
>
> }
>
> @Override
> protected void finalize() {
> logger.info("ACTOR FINALIZED. Instantiation count {}",
> instantiationCount.getAndDecrement());
> }
> }
>
>
> When I run  my application I see constant flow of "ACTOR CREATED" log
> entries with ever incrementing counter with the finalize() method never
> called. Eventually after few days of running the system runs out of 
> memory.
> I am wondering if I am doing something wrong with obtaining the actor
> references or there is some issues with Akka/Spring integration
>
>
> --
> >> 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:

Re: [akka-user] How to handle zero (almost) downtime deployments of sharded persistent system.

[Justin du coeur]

Denis' definition is about right, although I think of it slightly
differently: so that an end user doesn't see any hiccup beyond somewhat
longer latency than normal.  I can think of various ways to achieve this,
but all of them look like a fairly major pain in the tuchus in one way or
another, so I'm curious about whether you have recommendations.

We're using ConductR, but I'm curious about approaches both with and
without it.  Architecturally, you can think of Querki as a Play
application, where 95% of the serious code is under sharded Actors in an
Akka cluster, which is started under but separate from Play's built-in
ActorSystem.  (That's wildly oversimplified, but a decent thousand-foot
block diagram description.)

On Thu, Jun 9, 2016 at 4:31 PM, Viktor Klang  wrote:

> Can we please define "zero" in this context?
>
> On Thu, Jun 9, 2016 at 9:05 PM, Justin du coeur 
> wrote:
>
>> +1 to this question.  For the moment I'm coping with a few seconds of
>> downtime for releases, but we're going to have to become
>> downtime-intolerant before long.  And zero downtime does look challenging
>> in a heavily-sharded application.
>>
>> Personally, I've been wondering if I should be trying to deal with
>> intermixed releases -- bringing the new release up on one node at a time,
>> in the *same* cluster as the old one, and gradually shutting the old ones
>> down.  That seems to make sense in theory, but also seems bloody dangerous
>> -- it requires that the releases be 100% wire-compatible, which is hard to
>> test and presents evolutionary challenges -- and I'm not sure if there are
>> gotchas to be aware of...
>>
>> On Thu, Jun 9, 2016 at 3:44 AM, Denis Mikhaylov 
>> wrote:
>>
>>> Hi, hakkers!
>>>
>>> I have a distributed app that uses `akka-persistence` and
>>> `akka-sharding`.
>>> For some of my shard coordinators I use `remember entities` feature.
>>> I heard (from Bonér or Kuhn, can't say for sure) that in production it's
>>> better to use blue/green deployments.
>>> As I see, the steps are:
>>> 1. Deploy and start fresh application, let it form cluster (don't start
>>> any ShardRegions yet)
>>> 2. Stop ShardRegions that do not use `remember entities` features (e.g.
>>> Aggregate Roots).
>>> 3. Start these ShardRegions on freshly deployed system
>>> 4. Switch external traffic to new system (so that we already can accept
>>> external commands).
>>> 5. Stop ShardRegions that use `remember entities` features (e.g. Long
>>> Running Processes, that react to events from Aggregate Roots).
>>> 6. Start these ShardRegions on freshly deployed system (here I need akka
>>> sharding to restart entities that were alive on previous system)
>>> 7. Shut down old system
>>>
>>> So the questions are:
>>> 1. Is there any improvements to the deployment process?
>>> 2. Wouldn't this scenario corrupt Sharding related or any Akka internal
>>> data in journal?
>>> 3. How do you handle deployments in production?
>>>
>>> Thanks a lot,
>>> Denis.
>>>
>>> --
>>> >> 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.
>>
>
>
>
> --
> Cheers,
> √
>
> --
> >> 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: Another Newbie Question -- Sending message to Millions of Cluster sharded actors.

[kraythe]

The problem is I need to have the actors running and from what I understand 
the sharding system doesn't start an actor until you actually pass a 
message to an actor with that id. They cant subscribe to the topic until 
they are started. Now I could have some mediator actor to start them but 
then I would have to know if the ID of the actor would end up on the 
current system. Otherwise I would be making a remote call anyway. 

On Wednesday, June 8, 2016 at 3:36:07 PM UTC-5, Rob Crawford wrote:
>
> As I recall, the distributed pub/sub sends a single message to each node, 
> then the message is distributed to the subscribers on those nodes. So it's 
> likely more efficient to use this method to ask the actors for their state. 
> More efficient both ways -- no million-iteration loop to generate the 
> messages, and no transmission of millions of messages.
>
>
>

-- 
>>  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] Runtime issue with Cluster Sharding.

[kraythe]

Greetings, 

I apologize if this has been asked but I am having what I assume is a 
config problem. When I start a single node I get the following logged 
errors and my sharded actors don't start. The errors are like such: 

2016-06-10 14:07:01 -0500 - [INFO] - Message 
[akka.cluster.InternalClusterAction$InitJoin$] from 
Actor[akka://application/system/cluster/core/daemon/joinSeedNodeProcess-1#-956463865]
 
to Actor[akka://application/deadLetters] was not delivered. [10] dead 
letters encountered, no more dead letters will be logged. This logging can 
be turned off or adjusted with configuration settings 
'akka.log-dead-letters' and 'akka.log-dead-letters-during-shutdown'.

2016-06-10 14:07:01 -0500 - [WARN] - Trying to register to coordinator at 
[None], but no acknowledgement. Total [368] buffered messages.

2016-06-10 14:07:03 -0500 - [WARN] - Trying to register to coordinator at 
[None], but no acknowledgement. Total [368] buffered messages.

2016-06-10 14:07:05 -0500 - [WARN] - Trying to register to coordinator at 
[None], but no acknowledgement. Total [368] buffered messages.
2016-06-10 14:07:06 -0500 - [WARN] - Association with remote system 
[akka.tcp://ClusterSystem@127.0.0.1:2551] has failed, address is now gated 
for [5000] ms. Reason: [Association failed with 
[akka.tcp://ClusterSystem@127.0.0.1:2551]] Caused by: [Connection refused: 
/127.0.0.1:2551]ere...

As you can see there seems to be a problem starting sharding. So I checked 
my config and build.sbt and it seems to me I have my ducks in a row. Here 
is the akka.conf file (which is included by application.conf in a play2.5 
app.) 

akka {

  log-dead-letters-during-shutdown = off
  extensions = [
"com.romix.akka.serialization.kryo.KryoSerializationExtension$",
"akka.cluster.metrics.ClusterMetricsExtension"
  ]

  actor {
provider = "akka.cluster.ClusterActorRefProvider"
serializers {
  java = "akka.serialization.JavaSerializer"
  proto = "akka.remote.serialization.ProtobufSerializer"
  // FIXME define bindings in code for config.
  kryo = "com.romix.akka.serialization.kryo.KryoSerializer"
}

# See for Documentation: https://github.com/romix/akka-kryo-serialization
kryo {
  type = "graph"
  idstrategy = "automatic"
  buffer-size = 4096
  max-buffer-size = -1
  use-manifests = false
  post-serialization-transformations = "off"
  kryo-custom-serializer-init = 
"distributed.serialization.SerializationConfigUtil"
  implicit-registration-logging = true
  kryo-trace = false
}

# default dispatcher used by Play
default-dispatcher {
  # This will be used if you have set "executor = "fork-join-executor""
  fork-join-executor {
# Min number of threads to cap factor-based parallelism number to
parallelism-min = 8

# The parallelism factor is used to determine thread pool size using the
# following formula: ceil(available processors * factor). Resulting size
# is then bounded by the parallelism-min and parallelism-max values.
parallelism-factor = 4.0

# Max number of threads to cap factor-based parallelism number to
parallelism-max = 64

# Setting to "FIFO" to use queue like peeking mode which "poll" or 
"LIFO" to use stack
# like peeking mode which "pop".
task-peeking-mode = "FIFO"
  }
}
  }

  # See 
http://doc.akka.io/docs/akka/snapshot/general/configuration.html#config-akka-remote
  remote {
log-remote-lifecycle-events = off
enabled-transports = ["akka.remote.netty.tcp"]
netty.tcp {
  # This causes the server to select a random available port in local mode 
and is important for running multiple
  # nodes on the same machine. It is overridden in environments.
  port = 0
}
  }

  cluster {
// FIXME cant use static config!
seed-nodes = [
   "akka.tcp://ClusterSystem@127.0.0.1:2551"
]

metrics {
  enabled = on
  native-library-extract-folder = ${user.dir}/target/native
}

# auto downing is NOT safe for production deployments.
# you may want to use it during development, read more about it in the docs.
#
# auto-down-unreachable-after = 10s
  }

  akka {
persistence {
  journal.plugin = "akka-persistence-sql-async.journal"
  snapshot-store.plugin = "akka-persistence-sql-async.snapshot-store"
}
  }

  akka-persistence-sql-async {
journal.class = "akka.persistence.journal.sqlasync.MySQLAsyncWriteJournal"
snapshot-store.class = 
"akka.persistence.snapshot.sqlasync.MySQLSnapshotStore"

user = ${db.default.username}
password = ${db.default.password}
url = ${db.default.url}
max-pool-size = 4
wait-queue-capacity = 1

metadata-table-name = "akka_persistence_metadata"
journal-table-name = "akka_persistence_journal"
snapshot-table-name = "akka_persistence_snapshots"
  }
}


And the build.sbt 

libraryDependencies ++= Seq(
  javaCore,
  

Re: [akka-user] Re: Another Newbie Question -- Sending message to Millions of Cluster sharded actors.

[Justin du coeur]

Ahhh -- I get it.  So you're trying to "pre-inflate" the whole cluster of
shards and entities, and they're expected to be essentially static after
that?  Interesting problem.

So basically, I'd recommend the previous advice to start with: try it out
the easy way, and see whether it works acceptably.  It's potentially
straining the system, but it's not *obviously* a crisis, and trying it
shouldn't be too hard.


If that doesn't work, I *suspect* you can do this in a much lower-traffic
way, but it would take a *bunch* more hacking of the sharding system.
Consider:

-- You have a lot of control over where a given message gets routed,
through the ExtractShardId function.  That implicitly determines what
Shards exist: the possible Shards are exactly the possible return values of
that function.
-- You *can* take control over where a given Shard lives, by defining a
ShardAllocationStrategy.  Folks usually just use the default, allowing
things to happen dynamically, but if you want more static control, you can
likely make that bend to your will.

So, in order to inflate huge numbers of entities with minimal network
traffic, it seems like you could pre-decide on how you *want* the
allocation to work, build ExtractShardId and ShardAllocationStrategy
accordingly, and send "init" messages to each Entity separately from the
node where you are coercing it to live.  That is, each node would be
responsible for "inflating" the Entities that are going to live on it
according to the ShardAllocationStrategy.

I don't think I'd recommend this approach unless the situation is dire
enough to warrant it -- it's a lot of work, and requires you to take on a
lot of responsibility for the sharding -- but consider it food for thought
if things look problematic...

On Fri, Jun 10, 2016 at 2:43 PM, kraythe  wrote:

> The problem is I need to have the actors running and from what I
> understand the sharding system doesn't start an actor until you actually
> pass a message to an actor with that id. They cant subscribe to the topic
> until they are started. Now I could have some mediator actor to start them
> but then I would have to know if the ID of the actor would end up on the
> current system. Otherwise I would be making a remote call anyway.
>
> On Wednesday, June 8, 2016 at 3:36:07 PM UTC-5, Rob Crawford wrote:
>>
>> As I recall, the distributed pub/sub sends a single message to each node,
>> then the message is distributed to the subscribers on those nodes. So it's
>> likely more efficient to use this method to ask the actors for their state.
>> More efficient both ways -- no million-iteration loop to generate the
>> messages, and no transmission of millions of messages.
>>
>>
>> --
> >> 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: Another Newbie Question -- Sending message to Millions of Cluster sharded actors.

[kraythe]

Always thought provoking response. The issue is that I have a number of 
entities that are looking for certain events and updating themselved based 
on those events. If they change then they post another message to a topic 
indicating they were updated. There is another entity that integrates those 
changes into a analytics calculation. So the entities I am trying to 
inflate are A and there are millions of them. If they change then they 
inform all the Bs that care. Multiple Bs care about potentially the same A. 
I thought about doing all the updating on every B but I was concerned this 
would cause the analytics calculation in B to take that much longer. 
Already its evaluating data from millions of As but currently its just 
sorting. If I integrate the events into Bs and update the objects from 
within the B then the time could tripple. So the idea was to inflate all 
the As that feed the Bs and then have them detect updates and feed a topic 
for the Bs. Of course that requires all the As participating to be alive to 
get the distributed pub sub messages. 

For now I just power through sending all 1m As an init message but the 
implementation bothers me. 

On Friday, June 10, 2016 at 2:28:46 PM UTC-5, Justin du coeur wrote:
>
> Ahhh -- I get it.  So you're trying to "pre-inflate" the whole cluster of 
> shards and entities, and they're expected to be essentially static after 
> that?  Interesting problem.
>
> So basically, I'd recommend the previous advice to start with: try it out 
> the easy way, and see whether it works acceptably.  It's potentially 
> straining the system, but it's not *obviously* a crisis, and trying it 
> shouldn't be too hard.
>
>
> If that doesn't work, I *suspect* you can do this in a much lower-traffic 
> way, but it would take a *bunch* more hacking of the sharding system.  
> Consider:
>
> -- You have a lot of control over where a given message gets routed, 
> through the ExtractShardId function.  That implicitly determines what 
> Shards exist: the possible Shards are exactly the possible return values of 
> that function.
> -- You *can* take control over where a given Shard lives, by defining a 
> ShardAllocationStrategy.  Folks usually just use the default, allowing 
> things to happen dynamically, but if you want more static control, you can 
> likely make that bend to your will.
>
> So, in order to inflate huge numbers of entities with minimal network 
> traffic, it seems like you could pre-decide on how you *want* the 
> allocation to work, build ExtractShardId and ShardAllocationStrategy 
> accordingly, and send "init" messages to each Entity separately from the 
> node where you are coercing it to live.  That is, each node would be 
> responsible for "inflating" the Entities that are going to live on it 
> according to the ShardAllocationStrategy.
>
> I don't think I'd recommend this approach unless the situation is dire 
> enough to warrant it -- it's a lot of work, and requires you to take on a 
> lot of responsibility for the sharding -- but consider it food for thought 
> if things look problematic...
>
> On Fri, Jun 10, 2016 at 2:43 PM, kraythe > 
> wrote:
>
>> The problem is I need to have the actors running and from what I 
>> understand the sharding system doesn't start an actor until you actually 
>> pass a message to an actor with that id. They cant subscribe to the topic 
>> until they are started. Now I could have some mediator actor to start them 
>> but then I would have to know if the ID of the actor would end up on the 
>> current system. Otherwise I would be making a remote call anyway. 
>>
>> On Wednesday, June 8, 2016 at 3:36:07 PM UTC-5, Rob Crawford wrote:
>>>
>>> As I recall, the distributed pub/sub sends a single message to each 
>>> node, then the message is distributed to the subscribers on those nodes. So 
>>> it's likely more efficient to use this method to ask the actors for their 
>>> state. More efficient both ways -- no million-iteration loop to generate 
>>> the messages, and no transmission of millions of messages.
>>>
>>>
>>> -- 
>> >> 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 me

Re: [akka-user] Akka Spring integration seems to slowly leak memory

[Mark Kaberman]

I debugged my application and it seems to be a bug in Akka:

My routers are defined similarly to each other as
/myActor/ {
  dispatcher = my-pinned-dispatcher
  router = round-robin
  nr-of-instances = 10
}

When I debug into my actor creation and messaging method

public sendAkkaMessage(String actorBeanName, String actorRouterName, Object 
message) {
ActorRef actor = null;
final scala.Option child = context().child(actorRouterName);
if (child != null && child.isDefined()) {
actor = child.get();
} else {
actor = 
getContext().actorOf(SpringExtProvider.get(system).props(actorBeanName).withRouter(new
 
FromConfig()), actorRouterName);
}
actor.tell(message, self());
}

I see that when a new actor is created by calling getContext().actorOf()... 
 I see 10 new Spring beans being created (as per Akka config). When an 
actor is created via child.get() I see one Spring bean is created. So it 
seems that in the case of a get() Akka disregards already created Spring 
beans and creates one more. 
 


On Friday, June 10, 2016 at 1:24:21 PM UTC-4, √ wrote:
>
> I don't know how your app works or what router config you are using so it 
> is impossible for me to know what's happening.
>
> Perhaps you have Restarts happening which will create new MyActor 
> instances but the old instances are still reachable by something else. 
> Spring perhaps?
>
> Use a memory debugger and trace the reachability of those MyActor 
> instances.
>
> -- 
> Cheers,
> √
> On Jun 10, 2016 6:03 PM, "Mark Kaberman" > 
> wrote:
>
>> Isn't the code:
>>
>> if (child != null && child.isDefined()) {
>>actor = child.get();
>> } 
>>
>> supposed to fetch existing actor actor reference instead of creating a 
>> new one?
>>
>> If I call stop() at the end of onReceive() what happens to other 
>> instances of the same actor which could be processing different vertices? 
>> Will they be shut down as well?
>>
>>
>>
>> On Friday, June 10, 2016 at 10:48:48 AM UTC-4, √ wrote:
>>>
>>> If you create new actors continually and never stop any of them then you 
>>> have by design got a leak.
>>>
>>> -- 
>>> Cheers,
>>> √
>>> On Jun 10, 2016 4:35 PM, "Mark Kaberman"  wrote:
>>>
 Hi Viktor,

 I never stop my actors explicitly (except as reaction to failure in 
 supervision strategy). All actors process the vertex data in onReceive() 
 method, determine if a vertex has children, get the children actor by 
 calling my createActorRef, send the message to a child via tell (never 
 ask) 
 and exit onReceive.

 Regards,

 Mark


 On Friday, June 10, 2016 at 10:27:25 AM UTC-4, √ wrote:
>
> Hi Mark,
>
> Where are you stopping your actors?
>
> -- 
> Cheers,
> √
> On Jun 10, 2016 2:55 PM, "Mark Kaberman"  wrote:
>
>> I have Akka application which is essentially traverses a very large 
>> tree where each vertex processing is done by an individual  actor. 
>> Different kinds of vertices are processed by different actors. The 
>> actors 
>> are implemented as prototype Spring beans (they are derived from the 
>> same 
>> abstract class) and I am using Akka/Spring integration from Akka 
>> Spring integration 
>> . The 
>> only two differences between the githib example and my code is that I 
>> use 
>> configuration file to configure the routers and the way I get actor 
>> references. 
>> Since the example only uses one actor it creates it like 
>>
>> system.actorOf(SpringExtProvider.get(system).props("CountingActor"), 
>> "counter");
>>
>> My actor system is hierarchical and I create my actors differently
>>
>> public ActorRef createActorRef(String actorBeanName, String 
>> actorRouterName) {
>> ActorRef actor = null;
>> final scala.Option child = 
>> context().child(actorRouterName);
>> if (child != null && child.isDefined()) {
>> actor = child.get();
>> } else {
>> actor = 
>> getContext().actorOf(SpringExtProvider.get(system).props(actorBeanName).withRouter(new
>>  
>> FromConfig()), actorRouterName);
>> }
>> }
>>
>>
>> When my system is running for few days it runs out of memory. I ran 
>> the profiler and discovered that there is a huge number of actor's 
>> Spring 
>> beans being instantiated. So I instrumented my actors with the instance 
>> counters:
>>
>> public abstract class MyActor extends UntypedActor {
>>
>>
>> private static AtomicInteger instantiationCount = new 
>> AtomicInteger(0);
>>
>> public MyActor() {
>> logger.info("ACTOR CREATED. Instantiation count {}", 
>> instantiationCount.getAndIncrement());
>>
>> }
>>
>> @Override
>> protected void finalize() {
>> logger.

Re: [akka-user] Akka Persistence - callback for persistAll when all events have been saved

[Aditya Prasad]

Newb question: what if I don't have an event for the deferAsync() call? I 
just want to execute a block with the guarantee that it runs after 
persistAll() completes.

On Sunday, February 28, 2016 at 7:20:47 AM UTC-8, Łukasz Gąsior wrote:
>
> Thanks! 
> I think that's exactly what I need, and now that I know about it I see a 
> section in docs right above 
> "Nested persist calls", which I was looking at before posting my question.
>
> Cheers
>
> W dniu niedziela, 28 lutego 2016 15:50:55 UTC+1 użytkownik Konrad Malawski 
> napisał:
>>
>> A defer() just after the persistAll call should pretty much be what you 
>> need, unless I missed something :)
>> On Feb 28, 2016 15:23, "Łukasz Gąsior"  wrote:
>>
>>> Hi,
>>>
>>> Is there a way to execute a handler when all events have been saved 
>>> using persistAll?
>>> i.e. have (handler: Seq[A] => Unit) or even (handler: () => Unit)
>>>
>>> Cheers,
>>> Łukasz
>>>
>>> -- 
>>> >> 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.

[akka-user] Newbie question: connecting to read journal in preStart

[Aditya Prasad]

override def preStart = {
  super.preStart
  val persistenceIdsSink = Sink.actorRef(self, 
MyViewActor.Protocol.PersistenceIdsComplete)
  val source: Source[MyId, NotUsed] = 
readJournal.allPersistenceIds().map(MyId.apply)
  source.runWith(persistenceIdsSink)
}


Is this a sensible pattern for wiring up my source/sink?

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