AutoRun.xml error

[Lorena Escudero]

Hello,

I am receiving emails with the log below with what looks like an xml parsing error every time a user is uploading images. I believe the user is using the Compressed Uploader method and this is being uploading one patient at a time. Any ideas how and where this is happening, and if this is something to be worried about? I can see the scans archived and I can open them with the viewer, so I haven't encountered any problems so far... 

Thanks,

Lorena 

Pipeline:  

/data/xnat/pipeline/catalog/xnat_tools/AutoRun.xml


Cause:  

org.nrg.pipeline.exception.PipelineEngineException: fileUtils:GetCachePath(/Pipeline/parameters/parameter[name='resolvedHost']/values/unique/text(), /Pipeline/parameters/parameter[name='user']/values/unique/text(), /Pipeline/parameters/parameter[name='pwd']/values/unique/text(),/Pipeline/parameters/parameter[name='project']/values/unique/text()) Encountered class net.sf.saxon.trans.XPathException==>org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 39; Content is not allowed in prolog. org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 39; Content is not allowed in prolog. at org.nrg.pipeline.xpath.XPathResolverSaxon.resolveXPathExpressions(XPathResolverSaxon.java:269) at org.nrg.pipeline.xpath.XPathResolverSaxon.resolveXPathExpressions(XPathResolverSaxon.java:153) at org.nrg.pipeline.xpath.XPathResolverSaxon.resolveXPathExpressions(XPathResolverSaxon.java:279) at org.nrg.pipeline.xpath.XPathResolverSaxon.evaluate(XPathResolverSaxon.java:87) at org.nrg.pipeline.utils.ParameterUtils.resolveParameterValues(ParameterUtils.java:183) at org.nrg.pipeline.utils.ParameterUtils.setParameterValues(ParameterUtils.java:171) at org.nrg.pipeline.utils.PipelineEngineUtils.resolveXPath(PipelineEngineUtils.java:87) at org.nrg.pipeline.manager.PipelineManager.launchPipeline(PipelineManager.java:210) at org.nrg.pipeline.manager.PipelineManager.launchPipeline(PipelineManager.java:193) at org.nrg.pipeline.client.XNATPipelineLauncher.launch(XNATPipelineLauncher.java:63) at org.nrg.pipeline.client.XNATPipelineLauncher.run(XNATPipelineLauncher.java:298) at org.nrg.pipeline.client.XNATPipelineLauncher.main(XNATPipelineLauncher.java:260)

[Herrick, Rick]

A message like that usually means that the REST call that’s generating it is getting an error message of some sort. The pipeline code is trying to process it as XML, but since it’s just a message of some sort the parsing fails.

 

Does the AutoRun.xml work for other users and/or in other contexts, i.e. are snapshots generated for data uploaded through other means?

 

-- 

Rick Herrick

Sr. Programmer/Analyst

Neuroinformatics Research Group

Washington University School of Medicine

Phone: +1 (314) 273-1645

--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/45c6b157-27ce-4daa-b41d-4db2a7c3139f%40googlegroups.com.

 

---

The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

[Lorena Escudero]

Hi Rick,

