[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
[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
[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
[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
[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
[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
[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