AutoRun pipeline fails with error "SessionManager not inited. Please init the session manager first"

[Torsten Rohlfing]

After upgrade to 1.6.3, our AutoRun pipeline fails with the following error trace:

SessionManager not inited. Please init the session manager first
org.nrg.xnattools.exception.SessionManagerNotInitedException
        at org.nrg.xnattools.SessionManager.createJSESSION(SessionManager.java:92)
        at org.nrg.xnattools.SessionManager.getJSESSION(SessionManager.java:136)
        at org.nrg.xnattools.service.WebServiceClient.connect(WebServiceClient.java:88)
        at org.nrg.pipeline.client.XNATPipelineLauncher.isPipelineQueuedOrAwaitingOrOnHold(XNATPipelineLauncher.java:360)
        at org.nrg.pipeline.client.XNATPipelineLauncher.isPipelineQueuedOrAwaitingOrOnHold(XNATPipelineLauncher.java:344)
        at org.nrg.pipeline.client.XNATPipelineLauncher.launch(XNATPipelineLauncher.java:68)
        at org.nrg.pipeline.client.XNATPipelineLauncher.run(XNATPipelineLauncher.java:290)
        at org.nrg.pipeline.client.XNATPipelineLauncher.main(XNATPipelineLauncher.java:254)

[Trace continues with additional "not inited" messages; happy to post more]

What might I do to fix this?

Thanks!

Torsten

[Herrick, Rick]

Hey Torsten,

 

This was a problem that cropped up in some cases that quite honestly I never was able to figure out what was going wrong specifically. Most of the time it worked fine but in certain cases would never work. The code that actually gets the JSESSIONID in there was fairly old and used an older Web services framework, so it’s most likely that the creeping tendrils of modernity are just slowly strangling that functionality.

 

The fix I put in was to update the code so that it calls one of the REST functions back on XNAT using the HTTP components client library. This is available on the XNAT FTP site as a separate download:

 

ftp://ftp.nrg.wustl.edu/pub/xnat/pipeline-1.6.3.zip (MD5)

ftp://ftp.nrg.wustl.edu/pub/xnat/pipeline-1.6.3.tar.gz (MD5)

 

You can extract this over your current pipeline engine (please back it up beforehand!!) and run setup.sh. That should update the jar files and scripts and this should then work.

Let me know how it turns out.

 

Rick Herrick

Sr. Programmer/Analyst

Neuroinformatics Research Group

Washington University School of Medicine

(314) 827-4250

--
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 post to this group, send email to xnat_di...@googlegroups.com.
Visit this group at http://groups.google.com/group/xnat_discussion.
For more options, visit https://groups.google.com/d/optout.

---

The material in this message is private and may contain Protected Healthcare Information (PHI). 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.

[Torsten Rohlfing]

Thanks Rick - unfortunately, it's not working still.

Except, I get a different error when I run the pipeline as-is (or rather, now, as you sent it):

javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
        at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:397)
        at org.apache.http.conn.ssl.AbstractVerifier.verify(AbstractVerifier.java:126)
        at org.apache.http.conn.ssl.SSLSocketFactory.connectSocket(SSLSocketFactory.java:572)
        at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180)
        at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294)
        at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645)
        at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480)
        at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906)
        at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805)
        at org.nrg.xnattools.SessionManager.createJSESSION(SessionManager.java:84)
        at org.nrg.xnattools.SessionManager.getJSESSION(SessionManager.java:136)
        at org.nrg.xnattools.service.WebServiceClient.connect(WebServiceClient.java:84)
        at org.nrg.imagingtools.utils.FileUtils.FileExists(FileUtils.java:474)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

To address this, presumably, I have in the past added "-aliasHost http://localhost:8080/xnat" to the XnatPipelineLauncher command line.

Now when I do THAT, I get the "SessionManager not inited" error.

So without aliasHost, SSL bails, with aliasHost, SessionManager not inited.

Any way you can think of to get this working?

We do, by the way, have a valid, signed SSL certificate with all bells and whistles, and the server name is identical to the server hostname. But we do tunnel ssl traffic through Apache, which uses Tomcat as a proxy in the back.

Thanks again!

Torsten

[Torsten Rohlfing]

Oh, I think I got it...

Turns out the pipeline works if I use

-aliasHost http://localhost:8080/xnat/

with added slash at the end.

Ah well :)

Thanks again!

[Paul Groot]

Although this is a very old post, I would like to report a possible alternative cause for this issue. My google searches always end here, so it can be useful information for others. 

It took forever to find the cause of queued autorun jobs in xnat. This state is misleading because such 'stalled' jobs are not queued, but stopped because of an error situation (first message: 'SessionManager not inited. Please init the session manager first'). It turns out that autorun jobs will crash and remain queued forever if the password of the built-in (admin) account (used to run the jobs) has expired.  We only found this out recently because all admins have personal accounts and never used the default account. I suspect that the password of the admin account is initially set to change periodically. The problem can be solved by setting the account to non-expiring.

Op dinsdag 13 mei 2014 22:20:41 UTC+2 schreef Torsten Rohlfing: