April 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8427) Unignore XADatasourceCapacityPoliciesTestCase

by Martin Simka (JIRA)

[ https://issues.jboss.org/browse/WFLY-8427?page=com.atlassian.jira.plugin.... ] Martin Simka updated WFLY-8427: ------------------------------- Git Pull Request: https://github.com/wildfly/wildfly/pull/9941 > Unignore XADatasourceCapacityPoliciesTestCase > --------------------------------------------- > > Key: WFLY-8427 > URL: https://issues.jboss.org/browse/WFLY-8427 > Project: WildFly > Issue Type: Bug > Reporter: Kabir Khan > Assignee: Martin Simka > > I am going to ignore this test, until the ironjacamar upgrade which fixes the following (from [~simkam]'s mail) > {quote} > I might be completely wrong, but it seems to me like race condition between PoolFiller and CapacityFiller in IronJacamar. > 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 https://github.com/ironjacamar/ironjacamar/blob/1.4/core/src/main/java/or... > @Stefano, @Flavia could you please take a look? > I'm attaching logs with enabled TRACE on org.jboss.jca and jdbc.spy. > This might have been hidden until https://issues.jboss.org/browse/JBJCA-1330 was fixed in DR11. > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

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 closed JBJCA-1344. ------------------------------- Resolution: Rejected closing as rejected. https://github.com/wildfly/wildfly/pull/9941 fixes test in WildFly test suite > 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
0
0 / 0

[JBoss JIRA] (WFCORE-2682) Elytron token-realm attributes validations

by Martin Choma (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2682?page=com.atlassian.jira.plugi... ] Martin Choma moved JBEAP-10380 to WFCORE-2682: ---------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-2682 (was: JBEAP-10380) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: Security) Affects Version/s: 3.0.0.Beta13 (was: 7.1.0.DR16) > Elytron token-realm attributes validations > ------------------------------------------ > > Key: WFCORE-2682 > URL: https://issues.jboss.org/browse/WFCORE-2682 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta13 > Reporter: Martin Choma > > * I am able to set both {{key-store}} and {{public-key}} attributes. However based on model they should be alternatives and thus only one of them should be allowed. > * Althought, {{key-store}} and {{certificate}} are configured as requires in model, validation does not work. > Seems it is caused by WFCORE-2317. > {code} > "public-key" => { > "type" => STRING, > "description" => "A public key in PEM Format. During validation, if a public key is provided, signature will be verified based on the key you provided here.", > "expressions-allowed" => true, > "required" => false, > "nillable" => true, > "alternatives" => [ > "key-store", > "certificate" > ], > "min-length" => 1L, > "max-length" => 2147483647L > }, > "key-store" => { > "type" => STRING, > "description" => "A key store from where the certificate with a public key should be loaded from.", > "expressions-allowed" => false, > "required" => false, > "nillable" => true, > "alternatives" => ["public-key"], > "requires" => ["certificate"], > "capability-reference" => "org.wildfly.security.key-store", > "min-length" => 1L, > "max-length" => 2147483647L > }, > "certificate" => { > "type" => STRING, > "description" => "The name of the certificate with a public key to load from the key store.", > "expressions-allowed" => true, > "required" => false, > "nillable" => true, > "alternatives" => ["public-key"], > "requires" => ["key-store"], > "min-length" => 1L, > "max-length" => 2147483647L > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2681) Upgrade WildFly Elytron to 1.1.0.Beta37

by Kabir Khan (JIRA)

Kabir Khan created WFCORE-2681: ---------------------------------- Summary: Upgrade WildFly Elytron to 1.1.0.Beta37 Key: WFCORE-2681 URL: https://issues.jboss.org/browse/WFCORE-2681 Project: WildFly Core Issue Type: Component Upgrade Components: Security Reporter: Peter Skopek Assignee: Peter Skopek Fix For: 3.0.0.Beta16 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ELY-1082) Documentation is missing in elytron-1_0.xsd

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-1082?page=com.atlassian.jira.plugin.s... ] Ondrej Lukas moved JBEAP-10375 to ELY-1082: ------------------------------------------- Project: WildFly Elytron (was: JBoss Enterprise Application Platform) Key: ELY-1082 (was: JBEAP-10375) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: (was: Security) (was: User Experience) Affects Version/s: 1.1.0.Beta34 (was: 7.1.0.DR16) > Documentation is missing in elytron-1_0.xsd > ------------------------------------------- > > Key: ELY-1082 > URL: https://issues.jboss.org/browse/ELY-1082 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta34 > Reporter: Ondrej Lukas > Priority: Critical > > XSD file {{elytron-1_0.xsd}} [1] includes almost no documentation. If this XSD is included in server distribution (as {{docs/schema/elytron-1_0.xsd}}) then it affects user experience. > [1] https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2656) DeploymentTestCase.testFilesystemScannerRegistration fails intermittently

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2656?page=com.atlassian.jira.plugi... ] Chao Wang edited comment on WFCORE-2656 at 4/18/17 4:12 AM: ------------------------------------------------------------ I have also seen this test fails today with error: {noformat} Failed tests: DeploymentTestCase.testFilesystemScannerRegistration:253->addDeploymentScanner:799->addDeploymentScanner:817 { "outcome" => "failed", "failure-description" => "WFLYCTL0436: Cannot register capability 'org.wildfly.management.deployment-scanner.dummy' at location '[ (\"subsystem\" => \"deployment-scanner\"), (\"scanner\" => \"dummy\") ]' as it is already registered in context 'global' at location(s) '[[ (\"subsystem\" => \"deployment-scanner\"), (\"scanner\" => \"dummy\") ]]'", "rolled-back" => true } expected:<[success]> but was:<[failed]> {noformat} But it fails constantly on my machine, Is this the same cause appeared on CI ? Edit: [~ehugonnet] confirmed this on IRC. thanks was (Author: soul2zimate): I have also seen this test fails today with error: {noformat} Failed tests: DeploymentTestCase.testFilesystemScannerRegistration:253->addDeploymentScanner:799->addDeploymentScanner:817 { "outcome" => "failed", "failure-description" => "WFLYCTL0436: Cannot register capability 'org.wildfly.management.deployment-scanner.dummy' at location '[ (\"subsystem\" => \"deployment-scanner\"), (\"scanner\" => \"dummy\") ]' as it is already registered in context 'global' at location(s) '[[ (\"subsystem\" => \"deployment-scanner\"), (\"scanner\" => \"dummy\") ]]'", "rolled-back" => true } expected:<[success]> but was:<[failed]> {noformat} But it fails constantly on my machine, Is this the same cause appeared on CI ? > DeploymentTestCase.testFilesystemScannerRegistration fails intermittently > ------------------------------------------------------------------------- > > Key: WFCORE-2656 > URL: https://issues.jboss.org/browse/WFCORE-2656 > Project: WildFly Core > Issue Type: Bug > Components: Deployment Scanner, Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&tes... > I fear this has something to do with the capability registry and nothing to do with the scanner itself. It started happening when I added a capability to the scanner so it could consume a capability for the path it references. > The test does a quick add/remove/add of a scanner resource and it's the 2nd add that fails with a dupicate capability error. But the remove mean the dup is gone. It's intermittent so I fear some race, but there's nothing obvious. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-88) Manual Full Regression Testing

by Sunil kondkar (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-88?page=com.atlassian.jira.plu... ] Sunil kondkar reassigned HAWKULARQE-88: --------------------------------------- Assignee: Sunil kondkar (was: Michael Foley) > Manual Full Regression Testing > ------------------------------ > > Key: HAWKULARQE-88 > URL: https://issues.jboss.org/browse/HAWKULARQE-88 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: Hayk Hovsepyan > Assignee: Sunil kondkar > > Define the set of testcases to run. > Create test run in Polarion, add those testcases there. > Execute manual testcases. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2656) DeploymentTestCase.testFilesystemScannerRegistration fails intermittently

by ehsavoie Hugonnet (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2656?page=com.atlassian.jira.plugi... ] ehsavoie Hugonnet edited comment on WFCORE-2656 at 4/18/17 4:10 AM: -------------------------------------------------------------------- [~brian.stansberry] you are correct I 'see' a rollback of the CapabilityRegistry after the 'failure' of the RT : 2017-04-18 09:43:01,668 TRACE [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) Executing "read-children-resources" [] 2017-04-18 09:43:01,668 TRACE [org.jboss.threads.interrupt-handler] (MSC service thread 1-8) Interrupting thread "Thread[DeploymentScanner-threads - 1,5,DeploymentScanner-threads]" 2017-04-18 09:43:01,668 TRACE [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) Rolling back on cancellation of operation read-children-resources on address [] in stage MODEL 2017-04-18 09:43:01,668 TRACE [org.jboss.as.controller.management-operation] (management-handler-thread - 1) persisting org.jboss.as.controller.registry.BasicResource@4fcba122 from org.jboss.as.controller.ModelControllerImpl$ManagementModelImpl@3c98ea29 2017-04-18 09:43:01,668 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) Rollbacking current registry was (Author: ehugonnet): [~brian.stansberry]you are correct I 'see' a rollback of the CapabilityRegistry after the 'failure' of the RT : 2017-04-18 09:43:01,668 TRACE [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) Executing "read-children-resources" [] 2017-04-18 09:43:01,668 TRACE [org.jboss.threads.interrupt-handler] (MSC service thread 1-8) Interrupting thread "Thread[DeploymentScanner-threads - 1,5,DeploymentScanner-threads]" 2017-04-18 09:43:01,668 TRACE [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) Rolling back on cancellation of operation read-children-resources on address [] in stage MODEL 2017-04-18 09:43:01,668 TRACE [org.jboss.as.controller.management-operation] (management-handler-thread - 1) persisting org.jboss.as.controller.registry.BasicResource@4fcba122 from org.jboss.as.controller.ModelControllerImpl$ManagementModelImpl@3c98ea29 2017-04-18 09:43:01,668 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) Rollbacking current registry > DeploymentTestCase.testFilesystemScannerRegistration fails intermittently > ------------------------------------------------------------------------- > > Key: WFCORE-2656 > URL: https://issues.jboss.org/browse/WFCORE-2656 > Project: WildFly Core > Issue Type: Bug > Components: Deployment Scanner, Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&tes... > I fear this has something to do with the capability registry and nothing to do with the scanner itself. It started happening when I added a capability to the scanner so it could consume a capability for the path it references. > The test does a quick add/remove/add of a scanner resource and it's the 2nd add that fails with a dupicate capability error. But the remove mean the dup is gone. It's intermittent so I fear some race, but there's nothing obvious. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-87) Remove Postgres installation from Hawkular Services Installation

by Hayk Hovsepyan (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-87?page=com.atlassian.jira.plu... ] Hayk Hovsepyan reassigned HAWKULARQE-87: ---------------------------------------- Assignee: Hayk Hovsepyan (was: Michael Foley) > Remove Postgres installation from Hawkular Services Installation > ---------------------------------------------------------------- > > Key: HAWKULARQE-87 > URL: https://issues.jboss.org/browse/HAWKULARQE-87 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: Hayk Hovsepyan > Assignee: Hayk Hovsepyan > > In Foreman Hostgroups and Scripts which installs Hawkular Services, from ZIP or docker image. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (WFCORE-2656) DeploymentTestCase.testFilesystemScannerRegistration fails intermittently

by Chao Wang (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2656?page=com.atlassian.jira.plugi... ] Chao Wang commented on WFCORE-2656: ----------------------------------- I have also seen this test fails today with error: {noformat} Failed tests: DeploymentTestCase.testFilesystemScannerRegistration:253->addDeploymentScanner:799->addDeploymentScanner:817 { "outcome" => "failed", "failure-description" => "WFLYCTL0436: Cannot register capability 'org.wildfly.management.deployment-scanner.dummy' at location '[ (\"subsystem\" => \"deployment-scanner\"), (\"scanner\" => \"dummy\") ]' as it is already registered in context 'global' at location(s) '[[ (\"subsystem\" => \"deployment-scanner\"), (\"scanner\" => \"dummy\") ]]'", "rolled-back" => true } expected:<[success]> but was:<[failed]> {noformat} But it fails constantly on my machine, Is this the same cause appeared on CI ? > DeploymentTestCase.testFilesystemScannerRegistration fails intermittently > ------------------------------------------------------------------------- > > Key: WFCORE-2656 > URL: https://issues.jboss.org/browse/WFCORE-2656 > Project: WildFly Core > Issue Type: Bug > Components: Deployment Scanner, Domain Management > Reporter: Brian Stansberry > Assignee: Brian Stansberry > > https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&tes... > I fear this has something to do with the capability registry and nothing to do with the scanner itself. It started happening when I added a capability to the scanner so it could consume a capability for the path it references. > The test does a quick add/remove/add of a scanner resource and it's the 2nd add that fails with a dupicate capability error. But the remove mean the dup is gone. It's intermittent so I fear some race, but there's nothing obvious. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

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