DQR plugin - not able to import

322 views
Skip to first unread message

elijah....@gmail.com

unread,
Jun 25, 2021, 11:14:13 AM6/25/21
to xnat_discussion
Hello,

The DQR plugin does configure a DicomObjectIdentifier, which I can see under the DQR settings, with DQR-Enabled = True.

I set the SCP receiver to use this, but when I navigate to the "Import from PACS" page, there is a notification error that tells me "There's no available SCP receiver that is configured to allow DQR imports from a PACS system"

Although as far as I can tell.... I DO have this configured (see screenshot)



Thanks,
-Eli
dqr.PNG

Moore, Charlie

unread,
Jun 25, 2021, 11:23:29 AM6/25/21
to xnat_di...@googlegroups.com
Hi Eli,

Do you also have the "Custom Processing" flag turned on for your SCP receiver? That's an additional requirement for the DQR plugin.

Thanks,
Charlie
From: xnat_di...@googlegroups.com <xnat_di...@googlegroups.com> on behalf of elijah....@gmail.com <elijah....@gmail.com>
Sent: Friday, June 25, 2021 10:14 AM
To: xnat_discussion <xnat_di...@googlegroups.com>
Subject: [XNAT Discussion] DQR plugin - not able to import
 

* External Email - Caution *
--
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/62241a49-c8f3-4354-9c4d-5599c4f1826fn%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.

elijah....@gmail.com

unread,
Jun 25, 2021, 11:41:59 AM6/25/21
to xnat_discussion
Thanks Charlie, that did it.

elijah....@gmail.com

unread,
Jun 30, 2021, 3:04:33 PM6/30/21
to xnat_discussion
For some reason I'm unable to receive the query response from the PACS system. On the PACS side (using dcmtk, and looking at debug level logs), I can watch pings and the query request come in from XNAT, and PACS outputs the results successfully, but on the XNAT side the webapp just says no results were found.

Strangely, I am able to send images from XNAT to the PACS and see them stored in PACS. So it seems like some commands are working correctly, but the Query results C-FIND RSP messages don't seem to be going through to XNAT, and I'm not yet sure where the best place is to look to identify what might be the hang up.

Any guidance would be appreciated!
-Eli

Moore, Charlie

unread,
Jun 30, 2021, 3:36:13 PM6/30/21
to xnat_di...@googlegroups.com
Hi Eli,

The best thing I can think of to diagnose this is to try and mimic XNAT as closely as possible using dcmtk and see if it still fails. I'm a little unsure on some things in your first paragraph, so my apologies if this is already what you're doing, but this is what I would try. Make a study-level CFIND using dcmtk where...
  1. Run it from​ your XNAT server, not your PACS, so it should have the same IP/etc as the request from XNAT.
  2. Set the calling AE title of the CFIND to whatever you told XNAT to use (available under Administer > Plugin Settings).
If this all still works, you could also look at:
  1. The XNAT logs. Are there anything in XNAT's logs when you try the CFIND?
  2. The browser console. If you open your browser's dev tools, you should find a failing request for the CFIND. Does it say anything useful?
Thanks,
Charlie
Sent: Wednesday, June 30, 2021 2:04 PM
To: xnat_discussion <xnat_di...@googlegroups.com>
Subject: Re: [XNAT Discussion] DQR plugin - not able to import
 

elijah....@gmail.com

unread,
Jul 1, 2021, 3:00:15 PM7/1/21
to xnat_discussion
Quick update,

So I was able to run dcmtk's "findscu" from the XNAT dev server and get results back. I haven't found anything in XNAT's logs yet. However there was a message in the browser console..

From the browser's perspective, a POST command fails. I presume this is the POST command that sends the results over the the page to be rendered... But that could just be failing because the results aren't included in the POST command .... which doesn't necessarily tell me WHY they were not included. So I'm not sure how helpful that is, but I've been trying to work through some of these js files and try to get an idea of exactly where the failure might be happening.

hopefully this may spark some recognition on this group..
dqr-error2.PNG
dqr-error.PNG

Moore, Charlie

unread,
Jul 1, 2021, 3:16:20 PM7/1/21
to xnat_di...@googlegroups.com
Hi Eli,

