Re: [akka-user] Akka stream out of band data

[Christopher Hunt]

Hey Roland

> On 18 Feb 2018, at 22:45, 'Roland Kuhn' via Akka User List 
>  wrote:
> 
> Yes, we considered it with varying depth on multiple occasions and never 
> found a satisfactory solution. Since graph stages are free to transform not 
> only individual elements but also the stream structure the conclusion was 
> that the metadata cannot be hidden from the graph stage code, it must be 
> explicitly foreseen. This will then also need to be reflected in the types.
Thanks for the confirmation - it certainly validates my existing approach to 
instrumenting a stream whereby I pass through OpenTracing Span objects along 
with my main elements. 

This helps me a great deal. 

> One idea was to create a DSL on top that offers certain well behaved 
> combinators for tagged elements, but as far as I know this has not been 
> implemented yet.
Were there issues created for this so that I can follow along? I couldn’t find 
any. No worries if not. 

Thanks again. I really appreciate the dialogue. 

Cheers 
C

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka stream out of band data

[Christopher Hunt]

> On 18 Feb 2018, at 21:10, Viktor Klang  wrote:
> 
> How do you deal with M:N ports or X:Y element permutations?

No idea. :-) My main question is, has there been any thinking around 
associating metadata with elements in the past?

Thanks. 

Cheers 
C

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka stream element meta data

[Christopher Hunt]

> On 18 Feb 2018, at 3:18 pm, Christopher Hunt  wrote:
> 
> It just occurred to me that compound types might be the way to solve this eg 
> `new Element with OOB[Span]`. I shall experiment further... and then PR the 
> Akka stream doco with a section on OOB/instrumentation if there’s interest. 
> I’m very interested to hear about what others think though.

On further reflection, I don’t think that compound types really help that much 
given that it takes effort to deconstruct/reconstruct them through various 
transformations (map etc.).

Also, I was wrong to name this topic in relation to “out of band data”. In 
hindsight, I really meant element metadata. OOB is a separate signalling 
mechanism.

I remain curious as to whether an Akka streams API along the lines of the 
materialisation API has been considered for carrying additional data with an 
element to avoid polluting code.

Here’s a bit of (untested) code illustrating my thinking by way of a solution:
Source
  .single("hi")
  .mapMetadataValue(_ => hiStartedEvent)
  ...
  .viaMeta(hiEndedEvent)
  
…where `hiStartedEvent` starts/returns a OpenTracing Span and `hiEndedEvent` 
takes a single arg of a Span and ends it.

Of course, it doesn’t have to be a Span carried through… it could be any 
metadata you can imagine.

Thanks!

-C

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka stream out of band data

[Christopher Hunt]

> On 18 Feb 2018, at 11:53, Christopher Hunt  wrote:
> 
> By way of solution, perhaps this could be achieved similarly to the 
> materialiser api calls eg viaMat/viaOob.

It just occurred to me that compound types might be the way to solve this eg 
`new Element with OOB[Span]`. I shall experiment further... and then PR the 
Akka stream doco with a section on OOB/instrumentation if there’s interest. I’m 
very interested to hear about what others think though. 

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Akka stream out of band data

[Christopher Hunt]

Hi there,

I’ve been wondering recently if there’s been any thought around carrying out of 
band data through an Akka Stream in the spirit of network streams: 
https://en.m.wikipedia.org/wiki/Out-of-band_data 

One use case is for carrying Open Tracing Spans with elements without polluting 
stream stage operations. To illustrate: 
https://github.com/akka/alpakka/issues/463#issuecomment-365765409

By way of solution, perhaps this could be achieved similarly to the 
materialiser api calls eg viaMat/viaOob.

Thoughts?

Cheers 
C

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Persistence and avoiding var in favor of context.become

[Christopher Hunt]

> On 13 Feb 2018, at 20:50, Christopher Hunt  wrote:
> 
> While receiveRecover is executing though, I presume that I’m going to have to 
> store the current state in a var…? Here’s what I’ve started with:
> override def receiveRecover: Receive = {
>   case e: Event => context.become(unauthenticated(state(e)))
> }
> …but of course, there is no existing state…
Just to tie this off for me, I’m going to use a var to build initial state 
during receiveRecover as there is no way to become a new receiveRecover. 

Cheers 
C

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Persistence and avoiding var in favor of context.become

[Christopher Hunt]

> On 13 Feb 2018, at 8:26 pm, Patrik Nordwall  wrote:
> 
> You have to do the right become transitions in the replay of the events, and 
> when consuming snapshots. Especially the latter is very easy to get wrong.
> 
Thanks Patrik, that shouldn’t be an issue for my use case. My states are 
unauthenticated/authenticated… and that’s it. The actor only becomes 
authenticated after receiving a message from the outside along with some 
validation. So, I’m comfortable moving into the unauthenticated state until 
receiveRecover is finished.

While receiveRecover is executing though, I presume that I’m going to have to 
store the current state in a var…? Here’s what I’ve started with:
override def receiveRecover: Receive = {
  case e: Event => context.become(unauthenticated(state(e)))
}
…but of course, there is no existing state…

receiveCommand will present a similar challenge.

Any advice?

Cheers,
-C

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Persistence and avoiding var in favor of context.become

[Christopher Hunt]

On Friday, 15 September 2017 16:41:42 UTC+10, Konrad Malawski wrote:
>
> I would recommend avoiding become with PersistentActors in general, it 
> gets very complex.
>

The Akka doc (1) suggests that the use of become should be fine. Are you 
able to expand on the complexity statement above?

I'd also like to continue using become with an existing actor that I'm 
attempting to make persistent. Unfortunately, Akka Typed isn't an option 
for me at present.

Thanks for any guidance.

Kind regards,
Christopher

(1) https://doc.akka.io/docs/akka/2.5.9/persistence.html?language=scala

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka, Akka Typed and dead code elimination

[Christopher Hunt]

Hi Roland,

> On 3 Feb 2018, at 5:56 pm, Roland Kuhn  wrote:
> 
> I agree on the tendency. In the case of Akka there are two reasons for using 
> reflection and neither of them is caused by a lack of static types: 
> extensibility and remote marshaling. A new implementation could remove 
> configuration and skip serialization for the local case—in fact that was done 
> in my approach. Perhaps reviving that would solve your issue.
> 
Sounds good to me. :-)

As a slight aside, I think that my general position is that no matter how many 
resources are available to a system, or what the perceived security 
requirements are, dead code elimination is going to become necessary in order 
for the JVM to continue competing against LLVM and other native, linking style 
targets (hence Graal AOT perhaps). For one thing, the more that I can run on a 
single machine, the less my costs are in terms of the machine’s specs.

Thanks for the discussion.

Cheers,
-C

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka, Akka Typed and dead code elimination

[Christopher Hunt]

Hi Roland,

> On 3 Feb 2018, at 5:16 pm, Roland Kuhn  wrote:
> 
> could you elaborate on how exactly Akka Typed is expected to help with your 
> use-case? The only difference I can see is that the new (and currently 
> removed) implementation contained fewer extension points, but that is 
> unrelated to whether ActorRef has a type parameter or not.
> 
Perhaps Akka Typed doesn’t/wouldn’t help. I only mention it because I feel that 
the more strongly typed things are, the less use of reflection and other 
dynamic behaviour there tends to be.

Cheers,
-C

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka, Akka Typed and dead code elimination

[Christopher Hunt]

Thanks for the reply Konrad.

Although my use-case is somewhat forced by working with constrained device 
memory and enterprise security, I think that there’s a broader concern. My 
understanding is that the JVM is embracing ahead of time compilation and the 
potential for dead code elimination during the linking phase. I would think 
that most forms of reflection would be at odds to that. Shouldn’t Akka 
therefore be re-considering its position on its use of reflection, and might 
Akka Typed be a way forward in that regard?

Cheers,
-C

> On 3 Feb 2018, at 3:43 pm, Konrad “ktoso” Malawski 
>  wrote:
> 
> Hi Christopher,
> I’ve worked in the past on an Scala on Android project, so have had the 
> “pleasure” of battling proguard for similar reasons.
> In general I guess the “core stuff” needs to be kept, which would mostly be 
> the akka.actor and dungeon things.
> 
> AFAIR proguard is ale to understand references via “classOf” etc, so user 
> land actors should be fine. Typed actors also should be nicer to proguard.
> The only things we’d need to specifically exclude from removal is things that 
> have classnames defined in configuration,
> that’ll mostly e mailoxes, perhaps the remoting infra etc.
> 
> I guess it can be useful to have a config that is “known to work”, but I 
> don’t think it is realistic to fully know that “this will work for everyone”, 
> after all, you’re removing code.
> If you want to provide the core set of excludes, that sounds useful. We in 
> the time are unlikely to have the time to maintain or help much with this 
> though.
> 
> -- 
> Cheers,
> Konrad 'ktoso <http://kto.so/>' Malawski
> Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>
> On February 3, 2018 at 13:31:35, Christopher Hunt (hunt...@gmail.com 
> <mailto:hunt...@gmail.com>) wrote:
> 
>> Hi everyone, 
>> 
>> I’ve got a requirement to run services on machines with limited resources, 
>> memory in particular, but also disk (disk == memory for my use case!) In 
>> addition, I wish to reduce the attack surface area of a service by 
>> eliminating code that isn’t used. 
>> 
>> I’d therefore like to take a unikernal-style of approach to my services 
>> which, of course, use Akka. Using Proguard on my service very quickly 
>> revealed problems relating to Akka. From looking through past posts, it 
>> seems that the use of Proguard has been a discussion relating to Android 
>> (which also hasn’t helped me around the issues I’ve been having). 
>> 
>> Would there be any interest in seeing Akka become more suitable for dead 
>> code elimination, particularly with the advent of Akka Typed? (reflection 
>> and dead code elimination are at odds with each other) 
>> 
>> Having an official project declaration of what classes should be kept for 
>> dead code elimination, and an integration build verifying this to a degree 
>> is what I’m thinking. I’d be happy contribute a PR with a little help. 
>> 
>> Cheers  
>> C 
>> 
>> --  
>> >>>>>>>>>> Read the docs: http://akka.io/docs/ <http://akka.io/docs/> 
>> >>>>>>>>>> Check the FAQ: 
>> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html 
>> >>>>>>>>>> <http://doc.akka.io/docs/akka/current/additional/faq.html> 
>> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user 
>> >>>>>>>>>> <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 
>> <mailto:akka-user%2bunsubscr...@googlegroups.com>. 
>> To post to this group, send email to akka-user@googlegroups.com 
>> <mailto:akka-user@googlegroups.com>. 
>> Visit this group at https://groups.google.com/group/akka-user 
>> <https://groups.google.com/group/akka-user>. 
>> For more options, visit https://groups.google.com/d/optout 
>> <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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Akka, Akka Typed and dead code elimination

[Christopher Hunt]

