Re: [akka-user] Re: Logger specified in config can't be loaded [akka.event.slf4j.Slf4jLogger]

[Patrik Nordwall]

There is a config setting for the 5 seconds timeout, you can try to
increase it.

sön 23 okt. 2016 kl. 16:18 skrev Andrew James Ramirez <
andrewjamesrami...@gmail.com>:

> Try doing
>
> sbt clean update compile
>
>
>
>
> On Thursday, October 20, 2016 at 11:52:48 PM UTC+8, Gerard Vico wrote:
>
> Hi,
>
> I am working in a project with Scala and Akka. Two days ago, I can't
> launch the test because this error is thrown:
>
> [WARN] [10/20/2016 15:47:32.743] [pool-1-thread-1]
> [EventStream(akka://default)] Logger log1-Slf4jLogger did not respond
> within Timeout(5000 milliseconds) to InitializeLogger(bus)
> error while starting up loggers
> akka.ConfigurationException: Logger specified in config can't be loaded
> [akka.event.slf4j.Slf4jLogger] due to
> [akka.event.Logging$LoggerInitializationException: Logger log1-Slf4jLogger
> did not respond with LoggerInitialized, sent instead [TIMEOUT]]
>
> I am working in a team with 2 collegues and they don't have any problem
> with the same code (same branch).
>
> Any idea about what is happening?
>
> Thank you so much in advance.
>
> --
> >> 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-Cluster] PubSub Extension makes the cluster crash.

[Patrik Nordwall]

Hi Philippe,

You can use the cluster node role to use pub-sub on a subset of nodes. You
have to start the extension on all nodes with the given role.

I would be interested in taking a look at the logs from such a "crash". I
would expect that messages would be dropped, but nothing more. I would like
to fix such a problem, if it exists. Can you create an issue and attach
logs?

/Patrik
tors 20 okt. 2016 kl. 22:17 skrev Philippe N. :

> Hello,
>
> We are new at using Akka in general. So far we managed to create a cluster
> with the following components:
> Seeds
> Cluster-manager (simply display the status of componenents)
> Backend
> Frontend
>
> Recently we decided to add the pubsub extension to the backend and
> frontend. However introducing it makes the whole cluster crash, basically
> everything gets disassociated. We added it to the Seeds and then the
> Cluster-manager, and it works, If we add a new component to the cluster
> without the extension it crashes the cluster than the cluster cannot
> recuperate at all.
>
> Is this normal?
>
> Do we really need to add the extension to all components for the cluster
> to work properly?
>
> Thank you,
> Philippe
>
>
>
> --
> >> 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] Implementation of Persistent Actor with initial state

[Patrik Nordwall]

I think fsm has something similar to recovery completed

lör 15 okt. 2016 kl. 11:34 skrev Jakub Liska <liska.ja...@gmail.com>:

> Yes, that's what I meant.
>
> Perfect, it would work in Persistent Actor... What about PersistentFSM ?
> I guess that I will have to introduce an initial FSMState where I would
> check whether the persistent state is empty or it was recovered and act on
> that.
>
> Cool, thanks a lot Patrik !
>
>
>
> On Saturday, October 15, 2016 at 8:14:22 AM UTC+2, Patrik Nordwall wrote:
>
> I'm not sure I understand. You want to read the old data if the persistent
> actor doesn't have any events of its own?
>
> You can check the state when you get RecoveryCompleted. You can also count
> the events/snapshot in receiveRecover and act on that when
> RecoveryCompleted.
>
> /Patrik
>
> fre 14 okt. 2016 kl. 22:11 skrev Jakub Liska <liska...@gmail.com>:
>
> Hey,
>
> what is the best practice to do in this hypothetical scenario :
> 1) Say you have a time series pipeline that started at 2014 and created
> persistent state on S3 and other DB systems
> 2) You can introspect these storages and know what partitions already
> exists in all of them
> 3) The persistent actor's job would be scheduling tasks for newly added
> partitions (next minute/hour/day, etc.)
> 3) Now at 2016 you deploy a persistent Actor that will hold state about
> completness (existing partitions) of these storages and keep up with their
> progress
>
> The way I see it, when this persistent Actor boots up, it will have 2
> choices :
> a) either it starts for the very first time, it will have to replay all
> DomainEvents for all historical partitions from 2014 to itself to
> initialize it's state to the current view of the world in 2016
> b) or it restarts or crashes and its state is replayed from the journal
> implicitly
>
> Now I cannot find any reference of how this should be done. The only
> solution that comes to mind is to use persistence-query and obtaining
> Journal :
>
>readJournal.currentPersistenceIds()
>readJournal.eventsByPersistenceId("user-us-1337")
>1.
>And if the result is empty, then it will reconstructs the history.
>
> Is this a way to go?
>
> --
> >>>>>>>>>> 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.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Implementation of Persistent Actor with initial state

[Patrik Nordwall]

I'm not sure I understand. You want to read the old data if the persistent
actor doesn't have any events of its own?

You can check the state when you get RecoveryCompleted. You can also count
the events/snapshot in receiveRecover and act on that when
RecoveryCompleted.

/Patrik

fre 14 okt. 2016 kl. 22:11 skrev Jakub Liska :

> Hey,
>
> what is the best practice to do in this hypothetical scenario :
> 1) Say you have a time series pipeline that started at 2014 and created
> persistent state on S3 and other DB systems
> 2) You can introspect these storages and know what partitions already
> exists in all of them
> 3) The persistent actor's job would be scheduling tasks for newly added
> partitions (next minute/hour/day, etc.)
> 3) Now at 2016 you deploy a persistent Actor that will hold state about
> completness (existing partitions) of these storages and keep up with their
> progress
>
> The way I see it, when this persistent Actor boots up, it will have 2
> choices :
> a) either it starts for the very first time, it will have to replay all
> DomainEvents for all historical partitions from 2014 to itself to
> initialize it's state to the current view of the world in 2016
> b) or it restarts or crashes and its state is replayed from the journal
> implicitly
>
> Now I cannot find any reference of how this should be done. The only
> solution that comes to mind is to use persistence-query and obtaining
> Journal :
>
>readJournal.currentPersistenceIds()
>readJournal.eventsByPersistenceId("user-us-1337")
>1.
>And if the result is empty, then it will reconstructs the history.
>
> Is this a way to go?
>
> --
> >> 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] Testing Akka Persistence Recovery

[Patrik Nordwall]

On Thu, Oct 13, 2016 at 11:08 AM, Sebastian Piu <sebastian@gmail.com>
wrote:

> Is there any way of simulating the failure while processing, or force
> terminate the actor?
>
There is a akka.actor.Kill message that will make the Actor throw an
ActorKilledException, which will trigger supervision. The default
supervision strategy for that exception is to stop the actor, but you can
implement something else in your parent.

> It if my understanding that stopping will do it after the current message
> finishes right?
>
Yes, there is no way to interrupt the processing of current message.



>
> On Thu, 13 Oct 2016, 08:01 Patrik Nordwall, <patrik.nordw...@gmail.com>
> wrote:
>
>> The actor's name and persistenceId doesn't have to be the same, but if
>> you need that you must wait until it has been terminated before starting
>> the new instance
>>
>> watch(subscriber1)
>> expectTerminated(subscriber2)
>>
>> On Thu, Oct 13, 2016 at 7:10 AM, Richard Rodseth <rrods...@gmail.com>
>> wrote:
>>
>> Thanks, but if I do this:
>>
>>   system.stop(subscriber1)
>>
>>   val subscriber2 = system.actorOf(props1, "name1")
>>
>> I get an error that "name1" is not unique. The actor's persistence id is:
>>
>>   override val persistenceId: String = "subscriber-" + self.path.name
>>
>> On Wed, Oct 12, 2016 at 9:59 PM, Patrik Nordwall <
>> patrik.nordw...@gmail.com> wrote:
>>
>> You can stop it and start a new actor with the same persistenceId.
>> /Patrik
>> tors 13 okt. 2016 kl. 06:33 skrev Richard Rodseth <rrods...@gmail.com>:
>>
>> I've been able to test recovery by using the in-memory journal and
>> sending a "bomb" message to the actor, which is handled by throwing an
>> exception :
>>
>> myActorRef ! DoSomething
>> myActorRef ! "bomb"
>> myActorRef ! GetState
>> expectMsg(MyActorState(...))
>>
>> Is there any way I can do this without having to add the special "bomb"
>> message to the the Actor.
>>
>> 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 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.
>> Visit this group at https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>>
>> --
>>
>> Patrik Nordwall
>> Akka Tech Lead
>> Lightbend <http://www.lightben

Re: [akka-user] Testing Akka Persistence Recovery

[Patrik Nordwall]

The actor's name and persistenceId doesn't have to be the same, but if you
need that you must wait until it has been terminated before starting the
new instance

watch(subscriber1)
expectTerminated(subscriber2)

On Thu, Oct 13, 2016 at 7:10 AM, Richard Rodseth <rrods...@gmail.com> wrote:

> Thanks, but if I do this:
>
>   system.stop(subscriber1)
>
>   val subscriber2 = system.actorOf(props1, "name1")
>
> I get an error that "name1" is not unique. The actor's persistence id is:
>
>   override val persistenceId: String = "subscriber-" + self.path.name
>
> On Wed, Oct 12, 2016 at 9:59 PM, Patrik Nordwall <
> patrik.nordw...@gmail.com> wrote:
>
>> You can stop it and start a new actor with the same persistenceId.
>> /Patrik
>> tors 13 okt. 2016 kl. 06:33 skrev Richard Rodseth <rrods...@gmail.com>:
>>
>>> I've been able to test recovery by using the in-memory journal and
>>> sending a "bomb" message to the actor, which is handled by throwing an
>>> exception :
>>>
>>> myActorRef ! DoSomething
>>> myActorRef ! "bomb"
>>> myActorRef ! GetState
>>> expectMsg(MyActorState(...))
>>>
>>> Is there any way I can do this without having to add the special "bomb"
>>> message to the the Actor.
>>>
>>> Thanks.
>>>
>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou
>>> p/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/c
>> urrent/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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Testing Akka Persistence Recovery

[Patrik Nordwall]

You can stop it and start a new actor with the same persistenceId.
/Patrik
tors 13 okt. 2016 kl. 06:33 skrev Richard Rodseth :

> I've been able to test recovery by using the in-memory journal and sending
> a "bomb" message to the actor, which is handled by throwing an exception :
>
> myActorRef ! DoSomething
> myActorRef ! "bomb"
> myActorRef ! GetState
> expectMsg(MyActorState(...))
>
> Is there any way I can do this without having to add the special "bomb"
> message to the the Actor.
>
> 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 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: Journal Plugin Java API question regarding doAsyncWriteMessages

[Patrik Nordwall]

It will not be restarted. It will be stopped. You must anyway handle
journal failures.

ons 12 okt. 2016 kl. 09:44 skrev Daniel Stoner <daniel.sto...@ocado.com>:

> Beware that if you don't handle serialisation failures as rejection - then
> you can easily get into a state whereby another actor keeps sending a
> message that simply will not serialise when persisted. Your only awareness
> of this will be the log errors that might occur in your JournalImpl and
> your persistent actor will keep restarting because of the failure coming
> from the journal.
>
> This can end up being experienced by your read requests to the datastore
> going through the roof and if like me you use a store which throttles based
> on reads per second then you can end up denying service to the rest of your
> app.
>
> On the flip side I've seen journal implementations which rely implicitly
> on gapless sequences for reading from the DB - for instance the dynamodb
> journal impl (last time I looked at least) reads messages in batches of 50
> until it finds no messages in the batch - despite this implicit requirement
> it does support rejections. If you have a continuous series of 50
> rejections then your in really deep trouble.
>
> My best suggestion would be to set up a simple test which initialises a
> persistent actor with a journal which rejects everything. Take a look at
> messages like aroundPreStart and onPersistRejected and onPersistFailure and
> see what behaviour you want your application to have.
>
> As a final comment - if your implementing your own Journal beware that
> EventAdapters are not free and if you plan on allowing the feature in
> future (And it is incredibly useful whenever you plan to change your beans
> from whatever might be stored to some new version) then you must implement
> this in your Journal. We implemented EventAdapter on the read side only (EG
> You can read an old version of a Bean and auto-convert it into a newer
> version) and the code for that was as simple as:
>
> (Config is com.typesafe.config.Config)
> EventAdapters eventAdapters = EventAdapters.apply(actorSystem,
> actorConfig);
>
> private List persistentFromByteBuffer(ByteBuffer b) throws
> NotSerializableException {
> PersistentRepr originalRepr =
> serialization.deserialize(ByteString.fromByteBuffer(b).toArray(),
> PersistentRepr.class).get();
> EventSeq adapted =
> config.eventAdapters.get(originalRepr.payload().getClass()).fromJournal(originalRepr.payload(),
> originalRepr.manifest());
>
> return
> JavaConversions.asJavaCollection(adapted.events()).stream().map(originalRepr::withPayload).collect(Collectors.toList());
> }
>
> On Tuesday, 11 October 2016 15:42:14 UTC+1, Patrik Nordwall wrote:
>
>
>
> On Tue, Oct 11, 2016 at 3:55 PM, Ian Grima <iang...@gmail.com> wrote:
>
> Thanks for your reply :). If I were not to support rejections, that would
> imply that if a serialization error occurs i would simply fail the entire
> Future correct?
>
>
> yes, right
>
>
> Gapless sequence numbers does indeed sound like a worthy consideration.
>
> Thanks Again,
> Ian Grima
>
> On Tuesday, 11 October 2016 12:21:38 UTC+2, Patrik Nordwall wrote:
>
>
>
> On Tue, Oct 11, 2016 at 11:24 AM, Ian Grima <iang...@gmail.com> wrote:
>
> I am still looking for an opinion on this matter if anyone could help :)
>
>
>
> On Saturday, 8 October 2016 15:31:32 UTC+2, Ian Grima wrote:
>
> Hi,
>
>   I was reading up on the API of implementing a custom journal plugin in
> Java. Could you please tell me if I have understood this section correctly.
>
> With regards to the following API:
>
>  Future<Iterable<Optional>> doAsyncWriteMessages(Iterable<
> AtomicWrite> messages);
>
> whose Java docs can be found here:
>  
> http://doc.akka.io/docs/akka/snapshot/java/persistence.html#Journal_plugin_API
> <http://doc.akka.io/docs/akka/snapshot/java/persistence.html#Journal_plugin_API>
>
>
> Specifically this line : "If there are failures when storing any of the
> messages in the batch the returned `Future` must be completed with
> failure."
>
> and this section: "The journal can also signal that it rejects individual
> messages(`AtomicWrite`) by the returned
> `IterableOptionalException`. The returned `Iterable` must
> have as many elements as the input `messages` `Iterable`. Each `Optional`
> element signals if the corresponding `AtomicWrite` is rejected or not, with an
> exception describing
> the problem. Rejecting a message means it was not stored, i.e. it must
> not be included in a later replay. Rejecting a message is typically done
> before attempting to store it,
> e.g. because of serializat

Re: [akka-user] Re: What's the replacement for Akka Actor Publisher and Subscriber?

[Patrik Nordwall]

In addition to what has already been said there will be a few more options:

   - Gearpump <http://gearpump.incubator.apache.org/overview.html> is
   implementing distributed streaming with Akka Streams
   - We will evaluate if it's suitable to make an Akka Streams API on top
   of ReactiveSocket <http://reactivesocket.io/>

Regards,
Patrik


On Tue, Oct 11, 2016 at 10:52 PM, Rafał Krzewski <rafal.krzew...@gmail.com>
wrote:

> You can use Akka HTTP with WebSockets for streaming data over a network
> link between nodes. This way you could attach a reactive stream in one node
> with a remote reactive stream, preserving backpressure semantics.
> If you are concerned with the overhead, you could use
> akka.streams.scaladsl.Tcp to stream data over a raw TCP socket, but of
> course you'd need to work out your custom protocol details.
> This may look like a lot of work, but that's just another example of Akka
> being honest with you: network is unreliable in general, and "exactly once"
> semantics of message delivery come at a cost.
>
> Cheers,
> Rafał
>
> W dniu wtorek, 11 października 2016 21:08:03 UTC+2 użytkownik Justin du
> coeur napisał:
>>
>> One of the team will have to answer this -- AFAIK, streams just plain
>> don't work cross-node yet.  (Which is why I'm not using them myself yet.)
>>
>> On Mon, Oct 10, 2016 at 7:27 PM, Dagny T <dagnyt...@gmail.com> wrote:
>>
>>>
>>> Right; can you provide a Blog URL or something to explain further?
>>>
>>> What is the recommended architecture when you want to stream data
>>> between remote Actor-based services?
>>> i.e. the implementations of Actor Publisher/Subscriber which actually
>>> work across remote boundaries
>>> (location transparency, I thought was the whole point of Akka's
>>> awesomeness).
>>>
>>> Thanks in advance!
>>> D
>>>
>>> On Monday, September 26, 2016 at 12:07:55 AM UTC-7, Dagny T wrote:
>>>>
>>>> Hi there,
>>>>
>>>> The latest info I have from a prior Akka Team response was that the
>>>> Akka Actor Publisher/Subscriber APIs are now deprecated;
>>>> and one should be looking at the Graph DSL instead.
>>>>
>>>> i.e. Latest Akka Docs state:
>>>> ActorPublisher and ActorSubscriber
>>>>  cannot be used with remote actors,
>>>> because if signals of the Reactive Streams protocol (e.g. request) are
>>>> lost the the stream may deadlock.
>>>>
>>>> So, now I'm not clear on what the replacement APIs we're supposed to be
>>>> using; as far as connecting State-Holding Akka Actors to Graph DSL
>>>> Event-Streams.
>>>>
>>>> Is there an Akka Team Blog with a GitHub link to a small focused
>>>> example which demonstrates this?
>>>>
>>>> THANKS in advance for any help with finding the latest APIs to use for
>>>> this!
>>>> Dagny
>>>>
>>>>
>>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou
>>> p/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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Re: Journal Plugin Java API question regarding doAsyncWriteMessages

[Patrik Nordwall]

On Tue, Oct 11, 2016 at 3:55 PM, Ian Grima <iangr...@gmail.com> wrote:

> Thanks for your reply :). If I were not to support rejections, that would
> imply that if a serialization error occurs i would simply fail the entire
> Future correct?
>

yes, right


> Gapless sequence numbers does indeed sound like a worthy consideration.
>
> Thanks Again,
> Ian Grima
>
> On Tuesday, 11 October 2016 12:21:38 UTC+2, Patrik Nordwall wrote:
>>
>>
>>
>> On Tue, Oct 11, 2016 at 11:24 AM, Ian Grima <iang...@gmail.com> wrote:
>>
>>> I am still looking for an opinion on this matter if anyone could help :)
>>>
>>>
>>>
>>> On Saturday, 8 October 2016 15:31:32 UTC+2, Ian Grima wrote:
>>>>
>>>> Hi,
>>>>
>>>>   I was reading up on the API of implementing a custom journal plugin
>>>> in Java. Could you please tell me if I have understood this section
>>>> correctly.
>>>>
>>>> With regards to the following API:
>>>>
>>>>  Future<Iterable<Optional>> doAsyncWriteMessages(Iterable<
>>>> AtomicWrite> messages);
>>>>
>>>> whose Java docs can be found here: http://doc.akka.io/docs/
>>>> akka/snapshot/java/persistence.html#Journal_plugin_API
>>>> <http://doc.akka.io/docs/akka/snapshot/java/persistence.html#Journal_plugin_API>
>>>>
>>>>
>>>> Specifically this line : "If there are failures when storing any of
>>>> the messages in the batch the returned `Future` must be completed with
>>>> failure."
>>>>
>>>> and this section: "The journal can also signal that it rejects
>>>> individual messages(`AtomicWrite`) by the returned
>>>> `IterableOptionalException`. The returned `Iterable`
>>>> must
>>>> have as many elements as the input `messages` `Iterable`. Each
>>>> `Optional` element signals if the corresponding `AtomicWrite` is
>>>> rejected or not, with an exception describing
>>>> the problem. Rejecting a message means it was not stored, i.e. it must
>>>> not be included in a later replay. Rejecting a message is typically
>>>> done before attempting to store it,
>>>> e.g. because of serialization error."
>>>>
>>>>
>>>> I had difficulty understanding how it would be possible to reject an
>>>> individual atomic write when the first line states that the future must be
>>>> completed with failure if storing a single message fails.
>>>>
>>>
>> Rejections are not failure to store them, but it can be seen as a
>> validation error, i.e. something that is performed before the database is
>> involved, e.g. serialization error.
>>
>>
>>> Returning the Iterable<Optional>> result would imply that
>>>> the future would have to be completed successfully. If I ended up
>>>> implementing it in this manner would it be correct? :
>>>>
>>>> - Iterate over all messages validating and serializing each one, during
>>>> this process I would be building an Iterable<Optional>> with
>>>> an Optional.empty for each successfully validated
>>>> and serialized message and an Optional containing an exception if one
>>>> of the messages fails validation and serialization.
>>>>
>>>> - I would then attempt to persist the successfully serialized batch of
>>>> messages in a single shot (given it is more optimal to do it in batch for
>>>> my data store).
>>>> - If the persist succeed i would complete the future successfully by
>>>> returning the previously constructed Iterable<Optional>> 
>>>> containing
>>>> possible rejections.
>>>>
>>>> - If the persist fails i would simply fail the future with an exception
>>>> indicating why the persist for the entire set of AtomicWrites failed. We
>>>> would be loosing information with regards to if any of the
>>>> AtomicWrites were rejected but I imagine this is somewhat irrelevant
>>>> since none of them got persisted anyway.
>>>>
>>>>
>> That looks correct.
>>
>> You can also consider to not support rejections at all. It's an optional
>> feature, and many of the existing implementations doesn't support it.
>> Rejections will result in gaps in the sequence numbers. Gapless sequence
>> numbers is a very nice feature, much more importan

Re: [akka-user] Re: Journal Plugin Java API question regarding doAsyncWriteMessages

[Patrik Nordwall]

On Tue, Oct 11, 2016 at 11:24 AM, Ian Grima <iangr...@gmail.com> wrote:

> I am still looking for an opinion on this matter if anyone could help :)
>
>
>
> On Saturday, 8 October 2016 15:31:32 UTC+2, Ian Grima wrote:
>>
>> Hi,
>>
>>   I was reading up on the API of implementing a custom journal plugin in
>> Java. Could you please tell me if I have understood this section correctly.
>>
>> With regards to the following API:
>>
>>  Future<Iterable<Optional>> doAsyncWriteMessages(Iterable<
>> AtomicWrite> messages);
>>
>> whose Java docs can be found here: http://doc.akka.io/docs/
>> akka/snapshot/java/persistence.html#Journal_plugin_API
>> <http://doc.akka.io/docs/akka/snapshot/java/persistence.html#Journal_plugin_API>
>>
>>
>> Specifically this line : "If there are failures when storing any of the
>> messages in the batch the returned `Future` must be completed with
>> failure."
>>
>> and this section: "The journal can also signal that it rejects
>> individual messages(`AtomicWrite`) by the returned
>> `IterableOptionalException`. The returned `Iterable` must
>> have as many elements as the input `messages` `Iterable`. Each `Optional`
>> element signals if the corresponding `AtomicWrite` is rejected or not, with 
>> an
>> exception describing
>> the problem. Rejecting a message means it was not stored, i.e. it must
>> not be included in a later replay. Rejecting a message is typically done
>> before attempting to store it,
>> e.g. because of serialization error."
>>
>>
>> I had difficulty understanding how it would be possible to reject an
>> individual atomic write when the first line states that the future must be
>> completed with failure if storing a single message fails.
>>
>
Rejections are not failure to store them, but it can be seen as a
validation error, i.e. something that is performed before the database is
involved, e.g. serialization error.


> Returning the Iterable<Optional>> result would imply that the
>> future would have to be completed successfully. If I ended up implementing
>> it in this manner would it be correct? :
>>
>> - Iterate over all messages validating and serializing each one, during
>> this process I would be building an Iterable<Optional>> with
>> an Optional.empty for each successfully validated
>> and serialized message and an Optional containing an exception if one of
>> the messages fails validation and serialization.
>>
>> - I would then attempt to persist the successfully serialized batch of
>> messages in a single shot (given it is more optimal to do it in batch for
>> my data store).
>> - If the persist succeed i would complete the future successfully by
>> returning the previously constructed Iterable<Optional>> 
>> containing
>> possible rejections.
>>
>> - If the persist fails i would simply fail the future with an exception
>> indicating why the persist for the entire set of AtomicWrites failed. We
>> would be loosing information with regards to if any of the
>> AtomicWrites were rejected but I imagine this is somewhat irrelevant
>> since none of them got persisted anyway.
>>
>>
That looks correct.

You can also consider to not support rejections at all. It's an optional
feature, and many of the existing implementations doesn't support it.
Rejections will result in gaps in the sequence numbers. Gapless sequence
numbers is a very nice feature, much more important than rejections in my
opinion.

/Patrik


>
>> Thanks,
>> Ian Grima
>>
>>
>>
>>
>>
>> --
> >>>>>>>>>> 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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Ask or Tell ?

[Patrik Nordwall]

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



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Re: Cluster inconsistency when using AWS EC2 autoscale groups ('No route to host' not triggering unreachable state)

[Patrik Nordwall]

It is expected that it detects crashed/stopped nodes as unreachable. When
unreachable have been downed and removed the cluster canmove joining nodes
to Up. I'm not sure I understand the question/problem.

Also, don't change heartbeat-interval. That will not make anything better.
acceptable-heartbeat-pause is what you should increase if needed.

/Patrik

tis 27 sep. 2016 kl. 15:24 skrev :

> i also redefined values in failure detector
>
>> failure-detector {
>>   threshold = 16
>>   acceptable-heartbeat-pause = 10s
>>   heartbeat-interval = 3s
>>   #expected-response-after = 20s #this means time for receiving first
>> gossip from anyone or node will be detected as broken
>> https://groups.google.com/forum/#!topic/akka-user/2JKtDw7dcJs
>> }#failure-detector
>>
> --
> >> 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: Message not delivered log entry, after log entry of message having been delivered?

[Patrik Nordwall]

You use noSender in ActorA when sending START. Use self instead.
/Patrik
tors 29 sep. 2016 kl. 19:20 skrev :

> On Wednesday, September 28, 2016 at 1:55:42 PM UTC-7, que...@gmail.com
> wrote:
>>
>> I have one actor that sends a message to another actor. There is a
>> message logged that the message is sent and a message logged that it was
>> received, then later there is a message saying that the message could not
>> be delivered. Is this normal?
>>
>> Essentially, I have (java):
>>
>> ActorRef actorB = system.actorOf(Props.create(ActorB.class), "actorb");
>> ActorRef actorA = system.actorOf(Props.create(ActorA.class, actorB),
>> "actora");
>>
>> actorA.tell(START, ActorRef.noSender());
>>
>>
>> ActorA's receive method:
>>
>> ReceiveBuilder.matchEquals(START, ignored -> actorBRef.tell(START, self
>> ()))
>> .matchEquals(STOP, ignored -> context().system().
>> terminate())
>> .build();
>>
>>
>> ActorB's receive method:
>>
>> ReceiveBuilder.matchEquals(START, ignored -> {
>> // do stuff
>> sender().tell(STOP, self());
>> context().stop(self());
>>  })
>> .build();
>>
>>
>> The log shows ActorA sent START to ActorB, ActorB received START and sent
>> STOP to ActorA. Then later the dispatcher logs a message that ActorA's
>> START message was not delivered to ActorB.
>>
>> Is ActorB supposed to do something to indicate to the dispatcher that it
>> received the message? I am guessing it has to do ActorB teliing itself to
>> stop. Or, why is complaining about a message not being sent after it was
>> sent and received?
>>
>
> My guess is that this is normal. I changed my code so that it sends a
> message that it is done without stopping itself, then when it receives a
> message to stop itself it stops without also sending a message. So, there
> is no longer a message from the actor, in transit (maybe), while it is
> stopping itself.
>
> I would still like to understand how the dispatcher saw a message as
> undelivered after it had been received.
>
> --
> >> 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] Successor Technology to Microkernal

[Patrik Nordwall]

You find most of the answers here:
http://doc.akka.io/docs/akka/2.4/intro/deployment-scenarios.html

It will be removed in Akka 2.5, unkown release date.

/Patrik
tors 29 sep. 2016 kl. 22:18 skrev Joseph Mansigian <
joseph.c.mansig...@gmail.com>:

>
> I read that the Microkernal was going away.  Would you tell me, if you can:
>
> - The name of the successor technology.
> - A link to doc on it
> - Will new technology be able to put anything found in Akka with Scala in
> one package?
> - Any idea when it will roll out?
> - When will Microkernal be removed?
>
> 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 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] Control how much cpu are used by the actor system?

[Patrik Nordwall]

On Linux you can use taskset to pin the jmv process to specific cores.
fre 30 sep. 2016 kl. 19:56 skrev Konrad Malawski <
konrad.malaw...@lightbend.com>:

> That's what containers are for though.
> Run your jvm in a container and restrict resources available to that one
>
> On 30 Sep 2016 19:48, "Roland Kuhn"  wrote:
>
>> Hi Jean-François,
>>
>> the JVM does not offer the functionality you seek, you'll have to use
>> your operating system’s capabilities to restrict the resources available to
>> the JVM itself.
>>
>> Regards, Roland
>>
>> Sent from my iPhone
>>
>> On 30 Sep 2016, at 18:29, Jean-François Côté 
>> wrote:
>>
>> Hi guys!
>>
>> Is there any way to control how much cpu the akka system use over the
>> total of cpu available in the JVM? For example, I would want all my actor
>> system to only use 75% of the processing power available so that 2 of my 8
>> core is available for other system on the server. I've checked dispatcher,
>> router, etc but nothing seems to control this kind of thing. But maybe I
>> missed something.
>>
>> Thanks!
>> J-F
>>
>> --
>> >> 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.
>>
> --
> >> 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.

[akka-user] Akka HTTP / Spray: Directory Traversal Vulnerability Announcement

[Patrik Nordwall]

Dear users of Akka HTTP and Spray,

We have just released akka-http 2.4.11 and spray 1.3.4 with a critical
security update for users running akka-http servers on Windows. We were
notified (akka/akka-http#346 <https://github.com/akka/akka-http/issues/346>)
that on Windows akka-http’s `getFromDirectory`, `getFromBrowseableDirectory`,
`getFromBrowseableDirectories`, and `listDirectoryContents` directives
unintentionally allow access to directories and files outside of the
specified directory. All directories and files on the same drive as the
specified directory for which the server process has sufficient permissions may
be downloaded or browsed. This can be easily exploited by using a specially
crafted URI. For example, such specially crafted request
http://localhost:8080/%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5cwindows/win.ini
when handles by one of the affected directives, could expose your win.ini
(and potentially any other file) to the attacker.

Please update to the latest version of akka-http as soon as possible.

Affected configurations:

   -

   OS: Windows
   -

   Modules
   -

  akka-http-experimental prior to 2.4.11
  -

  spray-routing and spray-routing-shapeless2 prior to 1.3.4
  -

   Affected directives:
   -

  getFromDirectory
  -

  getFromBrowseableDirectory
  -

  getFromBrowseableDirectories
  -

  listDirectoryContents


Fixed versions:

   -

   akka-http-experimental 2.4.11
   -

   akka-http-experimental 2.0.5
   -

   spray 1.3.4


Following best security practices it is furthermore recommended to run the
web server process with user credentials with as few permissions as
possible to prevent unintended file access.  Furthermore, we suggest using
Linux servers and/or containers for hosting Akka HTTP applications, as
these OSes receive more scrutiny than any other OS just because of the
overwhelming number of installations running on Linux.

Please note that we have also updated Spray 1.3, even though it is slowly
reaching it’s end of life, and will be deprecated with the upcoming (very
soon) stable release of Akka HTTP. Please update to the latest version of
Spray if you are using it, and be prepared to move onwards to Akka HTTP
soon.

Many thanks go to @roikonen for reporting the problem, @2beaucoup for
providing a fix and @rbudzko and @jypma for providing advice for fixing the
problem.


-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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.

[akka-user] ANNOUNCE: Akka 2.4.11 - Including New Remoting

[Patrik Nordwall]

Dear hakkers,

We are proud to announce the release of Akka 2.4.11, which includes the new
experimental Akka Remoting, codenamed Artery.

Some noteworthy changes in the 2.4.11 release are:


   -

   New remoting, see below
   -

   Progress of Akka Typed, see below
   -

   Fixed an issue where in some cases cancel or failure events was dropped
   in Streams leading to potential deadlock #21446
   <https://github.com/akka/akka/issues/21446>

New Remoting

Artery is a reimplementation of the old remoting module aimed at improving
performance and stability. It is mostly source compatible with the old
implementation and it is a drop-in replacement in many cases. Main features
of Artery compared to the previous implementation:


   -

   Based on Aeron <https://github.com/real-logic/Aeron> (UDP) instead of TCP
   -

   Focused on high-throughput, low-latency communication, mostly
   allocation-free operation
   -

   Isolation of internal control messages from user messages improving
   stability and reducing false failure detection in case of heavy traffic by
   using a dedicated subchannel.
   -

   Support for a separate subchannel for large messages to avoid
   interference with smaller messages
   -

   Compression of actor paths on the wire to reduce overhead for smaller
   messages
   -

   Support for faster serialization/deserialization using ByteBuffers
   directly
   -

   Built-in Flight-Recorder to help debugging implementation issues without
   polluting users logs with implementation specific events
   -

   Providing protocol stability across major Akka versions to support
   rolling updates of large-scale systems



The new remoting is enabled with configuration:

akka.remote.artery {

 enabled = on

 # The hostname or ip clients should connect to.

 canonical.hostname = localhost

 # use 0 if you want a random available port

 canonical.port = 25520

}

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

Please read the documentation for Scala
<http://doc.akka.io/docs/akka/2.4/scala/remoting-artery.html> or Java
<http://doc.akka.io/docs/akka/2.4/java/remoting-artery.html> for more
details.

The full list of changes since the last milestone is available under the
2.4.11-ARTERY <https://github.com/akka/akka/milestone/97?closed=1>
milestone on github for your reference.
Akka Typed

This release brings some significant changes to the Akka Typed module:

   -

   a completely new implementation <https://github.com/akka/akka/pull/21128>
   that has 20–30% less message-passing overhead even though it has not yet
   been fully optimized—the goal is to allow zero-allocation messaging once we
   have all the pieces in place
   -

   a few semantic simplifications, most of which have little to no impact
   on what can be expressed by user code but which tremendously simplify the
   internal implementation, see the discussion on akka-meta
   <https://github.com/akka/akka-meta/issues/18>, the summary of the
differences
   in the Actor lifecycle <https://github.com/akka/akka-meta/issues/21>,
   and the notes on co-existence of typed and untyped Actors
   <https://github.com/akka/akka-meta/issues/26>
   -

   the removal of Props <https://github.com/akka/akka/issues/21597> which
   now do not serve enough purpose anymore to warrant all those extra
   allocations

All these changes are contributed by Actyx <https://actyx.io/>, the company
Roland Kuhn co-founded recently. Actyx is interested in pushing Akka Typed
forward as an open-source base technology for the implementation of cloud
services for the manufacturing industry.
Credits

A total 46 issues were closed since 2.4.10 (New remoting not counted).

The complete list of closed issues can be found on the 2.4.11
<https://github.com/akka/akka/milestone/96?closed=1> and 2.4.11-ARTERY
<https://github.com/akka/akka/milestone/97?closed=1> milestones on github.

For this release we had the help of 19 committers – thank you!

A special thanks to Łukasz Dubiel <https://github.com/bambuchaAdm> who
contributed to Artery and Roland Kuhn <https://github.com/rkuhn> who
contributed to Akka Typed.

Credits:
commits added removed

 142   224456850 Patrik Nordwall

  232573 Johan Andrén

  20   11067 807 Endre Sándor Varga

  1149781651 Konrad Malawski

   6 828 202 Johan Andrén

   56740  90 Johannes Rudolph

   41441 361 Martynas Mickevičius

   31139   4 Richard Imaoka

   350901174 Roland Kuhn

   2 341 276 Łukasz Dubiel

   2  96  15 gosubpl

   1  12   4 drewhk

   1  37  13 monkey-mas

   1  22  22 Michał Płachta

   1  10   7 Richard S. Imaoka

   1  12   4 Jeroen Gordijn

   1   1   1 KAWACHI Takashi

   1   9   1 Mat

Re: [akka-user] how to set an node to seed please?

[Patrik Nordwall]

There is the API cluster.joinSeedNodes if you don't want to use config. See
docs for details.

/Patrik
lör 24 sep. 2016 kl. 11:43 skrev :

> If all nodes in cluster is normal node, none is seed.
> How to set one of nodes as seed please?
> I can't do this, no new node can join the cluster.
>
> 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 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] Merging more than two Akka Stream Sources with materialized values

[Patrik Nordwall]

Take a look at MergeHub. It's rather new.
http://doc.akka.io/docs/akka/2.4/scala/stream/stream-dynamic.html

/Patrik
lör 24 sep. 2016 kl. 00:53 skrev oleksiys :

> Hi guys,
>
> I need to merge mutliple sources Seq[Source[A, Mat]] and as an output get
> something like Source[A, Seq[Mat]].
> For now I just merge sources in pairs using mergeMat, but I have a doubt
> that the merged Source will distribute the demand fairly among the
> underlying sources, because AFAIK my merged source will finally look like:
> (source-1, (source-2, (source-3 ... (source-N-1, source-N)... and
> assuming random demand distribution - the larger the N is - less chances
> that source-N will ever see any demand. Is that correct?
>
> There is a Source.combine method, that does almost exactly what I need,
> but unfortunately it wipes all the Mats information.
>
> Do you have any suggestion how I can achieve that?
>
> Thank you!
>
> WBR,
> Alexey
>
> --
> >> 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] Creating multiple instances of ActorSystem

[Patrik Nordwall]

It's fine to create more than one in the same jvm. It can be useful for
tests. Be careful to not pass ActorRef instances in a way that would not be
possible if the ActorSystems were in different jvms. Only pass them with
messages. Locate them initially with actorSelection.

/Patrik
ons 21 sep. 2016 kl. 16:36 skrev Justin du coeur :

> On Wed, Sep 21, 2016 at 10:24 AM, Mark Kaberman 
> wrote:
>
>> I am wondering if it is possible to create multiple instances of
>> ActorSystem within a single JVM?
>>
>
> Possible, yes, but it's rarely a good idea -- ActorSystems are very
> heavyweight, and there are almost no conventional circumstances where it is
> appropriate to do so.  I don't know offhand whether creating multiple
> ActorSystems with the same name is safe; it certainly seems likely to cause
> conflicts, especially if you have any remoting 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.
>

-- 
>>  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] out-of-the-box support for json serialization for akka persistence?

[Patrik Nordwall]

For Lagom I wrote json serializer that is using Jackson. You can look at it
for inspiration. It's stored in Cassandra as bytes, but how it's stored is
less important as far as I can see.

/Patrik
ons 21 sep. 2016 kl. 17:58 skrev Tim Pigden :

> Hi Justin
> Thanks for the comments. However, as I said I have decided that I do want
> to use json asa format, so I'm really looking to see who has direct
> experience of that.
> The serialization format is less orthogonal that you might expect, given
> that the database table layouts are all part of the plugin and as far as I
> can see, all use blob rather than json format with no obvious way to change
> that.
> And yes the json-ness does make a difference to me. Without going into
> elaborate CQRS "Q" coding, it will enable the developers to find out about
> how the system is being used, what sort of messages are being created with
> what payloads, through simple sql. My increased data volumes are extremely
> unlikely to burden a single server db in the short to medium term.
>
> Tim
>
>
> On Wednesday, September 21, 2016 at 2:58:27 PM UTC+1, Justin du coeur
> wrote:
>
>> A few general reactions (personally, I'm using Kryo over Cassandra, so I
>> can't address the direct questions):
>>
>> Keep in mind that json is a relatively bulky serialization format -- it's
>> going to take rather more disk space than more typical options like
>> protobuf.
>>
>> In *general*, the serialization format and database are pretty orthogonal
>> concerns.  It's possible that json might have specific advantages when used
>> with a json-native DB like Mongo, but AFAICT the Cassandra driver is the
>> most mature in general.  Are you planning on using the json-ness in some
>> particular way?
>>
>> Finally, remember that json doesn't save you from all the complications
>> of schema evolution: you're still going to need to think about how you deal
>> with missing fields, name changes, and stuff like that.  It's probably a
>> bit easier than Kryo, but only a bit.  Schema evolution is a real bear --
>> making sure I can deal with it took most of my effort in getting
>> Persistence up and running...
>>
> On Wed, Sep 21, 2016 at 9:16 AM, Tim Pigden  wrote:
>>
> Hi
>>> Reading
>>>
>>> http://doc.akka.io/docs/akka/2.4.10/scala/persistence-schema-evolution.html
>>>
>>> and thinking about what we currently do, I've concluded that I'd like to
>>> serialize my events as json.
>>> The article suggests I should check the list of plugins to see which
>>> specifically support json. But I can't find clear indications that any of
>>> them do from the respective github pages (apologies if I've missed
>>> something). Most seem to want the target database tables to be a BLOB with
>>> no option of a native json type.
>>>
>>> My current database target is Postgres (because we use postgis for
>>> mapping and because I need a proper sql database for data warehouse).
>>> However, for the event serialization I could certainly contemplate
>>> something else if it made the current development path quicker and easier.
>>> MongoDB or Cassandra are obvious possible targets.
>>>
>>> So my question is: is anyone actually using json as a serialization
>>> format, and if so
>>> a) what database and driver?
>>> b) is the database-native json support being used (if any?)
>>> c) how much effort was it? I can already serialize everthing to json
>>> that needs to go in the persistence journal or snapshots.
>>>
>>> it's got to be something with active support/interest.
>>>
>>> Thanks
>>> tim
>>>
>> --
>>> >> 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: 

Re: [akka-user] On cluster node failure is there an automatic way to recover cluster shard persistent actors in the failed node to other node?

[Patrik Nordwall]

Automatic startup on other node is how it is supposed to work, and we have
tests for it. How do you down the dead node?

/Patrik
mån 19 sep. 2016 kl. 22:00 skrev Ajmal Babu :

> Working on AKKA persistence with cluster sharding and the flag
> akka.cluster.sharding.remember-entities set to "on". For some reason when
> one of the node dies in the cluster the entities in that node does not get
> automatically restarted in the other available nodes in the cluster. Is
> that the expected behavior? Is there an automatic recover-ability on node
> failure to move actors to another node, for such feature what is the right
> way to implement?
>
> --
> >> 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] Cluster Sharding with remember-entity restarting a stopped actor

[Patrik Nordwall]

You need to use the `Passivate` message.
http://doc.akka.io/docs/akka/2.4/java/cluster-sharding.html#Remembering_Entities

Also, make sure that you don't call context.stop from any other thread than
the actor's message receive.

/Patrik

On Sun, Sep 18, 2016 at 11:52 PM, Ajmal Babu <ajmalb...@gmail.com> wrote:

> We are using AKKA 2.4.10 persistent actor, cluster sharding with Cassandra
> storage and have enabled remember-entity = true. We need to stop certain
> persistent actor after a specific time-frame. (few days). The issue is that
> the actor once stopped gets automatically restarted after 10 seconds. But
> if remember-entity is set to false it does not restart. The actor stop is
> tried out (a) from another persistent actor or (b) from the same persistent
> actor with a scheduled future event to stop itself. Both cases automatic
> restart happens.
>
> We are using Spring with AKKA. Interestingly if the persistence actor stop
> is performed from direct spring code for e.g. on a rest end point (not from
> an actor code) persistent actor does not get automatically restarted
> irrespective of the above flag remember-entity = true or false. Can you
> please provide solution for this,
>
> --
> >>>>>>>>>> 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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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 Multithreading on Akka-Cluster

[Patrik Nordwall]

The Artery config is not correct, see release announcement for M4

/Patr
ons 14 sep. 2016 kl. 14:12 skrev Guido Medina :

> Hi Silvio,
>
> The following are the only things I can recommend you:
>
>- You have a short time to deliver? Why bother now with Artery if
>that's the least of your problems? Your performance issue has nothing to do
>with Akka Cluster or Akka Remote.
>- Why use a future? Your future is probably running at the default
>dispatcher hence you are blocking at the wrong place !!!
>- Why don't you just dedicate a dispatcher for your worker actors and
>just do your blocking call there with no future, a standard synchronous
>call, in the worst scenarios messages will just accumulate at your workers
>which is OK, you can set some expire time to not deal with then if they
>have expired but please keep it simple, make it work at a decent speed and
>then make it fast.
>
> Try that and it should improve your performance, before you try more
> complex scenarios please read the Akka documentation or you will be slowing
> things rather than making them faster, start simple then add to it.
>
> HTH,
>
> Guido.
>
> --
> >> 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] Cluster seed nodes resulting in multiple split brains?

[Patrik Nordwall]

How do you then handle node crashes and other unexpected failures?

It's right that we strongly recommend against auto-down, but you must still
use something. I hope that is not completely unclear in the documentation:
http://doc.akka.io/docs/akka/2.4/scala/cluster-usage.html#Downing

On Mon, Sep 12, 2016 at 6:06 PM, kraythe <kray...@gmail.com> wrote:

> All I do is issue a Cluster.get(system).leave(cluster.selfAddress)
>
> On Monday, September 12, 2016 at 9:49:22 AM UTC-5, √ wrote:
>>
>> What are you using/doing for downing?
>>
>> On Mon, Sep 12, 2016 at 4:13 PM, kraythe <kra...@gmail.com> wrote:
>>
>>> No, we have disabled that as per suggestion in the docs. Should we?
>>>
>>> --
>>> >>>>>>>>>>  Read the docs: http://akka.io/docs/
>>> >>>>>>>>>>  Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >>>>>>>>>>  Search the archives: https://groups.google.com/grou
>>> p/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.
>>>
>>
>>
>>
>> --
>> 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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Cluster seed nodes resulting in multiple split brains?

[Patrik Nordwall]

You asked for links

http://doc.akka.io/docs/akka/2.4/scala/cluster-usage.html#Joining_to_Seed_Nodes

http://doc.akka.io/docs/akka/2.4/scala/cluster-usage.html#Downing

https://conductr.lightbend.com/docs/1.1.x/Home
lör 10 sep. 2016 kl. 19:27 skrev Viktor Klang <viktor.kl...@gmail.com>:

> ConductR* is designed to properly seed, and update, Akka Cluster based
> applications, and the Akka Split Brain Resolver provides deterministic
> partition handling.
>
> ConductR runs well on EC2:
> https://conductr.lightbend.com/docs/1.0.x/Install#EC2-Installation
>
> * ConductR and SBR are Lightbend products
>
> --
> Cheers,
> √
>
> On Sep 10, 2016 6:46 PM, "kraythe" <kray...@gmail.com> wrote:
>
>> I am not following you on this one. Is there a blog post or article you
>> can reference me to ?
>>
>> Thanks to you both.
>>
>> On Saturday, September 10, 2016 at 11:34:26 AM UTC-5, √ wrote:
>>>
>>> There's also ConductR + SBR
>>>
>>> --
>>> Cheers,
>>> √
>>>
>>> On Sep 10, 2016 5:09 PM, "Patrik Nordwall" <patrik@gmail.com> wrote:
>>>
>>>> Are you aware of the importance of the first seed node, the one you
>>>> have listed as first element in sees-nodes list? See documentation.
>>>>
>>>> You can get decent behavior if you wait with joining until the list of
>>>> discovered nodes stabilize, i.e. not changing within X seconds. Then sort
>>>> them to make sure the same is used as the first from all places. Then
>>>> joinSeedNodes with that sorted list.
>>>>
>>>> To be completely safe you must manually decide which one to use as the
>>>> first seed node.
>>>>
>>>> /Patrik
>>>>
>>>> fre 9 sep. 2016 kl. 20:32 skrev kraythe <kra...@gmail.com>:
>>>>
>>>>> Greetings,
>>>>>
>>>>> We are having some problems with our cluster configuration that
>>>>> manifest themselves in the following log lines (redacted for
>>>>> confidentiality reasons.
>>>>>
>>>>> Sep 09 00:58:10 host1.mycompany.com application-9001.log:  2016-09-09
>>>>> 05:58:10 + - [WARN] - [OrdersActor] 
>>>>> akka://myCompany/user/OrdersActor/291
>>>>> -  (291) #recordTxns, sending 54 txns to UserActor took 0.0044229 seconds
>>>>> Sep 09 00:58:19 host1.mycompany.com application-9001.log:  2016-09-09
>>>>> 05:58:19 + - [WARN] - [ShardRegion] akka.tcp://
>>>>> myCompany@10.8.1.169:2551/system/sharding/UserActor -  Trying to
>>>>> register to coordinator at [None], but no acknowledgement. Total [54]
>>>>> buffered messages.
>>>>>
>>>>> I have traced this to the configuration of the cluster. We are running
>>>>> this on Amazon AWS and the code includes use of Hazelcast for finding the
>>>>> IPs of the other nodes (mostly because we have solved discovery for
>>>>> hazelcast in our dynamic IP cluster). We retrieve the IPs of the other
>>>>> nodes in the cluster from hazelcast and appropriately use them to create
>>>>> the Address object to use in the seed node. Once we have the seed nodes we
>>>>> have tried two mechanisms. First is to take the list of seed nodes and use
>>>>> them to join the cluster with cluster.joinSeedNodes(). Of Course not
>>>>> all machines come up and are discovered by hazelcast at exactly the same
>>>>> instant so the first 3 nodes might come up first and use each other to 
>>>>> join
>>>>> whereas by the time the 9th node comes up there are 9 seed nodes. When we
>>>>> start sending messages to cluster shared actors, we get the errors above.
>>>>> Also when a node goes down the system screams constantly that a seed node
>>>>> is gone. So I changed the code to pick a node at random and do a
>>>>> cluster.join() with that node instead. However, we have the same
>>>>> problem as above. However, when we first bring up one node then bring them
>>>>> up one at a time, the problem goes away. Another symptom is that if we 
>>>>> have
>>>>> the problem above and we terminate host1 then other nodes start 
>>>>> propagating
>>>>> this behavior. Probably all the other nodes that were connected to host1.
>>>>> Apparently they can't heal to connect to another node. So this lends
>>>>> e

Re: [akka-user] Cluster seed nodes resulting in multiple split brains?

[Patrik Nordwall]

Are you aware of the importance of the first seed node, the one you have
listed as first element in sees-nodes list? See documentation.

You can get decent behavior if you wait with joining until the list of
discovered nodes stabilize, i.e. not changing within X seconds. Then sort
them to make sure the same is used as the first from all places. Then
joinSeedNodes with that sorted list.

To be completely safe you must manually decide which one to use as the
first seed node.

/Patrik

fre 9 sep. 2016 kl. 20:32 skrev kraythe :

> Greetings,
>
> We are having some problems with our cluster configuration that manifest
> themselves in the following log lines (redacted for confidentiality
> reasons.
>
> Sep 09 00:58:10 host1.mycompany.com application-9001.log:  2016-09-09 05:
> 58:10 + - [WARN] - [OrdersActor] akka://myCompany/user/OrdersActor/291
> -  (291) #recordTxns, sending 54 txns to UserActor took 0.0044229 seconds
> Sep 09 00:58:19 host1.mycompany.com application-9001.log:  2016-09-09 05:
> 58:19 + - [WARN] - [ShardRegion] akka.tcp://
> myCompany@10.8.1.169:2551/system/sharding/UserActor -  Trying to register
> to coordinator at [None], but no acknowledgement. Total [54] buffered
> messages.
>
> I have traced this to the configuration of the cluster. We are running
> this on Amazon AWS and the code includes use of Hazelcast for finding the
> IPs of the other nodes (mostly because we have solved discovery for
> hazelcast in our dynamic IP cluster). We retrieve the IPs of the other
> nodes in the cluster from hazelcast and appropriately use them to create
> the Address object to use in the seed node. Once we have the seed nodes we
> have tried two mechanisms. First is to take the list of seed nodes and use
> them to join the cluster with cluster.joinSeedNodes(). Of Course not all
> machines come up and are discovered by hazelcast at exactly the same
> instant so the first 3 nodes might come up first and use each other to join
> whereas by the time the 9th node comes up there are 9 seed nodes. When we
> start sending messages to cluster shared actors, we get the errors above.
> Also when a node goes down the system screams constantly that a seed node
> is gone. So I changed the code to pick a node at random and do a
> cluster.join() with that node instead. However, we have the same problem
> as above. However, when we first bring up one node then bring them up one
> at a time, the problem goes away. Another symptom is that if we have the
> problem above and we terminate host1 then other nodes start propagating
> this behavior. Probably all the other nodes that were connected to host1.
> Apparently they can't heal to connect to another node. So this lends
> evidence to the multiple split brains theory.
>
> My theory is that by using all these seed nodes I am creating multiple
> split brains. So if you have 5 nodes, A, B, C, D, E and A connects to B, B
> to A, C to E, E to D, D to E then we have two clusters running that know
> nothing about each other. For some reason then the coordinators get
> confused about what is going on.
>
> Essentially the problem domain is this: 1. We don't know what ANY of the
> IPs are ahead of time. 2) We want the cluster to be whole. 3) If a single
> node leaves the cluster we would like the remaining nodes to recover.
>
> I would appreciate any insight anyone could provide on this and especially
> what may be the problem (I could be wrong), and how we can accomplish our
> goals. Note that I am not committed to using hazelcast to find other nodes.
>
>  Thanks in advance.
>
>
> --
> >> 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.

