March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-8270) UndertowSslSecurityDomainTestCase - close client to avoid resource leaks

by Ondrej Kotek (JIRA)

[ https://issues.jboss.org/browse/WFLY-8270?page=com.atlassian.jira.plugin.... ] Ondrej Kotek moved JBEAP-9226 to WFLY-8270: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8270 (was: JBEAP-9226) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Test Suite (was: Test Suite) Affects Version/s: 11.0.0.Alpha1 (was: 7.1.0.DR12) > UndertowSslSecurityDomainTestCase - close client to avoid resource leaks > ------------------------------------------------------------------------ > > Key: WFLY-8270 > URL: https://issues.jboss.org/browse/WFLY-8270 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 11.0.0.Alpha1 > Reporter: Ondrej Kotek > Assignee: Ondrej Kotek > > There are 4 tests in https://github.com/wildfly/wildfly/blob/master/testsuite/elytron/src/test... and each is creating client and making the call. > But the client is never closed. > I checked https://github.com/wildfly/wildfly/blob/master/testsuite/shared/src/main/... but it doesn't close the client either. > I think it makes sense to enhance those 4 tests with {{client.close();}} lines. > Changing Utils class can cause regressions when client is used for multiple calls. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8269) Encrypt-protocol can not be used without Elytron

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-8269?page=com.atlassian.jira.plugin.... ] Paul Ferraro moved JBEAP-9225 to WFLY-8269: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8269 (was: JBEAP-9225) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Clustering (was: Clustering) Affects Version/s: (was: 7.1.0.DR12) Affects Testing: (was: Regression) > Encrypt-protocol can not be used without Elytron > ------------------------------------------------ > > Key: WFLY-8269 > URL: https://issues.jboss.org/browse/WFLY-8269 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Blocker > > When we tried to configure UDP stack in JGroups subsystem, we added ASYM_ENCRYPT protocol. According to the model definition attributes "key-store" and "key-alias" together with "credential-reference" child element had to be defined as well. Due to this configuration server failed to start with errors: > {code} > ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0362: Capabilities required by resource '/subsystem=jgroups/stack=udp/protocol=ASYM_ENCRYPT' are not available: > org.wildfly.security.key-store.server.keystore; There are no known registration points which can provide this capability. > FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. > {code} > We should still be able to define original protocol behaviour without Elytron, but it seems we can not use encrypt-protocol without keystore definition in Elytron which could be a backward compatibility issue. > Used configuration in standalone-ha.xml is attached. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2161) UNICAST3: message delivery fails after disconnect-connect sequence

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2161?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2161: -------------------------------- The test passes in JGroups 4.0.0.Beta3 > UNICAST3: message delivery fails after disconnect-connect sequence > ------------------------------------------------------------------ > > Key: JGRP-2161 > URL: https://issues.jboss.org/browse/JGRP-2161 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Critical > Fix For: 4.1, 4.0.1 > > > When disconnecting and reconnecting a channel, unicast messages are not delivered. {{ConnectTest.testDisconnectConnectndMessageSending()}} reproduces the issue. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2161) UNICAST3: message delivery fails after disconnect-connect sequence

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2161?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2161 at 3/1/17 10:07 AM: --------------------------------------------------------- The test passes in JGroups 4.0.0.Beta3, but fails in 4.0.0.CR1, so this is a regression between Beta3 and CR1. was (Author: belaban): The test passes in JGroups 4.0.0.Beta3 > UNICAST3: message delivery fails after disconnect-connect sequence > ------------------------------------------------------------------ > > Key: JGRP-2161 > URL: https://issues.jboss.org/browse/JGRP-2161 > Project: JGroups > Issue Type: Bug > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Critical > Fix For: 4.1, 4.0.1 > > > When disconnecting and reconnecting a channel, unicast messages are not delivered. {{ConnectTest.testDisconnectConnectndMessageSending()}} reproduces the issue. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JGRP-2161) UNICAST3: message delivery fails after disconnect-connect sequence

by Bela Ban (JIRA)

Bela Ban created JGRP-2161: ------------------------------ Summary: UNICAST3: message delivery fails after disconnect-connect sequence Key: JGRP-2161 URL: https://issues.jboss.org/browse/JGRP-2161 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assignee: Bela Ban Priority: Critical Fix For: 4.1, 4.0.1 When disconnecting and reconnecting a channel, unicast messages are not delivered. {{ConnectTest.testDisconnectConnectndMessageSending()}} reproduces the issue. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8268) Obtain password from external source (CMD, EXT) doesn't work on Windows.

