I've been looking at the zeromq project. It's a precursor to aeron. On 11 Jul 2015 3:01 am, "Anthony Baker" <[email protected]> wrote:
> 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 <[email protected]> > 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 <[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 > >>> > >> > > > >