[akka-user] ANNOUNCE: New Remoting Milestone 4

[Patrik Nordwall]

Dear hakkers,

We are pleased to announce the availability of the fourth development
milestone of the new Akka Remoting, codenamed Artery. It’s a 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-M4 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.

 canonical.hostname = localhost

 # use 0 if you want a random available port

 canonical.port = 25520

}

Note that the configuration has changed since M3.

The protocol part of the actor system address is akka, so you need to
change previous akka.tcp to akka in for example configuration of cluster
seed-nodes. Note that this has changed from artery to akka since M3.

A summary of what is included in M4 compared to M3
<https://groups.google.com/d/msg/akka-user/JLbLrLh3vIg/twhLMRg7CQAJ>:


   -

   send heartbeat messages over the control stream, so that failure
   detectors are not disturbed by heavy traffic of ordinary messages
   -

   support for parallel serialization and deserialization
   -

   bind hostname and port for usage with Docker or NAT environment
   -

   many bug fixes, most cluster tests are now passing


The full list of changes since the last milestone is available under the
2.4-ARTERY-M3 <https://github.com/akka/akka/milestone/95?closed=1>
milestone on github for your reference.

We are using Aeron <https://github.com/real-logic/Aeron> as the underlying
transport and are implementing the layers on top using Akka Streams. You
find more details in the design document
<https://github.com/akka/akka-meta/issues/16>.

The development branch is artery-dev
<https://github.com/akka/akka/tree/artery-dev>, in case you want to take a
look or contribute. Issues are labeled with t:remoting:artery
<https://github.com/akka/akka/issues?q=is%3Aopen+is%3Aissue+label%3At%3Aremoting%3Aartery>
.

In the next three weeks we will work on additional hardening and testing,
followed by releasing it in a 2.4.x version of Akka as an optional
transport.

We would also like to ask you to take the Akka Community Survey
<http://blog.akka.io/community/2016/09/01/akka-community-survey-2016>. This
is a great opportunity for you to influence what we will work on next.
Pssst... you can also win a t-shirt.

Happy hakking!

-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Re: Suddenly increasing inter-actor message delivery time

[Patrik Nordwall]

If it's cpu bound work I would recommend one dispatcher for all with
slightly less threads than cores. Set max to cores - 1. Too many threads
will just make things slower for cpu bound work.

The reason for not using all cores is that it can be good to have some
spare capacity for other manegement tasks. You have to experiment with what
is best for your system.

/Patrik
tors 8 sep. 2016 kl. 21:10 skrev Rob Crawford :

> Kamon (kamon.io) has some of those metrics.
>
> http://kamon.io/integrations/akka/actor-router-and-dispatcher-metrics/
>
> Can you reproduce the problem easily? If so, try it with a
> Kamon-instrumented build and see what you get.
>
>
> On Thursday, September 8, 2016 at 12:41:00 PM UTC-4, Alexey Shuksto wrote:
>>
>> Hello hAkkers!
>>
>> We've got some very strange message delivery time pattern between actors:
>>
>> We have system with ~2000 type "A" working actors, each of whom have 1 to
>> 50 type "B" sub-workers (who do actual work, but do it very fast -- >1ms
>> between request and response).
>>
>> Every type A actor every second receives 1 to 50 (equal to number of
>> sub-workers) payloads of 1 to 10 messages (1 to 500 messages total),
>> chooses one type B actor per payload (1 to 10 messages), forwards them and
>> interpreting B-actor result.
>>
>> Number of "in-payload" messages is dependent of 'second-per-minute' --
>> most messages are received in 29th and 59th seconds.
>>
>> Usually a total time of message processing is around 1 to 5ms for a full
>> circle: in -> A -> B -> A -> out.
>> But in the "high load" times processing time quickly escalates up to 2.5
>> _seconds_.
>>
>> After some investigation and providing of separate dispatchers for type A
>> (FJE, parallelism 8 min, 64 max, 3.0 factor) and type B (same
>> configuration) actors, we were able to determine that type A actor still
>> receive messages at very fast rate, but type B actors...
>> At the start of processing they receive payload almost momentarily (0 to
>> 1ms latency), but as processing continues, time to deliver message from A
>> to B starts increasing up to 2.5 seconds mentioned above.
>>
>> We tried to tweak type B dispatcher and set 
>> SingleConsumerOnlyUnboundedMailbox
>> for them to no effect at all.
>>
>> From hardware side we have dual 6 core Intel server class processors (24
>> cores total), JVM has 32GB of ram (no swapping), G1GC, gc pauses do not
>> exceed 100ms and happens usually every 10-15 seconds.
>>
>> Is there anything else that we can tweak or use to pinpoint the problem?
>> May be some metric for average actor queue size and per-actor dispatcher
>> time?
>>
> --
> >> 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] Any form of first-try / first-peek at Artery Akka remoting ?

[Patrik Nordwall]

and the announcement contains a quick getting started guide:
https://groups.google.com/d/msg/akka-user/JLbLrLh3vIg/twhLMRg7CQAJ
there will be a M4 tomorrow

On Thu, Sep 8, 2016 at 10:49 AM, Viktor Klang <viktor.kl...@gmail.com>
wrote:

> Also, little known fact: "ARTERY" is pronounced in the same way as the
> chorus in Metallica's "BATTERY"
>
> On Thu, Sep 8, 2016 at 10:31 AM, Konrad Malawski <
> konrad.malaw...@lightbend.com> wrote:
>
>> Yes we're working on it.
>> Yes there's releases, just use them ;-)
>>
>> See 2.4-ARTERY versions: http://search.maven.
>> org/#search%7Cgav%7C1%7Cg%3A%22com.typesafe.akka%22%20AND%20
>> a%3A%22akka-remote_2.11%22
>>
>> --
>> Konrad `ktoso` Malawski
>> Akka <http://akka.io> @ Lightbend <http://lightbend.com>
>>
>> On 8 September 2016 at 10:29:26, Muthukumaran Kothandaraman (
>> muthu.kmk2...@gmail.com) wrote:
>>
>> Hi,
>>
>> Is Artery still a work in progress or any snapshots are available for
>> trying out ?
>>
>> Regards
>> Muthu
>>
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>> urrent/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/c
>> urrent/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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Re: Are messages ordered in activator hello akka java8 tutorial?

[Patrik Nordwall]

On Thu, Sep 8, 2016 at 8:38 AM, Patrik Nordwall <patrik.nordw...@gmail.com>
wrote:

>
>
> On Thu, Sep 8, 2016 at 12:42 AM, <ques...@gmail.com> wrote:
>
>> On Wednesday, September 7, 2016 at 3:16:57 PM UTC-7, Guido Medina wrote:
>>>
>>> By induction you can conclude that messages order is guaranteed when
>>> sending sequentially (in the same thread) by using the following assertions:
>>>
>>>- Messages sent to any local actor go immediately to their
>>>destination inbox hence order is preserved because of sequential 
>>> execution
>>>- JMM rule.
>>>- Messages that go from node A to node B will be sent in the same
>>>order as they arrive to node A remote dispatcher's inbox which for an 
>>> actor
>>>hosted at node A, the order of arrival is preserved (apply previous rule)
>>>- Messages that arrive to node B will be put in the remote
>>>dispatcher inbox in the same order they arrived, apply first two rules 
>>> and
>>>you that concludes in the messaging ordering rule - as for remote, 
>>> current
>>>remote implementation when sending from node A to B, it can only send
>>>synchronously hence, order is also preserved.
>>>
>>> The most complicated rule is the last one, but once order from node A to
>>> node B is preserved then you can conclude that order messages from actor A
>>> to actor B is also preserved regardless of their location.
>>>
>>
> The rules only apply when the destination actor is the same.
> Implementation of old and new remoting are different in this regard, but
> that is implementation details that doesn't change the original rule.
> The new remoting will support parallel outbound and inbound lanes that are
> selected based on hashing of the destination ActorRef.
>
>
>> This is my explanation with my own words, the documentation I think
>>> explains it using the Java Memory Model as a reflection.
>>>
>>> HTH,
>>>
>>> Guido.
>>>
>>>>
>>>>
>> Can't the data that makes up 2 messages arrive out of order when sent
>> over a network? So, node A might send them in the order it received them,
>> but the order in which the node received the messages could be different
>> from what was sent to node A.
>>
>
We are only using transports that preserve order. TCP and Aeron.


>
>> The cited documentation says:
>>
>> It is important to note that Akka’s guarantee applies to the order in
>>> which messages are enqueued into the recipient’s mailbox.
>>
>>
>> Does that refer to the order in which messages are sent by Akka instead
>> of enqueued for the receiver?
>>
>
> I think that is a disclaimer for when the mailbox itself is not preserving
> order, e.g. a priority queue.
>
>
>>
>>
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>> urrent/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.
>>
>
>
>
> --
>
> Patrik Nordwall
> Akka Tech Lead
> Lightbend <http://www.lightbend.com/> -  Reactive apps on the JVM
> Twitter: @patriknw
>
>


-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Re: Are messages ordered in activator hello akka java8 tutorial?

[Patrik Nordwall]

On Thu, Sep 8, 2016 at 12:42 AM, <ques...@gmail.com> wrote:

> On Wednesday, September 7, 2016 at 3:16:57 PM UTC-7, Guido Medina wrote:
>>
>> By induction you can conclude that messages order is guaranteed when
>> sending sequentially (in the same thread) by using the following assertions:
>>
>>- Messages sent to any local actor go immediately to their
>>destination inbox hence order is preserved because of sequential execution
>>- JMM rule.
>>- Messages that go from node A to node B will be sent in the same
>>order as they arrive to node A remote dispatcher's inbox which for an 
>> actor
>>hosted at node A, the order of arrival is preserved (apply previous rule)
>>- Messages that arrive to node B will be put in the remote dispatcher
>>inbox in the same order they arrived, apply first two rules and you that
>>concludes in the messaging ordering rule - as for remote, current remote
>>implementation when sending from node A to B, it can only send
>>synchronously hence, order is also preserved.
>>
>> The most complicated rule is the last one, but once order from node A to
>> node B is preserved then you can conclude that order messages from actor A
>> to actor B is also preserved regardless of their location.
>>
>
The rules only apply when the destination actor is the same.
Implementation of old and new remoting are different in this regard, but
that is implementation details that doesn't change the original rule.
The new remoting will support parallel outbound and inbound lanes that are
selected based on hashing of the destination ActorRef.


> This is my explanation with my own words, the documentation I think
>> explains it using the Java Memory Model as a reflection.
>>
>> HTH,
>>
>> Guido.
>>
>>>
>>>
> Can't the data that makes up 2 messages arrive out of order when sent over
> a network? So, node A might send them in the order it received them, but
> the order in which the node received the messages could be different from
> what was sent to node A.
>
> The cited documentation says:
>
> It is important to note that Akka’s guarantee applies to the order in
>> which messages are enqueued into the recipient’s mailbox.
>
>
> Does that refer to the order in which messages are sent by Akka instead of
> enqueued for the receiver?
>

I think that is a disclaimer for when the mailbox itself is not preserving
order, e.g. a priority queue.


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



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Re: Are messages ordered in activator hello akka java8 tutorial?

[Patrik Nordwall]

On Wed, Sep 7, 2016 at 7:51 PM, <ques...@gmail.com> wrote:

> Sorry for not understanding yet. The message ordering link cited earlier
> seems to me to be suggesting that ultimately programs in general can only
> have reliable message passing by having business logic that deals with it.
> The section from that link says:
>
> *for a given pair of actors, messages sent directly from the first to the
>> second will not be received out-of-order. *The word *directly* emphasizes
>> that this guarantee only applies when sending with the tell operator to
>> the final destination, not when employing mediators or other message
>> dissemination features (unless stated otherwise).
>
>
> I thought that this is no actor passing a message to an actor:
>
> final ActorRef greeter = system.actorOf(Props.create(Greeter.class),
>> "greeter");
>> greeter.tell(new WhoToGreet("akka"), ActorRef.noSender());
>
>
> And this is the Inbox actor sending a message to an actor:
>
> inbox.send(greeter, new Greet());
>
>
> So, I thought that would mean that it is not the scenario described where
> there is 1 pair of actors passing messages between each other. It's 2
> independent pairs, I thought. greet.tell is one pair? no actor and an
> actor. inbox.send is another pair: inbox actor exchanges a message with the
> greeter actor. If that is the case, then is the order undefined between the
> 2 invocations?
>

No, the message is not sent from the inbox actor. It is sent from the same
thread as
greeter.tell(new WhoToGreet("akka"), ActorRef.noSender());

That is why I said that it might look confusing to use inbox.send, and I
therefore recommend

greeter.tell(new WhoToGreet("akka"), ActorRef.noSender());
greeter.tell(new Greet(), inbox.getRef());

Then it is clear what order those two messages are sent in, and they both
have the same destination.

The documentation is talking about actor pairs, because you normally send
messages from an actor. In this example you don't send them from an actor,
but that doesn't matter. The tell methods are called in a specific order
since you invoke them from the same thread. Same would happen if the code
were running in an actor.


>
> Tal Pressman, earlier in the thread, says the message are sent from the
> same "context". Maybe I'm missing a context other than the pair of actors
> that applies to message ordering.
>
> Kendall
>
> On Wednesday, September 7, 2016 at 5:12:49 AM UTC-7, Patrik Nordwall wrote:
>>
>> I think the line that might cause confusion here is
>>
>> inbox.send(greeter, new Greet());
>>
>> The inbox can be seen as a "mediator" and therefore perceived as it might
>> not preserve ordering. For this reason I would prefer to write it as:
>>
>> greeter.tell(new Greet(), inbox.getRef());
>>
>> That is exactly how inbox.send is implemented, so the ordering is just
>> fine.
>>
>> Cheers,
>> Patrik
>>
>> On Wed, Sep 7, 2016 at 10:58 AM, Guido Medina <oxy...@gmail.com> wrote:
>>
>>> In the introduction chapter of Akka this is explained in details, how
>>> Akka takes care of it,
>>> I suggest you go there to learn the exact details:
>>>
>>> http://doc.akka.io/docs/akka/2.4.10/general/message-delivery
>>> -reliability.html#Discussion__Message_Ordering
>>>
>>> HTH,
>>>
>>> Guido.
>>>
>>>
>>>
>>> On Tuesday, September 6, 2016 at 5:12:32 PM UTC+1, que...@gmail.com
>>> wrote:
>>>>
>>>> The order that they are received would be the critical thing, I would
>>>> think. So, is the example not dealing with the possibility that the
>>>> messages could be received out of order? Or, is this somehow taken care of?
>>>>
>>>> Kendall
>>>>
>>>> On Monday, September 5, 2016 at 2:40:34 AM UTC-7, Tal Pressman wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> Message ordering is preserved between a sender-receiver pair. However,
>>>>> this refers to the actual actual actor sending the message, regardless of
>>>>> the ActorRef passed as the sender reference.
>>>>> In the example above, both messages are being sent from the same
>>>>> context, and therefor should be sent in-order.
>>>>>
>>>>> Tal
>>>>>
>>>>>
>>>>> On Saturday, September 3, 2016 at 8:19:33 AM UTC+3, que...@gmail.com
>>>>> wrote:
>>>>>>
>>>>>> I'm early in learning Akka.

Re: [akka-user] Re: Are messages ordered in activator hello akka java8 tutorial?

[Patrik Nordwall]

I think the line that might cause confusion here is

inbox.send(greeter, new Greet());

The inbox can be seen as a "mediator" and therefore perceived as it might
not preserve ordering. For this reason I would prefer to write it as:

greeter.tell(new Greet(), inbox.getRef());

That is exactly how inbox.send is implemented, so the ordering is just fine.

Cheers,
Patrik

On Wed, Sep 7, 2016 at 10:58 AM, Guido Medina <oxyg...@gmail.com> wrote:

> In the introduction chapter of Akka this is explained in details, how Akka
> takes care of it,
> I suggest you go there to learn the exact details:
>
> http://doc.akka.io/docs/akka/2.4.10/general/message-
> delivery-reliability.html#Discussion__Message_Ordering
>
> HTH,
>
> Guido.
>
>
>
> On Tuesday, September 6, 2016 at 5:12:32 PM UTC+1, que...@gmail.com wrote:
>>
>> The order that they are received would be the critical thing, I would
>> think. So, is the example not dealing with the possibility that the
>> messages could be received out of order? Or, is this somehow taken care of?
>>
>> Kendall
>>
>> On Monday, September 5, 2016 at 2:40:34 AM UTC-7, Tal Pressman wrote:
>>>
>>> Hi,
>>>
>>> Message ordering is preserved between a sender-receiver pair. However,
>>> this refers to the actual actual actor sending the message, regardless of
>>> the ActorRef passed as the sender reference.
>>> In the example above, both messages are being sent from the same
>>> context, and therefor should be sent in-order.
>>>
>>> Tal
>>>
>>>
>>> On Saturday, September 3, 2016 at 8:19:33 AM UTC+3, que...@gmail.com
>>> wrote:
>>>>
>>>> I'm early in learning Akka. The hello-akka-java8 tutorial has
>>>> greeter.tell from no actor, followed by inbox.send:
>>>>
>>>> final ActorRef greeter = system.actorOf(Props.create(Greeter.class),
>>>> "greeter");
>>>> final Inbox inbox = Inbox.create(system);
>>>> greeter.tell(new WhoToGreet("akka"), ActorRef.noSender());
>>>> inbox.send(greeter, new Greet());
>>>> Greeting greeting1 = (Greeting) inbox.receive(Duration.create(5,
>>>> TimeUnit.SECONDS));
>>>>
>>>> Can I expect that the greeter actor is going to process new
>>>> WhoToGreet("akka"), before new Greet()?
>>>>
>>>> If so, why?
>>>>
>>>> I read in Akka documentation:
>>>>
>>>> "*...for a given pair of actors, messages sent directly from the first
>>>> to the second will not be received out-of-order.* The word *directly* 
>>>> emphasizes
>>>> that this guarantee only applies when sending with the telloperator to
>>>> the final destination, not when employing mediators or other message
>>>> dissemination features (unless stated otherwise)."
>>>>
>>>> I think the tutorial is not sending messages from one actor.
>>>>
>>>>
>>>> --
> >>>>>>>>>> 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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Sharing my attempt at contributing to Akka

[Patrik Nordwall]

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



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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 and Streams Concurrency Fundamentals

[Patrik Nordwall]

Isn't it covered in the documentation?
http://akka.io/docs/

/Patrik
tors 1 sep. 2016 kl. 23:43 skrev Dagny T :

>
> I'd like to find reliable and current information for learning this using
> v2.4.9.
>
> I've posted a reply to someone else's related message; but wanted to call
> Forum attention to please help refer us to a useful Blog or GitHub repo on
> this topic; AND
> using the latest and greatest TestKit tools!
>
> It's been rather hit-or-miss with Googling samples lately; as the APIs
> have been moving rapidly, and I'm still too new to pick out what's
> essentially most important!
>
> THANK you so much in advance for any Best-Practice info on these
> fundamentals!
>
> Here was my reply to that earlier related post:
> https://groups.google.com/forum/#!topic/akka-user/4k4nXVn-wWw
>
> THANKS in advance to hAKKArs!
>
> --
> >> 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] Nodes becomes unreachable due to serialization-issues with one single message

[Patrik Nordwall]

Thanks for reporting., Fixed, will be in upcoming 2.4.10

/Patrik
tors 1 sep. 2016 kl. 20:58 skrev Moax76 <morten.kjetl...@gmail.com>:

> Issue created: https://github.com/akka/akka/issues/21343
>
> But I'll modify my serializer anyway.
>
> Thanks.
>
> -Morten
>
>
> On Thursday, September 1, 2016 at 8:33:04 PM UTC+2, Patrik Nordwall wrote:
>
>> I think we should handle exceptions from serializer.toBinary as transient.
>> Can you please create an issue. <https://github.com/akka/akka/issues/new> I
>> can understand that the reason might be that it is a program bug and the
>> system should probably not run with the bug, but I think error logging
>> should be enough since the exception doesn't result in any undefined state.
>>
>> Deserialization is a another story, which is exhausted in that ticket
>> Martynas linked to.
>>
>
>> On Thu, Sep 1, 2016 at 7:46 PM, Moax76 <morten@gmail.com> wrote:
>>
>>> Thanks a lot for the info.
>>>
>>> I'll fix my serializer so that it wraps all exceptions
>>> in NotSerializableException.
>>> Am I understanding it correct that I should only do this wrapping when
>>> serializing, and not deserializing?
>>>
>>> Thanks again.
>>>
>>> -Morten
>>>
>>> On Thursday, September 1, 2016 at 4:14:43 PM UTC+2, drewhk wrote:
>>>>
>>>> The only reason serialization errors cause a connection to be dropped
>>>> if the *deserialization* fails. This is because TCP is a streaming protocol
>>>> and we cannot decide why the deserialization failed, because of some bug,
>>>> or the TCP framing is out of sync. We just drop the connection to start
>>>> from a clean state.
>>>>
>>>> -Endre
>>>>
>>>> On Thu, Sep 1, 2016 at 3:33 PM, Martynas Mickevičius <
>>>> martynas.m...@lightbend.com> wrote:
>>>>
>>>>> EndpointWriter is only treating NotSerializableException as a
>>>>> transient one. So wrapping all of the exceptions from your serializer
>>>>> into NotSerializableException will not get the association dropped.
>>>>>
>>>>> Here is the discussion on having all of the exceptions transient:
>>>>> https://github.com/akka/akka/issues/20641
>>>>>
>>>>> On Wed, Aug 31, 2016 at 4:56 PM, Viktor Klang <viktor...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Well, I agree that it shouldn't gate the connection due to a failure
>>>>>> to serialize.
>>>>>>
>>>>>> Do you have a minimal reproducer to share?
>>>>>>
>>>>>> On Wed, Aug 31, 2016 at 3:48 PM, Moax76 <morten@gmail.com> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wednesday, August 31, 2016 at 3:37:41 PM UTC+2, √ wrote:
>>>>>>>>
>>>>>>>> What happens if you fix the serializer?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> If I fix the serializer, then the problem off course goes away, but
>>>>>>> that is not the point.
>>>>>>>
>>>>>>> The problem is that instead of dropping the message that (for some
>>>>>>> 'unknown' reason) failed to be serialized, it "drops" the connection, 
>>>>>>> and
>>>>>>> GATES it so that it will not try to reconnect in 5 seconds.
>>>>>>>
>>>>>>> If it worked as described above, this serializing issue would be a
>>>>>>> regular bug the only effected parts of the application, instead of the
>>>>>>> entire application going "down" due to cluster-issues.
>>>>>>>
>>>>>>>
>>>>>>> -Morten
>>>>>>>
>>>>>>> --
>>>>>>> >>>>>>>>>> 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

Re: [akka-user] Method to block Migration of Cluster Sharded Actors in a Certain State

[Patrik Nordwall]

The stop signal is that the actor is terminated, i.e. you called
context.stop, so stashing is fine
fre 2 sep. 2016 kl. 16:46 skrev kraythe :

> So if I have an actor that while on a specific state simply stashes any
> message that it doesn't handle, will it ignore the stop request until the
> message is I stashed and processed? Although that time delay should be a
> max of a couple seconds it does exist. And in the meantime j don't want the
> actor waiting for the reply to be never replied to because the message got
> dumped when the actor moved.
>
> The thing is the actor ends up only in this state due to a request from
> another actor and although I could get a receive timeout and try again, I
> would prefer to not do that if it can be avoided.
>
> --
> >>  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] Problem Configuring ActorSystem

[Patrik Nordwall]

That feature with short names is not released yet. It's in the Artery
branch.
/Patrik
tors 1 sep. 2016 kl. 10:42 skrev Konrad Malawski :

> You can also just set the provider to "remote" (or "cluster").
> It's a bit simpler to not make a typo in those ;)
>
> On Thu, Sep 1, 2016 at 6:14 AM, Viktor Klang 
> wrote:
>
>> there's a comma in the class name
>>
>> --
>> Cheers,
>> √
>>
>> On Sep 1, 2016 5:11 AM, "Joseph Mansigian" 
>> wrote:
>>
>>> I am using Akka with Scala and want to configure an ActorSystem for
>>> remote messaging ( but does not need to be remotely configurable ).  The
>>> problem I am having is that I am getting a Class Not Found exception for 
>>> akka,remote.RemoteActorRefProvider
>>> when I run the code.  I've double checked all of the usual suspects,
>>> the appropriate jar on the compile,  the appropriate jar on the run.
>>> Imports are all Ok as far as I can tell.  I am using scala 2.11.8 with akka
>>> 2,4,9 and Java 8 is installed but no Java coding
>>>
>>> I have read some old posts ( not here ) about Scala placing a version of
>>> Akka in its scala/lib and that this version of Akka comes into conflict
>>> with the other Akka.
>>>
>>> Does anyone have any insight into this?  Your help would be much
>>> appreciated.
>>>
>>> thanks, joe
>>>
>>> --
>>> >> 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,
> Konrad 'ktoso' Malawski
> Akka  @ Lightbend 
>
> --
> >> 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] Nodes becomes unreachable due to serialization-issues with one single message

