[jira] [Commented] (ACCUMULO-4600) Shell does not fall back to accumulo-site.xml when on classpath
[
https://issues.apache.org/jira/browse/ACCUMULO-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15899788#comment-15899788
]
Josh Elser commented on ACCUMULO-4600:
--
Looks like ACCUMULO-4505 broke this.
FYI [~milleruntime], [~ctubbsii].
> Shell does not fall back to accumulo-site.xml when on classpath
> ---
>
> Key: ACCUMULO-4600
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4600
> Project: Accumulo
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.7.3
>Reporter: Josh Elser
>Priority: Critical
>
> When inspecting 1.7.3-rc1 for the VOTE, I did the following steps:
> * Unpack bin-tarball
> * Copy 3gb native example confs
> * Set {{instance.volumes}} in accumulo-site.xml
> * {{export ACCUMULO_HOME="$(pwd)"}}
> * {{./bin/accumulo init}}
> * {{./bin/start-all.sh}}
> * {{./bin/accumulo shell -u root}}
> The shell failed to connect stating that no tservers were running. By turning
> on the debug option to the shell, I could see that the wrong HDFS directory
> was being used to find the Accumulo instance ID, {{/accumulo}} instead of
> {{/accumulo173rc1}}.
> This appears to be because of
> {{ClientContext#convertClientConfig(Configuration)}} and
> {{Shell#getZooInstance(String, String, ClientConfiguration}}. The client
> configuration is empty, therefore, all values end up being pulled from the
> {{DefaultConfiguration}} instance instead of the accumulo-site.xml which is
> on the classpath.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ACCUMULO-4600) Shell does not fall back to accumulo-site.xml when on classpath
[
https://issues.apache.org/jira/browse/ACCUMULO-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15899846#comment-15899846
]
Michael Miller commented on ACCUMULO-4600:
--
[~elserj] Thoughts on remedies?
> Shell does not fall back to accumulo-site.xml when on classpath
> ---
>
> Key: ACCUMULO-4600
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4600
> Project: Accumulo
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.7.3
>Reporter: Josh Elser
>Priority: Critical
>
> When inspecting 1.7.3-rc1 for the VOTE, I did the following steps:
> * Unpack bin-tarball
> * Copy 3gb native example confs
> * Set {{instance.volumes}} in accumulo-site.xml
> * {{export ACCUMULO_HOME="$(pwd)"}}
> * {{./bin/accumulo init}}
> * {{./bin/start-all.sh}}
> * {{./bin/accumulo shell -u root}}
> The shell failed to connect stating that no tservers were running. By turning
> on the debug option to the shell, I could see that the wrong HDFS directory
> was being used to find the Accumulo instance ID, {{/accumulo}} instead of
> {{/accumulo173rc1}}.
> This appears to be because of
> {{ClientContext#convertClientConfig(Configuration)}} and
> {{Shell#getZooInstance(String, String, ClientConfiguration}}. The client
> configuration is empty, therefore, all values end up being pulled from the
> {{DefaultConfiguration}} instance instead of the accumulo-site.xml which is
> on the classpath.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ACCUMULO-4600) Shell does not fall back to accumulo-site.xml when on classpath
[
https://issues.apache.org/jira/browse/ACCUMULO-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15899858#comment-15899858
]
Josh Elser commented on ACCUMULO-4600:
--
bq. Thoughts on remedies?
The first (trivial) idea I had was that this method should not use a
{{DefaultConfiguration}} instance, instead a {{SiteConfiguration}}. I assume if
we reverted your change, we would end up breaking your fix. So, we would have
to break the ClientContext call into some different logic -- perhaps passing in
an {{AccumuloConfiguration}} instance instead of blindly choosing one in the
method itself.
However, I don't know if there are more edge cases lying in wait...
> Shell does not fall back to accumulo-site.xml when on classpath
> ---
>
> Key: ACCUMULO-4600
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4600
> Project: Accumulo
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.7.3
>Reporter: Josh Elser
>Priority: Critical
>
> When inspecting 1.7.3-rc1 for the VOTE, I did the following steps:
> * Unpack bin-tarball
> * Copy 3gb native example confs
> * Set {{instance.volumes}} in accumulo-site.xml
> * {{export ACCUMULO_HOME="$(pwd)"}}
> * {{./bin/accumulo init}}
> * {{./bin/start-all.sh}}
> * {{./bin/accumulo shell -u root}}
> The shell failed to connect stating that no tservers were running. By turning
> on the debug option to the shell, I could see that the wrong HDFS directory
> was being used to find the Accumulo instance ID, {{/accumulo}} instead of
> {{/accumulo173rc1}}.
> This appears to be because of
> {{ClientContext#convertClientConfig(Configuration)}} and
> {{Shell#getZooInstance(String, String, ClientConfiguration}}. The client
> configuration is empty, therefore, all values end up being pulled from the
> {{DefaultConfiguration}} instance instead of the accumulo-site.xml which is
> on the classpath.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ACCUMULO-4600) Shell does not fall back to accumulo-site.xml when on classpath
[
https://issues.apache.org/jira/browse/ACCUMULO-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15900022#comment-15900022
]
Christopher Tubbs commented on ACCUMULO-4600:
-
Ugh. I really hate this special shell behavior.
> Shell does not fall back to accumulo-site.xml when on classpath
> ---
>
> Key: ACCUMULO-4600
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4600
> Project: Accumulo
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.7.3
>Reporter: Josh Elser
>Priority: Critical
>
> When inspecting 1.7.3-rc1 for the VOTE, I did the following steps:
> * Unpack bin-tarball
> * Copy 3gb native example confs
> * Set {{instance.volumes}} in accumulo-site.xml
> * {{export ACCUMULO_HOME="$(pwd)"}}
> * {{./bin/accumulo init}}
> * {{./bin/start-all.sh}}
> * {{./bin/accumulo shell -u root}}
> The shell failed to connect stating that no tservers were running. By turning
> on the debug option to the shell, I could see that the wrong HDFS directory
> was being used to find the Accumulo instance ID, {{/accumulo}} instead of
> {{/accumulo173rc1}}.
> This appears to be because of
> {{ClientContext#convertClientConfig(Configuration)}} and
> {{Shell#getZooInstance(String, String, ClientConfiguration}}. The client
> configuration is empty, therefore, all values end up being pulled from the
> {{DefaultConfiguration}} instance instead of the accumulo-site.xml which is
> on the classpath.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ACCUMULO-4600) Shell does not fall back to accumulo-site.xml when on classpath
[
https://issues.apache.org/jira/browse/ACCUMULO-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15900026#comment-15900026
]
Christopher Tubbs commented on ACCUMULO-4600:
-
I think maybe another solution might work: create a
{{SiteConfiguration.getInstanceOrDefault(...)}} method specifically for this
shell use case. We have to be careful not to override the client config if it's
available, but then sanely fall back on the site config, but only if that site
config is accessible.
> Shell does not fall back to accumulo-site.xml when on classpath
> ---
>
> Key: ACCUMULO-4600
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4600
> Project: Accumulo
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.7.3
>Reporter: Josh Elser
>Priority: Critical
>
> When inspecting 1.7.3-rc1 for the VOTE, I did the following steps:
> * Unpack bin-tarball
> * Copy 3gb native example confs
> * Set {{instance.volumes}} in accumulo-site.xml
> * {{export ACCUMULO_HOME="$(pwd)"}}
> * {{./bin/accumulo init}}
> * {{./bin/start-all.sh}}
> * {{./bin/accumulo shell -u root}}
> The shell failed to connect stating that no tservers were running. By turning
> on the debug option to the shell, I could see that the wrong HDFS directory
> was being used to find the Accumulo instance ID, {{/accumulo}} instead of
> {{/accumulo173rc1}}.
> This appears to be because of
> {{ClientContext#convertClientConfig(Configuration)}} and
> {{Shell#getZooInstance(String, String, ClientConfiguration}}. The client
> configuration is empty, therefore, all values end up being pulled from the
> {{DefaultConfiguration}} instance instead of the accumulo-site.xml which is
> on the classpath.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ACCUMULO-4600) Shell does not fall back to accumulo-site.xml when on classpath
[
https://issues.apache.org/jira/browse/ACCUMULO-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15900030#comment-15900030
]
Michael Miller commented on ACCUMULO-4600:
--
I made the (breaking) fix in 1.8.1 as well. Did we miss this issue with the
last realease or does it not apply in the 1.8 branch?
> Shell does not fall back to accumulo-site.xml when on classpath
> ---
>
> Key: ACCUMULO-4600
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4600
> Project: Accumulo
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.7.3
>Reporter: Josh Elser
>Priority: Critical
>
> When inspecting 1.7.3-rc1 for the VOTE, I did the following steps:
> * Unpack bin-tarball
> * Copy 3gb native example confs
> * Set {{instance.volumes}} in accumulo-site.xml
> * {{export ACCUMULO_HOME="$(pwd)"}}
> * {{./bin/accumulo init}}
> * {{./bin/start-all.sh}}
> * {{./bin/accumulo shell -u root}}
> The shell failed to connect stating that no tservers were running. By turning
> on the debug option to the shell, I could see that the wrong HDFS directory
> was being used to find the Accumulo instance ID, {{/accumulo}} instead of
> {{/accumulo173rc1}}.
> This appears to be because of
> {{ClientContext#convertClientConfig(Configuration)}} and
> {{Shell#getZooInstance(String, String, ClientConfiguration}}. The client
> configuration is empty, therefore, all values end up being pulled from the
> {{DefaultConfiguration}} instance instead of the accumulo-site.xml which is
> on the classpath.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ACCUMULO-4600) Shell does not fall back to accumulo-site.xml when on classpath
[
https://issues.apache.org/jira/browse/ACCUMULO-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15900047#comment-15900047
]
Josh Elser commented on ACCUMULO-4600:
--
bq. I made the (breaking) fix in 1.8.1 as well. Did we miss this issue with the
last release or does it not apply in the 1.8 branch?
I'm guessing it was missed (I don't think I made time to test that out), but I
have not yet confirmed. Steps above should apply..
> Shell does not fall back to accumulo-site.xml when on classpath
> ---
>
> Key: ACCUMULO-4600
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4600
> Project: Accumulo
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.7.3
>Reporter: Josh Elser
>Priority: Critical
>
> When inspecting 1.7.3-rc1 for the VOTE, I did the following steps:
> * Unpack bin-tarball
> * Copy 3gb native example confs
> * Set {{instance.volumes}} in accumulo-site.xml
> * {{export ACCUMULO_HOME="$(pwd)"}}
> * {{./bin/accumulo init}}
> * {{./bin/start-all.sh}}
> * {{./bin/accumulo shell -u root}}
> The shell failed to connect stating that no tservers were running. By turning
> on the debug option to the shell, I could see that the wrong HDFS directory
> was being used to find the Accumulo instance ID, {{/accumulo}} instead of
> {{/accumulo173rc1}}.
> This appears to be because of
> {{ClientContext#convertClientConfig(Configuration)}} and
> {{Shell#getZooInstance(String, String, ClientConfiguration}}. The client
> configuration is empty, therefore, all values end up being pulled from the
> {{DefaultConfiguration}} instance instead of the accumulo-site.xml which is
> on the classpath.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ACCUMULO-4600) Shell does not fall back to accumulo-site.xml when on classpath
[
https://issues.apache.org/jira/browse/ACCUMULO-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15900048#comment-15900048
]
Josh Elser commented on ACCUMULO-4600:
--
bq. Ugh. I really hate this special shell behavior. We don't expect this of any
other client.
Compatibility is hard :)
> Shell does not fall back to accumulo-site.xml when on classpath
> ---
>
> Key: ACCUMULO-4600
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4600
> Project: Accumulo
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.7.3
>Reporter: Josh Elser
>Priority: Critical
>
> When inspecting 1.7.3-rc1 for the VOTE, I did the following steps:
> * Unpack bin-tarball
> * Copy 3gb native example confs
> * Set {{instance.volumes}} in accumulo-site.xml
> * {{export ACCUMULO_HOME="$(pwd)"}}
> * {{./bin/accumulo init}}
> * {{./bin/start-all.sh}}
> * {{./bin/accumulo shell -u root}}
> The shell failed to connect stating that no tservers were running. By turning
> on the debug option to the shell, I could see that the wrong HDFS directory
> was being used to find the Accumulo instance ID, {{/accumulo}} instead of
> {{/accumulo173rc1}}.
> This appears to be because of
> {{ClientContext#convertClientConfig(Configuration)}} and
> {{Shell#getZooInstance(String, String, ClientConfiguration}}. The client
> configuration is empty, therefore, all values end up being pulled from the
> {{DefaultConfiguration}} instance instead of the accumulo-site.xml which is
> on the classpath.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ACCUMULO-4600) Shell does not fall back to accumulo-site.xml when on classpath
[
https://issues.apache.org/jira/browse/ACCUMULO-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15900107#comment-15900107
]
Michael Miller commented on ACCUMULO-4600:
--
I think I got burned by this comment:
https://github.com/apache/accumulo/blob/1.7/shell/src/main/java/org/apache/accumulo/shell/ShellOptionsJC.java#L329
What about just making ShellOptionsJC read from accumulo-site like the comment
claims its doing? I'd feel more comfortable modifying ShellOptionsJC instead
of messing with any of the *Configuration or ClientContext objects.
> Shell does not fall back to accumulo-site.xml when on classpath
> ---
>
> Key: ACCUMULO-4600
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4600
> Project: Accumulo
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.7.3
>Reporter: Josh Elser
>Priority: Critical
>
> When inspecting 1.7.3-rc1 for the VOTE, I did the following steps:
> * Unpack bin-tarball
> * Copy 3gb native example confs
> * Set {{instance.volumes}} in accumulo-site.xml to
> {{hdfs://localhost:8020/accumulo173rc1}}
> * {{export ACCUMULO_HOME="$(pwd)"}}
> * {{./bin/accumulo init}}
> * {{./bin/start-all.sh}}
> * {{./bin/accumulo shell -u root}}
> The shell failed to connect stating that no tservers were running. By turning
> on the debug option to the shell, I could see that the wrong HDFS directory
> was being used to find the Accumulo instance ID, {{/accumulo}} instead of
> {{/accumulo173rc1}}.
> This appears to be because of
> {{ClientContext#convertClientConfig(Configuration)}} and
> {{Shell#getZooInstance(String, String, ClientConfiguration}}. The client
> configuration is empty, therefore, all values end up being pulled from the
> {{DefaultConfiguration}} instance instead of the accumulo-site.xml which is
> on the classpath.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ACCUMULO-4600) Shell does not fall back to accumulo-site.xml when on classpath
[
https://issues.apache.org/jira/browse/ACCUMULO-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15900147#comment-15900147
]
Josh Elser commented on ACCUMULO-4600:
--
bq. What about just making ShellOptionsJC read from accumulo-site like the
comment claims its doing?
I don't understand what you mean by this. Are you implying that we should also
have {{instance.volumes}} (and maybe the old {{instance.dfs.*}} properties also
automagically pulled via the ClientConfiguration?
> Shell does not fall back to accumulo-site.xml when on classpath
> ---
>
> Key: ACCUMULO-4600
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4600
> Project: Accumulo
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.7.3
>Reporter: Josh Elser
>Priority: Critical
>
> When inspecting 1.7.3-rc1 for the VOTE, I did the following steps:
> * Unpack bin-tarball
> * Copy 3gb native example confs
> * Set {{instance.volumes}} in accumulo-site.xml to
> {{hdfs://localhost:8020/accumulo173rc1}}
> * {{export ACCUMULO_HOME="$(pwd)"}}
> * {{./bin/accumulo init}}
> * {{./bin/start-all.sh}}
> * {{./bin/accumulo shell -u root}}
> The shell failed to connect stating that no tservers were running. By turning
> on the debug option to the shell, I could see that the wrong HDFS directory
> was being used to find the Accumulo instance ID, {{/accumulo}} instead of
> {{/accumulo173rc1}}.
> This appears to be because of
> {{ClientContext#convertClientConfig(Configuration)}} and
> {{Shell#getZooInstance(String, String, ClientConfiguration}}. The client
> configuration is empty, therefore, all values end up being pulled from the
> {{DefaultConfiguration}} instance instead of the accumulo-site.xml which is
> on the classpath.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ACCUMULO-4600) Shell does not fall back to accumulo-site.xml when on classpath
[
https://issues.apache.org/jira/browse/ACCUMULO-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15900146#comment-15900146
]
Christopher Tubbs commented on ACCUMULO-4600:
-
I think the problem in ACCUMULO-4505 was that when ShellOptionsJC tried to call
the SiteConfiguration method, it failed, because SiteConfiguration assumes the
file is readable. If SiteConfiguration can have a more tolerant method that
doesn't cause a hard failure, and ShellOptionsJC called that... I think that
would make the most sense.
> Shell does not fall back to accumulo-site.xml when on classpath
> ---
>
> Key: ACCUMULO-4600
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4600
> Project: Accumulo
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.7.3
>Reporter: Josh Elser
>Priority: Critical
>
> When inspecting 1.7.3-rc1 for the VOTE, I did the following steps:
> * Unpack bin-tarball
> * Copy 3gb native example confs
> * Set {{instance.volumes}} in accumulo-site.xml to
> {{hdfs://localhost:8020/accumulo173rc1}}
> * {{export ACCUMULO_HOME="$(pwd)"}}
> * {{./bin/accumulo init}}
> * {{./bin/start-all.sh}}
> * {{./bin/accumulo shell -u root}}
> The shell failed to connect stating that no tservers were running. By turning
> on the debug option to the shell, I could see that the wrong HDFS directory
> was being used to find the Accumulo instance ID, {{/accumulo}} instead of
> {{/accumulo173rc1}}.
> This appears to be because of
> {{ClientContext#convertClientConfig(Configuration)}} and
> {{Shell#getZooInstance(String, String, ClientConfiguration}}. The client
> configuration is empty, therefore, all values end up being pulled from the
> {{DefaultConfiguration}} instance instead of the accumulo-site.xml which is
> on the classpath.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ACCUMULO-4600) Shell does not fall back to accumulo-site.xml when on classpath
[
https://issues.apache.org/jira/browse/ACCUMULO-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15901365#comment-15901365
]
Michael Miller commented on ACCUMULO-4600:
--
After some debugging, the Shell is reading from accumulo-site.xml just fine. I
think the problem is the conversion from SiteConfiguration to
ClientConfiguration... mainly the fact that there is no INSTANCE_VOLUMES
ClientProperty.
> Shell does not fall back to accumulo-site.xml when on classpath
> ---
>
> Key: ACCUMULO-4600
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4600
> Project: Accumulo
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.7.3
>Reporter: Josh Elser
>Priority: Critical
>
> When inspecting 1.7.3-rc1 for the VOTE, I did the following steps:
> * Unpack bin-tarball
> * Copy 3gb native example confs
> * Set {{instance.volumes}} in accumulo-site.xml to
> {{hdfs://localhost:8020/accumulo173rc1}}
> * {{export ACCUMULO_HOME="$(pwd)"}}
> * {{./bin/accumulo init}}
> * {{./bin/start-all.sh}}
> * {{./bin/accumulo shell -u root}}
> The shell failed to connect stating that no tservers were running. By turning
> on the debug option to the shell, I could see that the wrong HDFS directory
> was being used to find the Accumulo instance ID, {{/accumulo}} instead of
> {{/accumulo173rc1}}.
> This appears to be because of
> {{ClientContext#convertClientConfig(Configuration)}} and
> {{Shell#getZooInstance(String, String, ClientConfiguration}}. The client
> configuration is empty, therefore, all values end up being pulled from the
> {{DefaultConfiguration}} instance instead of the accumulo-site.xml which is
> on the classpath.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ACCUMULO-4600) Shell does not fall back to accumulo-site.xml when on classpath
[
https://issues.apache.org/jira/browse/ACCUMULO-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15901461#comment-15901461
]
Josh Elser commented on ACCUMULO-4600:
--
I don't think it makes sense to have an instance.volumes client property,
explicitly. Like Christopher pointed out, this is an edge case, not a normal
one. Users shouldn't have to know where in hdfs Accumulo is writing files.
> Shell does not fall back to accumulo-site.xml when on classpath
> ---
>
> Key: ACCUMULO-4600
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4600
> Project: Accumulo
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.7.3
>Reporter: Josh Elser
>Priority: Critical
>
> When inspecting 1.7.3-rc1 for the VOTE, I did the following steps:
> * Unpack bin-tarball
> * Copy 3gb native example confs
> * Set {{instance.volumes}} in accumulo-site.xml to
> {{hdfs://localhost:8020/accumulo173rc1}}
> * {{export ACCUMULO_HOME="$(pwd)"}}
> * {{./bin/accumulo init}}
> * {{./bin/start-all.sh}}
> * {{./bin/accumulo shell -u root}}
> The shell failed to connect stating that no tservers were running. By turning
> on the debug option to the shell, I could see that the wrong HDFS directory
> was being used to find the Accumulo instance ID, {{/accumulo}} instead of
> {{/accumulo173rc1}}.
> This appears to be because of
> {{ClientContext#convertClientConfig(Configuration)}} and
> {{Shell#getZooInstance(String, String, ClientConfiguration}}. The client
> configuration is empty, therefore, all values end up being pulled from the
> {{DefaultConfiguration}} instance instead of the accumulo-site.xml which is
> on the classpath.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ACCUMULO-4600) Shell does not fall back to accumulo-site.xml when on classpath
[
https://issues.apache.org/jira/browse/ACCUMULO-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15901504#comment-15901504
]
Christopher Tubbs commented on ACCUMULO-4600:
-
I agree. Clients don't need to know where instance volumes are, in general.
Unfortunately, in this case, that's exactly what makes the shell different.
I think the problem is in {{Shell.getZooInstance(...)}}. There, it is trying to
read the instance ID from HDFS, but it's using the client config to determine
the volumes to inspect, rather than the site config. In {{ShellOptionsJC}}, we
handle a similar case by wrapping the client config with a
{{SiteConfiguration}} so we can fall back to the ZK hosts in the site file when
its missing from the {{ClientConfiguration}}, but we're not doing that here for
the fallback volumes when the instance name is missing from the
{{ClientConfiguration}} so we can get the instanceID.
> Shell does not fall back to accumulo-site.xml when on classpath
> ---
>
> Key: ACCUMULO-4600
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4600
> Project: Accumulo
> Issue Type: Bug
> Components: shell
>Affects Versions: 1.7.3
>Reporter: Josh Elser
>Priority: Critical
>
> When inspecting 1.7.3-rc1 for the VOTE, I did the following steps:
> * Unpack bin-tarball
> * Copy 3gb native example confs
> * Set {{instance.volumes}} in accumulo-site.xml to
> {{hdfs://localhost:8020/accumulo173rc1}}
> * {{export ACCUMULO_HOME="$(pwd)"}}
> * {{./bin/accumulo init}}
> * {{./bin/start-all.sh}}
> * {{./bin/accumulo shell -u root}}
> The shell failed to connect stating that no tservers were running. By turning
> on the debug option to the shell, I could see that the wrong HDFS directory
> was being used to find the Accumulo instance ID, {{/accumulo}} instead of
> {{/accumulo173rc1}}.
> This appears to be because of
> {{ClientContext#convertClientConfig(Configuration)}} and
> {{Shell#getZooInstance(String, String, ClientConfiguration}}. The client
> configuration is empty, therefore, all values end up being pulled from the
> {{DefaultConfiguration}} instance instead of the accumulo-site.xml which is
> on the classpath.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ACCUMULO-4600) Shell does not fall back to accumulo-site.xml when on classpath
[
https://issues.apache.org/jira/browse/ACCUMULO-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15901674#comment-15901674
]
Michael Miller commented on ACCUMULO-4600:
--
I think I have a solution, Mr. Turner helped set me straight. I will open a
pull request momentarily. Uno momento por favor
> Shell does not fall back to accumulo-site.xml when on classpath
> ---
>
> Key: ACCUMULO-4600
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4600
> Project: Accumulo
> Issue Type: Bug
> Components: shell
>Reporter: Josh Elser
>Priority: Blocker
> Fix For: 1.7.3, 1.8.2, 2.0.0
>
>
> When inspecting 1.7.3-rc1 for the VOTE, I did the following steps:
> * Unpack bin-tarball
> * Copy 3gb native example confs
> * Set {{instance.volumes}} in accumulo-site.xml to
> {{hdfs://localhost:8020/accumulo173rc1}}
> * {{export ACCUMULO_HOME="$(pwd)"}}
> * {{./bin/accumulo init}}
> * {{./bin/start-all.sh}}
> * {{./bin/accumulo shell -u root}}
> The shell failed to connect stating that no tservers were running. By turning
> on the debug option to the shell, I could see that the wrong HDFS directory
> was being used to find the Accumulo instance ID, {{/accumulo}} instead of
> {{/accumulo173rc1}}.
> This appears to be because of
> {{ClientContext#convertClientConfig(Configuration)}} and
> {{Shell#getZooInstance(String, String, ClientConfiguration}}. The client
> configuration is empty, therefore, all values end up being pulled from the
> {{DefaultConfiguration}} instance instead of the accumulo-site.xml which is
> on the classpath.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ACCUMULO-4600) Shell does not fall back to accumulo-site.xml when on classpath
[
https://issues.apache.org/jira/browse/ACCUMULO-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15902253#comment-15902253
]
Christopher Tubbs commented on ACCUMULO-4600:
-
It took me *SO* much longer than it should have to figure out who "Mr. Turner"
was.
I assume he means [~kturner] :)
> Shell does not fall back to accumulo-site.xml when on classpath
> ---
>
> Key: ACCUMULO-4600
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4600
> Project: Accumulo
> Issue Type: Bug
> Components: shell
>Reporter: Josh Elser
>Priority: Blocker
> Fix For: 1.7.3, 1.8.2, 2.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When inspecting 1.7.3-rc1 for the VOTE, I did the following steps:
> * Unpack bin-tarball
> * Copy 3gb native example confs
> * Set {{instance.volumes}} in accumulo-site.xml to
> {{hdfs://localhost:8020/accumulo173rc1}}
> * {{export ACCUMULO_HOME="$(pwd)"}}
> * {{./bin/accumulo init}}
> * {{./bin/start-all.sh}}
> * {{./bin/accumulo shell -u root}}
> The shell failed to connect stating that no tservers were running. By turning
> on the debug option to the shell, I could see that the wrong HDFS directory
> was being used to find the Accumulo instance ID, {{/accumulo}} instead of
> {{/accumulo173rc1}}.
> This appears to be because of
> {{ClientContext#convertClientConfig(Configuration)}} and
> {{Shell#getZooInstance(String, String, ClientConfiguration}}. The client
> configuration is empty, therefore, all values end up being pulled from the
> {{DefaultConfiguration}} instance instead of the accumulo-site.xml which is
> on the classpath.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ACCUMULO-4600) Shell does not fall back to accumulo-site.xml when on classpath
[
https://issues.apache.org/jira/browse/ACCUMULO-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15902256#comment-15902256
]
Josh Elser commented on ACCUMULO-4600:
--
bq. It took me SO much longer than it should have to figure out who "Mr.
Turner" was.
Nah, probably that Dick Turner guy.
> Shell does not fall back to accumulo-site.xml when on classpath
> ---
>
> Key: ACCUMULO-4600
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4600
> Project: Accumulo
> Issue Type: Bug
> Components: shell
>Reporter: Josh Elser
>Priority: Blocker
> Fix For: 1.7.3, 1.8.2, 2.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When inspecting 1.7.3-rc1 for the VOTE, I did the following steps:
> * Unpack bin-tarball
> * Copy 3gb native example confs
> * Set {{instance.volumes}} in accumulo-site.xml to
> {{hdfs://localhost:8020/accumulo173rc1}}
> * {{export ACCUMULO_HOME="$(pwd)"}}
> * {{./bin/accumulo init}}
> * {{./bin/start-all.sh}}
> * {{./bin/accumulo shell -u root}}
> The shell failed to connect stating that no tservers were running. By turning
> on the debug option to the shell, I could see that the wrong HDFS directory
> was being used to find the Accumulo instance ID, {{/accumulo}} instead of
> {{/accumulo173rc1}}.
> This appears to be because of
> {{ClientContext#convertClientConfig(Configuration)}} and
> {{Shell#getZooInstance(String, String, ClientConfiguration}}. The client
> configuration is empty, therefore, all values end up being pulled from the
> {{DefaultConfiguration}} instance instead of the accumulo-site.xml which is
> on the classpath.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (ACCUMULO-4600) Shell does not fall back to accumulo-site.xml when on classpath
[
https://issues.apache.org/jira/browse/ACCUMULO-4600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15902303#comment-15902303
]
marco polo commented on ACCUMULO-4600:
--
Who is Tick Durner?
> Shell does not fall back to accumulo-site.xml when on classpath
> ---
>
> Key: ACCUMULO-4600
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4600
> Project: Accumulo
> Issue Type: Bug
> Components: shell
>Reporter: Josh Elser
>Priority: Blocker
> Fix For: 1.7.3, 1.8.2, 2.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When inspecting 1.7.3-rc1 for the VOTE, I did the following steps:
> * Unpack bin-tarball
> * Copy 3gb native example confs
> * Set {{instance.volumes}} in accumulo-site.xml to
> {{hdfs://localhost:8020/accumulo173rc1}}
> * {{export ACCUMULO_HOME="$(pwd)"}}
> * {{./bin/accumulo init}}
> * {{./bin/start-all.sh}}
> * {{./bin/accumulo shell -u root}}
> The shell failed to connect stating that no tservers were running. By turning
> on the debug option to the shell, I could see that the wrong HDFS directory
> was being used to find the Accumulo instance ID, {{/accumulo}} instead of
> {{/accumulo173rc1}}.
> This appears to be because of
> {{ClientContext#convertClientConfig(Configuration)}} and
> {{Shell#getZooInstance(String, String, ClientConfiguration}}. The client
> configuration is empty, therefore, all values end up being pulled from the
> {{DefaultConfiguration}} instance instead of the accumulo-site.xml which is
> on the classpath.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
