[JBoss JIRA] (WFLY-7790) ResourceAdapter#endpointActivation called twice because of SuspendController activation
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7790?page=com.atlassian.jira.plugin.... ]
Stuart Douglas moved WFCORE-2113 to WFLY-7790:
----------------------------------------------
Project: WildFly (was: WildFly Core)
Key: WFLY-7790 (was: WFCORE-2113)
Component/s: EJB
(was: Server)
Affects Version/s: (was: 3.0.0.Alpha13)
> ResourceAdapter#endpointActivation called twice because of SuspendController activation
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-7790
> URL: https://issues.jboss.org/browse/WFLY-7790
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Ondra Chaloupka
> Assignee: Stuart Douglas
>
> I do experience that call of my implementation {{ResourceAdapter#endpointActivation}} is called twice. Which is difference against behavior before (<=7.1.0.DR8) and I think that that method should be called just once. My RAR implementation uses the method {{endpointActivation}} for opening a socket and second call then causes a {{ResourceException}} being thrown and ERROR log message appears in server log
> {code}
> ERROR [org.jboss.as.server] (ServerService Thread Pool -- 66) WFLYSRV0215: Failed to resume activity org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent$1@43ab957d. To resume normal operation it is recommended that you restart the server.
> {code}
> By my investigation it's caused by the fact that {{SuspendController}} launches {{resume}} method of {{ServerActivity serverActivity}} at {{org.jboss.as.ejb3.component.messagedriven.MessageDrivenComponent}}.
> I think it's caused because method {{SuspendController#setStartSuspended}} sets state to {{SUSPENDED}} regardless of boolean parameter value.
> https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/...
> I tried to do a small fix (I'm not sure if it's correct one) and that way the endpoint activation is launched just once as I expect.
> https://github.com/ochaloup/wildfly-core/commit/4d6ac5777414088c9f39605e9...
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFCORE-2118) Start/restart/reload options naming should be consistent for server in standalone and in domain mode
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2118?page=com.atlassian.jira.plugi... ]
Stuart Douglas moved JBEAP-7868 to WFCORE-2118:
-----------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2118 (was: JBEAP-7868)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
Server
(was: Domain Management)
(was: Server)
(was: User Experience)
Affects Version/s: (was: 7.1.0.DR9)
> Start/restart/reload options naming should be consistent for server in standalone and in domain mode
> ----------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2118
> URL: https://issues.jboss.org/browse/WFCORE-2118
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Server
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Priority: Minor
>
> As part of EAP 7.1.0.DR9 and [EAP7-636] there was introduced possibility to define that start/reload/restart operation should end up in suspended mode instead of fully starting immediately.
> In standalone mode this is controlled via {{start-mode}} parameter. In case of domain mode there are boolean attributes for each of the start options.
> It would be nice to be consistent and also in domain use {{start-mode}} parameter (it can be limited to values making sense only in domain mode)
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (DROOLS-1373) Rules are not removed from the KieModule/KieContainer
by Bill Tuminaro (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1373?page=com.atlassian.jira.plugi... ]
Bill Tuminaro commented on DROOLS-1373:
---------------------------------------
Based on some initial testing this situation appears to be resolved in the 6.5.0.Final release.
We will conduct a few more tests before closing this item.
-BillT
> Rules are not removed from the KieModule/KieContainer
> -----------------------------------------------------
>
> Key: DROOLS-1373
> URL: https://issues.jboss.org/browse/DROOLS-1373
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Bill Tuminaro
> Assignee: Mario Fusco
> Attachments: NotRemovingRules.java, drools-1373.PNG
>
>
> I have attached a reproducer named NotRemovingRules.java that creates a KieContainer with a KieModule that contains a single rule (rule name 1081) and then runs a loop that adds 2 rules and removes 2 rules and calls KieContainer.updateToVersion(). Along the way it creates .dmp files.
> If you examine the last .dmp file created names ckpoint3.drl you will see that rules named like
> org.drools.compiler.integraionTests.Rule_120#0DefaultConsequenceInvoker are still present. However, if you examine the console or System.out you will notice the code is executing that is removing the rules from the KieModule/KieContainer.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-7746) Fix compatibility between Infinispan and JBoss Marshalling 2.0.0.Beta3
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-7746?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-7746:
-------------------------------
Summary: Fix compatibility between Infinispan and JBoss Marshalling 2.0.0.Beta3 (was: Upgrade to a version of Infinispan that depends on JBoss Marshalling 2.0.0.Beta3)
> Fix compatibility between Infinispan and JBoss Marshalling 2.0.0.Beta3
> ----------------------------------------------------------------------
>
> Key: WFLY-7746
> URL: https://issues.jboss.org/browse/WFLY-7746
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Clustering
> Reporter: Farah Juma
> Assignee: Paul Ferraro
> Attachments: org.jboss.as.test.clustering.cluster.sso.ClusteredSingleSignOnTestCase-SYNC-tcp-output.txt
>
>
> As part of the wildfly-naming-client integration work, we need to upgrade to JBoss Marshalling 2.0.0.Beta3 (see WFCORE-2044 and WFLY-7675). This upgrade currently results in testsuite failures in {{org.jboss.as.test.clustering.cluster.sso.ClusteredSingleSignOnTestCase}} since Infinispan is still on JBoss Marshalling 1.4.x.
> ISPN-3391 was created a while back to upgrade Infinispan to JBoss Marshalling 2.0.0 but it seems this issue was waiting on a JBoss Marshalling release that adds back some classes that had previously been removed. JBoss Marshalling 2.0.0.Beta3 contains these classes so it should be possible now to upgrade Infinispan to this new version.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (JASSIST-141) Failed to transform class with name com.some.class. Reason: null
by Saravanan S (JIRA)
[ https://issues.jboss.org/browse/JASSIST-141?page=com.atlassian.jira.plugi... ]
Saravanan S commented on JASSIST-141:
-------------------------------------
Anyone knows if this is a Javassist bug? Ran into same javaassist error and looking for options to resolve
> Failed to transform class with name com.some.class. Reason: null
> ----------------------------------------------------------------
>
> Key: JASSIST-141
> URL: https://issues.jboss.org/browse/JASSIST-141
> Project: Javassist
> Issue Type: Bug
> Affects Versions: 3.14.0.GA
> Environment: eclipse, powermock 1.4.8, easymock 3, junit 4.8, javassist 3.14.0.GA
> Reporter: Andreas Don'tAskDon'tTell
> Assignee: Shigeru Chiba
> Labels: mapmaker, powermock
>
> Hi,
> i get this error while using the @PrepareForTest() annotation from the powermock framework.
> This framework uses javassist for bytecode manipulation and i think it's more a javassist bug then a powermock bug.
> the code i try to parse is 2500 lines long (i know bad bad bad code but it's not mine, i only need to test it). i do not want to post all. If you could help me to debug the hole file with javassist to find the methodes or statments that produces this error, i am happy to do so. Is there some debuging level or something to check where javassist crashes?
> Thankyou for now :D
> Yours,
> Andreas
> and here the stacktrace:
> java.lang.IllegalStateException: Failed to transform class with name com.some.class. Reason: null
> at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:207)
> at org.powermock.core.classloader.MockClassLoader.loadModifiedClass(MockClassLoader.java:145)
> at org.powermock.core.classloader.DeferSupportingClassLoader.loadClass(DeferSupportingClassLoader.java:65)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:247)
> at sun.reflect.generics.factory.CoreReflectionFactory.makeNamedType(CoreReflectionFactory.java:95)
> at sun.reflect.generics.visitor.Reifier.visitClassTypeSignature(Reifier.java:107)
> at sun.reflect.generics.tree.ClassTypeSignature.accept(ClassTypeSignature.java:31)
> at sun.reflect.annotation.AnnotationParser.parseSig(AnnotationParser.java:370)
> at sun.reflect.annotation.AnnotationParser.parseClassValue(AnnotationParser.java:351)
> at sun.reflect.annotation.AnnotationParser.parseClassArray(AnnotationParser.java:653)
> at sun.reflect.annotation.AnnotationParser.parseArray(AnnotationParser.java:460)
> at sun.reflect.annotation.AnnotationParser.parseMemberValue(AnnotationParser.java:286)
> at sun.reflect.annotation.AnnotationParser.parseAnnotation(AnnotationParser.java:222)
> at sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:69)
> at sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:52)
> at java.lang.Class.initAnnotationsIfNecessary(Class.java:3070)
> at java.lang.Class.getAnnotations(Class.java:3050)
> at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.classAnnotations(PowerMockJUnit44RunnerDelegateImpl.java:163)
> at org.powermock.modules.junit4.internal.impl.PowerMockJUnit44RunnerDelegateImpl.getDescription(PowerMockJUnit44RunnerDelegateImpl.java:155)
> at org.powermock.modules.junit4.common.internal.impl.JUnit4TestSuiteChunkerImpl.getDescription(JUnit4TestSuiteChunkerImpl.java:172)
> at org.powermock.modules.junit4.common.internal.impl.AbstractCommonPowerMockRunner.getDescription(AbstractCommonPowerMockRunner.java:47)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.sendTree(JUnit4TestClassReference.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.sendTrees(RemoteTestRunner.java:476)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:464)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
> Caused by: java.lang.NullPointerException
> at javassist.bytecode.stackmap.Tracer.checkParamTypes(Tracer.java:888)
> at javassist.bytecode.stackmap.Tracer.doInvokeMethod(Tracer.java:822)
> at javassist.bytecode.stackmap.Tracer.doOpcode148_201(Tracer.java:620)
> at javassist.bytecode.stackmap.Tracer.doOpcode(Tracer.java:102)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:182)
> at javassist.bytecode.stackmap.MapMaker.traceException(MapMaker.java:213)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:175)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:192)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:192)
> =====================================================================================================================
> 243 times this line : at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:192)
> =====================================================================================================================
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:141)
> at javassist.bytecode.stackmap.MapMaker.make(MapMaker.java:96)
> at javassist.bytecode.MethodInfo.rebuildStackMap(MethodInfo.java:416)
> at javassist.bytecode.MethodInfo.rebuildStackMapIf6(MethodInfo.java:398)
> at javassist.expr.ExprEditor.doit(ExprEditor.java:112)
> at javassist.CtClassType.instrument(CtClassType.java:1384)
> at org.powermock.core.transformers.impl.MainMockTransformer.transform(MainMockTransformer.java:77)
> at org.powermock.core.classloader.MockClassLoader.loadMockClass(MockClassLoader.java:203)
> ... 28 more
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-7788) Retire cluster-ha-singleton quickstart
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7788?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-7788:
---------------------------------
Description: Quickstart cluster-ha-singleton was effectively made obsolete by singleton deployments, which were introduced in EAP 7.0. (was: Quickstart cluster-ha-singleton was effectively made obsolete by singleton deployments, which were introduced in EAP 7.0)
> Retire cluster-ha-singleton quickstart
> ---------------------------------------
>
> Key: WFLY-7788
> URL: https://issues.jboss.org/browse/WFLY-7788
> Project: WildFly
> Issue Type: Task
> Components: Quickstarts
> Affects Versions: 10.0.0.Final, 11.0.0.Alpha1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> Quickstart cluster-ha-singleton was effectively made obsolete by singleton deployments, which were introduced in EAP 7.0.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-7788) Retire cluster-ha-singleton quickstart
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7788?page=com.atlassian.jira.plugin.... ]
Radoslav Husar moved JBEAP-7866 to WFLY-7788:
---------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7788 (was: JBEAP-7866)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Quickstarts
(was: Quickstarts)
Affects Version/s: 10.0.0.Final
11.0.0.Alpha1
(was: 7.0.0.ER6)
> Retire cluster-ha-singleton quickstart
> ---------------------------------------
>
> Key: WFLY-7788
> URL: https://issues.jboss.org/browse/WFLY-7788
> Project: WildFly
> Issue Type: Task
> Components: Quickstarts
> Affects Versions: 10.0.0.Final, 11.0.0.Alpha1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> Quickstart cluster-ha-singleton was effectively made obsolete by singleton deployments, which were introduced in EAP 7.0
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months
[JBoss JIRA] (WFLY-7772) Configuring L1 results in invalid configuration for 'routing' and 'client-mapping' caches
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7772?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-7772:
---------------------------------
Summary: Configuring L1 results in invalid configuration for 'routing' and 'client-mapping' caches (was: Distributed cache is created in REPLICATED mode)
> Configuring L1 results in invalid configuration for 'routing' and 'client-mapping' caches
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-7772
> URL: https://issues.jboss.org/browse/WFLY-7772
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: Richard Janík
> Assignee: Radoslav Husar
>
> While trying to verify a different issue, I configured a {{<distributed-cache>}} with {{l1-lifespan=300000}} and added a Clusterbench deployment. The EAP start failed with:
> {code}
> ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service org.wildfly.clustering.infinispan.cache-configuration.web.routing: org.jboss.msc.service.StartException in service org.wildfly.clustering.infinispan.cache-configuration.web.routing: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1919)
> 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: org.infinispan.commons.CacheConfigurationException: ISPN000350: Enabling the L1 cache is only supported when using DISTRIBUTED as a cache mode. Your cache mode is set to REPLICATED
> at org.infinispan.configuration.cache.L1ConfigurationBuilder.validate(L1ConfigurationBuilder.java:97)
> at org.infinispan.configuration.cache.ClusteringConfigurationBuilder.validate(ClusteringConfigurationBuilder.java:108)
> at org.infinispan.configuration.cache.ConfigurationBuilder.validate(ConfigurationBuilder.java:203)
> at org.infinispan.configuration.cache.ConfigurationBuilder.build(ConfigurationBuilder.java:246)
> at org.infinispan.configuration.cache.ConfigurationBuilder.build(ConfigurationBuilder.java:236)
> at org.wildfly.clustering.infinispan.spi.service.ConfigurationBuilder.start(ConfigurationBuilder.java:88)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1963)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1896)
> ... 3 more
> {code}
> The full config is here:
> http://pastebin.test.redhat.com/437800
> The cache has {{owners=1}}, but that does not matter, the exception is thrown with the default {{owners=2}} as well.
> And the full server log is here:
> http://pastebin.test.redhat.com/437799
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 4 months