Re: [akka-user] import context.dispatcher nullpointerexception

[Viktor Klang]

Context is bound to the lifecycle of the actor.

On Tue, Mar 6, 2018 at 8:37 PM, Jeff  wrote:

> I have noticed an issue where if a future maps/flatmaps after actor
> shutdown, a NullPointerException is thrown. I've narrowed it down to the 
> import
> context.dispatcher, which I technically understand since that is closing
> over actor state. If I change that to implicit val ec = context.dispatcher,
> everything works fine.
>
> I'd like to understand what is the best practice in this case, since the
> documentation for context.dispatcher indicates that it is threadsafe and
> looking at the actor trait, context is a val. Most documentation seems to
> indicate that import context.dispatcher is preferred.
>
> Thanks
> Jeff
>
> --
> >> 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 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] Re: HTTP server performance

[Viktor Klang]

What does wrk2 say w.r.t. throughput?
Are you testing pipelined requests or new connections for each request? Are
you testing over network or not?

On Wed, Feb 21, 2018 at 12:25 AM, Mirek Suk  wrote:

> Lesser = less maximum threads. Akka has minimum which is "high" for 2 core
> machines. = in error margin difference +-~5%
> throuput on default displtcher changed to 100 and 1 (clustering changes
> this to 10 from 1)
> 1 = worse performance (around -20%, but once again consider artery in
> play, with default remoting I assume it would be worse)
> 100 = in error margin.
>
> I even tried to create "local" actorSystem for services which are local to
> each akka pod/node (in jvm process) instead of using clusered one. made no
> difference.
> Noticeable difference in grpc was
> https://grpc.io/grpc-java/javadoc/io/grpc/ServerBuilder.
> html#directExecutor--
> around 10% in overall cpu consumption. meaning routing "something" from
> netty thread to executor is somewhat slow. (considering we only do ask in
> grpc)
>
> Tools
> - jmeter (for "hello world" benchmark)
> - custom device simulator. We're prototyping IOT server app.
>
> M.
>
> --
> >> 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 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] Re: HTTP server performance

[Viktor Klang]

On Tue, Feb 20, 2018 at 11:46 PM, Mirek Suk  wrote:

> I doubt dispatcher is problem as forkjoinpool with default (and lesser
> settings due to tests required by ops) were tried.
>

What do you mean by "lesser settings"? How did changing pool size and/or
throughput affect your bench?

What tool are you using to bench it with?


> No other dispatches would make sense in our case.
>
> As a sidenote grpc.io endpoint which does
> - route to akka cluster instance where state is via sharding actor (artery
> is used)
> - persistent actor modifies state (cassandra cluster)
> - route response back and respond to grpc call
>
> This endpoint has performance of ~6k req/sec (akka is cpu bound here)
> which (considering the amount of work) is "nice" (once again I see
> performance metrics in c++ so I'm biased, but rapid development in akka
> somewhat erases some issues for me)
>
> So I don't see where http endpoint could spend so much time if it has only
> ~15% more performance over grpc.
>
> Once again my main issue here is original vs current tests.
> Sadly I can find proof for both cases - akka http unacceptable/acceptable
> - online. One here, second on unrelated site.
> However nothing still explains performance degradation, except for my
> error.
> https://groups.google.com/forum/#!topic/akka-user/qhZlh0KBl2A
> https://www.techempower.com/benchmarks/
>
> I did not study methodologies used to validate any of those benchmarks.
> Possibly akka team should do that so we have reference point.
>
> M.
>
> --
> >> 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 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] HTTP server performance

[Viktor Klang]

What dispatcher tuning did you experiment with?

On Tue, Feb 20, 2018 at 10:57 PM, Mirek Suk  wrote:

> Only a few of them could affect CPU consumption and throuput, unless they
> mean something else.
> Besides that as I mentioned in op throuput degradation was "random" and on
> same system. Tunning (in java) usually means ~50%. As I mentioned I'm
> experiencing 9x performance drop from initial benchmarks.
>
> As a sidenote
> JVM tuning: min, max memory = 2gb (bit op, but due to sharding state),disable
> shared memory (akka is distributed as docker)
> Linux IO tuning: netty (both v3 and v4 as akka uses v3) epoll loop used.
>
> Performance degradation happened on windows server machine used for
> initial evaluation. I sadly never did benchmarks on EC2 linux instances
> initially as we were bound for Azure, so my reference point sucks a bit.
> I still do consider 7k requests with 1000milicores on 2xcpu a very
> miserable result.
>
> My experience with scala/java is very limited - 2 months (c++ guy here) so
> my expectations may be above what jvm is capable of.
> Benchmark from someone else would probably help, but akka http benchmarks
> are scarce.
>
> Besides that I'm unsure why do I answer to non constructive posts.
> Probably because I needed help which won't be found here.
>
> Thanks.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at 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 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] HTTP server performance

[Viktor Klang]

Ok. So besides the common dispatcher tuning tips, JVM tuning tips, and
Linux IO tuning tips there's also a lot of settings for Akka Http

 specifically.

On Tue, Feb 20, 2018 at 6:23 PM, Mirek Suk  wrote:

> Thanks, but been there seen that, I would not be here without simple
> google search.
>
> Guy used blocking operations which limited his throughput. We - as far as
> I know and as far cpu usage says - don't.
> For http benchmark i use - as I mentioned - simple complete("hello world")
> For normal operation we use ask pattern which creates temporary actor and
> complete requests in async manner.
>
> M.
>
> --
> >> 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 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] HTTP server performance

[Viktor Klang]

The top hit for me when searching for "tuning akka http" is:
https://stackoverflow.com/questions/41297334/akka-http-performance-tuning

On Tue, Feb 20, 2018 at 5:39 PM, Mirek Suk  wrote:

> There is not much to change in akka http server configuration. Care to
> share any tips ?
>
> I've tried fidling with io.tcp with little luck. (accept batches etc...)
> EC2 instances are restarted during every deployment.
>
> Anyways I'm currently in process of migration of http interface to
> finangle as it seems to have ~2.5x better throughput with less cpu
> consumed.
> But I still wonder where the performance I initially measured went. (I
> blame the meltdown patch on windows secretly lol)
>
> Thanks
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at 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 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] HTTP server performance

[Viktor Klang]

Mirek,

As a general note: Benchmarking using default configuration is almost
pointless* since a default configuration is—by definition, and by
necessity—a configuration which will not be *optimal for a specific
use-case*.

*It can be useful as a baseline for tuning.

On Mon, Feb 19, 2018 at 11:30 PM, Mirek Suk  wrote:

> Hi everyone.
>
> AKKA 2.5.9 / HTTP 10.0.11
>
> As part of prototyping architecture, I ran some benchmarks (including
> http) few months ago.
> A simple hello world (request handler is completed with result
> immediately) had nice performance ~2.7m requests/minute. with 1,6m r/m when
> response included ask to sharded actor.
>
> Recently I re-did those benchmarks to find out around ~9x performance drop
> on original test system.
> Rolled prototype back to point of original test with similar result.
> Built scala http sample with similar result.
> Reinstalled JVM with similar result.
> Randomly got performance back, until system restart (yeah like what ?)
>
> On EC2-T2.medium I can do ~7k req/s to "hello world" page with 100% CPU
> usage (2 cores).
> No akka.http configuration is changed and system does no background
> processing.
> Default dispatcher is unchanged (only due to clustering throughput = 10).
>
> Is this kind of performance expected ?
> Is there something I can try ?
>
> Thanks,
> M.
>
> --
> >> 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/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 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

[Viktor Klang]

How do you deal with M:N ports or X:Y element permutations?

-- 
Cheers,
√

On Feb 18, 2018 01:53, "Christopher Hunt"  wrote:

> 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.
>

-- 
>>  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] Request for help on Improving Scalability for Akka Streams Program

[Viktor Klang]

Where is your bottleneck?

On Thu, Jan 11, 2018 at 12:17 PM,  wrote:

> Hi Everyone,
>
> I am learning Scala and Akka Streams, I would kindly like to request for
> help on enhancing my small Akka Streams Program so that it can scale with
> increase in data. Below are the two functions of the Program;
>
> a. convertTxtToPDF: This function converts raw text files to PDF files
> b. setPwdLock: This function sets a password on PDF files generated
>
> It takes below time for processing;
>
> i. 1000 text files takes 8 mins (50 parallelism)
> ii. 3000 text files takes 14 mins (150 parallelism)
> iii. 1 text files takes 47 mins (500 parallelism)
>
> I noted that with increase in files, the longer it takes to process.
> Kindly help me enhance the Program to scale with increased data i.e
> processing should take less time with increased number of text files.
>
> Please find the attached code for the Program.
>
> Kind Regards,
> Emmanuel.
>
> --
> >> 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 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] Re: How to measure performance of Actor Message from one actor reaching to another actor

[Viktor Klang]

Also, is serialization/deserialization included? At what point does the
timer clock start, and when does it stop?

-- 
Cheers,
√

On Dec 15, 2017 20:31, "Patrik Nordwall"  wrote:

> What are you interested in? Throughput (msg/s) or latency (us)? Remote or
> local? What will the results of the benchmarks be used for?
>
> /Patrik
> fre 15 dec. 2017 kl. 12:23 skrev Akka Team :
>
>> I think the floodPipe benchmark may do what you want, commented out but
>> you could easily uncomment and run locally:
>>
>> https://github.com/akka/akka/blob/master/akka-bench-jmh/
>> src/main/scala/akka/actor/ForkJoinActorBenchmark.scala#L92
>>
>> --
>> Johan
>> Akka Team
>>
>> On Fri, Dec 15, 2017 at 11:20 AM,  wrote:
>>
>>> Ok, I just looked at TellOnlyBenchmark.scala
>>> 
>>>  closely and it just drops all the message and does not take into
>>> consideration of time taken by message to reach receiving actor.
>>>
>>>
>>> On Friday, December 15, 2017 at 2:54:55 PM UTC+5:30,
>>> kpr...@thoughtworks.com wrote:

 Hello,

 I want to measure a performance of following use case using jmh.




 1.
 Actor A sends Msg A to Actor B
 2. On receiving Msg A, Actor B sends Same Msg A to Actor C

 I just want to measure performance of Msg A from Actor A reaching to
 Actor C (Do not want to consider acknowledgment).
 Is there any way i can measure this performance?

 I was going through Akka jmh benchmarks and found this
 TellOnlyBenchmark.scala
 

 But not sure it just measures the performance of sending messages or it
 considers time required to reach message to Echo Actor?


 Thanks


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

[Viktor Klang]

The ActorRef won't prevent the Actor-instance from being garbage-collected.
But if you want to avoid hanging onto stale ActorRefs I'd recommend using
Death Watch and remove the refs as they are reported in as dead.

On Sun, Nov 19, 2017 at 8:13 PM, Joseph Mansigian <
joseph.c.mansig...@gmail.com> wrote:

> I have a Play Framework Scala application in development that stores long
> lived ActorRefs in a mutable Map. When an actor is no longer needed it is
> sent it a message that informs it to stop itself and it will.
>
> My concern is about the visibility of stopped actors to JVM garbage
> collection; especially those whose ActorRefs are enclosed within a
> Collection,
>
> What do I need to do if  ActorRefs are ( hidden ? ) inside a Scala
> Collection?
>
> --
> >> 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 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

[Viktor Klang]

Depends on what you want to achieve. You can always do
Thread.currentThread.getUncaughtExeptionHandler and pass your exception in
manually (if you don't want to throw a Fatal exception or provide your own
`reporter` (to the ExecutionContext).

On Mon, Nov 13, 2017 at 1:30 PM, Christopher Hunt  wrote:

> 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/c
>> urrent/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.
>



-- 
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 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

[Viktor Klang]

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 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] Re: Usage of StreamConverters.asOutputStream / possible alternative API?

[Viktor Klang]

Yup

On Thu, Oct 26, 2017 at 3:51 PM, Rafał Krzewski 
wrote:

> Hi Viktor,
>
> I'm passing the OutputStream to a single method that does a bunch of
> writes synchronously and as soon as it returns I do os.close() so I should
> be good, no?
>
> Cheers,
> Rafał
>
> W dniu czwartek, 26 października 2017 14:02:32 UTC+2 użytkownik √ napisał:
>>
>> Be careful though, as you need to ensure proper happens-before
>> relationship between the writes and the closing of the OutputStream. (and
>> other writes of course)
>>
>> On Thu, Oct 26, 2017 at 1:56 PM, Rafał Krzewski 
>> wrote:
>>
>>> That worked like a charm :) Thanks a lot Johan!
>>>
>>> Cheers,
>>> Rafał
>>>
>>> W dniu czwartek, 26 października 2017 10:49:52 UTC+2 użytkownik Johan
>>> Andrén napisał:

 Materialization is not async, so anything you do in
 mapMaterializedValue will block the materialization. Simplest solution is
 to not run the logic that feeds the OutputStream inside the
 materialization, but instead do that by keeping the materialized value
 through your chain of stages, and getting it as the returned value from
 run(). In some cases, maybe yours, you cannot do that because you are
 passing the blueprint to some API that will do the actual materialization,
 in that case you can instead fork off a future/thread to do the writing, to
 let the materialization complete.

 Something like this:

   def legacySource =
 StreamConverters.asOutputStream()
   .mapMaterializedValue { outputstream =>
 Future {
   while(something) {
 outputstream.write(data)
   }
 }(use-a-blocking-specific-dispatcher-here-as-write-is-blocking)
 NotUsed
   }

   val route = get {
 complete {
   HttpEntity(
 ContentTypes.`application/octet-stream`,
 legacySource
   )
 }
   }

 --
 Johan
 Akka Team

 On Wednesday, October 25, 2017 at 1:42:58 PM UTC+2, Rafał Krzewski
 wrote:
>
> Hi,
>
> I've tried using `StreamConverters.asOutputStream` and immediately
> run into the deadlock described in the documentation [1]
>
> My use case is that I am am creating Excel spreadsheet using Apache
> POI's streaming API [2] and then stream out the result using Akka HTTP.
>
> Under the hood POI is writing the row data into a temporary files on
> disk. When all data is ready, one can write out the result to an arbitrary
> `OutputStream` [3].
>
> When interoperating with Akka HTTP I need to provide a `Source` that
> is materialized by the framework. That's why my intuition was using
> `mapMaterializedValue` to provide the code making use of the 
> `OutputStream`
> at the site when I'm creating the source. Unfortunately this does not 
> work.
> I was able to work around that by writing out the spreadsheet to another
> temporary file, providing a `Source` to Akka HTTP side using `FileIO` and
> some additional song and dance to clean up the temporary files in all
> circumstances.
>
>
> I am wondering if there is a way I could use
> `StreamConverters.asOutputStream` correctly in this scenario that I
> don't see? Or maybe another kind of API would be necessary here? I'm
> thinking about something along the lines of:
>
>
> `asOutputStream(f: OutputStream => Done, writeTimeout: FiniteDuration
> = 5.seconds): Source[ByteString, Future[IOResult]]`
>
>
> `f` would be invoked after the stream is ready for writing. After `f`
> completes, the framework could ensure the stream is cleaned up properly.
> The returned `IOResult.status` could be used to check whether `f` 
> completed
> normally. If `f` fails to complete within specified timeout, any further
> attempt to call methods on the `OutputStream` should result in an
> `IOException`. The problem I see is that `f` could get permanently blocked
> on some condition and thus steal a thread from
> `akka.stream.blocking-io-dispatcher` but I don't think there is any
> way to handled that on the JVM.
>
>
> I am not sure if the above is feasible but if it were I'm sure people
> would find it useful for interfacing with legacy code ;)
>
>
> Cheers,
>
> Rafał
>
>
> [1] https://doc.akka.io/docs/akka/current/scala/stream/stages-ov
> erview.html#additional-sink-and-source-converters
>
> [2] https://poi.apache.org/spreadsheet/how-to.html#sxssf
>
> [3] https://poi.apache.org/apidocs/org/apache/poi/xssf/streaming
> /SXSSFWorkbook.html#write-java.io.OutputStream-
>
 --
>>> >> 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

Re: [akka-user] Re: Usage of StreamConverters.asOutputStream / possible alternative API?

[Viktor Klang]

Be careful though, as you need to ensure proper happens-before relationship
between the writes and the closing of the OutputStream. (and other writes
of course)

On Thu, Oct 26, 2017 at 1:56 PM, Rafał Krzewski 
wrote:

> That worked like a charm :) Thanks a lot Johan!
>
> Cheers,
> Rafał
>
> W dniu czwartek, 26 października 2017 10:49:52 UTC+2 użytkownik Johan
> Andrén napisał:
>>
>> Materialization is not async, so anything you do in mapMaterializedValue
>> will block the materialization. Simplest solution is to not run the logic
>> that feeds the OutputStream inside the materialization, but instead do that
>> by keeping the materialized value through your chain of stages, and getting
>> it as the returned value from run(). In some cases, maybe yours, you cannot
>> do that because you are passing the blueprint to some API that will do the
>> actual materialization, in that case you can instead fork off a
>> future/thread to do the writing, to let the materialization complete.
>>
>> Something like this:
>>
>>   def legacySource =
>> StreamConverters.asOutputStream()
>>   .mapMaterializedValue { outputstream =>
>> Future {
>>   while(something) {
>> outputstream.write(data)
>>   }
>> }(use-a-blocking-specific-dispatcher-here-as-write-is-blocking)
>> NotUsed
>>   }
>>
>>   val route = get {
>> complete {
>>   HttpEntity(
>> ContentTypes.`application/octet-stream`,
>> legacySource
>>   )
>> }
>>   }
>>
>> --
>> Johan
>> Akka Team
>>
>> On Wednesday, October 25, 2017 at 1:42:58 PM UTC+2, Rafał Krzewski wrote:
>>>
>>> Hi,
>>>
>>> I've tried using `StreamConverters.asOutputStream` and immediately run
>>> into the deadlock described in the documentation [1]
>>>
>>> My use case is that I am am creating Excel spreadsheet using Apache
>>> POI's streaming API [2] and then stream out the result using Akka HTTP.
>>>
>>> Under the hood POI is writing the row data into a temporary files on
>>> disk. When all data is ready, one can write out the result to an arbitrary
>>> `OutputStream` [3].
>>>
>>> When interoperating with Akka HTTP I need to provide a `Source` that is
>>> materialized by the framework. That's why my intuition was using
>>> `mapMaterializedValue` to provide the code making use of the `OutputStream`
>>> at the site when I'm creating the source. Unfortunately this does not work.
>>> I was able to work around that by writing out the spreadsheet to another
>>> temporary file, providing a `Source` to Akka HTTP side using `FileIO` and
>>> some additional song and dance to clean up the temporary files in all
>>> circumstances.
>>>
>>>
>>> I am wondering if there is a way I could use
>>> `StreamConverters.asOutputStream` correctly in this scenario that I
>>> don't see? Or maybe another kind of API would be necessary here? I'm
>>> thinking about something along the lines of:
>>>
>>>
>>> `asOutputStream(f: OutputStream => Done, writeTimeout: FiniteDuration =
>>> 5.seconds): Source[ByteString, Future[IOResult]]`
>>>
>>>
>>> `f` would be invoked after the stream is ready for writing. After `f`
>>> completes, the framework could ensure the stream is cleaned up properly.
>>> The returned `IOResult.status` could be used to check whether `f` completed
>>> normally. If `f` fails to complete within specified timeout, any further
>>> attempt to call methods on the `OutputStream` should result in an
>>> `IOException`. The problem I see is that `f` could get permanently blocked
>>> on some condition and thus steal a thread from
>>> `akka.stream.blocking-io-dispatcher` but I don't think there is any way
>>> to handled that on the JVM.
>>>
>>>
>>> I am not sure if the above is feasible but if it were I'm sure people
>>> would find it useful for interfacing with legacy code ;)
>>>
>>>
>>> Cheers,
>>>
>>> Rafał
>>>
>>>
>>> [1] https://doc.akka.io/docs/akka/current/scala/stream/stages-ov
>>> erview.html#additional-sink-and-source-converters
>>>
>>> [2] https://poi.apache.org/spreadsheet/how-to.html#sxssf
>>>
>>> [3] https://poi.apache.org/apidocs/org/apache/poi/xssf/streaming
>>> /SXSSFWorkbook.html#write-java.io.OutputStream-
>>>
>> --
> >> 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.h

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

[Viktor Klang]

On Wed, Oct 25, 2017 at 1:16 PM, Christopher Hunt  wrote:

>
>
> > 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...
>

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.


>
> --
> >>>>>>>>>>  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 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

[Viktor Klang]

Does it behave differently from
`Source.single(somePromise.future).mapAsync(1)(identity)` ?

On Wed, Oct 25, 2017 at 12:01 PM, Christopher Hunt 
wrote:

> 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.
>



-- 
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Spray->Akka-Http Migration - seeing high 99th percentile latencies post-migration

[Viktor Klang]

And you consume the entityBytes I presume?

On Mon, Oct 23, 2017 at 10:35 PM, Gary Malouf  wrote:

> It is from when I start the Kamon trace (just inside of my
> path("myawesomepath") declaration until (theoretically) a 'complete' call
> is made.
>
> path("myawesomepath") {
>   traceName("CoolStory") {
> ///do some stuff
>  complete("This is great")
> } }
>
> For what it's worth, this route is a 'POST' call.
>
> On Mon, Oct 23, 2017 at 4:30 PM, Viktor Klang 
> wrote:
>
>> No, I mean, is it from first-byte-received to last-byte-sent or what?
>>
>> On Mon, Oct 23, 2017 at 10:22 PM, Gary Malouf 
>> wrote:
>>
>>> We are using percentiles computed via Kamon 0.6.8.  In a very low
>>> request rate environment like this, it takes roughly 1 super slow
>>> request/second to throw off the percentiles (which is what I think is
>>> happening).
>>>
>>>
>>>
>>> On Mon, Oct 23, 2017 at 4:20 PM, Viktor Klang 
>>> wrote:
>>>
>>>> What definition of latency are you using? (i.e. how is it derived)
>>>>
>>>> On Mon, Oct 23, 2017 at 10:11 PM, Gary Malouf 
>>>> wrote:
>>>>
>>>>> Hi Konrad,
>>>>>
>>>>> Our real issue is that we can not reproduce the results.  The web
>>>>> server we are having latency issues with is under peak load of 10-15
>>>>> requests/second - obviously not much to deal with.
>>>>>
>>>>> When we use load tests (https://github.com/apigee/apib), it's easy
>>>>> for us to throw a few thousand requests/second at it and get latencies in
>>>>> the ~ 3 ms range.  We use kamon to track internal metrics - what we see is
>>>>> that our 95th and 99th percentiles only look bad under the production
>>>>> traffic but not under load tests.
>>>>>
>>>>> I've since used kamon to print out the actual requests trying to find
>>>>> any pattern in them to hint at what's wrong in my own code, but they seem
>>>>> to be completely random.  What we do know is that downgrading to spray 
>>>>> gets
>>>>> us 99.9th percentile latencies under 2ms, so something related to the
>>>>> upgrade is allowing this.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Gary
>>>>>
>>>>> On Tuesday, October 17, 2017 at 12:07:51 PM UTC-4, Konrad Malawski
>>>>> wrote:
>>>>>>
>>>>>> Step 1 – don’t panic ;-)
>>>>>> Step 2 – as I already asked for, please share actual details of the
>>>>>> benchmarks. It is not good to discuss benchmarks without any insight into
>>>>>> what / how exactly you’re measuring.
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Konrad 'ktoso <http://kto.so>' Malawski
>>>>>> Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>
>>>>>>
>>>>>> On October 12, 2017 at 15:31:19, Gary Malouf (malou...@gmail.com)
>>>>>> wrote:
>>>>>>
>>>>>> We have a web service that we just finished migrating from spray 1.3
>>>>>> to Akka-Http 10.0.9.  While in most cases it is performing well, we are
>>>>>> seeing terrible 99th percentile latencies 300-450ms range) starting from 
>>>>>> a
>>>>>> very low request rate (10/second) on an ec2 m3.large.
>>>>>>
>>>>>> Our service does not do anything complicated - it does a few Map
>>>>>> lookups and returns a response to a request.  In spray, even 99th
>>>>>> percentile latencies were on the order of 1-3 ms, so we are definitely
>>>>>> concerned.  Connections as with many pixel-type servers are short-lived 
>>>>>> ->
>>>>>> we actually pass the Connection: Close header intentionally in our
>>>>>> responses.
>>>>>>
>>>>>> Is there any obvious tuning that should be done on the server
>>>>>> configuration that others have found?
>>>>>> --
>>>>>> >>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>> >>>>>>>>>> Check the FAQ: http://doc.akka.io/docs/akka/c
>>>>>> urrent/additional/

Re: [akka-user] Spray->Akka-Http Migration - seeing high 99th percentile latencies post-migration

[Viktor Klang]

No, I mean, is it from first-byte-received to last-byte-sent or what?

On Mon, Oct 23, 2017 at 10:22 PM, Gary Malouf  wrote:

> We are using percentiles computed via Kamon 0.6.8.  In a very low request
> rate environment like this, it takes roughly 1 super slow request/second to
> throw off the percentiles (which is what I think is happening).
>
>
>
> On Mon, Oct 23, 2017 at 4:20 PM, Viktor Klang 
> wrote:
>
>> What definition of latency are you using? (i.e. how is it derived)
>>
>> On Mon, Oct 23, 2017 at 10:11 PM, Gary Malouf 
>> wrote:
>>
>>> Hi Konrad,
>>>
>>> Our real issue is that we can not reproduce the results.  The web server
>>> we are having latency issues with is under peak load of 10-15
>>> requests/second - obviously not much to deal with.
>>>
>>> When we use load tests (https://github.com/apigee/apib), it's easy for
>>> us to throw a few thousand requests/second at it and get latencies in the ~
>>> 3 ms range.  We use kamon to track internal metrics - what we see is that
>>> our 95th and 99th percentiles only look bad under the production traffic
>>> but not under load tests.
>>>
>>> I've since used kamon to print out the actual requests trying to find
>>> any pattern in them to hint at what's wrong in my own code, but they seem
>>> to be completely random.  What we do know is that downgrading to spray gets
>>> us 99.9th percentile latencies under 2ms, so something related to the
>>> upgrade is allowing this.
>>>
>>> Thanks,
>>>
>>> Gary
>>>
>>> On Tuesday, October 17, 2017 at 12:07:51 PM UTC-4, Konrad Malawski wrote:
>>>>
>>>> Step 1 – don’t panic ;-)
>>>> Step 2 – as I already asked for, please share actual details of the
>>>> benchmarks. It is not good to discuss benchmarks without any insight into
>>>> what / how exactly you’re measuring.
>>>>
>>>> --
>>>> Cheers,
>>>> Konrad 'ktoso <http://kto.so>' Malawski
>>>> Akka <http://akka.io/> @ Lightbend <http://lightbend.com/>
>>>>
>>>> On October 12, 2017 at 15:31:19, Gary Malouf (malou...@gmail.com)
>>>> wrote:
>>>>
>>>> We have a web service that we just finished migrating from spray 1.3 to
>>>> Akka-Http 10.0.9.  While in most cases it is performing well, we are seeing
>>>> terrible 99th percentile latencies 300-450ms range) starting from a very
>>>> low request rate (10/second) on an ec2 m3.large.
>>>>
>>>> Our service does not do anything complicated - it does a few Map
>>>> lookups and returns a response to a request.  In spray, even 99th
>>>> percentile latencies were on the order of 1-3 ms, so we are definitely
>>>> concerned.  Connections as with many pixel-type servers are short-lived ->
>>>> we actually pass the Connection: Close header intentionally in our
>>>> responses.
>>>>
>>>> Is there any obvious tuning that should be done on the server
>>>> configuration that others have found?
>>>> --
>>>> >>>>>>>>>> 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 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/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

Re: [akka-user] Spray->Akka-Http Migration - seeing high 99th percentile latencies post-migration

[Viktor Klang]

What definition of latency are you using? (i.e. how is it derived)

On Mon, Oct 23, 2017 at 10:11 PM, Gary Malouf  wrote:

> Hi Konrad,
>
> Our real issue is that we can not reproduce the results.  The web server
> we are having latency issues with is under peak load of 10-15
> requests/second - obviously not much to deal with.
>
> When we use load tests (https://github.com/apigee/apib), it's easy for us
> to throw a few thousand requests/second at it and get latencies in the ~ 3
> ms range.  We use kamon to track internal metrics - what we see is that our
> 95th and 99th percentiles only look bad under the production traffic but
> not under load tests.
>
> I've since used kamon to print out the actual requests trying to find any
> pattern in them to hint at what's wrong in my own code, but they seem to be
> completely random.  What we do know is that downgrading to spray gets us
> 99.9th percentile latencies under 2ms, so something related to the upgrade
> is allowing this.
>
> Thanks,
>
> Gary
>
> On Tuesday, October 17, 2017 at 12:07:51 PM UTC-4, Konrad Malawski wrote:
>>
>> Step 1 – don’t panic ;-)
>> Step 2 – as I already asked for, please share actual details of the
>> benchmarks. It is not good to discuss benchmarks without any insight into
>> what / how exactly you’re measuring.
>>
>> --
>> Cheers,
>> Konrad 'ktoso ' Malawski
>> Akka  @ Lightbend 
>>
>> On October 12, 2017 at 15:31:19, Gary Malouf (malou...@gmail.com) wrote:
>>
>> We have a web service that we just finished migrating from spray 1.3 to
>> Akka-Http 10.0.9.  While in most cases it is performing well, we are seeing
>> terrible 99th percentile latencies 300-450ms range) starting from a very
>> low request rate (10/second) on an ec2 m3.large.
>>
>> Our service does not do anything complicated - it does a few Map lookups
>> and returns a response to a request.  In spray, even 99th percentile
>> latencies were on the order of 1-3 ms, so we are definitely concerned.
>> Connections as with many pixel-type servers are short-lived -> we actually
>> pass the Connection: Close header intentionally in our responses.
>>
>> Is there any obvious tuning that should be done on the server
>> configuration that others have found?
>> --
>> >> 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/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 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.
>



-- 
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Ask not working if Future is used in receive partial method

[Viktor Klang]

Hi Danny,

there are two problems:

1)
https://doc.akka.io/docs/akka/current/scala/additional/faq.html#sender-getsender-disappears-when-i-use-future-in-my-actor-why-

2)
https://doc.akka.io/docs/akka/current/scala/general/jmm.html#jmm-shared-state

Happy hakking!


On Fri, Oct 13, 2017 at 6:59 PM, Danny Lesnik 
wrote:

> I have the following stateful Actor
>
> class StudentActor extends Actor with ActorLogging{
>
>   var student:Student = Student(id,firstName,lastName)
>
>   implicit val executionContext = Try {
> context.system.dispatchers.lookup("blocking-code-dispatcher")
>   }.getOrElse(context.system.dispatcher)
>
>
>   override def receive = {
>
> case UpdateStudent(_, c) =>
>   Future[Student] {
>
> val updatedStudent = student.copy(counter = student.counter + c)
> student = updatedStudent
> log.info(sender().toString())
> updatedStudent
>   }(executionContext).map(updatedStudent => sender() ! updatedStudent)
>
> case GetStudent(id,_) => sender() ! student
>
>   }
> }
>
>
>
> When I try to use ask pattern to update this student from main method, I'm 
> receiving timeout
>
>
> holder.ask(UpdateStudent("1")).mapTo[Student].foreach(println(_))
>
>
> However, if I remove Future method and using the following code it works like 
> charm:
>
>
>   case UpdateStudent(_, c) =>val updatedStudent = 
> student.copy(counter = student.counter + c)
>
> student = updatedStudent
> log.info(sender().toString())
> updatedStudent
>
> sender() ! updatedStudent
>
>
> Why using Future in partial method causes ask timeout?
>
> I believe this is something stupid, but I can't figure it out :)
>
> --
> >> 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 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] Using zip with mapAsyncUnordered

[Viktor Klang]

 Hi Ori,

The answer is: it is allowed for the materializer, dispatcher, JVM, OS
Scheduler to allow for elements produced by the mapAsyncUnordered to be
reordered—it doesn't mean that they will sometimes, will always, will
never, etc.

If you don't want possible reordering, use mapAsync.

Cheers,
√

On Sat, 26 Aug 2017 at 17:11, Ori Popowski  wrote:

>
> Hi,
>
> Say that I have a stream with a consecutive integers source (1, 2, 3 ...),
> and assume that toString returns a Future[String]:
>
> source ~> bcast ~> toString.mapAsyncUnordered(8)(identity) ~> zip.in0
>   bcast ~>zip.in1
>   zip.out ~>
> sink
>
> My question is if mapAsyncUnordered will cause a shuffling, or will every
> integer will be paired with its own toString representation?
>
> Will the result be this:
>
> "1" -> 1
> "2" -> 2
> "3" -> 3
> ...
>
>
>
> or more like this:
>
> "1" -> 7
> "2" -> 1
> "3" -> 3
> ...
>
>
>
> --
> >> 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 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] problem with pinned dispatcher

[Viktor Klang]

«Note that it’s not guaranteed that the *same* thread is used over time,
since the core pool timeout is used for PinnedDispatcher to keep resource
usage down in case of idle actors. To use the same thread all the time you
need to add thread-pool-executor.allow-core-timeout=off to the
configuration of the PinnedDispatcher.»

http://doc.akka.io/docs/akka/current/scala/dispatchers.html#types-of-dispatchers


On Tue, Aug 1, 2017 at 5:04 PM, mc  wrote:

> Hello,
>
> I'm trying to use PinnedDispatcher using the following configuration (in
> application.conf):
>
> app {
> pinnedDispatcher {
> type = "PinnedDispatcher"
> executor = "thread-pool-executor"
> thread-pool-executor.allow-
> core-timeout = off
> thread-pool-executor {
> core-pool-size-min = 2
> core-pool-size-factor = 2.0
> core-pool-size-max = 4
> }
> throughput = 1
> }
> }
>
> akka.actor.deployment {
> /master/worker {
> dispatcher = app.pinnedDispatcher
> router = round-robin-pool
> }
> }
>
> This is my code for creating worker pool (inside MyMaster actor called
> "master"):
>   private lazy val worker = context.actorOf(FromConfig.props(Props[MyWorker]),
> "worker")
>
> Worker actors are receiving messages but it looks like actors created on
> one thread are later executed on another thread.
> Is my configuration incorrect? I thought that using pinned dispatcher
> would guarantee that an actor created on a thread would later be always
> called from that same thread.
> I'd appreciate any help with this problem.
> Thanks,
>
> M
>
> --
> >> 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 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] [ANNOUNCE] ChanaMQ - an Akka based AMQP messaging broker

[Viktor Klang]

Would be interesting to see if the new AffinityPool would make any
difference.

On Thu, Jul 27, 2017 at 10:44 PM, Caoyuan  wrote:

>
>
> On Thursday, July 27, 2017 at 12:47:39 PM UTC-7, √ wrote:
>>
>> Very consistent. What's the current bottleneck?
>>
>
> Not too much so far. The major decision of ChanaMQ design is that each
> message is an actor and each queue is an actor etc. So the scalability on
> number of CPU cores or cluster nodes should be well. I can see the CPU
> cores usages are balanced very well.
>
> The only issue is the fluctuated of send/receive rate under some cases,
> I'll try to figure out whether the cause is from client side or ChanaMQ
> server side.
>
>
>
>> On Thu, Jul 27, 2017 at 7:52 PM, Caoyuan  wrote:
>>
>>> Below is the latency in ms when applying 1-publishers - 100-consumers:
>>>
>>>
>>>   "max-latency":15.044784,
>>>   "min-latency":13.960142,
>>>   "avg-latency":14.623772,
>>>   "p95-latency":14.830327,
>>>   "p99-latency":14.884950,
>>>
>>> On Monday, July 24, 2017 at 11:30:04 PM UTC-7, √ wrote:

 Cool. What does the p90 and p99 look like?

 --
 Cheers,
 √

 On Jul 25, 2017 12:19 AM, "Caoyuan"  wrote:

> I've got some preliminary benchmarks. As the maximized distributed
> design of ChanaMQ. It's bit lagging behind RabbitMQ when applying a few
> publishers/consumers, but will be on par with RabbitMQ when applying lots
> of publishers/consumers.
>
> Attached are benchmarks on my dual Intel Xeon E5620@2.4GHz
>
> ChanaMQ is designed as a plain Akka sharding cluster, so it should
> scale out well, although I do not yet take a serious test on it.
>
> --
> Cheers
> Caoyuan Deng
>
> On Monday, July 24, 2017 at 12:36:27 AM UTC-7, √ wrote:
>>
>> Cool! What kind of scalability&performance profile are you getting?
>>
>> On Fri, Jul 21, 2017 at 9:20 PM, Caoyuan  wrote:
>>
>>> Hi,
>>>
>>> We are developing an AMQP messaging broker - ChanaMQ, which is based
>>> on Akka actors and Akka streaming.
>>>
>>> It's currently under Alpha phase, but with lots of AMQP 0-9-1
>>> features implemented, including ack, persistent (Cassandra only so far) 
>>> etc.
>>>
>>> Methods/Features are not supported yet:
>>>
>>>- Connection.SecureOk
>>>- Channel.Flow
>>>- Exchange.Bind / Exchange.Unbind
>>>- Basic.Reject / Basic.Nack / Basic.RecoverAsync / Basic.Recover
>>>- Access.Request
>>>- Tx.Select / Tx.Commit / Tx.Rollback
>>>- Confirm.Select
>>>- ...
>>>
>>> For more information, please visit:
>>>
>>> https://github.com/qingmang-team/chanamq
>>>
>>> Regards,
>>>
>>> Caoyuan Deng
>>> Qingmang  - Your magazine on mobile
>>> Twitter: @dcaoyuan
>>>
>>> --
>>> >> 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 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/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 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/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 https://groups.google.com/group/akka-user.

Re: [akka-user] [ANNOUNCE] ChanaMQ - an Akka based AMQP messaging broker

[Viktor Klang]

Very consistent. What's the current bottleneck?

On Thu, Jul 27, 2017 at 7:52 PM, Caoyuan  wrote:

> Below is the latency in ms when applying 1-publishers - 100-consumers:
>
>
>   "max-latency":15.044784,
>   "min-latency":13.960142,
>   "avg-latency":14.623772,
>   "p95-latency":14.830327,
>   "p99-latency":14.884950,
>
> On Monday, July 24, 2017 at 11:30:04 PM UTC-7, √ wrote:
>>
>> Cool. What does the p90 and p99 look like?
>>
>> --
>> Cheers,
>> √
>>
>> On Jul 25, 2017 12:19 AM, "Caoyuan"  wrote:
>>
>>> I've got some preliminary benchmarks. As the maximized distributed
>>> design of ChanaMQ. It's bit lagging behind RabbitMQ when applying a few
>>> publishers/consumers, but will be on par with RabbitMQ when applying lots
>>> of publishers/consumers.
>>>
>>> Attached are benchmarks on my dual Intel Xeon E5620@2.4GHz
>>>
>>> ChanaMQ is designed as a plain Akka sharding cluster, so it should scale
>>> out well, although I do not yet take a serious test on it.
>>>
>>> --
>>> Cheers
>>> Caoyuan Deng
>>>
>>> On Monday, July 24, 2017 at 12:36:27 AM UTC-7, √ wrote:

 Cool! What kind of scalability&performance profile are you getting?

 On Fri, Jul 21, 2017 at 9:20 PM, Caoyuan  wrote:

> Hi,
>
> We are developing an AMQP messaging broker - ChanaMQ, which is based
> on Akka actors and Akka streaming.
>
> It's currently under Alpha phase, but with lots of AMQP 0-9-1 features
> implemented, including ack, persistent (Cassandra only so far) etc.
>
> Methods/Features are not supported yet:
>
>- Connection.SecureOk
>- Channel.Flow
>- Exchange.Bind / Exchange.Unbind
>- Basic.Reject / Basic.Nack / Basic.RecoverAsync / Basic.Recover
>- Access.Request
>- Tx.Select / Tx.Commit / Tx.Rollback
>- Confirm.Select
>- ...
>
> For more information, please visit:
>
> https://github.com/qingmang-team/chanamq
>
> Regards,
>
> Caoyuan Deng
> Qingmang  - Your magazine on mobile
> Twitter: @dcaoyuan
>
> --
> >> 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 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/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 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.
>



-- 
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] [ANNOUNCE] ChanaMQ - an Akka based AMQP messaging broker

[Viktor Klang]

Cool. What does the p90 and p99 look like?

-- 
Cheers,
√

On Jul 25, 2017 12:19 AM, "Caoyuan"  wrote:

> I've got some preliminary benchmarks. As the maximized distributed design
> of ChanaMQ. It's bit lagging behind RabbitMQ when applying a few
> publishers/consumers, but will be on par with RabbitMQ when applying lots
> of publishers/consumers.
>
> Attached are benchmarks on my dual Intel Xeon E5620@2.4GHz
>
> ChanaMQ is designed as a plain Akka sharding cluster, so it should scale
> out well, although I do not yet take a serious test on it.
>
> --
> Cheers
> Caoyuan Deng
>
> On Monday, July 24, 2017 at 12:36:27 AM UTC-7, √ wrote:
>>
>> Cool! What kind of scalability&performance profile are you getting?
>>
>> On Fri, Jul 21, 2017 at 9:20 PM, Caoyuan  wrote:
>>
>>> Hi,
>>>
>>> We are developing an AMQP messaging broker - ChanaMQ, which is based on
>>> Akka actors and Akka streaming.
>>>
>>> It's currently under Alpha phase, but with lots of AMQP 0-9-1 features
>>> implemented, including ack, persistent (Cassandra only so far) etc.
>>>
>>> Methods/Features are not supported yet:
>>>
>>>- Connection.SecureOk
>>>- Channel.Flow
>>>- Exchange.Bind / Exchange.Unbind
>>>- Basic.Reject / Basic.Nack / Basic.RecoverAsync / Basic.Recover
>>>- Access.Request
>>>- Tx.Select / Tx.Commit / Tx.Rollback
>>>- Confirm.Select
>>>- ...
>>>
>>> For more information, please visit:
>>>
>>> https://github.com/qingmang-team/chanamq
>>>
>>> Regards,
>>>
>>> Caoyuan Deng
>>> Qingmang  - Your magazine on mobile
>>> Twitter: @dcaoyuan
>>>
>>> --
>>> >> 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 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 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] [ANNOUNCE] ChanaMQ - an Akka based AMQP messaging broker

[Viktor Klang]

Cool! What kind of scalability&performance profile are you getting?

On Fri, Jul 21, 2017 at 9:20 PM, Caoyuan  wrote:

> Hi,
>
> We are developing an AMQP messaging broker - ChanaMQ, which is based on
> Akka actors and Akka streaming.
>
> It's currently under Alpha phase, but with lots of AMQP 0-9-1 features
> implemented, including ack, persistent (Cassandra only so far) etc.
>
> Methods/Features are not supported yet:
>
>- Connection.SecureOk
>- Channel.Flow
>- Exchange.Bind / Exchange.Unbind
>- Basic.Reject / Basic.Nack / Basic.RecoverAsync / Basic.Recover
>- Access.Request
>- Tx.Select / Tx.Commit / Tx.Rollback
>- Confirm.Select
>- ...
>
> For more information, please visit:
>
> https://github.com/qingmang-team/chanamq
>
> Regards,
>
> Caoyuan Deng
> Qingmang  - Your magazine on mobile
> Twitter: @dcaoyuan
>
> --
> >> 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 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] remoting comparison: Artery vs Netty

[Viktor Klang]

Likely bottlenecked either by network or serialization method (or quite
possibly both?).

-- 
Cheers,
√

On Jul 3, 2017 1:06 PM, "Patrik Nordwall"  wrote:

> What is the unit of the values in the table, e.g. 416? I guess it's
> milliseconds?
>
> That doesn't match our tests
> 
> at all. We have measured 800k msg/s for the 100 byte payload.
>
> I'd recommend that you use something bigger than micro instances.
> Corresponding to 4 cores at least. I don't know how much the far apart
> regions matters, we have only tried in same zone.
>
> On Mon, Jul 3, 2017 at 11:42 AM, 'Kostiantyn Gorustovych' via Akka User
> List  wrote:
>
>> Hi guys. We are migrating our application from akka 2.4 to 2.5 and among
>> other there is new remoting available.
>> The throughput Before switching from netty to artery we decided to
>> compare them.
>>
>> So I created the app with two modules: sender & receiver with 16 remote
>> actors spawned by sender on receiver side.
>> The finished transmission is that one in which the payload delivered to
>> receiver and message id returned to sender.
>>
>> The tests implemented as a series of messaging batches. Each batch
>> consisted of 1000 message transmissions of K bytes (per message).
>> I tested it with messages of 100 byte, 1000 byte, 1 byte with
>> different idle-cpu-level.
>> With 100 byte message the artery's throughput looks better than netty's
>> (up to 26%), but for the rest it seems that netty beat artery (40% for 1k
>> message and 60% for 10k message).
>>
>> Some info about test execution:
>> - warm up the system with 50 batches of 100 bytes messages;
>> - measure the average for 100 batches of 100 bytes messages;
>> - measure the average for 50 batches of 1000 bytes messages;
>> - measure the average for 115 batches of 1 bytes messages;
>>
>> I tested it on AWS micro instances in different regions.
>>
>> Is it expected results?
>>
>> idle-cpu-level is represented as Artery X, e.g. Artery 1
>> AWS micro instances (singapore ↔ frankfurt)
>> messages / bytes per message Artery 1 Artery 3 Artery 5 Artery 7 Artery 9 
>> Artery
>> 10 Netty
>> 1k / 100 441 400 416 445 466 969 543
>> 1k / 1k 1655 1671 1674 1790 1755 3728 1217
>> 1k / 10k 14005 15237 19142 19463 20833 37539 8565
>>
>> --
>> >> 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/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 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] Is ExecutionContext.reportFailure working?

[Viktor Klang]

happy hakking!

On Tue, Jun 20, 2017 at 10:32 PM, Sean Shubin  wrote:

> Regarding #1, that is the information I was missing, thank you for
> clearing that up.  Hopefully that will guide me to how to test asynchronous
> code with an synchronous execution context.
>
> Regarding #2 and #3, I agree, I was just trying to figure out what was
> going on.  The reportFailure behavior was surprising to me, so I was
> guarding against other surprises.
>
> On Tuesday, June 20, 2017 at 1:01:09 AM UTC-7, √ wrote:
>>
>> Hi Sean,
>>
>> On Tue, Jun 20, 2017 at 12:51 AM, Sean Shubin  wrote:
>>
>>> While I was trying to stub out an execution context to test concurrent
>>> code, I noticed some surprising behavior demonstrated below.  I would have
>>> expected the exception thrown by the Future to cause reportFailure to be
>>> invoked.  To my surprise, reportFailure never got called at all, and the
>>> runnable.run() method carried on like nothing happened, even though an
>>> exception was thrown.  Obviously the code block run by the future is being
>>> wrapped by a runnable at some point, the surprising thing is that it seems
>>> to be handling the exception in a way that never notifies the reportFailure
>>> method.  I am having a hard time figuring it out from the source code, so
>>> was hoping someone more familiar with the scala.concurrent library could
>>> help me understand what is going on here.  My eventual goal is to be able
>>> to unit-test concurrent code by having tests take control of when different
>>> futures are launched and resolved.  That way I can resolve futures in
>>> different orders and make sure the code is correct no matter how the thread
>>> scheduler happens to fire off the futures.
>>>
>>> import java.util.concurrent.TimeUnit
>>>
>>> import org.scalatest.FunSuite
>>>
>>> import scala.concurrent.duration.Duration
>>> import scala.concurrent.{Await, ExecutionContext, Future}
>>>
>>> class PrototypeForStubbingExecutionContext extends FunSuite {
>>>   test("foo") {
>>> implicit val executionContext = new ExecutionContext {
>>>   override def execute(runnable: Runnable): Unit = {
>>> println("a")
>>> runnable.run()
>>> println("d")
>>>   }
>>>
>>>   override def reportFailure(cause: Throwable): Unit = {
>>> println("e")
>>> cause.printStackTrace()
>>> throw cause
>>>   }
>>> }
>>> val x = Future {
>>>   println("b")
>>>   throw new RuntimeException("boo!")
>>>   println("c")
>>> }(executionContext)
>>> Await.ready(x, Duration(1, TimeUnit.SECONDS))
>>> println(x)
>>>   }
>>> }
>>>
>>
>> There are several issues with the code above,
>>
>> 1: `reportFailure` is only invoked if there is nowhere else to send the
>> exception, in the case of Future if it is possible to complete the end
>> result with the failure.
>>
>> 2: `reportFailure` should most definitely not throw exceptions, the only
>> reason it was invoked was that there was nowhere else to pass the original
>> exception, so rethrowing from it make little-to-no-sense at all.
>>
>> 3: Await.ready for logic executed on a synchronous EC seems superfluous?
>>
>> You can see the `reportFailure` be invoked in for instance, `andThen`
>> throws an exception:
>>
>> scala> Future(1).andThen({ case _ => throw null }).foreach(println)
>> java.lang.NullPointerException
>> at $line11.$read$$iw$$iw$$iw$$iw$$iw$$iw$$anonfun$1.applyOrElse
>> (:18)
>> at $line11.$read$$iw$$iw$$iw$$iw$$iw$$iw$$anonfun$1.applyOrElse
>> (:18)
>> at scala.concurrent.Future.$anonfun$andThen$1(Future.scala:531)
>> at scala.concurrent.impl.Promise.liftedTree1$1(Promise.scala:29)
>> at scala.concurrent.impl.Promise.$anonfun$transform$1(Promise.scala:29)
>> at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:60)
>> at scala.concurrent.impl.ExecutionContextImpl$AdaptedForkJoinTa
>> sk.exec(ExecutionContextImpl.scala:140)
>> at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
>> at java.util.concurrent.ForkJoinPool$WorkQueue.pollAndExecAll(
>> ForkJoinPool.java:1021)
>> at java.util.concurrent.ForkJoinPool$WorkQueue.execLocalTasks(
>> ForkJoinPool.java:1046)
>> at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(
>> ForkJoinPool.java:1058)
>> at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
>> at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorker
>> Thread.java:157)
>> 1
>>
>>
>>>
>>> Output
>>>
>>> a
>>> b
>>> d
>>> Future(Failure(java.lang.RuntimeException: boo!))
>>>
>>> --
>>> >> 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 u

