[akka-user] Dokumentation inconsistency

[Gerald Mixa]

Hi,

i want to report a inconsisty of the akka documentation.

the folloing class should be in akka http
http://doc.akka.io/api/akka-stream-and-http-experimental/1.0-M2/index.html#akka.http.marshallers.sprayjson.SprayJsonSupport

at least to the scaladoc documentation.

Due to the javadoc documentation it is not.

In the jar files its not contained. Seems there is som flaw in the doc and 
code publishing process

Greetings

Gerald

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

Re: [akka-user] Re: How to Properly Manage Akka's Memory Usage with 40 Million Lines Task?

[Soumya Simanta]

Allen,

What are your constraints ? Does the output CSV have to maintain the order 
of the input file ? Do you have an upper bound ?

I don't think you are CPU bound so you need to look at ways of 
reading/writing faster. Maybe async IO using nio can help. 
You can split the input and process in parallel if you don't mind multiple 
output files.  

I'm not aware of any way of doing file IO faster using Akka. Maybe the Akka 
folks can provide better guidance there. 

BTW how much memory are you giving your akka-streams program? 

-Soumya


On Friday, January 9, 2015 at 4:53:29 PM UTC-5, Allen Nie wrote:
>
> Hey Viktor,
>
> I'm trying to use Akka to parallelize this process. There shouldn't be 
> any bottleneck, and I don't understand why I got memory overflow with my 
> first version (actor version). The main task is to read in a line, break it 
> up, and turn each segments (strings) into an integer, then prints it out to 
> a CSV file (vectorization process).
>
>def processLine(line: String): Unit = {
>
>   val vector: ListBuffer[String] = ListBuffer()
>   val segs = line.split(",")
>
>   println(segs(0))
>
>   (1 to segs.length - 1).map {i =>
> val factorArray = dictionaries(i-1)
> vector += factorArray._2.indexOf(segs(i)).toString   //get the factor 
> level of string
>   }
>
>   timer ! OneDone
>
>   printer ! Print(vector.toList)}
>
>
> When I'm doing this in pure Akka (with actors), since I created 40 
> million objects: Row(line: String), I get memory overflow issue. If I use 
> Akka-stream, there is no memory overflow issue, but the performance is too 
> similar to the non-parallelized version (even slower).
>
> It's my first time using Akka-stream. So I'm unfamiliar with the 
> optimization you were talking about.
>
> Sincerely,
> Allen
>
> On Friday, January 9, 2015 at 4:03:13 PM UTC-5, √ wrote:
>>
>> Hi Allen,
>>
>> What's the bottleneck?
>> Have you tried enabling the experimental optimizations?
>>
>> On Fri, Jan 9, 2015 at 9:52 PM, Allen Nie  wrote:
>>
>>> Thank you Soumya, 
>>>
>>>I think Akka-streams is the way to go. However, I would also 
>>> appreciate some performance boost as well - still have 40 million lines to 
>>> go through! But thanks anyway!
>>>
>>>
>>> On Friday, January 9, 2015 at 12:43:49 PM UTC-5, Soumya Simanta wrote:

 I would recommend using the Akka-streams API for this. 
 Here is sample. I was able to process a 1G file with around 1.5 million 
 records in *20MB* of memory. The file read and the writing on the 
 console rates are different but the streams API handles that.  This is not 
 the fastest but you at least won't run out of memory. 



 

 import java.io.FileInputStream
 import java.util.Scanner

 import akka.actor.ActorSystem
 import akka.stream.{FlowMaterializer, MaterializerSettings}
 import akka.stream.scaladsl.Source

 import scala.util.Try


 object StreamingFileReader extends App {


   val inputStream = new FileInputStream("/path/to/file")
   val sc = new Scanner(inputStream, "UTF-8")

   implicit val system = ActorSystem("Sys")
   val settings = MaterializerSettings(system)
   implicit val materializer = 
 FlowMaterializer(settings.copy(maxInputBufferSize 
 = 256, initialInputBufferSize = 256))

   val fileSource = Source(() => Iterator.continually(sc.nextLine()))

   import system.dispatcher

   fileSource.map { line =>
 line //do nothing
   //in the for each print the line. 
   }.foreach(println).onComplete { _ =>
 Try {
   sc.close()
   inputStream.close()
 }
 system.shutdown()
   }
 }




 On Friday, January 9, 2015 at 10:53:33 AM UTC-5, Allen Nie wrote:
>
> Hi,
>
> I am trying to process a csv file with 40 million lines of data in 
> there. It's a 5GB size file. I'm trying to use Akka to parallelize the 
> task. However, it seems like I can't stop the quick memory growth. It 
> expanded from 1GB to almost 15GB (the limit I set) under 5 minutes. This 
> is 
> the code in my main() method:
>
> val inputStream = new 
> FileInputStream("E:\\Allen\\DataScience\\train\\train.csv")val sc = new 
> Scanner(inputStream, "UTF-8")
> var counter = 0
> while (sc.hasNextLine) {
>
>   rowActors(counter % 20) ! Row(sc.nextLine())
>
>   counter += 1}
>
> sc.close()
> inputStream.close()
>
> Someone pointed out that I was essentially creating 40 million Row 
> objects, which naturally will take up a lot of space. My row actor is not 
> doing much. Just simply transforming each line into an array of integers 
> (if you are familiar with the concept of vectorizing, that's what I

Re: [akka-user] Re: How to Properly Manage Akka's Memory Usage with 40 Million Lines Task?

[Allen Nie]

Hey Viktor,

I'm trying to use Akka to parallelize this process. There shouldn't be 
any bottleneck, and I don't understand why I got memory overflow with my 
first version (actor version). The main task is to read in a line, break it 
up, and turn each segments (strings) into an integer, then prints it out to 
a CSV file (vectorization process).

   def processLine(line: String): Unit = {

  val vector: ListBuffer[String] = ListBuffer()
  val segs = line.split(",")

  println(segs(0))

  (1 to segs.length - 1).map {i =>
val factorArray = dictionaries(i-1)
vector += factorArray._2.indexOf(segs(i)).toString   //get the factor level 
of string
  }

  timer ! OneDone

  printer ! Print(vector.toList)}


When I'm doing this in pure Akka (with actors), since I created 40 
million objects: Row(line: String), I get memory overflow issue. If I use 
Akka-stream, there is no memory overflow issue, but the performance is too 
similar to the non-parallelized version (even slower).

It's my first time using Akka-stream. So I'm unfamiliar with the 
optimization you were talking about.

Sincerely,
Allen

On Friday, January 9, 2015 at 4:03:13 PM UTC-5, √ wrote:
>
> Hi Allen,
>
> What's the bottleneck?
> Have you tried enabling the experimental optimizations?
>
> On Fri, Jan 9, 2015 at 9:52 PM, Allen Nie 
> > wrote:
>
>> Thank you Soumya, 
>>
>>I think Akka-streams is the way to go. However, I would also 
>> appreciate some performance boost as well - still have 40 million lines to 
>> go through! But thanks anyway!
>>
>>
>> On Friday, January 9, 2015 at 12:43:49 PM UTC-5, Soumya Simanta wrote:
>>>
>>> I would recommend using the Akka-streams API for this. 
>>> Here is sample. I was able to process a 1G file with around 1.5 million 
>>> records in *20MB* of memory. The file read and the writing on the 
>>> console rates are different but the streams API handles that.  This is not 
>>> the fastest but you at least won't run out of memory. 
>>>
>>>
>>>
>>> 
>>>
>>> import java.io.FileInputStream
>>> import java.util.Scanner
>>>
>>> import akka.actor.ActorSystem
>>> import akka.stream.{FlowMaterializer, MaterializerSettings}
>>> import akka.stream.scaladsl.Source
>>>
>>> import scala.util.Try
>>>
>>>
>>> object StreamingFileReader extends App {
>>>
>>>
>>>   val inputStream = new FileInputStream("/path/to/file")
>>>   val sc = new Scanner(inputStream, "UTF-8")
>>>
>>>   implicit val system = ActorSystem("Sys")
>>>   val settings = MaterializerSettings(system)
>>>   implicit val materializer = 
>>> FlowMaterializer(settings.copy(maxInputBufferSize 
>>> = 256, initialInputBufferSize = 256))
>>>
>>>   val fileSource = Source(() => Iterator.continually(sc.nextLine()))
>>>
>>>   import system.dispatcher
>>>
>>>   fileSource.map { line =>
>>> line //do nothing
>>>   //in the for each print the line. 
>>>   }.foreach(println).onComplete { _ =>
>>> Try {
>>>   sc.close()
>>>   inputStream.close()
>>> }
>>> system.shutdown()
>>>   }
>>> }
>>>
>>>
>>>
>>>
>>> On Friday, January 9, 2015 at 10:53:33 AM UTC-5, Allen Nie wrote:

 Hi,

 I am trying to process a csv file with 40 million lines of data in 
 there. It's a 5GB size file. I'm trying to use Akka to parallelize the 
 task. However, it seems like I can't stop the quick memory growth. It 
 expanded from 1GB to almost 15GB (the limit I set) under 5 minutes. This 
 is 
 the code in my main() method:

 val inputStream = new 
 FileInputStream("E:\\Allen\\DataScience\\train\\train.csv")val sc = new 
 Scanner(inputStream, "UTF-8")
 var counter = 0
 while (sc.hasNextLine) {

   rowActors(counter % 20) ! Row(sc.nextLine())

   counter += 1}

 sc.close()
 inputStream.close()

 Someone pointed out that I was essentially creating 40 million Row 
 objects, which naturally will take up a lot of space. My row actor is not 
 doing much. Just simply transforming each line into an array of integers 
 (if you are familiar with the concept of vectorizing, that's what I'm 
 doing). Then the transformed array gets printed out. Done. I originally 
 thought there was a memory leak but maybe I'm not managing memory right. 
 Can I get any wise suggestions from the Akka experts here??

 

 

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

Re: [akka-user] TimeoutException when using tell on an ActorSelection if the target actor is created through AskSupport

[Ferdinand Hübner]

On Friday, January 9, 2015 at 7:34:08 PM UTC+1, Patrik Nordwall wrote:
>
>
> 9 jan 2015 kl. 18:10 skrev Ferdinand Hübner  >:
>
> Yes, that is what I'm doing. I'm passing the sender() ActorRef to other 
> actors until I am able to reply to it with deliver. When I reply with 
> delivery, I call path on the ActorRef.
> In my service layer, I would send a confirmation using tell with 
> ActorRef.noSender once the future from AskSupport completes.
>
> That is not going to work. Let's say that the confirmation message is 
> lost. Then AtLeastOnceDelivery will resend it to the path of the 
> PromiseActorRef (created by ask), but that is already completed and the 
> resent message will go to deadLetters, and be retried again.
>

I am aware of that and decided to ignore it at this point until I am able 
to decide if AtLeastOnceSupport is really something that I want and need. 
My idea was to handle UnconfirmedWarning by simply confirming the messages 
it contains. 
 

> Would it be possible to implement it without ask?
>

Yes, that should be possible. I never really thought about implementing it 
without ask. It's the first thing that came to my mind and worked well so 
far. 
I'll be going for a less temporay actor that completes promises and 
confirms deliveryIds that are not pending completion.

Thank you for the help and your suggestions.
Ferdinand

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

Re: [akka-user] Re: How to Properly Manage Akka's Memory Usage with 40 Million Lines Task?

[Viktor Klang]

Hi Allen,

What's the bottleneck?
Have you tried enabling the experimental optimizations?

On Fri, Jan 9, 2015 at 9:52 PM, Allen Nie  wrote:

> Thank you Soumya,
>
>I think Akka-streams is the way to go. However, I would also
> appreciate some performance boost as well - still have 40 million lines to
> go through! But thanks anyway!
>
>
> On Friday, January 9, 2015 at 12:43:49 PM UTC-5, Soumya Simanta wrote:
>>
>> I would recommend using the Akka-streams API for this.
>> Here is sample. I was able to process a 1G file with around 1.5 million
>> records in *20MB* of memory. The file read and the writing on the
>> console rates are different but the streams API handles that.  This is not
>> the fastest but you at least won't run out of memory.
>>
>>
>>
>> 
>>
>> import java.io.FileInputStream
>> import java.util.Scanner
>>
>> import akka.actor.ActorSystem
>> import akka.stream.{FlowMaterializer, MaterializerSettings}
>> import akka.stream.scaladsl.Source
>>
>> import scala.util.Try
>>
>>
>> object StreamingFileReader extends App {
>>
>>
>>   val inputStream = new FileInputStream("/path/to/file")
>>   val sc = new Scanner(inputStream, "UTF-8")
>>
>>   implicit val system = ActorSystem("Sys")
>>   val settings = MaterializerSettings(system)
>>   implicit val materializer = 
>> FlowMaterializer(settings.copy(maxInputBufferSize
>> = 256, initialInputBufferSize = 256))
>>
>>   val fileSource = Source(() => Iterator.continually(sc.nextLine()))
>>
>>   import system.dispatcher
>>
>>   fileSource.map { line =>
>> line //do nothing
>>   //in the for each print the line.
>>   }.foreach(println).onComplete { _ =>
>> Try {
>>   sc.close()
>>   inputStream.close()
>> }
>> system.shutdown()
>>   }
>> }
>>
>>
>>
>>
>> On Friday, January 9, 2015 at 10:53:33 AM UTC-5, Allen Nie wrote:
>>>
>>> Hi,
>>>
>>> I am trying to process a csv file with 40 million lines of data in
>>> there. It's a 5GB size file. I'm trying to use Akka to parallelize the
>>> task. However, it seems like I can't stop the quick memory growth. It
>>> expanded from 1GB to almost 15GB (the limit I set) under 5 minutes. This is
>>> the code in my main() method:
>>>
>>> val inputStream = new 
>>> FileInputStream("E:\\Allen\\DataScience\\train\\train.csv")val sc = new 
>>> Scanner(inputStream, "UTF-8")
>>> var counter = 0
>>> while (sc.hasNextLine) {
>>>
>>>   rowActors(counter % 20) ! Row(sc.nextLine())
>>>
>>>   counter += 1}
>>>
>>> sc.close()
>>> inputStream.close()
>>>
>>> Someone pointed out that I was essentially creating 40 million Row
>>> objects, which naturally will take up a lot of space. My row actor is not
>>> doing much. Just simply transforming each line into an array of integers
>>> (if you are familiar with the concept of vectorizing, that's what I'm
>>> doing). Then the transformed array gets printed out. Done. I originally
>>> thought there was a memory leak but maybe I'm not managing memory right.
>>> Can I get any wise suggestions from the Akka experts here??
>>>
>>>
>>>
>>> 
>>>
>>>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



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

Re: [akka-user] Re: UnboundedPriorityMailbox breaks message ordering?

[Viktor Klang]

On Fri, Jan 9, 2015 at 9:40 PM, David Hotham 
wrote:

> Of course it's normal and expected that a PriorityQueue returns equal
> priority elements in arbitrary order.  That's just how heaps work.  However
> that doesn't imply that a mailbox has to do the same thing!
>

Absolutely, the reordering is not a requirement :) However, silently
switching to a new, non-reordering-of-same-priority implementation would
risk breaking existing code (that for some reason relies on this behavior).


