April 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-1044) CS tool has to support bulk conversion of vaults to credential stores.

by Hynek Švábek (JIRA)

[ https://issues.jboss.org/browse/ELY-1044?page=com.atlassian.jira.plugin.s... ] Hynek Švábek updated ELY-1044: ------------------------------ Component/s: Credential Store (was: Command-Line Tool) > CS tool has to support bulk conversion of vaults to credential stores. > ---------------------------------------------------------------------- > > Key: ELY-1044 > URL: https://issues.jboss.org/browse/ELY-1044 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Reporter: Hynek Švábek > Assignee: Darran Lofthouse > Priority: Blocker > > CS tool has to support bulk conversion of vaults to credential stores. > It is requirement for RFE https://issues.jboss.org/browse/EAP7-539 and it is reason for BLOCKER priority. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1043) CS tool must perform conversion from vault 2.0 format to CredentialStore/KeystorePasswordStore

by Hynek Švábek (JIRA)

[ https://issues.jboss.org/browse/ELY-1043?page=com.atlassian.jira.plugin.s... ] Hynek Švábek updated ELY-1043: ------------------------------ Component/s: Credential Store (was: Command-Line Tool) > CS tool must perform conversion from vault 2.0 format to CredentialStore/KeystorePasswordStore > ---------------------------------------------------------------------------------------------- > > Key: ELY-1043 > URL: https://issues.jboss.org/browse/ELY-1043 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Reporter: Hynek Švábek > Assignee: Darran Lofthouse > Priority: Blocker > > CS tool must perform conversion from vault 2.0 format to CredentialStore/KeystorePasswordStore. > It is requirement for RFE https://issues.jboss.org/browse/EAP7-539 and it is reason for BLOCKER priority. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2619) Unclear model description of core-pool-size attribute in IO subsystem

by Romain Pelisse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2619?page=com.atlassian.jira.plugi... ] Romain Pelisse updated WFCORE-2619: ----------------------------------- Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2311 (was: https://github.com/wildfly/wildfly-core/pull/2306) > Unclear model description of core-pool-size attribute in IO subsystem > --------------------------------------------------------------------- > > Key: WFCORE-2619 > URL: https://issues.jboss.org/browse/WFCORE-2619 > Project: WildFly Core > Issue Type: Bug > Components: IO > Affects Versions: 3.0.0.Beta12 > Reporter: Romain Pelisse > Assignee: Romain Pelisse > Priority: Minor > Original Estimate: 1 week > Remaining Estimate: 1 week > > */subsystem=io/worker=*:read-attribute(name=core-pool-size)* > Current model description: "Core worker thread pool size" > Suggested improvement: "Minimum number of threads to keep in the underlying java.util.concurrent.ThreadPoolExecutor even if they are idle. Threads over this limit will be terminated over time specified by task-keepalive attribute." -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2619) Unclear model description of core-pool-size attribute in IO subsystem

by Romain Pelisse (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2619?page=com.atlassian.jira.plugi... ] Romain Pelisse moved WFLY-8496 to WFCORE-2619: ---------------------------------------------- Project: WildFly Core (was: WildFly) Key: WFCORE-2619 (was: WFLY-8496) Component/s: IO (was: IO) Affects Version/s: 3.0.0.Beta12 (was: 11.0.0.Alpha1) > Unclear model description of core-pool-size attribute in IO subsystem > --------------------------------------------------------------------- > > Key: WFCORE-2619 > URL: https://issues.jboss.org/browse/WFCORE-2619 > Project: WildFly Core > Issue Type: Bug > Components: IO > Affects Versions: 3.0.0.Beta12 > Reporter: Romain Pelisse > Assignee: Romain Pelisse > Priority: Minor > Original Estimate: 1 week > Remaining Estimate: 1 week > > */subsystem=io/worker=*:read-attribute(name=core-pool-size)* > Current model description: "Core worker thread pool size" > Suggested improvement: "Minimum number of threads to keep in the underlying java.util.concurrent.ThreadPoolExecutor even if they are idle. Threads over this limit will be terminated over time specified by task-keepalive attribute." -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2618) CS tool, Without --location parameter a credential store storage file isn't saved (or save as is expected).

by Hynek Švábek (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2618?page=com.atlassian.jira.plugi... ] Hynek Švábek commented on WFCORE-2618: -------------------------------------- [~ivassile] Wildfly-elytron-tool is located in wildfly-elytron project -> ELY project is right for this issue. > CS tool, Without --location parameter a credential store storage file isn't saved (or save as is expected). > ----------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2618 > URL: https://issues.jboss.org/browse/WFCORE-2618 > Project: WildFly Core > Issue Type: Bug > Affects Versions: 3.0.0.Beta11 > Reporter: Hynek Švábek > Assignee: Ilia Vassilev > > Without --location parameter a credential store storage file isn't saved (or save as is expected). > It pass but I am not able find credential store storage file on disk. > {code} > [hsvabek@localhost bin]$ java -jar wildfly-elytron-tool.jar credential-store --add myalias --secret supersecretpassword --uri "cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS" --password mycspassword --summary > Alias "myalias" has been successfully stored > Credential store command summary: > -------------------------------------- > /subsystem=elytron/credential-store=test:add(uri="cr-store://test.store?modifiable=true;create=true;keyStoreType=JCEKS",relative-to=jboss.server.data.dir,credential-reference={clear-text="mycspassword"}) > {code} > It pass with this URI value and I am able to find credential store storage file on disk. > {code} > uri="cr-store://credentialstorename/test.store?modifiable=true;create=true;keyStoreType=JCEKS" > {code} > I see problem here https://github.com/wildfly-security/wildfly-elytron-tool/blob/1.0.0.Alpha... > (test.store is interpreded as hostname in URI in first case) > *NOTE* > Please keep in mind this issue https://issues.jboss.org/browse/JBEAP-8450. > Behaviour must be consistent! -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1053) Review realm attribute in Elytron authentication-configuration

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-1053?page=com.atlassian.jira.plugin.s... ] Ondrej Lukas updated ELY-1053: ------------------------------ Affects Version/s: 1.1.0.Beta31-SP1 > Review realm attribute in Elytron authentication-configuration > -------------------------------------------------------------- > > Key: ELY-1053 > URL: https://issues.jboss.org/browse/ELY-1053 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta31-SP1 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > > Is there any real scenario for usage of {{realm}} attribute in authentication-configuration? > If server provides DIGEST-MD5 mechanism and client chooses it, then server provides name of realm which should be used for creating {{user:realm:password}} digest. It was the original reason which was provided to us. However it seems that reason for that attribute is currently different. What is the reason for attribute {{realm}} in authentication-configuration? > This information will be also needed for documentation. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-1053) Review realm attribute in Elytron authentication-configuration

by Ondrej Lukas (JIRA)

Ondrej Lukas created ELY-1053: --------------------------------- Summary: Review realm attribute in Elytron authentication-configuration Key: ELY-1053 URL: https://issues.jboss.org/browse/ELY-1053 Project: WildFly Elytron Issue Type: Bug Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical Is there any real scenario for usage of {{realm}} attribute in authentication-configuration? If server provides DIGEST-MD5 mechanism and client chooses it, then server provides name of realm which should be used for creating {{user:realm:password}} digest. It was the original reason which was provided to us. However it seems that reason for that attribute is currently different. What is the reason for attribute {{realm}} in authentication-configuration? This information will be also needed for documentation. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

[JBoss JIRA] (HAWKULARQE-81) Baseline #3

by viet nguyen (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-81?page=com.atlassian.jira.plu... ] viet nguyen updated HAWKULARQE-81: ---------------------------------- Description: * Run pyme on master to eliminate vpn slowness * Fix query start-end window * Update pyme endpoint to increase metrics to 30 (currently 2) * insert metrics tallies into a separate Hawkular Metrics instance and use Grafana as a visual tool was: * Run pyme on master to eliminate vpn slowness * Fix query start-end window * Update pyme endpoint to increase metrics to 30 (currently 2) * insert metrics tallies into a separate Hawkular Metrics instance and user Grafana as a visual tool > Baseline #3 > ----------- > > Key: HAWKULARQE-81 > URL: https://issues.jboss.org/browse/HAWKULARQE-81 > Project: Hawkular QE > Issue Type: Sub-task > Reporter: viet nguyen > Assignee: viet nguyen > Attachments: March28_0200_raw.zip > > > * Run pyme on master to eliminate vpn slowness > * Fix query start-end window > * Update pyme endpoint to increase metrics to 30 (currently 2) > * insert metrics tallies into a separate Hawkular Metrics instance and use Grafana as a visual tool -- This message was sent by Atlassian JIRA (v7.2.3#72005)

7 years, 6 months

1
0
0 / 0

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

by Flavia Rainone (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1344?page=com.atlassian.jira.plugin... ] Flavia Rainone commented on JBJCA-1344: --------------------------------------- As a side note,, I used the IronJacamar tracer, as [~maeste] adivsed, to track this bug, and I ended up finding a problem in the trace result, there are some unexpected clearConnectionListener invocations flagged as Red. I'm investigating what is causing that trace result, if this is a known issue, please let me know. > 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)

7 years, 6 months

1
0
0 / 0

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

by Flavia Rainone (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1344?page=com.atlassian.jira.plugin... ] Flavia Rainone commented on JBJCA-1344: --------------------------------------- [~simkam] Yes, the analysis is correct, that concurrent behavior is causing the 1 destroyed statistics. What I need to check with you and [~maeste] is: is this behavior unexpected? Synchronizing both threads would just result in loss of performance and defeat the purpose of the entire synchronization algorithm in the MCP, so I see that as a no no. The other possibility for fixing the statistics is just not adding to the destroyed statistics count when the connection is destroyed in the given scenario. But is the statistics supposed to hide that info, given that the statistics will show that there was an extra connection created (at https://github.com/ironjacamar/ironjacamar/blob/1.4/core/src/main/java/or... and at https://github.com/ironjacamar/ironjacamar/blob/1.4/core/src/main/java/or...). I'm afraid that omitting the destroyed connection from the statistics will just leave it inconsistent. And, if to make it consistent will also mean not incrementing the created connection statistics, it will still be inconsistent with the fact that there was an actual connection created. > 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)

7 years, 6 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 April 2017