date:20150514

[akka-user] Core Akka classes in akka-stream-experimental_2.11-1.0-RC2.jar

2015-05-14 Thread Maxim Valyanskiy

Hello!

I see a lot of akka core classes in 
akka-stream-experimental_2.11-1.0-RC2.jar. This breaks sbt assembly plugin. Is 
it a bug in packaging or I'm going something wrong?

[error] 46 errors were encountered during merge

java.lang.RuntimeException: deduplicate: different file contents found in 
the following:

/Users/maxcom/.ivy2/cache/com.typesafe.akka/akka-actor_2.11/jars/akka-actor_2.11-2.3.11.jar:akka/japi/function/Effect.class

/Users/maxcom/.ivy2/cache/com.typesafe.akka/akka-stream-experimental_2.11/jars/akka-stream-experimental_2.11-1.0-RC2.jar:akka/japi/function/Effect.class

deduplicate: different file contents found in the following:

/Users/maxcom/.ivy2/cache/com.typesafe.akka/akka-actor_2.11/jars/akka-actor_2.11-2.3.11.jar:akka/japi/function/Function.class

/Users/maxcom/.ivy2/cache/com.typesafe.akka/akka-stream-experimental_2.11/jars/akka-stream-experimental_2.11-1.0-RC2.jar:akka/japi/function/Function.class

deduplicate: different file contents found in the following:

/Users/maxcom/.ivy2/cache/com.typesafe.akka/akka-actor_2.11/jars/akka-actor_2.11-2.3.11.jar:akka/japi/function/Function10.class

/Users/maxcom/.ivy2/cache/com.typesafe.akka/akka-stream-experimental_2.11/jars/akka-stream-experimental_2.11-1.0-RC2.jar:akka/japi/function/Function10.class

deduplicate: different file contents found in the following:

/Users/maxcom/.ivy2/cache/com.typesafe.akka/akka-actor_2.11/jars/akka-actor_2.11-2.3.11.jar:akka/japi/function/Function11.class

/Users/maxcom/.ivy2/cache/com.typesafe.akka/akka-stream-experimental_2.11/jars/akka-stream-experimental_2.11-1.0-RC2.jar:akka/japi/function/Function11.class

Maxim

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

2015-05-14 Thread Дмитрий Куринский

The common way for pipes:

def receive = {
case m =>
val s = sender()
f(m) pipeTo self
context.become({
  case e:Status.Failure =>
 s ! e
 context.unbecome()
 unstashAll()
  case ok:OkType =>
 s ! ok
 internalState = mutate(internalState, ok)
 context.unbecome()
 unstashAll()
  case _ =>
 stash()
})
}

With FSM I'm doing something more complex, introducing "Processing" data 
type with a Receive handler inside.

This cannot be performed using akka streams (at least I don't know how to 
do it). Problem is not in resolving future (with flatMap, mapAsync, 
pipeTo), but in preserving actor's state.

For command messages actor should stop processing until remote job is done.

I dislike this pattern due to verbosity and mistakes.

For better understanding: I have a persistent actor per aggregate, in a 
sharded environment. So I have to mutate aggregates internal data in a 
transactional manner -- receiving Commands, performing external action with 
future, saving event, mutating internal state.

On Thursday, May 14, 2015 at 9:19:30 PM UTC+3, Andrew Gaydenko wrote:
>
> On Thursday, May 14, 2015 at 8:46:27 PM UTC+3, Patrik Nordwall wrote:
>>
>> If there are no relationship (no ordering) between the future result and 
>> other incoming messages you can just use pipe, without stash.
>>
>
> Let's assume at the moment we have:
>
> def receive = {
>   case Msg(data) =>
> def job = callReturningFuture(data)(context.dispatcher)
> Await.result(job, 1000.millis)
> }
>
> What is the suggestion?
>
>

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

2015-05-14 Thread Artur Opala

Anyone interested in testing/using/developing Akka I/O driver for SCTP 
protocol?

Just started working on this: https://github.com/arturopala/akka-io-sctp

Best Regards, Artur Opala

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

2015-05-14 Thread dpratt

This is actually a fairly interesting problem that I've been putting a lot 
of thought into lately as well. I've been working on a (very rough) 
ground-up implementation of AMQP using the new StreamTcp API, and I've run 
into an interesting problem with RabbitMQ.

Basically, AMQP uses the concept of an Ack for a message into two different 
(and unrelated) concepts:

1) It's used to signal that a message has been handled and consumed, and 
thus may be removed from the queue that it originated in.
2) It's also used to signal back pressure to the broker from a client. When 
creating an AMQP channel, you specify a QoS level, which is the total 
number of in-flight un-acked messages that the broker will deliver to you.

On top of this, Rabbit also uses TCP to signal back pressure the other way 
around - when a client sends too many requests (publishes, etc), it signals 
TCP back pressure.

The incoming/subscription method of using Acks and QoS seems to make sense 
to me, since you don't want a slow consumer to stall all of the other 
subscribing channels on a given connection. I've been playing with the idea 
of modeling a subscription as a BidiFlow with messages being emitted on the 
top side, and having an incoming stream of Ack/Reject messages on the 
bottom side. The top side would adjust the underlying channel's QoS based 
on incoming demand, and leaving the responsibility to Ack messages entirely 
up to the user-defined downstream message-processing Flow. This is 
obviously not ideal, since it would easily allow a poorly-behaved 
downstream that never sends an Ack to cause the QoS on the channel to 
eventually blow up and be unbounded.

The best I can think of to get around this is to just remove the concept of 
Acks from the downstream consumer, and keep it entirely bounded inside of 
the subscription's Source. Namely, keep an internal buffer of messages, and 
send an Ack back to the broker when downstream signals demand and an 
element is emitted. This would work quite well, but it does eliminate some 
of the AMQP model from the downstream processor - namely, there's no way to 
explicitly reject a message as inappropriate. In the grand scheme of 
things, I don't think this is a big deal, however, because for most of the 
use cases I've seen, when a message on an AMQP queue is malformed or 
unprocurable, the last thing you really want to do is put it back on the 
same queue to be processed later.

Forgive the digression and wordiness, this is just something I've been 
thinking about quite a lot recently - my end goal is the ability to have a 
Rabbit client that supports a subset of the protocol (most likely publish 
and subscribe) written and based from the ground up on Akka StreamTcp. Am I 
completely barking the wrong tree here?

On Thursday, May 14, 2015 at 1:12:01 AM UTC-5, rkuhn wrote:
>
>
> 14 maj 2015 kl. 00:43 skrev Tim Harper >:
>
>
> On May 13, 2015, at 01:15, Roland Kuhn > 
> wrote:
>
> Hi Tim,
>
> this looks like a very nice package, thanks for sharing! Since I am not 
> that deeply into RabbitMQ, I guess the “opinionated” part is about favoring 
> at-least-once guarantees and explicit acknowledgement over magic? This 
> would fit in well with the overall Akka philosophy, and that would 
> presumably not be coincidental ;-)
>
>
> It's the consumer pattern, deserialization pattern and error-reporting 
> pattern, bundled up into one integrated package.
>
> How has your experience been so far with building upon Akka Streams, did 
> you miss anything or find anything especially great?
>
>
> I love Akka Streams. My only qualm currently (was going to comment on the 
> thread in which you solicited feedback on the DSL) is the 
> .toMat(sink)(Keep.right); I frequently use the Future from Sink.foreach 
> and wish it were the default.
>
>
> In that situation you can use .runWith(Sink.head) where the default is to 
> return the Future—we use that in almost all our tests ;-) The non-running 
> DSL methods all consistently default to the “left” side since that is 
> obviously correct for almost all of them (like map/filter/drop/take), while 
> the convenience runners default to their argument to provide this choice in 
> a nicer fashion for some prominent use-cases.
>
>
> Looking at your code samples there is possibly one difficult part, which 
> is the Promise that gets fed into the Sink in order to signal 
> completion—perhaps that could be modeled more cleanly by exposing an 
> outgoing stream of acknowledgements (i.e. making the producer a Flow and 
> not a Sink) so that a feedback loop would inform upstream producers of 
> successful ingestion.
>
>
> That's an interesting idea; I am using promises right now to achieve that 
> result, and the pattern works relatively well. It allows me to pass the 
> original upstream acknowledgement promise into the publisher sink, such 
> that the message isn't considered "done" until any resultant messages are 
> persisted in another message queue.
>
> I've though

[akka-user] Looking for the right remoting config to tune when 'unreachable' is not an error - to stop connecting after configurable duration

2015-05-14 Thread Helena Edelson

Hi,

I am looking for the right remoting config to tune for expected unreachable 
behavior when a node goes down, to not continue past n-duration to keep 
trying to connect. For what I'm doing it can be perfectly normal for a node 
to go down and come up again. It's chaos monkey friendly.

This is the known logging, that I want to prevent the cause of when 
expected: I see it go on forever vs stop after a certain period:
WARN  19:50:12 Tried to associate with unreachable remote address 
[akka.tcp://system@host:port]. Address is now gated for 1000 ms, all 
messages to this address will be delivered to dead letters. Reason: 
Connection refused: /host:port

I have a cluster of 2 roles, say nodes of roles A and B. I have a node of 
role A running, and as I bringing role B nodes up and down ( in lifecycle 
testing),  I want nodes of role A to not interpret the remoting 'Connection 
refused' as an error but to simply stop attempting to use it, to forget 
about the address/port completely. A downed node will come back with a new 
port. So it's not the cluster MemberRemoved and Unreachable events, just 
seems the remoting configuration I need to add/modify. 

What might that be? I've been trying a few things, nothing clicking yet ;)

Thanks,
Helena
@helenaedelson 
  

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

Re: [akka-user] using Akka with Kamon...

2015-05-14 Thread Albert Gorski

Hi,

I'm also new in kamon but shuold't you specify actor-system name in the 
kamon configuration?
You have :
.
actor   = [ "user/myActor*" ]


and it should be like that (see docs 
):


akka-actor {
includes = [ "my-app/user/job-manager", "my-app/user/worker-*" ]
excludes = [ "my-app/system/**", "my-app/user/worker-helper" ]}



hope it helps :)

Cheers
Albert

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

2015-05-14 Thread Jonas Adler

Thank you for the hint Martynas! I'll see if I can transfer that to my 
problem.

On Thursday, May 14, 2015 at 3:17:00 PM UTC+2, Martynas Mickevičius wrote:
>
> Hi Jonas,
>
> akka stream tcp/http works in a similar way. A bind to a socket is made 
> when Source[IncomingConnection, ...] is materialized. Then every element in 
> that source represents a client connection which can accept a Flow that 
> transforms incoming bytes to outgoing ones. So materialization is actually 
> happening more that once. First for the incoming connection source, and 
> then for every incoming connection.
>
> You can check out bindAndHandle in akka-http 
> 
>  
> code where you can see one .run() on the outer layer, and then a .run() in 
> the foreach.
>
> On Sun, May 10, 2015 at 2:30 PM, Jonas Adler  > wrote:
>
>> Hi All, 
>>
>> I have a graph consisting of 2 parts: The first part is a flow that 
>> connects to an irc network, it looks something like this: 
>> Source[IrcMessage, Unit]
>> The second part is a flow that is materialized once per client connection 
>> (websockets: Flow[Message, Message, Any]). 
>>
>> The goal is to have the Source connected to the outgoing client flow. The 
>> Problem is that I want that Source to only materialize once (one connection 
>> to the irc network, fan out to all websocket clients)
>> Basically I need to generate a Source[IrcMessage, Unit] from an already 
>> materialized Source[IrcMessage, Unit].
>>
>> Did anyone encounter a similar problem and found a solution? Every hint 
>> is welcome :)
>>
>> Thanks, 
>>
>> Jonas
>>
>>
>>
>>  -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Martynas Mickevičius
> Typesafe  – Reactive 
>  Apps on the JVM
>  

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

Re: [akka-user] [akka stream] Materialize a Source only once

2015-05-14 Thread Jonas Adler

Thank you for the hint Martynas! I'll see if I can transfer that to my 
problem.

