April 2017 - jboss-jira - Jboss List Archives

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

8 years, 7 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)

8 years, 7 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)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8504) EJB over HTTP sesion id does not include the JVM route

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-8504?page=com.atlassian.jira.plugin.... ] Stuart Douglas moved JBEAP-10109 to WFLY-8504: ---------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8504 (was: JBEAP-10109) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: EJB Web (Undertow) (was: EJB) (was: Web (Undertow)) > EJB over HTTP sesion id does not include the JVM route > ------------------------------------------------------ > > Key: WFLY-8504 > URL: https://issues.jboss.org/browse/WFLY-8504 > Project: WildFly > Issue Type: Bug > Components: EJB, Web (Undertow) > Reporter: Stuart Douglas > Assignee: Stuart Douglas > > This means affinity will not be correctly established -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8503) Wildfly HTTP Client 1.0.0.CR1

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-8503?page=com.atlassian.jira.plugin.... ] Stuart Douglas reassigned WFLY-8503: ------------------------------------ Assignee: Stuart Douglas > Wildfly HTTP Client 1.0.0.CR1 > ----------------------------- > > Key: WFLY-8503 > URL: https://issues.jboss.org/browse/WFLY-8503 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Stuart Douglas > Assignee: Stuart Douglas > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8503) Wildfly HTTP Client 1.0.0.CR1

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-8503?page=com.atlassian.jira.plugin.... ] Stuart Douglas moved JBEAP-10107 to WFLY-8503: ---------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-8503 (was: JBEAP-10107) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Target Release: (was: 7.1.0.GA) > Wildfly HTTP Client 1.0.0.CR1 > ----------------------------- > > Key: WFLY-8503 > URL: https://issues.jboss.org/browse/WFLY-8503 > Project: WildFly > Issue Type: Component Upgrade > Reporter: Stuart Douglas > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8502) Upgrade transaction client to 1.0.0.Beta20 from 1.0.0.Beta19

by David Lloyd (JIRA)

David Lloyd created WFLY-8502: --------------------------------- Summary: Upgrade transaction client to 1.0.0.Beta20 from 1.0.0.Beta19 Key: WFLY-8502 URL: https://issues.jboss.org/browse/WFLY-8502 Project: WildFly Issue Type: Component Upgrade Components: EJB Reporter: David Lloyd Assignee: David Lloyd -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8501) Upgrade ejb client to 4.0.0.Beta23 from 4.0.0.Beta22

by David Lloyd (JIRA)

David Lloyd created WFLY-8501: --------------------------------- Summary: Upgrade ejb client to 4.0.0.Beta23 from 4.0.0.Beta22 Key: WFLY-8501 URL: https://issues.jboss.org/browse/WFLY-8501 Project: WildFly Issue Type: Component Upgrade Components: EJB Reporter: David Lloyd Assignee: David Lloyd -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1508) Prevent NPE when compiler fails to resolve a typeref

by Edson Tirelli (JIRA)

Edson Tirelli created DROOLS-1508: ------------------------------------- Summary: Prevent NPE when compiler fails to resolve a typeref Key: DROOLS-1508 URL: https://issues.jboss.org/browse/DROOLS-1508 Project: Drools Issue Type: Bug Components: dmn engine Affects Versions: 7.0.0.Beta8 Reporter: Edson Tirelli Assignee: Edson Tirelli Priority: Critical Fix For: 7.0.0.Final The compiler is raising a NPE when it fails to resolve a typeref. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 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 Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2618?page=com.atlassian.jira.plugi... ] Ilia Vassilev updated WFCORE-2618: ---------------------------------- Affects Version/s: 3.0.0.Beta11 > 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)

8 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2017