Bug 1277919

Summary: [QE](6.4.z) Peculiar behavior of data source pool statistics
Product: [JBoss] JBoss Enterprise Application Platform 6 Reporter: Jan Martiska <jmartisk>
Component: JCAAssignee: Jesper Pedersen <jpederse>
Status: CLOSED CURRENTRELEASE QA Contact: Jan Martiska <jmartisk>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 6.4.5CC: bmaxwell, cdewolf, jolee, jpederse, remerson, vtunka
Target Milestone: CR2Keywords: Regression
Target Release: EAP 6.4.5   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-01-17 11:40:29 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1235745, 1278301    

Description Jan Martiska 2015-11-04 10:52:46 UTC
I noticed a peculiar behavior of data source statistics. This happens in 6.4.5.CR1, but it works correctly in 6.4.4.

1. an application (or a user using CLI) obtains a connection (or multiple connections) from a data source and then closes it
2. statistics get enabled for the data source, eg. /subsystem=datasources/data-source=ExampleDS/statistics=pool:write-attribute(name=statistics-enabled,value=true)
3. a flush-all-connections-in-pool is made for the data source
4. read the data source statistics - the previously active connections from step 1 (before the statistics get enabled/reset) are SUBTRACTED from the ActiveCount statistic (during the flush), so the ActiveCount is now a negative number

How to reproduce manually using CLI:

[standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS:test-connection-in-pool
{
    "outcome" => "success",
    "result" => [true]
}
[standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS/statistics=pool:write-attribute(name=statistics-enabled,value=true)
{"outcome" => "success"}
[standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS:flush-all-connection-in-pool
{"outcome" => "success"}
[standalone@localhost:9999 /] /subsystem=datasources/data-source=ExampleDS/statistics=pool:read-resource(include-runtime=true)
{
    "outcome" => "success",
    "result" => {
        "ActiveCount" => "-1",
        "AvailableCount" => "20",
        "AverageBlockingTime" => "0",
        "AverageCreationTime" => "0",
        "CreatedCount" => "0",
        "DestroyedCount" => "1",
        "InUseCount" => "0",
        "MaxCreationTime" => "0",
        "MaxUsedCount" => "0",
        "MaxWaitCount" => "0",
        "MaxWaitTime" => "0",
        "TimedOut" => "0",
        "TotalBlockingTime" => "0",
        "TotalCreationTime" => "0",
        "statistics-enabled" => true
    }
}

Comment 4 Jesper Pedersen 2015-11-04 13:00:49 UTC
It is not a regression, that commit just exposes the issue

Comment 6 Enrique Gonzalez Martinez 2015-11-05 07:55:08 UTC
commit 6.4.z - 1.0.x branch
https://github.com/ironjacamar/ironjacamar/commit/1511519f23450e06dd84faaf512ebe37416a8ad4

Comment 7 Jan Martiska 2015-11-12 10:54:17 UTC
Verified with EAP 6.4.5.CR2.

Comment 8 Petr Penicka 2017-01-17 11:40:29 UTC
Retroactively bulk-closing issues from released EAP 6.4 cumulative patches.

Comment 9 Petr Penicka 2017-01-17 11:42:19 UTC
Retroactively bulk-closing issues from released EAP 6.4 cumulative patches.