[JBoss JIRA] (DROOLS-523) KieContainer#updateToVersion does not update globals
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-523?page=com.atlassian.jira.plugin... ]
Mario Fusco reassigned DROOLS-523:
----------------------------------
Assignee: Mario Fusco (was: Mark Proctor)
> KieContainer#updateToVersion does not update globals
> ----------------------------------------------------
>
> Key: DROOLS-523
> URL: https://issues.jboss.org/browse/DROOLS-523
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.Final
> Reporter: Mike Wilson
> Assignee: Mario Fusco
> Labels: backport-to-6.0.x
> Fix For: 6.1.0.Final
>
>
> When the original version of a KieModule does not contain a given global, but the new version does, it is impossible to set the global after upgrading from the original version to the new version.
> The following unit test can be added to [IncrementalCompilationTest.java|https://github.com/droolsjbpm/drools/blob...] and executed to demonstrate the problem:
> {code:title=IncrementalCompilationTest.java}
> @Test
> public void testKJarUpgradeSameSessionAddingGlobal() throws Exception {
> String drl1 = "package org.drools.compiler\n" +
> "rule R1 when\n" +
> " $m : Message()\n" +
> "then\n" +
> "end\n";
> String drl2_1 = "package org.drools.compiler\n" +
> "rule R2_1 when\n" +
> " $m : Message( message == \"Hi Universe\" )\n" +
> "then\n" +
> "end\n";
> String drl2_2 = "package org.drools.compiler\n" +
> "global java.lang.String foo\n" +
> "rule R2_2 when\n" +
> " $m : Message( message == \"Hello World\" )\n" +
> "then\n" +
> "end\n";
> KieServices ks = KieServices.Factory.get();
> // Create an in-memory jar for version 1.0.0
> ReleaseId releaseId1 = ks.newReleaseId( "org.kie", "test-upgrade", "1.0.0" );
> KieModule km = createAndDeployJar( ks, releaseId1, drl1, drl2_1 );
> // Create a session and fire rules
> KieContainer kc = ks.newKieContainer( km.getReleaseId() );
> KieSession ksession = kc.newKieSession();
> ksession.insert( new Message( "Hello World" ) );
> assertEquals( 1, ksession.fireAllRules() );
> // Create a new jar for version 1.1.0
> ReleaseId releaseId2 = ks.newReleaseId( "org.kie", "test-upgrade", "1.1.0" );
> km = createAndDeployJar( ks, releaseId2, drl1, drl2_2 );
> // try to update the container to version 1.1.0
> kc.updateToVersion( releaseId2 );
>
> ksession.setGlobal("foo", "bar");
> // continue working with the session
> ksession.insert( new Message( "Hello World" ) );
> assertEquals( 3, ksession.fireAllRules() );
> }
> {code}
> When I run this unit test, I get the following exception:
> {code}
> java.lang.RuntimeException: Unexpected global [foo]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.setGlobal(StatefulKnowledgeSessionImpl.java:1089)
> at org.drools.compiler.integrationtests.IncrementalCompilationTest.testKJarUpgradeSameSessionAddingGlobal(IncrementalCompilationTest.java:239)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years
[JBoss JIRA] (DROOLS-523) KieContainer#updateToVersion does not update globals
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-523?page=com.atlassian.jira.plugin... ]
Mario Fusco resolved DROOLS-523.
--------------------------------
Fix Version/s: 6.1.0.Final
Resolution: Done
Fixed by https://github.com/droolsjbpm/drools/commit/184765346
> KieContainer#updateToVersion does not update globals
> ----------------------------------------------------
>
> Key: DROOLS-523
> URL: https://issues.jboss.org/browse/DROOLS-523
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.Final
> Reporter: Mike Wilson
> Assignee: Mario Fusco
> Fix For: 6.1.0.Final
>
>
> When the original version of a KieModule does not contain a given global, but the new version does, it is impossible to set the global after upgrading from the original version to the new version.
> The following unit test can be added to [IncrementalCompilationTest.java|https://github.com/droolsjbpm/drools/blob...] and executed to demonstrate the problem:
> {code:title=IncrementalCompilationTest.java}
> @Test
> public void testKJarUpgradeSameSessionAddingGlobal() throws Exception {
> String drl1 = "package org.drools.compiler\n" +
> "rule R1 when\n" +
> " $m : Message()\n" +
> "then\n" +
> "end\n";
> String drl2_1 = "package org.drools.compiler\n" +
> "rule R2_1 when\n" +
> " $m : Message( message == \"Hi Universe\" )\n" +
> "then\n" +
> "end\n";
> String drl2_2 = "package org.drools.compiler\n" +
> "global java.lang.String foo\n" +
> "rule R2_2 when\n" +
> " $m : Message( message == \"Hello World\" )\n" +
> "then\n" +
> "end\n";
> KieServices ks = KieServices.Factory.get();
> // Create an in-memory jar for version 1.0.0
> ReleaseId releaseId1 = ks.newReleaseId( "org.kie", "test-upgrade", "1.0.0" );
> KieModule km = createAndDeployJar( ks, releaseId1, drl1, drl2_1 );
> // Create a session and fire rules
> KieContainer kc = ks.newKieContainer( km.getReleaseId() );
> KieSession ksession = kc.newKieSession();
> ksession.insert( new Message( "Hello World" ) );
> assertEquals( 1, ksession.fireAllRules() );
> // Create a new jar for version 1.1.0
> ReleaseId releaseId2 = ks.newReleaseId( "org.kie", "test-upgrade", "1.1.0" );
> km = createAndDeployJar( ks, releaseId2, drl1, drl2_2 );
> // try to update the container to version 1.1.0
> kc.updateToVersion( releaseId2 );
>
> ksession.setGlobal("foo", "bar");
> // continue working with the session
> ksession.insert( new Message( "Hello World" ) );
> assertEquals( 3, ksession.fireAllRules() );
> }
> {code}
> When I run this unit test, I get the following exception:
> {code}
> java.lang.RuntimeException: Unexpected global [foo]
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.setGlobal(StatefulKnowledgeSessionImpl.java:1089)
> at org.drools.compiler.integrationtests.IncrementalCompilationTest.testKJarUpgradeSameSessionAddingGlobal(IncrementalCompilationTest.java:239)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> 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)
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years
[JBoss JIRA] (DROOLS-509) Constraint method is resolved erroneously when potential ambiguities exist
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-509?page=com.atlassian.jira.plugin... ]
Mario Fusco commented on DROOLS-509:
------------------------------------
I tried to reproduce this problem with the following test case also switching the MvelConstraint.TEST_JITTING flag to true but it works for me and I couldn't generate any CCE. Am I missing something?
{code}
public interface I0 {
String getValue();
}
public interface I1 extends I0 { }
public static class X implements I1 {
@Override
public String getValue() {
return "x";
}
}
public static class Y implements I1 {
@Override
public String getValue() {
return "y";
}
}
@Test
public void testMethodResolution() throws Exception {
// DROOLS-509
String drl =
"import " + I1.class.getCanonicalName() + ";\n" +
"rule R when\n" +
" I1 ( value == \"x\" )\n" +
"then\n" +
"end";
KieHelper helper = new KieHelper();
helper.addContent( drl, ResourceType.DRL );
KieSession ksession = helper.build().newKieSession();
ksession.insert(new X());
ksession.fireAllRules();
ksession.insert(new Y());
ksession.fireAllRules();
}
{code}
> Constraint method is resolved erroneously when potential ambiguities exist
> --------------------------------------------------------------------------
>
> Key: DROOLS-509
> URL: https://issues.jboss.org/browse/DROOLS-509
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.6.0.Final, 6.1.0.Beta4
> Reporter: Davide Sottara
> Assignee: Mario Fusco
> Priority: Critical
> Fix For: 6.1.0.CR1
>
>
> Assume:
> Class X implement I1
> Interface I1 extends I0
> I0 defines the property foo
> Write a rule:
> I1( foo == .. )
> and insert an instance of class X
> The condition analyzer will look in classes first, rather than interfaces, assuming that "foo" is provided by X.
> The next time an instance of some class Y implementing I1 is inserted,
> a ClassCastException will be thrown since X is expected
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years
[JBoss JIRA] (WFLY-3435) jboss-as-infinispan_1_X.xsd schema has incorrect default value for flush-lock-timeout in write-behind
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3435?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-3435:
---------------------------------
Fix Version/s: (was: 8.2.0.CR1)
> jboss-as-infinispan_1_X.xsd schema has incorrect default value for flush-lock-timeout in write-behind
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-3435
> URL: https://issues.jboss.org/browse/WFLY-3435
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 9.0.0.Alpha1
>
>
> Description of problem:
> In org.infinispan.loaders.decorators.AsyncStoreConfig, the default flushLockTimeout is set to 5000. However, the default in the JBoss Infinispan schema ($JBOSS_HOME/docs/schema/jboss-as-infinispan_1_X.xsd) is set to 1. Because of this, if the thread-pool-size for write-behind is increased, then it is likely that one of the threads will not be able to obtain the state map lock within the 1 millisecond time provided by the schema default. This results in the following error:
> ERROR o.i.loaders.decorators.AsyncStore.run - ISPN000051: Unexpected error
> org.infinispan.CacheException: Unable to acquire lock on update map
> at org.infinispan.loaders.decorators.AsyncStore.acquireLock(AsyncStore.java:293) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL]
> at org.infinispan.loaders.decorators.AsyncStore.access$900(AsyncStore.java:86) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL]
> at org.infinispan.loaders.decorators.AsyncStore$AsyncProcessor.innerRun(AsyncStore.java:336) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL]
> at org.infinispan.loaders.decorators.AsyncStore$AsyncProcessor.run(AsyncStore.java:312) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) ~[na:1.6.0_31]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) ~[na:1.6.0_31]
> at java.lang.Thread.run(Thread.java:662) ~[na:1.6.0_31]
> Version-Release number of selected component (if applicable):
> Infinispan version 5.1.8
> How reproducible:
> Code inspection
> Steps to Reproduce:
> 1. Check the default value for flush-lock-timeout in $JBOSS_HOME/docs/schema/jboss-as-infinispan_1_3.xsd
> 2. Check the default value for flushLockTimeout in the org.infinispan.loaders.decorators.AsyncStoreConfig class
> 3. Note the disparity
> Actual results:
> Default in schema is 1
> Expected results:
> Default in schema is 5000
> Additional info:
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years
[JBoss JIRA] (WFLY-3435) jboss-as-infinispan_1_X.xsd schema has incorrect default value for flush-lock-timeout in write-behind
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-3435?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-3435:
--------------------------------------
Rebased and resubmitted original pull request.
> jboss-as-infinispan_1_X.xsd schema has incorrect default value for flush-lock-timeout in write-behind
> -----------------------------------------------------------------------------------------------------
>
> Key: WFLY-3435
> URL: https://issues.jboss.org/browse/WFLY-3435
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.0.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Fix For: 9.0.0.Alpha1
>
>
> Description of problem:
> In org.infinispan.loaders.decorators.AsyncStoreConfig, the default flushLockTimeout is set to 5000. However, the default in the JBoss Infinispan schema ($JBOSS_HOME/docs/schema/jboss-as-infinispan_1_X.xsd) is set to 1. Because of this, if the thread-pool-size for write-behind is increased, then it is likely that one of the threads will not be able to obtain the state map lock within the 1 millisecond time provided by the schema default. This results in the following error:
> ERROR o.i.loaders.decorators.AsyncStore.run - ISPN000051: Unexpected error
> org.infinispan.CacheException: Unable to acquire lock on update map
> at org.infinispan.loaders.decorators.AsyncStore.acquireLock(AsyncStore.java:293) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL]
> at org.infinispan.loaders.decorators.AsyncStore.access$900(AsyncStore.java:86) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL]
> at org.infinispan.loaders.decorators.AsyncStore$AsyncProcessor.innerRun(AsyncStore.java:336) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL]
> at org.infinispan.loaders.decorators.AsyncStore$AsyncProcessor.run(AsyncStore.java:312) ~[infinispan-core-5.1.3.FINAL.jar:5.1.3.FINAL]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) ~[na:1.6.0_31]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) ~[na:1.6.0_31]
> at java.lang.Thread.run(Thread.java:662) ~[na:1.6.0_31]
> Version-Release number of selected component (if applicable):
> Infinispan version 5.1.8
> How reproducible:
> Code inspection
> Steps to Reproduce:
> 1. Check the default value for flush-lock-timeout in $JBOSS_HOME/docs/schema/jboss-as-infinispan_1_3.xsd
> 2. Check the default value for flushLockTimeout in the org.infinispan.loaders.decorators.AsyncStoreConfig class
> 3. Note the disparity
> Actual results:
> Default in schema is 1
> Expected results:
> Default in schema is 5000
> Additional info:
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years
[JBoss JIRA] (JGRP-1841) Discovery: reduce number of discovery requests to backend store
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1841?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1841.
----------------------------
Resolution: Done
> Discovery: reduce number of discovery requests to backend store
> ----------------------------------------------------------------
>
> Key: JGRP-1841
> URL: https://issues.jboss.org/browse/JGRP-1841
> Project: JGroups
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> The goal is to reduce the number of discovery calls to a backend store, e.g. for {{FILE_PING}} if located on a shared drive (using read and write RPCs) and all cloud store discovery protocols such as {{S3_PING}}, {{RACKSPACE_PING}}, {{SWIFT_PING}} and {{GOOGLE_PING}}.
> This is mainly done by
> * Having *one file* containing the information for *all members* rather than a single file *per member*. This means just *1 read instead of N reads* (N= cluster size)
> * Providing a boostrap file containing the UUID, logical name and IP address of *all members* up front
> For example, if we start a cluster of 1000 nodes, the cost of the existing mechanism would be 1 for the first member, 2 for the second etc, for a total of roughly N*N/2 = ~500'000 calls. With the new algorithm, it would be N = 1'000 calls.
> Not only does this save money (if a cloud store is used, ingress or egress traffic may be charged for), but also reduces overall latency by making fewer calls.
> The _members file_ lists *all* members in a boostrap file in the following format:
> || Logical name || UUID || IP address:port || coord ||
> | A | 1 | 192.168.1.5:7800 | true |
> | B | 2 | 192.168.1.6:7800 | false |
> | C | 3 | 192.168.1.7:7800 | false |
> The file could be located on a (shared) file system, S3, a DB table or a cloud store.
> *This could possibly be an alternative impl of {{FILE_PING}}, {{S3_PING}}, {{GOOGLE_PING}}, {{SWIFT_PING}} etc.*
> On startup, the static discovery protocol reads this file and populates the {{UUID.cache}} and {{TP.logical_addr_cache}} caches in the transport.
> Once this is done, there is no need for lookups as the caches should have the complete information. Note that {{TP.logical_addr_cache_max_size}} should be greater than the max number of nodes.
> When nodes are started, they need to be given the logical name and UUID indicated in the file. The former can be done via {{JChannel.name(String name)}}, the latter should be done via an {{AddressGenerator}}.
> Note that UUIDs cannot be reused, so when a channel is disconnected and subsequently reconnected, the address generator should pick a different UUID (perhaps a random one). This should be reflected in the config file as well.
> Also, nodes need to be started in the order in which they are listed. The coordinator to contact for joining the cluster is marked, so ideally only 1 JOIN req-rsp round is needed.
> h5. The goals of this protocol are:
> * Used when IP multicast is not available
> * Quick startup
> * Reducing the number of calls to the cloud store (latency!)
> ** Instead of N calls to the (cloud) store, only 1 call is needed (to read the file)
> * Large clusters: using N-1 for multicast simulation quickly generates too much traffic in the discovery phase
> h5. Coordinator changes
> When the coordinator changes, the new coordinator needs to update the file; changing the coordinatorship so nodes started after this will contact the right coordinator.
> h5. New members (not listed) join
> This could be handled by either changing the bootstrap file manually or dynamically:
> * The new member reads the file and sends an INFO message with its UUID, logical_name and IP address to all members
> ** (This is done before sending a JOIN request to the coordinator)
> * Every member updates their local cache when receiving the INFO message
> * The coordinator, upon reception of an INFO message, updates the file
> ** This ensures that only 1 node (the coord) updates the file and prevents corruption of the file through concurrent updates
> h5. References
> See https://github.com/belaban/JGroups/blob/master/doc/design/CloudBasedDisco... for the design
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
12 years