aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Schroeder <jeffschroe...@computer.org>
Subject Re: Subscribing to Aurora's tasks' event changes
Date Thu, 28 Apr 2016 19:03:35 GMT
On Monday, April 25, 2016, John Sirois <john.sirois@gmail.com> wrote:

> On Mon, Apr 25, 2016 at 8:15 PM, John Sirois <john.sirois@gmail.com
> <javascript:;>> wrote:
>
> >
> >
> > On Mon, Apr 25, 2016 at 7:58 PM, Bill Farner <wfarner@apache.org
> <javascript:;>> wrote:
> >
> >> I don't have a firm example in mind, I just don't think the approach
> >> recommended by Zameer is optimal.  It's only marginally better than
> >> forking
> >> (and probably requires you to fork for the sake of sanity).
> >>
> >> Thinking out loud, it would be nice if Kafka had a JMS interface/bridge,
> >> as
> >> it would allow us to add support for a bunch of backends with one
> >> implementation.  Unfortunately that does not appear to be the case.
> >>
> >
> > That said - supporting a JMS interface doesn't sound too bad on the
> aurora
> > end.
> > Motivated consumers could write a bridge presumably if they insist on
> > using Kafka.
> >
>
> Or maybe even just a webhook API.  You configure aurora with an HTTP
> endpoint that must conform to a given api and Aurora tries, best effort
> only, to post events to the endpoint, perhaps on a streaming connection.
> This scales well for Aurora.



Or Server Send Events, an often overlooked but really nice way of having a
server send clients events in realtime over http. I *think* this is the way
marathon sends events to marathon-lb (haven't looked though)





-- 
Text by Jeff, typos by iPhone

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message