accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <ctubb...@apache.org>
Subject Re: [DISCUSS] Rethinking monitor log receiver
Date Fri, 24 Feb 2017 03:57:18 GMT
To wrap this thread up, I'm basically going to do ACCUMULO-4409, and leave
the monitor registration in place for the active monitor.

On Tue, Feb 7, 2017 at 6:09 PM Christopher <ctubbsii@apache.org> wrote:

> On Tue, Feb 7, 2017 at 12:17 PM Josh Elser <josh.elser@gmail.com> wrote:
>
> Christopher wrote:
> > OnTue, Feb 7, 2017  at 11:02 AM  Billie Rinaldi<billie.rinaldi@gmail.com
> >
> > wrote:
> >
> >> >  I am a fan of the log-forwarding feature. I wouldn't mind if there
> were an
> >> >  option to turn it off for users that don't want it. I also wouldn't
> mind if
> >> >  someone wanted to improve how the log-forwarding mechanism is
> implemented.
> >> >  Option (2) doesn't work for me, though. I need the log-forwarding
> >> >  destination(s) to be discovered automatically rather than requiring
> it to
> >> >  be known in advance / configured manually by the user.
> >> >
> >> >
> > Using DNS (CNAME) for the monitor destination might be a better solution
> > for auto-routing to the current monitor, rather than the auto-discovery
> > happening inside Accumulo. The DNS solution won't work for random
> ports...
> > but I'm not sure what the use is for a monitor that isn't served to a
> > well-known location. A custom appender which does the logic (rather than
> > the standard socket appender, custom properties, and tserver logic) would
> > also work, if the services are properly advertised.
> >
> > What are your thoughts on these?
> >
>
> I don't know much about DNS, but I know enough to say that trying to
> provide a DNS-based approach would be a bigger burden than what we have
> now (security concerns and deployment into "enterprise" environments).
>
>
> If we tried to do it, yes, it would be a bigger burden. But, I'm not sure
> if I agree that would be the case for external services. It's pretty easy
> to update /etc/hosts, to write a name service plugin for nsswitch.conf, or
> to use a dynamic DNS service, etc. Lots of external options for this sort
> of thing. If we were to recommend this option, it'd basically be a
> recommendation for users to look outside of our project for such a solution.
>
>
> Also, Billie can probably speak to this better than I can, but with DNS
> (at least in Java), you'll also have to deal with caching of stale
> mappings.
>
>
> http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-jvm-ttl.html
>
>
> Yeah, another colleague pointed this out to me, and I was shocked that
> Java did this at all... it seems crazy to me that they wouldn't just defer
> to the OS for all DNS resolution, which would inherently use OS preferences
> for DNS caching (which typically respects TTL). At the very least, it could
> do DNS caching which respects TTL. I have no idea what the JVM developers
> could have been thinking here. (Maybe attempting to achieve cross-platform
> network support in an era prior to widespread OS support for networking?
> Maybe this is all just legacy stuff... still, it seems crazy to me.)
>
> --
> Christopher
>
-- 
Christopher

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