Thanks, this is very helpful. "Failed to load the ORM strategy defined by bean 'string'" is what looks like the smoking gun to me. The failing POST is from XNAT failing to do the C-FIND at all, but it looks like XNAT is failing before even attempting to make the C-FIND. To confirm what I suspect is the issue...try retrieving the list of PACS connections. You can either do this with a REST client of your fancy, or just go to $YOUR_XNAT_URL/xapi/pacs in your browser. You should get back a list of the PACS that XNAT knows about, like this:
  [{
    "label": "ORTHANC",
    "host": "10.100.100.1",
    "aeTitle": "ORTHANC",
    "storable": true,
    "queryable": true,
    "ormStrategySpringBeanId": "dicomOrmStrategy",
    "defaultStoragePacs": false,
    "defaultQueryRetrievePacs": false,
    "queryRetrievePort": 4242,
    "supportsExtendedNegotiations": false,
    "timestamp": 1624549844203,
    "enabled": true,
    "created": 1624373598996,
    "id": 1,
    "disabled": 0
  }]

If my suspicion is correct, the field I highlighted above is going to have the value "string" instead of "dicomOrmStrategy". If you set up your PACS connection via the XNAT UI, I have no idea how this would have happened as that property gets set by default and isn't actually modifiable. If you set up the PACS connection via REST, that would make sense how this happened. Either way, if you're comfortable with REST (or Swagger), you could try updating the particular PACS connection and set that field to the proper value, or you could [maybe] delete the PACS connection and re-add it. I say "maybe" because in recent code for this plugin, the "delete" function for a PACS has actually been removed as a temporary solution for the big problem of data audit/provenance/history if the PACS connection gets removed.

This is a bit of an info dump, so sorry if parts of it don't make sense. Please ask for clarification on any part if you need it.

Thanks,
Charlie
Sent: Thursday, July 1, 2021 2:00 PM

elijah....@gmail.com

unread,
Jul 1, 2021, 4:13:28 PM7/1/21
to xnat_discussion
What you say makes perfect sense. So, I hope you don't mind an info dump of my own:

Some background: 

We never used our own fancy REST calls to modify anything on XNAT, so configuring the DQR plugin and SCP receivers was all entirely done through the administration plugin settings pages. Any queries, C-STORE etc have all been issued by way of the XNAT web application interface.... no cheating ;)

When we first set up the DQR plugin: On the PACS (dcmtk) side, we were able to watch the C-FIND commands incoming from XNAT, and watch the PACS fulfill the request, and send back the C-FIND response to XNAT. But on the XNAT side, we got no results. As you suggested, I tried with dcmtk's "findscu" command, to catch if maybe there was some hidden network issue at play (our institution has several layers of network traffic monitoring, so that's always a source of .... joy)

We have now created a couple of PACS instances in hopes of troubleshooting things on the PACS side, but we are pretty confident the issue is on the XNAT side. So, what you see in the xapi/pacs output (attached) is those three PACS instances (COMMON and COMMON2 are the only active ones at the moment)

Oddly, I do see what you mention (ormStrategy values) in the case of "COMMON".... however I notice that "COMMON2" has the apparent correct value there... So lets ignore "COMMON" and just focus on "COMMON2" for now .... so I just tried running the query using that PACS system, and I stumbled onto kind of a different situation.

When I try to query a subject (see browser console screenshot) that I know is not in PACS (patient ID: not_in_PACS) there is no error in the browser console whatsoever (only deprecation warnings as usual), but the results page still says "no results found". As expected! And no errors!

However, when I try to query a subject I know IS in PACS (patient ID: 1040), THAT'S when we get the POST error. (See other attached)

So that makes me suspect there's something happening after (or just as) the results have reached XNAT, but before it renders them to the page. Maybe the results are not being injected into the POST command properly, or are somehow malformed?
xapi-pacs.PNG
dqr-error-new.PNG

Moore, Charlie

unread,
Jul 1, 2021, 4:40:54 PM7/1/21
to xnat_di...@googlegroups.com
Hi Eli,

Ah, I see. I think you're probably spot on, then. How/where/when did you get the DQR jar that you're using? We haven't actually released it yet (although we hope to very soon). The section of our JIRA [issue tracker] that houses the DQR issues is unfortunately not public, so I can't point you at the relevant ticket, but I had actually filed a ticket to improve the error messages presented to the end user. The reason I bring that up is that Rick fixed the messaging, but also this: "the NullPointerException noted in the description here was due to a screw-up in parsing timestamps without dates. That's been fixed". My original issue had the same generic NPE in the failing REST call. So, my suggestion would be:
  1. Double check when you installed the plugin, and from where, etc. Rick made this fix on June 16th, so if you installed the plugin before then, you'll have that issue.
  2. Double check the data you're trying to retrieve. Is it maybe missing (0008,0020) Study Date? That would be pretty good evidence you're running into the same issue.
  3. When I said "very soon", we have actually already built what is intended to be the first "official" release build of the DQR plugin. It's still not quite released because we don't have publication-type tasks to finish, but you can get a sneak peek here: https://ci.xnat.org/job/Plugins_Release/job/DICOM_Query_Retrieve/lastSuccessfulBuild/artifact/build/libs/dicom-query-retrieve-1.0.0-xpl.jar .
