Message-passing programming in Java by dffhrtcv3


									        A Proposed Jini Infrastructure
        to Support a Java Message
        Passing Implementation

            Mark Baker*, Bryan Carpenter
            *University of Portsmouth
            Florida   State University
             AMS, HPDC, Pittsburgh – 1st August 2000

01 February 2013            Mark.Baker@Computer.Org
         An Introduction to MPJ.
         MPJ Requirements.
         Jini Technologies and Architecture:
             Lookup, discovery and join;
             Leasing, events and transactions;
             Object activation;
         MPJ and Jini.
             Handling failure, checkpointing, abort.
         Conclusions and Future Work.

1 February, 2013             Mark.baker@Computer.Org
          The Message-Passing Working Group of the
           Java Grande Forum was formed in late 1998
           as a response to the appearance of several
           prototype Java bindings for MPI-like libraries.
          An initial draft for a common API specification
           was distributed at Supercomputing '98.
          Since then the working group has met in San
           Francisco and Syracuse.
          The present API is now called MPJ.

1 February, 2013         Mark.baker@Computer.Org
          No complete implementation of the draft
          mpiJava, is moving towards the “standard”.
          Version 1.3 will implement the new API.
          mpiJava wrappers rely on the availability of
           platform-dependent native MPI
           implementation for the target computer.

1 February, 2013        Mark.baker@Computer.Org
           Problems with mpiJava
          Wrapper approach has some disadvantages.
              2-stage installation:
                   Get/build native MPI then install/match the Java
                   Tedious/off-putting to new users.
              Problems – conflicts between the JVM and
               the native MPI runtime behaviour.
                   mpiJava now runs on various combinations of
                    JVM and MPI implementation.
              Strategy simply conflicts with the ethos of
               Java – write-once-run-anywhere.

1 February, 2013               Mark.baker@Computer.Org
           MPJ – the Next Generation of
           Message Passing in Java
          An MPJ reference implementation could be
           implemented as:
              Java wrappers to a native MPI implementation;
              Pure Java;
              Principally in Java – native methods to optimize
               operations (like marshalling arrays of primitive
               elements) that are difficult to do efficiently in Java.
          We are aiming at pure Java to provide an
           implementation of MPJ that is maximally
           portable and that hopefully requires the
           minimum amount of support effort.
1 February, 2013              Mark.baker@Computer.Org
           Benefits of a pure Java
           implementation of MPJ
          Highly portable – assumes only a Java
           development environment.
          Performance: moderate – may need JNI
           inserts for marshalling arrays.
          Network speed limited by Java sockets.
          Good for education/evaluation.
          Vendors provide wrappers to native MPI for
           ultimate performance?

1 February, 2013         Mark.baker@Computer.Org
          We envisage that a user will download a jar-file
           of MPJ library classes onto machines that may
           host parallel jobs, and install a daemon on
           those machines.
          Parallel java codes are compiled on one host.
          An mpjrun program invoked on that host
           transparently loads the user's class files into
           JVMs created on remote hosts by the MPJ
           daemons, and the parallel job starts.

1 February, 2013         Mark.baker@Computer.Org
          Design Criteria for the MPJ
         Need an infrastructure to support
          groups of distributed processes:
             Resource discovery;
             Communications (not discussed here);
             Handling failure and fault tolerance;
             Spawn processes on hosts;
             …

1 February, 2013          Mark.baker@Computer.Org
                Layers of an MPJ
                Reference Implementation
                         High Level MPI                     Collective Operations
                                                            Process Topologies
                                                                All pt-to-pt modes
                         Base Level MPI
Isend, irecv, waitany,
…                        MPJ Device Level
Physical PIDs
Contexts & Tags
Byte vector data
                         Java Socket and Thread API         All-to-all TCP Connect

MPJ Daemon                                                  Input Handler Threads

Lookup, Leasing          Process Creation and Monitoring    Synchronised methods,
(Jini)                                                      wait, notify…

Exec java MPJLoader
Serializable objects

 1 February, 2013                 Mark.baker@Computer.Org
          Jini Technologies

1 February, 2013   Mark.baker@Computer.Org
          Jini Architecture

1 February, 2013    Mark.baker@Computer.Org
          A Jini Community

1 February, 2013   Mark.baker@Computer.Org
           Lookup service
          Repository of available services.
          Stores each service as an extensible set of
           Java objects.
          Service objects may be downloaded to clients
           as required.
          May be federated with other lookup services.
          Lookup service interface provides:
              Registration, Access, Search, Removal.

1 February, 2013            Mark.baker@Computer.Org
          Discovery and Join
         Allow a Jini service (hardware or
          software) to:
             Find and join a group of Jini services;
             Advertise capabilities/services;
             Provide required software and attributes.

1 February, 2013          Mark.baker@Computer.Org
          Steps in Discovery and Join
         A Jini enabled Object (representing a
          hardware and/or software service) multicasts
          a packet with a reference to itself.
         The service receives an RMI reference to the
          Lookup service (one or more).
         The service joins a Federation by placing an
          object representing its capabilities into the
          Lookup service for other clients and services
          to use.

1 February, 2013         Mark.baker@Computer.Org
          Registering a Service

            Lookup Service
                                 Discovery Request
              Registrar                                  Service

               Service Proxy                             Registrar
                                Service Registration

1 February, 2013               Mark.baker@Computer.Org
           Entry Object
          When a server registers a service, it places a
           copy of the service (or a suitable proxy) on the
           lookup service.
          This copy is an instance of an object, albeit in
           serialised form.
          The server can optionally register sets of
           attributes along with the service instance.
          So what is stored on each service locator is an
           instance of a class along with a set of attribute

1 February, 2013          Mark.baker@Computer.Org
           Client Search
          A client gets a Registrar object from the lookup
           service – used to search for a service stored on
           that lookup service.
          The client prepares a Template which is a list of
           class objects and entries it wants to use.
          The client can query using the Registrar object's
           lookup() method, to see if a service matching
           the template is available.
          If successful, an object is returned that can be
           used to invoke services on that the remote
1 February, 2013         Mark.baker@Computer.Org
          Jini Lookup

1 February, 2013   Mark.baker@Computer.Org
          Acquiring compute slaves
          through Jini

                                                MPJ Process

                                     mpjrun …

1 February, 2013            Mark.baker@Computer.Org
           Object Activation
          The RMI Activation Daemon (rmid)
           allows us to register servers (objects).
          The daemon starts servers on an as-
           needed basis.
          The servers terminate themselves when
           they are idle.
          This reduces the resources required
           since it only runs active objects.

1 February, 2013       Mark.baker@Computer.Org
           Leasing protocol in Jini
          Protocol for managing resources using a
           renewable, duration-based model.
          Contract between objects.
          Resources can be shared or non-
          Provides a method of managing
           resources in an environment where
           network failures can, and do, occur.

1 February, 2013       Mark.baker@Computer.Org
           Distributed events in Jini
          Enables Java event model to work in a
           distributed network.
          Register interest, receive notification.
          Allows for use of event managers.
          Can use numerous distributed delivery
              Push, pull, filter...
          Uses leasing protocol.
1 February, 2013             Mark.baker@Computer.Org
          Transaction model in Jini
         Designed for distributed object coordination:
          Light weight, object-oriented.
         Supports nested transactions.
         Supports various levels of ACID properties
          (Atomicity, Consistency, Isolation, Durability).
         Uses leasing protocol.
         Implemented in Transaction Manager service.

1 February, 2013         Mark.baker@Computer.Org
          MPJ - Implementation
         In the short-to-medium-term – before Jini
          software is widely installed – we might
          have to provide a “lite” version of MPJ
          that is unbundled from Jini.
         Designing for the Jini architecture should,
          nevertheless, have a beneficial influence
          on overall robustness and maintainability.
         Use of Jini implies use of RMI for various
          management functions.

1 February, 2013       Mark.baker@Computer.Org
           MPJ – Implementation
          The role of the MPJ daemons and their
           associated infrastructure is to provide
           an environment consisting of a group
           of processes with the user-code loaded
           and running in a reliable way.
          The process group is reliable in the
           sense that no partial failures should be
           visible to higher levels of the MPJ
           implementation or the user code.

1 February, 2013        Mark.baker@Computer.Org
          MPJ – Implementation
         We will use Jini leasing to provide fault
         No software technology can guarantee
          the absence of total failures, where the
          whole MPJ job dies at essentially the
          same time.

1 February, 2013       Mark.baker@Computer.Org
          Handling failures with Jini
         If any slave dies, a client generates a Jini
          distributed event, MPIAbort – all slaves
          are notified and all processes killed.
         In case of other failures (network failure,
          death of client, death of controlling
          daemon, …) client leases on slaves
          expire in a fixed time, and processes are

1 February, 2013        Mark.baker@Computer.Org
          MPJ – Implementation
         Checkpointing and restarting of
          interrupted jobs may be quite useful.
         Checkpointing would not happen without
          explicit invocation in the user-level code,
          or that restarting would happen
         A serialized object can be saved to disk
          and restarted.

1 February, 2013       Mark.baker@Computer.Org
          MPJ - Implementation
         Once a reliable cocoon of user processes has
          been created through negotiation with the
          daemons, we have to establish connectivity.
         In the reference implementation this will be
          based on Java sockets.
         Recently there has been interest in producing
          Java bindings to VIA - eventually this may
          provide a better platform on which to
          implement MPI, but for now sockets are the
          only realistic, portable option.

1 February, 2013        Mark.baker@Computer.Org
    Slave 1         Slave 2        Slave 3

                                                  Slave 4


                                                            Mpj Deamon

           Mpjrun myproggy –np 4

                                                            http server

1 February, 2013              Mark.baker@Computer.Org
           MPJ - Conclusions
          On-going effort (proposal + volunteer
          Collaboration to define exact MPJ
           interface – consisting of other Java MP
           system developers.
          Work at the moment is based around the
           development of the low-level MPJ device
           and exploring the functionality of Jini.
          Looking at Security deeply!

1 February, 2013       Mark.baker@Computer.Org

To top