[jira] [Updated] (GEODE-9768) Start gateway sender with clean queues hangs
[ https://issues.apache.org/jira/browse/GEODE-9768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-9768: - Labels: needsTriage (was: ) > Start gateway sender with clean queues hangs > > > Key: GEODE-9768 > URL: https://issues.apache.org/jira/browse/GEODE-9768 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.15.0 >Reporter: Mario Ivanac >Priority: Major > Labels: needsTriage > > In case we are starting consecutive gw senders with clean queue, 2nd gw > sender hangs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9768) Start gateway sender with clean queues hangs
Mario Ivanac created GEODE-9768: --- Summary: Start gateway sender with clean queues hangs Key: GEODE-9768 URL: https://issues.apache.org/jira/browse/GEODE-9768 Project: Geode Issue Type: Bug Components: wan Affects Versions: 1.15.0 Reporter: Mario Ivanac In case we are starting consecutive gw senders with clean queue, 2nd gw sender hangs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9768) Start gateway sender with clean queues hangs
[ https://issues.apache.org/jira/browse/GEODE-9768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac reassigned GEODE-9768: --- Assignee: Mario Ivanac > Start gateway sender with clean queues hangs > > > Key: GEODE-9768 > URL: https://issues.apache.org/jira/browse/GEODE-9768 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.15.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: needsTriage > > In case we are starting consecutive gw senders with clean queue, 2nd gw > sender hangs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9768) Consecutive start gateway sender with clean queues hangs
[ https://issues.apache.org/jira/browse/GEODE-9768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Ivanac updated GEODE-9768: Summary: Consecutive start gateway sender with clean queues hangs (was: Start gateway sender with clean queues hangs) > Consecutive start gateway sender with clean queues hangs > > > Key: GEODE-9768 > URL: https://issues.apache.org/jira/browse/GEODE-9768 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.15.0 >Reporter: Mario Ivanac >Assignee: Mario Ivanac >Priority: Major > Labels: needsTriage > > In case we are starting consecutive gw senders with clean queue, 2nd gw > sender hangs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9760) Partition Regions Gets Statistic Broken
[
https://issues.apache.org/jira/browse/GEODE-9760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols resolved GEODE-9760.
-
Fix Version/s: 1.15.0
Resolution: Fixed
resolved by revert of GEODE-8876
> Partition Regions Gets Statistic Broken
> ---
>
> Key: GEODE-9760
> URL: https://issues.apache.org/jira/browse/GEODE-9760
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Priority: Major
> Labels: needsTriage
> Fix For: 1.15.0
>
> Attachments: workspace.zip
>
>
> The issue was introduced by
> [GEODE-8876|https://issues.apache.org/jira/browse/GEODE-8876]. After commit
> [5dde7d765c252ef20cfb16981b18e68903e32165|https://github.com/apache/geode/commit/5dde7d765c252ef20cfb16981b18e68903e32165],
> the {{CachePerfStats.gets}} statistic for {{PartitionRegion}} remains empty,
> even though {{get}} operations are executed on the region.
> I'm attaching a small scenario that reproduces the problem every single time
> when using any commit after the mentioned one.
> The {{reproduce.sh}} script:
> # Builds a small java client that creates 1 entries into the configured
> region, and launches 5 threads to continuously execute the {{Region.get()}}
> operation for 60 seconds.
> # Starts a cluster with 1 locator and 3 servers.
> # Creates a partition region.
> # Launches the client application and waits for it to complete.
> # Prints the amount of gets operations/sec for the relevant region (VSD can
> be used here to inspect the values instead, the result is exactly the same).
> ---
> How to reproduce the problem:
> # Download the attached tar file.
> # Uncompress the file and update the {{GEMFIRE}} variable to use your local
> build of the latest Geode from {{develop}}.
> # Execute the {{reproduce.sh}} script and wait for it to finish.
> Once the execution is done, the output will show the following:
> {noformat}
> server-0.gfs:
> gets operations/sec: samples=74 min=0 max=0 average=0 stddev=0 last=0
> server-1.gfs:
> gets operations/sec: samples=74 min=0 max=0 average=0 stddev=0 last=0
> server-2.gfs:
> gets operations/sec: samples=75 min=0 max=0 average=0 stddev=0 last=0
> {noformat}
> The above is clearly wrong, as the {{client}} application continuously
> executed the {{Region.get()}} operation using 5 threads for 60 seconds.
> If you execute a reverse apply of commit
> [5dde7d765c252ef20cfb16981b18e68903e32165|https://github.com/apache/geode/commit/5dde7d765c252ef20cfb16981b18e68903e32165]
> to undo the changes (use {{git show 5dde7d765c252ef20cfb16981b18e68903e32165
> | git apply -R}}), re-build {{geode}} and execute the tests again the output,
> instead, will show the correct values:
> {noformat}
> server-0.gfs:
> gets operations/sec: samples=75 min=0 max=22500.5 average=15252.61
> stddev=7747.94 last=0
> server-1.gfs:
> gets operations/sec: samples=75 min=0 max=22487.54 average=15241.54
> stddev=7705.99 last=0
> server-2.gfs:
> gets operations/sec: samples=75 min=0 max=22194.61 average=15459.16
> stddev=7751.5 last=0
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8876) Statistics not collecting correct value for gets when transaction is used
[
https://issues.apache.org/jira/browse/GEODE-8876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433581#comment-17433581
]
ASF subversion and git services commented on GEODE-8876:
Commit 17a67bc6397890f10696410fcb6a1798031fcf6c in geode's branch
refs/heads/develop from Jakov Varenina
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=17a67bc ]
Revert "GEODE-8876: Statistics not collecting correct value for gets when tra…
(#6199)" (#7027)
This reverts commit 5dde7d765c252ef20cfb16981b18e68903e32165 that caused
GEODE-9760
> Statistics not collecting correct value for gets when transaction is used
> -
>
> Key: GEODE-8876
> URL: https://issues.apache.org/jira/browse/GEODE-8876
> Project: Geode
> Issue Type: Bug
> Components: statistics, transactions
>Reporter: Mario Kevo
>Assignee: Jakov Varenina
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> {color:#172b4d}We were running traffic with reads and updates using
> transactions. After traffic finished we collected statistic file from the
> server pods.{color}
> {color:#172b4d}After opening stats file we got the following:{color}
> * {color:#172b4d}In the CacheSeverStats statistics, counters for getRequest
> and putRequest are showing correct number of get and put operations requested
> by client.{color}
> * {color:#172b4d}In the *CachePerfStats*, graph for puts during traffic time
> is showing expected number of put operation, but the graph for *gets* was
> *empty* in that period!{color}
> {color:#172b4d}We tried to check the same statistics for traffic generated
> without using transactions and statistic for gets was showing correct number
> of operations.{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9760) Partition Regions Gets Statistic Broken
[
https://issues.apache.org/jira/browse/GEODE-9760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433582#comment-17433582
]
ASF subversion and git services commented on GEODE-9760:
Commit 17a67bc6397890f10696410fcb6a1798031fcf6c in geode's branch
refs/heads/develop from Jakov Varenina
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=17a67bc ]
Revert "GEODE-8876: Statistics not collecting correct value for gets when tra…
(#6199)" (#7027)
This reverts commit 5dde7d765c252ef20cfb16981b18e68903e32165 that caused
GEODE-9760
> Partition Regions Gets Statistic Broken
> ---
>
> Key: GEODE-9760
> URL: https://issues.apache.org/jira/browse/GEODE-9760
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Priority: Major
> Labels: needsTriage
> Fix For: 1.15.0
>
> Attachments: workspace.zip
>
>
> The issue was introduced by
> [GEODE-8876|https://issues.apache.org/jira/browse/GEODE-8876]. After commit
> [5dde7d765c252ef20cfb16981b18e68903e32165|https://github.com/apache/geode/commit/5dde7d765c252ef20cfb16981b18e68903e32165],
> the {{CachePerfStats.gets}} statistic for {{PartitionRegion}} remains empty,
> even though {{get}} operations are executed on the region.
> I'm attaching a small scenario that reproduces the problem every single time
> when using any commit after the mentioned one.
> The {{reproduce.sh}} script:
> # Builds a small java client that creates 1 entries into the configured
> region, and launches 5 threads to continuously execute the {{Region.get()}}
> operation for 60 seconds.
> # Starts a cluster with 1 locator and 3 servers.
> # Creates a partition region.
> # Launches the client application and waits for it to complete.
> # Prints the amount of gets operations/sec for the relevant region (VSD can
> be used here to inspect the values instead, the result is exactly the same).
> ---
> How to reproduce the problem:
> # Download the attached tar file.
> # Uncompress the file and update the {{GEMFIRE}} variable to use your local
> build of the latest Geode from {{develop}}.
> # Execute the {{reproduce.sh}} script and wait for it to finish.
> Once the execution is done, the output will show the following:
> {noformat}
> server-0.gfs:
> gets operations/sec: samples=74 min=0 max=0 average=0 stddev=0 last=0
> server-1.gfs:
> gets operations/sec: samples=74 min=0 max=0 average=0 stddev=0 last=0
> server-2.gfs:
> gets operations/sec: samples=75 min=0 max=0 average=0 stddev=0 last=0
> {noformat}
> The above is clearly wrong, as the {{client}} application continuously
> executed the {{Region.get()}} operation using 5 threads for 60 seconds.
> If you execute a reverse apply of commit
> [5dde7d765c252ef20cfb16981b18e68903e32165|https://github.com/apache/geode/commit/5dde7d765c252ef20cfb16981b18e68903e32165]
> to undo the changes (use {{git show 5dde7d765c252ef20cfb16981b18e68903e32165
> | git apply -R}}), re-build {{geode}} and execute the tests again the output,
> instead, will show the correct values:
> {noformat}
> server-0.gfs:
> gets operations/sec: samples=75 min=0 max=22500.5 average=15252.61
> stddev=7747.94 last=0
> server-1.gfs:
> gets operations/sec: samples=75 min=0 max=22487.54 average=15241.54
> stddev=7705.99 last=0
> server-2.gfs:
> gets operations/sec: samples=75 min=0 max=22194.61 average=15459.16
> stddev=7751.5 last=0
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (GEODE-8876) Statistics not collecting correct value for gets when transaction is used
[
https://issues.apache.org/jira/browse/GEODE-8876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols reopened GEODE-8876:
-
reopening since the initial fix was reverted due to causing GEODE-9760
> Statistics not collecting correct value for gets when transaction is used
> -
>
> Key: GEODE-8876
> URL: https://issues.apache.org/jira/browse/GEODE-8876
> Project: Geode
> Issue Type: Bug
> Components: statistics, transactions
>Reporter: Mario Kevo
>Assignee: Jakov Varenina
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> {color:#172b4d}We were running traffic with reads and updates using
> transactions. After traffic finished we collected statistic file from the
> server pods.{color}
> {color:#172b4d}After opening stats file we got the following:{color}
> * {color:#172b4d}In the CacheSeverStats statistics, counters for getRequest
> and putRequest are showing correct number of get and put operations requested
> by client.{color}
> * {color:#172b4d}In the *CachePerfStats*, graph for puts during traffic time
> is showing expected number of put operation, but the graph for *gets* was
> *empty* in that period!{color}
> {color:#172b4d}We tried to check the same statistics for traffic generated
> without using transactions and statistic for gets was showing correct number
> of operations.{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
