Deadlocks in Groovy shell evaluations - groovy

I am using Groovy 1.7.8. and have written a Groovy DSL which I execute concurrently on different domain objects.
Of late, I have started facing deadlocks under heavy concurrency when DSLs are compiling/executing concurrently.
I am compiling/executing Groovy DSL at runtime using:
Script s = compileScript(dsl)
def binding = new Binding()
binding.setVariable("domainObj", domainObj)
s.setBinding(binding)
s.run()
def Script compileScript(String dsl) {
def scriptText = getScriptText(dsl)
def conf = new CompilerConfiguration()
conf.setScriptBaseClass(GroovyViewExecutionBase.class.getName())
new GroovyShell(conf).parse(scriptText)
}
Below is the thread dump of deadlocked threads, looking at the thread dumps I feel that Groovy is deadlocking internally when we concurrently compile/execute scripts at runtime.
Deadlock-Participant-1:
at java.beans.PropertyDescriptor.getReadMethod(PropertyDescriptor.java:158)
- waiting to lock <0x00007f41a3363960> (a java.beans.PropertyDescriptor)
at java.beans.Introspector.processPropertyDescriptors(Introspector.java:683)
at java.beans.Introspector.getTargetPropertyInfo(Introspector.java:615)
at java.beans.Introspector.getBeanInfo(Introspector.java:407)
at java.beans.Introspector.getBeanInfo(Introspector.java:164)
- locked <0x00007f41a3358c28> (a java.lang.Object)
at groovy.lang.MetaClassImpl$15.run(MetaClassImpl.java:2940)
at java.security.AccessController.doPrivileged(Native Method)
at groovy.lang.MetaClassImpl.addProperties(MetaClassImpl.java:2938)
at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:2921)
- locked <0x00007f429f011268> (a groovy.lang.ExpandoMetaClass)
at groovy.lang.ExpandoMetaClass.initialize(ExpandoMetaClass.java:463)
- locked <0x00007f429f011268> (a groovy.lang.ExpandoMetaClass)
at org.codehaus.groovy.reflection.ClassInfo.getMetaClassUnderLock(ClassInfo.java:166)
at org.codehaus.groovy.reflection.ClassInfo.getMetaClass(ClassInfo.java:182)
at org.codehaus.groovy.runtime.metaclass.MetaClassRegistryImpl.getMetaClass(MetaClassRegistryImpl.java:210)
at org.codehaus.groovy.runtime.InvokerHelper.getMetaClass(InvokerHelper.java:751)
at groovy.lang.GroovyObjectSupport.<init>(GroovyObjectSupport.java:32)
at groovy.lang.Script.<init>(Script.java:40)
at groovy.lang.Script.<init>(Script.java:37)
at flipkart.cms.views.core.GroovyViewExecutionBase.<init>(GroovyViewExecutionBase.groovy)
at Script1.<init>(Script1.groovy)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at org.codehaus.groovy.runtime.InvokerHelper.createScript(InvokerHelper.java:408)
at groovy.lang.GroovyShell.parse(GroovyShell.java:743)
at groovy.lang.GroovyShell.parse(GroovyShell.java:770)
at groovy.lang.GroovyShell.parse(GroovyShell.java:761)
at groovy.lang.GroovyShell$parse.call(Unknown Source)
at cms.views.core.GroovyDSLViewComputer.compileScript(GroovyDSLViewComputer.groovy:85)
==================
Deadlock-Participant-2:
at java.beans.Introspector.getPublicDeclaredMethods(Introspector.java:1277)
- waiting to lock <0x00007f41a3358c28> (a java.lang.Object)
at java.beans.Introspector.internalFindMethod(Introspector.java:1312)
at java.beans.Introspector.findMethod(Introspector.java:1383)
at java.beans.Introspector.findMethod(Introspector.java:1363)
at java.beans.PropertyDescriptor.getReadMethod(PropertyDescriptor.java:179)
- locked <0x00007f41a3363960> (a java.beans.PropertyDescriptor)
at groovy.lang.MetaClassImpl.applyPropertyDescriptors(MetaClassImpl.java:2215)
at groovy.lang.MetaClassImpl.setupProperties(MetaClassImpl.java:1995)
at groovy.lang.MetaClassImpl.addProperties(MetaClassImpl.java:2950)
at groovy.lang.MetaClassImpl.initialize(MetaClassImpl.java:2921)
- locked <0x00007f42a12972b8> (a groovy.lang.ExpandoMetaClass)
at groovy.lang.ExpandoMetaClass.initialize(ExpandoMetaClass.java:463)
- locked <0x00007f42a12972b8> (a groovy.lang.ExpandoMetaClass)
at org.codehaus.groovy.runtime.HandleMetaClass.replaceDelegate(HandleMetaClass.java:66)
at org.codehaus.groovy.runtime.HandleMetaClass.setProperty(HandleMetaClass.java:91)
at org.codehaus.groovy.runtime.InvokerHelper.setProperty(InvokerHelper.java:179)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.setProperty(ScriptBytecodeAdapter.java:483)
at flipkart.cms.views.core.GroovyViewExecutionBase.setupAttrProperties(GroovyViewExecutionBase.groovy:60)
at flipkart.cms.views.core.GroovyViewExecutionBase$setupAttrProperties$0.callCurrent(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:44)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:141)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:149)
at cms.views.core.GroovyViewExecutionBase.computeView(GroovyViewExecutionBase.groovy:32)
==================
Any ideas how I can fix/workaround this?

