[JBoss JIRA] (DROOLS-951) Removing 2 or more rules does not retract justified objects
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-951?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-951:
------------------------------------------------
Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1273087|https://bugzilla.redhat.com/show_bug.cgi?id=1273087] from ON_QA to ASSIGNED
> Removing 2 or more rules does not retract justified objects
> -----------------------------------------------------------
>
> Key: DROOLS-951
> URL: https://issues.jboss.org/browse/DROOLS-951
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Reporter: Zvonimir Bošnjak
> Assignee: Mario Fusco
> Fix For: 6.4.x
>
>
> When removing rules from knowledge which have logically inserted (justified) objects, only one object (from first removed rule) will be retracted.
> In example from AddRemoveRule#184: as it removes the first rule, it re-initializes all other path memories and, in particular, marks them as unlinked (AbstractTerminalNode#204)
> Later, when it tries to flush the deletions (AddRemoveRule#280), the unlinked status prevents the propagation from taking place.
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (DROOLS-930) ClassCastException after segment split during incremental compilation
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-930?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-930:
------------------------------------------------
Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1273087|https://bugzilla.redhat.com/show_bug.cgi?id=1273087] from ON_QA to ASSIGNED
> ClassCastException after segment split during incremental compilation
> ---------------------------------------------------------------------
>
> Key: DROOLS-930
> URL: https://issues.jboss.org/browse/DROOLS-930
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.4.x
>
>
> A segment split during an incremental compilation as in the following test case
> {code}
> @Test
> public void testSegmentSplitOnIncrementalCompilation() throws Exception {
> String drl =
> "import " + Person.class.getCanonicalName() + "\n" +
> "rule R1 when\n" +
> " $s : String()" +
> " Person( name == $s ) \n" +
> "then\n" +
> " System.out.println(\"Triggered: R1\");\n" +
> "end\n" +
> "rule R2 when\n" +
> " $s : String()" +
> " Person( name == $s ) \n" +
> "then\n" +
> " System.out.println(\"Triggered: R2\");\n" +
> "end\n" +
> "rule R3 when\n" +
> " $s : String()" +
> " Person( name != $s ) \n" +
> "then\n" +
> " System.out.println(\"Triggered: R3\");\n" +
> "end\n";
> KieServices ks = KieServices.Factory.get();
> ReleaseId releaseId1 = ks.newReleaseId("org.kie", "test-upgrade", "1.1.1");
> KieModule km = createAndDeployJar(ks, releaseId1);
> KieContainer kc = ks.newKieContainer(km.getReleaseId());
> KieSession ksession = kc.newKieSession();
> kc.updateToVersion(releaseId1);
> ksession.insert(new Person("John", 26));
> ksession.insert( "John" );
> ksession.fireAllRules();
> ReleaseId releaseId2 = ks.newReleaseId("org.kie", "test-upgrade", "1.1.2");
> km = createAndDeployJar(ks, releaseId2, drl);
> kc.updateToVersion(releaseId2);
> ksession.fireAllRules();
> }
> {code}
> may cause the following ClassCastException during the subsequent network evaluation
> {code}
> java.lang.ClassCastException: org.drools.core.reteoo.RuleTerminalNode cannot be cast to org.drools.core.reteoo.LeftInputAdapterNode
> at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:99)
> at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194)
> at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73)
> at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:978)
> at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1292)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1294)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1260)
> at org.drools.compiler.integrationtests.IncrementalCompilationTest.testSegmentSplit(IncrementalCompilationTest.java:2001)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5549) org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-5549?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-5549:
------------------------------------
Do you have dom4j jar in your application? That is causing this problem since Hibernate is trying to use the dom4j in wildfly/modules/system/layers/base/org/dom4j/main/dom4j-1.6.1.jar, but is seeing the application copy of dom4j instead. You need to remove the dom4j jar from your application. If this is not the case, show us the output from doing "jar tf cooperativa-1.0.0.Final.war"
> org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> ---------------------------------------------------------------------
>
> Key: WFLY-5549
> URL: https://issues.jboss.org/browse/WFLY-5549
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Reporter: carlos feria
> Assignee: Scott Marlow
>
> 10:06:35,545 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 61) MSC000001: Failed to start service jboss.persistenceunit."********": org.jboss.msc.service.StartException in service jboss.persistenceunit."*******": java.lang.ClassCastException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:172)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:117)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:667)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:182)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.ClassCastException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> at org.dom4j.DocumentFactory.getInstance(DocumentFactory.java:97)
> at org.hibernate.internal.util.xml.XMLHelper$1.doWork(XMLHelper.java:33)
> at org.hibernate.internal.util.xml.XMLHelper$1.doWork(XMLHelper.java:27)
> at org.hibernate.boot.registry.classloading.internal.ClassLoaderServiceImpl.workWithClassLoader(ClassLoaderServiceImpl.java:342)
> at org.hibernate.internal.util.xml.XMLHelper.<init>(XMLHelper.java:26)
> at org.hibernate.envers.boot.internal.EnversServiceImpl.initialize(EnversServiceImpl.java:115)
> at org.hibernate.envers.boot.internal.AdditionalJaxbMappingProducerImpl.produceAdditionalMappings(AdditionalJaxbMappingProducerImpl.java:99)
> at org.hibernate.boot.model.process.spi.MetadataBuildingProcess.complete(MetadataBuildingProcess.java:288)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.metadata(EntityManagerFactoryBuilderImpl.java:770)
> at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:797)
> at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
> at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:154)
> ... 7 more
> 10:06:35,552 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 2) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "cooperativa-1.0.0.Final.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.persistenceunit.\"cooperativa-1.0.0.Final.war#CooperativaPU\"" => "org.jboss.msc.service.StartException in service jboss.persistenceunit.\"cooperativa-1.0.0.Final.war#CooperativaPU\": java.lang.ClassCastException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
> Caused by: java.lang.ClassCastException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory"}}
> 10:06:35,732 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) WFLYSRV0010: Deployed "cooperativa-1.0.0.Final.war" (runtime-name : "cooperativa-1.0.0.Final.war")
> 10:06:35,733 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) WFLYCTL0183: Service status report
> WFLYCTL0186: Services which failed to start: service jboss.persistenceunit."cooperativa-1.0.0.Final.war#CooperativaPU": org.jboss.msc.service.StartException in service jboss.persistenceunit."cooperativa-1.0.0.Final.war#CooperativaPU": java.lang.ClassCastException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-4970) After removing a resource through the CLI, one with the same name can not be added
by David Frank (JIRA)
[ https://issues.jboss.org/browse/WFLY-4970?page=com.atlassian.jira.plugin.... ]
David Frank commented on WFLY-4970:
-----------------------------------
What does "reload" mean? Is it restarting the application server process or is there a reload command that I missed?
> After removing a resource through the CLI, one with the same name can not be added
> ----------------------------------------------------------------------------------
>
> Key: WFLY-4970
> URL: https://issues.jboss.org/browse/WFLY-4970
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.2.0.Final
> Environment: Windows 7 64-bit, Java 7
> Reporter: David Frank
> Assignee: Brian Stansberry
>
> If a resource (tested with a datasource and a security domain) is removed using the CLI, a new resource (of the same type) with the same name can not be added. The CLI shows the resource as removed, but an error will always be returned to the caller indicating that the resource already exists. In the Wildfly server log, you see a DuplicateServiceException.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (JBJCA-1300) <datasource-class> in <driver> is ignored
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/JBJCA-1300?page=com.atlassian.jira.plugin... ]
Jesper Pedersen resolved JBJCA-1300.
------------------------------------
Fix Version/s: WildFly/IronJacamar 1.3.2.Final
1.2.7.Final
Resolution: Done
> <datasource-class> in <driver> is ignored
> -----------------------------------------
>
> Key: JBJCA-1300
> URL: https://issues.jboss.org/browse/JBJCA-1300
> Project: IronJacamar
> Issue Type: Bug
> Components: Deployer
> Reporter: Martin Simka
> Assignee: Jesper Pedersen
> Priority: Critical
> Fix For: WildFly/IronJacamar 1.3.2.Final, 1.2.7.Final
>
>
> {code:xml}
> <driver name="oracle-ucp" module="com.oracle.ucp">
> <xa-datasource-class>[class]</xa-datasource-class>
> <datasource-class>[class]</datasource-class>
> </driver>
> {code}
> datasource-class setting is ignored and Driver class is used instead, DataSource class should have priority over Driver if defined
> <datasource-class> in <datasource> works
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-4890) IronJacamar: pool gracefull flush
by Jesper Pedersen (JIRA)
[ https://issues.jboss.org/browse/WFLY-4890?page=com.atlassian.jira.plugin.... ]
Jesper Pedersen closed WFLY-4890.
---------------------------------
Resolution: Out of Date
> IronJacamar: pool gracefull flush
> ---------------------------------
>
> Key: WFLY-4890
> URL: https://issues.jboss.org/browse/WFLY-4890
> Project: WildFly
> Issue Type: Feature Request
> Components: JCA
> Reporter: Bartosz Baranowski
> Assignee: Jesper Pedersen
> Attachments: jboss_eap_6.4.1_flush_pool_gracefully.tar.gz
>
>
> This RFE comes from EAP BZ:
> Sample implemenation of flush-all-connection-gracefully-in-pool
> Description of problem:
> A new operation for flushing all connections in pool GRACEFULLY is needed. It was available in JBoss EAP 5 and is missing in EAP 6.
> Currently JBoss EAP 6 provides two options to flush pools:
> 1) flush-idle-connection-in-pool
> Closes connections not used by application (in pool)
> 2) flush-all-connection-in-pool
> Closes all connections in pool. This operations causes exceptions on connections that are in use by application.
> A third operation is needed to flush all connections in pool without immediate kill of in-use connections. It should operate as follows:
> 1) close idle connections (just as flush-idle-connection-in-pool)
> 2) mark all in-use connections for need of destroying when returned to pool
> 3) immediately on return of connection to by application to pool close the connection
> This operation is needed to support load-balancing of connections in clusters for external providers. Examples:
> 1) JMS connections even load-balacing of connections. After JMS server restart, connections need to be reopened to evenly spread connections among servers.
> 2) Oracle RAC service migration. After the service is migrated between RAC nodes, DB connections to old node can linger for very long time (many days) to old node.
> 3) operation teams need to refresh all connections sometimes (external server maintanance)
> Version-Release number of selected component (if applicable): JBoss EAP 6.x
> How reproducible: always
> Steps to Reproduce: not possible, functionallity is missing
> Expected results: new operation available on JMS and DB pools
> Additional info: a sample implementation provided in attachment as patches to 6.4.1 (ironjacamar and jboss-as-connector). The new operation is named "flush-all-connection-gracefully-in-pool" and is available for JMS and DB pools. It doesn't modify any other places like web console, etc.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-4971) lots of warnings discarded message from different cluster
by Witold Bołt (JIRA)
[ https://issues.jboss.org/browse/WFLY-4971?page=com.atlassian.jira.plugin.... ]
Witold Bołt commented on WFLY-4971:
-----------------------------------
Could you please point out more details on the suggested workarounds.
The problem discussed here is present when using Wildfly 9 cluster configured according to the official documentation: https://docs.jboss.org/author/display/WFLY9/WildFly+9+Cluster+Howto
I'm not sure which of the 2 suggested workarounds should be applied, and how exactly should it be done.
> lots of warnings discarded message from different cluster
> ---------------------------------------------------------
>
> Key: WFLY-4971
> URL: https://issues.jboss.org/browse/WFLY-4971
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 9.0.0.Final
> Reporter: Daniele Pirola
> Assignee: Paul Ferraro
>
> I run the latest wildfly-9.0.0.Final. I have an environment with 2 host and 3 server per host. I noticed that there are a lot of warning like this
> JGRP000012: discarded message from different cluster hq-cluster (our cluster is ee)
> or this
> JGRP000012: discarded message from different cluster ee (our cluster is hq-cluster)
> With the same configuration in wildfly-8.2.0.Final I didn't noticed anything.
> The strange thing is that warnings still appear even if I run only the domain controller with 1 server active. I think that the domain configuration (I used the default with full-ha profile) is missing something that can diffentiate jgroup channel but I don't know how
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (JGRP-1891) org.jgroups.tests.ConnectStressTest.testConcurrentJoining fails randomly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JGRP-1891?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on JGRP-1891:
-----------------------------------------------
Romain Pelisse <rpelisse(a)redhat.com> changed the Status of [bug 1138568|https://bugzilla.redhat.com/show_bug.cgi?id=1138568] from NEW to CLOSED
> org.jgroups.tests.ConnectStressTest.testConcurrentJoining fails randomly
> ------------------------------------------------------------------------
>
> Key: JGRP-1891
> URL: https://issues.jboss.org/browse/JGRP-1891
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.2.13
> Environment: too rare to pinpoint, seen on RHEL
> Reporter: Richard Janík
> Assignee: Bela Ban
> Priority: Minor
> Attachments: log.txt
>
>
> org.jgroups.tests.ConnectStressTest.testConcurrentJoining seems to fail at random, roughly 1 fail in 50 executions (or more). Standard output can be found in referenced BZ or among attachments (a newer one).
> link: https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6x-manu-jgroups-...
> {code}
> Error Message
> view doesn't have size of 20 (has 19): [7|2] [7, 20, 2, 14, 9, 18, 13, 8, 16, 15, 10, 4, 1, 12, 3, 6, 11, 5, 17]
> Stacktrace
> java.lang.AssertionError
> at org.jgroups.tests.ConnectStressTest.testConcurrentJoining(ConnectStressTest.java:91)
> 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.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:84)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:714)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months