[akka-user] Save 2 snapshots at the same time?

[Karthik Chandraraj]

Hi,

In my code, I am saving snapshots frequently (For every message received by 
the Actor, to achieve durability)
I was going thru the LocalSnapshotStore code and found that snapshots are 
stored with current_time_millisec as filename. 
What if my code saves 2 snapshot at the same millisec? Will I loose the 
first data?

Thanks,
C.Karthik

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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] Confusion about durable mailboxes superseded by akka-persistence?

[Karthik Chandraraj]

Hi,

As per the suggestion, I implemented a QueueActor, which will saveSnapshot 
for every message it receives or removed. And then a ProcessActor, which 
will read the message from the QueueActor to process it.

Is this the right way to implement durable mailbox with akka-persistence?
Problem I see with this approach is, for every message, the data is written 
to the file. Can we achieve durability only with this performance hit?

Thanks,
C.Karthik


On Thursday, November 13, 2014 7:58:01 PM UTC+5:30, Martynas Mickevičius 
wrote:
>
> Hi Karthik,
>
> akka-persistence does not replace but supersede durable mailboxes. That 
> means if one wants to have an Actor that does not loose messages upon being 
> killed then sender must use AtLeastOnce delivery trait (or some other means 
> of durability with akka-persistence or not) to deliver messages to that 
> Actor.
>
> Let me know if that helped.
>
> On Wed, Nov 12, 2014 at 2:03 PM, Karthik Chandraraj  > wrote:
>
>> Consider there are 100 messages in the mailbox and the actor is 
>> processing the first.
>> If the process is killed, what happens to the 99 messages?
>>
>> When I was searching about this, I came across durable mailboxes, but the 
>> doc says 'durable mailboxes superseded by akka-persistence'. 
>> When I went though akka persistence, it said the actor state can be 
>> persisted, it doesn't talk about mailboxes? using akka-persistence, actors 
>> state can be stored, but what about messages that are in the mailbox and 
>> not received?
>>
>> can someone please explain?
>>
>> -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to 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.
>>
>
>
>
> -- 
> Martynas Mickevičius
> Typesafe  – Reactive 
>  Apps on the JVM
>  

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

Re: [akka-user] Re: Pooled Async Actor Architecture

[Konrad 'ktoso' Malawski]

Using that `id` is *safe*.
Let me maybe explain by example why closing over sender is not safe when it 
seems as if it’s the same thing “from the outside"…

So `sender()` is not a value, it’s a `def` which has an underlying `var`. That 
var is changed each time a message arrives to the Actor,
to point to the sender of that message. This leads to the problem why closing 
over sender is not safe.
Two hints here: 
1) you can write `sender()` instead of `sender` to remind yourself about “oh 
man, but this is a method, not a value!”
2) we want to remove sender all together from akka 3 - but that’s waaay ahead 
of us, but we know we’ll want to remove it as it’s unsafe.

So, back to the example:

I get a message “a",
sender is A,
I start my future to process “a",
I get another message “b”,
sender is set to B,
future triggers and accesses sender(),
sender returns B.

So that’s the problem scenario.
Whereas closing over any `val` is completely safe, because noone will swap 
things in it (id is a val in your case - as I assume CalculateFor is a case 
class).

Hope this explains things in more depth!
Happy hakking!

— konrad

On 21 November 2014 at 00:55:12, David (davidlu...@gmail.com) wrote:

Thanks very much for your reply, Konrad.

Could you tell me if the state of "id" is preserved when the future returns?

I would assume "No", since I don't see how I'm "freezing" the state of "id" 
when the future returns.


class ConfirmationCalc( dbClient:ActorRef ) extends Actor{

    def receive:Receive = {
        case CalculateFor( id ) =>
            val orig_sender = sender
            val f = ( dbClient ? ReadCommand( id ) )mapTo[Option[String]]
            f.onComplete{
                case Success( result ) => result match {
                    case Some( click ) =>
                         println( "Success: calculate using {}", click )
                         //orig_sender ! calculate( click )
                         orig_sender ! calculate( click, id )     //  <--- I am 
now using a previously received "id"
                    case None =>
                         println( "Got Empty" )
                case Failure( e ) =>
                    e.printStackTrace()
             }
         
        case _ =>
    }

    def calculate( click:String, id:String ):BigDecimal = {...}
}





On Wednesday, November 19, 2014 12:13:06 PM UTC-5, David wrote:
Hi,

I am coming from Java and am new to Scala and Akka and asynchronous programming 
in general.

I have a threadsafe, async db client like this:

class Client{
...
def get(key: K): Future[Option[V]] = ...
}


I would like embed this functionality in an Actor.


My initial thoughts are something like this:


class MyDBClient extends Actor{
    val client = Client( "102.98.2.1:3000" )
   
    def receive = {
        case ReadCommand( id ) =>
            val orig_sender = sender
            val f:Future[Option[String]] = client.get( id )
            f pipeTo orig_sender
        case _ =>
    }
}


And I would have a pool of these actors like this:


class DBManager extends Actor{

  
var router = {
  val routees = Vector.fill(5) {
val r = context.actorOf( Props[MyDBClient] )
context watch r
ActorRefRoutee(r)
  }
  Router( RoundRobinRoutingLogic(), routees )
}

def receive = {

  case DoSomething( id ) => {
router.route( ReadCommand( id ), sender() )
  }

  case _ =>
}


I have an actor which requires the database parameter to calculate a click 
value:


class ConfirmationCalc( dbClient:ActorRef ) extends Actor{

    def receive:Receive = {
        case CalculateFor( id ) =>
            val orig_sender = sender
            val f = ( dbClient ? ReadCommand( id ) )mapTo[Option[String]]
            f.onComplete{
                case Success( result ) => result match {
                    case Some( click ) =>
                         println( "Success: calculate using {}", click )
                         orig_sender ! calculate( click )
                    case None =>
                         println( "Got Empty" )
                case Failure( e ) =>
                    e.printStackTrace()
             }
         
        case _ =>
    }

    def calculate( click:String ):BigDecimal = {...}
}


My questions are:


1. Is this the "correct" pooling architecture - that is, having a central 
router that delegates to a number of dbactors which have a "connection" to the 
database?  Are there other architectures given that each DB Client class 
controls its own connections?


2. ConfirmationCalc actor will be furiously processing "CalculateFor" messages. 
 I understand that the future will eventually complete with either Success or 
Failure or timeout.  My newbie question is after I process my first message in 
ConfirmationCalc and send the async request to the dbclient, ConfirmationCalc 
may be processing its second message when the future completes.  In my newbie 
opinion, this code would have concurrenc

[akka-user] Re: Pooled Async Actor Architecture

[David]

Thanks very much for your reply, Konrad.

Could you tell me if the state of "id" is preserved when the future returns?

I would assume "No", since I don't see how I'm "freezing" the state of "id" 
when the future returns.

class ConfirmationCalc( dbClient:ActorRef ) extends Actor{

def receive:Receive = {
case CalculateFor( id ) =>
val orig_sender = sender
val f = ( dbClient ? ReadCommand( id ) )mapTo[Option[String]]
f.onComplete{
case Success( result ) => result match {
case Some( click ) =>
 println( "Success: calculate using {}", click )
 //orig_sender ! calculate( click )
 orig_sender ! calculate( click, id ) //  <--- I am 
now using a previously received "id"
case None =>
 println( "Got Empty" )
case Failure( e ) =>
e.printStackTrace()
 }
 
case _ =>
}

def calculate( click:String, id:String ):BigDecimal = {...}
}





On Wednesday, November 19, 2014 12:13:06 PM UTC-5, David wrote:
>
> Hi,
>
> I am coming from Java and am new to Scala and Akka and asynchronous 
> programming in general.
>
> I have a threadsafe, async db client like this:
>
> class Client{
>
> ...
>
> def get(key: K): Future[Option[V]] = ...
>
> }
>
>
> I would like embed this functionality in an Actor.
>
>
> My initial thoughts are something like this:
>
>
> class MyDBClient extends Actor{
> val client = Client( "102.98.2.1:3000" )
> 
> def receive = {
> case ReadCommand( id ) =>
> val orig_sender = sender
> val f:Future[Option[String]] = client.get( id )
> f pipeTo orig_sender
> case _ =>
> }
> }
>
>
> And I would have a pool of these actors like this:
>
>
> class DBManager extends Actor{
>
> var router = {
>   val routees = Vector.fill(5) {
> val r = context.actorOf( Props[MyDBClient] )
> context watch r
> ActorRefRoutee(r)
>   }
>   Router( RoundRobinRoutingLogic(), routees )
> }
>
> def receive = {
>
>   case DoSomething( id ) => {
> router.route( ReadCommand( id ), sender() )
>   }
>
>   case _ =>
> }
>
>
>
> I have an actor which requires the database parameter to calculate a click 
> value:
>
>
> class ConfirmationCalc( dbClient:ActorRef ) extends Actor{
>
> def receive:Receive = {
> case CalculateFor( id ) =>
> val orig_sender = sender
> val f = ( dbClient ? ReadCommand( id ) )mapTo[Option[String]]
> f.onComplete{
> case Success( result ) => result match {
> case Some( click ) =>
>  println( "Success: calculate using {}", click )
>  orig_sender ! calculate( click )
> case None =>
>  println( "Got Empty" )
> case Failure( e ) =>
> e.printStackTrace()
>  }
>  
> case _ =>
> }
>
> def calculate( click:String ):BigDecimal = {...}
> }
>
>
> My questions are:
>
>
> 1. Is this the "correct" pooling architecture - that is, having a central 
> router that delegates to a number of dbactors which have a "connection" to 
> the database?  Are there other architectures given that each DB Client class 
> controls its own connections?
>
>
> 2. ConfirmationCalc actor will be furiously processing "CalculateFor" 
> messages.  I understand that the future will eventually complete with either 
> Success or Failure or timeout.  My newbie question is after I process my 
> first message in ConfirmationCalc and send the async request to the dbclient, 
> ConfirmationCalc may be processing its second message when the future 
> completes.  In my newbie opinion, this code would have concurrency issues 
> since I would be getting the first message's db results when processing the 
> second message and send back the first results to the sender who is expecting 
> the second results.  I have read about "Cameo" patterns that encapsulate 
> state within actors but "ask" does not allow me to send the cameo in the ask. 
>  What code would address this issue ( if it is one at all ?)
>
>
> 3. This is related to my previous question.  In asynchronous systems, we 
> might have ActorA asking ActorB asking ActorC asking ActorD.  I find it a bit 
> mind bending how each actor in the chain is going to maintain state of 
> futures.  Future A may have onCompletions triggered thousands of times while 
> it is processing a message.  Is there example code somewhere that addresses 
> this?
>
>
> 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://grou

[akka-user] Re: Basic HTTP client with Akka HTTP

[Allan Brighton]

I'm also interested in this. Here is a modified example http client and 
server that work on 0.11 (based on Rüdiger's example):
   https://gist.github.com/abrighton/acd43a6cd9c0b997c456

Any suggestions are welcome. I also plan to add the capability to upload 
files using this (with POST), which should work in a similar way. 

--
Allan

On Thursday, November 20, 2014 8:16:26 PM UTC+1, Brian Topping wrote:
>
> Hi all,
>
> It looks like the syntax of handling client HTTP streams are under rapid 
> revision, but I wanted to build a client with 0.11 anyway. I've found some 
> examples, but none of them are quite up-to-date. 
>
> If anyone cares to contribute, a little discussion is going on at 
> https://gist.github.com/rklaehn/3f26c3f80e5870831f52 for 0.11. (A dead 
> link for future seekers means the examples are better documented 
> elsewhere!).
>
> Kind of wondering if a test client could be kept updated, maybe something 
> paired with 
> https://github.com/akka/akka/blob/release-2.3-dev/akka-http-tests/src/test/scala/akka/http/server/TestServer.scala.
>  
>  I think it would be completely reasonable to skip the HttpAuthentication 
> directive that Johannes added on 3-Nov to the server, just something that 
> can log in and dump the results of the "/ping" path would be awesome!
>
> Thoughts?
>
> Cheers, Brian
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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] Basic HTTP client with Akka HTTP

[Brian Topping]

Hi all,

It looks like the syntax of handling client HTTP streams are under rapid 
revision, but I wanted to build a client with 0.11 anyway. I've found some 
examples, but none of them are quite up-to-date. 

If anyone cares to contribute, a little discussion is going on 
at https://gist.github.com/rklaehn/3f26c3f80e5870831f52 for 0.11. (A dead 
link for future seekers means the examples are better documented 
elsewhere!).

Kind of wondering if a test client could be kept updated, maybe something 
paired 
with 
https://github.com/akka/akka/blob/release-2.3-dev/akka-http-tests/src/test/scala/akka/http/server/TestServer.scala.
 
