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

[Roland Kuhn]

Hi Adam,

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

Thanks,

Roland 

Sent from my iPhone

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

Re: [akka-user] Testing per-request child creation

[Richard Rodseth]

This does rather beg the question of what the integration boundary is, and
also if the use case in question ends with an ack back to the initiating
actor, how would one test for that message (or its effect), given that it's
a TestActorRef rather than a TestProbe.



On Tue, Nov 18, 2014 at 3:08 PM, Richard Rodseth  wrote:

> Thanks for the input. I guess I can register a testprobe.ref as a
> subscriber to the event bus. I will still need to control the creation of
> the per-request child so that I can inject a mock storage interface that
> acks with success so that the posting to the event bus occurs.
>
> On Tue, Nov 18, 2014 at 2:48 PM, √iktor Ҡlang 
> wrote:
>
>> You can test that the parent passed the correct set of results to the
>> child actor by observing the results of the child actors processing.
>>
>> Usually it becomes tricky to apply Unit Testing to Actors, think
>> Integration testing instead (but at a microlevel).
>>
>> On Tue, Nov 18, 2014 at 11:43 PM, Richard Rodseth 
>> wrote:
>>
>>> The message A in the parent actor is computing a set of results. The
>>> per-request child will be saving some state from those results, and if
>>> successful, posting a domain event containing the results to an event bus
>>> and also acking back to the parent.
>>>
>>> To begin with, I just wish to test that the parent actor passed the
>>> correct set of results to the child constructor.
>>>
>>>
>>>
>>> On Tue, Nov 18, 2014 at 2:24 PM, √iktor Ҡlang 
>>> wrote:
>>>
 Hi Richard,

 what effects are you trying to test?

 On Tue, Nov 18, 2014 at 11:17 PM, Richard Rodseth 
 wrote:

> I have a parent actor which, on receipt of a certain message A, spawns
> a child actor, and sends it a "Run" message with no parameters. The child
> actor has constructor parameters derived from the contents of message A.
>
> What's the best way to test this? I don't think I can apply techniques
> like
> childMaker: ActorRefFactory => ActorRef
> because of the per-request constructor parameters.
>
>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives:
> https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google
> Groups "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send
> 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.
>>>
>>
>>
>>
>> --
>> 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: 

Re: [akka-user] Testing per-request child creation

[Richard Rodseth]

Thanks for the input. I guess I can register a testprobe.ref as a
subscriber to the event bus. I will still need to control the creation of
the per-request child so that I can inject a mock storage interface that
acks with success so that the posting to the event bus occurs.

On Tue, Nov 18, 2014 at 2:48 PM, √iktor Ҡlang 
wrote:

> You can test that the parent passed the correct set of results to the
> child actor by observing the results of the child actors processing.
>
> Usually it becomes tricky to apply Unit Testing to Actors, think
> Integration testing instead (but at a microlevel).
>
> On Tue, Nov 18, 2014 at 11:43 PM, Richard Rodseth 
> wrote:
>
>> The message A in the parent actor is computing a set of results. The
>> per-request child will be saving some state from those results, and if
>> successful, posting a domain event containing the results to an event bus
>> and also acking back to the parent.
>>
>> To begin with, I just wish to test that the parent actor passed the
>> correct set of results to the child constructor.
>>
>>
>>
>> On Tue, Nov 18, 2014 at 2:24 PM, √iktor Ҡlang 
>> wrote:
>>
>>> Hi Richard,
>>>
>>> what effects are you trying to test?
>>>
>>> On Tue, Nov 18, 2014 at 11:17 PM, Richard Rodseth 
>>> wrote:
>>>
 I have a parent actor which, on receipt of a certain message A, spawns
 a child actor, and sends it a "Run" message with no parameters. The child
 actor has constructor parameters derived from the contents of message A.

 What's the best way to test this? I don't think I can apply techniques
 like
 childMaker: ActorRefFactory => ActorRef
 because of the per-request constructor parameters.


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

Re: [akka-user] Testing per-request child creation

[√iktor Ҡlang]

You can test that the parent passed the correct set of results to the child
actor by observing the results of the child actors processing.

Usually it becomes tricky to apply Unit Testing to Actors, think
Integration testing instead (but at a microlevel).

On Tue, Nov 18, 2014 at 11:43 PM, Richard Rodseth 
wrote:

> The message A in the parent actor is computing a set of results. The
> per-request child will be saving some state from those results, and if
> successful, posting a domain event containing the results to an event bus
> and also acking back to the parent.
>
> To begin with, I just wish to test that the parent actor passed the
> correct set of results to the child constructor.
>
>
>
> On Tue, Nov 18, 2014 at 2:24 PM, √iktor Ҡlang 
> wrote:
>
>> Hi Richard,
>>
>> what effects are you trying to test?
>>
>> On Tue, Nov 18, 2014 at 11:17 PM, Richard Rodseth 
>> wrote:
>>
>>> I have a parent actor which, on receipt of a certain message A, spawns a
>>> child actor, and sends it a "Run" message with no parameters. The child
>>> actor has constructor parameters derived from the contents of message A.
>>>
>>> What's the best way to test this? I don't think I can apply techniques
>>> like
>>> childMaker: ActorRefFactory => ActorRef
>>> because of the per-request constructor parameters.
>>>
>>>
>>>  --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> 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.
>



-- 
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] Testing per-request child creation

[Richard Rodseth]

The message A in the parent actor is computing a set of results. The
per-request child will be saving some state from those results, and if
successful, posting a domain event containing the results to an event bus
and also acking back to the parent.

To begin with, I just wish to test that the parent actor passed the correct
set of results to the child constructor.



On Tue, Nov 18, 2014 at 2:24 PM, √iktor Ҡlang 
wrote:

> Hi Richard,
>
> what effects are you trying to test?
>
> On Tue, Nov 18, 2014 at 11:17 PM, Richard Rodseth 
> wrote:
>
>> I have a parent actor which, on receipt of a certain message A, spawns a
>> child actor, and sends it a "Run" message with no parameters. The child
>> actor has constructor parameters derived from the contents of message A.
>>
>> What's the best way to test this? I don't think I can apply techniques
>> like
>> childMaker: ActorRefFactory => ActorRef
>> because of the per-request constructor parameters.
>>
>>
>>  --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send 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] Testing per-request child creation

[√iktor Ҡlang]

Hi Richard,

what effects are you trying to test?

On Tue, Nov 18, 2014 at 11:17 PM, Richard Rodseth 
wrote:

> I have a parent actor which, on receipt of a certain message A, spawns a
> child actor, and sends it a "Run" message with no parameters. The child
> actor has constructor parameters derived from the contents of message A.
>
> What's the best way to test this? I don't think I can apply techniques like
> childMaker: ActorRefFactory => ActorRef
> because of the per-request constructor parameters.
>
>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send 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] Testing per-request child creation

[Richard Rodseth]

I have a parent actor which, on receipt of a certain message A, spawns a
child actor, and sends it a "Run" message with no parameters. The child
actor has constructor parameters derived from the contents of message A.

What's the best way to test this? I don't think I can apply techniques like
childMaker: ActorRefFactory => ActorRef
because of the per-request constructor parameters.

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

[Martin Jöhren]

Thanks for your feedback

Am Montag, 17. November 2014 13:14:13 UTC+1 schrieb Konrad Malawski:
>
> Hi Martin,
> This is all journal dependent - it's up to the journal implementation to 
> decide how to deal with this,
> where as the default answer should be that "don't do this". Otherwise 
> you'd have to lock and/or coordinate before every write to make sure you're 
> the one writing - this costs a lot.
>
> Summing up: 
> * don't assume journals will magically fix this,
> * use cluster sharding or cluster singleton to make sure you have one 
> persistent actor for a given key performing the writes,
> * if you do write from multiple sources to one persistence id - expect 
> things will break in recovery - yes.
>
> On Fri, Nov 14, 2014 at 9:11 PM, Olger Warnier  > wrote:
>
>> Hi Martin, 
>>
>> In my experience, the last update for a specific sequence number is kept.
>> With a replay, you'll end up with a mixed state. 
>>
>> Kind regards, 
>>
>> Olger
>>
>> On Friday, November 14, 2014 1:16:27 PM UTC+1, Martin Jöhren wrote:
>>>
>>> Hi,
>>>
>>> what would happen when two different servers somehow create a persistent 
>>> actor with the same persistence id and then storing some events? I think 
>>> the sequence number will go out of sync and of course the state of the 
>>> aggregate is also out of sync but what happens then from a runtime 
>>> perspective? Does the system continue running and will fail only next time 
>>> I recover?
>>>
>>> Any details about that appreciated.
>>>
>>> Best
>>>
>>> Martin
>>>
>>  -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Cheers,
> Konrad 'ktoso' Malawski
> hAkker @ Typesafe
>
>
> 

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

Re: [akka-user] ActorPath vs ActorSelection in AtLeastOnceDelivery

[Akka Team]

Hmm, yes I see your point and that it could be a perfectly fine use case.
Would you mind opening a ticket  so we
can have a look at it once we have some spare cycles?
Thanks in advance!

-- 
cheers,
Konrad `ktoso` Malawski

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

[Ryan Bair]

In my particular case, I have an ActorSelection that I'm trying to send to. 
If I could feed that to `deliver` directly, the code would be quite simple. 

Right now I'm getting an ActorPath from the selection by doing 
`ActorPath.fromString(actorSelection.toSerializationFormat)`, although this 
feels a little evil. The more correct approach seems to be sending an 
`Identify` message to the `actorSelection` and handling the response (or 
lack thereof). 

It would appear to be much simpler and less error prone if `deliver` 
accepted an ActorSelection rather than having to convert back and forth 
between the selection and the path.

On Tuesday, November 18, 2014 4:20:29 AM UTC-5, Akka Team wrote:
>
> Hi Ryan,
> Thanks for the feedback!
>
> API wise I do feel it’s a bit more usable by asking for a ActorPath 
> instead of a selection, since selection is when you “look for someone”,
> and you’d have to system.actorSelection(sender().path) for example. By 
> taking an ActorPath you’re able to simply write: deliver(msg.path, ...).
>
> Semantics wise you’re right that selection / paths are used because 
> ActorRef won’t do here, 
> but I’m not seeing how the use of actorSelection in the API here would be 
> beneficial.
>
> Would you be able to show an example where it makes more sense to use 
> selection than just paths for deliver()?
> ​
>
> -- 
> Cheers,
> Konrad `ktoso` Malawski
> Typesafe - The software stack for applications that scale
> Blog: letitcrash.com
> Twitter: @akkateam
>  

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

Re: [akka-user] Aeron as Akka's transport layer ?

[Konrad 'ktoso' Malawski]

It would be really nice to get an idea of the timeline. 

"When it’s done” ;-) I’m sorry, but we’re not able to commit to these features 
nor dates for them as of now. It’s something we look into and is very tempting 
to implement.
For now though we’re all focused on getting streams out the door (1.0) and 
stabilising persistence 2.4 in the beginning of 2015, can’t guarantee anything 
beyond that.


Also ideas about how it can be integrated into a current system would 
be really helpful. 

It would be a replacement of the transport layer of akka for starters. Or 
simply use some of their tricks in our code (NIO hacks).
It does a bunch of more things (it’s log) which we could use for things, but no 
plans yet.
The future will be very interesting :-)

-- 
Konrad 'ktoso' Malawski
hAkker @ typesafe
http://akka.io

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

Re: [akka-user] Aeron as Akka's transport layer ?

[Soumya Simanta]

Konrad, That's very reassuring to hear. If the claims made by Aeron are 
true it can be a game changer. 
Imagine an super faster transport layer, combined with an efficient 
serialization format can make Akka even more compelling :-) 

It would be really nice to get an idea of the timeline. 

Also ideas about how it can be integrated into a current system would be 
really helpful. 

Thanks again ! 

-Soumya




On Tuesday, November 18, 2014 5:34:40 AM UTC-5, Akka Team wrote:
>
> Definitely, it would be a great transport layer!
> No worries, we are looking at it very closely – now the only remaining 
> question is timelines... ;-)
>
> -- 
> Konrad `ktoso` Malawski
> Akka Team
> Typesafe - The software stack for applications that scale
> Blog: letitcrash.com
> Twitter: @akkateam
>  

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

[akka-user] Re: [akka-streams] Dynamically add route output port

[Oscar Broman]

Some messages belong in more than one sub-stream - how would I accomplish 
that using groupBy?

On Sunday, November 16, 2014 1:42:48 AM UTC+1, Oscar Broman wrote:
>
> Hello!
>
> I've been messing around with akka-streams lately and ran into some 
> problems. I'm not sure where to go from this point.
>
> I have a TCP connection to an external data feed, in which I can subscribe 
> to a wide variety of real-time data. What exactly will be subscribed to 
> changes during runtime.
>
> Messages from the external feed can land in one or many actors, and these 
> actors have varying lifespans. Where the messages end up depend on their 
> type and different types of information inside them.
>
> How would I do this? From what I gather, using a FlexiRoute means I cannot 
> add output ports after it has been materialized.
>
> At one point the stream could look like this:
>
>  tcp io
>|
>   transform(chop at LF)
>|
> map(_.utf8String)
>|
>   map(FeedMessageParser(_)) // data is now Option(FeedMessage)
>|
>filter(_ != None)
>|
>   /|\
>  / | \
> /  |  \
>/   |   \
>   /|\
>  / | \
> /  |  \
>  TYPE=1  ID=3   TYPE=4,ID=4 // different prerequisites decide where the 
> data flows next
>|   |  / \
>|   | /   \
>|   | |   |
>|   | |   |
>|   | |   |
>   sub1 | |   |
>  sub2|   |
>sub3 sub4
>
>
> How do I do this best? Should I take a step back and look over my options, 
> or is there a way to tame the river?
>

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

[Danny Browning]

That's what we're doing in the interim, just wanted to make sure we weren't
missing something. Thanks for the work on streams!

On Tue, Nov 18, 2014 at 8:50 AM, Konrad Malawski  wrote:

> For now you'll have to push it to an Actor{Subscriber / Publisher}
> boundary and take it from there into remoting.
> We're also very much looking forward to streams in clusters, but for now
> the local ones are loads of work and fun already :-)
>
> On Mon, Nov 17, 2014 at 4:17 PM, Danny Browning <
> danny.brown...@protectwise.com> wrote:
>
>> The main use case would be a flexiroute or groupBy with an elastic
>> cluster. Since remoting/clustering is down the road, was just looking for a
>> possible way to use streams with remoting/clustering, other than
>> ActorPublisher/ActorSubscriber.
>>
>> On Mon, Nov 17, 2014 at 5:05 AM, Konrad Malawski 
>> wrote:
>>
>>> Hi Danny,
>>> What you describe sounds more like an "stream of streams" scenario (like
>>> our groupBy
>>> 
>>>  for
>>> example) - using it you can create substreams based on some key and then
>>> produce to that substream.
>>> In FlexiRoute / FlexiMerge it's not supported to change the number of
>>> endpoints - it's a static junction currently.
>>>
>>> If you could come up on a few use case descriptions and maybe formulate
>>> them as an issue  we can take a
>>> look at it during our planing and decide if it's something fundamental
>>> enough to include as building block or if it's something that should be
>>> described as a
>>> cookbook recipe as "how to build these kinds of junctions if you need
>>> one". We definitely do appreciate your feedback, thanks a lot in advance!
>>>
>>>
>>>
>>> On Thu, Nov 13, 2014 at 4:04 PM,  wrote:
>>>
 Are there plans to add routers to streams? FlexiRoute accomplishes some
 of that behavior, but I'm not seeing how to safely dynamically add/remove
 OutputHandles. Also not sure of how one would accomplish consistent
 hashing, where we're looking to split up a stream to specific processors
 for the purpose of state maintenance. Wasn't sure how to create a state
 where you wait till an element is ready, then wait for demand for the
 output that the element hashes to. Alternatively, buffer elements/outputs
 until an element hashes to an output with demand.

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

>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Konrad 'ktoso' Malawski
>>> hAkker @ Typesafe
>>>
>>>
>>>  --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "Akka User List" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/akka-user/HyvIUMaIBbQ/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.
>>
>
>
>
> --
> Cheers,
> Konrad 'ktoso' Malawski
> hAkker @ Typesafe
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received

[akka-user] Recording of Dr. Roland Kuhn's webinar of Akka Roadmap Update?

[Chanan Braunstein]

Hello,

Unfortunately, I was not able to attend yesterday's Webinar. Was the event 
recorded? If so, can someone post the link please?

Thanks,
Chanan

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

[Konrad Malawski]

For now you'll have to push it to an Actor{Subscriber / Publisher} boundary
and take it from there into remoting.
We're also very much looking forward to streams in clusters, but for now
the local ones are loads of work and fun already :-)

On Mon, Nov 17, 2014 at 4:17 PM, Danny Browning <
danny.brown...@protectwise.com> wrote:

> The main use case would be a flexiroute or groupBy with an elastic
> cluster. Since remoting/clustering is down the road, was just looking for a
> possible way to use streams with remoting/clustering, other than
> ActorPublisher/ActorSubscriber.
>
> On Mon, Nov 17, 2014 at 5:05 AM, Konrad Malawski 
> wrote:
>
>> Hi Danny,
>> What you describe sounds more like an "stream of streams" scenario (like
>> our groupBy
>> 
>>  for
>> example) - using it you can create substreams based on some key and then
>> produce to that substream.
>> In FlexiRoute / FlexiMerge it's not supported to change the number of
>> endpoints - it's a static junction currently.
>>
>> If you could come up on a few use case descriptions and maybe formulate
>> them as an issue  we can take a
>> look at it during our planing and decide if it's something fundamental
>> enough to include as building block or if it's something that should be
>> described as a
>> cookbook recipe as "how to build these kinds of junctions if you need
>> one". We definitely do appreciate your feedback, thanks a lot in advance!
>>
>>
>>
>> On Thu, Nov 13, 2014 at 4:04 PM,  wrote:
>>
>>> Are there plans to add routers to streams? FlexiRoute accomplishes some
>>> of that behavior, but I'm not seeing how to safely dynamically add/remove
>>> OutputHandles. Also not sure of how one would accomplish consistent
>>> hashing, where we're looking to split up a stream to specific processors
>>> for the purpose of state maintenance. Wasn't sure how to create a state
>>> where you wait till an element is ready, then wait for demand for the
>>> output that the element hashes to. Alternatively, buffer elements/outputs
>>> until an element hashes to an output with demand.
>>>
>>> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+unsubscr...@googlegroups.com.
>>> To post to this group, send email to akka-user@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Cheers,
>> Konrad 'ktoso' Malawski
>> hAkker @ Typesafe
>>
>>
>>  --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Akka User List" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/akka-user/HyvIUMaIBbQ/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.
>



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

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

Re: [akka-user] [akka-streams] Dynamically add route output port

[Akka Team]

Sounds to me like you could get away with using groupBy

- where you assemble the group key based on your criteria.
Elements with the same criteria end up in the same "sub-stream".

Have you tried playing around with this idea by adding a groupBy after the
filter step?

On Sun, Nov 16, 2014 at 1:42 AM, Oscar Broman 
wrote:

> Hello!
>
> I've been messing around with akka-streams lately and ran into some
> problems. I'm not sure where to go from this point.
>
> I have a TCP connection to an external data feed, in which I can subscribe
> to a wide variety of real-time data. What exactly will be subscribed to
> changes during runtime.
>
> Messages from the external feed can land in one or many actors, and these
> actors have varying lifespans. Where the messages end up depend on their
> type and different types of information inside them.
>
> How would I do this? From what I gather, using a FlexiRoute means I cannot
> add output ports after it has been materialized.
>
> At one point the stream could look like this:
>
>  tcp io
>|
>   transform(chop at LF)
>|
> map(_.utf8String)
>|
>   map(FeedMessageParser(_)) // data is now Option(FeedMessage)
>|
>filter(_ != None)
>|
>   /|\
>  / | \
> /  |  \
>/   |   \
>   /|\
>  / | \
> /  |  \
>  TYPE=1  ID=3   TYPE=4,ID=4 // different prerequisites decide where the
> data flows next
>|   |  / \
>|   | /   \
>|   | |   |
>|   | |   |
>|   | |   |
>   sub1 | |   |
>  sub2|   |
>sub3 sub4
>
>
> How do I do this best? Should I take a step back and look over my options,
> or is there a way to tame the river?
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send 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 Team
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
Twitter: @akkateam

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

Re: [akka-user] Re: [akka-streams] ActorPublisher-based Source

[Boris Lopukhov]

No, the actor system is alive. Additionally, i have repeated that code many 
times with the same result:

for (i <-  1 to 10) {
  Source(list).mapConcat(x => x).runWith(ForeachSink(println))
}



вторник, 18 ноября 2014 г., 16:29:08 UTC+4 пользователь Patrik Nordwall 
написал:
>
> Do you shutdown the actor system prematurely?
> /Patrik
>
> On Tue, Nov 18, 2014 at 1:24 PM, Boris Lopukhov <89b...@gmail.com 
> > wrote:
>
>> I have isolated the problem, it seems that ActorPublisher is not the 
>> cause:
>>
>>   val list = List.range(1, 21).grouped(5).toList
>>   Source(list).mapConcat(x => x).runWith(ForeachSink(println))
>>
>> expectation:  1..20
>> reality: 1..16
>>
>>
>> понедельник, 17 ноября 2014 г., 19:46:58 UTC+4 пользователь Boris 
>> Lopukhov написал:
>>
>>> Hi everyone!
>>>
>>> I am trying to create a stream with an ActorPublisher:
>>>
>>> class SourceActor extends ActorPublisher[List[Int]] {
>>>   import akka.stream.actor.ActorPublisherMessage.Request
>>>
>>>   var list = List.range(1, 21).grouped(5).toList // for example
>>>
>>>   def receive = {
>>> case Request(elems) => while (totalDemand > 0 && isActive) {
>>>   list match {
>>> case Nil =>
>>>   onComplete()
>>>   self ! PoisonPill
>>> case head :: tail =>
>>>   list = tail
>>>   onNext(head)
>>>   }
>>> }
>>>   }
>>> }
>>>
>>> val sourceActor = system.actorOf(Props[SourceActor])
>>> val source = Source(ActorPublisher[List[Int]](sourceActor))
>>> val out = ForeachSink(println)
>>> source.mapConcat{x => x}.runWith(out)
>>>
>>> I expect to see numbers from 1 to 20, but random printed from 1 to 17~19
>>> As I understand, it occur due to the stream complete before all elements 
>>> are processed. How can I implement an ActorPublisher properly and escape 
>>> this problem?
>>>
>>>  -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> Patrik Nordwall
> Typesafe  -  Reactive apps on the JVM
> Twitter: @patriknw
>
> 

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