Hi everyone,

I’ve got a requirement to run services on machines with limited resources, 
memory in particular, but also disk (disk == memory for my use case!) In 
addition, I wish to reduce the attack surface area of a service by eliminating 
code that isn’t used.

I’d therefore like to take a unikernal-style of approach to my services which, 
of course, use Akka. Using Proguard on my service very quickly revealed 
problems relating to Akka. From looking through past posts, it seems that the 
use of Proguard has been a discussion relating to Android (which also hasn’t 
helped me around the issues I’ve been having).

Would there be any interest in seeing Akka become more suitable for dead code 
elimination, particularly with the advent of Akka Typed? (reflection and dead 
code elimination are at odds with each other)

Having an official project declaration of what classes should be kept for dead 
code elimination, and an integration build verifying this to a degree is what 
I’m thinking. I’d be happy contribute a PR with a little help.

Cheers 
C

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Kafka journal

[Christopher Hunt]

Replying to an old thread. I’m interested to learn of any advancements in 
thinking on this topic over the past 3+ years. 

‪If I have Kafka and want CQRS, how much do I need #akka-persistence? I’m 
starting to wonder if I need it at all and just treating CQRS as the 
architectural pattern that it is and implement as per: 
https://www.confluent.io/blog/event-sourcing-cqrs-stream-processing-apache-kafka-whats-connection/‬

Thanks. 

Cheers 
C

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Supporting transient states using Akka FSM

[Christopher Hunt]

You may not always want to go to C. My example didn’t highlight that, so 
apologies. 

It turns out that you can’t goto within anything other than a when handler 
anyhow (which makes sense to me).

What I did subsequently was send a message to self during B’s onTransition and 
capture it within B’s when. The code looks decent and correct in accordance 
with my state machine diagram. 

> On 23 Dec 2017, at 04:44, Heiko Seeberger  wrote:
> 
> Hmm … ain’t is possible to goto(C) when in state A? Instead of going to the 
> transient B.
> 
> --
> 
> Heiko Seeberger
> Home: heikoseeberger.de
> Twitter: @hseeberger
> Public key: keybase.io/hseeberger
> 
> 
> 
>> Am 22.12.2017 um 09:15 schrieb Christopher Hunt :
>> 
>> Hey there,
>> 
>> I've recently come across a situation with transient FSM states that I'd 
>> like to model in Akka FSM. I'm wondering if there's a better way than below 
>> in terms of expressing transient states:
>> 
>> onTransition {
>>  case A -> B
>>goto(C)
>> }
>> 
>> when(B) {
>>   case _ =>
>> log.error("we should never have got here")
>> }
>> 
>> 
>> 
>> i.e. I need the when(B) in order to register the state. However, it is a 
>> state that we quickly pass through and serves to support the onTransition 
>> logic.
>> 
>> Is there a better way while retaining the B state?
>> 
>> Cheers,
>> -C
>> 
>> -- 
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ: 
>> >>>>>>>>>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ: 
> >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html
> >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user
> --- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Akka User List" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/akka-user/rZI1PcS_L1U/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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Supporting transient states using Akka FSM

[Christopher Hunt]

Hey there,

I've recently come across a situation with transient FSM states that I'd 
like to model in Akka FSM. I'm wondering if there's a better way than below 
in terms of expressing transient states:

onTransition {
 case A -> B
   goto(C)
}

when(B) {
  case _ =>
log.error("we should never have got here")
}



i.e. I need the when(B) in order to register the state. However, it is a 
state that we quickly pass through and serves to support the onTransition
 logic.

Is there a better way while retaining the B state?

Cheers,
-C

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Unix Domain Socket support interest given code written

[Christopher Hunt]

As a follow-up in order to close off this thread, I've now submitted a PR 
for Alpakka: https://github.com/akka/alpakka/pull/623

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Overriding onUpstreamFinish behaviour for FlowOps

[Christopher Hunt]

As a follow-up, I’ve implemented a custom half close stage after having a good 
night’s sleep and thinking about it. :-)

First, the simple half-close custom stage: 
https://github.com/huntc/landlord/pull/14/files#diff-b745088184322d5d8e53de44d17b9ca6R262
 


…and then, if you need to use half close: 
https://github.com/huntc/landlord/pull/14/files#diff-b745088184322d5d8e53de44d17b9ca6R466
 


Cheers,
-C

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Overriding onUpstreamFinish behaviour for FlowOps

[Christopher Hunt]

Thinking about it, what I’m trying to do is implement halfClose behaviour as 
per Tcp.

> On 27 Nov 2017, at 16:17, Konrad “ktoso” Malawski 
>  wrote:
> 
> What kind of Flow exactly. What does it do?
> See this too 
> https://doc.akka.io/docs/akka/current/stream/stream-error.html?language=scala#delayed-restarts-with-a-backoff-stage
>  other than supervision which isn’t generic.
> 
> 
> 
> -- 
> Cheers,
> Konrad 'ktoso' Malawski
> Akka @ Lightbend
> 
>> On November 27, 2017 at 14:14:33, Christopher Hunt (hunt...@gmail.com) wrote:
>> 
>> Hi there.
>> 
>> I've got a requirement for a flow to keep going when its upstream input 
>> completes/fails. I could write a custom flow stage and override 
>> onUpstreamFinish, but I was wondering if there were a means to express this 
>> just using the FlowOps API. FlowOps.detach got me excited, but that isn't 
>> quite what I expected. Also, buffer(0, OverflowStrategy.backpressure) looked 
>> as though it could do the job, but the buffer size must be positive.
>> 
>> Thanks for any assistance.
>> 
>> Kind regards,
>> Christopher
>> --
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ: 
>> >>>>>>>>>> http://doc.akka.io/docs/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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Overriding onUpstreamFinish behaviour for FlowOps

