JPPF Issue Tracker
star_faded.png
Please log in to bookmark issues
bug_report_small.png
CLOSED  Bug report JPPF-96  -  Deadlock in the client: RemoteChannelWrapper / TaskQUeueChecker
Posted Nov 04, 2012 - updated Nov 11, 2012
icon_info.png This issue has been closed with status "Closed" and resolution "RESOLVED".
Issue details
  • Type of issue
    Bug report
  • Status
     
    		 Closed
  • Assigned to
    lolo4j
  • Progress
       
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
    lolo4j
  • Owned by
    Not owned by anyone
  • Category
    Client
  • Resolution
    RESOLVED
  • Priority
    Normal
  • Reproducability
    Rarely
  • Severity
    Normal
  • Targetted for
    icon_milestones.png JPPF 3.2
Issue description
During a test with a complex topology, I got the following deadlock:

Found one Java-level deadlock 
"RemoteChannelWrapper-driver-1-2--1":
  waiting for ownable synchronizer 0x00000000e0e29330, (a java.util.concurrent.locks.ReentrantLock$NonfairSync),
  which is held by "TaskQueueChecker"
 
"TaskQueueChecker":
  waiting to lock monitor 0x000000000a1bc870 (object 0x00000000e0e29640, a java.util.HashSet),
  which is held by "RemoteChannelWrapper-driver-1-2--1"
 Java stack information for the threads listed above 
"RemoteChannelWrapper-driver-1-2--1":
  at sun.misc.Unsafe.park(Native Method)
  - parking to wait for  0x00000000e0e29330> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
  at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
  at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
  at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
  at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
  at org.jppf.client.balancer.queue.JPPFPriorityQueue.getMaxBundleSize(JPPFPriorityQueue.java:238)
  at org.jppf.client.JPPFContextClient.getMaxBundleSize(JPPFContextClient.java:52)
  at org.jppf.server.scheduler.bundle.impl.ProportionalBundler.maxSize(ProportionalBundler.java:85)
  at org.jppf.server.scheduler.bundle.proportional.AbstractProportionalBundler.computeBundleSizes(AbstractProportionalBundler.java:216)
  - locked <0x00000000e0e29640> (a java.util.HashSet)
  at org.jppf.server.scheduler.bundle.proportional.AbstractProportionalBundler.feedback(AbstractProportionalBundler.java:150)
  - locked <0x00000000e0e29640> (a java.util.HashSet)
  at org.jppf.client.balancer.ChannelWrapperRemote$RemoteRunnable.run(ChannelWrapperRemote.java:263)
  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
  at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
  at java.util.concurrent.FutureTask.run(FutureTask.java:166)
  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
  at java.lang.Thread.run(Thread.java:722)
 
"TaskQueueChecker":
  at org.jppf.server.scheduler.bundle.proportional.AbstractProportionalBundler.setup(AbstractProportionalBundler.java:163)
  - waiting to lock <0x00000000e0e29640> (a java.util.HashSet)
  at org.jppf.client.balancer.ChannelWrapper.checkBundler(ChannelWrapper.java:140)
  at org.jppf.client.balancer.queue.TaskQueueChecker.updateBundler(TaskQueueChecker.java:362)
  at org.jppf.client.balancer.queue.TaskQueueChecker.dispatchJobToChannel(TaskQueueChecker.java:306)
  - locked <0x00000000e0e29580> (a org.jppf.client.balancer.ChannelWrapperRemote)
  at org.jppf.client.balancer.queue.TaskQueueChecker.dispatch(TaskQueueChecker.java:256)
  - locked <0x00000000e0e294b0> (a java.util.LinkedHashSet)
  at org.jppf.client.balancer.queue.TaskQueueChecker.run(TaskQueueChecker.java:222)
  at java.lang.Thread.run(Thread.java:722)
Steps to reproduce this issue
Configuration used:
  • 2 drivers in P2P
  • 1 node attached to each driver
  • client: 1000x1000 matrix multiplication sample, jppf.pool.size = 2 (4 channels total), 2 channels max per job
I suppose I was lucky to reproduce once

#2
Comment posted by
lolo4j
Nov 04, 22:54
Fixed: trunk revision 2534.

While I was at it, I also refactored the JPPFQueue and associated events APIs, so both client and server-side queuing use the same code.

The issue was updated with the following change(s):
  • The assignee has been changed to lolo4j.
  • This issue has been closed
  • The status has been updated, from New to Closed.
  • This issue's progression has been updated to 100 percent completed.
  • The resolution has been updated, from Not determined to RESOLVED.
#5
Comment posted by
lolo4j
Nov 11, 03:10
Fixed in branch b3.1 revision 2540

The issue was updated with the following change(s):
  • This issue has been closed
  • The status has been updated, from New to Closed.
  • This issue's progression has been updated to 100 percent completed.
  • The resolution has been updated, from Not determined to RESOLVED.
  • Information about the user working on this issue has been changed, from lolo4j to Not being worked on.