November 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-327) PHREAK goes into infinite loop, even with 'no-loop' defined.

by Duncan Doyle (JIRA)

[ https://issues.jboss.org/browse/DROOLS-327?page=com.atlassian.jira.plugin... ] Duncan Doyle commented on DROOLS-327: ------------------------------------- Just did some more testing. If you remove the 'Conditional Named Consequence', the 'no-loop' does work as expected, i.e.: rule "Hello World" dialect "java" no-loop when m : Message( myMessage : message ) // if (m.getStatus() == 0) do [sayHello] then System.out.println( myMessage ); m.setMessage( "Goodbye cruel world" ); m.setStatus( Message.GOODBYE ); update( m ); //then[sayHello] // System.out.println("Hello, I'm here!"); end > PHREAK goes into infinite loop, even with 'no-loop' defined. > ------------------------------------------------------------ > > Key: DROOLS-327 > URL: https://issues.jboss.org/browse/DROOLS-327 > 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 > Reporter: Duncan Doyle > Assignee: Mark Proctor > Labels: infinite, loop, no-loop, phreak > > See this project on my Github: https://github.com/DuncanDoyle/DroolsPhreakConditionalNamedConsequenceInf... > The 'src/main/resources/rules/Sample.drl' contains an adapted version of the default Drools Eclipse plugin sample rule. As you can see, the rule uses Conditional Named Consequence construct. Although the rule is a bit strange (the issue actuallty popped up while debugging another issue) it does show different behaviour between ReteOO and PHREAK, where in this case PHREAK actually goes into an infinitie-loop, even though 'no-loop' has been defined on the "Hello World" rule. > To run the sample using ReteOO: > - mvn -Preteoo exec:java > The (correct) output is: > Hello World > Goodbye cruel world > To run the sample using PHREAK > - mvn -Pphreak exec:java > The incorrect output is: > Hello, I'm here! > Hello World > Goodbye cruel world > Goodbye cruel world > Goodbye cruel world > Goodbye cruel world > Goodbye cruel world > {infinite loop} > Note that the PHREAK run also prints "Hello, I'm here!" and ReteOO doesn't (because the activation of that rule is canceled when the Message is updated with a new message and status). -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1733) UNICAST / NAKACK: OOB messages should be marked as OOB_DELIVERED before adding them to the table

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1733?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1733 at 11/7/13 7:46 AM: --------------------------------------------------------- The main advantage is that messages flagged as {{[OOB | DONT_BUNDLE]}} or {{[OOB | INTERNAL | DONT_BUNDLE]}} don't end up getting processed in a batch, possibly even by a regular thread. These types of messages are often used internally, and cannot get stuck behind other (application) messages in a batch, which delay deliver of the internal message or even block (e.g. RPCs waiting for a response). was (Author: belaban): The main advantage is that messages flagged as {{[OOB | DONT_BUNDLE]}} or {{[OOB | INTERNAL | DONT_BUNDLE]}} don't end up getting in a batch, possibly even by a regular thread. These types of messages are often used internally, and cannot get stuck behind other (application) messages in a batch, which delay deliver of the internal message or even block (e.g. RPCs waiting for a response). > UNICAST / NAKACK: OOB messages should be marked as OOB_DELIVERED before adding them to the table > ------------------------------------------------------------------------------------------------ > > Key: JGRP-1733 > URL: https://issues.jboss.org/browse/JGRP-1733 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5 > > > Currently, OOB messages are added to the table, then passed up unless they're already marked as OOB_DELIVERED. This could happen if another thread removed messages from the table and passed them up before the current thread could pass the message up. > However, this work stealing might be detrimental: if the stealing thread batched messages up and 'stole' OOB messages (and those messages blocked), then the rest of the batch would be blocked from delivery. > This is the same though if a batch only contains regular messages... > However, this would make things simpler as threads from the regular pool would never deliver OOB messages (but not the other way round, OOB thread could still deliver regular messages). -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1733) UNICAST / NAKACK: OOB messages should be marked as OOB_DELIVERED before adding them to the table

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1733?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-1733 at 11/7/13 7:47 AM: --------------------------------------------------------- The main advantage is that messages flagged as {{[OOB | DONT_BUNDLE]}} or {{[OOB | INTERNAL | DONT_BUNDLE]}} don't end up getting processed in a batch, possibly even by a regular thread. These types of messages are often used internally, and cannot get stuck behind other (application) messages in a batch, which delay delivery of the internal message or even block (e.g. RPCs waiting for a response). was (Author: belaban): The main advantage is that messages flagged as {{[OOB | DONT_BUNDLE]}} or {{[OOB | INTERNAL | DONT_BUNDLE]}} don't end up getting processed in a batch, possibly even by a regular thread. These types of messages are often used internally, and cannot get stuck behind other (application) messages in a batch, which delay deliver of the internal message or even block (e.g. RPCs waiting for a response). > UNICAST / NAKACK: OOB messages should be marked as OOB_DELIVERED before adding them to the table > ------------------------------------------------------------------------------------------------ > > Key: JGRP-1733 > URL: https://issues.jboss.org/browse/JGRP-1733 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5 > > > Currently, OOB messages are added to the table, then passed up unless they're already marked as OOB_DELIVERED. This could happen if another thread removed messages from the table and passed them up before the current thread could pass the message up. > However, this work stealing might be detrimental: if the stealing thread batched messages up and 'stole' OOB messages (and those messages blocked), then the rest of the batch would be blocked from delivery. > This is the same though if a batch only contains regular messages... > However, this would make things simpler as threads from the regular pool would never deliver OOB messages (but not the other way round, OOB thread could still deliver regular messages). -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1733) UNICAST / NAKACK: OOB messages should be marked as OOB_DELIVERED before adding them to the table

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1733?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1733: -------------------------------- The main advantage is that messages flagged as {{OOB | DONT_BUNDLE}} or {{OOB | INTERNAL | DONT_BUNDLE}} don't end up getting in a batch, possibly even by a regular thread. These types of messages are often used internally, and cannot get stuck behind other (application) messages in a batch, which delay deliver of the internal message or even block (e.g. RPCs waiting for a response). > UNICAST / NAKACK: OOB messages should be marked as OOB_DELIVERED before adding them to the table > ------------------------------------------------------------------------------------------------ > > Key: JGRP-1733 > URL: https://issues.jboss.org/browse/JGRP-1733 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5 > > > Currently, OOB messages are added to the table, then passed up unless they're already marked as OOB_DELIVERED. This could happen if another thread removed messages from the table and passed them up before the current thread could pass the message up. > However, this work stealing might be detrimental: if the stealing thread batched messages up and 'stole' OOB messages (and those messages blocked), then the rest of the batch would be blocked from delivery. > This is the same though if a batch only contains regular messages... > However, this would make things simpler as threads from the regular pool would never deliver OOB messages (but not the other way round, OOB thread could still deliver regular messages). -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2430) App with custom ContainerResponseFilter (JAX-RS) fails deploy

