zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ZOOKEEPER-2933) Ability to monitor the jute.maxBuffer usage in real-time
Date Thu, 09 Nov 2017 12:33:00 GMT

    [ https://issues.apache.org/jira/browse/ZOOKEEPER-2933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16245566#comment-16245566
] 

ASF GitHub Bot commented on ZOOKEEPER-2933:
-------------------------------------------

Github user anmolnar commented on a diff in the pull request:

    https://github.com/apache/zookeeper/pull/415#discussion_r149948702
  
    --- Diff: src/java/test/org/apache/zookeeper/server/util/SerializeUtilsTest.java ---
    @@ -0,0 +1,73 @@
    +/**
    + * Licensed to the Apache Software Foundation (ASF) under one
    + * or more contributor license agreements.  See the NOTICE file
    + * distributed with this work for additional information
    + * regarding copyright ownership.  The ASF licenses this file
    + * to you under the Apache License, Version 2.0 (the
    + * "License"); you may not use this file except in compliance
    + * with the License.  You may obtain a copy of the License at
    + *
    + *     http://www.apache.org/licenses/LICENSE-2.0
    + *
    + * Unless required by applicable law or agreed to in writing, software
    + * distributed under the License is distributed on an "AS IS" BASIS,
    + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    + * See the License for the specific language governing permissions and
    + * limitations under the License.
    + */
    +
    +package org.apache.zookeeper.server.util;
    +
    +import org.apache.jute.OutputArchive;
    +import org.apache.jute.Record;
    +import org.apache.zookeeper.server.Request;
    +import org.apache.zookeeper.txn.TxnHeader;
    +import org.junit.Test;
    +import org.mockito.InOrder;
    +
    +import java.io.IOException;
    +
    +import static org.junit.Assert.assertNotNull;
    +import static org.junit.Assert.assertNull;
    +import static org.mockito.Matchers.any;
    +import static org.mockito.Matchers.eq;
    +import static org.mockito.Mockito.inOrder;
    +import static org.mockito.Mockito.mock;
    +import static org.mockito.Mockito.verify;
    +
    +public class SerializeUtilsTest {
    +
    +    @Test
    +    public void testSerializeRequest_RequestIsNull() {
    +        byte[] data = SerializeUtils.serializeRequest(null);
    +        assertNull(data);
    +    }
    +
    +    @Test
    +    public void testSerializeRequest_RequestHeaderIsNull() {
    +        Request request = new Request(0, 0, 0, null, null, 0);
    +        byte[] data = SerializeUtils.serializeRequest(request);
    +        assertNull(data);
    +    }
    +
    +    @Test
    +    public void testSerializeRequest_WithoutTxn() throws IOException {
    +        TxnHeader header = mock(TxnHeader.class);
    +        Request request = new Request(1, 2, 3, header, null, 4);
    +        byte[] data = SerializeUtils.serializeRequest(request);
    +        assertNotNull(data);
    +        verify(header).serialize(any(OutputArchive.class), eq("hdr"));
    +    }
    +
    +    @Test
    +    public void testSerializeRequest_WithTxn() throws IOException {
    +        Record txn = mock(Record.class);
    +        TxnHeader header = mock(TxnHeader.class);
    +        Request request = new Request(1, 2, 3, header, txn, 4);
    +        byte[] data = SerializeUtils.serializeRequest(request);
    +        assertNotNull(data);
    +        InOrder inOrder = inOrder(header, txn);
    --- End diff --
    
    Very good question, I'd been thinking about it for a while. The reason why I eventually
left it out is that this unit test verifies the behaviour of serializeRequest() method and
_not_ the serialization itself. So basically we have to verify that the right serialize()
methods get called in the right order instead of what they actually do. 
    
    On the other hand, you're right, because if we mock the serialize() methods, they won't
have sideeffect on our test.
    
    What do you think?



> Ability to monitor the jute.maxBuffer usage in real-time
> --------------------------------------------------------
>
>                 Key: ZOOKEEPER-2933
>                 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2933
>             Project: ZooKeeper
>          Issue Type: New Feature
>          Components: jute, server
>            Reporter: Andor Molnar
>            Assignee: Andor Molnar
>              Labels: buffer, buffer-length
>             Fix For: 3.5.4, 3.6.0
>
>
> This is related to jute.maxbuffer problems on the server side when Leader generates a
proposal that doesn't fit into Follower's Jute buffer causing the quorum to be broken.
> Proposed solution is to add the following new JMX Beans:
> 1. Add getJuteMaxBuffer to ZookeeperServerBean which monitors the current jute.maxbuffer
setting,
> 2. Add get last/min/max ProposalSize to LeaderBean which monitors the size of the latest/min/max
proposal.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message