[akka-user] Re: Distributed cache with Akka

[Ngoc Dao]

Not related to Akka, but you should try Hazelcast:
http://hazelcast.org/

Hazelcast is designed for this problem.

There's code and data in your program.
If you want to distribute code => use Akka,
if you want to distribute data => use Hazelcast.


On Tuesday, January 20, 2015 at 10:42:09 AM UTC+9, as...@indexia.co wrote:
>
> Hey,
>
> I'm trying to build a small akka app that supports authentication via 
> tokens,
>
> What would be the simplest approach to store user tokens in a distributed 
> map cache for all akka nodes 
> as I can't guarantee that users will be served by the same akka node,
>
>
> 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] ClusterSingleton, multiple proxies?

[Patrik Nordwall]

> 20 jan 2015 kl. 11:45 skrev Roland Kuhn :
> 
> Hi Brice,
> 
>> 15 jan 2015 kl. 17:15 skrev Brice Figureau :
>> 
>> Hi,
>> 
>> I have several utility ClusterSingleton actors in my cluster that are
>> used by several client actors (some of them are also singleton or
>> ClusterSharding entries).
>> 
>> Those client actors are currently created by passing the ActoRef of said
>> utility singletons proxies as Props arguments. This can't work when
>> those actors are themselves singletons or sharded entries, because they
>> might run on a different node than the passed-in proxies (and props
>> might not even be serialized?).
>> 
>> So I need to refactor all this to not pass any ActorRef. 
>> 
>> My question finally is what would be the best way to achieve that:
>> * have client actors create their own proxy (or ClusterShard region).
>> This doesn't seem the good solution :(

For sharded actors this a good solution, because the shard region is accessed 
via the local extension anyway.

For singleton proxies you can create you own extension that holds all your 
singleton proxy instances. You probably don't have a lot of singletons anyway.

If you don't have many (>20) client actors you don't need the extension for the 
singleton proxies. Then each client can create its own.

/Patrik
>> 
>> or
>> * have a well known per-node registry actor that creates the needed
>> proxies (and region) at start and can send those ActorRef to client
>> actors.
>> 
>> I'm much more inclined toward the second solution, but unfortunately it
>> makes the various tests a bit more complex (setup a registry instead of
>> injecting TestProbe).
> 
> You would still inject a TestProbe by injecting a mock registry (can be the 
> same as the production code but filled with TestProbes). Otherwise I don’t 
> see anything wrong with this proposal.
> 
> Regards,
> 
> Roland
> 
>> 
>> What do you think?
>> Is there a better solution I didn't think about?
>> -- 
>> Brice Figureau
>> My Blog: http://www.masterzen.fr/
>> 
>> -- 
Read the docs: http://akka.io/docs/
Check the FAQ: 
 http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send 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.
> 
> 
> 
> Dr. Roland Kuhn
> Akka Tech Lead
> Typesafe – Reactive apps on the JVM.
> 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.

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

[Rajesh Shetty]

What is the best way to start Akka cluster nodes?.
as a 
> microkernel (bootable )
> using java -jar 
> anything else ?

in either case what should be the code structure

*Microkernel*

> Actors
> bootable extension (for microkernel) -> that creates ActorSystem 
> What else?

*> using java -jar *
> Actors
> ?


Any examples of these techniques we have , that I can refer ?


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

[Rajesh Shetty]

Here is the layman understanding

Cluster -> network of nodes 
nodes -> Physical or virtual instances on a single hardware boxes. 
Essentially which means you can have more than 1 node on a same physical 
box . which means more than one node can have same IP address but MUST have 
different port.

Now this solves the general understanding of cluster/nodes in a typical web 
app scale.

Does akka follow same convention ?.  Question is when you specify following 
application.conf for seed nodes

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

which means it starts 2 nodes , adds it to the cluster. Now the question is 
if have bunch of actors, do they get created for each of the nodes? e.g if 
have created 4 actors as a part of the process, will I have 8 actors of 
type 4 in each nodes ?. is that a right assumption ?

Next question is routers and routees

As I understand each of these actors can be a router . ACTOR > Router and 
router can create child actors a.k.a routees.  So lets say if I use above 
example out of 4 , I make 2 actors as routers (not sure how to make them 
router) and each router creates 4 more child actors (routees) . Which means 
in my cluster I will have 

Node1 - 4 actors ; 2 routers , 2 regular actors 
 > 2 router creates > 4 child actors (routees ) each. ->  Node1 
total actors : 8 
Node2- 4 actors ; 2 routers , 2 regular actors 
 > 2 router creates > 4 child actors (routees ) each. ->  Node1 
total actors : 8

So total actors in a given cluster 16 . is that a right assumption or 
calculation.?

In short Cluster -> (1-n) Nodes  (physical or virtual ) -> (1-1) Routers -> 
(1-n) Routees





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

[Alexey Romanchuk]

Hi again, hakkers!

I can not find any documentation about conditions when juntions becomes
completed and how junctions propagate errors. Something like "Merge
completes when all of his input completes". Also there is no such cases in
unit tests.

Am I miss something? Sure this information can be found in sources, but I
think it should be documentation.

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

[Alexey Romanchuk]

Hi,

looks very interesting and very useful especially for stages testing.

Thanks!

On Tue, Jan 20, 2015 at 5:26 PM, Endre Varga 
wrote:

> Hi,
>
>
> On Mon, Jan 19, 2015 at 5:54 PM, Alexey Romanchuk <
> alexey.romanc...@gmail.com> wrote:
>
>> Hey hakkers!
>>
>> I am currently updating old application built on akka-streams 0.4 to
>> 1.0-MX API. I used Transformers and now migrate it to PullPushStages. In
>> general migration is pretty easy, but I can not figure out how should I
>> rewrite unit test for custom stages?
>>
>> In 0.4 transformers had simple external API and I use unit test to test
>> them. There is context in 1.0 stages API and unit testing is not so
>> straightforward. I found that most of prebuild stages test by building
>> simple streams, but looks like it is too much testing environment for stage
>> testing.
>>
>
> I think simple streams are usually all you need for testing PushPullStages
> (but not enough for DetachedStages, we need better testing support for them
> than the very low level testing stuff we have now). Now there is a hidden
> class, that is INTERNAL API for now, but we might open it up. It is called
> IteratorInterpreter, and it allows to execute a series of PushPullStages on
> top of an Iterator, providing a new Iterator in turn, which basically
> drives the Stages. No materialization, no actors, no threads, no
> actorsystem, just a plain iterator. I guess it is useful for lot of testing
> tasks. Btw, all of the interpreters are very lightweight, they are
> basically allocation free even for the hot path, only completion and error
> handling uses some allocations.
>
> -Endre
>
>
>> Could you advise right approach to test streams and custom stages
>> especially?
>>
>> 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.
>>
>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/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/lopuSiMfXMw/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.
>

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

[Yogesh Pandit]

​
Hello,

I am using spray-can 1.2.1 and have a service to upload data in chunks.

It seems to be working fine but for the following boundary data being 
written to the uploaded file. How can I not write this into the file. 
Reading the whole file is not an option due to large size.
I have used the following example - 
https://github.com/spray/spray/tree/master/examples/spray-can/simple-http-server/src/main/scala/spray/examples


--WebKitFormBoundary5mkhOpb3GjmIWL7a
Content-Disposition: form-data; name="datafile"; filename="file.csv"
Content-Type: text/csv



--WebKitFormBoundary5mkhOpb3GjmIWL7a--

Thanks you,
-Yogesh

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

[Viktor Klang]

Could you put together a minimized reproducer?

On Tue, Jan 20, 2015 at 5:21 PM, Randy Fox  wrote:

> Nope.  Did I find a bug or am i doing something wrong?
>
> On Saturday, January 17, 2015 at 1:21:12 PM UTC-8, √ wrote:
>>
>> Alright. Did you manage to sort it out?
>>
>> --
>> Cheers,
>> √
>> On 16 Jan 2015 16:56, "Randy Fox"  wrote:
>>
>>> I expected the thread pool to be pegged at 100 threads, but watching in
>>> visual vm showed 24 threads (default).  Poking around the object structure
>>> in the debugger, I found nested deep under the flowmaterializer was a
>>> maxsize of 64 (also default).
>>>
>>> -r
>>>
>>> On Thursday, January 15, 2015 at 5:34:05 PM UTC-8, Randy Fox wrote:

 I am trying to assign a dispatcher to be used for my http server (using
 the new Akka HTTP Server) and can’t get it to honor my pool size settings.
 Logs show it is using the dispatcher, but visualvm shows it is not using
 the core pool size settings.   Loos like it might be using the defaults for
 a thread-pool-executor.


 All I did was modify the example:

1. import akka.http.Http
2. import akka.stream.FlowMaterializer
3.
4. implicit val system = ActorSystem()
5. implicit val materializer = FlowMaterializer(
*MaterializerSettings*(*system*).withDispatcher(
*“myhttpRequestHandler.dispatcher"*))
6.
7. val serverBinding = Http(system).bind(interface = "localhost",
port = 8080)
8. serverBinding.connections.foreach { connection => // foreach
materializes the source
9.   println("Accepted new connection from " +
connection.remoteAddress)
10. }
11. …

 myhttpRequestHandler {

   dispatcher {

 type = Dispatcher

 executor = *"thread-pool-executor"*

 name = httprequesthandler-dispatcher

 thread-pool-executor {

   core-pool-size-min = 100

   core-pool-size-factor = 2.0

   core-pool-size-max = 100

 }

 throughput = 5

   }

 }

 [INFO] [2015-01-15 17:24:27,516] [DUDE-myhttpRequestHandler.dispatcher-79]
 HttpRequestHandler(akka://DUDE): Accepted new connection from /
 127.0.0.1:54046

 What am I missing?

 Thanks,

 Randy Fox

>>>  --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: http://doc.akka.io/docs/akka/
>>> current/additional/faq.html
>>> >> Search the archives: https://groups.google.com/
>>> group/akka-user
>>> ---
>>> You received this message because you are subscribed to 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.
>



-- 
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] Re: Feedback on Akka Streams 1.0-M2 Documentation

[Sam Halliday]

One more comment on the streams API. It is really cool that you've thought 
about using mapConcat instead of flatMap to enable optimised merge 
operations. I just wanted to draw your attention to a clojure project that 
does super-fast merging of immutable Tree/Trie structures:
 https://github.com/JulesGosnell/seqspert

The work is definitely portable to the Scala collection types, as they are 
based on the Clojure implementations.


On Tuesday, 20 January 2015 19:04:45 UTC, Sam Halliday wrote:
>
> Dear Akka Team,
>
> In response to Bjorn's prompting[1], I have read all the Akka
> Streams 1.0-M2 documentation[2].
>
> I am very impressed, and excited! There has clearly been a lot of
> thought put into this framework and I am looking forward to using
> it in anger over the coming years.
>
> Bjorn asked if I felt any examples were missing, and sadly my
> original request (that I've been going on about for years,
> sorry!) is indeed missing. It is the case of a fast producer and
> a slow consumer that is ideal for parallelisation.
>
> I believe it may be possible to use the current 1.0-M2 to address
> my bugbear by using the Actor integration to write an actor that
> has N instances behind a router, but it feels hacky to have to
> use an Actor at all. What is really missing is a Junction that
> multiplies the next Flow into N parallel parts that run on
> separate threads.
>
>
> In general, I felt that the documentation was missing any
> commentary on concurrency and parallelisation. I was left
> wondering what thread everything was happening on. Some initial
> questions I have in this area:
>
> 1. Is everything actually executed in the same thread? What about
>when you have a Junction?
>
> 2. Is it possible to be doing work to populate the Source's cache
>while work is being executed in a Flow or Sink?
>
> It would be good to have a section in the documentation that
> discusses this in more detail.
>
>
> And, very importantly, it would be good to have the feature of
> being able to split a Flow into N parallel parts! I recently
> learnt how to do this in ScalazStreams but I'm much rather be
> able to do it in Akka Streams as I find everything else about the
> architecture to be so much easier to understand (plus integration
> with Akka Actors is just tremendous).
>
> PS: I'm also very excited by Slick 3.0 which appears to be aiming toward 
> Reactive Streams and, I assume, integration with Akka Streams. e.g. produce 
> a Source[Entity] from a SELECT with pushback on extremely large result sets.
>
>
> [1] https://groups.google.com/d/msg/akka-user/1TlAy-oqOk8/xvJpyVMWytsJ
> [2] 
> http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M2/scala.html
> [3] 
> https://github.com/fommil/rx-playground/blob/master/src/main/scala/com/github/fommil/rx/scratch.scala#L204
>
> Best regards,
> Sam (fommil)
>
>

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

[Sam Halliday]

Dear Akka Team,

In response to Bjorn's prompting[1], I have read all the Akka
Streams 1.0-M2 documentation[2].

I am very impressed, and excited! There has clearly been a lot of
thought put into this framework and I am looking forward to using
it in anger over the coming years.

Bjorn asked if I felt any examples were missing, and sadly my
original request (that I've been going on about for years,
sorry!) is indeed missing. It is the case of a fast producer and
a slow consumer that is ideal for parallelisation.

I believe it may be possible to use the current 1.0-M2 to address
my bugbear by using the Actor integration to write an actor that
has N instances behind a router, but it feels hacky to have to
use an Actor at all. What is really missing is a Junction that
multiplies the next Flow into N parallel parts that run on
separate threads.


In general, I felt that the documentation was missing any
commentary on concurrency and parallelisation. I was left
wondering what thread everything was happening on. Some initial
questions I have in this area:

1. Is everything actually executed in the same thread? What about
   when you have a Junction?

2. Is it possible to be doing work to populate the Source's cache
   while work is being executed in a Flow or Sink?

It would be good to have a section in the documentation that
discusses this in more detail.


And, very importantly, it would be good to have the feature of
being able to split a Flow into N parallel parts! I recently
learnt how to do this in ScalazStreams but I'm much rather be
able to do it in Akka Streams as I find everything else about the
architecture to be so much easier to understand (plus integration
with Akka Actors is just tremendous).

PS: I'm also very excited by Slick 3.0 which appears to be aiming toward 
Reactive Streams and, I assume, integration with Akka Streams. e.g. produce 
a Source[Entity] from a SELECT with pushback on extremely large result sets.


[1] https://groups.google.com/d/msg/akka-user/1TlAy-oqOk8/xvJpyVMWytsJ
[2] 
http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M2/scala.html
[3] 
https://github.com/fommil/rx-playground/blob/master/src/main/scala/com/github/fommil/rx/scratch.scala#L204

Best regards,
Sam (fommil)

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

[Martynas Mickevičius]

That is the correct behavior. When the actor is restarted by the supervisor
the Terminated message is not sent. Even the UUID of the actor instance
does not change.

You could send a message to the interested parties from the actor's that is
being restarted one of the life-cycle hooks. You can read more what
life-cycle hooks are being called on actor restart in the documentation

.

On Mon, Jan 19, 2015 at 3:45 AM, Dmitry Semenov 
wrote:

> Hello colleagues.
>
> I observe some behavior which seems odd for me. When i create an actor and
> it's child and start death watching on parent actor, i may or i may not
> receive Terminated message in death watcher depending of what supervisor
> strategy has been chosen.
>
> If Stop selected death watcher receive Terminated as expected, when
> Restart - it doesn't.
>
> I've written a small test case o reproduce this issue, you can follow the
> link bellow
>
> Test case 
>
> I wonder if it desired behavior or not? If it desired, then how can i
> handle actor termination in case Restart strategy chosen? In my actor
> system i need to register any actor failure regardless of what supervisor
> strategy has been selected, i need the fact of termination and actor
> reference (path)
> 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.
>



-- 
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] received Supervise from unregistered child ... this will not end well

[Viktor Klang]

Have you closed over "context.actorOf" and execute it within a Future or
similar?

On Tue, Jan 20, 2015 at 6:47 PM, Marco Luca Sbodio 
wrote:

> Hello everyone,
>
> while testing my system I'm randomly getting error messages similar to the
> one in the subject of this topic. Here's an example:
>
> 17:27:59.265UTC ERROR
> [MySystemMultiNodeTest-akka.actor.default-dispatcher-16]
> [org.mysystem.actor.Worker]
> [akka://MySystemMultiNodeTest/user/the-engine/executor-7b7690ee-f31d-45f1-93ef-79cba01fe604/planner/sub-planner-951/worker0]
> - received Supervise from unregistered child Actor[akka.tcp://
> mysystemmultinodet...@nd06.domain.com:3002/remote/akka.tcp/mysystemmultinodet...@nd03.domain.com:3001/user/the-engine/executor-7b7690ee-f31d-45f1-93ef-79cba01fe604/planner/sub-planner-951/worker0/worker1.4#-430862452],
> this will not end well
>
> I really have no clue what might cause these errors, and what the
> consequences are ("this will not end well"). I've tried searching on the
> Web, but didn't find anything that helped me.
>
> I'm using akka 2.2.3
>
> Any help is highly appreciated!
>
> Thanks,
> Marco
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send 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] received Supervise from unregistered child ... this will not end well

[Marco Luca Sbodio]

Hello everyone,

while testing my system I'm randomly getting error messages similar to the 
one in the subject of this topic. Here's an example:

17:27:59.265UTC ERROR 
[MySystemMultiNodeTest-akka.actor.default-dispatcher-16] 
[org.mysystem.actor.Worker] 
[akka://MySystemMultiNodeTest/user/the-engine/executor-7b7690ee-f31d-45f1-93ef-79cba01fe604/planner/sub-planner-951/worker0]
 
- received Supervise from unregistered child 
Actor[akka.tcp://mysystemmultinodet...@nd06.domain.com:3002/remote/akka.tcp/mysystemmultinodet...@nd03.domain.com:3001/user/the-engine/executor-7b7690ee-f31d-45f1-93ef-79cba01fe604/planner/sub-planner-951/worker0/worker1.4#-430862452],
 
this will not end well

I really have no clue what might cause these errors, and what the 
consequences are ("this will not end well"). I've tried searching on the 
Web, but didn't find anything that helped me.

I'm using akka 2.2.3

Any help is highly appreciated!

Thanks,
Marco

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

[Greg Young]

Weak/hybrid serialization ...

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

[Randy Fox]

Nope.  Did I find a bug or am i doing something wrong?

On Saturday, January 17, 2015 at 1:21:12 PM UTC-8, √ wrote:
>
> Alright. Did you manage to sort it out?
>
> -- 
> Cheers,
> √
> On 16 Jan 2015 16:56, "Randy Fox" > 
> wrote:
>
>> I expected the thread pool to be pegged at 100 threads, but watching in 
>> visual vm showed 24 threads (default).  Poking around the object structure 
>> in the debugger, I found nested deep under the flowmaterializer was a 
>> maxsize of 64 (also default).
>>
>> -r
>>
>> On Thursday, January 15, 2015 at 5:34:05 PM UTC-8, Randy Fox wrote:
>>>
>>> I am trying to assign a dispatcher to be used for my http server (using 
>>> the new Akka HTTP Server) and can’t get it to honor my pool size settings.  
>>> Logs show it is using the dispatcher, but visualvm shows it is not using 
>>> the core pool size settings.   Loos like it might be using the defaults for 
>>> a thread-pool-executor.
>>>
>>>
>>> All I did was modify the example:
>>>
>>>1. import akka.http.Http 
>>>2. import akka.stream.FlowMaterializer 
>>>3.   
>>>4. implicit val system = ActorSystem() 
>>>5. implicit val materializer = FlowMaterializer(
>>>*MaterializerSettings*(*system*).withDispatcher(
>>>*“myhttpRequestHandler.dispatcher"*)) 
>>>6.   
>>>7. val serverBinding = Http(system).bind(interface = "localhost", 
>>>port = 8080) 
>>>8. serverBinding.connections.foreach { connection => // foreach 
>>>materializes the source 
>>>9.   println("Accepted new connection from " + 
>>>connection.remoteAddress) 
>>>10. } 
>>>11. … 
>>>
>>> myhttpRequestHandler {
>>>
>>>   dispatcher {
>>>
>>> type = Dispatcher
>>>
>>> executor = *"thread-pool-executor"*
>>>
>>> name = httprequesthandler-dispatcher
>>>
>>> thread-pool-executor {
>>>
>>>   core-pool-size-min = 100
>>>
>>>   core-pool-size-factor = 2.0
>>>
>>>   core-pool-size-max = 100
>>>
>>> }
>>>
>>> throughput = 5
>>>
>>>   }
>>>
>>> }
>>>
>>> [INFO] [2015-01-15 17:24:27,516] [DUDE-myhttpRequestHandler.dispatcher-79] 
>>> HttpRequestHandler(akka://DUDE): Accepted new connection from /
>>> 127.0.0.1:54046
>>>
>>> What am I missing?
>>>
>>> Thanks,
>>>
>>> Randy Fox
>>>
>>  -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to 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] Re: akka-http respond with result of an actor call (java-api)

[Martynas Mickevičius]

Hi,

did you try onComplete or onSuccess directives?

https://github.com/akka/akka/blob/4b603ad018b1b909bb331b26ab7ec5464d86cd50/akka-http-tests/src/test/scala/akka/http/server/directives/FutureDirectivesSpec.scala

On Mon, Jan 12, 2015 at 7:40 PM, Asaf Shakarzy  wrote:

> +1! ping? anyone?
>
>
> On Thursday, January 8, 2015 at 1:07:58 PM UTC+2, Peter wrote:
>>
>> Hello,
>> I'm playing arround with the Java-API of the new akka-http server and I
>> would like to reply to a request with the result of an asynchronous actor
>> (i.e. some kind of DB-query).
>>
>> I would have expected that I somehow can pass a Future to the
>> context.complete or a "Future" entity. But this seams not be possible.
>>
>> One  solution seams to be to generate a streaming entity and stream the
>> result back. But how do I do it if I just want to have a "traditional" http
>> response?
>>
>> import akka.actor.ActorRef;
>>
>> import akka.actor.ActorSystem;
>> import akka.actor.Props;
>> import akka.actor.UntypedActor;
>> import akka.http.model.japi.HttpMethods;
>> import akka.http.model.japi.HttpResponse;
>> import akka.http.model.japi.headers.AccessControlAllowHeaders;
>> import akka.http.model.japi.headers.AccessControlAllowMethods;
>> import akka.http.model.japi.headers.AccessControlAllowOrigin;
>> import akka.http.model.japi.headers.HttpOriginRange;
>> import akka.http.server.japi.HttpApp;
>> import akka.http.server.japi.RequestContext;
>> import akka.http.server.japi.Route;
>> import akka.pattern.Patterns;
>>
>>
>> public class MetaApi extends HttpApp {
>>
>>private static ActorSystem actorSystem;
>>private static ActorRef handlerActor;
>>
>>public static class HandlerActor extends UntypedActor {
>>   @Override
>>   public void onReceive( Object message ) throws Exception {
>>  if ( message instanceof RequestContext ) {
>> RequestContext ctx = (RequestContext)message;
>> // ...
>>  } else {
>> unhandled( message );
>>  }
>>   }
>>}
>>@Override
>>public Route createRoute() {
>>   return route( path( "meta" ).route(
>> get( handleWith( ctx -> {
>>HttpResponse response = HttpResponse.create()
>>  .addHeader( AccessControlAllowOrigin.create(
>> HttpOriginRange.ALL ) )
>>  .addHeader(
>>AccessControlAllowHeaders.create(
>> "Access-Control-Allow-Origin",
>>  "Access-Control-Allow-Method",
>> "Content-Type" ) )
>>  .addHeader(
>>AccessControlAllowMethods.create( HttpMethods.
>> GET, HttpMethods.POST, HttpMethods.PUT,
>>  HttpMethods.OPTIONS, HttpMethods.DELETE
>> ) )
>>  .withEntity( "Response of actor?" ); //
>> Patterns.ask( handlerActor, ctx, 10_000 );
>>return ctx.complete( response );
>> } ) ) ) );
>>}
>>
>>
>>public static void main(String ... args) throws Exception {
>>   MetaApi api = new MetaApi();
>>   actorSystem = ActorSystem.create();
>>  handlerActor = actorSystem.actorOf( Props.create( HandlerActor.
>> class ), "Get Handler" );
>>   api.bindRoute("localhost",8080, actorSystem);
>> }
>>
>>
>> }
>>
>>
>> Thanks & best regards
>> Peter
>>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send 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.
>



-- 
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] Naming mismatch? FlowGraphBuilder = Builder of FlowGraph vs GraphFlow

[Martynas Mickevičius]

As good as done: https://github.com/akka/akka/issues/16687

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

[Jean Helou]

Hello Roland, 
 
thanks for taking the time to answer. 

your description very much sounds like an Actor should be handling the 
> pool, not a router.
>

Alright, however I am still curious as to why the BalancingPool doesn't 
handle resize and why RoundRobinPool + BalancingDispatcher is deprecated. 
 

> You can use the DefaultResizer stand-alone (for determining what to do) 
> and you can also use the RoundRobinRoutingLogic stand-alone (for 
> determining where to send to); then the only missing piece is to place 
> these inside an Actor that will then start new Actors (easy) or stop Actors 
> in a coordinated fashion (straight-forward: just send a termination request 
> and take it out of the list of routees you pass into the RoutingLogic).
>

 starting & stopping actors is indeed easy, using the 
RoundRobinRoutingLogic is fairly straightforward. Implementing the 
management messages is starting to be a bit of a bother. Using 
DefaultResizer for anything else than a fixed size actor based pool is 
really not trivial.

As I said in my introduction 

>  I experimented with a fixed size pool but ultimately I would prefer an 
> elastic pool able to spawn despawn actors depending on request pressure


Hopefully the following will fill the fixed size pool with a round robin 
behavior , an enforced fixed size  and can be safely combined with 
routeeProps having a BalancingDispatcher.

package actors.browser
>  
> import akka.actor.{Terminated, Props, ActorLogging, Actor}
> import akka.routing._
>  
> import scala.collection.immutable.IndexedSeq
>  
> class RoundRobinFixedSizeActorPool(routeeProps:Props, nbActors:Int) extends 
> Actor with ActorLogging{
>   val resizer = DefaultResizer(nbActors, nbActors)
>   val routingLogic = RoundRobinRoutingLogic()
>  
>   var routees: IndexedSeq[Routee] = (1 until resizer.lowerBound).map{_=>
> val routee = context.actorOf(routeeProps)
> context.watch(routee)
> ActorRefRoutee(routee)
>   }
>  
>   override def receive: Receive = {
> case Terminated(actor) if routees.contains(ActorRefRoutee(actor))=>
>   routees=routees.filterNot(_ == ActorRefRoutee(actor))
>   val routee = context.actorOf(routeeProps)
>   context.watch(routee)
>   routees=routees :+ ActorRefRoutee(routee)
> case GetRoutees =>
>   sender() ! Routees(routees)
> case evt => routingLogic.select(evt, routees).send(evt,sender())
>   }
> }
> object RoundRobinFixedSizeActorPool{
>   def props(props:Props, nbActors:Int)=Props(new 
> RoundRobinFixedSizeActorPool(props, nbActors))
> }


How would you recommend going from there to a pressure sensitive actor pool 
oscillating between a min and a max ? 

Does the following look correct (I am unsure how to write tests for this 
... ) ?

package actors.browser
>  
> import java.util.concurrent.atomic.AtomicLong
>  
> import akka.actor._
> import akka.routing._
>  
> import scala.collection.immutable.IndexedSeq
>  
> class RoundRobinActorPool(routeeProps: Props, minRoutees: Int, maxRoutees: 
> Int) extends Actor with ActorLogging {
>   val resizer: Resizer = DefaultResizer(minRoutees, maxRoutees)
>   val nbMsgs = new AtomicLong()
>   val routingLogic = RoundRobinRoutingLogic()
>  
>   var routees: IndexedSeq[Routee] = IndexedSeq()
>   upsize(minRoutees)
>  
>   override def receive: Receive = {
> case Terminated(actor) if routees.contains(ActorRefRoutee(actor)) =>
>   routees = routees.filterNot(_ == ActorRefRoutee(actor))
> case GetRoutees =>
>   sender() ! Routees(routees)
> case evt =>
>   if (resizer.isTimeForResize(nbMsgs.incrementAndGet())) {
> resizer.resize(routees)
>   }
>  
>   routingLogic.select(evt, routees).send(evt, sender())
>   }
>  
>   private def resize(delta: Int) = {
> if (delta < 0) downsize(delta)
> else upsize(delta)
>   }
>  
>   private def downsize(delta: Int) = {
> val (killed, remaining) = this.routees.splitAt(delta)
> this.routees = remaining
> killed.foreach(_.send(PoisonPill, self))
>   }
>  
>   private def upsize(delta: Int) = {
> routees = routees ++ (1 until minRoutees).map { _ =>
>   val routee = context.actorOf(routeeProps)
>   context.watch(routee)
>   ActorRefRoutee(routee)
> }
>   }
> }
>  
> object RoundRobinActorPool {
>   def props(props: Props,minRoutees: Int, maxRoutees: Int) = Props(new 
> RoundRobinActorPool(props, minRoutees, maxRoutees))
> }
>
>
Are you aware of a contrib/3rd party package which would offer Actor based 
pools while preserving most of the semantics of router based ones ?

Thanks for your help
Jean

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

[akka-user] Custom response for Empty (NotFound) results. e.g. RejectionHandler

[Everson Alves da Silva]

Hi,

I need to wrap every response into json objects, including errors such as 
404. I got most of it working by providing RejectionHandler and 
ExceptionHandler.

One piece that is missing is handling the case where the complete{} block 
is invoking an expression that returns Future[Option[X]]. If the option is 
None, then the request returns 404 but the RejectionHandler doesn't catch 
it, even with if I put a catch-all case.

Any way I can catch this case without resorting to use something like 
.getOrElse on every expression of that type (we have lots of them)?

Thanks,
@johnny_everson

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

[André]

Hi Allan,

have you tried the completeWith 

 
directive? Look here 
for
 
examples.

Cheers
André

On Tuesday, January 20, 2015 at 2:14:49 PM UTC+1, Allan Brighton wrote:
>
> Hi Roland,
>
> I wasn't sure how to use the new streaming APIs from the spray DSL, so I 
> used the akka-http core API instead:
>
>   implicit val materializer = FlowMaterializer()
>
>   val binding = Http().bind(interface = settings.interface, port = 
> settings.port)
>   binding.connections.foreach { c ⇒
> logger.info(s"Accepted new connection from ${c.remoteAddress}")
> c.handleWithAsyncHandler {
>   case HttpRequest(GET, uri, _, _, _)   ⇒ httpGet(uri)
>   case HttpRequest(POST, uri, _, entity, _) ⇒ httpPost(uri, entity)
>   case HttpRequest(HEAD, uri, _, _, _)  ⇒ httpHead(uri)
>   case HttpRequest(DELETE, uri, _, _, _)⇒ httpDelete(uri)
>   case _: HttpRequest   ⇒ Future.successful(
> HttpResponse(StatusCodes.NotFound, entity = "Unknown resource!"))
> }
>   }
>
> Is use of the spray DSL still encouraged or is it deprecated in favour of 
> the above usage?
>
> Thanks,
> Allan
>
> On Tuesday, January 20, 2015 at 1:10:56 PM UTC+1, rkuhn wrote:
>>
>> Hi Allan,
>>
>> there should in principle be a marshaller that wraps your Source into an 
>> Entity, what is the exact error you are seeing?
>>
>> Regards,
>>
>> Roland
>>
>> 7 jan 2015 kl. 14:00 skrev Allan Brighton :
>>
>> Hi,
>>
>> I know how to do this now using the new akka-http core API, but how would 
>> it work using the spray-like DSL?
>> How can I complete an http get using a Future[Source[ByteString]]?
>>
>> import akka.http.model._
>> import akka.http.server._
>> ...
>>   def route: Route =
>> path("get") {
>>   get {
>> parameters('path, 'id ?) { (path, id) =>
>>   respondWithMediaType(`application/octet-stream`) {
>> complete {
>>   val f: Future[Source[ByteString]] = ???
>>   f.onComplete {
>> case Success(source) => ...
>> case Failure(ex) => ...
>>   }
>> }
>>   }
>> }
>>   }
>> }
>>
>> I would also be interested in an example going the other way: 
>> implementing an http post that receives data from a stream.
>>
>> 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.
>>
>>
>>
>>
>> *Dr. Roland Kuhn*
>> *Akka Tech Lead*
>> Typesafe  – Reactive apps on the JVM.
>> 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.

Re: [akka-user] akka-http-experimental: Using the spray DSL: how to complete a route with a Source[ByteString]?

[Allan Brighton]

Hi Roland,

I wasn't sure how to use the new streaming APIs from the spray DSL, so I 
used the akka-http core API instead:

  implicit val materializer = FlowMaterializer()

  val binding = Http().bind(interface = settings.interface, port = settings.
port)
  binding.connections.foreach { c ⇒
logger.info(s"Accepted new connection from ${c.remoteAddress}")
c.handleWithAsyncHandler {
  case HttpRequest(GET, uri, _, _, _)   ⇒ httpGet(uri)
  case HttpRequest(POST, uri, _, entity, _) ⇒ httpPost(uri, entity)
  case HttpRequest(HEAD, uri, _, _, _)  ⇒ httpHead(uri)
  case HttpRequest(DELETE, uri, _, _, _)⇒ httpDelete(uri)
  case _: HttpRequest   ⇒ Future.successful(
HttpResponse(StatusCodes.NotFound, entity = "Unknown resource!"))
}
  }

Is use of the spray DSL still encouraged or is it deprecated in favour of 
the above usage?

Thanks,
Allan

On Tuesday, January 20, 2015 at 1:10:56 PM UTC+1, rkuhn wrote:
>
> Hi Allan,
>
> there should in principle be a marshaller that wraps your Source into an 
> Entity, what is the exact error you are seeing?
>
> Regards,
>
> Roland
>
> 7 jan 2015 kl. 14:00 skrev Allan Brighton 
> >:
>
> Hi,
>
> I know how to do this now using the new akka-http core API, but how would 
> it work using the spray-like DSL?
> How can I complete an http get using a Future[Source[ByteString]]?
>
> import akka.http.model._
> import akka.http.server._
> ...
>   def route: Route =
> path("get") {
>   get {
> parameters('path, 'id ?) { (path, id) =>
>   respondWithMediaType(`application/octet-stream`) {
> complete {
>   val f: Future[Source[ByteString]] = ???
>   f.onComplete {
> case Success(source) => ...
> case Failure(ex) => ...
>   }
> }
>   }
> }
>   }
> }
>
> I would also be interested in an example going the other way: implementing 
> an http post that receives data from a stream.
>
> 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.
>
>
>
>
> *Dr. Roland Kuhn*
> *Akka Tech Lead*
> Typesafe  – Reactive apps on the JVM.
> 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.

Re: [akka-user] upgrading production cluster (sharded) system

[09goral .]

I guess you mean *blue/green *? :)

2015-01-20 11:38 GMT+01:00 Roland Kuhn :

> Hi Peter,
>
> upgrading usually implies that some changes were made: bugs were fixed and
> features added. This usually also implies that some messages have change in
> format or meaning (if only from “broken” to “works now”). Operating nodes
> of different understanding within the same cluster is a very risky
> proposition as it is very hard to get right—the new nodes must be fully
> capable of understanding the old ones and they must also not confuse the
> old ones with new language. Other issues arise when talking to a shared
> data store: if new nodes write new data, will the old nodes be able to deal
> with it? Will they silently and unknowingly corrupt new records?
>
> For these reasons the stories from the field I have heard have all pointed
> towards doing red/blue deployments, starting a new cluster next to the old
> one and shifting traffic and deployment size between them in order to
> switch over.
>
> Regards,
>
> Roland
>
> 14 jan 2015 kl. 18:44 skrev Peter :
>
> Hi
>
> I wonder if anyone has experience or thoughts to share about upgrading
> production cluster systems?
>
> I would ideally like to
>
>- upgrade the cluster without downtime/scheduled outage
>- not mutate infrastructure, in other words, deploy a new set of nodes
>with the new version
>- do a staged upgrade, first just a single node taking as little as
>possible production traffic - a canary in the coal mine
>
>
> A little bit more about my specific environment
>
>- cluster runs as a single EC2 autoscale group
>- no akka roles (looking into this as a way to gain independence
>between functional areas within the application & facilitate independent
>upgrades - something akin to micro services to use the buzzword du jour)
>- i don't use akka persistence but each sharded actor is backed by my
>own distributed persistence mechanism based on DynamoDB
>- there is some tolerance for stale reads but there could be some
>cases where it's not acceptable
>
> My understanding is that the number of cluster shards should be kept
> constant irrespective of number of cluster nodes, so that the shard
> resolution also remains stable irrespective of number of cluster nodes, as
> in the example in the documentation. It sounds like the bundled rebalancing
> strategy (LeastShardAllocationStrategy) should do the trick when adding the
> first node (canary). I'm wondering if there's any suggestions for doing the
> rest?
>
>
>- start all of the remaining new cluster nodes
>   - at what point does rebalancing get kicked off? is there a
>   specific event that triggers a rebalance? is it possible to delay until 
> all
>   the new nodes/X nodes has joined/Y time has passed to minimize 
> disruption
>   (single rebalance vs rebalance for every node)
>- wait for period X to ensure rebalancing is complete and all buffered
>messages during rebalancing has been processed
>   - is it possible to determine this programmatically?
>- stop all the old version nodes
>   - one by one with a period in between or all at once?
>   - at this point, messages in flight are lost, need to fall back to
>   clients to retry
>
> It gets progressively more hand wavy towards the end as I'm still thinking
> about the details, would love some input & feedback!
>
> Thanks
> Peter
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send 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.
>
>
>
>
> *Dr. Roland Kuhn*
> *Akka Tech Lead*
> Typesafe  – Reactive apps on the JVM.
> 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 a topic in the
> Google Groups "Akka User List" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/akka-user/tC2RfJBruYA/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

Re: [akka-user] BalancingPool versus RoundRobinPool + BalancingDispatcher

[Roland Kuhn]

Hi Jean,

your description very much sounds like an Actor should be handling the pool, 
not a router. You can use the DefaultResizer stand-alone (for determining what 
to do) and you can also use the RoundRobinRoutingLogic stand-alone (for 
determining where to send to); then the only missing piece is to place these 
inside an Actor that will then start new Actors (easy) or stop Actors in a 
coordinated fashion (straight-forward: just send a termination request and take 
it out of the list of routees you pass into the RoutingLogic).

Regards,

Roland

> 13 jan 2015 kl. 10:26 skrev Jean Helou :
> 
> Hi everyone, 
> 
> 
> Using Akka 2.3.6, I would like to create a fixed size actor pool which keeps 
> a constant number of actors, spawning new routees to replace any routee which 
> stops or dies. I would also like to loose as few messages as possible. I 
> experimented with a fixed size pool but ultimately I would prefer an elastic 
> pool able to spawn despawn actors depending on request pressure.
> 
> A simple RoundRobinPool or even a SmallestMailboxPool can easily be made to 
> resize in the way I want, but  any message already routed to the actor when 
> it stops will be lost and sent to deadletters. A collaborative mailbox sounds 
> as offered by the BalancingPool is very appealing to avoid having to 
> implement a handler for the deadletters. However, according to the code: 
> "Resizer cannot be used together with BalancingPool". 
> 
> Sifting through the mailing list I found multiple recommendations to use a 
> RoundRobinPool with a BalancingDispatcher, however when experimenting with it 
> I  encountered the following deprecation warning : 
> 
>  Caused by: java.lang.IllegalArgumentException: BalancingDispatcher is 
> deprecated, use a BalancingPool instead. During a migration period you can 
> still use BalancingDispatcher by specifying the full class name: 
> akka.dispatch.BalancingDispatcherConfigurator
> 
> While I was able to make the RoundRobinPool work by specifying 
> akka.dispatch.BalancingDispatcherConfigurator, I wasn't able to find the 
> answer to the following questions in either the mailing list or the 
> documentation :
> - Why can't resizers be use with BalancingPool ?
> - Why the deprecation ? 
> - Is my setup actually subtly incorrect even though it seems to behave 
> correctly in test runs ? 
> - Is there an alternative setup offering the same benefits which I have 
> missed ? 
> 
> The routees are very heavily IO bound, I don't really care about the 
> performance offered by the routers, but I would much prefer not to have to 
> reimplement the pool tracking logic myself.
> 
> Thank you !
> Jean
> 
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send 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 
> .



Dr. Roland Kuhn
Akka Tech Lead
Typesafe  – Reactive apps on the JVM.
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.

Re: [akka-user] ClusterSingleton, multiple proxies?

[Roland Kuhn]

Hi Brice,

> 15 jan 2015 kl. 17:15 skrev Brice Figureau :
> 
> Hi,
> 
> I have several utility ClusterSingleton actors in my cluster that are
> used by several client actors (some of them are also singleton or
> ClusterSharding entries).
> 
> Those client actors are currently created by passing the ActoRef of said
> utility singletons proxies as Props arguments. This can't work when
> those actors are themselves singletons or sharded entries, because they
> might run on a different node than the passed-in proxies (and props
> might not even be serialized?).
> 
> So I need to refactor all this to not pass any ActorRef. 
> 
> My question finally is what would be the best way to achieve that:
> * have client actors create their own proxy (or ClusterShard region).
> This doesn't seem the good solution :(
> 
> or
> * have a well known per-node registry actor that creates the needed
> proxies (and region) at start and can send those ActorRef to client
> actors.
> 
> I'm much more inclined toward the second solution, but unfortunately it
> makes the various tests a bit more complex (setup a registry instead of
> injecting TestProbe).

You would still inject a TestProbe by injecting a mock registry (can be the 
same as the production code but filled with TestProbes). Otherwise I don’t see 
anything wrong with this proposal.

Regards,

Roland

> 
> What do you think?
> Is there a better solution I didn't think about?
> -- 
> Brice Figureau
> My Blog: http://www.masterzen.fr/
> 
> -- 
>>> Read the docs: http://akka.io/docs/
>>> Check the FAQ: 
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send 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.



Dr. Roland Kuhn
Akka Tech Lead
Typesafe – Reactive apps on the JVM.
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.

Re: [akka-user] akka-http-experimental: Using the spray DSL: how to complete a route with a Source[ByteString]?

[Roland Kuhn]

Hi Allan,

there should in principle be a marshaller that wraps your Source into an 
Entity, what is the exact error you are seeing?

Regards,

Roland

> 7 jan 2015 kl. 14:00 skrev Allan Brighton :
> 
> Hi,
> 
> I know how to do this now using the new akka-http core API, but how would it 
> work using the spray-like DSL?
> How can I complete an http get using a Future[Source[ByteString]]?
> 
> import akka.http.model._
> import akka.http.server._
> ...
>   def route: Route =
> path("get") {
>   get {
> parameters('path, 'id ?) { (path, id) =>
>   respondWithMediaType(`application/octet-stream`) {
> complete {
>   val f: Future[Source[ByteString]] = ???
>   f.onComplete {
> case Success(source) => ...
> case Failure(ex) => ...
>   }
> }
>   }
> }
>   }
> }
> 
> I would also be interested in an example going the other way: implementing an 
> http post that receives data from a stream.
> 
> 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+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 
> .



Dr. Roland Kuhn
Akka Tech Lead
Typesafe  – Reactive apps on the JVM.
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.

Re: [akka-user] Akka Cluster Project - Monolithic JAR or JARs per "service"?

[Roland Kuhn]

> 7 jan 2015 kl. 11:53 skrev Kane Rogers :
> 
> Awesome. This is exactly the answer I was looking for, Ryan!
> 
> I need to read and re-read your post a couple more times for it to sink in, 
> but this seems like a great starting point. A blog article on this topic 
> would really be appreciated, though! :- )
> 
> I'm of the opinion that while Typesafe has done an absolutely brilliant job 
> at documenting the technology from a developer's point of view, documentation 
> on the ops/production side of things really is a little lacking. I'm super 
> glad that business like Conspire are giving back to the community like this - 
> your 5 part blog series has been absolutely invaluable to us.
> 
> Thanks again, Ryan,

Very much seconded, thanks a lot Ryan! We are working on better coverage for 
deployment of Akka (and Scala, Play—the whole Reactive Platform), but 
successful reports from active users are the best.

Regards,

Roland

> 
> Kane
> 
> 
> On Wednesday, 7 January 2015 02:39:57 UTC+11, Ryan Tanner wrote:
> We're also deploying an Akka cluster on CoreOS with Docker.  We deploy the 
> same fat JAR for every node (in fact, the exact same docker image) and then 
> change their behavior by setting the role via environment variables.
> 
> In our case, each role has a "bootstrap" class which sets up whatever 
> role-specific actors might be needed (but *not* the worker actors) as well as 
> the actors needed on every node.  Cluster-aware routers running on our 
> supervisor node are responsible for actually creating the worker actors as 
> needed.
> 
> We still split each role into sub-projects in our SBT project.  We then have 
> an SBT project within that called "node" which aggregates all of the 
> service-specific sub-projects into a single JAR and builds the Docker image 
> using sbt-docker.  This way, we can iterate quickly on code within a specific 
> service and keep our compile/test times down.  That "node" project also 
> houses our multi-JVM end-to-end tests.
> 
> Then, opposite that, is our "commons" project which every other project 
> depends on.  The service projects explicitly do *not* depend on each other, 
> only commons.  This keeps us from getting them too coupled.
> 
> Since our service isn't directly user-facing, we don't bother trying to 
> upgrade a single service at a time, we just restart the whole thing and let 
> it pull down the new Docker image if needed.
> 
> Most of this is written up on our blog: 
> http://blog.conspire.com/post/64130417462/akka-at-conspire-part-1-how-we-built-our-backend-on
>  
> 
> 
> I've been meaning to write about our transition from Chef/Vagrant to 
> CoreOS/Docker but I haven't found the time yet.  Hopefully within the next 
> few weeks (which, of course, I said a month ago).
> 
> On Sunday, January 4, 2015 6:42:21 PM UTC-7, Kane Rogers wrote:
> Hi, hAkkers!
> 
> We're in the process of moving our distributed Akka service from the dark 
> ages of remoting and manual management of IPs (shudder) into the wonderful 
> new world of Akka Cluster.
> 
> Currently, our project is split up something like this:
> spray-frontend
> worker-1
> worker-2
> worker-3
> Where the spray-frontend forwards messages to the different worker,  
> depending on the type of job. In our current environment, each of these 
> projects are deployed as individual fat JARs using sbt-assembly, and deployed 
> onto individual nodes. 
> 
> In our planned environment, we'll be deploying these fat JARs into docker 
> containers and allow CoreOS to take care of distributing the nodes. We're 
> toying with things like roles, ClusterPoolRouter and ClusterGroupRouter to 
> take care of distributing work amongst the correct node - but nothing is set 
> in stone yet.
> 
> This then begs the question - how should these nodes be deployed? I can see a 
> couple of possibilities:
> 
> Docker container with fat JAR per project (eg. spray-frontend container, 
> worker-1 container etc. etc).
> Docker container with fat JAR containing all projects (eg. one container 
> containing code for spray-frontend AND worker-1 etc.). Role is then set via 
> environment variable, or a different main class is fired off on startup.
> Exploring the different options, one limitation that I can see is that 
> ClusterPoolRouter requires the class of the actor that's going to be remotely 
> deployed to the cluster to be present on the class path of the router. That 
> is, if our front-ends are to create a worker on a remote machine to handle a 
> request, the class for that router must be in the JAR on the front-end 
> machine. Please correct me if I'm mistaken here.
> 
> The advantage we've found in splitting the project up into these different 
> sub-projects is tests are a lot quicker, code is smaller, etc. etc. Upgrades 
> are also then made easier, as only certain machines have to be 
> upgraded/restarted if a component of

Re: [akka-user] Naming mismatch? FlowGraphBuilder = Builder of FlowGraph vs GraphFlow

[Roland Kuhn]

> 6 jan 2015 kl. 14:18 skrev Patrik Nordwall :
> 
> Hi Jacek,
> 
> The public API consist of FlowGraph and FlowGraphBuilder. GraphFlow is an 
> internal implementation detail.
> 
> Regards,
> Patrik
> 
> PS. In my opinion we should rename GraphFlow to something else. It's rather 
> confusing for anyone reading the source code.

Yes, please.

> 
> 
> On Tue, Jan 6, 2015 at 12:04 PM, Jacek Laskowski  > wrote:
> Hi,
> 
> Notice the naming mismatch - FlowGraphBuilder builds FlowGraph's when there's 
> also the case class GraphFlow. Are the types (supposed to be) working 
> together? What's the reason behind the naming difference?
> 
> Just ran across it this morning while reviewing the source code and worth to 
> point out that I have no idea what the two types are for.
> 
> Jacek
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send 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 
> .



Dr. Roland Kuhn
Akka Tech Lead
Typesafe  – Reactive apps on the JVM.
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.

Re: [akka-user] Akka 2.3.8: context.stop(self) and self ! PoisonPill fails on remotely deployed actors

[Roland Kuhn]

Hi Brian,

I’m not sure I understand: what exactly do you mean by “it fails”? The log you 
provided just says that the system has shut down after the actor was terminated.

Regards,

Roland

> 12 jan 2015 kl. 11:43 skrev Brian Fowler :
> 
> Hi,
> 
> Can anyone help with the following in Akka 2.3.8
> 
> The actor
> 
> class SquarerActor extends Actor with ActorLogging {
>   override def receive = {
> case SquareTask(id, number, _) => {
>   log.info(s"${Thread.currentThread()} ${id}: ${number}^2 = 
> ${number*number} for ${sender}")
>   context.stop(self)
> }
> case _ => {
>   log.info(s"unknown message received")
> }
>   }
> }
> 
> when created locally from 
> 
> class TaskAllocatorActor extends Actor with ActorLogging {
>   override def receive = {
> case task: SquareTask => {
>   log.info(s"${Thread.currentThread()} received ${task} from ${sender}")
> 
>   context.actorOf(Props[SquarerActor],task.id) ! task
> }
> case _ => {
>   println("Unknown Task")
> }
>   }
> }
> 
> works, but when deployed remotely using
> 
> class TaskAllocatorActor extends Actor with ActorLogging {
>   override def receive = {
> case task: SquareTask => {
>   log.info(s"${Thread.currentThread()} received ${task} from ${sender}")
> 
> 
>   val actorRef = context.actorOf(Props[SquarerActor]
> .withDeploy(Deploy(scope = 
> RemoteScope(AddressFromURIString("akka.tcp://Example2BoxTwo@127.0.0.1:2553",
>  task.id)
>   actorRef ! task
> }
> case _ => {
>   println("Unknown Task")
> }
>   }
> }
> 
> the SquarerActor context.stop(self) fails, on the remote system the log is 
> below, note that the remote actor receives the message and executes the 
> receive block but the context.stop(self) fails 
> 
> [2015-01-12 10:33:47,735] [DEBUG] 
> LocalActorRefProvider(akka://Example2BoxTwo) - Received command 
> [DaemonMsgCreate(Props(Deploy(,Config(SimpleConfigObject({})),NoRouter,RemoteScope(akka.tcp://Example2BoxTwo@127.0.0.1:2553),,),class
>  
> com.markit.brianfowler.presentations.akkatotem201501.actors.SquarerActor,Vector()),Deploy(,Config(SimpleConfigObject({})),NoRouter,RemoteScope(akka.tcp://Example2BoxTwo@127.0.0.1:2553),,),akka.tcp://Example2BoxTwo@127.0.0.1:2553/remote/akka.tcp/Example1OneBoxOneTaskAllocatorActor@127.0.0.1:2552/user/taskAllocatorActor/5#562890728,Actor[akka.tcp://Example1OneBoxOneTaskAllocatorActor@127.0.0.1:2552/user/taskAllocatorActor#1735676205])]
>  to RemoteSystemDaemon on [akka://Example2BoxTwo] 
> [2015-01-12 10:33:47,747] [INFO] SquarerActor - 
> Thread[Example2BoxTwo-akka.actor.default-dispatcher-21,5,main] 5: 5^2 = 25 
> for 
> Actor[akka.tcp://Example1OneBoxOneTaskAllocatorActor@127.0.0.1:2552/user/taskAllocatorActor#1735676205]
>  
>  [2015-01-12 10:33:47,760] [DEBUG] 
> LocalActorRefProvider(akka://Example2BoxTwo) - resolve of path sequence 
> [/remote/akka.tcp/Example1OneBoxOneTaskAllocatorActor@127.0.0.1:2552/user/taskAllocatorActor/5#562890728]
>  failed 
> [2015-01-12 10:33:47,792] [WARN] LocalActorRefProvider(akka://Example2BoxTwo) 
> - Unknown message 
> [DeathWatchNotification(Actor[akka.tcp://Example1OneBoxOneTaskAllocatorActor@127.0.0.1:2552/user/taskAllocatorActor#1735676205],true,false)]
>  received by [Actor[akka://Example2BoxTwo/remote]] 
> [2015-01-12 10:33:47,820] [ERROR] akka.remote.EndpointWriter - 
> AssociationError [akka.tcp://Example2BoxTwo@127.0.0.1:2553] <- 
> [akka.tcp://Example1OneBoxOneTaskAllocatorActor@127.0.0.1:2552]: Error [Shut 
> down address: akka.tcp://Example1OneBoxOneTaskAllocatorActor@127.0.0.1:2552] 
> [ akka.remote.ShutDownAssociation: Shut down address: 
> akka.tcp://Example1OneBoxOneTaskAllocatorActor@127.0.0.1:2552 Caused by: 
> akka.remote.transport.Transport$InvalidAssociationException: The remote 
> system terminated the association because it is shutting down. ] 
> [2015-01-12 10:33:47,820] [ERROR] akka.remote.EndpointWriter - 
> AssociationError [akka.tcp://Example2BoxTwo@127.0.0.1:2553] <- 
> [akka.tcp://Example1OneBoxOneTaskAllocatorActor@127.0.0.1:2552]: Error [Shut 
> down address: akka.tcp://Example1OneBoxOneTaskAllocatorActor@127.0.0.1:2552] 
> [ akka.remote.ShutDownAssociation: Shut down address: 
> akka.tcp://Example1OneBoxOneTaskAllocatorActor@127.0.0.1:2552 Caused by: 
> akka.remote.transport.Transport$InvalidAssociationException: The remote 
> system terminated the association because it is shutting down. ] 
> 
> Thanks,
> 
> 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 gro

Re: [akka-user] upgrading production cluster (sharded) system

[Roland Kuhn]

Hi Peter,

upgrading usually implies that some changes were made: bugs were fixed and 
features added. This usually also implies that some messages have change in 
format or meaning (if only from “broken” to “works now”). Operating nodes of 
different understanding within the same cluster is a very risky proposition as 
it is very hard to get right—the new nodes must be fully capable of 
understanding the old ones and they must also not confuse the old ones with new 
language. Other issues arise when talking to a shared data store: if new nodes 
write new data, will the old nodes be able to deal with it? Will they silently 
and unknowingly corrupt new records?

For these reasons the stories from the field I have heard have all pointed 
towards doing red/blue deployments, starting a new cluster next to the old one 
and shifting traffic and deployment size between them in order to switch over.

Regards,

Roland

> 14 jan 2015 kl. 18:44 skrev Peter :
> 
> Hi
> 
> I wonder if anyone has experience or thoughts to share about upgrading 
> production cluster systems?
> 
> I would ideally like to 
> upgrade the cluster without downtime/scheduled outage
> not mutate infrastructure, in other words, deploy a new set of nodes with the 
> new version
> do a staged upgrade, first just a single node taking as little as possible 
> production traffic - a canary in the coal mine
> 
> A little bit more about my specific environment
> cluster runs as a single EC2 autoscale group
> no akka roles (looking into this as a way to gain independence between 
> functional areas within the application & facilitate independent upgrades - 
> something akin to micro services to use the buzzword du jour) 
> i don't use akka persistence but each sharded actor is backed by my own 
> distributed persistence mechanism based on DynamoDB
> there is some tolerance for stale reads but there could be some cases where 
> it's not acceptable
> My understanding is that the number of cluster shards should be kept constant 
> irrespective of number of cluster nodes, so that the shard resolution also 
> remains stable irrespective of number of cluster nodes, as in the example in 
> the documentation. It sounds like the bundled rebalancing strategy 
> (LeastShardAllocationStrategy) should do the trick when adding the first node 
> (canary). I'm wondering if there's any suggestions for doing the rest?
> 
> start all of the remaining new cluster nodes 
> at what point does rebalancing get kicked off? is there a specific event that 
> triggers a rebalance? is it possible to delay until all the new nodes/X nodes 
> has joined/Y time has passed to minimize disruption (single rebalance vs 
> rebalance for every node)
> wait for period X to ensure rebalancing is complete and all buffered messages 
> during rebalancing has been processed 
> is it possible to determine this programmatically?
> stop all the old version nodes 
> one by one with a period in between or all at once?
> at this point, messages in flight are lost, need to fall back to clients to 
> retry
> It gets progressively more hand wavy towards the end as I'm still thinking 
> about the details, would love some input & feedback!
> 
> Thanks
> Peter
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send 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 
> .



Dr. Roland Kuhn
Akka Tech Lead
Typesafe  – Reactive apps on the JVM.
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.c

Re: [akka-user] akka persistence and need for intercept of persisted messages

[Roland Kuhn]

Hi Ketil,

during development you will commonly find and fix mistakes or add feature which 
will require you to scrap all the (wrong) history, but that is fine because 
nothing is really durable at that time. When you go to production the use of 
persistence implies that you need to keep those data around—if not then why 
would you persist them? So the only solution is to remain able to read old 
data, which is most reliably implemented by never removing or changing an old 
event type and only add new ones. While you can of course convert all stored 
events on disk into a new format after a change, this should not be a 
requirement for your program to run—it is more a maintenance optimization.

The best way to convert stored events is to replay them by an Actor that will 
persist them in the new format, currently that would be a PersistentView.

Regards,

Roland

> 16 jan 2015 kl. 14:50 skrev Ketil Johannessen :
> 
> Hi!
> 
> In my current project we are using akka-persistence with LevelDB. Our 
> application is completely event sourced using akka-persistence, i.e there are 
> no other mechanism for persisting business state in use. 
> 
> However, we have identified the need for being able to convert persisted 
> messages, when deploying a new version of the application with changes 
> effecting the persisted data structure (.ie new attributes, deleted 
> attributes, changed datatypes). As of now, we must completely discard our 
> business data every time we deploy a new version, in order to avoid 
> exceptions when replay of persisted messages upon startup.
> 
> I would believe that many other projects face the same problem, and believe 
> that this could be solved with a general mechanism in akka persistence.
> 
> I have done a poc on "daisy-chaining" persistence plugins, by creating my own 
> plugin ("proxy-plugin") and have this plugin forward all messages to the 
> actual persistence plugin (leveldb or cassandra). In addition we are using 
> our own serializer, serializing all messages to json strings prior to 
> persisting (to avoid class version issues).
> 
> In my own proxy-plugin I can now register mapper classes (these implementing 
> a common apply() trait, intercept messages and modify the persisted 
> json-based messages from previous versions to the current deployed. This way 
> we can keep our persisted business messages across versions of the message 
> classes, without the need for discarding old data. The poc now is working ok 
> for journals, but not yet for snapshots.
> 
> There are also other cross-cutting concerns related to persistence where such 
> a feature could be useful, for instance auditing
> 
> Is this something that could be implemented in akka-persistence?
> 
> 
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send 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 
> .



Dr. Roland Kuhn
Akka Tech Lead
Typesafe  – Reactive apps on the JVM.
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.

Re: [akka-user] [akka-stream] Stages unit testing

[Endre Varga]

Hi,


On Mon, Jan 19, 2015 at 5:54 PM, Alexey Romanchuk <
alexey.romanc...@gmail.com> wrote:

> Hey hakkers!
>
> I am currently updating old application built on akka-streams 0.4 to
> 1.0-MX API. I used Transformers and now migrate it to PullPushStages. In
> general migration is pretty easy, but I can not figure out how should I
> rewrite unit test for custom stages?
>
> In 0.4 transformers had simple external API and I use unit test to test
> them. There is context in 1.0 stages API and unit testing is not so
> straightforward. I found that most of prebuild stages test by building
> simple streams, but looks like it is too much testing environment for stage
> testing.
>

I think simple streams are usually all you need for testing PushPullStages
(but not enough for DetachedStages, we need better testing support for them
than the very low level testing stuff we have now). Now there is a hidden
class, that is INTERNAL API for now, but we might open it up. It is called
IteratorInterpreter, and it allows to execute a series of PushPullStages on
top of an Iterator, providing a new Iterator in turn, which basically
drives the Stages. No materialization, no actors, no threads, no
actorsystem, just a plain iterator. I guess it is useful for lot of testing
tasks. Btw, all of the interpreters are very lightweight, they are
basically allocation free even for the hot path, only completion and error
handling uses some allocations.

-Endre


> Could you advise right approach to test streams and custom stages
> especially?
>
> 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.
>

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

[Patrik Nordwall]

Another alternative is to use akka-data-replication
.

/Patrik

On Tue, Jan 20, 2015 at 3:16 AM, Soumya Simanta 
wrote:

> I would recommend using Redis based on personal experience. The current
> stable version is not distributed but the new 3.0 version that will be out
> in a few weeks supports clustering.
> https://groups.google.com/forum/#!topic/redis-db/_DqcFW8EAOA
>
> There are many Scala API for connecting to Redis.
>
> Here are some other options. I personally don't have much experience with
> these.
> MapDB http://www.mapdb.org/
> Hazelcast http://hazelcast.com/
> Chronicle Map http://openhft.net
>
>
>
> On Monday, January 19, 2015 at 8:42:09 PM UTC-5, as...@indexia.co wrote:
>>
>> Hey,
>>
>> I'm trying to build a small akka app that supports authentication via
>> tokens,
>>
>> What would be the simplest approach to store user tokens in a distributed
>> map cache for all akka nodes
>> as I can't guarantee that users will be served by the same akka node,
>>
>>
>> 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.
>



-- 

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.