On Thursday, May 14, 2015 at 3:17:00 PM UTC+2, Martynas Mickevičius wrote:
>
> Hi Jonas,
>
> akka stream tcp/http works in a similar way. A bind to a socket is made 
> when Source[IncomingConnection, ...] is materialized. Then every element in 
> that source represents a client connection which can accept a Flow that 
> transforms incoming bytes to outgoing ones. So materialization is actually 
> happening more that once. First for the incoming connection source, and 
> then for every incoming connection.
>
> You can check out bindAndHandle in akka-http 
> 
>  
> code where you can see one .run() on the outer layer, and then a .run() in 
> the foreach.
>
> On Sun, May 10, 2015 at 2:30 PM, Jonas Adler  > wrote:
>
>> Hi All, 
>>
>> I have a graph consisting of 2 parts: The first part is a flow that 
>> connects to an irc network, it looks something like this: 
>> Source[IrcMessage, Unit]
>> The second part is a flow that is materialized once per client connection 
>> (websockets: Flow[Message, Message, Any]). 
>>
>> The goal is to have the Source connected to the outgoing client flow. The 
>> Problem is that I want that Source to only materialize once (one connection 
>> to the irc network, fan out to all websocket clients)
>> Basically I need to generate a Source[IrcMessage, Unit] from an already 
>> materialized Source[IrcMessage, Unit].
>>
>> Did anyone encounter a similar problem and found a solution? Every hint 
>> is welcome :)
>>
>> Thanks, 
>>
>> Jonas
>>
>>
>>
>>  -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Martynas Mickevičius
> Typesafe  – Reactive 
>  Apps on the JVM
>  

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

Re: [akka-user] Re: The best ways to resolve future inside an actor?

2015-05-14 Thread Andrew Gaydenko

On Thursday, May 14, 2015 at 8:46:27 PM UTC+3, Patrik Nordwall wrote:
>
> If there are no relationship (no ordering) between the future result and 
> other incoming messages you can just use pipe, without stash.
>

Let's assume at the moment we have:

def receive = {
  case Msg(data) =>
def job = callReturningFuture(data)(context.dispatcher)
Await.result(job, 1000.millis)
}

What is the suggestion?

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

2015-05-14 Thread Patrik Nordwall

If there are no relationship (no ordering) between the future result and other 
incoming messages you can just use pipe, without stash.

/Patrik

> 14 maj 2015 kl. 19:24 skrev Viktor Klang :
> 
> Stash and pipeTo is probably the best you can do today.
> The reason for things to be as they are is because it amounts to what's 
> called a "selective receive" and it is typically a cause of poor performance 
> during runtime (since it stalls the actor).
> 
> If you have a more typical "pipeline processing" requirement you should 
> definitely look into Akka Streams, with its "mapAsync" operation—with a more 
> constrained target domain as stream processing is, it is possible to create 
> more targeted solutions.
> Does that help?
> 
>> On Thu, May 14, 2015 at 7:06 PM, Andrew Gaydenko  
>> wrote:
>>> On Thursday, May 14, 2015 at 8:04:50 PM UTC+3, √ wrote:
>>> What if it never completes?
>> 
>> Timeout is acceptable.
>> -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> >> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send 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.

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

2015-05-14 Thread Viktor Klang

Stash and pipeTo is probably the best you can do today.
The reason for things to be as they are is because it amounts to what's
called a "selective receive" and it is typically a cause of poor
performance during runtime (since it stalls the actor).

If you have a more typical "pipeline processing" requirement you should
definitely look into Akka Streams, with its "mapAsync" operation—with a
more constrained target domain as stream processing is, it is possible to
create more targeted solutions.
Does that help?

On Thu, May 14, 2015 at 7:06 PM, Andrew Gaydenko 
wrote:

> On Thursday, May 14, 2015 at 8:04:50 PM UTC+3, √ wrote:
>>
>> What if it never completes?
>>
>
> Timeout is acceptable.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

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

Re: [akka-user] Re: The best ways to resolve future inside an actor?

2015-05-14 Thread Andrew Gaydenko

On Thursday, May 14, 2015 at 8:04:50 PM UTC+3, √ wrote:
>
> What if it never completes?
>

Timeout is acceptable.

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

2015-05-14 Thread Viktor Klang

What if it never completes?

On Thu, May 14, 2015 at 7:03 PM, Andrew Gaydenko 
wrote:

> Sequence order isn't a problem. RondRobinPool(1) here isn't more rather
> just a limiting CPU consumption to a single core. As at the first message
> in the topic, the problem is to gracefully call function returning Future
> inside a message handler. We don't want answering to sender, don't want to
> serialize per se.. Just are looking for the best way to resolve a Future
> inside a receive/case message handler.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Cheers,
√

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

Re: [akka-user] Re: The best ways to resolve future inside an actor?

2015-05-14 Thread Andrew Gaydenko

Sequence order isn't a problem. RondRobinPool(1) here isn't more rather 
just a limiting CPU consumption to a single core. As at the first message 
in the topic, the problem is to gracefully call function returning Future 
inside a message handler. We don't want answering to sender, don't want to 
serialize per se.. Just are looking for the best way to resolve a Future 
inside a receive/case message handler.

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

2015-05-14 Thread Dragisa Krsmanovic

Piping does not guarantee that order will be preserved.

There are several ways to do this without waiting.

For example, you can maintain a sequence number and send current sequence
number to your long-running service to be returned when job completes.
Then you can have logic to assure that, when long-running task returns, you
apply the changes in the right order .

On Thu, May 14, 2015 at 4:06 AM, Andrew Gaydenko 
wrote:

> On Thursday, May 14, 2015 at 1:41:30 PM UTC+3, rrodseth wrote:
>>
>> Have you looked at the pipeTo pattern and the Stash trait? I'm not sure
>> why a combination of pipeTo and become() with Stash wouldn't work.
>>
>
> What is that relation between stashing and piping with resolving a future?
> Can you, please, explain in code?
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send 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] Cluster Shard Region entries stopping after starting.

2015-05-14 Thread Patrik Nordwall

They may be stopped because of cluster sharding rebalance.

How do you setup the inmem journal? It must be used together with the shared 
journal to work across cluster nodes. That is important for the shard 
coordinator, which is a persistent actor. See the cluster sharding activator 
tutorial for such setup.

/Patrik

> 14 maj 2015 kl. 14:38 skrev Martynas Mickevičius 
> :
> 
> Hi Zoe,
> 
> how quickly are they stopping? Are you sure you are not stopping actor system?
> 
>> On Fri, May 8, 2015 at 6:40 AM, Zoe Gagnon  wrote:
>> Hi, 
>> I have a set up a cluster shard region which contains entry actors similar 
>> to the Counter class used in the examples. All data is ephemeral, so there 
>> are no persist calls being made, but the actors are expected to have very 
>> long life span. However, my logging shows actors moving from start (preStart 
>> is called), to stop (postStop is called) in a relatively short amount of 
>> time. Nothing I've written is explicitly stopping the actors (no Stop, 
>> PoisonPill, or context.stop is being sent or called). Since this is for 
>> testing purposes, I am using the in-memory persistence plugin (as I said, 
>> nothing is persisted). My cluster contains several machines, and I'm 
>> currently trying to evaluate performance with a fairly large number of 
>> entries (>40 million), but as I said, they seem to be stopping shortly after 
>> starting. Any ideas what's going on, how to get more information about it, 
>> or how to fix it? Any help is appreciated.
>> 
>> Thanks,
>> Zoe Gagnon
>> -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> >> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send 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.

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

