On Feb. 25, 2014, 9:01 a.m., Bill Havanki wrote:
src/server/src/main/java/org/apache/accumulo/server/test/continuous/ContinuousUtil.java,
line 46
https://reviews.apache.org/r/18444/diff/1/?file=502880#file502880line46
What if, due to the cluster environment, it always takes
On Feb. 25, 2014, 12:23 a.m., Sean Busbey wrote:
Is there a disadvantage to instead updating the README to require creating
the table ahead of time? That way we could avoid this code, and we could
remove the table creation code from the writers.
As a side effect, there'd also be a
On Feb. 25, 2014, 12:23 a.m., Sean Busbey wrote:
Is there a disadvantage to instead updating the README to require creating
the table ahead of time? That way we could avoid this code, and we could
remove the table creation code from the writers.
As a side effect, there'd also be a
On Feb. 25, 2014, 12:23 a.m., Sean Busbey wrote:
Is there a disadvantage to instead updating the README to require creating
the table ahead of time? That way we could avoid this code, and we could
remove the table creation code from the writers.
As a side effect, there'd also be a
On Feb. 25, 2014, 12:23 a.m., Sean Busbey wrote:
Is there a disadvantage to instead updating the README to require creating
the table ahead of time? That way we could avoid this code, and we could
remove the table creation code from the writers.
As a side effect, there'd also be a
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/18467/
---
Review request for accumulo.
Bugs: ACCUMULO-2404
On Feb. 24, 2014, 7:23 p.m., Sean Busbey wrote:
Is there a disadvantage to instead updating the README to require creating
the table ahead of time? That way we could avoid this code, and we could
remove the table creation code from the writers.
As a side effect, there'd also be a
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/18467/#review35424
---
Ship it!
Ship It!
- Bill Havanki
On Feb. 25, 2014, 11:49 a.m.,
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/18438/
---
Review request for accumulo.
Repository: accumulo
Description
---
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/18438/#review35427
---
bin/bootstrap_config.sh
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/18438/
---
(Updated Feb. 25, 2014, 6:36 p.m.)
Review request for accumulo.
Changes
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/18444/
---
(Updated Feb. 25, 2014, 8:46 p.m.)
Review request for accumulo.
Changes
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/18444/#review35467
---
Aside: it's also probably worth verifying that when you do create
On Tue, Feb 25, 2014 at 2:16 PM, Mike Drob mad...@cloudera.com wrote:
What is the recommended way to disable tracing on a cluster? I tried just
killing my tracers, but now my tablet servers are spamming the monitor logs
with ConnectionRefused exceptions. A cleaner method to do this would be
Try removing the tracer's entry in zookeeper.
The spamming should have stopped when the ephemeral node advertising the
tracer's location expired.
-Eric
On Tue, Feb 25, 2014 at 4:27 PM, Sean Busbey busbey+li...@cloudera.comwrote:
On Tue, Feb 25, 2014 at 2:16 PM, Mike Drob mad...@cloudera.com
I ran a utility [1] to analyze API diffs [2] between 1.5.0 and 1.5.1-RC3.
The configs I used are the two xml files in the parent [3] of the report.
I think the diff looks ok. I used jars from 1.5.0 and 1.5.1-RC3 bin.tar.gz.
[1] : http://ispras.linuxbase.org/index.php/Java_API_Compliance_Checker
Thanks for running that checker, Keith. Should we not be worried about the
removal of InputFormatBase.RangeInputSplit? If I read correctly this will
break both binary (runtime) compatibility and code (compile-time)
compatibility. Can somebody make an argument for why this is not a problem
in a
Will it? Clients don't interact with that code at all directly.
On Tue, Feb 25, 2014 at 5:57 PM, Adam Fuchs afu...@apache.org wrote:
Thanks for running that checker, Keith. Should we not be worried about the
removal of InputFormatBase.RangeInputSplit? If I read correctly this will
break both
I haven't checked what would happen. If you subclassed the
RangeInputSplit, it's rather likely that you'd need a recompilation.
On 2/25/14, 5:59 PM, John Vines wrote:
Will it? Clients don't interact with that code at all directly.
On Tue, Feb 25, 2014 at 5:57 PM, Adam Fuchs afu...@apache.org
I don't know that this inner class used for M/R should be considered
public API... nor do I imagine it will cause compatibility problems if
users aren't referencing it in their code (which there's no reason to
expect them to). I don't know if anybody is subclassing
RangeInputSplit, but I'd suspect
Seems reasonable to update these tentatively in JIRA... but I hope
1.6.0 is out before the end of March.
I would say that the the 1.4.5 release will probably not benefit from
1.5.1's lessons learned much, though. A lot of work went into
simplifying/automating the release process in 1.5.0 that I
I'll buy that the RangeInputSplit is probably not referenced directly in
user code. In this case it's probably not a big enough change to delay the
release.
Adam
On Feb 25, 2014 6:19 PM, Christopher ctubb...@apache.org wrote:
I don't know that this inner class used for M/R should be considered
22 matches
Mail list logo