[Christopher Hunt]

> On 27 Nov 2017, at 4:17 pm, Konrad “ktoso” Malawski 
>  wrote:
> 
> What kind of Flow exactly. What does it do?
I’m implementing Unix Domain Sockets and the following interface borrowed from 
Tcp:
def outgoingConnection(
  remoteAddress: UnixSocketAddress,
  localAddress: Option[UnixSocketAddress] = None,
  connectTimeout: Duration = Duration.Inf): Flow[ByteString, ByteString, 
Future[OutgoingConnection]]
If I connect thus:
Source.single(bytes)
  .via(UnixDomainSocket().outgoingConnection(file))
  .runWith(Sink.head)
…then the stream completes given that Source.single is completed. Changing 
Source.single to Source.repeat as a test keeps the stream open of course, and 
the socket connection works nicely.

I notice that the Tcp implementation has a custom stage and uses setKeepGoing. 
I was just wondering if there was a way to avoid my own custom stage. I’m 
currently thinking that there isn’t, but I just wanted to check in the spirit 
of writing less code.

> See this too 
> https://doc.akka.io/docs/akka/current/stream/stream-error.html?language=scala#delayed-restarts-with-a-backoff-stage
>  
> 
>  other than supervision which isn’t generic.
> 
I think I might be able to use that, but it’d be a move away from the Tcp API 
that I’m attempting to preserve. My goal is for UnixDomainSocket to be a 
drop-in replacement for Tcp.

Cheers,
-C

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Overriding onUpstreamFinish behaviour for FlowOps

[Christopher Hunt]

Hi there.

I've got a requirement for a flow to keep going when its upstream input 
completes/fails. I could write a custom flow stage and override 
onUpstreamFinish, but I was wondering if there were a means to express this 
just using the FlowOps API. FlowOps.detach got me excited, but that isn't 
quite what I expected. Also, buffer(0, OverflowStrategy.backpressure) 
looked as though it could do the job, but the buffer size must be positive.

Thanks for any assistance.

Kind regards,
Christopher

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Unix Domain Socket support interest given code written

[Christopher Hunt]

> On 25 Nov 2017, at 01:02, Martynas Mickevičius 
>  wrote:
> 
> this looks really cool! I think extracting it to a separate module for 
> Alpakka is a great idea as well.  

Thanks!

I’ll finish my PR for Landlord and then migrate it.  Should be started within a 
week. 

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Akka Unix Domain Socket support interest given code written

[Christopher Hunt]

Hi Akka team,

Over the past week, I've implemented Akka Streams support for Unix Domain 
Sockets by leveraging the JNR library. There's more work to be done and my 
progress can be seen here: https://github.com/huntc/landlord/pull/14 (the 
UnixDomainSocket class 
itself: 
https://github.com/huntc/landlord/pull/14/files#diff-b745088184322d5d8e53de44d17b9ca6R20).
 
The code is complete but I need to provide unit tests which is what I'm now 
doing.

I was wondering if this functionality would be of interest in general and, 
if so, where would the best place be to raise a PR e.g. Akka core, Alpakka 
etc. given consideration to its JNR library dependency (all Apache licensed 
and totaling about 2MB of class files).

Please advise.

Kind regards,
Christopher

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Allowing SecurityException to propagate during actor system termination

[Christopher Hunt]

Thanks Viktor, I’ve gone with your suggestion which I think is nice and 
explicit:

private val eh = Thread.currentThread().getUncaughtExceptionHandler
system.whenTerminated
  .andThen {
case _ =>
  try {
println("Exiting")
System.exit(exitStatus.getOrElse(1))
  } catch {
case se: SecurityException => 
eh.uncaughtException(Thread.currentThread(), se)
  }
  }

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Allowing SecurityException to propagate during actor system termination

[Christopher Hunt]

Ah yes, uncaught. Thanks for the correction. 

> On 13 Nov 2017, at 21:12, Viktor Klang  wrote:
> 
> When you say "unhandled exception" you mean "uncaught exception"?
> 
>> On Mon, Nov 13, 2017 at 4:48 AM, Christopher Hunt  wrote:
>> Hi everyone,
>> 
>> I have a situation where I need to call System.exit upon an actor system 
>> having terminated. In some runtime situations, a SecurityException will be 
>> thrown and I need that to be propagated as an unhandled exception. I can go 
>> into the details of why if required, but my question is how to enable this. 
>> Here's my existing termination handler which does what I want. However, I'm 
>> wondering if there's a better way given that onComplete and friends all 
>> swallow exceptions and pass them onto the Dispatcher's reporter:
>> 
>>   system.whenTerminated
>> .andThen {
>>   case _ =>
>> new Thread({ () =>
>>   println("Exiting")
>>   System.exit(exitStatus.getOrElse(1))
>> }: Runnable).start()
>> }
>> 
>> 
>> Cheers,
>> -C
>> -- 
>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>> >>>>>>>>>> Check the FAQ: 
>> >>>>>>>>>> http://doc.akka.io/docs/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 https://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 a topic in the Google 
> Groups "Akka User List" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/akka-user/gZkCvLWhyGc/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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Allowing SecurityException to propagate during actor system termination

[Christopher Hunt]

Hi everyone,

I have a situation where I need to call System.exit upon an actor system 
having terminated. In some runtime situations, a SecurityException will be 
thrown and I need that to be propagated as an unhandled exception. I can go 
into the details of why if required, but my question is how to enable this. 
Here's my existing termination handler which does what I want. However, I'm 
wondering if there's a better way given that onComplete and friends all 
swallow exceptions and pass them onto the Dispatcher's reporter:

  system.whenTerminated
.andThen {
  case _ =>
new Thread({ () =>
  println("Exiting")
  System.exit(exitStatus.getOrElse(1))
}: Runnable).start()
}


Cheers,
-C

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Debugging postStop cause within a custom stage

[Christopher Hunt]

As a follow-up to this, the problem was of course of my own creation. However, 
what wasn’t obvious to me was that the default behaviour of an InHandler is to 
complete the stage once the upstream is completed. The API doc states:

Called when the input port is finished. After this callback no other 
callbacks will be called for this port.

…but what it fails to state is that the default behaviour is to complete the 
stage. Same goes for the OutHandler when the downstream is complete (which 
makes more sense to me as default behaviour).

The reason that this became an issue for me was because my upstream completed 
very quickly (it was a Source.single). Thus, my custom stage completed fast and 
my async handler fired, but didn’t get processed.

Would a PR be welcomed to enhance the API doc for InHandler and OutHandler? I 
think it’d be good to mention that completeStage is called by default and that 
any outstanding async requests will go unprocessed.

Cheers,
-C

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Debugging postStop cause within a custom stage

[Christopher Hunt]

I’m wondering if I'm seeing a problem related to 
https://github.com/akka/akka/issues/23111 
. 

My `Source.single` completes quite quickly. I also have a custom stage with an 
async callback. I have observed that the stage registers as being completed 
while the async callback hasn't been serviced. It could absolutely be something 
wrong with my test case. I'm still not clear on why my custom stage is 
registered as being completed, although I don’t see it being because of the 
materialiser shutting down.

If I concat an extra ByteString onto the Source.single then I don’t see the 
issue. Perhaps some race condition then…

Here’s my (uncomfortable) workaround: 
https://github.com/huntc/landlord/blob/3785b47a2f770ede44351b588e3b53a7cdf7d013/landlordd/daemon/src/test/scala/com/github/huntc/landlord/JvmExecutorSpec.scala#L53-L60
 


Thanks for helping me gain further insight into what’s going on.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Debugging postStop cause within a custom stage

[Christopher Hunt]

> On 3 Nov 2017, at 8:30 am, Patrik Nordwall  wrote:
> 
> Could it be that the materializer is shutting down?
> “Abrupt termination”
> /Patrik
I don’t *think* so, as I should see that exception manifest itself in the test: 
https://github.com/huntc/landlord/blob/8671d90dba7247db517ef21b64b84d659084a02f/landlordd/daemon/src/test/scala/com/github/huntc/landlord/JvmExecutorSpec.scala#L29
 


Interestingly, if I change the Source.single to a Source.apply with a one 
element list of the byte string then I don’t see the problem… so it appears to 
be a race condition of some kind… and probably to do with the test.

I’m suspicious of this test though and so shall look further. Thanks for 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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: FSM, how to make stateTimeout relative?

[Christopher Hunt]

Perhaps something like this in order to get your FiniteDuration:

Duration.ofMillis(
  ChronoUnit.MILLIS.between(
ZonedDateTime.parse("2007-12-03T10:15:30+01:00[Europe/Paris]"), 
ZonedDateTime.now
  )
)

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Debugging postStop cause within a custom stage

[Christopher Hunt]

Hi there,

I've got a situation where I observe a postStop being called within my 
custom GraphStage prior to when I'd expect. I'm sure Akka is doing the 
right thing but, what's the best way to debug what is causing the postStop? 
My understanding is that the input and output connections should all have 
closed in order for postStop to be invoked. I'm not expecting the output 
connection to have been closed though.

Thanks for any pointers.

Cheers,
-C

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Artery and IPC

[Christopher Hunt]

Thanks Patrik. 

I imagine that most savings will come in the area of establishing a connection 
as this is completely bypassed with IPC of course. 

As an aside, perhaps a functional advantage to supporting IPC is security 
though as you can leverage OS permissions. 

Cheers 
C

> On 30 Oct 2017, at 06:38, Patrik Nordwall  wrote:
> 
> Hi Christopher,
> 
> Aeron IPC is currently not supported, but I found it interesting to see if it 
> works so I tried it. Had to change a few small things. Of course I was 
> curious about the performance. No difference for small messages (100 bytes), 
> but for 10kB messages it has higher throughput 1100 MB/s with ipc vs 320 MB/s 
> with upd on my laptop. This is with actor messages (MaxThroughputSpec), not 
> raw Aeron.
> 
> I would have to verify more before promising that we will support it.
> 
> Cheers,
> Patrik
> 
>> On Sat, Oct 28, 2017 at 2:38 AM, Christopher Hunt  wrote:
>> Hi there
>> 
>> I’m thinking of using Akka cluster in a single machine style scenario (low 
>> powered router), so that I can use distributed pub/sub across processes in 
>> particular. I see that Aeron supports IPC as a transport, but Akka’s Artery 
>> doesn’t appear to be able to utilise it - I could be misreading the 
>> reference config though.
>> 
>> Has any consideration been given to supporting the other non-UDP Aeron 
>> transports within Akka Artery?
>> 
>> Cheers
>> C
>> 
>> --
>> >>>>>>>>>>  Read the docs: http://akka.io/docs/
>> >>>>>>>>>>  Check the FAQ: 
>> >>>>>>>>>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
> 
> 
> 
> -- 
> Patrik Nordwall
> Akka Tech Lead
> Lightbend -  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 a topic in the Google 
> Groups "Akka User List" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/akka-user/XimVIC_KvMA/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 https://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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Artery and IPC

[Christopher Hunt]

Hi there

I’m thinking of using Akka cluster in a single machine style scenario (low 
powered router), so that I can use distributed pub/sub across processes in 
particular. I see that Aeron supports IPC as a transport, but Akka’s Artery 
doesn’t appear to be able to utilise it - I could be misreading the reference 
config though. 

Has any consideration been given to supporting the other non-UDP Aeron 
transports within Akka Artery?

Cheers 
C

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: FlowOps concat with Source.fromFuture behaviour

[Christopher Hunt]

Thanks for the advice Johan. I thought I had it all cracked given my last 
reply, but alas, no. So perhaps this is the issue that you describe after 
all. I'm quite confused at this point.

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] FlowOps concat with Source.fromFuture behaviour

[Christopher Hunt]

It turns out not to be an issue with concat and futures... I believe the 
issue is in relation to my usage of BroadcastHub (which I didn't reveal 
before). Here's a reproducer:

import akka.actor.ActorSystem
import akka.stream.ActorMaterializer
import akka.stream.scaladsl.{ BroadcastHub, Keep, Source }
import scala.concurrent.duration._
import scala.concurrent.Promise
import scala.concurrent.ExecutionContext.Implicits.global

implicit val system = ActorSystem("test")
implicit val mat = ActorMaterializer()

val someSource = 
  Source.single("This is someSource")
.toMat(BroadcastHub.sink)(Keep.right)
.run()

val somePromise = Promise[String]
someSource.concat(Source.fromFuture(somePromise.future)).runForeach(println)
Thread.sleep(1000)
somePromise.success("This is some Promise")

The above outputs just the "This is some Promise", and not the "This 
is someSource". I'm presuming that this is because the BroadcastHub 
completes given the Source.single and so any subsequent usage 
of someSource will represent that the source is completed. While this makes 
sense and is as per the API spec, I was expecting that any buffered 
elements of the broadcast sink would be flushed out first... seems not so 
though.

My goal with the above code is to get hold of an output stream and source 
without dealing with a future. Any further ideas on an approach would be 
welcomed.
Thanks.

Cheers,
-C

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] FlowOps concat with Source.fromFuture behaviour

[Christopher Hunt]

How weird, I don't appear to be able to reproduce in a simplified fashion. 
I shall investigate further. Here's my attempt (that works as expected):

import akka.actor.ActorSystem
import akka.stream.ActorMaterializer
import akka.stream.scaladsl.Source
import scala.concurrent.duration._
import scala.concurrent.Promise
import scala.concurrent.ExecutionContext.Implicits.global

implicit val system = ActorSystem("test")
implicit val mat = ActorMaterializer()

val someSource = Source.single("someSource").initialDelay(1.second)
val somePromise = Promise[String]

someSource.concat(Source.fromFuture(somePromise.future)).runForeach(println)
somePromise.success("somePromise")



-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] FlowOps concat with Source.fromFuture behaviour

[Christopher Hunt]

> On 25 Oct 2017, at 10:25 pm, Viktor Klang  wrote:
> 
> Sure, I'm asking if it behaves differently because AFAICT they shouldn't. So 
> if the alternate encoding fixes it, then it's pretty simple to utility-fy it 
> until the inconsistency is fixed.
> 
Hey Viktor,

You suggestion didn’t make any difference i.e. it appears as though the 
Source.single approach yields the same outcome as Source.fromFuture.

I’ll craft a reproducer and raise an issue.

Thanks.

Cheers,
-C

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] FlowOps concat with Source.fromFuture behaviour

[Christopher Hunt]

> On 25 Oct 2017, at 21:05, Viktor Klang  wrote:
> 
> Does it behave differently from 
> `Source.single(somePromise.future).mapAsync(1)(identity)` ?

Interesting idea. Thanks Viktor. I’ll try it in the morning. 

It feels a little odd to look at though...

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] FlowOps concat with Source.fromFuture behaviour

[Christopher Hunt]

Hey community,

I've got a situation where there's a promise that, when completed, I'd like 
to concat its value onto the *end* of any stream elements before it i.e.:

someSource.concat(Source.fromFuture(somePromise.future))

What I'm noticing is that if the promise is completed then the promised 
value doesn't wait for someSource to complete. Rather, it yields an element 
near to the time that the promise was completed, seemingly ignoring any 
further elements from someSource.

This problem appears to be similar 
to https://github.com/akka/akka/issues/22042, where flatMapConcat is 
recommended. However, I'm not sure that flatMapConcat as its contract 
appears to be different - I only want to concat elements when someSource is 
complete. flatMapConcat appears to get called for each element from 
someSource.

Any further pointers in order to achieve the API description of concat in 
conjunction with Source.fromFuture?

Cheers,
-C

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: Custom stage with a sub-flow maintaining backpressure

[Christopher Hunt]

Ah, I re-discovered the async callback APIs... I'd forgotten about them. 
Thus, my code now becomes:

val (queue, ar) = 
  Source
.queue[ByteString](100, OverflowStrategy.backpressure)
.prefixAndTail(0)
.map {
  case (_, in) => in
}
.toMat(Sink.head)(Keep.both)
.run
val asyncTryPull = getAsyncCallback[Unit]( _ => if (!hasBeenPulled(in)) 
tryPull(in))
val asyncCancel = getAsyncCallback[Unit]( _ => cancel(in))