2015-05-14 Thread Rafał Krzewski

W dniu czwartek, 14 maja 2015 15:45:43 UTC+2 użytkownik Robert O'Regan 
napisał:
>
> Hi Rafał,
>
> First, thanks for the reply. If you look towards the end of my post I 
> actually tried that with AWS.
>
> Oh, sorry. I completely missed that.
 

> I suppose my main question here is should I be seeing an appreciable 
> increase in performance when using Akka clustering and add cluster nodes?
> i.e. Is the problem related to Akka clustering or is it more likely to be 
> an issue (bottleneck?) somewhere in my application?
>
> One common pitfall with Akka remoting is message serialization. Akka uses 
standard Java serialization by default which is rather slow compared to 
other alternatives available.
http://doc.akka.io/docs/akka/snapshot/scala/serialization.html has some 
suggestions near the end.

Of course there could be problems with the demo application itself, but I 
don't know enough to really advise anything here.

Cheers,
Rafał

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

2015-05-14 Thread Patrik Nordwall



> 14 maj 2015 kl. 15:23 skrev Martynas Mickevičius 
> :
> 
> Hi Jan,
> 
>> On Mon, May 11, 2015 at 1:47 PM, Jan Heise  
>> wrote:
>> Hi everybody,
>> 
>> I'm currently trying to get into akka-cluster and some questions popped up. 
>> Maybe somebody is able to help me.
>> 
>> 1. ClusterSingleton: if I leave the cluster programmatically, the singleton 
>> moves to another node. But if I crash the VM (control-c), nothing happens. 
>> Is there a solution for this scenario so that we do end up with the 
>> singleton on another node?
> 
> You might have to wait a bit for failure detector to kick in.

You must also down the crashed node so that it is removed from the cluster. 
After that a new singleton instance will be started on another node. See docs 
http://doc.akka.io/docs/akka/2.3.11/scala/cluster-usage.html#Automatic_vs__Manual_Downing

/Patrik

>  
>> 
>> 2. According to the docs, hand-over for regular actors is only possible with 
>> partitioning and routed actors? Is there a pattern that I could use for 
>> plain actors?
> 
> You could use Cluster Sharding which would rebalance actors if nodes go up or 
> down.
>  
>> 
>> 3. How about hand-over and FSM, is the state preserved?
> 
> Actors do not preserve state automatically. One can use Persistent Actors to 
> achieve that. Currently FSM and Persistent Actors can not be used together, 
> but there is an ongoing effort to enable this.
>  
>> 
>> 4. Is there a pattern one should follow to hand-over the state between 
>> actors, too?
> 
> Check out Persistent Actors.
>  
>> 
>> Thank you,
>> 
>> Jan
>> 
>> -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> >> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send 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.

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

2015-05-14 Thread Avi Levi

Thank you very much , exactly what I was looking for

2015-05-14 15:56 GMT+03:00 Martynas Mickevičius <
martynas.mickevic...@typesafe.com>:

> Hi Avi,
>
> On Sun, May 10, 2015 at 9:43 AM, Avi <123...@gmail.com> wrote:
>
>> Hi,
>> I want to implement I was looking at this example taken from typesafe
>> activator (spray-actor-per-request)
>> 
>>
>>
>> class RestRouting extends HttpService with Actor with PerRequestCreator {
>>
>> implicit def actorRefFactory: ActorContext = context
>>
>> def receive = runRoute(route)
>>
>> val petService = context.actorOf(Props[PetClient])
>> val ownerService = context.actorOf(Props[OwnerClient])
>>
>> val route = {
>>  get {
>>path("pets") {
>>   parameters('names) { names =>
>> petsWithOwner {
>>GetPetsWithOwners(names.split(',').toList)
>>  }
>>}
>>   }
>>  }
>> }
>>
>> def petsWithOwner(message : RestMessage): Route =
>> ctx => perRequest(ctx, Props(new GetPetsWithOwnersActor(petService,
>> ownerService)), message)
>> }
>>
>>
>>
>> and I wonder if this is the best parctice to implement the actors
>> creation :
>> ctx => perRequest(ctx, Props(new GetPetsWithOwnersActor(petService,
>> ownerService)), message)
>> because I saw at the akka documentation this warning
>>  regarding
>> creating actor within an actor :
>> val props2 = Props(new ActorWithArgs("arg")) // careful, see below
>>
>
> The warning is here to remind users to be careful when constructing Props.
> It is important that Props are serializable. When constructing Props
> instances inside an actor one can easily close over the surrounding actor
> instance. To avoid this, there is a recommended practice to create Props
> factory methods inside the companion object that corresponds to your actor.
>
>
>>
>>
>> also if we define an actor within an actor
>> val ownerService = context.actorOf(Props[OwnerClient])
>> how can it be tested ?
>>
>
> To make this testable you would need to either OwnerClient ActorRef or
> Props into the RestRouting class. You can find more information with
> examples on testing parent-child relationships
> 
> in the Akka documentation.
>
>
>>
>>
>> Just to make things clear - I am not criticizing, I am just trying to
>> learn the best practice of implementation specially as I see the typesafe
>> activator as educational source
>>
>>
>> Best wishes
>> Avi
>>
>>  --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send 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 a topic in the
> Google Groups "Akka User List" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/akka-user/XGzZvxP_Rak/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] Re: Performance of Akka Cluster with Spray Frontend

2015-05-14 Thread Robert O'Regan

Hi Rafał,

First, thanks for the reply. If you look towards the end of my post I 
actually tried that with AWS.
I suspected there might be an issue with using a single machine so created 
a couple of instances on AWS.
I found the similar degradation.

With my application running on one t2.small instance I got about 120 
requests per second.
I brought up another t2.small instance and the requests per second dropped 
to about 80.
I brought up a third instance and the performance increased this time to 
about 100 requests per second.

I suppose my main question here is should I be seeing an appreciable 
increase in performance when using Akka clustering and add cluster nodes?
i.e. Is the problem related to Akka clustering or is it more likely to be 
an issue (bottleneck?) somewhere in my application?

Thanks
Robert

On Wednesday, May 13, 2015 at 3:46:14 PM UTC+1, Robert O'Regan wrote:
>
> I'm building a RESTful API using Akka and Spray. I'm using the Typesafe 
> Akka Cluster Sample project...
>
> (http://www.typesafe.com/activator/template/akka-sample-cluster-scala)
>
> as a reference. I have a cluster which uses a pool of routees and cluster 
> aware routing. The interface to the API is through a spray frontend which 
> creates an actor (ClusterClient) that acts as a frontend to the cluster and 
> monitors cluster activity (new nodes, downed nodes etc...). When a request 
> comes in to a spray route I delegate the work to a Cluster backend worker 
> via the cluster aware router.
>
> My hope/goal here is that I can increase performance in the system by 
> adding more back-end worker nodes and routees as needed. I may also add 
> more frontend (spray) nodes that will be accessed via a Load Balancer. I'm 
> trying to build something performant and scalable.
>
> This all works fine. The worker actors at the moment just return a string 
> for testing.
>
> Before I go any further I wanted to get an idea of current cluster 
> performance by stress testing the application. So I am using apache bench 
> to do some quick tests.
>
> All the testing is being done on my local development machine (QuadCore 
> Macbook Pro with 16gb RAM). The application is running on spray-can. The 
> frontend (spray) and backend nodes are being kicked off on seperate JVM's 
> on the same machine by using different ports.
>
> The strange thing is performance seems to degrade when I add more backend 
> nodes to the cluster. Here are my tests and results. I ran each test about 
> 10 times to get better average...
>
> One Backend Node
>
> ab -l -n 1000 -c 100 http://localhost:3050/api
>
> Requests per second [#/sec] (mean): 4708.25, 5086.11, 4341.52, 5850.76, 
> 4403.33, 5046.78, 4151.84, 5686.24, 3399.38, 4466.26, 3755.98, 5619.18, 
> 5187.96
> Average: 4745 requests per second
>
> Two Backend Nodes
>
> ab -l -n 1000 -c 100 http://localhost:3050/api
>
> Requests per second [#/sec] (mean): 3381.75, 4108.51, 2969.41, 3732.29, 
> 3804.48, 3644.12, 2516.05, 2968.17, 3308.01, 3378.69, 4049.71, 3738.21, 
> 4068.84
> Average: 3512 requests per second
>
> Three Backend Nodes
>
> ab -l -n 1000 -c 100 http://localhost:3050/api
>
> Requests per second [#/sec] (mean): 2756.49, 2516.77, 2535.34, 2464.37, 
> 2887.51, 2421.98, 2794.03, 2633.36, 2735.74, 3021.81, 2612.39, 3052.53, 
> 3714.88
> Average: 2780 requests per second
>
> Is this expected? i.e. Am I wrong in thinking that I should be getting 
> more performance by adding more backend/worker nodes? Based on the figures 
> above, the more nodes I add to the cluster the worse the performance will 
> become. 
>
> I also ran the same tests on AWS using a couple of t2.small instances. On 
> both instances I deployed my application and  kicked off two "backend" 
> cluster nodes. I then started my frontend spray node on one of the 
> instances and used apache bench to test the cluster.
>
> Again I get about 30% less performance from the cluster when I have two 
> backend nodes compared to one. So the problem does not seem to be related 
> to running the test on a single development machine.
>
> Has anyone any ideas? Am I using Akka's clustering capabilities 
> incorrectly?
>
> 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] Clustering and hand-over

2015-05-14 Thread Martynas Mickevičius

Hi Jan,

On Mon, May 11, 2015 at 1:47 PM, Jan Heise 
wrote:

> Hi everybody,
>
> I'm currently trying to get into akka-cluster and some questions popped
> up. Maybe somebody is able to help me.
>
> 1. ClusterSingleton: if I leave the cluster programmatically, the
> singleton moves to another node. But if I crash the VM (control-c), nothing
> happens. Is there a solution for this scenario so that we do end up with
> the singleton on another node?
>

You might have to wait a bit for failure detector to kick in.


>
> 2. According to the docs, hand-over for regular actors is only possible
> with partitioning and routed actors? Is there a pattern that I could use
> for plain actors?
>

You could use Cluster Sharding
 which
would rebalance actors if nodes go up or down.


>
> 3. How about hand-over and FSM, is the state preserved?
>

Actors do not preserve state automatically. One can use Persistent Actors
to achieve that. Currently FSM and Persistent Actors can not be used
together, but there is an ongoing effort
 to enable this.


>
> 4. Is there a pattern one should follow to hand-over the state between
> actors, too?
>

Check out Persistent Actors
.


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

2015-05-14 Thread Martynas Mickevičius

Hi Jonas,

akka stream tcp/http works in a similar way. A bind to a socket is made
when Source[IncomingConnection, ...] is materialized. Then every element in
that source represents a client connection which can accept a Flow that
transforms incoming bytes to outgoing ones. So materialization is actually
happening more that once. First for the incoming connection source, and
then for every incoming connection.

You can check out bindAndHandle in akka-http

code where you can see one .run() on the outer layer, and then a .run() in
the foreach.

On Sun, May 10, 2015 at 2:30 PM, Jonas Adler  wrote:

> Hi All,
>
> I have a graph consisting of 2 parts: The first part is a flow that
> connects to an irc network, it looks something like this:
> Source[IrcMessage, Unit]
> The second part is a flow that is materialized once per client connection
> (websockets: Flow[Message, Message, Any]).
>
> The goal is to have the Source connected to the outgoing client flow. The
> Problem is that I want that Source to only materialize once (one connection
> to the irc network, fan out to all websocket clients)
> Basically I need to generate a Source[IrcMessage, Unit] from an already
> materialized Source[IrcMessage, Unit].
>
> Did anyone encounter a similar problem and found a solution? Every hint is
> welcome :)
>
> Thanks,
>
> Jonas
>
>
>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
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] How to using Akka-Http make transformation: RequestContext -> HttpEntity -> ByteStrings -> JsonString -> Deserialize -> [Domain object]

2015-05-14 Thread Rafał Krzewski

Pavel,
here's another example of using akka-http client to execute HTTP requests 
and materialize responses into domain objects:
https://github.com/rkrzewski/akka-cluster-etcd/blob/master/etcd-client/src/main/scala/pl/caltha/akka/etcd/EtcdClientImpl.scala#L106

cheers,
Rafał

W dniu czwartek, 14 maja 2015 14:25:59 UTC+2 użytkownik Martynas 
Mickevičius napisał:
>
> Hi Pavel,
>
> you are able to transform request to the domain object leveraging 
> Mashalling/Unmarshalling without any custom code.
>
> Here is an example of how to do it using spray-json: 
> https://github.com/2m/akka-stream-sandbox/blob/a07f824a1a783eb156f1c52b2b6f7319bf362761/src/test/scala/ServerRequestAsJson.scala
>
> If you want to use something other that spray-json, you can write your own 
> marshaller/unmarshaller. Here is the source code of spray-json marshaller 
> and unmarshaller: 
> https://github.com/akka/akka/blob/release-2.3-dev/akka-http-marshallers-scala/akka-http-spray-json/src/main/scala/akka/http/scaladsl/marshallers/sprayjson/SprayJsonSupport.scala
>
> On Thu, Apr 23, 2015 at 6:45 PM, pavel meledin  > wrote:
>
>> Hi everyone,
>>
>> I'm using akka-http 1.0-M5 and I want to make the following 
>> transformation:
>>
>> From *RequestContext* to *HttpEntity* then *ByteStrings* andthen 
>> *JsonString* andthen *Deserialize* andthen *[Domain object that came to 
>> server in payload]*
>>
>> The transformation path looks like: *RequestContext -> HttpEntity -> 
>> ByteStrings -> JsonString -> Deserialize -> [Domain object]*
>>
>> Here is a naive implementation of how to get complete request body as a 
>> string:
>>
>> // How to process request body
>> val collectBodySink = Sink.fold[String, String]("")(_ + _)
>>
>> // Extract request body
>> val source = ctx.request.entity.getDataBytes().map {
>>   chunk ⇒
>> chunk.decodeString(HttpCharsets.`UTF-8`.value)
>> }
>>
>> // Define the way how materialization should follow
>> val runnable = source.toMat(collectBodySink)(Keep.right)
>>
>> // Run materialization process
>> val requestBody = runnable.run()
>>
>> // Wait till materialization will be finished
>> println(Await.result(requestBody, 5.seconds))
>>
>>
>> I thought that I can describe a bunch of flows:
>>
>>- From *RequestContext* to *HttpEntity*
>>- From *HttpEntity* to *ByteStrings*
>>- From *ByteStrings* to *JsonString*
>>- etc
>>
>> and later combine them all in the following way (pseudo code):
>>
>> var domainObject = Source(ctx)
>>   .via(Flow[RequestContext].to[HttpEntity]())
>>   .via(Flow[HttpEntity].to[ByteStrings]())
>>   .via(Flow[ByteStrings].to[JsonString]())
>>   .via(Flow[JsonString].to[DomainObject]())
>>   .toMat(Sink.ignore)
>>
>>
>> Questions regarding solution of this task:
>>
>>1. Is it a correct idea to split such transformation into small 
>>pieces in order to be able to combine them later?
>>2. How such things are suppose to be handled / implemented?
>>3. RequestContext contains a Request which contains HttpEntity which 
>>contains dataBytes as a Source. In order to implement Flow from 
>> HttpEntity 
>>to ByteStrings I'll have to materialize & run inside this Flow's body 
>> some 
>>RunnableFlow. Was it designed like that? Is it ok to do it this ways? Or 
>> I 
>>have to describe all flows, then combine then in some logical stream and 
>>only then call run once in order to start all those transformations ?
>>
>> 
>>
>> Thank you in advance,
>> Appriciate any help/info regarding this topic.
>>
>> Br,
>> Pavel
>>
>>
>>
>>
>>  -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Martynas Mickevičius
> Typesafe  – Reactive 
>  Apps on the JVM
>  

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

Re: [akka-user] Is this a good way of implementing akka actor best practices

2015-05-14 Thread Martynas Mickevičius

Hi Avi,

On Sun, May 10, 2015 at 9:43 AM, Avi <123...@gmail.com> wrote:

> Hi,
> I want to implement I was looking at this example taken from typesafe
> activator (spray-actor-per-request)
> 
>
>
> class RestRouting extends HttpService with Actor with PerRequestCreator {
>
> implicit def actorRefFactory: ActorContext = context
>
> def receive = runRoute(route)
>
> val petService = context.actorOf(Props[PetClient])
> val ownerService = context.actorOf(Props[OwnerClient])
>
> val route = {
>  get {
>path("pets") {
>   parameters('names) { names =>
> petsWithOwner {
>GetPetsWithOwners(names.split(',').toList)
>  }
>}
>   }
>  }
> }
>
> def petsWithOwner(message : RestMessage): Route =
> ctx => perRequest(ctx, Props(new GetPetsWithOwnersActor(petService,
> ownerService)), message)
> }
>
>
>
> and I wonder if this is the best parctice to implement the actors creation
> :
> ctx => perRequest(ctx, Props(new GetPetsWithOwnersActor(petService,
> ownerService)), message)
> because I saw at the akka documentation this warning
>  regarding
> creating actor within an actor :
> val props2 = Props(new ActorWithArgs("arg")) // careful, see below
>

The warning is here to remind users to be careful when constructing Props.
It is important that Props are serializable. When constructing Props
instances inside an actor one can easily close over the surrounding actor
instance. To avoid this, there is a recommended practice to create Props
factory methods inside the companion object that corresponds to your actor.


>
>
> also if we define an actor within an actor
> val ownerService = context.actorOf(Props[OwnerClient])
> how can it be tested ?
>

To make this testable you would need to either OwnerClient ActorRef or
Props into the RestRouting class. You can find more information with
examples on testing parent-child relationships

in the Akka documentation.


>
>
> Just to make things clear - I am not criticizing, I am just trying to
> learn the best practice of implementation specially as I see the typesafe
> activator as educational source
>
>
> Best wishes
> Avi
>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send 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.

[akka-user] Re: Performance of Akka Cluster with Spray Frontend

2015-05-14 Thread Rafał Krzewski

W dniu środa, 13 maja 2015 16:46:14 UTC+2 użytkownik Robert O'Regan napisał:
>
> All the testing is being done on my local development machine (QuadCore 
> Macbook Pro with 16gb RAM). The application is running on spray-can. The 
> frontend (spray) and backend nodes are being kicked off on seperate JVM's 
> on the same machine by using different ports.
>
A single ActorSystem / VM will saturate all cores of a machine if you give 
it enough work to do. When you are running all VMs on the same box they are 
competing against one another for resources, moreover the the overhead 
caused both by JVM and Akka housekeeping is multiplied by the number of 
instances you run. Why don't you spin up a few nodes on Digital Ocean / AWS 
/ GCE and run your test there? It should give you much better assessment of 
Akka's scalability.

Cheers,
Rafał

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

2015-05-14 Thread Martynas Mickevičius

Hi Sylvain,

can you elaborate more on why do you need two recoveries one after another?

It is possible to disable automatic recovery by overriding preStart

method.
Also recovery can be started from arbitrary sequence number for an
arbitrary number of events. This should be enough to have a full control
over recovery.

On Fri, May 8, 2015 at 6:58 PM, Sylvain Frey  wrote:

> After digging into akka.persistence.Eventsourced: *the implementation
> allows only one recovery, when the actor is started and before any commands
> are processed.* There does not seem to be a way to return to an "awaiting
> recovery" state without fiddling with the private behaviour of a
> PersistentActor.
>
> Perhaps this feature should be documented?
>
>
> Sylvain
>
>
> On Thursday, May 7, 2015 at 7:03:28 PM UTC+1, Sylvain Frey wrote:
>>
>> Am I right supposing that a PersistentActor supports only a single
>> recovery?
>>
>> For instance, with a PersistentActor that has already persisted a number
>> of events commands, when doing:
>>
>> persistentActor ! Recover(toSequenceNr = 2L)
>> persistentActor ! Recover(toSequenceNr = 1L)
>>
>> only the first recovery ever happens - and only in case it manages to get
>> in *before* the initial automatic recovery for PersistentActors,
>> otherwise it is also discarded.
>>
>> In case this is unclear, I have a minimal test case at hand.
>>
>> The bigger picture: my goal was to implement a time travelling feature
>> where actors would be sent back in time at runtime, to arbitrary past
>> states (rewinding a simulation for instance).
>>
>> Thanks!
>>
>>
>> Sylvain
>>
>>
>>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send 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] Messages simultaneously sended to Dead Letters and to destination Actor

