[
https://issues.apache.org/jira/browse/ACCUMULO-4328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15316726#comment-15316726
]
Keith Turner commented on ACCUMULO-4328:
----------------------------------------
In general I think bug fix releases with compatibility caveats are a bad thing
over time. This can lead to a very confusing user experience. I think these
caveats are worse the further a user is away from directly using Accumulo. For
users using Accumulo as part of a stack, they primarily interact with the top
of the stack (software built on top of Accumulo). When someone is trying to
use something like Geowave, its nice to know that version 1.X.ANY of Geowave
works with Accumulo 1.6.ANY. Ideally a user of something like Geowave could
move between the bug fix release of Hadoop, Accumulo, and Zookeeper w/o issue.
The stories about Hadoop in this issue make me cringe, but there is nothing we
can do about that. I would hope the incremental decision we make in the short
term also make sense in the long term. If we fast forward a few years and look
at all of the 1.7.X release notes, hopefully it looks very orderly and sane.
Recently there was some major issue with Zookeeper 3.4.7. When the issue was
discovered the remedy was for users to move back to 3.4.6 until 3.4.8 was
released. Its really nice to have that level of flexibility w/ bug fix
releases, the ability to move in both directions w/o worry.
Also I am not a big fan of one off exceptions, because they can be time sinks
(like me currently sharing my opinions, that I am not sure anyone will fully
read.. I am doing my best to keep it short and to the point). Personally I
would rather drop it in the latest minor release. A really strong case needs
to be made for exceptions. Like in this case there does not seem to be
performance numbers. Also the implementation (using PIDs in log files) has
raised concern. Seem like these issues should be addressed before we consider
putting this in a bug fix release. I am going to look into the file per
tserver issue when I look at the PR (I did this locally once, where each
tserver had its own log file).
I am excited about this feature. I tend to think multiple tservers can perform
much better, simply because when a node had oodles of disk and cores there is
no way a single walog can utilize all of that capacity. However I think that
premise needs to be verified and ensure there are not unforeseen issues with
attaining higher utilization.
> 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)