>
> For instance, I guess that it shouldn't be very hard for the mailbox to
> maintain a sequence number that it associates with each message.
>

Sure! The question is how how big the impact is on memory consumption and
performance.


> Then it could order messages first according to the comparator that it
> currently uses, and second according to the sequence number.  That way it
> would return equal priority messages in the same order that it saw them
> arrive - which gives exactly the property that I'd hoped for.
>

Absolutely :)


>
> I can't tell from your reply whether you think that maintaining order for
> equal priority messages is desirable or not.
>

I think it could be interesting as an alternative to the current version of
the PriorityMailbox, or perhaps even as a replacement if it is performing
as well as the thing it replaces.


>
>- If yes, what do you think about an implementation along these
>lines?  Is it worth me raising an issue at github?
>
> I wish I had time to do that, is it something you'd be willing/able to
take a stab at? Would love to see something like that.

>
>- If no, can I at least encourage the Akka maintainers to add an
>explicit note to the documentation, so that other users are less likely to
>fall into my error?
>
> I think this should be done anyway, since it as you said, and I confirmed,
surprising at first. :)



> Cheers,
>
> David
>
> On Friday, 9 January 2015 19:43:27 UTC, √ wrote:
>>
>> Hi David,
>>
>> yes, I can definitely understand that it can be surprising, but I
>> wouldn't call it a bug -per se-, since it is not a promise that was
>> violated.
>>
>> If you happen to have, or come by, a performant version of a
>> PriorityQueue with the semantics you described, please don't hesitate to
>> share it.
>>
>> On Fri, Jan 9, 2015 at 7:21 PM, David Hotham 
>> wrote:
>>
>>> It occurs to me that I wasn't completely clear:
>>>
>>>- Of course the priority mailbox must break message ordering in some
>>>general sense. Else it wouldn't be a priority mailbox at all!
>>>- But it is highly surprising to me that it should break ordering
>>>for messages of equal priority between a sender-receiver pair.
>>>
>>>
>>> On Friday, 9 January 2015 17:58:40 UTC, David Hotham wrote:

 Hi,

 We've been tracking down a bug in which reading from a TCP stream was
 getting all messed up.

 It turns out that we see the problem only when our actor handling
 Tcp.Received messages is using an UnboundedPriorityMailbox; the default
 mailbox doesn't exhibit any problem.

 I believe that the issue is that the UnboundedPriorityMailbox is backed
 by a PriorityBlockingQueue; and that, per the documentation for that class,
 "Operations on this class make no guarantees about the ordering of elements
 with equal priority".

 That is, it seems that the UnboundedPriorityMailbox breaks the
 guarantee of message ordering per sender–receiver pair.  In our case, the
 result being that different chunks of the TCP data stream arrive not in the
 order in which they were read from the wire.

 Does this analysis seem to be correct?

 If yes, is it a bug?  Would you like me to raise a ticket?

 Thanks!

 David

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

[akka-user] Re: How to Properly Manage Akka's Memory Usage with 40 Million Lines Task?

[Allen Nie]

Thank you Soumya, 

   I think Akka-streams is the way to go. However, I would also 
appreciate some performance boost as well - still have 40 million lines to 
go through! But thanks anyway!


On Friday, January 9, 2015 at 12:43:49 PM UTC-5, Soumya Simanta wrote:
>
> I would recommend using the Akka-streams API for this. 
> Here is sample. I was able to process a 1G file with around 1.5 million 
> records in *20MB* of memory. The file read and the writing on the console 
> rates are different but the streams API handles that.  This is not the 
> fastest but you at least won't run out of memory. 
>
>
>
> 
>
> import java.io.FileInputStream
> import java.util.Scanner
>
> import akka.actor.ActorSystem
> import akka.stream.{FlowMaterializer, MaterializerSettings}
> import akka.stream.scaladsl.Source
>
> import scala.util.Try
>
>
> object StreamingFileReader extends App {
>
>
>   val inputStream = new FileInputStream("/path/to/file")
>   val sc = new Scanner(inputStream, "UTF-8")
>
>   implicit val system = ActorSystem("Sys")
>   val settings = MaterializerSettings(system)
>   implicit val materializer = 
> FlowMaterializer(settings.copy(maxInputBufferSize = 256, 
> initialInputBufferSize = 256))
>
>   val fileSource = Source(() => Iterator.continually(sc.nextLine()))
>
>   import system.dispatcher
>
>   fileSource.map { line =>
> line //do nothing
>   //in the for each print the line. 
>   }.foreach(println).onComplete { _ =>
> Try {
>   sc.close()
>   inputStream.close()
> }
> system.shutdown()
>   }
> }
>
>
>
>
> On Friday, January 9, 2015 at 10:53:33 AM UTC-5, Allen Nie wrote:
>>
>> Hi,
>>
>> I am trying to process a csv file with 40 million lines of data in 
>> there. It's a 5GB size file. I'm trying to use Akka to parallelize the 
>> task. However, it seems like I can't stop the quick memory growth. It 
>> expanded from 1GB to almost 15GB (the limit I set) under 5 minutes. This is 
>> the code in my main() method:
>>
>> val inputStream = new 
>> FileInputStream("E:\\Allen\\DataScience\\train\\train.csv")val sc = new 
>> Scanner(inputStream, "UTF-8")
>> var counter = 0
>> while (sc.hasNextLine) {
>>
>>   rowActors(counter % 20) ! Row(sc.nextLine())
>>
>>   counter += 1}
>>
>> sc.close()
>> inputStream.close()
>>
>> Someone pointed out that I was essentially creating 40 million Row 
>> objects, which naturally will take up a lot of space. My row actor is not 
>> doing much. Just simply transforming each line into an array of integers 
>> (if you are familiar with the concept of vectorizing, that's what I'm 
>> doing). Then the transformed array gets printed out. Done. I originally 
>> thought there was a memory leak but maybe I'm not managing memory right. 
>> Can I get any wise suggestions from the Akka experts here??
>>
>> 
>>
>> 
>>
>>

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

Re: [akka-user] Re: UnboundedPriorityMailbox breaks message ordering?

[David Hotham]

Of course it's normal and expected that a PriorityQueue returns equal 
priority elements in arbitrary order.  That's just how heaps work.  However 
that doesn't imply that a mailbox has to do the same thing!

For instance, I guess that it shouldn't be very hard for the mailbox to 
maintain a sequence number that it associates with each message.  Then it 
could order messages first according to the comparator that it currently 
uses, and second according to the sequence number.  That way it would 
return equal priority messages in the same order that it saw them arrive - 
which gives exactly the property that I'd hoped for.

I can't tell from your reply whether you think that maintaining order for 
equal priority messages is desirable or not.

   - If yes, what do you think about an implementation along these lines?  
   Is it worth me raising an issue at github?
   - If no, can I at least encourage the Akka maintainers to add an 
   explicit note to the documentation, so that other users are less likely to 
   fall into my error?

Cheers, 

David

On Friday, 9 January 2015 19:43:27 UTC, √ wrote:
>
> Hi David,
>
> yes, I can definitely understand that it can be surprising, but I wouldn't 
> call it a bug -per se-, since it is not a promise that was violated.
>
> If you happen to have, or come by, a performant version of a PriorityQueue 
> with the semantics you described, please don't hesitate to share it.
>
> On Fri, Jan 9, 2015 at 7:21 PM, David Hotham  > wrote:
>
>> It occurs to me that I wasn't completely clear:
>>
>>- Of course the priority mailbox must break message ordering in some 
>>general sense. Else it wouldn't be a priority mailbox at all!
>>- But it is highly surprising to me that it should break ordering for 
>>messages of equal priority between a sender-receiver pair.
>>
>>
>> On Friday, 9 January 2015 17:58:40 UTC, David Hotham wrote:
>>>
>>> Hi, 
>>>
>>> We've been tracking down a bug in which reading from a TCP stream was 
>>> getting all messed up.
>>>
>>> It turns out that we see the problem only when our actor handling 
>>> Tcp.Received messages is using an UnboundedPriorityMailbox; the default 
>>> mailbox doesn't exhibit any problem.
>>>
>>> I believe that the issue is that the UnboundedPriorityMailbox is backed 
>>> by a PriorityBlockingQueue; and that, per the documentation for that class, 
>>> "Operations on this class make no guarantees about the ordering of elements 
>>> with equal priority".
>>>
>>> That is, it seems that the UnboundedPriorityMailbox breaks the guarantee 
>>> of message ordering per sender–receiver pair.  In our case, the result 
>>> being that different chunks of the TCP data stream arrive not in the order 
>>> in which they were read from the wire.
>>>
>>> Does this analysis seem to be correct?
>>>
>>> If yes, is it a bug?  Would you like me to raise a ticket?
>>>
>>> Thanks!
>>>
>>> David
>>>
>>  -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> 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 http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Re: UnboundedPriorityMailbox breaks message ordering?

[Viktor Klang]

Hi David,

yes, I can definitely understand that it can be surprising, but I wouldn't
call it a bug -per se-, since it is not a promise that was violated.

If you happen to have, or come by, a performant version of a PriorityQueue
with the semantics you described, please don't hesitate to share it.

On Fri, Jan 9, 2015 at 7:21 PM, David Hotham 
wrote:

> It occurs to me that I wasn't completely clear:
>
>- Of course the priority mailbox must break message ordering in some
>general sense. Else it wouldn't be a priority mailbox at all!
>- But it is highly surprising to me that it should break ordering for
>messages of equal priority between a sender-receiver pair.
>
>
> On Friday, 9 January 2015 17:58:40 UTC, David Hotham wrote:
>>
>> Hi,
>>
>> We've been tracking down a bug in which reading from a TCP stream was
>> getting all messed up.
>>
>> It turns out that we see the problem only when our actor handling
>> Tcp.Received messages is using an UnboundedPriorityMailbox; the default
>> mailbox doesn't exhibit any problem.
>>
>> I believe that the issue is that the UnboundedPriorityMailbox is backed
>> by a PriorityBlockingQueue; and that, per the documentation for that class,
>> "Operations on this class make no guarantees about the ordering of elements
>> with equal priority".
>>
>> That is, it seems that the UnboundedPriorityMailbox breaks the guarantee
>> of message ordering per sender–receiver pair.  In our case, the result
>> being that different chunks of the TCP data stream arrive not in the order
>> in which they were read from the wire.
>>
>> Does this analysis seem to be correct?
>>
>> If yes, is it a bug?  Would you like me to raise a ticket?
>>
>> Thanks!
>>
>> David
>>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



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

Re: [akka-user] Re: is this a sensible problem for persistence?

[Tim Pigden]

Hi Greg
Well the history of ETA changes might be useful but certainly is never
essential.


On 9 January 2015 at 17:30, Greg Young  wrote:

> Its also very common to CALCULATE the ETA changes and raise them as events
> without necessarily persisting them.
>
> As a thought experiment if your notification system lost 1/1000 would
> it really matter?
>
>
> On Thursday, January 8, 2015 at 12:59:51 PM UTC+2, Tim Pigden wrote:
>>
>> Hmm - on reading other threads and reflection I think I may have the
>> wrong model here. The information about the ETA is possibly not something
>> that should be persisted. It's not hard data. And perhaps my parcel should
>> be split between a persisting actor (still need 1m of them) and some sort
>> of query object that reflects current ETA and the real object is only
>> updated in response to materialisation of the ETA (i.e. sending it to the
>> customer as advice) in which case it's the advice history that's the thing
>> to persist.
>>
>> Is anyone encountering similar modelling issues?
>>
>> On Thursday, January 8, 2015 10:34:10 AM UTC, Tim Pigden wrote:
>>>
>>> Hi
>>> I'm looking at modelling a large parcel delivery system with
>>> approximately 300k - 1m parcels per day depending on time of year. Each of
>>> those parcels has its own life cycle from assignment to a trip through
>>> eventual delivery. If parcels are on a route, then, for example, a delivery
>>> event at position 5 on the route will cause an update of the ETA for
>>> parcels 6 - n where n could be 100 or so.
>>> A parcel in position 50 might receive 60 such updates up until it is
>>> successfully delivered and therefore "retired" from active consideration.
>>>
>>> I'm estimating that with 0.5m parcels and an 8 hour working day, I'll
>>> get around 20 delivery notifications per second, each generating a cascade
>>> of up to 100 new ETAs - so around 2000 updates/second. In the morning,
>>> around 8am and 9am these numbers will peak as high priority orders tend to
>>> cluster well geographically so the drivers hit more deliveries in a shorter
>>> space of time - so say at Christmas peak we could get up to 5000
>>> updates/second for brief periods.
>>>
>>> Now I'm not a big data guy. To me this is immense, but realistically is
>>> this going to cause any problem for Akka persistence? Is up to 1m separate
>>> actor processors a sensible thing to have? There are alternative ways to
>>> model it - the updates are internally generated at the vehicle level (so
>>> theoretically I only need to persist the incoming vehicle signals) but the
>>> parcel life cycle extends beyond the duration of the vehicle trip so that
>>> could get messy.
>>>
>>>
>>>  --
> >> 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/HTyC75jnOEc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Tim Pigden
Optrak Distribution Software Limited
+44 (0)1992 517100
http://www.linkedin.com/in/timpigden
http://optrak.com
Optrak Distribution Software Ltd is a limited company registered in England
and Wales.
Company Registration No. 2327613 Registered Offices: Suite 6,The Maltings,
Hoe Lane, Ware, SG12 9LR England
This email and any attachments to it may be confidential and are intended
solely for the use of the individual to whom it is addressed. Any views or
opinions expressed are solely those of the author and do not necessarily
represent those of Optrak Distribution Software Ltd. If you are not the
intended recipient of this email, you must neither take any action based
upon its contents, nor copy or show it to anyone. Please contact the sender
if you believe you have received this email in error.

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

[akka-user] akka-plugins: consolidate repositories under akka

[Andrei Pozolotin]

request to external akka module authors: please vote +1 / -1 your opinion 
here: https://github.com/akka/akka/issues/16618

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

Re: [akka-user] TimeoutException when using tell on an ActorSelection if the target actor is created through AskSupport

[Patrik Nordwall]

> 9 jan 2015 kl. 18:10 skrev Ferdinand Hübner :
> 
> Hi Patrik,
> 
> thank you for the reply.
> 
>> On Friday, January 9, 2015 at 9:49:40 AM UTC+1, Patrik Nordwall wrote:
>> 
>> Let me try to understand your original problem. You send a request with ask 
>> to an Actor with AtLeastOnceDelivery. There you reply to the sender() using 
>> the deliver method (and the path of the sender()). Is that what you are 
>> doing?
> 
> Yes, that is what I'm doing. I'm passing the sender() ActorRef to other 
> actors until I am able to reply to it with deliver. When I reply with 
> delivery, I call path on the ActorRef.
> In my service layer, I would send a confirmation using tell with 
> ActorRef.noSender once the future from AskSupport completes.
> 

That is not going to work. Let's say that the confirmation message is lost. 
Then AtLeastOnceDelivery will resend it to the path of the PromiseActorRef 
(created by ask), but that is already completed and the resent message will go 
to deadLetters, and be retried again.

Would it be possible to implement it without ask?

> To be honest, I'm not sure If what I'm doing is weird somehow because of the 
> temporary actor from AskSupport (I'm experimenting/prototyping). I'm 
> uncertain what would happen upon re-delivery, I guess a dead letter. 
> What perplexes me is that you cannot tell an ActorSelection if you create it 
> by calling path on an ActorRef from AskSupport. Is this by design?

I don't think we have thought of replying to an ask via an actor selection, 
because we have not thought of a use case where it would be needed.

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

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

[akka-user] Re: UnboundedPriorityMailbox breaks message ordering?

[David Hotham]

It occurs to me that I wasn't completely clear:

   - Of course the priority mailbox must break message ordering in some 
   general sense. Else it wouldn't be a priority mailbox at all!
   - But it is highly surprising to me that it should break ordering for 
   messages of equal priority between a sender-receiver pair.
   

On Friday, 9 January 2015 17:58:40 UTC, David Hotham wrote:
>
> Hi, 
>
> We've been tracking down a bug in which reading from a TCP stream was 
> getting all messed up.
>
> It turns out that we see the problem only when our actor handling 
> Tcp.Received messages is using an UnboundedPriorityMailbox; the default 
> mailbox doesn't exhibit any problem.
>
> I believe that the issue is that the UnboundedPriorityMailbox is backed by 
> a PriorityBlockingQueue; and that, per the documentation for that class, 
> "Operations on this class make no guarantees about the ordering of elements 
> with equal priority".
>
> That is, it seems that the UnboundedPriorityMailbox breaks the guarantee 
> of message ordering per sender–receiver pair.  In our case, the result 
> being that different chunks of the TCP data stream arrive not in the order 
> in which they were read from the wire.
>
> Does this analysis seem to be correct?
>
> If yes, is it a bug?  Would you like me to raise a ticket?
>
> Thanks!
>
> David
>

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

[akka-user] UnboundedPriorityMailbox breaks message ordering?

[David Hotham]

Hi, 

We've been tracking down a bug in which reading from a TCP stream was 
getting all messed up.

It turns out that we see the problem only when our actor handling 
Tcp.Received messages is using an UnboundedPriorityMailbox; the default 
mailbox doesn't exhibit any problem.

I believe that the issue is that the UnboundedPriorityMailbox is backed by 
a PriorityBlockingQueue; and that, per the documentation for that class, 
"Operations on this class make no guarantees about the ordering of elements 
with equal priority".

That is, it seems that the UnboundedPriorityMailbox breaks the guarantee of 
message ordering per sender–receiver pair.  In our case, the result being 
that different chunks of the TCP data stream arrive not in the order in 
which they were read from the wire.

Does this analysis seem to be correct?

If yes, is it a bug?  Would you like me to raise a ticket?

Thanks!

David

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

[akka-user] Re: How to Properly Manage Akka's Memory Usage with 40 Million Lines Task?

[Soumya Simanta]

I would recommend using the Akka-streams API for this. 
Here is sample. I was able to process a 1G file with around 1.5 million 
records in *20MB* of memory. The file read and the writing on the console 
rates are different but the streams API handles that.  This is not the 
fastest but you at least won't run out of memory. 




import java.io.FileInputStream
import java.util.Scanner

import akka.actor.ActorSystem
import akka.stream.{FlowMaterializer, MaterializerSettings}
import akka.stream.scaladsl.Source

import scala.util.Try


object StreamingFileReader extends App {


  val inputStream = new FileInputStream("/path/to/file")
  val sc = new Scanner(inputStream, "UTF-8")

  implicit val system = ActorSystem("Sys")
  val settings = MaterializerSettings(system)
  implicit val materializer = 
FlowMaterializer(settings.copy(maxInputBufferSize = 256, 
initialInputBufferSize = 256))

  val fileSource = Source(() => Iterator.continually(sc.nextLine()))

  import system.dispatcher

  fileSource.map { line =>
line //do nothing
  //in the for each print the line. 
  }.foreach(println).onComplete { _ =>
Try {
  sc.close()
  inputStream.close()
}
system.shutdown()
  }
}




On Friday, January 9, 2015 at 10:53:33 AM UTC-5, Allen Nie wrote:
>
> Hi,
>
> I am trying to process a csv file with 40 million lines of data in 
> there. It's a 5GB size file. I'm trying to use Akka to parallelize the 
> task. However, it seems like I can't stop the quick memory growth. It 
> expanded from 1GB to almost 15GB (the limit I set) under 5 minutes. This is 
> the code in my main() method:
>
> val inputStream = new 
> FileInputStream("E:\\Allen\\DataScience\\train\\train.csv")val sc = new 
> Scanner(inputStream, "UTF-8")
> var counter = 0
> while (sc.hasNextLine) {
>
>   rowActors(counter % 20) ! Row(sc.nextLine())
>
>   counter += 1}
>
> sc.close()
> inputStream.close()
>
> Someone pointed out that I was essentially creating 40 million Row 
> objects, which naturally will take up a lot of space. My row actor is not 
> doing much. Just simply transforming each line into an array of integers 
> (if you are familiar with the concept of vectorizing, that's what I'm 
> doing). Then the transformed array gets printed out. Done. I originally 
> thought there was a memory leak but maybe I'm not managing memory right. 
> Can I get any wise suggestions from the Akka experts here??
>
> 
>
> 
>
>

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

[akka-user] Re: is this a sensible problem for persistence?

[Greg Young]

Its also very common to CALCULATE the ETA changes and raise them as events 
without necessarily persisting them.

As a thought experiment if your notification system lost 1/1000 would 
it really matter?

On Thursday, January 8, 2015 at 12:59:51 PM UTC+2, Tim Pigden wrote:
>
> Hmm - on reading other threads and reflection I think I may have the wrong 
> model here. The information about the ETA is possibly not something that 
> should be persisted. It's not hard data. And perhaps my parcel should be 
> split between a persisting actor (still need 1m of them) and some sort of 
> query object that reflects current ETA and the real object is only updated 
> in response to materialisation of the ETA (i.e. sending it to the customer 
> as advice) in which case it's the advice history that's the thing to 
> persist.
>
> Is anyone encountering similar modelling issues?
>
> On Thursday, January 8, 2015 10:34:10 AM UTC, Tim Pigden wrote:
>>
>> Hi
>> I'm looking at modelling a large parcel delivery system with 
>> approximately 300k - 1m parcels per day depending on time of year. Each of 
>> those parcels has its own life cycle from assignment to a trip through 
>> eventual delivery. If parcels are on a route, then, for example, a delivery 
>> event at position 5 on the route will cause an update of the ETA for 
>> parcels 6 - n where n could be 100 or so.
>> A parcel in position 50 might receive 60 such updates up until it is 
>> successfully delivered and therefore "retired" from active consideration.
>>
>> I'm estimating that with 0.5m parcels and an 8 hour working day, I'll get 
>> around 20 delivery notifications per second, each generating a cascade of 
>> up to 100 new ETAs - so around 2000 updates/second. In the morning, around 
>> 8am and 9am these numbers will peak as high priority orders tend to cluster 
>> well geographically so the drivers hit more deliveries in a shorter space 
>> of time - so say at Christmas peak we could get up to 5000 updates/second 
>> for brief periods.
>>
>> Now I'm not a big data guy. To me this is immense, but realistically is 
>> this going to cause any problem for Akka persistence? Is up to 1m separate 
>> actor processors a sensible thing to have? There are alternative ways to 
>> model it - the updates are internally generated at the vehicle level (so 
>> theoretically I only need to persist the incoming vehicle signals) but the 
>> parcel life cycle extends beyond the duration of the vehicle trip so that 
>> could get messy.
>>
>>
>>

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

Re: [akka-user] support for akka persistent plugins

[Greg Young]

We are close to having official support for the event store one (weeks time 
frame)

On Friday, January 9, 2015 at 10:19:03 AM UTC+2, Patrik Nordwall wrote:
>
> Hi Tim,
>
> None of the external plugins are officially supported by Typesafe. You can 
> contact 
> Typesafe  to discuss it and at least 
> let Typesafe know that you would be interested in such support.
>
> I think geteventstore  offers 
> commercial support for their plugin and backend store.
>
> Regards,
> Patrik
>
> On Thu, Jan 8, 2015 at 11:43 AM, Tim Pigden  > wrote:
>
>> Which, if any, of the main target plugins (Cassandra, etc) are supported 
>> by Typesafe or commercially via other parties? 
>>
>> -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> Patrik Nordwall
> Typesafe  -  Reactive apps on the JVM
> Twitter: @patriknw
>
>  

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

Re: [akka-user] TimeoutException when using tell on an ActorSelection if the target actor is created through AskSupport

[Ferdinand Hübner]

Hi Patrik,

thank you for the reply.

On Friday, January 9, 2015 at 9:49:40 AM UTC+1, Patrik Nordwall wrote:
>
>
> Let me try to understand your original problem. You send a request with 
> ask to an Actor with AtLeastOnceDelivery. There you reply to the sender() 
> using the deliver method (and the path of the sender()). Is that what you 
> are doing?
>

Yes, that is what I'm doing. I'm passing the sender() ActorRef to other 
actors until I am able to reply to it with deliver. When I reply with 
delivery, I call path on the ActorRef.
In my service layer, I would send a confirmation using tell with 
ActorRef.noSender once the future from AskSupport completes.

To be honest, I'm not sure If what I'm doing is weird somehow because of 
the temporary actor from AskSupport (I'm experimenting/prototyping). I'm 
uncertain what would happen upon re-delivery, I guess a dead letter. 
What perplexes me is that you cannot tell an ActorSelection if you create 
it by calling path on an ActorRef from AskSupport. Is this by design?

Ferdinand

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

[akka-user] How to Properly Manage Akka's Memory Usage with 40 Million Lines Task?

[Allen Nie]

Hi,

I am trying to process a csv file with 40 million lines of data in 
there. It's a 5GB size file. I'm trying to use Akka to parallelize the 
task. However, it seems like I can't stop the quick memory growth. It 
expanded from 1GB to almost 15GB (the limit I set) under 5 minutes. This is 
the code in my main() method:

val inputStream = new 
FileInputStream("E:\\Allen\\DataScience\\train\\train.csv")val sc = new 
Scanner(inputStream, "UTF-8")
var counter = 0
while (sc.hasNextLine) {

  rowActors(counter % 20) ! Row(sc.nextLine())

  counter += 1}

sc.close()
inputStream.close()

Someone pointed out that I was essentially creating 40 million Row 
objects, which naturally will take up a lot of space. My row actor is not 
doing much. Just simply transforming each line into an array of integers 
(if you are familiar with the concept of vectorizing, that's what I'm 
doing). Then the transformed array gets printed out. Done. I originally 
thought there was a memory leak but maybe I'm not managing memory right. 
Can I get any wise suggestions from the Akka experts here??





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

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

[Sebastian Bach]

Maybe in 'The Reactive Manifesto' v3.0:
The human user as an auxiliary part of a reactive system should be 
responsive, resilient, elastic and message-driven too. He may be the 
weakest link in the chain.

W dniu piątek, 9 stycznia 2015 11:56:40 UTC+1 użytkownik Greg Young napisał:
>
> Usually it comes down to the realization that the computer is not the book 
> of record. One of my favourites was being asked to build a fully consistent 
> inventory system. I generally like to approach things with questions, the 
> one i had was 'sure but how do we get people who are stealing stuff to 
> appropriately check it out?'
> On 9 Jan 2015 12:02, "Sebastian Bach"  > wrote:
>
>>
>> Thank you Greg. The mind shift from a preventive to a reactive workflow 
>> is not easy for users (humans), because it requires a change of habits. For 
>> many people computer systems are kind of authoritative. There is this wrong 
>> assumption (from early days of computation?) that a computer accepts only a 
>> valid input or returns an error. It was then only black or white, the 
>> golden era of transactions. But this was (as you pointed out) always to 
>> some degree an hypocrisy. Now we have this shades of gray and many users 
>> feel unsettled. This holds true for any kind of resource allocation 
>> application and the overbooking (or wrong booking) problem. Some of the 
>> users define taking workload off of them as avoiding of planning mistakes, 
>> like commit and forget. But the actual workflow seems to shift towards an 
>> iterative process of human-computer interaction, to some kind of 
>> react-react ping-pong.
>>
>> Best Regards
>> Sebastian
>>
>>
>> W dniu środa, 7 stycznia 2015 22:15:42 UTC+1 użytkownik Greg Young 
>> napisał:
>>>
>>> "The consistency of the query model should be achieved as soon as 
>>> possible and close to real-time." 
>>>
>>> It really depends on the domain. I have worked in many situations 
>>> where the data in question would be perfectly fine updated once per 
>>> month. 
>>>
>>> " (e.g. adding a sold out item to the shopping cart)." 
>>>
>>> This is a funny example because it shows not that you need to update 
>>> read models more quickly but that you need to get the whole business 
>>> on board. Remember that computer systems are normally part of a larger 
>>> system fulfilling business needs. It really is a mind shift moving to 
>>> eventual consistency. 
>>>
>>> In the example of adding a sold out item... why stop it? Does it 
>>> matter that we don't have any of this item? The real question is how 
>>> quickly we can get it and if its worth our while to do so. To be fair 
>>> 30 years ago these times were much much higher than what we talk about 
>>> today and yet businesses still managed to work their way through 
>>> things. 
>>>
>>> For many of these types allowing things to go incorrectly is actually 
>>> a good thing (overbooked seats on an airline, overdraft charges at 
>>> banks...). To really be benefiting from eventual consistency the whole 
>>> business process must recognize it. In terms of handling failures they 
>>> are normally handled in a reactive not a preventative manner (like 
>>> most business problems). Detect the failure, let a human deal with it. 
>>>
>>> At the end of the day the primary role of the computer system is to 
>>> take workload off of humans. You will hit the law of diminishing 
>>> returns. dont try to solve every problem :) 
>>>
>>> Greg 
>>>
>>> On Wed, Jan 7, 2015 at 11:07 PM, Sebastian Bach 
>>>  wrote: 
>>> > Hi Roland, 
>>> > 
>>> > one thing to keep in mind in the CQRS/ES architecture is that not only 
>>> the 
>>> > query side depends on the command side (by following the event stream) 
>>> but 
>>> > also the command side depends on the query side for validation of 
>>> complex 
>>> > business rules. This has a deep impact on correctness and throughput. 
>>> > Validation checks on an potentially outdated query model in an 
>>> eventually 
>>> > consistent architecture is a hard problem (e.g. adding a sold out item 
>>> to 
>>> > the shopping cart). The consistency of the query model should be 
>>> achieved as 
>>> > soon as possible and close to real-time. A PersistentView in Akka has 
>>> a 
>>> > default of 5s? On the other hand the speed of validation depends on 
>>> the 
>>> > speed of the queries. And the throughput depends on the validation 
>>> speed. 
>>> > Thus, queries directly on the whole event stream are less useful than 
>>> > persistent projections. 
>>> > 
>>> > Keep up the good work :) 
>>> > Cheers 
>>> > Sebastian 
>>> > 
>>> > 
>>> > W dniu wtorek, 7 października 2014 07:32:20 UTC+2 użytkownik rkuhn 
>>> napisał: 
>>> >> 
>>> >> Hi Vaughn, 
>>> >> 
>>> >> from our side nothing has happened yet: my conclusion is that this 
>>> thread 
>>> >> contains all the information we need when we start working on this. 
>>> The 
>>> >> reason why we are waiting is that this work will depend heavily upon 
>>> Akka 
>>> >> Streams and there

Re: [akka-user] Not loosing message due to remote actor unavailable.

[Patrik Nordwall]

http://doc.akka.io/docs/akka/2.3.8/common/cluster.html

http://doc.akka.io/docs/akka/2.3.8/scala/cluster-usage.html

http://doc.akka.io/docs/akka/2.3.8/java/cluster-usage.html

On Fri, Jan 9, 2015 at 4:36 PM, Endre Varga 
wrote:

> Hi Matan,
>
> On Fri, Jan 9, 2015 at 4:30 PM, Matan Safriel  wrote:
>
>> Thanks, good to know! Does it include a leader election process for when
>> the leader isn't available?
>>
>
> From the docs:
>
> "After gossip convergence a leader for the cluster can be determined.
> There is no leader election process, the leader can always be recognised
> deterministically by any node whenever there is gossip convergence. The
> leader is just a role, any node can be the leader and it can change between
> convergence rounds. The leader is simply the first node in sorted order
> that is able to take the leadership role, where the preferred member states
> for a leader are upand leaving (see the Membership Lifecycle section below
> for more information about member states)."
>
> There is no explicit leader election because the leader can be always
> implicitly determinable from the cluster CRDT state.
>
>
>> I was not sure from the documentation whether the leader is a single
>> point of failure, or its relationship to seed nodes.
>>
>
> Leader is not a single point of failure, it changes many times during the
> life of a cluster.
>
> Seed nodes are not special either, they are just a set of known IP
> addresses to bootstrap from (i.e. a set of nodes that can be used to enter
> the cluster, only one of them that is needed to be up at any time) when a
> node wants to join. This idea is not unique to Akka, for example quoting
> from the Cassandra docs:
>
> "Cassandra nodes exchange information about one another using a mechanism
> called Gossip, but to get the ball rolling a newly started node needs to
> know of at least one other, this is called a Seed. It's customary to pick a
> small number of relatively stable nodes to serve as your seeds, but there
> is no hard-and-fast rule here. Do make sure that each seed also knows of at
> least one other, remember, the goal is to avoid a chicken-and-egg scenario
> and provide an avenue for all nodes in the cluster to discover one another."
>
> -Endre
>
>
>
>>
>> Maybe this should be a different thread.
>>
>> On Fri, Jan 9, 2015 at 5:15 PM, Endre Varga 
>> wrote:
>>
>>> Hi,
>>>
>>> On Fri, Jan 9, 2015 at 4:12 PM, Matan Safriel 
>>> wrote:
>>>
 Thanks Patrik, good to know, because the cluster module may seem like a
 very specific and rather unfinished reference implementation;

>>>
>>> What do you mean by unfinished reference implementation? It is a fully
>>> supported module of Akka.
>>>
>>> -Endre
>>>
>>>
 Good to have this in the core without relying on the cluster module.

 On Friday, January 9, 2015 at 11:25:30 AM UTC+2, Patrik Nordwall wrote:
>
>
>
> On Thu, Jan 8, 2015 at 9:56 PM, Matan Safriel 
> wrote:
>
>> Sorry for awakening this old thread...
>> Is it really the case that there is all this fancy supervision
>> architecture, and then a remote actor that has gone non-responsive, needs
>> to be handled outside of the supervision hierarchy alltogether? was it
>> considered enabling supervision to work such that the supervisor would 
>> know
>> in case its remote child has gone unresponsive/gated/quarantined?
>>
>
> The information in this thread is outdated. We have added support for
> proper remote death watch also when using remoting only (without cluster).
>
>
>>
>> Perhaps I misinterpret the reference to the "cluster module" in the
>> response by Dr. Roland Kuhn below.
>>
>> Thanks for clarifying,
>> Matan
>>
>> On Thursday, January 31, 2013 at 10:13:26 PM UTC+2, rkuhn wrote:
>>>
>>> Hi Juan Pablo,
>>>
>>> 30 jan 2013 kl. 22:08 skrev Juan Pablo Vergara Villarraga:
>>>
>>> If a remote actor is not available due to power loss Can the
>>> supervision strategy handle the situation?
>>>
>>>
>>> No, loss of actors is managed by the Death Watch (
>>> http://doc.akka.io/docs/akka/2.1.0/general/supervision.html
>>> #What_Lifecycle_Monitoring_Means
>>> ),
>>> but support for detecting unreachable remote nodes is only present in 
>>> the
>>> cluster module.
>>>
>>> I have coded the example and I have shut down the remote actor
>>> system but it seems that the supervision strategy only takes into 
>>> account
>>> Exceptions thrown by the remote actor once reached.
>>>
>>>
>>> Yes, that is correct.
>>>
>>> I have already implemented the subscription to the events that
>>> indicates that error in the connection have occurred. I st

Re: [akka-user] Not loosing message due to remote actor unavailable.

[Endre Varga]

Hi Matan,

On Fri, Jan 9, 2015 at 4:30 PM, Matan Safriel  wrote:

> Thanks, good to know! Does it include a leader election process for when
> the leader isn't available?
>

>From the docs:

"After gossip convergence a leader for the cluster can be determined. There
is no leader election process, the leader can always be recognised
deterministically by any node whenever there is gossip convergence. The
leader is just a role, any node can be the leader and it can change between
convergence rounds. The leader is simply the first node in sorted order
that is able to take the leadership role, where the preferred member states
for a leader are upand leaving (see the Membership Lifecycle section below
for more information about member states)."

There is no explicit leader election because the leader can be always
implicitly determinable from the cluster CRDT state.


> I was not sure from the documentation whether the leader is a single point
> of failure, or its relationship to seed nodes.
>

Leader is not a single point of failure, it changes many times during the
life of a cluster.

Seed nodes are not special either, they are just a set of known IP
addresses to bootstrap from (i.e. a set of nodes that can be used to enter
the cluster, only one of them that is needed to be up at any time) when a
node wants to join. This idea is not unique to Akka, for example quoting
from the Cassandra docs:

"Cassandra nodes exchange information about one another using a mechanism
called Gossip, but to get the ball rolling a newly started node needs to
know of at least one other, this is called a Seed. It's customary to pick a
small number of relatively stable nodes to serve as your seeds, but there
is no hard-and-fast rule here. Do make sure that each seed also knows of at
least one other, remember, the goal is to avoid a chicken-and-egg scenario
and provide an avenue for all nodes in the cluster to discover one another."

-Endre


>
> Maybe this should be a different thread.
>
> On Fri, Jan 9, 2015 at 5:15 PM, Endre Varga 
> wrote:
>
>> Hi,
>>
>> On Fri, Jan 9, 2015 at 4:12 PM, Matan Safriel 
>> wrote:
>>
>>> Thanks Patrik, good to know, because the cluster module may seem like a
>>> very specific and rather unfinished reference implementation;
>>>
>>
>> What do you mean by unfinished reference implementation? It is a fully
>> supported module of Akka.
>>
>> -Endre
>>
>>
>>> Good to have this in the core without relying on the cluster module.
>>>
>>> On Friday, January 9, 2015 at 11:25:30 AM UTC+2, Patrik Nordwall wrote:



 On Thu, Jan 8, 2015 at 9:56 PM, Matan Safriel 
 wrote:

