There are a lot of alternatives for the UDP transport service. I put
JGroups in the functional spec because it is a mature product that is
closely aligned with how Geode/GemFire works and will cause minimal
behavioral changes and no configuration changes.
It looks like Aeron has had 1 release and is at v0.1. I'm not saying
it's unreliable but why would we want move to it when we're trying to
get out of incubation and get people to move from GemFire to Geode?
In the functional spec I'm trying to allow for other transports to be
inserted in the future but I think we should be as conservative as
possible for the initial implementation.
Le 7/10/2015 8:07 AM, Anthony Baker a écrit :
Hi Bruce,
Any thoughts on whether the Aeron project [1] [2] from Martin Thompson et al
would prove useful for the reliable UDP transport layer? Not sure what level
of performance you need from that channel.
Anthony
[1] https://github.com/real-logic/Aeron <https://github.com/real-logic/Aeron>
[2]
http://highscalability.com/blog/2014/11/17/aeron-do-we-really-need-another-messaging-system.html
<http://highscalability.com/blog/2014/11/17/aeron-do-we-really-need-another-messaging-system.html>
On Jul 8, 2015, at 12:28 PM, Bruce Schuchardt <[email protected]> wrote:
An initial functional specification for a JGroups replacement can be found here:
https://cwiki.apache.org/confluence/display/GEODE/MembershipManager+Functional+Specification
