Unable to re-deploy rails app (java.lang.RuntimeException: BUG: could not initialize constructor handle) #4442

Closed
aldrinmartoq opened this Issue Jan 15, 2017 · 30 comments

Comments

Projects
None yet
10 participants
@aldrinmartoq

Environment

  • jruby 9.1.7.0 (2.3.1) 2017-01-11 68056ae Java HotSpot(TM) 64-Bit Server VM 25.111-b14 on 1.8.0_111-b14 +jit [linux-x86_64]
  • Linux 2.6.18-398.el5 #1 SMP Tue Aug 12 06:26:17 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux
  • rails 4.2.7.1
  • JBoss EAP 7.0.0.GA (WildFly Core 2.1.2.Final-redhat-1)

Expected Behavior

We need to reinstall a rails application without restarting the JBoss application server.

Actual Behavior

We are trying to redeploy our rails app into a JBoss Server (rm -f jboss-eap-7.0/standalone/deployments/prueba.war; cp -f prueba.war jboss-eap-7.0/standalone/deployments/), but it fails with an exception. If we restart JBoss, the application runs fine.

We can reproduce the error with the following:

$ rvm use jruby-9.1.7.0
$ gem install rails -v 4.2.7.1
$ gem install warbler
$ rails new prueba
$ cd prueba
$ warble war
$ cp -f prueba.war jboss-eap-7.0/standalone/deployments/
# wait the app is running
$ rm -f jboss-eap-7.0/standalone/deployments/prueba.war
$ cp -f prueba.war jboss-eap-7.0/standalone/deployments/
# exception occurs

Here is the error log:

13:44:09,592 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "prueba.war" (runtime-name: "prueba.war")
13:44:11,988 INFO  [io.undertow.servlet] (ServerService Thread Pool -- 66) INFO: jruby 9.1.7.0 (2.3.1) 2017-01-11 68056ae Java HotSpot(TM) 64-Bit Server VM 25.111-b14 on 1.8.0_111-b14 +jit [linux-x86_64]
13:44:11,991 INFO  [io.undertow.servlet] (ServerService Thread Pool -- 66) INFO: using a shared (threadsafe!) runtime

13:44:12,182 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 66) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./prueba: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./prueba: java.lang.ExceptionInInitializerError
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: java.lang.ExceptionInInitializerError
	at org.jruby.runtime.ThreadContext.<init>(ThreadContext.java:214)
	at org.jruby.runtime.ThreadContext.newContext(ThreadContext.java:85)
	at org.jruby.internal.runtime.ThreadService.initMainThread(ThreadService.java:166)
	at org.jruby.Ruby.init(Ruby.java:1161)
	at org.jruby.Ruby.newInstance(Ruby.java:334)
	at org.jruby.rack.DefaultRackApplicationFactory.newRuntime(DefaultRackApplicationFactory.java:337)
	at org.jruby.rack.DefaultRackApplicationFactory$RackApplicationImpl.<init>(DefaultRackApplicationFactory.java:438)
	at org.jruby.rack.DefaultRackApplicationFactory.createApplication(DefaultRackApplicationFactory.java:426)
	at org.jruby.rack.DefaultRackApplicationFactory.newApplication(DefaultRackApplicationFactory.java:99)
	at org.jruby.rack.DefaultRackApplicationFactory.getApplication(DefaultRackApplicationFactory.java:113)
	at org.jruby.rack.SharedRackApplicationFactory.doInit(SharedRackApplicationFactory.java:34)
	at org.jruby.rack.RackApplicationFactoryDecorator.init(RackApplicationFactoryDecorator.java:100)
	at org.jruby.rack.RackServletContextListener.contextInitialized(RackServletContextListener.java:50)
	at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187)
	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:198)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
	... 6 more
Caused by: java.lang.RuntimeException: BUG: could not initialize constructor handle
	at org.jruby.runtime.scope.ManyVarsDynamicScope.<clinit>(ManyVarsDynamicScope.java:39)
	... 23 more

13:44:12,184 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "prueba.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./prueba" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./prueba: java.lang.ExceptionInInitializerError
    Caused by: java.lang.ExceptionInInitializerError
    Caused by: java.lang.RuntimeException: BUG: could not initialize constructor handle"}}
13:44:12,202 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 2) WFLYSRV0010: Deployed "prueba.war" (runtime-name : "prueba.war")
@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius Jan 17, 2017

Member

Weird.

Member

headius commented Jan 17, 2017

Weird.

@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius Jan 17, 2017

Member

Ok, I've had a look at the code. This is failing inside ManyVarsDynamicScope where we attempt to create a MethodHandle for constructing instances of said scope. The handle is acquired in a static code block at boot and should only fail if security settings prevent acquisition of the needed constructor handle.

I would expect this to fail every time if it fails at all. If it's failing only in the n+1 deployments, I'd suspect some classloading problem.

Unfortunately I can't see what the original error was because we didn't log it (my mistake). I've pushed 9aad929 to remedy that. Are you able to try deploying with a jruby-head build so we can get a better error report?

Member

headius commented Jan 17, 2017

Ok, I've had a look at the code. This is failing inside ManyVarsDynamicScope where we attempt to create a MethodHandle for constructing instances of said scope. The handle is acquired in a static code block at boot and should only fail if security settings prevent acquisition of the needed constructor handle.

I would expect this to fail every time if it fails at all. If it's failing only in the n+1 deployments, I'd suspect some classloading problem.

Unfortunately I can't see what the original error was because we didn't log it (my mistake). I've pushed 9aad929 to remedy that. Are you able to try deploying with a jruby-head build so we can get a better error report?

@headius headius added this to the JRuby 9.1.8.0 milestone Jan 17, 2017

@aldrinmartoq

This comment has been minimized.

Show comment
Hide comment
@aldrinmartoq

aldrinmartoq Jan 18, 2017

Thanks @headius, I have installed jruby-head + jruby-jars gem from latest GIT, and here is the detailed log:

13:52:51,070 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.0.0.GA (WildFly Core 2.1.2.Final-redhat-1) started in 4667ms - Started 267 of 553 services (371 services are lazy, passive or on-demand)
13:53:26,301 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "prueba.war" (runtime-name: "prueba.war")
13:53:29,787 INFO  [io.undertow.servlet] (ServerService Thread Pool -- 62) INFO: jruby 9.1.8.0-SNAPSHOT (2.3.1) 2017-01-18 fffffff Java HotSpot(TM) 64-Bit Server VM 25.111-b14 on 1.8.0_111-b14 +jit [linux-x86_64]
13:53:29,792 INFO  [io.undertow.servlet] (ServerService Thread Pool -- 62) INFO: using a shared (threadsafe!) runtime
13:53:43,816 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 62) WFLYUT0021: Registered web context: /prueba
13:53:43,862 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0010: Deployed "prueba.war" (runtime-name : "prueba.war")
13:53:53,922 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 62) WFLYUT0022: Unregistered web context: /prueba
13:53:53,954 INFO  [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) HV000001: Hibernate Validator 5.2.4.Final-redhat-1
13:53:54,199 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment prueba.war (runtime-name: prueba.war) in 290ms
13:53:54,229 INFO  [org.jboss.as.repository] (DeploymentScanner-threads - 1) WFLYDR0002: Content removed from location /jboss-eap-7.0/standalone/data/content/29/73a8a7b7e6604384927987c0ca220847a55015/content
13:53:54,230 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0009: Undeployed "prueba.war" (runtime-name: "prueba.war")
13:53:59,554 INFO  [org.jboss.as.repository] (DeploymentScanner-threads - 1) WFLYDR0001: Content added at location /jboss-eap-7.0/standalone/data/content/29/73a8a7b7e6604384927987c0ca220847a55015/content
13:53:59,558 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "prueba.war" (runtime-name: "prueba.war")
13:54:01,949 INFO  [io.undertow.servlet] (ServerService Thread Pool -- 67) INFO: jruby 9.1.8.0-SNAPSHOT (2.3.1) 2017-01-18 fffffff Java HotSpot(TM) 64-Bit Server VM 25.111-b14 on 1.8.0_111-b14 +jit [linux-x86_64]
13:54:01,951 INFO  [io.undertow.servlet] (ServerService Thread Pool -- 67) INFO: using a shared (threadsafe!) runtime
13:54:02,108 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 67) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./prueba: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./prueba: java.lang.ExceptionInInitializerError
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: java.lang.ExceptionInInitializerError
	at org.jruby.runtime.ThreadContext.<init>(ThreadContext.java:214)
	at org.jruby.runtime.ThreadContext.newContext(ThreadContext.java:85)
	at org.jruby.internal.runtime.ThreadService.initMainThread(ThreadService.java:166)
	at org.jruby.Ruby.init(Ruby.java:1161)
	at org.jruby.Ruby.newInstance(Ruby.java:334)
	at org.jruby.rack.DefaultRackApplicationFactory.newRuntime(DefaultRackApplicationFactory.java:337)
	at org.jruby.rack.DefaultRackApplicationFactory$RackApplicationImpl.<init>(DefaultRackApplicationFactory.java:438)
	at org.jruby.rack.DefaultRackApplicationFactory.createApplication(DefaultRackApplicationFactory.java:426)
	at org.jruby.rack.DefaultRackApplicationFactory.newApplication(DefaultRackApplicationFactory.java:99)
	at org.jruby.rack.DefaultRackApplicationFactory.getApplication(DefaultRackApplicationFactory.java:113)
	at org.jruby.rack.SharedRackApplicationFactory.doInit(SharedRackApplicationFactory.java:34)
	at org.jruby.rack.RackApplicationFactoryDecorator.init(RackApplicationFactoryDecorator.java:100)
	at org.jruby.rack.RackServletContextListener.contextInitialized(RackServletContextListener.java:50)
	at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187)
	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:198)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
	... 6 more
Caused by: java.lang.RuntimeException: BUG: could not initialize constructor handle
	at org.jruby.runtime.scope.ManyVarsDynamicScope.<clinit>(ManyVarsDynamicScope.java:39)
	... 23 more
Caused by: java.lang.IllegalAccessException: no such constructor: org.jruby.runtime.scope.ManyVarsDynamicScope.<init>(StaticScope,DynamicScope)void/newInvokeSpecial
	at java.lang.invoke.MemberName.makeAccessException(MemberName.java:867)
	at java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:1003)
	at java.lang.invoke.MethodHandles$Lookup.resolveOrFail(MethodHandles.java:1381)
	at java.lang.invoke.MethodHandles$Lookup.findConstructor(MethodHandles.java:919)
	at org.jruby.runtime.scope.ManyVarsDynamicScope.<clinit>(ManyVarsDynamicScope.java:36)
	... 23 more
Caused by: java.lang.LinkageError: loader constraint violation: when resolving method "org.jruby.runtime.scope.ManyVarsDynamicScope.<init>(Lorg/jruby/parser/StaticScope;Lorg/jruby/runtime/DynamicScope;)V" the class loader (instance of <bootloader>) of the current class, java/lang/Object, and the class loader (instance of org/jboss/modules/ModuleClassLoader) for the method's defining class, org/jruby/runtime/scope/ManyVarsDynamicScope, have different Class objects for the type org/jruby/parser/StaticScope used in the signature
	at java.lang.invoke.MethodHandleNatives.resolve(Native Method)
	at java.lang.invoke.MemberName$Factory.resolve(MemberName.java:975)
	at java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:1000)
	... 26 more

13:54:02,112 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "prueba.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./prueba" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./prueba: java.lang.ExceptionInInitializerError
    Caused by: java.lang.ExceptionInInitializerError
    Caused by: java.lang.RuntimeException: BUG: could not initialize constructor handle
    Caused by: java.lang.IllegalAccessException: no such constructor: org.jruby.runtime.scope.ManyVarsDynamicScope.<init>(StaticScope,DynamicScope)void/newInvokeSpecial
    Caused by: java.lang.LinkageError: loader constraint violation: when resolving method \"org.jruby.runtime.scope.ManyVarsDynamicScope.<init>(Lorg/jruby/parser/StaticScope;Lorg/jruby/runtime/DynamicScope;)V\" the class loader (instance of <bootloader>) of the current class, java/lang/Object, and the class loader (instance of org/jboss/modules/ModuleClassLoader) for the method's defining class, org/jruby/runtime/scope/ManyVarsDynamicScope, have different Class objects for the type org/jruby/parser/StaticScope used in the signature"}}
13:54:02,123 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0010: Deployed "prueba.war" (runtime-name : "prueba.war")
13:54:02,123 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 1) WFLYCTL0183: Service status report
WFLYCTL0186:   Services which failed to start:      service jboss.undertow.deployment.default-server.default-host./prueba: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./prueba: java.lang.ExceptionInInitializerError

Seems to be a classloader problem… It happens when I deploy a second rails WAR, too.

Thanks @headius, I have installed jruby-head + jruby-jars gem from latest GIT, and here is the detailed log:

13:52:51,070 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: JBoss EAP 7.0.0.GA (WildFly Core 2.1.2.Final-redhat-1) started in 4667ms - Started 267 of 553 services (371 services are lazy, passive or on-demand)
13:53:26,301 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "prueba.war" (runtime-name: "prueba.war")
13:53:29,787 INFO  [io.undertow.servlet] (ServerService Thread Pool -- 62) INFO: jruby 9.1.8.0-SNAPSHOT (2.3.1) 2017-01-18 fffffff Java HotSpot(TM) 64-Bit Server VM 25.111-b14 on 1.8.0_111-b14 +jit [linux-x86_64]
13:53:29,792 INFO  [io.undertow.servlet] (ServerService Thread Pool -- 62) INFO: using a shared (threadsafe!) runtime
13:53:43,816 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 62) WFLYUT0021: Registered web context: /prueba
13:53:43,862 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0010: Deployed "prueba.war" (runtime-name : "prueba.war")
13:53:53,922 INFO  [org.wildfly.extension.undertow] (ServerService Thread Pool -- 62) WFLYUT0022: Unregistered web context: /prueba
13:53:53,954 INFO  [org.hibernate.validator.internal.util.Version] (MSC service thread 1-2) HV000001: Hibernate Validator 5.2.4.Final-redhat-1
13:53:54,199 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0028: Stopped deployment prueba.war (runtime-name: prueba.war) in 290ms
13:53:54,229 INFO  [org.jboss.as.repository] (DeploymentScanner-threads - 1) WFLYDR0002: Content removed from location /jboss-eap-7.0/standalone/data/content/29/73a8a7b7e6604384927987c0ca220847a55015/content
13:53:54,230 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0009: Undeployed "prueba.war" (runtime-name: "prueba.war")
13:53:59,554 INFO  [org.jboss.as.repository] (DeploymentScanner-threads - 1) WFLYDR0001: Content added at location /jboss-eap-7.0/standalone/data/content/29/73a8a7b7e6604384927987c0ca220847a55015/content
13:53:59,558 INFO  [org.jboss.as.server.deployment] (MSC service thread 1-1) WFLYSRV0027: Starting deployment of "prueba.war" (runtime-name: "prueba.war")
13:54:01,949 INFO  [io.undertow.servlet] (ServerService Thread Pool -- 67) INFO: jruby 9.1.8.0-SNAPSHOT (2.3.1) 2017-01-18 fffffff Java HotSpot(TM) 64-Bit Server VM 25.111-b14 on 1.8.0_111-b14 +jit [linux-x86_64]
13:54:01,951 INFO  [io.undertow.servlet] (ServerService Thread Pool -- 67) INFO: using a shared (threadsafe!) runtime
13:54:02,108 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 67) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./prueba: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./prueba: java.lang.ExceptionInInitializerError
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: java.lang.ExceptionInInitializerError
	at org.jruby.runtime.ThreadContext.<init>(ThreadContext.java:214)
	at org.jruby.runtime.ThreadContext.newContext(ThreadContext.java:85)
	at org.jruby.internal.runtime.ThreadService.initMainThread(ThreadService.java:166)
	at org.jruby.Ruby.init(Ruby.java:1161)
	at org.jruby.Ruby.newInstance(Ruby.java:334)
	at org.jruby.rack.DefaultRackApplicationFactory.newRuntime(DefaultRackApplicationFactory.java:337)
	at org.jruby.rack.DefaultRackApplicationFactory$RackApplicationImpl.<init>(DefaultRackApplicationFactory.java:438)
	at org.jruby.rack.DefaultRackApplicationFactory.createApplication(DefaultRackApplicationFactory.java:426)
	at org.jruby.rack.DefaultRackApplicationFactory.newApplication(DefaultRackApplicationFactory.java:99)
	at org.jruby.rack.DefaultRackApplicationFactory.getApplication(DefaultRackApplicationFactory.java:113)
	at org.jruby.rack.SharedRackApplicationFactory.doInit(SharedRackApplicationFactory.java:34)
	at org.jruby.rack.RackApplicationFactoryDecorator.init(RackApplicationFactoryDecorator.java:100)
	at org.jruby.rack.RackServletContextListener.contextInitialized(RackServletContextListener.java:50)
	at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187)
	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:198)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
	... 6 more
Caused by: java.lang.RuntimeException: BUG: could not initialize constructor handle
	at org.jruby.runtime.scope.ManyVarsDynamicScope.<clinit>(ManyVarsDynamicScope.java:39)
	... 23 more
Caused by: java.lang.IllegalAccessException: no such constructor: org.jruby.runtime.scope.ManyVarsDynamicScope.<init>(StaticScope,DynamicScope)void/newInvokeSpecial
	at java.lang.invoke.MemberName.makeAccessException(MemberName.java:867)
	at java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:1003)
	at java.lang.invoke.MethodHandles$Lookup.resolveOrFail(MethodHandles.java:1381)
	at java.lang.invoke.MethodHandles$Lookup.findConstructor(MethodHandles.java:919)
	at org.jruby.runtime.scope.ManyVarsDynamicScope.<clinit>(ManyVarsDynamicScope.java:36)
	... 23 more
Caused by: java.lang.LinkageError: loader constraint violation: when resolving method "org.jruby.runtime.scope.ManyVarsDynamicScope.<init>(Lorg/jruby/parser/StaticScope;Lorg/jruby/runtime/DynamicScope;)V" the class loader (instance of <bootloader>) of the current class, java/lang/Object, and the class loader (instance of org/jboss/modules/ModuleClassLoader) for the method's defining class, org/jruby/runtime/scope/ManyVarsDynamicScope, have different Class objects for the type org/jruby/parser/StaticScope used in the signature
	at java.lang.invoke.MethodHandleNatives.resolve(Native Method)
	at java.lang.invoke.MemberName$Factory.resolve(MemberName.java:975)
	at java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:1000)
	... 26 more