> Sorry for awakening this old thread...
> Is it really the case that there is all this fancy supervision
> architecture, and then a remote actor that has gone non-responsive, needs
> to be handled outside of the supervision hierarchy alltogether? was it
> considered enabling supervision to work such that the supervisor would 
> know
> in case its remote child has gone unresponsive/gated/quarantined?
>

 The information in this thread is outdated. We have added support for
 proper remote death watch also when using remoting only (without cluster).


>
> Perhaps I misinterpret the reference to the "cluster module" in the
> response by Dr. Roland Kuhn below.
>
> Thanks for clarifying,
> Matan
>
> On Thursday, January 31, 2013 at 10:13:26 PM UTC+2, rkuhn wrote:
>>
>> Hi Juan Pablo,
>>
>> 30 jan 2013 kl. 22:08 skrev Juan Pablo Vergara Villarraga:
>>
>> If a remote actor is not available due to power loss Can the
>> supervision strategy handle the situation?
>>
>>
>> No, loss of actors is managed by the Death Watch (
>> http://doc.akka.io/docs/akka/2.1.0/general/supervision.html
>> #What_Lifecycle_Monitoring_Means
>> ),
>> but support for detecting unreachable remote nodes is only present in the
>> cluster module.
>>
>> I have coded the example and I have shut down the remote actor system
>> but it seems that the supervision strategy only takes into account
>> Exceptions thrown by the remote actor once reached.
>>
>>
>> Yes, that is correct.
>>
>> I have already implemented the subscription to the events that
>> indicates that error in the connection have occurred. I still need to 
>> have
>> access to message the sender sent originally so the message do not get 
>> lost.
>>
>>
>> There is nothing you can subscribe to which tells you whether a given
>> message was processed on the remote system. If you cannot lose messages
>> then you need to persist them and use explicit acknowledgements from the
>> receiving actor to retire 

Re: [akka-user] Not loosing message due to remote actor unavailable.

[Matan Safriel]

Thanks, good to know! Does it include a leader election process for when
the leader isn't available? I was not sure from the documentation whether
the leader is a single point of failure, or its relationship to seed nodes.
Maybe this should be a different thread.

On Fri, Jan 9, 2015 at 5:15 PM, Endre Varga 
wrote:

> Hi,
>
> On Fri, Jan 9, 2015 at 4:12 PM, Matan Safriel  wrote:
>
>> Thanks Patrik, good to know, because the cluster module may seem like a
>> very specific and rather unfinished reference implementation;
>>
>
> What do you mean by unfinished reference implementation? It is a fully
> supported module of Akka.
>
> -Endre
>
>
>> Good to have this in the core without relying on the cluster module.
>>
>> On Friday, January 9, 2015 at 11:25:30 AM UTC+2, Patrik Nordwall wrote:
>>>
>>>
>>>
>>> On Thu, Jan 8, 2015 at 9:56 PM, Matan Safriel  wrote:
>>>
 Sorry for awakening this old thread...
 Is it really the case that there is all this fancy supervision
 architecture, and then a remote actor that has gone non-responsive, needs
 to be handled outside of the supervision hierarchy alltogether? was it
 considered enabling supervision to work such that the supervisor would know
 in case its remote child has gone unresponsive/gated/quarantined?

>>>
>>> The information in this thread is outdated. We have added support for
>>> proper remote death watch also when using remoting only (without cluster).
>>>
>>>

 Perhaps I misinterpret the reference to the "cluster module" in the
 response by Dr. Roland Kuhn below.

 Thanks for clarifying,
 Matan

 On Thursday, January 31, 2013 at 10:13:26 PM UTC+2, rkuhn wrote:
>
> Hi Juan Pablo,
>
> 30 jan 2013 kl. 22:08 skrev Juan Pablo Vergara Villarraga:
>
> If a remote actor is not available due to power loss Can the
> supervision strategy handle the situation?
>
>
> No, loss of actors is managed by the Death Watch (
> http://doc.akka.io/docs/akka/2.1.0/general/supervision.html
> #What_Lifecycle_Monitoring_Means
> ),
> but support for detecting unreachable remote nodes is only present in the
> cluster module.
>
> I have coded the example and I have shut down the remote actor system
> but it seems that the supervision strategy only takes into account
> Exceptions thrown by the remote actor once reached.
>
>
> Yes, that is correct.
>
> I have already implemented the subscription to the events that
> indicates that error in the connection have occurred. I still need to have
> access to message the sender sent originally so the message do not get 
> lost.
>
>
> There is nothing you can subscribe to which tells you whether a given
> message was processed on the remote system. If you cannot lose messages
> then you need to persist them and use explicit acknowledgements from the
> receiving actor to retire them from the local storage. You will also need
> to implement resending and deduplication if you need exactly-once 
> delivery;
> you might want to read the documentation on message delivery guarantees:
> http://doc.akka.io/docs/akka/2.1.0/general/messa
> ge-delivery-guarantees.html
>
> Regards,
>
> Roland
>
> JP.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://akka.io/faq/
> >> 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 http://groups.google.com/group/akka-user?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
>
>
> *Dr. Roland Kuhn*
> *Akka Tech Lead*
> Typesafe  – Empowering professional developers
> to build amazing apps.
> twitter: @rolandkuhn 
>
>  --
 >> Read the docs: http://akka.io/docs/
 >> Check the FAQ: http://doc.akka.io/docs/akka/
 current/additional/faq.html
 >> Search the archives: https://groups.google.com/
 group/akka-user
 ---
 You received this message because you are subscribed to the Google
 Groups "Akka User List" group.
 To unsubscribe from this group and stop receiving emails from it, send
 an email to akka-user+...@googlegroups.com.
 To post to this group, send email to akka...@googlegroups.co

Re: [akka-user] Not loosing message due to remote actor unavailable.

[Endre Varga]

Hi,

On Fri, Jan 9, 2015 at 4:12 PM, Matan Safriel  wrote:

> Thanks Patrik, good to know, because the cluster module may seem like a
> very specific and rather unfinished reference implementation;
>

What do you mean by unfinished reference implementation? It is a fully
supported module of Akka.

-Endre


> Good to have this in the core without relying on the cluster module.
>
> On Friday, January 9, 2015 at 11:25:30 AM UTC+2, Patrik Nordwall wrote:
>>
>>
>>
>> On Thu, Jan 8, 2015 at 9:56 PM, Matan Safriel  wrote:
>>
>>> Sorry for awakening this old thread...
>>> Is it really the case that there is all this fancy supervision
>>> architecture, and then a remote actor that has gone non-responsive, needs
>>> to be handled outside of the supervision hierarchy alltogether? was it
>>> considered enabling supervision to work such that the supervisor would know
>>> in case its remote child has gone unresponsive/gated/quarantined?
>>>
>>
>> The information in this thread is outdated. We have added support for
>> proper remote death watch also when using remoting only (without cluster).
>>
>>
>>>
>>> Perhaps I misinterpret the reference to the "cluster module" in the
>>> response by Dr. Roland Kuhn below.
>>>
>>> Thanks for clarifying,
>>> Matan
>>>
>>> On Thursday, January 31, 2013 at 10:13:26 PM UTC+2, rkuhn wrote:

 Hi Juan Pablo,

 30 jan 2013 kl. 22:08 skrev Juan Pablo Vergara Villarraga:

 If a remote actor is not available due to power loss Can the
 supervision strategy handle the situation?


 No, loss of actors is managed by the Death Watch (
 http://doc.akka.io/docs/akka/2.1.0/general/supervision.html
 #What_Lifecycle_Monitoring_Means
 ),
 but support for detecting unreachable remote nodes is only present in the
 cluster module.

 I have coded the example and I have shut down the remote actor system
 but it seems that the supervision strategy only takes into account
 Exceptions thrown by the remote actor once reached.


 Yes, that is correct.

 I have already implemented the subscription to the events that
 indicates that error in the connection have occurred. I still need to have
 access to message the sender sent originally so the message do not get 
 lost.


 There is nothing you can subscribe to which tells you whether a given
 message was processed on the remote system. If you cannot lose messages
 then you need to persist them and use explicit acknowledgements from the
 receiving actor to retire them from the local storage. You will also need
 to implement resending and deduplication if you need exactly-once delivery;
 you might want to read the documentation on message delivery guarantees:
 http://doc.akka.io/docs/akka/2.1.0/general/message-delivery-guarantees.
 html

 Regards,

 Roland

 JP.

 --
 >> Read the docs: http://akka.io/docs/
 >> Check the FAQ: http://akka.io/faq/
 >> 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 http://groups.google.com/group/akka-user?hl=en.
 For more options, visit https://groups.google.com/groups/opt_out.






 *Dr. Roland Kuhn*
 *Akka Tech Lead*
 Typesafe  – Empowering professional developers
 to build amazing apps.
 twitter: @rolandkuhn 

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

Re: [akka-user] Not loosing message due to remote actor unavailable.

[Matan Safriel]

Thanks Patrik, good to know, because the cluster module may seem like a 
very specific and rather unfinished reference implementation; Good to have 
this in the core without relying on the cluster module. 

On Friday, January 9, 2015 at 11:25:30 AM UTC+2, Patrik Nordwall wrote:
>
>
>
> On Thu, Jan 8, 2015 at 9:56 PM, Matan Safriel  > wrote:
>
>> Sorry for awakening this old thread... 
>> Is it really the case that there is all this fancy supervision 
>> architecture, and then a remote actor that has gone non-responsive, needs 
>> to be handled outside of the supervision hierarchy alltogether? was it 
>> considered enabling supervision to work such that the supervisor would know 
>> in case its remote child has gone unresponsive/gated/quarantined?
>>
>
> The information in this thread is outdated. We have added support for 
> proper remote death watch also when using remoting only (without cluster).
>  
>
>>
>> Perhaps I misinterpret the reference to the "cluster module" in the 
>> response by Dr. Roland Kuhn below.
>>
>> Thanks for clarifying,
>> Matan
>>
>> On Thursday, January 31, 2013 at 10:13:26 PM UTC+2, rkuhn wrote:
>>>
>>> Hi Juan Pablo,
>>>
>>> 30 jan 2013 kl. 22:08 skrev Juan Pablo Vergara Villarraga:
>>>
>>> If a remote actor is not available due to power loss Can the supervision 
>>> strategy handle the situation?
>>>
>>>
>>> No, loss of actors is managed by the Death Watch (
>>> http://doc.akka.io/docs/akka/2.1.0/general/supervision.
>>> html#What_Lifecycle_Monitoring_Means 
>>> ),
>>>  
>>> but support for detecting unreachable remote nodes is only present in the 
>>> cluster module.
>>>
>>> I have coded the example and I have shut down the remote actor system 
>>> but it seems that the supervision strategy only takes into account 
>>> Exceptions thrown by the remote actor once reached.
>>>
>>>
>>> Yes, that is correct.
>>>
>>> I have already implemented the subscription to the events that indicates 
>>> that error in the connection have occurred. I still need to have access to 
>>> message the sender sent originally so the message do not get lost.
>>>
>>>
>>> There is nothing you can subscribe to which tells you whether a given 
>>> message was processed on the remote system. If you cannot lose messages 
>>> then you need to persist them and use explicit acknowledgements from the 
>>> receiving actor to retire them from the local storage. You will also need 
>>> to implement resending and deduplication if you need exactly-once delivery; 
>>> you might want to read the documentation on message delivery guarantees: 
>>> http://doc.akka.io/docs/akka/2.1.0/general/message-delivery-guarantees.
>>> html
>>>
>>> Regards,
>>>
>>> Roland
>>>
>>> JP.
>>>
>>> -- 
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: http://akka.io/faq/
>>> >> Search the archives: https://groups.google.com/
>>> group/akka-user
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/akka-user?hl=en.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>  
>>>  
>>>
>>>
>>>
>>>
>>> *Dr. Roland Kuhn*
>>> *Akka Tech Lead*
>>> Typesafe  – Empowering professional developers to 
>>> build amazing apps.
>>> twitter: @rolandkuhn 
>>>  
>>>  -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> Patrik Nordwall
> Typesafe  -  Reactive apps on the JVM
> Twitter: @patriknw
>
> 

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsub

Re: [akka-user] Re: File based mailbox - Files under _mb location grows large consistently without getting cleared

[Patrik Nordwall]

On Fri, Jan 9, 2015 at 9:35 AM,  wrote:

> Hi Jonas,
>
> Thanks for the reply. I can probably think of moving to Akka Persistence
> for our current release project. But, it will be impossible to do it for
> the previous version which is in production.
>
> Do we have any way to get it resolved i? We are on 2.1.0-2.2.1.
>

I don't think we will be able to investigate this in those old open source
versions.
You might be interested a Typesafe Subscription
 to mitigate problems like this in the
future.

Regards,
Patrik


