[
https://issues.apache.org/jira/browse/ACCUMULO-4328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15316648#comment-15316648
]
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: https://issues.apache.org/jira/browse/ACCUMULO-4328
> 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
(v6.3.4#6332)
