Some quick feedback on raw iron performance, on my local workstation. Your
mileage my vary, but I'm pretty happy with these numbers.
Minimal example Webserver code
from: http://doc.akka.io/docs/akka/2.4/scala/http/routing-dsl/index.html
wrk -d30 -c100 -t12 http://localhost:8080/hello
Running 3
I think what you're looking for here is called a vector clock. Akka uses
them internally within its clustering implementation, however the
implementation isn't public.
There are some open source scala/java implementations you might want to
evaluate (Google). I don't have experience with any o
Isn't a valve just a specialization of a throttle?
Throttle at infinite = open valve
Throttle at 0 = closed valve
As long as you have an out of band way to adjust this throttle (via
materialized value?), you should have your valve already.
--
>> Read the docs: http://akka.io/docs/
I have this basic client test. It works way better in 2.4.2-RC2 than ever
before, however I still get an error during cleanup:
[akka.actor.ActorSystemImpl(HttpClient)] Outgoing request stream error (akka
.stream.AbruptTerminationException)
Seems like there's a akka-http/streams bug here, or a u
+1 here as well. I've been waiting in anger for akka-http to catch up to
spray in terms of performance and have verified some great leaps in recent
builds. Thanks guys! If there really is a 6-7x speedup waiting to fall
into place (after bug fixing), that would be amazing (and worth the wait).
At present, for a new learner, go with Spray. Spray is mature and fast and all
around, "just works". Akka-HTTP is the future of stream based HTTP processing
for Akka, but he current 1.0 release lacks the feature parity or performance of
Spray. That will hopefully change with the 2.0 release. I
But! It is important for me that the work of message 1 is done before
> message 2 is handled. And isn't one of the benefits for the actor model and
> akka itself, that I have the garantee to that message 1 is done before
> message 2?
>
> Yes. And you might be in trouble there. In which case,
On Thursday, November 19, 2015 at 12:32:38 PM UTC-8, Patrik Nordwall wrote:
>
>
>
> On Thu, Nov 19, 2015 at 8:06 PM, Jim Hazen > wrote:
>
>> Wait, what? So cluster sharding depends on shared mutable state across
>> your cluster to work? AFAIknew the indepen
I'm not saying use a lot of dispatchers. I'm saying that you should
delegate to maybe 1 more dispatcher for your heavy work to unblock your
actor's dispatching thread (and definitely another for blocking IO)
allowing it to put more of your Actor's mailbox entries to work
concurrently. In one
Wait, what? So cluster sharding depends on shared mutable state across
your cluster to work? AFAIknew the independent local nodes managed their
state internally, communicated/coordinated via network protocolling and
delegated to a master when it needed to determine a shard owner the first
tim
You don't need your clustered actors to be persistence aware. So you are
absolutely free to have sharded stateless actors, or manage state in some other
way.
The confusing part is that the cluster sharding internals requires akka
persistence to be configured for at least one journal. The inter
That's possible. Your actor won't be able to get more work until it completes
its receive. You could:
A: look into actor pool/routers. This will give you more receive blocks to
work with, increasing concurrency.
B: look into spending less time within your receive block, maybe by delegating
Might want to look into mapAsync and mapAsyncUnordered for the linear parts of
your slow graph. You can specify the desired parallelism as part of those calls.
I was about to write that in general there isn't a "make fast" button for
arbitrary graphs. However, that may not be strictly true. Just
Also, the default akka-remoting utilizing Java serialization is dog slow.
There are other threads that discuss swapping out the serializer with much
faster ones. So if you're doing a lot of cluster sharding, your throughput
may be bottlenecked on the remote inter-node IO.
--
>>
Try using the fork-join-executor instead of the thread-pool-executor for
multiplexing large numbers of non-blocking tasks across your CPUs.
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>
Hmm. I'm not an expert here (just use BC for CloudFront). Have you tried
keeping your Java 8 SSLContext while combining that with the BC cipher
support?
Something more like your original, but with the BC ciphers.
Security.addProvider(new
org.bouncycastle.jce.provider.BouncyCastleProvider())
Have you tried adding the BouncyCastleProvider as a security provider?
Then making your normal JSSE calls?
Security.addProvider(new
org.bouncycastle.jce.provider.BouncyCastleProvider())
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http:/
With these latest foundational changes, is akka-http 2.0 intended to be the
'spray parity' release? If not, is there a roadmap for an akka-http client
as rich as Spray's and akka-http server as performant as Spray's?
--
>> Read the docs: http://akka.io/docs/
>> Check
Yea. I can sympathize. Akka 2.4, supports and requires Java 8. Have you
explored the 2.4 milestones? I haven't looked at the 2.4 Java APIs,
however the assumption is that they may have much better support for
lambdas than the current 2.3 Java APIs.
--
>> Read the docs: http
I see this issue happen whenever AWS has a network hiccup. I have a
multi-node cluster behind a LB and akka cluster sharding along with akka
persistence writing to a Dynamo journal. I'm currently on akka 2.3.11,
which means the same shared Dynamo table used to store my persistent actors
is al
If you'd like to handle this in logback land and not deal with altering
akka's logging strategy, you can also configure logback to work in bounded
space and drop overflows as well.
Take a look at logback's AsyncAppender.
http://logback.qos.ch/manual/appenders.html
You'll configure your logback
http://letitcrash.com/post/96078609472/ask-tell-and-per-request-actors
Maybe this will help answer your question. Actors are cheap, but not free.
There are cases where using an actor-per-request pattern has more benefits
than performance detractors. Per method call? I think that would depend
To increase capacity you'll be scaling out nodes, not shard regions.
Shards are logical managers/buckets, they help organize and support the
actual processing actors, but it's those actors that are distributed.
You'll have one for each unique message destination, regardless of your
number of
n@host2?
>
> Thanks,
> Yifei
>
>
>
> On Monday, July 20, 2015 at 3:16:24 PM UTC-4, Jim Hazen wrote:
>>
>> There will be a new actor activated for each unique messageId
>> destination. Messages will arrive at that actor for processing. Actors
>> are grouped int
There will be a new actor activated for each unique messageId destination.
Messages will arrive at that actor for processing. Actors are grouped
into shards, which help manage those actors. If you send 100 messages to
unique destinations across your cluster, they'll be handled by 100 unique
If you already have the solution it shouldn't be hard to put Streams in front
of it to help manage back pressure. Call your code from within the sink and
apply whatever flow controls you need to the source ahead of it.
--
>> Read the docs: http://akka.io/docs/
>> Che
Akka clustering is built on top of akka remoting. The default serialization
used by remoting is terribly slow. Look into swapping it out with a third party
serializer. There are some linked/mentioned in the remoting docs.
Please post any results if a serializer change helps you. I know in my pr
You could implement the mediator yourself and include all your business logic
there. That said, why do this? What's the fear of an extra actor dealing with
these concerns and providing separation?
I don't think it's possible to use an external implementation and not have
separation.
--
Tried looking at the DistributedPubSub module?
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives: https://groups.google.com/group/akka-user
---
You receive
Does this work for you?
http://doc.akka.io/docs/akka/snapshot/contrib/aggregator.html
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives: https://groups.goog
On Wednesday, April 15, 2015 at 9:17:44 PM UTC-7, Rohit Jain wrote:
>
>
>
> On Wednesday, April 15, 2015 at 10:37:36 PM UTC+5:30, Michael Frank wrote:
>>
>> On 04/15/15 04:47, Rohit Jain wrote:
>>
>> How does using akka actor helps in achieving concurrency without use of
>> any external lock
Just because the HTTP protocol doesn't define the semantics doesn't mean
that RESTful services aren't allowed to take this on themselves, and some
do. Kinda like in the US where rights not reserved for the federal
government fall to the states.
ElasticSearch is one such
example:
http://www.e
I was originally thinking that this would be inconvenient for ES clients.
I could work around that. However for anyone attempting to build a
transparent proxy in front of ES (where they can't control client calls),
this would be an impossible to fix solution if a GET with body was
forbidden.
Hmm...
Spray currently allows this and products like ElasticSearch promote GET
bodies. This will be a breaking change for me as well once I migrate to
akka-http.
How opinionated are the developers here? Can this be more of a guideline
than a rule? :)
--
>> Read the docs: http:
Another thing that sometimes bites me on remote hosts that I'm not used to
is a local software firewall. Make sure the host itself isn't dropping
traffic back to your listening ports.
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.a
Try setting JVM system params. For example, an early demo that I hacked up
looked like this. It isn't on EC2, but I don't think that EC2 is really
your problem. Hack out the stuff you don't care about and omit the -J if
not using sbt.
Instance 1:
sbt -J-Dakka.remote.netty.tcp.hostname=lo
Looks like you're trying to connect to a seed that isn't available. Be sure
that your remote.netty.tcp host and port settings match your seed node setting.
They don't seem to here.
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka
This should still be easy with akka-streams. You'll probably need to write
a custom stage though. Check out the documentation on custom stages along
with the cookbook examples. I believe there is an example that implements
a batching collector like this. It's not 100% what you're looking for
it be better to expose some sort of action sink and information
source instead of a single shared object?
Thanks for your time,
Jim
On Sunday, March 8, 2015 at 11:24:58 AM UTC-7, rkuhn wrote:
>
> Hi Jim,
>
> thanks for starting the discussion! Replies inline.
>
> 5 mar 201
Start here:
http://doc.akka.io/docs/akka/2.3.9/contrib/cluster-sharding.html#cluster-sharding
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives: https://gr
Start hers:
http://doc.akka.io/docs/akka/2.3.9/contrib/cluster-sharding.html#cluster-sharding
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives: https://gr
Have you looked into writing a custom router component?
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives: https://groups.google.com/group/akka-user
---
Yo
I was confused. I thought you were looking for something like:
path("v2.0" / "tokens") {
post {
complete("it works")
}
} ~
path("v2.0" / "somethingelse") {
post {
complete("it works")
}
}
Otherwise with
path("v2.0") {
path("tokens") {
You
Have you followed all of the instructions for interacting with remote
actors here: http://doc.akka.io/docs/akka/2.3.9/scala/remoting.html ?
>From the error it appears to me that:
1. You are attempting to create a remote actor from a peer
2. This peer isn't able to properly interact with [akka.tcp
You're missing the route concatenation operator ~ between the two Path
directives.
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives: https://groups.googl
I've been following Akka Streams for bit. I've noticed the changes in M4
and of course read the materialization sections
of:
http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M4/scala/stream-flows-and-basics.html
I have tremendous respect for the Akka team and understand that gettin
Wouldn't migrating from a grouped to groupedWithin based chunker be the
compromise that ppl are looking for? Perform chunk packing within a given
window, but if you're waiting for too long, send what you have?
You mention here and in the JIRA that this a conflate problem, but conflate
deals wi
Only a 10s look and I'm in a rush. But I'm guessing the 'new Chunker()' is
where you want to start. In order for any chunker to process across
message boundaries it'll need to have some type of "memory" and getting a
new one each time probably won't accomplish that.
Now either the Chunker can
Check the nesting.
Does test.my-dispatcher work?
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives: https://groups.google.com/group/akka-user
---
You rece
Is there an ETA for akka-http on 2.4?
According to Mathias, Spray won't be ported to 2.4:
https://groups.google.com/d/msg/spray-user/x0KdMn_7exE/B8Rp2xuSa2sJ and
according to you akka-http also isn't yet ready for 2.4.
I'd like to develop a REST service that takes advantage of cluster sharding
Are these 1.0-M4 modules intended to be compatible with akka-2.4-SNAPSHOT?
I'm having trouble passing a custom materializer to an
IncommingConnection.handleWithAsyncHandler(). The default materializer
seems to work fine, but I wanted to play with buffer sizes.
implicit val materializer = Actor
I think the answer is in the {Scala, Java}Docs of mapAsync:
Transform this stream by applying the given function to each of the
> elements as they pass through this processing step. The function returns a
> Future and the value of that future will be emitted downstreams. As many
> futures as re
Lol. Or not, since you're the OP. Oh well, need more coffee.
On Monday, March 2, 2015 at 10:52:29 AM UTC-8, Jim Hazen wrote:
>
> Might want to look at this thread.
> https://groups.google.com/forum/#!topic/akka-user/wyA4xNfM5LM
>
--
>>>>>>>>&
Might want to look at this thread.
https://groups.google.com/forum/#!topic/akka-user/wyA4xNfM5LM
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives: https:
There's a bunch of information on CORS on the web. Here's my tl;dr.
To prevent web browsers and their JS execution engines from becoming a
malicious request attack vectors, browsers bake into their DNA certain
restrictions on when and how outgoing JS originated web requests are able
to be made
Hi Tim,
Not sure if this what you were thinking, but I tend to roll my own basic
CORS support via route composition of basic spray routing elements. I
haven't tried an akka-http port yet, but assume one would be straight
forward.
val optionsSupport = {
options {complete("")}
}
val corsHead
http://doc.akka.io/docs/akka/2.3.9/java/lambda-actors.html
See section on stopping actors.
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives: https://grou
Seems logical.
>From an actor within a running system you ask the system if it's dead. It
says no, because it still has actors running (there's at least the one
asking the question).
Then, from outside the system you wait for it to terminate, and then check
that it has terminated, which it co
To me, this isn't the correct solution. Passing Source(data) around seems
wrong, it would seem dangerous for large files and impossible for remote
actors if the source were pointer based. The tl;dr is that IMHO the
correct solution, where you process indexing responses in a flow based way,
is
Hi Reid,
Sorry I don't have my IDE in front of me. You might take a look at some of
Akka's scheduling configuration options. You mentioned Spray, and there's
a benchmark example Spray app that ships with a pretty good
application.conf that exposes and tweaks some of these config values, the
I'd also be interested to know what the best practice patterns for bridging
internal/external stream boundaries are. In this case there isn't yet a
well understood pattern for external entities to dynamically feed into a
stream source. There is likewise no easy way for an external library to
A bit of trivia came up today. Basically the question was, would it be a
good or bad idea to stick some number of actors behind a BroadcastRouter
and allow their ability to handle a message dictate whether it was routed
to them or not. For the most part, if one actor would be able to handle
t
You might want to try a custom serializer. Bottom of this page. I'd be
interested to know how well they work. Never used em, sorta curious.
http://doc.akka.io/docs/akka/2.3.9/scala/serialization.html
There is also a remoting SPI, but I don't know of any alternate
implementations.
--
>>>
These days the current API supports a number of ways of constructing a
Source.
http://doc.akka.io/api/akka-stream-and-http-experimental/1.0-M3/?_ga=1.72893075.1209102577.1407799351#akka.stream.scaladsl.Source$
Based upon these available methods, if I needed to supply 0 or 1 elements
based upon
Take a look at cluster sharding. By far the easiest way to get started
with clustered/distributed actors.
http://doc.akka.io/docs/akka/2.3.9/contrib/cluster-sharding.html#cluster-sharding
On Sunday, February 15, 2015 at 7:58:02 AM UTC-8, gitted wrote:
>
> Currently I am a play application that
Correction? I don't think I said main was a daemon, I said the
Implicits.global executor must be. In any case your main thread delegates
to other executors. Then, without the sleep, you run out of code and the
VM exists. Because at that point main is dead and no other non-daemon
threads are
You're best off answering these for yourself. I actually don't know off
the top of my head.
Take a look at the method signatures. If they require a passed in
execution context (implicit or not), they'll be using whatever context is
in scope. If they don't require an execution context, then t
This question is probably better asked on one of the Scala mailing lists.
You'll perhaps get a better answer.
To understand what is going on, take a look at the signatures for
Future.apply and Future.foreach. Each method has multiple parameter lists,
with the last requiring (a possibly implic
I think you're confusing two different sources of ExecutionContexts.
The Akka runtime, as far as I know, schedules and uses non-daemon threads
internally, 100%. So all the threads supporting the ActorSystem and those
backed by actor related ExecutionContexts (i.e., context.dispatcher),
should
Now that I think even more on the problem the more it seems that we're
trying to solve too much within a single flow. There are concepts that
ought to be independent that we're forcing to become dependent.
I still like the independent streams model. I'd start with that, but with
a realization
Thanks for creating the issue. Please note that there were actually two
issues discovered. The client flow issue was logged, but the server
request parsing issue wasn't.
The rest of this post is really just going through my thought process, so
that the group can benefit from an analysis of th
This appears to me to be a problem with rates and cycles within the
HttpClient.transportToConnectionClientFlow.
Augmenting the flow with a buffer as described in
http://doc.akka.io/docs/akka-stream-and-http-experimental/1.0-M3/scala/stream-graphs.html
seems to get us much farther. Here's the
There are probably a few ways to do this. Most straight forward might be
to start a local actor as part of each node's startup code. Then use Akka
clustering to observe node failures. Use some deterministic strategy to
reallocate that actor on some other host (let's say failed +1 in your
rin
73 matches
Mail list logo
