search

ilovesoup / hyracks

Automatically exported from code.google.com/p/hyracks
Apache License 2.0
0 stars 0 forks source link

Deadlock in send-mat-rec-mat-blocking connector policy #81

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
This happens when I run Hivesterix tests using 
send-side-materialize-receive-side-materialize blocking connector policy

Found one Java-level deadlock:
=============================
"pool-3-thread-5":
  waiting to lock monitor 1008ff918 (object 77ae78f28, a edu.uci.ics.hyracks.net.protocols.muxdemux.ChannelControlBlock),
  which is held by "TCPEndpoint IO Thread"
"TCPEndpoint IO Thread":
  waiting to lock monitor 10d849640 (object 77ae64fc8, a edu.uci.ics.hyracks.control.nc.partitions.ReceiveSideMaterializingCollector$PartitionWriter),
  which is held by "pool-3-thread-5"

Java stack information for the threads listed above:
===================================================
"pool-3-thread-5":
    at edu.uci.ics.hyracks.net.protocols.muxdemux.ChannelControlBlock$ReadInterface$1.accept(ChannelControlBlock.java:96)
    - waiting to lock <77ae78f28> (a edu.uci.ics.hyracks.net.protocols.muxdemux.ChannelControlBlock)
    at edu.uci.ics.hyracks.control.nc.net.NetworkInputChannel.recycleBuffer(NetworkInputChannel.java:87)
    at edu.uci.ics.hyracks.control.nc.partitions.ReceiveSideMaterializingCollector$PartitionWriter.run(ReceiveSideMaterializingCollector.java:130)
    - locked <77ae64fc8> (a edu.uci.ics.hyracks.control.nc.partitions.ReceiveSideMaterializingCollector$PartitionWriter)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:680)
"TCPEndpoint IO Thread":
    at edu.uci.ics.hyracks.control.nc.partitions.ReceiveSideMaterializingCollector$PartitionWriter.notifyDataAvailability(ReceiveSideMaterializingCollector.java:106)
    - waiting to lock <77ae64fc8> (a edu.uci.ics.hyracks.control.nc.partitions.ReceiveSideMaterializingCollector$PartitionWriter)
    at edu.uci.ics.hyracks.control.nc.net.NetworkInputChannel$ReadFullBufferAcceptor.accept(NetworkInputChannel.java:124)
    at edu.uci.ics.hyracks.net.protocols.muxdemux.ChannelControlBlock$ReadInterface.flush(ChannelControlBlock.java:163)
    at edu.uci.ics.hyracks.net.protocols.muxdemux.ChannelControlBlock$ReadInterface.read(ChannelControlBlock.java:155)
    at edu.uci.ics.hyracks.net.protocols.muxdemux.ChannelControlBlock.read(ChannelControlBlock.java:320)
    - locked <77ae78f28> (a edu.uci.ics.hyracks.net.protocols.muxdemux.ChannelControlBlock)
    at edu.uci.ics.hyracks.net.protocols.muxdemux.MultiplexedConnection.driveReaderStateMachine(MultiplexedConnection.java:403)
    at edu.uci.ics.hyracks.net.protocols.muxdemux.MultiplexedConnection.notifyIOReady(MultiplexedConnection.java:123)
    at edu.uci.ics.hyracks.net.protocols.tcp.TCPEndpoint$IOThread.run(TCPEndpoint.java:160)

Found one Java-level deadlock:
=============================
"pool-4-thread-9":
  waiting to lock monitor 10302b1e0 (object 77ae891b0, a edu.uci.ics.hyracks.net.protocols.muxdemux.ChannelControlBlock),
  which is held by "TCPEndpoint IO Thread"
"TCPEndpoint IO Thread":
  waiting to lock monitor 10302b288 (object 77af8c440, a edu.uci.ics.hyracks.control.nc.partitions.ReceiveSideMaterializingCollector$PartitionWriter),
  which is held by "pool-4-thread-9"

Java stack information for the threads listed above:
===================================================
"pool-4-thread-9":
    at edu.uci.ics.hyracks.net.protocols.muxdemux.ChannelControlBlock$ReadInterface$1.accept(ChannelControlBlock.java:96)
    - waiting to lock <77ae891b0> (a edu.uci.ics.hyracks.net.protocols.muxdemux.ChannelControlBlock)
    at edu.uci.ics.hyracks.control.nc.net.NetworkInputChannel.recycleBuffer(NetworkInputChannel.java:87)
    at edu.uci.ics.hyracks.control.nc.partitions.ReceiveSideMaterializingCollector$PartitionWriter.run(ReceiveSideMaterializingCollector.java:130)
    - locked <77af8c440> (a edu.uci.ics.hyracks.control.nc.partitions.ReceiveSideMaterializingCollector$PartitionWriter)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:680)
"TCPEndpoint IO Thread":
    at edu.uci.ics.hyracks.control.nc.partitions.ReceiveSideMaterializingCollector$PartitionWriter.notifyDataAvailability(ReceiveSideMaterializingCollector.java:106)
    - waiting to lock <77af8c440> (a edu.uci.ics.hyracks.control.nc.partitions.ReceiveSideMaterializingCollector$PartitionWriter)
    at edu.uci.ics.hyracks.control.nc.net.NetworkInputChannel$ReadFullBufferAcceptor.accept(NetworkInputChannel.java:124)
    at edu.uci.ics.hyracks.net.protocols.muxdemux.ChannelControlBlock$ReadInterface.flush(ChannelControlBlock.java:163)
    at edu.uci.ics.hyracks.net.protocols.muxdemux.ChannelControlBlock$ReadInterface.read(ChannelControlBlock.java:155)
    at edu.uci.ics.hyracks.net.protocols.muxdemux.ChannelControlBlock.read(ChannelControlBlock.java:320)
    - locked <77ae891b0> (a edu.uci.ics.hyracks.net.protocols.muxdemux.ChannelControlBlock)
    at edu.uci.ics.hyracks.net.protocols.muxdemux.MultiplexedConnection.driveReaderStateMachine(MultiplexedConnection.java:403)
    at edu.uci.ics.hyracks.net.protocols.muxdemux.MultiplexedConnection.notifyIOReady(MultiplexedConnection.java:123)
    at edu.uci.ics.hyracks.net.protocols.tcp.TCPEndpoint$IOThread.run(TCPEndpoint.java:160)

Found 2 deadlocks.

Original issue reported on code.google.com by buyingyi@gmail.com on 9 Jul 2012 at 2:09