January 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JGRP-457) Optimization: make threads return immediately if NAKACK has another active thread for the same sender

by Bela Ban (JIRA)

Optimization: make threads return immediately if NAKACK has another active thread for the same sender ----------------------------------------------------------------------------------------------------- Key: JGRP-457 URL: http://jira.jboss.com/jira/browse/JGRP-457 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.5 In NAKACK, when a thread places a message for sender S into the NakReceiverWindow NRW, it subsequently acquires a lock on NRW (lock by sender) and removes as many messages as possible and passes them up. If many threads do this at the same time, all threads but one are blocked, and - when finally unblocked - usually return. This causes context switches and possibly cache flushing, so a better way would be to have the threads check whether another thread is already removing messages using a CAS operation *before* acquiring the lock. The effect should be that no threads will wait on the lock unnecessarily, and thus fewer context switches, and more threads available to the pool. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 weeks, 6 days

2
3
0 / 0

[JBoss JIRA] (JBRULES-3445) DSL expander expands lines in /* */comment block

by Mario Fusco (JIRA)

Mario Fusco created JBRULES-3445: ------------------------------------ Summary: DSL expander expands lines in /* */comment block Key: JBRULES-3445 URL: https://issues.jboss.org/browse/JBRULES-3445 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Mario Fusco Assignee: Mario Fusco When you comment some code in dslr file, the expander still tries to expand it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

6 months, 1 week

3
10
0 / 0

[JBoss JIRA] (DROOLS-702) Rule Inheritance fired the sub rule even the condition doen't match

by Davide Sottara (JIRA)

[ https://issues.jboss.org/browse/DROOLS-702?page=com.atlassian.jira.plugin... ] Davide Sottara edited comment on DROOLS-702 at 1/31/15 9:54 AM: ---------------------------------------------------------------- When a rule extends another, patterns will not be merged. If you have: {code} rule "parent" when $p : Person() then end {code} and {code} rule "child" when Person() then end {code} the engine cannot safely infer that those two patterns should match the SAME fact, so you end up with a cross-product of two patterns. In your reproducer, the number of firings is consistent with the cross product of the facts you inserted, so I don't see any bug here. As an alternative to "from", you can use unification: {code} $p := Person() {code} in both rules (parent and child) to ensure the two patterns are linked. [Edit: clarification: "from" ensures the pattern applied to the same object, while ":=" is still affected by equality] was (Author: dsotty): When a rule extends another, patterns will not be merged. If you have: {code} rule "parent" when $p : Person() then end {code} and {code} rule "child" when Person() then end {code} the engine cannot safely infer that those two patterns should match the SAME fact, so you end up with a cross-product of two patterns. In your reproducer, the number of firings is consistent with the cross product of the facts you inserted, so I don't see any bug here. As an alternative to "from", you can use unification: {code} $p := Person() {code} in both rules (parent and child) to ensure the two patterns are linked. > Rule Inheritance fired the sub rule even the condition doen't match > ------------------------------------------------------------------- > > Key: DROOLS-702 > URL: https://issues.jboss.org/browse/DROOLS-702 > Project: Drools > Issue Type: Bug > Affects Versions: 6.1.0.Final > Environment: Windows, Java6.0.29 > Reporter: Yacine Jaber > Assignee: Davide Sottara > Priority: Critical > Attachments: wod-drools-test.7z > > > You can find the attached a simple maven project that shows this error. > You can run ExampleDrools class as main java application. > The sub rules are fired even if the condition is not matched. > There are a work arround by using <from $fact> into a sub rule to avoid firing this one. > This simple project shows the failed and work arround test. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-139) Appending into ByteStringBuilder fail if initial array blank

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-139?page=com.atlassian.jira.plugin.sy... ] Jan Kalina resolved ELY-139. ---------------------------- Resolution: Done > Appending into ByteStringBuilder fail if initial array blank > ------------------------------------------------------------ > > Key: ELY-139 > URL: https://issues.jboss.org/browse/ELY-139 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > -ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it.- > -(Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.)- > Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101 > *UPDATE:* > ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and (char) operator encode D800-D8FF bad as 3F. > Problem is only in appending into ByteStringBuilder constructed as: > {code:xml} > new ByteStringBuilder(new byte[]{}); > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-139) Appending into ByteStringBuilder fail if initial array blank

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-139?page=com.atlassian.jira.plugin.sy... ] Jan Kalina updated ELY-139: --------------------------- Git Pull Request: https://github.com/wildfly-security/wildfly-elytron/pull/101 > Appending into ByteStringBuilder fail if initial array blank > ------------------------------------------------------------ > > Key: ELY-139 > URL: https://issues.jboss.org/browse/ELY-139 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > -ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it.- > -(Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.)- > Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101 > *UPDATE:* > ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and (char) operator encode D800-D8FF bad as 3F. > Problem is only in appending into ByteStringBuilder constructed as: > {code:xml} > new ByteStringBuilder(new byte[]{}); > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3351) WildFly self-monitoring (history storage + REST API + web console plugin)

by Ondrej Zizka (JIRA)

[ https://issues.jboss.org/browse/WFLY-3351?page=com.atlassian.jira.plugin.... ] Ondrej Zizka commented on WFLY-3351: ------------------------------------ The result - a prototype - is at https://is.muni.cz/th/325163/fi_m/?furl=%2Fth%2F325163%2Ffi_m%2F;so=nx;la... For docs see the text of the thesis (in English), for working configured server download the Appendix. > WildFly self-monitoring (history storage + REST API + web console plugin) > ------------------------------------------------------------------------- > > Key: WFLY-3351 > URL: https://issues.jboss.org/browse/WFLY-3351 > Project: WildFly > Issue Type: Feature Request > Components: Logging > Reporter: Ondrej Zizka > Assignee: James Perkins > > Would be nice if WildFly had it's optional own submodule which would monitor the AS, store the data, and allow it's retrieval later through REST API. Also, the console could have a plugin to read and display these data. > This was discussed some time ago as one of requirements by different parties - JON, JBDS, end users. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-139) Appending into ByteStringBuilder fail if initial array blank

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-139?page=com.atlassian.jira.plugin.sy... ] Jan Kalina updated ELY-139: --------------------------- Description: -ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it.- -(Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.)- Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101 *UPDATE:* ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and (char) operator encode D800-D8FF bad as 3F. Problem is only in appending into ByteStringBuilder constructed as: {code:xml} new ByteStringBuilder(new byte[]{}); {code} was: -ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it. (Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.)- Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101 *UPDATE:* ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and (char) operator encode D800-D8FF bad as 3F. Problem is only in appending into ByteStringBuilder constructed as: {code:xml} new ByteStringBuilder(new byte[]{}); {code} > Appending into ByteStringBuilder fail if initial array blank > ------------------------------------------------------------ > > Key: ELY-139 > URL: https://issues.jboss.org/browse/ELY-139 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > -ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it.- > -(Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.)- > Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101 > *UPDATE:* > ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and (char) operator encode D800-D8FF bad as 3F. > Problem is only in appending into ByteStringBuilder constructed as: > {code:xml} > new ByteStringBuilder(new byte[]{}); > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ELY-139) Appending into ByteStringBuilder fail if initial array blank

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-139?page=com.atlassian.jira.plugin.sy... ] Jan Kalina updated ELY-139: --------------------------- Summary: Appending into ByteStringBuilder fail if initial array blank (was: ByteStringBuilder.appendUtf8Raw() cannot append lonely surrogates) Description: -ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it. (Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.)- Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101 *UPDATE:* ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and (char) operator encode D800-D8FF bad as 3F. Problem is only in appending into ByteStringBuilder constructed as: {code:xml} new ByteStringBuilder(new byte[]{}); {code} was: ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it. (Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.) Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101 *UPDATE:* ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and (char) operator encode D800-D8FF bad as 3F. Problem is only in appending into ByteStringBuilder constructed as: {code:xml} new ByteStringBuilder(new byte[]{}); {code} > Appending into ByteStringBuilder fail if initial array blank > ------------------------------------------------------------ > > Key: ELY-139 > URL: https://issues.jboss.org/browse/ELY-139 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > -ByteStringBuilder cannot append codepoints 0xD8xx (lonely surrogates). It should - StringBuilder.appendCodePoint() work with it. > (Problem is only with uncomplete/nonvalid unicode strings, so it is not critical problem.)- > Mentioned in: https://github.com/wildfly-security/wildfly-elytron/pull/101 > *UPDATE:* > ByteStringBuilder encode surrogates correctly by RFC3629 (if we ignore they are prohibited because they are reserved for UTF-16). Conversly StringBuilder and (char) operator encode D800-D8FF bad as 3F. > Problem is only in appending into ByteStringBuilder constructed as: > {code:xml} > new ByteStringBuilder(new byte[]{}); > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-695) Add ability to disable rules

by Stephen Slaboda (JIRA)

[ https://issues.jboss.org/browse/DROOLS-695?page=com.atlassian.jira.plugin... ] Stephen Slaboda closed DROOLS-695. ---------------------------------- Resolution: Rejected This functionality already exists in Drools and in the Workbench (the "enabled" option for a rule satisfies the requested capability) > Add ability to disable rules > ---------------------------- > > Key: DROOLS-695 > URL: https://issues.jboss.org/browse/DROOLS-695 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.2.0.CR4 > Environment: RedHat Linux 6.3 x86_64; Firefox 10.0.5 > Reporter: Stephen Slaboda > Labels: drools-wb > > Many times while working on rules, it would be helpful to be able to disable other rules. Reasons for doing this would be: > -Testing outside of the workbench (ensure your process using Drools activates certain rules, without the clutter of other rules firing) > -Turn off rules if it is determined that they are impacitng the operational environment > -Allow development of rules in the same space while not breaking the build/deploy of rules > -Allow for inclusion of rules in the operation system that do not run until approved, while still allowing other updates to occur in the meantime. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-695) Add ability to disable rules

by Stephen Slaboda (JIRA)

[ https://issues.jboss.org/browse/DROOLS-695?page=com.atlassian.jira.plugin... ] Stephen Slaboda commented on DROOLS-695: ---------------------------------------- I just discovered that the workbench provides the ability to specify an "enabled" option on a rule, allowing you to disable the rule. This satisfies my criteria, so I am closing this issue. > Add ability to disable rules > ---------------------------- > > Key: DROOLS-695 > URL: https://issues.jboss.org/browse/DROOLS-695 > Project: Drools > Issue Type: Enhancement > Affects Versions: 6.2.0.CR4 > Environment: RedHat Linux 6.3 x86_64; Firefox 10.0.5 > Reporter: Stephen Slaboda > Labels: drools-wb > > Many times while working on rules, it would be helpful to be able to disable other rules. Reasons for doing this would be: > -Testing outside of the workbench (ensure your process using Drools activates certain rules, without the clutter of other rules firing) > -Turn off rules if it is determined that they are impacitng the operational environment > -Allow development of rules in the same space while not breaking the build/deploy of rules > -Allow for inclusion of rules in the operation system that do not run until approved, while still allowing other updates to occur in the meantime. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

10 years, 9 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 January 2015