Posted this on groovy-user forum and looks like the deadlocks are caused because of synchronization issues in java 6's java.beans.Introspector class which apparently have been fixed in Java 7. Also received a backport of these classes for java 6 and am testing the backported classes to reproduce the deadlocks.
More details here:
http://groovy.329449.n5.nabble.com/Groovy-deadlocks-when-executing-DSL-from-GroovyShell-td5709889.html

Related

Strange error running a simple groovy script using Micronaut DI and Vertx

I have a project which is using Vertx and Micronaut DI
however something in this process breaks a simple capability in groovy of coercing a map to an interface
I have created a simple script like this. The same script in a simple groovy only project works just fine.
Has anyone else seen anything like this and what if anything needs to be fixed. I don't understand the error as the script itself isn't using DI or Vertx. I am assuming its something going wrong with Micronaut pre processors ?
package ioc
def map
map = [
i: 10,
hasNext: { map.i > 0 },
next: { map.i-- },
]
def iter = map as Iterator
iter.each {println it}
Which when i run it generates the following error.
Caught: java.lang.NoClassDefFoundError: io/vertx/codegen/annotations/DataObject
java.lang.NoClassDefFoundError: io/vertx/codegen/annotations/DataObject
at io.vertx.lang.groovy.VertxExtensionModule.asType(VertxExtensionModule.java:32)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at ioc.coerce.run(coerce.groovy:9)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
Caused by: java.lang.ClassNotFoundException: io.vertx.codegen.annotations.DataObject
... 8 more
Process finished with exit code 1
Has any one seen anything like this and were able to fix it? Its a bit weird by itself.

Log4j Logger class loading blocks application threads

