[JBoss JIRA] (AS7-4247) Server shutdown: Problems un-registering MBeans: CacheException: Failure while unregistering mbeans
by Radoslav Husar (JIRA)
Radoslav Husar created AS7-4247:
-----------------------------------
Summary: Server shutdown: Problems un-registering MBeans: CacheException: Failure while unregistering mbeans
Key: AS7-4247
URL: https://issues.jboss.org/browse/AS7-4247
Project: Application Server 7
Issue Type: Bug
Components: Clustering
Affects Versions: 7.1.1.Final
Reporter: Radoslav Husar
Assignee: Paul Ferraro
Fix For: 7.2.0.Alpha1
Just ran into this, implications not yet known.
{noformat}
[JBossINF] 15:02:54,085 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,null) ISPN000094: Received new cluster view: [perf18/ejb|12] [perf18/ejb, perf20/ejb, perf21/ejb]
[JBossINF] 15:02:54,086 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-6,null) ISPN000094: Received new cluster view: [perf18/web|12] [perf18/web, perf20/web, perf21/web]
[JBossINF] 15:02:58,127 INFO [org.jboss.as.clustering.impl.CoreGroupCommunicationService.lifecycle.web] (Incoming-5,null) JBAS010247: New cluster view for partition web (id: 13, delta: -1, merge: false) : [perf18/web, perf20/web]
[JBossINF] 15:02:58,128 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-5,null) ISPN000094: Received new cluster view: [perf18/web|13] [perf18/web, perf20/web]
[JBossINF] 15:02:58,135 INFO [org.jboss.as.clustering.impl.CoreGroupCommunicationService.lifecycle.ejb] (Incoming-4,null) JBAS010247: New cluster view for partition ejb (id: 13, delta: -1, merge: false) : [perf18/ejb, perf20/ejb]
[JBossINF] 15:02:58,136 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-4,null) ISPN000094: Received new cluster view: [perf18/ejb|13] [perf18/ejb, perf20/ejb]
[JBossINF] 15:03:02,476 INFO [org.jboss.as.clustering.impl.CoreGroupCommunicationService.lifecycle.web] (Incoming-2,null) JBAS010247: New cluster view for partition web (id: 14, delta: -1, merge: false) : [perf18/web]
[JBossINF] 15:03:02,477 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,null) ISPN000094: Received new cluster view: [perf18/web|14] [perf18/web]
[JBossINF] 15:03:02,494 INFO [org.jboss.as.clustering.impl.CoreGroupCommunicationService.lifecycle.ejb] (Incoming-16,null) JBAS010247: New cluster view for partition ejb (id: 14, delta: -1, merge: false) : [perf18/ejb]
[JBossINF] 15:03:02,495 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-16,null) ISPN000094: Received new cluster view: [perf18/ejb|14] [perf18/ejb]
2012/03/20 15:03:05:785 EDT [DEBUG][RMI TCP Connection(18)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - JBossApplicationServerImpl: sfTerminateWith().
2012/03/20 15:03:05:785 EDT [DEBUG][RMI TCP Connection(18)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - [JBossRuntime] sfTerminateWith() invoked.
2012/03/20 15:03:05:790 EDT [DEBUG][Thread-33] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - JBossShutdown server host: perf18
2012/03/20 15:03:05:829 EDT [DEBUG][RMI TCP Connection(18)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - JBossShutdown command executed successfuly.
2012/03/20 15:03:05:830 EDT [DEBUG][RMI TCP Connection(18)-10.16.90.52] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Waiting for server to shutdown.
[JBossINF] 15:03:05,850 INFO [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-3) ISPN000029: Passivating all entries to disk
[JBossINF] 15:03:05,851 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-9) Pausing Coyote HTTP/1.1 on http-perf18-10.16.90.54-8080
[JBossINF] 15:03:05,851 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-9) Stopping Coyote HTTP/1.1 on http-perf18-10.16.90.54-8080
[JBossINF] 15:03:05,850 INFO [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-12) ISPN000029: Passivating all entries to disk
[JBossINF] 15:03:05,851 INFO [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-3) ISPN000030: Passivated 0 entries in 0 milliseconds
[JBossINF] 15:03:05,855 INFO [org.infinispan.eviction.PassivationManagerImpl] (MSC service thread 1-12) ISPN000030: Passivated 0 entries in 4 milliseconds
[JBossINF] 15:03:05,858 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-12) JBAS010282: Stopped org.jboss.test.clusterbench.ejb.stateful.LocalStatefulSB cache from ejb container
[JBossINF] 15:03:05,858 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-3) JBAS010282: Stopped org.jboss.test.clusterbench.ejb.stateful.RemoteStatefulSBImpl cache from ejb container
[JBossINF] 15:03:05,879 INFO [org.jboss.as.logging] JBAS011503: Restored bootstrap log handlers
[JBossINF] 15:03:05,904 INFO [org.infinispan.eviction.PassivationManagerImpl] ISPN000029: Passivating all entries to disk
[JBossINF] 15:03:05,904 INFO [org.infinispan.eviction.PassivationManagerImpl] ISPN000030: Passivated 0 entries in 0 milliseconds
[JBossINF] 15:03:05,907 INFO [org.jboss.as.clustering.infinispan] JBAS010282: Stopped remote-connector-client-mappings cache from ejb container
[JBossINF] 15:03:05,913 INFO [org.jboss.as.clustering.infinispan] JBAS010282: Stopped repl cache from ejb container
[JBossINF] 15:03:05,939 INFO [org.infinispan.eviction.PassivationManagerImpl] ISPN000029: Passivating all entries to disk
[JBossINF] 15:03:05,940 INFO [org.infinispan.eviction.PassivationManagerImpl] ISPN000030: Passivated 0 entries in 0 milliseconds
[JBossINF] 15:03:05,941 WARN [org.infinispan.jmx.CacheJmxRegistration] ISPN000032: Problems un-registering MBeans: org.infinispan.CacheException: Failure while unregistering mbeans
[JBossINF] at org.infinispan.jmx.ComponentsJmxRegistration.unregisterMBeans(ComponentsJmxRegistration.java:105)
[JBossINF] at org.infinispan.jmx.AbstractJmxRegistration.unregisterMBeans(AbstractJmxRegistration.java:53)
[JBossINF] at org.infinispan.jmx.CacheJmxRegistration.stop(CacheJmxRegistration.java:100)
[JBossINF] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_30]
[JBossINF] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_30]
[JBossINF] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_30]
[JBossINF] at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_30]
[JBossINF] at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:236)
[JBossINF] at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:882)
[JBossINF] at org.infinispan.factories.AbstractComponentRegistry.internalStop(AbstractComponentRegistry.java:672)
[JBossINF] at org.infinispan.factories.AbstractComponentRegistry.stop(AbstractComponentRegistry.java:551)
[JBossINF] at org.infinispan.factories.ComponentRegistry.stop(ComponentRegistry.java:198)
[JBossINF] at org.infinispan.CacheImpl.stop(CacheImpl.java:516)
[JBossINF] at org.infinispan.DecoratedCache.stop(DecoratedCache.java:129)
[JBossINF] at org.infinispan.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:291)
[JBossINF] at org.infinispan.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:291)
[JBossINF] at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.stop(DistributedCacheManager.java:127)
[JBossINF] at org.jboss.as.web.session.DistributableSessionManager.stop(DistributableSessionManager.java:447) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
[JBossINF] at org.apache.catalina.core.StandardContext.stop(StandardContext.java:3995) [jbossweb-7.0.13.Final.jar:]
[JBossINF] at org.jboss.as.web.deployment.WebDeploymentService.stop(WebDeploymentService.java:108) [jboss-as-web-7.1.2.Final-SNAPSHOT.jar:7.1.2.Final-SNAPSHOT]
[JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911)
[JBossINF] at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874)
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [rt.jar:1.6.0_30]
[JBossINF] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [rt.jar:1.6.0_30]
[JBossINF] at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_30]
[JBossINF] Caused by: javax.management.InstanceNotFoundException: jboss.infinispan:type=Cache,name="//default-host//clusterbench(repl_async)",manager="web",component=Activation
[JBossINF] at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1094) [rt.jar:1.6.0_30]
[JBossINF] at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveUnregisterMBean(DefaultMBeanServerInterceptor.java:415) [rt.jar:1.6.0_30]
[JBossINF] at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(DefaultMBeanServerInterceptor.java:403) [rt.jar:1.6.0_30]
[JBossINF] at com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.java:506) [rt.jar:1.6.0_30]
[JBossINF] at org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.unregisterMBean(PluggableMBeanServerImpl.java:584)
[JBossINF] at org.jboss.as.jmx.PluggableMBeanServerImpl.unregisterMBean(PluggableMBeanServerImpl.java:331)
[JBossINF] at org.infinispan.jmx.JmxUtil.unregisterMBean(JmxUtil.java:109)
[JBossINF] at org.infinispan.jmx.ComponentsJmxRegistration.unregisterMBeans(ComponentsJmxRegistration.java:101)
[JBossINF] ... 24 more
[JBossINF]
[JBossINF] 15:03:05,955 INFO [org.jboss.as.clustering.infinispan] JBAS010282: Stopped //default-host//clusterbench cache from web container
[JBossINF] 15:03:05,979 INFO [org.jboss.weld.deployer] JBAS016009: Stopping weld service for deployment clusterbench-ee6.ear
[JBossINF] 15:03:05,992 INFO [org.infinispan.eviction.PassivationManagerImpl] ISPN000029: Passivating all entries to disk
[JBossINF] 15:03:05,993 INFO [org.infinispan.eviction.PassivationManagerImpl] ISPN000030: Passivated 0 entries in 0 milliseconds
[JBossINF] 15:03:06,016 INFO [org.jboss.as.clustering.infinispan] JBAS010282: Stopped repl cache from web container
[JBossINF] 15:03:06,025 INFO [com.arjuna.ats.jbossatx] ARJUNA032018: Destroying TransactionManagerService
[JBossINF] 15:03:06,025 INFO [com.arjuna.ats.jbossatx] ARJUNA032014: Stopping transaction recovery manager
[JBossINF] 15:03:06,030 INFO [org.jboss.as.server.deployment] JBAS015877: Stopped deployment clusterbench-ee6-ejb.jar in 172ms
[JBossINF] 15:03:06,032 INFO [org.jboss.as.server.deployment] JBAS015877: Stopped deployment clusterbench-ee6-web.war in 173ms
[JBossINF] 15:03:06,052 INFO [org.jboss.as.server.deployment] JBAS015877: Stopped deployment clusterbench-ee6.ear in 197ms
[JBossINF] 15:03:06,074 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] ISPN000082: Stopping the RpcDispatcher
[JBossINF] 15:03:06,102 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] ISPN000082: Stopping the RpcDispatcher
[JBossINF] 15:03:06,150 INFO [org.jboss.as] JBAS015950: JBoss AS 7.1.2.Final-SNAPSHOT "Brontes" stopped in 290ms
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (AS7-4682) Make read-resource report child resources of the same type in the same order they appear in the underlying model node
by Kabir Khan (JIRA)
Kabir Khan created AS7-4682:
-------------------------------
Summary: Make read-resource report child resources of the same type in the same order they appear in the underlying model node
Key: AS7-4682
URL: https://issues.jboss.org/browse/AS7-4682
Project: Application Server 7
Issue Type: Feature Request
Components: Domain Management
Reporter: Kabir Khan
Assignee: Kabir Khan
Fix For: 7.1.2.Final-redhat1
If the 'test' resource registration is for a wild card, e.g.
{code}
registration.registerSubModel(PathElement.pathElement("test"), new DescriptionProvider() {
@Override
public ModelNode getModelDescription(Locale locale) {
ModelNode node = new ModelNode();
node.get(DESCRIPTION).set("a test node");
node.get(ATTRIBUTES, "prop", TYPE).set(ModelType.STRING);
node.get(ATTRIBUTES, "prop", DESCRIPTION).set("A test property");
return node;
}
});
{code}
And the model is
{code}
{"test" => {
"g" => {"prop" => "G"},
"e" => {"prop" => "E"},
"l" => {"prop" => "L"},
"d" => {"prop" => "D"},
"h" => {"prop" => "H"},
"k" => {"prop" => "K"},
"f" => {"prop" => "F"},
"a" => {"prop" => "A"},
"b" => {"prop" => "B"},
"j" => {"prop" => "J"},
"c" => {"prop" => "C"},
"i" => {"prop" => "I"}
}}
{code}
A :read-resource(recursive=true) should return the exact same model, e.g.:
{code}
{"test" => {
"g" => {"prop" => "G"},
"e" => {"prop" => "E"},
"l" => {"prop" => "L"},
"d" => {"prop" => "D"},
"h" => {"prop" => "H"},
"k" => {"prop" => "K"},
"f" => {"prop" => "F"},
"a" => {"prop" => "A"},
"b" => {"prop" => "B"},
"j" => {"prop" => "J"},
"c" => {"prop" => "C"},
"i" => {"prop" => "I"}
}}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (JBRULES-3482) accumulate with an "and" predicate followed by an "or" causes a bogus ClassCast exception
by Chris Dolan (JIRA)
Chris Dolan created JBRULES-3482:
------------------------------------
Summary: accumulate with an "and" predicate followed by an "or" causes a bogus ClassCast exception
Key: JBRULES-3482
URL: https://issues.jboss.org/browse/JBRULES-3482
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-compiler
Affects Versions: 5.4.0.CR1
Environment: tested in 5.5.0 git HEAD from today (April 25, 2012). This same bug manifests in 5.4.0.CR1
Reporter: Chris Dolan
Assignee: Mark Proctor
The following unit test exhibits a class cast exception.
The JUnit test code, added to AccumulateTest. It crashes on the last line of the test method.
{noformat}
@Test
public void testAccumulateReverseModifyInsertLogical3() throws Exception {
// read in the source
final Reader reader = new InputStreamReader( getClass().getResourceAsStream( "test_AccumulateReverseModifyInsertLogical3.drl" ) );
final RuleBase ruleBase = loadRuleBase( reader );
final WorkingMemory wm = ruleBase.newStatefulSession();
wm.insert( new Cheese( "stilton", 10 ) );
wm.insert( new Person( "Alice", "brie" ) );
wm.insert( new Person( "Bob", "stilton" ) );
}
{noformat}
This is the rule that causes the crash:
{noformat}
package org.drools.test;
import org.drools.Cheese;
import org.drools.Person;
rule "Class cast causer"
when
$person : Person( $likes : likes )
$total : Number() from accumulate( $p : Person(likes != $likes, $l : likes) and $c : Cheese( type == $l ),
min($c.getPrice()) )
($p2 : Person(name == "nobody") or $p2 : Person(name == "Doug"))
then
System.out.println($p2.getName());
end
{noformat}
And finally this is the resulting stack trace:
{noformat}
org.drools.RuntimeDroolsException: java.lang.ClassCastException: org.drools.Person cannot be cast to org.drools.Cheese
at org.drools.rule.Accumulate.accumulate(Accumulate.java:187)
at org.drools.reteoo.AccumulateNode.addMatch(AccumulateNode.java:852)
at org.drools.reteoo.AccumulateNode.assertObject(AccumulateNode.java:274)
at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497)
at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382)
at org.drools.reteoo.RightInputAdapterNode.assertLeftTuple(RightInputAdapterNode.java:142)
at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:197)
at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:72)
at org.drools.reteoo.JoinNode.assertLeftTuple(JoinNode.java:98)
at org.drools.reteoo.SingleLeftTupleSinkAdapter.doPropagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:197)
at org.drools.reteoo.SingleLeftTupleSinkAdapter.propagateAssertLeftTuple(SingleLeftTupleSinkAdapter.java:72)
at org.drools.reteoo.JoinNode.assertObject(JoinNode.java:147)
at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497)
at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382)
at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235)
at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:337)
at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:298)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:888)
at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:847)
at org.drools.integrationtests.AccumulateTest.testAccumulateReverseModifyInsertLogical3(AccumulateTest.java:622)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
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.ClassCastException: org.drools.Person cannot be cast to org.drools.Cheese
at org.drools.test.Rule_Class_cast_causer_5a3e8961c4834e3d9c174ff2f2d98c7bAccumulateExpression0Invoker.evaluate(Rule_Class_cast_causer_5a3e8961c4834e3d9c174ff2f2d98c7bAccumulateExpression0Invoker.java:21)
at org.drools.base.accumulators.JavaAccumulatorFunctionExecutor.accumulate(JavaAccumulatorFunctionExecutor.java:107)
at org.drools.rule.Accumulate.accumulate(Accumulate.java:178)
... 43 more
{noformat}
My naive theory is that the "and" is causing an off-by-one in the compiler, and it's referencing the value assigned to $p when dereferencing $c in the min().
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (AS7-4656) Operation read-resource with include-runtime=true leads to no result
by Michael Voegele (JIRA)
Michael Voegele created AS7-4656:
------------------------------------
Summary: Operation read-resource with include-runtime=true leads to no result
Key: AS7-4656
URL: https://issues.jboss.org/browse/AS7-4656
Project: Application Server 7
Issue Type: Bug
Components: Domain Management
Affects Versions: 7.1.1.Final
Reporter: Michael Voegele
Assignee: Brian Stansberry
Following operation
{code:xml}
{
"address" : {
"host" : "master",
"server" : "server-1"
},
"operation" : "read-resource",
"recursive" : true,
"proxies" : true,
"include-defaults" : true,
"include-runtime" : true
}
{code}
leads to
{
"outcome" : "success",
"result" : null,
"failure-description" : null
}
but the result is null and there is a huge stacktrace in log beginning with java.lang.UnsupportedOperationException.
When combination of recursive=true and include-runtime=true is not allowed, the operation should fail.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (JBRULES-3320) Stateful memory corruption for repetitive updates on the same facts
by guy ramirez (Created) (JIRA)
Stateful memory corruption for repetitive updates on the same facts
-------------------------------------------------------------------
Key: JBRULES-3320
URL: https://issues.jboss.org/browse/JBRULES-3320
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: drools-core (expert)
Affects Versions: 5.4.0.Beta1, 5.3.0.Final
Environment: Windows 7 64, Java HotSpot(TM) 64-Bit Server 1.6.0_25
Reporter: guy ramirez
Assignee: Mark Proctor
Multiple updates to the same fact does not yield the expected results (similar to JBRULES-2809 issue)
The provided UT (see 'steps to reproduce' section) makes use of 2 fact instances: one IntervalRequirement (never updated) and one ShiftAssignment.
The same ShiftAssignment will be updated multiple times to cover one or more IntervalRequirement(s).
Here is the output of the test without executing the assertions. For each update I have added comments explaining what the expected results should be:
Update #1: ShiftAssignment set from 100 to 101
intervalRequirementPartiallyCovered -> IntervalRequirement: interval: 100, staffingRequired: 2 covered by 1 ShiftAssignment(s)
intervalRequirementNotCovered -> IntervalRequirement: interval: 103, staffingRequired: 2
intervalRequirementNotCovered -> IntervalRequirement: interval: 102, staffingRequired: 2
intervalRequirementNotCovered -> IntervalRequirement: interval: 101, staffingRequired: 2
COMMENTS: correct
Update #2:ShiftAssignment set from 100 to 103
intervalRequirementPartiallyCovered -> IntervalRequirement: interval: 101, staffingRequired: 2 covered by 1 ShiftAssignment(s)
intervalRequirementPartiallyCovered -> IntervalRequirement: interval: 102, staffingRequired: 2 covered by 1 ShiftAssignment(s)
intervalRequirementPartiallyCovered -> IntervalRequirement: interval: 100, staffingRequired: 2 covered by 1 ShiftAssignment(s)
COMMENTS: intervalRequirementNotCovered rule should have fired for interval 103
Update #3:ShiftAssignment set from 100 to 102
intervalRequirementNotCovered -> IntervalRequirement: interval: 102, staffingRequired: 2
intervalRequirementPartiallyCovered -> IntervalRequirement: interval: 101, staffingRequired: 2 covered by 1 ShiftAssignment(s)
intervalRequirementPartiallyCovered -> IntervalRequirement: interval: 100, staffingRequired: 2 covered by 1 ShiftAssignment(s)
COMMENT: intervalRequirementNotCovered rule should have fired for interval 103
Update #4:ShiftAssignment set from 100 to 104
intervalRequirementPartiallyCovered -> IntervalRequirement: interval: 102, staffingRequired: 2 covered by 1 ShiftAssignment(s)
intervalRequirementPartiallyCovered -> IntervalRequirement: interval: 103, staffingRequired: 2 covered by 1 ShiftAssignment(s)
intervalRequirementPartiallyCovered -> IntervalRequirement: interval: 101, staffingRequired: 2 covered by 1 ShiftAssignment(s)
intervalRequirementPartiallyCovered -> IntervalRequirement: interval: 100, staffingRequired: 2 covered by 1 ShiftAssignment(s)
COMMENT: correct
Update #5:ShiftAssignment set from 100 to 101
intervalRequirementTotallyCovered -> IntervalRequirement: interval: 100, staffingRequired: 2 covered by 2 ShiftAssignment(s)
intervalRequirementNotCovered -> IntervalRequirement: interval: 103, staffingRequired: 2
intervalRequirementNotCovered -> IntervalRequirement: interval: 102, staffingRequired: 2
intervalRequirementNotCovered -> IntervalRequirement: interval: 101, staffingRequired: 2
COMMENT: results should have been identical of that of update #1: intervalRequirementPartiallyCovered should have fired for interval 100, instead intervalRequirementTotallyCovered rule fired.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months
[JBoss JIRA] (JBJCA-730) Problem with IronJacamar .jar's
by Ondrej Zizka (JIRA)
Ondrej Zizka created JBJCA-730:
----------------------------------
Summary: Problem with IronJacamar .jar's
Key: JBJCA-730
URL: https://issues.jboss.org/browse/JBJCA-730
Project: IronJacamar
Issue Type: Bug
Components: Build
Affects Versions: 1.1.0.Alpha4
Environment: Linux, Java Sun 1.6.26 x64
Reporter: Ondrej Zizka
Assignee: Jesper Pedersen
Attachments: Emma-ZipException-Jacamar.txt
When I use various tools to manipulate AS jars, this happens with IronJacamar jars:
Caused by: java.util.zip.ZipException: invalid entry compressed size (expected 576 but got 577 bytes)
at java.util.zip.ZipOutputStream.closeEntry(ZipOutputStream.java:206)
at com.vladium.emma.instr.InstrProcessorST.writeZipEntry(InstrProcessorST.java:838)
at com.vladium.emma.instr.InstrProcessorST$EntryWriteJob.run(InstrProcessorST.java:905)
at com.vladium.emma.instr.InstrProcessorST.drainJobQueue(InstrProcessorST.java:943)
at com.vladium.emma.instr.InstrProcessorST.handleArchiveEnd(InstrProcessorST.java:353)
... 5 more
How are they packaged? Some special buggy tool?
It prevents me from preparing coverage reports, both Emma and JaCoco are affected.
STR:
1) Checkout and build AS7 master
2) wget --no-check-certificate https://repository.jboss.org/nexus/content/groups/developer/emma/emma/2.1... -O emma.jar
3)
{code:bash}
for i in `find $AS_DIR/modules/org/jboss/ -name '*.jar'`; do
echo "============ $i"
java -cp emma.jar emma instr -outmode overwrite -merge yes -instrpath $i;
done
{code}
Only IronJacamar jars cause problems, others are fine.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 2 months