Creating job via StarCom is broken

Hi all,

I played around a bit with StarCom and tried to create a new job:

Code:

StarCom> login u=<user> p=<pass>
StarCom> createjob id=<our space> qid=1 w=65 cpu=60

While I suspect that this command is missing our solver id and the id of the benchmarks that shall actually be run (but it wasn't clear to me how this would work), this already gives me "ERROR: Error communicating with server"

Gereon

I also cannot create jobs (programmatically and via uploadJobXml). I get

> http 500 - internal server error
> Failed to upload Job XML: File is not valid because:
> "cvc-elt.1: Cannot find the declaration of element 'tns:Jobs'."

My file does contain a "Job" element, and it worked before.
(And I don't know why the error message refers to "cvc", as I'm in Termination).

- J.

gereon wrote:Hi all,

I played around a bit with StarCom and tried to create a new job:

Code:

StarCom> login u=<user> p=<pass>
StarCom> createjob id=<our space> qid=1 w=65 cpu=60

While I suspect that this command is missing our solver id and the id of the benchmarks that shall actually be run (but it wasn't clear to me how this would work), this already gives me "ERROR: Error communicating with server"

Gereon

Hello,

Sorry for the trouble you've been having with the command. Are the solvers and benchmarks you want to run actually in the space hierarchy rooted at the space given by the "id=" parameter? The createjob command doesn't support specifying a specific solver / set of benchmarks to run, so right now everything you want to run needs to be in the space hierarchy rooted at the given space. Specifically, every solver in the hierarchy will be run against every benchmark in its space (the same behavior that you'd get if you selected "run and keep hierarchy structure" from the job creation page).

j.waldmann wrote:I also cannot create jobs (programmatically and via uploadJobXml). I get

> http 500 - internal server error
> Failed to upload Job XML: File is not valid because:
> "cvc-elt.1: Cannot find the declaration of element 'tns:Jobs'."

My file does contain a "Job" element, and it worked before.
(And I don't know why the error message refers to "cvc", as I'm in Termination).

- J.

Thanks for pointing out the XML issue-- an error was introduced into the schema that is breaking validation. It will also be remedied in the next deploy. The "cvc-elt" error is an error specified by the W3C XML specification-- it isn't related to the CVC community.

When you say you can't make jobs programmatically, are you talking about the web interface or StarexecCommand? The web interface did have a javascript bug that will be fixed in the next deploy. I'm not sure yet what the issue is with StarexecCommand, but I was able to create jobs successfully from StarexecCommand in this space.

https://www.starexec.org/starexec/secure/explore/spaces.jsp?id=12159

eric-burns wrote:

gereon wrote:Hi all,

I played around a bit with StarCom and tried to create a new job:

Code:

StarCom> login u=<user> p=<pass>
StarCom> createjob id=<our space> qid=1 w=65 cpu=60

While I suspect that this command is missing our solver id and the id of the benchmarks that shall actually be run (but it wasn't clear to me how this would work), this already gives me "ERROR: Error communicating with server"

Gereon

Hello,

Sorry for the trouble you've been having with the command. Are the solvers and benchmarks you want to run actually in the space hierarchy rooted at the space given by the "id=" parameter? The createjob command doesn't support specifying a specific solver / set of benchmarks to run, so right now everything you want to run needs to be in the space hierarchy rooted at the given space. Specifically, every solver in the hierarchy will be run against every benchmark in its space (the same behavior that you'd get if you selected "run and keep hierarchy structure" from the job creation page).

Hi,

I'm using id=20150 (florian_corzilius, I'm a colleague).
Directly in this space is a single solver (1836) and the space has four subspaces (which are linked, as far as I understand the setup...).
I tried to copy or link the solver into one of the subspaces, but this fails with an error message that there already is a solver with the same name. However, I can't see any solver with this name in any of the subspaces...

> When you say you can't make jobs programmatically,
> are you talking about the web interface or StarexecCommand?

neither - my software is using your starexec/secure/upload/jobXML URL directly.

https://github.com/stefanvonderkrone/star-exec-presenter/blob/master/StarExec/Commands.hs#L439

- J.

gereon wrote:=

Hi,

I'm using id=20150 (florian_corzilius, I'm a colleague).
Directly in this space is a single solver (1836) and the space has four subspaces (which are linked, as far as I understand the setup...).
I tried to copy or link the solver into one of the subspaces, but this fails with an error message that there already is a solver with the same name. However, I can't see any solver with this name in any of the subspaces...

When you choose to "link" the solver, are you trying to link into the individual space, or the entire hierarchy? While there is no solver with the same name in the immediate subspaces of space 20150, I can see in the database that there is a solver (id = 1110) with the same name further down in the hierarchy. Either linking or copying to a hierarchy will fail if there is a conflict in any space.

j.waldmann wrote:> When you say you can't make jobs programmatically,
> are you talking about the web interface or StarexecCommand?

neither - my software is using your starexec/secure/upload/jobXML URL directly.

https://github.com/stefanvonderkrone/star-exec-presenter/blob/master/StarExec/Commands.hs#L439

- J.

Ah, I see. In that case, the same issue with the schema would have caused the problem. We have done a redeploy, so you should hopefully be able to upload job XML documents again.

> the same issue with the schema would have caused the problem. We have done a redeploy

now (Mon Aug 4 19:50:40 CEST 2014, StarExec revision 18152) I'm getting

> Failed to upload Job XML:\nFile is not valid because: "cvc-complex-type.3.2.2:
> Attribute 'cpu-timeout' is not allowed to appear in element 'Job'."

j.waldmann wrote:
now  (Mon Aug  4 19:50:40 CEST 2014,   StarExec revision 18152) I'm getting

> Failed to upload Job XML:\nFile is not valid because: "cvc-complex-type.3.2.2:
> Attribute 'cpu-timeout' is not allowed to appear in element 'Job'."

Sorry for any inconvenience.

We recently changed the job and space xml formats to make them more human-readable.
In our new format, 'cpu-timeout' isn't an element or attribute of 'Job'.
Rather, it's an element of 'JobAttributes'.
You can view the new schema when trying to upload space or job xmls.
There is also an example job xml when trying to upload job xml.
There doesn't seem to be one when uploading space xml, but
we'll be adding one soon.

Let us know if this isn't the issue.

> We recently changed the job and space xml formats ...

Ouch. Can you please announce such changes (or did I miss this),
ideally, ask for comments beforehand,
and think twice (or more) before you make a breaking change.

> ... to make them more human-readable.

Are these files ever actually read or written by a human?
I thought XML is just a (programming-)language agnostic notation
for data to be transmitted between machines.
"(more) human-readable" is the goal for the source code of program
that does the transmission.

> Can you please announce such changes

We definitely did discuss announcing this change.
I suspect that this change sneaked by before we wanted it to.

> Are these files ever actually read or written by a human?

One use-case is re-running a job with slightly different job pairs and
slightly different configuration (such as changing pre and post processors).

Being able to easily read our xml documents helps when creating
automated job generators.

We also find that tweaking xml files is useful when testing.

> I thought XML is just a (programming-)language agnostic notation for data to be transmitted between machines.

Our priority is definitely to simplify the automation and reiteration of jobs.
To this extent, our XML documents don't need to be human-readable.
However, we find that friendly data is easier to debug, easier to manipulate, and easier to maintain
both from the developer's end and the user's.

Sorry for causing any trouble and thanks for the feedback.

Let us know if you run into any more issues.