You could use Akka HTTP between clusters or cluster client from one cluster
to another,
but your messages will have to be something they both understand, like Json:
http://doc.akka.io/docs/akka/2.5.4/java/cluster-client.html
On Thursday, September 14, 2017 at 8:04:55 AM UTC+1, Kiran Sarma wrote:
That's why there is documentation in Java and Scala, here is the one for
Java:
http://doc.akka.io/docs/akka/2.5.4/java/cluster-client.html
On Tuesday, September 19, 2017 at 2:48:28 PM UTC+1, Kiran Sarma wrote:
>
> can we do cluster communication between two systems. i am trying to do but
> don't
Try the following, I have been using them for years since Java 7,
*G1GC* will behave better and be more predictable if *Xms = Xmx* and both
are at least *2g*,
but I have read that *G1GC* starts shining at *4g+* heap sizes:
-
- -server
- -XX:+UseG1GC
- -XX:MaxGCPauseMillis=100
- -X
It should be completely OK to use 2.4.19 if you can't upgrade to 2.5.x
On Saturday, July 22, 2017 at 9:43:05 PM UTC+1, Muthukumaran Kothandaraman
wrote:
>
> Tested with 2.4.7 (well, I am constrained to use that version). Works
> correctly as expected. Thanks
>
> Muthu
>
--
>> Read
The Gist example is actually a "bounded *logger* mailbox for Akka",
basically the Akka logger is an actor, with such config you are basically
replacing the mailbox of such logging actor for a bounded MPSC mailbox
queue.
On Wed, Jul 26, 2017 at 9:18 PM, Guido Medina wrote:
&g
I use high performance bounded queues in my Akka projects, I used to use
the ones from JCtools but I discovered that Agrona which Aeron depends on
(which Akka Artery depends on) have similar implementations, anyway,
linking stuff:
- *Agrona:*
https://github.com/real-logic/agrona/tree/ma
I'm not sure if you can "forward" instead of "route" to a router, if not
you could probably set the router sender to sender() and just reply to the
sender from the processing actor,
that way you won't need to correlate, it should be do-able using existing
sender() reply mechanism.
The trick wou
2nd option is usually the way to go and if it involves I/O operations
dispatcher of thread-pool type will behave better than a fork-join.
HTH,
Guido.
On Sunday, April 30, 2017 at 8:24:53 AM UTC+1, Thibault Meyer wrote:
>
> Hello,
>
>
> what is the best way to proceed with blocking operation ?
>
You might want to try Json Smile which is a Json binary, it is very
effective and can favor of re-using Jackson ObjectMapper
https://github.com/FasterXML/jackson-dataformats-binary/tree/master/smile
I also use Kryo for mainly Java classes where schema evolution and
compatibility is not important
We also have a expected list of seed nodes, and the rest can be dynamic, in
production you need at least 2 seed nodes to make restart of seed nodes
work,
like it has been said, you need 1 seed node alive while restarting others.
On Tuesday, April 4, 2017 at 2:38:18 AM UTC+1, Unmesh Joshi wrote:
A concrete example:
Imagining you are doing some accounting and your events are a Json
representing any particular operation:
1. {"op":"set", "value":0}
2. {"op":"add", "value":20}
3. {"op":"substract", "value":20}
Then when you reply the events your account total should be zero.
That
Hi Sergey,
I have micro-services that run as Java main and the passed command line
parameter is where my config file is located,
I also fallback to an internal config (static.conf) which is part of a jar
file, example below:
final Config config = ConfigFactory.parseFile(new File(args[0])).
with
Jun Ma,
I honestly don't know what kind of universe you live, Akka or any other
open source toolkit which are "free" have nothing to do with comunism,
and yes, I know about comunism because I lived the 1st 24 years of my life
in Cuba.
Free in the sense that you don't have to spend money, but is
-XX:+ParallelRefProcEnabled
On Sunday, February 26, 2017 at 12:42:22 PM UTC, Guido Medina wrote:
>
> Hi Klaus,
>
> I have another example for you, I have an application in production
> runni
Hi Klaus,
I have another example for you, I have an application in production running
among 15 JVMs, it is in Java 8 + Akka cluster (2.4.latest),
The project itself is a Maven project with modules, the following are
important aspects of my design:
- each module has a different role and is as
Hi Christian,
Another possibility is to use Vert.x for the HTTP (with or without
websockets) embedded with Akka if you find Akka Streams overwhelming which
is what I have done,
I have websockets via Vert.x and each socket connection creates an actor
which basically have a mailbox (a queue) wher
:
>
> On Wed, Dec 14, 2016 at 5:53 PM, Guido Medina > wrote:
>
>> *How to pre-load your products and their caches:*
>>
>> Initially you could iterate through your products and send a dummy
>> message to all, say a Boolean.TRUE,
>> a dummy and very small mes
Wednesday, December 14, 2016 at 11:36:38 PM UTC, Guido Medina wrote:
>
> I don't think he has millions of products, the 1m/sec was shown a
> theoretical high number otherwise he wouldn't be asking to preload all
> products at the beginning.
>
> On Wednesday, December
I don't think he has millions of products, the 1m/sec was shown a
theoretical high number otherwise he wouldn't be asking to preload all
products at the beginning.
On Wednesday, December 14, 2016 at 11:32:46 PM UTC, Justin du coeur wrote:
>
> On Wed, Dec 14, 2016 at 5:53
Ah, you need to share the Aeron driver among JVMs, don't start Aeron
embedded per system JVM as it will exponentially suck all your shared
memory,
to calculate how to tune Media Driver so that it can fit all your JVMs see
here:
https://github.com/akka/akka/issues/21923
HTH,
Guido.
On Wednesd
*How to pre-load your products and their caches:*
Initially you could iterate through your products and send a dummy message
to all, say a Boolean.TRUE,
a dummy and very small message which will allow you to send up to 1m/sec
That way each product will be started before the first query, each pro
WDYT? https://github.com/real-logic/Agrona/issues/82
On Mon, Dec 5, 2016 at 3:24 PM, Guido Medina wrote:
> Don't rethrow the InterruptedException to allow shutdown cycle to start if
> main is interrupted (a sort of SIGNAL)
> import sun.misc.Signal;
>
> import java.util.concu
rrier() {
Signal.handle(new Signal("INT"), (signal) -> signal());
}
public void signal() {
latch.countDown();
}
public void await() {
try {
latch.await();
} catch (InterruptedException ignored) {
}
}
}
On Monday, December 5, 2016 at 3:07:38 PM UTC,
reaches zero.
HTH,
Guido.
On Monday, December 5, 2016 at 3:00:51 PM UTC, Guido Medina wrote:
>
> I have created my own version where I can simply signal if I want to
> shutdown from another place instead of signalling the process, the
> following support both:
>
> imp
I have created my own version where I can simply signal if I want to
shutdown from another place instead of signalling the process, the
following support both:
import sun.misc.Signal;
import java.util.concurrent.CountDownLatch;
public class SignalBarrier {
final CountDownLatch latch = new C
w to scale using Akka toolkit.
>
> In your answer to my post, you are saying that instead to use a pool, I
> can also use remote actors if I have a cluster with several nodes ?
>
> Le dimanche 27 novembre 2016 22:52:44 UTC+1, Guido Medina a écrit :
>>
>> If you have on
26:16 PM UTC, Guido Medina wrote:
>
> Last method call in main thread, no other thread needed as it will block
> until SigTerm is received.
>
> On 28 Nov 2016 4:40 p.m., "Marek Żebrowski"
> wrote:
>
>> Guido, how exactly do you use registerShutdownHook(Ac
Last method call in main thread, no other thread needed as it will block
until SigTerm is received.
On 28 Nov 2016 4:40 p.m., "Marek Żebrowski"
wrote:
> Guido, how exactly do you use registerShutdownHook(ActorSystem system) ?
> Is it last call in application main()
> I tried to write something s
Hmmm, maybe suggest Aeron guys to add an option to disable shutdown hooks,
I know the same is possible for Log4j2 which is why my shutdown code
fragment does once Akka system has been terminated.
On Mon, Nov 28, 2016 at 11:05 AM, Patrik Nordwall wrote:
> Thanks. Please let us know how it goes. W
PriorityMailbox to the aid:
http://doc.akka.io/docs/akka/2.4.14/java/mailboxes.html#PriorityMailbox
HTH,
Guido.
On Sunday, November 27, 2016 at 10:00:44 PM UTC, adrian...@gmail.com wrote:
>
> I have heard a lot of good things about Akka. I have a stream of price ,
> and I need to create two movi
I had the same problem of members not leaving correctly, all because Aeron
uses a JVM shutdown hook so your application cannot use also a shutdown
hook,
I had to switch to a provided SIGTERM class which catches the Ctrl + C or
kill signal:
public static void registerShutdownHook(ActorSystem sy
If you have one actor per device why do you need a pool? I believe you are
trying to use many *-and well known good-* concepts together which might
over-complicate things,
You could simply use one actor per device which will hold its own state and
make it expire after some time being idle, such
Also, don't forget to verify that the MemberRemoved is you, see in the
following example I created for some other test:
https://gist.github.com/guidomedina/fffeaa10d1017cc528a6817f2c4941be
HTH,
Guido.
On Saturday, November 19, 2016 at 5:25:21 PM UTC, Guido Medina wrote:
>
> I have th
I have the following shutdown hook (plus what you have on that actor), it
is designed for Ctrl + C on a standalone JVM or kill , if running on a
webapp, you have to first call clusler.leave(cluster.selfAddress()) and
then system.terminate()
I was having an issue because my shutdown hook was a JV
A couple of years ago I was a newbie in Akka, by newbie I mean I didn't
know anything and I had to deliver a project in a new job:
*A distributed and high available trading system for a financial
institution.*
My concurrency and Riak knowledge background helped me to understand how
Akka works b
make them
implement Serializable.
HTH,
Guido.
On Friday, October 28, 2016 at 10:06:52 PM UTC+1, kraythe wrote:
>
> I am wondering if this would use the same bindings for all the default JDK
> types or if that would be another issue.
>
> On Monday, June 13, 2016 at 3:10:01 AM U
you please elaborate on this?
> If I were to just use AKKA for point-to-point communication between multi
> sites, would there be any problem there?
>
> On Wednesday, September 7, 2016 at 2:34:09 PM UTC+3, Guido Medina wrote:
>>
>> Short answer is no, no, no, you need to
Also, I believe that it should be consistent, I think Java fixed thread
pool factories will give you a thread pool that expire the threads after 1
minute being idle,
should be the same *-consistency-* for Akka?
On Monday, October 3, 2016 at 4:20:01 PM UTC+1, Guido Medina wrote:
>
> Lo
Look and learn about the configuration option:
1. thread-pool-executor.allow-core-timeout = off
I suspect that what's happening is that your only thread is dying and
another started when a new task is queued.
HTH,
Guido.
On Friday, September 30, 2016 at 9:29:42 AM UTC+1, Marek Żebrowski w
Hi Silvio,
The following are the only things I can recommend you:
- You have a short time to deliver? Why bother now with Artery if that's
the least of your problems? Your performance issue has nothing to do with
Akka Cluster or Akka Remote.
- Why use a future? Your future is probab
If you want to test Netty indirectly and have some reasonable API in the
middle try comparing with Vert.x 3.
That way you are not just comparing against Netty but against a framework
that is built on top of Netty,
has a promising HTTP API and is matured (also faster than NodeJS of course):
http:
th Docker, that is what i need.
>
> Thanks Silvio
>
> Il giorno mercoledì 7 settembre 2016 17:50:44 UTC+2, Guido Medina ha
> scritto:
>>
>> Artery is at in milestone 3 (m3), you are welcome to use as I believe it
>> is in an extremely good shape but I would pursu
classes?
If the latter then I believe it should also apply to automatic listed
classes to register.
Guido.
On Friday, September 9, 2016 at 8:36:54 PM UTC+1, Justin du coeur wrote:
>
> On Fri, Sep 9, 2016 at 2:51 PM, Guido Medina > wrote:
>
>> The problem with explicit is that
day, September 9, 2016 at 5:56:16 PM UTC+1, Justin du coeur wrote:
>
> On Fri, Sep 9, 2016 at 12:27 PM, Guido Medina > wrote:
>
>> Also, what ID strategy are you using? I see none configured so it it is
>> using the default, try setting it like I posted in the example whi
And newest Akka Kryo doesn't require pool-size as that's a
java.util.ConcurrentLinkedQueue by default.
I contributed that new mechanism to use ConcurrentLinkedQueue for the pool
or your own implementation (See KryoQueueBuilder example in their doc).
On Monday, September 5, 2016 at 10:22:28 AM UT
Also, what ID strategy are you using? I see none configured so it it is
using the default, try setting it like I posted in the example which is
"automatic"
On Friday, September 9, 2016 at 5:26:00 PM UTC+1, Guido Medina wrote:
>
> Are you sharing the same conf file? if you re
"com.test.common.LoginRequest" = 20
>>
>>
>> }
>>
>>
>> classes = [
>> "com.test.common.LoginRequest"
>>
>> ]
>> }
>>
>> #akka.actor.serialize-messages = on
>>
>> akka.act
are
> writing in Java and not in Scala)
> Thanks Guys,
> Silvio
>
> Il giorno mercoledì 7 settembre 2016 17:52:39 UTC+2, √ ha scritto:
>>
>> IMO Artery won't help much if using Java Serialization.
>> Java Serialization is notoriously slow.
>>
>> On
By induction you can conclude that messages order is guaranteed when
sending sequentially (in the same thread) by using the following assertions:
- Messages sent to any local actor go immediately to their destination
inbox hence order is preserved because of sequential execution - JMM rule
> What do you suggest to focus our efforts on?
> Which of this two arguments can effectively improve the system efficiency?
>
> - Passing from Remote to Artery?
> - Remove Java serializer and use another one?
>
> Thanks,
> Looking forward to hear you.
> Silvio
>
Short answer is no, no, no, you need to interconnect the DCs using some
recoverable mechanism otherwise your cluster will suffer.
In other words, don't form Akka clusters among multiple DCs.
HTH,
Guido.
On Wednesday, September 7, 2016 at 12:27:54 PM UTC+1, Guy Sela wrote:
>
> Hi,
>
> I saw this
nk of, maybe too simple for your study but
anyways, hope somehow it can lead you to what you need/want.
Guido.
On Wednesday, September 7, 2016 at 12:28:19 PM UTC+1, Guido Medina wrote:
>
> Hi Carmen,
>
> The following might not have a specific example but will probably help you
&g
Hi Carmen,
The following might not have a specific example but will probably help you
seeing in details the design concepts behind Akka combined with the Java
Memory Model,
most of the aspects you have mentioned are avoided but maybe there is a way
to reproduce one or two by contradicting the a
Messages can be slow when being sent remotely from node A to node B,
current Akka remote will give you a top of 100k msg/sec best scenario and
that depending on the message size,
there is a new Akka remote (Akka artery which is a rewrite of Akka remote)
on the way so that shouldn't discourage you
In the introduction chapter of Akka this is explained in details, how Akka
takes care of it,
I suggest you go there to learn the exact details:
http://doc.akka.io/docs/akka/2.4.10/general/message-delivery-reliability.html#Discussion__Message_Ordering
HTH,
Guido.
On Tuesday, September 6, 2016
Hi,
You can also try Akka Kryo serialization extension, it has proven to be
very efficient so far so you don't have to write your own serialization.
Kryo offers you automatic, manual (by you listing explicitly) registration
of the classes and both.
It is a very matured extension and its backed
*Solution 1:*
Akka persistence (the parent only) with sharding can solve that problem for
you, basically the parent actor will be re-instantiated somewhere else and
resume from its last state and replay any message that follows.
*Solution 2:*
I used a similar concept where a type of parent is
Hi Bert,
What Martynas mentioned is the key to have a successful rolling restart,
for production you need more than one seed node, I would even start my
rolling restart with the seed nodes,
it shouldn't make a difference but it will help the new started nodes not
to rejoin seed nodes.
There is
To be honest and fair, TLS configuration is a messy "Java" subject, it has
nothing to do with Akka so I believe you should search for Java TLS
configuration instead,
I know there is a JVM parameter where you indicate the current JVM which
keystore should use but I don't know any details on how t
*Copy & paste from the other thread*
Your nodes will re-join if you keep at least 1 seed node up while
restarting other nodes, try having 2 seed nodes.
In production don't ever relay on only 1 seed node, have at least 2.
HTH,
Guido.
On Friday, July 8, 2016 at 11:44:52 AM UTC+1, 谌浏洋 wrote:
You posted this question in another thread, please go there and look.
On Friday, July 8, 2016 at 11:44:52 AM UTC+1, 谌浏洋 wrote:
>
> Sorry for my poor English
>
> I started two node A(seed) B, Both A and B can communication to each other.
>
> When I restart node A. node B cannot join A anymore. (No
Your nodes will re-join if you keep at least 1 seed node up while
restarting other nodes, try having 2 seed nodes.
In production don't ever relay on only 1 seed node, have at least 2.
HTH,
Guido.
On Friday, July 8, 2016 at 12:37:49 PM UTC+1, Patrik Nordwall wrote:
>
> When you restart node A it
out
>> automatically registered classed, which is very helpful.
>>
>> I'm working on it.
>>
>> Thanks again for you patience.
>>
>> /Eduardo
>>
>> On Sun, Jul 3, 2016 at 11:53 PM, Guido Medina > > wrote:
>>
>>> Question
t
> com.esotericsoftware.kryo.serializers.CollectionSerializer.read(CollectionSerializer.java:96)
> at
> com.esotericsoftware.kryo.serializers.CollectionSerializer.read(CollectionSerializer.java:22)
> at com.esotericsoftware.kryo.Kryo.readObject(Kryo.java:682)
> at
> com.esotericsoftware.kryo.serializers.ObjectField.r
serializer with its Kryo plus other things.
You can see the relevant Akka Kryo code for the pool in this
commit/diff:
https://github.com/romix/akka-kryo-serialization/commit/045cd27dfd01c2c41ab7c64bf6e25a63b3fd8e42
Guido.
On Sunday, July 3, 2016 at 1:47:45 PM UTC+1, Guido Medina wrote:
>
> Kr
.
>
> Anyway, kryo will scale vertically, I suppose. Will kryo use more threads
> than I'm using right now?
>
> Thanks again for your help and knowledge.
>
> On Sun, Jul 3, 2016 at 2:13 PM, Guido Medina > wrote:
>
>> I meant to say *"anything that imple
ve place holders until you don't call resolve()
HTH,
Guido.
On Sunday, July 3, 2016 at 12:57:21 PM UTC+1, Guido Medina wrote:
>
> I have mimic-ed your configuration and corrected some errors, also added
> Kryo if you want to give it a chance with the configuration I believe wil
I have mimic-ed your configuration and corrected some errors, also added
Kryo if you want to give it a chance with the configuration I believe will
do best.
I default the "java" serializer to Kryo, that way, everything that inherits
"Serializable" will use Kryo, also, I list every class that I c
pool-size-factor = 1
pool-size-max = 8
}
}
}
On Saturday, July 2, 2016 at 12:31:12 PM UTC+1, Guido Medina wrote:
>
> Didn't read the serialization part, must be that I need my coffee, Kryo is
> very well optimized, you don't know if is going to help until you t
izing.
On Saturday, July 2, 2016 at 12:27:28 PM UTC+1, Guido Medina wrote:
>
> Try the following, these values work great,
> you can try higher but I don't think it is going to help because the most
> of the bottleneck is because of design,
> a problem related with how akka-remote
Try the following, these values work great,
you can try higher but I don't think it is going to help because the most
of the bottleneck is because of design,
a problem related with how akka-remote is designed around Netty, but that
will change soon: https://github.com/akka/akka-meta/issues/22
ak
e when
dealing with legacy code.
On Thursday, June 30, 2016 at 9:17:35 PM UTC+1, Guido Medina wrote:
>
> That depends on the supervisor strategy, funny thing that for one my
> clients with lots of legacy code I had to use a CompletableFuture because
> the framework I'm introduc
That depends on the supervisor strategy, funny thing that for one my
clients with lots of legacy code I had to use a CompletableFuture because
the framework I'm introducing there has no of ask or await.
And that's an idea you can use, send a Java's CompletableFuture to your
actor, and in such fu
confirmed that it is needed.
>
> Cheers,
> Patrik
>
> On Wed, Jun 29, 2016 at 11:50 PM, Guido Medina > wrote:
>
>> Even if the cost of creating new actors is low, there is still a cost,
>> its lifecycle for example has to be ran per actor creation,
>> a m
two types of "faster" and "cheaper" mailboxes for
worker's like actors, like:
https://gist.github.com/guidomedina/ddd729492c8fb8148032
That way my workers are always ready to process whatever.
Just my opinion though,
Guido.
On Wednesday, June 29, 2016 at 10:41:52 PM
*Correction:* is actors.size(), not value.size(), value came from the
original code which iterates over a Map, something else, which is my DDD
shard distributor:
On Wednesday, June 29, 2016 at 10:40:20 PM UTC+1, Guido Medina wrote:
>
> Here is how to create your Router programmat
Here is how to create your Router programmatically:
final List actors = ...
Router router = new Router(new RoundRobinRoutingLogic(),
actors.stream().map(ActorRefRoutee::new).
collect(toCollection(() -> new ArrayList<>(value.size(;
In this case I'm using RoundRobinRoutingLogic, yo
akka.routing.SmallestMailboxRoutingLogic
*Source:* http://doc.akka.io/docs/akka/2.4.7/java/routing.html
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives:
But it can be improved; instead of creating and destroying actors per
Future why not just create a pool of actors (or workers if you will),
the recommended amount of concurrent actors you want is usually a factor of
CPUs, say CPUs x N where N in [1..4], of course,
and if these actors use legacy c
Not to worry, everybody is happy now ;-)
On Tuesday, June 28, 2016 at 10:51:30 PM UTC+1, Gavin Baumanis wrote:
>
>
> Guido
>
> It isn't lost on me that this is the Akka mailing list. I too am here to
> learn about Akka.
>
> I take onboard everything you say. But it was only a suggestion of an
utions ?
>
>
> On Tuesday, June 28, 2016 at 10:30:38 AM UTC+2, Guido Medina wrote:
>>
>> There are community contributions that can poll messages from a JMS
>> queue, then you could send these messages to a worker actor,
>> such actor then can forward that message
to the dispatcher that it has top
> priority over any other thread in the application, that could 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,
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 would
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 following
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:
>
>
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
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 resolve
; 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
*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 behav
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 what
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 wa
un,
> do I have to recreate actor then kill then at the end of run?
>
> On Wednesday, June 15, 2016 at 12:00:57 PM UTC-5, Guido Medina wrote:
>>
>> Akka will do that in an orderly fashion
>>
>> On Wednesday, June 15, 2016 at 5:43:20 PM UTC+1, Yan Pei wrote:
>&
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
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
> Scheduler.
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.
>
> Thanks fo
:
>
>
>
> On Mon, Jun 13, 2016 at 8:53 AM, Guido Medina > 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:
>>
>
> That is *very* su
fehub/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
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 change the "java.io.Serializable" binding from "java" to "kryo",
> I'm not at home so
Yes, just change the "java.io.Serializable" binding from "java" to "kryo",
I'm not at home so can't look the exact key nor copy & paste my config
section for that.
That way any object that implements serializable will be serialize with
Kryo, objects that don't implement Serializable you will hav
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 07:
1 - 100 of 356 matches
Mail list logo