 I think it would be completely reasonable to skip the HttpAuthentication 
directive that Johannes added on 3-Nov to the server, just something that 
can log in and dump the results of the "/ping" path would be awesome!

Thoughts?

Cheers, Brian

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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 KRYO causing cluster node unregister

[neeraj negi]

Hi,

I have two node system which was working fine till i have added the kryo.

Attached file is the application.conf that i am using.

KRYO causing the other node unregistered.

do i need to change something in the configuration


-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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 {
extensions = ["com.romix.akka.serialization.kryo.KryoSerializationExtension$"]
event-handlers = 
["akka.event.slf4j.Slf4jEventHandler","com.typesafe.atmos.trace.Slf4jTraceContextEventHandler"]
 
  loggers = ["akka.event.slf4j.Slf4jLogger"]
  loglevel = "ERROR"

  actor {
provider = "akka.cluster.ClusterActorRefProvider"
serializers {
# Define kryo serializer   
kryo = 
"com.romix.akka.serialization.kryo.KryoSerializer"
}

 serialization-bindings {
"java.util.List" = kryo
"java.io.Serializable" = kryo
"java.util.Map" = kryo
"akka.remote.message.Message" = kryo
} 

kryo  {  
# Possibles values for type are: graph or nograph  
# graph supports serialization of object graphs with shared nodes  
# and cyclic references, but this comes at the expense of a small overhead  
# nograph does not support object grpahs with shared nodes, but is usually 
faster   
type = "graph"  


# Possible values for idstrategy are:  
# default, explicit, incremental  
#  
# default - slowest and produces bigger serialized representation. Contains 
fully-  
# qualified class names (FQCNs) for each class. Note that selecting this 
strategy 
# does not work in version 0.3.2, but is available on master and from 0.3.3 
onward.
#  
# explicit - fast and produces compact serialized representation. Requires 
that all  
# classes that will be serialized are pre-registered using the "mappings" 
and "classes"
# sections. To guarantee that both sender and receiver use the same numeric 
ids for the same  
# classes it is advised to provide exactly the same entries in the 
"mappings" section   
#  
# incremental - fast and produces compact serialized representation. 
Support optional  
# pre-registering of classes using the "mappings" and "classes" sections. 
If class is  
# not pre-registered, it will be registered dynamically by picking a next 
available id  
# To guarantee that both sender and receiver use the same numeric ids for 
the same   
# classes it is advised to pre-register them using at least the "classes" 
section   

idstrategy = "incremental"  

# Define a default size for serializer pool
# Try to define the size to be at least as big as the max possible number
# of threads that may be used for serialization, i.e. max number
# of threads allowed for the scheduler
serializer-pool-size = 16

# Define a default size for byte buffers used during serialization   
buffer-size = 4096  

# The serialization byte buffers are doubled as needed until they exceed 
max-buffer-size and an exception is thrown. Can be -1 for no maximum.
max-buffer-size = -1

# If set, akka uses manifests to put a class name
# of the top-level object into each message
use-manifests = false

# Enable transparent compression of serialized messages
# accepted values are: off | lz4 | deflate
compression = off

# Log implicitly registered classes. Useful, if you want to know all classes
# which are serialized. You can then use this information in the mappings 
and/or 
# classes sections
implicit-registration-logging = false 

# If enabled, Kryo logs a lot of information about serialization process.
# Useful for debugging and lowl-level tweaking
kryo-trace = false 

# If proviced, Kryo uses the class specified by a fully qualified class name
# to perform a custom initialization of Kryo instances in addition to what
# is done automatically based on the config file.
#kryo-custom-serializer-init = "CustomKryoSerializerInitFQCN"

# Define mappings from a fully qualified class name to a numeric id.  
# Smaller ids lead to smaller sizes of serialized representations.  
#  
# This section is mandatory for idstartegy=explciit  
# This section is 

[akka-user] Use TypedActor or something else

[Владимир Морозов]

In one of threads 
(https://groups.google.com/forum/#!searchin/akka-user/Best$20way$20to$20integrate$20akka$20into$20a$20legacy$2Fexisting$20app/akka-user/SDHSJxjNYSY/cZgAdUklC28J)
 
user Akka team write 
"Typed actors are no longer recommended, we will eventually phase them out"
I already have application that use TypedActors inside, application grow 
up, but if Akka Team stop TypedActors improvement - my be I need to rewrite 
my application?
I choose TypedActors because return types of all calls check at compile 
time.

Any opinions or recommendation?

Best regards, Vladimir

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

Re: [akka-user] Using Akka Persistence with another KV store

[Konrad 'ktoso' Malawski]

Here’s all you need to know on how to implement your own journal plugin: 
http://doc.akka.io/docs/akka/snapshot/scala/persistence.html#journal-plugin-api
Here are the existing plugins: akka.io/community#plugins-to-akka-persistence

happy hakking
On 20 November 2014 at 16:41:07, Soumya Simanta (soumya.sima...@gmail.com) 
wrote:

My understanding is Akka Persistence uses LevelDB as the default journal. I 
want to evaluate another KV store that similar to LevelDB. How easy/hard is it 
to replace the LevelDB with the new KV store. The store is written in C. I'm 
assuming Akka persistence calls LevelDB API using a wrapper (JNI?) over the 
native LevelDB interface. Correct? 

Thanks
-Soumya



--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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.
-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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: Using Akka Persistence with another KV store

[Soumya Simanta]

Looks like Akka persistence uses a Java port of LevelDB
(https://github.com/dain/leveldb). 

So now my question what is the recommended way of using the new KV as the 
persistence journal? 

Thanks.


On Thursday, November 20, 2014 10:41:04 AM UTC-5, Soumya Simanta wrote:
>
> My understanding is Akka Persistence uses LevelDB as the default journal. 
> I want to evaluate another KV store that similar to LevelDB. How easy/hard 
> is it to replace the LevelDB with the new KV store. The store is written in 
> C. I'm assuming Akka persistence calls LevelDB API using a wrapper (JNI?) 
> over the native LevelDB interface. Correct? 
>
> Thanks
> -Soumya
>
>
>
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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] Using Akka Persistence with another KV store

[Soumya Simanta]

My understanding is Akka Persistence uses LevelDB as the default journal. I 
want to evaluate another KV store that similar to LevelDB. How easy/hard is 
it to replace the LevelDB with the new KV store. The store is written in C. 
I'm assuming Akka persistence calls LevelDB API using a wrapper (JNI?) over 
the native LevelDB interface. Correct? 

Thanks
-Soumya



-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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] Any update regarding Akka 3.0?

[Ryan Tanner]

> Please treat this as "random draft and ideas", it's not even an early 
preview *yet*.

Understood!

Thanks

On Thursday, November 20, 2014 3:24:58 AM UTC-7, Konrad Malawski wrote:
>
> Hi Ryan,
> while this is nothing official, here's one of the branches Roland is 
> experimenting on: 
> https://github.com/rkuhn/akka/tree/wip-g%C3%A5lbma-step1/akka-typed
> Not sure if that's the latest and greatest (branch), probably it is.
> Please treat this as "random draft and ideas", it's not even an early 
> preview *yet*.
>
> Interesting times ahead!
>
>
> On Thu, Nov 20, 2014 at 3:49 AM, Ryan Tanner  > wrote:
>
>> I saw on Twitter that Roland promised type safety in 3.0 during ReactConf 
>> today.  I recall a very preliminary preview from a few months ago but the 
>> link no longer works:
>>
>>
>> https://github.com/rkuhn/akka/blob/wip-g%C3%A5lbma-step1/akka-actor/src/main/scala/akka/typed/Sample.scala
>>
>> Is there anything more recent available to take a look at?
>>
>> -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to 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,
> Konrad 'ktoso' Malawski
> hAkker @ Typesafe
>  

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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 Persistence and Kryo serialization

[Richard Bowker]

I thought I'd experiment with using akka-kryo serializer to see what 
difference it made to performance of persisting an event (defined by a 
simple case class) compared to just allowing the default java serialization

after trying to follow the instructions in here 
https://github.com/romix/akka-kryo-serialization I am stuck.

it appears to serialize the class I wanted (as I can see it in the 
database), but on recovery of the actor I just get

"RecoveryFailure was caused by: com.esotericsoftware.kryo.KryoException: 
Encountered unregistered class ID: 1636190130 
(akka.actor.ActorKilledException)"

have I just got a setting wrong, or am I doing it all wrong! :)

thank you!

Rich


here are the relevant sections of the application.conf..


akka {
extensions = 
["com.romix.akka.serialization.kryo.KryoSerializationExtension$"]

actor {
serializers {  
kryo = "com.romix.akka.serialization.kryo.KryoSerializer"  
}   
 serialization-bindings {
"com.example.State$DomainEvent" = kryo
}
}
}

kryo  {  
# Possibles values for type are: graph or nograph  
# graph supports serialization of object graphs with shared nodes  
# and cyclic references, but this comes at the expense of a small 
overhead  
# nograph does not support object grpahs with shared nodes, but is 
usually faster   
type = "nograph"  


# Possible values for idstrategy are:  
# default, explicit, incremental  
#  
# default - slowest and produces bigger serialized representation. 
Contains fully-  
# qualified class names (FQCNs) for each class. Note that selecting 
this strategy 
# does not work in version 0.3.2, but is available on master and from 
0.3.3 onward.
#  
# explicit - fast and produces compact serialized representation. 
Requires that all  
# classes that will be serialized are pre-registered using the 
"mappings" and "classes"
# sections. To guarantee that both sender and receiver use the same 
numeric ids for the same  
# classes it is advised to provide exactly the same entries in the 
"mappings" section   
#  
# incremental - fast and produces compact serialized representation. 
Support optional  
# pre-registering of classes using the "mappings" and "classes" 
sections. If class is  
# not pre-registered, it will be registered dynamically by picking a 
next available id  
# To guarantee that both sender and receiver use the same numeric ids 
for the same   
# classes it is advised to pre-register them using at least the 
"classes" section   

idstrategy = "explicit"  

# Define a default size for serializer pool
# Try to define the size to be at least as big as the max possible 
number
# of threads that may be used for serialization, i.e. max number
# of threads allowed for the scheduler
serializer-pool-size = 16

# Define a default size for byte buffers used during serialization   
buffer-size = 4096  

# The serialization byte buffers are doubled as needed until they 
exceed max-buffer-size and an exception is thrown. Can be -1 for no maximum.
max-buffer-size = -1

# If set, akka uses manifests to put a class name
# of the top-level object into each message
use-manifests = false

# Enable transparent compression of serialized messages
# accepted values are: off | lz4 | deflate
compression = off

# Log implicitly registered classes. Useful, if you want to know all 
classes
# which are serialized. You can then use this information in the 
mappings and/or 
# classes sections
implicit-registration-logging = false 

# If enabled, Kryo logs a lot of information about serialization 
process.
# Useful for debugging and lowl-level tweaking
kryo-trace = true

# If proviced, Kryo uses the class specified by a fully qualified class 
name
# to perform a custom initialization of Kryo instances in addition to 
what
# is done automatically based on the config file.
#kryo-custom-serializer-init = "CustomKryoSerializerInitFQCN"

# Define mappings from a fully qualified class name to a numeric id.  
# Smaller ids lead to smaller sizes of serialized representations.  
#  
# This section is mandatory for idstartegy=explciit  
# This section is optional  for idstartegy=incremental  
# This section is ignored   for idstartegy=default  
#   
# The smallest possible id should start at 20 (or even higher), because
# ids below it are used by Kryo internally e.g. for built-in Java and 
# Scala types   
mappings {  
"com.example.State$DomainEvent" = 20
}  

# Define a set of fully qualified class names for   
# classes to be used for serialization.
# The ids for those classes will be assigned automatically,
# but respecting the order of declaration in this section  
#  
# This section is optional  for idstartegy=incremental  
# This section is ignored   for idstartegy=default  
# 

Re: [akka-user] akka-http (experimental) file server

[Rüdiger Klaehn]

On Thu, Nov 20, 2014 at 3:31 PM, Allan Brighton  wrote:
> Thanks for the http server example. It works fine.
> Do you also have a matching example for the client side?
> I found akka.http.TestClient, which is a start, but does not give any hints
> about reading the data from the server.
>
Sure. Based on the TestClient example, here is one that reads data
from the server and dumps it on the console.

https://gist.github.com/rklaehn/3f26c3f80e5870831f52#file-client-example

However, last time I tried this did not properly handle chunked
encoding. But that was 0.10-M1. I will have to try again.

Also, I hope there will be a less verbose way to do a simple GET request.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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] Pooled Async Actor Architecture

[Konrad Malawski]

Hi David and welcome to Scala/Akka!
Your design looks pretty OK :-)

I'll comment on a few things and you questions in-line, below:

class MyDBClient extends Actor{
> val client = Client( "102.98.2.1:3000" )
>
> def receive = {
> case ReadCommand( id ) =>
> val orig_sender = sender
> val f:Future[Option[String]] = client.get( id )
> f pipeTo orig_sender
> case _ =>
> }
> }
>
> No need to freeze the sender to orig_sender here, because you're not in a
future but using pipeTo instead - which is safe from the usual sender
problems (closing over it in a Future).
On the other hand, if you like this pattern for safety - harder to miss
freezing a value if you do it everywhere then cool, sounds like a plan as
well :-)

class DBManager extends Actor{
>
> [...] looks OK. You could put the router in a `val` instead.

class ConfirmationCalc( dbClient:ActorRef ) extends Actor{
>
> def receive:Receive = {
> case CalculateFor( id ) =>
> val orig_sender = sender
> val f = ( dbClient ? ReadCommand( id ) )mapTo[Option[String]]
> f.onComplete{
> case Success( result ) => result match {
> case Some( click ) =>
>  println( "Success: calculate using {}", click )
>  orig_sender ! calculate( click )
>
> // hint: good, here freezing the sender was needed.

> 1. Is this the "correct" pooling architecture - that is, having a central 
> router that delegates to a number of dbactors which have a "connection" to 
> the database?  Are there other architectures given that each DB Client class 
> controls its own connections?
>
> What you designed here is OK.
If this is a blocking database driver the bigger problem is blocking the
actor's threads when performing the query - you should then configure
dedicated dispatchers for the blocking code.
But since you said your db client returns a future and has some threadpools
of it's own I guess this shouldn't be a problem here (make sure it has a
dedicated thread pool, not the same one as the rest of the actor system).

> 2. ConfirmationCalc actor will be furiously processing "CalculateFor" 
> messages.  I understand that the future will eventually complete with either 
> Success or Failure or timeout.
>
> Correct, and timeout is a Failure, so you'd handle it in the onComplete.

> [...] I would be getting the *first message's db results* *when processing 
> the second message* and send back the *first results to the sender who is 
> expecting the second results*. [...]
>
>  It's true that this problem shows up when combining futures and
`sender()`. In your code however you have already guarded against that -
the way you "freeze" the sender value saves you
from the described concurrency problem. So while sender() may be "the
second guy" when the onComplete of "first" triggers, you're not using
sender() but orig_sender - which is a value frozen with the original sender
("first sender"). So all's good here.

3. This is related to my previous question.  In asynchronous systems,
we might have ActorA asking ActorB asking ActorC asking ActorD.  I
find it a bit mind bending how each actor in the chain is going to
maintain state of futures.  Future A may have onCompletions triggered
thousands of times while it is processing a message.  Is there example
code somewhere that addresses this?
>
> I'm not sure what exactly you're asking about here. Do you want to know
when futures trigger?
Maybe this may clarify – instead of thinking "the actor's oncomplete may
trigger", think "ok, so i have given this future a function that *IT* will
trigger when it gets completed",
it doesnt really have much to do with the actor other than that it may
share the same threadpool. So when you give stuff to a future to execute,
it becomes it's job to trigger these things (using whatever
execution context was used for the Future - in actors we often use import
context.dispatcher - so it's the same threadpool, not neccessarily not the
same thread).

Hope this helps!

-- 
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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-http (experimental) file server

[Allan Brighton]

Thanks for the http server example. It works fine.
Do you also have a matching example for the client side?
I found akka.http.TestClient, which is a start, but does not give any hints 
about reading the data from the server.


On Wednesday, November 19, 2014 9:35:18 PM UTC+1, rklaehn wrote:
>
> This should not be too hard. Regarding the filename: it depends on 
> what API you want. For the actual chunked sending, I would recommend 
> working with byte buffers if you want good performance. 
>
> This should get you going. But careful since it exposes your entire 
> machine via port 8080 
> https://gist.github.com/rklaehn/3f26c3f80e5870831f52 
>
> to test, use e.g. 
>
> curl http://localhost:8080/Users/rklaehn/tmp/test 
>
> Curl has some options to simulate low bandwidth connections which 
> allow you to experiment with the chunked encoding. 
>
> On Wed, Nov 19, 2014 at 6:49 PM, Allan Brighton  > wrote: 
> > Hi, 
> > 
> > I'd like to make an akka-http based file server that returns requested 
> large 
> > binary files 
> > (using chunking and ByteStrings), but haven't found any suitable 
> examples 
> > yet. 
> > So something like this: 
> > 
> > case class FileServer(interface: String, port: Int) { 
> >   implicit val system = ActorSystem() 
> >   import system.dispatcher 
> >   implicit val materializer = FlowMaterializer() 
> >   implicit val askTimeout: Timeout = 500.millis 
> > 
> >   IO(Http) ? Http.Bind(interface, port) foreach { 
> > case Http.ServerBinding(localAddress, connectionStream) ⇒ 
> >   Source(connectionStream).foreach({ 
> > case Http.IncomingConnection(remoteAddress, requestProducer, 
> > responseConsumer) ⇒ 
> > 
> > 
> Source(requestProducer).map(requestHandler).to(Sink(responseConsumer)).run() 
>
> >   }) 
> >   } 
> > 
> >   val requestHandler: HttpRequest ⇒ HttpResponse = { 
> > case HttpRequest(GET, _, _, _, _) ⇒ 
> >   val filename = ??? // how to get file name from URI path or use id 
> > attribute? 
> >   def output =  scala.io.Source.fromFile(filename) 
> > 
> >   HttpResponse( 
> > entity = 
> HttpEntity.Chunked(ContentTypes.`application/octet-stream`, 
> > Flow(???) // how to return the file contents in chunks of 
> > ByteStrings? 
> >   ) 
> > 
> > case _: HttpRequest ⇒ HttpResponse(404, entity = "Unknown 
> resource!") 
> >   } 
> > } 
> > 
> > Any suggestions on how to implement this? Any examples for the client 
> side? 
> > 
> > Thanks, 
> > Allan 
> > 
> > 
> > -- 
> >>> Read the docs: http://akka.io/docs/ 
> >>> Check the FAQ: 
> >>> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >>> Search the archives: https://groups.google.com/group/akka-user 
> > --- 
> > You received this message because you are subscribed to 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. 
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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] Reactive actor-actor communication

[Konrad 'ktoso' Malawski]

Yeah, was doing "the rounds” on creating tickets etc. Sorry I didn’t ping this 
thread! :-) 
I’ll get back to the other questions in this thread soon today, thanks for your 
patience!

— 
konrad


On 20 November 2014 at 13:51:17, Adam Warski (a...@warski.org) wrote:

I opened GH issues and I see Konrad beat me to it: 
https://github.com/akka/akka/issues/16348 :)

Adam

On Wednesday, November 19, 2014 8:36:41 AM UTC+2, rkuhn wrote:
Hi Adam,

your initial point of creating a growing (and maybe thundering) herd of retries 
is a good one and it would be better if we would limit the number of messages 
to be resent. Could you open a ticket for that?

Thanks,

Roland 

Sent from my iPhone

On Nov 18, 2014, at 04:08, Adam Warski  wrote:

Hey,

It would be more complicated to "replace" AtLeastOnceDelivery with your 
demand-driven proposal - the entire point of ALOD is that it fights back the 
fact that messages can get lost and nodes can go down.
Effectively what you're proposing is to switch from "re-sending until I get 
confirmations" (push) to "pulling all the time" (pull), the catch here is – 
"what if the demand messages get lost?", so you'd have to add re-delivery of 
the demand tokens themselves anyway.

True, the demand can get lost as well. Hmm... and that would be in fact a 
problem of any "reactive stream" between remote actors. This would make things 
more complex, but still doable, in a peer-to-peer setting at least (without 
routers). And would help with the potential flooding of the destination when it 
comes back after being absent for a longer time. But as I understand it's not 
complete non-sense ;) 

By the way - isn't dropping demand messages a problem also in the current 
remote-streams implementation?
 
Also imagine that you're trying to send M1 to A1, the A node goes down, it 
restarts. You could keep redelivering the M1 message, which would trigger the 
starting of the A1 actor (it could be persistent actor, in a shard, which 
starts when it gets a message),
then the push mode of ALOD will revive this A1 guy and deliver the M1 message. 
This would not work in a just pull based model - you'd have to revive everyone 
on A after a restart just in order to start asking around in the cluster if 
someone didn't have a message they wanted to send to these A# actor – where as 
with the "retry (push)" model, they are just started whenever there really is 
some message to be delivered to them, no need to start them and "ask around".

Sure, as we move away from peer-to-peer to more actors things do get more 
complex, but then, if you want to have back-pressure, you need some kind of 
feedback. I'd see it as a tradeoff - either lazily started actors, or 
backpressure.

If the sharded actors are aggregate roots, for example, then lazy loading makes 
perfect sense. But if these are workers, of which there are a couple per host, 
then this wouldn't be a problem. Just depends on the type of work they are 
supposed to do.
 
I'd also like to make sure what you mean by "reactive" when you use it in this 
proposal – I assume you mean the reactive-streams "reactive", as in "abides to 
the reactive streams protocol", and akka-streams of course drive those using 
messaging (in most cases).

Yes, reactive streams, mental shortcut :)
 
If so, then yes – we do plan to support reactive-streams over the network, in 
our case those will be actor's and messages of course, and yes, we'll need to 
implement a reliable redelivery transport for those messages.

Great to hear :)
 
We're not there yet, but we definitely will cross that bridge when we get there 
:-)

Let's move on to the Router example;
Well, this is pretty much what we deal with nowadays with elements like 
Broadcast / Balance and FlexiRoute.
Especially FlexiRoute should be of interest for you (in this example).

I'm wondering how many more functionalities are there in the code undiscovered 
;) But that will change when the docs are there I guess :)
 
As for the last proposal... I think it's either missing some details, or is 
wishful thinking.
How would you without a central entity be able to guarantee that you're 
properly balancing values among all the B side actors?
If you can just peer to peer between then you could simply just use 
point-to-point streams, and if that's not doable, there will be some form of 
router anyway doing the routing between A and B actors.

Right, well, originally I was wondering if Akka could replace Kafka+Zookeeper's 
message streams (which can be used to implement the scenario above: where 
there's a pool of producers, and a pool of consumers, all potentially on 
different hosts, and using Kafka they can stream messages reliably). With 
Kafka's delivery methods you bind each consumer to a number of partitions, so 
it would be as you describe, kind of point-to-point streams, which get 
re-balanced when a node goes down.

Going this route, there could be a cluster-singleton service which assigns 
B-actors to A-actors, and create

Re: [akka-user] Reactive actor-actor communication

[Adam Warski]

I opened GH issues and I see Konrad beat me to 
it: https://github.com/akka/akka/issues/16348 :)

Adam

On Wednesday, November 19, 2014 8:36:41 AM UTC+2, rkuhn wrote:
>
> Hi Adam,
>
> your initial point of creating a growing (and maybe thundering) herd of 
> retries is a good one and it would be better if we would limit the number 
> of messages to be resent. Could you open a ticket for that?
>
> Thanks,
>
> Roland 
>
> Sent from my iPhone
>
> On Nov 18, 2014, at 04:08, Adam Warski > 
> wrote:
>
> Hey,
>
> It would be more complicated to "replace" AtLeastOnceDelivery with your 
>> demand-driven proposal - the entire point of ALOD is that it fights back 
>> the fact that messages can get lost and nodes can go down.
>> Effectively what you're proposing is to switch from "re-sending until I 
>> get confirmations" (push) to "pulling all the time" (pull), the catch here 
>> is – "*what if the demand messages get lost?*", so you'd have to add 
>> re-delivery of the demand tokens themselves anyway.
>>
>
> True, the demand can get lost as well. Hmm... and that would be in fact a 
> problem of any "reactive stream" between remote actors. This would make 
> things more complex, but still doable, in a peer-to-peer setting at least 
> (without routers). And would help with the potential flooding of the 
> destination when it comes back after being absent for a longer time. But as 
> I understand it's not complete non-sense ;) 
>
> By the way - isn't dropping demand messages a problem also in the current 
> remote-streams implementation?
>  
>
>> Also imagine that you're trying to send M1 to A1, the A node goes down, 
>> it restarts. You could keep redelivering the M1 message, which would 
>> trigger the *starting* of the A1 actor (it could be persistent actor, in 
>> a shard, which starts when it gets a message),
>> then the push mode of ALOD will revive this A1 guy and deliver the M1 
>> message. This would not work in a just pull based model - you'd have to 
>> revive *everyone* on A after a restart just in order to start asking 
>> around in the cluster if someone didn't have a message they wanted to send 
>> to these A# actor – where as with the "retry (push)" model, they are just 
>> started whenever there really is some message to be delivered to them, no 
>> need to start them and "ask around".
>>
>
> Sure, as we move away from peer-to-peer to more actors things do get more 
> complex, but then, if you want to have back-pressure, you need some kind of 
> feedback. I'd see it as a tradeoff - either lazily started actors, or 
> backpressure.
>
> If the sharded actors are aggregate roots, for example, then lazy loading 
> makes perfect sense. But if these are workers, of which there are a couple 
> per host, then this wouldn't be a problem. Just depends on the type of work 
> they are supposed to do.
>  
>
>> I'd also like to make sure what you mean by "reactive" when you use it in 
>> this proposal – I assume you mean the *reactive*-streams "reactive", as 
>> in "abides to the reactive streams protocol", and akka-streams of course 
>> drive those using messaging (in most cases).
>>
>
> Yes, reactive streams, mental shortcut :)
>  
>
>> If so, then yes – we do plan to support reactive-streams over the 
>> network, in our case those will be actor's and messages of course, and yes, 
>> we'll need to implement a reliable redelivery transport for those messages.
>>
>
> Great to hear :)
>  
>
>> We're not there yet, but we definitely will cross that bridge when we get 
>> there :-)
>>
>> Let's move on to the Router example;
>> Well, this is pretty much what we deal with nowadays with elements like 
>> Broadcast 
>> 
>>  
>> / Balance 
>> 
>>  and *FlexiRoute* 
>> 
>> .
>> Especially FlexiRoute should be of interest for you (in this example).
>>
>
> I'm wondering how many more functionalities are there in the code 
> undiscovered ;) But that will change when the docs are there I guess :)
>  
>
>> As for the last proposal... I think it's either missing some details, or 
>> is wishful thinking.
>> How would you without a central entity be able to guarantee that you're 
>> properly balancing values among all the B side actors?
>> If you can just peer to peer between then you could simply just use 
>> point-to-point streams, and if that's not doable, there will be some form 
>> of router anyway doing the routing between A and B actors.
>>
>
> Right, well, orig

