[JBoss JIRA] (WFLY-2203) Error deploying multiple *-ds.xml files
by Isa Isa (JIRA)
[ https://issues.jboss.org/browse/WFLY-2203?page=com.atlassian.jira.plugin.... ]
Isa Isa commented on WFLY-2203:
-------------------------------
Hi I have added all my DS to the standalone.xml and it works fine. I will test multiple-ds after the next release
> Error deploying multiple *-ds.xml files
> ---------------------------------------
>
> Key: WFLY-2203
> URL: https://issues.jboss.org/browse/WFLY-2203
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: JCA
> Affects Versions: 8.0.0.Beta1
> Reporter: Nick Howes
> Assignee: Stefano Maestri
> Priority: Minor
> Fix For: 8.0.0.Final
>
>
> Our individual *-ds.xml datasources were all deploying fine in Alpha4 but in the Beta1 nightlies this error appears on startup:
> {noformat}
> 15:07:52,111 ERROR [org.jboss.msc.service] (MSC service thread 1-4) MSC000002: Invocation of listener "org.jboss.as.connector.subsystems.datasources.D
> ataSourceStatisticsListener@7d18ac99" failed: java.lang.IllegalArgumentException: JBAS014742: A node is already registered at '(deployment => *)(subsy
> stem => datasources)(data-source => *)(statistics => jdbc)'
> at org.jboss.as.controller.registry.NodeSubregistry.register(NodeSubregistry.java:86) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1
> -SNAPSHOT]
> at org.jboss.as.controller.registry.ConcreteResourceRegistration.registerSubModel(ConcreteResourceRegistration.java:149) [wildfly-controller-8
> .0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.registry.AbstractResourceRegistration.registerSubModel(AbstractResourceRegistration.java:90) [wildfly-controller-8.
> 0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.connector.subsystems.datasources.DataSourceStatisticsListener.transition(DataSourceStatisticsListener.java:72) [wildfly-connec
> tor-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1533) [jboss-msc-1.2.0.Beta2.jar:1.2.0.Beta2]
> {noformat}
> Our datasource files look like this. I haven't tried putting all the datasource elements into one file.
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <datasources>
> <datasource jndi-name="java:/AlphaDS" enabled="true" use-java-context="true" pool-name="AlphaDS">
> <connection-url>jdbc:oracle:thin://@db-host:1666/dev-db</connection-url>
> <driver>oracle</driver>
> <security>
> <user-name>XXX</user-name>
> <password>YYY</password>
> </security>
> <connection-property name="defaultNChar">true</connection-property>
> </datasource>
> </datasources>
> {code}
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <datasources>
> <datasource jndi-name="java:/BetaDS" enabled="true" use-java-context="true" pool-name="BetaDS">
> <connection-url>jdbc:oracle:thin://@db-host:1666/dev-db</connection-url>
> <driver>oracle</driver>
> <security>
> <user-name>XXX</user-name>
> <password>YYY</password>
> </security>
> <connection-property name="defaultNChar">true</connection-property>
> </datasource>
> </datasources>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (DROOLS-322) Memory corruption using property reactivity in phreak
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-322:
----------------------------------
Summary: Memory corruption using property reactivity in phreak
Key: DROOLS-322
URL: https://issues.jboss.org/browse/DROOLS-322
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Mario Fusco
Assignee: Mark Proctor
This issue can be reproduced with the test case pasted below. Note that if you remove the @PropertyReactive annotation from the Hero class the test becomes green.
More in detail the problem is caused by the fact that at some point, with property reactivity on, the method RuleNetworkEvaluator.doUpdatesReorderLeftMemory at line 802 tries to remove a leftTuple from an already empty memory causing the size to drop to -1 and then the memory corruption you found this morning.
I believe that this is in turn caused by the fact that with property reactivity some updated staged left tuples are missing (because not propagated by the AlphaNode.modifyObject method at line 148) and this prevents the correct update of the memories.
{code}
@Test
public void testWumpus() {
String drl = "import org.drools.compiler.integrationtests.Misc2Test.Hero;\n" +
"import org.drools.compiler.integrationtests.Misc2Test.StepForwardCommand;\n" +
"import org.drools.compiler.integrationtests.Misc2Test.ChangeDirectionCommand;\n" +
"\n" +
"rule RotateLeft when\n" +
" $h : Hero( goingRight == true )\n" +
" $dc : ChangeDirectionCommand()\n" +
"then\n" +
" retract ( $dc ); \n" +
" modify ( $h ) { setGoingRight( false ) };\n" +
"end\n" +
"\n" +
"rule RotateRight when\n" +
" $h : Hero( goingRight == false )\n" +
" $dc : ChangeDirectionCommand()\n" +
"then\n" +
" retract ( $dc ); \n" +
" modify ( $h ) { setGoingRight( true ) };\n" +
"end\n" +
"\n" +
"rule StepLeft when\n" +
" $h : Hero( goingRight == false )\n" +
" $sc : StepForwardCommand()\n" +
"then\n" +
" retract ( $sc ); \n" +
" modify ( $h ) { setPos( $h.getPos()-1 ) };\n" +
"end\n" +
"\n" +
"rule StepRight when\n" +
" $h : Hero( goingRight == true )\n" +
" $sc : StepForwardCommand()\n" +
"then\n" +
" retract ( $sc );\n" +
" modify ( $h ) { setPos( $h.getPos()+1 ) };\n" +
"end\n";
KnowledgeBuilderConfiguration kbConf = KnowledgeBuilderFactory.newKnowledgeBuilderConfiguration();
KnowledgeBase kbase = loadKnowledgeBaseFromString( kbConf, drl );
StatefulKnowledgeSession ksession = kbase.newStatefulKnowledgeSession();
Hero hero = new Hero(1);
ksession.insert(hero);
ksession.fireAllRules();
ksession.insert(new StepForwardCommand());
ksession.fireAllRules();
ksession.insert(new StepForwardCommand());
ksession.fireAllRules();
assertEquals(3, hero.getPos());
ksession.insert(new ChangeDirectionCommand());
ksession.fireAllRules();
ksession.insert(new StepForwardCommand());
ksession.fireAllRules();
assertEquals(2, hero.getPos());
}
@PropertyReactive
public static class Hero {
private int pos = 1;
private boolean goingRight = true;
public Hero(int pos) {
this.pos = pos;
}
public int getPos() {
return pos;
}
public void setPos(int pos) {
this.pos = pos;
}
public boolean isGoingRight() {
return goingRight;
}
public void setGoingRight(boolean goingRight) {
this.goingRight = goingRight;
}
}
public static class ChangeDirectionCommand { }
public static class StepForwardCommand { }
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (DROOLS-321) Unnecessary update using the TMS in EQUALITY mode
by Mario Fusco (JIRA)
Mario Fusco created DROOLS-321:
----------------------------------
Summary: Unnecessary update using the TMS in EQUALITY mode
Key: DROOLS-321
URL: https://issues.jboss.org/browse/DROOLS-321
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Mario Fusco
Assignee: Mark Proctor
Having a class where some attributes are @key, but not all of them in EQUALITY mode it is possible to have a family of equivalent (by equality) facts which are not the same (by identity). The TMS will consider them equivalent, and use one of them as the "prime". When the justification for this prime fact goes away the second takes its place as prime. However if the SAME (by ID) fact was justified by two or more rules, there would be multiple entries in the list being the SAME by identity and the update would not be necessary.
This is fixable in SimpleBeliefSystem by adding the condition:
{code}&& node.getObject() != bfh.getObject(){code}
at line 79 of the delete method. However other BeliefSystems need to be checked and fixed as well.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (DROOLS-319) "Unknown boolean operator" RuntimeException
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-319?page=com.atlassian.jira.plugin... ]
Mario Fusco commented on DROOLS-319:
------------------------------------
Could you please paste the stack trace of the Exception you got?
> "Unknown boolean operator" RuntimeException
> -------------------------------------------
>
> Key: DROOLS-319
> URL: https://issues.jboss.org/browse/DROOLS-319
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 5.5.0.Final
> Environment: Windows 8, java version "1.7.0_40"
> Reporter: David Tombs
> Assignee: Mark Proctor
>
> Steps to reproduce:
> # Create a decision table with something like {{fooString != ""}} in the constraint and {{true}} in the rule cell.
> # Execute the rule against a few objects.
> Actual Result:
> An internal Drools thread will crash with {{java.lang.RuntimeException: Unknown boolean operator}} when trying to compile {{fooString != "" == true}}.
> Expected Result:
> Even if an Exception is thrown, the currently-thrown exception is too low level and took me lots of investigation and debugging inside the drools code to figure out what I did wrong.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JGRP-1675) Threads stuck in FlowControl.decrementIfEnoughCredits
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.... ]
Radim Vansa edited comment on JGRP-1675 at 11/6/13 3:26 AM:
------------------------------------------------------------
I'd prefer JGroups to be always working rather than working with probability dependent on INT:OOB threadpool ratio/messages frequency/dark magic. INT TP has much lower value if regular messages which are non-blocking from application perspective may get the thread stuck -> lead to threadpool depletion. I agree with Dan that listing messages according to flags would make the system more reliable.
[~belaban]: -Could you specify what's the fix (as this is fixed in 3.5)? Marking the FlowControl messages ad DONT_BUNDLE, telling ISPN developers to fix GET_FIRST flooding or something else? Does the comment about the two tests passing mean "passing as long as these send the get with GET_ALL" (the number of targets doesn't matter)?-
OK, I've found in another mail that it is marking the credit request as INT | OOB, but it should be mentioned more clearly somewhere in the JIRA.
was (Author: rvansa):
I'd prefer JGroups to be always working rather than working with probability dependent on INT:OOB threadpool ratio/messages frequency/dark magic. INT TP has much lower value if regular messages which are non-blocking from application perspective may get the thread stuck -> lead to threadpool depletion. I agree with Dan that listing messages according to flags would make the system more reliable.
[~belaban]: Could you specify what's the fix (as this is fixed in 3.5)? Marking the FlowControl messages ad DONT_BUNDLE, telling ISPN developers to fix GET_FIRST flooding or something else? Does the comment about the two tests passing mean "passing as long as these send the get with GET_ALL" (the number of targets doesn't matter)?
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
> Key: JGRP-1675
> URL: https://issues.jboss.org/browse/JGRP-1675
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: jgroups-udp-radim.xml, RemoteGetStressTest.java, UPerf2.java
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (DROOLS-320) Drools plugin Rete Tree viewer does not work with timer and || operator.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-320?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated DROOLS-320:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1027118, https://bugzilla.redhat.com/show_bug.cgi?id=1027120 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1027118)
> Drools plugin Rete Tree viewer does not work with timer and || operator.
> ------------------------------------------------------------------------
>
> Key: DROOLS-320
> URL: https://issues.jboss.org/browse/DROOLS-320
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.CR5
> Environment: Mac OS-X 10.9, JBoss Developer Studio 7, Oracle Hotspot 1.7.0_45, Drools-jBPM Eclipse plugin 6.0.0.CR5
> Reporter: Duncan Doyle
> Assignee: Mark Proctor
> Labels: drools, eclipse, plugin, rete, tree, view
>
> See this example project: https://github.com/DuncanDoyle/DroolsReteViewer , which is based on the Drools Eclipse sample project.
> The 'src/main/resources/rules/Sample.drl' is a valid DRL file, but it cannot be opened in the Rete Tree because of:
> - the 'timer (int: 10s)' definition in rule "GoodBye-Timer". This gives the error:
> Rete Tree Build Error!
> Reason:
> org.drools.core.RuntimeDroolsException:
> java.lang.reflect.InvocationTargetException: [Rete(0)]
> - the '||' operator in the rule "Hello World-Or". This gives the error:
> Rete Tree Build Error!
> Reason:
> java.lang.NullPointerException: null
> This forces us to change our rule definition files to be able to inspect the Rete Tree (which we require to analyse the tree for possible optimizations).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JGRP-1675) Threads stuck in FlowControl.decrementIfEnoughCredits
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on JGRP-1675:
-----------------------------------
I'd prefer JGroups to be always working rather than working with probability dependent on INT:OOB threadpool ratio/messages frequency/dark magic. INT TP has much lower value if regular messages which are non-blocking from application perspective may get the thread stuck -> lead to threadpool depletion. I agree with dan that listing messages according.
[~belaban]: Could you specify what's the fix (as this is fixed in 3.5)? Marking the FlowControl messages ad DONT_BUNDLE, telling ISPN developers to fix GET_FIRST flooding or something else? Does the comment about the two tests passing mean "passing as long as these send the get with GET_ALL" (the number of targets doesn't matter)?
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
> Key: JGRP-1675
> URL: https://issues.jboss.org/browse/JGRP-1675
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: jgroups-udp-radim.xml, RemoteGetStressTest.java, UPerf2.java
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (JGRP-1675) Threads stuck in FlowControl.decrementIfEnoughCredits
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/JGRP-1675?page=com.atlassian.jira.plugin.... ]
Radim Vansa edited comment on JGRP-1675 at 11/6/13 3:16 AM:
------------------------------------------------------------
I'd prefer JGroups to be always working rather than working with probability dependent on INT:OOB threadpool ratio/messages frequency/dark magic. INT TP has much lower value if regular messages which are non-blocking from application perspective may get the thread stuck -> lead to threadpool depletion. I agree with Dan that listing messages according to flags would make the system more reliable.
[~belaban]: Could you specify what's the fix (as this is fixed in 3.5)? Marking the FlowControl messages ad DONT_BUNDLE, telling ISPN developers to fix GET_FIRST flooding or something else? Does the comment about the two tests passing mean "passing as long as these send the get with GET_ALL" (the number of targets doesn't matter)?
was (Author: rvansa):
I'd prefer JGroups to be always working rather than working with probability dependent on INT:OOB threadpool ratio/messages frequency/dark magic. INT TP has much lower value if regular messages which are non-blocking from application perspective may get the thread stuck -> lead to threadpool depletion. I agree with dan that listing messages according.
[~belaban]: Could you specify what's the fix (as this is fixed in 3.5)? Marking the FlowControl messages ad DONT_BUNDLE, telling ISPN developers to fix GET_FIRST flooding or something else? Does the comment about the two tests passing mean "passing as long as these send the get with GET_ALL" (the number of targets doesn't matter)?
> Threads stuck in FlowControl.decrementIfEnoughCredits
> -----------------------------------------------------
>
> Key: JGRP-1675
> URL: https://issues.jboss.org/browse/JGRP-1675
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.4
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: jgroups-udp-radim.xml, RemoteGetStressTest.java, UPerf2.java
>
>
> I have recently observed a repeated situation where many (or all) threads have been stuck waiting for credits in FlowControl protocol.
> The credit request was not handled on the other node as this is non-oob message and some (actually many of them - cause unknown) messages before the request have been lost - therefore the request was waiting for them to be re-sent.
> However, these have not been re-sent properly as the retransmission request was not received - all OOB threads were stuck in the FlowControl protocol as these handled some other request and tried to send a response - but the response could not be sent until FlowControl gets the credits.
> The probability of such situation could be lowered by tagging the credit request to be OOB - then it would be handled immediately. If the credit replenish message would then be processed in regular OOB pool, this could get already depleted by many requests, but setting up the internal thread pool would solve the problem.
> Other consideration would be to allow releasing thread from FlowControl (let it send the message even without credits) if it waits there for too long.
> h3. Workaround
> It appears that setting MFC and UFC max_credits to 10M or removing these protocols at all is a workaround for this issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months
[JBoss JIRA] (DROOLS-320) Drools plugin Rete Tree viewer does not work with timer and || operator.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-320?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated DROOLS-320:
-------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1027118
> Drools plugin Rete Tree viewer does not work with timer and || operator.
> ------------------------------------------------------------------------
>
> Key: DROOLS-320
> URL: https://issues.jboss.org/browse/DROOLS-320
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.0.0.CR5
> Environment: Mac OS-X 10.9, JBoss Developer Studio 7, Oracle Hotspot 1.7.0_45, Drools-jBPM Eclipse plugin 6.0.0.CR5
> Reporter: Duncan Doyle
> Assignee: Mark Proctor
> Labels: drools, eclipse, plugin, rete, tree, view
>
> See this example project: https://github.com/DuncanDoyle/DroolsReteViewer , which is based on the Drools Eclipse sample project.
> The 'src/main/resources/rules/Sample.drl' is a valid DRL file, but it cannot be opened in the Rete Tree because of:
> - the 'timer (int: 10s)' definition in rule "GoodBye-Timer". This gives the error:
> Rete Tree Build Error!
> Reason:
> org.drools.core.RuntimeDroolsException:
> java.lang.reflect.InvocationTargetException: [Rete(0)]
> - the '||' operator in the rule "Hello World-Or". This gives the error:
> Rete Tree Build Error!
> Reason:
> java.lang.NullPointerException: null
> This forces us to change our rule definition files to be able to inspect the Rete Tree (which we require to analyse the tree for possible optimizations).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 2 months