April 2017 - 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

3 days, 22 hours

2
3
0 / 0

[JBoss JIRA] (ELY-776) Eliminate reference to "slot" from module configurations

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-776?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse reassigned ELY-776: ------------------------------------ Assignee: Darran Lofthouse > Eliminate reference to "slot" from module configurations > -------------------------------------------------------- > > Key: ELY-776 > URL: https://issues.jboss.org/browse/ELY-776 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: David Lloyd > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta15 > > > The final version of our client XSD should accept a name for modules but no slot. Instead, either the new name-only APIs should be used or a ModuleIdentifier created via that class's "fromString" method. Module slots are deprecated. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

4 weeks

2
1
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

5 months, 3 weeks

3
10
0 / 0

[JBoss JIRA] (LOGMGR-153) Remove finalization from Logger

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-153?page=com.atlassian.jira.plugin... ] James Perkins updated LOGMGR-153: --------------------------------- Parent: LOGMGR-130 Issue Type: Sub-task (was: Enhancement) > Remove finalization from Logger > ------------------------------- > > Key: LOGMGR-153 > URL: https://issues.jboss.org/browse/LOGMGR-153 > Project: JBoss Log Manager > Issue Type: Sub-task > Components: core > Reporter: Philippe Marschall > > Finalization has been [deprecated in Java 9|https://stuartmarks.wordpress.com/2017/04/17/deprecation-of-object-fina...] because of performance issues with the recommendation that people switch to PhantomReference. Unfortunately as part of LOGMGR-107 Logger now uses finalization. Fortunately thanks to the excellent ref package in wildly-common this can be fixed easily. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-153) Remove finalization from Logger

by Philippe Marschall (JIRA)