13:54:02,112 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "prueba.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./prueba" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./prueba: java.lang.ExceptionInInitializerError
    Caused by: java.lang.ExceptionInInitializerError
    Caused by: java.lang.RuntimeException: BUG: could not initialize constructor handle
    Caused by: java.lang.IllegalAccessException: no such constructor: org.jruby.runtime.scope.ManyVarsDynamicScope.<init>(StaticScope,DynamicScope)void/newInvokeSpecial
    Caused by: java.lang.LinkageError: loader constraint violation: when resolving method \"org.jruby.runtime.scope.ManyVarsDynamicScope.<init>(Lorg/jruby/parser/StaticScope;Lorg/jruby/runtime/DynamicScope;)V\" the class loader (instance of <bootloader>) of the current class, java/lang/Object, and the class loader (instance of org/jboss/modules/ModuleClassLoader) for the method's defining class, org/jruby/runtime/scope/ManyVarsDynamicScope, have different Class objects for the type org/jruby/parser/StaticScope used in the signature"}}
13:54:02,123 INFO  [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0010: Deployed "prueba.war" (runtime-name : "prueba.war")
13:54:02,123 INFO  [org.jboss.as.controller] (DeploymentScanner-threads - 1) WFLYCTL0183: Service status report
WFLYCTL0186:   Services which failed to start:      service jboss.undertow.deployment.default-server.default-host./prueba: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./prueba: java.lang.ExceptionInInitializerError

Seems to be a classloader problem… It happens when I deploy a second rails WAR, too.

@kares

This comment has been minimized.

Show comment
Hide comment
@kares

kares Jan 18, 2017

Member

yay - yay - yay ... too much generated content for a re-boot :) !
maybe having ManyVarsScope classes pre-generated w help ?

Member

kares commented Jan 18, 2017

yay - yay - yay ... too much generated content for a re-boot :) !
maybe having ManyVarsScope classes pre-generated w help ?

@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius Jan 19, 2017

Member

Ok, so this looks like something wrong with classloading in your setup. You're getting two visible definitions of the StaticScope class, so when we try to capture a handle for ManyVarsDynamicScope's constructor it blows up. This may be a bug in JBoss or the JVM. I'll have a look at the code.

@kares This is actually just trying to get a MethodHandle to ManyVarsDynamicScope's constructor, so it can be constructed programmatically along with all the generated ones. This isn't a failure in our code generation.

Member

headius commented Jan 19, 2017

Ok, so this looks like something wrong with classloading in your setup. You're getting two visible definitions of the StaticScope class, so when we try to capture a handle for ManyVarsDynamicScope's constructor it blows up. This may be a bug in JBoss or the JVM. I'll have a look at the code.

@kares This is actually just trying to get a MethodHandle to ManyVarsDynamicScope's constructor, so it can be constructed programmatically along with all the generated ones. This isn't a failure in our code generation.

@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius Jan 19, 2017

Member

@aldrinmartoq It seems like this could only be failing if you had JRuby (or some version of it) also in the app server classpath, rather than only in the war file. Can you investigate if that's the case?

The error message claims that Object's classloader (the bootstrap classloader) sees a different version of the class than the webapp classloader, which should only be possible if JRuby is also being loaded at the bootstrap level.

If you do not have JRuby in the app server's classpath, this may be a bug in method handle logic.

Member

headius commented Jan 19, 2017

@aldrinmartoq It seems like this could only be failing if you had JRuby (or some version of it) also in the app server classpath, rather than only in the war file. Can you investigate if that's the case?

The error message claims that Object's classloader (the bootstrap classloader) sees a different version of the class than the webapp classloader, which should only be possible if JRuby is also being loaded at the bootstrap level.

If you do not have JRuby in the app server's classpath, this may be a bug in method handle logic.

@thomasoberle

This comment has been minimized.

Show comment
Hide comment
@thomasoberle

thomasoberle Jan 19, 2017

I have the same problem. With jruby 9.1.5.0 I don't have this problem.

Environment:

jruby 9.1.7.0 (2.3.1) 2017-01-11 68056ae Java HotSpot(TM) 64-Bit Server VM 25.112-b15 on 1.8.0_112-b15 +jit [linux-x86_64]
Linux sg005503 3.10.0-229.28.1.el7.x86_64 #1 SMP Mon Feb 1 10:41:10 EST 2016 x86_64 x86_64 x86_64 GNU/Linux
Rails 4.2.7.1 and Rails 5.0.1

