March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1492) DecisionTable to perform typeRef allowed values check for input and output clause

by Matteo Mortari (JIRA)

Matteo Mortari created DROOLS-1492: -------------------------------------- Summary: DecisionTable to perform typeRef allowed values check for input and output clause Key: DROOLS-1492 URL: https://issues.jboss.org/browse/DROOLS-1492 Project: Drools Issue Type: Feature Request Components: dmn engine Reporter: Matteo Mortari Assignee: Matteo Mortari Example model {code:xml} <definitions id="definitions" ... <itemDefinition label="MyType" name="MyType"> <typeRef>feel:string</typeRef> <allowedValues constraintsType="enumeration"> <text>"a","b","c"</text> </allowedValues> </itemDefinition> <inputData id="_3d560678-a126-4654-a686-bc6d941fe40b" name="MyInput"> <variable id="_053333df-1777-45f1-a6c7-56562fbdfdae" name="MyInput" typeRef="kie:MyType"/> </inputData> <decision id="_497a5306-b2e8-4945-b8b5-82af2e2b99b5" name="MyDecision"> <variable id="_514d6d8d-5329-44fa-af91-a7e7addbadd8" name="MyDecision" typeRef="feel:string"/> <informationRequirement> <requiredInput href="#_3d560678-a126-4654-a686-bc6d941fe40b"/> </informationRequirement> <decisionTable hitPolicy="UNIQUE" id="_fff2b82e-2850-4826-adc9-4b1570d6fa91" outputLabel="MyDecision"> <input id="_e0471736-9a71-40c7-b5ca-bf367c6a3af9" label="MyInput"> <inputExpression typeRef="kie:MyType"> <text>MyInput</text> </inputExpression> </input> <output id="_01796218-0d50-4ebe-bd2b-b4509318e334"/> <rule id="_fd1835b6-5fe1-4fd9-a8e4-39b4f7083b24"> <inputEntry expressionLanguage="http://www.omg.org/spec/FEEL/20140401" id="_1c8b24c7-e722-40d7-8661-f03d402688d2"> <text>-</text> </inputEntry> <outputEntry id="_0b9d04fe-032b-4753-84dd-9838f6cdef53"> <text>"Decision taken"</text> </outputEntry> </rule> </decisionTable> </decision> </definitions> {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1344) race condition between PoolFiller and CapacityFiller results in wrong pool statistics

by Martin Simka (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1344?page=com.atlassian.jira.plugin... ] Martin Simka reassigned JBJCA-1344: ----------------------------------- Assignee: Flavia Rainone > race condition between PoolFiller and CapacityFiller results in wrong pool statistics > ------------------------------------------------------------------------------------- > > Key: JBJCA-1344 > URL: https://issues.jboss.org/browse/JBJCA-1344 > Project: IronJacamar > Issue Type: Bug > Affects Versions: WildFly/IronJacamar 1.4.2.Final > Reporter: Martin Simka > Assignee: Flavia Rainone > Attachments: fail.log, pass.log > > > There seems to be race condition between PoolFiller and CapacityFiller which results in wrong pool statistics > I think what happens is: > - Both add connections to pool in different threads > - PoolFiller creates connection, then checks pools size and because pool has already certain size, it doesn't add connection and instead it destroys connection which increases destroyedCount > see [SemaphoreConcurrentLinkedDequeManagedConnectionPool.java#L1163|https://gi...] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1344) race condition between PoolFiller and CapacityFiller results in wrong pool statistics

by Martin Simka (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1344?page=com.atlassian.jira.plugin... ] Martin Simka reassigned JBJCA-1344: ----------------------------------- Affects Version/s: WildFly/IronJacamar 1.4.2.Final Assignee: (was: Flavia Rainone) > race condition between PoolFiller and CapacityFiller results in wrong pool statistics > ------------------------------------------------------------------------------------- > > Key: JBJCA-1344 > URL: https://issues.jboss.org/browse/JBJCA-1344 > Project: IronJacamar > Issue Type: Bug > Affects Versions: WildFly/IronJacamar 1.4.2.Final > Reporter: Martin Simka > Attachments: fail.log, pass.log > > > There seems to be race condition between PoolFiller and CapacityFiller which results in wrong pool statistics > I think what happens is: > - Both add connections to pool in different threads > - PoolFiller creates connection, then checks pools size and because pool has already certain size, it doesn't add connection and instead it destroys connection which increases destroyedCount > see [SemaphoreConcurrentLinkedDequeManagedConnectionPool.java#L1163|https://gi...] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1344) race condition between PoolFiller and CapacityFiller results in wrong pool statistics

by Stefano Maestri (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1344?page=com.atlassian.jira.plugin... ] Stefano Maestri reassigned JBJCA-1344: -------------------------------------- Assignee: Flavia Rainone > race condition between PoolFiller and CapacityFiller results in wrong pool statistics > ------------------------------------------------------------------------------------- > > Key: JBJCA-1344 > URL: https://issues.jboss.org/browse/JBJCA-1344 > Project: IronJacamar > Issue Type: Bug > Reporter: Martin Simka > Assignee: Flavia Rainone > Attachments: fail.log, pass.log > > > There seems to be race condition between PoolFiller and CapacityFiller which results in wrong pool statistics > I think what happens is: > - Both add connections to pool in different threads > - PoolFiller creates connection, then checks pools size and because pool has already certain size, it doesn't add connection and instead it destroys connection which increases destroyedCount > see [SemaphoreConcurrentLinkedDequeManagedConnectionPool.java#L1163|https://gi...] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1345) race condition between PoolFiller and CapacityFiller results in wrong pool statistics