Is it possible that the XML process that is failing is the one that creates the snapshots you can view from the session page when you click on the link of the scans (that also gives you access to view DICOM headers? Because it's what I am seeing in common between the first 8 subjects that the user has uploaded, that it says "No snapshot available", instead the rest of the uploads afterwards seem to not to be triggering any error and I can see the snapshots. Everything else looks correct for the first subjects as far as I can see. I downloaded the scans for one of those early subjects, created a .zip myself with the DICOM files downloaded, and uploaded it to a private test project of mine, and it does trigger that error message again, which I haven't seen in my private project before. I dont see anything strange in the DICOM files though (opening with DicomBrowser or Osirix) but I dont really know what to look for. 

Thanks!

Lorena 

On Thursday, April 9, 2020 at 4:28:43 PM UTC+1, Herrick, Rick wrote:

A message like that usually means that the REST call that’s generating it is getting an error message of some sort. The pipeline code is trying to process it as XML, but since it’s just a message of some sort the parsing fails.

 

Does the AutoRun.xml work for other users and/or in other contexts, i.e. are snapshots generated for data uploaded through other means?

 

-- 

Rick Herrick

Sr. Programmer/Analyst

Neuroinformatics Research Group

Washington University School of Medicine

Phone: +1 (314) 273-1645

 

From: "xnat_di...@googlegroups.com" <xnat_di...@googlegroups.com> on behalf of Lorena Escudero <loren...@gmail.com>
Reply-To: "xnat_di...@googlegroups.com" <xnat_di...@googlegroups.com>
Date: Thursday, April 9, 2020 at 9:14 AM
To: "xnat_di...@googlegroups.com" <xnat_di...@googlegroups.com>
Subject: [XNAT Discussion] AutoRun.xml error

 

Hello,

I am receiving emails with the log below with what looks like an xml parsing error every time a user is uploading images. I believe the user is using the Compressed Uploader method and this is being uploading one patient at a time. Any ideas how and where this is happening, and if this is something to be worried about? I can see the scans archived and I can open them with the viewer, so I haven't encountered any problems so far... 

Thanks,

Lorena 

Pipeline:  

/data/xnat/pipeline/catalog/xnat_tools/AutoRun.xml


Cause:  

org.nrg.pipeline.exception.PipelineEngineException: fileUtils:GetCachePath(/Pipeline/parameters/parameter[name='resolvedHost']/values/unique/text(), /Pipeline/parameters/parameter[name='user']/values/unique/text(), /Pipeline/parameters/parameter[name='pwd']/values/unique/text(),/Pipeline/parameters/parameter[name='project']/values/unique/text()) Encountered class net.sf.saxon.trans.XPathException==>org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 39; Content is not allowed in prolog. org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 39; Content is not allowed in prolog. at org.nrg.pipeline.xpath.XPathResolverSaxon.resolveXPathExpressions(XPathResolverSaxon.java:269) at org.nrg.pipeline.xpath.XPathResolverSaxon.resolveXPathExpressions(XPathResolverSaxon.java:153) at org.nrg.pipeline.xpath.XPathResolverSaxon.resolveXPathExpressions(XPathResolverSaxon.java:279) at org.nrg.pipeline.xpath.XPathResolverSaxon.evaluate(XPathResolverSaxon.java:87) at org.nrg.pipeline.utils.ParameterUtils.resolveParameterValues(ParameterUtils.java:183) at org.nrg.pipeline.utils.ParameterUtils.setParameterValues(ParameterUtils.java:171) at org.nrg.pipeline.utils.PipelineEngineUtils.resolveXPath(PipelineEngineUtils.java:87) at org.nrg.pipeline.manager.PipelineManager.launchPipeline(PipelineManager.java:210) at org.nrg.pipeline.manager.PipelineManager.launchPipeline(PipelineManager.java:193) at org.nrg.pipeline.client.XNATPipelineLauncher.launch(XNATPipelineLauncher.java:63) at org.nrg.pipeline.client.XNATPipelineLauncher.run(XNATPipelineLauncher.java:298) at org.nrg.pipeline.client.XNATPipelineLauncher.main(XNATPipelineLauncher.java:260)

--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to xnat_di...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/45c6b157-27ce-4daa-b41d-4db2a7c3139f%40googlegroups.com.

[Herrick, Rick]

Yes, that’s exactly what’s failing. The default AutoRun pipeline includes generating snapshots for new sessions and running any other pipelines that are configured to auto-run for the that session’s project. The error you’re seeing comes when the pipeline calls back to XNAT via REST and is expecting an XML document to be returned (maybe the XML for the new session or maybe for a workflow), but is getting an error of some sort back instead.

 

Two things to try:

 

• Look in the cache folder for the project containing the sessions where the pipeline is failing. This will be somewhere like /data/xnat/cache/<PROJECT>/<SESSION> (/data/xnat/cache would be whatever’s configured for your XNAT deployment). There should be some files in there that may have useful information.
• You can also look in the logs folder for your pipeline installation. To find the relevant log(s), try searching for the session ID or label.

 

It’s weird that this is only happening for these particular sessions. This is the sort of thing that tends to work or not work.

To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/2f9aa1d8-cda0-491a-849a-98eb827a2493%40googlegroups.com.

[Lorena Escudero]

Hi Rick,

Thanks a lot for the explanations! Glad the source of the error is clear now :) 

I looked into /data/xnat/cache/<PROJECT>/ and I can see .log and .err files exist inside /data/xnat/cache/<PROJECT>/<SESSION> but those directories only exist for the ones in which it didn't fail, there aren't directories for the earlier sessions. There is a /data/xnat/cache/<PROJECT>/merge/ with one directory for each of all the sessions, but they are empty. 