Threads got BLOCKED when application threads heavily tried to log. Has this been encountered before. Does Async logger solve problems around this. Below is the thread dump indicating application threads getting BLOCKED when it was trying to heavily log exceptions. Multiple threads got into a BLOCKED state
"app[LARLAca][TG][T#7]" #55 daemon prio=5 os_prio=0 tid=0x00007f2de800b800 nid=0x2fee runnable [0x00007f2e048ee000]
java.lang.Thread.State: RUNNABLE
at java.util.zip.ZipFile.getEntry(Native Method)
at java.util.zip.ZipFile.getEntry(ZipFile.java:316)
- locked <0x00007f2f5c2e1310> (a java.util.jar.JarFile)
at java.util.jar.JarFile.getEntry(JarFile.java:240)
at java.util.jar.JarFile.getJarEntry(JarFile.java:223)
at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:1054)
at sun.misc.URLClassPath.getResource(URLClassPath.java:249)
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:363)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:362)
at java.lang.ClassLoader.loadClass(ClassLoader.java:419)
- locked <0x00007f2f5e3c4d30> (a java.lang.Object)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
at java.lang.ClassLoader.loadClass(ClassLoader.java:352)
at org.apache.logging.log4j.core.util.Loader.loadClass(Loader.java:240)
at org.apache.logging.log4j.core.impl.ThrowableProxy.loadClass(ThrowableProxy.java:633)
at org.apache.logging.log4j.core.impl.ThrowableProxy.loadClass(ThrowableProxy.java:624)
at org.apache.logging.log4j.core.impl.ThrowableProxy.toExtendedStackTrace(ThrowableProxy.java:738)
at org.apache.logging.log4j.core.impl.ThrowableProxy.<init>(ThrowableProxy.java:138)
at org.apache.logging.log4j.core.impl.ThrowableProxy.<init>(ThrowableProxy.java:122)
at org.apache.logging.log4j.core.impl.Log4jLogEvent.getThrownProxy(Log4jLogEvent.java:605)
at org.apache.logging.log4j.core.pattern.ExtendedThrowablePatternConverter.format(ExtendedThrowablePatternConverter.java:64)
at org.apache.logging.log4j.core.pattern.PatternFormatter.format(PatternFormatter.java:38)
at org.apache.logging.log4j.core.layout.PatternLayout$PatternSerializer.toSerializable(PatternLayout.java:334)
at org.apache.logging.log4j.core.layout.PatternLayout.toText(PatternLayout.java:233)
at org.apache.logging.log4j.core.layout.PatternLayout.encode(PatternLayout.java:218)
at org.apache.logging.log4j.core.layout.PatternLayout.encode(PatternLayout.java:58)
at org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.directEncodeEvent(AbstractOutputStreamAppender.java:177)
at org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.tryAppend(AbstractOutputStreamAppender.java:170)
at org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:161)
at org.apache.logging.log4j.core.appender.RollingFileAppender.append(RollingFileAppender.java:309)
at org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
at org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:129)
at org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:120)
at org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:84)
at org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:464)
at org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:448)
at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:431)
at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:406)
at org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:63)
at org.apache.logging.log4j.core.Logger.logMessage(Logger.java:146)
at org.apache.logging.log4j.spi.AbstractLogger.tryLogMessage(AbstractLogger.java:2170)
at org.apache.logging.log4j.spi.AbstractLogger.logMessageTrackRecursion(AbstractLogger.java:2125)
at org.apache.logging.log4j.spi.AbstractLogger.logMessageSafely(AbstractLogger.java:2108)
at org.apache.logging.log4j.spi.AbstractLogger.logMessage(AbstractLogger.java:1991)
at org.apache.logging.log4j.spi.AbstractLogger.logIfEnabled(AbstractLogger.java:1835)
at org.apache.logging.log4j.spi.AbstractLogger.warn(AbstractLogger.java:2684)
"app[LARLAca][TG][T#1]" #44 daemon prio=5 os_prio=0 tid=0x00007f36fe6b3000 nid=0x2fe3 waiting for monitor entry [0x00007f2e06bfb000]
java.lang.Thread.State: BLOCKED (on object monitor)
at java.lang.ClassLoader.loadClass(ClassLoader.java:399)
- waiting to lock <0x00007f2f5e3c4d30> (a java.lang.Object)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:352)
at java.lang.ClassLoader.loadClass(ClassLoader.java:352)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:264)
at org.apache.logging.log4j.util.LoaderUtil.loadClass(LoaderUtil.java:168)
at org.apache.logging.log4j.core.impl.ThrowableProxy.loadClass(ThrowableProxy.java:622)
at org.apache.logging.log4j.core.impl.ThrowableProxy.toExtendedStackTrace(ThrowableProxy.java:738)
at org.apache.logging.log4j.core.impl.ThrowableProxy.<init>(ThrowableProxy.java:138)
at org.apache.logging.log4j.core.impl.ThrowableProxy.<init>(ThrowableProxy.java:122)
at org.apache.logging.log4j.core.impl.Log4jLogEvent.getThrownProxy(Log4jLogEvent.java:605)
at org.apache.logging.log4j.core.pattern.ExtendedThrowablePatternConverter.format(ExtendedThrowablePatternConverter.java:64)
at org.apache.logging.log4j.core.pattern.PatternFormatter.format(PatternFormatter.java:38)
at org.apache.logging.log4j.core.layout.PatternLayout$PatternSerializer.toSerializable(PatternLayout.java:334)
at org.apache.logging.log4j.core.layout.PatternLayout.toText(PatternLayout.java:233)
at org.apache.logging.log4j.core.layout.PatternLayout.encode(PatternLayout.java:218)
at org.apache.logging.log4j.core.layout.PatternLayout.encode(PatternLayout.java:58)
at org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.directEncodeEvent(AbstractOutputStreamAppender.java:177)
at org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.tryAppend(AbstractOutputStreamAppender.java:170)
at org.apache.logging.log4j.core.appender.AbstractOutputStreamAppender.append(AbstractOutputStreamAppender.java:161)
at org.apache.logging.log4j.core.appender.RollingFileAppender.append(RollingFileAppender.java:309)
at org.apache.logging.log4j.core.config.AppenderControl.tryCallAppender(AppenderControl.java:156)
at org.apache.logging.log4j.core.config.AppenderControl.callAppender0(AppenderControl.java:129)
at org.apache.logging.log4j.core.config.AppenderControl.callAppenderPreventRecursion(AppenderControl.java:120)
at org.apache.logging.log4j.core.config.AppenderControl.callAppender(AppenderControl.java:84)
at org.apache.logging.log4j.core.config.LoggerConfig.callAppenders(LoggerConfig.java:464)
at org.apache.logging.log4j.core.config.LoggerConfig.processLogEvent(LoggerConfig.java:448)
at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:431)
at org.apache.logging.log4j.core.config.LoggerConfig.log(LoggerConfig.java:406)
at org.apache.logging.log4j.core.config.AwaitCompletionReliabilityStrategy.log(AwaitCompletionReliabilityStrategy.java:63)
at org.apache.logging.log4j.core.Logger.logMessage(Logger.java:146)
at org.apache.logging.log4j.spi.AbstractLogger.tryLogMessage(AbstractLogger.java:2170)
at org.apache.logging.log4j.spi.AbstractLogger.logMessageTrackRecursion(AbstractLogger.java:2125)
at org.apache.logging.log4j.spi.AbstractLogger.logMessageSafely(AbstractLogger.java:2108)
at org.apache.logging.log4j.spi.AbstractLogger.logMessage(AbstractLogger.java:1991)
at org.apache.logging.log4j.spi.AbstractLogger.logIfEnabled(AbstractLogger.java:1835)
at org.apache.logging.log4j.spi.AbstractLogger.warn(AbstractLogger.java:2684)
I found a solution. using a %ex in the pattern layout prevent the ThrowableProxy class loading thus saving the thread from getting BLOCKED

