Print

[dbwiddis]

I'm working on configuring a local node on the same machine as my driver and have a few questions on configuration/setup/provisioning:

1. It looks like to enable the node I just set jppf.local.node.enabled = true in the driver's config file, and then set any parameters normally found in a node config file.  Since both files specify the jppf.management.host and port, this appears to imply that JMX management of the local node must be done on the same JMX host/port used for the driver.  Is this correct?  (It looks like the no-arg JMX constructor for the "same JVM" would only apply to a node in the same JVM as the client, presumably the "jppf.local.execution.enabled" directive for the client.)  If not, what is the best way to administer a local (to the driver) node?

2. It looks like to provision a node, I can either connect directly to the node OR use the NodeForwardingMBean on the driver.  In the latter case, how would I identify a local node uniquely?

[lolo]

this appears to imply that JMX management of the local node must be done on the same JMX host/port used for the driver.  Is this correct?

No, the driver and node use separate JMX remote connector servers, listening on separate ports. The fact that there is a single configuration property for both is a shortcoming for which I registered a bug: JPPF-276 The management port of a server-local node cannot be configured separately

We should have removed the "jppf.management.host" property, as it is not used anymore. The JPPF client uses the same host as <driver_name>.jppf.server.host or whatever is received from the server discovery. It's clear that we need to do some cleanup here 

Another precision: the local executor in the client is not manageable, it doesn't have any associated JMX connector server or MBeans. In this respect, it is not a real node and should be seen as an Executor Service that can be used via the JPPF APIs. The original intent was to enable local testing of the jobs using the same API as for a remote grid. It was since extended (enrolled in the client-side load balancing and job SLA), so it can also be used to offload some of the work to a local execution service.

In the latter case, how would I identify a local node uniquely?

Each node (and client and driver, for that matter) has its own UUID. You can use that to filter the nodes you want the NodeForwardingMBean request to apply to. You just need to define the appropriate node selector, for instance:

Code: [Select]

String node uuid = ...;
NodeSelector selector = new NodeSelector.UuidSelector(nodeUuid); // vararg constructor
// get the  number of executed tasks for each selected node
Map<String, Object> results = forwarder.forwardGetAttribute(selector, JPPFNodeTaskMonitorMBean.MBEAN_NAME, "TotalTasksExecuted");
The nodes uuids can be obtained via the JPPFManagementInfo returned by a number of methods in JMXDriverConnectionWrapper. They are also accessible via the JPPFSystemInformation objects, using the property "jppf.uuid": JPPFSystemInformation.getUuid().getString("jppf.uuid")

If you want to identify all driver-local nodes, the best is to use an execution policy selector in conjunction with JPPFSystemInfo property "jppf.channel.local", for example:

Code: [Select]

ExecutionPolicy localNodePolicy = new Equal("jppf.channel.local", true);
NodeSelector selector = new NodeSelector.ExecutionPolicySelector(localNodePolicy);
// forward some request ...
-Laurent

[lolo]

Ah, I forgot something really important, sorry 

As of v4.1.1, there is a bug that prevents local nodes from being managed: JPPF-274 Server-local nodes cannot be managed.
I implemented a fix, and uploaded it as part of patch 01 for JPPF 4.1.1, sicne the fix only impacts jppf-server.jar.

[dbwiddis]

this appears to imply that JMX management of the local node must be done on the same JMX host/port used for the driver.  Is this correct?

No, the driver and node use separate JMX remote connector servers, listening on separate ports. The fact that there is a single configuration property for both is a shortcoming for which I registered a bug: JPPF-276 The management port of a server-local node cannot be configured separately

I had guessed at a similar conclusion but didn't think it was that obvious. Thus a question on how to rather than a report of "you can't!"  It does appear from that bug report that a temporary workaround is just to increment the server port by one (11199 is available on my machine) so I'll try that out temporarily.

We should have removed the "jppf.management.host" property, as it is not used anymore. The JPPF client uses the same host as <driver_name>.jppf.server.host or whatever is received from the server discovery. It's clear that we need to do some cleanup here 

That's good to know!  I had been doing a few extra steps in my cloud node creation code to make sure that got set right (even though it didn't seem to matter), so it's good to know they aren't needed.

Ah, I forgot something really important, sorry 

As of v4.1.1, there is a bug that prevents local nodes from being managed: JPPF-274 Server-local nodes cannot be managed.
I implemented a fix, and uploaded it as part of patch 01 for JPPF 4.1.1, sicne the fix only impacts jppf-server.jar.

I had noticed that "null" in reports from the JobNotificationListener about tasks on the local node, but didn't realize it was more of a problem than that!