jboss/wildfly
[org.jboss.modules] (main) JBoss Modules version 1.5.2.Final
[org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
[org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Full 10.1.0.Final (WildFly Core 2.2.0.Final) starting
[org.xnio] (MSC service thread 1-7) XNIO version 3.4.0.Final

I have the same problem. With jruby 9.1.5.0 I don't have this problem.

Environment:

jruby 9.1.7.0 (2.3.1) 2017-01-11 68056ae Java HotSpot(TM) 64-Bit Server VM 25.112-b15 on 1.8.0_112-b15 +jit [linux-x86_64]
Linux sg005503 3.10.0-229.28.1.el7.x86_64 #1 SMP Mon Feb 1 10:41:10 EST 2016 x86_64 x86_64 x86_64 GNU/Linux
Rails 4.2.7.1 and Rails 5.0.1

jboss/wildfly
[org.jboss.modules] (main) JBoss Modules version 1.5.2.Final
[org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
[org.jboss.as] (MSC service thread 1-7) WFLYSRV0049: WildFly Full 10.1.0.Final (WildFly Core 2.2.0.Final) starting
[org.xnio] (MSC service thread 1-7) XNIO version 3.4.0.Final

@aldrinmartoq

This comment has been minimized.

Show comment
Hide comment
@aldrinmartoq

aldrinmartoq Jan 19, 2017

@headius I have checked, and there is no other JRuby jar in the classpath. Don't know how JBoss load that class with a bootstrap classloader. Here is my log:

# run with JAVA_OPTS="-verbose:class"
# first deploy
grep StaticScope server.log
[Loaded org.jruby.parser.StaticScopeFactory from vfs:/content/prueba.war/WEB-INF/lib/jruby-core-9.1.8.0-SNAPSHOT-complete.jar]
[Loaded org.jruby.parser.StaticScope from vfs:/content/prueba.war/WEB-INF/lib/jruby-core-9.1.8.0-SNAPSHOT-complete.jar]
[Loaded org.jruby.parser.StaticScope$Type from vfs:/content/prueba.war/WEB-INF/lib/jruby-core-9.1.8.0-SNAPSHOT-complete.jar]

# second deploy
[Loaded org.jruby.parser.StaticScopeFactory from vfs:/content/prueba.war/WEB-INF/lib/jruby-core-9.1.8.0-SNAPSHOT-complete.jar]
[Loaded org.jruby.parser.StaticScope from vfs:/content/prueba.war/WEB-INF/lib/jruby-core-9.1.8.0-SNAPSHOT-complete.jar]
[Loaded org.jruby.parser.StaticScope$Type from vfs:/content/prueba.war/WEB-INF/lib/jruby-core-9.1.8.0-SNAPSHOT-complete.jar]
Caused by: java.lang.IllegalAccessException: no such constructor: org.jruby.runtime.scope.ManyVarsDynamicScope.<init>(StaticScope,DynamicScope)void/newInvokeSpecial
Caused by: java.lang.LinkageError: loader constraint violation: when resolving method "org.jruby.runtime.scope.ManyVarsDynamicScope.<init>(Lorg/jruby/parser/StaticScope;Lorg/jruby/runtime/DynamicScope;)V" the class loader (instance of <bootloader>) of the current class, java/lang/Object, and the class loader (instance of org/jboss/modules/ModuleClassLoader) for the method's defining class, org/jruby/runtime/scope/ManyVarsDynamicScope, have different Class objects for the type org/jruby/parser/StaticScope used in the signature
    Caused by: java.lang.IllegalAccessException: no such constructor: org.jruby.runtime.scope.ManyVarsDynamicScope.<init>(StaticScope,DynamicScope)void/newInvokeSpecial

When I undeploy the war, there are no Unload entries in the log, and the server keep some JRuby jars open, for ex:

$ lsof -np 5777 | grep jar | grep jruby
java    5777 user  mem    REG              253,0    18611   622623 /tmp/jruby-5777/jruby6585587123256577341psych.jar
java    5777 user  mem    REG              253,0    16166   622628 /tmp/jruby-5777/jruby4208945813556012793cparse-jruby.jar
java    5777 user  mem    REG              253,0   273599   622624 /tmp/jruby-5777/jruby1485797000506859202snakeyaml-1.17.jar
java    5777 user  mem    REG              253,0   682213   622625 /tmp/jruby-5777/jruby3464567860517957798bcpkix-jdk15on-1.55.jar
java    5777 user  mem    REG              253,0  3398948   622626 /tmp/jruby-5777/jruby1985232427856674360bcprov-jdk15on-1.55.jar
java    5777 user  mem    REG              253,0  1092325   622627 /tmp/jruby-5777/jruby8880908503120144923jopenssl.jar
java    5777 user  397r   REG              253,0    18611   622623 /tmp/jruby-5777/jruby6585587123256577341psych.jar
java    5777 user  399r   REG              253,0   273599   622624 /tmp/jruby-5777/jruby1485797000506859202snakeyaml-1.17.jar
java    5777 user  401r   REG              253,0   682213   622625 /tmp/jruby-5777/jruby3464567860517957798bcpkix-jdk15on-1.55.jar
java    5777 user  404r   REG              253,0  3398948   622626 /tmp/jruby-5777/jruby1985232427856674360bcprov-jdk15on-1.55.jar
java    5777 user  405r   REG              253,0  1092325   622627 /tmp/jruby-5777/jruby8880908503120144923jopenssl.jar
java    5777 user  426r   REG              253,0    16166   622628 /tmp/jruby-5777/jruby4208945813556012793cparse-jruby.jar

But none of those jars has the StaticScope class. I'm still trying to debug what's wrong with JBoss with no luck.

@thomasoberle I will check later if JRuby 9.1.5.0 works for me, thanks.

@headius I have checked, and there is no other JRuby jar in the classpath. Don't know how JBoss load that class with a bootstrap classloader. Here is my log:

# run with JAVA_OPTS="-verbose:class"
# first deploy
grep StaticScope server.log
[Loaded org.jruby.parser.StaticScopeFactory from vfs:/content/prueba.war/WEB-INF/lib/jruby-core-9.1.8.0-SNAPSHOT-complete.jar]
[Loaded org.jruby.parser.StaticScope from vfs:/content/prueba.war/WEB-INF/lib/jruby-core-9.1.8.0-SNAPSHOT-complete.jar]
[Loaded org.jruby.parser.StaticScope$Type from vfs:/content/prueba.war/WEB-INF/lib/jruby-core-9.1.8.0-SNAPSHOT-complete.jar]

# second deploy
[Loaded org.jruby.parser.StaticScopeFactory from vfs:/content/prueba.war/WEB-INF/lib/jruby-core-9.1.8.0-SNAPSHOT-complete.jar]
[Loaded org.jruby.parser.StaticScope from vfs:/content/prueba.war/WEB-INF/lib/jruby-core-9.1.8.0-SNAPSHOT-complete.jar]
[Loaded org.jruby.parser.StaticScope$Type from vfs:/content/prueba.war/WEB-INF/lib/jruby-core-9.1.8.0-SNAPSHOT-complete.jar]
Caused by: java.lang.IllegalAccessException: no such constructor: org.jruby.runtime.scope.ManyVarsDynamicScope.<init>(StaticScope,DynamicScope)void/newInvokeSpecial
Caused by: java.lang.LinkageError: loader constraint violation: when resolving method "org.jruby.runtime.scope.ManyVarsDynamicScope.<init>(Lorg/jruby/parser/StaticScope;Lorg/jruby/runtime/DynamicScope;)V" the class loader (instance of <bootloader>) of the current class, java/lang/Object, and the class loader (instance of org/jboss/modules/ModuleClassLoader) for the method's defining class, org/jruby/runtime/scope/ManyVarsDynamicScope, have different Class objects for the type org/jruby/parser/StaticScope used in the signature
    Caused by: java.lang.IllegalAccessException: no such constructor: org.jruby.runtime.scope.ManyVarsDynamicScope.<init>(StaticScope,DynamicScope)void/newInvokeSpecial

When I undeploy the war, there are no Unload entries in the log, and the server keep some JRuby jars open, for ex:

$ lsof -np 5777 | grep jar | grep jruby
java    5777 user  mem    REG              253,0    18611   622623 /tmp/jruby-5777/jruby6585587123256577341psych.jar
java    5777 user  mem    REG              253,0    16166   622628 /tmp/jruby-5777/jruby4208945813556012793cparse-jruby.jar
java    5777 user  mem    REG              253,0   273599   622624 /tmp/jruby-5777/jruby1485797000506859202snakeyaml-1.17.jar
java    5777 user  mem    REG              253,0   682213   622625 /tmp/jruby-5777/jruby3464567860517957798bcpkix-jdk15on-1.55.jar
java    5777 user  mem    REG              253,0  3398948   622626 /tmp/jruby-5777/jruby1985232427856674360bcprov-jdk15on-1.55.jar
java    5777 user  mem    REG              253,0  1092325   622627 /tmp/jruby-5777/jruby8880908503120144923jopenssl.jar
java    5777 user  397r   REG              253,0    18611   622623 /tmp/jruby-5777/jruby6585587123256577341psych.jar
java    5777 user  399r   REG              253,0   273599   622624 /tmp/jruby-5777/jruby1485797000506859202snakeyaml-1.17.jar
java    5777 user  401r   REG              253,0   682213   622625 /tmp/jruby-5777/jruby3464567860517957798bcpkix-jdk15on-1.55.jar
java    5777 user  404r   REG              253,0  3398948   622626 /tmp/jruby-5777/jruby1985232427856674360bcprov-jdk15on-1.55.jar
java    5777 user  405r   REG              253,0  1092325   622627 /tmp/jruby-5777/jruby8880908503120144923jopenssl.jar
java    5777 user  426r   REG              253,0    16166   622628 /tmp/jruby-5777/jruby4208945813556012793cparse-jruby.jar

But none of those jars has the StaticScope class. I'm still trying to debug what's wrong with JBoss with no luck.

@thomasoberle I will check later if JRuby 9.1.5.0 works for me, thanks.

@aldrinmartoq

This comment has been minimized.

Show comment
Hide comment
@aldrinmartoq

aldrinmartoq Jan 20, 2017

@headius @thomasoberle I confirm I can re-deploy using JRuby 9.1.5.0 🤔

@headius @thomasoberle I confirm I can re-deploy using JRuby 9.1.5.0 🤔

@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius Jan 24, 2017

Member

Hmm, I wonder if our recently-failing j2ee test suite is caused by the same problem. Any thoughts, @mkristian?

Member

headius commented Jan 24, 2017

Hmm, I wonder if our recently-failing j2ee test suite is caused by the same problem. Any thoughts, @mkristian?

@mkristian

This comment has been minimized.

Show comment
Hide comment
@mkristian

mkristian Jan 24, 2017

Member

@headius thoughts: it first sounds more like some regression between 9.1.5.0 and 9.1.7.0. secondly it is high time to make some time and get these j2ee test green again as they might have caught this problem.

Member

mkristian commented Jan 24, 2017

@headius thoughts: it first sounds more like some regression between 9.1.5.0 and 9.1.7.0. secondly it is high time to make some time and get these j2ee test green again as they might have caught this problem.

@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius Jan 24, 2017

Member

@mkristian I agree.

Member

headius commented Jan 24, 2017

@mkristian I agree.

@aldrinmartoq

This comment has been minimized.

Show comment
Hide comment
@aldrinmartoq

aldrinmartoq Jan 31, 2017

@headius I have run git bisect between 9.1.5.0 and 9.1.6.0 to find the commit that introduced the bug, here is my report:

  1. Last known commit without the bug:
commit b561339c1fd0f97d81dfabf409af501a35bb5fff
Author: Charles Oliver Nutter <headius@headius.com>
Date:   Thu Sep 29 15:26:03 2016 -0500

    Tidy up some excess whitespace.
  1. Bug introduced in 1b657df
commit 1b657df5dffe0892a0fc7ca269d3de18dc518531
Author: Charles Oliver Nutter <headius@headius.com>
Date:   Thu Sep 29 15:34:18 2016 -0500

    Mark DynScope methods used by jit with @JIT.

@headius I have run git bisect between 9.1.5.0 and 9.1.6.0 to find the commit that introduced the bug, here is my report:

  1. Last known commit without the bug:
commit b561339c1fd0f97d81dfabf409af501a35bb5fff
Author: Charles Oliver Nutter <headius@headius.com>
Date:   Thu Sep 29 15:26:03 2016 -0500

    Tidy up some excess whitespace.
  1. Bug introduced in 1b657df
commit 1b657df5dffe0892a0fc7ca269d3de18dc518531
Author: Charles Oliver Nutter <headius@headius.com>
Date:   Thu Sep 29 15:34:18 2016 -0500

    Mark DynScope methods used by jit with @JIT.
@kares

This comment has been minimized.

Show comment
Hide comment
@kares

kares Feb 1, 2017

Member

@aldrinmartoq believe its pretty much solid what is the cause ... whats not clear is why its happening
@mkristian I have a very subjective feeling that most of the time as I pushed to my fork j2ee was 💚

Member

kares commented Feb 1, 2017

@aldrinmartoq believe its pretty much solid what is the cause ... whats not clear is why its happening
@mkristian I have a very subjective feeling that most of the time as I pushed to my fork j2ee was 💚

@mkristian

This comment has been minimized.

Show comment
Hide comment
@mkristian

mkristian Feb 1, 2017

Member

@kares the last time I wanted to have a look why it is red I saw that even green tests produces stacktraces so at this time I decided to put it under 'allow-failures'. anyways it is on my TODO for this week ;)

Member

mkristian commented Feb 1, 2017

@kares the last time I wanted to have a look why it is red I saw that even green tests produces stacktraces so at this time I decided to put it under 'allow-failures'. anyways it is on my TODO for this week ;)

@andy-twosticks

This comment has been minimized.

Show comment
Hide comment
@andy-twosticks

andy-twosticks Feb 13, 2017

Same problem here. Except we have two tomcat instances, and it only does it on one of them...?

Same problem here. Except we have two tomcat instances, and it only does it on one of them...?

@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius Feb 13, 2017

Member

@aldrinmartoq Interesting! I'll have a look and see if I can come up with a theory.

Member

headius commented Feb 13, 2017

@aldrinmartoq Interesting! I'll have a look and see if I can come up with a theory.

@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius Feb 13, 2017

Member

@aldrinmartoq Yeah, the commits around that one don't seem likely to have caused this...so I find that bisect very confusing. Neither of the two commits you point out made any substantive changes to the code. The @JIT annotation is only informational metadata.

It still seems like there has to be another JRuby sneaking into some lower classloader, or one deployed application is leaking into the next. Perhaps you can run something like this against your JBoss instance and see what you find?

find . -name '*.jar' -exec 'jar tf {}' | grep StaticScope

Member

headius commented Feb 13, 2017

@aldrinmartoq Yeah, the commits around that one don't seem likely to have caused this...so I find that bisect very confusing. Neither of the two commits you point out made any substantive changes to the code. The @JIT annotation is only informational metadata.

It still seems like there has to be another JRuby sneaking into some lower classloader, or one deployed application is leaking into the next. Perhaps you can run something like this against your JBoss instance and see what you find?

find . -name '*.jar' -exec 'jar tf {}' | grep StaticScope

@andy-twosticks

This comment has been minimized.

Show comment
Hide comment
@andy-twosticks

andy-twosticks Feb 14, 2017

Is there any information I can provide that would help? Would it be better if I raised a seperate issue for my problem? The error message is basically the same, but under Tomcat, not JBoss.

(Still trying to work out why we get the problem on one server but not the other here, but I'm not very hopeful...)

Is there any information I can provide that would help? Would it be better if I raised a seperate issue for my problem? The error message is basically the same, but under Tomcat, not JBoss.

(Still trying to work out why we get the problem on one server but not the other here, but I'm not very hopeful...)

@andy-twosticks

This comment has been minimized.

Show comment
Hide comment
@andy-twosticks

andy-twosticks Feb 14, 2017

News: On Tomcat, the problem only occurs if multiple war files on the Tomcat server are using jRuby. If you have only one, everything is fine.

This is why we had one instance that worked and one that did not.

Our .war files here are being built with Warbler and there is no mucking about with shared jars. So something is leaking?


For the record, this is the error message I see (in /var/log/tomcat/localhost.yyyy.mm.dd.txt). It's almost identical to the one raised by the OP:

Feb 14, 2017 10:08:50 AM org.apache.catalina.core.ApplicationContext log
INFO: INFO: jruby 9.1.7.0 (2.3.1) 2017-01-11 68056ae OpenJDK 64-Bit Server VM 25.121-b13 on 1.8.0_121-b13 +jit [linux-x86_64]
Feb 14, 2017 10:08:50 AM org.apache.catalina.core.ApplicationContext log
INFO: INFO: using a shared (threadsafe!) runtime
Feb 14, 2017 10:08:50 AM org.apache.catalina.core.StandardContext listenerStart
SEVERE: Exception sending context initialized event to listener instance of class org.jruby.rack.RackServletContextListener
java.lang.ExceptionInInitializerError
        at org.jruby.runtime.ThreadContext.<init>(ThreadContext.java:214)
        at org.jruby.runtime.ThreadContext.newContext(ThreadContext.java:85)
        at org.jruby.internal.runtime.ThreadService.initMainThread(ThreadService.java:166)
        at org.jruby.Ruby.init(Ruby.java:1161)
        at org.jruby.Ruby.newInstance(Ruby.java:334)
        at org.jruby.rack.DefaultRackApplicationFactory.newRuntime(DefaultRackApplicationFactory.java:337)
        at org.jruby.rack.DefaultRackApplicationFactory$RackApplicationImpl.<init>(DefaultRackApplicationFactory.java:438)
        at org.jruby.rack.DefaultRackApplicationFactory.createApplication(DefaultRackApplicationFactory.java:426)
        at org.jruby.rack.DefaultRackApplicationFactory.newApplication(DefaultRackApplicationFactory.java:99)
        at org.jruby.rack.DefaultRackApplicationFactory.getApplication(DefaultRackApplicationFactory.java:113)
        at org.jruby.rack.SharedRackApplicationFactory.doInit(SharedRackApplicationFactory.java:34)
        at org.jruby.rack.RackApplicationFactoryDecorator.init(RackApplicationFactoryDecorator.java:100)
        at org.jruby.rack.RackServletContextListener.contextInitialized(RackServletContextListener.java:50)
        at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:5068)
        at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5584)
        at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:147)
        at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:899)
        at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:875)
        at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:652)
        at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1092)
        at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1984)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: BUG: could not initialize constructor handle
        at org.jruby.runtime.scope.ManyVarsDynamicScope.<clinit>(ManyVarsDynamicScope.java:39)
        ... 26 more

