[jira] [Resolved] (ACCUMULO-4409) Create a custom log4j AccumuloMonitorAppender
[ https://issues.apache.org/jira/browse/ACCUMULO-4409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tubbs resolved ACCUMULO-4409. - Resolution: Fixed Okay, I'll continue to watch out for it. > Create a custom log4j AccumuloMonitorAppender > - > > Key: ACCUMULO-4409 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4409 > Project: Accumulo > Issue Type: Sub-task >Reporter: Christopher Tubbs >Assignee: Christopher Tubbs > Labels: release_notes > Fix For: 2.0.0 > > Time Spent: 6h > Remaining Estimate: 0h > > The current AsyncSocketAppender was an improvement over the older log4j > configuration options, but it did not fully satisfy the description in > ACCUMULO-2343. > What we really need is an appender which can be managed by configuration > alone, without using code to reload it with new system properties when the > location of the monitor changes. > So, rather than having a ZK watcher reload the log4j system, the appender > itself should internally detect the relocation of the monitor and adjust its > behavior accordingly. That way, the configuration files do not need to refer > to system properties for the hostname/port of the monitor, and there is no > need to reload the log4j logging when things change. > This will allow us to remove more custom log4j code, which gets us closer to > users having the ability to use another implementation for the slf4j API > (though this feature of logging to the monitor might not be available for > other slf4j implementations, unless they support using log4j appenders). -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ACCUMULO-4409) Create a custom log4j AccumuloMonitorAppender
[
https://issues.apache.org/jira/browse/ACCUMULO-4409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16203005#comment-16203005
]
Josh Elser commented on ACCUMULO-4409:
--
bq. If you can reproduce with a full stack trace, that might help.
That was all that was given to me by Maven. On a re-run of the {{mvn package}},
it passed. If you can't reproduce, I guess we just close again. Very strange.
> Create a custom log4j AccumuloMonitorAppender
> -
>
> Key: ACCUMULO-4409
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4409
> Project: Accumulo
> Issue Type: Sub-task
>Reporter: Christopher Tubbs
>Assignee: Christopher Tubbs
> Labels: release_notes
> Fix For: 2.0.0
>
> Time Spent: 6h
> Remaining Estimate: 0h
>
> The current AsyncSocketAppender was an improvement over the older log4j
> configuration options, but it did not fully satisfy the description in
> ACCUMULO-2343.
> What we really need is an appender which can be managed by configuration
> alone, without using code to reload it with new system properties when the
> location of the monitor changes.
> So, rather than having a ZK watcher reload the log4j system, the appender
> itself should internally detect the relocation of the monitor and adjust its
> behavior accordingly. That way, the configuration files do not need to refer
> to system properties for the hostname/port of the monitor, and there is no
> need to reload the log4j logging when things change.
> This will allow us to remove more custom log4j code, which gets us closer to
> users having the ability to use another implementation for the slf4j API
> (though this feature of logging to the monitor might not be available for
> other slf4j implementations, unless they support using log4j appenders).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ACCUMULO-4716) Do not attempt to cache blocks over max array size
[
https://issues.apache.org/jira/browse/ACCUMULO-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202825#comment-16202825
]
Mark Owens commented on ACCUMULO-4716:
--
Closed and fix versions updated. Thanks [~ctubbsii]
> Do not attempt to cache blocks over max array size
> --
>
> Key: ACCUMULO-4716
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4716
> Project: Accumulo
> Issue Type: Bug
>Reporter: Keith Turner
>Assignee: Mark Owens
> Labels: newbie, pull-request-available
> Fix For: 1.7.4, 1.8.2, 2.0.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> One might think you could do {{new byte\[Integer.MAX_VALUE\]}} in Java, but
> as I found when looking into ACCUMULO-4708 *suprise* you can't.
> According to the [stack overflow post |https://stackoverflow.com/a/8381338]
> {{new byte\[Integer.MAX_VALUE - 8\]}} should be safe. I was able to do up to
> {{new byte\[Integer.MAX_VALUE - 2\]}} in my local testing.
> When Accumulo caches a block it reads it into a byte array. For example this
> code in
> [CachableBlockFile.java|https://github.com/apache/accumulo/blob/rel/1.8.1/core/src/main/java/org/apache/accumulo/core/file/blockfile/impl/CachableBlockFile.java#L345]
> does this when {{_currBlock.getRawSize() <= cache.getMaxSize()}}.
> This code should ensure the size is less than {{min( cache.getMaxSize(),
> MAX_ARRAY_SIZE)}} inorder to read it into a byte array.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (ACCUMULO-4716) Do not attempt to cache blocks over max array size
[
https://issues.apache.org/jira/browse/ACCUMULO-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Owens resolved ACCUMULO-4716.
--
Resolution: Fixed
> Do not attempt to cache blocks over max array size
> --
>
> Key: ACCUMULO-4716
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4716
> Project: Accumulo
> Issue Type: Bug
>Reporter: Keith Turner
>Assignee: Mark Owens
> Labels: newbie, pull-request-available
> Fix For: 1.7.4, 1.8.2, 2.0.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> One might think you could do {{new byte\[Integer.MAX_VALUE\]}} in Java, but
> as I found when looking into ACCUMULO-4708 *suprise* you can't.
> According to the [stack overflow post |https://stackoverflow.com/a/8381338]
> {{new byte\[Integer.MAX_VALUE - 8\]}} should be safe. I was able to do up to
> {{new byte\[Integer.MAX_VALUE - 2\]}} in my local testing.
> When Accumulo caches a block it reads it into a byte array. For example this
> code in
> [CachableBlockFile.java|https://github.com/apache/accumulo/blob/rel/1.8.1/core/src/main/java/org/apache/accumulo/core/file/blockfile/impl/CachableBlockFile.java#L345]
> does this when {{_currBlock.getRawSize() <= cache.getMaxSize()}}.
> This code should ensure the size is less than {{min( cache.getMaxSize(),
> MAX_ARRAY_SIZE)}} inorder to read it into a byte array.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (ACCUMULO-4716) Do not attempt to cache blocks over max array size
[
https://issues.apache.org/jira/browse/ACCUMULO-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Owens updated ACCUMULO-4716:
-
Fix Version/s: 2.0.0
1.8.2
> Do not attempt to cache blocks over max array size
> --
>
> Key: ACCUMULO-4716
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4716
> Project: Accumulo
> Issue Type: Bug
>Reporter: Keith Turner
>Assignee: Mark Owens
> Labels: newbie, pull-request-available
> Fix For: 1.7.4, 1.8.2, 2.0.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> One might think you could do {{new byte\[Integer.MAX_VALUE\]}} in Java, but
> as I found when looking into ACCUMULO-4708 *suprise* you can't.
> According to the [stack overflow post |https://stackoverflow.com/a/8381338]
> {{new byte\[Integer.MAX_VALUE - 8\]}} should be safe. I was able to do up to
> {{new byte\[Integer.MAX_VALUE - 2\]}} in my local testing.
> When Accumulo caches a block it reads it into a byte array. For example this
> code in
> [CachableBlockFile.java|https://github.com/apache/accumulo/blob/rel/1.8.1/core/src/main/java/org/apache/accumulo/core/file/blockfile/impl/CachableBlockFile.java#L345]
> does this when {{_currBlock.getRawSize() <= cache.getMaxSize()}}.
> This code should ensure the size is less than {{min( cache.getMaxSize(),
> MAX_ARRAY_SIZE)}} inorder to read it into a byte array.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (ACCUMULO-4716) Do not attempt to cache blocks over max array size
[
https://issues.apache.org/jira/browse/ACCUMULO-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Owens updated ACCUMULO-4716:
-
Fix Version/s: 1.7.4
> Do not attempt to cache blocks over max array size
> --
>
> Key: ACCUMULO-4716
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4716
> Project: Accumulo
> Issue Type: Bug
>Reporter: Keith Turner
>Assignee: Mark Owens
> Labels: newbie, pull-request-available
> Fix For: 1.7.4
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> One might think you could do {{new byte\[Integer.MAX_VALUE\]}} in Java, but
> as I found when looking into ACCUMULO-4708 *suprise* you can't.
> According to the [stack overflow post |https://stackoverflow.com/a/8381338]
> {{new byte\[Integer.MAX_VALUE - 8\]}} should be safe. I was able to do up to
> {{new byte\[Integer.MAX_VALUE - 2\]}} in my local testing.
> When Accumulo caches a block it reads it into a byte array. For example this
> code in
> [CachableBlockFile.java|https://github.com/apache/accumulo/blob/rel/1.8.1/core/src/main/java/org/apache/accumulo/core/file/blockfile/impl/CachableBlockFile.java#L345]
> does this when {{_currBlock.getRawSize() <= cache.getMaxSize()}}.
> This code should ensure the size is less than {{min( cache.getMaxSize(),
> MAX_ARRAY_SIZE)}} inorder to read it into a byte array.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ACCUMULO-4716) Do not attempt to cache blocks over max array size
[
https://issues.apache.org/jira/browse/ACCUMULO-4716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202797#comment-16202797
]
Christopher Tubbs commented on ACCUMULO-4716:
-
Should this issue be closed now? I believe the fixVersion should be 1.7.4,
1.8.2, and 2.0.0. Please verify and update JIRA.
> Do not attempt to cache blocks over max array size
> --
>
> Key: ACCUMULO-4716
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4716
> Project: Accumulo
> Issue Type: Bug
>Reporter: Keith Turner
>Assignee: Mark Owens
> Labels: newbie, pull-request-available
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> One might think you could do {{new byte\[Integer.MAX_VALUE\]}} in Java, but
> as I found when looking into ACCUMULO-4708 *suprise* you can't.
> According to the [stack overflow post |https://stackoverflow.com/a/8381338]
> {{new byte\[Integer.MAX_VALUE - 8\]}} should be safe. I was able to do up to
> {{new byte\[Integer.MAX_VALUE - 2\]}} in my local testing.
> When Accumulo caches a block it reads it into a byte array. For example this
> code in
> [CachableBlockFile.java|https://github.com/apache/accumulo/blob/rel/1.8.1/core/src/main/java/org/apache/accumulo/core/file/blockfile/impl/CachableBlockFile.java#L345]
> does this when {{_currBlock.getRawSize() <= cache.getMaxSize()}}.
> This code should ensure the size is less than {{min( cache.getMaxSize(),
> MAX_ARRAY_SIZE)}} inorder to read it into a byte array.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ACCUMULO-4720) Replace use of WalkingSecurity with API
[ https://issues.apache.org/jira/browse/ACCUMULO-4720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202792#comment-16202792 ] Christopher Tubbs commented on ACCUMULO-4720: - Saw this was marked closed as duplicate, but not linked to a duplicate issue. Adding a link to ACCUMULO-4719, because I think that's what was intended. If there's another duplicate I missed, can add that later. > Replace use of WalkingSecurity with API > --- > > Key: ACCUMULO-4720 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4720 > Project: Accumulo > Issue Type: Sub-task > Components: test >Reporter: Michael Miller > > Randomwalk uses a class called WalkingSecurity all over the place. This > class extends o.a.a.server.security.SecurityOperation to make use of all its > static methods for testing permissions, getting user names, etc. > WalkingSecurity should be replaced with the public API SecurityOperations to > handle these tasks. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ACCUMULO-4721) Document rfile-info in the user manual
[ https://issues.apache.org/jira/browse/ACCUMULO-4721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tubbs updated ACCUMULO-4721: Affects Version/s: (was: 2.0.0) > Document rfile-info in the user manual > -- > > Key: ACCUMULO-4721 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4721 > Project: Accumulo > Issue Type: Bug >Affects Versions: 1.7.3, 1.8.1 >Reporter: Michael Wall >Priority: Trivial > Fix For: 1.7.4, 1.8.2, 2.0.0 > > > Currently the 'old school' PrintInfo is documented at > http://accumulo.apache.org/1.8/accumulo_user_manual.html#_tools > We should document the 'rfile-info' info which is easier to remember than > org.apache.accumulo.core.file.rfile.PrintInfo -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ACCUMULO-4721) Document rfile-info in the user manual
[ https://issues.apache.org/jira/browse/ACCUMULO-4721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tubbs updated ACCUMULO-4721: Fix Version/s: 2.0.0 1.8.2 1.7.4 > Document rfile-info in the user manual > -- > > Key: ACCUMULO-4721 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4721 > Project: Accumulo > Issue Type: Bug >Affects Versions: 1.7.3, 1.8.1 >Reporter: Michael Wall >Priority: Trivial > Fix For: 1.7.4, 1.8.2, 2.0.0 > > > Currently the 'old school' PrintInfo is documented at > http://accumulo.apache.org/1.8/accumulo_user_manual.html#_tools > We should document the 'rfile-info' info which is easier to remember than > org.apache.accumulo.core.file.rfile.PrintInfo -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ACCUMULO-4170) ClientConfiguration javadoc difficult to read
[ https://issues.apache.org/jira/browse/ACCUMULO-4170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tubbs updated ACCUMULO-4170: Fix Version/s: 2.0.0 1.8.2 1.7.4 > ClientConfiguration javadoc difficult to read > - > > Key: ACCUMULO-4170 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4170 > Project: Accumulo > Issue Type: Bug > Components: client, docs >Affects Versions: 1.7.1 >Reporter: Mike Drob >Assignee: Mark Owens >Priority: Trivial > Labels: newbie, pull-request-available > Fix For: 1.7.4, 1.8.2, 2.0.0 > > Time Spent: 2.5h > Remaining Estimate: 0h > > The docs displayed on > https://accumulo.apache.org/1.7/apidocs/org/apache/accumulo/core/client/ClientConfiguration.html#loadDefault%28%29 > are difficult to read because the list is displayed in-line. We could use > proper list formatting to improve readability. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (ACCUMULO-4409) Create a custom log4j AccumuloMonitorAppender
[
https://issues.apache.org/jira/browse/ACCUMULO-4409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202754#comment-16202754
]
Christopher Tubbs commented on ACCUMULO-4409:
-
[~elserj]: That's a strange error. I thought maybe it had to do with some
dependency version bumping done recently by [~milleruntime] and a behavior
change in a log4j dependency, but I could not reproduce with {{mvn clean
package -Dtest=AccumuloMonitorAppenderTest}} using Maven 3.3.9. It could also
be related to a log4j conflict with Maven 3.5.0 itself. I know they changed
some stuff with logging. I'll download and try with that.
> Create a custom log4j AccumuloMonitorAppender
> -
>
> Key: ACCUMULO-4409
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4409
> Project: Accumulo
> Issue Type: Sub-task
>Reporter: Christopher Tubbs
>Assignee: Christopher Tubbs
> Labels: release_notes
> Fix For: 2.0.0
>
> Time Spent: 6h
> Remaining Estimate: 0h
>
> The current AsyncSocketAppender was an improvement over the older log4j
> configuration options, but it did not fully satisfy the description in
> ACCUMULO-2343.
> What we really need is an appender which can be managed by configuration
> alone, without using code to reload it with new system properties when the
> location of the monitor changes.
> So, rather than having a ZK watcher reload the log4j system, the appender
> itself should internally detect the relocation of the monitor and adjust its
> behavior accordingly. That way, the configuration files do not need to refer
> to system properties for the hostname/port of the monitor, and there is no
> need to reload the log4j logging when things change.
> This will allow us to remove more custom log4j code, which gets us closer to
> users having the ability to use another implementation for the slf4j API
> (though this feature of logging to the monitor might not be available for
> other slf4j implementations, unless they support using log4j appenders).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (ACCUMULO-4409) Create a custom log4j AccumuloMonitorAppender
[
https://issues.apache.org/jira/browse/ACCUMULO-4409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202762#comment-16202762
]
Christopher Tubbs commented on ACCUMULO-4409:
-
I tried with Maven 3.5.0 (and, side note: the colorized output is awesome!),
but was not able to reproduce it at all.
The only line that could throw this is the call on line 177 to
{{childAppenders.nextElement()}}. However, we just verified on line 174 that it
was both non-null and that it has more elements, so it should not have thrown
that exception, unless maybe there was a multi-threading issue. If you can
reproduce with a full stack trace, that might help.
> Create a custom log4j AccumuloMonitorAppender
> -
>
> Key: ACCUMULO-4409
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4409
> Project: Accumulo
> Issue Type: Sub-task
>Reporter: Christopher Tubbs
>Assignee: Christopher Tubbs
> Labels: release_notes
> Fix For: 2.0.0
>
> Time Spent: 6h
> Remaining Estimate: 0h
>
> The current AsyncSocketAppender was an improvement over the older log4j
> configuration options, but it did not fully satisfy the description in
> ACCUMULO-2343.
> What we really need is an appender which can be managed by configuration
> alone, without using code to reload it with new system properties when the
> location of the monitor changes.
> So, rather than having a ZK watcher reload the log4j system, the appender
> itself should internally detect the relocation of the monitor and adjust its
> behavior accordingly. That way, the configuration files do not need to refer
> to system properties for the hostname/port of the monitor, and there is no
> need to reload the log4j logging when things change.
> This will allow us to remove more custom log4j code, which gets us closer to
> users having the ability to use another implementation for the slf4j API
> (though this feature of logging to the monitor might not be available for
> other slf4j implementations, unless they support using log4j appenders).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] ctubbsii commented on a change in pull request #6: ACCUMULO-4718 Add HADOOP_CONF_DIR to rw-local cp
ctubbsii commented on a change in pull request #6: ACCUMULO-4718 Add HADOOP_CONF_DIR to rw-local cp URL: https://github.com/apache/accumulo-testing/pull/6#discussion_r144427141 ## File path: bin/accumulo-testing ## @@ -229,7 +229,7 @@ rw-local) exit 1 fi build_shade_jar - java -Dlog4j.configuration="file:$log4j_config" -cp "$at_shaded_jar" "$randomwalk_main" "$at_props" "$2" + java -Dlog4j.configuration="file:$log4j_config" -cp "$at_shaded_jar:$HADOOP_CONF_DIR" "$randomwalk_main" "$at_props" "$2" Review comment: One way we can decouple this from specific environment variables (which may or may not exist), is to simply remove the `-cp` section, and set `CLASSPATH` above the call to `java`. Something like `export CLASSPATH="$at_shaded_jar:$CLASSPATH"` That way, the caller can simply set `CLASSPATH=/path/to/hadoop/confdir` prior to running the `accumulo-testing` command. We could also add a sanity check prior to running java to make sure that the `$CLASSPATH` contains a directory with `core-site.xml` and/or `hdfs-site.xml` (or whatever the Hadoop client configuration uses by default). This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] jmark99 commented on issue #306: ACCUMULO-4170 Clarify ClientConfiguration javadocs
jmark99 commented on issue #306: ACCUMULO-4170 Clarify ClientConfiguration javadocs URL: https://github.com/apache/accumulo/pull/306#issuecomment-336292989 Yes, @keith-turner , #307 has the correct documentation for 1.8. This documentation is also valid for the current master line of development. These was a slight modification to the loadDefaults() method between 1.7 and 1.8 that necessitated a small change to the documentation. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] keith-turner commented on issue #306: ACCUMULO-4170 Clarify ClientConfiguration javadocs
keith-turner commented on issue #306: ACCUMULO-4170 Clarify ClientConfiguration javadocs URL: https://github.com/apache/accumulo/pull/306#issuecomment-336292123 I can merge this. @jmark99 does #307 currently have the changes you want for 1.8? If so I will look at that when merging forward. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (ACCUMULO-4718) Accumulo-testing classes are broken
[ https://issues.apache.org/jira/browse/ACCUMULO-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Tubbs updated ACCUMULO-4718: Component/s: test > Accumulo-testing classes are broken > --- > > Key: ACCUMULO-4718 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4718 > Project: Accumulo > Issue Type: Bug > Components: test >Reporter: Michael Miller >Assignee: Michael Miller > Labels: pull-request-available > Fix For: 2.0.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Multiple changes to 2.0 over the past 6 months or so have been left out of > the accumulo-testing repo. Update the testing classes with these changes so > they can be run against 2.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] jmark99 commented on issue #306: ACCUMULO-4170 Clarify ClientConfiguration javadocs
jmark99 commented on issue #306: ACCUMULO-4170 Clarify ClientConfiguration javadocs URL: https://github.com/apache/accumulo/pull/306#issuecomment-336289581 Thanks @keith-turner. I've rendered the javadocs for all versions on my local machine and they render correctly. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] jmark99 commented on a change in pull request #306: ACCUMULO-4170 Clarify ClientConfiguration javadocs
jmark99 commented on a change in pull request #306: ACCUMULO-4170 Clarify
ClientConfiguration javadocs
URL: https://github.com/apache/accumulo/pull/306#discussion_r144411823
##
File path:
core/src/main/java/org/apache/accumulo/core/client/ClientConfiguration.java
##
@@ -199,15 +199,23 @@ public ClientConfiguration(Configuration... configs) {
}
/**
- * Attempts to load a configuration file from the system. Uses the
"ACCUMULO_CLIENT_CONF_PATH" environment variable, split on File.pathSeparator,
for a list
- * of target files. If not set, uses the following in this order-
~/.accumulo/config $ACCUMULO_CONF_DIR/client.conf -OR-
$ACCUMULO_HOME/conf/client.conf
- * (depending on whether $ACCUMULO_CONF_DIR is set) /etc/accumulo/client.conf
+ * Attempts to load a configuration file from the system using the default
search paths. Uses the ACCUMULO_CLIENT_CONF_PATH environment variable,
+ * split on File.pathSeparator, for a list of target files.
+ *
+ * If ACCUMULO_CLIENT_CONF_PATH is not set, uses the following in
this order:
+ *
+ * ~/.accumulo/config
+ * either:
+ *
+ * $ACCUMULO_CONF_DIR/client.conf, if
$ACCUMULO_CONF_DIR is defined.
+ * $ACCUMULO_HOME/conf/client.conf, otherwise.
+ *
+ * /etc/accumulo/client.conf
+ * /etc/accumulo/conf/client.conf
+ *
+ *
*
- * A client configuration will then be read from each location using
PropertiesConfiguration to construct a configuration. That means the latest
item will be
- * the one in the configuration.
- *
- * @see PropertiesConfiguration
- * @see File#pathSeparator
+ * @since 1.6.0
Review comment:
Thanks for the catch! I realized I had inadvertently removed a line of
documentation when I was performing the previous revision.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] keith-turner commented on a change in pull request #306: ACCUMULO-4170 Clarify ClientConfiguration javadocs
keith-turner commented on a change in pull request #306: ACCUMULO-4170 Clarify
ClientConfiguration javadocs
URL: https://github.com/apache/accumulo/pull/306#discussion_r144407156
##
File path:
core/src/main/java/org/apache/accumulo/core/client/ClientConfiguration.java
##
@@ -199,15 +199,23 @@ public ClientConfiguration(Configuration... configs) {
}
/**
- * Attempts to load a configuration file from the system. Uses the
"ACCUMULO_CLIENT_CONF_PATH" environment variable, split on File.pathSeparator,
for a list
- * of target files. If not set, uses the following in this order-
~/.accumulo/config $ACCUMULO_CONF_DIR/client.conf -OR-
$ACCUMULO_HOME/conf/client.conf
- * (depending on whether $ACCUMULO_CONF_DIR is set) /etc/accumulo/client.conf
+ * Attempts to load a configuration file from the system using the default
search paths. Uses the ACCUMULO_CLIENT_CONF_PATH environment variable,
+ * split on File.pathSeparator, for a list of target files.
+ *
+ * If ACCUMULO_CLIENT_CONF_PATH is not set, uses the following in
this order:
+ *
+ * ~/.accumulo/config
+ * either:
+ *
+ * $ACCUMULO_CONF_DIR/client.conf, if
$ACCUMULO_CONF_DIR is defined.
+ * $ACCUMULO_HOME/conf/client.conf, otherwise.
+ *
+ * /etc/accumulo/client.conf
+ * /etc/accumulo/conf/client.conf
+ *
+ *
*
- * A client configuration will then be read from each location using
PropertiesConfiguration to construct a configuration. That means the latest
item will be
- * the one in the configuration.
- *
- * @see PropertiesConfiguration
- * @see File#pathSeparator
+ * @since 1.6.0
Review comment:
This since tag is not needed because its the same as the class level since
tag. Methods inherit the since tag from the class. Only need to set it on
method if it differs from class since tag.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
[GitHub] ctubbsii commented on issue #220: ACCUMULO-4591 replication latency metrics added
ctubbsii commented on issue #220: ACCUMULO-4591 replication latency metrics added URL: https://github.com/apache/accumulo/pull/220#issuecomment-336260108 Closing this, as it was superseded by #305 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] ctubbsii closed pull request #220: ACCUMULO-4591 replication latency metrics added
ctubbsii closed pull request #220: ACCUMULO-4591 replication latency metrics added URL: https://github.com/apache/accumulo/pull/220 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (ACCUMULO-4718) Accumulo-testing classes are broken
[ https://issues.apache.org/jira/browse/ACCUMULO-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated ACCUMULO-4718: - Labels: pull-request-available (was: ) > Accumulo-testing classes are broken > --- > > Key: ACCUMULO-4718 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4718 > Project: Accumulo > Issue Type: Bug >Reporter: Michael Miller >Assignee: Michael Miller > Labels: pull-request-available > Fix For: 2.0.0 > > > Multiple changes to 2.0 over the past 6 months or so have been left out of > the accumulo-testing repo. Update the testing classes with these changes so > they can be run against 2.0 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] milleruntime opened a new pull request #6: ACCUMULO-4718 Add HADOOP_CONF_DIR to rw-local cp
milleruntime opened a new pull request #6: ACCUMULO-4718 Add HADOOP_CONF_DIR to rw-local cp URL: https://github.com/apache/accumulo-testing/pull/6 The test "rw-local Bulk.xml" was throwing errors because it couldn't find the HDFS containing the files to import. The hadoop conf wasn't on the classpath so it was defaulting to the disk "file:///" file system. This doesn't seem to affect the rest of the tests. Not sure if this is the best place to include HADOOP_CONF_DIR... This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
Accumulo-1.8 - Build # 227 - Fixed
The Apache Jenkins build system has built Accumulo-1.8 (build #227) Status: Fixed Check console output at https://builds.apache.org/job/Accumulo-1.8/227/ to view the results.
Accumulo-Master - Build # 2166 - Failure
The Apache Jenkins build system has built Accumulo-Master (build #2166) Status: Failure Check console output at https://builds.apache.org/job/Accumulo-Master/2166/ to view the results.
[jira] [Updated] (ACCUMULO-4722) Use Objects.equal in Pair equals method
[
https://issues.apache.org/jira/browse/ACCUMULO-4722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Turner updated ACCUMULO-4722:
---
Description: I think {{org.apache.accumulo.core.util.Pair.equals()}} could
call {{Objects.equal()}} and the private internal method that does and equality
check could be dropped. Need to verify the changes will have the same behavior
for null. (was: I think org.apache.accumulo.core.util.Pair.equals() could call
Objects.equal() and the private internal method that does and equality check
could be dropped. Need to verify the changes will have the same behavior for
null.)
> Use Objects.equal in Pair equals method
> ---
>
> Key: ACCUMULO-4722
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4722
> Project: Accumulo
> Issue Type: Improvement
>Reporter: Keith Turner
> Labels: newbie
>
> I think {{org.apache.accumulo.core.util.Pair.equals()}} could call
> {{Objects.equal()}} and the private internal method that does and equality
> check could be dropped. Need to verify the changes will have the same
> behavior for null.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (ACCUMULO-4722) Use Objects.equal in Pair equals method
Keith Turner created ACCUMULO-4722: -- Summary: Use Objects.equal in Pair equals method Key: ACCUMULO-4722 URL: https://issues.apache.org/jira/browse/ACCUMULO-4722 Project: Accumulo Issue Type: Improvement Reporter: Keith Turner I think org.apache.accumulo.core.util.Pair.equals() could call Objects.equal() and the private internal method that does and equality check could be dropped. Need to verify the changes will have the same behavior for null. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] adamjshook commented on issue #220: ACCUMULO-4591 replication latency metrics added
adamjshook commented on issue #220: ACCUMULO-4591 replication latency metrics added URL: https://github.com/apache/accumulo/pull/220#issuecomment-336228003 This PR can be closed with #305 being merged. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
Accumulo-1.8 - Build # 226 - Failure
The Apache Jenkins build system has built Accumulo-1.8 (build #226) Status: Failure Check console output at https://builds.apache.org/job/Accumulo-1.8/226/ to view the results.
[GitHub] keith-turner commented on a change in pull request #306: ACCUMULO-4170 Clarify ClientConfiguration javadocs
keith-turner commented on a change in pull request #306: ACCUMULO-4170 Clarify ClientConfiguration javadocs URL: https://github.com/apache/accumulo/pull/306#discussion_r144368491 ## File path: core/src/main/java/org/apache/accumulo/core/client/ClientConfiguration.java ## @@ -41,7 +41,22 @@ /** * Contains a list of property keys recognized by the Accumulo client and convenience methods for setting them. - * + * + * When loading a configuration file from the system, Accumulo uses the ACCUMULO_CLIENT_CONF_PATH environment variable, Review comment: > One for the 1.7 change and another for the 1.8 change and then the 1.8 change will be merged forward to 2.0? So you want the changes in 1.8 to be slightly different? If so it would be nice to end up with the following on 1.8 branch. * Your commit with 1.8 changes * Merge commit with your changes from 1.7 * Your 1.7 commit Lets go for the easiest way to get to those changes. Lets get the changes in 1.7 squared away and then we can get the 1.8 changes figured out. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
Accumulo-1.7 - Build # 384 - Unstable
The Apache Jenkins build system has built Accumulo-1.7 (build #384) Status: Unstable Check console output at https://builds.apache.org/job/Accumulo-1.7/384/ to view the results.
Accumulo-1.7 - Build # 385 - Failure
The Apache Jenkins build system has built Accumulo-1.7 (build #385) Status: Failure Check console output at https://builds.apache.org/job/Accumulo-1.7/385/ to view the results.
[GitHub] jmark99 commented on a change in pull request #306: ACCUMULO-4170 Clarify ClientConfiguration javadocs
jmark99 commented on a change in pull request #306: ACCUMULO-4170 Clarify ClientConfiguration javadocs URL: https://github.com/apache/accumulo/pull/306#discussion_r144362198 ## File path: core/src/main/java/org/apache/accumulo/core/client/ClientConfiguration.java ## @@ -41,7 +41,22 @@ /** * Contains a list of property keys recognized by the Accumulo client and convenience methods for setting them. - * + * + * When loading a configuration file from the system, Accumulo uses the ACCUMULO_CLIENT_CONF_PATH environment variable, Review comment: Sounds good. I'll update to make the adjustments. So if I understand you correctly I will only need 2 PR's. One for the 1.7 change and another for the 1.8 change and then the 1.8 change will be merged forward to 2.0? Thanks. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] keith-turner commented on a change in pull request #306: ACCUMULO-4170 Clarify ClientConfiguration javadocs
keith-turner commented on a change in pull request #306: ACCUMULO-4170 Clarify ClientConfiguration javadocs URL: https://github.com/apache/accumulo/pull/306#discussion_r144360720 ## File path: core/src/main/java/org/apache/accumulo/core/client/ClientConfiguration.java ## @@ -41,7 +41,22 @@ /** * Contains a list of property keys recognized by the Accumulo client and convenience methods for setting them. - * + * + * When loading a configuration file from the system, Accumulo uses the ACCUMULO_CLIENT_CONF_PATH environment variable, Review comment: > It can be moved back into the method call only if you think that would be more appropriate. Personally I would put the docs on the loadDefault method and then any constuctors that call load default I would state in the constuctors javadoc that it follows the search behavior described in loadDefatult using s javadoc link. If the docs are at the class level, I think the class level docs would need to detail which constuctors and methods do and/or do not follow the search behavior. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] jmark99 commented on issue #304: ACCUMULO-4716 Don't cache blks over max array size
jmark99 commented on issue #304: ACCUMULO-4716 Don't cache blks over max array size URL: https://github.com/apache/accumulo/pull/304#issuecomment-336212445 Thanks, Keith. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] keith-turner commented on issue #304: ACCUMULO-4716 Don't cache blks over max array size
keith-turner commented on issue #304: ACCUMULO-4716 Don't cache blks over max array size URL: https://github.com/apache/accumulo/pull/304#issuecomment-336211364 @jmark99 thanks for the contribution. I squashed these commits and cherry picked them back to 1.7 in commit 6ead4740dbc24485b51d73d0a006d44bb2f52833. I then merged the changes forward in commits ae3aa10027cc0926cd5b319d31bc3fd005ffb50f and 47d13beff82e547019faf551e9bdc76c4429e576. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] keith-turner closed pull request #304: ACCUMULO-4716 Don't cache blks over max array size
keith-turner closed pull request #304: ACCUMULO-4716 Don't cache blks over max array size URL: https://github.com/apache/accumulo/pull/304 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] jmark99 commented on a change in pull request #306: ACCUMULO-4170 Clarify ClientConfiguration javadocs
jmark99 commented on a change in pull request #306: ACCUMULO-4170 Clarify ClientConfiguration javadocs URL: https://github.com/apache/accumulo/pull/306#discussion_r144357873 ## File path: core/src/main/java/org/apache/accumulo/core/client/ClientConfiguration.java ## @@ -41,7 +41,22 @@ /** * Contains a list of property keys recognized by the Accumulo client and convenience methods for setting them. - * + * + * When loading a configuration file from the system, Accumulo uses the ACCUMULO_CLIENT_CONF_PATH environment variable, Review comment: Not all the constructors do the search. The described behavior occurs when load configurations use a default load path. Previously the path order was described only in the method. I moved it up to class level based upon the suggestion given by @madrob in the ticket comment. It can be moved back into the method call only if you think that would be more appropriate. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] jmark99 commented on issue #307: ACCUMULO-4170 Clarify ClientConfiguration javadocs
jmark99 commented on issue #307: ACCUMULO-4170 Clarify ClientConfiguration javadocs URL: https://github.com/apache/accumulo/pull/307#issuecomment-336207583 The change for 1.8 is slightly different than for 1.7. Although the 1.8 and 2.0 changes are identical so the #307 could be merged forward. I wasn't sure how that situation was handled so I ended up creating a pull request for master as well. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (ACCUMULO-4591) Replication Latency Metrics2
[ https://issues.apache.org/jira/browse/ACCUMULO-4591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated ACCUMULO-4591: - Fix Version/s: 1.8.2 1.7.4 > Replication Latency Metrics2 > > > Key: ACCUMULO-4591 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4591 > Project: Accumulo > Issue Type: Improvement >Reporter: Noe >Assignee: Adam J Shook > Labels: pull-request-available > Fix For: 1.7.4, 1.8.2, 2.0.0 > > Attachments: Screen Shot 2017-02-23 at 9.31.06 AM.png > > Time Spent: 5h 40m > Remaining Estimate: 0h > > Currently Files Pending Replication is the only available insight to the > state of replication. Latency of replication has been a great concern. > Without a latency metric users can not determine what configuration settings > either reduce or increase replication latency. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Updated] (ACCUMULO-4591) Replication Latency Metrics2
[ https://issues.apache.org/jira/browse/ACCUMULO-4591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Josh Elser updated ACCUMULO-4591: - Resolution: Fixed Status: Resolved (was: Patch Available) > Replication Latency Metrics2 > > > Key: ACCUMULO-4591 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4591 > Project: Accumulo > Issue Type: Improvement >Reporter: Noe >Assignee: Adam J Shook > Labels: pull-request-available > Fix For: 1.7.4, 1.8.2, 2.0.0 > > Attachments: Screen Shot 2017-02-23 at 9.31.06 AM.png > > Time Spent: 5h 40m > Remaining Estimate: 0h > > Currently Files Pending Replication is the only available insight to the > state of replication. Latency of replication has been a great concern. > Without a latency metric users can not determine what configuration settings > either reduce or increase replication latency. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] asfgit closed pull request #305: [ACCUMULO-4591] Add replication latency metrics
asfgit closed pull request #305: [ACCUMULO-4591] Add replication latency metrics URL: https://github.com/apache/accumulo/pull/305 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Reopened] (ACCUMULO-4409) Create a custom log4j AccumuloMonitorAppender
[
https://issues.apache.org/jira/browse/ACCUMULO-4409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser reopened ACCUMULO-4409:
--
{noformat}
Tests run: 3, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.272 sec <<<
FAILURE! - in org.apache.accumulo.monitor.util.AccumuloMonitorAppenderTest
testMonitorTracker(org.apache.accumulo.monitor.util.AccumuloMonitorAppenderTest)
Time elapsed: 0.121 sec <<< ERROR!
java.util.NoSuchElementException: Vector Enumeration
at
org.apache.accumulo.monitor.util.AccumuloMonitorAppenderTest.verifyAppender(AccumuloMonitorAppenderTest.java:177)
at
org.apache.accumulo.monitor.util.AccumuloMonitorAppenderTest.updateLocAndVerify(AccumuloMonitorAppenderTest.java:166)
at
org.apache.accumulo.monitor.util.AccumuloMonitorAppenderTest.testMonitorTracker(AccumuloMonitorAppenderTest.java:149)
{noformat}
{noformat}
Apache Maven 3.5.0 (ff8f5e7444045639af65f6095c62210b5713f426;
2017-04-03T15:39:06-04:00)
Maven home: /usr/local/Cellar/maven/3.5.0/libexec
Java version: 1.8.0_131, vendor: Oracle Corporation
Java home: /Library/Java/JavaVirtualMachines/jdk1.8.0_131.jdk/Contents/Home/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "10.11.6", arch: "x86_64", family: "mac"
{noformat}
[~ctubbsii] this test failed for me on Master. Could you please look into it?
> Create a custom log4j AccumuloMonitorAppender
> -
>
> Key: ACCUMULO-4409
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4409
> Project: Accumulo
> Issue Type: Sub-task
>Reporter: Christopher Tubbs
>Assignee: Christopher Tubbs
> Labels: release_notes
> Fix For: 2.0.0
>
> Time Spent: 6h
> Remaining Estimate: 0h
>
> The current AsyncSocketAppender was an improvement over the older log4j
> configuration options, but it did not fully satisfy the description in
> ACCUMULO-2343.
> What we really need is an appender which can be managed by configuration
> alone, without using code to reload it with new system properties when the
> location of the monitor changes.
> So, rather than having a ZK watcher reload the log4j system, the appender
> itself should internally detect the relocation of the monitor and adjust its
> behavior accordingly. That way, the configuration files do not need to refer
> to system properties for the hostname/port of the monitor, and there is no
> need to reload the log4j logging when things change.
> This will allow us to remove more custom log4j code, which gets us closer to
> users having the ability to use another implementation for the slf4j API
> (though this feature of logging to the monitor might not be available for
> other slf4j implementations, unless they support using log4j appenders).
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] keith-turner commented on issue #307: ACCUMULO-4170 Clarify ClientConfiguration javadocs
keith-turner commented on issue #307: ACCUMULO-4170 Clarify ClientConfiguration javadocs URL: https://github.com/apache/accumulo/pull/307#issuecomment-336189538 Is this the same change as #306? We usually make the change in the oldest branch and then merge it forward. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] keith-turner commented on a change in pull request #306: ACCUMULO-4170 Clarify ClientConfiguration javadocs
keith-turner commented on a change in pull request #306: ACCUMULO-4170 Clarify ClientConfiguration javadocs URL: https://github.com/apache/accumulo/pull/306#discussion_r144339507 ## File path: core/src/main/java/org/apache/accumulo/core/client/ClientConfiguration.java ## @@ -41,7 +41,22 @@ /** * Contains a list of property keys recognized by the Accumulo client and convenience methods for setting them. - * + * + * When loading a configuration file from the system, Accumulo uses the ACCUMULO_CLIENT_CONF_PATH environment variable, Review comment: Does the behavior described here only happen when calling `loadDefault()`? Or do all of the constuctors do this search? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] jmark99 opened a new pull request #308: ACCUMULO-4170 Clarify ClientConfiguration javadocs
jmark99 opened a new pull request #308: ACCUMULO-4170 Clarify ClientConfiguration javadocs URL: https://github.com/apache/accumulo/pull/308 ACCUMULO-4170 Clarify ClientConfiguration javadocs Updated the javadoc information with the ClientConfiguration class. Specifically reworked the default search path information to be displayed as a list rather than inline, thereby easing readability. Additionally moved the search path list to the class level vice the method level.   This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] jmark99 opened a new pull request #307: ACCUMULO-4170 Clarify ClientConfiguration javadocs
jmark99 opened a new pull request #307: ACCUMULO-4170 Clarify ClientConfiguration javadocs URL: https://github.com/apache/accumulo/pull/307 ACCUMULO-4170 Clarify ClientConfiguration javadocs Updated the javadoc information with the ClientConfiguration class. Specifically reworked the default search path information to be displayed as a list rather than inline, thereby easing readability. Reworded a few of the sentences and moved the path order up to the class level rather than the method level.   This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[jira] [Updated] (ACCUMULO-4170) ClientConfiguration javadoc difficult to read
[ https://issues.apache.org/jira/browse/ACCUMULO-4170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated ACCUMULO-4170: - Labels: newbie pull-request-available (was: newbie) > ClientConfiguration javadoc difficult to read > - > > Key: ACCUMULO-4170 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4170 > Project: Accumulo > Issue Type: Bug > Components: client, docs >Affects Versions: 1.7.1 >Reporter: Mike Drob >Assignee: Mark Owens >Priority: Trivial > Labels: newbie, pull-request-available > > The docs displayed on > https://accumulo.apache.org/1.7/apidocs/org/apache/accumulo/core/client/ClientConfiguration.html#loadDefault%28%29 > are difficult to read because the list is displayed in-line. We could use > proper list formatting to improve readability. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[GitHub] jmark99 opened a new pull request #306: ACCUMULO-4170 Clarify ClientConfiguration javadocs
jmark99 opened a new pull request #306: ACCUMULO-4170 Clarify ClientConfiguration javadocs URL: https://github.com/apache/accumulo/pull/306 ACCUMULO-4170 Clarify ClientConfiguration javadocs Updated the javadoc information with the ClientConfiguration class. Specifically reworked the default search path information to be displayed as a list rather than inline, thereby easing readability. Reworded a few of the sentences and moved the path order up to the class level rather than the method level.   This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