[Patrik Nordwall]

ge 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/c
>>> urrent/additional/faq.html
>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou
>>> p/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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Method to block Migration of Cluster Sharded Actors in a Certain State

[Patrik Nordwall]

You can define a custom handOffStopMessage that your actors will receive
when they are asked to stop for rebalance. You can delay the stop when
receiving that message by not calling context.stop(self) until you are
done.

Note that if you don't stop within the handOffTimeout the rebalance will be
aborted.

Also note that other entities within the same shard will also be asked to
stop so one "slow" entity will affect others. You should probably not have
too long such delays.

It's more robust to design the system so that can always crash and recover
independent of what state it is in. Then such rebalance in the middle of a
process should not be a problem.

Cheers,
Patrik

On Sat, Aug 27, 2016 at 6:56 PM, kraythe <kray...@gmail.com> wrote:

> I have a cluster shared actor that basically has two states; IDLE and
> BUSY. The actor is cluster shared because I need the behavior of having
> only a single one of these in the cluster per user and  I want all of the
> messages that the actor to handle to be serialized per user. The actor
> mostly sits on IDLE but when it gets a certain message it becomes BUSY.
> During the busy state, it is collecting information from several other
> actors through tell() calls and waiting on the response messages. During
> the BUSY state I do NOT want that actor changing nodes. If it did then it
> would basically have to start all over processing the message it was
> holding in the busy state. Furthermore, persisting the actor's state is a
> non-starter as the data it is collecting is quite large, other actors are
> sending it references to immutable data in the same VM, after it gets all
> the data it does some analysis, writes a record, and is done.
>
> So the question is, if a node falls out of the cluster (or a new node
> joins) while the actor is BUSY and the rebalancing of the system starts to
> happen, can I prevent the actor from moving to the new node until after it
> goes back to IDLE.
>
> Thanks a bunch.
>
> -- 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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] BalancingPool and router actor capacity

[Patrik Nordwall]

If the work is CPU bound you should not have more worker actors than number
of cores (and leave some room for other things).

/Patrik

On Wed, Aug 24, 2016 at 2:51 AM, Mahesh Govind <vu3...@gmail.com> wrote:

> Dear Experts ,
>
>
> I have a scenario where I need to create a list of  worker actors and load
> balance it using a Balancing pool .
> In this scenario we have the following
>
> Producer > routerActor --BalancedPool>  'n'  WorkerActors
>
>
> Do we have some heuristic using which i could decide the capacity of
> routerActor.
> Could you please provide a production example where 'n WorkerActors' are
> managed by one 'Router Actor'  , so that I can get some insight from the
> same.
>
> Currently I dont have any intuition about the number of workers or the
> message handling capacity  of a Router  .
>
>
> Could you please provide some pointers for the same .
>
> regards
> Mahesh
>
> --
> >>>>>>>>>> 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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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-kafka-stream "Offset Storage in Kafka" question/clarification

[Patrik Nordwall]

The commit commands are emitted to the underlying KafkaConsumer in right
order. It is waiting for the results of the commits that are done in
parallel, and will possibly increase total throughput. We observed better
throughput in performance tests.

It would be great to clarify this in docs. You are not the first one to
ask. Would you like to open a pull request?

/Patrik
lör 27 aug. 2016 kl. 00:35 skrev Drew Kutcharian :

> Hi,
>
> In the "Offset Storage in Kafka” on
> http://doc.akka.io/docs/akka-stream-kafka/current/consumer.html#offset-storage-in-kafka
>  there
> is the following example:
>
> .groupedWithin(10, 5.seconds)
> .map(group => group.foldLeft(CommittableOffsetBatch.empty) { (batch, elem)
> => batch.updated(elem) })
> .mapAsync(3)(_.commitScaladsl())
>
> Wouldn’t the ".mapAsync(3)(_.commitScaladsl())” cause the offsets to be
> committed to Kafka out of order? Shouldn’t it be "mapAsync(1)”?
>
> Best,
>
> Drew
>
> --
> >> 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] Subscribing to PersistentShardCoordinator startup failure

[Patrik Nordwall]

It's a fair point. I would like to have a good alternative, built-in. I'll
see what I can do.

On Fri, Aug 26, 2016 at 2:24 PM, Justin du coeur <jduco...@gmail.com> wrote:

> Time for another radical suggestion: I really think y'all should just
> excise auto-down from the documentation, and probably drop the feature
> entirely.  It doesn't add an awful lot of benefit (since people who are
> getting started usually aren't dealing with downing), and it's *way* too
> easy to get yourself into trouble with it.  Heck, even I managed to screw
> this one up until Chris and Ed pointed out that I had it sitting in my
> application.conf, and I *do* know better -- it was just left over from my
> original fumblings in the early days, before I knew what I was doing.
>
> Far as I can tell from the list, this is the single biggest cause of
> people having disasters in production; even with the big red warning box in
> the docs, people keep leaving it in.  (Presumably because it's mentioned in
> the reference confs.)  It replaces an easy-to-understand problem (state
> getting "stuck" because the node that owned it went down) with a much
> subtler one (split-brain).  IMO, it's time for this misfeature to die, and
> just be replaced with a flat statement in the documentation that "in a real
> cluster, you have to either buy SBR or come up with a downing strategy".
>
> On Fri, Aug 26, 2016 at 7:29 AM, Patrik Nordwall <
> patrik.nordw...@gmail.com> wrote:
>
>> There is no such feature. You can ping a dummy entity and see if you get
>> a reply. If it repeatedly times out you are in trouble.
>>
>> However, I think you should solve the root cause of the problem. The
>> typical mistake is to use auto-down and thereby get split clusters as
>> described in the documentation.
>>
>> /Patrik
>>
>> On Tue, Aug 23, 2016 at 12:04 PM, Paulina Morkytė <pmork...@gmail.com>
>> wrote:
>>
>>> Hello,
>>>
>>> From time to time we get a problem with our persistence shard
>>> coordinator corruption.
>>> The data gets corrupted, therefore, we can't start the system up until
>>> we clear all persisted coordinator information.
>>> The only way we managed to spot those kind of errors was by checking the
>>> logs, which is not a long term solution.
>>> Is it possible to subscribe to the persistent shard coordinator, so we
>>> could react to the problem on startup?
>>>
>>> We are using Akka versions 2.4.9.
>>>
>>> Kind Regards,
>>> Paulina Morkyte
>>>
>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou
>>> p/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.
>>>
>>
>>
>>
>> --
>>
>> Patrik Nordwall
>> Akka Tech Lead
>> Lightbend <http://www.lightbend.com/> -  Reactive apps on the JVM
>> Twitter: @patriknw
>>
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>> urrent/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
> >>>>>>>

Re: [akka-user] Subscribing to PersistentShardCoordinator startup failure

[Patrik Nordwall]

There is no such feature. You can ping a dummy entity and see if you get a
reply. If it repeatedly times out you are in trouble.

However, I think you should solve the root cause of the problem. The
typical mistake is to use auto-down and thereby get split clusters as
described in the documentation.

/Patrik

On Tue, Aug 23, 2016 at 12:04 PM, Paulina Morkytė <pmork...@gmail.com>
wrote:

> Hello,
>
> From time to time we get a problem with our persistence shard coordinator
> corruption.
> The data gets corrupted, therefore, we can't start the system up until we
> clear all persisted coordinator information.
> The only way we managed to spot those kind of errors was by checking the
> logs, which is not a long term solution.
> Is it possible to subscribe to the persistent shard coordinator, so we
> could react to the problem on startup?
>
> We are using Akka versions 2.4.9.
>
> Kind Regards,
> Paulina Morkyte
>
> --
> >>>>>>>>>> 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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Re: Cluster actors an parallelism

[Patrik Nordwall]

You could have only one routee per node that creates child actors and
delegates the actual work to them.
Another flexible and dynamic approach is to use Distributed Pub Sub as a
"router": http://doc.akka.io/docs/akka/2.4/scala/distributed-pub-sub.html

On Thu, Aug 25, 2016 at 11:20 PM, Cosmin Marginean <cos.margin...@gmail.com>
wrote:

> Thanks Patrik. I was hoping there would be a more flexible (and less
> hardcoded way to do this)
>
> On 25 Aug 2016, at 18:41, Patrik Nordwall <patrik.nordw...@gmail.com>
> wrote:
>
> Start more worker actors on each node, each with a different name, let's
> say worker1, worker2, worker3. Then in the config you define all 3 in the
> paths
>
> "paths": ["/user/worker1", "/user/worker2", "/user/worker3"]
>
> /Patrik
>
> On Thu, Aug 25, 2016 at 4:41 PM, Cosmin Marginean <cosmargin...@gmail.com>
> wrote:
>
>> Thanks, I will try to do further diagnosis, however this is a last
>> resort. I believe I would like to understand if this kind of use case is
>> something that Akka would natively be delivering in one form or another and
>> / or if I'm missing a trick in terms of correct router/etc that I'm using
>> here.
>>
>> Thank you
>> Cosmin
>>
>> On Thursday, August 25, 2016 at 3:14:38 PM UTC+1, Justin du coeur wrote:
>>>
>>> Smells like the problem is somewhere in the router?  I mean, if you're
>>> only processing one message at a time, that suggests that you've only got
>>> one instance of the worker Actor running, instead of the 100 that it's
>>> trying to declare.
>>>
>>> I don't use routers, so I can't speak to this config, but personally I
>>> would turn on a ton of logging, to see how many worker Actors are actually
>>> being created and how the requests are being routed to them...
>>>
>>> On Thu, Aug 25, 2016 at 9:17 AM, Cosmin Marginean <cosmar...@gmail.com>
>>> wrote:
>>>
>>>> Hi Muthu
>>>>
>>>> I've explored these but they're not exactly what I'm after. The use
>>>> case is as follows: we have let's say 5 nodes, and 3 of them serve as
>>>> "workers". These 3 should be processing a series of events/messages in
>>>> parallel.
>>>>
>>>> We thus want some "load balancing" (consistent hashing is rigid and not
>>>> suited for this IMO) whereby if we send 90 messages, they get (reasonably)
>>>> equally distributed between the 3 nodes (~30 each for example).
>>>>
>>>> Going further, we want on each of the 3 worker nodes to have a level of
>>>> parallel processing, so each node would be able to process 30 messages in
>>>> parallel let's say, and thus making all of this process (almost) fully
>>>> parallelised in this example.
>>>>
>>>> What happens now with one node is that we are sending a few thousand
>>>> messages and only one message is processed at a time (single threaded
>>>> like). This is something I couldn't figure out how to overcome.
>>>>
>>>> I've also configured the dispatcher to parallelise manically, so that
>>>> is clearly "not it". Below the complete config (seed nodes etc is added
>>>> dynamically from somewhere else)
>>>>
>>>> {
>>>> "main": {
>>>> "akka": {
>>>> "remote": {
>>>> "log-remote-lifecycle-events": "on"
>>>> },
>>>> "cluster": {
>>>> "auto-down-unreachable-after": "10s"
>>>> },
>>>> "actor": {
>>>> "provider": "akka.cluster.ClusterActorRefProvider",
>>>> "default-dispatcher": {
>>>> "type": "Dispatcher",
>>>> "executor": "fork-join-executor",
>>>> "fork-join-executor": {
>>>> "parallelism-min": 16,
>>>> "parallelism-factor": 32,
>>>> "parallelism-max": 512
>>>> },
>>>> "throughput": 1
>>>> },
>>>> "deployment": {

Re: [akka-user] Re: Cluster actors an parallelism

[Patrik Nordwall]

>
>>>
>>> Thank you
>>> Cosmin
>>>
>>> On Thursday, August 25, 2016 at 1:59:54 PM UTC+1, Muthukumaran
>>> Kothandaraman wrote:
>>>>
>>>> Hi Cosmin,
>>>>
>>>> Are these what you are looking for
>>>>
>>>> http://doc.akka.io/docs/akka/snapshot/scala/routing.html#Con
>>>> sistentHashingPool_and_ConsistentHashingGroup OR
>>>> http://doc.akka.io/docs/akka/snapshot/scala/routing.html#Bro
>>>> adcastPool_and_BroadcastGroup
>>>>
>>>> Regards
>>>> Muthu
>>>>
>>>>
>>>>
>>>>
>>>> On Thursday, 25 August 2016 14:50:13 UTC+5:30, Cosmin Marginean wrote:
>>>>>
>>>>> Hello everyone
>>>>>
>>>>> We have a classic scenario with a cluster with 2 tiers where one is a
>>>>> "worker" that we offload heavy processing to. We wired Akka clustering and
>>>>> have the following setup for a remote actor that is to be executed only on
>>>>> the worker tier.
>>>>>
>>>>> "/frontend/backend": {
>>>>> "router": "round-robin-group",
>>>>> "routees": {
>>>>> "paths": ["/user/worker"]
>>>>> },
>>>>> "cluster": {
>>>>> "enabled": "on",
>>>>> "allow-local-routees": "off",
>>>>> "use-role": "worker"
>>>>> }
>>>>> }
>>>>>
>>>>>
>>>>> This works fine and message gets processed in the worker accordingly,
>>>>> however we're interested to understand how to control the parallelism at
>>>>> that level. More precisely, we'd want each worker node to process a series
>>>>> of messages in parallel rather than one at a time as it does now.
>>>>> Any ideas?
>>>>>
>>>>> Thank you
>>>>> Cosmin
>>>>>
>>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou
>>> p/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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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 Streams Camel?

[Patrik Nordwall]

That would be a great contribution to the Akka Streams Intregration
initiative, see blog post
http://blog.akka.io/integrations/2016/08/23/intro-alpakka

Please create a pull request in akka-stream-contrib. It should be a
separate sub-project, similar to akka-stream-contib-amqp

Cheers,
Patrik

tors 25 aug. 2016 kl. 01:58 skrev Héctor Veiga :

> Hi,
>
> I am working on a project where we are using akka-streams and we have
> coded our own CamelSource and CamelSink. Basically a Source that can be any
> Camel consumer and a Sink that can be any Camel producer. I was wondering
> if it could be a good idea to provide those as part of some separated
> package like akka-camel-streams (or akka-streams-camel) so developers could
> use then out of the box.
>
> Let me know what you think,
>
> Thanks,
>
> Héctor.
>
> --
> >> 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 V2.3.9) Akka configured seed nodes are leaving cluster and unreachable/reachable warning message is getting logged. ::: Spring Class (ClassPathXmlApplicationContext) serializatio

[Patrik Nordwall]

and remote deployment Props is also a suspect
ons 24 aug. 2016 kl. 20:48 skrev Justin du coeur <jduco...@gmail.com>:

> It's not so much "how to avoid" -- you are presumably trying to send
> something that contains a reference to that Context, and you need to *not*
> do so.  It's unlikely to have anything to do with your configuration --
> you're probably doing something illegal in your code.  I doubt there's any
> way to know exactly what's going on without digging through your code in
> detail.
>
> Basically, you can't just send any arbitrary thing across the network.
> You should sit down and take a look at what messages you *are* sending
> between your Actors (especially Actors that may be on different nodes), and
> make sure that all of them (and everything they reference in their fields)
> are properly serializable.
>
> On Wed, Aug 24, 2016 at 6:23 AM, vipin mandloi <vipinmandl...@gmail.com>
> wrote:
>
>> Hello,
>>
>> Thanks for your quick response.
>>
>> *How can i avoid sending ClassPathXmlApplicationContext ?*
>>
>> I didn't have any custom code for serialization. I'm using akka provided
>> cluster message Serializer
>>
>>
>> serializers {
>>  akka-cluster = "akka.cluster.protobuf.ClusterMessageSerializer"
>> }
>> serialization-bindings {
>> "akka.cluster.ClusterMessage" = akka-cluster
>> }
>>
>>
>>
>>
>> On Wednesday, August 24, 2016 at 3:34:04 PM UTC+5:30, Patrik Nordwall
>> wrote:
>>>
>>> Then you must avoid sending ClassPathXmlApplicationContext. It's not
>>> serializable, and should not be, so you can't send it.
>>>
>>> On Wed, Aug 24, 2016 at 10:08 AM, vipin mandloi <vipinm...@gmail.com>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>>
>>>> Thanks a lot for the response.
>>>>
>>>> *Enabled remote debugging , Error - "Failed to write message to
>>>> Transport " is  occurring due to Spring Class
>>>> (ClassPathXmlApplicationContext) serialization failure. *
>>>>
>>>> Please let me know whether *Akka Cluster Remote Routess  usages
>>>> support spring configuration ?*
>>>>
>>>>  if yes then how can i fix *Spring Class
>>>> (ClassPathXmlApplicationContext) serialization failure ? *
>>>>
>>>>
>>>> *Logged error message:-*
>>>>
>>>>
>>>> *[ERROR] [08/24/2016 03:03:13.934]
>>>> [ClusterSystem-akka.remote.default-remote-dispatcher-23]
>>>> [akka.tcp://ClusterSystem*
>>>>
>>>>
>>>> *@localhost:2551/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FClusterSystem%40localhost%3A2552-0/en*
>>>>
>>>> *dpointWriter] AssociationError
>>>> [akka.tcp://ClusterSystem@localhost:2551] ->
>>>> [akka.tcp://ClusterSystem@localhost:2552*
>>>>
>>>> *]: Error [Failed to write message to the transport] [*
>>>>
>>>> *akka.remote.EndpointException: Failed to write message to the
>>>> transport*
>>>>
>>>> *Caused by: java.lang.IllegalArgumentException: Can't serialize object
>>>> of type class org.springframework.context.su
>>>> <http://org.springframework.context.su>pp*
>>>>
>>>> *ort.ClassPathXmlApplicationContext*
>>>>
>>>> at
>>>> akka.cluster.protobuf.ClusterMessageSerializer.toBinary(ClusterMessageSerializer.scala:74)
>>>>
>>>> at
>>>> akka.serialization.Serialization$$anonfun$serialize$1.apply(Serialization.scala:90)
>>>>
>>>> at
>>>> akka.serialization.Serialization$$anonfun$serialize$1.apply(Serialization.scala:90)
>>>>
>>>> at scala.util.Try$.apply(Try.scala:161)
>>>>
>>>> at
>>>> akka.serialization.Serialization.serialize(Serialization.scala:90)
>>>>
>>>> at
>>>> akka.remote.serialization.DaemonMsgCreateSerializer.serialize(DaemonMsgCreateSerializer.scala:107)
>>>>
>>>> at
>>>> akka.remote.serialization.DaemonMsgCreateSerializer$$anonfun$propsProto$1$1.apply(DaemonMsgCreateSerializ
>>>>
>>>> er.scala:56)
>>>>
>>>> at
>>>> akka.remote.serialization.DaemonMsgCreateSerializer$$anonfun$propsProto$1$1.apply(DaemonMsgCreateSerializ
>>>>
>>>> er.scala:56)
>&g

Re: [akka-user] (AKKA V2.3.9) Akka configured seed nodes are leaving cluster and unreachable/reachable warning message is getting logged. ::: Spring Class (ClassPathXmlApplicationContext) serializatio

[Patrik Nordwall]

Then you must avoid sending ClassPathXmlApplicationContext. It's not
serializable, and should not be, so you can't send it.

On Wed, Aug 24, 2016 at 10:08 AM, vipin mandloi <vipinmandl...@gmail.com>
wrote:

> Hello,
>
>
> Thanks a lot for the response.
>
> *Enabled remote debugging , Error - "Failed to write message to Transport
> " is  occurring due to Spring Class (ClassPathXmlApplicationContext)
> serialization failure. *
>
> Please let me know whether *Akka Cluster Remote Routess  usages support
> spring configuration ?*
>
>  if yes then how can i fix *Spring Class (ClassPathXmlApplicationContext)
> serialization failure ? *
>
>
> *Logged error message:-*
>
>
> *[ERROR] [08/24/2016 03:03:13.934]
> [ClusterSystem-akka.remote.default-remote-dispatcher-23]
> [akka.tcp://ClusterSystem*
>
>
> *@localhost:2551/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FClusterSystem%40localhost%3A2552-0/en*
>
> *dpointWriter] AssociationError [akka.tcp://ClusterSystem@localhost:2551]
> -> [akka.tcp://ClusterSystem@localhost:2552*
>
> *]: Error [Failed to write message to the transport] [*
>
> *akka.remote.EndpointException: Failed to write message to the transport*
>
> *Caused by: java.lang.IllegalArgumentException: Can't serialize object of
> type class org.springframework.context.supp*
>
> *ort.ClassPathXmlApplicationContext*
>
> at akka.cluster.protobuf.ClusterMessageSerializer.toBinary(
> ClusterMessageSerializer.scala:74)
>
> at akka.serialization.Serialization$$anonfun$serialize$1.apply(
> Serialization.scala:90)
>
> at akka.serialization.Serialization$$anonfun$serialize$1.apply(
> Serialization.scala:90)
>
> at scala.util.Try$.apply(Try.scala:161)
>
> at akka.serialization.Serialization.serialize(
> Serialization.scala:90)
>
> at akka.remote.serialization.DaemonMsgCreateSerializer.serialize(
> DaemonMsgCreateSerializer.scala:107)
>
> at akka.remote.serialization.DaemonMsgCreateSerializer$$
> anonfun$propsProto$1$1.apply(DaemonMsgCreateSerializ
>
> er.scala:56)
>
> at akka.remote.serialization.DaemonMsgCreateSerializer$$
> anonfun$propsProto$1$1.apply(DaemonMsgCreateSerializ
>
> er.scala:56)
>
> at scala.collection.TraversableLike$$anonfun$map$
> 1.apply(TraversableLike.scala:244)
>
> at scala.collection.TraversableLike$$anonfun$map$
> 1.apply(TraversableLike.scala:244)
>
> at scala.collection.immutable.List.foreach(List.scala:318)
>
> at scala.collection.TraversableLike$class.map(
> TraversableLike.scala:244)
>
> at scala.collection.AbstractTraversable.map(Traversable.scala:105)
>
> at akka.remote.serialization.DaemonMsgCreateSerializer.
> propsProto$1(DaemonMsgCreateSerializer.scala:56)
>
> at akka.remote.serialization.DaemonMsgCreateSerializer.toBinary(
> DaemonMsgCreateSerializer.scala:62)
>
> at akka.remote.MessageSerializer$.serialize(MessageSerializer.
> scala:36)
>
> at akka.remote.EndpointWriter$$anonfun$serializeMessage$1.
> apply(Endpoint.scala:842)
>
> at akka.remote.EndpointWriter$$anonfun$serializeMessage$1.
> apply(Endpoint.scala:842)
>
> at scala.util.DynamicVariable.withValue(DynamicVariable.scala:57)
>
> at akka.remote.EndpointWriter.serializeMessage(Endpoint.scala:841)
>
> at akka.remote.EndpointWriter.writeSend(Endpoint.scala:742)
>
> at akka.remote.EndpointWriter$$anonfun$2.applyOrElse(
> Endpoint.scala:717)
>
> at akka.actor.Actor$class.aroundReceive(Actor.scala:465)
>
> at akka.remote.EndpointActor.aroundReceive(Endpoint.scala:410)
>
> 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.
> pollAndExecAll(ForkJoinPool.java:1253)
>
>     at scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.
> runTask(ForkJoinPool.java:1346)
>
> at scala.concurrent.forkjoin.ForkJoinPool.runWorker(
> ForkJoinPool.java:1979)
>
> at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(
> ForkJoinWorkerThread.java:107)
>
>
>
> Thanks,
> Vipin Mandloi
>
> On Tuesday, August 23, 2016 at 11:33:43 PM UTC+5:30, Patrik Nordwall wrote:
>>
>> I would

Re: [akka-user] Akka configured seed nodes are leaving cluster and unreachable/reachable warning message is getting logged.

[Patrik Nordwall]

22, 2016 at 11:09 AM, vipin mandloi <vipinm...@gmail.com>
>>> wrote:
>>>
>>>> Please let me know if i am missing any configuration.
>>>>
>>>
>>> It's not a matter of *missing* -- the problem is that this:
>>>
>>>
>>>> *My application.conf is configured as below-*
>>>>
>>>>
>>>>   cluster {
>>>> auto-down-unreachable-after = 10s
>>>>   }
>>>>
>>>
>>> Should never, ever, *ever* be used except for initial testing.
>>> Auto-down is intended just as a way to get you started, but it's very
>>> primitive and dumb, and must *never* be used in production.  Auto-downing
>>> is always likely to cause cluster disasters, and having such a short
>>> auto-down timeout essentially guarantees it.
>>>
>>> Basically, you're getting split-brain -- you need to replace auto-down
>>> with a more-sophisticated downing strategy.  See this section of the
>>> documentation
>>> <http://doc.akka.io/docs/akka/2.4.9-RC2/scala/cluster-usage.html#automatic-vs-manual-downing-scala>
>>> for more information.
>>>
>> --
> >>>>>>>>>> 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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Binding Actors to CPU or to a core

[Patrik Nordwall]

There is a library that you might be able to use:
https://github.com/OpenHFT/Java-Thread-Affinity
It's using native code.

/Patrik

On Tue, Aug 23, 2016 at 9:15 AM, Endre Varga <endre.va...@lightbend.com>
wrote:

> Hi Mahesh,
>
> Unfortunately there is no way to set CPU affinity for a Java thread from
> the JVM. You can probably build a native library that you can call into via
> JNA.
>
> -Endre
>
> On Tue, Aug 23, 2016 at 5:13 AM, Mahesh Govind <vu3...@gmail.com> wrote:
>
>> Dear Experts,
>>
>> Is it possible to bind a group of akka actors to a specific core or to a
>> processor  .
>>
>> I have a situation where the machine is having 2 processors with 6
>> cores/processor , but I dont have any clue about the distribution of
>>  actors .
>>
>> Is there a java API equivalent of "taskset"  or similiar functionality ?
>>
>> Regards
>> mahesh
>>
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>> urrent/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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Re: leveldb readjournal eventsByPersistenceId hangs when toSequenceNr=0

[Patrik Nordwall]

It should terminate once it has arrived at or passed toSequenceNr.
Otherwise I see no point in that parameter.

toSeqNr=0 is an obvious boundary case, where it can terminate immediately.

Anything else?

/Patrik
sön 21 aug. 2016 kl. 18:10 skrev Aditya Prasad <akpra...@gmail.com>:

> On Sun, Aug 21, 2016 at 9:10 AM, Aditya Prasad <akpra...@gmail.com> wrote:
>
>> Thanks Patrick.
>>
> Sorry... thanks *Patrik*.
>
>> What are the more general conditions under which the stream should
>> terminate?
>>
>> I've come to appreciate the behavior that the stream terminates once it
>> has arrived at or passed toSequenceNr. I wrote a tentative PR for the JDBC
>> impl: https://github.com/dnvriend/akka-persistence-jdbc/pull/66.
>> The alternative in my application is to append a takeWhile() to the
>> stream, plus some extra logic so that it completes when it has delivered
>> item N (and not wait for N+1, which may be a long time coming).
>>
>> On Aug 21, 2016 6:50 AM, "Patrik Nordwall" <patrik.nordw...@gmail.com>
>> wrote:
>>
>> I think it makes sense to complete the stream when it's know that there
>> will be no events matching toSequenceNr.
>>
>> There is an effort to write a TCK for Persistence Query
>> https://github.com/akka/akka/pull/20807
>> Unfortunately the PR has been inactive for a while now. It would be great
>> if community can help out there and complete it. The TCK would be a great
>> place to add tests for the toSequenceNr. Fixing the actual implementations
>> would also be needed, of course.
>>
>> Thanks,
>> Patrik
>>
>> On Sun, Aug 21, 2016 at 7:33 AM, Aditya Prasad <akpra...@gmail.com>
>> wrote:
>>
>>> Does anyone know the expected semantics of eventsByPersistenceId when
>>> toSequenceNr is less than or equal to the journal's latest version?
>>>
>>> In some impls & cases it completes the stream (which makes sense), and
>>> in others it does not (which is hard to work with).
>>>
>>>
>>> On Thursday, August 18, 2016 at 10:52:58 AM UTC-7, Aditya Prasad wrote:
>>>>
>>>> Can anyone else repro this? This future never completes:
>>>>
>>>> val fut = readJournal.eventsByPersistenceId(tenantId.value, 0,
>>>>> 0).runWith(Sink.head)
>>>>> val res = Await.result(fut, 10 seconds)
>>>>
>>>>
>>>>
>>>>
>>> --
>>> >>>>>>>>>> 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.
>>>
>>
>>
>>
>> --
>>
>> Patrik Nordwall
>> Akka Tech Lead
>> Lightbend <http://www.lightbend.com/> -  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 a topic in the
>> Google Groups "Akka User List" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/akka-user/hl2A6e65gsQ/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 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/

Re: [akka-user] Re: leveldb readjournal eventsByPersistenceId hangs when toSequenceNr=0

[Patrik Nordwall]

I think it makes sense to complete the stream when it's know that there
will be no events matching toSequenceNr.

There is an effort to write a TCK for Persistence Query
https://github.com/akka/akka/pull/20807
Unfortunately the PR has been inactive for a while now. It would be great
if community can help out there and complete it. The TCK would be a great
place to add tests for the toSequenceNr. Fixing the actual implementations
would also be needed, of course.

Thanks,
Patrik

On Sun, Aug 21, 2016 at 7:33 AM, Aditya Prasad <akpra...@gmail.com> wrote:

> Does anyone know the expected semantics of eventsByPersistenceId when
> toSequenceNr is less than or equal to the journal's latest version?
>
> In some impls & cases it completes the stream (which makes sense), and in
> others it does not (which is hard to work with).
>
>
> On Thursday, August 18, 2016 at 10:52:58 AM UTC-7, Aditya Prasad wrote:
>>
>> Can anyone else repro this? This future never completes:
>>
>> val fut = readJournal.eventsByPersistenceId(tenantId.value, 0,
>>> 0).runWith(Sink.head)
>>> val res = Await.result(fut, 10 seconds)
>>
>>
>>
>>
> --
> >>>>>>>>>> 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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Cluster Metrics on Windows

[Patrik Nordwall]

It can sometimes be difficult to setup loading of the native sigar library.
Several alternatives are listed in docs
http://doc.akka.io/docs/akka/2.4/java/cluster-metrics.html#Hyperic_Sigar_Provisioning

You should see warnings/errors in the log.

/Patrik
lör 20 aug. 2016 kl. 17:10 skrev Chris Van Vranken <
cessationoft...@gmail.com>:

> Though sigar is the collector I would like to be able to use.
>
> On Aug 20, 2016 11:09 AM, "Chris Van Vranken" 
> wrote:
>
>> I have tried both of them with the same result on Windows. On Ubuntu I
>> have only tried sigar.
>>
>> On Aug 20, 2016 4:26 AM, "Endre Varga"  wrote:
>> >
>> > Hi,
>> >
>> > Which metric collector are you using, the JMX or the SIGAR collector?
>> >
>> > -Endre
>> >
>> > On Sat, Aug 20, 2016 at 1:31 AM, cessationoftime <
>> cessationoft...@gmail.com> wrote:
>> >>
>> >> Using Akka 2.4.9 and Windows 10 I am unable to get CPU cluster
>> metrics, I can only get HeapMemory metrics. Running the same code on a
>> Ubuntu server I get both CPU metrics and Heap metrics.  I am using the
>> factorial example located at:
>> http://www.lightbend.com/activator/template/akka-sample-cluster-scala.
>> And I am running it in sbt with the following command "runMain
>> sample.cluster.factorial.FactorialApp". Is there something I need to do to
>> get this to work on windows?  Should it work on windows?
>> >>
>> >> Thanks,
>> >> Chris
>> >>
>> >> --
>> >> >> 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 a topic in the
>> Google Groups "Akka User List" group.
>> > To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/akka-user/IMc50pgXssY/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 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.
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] What means of akka cluster roles leader?

[Patrik Nordwall]

It's also worth noting that for the "leader" concept there is no election.
It's simply the node with the lowest address with some additional rules
around membership status and unreachability. That means that there can be
more than one "leader" at the same time, e.g. one for each side of a
network partition.

Cluster singleton is more strict and ensures that there will not be more
than one active singleton at any time.

/Patrik
fre 19 aug. 2016 kl. 11:41 skrev Akka Team :

> HI Yutao,
>
> On Mon, Aug 15, 2016 at 2:26 PM, Yutao Shuai  wrote:
>
>>
>> 
>> Thanks for your help Konrad. So the return value of this function is the
>> leader of the cluster? But I read the DiffRolesLeader function in the
>> ClusterEvent.scala where call the roleLeader function. This function
>> traverse all roles and call the roleLeader function, What this mean? All
>> nodes with specfic roles have its own leader? What difference between this
>> leader and cluster leader ?
>>
>
> The cluster leader does certain responsibilities in the cluster,
> internally. If you want to also hook into this leader election, then you
> can since we expose via the API the leader. In certain cases it might be
> useful to be able to select a leader among a subset of cluster members
> though, in that case you can use the role leader functionality. By default
> the cluster does nothing with this, it is only an exposed API if someone
> needs this for building new functionality on top of this leader election
> protocol.
>
> It is *NOT *recommended to use these features directly, as in 99.9% of
> the cases you really want the cluster Singleton pattern instead:
> http://doc.akka.io/docs/akka/2.4/scala/cluster-singleton.html
> For example, the leader election protocol selects a new leader whenever a
> new node *added not just when the leader is removed.* This is not an
> issue for Akka itself, as the role of the leader is stateless, and this
> transition is cheap. On the other hand, with most user Singletons you want
> to usually have state and therefore prefer a more stable location. The
> Singleton pattern solve this for you.
>
> In general, I would avoid touching the internal leader election altogether
> and use Singletons instead.
>
> -Endre
>
>
>>
>>
>> 在 2016年8月15日星期一 UTC+8下午5:27:22，Konrad Malawski写道：
>>>
>>> Hi Yutao,
>>> look at the return type – Option, so it's a single element.
>>> It returns the leader of a given role (role == multiple nodes, 1 of them
>>> is the leader).
>>> I.e. it would host the the Singleton if it were constrained to this role.
>>>
>>> --
>>> Konrad `ktoso` Malawski
>>> Akka  @ Lightbend 
>>>
>>> On 15 August 2016 at 04:23:26, Yutao Shuai (szq...@gmail.com) wrote:
>>>
>>>
>>> 
>>>
>>> What this function means? Select a nodes with specfic roles as the
>>> cluster leader or every roles has its leader?
>>> --
>>> >> 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 Team
> Lightbend  - Reactive apps on the JVM
> Twitter: @akkateam
>
> --
> >> 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 

Re: [akka-user] Hot Standby Persistent Actor - https://github.com/akka/akka/issues/13938

[Patrik Nordwall]

By the way, we can continue design discussion in the ticket
https://github.com/akka/akka/issues/13938

On Tue, Aug 16, 2016 at 9:51 AM, Patrik Nordwall <patrik.nordw...@gmail.com>
wrote:

> Here is a link to the recovery logic: https://github.com/
> akka/akka/blob/master/akka-persistence/src/main/scala/
> akka/persistence/Eventsourced.scala#L467
>
> When looking at this now I think we should not use persistent query for
> this, since the ordinary replay has its own protocol (set of messages) to
> the journal. The hot standby should use the same protocol to ensure that it
> ends up in the same state.
>
> On Mon, Aug 15, 2016 at 2:44 PM, Muthukumaran Kothandaraman <
> muthu.kmk2...@gmail.com> wrote:
>
>> Thanks Patrik. I would like to follow this. I assume that the design
>> discussions are confined to the issues link.
>>
>> Are there any pointers in code for understanding how recovery is
>> currently triggered for persistent actors so that I can get warmed up ? I
>> guess that would be a good point for me to start with
>>
>> Regards
>> Muthu
>>
>>
>> On Thursday, 11 August 2016 23:27:59 UTC+5:30, Patrik Nordwall wrote:
>>>
>>> The milestone of an issue is no guarantee that it will be released in
>>> that version, until the issue is closed. We can't do that kind of planning.
>>>
>>> This would be a great feature for community contibution. Queries are
>>> there now.
>>>
>>> /Patrik
>>> ons 10 aug. 2016 kl. 07:04 skrev Muthukumaran Kothandaraman <
>>> muthu@gmail.com>:
>>>
>>>> Hi,
>>>>
>>>> Is this still targeted for 2.5 or it has moved further ? As I
>>>> understand, this required some query-side improvements before this could be
>>>> addressed.
>>>>
>>>> Regards
>>>> Muthu
>>>>
>>>> --
>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>>>> urrent/additional/faq.html
>>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou
>>>> p/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/c
>> urrent/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.
>>
>
>
>
> --
>
> Patrik Nordwall
> Akka Tech Lead
> Lightbend <http://www.lightbend.com/> -  Reactive apps on the JVM
> Twitter: @patriknw
>
>


-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Hot Standby Persistent Actor - https://github.com/akka/akka/issues/13938

[Patrik Nordwall]

Here is a link to the recovery logic:
https://github.com/akka/akka/blob/master/akka-persistence/src/main/scala/akka/persistence/Eventsourced.scala#L467

When looking at this now I think we should not use persistent query for
this, since the ordinary replay has its own protocol (set of messages) to
the journal. The hot standby should use the same protocol to ensure that it
ends up in the same state.

On Mon, Aug 15, 2016 at 2:44 PM, Muthukumaran Kothandaraman <
muthu.kmk2...@gmail.com> wrote:

> Thanks Patrik. I would like to follow this. I assume that the design
> discussions are confined to the issues link.
>
> Are there any pointers in code for understanding how recovery is currently
> triggered for persistent actors so that I can get warmed up ? I guess that
> would be a good point for me to start with
>
> Regards
> Muthu
>
>
> On Thursday, 11 August 2016 23:27:59 UTC+5:30, Patrik Nordwall wrote:
>>
>> The milestone of an issue is no guarantee that it will be released in
>> that version, until the issue is closed. We can't do that kind of planning.
>>
>> This would be a great feature for community contibution. Queries are
>> there now.
>>
>> /Patrik
>> ons 10 aug. 2016 kl. 07:04 skrev Muthukumaran Kothandaraman <
>> muthu@gmail.com>:
>>
>>> Hi,
>>>
>>> Is this still targeted for 2.5 or it has moved further ? As I
>>> understand, this required some query-side improvements before this could be
>>> addressed.
>>>
>>> Regards
>>> Muthu
>>>
>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou
>>> p/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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] What means of akka cluster roles leader?

[Patrik Nordwall]

On Mon, Aug 15, 2016 at 11:27 AM, Konrad Malawski <
konrad.malaw...@lightbend.com> wrote:

> Hi Yutao,
> look at the return type – Option, so it's a single element.
> It returns the leader of a given role (role == multiple nodes, 1 of them
> is the leader).
> I.e. it would host the the Singleton if it were constrained to this role.
>

That is not correct. Singleton runs on the oldest node. The leader is
simply the node (with given role) with the lowest address with some
additional rules. It's not at all as strict as the singleton. It's mostly
used to manage the cluster membership and applications typically use the
singleton instead of the leader.

/Patrik




>
> --
> Konrad `ktoso` Malawski
> Akka <http://akka.io> @ Lightbend <http://lightbend.com>
>
> On 15 August 2016 at 04:23:26, Yutao Shuai (szqs...@gmail.com) wrote:
>
>
> <https://lh3.googleusercontent.com/-tZtLqoK9VUY/V7EnCA2ZVKI/AL0/Gm66R8FjZqIZOmBWrT8b29IL8PdUJboCwCLcB/s1600/TT%25E6%2588%25AA%25E5%259B%25BE%25E6%259C%25AA%25E5%2591%25BD1%25E5%2590%258D.jpg>
>
> What this function means? Select a nodes with specfic roles as the cluster
> leader or every roles has its leader?
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
> urrent/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/c
> urrent/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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Event Adapters and custom journals

[Patrik Nordwall]

On Wed, Aug 10, 2016 at 1:13 PM, Daniel Stoner <daniel.sto...@ocado.com>
wrote:

> Hi all,
>
> Having read the docs on EventAdapters (http://doc.akka.io/docs/akka/
> 2.4.9-RC2/java/persistence.html#event-adapters-java) and seeing the
> example of how to ignore particular classes I thought this would be a
> perfect solution for me.
>
> Having implemented the example I have tried to the following the
> application.conf example where event-adapter is defined inside the
> 'journal.inmem' config location (EG The location specified by
> journal.plugin value). As such I have:
>
> persistence {
> journal {
> plugin = "com.osp.scs.libnado.persistence.dynamodb"
> }
> ..more things
> }
>
> com.osp.scs.libnado.persistence.dynamodb {
> event-adapters {
> class-not-found = "com.osp.scs.libnado.akka.codec.
> ClassNotFoundEventAdapter"
>   }
>   event-adapter-bindings {
> "com.osp.scs.libnado.akka.codec.JacksonSerializable" =
> class-not-found
>   }
> }
>
> Now it has suddenly occurred to me (since this isn't working) that
> actually event adaptation is something that has to be implemented in each
> Journal implementation that exists and not something that Akka is providing
> before it gets to the journal itself.
>
> Is this the case or am I just putting my config in the wrong place?
> If the former the documentation on how to write your own custom Journal
> may need updating to reflect the intended requirement to support this
> feature.
>

That is true. The TCK should also cover it. Please create an issue, and a
pull request would be great.


>
> Further - are there any shortcuts for implementing the requirements such
> as there is with Serialization and the serialisation-bindings and other
> assorted config working. EG You just utilise SerializationExtension.get(
> system).serialize(entity).
>

Persistence.get(system).adaptersFor


>
> Thanks kindly,
> Daniel Stoner
> --
> Daniel Stoner | Senior Software Engineer UtopiaIT | Ocado Technology
> daniel.sto...@ocado.com | Ext 7969 | www.ocadotechnology.com
>
>
> Notice:  This email is confidential and may contain copyright material of
> members of the Ocado Group. Opinions and views expressed in this message
> may not necessarily reflect the opinions and views of the members of the
> Ocado Group.
>
>
>
> If you are not the intended recipient, please notify us immediately and
> delete all copies of this message. Please note that it is your
> responsibility to scan this message for viruses.
>
>
>
> Fetch and Sizzle are trading names of Speciality Stores Limited and Fabled
> is a trading name of Marie Claire Beauty Limited, both members of the Ocado
> Group.
>
>
>
> References to the “Ocado Group” are to Ocado Group plc (registered in
> England and Wales with number 7098618) and its subsidiary undertakings (as
> that expression is defined in the Companies Act 2006) from time to time.
> The registered office of Ocado Group plc is Titan Court, 3 Bishops Square,
> Hatfield Business Park, Hatfield, Herts. AL10 9NE.
>
> --
> >>>>>>>>>> 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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] What happened if leader become unreachable in the cluster

[Patrik Nordwall]

What are you trying to solve?

/Patrik
tors 11 aug. 2016 kl. 13:46 skrev Yutao Shuai :

> Does the leader will down himself or another node will become leader?
> Where is  the code about this in the source files. Thanks much for your
> help!
>
> --
> >> 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] Is there a way to reload configuration at run time?

[Patrik Nordwall]

No, config is immutable and not changed after startup.

I see no reason for doing that in your example. Use default, 5.

/Patrik
fre 12 aug. 2016 kl. 03:56 skrev Yutao Shuai :

> Is there a way to reload configuration at run time?
>
> For example:
> I defined failure detect parameter
> "monitored-by-nr-of-members = 1"
>
> while the cluster consists of 3 nodes.
> I want to adjustment
> "monitored-by-nr-of-members = 5"
>
> after some new nodes have been joined to the cluster.
>
> 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 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: Akka cluster node shutting down in the middle of processing requests

[Patrik Nordwall]

I have not looked at the logs but you find answer to your last question in
http://doc.akka.io/docs/akka/2.4/scala/cluster-usage.html#How_To_Cleanup_when_Member_is_Removed

/Patrik

fre 5 aug. 2016 kl. 22:31 skrev Eric Swenson :

> One more clue as to the cluster daemon's shutting itself down.  Earlier in
> the logs (although prior to several successful requests being handled), I
> find this:
>
> [INFO] [08/05/2016 05:04:45.042]
> [ClusterSystem-akka.actor.default-dispatcher-5]
> [akka.cluster.Cluster(akka://ClusterSystem)] Cluster Node [akka.tcp://
> ClusterSystem@10.0.3.103:2552] - Leader can currently not perform its
> duties, reachability status: [akka.tcp://ClusterSystem@10.0.3.103:2552 ->
> akka.tcp://ClusterSystem@10.0.3.102:2552: Unreachable [Unreachable] (16),
> akka.tcp://ClusterSystem@10.0.3.103:2552 -> akka.tcp://
> ClusterSystem@10.0.3.104:2552: Unreachable [Unreachable] (17), akka.tcp://
> ClusterSystem@10.0.3.103:2552 -> akka.tcp://ClusterSystem@10.0.3.176:2552:
> Unreachable [Unreachable] (18), akka.tcp://ClusterSystem@10.0.3.103:2552
> -> akka.tcp://ClusterSystem@10.0.3.240:2552: Unreachable [Unreachable]
> (19)], member status: [akka.tcp://ClusterSystem@10.0.3.102:2552 Up
> seen=false, akka.tcp://ClusterSystem@10.0.3.103:2552 Up seen=true,
> akka.tcp://ClusterSystem@10.0.3.104:2552 Up seen=false, akka.tcp://
> ClusterSystem@10.0.3.176:2552 Up seen=false, akka.tcp://
> ClusterSystem@10.0.3.240:2552 Up seen=false]
>
>
> All these log messages are from the node at IP address 10.0.3.103.  So I'm
> assuming this means the Leader is THIS node.  It seems to be saying that it
> cannot reach all the other cluster members, and because of that, it cannot
> do its job. This probably accounts for why it decided to shut itself down.
>
>
> There were 6 AWS EC2 instances running this application at the time (not
> 10, as I said in an earlier message).  However, the cluster membership
> above, only shows 5 members at the time of this log message.  Not sure what
> happened to the other one.
>
>
> [akka.tcp://ClusterSystem@10.0.3.102:2552 Up seen=false,
>
>  akka.tcp://ClusterSystem@10.0.3.103:2552 Up seen=true,
>
>  akka.tcp://ClusterSystem@10.0.3.104:2552 Up seen=false,
>
>  akka.tcp://ClusterSystem@10.0.3.176:2552 Up seen=false,
>
>  akka.tcp://ClusterSystem@10.0.3.240:2552 Up seen=false]
>
>
> I'm going to assume, not having any other evidence, that AWS/EC2
> experienced some network issue at the time in question, and consequently
> this node was not able to talk to the rest of the cluster and therefore
> this member (the leader) shut down.  I only have logs for one of the other
> 5 cluster nodes, so I will check to see what that other node thought about
> all this at the time.  But I'm not very comfortable with the robustness of
> akka here.  I would have thought that the other cluster members could have,
> perhaps, noticing that the Leader was unreachable (assuming they couldn't
> reach it), and because I had auto-down-unreachable-after set (yes, yes,
> I've sense replaced this with manual downing logic -- but that is on our
> dev deployment and this issue happened on our staging deployment), elected
> a new leader and carried on -- even if this node became catatonic.
>
>
> This raises another point:  When the ClusterDaemon shuts itself down, it
> would appear that I should handle some event here (not sure how to do
> that), to cause the entire JVM to terminate.  This would cause AWS/ECS to
> launch a new instance to join the remaining cluster.
>
>
> Thoughts?  -- Eric
>
>
>
>
>
> --
> >> 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] Hot Standby Persistent Actor - https://github.com/akka/akka/issues/13938

[Patrik Nordwall]

The milestone of an issue is no guarantee that it will be released in that
version, until the issue is closed. We can't do that kind of planning.

This would be a great feature for community contibution. Queries are there
now.

/Patrik
ons 10 aug. 2016 kl. 07:04 skrev Muthukumaran Kothandaraman <
muthu.kmk2...@gmail.com>:

> Hi,
>
> Is this still targeted for 2.5 or it has moved further ? As I understand,
> this required some query-side improvements before this could be addressed.
>
> Regards
> Muthu
>
> --
> >> 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: Akka Cluster Across Datacenters

[Patrik Nordwall]

I agree with Ryan that it's generally not recommended.

I would like to add that the cluster membership and distributed data will
work pretty fine across DC thanks to their gossip based protocols, but
there are other tools, such as cluster sharding, that are not a good fit
for it.

Cluster downing can be a challenge. Network partitions vs. crashes. The
downing strategy should probably be DC aware.

/Patrik
tors 11 aug. 2016 kl. 18:47 skrev Ryan Tanner :

> Akka is generally not recommended for spanning data centers.
>
> I would consider the cluster client, though personally I'd probably choose
> Kafka for this role, with separate clusters in each DC.  IME cross-DC
> communication is generally a scenario where you really want to make sure
> messages are persisted to disk before being consumed on the other side, it
> just makes failure recovery 100x easier (unless you just don't care about
> missing messages).
>
>
> On Thursday, August 11, 2016 at 7:00:21 AM UTC-6, Eli Jordan wrote:
>>
>>
>> I am writing a system that needs to be distributed across various data
>> centers e.g. US, Europe, Asia. I need to replicate a small amount of
>> configuration data between the nodes in each datacenter (there are a small
>> number of nodes in each data center, 1 or 2) and this configuration can be
>> updated in any of the data centers.
>>
>> I am considering using akka clustering with the distributed data feature
>> to replicate this configuration data. However, I haven't been able to find
>> any documentation about whether it is recommended to have an akka cluster
>> span data centers, over a network leg that is much more unreliable than a
>> LAN connection or what guarantees are provided in such a configuration.
>>
>> Is this a configuration that will work well? Or is something like akka
>> cluster client a better approach? Or is there another solution akka can
>> offer to this problem?
>>
>> Any help appreciated
>>
> --
> >> 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: How to read XML inputstream (with SAX parser) received by akka-http?

[Patrik Nordwall]

Take a look at Endre's streaming xml parser, for inspiration:
https://github.com/drewhk/akka-xml-stream/pull/1

ons 10 aug. 2016 kl. 19:57 skrev JY :

> Nobody can help me to read 5GB of upload data with akka-http, and without
> crashing my VM with OutOfMemoryException ?
>
> (I think the topic of this conversation is too specific compared to the
> real explained problem, but I don't know how to modify the subject)
>
> Le mardi 2 août 2016 12:20:28 UTC+2, JY a écrit :
>>
>> I forgot to specify that flow I have to analyze weigh between 1 and 5 GB,
>> and I have to extract the value of a dozen tags, which is why we can't load
>> all data into memory, and that we've choose SAX :)
>>
>>
>>
>> Le mardi 2 août 2016 11:23:18 UTC+2, JY a écrit :
>>>
>>> In fact, (I will try to be both more specific and more generic):
>>>
>>> I have to read (via InputStream because of SAX parser) the data when the
>>> first bits are received.
>>>
>>> I'm not able to wait and load all data into memory before to use it.
>>>
>>> I can not yet find the way to do it.
>>>
>>> I need a little help :)
>>>
>>>
>>>
>>> Le mardi 2 août 2016 10:31:01 UTC+2, Konrad Malawski a écrit :

 Yeah, that'd be good to collect usecases and demadn there.
 Though with SAX it won't be automagical ever, they always require
 manually writing the parsing AFAIR

 --
 Konrad `ktoso` Malawski
 Akka  @ Lightbend 

 On 2 August 2016 at 10:29:21, André (andre.r...@gmail.com) wrote:

 Maybe you can add your use case to
 https://github.com/akka/akka/issues/16210.

 On Tuesday, August 2, 2016 at 10:12:13 AM UTC+2, JY wrote:
>
> I am new with AKKA and AKKA HTTP.
>
> I have to write a HTTP server application that reads a lot very big
> XML data flows (via HTTP PUT method) and parses this Data with a SAX 
> parser.
>
> How can I do that with akka-http?
>
> Thanx in advance for your help.
>
 --
 >> 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.
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: Akka Persistence - AtLeastOnceDelivery: How to get unlimited number of unconfirmed messages without running out of memory

[Patrik Nordwall]

Good suggestion. Another alternative is that the AtLeastOnceDelivery actor
rejects new incoming messages when there are too many unconfirmed messages.
That means that the original producer must deal with acknowledgments and
rejections. The AtLeastOnceDelivery actor becomes a safe-handoff point and
until it has acknowledged that it will take care of delivery of a message
it's the senders responsibility, e.g. return error response to a client.

On Wed, Aug 10, 2016 at 10:46 AM, Eric Yomi <ericy...@gmail.com> wrote:

> Hi Tal,
> Thanks for your reply. Your suggestion to use a PersistenceQuery actor
> seems like a good one. I'll look into that and let you know.
>
> On Wednesday, August 10, 2016 at 7:57:12 AM UTC+1, Tal Pressman wrote:
>>
>> Hi,
>>
>> From what I know, you can't do this using just a single PersistentActor,
>> since you have no control of the incoming message rate (even if you just
>> persist the messages and don't keep them in memory after that, they could
>> arrive faster than the journal can persist them).
>>
>> If we assume that you can persist the messages quickly enough, then you
>> can achieve something similar to what you are looking for using a
>> PersistentActor that just persists the messages as they come in and a
>> persistence-query stream that reads and sends the messages out. This way
>> the stream provides back-pressure, so you won't read messages from the
>> persistence layer unless previous messages were acknowledged.
>>
>> Hope this helps,
>> Tal
>>
>>
>> On Tuesday, August 9, 2016 at 4:59:56 PM UTC+3, Eric Yomi wrote:
>>>
>>> We are using a AtLeastOnceDelivery persistent actor. We are getting a
>>> huge volume of unconfirmed messages and this is causing an OutOfMemoryError
>>> if this number is too large.
>>>
>>>
>>> Is there a way we can configure the AtLeastOnceDelivery actor to keep
>>> the unconfirmed messages on disk rather than keeping them all in memory
>>> until they are confirmed?
>>>
>>> Or better is there an alternative to AtLeastOnceDelivery that gets
>>> around this limitation?
>>>
>>>
>>> Also we have played around with the max number of unconfirmed messages
>>> setting. Although reducing this value prevents an OutOfMemoryError it does
>>> however results in subsequent messages being discarded.
>>>
>>> We would like to have a solution where the unconfirmed messages are not
>>> kept in memory, but constantly flushed out to file without any loss 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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Weakly up feature not working

[Patrik Nordwall]

The problem is that to be able to restart and join a node with the same
hostname and port the cluster must first remove the old incarnation. The
downing of the old incarnation is triggered by the new join attempt, but
the actual removal can't be done until all unreachable have been downed. In
this scenario you still have node3 lingering around as unreachable and
hindering the removal of node2.

This is before WeaklyUp is involved. node2 is not accepted to join until
the old incarnation is removed.

It will work if you restart both node2 and node3.

It will also work if you use another port for node2 when restarting it.

I don't have a simple solution for supporting this scenario.

/Patrik

On Tue, Aug 9, 2016 at 9:28 PM, Akka Team <akka.offic...@gmail.com> wrote:

> Hi Tom,
>
> There might be something not working around new incarnations of the same
> node (same host and port) rejoining and weakly up, not quite sure if it is
> supposed to work. I can confirm that downing two nodes of a three node
> cluster, and have a new incarnation of one of them rejoining the cluster
> does not seem to work. I'll look into this and see if it might be a bug.
>
> However, here is a sample that shows weakly up working as expected,
> downing a node so it becomes unreachable, and then joining a new node:
> https://gist.github.com/johanandren/04c4720c917bad167169f73abe68da03
> --
> Johan
> Akka Team
>
> --
> >>>>>>>>>> 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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Re: from akka.persistence.journal.ReplayFilter Invalid replayed event [1] in buffer from old writer

[Patrik Nordwall]

I don't know about you, but I dislike mysteries. Could you start the actor
system with config
akka.log-config-on-start=on
and see what it logs for the mode.

/Patrik


On Tue, Aug 9, 2016 at 7:37 PM, Eric Swenson <e...@swenson.org> wrote:

> Just checked again. No override of that config parameter. Yet, these were,
> indeed, logged as errors not warnings.  -- Eric
>
> On Monday, August 8, 2016 at 11:28:33 PM UTC-7, Patrik Nordwall wrote:
>>
>>
>>
>> On Mon, Aug 8, 2016 at 10:06 PM, Eric Swenson <er...@swenson.org> wrote:
>>
>>> We have not changed the default mode=repair-by-discard-old config value
>>> for the replay-filter.  Should we?  — Eric
>>>
>>
>> Then I can't understand how you can get the ERROR as in the first message
>> in this thread
>>
>> IllegalStateException: Invalid replayed event [1] in buffer from old writer
>>
>> Then this should be logged at WARNING level and it should have discarded
>> the event from the "old" writer.
>>
>>
>>
>>>
>>> On Aug 7, 2016, at 9:47 AM, Patrik Nordwall <patrik@gmail.com>
>>> wrote:
>>>
>>> It's typically caused by multiple persistent actors with the same
>>> persistenceId running at the same time. E.g. because there were a network
>>> split and your cluster was split into two separate clusters and thereby
>>> starting multiple persistent actors. That is why we so strongly recommend
>>> against using auto-downing and instead recommend Split Brain Resolver
>>> <http://doc.akka.io/docs/akka/rp-current/scala/split-brain-resolver.html>
>>>  or similar.
>>>
>>> Now you need to cleanup the corrupted data before starting the system.
>>> http://doc.akka.io/docs/akka/2.4/scala/cluster-sharding.html
>>> #Removal_of_Internal_Cluster_Sharding_Data
>>>
>>> Have you changed the default mode=repair-by-discard-old in the config
>>> of the replay filter?
>>> https://github.com/akka/akka/blob/master/akka-persistence/sr
>>> c/main/resources/reference.conf#L131
>>>
>>> Regards,
>>> Patrik
>>>
>>> On Tue, Aug 2, 2016 at 9:44 PM, Eric Swenson <er...@swenson.org> wrote:
>>>
>>>> I'm getting this error consistently now, and don't know why this is
>>>> happening nor what to do about it.  I form the persistentId this way:
>>>>
>>>> override def persistenceId: String = self.path.parent.parent.name +
>>>> "-" + self.path.name
>>>>
>>>> So I don't see how I could have two persisters with the same id.  I'm
>>>> unable to bring up my akka cluster due to this error.
>>>>
>>>> Any suggestions?  I'm running akka 2.4.8 with akka.persistence:
>>>>
>>>> journal.plugin = "cassandra-journal"
>>>> snapshot-store.plugin = "cassandra-snapshot-store"
>>>>
>>>>
>>>> On Monday, April 25, 2016 at 3:34:21 AM UTC-7, Tim Pigden wrote:
>>>>>
>>>>> Hi
>>>>> I'm getting this message. I'm probably doing something wrong but any
>>>>> idea what that might be? I know what messages I'm persisting and this
>>>>> particular test is one in which I kill off my persistor and restart it.
>>>>> Or does it indicate the message is failing to deserialize or something
>>>>> like that
>>>>>
>>>>> 2016-04-25 10:33:47,570 - ERROR - from 
>>>>> com.optrak.opkakka.ddd.persistence.SimplePersistor Persistence failure 
>>>>> when replaying events for persistenceId [shd-matrix-testId]. Last known 
>>>>> sequence number [0]
>>>>> java.lang.IllegalStateException: Invalid replayed event [1] in buffer 
>>>>> from old writer [f6bd09c4-1f1c-4710-8cf6-c6f0776f39d3] with persistenceId 
>>>>> [shd-matrix-testId]
>>>>>at 
>>>>> akka.persistence.journal.ReplayFilter$$anonfun$receive$1.applyOrElse(ReplayFilter.scala:125)
>>>>>at akka.actor.Actor$class.aroundReceive(Actor.scala:480)
>>>>>at 
>>>>> akka.persistence.journal.ReplayFilter.aroundReceive(ReplayFilter.scala:50)
>>>>>
>>>>>
>>>>>
>>>>> Any suggests much appreciated!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>>&g

Re: [akka-user] Dynamically move proxied journal (PersistencePluginProxy) to another node

[Patrik Nordwall]

Hi Alexey,

Sorry for the confusion. I mixed up how this works. Do you think we should
add another method to start the target?

  def startJournalPlugin(system: ActorSystem, journalPluginId: String): Unit
  def startSnapshotStorePlugin(system: ActorSystem, snapshotPluginId: String
): Unit

It could live in the PersistencePluginProxy companion object.

Would you like to create a pull request for adding that method?

/Patrik

On Tue, Aug 9, 2016 at 6:33 PM, Alexey S <kvr...@gmail.com> wrote:

>
>
>>> The problem with the PersistencePluginProxy.start(system) is that AFAIU
>>> it checks the actual actor system config before it decides how exactly to
>>> start the plugin, and if in the config it say "start-target-journal=false"
>>> (as in my case) it won't start the underlying journal.
>>>
>>
>> No, it doesn't. See here: https://github.com/akka/
>> akka/blob/master/akka-persistence/src/main/scala/akka/
>> persistence/journal/PersistencePluginProxy.scala#L26
>>
>> Note that it only works for the default plugin (null). I think there are
>> other places in the PersistencePluginProxy where it only works for the
>> default plugin.
>>
>
> I understand the code you mentioned above as "PersistencePluginProxy only
> works *as* default plugin".
> Otherwise why does it need the target plugin ids config for the journal
> and snapshot?
>
> And this is
> https://github.com/akka/akka/blob/master/akka-persistence/
> src/main/scala/akka/persistence/journal/PersistencePluginProxy.scala#L80
>
> where it decides whether to start the target plugin or not.
>
> Thanks!
>
> WBR,
> Alexey.
>
>
>
>
>
>>
>>
>>>
>>> That's why I'm using that semi-hacky way to force the underlying journal
>>> plugin to start.
>>>
>>> Thanks.
>>>
>>> WBR,
>>> Alexey
>>>
>>> On Sunday, August 7, 2016 at 8:40:19 AM UTC-7, Patrik Nordwall wrote:
>>>>
>>>> As far as I can see the PersistencePluginProxy can only be used with
>>>> the default journal plugin and then you would use 
>>>> PersistencePluginProxy.sta
>>>> rt(system).
>>>>
>>>> I hope you need this for testing. PersistencePluginProxy is not
>>>> intended for production usage.
>>>>
>>>> Regards,
>>>> Patrik
>>>>
>>>> On Sat, Aug 6, 2016 at 12:46 AM, oleksiys <kvr...@gmail.com> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I have a usecase, where I'd like to be able to move the proxied
>>>>> journal from one cluster node to another.
>>>>> Looks like I can redirect all the journal clients using:
>>>>>
>>>>> *PersistencePluginProxy.setTargetLocation(someNewLocation)*
>>>>>
>>>>> But now on the cluster node, that has to host the journal I need to
>>>>> actually start the actual journal plugin (considering the default journal
>>>>> plugin is proxied-journal).
>>>>> So I need a way to start a non-default journal plugin at runtime.
>>>>>
>>>>> The closest I could get to it was:
>>>>>
>>>>> *Persistence(system).adaptersFor(journalPluginId)*
>>>>>
>>>>> it looks a bit hacky, but unfortunately:
>>>>>
>>>>> *Persistence(system).journalFor(journalPluginId)*
>>>>> *Persistence(system).snapshotStoreFor(snapshotStorePluginId)*
>>>>>
>>>>> are all in the private[akka] scope.
>>>>>
>>>>> Any suggestions?
>>>>>
>>>>> Thank you.
>>>>>
>>>>> WBR,
>>>>> Alexey
>>>>>
>>>>> --
>>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>>>>> urrent/additional/faq.html
>>>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou
>>>>> p/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.
>>>>

Re: [akka-user] Question about Akka Scaling: Memory

[Patrik Nordwall]

On Tue, Aug 9, 2016 at 5:14 PM, Endre Varga <endre.va...@lightbend.com>
wrote:

>
>
> On Tue, Aug 9, 2016 at 5:07 PM, Rob Crawford <rob5...@gmail.com> wrote:
>
>> The project home page says "~2.5 million actors per GB of heap" --
>>
>
> That is sadly outdated, actors now take up more memory. Still, not a
> drastic difference, the million in magnitude likely holds.
>

I actually checked that not too long ago and "~2.2 million actors per GB of
heap" is the current number.


>
>
>> that works out to just about 430 bytes per actor. I'm assuming these
>> actors have little or no state of their own, and the figure includes the
>> Akka kernel itself.
>>
>
> Akka "kernel" is a constant in this picture. What is measured here is the
> size of a minimal actor, which is yes, a few hundred bytes. Of course as
> soon as an actor has a message in its mailbox, then that will consume
> memory.
>
>
>>
>> A system I built previously has about 750,000 components it monitors; at
>> any time about 10,000 of those are loaded in memory. This application uses
>> JMS and runs under WebSphere -- and averages about 1.3GB heap usage.
>>
>> So, even assuming the actors use 1k each, this entire system would
>> consume just around 750MB -- and even adding 250MB for "other" consumption,
>> an Akka-based system would use less memory and keep the *entire* problem
>> domain in memory.
>>
>
> This might very well be the case. I recommend to try it out though and
> look at it with VisualVM or something like that.
>
>
>> Currently, we deserialize/re-serialize batches of components when we
>> receive a batch of messages for them; it looks like with Akka we could
>> limit deserialization only to restarts, and serialization could happen
>> asynchronously with Akka persistence -- which would undoubtedly give us a
>> performance gain.
>>
>> Am I off base? Is the Akka/actor model that much more efficient?
>>
>
> More efficient than what? There is nothing surprising that an actor itself
> is a few hundred bytes (and the additional state you put in there of
> course). It just keeps a queue, some fields for various internal state
> (like references to child actors, list of watchers, etc). These are all
> small, albeit they can grow depending on the pattern the actors are used.
>
>
>> Has anyone seen gains like this?
>>
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>> urrent/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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Released Requester 2.4

[Patrik Nordwall]

Awesome! Thanks for sharing.

On Tue, Aug 9, 2016 at 3:19 PM, Justin du coeur <jduco...@gmail.com> wrote:

> A quick note for those who care: I've just cut a new release of Requester
> <https://github.com/jducoeur/Requester>, the library that provides "the
> big brother of ask" -- functionality similar to ask and Future, but which
> are safe to use within Actors.  Requester lets you build complex
> multi-Actor workflows much more easily and cleanly than pipeTo, and more
> safely than ask.
>
> Release 2.4 adds the prep() / resolve() method pair, which lets you build
> Promise-like workflows using RequestM.  This lets you wrap Akka
> Persistence's persist() function so that you can build composable workflows
> using it.
>
> --
> >>>>>>>>>> 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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Dynamically move proxied journal (PersistencePluginProxy) to another node

[Patrik Nordwall]

On Mon, Aug 8, 2016 at 9:13 PM, oleksiys <kvr...@gmail.com> wrote:

> Hi Patrik,
>
> no, it's not for production, but during testing we'd like to be able to
> shutdown cluster nodes to make sure the app behaves properly.
> In the proxy journal config file I set the "start-target-..." property to
> false for all the nodes and I want to start the target journal only on the
> oldest cluster member, and if/when it dies I want the second oldest cluster
> member to start the target journal plugin etc...
>
> The problem with the PersistencePluginProxy.start(system) is that AFAIU
> it checks the actual actor system config before it decides how exactly to
> start the plugin, and if in the config it say "start-target-journal=false"
> (as in my case) it won't start the underlying journal.
>

No, it doesn't. See here:
https://github.com/akka/akka/blob/master/akka-persistence/src/main/scala/akka/persistence/journal/PersistencePluginProxy.scala#L26

Note that it only works for the default plugin (null). I think there are
other places in the PersistencePluginProxy where it only works for the
default plugin.


>
> That's why I'm using that semi-hacky way to force the underlying journal
> plugin to start.
>
> Thanks.
>
> WBR,
> Alexey
>
> On Sunday, August 7, 2016 at 8:40:19 AM UTC-7, Patrik Nordwall wrote:
>>
>> As far as I can see the PersistencePluginProxy can only be used with the
>> default journal plugin and then you would use PersistencePluginProxy.sta
>> rt(system).
>>
>> I hope you need this for testing. PersistencePluginProxy is not intended
>> for production usage.
>>
>> Regards,
>> Patrik
>>
>> On Sat, Aug 6, 2016 at 12:46 AM, oleksiys <kvr...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I have a usecase, where I'd like to be able to move the proxied journal
>>> from one cluster node to another.
>>> Looks like I can redirect all the journal clients using:
>>>
>>> *PersistencePluginProxy.setTargetLocation(someNewLocation)*
>>>
>>> But now on the cluster node, that has to host the journal I need to
>>> actually start the actual journal plugin (considering the default journal
>>> plugin is proxied-journal).
>>> So I need a way to start a non-default journal plugin at runtime.
>>>
>>> The closest I could get to it was:
>>>
>>> *Persistence(system).adaptersFor(journalPluginId)*
>>>
>>> it looks a bit hacky, but unfortunately:
>>>
>>> *Persistence(system).journalFor(journalPluginId)*
>>> *Persistence(system).snapshotStoreFor(snapshotStorePluginId)*
>>>
>>> are all in the private[akka] scope.
>>>
>>> Any suggestions?
>>>
>>> Thank you.
>>>
>>> WBR,
>>> Alexey
>>>
>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>>> urrent/additional/faq.html
>>> >>>>>>>>>> Search the archives: https://groups.google.com/grou
>>> p/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.
>>>
>>
>>
>>
>> --
>>
>> Patrik Nordwall
>> Akka Tech Lead
>> Lightbend <http://www.lightbend.com/> -  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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Re: from akka.persistence.journal.ReplayFilter Invalid replayed event [1] in buffer from old writer

[Patrik Nordwall]

On Mon, Aug 8, 2016 at 10:06 PM, Eric Swenson <e...@swenson.org> wrote:

> We have not changed the default mode=repair-by-discard-old config value
> for the replay-filter.  Should we?  — Eric
>

Then I can't understand how you can get the ERROR as in the first message
in this thread

IllegalStateException: Invalid replayed event [1] in buffer from old writer

Then this should be logged at WARNING level and it should have discarded
the event from the "old" writer.



>
> On Aug 7, 2016, at 9:47 AM, Patrik Nordwall <patrik.nordw...@gmail.com>
> wrote:
>
> It's typically caused by multiple persistent actors with the same
> persistenceId running at the same time. E.g. because there were a network
> split and your cluster was split into two separate clusters and thereby
> starting multiple persistent actors. That is why we so strongly recommend
> against using auto-downing and instead recommend Split Brain Resolver
> <http://doc.akka.io/docs/akka/rp-current/scala/split-brain-resolver.html> or
> similar.
>
> Now you need to cleanup the corrupted data before starting the system.
> http://doc.akka.io/docs/akka/2.4/scala/cluster-sharding.
> html#Removal_of_Internal_Cluster_Sharding_Data
>
> Have you changed the default mode=repair-by-discard-old in the config of
> the replay filter?
> https://github.com/akka/akka/blob/master/akka-persistence/
> src/main/resources/reference.conf#L131
>
> Regards,
> Patrik
>
> On Tue, Aug 2, 2016 at 9:44 PM, Eric Swenson <e...@swenson.org> wrote:
>
>> I'm getting this error consistently now, and don't know why this is
>> happening nor what to do about it.  I form the persistentId this way:
>>
>> override def persistenceId: String = self.path.parent.parent.name +
>> "-" + self.path.name
>>
>> So I don't see how I could have two persisters with the same id.  I'm
>> unable to bring up my akka cluster due to this error.
>>
>> Any suggestions?  I'm running akka 2.4.8 with akka.persistence:
>>
>> journal.plugin = "cassandra-journal"
>> snapshot-store.plugin = "cassandra-snapshot-store"
>>
>>
>> On Monday, April 25, 2016 at 3:34:21 AM UTC-7, Tim Pigden wrote:
>>>
>>> Hi
>>> I'm getting this message. I'm probably doing something wrong but any
>>> idea what that might be? I know what messages I'm persisting and this
>>> particular test is one in which I kill off my persistor and restart it.
>>> Or does it indicate the message is failing to deserialize or something
>>> like that
>>>
>>> 2016-04-25 10:33:47,570 - ERROR - from 
>>> com.optrak.opkakka.ddd.persistence.SimplePersistor Persistence failure when 
>>> replaying events for persistenceId [shd-matrix-testId]. Last known sequence 
>>> number [0]
>>> java.lang.IllegalStateException: Invalid replayed event [1] in buffer from 
>>> old writer [f6bd09c4-1f1c-4710-8cf6-c6f0776f39d3] with persistenceId 
>>> [shd-matrix-testId]
>>>at 
>>> akka.persistence.journal.ReplayFilter$$anonfun$receive$1.applyOrElse(ReplayFilter.scala:125)
>>>at akka.actor.Actor$class.aroundReceive(Actor.scala:480)
>>>at 
>>> akka.persistence.journal.ReplayFilter.aroundReceive(ReplayFilter.scala:50)
>>>
>>>
>>>
>>> Any suggests much appreciated!
>>>
>>>
>>>
>>>
>>>
>> --
>> >>>>>>>>>> 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.
>>
>
>
>
> --
>
> Patrik Nordwall
> Akka Tech Lead
> Lightbend <http://www.lightbend.com/> -  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://gr

Re: [akka-user] Re: from akka.persistence.journal.ReplayFilter Invalid replayed event [1] in buffer from old writer

[Patrik Nordwall]

Great, thanks for the update.
sön 7 aug. 2016 kl. 20:08 skrev Eric Swenson <e...@swenson.org>:

> Thanks, Patrik.  That is precisely what happened. I had been using
> auto-down-unreachable-after, and while this appeared to work fine in the
> normal "rolling update" mode of deploying nodes to our cluster, it had the
> split-brain effects when there were transient cases of unreachability.  I
> have sense replaced the use of the auto-down-unreachable-after with an
> implementation that, upon detecting a MemberUnreachable cluster event,
> queries AWS/ECS to determine whether the node is still present in the
> cluster (and service).  If not, it marks the node down, otherwise, it
> doesn't.  So far, this seems to work just fine.  (And yes, we did clean up
> the duplicate persistence records prior to restarting the cluster).
>
> And yes, I'm aware of the Split Brain Resolver from Lightbend. I'm sure it
> would work well too.  At this point in our journey, where we have no
> revenue and little funds, we're looking primarily to open source and
> roll-our-own solutions. But as we get into production and have customers,
> we'll likely take advantage of Lightbend services and products.
>
> Thanks again. -- Eric
>
>
> On Sunday, August 7, 2016 at 9:48:08 AM UTC-7, Patrik Nordwall wrote:
>
>> It's typically caused by multiple persistent actors with the same
>> persistenceId running at the same time. E.g. because there were a network
>> split and your cluster was split into two separate clusters and thereby
>> starting multiple persistent actors. That is why we so strongly recommend
>> against using auto-downing and instead recommend Split Brain Resolver
>> <http://doc.akka.io/docs/akka/rp-current/scala/split-brain-resolver.html>
>> or similar.
>>
>> Now you need to cleanup the corrupted data before starting the system.
>>
>> http://doc.akka.io/docs/akka/2.4/scala/cluster-sharding.html#Removal_of_Internal_Cluster_Sharding_Data
>>
>> Have you changed the default mode=repair-by-discard-old in the config of
>> the replay filter?
>>
>> https://github.com/akka/akka/blob/master/akka-persistence/src/main/resources/reference.conf#L131
>>
>> Regards,
>> Patrik
>>
> On Tue, Aug 2, 2016 at 9:44 PM, Eric Swenson <er...@swenson.org> wrote:
>>
> I'm getting this error consistently now, and don't know why this is
>>> happening nor what to do about it.  I form the persistentId this way:
>>>
>>> override def persistenceId: String = self.path.parent.parent.name +
>>> "-" + self.path.name
>>>
>>> So I don't see how I could have two persisters with the same id.  I'm
>>> unable to bring up my akka cluster due to this error.
>>>
>>> Any suggestions?  I'm running akka 2.4.8 with akka.persistence:
>>>
>>> journal.plugin = "cassandra-journal"
>>> snapshot-store.plugin = "cassandra-snapshot-store"
>>>
>>>
>>> On Monday, April 25, 2016 at 3:34:21 AM UTC-7, Tim Pigden wrote:
>>>>
>>>> Hi
>>>> I'm getting this message. I'm probably doing something wrong but any
>>>> idea what that might be? I know what messages I'm persisting and this
>>>> particular test is one in which I kill off my persistor and restart it.
>>>> Or does it indicate the message is failing to deserialize or something
>>>> like that
>>>>
>>>> 2016-04-25 10:33:47,570 - ERROR - from 
>>>> com.optrak.opkakka.ddd.persistence.SimplePersistor Persistence failure 
>>>> when replaying events for persistenceId [shd-matrix-testId]. Last known 
>>>> sequence number [0]
>>>> java.lang.IllegalStateException: Invalid replayed event [1] in buffer from 
>>>> old writer [f6bd09c4-1f1c-4710-8cf6-c6f0776f39d3] with persistenceId 
>>>> [shd-matrix-testId]
>>>>at 
>>>> akka.persistence.journal.ReplayFilter$$anonfun$receive$1.applyOrElse(ReplayFilter.scala:125)
>>>>at akka.actor.Actor$class.aroundReceive(Actor.scala:480)
>>>>at 
>>>> akka.persistence.journal.ReplayFilter.aroundReceive(ReplayFilter.scala:50)
>>>>
>>>>
>>>>
>>>> Any suggests much appreciated!
>>>>
>>>>
>>>>
>>>>
>>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >>>>>&g

Re: [akka-user] Re: from akka.persistence.journal.ReplayFilter Invalid replayed event [1] in buffer from old writer

[Patrik Nordwall]

It's typically caused by multiple persistent actors with the same
persistenceId running at the same time. E.g. because there were a network
split and your cluster was split into two separate clusters and thereby
starting multiple persistent actors. That is why we so strongly recommend
against using auto-downing and instead recommend Split Brain Resolver
<http://doc.akka.io/docs/akka/rp-current/scala/split-brain-resolver.html>
or similar.

Now you need to cleanup the corrupted data before starting the system.
http://doc.akka.io/docs/akka/2.4/scala/cluster-sharding.html#Removal_of_Internal_Cluster_Sharding_Data

Have you changed the default mode=repair-by-discard-old in the config of
the replay filter?
https://github.com/akka/akka/blob/master/akka-persistence/src/main/resources/reference.conf#L131

Regards,
Patrik

On Tue, Aug 2, 2016 at 9:44 PM, Eric Swenson <e...@swenson.org> wrote:

> I'm getting this error consistently now, and don't know why this is
> happening nor what to do about it.  I form the persistentId this way:
>
> override def persistenceId: String = self.path.parent.parent.name +
> "-" + self.path.name
>
> So I don't see how I could have two persisters with the same id.  I'm
> unable to bring up my akka cluster due to this error.
>
> Any suggestions?  I'm running akka 2.4.8 with akka.persistence:
>
> journal.plugin = "cassandra-journal"
> snapshot-store.plugin = "cassandra-snapshot-store"
>
>
> On Monday, April 25, 2016 at 3:34:21 AM UTC-7, Tim Pigden wrote:
>>
>> Hi
>> I'm getting this message. I'm probably doing something wrong but any idea
>> what that might be? I know what messages I'm persisting and this particular
>> test is one in which I kill off my persistor and restart it.
>> Or does it indicate the message is failing to deserialize or something
>> like that
>>
>> 2016-04-25 10:33:47,570 - ERROR - from 
>> com.optrak.opkakka.ddd.persistence.SimplePersistor Persistence failure when 
>> replaying events for persistenceId [shd-matrix-testId]. Last known sequence 
>> number [0]
>> java.lang.IllegalStateException: Invalid replayed event [1] in buffer from 
>> old writer [f6bd09c4-1f1c-4710-8cf6-c6f0776f39d3] with persistenceId 
>> [shd-matrix-testId]
>>at 
>> akka.persistence.journal.ReplayFilter$$anonfun$receive$1.applyOrElse(ReplayFilter.scala:125)
>>at akka.actor.Actor$class.aroundReceive(Actor.scala:480)
>>at 
>> akka.persistence.journal.ReplayFilter.aroundReceive(ReplayFilter.scala:50)
>>
>>
>>
>> Any suggests much appreciated!
>>
>>
>>
>>
>> --
> >>>>>>>>>> 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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Why isn't akka PersistenceQuery using the Event Adapter configuration?

[Patrik Nordwall]

This is by design. See discussion in
https://github.com/akka/akka/issues/18050. It should be done in the plugin
implementations where the necessary information is available. I have create
a feature request in the Cassandra plugin.
https://github.com/akka/akka/issues/18050

On Fri, Jul 29, 2016 at 2:55 PM, Konrad Malawski <
konrad.malaw...@lightbend.com> wrote:

> I believe this was by design actually if I remember correctly, as we
> considered the read side may want to operate on the raw events by default.
>
> Let's say that in the same app that needs adapters for the
> PersistentActors you want to project a view from historical data,
> thus you may not want to apply the adapters for example.
>
> It is possible to apply the adapters manually, as I explained here:
> https://github.com/akka/akka/issues/21065
>
> I agree however that it would be nice to make this simpler.
> Ideas and contributions how the API could be improved are very welcome :-)
>
>
>
> --
> Konrad `ktoso` Malawski
> Akka <http://akka.io> @ Lightbend <http://lightbend.com>
>
> On 29 July 2016 at 13:22:30, FCristovao (filipe.md.cristo...@gmail.com)
> wrote:
>
> Hey there,
>
>   Recently I tried out Akka Persistence, and I used a Event Adapter.
>   All works really well on the Journal side, but then I started trying to
> use the PersistenceQuery side, and I noticed that the events in the stream
> come "un-event-adapted", that is, the method "fromJournal" is never called
> on the adapter.
>   And since the EventEnvelope doesn't contain the manifest from
> PersistentRepr, one can't just map the "fromJournal" over the stream.
>
>   Am I missing something? Maybe I misconfigured something? Or is this on
> purpose?
>
> Kind Regards,
>   Filipe Cristóvão
> --
> >>>>>>>>>> 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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Why isn't akka PersistenceQuery using the Event Adapter configuration?

[Patrik Nordwall]

The last link should have been
https://github.com/akka/akka-persistence-cassandra/issues/116

On Sun, Aug 7, 2016 at 6:34 PM, Patrik Nordwall <patrik.nordw...@gmail.com>
wrote:

> This is by design. See discussion in https://github.com/akka/
> akka/issues/18050. It should be done in the plugin implementations where
> the necessary information is available. I have create a feature request in
> the Cassandra plugin. https://github.com/akka/akka/issues/18050
>
> On Fri, Jul 29, 2016 at 2:55 PM, Konrad Malawski <
> konrad.malaw...@lightbend.com> wrote:
>
>> I believe this was by design actually if I remember correctly, as we
>> considered the read side may want to operate on the raw events by default.
>>
>> Let's say that in the same app that needs adapters for the
>> PersistentActors you want to project a view from historical data,
>> thus you may not want to apply the adapters for example.
>>
>> It is possible to apply the adapters manually, as I explained here:
>> https://github.com/akka/akka/issues/21065
>>
>> I agree however that it would be nice to make this simpler.
>> Ideas and contributions how the API could be improved are very welcome :-)
>>
>>
>>
>> --
>> Konrad `ktoso` Malawski
>> Akka <http://akka.io> @ Lightbend <http://lightbend.com>
>>
>> On 29 July 2016 at 13:22:30, FCristovao (filipe.md.cristo...@gmail.com)
>> wrote:
>>
>> Hey there,
>>
>>   Recently I tried out Akka Persistence, and I used a Event Adapter.
>>   All works really well on the Journal side, but then I started trying to
>> use the PersistenceQuery side, and I noticed that the events in the stream
>> come "un-event-adapted", that is, the method "fromJournal" is never called
>> on the adapter.
>>   And since the EventEnvelope doesn't contain the manifest from
>> PersistentRepr, one can't just map the "fromJournal" over the stream.
>>
>>   Am I missing something? Maybe I misconfigured something? Or is this on
>> purpose?
>>
>> Kind Regards,
>>   Filipe Cristóvão
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>> urrent/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/c
>> urrent/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.
>>
>
>
>
> --
>
> Patrik Nordwall
> Akka Tech Lead
> Lightbend <http://www.lightbend.com/> -  Reactive apps on the JVM
> Twitter: @patriknw
>
>


-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Cassandra journal persistence - query on parallelism across persistenceIds

[Patrik Nordwall]

On Wed, Jul 27, 2016 at 8:12 PM, Muthukumaran Kothandaraman <
muthu.kmk2...@gmail.com> wrote:

> Hi,
>
> I would like to understand the possible degree of parallelism in Cassandra
> persistence plugin with Cassandra 3.4.0.
>
> For my usecase, I would be having around 3K distinct peristent actors
> using event-sourced pattern with Akka 2.4.1. I am not using any other
> capabilities like sharding. But 3K actors would be spread across akka
> cluster nodes - all cconnecting to Cassandra cluster for persistence.
>
> I assume events persisted across different persistenceIds can go in
> parallel so that overall event-persistence throughput across actors is
> better.
>

That is correct


> Is Cassandra persistence plugin implemented this way ? Any specific
> configurations I have to be aware of except for possible persistence
> dispatcher tuning ?
>
>
> Regards
> Muthu
>
>
>
>
>
>
>
>
>
> --
> >>>>>>>>>> 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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Dynamically move proxied journal (PersistencePluginProxy) to another node

[Patrik Nordwall]

As far as I can see the PersistencePluginProxy can only be used with the
default journal plugin and then you would
use PersistencePluginProxy.start(system).

I hope you need this for testing. PersistencePluginProxy is not intended
for production usage.

Regards,
Patrik

On Sat, Aug 6, 2016 at 12:46 AM, oleksiys <kvr...@gmail.com> wrote:

> Hi,
>
> I have a usecase, where I'd like to be able to move the proxied journal
> from one cluster node to another.
> Looks like I can redirect all the journal clients using:
>
> *PersistencePluginProxy.setTargetLocation(someNewLocation)*
>
> But now on the cluster node, that has to host the journal I need to
> actually start the actual journal plugin (considering the default journal
> plugin is proxied-journal).
> So I need a way to start a non-default journal plugin at runtime.
>
> The closest I could get to it was:
>
> *Persistence(system).adaptersFor(journalPluginId)*
>
> it looks a bit hacky, but unfortunately:
>
> *Persistence(system).journalFor(journalPluginId)*
> *Persistence(system).snapshotStoreFor(snapshotStorePluginId)*
>
> are all in the private[akka] scope.
>
> Any suggestions?
>
> Thank you.
>
> WBR,
> Alexey
>
> --
> >>>>>>>>>> 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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] If first seed node start failed, the whole cluster will start failed

[Patrik Nordwall]

Yes, that is documented behavior. The reason for the special first seed
node is also documented. What is your question?

Regards,
Patrik
tors 4 aug. 2016 kl. 04:33 skrev Yutao Shuai :

> In a 3-node cluster, all of nodes are seed nodes, if first node start
> failed, the whole cluster can't start successful.
>
> --
> >> 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] Why application.conf doesn't affect substitutions in reference.conf

[Patrik Nordwall]

That is documented behavior.

reference.conf have substitutions resolved first, without application.conf
in the stack, so the reference stack has to be self-contained.

One way to solve it is to do the concatenation of the base url and the
method suffix in code instead.

/Patrik
tors 4 aug. 2016 kl. 10:31 skrev BlueEyed Hush :

> Hello,
>
> I think I don't understand philosophy behind Typesafe Config, and I'd like
> to ask you to help me with that.
> Setup I thought to be natural for Config was:
> * My libraries have reference.conf files with default values
> * My application includes application.conf which overrides those values
> But everything breaks because of the fact that overrides from
> application.conf don't affect substitutions in reference.conf.
>
> Example:
> I've got library which connects to service. Urls are placed in
> reference.conf file, and they use ${service.url}:
>
> service {
>   url = "http://XXX;
>   schema {
> url = ${service.url}/schema
> get.url = ${service.schema.url}/get
> put.url = ${service.schema.url}/put
>   }
>
> }
>
> Now in my application.conf I override service.url, but it doesn't work since 
> substitutions aren't affected and urls are wrong.
>
>
> How should I structure my configuration to handle this scenario?
>
>
> Best wishes,
>
> Chris
>
> --
> >> 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: Performant SequenceID Generation

[Patrik Nordwall]

You're welcome

tis 2 aug. 2016 kl. 19:40 skrev Dagny T :

>
> Thank you, Jim and Patrik for your responses!
>
> Looking into the VersionVector.scala.
> Always amazed at what a good source of learning it is to see
> well-structured, code-reviewed Open Source(!)
>
> THANKS again!
> D
>
> On Thursday, July 28, 2016 at 11:23:46 AM UTC-7, Dagny T wrote:
>>
>>
>> So, in the context of async messaging systems where you can't predict the
>> sequencing of incoming messages.
>>
>> Typically, you have in the message (or event) payload:
>> - an Originating Entity Unique ID
>> - then a Version or Sequence ID for each incremental state-change event
>> on that originating entity
>>
>> So, if I need to initialize EntityID Generation, as well as its sub
>> VersionID Generation across a distributed cluster;
>>
>> Does AKKA provide an out-of-box configurable Sequence ID Generator
>> service cluster?
>> Otherwise, how is this typically handled in AKKA, and where can I get
>> sample code which demonstrates this?
>>
>> THANKS!
>> D
>>
> --
> >> 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: Performant SequenceID Generation

[Patrik Nordwall]

There is a public version vector implementation in akka-distributed-data,
if that is what you are looking for.
https://github.com/akka/akka/blob/master/akka-distributed-data/src/main/scala/akka/cluster/ddata/VersionVector.scala

/Patrik
fre 29 juli 2016 kl. 05:08 skrev Jim Hazen :

> I think what you're looking for here is called a vector clock.  Akka uses
> them internally within its clustering implementation, however the
> implementation isn't public.
>
> There are some open source scala/java implementations you might want to
> evaluate (Google).  I don't have experience with any of them.
>
> The problem is more annoying than it sounds.  You need a causal sequence
> of events (ie, this mutation happened from observation of state x), not
> just an increasing ID.  Vclocks help with that.  But then your app needs to
> deal with merge conflicts and resolution.  Plus your clients need to be
> vclock aware since you pass the current vclock along with your update.
> There are additional issues with vector clocks as well, but you're asking
> to solve a very complex distributed problem.
>
> The Basho guys (developers of the distributed Riak DB) have some good
> material on vclocks.  They've also apparently moved from vclocks to Dotted
> Version Vectors.
>
> If you want to start down the rabbit hole start here:
>
> http://docs.basho.com/riak/kv/2.1.4/learn/concepts/causal-context/#dotted-version-vectors
>
> If you want to take a look at an implementation (and detailed description
> of how it works) start here (the code is in Erlang, but the conceptual
> diagrams of the algorithm are portable to any lang):
> https://github.com/ricardobcl/Dotted-Version-Vectors
>
> --
> >> 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] Cassandra persistence - with Cassandra 2.2.7 + akka-persistence-cassandra-0.7 + akka 2.4.8 - not working

[Patrik Nordwall]

Have you tried version 0.17 with the compat flag described in the readme?
https://github.com/akka/akka-persistence-cassandra/blob/master/README.md

/Patrik
lör 30 juli 2016 kl. 16:56 skrev Justin du coeur :

> I see you got things working, which is great.  I just wanted to caution:
>
> On Sat, Jul 30, 2016 at 8:29 AM, Muthukumaran Kothandaraman <
> muthu.kmk2...@gmail.com> wrote:
>
>> I assume my application.conf below is fine because I do not see any
>> exceptions.
>>
>
> As a rule of thumb, this isn't a safe assumption.  Config-file format is
> weakly typed, remember -- it's just strings -- and it does *not*
> automatically detect errors.  Some mistakes will get caught by the relevant
> libraries, but in general if you make a typo in the name, and the library
> has a default value for that config key, the error will be silently
> ignored...
>
> --
> >> 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-cluster split brain when enable auto-down and set a node random package loss rate 50%

[Patrik Nordwall]

It's one of Lightbend's commercial offerings. Contact Lightbend for more
information and pricing https://www.lightbend.com/contact

lör 23 juli 2016 kl. 06:26 skrev Yutao Shuai <szqs...@gmail.com>:

> Can I use the SBR for free？
>
> 在 2016年7月22日星期五 UTC+8下午10:02:13，Patrik Nordwall写道：
>>
>> Yes, it exists for 2.3.x
>>
> fre 22 juli 2016 kl. 13:01 skrev Yutao Shuai <szq...@gmail.com>:
>>
>>> Can I use split brain resolver in version 2.3.10 ?
>>>
>>> 在 2016年7月22日星期五 UTC+8下午6:08:22，Akka Team写道：
>>>>
>>>> Hi Yutao,
>>>>
>>>> Please refer to the documentation page Patrik has linked. It explains
>>>> the problem in detail and various approaches to handle it. SBR is available
>>>> for Lightbend customers and provides ready-made solutions (the linked
>>>> pages), but if you want to go with the open source version, you can
>>>> implement similar strategies yourself.
>>>>
>>>> -Endre
>>>>
>>>
>>>> On Fri, Jul 22, 2016 at 11:18 AM, Yutao Shuai <szq...@gmail.com> wrote:
>>>>
>>>>> The result we expected is divide into two cluster, one of the cluster
>>>>> has three or four nodes and work normally.
>>>>>
>>>>> 在 2016年7月22日星期五 UTC+8下午3:41:32，√写道：
>>>>>>
>>>>>> What behavior are you looking to achieve?
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> √
>>>>>>
>>>>>> On Jul 22, 2016 5:11 AM, "Yutao Shuai" <szq...@gmail.com> wrote:
>>>>>>
>>>>>>>   In a 5-node cluster, hypothesis the nodes is A,B,C,D,E. All nodes
>>>>>>> monitor each other, enable auto-down,  and we  set the node-A random
>>>>>>> package loss rate 50%,  after a period of time, the cluster
>>>>>>>   will divide into two or more clusters. How can I fix this problem?
>>>>>>>
>>>>>>> --
>>>>>>> >>>>>>>>>> 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-user.
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>> Akka Team
>>>> Lightbend <http://www.lightbend.com/> - Reactive apps on the JVM
>>>> Twitter: @akkateam
>>>>
>>> --
>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>> >>>>>>>>>> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >>>>>>>>>> Search the archives:
>>> https

Re: [akka-user] akka-cluster split brain when enable auto-down and set a node random package loss rate 50%

[Patrik Nordwall]

Yes, it exists for 2.3.x
fre 22 juli 2016 kl. 13:01 skrev Yutao Shuai :

> Can I use split brain resolver in version 2.3.10 ?
>
> 在 2016年7月22日星期五 UTC+8下午6:08:22，Akka Team写道：
>>
>> Hi Yutao,
>>
>> Please refer to the documentation page Patrik has linked. It explains the
>> problem in detail and various approaches to handle it. SBR is available for
>> Lightbend customers and provides ready-made solutions (the linked pages),
>> but if you want to go with the open source version, you can implement
>> similar strategies yourself.
>>
>> -Endre
>>
>
>> On Fri, Jul 22, 2016 at 11:18 AM, Yutao Shuai  wrote:
>>
>>> The result we expected is divide into two cluster, one of the cluster
>>> has three or four nodes and work normally.
>>>
>>> 在 2016年7月22日星期五 UTC+8下午3:41:32，√写道：

 What behavior are you looking to achieve?

 --
 Cheers,
 √

 On Jul 22, 2016 5:11 AM, "Yutao Shuai"  wrote:

>   In a 5-node cluster, hypothesis the nodes is A,B,C,D,E. All nodes
> monitor each other, enable auto-down,  and we  set the node-A random
> package loss rate 50%,  after a period of time, the cluster
>   will divide into two or more clusters. How can I fix this problem?
>
> --
> >> 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-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>>
> Akka Team
>> Lightbend  - Reactive apps on the JVM
>> Twitter: @akkateam
>>
> --
> >> 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: Akka Cluster + Leveldb : Persistence failure when replaying events for ...

[Patrik Nordwall]

That is a setup that is not supported. It's clearly documented that it's
not intended for production usage.

/Patrik
fre 22 juli 2016 kl. 03:13 skrev Manoj Santhakumaran <manojnai...@gmail.com
>:

> Hi Patrik,
>
> Thank you very much for your reply.
>
> Correct me if I'm wrong. By "single point of failure" what I meant was, in
> case of any failure in the primary node, the events which is not yet
> persisted in the leveldb will be lost. But the events which is already
> persisted should be available in the leveldb (since it is in disk file).
> The leveldb store is shared by second node in the cluster through NFS
> mount. When primary is down, cann't we start the "SharedLeveldbStore" in
> the second node on receipt of "MemberRemoved/MemberExited" cluster events?
>
> Thanks,
> Manoj
>
>
> On Wednesday, 20 July 2016 23:37:55 UTC-7, Patrik Nordwall wrote:
>
>> SharedLeveldbJournal is not resillient. It's a single point of failure
>> since it is only running on one node. It's only intended for demo examples.
>> Please use a real distributed jounal, such as akka-persistence-cassandra
>>
>> /Patrik
>>
> tors 21 juli 2016 kl. 01:24 skrev Manoj Santhakumaran <manoj...@gmail.com
>> >:
>>
> Hi All,
>>>
>>> Today I analyzed by consuming cluster events.
>>> When first node is down, I got only an UnreachableMember event. I was
>>> expecting a MemberRemoved or MemberExited event after UnreachableMember. Is
>>> that correct? I didn't get either of them.
>>>
>>> Is this because I have only two nodes in the cluster and no one alive in
>>> first node to send out a MemberRemoved or MemberExited?
>>>
>>> I have attached here the logs of node 2 when node 1 goes down.
>>>
>>> Any suggestions/pointers on how we can enable proper fail-over when
>>> primary node crashed?
>>>
>>> Thanks and regards,
>>> Manoj
>>>
>>>
>>>
>>> On Tuesday, 19 July 2016 13:05:55 UTC-7, Manoj Santhakumaran wrote:
>>>>
>>>> Hi All,
>>>>
>>>> I'm facing following problem with my Akka cluster environment which has
>>>> two nodes, and Akka persistence using leveldb-journal.
>>>>
>>>> Both nodes are started with "ClusterSingletonManager" and
>>>> "ClusterSingletonProxy". My "UntypedPersistentActor" is started as
>>>> "ClusterClientReceptionist". In my first node, I'm starting the
>>>> "SharedLeveldbStore" and setting that by
>>>> "SharedLeveldbJournal.setStore(...)" call. But in second node, I'm only
>>>> setting "SharedLeveldbJournal.setStore(..)" of the first node when starts
>>>> up.
>>>>
>>>> When both nodes are running, everything works fine.
>>>>
>>>> But when the first node died, I was expecting the second node takes up
>>>> the charge and replay the persisted events. But it is throwing following
>>>> exception in the logs and became zombie (process is running but not doing
>>>> its job). I noticed that the "postStop" event handler of my
>>>> "UntypedPersistentActor" is called after this error.
>>>>
>>>> ERROR | 2016-07-19 11:37:24 |
>>>> [ClusterSystem-akka.actor.default-dispatcher-18] ? -
>>>> [sourceThread=ClusterSystem-akka.actor.default-dispatcher-18,
>>>> sourceActorSystem=ClusterSystem,
>>>> akkaSource=akka.tcp://ClusterSystem@hostname2:2552/user/master/singleton,
>>>> akkaTimestamp=18:37:24.195UTC] - Persistence failure when replaying events
>>>> for persistenceId [master]. Last known sequence number [0]
>>>> akka.pattern.CircuitBreaker$$anon$1: Circuit Breaker Timed out.
>>>>
>>>> My environment : Play (2.4.0), Akka (2.4.4), Akka Persistence (2.3.9),
>>>> Leveldb (0.7), Leveldb-Jni (1.8)
>>>>
>>>> My application.conf have following cluster configuration.
>>>>
>>>>   extensions = ["akka.cluster.client.ClusterClientReceptionist"]
>>>>   cluster {
>>>>   seed-nodes = [
>>>> "akka.tcp://ClusterSystem@hostname1:2551",
>>>> "akka.tcp://ClusterSystem@hostname2:2552"]
>>>>   }
>>>>   persistence {
>>>> journal.plugin = "akka.persistence.journal.leveldb-shared"
>>>> journal.leveldb-shared.store {
>>>>   # This is non-prod

Re: [akka-user] Re: Akka Cluster + Leveldb : Persistence failure when replaying events for ...

[Patrik Nordwall]

SharedLeveldbJournal is not resillient. It's a single point of failure
since it is only running on one node. It's only intended for demo examples.
Please use a real distributed jounal, such as akka-persistence-cassandra

/Patrik
tors 21 juli 2016 kl. 01:24 skrev Manoj Santhakumaran :

> Hi All,
>
> Today I analyzed by consuming cluster events.
> When first node is down, I got only an UnreachableMember event. I was
> expecting a MemberRemoved or MemberExited event after UnreachableMember. Is
> that correct? I didn't get either of them.
>
> Is this because I have only two nodes in the cluster and no one alive in
> first node to send out a MemberRemoved or MemberExited?
>
> I have attached here the logs of node 2 when node 1 goes down.
>
> Any suggestions/pointers on how we can enable proper fail-over when
> primary node crashed?
>
> Thanks and regards,
> Manoj
>
>
>
> On Tuesday, 19 July 2016 13:05:55 UTC-7, Manoj Santhakumaran wrote:
>>
>> Hi All,
>>
>> I'm facing following problem with my Akka cluster environment which has
>> two nodes, and Akka persistence using leveldb-journal.
>>
>> Both nodes are started with "ClusterSingletonManager" and
>> "ClusterSingletonProxy". My "UntypedPersistentActor" is started as
>> "ClusterClientReceptionist". In my first node, I'm starting the
>> "SharedLeveldbStore" and setting that by
>> "SharedLeveldbJournal.setStore(...)" call. But in second node, I'm only
>> setting "SharedLeveldbJournal.setStore(..)" of the first node when starts
>> up.
>>
>> When both nodes are running, everything works fine.
>>
>> But when the first node died, I was expecting the second node takes up
>> the charge and replay the persisted events. But it is throwing following
>> exception in the logs and became zombie (process is running but not doing
>> its job). I noticed that the "postStop" event handler of my
>> "UntypedPersistentActor" is called after this error.
>>
>> ERROR | 2016-07-19 11:37:24 |
>> [ClusterSystem-akka.actor.default-dispatcher-18] ? -
>> [sourceThread=ClusterSystem-akka.actor.default-dispatcher-18,
>> sourceActorSystem=ClusterSystem,
>> akkaSource=akka.tcp://ClusterSystem@hostname2:2552/user/master/singleton,
>> akkaTimestamp=18:37:24.195UTC] - Persistence failure when replaying events
>> for persistenceId [master]. Last known sequence number [0]
>> akka.pattern.CircuitBreaker$$anon$1: Circuit Breaker Timed out.
>>
>> My environment : Play (2.4.0), Akka (2.4.4), Akka Persistence (2.3.9),
>> Leveldb (0.7), Leveldb-Jni (1.8)
>>
>> My application.conf have following cluster configuration.
>>
>>   extensions = ["akka.cluster.client.ClusterClientReceptionist"]
>>   cluster {
>>   seed-nodes = [
>> "akka.tcp://ClusterSystem@hostname1:2551",
>> "akka.tcp://ClusterSystem@hostname2:2552"]
>>   }
>>   persistence {
>> journal.plugin = "akka.persistence.journal.leveldb-shared"
>> journal.leveldb-shared.store {
>>   # This is non-prod
>>   native = off
>>   dir = "/shared-vol1/leveldb-journal"
>> }
>> snapshot-store.plugin = "akka.persistence.snapshot-store.local"
>> snapshot-store.local.dir = "target/snapshots"
>>   }
>>
>> I appreciate any solution/suggestion/pointer to resolve this issue.
>>
>> Thank you very much.
>> Manoj
>>
>> --
> >> 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 Streams as an ETL tool?

[Patrik Nordwall]

Akka Streams is an excellent choice for this use case. I would even say
that it is the canonical use case for Akka Streams. We have probably not
highlighted that enough, yet.

Cheers,
Patrik
tors 14 juli 2016 kl. 13:22 skrev James Matlik :

> Using Akka streams for ETL is our primary use case. The back pressure
> support has been extremely useful in helping us maximize throughout while
> at the same time avoid overwhelming the multiple external rest services we
> query against. By maintaining dedicated, fixed sized dispatcher pools, we
> can easily use our legacy blocking client SDKs over a fixed max number of
> concurrent connections/requests. Then the ETL can process as fast as it
> possibly can within those constraints.
>
> We found the learning curve to be on the steep side, but once it clicks,
> the power and ease of use Streams provides is... impressive...
> refreshing... exhilarating... addicting.. take your pick.
>
> On Jul 14, 2016 12:28 AM, "Beno"  wrote:
>
>> Ive been using Akka streaming for a use case which I dont see much about
>> - that of a small/moderate scale ETL or simple processing pipeline. Im
>> relatively new to it all, so I just wanted to see if I might be missing
>> something that would change my opinion, which is that Akka Streams is among
>> the best tools for data cleaning--  the graph dsl is so easy to code with
>> and reason about.
>>
>> The details: Batch processing to clean and curate data, with external
>> calls RESTful requests as part of the flow.
>>
>> Source[A] (read from file or DB) ~> Flow[A,B](some transformation
>> function) ~>  Flow[B,C] (by way of a RESTful request/response) ~>
>> Flow[C,D](graph query) ~> Sink[D](to DB)
>>
>> Where Source might be 50,000 lines in a file or rows in a table.
>>
>> Thanks for any feedback
>>
>> --
>> >> 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.
>

-- 
>>  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] ANNOUNCE: New Remoting Milestone 3

[Patrik Nordwall]

Dear hakkers,


We are pleased to announce the availability of the third development
milestone of the new Akka Remoting, codenamed 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-M3 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 M3 compared to M2
<https://groups.google.com/d/msg/akka-user/tn6OB_NWaHE/K9PG-NT8QQAJ>::



   -

   compression of sender and recipient actor references in the message
   envelope header, explained below
   -

   performance improvements, results below
   -

   various bug fixes, all relevant remoting tests are now passing


The full list of changes since the last milestone is available under the
2.4-ARTERY-M3 <https://github.com/akka/akka/milestone/90?closed=1>
milestone on github for your reference.


The most exciting new feature in this milestone is the envelope header
compression. For small messages the sender and recipient Actor references
that are included in each remote message can be a large fraction of the
total payload since they are encoded as string representation of the full
ActorPath and the Actor’s UID. To reduce the message header size we have
developed a smart compression algorithm. The most commonly used sender and
recipient refs are detected by the recipient system and announced as a
compression table to the sender system. Then the sender can encode those
actor references as integers indexing the announced compression table. The
same thing is also done for serialization manifest strings. Overall
allowing us to save up to hundreds of bytes per message that would have
otherwise have be transferred over the wire (costing time and resources).


Another thing that some of you might find interesting is performance. We
have now measured the following between two m4.4xlarge EC2 instances (1
Gbit/s bandwidth) using the MaxThroughputSpec
<https://github.com/akka/akka/blob/v2.4-ARTERY-M3/akka-remote-tests/src/multi-jvm/scala/akka/remote/artery/MaxThroughputSpec.scala>
and LatencySpec
<https://github.com/akka/akka/blob/v2.4-ARTERY-M3/akka-remote-tests/src/multi-jvm/scala/akka/remote/artery/LatencySpec.scala>
:



   -

   630,239 messages/s with message payload of 100 bytes
   -

   8,245 messages/s with messages payload of 10,000 bytes
   -

   Round trip latency at a message rate of 10,000 messages/s: 50%ile: 155
   µs, 90%ile: 173 µs, 99%ile: 196 µs


We are using Aeron <https://github.com/real-logic/Aeron> as the underlying
transport and are implementing the layers on top using Akka Streams. You
find more details in the design document
<https://github.com/akka/akka-meta/issues/16>.


The development branch is artery-dev
<https://github.com/akka/akka/tree/artery-dev>, in case you want to take a
look or contribute. Issues are labeled with t:remoting:artery
<https://github.com/akka/akka/issues?q=is%3Aopen+is%3Aissue+label%3At%3Aremoting%3Aartery>
.


We are now taking a “summer break” from Artery development. We don’t only
need vacation, but we also have some other important areas to work on
before finalizing Artery. You find our  sprint plans at akka/akka-meta
<https://github.com/akka/akka-meta/issues>. The goal is to complete Artery
in end of August and September and then release it in a 2.4.x version of
Akka as an optional transport.


Happy hakking!

-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Re: node cannot automatically rejoin Cluster after seed node restarted

[Patrik Nordwall]

When you restart node A it will join itself and form a separate cluster,
since you have not configured node B in the list of seed nodes.

You are not using any downing strategy
<http://doc.akka.io/docs/akka/2.4.7/scala/cluster-usage.html#Automatic_vs__Manual_Downing>
so node B will not remove node A.

Cheers,
Patrik

On Fri, Jul 8, 2016 at 12:13 PM, 谌浏洋 <shenliuy...@gmail.com> wrote:

> I had the same problem
>
> --
> >>>>>>>>>> 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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] How to find Oldest node in Akka Cluster Singleton

[Patrik Nordwall]

You have to restart the ActorSystem (or JVM)

tis 5 juli 2016 kl. 12:51 skrev Madabhattula Rajesh Kumar <
mrajaf...@gmail.com>:

> Thank you Patrik for the details. I am using isOlderThan method. It is
> working.
>
> I have an another query :-
>
>- How to restart the cluster? Do we have a API for that?
>
> Regards,
> Rajesh
>
>
>
>
> On Monday, July 4, 2016 at 12:08:38 PM UTC+5:30, Patrik Nordwall wrote:
>
>> Normally you would use the ClusterSingletonProxy, but if you want to
>> subscribe to the membership events and sort them you can use
>> Member. ageOrdering
>> <https://github.com/akka/akka/blob/master/akka-cluster/src/main/scala/akka/cluster/Member.scala#L130>
>>  or
>> isOlderThan
>> <https://github.com/akka/akka/blob/master/akka-cluster/src/main/scala/akka/cluster/Member.scala#L46>
>> .
>>
>> /Patrik
>>
> On Sat, Jul 2, 2016 at 8:20 PM, Madabhattula Rajesh Kumar <
>> mraj...@gmail.com> wrote:
>>
> Hi,
>>>
>>> In  akka cluster singleton how to find "Oldest" node details.
>>>
>>> Regards,
>>> Rajesh
>>>
>> --
>>> >>>>>>>>>> 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.
>>>
>>
>>
>>
>> --
>>
>> Patrik Nordwall
>> Akka Tech Lead
>> Lightbend <http://www.lightbend.com/> -  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.
>

-- 
>>>>>>>>>>  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 cluster + sharding + persistence: LeaderChanged twice in very short time

[Patrik Nordwall]

On Fri, Jul 1, 2016 at 6:50 PM, Daniel Lopes <daniel.lo...@boxever.com>
wrote:

> Apologies, that last comment was a bit ambiguous.
> The slow down might be the result of quite a few moving pieces, not
> necessarily cluster sharding related - but that's what I'm trying to find
> out :)
>
> Each node reads from kafka (dedicated partition), fetches some
> intermediary data from cassandra, passes the data to it's pertaining shard
> and gets persisted to cassandra.
>
> So each node keeps metrics on the current committed offset that was
> consumed and when the leader node is restarted, the offset metrics from the
> remaining nodes don't move forward ("kafka lag") until the leader node
> resumed it's activity.
>
> This can also be caused by kafka consumer rebalance, although I did not
> observe the same amount of kafka lag when another node is restarted.
>
> I suspect that the leader node is also the coordinator node (by
> coincidence) hence my previous assumption that there was a relation between
> the too, leading me to believe that the shard handoff is in limbo.
>
> Is it possible to subscribe to sharding related messages just like cluster
> messages? That might help me figure out what's happening.
>