Fiji(ImageJ) takes too long to load (on linux), together with a lengthy error message

I'm using Fiji on linux (inside a virtual machine) from the command line.
Specifically I have a python script that calls many fiji macros.
Each time fiji loads it takes about a minute, making it the bottleneck of the process and slowing me considerably.
I wonder if this is normal. Could fiji perhaps be made to load more quickly?
Fiji also outputs a lengthy error message when it is called. I wonder if it is related to the lengthy time it takes to load.
The command I use to call it (for example)
//shared_directory/projects/Fiji.app/ImageJ-linux64 --headless
-macro //shared_directory/projects/retracted/fiji_scripts/patch_cropper.txt
The error message is as follows
java.awt.HeadlessException
at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:204)
at java.awt.Window.<init>(Window.java:536)
at java.awt.Frame.<init>(Frame.java:420)
at ij.plugin.frame.PlugInFrame.<init>(PlugInFrame.java:13)
at ij.plugin.frame.RoiManager.<init>(RoiManager.java:94)
at ij.macro.Interpreter.getBatchModeRoiManager(Interpreter.java:1875)
at ij.plugin.frame.RoiManager.getInstance(RoiManager.java:1795)
at ij.ImagePlus.deleteRoi(ImagePlus.java:1735)
at ij.ImagePlus.close(ImagePlus.java:391)
at ij.plugin.Commands.closeImage(Commands.java:136)
at ij.plugin.Commands.close(Commands.java:83)
at ij.plugin.Commands.run(Commands.java:29)
at ij.IJ.runPlugIn(IJ.java:187)
at ij.Executer.runCommand(Executer.java:137)
at ij.Executer.run(Executer.java:66)
at ij.IJ.run(IJ.java:297)
at ij.IJ.run(IJ.java:272)
at ij.macro.Functions.doRun(Functions.java:603)
at ij.macro.Functions.doFunction(Functions.java:96)
at ij.macro.Interpreter.doStatement(Interpreter.java:230)
at ij.macro.Interpreter.doStatements(Interpreter.java:218)
at ij.macro.Interpreter.run(Interpreter.java:115)
at ij.macro.Interpreter.run(Interpreter.java:85)
at ij.macro.Interpreter.run(Interpreter.java:96)
at ij.plugin.Macro_Runner.runMacro(Macro_Runner.java:155)
at ij.plugin.Macro_Runner.runMacroFile(Macro_Runner.java:139)
at ij.IJ.runMacroFile(IJ.java:148)
at net.imagej.legacy.IJ1Helper$4.call(IJ1Helper.java:1056)
at net.imagej.legacy.IJ1Helper$4.call(IJ1Helper.java:1052)
at net.imagej.legacy.IJ1Helper.runMacroFriendly(IJ1Helper.java:986)
at net.imagej.legacy.IJ1Helper.runMacroFile(IJ1Helper.java:1052)
at net.imagej.legacy.LegacyCommandline$Macro.handle(LegacyCommandline.java:188)
at org.scijava.console.DefaultConsoleService.processArgs(DefaultConsoleService.java:102)
at net.imagej.legacy.LegacyConsoleService.processArgs(LegacyConsoleService.java:81)
at org.scijava.AbstractGateway.launch(AbstractGateway.java:95)
at net.imagej.Main.launch(Main.java:62)
at net.imagej.Main.main(Main.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at net.imagej.launcher.ClassLauncher.launch(ClassLauncher.java:279)
at net.imagej.launcher.ClassLauncher.run(ClassLauncher.java:186)
at net.imagej.launcher.ClassLauncher.main(ClassLauncher.java:77)
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=128m; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: Using incremental CMS is deprecated and will likely be removed in a future release
java.lang.IllegalArgumentException: Cannot handle app name in ij.gui.YesNoCancelDialog's public <init>(java.awt.Frame parent, java.lang.String title, java.lang.String msg)
at net.imagej.patcher.CodeHacker.replaceAppNameInCall(CodeHacker.java:446)
at net.imagej.patcher.LegacyExtensions.insertAppNameHooks(LegacyExtensions.java:419)
at net.imagej.patcher.LegacyExtensions.injectHooks(LegacyExtensions.java:291)
at net.imagej.patcher.LegacyInjector.inject(LegacyInjector.java:308)
at net.imagej.patcher.LegacyInjector.injectHooks(LegacyInjector.java:109)
at net.imagej.patcher.LegacyEnvironment.initialize(LegacyEnvironment.java:101)
at net.imagej.patcher.LegacyEnvironment.applyPatches(LegacyEnvironment.java:495)
at net.imagej.patcher.LegacyInjector.preinit(LegacyInjector.java:397)
at net.imagej.patcher.LegacyInjector.preinit(LegacyInjector.java:376)
at net.imagej.legacy.LegacyService.<clinit>(LegacyService.java:134)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
at java.lang.Class.newInstance(Class.java:442)
at org.scijava.service.ServiceHelper.createServiceRecursively(ServiceHelper.java:302)
at org.scijava.service.ServiceHelper.createExactService(ServiceHelper.java:269)
at org.scijava.service.ServiceHelper.loadService(ServiceHelper.java:231)
at org.scijava.service.ServiceHelper.createServiceRecursively(ServiceHelper.java:340)
at org.scijava.service.ServiceHelper.createExactService(ServiceHelper.java:269)
at org.scijava.service.ServiceHelper.loadService(ServiceHelper.java:231)
at org.scijava.service.ServiceHelper.loadService(ServiceHelper.java:194)
at org.scijava.service.ServiceHelper.loadServices(ServiceHelper.java:166)
at org.scijava.Context.<init>(Context.java:278)
at org.scijava.Context.<init>(Context.java:234)
at org.scijava.Context.<init>(Context.java:174)
at org.scijava.Context.<init>(Context.java:160)
at net.imagej.ImageJ.<init>(ImageJ.java:77)
at net.imagej.Main.launch(Main.java:61)
at net.imagej.Main.main(Main.java:68)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:497)
at net.imagej.launcher.ClassLauncher.launch(ClassLauncher.java:279)
at net.imagej.launcher.ClassLauncher.run(ClassLauncher.java:186)
at net.imagej.launcher.ClassLauncher.main(ClassLauncher.java:77)
Caused by: javassist.CannotCompileException: No code replaced!
at net.imagej.patcher.CodeHacker$EagerExprEditor.instrument(CodeHacker.java:1280)
at net.imagej.patcher.CodeHacker.replaceAppNameInCall(CodeHacker.java:443)
... 36 more
Thanks!
I wonder if this is normal. Could fiji perhaps be made to load more quickly?
I don't think this is intended behavior. As this issue is very specific to ImageJ/Fiji, you should better raise this point on the ImageJ forum.
java.lang.IllegalArgumentException: Cannot handle app name in ij.gui.YesNoCancelDialog's public <init>(java.awt.Frame parent, java.lang.String title, java.lang.String msg)
This is likely due to ij1-patcher not handling ij.gui.YesNoCancelDialog to make it independent on the Java AWT framework (which interferes with the goal of running things headless).
You are welcome to submit a patch to the ij1-patcher project to make it deal with YesNoCancelDialog in a similar way as it currently does with GenericDialog, see these lines.
As a workaround, simply use a macro that doesn't use YesNoCancelDialog, i.e. does not run the getBoolean() macro function.
EDIT: as also noted in the ImageJ forum topic, a patch was submitted here.
Until this gets merged and released, you can work around the issue by downgrading ij.jar using Help > Update ImageJ...