Re: [akka-user] Is ExecutionContext.reportFailure working?

[Viktor Klang]

Hi Sean,

On Tue, Jun 20, 2017 at 12:51 AM, Sean Shubin  wrote:

> While I was trying to stub out an execution context to test concurrent
> code, I noticed some surprising behavior demonstrated below.  I would have
> expected the exception thrown by the Future to cause reportFailure to be
> invoked.  To my surprise, reportFailure never got called at all, and the
> runnable.run() method carried on like nothing happened, even though an
> exception was thrown.  Obviously the code block run by the future is being
> wrapped by a runnable at some point, the surprising thing is that it seems
> to be handling the exception in a way that never notifies the reportFailure
> method.  I am having a hard time figuring it out from the source code, so
> was hoping someone more familiar with the scala.concurrent library could
> help me understand what is going on here.  My eventual goal is to be able
> to unit-test concurrent code by having tests take control of when different
> futures are launched and resolved.  That way I can resolve futures in
> different orders and make sure the code is correct no matter how the thread
> scheduler happens to fire off the futures.
>
> import java.util.concurrent.TimeUnit
>
> import org.scalatest.FunSuite
>
> import scala.concurrent.duration.Duration
> import scala.concurrent.{Await, ExecutionContext, Future}
>
> class PrototypeForStubbingExecutionContext extends FunSuite {
>   test("foo") {
> implicit val executionContext = new ExecutionContext {
>   override def execute(runnable: Runnable): Unit = {
> println("a")
> runnable.run()
> println("d")
>   }
>
>   override def reportFailure(cause: Throwable): Unit = {
> println("e")
> cause.printStackTrace()
> throw cause
>   }
> }
> val x = Future {
>   println("b")
>   throw new RuntimeException("boo!")
>   println("c")
> }(executionContext)
> Await.ready(x, Duration(1, TimeUnit.SECONDS))
> println(x)
>   }
> }
>

There are several issues with the code above,

1: `reportFailure` is only invoked if there is nowhere else to send the
exception, in the case of Future if it is possible to complete the end
result with the failure.

2: `reportFailure` should most definitely not throw exceptions, the only
reason it was invoked was that there was nowhere else to pass the original
exception, so rethrowing from it make little-to-no-sense at all.

3: Await.ready for logic executed on a synchronous EC seems superfluous?

You can see the `reportFailure` be invoked in for instance, `andThen`
throws an exception:

scala> Future(1).andThen({ case _ => throw null }).foreach(println)
java.lang.NullPointerException
at
$line11.$read$$iw$$iw$$iw$$iw$$iw$$iw$$anonfun$1.applyOrElse(:18)
at
$line11.$read$$iw$$iw$$iw$$iw$$iw$$iw$$anonfun$1.applyOrElse(:18)
at scala.concurrent.Future.$anonfun$andThen$1(Future.scala:531)
at scala.concurrent.impl.Promise.liftedTree1$1(Promise.scala:29)
at scala.concurrent.impl.Promise.$anonfun$transform$1(Promise.scala:29)
at scala.concurrent.impl.CallbackRunnable.run(Promise.scala:60)
at
scala.concurrent.impl.ExecutionContextImpl$AdaptedForkJoinTask.exec(ExecutionContextImpl.scala:140)
at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
at
java.util.concurrent.ForkJoinPool$WorkQueue.pollAndExecAll(ForkJoinPool.java:1021)
at
java.util.concurrent.ForkJoinPool$WorkQueue.execLocalTasks(ForkJoinPool.java:1046)
at
java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1058)
at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
at
java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
1


>
> Output
>
> a
> b
> d
> Future(Failure(java.lang.RuntimeException: boo!))
>
> --
> >> 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 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

Re: [akka-user] Role of Akka in SMACK

[Viktor Klang]

On Fri, Apr 28, 2017 at 4:52 PM, Shiva Ramagopal  wrote:

> Viktor,
>
>
> On Fri, Apr 28, 2017 at 5:03 PM, Viktor Klang 
> wrote:
>
>>
>>
>> On Fri, Apr 28, 2017 at 1:12 PM, Shiva Ramagopal 
>> wrote:
>>
>>> Hi Viktor,
>>>
>>> On Fri, Apr 28, 2017 at 2:55 PM, Viktor Klang 
>>> wrote:
>>>
>>>> Hi Shiva,
>>>>
>>>> On Fri, Apr 28, 2017 at 11:20 AM, Shiva Ramagopal 
>>>> wrote:
>>>>
>>>>> I'm looking to compare Kafka Streams vs Akka Streams in two areas:
>>>>>
>>>>> 1. For ingesting between Kafka and HDFS/RDBMS
>>>>>
>>>>> Requirements are mainly around performance and latency. A Kafka topic
>>>>> can have several million events, each corresponding to a database change
>>>>> capture. When ingesting this topic into HDFS I'm also looking to partition
>>>>> the data by day, typically based on a timestamp field in the event record,
>>>>> aggregations on-the-fly (say by a userid field) and parquetizing
>>>>> (preferably on the fly to optimize performance by reducing two I/O
>>>>> operations).
>>>>>
>>>>
>>>> Looking forward to see your benchmark!
>>>>
>>>
>>> Hey, you wanted requirements! :)
>>>
>>>>
>>>>
>>>>>
>>>>> 2. Low-latency processing
>>>>>
>>>>> Experiences around performances of Storm/Flink and Akka Streams would
>>>>> be *very* nice. Typical use-cases are de-duping and enrichment with 
>>>>> metrics
>>>>> computation (# duplicate events/records, aggregate metrics etc). Low
>>>>> latency and scalability are main considerations
>>>>>
>>>>
>>>> Low latency is not a metric, and scalability is not a profile. :)
>>>> In other words: What latency distribution are you targeting and what
>>>> scalability curve?
>>>>
>>>
>>> I know latency is a nuanced topic. I'm just looking for broad
>>> experiences on performance comparisons if anyone has done that. Currently
>>> we have a Storm topology over 5 nodes doing enrichment of events from Kafka
>>> that involves a lookup into a db per event. 90th percentile of latency of
>>> this processing is under 200 ms and we are happy with this. While Storm is
>>> mature, Akka Streams seems more general purpose than Storm. I'd like to use
>>> Akka Streams for this reason if performance is comparable to Storm.
>>>
>>
>> There's one important architectural difference here tho: Akka Streams are
>> local-only (as in materialization). You can of course materialize Akka
>> Streams on multiple nodes and use a transport to coordinate data
>> processing. Interestingly it doesn't lock you in to a particular backend
>> such that Kafka Streams or even Storm would do.
>>
>
> The materialization part was something I was not aware of. Thanks for
> pointing it out, really appreciate it.
>

You're most welcome


>
>> All of this boils down to requirements. Something like Flink or Google
>> Beam could be viable options here as well. In your situation I'd look at
>> the requirements and make a couple of prototypes before picking a winner.
>>
>
> I was also looking for something to unify batch and streaming - which is
> how I came to look at SMACK. I'd really like to keep the tech stack small
> and have the parts integrate tightly with each other. Guess I have to pick
> between Spark, Flink, Beam and Storm.
>

Sounds like a fun exercise :)


>
>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>> On Thu, Apr 27, 2017 at 8:31 PM, Viktor Klang 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Apr 27, 2017 at 10:39 AM, Shiva Ramagopal 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have read through multiple articles describing the SMACK stack but
>>>>>>> I'm having difficulty understanding the role of Akka in the stack. How 
>>>>>>> does
>>>>>>> Akka fit in?
>>>>>>>
>>>>>>
>>>>>> Akka is for building the application itself.
>>>>>>
>>>>>>
>>>>>>>
>>&

Re: [akka-user] Role of Akka in SMACK

[Viktor Klang]

On Fri, Apr 28, 2017 at 1:12 PM, Shiva Ramagopal  wrote:

> Hi Viktor,
>
> On Fri, Apr 28, 2017 at 2:55 PM, Viktor Klang 
> wrote:
>
>> Hi Shiva,
>>
>> On Fri, Apr 28, 2017 at 11:20 AM, Shiva Ramagopal 
>> wrote:
>>
>>> I'm looking to compare Kafka Streams vs Akka Streams in two areas:
>>>
>>> 1. For ingesting between Kafka and HDFS/RDBMS
>>>
>>> Requirements are mainly around performance and latency. A Kafka topic
>>> can have several million events, each corresponding to a database change
>>> capture. When ingesting this topic into HDFS I'm also looking to partition
>>> the data by day, typically based on a timestamp field in the event record,
>>> aggregations on-the-fly (say by a userid field) and parquetizing
>>> (preferably on the fly to optimize performance by reducing two I/O
>>> operations).
>>>
>>
>> Looking forward to see your benchmark!
>>
>
> Hey, you wanted requirements! :)
>
>>
>>
>>>
>>> 2. Low-latency processing
>>>
>>> Experiences around performances of Storm/Flink and Akka Streams would be
>>> *very* nice. Typical use-cases are de-duping and enrichment with metrics
>>> computation (# duplicate events/records, aggregate metrics etc). Low
>>> latency and scalability are main considerations
>>>
>>
>> Low latency is not a metric, and scalability is not a profile. :)
>> In other words: What latency distribution are you targeting and what
>> scalability curve?
>>
>
> I know latency is a nuanced topic. I'm just looking for broad experiences
> on performance comparisons if anyone has done that. Currently we have a
> Storm topology over 5 nodes doing enrichment of events from Kafka that
> involves a lookup into a db per event. 90th percentile of latency of this
> processing is under 200 ms and we are happy with this. While Storm is
> mature, Akka Streams seems more general purpose than Storm. I'd like to use
> Akka Streams for this reason if performance is comparable to Storm.
>

There's one important architectural difference here tho: Akka Streams are
local-only (as in materialization). You can of course materialize Akka
Streams on multiple nodes and use a transport to coordinate data
processing. Interestingly it doesn't lock you in to a particular backend
such that Kafka Streams or even Storm would do.

All of this boils down to requirements. Something like Flink or Google Beam
could be viable options here as well. In your situation I'd look at the
requirements and make a couple of prototypes before picking a winner.


>
>
>>
>>
>>>
>>> On Thu, Apr 27, 2017 at 8:31 PM, Viktor Klang 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Thu, Apr 27, 2017 at 10:39 AM, Shiva Ramagopal 
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I have read through multiple articles describing the SMACK stack but
>>>>> I'm having difficulty understanding the role of Akka in the stack. How 
>>>>> does
>>>>> Akka fit in?
>>>>>
>>>>
>>>> Akka is for building the application itself.
>>>>
>>>>
>>>>>
>>>>> Also I would like to know of experiences in using Akka Streams vs
>>>>> Kafka Connect for ingesting from Kafka into HDFS (Hive) and RDBMS. Has
>>>>> anyone used Akka Streams for say, dynamic partitioning of events from a
>>>>> Kafka topic into HDFS?
>>>>>
>>>>
>>>> Based on what requirements?
>>>>
>>>>
>>>>>
>>>>> TIA
>>>>> -Shiva
>>>>>
>>>>> --
>>>>> >>>>>>>>>> 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+unsubscr...@googlegroups.com.
>>>>> To post to this group, send email to akka-user@googlegroups.com.
>>>>> Visit this group at https://groups.google

Re: [akka-user] Role of Akka in SMACK

[Viktor Klang]

Hi Shiva,

On Fri, Apr 28, 2017 at 11:20 AM, Shiva Ramagopal  wrote:

> I'm looking to compare Kafka Streams vs Akka Streams in two areas:
>
> 1. For ingesting between Kafka and HDFS/RDBMS
>
> Requirements are mainly around performance and latency. A Kafka topic can
> have several million events, each corresponding to a database change
> capture. When ingesting this topic into HDFS I'm also looking to partition
> the data by day, typically based on a timestamp field in the event record,
> aggregations on-the-fly (say by a userid field) and parquetizing
> (preferably on the fly to optimize performance by reducing two I/O
> operations).
>

Looking forward to see your benchmark!


>
> 2. Low-latency processing
>
> Experiences around performances of Storm/Flink and Akka Streams would be
> *very* nice. Typical use-cases are de-duping and enrichment with metrics
> computation (# duplicate events/records, aggregate metrics etc). Low
> latency and scalability are main considerations
>

Low latency is not a metric, and scalability is not a profile. :)
In other words: What latency distribution are you targeting and what
scalability curve?


>
> On Thu, Apr 27, 2017 at 8:31 PM, Viktor Klang 
> wrote:
>
>>
>>
>> On Thu, Apr 27, 2017 at 10:39 AM, Shiva Ramagopal 
>> wrote:
>>
>>> Hi,
>>>
>>> I have read through multiple articles describing the SMACK stack but I'm
>>> having difficulty understanding the role of Akka in the stack. How does
>>> Akka fit in?
>>>
>>
>> Akka is for building the application itself.
>>
>>
>>>
>>> Also I would like to know of experiences in using Akka Streams vs Kafka
>>> Connect for ingesting from Kafka into HDFS (Hive) and RDBMS. Has anyone
>>> used Akka Streams for say, dynamic partitioning of events from a Kafka
>>> topic into HDFS?
>>>
>>
>> Based on what requirements?
>>
>>
>>>
>>> TIA
>>> -Shiva
>>>
>>> --
>>> >>>>>>>>>> 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+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/c
>> urrent/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.
>



-- 
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Actor name is not unique after termination when running from unit tests

[Viktor Klang]

Hi Piotr,

the test thread having observed the termination does not mean that the user
guardian (/user) has observed it.

On Thu, Apr 27, 2017 at 4:53 PM, Piotr Droździel 
wrote:

> Hello,
> Akka docs say:
>
>> Warning
>>
>> Keep in mind that an actor stopping and its name being deregistered are
>> separate events which happen asynchronously from each other. Therefore it
>> may be that you will find the name still in use after gracefulStop() 
>> returned.
>> In order to guarantee proper deregistration, only reuse names from within a
>> supervisor you control and only in response to a Terminated message,
>> i.e. not for top-level actors.
>>
>
> But when testing one of the actors I get InvalidActorNameException even
> after expectTerminated was successful. This is the test:
>
>
> "stop self when finished" in {
>  val fetcher = system.actorOf(EventFetcherActor.props(eventId), "name1")
>
>  watch(fetcher)
>  // interact with the actor, it will call context.stop(self) after
> interaction
>  expectTerminated(fetcher)
>
>  system.actorOf(EventFetcherActor.props(eventId), "name1") //Exception
> thrown
> }
>
> 90% of times I run it, the test passes. But what is the reason of
> failures? Can it be related to the fact that it's unit test?
>
> This is exception message I get:
> actor name [name1] is not unique!
> akka.actor.InvalidActorNameException: actor name [name1] is not unique!
> at akka.actor.dungeon.ChildrenContainer$NormalChildrenContainer.
> reserve(ChildrenContainer.scala:129)
> at akka.actor.dungeon.Children$class.reserveChild(Children.scala:130)
> at akka.actor.ActorCell.reserveChild(ActorCell.scala:374)
> at akka.actor.dungeon.Children$class.makeChild(Children.scala:268)
> at akka.actor.dungeon.Children$class.attachChild(Children.scala:46)
>
> --
> >> 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 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 it possible to assure every message to be processed

[Viktor Klang]

Hi!

On Thu, Apr 27, 2017 at 9:08 AM, Laxmi Narayan  wrote:

> Hi ,
>
> I am working a high scalable application where I want to use akka as
> processing framework.
>
> But after reading not 100% guaranteed delivery I am actually afraid of
> using it.
>

Nothing in the world can guarantee 100% guaranteed delivery.


>
> I have checked supervision strategy  example but I am afraid of using it
> inside application.
>
> It says I will x number of attempts to push message and mostly db
> connections will be inside
>
> actor code , or may be mostly code to push to queue , if Ithat fails , I
> am screwed.
>
> Have any body using it with guaranteed delivery enabled in production ?
>

I'd recommend using AtLeastOnceDelivery combined with idempotent
operations—that gives you what is called "effectively-once" processing.


>
> --
> >> 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 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] Role of Akka in SMACK

[Viktor Klang]

On Thu, Apr 27, 2017 at 10:39 AM, Shiva Ramagopal  wrote:

> Hi,
>
> I have read through multiple articles describing the SMACK stack but I'm
> having difficulty understanding the role of Akka in the stack. How does
> Akka fit in?
>

Akka is for building the application itself.


>
> Also I would like to know of experiences in using Akka Streams vs Kafka
> Connect for ingesting from Kafka into HDFS (Hive) and RDBMS. Has anyone
> used Akka Streams for say, dynamic partitioning of events from a Kafka
> topic into HDFS?
>

Based on what requirements?


>
> TIA
> -Shiva
>
> --
> >> 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 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] Best way to handle large response from Actor

[Viktor Klang]

For that kind of "messages" I'd recommend using URLs and using a transport
protocol with builtin resumes etc, such as HTTP, FTP etc.

On Wed, Apr 26, 2017 at 8:19 PM, Sumanta Dutta  wrote:

> Hi, we generally use ask pattern to handle request-response between client
> and Akka Cluster. The client waits on the Future. We have a need where the
> response size (~150MB) is too large to fit in one message even after
> increasing message-frame-size to -
>
> maximum-payload-bytes = 5000 bytes
> netty.tcp {
>   message-frame-size = 5000b
>   send-buffer-size = 5000b
>   receive-buffer-size = 5000b
>   maximum-frame-size = 5000b
> }
>
> We don't like keep increasing the above limits. So one possibility is to
> break the response in small chunks, but then how to handle on the Future
> side using the ask pattern. The other possibility may be to use GraphStage
> between Actors to stream the response back. Is that a viable solution? Is
> there any example out there?
>
> Thanks,
> Sumanta
>
> --
> >> 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 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] Getting Classcase exception in TestNG while creating actor

[Viktor Klang]

ActorSystem.apply/create takes an optional ClassLoader if the current
thread context classloader isn't correct.

-- 
Cheers,
√

On Apr 12, 2017 6:43 AM, "Pradeep B K"  wrote:

> Hi All,
> I am seeing below exception when I try to create ActorSystem in TestNG
>
> *16:05:15* java.lang.ClassCastException: interface akka.actor.Scheduler is 
> not assignable from class akka.actor.LightArrayRevolverScheduler*16:05:15*
>  at 
> akka.actor.ReflectiveDynamicAccess$$anonfun$getClassFor$1.apply(DynamicAccess.scala:69)*16:05:15*
> at 
> akka.actor.ReflectiveDynamicAccess$$anonfun$getClassFor$1.apply(DynamicAccess.scala:66)*16:05:15*
> at scala.util.Try$.apply(Try.scala:161)*16:05:15*   at 
> akka.actor.ReflectiveDynamicAccess.getClassFor(DynamicAccess.scala:66)*16:05:15*
>  at 
> akka.actor.ReflectiveDynamicAccess.createInstanceFor(DynamicAccess.scala:84)*16:05:15*
>at 
> akka.actor.ActorSystemImpl.createScheduler(ActorSystem.scala:677)*16:05:15*  
> at akka.actor.ActorSystemImpl.(ActorSystem.scala:576)*16:05:15*   at 
> akka.actor.ActorSystem$.apply(ActorSystem.scala:142)*16:05:15*   at 
> akka.actor.ActorSystem$.apply(ActorSystem.scala:119)*16:05:15*   at 
> akka.actor.ActorSystem$.create(ActorSystem.scala:67)*16:05:15*   at 
> akka.actor.ActorSystem.create(ActorSystem.scala)
>
>
>
> Is this a know issue? How can I create ActorSystem in TestNG?
>
> --
> >> 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] Re: Understanding 'Leader can currently not perform its duties' message

[Viktor Klang]

No, it needs to be Downed.

On Tue, Apr 4, 2017 at 9:50 AM, Unmesh Joshi  wrote:

> Hi,
>
> If I restart the crashed node on same host and port, it should be
> reachable now and consensus should be reached isnt it?
>
> Thanks,
> Unmesh
>
> On Tuesday, 4 April 2017 13:09:22 UTC+5:30, Michal Borowiecki wrote:
>>
>> Hi Unmesh,
>>
>> AFAIK, the crashed node has to be downed (whether manually or
>> automatically) for the cluster to reach convergence.
>>
>> Only once there are no unreachable nodes observed by any member can the
>> leader resume it's duties and allow the new member (your re-started
>> instance) to join.
>>
>> For testing & dev, you can use auto-downing. For production you need to
>> choose a more resilient approach I'm afraid, as out of the box auto-downing
>> doesn't provide a way to address the split-brain-problem which most likely
>> would bite you in a real life environment sooner or later.
>>
>> Cheers,
>>
>> Michal
>>
>> On 04/04/17 08:31, Unmesh Joshi wrote:
>>
>> Is it possibly because in a two node cluster, there can never be majority
>> ( > 50%) nodes agreeing on membership to mark a node as 'seen'?
>>
>> On Tuesday, 4 April 2017 12:46:17 UTC+5:30, Unmesh Joshi wrote:
>>>
>>> Hi,
>>>
>>> I have a two node cluster in a cluster. If I crash one of the nodes 
>>> (*10.131.22.26:3552
>>> ), *and bring it up again, I start getting
>>> following messages from other nodes.  Now that the node is reachable and
>>> there are only two nodes in the cluster, why should it give following
>>> message with seen=false for 1*0.131.22.26:3552
>>> ? *
>>> For members to be seen, is there any other configuration that needs to
>>> be tuned?
>>>
>>>
>>> [INFO] [04/04/2017 12:38:49.623] 
>>> [csw-cluster-akka.actor.default-dispatcher-14]
>>> [akka.cluster.Cluster(akka://csw-cluster)] Cluster Node [akka.tcp://
>>> csw-cluster@10.131.22.26:41574] - Leader can currently not perform its
>>> duties, reachability status: [akka.tcp://csw-cluster@10.131.22.26:41574
>>> -> akka.tcp://csw-cluster@10.131.22.26:3552: Unreachable [Unreachable]
>>> (1)], member status: [akka.tcp://csw-cluster@10.131.22.26:3552 Up
>>> seen=false, akka.tcp://csw-cluster@10.131.22.26:41574 Up seen=true]
>>> [INFO] [04/04/2017 12:39:49.634] 
>>> [csw-cluster-akka.actor.default-dispatcher-2]
>>> [akka.cluster.Cluster(akka://csw-cluster)] Cluster Node [akka.tcp://
>>> csw-cluster@10.131.22.26:41574] - Leader can currently not perform its
>>> duties, reachability status: [akka.tcp://csw-cluster@10.131.22.26:41574
>>> -> akka.tcp://csw-cluster@10.131.22.26:3552: Unreachable [Unreachable]
>>> (1)], member status:* [akka.tcp://csw-cluster@10.131.22.26:3552
>>>  Up seen=false*, akka.tcp://
>>> csw-cluster@10.131.22.26:41574 Up seen=true]
>>> [INFO] [04/04/2017 12:40:49.632] 
>>> [csw-cluster-akka.actor.default-dispatcher-17]
>>> [akka.cluster.Cluster(akka://csw-cluster)] Cluster Node [akka.tcp://
>>> csw-cluster@10.131.22.26:41574] - Leader can currently not perform its
>>> duties, reachability status: [akka.t
>>>
>>>
>>>
>>> Thanks,
>>> Unmesh
>>>
>> --
>> >> 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/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 https://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>>  Michal Borowiecki
>> Senior Software Engineer L4
>> T: +44 208 742 1600 <+44%2020%208742%201600>
>>
>>
>> +44 203 249 8448 <+44%2020%203249%208448>
>>
>>
>>
>> E: michal.b...@openbet.com
>> W: www.openbet.com
>> OpenBet Ltd
>>
>> Chiswick Park Building 9
>>
>> 566 Chiswick High Rd
>>
>> London
>>
>> W4 5XT
>>
>> UK
>> 
>> This message is confidential and intended only for the addressee. If you
>> have received this message in error, please immediately notify the
>> ...@openbet.com and delete it from your system as well as any copies.
>> The content of e-mails as well as traffic data may be monitored by OpenBet
>> for employment and security purposes. To protect the environment please do
>> not print this e-mail unless necessary. OpenBet Ltd. Registered Office:
>> Chiswick Park Building 9, 566 Chiswick High Road, London, W4 5XT, United
>> Kingdom. A company registered in England and Wales. Registered no. 3134634.
>> VAT no. GB927523612
>>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >> Search the archiv

Re: [akka-user] How akka cluster become network partition

[Viktor Klang]

Disconnect the cable between A and B. Reconnect cable after the auto-downer
has trigger.

On Thu, Mar 16, 2017 at 12:08 PM, Dai Yinhua  wrote:

> Hi team,
>
> I am aware that akka cluster may be partitioned to 2 clusters with
> auto-downing.
> But I can't understand how does it happen?
> If node A is performing a long GC? And then node A become unreachable,
> after a while, node A is marked as down, why the cluster is partitioned in
> this case?
>
> Can you help to explain more clearly on that?
>
> Thank you.
>
> --
> >> 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 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] Re: Detail: akka.stream.StreamTcpException: Connection failed.

[Viktor Klang]

Are you consuming your response bodies?

-- 
Cheers,
√

On Feb 27, 2017 12:27 PM, "Chaitanya Mahipath" 
wrote:

> Hi Johannes,
>
> I tried with Http.SingleRequest as suggested but could see the following
> exception
>
> akka.stream.BufferOverflowException: Exceeded configured
> max-open-requests value of [32]
>
> This time the test has lasted only for 40 odd minutes(as compared to
> previous test result which lasted for over 2hrs 30mins.). Could you please
> let me know what configuration changes should be made?
>
> On Monday, February 27, 2017 at 1:59:10 PM UTC+5:30, Johannes Rudolph
> wrote:
>>
>> Hello,
>>
>> the error is thrown here: https://github.com/akka/
>> akka/blob/master/akka-stream/src/main/scala/akka/stream/impl
>> /io/TcpStages.scala#L303. I agree it's hard to see why that error would
>> happen. One thing that could have happened is that a connection attempt was
>> very slow and so the idle-timeout kicked in and killed the TCP stage before
>> a connection was established. Either there was a real connection problem,
>> or the infrastructure didn't make progress in due time e.g. because of a
>> thread starvation issue.
>>
>> Btw. using `Source.single().via(connectionFlow).runWith(Sink.head)` is
>> discouraged. Please use `Http.singleRequest` instead. See also the note at
>> http://doc.akka.io/docs/akka-http/current/scala/http/clie
>> nt-side/host-level.html#host-level-api.
>>
>> HTH
>> Johannes
>>
>>
>>
>> On Monday, February 27, 2017 at 8:25:37 AM UTC+1, Chaitanya Mahipath
>> wrote:
>>>
>>> Hi,
>>>
>>> I am using the akka http scaladsl library to do a HTTP calls against a
>>> server. I am running a test where I have 15 threads running concurrently
>>> each making around 250 GET calls(15*250). Trying to run this test for three
>>> hours but I see that after two and half hours of execution I could see
>>> Detail: akka.stream.StreamTcpException: Connection failed. exception
>>> being thrown.
>>>
>>> Initially I thought the servers isn't accepting the incoming requests.
>>> But, ran the same test directly against the server and could see no issues.
>>> Code snippet to connect to the server -
>>>
>>> connectionFlow= Http(context.system).outgoingC
>>> onnectionTls(req.uri.authority.host.address(), port)
>>> Source.single(req.withUri(req.uri.toRelative)).via(connectionFlow).runWith(Sink.head)
>>> - Here, req is the HttpRequest.
>>>
>>> Could someone please help me out why is that StreamTcpException
>>> exception is thrown?
>>>
>> --
> >> 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] Akka Streams - Retry failed RPC call.

[Viktor Klang]

Hi Sean!

There is a mistake and a misunderstanding in your code:


object Test extends App {

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


  val x: Future[Done] = Source(List("one", "two", "three")).map { value =>
val data = makeRPCcall(value)
data.recoverWithRetries(3 , {
  case e: Exception => makeRPCcall(value)
})
  }.flatMapConcat(identity).runForeach(println(_))



  var i = 0 //<--- NEVER DO THIS, you're closing over a mutable variable
without proper synchronization
  def makeRPCcall(key: String) = {
i = i + 1
if (i == 3) {
  Source.failed(new RuntimeException("failed in source")) //<--- You
need to return a Source which fails, not directly throw, otherwise your
*recovery* fails, not the source with which you are recovering.
} else {
  Source.single(i.toString)
}
  }



  Await.result(x, 10.minutes)
}



So something like this should demonstrate the solution:

object Test {
  val sys = ActorSystem("Test")
  implicit val mat = ActorMaterializer()(sys)

  def makeRPCcall(key: String): Source[Int, NotUsed] = {
val rnd = java.util.concurrent.ThreadLocalRandom.current.nextInt(100)
if (rnd <= 10) Source.failed(new RuntimeException(s"Tried $key but
can't handle the truth: $rnd"))
else Source.single(key.toInt)
  }

  def x: Future[Done] = Source((1 to 1).map(_.toString)).flatMapConcat
{ value =>
makeRPCcall(value).recoverWithRetries(3 , {
  case e: RuntimeException =>
println(e.getMessage) // <--- so we can see the sample output below
makeRPCcall(value)
})
  }.runForeach(println)
}

Test.x

Example output:

scala> Tried 1 but can't handle the truth: 7
1
2
3
4
5
6
7
8
9
10
11
12
Tried 13 but can't handle the truth: 10
13
14
15
16
Tried 17 but can't handle the truth: 8
17
18
19
20
21
22
23
24
25
26
27
28
29
Tried 30 but can't handle the truth: 9
30
31
32
33
34
Tried 35 but can't handle the truth: 9

Test.sys.terminate()

On Thu, Feb 23, 2017 at 9:00 PM, Sean Callahan 
wrote:

> I am skeptical of this working. The reason being is the following example.
> I would expect my printed output to be "1" "2" "4". But instead I get "1"
> "2" "Exception in thread "main" java.lang.RuntimeException: failed in
> source". So it seems that I am missing something here.
>
> object Test extends App {
>
>   implicit val system = ActorSystem()
>   implicit val mat = ActorMaterializer()
>
>
>   val x: Future[Done] = Source(List("one", "two", "three")).map { value =>
> val data = makeRPCcall(value)
> data.recoverWithRetries(3 , {
>   case e: Exception => makeRPCcall(value)
> })
>   }.flatMapConcat(identity).runForeach(println(_))
>
>
>
>   var i = 0
>   def makeRPCcall(key: String) = {
> i = i + 1
> if (i == 3) {
>   throw new RuntimeException("failed in source")
> } else {
>   Source.single(i.toString)
> }
>   }
>
>
>
>   Await.result(x, 10.minutes)
> }
>
>
>
>
> On Thursday, February 23, 2017 at 11:24:05 AM UTC-7, √ wrote:
>>
>> def downloadS3ObjectFlow(s3Client: S3Client, bucket: String):
>> Flow[String, ByteString, NotUsed] = {
>> Flow[String].flatMapConcat { key =>
>>   log.debug(s"Downloading $key")
>>   val data: Source[ByteString, NotUsed] = s3Client.download(bucket,
>> key)
>>   data.recoverWithRetries(3, {
>> case SomeExpectedException => data
>>   })
>> }
>>   }
>>
>> On Thu, Feb 23, 2017 at 5:20 PM, Sean Callahan 
>> wrote:
>>
>>> Hey all, Currently I have the following flow to take in an S3 key and
>>> download that that file from S3.
>>>
>>> def downloadS3ObjectFlow(s3Client: S3Client, bucket: String):
>>> Flow[String, ByteString, NotUsed] = {
>>> Flow[String].map { key =>
>>>   log.debug(s"Downloading $key")
>>>   val data: Source[ByteString, NotUsed] = s3Client.download(bucket,
>>> key)
>>>   data
>>> }.flatMapConcat(identity)
>>>   }
>>>
>>>
>>>
>>> In 99% of cases, this works great, but as many of us know, S3 fails a
>>> fair amount for random unknown reasons the proper way to resolve it is to
>>> just retry the request. After a few hours of googling and trying various
>>> different solutions out there I have yet to find the proper solution here.
>>> Is there anything built into Akka that can accomplish this, or should I
>>> write some custom logic here to check the value of "data" and setup some
>>> type of stateful retries?
>>>
>>> --
>>> >> 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 https://groups.google.com/

Re: [akka-user] Akka Streams - Retry failed RPC call.

[Viktor Klang]

def downloadS3ObjectFlow(s3Client: S3Client, bucket: String): Flow[String,
ByteString, NotUsed] = {
Flow[String].flatMapConcat { key =>
  log.debug(s"Downloading $key")
  val data: Source[ByteString, NotUsed] = s3Client.download(bucket, key)
  data.recoverWithRetries(3, {
case SomeExpectedException => data
  })
}
  }

On Thu, Feb 23, 2017 at 5:20 PM, Sean Callahan 
wrote:

> Hey all, Currently I have the following flow to take in an S3 key and
> download that that file from S3.
>
> def downloadS3ObjectFlow(s3Client: S3Client, bucket: String): Flow[String,
> ByteString, NotUsed] = {
> Flow[String].map { key =>
>   log.debug(s"Downloading $key")
>   val data: Source[ByteString, NotUsed] = s3Client.download(bucket,
> key)
>   data
> }.flatMapConcat(identity)
>   }
>
>
>
> In 99% of cases, this works great, but as many of us know, S3 fails a fair
> amount for random unknown reasons the proper way to resolve it is to just
> retry the request. After a few hours of googling and trying various
> different solutions out there I have yet to find the proper solution here.
> Is there anything built into Akka that can accomplish this, or should I
> write some custom logic here to check the value of "data" and setup some
> type of stateful retries?
>
> --
> >> 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 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] newbie question about await inside actors code

[Viktor Klang]

Perhaps it was implicit but I assumed that the question was how to not
process any new information until the response had been received, otherwise
you're just use pipeTo and be done with it?

On Tue, Feb 21, 2017 at 1:19 PM, Alan Burlison 
wrote:

> On 21/02/2017 12:12, Viktor Klang wrote:
>
> http://doc.akka.io/docs/akka/2.4/scala/actors.html#Stash
>>
>
> Ahah! I'd seen stash in the docs and not really come up with an case
> (other than become/become) where it would be useful, and then forgotten
> about it. I'm still not clear how it would help in this scenario though?
>
> Thanks,
>
>
> --
> Alan Burlison
> --
>
> --
>
>>  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+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 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] newbie question about await inside actors code

[Viktor Klang]

http://doc.akka.io/docs/akka/2.4/scala/actors.html#Stash

On Tue, Feb 21, 2017 at 1:09 PM, Alan Burlison 
wrote:

> On 20/02/2017 12:01, Viktor Klang wrote:
>
> No. I'd recommend to use stashing, makes the cost explicit.
>>
>
> Could you expand on what you mean by "stashing"?
>
>
> --
> Alan Burlison
> --
>
> --
>
>>  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+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 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] newbie question about await inside actors code

[Viktor Klang]

No. I'd recommend to use stashing, makes the cost explicit.

-- 
Cheers,
√

On Feb 20, 2017 12:56 PM, "Alan Burlison"  wrote:

> > This is not a solution because it creates one new thread for every
> blocker.
>
> In general I agree, but if the code has already aggregated all the
> futures into a single one, as seems to be suggested in an earlier
> email, wouldn't it be an option - albeit not an ideal one?
>
> --
> Alan Burlison
> --
>
> --
> >>  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] What is the difference between using broadcasts and manually connecting shapes

[Viktor Klang]

What does the test output show?

On Fri, Feb 10, 2017 at 5:30 AM, faiz halde  wrote:

> I wanted to know if there is any difference between the following two
> scenarios
>
> val g = RunnableGraph.fromGraph(GraphDSL.create() { implicit builder: 
> GraphDSL.Builder[NotUsed] =>
>   import GraphDSL.Implicits._
>   s ~> f1 ~> si
>   s ~> f2 ~> si
>   ClosedShape
> }).run()
>
> val g = RunnableGraph.fromGraph(GraphDSL.create() { implicit builder: 
> GraphDSL.Builder[NotUsed] =>
>   import GraphDSL.Implicits._
>
>   val b = builder.add(Broadcast[Int](2))
>   s ~> b ~> f1 ~> si
>b ~> f2 ~> si
>   ClosedShape
> }).run()
>
>
>
> In the first case, is it that two sources will be created ? What about
> second case ?
>
> --
> >> 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 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] Sink/source materialization

[Viktor Klang]

You mean like: Source.single(()).flatMapConcat(_ => yourFunction())?

-- 
Cheers,
√

On Feb 8, 2017 03:33, "hbf"  wrote:

> Heya everybody!
>
> I know that Akka Stream elegantly distinguishes *describing* a graph from
> *materializing* a graph.
>
> When working on custom Akka Stream sink/sources, I often find myself
> looking for a simple way to create a source (or sink) from a function that
> gets called at materialization time. However, I don't see this in the
> Source/Sink companion object.
>
> Examples:
>
>- Create a source that returns the results from a single HTTP call
>when materialized.
>- Create a sink that when materializes opens a connection to Redis and
>writes to it.
>
> In both cases, I'd like the some action (make the HTTP request, open the
> connection) to only take part when we materialize, and each time we
> materialize the flow.
>
> Am I missing something?
>
> Thanks for any feedback!
> Hbf
>
> P.S. I know I can use the GraphStage API to achieve this (and that's what
> I'm doing) but I think it might be nice to have this functionality in a
> more visible API – if what I say makes sense.
>
> --
> >> 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] Persistent Graph Stage

[Viktor Klang]

Would it be more flexible with a `persistentBuffer` stage?

On Mon, Feb 6, 2017 at 4:54 PM, Konrad Malawski <
konrad.malaw...@lightbend.com> wrote:

> Would you be up to implementing it? Otherwise I don't think there will be
> much happening around this.
> It could start out in github.com/akka/akka-stream-contrib
>
> --
> Konrad `ktoso` Malawski
> Akka  @ Lightbend 
>
> On 6 February 2017 at 16:51:19, Héctor Veiga (kec...@gmail.com) wrote:
>
>
> --
> >> 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 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] Class cast exceptions in actors that return Future[Unit]

[Viktor Klang]

On Wed, Feb 1, 2017 at 10:51 AM, Alan Burlison 
wrote:

> On 01/02/17 09:06, Viktor Klang wrote:
>
> You're welcome. A reminder that the actual error messages are very
>> important to include. :)
>>
>
> Yes, I consider my wrist to be slapped ;-) Thanks again!


lol, no wrist-slapping intended—but the more info is available, the more
people has a chance to understad.


>
>
> If there is no method in the java/scaladoc then you'll need to convert
>> manually.
>>
>
> If there is I haven't been able to spot it.


Try(block).fold(Status.Success(_), Status.Failure(_)) ?


>
>
> And if you need a shorthand, it should be a one-liner def. ;)
>>
>
> Well, nearly ;-) I just copied the "Try {???}" implementation but made it
> return Akka Status values rather those used by Try - I don't need any
> operations other than to return the Akka success types.
>
>   def actorTry[T](f: => T): akka.actor.Status.Status = {
> try {
>   akka.actor.Status.Success(f)
> } catch {
>   case NonFatal(e) => akka.actor.Status.Failure(e)
> }
>   }
>
> then in the receive method:
>
> case Read(from, to, reader) => sender ! actorTry { read(from, to, reader) }
>
> IIRC akka.actor.Status.Success was created aeons ago,
>> scala.util.Success was added with scala.util.Try, so they have
>> separate origins. (just like java.util.List and
>> scala.collection.immutable.List)
>>
>
> Ah, the curse of history :-) Sounds completely plausible - thanks.


:)


>
>
> --
> Alan Burlison
> --
>
> --
>
>>  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+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 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] Class cast exceptions in actors that return Future[Unit]

[Viktor Klang]

On Wed, Feb 1, 2017 at 2:55 AM, Alan Burlison 
wrote:

> Ahah! I think you may of nailed it... Thanks!
>>
>
> Indeed you did nail it - "thanks" doesn't come close as I'd looked at this
> for so long that I'd gone completely snow-blind ;-)
>

You're welcome. A reminder that the actual error messages are very
important to include. :)


>
> Is there a convenient shorthand way of mapping between a
> scala.util.Success and an akka.actor.Status.Success, or should I just do it
> with a match expression? What I'm doing is wrapping the IO functions that
> could fail in a "Try { ??? }" and returning the result to the calling actor.
>

If there is no method in the java/scaladoc then you'll need to convert
manually. And if you need a shorthand, it should be a one-liner def. ;)


>
> Is there a reason why there's both scala.util.Success and an
> akka.actor.Status.Success?


IIRC akka.actor.Status.Success was created aeons ago, scala.util.Success
was added with scala.util.Try,
so they have separate origins. (just like java.util.List and
scala.collection.immutable.List)


>
>
> --
> Alan Burlison
> --
>
> --
>
>>  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+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 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] Class cast exceptions in actors that return Future[Unit]

[Viktor Klang]

I think the problem is that your responding with a scala.util.Success
rather than a akka.actor.Status.Success.

On Wed, Feb 1, 2017 at 12:20 AM, Alan Burlison 
wrote:

> On 31/01/17 22:18, Viktor Klang wrote:
>
> The answer will be in the stack traces.
>>
>
> What I got was:
>
> java.lang.ClassCastException: Cannot cast scala.util.Success to
> scala.runtime.BoxedUnit
>
> which didn't give me much of a clue, however it was clear that
> asInstanceOf wasn't the right approach and when I looked at the mapTo
> implementation it was going to throw an exception as well, which is why I
> settled on the map alternative - but that didn't feel quite right either,
> hence the question. Thanks for the confirmation that's the right approach.
>
>
> --
> Alan Burlison
> --
>
> --
>
>>  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+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 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] Class cast exceptions in actors that return Future[Unit]

[Viktor Klang]

The answer will be in the stack traces.

-- 
Cheers,
√

On Jan 31, 2017 10:55 PM, "Akka Team"  wrote:

> If it in fact was a Unit you got back from the actor then neither of the
> things you tried should throw a class cast exception though. If the actor
> for example sends a Future[Unit] back, then you will have a
> Future[Future[Unit]] returned from ask.
>
> --
> Johan
> Akka Team
>
> On Tue, Jan 31, 2017 at 2:41 PM, Alan Burlison 
> wrote:
>
>> On 31/01/2017 21:36, Viktor Klang wrote:
>>
>> What'd be the alternative?
>>>
>>
>> Not sure really, don't know if there's any way of preserving a
>> Future[Unit] rather than converting it to a Future[Any]. As I said, it just
>> seemed a bit clunky, and not obvious immediately obvious as to how to solve
>> the issue. Perhaps just a note in the docs about how to handle Future[Unit]?
>>
>>
>> --
>> Alan Burlison
>> --
>>
>> --
>>
>>>  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+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 Team
> Lightbend <http://www.lightbend.com/> - Reactive apps on the JVM
> 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 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] Class cast exceptions in actors that return Future[Unit]

[Viktor Klang]

What'd be the alternative?

-- 
Cheers,
√

On Jan 31, 2017 10:28 PM, "Alan Burlison"  wrote:

> On 31/01/2017 20:32, Akka Team wrote:
>
> You have a Future[Something], and a Something is an Any (everything is) but
>> it is not Unit (only Unit is), so you can not just cast it, you must
>> replace it with an actual Unit, which is what .map(_ => ()) does.
>>
>
> OK, thanks for confirming that I haven't missed anything obvious.
>
> However that's a bit clunky - the method in the actor returns a
> Future[Unit], by the time it gets back to the "ask"ing Actor is has been
> converted to a Future[Any] and then you have to map it back to a
> Future[Unit] again.
>
> --
> Alan Burlison
> --
>
> --
>
>>  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+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] Slf4jLoggingFilter/logback level filtering issue

[Viktor Klang]

run the app with -Dakka.log-config-on-start=on

On Thu, Jan 12, 2017 at 11:15 AM, vacuumstate 
wrote:

> Hi,
>
> I'm having trouble trying to get logging working as per standard akka
> documentation.
>
> The application consists of several scala/sbt assembly jars deployed to a
> 'bin' folder along with their *.conf HOCON and logback.xml files (which are
> excluded from the assembly packaging).
>
>
> The issue is with trying to get the level filtering working i.e. it
> doesn't have any effect; - with all levels set to "warning' in logback.xml,
> I'm still getting debug and info logging output.
>
>
> The logback.xml must be used to some extent, because the log output is
> matching the logback.xml pattern.
>
> A log.conf is included by the other conf files:
>
> akka {
>   log-dead-letters = 0
>   log-dead-letters-during-shutdown = off
>   warn-about-java-serializer-usage = off
>   loglevel = DEBUG
>   stdout-loglevel = WARNING
>   loggers = ["akka.event.slf4j.Slf4jLogger"]
>   logging-filter = "akka.event.slf4j.Slf4jLoggingFilter"
> }
>
> And here is the logback.xml
>
> 
> 
> 
> System.out
> 
> %X{akkaTimestamp}| %-6level| %logger{36}|
> %X{sourceActorSystem}| %msg%n
> 
> 
>
> 
> 
> 
>
> 
> 
> 
> 
>
> And here are the library dependencies from one of the build.sbt files
> (scala version is *2.12.1*):
>
> libraryDependencies ++= {
>   val akkaVersion = "2.4.16"
>   Seq(
> "org.scala-lang"  % "scala-reflect"   %
> "2.12.1",
> "org.scala-lang.modules"  % "scala-xml_2.12"  %
> "1.0.6",
> "com.typesafe.akka"   %% "akka-actor" %
> akkaVersion,
> "com.typesafe.akka"   %% "akka-slf4j" %
> akkaVersion,
> "com.typesafe.akka"   %% "akka-remote"%
> akkaVersion,
> "com.typesafe.akka"   %% "akka-cluster"   %
> akkaVersion,
> "com.typesafe.akka"   %% "akka-cluster-tools" %
> akkaVersion,
> "ch.qos.logback"  %  "logback-classic"%
> "1.1.8",
> "org.eclipse.persistence" % "eclipselink" %
> "2.6.4",
> "javax.el"% "javax.el-api"%
> "3.0.0",
> "com.typesafe.akka"   %% "akka-multi-node-testkit"%
> akkaVersion   % "test",
> "com.typesafe.akka"   %% "akka-testkit"   %
> akkaVersion   % "test",
> "org.scalatest"   %% "scalatest"  %
> "3.0.1"   % "test",
> "com.novocode"% "junit-interface" %
> "0.11"% "test"
>   )
> }
>
> I'd appreciate any clues on how to resolve this!
>
> Thanks,
>
> Rob.
>
> --
> >> 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 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] Consistent Dissasociation, small cluster

[Viktor Klang]

Have you tried FromConfig?

-- 
Cheers,
√

On Jan 6, 2017 20:15, "Jordan Messec"  wrote:

> I am unable to get the dispatcher configuration to be applied. After
> running the application and noticing the problem persist, I added a tag to
> see the thread name in my logging lines, and notice that actors configured
> to use non-default dispatchers are still using the default. Even the
> akka.cluster.use-dispatcher configuration seems to be ignored.
>
> Here is my relevant config, does anyone see a problem here? Please note
> that I am using Google Guice to instantiate the top level
> "vcube-generation" actor.
>
> akka {
>   actor {
> provider = "cluster"
> # Customize dispatchers for blocking actors
> deployment {
>   /vcube-generation {
> dispatcher = my-pinned-dispatcher
>   }
>   # For the 4 actual vcubegenerators
>   /vcube-generation/generator {
> router = balancing-pool
> nr-of-instances = 4
> pool-dispatcher {
>   executor = "thread-pool-executor"
>   thread-pool-executor {
> core-pool-size-min = 4
> core-pool-size-max = 4
>   }
> }
>   }
>   # For the manager, which handles things such as cleanup
>   /vcube-manager {
> dispatcher = my-pinned-dispatcher
>   }
> }
>   }
>   cluster {
> use-dispatcher = cluster-dispatcher
>   }
> }
>
> # Set up dispatchers for blocking io
> blocking-io-dispatcher {
>   type = Dispatcher
>   executor = "thread-pool-executor"
>   thread-pool-executor {
> fixed-pool-size = 32
>   }
>   throughput = 1
> }
> my-pinned-dispatcher {
>   executor = "thread-pool-executor"
>   type = PinnedDispatcher
> }
>
> # Set up separate thread for akka cluster dispatcher
> cluster-dispatcher {
>   type = "Dispatcher"
>   executor = "fork-join-executor"
>   fork-join-executor {
> parallelism-min = 2
> parallelism-max = 4
>   }
> }
>
>
>
> And here is the creation of the "generator" actor:
> val generator = context.actorOf(BalancingPool(4).props(Props(classOf[
> VCubeGenerator], dimensionMapper, reactiveMongoApi, cubeDates, system)),
> name = "generator")
>
>
> Could it be that Guice creates some parent actor and therefore my
> references are not getting honored? But then why doesn't the
> cluster.use-dispatcher line get honored either?
>
> Jordan
>
> --
> >> 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] akka-http non-standard status codes

[Viktor Klang]

How about having that exception message suggest using the other factory
method?

-- 
Cheers,
√

On Jan 4, 2017 7:14 PM, "Konrad Malawski" 
wrote:

> Please read my response in detail:
> Use the 4 parameter version: StatusCodes.custom(666, "BadStatusCode", "The
> number of the beast", false, false)
>
> Since it's not a standard range you must provide the additional
> information since we can't guess it.
>
> --
> Konrad `ktoso` Malawski
> Akka  @ Lightbend 
>
> On 4 January 2017 at 19:13:37, Patrick O'Reilly (padjo.orei...@gmail.com)
> wrote:
>
> Hi Konrad,
>
> Thanks for the prompt reply. I've tried the StatusCodes.custom call with a
> non-standard status code but it throws the following exception:
>
> Exception in thread "main" java.lang.IllegalArgumentException: Can't
> register status code in non-standard region
> at akka.http.scaladsl.model.StatusCodes$.custom(StatusCode.scala:92)
> at AkkaHttp2$.delayedEndpoint$AkkaHttp2$1(AkkaHttp2.scala:47)
> at AkkaHttp2$delayedInit$body.apply(AkkaHttp2.scala:16)
> at scala.Function0$class.apply$mcV$sp(Function0.scala:34)
> at scala.runtime.AbstractFunction0.apply$mcV$
> sp(AbstractFunction0.scala:12)
> at scala.App$$anonfun$main$1.apply(App.scala:76)
> at scala.App$$anonfun$main$1.apply(App.scala:76)
> at scala.collection.immutable.List.foreach(List.scala:381)
> at scala.collection.generic.TraversableForwarder$class.
> foreach(TraversableForwarder.scala:35)
> at scala.App$class.main(App.scala:76)
> at AkkaHttp2$.main(AkkaHttp2.scala:16)
> at AkkaHttp2.main(AkkaHttp2.scala)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(
> NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:147)
>
> It seems StatusCodes.custom specifically doesn't allow codes outside the
> normal range:
>
> def custom(intValue: Int, reason: String, defaultMessage: String = ""):
> StatusCode =
> if (100 to 199 contains intValue) Informational(intValue)(reason,
> defaultMessage)
> else if (200 to 299 contains intValue) Success(intValue)(reason,
> defaultMessage)
> else if (300 to 399 contains intValue) Redirection(intValue)(reason,
> defaultMessage, defaultMessage)
> else if (400 to 499 contains intValue) ClientError(intValue)(reason,
> defaultMessage)
> else if (500 to 599 contains intValue) ServerError(intValue)(reason,
> defaultMessage)
> else throw new IllegalArgumentException("Can't register status code
> in non-standard region")
>
> Best,
> Patrick
>
>
> On Wednesday, January 4, 2017 at 12:49:21 PM UTC-5, Konrad Malawski wrote:
>>
>> Everything is configurable :-)
>>
>> I see we missed to document that setting. We documented how to do it for
>> custom media types here: http://doc.akka.io/docs/
>> akka-http/current/scala/http/routing-dsl/directives/method-d
>> irectives/extractMethod.html#custom-http-method
>>
>> Which is basically the same process you'll need to do for the status code:
>>
>> val parserSettings = 
>> ParserSettings(system).withCustomStatusCodes(StatusCodes.custom(666, 
>> "BadStatusCode", "The number of the beast", false, false))
>>
>> val serverSettings = 
>> ServerSettings(system).withParserSettings(parserSettings)
>>
>> val binding = Http().bindAndHandle(routes, host, port, settings = 
>> serverSettings)
>>
>>
>> I'll add that to the docs.
>>
>> Happy hakking
>>
>> --
>> Konrad `ktoso` Malawski
>> Akka  @ Lightbend 
>>
>> On 4 January 2017 at 18:46:08, Patrick O'Reilly (padjo@gmail.com)
>> wrote:
>>
>> Hi,
>>
>> We're using Akka HTTP client to consume a remote API. This API however is
>> returning non-standard status codes in the 600's which cannot be parsed by
>> Akka. akka.http.ParserSettings.withCustomStatusCodes only allow valid
>> 100-599 codes. Does anyone have a solution to this problem? The exception
>> thrown is an illegal response status but the exception has no details on
>> the actual status code.
>>
>> Thanks,
>> Patrick
>>
>> --
>> >> 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/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 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.h

Re: [akka-user] Correct way to "wait" for polling elements from a Source in Akka Streams

[Viktor Klang]

How about something like this?

Source.repeat(NotUsed).flatMapConcat { _ =>
  val items = service.getItems
  if (items.isEmpty)
Source.tick(30.seconds, 1.second, Seq.empty[Item]).take(1).drop(1) //
<-- more than likely easier ways to do this, but it is late here.
  else
Source.single(items)
}

On Fri, Dec 30, 2016 at 11:53 PM, Konrad Malawski <
konrad.malaw...@lightbend.com> wrote:

> Read the docs about GraphStage and custom stream processing elements. It
> had all the utilities needed for this. We also explained them on the Akka
> blog: Akka.io/blog so check that out :)
>
> On Dec 30, 2016 23:29, "Drew Kutcharian"  wrote:
>
>> Hi,
>>
>> I have a use case where I poll a datasource for items and as long as
>> there are items present I process them as quickly as possible, but when
>> there are no items, I would like to poll every X seconds. Is there a
>> built-in construct in Akka Streams that I can use?
>>
>> I'm currently using `Source.unfoldAsync` to get the records from the data
>> source. One "bad" option is to just call `Thread.sleep(XXX)` inside
>> `Source.unfoldAsync` when the datasource returns no results (as
>> demonstrated below), but I want to see if there's a better option.
>>
>> Source.unfoldAsync[NotUsed, Seq[Item]](NotUsed) { _ =>
>>   service.getItems flatMap { items =>
>>   if (items.isEmpty) {
>> //TODO Fix this!!!
>> Thread.sleep(30 * 1000) //30 seconds
>>   }
>>   Future.successful(Some((NotUsed, items)))
>>   }
>> }
>>
>> I can probably improve on the `Thread.sleep(XXX)` by using having some
>> "State" object and have smaller waits, but I feel like that's not going to
>> be that much better.
>>
>> Any input is appreciated.
>>
>> Thanks,
>>
>> Drew
>>
>> --
>> >>  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+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.
>



-- 
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Streaming protobuf objects

[Viktor Klang]

Glad it worked out well for you!

You'll want to put ` private var tail = ByteString.empty` inside the
creation of th GraphStageLogic (otherwise your stage does not rematerialize
properly)

On Thu, Dec 29, 2016 at 11:10 AM, Leopoldo Müller  wrote:

> Kyrylo,
>
> As suggested by √ I implemented the GraphStage, seems to be working so far.
>
> import com.google.protobuf.Parser
>
> import akka.actor._
> import akka.stream._
> import akka.stream.scaladsl._
> import akka.stream.stage._
> import akka.util._
> import scala.collection.JavaConverters._
>
> import scala.util.Try
>
> object BmruleView extends App {
>
> implicit val system = ActorSystem()
> implicit val executor = system.dispatcher
> implicit val materializer = ActorMaterializer()
>
> StreamConverters.fromInputStream(() => System.in)
> .via {
> new ParseDelimitedFromStage(MYMESSAGE.parser())
> }
> .runForeach { it =>
> println(it)
> }
> .onComplete {
> case _ => system.terminate()
> }
> }
>
> class ParseDelimitedFromStage[T](parser: Parser[T]) extends
> GraphStage[FlowShape[ByteString, T]] {
> val in = Inlet[ByteString]("ParseDelimitedFromStage.in")
> val out = Outlet[T]("ParseDelimitedFromStage.out")
> override val shape = FlowShape(in, out)
>
> private var tail = ByteString.empty
>
> override def createLogic(inheritedAttributes: Attributes):
> GraphStageLogic = new GraphStageLogic(shape) with InHandler with OutHandler
> {
>
> setHandlers(in, out, this)
>
> override def onPush() = {
>
> val chunk = tail ++ grab(in)
> val iterator = chunk.iterator
> var leftover = 0
>
> Iterator
> .continually {
> leftover = iterator.len
> Try(parser.parseDelimitedFrom(iterator.asInputStream))
> }
> .takeWhile { _ => iterator.len > 0 }
> .foreach { it => emit(out, it.get) }
>
> tail = chunk.takeRight(leftover)
> }
>
> override def onPull() = pull(in)
> }
> }
>
>
> On Sunday, January 31, 2016 at 2:16:58 PM UTC, √ wrote:
>>
>> Sounds like you ought to write a parser GraphStage which decodes inbound
>> ByteStrings and emits ByteStrings, one per object, then you can decode it
>> no matter if it comes from a file or over network, and the conversion from
>> ByteString to your protobuf object can be a simple map()
>>
>> --
>> Cheers,
>> √
>> On Jan 31, 2016 1:13 PM, "Kyrylo Stokoz"  wrote:
>>
>>> Ok, i dug into how our objects are stored and indeed they have a record
>>> length in front of them, but unfortunately protobuf is using base 128
>>> varints (https://developers.google.com/protocol-buffers/docs/encoding),
>>> length field can be encoded in 1 byte for short records and 2-4 bytes for
>>> longer records.
>>>
>>> Basically in this case i cannot split stream into frames with Framing.
>>> lengthField.
>>>
>>> Taking into account proto layout is there anything i can do to build
>>> above mentioned pipeline in efficient way?
>>> Any suggestions very appreciated.
>>>
>>> Thanks,
>>> Kyrylo
>>>
>>> On Saturday, January 30, 2016 at 6:50:13 PM UTC+1, √ wrote:

 Hi,

 it is important to know how the file is layouted. (i.e. between
 MyObjects)

 On Sat, Jan 30, 2016 at 6:32 PM, Kyrylo Stokoz 
 wrote:

> Sorry looks like i was wrong, there is no record length in beginning.
> Example of proto definition see below:
>
> message MyObject {
> optional string FieldName1 = 1;
> optional string FieldName2 = 2;
> optional string FieldName3 = 3;
> optional string FieldName4 = 4;
> optional int64 FieldName5 = 5;
> }
>
>
> On Saturday, January 30, 2016 at 6:19:40 PM UTC+1, Kyrylo Stokoz wrote:
>>
>> I guess you are interested how objects are stored:
>>
>> Initial bytes define length of record later goes record itself.
>> Normally i have file with 350K of them. Example head of file you can see
>> below:
>> Hope this answers your question.
>>
>> ~$
>> ^I326216374^R^KtrafficFlow^Xú<85>^B">bb1246cb-6f12-4b9e-a68c-fe3f67e65388*
>> 324a6978e0ae0e159437dc03a3f00ad9~$
>> ^I326216375^R^KtrafficFlow^Xú<85>^B">f647601e-5b1f-4325-a0a4-48cc1a1598a6*
>> 9585fd96770a68faa41eb0bd202c45d1~$
>> ^I326216380^R^KtrafficFlow^Xú<85>^B">6e3c8929-dd6e-4de7-8342-8f5f08da9e38*
>> df06d0a9f4ef5d8866538f5d2352b3fd~$
>> ...
>>
>> On Saturday, January 30, 2016 at 4:16:53 PM UTC+1, √ wrote:
>>>
>>> What's the layout of the file with protobuf objects?
>>>
>>> On Sat, Jan 30, 2016 at 2:57 PM, Kyrylo Stokoz 
>>> wrote:
>>>
 Hi All,

 I`m trying to learn more about akka streams and have on first sight
 trivial task.
 I have a very large file of protobuf encoded objects i want

Re: [akka-user] Akka stream never completes

[Viktor Klang]

eagerClose on the Merge?

-- 
Cheers,
√

On Dec 27, 2016 6:30 PM, "Sergey Sopin"  wrote:

> Hi all,
>
>
> I am trying to build a flow, which will return CompletionStage with the
> List inside. It looks like following:
>
>
> private CompletionStage> buildAndRunGraph(ArrayList 
> sourceList) {
> Source source = Source.from(sourceList);
> Materializer materializer = ActorMaterializer.create(context());
> return source.via(balancer(buildFinderFlow(), sourceList.size(), 
> false)).runWith(Sink.seq(), materializer);
> }
>
>
> The flow itself looks like following:
>
>
> 
>
> First two elements in the flow with multiple inlets and outlets are Merge
> and Partition. Third one (with two outlets) is custom FanOutShape2 which
> redirects message to one of two outlets based on condition.
> Flow itself is working, I added loging in it and if Source contains 55
> elements, then 55 results will be in the Sink, but resulted CompletionStage
> doesn't complete. It waits for some miracle which never happens.
> Could you please tell me how to fix that?
> Thank you in advance!
>
> Cheers,
> Sergey
>
> --
> >> 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] Completing request outside of main controller

[Viktor Klang]

I guess another option would be to spawn your own Promise and pass it in
your messages and complete it where you want?

-- 
Cheers,
√

On Dec 20, 2016 10:40 AM, "Konrad Malawski" 
wrote:

> Either of the two work. Use ask to integrate with the Actor.
>
> The complete has to be in the route - yes. This is a feature we added
> while we reflected on this while moving Spray to become Akka HTTP.
> In Spray people would forget to call complete() and it would still
> compile, now you have to complete in the routes.
>
> --
> Konrad `ktoso` Malawski
> Akka  @ Lightbend 
>
> On 20 December 2016 at 10:36:11, Sid Feiner (sidfei...@gmail.com) wrote:
>
> Hey, I've posted this question also on Stack Overflow but I'll post it
> here as well as I have a bigger chance of getting help :)
>
> I am pretty new to the Akka world and I have to migrate a project from
> Spray to akka-http.
>
> In spray, a route was of type Route = RequestContext ⇒ Unit.
> But in akka-http, it is of type Route = RequestContext ⇒
> Future[RouteResult].
>
> So in spray, we would often handle and complete our requests through a
> chain of Actors (outside of the main controller) using only fire-and-forget
> so we didn't have to "ask" and the performance was great. Now, we have to
> use "ask" every time we pass the request to another Actor (correct me if
> I'm wrong)
>
> I've been searching a lot and I found a few options which I'm not sure if
> they fully satisfy me (the need to complete a request in another Actor
> without the need to return it back to the controller). So that's where you
> could help me :)
>
>
> *Option 1: Using onSuccess/onComplete*
> Does using this block my main controller from receiving more requests?
>
>
> *Option 2: Using Futures and using RouteResult.Complete*
>
> I've found the following example at How to complete a request in another
> actor when using akka-http :
>
> import akka.actor.{ActorSystem, Actor, Props}import akka.pattern.askimport 
> akka.stream.ActorMaterializerimport akka.http.scaladsl.Httpimport 
> akka.http.scaladsl.server.Directives._import 
> akka.http.scaladsl.server.{RequestContext, RouteResult}import 
> scala.concurrent.Futureimport akka.http.scaladsl.model.HttpResponseimport 
> akka.util.Timeout
> class RequestActor extends Actor {
>
>   //business logic - returns empty HttpResponse
>   def handleRequestMessage(requestContext : RequestContext) =
> RouteResult.Complete(new HttpResponse())
>
>   override def receive = {
> case reqContext : RequestContext =>
>   sender ! handleRequestMessage(reqContext)
>   }}//end class RequestActor
> object RouteActorTest extends App {
>   implicit val as = ActorSystem("RouteActorTest")
>   implicit val timeout = new Timeout(1000)
>
>   val actorRef = as actorOf Props[RequestActor]
>
>   def handleRequest(reqContext : RequestContext) : Future[RouteResult] =
> ask(actorRef,reqContext).mapTo[RouteResult]
>
>   val route = path("") { get(handleRequest) }
>
>   //rest of application...
> }//end object RouteActorTest
>
>
> But this actually passes the response back every time to the previous
> Actor (the sender) until it reaches the main controller. Another thing
> about this option is that in the code, it says:
>
> /**
>  * The result of handling a request.
>  *
>  * As a user you typically don't create RouteResult instances directly.
>  * Instead, use the methods on the [[RequestContext]] to achieve the desired 
> effect.
>  */
>
> So I'm not sure if it's a recommended way of doing it.
>
>
> I've tried using requestContext.complete() in another actor but it doesn't
> work (no error thrown, simply doesn't send response) Does anybody know what
> the best way is to implement the previous architecture we had - The ability
> to fire-and-forget the request between Actors and completing it any Actor I
> want?
>
> Thanks a lot!
> --
> >> 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+unsubsc

Re: [akka-user] Consistent Dissasociation, small cluster

[Viktor Klang]

Hi!

Update to most recent version and report back.

-- 
Cheers,
√

On Dec 17, 2016 08:20, "Jordan Messec"  wrote:

> Hello, I am struggling with a problem I have spent days trying to resolve.
> I was hoping someone here may have some input that could help me look in
> the right direction.
>
> I am running a small cluster with 3 nodes. Two nodes reside on one
> machine, while the third resides on a separate machine. This cluster is
> formed between two applications. Call them Web and DataDig. DataDig and Web
> co-reside on Machine1 and Web is duplicated on machine two.
>
> Both use Akka 2.4.4, with Web's dependencies being transitive through Play
> 2.5.4
>
> My problem is that after sometime of running without issue, the nodes
> start having trouble communicating with each other. Within 24 hours of
> bringing the cluster members online, the logs start to display the
> following:
>
> [WARN] [12/16/2016 21:07:32.645] [a.r.ReliableDeliverySupervisor] [akka.
> tcp://application@host1:2552/system/endpointManager/
> reliableEndpointWriter-akka.tcp%3A%2F%2Fapplication%40host2%3A2552-588]
> Association with remote system [akka.tcp://host2:2552] has failed, address
> is now gated for [5000] ms. Reason: [Disassociated]
>
> A service is used to monitor cluster health, at this time it starts to
> report that cluster members are unreachable from each other.
>
> Obviously this starts to cause problems with cluster behavior, and also
> results in messages stating the Leader can currently not perform its duties:
>
> [INFO] [12/16/2016 21:05:48.440] [a.c.Cluster(akka://application)]
> [akka.cluster.Cluster(akka://application)] Cluster Node
> [akka.tcp://application@host1:2552] - Leader can currently not perform
> its duties, reachability status: [akka.tcp://application@host1:2552 ->
> akka.tcp://application@host2:2552: Unreachable [Unreachable] (328),
> akka.tcp://application@host1:37770 -> akka.tcp://application@host2:2552:
> Unreachable [Unreachable] (1), akka.tcp://application@host2:2552 ->
> akka.tcp://application@host1:2552: Reachable [Reachable] (616),
> akka.tcp://application@host2:2552 -> akka.tcp://application@host1:37770:
> Unreachable [Unreachable] (617)], member status:
> [akka.tcp://application@host1:2552 Up seen=true,
> akka.tcp://application@host1:37770 Up seen=false,
> akka.tcp://application@host2:2552 Leaving seen=false]
>
>
> I have turned on Akka debug logging but the only further messages around
> the time of Disassociation I see are:
>
> [DEBUG] [12/16/2016 21:42:58.893] [application-akka.actor.default-
> dispatcher-24] [akka.tcp://application@host1:37770/system/cluster/core/daemon]
> Cluster Node [akka.tcp://application@host1:37770] - Receiving gossip from
> [UniqueAddress(akka.tcp://application@host2:2552,921200398)]
>
> and
>
> [DEBUG] [12/16/2016 21:06:03.310] [a.r.EndpointWriter] [akka.tcp:
> //application@host1:2552/system/endpointManager/
> reliableEndpointWriter-akka.tcp%3A%2F%2Fapplication%40host2%3A2552-588/endpointWriter]
> Drained buffer with maxWriteCount: 50, fullBackoffCount: 1,
> smallBackoffCount: 0, noBackoffCount: 0 , adaptiveBackoff: 1000
>
>
>
> Here is the configuration being used for Web:
>
> akka {
>   actor {
> provider = "akka.cluster.ClusterActorRefProvider"
>   }
>
>   remote {
> secure-cookie = "9C7BBB890AB2C39691FC7B2A34F616C1D87FCC5B"
> require-cookie = on
> netty.tcp {
>   hostname = "localhost"
>   hostname = *$*{?HOSTNAME}
>   port = 2552
> }
> log-remote-lifecycle-events = off
>   }
>
>   cluster {
> failure-detector.threshold = 10
> pub-sub {
>   name = distributedPubSubMediator
>   routing-logic = round-robin
>   gossip-interval = 1s
>   removed-time-to-live = 60s
>   max-delta-elements = 3000
> }
>
> roles = ["Web"]
>
> seed-nodes = "akka.tcp://application@host1:2552"
>
>   }
>
>   loglevel = "DEBUG"
>   log-dead-letters-during-shutdown = off
>   log-dead-letters = off
>
>   extensions = ["akka.cluster.pubsub.DistributedPubSub"]
> }
>
> with JAVA_OPTS="
> ...
>
> -XX:HeapDumpPath=$HOME/log/ \
> -XX:+UseG1GC \
> -XX:MaxGCPauseMillis=300 \
> -XX:G1HeapWastePercent=20 \
> -XX:InitiatingHeapOccupancyPercent=75 \
> -XX:ConcGCThreads=32 \
> -XX:ParallelGCThreads=48 \
> -XX:NewRatio=1 \
> -verbose:gc \
> -XX:+UseGCLogFileRotation \
> -XX:NumberOfGCLogFiles=1 \
> -XX:GCLogFileSize=512M \
> -XX:+PrintGCDetails \
> -XX:+PrintGCTimeStamps \
> -Xloggc:$HOME/log/services_web_gc.log
> "
>
> With *very* similar config for DataDig.
>
> These hosts are very powerful machines that are not running any other
> resource heavy processes (in fact they're barely running anything else at
> all). There are a few GC pauses that are longer than I would expect.
>
>
> Any help is appreciated, and I can provide any further context/information.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >> Search the archives: ht

Re: [akka-user] akka streams graph is not fully drained when Future[Done] completes

[Viktor Klang]

Is this really a *minimized* reproducer?

On Fri, Dec 16, 2016 at 11:09 PM,  wrote:

> Here's the code to reproduce. The issue only seems to occur with my custom
> Source and using a callback in a Flow and while parallelizing. If this code
> is run with  .via(parallelizeFlow(parallelize = 1, asyncFlow)) it drops
> the last minute, but when run with .via(asyncFlow) it does not.
>
> So with parallelize it prints all but the last minute:
>
> seq is Vector(2016/12/14/23/50, 2016/12/14/23/51, 2016/12/14/23/52,
> 2016/12/14/23/53, 2016/12/14/23/54, 2016/12/14/23/55, 2016/12/14/23/56,
> 2016/12/14/23/57, 2016/12/14/23/58)
>
> and without it prints the expected value, with all minutes flowing through
> the graph:
>
> seq is Vector(2016/12/14/23/50, 2016/12/14/23/51, 2016/12/14/23/52,
> 2016/12/14/23/53, 2016/12/14/23/54, 2016/12/14/23/55, 2016/12/14/23/56,
> 2016/12/14/23/57, 2016/12/14/23/58, 2016/12/14/23/59)
>
>
>
>
>
> package hack.streams
>
> import akka.NotUsed
> import akka.stream._
> import akka.stream.scaladsl.{Balance, Flow, GraphDSL, Merge, Sink, Source}
> import akka.stream.stage._
> import org.joda.time.{DateTime, Duration, Interval}
>
> import scala.collection.immutable.Seq
> import scala.concurrent.{Await, Future}
>
> object AsyncIssue {
>   import StreamsMaterializer._
>
>   def minuteSource(interval: Interval) = new 
> GraphStage[SourceShape[DateTime]]() {
> val out = Outlet[DateTime]("keys")
> val shape = SourceShape(out)
>
> def zeroToMinute(date: DateTime) = 
> date.withMillisOfSecond(0).withSecondOfMinute(0)
>
> override def createLogic(inheritedAttributes: Attributes): 
> GraphStageLogic = new GraphStageLogic(shape) with StageLogging {
>   var isDone: Boolean = false
>   var current: DateTime = new DateTime(0)
>
>   override def preStart() = {
> current = zeroToMinute(interval.getStart)
>   }
>
>   setHandler(out,
> new OutHandler {
>   override def onPull(): Unit = {
> if (!isDone) {
>   push(out, current)
>   current = current.plusMinutes(1)
>
>   if (current.isEqual(zeroToMinute(interval.getEnd))) {
> isDone = true
>   }
> } else {
>   complete(out)
> }
>   }
> })
> }
>   }
>
>   def futureCallbackFlow = new GraphStage[FlowShape[DateTime, String]]() {
> val in = Inlet[DateTime]("minute")
> val out = Outlet[String]("string")
>
> val formatter = 
> org.joda.time.format.DateTimeFormat.forPattern("/MM/dd/HH/mm")
>
> val shape = FlowShape.of(in, out)
>
> override def createLogic(inheritedAttributes: Attributes): 
> GraphStageLogic = new GraphStageLogic(shape) with StageLogging {
>   val pushCallback = getAsyncCallback[String] { seq =>
> push(out, seq)
>   }
>
>   setHandler(in, new InHandler {
> override def onPush(): Unit = {
>   val minute = grab(in)
>
>   val fMin: Future[DateTime] = Future {minute}
>
>   fMin.foreach { min =>
> pushCallback.invoke(formatter.print(min))
>   }
> }
>   })
>
>   setHandler(out,
> new OutHandler {
>   override def onPull(): Unit = {
> pull(in)
>   }
> }
>   )
> }
>   }
>
>   def parallelizeFlow[In, Out](parallelize: Int, flow: Flow[In,Out,NotUsed]): 
> Flow[In, Out, NotUsed] = Flow.fromGraph(GraphDSL.create() { implicit builder 
> =>
> import GraphDSL.Implicits._
>
> val dispatcher = builder.add(Balance[In](parallelize))
> val merger = builder.add(Merge[Out](parallelize))
>
> for (i <- 0 to parallelize - 1) {
>   dispatcher.out(i) ~> flow.async ~> merger.in(i)
> }
>
> FlowShape(dispatcher.in, merger.out)
>   })
>
>   def run() = {
> import StreamsMaterializer._
>
> val asyncFlow = Flow[DateTime].via(futureCallbackFlow)
>
> val source: Source[DateTime, NotUsed] = Source(11 to 
> 20).via(Flow[Int].map { num =>
>   val formatter = 
> org.joda.time.format.DateTimeFormat.forPattern("/MM/dd/HH/mm")
>   formatter.parseDateTime(s"2016/12/14/14/$num")
> })
>
> val mat: Future[Seq[String]] = Source.fromGraph(minuteSource(new 
> Interval(Duration.standardMinutes(10), new 
> DateTime().dayOfMonth().roundFloorCopy().minusDays(1
>   .via(parallelizeFlow(parallelize = 1, asyncFlow))
> //  .via(asyncFlow)
>   .runWith(Sink.seq)
>
> val seq: Seq[String] = Await.result(mat, 
> scala.concurrent.duration.Duration.Inf)
> println(s"seq is $seq")
>   }
> }
>
>
>
>
> On Friday, December 16, 2016 at 8:03:45 AM UTC-7, √ wrote:
>>
>> Plase submit a miminized reproducer so readers have a chance of running
>> the code.
>>
>> On Fri, Dec 16, 2016 at 3:44 PM,  wrote:
>>
>>> Hi,
>>>
>>> I'm seeing an issue where the graph completes while there is still data
>>> in one of the flows. The last element emitted by the source enters a custom
>>> GraphStageLogic flow, 

Re: [akka-user] akka streams graph is not fully drained when Future[Done] completes

[Viktor Klang]

Mine [crystal ball] has been in the repair shop the past 5 years and
there's always excuse after excuse why they can't fix it. :(

On Fri, Dec 16, 2016 at 4:05 PM, Konrad Malawski <
konrad.malaw...@lightbend.com> wrote:

> My crystal ball tells me you may be observing timing artifacts which
> originate from the fact that you println one thing, but log the other.
> So there will be a timing difference when one or the other actually hits
> System.out.
>
> Agree with Viktor though, reproducers please for such cases :)
>
>
> --
> Konrad `ktoso` Malawski
> Akka <http://akka.io> @ Lightbend <http://lightbend.com>
>
> On 16 December 2016 at 16:03:44, Viktor Klang (viktor.kl...@gmail.com)
> wrote:
>
> Plase submit a miminized reproducer so readers have a chance of running
> the code.
>
> On Fri, Dec 16, 2016 at 3:44 PM,  wrote:
>
>> Hi,
>>
>> I'm seeing an issue where the graph completes while there is still data
>> in one of the flows. The last element emitted by the source enters a custom
>> GraphStageLogic flow, where it is sent to a function that returns a Future.
>> That Future has a callback which invokes getAsyncCallback and then
>> push(out). For the last element, the Future callback fires (pushCallback
>> .invoke(xml)) but the AsyncCallback is never invoked and the graph stops.
>>
>> For more context, this is what I have going on inside the GraphStageLogic:
>>
>> val s3ListBucket: Source[ByteString, NotUsed] =
>>   s3Client.listBucket(bucket, Some(currentPrefix), maxKeys, nextMarker)
>>
>> val bucketListingXml: Future[String] = s3ListBucket
>>   .map(_.utf8String)
>>   .runWith(Sink.seq)(materializer)
>>   .map(_.mkString)(materializer.executionContext)
>>
>>
>> bucketListingXml.foreach {
>> xml =>
>>
>>   println(s"This gets called. prefix $currentPrefix")
>>
>>   pushCallback.invoke(xml)
>>   }(materializer.executionContext)
>>
>>
>> And the callback
>>
>>
>> val pushCallback = getAsyncCallback[String] { xml =>
>>   log.info(s"This is never called for last element in graph!")
>>   push(out, xml)
>> }
>>
>>
>> I don't see any errors and this issue consistently occurs on the last
>> element. Thanks
>>
>> Andrew
>>
>> --
>> >>>>>>>>>> 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/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 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 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 streams graph is not fully drained when Future[Done] completes

[Viktor Klang]

Plase submit a miminized reproducer so readers have a chance of running the
code.

On Fri, Dec 16, 2016 at 3:44 PM,  wrote:

> Hi,
>
> I'm seeing an issue where the graph completes while there is still data in
> one of the flows. The last element emitted by the source enters a custom
> GraphStageLogic flow, where it is sent to a function that returns a Future.
> That Future has a callback which invokes getAsyncCallback and then
> push(out). For the last element, the Future callback fires (pushCallback
> .invoke(xml)) but the AsyncCallback is never invoked and the graph stops.
>
> For more context, this is what I have going on inside the GraphStageLogic:
>
> val s3ListBucket: Source[ByteString, NotUsed] =
>   s3Client.listBucket(bucket, Some(currentPrefix), maxKeys, nextMarker)
>
> val bucketListingXml: Future[String] = s3ListBucket
>   .map(_.utf8String)
>   .runWith(Sink.seq)(materializer)
>   .map(_.mkString)(materializer.executionContext)
>
>
>   bucketListingXml.foreach {
> xml =>
>
>   println(s"This gets called. prefix $currentPrefix")
>
> pushCallback.invoke(xml)
> }(materializer.executionContext)
>
>
> And the callback
>
>
> val pushCallback = getAsyncCallback[String] { xml =>
>   log.info(s"This is never called for last element in graph!")
>   push(out, xml)
> }
>
>
> I don't see any errors and this issue consistently occurs on the last
> element. Thanks
>
> Andrew
>
> --
> >> 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 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] What's wrong with value classes as parameters?

[Viktor Klang]

You missed that they are value classes. ;)

Try:

val valueRef = system.actorOf {
 Props(classOf[ValueActor], 10)
}


On Thu, Dec 15, 2016 at 8:28 AM, Dmb  wrote:

> I'm reading the documentation
>  about
> actors and now I'm at the section about actor creation. This is an example
> I tried:
>
>
>> case class MyValueClass(v: Int) extends AnyVal
>>
>> class ValueActor(v: MyValueClass) extends Actor {
>>  override def receive: Receive = {
>>  case _ => println("Received message")
>>  }
>> }
>>
>>
> When creating the actor as following:
>
> val valueRef = system.actorOf {
>>  Props(classOf[ValueActor], MyValueClass(10))
>> }
>>
>>
> I actually got the *IllegalArgumentException*. But what's wrong with
> that? To me, creating actors with value classes as parameters seems
> completely innocent. What did I miss?
>
> --
> >> 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 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] Unit test for Persistent Actor Replay

[Viktor Klang]

Good question!

The notification of its death hadn't reached the closest of kin (its
parent) so they hadn't even put it in the ground when you proposed to
create a new one and call it the same thing, so they (rightfully so)
objected to that suggestion.

This trips people up every now and then, but I've never seen a proposal to
solve it.

-- 
Cheers,
√

On Dec 2, 2016 02:44, "Richard Rodseth"  wrote:

> We have a unit test for a persistent actor, which instantiates a second
> instance after waiting for termination of the first.
>
> watch(definitionReader)
>
> system.stop(definitionReader)
>
> expectTerminated(definitionReader)
>
> val notificationDefinitionReader2 = system.actorOf(actorProps, actorName)
>
> This test fails intermittently on Bamboo
>
> actor name [name1] is not unique!
>
> Any ideas?
>
>
> --
> >> 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] UnboundedMailbox - One at a Time?

[Viktor Klang]

Hi Kevin,

this is explained in the following section:
http://doc.akka.io/docs/akka/2.4/general/jmm.html#Futures_and_the_Java_Memory_Model

On Mon, Nov 28, 2016 at 8:58 PM, Kevin Meredith 
wrote:

> Thanks, Viktor, for that link.
>
> So, in the following:
>
>1. class MyActor extends Actor {
>2. var state = ...
>3. def receive = {
>4. case _ =>
>5. //Wrongs
>6.
>7. // Very bad, shared mutable state,
>8. // will break your application in weird ways
>9. Future { state = NewState }
>10. anotherActor ? message onSuccess { r => state = r }
>11.
>12. // Very bad, "sender" changes for every message,
>13. // shared mutable state bug
>14. Future { expensiveCalculation(sender()) }
>15.
>16. //Rights
>17.
>18. // Completely safe, "self" is OK to close over
>19. // and it's an ActorRef, which is thread-safe
>20. Future { expensiveCalculation() } onComplete { f => self ! f.value.
>get }
>21.
>22. // Completely safe, we close over a fixed value
>23. // and it's an ActorRef, which is thread-safe
>24. val currentSender = sender()
>25. Future { expensiveCalculation(currentSender) }
>26. }
>27. }
>
> Why is the following call bad?
>
> > Future { state = NewState }
>
> Thanks,
> Kevin
>
> On Monday, November 28, 2016 at 2:49:26 PM UTC-5, √ wrote:
>
>> Hi Kevin,
>>
>> have you read this: http://doc.akka.io/docs/akka/2.4/general/jmm.html ?
>>
>> On Mon, Nov 28, 2016 at 8:44 PM, Kevin Meredith 
>> wrote:
>>
>>> Looking at the Mailboxes
>>> 
>>>  docs,
>>> for the *UnboundedMailbox, *is it true that an Actor with this mailbox
>>> will only read a single message from its mailbox at a time?
>>>
>>> In other words, if mutating a field within an Actor (and within that
>>> Actor alone), is it necessary to use a thread-safe value, i.e.
>>> java.util.concurrent.atomic.AtomicLong versus Scala's native Long?
>>>
>>> Further, in the following example using Scala 2.11.8:
>>>
>>> import akka.actor._
>>>
>>> class SimpleActor extends Actor {
>>>   var x = 0L;
>>>
>>>   def receive =  ??? // does not matter for this question
>>> }
>>>
>>> using the UnboundedMailbox, would `x` ever run into a race condition
>>> as-is?
>>>
>>> --
>>> >> 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 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 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 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] UnboundedMailbox - One at a Time?

[Viktor Klang]

Hi Kevin,

have you read this: http://doc.akka.io/docs/akka/2.4/general/jmm.html ?

On Mon, Nov 28, 2016 at 8:44 PM, Kevin Meredith 
wrote:

> Looking at the Mailboxes
> 
>  docs,
> for the *UnboundedMailbox, *is it true that an Actor with this mailbox
> will only read a single message from its mailbox at a time?
>
> In other words, if mutating a field within an Actor (and within that Actor
> alone), is it necessary to use a thread-safe value, i.e.
> java.util.concurrent.atomic.AtomicLong versus Scala's native Long?
>
> Further, in the following example using Scala 2.11.8:
>
> import akka.actor._
>
> class SimpleActor extends Actor {
>   var x = 0L;
>
>   def receive =  ??? // does not matter for this question
> }
>
> using the UnboundedMailbox, would `x` ever run into a race condition as-is?
>
> --
> >> 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 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 streams - tripped up by buffers

[Viktor Klang]

Sorry for the late response,

sounds like you found a solution to your problem!

On Wed, Nov 23, 2016 at 12:34 PM, Julian Howarth <10.howa...@gmail.com>
wrote:

> Is there any value in this approach for anyone else? Quite happy to raise
> issues/PR if there is.
>
> Thanks,
>
> Julian
>
>
> On Thursday, November 17, 2016 at 5:53:37 PM UTC, Julian Howarth wrote:
>>
>> Viktor,
>>
>> Here's what I came up with: https://gist.github.com/julian
>> howarth/7287a6e6eaf665dd79307aaff6164cd8
>>
>> Performance-wise, with some very casual testing I can't detect much, if
>> any, overhead over the original. Checked with both the vanilla case where
>> each inbound messaga corresponds to one frame, and also where the frames
>> are randomly split across the inbound packets. However, I assume you have a
>> more comprehensive set of tests which could be run.
>>
>> Julian
>>
>>
>>
>> --
> >> 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 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] Line count of each file in a given directory efficiently using akka

[Viktor Klang]

Your use-case sounds like a perfect example of something which would
benefit quite a bit from being based on Akka Streams.

On Wed, Nov 23, 2016 at 11:25 AM, kk k  wrote:

>
> This is my first program in akka so I wanted to know if the below program
> is efficient and is using the advantages of actor model.
>
> --
>
> The program's purpose is to scan a given directory for any files and print
> the number of lines in each file.
>
> 1. The main `Application` class will create the actor system and send a
> Scan message to a `FileScanner` actor.
> 2. The `FileScanner` actor will scan the given directory, and for each
> file it will create a new `FileParser` actor and send a Parse message.
> Also, all the fileparser actors are passed the same Aggregator actor
> Reference.
> 3. The `FileParser` actor will parse the given file, and for each line it
> will send a Line message to the Aggregator Actor.
> 4. The `Aggregator` actor will maintain a count of the number of lines for
> each file in an instance hashmap and will print the line count for each
> "End" message it receives. Once all files are processed, it will shutdown
> the actor system.
>
> --
>
> A few points which I need help on:
>
> 1. There is a separate `FileParser` actor for each file. Is this fine?
> What is the benefit of using a router which routes to FileParser actor?
> Will its use only help in controlling the number of fileparser actors and
> also how load is distributed among these actors?
>
> 2. There is a single Aggregator actor which counts the number of lines for
> each file. It's using an instance `HashMap` and I hope this is fine. Or
> will a separate aggregator actor for each file improve performance?
>
> 3. Also, I am passing the number of files to Aggregator actor while it's
> created so that I can shutdown the actor system once all files are
> processed. If I have a separate Aggregator for each file, I'm not sure how
> to shutdown.
>
> 4. Each file is only sequentially processed i.e a `FileParser` actor is
> reading the file sequentially and and then invoking aggregator for each
> line. Is this fine or can it be improved.
>
> --
>
> **Application**
>
> /**
> * The Application program bootstraps the actorsystem for parsing files in a
> * given directory and finding their linecount
> *
> * @author
> * @version 1.0
> */
> public class Application {
> public void start(String directoryPath) {
> ActorSystem actorSystem = ActorSystem.create("logProcessor");
> ActorRef fileScanner = actorSystem.actorOf(
> Props.create(FileScanner.class), "fileScanner");
> fileScanner.tell(new Scan(directoryPath), ActorRef.noSender());
> }
>
> public static void main(String[] args) {
>
> if (args.length < 1) {
> System.out
> .println("Usage: java -jar log-process-1.0-SNAPSHOT.jar ");
> System.exit(0);
> }
> String path = args[0];
> Application application = new Application();
> application.start(path);
> }
> }
>
> **FileScanner**
>
> /**
> * The FileScanner program scans for files in a given directory
> *
> * @author
> * @version 1.0
> */
> public class FileScanner extends UntypedActor {
>
> public FileScanner() {
> }
>
> /**
> * Invoked by the Actor System to scan a given directory
> *
> * @param message
> *The message to process
> */
> public void onReceive(Object message) {
> ActorRef parser;
> if (message instanceof Scan) {
> Scan scan = (Scan) message;
> System.out.println("Scan directory: " + scan.getDirectory());
>
> // Only top level files in the directory are read.No recursion is
> // done
> File directory = new File(scan.getDirectory());
> // Incase of large number of files,we need to optimize below call.
> File[] files = directory.listFiles();
> // Required to shutdown actorsystem after all files are processed
> int numberOfFiles = 0;
>
> /*
> * To only count the files and ignore any folders
> */
> for (File file : files) {
> if (file.isFile())
> numberOfFiles++;
> }
> ActorRef aggregator = getContext()
> .actorOf(Props.create(Aggregator.class, numberOfFiles),
> "aggregator");
> File file;
> for (int i = 0; i < files.length; i++) {
> file = files[i];
> if (!file.isFile())
> continue;
> System.out.println(file.getName());
>
> /*
> * Use a unique identifier(counter) for actor names as file
> * names can have special characters(ex:readme (copy).md) and
> * hence cannot be directly used as actor names
> *
> * Docs:Actor paths MUST: not start with `$`, // include only
> * ASCII letters and can only contain these special //
> * characters: -_.*$+:@&=,!~';.
> */
> parser = getContext().actorOf(
> Props.create(FileParser.class, aggregator),
> "parser-" + i);
> parser.tell(new Parse(file.getAbsolutePath()), getSelf());
> }
> } else {
> unhandled(message);
> }
> }
> }
>
> **FileParser**
>
> /**
> * The FileScanner program scans for files in a given directory
> *
> * @author
> * @version 1.0
> */
> public class FileParser extends UntypedActor {
>
> /**
> * An aggregator actor reference to send file events to.
> */
> private 

Re: [akka-user] Understanding scala.concurrent.Await#result

[Viktor Klang]

scala> def fut = {
 |   Thread.sleep(5000)
 |   Future(42)
 | }
fut: scala.concurrent.Future[Int]

scala> Await.result( fut, FiniteDuration(1, SECONDS) )
res1: Int = 42

The code above is equivalent of:

Thread.sleep(5000)
val anon = Future(42)
Await.result(anon, FiniteDuration(1, SECONDS))


On Tue, Nov 22, 2016 at 2:44 PM, Kevin Meredith 
wrote:

> Given the following on Scala 2.11.8:
>
> import scala.concurrent.Future
> import scala.concurrent.duration._
> import scala.concurrent.Await
> import scala.concurrent.ExecutionContext.Implicits.global
>
> scala> def fut = {
>  |   Thread.sleep(5000)
>  |   Future(42)
>  | }
> fut: scala.concurrent.Future[Int]
>
> Why does the following not throw a java.util.TimeoutException?
>
> scala> Await.result( fut, FiniteDuration(1, SECONDS) )
> res1: Int = 42
>
> As I understand, Await#result will throw if the time-out, i.e. its second
> argument, completes before the completion of the Future.
>
> If that's true, then why does 42 return in the above example instead of an
> exception?
>
> --
> >> 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 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] Future#mapTo versus Future.successful#mapTo?

[Viktor Klang]

On Mon, Nov 21, 2016 at 5:23 PM, Kevin Meredith 
wrote:

> Given:
>
> $scala
> Welcome to Scala 2.11.8 (Java HotSpot(TM) 64-Bit Server VM, Java
> 1.8.0_101).
> Type in expressions for evaluation. Or try :help.
>
> import scala.concurrent.Future
> import scala.concurrent.ExecutionContext.Implicits.global
>
> Why does `Future[Any]#mapTo` appear to behave differently than
> `Future.successful[Any]#mapTo`?
>

Because Future.apply is analogous to Future.successful(()).map(_ =>
x).mapTo and not Future.successful(x).mapTo


>
> scala> Future[Any](42).mapTo[Int]
> res1: scala.concurrent.Future[Int] = Success(42)
>

You're exercising a race-condition here. :)


>
> scala> Future[Any](42).mapTo[String]
> res2: scala.concurrent.Future[String] = List() // returns List()
>

Is fixed in 2.12.0 and will be fixed with 2.11.9:
https://issues.scala-lang.org/browse/SI-9488


>
> scala> Future.successful[Any](42).mapTo[Int]
> res3: scala.concurrent.Future[Int] = Success(42)
>
> scala> Future.successful[Any](42).mapTo[String]
> res4: scala.concurrent.Future[String] = Failure(java.lang.ClassCastException:
> Cannot cast java.lang.Integer to java.lang.String) // returns Failure
>
> --
> >> 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 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] Illegal Authorization Header

[Viktor Klang]

What does the RFC say about allowed characters in headers?

-- 
Cheers,
√

On Nov 16, 2016 20:52,  wrote:

> Hi,
>
> I am using akka-http in which I have implemented a custom authorization
> scheme (based on AWS' auth) which takes the header form "Authorization:
> CSTM uuid:signature"
>
> The problem is that I am getting a ton of log spam like the following:
>
> [WARN] [11/16/2016 11:43:37.341] [pwnd-akka.actor.default-dispatcher-20]
> [akka.actor.ActorSystemImpl(pwnd)] Illegal request header: Illegal
> 'authorization' header: Invalid input ':', expected token68-start, '=',
> OWS, 'EOI', tchar or ws (line 1, column 41): CSTM xxx----
> xxx:wArKQNT6Q7I148t/QGtX9zTfsHxkIZR4Rl77zxxZSD8=
>
> As far as I know there's nothing actually illegal about this format (not
> recommended perhaps?). What is the recommended way to address this problem?
> Should I reformat the header? Can I simply suppress these warnings? If
> suppressing the warnings is the suggested route is there a way to only
> suppress messages for the authorization header instead of a broad suppress.
>
> Thanks in advance,
>
> Jean-Philippe
>
> --
> >> 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] Akka streams - tripped up by buffers

[Viktor Klang]

On Wed, Nov 16, 2016 at 2:24 PM, Julian Howarth <10.howa...@gmail.com>
wrote:

>
> On Wednesday, November 16, 2016 at 11:04:55 AM UTC, √ wrote:
>>
>> How would auxiliary stages know which index the accumulation started at?
>>
>
> That's where I was hoping an appropriate buffer stage could help, by just
> keeping the one that corresponds to the initial packet after the
> accumulator has emitted. But if not ...
>

Seems like a "guesswork stage" :S


>
> The actual use case is for receiving chunked packets over a TCP stream so
> that I could keep track of when the first chunk arrived. I was hoping to
> use the built in Framing.lengthField flow, but will just implement it
> myself, keeping track of the timestamp. As an aside, is there any general
> value in extending that framing flow to allow storing additional state? For
> instance, in addition to tracking the timestamp, I am also extracting the
> original ip address using proxy protocol.
>

If you come up with a low-to-no-overhead solution for that which is a
drop-in replacement for the current one then I'd really like to have a look
at it. :)


>
>
>>
>> On Wed, Nov 16, 2016 at 12:02 PM, Julian Howarth <10.ho...@gmail.com>
>> wrote:
>>
>>> Thanks Viktor,
>>>
>>> But as I said, I don't have access to change the accumulator flow - it's
>>> a black box that I otherwise would have to reimplement myself. That's why
>>> I'm trying to work around it with the Graph DSL.
>>>
>>> Julian
>>>
>>>
>>> On Wednesday, November 16, 2016 at 10:05:27 AM UTC, √ wrote:

 val accumulator =
   Flow[Int]
 .statefulMapConcat { () ⇒
   var total = 0
   var curIdx = 0L
   var startIdx = curIdx
   i ⇒ {
 val newTotal = total + i
 if (newTotal >= 10) {
   val result = List((newTotal, startIdx))
   curIdx += 1
   startIdx = curIdx
   total = 0
   result
 } else {
   val result = List.empty[(Int, Long)]
   curIdx += 1
   total = newTotal
   result
 }
   }
 }


 On Wed, Nov 16, 2016 at 10:18 AM, Julian Howarth <10.ho...@gmail.com>
 wrote:

> I have what seems a very simple problem but cannot come up with a
> solution for it.
> Firstly, I have a flow that does some accumulation, therefore only
> emits after it has received a number of elements. As a simple example:
>
> val accumulator =
>   Flow[Int]
> .statefulMapConcat { () ⇒
>   var total = 0
>   i ⇒ {
> val newTotal = total + i
> if (newTotal >= 10) {
>   total = 0
>   List(newTotal)
> }
> else {
>   total = newTotal
>   List()
> }
>   }
> }
>
>
> This works as expected:
>
> val result = Source(List(2, 5, 6, 3, 8, 4, 1, 8, 7, 4))
>   .via(accumulator)
>   .runWith(Sink.fold(Seq.empty[Int])(_ :+ _))
>
> result.futureValue shouldBe Seq(13, 11, 13, 11)
>
>
> Now, I want to record the index of the first element which started the
> accumulation. In my actual application this is a java.time.Instant, but
> Long suffices for this example. As a first naive attempt, using the Graph
> DSL:
>
> val flow =
>   Flow[(Int, Long)]
> .via(Flow.fromGraph(GraphDSL.create() { implicit builder ⇒
>   import GraphDSL.Implicits._
>   val unzip = builder.add(Unzip[Int, Long]())
>   val acc = builder.add(accumulator)
>   val zip = builder.add(Zip[Int, Long]())
>
>   unzip.out0 ~> acc ~> zip.in0
>   unzip.out1 ~>zip.in1
>
>   FlowShape[(Int, Long), (Int, Long)](unzip.in, zip.out)
> }))
>
> val result = Source(List(2, 5, 6, 3, 8, 4, 1, 8, 7, 4)).zipWithIndex
>   .via(flow)
>   .runWith(Sink.fold(Seq.empty[(Int, Long)])(_ :+ _))
>
> result.futureValue shouldBe Seq((13, 0), (11, 3), (13, 5), (11, 8))
>
>
> which times out as no elements flow through. So adding a buffer:
>
> val flow =
>   Flow[(Int, Long)]
> .via(Flow.fromGraph(GraphDSL.create() { implicit builder ⇒
>   import GraphDSL.Implicits._
>   val unzip = builder.add(Unzip[Int, Long]())
>   val acc = builder.add(accumulator)
>   val zip = builder.add(Zip[Int, Long]())
>
>   val buffer = builder.add(Flow[Long].buffer(1, 
> OverflowStrategy.dropTail))
>
>   unzip.out0 ~> acc~> zip.in0
>   unzip.out1 ~> buffer ~> zip.in1
>
>   FlowShape[(Int, Long), (Int, Long)](unzip.in, zip.out)
> }))
>
>
> and I get output, but not what I need:
>
> List((13,0), (11,2), (13,4), (11,7)) was not equal to List((13,0),
> (11,3), (13,5), (11,8))
>
> I think I know what is happening -

Re: [akka-user] Akka streams - tripped up by buffers

[Viktor Klang]

How would auxiliary stages know which index the accumulation started at?

On Wed, Nov 16, 2016 at 12:02 PM, Julian Howarth <10.howa...@gmail.com>
wrote:

> Thanks Viktor,
>
> But as I said, I don't have access to change the accumulator flow - it's a
> black box that I otherwise would have to reimplement myself. That's why I'm
> trying to work around it with the Graph DSL.
>
> Julian
>
>
> On Wednesday, November 16, 2016 at 10:05:27 AM UTC, √ wrote:
>>
>> val accumulator =
>>   Flow[Int]
>> .statefulMapConcat { () ⇒
>>   var total = 0
>>   var curIdx = 0L
>>   var startIdx = curIdx
>>   i ⇒ {
>> val newTotal = total + i
>> if (newTotal >= 10) {
>>   val result = List((newTotal, startIdx))
>>   curIdx += 1
>>   startIdx = curIdx
>>   total = 0
>>   result
>> } else {
>>   val result = List.empty[(Int, Long)]
>>   curIdx += 1
>>   total = newTotal
>>   result
>> }
>>   }
>> }
>>
>>
>> On Wed, Nov 16, 2016 at 10:18 AM, Julian Howarth <10.ho...@gmail.com>
>> wrote:
>>
>>> I have what seems a very simple problem but cannot come up with a
>>> solution for it.
>>> Firstly, I have a flow that does some accumulation, therefore only emits
>>> after it has received a number of elements. As a simple example:
>>>
>>> val accumulator =
>>>   Flow[Int]
>>> .statefulMapConcat { () ⇒
>>>   var total = 0
>>>   i ⇒ {
>>> val newTotal = total + i
>>> if (newTotal >= 10) {
>>>   total = 0
>>>   List(newTotal)
>>> }
>>> else {
>>>   total = newTotal
>>>   List()
>>> }
>>>   }
>>> }
>>>
>>>
>>> This works as expected:
>>>
>>> val result = Source(List(2, 5, 6, 3, 8, 4, 1, 8, 7, 4))
>>>   .via(accumulator)
>>>   .runWith(Sink.fold(Seq.empty[Int])(_ :+ _))
>>>
>>> result.futureValue shouldBe Seq(13, 11, 13, 11)
>>>
>>>
>>> Now, I want to record the index of the first element which started the
>>> accumulation. In my actual application this is a java.time.Instant, but
>>> Long suffices for this example. As a first naive attempt, using the Graph
>>> DSL:
>>>
>>> val flow =
>>>   Flow[(Int, Long)]
>>> .via(Flow.fromGraph(GraphDSL.create() { implicit builder ⇒
>>>   import GraphDSL.Implicits._
>>>   val unzip = builder.add(Unzip[Int, Long]())
>>>   val acc = builder.add(accumulator)
>>>   val zip = builder.add(Zip[Int, Long]())
>>>
>>>   unzip.out0 ~> acc ~> zip.in0
>>>   unzip.out1 ~>zip.in1
>>>
>>>   FlowShape[(Int, Long), (Int, Long)](unzip.in, zip.out)
>>> }))
>>>
>>> val result = Source(List(2, 5, 6, 3, 8, 4, 1, 8, 7, 4)).zipWithIndex
>>>   .via(flow)
>>>   .runWith(Sink.fold(Seq.empty[(Int, Long)])(_ :+ _))
>>>
>>> result.futureValue shouldBe Seq((13, 0), (11, 3), (13, 5), (11, 8))
>>>
>>>
>>> which times out as no elements flow through. So adding a buffer:
>>>
>>> val flow =
>>>   Flow[(Int, Long)]
>>> .via(Flow.fromGraph(GraphDSL.create() { implicit builder ⇒
>>>   import GraphDSL.Implicits._
>>>   val unzip = builder.add(Unzip[Int, Long]())
>>>   val acc = builder.add(accumulator)
>>>   val zip = builder.add(Zip[Int, Long]())
>>>
>>>   val buffer = builder.add(Flow[Long].buffer(1, 
>>> OverflowStrategy.dropTail))
>>>
>>>   unzip.out0 ~> acc~> zip.in0
>>>   unzip.out1 ~> buffer ~> zip.in1
>>>
>>>   FlowShape[(Int, Long), (Int, Long)](unzip.in, zip.out)
>>> }))
>>>
>>>
>>> and I get output, but not what I need:
>>>
>>> List((13,0), (11,2), (13,4), (11,7)) was not equal to List((13,0),
>>> (11,3), (13,5), (11,8))
>>>
>>> I think I know what is happening - the first Long element is buffered in
>>> the zip stage and so the element in the buffer is not actually the one I
>>> expect. But I don't know how to get around it. Using conflate ends up with
>>> exactly the same result
>>>
>>> Note that I can't easily rewrite the accumulator stage, if I could I
>>> would just process the pairs together in a stateful stage.
>>>
>>> Thanks,
>>>
>>> Julian
>>>
>>> --
>>> >> 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 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.

Re: [akka-user] Akka streams - tripped up by buffers

[Viktor Klang]

val accumulator =
  Flow[Int]
.statefulMapConcat { () ⇒
  var total = 0
  var curIdx = 0L
  var startIdx = curIdx
  i ⇒ {
val newTotal = total + i
if (newTotal >= 10) {
  val result = List((newTotal, startIdx))
  curIdx += 1
  startIdx = curIdx
  total = 0
  result
} else {
  val result = List.empty[(Int, Long)]
  curIdx += 1
  total = newTotal
  result
}
  }
}


On Wed, Nov 16, 2016 at 10:18 AM, Julian Howarth <10.howa...@gmail.com>
wrote:

> I have what seems a very simple problem but cannot come up with a solution
> for it.
> Firstly, I have a flow that does some accumulation, therefore only emits
> after it has received a number of elements. As a simple example:
>
> val accumulator =
>   Flow[Int]
> .statefulMapConcat { () ⇒
>   var total = 0
>   i ⇒ {
> val newTotal = total + i
> if (newTotal >= 10) {
>   total = 0
>   List(newTotal)
> }
> else {
>   total = newTotal
>   List()
> }
>   }
> }
>
>
> This works as expected:
>
> val result = Source(List(2, 5, 6, 3, 8, 4, 1, 8, 7, 4))
>   .via(accumulator)
>   .runWith(Sink.fold(Seq.empty[Int])(_ :+ _))
>
> result.futureValue shouldBe Seq(13, 11, 13, 11)
>
>
> Now, I want to record the index of the first element which started the
> accumulation. In my actual application this is a java.time.Instant, but
> Long suffices for this example. As a first naive attempt, using the Graph
> DSL:
>
> val flow =
>   Flow[(Int, Long)]
> .via(Flow.fromGraph(GraphDSL.create() { implicit builder ⇒
>   import GraphDSL.Implicits._
>   val unzip = builder.add(Unzip[Int, Long]())
>   val acc = builder.add(accumulator)
>   val zip = builder.add(Zip[Int, Long]())
>
>   unzip.out0 ~> acc ~> zip.in0
>   unzip.out1 ~>zip.in1
>
>   FlowShape[(Int, Long), (Int, Long)](unzip.in, zip.out)
> }))
>
> val result = Source(List(2, 5, 6, 3, 8, 4, 1, 8, 7, 4)).zipWithIndex
>   .via(flow)
>   .runWith(Sink.fold(Seq.empty[(Int, Long)])(_ :+ _))
>
> result.futureValue shouldBe Seq((13, 0), (11, 3), (13, 5), (11, 8))
>
>
> which times out as no elements flow through. So adding a buffer:
>
> val flow =
>   Flow[(Int, Long)]
> .via(Flow.fromGraph(GraphDSL.create() { implicit builder ⇒
>   import GraphDSL.Implicits._
>   val unzip = builder.add(Unzip[Int, Long]())
>   val acc = builder.add(accumulator)
>   val zip = builder.add(Zip[Int, Long]())
>
>   val buffer = builder.add(Flow[Long].buffer(1, 
> OverflowStrategy.dropTail))
>
>   unzip.out0 ~> acc~> zip.in0
>   unzip.out1 ~> buffer ~> zip.in1
>
>   FlowShape[(Int, Long), (Int, Long)](unzip.in, zip.out)
> }))
>
>
> and I get output, but not what I need:
>
> List((13,0), (11,2), (13,4), (11,7)) was not equal to List((13,0), (11,3),
> (13,5), (11,8))
>
> I think I know what is happening - the first Long element is buffered in
> the zip stage and so the element in the buffer is not actually the one I
> expect. But I don't know how to get around it. Using conflate ends up with
> exactly the same result
>
> Note that I can't easily rewrite the accumulator stage, if I could I would
> just process the pairs together in a stateful stage.
>
> Thanks,
>
> Julian
>
> --
> >> 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 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] Server Sent Events with Play and Actor

[Viktor Klang]

Hi Alexandre,

perhaps if you describe what you are trying to do, then the readers can
suggest different solutions which might fit the use case?

On Fri, Nov 11, 2016 at 12:43 PM, Alexandre Masselot <
alexandre.masse...@gmail.com> wrote:

>
> Thanks √ ,
> Your feedback makes real sense. But I'm nonetheless confused about how to
> make it work:)
>
> Alex
>
> On Friday, November 11, 2016 at 11:38:48 AM UTC+1, √ wrote:
>>
>> Because in your actor example you're confusing the materialization of one
>> flow with the returning of another.
>>
>> On Fri, Nov 11, 2016 at 11:29 AM, Alexandre Masselot <
>> alexandre...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> I'm a bit stuck and seeking for help;)
>>> A play controller should be producing Server Side Events, tying the
>>> Source to an Actor. All this seems pretty basic stuff, but for some reasons
>>> I cannot make work.
>>>
>>> I pushed a minimalist project  https://github.com/alexmassel
>>> ot/play-akkastream-sse, but below is the controller code.
>>>
>>> *Story short:* the first stream works (tick), but the second one does
>>> not (actorFlow). More precisely, pushing messages through the Flow via
>>> Source.actorRef see them printed in the flow but not exposed to the http
>>> stream
>>>
>>> Both can be tested with
>>>
>>> curl  -H "Accept: text/event-stream" http://localhost:9000/ticks
>>> curl  -H "Accept: text/event-stream" http://localhost:9000/actor-flow
>>>
>>>
>>>
>>> Thanks a lot for the help,
>>>
>>> Alex
>>>
>>> @Singleton
>>> class StreamController @Inject()()(implicit exec: ExecutionContext,
>>> actorSystem: ActorSystem) extends Controller {
>>>   implicit val materializer = ActorMaterializer()
>>>
>>>
>>>   def tick = Action {
>>> val tickSource = Source.tick(0 millis, 100 millis, "TICK")
>>> Ok.chunked(tickSource via EventSource.flow).as(ContentTy
>>> pes.EVENT_STREAM)
>>>   }
>>>
>>>   def actorFlow = Action {
>>> val source = Source.actorRef[String](10, fail)
>>>   .map({ (x) =>
>>> //the message go through this stage
>>> println(s"through source '$x'")
>>> x
>>>   })
>>>
>>> val ref = Flow[String]
>>>   .to(Sink.ignore)
>>>   .runWith(
>>> source
>>>   )
>>>
>>> //send messages. One is now, oth is delayed
>>> ref ! "PAF"
>>> actorSystem.scheduler.scheduleOnce(1000 milliseconds, ref, "delayed
>>> PIF")
>>>
>>> Ok.chunked(source via EventSource.flow).as(ContentTy
>>> pes.EVENT_STREAM)
>>>   }
>>> }
>>>
>>>
>>>
>>>
>>> --
>>> >> 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 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 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 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] Server Sent Events with Play and Actor

[Viktor Klang]

Because in your actor example you're confusing the materialization of one
flow with the returning of another.

On Fri, Nov 11, 2016 at 11:29 AM, Alexandre Masselot <
alexandre.masse...@gmail.com> wrote:

> Hello,
>
> I'm a bit stuck and seeking for help;)
> A play controller should be producing Server Side Events, tying the Source
> to an Actor. All this seems pretty basic stuff, but for some reasons I
> cannot make work.
>
> I pushed a minimalist project  https://github.com/
> alexmasselot/play-akkastream-sse, but below is the controller code.
>
> *Story short:* the first stream works (tick), but the second one does not
> (actorFlow). More precisely, pushing messages through the Flow via
> Source.actorRef see them printed in the flow but not exposed to the http
> stream
>
> Both can be tested with
>
> curl  -H "Accept: text/event-stream" http://localhost:9000/ticks
> curl  -H "Accept: text/event-stream" http://localhost:9000/actor-flow
>
>
>
> Thanks a lot for the help,
>
> Alex
>
> @Singleton
> class StreamController @Inject()()(implicit exec: ExecutionContext,
> actorSystem: ActorSystem) extends Controller {
>   implicit val materializer = ActorMaterializer()
>
>
>   def tick = Action {
> val tickSource = Source.tick(0 millis, 100 millis, "TICK")
> Ok.chunked(tickSource via EventSource.flow).as(
> ContentTypes.EVENT_STREAM)
>   }
>
>   def actorFlow = Action {
> val source = Source.actorRef[String](10, fail)
>   .map({ (x) =>
> //the message go through this stage
> println(s"through source '$x'")
> x
>   })
>
> val ref = Flow[String]
>   .to(Sink.ignore)
>   .runWith(
> source
>   )
>
> //send messages. One is now, oth is delayed
> ref ! "PAF"
> actorSystem.scheduler.scheduleOnce(1000 milliseconds, ref, "delayed
> PIF")
>
> Ok.chunked(source via EventSource.flow).as(ContentTypes.EVENT_STREAM)
>   }
> }
>
>
>
>
> --
> >> 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 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-remoting with Artery using load balancing/round robbing dns

[Viktor Klang]

Consider that confirmed then. ;)

On Thu, Nov 10, 2016 at 5:12 PM, 
wrote:

> Ok. Just wanted that confirmed. We already have a workaround for it so I
> was mostly just curious to see if it was needed :).
>
> / Johan
>
>
>
> Den torsdag 10 november 2016 kl. 13:03:36 UTC+1 skrev √:
>>
>> the host needs to be a stable identifier.
>>
>> What problem are you trying to solve with the rr dns?
>>
>> On Thu, Nov 10, 2016 at 10:48 AM,  wrote:
>>
>>> Case:
>>>
>>> I have two services (A and B) that wish to talk to each other using
>>> akka-remoting over artery.
>>> Each service executes on it's own machine behind a load balancer mapping
>>> a dns name, e.g. $A resolving -> multiple IP addresses.
>>>
>>> For A to talk to B, we can for example execute:
>>>
>>> // Make request from an A to a B
>>> val b = context.actorSelection(s"akka://$systemName@$B:$port/user/$a
>>> ctorName")
>>> b ! Request()
>>>
>>> where $B is the load balanced address that is resolved to a B instance
>>> (maybe B1, maybe B2.. etc)
>>>
>>> In order for B to receive this message, B would need to have an akka
>>> conf with canonical.hostname = $B. Otherwise artery will filter out these
>>> messages...
>>>
>>> So far, this works. However, now let's say this is bidirectional
>>> communication.
>>> B wants to reply to A's requests, but also, B wants to send its own
>>> independent requests to A and expect A to reply back to B.
>>>
>>> B would then have something like the following code
>>> // Reply from B back to A
>>> def receive {
>>>   case  Request() => sender() ! Reply()
>>> }
>>>
>>> But because A has canonical.hostname set to $A, which is a load balanced
>>> address, the reply could end up at A1, A2 or any Ai for that matter.
>>>
>>> To work around this, all I can think of is to let each actor resolution
>>> actually do a manual dns lookup before calling context.actorSelection.. and
>>> write the explicit resolved address of each actor to their own akka conf.
>>> *Is this conclusion correct?*
>>>
>>> I suspect akka.tcp does not have this problem as sender() would just
>>> re-use the existing tcp connection, but artery being build on udp, will
>>> suffer from the problem above.
>>> Am I missing something? :)
>>>
>>> / Johan
>>>
>>> --
>>> >> 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 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 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 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-remoting with Artery using load balancing/round robbing dns

[Viktor Klang]

the host needs to be a stable identifier.

What problem are you trying to solve with the rr dns?

On Thu, Nov 10, 2016 at 10:48 AM, 
wrote:

> Case:
>
> I have two services (A and B) that wish to talk to each other using
> akka-remoting over artery.
> Each service executes on it's own machine behind a load balancer mapping a
> dns name, e.g. $A resolving -> multiple IP addresses.
>
> For A to talk to B, we can for example execute:
>
> // Make request from an A to a B
> val b = context.actorSelection(s"akka://$systemName@$B:$port/user/$
> actorName")
> b ! Request()
>
> where $B is the load balanced address that is resolved to a B instance
> (maybe B1, maybe B2.. etc)
>
> In order for B to receive this message, B would need to have an akka conf
> with canonical.hostname = $B. Otherwise artery will filter out these
> messages...
>
> So far, this works. However, now let's say this is bidirectional
> communication.
> B wants to reply to A's requests, but also, B wants to send its own
> independent requests to A and expect A to reply back to B.
>
> B would then have something like the following code
> // Reply from B back to A
> def receive {
>   case  Request() => sender() ! Reply()
> }
>
> But because A has canonical.hostname set to $A, which is a load balanced
> address, the reply could end up at A1, A2 or any Ai for that matter.
>
> To work around this, all I can think of is to let each actor resolution
> actually do a manual dns lookup before calling context.actorSelection.. and
> write the explicit resolved address of each actor to their own akka conf.
> *Is this conclusion correct?*
>
> I suspect akka.tcp does not have this problem as sender() would just
> re-use the existing tcp connection, but artery being build on udp, will
> suffer from the problem above.
> Am I missing something? :)
>
> / Johan
>
> --
> >> 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 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-remote docker<->docker works fine with netty.tcp, but fails with artery - ideas?

[Viktor Klang]

looks related

-- 
Cheers,
√

On Nov 9, 2016 20:13,  wrote:

> Well, host <-> docker container artery works (both permutations). It's
> just docker <-> docker on the same host that doesn't.
> So udp forwarding seems to work. I will try to figure out a non-artery way
> of testing udp. Might end up writing a small scala echo server + client
> with udp (im terrible at linux/unix/mac command line tools :))
>
> Also found this, but I'm confused as to what it says. Maybe it is related?
> https://github.com/docker/docker/issues/15127
>
> / Johan
>
>
> Den onsdag 9 november 2016 kl. 19:29:44 UTC+1 skrev Akka Team:
>>
>> Ah, sorry, didn't notice it in the command line.
>>
>> Can you verify with some other tool that you can communicate using udp
>> between the nodes? (using netcat for example)
>>
>> Set logs to debug to see if there is anything helpful in there.
>> Additionally artery contains a "flight recorder" which you can enable
>> using the setting akka.remote.artery.advanced.flight-recorder.enabled,
>> it will write artery related events to a binary logfile, which you can then
>> feed to akka.remote.artery.FlightRecorderDump in akka-remote to get
>> human readable output, it may also contain some hints about what/why/how it
>> is not working.
>>
>> --
>> Johan
>> Akka Team
>>
>> On Wed, Nov 9, 2016 at 7:14 PM,  wrote:
>>
>>> Yes - i Did. Please see my original post for details. You will see that
>>> I use the udp parameter for my docker port forwarding. Also please note
>>> that I've tested artery successfully in docker as long as one of the
>>> applications is running outside docker. However the problem occurs only
>>> when both producer and consumer run in containers. See the test results
>>> table and error log in my previous message for more details.
>>>
>>> /Johan
>>>
>>> --
>>> >>  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 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.
>

-- 
>>  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] Re: Akka-stream - aggregate record counts while writing to a sink, and update an object in the middle of the flow process with the aggregated data.

[Viktor Klang]

Why would it need its own materializer?

On Fri, Nov 4, 2016 at 1:26 PM, Eugene Dzhurinsky 
wrote:

> More I think about is - more I am convinced that this is something that
> must be implemented via nested flows, like - the step to extract the
> initial user profile and then extract all associated records must be
> implemented as a separate Graph, that is invoked as part of transformation
> of the input stream.
>
> So I have a flow nested in another flow with it's own materializer - on
> every user ID from the outer flow I spawn another instance of inner flow
> and wait until it completes, and then send the data down to the appropriate
> sinks.
>
> Am I missing something?
>
> --
> >> 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/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 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 Streams - output CSV - how to know last line so can avoid appending new line character

[Viktor Klang]

You're most welcome.

On Mon, Oct 31, 2016 at 2:49 PM, Gary Malouf  wrote:

> Ah - missed that in the API - thanks for the pointer!
>
> On Mon, Oct 31, 2016 at 9:47 AM, Viktor Klang 
> wrote:
>
>> intersperse?
>>
>> On Mon, Oct 31, 2016 at 2:40 PM, Gary Malouf 
>> wrote:
>>
>>> I am attempting to use Akka streams to read a large amount of data from
>>> a database (in chunks) and output to a CSV on S3.  While it may seem
>>> trivial, I'm trying to find the best way to identify the final line of the
>>> to be created file and avoid putting a new line character at the end of
>>> it.  Is there anyway to do this via the Source API?
>>>
>>> --
>>> >>>>>>>>>> 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+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/c
>> urrent/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/to
>> pic/akka-user/5mZUJzAdacM/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.
>



-- 
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 https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Re: [akka-user] Akka Streams - output CSV - how to know last line so can avoid appending new line character

[Viktor Klang]

intersperse?

On Mon, Oct 31, 2016 at 2:40 PM, Gary Malouf  wrote:

> I am attempting to use Akka streams to read a large amount of data from a
> database (in chunks) and output to a CSV on S3.  While it may seem trivial,
> I'm trying to find the best way to identify the final line of the to be
> created file and avoid putting a new line character at the end of it.  Is
> there anyway to do this via the Source API?
>
> --
> >> 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 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] Some remote nodes not joining the cluster

[Viktor Klang]

Are the hostnames properly configured/DNS:ed?

-- 
Cheers,
√

On Oct 30, 2016 4:45 PM, "Patrik Nordwall" 
wrote:

> The order should not matter. It will retry.
>
> Firewall rules can be unidirectional and then it matters in which
> direction the connection is established.
>
> sön 30 okt. 2016 kl. 15:36 skrev Jegan :
>
> Yes. There are no firewall rules between these machines. I can say this
> because node3 joins the cluster if I start the seed nodes in the order
> node2, node3 and then node1. This would not happen if there was any network
> related issue.
> Does the order of starting seed nodes really matter? The doc says only
> about starting the first seed node. But in this case, if I start the first
> seed node, then not all nodes join the cluster.
>
>
> On Saturday, October 29, 2016 at 5:17:54 AM UTC-7, Patrik Nordwall wrote:
>
> Are you sure that there are no firewall rules or similar that are blocking
> between the nodes?
>
> /Patrik
>
> fre 28 okt. 2016 kl. 16:21 skrev Jegan :
>
> Hi Everyone,
>
> Apologies for a long post. I am using Akka Cluster (version 2.4.10) to
> distribute an incoming HTTP request to a bunch of workers deployed on
> remote machines. I am following below sample from Lightbend. I am using
> Akka HTTP for the front-end role (as a REST layer)
>
> http://www.lightbend.com/activator/template/akka-sample-cluster-scala
>
> The issue is, when I start multiple instances of the worker processes on
> different machines (15 instances on 4 different machines), some of them do
> not join the cluster and hence do not get the work sent by the front-end.
> For debugging, I reduced the problem to just 3 machines and 3 worker
> instances. All of these 3 instances are configured as seed nodes.The 3rd
> node joins the cluster only if I start the nodes in this particular order,
> node 2, node 3 and then node 1. If I start in any other order, node 1 and
> node 2 are forming the cluster, but node 3 never joins them.
>
> But the below Akka documentation says that the first node configured in
> seed-nodes element should be started first (node 1, in this case). The doc
> also says, "Note that you can only join to an existing cluster member,
> which means that for bootstrapping some node must join itself". but, I am
> not sure what does this mean and if I am doing this in my code.
>
> http://doc.akka.io/docs/akka/current/scala/cluster-usage.
> html#Joining_to_Seed_Nodes
>
> Can you help/guide me if there is anything wrong I am doing in my
> configuration/code or if I am missing something obvious. Appreciate your
> help. Below are the other details.
>
> *FrontEnd*
> val config = ConfigFactory.parseString("akka.cluster.roles =
> [frontend]").
>   withFallback(ConfigFactory.load("rr"))
> implicit val system = ActorSystem("APICluster", config)
>
> val server = new HttpServer(host, port)
> Cluster(system) registerOnMemberUp {
>   system.actorOf(Props(classOf[FrontEnd], server, config), name =
> "FrontEnd")
> }
> *BackEnd*
> val config = ConfigFactory.parseString(s"akka.remote.netty.tcp.port=$
> port").
>   withFallback(ConfigFactory.parseString("akka.cluster.roles =
> [backend]")).
>   withFallback(ConfigFactory.load("rr"))
>
> val system = ActorSystem("APICluster", config)
>
> system.actorOf(Props(classOf[Worker]), name = "Worker")
> system.actorOf(Props[MetricsListener], name = "metricsListener")
> *application.conf*
> akka {
>   actor {
> provider = "akka.cluster.ClusterActorRefProvider"
>   }
>   remote {
> log-remote-lifecycle-events = off
> netty.tcp {
>   hostname = "node1"
>   port = 0
> }
>   }
>   cluster {
> seed-nodes = [
>   "akka.tcp://APICluster@node1:2551",
>   "akka.tcp://APICluster@node2:2581",
>   "akka.tcp://APICluster@node3:2591"]
>   }
> }
> *rr.conf*
> akka.cluster.min-nr-of-members = 2
> akka.cluster.role {
>  frontend.min-nr-of-members = 1
>  backend.min-nr-of-members = 2
> }
> akka.actor.deployment {
>  /frontEnd/backendRouter = {
>router = round-robin-group
>nr-of-instances = 20
>routees.paths = ["/user/worker"]
>cluster {
>  enabled = on
>  use-role = backend
>  allow-local-routees = on
>}
>  }
> }
>
> Below are the logs when I started the nodes in the order node1, node2 and
> then node3. Node1 runs both frontend and a worker (2551), as 2 different
> instances, node2 runs a worker (2581) and node3 runs a worker (2591).
>
> *Node1*
> 13:17:27.540UTC INFO [APICluster-akka.actor.default-dispatcher-18]
> akka://APICluster/deadLetters RemoteActorRefProvider$RemoteDeadLetterActorRef
> - Message [akka.cluster.InternalClusterAction$InitJoin$] from
> Actor[akka://APICluster/system/cluster/core/daemon/
> firstSeedNodeProcess-1#-2136455265] to Actor[akka://APICluster/deadLetters]
> was not delivered. [10] dead letters encountered, no more dead letters will
> be logged. This logging can be turned off or adjusted with configuration
> settings 'akka.log-dead-letters' and 'a

Re: [akka-user] Abstracting away CommitableMessage

[Viktor Klang]

In general that would only work for strictly 1:1 Flows.

-- 
Cheers,
√

On Oct 26, 2016 7:00 PM, "Richard Rodseth"  wrote:

> Poorly chosen title.
> By abstract away, I meant I want to reuse an existing Flow rather than
> having to rewrite it to use CommitableMessages all the way through.
> So I think I may need something like a nested flow (the "job") in a stage
> that hangs onto the current CommitableMessage.
>
>
> On Wed, Oct 26, 2016 at 9:23 AM, Viktor Klang 
> wrote:
>
>> what would happen if that stage would silently discard the
>> CommittableMessage?
>>
>> --
>> Cheers,
>> √
>>
>> On Oct 26, 2016 6:09 PM, "Richard Rodseth"  wrote:
>>
>>> I'm planning to use a commitableSource from akka-streams-kafka.
>>>
>>> Is there a way to re-use an existing Flow that knows nothing about
>>> Kafka, extracting the record value and reconstituting the CommitableMessage
>>> at the end of the flow?
>>>
>>> In the past I've experimented with using TypeClasses in my flow
>>> definition signatures, but it got a bit messy.
>>>
>>>
>>> --
>>> >>>>>>>>>> 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+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/c
>> urrent/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.
>

-- 
>>>>>>>>>>  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] Abstracting away CommitableMessage

[Viktor Klang]

what would happen if that stage would silently discard the
CommittableMessage?

-- 
Cheers,
√

On Oct 26, 2016 6:09 PM, "Richard Rodseth"  wrote:

> I'm planning to use a commitableSource from akka-streams-kafka.
>
> Is there a way to re-use an existing Flow that knows nothing about Kafka,
> extracting the record value and reconstituting the CommitableMessage at the
> end of the flow?
>
> In the past I've experimented with using TypeClasses in my flow definition
> signatures, but it got a bit messy.
>
>
> --
> >> 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] Is contents of GraphDSL.create() {..} thread-safe for BidiFlow?

[Viktor Klang]

On Wed, Oct 19, 2016 at 2:43 PM, Alexey Shuksto  wrote:

> 1. Flow itself is a bidi-codec from ByteString to our own Request/Response
> entities. Each Request has Promise[Response] attribute. Shared state is
> more like Map[Request.Id, Promise[Response]] -- because order of Responses
> are not guarantied.
>

Ok, so a sort of "correlator"-stage?


>
> 2. It should have state shared only "inside" this one materialized flow.
>

Yes, so the BidiFlow you create has shared state tied to the intance, not
the mateiralization.
I think you'll need to create a custom GraphStage with a BidiShape.


>
> среда, 19 октября 2016 г., 15:23:04 UTC+3 пользователь √ написал:
>
>>
>>
>> On Wed, Oct 19, 2016 at 2:18 PM, Alexey Shuksto  wrote:
>>
>>> 2 Konrad: Yep, in original question I meant not 'DSL construction time'
>>> but 'execution time' thread-safety. Thanks for clarification.
>>>
>>> 2 Victor: Use case is simple: outgoing flow need to store `Promise` of
>>> future remote response in some shared state which then would be completed
>>> by incoming flow.
>>>
>>
>> So it's a bidirectional buffer of Promises and Futures?
>>
>>
>>
>>
>>> There could be as many promises as there were outgoing messages, but the
>>> order of responses are not guaranteed and there could be additional
>>> messages in incoming flow.
>>>
>>> What do you meant by 'actively prevents multiple materializations'?
>>>
>>
>> What happens when you materialize that bidiflow N times?
>>
>>
>>>
>>> среда, 19 октября 2016 г., 14:29:14 UTC+3 пользователь √ написал:

 Hi Alexey,

 Not only is it not thread-safe, but it also actively prevents multiple
 materializations.

 Perhaps if you state your use-case we can suggest an alternative?

 On Wed, Oct 19, 2016 at 1:24 PM, Alexey Shuksto 
 wrote:

> Hello hAkkers,
>
> Simple example:
> val zipper = BidiFlow.fromGraph(GraphDSL.create() { b =>
>   var counter = 0
>
>   val outbound = b.add(Flow[String].map { str =>
> counter += 1
> str -> counter
>   })
>   val inbound = b.add(Flow[(String, Int)].map { pair =>
> counter -= 1
> pair._1
>   })
>
>   BidiShape.fromFlows(outbound, inbound)
> })
>
> Can I presume that contents of 'build block' is thread-safe or I need
> to guard `counter` somehow (use `AtomicInt` and such)?
>
> Also, do BidiFlow support 'duplex' mode or they process
> incoming/outgoing messages one at time?
>
> --
> >> 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 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/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 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 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 the Google Groups "Akka 
User List" group.
To unsubscribe from this grou

Re: [akka-user] Is contents of GraphDSL.create() {..} thread-safe for BidiFlow?

[Viktor Klang]

On Wed, Oct 19, 2016 at 2:18 PM, Alexey Shuksto  wrote:

> 2 Konrad: Yep, in original question I meant not 'DSL construction time'
> but 'execution time' thread-safety. Thanks for clarification.
>
> 2 Victor: Use case is simple: outgoing flow need to store `Promise` of
> future remote response in some shared state which then would be completed
> by incoming flow.
>

So it's a bidirectional buffer of Promises and Futures?




> There could be as many promises as there were outgoing messages, but the
> order of responses are not guaranteed and there could be additional
> messages in incoming flow.
>
> What do you meant by 'actively prevents multiple materializations'?
>

What happens when you materialize that bidiflow N times?


>
> среда, 19 октября 2016 г., 14:29:14 UTC+3 пользователь √ написал:
>>
>> Hi Alexey,
>>
>> Not only is it not thread-safe, but it also actively prevents multiple
>> materializations.
>>
>> Perhaps if you state your use-case we can suggest an alternative?
>>
>> On Wed, Oct 19, 2016 at 1:24 PM, Alexey Shuksto  wrote:
>>
>>> Hello hAkkers,
>>>
>>> Simple example:
>>> val zipper = BidiFlow.fromGraph(GraphDSL.create() { b =>
>>>   var counter = 0
>>>
>>>   val outbound = b.add(Flow[String].map { str =>
>>> counter += 1
>>> str -> counter
>>>   })
>>>   val inbound = b.add(Flow[(String, Int)].map { pair =>
>>> counter -= 1
>>> pair._1
>>>   })
>>>
>>>   BidiShape.fromFlows(outbound, inbound)
>>> })
>>>
>>> Can I presume that contents of 'build block' is thread-safe or I need to
>>> guard `counter` somehow (use `AtomicInt` and such)?
>>>
>>> Also, do BidiFlow support 'duplex' mode or they process
>>> incoming/outgoing messages one at time?
>>>
>>> --
>>> >> 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 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 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 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 contents of GraphDSL.create() {..} thread-safe for BidiFlow?

[Viktor Klang]

Hi Alexey,

Not only is it not thread-safe, but it also actively prevents multiple
materializations.

Perhaps if you state your use-case we can suggest an alternative?

On Wed, Oct 19, 2016 at 1:24 PM, Alexey Shuksto  wrote:

> Hello hAkkers,
>
> Simple example:
> val zipper = BidiFlow.fromGraph(GraphDSL.create() { b =>
>   var counter = 0
>
>   val outbound = b.add(Flow[String].map { str =>
> counter += 1
> str -> counter
>   })
>   val inbound = b.add(Flow[(String, Int)].map { pair =>
> counter -= 1
> pair._1
>   })
>
>   BidiShape.fromFlows(outbound, inbound)
> })
>
> Can I presume that contents of 'build block' is thread-safe or I need to
> guard `counter` somehow (use `AtomicInt` and such)?
>
> Also, do BidiFlow support 'duplex' mode or they process incoming/outgoing
> messages one at time?
>
> --
> >> 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 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] Re: Akka stream - implements Pause/Resume

[Viktor Klang]

Hi Regis,

unfortunately you're still doing unsafe things (you have a race-condition
in your accesses to bufferedElement)

On Fri, Oct 14, 2016 at 3:56 PM, regis leray  wrote:

> Thanks a lot i succeed, to make it work...
>
> val switch = new ValveSwitch {
>   val callback = getAsyncCallback[A](push(out, _))
>
>   override def open: Unit = {
> mode = ValveMode.Open
> bufferedElement.foreach(callback.invoke)
> bufferedElement = Option.empty
>   }
>
>   override def close: Unit = {
> mode = ValveMode.Closed
>   }
> }
>
>
>
> The whole solution
> https://gist.github.com/regis-leray/013dfe030159bcd890ca0d5cd440c938
>
>
> Le vendredi 14 octobre 2016 08:13:21 UTC-4, Konrad Malawski a écrit :
>>
>> Have you read the blog post?
>> In the async callback you can push(), that's what I meant.
>>
>> --
>> Konrad `ktoso` Malawski
>> Akka  @ Lightbend 
>>
>> On 14 October 2016 at 10:11:09, Konrad 'ktoso' Malawski (kto...@gmail.com)
>> wrote:
>>
>> Please read this:
>> - http://blog.akka.io/integrations/2016/08/29/connecting-existing-apis
>> - and this: http://doc.akka.io/docs/akka/2.4/scala/stream/stream-c
>> ustomize.html
>>
>> Specifically, your trigger should be implemented as async-callback, as it
>> comes from the outside but should "wake up" the stage to be able to push
>> data again.
>> In your current setup it never "wakes up" since all pulls/pushes have
>> been processed - the stage has no idea it should do something once you
>> called open.
>>
>> -- Konrad
>>
>> W dniu piątek, 14 października 2016 09:03:54 UTC+2 użytkownik regis leray
>> napisał:
>>>
>>> Hi,
>>>
>>> Im currently trying to implement a valve Graph to manage pause/resume.
>>> We can control the behavior of the graph by using the MaterializeValue
>>>
>>> trait ValveSwitch {
>>>   def open: Unit
>>>   def close: Unit
>>> }
>>>
>>>
>>> Current implementation of the valve
>>>
>>> class Valve[A](mode: ValveMode = ValveMode.Open) extends 
>>> GraphStageWithMaterializedValue[FlowShape[A, A], ValveSwitch] {
>>>
>>>   override val shape = FlowShape(Inlet[A]("valve.in"), 
>>> Outlet[A]("valve.out"))
>>>
>>>   override def createLogicAndMaterializedValue(inheritedAttributes: 
>>> Attributes): (GraphStageLogic, ValveSwitch) = {
>>> val logic = new ValveGraphStageLogic(shape, mode)
>>> (logic, logic.switch)
>>>   }
>>>
>>> }
>>>
>>>
>>> The current implementation is pretty simple, each time we are receiving
>>> a onPull demand we are requesting by doing pull(in).
>>> When a onPush demand is received we are checking the current state
>>> - if Open we are doing the default behavior by doing push(out,element)
>>> - if Close we are putting the element into a queue
>>>
>>> private class ValveGraphStageLogic(shape: Shape, var mode: ValveMode) 
>>> extends GraphStageLogic(shape){
>>>   import shape._
>>>
>>>   var bufferedElement = List.empty[A]
>>>
>>>   val switch = new ValveSwitch {
>>> override def open: Unit = {
>>>   mode = ValveMode.Open
>>>   println(s"pushing $bufferedElement, out is available ? 
>>> ${isAvailable(out)}")
>>>
>>>   bufferedElement.foreach(push(out, _))
>>>   bufferedElement = List.empty
>>> }
>>>
>>> override def close: Unit = {
>>>   mode = ValveMode.Closed
>>> }
>>>   }
>>>
>>>   setHandler(in, new InHandler {
>>> override def onPush(): Unit = {
>>>   val element = grab(in) //acquires the element that has been received 
>>> during an onPush
>>>   println(s"${mode} on push called with $element")
>>>   if (mode == ValveMode.Open) {
>>> push(out, element) //push directly the element on the out port
>>>   } else {
>>> bufferedElement = bufferedElement :+ element
>>>   }
>>> }
>>>   })
>>>
>>>   setHandler(out, new OutHandler {
>>> override def onPull(): Unit = {
>>>   println("on pull called")
>>>   pull(in) //request the next element on in port
>>> }
>>>   })
>>> }
>>>
>>>
>>> When we are resuming the valve my using the switch.open, we are pushing
>>> the element
>>>
>>> override def open: Unit = {
>>>
>>>   mode = ValveMode.Open
>>>   println(s"pushing $bufferedElement, out is available ? 
>>> ${isAvailable(out)}")
>>>
>>>   bufferedElement.foreach(push(out, _))
>>>   bufferedElement = List.empty
>>> }
>>>
>>>
>>> The Current test is failing
>>>
>>> "A closed valve" should "emit only 3 elements after it has been open" in {
>>>
>>> val (valve, probe) = Source(1 to 5)
>>> .viaMat(new Valve(ValveMode.Closed))(Keep.right) //the current valve by 
>>> default is closed, dont push any message
>>> .toMat(TestSink.probe[Int])(Keep.both)
>>> .run()
>>>
>>>   probe.request(2)
>>>   probe.expectNoMsg()
>>>
>>>   valve.open //open the valve should emit the previous
>>>
>>>
>>>   probe.expectNext shouldEqual 1 //we never receive the element
>>>   probe.expectNext shouldEqual 2
>>>
>>>   probe.request(3)
>>>   probe.expectNext shouldEqual 3
>>>   probe.expectNext shouldEqual 4
>>>   pr

Re: [akka-user] Re: What's the replacement for Akka Actor Publisher and Subscriber?

[Viktor Klang]

RS Backpressure can piggyback on top of TCP, which means HTTP, WebSocket
and HTTP/2 support.
Besides that there's *tons* of integrations (Sources and Sinks) for
networked components.

As if that wasn't enough there's both the ReactiveSocket initiative (
http://reactivesocket.io/) as well as Apache Gearpump (for distributed Akka
Stream materialization support)

On Thu, Oct 13, 2016 at 11:26 PM, Dagny T  wrote:

>
> HOLD ON .. SERIOUSLY?!
>
> So, do I understand correctly that the 'Reactive Manifesto' industry
> coalition among leading thought leaders at Netflix, Pivotal, and Lightbend;
> is for all intents and purposes -- still under construction?
>
> Sorry; I'm just seeking straight answers on this to gauge if this is even
> worthwhile for me to pursue.  Since, my prior interest in this area was
> based on the (mis?)understanding that the Reactive Streams API would
> essentially enable seamless interoperability between Actor-controlled
> Services across a distributed cluster.
> And, that different platform Vendors had agreed to comply with this API to
> permit that interoperability.
>
> If this is not the case -- then at least for me; I don't have bandwidth or
> depth of knowledge for constructing a bleeding-edge proprietary layer above
> TCP to make this happen.
>
> Any authoritative insight on the current state of this inter op situation
> would be VERY much appreciated!  THANKS in advance!
>
>
>
> On Monday, September 26, 2016 at 12:07:55 AM UTC-7, Dagny T wrote:
>
>> Hi there,
>>
>> The latest info I have from a prior Akka Team response was that the Akka
>> Actor Publisher/Subscriber APIs are now deprecated;
>> and one should be looking at the Graph DSL instead.
>>
>> i.e. Latest Akka Docs state:
>> ActorPublisher and ActorSubscriber
>>  cannot be used with remote actors,
>> because if signals of the Reactive Streams protocol (e.g. request) are
>> lost the the stream may deadlock.
>>
>> So, now I'm not clear on what the replacement APIs we're supposed to be
>> using; as far as connecting State-Holding Akka Actors to Graph DSL
>> Event-Streams.
>>
>> Is there an Akka Team Blog with a GitHub link to a small focused example
>> which demonstrates this?
>>
>> THANKS in advance for any help with finding the latest APIs to use for
>> this!
>> Dagny
>>
>>
>> --
> >> 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 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] Missing api GraphStageLogic

[Viktor Klang]

by default scaladoc only shows public members and the methods you are
speaking of are protected, so you need to click "All"

-- 
Cheers,
√

On Oct 13, 2016 8:37 AM, "Ortigali Bazarov" 
wrote:

> In documentation, there is a example how to use GraphStageLogic's pull,
> push, emit and etc methods. But when i looked for their's signature in
> here
> 
>  i
> could not find these methods.
>
> --
> >> 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] How to handle web socket message to upload base64 encoded string of 10mb file

[Viktor Klang]

You're most welcome! :)

On Tue, Oct 11, 2016 at 5:52 PM, Rafał Krzewski 
wrote:

> Right, thanks :)
>
> --
> >>  Read the docs: http://akka.io/docs/
> >>  Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >>  Search the archives: https://groups.google.com/
> group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at 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 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] How to handle web socket message to upload base64 encoded string of 10mb file

[Viktor Klang]

Use: Future.successful(text) iso `Future(text)` (no need to evaluate it
asynchronously)

On Tue, Oct 11, 2016 at 3:58 PM, Rafał Krzewski 
wrote:

> In my particular application the messages I'm receiving a few kB in size.
> Sometimes they arrive as Strict and sometimes as Streaming, but they are
> small enough to be collected and processed as a single chunk. Here's a
> pipeline stage I'm using to handle both cases in an uniform way:
>
>
>
>
>
>
>
>
>
> *val unframing: Flow[Message, String, NotUsed] =  
> Flow.fromFunction[Message, Future[String]](_ match {case 
> TextMessage.Strict(text) =>  Future(text)case 
> TextMessage.Streamed(textStream) =>  textStream.runFold("")(_ + _)
> case _ =>  throw new Exception("unexpected binary message")  
> }).mapAsyncUnordered(1)(identity)*
>
>
> This flow is attached to webSocketClientFlow output.
>
> An alternative solution would be looking up websocket buffering settings
> and jacking it up enough to receive all messages as Strict :)
>
> cheers,
> Rafał
>
> W dniu poniedziałek, 10 października 2016 12:43:20 UTC+2 użytkownik
> Narayan Kumar napisał:
>>
>> thanks  for quick reply rafal .
>> Yes you hav mentioned right , I am getting the 'message does no arrive'
>>  , but not any exception .
>>
>> I have tried with  the TextMessage.Streamed , but no progress from here
>> also . Please find the code below : -
>>
>> case TextMessage.Streamed(stream) => {
>>   stream
>> .limit(1) // Max frames we are willing to wait for
>> .completionTimeout(50 seconds) // Max time until last frame
>> .runFold("")(_ + _) // Merges the frames
>> .flatMap { msg =>
>>   logger.info("Getting streamed message " + msg)
>>   val action = (parse(msg) \ (ACTION)).extractOpt[String]
>>   if (action.isDefined) {
>> action.get match {
>>   case UPDATE_USER_PROFILE =>
>> val userProfile = parse(msg).extractOpt[UserProfileJson].get
>> val cover = userProfile.cover
>> val picture = userProfile.picture
>> val uploadCoverFile = 
>> FileUploadUtility.decodeBase64String(cover.get)
>> val uploadPictureFile = 
>> FileUploadUtility.decodeBase64String(picture.get)
>> println(" 1 " + uploadCoverFile + " @@@  2 " 
>> + uploadPictureFile)
>> Future(TextMessage("File Uploaded"))
>>   case _ => Future(TextMessage(INVALID_ACTION))
>> }
>>   } else {
>> Future(TextMessage(INVALID_ACTION))
>>   }
>> }
>> }
>>
>>
>>
>> Also I cannot test the case  properly cause the web socket client gets
>> hang's every time I send the large file Json.,
>> and using the above code also we are not getting any response back .
>> Please can you suggest any possible way to handle the scenarios.
>>
>>
>> Thanks in advance , waiting for positive early reply :) .
>>
>>
>>
>> On Monday, October 10, 2016 at 3:12:36 PM UTC+5:30, Rafał Krzewski wrote:
>>>
>>> Please elaborate on "unable to handle it" -- are you getting an
>>> exception, message does no arrive, something other?
>>> Also it would be helpful if you showed your code for
>>> TextMessage.Streamed case because that's how large messages would show up.
>>> I don't know the specifics but there appears to be a buffer in Akka
>>> WebSockets client code: if the incoming message fits into this buffer in
>>> full it's sent to the client code as Strict message, but when the message
>>> is too large to fit in the buffer Akka switches to streaming mode: Streamed
>>> message is sent to client code, carrying a stream that will deliver the
>>> message contents in buffer-sized chunks.
>>>
>>> Cheers,
>>> aRafał
>>>
>>>
>>> W dniu poniedziałek, 10 października 2016 08:21:14 UTC+2 użytkownik
>>> Narayan Kumar napisał:



 On Friday, October 7, 2016 at 7:52:03 PM UTC+5:30, √ wrote:
>
> Why are you assuming that it is a Strict message?
>
> On Fri, Oct 7, 2016 at 2:11 PM, Narayan Kumar 
> wrote:
>
>> Hi everyone,
>> Actually i was trying to handle a Web Socket message for base64
>> encoded string of 10mb file.but unable to handle it.
>> is there any way to handle large message please suggest ?
>>
>> Here is the code:
>>
>> def mediaUploadHandler: Flow[Message, Message, _] = {
>> val (accountSource, accountQueue) = sourceQueue
>> Flow[Message]
>>   .collect {
>> case TextMessage.Strict(txt) ⇒ {
>>   logger.info(s"${phoneNumber}: Got the request. Now
>> redirecting to account api ")
>>   val userProfile = parse(txt).extractOpt[UserProf
>> ileJson]
>>   println("user profile is ", userProfile)
>> }
>>
>> case _ => TextMessage(INVALID_ACTION)
>>   }
>>   .via(connectSource(accountSource)) // ... and route them
>> through the receiveNotification ...

Re: [akka-user] Re: [akka-streams] Debug of custom stream processing logic

[Viktor Klang]

happy hakking!

:)

On Tue, Oct 11, 2016 at 11:19 AM, Sergey Sopin  wrote:

> Yep, thanks!
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at 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 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] Re: [akka-streams] Debug of custom stream processing logic

[Viktor Klang]

Neither will the breakpoint (since there's concurrency involved).

On Tue, Oct 11, 2016 at 10:43 AM, Sergey Sopin  wrote:

> It may work, however it will not give me full picture of what is going on.
>
> Thanks.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at 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 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] Re: [akka-streams] Debug of custom stream processing logic

[Viktor Klang]

println?

On Tue, Oct 11, 2016 at 10:36 AM, Sergey Sopin  wrote:

> I agree, but I need to understand that this logic is being called. I do
> not need to debug whole flow, I need only one function inside one shape.
>
> --
> >> 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 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] Re: [akka-streams] Debug of custom stream processing logic

[Viktor Klang]

Akka Streams are executed concurrently. I'm not sure breakpoints make much
sense in this case.

On Tue, Oct 11, 2016 at 10:16 AM, Sergey Sopin  wrote:

> Hi,
>
> The question is still valid :)
>
> Thanks.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ: http://doc.akka.io/docs/akka/
> current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at 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 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.