You can enable debug level logging. Cluster Sharding logs things in great
detail.
akka.loglevel = DEBUG

/Patrik


>
> On Friday, 1 July 2016 15:16:00 UTC+1, Patrik Nordwall wrote:
>>
>>
>>
>> On Thu, Jun 30, 2016 at 5:47 PM, Daniel Lopes <daniel...@boxever.com>
>> wrote:
>>
>>> Using:
>>> * Akka 2.4.6 project
>>> * with cluster sharding
>>> * Cassandra persistence
>>> * Reactive Kafka Consumer
>>>
>>> Setup:
>>> * 5 nodes
>>> * 4 nodes consume from kafka
>>> * 1 node in standby
>>> * each node has cluster persistence and persistence for two other kind
>>> of entities
>>> * one entity is setup for 256 shard per node
>>> * remember entities is on
>>> * subscribing to and logging LeaderChanged cluster messages
>>>
>>> When performing a rolling release each node
>>> * is brought down,
>>> * project upgraded
>>> * started back up
>>> * waits 5min before moving to the next node
>>>
>>> The situation is that when the leader node is restarted, leadership goes
>>> from Node 1 to Node 2 and around 10s later leadership goes back to Node 1
>>> again.
>>>
>>
>> That is expected. The leader, that performs some of the cluster
>> membership management tasks, is simply the node with the lowest address
>> (sorted by host:port alphabetically) with some additional rules around
>> membership status and reachability status.
>>
>>
>>>
>>> Can anybody tell me if this behaviour affects sharding
>>> hand-off/rebalancing?
>>>
>>
>> No. The Cluster Sharding coordinator is a Cluster Singleton that is
>> running on the oldest node, which has nothing to do with the membership
>> leader. When restarting the coordinator node (oldest) you should also not
>> see much impact, because the the locations of the shards are cached on each
>> other node when they have been in use.
>>
>>
>>> Is there a way to keep leadership from flopping back and forth?
>>>
>>> The whole cluster slows downs during this situation and I'm concerned it
>>> might get worse as the  load grows.
>>>
>>
>> What do you mean by "whole cluster slows down"? What do you observe?
>>
>> Cheers,
>> Patrik
>>
>>
>>>
>>> --
>>> >>>>>>>>>> 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.
>>>
>>
>>
>>
>> --
>>
>> Patrik Nordwall
>> Akka Tech Lead
>> Lightbend <http://www.lightbend.com/> -  Reactive apps on the JVM
>> Tw

