Re: [akka-user] Re: ANNOUNCE: Akka Streams & HTTP 1.0-RC3

[Roland Kuhn]

Yes, as announced we collapsed the previously half-heartedly separated 
Java/Scala artifacts again, hence no “-scala” in the name anymore.

Regards,

Roland

> 28 maj 2015 kl. 22:14 skrev Jakub Liska :
> 
> Hi, 
> 
> how about these 2 deps? Haven't they been deployed or their name changed? 
> 
> [warn]  ::
> [warn]  ::  UNRESOLVED DEPENDENCIES ::
> [warn]  ::
> [warn]  :: com.typesafe.akka#akka-http-scala-experimental_2.11;1.0-RC3: not 
> found
> [warn]  :: 
> com.typesafe.akka#akka-http-testkit-scala-experimental_2.11;1.0-RC3: not found
> [warn]  ::
> [
> 
> -- 
> >> Read the docs: http://akka.io/docs/ 
> >> Check the FAQ: 
> >> http://doc.akka.io/docs/akka/current/additional/faq.html 
> >> 
> >> Search the archives: https://groups.google.com/group/akka-user 
> >> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to akka-user+unsubscr...@googlegroups.com 
> .
> To post to this group, send email to akka-user@googlegroups.com 
> .
> Visit this group at http://groups.google.com/group/akka-user 
> .
> For more options, visit https://groups.google.com/d/optout 
> .



Dr. Roland Kuhn
Akka Tech Lead
Typesafe  – Reactive apps on the JVM.
twitter: @rolandkuhn
 

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

Re: [akka-user] Re: ANNOUNCE: Akka Streams & HTTP 1.0-RC3

[Jakub Liska]

Hi, 

how about these 2 deps? Haven't they been deployed or their name changed? 

[warn]  ::
[warn]  ::  UNRESOLVED DEPENDENCIES ::
[warn]  ::
[warn]  :: com.typesafe.akka#akka-http-scala-experimental_2.11;1.0-RC3: not 
found
[warn]  :: 
com.typesafe.akka#akka-http-testkit-scala-experimental_2.11;1.0-RC3: not 
found
[warn]  ::
[

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

[akka-user] Re: [akka-stream] How to design stream profiling properly?

[Jakub Liska]

I have this weird problem with probably broken pull demand in a stream of 
this representation : 

Source[Foo]() { implicit b =>
val actorSources = Array(100%CorrectlyImplementedActorPublishers)
b.add(Merge[Foo](actorSources.length))
for (i <- 0 until actorSources.length) {
  b.addEdge(b.add(actorSources(i)), merge.in(i))
}
merge.out
  }
}


+ following 6 Flows doing map/mapAsync with various parallelism and 
Sink.fold.

And from profiling I just did it seems that most of the processing time the 
stream is stuck with 1% CPU usage, because it isn't pulling next elements, 
but I cannot reproduce it...
   

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

[akka-user] Re: RoundRobinRountingLogic: A slightly faster version?

[Guido Medina]

In fact, I think my implementation should not only be faster but it is also 
safer due to the *-unlikely event?-* of reaching Long.MAX_VALUE, a side by 
side comparison:

   - Both implementations "compare and set" the value atomically, but mine 
   does it for an *AtomicInteger vs AtomicLong* which is cheaper.
   - My implementation does one increment of an integer and compare it 
   against the size and return either the new value if less or  equal than 
   size or zero, the original implementation always MOD a long value which 
   according to my research *-not a very extensive one-* moding cost > 
   dividing cost > multiplying cost > incrementing cost

The other issue not strictly related with my implementation is that the 
static and singleton *NoRoutee* instance is a private member of 
*Router.scala* making it unusable for *RoutingLogic* extenders, and Akka 
does use equality *-if routee == NoRoutee then deadletters ! tell...-* which 
makes anyone's custom *RoutingLogic* implementation not able to behave like 
any other Akka provided RoutingLogic so I think it needs to be made public 
and mentioned in the documentation clarifying that returning it from a 
RoutingLogic will drop the message into the dead letters.

Best regards,

Guido.

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

[akka-user] Re: Caching akka futures - is it ok?

[Sam Halliday]

A Future is definitely mutable (it will hopefully complete), but you cannot 
mutate it.

You'd be best caching the result of the Future, rather than the future 
itself.

On Wednesday, 27 May 2015 21:48:52 UTC+1, Moiz Raja wrote:
>
> I have a piece of code where I make a request to an actor using ask and 
> cache the resulting future if that ask was successful. I am seeing problems 
> in this area where when I try to access that "completed" future later on I 
> find (a) that it does not contain a successful future and (b) the resulting 
> timeout exception has a completely unexpected timeout.
>
> This makes me wonder if the ask future that is being returned is something 
> we can cache. Is the future mutable per chance?
>
> Any advise on whether caching is ok or not would be helpful. 
>
> Thanks,
> -Moiz
>

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

[akka-user] Re: RoundRobinRountingLogic: A slightly faster version?

[Guido Medina]

There is one thing to clarify and two differences:

   - There are no locks in atomic operations, remember atomic operations 
   are based on CAS.
   - Incrementing an *AtomicInteger* will definitely be cheaper than 
   incrementing an *AtomicLong.*
   - Comparing the value and returning is definitely cheaper 
   than division/mod operation which is CPU intensive.
   - And last but least important and highly unlikely: No risk of 
   overflowing the counter because the value is always reset to zero.

Though you are right, I should JMH it, let me do that tonight:

Here is what the side-effect function looks like in Java 8:

/**
 * Atomically updates the current value with the results of
 * applying the given function to the current and given values,
 * returning the updated value. The function should be
 * side-effect-free, since it may be re-applied when attempted
 * updates fail due to contention among threads.  The function
 * is applied with the current value as its first argument,
 * and the given update as the second argument.
 *
 * @param x the update value
 * @param accumulatorFunction a side-effect-free function of two arguments
 * @return the updated value
 * @since 1.8
 */
public final int accumulateAndGet(int x,
  IntBinaryOperator accumulatorFunction) {
int prev, next;
do {
prev = get();
next = accumulatorFunction.applyAsInt(prev, x);
} while (!compareAndSet(prev, next));
return next;
}

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

[akka-user] Re: RoundRobinRountingLogic: A slightly faster version?

[Chris Baxter]

Have you profiled this to quantify the performance improvement, and if so, 
did you run it under high contention situations to be sure the locks on the 
atomic don't start to be an issue under high contention?

On Thursday, May 28, 2015 at 11:43:24 AM UTC-4, Guido Medina wrote:
>
> Hi,
>
> I have my own version of a RoundRobinRouting logic which I believe it is 
> faster and less CPU intensive due to no mod math operation, here is my 
> version in Java 8, it has though one small error because NoRoutee instance 
> if private and I don't know much Scala, so here it is a copy/proposal :
>
> public class CircularRoutingLogic implements RoutingLogic {
>
>   final AtomicInteger next = new AtomicInteger(-1);
>
>   @Override
>   public Routee select(Object message, IndexedSeq routees) {
> final int size = routees.size();
>
> // null should be replaced by NoRoutee Akka/Scala instance.
> return size == 0 ? null : routees.apply(next.accumulateAndGet(1, (index, 
> increment) -> ++index >= size ? 0 : index));
>   }
> }
>
>

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

[akka-user] Re: RoundRobinRountingLogic: A slightly faster version?

[Guido Medina]

Also it is unlikely such thing will happen, my atomic integer will never 
overflow because it goes back to zero.

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

[akka-user] RoundRobinRountingLogic: A slightly faster version?

[Guido Medina]

Hi,

I have my own version of a RoundRobinRouting logic which I believe it is 
faster and less CPU intensive due to no mod math operation, here is my 
version in Java 8, it has though one small error because NoRoutee instance 
if private and I don't know much Scala, so here it is a copy/proposal :

public class CircularRoutingLogic implements RoutingLogic {

  final AtomicInteger next = new AtomicInteger(-1);

  @Override
  public Routee select(Object message, IndexedSeq routees) {
final int size = routees.size();

// null should be replaced by NoRoutee Akka/Scala instance.
return size == 0 ? null : routees.apply(next.accumulateAndGet(1, (index, 
increment) -> ++index >= size ? 0 : index));
  }
}

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

Re: [akka-user] Caching akka futures - is it ok?

[Justin du coeur]

What do you mean by "cache" here?  A Future is mostly a Future -- I don't
have any reason to believe there is anything weird about the Futures from
ask -- but I'm not clear what your cache is...

On Wed, May 27, 2015 at 4:48 PM, Moiz Raja  wrote:

> I have a piece of code where I make a request to an actor using ask and
> cache the resulting future if that ask was successful. I am seeing problems
> in this area where when I try to access that "completed" future later on I
> find (a) that it does not contain a successful future and (b) the resulting
> timeout exception has a completely unexpected timeout.
>
> This makes me wonder if the ask future that is being returned is something
> we can cache. Is the future mutable per chance?
>
> Any advise on whether caching is ok or not would be helpful.
>
> Thanks,
> -Moiz
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [akka-user] Convert Source[ByteStream] to Java InputStream

[Michael Hamrah]

In researching how to do this I came across akka.stream.io.OutputStreamSink 
which is exactly what I 
need: 
https://github.com/akka/akka/blob/releasing-akka-stream-and-http-experimental-1.0-RC3/akka-stream/src/main/scala/akka/stream/io/OutputStreamSink.scala

The code snippet is very simple:

val outputStream: () => OutputStream = { () => {
 val pipedOutputStream = new PipedOutputStream()
 //do something with the piped output stream, like connect it to a read 
stream

 //return for later
 pipedOutputStream
}

//somewhere else, maybe in a route:
akkaHttpRequest.entity.getDataBytes.runWith(OutputStreamSink(outputStream), 
flow)

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

[akka-user] [akka-stream] What is the best way to acknowledge completion?

[Dom B]

Hi,

I'm looking at the new Streams API and trying to work out if it's a best 
fit for my use case. The problem I'm having is with acknowledgement.

I have an external system placing requests onto a queue (Beanstalk in this 
case), once the external system receives the OK from beanstalk, like an 
event during replay, I'm committed to preforming that job.

My plan was to build a ActorPublisher based Beanstalk client based on the 
existing Akka IO code, then reserve the jobs on the beanstalk server. This 
starts a time to live on the beanstalk server, if I do not delete or 
release the job within that window, the server will assume I'm dead and 
release the job back onto the queue (
https://github.com/kr/beanstalkd/wiki/faq#how-does-ttr-work). This is 
perfect in a HA system, because if my Akka node dies, beanstalk will simply 
reset the job for another node to process.

My problem is once my ActorPublisher gives the job to the "onNext" method, 
it has no way to track if and when the job is completed, thus the only time 
it can delete from beanstalk is straight away and then I just lost the 
whole advantage of the job TTL. 

I'm leaning towards a Sink such that the stream has to be 
`BeanstalkPublisher ~> F1 ~> F2 ~> BeanstalkDeleter`, but this means the 
data type flowing though F1 and F2 has to include the job id. This makes 
Flow composition a little more annoying as I had planned to reuse F1 and F2 
but without a Beanstalk source.

Am I missing something obvious, or is this the only way to achieve an ACK 
back to the upstream publisher once F2 has completed processing? (Note in 
this example F2 is the persistence point)

Cheers,

Dom

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

Re: [akka-user] Akka http vs Spray performance

[Giovanni Alberto Caporaletti]

Nice, thank you Endre.

I guess knowing that the project will stay under active development after 
1.0.0 is enough to choose it over spray, once the api is (roughly) stable 
with 1.0.0. 
I think that for most people it's important to know that the project will 
be supported and the current limitations will be gradually removed. I 
personally see less "danger" in using akka stream/http as experimental 
modules compared to something like persistence (back then) because -correct 
me if I'm wrong- it's less likely that something unrecoverable that 
completely destroys application data or requires a huge migration could 
happen, i.e. experimenting with data is riskier.
As I said I've been using http/stream in a small component here at my 
startup and I am pretty happy with the results. Some workarounds because of 
missing features are ok, as long as the job is done. I already "migrated" 
some of those workarounds to production code during the MX-RCX phases (e.g. 
I had written my own custom "SynchronousFileSource" before using the 
current one). Using an incomplete/changing api can be worked around, slow 
(1 order of magnitude) internals cannot, that's why it's very important to 
know that performance improvement is a priority. 

If the optimization work is supposed to show its first results in a matter 
of months (not year+), I could choose to use the new api in a more 
important component because I like it (a lot) and see a lot of potential 
for future extensions.


Cheers 
G


On Thursday, 28 May 2015 11:56:10 UTC+2, drewhk wrote:
>
>
>
> On Wed, May 27, 2015 at 10:45 PM, Giovanni Alberto Caporaletti <
> para...@gmail.com > wrote:
>
>> I'm already using http/streams in a minor component, but since you're 
>> talking about this: do you have a rough idea of when the performance 
>> improvement work will start? Of course I'm not talking about the exact day 
>> but it would be very useful to know if we can expect something by the end 
>> of the year, more or less. I mean, if I had a 75% chance to have 50% the 
>> performance of spray by the end of the year, I'd start using akka-http 
>> right away for my project... it's an investment ;)
>>
>
> I think it should start soon, since we are mostly happy with the API. 
> Also, since M5 the DSL layer, the representation layer and the 
> implementation layer are highly decoupled, so we can much more easily hack 
> around with the internals than before.
>
> I think two main architectural areas are to be covered:
>  - Dynamic streams usage: the current DSL is very rigid as in the layout 
> of the streams are mostly static after being materialized. We need to solve 
> this in a way that is not a collection of ad-hoc hacks and has similar 
> safety properties than the most common stream stages. 
>  - Graph interpreter support: this will allow us to expose much richer 
> APIs than the current FlexiMerge/FlexiRoute and unify it with the 
> PushPullStage infrastructure. It will allso allow users to demarcate 
> regions of a graph they want to map to an actor. I.e. you will be able to 
> execute a complex graph/flow inside one actor instead one actor for each 
> stage. I believe this will also improve performance.
>
> Performance optimizations should not interfere with the above goals, 
> therefore we are not jumping right into them, but we are very eager!
>
> -Endre
>
>
>> thanks
>> G
>>
>> On Wednesday, 27 May 2015 13:49:10 UTC+2, drewhk wrote:
>>>
>>> Hi,
>>>
>>> At the current point the aim of streams 1.0 was to reach a desired 
>>> functionality level. Basically there is zero performance work done at this 
>>> point. We will improve performance in later versions though. 
>>>
>>> We basically refactored streams API in roughly every second release, so 
>>> we are currently happy that the current API looks usable and most of the 
>>> bugs are ironed out. 
>>>
>>> -Endre
>>>
>>> On Wed, May 27, 2015 at 1:44 PM, zergood  wrote:
>>>
 I've done little benchmarks to compare spray and akka-http performance. 
 I use default jvm and akka settings. So you can see that there is 
 an significant performance difference between it.

 code:
 spray https://gist.github.com/zergood/18bae0adc2e774c31233. 
 akka-http https://gist.github.com/zergood/53977efd500985a34ea1.

 versions:
 spray 1.3.3 
 akka-http 1.0-RC3
 scala 2.11.6
 java 1.8

 wrk output for spray:
 Running 1m test @ 
 http://127.0.0.1:8080/dictionaries/hello/suggestions?ngr=hond
   30 threads and 64 connections
   Thread Stats   Avg  Stdev Max   +/- Stdev
 Latency 2.14ms9.82ms  78.22ms   98.22%
 Req/Sec 2.55k   609.68 4.22k78.12%
   4322357 requests in 1.00m, 614.20MB read
 Requests/sec:  72044.97
 Transfer/sec: 10.24MB

 wrk output for akka-http:
 Running 1m test @ 
 http://127.0.0.1:3535/dictionaries/hello/suggestions?ngr=hond
   30 threads and 64 connections
   Thread St

Re: [akka-user] Akka http load balancer

[Endre Varga]

But in the code you are using superPool. That gives back the same pool
every time, no matter how many times you are using it. Did you try
Http.cachedHostConnectionPool(...) explicitly?

-Endre

On Thu, May 28, 2015 at 4:05 PM, Илья Ненахов 
wrote:

> I did different pool for every server but there was no effect on
> performance.
>
> 2015-05-28 16:54 GMT+03:00 Endre Varga :
>
>>
>>
>> On Thu, May 28, 2015 at 3:08 PM, Илья Ненахов 
>> wrote:
>>
>>> Here it is https://github.com/zergood/akka-http-loadbalancer.git.
>>> Actualy this implemetation is not good, because I've relized that with
>>> Http().superFlow I miss request-response ordering.
>>>
>>
>> This is why you can attach context to the requests and that will be
>> returned with the response.
>>
>>
>>> Some requests get wrong responses, it is not so important for this
>>> implementation, because all responses are the same.
>>> How can I repair request-response ordering? I think about mapping
>>> request to some id, and store all unhandled requests before I get
>>> (response, id) from server, another variant is passing RequestContext to
>>> superFlow. Are there another ways how to do this?
>>>
>>> P.S in this implementation balancer performance ~900r/s. Single local
>>> http server performance is ~4800r/s.
>>>
>>
>> I just realized that because you are using the common pool (Http.request
>> is using the same one, too), balancing will have no real effect since all
>> the requests are routed to the same pool anyway. What you need is host
>> level connection pools on each balance edge, pinned to the server you
>> target on that graph edge.
>>
>> -Endre
>>
>>
>>
>>>
>>> 2015-05-28 13:09 GMT+03:00 Endre Varga :
>>>
 Can you bundle up a very simple self-contained app that just fires up a
 couple of server systems locally (can be on the same JVM), and uses the
 balancing logic above? Then we can look into that and see what is going on.

 -Endre

 On Wed, May 27, 2015 at 8:45 PM, Илья Ненахов 
 wrote:

> I added Http().superPool() to my implementation, but performance is
> still low. Performance does not increase after adding third server. It
> seems strange to me.
> Adam, yeah we have a reason not to use nginx or something similar,
> because there will be an additional business logic, not only load
> balancing. But if we can't fix the performance issue, nginx and etc would
> be a "plan b".
>
> 2015-05-27 17:14 GMT+03:00 Adam Shannon :
>
>> Is there a specific reason to not use another piece of software for
>> this? I'm thinking of something like nginx or haproxy. Both of which are
>> much more hardened and performant in regards to serving as proxies for 
>> HTTP
>> traffic.
>>
>> On Wed, May 27, 2015 at 7:34 AM, Viktor Klang > > wrote:
>>
>>>
>>>
>>> On Wed, May 27, 2015 at 2:33 PM, Viktor Klang <
>>> viktor.kl...@gmail.com> wrote:
>>>


 On Wed, May 27, 2015 at 2:01 PM, Endre Varga <
 endre.va...@typesafe.com> wrote:

> Hi,
>
> Instead of Http.request, you should use the Flow returned by
> Http.superPool() (see
> http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-RC3/scala/http/client-side/request-level.html).
> That flattens out the Futures and you get responses instead. That also
> makes Balance actually aware of response times.
>
> OTOH I don't think performance wise akka-http is currently up to
> the task of being a balancer.
>

 …at the moment.

>>>
>>> Doh, that "currently" eluded me, see my response as emphasis :)
>>>
>>>


>
> -Endre
>
> On Wed, May 27, 2015 at 1:21 PM, zergood 
> wrote:
>
>> Hello!
>>
>> I have a task to develop a http balance loader for my 2 servers.
>> Here is my qucik and very dirty implementation
>> https://gist.github.com/zergood/e705cd6ce4cfec47c0a5. The main
>> problem with it is performance, this solution is slower than my 
>> single
>> server.
>> What is the reason of performance degradation? Could you give me
>> any advices how to make http load balancer with akka-http? I am using
>> scala-2.11 and akka-http 1.0-RC3.
>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives:
>> https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the
>> Google Groups "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to akka-user+unsubscr...@googlegroups.com.

Re: [akka-user] Akka http load balancer

[Илья Ненахов]

I did different pool for every server but there was no effect on
performance.

2015-05-28 16:54 GMT+03:00 Endre Varga :

>
>
> On Thu, May 28, 2015 at 3:08 PM, Илья Ненахов 
> wrote:
>
>> Here it is https://github.com/zergood/akka-http-loadbalancer.git.
>> Actualy this implemetation is not good, because I've relized that with
>> Http().superFlow I miss request-response ordering.
>>
>
> This is why you can attach context to the requests and that will be
> returned with the response.
>
>
>> Some requests get wrong responses, it is not so important for this
>> implementation, because all responses are the same.
>> How can I repair request-response ordering? I think about mapping request
>> to some id, and store all unhandled requests before I get (response, id)
>> from server, another variant is passing RequestContext to superFlow. Are
>> there another ways how to do this?
>>
>> P.S in this implementation balancer performance ~900r/s. Single local
>> http server performance is ~4800r/s.
>>
>
> I just realized that because you are using the common pool (Http.request
> is using the same one, too), balancing will have no real effect since all
> the requests are routed to the same pool anyway. What you need is host
> level connection pools on each balance edge, pinned to the server you
> target on that graph edge.
>
> -Endre
>
>
>
>>
>> 2015-05-28 13:09 GMT+03:00 Endre Varga :
>>
>>> Can you bundle up a very simple self-contained app that just fires up a
>>> couple of server systems locally (can be on the same JVM), and uses the
>>> balancing logic above? Then we can look into that and see what is going on.
>>>
>>> -Endre
>>>
>>> On Wed, May 27, 2015 at 8:45 PM, Илья Ненахов 
>>> wrote:
>>>
 I added Http().superPool() to my implementation, but performance is
 still low. Performance does not increase after adding third server. It
 seems strange to me.
 Adam, yeah we have a reason not to use nginx or something similar,
 because there will be an additional business logic, not only load
 balancing. But if we can't fix the performance issue, nginx and etc would
 be a "plan b".

 2015-05-27 17:14 GMT+03:00 Adam Shannon :

> Is there a specific reason to not use another piece of software for
> this? I'm thinking of something like nginx or haproxy. Both of which are
> much more hardened and performant in regards to serving as proxies for 
> HTTP
> traffic.
>
> On Wed, May 27, 2015 at 7:34 AM, Viktor Klang 
> wrote:
>
>>
>>
>> On Wed, May 27, 2015 at 2:33 PM, Viktor Klang > > wrote:
>>
>>>
>>>
>>> On Wed, May 27, 2015 at 2:01 PM, Endre Varga <
>>> endre.va...@typesafe.com> wrote:
>>>
 Hi,

 Instead of Http.request, you should use the Flow returned by
 Http.superPool() (see
 http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-RC3/scala/http/client-side/request-level.html).
 That flattens out the Futures and you get responses instead. That also
 makes Balance actually aware of response times.

 OTOH I don't think performance wise akka-http is currently up to
 the task of being a balancer.

>>>
>>> …at the moment.
>>>
>>
>> Doh, that "currently" eluded me, see my response as emphasis :)
>>
>>
>>>
>>>

 -Endre

 On Wed, May 27, 2015 at 1:21 PM, zergood 
 wrote:

> Hello!
>
> I have a task to develop a http balance loader for my 2 servers.
> Here is my qucik and very dirty implementation
> https://gist.github.com/zergood/e705cd6ce4cfec47c0a5. The main
> problem with it is performance, this solution is slower than my single
> server.
> What is the reason of performance degradation? Could you give me
> any advices how to make http load balancer with akka-http? I am using
> scala-2.11 and akka-http 1.0-RC3.
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives:
> https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google
> Groups "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

  --
 >> Read the docs: http://akka.io/docs/
 >> Check the FAQ:
 http://doc.akka.io/docs/akka/current/additional/faq.html
 >>>

Re: [akka-user] Akka http load balancer

[Endre Varga]

On Thu, May 28, 2015 at 3:08 PM, Илья Ненахов 
wrote:

> Here it is https://github.com/zergood/akka-http-loadbalancer.git.
> Actualy this implemetation is not good, because I've relized that with
> Http().superFlow I miss request-response ordering.
>

This is why you can attach context to the requests and that will be
returned with the response.


> Some requests get wrong responses, it is not so important for this
> implementation, because all responses are the same.
> How can I repair request-response ordering? I think about mapping request
> to some id, and store all unhandled requests before I get (response, id)
> from server, another variant is passing RequestContext to superFlow. Are
> there another ways how to do this?
>
> P.S in this implementation balancer performance ~900r/s. Single local http
> server performance is ~4800r/s.
>

I just realized that because you are using the common pool (Http.request is
using the same one, too), balancing will have no real effect since all the
requests are routed to the same pool anyway. What you need is host level
connection pools on each balance edge, pinned to the server you target on
that graph edge.

-Endre



>
> 2015-05-28 13:09 GMT+03:00 Endre Varga :
>
>> Can you bundle up a very simple self-contained app that just fires up a
>> couple of server systems locally (can be on the same JVM), and uses the
>> balancing logic above? Then we can look into that and see what is going on.
>>
>> -Endre
>>
>> On Wed, May 27, 2015 at 8:45 PM, Илья Ненахов 
>> wrote:
>>
>>> I added Http().superPool() to my implementation, but performance is
>>> still low. Performance does not increase after adding third server. It
>>> seems strange to me.
>>> Adam, yeah we have a reason not to use nginx or something similar,
>>> because there will be an additional business logic, not only load
>>> balancing. But if we can't fix the performance issue, nginx and etc would
>>> be a "plan b".
>>>
>>> 2015-05-27 17:14 GMT+03:00 Adam Shannon :
>>>
 Is there a specific reason to not use another piece of software for
 this? I'm thinking of something like nginx or haproxy. Both of which are
 much more hardened and performant in regards to serving as proxies for HTTP
 traffic.

 On Wed, May 27, 2015 at 7:34 AM, Viktor Klang 
 wrote:

>
>
> On Wed, May 27, 2015 at 2:33 PM, Viktor Klang 
> wrote:
>
>>
>>
>> On Wed, May 27, 2015 at 2:01 PM, Endre Varga <
>> endre.va...@typesafe.com> wrote:
>>
>>> Hi,
>>>
>>> Instead of Http.request, you should use the Flow returned by
>>> Http.superPool() (see
>>> http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-RC3/scala/http/client-side/request-level.html).
>>> That flattens out the Futures and you get responses instead. That also
>>> makes Balance actually aware of response times.
>>>
>>> OTOH I don't think performance wise akka-http is currently up to the
>>> task of being a balancer.
>>>
>>
>> …at the moment.
>>
>
> Doh, that "currently" eluded me, see my response as emphasis :)
>
>
>>
>>
>>>
>>> -Endre
>>>
>>> On Wed, May 27, 2015 at 1:21 PM, zergood 
>>> wrote:
>>>
 Hello!

 I have a task to develop a http balance loader for my 2 servers.
 Here is my qucik and very dirty implementation
 https://gist.github.com/zergood/e705cd6ce4cfec47c0a5. The main
 problem with it is performance, this solution is slower than my single
 server.
 What is the reason of performance degradation? Could you give me
 any advices how to make http load balancer with akka-http? I am using
 scala-2.11 and akka-http 1.0-RC3.

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

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