You could try swapping out the previous jar for this new one. Hopefully it fixes the issue entirely and returns the result, but even a clearer error message would be better than nothing 🙂.

Thanks,
Charlie


Sent: Thursday, July 1, 2021 3:13 PM

elijah....@gmail.com

unread,
Jul 2, 2021, 9:19:01 AM7/2/21
to xnat_discussion
Unfortunately, I checked the study dates, they seem OK. We also tried the latest version of the plugin you linked, and that didn't change the NPE message (we had a very recent version of the .jar anyway, I think, so not entirely surprised)

I do find it odd that it works (i assume) on your dev systems, but fails with the same error on both our dev VM, and also a docker-compose instance I have. Wonder if it could be related to a version requirement for Java/Postgres or something ... there are numerous deprecation warnings in the browser console ... although I understand that's not necessarily an indicator of something wrong

elijah....@gmail.com

unread,
Jul 2, 2021, 3:48:36 PM7/2/21
to xnat_discussion
"debug jar" now shows the query arguments from XNAT in the error message, and dqr.log does seem to imply that the data is getting through to XNAT, so doesn't seem to be a network or port forwarding issue. We are wondering if our institution's HTTP content policy could be interfering ... but also that if it were, we would see a message in the browser dev tools saying something was blocked (which we don't)

See attached for dqr.log, and a new message from browser console.

Just want to say big thanks for all the help. If you see Richie on this thread, he is the technical lead for us (I'm on PTO next week, and he is following this thread)
dqr.log
dqr-debug.PNG

Moore, Charlie

unread,
Jul 2, 2021, 4:24:13 PM7/2/21
to xnat_discussion
Hi Eli,

I'm not super familiar with the code for the DQR plugin, but I think I see a major problem in there. See how the C-FIND XNAT is issuing is requesting (0008,0061) Modalities In Study? The response from your PACS isn't including it in the response. I took a look at the standard, and I see it defined for the STUDY-CFIND here: http://dicom.nema.org/medical/dicom/current/output/chtml/part04/sect_C.3.4.html . Assuming that "optional" in this context means "optional for a PACS to support", I would conclude your PACS is not misbehaving, it's just not supporting a field the DQR plugin relies on, and a lot of other PACS do support. I'd have to wait for Rick to have more certainty that is indeed the issue, and not just a red herring, but I'm medium-high on confidence for it.

Thanks,
Charlie

Sent: Friday, July 2, 2021 2:48 PM

Herrick, Rick

unread,
Jul 2, 2021, 5:20:52 PM7/2/21
to xnat_di...@googlegroups.com

Eli,

 

Is there anything in any of the XNAT logs that mention NullPointerException?

 

-- 

Rick Herrick

XNAT Architect/Developer

Computational Imaging Laboratory

Washington University School of Medicine

elijah....@gmail.com

unread,
Jul 2, 2021, 6:20:50 PM7/2/21
to xnat_discussion
If our dcmtk "PACS" is not supporting a necessary field in the response .... that could definitely be the issue. We're definitely going to check on that.

Rick, I grepped the logs directory, found a match related to a query (echo?) in the xapi logs. Not sure if it really helps, because we don't seem to have a problem with ECHO... from XNAT, we can ping the dcmtk PACS no problem.

[root@tmhri-dev-eli logs]# vi xapi.log.2021-07-01
2021-07-01 20:58:19,286 [http-apr-8080-exec-4] ERROR org.nrg.xapi.rest.XapiRestControllerAdvice - HTTP status 500: Request by user admin to URL /xapi/pacs/1/status caused an internal server error
java.lang.NullPointerException: null
        at org.dcm4che2.tool.dcmecho.DcmEcho.close(DcmEcho.java:664)
        at org.nrg.xnatx.dqr.dicom.command.cecho.dcm4che.tool.Dcm4cheToolCEchoSCU.canConnect(Dcm4cheToolCEchoSCU.java:74)
        at org.nrg.xnatx.dqr.services.impl.basic.BasicDicomQueryRetrieveService.canConnect(BasicDicomQueryRetrieveService.java:111)
        at org.nrg.xnatx.dqr.rest.DqrPacsApi.pingPacs(DqrPacsApi.java:126)
        at org.nrg.xnatx.dqr.rest.DqrPacsApi$$FastClassBySpringCGLIB$$d4d9c9f1.invoke(<generated>)
        at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
        at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:737)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
        at org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:84)
        at org.nrg.xapi.rest.aspects.XapiRequestMappingAspect.processXapiRequest(XapiRequestMappingAspect.java:86)
        at sun.reflect.GeneratedMethodAccessor274.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:498)

