Welcome to the WMS page
What is the WMS
The Workload Management System (WMS) is a software service of the gLite/EMI middleware which is responsible for distributing and managing tasks across computing and storage resources available on a Grid. WMS assigns user jobs to CEs and SEs belonging to a Grid environment in a convenient fashion, so that:
- jobs are always executed on resources that match the job requirements
- Grid-wide load balance is maintained, i.e. jobs are evenly and efficiently distributed across the entire Grid.
The WMS basically receives requests of job execution from a client, finds the required appropriate resources, then dispatches and follows them until completion. This is done handling failure in between and whenever possible. Other than single batch-like jobs, compound job types handled by the WMS are Directed Acyclic Graphs (a set of jobs where the input/output/execution of one of more jobs may depend on one or more other jobs), Parametric Jobs (multiple jobs with one parametrized description), and Collections (multiple jobs with a common description). Jobs are described via a flexible, high-level Job Definition Language (
JDL).
As a global Grid resource broker, the WMS represents a reliable and efficient entry point to high-end services available on a Grid, providing a common front-end for user job submission.
gLite WMS software
EMI WMS Software
Documentation
Documentation for EMI versions
Documentation for gLite versions
Documentation for administrators
Documentation for users
Other documentation concerning the WMS
Known issues
Version of ICE 3.3.5-3 has a bug that is triggered in some particular circumstances. Before explaining it, some details on the bug: there's a piece of code that matches the myproxy server address for correcteness; this check is performed by mean of a (quite) complicated regex that matches the address to be compliant with the FQDN format. The complexity of this regex triggers an high usage of boost's internal memory buffer that can run out of memory matching some particular addresses.
Now, the bug: the addresses that we found triggering this problem are like "ed8ac012f7da92dd487bc8d3edc4a49b" (or even shorter; not any alphanumeric combination is problematic though). Some VOs use addresse like that (LHCb for example)... We also noted that just adding the domain name to those addresses would by pass the boost's memory exhaustion.
To check if ICE keeps crashing for this problem you can follow these steps:
- login as root in the WMS node
- stop the daemon the automatically restart WMS services (if any)
- stop ICE
- su - glite
- execute (as glite) /usr/bin/glite-wms-ice --conf glite_wms.conf
After a little while you should receive on the console an error like this:
/usr/bin/glite-wms-ice --conf glite_wms.conf
Logfile is [/var/log/wms/ice.log]
terminate called after throwing an instance of 'std::runtime_error'
what(): Memory exhausted
Aborted
If this is the case you should proceed to modify the myproxy addresses stored in the ICE's database (thanks to Alessandro Paolini and Sergio Traldi):
1) come back to root user and change dir to ICE's persist directory:
cd /var/ice/persist_dir
2) put all the myproxy-url without the "dot" in the file "file.txt" by executing:
sqlite3 ice.db "select myproxyurl from delegation where myproxyurl not like '%.%';" > file.txt
3) grep -v ^$ file.txt > file1.txt
4) generate the instructions to update the ICE DB, and put them in a script
cat file1.txt | gawk '{print "sqlite3 /var/ice/persist_dir/ice.db \"update delegation set myproxyurl=\x27"$0".desy.de\x27 where myproxyurl=\x27"$0"\x27;\""}' > script
(Substitute the example desy.de domain name with yours).
6) execute the script:
chmod +x script
./script
Papers and Presentations
Testing and Certification
Documentation
Reports
Monitoring
Contacts and Support