[akka-user] Re: Akka allocates new socket for each unsuccessful connection attempt to a quarantined system.

[Sergii Vozniuk]

Here 
https://github.com/svozniuk/akka-sockets-issue

Четвер, 20 листопада 2014 р. 13:04:52 UTC+1 користувач Sergii Vozniuk 
написав:
>
> Sorry I don't know why google thinks there is a virus, or why it didn't 
> allow the zip. 
> I'll try to share it in some other way.
>
> Четвер, 20 листопада 2014 р. 12:48:31 UTC+1 користувач Konrad Malawski 
> написав:
>>
>> I'm also unable to download the reproducer (415 error from google drive).
>> Would you be able to share it some other way (git repo?)
>>
>> --
>> Konrad
>>
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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: Akka allocates new socket for each unsuccessful connection attempt to a quarantined system.

[Sergii Vozniuk]

Sorry I don't know why google thinks there is a virus, or why it didn't 
allow the zip. 
I'll try to share it in some other way.

Четвер, 20 листопада 2014 р. 12:48:31 UTC+1 користувач Konrad Malawski 
написав:
>
> I'm also unable to download the reproducer (415 error from google drive).
> Would you be able to share it some other way (git repo?)
>
> --
> Konrad
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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: Akka allocates new socket for each unsuccessful connection attempt to a quarantined system.