andy-twosticks commented Feb 14, 2017

News: On Tomcat, the problem only occurs if multiple war files on the Tomcat server are using jRuby. If you have only one, everything is fine.

This is why we had one instance that worked and one that did not.

Our .war files here are being built with Warbler and there is no mucking about with shared jars. So something is leaking?


For the record, this is the error message I see (in /var/log/tomcat/localhost.yyyy.mm.dd.txt). It's almost identical to the one raised by the OP:

Feb 14, 2017 10:08:50 AM org.apache.catalina.core.ApplicationContext log
INFO: INFO: jruby 9.1.7.0 (2.3.1) 2017-01-11 68056ae OpenJDK 64-Bit Server VM 25.121-b13 on 1.8.0_121-b13 +jit [linux-x86_64]
Feb 14, 2017 10:08:50 AM org.apache.catalina.core.ApplicationContext log
INFO: INFO: using a shared (threadsafe!) runtime
Feb 14, 2017 10:08:50 AM org.apache.catalina.core.StandardContext listenerStart
SEVERE: Exception sending context initialized event to listener instance of class org.jruby.rack.RackServletContextListener
java.lang.ExceptionInInitializerError
        at org.jruby.runtime.ThreadContext.<init>(ThreadContext.java:214)
        at org.jruby.runtime.ThreadContext.newContext(ThreadContext.java:85)
        at org.jruby.internal.runtime.ThreadService.initMainThread(ThreadService.java:166)
        at org.jruby.Ruby.init(Ruby.java:1161)
        at org.jruby.Ruby.newInstance(Ruby.java:334)
        at org.jruby.rack.DefaultRackApplicationFactory.newRuntime(DefaultRackApplicationFactory.java:337)
        at org.jruby.rack.DefaultRackApplicationFactory$RackApplicationImpl.<init>(DefaultRackApplicationFactory.java:438)
        at org.jruby.rack.DefaultRackApplicationFactory.createApplication(DefaultRackApplicationFactory.java:426)
        at org.jruby.rack.DefaultRackApplicationFactory.newApplication(DefaultRackApplicationFactory.java:99)
        at org.jruby.rack.DefaultRackApplicationFactory.getApplication(DefaultRackApplicationFactory.java:113)
        at org.jruby.rack.SharedRackApplicationFactory.doInit(SharedRackApplicationFactory.java:34)
        at org.jruby.rack.RackApplicationFactoryDecorator.init(RackApplicationFactoryDecorator.java:100)
        at org.jruby.rack.RackServletContextListener.contextInitialized(RackServletContextListener.java:50)
        at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:5068)
        at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5584)
        at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:147)
        at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:899)
        at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:875)
        at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:652)
        at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:1092)
        at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1984)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.RuntimeException: BUG: could not initialize constructor handle
        at org.jruby.runtime.scope.ManyVarsDynamicScope.<clinit>(ManyVarsDynamicScope.java:39)
        ... 26 more
@mwarnock

This comment has been minimized.

Show comment
Hide comment
@mwarnock

mwarnock Feb 20, 2017

By way of confirmation: I had the same error in wildfly 10.1.0 and jruby-jars 9.1.7.0. Reverting to jruby-jars 9.1.5.0 fixed the issue.

Thanks for all your hard work

By way of confirmation: I had the same error in wildfly 10.1.0 and jruby-jars 9.1.7.0. Reverting to jruby-jars 9.1.5.0 fixed the issue.

Thanks for all your hard work

@aldrinmartoq

This comment has been minimized.

Show comment
Hide comment
@aldrinmartoq

aldrinmartoq Feb 20, 2017

@headius I've tried your suggestion and it seems the jars are not left over between deploys.

Here is my reporte, please note that this same sequence works in jruby-9.1.5.0.

# 1. Start server
$ ./standalone.sh

# 2. Check for existing jruby jars (nothing)
$ find . -name '*.jar' -exec jar tf {} \; | grep StaticScope

# 3. Install app (it works fine)
$ cp app.war /jboss-eap-7.0/standalone/deployments/

