Be careful with Flink. IME it's got a long way to go. The core model is
fantastic but there's a lot of low-hanging fruit that needs to be fixed.
On Tuesday, May 2, 2017 at 4:03:12 PM UTC-6, Evan Chan wrote:
>
> Hi Shiva,
>
> Spark will likely be too high latency for you. Practical minimal
Two possibilities:
1. Go out-of-band and drop down to Http using, say, Netty. Flink does this
(it uses Akka remoting for command-and-control but transmits data using
Netty).
2. Stick the files on a blob store like S3 and just send messages telling
the other actor a file is available (or
Leaving aside the tone of this post...
Have you looked at the longer example of the DSL?
http://doc.akka.io/docs/akka-http/current/scala/http/routing-dsl/index.html#longer-example
It has examples of how to delegate an endpoint's business logic off to
actors or futures.
On Sunday, April 2,
One option, which may not be feasible depending on your use case, is to
simply replay *all* events from scratch, rebuilding current state on the
fly when needed. If you can configure enough retention on your Kafka
cluster, it's an option.
Another is to keep periodic snapshots so that you have
Unless you've profiled and found it to be a problem, worry about it later.
On Wednesday, June 8, 2016 at 10:10:37 AM UTC-6, kraythe wrote:
>
> Sorry but i have another newbie question. I have an actor that uses
> cluster sharding. There are potentially millions of these in the sytem
>
Might be best to send those over Kafka. Millions of updates per minute is
a trivial load for a properly tuned Kafka cluster, doesn't even require
more than 2-3 machines.
On Thursday, June 2, 2016 at 3:09:31 PM UTC-6, kraythe wrote:
>
> Good to know. I think I could batch the updates if need
How are you coordinating state between logically-equal actors on different
physical nodes?
On Wednesday, June 1, 2016 at 3:24:57 PM UTC-6, kraythe wrote:
>
> So the reason I didn't think this was cluster sharding is that I actually
> want these supervisor actors (and their supervised children)
I used to run an Akka cluster on top of etcd. I just had a wrapper script
that grabbed seed hosts from etcd and passed them as flags to my java
command.
We were using fleetd to deploy our Akka cluster nodes as Docker instances.
Each node had a sidekick job in fleetd that updated etcd with
I don't want to rain on anyone's parade, but I think there's a reason that
products like Solr and Elasticsearch are complicated: search is hard!
Getting it right at scale is *really tough*.
Personally, I would gladly trade the operational complexity of ES/Solr over
reimplementing them myself.
Don't pass auth info into the *system, *pass with with each message into
the *actor*. When a request comes in and its identity is authenticated,
pass that authentication along with your messages. Then, if needed, let
your actors figure out authorization based on that authenticated identity
Congrats Roland!
On Monday, March 7, 2016 at 10:42:32 AM UTC-7, rkuhn wrote:
>
> Dear fellow hakkers,
>
> as of today I am passing on the baton of Akka Tech Lead @ Lightbend to
> Patrik Nordwall. Don’t worry, I will stay around and keep working on Akka,
> but it will no longer be my day job
Yes.
But without knowing more there's no way we can know if it's an appropriate
choice or not.
On Wednesday, March 2, 2016 at 9:15:50 AM UTC-7, Oscar Gabriel Reyes Pupo
wrote:
>
> Hello,
>
> I'm new in Akka. After reading some examples, I have a simple question, It
> is suitable to use Akka
12 matches
Mail list logo