Mailing-List: contact dev-help@giraph.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@giraph.apache.org
Date: Wed, 29 Mar 2017 18:09:41 +0000 (UTC)
From: "ASF GitHub Bot (JIRA)" <jira@apache.org>
To: giraph-dev@incubator.apache.org
Message-ID: <JIRA.13056773.1489692904000.156943.1490810981539@Atlassian.JIRA>
In-Reply-To: <JIRA.13056773.1489692904000@Atlassian.JIRA>
References: <JIRA.13056773.1489692904000@Atlassian.JIRA> <JIRA.13056773.1489692904347@jira-lw-us.apache.org>
Subject: [jira] [Commented] (GIRAPH-1137) Remove channel probing from Netty
 worker thread for credit-based flow-control
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 29 Mar 2017 18:09:46 -0000


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

ASF GitHub Bot commented on GIRAPH-1137:
----------------------------------------

Github user dlogothetis commented on the issue:

    https://github.com/apache/giraph/pull/26
  
    @heslami, findbugs reports this:
    
    [INFO] [INFO] Synchronization performed on java.util.concurrent.atomic.AtomicInteger in org.apache.giraph.comm.flow_control.CreditBasedFlowControl$2.run() ["org.apache.giraph.comm.flow_control.CreditBasedFlowControl$2"] At CreditBasedFlowControl.java:[lines 237-256]


> Remove channel probing from Netty worker thread for credit-based flow-control
> -----------------------------------------------------------------------------
>
>                 Key: GIRAPH-1137
>                 URL: https://issues.apache.org/jira/browse/GIRAPH-1137
>             Project: Giraph
>          Issue Type: Bug
>            Reporter: Hassan Eslami
>            Assignee: Hassan Eslami
>
> In credit-based flow-control, sometimes, client threads (one type of Netty worker threads used in Giraph) try to send requests to other workers. This is bad practice for Netty and can cause Netty to mark the execution as deadlock-prone (an example exception shown below). Client threads should only be responsible for sending ACK/NACK messages in response to requests, and they should do so by reuseing the channel from which they received the request. In the current implementation, client threads may try to send unsent/cached requests in credit-based flow control. Sending such requests should be delegated to other threads.
> WARN 2017-03-08 06:06:22,104 [netty-client-worker-3] ....
> io.netty.util.concurrent.BlockingOperationException: DefaultChannelPromise@2c455378(incomplete)
> at io.netty.util.concurrent.DefaultPromise.checkDeadLock(DefaultPromise.java:383)
> at io.netty.channel.DefaultChannelPromise.checkDeadLock(DefaultChannelPromise.java:157)
> at io.netty.util.concurrent.DefaultPromise.await0(DefaultPromise.java:343)
> at io.netty.util.concurrent.DefaultPromise.await(DefaultPromise.java:259)
> at org.apache.giraph.utils.ProgressableUtils$ChannelFutureWaitable.waitFor(ProgressableUtils.java:461)
> at org.apache.giraph.utils.ProgressableUtils.waitFor(ProgressableUtils.java:214)
> at org.apache.giraph.utils.ProgressableUtils.waitForever(ProgressableUtils.java:180)
> at org.apache.giraph.utils.ProgressableUtils.waitForever(ProgressableUtils.java:165)
> at org.apache.giraph.utils.ProgressableUtils.awaitChannelFuture(ProgressableUtils.java:132)
> at org.apache.giraph.comm.netty.NettyClient.getNextChannel(NettyClient.java:715)
> at org.apache.giraph.comm.netty.NettyClient.writeRequestToChannel(NettyClient.java:799)
> at org.apache.giraph.comm.netty.NettyClient.doSend(NettyClient.java:789)
> at org.apache.giraph.comm.flow_control.CreditBasedFlowControl.trySendCachedRequests(CreditBasedFlowControl.java:515)
> at org.apache.giraph.comm.flow_control.CreditBasedFlowControl.messageAckReceived(CreditBasedFlowControl.java:485)
> at org.apache.giraph.comm.netty.NettyClient.messageReceived(NettyClient.java:840)
> at org.apache.giraph.comm.netty.handler.ResponseClientHandler.channelRead(ResponseClientHandler.java:87)
> at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:338)
> at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:324)
> at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:153)
> at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:338)
> at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:324)
> at org.apache.giraph.comm.netty.InboundByteCounter.channelRead(InboundByteCounter.java:89)
> at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:338)
> at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:324)
> at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:785)
> at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:126)
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:485)
> at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:452)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:346)
> at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101)
> at java.lang.Thread.run(Thread.java:745)


--
This message was sent by Atlassian JIRA
(v6.3.15#6346)