accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher <>
Subject Re: [DISCUSS] Rethinking monitor log receiver
Date Tue, 07 Feb 2017 23:09:09 GMT
On Tue, Feb 7, 2017 at 12:17 PM Josh Elser <> wrote:

> Christopher wrote:
> > OnTue, Feb 7, 2017  at 11:02 AM  Billie Rinaldi<
> >
> > 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.

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.)


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