Print

[whwayne]

how node side accept a task, i mean, our task extending JPPFTask  can be serializable, what is the node really get? the byte stream from socket, or class file of task?

anybody give me a hand? thanks in advance.

Wayne

[whwayne]

or  though a classloader loading task object remotely?

[lolo]

Hi Wayne,

As you mentioned, JPPF nodes use a distributed classloader that can locate and load classes in the driver's or client's classpath.
Tere isn't much (yet) in our documentation that explains how it works, but I wrote an article some time agho that should give you more details on this: http://www.jroller.com/jppf/entry/distributed_java_living_a_free

Is there any particular question ort concern you have?

Thanks,
-Laurent

[whwayne]

Hi Laurent:

  Thank you for your great help. I read your article.  that helps a lot. I still have some questions:

  1. the node's client class loader sends a class loading request with the binary name of A and an identifier for the client (client UUID)
   
    Q: how the node know the binary name of Class A and UUID of client? So, node should send request to server? what I am thinking is  a sever is responsible to distribute tasks.

  5. When the corresponding file is found, from either the file system or a jar file, it loads the class definition (i.e. bytecode) and sends it back to the server

    Q:you mentioned class definition(byte code) what kind of form for loading the class definition? the byte stream reading from class files? if so, can I save the class definition on node side by using class files?

   That's all there is to it. And all of this mechanism is completely transparent to the client's code, hidden behind a simple API call.
    Q: what a simple API  call you hidden. could you show me some details

 Thank you for your great help.

From Wayne

[lolo]

Hi Wayne,

Q: how the node know the binary name of Class A and UUID of client? So, node should send request to server? what I am thinking is  a sever is responsible to distribute tasks.

As you rightly stated, when the driver sends tasks to the node, it also sends, as a part of the message header, the UUID of the client that submitted them. This UUID is then set onto the JPPF classloader. In fact, there will be a class loader instance for each client UUID.
Note that for the communication channel that handles the tasks, it is the server that sends a request to the node, and the node sends a response back.
Then, when deserializing or executing the task, the class loader will need to load some classes. The binary name of a class is computed from the class name (for instance "my.package.MyClass" is transformed into the resource name "my/package/MyClass.class"). When a class is loaded the first time by a class loader, it is its findClass() method that is in charge of finding the class definition (in the classpath) and load it into the JVM (see the doc for the native method ClassLoader.defineClass()). The JPPF class loader overrides the findClass() method so that the class definition is loaded from the client over the network, instead of in the node's local classpath. Thus, for the class loader channel, it is the node that sends the request, and the driver that sends the response back.
Some of this is explained in the Networking considerations section of the JPPF Iverview.

Q:you mentioned class definition(byte code) what kind of form for loading the class definition? the byte stream reading from class files? if so, can I save the class definition on node side by using class files

Yes, we read the byte[] from the class file and send it over to the node. In theory it is possible to save the definition into a file on the node side, however we do not provide any API to do this, because this would interfere with the dynamic class reloading (if there is a new version of the class it will be loaded automatically). If you want the classes permanently on the node side, you have to deploy them manually.

Q: what a simple API  call you hidden. could you show me some details

Using the JPPF APIs to submit a job, like JPPFClient.submit(), will automatically trigger the class loading mechanism. For the details of how it is done, I invite to to look at the code of the classes in the package org.jppf.client, and in particular how the classes JPPFClient, JPPFClientConnectionImpl and ClassServerDelegateImpl interact with each other. The code is accessible from our SVN repository at this location: http://jppf-project.svn.sourceforge.net/viewvc/jppf-project

Sincerely,
-Laurent

[whwayne]

Thanks , Laurent, that helps a lot.
Actually, I want to implement my own checkpoint mechanism at node side. So I need to know the details about what nodes really get from sever. I already read the code. In my opinion, task object is serialized and sent to node by sever using byte stream. And node accept the byte stream (byte[]) through socket and then pack the task object into a thread for execution.
1.   In node main method:
new LauncherListener(port).start(); is  start to listen the socket. Is this operation try to receive the task object? How to keep the byte stream?
2.   How to use thread pool for execute the one task?
3.   node = createNode();
node.run();
I cannot see the details of node.run() method. I guess it may include executing the task. Is that right?

In fact, I want node receive the task object and rebuild the task class file at node side. Do you think it is possible? Hope to get your suggestion. Thank you.

From Wayne