Re: [akka-user] UnboundedControlAwareMailbox and ControlMessage

[Eyal Hayun]

Opps, Didn't noticed it was a snapshot of 2.4.

Thanks,



On Tuesday, November 18, 2014 2:29:31 PM UTC+2, Konrad Malawski wrote:
>
> Hey there,
> These are not the docs you're looking for :-)
>
> Your docs link: http://doc.akka.io/docs/akka/*snapshot*
> /java/mailboxes.html#ControlAwareMailbox 
> 
> The versions you're checking: 2.3.2, *2.3.7*
>
> The docs link you should be checking: http://doc.akka.io/docs/akka/*2.3.7*
> /java/mailboxes.html 
> 
>
> This feature is not available in akka 2.3.x, only 2.4 as you can see;
> It was implemented as of this PR https://github.com/akka/akka/pull/2050
> I'm not sure if we can/want to back port it to 2.3 at this point.
>
>
> On Tue, Nov 18, 2014 at 9:19 AM, Eyal Hayun  > wrote:
>
>> Hi,
>>
>> I'm trying to use the UnboundedControlAwareMailbox mailbox from 
>> http://doc.akka.io/docs/akka/snapshot/java/mailboxes.html#ControlAwareMailbox
>>  example 
>> to send ControlMessage  some ators.
>> I can't seem to find akka.dispatch.ControlMessage class under any jar in 
>> Akka 2.3.2 or 2.3.7 
>>
>> Am I'm missing something? 
>>
>> Thanks,
>> Eyal
>>
>>
>>
>>
>>  -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Cheers,
> Konrad 'ktoso' Malawski
> hAkker @ Typesafe
>  

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

Re: [akka-user] routing and load balancing with AKKA instead of regular NLB

[Tzvika Velich]

Hi Konrad,
Thanks.
I know all of Akka's concept (reading the documentation and articles) and I 
understand it is a little funny Q.
On top of that - of course we will continue to POC.
As I mentioned we are confident with Akka and using it's advantages BUT 
since we are new to Akka, we had some debate and one argument was "let NLB 
do what it knows and let the application do it's part".
Because that we understand (think :)) that Akka should be capable on 
delivering the inter load balancing - we just wanted to get 
some strengthening from the Experts and Experienced before/while continuing 
to the POC.

So if I may, let me be clearer - let say my "instance" consisted of: 4 
physical servers (each with 12 cores & 128 GB memory), total 14 VM 
machines. 
And let say that the OLTP modules and API zone take half of this horse 
power (other half go to UI, application and DB) 
Do you know of any successive implementation of Akka's routing & load 
balancing with numbers close to my above requirements? 

Tzvika



On Tuesday, November 18, 2014 12:43:13 PM UTC+2, Konrad Malawski wrote:
>
> Hi Tzivka,
> The questions you're asking seem very general and maybe not on-spot as 
> Akka is not just a router/load-balancer thingy.
> It's much more - a way to build ditributed peer to peer communicating 
> applications. We do have routers and other tools like this,
> but it seems to me that you're trying to compare Akka to a "normal router" 
> or "normal load balancer", that you slap before your servers
> and be done with it (like Amazon's ELB) – this is not what Akka is.
>
> For example – sticky sessions is a concept that you can of course build 
> using Actors etc, but it's not something Akka's core has any interest in,
> we're much more low level than this.
>
> If you'd be interested in having a more hand-holding during your 
> proof-of-concept phase of your app for example,
> we do offer commercial support  and 
> could help you out in a more involved way then.
>
> -- 
> Cheers,
> Konrad 'ktoso' Malawski
> hAkker @ Typesafe
>
>
> 

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

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

[Sergii Vozniuk]

Hello,

I'm using Akka 2.3.4 running on Java 1.7.0_72 in Ubuntu 14.04

I'm reproducibly falling into the situation when a remote system is 
quarantined and for each unsucessful attempt to connect to that remote 
system a new socket is allocated but never disposed. Eventually this leads 
to reaching the operating system limits on the number of open sockets (and 
files --> Too many open files in the system).

Our setup is the following:
There is one "hub" actor system (commLayer below) which is listening on 
default akka port 2552
There are three client actor systems which connect to 2552. They are 
configured to automatically find an empty port (akka.remote.netty.tcp.port 
= 0)

To fall into the described situation I do the following.
1. Start the system normally. All actor systems are started and operating 
the way they should
2. Suspend all thread of the system (I do it by putting the breakpoint 
which is configured to suspend all threads)
3. Wait for some period of time (e.g. 30 sec)
4. Remove the breakpoint and continue all the threads

Immediately after this I get similar logs for all three client systems.

2014-11-17 13:45:30,765 [commClient-akka.actor.default-dispatcher-15] WARN  
Remoting : Tried to associate with unreachable remote address 
[akka.tcp://commLayer@localhost:2552]. Address is now gated for 15000 ms, 
all messages to this address will be delivered to dead letters. Reason: The 
remote system has a UID that has been quarantined. Association aborted.
...
2014-11-17 13:45:50,769 [commClient-akka.actor.default-dispatcher-20] WARN  
Remoting : Tried to associate with unreachable remote address 
[akka.tcp://commLayer@localhost:2552]. Address is now gated for 15000 ms, 
all messages to this address will be delivered to dead letters. Reason: The 
remote system has quarantined this system. No further associations to the 
remote system are possible until this system is restarted.


So the hub system has quarantined the clients and the clients have 
quarantined the hub.
In current implementation in our system when the hub becomes unreachable 
the clients will try to reconnect to it with a certain rate (every 10 
seconds). It usually succeeds but of course it's pointless in case of 
quarantined systems and we have yet to handle this scenario. However what 
is strange is that  when the reconnection fails with the messages mentioned 
above a new socket is opened and netstat returns an ESTABLISHED state for 
each of them.

Periodic checks on netstat show that every 10-15 seconds 3 new sockets are 
opened to connect to 2552 and they are never closed reaching eventually the 
OS limit. It looks like a resource leak to me.
Is this kind of behavior expected for the quarantined systems?

Additional information: Initially we detected the issue on a dev Mac 
machine. If our system was left running and Mac went to sleep mode - after 
waking up the described behavior was observed. 

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

[Konrad Malawski]

Hey there,
These are not the docs you're looking for :-)

Your docs link: http://doc.akka.io/docs/akka/*snapshot*
/java/mailboxes.html#ControlAwareMailbox

The versions you're checking: 2.3.2, *2.3.7*

The docs link you should be checking: http://doc.akka.io/docs/akka/*2.3.7*
/java/mailboxes.html


This feature is not available in akka 2.3.x, only 2.4 as you can see;
It was implemented as of this PR https://github.com/akka/akka/pull/2050
I'm not sure if we can/want to back port it to 2.3 at this point.


On Tue, Nov 18, 2014 at 9:19 AM, Eyal Hayun  wrote:

> Hi,
>
> I'm trying to use the UnboundedControlAwareMailbox mailbox from
> http://doc.akka.io/docs/akka/snapshot/java/mailboxes.html#ControlAwareMailbox 
> example
> to send ControlMessage  some ators.
> I can't seem to find akka.dispatch.ControlMessage class under any jar in
> Akka 2.3.2 or 2.3.7
>
> Am I'm missing something?
>
> Thanks,
> Eyal
>
>
>
>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



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

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

Re: [akka-user] Re: [akka-streams] ActorPublisher-based Source

[Patrik Nordwall]

Do you shutdown the actor system prematurely?
/Patrik

On Tue, Nov 18, 2014 at 1:24 PM, Boris Lopukhov <89bo...@gmail.com> wrote:

> I have isolated the problem, it seems that ActorPublisher is not the cause:
>
>   val list = List.range(1, 21).grouped(5).toList
>   Source(list).mapConcat(x => x).runWith(ForeachSink(println))
>
> expectation:  1..20
> reality: 1..16
>
>
> понедельник, 17 ноября 2014 г., 19:46:58 UTC+4 пользователь Boris Lopukhov
> написал:
>
>> Hi everyone!
>>
>> I am trying to create a stream with an ActorPublisher:
>>
>> class SourceActor extends ActorPublisher[List[Int]] {
>>   import akka.stream.actor.ActorPublisherMessage.Request
>>
>>   var list = List.range(1, 21).grouped(5).toList // for example
>>
>>   def receive = {
>> case Request(elems) => while (totalDemand > 0 && isActive) {
>>   list match {
>> case Nil =>
>>   onComplete()
>>   self ! PoisonPill
>> case head :: tail =>
>>   list = tail
>>   onNext(head)
>>   }
>> }
>>   }
>> }
>>
>> val sourceActor = system.actorOf(Props[SourceActor])
>> val source = Source(ActorPublisher[List[Int]](sourceActor))
>> val out = ForeachSink(println)
>> source.mapConcat{x => x}.runWith(out)
>>
>> I expect to see numbers from 1 to 20, but random printed from 1 to 17~19
>> As I understand, it occur due to the stream complete before all elements
>> are processed. How can I implement an ActorPublisher properly and escape
>> this problem?
>>
>>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



-- 

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

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

[akka-user] Re: [akka-streams] ActorPublisher-based Source

[Boris Lopukhov]

 

I have isolated the problem, it seems that ActorPublisher is not the cause:

  val list = List.range(1, 21).grouped(5).toList
  Source(list).mapConcat(x => x).runWith(ForeachSink(println))

expectation:  1..20
reality: 1..16


понедельник, 17 ноября 2014 г., 19:46:58 UTC+4 пользователь Boris Lopukhov 
написал:
>
> Hi everyone!
>
> I am trying to create a stream with an ActorPublisher:
>
> class SourceActor extends ActorPublisher[List[Int]] {
>   import akka.stream.actor.ActorPublisherMessage.Request
>
>   var list = List.range(1, 21).grouped(5).toList // for example
>
>   def receive = {
> case Request(elems) => while (totalDemand > 0 && isActive) {
>   list match {
> case Nil =>
>   onComplete()
>   self ! PoisonPill
> case head :: tail =>
>   list = tail
>   onNext(head)
>   }
> }
>   }
> }
>
> val sourceActor = system.actorOf(Props[SourceActor])
> val source = Source(ActorPublisher[List[Int]](sourceActor))
> val out = ForeachSink(println)
> source.mapConcat{x => x}.runWith(out)
>
> I expect to see numbers from 1 to 20, but random printed from 1 to 17~19
> As I understand, it occur due to the stream complete before all elements 
> are processed. How can I implement an ActorPublisher properly and escape 
> this problem?
>
>

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

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

[Adam Warski]

Hey,

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

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

By the way - isn't dropping demand messages a problem also in the current 
remote-streams implementation?
 

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

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

If the sharded actors are aggregate roots, for example, then lazy loading 
makes perfect sense. But if these are workers, of which there are a couple 
per host, then this wouldn't be a problem. Just depends on the type of work 
they are supposed to do.
 

> I'd also like to make sure what you mean by "reactive" when you use it in 
> this proposal – I assume you mean the *reactive*-streams "reactive", as 
> in "abides to the reactive streams protocol", and akka-streams of course 
> drive those using messaging (in most cases).
>

Yes, reactive streams, mental shortcut :)
 

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

Great to hear :)
 

> We're not there yet, but we definitely will cross that bridge when we get 
> there :-)
>
> Let's move on to the Router example;
> Well, this is pretty much what we deal with nowadays with elements like 
> Broadcast 
> 
>  
> / Balance 
> 
>  and *FlexiRoute* 
> 
> .
> Especially FlexiRoute should be of interest for you (in this example).
>

