drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From adeneche <...@git.apache.org>
Subject [GitHub] drill pull request: DRILL-3714: Avoid cascading disconnection when...
Date Thu, 07 Apr 2016 06:48:16 GMT
Github user adeneche commented on a diff in the pull request:

    --- Diff: exec/rpc/src/main/java/org/apache/drill/exec/rpc/RequestIdMap.java ---
    @@ -20,51 +20,82 @@
     import io.netty.buffer.ByteBuf;
     import io.netty.channel.ChannelFuture;
    -import java.util.Map;
    -import java.util.concurrent.ConcurrentHashMap;
    +import java.util.concurrent.atomic.AtomicBoolean;
    +import java.util.concurrent.atomic.AtomicInteger;
     import org.apache.drill.common.exceptions.UserRemoteException;
     import org.apache.drill.exec.proto.UserBitShared.DrillPBError;
    +import com.carrotsearch.hppc.IntObjectHashMap;
    +import com.carrotsearch.hppc.procedures.IntObjectProcedure;
    +import com.google.common.base.Preconditions;
    - * Manages the creation of rpc futures for a particular socket.
    + * Manages the creation of rpc futures for a particular socket <--> socket
    + * connection. Generally speaking, there will be two threads working with this
    + * class (the socket thread and the Request generating thread). Synchronization
    + * is simple with the map being the only thing that is protected. Everything
    + * else works via Atomic variables.
    -public class CoordinationQueue {
    -  static final org.slf4j.Logger logger = org.slf4j.LoggerFactory.getLogger(CoordinationQueue.class);
    +class RequestIdMap {
    +  static final org.slf4j.Logger logger = org.slf4j.LoggerFactory.getLogger(RequestIdMap.class);
    +  private final AtomicInteger value = new AtomicInteger();
    +  private final AtomicBoolean acceptMessage = new AtomicBoolean(true);
    -  private final PositiveAtomicInteger circularInt = new PositiveAtomicInteger();
    --- End diff --
    I didn't notice this. I have a question about this change:
    so we still recycle coordinationIds, it's just that we don't care if they become negative
if the Drillbit runs long enough. Is this correct ?

If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.

View raw message