November 2013 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-336) Property Reactivity fails on phreak

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-336: ---------------------------------- Summary: Property Reactivity fails on phreak Key: DROOLS-336 URL: https://issues.jboss.org/browse/DROOLS-336 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mario Fusco Assignee: Mario Fusco In LeftInputAdapterNode a modifyByPass happens, for a sink that has not been reached before. So it thinks it's new, and thus propagates as an insert The real bug comes in doInsertObject method. It creates a child LT here, even though once it enters doInsertSegmentMemory the mask intersect fails. This leaves a child LT, that is not propagated. Next time update is called, as the LT is there it thinks it's a modify and propagates as a modify - but it never reached the beta node or the LeftMemory, and thus the memory corruption. -- 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

1
0
0 / 0

[JBoss JIRA] (WFLY-1458) Allow specifying timeout for org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState()

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1458?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1458: ----------------------------------------------- Pavel Jelinek <pjelinek(a)redhat.com> changed the Status of [bug 1021487|https://bugzilla.redhat.com/show_bug.cgi?id=1021487] from ON_QA to VERIFIED > Allow specifying timeout for org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState() > -------------------------------------------------------------------------------------------------------- > > Key: WFLY-1458 > URL: https://issues.jboss.org/browse/WFLY-1458 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management, Test Suite > Affects Versions: 8.0.0.Alpha1 > Reporter: Richard Achmatowicz > Assignee: Ladislav Thon > Fix For: 8.0.0.CR1 > > Attachments: thread.dump.txt > > > When deploying a container, Arquillian will use a management client to connect to the deployed container to see if it is in a running state. If the management address and management port are incorrect, the connection to the container hangs indefinitely. > Please allow configuration of a timeout so that if the connection paramaters are not correct, at least the container deployment will fail with a meaningful error. -- 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

1
0
0 / 0

[JBoss JIRA] (WFLY-1458) Allow specifying timeout for org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState()

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-1458?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-1458: ----------------------------------------------- Pavel Jelinek <pjelinek(a)redhat.com> made a comment on [bug 1021487|https://bugzilla.redhat.com/show_bug.cgi?id=1021487] This issue was not spotted in EAP 6.2.0.ER7. > Allow specifying timeout for org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState() > -------------------------------------------------------------------------------------------------------- > > Key: WFLY-1458 > URL: https://issues.jboss.org/browse/WFLY-1458 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management, Test Suite > Affects Versions: 8.0.0.Alpha1 > Reporter: Richard Achmatowicz > Assignee: Ladislav Thon > Fix For: 8.0.0.CR1 > > Attachments: thread.dump.txt > > > When deploying a container, Arquillian will use a management client to connect to the deployed container to see if it is in a running state. If the management address and management port are incorrect, the connection to the container hangs indefinitely. > Please allow configuration of a timeout so that if the connection paramaters are not correct, at least the container deployment will fail with a meaningful error. -- 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

1
0
0 / 0

[JBoss JIRA] (DROOLS-335) Inconsistency between ReteOO and PHREAK on test with temporal reasoning and dynamic salience.

by Duncan Doyle (JIRA)

Duncan Doyle created DROOLS-335: ----------------------------------- Summary: Inconsistency between ReteOO and PHREAK on test with temporal reasoning and dynamic salience. Key: DROOLS-335 URL: https://issues.jboss.org/browse/DROOLS-335 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 6.0.0.CR5 Environment: Mac OS-X 10.9, Oracle Hotspot 1.7.0_45 Reporter: Duncan Doyle Assignee: Mark Proctor Reproducer at: https://github.com/DuncanDoyle/DroolsInOrderTemporalReasoningPhreakIssue Clone the project in the given GitHub repository and run 'mvn -Preteoo clean test'. The test will pass. Next, run 'mvn -Pphreak clean test', both tests fail. -- 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

1
0
0 / 0

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

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-327?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-327. -------------------------------- Fix Version/s: 6.0.0.Final Resolution: Done > 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: Mario Fusco > Labels: infinite, loop, no-loop, phreak > Fix For: 6.0.0.Final > > > 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

11 years, 2 months

1
0
0 / 0

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

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-327?page=com.atlassian.jira.plugin... ] Mario Fusco reassigned DROOLS-327: ---------------------------------- Assignee: Mario Fusco (was: Mark Proctor) > 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: Mario Fusco > 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-334) PHREAK goes into infinite loop, and hangs with 'no-loop' on rules with conditional named consequence and dynamic salience

by Duncan Doyle (JIRA)