Re: [akka-user] LEAK: You are creating too many HashedWheelTimer instances

[Patrik Nordwall]

Could it be that these are created by Netty via Cassandra client driver via
akka-persistence-cassandra? You can try to add "ch.qos.logback" %
"logback-classic" % "1.1.3" dependency and enable logging in logback.xml
for


That might show you what the Cassandra driver is doing, e.g. scheduling
reconnects or something.

/Patrik

On Fri, Jul 1, 2016 at 7:59 PM, Yan Pei <yan@gmail.com> wrote:

> We run this application via a scheduler, every three hours. We did
> shutdown ActorSystem at the end of each run and restart ActorSystem at the
> beginning of each run. Will it cause problem?
>
> Thanks,
> Yan
>
> On Friday, July 1, 2016 at 12:47:45 PM UTC-5, √ wrote:
>>
>> I would suspect that you may be creating new ActorSystem instances
>> instead of reusing a single one.
>>
>> --
>> Cheers,
>> √
>> On Jul 1, 2016 7:05 PM, "Yan Pei" <yan...@gmail.com> wrote:
>>
>>> Hello All,
>>>
>>>   I am using AKKA 2.4.4 and Cassandra 2.x.
>>>   Today I found there is an error from the thread of
>>> 'actor-system-cassndra-plugin-default-dispatcher-380':
>>>
>>> LEAK: You are creating too many HashedWheelTimer instances.
>>> HashedWheelTimer is a shared resource that must be reused across the JVM
>>> ,so that only a few instances are created.
>>>
>>> Could anybody give me an hint which part cause the error? AKKA or
>>> Canssandra? How to fix it?
>>>
>>> Thanks,
>>> Yan
>>>
>>>
>>>
>>>
>>>
>>> --
>>> >>>>>>>>>> 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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] Bad example in documentation