tomcat classloader performance issue

Our benchmarking uncovered a bootleneck in Apache Tomcat 7.0.59. When the server reaches its performance limit, most of its threads are locked by ClassLoader.
Stack traces of blocked threads looks like this example:
"http-bio-4504-exec-500" Id=2335 BLOCKED on java.util.jar.JarFile#464f9f8 owned by "[1432628598653] POST /services/signin HTTP/1.0" Id=1990
at java.util.zip.ZipFile.getEntry(ZipFile.java:304)
- blocked on java.util.jar.JarFile#464f9f8
at java.util.jar.JarFile.getEntry(JarFile.java:226)
at java.util.jar.JarFile.getJarEntry(JarFile.java:209)
at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:840)
at sun.misc.URLClassPath$JarLoader.findResource(URLClassPath.java:818)
at sun.misc.URLClassPath$1.next(URLClassPath.java:226)
at sun.misc.URLClassPath$1.hasMoreElements(URLClassPath.java:236)
at java.net.URLClassLoader$3$1.run(URLClassLoader.java:583)
at java.net.URLClassLoader$3$1.run(URLClassLoader.java:581)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader$3.next(URLClassLoader.java:580)
at java.net.URLClassLoader$3.hasMoreElements(URLClassLoader.java:605)
at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45)
at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54)
at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45)
at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54)
at com.sun.xml.ws.util.ServiceFinder$LazyIterator.hasNext(ServiceFinder.java:443)
at com.sun.xml.ws.util.ServiceFinder$CompositeIterator.hasNext(ServiceFinder.java:390)
at com.sun.xml.ws.api.message.saaj.SAAJFactory.getMessageFactory(SAAJFactory.java:96)
at com.sun.xml.ws.api.SOAPVersion.getMessageFactory(SOAPVersion.java:221)
at com.sun.xml.ws.api.message.saaj.SAAJFactory.readAsSOAPMessage(SAAJFactory.java:275)
at com.sun.xml.ws.api.message.saaj.SAAJFactory.readAsSAAJ(SAAJFactory.java:205)
at com.sun.xml.ws.api.message.saaj.SAAJFactory.read(SAAJFactory.java:194)
at com.sun.xml.ws.message.AbstractMessageImpl.toSAAJ(AbstractMessageImpl.java:199)
at com.sun.xml.ws.api.message.MessageWrapper.readAsSOAPMessage(MessageWrapper.java:160)
at com.sun.xml.ws.handler.SOAPMessageContextImpl.getMessage(SOAPMessageContextImpl.java:86)
and the blocker thread is running at the same place
"[1432628598653] POST /services/signin HTTP/1.0" Id=1990 RUNNABLE
at java.util.zip.ZipFile.getEntry(ZipFile.java:304)
- locked java.util.jar.JarFile#464f9f8
at java.util.jar.JarFile.getEntry(JarFile.java:226)
at java.util.jar.JarFile.getJarEntry(JarFile.java:209)
at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:840)
at sun.misc.URLClassPath$JarLoader.findResource(URLClassPath.java:818)
at sun.misc.URLClassPath$1.next(URLClassPath.java:226)
at sun.misc.URLClassPath$1.hasMoreElements(URLClassPath.java:236)
at java.net.URLClassLoader$3$1.run(URLClassLoader.java:583)
at java.net.URLClassLoader$3$1.run(URLClassLoader.java:581)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader$3.next(URLClassLoader.java:580)
at java.net.URLClassLoader$3.hasMoreElements(URLClassLoader.java:605)
at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45)
at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54)
at sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45)
at sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54)
at com.sun.xml.ws.util.ServiceFinder$LazyIterator.hasNext(ServiceFinder.java:443)
at com.sun.xml.ws.util.ServiceFinder$CompositeIterator.hasNext(ServiceFinder.java:390)
at com.sun.xml.ws.api.message.saaj.SAAJFactory.read(SAAJFactory.java:190)
at com.sun.xml.ws.message.AbstractMessageImpl.toSAAJ(AbstractMessageImpl.java:199)
at com.sun.xml.ws.api.message.MessageWrapper.readAsSOAPMessage(MessageWrapper.java:160)
at com.sun.xml.ws.handler.SOAPMessageContextImpl.getMessage(SOAPMessageContextImpl.java:86)
Do our applications do something in a wrong way? Is there a workaround to avoid blocking in classloaders?
The problem was fixed completely with the following hack:
I added -Djaxp.debug=true to JVM args.
Then I found in logs all classes that JAX-WS was looking for.
I added system property for every mentioned class, and it made ServiceFinder to omit searching for service.properties files in classpath.
My final JVM args looked like:
-Djavax.xml.soap.MetaFactory=com.sun.xml.internal.messaging.saaj.soap.SAAJMetaFactoryImpl
-Djavax.xml.datatype.DatatypeFactory=com.sun.org.apache.xerces.internal.jaxp.datatype.DatatypeFactoryImpl
-Djavax.xml.parsers.DocumentBuilderFactory=com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl
-Djavax.xml.parsers.SAXParserFactory=com.sun.org.apache.xerces.internal.jaxp.SAXParserFactoryImpl
-Djavax.xml.stream.XMLInputFactory=com.ctc.wstx.stax.WstxInputFactory
-Djavax.xml.stream.XMLOutputFactory=com.ctc.wstx.stax.WstxOutputFactory
-Djavax.xml.transform.TransformerFactory=com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl

Getting StackTraceElement in groovy application

I have a piece of code that prints the current java file for logging purposes.
final StackTraceElement stackTraceElement = new Throwable().fillInStackTrace().getStackTrace()[2];
final String parentClassName = stackTraceElement.getFileName().replaceAll(".java", "");
final int lineNumber = stackTraceElement.getLineNumber();
I wrote something in groovy that uses the above code to print logs, it works, most of the time, however after couple of runs I'm starting to get NPE
java.lang.NullPointerException
at com.bla.general.util.log.LogUtils.generateLogMessage(LogUtils.java:140)
at com.bla.general.util.log.LogUtils.info(LogUtils.java:67)
at sun.reflect.GeneratedMethodAccessor831.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:90)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:324)
at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.invoke(StaticMetaMethodSite.java:43)
at org.codehaus.groovy.runtime.callsite.StaticMetaMethodSite.call(StaticMetaMethodSite.java:88)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
at com.bla.AppVersionServiceImpl.getAppVersion(AppVersionServiceImpl.groovy:47)
When the following line is the originator:
LogUtils.info("Trying to get details for device hash ${deviceHash}");
I'm using tomcat and java 1.7 as my stack. After restarting Tomcat things get back to normal.
It's my first endeavor to the dynamic world of JVM. I'll appreciate if you can enlighten me

Resources