by Hynek Švábek (JIRA)

[ https://issues.jboss.org/browse/WFLY-8268?page=com.atlassian.jira.plugin.... ] Hynek Švábek updated WFLY-8268: ------------------------------- Description: Obtain password from external source (CMD, EXT) doesn't work on Windows. Try to create new CS which obtains password from external source: {code} /subsystem=elytron/credential-store=myCredStore:add(uri="cr-store://test/myCredStore.jceks?create=true", credential-reference={clear-text="{CMD}C:\path\to\scrit\pass.bat,VerySecretPassword", type=COMMAND}, relative-to=jboss.server.config.dir) pass.bat file contains only this {code} echo %1 {code} Because of https://issues.jboss.org/browse/JBEAP-9211 you must do this extra step: Add new alias to CS -> JCEKS file is created Please try it open directly with pass "VerySecretPassword" -> *it doesn't work* on Windows. In my opinion there is problem with back slashes in script path. https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha22/controller/src... Because when I add there back slashed to path then it works. was: Obtain password from external source (CMD, EXT) doesn't work on Windows. Try to create new CS which obtains password from external source: {code} /subsystem=elytron/credential-store=myCredStore:add(uri="cr-store://test/myCredStore.jceks?create=true", credential-reference={clear-text="{CMD}C:\path\to\scrit\pass.bat,VerySecretPassword", type=COMMAND}, relative-to=jboss.server.config.dir) pass.bat file contains only this {code} echo %1 {code} Because of https://issues.jboss.org/browse/JBEAP-9211 you must do this extra step: Now you add new alias to CS -> JCEKS file is created Please try it open directly with pass "VerySecretPassword" -> *it doesn't work* on Windows. In my opinion there is problem with back slashes in script path. https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha22/controller/src... Because when I add there back slashed to path then it works. > Obtain password from external source (CMD, EXT) doesn't work on Windows. > ------------------------------------------------------------------------ > > Key: WFLY-8268 > URL: https://issues.jboss.org/browse/WFLY-8268 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Darran Lofthouse > > Obtain password from external source (CMD, EXT) doesn't work on Windows. > Try to create new CS which obtains password from external source: > {code} > /subsystem=elytron/credential-store=myCredStore:add(uri="cr-store://test/myCredStore.jceks?create=true", credential-reference={clear-text="{CMD}C:\path\to\scrit\pass.bat,VerySecretPassword", type=COMMAND}, relative-to=jboss.server.config.dir) > pass.bat file contains only this > {code} > echo %1 > {code} > Because of https://issues.jboss.org/browse/JBEAP-9211 you must do this extra step: > Add new alias to CS -> JCEKS file is created > Please try it open directly with pass "VerySecretPassword" -> *it doesn't work* on Windows. > In my opinion there is problem with back slashes in script path. > https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha22/controller/src... > Because when I add there back slashed to path then it works. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8268) Obtain password from external source (CMD, EXT) doesn't work on Windows.

by Hynek Švábek (JIRA)

Hynek Švábek created WFLY-8268: ---------------------------------- Summary: Obtain password from external source (CMD, EXT) doesn't work on Windows. Key: WFLY-8268 URL: https://issues.jboss.org/browse/WFLY-8268 Project: WildFly Issue Type: Bug Components: Security Reporter: Hynek Švábek Assignee: Darran Lofthouse Obtain password from external source (CMD, EXT) doesn't work on Windows. Try to create new CS which obtains password from external source: {code} /subsystem=elytron/credential-store=myCredStore:add(uri="cr-store://test/myCredStore.jceks?create=true", credential-reference={clear-text="{CMD}C:\path\to\scrit\pass.bat,VerySecretPassword", type=COMMAND}, relative-to=jboss.server.config.dir) pass.bat file contains only this {code} echo %1 {code} Because of https://issues.jboss.org/browse/JBEAP-9211 you must do this extra step: Now you add new alias to CS -> JCEKS file is created Please try it open directly with pass "VerySecretPassword" -> *it doesn't work* on Windows. In my opinion there is problem with back slashes in script path. https://github.com/wildfly/wildfly-core/blob/3.0.0.Alpha22/controller/src... Because when I add there back slashed to path then it works. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-32) Cassandra/Hawkular Schema Test

by Sunil kondkar (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-32?page=com.atlassian.jira.plu... ] Sunil kondkar resolved HAWKULARQE-32. ------------------------------------- Resolution: Done > Cassandra/Hawkular Schema Test > ------------------------------ > > Key: HAWKULARQE-32 > URL: https://issues.jboss.org/browse/HAWKULARQE-32 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Sunil kondkar > > Test case request from Heiko (verbatim): > Start C*,wait until up. Start metrics/h-services > and once it starts schema creation (watch the logs), kill C*. Stop > h-services. Start C* again and then h-services,it should continue Schema > creation > While I was talking about h-services here, this applies foremost to > h-metrics (which is also used inside > of h-services). > Also I think Juca had a variation of this yesterday: > deploy h-metrics + C* into Openshift and then scale h-metrics up and > down at will. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-32) Cassandra/Hawkular Schema Test

by Sunil kondkar (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-32?page=com.atlassian.jira.plu... ] Sunil kondkar commented on HAWKULARQE-32: ----------------------------------------- verified with docker start/stop cassandra and hawkular service containers manually. hawkular services continues schema creation if interrupted during initial install Test Run: https://polarion.engineering.redhat.com/polarion/#/project/JBossON4/testr... > Cassandra/Hawkular Schema Test > ------------------------------ > > Key: HAWKULARQE-32 > URL: https://issues.jboss.org/browse/HAWKULARQE-32 > Project: Hawkular QE > Issue Type: Task > Reporter: Matt Mahoney > Assignee: Sunil kondkar > > Test case request from Heiko (verbatim): > Start C*,wait until up. Start metrics/h-services > and once it starts schema creation (watch the logs), kill C*. Stop > h-services. Start C* again and then h-services,it should continue Schema > creation > While I was talking about h-services here, this applies foremost to > h-metrics (which is also used inside > of h-services). > Also I think Juca had a variation of this yesterday: > deploy h-metrics + C* into Openshift and then scale h-metrics up and > down at will. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5319) fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-5319?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-5319: ------------------------------------ Adding some more notes on this: Note 1: {quote} I noticed that [1] TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest is now failing on the CI machine but not locally for me. I saved a copy of the test output [1], so that we could look at the possible causes. 1. Reaper thread throws a IllegalMonitorStateException from org.jboss.as.ejb3.tx.OwnableReentrantLock.unlock(). I'm not sure exactly why but I'm wondering if TransactionSynchronizationRegistry.getTransactionKey() returned null to StatefulSessionSynchronizationInterceptor.getLockOwner(), which causes the current "thread" to be used in the call to OwnableReentrantLock.unlock(). This happens at "21:06:34,782" 2. An exception is thrown in the application thread and the EJB container ends the transaction ("javax.ejb.EJBTransactionRolledbackException: Transaction rolled back" is thrown since the transaction is already rolled back). 3. Application thread fails unit test with "entity manager should not of been closed by the reaper thread" error. From the log, the entity manager is closed from the reaper thread at "21:06:34,782". The unit test failure is reported from the application thread at "21:06:34,800". The test failure is clearly caused by (3) but that might reflect that the application thread was first disassociated from the active transaction and then the reaper thread ran the JPA container afterCompletion() synchronization callback (which is now legal but not expected IMO). {quote} Note 2, which refers back to note 1: {quote} I looked a little closer at (2) and the exception call stack points to the code at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:98) which is: else if (txStatus == Status.STATUS_ROLLEDBACK) { tm.rollback(); throw EjbLogger.ROOT_LOGGER.transactionAlreadyRolledBack(tx); } I don't really have any questions about (2), that is how the EJB container informs the application of the failure. For (1), I am curious if TransactionSynchronizationRegistry.getTransactionKey() can be expected to return null when the reaper thread calls the afterCompletion sync callback? For (3), it seems likely that the application thread was first disassociated from the transaction and then the JPA afterCompletion was invoked, which (properly) closed the container managed entity manager. If this is what happened, then TxTimeoutTestCase needs to check for different conditions to detect (potential) concurrency failure. {quote} > fix org.jboss.as.test.integration.jpa.mockprovider.txtimeout.TxTimeoutTestCase.test_negativeTxTimeoutVerifyReaperThreadCanceledTxTest failure > --------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-5319 > URL: https://issues.jboss.org/browse/WFLY-5319 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > > https://gist.github.com/scottmarlow/6409290362f35f2d1320 contains the error exception -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 1 month

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