For Tomcat 7 and up it is very easy with Servlet 3.0 specification,
basically you create create a listener and annotate it, then just add your
shutdown code in the context destroyed method:
Explained with one example
here: http://www.codejava.net/java-ee/servlet/weblistener-annotation-examples
Yeah, in Akka Cluster-Sharding you also have regions which I think you can
use to broadcast messages to actors living in such region, a region will
likely be spread between distinct nodes.
I use Akka Cluster roles because I have an admin node that keeps track of
each supervisor's actor and a
No so automated but I do this with specific supervisor actors that are
subscribed to cluster events.
So I have broadcast routers that are kept updated, so when some event happens I
just use the router.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
Cluster node has roles, and cluster events can keep your broadcast routers
updated, so you could broadcast a message to a role.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives:
But you need to read at least the first 3 parts of Java General
documentation *-there is a Scala counterpart of course-*, since the answers
are clearly there:
- *Introduction:*
http://doc.akka.io/docs/akka/2.3.11/intro/index-java.html
- *General:*
Like you would reference any other singleton instance, as a static variable
for example, ActorSystem is a heavy object so it is recommended to have
just one per JVM anyway.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
The documentation clearly says that ActorSystem is a heavy object and that
should be treated as a Singleton instance per JVM, you can have as many
dispatchers as you need to cover specialized tasks.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
I'm building a FX trading OMS and I have signals, strategies, accounts and
orders, they all run on a different JVM and each have a distribution type
like SINGLETON, SHARDED or ROUND_ROBIN, they communicate with each other
because they are part of the Akka cluster, so each has a separate Actor
Hi,
I have the following method which creates a FixInitiator which is part of
another multi-threaded framework I have no control, the client is started
inside an actor which its children are named and located by a generated
UUID.
I have read that passing the context to another thread is not
Is this a duplicate? I have spent sometime answering your other thread
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this
Some clarification on my previous posts:
- *Akka cluster:* My cluster events was a typo, I meant that I use
Akka cluster and each microservice is subscribed to the cluster events so
every time one actor system comes up, it knows about the other actor
systems and a handshake with
No, I have a single cluster, each micro-service is an Akka system that is
subscribed to cluster events and once a system is up, it sends a message to
every other node saying, hey, I'm here, lets exchange information, call it,
synchronizing their cache.
Risky?, Akka follow the let-it-crash
I don't have an answer nor time to respond to a blog comparison, but if you
google Akka vs Quasar you will find plenty of opinions and depending on
what you want or need to hear you will make your decision, now, in a
nutshell:
*Typesafe is a great, innovative and more matured company which
If you are starting Spring within Tomcat I would recommend you to have the
Spring programmatic-ally created and instantiated via @WebListener, then
create your @Bean method returning your singleton ActorSystem, within your
method you can tweak aspects like configuration, where to load it from,
The class loader effect, precedence, naming and how to load a custom
configuration is very well explained at the end of the Akka documentation
general section:
http://doc.akka.io/docs/akka/2.3.11/general/configuration.html
HTH
--
Read the docs: http://akka.io/docs/
Check the FAQ:
A better example:
@Configuration
public class SpringWebAppInitializer implements WebApplicationInitializer {
// Ugly but you don't have many options here, maybe a volatile?
// Just make sure you don't use this context before it is initialized,
// timing will be an issue, I have
Pay attention to the WebListener class and @Configuration annotation, my
recommendation would be to use both on the same class, create a static
spring context which is the one you will use later to locate the spring
beans including the ActorSystem which will have a signature like:
@Bean
public
Hi,
I have been using Akka now for three months now and one thing that got my
attention in a very good way is the fact that you can use Scala methods and
functions from Java, then I wonder:
- Is it really necessary to have an Akka Java API for Java developers in
general?
- I have not
You can set context time out for actors, if they don't receive a message
within some time passivate them, activate them at login, that way you don't
have to lazy load when the player is active but at login which will
basically happen asynchronously.
Now, Akka experts should tell us if setting
Assume the following is the default mailbox:
akka.actor.default-mailbox.mailbox-type =
akka.dispatch.SingleConsumerOnlyUnboundedMailbox
On Thursday, June 25, 2015 at 2:20:01 PM UTC+1, Guido Medina wrote:
Hi,
I have an scenario where all messages come to a single main actor
activate
them just at login times.
On Thursday, June 18, 2015 at 3:55:03 PM UTC+4:30, Guido Medina wrote:
You can set context time out for actors, if they don't receive a message
within some time passivate them, activate them at login, that way you don't
have to lazy load when the player
and concise way. But it introduces new concerns about RAM
usage. It can be handled with the help of Akka persistence and supervisors
although it's not as simple as I thought.
On 06/19/2015 11:40 AM, Guido Medina wrote:
You can activate an actor if not present, as long as you send
advices.
On 06/19/2015 05:19 PM, Guido Medina wrote:
And don't worry about performance, assuming each shard has a pattern of
Single Consumer - Multiple Producer, make sure the inbox type for shards
and players is SingleConsumerOnlyMailbox which is a the fastest Akka
mailbox atm
, June 19, 2015 at 12:27:39 PM UTC+1, Guido Medina wrote:
You could even have the concept of lazily load the zone and each zone
lazily load the players.
On Friday, June 19, 2015 at 12:25:47 PM UTC+1, Guido Medina wrote:
50K is like zero for current and modern hardware, so, I would say, load
to another zone in the middle of the finding
process :(
It seems like the cellular mobile network. How can they find the BTS to
which my phone is connected?
On 06/19/2015 04:31 PM, Guido Medina wrote:
Do you have player IDs? design your application to have zones divided by a
number
And don't worry about performance, assuming each shard has a pattern of
Single Consumer - Multiple Producer, make sure the inbox type for shards
and players is SingleConsumerOnlyMailbox which is a the fastest Akka
mailbox atm.
On Friday, June 19, 2015 at 1:43:46 PM UTC+1, Guido Medina wrote
easier and faster.
On 06/19/2015 03:05 PM, Guido Medina wrote:
Say you don't have zones or any sort of grouping, you need at least one
supervisor, I wouldn't recommend you to make all your players top level
actors where their parent is /user, you need a fast way to locate a
player and context
an actor which
knows about the players zone. That would be the bottleneck again.
On 06/19/2015 04:00 PM, Guido Medina wrote:
Nvm, that would run into the same problem, instead, eagerly load the
player's zone -a supervisor for a bunch of players- and then lazily load
the player per zone
You could even have the concept of lazily load the zone and each zone
lazily load the players.
On Friday, June 19, 2015 at 12:25:47 PM UTC+1, Guido Medina wrote:
50K is like zero for current and modern hardware, so, I would say, load
them lazily from your players' supervisor and don't expire
knows about the players zone. That would be the bottleneck again.
On 06/19/2015 04:00 PM, Guido Medina wrote:
Nvm, that would run into the same problem, instead, eagerly load the
player's zone -a supervisor for a bunch of players- and then lazily load
the player per zone, that will keep
Did you shutdown ActorSystem at some post context destroyed class? You can
add that to the same class of the previous question but just shutting down
spring context and at the @Bean annotation state what shutdown method
ActorSystem uses:
@Bean(destroyMethod=shutdown)
--
Read the docs:
Yeah, I'm helping you because I have been in your shoes where legacy code
cannot be just deleted, I'll guess you are the new guy that can't change
things drastically...
The problem you are facing is complex and simple at the same time, you have
Tomcat as container and Spring as DI so
:03:42 PM UTC+1, Guido Medina wrote:
Hi,
Just wondering what are the ETAs on Akka 2.4-M2, RCs and final?
Best regards,
Guido.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https
On Monday, June 15, 2015 at 1:57:23 PM UTC+1, Carsten Saathoff wrote:
Am Samstag, 6. Juni 2015 00:24:16 UTC+2 schrieb Guido Medina:
No, I have a single cluster, each micro-service is an Akka system that is
subscribed to cluster events and once a system is up, it sends a message to
every
the flush or trigger a flush every time you do write akk writeAndFlush.And
the current SPI is a little complicate too.
在 2015年6月15日星期一 UTC+8下午6:51:06，Guido Medina写道：
Hi Hepin,
Thanks for your response, what does that mean exactly?
Is it your extension going a workaround for Akka remote
to test with it. I've been banging on it
to try to make the app more modular and in line with DDD patterns since
it's already CQRS/ES friendly. If you get some free time, check it out!
best, Brian
On Jun 16, 2015, at 1:14 PM, Guido Medina oxy...@gmail.com javascript:
wrote:
Hi
Nice, you know projects from time to time deprecate things out, depending
on how things play out and time surely it will be worth to take a look at
new/easier ways to do things, for me it was a hell of a journey because I
had to learn Akka in 3 weeks with spoonful of salt and steroids included.
and for going off topic...!
On another note: is there anyone in this group who works in Singapore? If
there is, can you contact me? thanks
On Tuesday, 16 June 2015 22:14:53 UTC+2, Guido Medina wrote:
Hi,
This is not exactly a question, more like a discussion and sharing some
of my
Hi,
This is not exactly a question, more like a discussion and sharing some of
my experiences lately, most of it for medium+ size companies might not make
much sense but for overloaded small teams with one or two developers doing
everything, here is my *-as short as I can describe it-* story:
Scala rather
than old Java style.
Best regards,
Guido.
On Saturday, June 6, 2015 at 7:41:09 PM UTC+1, Guido Medina wrote:
Hi,
I have been using Akka now for three months now and one thing that got my
attention in a very good way is the fact that you can use Scala methods and
functions from
not support scalajs
On Tuesday, June 16, 2015 at 11:14:53 PM UTC+3, Guido Medina wrote:
Hi,
This is not exactly a question, more like a discussion and sharing some
of my experiences lately, most of it for medium+ size companies might not
make much sense but for overloaded small teams
nobody has
gotten it right or it is an ultra secret not shared anywhere, tips are
welcome.
Best regards,
Guido.
On Friday, June 5, 2015 at 6:28:39 PM UTC+1, Guido Medina wrote:
Hi,
I have the following method which creates a FixInitiator which is part of
another multi-threaded framework I
Hi,
Just wondering what are the ETAs on Akka 2.4-M2, RCs and final?
Best regards,
Guido.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You
Also, I would like to know what's the status of the new Akka remote using
Akka I/O, I was trying to use the Netty 4 implementation from Hepin:
https://github.com/hepin1989/akka-remote-transport-netty4
But I just realized it was deprecated in favor of the new Akka I/O.
Best regards,
Guido.
--
plugin to make a
project that IDEA can read (that is what I use now until they fix the
import).
-Endre
On Mon, Jun 1, 2015 at 12:54 PM, Guido Medina oxy...@gmail.com
javascript: wrote:
I modified the original to be correct, theoretically when your
AtomicLong reaches the *Long.MAX_VALUE* + 1
In fact, I think my implementation should not only be faster but it is also
safer due to the *-unlikely event?-* of reaching Long.MAX_VALUE, a side by
side comparison:
- Both implementations compare and set the value atomically, but mine
does it for an *AtomicInteger vs AtomicLong* which
One approach I use after watching Akka days videos, was to just create
small dispatchers for different types of tasks, say you have a set of
actors that persist to a relational database, create these actors on your
persistor-dispatcher for example, another example, say you have a single
Following up on my previous post, say there is a careful thread management
which interrupts a long running task, I have been there...if you are
interrupting something you coded, then probably you will refactor your code
so that it doesn't need to be interrupted which leads to another scenario,
Another approach that may as well deal with accidental issues, is to avoid
awaiting on messages, this is how I do, and again, it is working like a
charm, say you have the following scenario:
- Actor A running on persistor-dispatcher needs to insert a record on
the DB and send the
Will do that ;-)
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you are subscribed to the Google Groups Akka
Many thanks, that Optional pattern will come very handy to me.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
---
You received this message because
Is there any way to avoid the verbosity?, I try with a more functional
approach which was OK for IntelliJ but not for the Java 8 compiler, here is
the form that is working:
private void applyToAccount(Currency currency, BalanceOperation operation)
{
context().child(currency.code).
I modified the original to be correct, theoretically when your AtomicLong
reaches the *Long.MAX_VALUE* + 1 it will shift to *Long.MIN_VALUE* making
the mod (%) function return negative which will make the application fail
due to invalid list index *-list.get(neg_index)-*
In practice that is
I probably confused the readers with my long explanation so I'll ask the
question straight forward: If I have a cluster with one seed node, how do I
make the cluster reconnect to that seed node if I restart it? Is there any
resilient configuration I'm not aware of that can make the other nodes
Hi,
I have my own version of a RoundRobinRouting logic which I believe it is
faster and less CPU intensive due to no mod math operation, here is my
version in Java 8, it has though one small error because NoRoutee instance
if private and I don't know much Scala, so here it is a copy/proposal :
There is one thing to clarify and two differences:
- There are no locks in atomic operations, remember atomic operations
are based on CAS.
- Incrementing an *AtomicInteger* will definitely be cheaper than
incrementing an *AtomicLong.*
- Comparing the value and returning is
actors are using SingleConsumerOnlyMailbox.
On Friday, June 5, 2015 at 6:28:39 PM UTC+1, Guido Medina wrote:
Hi,
I have the following method which creates a FixInitiator which is part of
another multi-threaded framework I have no control, the client is started
inside an actor which its
What I meant if, would the incorrect use be kind of worked around if I do
this instead?, Notice also I remove the unhandled call.
@Override
public void preStart() throws Exception {
final ActorContext context = context();
initiator = new FixInitiator(entity, log, order) {
Hi Dr. Roland,
Sorry for being annoying over here :D
In Akka 2.3.11 self() for example is context.self() and context below,
doesn't that make self() also dangerous to be send to another thread
outside Akka?
It looks to me that these chances are also valid for self(), isn't all
about calling
Excellent news,
But I couldn't find the HTTP guide for Java, ETA?, unfortunately our
project is using Akka/Java 8.
We are waiting on it to use right away :D
Best regards,
Guido.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
Hi Shawn,
You need to handle such actors like a state machine, initial state will just
stash incoming messages and when its ready unstash all messages, for that Akka
has UntypedActorWithStah
HTH,
Guido.
--
Read the docs: http://akka.io/docs/
Check the FAQ:
Dear Hakkers,
I have a system with micro-services and my custom cluster shard
implementation *-a long story not to be told for now, glad to share my
approach later-*, so I have N roles in the cluster and each role with one
of the following types: *[singleton, evenly distributed, balanced]*
Hi Igor,
I have modified your initial implementation because on my tests it was
blocking the Akka system at shutdown so I simplified it for
SingleConsumerOnlyBoundedMailbox, look at the Akka git hub ticket and at my
forked branch:
https://github.com/akka/akka/issues/17558
Best regards and
*Quick question:* If my default mailbox is a
*SingleConsumerOnlyUnboundedMailbox* and my dispatcher a *PinnedDispatcher*,
does the thread pool *-in this case a single thread-* de-queue tasks from
it or is it there an intermediary Java blocking queue?
I'm assuming dispatchers in Akka are not
Sorry I mixed oranges with apples here, I just looked deeper the code and
no, my assumptions are *not* correct, the mailbox is one thing but the
task-queue is a different story, it would be nice at the
ThreadPoolExecutorConfigurator Scala class to have an option for single
thread dispatchers
is that the ExecutorService for the Dispatcher is pluggable
so you can provide your own, optimized version.
Would love to hear how much of a difference it could make (JMH bench would
be superb).
On Tue, May 26, 2015 at 6:35 PM, Guido Medina oxyg...@gmail.com wrote:
In fact, even more could be done here, I'm
Sorry I replied directly to you, my mistake, pasting message here:
It would only require a quick dirty hack, but I'm still in the process of
learning/developing a new project using Akka/Java 8 on a new job so time is
not much on my side *-you know, the first 6 months of every new job-*
There
In fact, even more could be done here, I'm assuming there is a reason why
mailboxes in general are not just blocking queues from Java, designers'
decision to provide a faster queue, so, why not reuse the same logic for
dispatchers?
--
Read the docs: http://akka.io/docs/
Check the
And more information about the application itself to see memory usage
patterns.
On Monday, August 24, 2015 at 4:22:10 PM UTC+1, Guido Medina wrote:
Hi Patrik,
I'm quite sure his problem has anything to do with Akka but lack of proper
JVM parameters, that 32 seconds pause shown in his logs
at 11:29 AM, Guido Medina oxy...@gmail.com
javascript: wrote:
Try the JVM option -XX:+UseG1GC, assuming you are using at least JVM
7uLatest where latest should be 79 or 80. The new GC algorithm doesn't stop
world, it works more often and can make your application a bit slower (on a
very
Try the JVM option -XX:+UseG1GC, assuming you are using at least JVM
7uLatest where latest should be 79 or 80. The new GC algorithm doesn't stop
world, it works more often and can make your application a bit slower (on a
very hyper micro-level) but GC will now be consistent.
On Friday, August
Hi,
I'm trying to implement the following workflow or checking if there is an
example (preferably in Java) somewhere:
1. Connect via web-socket, authenticate and receive a session ID
identifier.
2. Using that session ID an actor is created which will handle all
subsequent requests
I tried using withFallback(...) which has different semantics and behavior,
I need something that emulates include programmatically.
On Thursday, October 29, 2015 at 2:31:59 PM UTC, Guido Medina wrote:
>
> Hi,
>
> I have the following configuration which works fine bu
Hi,
I have the following configuration which works fine but because we are
externalizing so that IT admins have full control of it, we need to be able
to mimic the *include "common"* section programmatically, here is the
configution:
include "common"
engine {
cluster.name =
gFactory.load?
>
> On Thu, Oct 29, 2015 at 5:03 PM, Guido Medina <oxy...@gmail.com
> > wrote:
>
>> I tried using withFallback(...) which has different semantics and
>> behavior, I need something that emulates include programmatically.
>>
>>
>> On Thurs
rall I might end up serializing actorPath for actors in the same jvm -
> if the actor is inactive for a long time. This means actors might come and
> go quite frequently even if the servers are up.
>
> What happens to your cache if a server crashes? Do the cache removes the
> invalid
I have actors such like *AccountProcessor* and *AccountPersistor*,
AccountPersistor is a child of AccountProcessor and at its creation I pass
a different dispatcher, assuming your code is in Scala here is better
explained:
http://doc.akka.io/docs/akka/snapshot/scala/dispatchers.html
HTH,
;
-- removed company imports;
/**
* @author Guido Medina, created on 17/03/15.
*/
public abstract class SupervisorAbstractActor<
K extends Serializable,
T extends GenericEntity<K, T>,
S extends SupervisorAbstractActor<K, T, S, C>,
C extends ChildAbstractActor<K,
ou try to load, it will resolve, don't load, parse
with all fallback you need and then finally resolve()
final Config config = ConfigFactory.parseFile(new File(args[0])).
withFallback(ConfigFactory.parseResources("static.conf")).resolve();
Thanks for the ideas,
Guido.
On Thursday, O
I think you are looking at it from a very simplistic perspective without
taking into account many details that happen behind the scene, people tend
to use concurrent execution wrong where at the end of the day you still
have a finite set of processors -and small amount- so concurrent IMHO or at
The analogy of the JMM for Akka is also very interesting, it is an
important aspect of Akka to be aware
of http://doc.akka.io/docs/akka/2.4.0/general/jmm.html
On Monday, November 9, 2015 at 9:02:08 PM UTC, Stuart Reynolds wrote:
>
> In a highly concurrent system, it seems to me that the major
Hi Kostas,
I have few micro-services and some supervisor actors which inherited from
an AbstractSupervisor template which uses local caches per microservices
with an optimistic approach, example with requirements:
1) There is a uniform pattern where each micro-service is an independent
ion.
Best regards,
Guido.
On Wednesday, October 14, 2015 at 1:49:04 PM UTC+1, √ wrote:
>
> For extremely low latency we'd want to use a transport like Aeron.
>
> On Wed, Oct 14, 2015 at 1:34 PM, Guido Medina <oxy...@gmail.com
> > wrote:
>
>> Very nice, I wasn't a
sday, October 15, 2015 at 10:21:39 AM UTC+1, √ wrote:
>
> Hi Guido,
>
> Would you be interested in contributing towards this?
>
> On Thu, Oct 15, 2015 at 11:02 AM, Guido Medina <oxy...@gmail.com
> > wrote:
>
>> Hi Viktor,
>>
>> Maybe you could abstrac
Git URL
correction: https://github.com/hepin1989/akka-remote-transport-netty4
On Thursday, October 15, 2015 at 10:54:46 AM UTC+1, Guido Medina wrote:
>
> If that was my expertise I would at definitely done something already, but
> the only thing I have done with Netty is a T
Hi,
I created a similar post some time ago but the circumstances were a bit
different, the project I'm working at the moment has the requirement of
processing messages within 5ms, and I chose Akka remote to do this job, the
project also requires to be distributed so again, Akka remote with
n to streams. It already depends on
> Netty 4.
>
> On Wednesday, October 14, 2015 at 12:22:33 PM UTC+3, Guido Medina wrote:
>>
>> Hi,
>>
>> I created a similar post some time ago but the circumstances were a bit
>> different, the project I'm working at the mo
If I have to give up on Akka remote because it is slow, I'll just switch to
something like Vert.x, not sure what's going on here or why it has such
little importance when it is part of Akka selling speech: "Location
transparency" or is it only an advertisement but not used much in practice
m) or to research
> QUIC—but a pure UDP transport would also be interesting to explore in order
> to see which “connection-like” features we really need (which I guess to be
> extremely little).
>
> This is surely not satisfying in the short term but as other people say: I
&g
Hi Patrik,
That's great news, does the TCP no delay affect remote performance in
anyway? If so is that change reflected at 2.4-RC1 or is it coming in the
next 2.4 release?
Best regards,
Guido.
On Thursday, September 3, 2015 at 2:04:20 PM UTC+1, Patrik Nordwall wrote:
>
> Dear hAkkers,
>
>
>
Hi Robert,
The problem with old Java domain objects IMHO is how to properly guard
their state, for example, you might think of solutions like Loading caches
using Guava or any other caching framework but that still doesn't free you
from mutability problems, caching is one of the hardest
AFAIK nope, Akka micro kernel was deprecated, I think Akka completely moved
to a "toolkit/framework" approach, I have a system running micro-services
with some shared generic actors and a single configuration with seed nodes,
all using the good old Java main method per micro-service, each
*ConductR* is where we will be heading too in the future, when our project
get to a 2nd or 3rd major version, as I'm the only developer it is too
difficult for me to do everything and now would only be a hassle, but yes
that's where I would like to go.
On Wednesday, December 9, 2015 at 1:44:34
Or CRDT with any distributed data structure, I can mention a couple: Hazelcast,
Riak, etc
Basically you want a distributed counter.
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
I will need distributed data for my project in the future so it was good you
mentioned it cause I didn't know akka had it.
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>
Replacing anything that is using java
> serialization is good.
> lör 19 dec. 2015 kl. 17:12 skrev Guido Medina <oxy...@gmail.com
> >:
>
>> Hi, not with the intention of hijacking this thread but here is a
>> question related question:
>>
>> If I decid
Hi, not with the intention of hijacking this thread but here is a question
related question:
If I decide to use only Kryo for all sort of serializations, has anyone
done this? I mean to also serialize Akka inter-node messages with Kryo?
*This is what I had before:*
serializers {
java =
Sorry for brevity writing from phone which I hate.
In a nutshell I would like your plugin akka-log4j to offer an extra class to
log directly without an actor in between which is your current implementation,
same applies for akka-slf4j.
That way Akka system has a registered logger and my actors
I was planning to have Hazelcast start/stop with each ActorSystem
programmatically, Hazelcast API is as friendly as akka's
But again if akka has its own in-memory grid then no need, also think if you
only need a counter or other things from a toolkit like Hazelcast and if the
things you will
Why not Akka Kryo?
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives: https://groups.google.com/group/akka-user
---
You received this message because you
1 - 100 of 327 matches
Mail list logo