The log in /data/xnat/pipeline/logs for the time corresponding to one of the failing ones doesnt give us more information unfortunately, as it looks like exactly the same text I received by email and pasted in the first post. 

Shrug. 

Thanks again,

Lorena  

To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/2f9aa1d8-cda0-491a-849a-98eb827a2493%40googlegroups.com.

[Herrick, Rick]

Another option is to look in the XNAT log file pipeline.log. The lines in there will be something like:

 

2020-04-09 12:00:53,332 [xxx] ERROR someClassName – Couldnt launch pipeline something: /data/xnat/pipeline/bin/XnatPipelineLauncher <a bunch of stuff>

 

If you take that line starting with <pipeline path>/bin/XnatPipelineLauncher up to the end of the line, you can run that from the command line on the server. Either put it in a file and run that as a script or just paste the entire command into a shell and run it that way. That may give you more information on what exactly is failing.

To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/74cf2ab5-417d-4c09-8c4f-578256723b1f%40googlegroups.com.

[Lorena Escudero]

Hi Rick,

That's a very useful tip, thanks!

I did run that command on the command line, and it ends with something like this: 

INFO: Starting the HTTP client

Apr 09, 2020 6:21:09 PM com.noelios.restlet.http.HttpClientCall getResponseEntity

INFO: The length of the message body is unknown. The entity must be handled carefully and consumed entirely in order to surely release the connection.

Cachepath /data/xnat/cache/PROJECT/

Error on line 1 column 39 

  SXXP0003: Error reported by XML parser: Content is not allowed in prolog.

Is this possibly related to a connection problem? I see a 

Session Timeout () 

after 

Logging to File /data/xnat/pipeline/logs/pipeline_2020_04_09_18_21_07.log

Thanks!

Lorena 

To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/74cf2ab5-417d-4c09-8c4f-578256723b1f%40googlegroups.com.

[Martin Boswell]

Lorena,

Were you able to resolve your issue with these uploads?  I'm encountering the same AutoRun pipeline errors ("org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 39; Content is not allowed in prolog.") when I upload certain image files via curl.  And I also get the same kind of output when running the full XnatPipelineLauncher command on the command line (as Rick suggested).  

I'd really appreciate hearing about any progress that you made to track down and solve these errors.  

Thanks,

- Martin

[Lorena Escudero]

Hi Martin, 

No, no more progress after my last reply I am afraid. Seems I got to a dead end. It also seems that the rest of scans uploaded to that project by the same user worked fine, I havent got that error again... 

Best,

Lorena 

[lambert...@gmail.com]

Martin,

I think I have exactly the same issue that you described one year ago.

Did you manage to understand the issue and maybe how to deal with ?

Thank you in advance

Franck

[Martin Boswell]

Franck,

I'm afraid that I don't have an easy answer for you.  As Rick has stated further up in this thread, these messages are generated when a REST call generates an error.  I've found myself faced with these errors at quite a few different times and the source of the problems were very different each time.  

The specific incident that caused me to write the message above was very frustrating, and I never did resolve it exactly, but rather, worked around it.  I eventually discovered that a certain XNAT admin user could not perform specific tasks without generating this error, while a different admin user (configured exactly the same according to the XNAT GUI) does not have problems with the same tasks.  

In another case where I was getting the "content not allowed in prolog" error when trying to launch a Freesurfer pipeline via the REST API turned out to be a very simple, accidental change to a <name> tag in the Freesurfer.xml file.  There was nothing in the error that pointed to this, but when I compared the failing pipeline to a recent working version, the accidental change jumped right out at me.  

Anyway, my point here is that these errors can be the result of a problem from a seemingly unconnected source (from my perspective).  I generally check the access.log (and others) to see exactly what calls are generating the failures and then trace backward from there.  I've frequently found these problems while launching pipelines from the REST API, so I try the same thing from the  XNAT GUI and see if I can do it successfully from there or maybe as a different user (perhaps with different permissions) and eventually closely compare the working with the non-working items.  

Good luck.

 - Martin

[Baris Kanber]

Hi all,

I recently bumped into the same problem, while launching a pipeline from the command line via the REST API.

The XNAT user making the REST call had first name: XNAT, last name: Data Importer. Changing it to a "standard" name (e.g. no caps, single surname) seemed to solve the problem.

Kind regards,

Baris.