# 4. Check for existing jruby jars
$ find . -name '*.jar' -exec jar tf {} \; | grep StaticScope
./standalone/tmp/vfs/deployment/deployment5f68b1284b65427e/jruby-core-9.1.8.0-SNAPSHOT-complete.jar-55128f7dd075c566/jruby-core-9.1.8.0-SNAPSHOT-complete.jar
org/jruby/parser/StaticScope$Type.class
org/jruby/parser/StaticScope.class
org/jruby/parser/StaticScopeFactory.class
./standalone/tmp/vfs/temp/tempcdf486b6cf96f53b/content-89d4787060a19efb/WEB-INF/gems/gems/jruby-jars-9.1.8.0.SNAPSHOT/lib/jruby-core-9.1.8.0-SNAPSHOT-complete.jar
org/jruby/parser/StaticScope$Type.class
org/jruby/parser/StaticScope.class
org/jruby/parser/StaticScopeFactory.class
./standalone/tmp/vfs/temp/tempcdf486b6cf96f53b/content-89d4787060a19efb/WEB-INF/lib/jruby-core-9.1.8.0-SNAPSHOT-complete.jar
org/jruby/parser/StaticScope$Type.class
org/jruby/parser/StaticScope.class
org/jruby/parser/StaticScopeFactory.class

# 5. Remove app
$ rm -f /jboss-eap-7.0/standalone/deployments/app.war

# 6. Check for existing jruby jars (none)
$ find . -name '*.jar' -exec jar tf {} \; | grep StaticScope

# 7. Install app again (it will fail)
$ cp app.war /jboss-eap-7.0/standalone/deployments/
$ tail server.log
16:28:17,742 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 85) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./gcu: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./gcu: java.lang.ExceptionInInitializerError
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: java.lang.ExceptionInInitializerError
	at org.jruby.runtime.ThreadContext.<init>(ThreadContext.java:214)
	at org.jruby.runtime.ThreadContext.newContext(ThreadContext.java:85)
	at org.jruby.internal.runtime.ThreadService.initMainThread(ThreadService.java:166)
	at org.jruby.Ruby.init(Ruby.java:1164)
	at org.jruby.Ruby.newInstance(Ruby.java:338)
	at org.jruby.rack.DefaultRackApplicationFactory.newRuntime(DefaultRackApplicationFactory.java:337)
	at org.jruby.rack.DefaultRackApplicationFactory$RackApplicationImpl.<init>(DefaultRackApplicationFactory.java:438)
	at org.jruby.rack.DefaultRackApplicationFactory.createApplication(DefaultRackApplicationFactory.java:426)
	at org.jruby.rack.DefaultRackApplicationFactory.newApplication(DefaultRackApplicationFactory.java:99)
	at org.jruby.rack.DefaultRackApplicationFactory.getApplication(DefaultRackApplicationFactory.java:113)
	at org.jruby.rack.SharedRackApplicationFactory.doInit(SharedRackApplicationFactory.java:34)
	at org.jruby.rack.RackApplicationFactoryDecorator.init(RackApplicationFactoryDecorator.java:100)
	at org.jruby.rack.RackServletContextListener.contextInitialized(RackServletContextListener.java:50)
	at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187)
	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:198)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
	... 6 more
Caused by: java.lang.RuntimeException: BUG: could not initialize constructor handle
	at org.jruby.runtime.scope.ManyVarsDynamicScope.<clinit>(ManyVarsDynamicScope.java:39)
	... 23 more
Caused by: java.lang.IllegalAccessException: no such constructor: org.jruby.runtime.scope.ManyVarsDynamicScope.<init>(StaticScope,DynamicScope)void/newInvokeSpecial
	at java.lang.invoke.MemberName.makeAccessException(MemberName.java:867)
	at java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:1003)
	at java.lang.invoke.MethodHandles$Lookup.resolveOrFail(MethodHandles.java:1386)
	at java.lang.invoke.MethodHandles$Lookup.findConstructor(MethodHandles.java:924)
	at org.jruby.runtime.scope.ManyVarsDynamicScope.<clinit>(ManyVarsDynamicScope.java:36)
	... 23 more
Caused by: java.lang.LinkageError: loader constraint violation: when resolving method "org.jruby.runtime.scope.ManyVarsDynamicScope.<init>(Lorg/jruby/parser/StaticScope;Lorg/jruby/runtime/DynamicScope;)V" the class loader (instance of <bootloader>) of the current class, java/lang/Object, and the class loader (instance of org/jboss/modules/ModuleClassLoader) for the method's defining class, org/jruby/runtime/scope/ManyVarsDynamicScope, have different Class objects for the type org/jruby/parser/StaticScope used in the signature
	at java.lang.invoke.MethodHandleNatives.resolve(Native Method)
	at java.lang.invoke.MemberName$Factory.resolve(MemberName.java:975)
	at java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:1000)
	... 26 more

# 8. Check for existing jruby jars (please note the path is different)
$ find . -name '*.jar' -exec jar tf {} \; | grep StaticScope
./standalone/tmp/vfs/deployment/deployment5f68b1284b65427e/jruby-core-9.1.8.0-SNAPSHOT-complete.jar-9c14eaa135c5bf59/jruby-core-9.1.8.0-SNAPSHOT-complete.jar
org/jruby/parser/StaticScope$Type.class
org/jruby/parser/StaticScope.class
org/jruby/parser/StaticScopeFactory.class
./standalone/tmp/vfs/temp/tempcdf486b6cf96f53b/content-eb3c8b4bdb93aaa/WEB-INF/gems/gems/jruby-jars-9.1.8.0.SNAPSHOT/lib/jruby-core-9.1.8.0-SNAPSHOT-complete.jar
org/jruby/parser/StaticScope$Type.class
org/jruby/parser/StaticScope.class
org/jruby/parser/StaticScopeFactory.class
./standalone/tmp/vfs/temp/tempcdf486b6cf96f53b/content-eb3c8b4bdb93aaa/WEB-INF/lib/jruby-core-9.1.8.0-SNAPSHOT-complete.jar
org/jruby/parser/StaticScope$Type.class
org/jruby/parser/StaticScope.class
org/jruby/parser/StaticScopeFactory.class

@headius I've tried your suggestion and it seems the jars are not left over between deploys.

Here is my reporte, please note that this same sequence works in jruby-9.1.5.0.

# 1. Start server
$ ./standalone.sh

# 2. Check for existing jruby jars (nothing)
$ find . -name '*.jar' -exec jar tf {} \; | grep StaticScope

# 3. Install app (it works fine)
$ cp app.war /jboss-eap-7.0/standalone/deployments/

# 4. Check for existing jruby jars
$ find . -name '*.jar' -exec jar tf {} \; | grep StaticScope
./standalone/tmp/vfs/deployment/deployment5f68b1284b65427e/jruby-core-9.1.8.0-SNAPSHOT-complete.jar-55128f7dd075c566/jruby-core-9.1.8.0-SNAPSHOT-complete.jar
org/jruby/parser/StaticScope$Type.class
org/jruby/parser/StaticScope.class
org/jruby/parser/StaticScopeFactory.class
./standalone/tmp/vfs/temp/tempcdf486b6cf96f53b/content-89d4787060a19efb/WEB-INF/gems/gems/jruby-jars-9.1.8.0.SNAPSHOT/lib/jruby-core-9.1.8.0-SNAPSHOT-complete.jar
org/jruby/parser/StaticScope$Type.class
org/jruby/parser/StaticScope.class
org/jruby/parser/StaticScopeFactory.class
./standalone/tmp/vfs/temp/tempcdf486b6cf96f53b/content-89d4787060a19efb/WEB-INF/lib/jruby-core-9.1.8.0-SNAPSHOT-complete.jar
org/jruby/parser/StaticScope$Type.class
org/jruby/parser/StaticScope.class
org/jruby/parser/StaticScopeFactory.class

# 5. Remove app
$ rm -f /jboss-eap-7.0/standalone/deployments/app.war

# 6. Check for existing jruby jars (none)
$ find . -name '*.jar' -exec jar tf {} \; | grep StaticScope

# 7. Install app again (it will fail)
$ cp app.war /jboss-eap-7.0/standalone/deployments/
$ tail server.log
16:28:17,742 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 85) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./gcu: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./gcu: java.lang.ExceptionInInitializerError
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:85)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at java.lang.Thread.run(Thread.java:745)
	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: java.lang.ExceptionInInitializerError
	at org.jruby.runtime.ThreadContext.<init>(ThreadContext.java:214)
	at org.jruby.runtime.ThreadContext.newContext(ThreadContext.java:85)
	at org.jruby.internal.runtime.ThreadService.initMainThread(ThreadService.java:166)
	at org.jruby.Ruby.init(Ruby.java:1164)
	at org.jruby.Ruby.newInstance(Ruby.java:338)
	at org.jruby.rack.DefaultRackApplicationFactory.newRuntime(DefaultRackApplicationFactory.java:337)
	at org.jruby.rack.DefaultRackApplicationFactory$RackApplicationImpl.<init>(DefaultRackApplicationFactory.java:438)
	at org.jruby.rack.DefaultRackApplicationFactory.createApplication(DefaultRackApplicationFactory.java:426)
	at org.jruby.rack.DefaultRackApplicationFactory.newApplication(DefaultRackApplicationFactory.java:99)
	at org.jruby.rack.DefaultRackApplicationFactory.getApplication(DefaultRackApplicationFactory.java:113)
	at org.jruby.rack.SharedRackApplicationFactory.doInit(SharedRackApplicationFactory.java:34)
	at org.jruby.rack.RackApplicationFactoryDecorator.init(RackApplicationFactoryDecorator.java:100)
	at org.jruby.rack.RackServletContextListener.contextInitialized(RackServletContextListener.java:50)
	at io.undertow.servlet.core.ApplicationListeners.contextInitialized(ApplicationListeners.java:187)
	at io.undertow.servlet.core.DeploymentManagerImpl.deploy(DeploymentManagerImpl.java:198)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.startContext(UndertowDeploymentService.java:100)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$1.run(UndertowDeploymentService.java:82)
	... 6 more