[Konrad Malawski]

I'm also unable to download the reproducer (415 error from google drive).
Would you be able to share it some other way (git repo?)

--
Konrad

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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 allocates new socket for each unsuccessful connection attempt to a quarantined system.

[√iktor Ҡlang]

"*Anti-virus warning* - 1 attachment contains a virus or blocked file.
Downloading this attachment is disabled. Learn more
"

On Thu, Nov 20, 2014 at 12:32 PM, Sergii Vozniuk  wrote:

> Hi Konrad,
>
> Probably I didn't provide some important information:
>
> 1. In current implementation we don't stop and restart (or create new)
> actor systems after failures. Their number is unchanged from the start of
> the application. So I have no explanation why new sockets are allocated.
> 2. I have read every post on the forum about quarantines and posts related
> to "too many open file problem" and I'm sure our system doesn't fall into
> one of scenarios that have been discussed here or on stackoverflow.
>
> You can find attached a minimal example project where I can reproduce the
> problem every time (10 times out of 10)
>
> The application has
>
>- a client that connects to a server and tries to reconnect to it
>whenever the connection is lost
>- a server that does nothing except accepting client connections
>- a starter class that starts up client and server actor systems
>
> To reproduce the problem
>
>1. Execute from project directory ./gradlew run
>2. Wait until client is connected
>3. Execute sudo iptables -A INPUT -p tcp --destination-port 2552 -j
>DROP to drop all server connections
>4. Wait until the client detects problems and tries reconnecting
>5. Let it run for a minute
>6. Execute sudo iptables -D INPUT -p tcp --destination-port 2552 -j
>DROP to enable server connections
>7. Notice quarantined state being logged
>8. Run peridically sudo netstat -tulpna | grep 2552 and observe that
>the number of opened sockets grows
>9. After some time has passed (12 hours in my case) the JVM crashes
>due to Too many open files.
>
> Tell me if you need any additional info.
>
> Regards,
> Sergii
>
>
> Четвер, 20 листопада 2014 р. 11:19:58 UTC+1 користувач Akka Team написав:
>
>> Hi Sergii,
>> This sounds like a potential bug.
>> I tried to trace this back to something obvious in the code but didn't
>> find anything yet.
>>
>> Would you mind creating an issue 
>> for this and we'll have a deeper look into this then?
>>
>> --
>> Konrad,
>> Akka Team
>> Typesafe - The software stack for applications that scale
>> Blog: letitcrash.com
>> Twitter: @akkateam
>>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at 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] Simple Akka + TCP example?

