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
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
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
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
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
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:
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 man
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:
>>
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:
>> http://doc.akka.
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]* wher
*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 nec
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 *a
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/
>>>
torService 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 wrote:
>
>> In fact, even more could be
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
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 t
I'm going to say like the Martiens in Sesame street, ohhh, ConductR, yep
yep yep.
Many many thanks, I'll dig into it.
Guido.
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>>
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 :
Also it is unlikely such thing will happen, my atomic integer will never
overflow because it goes back to zero.
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the ar
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 definit
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* whic
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
supervi
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 identity
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
Hi,
I have a method to create an account balance actor per currency for that
account, I had that on a hash map but I think that if Akka has an internal
hash map *-concurrent or not-* to keep actor references then why should I
keep yet another hash map?, I was using a computeIfAbsent(...) on my
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
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).
g
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 unl
Hi,
I like the mix between Java and Scala and sometimes even more inclined to
Scala idiom, assume that we will eventually move from Java 8 to Scala but
for now we are stuck with Java 8, using the following two examples:
// Method using Scala API
private void applyToAccount(Currency curren
I'm doing that from Java by calling the Scala API's, like this:
context().system().settings().config()
--
>> Read the docs: http://akka.io/docs/
>> Check the FAQ:
>> http://doc.akka.io/docs/akka/current/additional/faq.html
>> Search the archives: h
You might want to pick the right tool, Akka is a process one message at a
time with low latency-ish while other products are more appropriate for
batching, there are other posts about this but this one gives you a good
idea of what I'm saying:
http://stackoverflow.com/questions/29088754/apache-
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 sa
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
S
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 c
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/grou
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 philo
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 h
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
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
>>
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 rou
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
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:
>> http://doc.akka.io/docs/
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:
>
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:* http://doc.akka.io/docs/akka/2.3.11/ge
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/
>>
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, e
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
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 bee
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 t
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 questions:
t to
do,
which is why my 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
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") {
@Ove
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 co
wards 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 meth
ching on Akka remote but looks like 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 FixIniti
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://group
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.
--
: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/
>>>>>>>>>>
lAddress))
>>
>> }
>>
>> @throws[Exception](classOf[Exception])
>> override def preStart(): Unit = {
>> import context.system
>> val manager = IO(Tcp)
>> manager ! Bind(self, new InetSocketAddress(9000))
>> super.preStart()
>> }
>> }
&g
w when to do a
> flush,and you have to using a tick to do
> 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
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 u
, or you can still use the old sbt-idea 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 > > wrote:
>>
>>> I modified the
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:
ck
> out https://github.com/hseeberger/reactive-flows/. Heiko has done an
> stellar job of assembling all the best widgets for a clustered app with
> Akka-HTTP, including showing how to test with it. I've been banging on it
> to try to make the app more modular and in line with
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.
yway.
> Are you able to split pom.xml in more than one file now? I like to have
> small, organized files for the build as well, I wouldn't use maven even
> only for the huge spammy-xml-ish pom files. I like the idea that the build
> is a project itself and not just a descriptor
> maven currently does 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
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 c
as well. So I can't 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
ve Akka would help me to handle the game entity states in a
> very simple 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,
gt; max) what about keeping all actors in memory? It will make everything
> 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
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' superv
riday, 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
ight? Then we need 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-
r B. First we need to find out the
>> player B zone (to find it's supervisor). Right? Then we need 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
that
> the player may have been moved 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 p
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
> Anyway, thanks a lot Guido for your kind 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
I do agree with Luis, but I wasn't pushing much that approach because AFAIK
you are new to Akka and you have only one server, the concept of sharding
and Akka persistence can be overwhelming at first, but if you read between
the lines, the hash code approach I proposed initially is the skeleton
Hi,
I have an scenario where all messages come to a single main actor and such
actor in my previous version was processing each message in a Future,
realistically speaking I wouldn't expect to be processing more than CPUs
messages concurrently, but I need the main actor to dispatch such message
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 sing
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
Basically I think what I really need is an implementation/example of Akka
HTTP/Streams server sent events to the web socket client in Java, the rest
should be easy to implement, any pointers will be of a great help I much
need.
On Thursday, August 6, 2015 at 11:39:34 AM UTC+1, Guido Medina
e in another example
> <https://github.com/jrudolph/akka-http-scala-js-websocket-chat/blob/bc807a7c27e52f75179c19fdedcafc7ebb864e3a/backend/src/main/scala/example/akkawschat/Chat.scala#L55>
> that
> actually does use websockets to send events both ways.
>
> Regards,
>
> Rol
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 2
eat-pause
>
> /Patrik
>
> On Fri, Aug 21, 2015 at 11:29 AM, Guido Medina > 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 m
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 second
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 problem
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,
>
>
> W
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
clu
of migration 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'
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 > wrote:
>
>> Very nice, I wasn't aware of it, IMHO it ne
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 > wrote:
>
>> Hi Viktor,
>>
>> Maybe you could abstract the transport API and
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 TCP ser
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
beca
d them) 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
>
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 = ${engine.cluster
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 but be
1 - 100 of 356 matches
Mail list logo
