December 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JBJCA-1399) Race condition between JCA Capacity Filler and new connections creation

by Flavia Rainone (Jira)

[ https://issues.redhat.com/browse/JBJCA-1399?page=com.atlassian.jira.plugi... ] Flavia Rainone commented on JBJCA-1399: --------------------------------------- As a result, the pool could end up empty. Every connection that is returned to the pool is destroyed, since the pool appears to be bigger than maximum capacity. At some point, the pool will point to a big size (such as 10), and have zero connections inside of it. Due to this consequence, I'm raising the priority of this issue. > Race condition between JCA Capacity Filler and new connections creation > ----------------------------------------------------------------------- > > Key: JBJCA-1399 > URL: https://issues.redhat.com/browse/JBJCA-1399 > Project: IronJacamar > Issue Type: Feature Request > Components: Core > Reporter: Flavia Rainone > Assignee: Flavia Rainone > Priority: Major > > JCA Capacity Filler is unaware of connections being created in a separate thread, which can lead to unexpected behavior, such as the pool being filled with too many connections. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1399) Race condition between JCA Capacity Filler and new connections creation

by Flavia Rainone (Jira)

[ https://issues.redhat.com/browse/JBJCA-1399?page=com.atlassian.jira.plugi... ] Flavia Rainone updated JBJCA-1399: ---------------------------------- Issue Type: Bug (was: Feature Request) > Race condition between JCA Capacity Filler and new connections creation > ----------------------------------------------------------------------- > > Key: JBJCA-1399 > URL: https://issues.redhat.com/browse/JBJCA-1399 > Project: IronJacamar > Issue Type: Bug > Components: Core > Reporter: Flavia Rainone > Assignee: Flavia Rainone > Priority: Major > > JCA Capacity Filler is unaware of connections being created in a separate thread, which can lead to unexpected behavior, such as the pool being filled with too many connections. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1399) Race condition between JCA Capacity Filler and new connections creation

by Flavia Rainone (Jira)

[ https://issues.redhat.com/browse/JBJCA-1399?page=com.atlassian.jira.plugi... ] Flavia Rainone updated JBJCA-1399: ---------------------------------- Priority: Critical (was: Major) > Race condition between JCA Capacity Filler and new connections creation > ----------------------------------------------------------------------- > > Key: JBJCA-1399 > URL: https://issues.redhat.com/browse/JBJCA-1399 > Project: IronJacamar > Issue Type: Bug > Components: Core > Reporter: Flavia Rainone > Assignee: Flavia Rainone > Priority: Critical > > JCA Capacity Filler is unaware of connections being created in a separate thread, which can lead to unexpected behavior, such as the pool being filled with too many connections. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1399) Race condition between JCA Capacity Filler and new connections creation

by Flavia Rainone (Jira)

[ https://issues.redhat.com/browse/JBJCA-1399?page=com.atlassian.jira.plugi... ] Flavia Rainone commented on JBJCA-1399: --------------------------------------- So, I'm not sure how this translates to a race condition yet, but the problem is that SemaphoreConcurrentLinkedDequeManagedConnectionPool.increaseCapacity is faulty when it reaches the limit. If it reaches the limit, it doesn't decrement the poolSize when removing the new connection. That leads to a "leak" in the pool size. I.e., the pool will appear bigger than it is. At every interaction, the pool is decremented because the size increases constantly at every attempt to fill the pool. I'm still investigating this [~stephen.fikes], because I want to be sure why it is a race condition before fixing it, since I wasn't able to reproduce the bug in my machine. > Race condition between JCA Capacity Filler and new connections creation > ----------------------------------------------------------------------- > > Key: JBJCA-1399 > URL: https://issues.redhat.com/browse/JBJCA-1399 > Project: IronJacamar > Issue Type: Feature Request > Components: Core > Reporter: Flavia Rainone > Assignee: Flavia Rainone > Priority: Major > > JCA Capacity Filler is unaware of connections being created in a separate thread, which can lead to unexpected behavior, such as the pool being filled with too many connections. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4024) Move keyboard shortcuts to menus in DMN.

by Sarah Rambacher (Jira)

[ https://issues.redhat.com/browse/DROOLS-4024?page=com.atlassian.jira.plug... ] Sarah Rambacher commented on DROOLS-4024: ----------------------------------------- There probably should be a comprehensive review of shortcut keys, judging by this one as it's pretty non-standard. But that seems like a large effort that should be planned; for now it would be really good to add the name of the action in to the tooltip as well as the shortcut. > Move keyboard shortcuts to menus in DMN. > ---------------------------------------- > > Key: DROOLS-4024 > URL: https://issues.redhat.com/browse/DROOLS-4024 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Elizabeth Clayton > Assignee: karreiro > Priority: Major > Labels: UX, UXTeam, drools-tools > Attachments: currentMenu.png, insert+.png, kebab-shortcuts.png > > > As a business analyst practitioner, I would like to view the keyboard shortcuts in the context of the menu actions that they refer to. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3948) Potential race condition on deployment of EAR when Class-Path manifest entry is in use

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFCORE-3948?page=com.atlassian.jira.plug... ] Brian Stansberry commented on WFCORE-3948: ------------------------------------------ Yeah I should have known better than to rely on test failures to tell me about any problem. > Potential race condition on deployment of EAR when Class-Path manifest entry is in use > -------------------------------------------------------------------------------------- > > Key: WFCORE-3948 > URL: https://issues.redhat.com/browse/WFCORE-3948 > Project: WildFly Core > Issue Type: Bug > Components: Server > Reporter: Stuart Douglas > Assignee: Brian Stansberry > Priority: Major > Fix For: 11.0.0.Beta4 > > > Attachments#ADDITIONAL_MODULES is attached to the top level DU, but modified by sub deployments in ManifestClassPathProcessor#createAdditionalModule without any sort of synchronisation. This can result in ConcurrentModificationException when the list is read/written to by other sub deployments at the same time. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBEE-249) Types associated with wildcard imports fail to load on Windows

by James Perkins (Jira)

[ https://issues.redhat.com/browse/JBEE-249?page=com.atlassian.jira.plugin.... ] James Perkins resolved JBEE-249. -------------------------------- Resolution: Done > Types associated with wildcard imports fail to load on Windows > -------------------------------------------------------------- > > Key: JBEE-249 > URL: https://issues.redhat.com/browse/JBEE-249 > Project: JBoss Enterprise Spec APIs > Issue Type: Bug > Components: jboss-el-api > Reporter: James Perkins > Assignee: James Perkins > Priority: Major > > As reported in WFLY-12701 a {{java.lang.NoClassDefFoundError}} in some cases on Windows. This looks like it's a result of Windows being case sensitive with paths, see https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8024775. The workaround is to not use wildcard imports. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3948) Potential race condition on deployment of EAR when Class-Path manifest entry is in use

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFCORE-3948?page=com.atlassian.jira.plug... ] Paul Ferraro commented on WFCORE-3948: -------------------------------------- [~brian.stansberry] It means undeploy throws a bunch of exceptions. See linked jira. > Potential race condition on deployment of EAR when Class-Path manifest entry is in use > -------------------------------------------------------------------------------------- > > Key: WFCORE-3948 > URL: https://issues.redhat.com/browse/WFCORE-3948 > Project: WildFly Core > Issue Type: Bug > Components: Server > Reporter: Stuart Douglas > Assignee: Brian Stansberry > Priority: Major > Fix For: 11.0.0.Beta4 > > > Attachments#ADDITIONAL_MODULES is attached to the top level DU, but modified by sub deployments in ManifestClassPathProcessor#createAdditionalModule without any sort of synchronisation. This can result in ConcurrentModificationException when the list is read/written to by other sub deployments at the same time. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-262) When setting the close handlers on a log context the control permission should be checked

by James Perkins (Jira)

[ https://issues.redhat.com/browse/LOGMGR-262?page=com.atlassian.jira.plugi... ] James Perkins updated LOGMGR-262: --------------------------------- Fix Version/s: 2.2.0.Final 3.0.0.Final > When setting the close handlers on a log context the control permission should be checked > ----------------------------------------------------------------------------------------- > > Key: LOGMGR-262 > URL: https://issues.redhat.com/browse/LOGMGR-262 > Project: JBoss Log Manager > Issue Type: Bug > Components: core > Reporter: James Perkins > Assignee: James Perkins > Priority: Blocker > Fix For: 2.1.15.Final, 2.2.0.Final, 3.0.0.Final > > > The {{LogContext}} has a {{LogContext.setCloseHandlers(Collection<AutoCloseable>)}} and {{LogContext.addCloseHandler(AutoCloseable)}} method which does not check the control permission before just setting the values. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-262) When setting the close handlers on a log context the control permission should be checked

by James Perkins (Jira)

[ https://issues.redhat.com/browse/LOGMGR-262?page=com.atlassian.jira.plugi... ] James Perkins updated LOGMGR-262: --------------------------------- Involved: (was: David Lloyd) > When setting the close handlers on a log context the control permission should be checked > ----------------------------------------------------------------------------------------- > > Key: LOGMGR-262 > URL: https://issues.redhat.com/browse/LOGMGR-262 > Project: JBoss Log Manager > Issue Type: Bug > Components: core > Reporter: James Perkins > Assignee: James Perkins > Priority: Blocker > Fix For: 2.1.15.Final > > > The {{LogContext}} has a {{LogContext.setCloseHandlers(Collection<AutoCloseable>)}} and {{LogContext.addCloseHandler(AutoCloseable)}} method which does not check the control permission before just setting the values. -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 5 months

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 December 2019