by Rudy De Busscher (JIRA)

[ https://issues.jboss.org/browse/WFLY-2430?page=com.atlassian.jira.plugin.... ] Rudy De Busscher commented on WFLY-2430: ---------------------------------------- Ok, found the issue. I had a environment value for the previous version of Jboss jboss_home=C:\jboss-as-7.1.1.Final And that is why it was failing. Thanks for your time. Rudy > App with custom ContainerResponseFilter (JAX-RS) fails deploy > ------------------------------------------------------------- > > Key: WFLY-2430 > URL: https://issues.jboss.org/browse/WFLY-2430 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: REST > Affects Versions: 8.0.0.Beta1 > Environment: Windows 7 > Reporter: Rudy De Busscher > Assignee: Stuart Douglas > Attachments: exampleRest.zip > > > Created a simple rest application with a ContainerResponseFilter. The deploy fails with a ClassNotFoundException of javax.ws.rs.container.ContainerResponseFilter. > See also https://community.jboss.org/message/844105 -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2401) org.jboss.as.test.smoke.mgmt.BasicOperationsUnitTestCase fails

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/WFLY-2401?page=com.atlassian.jira.plugin.... ] Ondrej Zizka updated WFLY-2401: ------------------------------- Assignee: Emanuel Muckenhuber > org.jboss.as.test.smoke.mgmt.BasicOperationsUnitTestCase fails > -------------------------------------------------------------- > > Key: WFLY-2401 > URL: https://issues.jboss.org/browse/WFLY-2401 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite > Affects Versions: 8.0.0.Beta1 > Environment: Solaris SPARC 10, Oracle Java 1.7.0_45 > Reporter: Frank Langelage > Assignee: Emanuel Muckenhuber > Attachments: org.jboss.as.test.smoke.mgmt.BasicOperationsUnitTestCase.txt > > > Running a build of current sources with complete testsuite this test is failing with > testReadAttributeWildcards(org.jboss.as.test.smoke.mgmt.BasicOperationsUnitTestCase) -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2401) org.jboss.as.test.smoke.mgmt.BasicOperationsUnitTestCase fails

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/WFLY-2401?page=com.atlassian.jira.plugin.... ] Ondrej Zizka updated WFLY-2401: ------------------------------- Assignee: (was: Ondrej Zizka) > org.jboss.as.test.smoke.mgmt.BasicOperationsUnitTestCase fails > -------------------------------------------------------------- > > Key: WFLY-2401 > URL: https://issues.jboss.org/browse/WFLY-2401 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Test Suite > Affects Versions: 8.0.0.Beta1 > Environment: Solaris SPARC 10, Oracle Java 1.7.0_45 > Reporter: Frank Langelage > Attachments: org.jboss.as.test.smoke.mgmt.BasicOperationsUnitTestCase.txt > > > Running a build of current sources with complete testsuite this test is failing with > testReadAttributeWildcards(org.jboss.as.test.smoke.mgmt.BasicOperationsUnitTestCase) -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1733) UNICAST / NAKACK: OOB messages should be marked as OOB_DELIVERED before adding them to the table

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1733?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1733: -------------------------------- Can't do this for batches: if we successfully add a batch, this only means that at least 1 message was added. Therefore, we still have to check for each message whether it has the OOB_DELIVERED flag set and cannot set it in all messages of a batch up front. So we can do this for single messages, but not for message batches. > UNICAST / NAKACK: OOB messages should be marked as OOB_DELIVERED before adding them to the table > ------------------------------------------------------------------------------------------------ > > Key: JGRP-1733 > URL: https://issues.jboss.org/browse/JGRP-1733 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5 > > > Currently, OOB messages are added to the table, then passed up unless they're already marked as OOB_DELIVERED. This could happen if another thread removed messages from the table and passed them up before the current thread could pass the message up. > However, this work stealing might be detrimental: if the stealing thread batched messages up and 'stole' OOB messages (and those messages blocked), then the rest of the batch would be blocked from delivery. > This is the same though if a batch only contains regular messages... > However, this would make things simpler as threads from the regular pool would never deliver OOB messages (but not the other way round, OOB thread could still deliver regular messages). -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-326) Drools plugin Rete Tree viewer does not work with Conditional Named Consequence expressions

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-326?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated DROOLS-326: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1027765 > Drools plugin Rete Tree viewer does not work with Conditional Named Consequence expressions > ------------------------------------------------------------------------------------------- > > Key: DROOLS-326 > URL: https://issues.jboss.org/browse/DROOLS-326 > 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 > Reporter: Duncan Doyle > Assignee: Mark Proctor > Labels: conditional, consequence, eclipse, named, plugin, rete, tree, view > > See this project, which is based on the standard Sample.drl of the Drools Eclipse plugin: https://github.com/DuncanDoyle/DroolsConditionalNamedConsequenceIssue > The 'src/main/resources/rules/Sample.drl' contains a rule which uses a 'Conditional Named Consequence' construct. When clicking the Rete Tree tab in the DRL editor I receive this error: > Rete Tree Build Error! > Reason: > org.drools.core.RuntimeDroolsException: > java.lang.reflect.InvocationTargetException : [Rete(0)] > And the Rete Tree is not displayed. -- 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

12 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1733) UNICAST / NAKACK: OOB messages should be marked as OOB_DELIVERED before adding them to the table

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1733?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-1733: --------------------------- Fix Version/s: (was: 3.4.1) > UNICAST / NAKACK: OOB messages should be marked as OOB_DELIVERED before adding them to the table > ------------------------------------------------------------------------------------------------ > > Key: JGRP-1733 > URL: https://issues.jboss.org/browse/JGRP-1733 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5 > > > Currently, OOB messages are added to the table, then passed up unless they're already marked as OOB_DELIVERED. This could happen if another thread removed messages from the table and passed them up before the current thread could pass the message up. > However, this work stealing might be detrimental: if the stealing thread batched messages up and 'stole' OOB messages (and those messages blocked), then the rest of the batch would be blocked from delivery. > This is the same though if a batch only contains regular messages... > However, this would make things simpler as threads from the regular pool would never deliver OOB messages (but not the other way round, OOB thread could still deliver regular messages). -- 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

12 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2013