:
> On Mon, Jan 25, 2016 at 10:59 AM, John Vines wrote:
>
> > Of course, it's when I hit send that I realize that we could mitigate by
> > making the client aware of the master state, and if the system is shut
> down
> >
>
> Thats a good idea. Should consider t
Of course, it's when I hit send that I realize that we could mitigate by
making the client aware of the master state, and if the system is shut down
(which was the case for that ticket), then it can fail quickly with a
descriptive message.
On Mon, Jan 25, 2016 at 10:58 AM John Vines
While we want to be fault tolerant, there's a point where we want to
eventually fail. I know we have a couple never ending retry loops that need
to be addressed (https://issues.apache.org/jira/browse/ACCUMULO-1268), but
I'm unsure if queries suffer from this problem.
Unfortunately, fault tolerance
+1
On Fri, Jan 8, 2016 at 12:58 PM Keith Turner wrote:
> +1
>
> On Fri, Jan 8, 2016 at 12:24 PM, Josh Elser wrote:
>
> > Hi,
> >
> > Per the other thread "Yetus Accumulo 'Personality'" [1], I'd like to see
> > what people think about turning this on by default.
> >
> > I've been talking to Sean
+1, license and notify issues resolved (agreed that ACCUMULO-4003 isn't a
blocker)
On Fri, Sep 18, 2015 at 1:40 PM Sean Busbey wrote:
> +1
>
> * checked sigs
> * checked hashs
> * verified src tarball matches RC tag
> * verified all LICENSE and NOTICE files (hit ACCUMULO-4003, but it's a
> minor
-1
I'm with Sean on this one. Ignoring now known licensing issues because we
hadn't handled them in the past is not a valid excuse.
On Thu, Sep 10, 2015 at 2:27 PM Sean Busbey wrote:
> As members of the PMC, we're required to verify all releases we approve of
> meet ASF licensing policy[1], so
README in the top of the testing module?
On Tue, Jul 7, 2015 at 12:18 PM Josh Elser wrote:
> I committed https://issues.apache.org/jira/browse/ACCUMULO-3929 yesterday.
>
> Had a thought today that it might be beneficial to write down how it
> works somewhere, but I don't know where would be best
This may be tangential, but I heard the scripts for hadoop 3 had a massive
rewrite. Perhaps they can be consulted for desired behavior?
On Fri, Jun 26, 2015 at 2:03 PM Eric Newton wrote:
> Our ops people use the "start-here.sh" scripts to bring services back up
> after failures. That's a great
I would attach cat pictures but the email aliases strips them off.
Aside from that, sounds good.
On Wed, Apr 15, 2015 at 3:22 PM Josh Elser wrote:
> End of week? Any objections/complaints/opinions/cat-pictures?
>
> I'm thinking our branches would then look like
>
> 1.5 -> 1.5.3-SNAPSHOT
> 1.6 -
Yup, they look like they don't belong there.
On Thu, Feb 19, 2015 at 1:06 PM, Srikanth Viswanathan
wrote:
> There appears to be redundant code in the ZKAuthorizor's
> 'initializeSecurity' method. It's initializing a bunch of permissions
> that are unnecessary in the authorizor. The code seems to
ZooKeeper should always be done in odd quantities. For such a small
cluster, you may just want to dual purpose your workers as zk nodes though.
I really can't say more without knowing more about the underlying hardware.
On Tue, Jan 13, 2015 at 4:08 AM, panqing...@163.com
wrote:
> HI
>
> I want t
Another option is to change the default port in your accumulo-site.xml file
(master.port.client) to a port that isn't being hit by that scan.
On Tue, Jan 13, 2015 at 10:41 AM, John Vines wrote:
> This is an indicator that something is hitting that port with a different
> protocol. Ma
This is an indicator that something is hitting that port with a different
protocol. Make sure you don't have anything doing port scanning,
particularly for the default ports (monitor is ). Be aware, then some
pre-packaged hadoop releases do have monitoring software that may be doing
this.
On T
+1
On Wed, Jan 7, 2015 at 3:12 PM, Christopher wrote:
> To make it easier to apply some minimal checkstyle rules for ACCUMULO-3451,
> I'm announcing my intentions to do a full, one-time, auto-format and
> organize imports on all our supported branches (1.5, 1.6, and master) to
> bring us up to s
I share sentiments with Josh. I'm all for a more universally supported
standard. Going back down to 100 characters feels limiting and I'm not a
fan, but I'm not going to let that stop me.
On Tue, Dec 23, 2014 at 1:36 PM, Josh Elser wrote:
>
> Thanks for taking the time to do this. I know it can b
ional permissions to ensure not just
> > everybody can perform this action? With a check to verify that the same
> > iterators exist on the destination table that existed on the source table?
>
> John Vines wrote:
> I see your concerns no different as those for a
ional permissions to ensure not just
> > everybody can perform this action? With a check to verify that the same
> > iterators exist on the destination table that existed on the source table?
>
> John Vines wrote:
> I see your concerns no different as those for a
ional permissions to ensure not just
> > everybody can perform this action? With a check to verify that the same
> > iterators exist on the destination table that existed on the source table?
>
> John Vines wrote:
> I see your concerns no different as those for a
ional permissions to ensure not just
> > everybody can perform this action? With a check to verify that the same
> > iterators exist on the destination table that existed on the source table?
>
> John Vines wrote:
> I see your concerns no different as those for a
offline? If not, then the splits could change during
> > this operation.
>
> John Vines wrote:
> They are not, but this isn't an issue. The locks prevent a merge and the
> bulk import code we're utilizing handles tablets splitting mid-operation.
>
> kturner
as those for a standard bulk import. And these
concerns are currently handled by the user doing the bulk import needs to be
aware of the data they're calling the command on.
- John
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/27198/#review658
some oversights in it
- John Vines
On Dec. 22, 2014, 7:59 p.m., John Vines wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.a
REATION
Diff: https://reviews.apache.org/r/27198/diff/
Testing
---
Includes CloneIntoIT, which exercises all permutations of the flags. Existing
BulkIT still functions as intended for validation of no feature loss in
refactoring exiting code for multi-purposing.
Thanks,
John Vines
est/functional/CloneIntoIT.java
PRE-CREATION
Diff: https://reviews.apache.org/r/27198/diff/
Testing
---
Includes CloneIntoIT, which exercises all permutations of the flags. Existing
BulkIT still functions as intended for validation of no feature loss in
refactoring exiting code for multi-purposing.
; this operation.
They are not, but this isn't an issue. The locks prevent a merge and the bulk
import code we're utilizing handles tablets splitting mid-operation.
On Oct. 30, 2014, 4:06 p.m., John Vines wrote:
> > I have only reviewed the FATE ops so far. How will this work w/
>
The ip the processes inside docker resolve to need to be resolveable from
outside docker, which iirc, is not something easily achieved in Docker.
On Mon, Dec 15, 2014 at 6:54 PM, David Medinets
wrote:
>
> Can I use the accumulo shell with the MiniAccumuloCluster? That's an
> interesting idea. I d
glib, but it reads like your suggestion to Jeremy for when
> >>>>>> we
> >>>>>> have a 2.0.0 release (assuming semver passes) is to take option (2)
> >>>>>> Don't
> >>>>>> upgrade Accumulo.
> >>&g
Wouldn't this be resolved with our SemVer sqwitch?
On Thu, Dec 11, 2014 at 11:36 AM, Kepner, Jeremy - 0553 - MITLL <
kep...@ll.mit.edu> wrote:
> When we remove functions, do we have any official guidance to our users
> who may have built applications that use those functions?
>
> Right now, the o
Adam, the vote isn't for 2.0.0, it's for all future releases. Can you
please clarify your vote?
On Tue, Dec 9, 2014 at 3:40 PM, Adam Fuchs wrote:
> +1 for semver version 2.0.0
>
> Assuming this passes, let's make sure we grab a copy for posterity and
> post it on our site.
>
> Adam
>
> On Tue, D
+1
On Tue, Dec 9, 2014 at 1:30 PM, Keith Turner wrote:
> +1
>
> On Tue, Dec 9, 2014 at 1:23 PM, Billie Rinaldi wrote:
>
> > I would like to call a vote on adopting semantic versioning (
> > http://semver.org/) for future releases.
> >
> > This vote is subject to majority approval and will remai
Just to make sure I'm understanding this before we get into another vote
thread kerfluffle, if we adopt semver in 1.7.0, include a new client api in
1.7.0, deprecate the old api in 1.7.0, then semver would allow (but not
require) removing the deprecated api in 2.0.0, correct?
On Mon, Dec 8, 2014 a
I think there's an issue with this course of discussion because we're
discussion issues of our current 1.x release style while also discussion
Semver, both of which are incongruent with one another. Perhaps we need to
segregate adopting semver for 2.0.0 (which is waht I assumed), vs. adopting
semve
itted undecided, or "-1".
>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
> On Fri, Dec 5, 2014 at 1:51 PM, John Vines wrote:
>
>> [X]: adopt semver 2.0.0 (http://semver.org)
>> [ ]: adopt additional strictness to require documenting deprecati
[X]: adopt semver 2.0.0 (http://semver.org)
[ ]: adopt additional strictness to require documenting deprecation for at
least 1 major release before possible to consider in the next major release
[X]: adopt additional strictness to ensure forward compatibility between
bugfix releases
[ ]: start oper
2014 at 5:12 PM, Keith Turner wrote:
>
>
> On Thu, Dec 4, 2014 at 4:36 PM, Keith Turner wrote:
>
>>
>>
>> On Thu, Dec 4, 2014 at 4:00 PM, John Vines wrote:
>>
>>> Yes, I'm advocating for the freedom to drop undeprecated APIs in 2.0.0.
>>&g
Yes, I'm advocating for the freedom to drop undeprecated APIs in 2.0.0.
This is not something I encourage but I think this is something we should
have in our pocket just in case.
On Thu, Dec 4, 2014 at 3:56 PM, Keith Turner wrote:
> On Thu, Dec 4, 2014 at 12:59 PM, John Vines wrote:
opher wrote:
> On Thu, Dec 4, 2014 at 11:30 AM, John Vines wrote:
>
>> Sent from my phone, please pardon the typos and brevity.
>> On Dec 4, 2014 11:20 AM, "Keith Turner" wrote:
>> >
>> > On Wed, Dec 3, 2014 at 6:48 PM, John Vines wrote:
&g
wrote:
> On Thu, Dec 4, 2014 at 11:11 AM, Josh Elser wrote:
>
> > John Vines wrote:
> >
> >> On Thu, Dec 4, 2014 at 11:52 AM, Keith Turner wrote:
> >>
> >> On Thu, Dec 4, 2014 at 11:40 AM, Josh Elser
> >>> wrote:
> >>>
> >
On Thu, Dec 4, 2014 at 12:39 PM, Keith Turner wrote:
> On Thu, Dec 4, 2014 at 12:17 PM, John Vines wrote:
>
> > On Thu, Dec 4, 2014 at 12:11 PM, Josh Elser
> wrote:
> >
> > > John Vines wrote:
> > >
> > >> On Thu, Dec 4, 2014 at 11:52 AM,
On Thu, Dec 4, 2014 at 12:11 PM, Josh Elser wrote:
> John Vines wrote:
>
>> On Thu, Dec 4, 2014 at 11:52 AM, Keith Turner wrote:
>>
>> On Thu, Dec 4, 2014 at 11:40 AM, Josh Elser
>>> wrote:
>>>
>>> John Vines wrote:
>>>>
>
On Thu, Dec 4, 2014 at 11:52 AM, Keith Turner wrote:
> On Thu, Dec 4, 2014 at 11:40 AM, Josh Elser wrote:
>
> > John Vines wrote:
> >
> >> Though I feel the biggest reasoning is our switch to semantic
> >>>>
> >>> versioning. And from semv
On Thu, Dec 4, 2014 at 11:34 AM, Keith Turner wrote:
> On Thu, Dec 4, 2014 at 11:30 AM, John Vines wrote:
>
> > Sent from my phone, please pardon the typos and brevity.
> > On Dec 4, 2014 11:20 AM, "Keith Turner" wrote:
> > >
> > > On
Sent from my phone, please pardon the typos and brevity.
On Dec 4, 2014 11:20 AM, "Keith Turner" wrote:
>
> On Wed, Dec 3, 2014 at 6:48 PM, John Vines wrote:
>
> > It's hard to track this down-
> > http://www.mail-archive.com/dev@accumulo.apache.org/msg07336
On Thu, Dec 4, 2014 at 8:15 AM, Sean Busbey wrote:
> On Dec 4, 2014 6:55 AM, "Josh Elser" wrote:
> >
> > (I was still confused so I just chatted with John on the subject of his
> -1)
> >
> > He was under the impression that it would not be feasible to leave the
> existing 1.X APIs in place with
On Wed, Dec 3, 2014 at 4:06 PM, Josh Elser wrote:
> Can we bring the discussion back around? I feel like we have two separate
> things going on here.
>
> 1) Can we avoid further churn in the public API for [1.7.0,2.0.0] by
> avoiding any removal or additional deprecation.
>
Do you mean [1.7.0,2.
On Wed, Dec 3, 2014 at 7:02 PM, Christopher wrote:
> On Wed, Dec 3, 2014 at 6:48 PM, John Vines wrote:
>
>> It's hard to track this down-
>> http://www.mail-archive.com/dev@accumulo.apache.org/msg07336.html has
>> Busbey mentioning that 2.0 was breaking, whic
I already cited sources for it in my previous response.
On Wed, Dec 3, 2014 at 6:57 PM, Christopher wrote:
> On Wed, Dec 3, 2014 at 5:28 PM, John Vines wrote:
>
>> I stand by my -1. This vote would guarantee a level of API compatibility
>> that I don't think we should
t 6:01 PM, Keith Turner wrote:
>
>
> On Tue, Dec 2, 2014 at 3:07 PM, John Vines wrote:
>
>> -1 I do not like the idea of committing to 1.7.0-1.9.9... API additions
>> for
>> the 2.0 API. We have already come to the consensus that 2.0 will break the
>> 1
wrote:
>
>
> On Wed, Dec 3, 2014 at 5:28 PM, John Vines wrote:
>
>> I stand by my -1. This vote would guarantee a level of API compatibility
>> that I don't think we should be held to.
>>
>
> Can you give some some specific reasons for your -1?
>
>
>
>
> On Tue, Dec 2, 2014 at 6:16 PM, Christopher wrote:
>
>> On Tue, Dec 2, 2014 at 5:18 PM, John Vines wrote:
>>
>>> On Tue, Dec 2, 2014 at 3:14 PM, Christopher wrote:
>>>
>>> > On Tue, Dec 2, 2014 at 3:07 PM, John Vines wrote:
>>> &g
Accidentally sent to just Shawn before
Sent from my phone, please pardon the typos and brevity.
-- Forwarded message --
From: "John Vines"
Date: Dec 3, 2014 10:01 AM
Subject: Re: [VOTE] API release policy for 1.7/2.0
To: "Sean Busbey"
Cc:
Sent from my phon
On Tue, Dec 2, 2014 at 3:14 PM, Christopher wrote:
> On Tue, Dec 2, 2014 at 3:07 PM, John Vines wrote:
>
> > -1 I do not like the idea of committing to 1.7.0-1.9.9... API additions
> for
> > the 2.0 API. We have already come to the consensus that 2.0 will break
> the
&g
-1 I do not like the idea of committing to 1.7.0-1.9.9... API additions for
the 2.0 API. We have already come to the consensus that 2.0 will break the
1.x API which provides a lot of breathing room and freedom from old
decisions. This causes this issue to come roaring back and an even larger
amount
I was having issues with apache's mail forwarding.
I would have been +1. I don't consider adding a new api breaking it. It
would be nice to have the root synchronization of config updates settled,
but that was outside the scope of the ticket.
On Mon, Dec 1, 2014, 3:55 PM Corey Nolet wrote:
> +1
s to reserve the table. If it succeeds it returns
> > 0, otherwise it returns 100. It should be called in isReady(), and
> > isReady() should return what it returns.
>
> John Vines wrote:
> CloneTable does it in the call space, as a heads up then
>
On Oct. 30, 2014, 4:06 p.m., John Vines wrote:
> > I have only reviewed the FATE ops so far. How will this work w/
> > replication?
> >
> > I am thinking another possible approach may be to make a clone operation
> > that accepts multiple input tables and crea
--
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/27198/#review59201
---
On Oct. 29, 2014, 8:52 p.m., John Vines wrote:
>
>
t-patch. Hopefully
this works better
- John
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/27198/#review58795
---
7198/diff/
Testing
---
Includes CloneIntoIT, which exercises all permutations of the flags. Existing
BulkIT still functions as intended for validation of no feature loss in
refactoring exiting code for multi-purposing.
Thanks,
John Vines
ine180>
> >
> > I don't like removing the old bulkImport method. We should try to keep
> > the server APIs as stable as we can. You can keep the old bulkImport method
> > around and just call the new addFiles method in the implementation. This
> > will help us
to keep
> > the server APIs as stable as we can. You can keep the old bulkImport method
> > around and just call the new addFiles method in the implementation. This
> > will help us stay closer to compatibility across versions.
>
> John Vines wrote:
> This isn
7line45>
> >
> > Thank you for adding this :)
I just copied the CloneIT... or BulkIT which had it.
- John
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.
g
BulkIT still functions as intended for validation of no feature loss in
refactoring exiting code for multi-purposing.
Thanks,
John Vines
Makes me think the Range(Text row) constructor should be row, true, row,
false
On Fri, Oct 24, 2014 at 10:53 AM, Andrew Wells
wrote:
> It may be need to change either the implementation of Key::new(Text row),
> or change the way Range::exact(Text row) matches
>
> Trace on Key::new(Text row)
> li
, except stopping issues which seem to be related to
ACCUMULO-2985
After running this, I validated that the table was created in the real accumulo
instance via zkCli
Thanks,
John Vines
").tableOperations().create("macCreated");
System.out.println("Stopping");
mac.stop();
System.out.println("Stopped");
}
}
Which runs fine, except stopping issues which seem to be related to
ACCUMULO-2985
After running this, I validated that the table was created in the real accumulo
instance via zkCli
Thanks,
John Vines
elated to
ACCUMULO-2985
After running this, I validated that the table was created in the real accumulo
instance via zkCli
Thanks,
John Vines
nstance 2
> > uses ZK2)
> >
> > I think the code gets stuck trying to connect to ZK1, when trying to
> > connection to Accumulo instance 2
>
> John Vines wrote:
> So you're expecting this to work with a new zookeeper? Standard Accumulo
> doesn&#x
2985
After running this, I validated that the table was created in the real accumulo
instance via zkCli
Thanks,
John Vines
ccumulo
doesn't work with a new ZK instance, why would you expect the MAC equivalent to?
- John
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23397/#review57431
---
On Oct. 20, 2014, 8:0
;Stopping");
mac.stop();
System.out.println("Stopped");
}
}
Which runs fine, except stopping issues which seem to be related to
ACCUMULO-2985
After running this, I validated that the table was created in the real accumulo
instance via zkCli
Thanks,
John Vines
ntln("Stopped");
}
}
Which runs fine, except stopping issues which seem to be related to
ACCUMULO-2985
After running this, I validated that the table was created in the real accumulo
instance via zkCli
Thanks,
John Vines
egressions would be really nice. Might be able to
> > start a mini instance, stop it, use internal exec methods to start a
> > zookeeper, and then point another mac to the old mini instance.
>
> John Vines wrote:
> I'm gonna be blunt - this is really really
egressions would be really nice. Might be able to
> > start a mini instance, stop it, use internal exec methods to start a
> > zookeeper, and then point another mac to the old mini instance.
>
> John Vines wrote:
> I'm gonna be blunt - this is really really
ntln("Stopping");
mac.stop();
System.out.println("Stopped");
}
}
Which runs fine, except stopping issues which seem to be related to
ACCUMULO-2985
After running this, I validated that the table was created in the real accumulo
instance via zkCli
Thanks,
John Vines
egressions would be really nice. Might be able to
> > start a mini instance, stop it, use internal exec methods to start a
> > zookeeper, and then point another mac to the old mini instance.
>
> John Vines wrote:
> I'm gonna be blunt - this is really really
tem.out.println("Stopped");
}
}
Which runs fine, except stopping issues which seem to be related to
ACCUMULO-2985
After running this, I validated that the table was created in the real accumulo
instance via zkCli
Thanks,
John Vines
port-running-MAC-against-a-real-acc.patch
https://reviews.apache.org/media/uploaded/files/2014/10/15/d38c6150-4320-41e1-8495-b42d050ddc93__0001-ACCUMULO-2984-support-running-MAC-against-a-real-acc.patch
Thanks,
John Vines
UMULO-2984-support-running-MAC-against-a-real-acc.patch
https://reviews.apache.org/media/uploaded/files/2014/10/15/d38c6150-4320-41e1-8495-b42d050ddc93__0001-ACCUMULO-2984-support-running-MAC-against-a-real-acc.patch
Thanks,
John Vines
-2985
After running this, I validated that the table was created in the real accumulo
instance via zkCli
File Attachments (updated)
0001-ACCUMULO-2984-support-running-MAC-against-a-real-acc.patch
https://reviews.apache.org/media/uploaded/files/2014/10/15/1ee9c409-65de-4a44-a86e-e905b4593a8f__0001-ACCUMULO-2984-support-running-MAC-against-a-real-acc.patch
Thanks,
John Vines
d mini instance.
I'm gonna be blunt - this is really really hard and I think it can be punted to
a ticket for future work
- John
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apa
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23397/#review47661
-------
On July 10, 2014, 10:48 p.m., John Vines wrote:
>
> -
Moving this to it's own thread...
On Mon, Oct 6, 2014 at 5:54 PM, Mike Drob wrote:
> Related: Do we have a release timeline for 1.7?
>
> On Mon, Oct 6, 2014 at 4:51 PM, Christopher wrote:
>
> > On Mon, Oct 6, 2014 at 5:20 PM, Sean Busbey wrote:
> >
> > > On Mon, Oct 6, 2014 at 4:12 PM, Mike Dr
Go for it!
Sent from my phone, please pardon the typos and brevity.
On Sep 3, 2014 4:13 PM, "Jenna Huston" wrote:
> John Vines, would it be ok if I worked on and submitted a patch to
> Accumulo ticket 2841?
>
> Thanks!
> Jenna
>
That is my issue with Keith. Requiring a double dot upgrade to do a single
dot upgrade is a pretty big break in our operating procedure up until this
point.
How do we ensure people don't go to 1.7.0 straight from 1.6.1 and earlier
versions?
On Wed, Jul 23, 2014 at 10:03 AM, Keith Turner wrote:
System.out.println("Stopped");
}
}
Which runs fine, except stopping issues which seem to be related to
ACCUMULO-2985
After running this, I validated that the table was created in the real accumulo
instance via zkCli
Thanks,
John Vines
mb in.
- John
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/23397/#review47622
---
On July 10, 2014, 6:43 p.m., J
In using MAC on 1.6.1-SNAPSHOT, I noticed that the configimpl has a
setProperty that is not exposed in the general MiniAccumuloConfig. Is this
intentional or an oversight?
> On July 10, 2014, 8:42 p.m., Christopher Tubbs wrote:
> > -1
> > There's absolutely no reason to create a profile and options to skip the
> > execution of the plugin since there is a built-in mechanism for controlling
> > the rat check's impact on the build (eg. by setting rat.ignoreErrors).
> On July 10, 2014, 5:50 p.m., Sean Busbey wrote:
> > minicluster/src/main/java/org/apache/accumulo/minicluster/MiniAccumuloConfig.java,
> > line 259
> > <https://reviews.apache.org/r/23397/diff/1/?file=627812#file627812line259>
> >
> > nit: whitesapce
ntln("Stopped");
}
}
Which runs fine, except stopping issues which seem to be related to
ACCUMULO-2985
After running this, I validated that the table was created in the real accumulo
instance via zkCli
Thanks,
John Vines
;Stopped");
}
}
Which runs fine, except stopping issues which seem to be related to
ACCUMULO-2985
After running this, I validated that the table was created in the real accumulo
instance via zkCli
Thanks,
John Vines
System.out.println("Stopped");
}
}
Which runs fine, except stopping issues which seem to be related to
ACCUMULO-2985
After running this, I validated that the table was created in the real accumulo
instance via zkCli
Thanks,
John Vines
views.apache.org/r/23397/#review47585
---
On July 10, 2014, 5:24 p.m., John Vines wrote:
>
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://review
nnector("root", "secret").tableOperations().create("macCreated");
System.out.println("Stopping");
mac.stop();
System.out.println("Stopped");
}
}
Which runs fine, except stopping issues which seem to be related to
ACCUMULO-2985
After running t
Unfortunately to run the shell, it does seem like accumulo-env.sh needs to
be readable, even in the case where you have those variables set (and are
using the shell's -z flag). There seems to be a hack by setting
ACCUMULO_TEST env var, but that seems really hacky and rediculous.
On Wed, Jun 11, 2
My comfort with this is based solely on the amount of effort and complexity
involved. I have no direct qualms with providing that path, on the
assumption we don't spend an exorbitant amount of hours developing it and
end up with a ridiculous amount of code brought up to support this which we
have t
Yes, restore the old behavior
On Wed, May 14, 2014 at 4:38 PM, Sean Busbey wrote:
> We don't have a formal onboarding process for drawing in new contributors,
> but a recent ASF Infra change impacts what I've observed historically.
>
> Here's what I've seen historically, more or less:
>
> 1) So
/DfsLogger.java
<https://reviews.apache.org/r/21557/#comment77307>
I think that before this loop the closeLock and/or closed should be checked
and if it is closed, then LogClosedExceptions should be placed on all of the
LogWorks, not the Exception received.
- John Vines
On May 16, 2014
Why eliminate the 1.6.1-SNAPSHOT branch for 1.7.0-SNAPSHOT? Why not just
branch the master and insert a 1.7.0-SNAPSHOT into our workflow after
1.6.1-SNAPSHOT and before master?
On Mon, May 12, 2014 at 11:10 AM, Bill Havanki wrote:
> I like this plan overall. I am definitely in favor of more freq
1 - 100 of 701 matches
Mail list logo
