[jira] [Commented] (GEODE-8259) when client singlehop getAll encountered SerializationException, it should retry
[ https://issues.apache.org/jira/browse/GEODE-8259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149124#comment-17149124 ] ASF subversion and git services commented on GEODE-8259: Commit 16f2093fa59b9f0f3b7600cc365d922d78d6e8dd in geode's branch refs/heads/support/1.12 from Xiaojian Zhou [ https://gitbox.apache.org/repos/asf?p=geode.git;h=16f2093 ] GEODE-8259: when client singlehop getAll encountered SerializationException, it should retry (#5253) Co-authored-by: Xiaojian Zhou Co-authored-by: Anil (cherry picked from commit ee9a4b05277ff531d0d89d5d0fb65f63063557e3) > when client singlehop getAll encountered SerializationException, it should > retry > > > Key: GEODE-8259 > URL: https://issues.apache.org/jira/browse/GEODE-8259 > Project: Geode > Issue Type: Improvement >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Fix For: 1.14.0 > > > In GEOEDE-7090, DSFIDSerializerImpl.invokeFromData() will catch > RunTimeException and throw. But convert Exception to be IOException. The idea > is to avoid using SerializationException which is in another package. > However, if my fromData() failed with IndexOutOfBoundary exception (which is > an RTE), it will be thrown directly instead of treating it in > handleException(), thus my serialization exception will never get handled. > The fix is to merge the catch RunTimeException into catch Exception. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8323) Need to correctly process QueueRemovalMessage during HARegionQueue initialization
[ https://issues.apache.org/jira/browse/GEODE-8323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149075#comment-17149075 ] ASF GitHub Bot commented on GEODE-8323: --- pivotal-eshu opened a new pull request #5333: URL: https://github.com/apache/geode/pull/5333 Thank you for submitting a contribution to Apache Geode. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Has your PR been rebased against the latest commit within the target branch (typically `develop`)? - [ ] Is your initial contribution a single, squashed commit? - [ ] Does `gradlew build` run cleanly? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? ### Note: Please ensure that once the PR is submitted, check Concourse for build issues and submit an update to your PR as soon as possible. If you need help, please send an email to d...@geode.apache.org. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Need to correctly process QueueRemovalMessage during HARegionQueue > initialization > - > > Key: GEODE-8323 > URL: https://issues.apache.org/jira/browse/GEODE-8323 > Project: Geode > Issue Type: Bug > Components: client queues >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: caching-applications > > Currently, these events in queue removal message are ignored as the idea is > that correct setting of messageTimeToLive and > subscriptionMessageTrackingTimeout should prevent a previous seen event > replayed on a client. > However, it failover scenario occurs, a restarted/newly joined member could > gii from a secondary HARegionQueue which has those events not removed by the > QRM. As the restarted member starts the timer for messageTimeToLive after it > restarted. The event could live longer than the messageTimeToLive setting if > starts from the original operation time. If this time is longer than the > subscriptionMessageTrackingTimeout setting on the client, the client will not > prevent the replay of the stray event. This could leads to data inconsistency > between client and server. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8216) SerialWANPersistenceEnabledGatewaySenderOffHeapDUnitTest.testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived FAILED
[
https://issues.apache.org/jira/browse/GEODE-8216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-8216:
Fix Version/s: (was: 1.14.0)
> SerialWANPersistenceEnabledGatewaySenderOffHeapDUnitTest.testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
> FAILED
>
>
> Key: GEODE-8216
> URL: https://issues.apache.org/jira/browse/GEODE-8216
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Mark Hanson
>Assignee: Mario Ivanac
>Priority: Major
> Labels: ci
> Attachments: geode-8216-logs.tgz
>
>
> Test failure
> {noformat}
> org.apache.geode.internal.cache.wan.offheap.SerialWANPersistenceEnabledGatewaySenderOffHeapDUnitTest
> >
> testReplicatedRegionPersistentWanGateway_restartSenderWithCleanQueues_expectNoEventsReceived
> FAILED
> 11:25:56org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.serial.SerialWANPersistenceEnabledGatewaySenderDUnitTest$$Lambda$182/1489068907.run
> in VM 2 running on Host 40c25330a7e0 with 8 VMs
> 11:25:56
> 11:25:56Caused by:
> 11:25:56org.awaitility.core.ConditionTimeoutException: Assertion
> condition defined as a lambda expression in
> org.apache.geode.internal.cache.wan.WANTestBase that uses int,
> intorg.apache.geode.cache.Region Expected region entries: 0 but actual
> entries: 10 present region keyset [6, 5, 7, 0, 8, 9, 2, 1, 3, 4] expected:<0>
> but was:<10> within 5 minutes.
> 11:25:56
> 11:25:56Caused by:
> 11:25:56java.lang.AssertionError: Expected region entries: 0 but
> actual entries: 10 present region keyset [6, 5, 7, 0, 8, 9, 2, 1, 3, 4]
> expected:<0> but was:<10>
> 11:33:48 {noformat}
>
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/229]
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0098/test-results/distributedTest/1591126795/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0098/test-artifacts/1591126795/distributedtestfiles-OpenJDK8-1.14.0-build.0098.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8284) Break up StringsIntegration test class
[ https://issues.apache.org/jira/browse/GEODE-8284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8284: Fix Version/s: 1.14.0 > Break up StringsIntegration test class > -- > > Key: GEODE-8284 > URL: https://issues.apache.org/jira/browse/GEODE-8284 > Project: Geode > Issue Type: Improvement > Components: redis, tests >Reporter: Sarah Abbey >Priority: Major > Fix For: 1.14.0 > > > Break up StringsIntegration test class into relevant files for each Strings > executor -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8269) Improve test coverage
[ https://issues.apache.org/jira/browse/GEODE-8269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8269: Fix Version/s: 1.14.0 > Improve test coverage > - > > Key: GEODE-8269 > URL: https://issues.apache.org/jira/browse/GEODE-8269 > Project: Geode > Issue Type: Test > Components: redis, tests >Reporter: Sarah Abbey >Priority: Major > Fix For: 1.14.0 > > > Analyzed test coverage via Intellij and by looking through all tests. There > were some test cases missing, we added some. Others will be added later. > Jiras coming soon. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8303) refactor Redis (String)SetExecutor
[ https://issues.apache.org/jira/browse/GEODE-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8303: Fix Version/s: 1.14.0 > refactor Redis (String)SetExecutor > -- > > Key: GEODE-8303 > URL: https://issues.apache.org/jira/browse/GEODE-8303 > Project: Geode > Issue Type: Improvement >Reporter: John Hutchison >Priority: Major > Fix For: 1.14.0 > > > break up single loop and corresponding switch statement into methods with > intention of grouping together business logic associated with different > optional parameters -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8259) when client singlehop getAll encountered SerializationException, it should retry
[ https://issues.apache.org/jira/browse/GEODE-8259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou resolved GEODE-8259. -- Fix Version/s: 1.14.0 Resolution: Fixed > when client singlehop getAll encountered SerializationException, it should > retry > > > Key: GEODE-8259 > URL: https://issues.apache.org/jira/browse/GEODE-8259 > Project: Geode > Issue Type: Improvement >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Fix For: 1.14.0 > > > In GEOEDE-7090, DSFIDSerializerImpl.invokeFromData() will catch > RunTimeException and throw. But convert Exception to be IOException. The idea > is to avoid using SerializationException which is in another package. > However, if my fromData() failed with IndexOutOfBoundary exception (which is > an RTE), it will be thrown directly instead of treating it in > handleException(), thus my serialization exception will never get handled. > The fix is to merge the catch RunTimeException into catch Exception. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8259) when client singlehop getAll encountered SerializationException, it should retry
[ https://issues.apache.org/jira/browse/GEODE-8259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148978#comment-17148978 ] ASF subversion and git services commented on GEODE-8259: Commit ee9a4b05277ff531d0d89d5d0fb65f63063557e3 in geode's branch refs/heads/develop from Xiaojian Zhou [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ee9a4b0 ] GEODE-8259: when client singlehop getAll encountered SerializationException, it should retry (#5253) Co-authored-by: Xiaojian Zhou Co-authored-by: Anil > when client singlehop getAll encountered SerializationException, it should > retry > > > Key: GEODE-8259 > URL: https://issues.apache.org/jira/browse/GEODE-8259 > Project: Geode > Issue Type: Improvement >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > Fix For: 1.14.0 > > > In GEOEDE-7090, DSFIDSerializerImpl.invokeFromData() will catch > RunTimeException and throw. But convert Exception to be IOException. The idea > is to avoid using SerializationException which is in another package. > However, if my fromData() failed with IndexOutOfBoundary exception (which is > an RTE), it will be thrown directly instead of treating it in > handleException(), thus my serialization exception will never get handled. > The fix is to merge the catch RunTimeException into catch Exception. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8259) when client singlehop getAll encountered SerializationException, it should retry
[ https://issues.apache.org/jira/browse/GEODE-8259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou reassigned GEODE-8259: Assignee: Xiaojian Zhou > when client singlehop getAll encountered SerializationException, it should > retry > > > Key: GEODE-8259 > URL: https://issues.apache.org/jira/browse/GEODE-8259 > Project: Geode > Issue Type: Improvement >Reporter: Xiaojian Zhou >Assignee: Xiaojian Zhou >Priority: Major > > In GEOEDE-7090, DSFIDSerializerImpl.invokeFromData() will catch > RunTimeException and throw. But convert Exception to be IOException. The idea > is to avoid using SerializationException which is in another package. > However, if my fromData() failed with IndexOutOfBoundary exception (which is > an RTE), it will be thrown directly instead of treating it in > handleException(), thus my serialization exception will never get handled. > The fix is to merge the catch RunTimeException into catch Exception. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8259) when client singlehop getAll encountered SerializationException, it should retry
[ https://issues.apache.org/jira/browse/GEODE-8259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148977#comment-17148977 ] ASF GitHub Bot commented on GEODE-8259: --- gesterzhou merged pull request #5253: URL: https://github.com/apache/geode/pull/5253 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > when client singlehop getAll encountered SerializationException, it should > retry > > > Key: GEODE-8259 > URL: https://issues.apache.org/jira/browse/GEODE-8259 > Project: Geode > Issue Type: Improvement >Reporter: Xiaojian Zhou >Priority: Major > > In GEOEDE-7090, DSFIDSerializerImpl.invokeFromData() will catch > RunTimeException and throw. But convert Exception to be IOException. The idea > is to avoid using SerializationException which is in another package. > However, if my fromData() failed with IndexOutOfBoundary exception (which is > an RTE), it will be thrown directly instead of treating it in > handleException(), thus my serialization exception will never get handled. > The fix is to merge the catch RunTimeException into catch Exception. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8259) when client singlehop getAll encountered SerializationException, it should retry
[ https://issues.apache.org/jira/browse/GEODE-8259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou updated GEODE-8259: - Summary: when client singlehop getAll encountered SerializationException, it should retry (was: when client encountered SerializationException, it should retry for singlehop) > when client singlehop getAll encountered SerializationException, it should > retry > > > Key: GEODE-8259 > URL: https://issues.apache.org/jira/browse/GEODE-8259 > Project: Geode > Issue Type: Improvement >Reporter: Xiaojian Zhou >Priority: Major > > In GEOEDE-7090, DSFIDSerializerImpl.invokeFromData() will catch > RunTimeException and throw. But convert Exception to be IOException. The idea > is to avoid using SerializationException which is in another package. > However, if my fromData() failed with IndexOutOfBoundary exception (which is > an RTE), it will be thrown directly instead of treating it in > handleException(), thus my serialization exception will never get handled. > The fix is to merge the catch RunTimeException into catch Exception. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8259) when client encountered SerializationException, it should retry for singlehop
[ https://issues.apache.org/jira/browse/GEODE-8259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Xiaojian Zhou updated GEODE-8259: - Summary: when client encountered SerializationException, it should retry for singlehop (was: when client encountered SerializationException, it should retry) > when client encountered SerializationException, it should retry for singlehop > - > > Key: GEODE-8259 > URL: https://issues.apache.org/jira/browse/GEODE-8259 > Project: Geode > Issue Type: Improvement >Reporter: Xiaojian Zhou >Priority: Major > > In GEOEDE-7090, DSFIDSerializerImpl.invokeFromData() will catch > RunTimeException and throw. But convert Exception to be IOException. The idea > is to avoid using SerializationException which is in another package. > However, if my fromData() failed with IndexOutOfBoundary exception (which is > an RTE), it will be thrown directly instead of treating it in > handleException(), thus my serialization exception will never get handled. > The fix is to merge the catch RunTimeException into catch Exception. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8324) Events are not being replicated from one WAN site to another when there are multiple paths between the sites and the direct one is stopped
[
https://issues.apache.org/jira/browse/GEODE-8324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148966#comment-17148966
]
ASF subversion and git services commented on GEODE-8324:
Commit 514b17a5a43093c2301c5305ea356bc48924fe90 in geode's branch
refs/heads/feature/GEODE-8324 from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=514b17a ]
GEODE-8324: Don't add a remote ds id to recipients unless it is running
> Events are not being replicated from one WAN site to another when there are
> multiple paths between the sites and the direct one is stopped
> --
>
> Key: GEODE-8324
> URL: https://issues.apache.org/jira/browse/GEODE-8324
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: caching-applications
>
> Scenario
>
> The configuration is a normal star/mesh pattern where each site is connected
> to each other site.
> So, there are 2 paths from site-A to site-B:
> - the direct (site-A -> site-B)
> - the indirect path (site-A -> site-C -> site-B)
> If the direct path (meaning the sender in site-A to site-B) is stopped and a
> put is done in site-A, site-B doesn't receive the event even though the
> indirect path is not stopped.
> Here is the behavior:
> Site-A - dsid=1
> Site-B - dsid=2
> Site-C - dsid=3
> Site-A
> --
> Since site-A is configured with site-B and site-C, its events will contain
> recipient dsids for those sites (2 and 3 below).
> The event sent to site-C will look like:
> {noformat}
> AbstractGatewaySender.distribute sender=site-C processing local event
> newCallbackArg=GatewaySenderEventCallbackArgument
> [originatingSenderId=1;recipientGatewayReceivers={3, 2}]; region=/data; key=0
> {noformat}
> Site-C
> --
> Site-C receives the event:
> {noformat}
> GatewayReceiverCommand.cmdExecute processing create region=/data; key=0
> {noformat}
> The sender to site-B drops the event since it thinks it is already a
> recipient:
> {noformat}
> AbstractGatewaySender.distribute sender=site-B received event from remote
> site receivedCallbackArg=GatewaySenderEventCallbackArgument
> [originatingSenderId=1;recipientGatewayReceivers={3, 2}]; region=/data;
> key=0; eventId=EventID[id=25
> bytes;threadID=0x10030|1;sequenceID=0;bucketId=48]
> AbstractGatewaySender.distribute sender=site-B dropping event since it is
> already a recipient
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8324) Events are not being replicated from one WAN site to another when there are multiple paths between the sites and the direct one is stopped
[
https://issues.apache.org/jira/browse/GEODE-8324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148967#comment-17148967
]
ASF GitHub Bot commented on GEODE-8324:
---
boglesby opened a new pull request #5331:
URL: https://github.com/apache/geode/pull/5331
Thank you for submitting a contribution to Apache Geode.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced in
the commit message?
- [ ] Has your PR been rebased against the latest commit within the target
branch (typically `develop`)?
- [ ] Is your initial contribution a single, squashed commit?
- [ ] Does `gradlew build` run cleanly?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies
licensed in a way that is compatible for inclusion under [ASF
2.0](http://www.apache.org/legal/resolved.html#category-a)?
### Note:
Please ensure that once the PR is submitted, check Concourse for build
issues and
submit an update to your PR as soon as possible. If you need help, please
send an
email to d...@geode.apache.org.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Events are not being replicated from one WAN site to another when there are
> multiple paths between the sites and the direct one is stopped
> --
>
> Key: GEODE-8324
> URL: https://issues.apache.org/jira/browse/GEODE-8324
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: caching-applications
>
> Scenario
>
> The configuration is a normal star/mesh pattern where each site is connected
> to each other site.
> So, there are 2 paths from site-A to site-B:
> - the direct (site-A -> site-B)
> - the indirect path (site-A -> site-C -> site-B)
> If the direct path (meaning the sender in site-A to site-B) is stopped and a
> put is done in site-A, site-B doesn't receive the event even though the
> indirect path is not stopped.
> Here is the behavior:
> Site-A - dsid=1
> Site-B - dsid=2
> Site-C - dsid=3
> Site-A
> --
> Since site-A is configured with site-B and site-C, its events will contain
> recipient dsids for those sites (2 and 3 below).
> The event sent to site-C will look like:
> {noformat}
> AbstractGatewaySender.distribute sender=site-C processing local event
> newCallbackArg=GatewaySenderEventCallbackArgument
> [originatingSenderId=1;recipientGatewayReceivers={3, 2}]; region=/data; key=0
> {noformat}
> Site-C
> --
> Site-C receives the event:
> {noformat}
> GatewayReceiverCommand.cmdExecute processing create region=/data; key=0
> {noformat}
> The sender to site-B drops the event since it thinks it is already a
> recipient:
> {noformat}
> AbstractGatewaySender.distribute sender=site-B received event from remote
> site receivedCallbackArg=GatewaySenderEventCallbackArgument
> [originatingSenderId=1;recipientGatewayReceivers={3, 2}]; region=/data;
> key=0; eventId=EventID[id=25
> bytes;threadID=0x10030|1;sequenceID=0;bucketId=48]
> AbstractGatewaySender.distribute sender=site-B dropping event since it is
> already a recipient
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8240) View has old locator version number after rolling upgrade
[
https://issues.apache.org/jira/browse/GEODE-8240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148958#comment-17148958
]
ASF GitHub Bot commented on GEODE-8240:
---
Bill closed pull request #5278:
URL: https://github.com/apache/geode/pull/5278
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> View has old locator version number after rolling upgrade
> -
>
> Key: GEODE-8240
> URL: https://issues.apache.org/jira/browse/GEODE-8240
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership
>Reporter: Ernest Burghardt
>Assignee: Bill Burcham
>Priority: Major
>
> as shown in [https://github.com/apache/geode/pull/5224]
> locator upgrade from version 1.12.0 doesn't seem to occur
> {{testRollServersOnPartitionedRegion_dataserializable}} failure results:
> Expecting:
> <"Member Count : 3
> Name | Id
> |
> ---
> vm2 | 127.0.0.1(vm2:35019:locator):41000(version:GEODE 1.12.0)
> [Coordinator]
> vm0 | 10.0.0.111(vm0:35025):41001
> vm1 | 10.0.0.111(vm1:35030):41002
> ">
> not to contain:
> <"1.12.0">
> This problem was introduced in 1.12.0 and is present in all lines derived
> from that one, including 9.10, 1.13, and current develop/1.14
> What's actually happening is that the locator _is_ upgraded to a newer
> version. It joins with an older coordinator (that's running e.g. 1.12.0) and
> that coordinator produces a view showing the new locator/member as running
> the same version, in this case 1.12.0, as the coordinator.
> Eventually, all locators will be upgraded. But the view carries the incorrect
> version indication.
> The root cause seems to be that when {{GMSMemberData.setVersionObject(short
> versionOrdinal)}} sees a version ordinal that is unknown, i.e. a version
> ordinal corresponding to a new line of development: 1.13, 1.14, … that method
> throws away that version ordinal and replaces it with the one for the 1.12
> line.
> Since the current {{support/1.13}} and {{develop}} branches have the bug
> upgrading a current 1.13 to 1.14 or a current development/1.14 to 1.15 would
> exhibit the same behavior (locator apparently stuck at the older version in
> the view.)
> Ramifications of this incorrect version indication in the view are TBD.
> Whether or not this situation resolves itself after _another_ round of
> restarts is TBD.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8240) View has old locator version number after rolling upgrade
[
https://issues.apache.org/jira/browse/GEODE-8240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148957#comment-17148957
]
ASF GitHub Bot commented on GEODE-8240:
---
Bill commented on pull request #5278:
URL: https://github.com/apache/geode/pull/5278#issuecomment-652050659
closing this PR. it's out of date. It was made with an early version of the
GEODE-8240 fix on the `develop` branch. I'm about to make a brand new
1.12-based branch to test the latest version of that fix that just merged to
`develop`.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> View has old locator version number after rolling upgrade
> -
>
> Key: GEODE-8240
> URL: https://issues.apache.org/jira/browse/GEODE-8240
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership
>Reporter: Ernest Burghardt
>Assignee: Bill Burcham
>Priority: Major
>
> as shown in [https://github.com/apache/geode/pull/5224]
> locator upgrade from version 1.12.0 doesn't seem to occur
> {{testRollServersOnPartitionedRegion_dataserializable}} failure results:
> Expecting:
> <"Member Count : 3
> Name | Id
> |
> ---
> vm2 | 127.0.0.1(vm2:35019:locator):41000(version:GEODE 1.12.0)
> [Coordinator]
> vm0 | 10.0.0.111(vm0:35025):41001
> vm1 | 10.0.0.111(vm1:35030):41002
> ">
> not to contain:
> <"1.12.0">
> This problem was introduced in 1.12.0 and is present in all lines derived
> from that one, including 9.10, 1.13, and current develop/1.14
> What's actually happening is that the locator _is_ upgraded to a newer
> version. It joins with an older coordinator (that's running e.g. 1.12.0) and
> that coordinator produces a view showing the new locator/member as running
> the same version, in this case 1.12.0, as the coordinator.
> Eventually, all locators will be upgraded. But the view carries the incorrect
> version indication.
> The root cause seems to be that when {{GMSMemberData.setVersionObject(short
> versionOrdinal)}} sees a version ordinal that is unknown, i.e. a version
> ordinal corresponding to a new line of development: 1.13, 1.14, … that method
> throws away that version ordinal and replaces it with the one for the 1.12
> line.
> Since the current {{support/1.13}} and {{develop}} branches have the bug
> upgrading a current 1.13 to 1.14 or a current development/1.14 to 1.15 would
> exhibit the same behavior (locator apparently stuck at the older version in
> the view.)
> Ramifications of this incorrect version indication in the view are TBD.
> Whether or not this situation resolves itself after _another_ round of
> restarts is TBD.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8240) View has old locator version number after rolling upgrade
[
https://issues.apache.org/jira/browse/GEODE-8240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148955#comment-17148955
]
Bill Burcham commented on GEODE-8240:
-
Merged to {{develop}}. Waiting for CI to get further along before committing to
1.12, and 1.13 branches.
In advance of that I'm making a new experimental 1.12 feature branch to test
cherry-picking the fix back there.
> View has old locator version number after rolling upgrade
> -
>
> Key: GEODE-8240
> URL: https://issues.apache.org/jira/browse/GEODE-8240
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership
>Reporter: Ernest Burghardt
>Assignee: Bill Burcham
>Priority: Major
>
> as shown in [https://github.com/apache/geode/pull/5224]
> locator upgrade from version 1.12.0 doesn't seem to occur
> {{testRollServersOnPartitionedRegion_dataserializable}} failure results:
> Expecting:
> <"Member Count : 3
> Name | Id
> |
> ---
> vm2 | 127.0.0.1(vm2:35019:locator):41000(version:GEODE 1.12.0)
> [Coordinator]
> vm0 | 10.0.0.111(vm0:35025):41001
> vm1 | 10.0.0.111(vm1:35030):41002
> ">
> not to contain:
> <"1.12.0">
> This problem was introduced in 1.12.0 and is present in all lines derived
> from that one, including 9.10, 1.13, and current develop/1.14
> What's actually happening is that the locator _is_ upgraded to a newer
> version. It joins with an older coordinator (that's running e.g. 1.12.0) and
> that coordinator produces a view showing the new locator/member as running
> the same version, in this case 1.12.0, as the coordinator.
> Eventually, all locators will be upgraded. But the view carries the incorrect
> version indication.
> The root cause seems to be that when {{GMSMemberData.setVersionObject(short
> versionOrdinal)}} sees a version ordinal that is unknown, i.e. a version
> ordinal corresponding to a new line of development: 1.13, 1.14, … that method
> throws away that version ordinal and replaces it with the one for the 1.12
> line.
> Since the current {{support/1.13}} and {{develop}} branches have the bug
> upgrading a current 1.13 to 1.14 or a current development/1.14 to 1.15 would
> exhibit the same behavior (locator apparently stuck at the older version in
> the view.)
> Ramifications of this incorrect version indication in the view are TBD.
> Whether or not this situation resolves itself after _another_ round of
> restarts is TBD.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8324) Events are not being replicated from one WAN site to another when there are multiple paths between the sites and the direct one is stopped
[
https://issues.apache.org/jira/browse/GEODE-8324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barrett Oglesby updated GEODE-8324:
---
Labels: caching-applications (was: )
> Events are not being replicated from one WAN site to another when there are
> multiple paths between the sites and the direct one is stopped
> --
>
> Key: GEODE-8324
> URL: https://issues.apache.org/jira/browse/GEODE-8324
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
> Labels: caching-applications
>
> Scenario
>
> The configuration is a normal star/mesh pattern where each site is connected
> to each other site.
> So, there are 2 paths from site-A to site-B:
> - the direct (site-A -> site-B)
> - the indirect path (site-A -> site-C -> site-B)
> If the direct path (meaning the sender in site-A to site-B) is stopped and a
> put is done in site-A, site-B doesn't receive the event even though the
> indirect path is not stopped.
> Here is the behavior:
> Site-A - dsid=1
> Site-B - dsid=2
> Site-C - dsid=3
> Site-A
> --
> Since site-A is configured with site-B and site-C, its events will contain
> recipient dsids for those sites (2 and 3 below).
> The event sent to site-C will look like:
> {noformat}
> AbstractGatewaySender.distribute sender=site-C processing local event
> newCallbackArg=GatewaySenderEventCallbackArgument
> [originatingSenderId=1;recipientGatewayReceivers={3, 2}]; region=/data; key=0
> {noformat}
> Site-C
> --
> Site-C receives the event:
> {noformat}
> GatewayReceiverCommand.cmdExecute processing create region=/data; key=0
> {noformat}
> The sender to site-B drops the event since it thinks it is already a
> recipient:
> {noformat}
> AbstractGatewaySender.distribute sender=site-B received event from remote
> site receivedCallbackArg=GatewaySenderEventCallbackArgument
> [originatingSenderId=1;recipientGatewayReceivers={3, 2}]; region=/data;
> key=0; eventId=EventID[id=25
> bytes;threadID=0x10030|1;sequenceID=0;bucketId=48]
> AbstractGatewaySender.distribute sender=site-B dropping event since it is
> already a recipient
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8324) Events are not being replicated from one WAN site to another when there are multiple paths between the sites and the direct one is stopped
[
https://issues.apache.org/jira/browse/GEODE-8324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barrett Oglesby reassigned GEODE-8324:
--
Assignee: Barrett Oglesby
> Events are not being replicated from one WAN site to another when there are
> multiple paths between the sites and the direct one is stopped
> --
>
> Key: GEODE-8324
> URL: https://issues.apache.org/jira/browse/GEODE-8324
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
>
> Scenario
>
> The configuration is a normal star/mesh pattern where each site is connected
> to each other site.
> So, there are 2 paths from site-A to site-B:
> - the direct (site-A -> site-B)
> - the indirect path (site-A -> site-C -> site-B)
> If the direct path (meaning the sender in site-A to site-B) is stopped and a
> put is done in site-A, site-B doesn't receive the event even though the
> indirect path is not stopped.
> Here is the behavior:
> Site-A - dsid=1
> Site-B - dsid=2
> Site-C - dsid=3
> Site-A
> --
> Since site-A is configured with site-B and site-C, its events will contain
> recipient dsids for those sites (2 and 3 below).
> The event sent to site-C will look like:
> {noformat}
> AbstractGatewaySender.distribute sender=site-C processing local event
> newCallbackArg=GatewaySenderEventCallbackArgument
> [originatingSenderId=1;recipientGatewayReceivers={3, 2}]; region=/data; key=0
> {noformat}
> Site-C
> --
> Site-C receives the event:
> {noformat}
> GatewayReceiverCommand.cmdExecute processing create region=/data; key=0
> {noformat}
> The sender to site-B drops the event since it thinks it is already a
> recipient:
> {noformat}
> AbstractGatewaySender.distribute sender=site-B received event from remote
> site receivedCallbackArg=GatewaySenderEventCallbackArgument
> [originatingSenderId=1;recipientGatewayReceivers={3, 2}]; region=/data;
> key=0; eventId=EventID[id=25
> bytes;threadID=0x10030|1;sequenceID=0;bucketId=48]
> AbstractGatewaySender.distribute sender=site-B dropping event since it is
> already a recipient
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8324) Events are not being replicated from one WAN site to another when there are multiple paths between the sites and the direct one is stopped
Barrett Oglesby created GEODE-8324:
--
Summary: Events are not being replicated from one WAN site to
another when there are multiple paths between the sites and the direct one is
stopped
Key: GEODE-8324
URL: https://issues.apache.org/jira/browse/GEODE-8324
Project: Geode
Issue Type: Bug
Components: wan
Reporter: Barrett Oglesby
Scenario
The configuration is a normal star/mesh pattern where each site is connected
to each other site.
So, there are 2 paths from site-A to site-B:
- the direct (site-A -> site-B)
- the indirect path (site-A -> site-C -> site-B)
If the direct path (meaning the sender in site-A to site-B) is stopped and a
put is done in site-A, site-B doesn't receive the event even though the
indirect path is not stopped.
Here is the behavior:
Site-A - dsid=1
Site-B - dsid=2
Site-C - dsid=3
Site-A
--
Since site-A is configured with site-B and site-C, its events will contain
recipient dsids for those sites (2 and 3 below).
The event sent to site-C will look like:
{noformat}
AbstractGatewaySender.distribute sender=site-C processing local event
newCallbackArg=GatewaySenderEventCallbackArgument
[originatingSenderId=1;recipientGatewayReceivers={3, 2}]; region=/data; key=0
{noformat}
Site-C
--
Site-C receives the event:
{noformat}
GatewayReceiverCommand.cmdExecute processing create region=/data; key=0
{noformat}
The sender to site-B drops the event since it thinks it is already a recipient:
{noformat}
AbstractGatewaySender.distribute sender=site-B received event from remote site
receivedCallbackArg=GatewaySenderEventCallbackArgument
[originatingSenderId=1;recipientGatewayReceivers={3, 2}]; region=/data; key=0;
eventId=EventID[id=25 bytes;threadID=0x10030|1;sequenceID=0;bucketId=48]
AbstractGatewaySender.distribute sender=site-B dropping event since it is
already a recipient
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7971) Gateway sender to deliver transaction events atomically to gateway receivers
[ https://issues.apache.org/jira/browse/GEODE-7971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hanson updated GEODE-7971: --- Fix Version/s: (was: 1.13.0) 1.14.0 > Gateway sender to deliver transaction events atomically to gateway receivers > > > Key: GEODE-7971 > URL: https://issues.apache.org/jira/browse/GEODE-7971 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Fix For: 1.14.0 > > Time Spent: 50m > Remaining Estimate: 0h > > The goal of this ticket is to implement the necessary changes in the gateway > sender to prevent that events belonging to the same transaction are spread > across different batches. In other words, to ensure that events from the same > transaction are sent inside the same batch. > This will be an optional feature on gateway senders to be enabled via a new > parameter (--group-transaction-events) and will be restricted to serial > gateway senders with just one dispatcher thread or to parallel gateway > senders. > Apart from the above restriction, grouping of events for a transaction inside > the same batch may only be attained if the regions to which the events belong > are replicated by the same set of gateway senders with the > --group-transaction-events flag enabled. If this condition is not met, the > events will be correctly delivered by the gateway senders but it will not be > guaranteed that all events will always be sent inside the same batch. > For more details see: > [https://cwiki.apache.org/confluence/display/GEODE/Gw+sender+to+deliver+transaction+events+atomically+to+receivers] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-7971) Gateway sender to deliver transaction events atomically to gateway receivers
[ https://issues.apache.org/jira/browse/GEODE-7971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Hanson resolved GEODE-7971. Fix Version/s: 1.13.0 Resolution: Fixed Moved remaining issue to GEODE-8320 > Gateway sender to deliver transaction events atomically to gateway receivers > > > Key: GEODE-7971 > URL: https://issues.apache.org/jira/browse/GEODE-7971 > Project: Geode > Issue Type: Improvement > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Fix For: 1.13.0 > > Time Spent: 50m > Remaining Estimate: 0h > > The goal of this ticket is to implement the necessary changes in the gateway > sender to prevent that events belonging to the same transaction are spread > across different batches. In other words, to ensure that events from the same > transaction are sent inside the same batch. > This will be an optional feature on gateway senders to be enabled via a new > parameter (--group-transaction-events) and will be restricted to serial > gateway senders with just one dispatcher thread or to parallel gateway > senders. > Apart from the above restriction, grouping of events for a transaction inside > the same batch may only be attained if the regions to which the events belong > are replicated by the same set of gateway senders with the > --group-transaction-events flag enabled. If this condition is not met, the > events will be correctly delivered by the gateway senders but it will not be > guaranteed that all events will always be sent inside the same batch. > For more details see: > [https://cwiki.apache.org/confluence/display/GEODE/Gw+sender+to+deliver+transaction+events+atomically+to+receivers] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8320) SerialWANStatsDUnitTest.testReplicatedSerialPropagationHAWithGroupTransactionEvents is failiing
[
https://issues.apache.org/jira/browse/GEODE-8320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson resolved GEODE-8320.
Resolution: Duplicate
> SerialWANStatsDUnitTest.testReplicatedSerialPropagationHAWithGroupTransactionEvents
> is failiing
> ---
>
> Key: GEODE-8320
> URL: https://issues.apache.org/jira/browse/GEODE-8320
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Mark Hanson
>Assignee: Alberto Gomez
>Priority: Major
> Fix For: 1.14.0
>
>
> {noformat}
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest >
> testReplicatedSerialPropagationHAWithGroupTransactionEvents FAILED
> 11:55:01
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest$$Lambda$134/1929719983.run
> in VM 2 running on Host 249227cf2774 with 8 VMs
> 11:55:01
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 11:55:01
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> 11:55:01
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.testReplicatedSerialPropagationHAWithGroupTransactionEvents(SerialWANStatsDUnitTest.java:578)
> 11:55:01
> 11:55:01
> Caused by:
> 11:55:01
> org.awaitility.core.ConditionTimeoutException: Assertion condition defined
> as a lambda expression in org.apache.geode.internal.cache.wan.WANTestBase
> that uses int, intorg.apache.geode.cache.Region Expected region entries:
> 2 but actual entries: 1 present region keyset [7435200, <*
> Intentionally cut out by Jira submitter *> 8851200] expected:<2> but
> was:<1> within 5 minutes.
> 11:55:01
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> 11:55:01
> at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> 11:55:01
> at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> 11:55:01
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> 11:55:01
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> 11:55:01
> at
> org.apache.geode.internal.cache.wan.WANTestBase.validateRegionSize(WANTestBase.java:2942)
> 11:55:01
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.lambda$testReplicatedSerialPropagationHAWithGroupTransactionEvents$bb17a952$8(SerialWANStatsDUnitTest.java:578)
> 11:55:01
> 11:55:01
> Caused by:
> 11:55:01
> java.lang.AssertionError: Expected region entries: 2 but actual entries:
> 1 present region keyset [7435200, <*Intentionally cut out by Jira
> submitter*> ] expected:<2> but was:<1>
> 12:31:11
> {noformat}
>
>
>
>
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0193/test-results/distributedTest/1593463337/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0193/test-artifacts/1593463337/distributedtestfiles-OpenJDK8-1.14.0-build.0193.tgz
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (GEODE-8320) SerialWANStatsDUnitTest.testReplicatedSerialPropagationHAWithGroupTransactionEvents is failiing
[
https://issues.apache.org/jira/browse/GEODE-8320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Hanson reopened GEODE-8320:
> SerialWANStatsDUnitTest.testReplicatedSerialPropagationHAWithGroupTransactionEvents
> is failiing
> ---
>
> Key: GEODE-8320
> URL: https://issues.apache.org/jira/browse/GEODE-8320
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Mark Hanson
>Assignee: Alberto Gomez
>Priority: Major
> Fix For: 1.14.0
>
>
> {noformat}
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest >
> testReplicatedSerialPropagationHAWithGroupTransactionEvents FAILED
> 11:55:01
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest$$Lambda$134/1929719983.run
> in VM 2 running on Host 249227cf2774 with 8 VMs
> 11:55:01
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> 11:55:01
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> 11:55:01
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.testReplicatedSerialPropagationHAWithGroupTransactionEvents(SerialWANStatsDUnitTest.java:578)
> 11:55:01
> 11:55:01
> Caused by:
> 11:55:01
> org.awaitility.core.ConditionTimeoutException: Assertion condition defined
> as a lambda expression in org.apache.geode.internal.cache.wan.WANTestBase
> that uses int, intorg.apache.geode.cache.Region Expected region entries:
> 2 but actual entries: 1 present region keyset [7435200, <*
> Intentionally cut out by Jira submitter *> 8851200] expected:<2> but
> was:<1> within 5 minutes.
> 11:55:01
> at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> 11:55:01
> at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> 11:55:01
> at org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> 11:55:01
> at org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> 11:55:01
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> 11:55:01
> at
> org.apache.geode.internal.cache.wan.WANTestBase.validateRegionSize(WANTestBase.java:2942)
> 11:55:01
> at
> org.apache.geode.internal.cache.wan.serial.SerialWANStatsDUnitTest.lambda$testReplicatedSerialPropagationHAWithGroupTransactionEvents$bb17a952$8(SerialWANStatsDUnitTest.java:578)
> 11:55:01
> 11:55:01
> Caused by:
> 11:55:01
> java.lang.AssertionError: Expected region entries: 2 but actual entries:
> 1 present region keyset [7435200, <*Intentionally cut out by Jira
> submitter*> ] expected:<2> but was:<1>
> 12:31:11
> {noformat}
>
>
>
>
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0193/test-results/distributedTest/1593463337/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0193/test-artifacts/1593463337/distributedtestfiles-OpenJDK8-1.14.0-build.0193.tgz
> {noformat}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-7864) Code improvement refactoring
[ https://issues.apache.org/jira/browse/GEODE-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148934#comment-17148934 ] ASF GitHub Bot commented on GEODE-7864: --- DonalEvans merged pull request #5330: URL: https://github.com/apache/geode/pull/5330 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Code improvement refactoring > > > Key: GEODE-7864 > URL: https://issues.apache.org/jira/browse/GEODE-7864 > Project: Geode > Issue Type: Improvement >Reporter: Nabarun Nag >Priority: Major > Time Spent: 13h 10m > Remaining Estimate: 0h > > This is a placeholder ticket. > * this is used to do refactoring. > * this ticket number is used to number the commit message. > * this ticket will never be closed. > * it will be used to mark improvements like correcting spelling mistakes, > efficient java code, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7864) Code improvement refactoring
[ https://issues.apache.org/jira/browse/GEODE-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148935#comment-17148935 ] ASF subversion and git services commented on GEODE-7864: Commit 5d6fcf1d8113071299a0fad09db9f1c6825b0ea6 in geode's branch refs/heads/develop from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5d6fcf1 ] GEODE-7864: Fix array index out of bounds alerts (#5330) Authored-by: Donal Evans > Code improvement refactoring > > > Key: GEODE-7864 > URL: https://issues.apache.org/jira/browse/GEODE-7864 > Project: Geode > Issue Type: Improvement >Reporter: Nabarun Nag >Priority: Major > Time Spent: 13h 10m > Remaining Estimate: 0h > > This is a placeholder ticket. > * this is used to do refactoring. > * this ticket number is used to number the commit message. > * this ticket will never be closed. > * it will be used to mark improvements like correcting spelling mistakes, > efficient java code, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8185) Geode should participate in JTA transaction as a normal XA resource
[ https://issues.apache.org/jira/browse/GEODE-8185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148925#comment-17148925 ] Eric Shu commented on GEODE-8185: - In Geode it is hard to support XA transaction. The transaction doe not hold locks for a period of time (only holds the locks during commit). Therefore commit could fail if another transaction has committed and modify the state of entries touched in the current transaction. And current transaction could fail with CommitConflictException. Basically, there is no prepare phase in Geode. Also, geode does not support for recovery -- it can not rollback if a transaction is in commit process or committed. If another XAResource failed during commit phase, Geode can not rollback the transaction. > Geode should participate in JTA transaction as a normal XA resource > --- > > Key: GEODE-8185 > URL: https://issues.apache.org/jira/browse/GEODE-8185 > Project: Geode > Issue Type: Improvement >Reporter: Vadim Lotarev >Priority: Critical > > Currently Geode doesn't support two phase commit and can participate in JTA > transaction only as LRCO (what is not very reliable). It is highly desirable > to add normal XA support making Geode cache a normal XA resource with > two-phase commit support. > Many competitors already has such a support. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7864) Code improvement refactoring
[ https://issues.apache.org/jira/browse/GEODE-7864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148897#comment-17148897 ] ASF GitHub Bot commented on GEODE-7864: --- lgtm-com[bot] commented on pull request #5330: URL: https://github.com/apache/geode/pull/5330#issuecomment-651976168 This pull request **fixes 9 alerts** when merging 209665716235025c0967c8ae1c8e7760647cd42e into bfe1ca113124ea958dc02dd9be90cdb0aabe5c4d - [view on LGTM.com](https://lgtm.com/projects/g/apache/geode/rev/pr-bd9d26ca8975c37e3bb7f4dd43fda3573d309eeb) **fixed alerts:** * 9 for Array index out of bounds This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Code improvement refactoring > > > Key: GEODE-7864 > URL: https://issues.apache.org/jira/browse/GEODE-7864 > Project: Geode > Issue Type: Improvement >Reporter: Nabarun Nag >Priority: Major > Time Spent: 13h 10m > Remaining Estimate: 0h > > This is a placeholder ticket. > * this is used to do refactoring. > * this ticket number is used to number the commit message. > * this ticket will never be closed. > * it will be used to mark improvements like correcting spelling mistakes, > efficient java code, etc. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GEODE-7254) ServerOperationException While performing a remote put
[
https://issues.apache.org/jira/browse/GEODE-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148826#comment-17148826
]
Kirk Lund edited comment on GEODE-7254 at 6/30/20, 5:33 PM:
The ServerOperationException is logged at debug/fine level which is why you
only see it at debug/fine or lower.
The complete stack is:
{noformat}
org.apache.geode.cache.client.ServerOperationException: remote server on
RGOTETPF0T711Q(5296:loner):51773:b186be82: : While performing a remote put
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.processAck(PutOp.java:384)
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.processResponse(PutOp.java:308)
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.attemptReadResponse(PutOp.java:449)
at
org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:386)
at
org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:274)
at
org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:325)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:892)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:171)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:128)
at
org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:758)
at org.apache.geode.cache.client.internal.PutOp.execute(PutOp.java:89)
at
org.apache.geode.cache.client.internal.ServerRegionProxy.put(ServerRegionProxy.java:152)
at
org.apache.geode.internal.cache.LocalRegion.serverPut(LocalRegion.java:3032)
at
org.apache.geode.internal.cache.LocalRegion.cacheWriteBeforePut(LocalRegion.java:3144)
at
org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:238)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5664)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:152)
at
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5090)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1635)
at
org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1622)
at
org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:411)
at
com.actuate.iserver.utils.cache.GeodeCacheClient.cacheObject(GeodeCacheClient.java:41)
at
com.actuate.iserver.utils.CachedUserProperties.cache(CachedUserProperties.java:88)
at
com.actuate.iserver.services.api.LoginServiceBase.updateTokenMappings(LoginServiceBase.java:144)
at
com.actuate.iserver.services.api.LoginServiceBase.doExecute(LoginServiceBase.java:139)
at com.actuate.iserver.services.ServiceBase.execute(ServiceBase.java:72)
at
com.actuate.iserver.services.api.idapi.actuate11.ActuateSoapBindingImpl.login(ActuateSoapBindingImpl.java:29)
at
com.actuate.schemas.actuate11.wsdl.ActuateAPIMessageReceiverInOut.invokeBusinessLogic(ActuateAPIMessageReceiverInOut.java:2245)
at
com.actuate.iserver.services.api.idapi.actuate11.ActuateAPIMessageReceiver.invokeBusinessLogic(ActuateAPIMessageReceiver.java:29)
at
org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40)
at
org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:114)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:173)
at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:173)
at
org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:144)
at
com.actuate.webserver.NimbleAxis2Servlet.doPostWrapper(NimbleAxis2Servlet.java:88)
at
com.actuate.ihub.filter.LocalFilter.processRequest(LocalFilter.java:331)
at
com.actuate.ihub.filter.RequestFilter.doFilter(RequestFilter.java:269)
at
com.actuate.ihub.filter.RequestFilterChain.processFilter(RequestFilterChain.java:52)
at
com.actuate.ihub.filter.RequestFilterManager.processFilters(RequestFilterManager.java:264)
at com.actuate.ihub.web.FilterServlet.doRequest(FilterServlet.java:153)
at com.actuate.ihub.web.FilterServlet.doPost(FilterServlet.java:82)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:660)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
[jira] [Comment Edited] (GEODE-7254) ServerOperationException While performing a remote put
[
https://issues.apache.org/jira/browse/GEODE-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148826#comment-17148826
]
Kirk Lund edited comment on GEODE-7254 at 6/30/20, 5:31 PM:
The ServerOperationException is logged at debug/fine level which is why you
only see it at debug/fine or lower.
The complete stack is:
{noformat}
org.apache.geode.cache.client.ServerOperationException: remote server on
RGOTETPF0T711Q(5296:loner):51773:b186be82: : While performing a remote put
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.processAck(PutOp.java:384)
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.processResponse(PutOp.java:308)
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.attemptReadResponse(PutOp.java:449)
at
org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:386)
at
org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:274)
at
org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:325)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:892)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:171)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:128)
at
org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:758)
at org.apache.geode.cache.client.internal.PutOp.execute(PutOp.java:89)
at
org.apache.geode.cache.client.internal.ServerRegionProxy.put(ServerRegionProxy.java:152)
at
org.apache.geode.internal.cache.LocalRegion.serverPut(LocalRegion.java:3032)
at
org.apache.geode.internal.cache.LocalRegion.cacheWriteBeforePut(LocalRegion.java:3144)
at
org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:238)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5664)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:152)
at
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5090)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1635)
at
org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1622)
at
org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:411)
at
com.actuate.iserver.utils.cache.GeodeCacheClient.cacheObject(GeodeCacheClient.java:41)
at
com.actuate.iserver.utils.CachedUserProperties.cache(CachedUserProperties.java:88)
at
com.actuate.iserver.services.api.LoginServiceBase.updateTokenMappings(LoginServiceBase.java:144)
at
com.actuate.iserver.services.api.LoginServiceBase.doExecute(LoginServiceBase.java:139)
at com.actuate.iserver.services.ServiceBase.execute(ServiceBase.java:72)
at
com.actuate.iserver.services.api.idapi.actuate11.ActuateSoapBindingImpl.login(ActuateSoapBindingImpl.java:29)
at
com.actuate.schemas.actuate11.wsdl.ActuateAPIMessageReceiverInOut.invokeBusinessLogic(ActuateAPIMessageReceiverInOut.java:2245)
at
com.actuate.iserver.services.api.idapi.actuate11.ActuateAPIMessageReceiver.invokeBusinessLogic(ActuateAPIMessageReceiver.java:29)
at
org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40)
at
org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:114)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:173)
at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:173)
at
org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:144)
at
com.actuate.webserver.NimbleAxis2Servlet.doPostWrapper(NimbleAxis2Servlet.java:88)
at
com.actuate.ihub.filter.LocalFilter.processRequest(LocalFilter.java:331)
at
com.actuate.ihub.filter.RequestFilter.doFilter(RequestFilter.java:269)
at
com.actuate.ihub.filter.RequestFilterChain.processFilter(RequestFilterChain.java:52)
at
com.actuate.ihub.filter.RequestFilterManager.processFilters(RequestFilterManager.java:264)
at com.actuate.ihub.web.FilterServlet.doRequest(FilterServlet.java:153)
at com.actuate.ihub.web.FilterServlet.doPost(FilterServlet.java:82)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:660)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
[jira] [Comment Edited] (GEODE-7254) ServerOperationException While performing a remote put
[
https://issues.apache.org/jira/browse/GEODE-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148826#comment-17148826
]
Kirk Lund edited comment on GEODE-7254 at 6/30/20, 5:29 PM:
The ServerOperationException is logged at debug/fine level which is why you
only see it at debug/fine or lower.
The complete stack is:
{noformat}
org.apache.geode.cache.client.ServerOperationException: remote server on
RGOTETPF0T711Q(5296:loner):51773:b186be82: : While performing a remote put
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.processAck(PutOp.java:384)
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.processResponse(PutOp.java:308)
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.attemptReadResponse(PutOp.java:449)
at
org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:386)
at
org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:274)
at
org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:325)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:892)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:171)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:128)
at
org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:758)
at org.apache.geode.cache.client.internal.PutOp.execute(PutOp.java:89)
at
org.apache.geode.cache.client.internal.ServerRegionProxy.put(ServerRegionProxy.java:152)
at
org.apache.geode.internal.cache.LocalRegion.serverPut(LocalRegion.java:3032)
at
org.apache.geode.internal.cache.LocalRegion.cacheWriteBeforePut(LocalRegion.java:3144)
at
org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:238)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5664)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:152)
at
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5090)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1635)
at
org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1622)
at
org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:411)
at
com.actuate.iserver.utils.cache.GeodeCacheClient.cacheObject(GeodeCacheClient.java:41)
at
com.actuate.iserver.utils.CachedUserProperties.cache(CachedUserProperties.java:88)
at
com.actuate.iserver.services.api.LoginServiceBase.updateTokenMappings(LoginServiceBase.java:144)
at
com.actuate.iserver.services.api.LoginServiceBase.doExecute(LoginServiceBase.java:139)
at com.actuate.iserver.services.ServiceBase.execute(ServiceBase.java:72)
at
com.actuate.iserver.services.api.idapi.actuate11.ActuateSoapBindingImpl.login(ActuateSoapBindingImpl.java:29)
at
com.actuate.schemas.actuate11.wsdl.ActuateAPIMessageReceiverInOut.invokeBusinessLogic(ActuateAPIMessageReceiverInOut.java:2245)
at
com.actuate.iserver.services.api.idapi.actuate11.ActuateAPIMessageReceiver.invokeBusinessLogic(ActuateAPIMessageReceiver.java:29)
at
org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40)
at
org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:114)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:173)
at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:173)
at
org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:144)
at
com.actuate.webserver.NimbleAxis2Servlet.doPostWrapper(NimbleAxis2Servlet.java:88)
at
com.actuate.ihub.filter.LocalFilter.processRequest(LocalFilter.java:331)
at
com.actuate.ihub.filter.RequestFilter.doFilter(RequestFilter.java:269)
at
com.actuate.ihub.filter.RequestFilterChain.processFilter(RequestFilterChain.java:52)
at
com.actuate.ihub.filter.RequestFilterManager.processFilters(RequestFilterManager.java:264)
at com.actuate.ihub.web.FilterServlet.doRequest(FilterServlet.java:153)
at com.actuate.ihub.web.FilterServlet.doPost(FilterServlet.java:82)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:660)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
[jira] [Comment Edited] (GEODE-7254) ServerOperationException While performing a remote put
[
https://issues.apache.org/jira/browse/GEODE-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148826#comment-17148826
]
Kirk Lund edited comment on GEODE-7254 at 6/30/20, 5:29 PM:
The ServerOperationException is logged at debug/fine level which is why you
only see it at debug/fine or lower.
The complete stack is:
{noformat}
org.apache.geode.cache.client.ServerOperationException: remote server on
RGOTETPF0T711Q(5296:loner):51773:b186be82: : While performing a remote put
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.processAck(PutOp.java:384)
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.processResponse(PutOp.java:308)
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.attemptReadResponse(PutOp.java:449)
at
org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:386)
at
org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:274)
at
org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:325)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:892)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:171)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:128)
at
org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:758)
at org.apache.geode.cache.client.internal.PutOp.execute(PutOp.java:89)
at
org.apache.geode.cache.client.internal.ServerRegionProxy.put(ServerRegionProxy.java:152)
at
org.apache.geode.internal.cache.LocalRegion.serverPut(LocalRegion.java:3032)
at
org.apache.geode.internal.cache.LocalRegion.cacheWriteBeforePut(LocalRegion.java:3144)
at
org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:238)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5664)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:152)
at
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5090)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1635)
at
org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1622)
at
org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:411)
at
com.actuate.iserver.utils.cache.GeodeCacheClient.cacheObject(GeodeCacheClient.java:41)
at
com.actuate.iserver.utils.CachedUserProperties.cache(CachedUserProperties.java:88)
at
com.actuate.iserver.services.api.LoginServiceBase.updateTokenMappings(LoginServiceBase.java:144)
at
com.actuate.iserver.services.api.LoginServiceBase.doExecute(LoginServiceBase.java:139)
at com.actuate.iserver.services.ServiceBase.execute(ServiceBase.java:72)
at
com.actuate.iserver.services.api.idapi.actuate11.ActuateSoapBindingImpl.login(ActuateSoapBindingImpl.java:29)
at
com.actuate.schemas.actuate11.wsdl.ActuateAPIMessageReceiverInOut.invokeBusinessLogic(ActuateAPIMessageReceiverInOut.java:2245)
at
com.actuate.iserver.services.api.idapi.actuate11.ActuateAPIMessageReceiver.invokeBusinessLogic(ActuateAPIMessageReceiver.java:29)
at
org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40)
at
org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:114)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:173)
at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:173)
at
org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:144)
at
com.actuate.webserver.NimbleAxis2Servlet.doPostWrapper(NimbleAxis2Servlet.java:88)
at
com.actuate.ihub.filter.LocalFilter.processRequest(LocalFilter.java:331)
at
com.actuate.ihub.filter.RequestFilter.doFilter(RequestFilter.java:269)
at
com.actuate.ihub.filter.RequestFilterChain.processFilter(RequestFilterChain.java:52)
at
com.actuate.ihub.filter.RequestFilterManager.processFilters(RequestFilterManager.java:264)
at com.actuate.ihub.web.FilterServlet.doRequest(FilterServlet.java:153)
at com.actuate.ihub.web.FilterServlet.doPost(FilterServlet.java:82)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:660)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
[jira] [Comment Edited] (GEODE-7254) ServerOperationException While performing a remote put
[
https://issues.apache.org/jira/browse/GEODE-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148826#comment-17148826
]
Kirk Lund edited comment on GEODE-7254 at 6/30/20, 5:28 PM:
The ServerOperationException is logged at debug/fine level which is why you
only see it at debug/fine or lower.
The complete stack is:
{noformat}
org.apache.geode.cache.client.ServerOperationException: remote server on
RGOTETPF0T711Q(5296:loner):51773:b186be82: : While performing a remote put
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.processAck(PutOp.java:384)
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.processResponse(PutOp.java:308)
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.attemptReadResponse(PutOp.java:449)
at
org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:386)
at
org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:274)
at
org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:325)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:892)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:171)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:128)
at
org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:758)
at org.apache.geode.cache.client.internal.PutOp.execute(PutOp.java:89)
at
org.apache.geode.cache.client.internal.ServerRegionProxy.put(ServerRegionProxy.java:152)
at
org.apache.geode.internal.cache.LocalRegion.serverPut(LocalRegion.java:3032)
at
org.apache.geode.internal.cache.LocalRegion.cacheWriteBeforePut(LocalRegion.java:3144)
at
org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:238)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5664)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:152)
at
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5090)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1635)
at
org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1622)
at
org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:411)
at
com.actuate.iserver.utils.cache.GeodeCacheClient.cacheObject(GeodeCacheClient.java:41)
at
com.actuate.iserver.utils.CachedUserProperties.cache(CachedUserProperties.java:88)
at
com.actuate.iserver.services.api.LoginServiceBase.updateTokenMappings(LoginServiceBase.java:144)
at
com.actuate.iserver.services.api.LoginServiceBase.doExecute(LoginServiceBase.java:139)
at com.actuate.iserver.services.ServiceBase.execute(ServiceBase.java:72)
at
com.actuate.iserver.services.api.idapi.actuate11.ActuateSoapBindingImpl.login(ActuateSoapBindingImpl.java:29)
at
com.actuate.schemas.actuate11.wsdl.ActuateAPIMessageReceiverInOut.invokeBusinessLogic(ActuateAPIMessageReceiverInOut.java:2245)
at
com.actuate.iserver.services.api.idapi.actuate11.ActuateAPIMessageReceiver.invokeBusinessLogic(ActuateAPIMessageReceiver.java:29)
at
org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40)
at
org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:114)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:173)
at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:173)
at
org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:144)
at
com.actuate.webserver.NimbleAxis2Servlet.doPostWrapper(NimbleAxis2Servlet.java:88)
at
com.actuate.ihub.filter.LocalFilter.processRequest(LocalFilter.java:331)
at
com.actuate.ihub.filter.RequestFilter.doFilter(RequestFilter.java:269)
at
com.actuate.ihub.filter.RequestFilterChain.processFilter(RequestFilterChain.java:52)
at
com.actuate.ihub.filter.RequestFilterManager.processFilters(RequestFilterManager.java:264)
at com.actuate.ihub.web.FilterServlet.doRequest(FilterServlet.java:153)
at com.actuate.ihub.web.FilterServlet.doPost(FilterServlet.java:82)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:660)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
[jira] [Comment Edited] (GEODE-7254) ServerOperationException While performing a remote put
[
https://issues.apache.org/jira/browse/GEODE-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148826#comment-17148826
]
Kirk Lund edited comment on GEODE-7254 at 6/30/20, 5:25 PM:
The ServerOperationException is logged at debug/fine level which is why you
only see it at debug/fine or lower.
The complete stack is:
{noformat}
org.apache.geode.cache.client.ServerOperationException: remote server on
RGOTETPF0T711Q(5296:loner):51773:b186be82: : While performing a remote put
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.processAck(PutOp.java:384)
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.processResponse(PutOp.java:308)
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.attemptReadResponse(PutOp.java:449)
at
org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:386)
at
org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:274)
at
org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:325)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:892)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:171)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:128)
at
org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:758)
at org.apache.geode.cache.client.internal.PutOp.execute(PutOp.java:89)
at
org.apache.geode.cache.client.internal.ServerRegionProxy.put(ServerRegionProxy.java:152)
at
org.apache.geode.internal.cache.LocalRegion.serverPut(LocalRegion.java:3032)
at
org.apache.geode.internal.cache.LocalRegion.cacheWriteBeforePut(LocalRegion.java:3144)
at
org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:238)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5664)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:152)
at
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5090)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1635)
at
org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1622)
at
org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:411)
at
com.actuate.iserver.utils.cache.GeodeCacheClient.cacheObject(GeodeCacheClient.java:41)
at
com.actuate.iserver.utils.CachedUserProperties.cache(CachedUserProperties.java:88)
at
com.actuate.iserver.services.api.LoginServiceBase.updateTokenMappings(LoginServiceBase.java:144)
at
com.actuate.iserver.services.api.LoginServiceBase.doExecute(LoginServiceBase.java:139)
at com.actuate.iserver.services.ServiceBase.execute(ServiceBase.java:72)
at
com.actuate.iserver.services.api.idapi.actuate11.ActuateSoapBindingImpl.login(ActuateSoapBindingImpl.java:29)
at
com.actuate.schemas.actuate11.wsdl.ActuateAPIMessageReceiverInOut.invokeBusinessLogic(ActuateAPIMessageReceiverInOut.java:2245)
at
com.actuate.iserver.services.api.idapi.actuate11.ActuateAPIMessageReceiver.invokeBusinessLogic(ActuateAPIMessageReceiver.java:29)
at
org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40)
at
org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:114)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:173)
at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:173)
at
org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:144)
at
com.actuate.webserver.NimbleAxis2Servlet.doPostWrapper(NimbleAxis2Servlet.java:88)
at
com.actuate.ihub.filter.LocalFilter.processRequest(LocalFilter.java:331)
at
com.actuate.ihub.filter.RequestFilter.doFilter(RequestFilter.java:269)
at
com.actuate.ihub.filter.RequestFilterChain.processFilter(RequestFilterChain.java:52)
at
com.actuate.ihub.filter.RequestFilterManager.processFilters(RequestFilterManager.java:264)
at com.actuate.ihub.web.FilterServlet.doRequest(FilterServlet.java:153)
at com.actuate.ihub.web.FilterServlet.doPost(FilterServlet.java:82)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:660)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
[jira] [Comment Edited] (GEODE-7254) ServerOperationException While performing a remote put
[
https://issues.apache.org/jira/browse/GEODE-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148826#comment-17148826
]
Kirk Lund edited comment on GEODE-7254 at 6/30/20, 5:23 PM:
The ServerOperationException is logged at debug/fine level which is why you
only see it at debug/fine or lower.
The complete stack is:
{noformat}
org.apache.geode.cache.client.ServerOperationException: remote server on
RGOTETPF0T711Q(5296:loner):51773:b186be82: : While performing a remote put
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.processAck(PutOp.java:384)
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.processResponse(PutOp.java:308)
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.attemptReadResponse(PutOp.java:449)
at
org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:386)
at
org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:274)
at
org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:325)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:892)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:171)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:128)
at
org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:758)
at org.apache.geode.cache.client.internal.PutOp.execute(PutOp.java:89)
at
org.apache.geode.cache.client.internal.ServerRegionProxy.put(ServerRegionProxy.java:152)
at
org.apache.geode.internal.cache.LocalRegion.serverPut(LocalRegion.java:3032)
at
org.apache.geode.internal.cache.LocalRegion.cacheWriteBeforePut(LocalRegion.java:3144)
at
org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:238)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5664)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:152)
at
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5090)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1635)
at
org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1622)
at
org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:411)
at
com.actuate.iserver.utils.cache.GeodeCacheClient.cacheObject(GeodeCacheClient.java:41)
at
com.actuate.iserver.utils.CachedUserProperties.cache(CachedUserProperties.java:88)
at
com.actuate.iserver.services.api.LoginServiceBase.updateTokenMappings(LoginServiceBase.java:144)
at
com.actuate.iserver.services.api.LoginServiceBase.doExecute(LoginServiceBase.java:139)
at com.actuate.iserver.services.ServiceBase.execute(ServiceBase.java:72)
at
com.actuate.iserver.services.api.idapi.actuate11.ActuateSoapBindingImpl.login(ActuateSoapBindingImpl.java:29)
at
com.actuate.schemas.actuate11.wsdl.ActuateAPIMessageReceiverInOut.invokeBusinessLogic(ActuateAPIMessageReceiverInOut.java:2245)
at
com.actuate.iserver.services.api.idapi.actuate11.ActuateAPIMessageReceiver.invokeBusinessLogic(ActuateAPIMessageReceiver.java:29)
at
org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40)
at
org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:114)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:173)
at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:173)
at
org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:144)
at
com.actuate.webserver.NimbleAxis2Servlet.doPostWrapper(NimbleAxis2Servlet.java:88)
at
com.actuate.ihub.filter.LocalFilter.processRequest(LocalFilter.java:331)
at
com.actuate.ihub.filter.RequestFilter.doFilter(RequestFilter.java:269)
at
com.actuate.ihub.filter.RequestFilterChain.processFilter(RequestFilterChain.java:52)
at
com.actuate.ihub.filter.RequestFilterManager.processFilters(RequestFilterManager.java:264)
at com.actuate.ihub.web.FilterServlet.doRequest(FilterServlet.java:153)
at com.actuate.ihub.web.FilterServlet.doPost(FilterServlet.java:82)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:660)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
[jira] [Resolved] (GEODE-8303) refactor Redis (String)SetExecutor
[ https://issues.apache.org/jira/browse/GEODE-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Hutchison resolved GEODE-8303. --- Resolution: Fixed > refactor Redis (String)SetExecutor > -- > > Key: GEODE-8303 > URL: https://issues.apache.org/jira/browse/GEODE-8303 > Project: Geode > Issue Type: Improvement >Reporter: John Hutchison >Priority: Major > > break up single loop and corresponding switch statement into methods with > intention of grouping together business logic associated with different > optional parameters -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7254) ServerOperationException While performing a remote put
[ https://issues.apache.org/jira/browse/GEODE-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-7254: - Component/s: (was: core) (was: configuration) serialization > ServerOperationException While performing a remote put > -- > > Key: GEODE-7254 > URL: https://issues.apache.org/jira/browse/GEODE-7254 > Project: Geode > Issue Type: Bug > Components: client/server, serialization >Affects Versions: 1.8.0 >Reporter: rajesh >Priority: Blocker > Attachments: iHubCacheLocatorProcess.log, iHubCacheServerProcess.log, > ihub.5296.RGOTETPF0T711Q.2019-09-30_20_44_40+0530.0.log, > meta-iHubCacheLocatorProcess-01.log, meta-iHubCacheServerProcess-02.log > > > Configuration: Locator and Server are running as different process using > peer to peer configuration. > while trying to insert a custom object in to a cache region using client > cache we are getting the following exception. > This occurs only when the Geode Locator/Server are started with log level set > to fine, finer, finest and all. > If the log level is set to severe, error, warning, info, config everything > works fine. > I am not sure if log level change has anything to do with put operation. I am > attaching the locator and server log files. > > Also we have recently upgraded the geode version from 1.1.0 to 1.8. we have > been using 1.1.0 for quite sometime without any major issues. upgraded to > 1.8 and no code changes were made but still getting this issue. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7254) ServerOperationException While performing a remote put
[
https://issues.apache.org/jira/browse/GEODE-7254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148826#comment-17148826
]
Kirk Lund commented on GEODE-7254:
--
The ServerOperationException is logged at debug/fine level which is why you
only see it at debug/fine or lower.
The complete stack is:
{noformat}
org.apache.geode.cache.client.ServerOperationException: remote server on
RGOTETPF0T711Q(5296:loner):51773:b186be82: : While performing a remote put
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.processAck(PutOp.java:384)
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.processResponse(PutOp.java:308)
at
org.apache.geode.cache.client.internal.PutOp$PutOpImpl.attemptReadResponse(PutOp.java:449)
at
org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:386)
at
org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:274)
at
org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:325)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:892)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:171)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:128)
at
org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:758)
at org.apache.geode.cache.client.internal.PutOp.execute(PutOp.java:89)
at
org.apache.geode.cache.client.internal.ServerRegionProxy.put(ServerRegionProxy.java:152)
at
org.apache.geode.internal.cache.LocalRegion.serverPut(LocalRegion.java:3032)
at
org.apache.geode.internal.cache.LocalRegion.cacheWriteBeforePut(LocalRegion.java:3144)
at
org.apache.geode.internal.cache.ProxyRegionMap.basicPut(ProxyRegionMap.java:238)
at
org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5664)
at
org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:152)
at
org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5090)
at
org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1635)
at
org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1622)
at
org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:411)
at
com.actuate.iserver.utils.cache.GeodeCacheClient.cacheObject(GeodeCacheClient.java:41)
at
com.actuate.iserver.utils.CachedUserProperties.cache(CachedUserProperties.java:88)
at
com.actuate.iserver.services.api.LoginServiceBase.updateTokenMappings(LoginServiceBase.java:144)
at
com.actuate.iserver.services.api.LoginServiceBase.doExecute(LoginServiceBase.java:139)
at com.actuate.iserver.services.ServiceBase.execute(ServiceBase.java:72)
at
com.actuate.iserver.services.api.idapi.actuate11.ActuateSoapBindingImpl.login(ActuateSoapBindingImpl.java:29)
at
com.actuate.schemas.actuate11.wsdl.ActuateAPIMessageReceiverInOut.invokeBusinessLogic(ActuateAPIMessageReceiverInOut.java:2245)
at
com.actuate.iserver.services.api.idapi.actuate11.ActuateAPIMessageReceiver.invokeBusinessLogic(ActuateAPIMessageReceiver.java:29)
at
org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40)
at
org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:114)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:173)
at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:173)
at
org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:144)
at
com.actuate.webserver.NimbleAxis2Servlet.doPostWrapper(NimbleAxis2Servlet.java:88)
at
com.actuate.ihub.filter.LocalFilter.processRequest(LocalFilter.java:331)
at
com.actuate.ihub.filter.RequestFilter.doFilter(RequestFilter.java:269)
at
com.actuate.ihub.filter.RequestFilterChain.processFilter(RequestFilterChain.java:52)
at
com.actuate.ihub.filter.RequestFilterManager.processFilters(RequestFilterManager.java:264)
at com.actuate.ihub.web.FilterServlet.doRequest(FilterServlet.java:153)
at com.actuate.ihub.web.FilterServlet.doPost(FilterServlet.java:82)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:660)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at
[jira] [Updated] (GEODE-8323) Need to correctly process QueueRemovalMessage during HARegionQueue initialization
[ https://issues.apache.org/jira/browse/GEODE-8323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-8323: Labels: caching-applications (was: ) > Need to correctly process QueueRemovalMessage during HARegionQueue > initialization > - > > Key: GEODE-8323 > URL: https://issues.apache.org/jira/browse/GEODE-8323 > Project: Geode > Issue Type: Bug > Components: client queues >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: caching-applications > > Currently, these events in queue removal message are ignored as the idea is > that correct setting of messageTimeToLive and > subscriptionMessageTrackingTimeout should prevent a previous seen event > replayed on a client. > However, it failover scenario occurs, a restarted/newly joined member could > gii from a secondary HARegionQueue which has those events not removed by the > QRM. As the restarted member starts the timer for messageTimeToLive after it > restarted. The event could live longer than the messageTimeToLive setting if > starts from the original operation time. If this time is longer than the > subscriptionMessageTrackingTimeout setting on the client, the client will not > prevent the replay of the stray event. This could leads to data inconsistency > between client and server. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8323) Need to correctly process QueueRemovalMessage during HARegionQueue initialization
[ https://issues.apache.org/jira/browse/GEODE-8323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu reassigned GEODE-8323: --- Assignee: Eric Shu > Need to correctly process QueueRemovalMessage during HARegionQueue > initialization > - > > Key: GEODE-8323 > URL: https://issues.apache.org/jira/browse/GEODE-8323 > Project: Geode > Issue Type: Bug > Components: client queues >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > > Currently, these events in queue removal message are ignored as the idea is > that correct setting of messageTimeToLive and > subscriptionMessageTrackingTimeout should prevent a previous seen event > replayed on a client. > However, it failover scenario occurs, a restarted/newly joined member could > gii from a secondary HARegionQueue which has those events not removed by the > QRM. As the restarted member starts the timer for messageTimeToLive after it > restarted. The event could live longer than the messageTimeToLive setting if > starts from the original operation time. If this time is longer than the > subscriptionMessageTrackingTimeout setting on the client, the client will not > prevent the replay of the stray event. This could leads to data inconsistency > between client and server. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8323) Need to correctly process QueueRemovalMessage during HARegionQueue initialization
Eric Shu created GEODE-8323: --- Summary: Need to correctly process QueueRemovalMessage during HARegionQueue initialization Key: GEODE-8323 URL: https://issues.apache.org/jira/browse/GEODE-8323 Project: Geode Issue Type: Bug Components: client queues Reporter: Eric Shu Currently, these events in queue removal message are ignored as the idea is that correct setting of messageTimeToLive and subscriptionMessageTrackingTimeout should prevent a previous seen event replayed on a client. However, it failover scenario occurs, a restarted/newly joined member could gii from a secondary HARegionQueue which has those events not removed by the QRM. As the restarted member starts the timer for messageTimeToLive after it restarted. The event could live longer than the messageTimeToLive setting if starts from the original operation time. If this time is longer than the subscriptionMessageTrackingTimeout setting on the client, the client will not prevent the replay of the stray event. This could leads to data inconsistency between client and server. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8273) Cleanup GfshExecution and GfshScript classes in geode-junit
[ https://issues.apache.org/jira/browse/GEODE-8273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund resolved GEODE-8273. -- Fix Version/s: 1.14.0 Resolution: Fixed > Cleanup GfshExecution and GfshScript classes in geode-junit > --- > > Key: GEODE-8273 > URL: https://issues.apache.org/jira/browse/GEODE-8273 > Project: Geode > Issue Type: Wish > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Fix For: 1.14.0 > > > Cleanup GfshExecution and GfshScript classes in geode-junit. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8322) Utilize Boost Library Instead of Platform Dependent Test Code
Michael Martell created GEODE-8322: -- Summary: Utilize Boost Library Instead of Platform Dependent Test Code Key: GEODE-8322 URL: https://issues.apache.org/jira/browse/GEODE-8322 Project: Geode Issue Type: Improvement Components: native client Reporter: Michael Martell The new SNITest.cpp file utilizes #ifdef PLATFORM to launch docker components and also for retrieving the working directory. Although only test code, we should endeavor to leverage standard libraries for all new development. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-8293) activeCQCount has negative value
[
https://issues.apache.org/jira/browse/GEODE-8293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo reassigned GEODE-8293:
-
Assignee: Mario Kevo
> activeCQCount has negative value
>
>
> Key: GEODE-8293
> URL: https://issues.apache.org/jira/browse/GEODE-8293
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
>
> In case you have more than one server in the system and you close CQ there
> will be negative value of active cqs.
> The problem is when you started more than one server and execute cq on it. In
> that case we got incCqsActive on one server, but when it is closed we have
> decCqsActive on both servers.
> {code:java}
> gfsh>show metrics --categories=query
> Cluster-wide MetricsCategory | Metric | Value
> | | -
> query| activeCQCount| 1
> | queryRequestRate | 0.0
> {code}
> After cq is closed or stopped:
> {code:java}
> gfsh>show metrics --categories=query
> Cluster-wide Metrics
> Category | Metric | Value
> | | -
> query| activeCQCount| -1
> | queryRequestRate | 0.0
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8029) java.lang.IllegalArgumentException: Too large (805306401 expected elements with load factor 0.75)
[ https://issues.apache.org/jira/browse/GEODE-8029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148489#comment-17148489 ] ASF GitHub Bot commented on GEODE-8029: --- jujoramos opened a new pull request #5329: URL: https://github.com/apache/geode/pull/5329 Do not delete drf files during member startup as that should be only done by the compactor thread. Instead, allow the OplogEntryIdSet to grow over the default capacity and log a warning message instructing the user to manually compact the disk-stores. - Added unit tests. - Replaced usages of 'junit.Assert' by 'assertj'. - Modified DiskStoreImpl.deadRecordCount to return long instead of int. - Added internal overflow implementation to the OplogEntryIdSet so it can grow above the default limit. Thank you for submitting a contribution to Apache Geode. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [X] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [X] Has your PR been rebased against the latest commit within the target branch (typically `develop`)? - [X] Is your initial contribution a single, squashed commit? - [X] Does `gradlew build` run cleanly? - [X] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? ### Note: Please ensure that once the PR is submitted, check Concourse for build issues and submit an update to your PR as soon as possible. If you need help, please send an email to d...@geode.apache.org. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > java.lang.IllegalArgumentException: Too large (805306401 expected elements > with load factor 0.75) > - > > Key: GEODE-8029 > URL: https://issues.apache.org/jira/browse/GEODE-8029 > Project: Geode > Issue Type: Bug > Components: configuration, core, gfsh >Affects Versions: 1.9.0 >Reporter: Jagadeesh sivasankaran >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons, caching-applications > Attachments: Screen Shot 2020-04-27 at 12.21.19 PM.png, Screen Shot > 2020-04-27 at 12.21.19 PM.png, server02.log > > > we have a cluster of three Locator Geode and three Cache Server running in > CentOS servers. Today (April 27) after patching our CENTOS servers , all > locator and 2 servers came up , But one Cache server was not starting . here > is the Exception details. Please let me know how to resolve the beloe issue > and need any configuration changes to diskstore ? > > > Starting a Geode Server in /app/provServerHO2... > The > Cache Server process terminated unexpectedly with exit status 1. Please > refer to the log file in /app/provServerHO2 for full details. > Exception in thread "main" java.lang.IllegalArgumentException: Too large > (805306401 expected elements with load factor 0.75) > at it.unimi.dsi.fastutil.HashCommon.arraySize(HashCommon.java:222) > at it.unimi.dsi.fastutil.ints.IntOpenHashSet.add(IntOpenHashSet.java:308) > at > org.apache.geode.internal.cache.DiskStoreImpl$OplogEntryIdSet.add(DiskStoreImpl.java:3474) > at org.apache.geode.internal.cache.Oplog.readDelEntry(Oplog.java:3007) > at org.apache.geode.internal.cache.Oplog.recoverDrf(Oplog.java:1500) > at > org.apache.geode.internal.cache.PersistentOplogSet.recoverOplogs(PersistentOplogSet.java:445) > at > org.apache.geode.internal.cache.PersistentOplogSet.recoverRegionsThatAreReady(PersistentOplogSet.java:369) > at > org.apache.geode.internal.cache.DiskStoreImpl.recoverRegionsThatAreReady(DiskStoreImpl.java:2053) > at > org.apache.geode.internal.cache.DiskStoreImpl.initializeIfNeeded(DiskStoreImpl.java:2041) > security-peer-auth-init= > at > org.apache.geode.internal.cache.DiskStoreImpl.doInitialRecovery(DiskStoreImpl.java:2046) > at > org.apache.geode.internal.cache.DiskStoreFactoryImpl.initializeDiskStore(DiskStoreFactoryImpl.java:184) > at >
[jira] [Updated] (GEODE-8029) java.lang.IllegalArgumentException: Too large (805306401 expected elements with load factor 0.75)
[ https://issues.apache.org/jira/browse/GEODE-8029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan Ramos updated GEODE-8029: -- Fix Version/s: (was: 1.14.0) (was: 1.12.1) (was: 1.13.0) > java.lang.IllegalArgumentException: Too large (805306401 expected elements > with load factor 0.75) > - > > Key: GEODE-8029 > URL: https://issues.apache.org/jira/browse/GEODE-8029 > Project: Geode > Issue Type: Bug > Components: configuration, core, gfsh >Affects Versions: 1.9.0 >Reporter: Jagadeesh sivasankaran >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons, caching-applications > Attachments: Screen Shot 2020-04-27 at 12.21.19 PM.png, Screen Shot > 2020-04-27 at 12.21.19 PM.png, server02.log > > > we have a cluster of three Locator Geode and three Cache Server running in > CentOS servers. Today (April 27) after patching our CENTOS servers , all > locator and 2 servers came up , But one Cache server was not starting . here > is the Exception details. Please let me know how to resolve the beloe issue > and need any configuration changes to diskstore ? > > > Starting a Geode Server in /app/provServerHO2... > The > Cache Server process terminated unexpectedly with exit status 1. Please > refer to the log file in /app/provServerHO2 for full details. > Exception in thread "main" java.lang.IllegalArgumentException: Too large > (805306401 expected elements with load factor 0.75) > at it.unimi.dsi.fastutil.HashCommon.arraySize(HashCommon.java:222) > at it.unimi.dsi.fastutil.ints.IntOpenHashSet.add(IntOpenHashSet.java:308) > at > org.apache.geode.internal.cache.DiskStoreImpl$OplogEntryIdSet.add(DiskStoreImpl.java:3474) > at org.apache.geode.internal.cache.Oplog.readDelEntry(Oplog.java:3007) > at org.apache.geode.internal.cache.Oplog.recoverDrf(Oplog.java:1500) > at > org.apache.geode.internal.cache.PersistentOplogSet.recoverOplogs(PersistentOplogSet.java:445) > at > org.apache.geode.internal.cache.PersistentOplogSet.recoverRegionsThatAreReady(PersistentOplogSet.java:369) > at > org.apache.geode.internal.cache.DiskStoreImpl.recoverRegionsThatAreReady(DiskStoreImpl.java:2053) > at > org.apache.geode.internal.cache.DiskStoreImpl.initializeIfNeeded(DiskStoreImpl.java:2041) > security-peer-auth-init= > at > org.apache.geode.internal.cache.DiskStoreImpl.doInitialRecovery(DiskStoreImpl.java:2046) > at > org.apache.geode.internal.cache.DiskStoreFactoryImpl.initializeDiskStore(DiskStoreFactoryImpl.java:184) > at > org.apache.geode.internal.cache.DiskStoreFactoryImpl.create(DiskStoreFactoryImpl.java:150) > at > org.apache.geode.internal.cache.xmlcache.CacheCreation.createDiskStore(CacheCreation.java:794) > at > org.apache.geode.internal.cache.xmlcache.CacheCreation.initializePdxDiskStore(CacheCreation.java:785) > at > org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:509) > at > org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:337) > at > org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4272) > at > org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:197) > at > org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1240) > at > org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1206) > at > org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:207) > at > org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:164) > at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:139) > at > org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52) > at > org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:869) > at org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:786) > at org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:716) > at org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:236) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (GEODE-8029) java.lang.IllegalArgumentException: Too large (805306401 expected elements with load factor 0.75)
[ https://issues.apache.org/jira/browse/GEODE-8029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Juan Ramos reopened GEODE-8029: --- Re-opening the ticket as the fix has proven to be insufficient to solve the problem. > java.lang.IllegalArgumentException: Too large (805306401 expected elements > with load factor 0.75) > - > > Key: GEODE-8029 > URL: https://issues.apache.org/jira/browse/GEODE-8029 > Project: Geode > Issue Type: Bug > Components: configuration, core, gfsh >Affects Versions: 1.9.0 >Reporter: Jagadeesh sivasankaran >Assignee: Juan Ramos >Priority: Major > Labels: GeodeCommons, caching-applications > Fix For: 1.12.1, 1.13.0, 1.14.0 > > Attachments: Screen Shot 2020-04-27 at 12.21.19 PM.png, Screen Shot > 2020-04-27 at 12.21.19 PM.png, server02.log > > > we have a cluster of three Locator Geode and three Cache Server running in > CentOS servers. Today (April 27) after patching our CENTOS servers , all > locator and 2 servers came up , But one Cache server was not starting . here > is the Exception details. Please let me know how to resolve the beloe issue > and need any configuration changes to diskstore ? > > > Starting a Geode Server in /app/provServerHO2... > The > Cache Server process terminated unexpectedly with exit status 1. Please > refer to the log file in /app/provServerHO2 for full details. > Exception in thread "main" java.lang.IllegalArgumentException: Too large > (805306401 expected elements with load factor 0.75) > at it.unimi.dsi.fastutil.HashCommon.arraySize(HashCommon.java:222) > at it.unimi.dsi.fastutil.ints.IntOpenHashSet.add(IntOpenHashSet.java:308) > at > org.apache.geode.internal.cache.DiskStoreImpl$OplogEntryIdSet.add(DiskStoreImpl.java:3474) > at org.apache.geode.internal.cache.Oplog.readDelEntry(Oplog.java:3007) > at org.apache.geode.internal.cache.Oplog.recoverDrf(Oplog.java:1500) > at > org.apache.geode.internal.cache.PersistentOplogSet.recoverOplogs(PersistentOplogSet.java:445) > at > org.apache.geode.internal.cache.PersistentOplogSet.recoverRegionsThatAreReady(PersistentOplogSet.java:369) > at > org.apache.geode.internal.cache.DiskStoreImpl.recoverRegionsThatAreReady(DiskStoreImpl.java:2053) > at > org.apache.geode.internal.cache.DiskStoreImpl.initializeIfNeeded(DiskStoreImpl.java:2041) > security-peer-auth-init= > at > org.apache.geode.internal.cache.DiskStoreImpl.doInitialRecovery(DiskStoreImpl.java:2046) > at > org.apache.geode.internal.cache.DiskStoreFactoryImpl.initializeDiskStore(DiskStoreFactoryImpl.java:184) > at > org.apache.geode.internal.cache.DiskStoreFactoryImpl.create(DiskStoreFactoryImpl.java:150) > at > org.apache.geode.internal.cache.xmlcache.CacheCreation.createDiskStore(CacheCreation.java:794) > at > org.apache.geode.internal.cache.xmlcache.CacheCreation.initializePdxDiskStore(CacheCreation.java:785) > at > org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:509) > at > org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:337) > at > org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4272) > at > org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:197) > at > org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1240) > at > org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1206) > at > org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:207) > at > org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:164) > at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:139) > at > org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52) > at > org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:869) > at org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:786) > at org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:716) > at org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:236) > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8302) WAN Conflation stats are being incorrectly incremented
[
https://issues.apache.org/jira/browse/GEODE-8302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148357#comment-17148357
]
ASF GitHub Bot commented on GEODE-8302:
---
albertogpz commented on pull request #5313:
URL: https://github.com/apache/geode/pull/5313#issuecomment-651582218
> @albertogpz Good material - thanks for writing the docs for this feature.
> I have some edits for clarification and consistency, in both user guide
files and the javadoc comments in class files. I will send these to you in
email for you to incorporate as you see fit. Thanks!
Thanks for the review, Dave. I have accepted all your proposals with the
exception of the javadoc on ```GatewaySenderQueue.java``` which had not ended
up describing correctly the ```peekedIdsWithoutExtra``` member variable. I
changed it to a simpler sentence. Let me know if you are ok with the change.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> WAN Conflation stats are being incorrectly incremented
> --
>
> Key: GEODE-8302
> URL: https://issues.apache.org/jira/browse/GEODE-8302
> Project: Geode
> Issue Type: Bug
> Components: statistics, wan
>Affects Versions: 1.14.0
>Reporter: Donal Evans
>Assignee: Alberto Gomez
>Priority: Major
>
> When the below diff (which adds checks to confirm that conflation stats are
> not incremented in WAN tests with conflation disabled) is applied, the
> modified tests fail due to conflation stats being incorrectly incremented.
> This behaviour is only observed since the changes included in this PR were
> introduced: https://github.com/apache/geode/pull/4928
> {noformat}
> diff --git
> a/geode-wan/src/distributedTest/java/org/apache/geode/internal/cache/wan/serial/SerialWANStatsDUnitTest.java
>
> b/geode-wan/src/distributedTest/java/org/apache/geode/internal/cache/wan/serial/SerialWANStatsDUnitTest.java
> index b2ed76728f..bc6beb0002 100644
> ---
> a/geode-wan/src/distributedTest/java/org/apache/geode/internal/cache/wan/serial/SerialWANStatsDUnitTest.java
> +++
> b/geode-wan/src/distributedTest/java/org/apache/geode/internal/cache/wan/serial/SerialWANStatsDUnitTest.java
> @@ -209,6 +209,7 @@ public class SerialWANStatsDUnitTest extends WANTestBase {
>
> vm4.invoke(() -> WANTestBase.checkQueueStats("ln", 0, entries, entries,
> entries));
> vm4.invoke(() -> WANTestBase.checkBatchStats("ln", 1, true));
> +vm4.invoke(() -> WANTestBase.checkConflatedStats("ln", 0));
>
> // wait until queue is empty
> vm5.invoke(() -> await()
> @@ -354,6 +355,7 @@ public class SerialWANStatsDUnitTest extends WANTestBase {
>
> vm4.invoke(() -> WANTestBase.checkQueueStats("ln", 0, entries, entries,
> entries));
> vm4.invoke(() -> WANTestBase.checkBatchStats("ln", 2, true, true));
> +vm4.invoke(() -> WANTestBase.checkConflatedStats("ln", 0));
>
> // wait until queue is empty
> vm5.invoke(() -> await()
> {noformat}
> In addition to the tests above,
> SerialWANPropagation_PartitionedRegionDUnitTest.testPartitionedSerialPropagationHA()
> fails with incorrectly incremented conflation stats if a similar check is
> introduced at the end of the test. Again, without the changes introduced by
> PR #4928, this modified test passes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-8240) View has old locator version number after rolling upgrade
[
https://issues.apache.org/jira/browse/GEODE-8240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17148340#comment-17148340
]
ASF GitHub Bot commented on GEODE-8240:
---
albertogpz commented on a change in pull request #5273:
URL: https://github.com/apache/geode/pull/5273#discussion_r447434620
##
File path:
geode-core/src/upgradeTest/java/org/apache/geode/internal/cache/rollingupgrade/RollingUpgradeDUnitTest.java
##
@@ -191,20 +207,26 @@ void doTestRollAll(String regionType, String objectType,
String startingVersion)
}
putAndVerify(objectType, server1, regionName, 0, 10, server2);
- locator = rollLocatorToCurrent(locator, hostName, locatorPorts[0],
getTestMethodName(),
- locatorString);
+ locator =
+ rollLocatorToCurrent(locator, hostName, locatorPort, locatorProps,
getTestMethodName(),
+ locatorString);
server1 = rollServerToCurrentAndCreateRegion(server1, regionType,
testingDirs[0],
- shortcutName, regionName, locatorPorts);
+ shortcutName, regionName, new int[] {locatorPort});
verifyValues(objectType, regionName, 0, 10, server1);
putAndVerify(objectType, server1, regionName, 5, 15, server2);
putAndVerify(objectType, server2, regionName, 10, 20, server1);
server2 = rollServerToCurrentAndCreateRegion(server2, regionType,
testingDirs[1],
- shortcutName, regionName, locatorPorts);
+ shortcutName, regionName, ports);
verifyValues(objectType, regionName, 0, 10, server2);
putAndVerify(objectType, server2, regionName, 15, 25, server1);
+ String shutDownCommand = "shutdown --include-locators=true";
Review comment:
Overall, great work. Thanks, Bill.
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> View has old locator version number after rolling upgrade
> -
>
> Key: GEODE-8240
> URL: https://issues.apache.org/jira/browse/GEODE-8240
> Project: Geode
> Issue Type: Bug
> Components: client/server, membership
>Reporter: Ernest Burghardt
>Assignee: Bill Burcham
>Priority: Major
>
> as shown in [https://github.com/apache/geode/pull/5224]
> locator upgrade from version 1.12.0 doesn't seem to occur
> {{testRollServersOnPartitionedRegion_dataserializable}} failure results:
> Expecting:
> <"Member Count : 3
> Name | Id
> |
> ---
> vm2 | 127.0.0.1(vm2:35019:locator):41000(version:GEODE 1.12.0)
> [Coordinator]
> vm0 | 10.0.0.111(vm0:35025):41001
> vm1 | 10.0.0.111(vm1:35030):41002
> ">
> not to contain:
> <"1.12.0">
> This problem was introduced in 1.12.0 and is present in all lines derived
> from that one, including 9.10, 1.13, and current develop/1.14
> What's actually happening is that the locator _is_ upgraded to a newer
> version. It joins with an older coordinator (that's running e.g. 1.12.0) and
> that coordinator produces a view showing the new locator/member as running
> the same version, in this case 1.12.0, as the coordinator.
> Eventually, all locators will be upgraded. But the view carries the incorrect
> version indication.
> The root cause seems to be that when {{GMSMemberData.setVersionObject(short
> versionOrdinal)}} sees a version ordinal that is unknown, i.e. a version
> ordinal corresponding to a new line of development: 1.13, 1.14, … that method
> throws away that version ordinal and replaces it with the one for the 1.12
> line.
> Since the current {{support/1.13}} and {{develop}} branches have the bug
> upgrading a current 1.13 to 1.14 or a current development/1.14 to 1.15 would
> exhibit the same behavior (locator apparently stuck at the older version in
> the view.)
> Ramifications of this incorrect version indication in the view are TBD.
> Whether or not this situation resolves itself after _another_ round of
> restarts is TBD.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