>
> Regards,
> Anoop
>
> On Friday, January 9, 2015 at 1:25:42 PM UTC+5:30, Jonas Bonér wrote:
>>
>> Durable MBs are no longer supported. I recommend you to switch to Akka
>> Persistence (perhaps with the LevelDB Journal, since it is closest to your
>> durable MB). Is that possible?
>>
>> On Fri, Jan 9, 2015 at 7:27 AM,  wrote:
>>
>>> I could see a similar issue was discussed in the below thread from
>>> Daniele.
>>>
>>> https://groups.google.com/forum/#!searchin/akka-user/
>>> file$20based/akka-user/0Yt78n73a4o
>>>
>>> But, I couldn't find an answer there for the files growing big issue.
>>>
>>>
>>> On Friday, January 9, 2015 at 11:56:39 AM UTC+5:30, araman...@gmail.com
>>> wrote:

 Hi Akka Users,

 I have a problem with actors using the file based mailbox. The size of
 mailbox files under _mb folder keeps on increasing as the number of
 messages are processed. All messages are getting processed fine in the
 system, so shouldn't they be removed from the file when completed? I feel
 this is not happening, and the mailbox file grows in size finally eating up
 the diskspace. I do not understand why the messages are still kept in the
 mailbox when they are successfully processed.

 I am going with the default configuration values (journal size 16MB
 etc).  Are there any config options that I can use to clear the file
 contents once a message is processed?

 Regards,
 Anoop

>>>  --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: http://doc.akka.io/docs/akka/
>>> current/additional/faq.html
>>> >> Search the archives: https://groups.google.com/
>>> group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> *Jonas Bonér*
>> Home: jonasboner.com
>> Twitter: @jboner 
>> Public Key: keybase.io/jonas
>>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw

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

Re: [akka-user] Re: Unordered merge of 2..n streams created by groupBy

[Patrik Nordwall]

Hi Tim,

Thanks for your interest in contributing. That is of course welcome. Please
start by creating an issue, if there is no one already. I don't know if the
functionality or design needs any discussion, but that is something we can
do in the issue.
Base the pull request on branch release-2.3-dev.

Thanks,
Patrik

On Fri, Jan 9, 2015 at 12:35 AM, Tim Harper  wrote:

> Akka maintainers, how does this solution look (see mentioned gist in
> quoted text)? I'll probably need some degree of guidance, but this solution
> is working well for my needs; I'm happy to produce a pull-request for Akka
> streams to implement FlattenStrategy.mergeUnordered.
>
> On Wednesday, January 7, 2015 at 3:51:09 PM UTC-7, Tim Harper wrote:
>>
>> Gist is here: https://gist.github.com/timcharper/a6642275bfaebbd2194d
>>
>>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw

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

Re: [akka-user] Deficiencies in actor testability?

[Patrik Nordwall]

Let us say that methodB is a call to an external service (preferable
returning a Future, but that is irrelevant for the question).
That external service is not valid in some test environments and therefore
you want to stub it. Valid use case.

There are several ways to solve that. For example:
1) break out methodB into a class and a test implementation of that can be
injected in the constructor of ActorUnderTest
2) create a subclass of ActorUnderTest and override methodB with the test
behavior

What am I missing?

Regards,
Patrik

On Thu, Jan 8, 2015 at 12:27 AM,  wrote:

> The issue of testing business functionality that may be implemented in the
> class extending Actor has been raised quite a few times and I haven't found
> any good suggestions yet. Most Actor testing examples are focused around
> message receipt, type, timing etc. Akka team's response to this post
> https://groups.google.com/forum/#!topic/akka-user/tWAvAMMcOYs seems to be
> very dismissive. Why? This is legitimate issue! If there is no good way to
> test functionality provided by classes extending Actors then perhaps it
> should be stated please delegate such functionality to services etc.
>
> What is wrong with example 1, and if nothing, how it is different from
> example 2 where I want to stub methodB()?
>
> Example 1 from https://code.google.com/p/specs/wiki/UsingMockito
>   object spec extends Specification with Mockito {
>
> val m = mock[java.util.List[String]] // a concrete class would be
> mocked with: mock(new java.util.LinkedList[String])
>
> // stub a method call with a return value
> m.get(0) returns "one"
>
> ...
> }
>
> Example 2
>
> class ActorUnderTest extends Actor {
>  def receive = {
>   case TestMessage => methodA()
>  }
>
> def methodA() = {
>  methodB()
>  //doSomtehing
> }
>
> def methodB() = {
> 
> }
>
> }
>
> Andre Piwoni
>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw

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

Re: [akka-user] Not getting an "OnComplete" message for TCP Connection with Stream-M2 and Akka 2.3.7

[Patrik Nordwall]

Thanks for reporting.
/Patrik

On Wed, Jan 7, 2015 at 2:23 PM, Thomas Zimmer 
wrote:

> Hi,
>
> i created a simple application (
> https://gist.github.com/Alien2150/9468c871135fd94869a2) to play around
> with the SSL-Stream. But as soon as my client has been closed I am seeing
> this log-message (without receiving any OnComplete messages):
>
> [INFO] [01/07/2015 14:12:53.549] [app-akka.actor.default-dispatcher-15]
> [akka://
> app/system/IO-TCP/selectors/$a/1] Message [akka.io.Tcp$Abort$] from
> Actor[akka:/
> /app/system/IO-TCP-STREAM/server-1-%2F0.0.0.0%3A16500/$a#-536894325] to
> Actor[ak
> ka://app/system/IO-TCP/selectors/$a/1#-1566861189] was not delivered. [1]
> dead l
> etters encountered. This logging can be turned off or adjusted with
> configuratio
> n settings 'akka.log-dead-letters' and
> 'akka.log-dead-letters-during-shutdown'.
>
> I am not sure if this issue is related to:
> https://github.com/akka/akka/issues/16553
>
> Regards,
> Thomas
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw

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

[akka-user] Database Actor Read Model

[Andy Zelinski]

Lots of database actor questions, but I couldn't find one that directly 
addressed data size limits:

I want to send requests for data from a frontend to a Cluster Singleton 
which will forward each request to a Database Actor.

The database actor runs query, then from the Row result constructs a domain 
object. this works great for case class Tweet(id: TweetId, user: User, 
text: Text, createdAt: Date).

But what if we need to gather and pass around data from much wider tables 
than that?

say we need to gather a bunch of user data.  profile data, preference data, 
history, purchases, moderately large collection, etc. for use both by the 
akka cluster that performs our logic,

and also simply to pass data to the frontend for templating. Put simply, 
potentially much more than the 120Kb maximum-frame-size. 

thus the following conundrum: 

1. want to limit number of queries to database per data request, since that 
is the biggest bottleneck, area for headache. (although im using an async 
driver so its not as bad as blocking jdbc)
2. most data will be requested together, so want to to be able to get all 
row data in one query
3. thus the database actor will have too much data to send as a message 
back to its parent and ultimately to frontend actor

of course i could split the query results into multiple messages, but that 
necessitates changing the whole actor system.

can chunking or some kind of dedicated channel save me from having to 
completely re-think my backend?

thanks! 






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

Re: [akka-user] Akka Cluster node automatically joining.

[Konrad Malawski]

Ah, excellent idea! Thanks for chiming in Patrik :-)

— 
Cheers,
Konrad Malawski

From: Patrik Nordwall 
Reply: akka-user@googlegroups.com >
Date: January 9, 2015 at 12:10:08 PM
To: akka-user@googlegroups.com >
Cc: Bourne Toulouss >
Subject:  Re: [akka-user] Akka Cluster node automatically joining.  



On Fri, Jan 9, 2015 at 11:55 AM, Konrad Malawski  
wrote:
Hi Bourne,
automatic joining keep retrying until successful.

Since you have a very specific way you want this to happen, you should drive 
the joining programatically,
refer to 
http://doc.akka.io/docs/akka/current/scala/cluster-usage.html#joining-to-seed-nodes
 for details on how to go about this.

I have another suggestion.
Setup a Cluster listener, and if you don't receive MemberUp for 
Cluster(system).selfAddress within your desired timeout you shutdown.

Cheers,
Patrik
 

— 
Cheers,
Konrad Malawski

From: Bourne Toulouss 
Reply: akka-user@googlegroups.com >
Date: January 9, 2015 at 9:56:06 AM
To: akka-user@googlegroups.com >
Subject:  [akka-user] Akka Cluster node automatically joining.

Hi all,
At the moment, i have a java application with akka that uses master and slave 
architecture.
masters and workers starts randomly.
I want it so if no master's been started yet, then worker will tryto join the 
cluster with seed nodes as the nodes that the masters reside for a number of 
times, then after a number of retries, i want to shut down the jvm of worker .
I've looked over the docs and saw the seed-node-timeout and 
retry-unsuccessful-join-after,  but that doesnt do anything about the times  of 
retries only the duration of the retry
what would you suggest me do in this case.
Thank you in advanced for your help.
Cheers,
Bourne.
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.



--
Patrik Nordwall
Typesafe -  Reactive apps on the JVM
Twitter: @patriknw

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

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

Re: [akka-user] Akka Cluster node automatically joining.

[Patrik Nordwall]

On Fri, Jan 9, 2015 at 11:55 AM, Konrad Malawski <
konrad.malaw...@typesafe.com> wrote:

> Hi Bourne,
> automatic joining keep retrying until successful.
>
> Since you have a very specific way you want this to happen, you should
> drive the joining programatically,
> refer to
> http://doc.akka.io/docs/akka/current/scala/cluster-usage.html#joining-to-seed-nodes
>  for
> details on how to go about this.
>

I have another suggestion.
Setup a Cluster listener
,
and if you don't receive MemberUp for Cluster(system).selfAddress within
your desired timeout you shutdown.

Cheers,
Patrik


>
> —
> Cheers,
> Konrad Malawski
> 
>
> From: Bourne Toulouss 
> 
> Reply: akka-user@googlegroups.com >
> 
> Date: January 9, 2015 at 9:56:06 AM
> To: akka-user@googlegroups.com >
> 
> Subject:  [akka-user] Akka Cluster node automatically joining.
>
>  Hi all,
> At the moment, i have a java application with akka that uses master and
> slave architecture.
> masters and workers starts randomly.
> I want it so if no master's been started yet, then worker will tryto join
> the cluster with seed nodes as the nodes that the masters reside for a
> number of times, then after a number of retries, i want to shut down the
> jvm of worker .
> I've looked over the docs and saw the seed-node-timeout and
> retry-unsuccessful-join-after,  but that doesnt do anything about the
> times  of retries only the duration of the retry
>  what would you suggest me do in this case.
>  Thank you in advanced for your help.
> Cheers,
> Bourne.
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw

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

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

[Viktor Klang]

On Fri, Jan 9, 2015 at 11:56 AM, Greg Young  wrote:

> Usually it comes down to the realization that the computer is not the book
> of record. One of my favourites was being asked to build a fully consistent
> inventory system. I generally like to approach things with questions, the
> one i had was 'sure but how do we get people who are stealing stuff to
> appropriately check it out?'
>
+Long.MAX_VALUE on this. Building warehouse management systems is very
eye-opening.



> On 9 Jan 2015 12:02, "Sebastian Bach" 
> wrote:
>
>>
>> Thank you Greg. The mind shift from a preventive to a reactive workflow
>> is not easy for users (humans), because it requires a change of habits. For
>> many people computer systems are kind of authoritative. There is this wrong
>> assumption (from early days of computation?) that a computer accepts only a
>> valid input or returns an error. It was then only black or white, the
>> golden era of transactions. But this was (as you pointed out) always to
>> some degree an hypocrisy. Now we have this shades of gray and many users
>> feel unsettled. This holds true for any kind of resource allocation
>> application and the overbooking (or wrong booking) problem. Some of the
>> users define taking workload off of them as avoiding of planning mistakes,
>> like commit and forget. But the actual workflow seems to shift towards an
>> iterative process of human-computer interaction, to some kind of
>> react-react ping-pong.
>>
>> Best Regards
>> Sebastian
>>
>>
>> W dniu środa, 7 stycznia 2015 22:15:42 UTC+1 użytkownik Greg Young
>> napisał:
>>>
>>> "The consistency of the query model should be achieved as soon as
>>> possible and close to real-time."
>>>
>>> It really depends on the domain. I have worked in many situations
>>> where the data in question would be perfectly fine updated once per
>>> month.
>>>
>>> " (e.g. adding a sold out item to the shopping cart)."
>>>
>>> This is a funny example because it shows not that you need to update
>>> read models more quickly but that you need to get the whole business
>>> on board. Remember that computer systems are normally part of a larger
>>> system fulfilling business needs. It really is a mind shift moving to
>>> eventual consistency.
>>>
>>> In the example of adding a sold out item... why stop it? Does it
>>> matter that we don't have any of this item? The real question is how
>>> quickly we can get it and if its worth our while to do so. To be fair
>>> 30 years ago these times were much much higher than what we talk about
>>> today and yet businesses still managed to work their way through
>>> things.
>>>
>>> For many of these types allowing things to go incorrectly is actually
>>> a good thing (overbooked seats on an airline, overdraft charges at
>>> banks...). To really be benefiting from eventual consistency the whole
>>> business process must recognize it. In terms of handling failures they
>>> are normally handled in a reactive not a preventative manner (like
>>> most business problems). Detect the failure, let a human deal with it.
>>>
>>> At the end of the day the primary role of the computer system is to
>>> take workload off of humans. You will hit the law of diminishing
>>> returns. dont try to solve every problem :)
>>>
>>> Greg
>>>
>>> On Wed, Jan 7, 2015 at 11:07 PM, Sebastian Bach
>>>  wrote:
>>> > Hi Roland,
>>> >
>>> > one thing to keep in mind in the CQRS/ES architecture is that not only
>>> the
>>> > query side depends on the command side (by following the event stream)
>>> but
>>> > also the command side depends on the query side for validation of
>>> complex
>>> > business rules. This has a deep impact on correctness and throughput.
>>> > Validation checks on an potentially outdated query model in an
>>> eventually
>>> > consistent architecture is a hard problem (e.g. adding a sold out item
>>> to
>>> > the shopping cart). The consistency of the query model should be
>>> achieved as
>>> > soon as possible and close to real-time. A PersistentView in Akka has
>>> a
>>> > default of 5s? On the other hand the speed of validation depends on
>>> the
>>> > speed of the queries. And the throughput depends on the validation
>>> speed.
>>> > Thus, queries directly on the whole event stream are less useful than
>>> > persistent projections.
>>> >
>>> > Keep up the good work :)
>>> > Cheers
>>> > Sebastian
>>> >
>>> >
>>> > W dniu wtorek, 7 października 2014 07:32:20 UTC+2 użytkownik rkuhn
>>> napisał:
>>> >>
>>> >> Hi Vaughn,
>>> >>
>>> >> from our side nothing has happened yet: my conclusion is that this
>>> thread
>>> >> contains all the information we need when we start working on this.
>>> The
>>> >> reason why we are waiting is that this work will depend heavily upon
>>> Akka
>>> >> Streams and therefore we are finishing those first, which should take
>>> >> roughly one month. Meanwhile, if use cases come up which could be
>>> used to
>>> >> refine the plans, please point them out here so that we can take all
>>> the
>>> >> 

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

