[JBoss JIRA] (JBJCA-1357) TransactionSynchronizer registered as interposed synchronization leads to ordering issue when using hibernate
by Alexander Pinske (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1357?page=com.atlassian.jira.plugin... ]
Alexander Pinske commented on JBJCA-1357:
-----------------------------------------
I attached a test case that reproduces the issue. Run with "mvn clean test".
> TransactionSynchronizer registered as interposed synchronization leads to ordering issue when using hibernate
> -------------------------------------------------------------------------------------------------------------
>
> Key: JBJCA-1357
> URL: https://issues.jboss.org/browse/JBJCA-1357
> Project: IronJacamar
> Issue Type: Bug
> Affects Versions: 1.4.5
> Reporter: Alexander Pinske
> Attachments: jca-hibernate.zip
>
>
> The TransactionSynchronizer (to cleanup connections) is registered as an interposed synchronization. Hibernate also registers its synchronization (to close the underlying JDBC connection handle) as interposed.
> This leads to undefined ordering, which in my case runs the JCA Synch before the Hibernate Synch. This leads to a log of IJ000316 and the connection being killed.
> I think that platform specific cleanup should be executed after all application level synchronization have run, therefore it should be registered with the TM (not the TSR).
> http://www.ironjacamar.org/doc/roadto12/txtracking.html describes this as an application misbehaviour. But I don't think the application has any means of controlling the ordering in this scenario.
> If I do not provide a TSR to the TransactionIntegrationImpl (which would lead to the registration of the TransactionSynchronizer via TransactionManager - thus non-interposed) has the problem that AbstractPool uses the TSR to check if a transaction is actually in progress.
> I don't know if my rationale is correct. Could you please comment on the issue?
> Thanks!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (JASSIST-270) Error loading class only available to bootstrap loader with jboss7+ and javassist 3.22
by Patson Luk (JIRA)
[ https://issues.jboss.org/browse/JASSIST-270?page=com.atlassian.jira.plugi... ]
Patson Luk commented on JASSIST-270:
------------------------------------
Many thanks for quick reply and suggestion!
I have tried your fix and it works on:
Tomcat 9 / JDK 8
Tomcat 9 / JDK 9
Wildfly 11 / JDK 8
But it does not work on
Wildfly 11 / JDK 9
The problem (which i mostly think is on Wildfly side) is that the Context Class Loader for wildfly - jboss module classloader(Module "org.jboss.as.standalone:main"), cannot load classes provided via Boot-Class-Path entry in MANIFEST.MF which is made available to bootstrap classloader.
Therefore my workaround is to use the "LoaderClassPath(ClassLoader.getSystemClassLoader())", which in wildfly is the "jdk.internal.loader.ClassLoaders$AppClassLoader" that can actually load bootstrap classes.
I probably need to look deeper into the jdk 9 module/class loading changes to find the right fix.
As for javassist side, i'm wondering what exactly should `appendSystemPath` do. Should classes available to bootstrap classloader be considered as a part of the "System path"? If so, some context class loader in jdk 9 (like the jboss/wildfly one) might not have access to bootstrap classes.
> Error loading class only available to bootstrap loader with jboss7+ and javassist 3.22
> --------------------------------------------------------------------------------------
>
> Key: JASSIST-270
> URL: https://issues.jboss.org/browse/JASSIST-270
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.22.0-GA
> Environment: oracle JDK 1.8.0_40
> jboss 7, wildfly 8, wildfly 9, wildfly 10
> Reporter: Patson Luk
> Assignee: Shigeru Chiba
>
> h3. Description
> After upgrading our agent from javassist 3.21 to 3.22, we started observing class loading problem during injection of code
> {{CannotCompileException: [source error] no such class: test.TestClass}}
> h3. Setup
> # Our agent inject a piece of code with reference to class `test.TestClass`
> # `test.TestClass` is provided by adding Boot-Class-Path entry in MANIFEST.MF, for example : Boot-Class-Path: ./ (with relative path, which we put the class binary `test.TestClass.class` within "test" folder relative to the agent JAR)
> # When obtaining the classpool, we always call `ClassPool.appendSystemPath()` such that `test.TestClass` available to bootstrap classloader will be loaded properly in all situations
> # Start Jboss 7 or any wildfly with `javaagent` that triggers the code injection, we will then observe the exception mentioned. Such a problem does not exist in version 3.21
> h3. Cause
> With some drill down into the source code, it appears that this [change|https://github.com/jboss-javassist/javassist/commit/778c463e5aa179...] in 3.22 combined with how jboss loads classes with its module class loader trigger the problem
> The steps are:
> # JBoss tries to load a class that triggers transformation, the javasist classpool used to load the class has a reference to the "module classloader" provided by JBoss + our `ClassPool.appendSystemPath()` call, which in 3.22, appends a LoaderClassPath of the thread's Context classloader, which is also a jboss module classloader (Module "org.jboss.as.standalone:main")
> # The injected code references class `test.TestClass`
> # `ClassPool.find` tries to use all the `ClassPath` to load `test.TestClass`, which they are both JBoss's "module classloader". Unfortunately, neither of those loaders can load the `test.TestClass` which is available to bootstrap loader
> # Throws the CannotCompileException exception as the referenced class in injected code cannot be loaded
> Take note that this worked in 3.21 as `appendSystemPath` appends the `ClassClassPath` intead of a `LoaderClassPath` with the context class loader.
> As a workaround, we added
> {code:java}
> if (ClassLoader.getSystemClassLoader() != null) {
> classPool.appendClassPath(new LoaderClassPath(ClassLoader.getSystemClassLoader()));
> } else {
> classPool.appendClassPath(new ClassClassPath(Object.class));
> }
> {code}
> on top of `classPool.appendSystemPath()` and it no longer complains about class loading problem for jdk 8 and jdk 9.
> -However, wildfly 10 + jdk 9 actually prints a warning `WARNING: An illegal reflective access operation has occurred`, but this probably is some other issues to be sorted out...- Not an issue of javaagent/javassist, as this same warning is shown even w/o agent
> Sorry about the long post. I honestly do not know whether this should be considered as a bug as all. As the name `appendSystemPath` somehow suggests to me that a class available to bootstrap classloader should be taken care of (is it considered part of the "system path"?), but i might be totally mistaken...
> Many thanks for your attention!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (JBJCA-1357) TransactionSynchronizer registered as interposed synchronization leads to ordering issue when using hibernate
by Alexanderke Pinske (JIRA)
Alexanderke Pinske created JBJCA-1357:
-----------------------------------------
Summary: TransactionSynchronizer registered as interposed synchronization leads to ordering issue when using hibernate
Key: JBJCA-1357
URL: https://issues.jboss.org/browse/JBJCA-1357
Project: IronJacamar
Issue Type: Bug
Affects Versions: 1.4.5
Reporter: Alexanderke Pinske
The TransactionSynchronizer (to cleanup connections) is registered as an interposed synchronization. Hibernate also registers its synchronization (to close the underlying JDBC connection handle) as interposed.
This leads to undefined ordering, which in my case runs the JCA Synch before the Hibernate Synch. This leads to a log of IJ000316 and the connection being killed.
I think that platform specific cleanup should be executed after all application level synchronization have run, therefore it should be registered with the TM (not the TSR).
http://www.ironjacamar.org/doc/roadto12/txtracking.html describes this as an application misbehaviour. But I don't think the application has any means of controlling the ordering in this scenario.
If I do not provide a TSR to the TransactionIntegrationImpl (which would lead to the registration of the TransactionSynchronizer via TransactionManager - thus non-interposed) has the problem that AbstractPool uses the TSR to check if a transaction is actually in progress.
I don't know if my rationale is correct. Could you please comment on the issue?
Thanks!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (JASSIST-270) Error loading class only available to bootstrap loader with jboss7+ and javassist 3.22
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-270?page=com.atlassian.jira.plugi... ]
Shigeru Chiba edited comment on JASSIST-270 at 10/24/17 2:31 PM:
-----------------------------------------------------------------
Thank you for drilling down the problem!
This is a sort of bug caused by the last-minutes hassle due to jigsaw.
It seems that the basic behavior of class loading is not compatible between Java 9 and earlier ones.
My suggestion to fix this bug is:
{{
if (javassist.bytecode.ClassFile.MAJOR_VERSION < javassist.bytecode.ClassFile.JAVA_9) {
return appendClassPath(new ClassClassPath());
}
else {
ClassLoader cl = Thread.currentThread().getContextClassLoader();
return appendClassPath(new LoaderClassPath(cl, true));
}
}}
Does this work with Java 8 and wildfly?
was (Author: chiba):
Thank you for drilling down the problem!
This is a sort of bug caused by the last-minutes hassle due to jigsaw.
It seems that the basic behavior of class loading is not compatible between Java 9 and earlier ones.
My suggestion to fix this bug is:
{{if (javassist.bytecode.ClassFile.MAJOR_VERSION < javassist.bytecode.ClassFile.JAVA_9) {
return appendClassPath(new ClassClassPath());
}
else {
ClassLoader cl = Thread.currentThread().getContextClassLoader();
return appendClassPath(new LoaderClassPath(cl, true));
}}}
Does this work with Java 8 and wildfly?
> Error loading class only available to bootstrap loader with jboss7+ and javassist 3.22
> --------------------------------------------------------------------------------------
>
> Key: JASSIST-270
> URL: https://issues.jboss.org/browse/JASSIST-270
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.22.0-GA
> Environment: oracle JDK 1.8.0_40
> jboss 7, wildfly 8, wildfly 9, wildfly 10
> Reporter: Patson Luk
> Assignee: Shigeru Chiba
>
> h3. Description
> After upgrading our agent from javassist 3.21 to 3.22, we started observing class loading problem during injection of code
> {{CannotCompileException: [source error] no such class: test.TestClass}}
> h3. Setup
> # Our agent inject a piece of code with reference to class `test.TestClass`
> # `test.TestClass` is provided by adding Boot-Class-Path entry in MANIFEST.MF, for example : Boot-Class-Path: ./ (with relative path, which we put the class binary `test.TestClass.class` within "test" folder relative to the agent JAR)
> # When obtaining the classpool, we always call `ClassPool.appendSystemPath()` such that `test.TestClass` available to bootstrap classloader will be loaded properly in all situations
> # Start Jboss 7 or any wildfly with `javaagent` that triggers the code injection, we will then observe the exception mentioned. Such a problem does not exist in version 3.21
> h3. Cause
> With some drill down into the source code, it appears that this [change|https://github.com/jboss-javassist/javassist/commit/778c463e5aa179...] in 3.22 combined with how jboss loads classes with its module class loader trigger the problem
> The steps are:
> # JBoss tries to load a class that triggers transformation, the javasist classpool used to load the class has a reference to the "module classloader" provided by JBoss + our `ClassPool.appendSystemPath()` call, which in 3.22, appends a LoaderClassPath of the thread's Context classloader, which is also a jboss module classloader (Module "org.jboss.as.standalone:main")
> # The injected code references class `test.TestClass`
> # `ClassPool.find` tries to use all the `ClassPath` to load `test.TestClass`, which they are both JBoss's "module classloader". Unfortunately, neither of those loaders can load the `test.TestClass` which is available to bootstrap loader
> # Throws the CannotCompileException exception as the referenced class in injected code cannot be loaded
> Take note that this worked in 3.21 as `appendSystemPath` appends the `ClassClassPath` intead of a `LoaderClassPath` with the context class loader.
> As a workaround, we added
> {code:java}
> if (ClassLoader.getSystemClassLoader() != null) {
> classPool.appendClassPath(new LoaderClassPath(ClassLoader.getSystemClassLoader()));
> } else {
> classPool.appendClassPath(new ClassClassPath(Object.class));
> }
> {code}
> on top of `classPool.appendSystemPath()` and it no longer complains about class loading problem for jdk 8 and jdk 9.
> -However, wildfly 10 + jdk 9 actually prints a warning `WARNING: An illegal reflective access operation has occurred`, but this probably is some other issues to be sorted out...- Not an issue of javaagent/javassist, as this same warning is shown even w/o agent
> Sorry about the long post. I honestly do not know whether this should be considered as a bug as all. As the name `appendSystemPath` somehow suggests to me that a class available to bootstrap classloader should be taken care of (is it considered part of the "system path"?), but i might be totally mistaken...
> Many thanks for your attention!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (JASSIST-270) Error loading class only available to bootstrap loader with jboss7+ and javassist 3.22
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-270?page=com.atlassian.jira.plugi... ]
Shigeru Chiba edited comment on JASSIST-270 at 10/24/17 2:31 PM:
-----------------------------------------------------------------
Thank you for drilling down the problem!
This is a sort of bug caused by the last-minutes hassle due to jigsaw.
It seems that the basic behavior of class loading is not compatible between Java 9 and earlier ones.
My suggestion to fix this bug is:
{code:java}
if (javassist.bytecode.ClassFile.MAJOR_VERSION < javassist.bytecode.ClassFile.JAVA_9) {
return appendClassPath(new ClassClassPath());
}
else {
ClassLoader cl = Thread.currentThread().getContextClassLoader();
return appendClassPath(new LoaderClassPath(cl, true));
}
{code}
Does this work with Java 8 and wildfly?
was (Author: chiba):
Thank you for drilling down the problem!
This is a sort of bug caused by the last-minutes hassle due to jigsaw.
It seems that the basic behavior of class loading is not compatible between Java 9 and earlier ones.
My suggestion to fix this bug is:
{{
if (javassist.bytecode.ClassFile.MAJOR_VERSION < javassist.bytecode.ClassFile.JAVA_9) {
return appendClassPath(new ClassClassPath());
}
else {
ClassLoader cl = Thread.currentThread().getContextClassLoader();
return appendClassPath(new LoaderClassPath(cl, true));
}
}}
Does this work with Java 8 and wildfly?
> Error loading class only available to bootstrap loader with jboss7+ and javassist 3.22
> --------------------------------------------------------------------------------------
>
> Key: JASSIST-270
> URL: https://issues.jboss.org/browse/JASSIST-270
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.22.0-GA
> Environment: oracle JDK 1.8.0_40
> jboss 7, wildfly 8, wildfly 9, wildfly 10
> Reporter: Patson Luk
> Assignee: Shigeru Chiba
>
> h3. Description
> After upgrading our agent from javassist 3.21 to 3.22, we started observing class loading problem during injection of code
> {{CannotCompileException: [source error] no such class: test.TestClass}}
> h3. Setup
> # Our agent inject a piece of code with reference to class `test.TestClass`
> # `test.TestClass` is provided by adding Boot-Class-Path entry in MANIFEST.MF, for example : Boot-Class-Path: ./ (with relative path, which we put the class binary `test.TestClass.class` within "test" folder relative to the agent JAR)
> # When obtaining the classpool, we always call `ClassPool.appendSystemPath()` such that `test.TestClass` available to bootstrap classloader will be loaded properly in all situations
> # Start Jboss 7 or any wildfly with `javaagent` that triggers the code injection, we will then observe the exception mentioned. Such a problem does not exist in version 3.21
> h3. Cause
> With some drill down into the source code, it appears that this [change|https://github.com/jboss-javassist/javassist/commit/778c463e5aa179...] in 3.22 combined with how jboss loads classes with its module class loader trigger the problem
> The steps are:
> # JBoss tries to load a class that triggers transformation, the javasist classpool used to load the class has a reference to the "module classloader" provided by JBoss + our `ClassPool.appendSystemPath()` call, which in 3.22, appends a LoaderClassPath of the thread's Context classloader, which is also a jboss module classloader (Module "org.jboss.as.standalone:main")
> # The injected code references class `test.TestClass`
> # `ClassPool.find` tries to use all the `ClassPath` to load `test.TestClass`, which they are both JBoss's "module classloader". Unfortunately, neither of those loaders can load the `test.TestClass` which is available to bootstrap loader
> # Throws the CannotCompileException exception as the referenced class in injected code cannot be loaded
> Take note that this worked in 3.21 as `appendSystemPath` appends the `ClassClassPath` intead of a `LoaderClassPath` with the context class loader.
> As a workaround, we added
> {code:java}
> if (ClassLoader.getSystemClassLoader() != null) {
> classPool.appendClassPath(new LoaderClassPath(ClassLoader.getSystemClassLoader()));
> } else {
> classPool.appendClassPath(new ClassClassPath(Object.class));
> }
> {code}
> on top of `classPool.appendSystemPath()` and it no longer complains about class loading problem for jdk 8 and jdk 9.
> -However, wildfly 10 + jdk 9 actually prints a warning `WARNING: An illegal reflective access operation has occurred`, but this probably is some other issues to be sorted out...- Not an issue of javaagent/javassist, as this same warning is shown even w/o agent
> Sorry about the long post. I honestly do not know whether this should be considered as a bug as all. As the name `appendSystemPath` somehow suggests to me that a class available to bootstrap classloader should be taken care of (is it considered part of the "system path"?), but i might be totally mistaken...
> Many thanks for your attention!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (JASSIST-270) Error loading class only available to bootstrap loader with jboss7+ and javassist 3.22
by Shigeru Chiba (JIRA)
[ https://issues.jboss.org/browse/JASSIST-270?page=com.atlassian.jira.plugi... ]
Shigeru Chiba commented on JASSIST-270:
---------------------------------------
Thank you for drilling down the problem!
This is a sort of bug caused by the last-minutes hassle due to jigsaw.
It seems that the basic behavior of class loading is not compatible between Java 9 and earlier ones.
My suggestion to fix this bug is:
{{if (javassist.bytecode.ClassFile.MAJOR_VERSION < javassist.bytecode.ClassFile.JAVA_9) {
return appendClassPath(new ClassClassPath());
}
else {
ClassLoader cl = Thread.currentThread().getContextClassLoader();
return appendClassPath(new LoaderClassPath(cl, true));
}}}
Does this work with Java 8 and wildfly?
> Error loading class only available to bootstrap loader with jboss7+ and javassist 3.22
> --------------------------------------------------------------------------------------
>
> Key: JASSIST-270
> URL: https://issues.jboss.org/browse/JASSIST-270
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.22.0-GA
> Environment: oracle JDK 1.8.0_40
> jboss 7, wildfly 8, wildfly 9, wildfly 10
> Reporter: Patson Luk
> Assignee: Shigeru Chiba
>
> h3. Description
> After upgrading our agent from javassist 3.21 to 3.22, we started observing class loading problem during injection of code
> {{CannotCompileException: [source error] no such class: test.TestClass}}
> h3. Setup
> # Our agent inject a piece of code with reference to class `test.TestClass`
> # `test.TestClass` is provided by adding Boot-Class-Path entry in MANIFEST.MF, for example : Boot-Class-Path: ./ (with relative path, which we put the class binary `test.TestClass.class` within "test" folder relative to the agent JAR)
> # When obtaining the classpool, we always call `ClassPool.appendSystemPath()` such that `test.TestClass` available to bootstrap classloader will be loaded properly in all situations
> # Start Jboss 7 or any wildfly with `javaagent` that triggers the code injection, we will then observe the exception mentioned. Such a problem does not exist in version 3.21
> h3. Cause
> With some drill down into the source code, it appears that this [change|https://github.com/jboss-javassist/javassist/commit/778c463e5aa179...] in 3.22 combined with how jboss loads classes with its module class loader trigger the problem
> The steps are:
> # JBoss tries to load a class that triggers transformation, the javasist classpool used to load the class has a reference to the "module classloader" provided by JBoss + our `ClassPool.appendSystemPath()` call, which in 3.22, appends a LoaderClassPath of the thread's Context classloader, which is also a jboss module classloader (Module "org.jboss.as.standalone:main")
> # The injected code references class `test.TestClass`
> # `ClassPool.find` tries to use all the `ClassPath` to load `test.TestClass`, which they are both JBoss's "module classloader". Unfortunately, neither of those loaders can load the `test.TestClass` which is available to bootstrap loader
> # Throws the CannotCompileException exception as the referenced class in injected code cannot be loaded
> Take note that this worked in 3.21 as `appendSystemPath` appends the `ClassClassPath` intead of a `LoaderClassPath` with the context class loader.
> As a workaround, we added
> {code:java}
> if (ClassLoader.getSystemClassLoader() != null) {
> classPool.appendClassPath(new LoaderClassPath(ClassLoader.getSystemClassLoader()));
> } else {
> classPool.appendClassPath(new ClassClassPath(Object.class));
> }
> {code}
> on top of `classPool.appendSystemPath()` and it no longer complains about class loading problem for jdk 8 and jdk 9.
> -However, wildfly 10 + jdk 9 actually prints a warning `WARNING: An illegal reflective access operation has occurred`, but this probably is some other issues to be sorted out...- Not an issue of javaagent/javassist, as this same warning is shown even w/o agent
> Sorry about the long post. I honestly do not know whether this should be considered as a bug as all. As the name `appendSystemPath` somehow suggests to me that a class available to bootstrap classloader should be taken care of (is it considered part of the "system path"?), but i might be totally mistaken...
> Many thanks for your attention!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9460) Sample application with 4999 CDI beans 19 seconds on initial scanning and only 2 seconds of WeldBootStrap
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-9460?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-9460:
--------------------------------------
https://github.com/wildfly/jandex/pull/34 fixes some of the Jandex hash collisions. If you want to try it out you will need to build Jandex and replace the instance that is present in Wildfly.
> Sample application with 4999 CDI beans 19 seconds on initial scanning and only 2 seconds of WeldBootStrap
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9460
> URL: https://issues.jboss.org/browse/WFLY-9460
> Project: WildFly
> Issue Type: Enhancement
> Components: CDI / Weld
> Environment: Wildfly 10.1.0.final
> Reporter: Nuno Godinho de Matos
> Assignee: Martin Kouba
> Priority: Optional
>
> During the analsysis of an application depyloment, I ended up creating a sample application to demonstrate a small but important issue that Jersey causes to deployments in Weblogic echosystem, by expensively taking 2/3 of WeldBootsrap time during the "deployBeans()" phase.
> This application is a trivial WAR application composed 99% of CDI beans.
> In particularl it holds 4999 CDI beans automcatically generated via groovy.
> URL to sample app:
> https://github.com/99sono/wls-jsf-2-2-12-jersey-weldstartup-bottleneck
> Just mvn clean install. I has no data source dependencies, just CDI beans essentially.
> It should deploy in any application server without problems.
> While testing the same application deployment on Wildfly, I noticed that essentially:
> WeldBootstrap costs almost nothing in this case (2 seconds).
> But the time spent during deployment leading up to the WeldBootstrap phase is quite costly.
> In particular, we have about 19 seconds of deployment time.
> I will now quote the deployment time log:
> {panel}
> ####2017-10-20 13:16:50,196 ThreadId:17 INFO [logger: org.jboss.as.server.deployment] - WFLYSRV0027: Starting deployment of "wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT.war" (runtime-name: "wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT.war") <LogContext:none> <MSC service thread 1-3>
> ####2017-10-20 13:17:07,279 ThreadId:18 INFO [logger: org.jboss.weld.deployer] - WFLYWELD0003: Processing weld deployment wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT.war <LogContext:none> <MSC service thread 1-4>
> ####2017-10-20 13:17:07,360 ThreadId:18 INFO [logger: org.hibernate.validator.internal.util.Version] - HV000001: Hibernate Validator 5.2.4.Final <LogContext:none> <MSC service thread 1-4>
> ####2017-10-20 13:17:07,408 ThreadId:18 INFO [logger: org.jboss.as.ejb3.deployment] - WFLYEJB0473: JNDI bindings for session bean named 'LogEjbStartupPhaseSingleton' in deployment unit 'deployment "wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT.war"' are as follows:
> java:global/wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT/LogEjbStartupPhaseSingleton!startup.LogEjbStartupPhaseSingleton
> java:app/wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT/LogEjbStartupPhaseSingleton!startup.LogEjbStartupPhaseSingleton
> java:module/LogEjbStartupPhaseSingleton!startup.LogEjbStartupPhaseSingleton
> java:global/wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT/LogEjbStartupPhaseSingleton
> java:app/wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT/LogEjbStartupPhaseSingleton
> java:module/LogEjbStartupPhaseSingleton
> <LogContext:none> <MSC service thread 1-4>
> NOTE:
> This is when the WeldBootstrapt Actually starts.
> And compared to the time spent to come here, this step costs nothing 2 seconds. [09 seocnds to 11seconds]. But to get here, we spent 19 seconds of deployment time.
> Is it possible to lower the time to come here?
> ####2017-10-20 13:17:09,208 ThreadId:15 INFO [logger: org.jboss.weld.Version] - WELD-000900: 2.3.5 (Final) <LogContext:none> <MSC service thread 1-1>
> ####2017-10-20 13:17:11,388 ThreadId:528 INFO [logger: startup.LogEjbStartupPhaseSingleton] -
> DEPLOYMENT IS NOW INVOKING STARTUP EJBS.
> <LogContext:none> <ServerService Thread Pool -- 359>
> -- Now we have a very expensive and costly mojarra startup.
> -- For this we already have opened the issue: https://github.com/javaserverfaces/mojarra/issues/4298
> ####2017-10-20 13:17:11,499 ThreadId:528 INFO [logger: javax.enterprise.resource.webcontainer.jsf.config] - Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '/wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT' <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:12,768 ThreadId:528 FINE [logger: javax.enterprise.resource.webcontainer.jsf.timing] - [TIMING] - [62ms] : Parse jar:file:/C:/dev/appserver/wildfly/wildfly-10.1.0.Final/modules/system/layers/base/com/sun/jsf-impl/main/jsf-impl-2.2.13.SP1.jar!/com/sun/faces/jsf-ri-runtime.xml <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:12,768 ThreadId:528 FINE [logger: javax.enterprise.resource.webcontainer.jsf.timing] - [TIMING] - [0ms] : Parse vfs:/C:/dev/appserver/wildfly/wildfly-10.1.0.Final/user_projects/domains/powerhousejumpstartTrunkPostgres/bin/content/wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT.war/WEB-INF/lib/primefaces-6.0.jar/META-INF/faces-config.xml <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:12,768 ThreadId:528 FINE [logger: javax.enterprise.resource.webcontainer.jsf.timing] - [TIMING] - [0ms] : Parse vfs:/C:/dev/appserver/wildfly/wildfly-10.1.0.Final/user_projects/domains/powerhousejumpstartTrunkPostgres/bin/content/wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT.war/WEB-INF/lib/primefaces-extensions-6.0.0.jar/META-INF/faces-config.xml <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:12,768 ThreadId:528 FINE [logger: javax.enterprise.resource.webcontainer.jsf.timing] - [TIMING] - [0ms] : Parse jar:file:/C:/dev/appserver/wildfly/wildfly-10.1.0.Final/modules/system/layers/base/org/jboss/as/jsf-injection/main/wildfly-jsf-injection-10.1.0.Final.jar!/META-INF/faces-config.xml <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:12,783 ThreadId:528 FINE [logger: javax.enterprise.resource.webcontainer.jsf.timing] - [TIMING] - [15ms] : Parse file:/C:/dev/appserver/wildfly/wildfly-10.1.0.Final/user_projects/domains/powerhousejumpstartTrunkPostgres/tmp/vfs/temp/temp7406137a79d4ce52/content-9b229cec60054d8f/WEB-INF/faces-config.xml <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:12,783 ThreadId:528 FINE [logger: javax.enterprise.resource.webcontainer.jsf.timing] - [TIMING] - [0ms] : "faces-config" document sorting complete in 2. <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:12,799 ThreadId:528 FINE [logger: javax.enterprise.resource.webcontainer.jsf.timing] - [TIMING] - [0ms] : Configuration annotation scan complete. <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:14,158 ThreadId:528 FINE [logger: javax.enterprise.resource.webcontainer.jsf.timing] - [TIMING] - [0ms] : Parse jar:file:/C:/dev/appserver/wildfly/wildfly-10.1.0.Final/modules/system/layers/base/com/sun/jsf-impl/main/jsf-impl-2.2.13.SP1.jar!/META-INF/mojarra_ext.taglib.xml <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:14,158 ThreadId:528 FINE [logger: javax.enterprise.resource.webcontainer.jsf.timing] - [TIMING] - [0ms] : Parse vfs:/C:/dev/appserver/wildfly/wildfly-10.1.0.Final/user_projects/domains/powerhousejumpstartTrunkPostgres/bin/content/wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT.war/WEB-INF/lib/primefaces-6.0.jar/META-INF/primefaces-pm.taglib.xml <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:14,174 ThreadId:528 FINE [logger: javax.enterprise.resource.webcontainer.jsf.timing] - [TIMING] - [16ms] : Parse vfs:/C:/dev/appserver/wildfly/wildfly-10.1.0.Final/user_projects/domains/powerhousejumpstartTrunkPostgres/bin/content/wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT.war/WEB-INF/lib/primefaces-6.0.jar/META-INF/primefaces-p.taglib.xml <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:14,190 ThreadId:528 FINE [logger: javax.enterprise.resource.webcontainer.jsf.timing] - [TIMING] - [16ms] : Parse vfs:/C:/dev/appserver/wildfly/wildfly-10.1.0.Final/user_projects/domains/powerhousejumpstartTrunkPostgres/bin/content/wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT.war/WEB-INF/lib/primefaces-extensions-6.0.0.jar/META-INF/primefaces-extensions.taglib.xml <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:14,190 ThreadId:528 FINE [logger: javax.enterprise.resource.webcontainer.jsf.timing] - [TIMING] - [0ms] : Parse jar:file:/C:/dev/appserver/wildfly/wildfly-10.1.0.Final/modules/system/layers/base/com/sun/jsf-impl/main/jsf-impl-2.2.13.SP1.jar!/META-INF/mojarra_ext.taglib.xml <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:14,274 ThreadId:528 INFO [logger: javax.enterprise.resource.webcontainer.jsf.config] - Monitoring file:/C:/dev/appserver/wildfly/wildfly-10.1.0.Final/user_projects/domains/powerhousejumpstartTrunkPostgres/tmp/vfs/temp/temp7406137a79d4ce52/content-9b229cec60054d8f/WEB-INF/faces-config.xml for modifications <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:14,362 ThreadId:528 INFO [logger: org.primefaces.webapp.PostConstructApplicationEventListener] - Running on PrimeFaces 6.0 <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:14,362 ThreadId:528 INFO [logger: org.primefaces.extensions.application.PostConstructApplicationEventListener] - Running on PrimeFaces Extensions 6.0.0 <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:14,362 ThreadId:528 FINE [logger: javax.enterprise.resource.webcontainer.jsf.timing] - [TIMING] - [2894ms] : Initialization of context /wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:14,658 ThreadId:528 INFO [logger: org.jboss.resteasy.resteasy_jaxrs.i18n] - RESTEASY002225: Deploying javax.ws.rs.core.Application: class rest.RestApplication$Proxy$_$$_WeldClientProxy <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:14,689 ThreadId:528 INFO [logger: org.wildfly.extension.undertow] - WFLYUT0021: Registered web context: /wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT <LogContext:none> <ServerService Thread Pool -- 359>
> ####2017-10-20 13:17:14,748 ThreadId:507 INFO [logger: org.jboss.as.server] - WFLYSRV0010: Deployed "wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT.war" (runtime-name : "wls-jsf-2-2-12-jersey-weldstartup-bottleneck-1.0.0-SANPSHOT.war") <LogContext:none> <External Management Request Threads -- 5>
> {panel}
> Would it possible for a CDI expert to try deploying the application and determine if the 19 seocnds that lead up to the first message: WELD-000900 2.3.5
> Is well justified, or if there is room optimizing this boostraping costs.
> To me 19 seonds to analyse 4999 CDI beans, that are all located uner WEB-INF/classes looks like an expensive cost.
> Is there any sort of static configuration that we could perhaps create to lower the annotation analysis cost or any other sort of trick.
> I would have hoped that this war file could deploy in under 5 seconds.
> Many thanks for any feedback on this.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (JASSIST-270) Error loading class only available to bootstrap loader with jboss7+ and javassist 3.22
by Patson Luk (JIRA)
[ https://issues.jboss.org/browse/JASSIST-270?page=com.atlassian.jira.plugi... ]
Patson Luk updated JASSIST-270:
-------------------------------
Description:
h3. Description
After upgrading our agent from javassist 3.21 to 3.22, we started observing class loading problem during injection of code
{{CannotCompileException: [source error] no such class: test.TestClass}}
h3. Setup
# Our agent inject a piece of code with reference to class `test.TestClass`
# `test.TestClass` is provided by adding Boot-Class-Path entry in MANIFEST.MF, for example : Boot-Class-Path: ./ (with relative path, which we put the class binary `test.TestClass.class` within "test" folder relative to the agent JAR)
# When obtaining the classpool, we always call `ClassPool.appendSystemPath()` such that `test.TestClass` available to bootstrap classloader will be loaded properly in all situations
# Start Jboss 7 or any wildfly with `javaagent` that triggers the code injection, we will then observe the exception mentioned. Such a problem does not exist in version 3.21
h3. Cause
With some drill down into the source code, it appears that this [change|https://github.com/jboss-javassist/javassist/commit/778c463e5aa179...] in 3.22 combined with how jboss loads classes with its module class loader trigger the problem
The steps are:
# JBoss tries to load a class that triggers transformation, the javasist classpool used to load the class has a reference to the "module classloader" provided by JBoss + our `ClassPool.appendSystemPath()` call, which in 3.22, appends a LoaderClassPath of the thread's Context classloader, which is also a jboss module classloader (Module "org.jboss.as.standalone:main")
# The injected code references class `test.TestClass`
# `ClassPool.find` tries to use all the `ClassPath` to load `test.TestClass`, which they are both JBoss's "module classloader". Unfortunately, neither of those loaders can load the `test.TestClass` which is available to bootstrap loader
# Throws the CannotCompileException exception as the referenced class in injected code cannot be loaded
Take note that this worked in 3.21 as `appendSystemPath` appends the `ClassClassPath` intead of a `LoaderClassPath` with the context class loader.
As a workaround, we added
{code:java}
if (ClassLoader.getSystemClassLoader() != null) {
classPool.appendClassPath(new LoaderClassPath(ClassLoader.getSystemClassLoader()));
} else {
classPool.appendClassPath(new ClassClassPath(Object.class));
}
{code}
on top of `classPool.appendSystemPath()` and it no longer complains about class loading problem for jdk 8 and jdk 9.
-However, wildfly 10 + jdk 9 actually prints a warning `WARNING: An illegal reflective access operation has occurred`, but this probably is some other issues to be sorted out...- Not an issue of javaagent/javassist, as this same warning is shown even w/o agent
Sorry about the long post. I honestly do not know whether this should be considered as a bug as all. As the name `appendSystemPath` somehow suggests to me that a class available to bootstrap classloader should be taken care of (is it considered part of the "system path"?), but i might be totally mistaken...
Many thanks for your attention!
was:
h3. Description
After upgrading our agent from javassist 3.21 to 3.22, we started observing class loading problem during injection of code
{{CannotCompileException: [source error] no such class: test.TestClass}}
h3. Setup
# Our agent inject a piece of code with reference to class `test.TestClass`
# `test.TestClass` is provided by adding Boot-Class-Path entry in MANIFEST.MF, for example : Boot-Class-Path: ./ (with relative path, which we put the class binary `test.TestClass.class` within "test" folder relative to the agent JAR)
# When obtaining the classpool, we always call `ClassPool.appendSystemPath()` such that `test.TestClass` available to bootstrap classloader will be loaded properly in all situations
# Start Jboss 7 or any wildfly with `javaagent` that triggers the code injection, we will then observe the exception mentioned. Such a problem does not exist in version 3.21
h3. Cause
With some drill down into the source code, it appears that this [change|https://github.com/jboss-javassist/javassist/commit/778c463e5aa179...] in 3.22 combined with how jboss loads classes with its module class loader trigger the problem
The steps are:
# JBoss tries to load a class that triggers transformation, the javasist classpool used to load the class has a reference to the "module classloader" provided by JBoss + our `ClassPool.appendSystemPath()` call, which in 3.22, appends a LoaderClassPath of the thread's Context classloader, which is also a jboss module classloader (Module "org.jboss.as.standalone:main")
# The injected code references class `test.TestClass`
# `ClassPool.find` tries to use all the `ClassPath` to load `test.TestClass`, which they are both JBoss's "module classloader". Unfortunately, neither of those loaders can load the `test.TestClass` which is available to bootstrap loader
# Throws the CannotCompileException exception as the referenced class in injected code cannot be loaded
Take note that this worked in 3.21 as `appendSystemPath` appends the `ClassClassPath` intead of a `LoaderClassPath` with the context class loader.
As a workaround, we added
{code:java}
if (ClassLoader.getSystemClassLoader() != null) {
classPool.appendClassPath(new LoaderClassPath(ClassLoader.getSystemClassLoader()));
} else {
classPool.appendClassPath(new ClassClassPath(Object.class));
}
{code}
on top of `classPool.appendSystemPath()` and it no longer complains about class loading problem for jdk 8 and jdk 9. However, wildfly 10 + jdk 9 actually prints a warning `WARNING: An illegal reflective access operation has occurred`, but this probably is some other issues to be sorted out...
Sorry about the long post. I honestly do not know whether this should be considered as a bug as all. As the name `appendSystemPath` somehow suggests to me that a class available to bootstrap classloader should be taken care of (is it considered part of the "system path"?), but i might be totally mistaken...
Many thanks for your attention!
> Error loading class only available to bootstrap loader with jboss7+ and javassist 3.22
> --------------------------------------------------------------------------------------
>
> Key: JASSIST-270
> URL: https://issues.jboss.org/browse/JASSIST-270
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.22.0-GA
> Environment: oracle JDK 1.8.0_40
> jboss 7, wildfly 8, wildfly 9, wildfly 10
> Reporter: Patson Luk
> Assignee: Shigeru Chiba
>
> h3. Description
> After upgrading our agent from javassist 3.21 to 3.22, we started observing class loading problem during injection of code
> {{CannotCompileException: [source error] no such class: test.TestClass}}
> h3. Setup
> # Our agent inject a piece of code with reference to class `test.TestClass`
> # `test.TestClass` is provided by adding Boot-Class-Path entry in MANIFEST.MF, for example : Boot-Class-Path: ./ (with relative path, which we put the class binary `test.TestClass.class` within "test" folder relative to the agent JAR)
> # When obtaining the classpool, we always call `ClassPool.appendSystemPath()` such that `test.TestClass` available to bootstrap classloader will be loaded properly in all situations
> # Start Jboss 7 or any wildfly with `javaagent` that triggers the code injection, we will then observe the exception mentioned. Such a problem does not exist in version 3.21
> h3. Cause
> With some drill down into the source code, it appears that this [change|https://github.com/jboss-javassist/javassist/commit/778c463e5aa179...] in 3.22 combined with how jboss loads classes with its module class loader trigger the problem
> The steps are:
> # JBoss tries to load a class that triggers transformation, the javasist classpool used to load the class has a reference to the "module classloader" provided by JBoss + our `ClassPool.appendSystemPath()` call, which in 3.22, appends a LoaderClassPath of the thread's Context classloader, which is also a jboss module classloader (Module "org.jboss.as.standalone:main")
> # The injected code references class `test.TestClass`
> # `ClassPool.find` tries to use all the `ClassPath` to load `test.TestClass`, which they are both JBoss's "module classloader". Unfortunately, neither of those loaders can load the `test.TestClass` which is available to bootstrap loader
> # Throws the CannotCompileException exception as the referenced class in injected code cannot be loaded
> Take note that this worked in 3.21 as `appendSystemPath` appends the `ClassClassPath` intead of a `LoaderClassPath` with the context class loader.
> As a workaround, we added
> {code:java}
> if (ClassLoader.getSystemClassLoader() != null) {
> classPool.appendClassPath(new LoaderClassPath(ClassLoader.getSystemClassLoader()));
> } else {
> classPool.appendClassPath(new ClassClassPath(Object.class));
> }
> {code}
> on top of `classPool.appendSystemPath()` and it no longer complains about class loading problem for jdk 8 and jdk 9.
> -However, wildfly 10 + jdk 9 actually prints a warning `WARNING: An illegal reflective access operation has occurred`, but this probably is some other issues to be sorted out...- Not an issue of javaagent/javassist, as this same warning is shown even w/o agent
> Sorry about the long post. I honestly do not know whether this should be considered as a bug as all. As the name `appendSystemPath` somehow suggests to me that a class available to bootstrap classloader should be taken care of (is it considered part of the "system path"?), but i might be totally mistaken...
> Many thanks for your attention!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9475) org.omg.CORBA.BAD_OPERATION in TCK
by Tomasz Adamski (JIRA)
Tomasz Adamski created WFLY-9475:
------------------------------------
Summary: org.omg.CORBA.BAD_OPERATION in TCK
Key: WFLY-9475
URL: https://issues.jboss.org/browse/WFLY-9475
Project: WildFly
Issue Type: Bug
Components: IIOP
Affects Versions: 11.0.0.Final
Reporter: Tomasz Adamski
Assignee: Tomasz Adamski
Following error occurs occasionally in TCK testsuite:
{code}
[javax.enterprise.resource.corba._INITIALIZING_.rpc.presentation] (MSC
service thread 1-3) "IOP01210227: (BAD_OPERATION) Error in running ORB
configurator": org.omg.CORBA.BAD_OPERATION: vmcid: SUN minor code:
227 completed: No
at com.sun.corba.se.impl.logging.ORBUtilSystemException.orbConfiguratorError(ORBUtilSystemException.java:558)
[openjdk-orb-8.0.8.Final-redhat-1.jar:8.0.8.Final-redhat-1]
at com.sun.corba.se.impl.logging.ORBUtilSystemException.orbConfiguratorError(ORBUtilSystemException.java:576)
[openjdk-orb-8.0.8.Final-redhat-1.jar:8.0.8.Final-redhat-1]
at com.sun.corba.se.impl.orb.ORBImpl.postInit(ORBImpl.java:485)
[openjdk-orb-8.0.8.Final-redhat-1.jar:8.0.8.Final-redhat-1]
at com.sun.corba.se.impl.orb.ORBImpl.set_parameters(ORBImpl.java:543)
[openjdk-orb-8.0.8.Final-redhat-1.jar:8.0.8.Final-redhat-1]
at org.omg.CORBA.ORB.init(ORB.java:353)
[openjdk-orb-8.0.8.Final-redhat-1.jar:8.0.8.Final-redhat-1]
at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:126)
[wildfly-iiop-openjdk-7.1.0.GA-redhat-SNAPSHOT.jar:7.1.0.GA-redhat-SNAPSHOT]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
[jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
[jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[rt.jar:1.8.0_144]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[rt.jar:1.8.0_144]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_144]
Caused by: java.lang.RuntimeException:
javax.naming.ConfigurationException: WFLYIIOP0051: Error configuring
domain socket factory: failed to lookup JSSE security domain
at org.wildfly.iiop.openjdk.security.LegacySSLSocketFactory.setORB(LegacySSLSocketFactory.java:86)
[wildfly-iiop-openjdk-7.1.0.GA-redhat-SNAPSHOT.jar:7.1.0.GA-redhat-SNAPSHOT]
at com.sun.corba.se.impl.orb.ORBConfiguratorImpl.initializeTransport(ORBConfiguratorImpl.java:271)
[openjdk-orb-8.0.8.Final-redhat-1.jar:8.0.8.Final-redhat-1]
at com.sun.corba.se.impl.orb.ORBConfiguratorImpl.configure(ORBConfiguratorImpl.java:149)
[openjdk-orb-8.0.8.Final-redhat-1.jar:8.0.8.Final-redhat-1]
at com.sun.corba.se.impl.orb.ORBImpl.postInit(ORBImpl.java:483)
[openjdk-orb-8.0.8.Final-redhat-1.jar:8.0.8.Final-redhat-1]
... 8 more
Caused by: javax.naming.ConfigurationException: WFLYIIOP0051: Error
configuring domain socket factory: failed to lookup JSSE security
domain
... 12 more
[javax.enterprise.resource.corba._INITIALIZING_.rpc.presentation] (MSC
service thread 1-3) "IOP01210227: (BAD_OPERATION) Error in running ORB
configurator": org.omg.CORBA.BAD_OPERATION: vmcid: SUN minor code:
227 completed: No
at com.sun.corba.se.impl.logging.ORBUtilSystemException.orbConfiguratorError(ORBUtilSystemException.java:558)
[openjdk-orb-8.0.8.Final-redhat-1.jar:8.0.8.Final-redhat-1]
at com.sun.corba.se.impl.logging.ORBUtilSystemException.orbConfiguratorError(ORBUtilSystemException.java:576)
[openjdk-orb-8.0.8.Final-redhat-1.jar:8.0.8.Final-redhat-1]
at com.sun.corba.se.impl.orb.ORBImpl.postInit(ORBImpl.java:485)
[openjdk-orb-8.0.8.Final-redhat-1.jar:8.0.8.Final-redhat-1]
at com.sun.corba.se.impl.orb.ORBImpl.set_parameters(ORBImpl.java:543)
[openjdk-orb-8.0.8.Final-redhat-1.jar:8.0.8.Final-redhat-1]
at org.omg.CORBA.ORB.init(ORB.java:353)
[openjdk-orb-8.0.8.Final-redhat-1.jar:8.0.8.Final-redhat-1]
at org.wildfly.iiop.openjdk.service.CorbaORBService.start(CorbaORBService.java:126)
[wildfly-iiop-openjdk-7.1.0.GA-redhat-SNAPSHOT.jar:7.1.0.GA-redhat-SNAPSHOT]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
[jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
[jboss-msc-1.2.7.SP1-redhat-1.jar:1.2.7.SP1-redhat-1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[rt.jar:1.8.0_144]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[rt.jar:1.8.0_144]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_144]
Caused by: java.lang.RuntimeException:
javax.naming.ConfigurationException: WFLYIIOP0051: Error configuring
domain socket factory: failed to lookup JSSE security domain
at org.wildfly.iiop.openjdk.security.LegacySSLSocketFactory.setORB(LegacySSLSocketFactory.java:86)
[wildfly-iiop-openjdk-7.1.0.GA-redhat-SNAPSHOT.jar:7.1.0.GA-redhat-SNAPSHOT]
at com.sun.corba.se.impl.orb.ORBConfiguratorImpl.initializeTransport(ORBConfiguratorImpl.java:271)
[openjdk-orb-8.0.8.Final-redhat-1.jar:8.0.8.Final-redhat-1]
at com.sun.corba.se.impl.orb.ORBConfiguratorImpl.configure(ORBConfiguratorImpl.java:149)
[openjdk-orb-8.0.8.Final-redhat-1.jar:8.0.8.Final-redhat-1]
at com.sun.corba.se.impl.orb.ORBImpl.postInit(ORBImpl.java:483)
[openjdk-orb-8.0.8.Final-redhat-1.jar:8.0.8.Final-redhat-1]
... 8 more
Caused by: javax.naming.ConfigurationException: WFLYIIOP0051: Error
configuring domain socket factory: failed to lookup JSSE security
domain
... 12 more
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months
[JBoss JIRA] (WFLY-9474) Message NODE_X::MESSAGE_Y not found in retransmission table
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9474?page=com.atlassian.jira.plugin.... ]
Radoslav Husar moved JBEAP-13605 to WFLY-9474:
----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9474 (was: JBEAP-13605)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Clustering
(was: Clustering)
Affects Version/s: 11.0.0.Final
(was: 7.1.0.DR12)
(was: 7.1.0.DR13)
(was: 7.1.0.CR3)
> Message NODE_X::MESSAGE_Y not found in retransmission table
> -----------------------------------------------------------
>
> Key: WFLY-9474
> URL: https://issues.jboss.org/browse/WFLY-9474
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Critical
>
> In failover scenario *ejb-ejbservlet-jvmkill-repl-async* we saw this WARN message on *server*:
> {code}
> 08:09:22,881 WARN [org.jboss.as.clustering.jgroups.protocol.NAKACK2] (thread-2) JGRP000041: perf18: message perf20::104044 not found in retransmission table
> {code}
> This message is being logged repeatedly causing the test not to finish properly until time-out.
> Timeline:
> 1. JVMKILL started at 08:09:16:197 (Failing node 1 (perf19)):
> {code}
> 08:09:16:197 EST [DEBUG][RMI TCP Connection(49)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - [JVM-KILL] =Start=
> {code}
> 2. New cluster view was received at 08:09:21,413 (without perf19)
> {code}
> 08:09:21,413 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (thread-14) ISPN000094: Received new cluster view for channel ejb: [perf21|6] (3) [perf21, perf20, perf18]
> {code}
> 3. Message "... not found in retransmission table" starts to occur on perf18, perf20, perf21 repeatedly:
> {code}
> 08:09:22,881 WARN [org.jboss.as.clustering.jgroups.protocol.NAKACK2] (thread-2) JGRP000041: perf18: message perf20::104044 not found in retransmission table
> {code}
> 4. Server started on perf19 at 08:10:30,218
> 5. ERROR message is logged afterward on perf19:
> {code}
> 08:10:30,790 ERROR [org.jboss.as.clustering.jgroups.protocol.NAKACK2] (thread-1) JGRP000040: perf19: sender e6c86784-b1b1-4135-5719-9ffc8654e4cb not found in retransmission table
> {code}
> 6. "... not found in retransmission table" is logged repeatedly on perf19
> {code}
> 08:11:18,836 ERROR [org.jboss.as.clustering.jgroups.protocol.NAKACK2] (thread-1) JGRP000040: perf19: sender perf18 not found in retransmission table
> {code}
> This message occurs on all nodes. Client is not affected.
> Link to server log:
> http://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/job/perflab_eap-7x-fa...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 8 months