Another solution I can think of is to forward the cassanda [user] events to
a key-value db such as redis. For example, [email -> userId]. Anyone
else come across this problem and how did they solve it?
On Tuesday, July 5, 2016 at 2:35:36 PM UTC+8, Lap Ming Lee wrote:
>
> Hi,
>
> Suppose
Hi,
Suppose I have a stream of [user] events coming from cassandra and I
forward those events the correct [user] view actor using cluster sharding.
How would I perform a query for all the users in this case? For example,
if I need to create a new [user], I first need to check if any of the
Ok I'll have a look, even if I set all the confs to the same minimum of 2
worker nodes, the master starts up when there are no worker nodes yet.
On Mon, Jul 4, 2016 at 11:35 AM Patrik Nordwall
wrote:
> The sample doesn't have those settings, but i added them for two roles and
> I could see from
The sample doesn't have those settings, but i added them for two roles and
I could see from the MemberUp logging that it was working
mån 4 juli 2016 kl. 11:08 skrev Raymond Roestenburg <
raymond.roestenb...@gmail.com>:
> That does not seem to solve the issue, I'll check out the
> akka-sample-clust
Yes, I definitely will give a try to Kryo serialization. Right know,
despite of using standard Java serialization, we're not sending class id's
over the wire since we have a morphological serialization on each class.
Nevertheless the Akka itself is doing that so Kryo could provide a good
enhancemen
Thanks Patrik for clarifying the Artery part I had misunderstood, it is
getting really close anyway which makes me *-and sure others-* happy.
@Eduardo, the Kryo part will still apply, specially listing the classes as
I did in my config example,
I wouldn't worry much about the KryoQueueBuilder pa
That does not seem to solve the issue, I'll check out the
akka-sample-cluster-scala to see what you're doing differently there..
On Sunday, July 3, 2016 at 8:45:25 PM UTC+2, Raymond Roestenburg wrote:
>
> Thanks Patrik, I'll try that.
>
> On Friday, July 1, 2016 at 8:32:27 AM UTC+2, Patrik Nordwa
Ok. In our case the ack is per message... anyway I could expect a very good
improvement in number of transactions upgrading to Artery. We don't need
the factor 30x you have. If we have a factor 2 or 3 it would be very
welcome.
Thanks for the info. This numbers could help me to push it into a near
On Mon, Jul 4, 2016 at 9:13 AM, Eduardo Fernandes wrote:
> Wow!!! I have to try the new remoting!
>
> The measurement is quite basic: I have a pool of threads and I just call
> the sends() and wait for the response and execute a new send. Nothing
> particular. I made a simple test with the old re
Wow!!! I have to try the new remoting!
The measurement is quite basic: I have a pool of threads and I just call
the sends() and wait for the response and execute a new send. Nothing
particular. I made a simple test with the old remote and my numbers were
also around 25.000 msg/s, so we agree on th
Then I question how you measure this in your benchmark. With old (current)
remoting I have observed max throughput of 25.000 msg/s (one way) using
this test:
https://github.com/akka/akka/blob/artery-dev/akka-remote-tests/src/multi-jvm/scala/akka/remote/artery/MaxThroughputSpec.scala
With new remot
11 matches
Mail list logo
