JPPF Issue Tracker
Please log in to bookmark issues
CLOSED  Bug report JPPF-465  -  Adaptive Grid demo is not working
Posted Jul 23, 2016 - updated Mar 21, 2019
icon_info.png This issue has been closed with status "Closed" and resolution "RESOLVED".
Issue details
  • Type of issue
    Bug report
  • Status
  • Assigned to
  • Progress
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
  • Owned by
    Not owned by anyone
  • Category
  • Resolution
  • Priority
  • Reproducability
  • Severity
  • Targetted for
    icon_milestones.png JPPF 5.1.x
Issue description
When running the adaptive grid demo from the samples pack, the client application displays the following messages, then just hangs:
**** submitting jobs batch #1 *****
decreasing the number of server connections to 0
In the client log I can see the following exception:
2016-07-23 10:10:47,855 [DEBUG][apper-driver1-1-0001][]: 
  at org.jppf.client.BaseJPPFClientConnection.sendTasks(
  at org.jppf.client.JPPFClientConnectionImpl.sendTasks(
  at org.jppf.client.balancer.ChannelWrapperRemote$
  at java.util.concurrent.ThreadPoolExecutor.runWorker(
  at java.util.concurrent.ThreadPoolExecutor$
Steps to reproduce this issue
  • start a driver and a node
  • run the demo
  • ==> the demo hangs and its log shows the NPE

Comment posted by
Jul 23, 10:36
  • the message "decreasing the number of server connections to 0" is printed when in the jobRemoved() method of the queue listener
  • decreasing to 0 should never happen, we should always have at least 1 connection
  • the NPE occurs while the client is sending the job to the server.
Analysis: the probable cause of the NPE is that the connection to the server was just closed (related to the 0 connections message). Thus, it seems that either the jobRemoved() notification is sent too soon, or we shouldn't assume that the job remains in the queue while it is being executed. In fact, looking at the code, I can see that when the number of tasks to send to the server, computed by the client-side load-balancer, equals or exceeds the number of unexecuted tasks in the job, then the job is removed from the queue. It may be put back in later on, for instance if the server connection fails and the job is consequently resubmitted.

Conclusion: it seems the queue listener is not suitable for the purpose of the demo and should be replaced with another mechanism. The demo code and documentation shall be updated accordingly.
Comment posted by
Jul 23, 13:03
Fixed in: