January 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-12929) Session remove event can deadlock if it attempts write operations on a session

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-12929?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-12929: -------------------------------- Affects Version/s: 18.0.1.Final (was: 18.0.0.Final) > Session remove event can deadlock if it attempts write operations on a session > ------------------------------------------------------------------------------ > > Key: WFLY-12929 > URL: https://issues.redhat.com/browse/WFLY-12929 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 18.0.1.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > Labels: downstream_dependency > > Activation/passivation listeners are intentionally non-transactional - and thus should never attempt to perform cache writes. > In order to trigger the requisite activation/passivation listeners, activation/passivation events need to lookup the cache entries relevant to a given session via SessionFactory.findValue(..). However, if there are entries missing (e.g. a creation meta data entry w/out a access meta data entry), this method will attempt to purge the orphaned entries. This should never be done within the context of an activation/passivation event. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12929) Session remove event can deadlock if it attempts write operations on a session

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-12929?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-12929: -------------------------------- Fix Version/s: (was: 19.0.0.Beta1) > Session remove event can deadlock if it attempts write operations on a session > ------------------------------------------------------------------------------ > > Key: WFLY-12929 > URL: https://issues.redhat.com/browse/WFLY-12929 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 18.0.1.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > Labels: downstream_dependency > > Activation/passivation listeners are intentionally non-transactional - and thus should never attempt to perform cache writes. > In order to trigger the requisite activation/passivation listeners, activation/passivation events need to lookup the cache entries relevant to a given session via SessionFactory.findValue(..). However, if there are entries missing (e.g. a creation meta data entry w/out a access meta data entry), this method will attempt to purge the orphaned entries. This should never be done within the context of an activation/passivation event. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12929) Session remove event can deadlock if it attempts write operations on a session

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-12929?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-12929: -------------------------------- Git Pull Request: (was: https://github.com/wildfly/wildfly/pull/12705) > Session remove event can deadlock if it attempts write operations on a session > ------------------------------------------------------------------------------ > > Key: WFLY-12929 > URL: https://issues.redhat.com/browse/WFLY-12929 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 18.0.1.Final > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > Labels: downstream_dependency > > Activation/passivation listeners are intentionally non-transactional - and thus should never attempt to perform cache writes. > In order to trigger the requisite activation/passivation listeners, activation/passivation events need to lookup the cache entries relevant to a given session via SessionFactory.findValue(..). However, if there are entries missing (e.g. a creation meta data entry w/out a access meta data entry), this method will attempt to purge the orphaned entries. This should never be done within the context of an activation/passivation event. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12929) Session remove event can deadlock if it attempts write operations on a session

by Paul Ferraro (Jira)

Paul Ferraro created WFLY-12929: ----------------------------------- Summary: Session remove event can deadlock if it attempts write operations on a session Key: WFLY-12929 URL: https://issues.redhat.com/browse/WFLY-12929 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 18.0.0.Final Reporter: Paul Ferraro Assignee: Paul Ferraro Fix For: 19.0.0.Beta1 Activation/passivation listeners are intentionally non-transactional - and thus should never attempt to perform cache writes. In order to trigger the requisite activation/passivation listeners, activation/passivation events need to lookup the cache entries relevant to a given session via SessionFactory.findValue(..). However, if there are entries missing (e.g. a creation meta data entry w/out a access meta data entry), this method will attempt to purge the orphaned entries. This should never be done within the context of an activation/passivation event. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4789) Enable TLS 1.3 by default

by Farah Juma (Jira)

Farah Juma created WFCORE-4789: ---------------------------------- Summary: Enable TLS 1.3 by default Key: WFCORE-4789 URL: https://issues.redhat.com/browse/WFCORE-4789 Project: WildFly Core Issue Type: Feature Request Components: Security Reporter: Farah Juma WFCORE-4172 added support for TLS 1.3 but left TLS 1.3 disabled by default for reasons described in WFWIP-160: https://github.com/wildfly/wildfly-core/pull/3815/commits/4ee03bd5662b1fd... Once we are ready to do so, we should enable TLS 1.3 by default. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ELY-1917) Enable TLS 1.3 by default

by Farah Juma (Jira)

Farah Juma created ELY-1917: ------------------------------- Summary: Enable TLS 1.3 by default Key: ELY-1917 URL: https://issues.redhat.com/browse/ELY-1917 Project: WildFly Elytron Issue Type: Feature Request Components: SSL Reporter: Farah Juma ELY-1706 added support for TLS 1.3 but left TLS 1.3 disabled by default for reasons described in WFWIP-160: https://github.com/wildfly-security/wildfly-elytron/pull/1295/commits/0f2... Once we are ready to do so, we should enable TLS 1.3 by default. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12915) Clean out unneeded provisioning boilerplate

by Brian Stansberry (Jira)

[ https://issues.redhat.com/browse/WFLY-12915?page=com.atlassian.jira.plugi... ] Brian Stansberry resolved WFLY-12915. ------------------------------------- Resolution: Duplicate Issue > Clean out unneeded provisioning boilerplate > ------------------------------------------- > > Key: WFLY-12915 > URL: https://issues.redhat.com/browse/WFLY-12915 > Project: WildFly > Issue Type: Task > Components: Build System > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Priority: Major > > The current Galleon versions should allow trimming quite a bit of boilerplate from all the places where we provision servers: > Alexey Loubyansky 5:07 PM > I did a bit more work on this, fixed a couple of issues and just released Galleon 4.2.1.Final and WFGP 4.2.1.Final > Alexey Loubyansky 5:07 PM > also opened a PR to upgrade WildFly Core to these releases https://github.com/wildfly/wildfly-core/pull/4025 > 5:08 PM > upgrading doesn't affect anything, except the bug fixes contained in those versions > 5:10 PM > however, for wildfly, i think we should use GAVs as feature-pack locations for feature-pack dependencies, in place of Galleon FPL > 5:11 PM > the benefit would be to avoid the universe resolver in maven builds > 5:11 PM > and also a simplified (mojo) provisioning config > Brian Stansberry 5:14 PM > good timing; I'm working on how to add a new f-p to wildfly (for microprofile stuff) so i should use best practices :) > Alexey Loubyansky 5:16 PM > by simplified provisioning config i mean that the selected block should be removed completely https://github.com/wildfly/wildfly/blob/master/build/pom.xml#L84-L97 > 5:16 PM > the only reason it is there is to avoid resolution from the universe > 5:17 PM > with GAVs for dependencies, it won't be necessary anymore > Brian Stansberry 5:17 PM > what about <inheritConfigs>false</inheritConfigs> ? > Alexey Loubyansky 5:18 PM > that was there to workaround a bug which was fixed in 4.2.0.Final > Brian Stansberry 5:18 PM > how about > 5:18 PM > <included-packages> > <name>docs.examples.configs</name> > </included-packages> > 5:19 PM > assuming that's not in the top level f-p > Alexey Loubyansky 5:19 PM > that should definitely stay, it's not in the selected block > 5:19 PM > ah, then you can have that > 5:20 PM > then there would be a real reason to mention the transitive dependency > 5:20 PM > i.e. you want something from it > Brian Stansberry 5:20 PM > could it be declared in the top level block, even though the package is in the transitive dep? > 5:20 PM > i'm going off on tangents, but first i should have said... > 5:21 PM > Nice! > Alexey Loubyansky 5:21 PM (EDITED) > unless the package is installed by default, it has to be included explicitly using transitive element > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1401) Avoid flushing pooled connections when matchManagedConnections returns no match

by Stephen Fikes (Jira)

[ https://issues.redhat.com/browse/JBJCA-1401?page=com.atlassian.jira.plugi... ] Stephen Fikes commented on JBJCA-1401: -------------------------------------- [~maeste], can you verify if there is a workaround to have pooling when using different credentials with a resource adapter? Would the workaround be to define different connection-definitions for each distinct credential? > Avoid flushing pooled connections when matchManagedConnections returns no match > ------------------------------------------------------------------------------- > > Key: JBJCA-1401 > URL: https://issues.redhat.com/browse/JBJCA-1401 > Project: IronJacamar > Issue Type: Feature Request > Components: Core > Affects Versions: 1.4.10 > Reporter: Stephen Fikes > Priority: Major > > When no match is returned by the resource adapter implementation of [ManagedConnectionFactory.matchManagedConnections|https://docs.oracle.com/...], the IronJacamar pool implementation [terminates non-matching connections|https://github.com/ironjacamar/ironjacamar/blob/ironjacamar-1...]. > There may be cases where resource adapters return {{null}} for cases where no connection matches but where the connections in the match set are not invalid though a different connection needs to be created based on the calling context ({{ConnectionRequestInfo}}). > A mechanism to avoid the termination of non-matching connections is needed to support such cases. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-1048) Testcases - Kiali Validations sync-up

by Hayk Hovsepyan (Jira)

[ https://issues.redhat.com/browse/SWSQE-1048?page=com.atlassian.jira.plugi... ] Hayk Hovsepyan commented on SWSQE-1048: --------------------------------------- "MeshPolicy enabling mTLS is missing" is shown in fact "ServiceMeshPolicy enabling mTLS is missing" > Testcases - Kiali Validations sync-up > ------------------------------------- > > Key: SWSQE-1048 > URL: https://issues.redhat.com/browse/SWSQE-1048 > Project: Kiali QE > Issue Type: Sub-task > Reporter: Hayk Hovsepyan > Assignee: Sunil Kondkar > Priority: Major > > Sync up all validations from https://kiali.io/documentation/validations/ with Polarion estcases. > Make sure all validations have up-to-date testcases in Polarion. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4903) In constraints fail to compile if negated or inside a forall pattern

by Matteo Casalino (Jira)

Matteo Casalino created DROOLS-4903: --------------------------------------- Summary: In constraints fail to compile if negated or inside a forall pattern Key: DROOLS-4903 URL: https://issues.redhat.com/browse/DROOLS-4903 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.31.0.Final Reporter: Matteo Casalino Assignee: Mario Fusco Attachments: in-constraint-negation.tgz It appears that the KieBuilder fails to compile the following pattern: {noformat} Pojo(!(x in (1,2,3))) {noformat} returning the following error: {noformat} Error Messages: Message [id=1, kieBase=defaultKieBase, level=ERROR, path=rules.drl, line=4, column=0 text=Unable to Analyse Expression !(x in (1,2,3)): [Error: unexpected token: ,2] [Near : {... !(x in (1,2,3)) ....}] {noformat} Furthermore, as of Drools 7.29.0.Final, the following form will also fail to compile: {noformat} forall(Pojo(y==42, x in (1,2,3))) {noformat} with the following error: {noformat} Error Messages: Message [id=1, kieBase=defaultKieBase, level=ERROR, path=rules.drl, line=4, column=0 text=Unable to Analyse Expression !(y==42) || !(x in (1,2,3)): [Error: unexpected token: ,2] [Near : {... !(y==42) || !(x in (1,2,3)) ....}] {noformat} The latter is likely a consequence of the negation introduced by [DROOLS-4632|https://issues.redhat.com/browse/DROOLS-4632] -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2020