[JBoss JIRA] (JGRP-1733) UNICAST3: 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 resolved JGRP-1733.
----------------------------
Resolution: Done
> UNICAST3: 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
11 years, 2 months
[JBoss JIRA] (WFLY-2463) Set Strict-Transport-Security in HTTP-Header
by Juergen Zimmermann (JIRA)
Juergen Zimmermann created WFLY-2463:
----------------------------------------
Summary: Set Strict-Transport-Security in HTTP-Header
Key: WFLY-2463
URL: https://issues.jboss.org/browse/WFLY-2463
Project: WildFly
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Web (Undertow)
Affects Versions: 8.0.0.Beta1
Reporter: Juergen Zimmermann
Assignee: Stuart Douglas
It would be good to set the http Header "Strict-Transport-Security: max-age=<SECONDS>" in Undertow
--
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 David Tombs (JIRA)
[ https://issues.jboss.org/browse/DROOLS-319?page=com.atlassian.jira.plugin... ]
David Tombs commented on DROOLS-319:
------------------------------------
OK, I updated the description.
> "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}}.
> {noformat}
> Exception in thread "Thread-15" java.lang.RuntimeException: Unknown boolean operator
> at org.drools.rule.constraint.ConditionAnalyzer$AritmeticOperator.fromMvelOpCode(ConditionAnalyzer.java:1059)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:169)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeSingleCondition(ConditionAnalyzer.java:106)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:99)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:70)
> at org.drools.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:83)
> at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:270)
> at org.drools.rule.constraint.MvelConstraint.access$200(MvelConstraint.java:51)
> at org.drools.rule.constraint.MvelConstraint$ConditionJitter.run(MvelConstraint.java:250)
> 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:724)
> {noformat}
> 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] (DROOLS-319) "Unknown boolean operator" RuntimeException
by David Tombs (JIRA)
[ https://issues.jboss.org/browse/DROOLS-319?page=com.atlassian.jira.plugin... ]
David Tombs updated DROOLS-319:
-------------------------------
Description:
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}}.
{{
Exception in thread "Thread-15" java.lang.RuntimeException: Unknown boolean operator
at org.drools.rule.constraint.ConditionAnalyzer$AritmeticOperator.fromMvelOpCode(ConditionAnalyzer.java:1059)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:169)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeSingleCondition(ConditionAnalyzer.java:106)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:99)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:70)
at org.drools.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:83)
at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:270)
at org.drools.rule.constraint.MvelConstraint.access$200(MvelConstraint.java:51)
at org.drools.rule.constraint.MvelConstraint$ConditionJitter.run(MvelConstraint.java:250)
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:724)
}}
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.
was:
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.
> "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}}.
> {{
> Exception in thread "Thread-15" java.lang.RuntimeException: Unknown boolean operator
> at org.drools.rule.constraint.ConditionAnalyzer$AritmeticOperator.fromMvelOpCode(ConditionAnalyzer.java:1059)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:169)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeSingleCondition(ConditionAnalyzer.java:106)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:99)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:70)
> at org.drools.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:83)
> at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:270)
> at org.drools.rule.constraint.MvelConstraint.access$200(MvelConstraint.java:51)
> at org.drools.rule.constraint.MvelConstraint$ConditionJitter.run(MvelConstraint.java:250)
> 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:724)
> }}
> 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-1733) UNICAST3: 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:
---------------------------
Summary: UNICAST3: OOB messages should be marked as OOB_DELIVERED before adding them to the table (was: UNICAST / NAKACK: OOB messages should be marked as OOB_DELIVERED before adding them to the table)
> UNICAST3: 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
11 years, 2 months
[JBoss JIRA] (DROOLS-319) "Unknown boolean operator" RuntimeException
by David Tombs (JIRA)
[ https://issues.jboss.org/browse/DROOLS-319?page=com.atlassian.jira.plugin... ]
David Tombs updated DROOLS-319:
-------------------------------
Description:
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}}.
{noformat}
Exception in thread "Thread-15" java.lang.RuntimeException: Unknown boolean operator
at org.drools.rule.constraint.ConditionAnalyzer$AritmeticOperator.fromMvelOpCode(ConditionAnalyzer.java:1059)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:169)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeSingleCondition(ConditionAnalyzer.java:106)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:99)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:70)
at org.drools.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:83)
at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:270)
at org.drools.rule.constraint.MvelConstraint.access$200(MvelConstraint.java:51)
at org.drools.rule.constraint.MvelConstraint$ConditionJitter.run(MvelConstraint.java:250)
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:724)
{noformat}
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.
was:
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}}.
{{
Exception in thread "Thread-15" java.lang.RuntimeException: Unknown boolean operator
at org.drools.rule.constraint.ConditionAnalyzer$AritmeticOperator.fromMvelOpCode(ConditionAnalyzer.java:1059)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:169)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeSingleCondition(ConditionAnalyzer.java:106)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:99)
at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:70)
at org.drools.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:83)
at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:270)
at org.drools.rule.constraint.MvelConstraint.access$200(MvelConstraint.java:51)
at org.drools.rule.constraint.MvelConstraint$ConditionJitter.run(MvelConstraint.java:250)
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:724)
}}
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.
> "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}}.
> {noformat}
> Exception in thread "Thread-15" java.lang.RuntimeException: Unknown boolean operator
> at org.drools.rule.constraint.ConditionAnalyzer$AritmeticOperator.fromMvelOpCode(ConditionAnalyzer.java:1059)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeNode(ConditionAnalyzer.java:169)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeSingleCondition(ConditionAnalyzer.java:106)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:99)
> at org.drools.rule.constraint.ConditionAnalyzer.analyzeCondition(ConditionAnalyzer.java:70)
> at org.drools.rule.constraint.MvelConditionEvaluator.getAnalyzedCondition(MvelConditionEvaluator.java:83)
> at org.drools.rule.constraint.MvelConstraint.executeJitting(MvelConstraint.java:270)
> at org.drools.rule.constraint.MvelConstraint.access$200(MvelConstraint.java:51)
> at org.drools.rule.constraint.MvelConstraint$ConditionJitter.run(MvelConstraint.java:250)
> 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:724)
> {noformat}
> 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] (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 commented on DROOLS-326:
------------------------------------------------
Kris Verlaenen <kverlaen(a)redhat.com> changed the Status of [bug 1027765|https://bugzilla.redhat.com/show_bug.cgi?id=1027765] from NEW to MODIFIED
> 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
11 years, 2 months
[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 commented on DROOLS-326:
------------------------------------------------
Kris Verlaenen <kverlaen(a)redhat.com> made a comment on [bug 1027765|https://bugzilla.redhat.com/show_bug.cgi?id=1027765]
Already fixed as part of previous commit (see https://bugzilla.redhat.com/show_bug.cgi?id=1027118)
master: https://github.com/droolsjbpm/droolsjbpm-tools/commit/ff822bdc36de07e7071...
6.0.x: https://github.com/droolsjbpm/droolsjbpm-tools/commit/60c768cbad80bedcbd6...
Note this is not in the 6.0.0.Final tag.
> 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
11 years, 2 months
[JBoss JIRA] (WFLY-2462) Too many element definitions in the CLI configuration schema.
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFLY-2462:
--------------------------------------
Summary: Too many element definitions in the CLI configuration schema.
Key: WFLY-2462
URL: https://issues.jboss.org/browse/WFLY-2462
Project: WildFly
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: CLI
Affects Versions: 8.0.0.Beta1
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Fix For: 8.0.0.CR1
The CLI schema contains many element definitions, however the only one supported at the top level is 'jboss-cli' - the remainder need converting to complex type definitions.
--
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