[jira] [Created] (ZOOKEEPER-4379) Use Commons-Io CountingInputStream
David Mollitor created ZOOKEEPER-4379:
-
Summary: Use Commons-Io CountingInputStream
Key: ZOOKEEPER-4379
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4379
Project: ZooKeeper
Issue Type: Improvement
Reporter: David Mollitor
Assignee: David Mollitor
The {{FileTxnLog}} class uses its own implementation of a counting
{{InputStream}}. Commons-io is a direct dependency of Apache ZooKeeper, might
as well use its implementation instead.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3993) Review some hashcode / equals methods
David Mollitor created ZOOKEEPER-3993: - Summary: Review some hashcode / equals methods Key: ZOOKEEPER-3993 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3993 Project: ZooKeeper Issue Type: Improvement Reporter: David Mollitor Assignee: David Mollitor -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3963) Revamp and Log Connection Disconnect Reason
David Mollitor created ZOOKEEPER-3963: - Summary: Revamp and Log Connection Disconnect Reason Key: ZOOKEEPER-3963 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3963 Project: ZooKeeper Issue Type: Improvement Reporter: David Mollitor Assignee: David Mollitor -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3961) Inaccurate Error Message
David Mollitor created ZOOKEEPER-3961:
-
Summary: Inaccurate Error Message
Key: ZOOKEEPER-3961
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3961
Project: ZooKeeper
Issue Type: Improvement
Reporter: David Mollitor
https://github.com/apache/zookeeper/blob/c47ef905e077184bc5b7f555a3e2dfeb6dc046e1/zookeeper-server/src/main/java/org/apache/zookeeper/server/ZooKeeperServer.java#L239-L244
{code:java|title=ZooKeeperServer.java}
if (intBufferStartingSizeBytes < 32) {
String msg = "Buffer starting size must be greater than 0."
+ "Configure with
\"-Dzookeeper.intBufferStartingSizeBytes=\" ";
LOG.error(msg);
throw new IllegalArgumentException(msg);
}
{code}
Actually the size must be _greater or equal to 32_
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3840) Use JDK 8 Facilities to Synchronize Access to DataTree Ephemerals
David Mollitor created ZOOKEEPER-3840: - Summary: Use JDK 8 Facilities to Synchronize Access to DataTree Ephemerals Key: ZOOKEEPER-3840 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3840 Project: ZooKeeper Issue Type: Improvement Reporter: David Mollitor Assignee: David Mollitor The current setup is a bit confusing and hard to verify. Use JDK8 facilities to manage this collection. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3839) ReconfigBackupTest Remove getFileContent
David Mollitor created ZOOKEEPER-3839: - Summary: ReconfigBackupTest Remove getFileContent Key: ZOOKEEPER-3839 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3839 Project: ZooKeeper Issue Type: Improvement Reporter: David Mollitor Assignee: David Mollitor bq. // upgrade this once we have Google-Guava or Java 7+ https://github.com/apache/zookeeper/blob/a908001be9641d78040b1954acb0cd3a8e9e42c2/zookeeper-server/src/test/java/org/apache/zookeeper/server/quorum/ReconfigBackupTest.java#L53 OK. Done. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3837) Deprecate StringUtils Join
David Mollitor created ZOOKEEPER-3837: - Summary: Deprecate StringUtils Join Key: ZOOKEEPER-3837 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3837 Project: ZooKeeper Issue Type: Improvement Reporter: David Mollitor Assignee: David Mollitor -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3836) Use Common IOUtils and JDK Functions in ClientBase
David Mollitor created ZOOKEEPER-3836:
-
Summary: Use Common IOUtils and JDK Functions in ClientBase
Key: ZOOKEEPER-3836
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3836
Project: ZooKeeper
Issue Type: Improvement
Reporter: David Mollitor
Assignee: David Mollitor
Remove code in {{ClientBase}} that now exist in JDK and Apache Commons.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3834) Do Not Set Explicit Test Includes in POM
David Mollitor created ZOOKEEPER-3834:
-
Summary: Do Not Set Explicit Test Includes in POM
Key: ZOOKEEPER-3834
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3834
Project: ZooKeeper
Issue Type: Improvement
Reporter: David Mollitor
Assignee: David Mollitor
{quote}
By default, the Surefire Plugin will automatically include all test classes
with the following wildcard patterns:
"**/Test*.java" - includes all of its subdirectories and all Java filenames
that start with "Test".
"**/*Test.java" - includes all of its subdirectories and all Java filenames
that end with "Test".
"**/*Tests.java" - includes all of its subdirectories and all Java filenames
that end with "Tests".
"**/*TestCase.java" - includes all of its subdirectories and all Java filenames
that end with "TestCase".
{quote}
https://maven.apache.org/surefire/maven-surefire-plugin/examples/inclusion-exclusion.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3833) So Not Override Plugin Versions from Apache Parent POM
David Mollitor created ZOOKEEPER-3833: - Summary: So Not Override Plugin Versions from Apache Parent POM Key: ZOOKEEPER-3833 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3833 Project: ZooKeeper Issue Type: Improvement Reporter: David Mollitor Assignee: David Mollitor Only override plugin versions (inherited from Apache POM 23) if a newer version than is specified in the parent POM is required. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3764) Add High Availability Guarantee Into Docs
David Mollitor created ZOOKEEPER-3764:
-
Summary: Add High Availability Guarantee Into Docs
Key: ZOOKEEPER-3764
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3764
Project: ZooKeeper
Issue Type: Improvement
Components: documentation
Reporter: David Mollitor
{quote}
For a topic with replication factor N, we will tolerate up to N-1 server
failures without losing any records committed to the log.
* https://kafka.apache.org/documentation/
{quote}
Please add a similar statement to the ZK docs, to include the formula for
calculating the maximum number of server failures.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3709) Pre-Size Buffer in Learner Send Method
David Mollitor created ZOOKEEPER-3709:
-
Summary: Pre-Size Buffer in Learner Send Method
Key: ZOOKEEPER-3709
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3709
Project: ZooKeeper
Issue Type: Improvement
Reporter: David Mollitor
{code:java|title=Learner.java}
void request(Request request) throws IOException {
ByteArrayOutputStream baos = new ByteArrayOutputStream();
DataOutputStream oa = new DataOutputStream(baos);
oa.writeLong(request.sessionId);
oa.writeInt(request.cxid);
oa.writeInt(request.type);
if (request.request != null) {
request.request.rewind();
int len = request.request.remaining();
byte[] b = new byte[len];
request.request.get(b);
request.request.rewind();
oa.write(b);
}
oa.close();
QuorumPacket qp = new QuorumPacket(Leader.REQUEST, -1,
baos.toByteArray(), request.authInfo);
writePacket(qp, true);
}
{code}
The default internal array size of {{ByteArrayOutputStream}} is 32 bytes. It
will be expanded as required but this operation is not optimal. Since the
exact size of the buffer can be pre-determined (long, int, int, request buffer
size), it would be better to specify the array size in
{{ByteArrayOutputStream}} before writing to it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3708) Move Logging Code into Logging Guard in Learner
David Mollitor created ZOOKEEPER-3708:
-
Summary: Move Logging Code into Logging Guard in Learner
Key: ZOOKEEPER-3708
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3708
Project: ZooKeeper
Issue Type: Improvement
Reporter: David Mollitor
{code:java|title=Learner.java}
void readPacket(QuorumPacket pp) throws IOException {
...
long traceMask = ZooTrace.SERVER_PACKET_TRACE_MASK;
if (pp.getType() == Leader.PING) {
traceMask = ZooTrace.SERVER_PING_TRACE_MASK;
}
if (LOG.isTraceEnabled()) {
ZooTrace.logQuorumPacket(LOG, traceMask, 'i', pp);
}
}
{code}
The traceMask only matters if trace is enabled, so move it and the associated
code into the logging guard.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3694) Use Map computeIfAbsent in AvgMinMaxCounterSet Class
David Mollitor created ZOOKEEPER-3694: - Summary: Use Map computeIfAbsent in AvgMinMaxCounterSet Class Key: ZOOKEEPER-3694 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3694 Project: ZooKeeper Issue Type: Improvement Reporter: David Mollitor Assignee: David Mollitor https://github.com/apache/zookeeper/blob/27b92caefd57a60309af06ebce29e56954ca9aac/zookeeper-server/src/main/java/org/apache/zookeeper/server/metric/AvgMinMaxCounterSet.java#L41 More concise to use JDK facilities for this operation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3693) Use Map computeIfAbsent in AvgMinMaxCounterSet Class
David Mollitor created ZOOKEEPER-3693: - Summary: Use Map computeIfAbsent in AvgMinMaxCounterSet Class Key: ZOOKEEPER-3693 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3693 Project: ZooKeeper Issue Type: Improvement Reporter: David Mollitor Assignee: David Mollitor https://github.com/apache/zookeeper/blob/27b92caefd57a60309af06ebce29e56954ca9aac/zookeeper-server/src/main/java/org/apache/zookeeper/server/metric/AvgMinMaxCounterSet.java#L41 More concise to use JDK facilities for this operation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3692) Change Java Package For TestStringUtils
David Mollitor created ZOOKEEPER-3692:
-
Summary: Change Java Package For TestStringUtils
Key: ZOOKEEPER-3692
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3692
Project: ZooKeeper
Issue Type: Improvement
Reporter: David Mollitor
Move {{TestStringUtils}} into the common package so that it aligns with the
class being tested.
{code:none}
/zookeeper/src/main/java/org/apache/zookeeper/common/StringUtils.java
/zookeeper/src/test/java/org/apache/zookeeper/test/StringUtilTest.java
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3691) Use JDK String Join Method in ZK StringUtils
David Mollitor created ZOOKEEPER-3691: - Summary: Use JDK String Join Method in ZK StringUtils Key: ZOOKEEPER-3691 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3691 Project: ZooKeeper Issue Type: Improvement Reporter: David Mollitor Assignee: David Mollitor https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#join-java.lang.CharSequence-java.lang.Iterable- -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3688) Use StandardCharsets UTF-8 in Jute toString
David Mollitor created ZOOKEEPER-3688: - Summary: Use StandardCharsets UTF-8 in Jute toString Key: ZOOKEEPER-3688 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3688 Project: ZooKeeper Issue Type: Improvement Components: jute Reporter: David Mollitor Assignee: David Mollitor -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3687) Jute Use JDK hashCode Methods for Native Types
David Mollitor created ZOOKEEPER-3687: - Summary: Jute Use JDK hashCode Methods for Native Types Key: ZOOKEEPER-3687 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3687 Project: ZooKeeper Issue Type: Improvement Components: jute Reporter: David Mollitor Assignee: David Mollitor -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3686) Use JDK Arrays hashCode for Jute
David Mollitor created ZOOKEEPER-3686: - Summary: Use JDK Arrays hashCode for Jute Key: ZOOKEEPER-3686 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3686 Project: ZooKeeper Issue Type: Improvement Reporter: David Mollitor Assignee: David Mollitor https://github.com/apache/zookeeper/blob/27b92caefd57a60309af06ebce29e56954ca9aac/zookeeper-jute/src/main/java/org/apache/jute/compiler/JBuffer.java#L82 https://docs.oracle.com/javase/7/docs/api/java/util/Arrays.html#hashCode(byte[]) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3685) Use JDK Arrays Equals for Jute
David Mollitor created ZOOKEEPER-3685:
-
Summary: Use JDK Arrays Equals for Jute
Key: ZOOKEEPER-3685
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3685
Project: ZooKeeper
Issue Type: Improvement
Reporter: David Mollitor
Assignee: David Mollitor
ZK Jute compiler uses its own byte Array equality check. JDK has one which is
marked with the {{HotSpotIntrinsicCandidate}} annotation. This means that the
JDK may have a native optimization for the routine.
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/Arrays.java#L2654
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3684) Use JDK emptyIterator in ConnectHeaders Class
David Mollitor created ZOOKEEPER-3684: - Summary: Use JDK emptyIterator in ConnectHeaders Class Key: ZOOKEEPER-3684 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3684 Project: ZooKeeper Issue Type: Improvement Reporter: David Mollitor Assignee: David Mollitor https://docs.oracle.com/javase/8/docs/api/java/util/Collections.html#emptyIterator-- -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3680) Standardize on commons-lang 2.6
David Mollitor created ZOOKEEPER-3680: - Summary: Standardize on commons-lang 2.6 Key: ZOOKEEPER-3680 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3680 Project: ZooKeeper Issue Type: Improvement Reporter: David Mollitor Assignee: David Mollitor ZooKeeper parent pom defines 2.6, but 2.4 still exists elsewhere. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3679) Upgrade maven-compiler-plugin For ZooKeeper-jute
David Mollitor created ZOOKEEPER-3679: - Summary: Upgrade maven-compiler-plugin For ZooKeeper-jute Key: ZOOKEEPER-3679 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3679 Project: ZooKeeper Issue Type: Improvement Reporter: David Mollitor Assignee: David Mollitor Let it match the same version as the rest of the project. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3678) Remove Redundant GroupID from Maven POMs
David Mollitor created ZOOKEEPER-3678:
-
Summary: Remove Redundant GroupID from Maven POMs
Key: ZOOKEEPER-3678
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3678
Project: ZooKeeper
Issue Type: Improvement
Reporter: David Mollitor
Assignee: David Mollitor
No need to declare a {{groupId}} in each POM because it is inherited from the
parent POM file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3676) Clean Up TxnLogProposalIterator
David Mollitor created ZOOKEEPER-3676: - Summary: Clean Up TxnLogProposalIterator Key: ZOOKEEPER-3676 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3676 Project: ZooKeeper Issue Type: Improvement Reporter: David Mollitor Assignee: David Mollitor * Use JDK Collections.emptyIterator where needed * The the code manually returns an emptyIterator when an error occurs, but it's also possible to return an emptyIterator by passing 'null' to the TxnLogProposalIterator constructor. This is a bit ambiguous... why allow both? Null values 'suck' so I think it's better to just make sure that emptyIterator is returned where needed an throw NPE if a 'null' value is passed in. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3675) Clean Up committedLog Interaction in ZKDatabase
David Mollitor created ZOOKEEPER-3675: - Summary: Clean Up committedLog Interaction in ZKDatabase Key: ZOOKEEPER-3675 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3675 Project: ZooKeeper Issue Type: Improvement Reporter: David Mollitor Assignee: David Mollitor * To be proper, minCommittedLog/maxCommittedLog should only be modified in a lock. * maxCommittedLog is potentially set twice (to the same value) for each call to the method * Streamline code in addCommittedProposal * Pre-initialize committedLog data structure to the full size * Remove unused commitLogBuffer * Remove synchronization of method getCommittedLog(), it is protected with lock * Unify grabbing locks outside of try block -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3671) Use ThreadLocalConcurrent to Replace Random and Math.random
David Mollitor created ZOOKEEPER-3671: - Summary: Use ThreadLocalConcurrent to Replace Random and Math.random Key: ZOOKEEPER-3671 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3671 Project: ZooKeeper Issue Type: Improvement Reporter: David Mollitor Assignee: David Mollitor -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3670) Clean Up Log Statements for SLF4J
David Mollitor created ZOOKEEPER-3670: - Summary: Clean Up Log Statements for SLF4J Key: ZOOKEEPER-3670 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3670 Project: ZooKeeper Issue Type: Improvement Reporter: David Mollitor Assignee: David Mollitor Not changing anything controversial, just some of the obvious stuff I noticed across the project. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3669) Use switch Statement in ClientCnxn SendThread
David Mollitor created ZOOKEEPER-3669: - Summary: Use switch Statement in ClientCnxn SendThread Key: ZOOKEEPER-3669 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3669 Project: ZooKeeper Issue Type: Improvement Reporter: David Mollitor Assignee: David Mollitor -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3663) Clean Up ZNodeName Class
David Mollitor created ZOOKEEPER-3663:
-
Summary: Clean Up ZNodeName Class
Key: ZOOKEEPER-3663
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3663
Project: ZooKeeper
Issue Type: Improvement
Reporter: David Mollitor
Assignee: David Mollitor
# Make class immutable
# Enforce null check of constructor
# Enhance and add unit tests
# Make 'sequence' an {{Optional}} field
# Change name of getter 'getZNodeName' to more appropriate 'getSequence'
This is a {{default}} scoped class so please allow for some change in API
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3662) Remove NPE Possibility in Follower Class
David Mollitor created ZOOKEEPER-3662:
-
Summary: Remove NPE Possibility in Follower Class
Key: ZOOKEEPER-3662
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3662
Project: ZooKeeper
Issue Type: Improvement
Reporter: David Mollitor
Assignee: David Mollitor
{code:java|title=Follower.java}
public long getZxid() {
try {
synchronized (fzk) {
return fzk.getZxid();
}
} catch (NullPointerException e) {
LOG.warn("error getting zxid", e);
}
return -1;
}
{code}
I traced the code and there is no reason to catch a NPE here. Add additional
restrictions to make sure NPE will never happen.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3586) Write Log To Multiple Drives
David Mollitor created ZOOKEEPER-3586: - Summary: Write Log To Multiple Drives Key: ZOOKEEPER-3586 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3586 Project: ZooKeeper Issue Type: Improvement Components: server Reporter: David Mollitor Allow ZooKeeper server to write the transaction log to multiple drives. I can imagine two different ways of doing this: # Allow special namespace ZNodes under the root node. Upon creation, the user can specify the location of the log file for all activity under this node. # Write each transaction out to more than one drive and return an ACK when any of the writes complete. Cancel any pending writes and delete the files that are furthest behind on merge. # Write each transaction out to more than one drive and obtain a lock on a target drive before each write. If the lock for the first drive is taken, attempt to get the lock on the second drive, and so on, ... combine logs on merge being mindful that one of the transactions may have failed and created a small hole in the middle of the log. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3553) Create Performance Test Tool
David Mollitor created ZOOKEEPER-3553: - Summary: Create Performance Test Tool Key: ZOOKEEPER-3553 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3553 Project: ZooKeeper Issue Type: New Feature Affects Versions: 3.6.0 Reporter: David Mollitor Create a tool similar to [Dynamometer|https://github.com/linkedin/dynamometer] for ZooKeeper. To use this tool, the operator should collect transaction log files from a live instance of ZooKeeper and supply them to the tool. The tool then simply replays all of the commands it finds in all of the supplied transaction logs, in order. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3450) Allow Quorum Leader to Register with Another Quorum
David Mollitor created ZOOKEEPER-3450:
-
Summary: Allow Quorum Leader to Register with Another Quorum
Key: ZOOKEEPER-3450
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3450
Project: ZooKeeper
Issue Type: Sub-task
Components: server
Reporter: David Mollitor
When a ZK instance within a quorum is elected leader, add a feature that
registers all the servers within the quorum with another ZK quorum.
The idea is ultimately that all quorums within an environment register with a
single global quorum so that clients can discover the service-specific quorums.
{code:Plain Text}
/zk/register//quorum{host1,host2,host3}
/zk/register/hbase/quorum{host1,host2,host3}
/zk/register/hdfs/quorum{host1,host2,host3}
/zk/register/yarn/quorum{host1,host2,host3}
{code}
Note that a single quorum should be able to register (be responsible for)
several services.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-3449) Zero Configuration Discovery of ZooKeeper Quorum
David Mollitor created ZOOKEEPER-3449: - Summary: Zero Configuration Discovery of ZooKeeper Quorum Key: ZOOKEEPER-3449 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3449 Project: ZooKeeper Issue Type: New Feature Components: server Reporter: David Mollitor ZooKeeper is often used for [service discovery|https://curator.apache.org/curator-x-discovery/index.html]. However, how are clients to discover the ZooKeeper quorum itself? Provide a mechanism for clients to automatically discover a ZooKeeper quorum. [https://en.wikipedia.org/wiki/Zero-configuration_networking] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-3352) Use LevelDB For Backend
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16836709#comment-16836709 ] David Mollitor commented on ZOOKEEPER-3352: --- I haven't moved much on this. I spent some time looking at the issue and like most things, the more I saw, the more I realized this would not be easy to shim in. However, I can imagine a situation where ZK is greatly simplified and implemented more-or-less as Netty connectors to an LSM instance. LSMs already have a WAL (transaction log) and have a datastore (data tree) with fast look-ups. one of the slightly trickier parts I was looking at is that the LSMs, from a glance, do not expose their internal TXiD, so ZK would have to be stored its own in each record. It feels a bit dirty having to have two different TXiDs and also finding the record with the highest TXiD at startup would require a scan of the entire data set... that also feels wrong. > Use LevelDB For Backend > --- > > Key: ZOOKEEPER-3352 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3352 > Project: ZooKeeper > Issue Type: New Feature > Components: server >Reporter: David Mollitor >Assignee: David Mollitor >Priority: Critical > Fix For: 4.0.0 > > > Use LevelDB for managing data stored in ZK (transaction logs and snapshots). > https://stackoverflow.com/questions/6779669/does-leveldb-support-java -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3382) Update Documentation: If you only have one storage device
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Mollitor updated ZOOKEEPER-3382:
--
Description:
{quote}
If you only have one storage device, put trace files on NFS and increase the
snapshotCount; it doesn't eliminate the problem, but it should mitigate it.
{quote}
'trace files' are no longer available in ZooKeeper; remove mention of it.
Also, there is no such configuration named 'snapshotCount'; update it.
was:
The feature formally known as {{requestTraceFile}} has been removed.
Remove mention of it from docs.
> Update Documentation: If you only have one storage device
> -
>
> Key: ZOOKEEPER-3382
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3382
> Project: ZooKeeper
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 3.6.0, 3.5.5, 3.4.15
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Minor
> Fix For: 3.6.0
>
>
> {quote}
> If you only have one storage device, put trace files on NFS and increase the
> snapshotCount; it doesn't eliminate the problem, but it should mitigate it.
> {quote}
> 'trace files' are no longer available in ZooKeeper; remove mention of it.
> Also, there is no such configuration named 'snapshotCount'; update it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3382) Update Documentation: If you only have one storage device
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Mollitor updated ZOOKEEPER-3382:
--
Summary: Update Documentation: If you only have one storage device (was:
Remove References To requestTraceFile From Docs)
> Update Documentation: If you only have one storage device
> -
>
> Key: ZOOKEEPER-3382
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3382
> Project: ZooKeeper
> Issue Type: Improvement
>Affects Versions: 3.6.0, 3.5.5, 3.4.15
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Minor
> Fix For: 3.6.0
>
>
> The feature formally known as {{requestTraceFile}} has been removed.
> Remove mention of it from docs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3382) Update Documentation: If you only have one storage device
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Mollitor updated ZOOKEEPER-3382:
--
Component/s: documentation
> Update Documentation: If you only have one storage device
> -
>
> Key: ZOOKEEPER-3382
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3382
> Project: ZooKeeper
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 3.6.0, 3.5.5, 3.4.15
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Minor
> Fix For: 3.6.0
>
>
> The feature formally known as {{requestTraceFile}} has been removed.
> Remove mention of it from docs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-3382) Remove References To requestTraceFile From Docs
David Mollitor created ZOOKEEPER-3382:
-
Summary: Remove References To requestTraceFile From Docs
Key: ZOOKEEPER-3382
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3382
Project: ZooKeeper
Issue Type: Improvement
Affects Versions: 3.6.0, 3.5.5, 3.4.15
Reporter: David Mollitor
Assignee: David Mollitor
Fix For: 3.6.0
The feature formally known as {{requestTraceFile}} has been removed.
Remove mention of it from docs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (ZOOKEEPER-3358) Make Snappy The Default Snapshot Compression Algorithm
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16836479#comment-16836479 ] David Mollitor edited comment on ZOOKEEPER-3358 at 5/9/19 3:43 PM: --- [~lvfangmin] It's understandable that this should be a configurable (on/off) feature, however, I still advocate that it should be on by default. The snap shot file contains Strings representing the ZNode paths and that path data is almost certainly highly compressible. So even if there is compressed payload, the metadata still will gain from compression. Edit: That is to say, how common is it to store data in ZNodes or is the more commons use case to simply use ZNodes paths to encode some sort of state... i.e., service discovery or locking recipes. was (Author: belugabehr): [~lvfangmin] It's understandable that this should be a configurable (on/off) feature, however, I still advocate that it should be on by default. The snap shot file contains Strings representing the ZNode paths and that path data is almost certainly highly compressible. So even if there is compressed payload, the metadata still will gain from compression. > Make Snappy The Default Snapshot Compression Algorithm > -- > > Key: ZOOKEEPER-3358 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3358 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.6.0 >Reporter: David Mollitor >Priority: Major > Fix For: 3.6.0 > > > Now that SnapShots are compressed, thanks to [ZOOKEEPER-3179], make the > default algorithm Snappy compression. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-3358) Make Snappy The Default Snapshot Compression Algorithm
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16836479#comment-16836479 ] David Mollitor commented on ZOOKEEPER-3358: --- [~lvfangmin] It's understandable that this should be a configurable (on/off) feature, however, I still advocate that it should be on by default. The snap shot file contains Strings representing the ZNode paths and that path data is almost certainly highly compressible. So even if there is compressed payload, the metadata still will gain from compression. > Make Snappy The Default Snapshot Compression Algorithm > -- > > Key: ZOOKEEPER-3358 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3358 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.6.0 >Reporter: David Mollitor >Priority: Major > Fix For: 3.6.0 > > > Now that SnapShots are compressed, thanks to [ZOOKEEPER-3179], make the > default algorithm Snappy compression. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-3301) Enforce the quota limit
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16835582#comment-16835582 ] David Mollitor commented on ZOOKEEPER-3301: --- Also be sure to take a look at [ZOOKEEPER-3347] > Enforce the quota limit > --- > > Key: ZOOKEEPER-3301 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3301 > Project: ZooKeeper > Issue Type: Sub-task >Reporter: maoling >Priority: Major > > We need a complete quota feature, not just the printing the warning logs > which is a bit chicken ribs. > [zk: localhost:2181(CONNECTED) 18] setquota -n 2 /quota_test > [zk: localhost:2181(CONNECTED) 19] create /quota_test/child_1 > Created /quota_test/child_1 > [zk: localhost:2181(CONNECTED) 20] create /quota_test/child_2 > Created /quota_test/child_2 > [zk: localhost:2181(CONNECTED) 21] create /quota_test/child_3 > Created /quota_test/child_3 > look at the following logs: > 2019-03-07 11:22:36,680 [myid:1] - WARN [SyncThread:0:DataTree@374] - Quota > exceeded: /quota_test count=3 limit=2 > 2019-03-07 11:22:41,861 [myid:1] - WARN [SyncThread:0:DataTree@374] - Quota > exceeded: /quota_test count=4 limit=2 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-102) Need to replace Jute with supported code
[ https://issues.apache.org/jira/browse/ZOOKEEPER-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16825130#comment-16825130 ] David Mollitor commented on ZOOKEEPER-102: -- [~maoling] Perhaps you can simply add a new port for Thrift comms and the Jute comms can be deprecated and eventually removed. > Need to replace Jute with supported code > > > Key: ZOOKEEPER-102 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-102 > Project: ZooKeeper > Issue Type: Improvement >Reporter: Benjamin Reed >Priority: Major > Fix For: 4.0.0 > > > ZooKeeper currently uses Jute to serialize objects to put on the wire and on > disk. We pulled Jute out of Hadoop and added a C binding. Both versions of > Jute have evolved (although Hadoop still doesn't have a C binding). It would > be nice to use a more standard serialization library. Some options include > Thrift or Google's protocol buffers. > Our main requirements would be Java and C bindings and good performance. (For > example, serializing to XML would give us incredibly bad performance and > would not be acceptible!) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3340) Improve Queue Usage in QuorumCnxManager.java
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Mollitor updated ZOOKEEPER-3340:
--
Description:
I was recently profiling a on a ZK Quorum Leader in a low-volume environment
and noticed that most of its time was spent in {{QuorumCnxManager#RecvWorker}}.
Nothing wrong with that, but it did draw my attention to it. I noticed that
{{Queue}} interactions are a bit... verbose. I would like to propose that we
streamline this area of the code.
[https://github.com/apache/zookeeper/blob/master/zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/QuorumCnxManager.java#L1291-L1309]
This proposed JIRA should not be viewed simply as 'ArrayBlockingQueue' v.s.
'CircularBlockingQueue'.
One of the things that this PR does is remove the need for double-locking. For
example in addToRecvQueue the following condition exists:
{code}
public void addToRecvQueue(Message msg) {
synchronized(recvQLock) {
if (recvQueue.remainingCapacity() == 0) {
try {
{code}
>From here it can be observed that there are two locks obtained: {{recvQLock}}
>and the one internal to {{recvQueue}}. This is required because there are
>multiple interactions that this Manager wants to do on the queue in a
>serialized way. The {{CircularBlockingQueue}} performs all of those actions on
>behalf of the caller, but it does it internal to the queue, under a single
>lock,... the one internal to {{CircularBlockingQueue}}.
The current code also has some race-conditions that are simply ignored when
they happen. The race conditions are detailed nicely in the code comments here.
However, the changes in this PR directly deal with, and eliminate, these race
conditions altogether since all actions that work against the
{{CircularBlockingQueue}} all occur within its internal locks. This greatly
simplifies the code and removes the need for new folks to learn this nuance of
"why is the code doing this."
was:
I was recently profiling a on a ZK Quorum Leader in a low-volume environment
and noticed that most of its time was spent in {{QuorumCnxManager#RecvWorker}}.
Nothing wrong with that, but it did draw my attention to it. I noticed that
{{Queue}} interactions are a bit... verbose. I would like to propose that we
streamline this area of the code.
[https://github.com/apache/zookeeper/blob/master/zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/QuorumCnxManager.java#L1291-L1309]
> Improve Queue Usage in QuorumCnxManager.java
>
>
> Key: ZOOKEEPER-3340
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3340
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.6.0
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> I was recently profiling a on a ZK Quorum Leader in a low-volume environment
> and noticed that most of its time was spent in
> {{QuorumCnxManager#RecvWorker}}. Nothing wrong with that, but it did draw my
> attention to it. I noticed that {{Queue}} interactions are a bit... verbose.
> I would like to propose that we streamline this area of the code.
>
> [https://github.com/apache/zookeeper/blob/master/zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/QuorumCnxManager.java#L1291-L1309]
> This proposed JIRA should not be viewed simply as 'ArrayBlockingQueue' v.s.
> 'CircularBlockingQueue'.
> One of the things that this PR does is remove the need for double-locking.
> For example in addToRecvQueue the following condition exists:
> {code}
> public void addToRecvQueue(Message msg) {
> synchronized(recvQLock) {
> if (recvQueue.remainingCapacity() == 0) {
> try {
> {code}
> From here it can be observed that there are two locks obtained: {{recvQLock}}
> and the one internal to {{recvQueue}}. This is required because there are
> multiple interactions that this Manager wants to do on the queue in a
> serialized way. The {{CircularBlockingQueue}} performs all of those actions
> on behalf of the caller, but it does it internal to the queue, under a single
> lock,... the one internal to {{CircularBlockingQueue}}.
> The current code also has some race-conditions that are simply ignored when
> they happen. The race conditions are detailed nicely in the code comments
> here. However, the changes in this PR directly deal with, and eliminate,
> these race conditions altogether since all actions that work against the
> {{CircularBlockingQueue}} all occur within its internal locks. This greatly
> simplifies the code and removes the need for new folks to learn this
[jira] [Updated] (ZOOKEEPER-3340) Introduce CircularBlockingQueue in QuorumCnxManager.java
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Mollitor updated ZOOKEEPER-3340:
--
Summary: Introduce CircularBlockingQueue in QuorumCnxManager.java (was:
Improve Queue Usage in QuorumCnxManager.java)
> Introduce CircularBlockingQueue in QuorumCnxManager.java
>
>
> Key: ZOOKEEPER-3340
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3340
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.6.0
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> I was recently profiling a on a ZK Quorum Leader in a low-volume environment
> and noticed that most of its time was spent in
> {{QuorumCnxManager#RecvWorker}}. Nothing wrong with that, but it did draw my
> attention to it. I noticed that {{Queue}} interactions are a bit... verbose.
> I would like to propose that we streamline this area of the code.
>
> [https://github.com/apache/zookeeper/blob/master/zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/QuorumCnxManager.java#L1291-L1309]
> This proposed JIRA should not be viewed simply as 'ArrayBlockingQueue' v.s.
> 'CircularBlockingQueue'.
> One of the things that this PR does is remove the need for double-locking.
> For example in addToRecvQueue the following condition exists:
> {code}
> public void addToRecvQueue(Message msg) {
> synchronized(recvQLock) {
> if (recvQueue.remainingCapacity() == 0) {
> try {
> {code}
> From here it can be observed that there are two locks obtained: {{recvQLock}}
> and the one internal to {{recvQueue}}. This is required because there are
> multiple interactions that this Manager wants to do on the queue in a
> serialized way. The {{CircularBlockingQueue}} performs all of those actions
> on behalf of the caller, but it does it internal to the queue, under a single
> lock,... the one internal to {{CircularBlockingQueue}}.
> The current code also has some race-conditions that are simply ignored when
> they happen. The race conditions are detailed nicely in the code comments
> here. However, the changes in this PR directly deal with, and eliminate,
> these race conditions altogether since all actions that work against the
> {{CircularBlockingQueue}} all occur within its internal locks. This greatly
> simplifies the code and removes the need for new folks to learn this nuance
> of "why is the code doing this."
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3365) Use Concurrent HashMap in NettyServerCnxnFactory
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Mollitor updated ZOOKEEPER-3365:
--
Description:
{code:java|title=NettyServerCnxnFactory.java}
// Access to ipMap or to any Set contained in the map needs to be
// protected with synchronized (ipMap) { ... }
private final Map> ipMap = new
HashMap<>();
private void addCnxn(NettyServerCnxn cnxn) {
cnxns.add(cnxn);
synchronized (ipMap){
InetAddress addr =
((InetSocketAddress)cnxn.getChannel().remoteAddress()).getAddress();
Set s = ipMap.get(addr);
if (s == null) {
s = new HashSet<>();
ipMap.put(addr, s);
}
s.add(cnxn);
}
}
{code}
This can be done better (less code, less contention) with Java 8 Map API.
Although, as I look at this, the only thing this is used for is a count of the
number of connections from each address. Maybe this should just store a count
instead of a collection.
https://github.com/apache/zookeeper/blob/f69ad1b0fed88da3c1b67fd73031e7248c0564f7/zookeeper-server/src/main/java/org/apache/zookeeper/server/NettyServerCnxnFactory.java
Also note that an exclusive lock is required with each interaction of the
table. By moving to a {{ConcurrentHashMap}}:
bq. Retrieval operations (including get) generally do not block, so may overlap
with update operations (including put and remove).
https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentHashMap.html
Removing this lock should improve ZK's performance for highly concurrent client
workloads, especially since its Async Netty operations, unless of course there
are other locks elsewhere.
was:
{code:java|title=NettyServerCnxnFactory.java}
// Access to ipMap or to any Set contained in the map needs to be
// protected with synchronized (ipMap) { ... }
private final Map> ipMap = new
HashMap<>();
private void addCnxn(NettyServerCnxn cnxn) {
cnxns.add(cnxn);
synchronized (ipMap){
InetAddress addr =
((InetSocketAddress)cnxn.getChannel().remoteAddress()).getAddress();
Set s = ipMap.get(addr);
if (s == null) {
s = new HashSet<>();
ipMap.put(addr, s);
}
s.add(cnxn);
}
}
{code}
This can be done better (less code, less contention) with Java 8 Map API.
Although, as I look at this, the only thing this is used for is a count of the
number of connections from each address. Maybe this should just store a count
instead of a collection.
https://github.com/apache/zookeeper/blob/f69ad1b0fed88da3c1b67fd73031e7248c0564f7/zookeeper-server/src/main/java/org/apache/zookeeper/server/NettyServerCnxnFactory.java
> Use Concurrent HashMap in NettyServerCnxnFactory
> -
>
> Key: ZOOKEEPER-3365
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3365
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.6.0
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Minor
> Labels: pull-request-available
> Fix For: 3.6.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> {code:java|title=NettyServerCnxnFactory.java}
> // Access to ipMap or to any Set contained in the map needs to be
> // protected with synchronized (ipMap) { ... }
> private final Map> ipMap = new
> HashMap<>();
> private void addCnxn(NettyServerCnxn cnxn) {
> cnxns.add(cnxn);
> synchronized (ipMap){
> InetAddress addr =
>
> ((InetSocketAddress)cnxn.getChannel().remoteAddress()).getAddress();
> Set s = ipMap.get(addr);
> if (s == null) {
> s = new HashSet<>();
> ipMap.put(addr, s);
> }
> s.add(cnxn);
> }
> }
> {code}
> This can be done better (less code, less contention) with Java 8 Map API.
> Although, as I look at this, the only thing this is used for is a count of
> the number of connections from each address. Maybe this should just store a
> count instead of a collection.
> https://github.com/apache/zookeeper/blob/f69ad1b0fed88da3c1b67fd73031e7248c0564f7/zookeeper-server/src/main/java/org/apache/zookeeper/server/NettyServerCnxnFactory.java
> Also note that an exclusive lock is required with each interaction of the
> table. By moving to a {{ConcurrentHashMap}}:
> bq. Retrieval operations (including get) generally do not block, so may
> overlap with update operations (including put and remove).
> https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ConcurrentHashMap.html
> Removing this lock should
[jira] [Commented] (ZOOKEEPER-3365) Use Concurrent HashMap in NettyServerCnxnFactory
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16817175#comment-16817175
]
David Mollitor commented on ZOOKEEPER-3365:
---
I provided two different PRs with two different implementations:
https://github.com/apache/zookeeper/pull/911
Same as current, but with {{ConcurrentHashMap}}
https://github.com/apache/zookeeper/pull/912
With {{ConcurrentHashMap}} and a counter
> Use Concurrent HashMap in NettyServerCnxnFactory
> -
>
> Key: ZOOKEEPER-3365
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3365
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.6.0
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Minor
> Labels: pull-request-available
> Fix For: 3.6.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {code:java|title=NettyServerCnxnFactory.java}
> // Access to ipMap or to any Set contained in the map needs to be
> // protected with synchronized (ipMap) { ... }
> private final Map> ipMap = new
> HashMap<>();
> private void addCnxn(NettyServerCnxn cnxn) {
> cnxns.add(cnxn);
> synchronized (ipMap){
> InetAddress addr =
>
> ((InetSocketAddress)cnxn.getChannel().remoteAddress()).getAddress();
> Set s = ipMap.get(addr);
> if (s == null) {
> s = new HashSet<>();
> ipMap.put(addr, s);
> }
> s.add(cnxn);
> }
> }
> {code}
> This can be done better (less code, less contention) with Java 8 Map API.
> Although, as I look at this, the only thing this is used for is a count of
> the number of connections from each address. Maybe this should just store a
> count instead of a collection.
> https://github.com/apache/zookeeper/blob/f69ad1b0fed88da3c1b67fd73031e7248c0564f7/zookeeper-server/src/main/java/org/apache/zookeeper/server/NettyServerCnxnFactory.java
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3365) Use Concurrent HashMap in NettyServerCnxnFactory
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Mollitor updated ZOOKEEPER-3365:
--
Summary: Use Concurrent HashMap in NettyServerCnxnFactory (was: Use New
Concurrent HashMap in NettyServerCnxnFactory )
> Use Concurrent HashMap in NettyServerCnxnFactory
> -
>
> Key: ZOOKEEPER-3365
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3365
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.6.0
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Minor
> Fix For: 3.6.0
>
>
> {code:java|title=NettyServerCnxnFactory.java}
> // Access to ipMap or to any Set contained in the map needs to be
> // protected with synchronized (ipMap) { ... }
> private final Map> ipMap = new
> HashMap<>();
> private void addCnxn(NettyServerCnxn cnxn) {
> cnxns.add(cnxn);
> synchronized (ipMap){
> InetAddress addr =
>
> ((InetSocketAddress)cnxn.getChannel().remoteAddress()).getAddress();
> Set s = ipMap.get(addr);
> if (s == null) {
> s = new HashSet<>();
> ipMap.put(addr, s);
> }
> s.add(cnxn);
> }
> }
> {code}
> This can be done better (less code, less contention) with Java 8 Map API.
> Although, as I look at this, the only thing this is used for is a count of
> the number of connections from each address. Maybe this should just store a
> count instead of a collection.
> https://github.com/apache/zookeeper/blob/f69ad1b0fed88da3c1b67fd73031e7248c0564f7/zookeeper-server/src/main/java/org/apache/zookeeper/server/NettyServerCnxnFactory.java
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-3365) Use New Concurrent HashMap in NettyServerCnxnFactory
David Mollitor created ZOOKEEPER-3365:
-
Summary: Use New Concurrent HashMap in NettyServerCnxnFactory
Key: ZOOKEEPER-3365
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3365
Project: ZooKeeper
Issue Type: Improvement
Components: server
Affects Versions: 3.6.0
Reporter: David Mollitor
Assignee: David Mollitor
Fix For: 3.6.0
{code:java|title=NettyServerCnxnFactory.java}
// Access to ipMap or to any Set contained in the map needs to be
// protected with synchronized (ipMap) { ... }
private final Map> ipMap = new
HashMap<>();
private void addCnxn(NettyServerCnxn cnxn) {
cnxns.add(cnxn);
synchronized (ipMap){
InetAddress addr =
((InetSocketAddress)cnxn.getChannel().remoteAddress()).getAddress();
Set s = ipMap.get(addr);
if (s == null) {
s = new HashSet<>();
ipMap.put(addr, s);
}
s.add(cnxn);
}
}
{code}
This can be done better (less code, less contention) with Java 8 Map API.
Although, as I look at this, the only thing this is used for is a count of the
number of connections from each address. Maybe this should just store a count
instead of a collection.
https://github.com/apache/zookeeper/blob/f69ad1b0fed88da3c1b67fd73031e7248c0564f7/zookeeper-server/src/main/java/org/apache/zookeeper/server/NettyServerCnxnFactory.java
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-3352) Use LevelDB For Backend
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16815463#comment-16815463 ] David Mollitor commented on ZOOKEEPER-3352: --- I am a bit confused on the requirement for ACID compliance? My understanding is that the consistency was a result of the quorum agreement protocol. Is there some sort of ACID mechanism currently in 3.x? bq. If you require a high random write throughput (>10,000 w/sec) _or you need to use spinning disks then_ LevelDB could be a good choice. If your application is read-heavy or does a lot of range scans then Bolt could be a good choice. I would go a step further and say that LSM has a *much faster* write than B+tree. LSM performs a simple append on a write-ahead log file when a record is inserted, for a B+tree, it has to seek around the single file for each insert to ensure that related data is co-located. Theoretically, the B+tree has a faster read speed and faster scan speed than LSM. However, this only when comparing disk reads. When data is co-located in a single file, scans are faster. When data is read with LSM, related records may be sprayed across multiple files, requiring many seeks around the disk to load all the records. However, ZK has a tradition of storing its entire data set in-memory for fast look ups. If this continues (which I recommend) then data is never being read from disk and the B+tree loses its advantage. > Use LevelDB For Backend > --- > > Key: ZOOKEEPER-3352 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3352 > Project: ZooKeeper > Issue Type: New Feature > Components: server >Reporter: David Mollitor >Assignee: David Mollitor >Priority: Critical > Fix For: 4.0.0 > > > Use LevelDB for managing data stored in ZK (transaction logs and snapshots). > https://stackoverflow.com/questions/6779669/does-leveldb-support-java -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-3179) Add snapshot compression to reduce the disk IO
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814549#comment-16814549 ] David Mollitor commented on ZOOKEEPER-3179: --- Also, requires update to docs. > Add snapshot compression to reduce the disk IO > -- > > Key: ZOOKEEPER-3179 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3179 > Project: ZooKeeper > Issue Type: Improvement >Reporter: Fangmin Lv >Assignee: Yisong Yue >Priority: Major > Labels: pull-request-available > Fix For: 3.6.0 > > Time Spent: 4h 40m > Remaining Estimate: 0h > > When the snapshot becomes larger, the periodically snapshot after certain > number of txns will be more expensive. Which will in turn affect the maximum > throughput we can support within SLA, because of the disk contention between > snapshot and txn when they're on the same drive. > > With compression like zstd/snappy/gzip, the actual snapshot size could be > much smaller, the compress ratio depends on the actual data. It might make > the recovery time (loading from disk) faster in some cases, but will take > longer sometimes because of the extra time used to compress/decompress. > > Based on the production traffic, the performance various with different > compress method as well, that's why we provided different implementations, we > can select different compress method for different use cases. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-3358) Make Snappy The Default Snapshot Compression Algorithm
David Mollitor created ZOOKEEPER-3358: - Summary: Make Snappy The Default Snapshot Compression Algorithm Key: ZOOKEEPER-3358 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3358 Project: ZooKeeper Issue Type: Improvement Components: server Affects Versions: 3.6.0 Reporter: David Mollitor Fix For: 3.6.0 Now that SnapShots are compressed, thanks to [ZOOKEEPER-3179], make the default algorithm Snappy compression. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-3179) Add snapshot compression to reduce the disk IO
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814483#comment-16814483 ] David Mollitor commented on ZOOKEEPER-3179: --- Does this resolve ZOOKEEPER-1651 ? > Add snapshot compression to reduce the disk IO > -- > > Key: ZOOKEEPER-3179 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3179 > Project: ZooKeeper > Issue Type: Improvement >Reporter: Fangmin Lv >Assignee: Yisong Yue >Priority: Major > Labels: pull-request-available > Fix For: 3.6.0 > > Time Spent: 4h 40m > Remaining Estimate: 0h > > When the snapshot becomes larger, the periodically snapshot after certain > number of txns will be more expensive. Which will in turn affect the maximum > throughput we can support within SLA, because of the disk contention between > snapshot and txn when they're on the same drive. > > With compression like zstd/snappy/gzip, the actual snapshot size could be > much smaller, the compress ratio depends on the actual data. It might make > the recovery time (loading from disk) faster in some cases, but will take > longer sometimes because of the extra time used to compress/decompress. > > Based on the production traffic, the performance various with different > compress method as well, that's why we provided different implementations, we > can select different compress method for different use cases. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-3352) Use LevelDB For Backend
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16814466#comment-16814466
]
David Mollitor commented on ZOOKEEPER-3352:
---
Ya, my drive here for using a third-party library on this is that ZK should not
be writing its own data store. ZK would benefit from a lot of the work that
these specialized projects are doing.
As a start, I was thinking that the ZK Transaction Log could be replaced with
Level/RocksDB.
* Compression: faster writes
* TTL for each record: TXN log entries expire automatically
Since TXN logs are not read that often (as I understand it), the 'read' buffer
for the DB would be disabled.
However, as an entire database system for ZK, I think these key/value stores
are probably a good fit for ZK since they keep everything sorted. For example,
for the following znodes, if the storage key is the path,
* /service/lock-001
* /service/lock-002
* /service/lock-003
To perform an 'ls' on the {{/service}} ZNode would only require a quick scan
> Use LevelDB For Backend
> ---
>
> Key: ZOOKEEPER-3352
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3352
> Project: ZooKeeper
> Issue Type: New Feature
> Components: server
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Critical
> Fix For: 4.0.0
>
>
> Use LevelDB for managing data stored in ZK (transaction logs and snapshots).
> https://stackoverflow.com/questions/6779669/does-leveldb-support-java
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-3352) Use LevelDB For Backend
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813824#comment-16813824
]
David Mollitor commented on ZOOKEEPER-3352:
---
Thanks Brian,
Interesting to note that:
{quote}It is built on earlier work on LevelDB
{quote}
> Use LevelDB For Backend
> ---
>
> Key: ZOOKEEPER-3352
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3352
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Major
> Fix For: 4.0.0
>
>
> Use LevelDB for managing data stored in ZK (transaction logs and snapshots).
> https://stackoverflow.com/questions/6779669/does-leveldb-support-java
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-3357) Remove Dead Link from ZooKeeper Programmer's Guide
David Mollitor created ZOOKEEPER-3357: - Summary: Remove Dead Link from ZooKeeper Programmer's Guide Key: ZOOKEEPER-3357 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3357 Project: ZooKeeper Issue Type: Improvement Components: documentation Affects Versions: 3.5.4, 3.6.0 Reporter: David Mollitor Assignee: David Mollitor Fix For: 3.6.0, 3.5.5 Remove dead link to _ZooKeeper Talk at the Hadoup Summit 2008_ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-3355) Remove 'tbd' From Docs
David Mollitor created ZOOKEEPER-3355: - Summary: Remove 'tbd' From Docs Key: ZOOKEEPER-3355 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3355 Project: ZooKeeper Issue Type: Improvement Components: documentation Affects Versions: 3.5.4, 3.6.0 Reporter: David Mollitor Assignee: David Mollitor Fix For: 3.6.0, 3.5.5 For years, there have been lots of 'tbd' recorded in the documentation. It does not look very polished and there is no one working on these. I think it's time to finally remove them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ZOOKEEPER-3342) Use StandardCharsets
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Mollitor reassigned ZOOKEEPER-3342:
-
Assignee: David Mollitor
> Use StandardCharsets
>
>
> Key: ZOOKEEPER-3342
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3342
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.6.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> {quote}
> Encodes this String into a sequence of bytes using the platform's default
> charset, storing the result into a new byte array. The behavior of this
> method when this string cannot be encoded in the default charset is
> unspecified.
> https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#getBytes--
> {quote}
> Since this is a distributed system, it is always possible that different
> nodes have different default charsets defined. I think it's most safe to
> specify it explicitly across all nodes for safety sake. You could for example
> see a situation where an upgrade JVM uses a different default and during a
> rolling upgrade of the JVM, different nodes now have a different default.
> * The default charset is usually "ISO-8859-1". UTF-8 covers more of our
> international friends.
> * Explicitly specifying the CharSet yields slight performance gains
> * Explicitly specifying the CharSet removes the need for try/catch blocks of
> UnsupportedEncodingException
> https://blog.codecentric.de/en/2014/04/faster-cleaner-code-since-java-7/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (ZOOKEEPER-3339) Improve Debug and Trace Log Statements
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Mollitor reassigned ZOOKEEPER-3339: - Assignee: David Mollitor > Improve Debug and Trace Log Statements > -- > > Key: ZOOKEEPER-3339 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3339 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: David Mollitor >Assignee: David Mollitor >Priority: Minor > Labels: pull-request-available > Fix For: 3.6.0 > > Time Spent: 40m > Remaining Estimate: 0h > > SLF4J supports an advanced feature called parameterized logging which can > significantly boost logging performance for disabled logging statement. > Review all logging and ensure that it adheres to parameterized logging. > https://www.slf4j.org/faq.html#logging_performance -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ZOOKEEPER-3338) Review of BufferStats Class
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Mollitor reassigned ZOOKEEPER-3338: - Assignee: David Mollitor > Review of BufferStats Class > --- > > Key: ZOOKEEPER-3338 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3338 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: David Mollitor >Assignee: David Mollitor >Priority: Trivial > Labels: pull-request-available > Fix For: 3.6.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > * Faster to use StringBuilder than String Format > * Tidy up -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ZOOKEEPER-3352) Use LevelDB For Backend
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Mollitor reassigned ZOOKEEPER-3352: - Assignee: David Mollitor > Use LevelDB For Backend > --- > > Key: ZOOKEEPER-3352 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3352 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: David Mollitor >Assignee: David Mollitor >Priority: Major > Fix For: 4.0.0 > > > Use LevelDB for managing data stored in ZK (transaction logs and snapshots). > https://stackoverflow.com/questions/6779669/does-leveldb-support-java -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ZOOKEEPER-3348) Make TxnLog and TxnLog Iterator Closable
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Mollitor reassigned ZOOKEEPER-3348: - Assignee: David Mollitor > Make TxnLog and TxnLog Iterator Closable > > > Key: ZOOKEEPER-3348 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3348 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: David Mollitor >Assignee: David Mollitor >Priority: Minor > Labels: pull-request-available > Fix For: 3.6.0 > > Time Spent: 20m > Remaining Estimate: 0h > > [https://docs.oracle.com/javase/7/docs/api/java/io/Closeable.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ZOOKEEPER-3347) Improve PathTrie Consistency
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Mollitor reassigned ZOOKEEPER-3347:
-
Assignee: David Mollitor
> Improve PathTrie Consistency
> -
>
> Key: ZOOKEEPER-3347
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3347
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.6.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> There is a bunch of synchronization that occurs in the {{PathTrie}}. Each
> node in the tree requires a lock to view its children, so to traverse a tree
> that is 8 nodes deep, it is required to lock 8 different times. Also, I'm
> not really sure that the locking is consistent; a node deep in the tree can
> be negatively impacted by another thread deleting the node's parent at the
> same time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (ZOOKEEPER-3340) Improve Queue Usage in QuorumCnxManager.java
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Mollitor reassigned ZOOKEEPER-3340:
-
Assignee: David Mollitor
> Improve Queue Usage in QuorumCnxManager.java
>
>
> Key: ZOOKEEPER-3340
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3340
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Reporter: David Mollitor
>Assignee: David Mollitor
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.6.0
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> I was recently profiling a on a ZK Quorum Leader in a low-volume environment
> and noticed that most of its time was spent in
> {{QuorumCnxManager#RecvWorker}}. Nothing wrong with that, but it did draw my
> attention to it. I noticed that {{Queue}} interactions are a bit... verbose.
> I would like to propose that we streamline this area of the code.
>
> [https://github.com/apache/zookeeper/blob/master/zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/QuorumCnxManager.java#L1291-L1309]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3352) Use LevelDB For Backend
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Mollitor updated ZOOKEEPER-3352: -- Priority: Major (was: Critical) > Use LevelDB For Backend > --- > > Key: ZOOKEEPER-3352 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3352 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: David Mollitor >Priority: Major > Fix For: 4.0.0 > > > Use LevelDB for managing data stored in ZK (transaction logs and snapshots). > https://stackoverflow.com/questions/6779669/does-leveldb-support-java -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3352) Use LevelDB For Backend
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Mollitor updated ZOOKEEPER-3352: -- Fix Version/s: 4.0.0 Description: Use LevelDB for managing data stored in ZK (transaction logs and snapshots). https://stackoverflow.com/questions/6779669/does-leveldb-support-java was: Use LevelDB for managing data stored in ZK (transaction logs and snapshots). https://stackoverflow.com/questions/6779669/does-leveldb-support-java Target 2.0 > Use LevelDB For Backend > --- > > Key: ZOOKEEPER-3352 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3352 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: David Mollitor >Priority: Critical > Fix For: 4.0.0 > > > Use LevelDB for managing data stored in ZK (transaction logs and snapshots). > https://stackoverflow.com/questions/6779669/does-leveldb-support-java -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-102) Need to replace Jute with supported code
[ https://issues.apache.org/jira/browse/ZOOKEEPER-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16813362#comment-16813362 ] David Mollitor commented on ZOOKEEPER-102: -- [~maoling] Instead of sinking even more time into jute, may I recommend that ZK simply replace the jute framework with something else? Protobufs is perhaps the best replacement, but ZK, being part of Apache, should probably use an Apache serialization library (eat Apache dog food / drink Apache champagne). * Apache Avro * Apache Thrift * Google Protobufs I have recently put some of my own time into improving Avro and Thrift. If you would like to improve performance of serialization, best that everyone focuses their energy on these libraries. > Need to replace Jute with supported code > > > Key: ZOOKEEPER-102 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-102 > Project: ZooKeeper > Issue Type: Improvement >Reporter: Benjamin Reed >Priority: Major > Fix For: 4.0.0 > > > ZooKeeper currently uses Jute to serialize objects to put on the wire and on > disk. We pulled Jute out of Hadoop and added a C binding. Both versions of > Jute have evolved (although Hadoop still doesn't have a C binding). It would > be nice to use a more standard serialization library. Some options include > Thrift or Google's protocol buffers. > Our main requirements would be Java and C bindings and good performance. (For > example, serializing to XML would give us incredibly bad performance and > would not be acceptible!) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-3352) Use LevelDB For Backend
David Mollitor created ZOOKEEPER-3352: - Summary: Use LevelDB For Backend Key: ZOOKEEPER-3352 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3352 Project: ZooKeeper Issue Type: Improvement Components: server Reporter: David Mollitor Use LevelDB for managing data stored in ZK (transaction logs and snapshots). https://stackoverflow.com/questions/6779669/does-leveldb-support-java Target 2.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-3348) Make TxnLog and TxnLog Iterator Closable
David Mollitor created ZOOKEEPER-3348: - Summary: Make TxnLog and TxnLog Iterator Closable Key: ZOOKEEPER-3348 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3348 Project: ZooKeeper Issue Type: Improvement Components: server Reporter: David Mollitor Fix For: 3.6.0 [https://docs.oracle.com/javase/7/docs/api/java/io/Closeable.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3347) Improve PathTrie Consistency
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Mollitor updated ZOOKEEPER-3347:
--
Fix Version/s: 3.6.0
> Improve PathTrie Consistency
> -
>
> Key: ZOOKEEPER-3347
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3347
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Reporter: David Mollitor
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.6.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There is a bunch of synchronization that occurs in the {{PathTrie}}. Each
> node in the tree requires a lock to view its children, so to traverse a tree
> that is 8 nodes deep, it is required to lock 8 different times. Also, I'm
> not really sure that the locking is consistent; a node deep in the tree can
> be negatively impacted by another thread deleting the node's parent at the
> same time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3340) Improve Queue Usage in QuorumCnxManager.java
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Mollitor updated ZOOKEEPER-3340:
--
Affects Version/s: (was: 3.6.0)
Fix Version/s: 3.6.0
> Improve Queue Usage in QuorumCnxManager.java
>
>
> Key: ZOOKEEPER-3340
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3340
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Reporter: David Mollitor
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.6.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I was recently profiling a on a ZK Quorum Leader in a low-volume environment
> and noticed that most of its time was spent in
> {{QuorumCnxManager#RecvWorker}}. Nothing wrong with that, but it did draw my
> attention to it. I noticed that {{Queue}} interactions are a bit... verbose.
> I would like to propose that we streamline this area of the code.
>
> [https://github.com/apache/zookeeper/blob/master/zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/QuorumCnxManager.java#L1291-L1309]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3340) Improve Queue Usage in QuorumCnxManager.java
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Mollitor updated ZOOKEEPER-3340:
--
Affects Version/s: 3.6.0
> Improve Queue Usage in QuorumCnxManager.java
>
>
> Key: ZOOKEEPER-3340
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3340
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.6.0
>Reporter: David Mollitor
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I was recently profiling a on a ZK Quorum Leader in a low-volume environment
> and noticed that most of its time was spent in
> {{QuorumCnxManager#RecvWorker}}. Nothing wrong with that, but it did draw my
> attention to it. I noticed that {{Queue}} interactions are a bit... verbose.
> I would like to propose that we streamline this area of the code.
>
> [https://github.com/apache/zookeeper/blob/master/zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/QuorumCnxManager.java#L1291-L1309]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3020) Review of SyncRequestProcessor
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Mollitor updated ZOOKEEPER-3020:
--
Fix Version/s: 3.6.0
> Review of SyncRequestProcessor
> --
>
> Key: ZOOKEEPER-3020
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3020
> Project: ZooKeeper
> Issue Type: Improvement
>Reporter: David Mollitor
>Priority: Minor
> Labels: pull-request-available
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER.3020.1.patch
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> # Use {{ArrayDeque}} instead of {{LinkedList}}
> # Use {{ThreadLocalRandom}} instead of {{Random}}
> # Remove the 'running' flag - use the {{Thread#join}} facility to detect if
> the thread has stopped running. Using a flag can cause race condition issues
> and is superfluous.
> # Make static final variable names in all caps
> # General cleanup
> {quote}
> This class is likely to be faster than Stack when used as a stack, and faster
> than LinkedList when used as a queue.
> {quote}
> https://docs.oracle.com/javase/7/docs/api/java/util/ArrayDeque.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3335) Improve the usage of Collections
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Mollitor updated ZOOKEEPER-3335: -- Fix Version/s: 3.6.0 Description: bq. This class is likely to be faster than Stack when used as a stack, and faster than LinkedList when used as a queue. https://docs.oracle.com/javase/7/docs/api/java/util/ArrayDeque.html was: bq. This class is likely to be faster than Stack when used as a stack, and faster than LinkedList when used as a queue. https://docs.oracle.com/javase/7/docs/api/java/util/ArrayDeque.html Component/s: server > Improve the usage of Collections > > > Key: ZOOKEEPER-3335 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3335 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: David Mollitor >Priority: Minor > Labels: pull-request-available > Fix For: 3.6.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > bq. This class is likely to be faster than Stack when used as a stack, and > faster than LinkedList when used as a queue. > https://docs.oracle.com/javase/7/docs/api/java/util/ArrayDeque.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3338) Review of BufferStats Class
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Mollitor updated ZOOKEEPER-3338: -- Fix Version/s: 3.6.0 > Review of BufferStats Class > --- > > Key: ZOOKEEPER-3338 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3338 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: David Mollitor >Priority: Trivial > Labels: pull-request-available > Fix For: 3.6.0 > > Time Spent: 10m > Remaining Estimate: 0h > > * Faster to use StringBuilder than String Format > * Tidy up -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3339) Improve Debug and Trace Log Statements
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Mollitor updated ZOOKEEPER-3339: -- Fix Version/s: 3.6.0 Component/s: server > Improve Debug and Trace Log Statements > -- > > Key: ZOOKEEPER-3339 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3339 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: David Mollitor >Priority: Minor > Labels: pull-request-available > Fix For: 3.6.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > SLF4J supports an advanced feature called parameterized logging which can > significantly boost logging performance for disabled logging statement. > Review all logging and ensure that it adheres to parameterized logging. > https://www.slf4j.org/faq.html#logging_performance -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3342) Use StandardCharsets
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Mollitor updated ZOOKEEPER-3342:
--
Fix Version/s: 3.6.0
Component/s: server
> Use StandardCharsets
>
>
> Key: ZOOKEEPER-3342
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3342
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Reporter: David Mollitor
>Priority: Major
> Labels: pull-request-available
> Fix For: 3.6.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> {quote}
> Encodes this String into a sequence of bytes using the platform's default
> charset, storing the result into a new byte array. The behavior of this
> method when this string cannot be encoded in the default charset is
> unspecified.
> https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#getBytes--
> {quote}
> Since this is a distributed system, it is always possible that different
> nodes have different default charsets defined. I think it's most safe to
> specify it explicitly across all nodes for safety sake. You could for example
> see a situation where an upgrade JVM uses a different default and during a
> rolling upgrade of the JVM, different nodes now have a different default.
> * The default charset is usually "ISO-8859-1". UTF-8 covers more of our
> international friends.
> * Explicitly specifying the CharSet yields slight performance gains
> * Explicitly specifying the CharSet removes the need for try/catch blocks of
> UnsupportedEncodingException
> https://blog.codecentric.de/en/2014/04/faster-cleaner-code-since-java-7/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3341) Remove Superfluous ByteBuffer Duplicate
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Mollitor updated ZOOKEEPER-3341:
--
Fix Version/s: 3.5.6
3.6.0
> Remove Superfluous ByteBuffer Duplicate
> ---
>
> Key: ZOOKEEPER-3341
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3341
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Reporter: David Mollitor
>Priority: Trivial
> Labels: pull-request-available
> Fix For: 3.6.0, 3.5.6
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> {code:java|title=QuorumCnxManager.java}
> byte[] msgArray = new byte[length];
> din.readFully(msgArray, 0, length);
> ByteBuffer message = ByteBuffer.wrap(msgArray);
> addToRecvQueue(new Message(message.duplicate(), sid));
> {code}
> The {{message}} is being duplicated and the original is GC'ed. Just pass the
> {{message}}; do not bother with making a duplicate. I think this is a
> copy+paste bug.
> https://github.com/apache/zookeeper/blob/master/zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/QuorumCnxManager.java#L1195-L1198
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3342) Use StandardCharsets
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Mollitor updated ZOOKEEPER-3342:
--
Description:
{quote}
Encodes this String into a sequence of bytes using the platform's default
charset, storing the result into a new byte array. The behavior of this method
when this string cannot be encoded in the default charset is unspecified.
https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#getBytes--
{quote}
Since this is a distributed system, it is always possible that different nodes
have different default charsets defined. I think it's most safe to specify it
explicitly across all nodes for safety sake. You could for example see a
situation where an upgrade JVM uses a different default and during a rolling
upgrade of the JVM, different nodes now have a different default.
* The default charset is usually "ISO-8859-1". UTF-8 covers more of our
international friends.
* Explicitly specifying the CharSet yields slight performance gains
* Explicitly specifying the CharSet removes the need for try/catch blocks of
UnsupportedEncodingException
https://blog.codecentric.de/en/2014/04/faster-cleaner-code-since-java-7/
> Use StandardCharsets
>
>
> Key: ZOOKEEPER-3342
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3342
> Project: ZooKeeper
> Issue Type: Improvement
>Reporter: David Mollitor
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> {quote}
> Encodes this String into a sequence of bytes using the platform's default
> charset, storing the result into a new byte array. The behavior of this
> method when this string cannot be encoded in the default charset is
> unspecified.
> https://docs.oracle.com/javase/8/docs/api/java/lang/String.html#getBytes--
> {quote}
> Since this is a distributed system, it is always possible that different
> nodes have different default charsets defined. I think it's most safe to
> specify it explicitly across all nodes for safety sake. You could for example
> see a situation where an upgrade JVM uses a different default and during a
> rolling upgrade of the JVM, different nodes now have a different default.
> * The default charset is usually "ISO-8859-1". UTF-8 covers more of our
> international friends.
> * Explicitly specifying the CharSet yields slight performance gains
> * Explicitly specifying the CharSet removes the need for try/catch blocks of
> UnsupportedEncodingException
> https://blog.codecentric.de/en/2014/04/faster-cleaner-code-since-java-7/
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3347) Improve PathTrie Consistency
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Mollitor updated ZOOKEEPER-3347:
--
Summary: Improve PathTrie Consistency (was: Review PathTrie Consistency )
> Improve PathTrie Consistency
> -
>
> Key: ZOOKEEPER-3347
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3347
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Reporter: David Mollitor
>Priority: Major
>
> There is a bunch of synchronization that occurs in the {{PathTrie}}. Each
> node in the tree requires a lock to view its children, so to traverse a tree
> that is 8 nodes deep, it is required to lock 8 different times. Also, I'm
> not really sure that the locking is consistent; a node deep in the tree can
> be negatively impacted by another thread deleting the node's parent at the
> same time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3347) Review PathTrie Consistency
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Mollitor updated ZOOKEEPER-3347:
--
Summary: Review PathTrie Consistency (was: PathTrie Consistency )
> Review PathTrie Consistency
>
>
> Key: ZOOKEEPER-3347
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3347
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Reporter: David Mollitor
>Priority: Major
>
> There is a bunch of synchronization that occurs in the {{PathTrie}}. Each
> node in the tree requires a lock to view its children, so to traverse a tree
> that is 8 nodes deep, it is required to lock 8 different times. Also, I'm
> not really sure that the locking is consistent; a node deep in the tree can
> be negatively impacted by another thread deleting the node's parent at the
> same time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-3347) PathTrie Consistency
David Mollitor created ZOOKEEPER-3347:
-
Summary: PathTrie Consistency
Key: ZOOKEEPER-3347
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3347
Project: ZooKeeper
Issue Type: Improvement
Components: server
Reporter: David Mollitor
There is a bunch of synchronization that occurs in the {{PathTrie}}. Each node
in the tree requires a lock to view its children, so to traverse a tree that is
8 nodes deep, it is required to lock 8 different times. Also, I'm not really
sure that the locking is consistent; a node deep in the tree can be negatively
impacted by another thread deleting the node's parent at the same time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-3342) Use StandardCharsets
David Mollitor created ZOOKEEPER-3342: - Summary: Use StandardCharsets Key: ZOOKEEPER-3342 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3342 Project: ZooKeeper Issue Type: Improvement Reporter: David Mollitor -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3341) Remove Superfluous ByteBuffer Duplicate
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Mollitor updated ZOOKEEPER-3341:
--
Summary: Remove Superfluous ByteBuffer Duplicate (was: Superfluous
ByteBuffer Duplicate)
> Remove Superfluous ByteBuffer Duplicate
> ---
>
> Key: ZOOKEEPER-3341
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3341
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
>Reporter: David Mollitor
>Priority: Trivial
>
> {code:java|title=QuorumCnxManager.java}
> byte[] msgArray = new byte[length];
> din.readFully(msgArray, 0, length);
> ByteBuffer message = ByteBuffer.wrap(msgArray);
> addToRecvQueue(new Message(message.duplicate(), sid));
> {code}
> The {{message}} is being duplicated and the original is GC'ed. Just pass the
> {{message}}; do not bother with making a duplicate. I think this is a
> copy+paste bug.
> https://github.com/apache/zookeeper/blob/master/zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/QuorumCnxManager.java#L1195-L1198
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-3341) Superfluous ByteBuffer Duplicate
David Mollitor created ZOOKEEPER-3341:
-
Summary: Superfluous ByteBuffer Duplicate
Key: ZOOKEEPER-3341
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3341
Project: ZooKeeper
Issue Type: Improvement
Components: server
Reporter: David Mollitor
{code:java|title=QuorumCnxManager.java}
byte[] msgArray = new byte[length];
din.readFully(msgArray, 0, length);
ByteBuffer message = ByteBuffer.wrap(msgArray);
addToRecvQueue(new Message(message.duplicate(), sid));
{code}
The {{message}} is being duplicated and the original is GC'ed. Just pass the
{{message}}; do not bother with making a duplicate. I think this is a
copy+paste bug.
https://github.com/apache/zookeeper/blob/master/zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/QuorumCnxManager.java#L1195-L1198
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-3340) Improve Queue Usage in QuorumCnxManager.java
David Mollitor created ZOOKEEPER-3340:
-
Summary: Improve Queue Usage in QuorumCnxManager.java
Key: ZOOKEEPER-3340
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3340
Project: ZooKeeper
Issue Type: Improvement
Components: server
Reporter: David Mollitor
I was recently profiling a on a ZK Quorum Leader in a low-volume environment
and noticed that most of its time was spent in {{QuorumCnxManager#RecvWorker}}.
Nothing wrong with that, but it did draw my attention to it. I noticed that
{{Queue}} interactions are a bit... verbose. I would like to propose that we
streamline this area of the code.
[https://github.com/apache/zookeeper/blob/master/zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/QuorumCnxManager.java#L1291-L1309]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-3020) Review of SyncRequestProcessor
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16804164#comment-16804164
]
David Mollitor commented on ZOOKEEPER-3020:
---
Created a new PR
[https://github.com/apache/zookeeper/pull/876]
> Review of SyncRequestProcessor
> --
>
> Key: ZOOKEEPER-3020
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3020
> Project: ZooKeeper
> Issue Type: Improvement
>Reporter: David Mollitor
>Priority: Minor
> Labels: pull-request-available
> Attachments: ZOOKEEPER.3020.1.patch
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> # Use {{ArrayDeque}} instead of {{LinkedList}}
> # Use {{ThreadLocalRandom}} instead of {{Random}}
> # Remove the 'running' flag - use the {{Thread#join}} facility to detect if
> the thread has stopped running. Using a flag can cause race condition issues
> and is superfluous.
> # Make static final variable names in all caps
> # General cleanup
> {quote}
> This class is likely to be faster than Stack when used as a stack, and faster
> than LinkedList when used as a queue.
> {quote}
> https://docs.oracle.com/javase/7/docs/api/java/util/ArrayDeque.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-3339) Improve Debug and Trace Log Statements
David Mollitor created ZOOKEEPER-3339: - Summary: Improve Debug and Trace Log Statements Key: ZOOKEEPER-3339 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3339 Project: ZooKeeper Issue Type: Improvement Reporter: David Mollitor SLF4J supports an advanced feature called parameterized logging which can significantly boost logging performance for disabled logging statement. Review all logging and ensure that it adheres to parameterized logging. https://www.slf4j.org/faq.html#logging_performance -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3338) Review of BufferStats Class
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Mollitor updated ZOOKEEPER-3338: -- Summary: Review of BufferStats Class (was: Review of BufferStats) > Review of BufferStats Class > --- > > Key: ZOOKEEPER-3338 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3338 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: David Mollitor >Priority: Trivial > > * Faster to use StringBuilder than String Format > * Tidy up -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-3338) Review of BufferStats
David Mollitor created ZOOKEEPER-3338: - Summary: Review of BufferStats Key: ZOOKEEPER-3338 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3338 Project: ZooKeeper Issue Type: Improvement Components: server Reporter: David Mollitor * Faster to use StringBuilder than String Format * Tidy up -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3335) Improve the usage of Collections
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Mollitor updated ZOOKEEPER-3335: -- Summary: Improve the usage of Collections (was: Prefer ArrayList over LinkedList) > Improve the usage of Collections > > > Key: ZOOKEEPER-3335 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3335 > Project: ZooKeeper > Issue Type: Improvement >Reporter: David Mollitor >Priority: Minor > Labels: pull-request-available > Time Spent: 1h 20m > Remaining Estimate: 0h > > bq. This class is likely to be faster than Stack when used as a stack, and > faster than LinkedList when used as a queue. > https://docs.oracle.com/javase/7/docs/api/java/util/ArrayDeque.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-3335) Prefer ArrayList over LinkedList
David Mollitor created ZOOKEEPER-3335: - Summary: Prefer ArrayList over LinkedList Key: ZOOKEEPER-3335 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3335 Project: ZooKeeper Issue Type: Improvement Reporter: David Mollitor bq. This class is likely to be faster than Stack when used as a stack, and faster than LinkedList when used as a queue. https://docs.oracle.com/javase/7/docs/api/java/util/ArrayDeque.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