Caused by: java.lang.RuntimeException: BUG: could not initialize constructor handle
	at org.jruby.runtime.scope.ManyVarsDynamicScope.<clinit>(ManyVarsDynamicScope.java:39)
	... 23 more
Caused by: java.lang.IllegalAccessException: no such constructor: org.jruby.runtime.scope.ManyVarsDynamicScope.<init>(StaticScope,DynamicScope)void/newInvokeSpecial
	at java.lang.invoke.MemberName.makeAccessException(MemberName.java:867)
	at java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:1003)
	at java.lang.invoke.MethodHandles$Lookup.resolveOrFail(MethodHandles.java:1386)
	at java.lang.invoke.MethodHandles$Lookup.findConstructor(MethodHandles.java:924)
	at org.jruby.runtime.scope.ManyVarsDynamicScope.<clinit>(ManyVarsDynamicScope.java:36)
	... 23 more
Caused by: java.lang.LinkageError: loader constraint violation: when resolving method "org.jruby.runtime.scope.ManyVarsDynamicScope.<init>(Lorg/jruby/parser/StaticScope;Lorg/jruby/runtime/DynamicScope;)V" the class loader (instance of <bootloader>) of the current class, java/lang/Object, and the class loader (instance of org/jboss/modules/ModuleClassLoader) for the method's defining class, org/jruby/runtime/scope/ManyVarsDynamicScope, have different Class objects for the type org/jruby/parser/StaticScope used in the signature
	at java.lang.invoke.MethodHandleNatives.resolve(Native Method)
	at java.lang.invoke.MemberName$Factory.resolve(MemberName.java:975)
	at java.lang.invoke.MemberName$Factory.resolveOrFail(MemberName.java:1000)
	... 26 more

# 8. Check for existing jruby jars (please note the path is different)
$ find . -name '*.jar' -exec jar tf {} \; | grep StaticScope
./standalone/tmp/vfs/deployment/deployment5f68b1284b65427e/jruby-core-9.1.8.0-SNAPSHOT-complete.jar-9c14eaa135c5bf59/jruby-core-9.1.8.0-SNAPSHOT-complete.jar
org/jruby/parser/StaticScope$Type.class
org/jruby/parser/StaticScope.class
org/jruby/parser/StaticScopeFactory.class
./standalone/tmp/vfs/temp/tempcdf486b6cf96f53b/content-eb3c8b4bdb93aaa/WEB-INF/gems/gems/jruby-jars-9.1.8.0.SNAPSHOT/lib/jruby-core-9.1.8.0-SNAPSHOT-complete.jar
org/jruby/parser/StaticScope$Type.class
org/jruby/parser/StaticScope.class
org/jruby/parser/StaticScopeFactory.class
./standalone/tmp/vfs/temp/tempcdf486b6cf96f53b/content-eb3c8b4bdb93aaa/WEB-INF/lib/jruby-core-9.1.8.0-SNAPSHOT-complete.jar
org/jruby/parser/StaticScope$Type.class
org/jruby/parser/StaticScope.class
org/jruby/parser/StaticScopeFactory.class
@mskutin

This comment has been minimized.

Show comment
Hide comment
@mskutin

mskutin Feb 21, 2017

Get into the similar problem with JRuby [9.0.5.0, 9.1.5.0, 9.1.7.0] and Weblogic 12.
Deployed via:

  • web console:
    image
  • Weblogic Deployer:
  1. undeploy:
    java weblogic.Deployer -adminurl t3://weblogic:8001 -user user -password password -undeploy -name my_war -targets
    <21 Feb, 2017 10:49:30 AM SGT> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiating undeploy operation for application, my_war [archive: null], to myWebServer .>
    Task 1 initiated: [Deployer:149026]remove application my_war on myWebServer.
    Task 1 completed: [Deployer:149026]remove application my_war on myWebServer.
    Target state: undeploy completed on Server myWebServer
  2. deploy:
    java weblogic.Deployer -adminurl t3://weblogic:8001 -user user -password password -deploy /artifact_path/my_war.war -remote -upload
    <21 Feb, 2017 10:50:03 AM SGT> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiating deploy operation for application, my_war [archive: /artifact_path/my_war.war], to configured targets.>
    Task 2 initiated: [Deployer:149026]deploy application my_war on myWebServer.
    Task 2 failed: [Deployer:149026]deploy application my_war on myWebServer.
    Target state: deploy failed on Server myWebServer
    java.lang.RuntimeException: BUG: could not initialize constructor handle
  3. redeploy:
    java weblogic.Deployer -adminurl t3://weblogic:8001 -user user -password password -redeploy -name my_war -targets myWebServer
    <21 Feb, 2017 10:51:07 AM SGT> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiating redeploy operation for application, my_war [archive: null], to myWebServer .>
    Task 3 initiated: [Deployer:149026]redeploy application my_war on myWebServer.
    Task 3 failed: [Deployer:149026]redeploy application my_war on myWebServer.
    Target state: redeploy failed on Server myWebServer
    java.lang.RuntimeException: BUG: could not initialize constructor handle
  • jruby 9.1.5.0 (2.3.1) 2016-09-07 036ce39 Java HotSpot(TM) 64-Bit Server VM 25.111-b14 on 1.8.0_111-b14 +jit [linux-x86_64]

  • jruby 9.0.5.0 (2.2.3) 2016-01-26 7bee00d Java HotSpot(TM) 64-Bit Server VM 25.92-b14 on 1.8.0_92-b14 +jit [darwin-x86_64]

  • WebLogic Server 12.2.1.2.0

  • Rails 4.2.7, warbler 2.0.3

  • Linux 3.13.0-95-generic #142-Ubuntu SMP Fri Aug 12 17:00:09 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

  • Darwin 16.4.0 Darwin Kernel Version 16.4.0: Thu Dec 22 22:53:21 PST 2016; root:xnu-3789.41.3~3/RELEASE_X86_64 x86_64

<Feb 21, 2017, 2:51:20,921 AM UTC> <Error> <Deployer> <BEA-149202> <Encountered an exception while attempting to commit the 9 task for the application "my_war" on [partition-name: DOMAIN].>
<Feb 21, 2017, 2:51:20,928 AM UTC> <Warning> <Deployer> <BEA-149004> <Failures were detected while initiating redeploy task for application "my_war".>
<Feb 21, 2017, 2:51:20,928 AM UTC> <Warning> <Deployer> <BEA-149078> <Stack trace for message 149004
weblogic.application.ModuleException: java.lang.RuntimeException: BUG: could not initialize constructor handle
        at weblogic.application.internal.ExtensibleModuleWrapper.start(ExtensibleModuleWrapper.java:140)
        at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:124)
        at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:233)
        at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:228)
        at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:45)
        Truncated. see log file for complete stacktrace
Caused By: java.lang.RuntimeException: BUG: could not initialize constructor handle
        at org.jruby.runtime.scope.ManyVarsDynamicScope.<clinit>(ManyVarsDynamicScope.java:39)
        at org.jruby.runtime.ThreadContext.<init>(ThreadContext.java:214)
        at org.jruby.runtime.ThreadContext.newContext(ThreadContext.java:85)
        at org.jruby.internal.runtime.ThreadService.initMainThread(ThreadService.java:166)
        at org.jruby.Ruby.init(Ruby.java:1161)
        Truncated. see log file for complete stacktrace

mskutin commented Feb 21, 2017