[Konrad Malawski]

Hi Luc,
Have you looked at the examples in the akka-io-tcp section of the docs?
Writing to a connection

is
as simple as opening the connection and then sending Write messages to the
connection actor you'll get back from IO.

The simlpest example that covers your case is listed under the Connecting
section of the docs
. You send
a Connect, then Register, and then ou're ready to star writing data to the
socket.

Hope this helps!

On Wed, Nov 19, 2014 at 7:56 AM, Luc Perkins  wrote:

> Sorry in advance for the noob question, but I'm trying to build a database
> client on top of Akka IO (or Akka Streams, if applicable), and I'm having a
> big of trouble learning the ropes because most of the example code that
> I've seen is geared toward building both client and server, whereas I'm
> only interested in the client side.
>
> Could somebody point me to an example of a minimum viable implementation?
> To get off to a good start, I really just need to open up a TCP connection
> to the DB (Riak in this case), send Protocol Buffers messages (the message
> generation part is easy), and then handle the DB's response (the handling
> could just be *println* or something basic for now). Once I get the
> transport layer up and going, the other parts of building the client should
> be fairly simple.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send 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,
Konrad 'ktoso' Malawski
hAkker @ Typesafe

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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] routing and load balancing with AKKA instead of regular NLB

[Konrad Malawski]

>
> On top of that - of course we will continue to POC.
> As I mentioned we are confident with Akka and using it's advantages BUT
> since we are new to Akka, we had some debate and one argument was "let NLB
> do what it knows and let the application do it's part".
> Because that we understand (think :)) that Akka should be capable on
> delivering the inter load balancing - we just wanted to get
> some strengthening from the Experts and Experienced before/while continuing
> to the POC.
>
In general - yes, Akka is able to balance load in a cluster by utilising
it's own routers.
Like I mentioned before, if you need in depth consulting, we can do that as
part of a commercial offering - http://typesafe.com/how/subscription


So if I may, let me be clearer - let say my "instance" consisted of: 4
> physical servers (each with 12 cores & 128 GB memory), total 14 VM
> machines.
> [...]
> Do you know of any successive implementation of Akka's routing & load
> balancing with numbers close to my above requirements?
>
We've seen deployments on hundreds of servers in the field and Akka was
able to run just fine in there, so I wouldn't be worried about 14 machines
:-)


Happy hakking!

-- 
Cheers,
Konrad 'ktoso' Malawski
hAkker @ Typesafe

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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] Any update regarding Akka 3.0?

[Konrad Malawski]

Hi Ryan,
while this is nothing official, here's one of the branches Roland is
experimenting on:
https://github.com/rkuhn/akka/tree/wip-g%C3%A5lbma-step1/akka-typed
Not sure if that's the latest and greatest (branch), probably it is.
Please treat this as "random draft and ideas", it's not even an early
preview *yet*.

Interesting times ahead!


On Thu, Nov 20, 2014 at 3:49 AM, Ryan Tanner  wrote:

> I saw on Twitter that Roland promised type safety in 3.0 during ReactConf
> today.  I recall a very preliminary preview from a few months ago but the
> link no longer works:
>
>
> https://github.com/rkuhn/akka/blob/wip-g%C3%A5lbma-step1/akka-actor/src/main/scala/akka/typed/Sample.scala
>
> Is there anything more recent available to take a look at?
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send 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,
Konrad 'ktoso' Malawski
hAkker @ Typesafe

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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 allocates new socket for each unsuccessful connection attempt to a quarantined system.

[Akka Team]

Hi Sergii,
This sounds like a potential bug.
I tried to trace this back to something obvious in the code but didn't find
anything yet.

Would you mind creating an issue  for
this and we'll have a deeper look into this then?

-- 
Konrad,
Akka Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
Twitter: @akkateam

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

Re: [akka-user] Akka stream question

[√iktor Ҡlang]

We've focused on getting the representation, materialization and execution
-correctness- in place before we start optimizing. Stay tuned.

On Thu, Nov 20, 2014 at 3:54 AM, mqshen  wrote:

> Hi,
>
> I'm use akka stream 0.10 for StreamTcp data read and decode.
>
> Source(connection.inputStream)
>   .mapConcat(delimiterFraming.apply)
>   .map(_.utf8String)
>   .map(MessageParser.parse)
>   .filter(_.isSuccess)
>   .map(_.get)
>   .foreach(connectionActor ! _)
>
>
> When I do a performance test.  the inputStream data is very slow to pass
> to delimiterFraming.apply method.
>
> The delimiterFraming.apply method call interval more than 10ms,the max
> will be 3s.
>
> There is only one Connect. 100messages/s test message is about 40 bytes
> length.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send 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.

[akka-user] Akka stream question

[mqshen]

Hi,

I'm use akka stream 0.10 for StreamTcp data read and decode.

Source(connection.inputStream)
  .mapConcat(delimiterFraming.apply)
  .map(_.utf8String)
  .map(MessageParser.parse)
  .filter(_.isSuccess)
  .map(_.get)
  .foreach(connectionActor ! _)


When I do a performance test.  the inputStream data is very slow to pass to 
delimiterFraming.apply method.

The delimiterFraming.apply method call interval more than 10ms,the max will 
be 3s. 

There is only one Connect. 100messages/s test message is about 40 bytes 
length.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>  Search the archives: https://groups.google.com/group/akka-user
--- 
You received this message because you are subscribed to the Google Groups "Akka 
User List" group.
To unsubscribe from this group and stop receiving emails from it, send 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 remoting taking time

[neeraj negi]

Hi,

I have two node system one running on 2551 port and other running on 2552 
port on single machine right now.

I am sending object containing 1 records from 2551 to 2552 and the 
payload size is less then 1 Mb and it's taking around 60 to 70 millisecond 
for transfer from one node to another

and if I increase the records i.e. 7 and payload becomes around 6 Mb 
then it start taking 300 to 400 ms for transfer from one node to another


my application conf is:-

akka {

event-handlers = ["akka.event.slf4j.Slf4jEventHandler"] 
  loggers = ["akka.event.slf4j.Slf4jLogger"]
  loglevel = "debug"

  actor {
provider = "akka.cluster.ClusterActorRefProvider"
  }
  remote {
log-remote-lifecycle-events = off
netty.tcp {
  hostname = "127.0.0.1"
  port = 0
  maximum-frame-size = 52428800
   send-buffer-size = 52428800
  receive-buffer-size = 52428800 
}
  }

cluster {
seed-nodes = [
  "akka.tcp://ClusterSystem@127.0.0.1:2551",
  "akka.tcp://ClusterSystem@127.0.0.1:2552"]

auto-down-unreachable-after = 300s
  }
  
}

How can i increase my transfer speed? 
am i missing something in Application.conf?




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