[Greg Young]

Usually it comes down to the realization that the computer is not the book
of record. One of my favourites was being asked to build a fully consistent
inventory system. I generally like to approach things with questions, the
one i had was 'sure but how do we get people who are stealing stuff to
appropriately check it out?'
On 9 Jan 2015 12:02, "Sebastian Bach" 
wrote:

>
> Thank you Greg. The mind shift from a preventive to a reactive workflow is
> not easy for users (humans), because it requires a change of habits. For
> many people computer systems are kind of authoritative. There is this wrong
> assumption (from early days of computation?) that a computer accepts only a
> valid input or returns an error. It was then only black or white, the
> golden era of transactions. But this was (as you pointed out) always to
> some degree an hypocrisy. Now we have this shades of gray and many users
> feel unsettled. This holds true for any kind of resource allocation
> application and the overbooking (or wrong booking) problem. Some of the
> users define taking workload off of them as avoiding of planning mistakes,
> like commit and forget. But the actual workflow seems to shift towards an
> iterative process of human-computer interaction, to some kind of
> react-react ping-pong.
>
> Best Regards
> Sebastian
>
>
> W dniu środa, 7 stycznia 2015 22:15:42 UTC+1 użytkownik Greg Young napisał:
>>
>> "The consistency of the query model should be achieved as soon as
>> possible and close to real-time."
>>
>> It really depends on the domain. I have worked in many situations
>> where the data in question would be perfectly fine updated once per
>> month.
>>
>> " (e.g. adding a sold out item to the shopping cart)."
>>
>> This is a funny example because it shows not that you need to update
>> read models more quickly but that you need to get the whole business
>> on board. Remember that computer systems are normally part of a larger
>> system fulfilling business needs. It really is a mind shift moving to
>> eventual consistency.
>>
>> In the example of adding a sold out item... why stop it? Does it
>> matter that we don't have any of this item? The real question is how
>> quickly we can get it and if its worth our while to do so. To be fair
>> 30 years ago these times were much much higher than what we talk about
>> today and yet businesses still managed to work their way through
>> things.
>>
>> For many of these types allowing things to go incorrectly is actually
>> a good thing (overbooked seats on an airline, overdraft charges at
>> banks...). To really be benefiting from eventual consistency the whole
>> business process must recognize it. In terms of handling failures they
>> are normally handled in a reactive not a preventative manner (like
>> most business problems). Detect the failure, let a human deal with it.
>>
>> At the end of the day the primary role of the computer system is to
>> take workload off of humans. You will hit the law of diminishing
>> returns. dont try to solve every problem :)
>>
>> Greg
>>
>> On Wed, Jan 7, 2015 at 11:07 PM, Sebastian Bach
>>  wrote:
>> > Hi Roland,
>> >
>> > one thing to keep in mind in the CQRS/ES architecture is that not only
>> the
>> > query side depends on the command side (by following the event stream)
>> but
>> > also the command side depends on the query side for validation of
>> complex
>> > business rules. This has a deep impact on correctness and throughput.
>> > Validation checks on an potentially outdated query model in an
>> eventually
>> > consistent architecture is a hard problem (e.g. adding a sold out item
>> to
>> > the shopping cart). The consistency of the query model should be
>> achieved as
>> > soon as possible and close to real-time. A PersistentView in Akka has a
>> > default of 5s? On the other hand the speed of validation depends on the
>> > speed of the queries. And the throughput depends on the validation
>> speed.
>> > Thus, queries directly on the whole event stream are less useful than
>> > persistent projections.
>> >
>> > Keep up the good work :)
>> > Cheers
>> > Sebastian
>> >
>> >
>> > W dniu wtorek, 7 października 2014 07:32:20 UTC+2 użytkownik rkuhn
>> napisał:
>> >>
>> >> Hi Vaughn,
>> >>
>> >> from our side nothing has happened yet: my conclusion is that this
>> thread
>> >> contains all the information we need when we start working on this.
>> The
>> >> reason why we are waiting is that this work will depend heavily upon
>> Akka
>> >> Streams and therefore we are finishing those first, which should take
>> >> roughly one month. Meanwhile, if use cases come up which could be used
>> to
>> >> refine the plans, please point them out here so that we can take all
>> the
>> >> inputs into account.
>> >>
>> >> Regards,
>> >>
>> >> Roland
>> >>
>> >> 6 okt 2014 kl. 20:09 skrev Vaughn Vernon :
>> >>
>> >> Hi Roland,
>> >>
>> >> I's been a month this the last update on this and I have lost track of
>> the
>> >> status.
>> >>
>> >> Can you provide

Re: [akka-user] Akka Cluster node automatically joining.

[Konrad Malawski]

Hi Bourne,
automatic joining keep retrying until successful.

Since you have a very specific way you want this to happen, you should drive 
the joining programatically,
refer to 
http://doc.akka.io/docs/akka/current/scala/cluster-usage.html#joining-to-seed-nodes
 for details on how to go about this.

— 
Cheers,
Konrad Malawski

From: Bourne Toulouss 
Reply: akka-user@googlegroups.com >
Date: January 9, 2015 at 9:56:06 AM
To: akka-user@googlegroups.com >
Subject:  [akka-user] Akka Cluster node automatically joining.  

Hi all,
At the moment, i have a java application with akka that uses master and slave 
architecture.
masters and workers starts randomly.
I want it so if no master's been started yet, then worker will tryto join the 
cluster with seed nodes as the nodes that the masters reside for a number of 
times, then after a number of retries, i want to shut down the jvm of worker .
I've looked over the docs and saw the seed-node-timeout and 
retry-unsuccessful-join-after,  but that doesnt do anything about the times  of 
retries only the duration of the retry
what would you suggest me do in this case.
Thank you in advanced for your help.
Cheers,
Bourne.
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

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

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

[Sebastian Bach]

Thank you Greg. The mind shift from a preventive to a reactive workflow is 
not easy for users (humans), because it requires a change of habits. For 
many people computer systems are kind of authoritative. There is this wrong 
assumption (from early days of computation?) that a computer accepts only a 
valid input or returns an error. It was then only black or white, the 
golden era of transactions. But this was (as you pointed out) always to 
some degree an hypocrisy. Now we have this shades of gray and many users 
feel unsettled. This holds true for any kind of resource allocation 
application and the overbooking (or wrong booking) problem. Some of the 
users define taking workload off of them as avoiding of planning mistakes, 
like commit and forget. But the actual workflow seems to shift towards an 
iterative process of human-computer interaction, to some kind of 
react-react ping-pong.

Best Regards
Sebastian


W dniu środa, 7 stycznia 2015 22:15:42 UTC+1 użytkownik Greg Young napisał:
>
> "The consistency of the query model should be achieved as soon as 
> possible and close to real-time." 
>
> It really depends on the domain. I have worked in many situations 
> where the data in question would be perfectly fine updated once per 
> month. 
>
> " (e.g. adding a sold out item to the shopping cart)." 
>
> This is a funny example because it shows not that you need to update 
> read models more quickly but that you need to get the whole business 
> on board. Remember that computer systems are normally part of a larger 
> system fulfilling business needs. It really is a mind shift moving to 
> eventual consistency. 
>
> In the example of adding a sold out item... why stop it? Does it 
> matter that we don't have any of this item? The real question is how 
> quickly we can get it and if its worth our while to do so. To be fair 
> 30 years ago these times were much much higher than what we talk about 
> today and yet businesses still managed to work their way through 
> things. 
>
> For many of these types allowing things to go incorrectly is actually 
> a good thing (overbooked seats on an airline, overdraft charges at 
> banks...). To really be benefiting from eventual consistency the whole 
> business process must recognize it. In terms of handling failures they 
> are normally handled in a reactive not a preventative manner (like 
> most business problems). Detect the failure, let a human deal with it. 
>
> At the end of the day the primary role of the computer system is to 
> take workload off of humans. You will hit the law of diminishing 
> returns. dont try to solve every problem :) 
>
> Greg 
>
> On Wed, Jan 7, 2015 at 11:07 PM, Sebastian Bach 
> > wrote: 
> > Hi Roland, 
> > 
> > one thing to keep in mind in the CQRS/ES architecture is that not only 
> the 
> > query side depends on the command side (by following the event stream) 
> but 
> > also the command side depends on the query side for validation of 
> complex 
> > business rules. This has a deep impact on correctness and throughput. 
> > Validation checks on an potentially outdated query model in an 
> eventually 
> > consistent architecture is a hard problem (e.g. adding a sold out item 
> to 
> > the shopping cart). The consistency of the query model should be 
> achieved as 
> > soon as possible and close to real-time. A PersistentView in Akka has a 
> > default of 5s? On the other hand the speed of validation depends on the 
> > speed of the queries. And the throughput depends on the validation 
> speed. 
> > Thus, queries directly on the whole event stream are less useful than 
> > persistent projections. 
> > 
> > Keep up the good work :) 
> > Cheers 
> > Sebastian 
> > 
> > 
> > W dniu wtorek, 7 października 2014 07:32:20 UTC+2 użytkownik rkuhn 
> napisał: 
> >> 
> >> Hi Vaughn, 
> >> 
> >> from our side nothing has happened yet: my conclusion is that this 
> thread 
> >> contains all the information we need when we start working on this. The 
> >> reason why we are waiting is that this work will depend heavily upon 
> Akka 
> >> Streams and therefore we are finishing those first, which should take 
> >> roughly one month. Meanwhile, if use cases come up which could be used 
> to 
> >> refine the plans, please point them out here so that we can take all 
> the 
> >> inputs into account. 
> >> 
> >> Regards, 
> >> 
> >> Roland 
> >> 
> >> 6 okt 2014 kl. 20:09 skrev Vaughn Vernon : 
> >> 
> >> Hi Roland, 
> >> 
> >> I's been a month this the last update on this and I have lost track of 
> the 
> >> status. 
> >> 
> >> Can you provide an update on where this stands? Is there a more recent 
> >> akka-persistence build that supports the conclusions reached in this 
> >> discussion? If so, what is the release number? If no, when is will the 
> >> proposed features be released? 
> >> 
> >> Best, 
> >> Vaughn 
> >> 
> >> On Fri, Sep 5, 2014 at 1:09 AM, Roland Kuhn  wrote: 
> >>> 
> >>> Attempting a second round-up of what shall go into tic

Re: [akka-user] Not loosing message due to remote actor unavailable.

[Patrik Nordwall]

On Thu, Jan 8, 2015 at 9:56 PM, Matan Safriel  wrote:

> Sorry for awakening this old thread...
> Is it really the case that there is all this fancy supervision
> architecture, and then a remote actor that has gone non-responsive, needs
> to be handled outside of the supervision hierarchy alltogether? was it
> considered enabling supervision to work such that the supervisor would know
> in case its remote child has gone unresponsive/gated/quarantined?
>

The information in this thread is outdated. We have added support for
proper remote death watch also when using remoting only (without cluster).


>
> Perhaps I misinterpret the reference to the "cluster module" in the
> response by Dr. Roland Kuhn below.
>
> Thanks for clarifying,
> Matan
>
> On Thursday, January 31, 2013 at 10:13:26 PM UTC+2, rkuhn wrote:
>>
>> Hi Juan Pablo,
>>
>> 30 jan 2013 kl. 22:08 skrev Juan Pablo Vergara Villarraga:
>>
>> If a remote actor is not available due to power loss Can the supervision
>> strategy handle the situation?
>>
>>
>> No, loss of actors is managed by the Death Watch (
>> http://doc.akka.io/docs/akka/2.1.0/general/supervision.
>> html#What_Lifecycle_Monitoring_Means
>> ),
>> but support for detecting unreachable remote nodes is only present in the
>> cluster module.
>>
>> I have coded the example and I have shut down the remote actor system but
>> it seems that the supervision strategy only takes into account Exceptions
>> thrown by the remote actor once reached.
>>
>>
>> Yes, that is correct.
>>
>> I have already implemented the subscription to the events that indicates
>> that error in the connection have occurred. I still need to have access to
>> message the sender sent originally so the message do not get lost.
>>
>>
>> There is nothing you can subscribe to which tells you whether a given
>> message was processed on the remote system. If you cannot lose messages
>> then you need to persist them and use explicit acknowledgements from the
>> receiving actor to retire them from the local storage. You will also need
>> to implement resending and deduplication if you need exactly-once delivery;
>> you might want to read the documentation on message delivery guarantees:
>> http://doc.akka.io/docs/akka/2.1.0/general/message-delivery-guarantees.
>> html
>>
>> Regards,
>>
>> Roland
>>
>> JP.
>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: http://akka.io/faq/
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to akka-user+...@googlegroups.com.
>> To post to this group, send email to akka...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/akka-user?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>>
>>
>>
>> *Dr. Roland Kuhn*
>> *Akka Tech Lead*
>> Typesafe  – Empowering professional developers to
>> build amazing apps.
>> twitter: @rolandkuhn 
>>
>>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw

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

Re: [akka-user] Re: Actor lifecycle with regard to unresponsive actors

[Patrik Nordwall]

On Thu, Jan 8, 2015 at 9:37 PM, Matan Safriel  wrote:

> Thanks for the reminder. The Phi Accrual Failure Detector is nice,
> although it is unfortunate that tuning the threshold is an art (see mention
> of EC2 in http://doc.akka.io/docs/akka/snapshot/scala/remoting.html
> 
> ).
>

In practise the acceptable-heartbeat-pause is the only thing that you will
adjust.


> I wonder what may "inconsistent" mean in "In the face of communication
> failures that are unrecoverable because the state of the participating
> systems are inconsistent, the remote system becomes Quarantined. "
>

For example, system messages could not be delivered. System messages are
used for things like watch, remote deployment, supervision. System messages
are acknowledged and retried if lost and are therefore normally delivered
reliably, but for example the system redelivery buffer is limited in size
and if that is exceeded there is no way back, and the system must be
quarantined.


>
> Thanks in advance!
>
>
> On Thursday, January 8, 2015 at 6:29:48 PM UTC+2, bearrito wrote:
>>
>> Your first step would probably be the documentation at :
>> http://doc.akka.io/docs/akka/snapshot/scala/remoting.html
>> 
>>
>> In particular the sections - "Lifecycle and Failure Recovery Model"
>>
>> You could also have a look at http://doc.akka.io/docs/akka/
>> snapshot/general/configuration.html and any of the sections with
>> keywords "gated,retry,quarantine"
>>
>> -b
>>
>> On Thursday, January 8, 2015 4:12:08 AM UTC-5, Matan Safriel wrote:
>>>
>>> Hi,
>>>
>>> I have read this other thread about the case of a remote being
>>> unavailable
>>> .
>>> I assume it still applies to the most current version (?).
>>>
>>
No, that looks old. We have added support for remote death watch.


>
>>> My question is, how do both the supervision system (the part that's
>>> above user code) and the death watch, in short, Akka, determine that a
>>> remote is unavailable, and whether that is in any way configurable. I may
>>> assume some polling is relied upon and wonder how exactly does it reach
>>> that determination of "unavailability".
>>>
>>
Heartbeat messages are sent between the nodes, and the inter-arrival times
are fed into the failure detector, which detects unreachability.


>
>>> In the same vein, I would like to ask whether actors perform any sort of
>>> retry of their own, in case they determine that they *failed* *sending
>>> or replying to *a message. Or is it the case that message sending is a
>>> "one time attempt".
>>>
>>
No, normal message delivery is at-most-once
.
There is an utility for at-least-once

delivery.


> Pointers to relevant source code are also welcome.
>>>
>>> Thanks in advance,
>>> Matan
>>>
>>> *P.S. in case relevant changes are on the roadmap, it would be also cool
>>> to know about 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 http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw

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

[akka-user] Akka Cluster node automatically joining.

[Bourne Toulouss]

Hi all,
At the moment, i have a java application with akka that uses master and 
slave architecture.
masters and workers starts randomly.
I want it so if no master's been started yet, then worker will tryto join 
the cluster with seed nodes as the nodes that the masters reside for a 
number of times, then after a number of retries, i want to shut down the 
jvm of worker .
I've looked over the docs and saw the seed-node-timeout and 
retry-unsuccessful-join-after, 
 but that doesnt do anything about the times  of retries only the duration 
of the retry
what would you suggest me do in this case.
Thank you in advanced for your help.
Cheers,
Bourne.

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

Re: [akka-user] TimeoutException when using tell on an ActorSelection if the target actor is created through AskSupport

[Patrik Nordwall]

Hi Ferdinand,

Let me try to understand your original problem. You send a request with ask
to an Actor with AtLeastOnceDelivery. There you reply to the sender() using
the deliver method (and the path of the sender()). Is that what you are
doing?

/Patrik


On Wed, Jan 7, 2015 at 8:07 PM, Ferdinand Hübner <
ferdinand.hueb...@gmail.com> wrote:

> Hello,
>
> I am experimenting with at-least-once-delivery in akka-persistence. My
> goal is to create a future-based service layer on top of an actor system by
> using AskSupport.
>
> The deliver method in AtLeastOnceDelivery expects an ActorPath as its
> message destination and delivers the message by using tell on an
> ActorSelection created from the ActorPath.
> Using tell on an ActorSelection always results in a TimeoutException in my
> unit tests if the target of the ActorSelection is a temporary actor created
> by AskSupport.
>
> I created a test-case on github that can be used to reproduce the problem:
> https://github.com/ferdinandhuebner/akka-asksupport-actorselection
>
> Here's a direkt link to the test-suite:
>
> https://github.com/ferdinandhuebner/akka-asksupport-actorselection/blob/master/src/test/scala/ActorSelectionVsAskSupportSuite.scala
>
> I tested with Java 1.8, 1.7 and akka 2.3.8, 2.3.7, 2.3.4 and 2.3.2, the
> result is always the same.
>
> Is this an expected behaviour of ActorSelection and temporary actors
> created through AskSupport?
>
> What I can tell from debugging the code: ActorSelection#deliverSelection
> doesn't seem to be able to resolve the temporary actor.
> After a few recursions it ends in a case that is commented with "foreign
> ref" and calls tell on an ActorRef [akka://test/temp] instead of
> [akka://test/temp/$a]
>
> I added another test-case with a proxy intermediary that receives the
> message from the AskSupport actor and sends it to the desired target. That
> code works fine. However, I want to avoid creating proxy actors.
> I don't think that I'm accidentally blocking somewhere in my test-code,
> since the test with the proxy actor runs fine.
>
> If anybody can share any hints or feedback, I would appreciate it.
>
> Thank you,
> Ferdinand
>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw

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

Re: [akka-user] Akka Cluster: consistent hashing with balancing?

[Patrik Nordwall]

Hi Hector,

On Wed, Jan 7, 2015 at 4:29 PM, Héctor Veiga  wrote:

> Hello,
>
> I have a setup of 5 nodes running clustered using Akka Cluster (Akka
> 2.3.7) and I am using a consistent-hashing router to spread the load among
> all nodes. My consistent key is based on a String and I have verified that
> the number of actors creating in the cluster is almost evenly distributed.
> However, my problem is that for some particular keys there is around 3x
> more load than for the rest. This leads to have an unbalanced data
> processing cluster where some nodes are processing around 5000 messages per
> second and some others just 2000.
>
> Is there a way to distribute the actors in the cluster in a way that when
> a new actor for a new consistent hash key is created, the actor is created
> in the node that is processing less data?
>

I'm afraid that is not possible with the consistent hashing router or any
of the other built-in tools. You have to develop that yourself with an
ordinary actor.

Regards,
Patrik


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



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw

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

Re: [akka-user] Re: File based mailbox - Files under _mb location grows large consistently without getting cleared

[aramankandath]

Hi Jonas,

Thanks for the reply. I can probably think of moving to Akka Persistence 
for our current release project. But, it will be impossible to do it for 
the previous version which is in production.

Do we have any way to get it resolved i? We are on 2.1.0-2.2.1.

Regards,
Anoop

On Friday, January 9, 2015 at 1:25:42 PM UTC+5:30, Jonas Bonér wrote:
>
> Durable MBs are no longer supported. I recommend you to switch to Akka 
> Persistence (perhaps with the LevelDB Journal, since it is closest to your 
> durable MB). Is that possible? 
>
> On Fri, Jan 9, 2015 at 7:27 AM, > wrote:
>
>> I could see a similar issue was discussed in the below thread from 
>> Daniele.
>>
>>
>> https://groups.google.com/forum/#!searchin/akka-user/file$20based/akka-user/0Yt78n73a4o
>>
>> But, I couldn't find an answer there for the files growing big issue.
>>
>>
>> On Friday, January 9, 2015 at 11:56:39 AM UTC+5:30, araman...@gmail.com 
>> wrote:
>>>
>>> Hi Akka Users,
>>>
>>> I have a problem with actors using the file based mailbox. The size of 
>>> mailbox files under _mb folder keeps on increasing as the number of 
>>> messages are processed. All messages are getting processed fine in the 
>>> system, so shouldn't they be removed from the file when completed? I feel 
>>> this is not happening, and the mailbox file grows in size finally eating up 
>>> the diskspace. I do not understand why the messages are still kept in the 
>>> mailbox when they are successfully processed.
>>>
>>> I am going with the default configuration values (journal size 16MB 
>>> etc).  Are there any config options that I can use to clear the file 
>>> contents once a message is processed?
>>>
>>> Regards,
>>> Anoop
>>>
>>  -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> *Jonas Bonér*
> Home: jonasboner.com
> Twitter: @jboner 
> Public Key: keybase.io/jonas
>  

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

Re: [akka-user] support for akka persistent plugins

[Patrik Nordwall]

Hi Tim,

None of the external plugins are officially supported by Typesafe. You
can contact
Typesafe  to discuss it and at least
let Typesafe know that you would be interested in such support.

I think geteventstore  offers commercial
support for their plugin and backend store.

Regards,
Patrik

On Thu, Jan 8, 2015 at 11:43 AM, Tim Pigden  wrote:

> Which, if any, of the main target plugins (Cassandra, etc) are supported
> by Typesafe or commercially via other parties?
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw

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

Re: [akka-user] Re: is this a sensible problem for persistence?

[Patrik Nordwall]

On Thu, Jan 8, 2015 at 11:59 AM, Tim Pigden  wrote:

> Hmm - on reading other threads and reflection I think I may have the wrong
> model here. The information about the ETA is possibly not something that
> should be persisted. It's not hard data. And perhaps my parcel should be
> split between a persisting actor (still need 1m of them) and some sort of
> query object that reflects current ETA and the real object is only updated
> in response to materialisation of the ETA (i.e. sending it to the customer
> as advice) in which case it's the advice history that's the thing to
> persist.
>

That sounds good.
/Patrik


>
> Is anyone encountering similar modelling issues?
>
> On Thursday, January 8, 2015 10:34:10 AM UTC, Tim Pigden wrote:
>>
>> Hi
>> I'm looking at modelling a large parcel delivery system with
>> approximately 300k - 1m parcels per day depending on time of year. Each of
>> those parcels has its own life cycle from assignment to a trip through
>> eventual delivery. If parcels are on a route, then, for example, a delivery
>> event at position 5 on the route will cause an update of the ETA for
>> parcels 6 - n where n could be 100 or so.
>> A parcel in position 50 might receive 60 such updates up until it is
>> successfully delivered and therefore "retired" from active consideration.
>>
>> I'm estimating that with 0.5m parcels and an 8 hour working day, I'll get
>> around 20 delivery notifications per second, each generating a cascade of
>> up to 100 new ETAs - so around 2000 updates/second. In the morning, around
>> 8am and 9am these numbers will peak as high priority orders tend to cluster
>> well geographically so the drivers hit more deliveries in a shorter space
>> of time - so say at Christmas peak we could get up to 5000 updates/second
>> for brief periods.
>>
>> Now I'm not a big data guy. To me this is immense, but realistically is
>> this going to cause any problem for Akka persistence? Is up to 1m separate
>> actor processors a sensible thing to have? There are alternative ways to
>> model it - the updates are internally generated at the vehicle level (so
>> theoretically I only need to persist the incoming vehicle signals) but the
>> parcel life cycle extends beyond the duration of the vehicle trip so that
>> could get messy.
>>
>>
>>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

Patrik Nordwall
Typesafe  -  Reactive apps on the JVM
Twitter: @patriknw

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