I'm wondering how many more functionalities are there in the code 
undiscovered ;) But that will change when the docs are there I guess :)
 

> As for the last proposal... I think it's either missing some details, or 
> is wishful thinking.
> How would you without a central entity be able to guarantee that you're 
> properly balancing values among all the B side actors?
> If you can just peer to peer between then you could simply just use 
> point-to-point streams, and if that's not doable, there will be some form 
> of router anyway doing the routing between A and B actors.
>

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

Going this route, there could be a cluster-singleton service which assigns 
B-actors to A-actors, and creates streams between those two. These coul

Re: [akka-user] IllegalStateException in akka.dispatch.BatchingExecutor$Batch.run

[Konrad Malawski]

Thanks a lot for creating the issue Maxim!
Let us know if you'd be able to find any more details that would help us
find the root cause of the issue.

Thanks in advance

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

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

Re: [akka-user] IllegalStateException in akka.dispatch.BatchingExecutor$Batch.run

[Maxim Valyanskiy]

Hello!

I created new issue https://github.com/akka/akka/issues/16327. I'm going to 
reproduce this problem later with logging settings that was suggested by 
Viktor and also update Akka to 2.3.7.

Maxim

понедельник, 17 ноября 2014 г., 20:18:07 UTC+3 пользователь Konrad Malawski 
написал:
>
> Thanks for the description Maxim, would you mind opening an issue on our 
> issue tracker  using the data you've 
> collected so far (the stacktrace and your descrition here)?
> Sounds like there may be something on our side we should look deeper into.
>
> Thanks in advance!
>
> On Mon, Nov 17, 2014 at 3:25 PM, Maxim Valyanskiy  > wrote:
>
>> Hello!
>>
>> Our application provides REST interface to database storage. User uploads 
>> data via HTTP interface, we store it to JDBC and then do some additional 
>> logic that processes uploaded data. HTTP interface is implemented via Spray 
>> 1.3.2; Akka version 2.3.6 (but I have seen this problem in previous 2.3.x). 
>> We do not use akka-streams.
>>
>> We create and then stop an some number of actors per upload; also we use 
>> transformation operations on Future in context dispatcher.
>>
>> We see this exception when client continuously uploads large number of 
>> objects (about a million). I do not know the way to reproduce this bug 
>> (other that posting a lot of data and waiting before the problem occurs).
>>
>> Maxim
>>
>> понедельник, 17 ноября 2014 г., 17:04:30 UTC+3 пользователь Konrad 
>> Malawski написал:
>>
>>> Hi Maxim,
>>> We fixed a very similar bug in akka-streams 0.11, but it does not seem 
>>> that’s the exact place that your stacktrace is coming from…
>>> Here’s the issue we fixed in 0.11 => https://github.com/akka/
>>> akka/issues/16263
>>>
>>> Would you mind giving more background on what you’ve been using and when 
>>> this appeared?
>>> Are you using akka streams?
>>> Which version of akka etc are you using?
>>>
>>> Thanks for the additional info, let’s try looking into it.
>>>
>>> -- 
>>> Konrad 'ktoso' Malawski
>>> hAkker @ typesafe
>>> http://akka.io
>>>
>>  -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Cheers,
> Konrad 'ktoso' Malawski
> hAkker @ Typesafe
>
>
> 

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

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

[Konrad Malawski]

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

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

I'd also like to make sure what you mean by "reactive" when you use it in
this proposal – I assume you mean the *reactive*-streams "reactive", as in
"abides to the reactive streams protocol", and akka-streams of course drive
those using messaging (in most cases).
If so, then yes – we do plan to support reactive-streams over the network,
in our case those will be actor's and messages of course, and yes, we'll
need to implement a reliable redelivery transport for those messages.
We're not there yet, but we definitely will cross that bridge when we get
there :-)

Let's move on to the Router example;
Well, this is pretty much what we deal with nowadays with elements like
Broadcast

/ Balance

 and *FlexiRoute*

.
Especially FlexiRoute should be of interest for you (in this example).

As for the last proposal... I think it's either missing some details, or is
wishful thinking.
How would you without a central entity be able to guarantee that you're
properly balancing values among all the B side actors?
If you can just peer to peer between then you could simply just use
point-to-point streams, and if that's not doable, there will be some form
of router anyway doing the routing between A and B actors.

Hope this helps to clarify some of the differences.

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

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

Re: [akka-user] routing and load balancing with AKKA instead of regular NLB

[Konrad Malawski]

Hi Tzivka,
The questions you're asking seem very general and maybe not on-spot as Akka
is not just a router/load-balancer thingy.
It's much more - a way to build ditributed peer to peer communicating
applications. We do have routers and other tools like this,
but it seems to me that you're trying to compare Akka to a "normal router"
or "normal load balancer", that you slap before your servers
and be done with it (like Amazon's ELB) – this is not what Akka is.

For example – sticky sessions is a concept that you can of course build
using Actors etc, but it's not something Akka's core has any interest in,
we're much more low level than this.

If you'd be interested in having a more hand-holding during your
proof-of-concept phase of your app for example,
we do offer commercial support  and
could help you out in a more involved way then.

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

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

Re: [akka-user] Aeron as Akka's transport layer ?

[Akka Team]

Definitely, it would be a great transport layer!
No worries, we are looking at it very closely – now the only remaining
question is timelines... ;-)

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

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