by Martin Simka (JIRA)

Martin Simka created JBJCA-1345: ----------------------------------- Summary: race condition between PoolFiller and CapacityFiller results in wrong pool statistics Key: JBJCA-1345 URL: https://issues.jboss.org/browse/JBJCA-1345 Project: IronJacamar Issue Type: Bug Reporter: Martin Simka There seems to be race condition between PoolFiller and CapacityFiller which results in wrong pool statistics I think what happens is: - Both add connections to pool in different threads - PoolFiller creates connection, then checks pools size and because pool has already certain size, it doesn't add connection and instead it destroys connection which increases destroyedCount see [SemaphoreConcurrentLinkedDequeManagedConnectionPool.java#L1163|https://gi...] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1344) race condition between PoolFiller and CapacityFiller results in wrong pool statistics

by Martin Simka (JIRA)

Martin Simka created JBJCA-1344: ----------------------------------- Summary: race condition between PoolFiller and CapacityFiller results in wrong pool statistics Key: JBJCA-1344 URL: https://issues.jboss.org/browse/JBJCA-1344 Project: IronJacamar Issue Type: Bug Reporter: Martin Simka Attachments: fail.log, pass.log There seems to be race condition between PoolFiller and CapacityFiller which results in wrong pool statistics I think what happens is: - Both add connections to pool in different threads - PoolFiller creates connection, then checks pools size and because pool has already certain size, it doesn't add connection and instead it destroys connection which increases destroyedCount see [SemaphoreConcurrentLinkedDequeManagedConnectionPool.java#L1163|https://gi...] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2071) Ignore unknown roles instead of throwing exception

by Pedro Igor (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2071?page=com.atlassian.jira.plugi... ] Pedro Igor updated WFCORE-2071: ------------------------------- Summary: Ignore unknown roles instead of throwing exception (was: Properly handle unknown roles instead of throwing exception) > Ignore unknown roles instead of throwing exception > -------------------------------------------------- > > Key: WFCORE-2071 > URL: https://issues.jboss.org/browse/WFCORE-2071 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Pedro Igor > Assignee: Pedro Igor > Fix For: 3.0.0.Beta11 > > > When mapping roles directly from the identity: > {code} > <access-control provider="rbac" use-identity-roles="true"/> > {code} > If the identity has a role that is not known, a {{UnknowRoleException}} is thrown. > Ideally, we should just ignore unknown roles. Or is there any reason for this check ? -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1024) Match rules do not allow matching any-or-no user

by David Lloyd (JIRA)

David Lloyd created ELY-1024: -------------------------------- Summary: Match rules do not allow matching any-or-no user Key: ELY-1024 URL: https://issues.jboss.org/browse/ELY-1024 Project: WildFly Elytron Issue Type: Bug Components: Authentication Client Reporter: David Lloyd Assignee: David Lloyd -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2570) Explain the meaning of maximum-session-cache-size and session-timeout default values.

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2570?page=com.atlassian.jira.plugi... ] Ilia Vassilev updated WFCORE-2570: ---------------------------------- Affects Version/s: 3.0.0.Beta9 > Explain the meaning of maximum-session-cache-size and session-timeout default values. > ------------------------------------------------------------------------------------- > > Key: WFCORE-2570 > URL: https://issues.jboss.org/browse/WFCORE-2570 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta9 > Reporter: Ilia Vassilev > Assignee: Ilia Vassilev > > The default values 0 of maximum-session-cache-size and session-timeout of Elytron will not override the JVM defaults. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8419) poll pool stats in loop instead of Thread.sleep in AbstractDatasourceCapacityPoliciesTestCase

by Martin Simka (JIRA)

[ https://issues.jboss.org/browse/WFLY-8419?page=com.atlassian.jira.plugin.... ] Martin Simka updated WFLY-8419: ------------------------------- Description: There is {{Thread.sleep}} in [AbstractDatasourceCapacityPoliciesTestCase.java#L130|https://github.com/w...] and [ResourceAdapterCapacityPoliciesTestCase.java#L148|https://github.com/wild...] which is used to wait until pool is filled with expected number of connections. But it is generally better to loop around for a while until things are in the right state, and then fail if that state does not happen within a (adjustable) timeout (was: There is {{Thread.sleep}} in [AbstractDatasourceCapacityPoliciesTestCase.java#L130|https://github.com/w...] which is used to wait until pool is filled with expected number of connections. But it is generally better to loop around for a while until things are in the right state, and then fail if that state does not happen within a (adjustable) timeout) > poll pool stats in loop instead of Thread.sleep in AbstractDatasourceCapacityPoliciesTestCase > --------------------------------------------------------------------------------------------- > > Key: WFLY-8419 > URL: https://issues.jboss.org/browse/WFLY-8419 > Project: WildFly > Issue Type: Task > Components: Test Suite > Reporter: Martin Simka > Assignee: Martin Simka > Priority: Trivial > > There is {{Thread.sleep}} in [AbstractDatasourceCapacityPoliciesTestCase.java#L130|https://github.com/w...] and [ResourceAdapterCapacityPoliciesTestCase.java#L148|https://github.com/wild...] which is used to wait until pool is filled with expected number of connections. But it is generally better to loop around for a while until things are in the right state, and then fail if that state does not happen within a (adjustable) timeout -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

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