JPPF Issue Tracker
Please log in to bookmark issues
CLOSED  Bug report JPPF-56  -  Bad initialization of management broadcast information
Posted Aug 30, 2012 - updated Dec 27, 2014
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
    Not determined
  • Targetted for
    icon_milestones.png JPPF 3.1.x
Issue description
From this forum discussion.

The method org.jppf.server.DriverInitializer.getConnectionInformation() has the following:
if (config.getBoolean("", true))
  connectionInfo.managementPort = config.getInt("", 11198);
  connectionInfo.sslManagementPort = config.getInt("", 11198);
We can see that the plain and secure management ports that will be broadcast by the server will have the same value, which is incorrect

Instead we should have:
if (config.getBoolean("", true))
  connectionInfo.managementPort = config.getInt("", 11198);
if (config.getBoolean("", false))
  connectionInfo.sslManagementPort = config.getInt("", 11193);
Steps to reproduce this issue
This is an identified proble in the code.

Comment posted by
Aug 30, 08:03
In fact I just realized that connectionInfo.managementPort and connectionInfo.sslManagementPort are later overriden in method DriverInitializer.createJMXServer():
if (!ssl) info.managementPort = server.getManagementPort();
else info.sslManagementPort = server.getManagementPort();
So I believe we should remove the initialization of these attributes from getConnectionInformation() alltogether, since the management port may not be the one configured in the configuration file: the driver checks if the configured port is already bound, in which case it will try different ports (by incrementing up to 65535 with rollover to 1024), until it finds one that works.
Comment posted by
Aug 31, 02:42
Fixed. Changes committed to SVN:

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.