Hi Brian,
thanks for sharing your ideas.
Am 11.12.2017 um 01:13 schrieb Brian Topping:
> What if you kept the shard for the geographies and removed it for the
> users, keeping the latter persistent all the same. Then spread the
> persistence configuration for users across the cluster (I use ZK fo
ld check out the concept of the "Home Location Register" in the
> realm of cellular telephony.
>
> On Sunday, December 10, 2017 at 3:03:33 AM UTC-7, Arno Haase wrote:
>
> I am thinking about how to build a massively parallel online game on
> top
> of Ak
I am thinking about how to build a massively parallel online game on top
of Akka cluster. The game is based on a huge two dimensional "world"
through which players can move.
I would like to scale across several servers, and I would like players
who are close to each other in the game to be co-loca
I am aware that response entities must always be consumed with akka-http
client.
For (very) slow connections I find it difficult to do that reliably.
Consuming the entity is asynchronous and therefore requires timeouts -
but if the timeouts fire, I may be left with an entity that is only
partly co
> /_Question_:/
> - does it make really sense to create dispatcher pro web service client
> or one for all? Do you've any experience with it?
> - is it better to use Dispatcher with fork-join or fixed-size one?
Using the default pool fully utilizes the CPU, and using a separate
dispatcher will
By default it is PoisonPill, but you can
> define your own custom message and then the entity actor can complete
> it's work before stopping itself.
>
> /Patrik
>
> On Tue, Apr 18, 2017 at 7:50 AM, Arno Haase
> <mailto:arno.ha...@haase-consulting.com>> wrote:
xcept if a library touched some
> specific internals / private APIs - see the release notes for details),
> so you should be able to quickly hop onto it :-)
>
> Happy hakking!
>
> --
> Konrad `ktoso` Malawski
> Akka <http://akka.io> @ Lightbend <http://lightbend.com>
When shutting down an ActorSystem, I would like to shut down a
ShardRegion in three phases to ensure consistency:
1. Prevent sharded entities from receiving any new commands
2. Let the sharded entities finish their work
3. Actually shut down the ShardRegion, stopping all sharded entities and
allow
When you kill a JVM running a cluster node, it becomes 'unreachable'.
The other nodes in the cluster have no way of knowing whether this is
permanent or temporary (e.g. network congestion).
In order for a singleton to be started on another node, the node it was
running on must be moved to state "d
state will be full mapping userId -> timestamp, so I'm not sure
> if that helps.
>
> cheers,
> Rafał
>
> W dniu środa, 8 marca 2017 16:34:49 UTC+1 użytkownik Arno Haase napisał:
>
> Rafał,
>
> thank you for the fast reply!
>
> I had th
message sent to a shared User entity will
> activate the target if necessary.
> I think it will be reasonable from resource management point of view,
> and also safe against system restarts.
>
> Cheers,
> Rafał
>
> W dniu środa, 8 marca 2017 06:35:11 UTC+1 użytkownik
I am working on a social media kind of system, and we have users
represented as sharded persistent entities. Now we want to react to
users' inactivity, e.g. sending out 'come back' emails to users who were
inactive for a week.
Any suggestions for how to implement that? Scheduling (and mostly
cance
s take time, and we drop it from the calling
> function, but in the backend it was successful
> - What if the job that is performing the commit has to do it over
> multiple DB and some succeed and some fail
>
> Also, how should be orchestrate the API calls.
>
> On
Assuming you are thinking about transactional access to a relational
database, you could have an actor representing the transaction. Every
write goes to it as a message, and it stores these operations. A
'commit' message can then trigger the actual database transaction, with
all writes being done i
hat you need to write a custom stage.
>>
>> -Endre
>>
>> On Tue, Apr 12, 2016 at 11:01 AM, Arno Haase
>> > <mailto:arno.ha...@haase-consulting.com>> wrote:
>>
>> Hi Endre,
>>
>> thanks for the reply. Is there any way I can get s
custom stage.
>
> -Endre
>
> On Mon, Apr 11, 2016 at 8:09 PM, Arno Haase
> <mailto:arno.ha...@haase-consulting.com>> wrote:
>
> I have a Source of element type A, and I am looking for a way to build a
> stage combining several of them into elements of type B. Th
I have a Source of element type A, and I am looking for a way to build a
stage combining several of them into elements of type B. This is done
based on size and count, and an 'incomplete' instance of B needs to be
generated at the end of the stream.
Source.mapConcat() with a buffering function tha
HttpEntity has an apply method taking a ContentType and a
Source[ByteString,Any] which returns a Chunked entity. Each element
returned by the source is encoded as a chunk in the HTTP response.
This is not 'automatic' per se, but it exposes explicit control over
chunking.
- Arno
Am 11.04.2016 um
I guess that depends on what you are trying to achieve, e.g. what degree
of durability, consistency etc. you need.
What you describe sounds like you are basically beginning to write your
own local database. Doing that well involves *hugh* amounts of tricky
code, like ensuring data consistency in r
Hi!
I am involved in developing an Akka-based system that is to be deployed in
three data centers with shared databases (Cassandra, among others). We
would like one of the clusters to handle all modifications, with the other
two serving read requests and stepping up if the 'writing' cluster goe
20 matches
Mail list logo