Philippe Marschall created LOGMGR-153: ----------------------------------------- Summary: Remove finalization from Logger Key: LOGMGR-153 URL: https://issues.jboss.org/browse/LOGMGR-153 Project: JBoss Log Manager Issue Type: Enhancement Components: core Reporter: Philippe Marschall Finalization has been [deprecated in Java 9|https://stuartmarks.wordpress.com/2017/04/17/deprecation-of-object-fina...] because of performance issues with the recommendation that people switch to PhantomReference. Unfortunately as part of LOGMGR-107 Logger now uses finalization. Fortunately thanks to the excellent ref package in wildly-common this can be fixed easily. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2740) Recursive read-resource should not fail if an expected address type disappears in the middle of execution

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2740?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-2740: ------------------------------------- Fix Version/s: (was: 4.0.0.Alpha1) > Recursive read-resource should not fail if an expected address type disappears in the middle of execution > --------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2740 > URL: https://issues.jboss.org/browse/WFCORE-2740 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Minor > > The ManagementResourceRegistration tree is not cloned upon modification the way Resource tree is. That means read ops executing concurrently with ops that modify the MRR tree can have the tree change underneath them. > This can affect recursive read-resource ops, as they calculate possible child addresses and then later they process those addresses, failing if an MRR is missing. A failure only makes sense if the user did something wrong or, perhaps, if it's clear that the code is broken. But here there's a perfectly valid reason for the MRR to be missing, so there should be no failure. > Not an urgent thing; I saw this quite a while ago when investigating a different issue and quickly worked up a fix which has now been sitting around gathering dust. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2547) Revisit the meaning of aggregate-principal-transformer

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2547?page=com.atlassian.jira.plugi... ] Jan Kalina reassigned WFCORE-2547: ---------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > Revisit the meaning of aggregate-principal-transformer > ------------------------------------------------------ > > Key: WFCORE-2547 > URL: https://issues.jboss.org/browse/WFCORE-2547 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > Labels: principal-transformer > > Meaning of Elytron {{aggregate-principal-transformer}} should be revised. Also one point about {{regex-validating-principal-transformer}} is included since it seems its use cases are related to aggregate-principal-transformer. See: > * It seems that it works like "It iterates through assigned Principal Transformers and returns the first non-null transformed Principal" - is it correct and intended behaviour? Is "aggregate-principal-transformer" appropriate name for transformer which works like that? > * What is the use case for regex-validating-principal-transformer. This transformer just checks some pattern and if it does not match then it rewrites Principal name to null. I think it can be useful in aggregate-principal-transformer, when it can check that name matches some pattern in first transformer (regex-validating-principal-transformer) and then transforms principal in another transformer (e.g. constant-principal-transformer). Is there any other use case? > * When can aggregate-principal-transformer return any other Principal Transformer than first of the list? I think only user implemented custom-principal-transformer can currently return null (which enable iterating to another principal transformer in the list). Also regex-validating-principal-transformer can be used for returning non-first transformer, as I mentioned in previous point. Is there any real scenario when aggregate-principal-transformer can be used? > This issue is reported based on previous discussion with engineering. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2547) Revisit the meaning of aggregate-principal-transformer

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2547?page=com.atlassian.jira.plugi... ] Jan Kalina updated WFCORE-2547: ------------------------------- Labels: principal-transformer (was: ) > Revisit the meaning of aggregate-principal-transformer > ------------------------------------------------------ > > Key: WFCORE-2547 > URL: https://issues.jboss.org/browse/WFCORE-2547 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Blocker > Labels: principal-transformer > > Meaning of Elytron {{aggregate-principal-transformer}} should be revised. Also one point about {{regex-validating-principal-transformer}} is included since it seems its use cases are related to aggregate-principal-transformer. See: > * It seems that it works like "It iterates through assigned Principal Transformers and returns the first non-null transformed Principal" - is it correct and intended behaviour? Is "aggregate-principal-transformer" appropriate name for transformer which works like that? > * What is the use case for regex-validating-principal-transformer. This transformer just checks some pattern and if it does not match then it rewrites Principal name to null. I think it can be useful in aggregate-principal-transformer, when it can check that name matches some pattern in first transformer (regex-validating-principal-transformer) and then transforms principal in another transformer (e.g. constant-principal-transformer). Is there any other use case? > * When can aggregate-principal-transformer return any other Principal Transformer than first of the list? I think only user implemented custom-principal-transformer can currently return null (which enable iterating to another principal transformer in the list). Also regex-validating-principal-transformer can be used for returning non-first transformer, as I mentioned in previous point. Is there any real scenario when aggregate-principal-transformer can be used? > This issue is reported based on previous discussion with engineering. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2547) Revisit the meaning of aggregate-principal-transformer

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2547?page=com.atlassian.jira.plugi... ] Jan Kalina updated WFCORE-2547: ------------------------------- Priority: Blocker (was: Critical) > Revisit the meaning of aggregate-principal-transformer > ------------------------------------------------------ > > Key: WFCORE-2547 > URL: https://issues.jboss.org/browse/WFCORE-2547 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Blocker > Labels: principal-transformer > > Meaning of Elytron {{aggregate-principal-transformer}} should be revised. Also one point about {{regex-validating-principal-transformer}} is included since it seems its use cases are related to aggregate-principal-transformer. See: > * It seems that it works like "It iterates through assigned Principal Transformers and returns the first non-null transformed Principal" - is it correct and intended behaviour? Is "aggregate-principal-transformer" appropriate name for transformer which works like that? > * What is the use case for regex-validating-principal-transformer. This transformer just checks some pattern and if it does not match then it rewrites Principal name to null. I think it can be useful in aggregate-principal-transformer, when it can check that name matches some pattern in first transformer (regex-validating-principal-transformer) and then transforms principal in another transformer (e.g. constant-principal-transformer). Is there any other use case? > * When can aggregate-principal-transformer return any other Principal Transformer than first of the list? I think only user implemented custom-principal-transformer can currently return null (which enable iterating to another principal transformer in the list). Also regex-validating-principal-transformer can be used for returning non-first transformer, as I mentioned in previous point. Is there any real scenario when aggregate-principal-transformer can be used? > This issue is reported based on previous discussion with engineering. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1115) Revisit the meaning of aggregate-principal-transformer

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1115?page=com.atlassian.jira.plugin.s... ] Jan Kalina moved JBEAP-10637 to ELY-1115: ----------------------------------------- Project: WildFly Elytron (was: JBoss Enterprise Application Platform) Key: ELY-1115 (was: JBEAP-10637) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Utils (was: Security) Affects Version/s: 1.1.0.Beta38 (was: 7.1.0.DR14) > Revisit the meaning of aggregate-principal-transformer > ------------------------------------------------------ > > Key: ELY-1115 > URL: https://issues.jboss.org/browse/ELY-1115 > Project: WildFly Elytron > Issue Type: Bug > Components: Utils > Affects Versions: 1.1.0.Beta38 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > Labels: management-model, principal-transformer > > Meaning of Elytron {{aggregate-principal-transformer}} should be revised. Also one point about {{regex-validating-principal-transformer}} is included since it seems its use cases are related to aggregate-principal-transformer. See: > * It seems that it works like "It iterates through assigned Principal Transformers and returns the first non-null transformed Principal" - is it correct and intended behaviour? Is "aggregate-principal-transformer" appropriate name for transformer which works like that? > * What is the use case for regex-validating-principal-transformer. This transformer just checks some pattern and if it does not match then it rewrites Principal name to null. I think it can be useful in aggregate-principal-transformer, when it can check that name matches some pattern in first transformer (regex-validating-principal-transformer) and then transforms principal in another transformer (e.g. constant-principal-transformer). Is there any other use case? > * When can aggregate-principal-transformer return any other Principal Transformer than first of the list? I think only user implemented custom-principal-transformer can currently return null (which enable iterating to another principal transformer in the list). Also regex-validating-principal-transformer can be used for returning non-first transformer, as I mentioned in previous point. Is there any real scenario when aggregate-principal-transformer can be used? > This issue is reported based on previous discussion with engineering. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 5 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 April 2017