elijah....@gmail.com

unread,
Jul 2, 2021, 6:24:04 PM7/2/21
to xnat_discussion
I should just clarify and point out that NPE was from yesterday, nothing from today (and I've been trying), so not sure how relevant it is

Herrick, Rick

unread,
Jul 2, 2021, 6:40:09 PM7/2/21
to xnat_di...@googlegroups.com

That’s actually some issue in dcm4che. Occasionally when it closes the connection to a PACS it throws an NPE for some reason. We catch those and just ignore them in other places, but I’ll wrap this particular instance up as well.

Richard Cole

unread,
Jul 7, 2021, 12:23:11 PM7/7/21
to xnat_di...@googlegroups.com
Just to give an update.  To eliminate any possible issues with the "Test PACS" we previously setup for testing, I created a fresh VM with dcm4chee basic setup and the result was a successful query of the PACS and I was able to get results. 

image.png


  I did walk through re-labeling and retrieving, which failed, but we will put that as the next thing to look into.  Probably something easy.. will let you know, but I don't currently have time to further troubleshoot..      

Thanks for all the assistance ..  

 



To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/6143331a-2f0c-4015-8aff-5f2c66b47178n%40googlegroups.com.

Moore, Charlie

unread,
Jul 8, 2021, 10:51:04 AM7/8/21
to xnat_di...@googlegroups.com
Could you try your previous PACS with a new build of the plugin here: https://ci.xnat.org/job/Plugins_Develop/job/DICOM_Query_Retrieve/lastSuccessfulBuild/artifact/build/libs/dicom-query-retrieve-1.0.1-SNAPSHOT-xpl.jar ? I believe we've fixed the issue of the search failing when the PACS doesn't support Modalities In Study.

Thanks,
Charlie
From: xnat_di...@googlegroups.com <xnat_di...@googlegroups.com> on behalf of Richard Cole <richie...@gmail.com>
Sent: Wednesday, July 7, 2021 11:22 AM
To: xnat_di...@googlegroups.com <xnat_di...@googlegroups.com>

Richard Cole

unread,
Jul 9, 2021, 12:32:02 PM7/9/21
to xnat_di...@googlegroups.com
Yes, the newly provided .jar worked with both of our test PACS Servers.. 

image.png

To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/CH2PR02MB6710E6FE23381CBA0E7AB133FE199%40CH2PR02MB6710.namprd02.prod.outlook.com.

elijah....@gmail.com

unread,
Jul 13, 2021, 5:17:41 PM7/13/21
to xnat_discussion
So the query works now, but the import does not.

It sits in the queue for a minute or two, and then query history shows a failure, though the image appears to have been sent successfully from the dcmtk and/or dcm4che PACS.

One clue might be that we get an error message when trying to send a DICOM image to the DQR receiver from the "Dicom Browser" tool, which makes us think there might be something about the "dqrObjectIdentifier" class that is rejecting the images (see attached error message). But we can send images to the standard receiver with no problem.

-Eli
xnat2.PNG
xnat.PNG

Herrick, Rick

unread,
Jul 13, 2021, 7:46:13 PM7/13/21
to xnat_di...@googlegroups.com

Sending data to a receiver using dqrObjectIdentifier would have issues:

 

  • dqrObjectIdentifier uses the RoutedStudyDicomProjectIdentifier class as its project identifier, which sets the project based on the study instance UID. That said, the data should still be captured, but end up with the project set to “Unassigned”.
  • It also uses an extractor for the session label that uses the study ID and study instance UID to look up any cached mappings for the subject and session labels. If there are no mappings for the study, it uses the study ID as the session label.

 

I was able to send a basic DICOM image to a receiver configured with dqrObjectIdentifier just using dcmsend (i.e. the study instance UID wasn’t configured for the RoutedStudyDicomProjectIdentifier, nothing in there for the study ID or study instance UID, etc.) and it worked without issue. I did the same with DicomBrowser with the same results.

 

Could you possibly share a sample of your data? Anonymized of course, but if you can share that, please verify that the scrubbed data still has the same failure when sent to your DQR receiver. Just a single frame would be sufficient, I think.

 

-- 

Rick Herrick

XNAT Architect/Developer

Computational Imaging Laboratory

Washington University School of Medicine

 

 

From: xnat_di...@googlegroups.com <xnat_di...@googlegroups.com> on behalf of elijah....@gmail.com <elijah....@gmail.com>
Date: Tuesday, July 13, 2021 at 4:17 PM
To: xnat_discussion <xnat_di...@googlegroups.com>
Subject: Re: [XNAT Discussion] DQR plugin - not able to import

* External Email - Caution *

So the query works now, but the import does not.

 

It sits in the queue for a minute or two, and then query history shows a failure, though the image appears to have been sent successfully from the dcmtk and/or dcm4che PACS.

 

One clue might be that we get an error message when trying to send a DICOM image to the DQR receiver from the "Dicom Browser" tool, which makes us think there might be something about the "dqrObjectIdentifier" class that is rejecting the images (see attached error message). But we can send images to the standard receiver with no problem.

 

-Eli

 

On Friday, July 9, 2021 at 11:32:02 AM UTC-5 richie...@gmail.com wrote:

Yes, the newly provided .jar worked with both of our test PACS Servers.. 

 

 

On Thu, Jul 8, 2021 at 9:51 AM Moore, Charlie <moo...@wustl.edu> wrote:

Could you try your previous PACS with a new build of the plugin here: https://ci.xnat.org/job/Plugins_Develop/job/DICOM_Query_Retrieve/lastSuccessfulBuild/artifact/build/libs/dicom-query-retrieve-1.0.1-SNAPSHOT-xpl.jar ? I believe we've fixed the issue of the search failing when the PACS doesn't support Modalities In Study.

 

Thanks,

Charlie

From: xnat_di...@googlegroups.com <xnat_di...@googlegroups.com> on behalf of Richard Cole <richie...@gmail.com>
Sent: Wednesday, July 7, 2021 11:22 AM
To: xnat_di...@googlegroups.com <xnat_di...@googlegroups.com>
Subject: Re: [XNAT Discussion] DQR plugin - not able to import

 

* External Email - Caution *

Just to give an update.  To eliminate any possible issues with the "Test PACS" we previously setup for testing, I created a fresh VM with dcm4chee basic setup and the result was a successful query of the PACS and I was able to get results. 

 

Moore, Charlie

unread,
Jul 14, 2021, 10:14:50 AM7/14/21
to xnat_di...@googlegroups.com
Hi Eli,

When you do that, is there anything in the logs? Usually errors like that log something interesting in dicom.log.

Thanks,
Charlie
From: xnat_di...@googlegroups.com <xnat_di...@googlegroups.com> on behalf of Herrick, Rick <jrhe...@wustl.edu>
Sent: Tuesday, July 13, 2021 6:46 PM

Moore, Charlie

unread,
Jul 14, 2021, 11:20:31 AM7/14/21
to xnat_di...@googlegroups.com
Also, do you have site-level anonymization on? Are you able to share the script if so?
From: xnat_di...@googlegroups.com <xnat_di...@googlegroups.com> on behalf of Moore, Charlie <moo...@wustl.edu>
Sent: Wednesday, July 14, 2021 9:14 AM

elijah....@gmail.com

unread,
Jul 14, 2021, 3:06:33 PM7/14/21
to xnat_discussion
For Rick, I attached an anonymized DICOM that I have been using to test the DQR etc. Also, one thing I should note is that the easiest way for us to get the images into PACS is actually to send them over from XNAT. So when importing, we are dealing with images that are already in XNAT, therefore have a study instance ID, etc, and are "scrubbed". I also just downloaded this image from the PACS directly, and tried sending via Dicom Browser.

For Charlie, I have found that the dicom.log only gets used when I try a DQR import. Sending from Dicom Browser doesn't seem to create any log, that I see. So I am also attaching a log which corresponds to an attempt to import from PACS... pretty much seems to echo the same error message generated by Dicom Browser.
dicom_import.log
1040_dicom.zip

Moore, Charlie

unread,
Jul 14, 2021, 3:23:07 PM7/14/21
to xnat_di...@googlegroups.com
Hi Eli,

Aha, I see the issue:  
Caused by: org.nrg.action.ServerException: java.lang.ClassNotFoundException: org.nrg.dqr.processors.UpdateRequestStatusArchiveProcessor

That class was moved in this commit:

I think you may have a "processor" instanced cached from an old version of the plugin. Try the GET to /xapi/processors/site/list as defined here (https://wiki.xnat.org/display/XAPI/Archive+Processor+API). You can just do it in your browser if you wish. Can you post the results for that?

Thanks,
Charlie
Sent: Wednesday, July 14, 2021 2:06 PM
To: xnat_discussion <xnat_di...@googlegroups.com>
Subject: [WARNING: UNSCANNABLE EXTRACTION FAILED]Re: [XNAT Discussion] DQR plugin - not able to import
 

elijah....@gmail.com

unread,
Jul 14, 2021, 3:45:13 PM7/14/21
to xnat_discussion
Hey Charlie, below is the xapi output. So maybe spinning up a new XNAT instance wouldn't have the issue, since we wouldn't have old plugin versions chached? Or maybe redeploying a fresh instance, given this is all being done in a dev environment?

[{"label":"Site Anonymization","scope":"site","scpWhitelist":[],"scpBlacklist":[],"location":"AfterAddedToPrearchiveDatabase","priority":10,"parameters":{},"processorClass":"org.nrg.xnat.processors.MizerArchiveProcessor","projectIdsList":[],"timestamp":1622157257865,"enabled":true,"created":1622157257865,"id":2,"disabled":0},{"label":"Update Request","scope":"site","scpWhitelist":[],"scpBlacklist":[],"location":"AfterDicomRead","priority":10,"parameters":{},"processorClass":"org.nrg.xnatx.dqr.processors.UpdateRequestStatusArchiveProcessor","projectIdsList":[],"timestamp":1624631252949,"enabled":true,"created":1624631252949,"id":4,"disabled":0},{"label":"Update Request","scope":"site","scpWhitelist":[],"scpBlacklist":[],"location":"AfterDicomRead","priority":10,"parameters":{},"processorClass":"org.nrg.dqr.processors.UpdateRequestStatusArchiveProcessor","projectIdsList":[],"timestamp":1622157255467,"enabled":true,"created":1622157255467,"id":1,"disabled":0},{"label":"Remapping","scope":"site","scpWhitelist":[],"scpBlacklist":[],"location":"AfterProjectSet","priority":10,"parameters":{},"processorClass":"org.nrg.xnat.processors.StudyRemappingArchiveProcessor","projectIdsList":[],"timestamp":1622157257870,"enabled":true,"created":1622157257870,"id":3,"disabled":0}]

Moore, Charlie

unread,
Jul 14, 2021, 3:56:18 PM7/14/21
to xnat_discussion
Hi Eli,

That would solve this issue at least (it's possible there's another one lurking), but I don't think it should be necessary. It looks like you have a processor instance for both the new class and the old class. If you're comfortable with REST, try a DELETE to $SERVER/processors/site/id/1 to delete the old one. If you're not comfortable with REST, try this:
  1. Go to $SERVER/xapi/swagger-ui.html#/ . This is the "Swagger" page which gives you a basic GUI for issuing some REST calls.
  2. Find the "archive-processor-instance-api" entry. Expand that.
  3. Find the "DELETE" to 
    /processors/site/id/{instanceId} and "Try It Out" with instanceId = 1.
Thanks,
Charlie
Sent: Wednesday, July 14, 2021 2:45 PM

Herrick, Rick

unread,
Jul 14, 2021, 4:02:23 PM7/14/21
to xnat_di...@googlegroups.com

Yes, either one of those should work. You could also run this query:

 

DELETE FROM xhbm_archive_processor_instance WHERE id = 1;

 

You’ll need to restart to clear the Hibernate cache, but that should clear out the entry with the invalid class reference.

Herrick, Rick

unread,
Jul 14, 2021, 4:03:37 PM7/14/21
to xnat_di...@googlegroups.com

This ends up doing the same thing as the query I sent at the same time, but doesn’t require a restart. I’m interested to hear if it works properly 😊

elijah....@gmail.com

unread,
Jul 14, 2021, 4:12:29 PM7/14/21
to xnat_discussion
The xapi/swagger delete seems to have fixed the issue... the image is currently receiving in the prearchive. Thanks to you both!
Reply all
Reply to author
Forward
0 new messages