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 said (awareness of the current state/situation), knowing that you guys are aware of its importance is a big relief, I'll do my best to catch up and try to help when I get there (That is the learning curve of Scala and Akka abstraction layers needed to help with it, no promises though) Best regards, Guido. On Tuesday, October 20, 2015 at 11:13:44 AM UTC+1, rkuhn wrote: > > 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 semantics (*) > - … across connection failures > > I’d very much like to dump as much of the baggage as possible to make > headway, but this will mean that we become (even) more opinionated in terms > of where Akka Cluster is applicable—I’d envision it to be targeted at > localized deployment within the same rack or data center so that we can go > beyond TCP. The (*) point is not negotiable, though. > > One thing that might not be widely known—despite there being no secret > about it—is that the Akka team at Typesafe is not actually that big, we > cannot do all things at once. We are right now in a position where we must > finish what we began, we cannot leave Streams & HTTP in this half-finished > state, with lots of performance and API improvements lying on the table. > And to make in particular Streams more widely applicable we also need to > work on getting more data sources and sinks integrated with it, either > directly or via Reactive Streams interfaces. > > This means that there is no wiggle room for us in the near term future to > tackle such a large new topic as re-envisioning the remoting > implementation. Such an effort could start small, though, and it could also > start outside of the core team. I’m absolutely ready to support any such > initiative, e.g. by making sure that the RemoteTransport interface is > high-level and accessible enough to make an alternative transport not only > possible but also successful. > > Ideas could be to use Aeron in terms of a communication model (e.g. by > switching off redeliveries since we don’t need them) or to research > QUIC—but a pure UDP transport would also be interesting to explore in order > 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 > want a pony! (I actually want a time machine …) > > Regards, > > Roland > > 20 okt 2015 kl. 11:41 skrev Guido Medina <oxy...@gmail.com <javascript:>>: > > 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 > because of its performance? > > I think Akka remote performance is a very important aspect for Akka and > should deserve a higher priority but hey, I'm only one Akka user maybe the > other thousands think otherwise. > > On Tuesday, October 20, 2015 at 8:02:40 AM UTC+1, 何品 wrote: >> >> I rewrite it with akka-io-netty ,it has the same api as the akka-io,and >> then redo the transport based on it.but my company asked me to delete it >> from the github.so sorry.and the link below is unmatained and we are not >> using it in production any more. >> and I think for the really HT,you could do the things like: >> 1,reduce context switch >> 2,reduce gc pressure >> 3,quick serialization >> 4,don't using tcp >> 5,don't using akka remote directly >> >> If I was you ,I would start a dedicated endpoint for the exchange ,which >> may be based on Aeron or Netty4 with UDT.only by using akka-stream and >> netty4 will not make it works here I think,5 ms,need some special work. >> >>> > -- > >>>>>>>>>> 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 User List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to akka-user+...@googlegroups.com <javascript:>. > To post to this group, send email to akka...@googlegroups.com > <javascript:>. > Visit this group at http://groups.google.com/group/akka-user. > For more options, visit https://groups.google.com/d/optout. > > > > > *Dr. Roland Kuhn* > *Akka Tech Lead* > Typesafe <http://typesafe.com/> – Reactive apps on the JVM. > twitter: @rolandkuhn > <http://twitter.com/#!/rolandkuhn> > > -- >>>>>>>>>> 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 User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscr...@googlegroups.com. To post to this group, send email to akka-user@googlegroups.com. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
