Hi there,
firstly - remoting does not like such large messages, it's effectively
cloging the pipe.
You should rather try to send more smaller messages to keep the system
responsive - sending a large message will take more time to serially
serialize it etc.
Concerning the speed... You're using the
Are both nodes configured to use kryo?
What's the error you're getting?
Try `default` id generation strategy, like mentioned in another thread this
week.
--konrad
On Thu, Nov 20, 2014 at 7:06 PM, neeraj negi negi.neerajn...@gmail.com
wrote:
Hi,
I have two node system which was working fine
Just use persist() to persist messages.
Snapshotting should not be used for every message - it should be used once
in a while.
— konrad
On Fri, Nov 21, 2014 at 7:40 AM, Karthik Chandraraj ckarthi...@gmail.com
wrote:
Hi,
As per the suggestion, I implemented a QueueActor, which will
Yeah this is one way to do this - to use the view as the read side.
On the other hand, you could use the view to put it into some query
optimised database or journal - this is also a good way to use
akka-persistence,
but for your case it seems persistent view may just be enough.
PS: Just making
Thanks for reporting!
We'll look into it.
refs https://github.com/akka/akka/issues/16346
-- konrad
On Thu, Nov 20, 2014 at 1:08 PM, Sergii Vozniuk ser...@vozniuk.com wrote:
Here
https://github.com/svozniuk/akka-sockets-issue
Четвер, 20 листопада 2014 р. 13:04:52 UTC+1 користувач Sergii
AtLeastOnceDelivery requires the host actor to be a persistent actor.
Regards,
Patrik
On Sun, Nov 9, 2014 at 6:41 PM, Burak Emre Kabakcı emrekaba...@gmail.com
wrote:
The documentation assumes that we need PersistentActor so I didn't know
such option is available. However what I want to do is
Hi Moritz,
On Wed, Nov 19, 2014 at 3:27 PM, Moritz Schallaböck
moritz.schallabo...@agido.com wrote:
Hello fellow hAkkers,
we have multiple persistent actor types distributed using cluster
sharding. Some of them logically belong together, lets say they're
customers and their orders.
Hi Nan,
On Fri, Nov 21, 2014 at 1:53 PM, Nan Zhu zhunanmcg...@gmail.com wrote:
the only way is to replicate what cluster -sharding does?
use a singleton instance to maintain everything? (but that is contrast
with the discipline of DHT which is essentially a de-centralized design?)
Best,
I was pretty fascinated to read about the introduction of Amazon's DynamoDB
Streams http://aws.amazon.com/blogs/aws/dynamodb-streams-preview/. Given
there are DynamoDB based community journal/snapshot store plugins for
akka-persistence, I was wondering whether anyone else was thinking that the
yes, I have refactored system as using cluster sharding now,
just curious about if we can implement state migration with consistent hashing
Best,
--
Nan Zhu
http://codingcat.me
On Saturday, November 22, 2014 at 11:19 AM, Patrik Nordwall wrote:
Hi Nan,
On Fri, Nov 21, 2014 at 1:53
We actually often find this rather useful - for example, if there comes a
response from the previous test case which I did not expect,
it could fail the 2nd test as an unexpected message may come in. This helps to
make sure there’s no spurious and additional messages sent around.
So yes, when
Makes sense to mix both styles. Thanks for the insight from inside the
akka-team ;-)
Keep up the good work!
Am Sonntag, 23. November 2014 00:51:52 UTC+1 schrieb Konrad Malawski:
We actually often find this rather useful - for example, if there comes a
response from the previous test case
Thanks; you too!
Happy hakking!
— konrad
On 23 November 2014 at 00:51:45, Konrad 'ktoso' Malawski
(konrad.malaw...@typesafe.com) wrote:
We actually often find this rather useful - for example, if there comes a
response from the previous test case which I did not expect,
it could fail the 2nd
13 matches
Mail list logo