[Patrik Nordwall]

Thanks for reporting. Could you please open a pull request with the fix?
Regards,
Patrik

On Sat, Jul 2, 2016 at 12:31 AM, Sergey Sopin <sopin1...@gmail.com> wrote:

> Hi,
>
> It seems that one of examples in the documentation contains bug, namely:
> http://doc.akka.io/docs/akka/2.4.7/java/stream/stream-graphs.html
>
>
>1. final Source<Integer, NotUsed> in = Source.from(Arrays.asList(1, 2,
>3, 4, 5));
>2. final Sink<List, CompletionStage<List>> sink = Sink.
>head();
>3. final Sink<List, CompletionStage<List>> sink2 =
>Sink.head();
>4. final Flow<Integer, Integer, NotUsed> f1 = Flow.of(Integer.class).
>map(elem -> elem + 10);
>5. final Flow<Integer, Integer, NotUsed> f2 = Flow.of(Integer.class).
>map(elem -> elem + 20);
>6. final Flow<Integer, String, NotUsed> f3 = Flow.of(Integer.class).map
>(elem -> elem.toString());
>7. final Flow<Integer, Integer, NotUsed> f4 = Flow.of(Integer.class).
>map(elem -> elem + 30);
>8.
>9. final RunnableGraph<CompletionStage<List>> result =
>10.  RunnableGraph.<CompletionStage<List>>fromGraph(
>11.GraphDSL
>12.  .create(
>13.sink,
>14.(builder, out) -> {
>15.  final UniformFanOutShape<Integer, Integer> bcast = builder
>.add(Broadcast.create(2));
>16.  final UniformFanInShape<Integer, Integer> merge = builder.
>add(Merge.create(2));
>17.
>18.   final Outlet source = builder.add(in).out();
>19.  builder.from(source).via(builder.add(f1))
>20..viaFanOut(bcast).via(builder.add(f2)).viaFanIn(merge)
>21..via(builder.add(f3.grouped(1000))).to(out);
>22.  builder.from(bcast).via(builder.add(f4)).toFanIn(merge);
>23.  return ClosedShape.getInstance();
>24.}));
>
>
> Here we define 'sink2' variable, but never use it. We are using 'out'
> variable instead, which is undefined.
> Please fix this confusing thing when it will be possible.
>
> Thanks,
> Sergey
>
> --
> >>>>>>>>>> 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.
>



-- 

Patrik Nordwall
Akka Tech Lead
Lightbend <http://www.lightbend.com/> -  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] min-nr-of-members not working?

[Patrik Nordwall]

The sample doesn't have those settings, but i added them for two roles and
I could see from the MemberUp logging that it was working
mån 4 juli 2016 kl. 11:08 skrev Raymond Roestenburg <
raymond.roestenb...@gmail.com>:

> That does not seem to solve the issue, I'll check out the
> akka-sample-cluster-scala to see what you're doing differently there..
>
>
> On Sunday, July 3, 2016 at 8:45:25 PM UTC+2, Raymond Roestenburg wrote:
>>
>> Thanks Patrik, I'll try that.
>>
>> On Friday, July 1, 2016 at 8:32:27 AM UTC+2, Patrik Nordwall wrote:
>>>
>>> I have verified that it works as expected with
>>> the akka-sample-cluster-scala.
>>>
>>> I think the problem is that you have not defined the same min-nr-of-members
>>> in all config files. seed.config only contains seed.min-nr-of-members
>>>
>>> /Patrik
>>>
>>> On Thu, Jun 30, 2016 at 2:47 PM, Raymond Roestenburg <
>>> raymond.r...@gmail.com> wrote:
>>>
>>>> (Copy from gitter)
>>>>
>>>> Hey guys, I don’t think 'min-nr-of-members’ in cluster works anymore,
>>>> I’ve got an example where I would expect the registerOnMemberUp to not get
>>>> called until two ‘worker’ role nodes are up, but it gets called anyway.
>>>> Example is here at
>>>> https://github.com/RayRoestenburg/akka-in-action/tree/master/chapter-cluster
>>>> .
>>>>
>>>> I you would like to try:
>>>>
>>>> run sbt assembly, start a 'seed' with
>>>> java -DPORT=2551 -Dconfig.resource=/seed.conf -jar target/words-node.jar
>>>> And a 'master’ with
>>>> java -DPORT=2554 -Dconfig.resource=/master.conf -jar
>>>> target/words-node.jar
>>>> Since worker.min-nr-of-members = 2 is set, I would expect the master
>>>> not to get up, but it does.
>>>> (Am I doing something wrong?)
>>>>
>>>> Cheers,
>>>> Ray
>>>>
>>>> --
>>>> >>>>>>>>>> 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.
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Patrik Nordwall
>>> Akka Tech Lead
>>> Lightbend <http://www.lightbend.com/> -  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.
>

-- 
>>>>>>>>>>  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] Is it possible to increase the number of serialization threads?

[Patrik Nordwall]

On Mon, Jul 4, 2016 at 9:13 AM, Eduardo Fernandes <edu...@gmail.com> wrote:

> Wow!!! I have to try the new remoting!
>
> The measurement is quite basic: I have a pool of threads and I just call
> the sends() and wait for the response and execute a new send. Nothing
> particular. I made a simple test with the old remote and my numbers were
> also around 25.000 msg/s, so we agree on that. On top of the old remote, on
> my local machine (4 cores) I set the client and the server and I get around
> 300.000 msg/s (really are 600.000 because we have cli->server and other
> server->client response). So I could expect a very good enhancement if we
> move to Artery.
>
> The limitation in my machine is CPU, not network, of course, because all
> operations go through the loopback virtual card, which is a lot faster than
> the real card. The CPU is high because of serialization.
>
> In your test of 700.000 does this include a response from the server (or
> remote peer or whatever)?
>

No, that's one-way between two JVMs. Flow control is handled by one ack per
batch of 1000 messages (several of these batches in flight).


>
> Thanks.
>
>
> On Mon, Jul 4, 2016 at 9:03 AM, Patrik Nordwall <patrik.nordw...@gmail.com
> > wrote:
>
>> Then I question how you measure this in your benchmark. With old
>> (current) remoting I have observed max throughput of 25.000 msg/s (one way)
>> using this test:
>> https://github.com/akka/akka/blob/artery-dev/akka-remote-tests/src/multi-jvm/scala/akka/remote/artery/MaxThroughputSpec.scala
>>
>> With new remoting (Artery) that test performs around 700.000 msg/s on my
>> local machine.
>>
>>
>> On Mon, Jul 4, 2016 at 8:54 AM, Eduardo Fernandes <edu...@gmail.com>
>> wrote:
>>
>>> Yes... 1.000.000 messages over the network (1.000.000 sent and 1.000.000
>>> of ack's with the operation state, in this case a single echo). Sorry, I
>>> was not precise on that. We call it transaction becase we make a kind of
>>> commit in ram but in this case it is not relevant.
>>>
>>> On Mon, Jul 4, 2016 at 8:51 AM, Patrik Nordwall <
>>> patrik.nordw...@gmail.com> wrote:
>>>
>>>> Are you talking about 1.000.000 (500.000) messages/s over the network
>>>> or what is your definition of transaction?
>>>>
>>>> On Mon, Jul 4, 2016 at 8:47 AM, Eduardo Fernandes <edu...@gmail.com>
>>>> wrote:
>>>>
>>>>> Many thanks Patrik. I'll share it with our dev team. I've read it when
>>>>> we have indeed to change our code a bit. If we can distribute the
>>>>> serialization across the processors I'm pretty sure we could achieve 
>>>>> around
>>>>> 1.000.000 transactions/s in an 8 cores machine with 4 or 5 actors on each
>>>>> node. Right now I have around 500.000 with 2 actors but increasing the
>>>>> number of actors is not increasing the numbers as we should expect. The
>>>>> network bandwidth is not the problem and I have around 48% of CPU in idle
>>>>> state.
>>>>>
>>>>> Regards and thanks again for the info.
>>>>>
>>>>> On Mon, Jul 4, 2016 at 7:56 AM, Patrik Nordwall <
>>>>> patrik.nordw...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Jul 4, 2016 at 12:09 AM, Eduardo Fernandes <edu...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Ok. I'll manage to change from 2.10 to 2.11. Yes, my project is in
>>>>>>> Java. We're using Java 8 but the transition to 2.4 is not direct since
>>>>>>> we've overriden some behaviors in 2.3 which changed in 2.4 ( for ex.
>>>>>>> AllocationStrategy). I've tried to change to 2.4 and I got many errors.
>>>>>>>
>>>>>>
>>>>>> Updating to 2.4 is a good idea, since OSS version of 2.3 is
>>>>>> end-of-life. You find the migration guide here:
>>>>>> http://doc.akka.io/docs/akka/2.4.7/project/migration-guide-2.3.x-2.4.x.html
>>>>>>
>>>>>> I would like to clarify one thing regarding the release of the new
>>>>>> remoting (Artery). We are still developing it and we are releasing
>>>>>> development milestones that you can try out. M3 to be released end of 
>>>>>> next
>>>>>> week according to the plan
>>>>>> <https://github.com/akka/akka-meta/issues/22>. It w

Re: [akka-user] Is it possible to increase the number of serialization threads?

[Patrik Nordwall]

Then I question how you measure this in your benchmark. With old (current)
remoting I have observed max throughput of 25.000 msg/s (one way) using
this test:
https://github.com/akka/akka/blob/artery-dev/akka-remote-tests/src/multi-jvm/scala/akka/remote/artery/MaxThroughputSpec.scala

With new remoting (Artery) that test performs around 700.000 msg/s on my
local machine.


On Mon, Jul 4, 2016 at 8:54 AM, Eduardo Fernandes <edu...@gmail.com> wrote:

> Yes... 1.000.000 messages over the network (1.000.000 sent and 1.000.000
> of ack's with the operation state, in this case a single echo). Sorry, I
> was not precise on that. We call it transaction becase we make a kind of
> commit in ram but in this case it is not relevant.
>
> On Mon, Jul 4, 2016 at 8:51 AM, Patrik Nordwall <patrik.nordw...@gmail.com
> > wrote:
>
>> Are you talking about 1.000.000 (500.000) messages/s over the network or
>> what is your definition of transaction?
>>
>> On Mon, Jul 4, 2016 at 8:47 AM, Eduardo Fernandes <edu...@gmail.com>
>> wrote:
>>
>>> Many thanks Patrik. I'll share it with our dev team. I've read it when
>>> we have indeed to change our code a bit. If we can distribute the
>>> serialization across the processors I'm pretty sure we could achieve around
>>> 1.000.000 transactions/s in an 8 cores machine with 4 or 5 actors on each
>>> node. Right now I have around 500.000 with 2 actors but increasing the
>>> number of actors is not increasing the numbers as we should expect. The
>>> network bandwidth is not the problem and I have around 48% of CPU in idle
>>> state.
>>>
>>> Regards and thanks again for the info.
>>>
>>> On Mon, Jul 4, 2016 at 7:56 AM, Patrik Nordwall <
>>> patrik.nordw...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Jul 4, 2016 at 12:09 AM, Eduardo Fernandes <edu...@gmail.com>
>>>> wrote:
>>>>
>>>>> Ok. I'll manage to change from 2.10 to 2.11. Yes, my project is in
>>>>> Java. We're using Java 8 but the transition to 2.4 is not direct since
>>>>> we've overriden some behaviors in 2.3 which changed in 2.4 ( for ex.
>>>>> AllocationStrategy). I've tried to change to 2.4 and I got many errors.
>>>>>
>>>>
>>>> Updating to 2.4 is a good idea, since OSS version of 2.3 is
>>>> end-of-life. You find the migration guide here:
>>>> http://doc.akka.io/docs/akka/2.4.7/project/migration-guide-2.3.x-2.4.x.html
>>>>
>>>> I would like to clarify one thing regarding the release of the new
>>>> remoting (Artery). We are still developing it and we are releasing
>>>> development milestones that you can try out. M3 to be released end of next
>>>> week according to the plan
>>>> <https://github.com/akka/akka-meta/issues/22>. It will be merged back
>>>> to 2.4 and released in a 2.4.x version, but that will not happen next week.
>>>>
>>>> /Patrik
>>>>
>>>>
>>>>>
>>>>> Registering classes implicitly is not possible since we have many
>>>>> serialization asymmetries so I have to list the classes explicitly in
>>>>> configuration, as you've said.  I enabled kryo traces to print out
>>>>> automatically registered classed, which is very helpful.
>>>>>
>>>>> I'm working on it.
>>>>>
>>>>> Thanks again for you patience.
>>>>>
>>>>> /Eduardo
>>>>>
>>>>> On Sun, Jul 3, 2016 at 11:53 PM, Guido Medina <oxyg...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Questions:
>>>>>>
>>>>>>- Why not just replace 2.10 with 2.11? From the Java perspective
>>>>>>it should be transparent and irrelevant to your project *-if I
>>>>>>understood correctly, your project is in Java-*
>>>>>>- Are you using Java 8? If just why not just go Akka 2.4.x?
>>>>>>
>>>>>> Next week Akka 2.4.8+ (if sprint goes well I think) will get a new
>>>>>> juice, akka-artery which will replace the current Netty basically giving
>>>>>> you a much faster remote component.
>>>>>> The automatic ID strategy is only available for akka-kryo 0.4.1+
>>>>>> which uses 2.11, automatic was the name we came up for default +
>>>>>> incremental, basically to allow the developer to:
&