Get into the similar problem with JRuby [9.0.5.0, 9.1.5.0, 9.1.7.0] and Weblogic 12.
Deployed via:

  • web console:
    image
  • Weblogic Deployer:
  1. undeploy:
    java weblogic.Deployer -adminurl t3://weblogic:8001 -user user -password password -undeploy -name my_war -targets
    <21 Feb, 2017 10:49:30 AM SGT> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiating undeploy operation for application, my_war [archive: null], to myWebServer .>
    Task 1 initiated: [Deployer:149026]remove application my_war on myWebServer.
    Task 1 completed: [Deployer:149026]remove application my_war on myWebServer.
    Target state: undeploy completed on Server myWebServer
  2. deploy:
    java weblogic.Deployer -adminurl t3://weblogic:8001 -user user -password password -deploy /artifact_path/my_war.war -remote -upload
    <21 Feb, 2017 10:50:03 AM SGT> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiating deploy operation for application, my_war [archive: /artifact_path/my_war.war], to configured targets.>
    Task 2 initiated: [Deployer:149026]deploy application my_war on myWebServer.
    Task 2 failed: [Deployer:149026]deploy application my_war on myWebServer.
    Target state: deploy failed on Server myWebServer
    java.lang.RuntimeException: BUG: could not initialize constructor handle
  3. redeploy:
    java weblogic.Deployer -adminurl t3://weblogic:8001 -user user -password password -redeploy -name my_war -targets myWebServer
    <21 Feb, 2017 10:51:07 AM SGT> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiating redeploy operation for application, my_war [archive: null], to myWebServer .>
    Task 3 initiated: [Deployer:149026]redeploy application my_war on myWebServer.
    Task 3 failed: [Deployer:149026]redeploy application my_war on myWebServer.
    Target state: redeploy failed on Server myWebServer
    java.lang.RuntimeException: BUG: could not initialize constructor handle
  • jruby 9.1.5.0 (2.3.1) 2016-09-07 036ce39 Java HotSpot(TM) 64-Bit Server VM 25.111-b14 on 1.8.0_111-b14 +jit [linux-x86_64]

  • jruby 9.0.5.0 (2.2.3) 2016-01-26 7bee00d Java HotSpot(TM) 64-Bit Server VM 25.92-b14 on 1.8.0_92-b14 +jit [darwin-x86_64]

  • WebLogic Server 12.2.1.2.0

  • Rails 4.2.7, warbler 2.0.3

  • Linux 3.13.0-95-generic #142-Ubuntu SMP Fri Aug 12 17:00:09 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

  • Darwin 16.4.0 Darwin Kernel Version 16.4.0: Thu Dec 22 22:53:21 PST 2016; root:xnu-3789.41.3~3/RELEASE_X86_64 x86_64

<Feb 21, 2017, 2:51:20,921 AM UTC> <Error> <Deployer> <BEA-149202> <Encountered an exception while attempting to commit the 9 task for the application "my_war" on [partition-name: DOMAIN].>
<Feb 21, 2017, 2:51:20,928 AM UTC> <Warning> <Deployer> <BEA-149004> <Failures were detected while initiating redeploy task for application "my_war".>
<Feb 21, 2017, 2:51:20,928 AM UTC> <Warning> <Deployer> <BEA-149078> <Stack trace for message 149004
weblogic.application.ModuleException: java.lang.RuntimeException: BUG: could not initialize constructor handle
        at weblogic.application.internal.ExtensibleModuleWrapper.start(ExtensibleModuleWrapper.java:140)
        at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:124)
        at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:233)
        at weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:228)
        at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:45)
        Truncated. see log file for complete stacktrace
Caused By: java.lang.RuntimeException: BUG: could not initialize constructor handle
        at org.jruby.runtime.scope.ManyVarsDynamicScope.<clinit>(ManyVarsDynamicScope.java:39)
        at org.jruby.runtime.ThreadContext.<init>(ThreadContext.java:214)
        at org.jruby.runtime.ThreadContext.newContext(ThreadContext.java:85)
        at org.jruby.internal.runtime.ThreadService.initMainThread(ThreadService.java:166)
        at org.jruby.Ruby.init(Ruby.java:1161)
        Truncated. see log file for complete stacktrace
@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius Feb 23, 2017

Member

@mskutin You are seeing this happen with 9.0.5.0 and 9.1.5.0 as well as later releases? That doesn't seem to fit other folks saying that 9.1.5.0 works ok.

@mwarnock @aldrinmartoq Ok. We need a way to reproduce this. I'm very confused where the duplicate class is coming from.

So a few suggestions:

  1. If one of you can put together a dummy app and push it to github with instructions to run it, that would be a great help. I'm guessing at this stuff from your reports and I don't feel like we're finding the issue.
  2. Try running jboss/wildfly with the JVM flag -verbose:class to show all classes being loaded. Grep for ManyVarsDynamicScope and see what you can see.

Given that it doesn't look like there's a duplicate coming in from the filesystem or system-level classloader, my current theory is something unusual happening with JBoss classloading. Another possibility is that a thread context classloader is getting shared across deploys and causing the same classes to conflict with each other.

@bbrowning This isn't Torquebox, but do you have any ideas here? You've worked at this level of JBoss/WildFly more than me.

Member

headius commented Feb 23, 2017

@mskutin You are seeing this happen with 9.0.5.0 and 9.1.5.0 as well as later releases? That doesn't seem to fit other folks saying that 9.1.5.0 works ok.

@mwarnock @aldrinmartoq Ok. We need a way to reproduce this. I'm very confused where the duplicate class is coming from.

So a few suggestions:

  1. If one of you can put together a dummy app and push it to github with instructions to run it, that would be a great help. I'm guessing at this stuff from your reports and I don't feel like we're finding the issue.
  2. Try running jboss/wildfly with the JVM flag -verbose:class to show all classes being loaded. Grep for ManyVarsDynamicScope and see what you can see.

Given that it doesn't look like there's a duplicate coming in from the filesystem or system-level classloader, my current theory is something unusual happening with JBoss classloading. Another possibility is that a thread context classloader is getting shared across deploys and causing the same classes to conflict with each other.

@bbrowning This isn't Torquebox, but do you have any ideas here? You've worked at this level of JBoss/WildFly more than me.

@mskutin

This comment has been minimized.

Show comment
Hide comment
@mskutin

mskutin Feb 23, 2017

@headius Hey, I forgot to write that jruby-jars was absent in the Gemfile, so adding jruby-jars ~> 9.1.5.0 made me a trick.

mskutin commented Feb 23, 2017

@headius Hey, I forgot to write that jruby-jars was absent in the Gemfile, so adding jruby-jars ~> 9.1.5.0 made me a trick.

@k77ch7

This comment has been minimized.

Show comment
Hide comment
@k77ch7

k77ch7 Feb 24, 2017

Contributor

Is this related to #4312 ? The same exception appears in both cases.

Contributor

k77ch7 commented Feb 24, 2017

Is this related to #4312 ? The same exception appears in both cases.

@thomasoberle

This comment has been minimized.

Show comment
Hide comment
@thomasoberle

thomasoberle Feb 24, 2017

Rails dummy app to reproduce
https://github.com/thomasoberle/wardemo

Instruction in README.md

create the war file:
jruby -S rake assets:precompile
jruby -S warble war

install a wildfly 10.1 / startup parameters

JBOSS_HOME="{path}/wildfly"

JBOSS_LOG_FILE="${JBOSS_HOME}/standalone/log/jboss_startup.log"

SHORT_DATE=$(date +"%Y%m%d%H%M")
export RAILS_ENV=development
export JAVA="{path}/jdk/bin/java"
export JAVA_OPTS="-server -Xms512m -Xmx3g -d64 -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=1g -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true"
STARTUP_PARAMS="-b=0.0.0.0 -bmanagement=0.0.0.0 --server-config=standalone.xml"
$JBOSS_HOME/bin/standalone.sh

to Reproduce the error: Unable to re-deploy rails app (java.lang.RuntimeException: BUG: could not initialize constructor handle) #4442

Deploy the app and replace or remove the app and deploy again

Rails dummy app to reproduce
https://github.com/thomasoberle/wardemo

Instruction in README.md

create the war file:
jruby -S rake assets:precompile
jruby -S warble war

install a wildfly 10.1 / startup parameters

JBOSS_HOME="{path}/wildfly"

JBOSS_LOG_FILE="${JBOSS_HOME}/standalone/log/jboss_startup.log"

SHORT_DATE=$(date +"%Y%m%d%H%M")
export RAILS_ENV=development
export JAVA="{path}/jdk/bin/java"
export JAVA_OPTS="-server -Xms512m -Xmx3g -d64 -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=1g -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true"
STARTUP_PARAMS="-b=0.0.0.0 -bmanagement=0.0.0.0 --server-config=standalone.xml"
$JBOSS_HOME/bin/standalone.sh

to Reproduce the error: Unable to re-deploy rails app (java.lang.RuntimeException: BUG: could not initialize constructor handle) #4442

Deploy the app and replace or remove the app and deploy again

@headius

This comment has been minimized.

Show comment
Hide comment
@headius

headius Feb 24, 2017

Member

I believe @k77ch7 is right that this is fixed by #4312, and I have merged that for JRuby 9.1.8.0.

In #4312, @shirosaki discovered (and I have reproduced) a separate issue with jnr-ffi segfaulting in its finalizer. I will investigate that now.

Member

headius commented Feb 24, 2017

I believe @k77ch7 is right that this is fixed by #4312, and I have merged that for JRuby 9.1.8.0.

In #4312, @shirosaki discovered (and I have reproduced) a separate issue with jnr-ffi segfaulting in its finalizer. I will investigate that now.

@mwarnock

This comment has been minimized.

Show comment
Hide comment
@mwarnock

mwarnock Feb 27, 2017

Thanks guys! Sorry to be entirely unhelpful, I've been sick the last 4 days.

Thanks guys! Sorry to be entirely unhelpful, I've been sick the last 4 days.

@remofritzsche

This comment has been minimized.

Show comment
Hide comment
@remofritzsche

remofritzsche May 23, 2017

Thank you guys a bunch! For the record: This fixed our issue described in this SO post.

Thank you guys a bunch! For the record: This fixed our issue described in this SO post.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment