accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sean Busbey (JIRA)" <>
Subject [jira] [Commented] (ACCUMULO-4328) Run multiple tablet servers on a single host
Date Mon, 06 Jun 2016 15:29:21 GMT


Sean Busbey commented on ACCUMULO-4328:

Hadoop is a terrible example to look at, because our versioning there is a mess. Surprising
changes regularly show up in double-dot releases and changes that can only be undone with
a system rollback happen on single-dot releases. For example I had to argue against changes
to the datanode's underlying filesystem layout on a double-dot release recently.

I personally wouldn't want to see this in a 1.6 or 1.7 release for largely the same reasons
Josh states. Changing basics around how we do process management on a double-dot release is
tempting trouble. It's not this particular PR's problem, but we have essentially no testing
around our scripts so any verification of how 'safe' changes like this are essentially come
down to some subset of us working through them manually with ill-defined criteria.  But I
agree with Dave that this kind of change would not violate the letter of our versioning policy,
so I wouldn't -1 on principle. If problems showed up after we had a 1.6.z release that contained
it I would, however, then strongly advocate for reverting it in later 1.6 releases using the
same 'not the public API' argument.

Aren't we getting ready to have a 1.8 release soon? What's so pressing about this particular
new feature that means we should introduce risk in our established lines rather than roll
forward with more minor releases?

The lack of user-facing docs on what can be expected from this feature, when folks should
use it, how folks should use it, etc cause me concern. I get that we pretty regularly have
an issue with these kind of "finishing touches" on feature in Accumulo, but it's particularly
troublesome to me when these kinds of 'in-the-know' things show up in maintenance releases.

I'd also strongly prefer having the different tserver instances log to distinct files, regardless
of what version this lands in. I get that I can use post-processing to figure out which lines
correspond to a given process, but I'm skeptical of log4j's ability to efficiently and safely
have multiple processes share a log file. This should be doable with a log4j configs since
we control the filename via a classpath config file. I don't have strong feelings on how we
go about doing that, wether it's example config files that show making a config-per-expected-process
(preferably referenced/explained in the user manual) or a parameter in a single log4j config
that the launching script sets via a system property.

> Run multiple tablet servers on a single host
> --------------------------------------------
>                 Key: ACCUMULO-4328
>                 URL:
>             Project: Accumulo
>          Issue Type: Improvement
>          Components: scripts, tserver
>            Reporter: Dave Marion
>            Assignee: Dave Marion
>          Time Spent: 10m
>  Remaining Estimate: 0h
> Modify scripts and necessary code to run multiple tablet servers on a single host.

This message was sent by Atlassian JIRA

View raw message