and...

queue.offer(newBlockBuffer).andThen { 
  case Success(QueueOfferResult.Enqueued) => asyncTryPull.invoke(())
  case _  => asyncCancel.invoke(())
}


Sanity check still appreciated. Thanks.

Cheers,
-C

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Custom stage with a sub-flow maintaining backpressure

[Christopher Hunt]

Hi Akka community,

I'm looking to confirm that the below strategy for managing back pressure 
in sub-flows is sane.

I have a need to create a sub-flow within a custom stage. In order to 
create the sub-flow, I'm using `prefixAndTail` as follows:

val (queue, source) = 
  Source
.queue[ByteString](100, OverflowStrategy.backpressure)
.prefixAndTail(0)
.map {
  case (_, in) => in
}
.toMat(Sink.head)(Keep.both)
.run



This then provides me with a means to feed my custom stage's pushed input 
into the sub-flow via a queue and source respectively:

queue.offer(bytes).andThen { 
  // Note that we're calling pull and cancel from a different thread.
  // This is fine though given that the stage's onPush will not be called
  // again until we pull or cancel.
  case Success(QueueOfferResult.Enqueued) => pull(in)
  case _ => cancel(in)
}


Thus I only wish to pull for more elements when backpressure permits.

Thanks for any confirmation or otherwise.

Kind regards,
Christopher

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Is there an Akka stream mapAsync equivalent for yielding a Source?

[Christopher Hunt]

:$

Thanks Konrad.

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

[akka-user] Is there an Akka stream mapAsync equivalent for yielding a Source?

[Christopher Hunt]

Hey everyone,

Given that mapAsync yields a Future, I was looking for a similar type of 
stage that yields a Source instead. My goal is to direct the flow's input 
to an in-process actor and then have that actor feedback its reply as a 
Source (the reply is most certainly a stream).

Thanks for any guidance.

Kind regards,
Christopher

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

[akka-user] Re: ConductR sandbox linking to another container

[Christopher Hunt]

Hi Chris,

There's nothing built in to do this right now. Sounds like what we need to 
do here is allow the service locator to be configured with an external 
service. We have this on our to-do list.

However you should be able to pass an environment var via the -e option 
though and have that environment var resolve to the uri of your Cassandra 
instance. Your Typesafe Config file could then use environment var 
substitution in order to declare the location of your Cassandra service. 
How does that sound?

Kind regards,
Christopher

On Monday, 15 August 2016 00:13:41 UTC+10, Chris Baxter wrote:
>
> I don't know of any ConductR user group or forum out there, so I am asking 
> here.  I am playing around with the ConductR sandbox on my Mac and I want 
> to be able to have my 3 ConductR nodes communicate with Cassandra which is 
> running in another local container.  Usually, this can be accomplished with 
> links (--link) being established when starting up the containers.  But it 
> seems that you cannot use the --link option when running the sandbox via 
> "sandbox run ...".  I know you can deploy Cassandra as another bundle into 
> ConductR but I don't want to go that route.  Does anyone have any expertise 
> or suggestions on being able to setup a networking link between a ConductR 
> node's container in sandbox and my Cassandra container?
>

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka and Lagom

[Christopher Hunt]

Akka is a low level toolkit. Lagom is a higher level framework. Frameworks are 
opinionated and tend to be strongly focused on developer productivity. This is 
a goal of Lagom. 

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka stream compression / decompression

[Christopher Hunt]

...but your example doesn't close the output stream right?

Don't you want something like this:

writeToFile
  .future(someMaterializer)
  .andThen {
case _ => out.close()
  }


On Thursday, 9 October 2014 00:57:30 UTC+11, Nicolas Jozwiak wrote:
>
> Yes we close the outputstream at the end.
>
> I've continued to do some tests with small chunk size and it passes only 
> one time... When I retry I have the above error => (Expected file length: 
> '114541', actual: '95541') or a Java OutOfMemoryError...
>
> Nicolas.
>
> Le mercredi 8 octobre 2014 15:48:42 UTC+2, drewhk a écrit :
>>
>> Do you properly close/flush the outputstream?
>>
>> -Endre
>>
>> On Wed, Oct 8, 2014 at 3:45 PM, Nicolas Jozwiak  
>> wrote:
>>
>>> I've just tried with a smaller chunk size (1000), and now I have a 
>>> different file size at the end => (Expected file length: '114541', actual: 
>>> '95541')
>>> Weird...
>>>
>>> Nicolas
>>>
>>> Le mercredi 8 octobre 2014 11:37:42 UTC+2, Martynas Mickevičius a écrit :

 Have you tried it with smaller chunk sized?

 On Wed, Oct 8, 2014 at 12:34 PM, Nicolas Jozwiak  
 wrote:

> The compress / decompress implementation works well (tested with a 
> simple example without stream).
>
> The ByteString I receive are not the same size from the compression. 
> For example a chunk size of 2, it will be 19065 after compression. 
> From 
> the decompression I will receive 19070 to decompress...
>
> Here the stack error : 
>
> net.jpountz.lz4.LZ4Exception: Error decoding offset 10 of input buffer
> at net.jpountz.lz4.LZ4JNIFastDecompressor.decompress(
> LZ4JNIFastDecompressor.java:33) ~[lz4-1.2.0.jar:na]
>
> Nicolas.
>
> Le mercredi 8 octobre 2014 11:14:53 UTC+2, Martynas Mickevičius a 
> écrit :
>>
>> Okay. That makes sense then.
>>
>> What kind of errors are you getting? Are the ByteStrings received in 
>> a different order?
>>
>> Have you tested compress/decompress method implementation?
>>
>> On Wed, Oct 8, 2014 at 12:08 PM, Nicolas Jozwiak  
>> wrote:
>>
>>> Hi Martynas,
>>>
>>>Yes it's a simplified example, because we use another branch to 
>>> do some some digester process.
>>> Here the complete code  :
>>>
>>> FlowGraph { implicit builder =>
>>>   val broadcast = Broadcast[ByteString]
>>>
>>>   // streamDigester is an extends to Subscriber and update a 
>>> MessageDigest object
>>>   val digester = SubscriberSink(streamDigester)
>>>
>>>   val in = IteratorSource(byteStream.grouped(chunkSize).map(
>>> StreamOps.toByteString))
>>>
>>>   val compress = FlowFrom[ByteString].map(StreamOps.compress)
>>>   val out = SubscriberSink(outputStream)
>>>
>>>   in ~> broadcast ~> compress ~> out
>>>   broadcast ~> digester
>>>
>>> }.run()
>>>
>>> Nicolas.
>>> Le mercredi 8 octobre 2014 10:34:17 UTC+2, Martynas Mickevičius a 
>>> écrit :

 Hello Nicolas,

 is this the code you are running or is the the simplified example?

 I am asking, because you do not need to use FlowGraph in a linear 
 use case like this. Broadcast junction that you create and use only 
 once is 
 meant to split the stream into two or more legs.

 Another issue in this code on the publisher side is that you are 
 grouping and mapping on iterator and not on the Flow. I think you 
 should 
 move these operation to the flow.

 The producer side with FlowGraph creation removed and combinator 
 operations moved to the Flow then would look like:

 // warning, not compiled
 IteratorSource(byteStream).grouped(chunkSize).map(StreamOps.
 toByteString).produceTo(outputStream)

 On Tue, Oct 7, 2014 at 11:53 PM, Nicolas Jozwiak >>> > wrote:

> Hello,
>
>I’m currently using akka stream to stream some big files and it 
> works quit well :) 
>
>But in the FlowGraph stream I want to add some compression and 
> decompression steps.
>
>Compression seems working correctly, but I’ve got some offset 
> errors when the decompression is executed. 
>
> To help, here is the code :
>
> On the Producer :
>
>   // ByteIterator implements Iterable[Byte] and reads the file 
> byte by byte
>
>  val byteStream = new ByteIterator(buffStream)
>
>  FlowGraph { implicit builder =>
>
> val broadcast = Broadcast[ByteString]
>
> val in = IteratorSource(byteStream.grouped(chunkSize).map(
> StreamOps.toByteString))
>
> val compress = FlowFrom[ByteString

Re: [akka-user] Re: Multiple Futures inside Actor's receive

[Christopher Hunt]

…so there you are… there is of course still a danger of closing over the wrong 
thing. We should take a copy of the log then before the callback. As stated, 
the idea is to minimise the potential for closing over the wrong thing, but of 
course the approach doesn't eliminate that possibility.

On 08/08/2014, at 5:55 PM, √iktor Ҡlang  wrote:
> In the example you are closing over 'this.log...'
> 

-- 
Christopher Hunt
Senior Engineer
Typesafe – Build Reactive Apps on the JVM!

Twitter: @huntchr

-- 
>>>>>>>>>>  Read the docs: http://akka.io/docs/
>>>>>>>>>>  Check the FAQ: 
>>>>>>>>>> http://doc.akka.io/docs/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: Multiple Futures inside Actor's receive

[Christopher Hunt]

IMHO the key is to minimise the potential for closing over state that isn't 
available to a future's callback. This is tricky, and the approach I'm 
going to suggest only diminishes the risk, it does not eliminate it.

I see that there are broadly two options: either create a worker actor to 
manage your asynchronous action; or use pipeTo as Michael suggests.

Using a worker actor in place of the future isn't always under your control 
given that the future is yielded by some other library; as appears to be 
the case for you. Which leaves you pipeTo...

The thing to manage it transforming the result of the future into a form 
that your actor can receive and continue with i.e. you may need to pass 
context. It is this additional context that you must be careful about 
constructing in order to avoid closing over state that isn't available to 
your callback. However given that you're just performing a transformation, 
the risk of closing over something is lessened. Here is an example 
(absolutely not tested/compiled/styled etc.):

case UpdateState => {
  val tran = rClient.transaction()

  (tran.zcard(key) 
mapTo (z => (tran, key, z))
recover {case f => log.warning("ZCARD future failed ...", f)}
pipeTo self)
  
  tran.exec()
   
case (tran: Transaction, key: String, z: Int) =>
  (tran.zrange(key, z - 1, z) 
recover {case e => log.warning("ZRANGE future failed ...", e)}
pipeTo self)
  
case x: ByteString =>
  val v = x.utf8String
  log.info(s"Updating state with $v ")
  mutableState ++ v

-- 
>>  Read the docs: http://akka.io/docs/
>>  Check the FAQ: 
>> http://doc.akka.io/docs/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] [Java] Registering Actors with Guice

[Christopher Hunt]

My two cents:

The actor system should be made available as something that is injectable 
(a bean). The actor system should be used to resolve actor refs via actor 
selection. Any actors that require construction either from the actor 
system or the context should call upon the bean context to resolve 
arguments for Props. 

HTH

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