Duncan Doyle created DROOLS-334: ----------------------------------- Summary: PHREAK goes into infinite loop, and hangs with 'no-loop' on rules with conditional named consequence and dynamic salience Key: DROOLS-334 URL: https://issues.jboss.org/browse/DROOLS-334 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 6.0.0.CR5 Environment: Mac OS-X 10.9, Oracle Hotspot 1.7.0_45 Reporter: Duncan Doyle Assignee: Mark Proctor Reproducer at: https://github.com/DuncanDoyle/DroolsInOrderTemporalReasoningPhreakLoopAn... Clone the project in the given GitHub repository and run 'mvn -Pphreak clean test' (-Pphreak runs the test with PHREAK, -Preteoo runs the test with ReteOO). ReteOO works fine, but PHREAK goes into an infinite-loop. Setting 'no-loop' on the "TECH-rule-RG-FLT-03B Retract all filtered events once we've sent an event."-rule causes the engine to hang and use 100% CPU on one core. -- 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

1
0
0 / 0

[JBoss JIRA] (WFLY-2477) Lifecycle callback methods not invoked on interceptors intercepting servlet component classes

by Matus Abaffy (JIRA)

[ https://issues.jboss.org/browse/WFLY-2477?page=com.atlassian.jira.plugin.... ] Matus Abaffy updated WFLY-2477: ------------------------------- Issue Type: Bug (was: Feature Request) > Lifecycle callback methods not invoked on interceptors intercepting servlet component classes > --------------------------------------------------------------------------------------------- > > Key: WFLY-2477 > URL: https://issues.jboss.org/browse/WFLY-2477 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: CDI / Weld > Affects Versions: 8.0.0.Beta1 > Reporter: Matus Abaffy > Assignee: Jozef Hartinger > > Even after fix for https://issues.jboss.org/browse/WFLY-2375, the @PostConstruct and @PreDestroy methods on interceptors (bound using interceptor bindings) intercepting servlet component classes are not invoked. > Tests available here: https://github.com/bafco/wildfly/commits/WFLY-2375-tests (only for servlets at the moment). -- 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

1
0
0 / 0

[JBoss JIRA] (WFLY-276) Clustering/multi-node tests cannot be run with -Djpda debugger

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-276?page=com.atlassian.jira.plugin.s... ] Radoslav Husar updated WFLY-276: -------------------------------- Summary: Clustering/multi-node tests cannot be run with -Djpda debugger (was: TS: How to use -Djpda with clustered tests) Affects Version/s: 8.0.0.Alpha1 Yep, they both listen on 8787. > Clustering/multi-node tests cannot be run with -Djpda debugger > -------------------------------------------------------------- > > Key: WFLY-276 > URL: https://issues.jboss.org/browse/WFLY-276 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Clustering, Documentation, Test Suite > Affects Versions: 8.0.0.Alpha1 > Reporter: Radoslav Husar > Assignee: Ondrej Zizka > Priority: Minor > Fix For: 8.0.0.CR1 > > > The doc now says whats pasted below, but I am not sure if both servers are listening on 8787 because (that would fail the startup), if I have to connect to both or where do I configure that, etc. > {code} > Running JBoss AS instances with debugger > Adding -Djpda (May be changed to -Ddebug in the future) will make JBoss AS run with JPDA JVM arguments for debugging. > It will suspend and wait for the debugger to connect at port 8787. > JBoss AS is started by Arquillian, when the first test which requires given instance is run. There's (currently) no challenge text in the console, it will look like the first test is stuck. This is being solved in http://jira.codehaus.org/browse/SUREFIRE-781. > Depending on which test group(s) you run, multiple instances may be started. In that case, you need to attach the debugger multiple times. > {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

1
0
0 / 0

[JBoss JIRA] (WFLY-2484) Revise clustering tests

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-2484?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on WFLY-2484: -------------------------------------- Updated WFLY-276, are you guys using clustering tests with attached debuggers? > Revise clustering tests > ----------------------- > > Key: WFLY-2484 > URL: https://issues.jboss.org/browse/WFLY-2484 > Project: WildFly > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Clustering > Affects Versions: 8.0.0.Beta1 > Reporter: Radoslav Husar > Assignee: Paul Ferraro > Fix For: 8.0.0.Final > > > Paul pointed out that some of the tests are no longer relevant with the new implementation and some were never actually relevant, e.g. duplicate tests. > We should revise the set of tests to keep the testsuite small and find out missing tests. -- 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

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira November 2013