[akka-user] [akka-stream] How to design stream profiling properly?

[Jakub Liska]

Hi,

having a stream with many Flow components often makes you wondering where 
all the time is being spent.

Any idea how to end up with something like a HashMap with entries 
[flowName/flowType, msSum] ?

I can think of either a profiling function being explicitly passed to all 
Flow combinators that do some work like map/mapAsync

Or implementing a PushPullStage that would be appended via "transform()" 
after each Flow - but I'm not sure at all if summing times between 
individual pushes would be a sensible and correct result - imho it 
wouldn't...

Is there a better way to do this ?

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

Re: [akka-user] Akka http load balancer

[Илья Ненахов]

Here it is https://github.com/zergood/akka-http-loadbalancer.git.
Actualy this implemetation is not good, because I've relized that with
Http().superFlow I miss request-response ordering. Some requests get wrong
responses, it is not so important for this implementation, because all
responses are the same.
How can I repair request-response ordering? I think about mapping request
to some id, and store all unhandled requests before I get (response, id)
from server, another variant is passing RequestContext to superFlow. Are
there another ways how to do this?

P.S in this implementation balancer performance ~900r/s. Single local http
server performance is ~4800r/s.

2015-05-28 13:09 GMT+03:00 Endre Varga :

> Can you bundle up a very simple self-contained app that just fires up a
> couple of server systems locally (can be on the same JVM), and uses the
> balancing logic above? Then we can look into that and see what is going on.
>
> -Endre
>
> On Wed, May 27, 2015 at 8:45 PM, Илья Ненахов 
> wrote:
>
>> I added Http().superPool() to my implementation, but performance is still
>> low. Performance does not increase after adding third server. It seems
>> strange to me.
>> Adam, yeah we have a reason not to use nginx or something similar,
>> because there will be an additional business logic, not only load
>> balancing. But if we can't fix the performance issue, nginx and etc would
>> be a "plan b".
>>
>> 2015-05-27 17:14 GMT+03:00 Adam Shannon :
>>
>>> Is there a specific reason to not use another piece of software for
>>> this? I'm thinking of something like nginx or haproxy. Both of which are
>>> much more hardened and performant in regards to serving as proxies for HTTP
>>> traffic.
>>>
>>> On Wed, May 27, 2015 at 7:34 AM, Viktor Klang 
>>> wrote:
>>>


 On Wed, May 27, 2015 at 2:33 PM, Viktor Klang 
 wrote:

>
>
> On Wed, May 27, 2015 at 2:01 PM, Endre Varga  > wrote:
>
>> Hi,
>>
>> Instead of Http.request, you should use the Flow returned by
>> Http.superPool() (see
>> http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-RC3/scala/http/client-side/request-level.html).
>> That flattens out the Futures and you get responses instead. That also
>> makes Balance actually aware of response times.
>>
>> OTOH I don't think performance wise akka-http is currently up to the
>> task of being a balancer.
>>
>
> …at the moment.
>

 Doh, that "currently" eluded me, see my response as emphasis :)


>
>
>>
>> -Endre
>>
>> On Wed, May 27, 2015 at 1:21 PM, zergood 
>> wrote:
>>
>>> Hello!
>>>
>>> I have a task to develop a http balance loader for my 2 servers.
>>> Here is my qucik and very dirty implementation
>>> https://gist.github.com/zergood/e705cd6ce4cfec47c0a5. The main
>>> problem with it is performance, this solution is slower than my single
>>> server.
>>> What is the reason of performance degradation? Could you give me any
>>> advices how to make http load balancer with akka-http? I am using
>>> scala-2.11 and akka-http 1.0-RC3.
>>>
>>> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it,
>>> send an email to akka-user+unsubscr...@googlegroups.com.
>>> To post to this group, send email to akka-user@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives:
>> https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google
>> Groups "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> Cheers,
> √
>



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

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

[Tal Pressman]

On Thursday, May 28, 2015 at 1:26:28 AM UTC+3, Tim Harper wrote:

You're right; after the retry amount, the messages are lost. Also, worse, 
> is that message order is not maintained. This makes the recovery strategy 
> good only when message order does not matter. I had to do this because I 
> use message headers to count retries.
>
> If you'll look at *impl/AsyncAckingConsumer.scala* 
> 
>  you'll 
> find the implementation for the RecoveryStrategy withRetry. I'd be open to 
> an alternative recovery strategy. If the future returned by the 
> RecoveryStrategy is a failure, then the original delivery gets Nacked.
>
>
Indeed, I hadn't noticed that the retries actually re-enqueued the message.
Maybe it's better to just let the downstream decide what to do with the 
message (retry for however many times it wants, for example), and make the 
AsyncAckingRabbitConsumer "stupid" - when it gets an error it rejects the 
message (or some other simple strategy) ?
Anyway, I'll try playing around with it and see where I get...
 

This is doable; we could model the configuration values available with a 
> case class, then create a method fromConfig to pull it from typesafe 
> configuration; make it the default.
>
>
Adding case classes for configuration would be a nice touch. What I was 
trying to get at, however, is the ability to load from the non-default 
Config (for example, fromConfig(config: Config = ConfigFactory.load() or 
something).


That may be a good idea, especially if op-rabbit begins adding more 
> configuration options other than just how to connect to rabbitmq; however, 
> I'd hope to avoid adding more configuration if possible.
>
>
I think the more important issue here is just to make the "root" 
configuration element name more unique and less likely to conflict with 
other libraries. "rabbitmq" seems like a name that could be picked by any 
number of RabbitMQ-related libraries.

 

> I've considered Roland's comments deeply. I started down the route of 
> implementing his suggestion and abandoned it as complexity grew. We have 
> cases where the messages will be routed to different message sinks, or 
> perhaps delivered to two different sinks. Passing along a promise allows us 
> to fork this promise, such that the upstream promise is fulfilled only 
> after the two forked downstream promises are (that way, enabling us to 
> declare "the work is done" once the byproduct messages have all been 
> confirmed to be persisted.
>
>
Yeah, that's what I like about the Future/Promise approach...
On the other hand, streams already have a similar capability in the way 
they report back-pressure and demand for flows that are just as complex. 
Maybe it's something the Akka guys should consider adding to the streams 
directly...  


If you'd like to toy with alternative recovery strategies, that would be 
> most helpful. I can work on switching the streams over to your suggestion 
> of having them handle allocating and subscription to the subscription.
>

Yeah, I'll start playing around with it, and see what happens. And maybe 
also try to get publish confirmations working - blocking commits are really 
painful.

 Tal

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

Re: [akka-user] Cluster Sharding and auto downing

[Anders Båtstrand]

Hi

I am removing the node, but I am waiting for 
https://github.com/akka/akka/pull/17527 for the more graceful shutdown.

Right now the singleton-actors are quickly restored on another node, but 
the sharded actors are very slow...

I will test again after your pull-request is merged, it looks very 
promising!

Anders

mandag 18. mai 2015 17.54.42 UTC+2 skrev Patrik Nordwall følgende:
>
> Hi Anders,
>
> It looks like this question has fallen between the cracks. I'm so sorry 
> for that. Have you found a solution?
>
> The node must be removed, not only detected as unreachable.
>
> Failover of the singleton may take some additional time, 
> see maxHandOverRetries and maxTakeOverRetries in API docs 
> of ClusterSingletonManager.
>
> Regards,
> Patrik
>
> On Mon, May 4, 2015 at 11:40 AM, Anders Båtstrand  > wrote:
>
>> Dear group
>>
>> I have a Akka cluster, with cluster sharding.
>>
>> When I kill the oldest node, the shard coordinator and other 
>> singleton-actors are started on another node in the cluster after a few 
>> seconds (as I have tuned it to). However, calls to the sharded actors 
>> continue to time out, and they are started on the new node first 20 seconds 
>> later. It seems the cluster manager knows the old node is removed from the 
>> cluster, but the shard coordinator does not.
>>
>> Is this expected behavior? I would expect the coordinator to re-balance 
>> the shards immediately after a node is marked down...
>>
>> Is there a way I can trigger the re-balancing process?
>>
>> Best regards,
>>
>> Anders Båtstrand
>>
>> -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
>
> Patrik Nordwall
> Typesafe  -  Reactive apps on the JVM
> Twitter: @patriknw
>
> 

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

[akka-user] Config for adding the Remote-Address header in Akka Http

[Chris Baxter]

I noticed there is a setting (akka.http.server.remote-address-header) that 
can be turned to "on" that should automatically add the Remote-Address 
header to all incoming requests.  I set this to on using RC3 but I do not 
see the header being added. I searched through the source and saw the 
setting in ServerSettings but I did not see that field that ties to this 
config setting being used anywhere in the code.  Is this something that has 
yet to be implemented?

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

Re: [akka-user] Re: [akka-stream] How to construct an empty/dummy partial graph?

[Endre Varga]

On Thu, May 28, 2015 at 12:36 PM, Jakub Liska  wrote:

> I see,
>
> I didn't know that partial graph that exposes in&out ports can be used
> like a common Flow :
>

It can only be used this way if it has the right shape (FlowShape). If you
want to stub out a more complex graph (multiple ins and/or outs) then you
need to explicitly construct a replacement graph of the right shape (since
there is no default way to wire things together).

In your code you returned Flow on one branch, so it is completely fine to
return an identity Flow on the other branch. This can only work of course
if the Flow does not change the type of course.

-Endre


>
> in ~> partialGraph ~> out
>
> There is only this in documentation :
>
> partialGraph.runWith(Source(List(1)), Sink.head)
>
> So I thought it was not possible... Thank you Endre !!!
>
> --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

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

[akka-user] Re: [akka-stream] How to construct an empty/dummy partial graph?

[Jakub Liska]

I see,

I didn't know that partial graph that exposes in&out ports can be used like 
a common Flow : 

in ~> partialGraph ~> out

There is only this in documentation : 

partialGraph.runWith(Source(List(1)), Sink.head)

So I thought it was not possible... Thank you Endre !!!

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

Re: [akka-user] [akka-stream] How to construct an empty/dummy partial graph?

[Endre Varga]

Hi Jakub,

(Please remove the formatting from IntelliJ next time, it is hard to read
in Gmail)

On Thu, May 28, 2015 at 12:18 PM, Jakub Liska  wrote:

> Hi,
>
> I cannot figure out, how would I do something like :
>
> bucketOpt match {
>   case None =>
> *// ??? How to return just a dummy partial graph ???*
>   case Some(bucket) =>
> Flow() { implicit b =>
>   import FlowGraph.Implicits._
>
>   val broadcast = b.add(Broadcast[Array[ResCtx]](2))
>
>   val uniqueResourceFilter = Flow[Array[ResCtx]].transform(() => new 
> UniqueResourceFilter)
>   val backup = Flow[Iterable[Resource]].mapAsyncUnordered(4) { resources 
> =>
> Future.sequence(
>   resources.map( res => S3BackupFlow.backup(bucket, res, res.name, 
> deleteLocal))
> )
>   }
>   broadcast.out(0) ~> uniqueResourceFilter ~> backup ~> Sink.ignore
>
>   (broadcast.in, broadcast.out(1))
> }
> }
>
>
>
Since you return just a Flow, why don't you just create an empty Flow? I.e
Flow[Array[ResCtx]]


> Also it is a mystery to me how to grab just an inlet stream, for doing
> something like :
>
> Flow() { implicit b =>
>   import FlowGraph.Implicits._
>
>
>
>   val uniqueResourceFilter = Flow[Array[ResCtx]].transform(() => new 
> UniqueResourceFilter)
>
>   val merge = b.add(Merge[Array[ResCtx]](2))
>
>
>
>   ???in??? ~> filter ~> broadcast.out(0) ~> uniqueResourceFilter ~> backup ~> 
> merge.in(0)
>
>  ~> broadcast.out(1) ~> uniqueResourceFilter ~> backup ~> 
> merge.in(1)
>
>
> (???in???, merge.out)
> }
>
>
>
You can always do:
 val f = b.add(filter)
 f.out ~> broadcast ...
 (f.in, merge.out)

Flows/Sources/Sinks have this little feature that you don't need to import
them explicitly like I did above, but that does not mean you can't import
them explicitly.

-Endre


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

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

[akka-user] [akka-stream] How to construct an empty/dummy partial graph?

[Jakub Liska]

Hi,

I cannot figure out, how would I do something like : 

bucketOpt match {
  case None =>
*// ??? How to return just a dummy partial graph ???*
  case Some(bucket) =>
Flow() { implicit b =>
  import FlowGraph.Implicits._

  val broadcast = b.add(Broadcast[Array[ResCtx]](2))

  val uniqueResourceFilter = Flow[Array[ResCtx]].transform(() => new 
UniqueResourceFilter)
  val backup = Flow[Iterable[Resource]].mapAsyncUnordered(4) { resources =>
Future.sequence(
  resources.map( res => S3BackupFlow.backup(bucket, res, res.name, 
deleteLocal))
)
  }
  broadcast.out(0) ~> uniqueResourceFilter ~> backup ~> Sink.ignore

  (broadcast.in, broadcast.out(1))
}
}


Also it is a mystery to me how to grab just an inlet stream, for doing 
something like : 

Flow() { implicit b =>
  import FlowGraph.Implicits._

  

  val uniqueResourceFilter = Flow[Array[ResCtx]].transform(() => new 
UniqueResourceFilter)

  val merge = b.add(Merge[Array[ResCtx]](2))

 

  ???in??? ~> filter ~> broadcast.out(0) ~> uniqueResourceFilter ~> backup ~> 
merge.in(0)

 ~> broadcast.out(1) ~> uniqueResourceFilter ~> backup ~> 
merge.in(1)


(???in???, merge.out)
}



Thanks, Jakub

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

Re: [akka-user] Cluster disconnection - "Failed to write message to the transport"

[rnozik]

Hi Again,

I noticed a few more things:

First of all, I ran the same test (master with s single worker) with a 
physical Android device (instead of an emulator), and the cluster 
disconnection was much less frequent (took more than two hours), but with 
the same symptoms.
I therefore suspect that the problem may be related to an arbitrary 
communication failure with the device - that happens less frequently with 
physical devices (as they are more stable).

Secondly, looking at the Akka logs from the master side, after the 
disassociation event occurs, I start getting dead-letters messages:
[INFO] [05/28/2015 09:59:50.715] 
[ClusterSystem-akka.actor.default-dispatcher-25] 
[akka://ClusterSystem/deadLetters] Message [akka.cluster.GossipStatus] from 
Actor[akka://ClusterSystem/system/cluster/core/daemon#-1559364220] to 
Actor[akka://ClusterSystem/deadLetters] was not delivered. [3] dead letters 
encountered. This logging can be turned off or adjusted with configuration 
settings 'akka.log-dead-letters' and 
'akka.log-dead-letters-during-shutdown'.
[INFO] [05/28/2015 09:59:50.731] 
[ClusterSystem-akka.actor.default-dispatcher-19] 
[akka://ClusterSystem/deadLetters] Message 
[akka.contrib.pattern.DistributedPubSubMediator$Internal$Status] from 
Actor[akka://ClusterSystem/user/distributedPubSubMediator#-825410933] to 
Actor[akka://ClusterSystem/deadLetters] was not delivered. [4] dead letters 
encountered. This logging can be turned off or adjusted with configuration 
settings 'akka.log-dead-letters' and 
'akka.log-dead-letters-during-shutdown'.

After a few seconds, I notice that the connection to the worker was refused:
[WARN] [05/28/2015 09:59:54.746] 
[ClusterSystem-akka.remote.default-remote-dispatcher-26] 
[akka.tcp://ClusterSystem@10.141.4.140:2551/system/endpointManager/reliableEndpointWriter-akka.tcp%3A%2F%2FClusterSystem%40127.0.0.1%3A2553-0]
 
Association with remote system [akka.tcp://ClusterSystem@127.0.0.1:2553] 
has failed, address is now gated for [5000] ms. Reason: [Association failed 
with [akka.tcp://ClusterSystem@127.0.0.1:2553]] Caused by: [Connection 
refused: /127.0.0.1:2553]

Afterwards I see two more heartbeats sent to the worker (with no response), 
before it is marked unreachable (The IP of the other node is localhost as 
it runs on a local Android emulator)

My questions are:
1. Is it possible that the other node actively refuses the tcp connection? 
If so, why, and how can I avoid it?
2. The exception that I brought in the first post of this thread, the 
cluster can generally recover from it, right? If so, what stops the cluster 
from doing so? 

Thank,
Nozik



On Tuesday, May 26, 2015 at 4:55:39 PM UTC+3, Ran Nozik wrote:
>
> Hi Endre,
>
> Thank you for your quick response.
>
> I verified that the only protobuf version we use 
> is com.google.protobuf:protobuf-java:2.5.0 (no other versions in the 
> classpath).
>
> I'm not sure I understood your question about the remoting. We have a 
> distributed system with many (backend) Android workers and one master 
> (frontend) node. They do not interact as client and server.
>
> Regards,
> Nozik
>
> On Tue, May 26, 2015 at 4:21 PM, Endre Varga  
> wrote:
>
>> Caused by: com.google.protobuf.UninitializedMessageException: Message 
>> missing required fields: 
>> ... 30 more
>> ]
>>
>> This very much looks like a serialization problem though. Do you maybe 
>> have a newer protobuf version on your classpath than the one Akka uses?
>>
>> Btw, why are you using akka-remoting between android systems? Don't 
>> forget that remoting and clustering are not client-server technologies but 
>> peer-to-peer technologies: 
>> http://doc.akka.io/docs/akka/2.3.11/general/remoting.html#Peer-to-Peer_vs__Client-Server
>>
>> -Endre
>>
>> On Tue, May 26, 2015 at 3:16 PM,  wrote:
>>
>>> Hi,
>>>
>>> I upgraded to 2.3.11 and the problem reproduced again.
>>>
>>> Thanks.
>>>
>>>
>>> On Tuesday, May 26, 2015 at 3:12:38 PM UTC+3, √ wrote:

 Hi Mozik,

 please upgrade to the latest version and report back if you still have 
 the same problem.

 On Tue, May 26, 2015 at 2:03 PM,  wrote:

> Hi Everyone,
>
> I've been trying to set an Akka cluster with one master node and 
> multiple workers. The workers are actor systems than run on Android 
> emulators.
> As a start, I work with one worker (emulator). I verify that it 
> successfully joins the cluster and start sending it messages, that are 
> handled successfully. After some time (from 2-3 to 30-40 minutes), 
> however, 
> it disconnects from the cluster.
> Trying to figure out what causes the problem, I noticed that even if 
> the worker is idle (no messages are sent), it disconnects from the 
> cluster 
> after some time. 
>
> In the Android logcat, the following message is displayed:
>
> [ClusterSystem-akka.remote.default-remote-dispatcher-5] [akka.tcp://
>> ClusterSystem@127.0.0.1:2553/system/endpointManage

Re: [akka-user] Akka http load balancer

[Endre Varga]

Can you bundle up a very simple self-contained app that just fires up a
couple of server systems locally (can be on the same JVM), and uses the
balancing logic above? Then we can look into that and see what is going on.

-Endre

On Wed, May 27, 2015 at 8:45 PM, Илья Ненахов 
wrote:

> I added Http().superPool() to my implementation, but performance is still
> low. Performance does not increase after adding third server. It seems
> strange to me.
> Adam, yeah we have a reason not to use nginx or something similar, because
> there will be an additional business logic, not only load balancing. But if
> we can't fix the performance issue, nginx and etc would be a "plan b".
>
> 2015-05-27 17:14 GMT+03:00 Adam Shannon :
>
>> Is there a specific reason to not use another piece of software for this?
>> I'm thinking of something like nginx or haproxy. Both of which are much
>> more hardened and performant in regards to serving as proxies for HTTP
>> traffic.
>>
>> On Wed, May 27, 2015 at 7:34 AM, Viktor Klang 
>> wrote:
>>
>>>
>>>
>>> On Wed, May 27, 2015 at 2:33 PM, Viktor Klang 
>>> wrote:
>>>


 On Wed, May 27, 2015 at 2:01 PM, Endre Varga 
 wrote:

> Hi,
>
> Instead of Http.request, you should use the Flow returned by
> Http.superPool() (see
> http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-RC3/scala/http/client-side/request-level.html).
> That flattens out the Futures and you get responses instead. That also
> makes Balance actually aware of response times.
>
> OTOH I don't think performance wise akka-http is currently up to the
> task of being a balancer.
>

 …at the moment.

>>>
>>> Doh, that "currently" eluded me, see my response as emphasis :)
>>>
>>>


>
> -Endre
>
> On Wed, May 27, 2015 at 1:21 PM, zergood 
> wrote:
>
>> Hello!
>>
>> I have a task to develop a http balance loader for my 2 servers. Here
>> is my qucik and very dirty implementation
>> https://gist.github.com/zergood/e705cd6ce4cfec47c0a5. The main
>> problem with it is performance, this solution is slower than my single
>> server.
>> What is the reason of performance degradation? Could you give me any
>> advices how to make http load balancer with akka-http? I am using
>> scala-2.11 and akka-http 1.0-RC3.
>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives:
>> https://groups.google.com/group/akka-user
>> ---
>> You received this message because you are subscribed to the Google
>> Groups "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it,
>> send an email to akka-user+unsubscr...@googlegroups.com.
>> To post to this group, send email to akka-user@googlegroups.com.
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives:
> https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google
> Groups "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>



 --
 Cheers,
 √

>>>
>>>
>>>
>>> --
>>> Cheers,
>>> √
>>>
>>> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+unsubscr...@googlegroups.com.
>>> To post to this group, send email to akka-user@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Adam Shannon | Software Engineer | Banno | Jack Henry
>> 206 6th Ave Suite 1020 | Des Moines, IA 50309 | Cell: 515.867.8337
>>
>> --
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> ---
>> You received this message because y

Re: [akka-user] [akka streams] question on some time related use cases

[Endre Varga]

Hi Jakub,

Every state that is encapsulated in the Stage is safe to being accessed
from any of the Stage callbacks (onPull, onPush, etc.). In this regard it
is like an Actor, where you can safely access its state from the receive
block.

You can look into the cookbook (
http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-RC3/scala/stream-cookbook.html)
for examples, or you can look at how some built-in stages are implemented:
https://github.com/akka/akka/blob/release-2.3-dev/akka-stream/src/main/scala/akka/stream/impl/fusing/Ops.scala

-Endre

On Thu, May 28, 2015 at 1:32 AM, Jakub Liska  wrote:

> Hi,
>
> btw can Stage by stateful? Is R/W from/to this in a PushPullStage thread
> safe?
>
> var state : Map[A,Cancellable] = Map.empty
>
> Thanks, Jakub
>
>
> On Friday, January 23, 2015 at 2:42:11 AM UTC+1, Frank Sauer wrote:
>>
>> Thanks for the pointers Endre,  I’ll explore those ideas.
>>
>> Frank
>>
>> On Jan 22, 2015, at 4:02 AM, Endre Varga  wrote:
>>
>>
>>
>> On Thu, Jan 22, 2015 at 5:07 AM, Frank Sauer  wrote:
>>
>>> Update, in a simple test scenario like so
>>>
>>>   val ticks = Source(1 second, 1 second, () => "Hello")
>>>
>>>   val flow = ticks.transform(() => new FilterFor[String](10 seconds)(x
>>> => true)).to(Sink.foreach(println(_)))
>>>
>>>   flow.run()
>>>
>>> I'm seeing the following error, so this doesn't work at all and I'm not
>>> sure it is because of threading:
>>>
>>> java.lang.ArrayIndexOutOfBoundsException: -1
>>> at
>>> akka.stream.impl.fusing.OneBoundedInterpreter.akka$stream$impl$fusing$OneBoundedInterpreter$$currentOp(Interpreter.scala:175)
>>> at
>>> akka.stream.impl.fusing.OneBoundedInterpreter$State$class.push(Interpreter.scala:209)
>>> at
>>> akka.stream.impl.fusing.OneBoundedInterpreter$$anon$1.push(Interpreter.scala:278)
>>> at
>>> experiments.streams.time$FilterFor$$anonfun$1.apply$mcV$sp(time.scala:46)
>>> at akka.actor.Scheduler$$anon$7.run(Scheduler.scala:117)
>>> at
>>> scala.concurrent.impl.ExecutionContextImpl$AdaptedForkJoinTask.exec(ExecutionContextImpl.scala:121)
>>> at scala.concurrent.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260)
>>> at
>>> scala.concurrent.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339)
>>> at
>>> scala.concurrent.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979)
>>> at
>>> scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)
>>>
>>> I think I'm violating the one very important rule mentioned in the docs
>>> - when the timer fires it calls a push on the context but there is also a
>>> pull going on concurrently(?) - and this is indeed breaking in spectacular
>>> ways as expected
>>>
>>
>> :)
>>
>>
>>>
>>> I have no idea how to implement this correctly. It looked pretty simple
>>> at first, but alas...
>>>
>>
>> See my previous mail. The main problem here is mixing backpressured
>> streams (your data) and non-backpressured events (timer triggers) in a safe
>> fashion. Well, the main problem is not how to implement it, but how to
>> expose an API to users which is as safe as possible. We have groupedWithin,
>> takeWithin and dropWithin as timer based ops, but no customization for now.
>>
>> -Endre
>>
>>
>>>
>>> On Wednesday, January 21, 2015 at 8:51:21 PM UTC-5, Frank Sauer wrote:

 Thanks, I came up with the following, but I have some questions:

 /**
* Holds elements of type A for a given finite duration after a
 predicate p first yields true and as long as subsequent
* elements matching that first element (e.g. are equal) still
 satisfy the predicate. If a matching element arrives during
* the given FiniteDuration for which the predicate p does not hold,
 the original element will NOT be pushed downstream.
* Only when the timer expires and no matching elements have been
 seen for which p does not hold, will elem be pushed
* downstream.
*
* @param duration The polling interval during which p has to hold
 true
* @param pThe predicate that has to remain true during the
 duration
* @param system   implicit required to schedule timers
* @tparam A   type of the elements
*/
   class FilterFor[A](duration : FiniteDuration)(p: A =>
 Boolean)(implicit system: ActorSystem) extends PushStage[A,A] {

 var state : Map[A,Cancellable] = Map.empty

 override def onPush(elem: A, ctx: Context[A]): Directive =
 state.get(elem) match {

   case Some(timer) if !p(elem) => // pending timer but condition no
 longer holds => cancel timer
  timer.cancel()
  state = state - elem
  ctx.pull()

case None if p(elem) => // no pending timer and predicate true
 -> start and cache new timer
  val timer = system.scheduler.scheduleOnce(duration) {
// when timer fires, remove from state and push elem
 downstream
state = 

Re: [akka-user] Akka http vs Spray performance

[Endre Varga]

On Wed, May 27, 2015 at 10:45 PM, Giovanni Alberto Caporaletti <
paradi...@gmail.com> wrote:

> I'm already using http/streams in a minor component, but since you're
> talking about this: do you have a rough idea of when the performance
> improvement work will start? Of course I'm not talking about the exact day
> but it would be very useful to know if we can expect something by the end
> of the year, more or less. I mean, if I had a 75% chance to have 50% the
> performance of spray by the end of the year, I'd start using akka-http
> right away for my project... it's an investment ;)
>

I think it should start soon, since we are mostly happy with the API. Also,
since M5 the DSL layer, the representation layer and the implementation
layer are highly decoupled, so we can much more easily hack around with the
internals than before.

I think two main architectural areas are to be covered:
 - Dynamic streams usage: the current DSL is very rigid as in the layout of
the streams are mostly static after being materialized. We need to solve
this in a way that is not a collection of ad-hoc hacks and has similar
safety properties than the most common stream stages.
 - Graph interpreter support: this will allow us to expose much richer APIs
than the current FlexiMerge/FlexiRoute and unify it with the PushPullStage
infrastructure. It will allso allow users to demarcate regions of a graph
they want to map to an actor. I.e. you will be able to execute a complex
graph/flow inside one actor instead one actor for each stage. I believe
this will also improve performance.

Performance optimizations should not interfere with the above goals,
therefore we are not jumping right into them, but we are very eager!

-Endre


> thanks
> G
>
> On Wednesday, 27 May 2015 13:49:10 UTC+2, drewhk wrote:
>>
>> Hi,
>>
>> At the current point the aim of streams 1.0 was to reach a desired
>> functionality level. Basically there is zero performance work done at this
>> point. We will improve performance in later versions though.
>>
>> We basically refactored streams API in roughly every second release, so
>> we are currently happy that the current API looks usable and most of the
>> bugs are ironed out.
>>
>> -Endre
>>
>> On Wed, May 27, 2015 at 1:44 PM, zergood  wrote:
>>
>>> I've done little benchmarks to compare spray and akka-http performance.
>>> I use default jvm and akka settings. So you can see that there is
>>> an significant performance difference between it.
>>>
>>> code:
>>> spray https://gist.github.com/zergood/18bae0adc2e774c31233.
>>> akka-http https://gist.github.com/zergood/53977efd500985a34ea1.
>>>
>>> versions:
>>> spray 1.3.3
>>> akka-http 1.0-RC3
>>> scala 2.11.6
>>> java 1.8
>>>
>>> wrk output for spray:
>>> Running 1m test @
>>> http://127.0.0.1:8080/dictionaries/hello/suggestions?ngr=hond
>>>   30 threads and 64 connections
>>>   Thread Stats   Avg  Stdev Max   +/- Stdev
>>> Latency 2.14ms9.82ms  78.22ms   98.22%
>>> Req/Sec 2.55k   609.68 4.22k78.12%
>>>   4322357 requests in 1.00m, 614.20MB read
>>> Requests/sec:  72044.97
>>> Transfer/sec: 10.24MB
>>>
>>> wrk output for akka-http:
>>> Running 1m test @
>>> http://127.0.0.1:3535/dictionaries/hello/suggestions?ngr=hond
>>>   30 threads and 64 connections
>>>   Thread Stats   Avg  Stdev Max   +/- Stdev
>>> Latency 5.39ms6.82ms 108.07ms   92.80%
>>> Req/Sec   454.43126.73   679.00 77.77%
>>>   811836 requests in 1.00m, 115.36MB read
>>> Requests/sec:  13531.62
>>> Transfer/sec:  1.92MB
>>>
>>> Is there any akka-http config options to increase performance to the
>>> same level as spray?
>>>
>>> --
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ:
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives:
>>> https://groups.google.com/group/akka-user
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
> >> Read the docs: http://akka.io/docs/
> >> Check the FAQ:
> http://doc.akka.io/docs/akka/current/additional/faq.html
> >> Search the archives: https://groups.google.com/group/akka-user
> ---
> You received this message because you are subscribed to the Google Groups
> "Akka User List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to akka-user+unsubscr...@googlegroups.com.
> To post to this group, send email to akka-user@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>

-- 

Re: [akka-user] Akka Streams Remote Materialization

[Oliver Winks]

Thanks for the info. I'm looking forward to future releases of Akka Streams.
Cheers

On Wednesday, 27 May 2015 22:24:44 UTC+1, Akka Team wrote:
>
> Hi Oliver,
> we do not (currently) support distributed materialization of streams.
> The reason is that it will require implementing redelivery for stream 
> messages and a number of related issues which need to be fixed, which has 
> not happened yet.
>
> Currently we are focusing on getting the 1.0 out the door, which means API 
> stability, we also need to work on in-memory performance as it has not yet 
> been a focus,
> and is a critical point for making Akka HTTP as performant as Spray - at 
> which point we'll be happy to recommend using streams in production systems.
> Please remember that 1.0 still means that streams are experimental.
>
> The distributed scenario is a very interesting one, but we do not have 
> enough people/time to throw at that problem currently as other tasks are 
> more urgent.
> Hope this explains things a bit!
>
> -- konrad
>
> On Sat, May 23, 2015 at 3:18 AM, Oliver Winks  > wrote:
>
>> Hi,
>>
>> The way I understand materialisation in Akka Streams is that the 
>> ActorFlowMaterializer will create a number of actors which are used to 
>> process the flows within a stream. Is it possible to control the number and 
>> location of actors that get materialised when running a Flow? I'd like to 
>> be able to create remote actors on several machines for processing my 
>> FlowGraph.
>>
>> Thanks,
>> Oli.
>>
>> -- 
>> >> Read the docs: http://akka.io/docs/
>> >> Check the FAQ: 
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> >> Search the archives: https://groups.google.com/group/akka-user
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "Akka User List" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to akka-user+...@googlegroups.com .
>> To post to this group, send email to akka...@googlegroups.com 
>> .
>> Visit this group at http://groups.google.com/group/akka-user.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Akka Team
> Typesafe - Reactive apps on the JVM
> Blog: letitcrash.com
> Twitter: @akkateam
>  

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

Re: [akka-user] Akka http load balancer

[André]

A quick search revealed some more places that needed fixing. PR submitted 
.

On Thursday, May 28, 2015 at 9:22:35 AM UTC+2, André wrote:
>
> Source (and edit button) are here 
> .
>  
> ;)
>
> On Thursday, May 28, 2015 at 8:09:27 AM UTC+2, zergood wrote:
>>
>> Mistake in docs 
>> http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-RC3/scala/http/client-side/request-level.html
>>  
>> .
>>  Http.superPool(...) 
>> need to be Http().superPool(...) and the same for Http.singleRequest.
>>  
>> среда, 27 мая 2015 г., 15:01:34 UTC+3 пользователь drewhk написал:
>>>
>>> Hi,
>>>
>>> Instead of Http.request, you should use the Flow returned by 
>>> Http.superPool() (see 
>>> http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-RC3/scala/http/client-side/request-level.html
>>>  
>>> ).
>>>  
>>> That flattens out the Futures and you get responses instead. That also 
>>> makes Balance actually aware of response times.
>>>
>>> OTOH I don't think performance wise akka-http is currently up to the 
>>> task of being a balancer. 
>>>
>>> -Endre
>>>
>>> On Wed, May 27, 2015 at 1:21 PM, zergood  wrote:
>>>
 Hello! 

 I have a task to develop a http balance loader for my 2 servers. Here 
 is my qucik and very dirty implementation 
 https://gist.github.com/zergood/e705cd6ce4cfec47c0a5. The main problem 
 with it is performance, this solution is slower than my single server. 
 What is the reason of performance degradation? Could you give me any 
 advices how to make http load balancer with akka-http? I am using 
 scala-2.11 and akka-http 1.0-RC3.  

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

>>>
>>>

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

Re: [akka-user] Akka http load balancer

[André]

Source (and edit button) are here 
.
 
;)

On Thursday, May 28, 2015 at 8:09:27 AM UTC+2, zergood wrote:
>
> Mistake in docs 
> http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-RC3/scala/http/client-side/request-level.html
>  
> .
>  Http.superPool(...) 
> need to be Http().superPool(...) and the same for Http.singleRequest.
>  
> среда, 27 мая 2015 г., 15:01:34 UTC+3 пользователь drewhk написал:
>>
>> Hi,
>>
>> Instead of Http.request, you should use the Flow returned by 
>> Http.superPool() (see 
>> http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-RC3/scala/http/client-side/request-level.html
>>  
>> ).
>>  
>> That flattens out the Futures and you get responses instead. That also 
>> makes Balance actually aware of response times.
>>
>> OTOH I don't think performance wise akka-http is currently up to the task 
>> of being a balancer. 
>>
>> -Endre
>>
>> On Wed, May 27, 2015 at 1:21 PM, zergood  wrote:
>>
>>> Hello! 
>>>
>>> I have a task to develop a http balance loader for my 2 servers. Here is 
>>> my qucik and very dirty implementation 
>>> https://gist.github.com/zergood/e705cd6ce4cfec47c0a5. The main problem 
>>> with it is performance, this solution is slower than my single server. 
>>> What is the reason of performance degradation? Could you give me any 
>>> advices how to make http load balancer with akka-http? I am using 
>>> scala-2.11 and akka-http 1.0-RC3.  
>>>
>>> -- 
>>> >> Read the docs: http://akka.io/docs/
>>> >> Check the FAQ: 
>>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>> >> Search the archives: 
>>> https://groups.google.com/group/akka-user
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "Akka User List" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to akka-user+...@googlegroups.com.
>>> To post to this group, send email to akka...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/akka-user.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>

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