accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Basit Mustafa (JIRA)" <>
Subject [jira] [Created] (ACCUMULO-1585) Provide option for FQDN/verbatim data from config files of servers to be stored in ZooKeeper rather than resolved IP
Date Fri, 19 Jul 2013 00:42:49 GMT
Basit Mustafa created ACCUMULO-1585:

             Summary: Provide option for FQDN/verbatim data from config files of servers to
be stored in ZooKeeper rather than resolved IP
                 Key: ACCUMULO-1585
             Project: Accumulo
          Issue Type: Improvement
          Components: tserver
         Environment: All
            Reporter: Basit Mustafa
            Priority: Minor

There are some situations (esp in virtualized/cloud environments) where "hardwiring" the IP
into ZooKeeper can create reachability issues and an FQDN (or, better/also, the verbatim string/line
from the concerned config file) would fix this problem. 

For example, hostname specified in configuration files resolves to an Amazon
EC2 *internal* IP of (internal on virtualized network). Externally (e.g. from your
dev machine, your offsite/non-VPN/non-VPCed data center, other client machines on different
networks/clouds), will resolve to a public IP (e.g. Amazon Elastic IP, etc)
of something more routeable, like 

Accumulo currently stores in ZooKeeper based on this resolution, but, if you try
to connect to Accumulo from outside these machines/machines in the same cloud/vitualized network/non
routeable network, and the same FQDN ( resolves to the public address now
(, you will not be able to connect, because the Accumulo client will have pulled
the resolved, and from here, unreachable, IP of

Using the FQDN (or in some other way allowing for client-side name resolution/address translation,
although this seems kludgy) would fix this issue in a relatively standard way. Ideally, this
would not incur a performance issue beyond the first resolution assuming the TCP/IP stack
is doing its job and caching stuff effectively (I assume). 

This doesn't really hurt/break things if you give an option in some config, and, really, taking
the literal from the file allows you to use whatever you want, the ultimate in flexibility.

See discussion
for more details and others having the same issue. 

I will look into creating a patch for this as soon as I have some time to find/look at relevant
code portions (I need to find where accumulo is making these writes to ZK and if the read
FQDNs would need any resolution/their use further down the line expects strictly IP or is
in host or IP safe API calls, etc). Any suggestions on where I can begin this are always appreciated.
Otherwise, I'll try and submit a patch when I can. 

Figure I'd open this issue to at least provide a discussion on what more experienced Accumulo
devs and users think and what a solution based on the style/patterns accepted for Accumulo
development/configuration are. I can read the guidelines myself, of course, and will, but
someone suggested opening an issue, so I am...

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message