Menu
▾
▴
gridsam-discuss — GridSAM users and developers
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(3) |
Dec
(18) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(11) |
Feb
(19) |
Mar
(5) |
Apr
(9) |
May
(5) |
Jun
(1) |
Jul
|
Aug
(6) |
Sep
(8) |
Oct
|
Nov
(10) |
Dec
(1) |
| 2007 |
Jan
(3) |
Feb
(14) |
Mar
(8) |
Apr
(5) |
May
(5) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
(8) |
Nov
(3) |
Dec
(1) |
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
(1) |
Nov
(9) |
Dec
(7) |
| 2009 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
(8) |
May
(3) |
Jun
(2) |
Jul
(7) |
Aug
(5) |
Sep
|
Oct
(6) |
Nov
(1) |
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
(6) |
Apr
(1) |
May
(1) |
Jun
(2) |
Jul
(3) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(5) |
| 2011 |
Jan
(2) |
Feb
(3) |
Mar
(6) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
|
From: Justin B. <jb...@ec...> - 2010-03-22 12:08:19
|
Hi Pawel, The in-memory database is loaded quiet heavily. Its memory footprint is more related to the overall throughput on the server rather than the number of concurrent jobs. However saying this, there has been some work to improve its utilisation since 2.1.4, the upgrading of the Quartz libraries for one. I would recommend the use of a MySQL database in place of the inbuilt database for a production system. In terms of loading GridSAM with 100+ PBS jobs via the web services interface, this should be fine - given moderate server resources. Again, improvements have been made since 2.1.4. So if you are seeing problems, I suggest you upgrade to 2.1.9. If you need help with this just let me know. The changes between versions are detailed here http://gridsam.svn.sourceforge.net/viewvc/gridsam/trunk/GridSAM-2.1.x-Change-Log.txt?revision=531 Regards, Justin On 22 Mar 2010, at 10:24, gri...@li... wrote: > As list administrator, your authorization is requested for the > following mailing list posting: > > List: Gri...@li... > From: paw...@ii... > Subject: GridSAM's default database and limitations > Reason: Post by non-member to a members-only list > > At your convenience, visit: > > https://lists.sourceforge.net/lists/admindb/gridsam-discuss > > to approve or deny the request. > > From: Paweł Sztromwasser <paw...@ii...> > Date: 22 March 2010 10:08:35 GMT > To: gri...@li... > Subject: GridSAM's default database and limitations > > > Hi, > > I am using the default built-in database of GridSAM (2.1.4). Is it completely stored in memory, or only the currently used entities are? How heavy is it in terms of memory use? Can running multiple jobs concurrently result in high memory use? > > And second question: would you expect any performance problems when using GridSAM's web service interface to run and trace ~100 jobs on PBS? > > Thanks in advance, > Pawel Sztromwasser > <pawel_sztromwasser.vcf> > > > From: gri...@li... > Subject: confirm 55c8e994d1f123029f098a29a91a4af48615a22b > > > If you reply to this message, keeping the Subject: header intact, > Mailman will discard the held message. Do this if the message is > spam. If you reply to this message and include an Approved: header > with the list password in it, the message will be approved for posting > to the list. The Approved: header can also appear in the first line > of the body of the reply. > -- Justin Bradley Software Engineer j.b...@om... OMII-UK Bay 23, 4067, B32 University of Southampton |
|
From: Paweł S. <paw...@ii...> - 2010-03-22 10:24:11
|
Hi, I am using the default built-in database of GridSAM (2.1.4). Is it completely stored in memory, or only the currently used entities are? How heavy is it in terms of memory use? Can running multiple jobs concurrently result in high memory use? And second question: would you expect any performance problems when using GridSAM's web service interface to run and trace ~100 jobs on PBS? Thanks in advance, Pawel Sztromwasser |
|
From: Justin B. <jb...@ec...> - 2010-03-11 09:51:12
|
Hi, I note that you are using GridSAM 2.1.4, there have been a number of changes since then which may well fix your problem. Also, I am currently working on new code as an alternative to the current gsiftp transfer routines. I will release GridSAM 2.1.10 soon, I'll post to the list when this happens. Regards, Justin On 8 Mar 2010, at 19:04, 田中 義一 wrote: > Hi, > > Thank you for your quick reply. > You have thought that problems occurs when staging. > But the too many file problems ocuurs even in the following job without data-staging > > <?xml version="1.0" encoding="UTF-8"?> > <JobDefinition xmlns="http://schemas.ggf.org/jsdl/2005/11/jsdl"> > <JobDescription> > <Application> > <POSIXApplication xmlns="http://schemas.ggf.org/jsdl/2005/11/jsdl-posix"> > <Executable>/bin/hostname</Executable> > <Output>host.txt</Output> > <WorkingDirectory>./tmp</WorkingDirectory> > </POSIXApplication> > </Application> > </JobDescription> > <MyProxy xmlns="urn:gridsam:myproxy"> > <ProxyServer>*******</ProxyServer> > <ProxyServerUserName>******</ProxyServerUserName> > <ProxyServerPassPhrase>******</ProxyServerPassPhrase> > </MyProxy> > > </JobDefinition> > > Regards, > Yoshikazu Tanaka > > >> Hi, > >> We are aware that there is an issue relating to gsiftp transfers. >> The problem seems to be an unclosed socket when staging files via gsiftp. >When a file is staged back to gridsam, the connection used for the transfer >remains in CLOSED_WAIT indefinitely. I believe that the underlying commons >vfs library, or perhaps ultimately part of the cog kit is not releasing the >resources correctly. >> I am currently looking into the problem, and hope to have a fix shortly. > >> Regards, >> Justin > >> On 2 Mar 2010, at 07:07, 田中 義一 wrote: > >>> <TooManyFiles> error occurs when we have submitted more than 500 jobs since >>> invoking gridsam. >>> We have observed directory in /proc/omii-server process#/fd, >>> then we have understood that 1 socket file per 1 job remains left after job- >>> completion. >>> Please teach me how to destory job information after job-completion. Even if using gridsam-status, gridsam-terminate command, these socket files does't disappear. >>> >>> Environment >>> CentOS 5.3 >>> GridSAM 2.1.4 >>> gridsam-jobmanager globus (GT 4.0.5) >>> >>> Center for Grid Research and Development(NAREGI) >>> Yoshikazu Tanaka >>> >>> >>> ------------------------------------------------------------------------------ >>> Download Intel® Parallel Studio Eval >>> Try the new software tools for yourself. Speed compiling, find bugs >>> proactively, and fine-tune applications for parallel performance. >>> See why Intel Parallel Studio got high marks during beta. >>> http://p.sf.net/sfu/intel-sw-dev >>> _______________________________________________ >>> GridSAM-Discuss mailing list >>> Gri...@li... >>> https://lists.sourceforge.net/lists/listinfo/gridsam-discuss > >> -- >> Justin Bradley >> Software Engineer >> j.b...@om... >> OMII-UK >> Bay 23, 4067, B32 >> University of Southampton > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > GridSAM-Discuss mailing list > Gri...@li... > https://lists.sourceforge.net/lists/listinfo/gridsam-discuss -- Justin Bradley Software Engineer j.b...@om... OMII-UK Bay 23, 4067, B32 University of Southampton |
|
From: 田中 義一 <yt...@ni...> - 2010-03-08 19:26:13
|
Hi, Thank you for your quick reply. You have thought that problems occurs when staging. But the too many file problems ocuurs even in the following job without data-staging <?xml version="1.0" encoding="UTF-8"?> <JobDefinition xmlns="http://schemas.ggf.org/jsdl/2005/11/jsdl"> <JobDescription> <Application> <POSIXApplication xmlns="http://schemas.ggf.org/jsdl/2005/11/jsdl-posix"> <Executable>/bin/hostname</Executable> <Output>host.txt</Output> <WorkingDirectory>./tmp</WorkingDirectory> </POSIXApplication> </Application> </JobDescription> <MyProxy xmlns="urn:gridsam:myproxy"> <ProxyServer>*******</ProxyServer> <ProxyServerUserName>******</ProxyServerUserName> <ProxyServerPassPhrase>******</ProxyServerPassPhrase> </MyProxy> </JobDefinition> Regards, Yoshikazu Tanaka >Hi, >We are aware that there is an issue relating to gsiftp transfers. >The problem seems to be an unclosed socket when staging files via gsiftp. >When a file is staged back to gridsam, the connection used for the transfer >remains in CLOSED_WAIT indefinitely. I believe that the underlying commons >vfs library, or perhaps ultimately part of the cog kit is not releasing the >resources correctly. >I am currently looking into the problem, and hope to have a fix shortly. >Regards, > Justin >On 2 Mar 2010, at 07:07, 田中 義一 wrote: >> <TooManyFiles> error occurs when we have submitted more than 500 jobs since >> invoking gridsam. >> We have observed directory in /proc/omii-server process#/fd, >> then we have understood that 1 socket file per 1 job remains left after job- >> completion. >> Please teach me how to destory job information after job-completion. Even if using gridsam-status, gridsam-terminate command, these socket files does't disappear. >> >> Environment >> CentOS 5.3 >> GridSAM 2.1.4 >> gridsam-jobmanager globus (GT 4.0.5) >> >> Center for Grid Research and Development(NAREGI) >> Yoshikazu Tanaka >> >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> GridSAM-Discuss mailing list >> Gri...@li... >> https://lists.sourceforge.net/lists/listinfo/gridsam-discuss >-- >Justin Bradley >Software Engineer >j.b...@om... >OMII-UK >Bay 23, 4067, B32 >University of Southampton |
|
From: Justin B. <jb...@ec...> - 2010-03-03 17:47:19
|
Hi, We are aware that there is an issue relating to gsiftp transfers. The problem seems to be an unclosed socket when staging files via gsiftp. When a file is staged back to gridsam, the connection used for the transfer remains in CLOSED_WAIT indefinitely. I believe that the underlying commons vfs library, or perhaps ultimately part of the cog kit is not releasing the resources correctly. I am currently looking into the problem, and hope to have a fix shortly. Regards, Justin On 2 Mar 2010, at 07:07, 田中 義一 wrote: > <TooManyFiles> error occurs when we have submitted more than 500 jobs since > invoking gridsam. > We have observed directory in /proc/omii-server process#/fd, > then we have understood that 1 socket file per 1 job remains left after job- > completion. > Please teach me how to destory job information after job-completion. Even if using gridsam-status, gridsam-terminate command, these socket files does't disappear. > > Environment > CentOS 5.3 > GridSAM 2.1.4 > gridsam-jobmanager globus (GT 4.0.5) > > Center for Grid Research and Development(NAREGI) > Yoshikazu Tanaka > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > GridSAM-Discuss mailing list > Gri...@li... > https://lists.sourceforge.net/lists/listinfo/gridsam-discuss -- Justin Bradley Software Engineer j.b...@om... OMII-UK Bay 23, 4067, B32 University of Southampton |
|
From: 田中 義一 <yt...@ni...> - 2010-03-02 07:07:21
|
<TooManyFiles> error occurs when we have submitted more than 500 jobs since invoking gridsam. We have observed directory in /proc/omii-server process#/fd, then we have understood that 1 socket file per 1 job remains left after job- completion. Please teach me how to destory job information after job-completion. Even if using gridsam-status, gridsam-terminate command, these socket files does't disappear. Environment CentOS 5.3 GridSAM 2.1.4 gridsam-jobmanager globus (GT 4.0.5) Center for Grid Research and Development(NAREGI) Yoshikazu Tanaka |
|
From: Pawel S. <Paw...@bc...> - 2009-11-13 14:15:06
|
Hi, Is IndividualPhysicalMemory (or IndividualVirtualMemory) from JSDL job description (Resources element) supported in GridSAM? How about CPUSpeed, Time and Count elements? Are there plans to support them? Cheers, Pawel |
|
From: Justin B. <jb...@ec...> - 2009-10-28 17:34:44
|
Hi All, Following on from the recent series of GridSAM releases. We are pleased to announce the release of GridSAM 2.1.9. This release focuses on performance enhancements as well as incorporating some new features. The motivation for this version and its release has been from: OMII-UK's continuing work with Professor Sally Price's Computational Chemistry Group at UCL. From the work done with the Irish Centre for High End Computing. And from the integration of the work done for the EMERGE project from the Institute of Computing Technology (China). This is the first release since 2.1.7 as 2.1.8 was used as milestone build for some of the new features. See http://www.omii.ac.uk/wiki/GridSAM for more details. For a list of technical changes see http://gridsam.svn.sf.net/viewvc/gridsam/trunk/GridSAM-2.1.x-Change-Log.txt Regards Justin -- Justin Bradley Design & Development Team Leader j.b...@om... OMII-UK Bay 23, 4067, B32 University of Southampton |
|
From: Stefan Z. <ste...@uc...> - 2009-10-05 15:43:32
|
On 5 Oct 2009, at 16:27, John S Robinson wrote: > On Monday 05 October 2009 15:01:46 Stefan Zasada wrote: > >> The corrupted ones are larger. For text files it seems that a byte is >> added for each line of the file - it looks like DOS style carriage >> returns are being automatically added for each file. >> > > Hi Stefan, > > Just to clarify, am I right in assuming that no Windows machines are > involved > at any stage? > No, all the machines are running variants of Linux. Cheers, Stefan. > Cheers, > > JohnR. > > -- > ---------------------------------------- > John S. Robinson, BSc. (Hons) > OMII-UK | www.omii.ac.uk > School of Electronics & Computer Science > University of Southampton, SO17 1BJ, UK > J.S...@so... > ---------------------------------------- > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9-12, 2009. Register > now! > http://p.sf.net/sfu/devconf > _______________________________________________ > GridSAM-Discuss mailing list > Gri...@li... > https://lists.sourceforge.net/lists/listinfo/gridsam-discuss |
|
From: John S R. <J.S...@so...> - 2009-10-05 15:28:23
|
On Monday 05 October 2009 15:01:46 Stefan Zasada wrote: > The corrupted ones are larger. For text files it seems that a byte is > added for each line of the file - it looks like DOS style carriage > returns are being automatically added for each file. > Hi Stefan, Just to clarify, am I right in assuming that no Windows machines are involved at any stage? Cheers, JohnR. -- ---------------------------------------- John S. Robinson, BSc. (Hons) OMII-UK | www.omii.ac.uk School of Electronics & Computer Science University of Southampton, SO17 1BJ, UK J.S...@so... ---------------------------------------- |
|
From: Stefan Z. <ste...@uc...> - 2009-10-05 14:02:22
|
Hi Justin, On 2 Oct 2009, at 10:19, Justin Bradley wrote: > Hi Stefan, > > This is not a problem I've seen before. I have a few questions... > Which version of GridSAM is this with? Sorry, I should have said: it's GridSAM 2.0.2 in OMII 3.4 > And what type of WebDAV server is this (tomcat's, httpd apache's)? I've tried with both Tomcat and Apache, and the same thing happens. > Is there a way to see if the corrupted files have been truncated > rather than transcoded (are the corrupted ones smaller, and have > they been turned from 'data' to 'text')? > The corrupted ones are larger. For text files it seems that a byte is added for each line of the file - it looks like DOS style carriage returns are being automatically added for each file. The original file on the NGS machine: $ file alanin.xsc alanin.xsc: ASCII text The file that has been staged to WebDav by GridSAM: $ file alanin.xsc alanin.xsc: ASCII text, with CRLF line terminators Extra bytes are also being added to the binary files that are staged back, but I'm not sure what they are. Thanks, Stefan. > Justin > > On 2 Oct 2009, at 10:10, Stefan Zasada wrote: > >> Hi, >> >> We have GridSAM instances setup to submit jobs to the UK NGS via >> the Globus GRAM 2 connector. When running our jobs, we use GridSAM >> to stage input and output data from a WebDav server to the GridFTP >> server running on the NGS node we are using. While there are no >> problems staging files from our WebDav server to the NGS, when we >> stage data back we see that some of the files have been mangled. >> All files staged back to the WebDav server after the job completes >> are of different sizes and have different MD5 signatures to the >> original versions on the NGS node, for example: >> >> NGS >> [ngs0009@vidar 154382481094266025861]$ md5sum fbpc-1-a-3.out.dcd >> ba25432f11942ab81d325796dbfc7003 fbpc-1-a-3.out.dcd >> >> Local machine >> nak 585 $ md5 fbpc-1-a-3.out.dcd >> MD5 (fbpc-1-a-3.out.dcd) = f6ecc06a87df9cd559519de4ea467bbc >> >> >> Has anyone come across this problem before? We are using GridSAM >> with OMII container >> >> Any help resolving this would be much appreciated. >> >> Thanks, >> >> Stefan. >> ------------------------------------------------------------------------------ >> Come build with us! The BlackBerry® Developer Conference in SF, >> CA >> is the only developer event you need to attend this year. Jumpstart >> your >> developing skills, take BlackBerry mobile applications to market >> and stay >> ahead of the curve. Join us from November 9-12, 2009. Register >> now! >> http://p.sf.net/sfu/devconf_______________________________________________ >> GridSAM-Discuss mailing list >> Gri...@li... >> https://lists.sourceforge.net/lists/listinfo/gridsam-discuss > > -- > Justin Bradley > Design & Development Team Leader > j.b...@om... > OMII-UK > Bay 23, 4067, B32 > University of Southampton > > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9-12, 2009. Register > now! > http://p.sf.net/sfu/devconf_______________________________________________ > GridSAM-Discuss mailing list > Gri...@li... > https://lists.sourceforge.net/lists/listinfo/gridsam-discuss |
|
From: Justin B. <jb...@ec...> - 2009-10-02 09:19:54
|
Hi Stefan, This is not a problem I've seen before. I have a few questions... Which version of GridSAM is this with? And what type of WebDAV server is this (tomcat's, httpd apache's)? Is there a way to see if the corrupted files have been truncated rather than transcoded (are the corrupted ones smaller, and have they been turned from 'data' to 'text')? Justin On 2 Oct 2009, at 10:10, Stefan Zasada wrote: > Hi, > > We have GridSAM instances setup to submit jobs to the UK NGS via the > Globus GRAM 2 connector. When running our jobs, we use GridSAM to > stage input and output data from a WebDav server to the GridFTP > server running on the NGS node we are using. While there are no > problems staging files from our WebDav server to the NGS, when we > stage data back we see that some of the files have been mangled. All > files staged back to the WebDav server after the job completes are > of different sizes and have different MD5 signatures to the original > versions on the NGS node, for example: > > NGS > [ngs0009@vidar 154382481094266025861]$ md5sum fbpc-1-a-3.out.dcd > ba25432f11942ab81d325796dbfc7003 fbpc-1-a-3.out.dcd > > Local machine > nak 585 $ md5 fbpc-1-a-3.out.dcd > MD5 (fbpc-1-a-3.out.dcd) = f6ecc06a87df9cd559519de4ea467bbc > > > Has anyone come across this problem before? We are using GridSAM > with OMII container > > Any help resolving this would be much appreciated. > > Thanks, > > Stefan. > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry® Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart > your > developing skills, take BlackBerry mobile applications to market and > stay > ahead of the curve. Join us from November 9-12, 2009. Register > now! > http://p.sf.net/sfu/devconf_______________________________________________ > GridSAM-Discuss mailing list > Gri...@li... > https://lists.sourceforge.net/lists/listinfo/gridsam-discuss -- Justin Bradley Design & Development Team Leader j.b...@om... OMII-UK Bay 23, 4067, B32 University of Southampton |
|
From: Stefan Z. <ste...@uc...> - 2009-10-02 09:10:43
|
Hi, We have GridSAM instances setup to submit jobs to the UK NGS via the Globus GRAM 2 connector. When running our jobs, we use GridSAM to stage input and output data from a WebDav server to the GridFTP server running on the NGS node we are using. While there are no problems staging files from our WebDav server to the NGS, when we stage data back we see that some of the files have been mangled. All files staged back to the WebDav server after the job completes are of different sizes and have different MD5 signatures to the original versions on the NGS node, for example: NGS [ngs0009@vidar 154382481094266025861]$ md5sum fbpc-1-a-3.out.dcd ba25432f11942ab81d325796dbfc7003 fbpc-1-a-3.out.dcd Local machine nak 585 $ md5 fbpc-1-a-3.out.dcd MD5 (fbpc-1-a-3.out.dcd) = f6ecc06a87df9cd559519de4ea467bbc Has anyone come across this problem before? We are using GridSAM with OMII container Any help resolving this would be much appreciated. Thanks, Stefan. |
|
From: Justin B. <jb...@ec...> - 2009-08-17 12:55:53
|
Hi Pawel, The support for WallTimeLimit is only the ICT connectors (ict-pbs, ict- condor, lsf) and Fork. It is not in the older PBS and Condor connectors. As a test I added the following line <WallTimeLimit>42</WallTimeLimit> into the JobDescription/POSIXApplication section of my JSDL. This resulted in the following line being included in the generated PBS input file periodic_remove=(currentTime - EnteredCurrentStatus)>42:00:00 Hope that helps. Justin On 17 Aug 2009, at 12:42, Pawel Sztromwasser wrote: > Hi, > > I am trying to use WallTimeLimit element in JSDL job description. Is > it > supported by GridSAM? I can't see any change neither in generated pbs > script, nor in the qstat output. > > Cheers, > Pawel > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > GridSAM-Discuss mailing list > Gri...@li... > https://lists.sourceforge.net/lists/listinfo/gridsam-discuss -- Justin Bradley Design & Development Team Leader j.b...@om... OMII-UK Bay 23, 4067, B32 University of Southampton |
|
From: Pawel S. <Paw...@bc...> - 2009-08-17 11:42:44
|
Hi, I am trying to use WallTimeLimit element in JSDL job description. Is it supported by GridSAM? I can't see any change neither in generated pbs script, nor in the qstat output. Cheers, Pawel |
|
From: Justin B. <jb...@ec...> - 2009-08-10 15:18:59
|
Hi All, Following on from the recent series of GridSAM releases. We are pleased to announce the release of GridSAM 2.1.7 This release mainly focuses on configuration enhancements, 3rd party library updates and bug fixes. See https://sourceforge.net/projects/gridsam/files/gridsam/2.1.7/ GridSAM 2.1.7 is a release intended for developers and since the 2.1.6 release the following changes have been made. Moved from Quartz 1.4.5 to a patched 1.6.5 for database performance reasons. This also requires the use of commons-collections 3.2 rather than 2.1.1. (See subversion revisions 460 447-443, 437.) Initial round of changes to support supplying user credentials as a set of additional soap headers. This is as an alternative to using the serverside map between certificate DN and unix user. This change relies upon omii-security-utils-1.2.jar (rather than 1.1). (See subversion revisions 461, 457.) Relocated org/icenigrid/gridsam/resource/config/ from within the gridsam-core jar into the webapp in WEB-INF/classes/base-config so it can be configured without having to rebuild the jar from source. Rationalised condor and pbs configuration files usage. (See subversion revisions 456-454, 451-448, 442-438.) Set MySQL database to automatically reconnect, this will alleviate timeout issues on longer runs. Add a length to the serializable types to help advise MySql to use a type larger than a tinyblob (256 bytes). (See subversion revisions 462, 453, 452, 435.) Moved the bug fixed and more efficient condor submit code into common and change the existing pbs/lsf code to use the common version. (See subversion revisison 436.) omii-security-utils-1.2.jar is supplied here for convenience as it not yet otherwise publically available. It is also designed to be used with OMII-UK's - Campus Grid Toolkit 1.1.3 - Development Kit 3.4.4 These are available from www.omii.ac.uk Support is available via su...@om... Regards, Justin -- Justin Bradley Design & Development Team Leader j.b...@om... OMII-UK Bay 23, 4067, B32 University of Southampton |
|
From: Justin B. <jb...@ec...> - 2009-08-10 10:55:18
|
Hi Elliott, GridSAM doesn't support recursive file copy. Also ftp doesn't either. What I suggest you do is tar or zip (or even jar) up the directory and send the resulting file over in one go. Then also send over a script to be used as the Executable which unpacks the archive file and uses its contents. The 'fractal' sample client which comes with the OMII-UK Campus Grid Toolkit uses this method. Let me know if you require any more help with this. Regards, Justin On 5 Aug 2009, at 17:36, eh...@ba... wrote: > Hi > > I am attempting to stage in a whole directory for use within GridSAM, > the JSDL that I am using to do this is: > > <JobDefinition xmlns="http://schemas.ggf.org/jsdl/2005/11/jsdl"> > <JobDescription> > <Application> > <POSIXApplication > xmlns="http://schemas.ggf.org/jsdl/2005/11/jsdl-posix"> > <Executable>/bin/echo</Executable> > <Argument>Hello World</Argument> > </POSIXApplication> > </Application> > <DataStaging> > <FileName>./GridScape/bin</FileName> > <CreationFlag>overwrite</CreationFlag> > <Source> > <URI>ftp://anonymous@localhost:44556/GridScape/bin</ > URI> > </Source> > </DataStaging> > </JobDescription> > </JobDefinition> > > However the GridSAM job fails with the error message: > > reason for {failed} state - Could not determine the size of > "ftp://anonymous@localhost:44556/GridScape/bin" because it is not a > file. > > How do I go about staging in whole directories for use within a > GridSAM job? > > Thanks > Elliott Hill > > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 > 30-Day > trial. Simplify your report design, integration and deployment - and > focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > GridSAM-Discuss mailing list > Gri...@li... > https://lists.sourceforge.net/lists/listinfo/gridsam-discuss -- Justin Bradley Design & Development Team Leader j.b...@om... OMII-UK Bay 23, 4067, B32 University of Southampton |
|
From: <eh...@ba...> - 2009-08-05 16:36:42
|
Hi I am attempting to stage in a whole directory for use within GridSAM, the JSDL that I am using to do this is: <JobDefinition xmlns="http://schemas.ggf.org/jsdl/2005/11/jsdl"> <JobDescription> <Application> <POSIXApplication xmlns="http://schemas.ggf.org/jsdl/2005/11/jsdl-posix"> <Executable>/bin/echo</Executable> <Argument>Hello World</Argument> </POSIXApplication> </Application> <DataStaging> <FileName>./GridScape/bin</FileName> <CreationFlag>overwrite</CreationFlag> <Source> <URI>ftp://anonymous@localhost:44556/GridScape/bin</URI> </Source> </DataStaging> </JobDescription> </JobDefinition> However the GridSAM job fails with the error message: reason for {failed} state - Could not determine the size of "ftp://anonymous@localhost:44556/GridScape/bin" because it is not a file. How do I go about staging in whole directories for use within a GridSAM job? Thanks Elliott Hill |
|
From: Steve C. <s.c...@om...> - 2009-07-31 16:10:11
|
Hi All, A new draft GridSAM roadmap for comment has been published on the OMII-UK website at: http://www.omii.ac.uk/news/news.jhtml?nid=252 It outlines OMII-UK's GridSAM development for the next 5 months from August, bringing together product requirements that have been received over previous months. Input and feedback from users, user groups, service providers and developers is invited. New requirements, requests for clarification or amendment to existing requirements or indications of support for existing requirements should be sent to either the GridSAM SourceForge project mailing lists (gridsam-discuss/gridsam-developer) or through the OMII-UK Support ticketing system. Due to technical issues we're experiencing with SourceForge file uploads, we've had to host the file on the OMII-UK website. Once these are resolved, you will also be able to find the roadmap here: https://sourceforge.net/projects/gridsam/files/project-docs/ We look forward to your input! Best Regards, Steve Crouch -- Dr Stephen Crouch, Software Architect, OMII-UK, School of Electronics and Computer Science, Room 4067, Level 4, Building 32, University of Southampton, Highfield, Southampton SO17 1BJ Tel: +44 (0)23 8059 8787 EMail: s.c...@om... Fax: +44 (0)23 8059 3045 WWW: http://www.ecs.soton.ac.uk/~stc |
|
From: <eh...@ba...> - 2009-07-29 17:11:00
|
Hi I am attempting to use GridSAM within another program and am calling the methods contained with the gridsam jars in omii-server-3.4.4. I have extracted these jars into the class path of the program that I am writing. Now when I attempt to call these classes and pass a job to GridSAM I am getting an error: javax.xml.rpc.ServiceException: No jsdl:JobDefinition element can be found in the request. Please check your input and the namespace declarations. To create the JobDefinitionDocument object that is passed to submitJob() I am using the parse(String) Factory method and passing in: <jsdl:JobDefinition xmlns:jsdl="http://schemas.ggf.org/jsdl/2005/11/jsdl"> <jsdl:JobDescription> <jsdl:Application>along side my own ( <jsdl-posix:POSIXApplication xmlns:jsdl-posix="http://schemas.ggf.org/jsdl/2005/11/jsdl-posix"> <jsdl-posix:Executable>/bin/echo</jsdl-posix:Executable> <jsdl-posix:Argument>hello world</jsdl-posix:Argument> </jsdl-posix:POSIXApplication> </jsdl:Application> </jsdl:JobDescription> </jsdl:JobDefinition> It appears that the JSDL is all correct. After tracing the calls back it appears that the error is coming from package org.icenigrid.gridsam.webservice.common.GridSAMService.submitJob(SubmitJobDocument pRequest) After running the code run in this package by manually recreating it, it will not fail the 'if' clause and throw the exception (it sees that there is one JobDefinition element in the JSDL), but the code within GridSAMService will still throw the exception. Does anyone have any steps that can solve this problem? Many Thanks Elliott Hill |
|
From: 田中 義一 <yt...@gr...> - 2009-07-24 06:17:05
|
Dr Stephen Crouch: Thank you very much for your kind explanation. I have succeeded in using bes-interface. > Out of interest, could I ask how you are currently using GridSAM? And > also, how you intend to use the BES interface? It's always very I intended to use the BES interface only because of getting a better understaing of BES. I am now developing a seamless user interface for job-submission and monitoring GUI tool for GridSAM and NAREGI(Japanese grid http://www.naregi.org). GridSAM service is on laboratory resources, and NAREGI is on grid resources. Y.Tanaka Steve Crouch wrote: > Hi Y.Tanaka, > > Yes, the OGSA-BES v1.0 interface is indeed supported within GridSAM. By > default, the GridSAM service already has this interface ready for use, > so from the client, in the omii-uk-client/gridsam/bin directory for > example, you can run: > > ./bes-create-activity -s > https://yourserver:port/gridsam/services/bes?wsdl -j something.jsdl > > An EndpointReference (EPR) will be returned on std output which uniquely > identifies the job, e.g. (formatted for clarity): > > <?xml version="1.0" encoding="UTF-8"?> > <EndpointReference xmlns="http://www.w3.org/2005/08/addressing"> > <Address>https://blade10.omii.ac.uk:18443/gridsam/services/bes</Address> > <ReferenceParameters> > <JobIdentifier xmlns="http://www.icenigrid.org/service/gridsam"> > <ID>urn:gridsam:18ce6dd322a31d1b0122a70745c90028</ID> > </JobIdentifier> > </ReferenceParameters> > </EndpointReference> > > ...which you can capture like this: > > ./bes-create-activity -s > https://yourserver:port/gridsam/services/bes?wsdl -j something.jsdl > > epr.text > > And then use the following to check the status of the submission (see > caveat below!): > > ./bes-get-activity-statuses -s > https://yourserver:port/gridsam/services/bes?wsdl -file epr.text > > Which returns a GetActivityStatusResponse with the status(es) included. > This epr file can contain a number of EPRs, which means you can query > the status of many jobs at a time. > > You can also use the bes-terminate-activities command in a similar > manner to pre-emptively kill jobs, and similarly the > bes-get-activity-documents command to return JSDLs that were submitted > for a given list of jobs. > > Of course, being an open interface, you should be able to use any > BES-v1.0 compliant client to submit jobs to GridSAM using this > interface, although the tricky part is to configure compatible security > between the BES client and GridSAM. In addition, GridSAM also supports > HPC Basic Profile v1.0 and HPC Profile Application Extension v1.0, which > may be handy to look at when constructing JSDL that works between > different BES implementations. > > > In terms of how to use this interface within a client-side Java > application, you can see how to use the API by looking within > modules/client/src/main/java/org/icenigrid/gridsam/client/cli/ within > the GridSAM source release on SourceForge, and looking at the API docs > within the client release e.g. > omii-uk-client/gridsam/docs/gridsam-client/apidocs > > At the moment, however, there are a number of minor issues with the BES > interface we are currently working on: > > -- Completed documentation for the BES interface, support and commands > > -- The bes-* commands currently return the following message when used: > {http://schemas.xmlsoap.org/soap/envelope/}encodingStyle already exists > > ...on the first line, which doesn't cause the commands to fail, but is a > nuisance. When submitting a job using bes-create-activity, you can > filter this out using something like: > > ./bes-create-activity -s > https://yourserver:port/gridsam/services/bes?wsdl -j something.jsdl | > grep -v 'encodingStyle already exists' > epr.text > > Which removes the unwanted message and ensures the EPR can be used > correctly. > > -- The bes-get-factory-attributes-document command (which returns a list > of available computational resources provided by the BES service) > currently isn't supported within the Globus connector. > > Out of interest, could I ask how you are currently using GridSAM? And > also, how you intend to use the BES interface? It's always very > valuable to know how our products are being used, and this can help us > to be more informed when helping you in the future. > > I hope this helps, please let us know if you have any further questions, > > Regards, > > Steve Crouch > > 逕ー荳ュ縲セゥ荳wrote: > > Hello > > > > I have installed and used Gridsam2.1.4 by globus engine. > > Paper says that Gridsam supports OGSA-BES standard. > > If we can use BES-interface, please show me examples(how to > > use this interface in GridSAM) > > > > Thanks in advance. > > > > National Institute of Informatics > > Y.Tanaka > > > > > > > > ------------------------------------------------------------------------------ > > Enter the BlackBerry Developer Challenge > > This is your chance to win up to $100,000 in prizes! For a limited time, > > vendors submitting new applications to BlackBerry App World(TM) will have > > the opportunity to enter the BlackBerry Developer Challenge. See full prize > > details at: http://p.sf.net/sfu/Challenge > > _______________________________________________ > > GridSAM-Discuss mailing list > > Gri...@li... > > https://lists.sourceforge.net/lists/listinfo/gridsam-discuss > > -- > Dr Stephen Crouch, > Software Architect, > OMII-UK, > School of Electronics and Computer Science, > Room 4067, Level 4, Building 32, > University of Southampton, > Highfield, Southampton SO17 1BJ > Tel: +44 (0)23 8059 8787 EMail: s.c...@om... > Fax: +44 (0)23 8059 3045 WWW: http://www.ecs.soton.ac.uk/~stc > > > |
|
From: Steve C. <s.c...@om...> - 2009-07-23 12:34:04
|
Hi Y.Tanaka, Yes, the OGSA-BES v1.0 interface is indeed supported within GridSAM. By default, the GridSAM service already has this interface ready for use, so from the client, in the omii-uk-client/gridsam/bin directory for example, you can run: ./bes-create-activity -s https://yourserver:port/gridsam/services/bes?wsdl -j something.jsdl An EndpointReference (EPR) will be returned on std output which uniquely identifies the job, e.g. (formatted for clarity): <?xml version="1.0" encoding="UTF-8"?> <EndpointReference xmlns="http://www.w3.org/2005/08/addressing"> <Address>https://blade10.omii.ac.uk:18443/gridsam/services/bes</Address> <ReferenceParameters> <JobIdentifier xmlns="http://www.icenigrid.org/service/gridsam"> <ID>urn:gridsam:18ce6dd322a31d1b0122a70745c90028</ID> </JobIdentifier> </ReferenceParameters> </EndpointReference> ...which you can capture like this: ./bes-create-activity -s https://yourserver:port/gridsam/services/bes?wsdl -j something.jsdl > epr.text And then use the following to check the status of the submission (see caveat below!): ./bes-get-activity-statuses -s https://yourserver:port/gridsam/services/bes?wsdl -file epr.text Which returns a GetActivityStatusResponse with the status(es) included. This epr file can contain a number of EPRs, which means you can query the status of many jobs at a time. You can also use the bes-terminate-activities command in a similar manner to pre-emptively kill jobs, and similarly the bes-get-activity-documents command to return JSDLs that were submitted for a given list of jobs. Of course, being an open interface, you should be able to use any BES-v1.0 compliant client to submit jobs to GridSAM using this interface, although the tricky part is to configure compatible security between the BES client and GridSAM. In addition, GridSAM also supports HPC Basic Profile v1.0 and HPC Profile Application Extension v1.0, which may be handy to look at when constructing JSDL that works between different BES implementations. In terms of how to use this interface within a client-side Java application, you can see how to use the API by looking within modules/client/src/main/java/org/icenigrid/gridsam/client/cli/ within the GridSAM source release on SourceForge, and looking at the API docs within the client release e.g. omii-uk-client/gridsam/docs/gridsam-client/apidocs At the moment, however, there are a number of minor issues with the BES interface we are currently working on: -- Completed documentation for the BES interface, support and commands -- The bes-* commands currently return the following message when used: {http://schemas.xmlsoap.org/soap/envelope/}encodingStyle already exists ...on the first line, which doesn't cause the commands to fail, but is a nuisance. When submitting a job using bes-create-activity, you can filter this out using something like: ./bes-create-activity -s https://yourserver:port/gridsam/services/bes?wsdl -j something.jsdl | grep -v 'encodingStyle already exists' > epr.text Which removes the unwanted message and ensures the EPR can be used correctly. -- The bes-get-factory-attributes-document command (which returns a list of available computational resources provided by the BES service) currently isn't supported within the Globus connector. Out of interest, could I ask how you are currently using GridSAM? And also, how you intend to use the BES interface? It's always very valuable to know how our products are being used, and this can help us to be more informed when helping you in the future. I hope this helps, please let us know if you have any further questions, Regards, Steve Crouch 田中 義一 wrote: > Hello > > I have installed and used Gridsam2.1.4 by globus engine. > Paper says that Gridsam supports OGSA-BES standard. > If we can use BES-interface, please show me examples(how to > use this interface in GridSAM) > > Thanks in advance. > > National Institute of Informatics > Y.Tanaka > > > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited time, > vendors submitting new applications to BlackBerry App World(TM) will have > the opportunity to enter the BlackBerry Developer Challenge. See full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > GridSAM-Discuss mailing list > Gri...@li... > https://lists.sourceforge.net/lists/listinfo/gridsam-discuss -- Dr Stephen Crouch, Software Architect, OMII-UK, School of Electronics and Computer Science, Room 4067, Level 4, Building 32, University of Southampton, Highfield, Southampton SO17 1BJ Tel: +44 (0)23 8059 8787 EMail: s.c...@om... Fax: +44 (0)23 8059 3045 WWW: http://www.ecs.soton.ac.uk/~stc |
|
From: Justin B. <jb...@ec...> - 2009-07-20 09:24:23
|
Hello, Sorry for the delay in responding. We will look into this and get back to you as soon as we can. Regards, Justin On 15 Jul 2009, at 09:06, 田中 義一 wrote: > Hello > > I have installed and used Gridsam2.1.4 by globus engine. > Paper says that Gridsam supports OGSA-BES standard. > If we can use BES-interface, please show me examples(how to > use this interface in GridSAM) > > Thanks in advance. > > National Institute of Informatics > Y.Tanaka > > > > ------------------------------------------------------------------------------ > Enter the BlackBerry Developer Challenge > This is your chance to win up to $100,000 in prizes! For a limited > time, > vendors submitting new applications to BlackBerry App World(TM) will > have > the opportunity to enter the BlackBerry Developer Challenge. See > full prize > details at: http://p.sf.net/sfu/Challenge > _______________________________________________ > GridSAM-Discuss mailing list > Gri...@li... > https://lists.sourceforge.net/lists/listinfo/gridsam-discuss -- Justin Bradley Design & Development Team Leader j.b...@om... OMII-UK Bay 23, 4067, B32 University of Southampton |
|
From: Pawel S. <Paw...@bc...> - 2009-07-20 07:18:37
|
Hi,
Sorry for not replying for a long time, but I was away. I am back to the
issue now.
So I had some chats with HPC engineer here and I think we are closer to
finding the problem now. So it seems to be due to our setup: I am
running GridSAM on virtual machine (lets call it VM) which is a mirror
copy of submition node (SN) to the cluster. They have many in common,
but not the filesystem. So basically PBS script generated by GridSAM is
running on one machine while GridSAM on another. I am not sure if such a
usecase has been thought of, but apparently the generated PBS script
(snippet at the end of email) tries to 'cd' from SN to a directory
(PBS_O_WORKDIR) that is on VM, which obviously fails. This brings me to
suspicion that file .complete touched at the end of the script is never
created in place where GridSAM expects it to be, so it does not know
when the job completes. Stdout and stderr files configured in PBS script
(#PBS -o and #PBS -e) get to the right place though, so PBS handles this
virtual-machine setup.
We came up with two solutions to that: either SN and VM have to share
some disc space mounted in the same path in both, or we can alter the
way PBS script is generated. And here comes the question: is that
possible? Is there some config file I can alter in order to get for
example "ssh VM:$PBS_O_WORKDIR/ touch .complete" instead of "touch
.complete"?
Cheers,
Paweł
-----------------
#! /bin/sh
# PBS batch job script built by Globus job manager
#
#PBS -S /bin/sh
#PBS -Wx=NODESET:ONEOF:FEATURE:switch10:switch11:ecs
#PBS -o /tmp/blast1.out
#PBS -e /tmp/blast1.err
cd ${PBS_O_WORKDIR}
/export/fimm/local2/blast-2.2.13/bin/blastall \
-i /work/pawels/blast-runs/seq/batch0.fasta -p blastp -d
/work2/speil/flatdb/genbank/fasta/nr -m7
touch .complete
------------------
Justin Bradley wrote:
> Hi Pawel,
>
> Sorry for the slow response.
>
> The UserMappingStage warning is nothing to worry about. GridSAM can be
> set up to map user certificates to local users, then submit jobs as that
> user. Rather than the default which is to run the jobs as the user
> running the Tomcat container.
>
> The SPMDVariation is also nothing to be concerned by unless you are
> using MPI.
>
> The PBSStageStatus is alas only a poorly formatted piece of logging.
>
> I must ad it I'm slightly stumped. However it may be beneficial if you
> sent me both some working JSDL and some from your problematic job. And
> I'll take a look to see if there is anything wrong. Also could you send
> me: tomcat/logs/gridsam.log records/omii
> webapps/gridsam/WEB-INF/classes/jobmanager.xml and jobmanager-pbs.xml
>
> There are known edge cases with the default PBS connector where if a job
> completes too quickly, it can be removed from the PBS queue such that
> qstat no longer reports its status. Then GridSAM can loose track of the
> job. However, this doesn't feel like this problem (and there are
> several workarounds if it was.)
>
> Justin
>
> On 24 May 2009, at 21:55, Pawel Sztromwasser wrote:
>
>>
>> Hi Justin,
>>
>>> Is this PBS Torque and using the default scheduler?
>> yes this is Torque. scheduler is combination of Torque and Maui
>>> If the simple jobs work with GridSAM, then the more complex ones
>>> shouldn't really be any different.
>>> You could check the gridsam.log in tomcat/logs, see if that mentions
>>> anything useful. Feel free to email this to me if you like.
>>
>> This are the only warnings and errors I have found (there are a few
>> occurrences of each of these three, but no other errors/warns)
>>
>> $ grep WARN gridsam.log.2009-05-19
>> 2009-05-19 16:37:49,303 WARN [UserMappingStage] You disabled security
>> features: pool accounts and private workding directory.
>> 2009-05-19 16:37:49,339 WARN [UserMappingStage] Use the local user
>> account (pawels) of OU=CBU, O=UiB, EMAILADDRESS=<my_email>, C=Norway,
>> ST=Hordaland,
>>
>> $ grep ERROR gridsam.log.2009-05-19
>> 2009-05-19 15:48:03,989 ERROR [ResourceRegistry]
>> classpath:org/icenigrid/gridsam/resource/config/common.xml, line 135,
>> column 81 - No value available for symbol 'gridsam.SPMDVariation'.
>>
>>
>> This was interesting though:
>>
>> 2009-05-19 17:19:26,941 INFO [PBSStatusStage] monitoring PBS using
>> /opt/torque/bin/qstat2116221.hpcmaster.bccs.uib.no
>>
>> There is no space between qstat and jobId. I don't know if this is
>> smth to worry about or just the way log4j prints this message?
>>
>> Cheers,
>> Pawel
>>
>>>
>>> Justin
>>>
>>>
>>> On 22 May 2009, at 07:23, Pawel Sztromwasser wrote:
>>>
>>>> Justin Bradley wrote:
>>>>> Hi Pawel,
>>>>> Which version of PBS are you using?
>>>>
>>>> pbs_server is version 2.3.5
>>>>
>>>>> And are the PBS server and scheduler on the same machine as GridSAM?
>>>>
>>>> No. GridSAM is running on a virtual machine that has access to the
>>>> queue (and scheduling tools like qsub, qstat...), but not to
>>>> pbs_server for example. I can run jobs on the cluster from this
>>>> virtual machine as I was on the cluster itself (this is what
>>>> cluster's admin said;). Does this affect GridSAM?
>>>>
>>>> Pawel
>>>>
>>>>> Justin
>>>>> On 20 May 2009, at 13:51, Pawel Sztromwasser wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I guess similar issue has been mentioned once on the mailing list,
>>>>>> but
>>>>>> doesn't look like solved:
>>>>>>
>>>>>> http://sourceforge.net/mailarchive/forum.php?thread_name=002701c64d08%2449efd790%24db421080%40cs.ucl.ac.uk&forum_name=gridsam-discuss
>>>>>>
>>>>>>
>>>>>> This also looks relevant, but I think it has been included into
>>>>>> version
>>>>>> of GridSAM I am using (2.1.4):
>>>>>>
>>>>>> http://sourceforge.net/mailarchive/forum.php?thread_name=20080617145418.605536413%40soton.ac.uk&forum_name=gridsam-developer
>>>>>>
>>>>>>
>>>>>> So what is the problem? I configured GridSAM to run jobs using PBS
>>>>>> and
>>>>>> then I am submitting them using GridSAM's Web Services. Jobs start
>>>>>> OK,
>>>>>> but their status freezes at state 'active' (response from
>>>>>> getJobStatus
>>>>>> method below). I checked jobs on the cluster and they had
>>>>>> finished, so
>>>>>> it seems like GridSAM doesn't check properly job's status on the
>>>>>> cluster. It worked properly while running simple POSIX programs
>>>>>> like cat
>>>>>> and echo, so it is something with PBS.
>>>>>>
>>>>>> I double checked pbs.PBSJobStatusCommand in jobmanager-pbs.xml
>>>>>> file and
>>>>>> it is correct. Is there anything additional that GridSAM uses to
>>>>>> check
>>>>>> if job completed on the cluster? maybe something is wrong with my
>>>>>> setup,
>>>>>> like directories with wrong permissions it can't access?
>>>>>>
>>>>>> I am using GridSAM 2.1.4 with OMII toolkit 3.4.4.
>>>>>>
>>>>>> Thank you in advance for help,
>>>>>> Pawel
>>>>>>
>>>>>>
>>>>>> ------------------------
>>>>>> <getJobStatusResponse
>>>>>> xmlns="http://www.icenigrid.org/service/gridsam">
>>>>>> <JobStatus>
>>>>>> <JobIdentifier>
>>>>>> <ID>urn:gridsam:0131f86a215956de01215965031d000b</ID>
>>>>>> </JobIdentifier>
>>>>>> <Stage>
>>>>>> <State>pending</State>
>>>>>> <Description>job is being scheduled</Description>
>>>>>> <Time>2009-05-19T17:02:20.701+02:00</Time>
>>>>>> </Stage>
>>>>>> <Stage><State>staging-in</State><Description>staging
>>>>>> files...</Description><Time>2009-05-19T17:02:20.803+02:00</Time></Stage><Stage><State>staged-in</State><Description>no
>>>>>>
>>>>>> file needs to be staged
>>>>>> in</Description><Time>2009-05-19T17:02:20.807+02:00</Time></Stage>
>>>>>> <Stage>
>>>>>> <State>active</State>
>>>>>> <Description>job is being launched through
>>>>>> PBS</Description>
>>>>>> <Time>2009-05-19T17:02:20.933+02:00</Time>
>>>>>> </Stage>
>>>>>> <Property name="urn:pbs:script">
>>>>>>
>>>>>> #! /bin/sh
>>>>>> # PBS batch job script built by Globus job manager
>>>>>> #
>>>>>> #PBS -S /bin/sh
>>>>>> #PBS -Wx=NODESET:ONEOF:FEATURE:switch10:switch11:ecs
>>>>>>
>>>>>> #PBS -o /work/pawels/blast-runs/blast1.out
>>>>>>
>>>>>> #PBS -e /work/pawels/blast-runs/blast1.err
>>>>>>
>>>>>> cd ${PBS_O_WORKDIR}
>>>>>>
>>>>>> /local/blast-2.2.18/bin/blastall \
>>>>>> -i /work/pawels/blast-runs/seq/batch0.fasta -o
>>>>>> /work/pawels/blast-runs/seq/batch0.fasta.blast -p blastp -d
>>>>>> /net/compute-2-23.local/scratch/andersl/uniref90 -m7
>>>>>> touch .complete
>>>>>> </Property>
>>>>>> <Property name="urn:pbs:launched">true</Property>
>>>>>> <Property name="urn:gridsam:principal">OU=BCCS, O=UiB,
>>>>>> EMAILADDRESS=paw...@bc..., C=Norway, ST=Hordaland,
>>>>>> CN=gridsam_certificate</Property>
>>>>>> <Property
>>>>>> name="urn:gridsam:pbs:jobid">2116221.hpcmaster.bccs.uib.no</Property>
>>>>>> </JobStatus>
>>>>>> </getJobStatusResponse>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>>
>>>>>> Crystal Reports - New Free Runtime and 30 Day Trial
>>>>>> Check out the new simplified licensing option that enables
>>>>>> unlimited royalty-free distribution of the report engine
>>>>>> for externally facing server and web deployment.
>>>>>> http://p.sf.net/sfu/businessobjects
>>>>>> _______________________________________________
>>>>>> GridSAM-Discuss mailing list
>>>>>> Gri...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/gridsam-discuss
>>>>> --
>>>>> Justin Bradley
>>>>> Design & Development Team Leader
>>>>> j.b...@om...
>>>>> OMII-UK
>>>>> Bay 23, 4067, B32
>>>>> University of Southampton
>>>>
>>>
>>> --
>>> Justin Bradley
>>> Design & Development Team Leader
>>> j.b...@om...
>>> OMII-UK
>>> Bay 23, 4067, B32
>>> University of Southampton
>>>
>>>
>>>
>>>
>
> --
> Justin Bradley
> Design & Development Team Leader
> j.b...@om...
> OMII-UK
> Bay 23, 4067, B32
> University of Southampton
>
>
>
>
|
|
From: 田中 義一 <yt...@gr...> - 2009-07-15 08:06:18
|
Hello I have installed and used Gridsam2.1.4 by globus engine. Paper says that Gridsam supports OGSA-BES standard. If we can use BES-interface, please show me examples(how to use this interface in GridSAM) Thanks in advance. National Institute of Informatics Y.Tanaka |
2 messages has been excluded from this view by a project administrator.
