Posted by
dscho on
Jun 24, 2014; 1:51pm
URL: http://imagej.273.s1.nabble.com/Headless-ImageJ2-rc2-Analyze-Particles-returns-no-result-tp5008127p5008395.html
Hi Paul,
On Tue, 24 Jun 2014, Paul van Schayck wrote:
> On Mon, Jun 23, 2014 at 6:31 PM, Johannes Schindelin
> <
[hidden email]> wrote:
> >
> > That is strange. We run our regression tests (including macros) pretty
> > frequently and no such behavior was recorded. Maybe this behavior does not
> > occur in headless mode?
>
> It is pretty consistent behaviour in headless mode. It takes about 30s
> to a minute for it to return to the command line after running a macro
> or script (only js, not bsh!). It also happens after having run the
> updater (although the cause may be completely different there I
> realise). It does not happen in Fiji.daily.
>
> > In any case, do you know about the Ctrl+\ trick on the console to ask Java
> > for a thread dump? That might help you determine which thread is still
> > alive (and obviously blocking).
>
> I've made a pastebin from this:
>
http://pastebin.com/uF9AMKNH>
> This one looks suspicious:
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000000009d8b0070> (a
> java.util.concurrent.SynchronousQueue$TransferStack)
Hmm... It looks as if the Context is not correctly disposed of. Is there
any chance that you can reduce your script to a minimal example of that
behavior and share that script with us? At least here I cannot reproduce
with a print("Hello"); script...
> >> >> Running scripts this way in pure ImageJ has been giving this exception
> >> >> for me for a few weeks. However, it does work in the daily Fiji build.
> >> >>
> >> >> Exception in thread "main" java.lang.NullPointerException
> >> >> at net.imagej.launcher.ClassLauncher.launch(ClassLauncher.java:248)
> >> >> at net.imagej.launcher.ClassLauncher.run(ClassLauncher.java:184)
> >> >> at net.imagej.launcher.ClassLauncher.main(ClassLauncher.java:76)
> >> >
> >> >Hmm... I cannot reproduce in my Fiji.app/...
> >>
> >> No, exactly, it does work for me in Fiji.app/ but it does *not* work
> >> in ImageJ.app/.
> >
> > I'll have another look. Thank you for pointing out that the problem occurs
> > in ImageJ.app/, it never occured to me that that was the issue.
>
> You were right, it's the language used. This works:
> ./ImageJ-linux64 --headless scripts/short.bsh
>
> This throws the exception:
> ./ImageJ-linux64 --headless scripts/short.js
>
> Once again, not in Fiji.daily. They are both running the same JRE (the
> one distributed with Fiji.app).
Ah! That is easily explained. Javascript is included in Java 6. But in a
different package than Mozilla's original one (this is called "shading"
and prevents many problems when inconsistent versions of the same
component are on the same class path).
The launcher assumes the original packages, i.e. the Mozilla ones, but
that .jar file is only present in Fiji's jars/ directory.
We probably need to integrate the launcher better with the SciJava
scripting framework (which was designed, after all, to offer a
consistent interface to all scripting languages); that would fix your
problem with Javascript, make the command-line support for scripting more
easily extended (supporting e.g. running .java "scripts" from the
command-line!), and in general The Right Thing.
Having said that, I still feel that we have a little more work to do in
the user-centric phase of the work leading to 2.0.0 final, and this change
strikes me as a developer-centric one.
So I opened a ticket as a reminder for later:
https://github.com/imagej/imagej-launcher/issues/15Feel free to log into GitHub (if you do not have an account yet: it is
free) and click the "Watch" button of that ticket to receive notification
mails about updates.
Ciao,
Johannes
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html