Re: [akka-user] Akka remote communication roadmap?

Great news ! >From my experience current remoting ( cluster that depends on it) is way to fragile to be used in boxes that are not in the same data center, and in such case of co-location UDP is perfectly fine. I expect that people trying to deploy in any "enterprise" or "coroprate"

Re: [akka-user] Akka remote communication roadmap?

Hi Patrik, Good morning news, I think a light framework like Aeron will be most welcome, UDP shouldn't be a problem as long as (as you mentioned) reliable delivery can be implemented/configured on top. About Netty 3 I don't understand what you are saying, akka-remote is already based on Netty

Re: [akka-user] Akka remote communication roadmap?

Nope. We just drop out-of-order messages. There will be no reliable delivery (except system messages). But even if we need to add it, it is not hard to implement. -Endre On Fri, Mar 18, 2016 at 11:21 AM, Guido Medina wrote: > Message ordering would be challenging to

Re: [akka-user] Akka remote communication roadmap?

Hi all, A quick update of the roadmap for Akka Remoting. Lightbend's core Akka team will be able to start working on a new implementation for Akka Remoting next sprint, which starts April 4. We will then start with describing the goals and overall design ideas and share with you. We are

Re: [akka-user] Akka remote communication roadmap?

On Fri, Mar 18, 2016 at 11:14 AM, Guido Medina wrote: > Hi Patrik, > > Good morning news, I think a light framework like Aeron will be most > welcome, UDP shouldn't be a problem as long as (as you mentioned) reliable > delivery can be implemented/configured on top. > About

Re: [akka-user] Akka remote communication roadmap?

Hi Patrick, what is the advantage of the UPD over TCP if we have to develop the order and delivery reliability on top of that? The only scenario I see is the multicast, is it needed for akka-remoting? Cheers On 18 March 2016 at 09:46, Patrik Nordwall wrote: > Hi

Re: [akka-user] Akka remote communication roadmap?

@Filippo, I haven't watched it but it looks interesting: http://www.infoq.com/presentations/aeron-messaging Cheers, Guido. On Friday, March 18, 2016 at 10:09:06 AM UTC, Filippo De Luca wrote: > > Hi Patrick, what is the advantage of the UPD over TCP if we have to > develop the order and

Re: [akka-user] Akka remote communication roadmap?

On Fri, Mar 18, 2016 at 11:09 AM, Filippo De Luca wrote: > Hi Patrick, what is the advantage of the UPD over TCP if we have to > develop the order and delivery reliability on top of that? > There are probably several performance reasons, but also the connection lifecycle

Re: [akka-user] Akka remote communication roadmap?

Make sense, Akka is at-most-one delivery guarantee. Good news On 18 March 2016 at 10:26, Patrik Nordwall wrote: > > > On Fri, Mar 18, 2016 at 11:14 AM, Guido Medina wrote: > >> Hi Patrik, >> >> Good morning news, I think a light framework like

Re: [akka-user] Akka remote communication roadmap?

Message ordering would be challenging to implement with UDP right? On Friday, March 18, 2016 at 10:20:19 AM UTC, Patrik Nordwall wrote: > > > > On Fri, Mar 18, 2016 at 11:09 AM, Filippo De Luca > wrote: > >> Hi Patrick, what is the advantage of the UPD over TCP if we

Re: [akka-user] Akka remote communication roadmap?

In the meantime I can't stay idle so I started digging inside Netty 3 and at the moment I'm using my own Netty 3.10.6.Final (Not release yet) which replaces the Netty internal CHM (Was the one from JDK 5) There is a PR which most likely will be on 3.10.6.Final so be watching, I didn't bother to

Re: [akka-user] Akka remote communication roadmap?

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

Re: [akka-user] Akka remote communication roadmap?

I hope we can get finally remoting up on our table again in our new roadmap (to be decided next week). Stay tuned. -Endre On Sun, Feb 21, 2016 at 4:53 PM, Guido Medina wrote: > Now on another I'll be one of the users that will appreciate a lot your > effort as I completely

Re: [akka-user] Akka remote communication roadmap?

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

Re: [akka-user] Akka remote communication roadmap?

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 > >

Re: [akka-user] Akka remote communication roadmap?

After adding framing to https://github.com/marekzebrowski/akka-remote-io it seems to work fine - echo server started to respond to all messages properly. There is still lots of work to do (error handling, configurability, udp support, proper dispatchers usage), but probably not that far away

Re: [akka-user] Akka remote communication roadmap?

I see my error - I just write payload, without any framing - I need to adjust protocol to match netty implementation. -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >>

Re: [akka-user] Akka remote communication roadmap?

Hi Marek,​ It seems a good starting point for a huge community contribution​. Good stuff On 20 February 2016 at 19:53, Marek Żebrowski wrote: > I wondered how hard could it be to write akka-remote transport using > akka.io only. > It turned out that it is not that

Re: [akka-user] Akka remote communication roadmap?

I wondered how hard could it be to write akka-remote transport using akka.io only. It turned out that it is not that hard to start: https://github.com/marekzebrowski/akka-remote-io roughly ~ 200 lines for proof of concept tcp implementation probably I'm doing something wrong as simple test

Re: [akka-user] Akka remote communication roadmap?

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

Re: [akka-user] Akka remote communication roadmap?

Hi Endre, Yeah, I understand, I posted the article because of what it states, it seems that Netty 3 didn't use any of the nice features of Java NIO making it inefficient to a point so there is a noticeable difference between the two *-according to the article-* > Was it worthwhile to make

Re: [akka-user] Akka remote communication roadmap?

Hi Guido, This is one of the backlog tickets that I hope to work on at some point. One one hand, the situation has not changed much, this is still not planned in the near future. On the other hand, streams is finally moving into master and 2.4, therefore we have the foundation that we can use for

Re: [akka-user] Akka remote communication roadmap?

- *Solution A:* Migrate akka-remote from Netty 3 to 4 and gain 4 times the performance with an effort equivalent to N hours. - //this would not happen, and don't give you 4 times boost - *Solution B:* Migrate akka-remote from Netty 3 to akka-streams and gain 5 to 6 times the

Re: [akka-user] Akka remote communication roadmap?

yes,akka-stream based will give us more control,and I think that's is more important than performance,because it means how stable akka-cluster will be. 在 2016年1月22日星期五 UTC+8下午9:23:03，Akka Team写道： > > > > On Fri, Jan 22, 2016 at 2:00 PM, 何品 > wrote: > >> >>- *Solution

Re: [akka-user] Akka remote communication roadmap?

On Fri, Jan 22, 2016 at 2:00 PM, 何品 wrote: > >- *Solution A:* Migrate akka-remote from Netty 3 to 4 and gain 4 times >the performance with an effort equivalent to N hours. >- //this would not happen, and don't give you 4 times boost > > It won't give a

Re: [akka-user] Akka remote communication roadmap?

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 from 2ms to 3ms, found an interesting article that maybe could help in the future: https://blog.twitter.com/2013/netty-4-at-twitter-reduced-gc-overhead I'm just

Re: [akka-user] Akka remote communication roadmap?

Hi Roland, This is a very good and honest insight view of the Akka roadmap. You are doing an extreme good job with the Akka project. I hope the team will get bigger without compromising the quality. Best Regards. On 20 October 2015 at 11:13, Roland Kuhn wrote: > Guido, you

Re: [akka-user] Akka remote communication roadmap?

Hi Roland, Fair enough, I agree with all you have said, specially the non-negotiable points which are the foundation of the remote communication contracts ported from Erlang paradigms, our application can survive with the times it has at the moment. I only needed to hear/know what you just

Re: [akka-user] Akka remote communication roadmap?

Guido, you are right that remote communication is key to what Akka is all about. The main hindrance in terms of implementation improvements is that there is a rather large complexity overhead incurred by supporting bidirectional TCP usage guaranteeing per-pair ordering with at-most-once

Re: [akka-user] Akka remote communication roadmap?

Thanks for your understanding, Guido. The offer of support is not specifically for you only, though: if anyone wants to start exploring this space then please go ahead and share your findings! Regards, Roland > 20 okt 2015 kl. 12:30 skrev Guido Medina : > > Hi Roland, > >

Re: [akka-user] Akka remote communication roadmap?

HFT is really different I think,could not only depends on one framework to solve them all.Akka is really great ,as one of my mate said when he is reading ```java concurrency practice```,we would have failed without select Akka as our game server base. Akka/erlang or any other

Re: [akka-user] Akka remote communication roadmap?

Thanks, Filippo! Concerning reaching for other tools where appropriate: there is https://github.com/StefanE/AkkAeron but I have not yet tried it out—this might be a viable approach, too, that punts on location transparent ActorRefs in exchange for high

[akka-user] Akka remote communication roadmap?

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