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 <[email protected]> wrote: > On Tue, Feb 7, 2017 at 12:17 PM Josh Elser <[email protected]> wrote: > > Christopher wrote: > > OnTue, Feb 7, 2017 at 11:02 AM Billie Rinaldi<[email protected] > > > > 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
