ter: @hseeberger <https://twitter.com/hseeberger>
> Public key: keybase.io/hseeberger
>
> On 20 Dec 2015, at 13:17, Guido Medina <oxy...@gmail.com >
> wrote:
>
> Sorry for brevity writing from phone which I hate.
>
> In a nutshell I would like your plugin akk
Hi Patrik,
About performance, it seems to perform worse than the old akka remote, I
usually get averages of 1ms and peaks between 10-20ms:
INFO 07:43:01,539 PriceDistributor - Price stats: avg 2.5896ms, max 75ms
INFO 07:43:01,540 PriceDistributor - Price stats: avg 2.6026ms, max 75ms
INFO
16 at 12:36:57 PM UTC-5, Guido Medina wrote:
>>
>> You could create a compressed list of Integers and send the message to
>> their supervisor, that way the children's supervisor pass that message to
>> each actor ID, assuming your IDs come from a sequence,
>> if yo
You could create a compressed list of Integers and send the message to
their supervisor, that way the children's supervisor pass that message to
each actor ID, assuming your IDs come from a sequence,
if you have from 1 to 1m, that can be expressed as [1,20], [25,50], [52],
[55..100] where each
Hi Patrik,
Firstable many thanks for the great effort you guys are putting into this
project.
I would like to test it, where can I find a mini-doc to make akka-cluster
and akka-remote work with Artery?
Regards,
Guido.
On Friday, June 10, 2016 at 4:46:09 PM UTC+1, Patrik Nordwall wrote:
>
>
And with the new akka remote it might be pointless, you could control some
association by for example, deploying children actors of a shard actor, in
that matter such children are local to their parent and to their siblings,
but that's the end of it,
anything else because it will be you against
Ignore, it is part of Aeron troubleshooting, a shared memory issue, need to
adjust stuff...
On Sunday, June 12, 2016 at 11:14:16 AM UTC+1, Guido Medina wrote:
>
> Hi Patrik,
>
> Have you seen this before? It is happening on one PC but not in the other,
> I changed *advanced.idle-
mark these temp folder to
delete?
Guido.
On Sunday, June 12, 2016 at 11:14:16 AM UTC+1, Guido Medina wrote:
>
> Hi Patrik,
>
> Have you seen this before? It is happening on one PC but not in the other,
> I changed *advanced.idle-cpu-level* to 3, got that error, then removed
I read that if you start the driver you have to stop it in order to delete
the sampling folder which for Linux is usually at /dev/shm (shared memory)
so, a bug?
On Sunday, June 12, 2016 at 12:52:59 PM UTC+1, Guido Medina wrote:
>
> I fixed this on Linux by deleting the folders created by
/config#merging-config-trees
On Monday, June 13, 2016 at 9:10:50 AM UTC+1, Guido Medina wrote:
>
> To look for that key in the config open reference.conf of
> akka-remote-2.4.7.jar
>
> On Monday, June 13, 2016 at 9:10:01 AM UTC+1, Guido Medina wrote:
>>
>> Yes, just chang
have more questions.
>
> /Patrik
>
> lör 11 juni 2016 kl. 13:11 skrev Guido Medina <oxy...@gmail.com
> >:
>
>> Hi Patrik,
>>
>> Firstable many thanks for the great effort you guys are putting into this
>> project.
>> I would like to test it
I got this exception because I'm explicitly excluding Netty 3 as
dependency, should I leave it? but then, why is Netty 3 still in there?
On Saturday, June 11, 2016 at 3:05:45 PM UTC+1, Guido Medina wrote:
>
> This stack trace is better as it shows the jar it comes from:
>
> ERROR
work. Let us know how it goes or
> if you have more questions.
>
> /Patrik
>
> lör 11 juni 2016 kl. 13:11 skrev Guido Medina <oxy...@gmail.com
> >:
>
>> Hi Patrik,
>>
>> Firstable many thanks for the great effort you guys are putting into this
>&
Hi Patrik,
Have you seen this before? It is happening on one PC but not in the other,
I changed *advanced.idle-cpu-level* to 3, got that error, then removed that
setting and recompiled but still getting the following exception:
ERROR 11:05:07,979 ArteryTransport(akka://DevCluster) - Aeron
2016 at 9:31:28 AM UTC+1, Guido Medina wrote:
>
> We discussed this via Gitter and got some tips of what I probably did
> wrong, like too many threads, etc etc, scratch these results, I have to
> re-test again.
>
> About Netty, yes, that was addressed also.
>
> T
:
>
>
>
> On Mon, Jun 13, 2016 at 8:53 AM, Guido Medina <oxy...@gmail.com
> > wrote:
>
>> Hi Patrik,
>>
>> About performance, it seems to perform worse than the old akka remote, I
>> usually get averages of 1ms and peaks between 10-20ms:
>>
Akka will do that in an orderly fashion
On Wednesday, June 15, 2016 at 5:43:20 PM UTC+1, Yan Pei wrote:
>
> Thank you Guido. If I don't shutdown akka system, should I also not kill
> the actors under the akka system?
>
> On Wednesday, June 15, 2016 at 9:42:44 AM UTC-5, Gui
I know I have between akka actor, cluster, remote and protobuf around 5m, I
guess that if you add http and streams you would be very close to that
value.
check if you are not including different versions as I can see 9m easily as
a total not as addend.
On Saturday, June 4, 2016 at 10:35:54 AM
*Correction:* akka actor + cluster + remote + protobuf jar = 6.1m
On Saturday, June 4, 2016 at 12:43:29 PM UTC+1, Guido Medina wrote:
>
> I know I have between akka actor, cluster, remote and protobuf around 5m,
> I guess that if you add http and streams you would be very close to that
Nope, if you are controlling your application via Spring, make akka system
a singleton bean with destructor method = terminate.
On Tuesday, June 14, 2016 at 5:29:29 PM UTC+1, Yan Pei wrote:
>
> Hello All,
>
>I've designed the application with AKKA + Spring Framework IOC + Spring
>
to
pass constructor parameters)
If you still have doubts when I get home I'mm paste some sample code.
HTH,
Guido.
On Tuesday, June 28, 2016 at 8:58:37 AM UTC+1, Guido Medina wrote:
>
> I try to understand the problem he is describing, but when someone suggest
> a solution it co
I try to understand the problem he is describing, but when someone suggest
a solution it confuses me,
specially when the solution shows little knowledge of the framework being
used.
His question is akka related, he wants to resolve his problem with Akka,
he doesn't need to use an ESB to
with a
dispatcher with few threads.
It might be difficult to understand why you don't need to lock anything but
think again and read Akka message ordering, you will realize it is simpler
than what you think.
HTH,
Guido.
On Tuesday, June 28, 2016 at 9:30:38 AM UTC+1, Guido Medina wrote
You could still have Spring JMS beans poll and forward to its corresponding
actor (1 actor per queue), switch on/off would be to forward to Akka or to
just use your Spring processor as you are doing atm.
if you need ack you can do it with 1 intermediary -and supervisor- actor
doing the
So you expect it work on a experimental version and then you will move to
the version could actually work?
I don't understand that logic, you should set your versions to:
com.typesafe.akka
akka-actor_2.11
2.4.7
com.typesafe.akka
akka-persistence_2.11
2.4.7
And I
ld be awesome,
> because then maybe I could just solve my issue by forcing that priority ;)
>
> Thanks again, for all the help :)
>
> On Tuesday, June 28, 2016 at 1:08:57 PM UTC+2, Guido Medina wrote:
>>
>> You could still have Spring JMS beans poll and forward to
Hi Rajesh,
If you have only one seed node, once restarted, other nodes won't try to
re-join, at least that's the behavior for akka 2.4.7
I see one exception that was probably fixed already so you might want to
use either latest 2.4.x which is 2.4.7 or latest 2.3.x
Try the latest version of
*Edit:* I can be wrong that's what I meant, "not can't"
On Sunday, June 26, 2016 at 2:28:51 PM UTC+1, Guido Medina wrote:
>
> Hi Rajesh,
>
> If you have only one seed node, once restarted, other nodes won't try to
> re-join, at least that's the behavior for akka 2.
; When I kill Node A, Node B become Oldest. When I restart Node A, Node A
> starts it's own cluster. It is not rejoining the cluster.
>
> Regards,
> Rajesh
>
> On Sunday, June 26, 2016 at 7:00:05 PM UTC+5:30, Guido Medina wrote:
>>
>> *Edit:* I can be wrong that's wh
It depends, if your application life-cycle is handled by Spring then I
usually recommend to have the ActorSystem as a singleton bean with destroy
method set to "terminate"
It also depends on what type of application you are building, do you really
need Spring? if you really do then that's one
Every man is by himself in the dependencies world and some other men thrive
through such mayhem by using:
*mvn -U versions:display-dependency-updates | grep -e '->' -e Building*
HTH,
Guido.
On Thursday, February 4, 2016 at 5:39:55 AM UTC, gwanggaeto wrote:
>
> In mvnrepository.com, I found
Forgot to mention, when a job finishes, it sends poison pill to its parent
unless that job is a master/starter job.
On Friday, February 5, 2016 at 4:06:18 PM UTC, Guido Medina wrote:
>
> Allow your design to have sequential and parallel jobs as the following by
> abstractin
started,
if you got to onReceive this job specific task is done and what he needs to
do is to supervise its subtasks.
On Friday, February 5, 2016 at 4:18:50 PM UTC, Guido Medina wrote:
>
> The mechanism is a bit tricky. the trick is to use preStart() to do that
> Job unit of work an
Step 1, 2 and 3 need to be done in sequence/synchronous which is OK because
preStart runs asynchronously.
On Friday, February 5, 2016 at 4:47:22 PM UTC, Guido Medina wrote:
>
> Actor's A preStart does the following:
>
>1. Load stuff from DB - *might fail and restart actor but is
Well, you can't stay forever in preStart() because you would be blocking a
thread, if your actor must be resilient and must start then the backoff
supervisor with a time and stash while the actor is not ready will be your
only choice.
On Friday, February 5, 2016 at 2:49:35 PM UTC, Guido Medina
The mechanism is a bit tricky. the trick is to use preStart() to do that
Job unit of work and the 1st message to process sub-task explained in
details:
- Supervisor loads Job A which has a definition like how many times
should retry, how long to backoff, etc.
- Supervisor spawn actor
the last known state of
> the job.
>
> You've been great, this is a very helpful dialog, also good for this user
> group in case someone else has the same conundrum in the future :)
>
> On Friday, February 5, 2016 at 11:18:50 AM UTC-5, Guido Medina wrote:
>>
>> T
s task 1, task 2 and task 3 all children of Job B.
Guido.
On Friday, February 5, 2016 at 3:59:02 PM UTC, Guido Medina wrote:
>
> Divide, conquer and repeat, don't treat each case differently there since
> you have a parent, for the sake of simplicity I will change the term
Hmmm, that shouldn't happen, I poison self all the time no problem, I think
maybe is a bug on the akka.patterns, instead try creating your own
supervisor strategy with time in mind:
http://doc.akka.io/docs/akka/2.4.2-RC2/scala/fault-tolerance.html
Then read a bit there what the default
Divide, conquer and repeat, don't treat each case differently there since
you have a parent, for the sake of simplicity I will change the terms and
define the following:
- 1 actor = 1 transaction.
- 1 transaction is a unit of work that either fails of success.
- each transaction has
the parent
creators, meaning that the overwritten supervisorStrategy() method applies
to the children actor not to the actor itself.
On Friday, February 5, 2016 at 7:14:09 PM UTC, Guido Medina wrote:
>
> Hmmm, that shouldn't happen, I poison self all the time no problem, I
> think maybe
Tests on Solr with JDK 8u72 corroborates my statement of G1GC looking good:
https://wiki.apache.org/solr/ShawnHeisey
On Friday, February 5, 2016 at 11:50:16 AM UTC, Guido Medina wrote:
>
> It looks like for Java 8u72 G1GC is pretty much fixed, again I'm using it
> for low heap/late
> fre 5 feb. 2016 kl. 12:54 skrev Guido Medina <oxy...@gmail.com
> >:
>
>> Tests on Solr with JDK 8u72 corroborates my statement of G1GC looking
>> good:
>>
>> https://wiki.apache.org/solr/ShawnHeisey
>>
>>
>> On Friday, February 5, 201
It looks like for Java 8u72 G1GC is pretty much fixed, again I'm using it
for low heap/latency micro-services, each micro-service won't exceed 1GB
heap size.
I had to remove the MaxGCPauseMillis=10 because was making GC too costly
slowing down my application and causing some 10+ ms pauses, and
Or, you can use something like Kryo which is kind of straight forward and
very fast compared to Java serialization, for the lazy here is a quick
snippet for your application conf:
akka {
extensions = [
"com.romix.akka.serialization.kryo.KryoSerializationExtension$"]
actor {
preStart is your friend, but also make sure you create these children in
another dispatcher, preStart is my preferred way, another way is an actor
with stash, with stash will give you less performance as the mailbox has
different requirements and the code will be less readable.
HTH,
Guido.
preStart method always executes before the 1st message is consumed so you
don't need both at the same time unless you have to wait for another thing
to happen hence handling states as you are in your example.
On Friday, February 5, 2016 at 2:42:36 PM UTC, Guido Medina wrote:
>
> pr
Take a look at akka patterns backup supervisor, I think you can backoff for
a time in case DB problem will take some time to fix:
http://doc.akka.io/api/akka/2.4.1/index.html#akka.pattern.BackoffSupervisor
On Friday, February 5, 2016 at 2:43:47 PM UTC, Guido Medina wrote:
>
> preStart
If that is the case I think that design can be improved, I don't know Scala
but I can explain my solution, assuming that the number of channels is a
constant you can do the following:
public int hashOfSenderToRecipient(ActorRef sender, ActorRef recipient) {
return sender.hashCode() * 31 +
If that is the case I think that design can be improved, I don't know Scala
but I can explain my solution, assuming that number channels are a constant
you can do the following:
public int hashOfSenderToRecipient(ActorRef sender, ActorRef recipient) {
return sender.hashCode() * 31 +
I'm half capacity today due to long hours, revert the division...
On Monday, February 1, 2016 at 7:57:58 PM UTC, Guido Medina wrote:
>
> If that is the case I think that design can be improved, I don't know
> Scala but I can explain my solution, assuming that number channels are a
&
I started testing today so I still have no data, I barely finished tuning
the parameters base on research, but facts still zero, nada :(
On Monday, February 1, 2016 at 7:11:09 PM UTC, Konstantin Shaposhnikov
wrote:
>
> Out of curiosity what are the average and max GC pause times you observing
Hi,
I'm wondering if anyone has dealt with the pain of tuning the JVM 8 GC for
Akka micro-services where the heap size isn't more than 1GB per JVM, here
is what I have come up with:
-server
-Xms256m
-Xmx256m
-XX:NewSize=64m
-XX:MaxNewSize=64m
-XX:MaxTenuringThreshold=2
-XX:+UseConcMarkSweepGC
Try setting some GC options just to be able to finish the tests, that will
at least tell you that there is too much garbage being generated, try
either of the following:
For a quick test:
-server
-XX:+UseG1GC
-XX:+AlwaysPreTouch
For a better performance test try:
-server
-Xms1g
-Xmx1g
Typos correction, I'm a bit sleepy sorry:
*Note:* Some old JVM options for Java 8 are *now* default to true or what
should be obvious like *-XX:+UseNewParGC* for *young* generation.
On Monday, February 1, 2016 at 5:03:15 PM UTC, Guido Medina wrote:
>
> Hi,
>
> I'm wondering if anyo
pause.
On Wednesday, February 3, 2016 at 1:21:51 PM UTC, √ wrote:
>
> Do you have a jmh bench for testing this?
>
> --
> Cheers,
> √
> On Feb 3, 2016 1:58 PM, "Guido Medina" <oxy...@gmail.com >
> wrote:
>
>> For what I could gather and after 2012 bug
For what I could gather and after 2012 bug fixed on the Linux kernel for
NUMA it is safe and profitable to use NUMA, though I'm not fully aware if
G1GC is NUMA-aware, at least JVM is not complaining about it:
-
That has been reported and resolved, tried 2.4.2-CR2 which was released
yesterday I think.
On Wednesday, February 3, 2016 at 8:05:18 PM UTC, tigerfoot wrote:
>
> Hello,
>
> I'm running some simple HTTP performance measurements. I've created a
> trivial "ping" endpoint (blindly returns "pong")
Sorry I meant try 2.4.2-RC2
On Wednesday, February 3, 2016 at 8:18:22 PM UTC, Guido Medina wrote:
>
> That has been reported and resolved, tried 2.4.2-CR2 which was released
> yesterday I think.
>
> On Wednesday, February 3, 2016 at 8:05:18 PM UTC, tigerfoot wrote:
>>
>&g
Imagine there is a dedicated mailbox per remote TCP connection, example:
- Assume you have node 1, node 2 and node 3
- node 1 has a single consumer multiple producer mailbox dedicated for
node 2 and another for node 3.
- that same for the other nodes.
So if many actors from node 1
Hi,
I recently read there is a Netty single channel between nodes to strongly
guarantee message ordering, is that true?
My other concern is about message ordering when using remote/cluster
extensions:
Say there are N channels between *node_1* and *node_2*:
- How is a channel selected when
Your pom is broken, you are using 3 distinct versions of akka and 2
versions of scala.
Set akka to 2.4.1 (or 2.4.2-CR1) and scala to 2.11
On Tuesday, February 2, 2016 at 11:35:09 AM UTC, Augusto Vinicius wrote:
>
> Hello everybody!
>
> Its my first time using Akka and logging with
I have been using Akka remote/cluster for a year now, I was sold with
location transparency so my micro-services have a cache of remote actors
and for the engine it is irrelevant where the actor is, the only drawbacks
of akka-remote are:
- It is still based on Netty 3.x which is kind of old
*Correction highlighted:*
Hepin's *Netty 4* implementation is "not" publicly available, though he
forgot to eliminate it from Maven central servers, though I'm not using it
because is *NOT* a contribution purposed for the community:
On Sunday, January 31, 2016 at 4:39:29 PM UTC, Gu
While Akka HTTP is accessible to Java 8 users I decided to go for an
alternative which I was trying to avoid but at least I know is of high
performance and it fits right my needs.
When a connection is upgraded to websocket it is passed to an actor, also
every message sent is forwarded to an
Yeah, it seems the way remote was originally designed and coded makes
really difficult to migrate which lead my suggestion before to an
intermediary solution in order to make it faster and remove a well known
JVM garbage emitter (Netty 3)
There are at least a couple of successful attempts in
Hi,
Has anyone been able to write an Akka HTTP websockets server that
delegates/relays the established connection to an existing or newly created
actor?
where messages sent from that connection comes to an actor and messages to
another actor? (I'm not sure how is this done behind the scenes if
Take into account the distinction between outside world (HTTP, Websockets)
and inside world (Akka Cluster with each role with some HA capability)
*Disclaimer:* I have only 1 year of experience using Akka but successfully
implemented my shard for DDD:
I have HTTP servers load balanced with HA
/guidomedina/b586936a4625ae3a25ca
On Friday, February 26, 2016 at 2:27:21 PM UTC, Guido Medina wrote:
>
> Take into account the distinction between outside world (HTTP, Websockets)
> and inside world (Akka Cluster with each role with some HA capability)
>
> *Disclaimer:* I have only 1 yea
As far as my experience with RabbitMQ goes they provide which will start a
loop thread and a handler function should be specified.
*RMQ Java client:* https://www.rabbitmq.com/java-client.html
Your handler function will just forward the message to your intended actor,
and your handler should
*Correction of previous response:* As far as my experience with RabbitMQ
goes they provide *a client* which will start a loop thread and a handler
function should be specified.
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>>
ble but also successful.
>>>
>>> Ideas could be to use Aeron in terms of a communication model (e.g. by
>>> switching off redeliveries since we don’t need them) or to research
>>> QUIC—but a pure UDP transport would also be interesting to explore in order
>>
ficient remoting layer.
>
> -Endre
>
> On Thu, Jan 21, 2016 at 4:59 PM, Guido Medina <oxy...@gmail.com
> > wrote:
>
>> At the moment using Akka 2.4.1 with Kryo serialization my total cost of
>> messages travelling from Node A to B and then to C varies fr
I know the saying: make it work *-and correct-* and then make it fast.
But 3ms for 3 JVMs *-2 hops -> Message going from A to B and then to C-*
running on localhost host is ridiculously slow, I mean, I'm using other API
that transmits FIX messages *-financial industry-* from a high speed
Hi Luben,
There are other types of mailboxes good for that (depending on your
requirements) you have bounded non-blocking and I'm not 100% sure but I
think I read somewhere that in Akka streams you have a bounded chopping
head sink, say you don't care about head messages that have taken too
I'll motivate you to get a better performance as if the current
implementation were on Netty 4.
Enjoy: https://www.youtube.com/watch?v=yJ7ZgeKx8a8
On Sunday, February 21, 2016 at 12:48:56 PM UTC, Marek Żebrowski wrote:
>
> After adding framing to
>
>
Now on another I'll be one of the users that will appreciate a lot your
effort as I completely relay on akka-remote for my (or my company) trading
application.
When I'm able to just get rid of Netty 3 that will be a happy day.
Thank you very much for trying and probably boosting this
NewSize and MaxNewSize should had been at least (recommended) 25% of the
your new heap size (for 4g make it 1gb) but I don't think that would had
made a difference anyway, seems the problem at this point is a memory leak.
On Monday, February 1, 2016 at 5:56:49 PM UTC, Sebastian Jastrzebski
Did you try the following JVM options?
-server
-Xms2g
-Xmx2g
-XX:NewSize=512m
-XX:MaxNewSize=512m
-XX:+AlwaysPreTouch
-XX:MaxTenuringThreshold=2
-XX:+UseConcMarkSweepGC
-XX:+ParallelRefProcEnabled
-XX:+UseCMSInitiatingOccupancyOnly
-XX:CMSInitiatingOccupancyFraction=80
On Monday, February 1,
My new *G1GC* parameters:
-server
-Xms256m
-Xmx256m
-XX:+AlwaysPreTouch
-XX:+UseG1GC
-XX:MaxGCPauseMillis=10
-XX:+PerfDisableSharedMem
-XX:+ParallelRefProcEnabled
I found an interesting article about a major Linux related GC bug which is
causing long pauses:
to
guarantee the akka documented order of events.
On Tuesday, February 2, 2016 at 11:36:14 AM UTC, drewhk wrote:
>
> HI Guido,
>
> On Tue, Feb 2, 2016 at 11:40 AM, Guido Medina <oxy...@gmail.com
> > wrote:
>
>> Hi,
>>
>> I recently read there is a Netty single chann
With one connection, as soon as the message gets to the other side and it
is put into the target mailbox the promised akka ordering documented rules
are covered with that (it can be proven mathematically or by logic)
On Tuesday, February 2, 2016 at 12:57:33 PM UTC, Joseph Noir wrote:
>
> Hi,
>
recipient, it sounds repetitive but the concept is in itself a bit
recursivethe happens before rules are hence implied to be true, by
mathematical implication.
On Tuesday, February 2, 2016 at 1:09:51 PM UTC, Guido Medina wrote:
>
> With one connection, as soon as the message gets t
m/protocol-buffers/) instead of JSON.
> You recommend using Vort.x with Netty implementation instead of Akka HTTP
> for now?
>
> Br,
> Alan
>
> Dana srijeda, 9. ožujka 2016. u 11:11:43 UTC+1, korisnik Guido Medina
> napisao je:
>>
>> *Disclaimer:* The Akka HTTP
w and then with the process progress
> and with the final result.
>
> So I will have one Actor instance for each execution, lets call it
> ProcessMonitor and one Actor instance for each node as executor. These will
> be reused.
>
> I think I may work as I want.
>
> On 17 March 20
introducing new bugs. Therefore
>>> we will not update to Netty 3. When we have a stable replacement the old
>>> implementation will be removed.
>>>
>>> We are looking forward to working on this important area, and community
>>> involvement is very much welcome.
Regards,
Guido.
On Friday, March 18, 2016 at 11:26:07 AM UTC, drewhk wrote:
>
>
>
> On Fri, Mar 18, 2016 at 12:13 PM, Guido Medina <oxy...@gmail.com
> > wrote:
>
>> Given the following scenario, which design would fit best:
>>
>> Assume I have 2 recei
*Disclaimer:* The Akka HTTP performance on that page is outdated, now; if
Akka HTTP is around 75% performance of Play 2, you can guess where it would
be on that list.
On Wednesday, March 9, 2016 at 9:58:04 AM UTC, Guido Medina wrote:
>
> Hi Alan,
>
> I hope the Akka/Java example h
o add nodes
> whilst any node in the cluster is considered unreachable, which is a
> problem if I'm doing a rolling restart of all the nodes.
>
> Regards,
> Ben
>
> On Thursday, March 17, 2016 at 4:51:30 PM UTC-4, Guido Medina wrote:
>>
>> As for cluster.leave(cluste
Given the following scenario, which design would fit best:
Assume I have 2 receivers@node-1, for simplicity lets call them (I know I'm
using the wrong convention):
- receiver-1@node-1
- receiver-2@node-1
Assume I have 4 processors@node-2, for simplicity again lets call them:
-
in my case.
HTH,
Guido.
On Thursday, March 17, 2016 at 8:33:29 PM UTC, Guido Medina wrote:
>
> Hi Benjamin,
>
> I also rely on cluster events and AFAIK you can expect (and trust)
> *MemberUp* and *MemberRemoved*, these IMHO are the only two consistent
> states you can trust.
&
- MemberUp(Member(address =
akka.tcp://DevCluster@127.0.0.1:54621,
status = Up))
Regards,
Guido.
On Thursday, March 17, 2016 at 10:15:52 PM UTC, Guido Medina wrote:
>
> I just tried this:
>
> final Cluster cluster = Cluster.get(system);
> cluster.leave(cluster.selfAd
Won't happen, the micro-services are being sent Linux SIGTERM, which is why
I'm hooking on the JVM shutdown.
On Friday, March 18, 2016 at 5:26:01 PM UTC, Konrad Malawski wrote:
>
> I precisely explained for what event you need to wait :-)
>
> Proper graceful shutdown means you need to wait for
me.
>
> Apache Crunch looks great, may be there is a Scala client for this. I will
> read up on it more.
>
>
>
>
> On Wednesday, March 30, 2016 at 9:53:51 PM UTC+11, Guido Medina wrote:
>>
>> Even if you want to do it yourself you still have to reduce data fro
I haven't seen any system stopping something consciously that it was unable
to start, the created instance is just an instance like another other
object which will be GCed.
If you look at it from a state machine perspective Status: CREATED => CALL
START (or preStart don't worry about details)
What I meant by distributed data was "in-memory akka distributed data
extension"
On Tuesday, April 12, 2016 at 11:35:01 AM UTC+1, Guido Medina wrote:
>
> When shutting down your old actor, send its latest state to some
> distributed data, when loading the ac
When shutting down your old actor, send its latest state to some
distributed data, when loading the actor check the state at that
distributed data repository.
The tricky part is if messages are sent to the old actor after it got
poisoned, then you will have to drain its mailbox to your
Hi Benjamin,
I also rely on cluster events and AFAIK you can expect (and trust)
*MemberUp* and *MemberRemoved*, these IMHO are the only two consistent
states you can trust.
In other words, I register some actors only when their nodes reach
*MemberUp* and unregister only when their nodes reach
fore
>> we will not update to Netty 3. When we have a stable replacement the old
>> implementation will be removed.
>>
>> We are looking forward to working on this important area, and community
>> involvement is very much welcome.
>>
>> Cheers,
>> Patrik
Trying to emulate a read/write lock with actors can be very difficult,
maybe agents can do?
http://doc.akka.io/docs/akka/snapshot/java/agents.html
HTH,
Guido.
On Thursday, March 17, 2016 at 3:52:47 PM UTC, neel choudhury wrote:
>
> I want to implement the famous reader writer model using
101 - 200 of 327 matches
Mail list logo