2015-05-14 Thread Martynas Mickevičius

Hi Antonio,

if you see the same message in deadletters and received by some actor, I
would say that there are two copies of that message being sent. Are you
sure that COORDINATOR_ACTOR does not duplicate messages and send to more
than one JOB actor?

On Fri, May 8, 2015 at 6:49 PM, Antonio Benvenuto 
wrote:

> Hi all
>
> I'm newbie with Akka Framework and I have observed a strange behavior in
> my akka test project.
> At first look all seems to work well,but activating log I noticed that
> same message were delivered to dead letters.
> It seems to be that some messages were simultaneously sended both to dead
> letters and to destination actor.
> Is this situation possible with Akka?
> Is my system correctly architectured?
>
> This is my architecture:
> 1. A TypedActor,the GATE_ACTOR,which is the bridge between normal java
> world and akka world.
> 2. An UntypedActor,the COORDINATOR_ACTOR,which receives RequestMessages
> from GATE_ACTOR and coordinate his three untyped actors childs,forwarding
> them requests and building final result.
> 3. Three UntypedActors,the
> FIRST_JOB_ACTOR,SECOND_JOB_ACTOR,THIRD_JOB_ACTOR,which receives requests
> from COORDINATOR_ACTOR and perform business logic operation.
>
> Thank you
> Antonio
>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send 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] Cluster Shard Region entries stopping after starting.

