Page Tools


    Hallo, es ist die dokumentation für das ADAGE JXTA plugin. This plugin can be used to deploy all kind of JXTA-based applications such as JuxMem.

    Describing a JXTA application (JDL)

    A JXTA application is composed by two kind of peers: rendezvous peers and edge peers. Please refer to the JXTA documentation to understand how these roles are acting and, possibly, what you are doing.

    This plugin is designed for JXTA-C 2.5.x (see below for 2.3 support).

    A JXTA overlay can be described thanks to the JXTA Description Language (JDL). You can find more information about this language in Mathieu Jan's Thesis (Fr). A JDL example describing a basic JuxMem application is available here tests/jxta/appl.xml (from the adage source directory). It starts with:

    <?xml version="1.0"?>
    <!DOCTYPE JXTA_application>
    <JXTA_application xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="../../src/plugin/jxta//JXTA_application.xsd">

    We are now ready to declare some peer profiles.

     <profiles>

    Describing a profile

    Each peer is associated with a profile that indicates information such as its type (edge or rendezvous), the binary to use or the connection settings.

       <profile name="p_manager">
        <services rdv="true" relay="false" />
        <networks tcp="true" port="9701" multicast="false" http="false"/>
        <behavior binding="c" filename="simple_manager" args="120"/>
       </profile>

    According to the current status of this JXTA plugin, here is the description of the options that are already available:

    • services.rdv indicates whether the corresponding peers have to act as a rendezvous or not. This is deprecated because this information is already given in the overlay description (see below).
    • networks.port (optional) indicates the tcp port to use. This may change depending on the port availability when deploying the peers. If not set, the default value is 9701.
    • behavior.filename indicates the name of the binary to launch. The program will be called “as this”, which means it has to be reachable from everywhere ($PATH is a good guess).
    • behavior.args indicates the arguments to use with the binary.

    Other options are not supported yet but have to be filled in order to make a valid JXTA description file. Now let's build the JXTA overlay:

     </profiles>
     
     <overlay>

    Describing the overlay

    The overlay is made of the description of rendezvous and edge peers.

    Rendezvous peers

    The following code describes a 4-rendezvous star topology, each peer using the same profile.

       <rdvs>
         <rdv id="manager1" profile_name="p_manager" cardinality="1">
         </rdv>
         <rdv id="manager2" profile_name="p_manager" cardinality="3">
          <rpv>manager1</rpv>
         </rdv>
       </rdvs>

    Edge peers

    The following code describes 2 edge peers using the same rendezvous peer but different profiles.

       <edges>
          <edge id="writer" profile_name="p_writer" cardinality="1" rdv="manager1" />
          <edge id="reader" profile_name="p_reader" cardinality="1" rdv="manager1" />
       </edges>

    Your JXTA application description is now finished, you can end the file.

    </overlay>
     
    </JXTA_application>

    Getting started

    Deploying JXTA

    If you are not using the OAR(Grid) scheduler, this is the right time to create your resource file. Then you can type:

    ./src/adage -a tests/jxta/appl.xml -c tests/jxta/ctrl-params-ssh.xml -r tests/nodes.res -R
    

    If you are using the OAR(Grid) scheduler you can directly indicate your reservation number. Grid5000 users, please indicate the ctrl-params-oarsh.xml file to force the use of OAR2 tools.

    ./src/adage -a tests/jxta/appl.xml -c tests/jxta/ctrl-params-oarsh.xml -g 9147 -R
    

    The deployment ends with a report indicating hosts and PIDs:

    DBG[scripts_generator.cc:73] generate(): hosts_pid[paravent12.rennes.grid5000.fr] = 10472 
    DBG[scripts_generator.cc:73] generate(): hosts_pid[paravent20.rennes.grid5000.fr] = 13632 
    DBG[scripts_generator.cc:73] generate(): hosts_pid[paravent58.rennes.grid5000.fr] = 693 
    DBG[scripts_generator.cc:73] generate(): hosts_pid[paravent65.rennes.grid5000.fr] = 28520
    

    You can now monitor that your application is currently running using the generated ./get_status.sh script. You can also kill all the processes using the ./clean_up.sh script.

    What this plugin really does

    This plugin uses the specific JXTA application description to generates all the PlatformConfig files. The original PlatformConfig file can be found in the adage/src/plugin/jxta directory. It is also installed in the $prefix/share/adage/plugins/jxta directory.

    Each peer creates a local directory named $destdir/$user/adage-$adagepid, used to copy and modify the PlatformConfig file. $destdir may change depending on your node, usually it is the local /tmp directory. It is also the right place to retrieve your log files.

    TCP ports are dynamically set on the node, returned back to the JXTA plugin and used to configure peers that depend on it. You will find the complete list of tcp ports used by this deployment in the $destdir/$user/adage-$adagepid/share/jxta_tcp_ports file.

    Using the ADAGE WAIT FILE feature to control the bootstrap timing

    Most of the peers belonging to a JXTA network have to contact a rendezvous peer (called a seed) to be inserted into the overlay. These implicit dependancies are automatically handled by the plugin, making sure that a peer will be launched only if its rendezvous is already started.

    The default ADAGE behaviour is to wait for the process creation before sending the ack that triggers the deployment of the depending processes. However, starting a JXTA peer and all its associated services may take more time than just starting a process. Hopefully it is possible to wait for a signal sent by the application, such as the creation of a file (WAIT_FILE).

    This file has to be created by the JXTA application in the working directory, with the following name: adage_jxta_wait_file. It can remain empty.

    To enable the WAIT FILE feature, just switch the option to true in the specific control parameters file (tests/jxta/ctrl-params-spec.xml).

     <adage waitfile="true" />

    Deploying a specific version of JXTA

    The structure of the PlatformConfig file can change depending on the version of JXTA used. By default, this plugin generates a configuration file for JXTA 2.5. However, it is possible to generate a JXTA 2.3 compliant PlatformConfig file using the ADAGE control parameters.

    Create first a specific control parameter file for JXTA indicating the version you want to use (handled: 2.3, 2.5). An example is available here: tests/jxta/ctrl-params-spec.xml

     <platformconfig version="2.3" />

    Declare this JXTA control parameters file to the general control parameter file, adding the following line. An example is available here: tests/jxta/ctrl-params-ssh.xml

     <plugin name="JXTA" file="tests/jxta/ctrl-params-spec.xml"/>

    Now you are ready to deploy an overlay with a specific version of JXTA.

    ./src/adage -a tests/jxta/appl.xml -c tests/jxta/ctrl-params-oarsh.xml -g 10043 -x
    


    Powered by Heliovista - Création site internet