Two contests will take place during the plugtest: The N-Queens Counting Problem and The Flowshop Problem. To solve these problems, a world wide Grid will be configured, composed of a rich diversity of systems (architecture, operating system and Java virtual machines).
The following document is intended to help contestants fine tune their applications to compete at the plugtest event.
The Grid will be composed of more than a 1000 CPUs. These CPUs will be distributed all around the world, and grouped into sites. The size of all sites will be heterogeneous, ranging from a handful to hundreds.
To deploy on each site, contestants will use already configured Deployment Descriptors. There will be one deployment descriptor per site, configured with a virtualnode named "plugtest". The name of this virtualnode is the one that should be hardcoded into the contestant's application code. The length of the node array (number of nodes) returned from the virtualnode will vary depending on the size of the site.
The machines on a site may have one or more CPUs. For each site with more than one CPU the configuration can be one of the following:
It is highly discouraged to use static variables in the deployed active objects. Sometimes, more than one active object will be deployed on the same same java virtual machine, which may produce a race conflict between the active objects.
Last year experience shows this is a latent risk, and must be avoided.
Native code, is highly discouraged. The first reason is the heterogeneousness of the Grid, since code will require specific compilation for each site. The second reason is that size of the Grid, which makes it unfeasible to compile and copy the native code to the remote sites during the plugtest event. The third and last reason not to use native code is that by using it your team will limit the amount of machines to which it can deploy, reducing the Grid capacity.
The ProActive / Plugtests staff will not provide support for native code during the plugtest event.
The machines of a site can have: private or public IPs. For sites with private IPs, ProActive has provided a new feature that will allow deployment between the site's frontend and the innermachines.
Nevertheless, the current status of this feature does not support inner node communication between two different sites. That is to say, if site A and site B have inner nodes: A1...AN, B1...BM, then Ax will not be able to communicate with By.
For security reasons, solutions which require communication between tasks will be limited to a subset of the sites known as Grid5000 (composed of more than a thousand CPUs).
Due to the large number of descriptor files, the deployment time is significant. Therefore it is recommended to contestants to deploy each descriptor file in parallel thread.
Moreover, the process of placing active objects on the nodes can also be done in parallel, using a thread pool.
Teams are expected to:
Last update: Thu Oct 6 19:33:06 CEST 2005