2015-05-14 Thread Martynas Mickevičius

Hi Zoe,

how quickly are they stopping? Are you sure you are not stopping actor
system?

On Fri, May 8, 2015 at 6:40 AM, Zoe Gagnon  wrote:

> Hi,
> I have a set up a cluster shard region which contains entry actors similar
> to the Counter class used in the examples. All data is ephemeral, so there
> are no persist calls being made, but the actors are expected to have very
> long life span. However, my logging shows actors moving from start
> (preStart is called), to stop (postStop is called) in a relatively short
> amount of time. Nothing I've written is explicitly stopping the actors (no
> Stop, PoisonPill, or context.stop is being sent or called). Since this is
> for testing purposes, I am using the in-memory persistence plugin (as I
> said, nothing is persisted). My cluster contains several machines, and I'm
> currently trying to evaluate performance with a fairly large number of
> entries (>40 million), but as I said, they seem to be stopping shortly
> after starting. Any ideas what's going on, how to get more information
> about it, or how to fix it? Any help is appreciated.
>
> Thanks,
> Zoe Gagnon
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send 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] Is there a way to replay journal events from beginning in a PersistentView?

2015-05-14 Thread Martynas Mickevičius

Hi Joel,

you can initiate recovery by sending Recover

message to PersistentView. Recover message has parameters which control
from what sequence number and how many events should be replayed.

Cheers,

On Thu, May 7, 2015 at 5:29 PM, Joel  wrote:

> Is there a way to control the replay sequence of the journal by a
> PersistentView, meaning schedule to replay journal from the start?
>
> The use case is to relate to the journal as a queue were a PersistentActor
> writes to one end and the PersistentView reading from the start, do some
> validation on the message, if succeeds - go on to the next one, if not -
> schedules to run through same procedure in later time.
>
> Joel
>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send 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] How to using Akka-Http make transformation: RequestContext -> HttpEntity -> ByteStrings -> JsonString -> Deserialize -> [Domain object]

2015-05-14 Thread Martynas Mickevičius

Hi Pavel,

you are able to transform request to the domain object leveraging
Mashalling/Unmarshalling without any custom code.

Here is an example of how to do it using spray-json:
https://github.com/2m/akka-stream-sandbox/blob/a07f824a1a783eb156f1c52b2b6f7319bf362761/src/test/scala/ServerRequestAsJson.scala

If you want to use something other that spray-json, you can write your own
marshaller/unmarshaller. Here is the source code of spray-json marshaller
and unmarshaller:
https://github.com/akka/akka/blob/release-2.3-dev/akka-http-marshallers-scala/akka-http-spray-json/src/main/scala/akka/http/scaladsl/marshallers/sprayjson/SprayJsonSupport.scala

On Thu, Apr 23, 2015 at 6:45 PM, pavel meledin  wrote:

> Hi everyone,
>
> I'm using akka-http 1.0-M5 and I want to make the following transformation:
>
> From *RequestContext* to *HttpEntity* then *ByteStrings* andthen
> *JsonString* andthen *Deserialize* andthen *[Domain object that came to
> server in payload]*
>
> The transformation path looks like: *RequestContext -> HttpEntity ->
> ByteStrings -> JsonString -> Deserialize -> [Domain object]*
>
> Here is a naive implementation of how to get complete request body as a
> string:
>
> // How to process request body
> val collectBodySink = Sink.fold[String, String]("")(_ + _)
>
> // Extract request body
> val source = ctx.request.entity.getDataBytes().map {
>   chunk ⇒
> chunk.decodeString(HttpCharsets.`UTF-8`.value)
> }
>
> // Define the way how materialization should follow
> val runnable = source.toMat(collectBodySink)(Keep.right)
>
> // Run materialization process
> val requestBody = runnable.run()
>
> // Wait till materialization will be finished
> println(Await.result(requestBody, 5.seconds))
>
>
> I thought that I can describe a bunch of flows:
>
>- From *RequestContext* to *HttpEntity*
>- From *HttpEntity* to *ByteStrings*
>- From *ByteStrings* to *JsonString*
>- etc
>
> and later combine them all in the following way (pseudo code):
>
> var domainObject = Source(ctx)
>   .via(Flow[RequestContext].to[HttpEntity]())
>   .via(Flow[HttpEntity].to[ByteStrings]())
>   .via(Flow[ByteStrings].to[JsonString]())
>   .via(Flow[JsonString].to[DomainObject]())
>   .toMat(Sink.ignore)
>
>
> Questions regarding solution of this task:
>
>1. Is it a correct idea to split such transformation into small pieces
>in order to be able to combine them later?
>2. How such things are suppose to be handled / implemented?
>3. RequestContext contains a Request which contains HttpEntity which
>contains dataBytes as a Source. In order to implement Flow from HttpEntity
>to ByteStrings I'll have to materialize & run inside this Flow's body some
>RunnableFlow. Was it designed like that? Is it ok to do it this ways? Or I
>have to describe all flows, then combine then in some logical stream and
>only then call run once in order to start all those transformations ?
>
>
>
> Thank you in advance,
> Appriciate any help/info regarding this topic.
>
> Br,
> Pavel
>
>
>
>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send 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] Re: The best ways to resolve future inside an actor?

2015-05-14 Thread Andrew Gaydenko

On Thursday, May 14, 2015 at 1:41:30 PM UTC+3, rrodseth wrote:
>
> Have you looked at the pipeTo pattern and the Stash trait? I'm not sure 
> why a combination of pipeTo and become() with Stash wouldn't work.
>

What is that relation between stashing and piping with resolving a future? 
Can you, please, explain in code?

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

2015-05-14 Thread Richard Rodseth

Have you looked at the pipeTo pattern and the Stash trait? I'm not sure why
a combination of pipeTo and become() with Stash wouldn't work.

On Thu, May 14, 2015 at 4:33 AM, Andrew Gaydenko 
wrote:

> It's funny just now I have met the same situation! :)
>
> More strictly, my case is even simpler as far as an actor hasn't got
> state. I also use RoundRobinPool(1) to force serialization. I have tried
> just to use Await.result(), and it seems to work . To call function
> returning Future  I use context.dispatcher as execution context.
>
> OTOH, there is a common recommendation to avoid awaiting. So, what is the
> best practice here?
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

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

2015-05-14 Thread Andrew Gaydenko

It's funny just now I have met the same situation! :) 

More strictly, my case is even simpler as far as an actor hasn't got state. 
I also use RoundRobinPool(1) to force serialization. I have tried just to 
use Await.result(), and it seems to work . To call function returning Future  
I use context.dispatcher as execution context. 

OTOH, there is a common recommendation to avoid awaiting. So, what is the 
best practice here?

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

[akka-user] Core Akka classes in akka-stream-experimental_2.11-1.0-RC2.jar

Re: [akka-user] Re: The best ways to resolve future inside an actor?

[akka-user] Akka I/O driver for SCTP ?

Re: [akka-user] Announcement: Opinionated RabbitMQ library using Akka / Reactive Streams

[akka-user] Looking for the right remoting config to tune when 'unreachable' is not an error - to stop connecting after configurable duration

Re: [akka-user] using Akka with Kamon...

Re: [akka-user] [akka stream] Materialize a Source only once

Re: [akka-user] [akka stream] Materialize a Source only once

Re: [akka-user] Re: The best ways to resolve future inside an actor?

Re: [akka-user] Re: The best ways to resolve future inside an actor?

Re: [akka-user] Re: The best ways to resolve future inside an actor?

Re: [akka-user] Re: The best ways to resolve future inside an actor?

Re: [akka-user] Re: The best ways to resolve future inside an actor?

Re: [akka-user] Re: The best ways to resolve future inside an actor?

Re: [akka-user] Re: The best ways to resolve future inside an actor?

Re: [akka-user] Cluster Shard Region entries stopping after starting.

[akka-user] Re: Performance of Akka Cluster with Spray Frontend

Re: [akka-user] Clustering and hand-over

Re: [akka-user] Is this a good way of implementing akka actor best practices

[akka-user] Re: Performance of Akka Cluster with Spray Frontend

Re: [akka-user] Clustering and hand-over

Re: [akka-user] [akka stream] Materialize a Source only once

Re: [akka-user] How to using Akka-Http make transformation: RequestContext -> HttpEntity -> ByteStrings -> JsonString -> Deserialize -> [Domain object]

Re: [akka-user] Is this a good way of implementing akka actor best practices

[akka-user] Re: Performance of Akka Cluster with Spray Frontend

Re: [akka-user] Re: Multiple recoveries on PersistentActor

Re: [akka-user] Messages simultaneously sended to Dead Letters and to destination Actor

Re: [akka-user] Cluster Shard Region entries stopping after starting.

Re: [akka-user] Is there a way to replay journal events from beginning in a PersistentView?

Re: [akka-user] How to using Akka-Http make transformation: RequestContext -> HttpEntity -> ByteStrings -> JsonString -> Deserialize -> [Domain object]

Re: [akka-user] Re: The best ways to resolve future inside an actor?

Re: [akka-user] Re: The best ways to resolve future inside an actor?

[akka-user] Re: The best ways to resolve future inside an actor?

33 matches

Site Navigation

Mail list logo

Footer information