Sounds good! It will be interesting to see if the Aeron project gets any traction.
Anthony > On Jul 10, 2015, at 8:59 AM, Bruce Schuchardt <bschucha...@pivotal.io> wrote: > > 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 <bschucha...@pivotal.io> >>> wrote: >>> >>> An initial functional specification for a JGroups replacement can be found >>> here: >>> >>> https://cwiki.apache.org/confluence/display/GEODE/MembershipManager+Functional+Specification >>> >> >
