Print

[Orange]

Hi,

I was wondering whether there are currently any communication means between the client and the JPPFTasks. What I would need is some way of returning the progress from each task while they are running. I saw that listeners can be registered to Jobs, but they only fire on completion/cancellation/restart and once the result can be obtained.

Any help is appreciated.

Cheers.

[lolo]

Hello,

There are several ways you can do this:

- you can implement the ability to send JMX notifications from a task. We have an example of this in our samples pack, and which addresses your requirements exactly.

- you can also use a ClientDataProvider with your job, to allow your tasks to execute a Callable on the client-side. Please note that this feature will be deprecated in the next release (v3.2) and replaced with a more convenient API directly in JPPFTask, as described in this enhancement - JPPFTask.compute(JPPFCallable).

- lastly, you can also integrate the nodes/client with a distirbuted cache (aka data grid) such as Hazelcast or Ehcache and use the notification mechanisms they provide. The hookup between node and data grid can be implemented using several of the JPPF extension points: node startup class, pluggable node mbean or node life cycle listener.

I hope this helps,
-Laurent

[Orange]

Thanks for the swift response! Option #1 seemed most applicable.

While I was able to follow the steps and got the expected output, I still have to understand how this works to use it in my application.

When I tried to simply modify my tasks as per the example it didn't get past the registerToMBeans() call (I essentially copied all the necessary code into my application). For some reason,

while ((connection.getJmxConnection() == null) || !connection.getJmxConnection().isConnected())
            Thread.sleep(100L);

does not complete as isConnected() stays false. As I said, I just followed the example blindly and didn't have much of a clue what I was doing.

Thanks again for you help!

[Orange]

I'm a bit lost in figuring this out. The way I understand it is, that an MBean is some sort of Plugin for the server. The server picks up the plugin if it can find it in its class path (which is where I put the compiled jar file of the example).

Now when I start the TaskNotificationRunner, a job with 1 task will be created that sends out status message (as I would like to have it in my application). The thing that I don't understand is where the logic for dispatching the message is written. The mbean package contains just a couple of interfaces without much code... Also, why do I have to go the way via an MBean? Can't the client and the task work this out between them? Could you please elaborate on what's happening in registerToMBean(). The javadoc says "Subscribe to notifications from all the nodes.". Am I correct in assuming that the communication is established between nodes and client and each task uses the facilities of the node's communication channel it's executed on?

What could be the reason for this method to fail in my application? connection.getJmxConnection().isConnected() is returning false which prevents this loop to terminate.

Sorry to dump all these questions on you, but I really would like to understand more about the software, and use it in my application.

Cheers.

[lolo]

Hello,

Sorry for this late response.
Just before answering your questions, I would like to ask you to check if you have the "jmxremote_optional.jar" in your client application's classpath? When it is missing, this is known to cause the kind of hang you have described.

The dispatching of messages relies entirely on the JMX and JMX-remote APIs that come with the JDK. You might have noticed the following in the sample:

• TaskNotificationMBean and TaskNotification follow the naming convention for Standard MBeans
• TaskNotificationMBean extends the interface NotificationEmitter and TaskNotification extends the class NotificationBroadcasterSupport. This is what provides the support for emitting and dispatching notifications. Sending the notifications is implemented in the sendTaskNotification(...) methods, which simply delegate to NotificationBroadcasterSupport.sendNotification().

When you deploy a pluggable MBean, JPPF uses the information in the service file in META-INF/services (using the service provider interface or SPI) to instantiate the MBean and register it with the default MBean server. This makes the MBean available to any JMX-based monitoring tool, such as JConsole or VisualVM, which you can eventually use to check the state of your MBeans and others.

The transport layer for remote management and monitoring is implemented via the JMX remote APIs. The JDK (since 1.5) provides a default implementation based on RMI. JPPF does not use it, instead we use the JMXMP remote connector, which provides more features, can be fully secured and is generally better performance-wise. This why you need the file jmxremote_optional.jar in the classpath of each JPPF component: drivers, nodes and clients.

I hope this calrifies the way mbeans work in JPPF.

Could you please elaborate on what's happening in registerToMBean()

In this method, we use a MBean that the JPPF driver registers by default, to get  a list of nodes connected to this driver. This information is then used to connect to each node's MBean server and register a NotificationListener with the custom MBean, which will handle remote notifications from all the nodes.

Am I correct in assuming that the communication is established between nodes and client and each task uses the facilities of the node's communication channel it's executed on?

Yes and no. Yes, the communication is established between node and client, and no because it is a different channel than the one used to send the tasks and receive their results. The channel used is created by the JMXMP remote connector.
The node-to-client communication causes issues in a number of networking environments, in particular when the nodes are in a different network than the client. In this case, the client will not be able to monitor or manage the nodes. However, this does not prevent jobs from being executed on these nodes, since all other JPPF communication channels go via the driver first. We are addressing this problem, but this is quite complex and will not yet be available in the upcoming v3.2 release (for which we are late  ). See feature request JPPF-26 Enable node management via the driver connection

hat could be the reason for this method to fail in my application?

As I mentioned above, we have seen this problem when "jmxremote_optional.jar" is missing from your client's classpath. Could you check it and let us know?

Sincerely,
-Laurent

[Orange]

Hi Laurent,

Thanks for getting back to me. Your response was spot on! After copying jmxremote_optional.jar into the lib path, it worked like a charm :-).

Thanks again for your great help.

Regards,
Sven