Re: [akka-user] Re: How to Monitor akka, improving performance

[Akka Team]

Hi Gaurav,
the multiple threads show up because Akka is using thread pools (multiple
threads) for running Actors - which is why you’ll see
systemName-dispatcher-...-N threads.

It’s tough to say what exactly might be causing the threads to wait without
more details on the interactions - are you sure you don’t block somewhere?
Hints given by Soumya are good ones - check your GC if it’s going haywire
or not, if yes, then investigate why (which objects) etc.

Hope this helps, report back if you find more info though!


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

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

Re: [akka-user] ActorPath vs ActorSelection in AtLeastOnceDelivery

[Akka Team]

Hi Ryan,
Thanks for the feedback!

API wise I do feel it’s a bit more usable by asking for a ActorPath instead
of a selection, since selection is when you “look for someone”,
and you’d have to system.actorSelection(sender().path) for example. By
taking an ActorPath you’re able to simply write: deliver(msg.path, ...).

Semantics wise you’re right that selection / paths are used because
ActorRef won’t do here,
but I’m not seeing how the use of actorSelection in the API here would be
beneficial.

Would you be able to show an example where it makes more sense to use
selection than just paths for deliver()?
​

-- 
Cheers,
Konrad `ktoso` Malawski
Typesafe - The software stack for applications that scale
Blog: letitcrash.com
Twitter: @akkateam

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

Re: [akka-user] Accessing Future's onComplete Internal variables

[Derek Williams]

Why not call the method from within the map function? Instead of trying to
get the result out of the Future, you can move more processing into the
Future.

On Mon Nov 17 2014 at 12:51:34 PM Syd Gillani 
wrote:

> Alright, but I would like to send the result to an API ( a method in an
> external class). Is there any way for it. Cheers
>
>
> Syd
>
>
> On Monday, 17 November 2014 12:35:42 UTC+1, Konrad Malawski wrote:
>
>> Have you looked into our pipeTo pattern? It allows to send the result of
>> a Future to an Actor, without having to block on the result:
>>
>> import static akka.pattern.Patterns.pipe;
>>
>>
>> final ActorRef alice = ???;
>> final Future future = ???;
>> pipe(future, ec).to(alice);
>>
>>
>> Alice can receive the value and do things with it.
>> More info in the docs: http://doc.akka.io/docs/akka/2.3.7/java/untyped-
>> actors.html#Ask__Send-And-Receive-Future
>>
>> -- k
>>
>
>>
>> On Mon, Nov 17, 2014 at 12:22 PM, Syd Gillani 
>> wrote:
>>
>>> Thanks Konrad,
>>> The issue with the mapping is that I won't be able to send the results
>>> to an external class -- that is exactly my case. I need to send the result
>>> of the future to an external class which will perform some other
>>> computation and so.
>>> I knew about the await method, but as It is described in the
>>> documentation (not a preferred approach  ), so I was hesitant to use it.
>>> Cheers
>>>
>>> Syd
>>>
>>>
>>>
>>>
>>> On Monday, 17 November 2014 12:10:16 UTC+1, Konrad Malawski wrote:

 Hi Syd,
 your code samples are not valid Java (well, the first one could be if
 testVar would be a field, but that's unsafe instead maybe use
 `AtomicReference` and `set` it from the completion?).
 OnComplete has a `void` method so you cannot return from it.

 Instead of taking things out of the future like this you can either:
 1) keep mapping (transfroming the value):

 future.map(new Function1(){
   @Override public Object apply(Object v1) {
 return null;
   }
 }, ec);

 never getting out of this transformation - this way you can chain all
 transformations you need.

 2) Await on the result of the future (*we discourage this*) as it will
 block the thread that you're calling await from:

 Future future = null;
 Object o = scala.concurrent.Await.result(future, Duration.apply(100, 
 TimeUnit.DAYS))


 Hope this helps, happy hakkionmg!

 On Mon, Nov 17, 2014 at 11:36 AM, Syd Gillani 
 wrote:

> Hi,
>
> I wanted to ask if there is any way to map the internal variables to
> the external java ones. For instance, for the following method
>
> String testVar=null;
>
>
> future.onComplete(new OnComplete(){
> public void onComplete(Throwable t, Object result){
>
>  testVar=(String) result;
>
> }
> }, ec);
>
>
> I have tried the following method to get the results by calling
> onSuccess
>
> future.onComplete(new OnComplete(){
> public void onComplete(Throwable t, Object result){
>
>return result;
>
> }
> }, ec);
>
>
> future.onSuccess(new Result(), ec);
>
>
> However I am kept on getting the error (cannot cast the Result class
> to a partial function ).  Cheers
>
>
>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/c
> urrent/additional/faq.html
> >> Search the archives: https://groups.google.com/grou
> p/akka-user
> ---
> You received this message because you are subscribed to the Google
> Groups "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to akka-user+...@googlegroups.com.
> To post to this group, send email to akka...@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



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


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

[akka-user] UnboundedControlAwareMailbox and ControlMessage

[Eyal Hayun]

Hi,

I'm trying to use the UnboundedControlAwareMailbox mailbox from 
http://doc.akka.io/docs/akka/snapshot/java/mailboxes.html#ControlAwareMailbox 
example 
to send ControlMessage  some ators.
I can't seem to find akka.dispatch.ControlMessage class under any jar in 
Akka 2.3.2 or 2.3.7 

Am I'm missing something? 

Thanks,
Eyal




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