[jira] [Resolved] (GEODE-5087) SerialGatewaySenderOperationsDUnitTest.testRestartSerialGatewaySendersWhilePutting intermittently fail
[ https://issues.apache.org/jira/browse/GEODE-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] xiaojian zhou resolved GEODE-5087. -- Resolution: Fixed Fix Version/s: 1.7.0 > SerialGatewaySenderOperationsDUnitTest.testRestartSerialGatewaySendersWhilePutting > intermittently fail > --- > > Key: GEODE-5087 > URL: https://issues.apache.org/jira/browse/GEODE-5087 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: xiaojian zhou >Assignee: xiaojian zhou >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > I introduced this dunit test for GEODE-4942, while GEODE-4942 is for parallel > gateway sender, the test is for serial gateway sender. And I did reproduce > the issue: event is dropped at primary sender (because it's not running yet), > but event has been put into unprocessedEventsMap at secondary sender's queue > and will stay there forever. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5087) SerialGatewaySenderOperationsDUnitTest.testRestartSerialGatewaySendersWhilePutting intermittently fail
[ https://issues.apache.org/jira/browse/GEODE-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472852#comment-16472852 ] ASF subversion and git services commented on GEODE-5087: Commit 5c378931c672d695f168d2aca0848664cb4c2f2f in geode's branch refs/heads/develop from Xiaojian Zhou [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5c37893 ] GEODE-5087: send a BatchDestroyOperation for each dropped event at serial primary sender (#1924) > SerialGatewaySenderOperationsDUnitTest.testRestartSerialGatewaySendersWhilePutting > intermittently fail > --- > > Key: GEODE-5087 > URL: https://issues.apache.org/jira/browse/GEODE-5087 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: xiaojian zhou >Assignee: xiaojian zhou >Priority: Major > Labels: pull-request-available > Time Spent: 1h 40m > Remaining Estimate: 0h > > I introduced this dunit test for GEODE-4942, while GEODE-4942 is for parallel > gateway sender, the test is for serial gateway sender. And I did reproduce > the issue: event is dropped at primary sender (because it's not running yet), > but event has been put into unprocessedEventsMap at secondary sender's queue > and will stay there forever. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5209) Code Coverage Integration
Ryan McMahon created GEODE-5209: --- Summary: Code Coverage Integration Key: GEODE-5209 URL: https://issues.apache.org/jira/browse/GEODE-5209 Project: Geode Issue Type: Test Components: native client Reporter: Ryan McMahon _As_ a Geode-Native contributor/developer _I want to_ use code coverage tools _So that_ see what code is currently covered by our unit and integration tests We will want to add this to CMake so we can run code coverage analysis on demand. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5203) User Guide - clarify that client SSL setting descriptions are for Java clients only
[ https://issues.apache.org/jira/browse/GEODE-5203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472802#comment-16472802 ] ASF subversion and git services commented on GEODE-5203: Commit 07ef1fa9989d3c8e976511df72220062e436cfa0 in geode's branch refs/heads/develop from [~dbarnes97] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=07ef1fa ] GEODE-5203: User Guide - clarify that client SSL setting descriptions are for Java clients only > User Guide - clarify that client SSL setting descriptions are for Java > clients only > --- > > Key: GEODE-5203 > URL: https://issues.apache.org/jira/browse/GEODE-5203 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > In Managing -> Security -> SSL -> Configuring SSL, the explanation of SSL > settings for clients applies only to Java clients. > Settings for C++ or .NET clients (developed using the in-the-works > geode-native API) may differ from the Java settings. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5207) Document that extensions dir is in CLASSPATH
[ https://issues.apache.org/jira/browse/GEODE-5207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5207: -- Labels: pull-request-available (was: ) > Document that extensions dir is in CLASSPATH > > > Key: GEODE-5207 > URL: https://issues.apache.org/jira/browse/GEODE-5207 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > > gfsh got updated so that upon server/locator start, any JAR files in the > extensions/ directory would be automatically included on the classpath. This > work was done in GEODE-4923. This ticket exists to document the change. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5208) Remove test hooks from TypeRegistration classes
[ https://issues.apache.org/jira/browse/GEODE-5208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan updated GEODE-5208: Summary: Remove test hooks from TypeRegistration classes (was: Remove test hooks from TypeRegistry and TypeRegistration classes) > Remove test hooks from TypeRegistration classes > --- > > Key: GEODE-5208 > URL: https://issues.apache.org/jira/browse/GEODE-5208 > Project: Geode > Issue Type: Sub-task > Components: membership >Reporter: Galen O'Sullivan >Priority: Major > > PeerTypeRegistration has lastAllocatedTypeId and > lastAllocatedEnumId. These are used on other methods, even put on interfaces, > but never actually used by tests. There's also > LonerTypeRegistration.testClearRegistry, which is never used. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5208) Remove test hooks from TypeRegistry and TypeRegistration classes
Galen O'Sullivan created GEODE-5208: --- Summary: Remove test hooks from TypeRegistry and TypeRegistration classes Key: GEODE-5208 URL: https://issues.apache.org/jira/browse/GEODE-5208 Project: Geode Issue Type: Sub-task Components: membership Reporter: Galen O'Sullivan PeerTypeRegistration has lastAllocatedTypeId and lastAllocatedEnumId. These are used on other methods, even put on interfaces, but never actually used by tests. There's also LonerTypeRegistration.testClearRegistry, which is never used. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5160) Remove test hooks from o.a.g.d.i.membership.gms.interfaces.Service
[
https://issues.apache.org/jira/browse/GEODE-5160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan updated GEODE-5160:
Issue Type: Sub-task (was: Improvement)
Parent: GEODE-3652
> Remove test hooks from o.a.g.d.i.membership.gms.interfaces.Service
> --
>
> Key: GEODE-5160
> URL: https://issues.apache.org/jira/browse/GEODE-5160
> Project: Geode
> Issue Type: Sub-task
> Components: membership
>Reporter: Galen O'Sullivan
>Priority: Major
>
> Service has the following methods:
> {code}
> /**
>* test method for simulating a sick/dead member
>*/
> void beSick();
> /**
>* test method for simulating a sick/dead member
>*/
> void playDead();
> /**
>* test method for simulating a sick/dead member
>*/
> void beHealthy();
> {code}
> It doesn't make sense for all services to have to implement these, especially
> since most services make these a no-op. Let's cast where we know what we're
> looking for instead.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5173) Transactional get from a client on a REPLICATE_HEAP_LRU region throws NotSerializableException
[
https://issues.apache.org/jira/browse/GEODE-5173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu resolved GEODE-5173.
-
Resolution: Fixed
> Transactional get from a client on a REPLICATE_HEAP_LRU region throws
> NotSerializableException
> --
>
> Key: GEODE-5173
> URL: https://issues.apache.org/jira/browse/GEODE-5173
> Project: Geode
> Issue Type: Bug
> Components: persistence, transactions
>Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1, 1.4.0, 1.5.0, 1.6.0
>Reporter: Dan Smith
>Assignee: Eric Shu
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Doing a get from a client within a transaction on a region with persistence
> and overflow results in the below exception.
> It looks like this issue has to do with some code returning a
> Token.NOT_AVAILABLE rather than reading the value from disk if the get is
> performed within a transaction. Without using transactions, this same use
> case works:
>
> {noformat}
> Caused by: org.apache.geode.cache.client.ServerOperationException: remote
> server on 10.1.10.126(15995:loner):34188:40be7322:
> org.apache.geode.SerializationException: failed serializing object
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:680)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:739)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:622)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnServer(OpExecutorImpl.java:384)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithServerAffinity(OpExecutorImpl.java:231)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:140)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:127)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:782)
> at org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:91)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:113)
> at
> org.apache.geode.internal.cache.tx.ClientTXRegionStub.findObject(ClientTXRegionStub.java:72)
> at
> org.apache.geode.internal.cache.TXStateStub.findObject(TXStateStub.java:472)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.findObject(TXStateProxyImpl.java:536)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1400)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1334)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1319)
> at
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:408)
> at
> org.apache.geode.internal.cache.ClientPersistentTransactionDUnitTest.lambda$test$2c6907a2$1(ClientPersistentTransactionDUnitTest.java:75)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at hydra.MethExecutor.executeObject(MethExecutor.java:244)
> at
> org.apache.geode.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:70)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:361)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
> at
>
[jira] [Commented] (GEODE-5173) Transactional get from a client on a REPLICATE_HEAP_LRU region throws NotSerializableException
[
https://issues.apache.org/jira/browse/GEODE-5173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472781#comment-16472781
]
ASF subversion and git services commented on GEODE-5173:
Commit 52bdb96e7c073ed623f4f53e1e6083f849bf2863 in geode's branch
refs/heads/develop from [~eshu]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=52bdb96 ]
Feature/geode 5173 1 (#1948)
* GEODE-5173: Transaction will fault in value if value is Token.NOT_AVAILABLE
or isEvicted.
> Transactional get from a client on a REPLICATE_HEAP_LRU region throws
> NotSerializableException
> --
>
> Key: GEODE-5173
> URL: https://issues.apache.org/jira/browse/GEODE-5173
> Project: Geode
> Issue Type: Bug
> Components: persistence, transactions
>Affects Versions: 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1, 1.4.0, 1.5.0, 1.6.0
>Reporter: Dan Smith
>Assignee: Eric Shu
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Doing a get from a client within a transaction on a region with persistence
> and overflow results in the below exception.
> It looks like this issue has to do with some code returning a
> Token.NOT_AVAILABLE rather than reading the value from disk if the get is
> performed within a transaction. Without using transactions, this same use
> case works:
>
> {noformat}
> Caused by: org.apache.geode.cache.client.ServerOperationException: remote
> server on 10.1.10.126(15995:loner):34188:40be7322:
> org.apache.geode.SerializationException: failed serializing object
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:680)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:739)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.handleException(OpExecutorImpl.java:622)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnServer(OpExecutorImpl.java:384)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithServerAffinity(OpExecutorImpl.java:231)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:140)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:127)
> at
> org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:782)
> at org.apache.geode.cache.client.internal.GetOp.execute(GetOp.java:91)
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.get(ServerRegionProxy.java:113)
> at
> org.apache.geode.internal.cache.tx.ClientTXRegionStub.findObject(ClientTXRegionStub.java:72)
> at
> org.apache.geode.internal.cache.TXStateStub.findObject(TXStateStub.java:472)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.findObject(TXStateProxyImpl.java:536)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1400)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1334)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1319)
> at
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:408)
> at
> org.apache.geode.internal.cache.ClientPersistentTransactionDUnitTest.lambda$test$2c6907a2$1(ClientPersistentTransactionDUnitTest.java:75)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at hydra.MethExecutor.executeObject(MethExecutor.java:244)
> at
> org.apache.geode.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:70)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:361)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> at
>
[jira] [Commented] (GEODE-4728) Geode Native Documentation Improvements
[ https://issues.apache.org/jira/browse/GEODE-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472766#comment-16472766 ] ASF subversion and git services commented on GEODE-4728: Commit ac96e697bdc7fc209db06df56d70d238a40856b4 in geode-native's branch refs/heads/develop from [~dbarnes97] [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=ac96e69 ] GEODE-4728: Docs - SSL configuration, incorporate reviewer feedback > Geode Native Documentation Improvements > --- > > Key: GEODE-4728 > URL: https://issues.apache.org/jira/browse/GEODE-4728 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Addison >Priority: Major > Labels: pull-request-available > Time Spent: 2h 40m > Remaining Estimate: 0h > > This ticket will capture a series of changes to the Geode Native docs to > bring them inline with the updated API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5207) Document that extensions dir is in CLASSPATH
Karen Smoler Miller created GEODE-5207: -- Summary: Document that extensions dir is in CLASSPATH Key: GEODE-5207 URL: https://issues.apache.org/jira/browse/GEODE-5207 Project: Geode Issue Type: Improvement Components: docs Reporter: Karen Smoler Miller gfsh got updated so that upon server/locator start, any JAR files in the extensions/ directory would be automatically included on the classpath. This work was done in GEODE-4923. This ticket exists to document the change. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4728) Geode Native Documentation Improvements
[ https://issues.apache.org/jira/browse/GEODE-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472757#comment-16472757 ] ASF subversion and git services commented on GEODE-4728: Commit 6aede67c20ea1856e2d545ad512a424787a5daee in geode-native's branch refs/heads/develop from [~dbarnes97] [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=6aede67 ] GEODE-4728: Docs - SSL configuration > Geode Native Documentation Improvements > --- > > Key: GEODE-4728 > URL: https://issues.apache.org/jira/browse/GEODE-4728 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Addison >Priority: Major > Labels: pull-request-available > Time Spent: 2h 40m > Remaining Estimate: 0h > > This ticket will capture a series of changes to the Geode Native docs to > bring them inline with the updated API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-3845) Distributed destroy for replicated region
[
https://issues.apache.org/jira/browse/GEODE-3845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Vallely updated GEODE-3845:
Summary: Distributed destroy for replicated region (was: As a user, I want
to be able to do a distributed destroy action from a local region)
> Distributed destroy for replicated region
> -
>
> Key: GEODE-3845
> URL: https://issues.apache.org/jira/browse/GEODE-3845
> Project: Geode
> Issue Type: New Feature
> Components: docs, eviction
>Reporter: Masaki Yamakawa
>Priority: Major
>
> I use entry-idle-time and eviction together in a partition region that holds
> one redundant copy.
> Details of setting are as follows:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
> {code}
> In this setting, the data held by the cache server is different. Then,
> inconsistent results are returned depending on the server to be connected.
> Eviction of the partition region can only select local-destroy or
> overflow-to-disk. On the other hand, it is written that the expire chapter of
> the document can not use local-destroy, local-invalidate in the partition
> region. Likewise, I think that data inconsistency will occur even with the
> settings like this time.
> Below is the test code:
> [https://github.com/masaki-yamakawa/geode/blob/bug-partition-local-destroy/geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/BugExpireAndEvictionDUnitTest.java]
> I think that it is necessary to add a check at the time of region creation or
> write it in the document.
>
> **
> Problem: currently eviction-action must be either 'local-destroy' or
> 'overflow-to-disk'
> ex:
> Solution: This story is to add the additional option "distributed-destroy" as
> an action setting for expiration-attributes.
> This will enable a local destroy action to be distributed across the cluster
> (currently this does not exist)
>
> Acceptance: can set this on region configuration via cache.xml, API or gfsh
> gfsh help and docs have been updated
>
> +Story: Add Option+
> Given I want data consistency across a distributed replicated region
> When I go to set an eviction action
> Then I should have the ability to specify one of the following actions:
> * 'local-destroy' [Default action]
> * 'none'
> * 'overflow-to-disk'
> * 'distributed-destroy' (NEW option)
>
> +Story: Behavior+
>
> Given I have a region expiration action set in the system to
> 'distributed-destroy'
> When an eviction event based on [mem%, count, regionSize, time] occurs to
> destroy entries
> Then the system will destroy the same entries in any region where they exist
> across the distributed environment
>
> +Story: Configuring cache.xml+
> Given I am configuring a system with replicated regions
> When I setup my cache.xml
> Then I have the ability to add a 'destributed–destroy' action value for the
> following tags:
> *
> *
>
>
> +Story: Spring Data Gemfire+
> Given I am configuring a system with replicated regions
> when I setup my region's eviction action through Spring Data Gemfire
> Then I need the ability to specify the value of 'distributed-destroy'
>
> +Story : Documentation+
> Given I am looking for help for region configuration
> When I look at the help documentation for 'Configure Data Eviction'
> Then I should see details under the 'Decide what action to take when the
> limit is reached' section for 'Distributed Destroy'
>
> +Story: GFSH Create region+
> GIVEN I want to create a new region with distributed-destroy eviction-action
> through GFSH CLI
> WHEN I use the command
> {code:java}
> create region{code}
> THEN I have the optional parameter of
> {code:java}
> --eviction-action=distributed-destroy{code}
> AND the API utilized by GFSH is updated to support this value for create
> region
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5206) Add an 'ignoreFailure' flag to CliFunctionResult
Jens Deppe created GEODE-5206:
-
Summary: Add an 'ignoreFailure' flag to CliFunctionResult
Key: GEODE-5206
URL: https://issues.apache.org/jira/browse/GEODE-5206
Project: Geode
Issue Type: Improvement
Components: gfsh
Reporter: Jens Deppe
Various commands have the ability to be idempotent with a {{--skip-if-exists}}
(typically creation) or {{\-\-if-exists}} (typically deletion). This flag is
passed to the function performing the actual work. With new cluster config
POJOs we want to have the functions *only* accept the POJO as an argument. To
that end the function should be able to set this new flag if the action fails
because of a missing or already existing component. It will then be up to the
command to process the returned {{CliFunctionResult}} to determine what to
present to the user.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-3845) As a user, I want to be able to do a distributed destroy action from a local region
[
https://issues.apache.org/jira/browse/GEODE-3845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Vallely updated GEODE-3845:
Description:
I use entry-idle-time and eviction together in a partition region that holds
one redundant copy.
Details of setting are as follows:
{code:xml}
{code}
In this setting, the data held by the cache server is different. Then,
inconsistent results are returned depending on the server to be connected.
Eviction of the partition region can only select local-destroy or
overflow-to-disk. On the other hand, it is written that the expire chapter of
the document can not use local-destroy, local-invalidate in the partition
region. Likewise, I think that data inconsistency will occur even with the
settings like this time.
Below is the test code:
[https://github.com/masaki-yamakawa/geode/blob/bug-partition-local-destroy/geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/BugExpireAndEvictionDUnitTest.java]
I think that it is necessary to add a check at the time of region creation or
write it in the document.
**
Problem: currently eviction-action must be either 'local-destroy' or
'overflow-to-disk'
ex:
Solution: This story is to add the additional option "distributed-destroy" as
an action setting for expiration-attributes.
This will enable a local destroy action to be distributed across the cluster
(currently this does not exist)
Acceptance: can set this on region configuration via cache.xml, API or gfsh
gfsh help and docs have been updated
+Story: Add Option+
Given I want data consistency across a distributed replicated region
When I go to set an eviction action
Then I should have the ability to specify one of the following actions:
* 'local-destroy' [Default action]
* 'none'
* 'overflow-to-disk'
* 'distributed-destroy' (NEW option)
+Story: Behavior+
Given I have a region expiration action set in the system to
'distributed-destroy'
When an eviction event based on [mem%, count, regionSize, time] occurs to
destroy entries
Then the system will destroy the same entries in any region where they exist
across the distributed environment
+Story: Configuring cache.xml+
Given I am configuring a system with replicated regions
When I setup my cache.xml
Then I have the ability to add a 'destributed–destroy' action value for the
following tags:
*
*
+Story: Spring Data Gemfire+
Given I am configuring a system with replicated regions
when I setup my region's eviction action through Spring Data Gemfire
Then I need the ability to specify the value of 'distributed-destroy'
+Story : Documentation+
Given I am looking for help for region configuration
When I look at the help documentation for 'Configure Data Eviction'
Then I should see details under the 'Decide what action to take when the limit
is reached' section for 'Distributed Destroy'
+Story: GFSH Create region+
GIVEN I want to create a new region with distributed-destroy eviction-action
through GFSH CLI
WHEN I use the command
{code:java}
create region{code}
THEN I have the optional parameter of
{code:java}
--eviction-action=distributed-destroy{code}
AND the API utilized by GFSH is updated to support this value for create region
was:
I use entry-idle-time and eviction together in a partition region that holds
one redundant copy.
Details of setting are as follows:
{code:xml}
{code}
In this setting, the data held by the cache server is different. Then,
inconsistent results are returned depending on the server to be connected.
Eviction of the partition region can only select local-destroy or
overflow-to-disk. On the other hand, it is written that the expire chapter of
the document can not use local-destroy, local-invalidate in the partition
region. Likewise, I think that data inconsistency will occur even with the
settings like this time.
Below is the test code:
[https://github.com/masaki-yamakawa/geode/blob/bug-partition-local-destroy/geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/BugExpireAndEvictionDUnitTest.java]
I think that it is necessary to add a check at the time of region creation or
write it in the document.
**
Problem: currently eviction-action must be either 'local-destroy' or
'overflow-to-disk'
ex:
Solution: This story is to add the additional option "distributed-destroy" as
an action setting for expiration-attributes.
This will enable a local destroy action to be distributed across the cluster
(currently this does not exist)
Acceptance: can set this on region configuration via cache.xml, API or gfsh
gfsh help and docs have been updated
+Story: Add Option+
Given I want data consistency across a distributed replicated region
When I go to set an eviction action
Then I should have the ability to specify
[jira] [Updated] (GEODE-3845) As a user, I want to be able to do a distributed destroy action from a local region
[
https://issues.apache.org/jira/browse/GEODE-3845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Vallely updated GEODE-3845:
Description:
I use entry-idle-time and eviction together in a partition region that holds
one redundant copy.
Details of setting are as follows:
{code:xml}
{code}
In this setting, the data held by the cache server is different. Then,
inconsistent results are returned depending on the server to be connected.
Eviction of the partition region can only select local-destroy or
overflow-to-disk. On the other hand, it is written that the expire chapter of
the document can not use local-destroy, local-invalidate in the partition
region. Likewise, I think that data inconsistency will occur even with the
settings like this time.
Below is the test code:
[https://github.com/masaki-yamakawa/geode/blob/bug-partition-local-destroy/geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/BugExpireAndEvictionDUnitTest.java]
I think that it is necessary to add a check at the time of region creation or
write it in the document.
**
Problem: currently eviction-action must be either 'local-destroy' or
'overflow-to-disk'
ex:
Solution: This story is to add the additional option "distributed-destroy" as
an action setting for expiration-attributes.
This will enable a local destroy action to be distributed across the cluster
(currently this does not exist)
Acceptance: can set this on region configuration via cache.xml, API or gfsh
gfsh help and docs have been updated
+Story: Add Option+
Given I want data consistency across a distributed replicated region
When I go to set an eviction action
Then I should have the ability to specify one of the following actions:
* 'local-destroy' [Default action]
* 'none'
* 'overflow-to-disk'
* 'distributed-destroy' (NEW option)
+Story: Behavior+
Given I have a region expiration action set in the system to
'distributed-destroy'
When an eviction event based on [mem%, count, regionSize, time] occurs to
destroy entries
Then the system will destroy the same entries in any region where they exist
across the distributed environment
+Story: Configuring cache.xml+
Given I am configuring a system with replicated regions
When I setup my cache.xml
Then I have the ability to add a 'destributed–destroy' action value for the
following tags:
*
*
+Story: Spring Data Gemfire+
Given I am configuring a system with replicated regions
when I setup my region's eviction action through Spring Data Gemfire
Then I need the ability to specify the value of 'distributed-destroy'
+Story : Documentation+
Given I am looking for help for region configuration
When I look at the help documentation for 'Configure Data Eviction'
Then I should see details under the 'Decide what action to take when the limit
is reached' section for 'Distributed Destroy'
+Story: GFSH Create region+
GIVEN I want to create a new region with distributed-destroy eviction-action
through GFSH CLI
WHEN I use the command
{code:java}
create region{code}
THEN I have the optional parameter of
{code:java}
--eviction-action=distributed-destroy{code}
AND the API utilized by GFSH is updated to support this value for create region
Open questions?
+Story:+ Mutable Region
* Should we support modification of region?
+Story:+ Create replicated region one with local-destroy and one with
distributed-destroy, is this possible?
+Story: Region-wide override+
Given I want to create an customExpire class to override existing region
expiration actions
When I create a custom expiration class that implements
'org.apache.geode.cache.CustomExpiry' documented
[here|https://gemfire.docs.pivotal.io/95/geode/developing/expiration/configuring_data_expiration.html]
Then I can use the 'DISTRIBUTED-DESTROY' expiration action
{code:java}
private static final ExpirationAttribute CUSTOM_EXPIRY =
new ExpirationAttributes(10, ExpirationAction.DISTRIBUTED_DESTROY);{code}
was:
I use entry-idle-time and eviction together in a partition region that holds
one redundant copy.
Details of setting are as follows:
{code:xml}
{code}
In this setting, the data held by the cache server is different. Then,
inconsistent results are returned depending on the server to be connected.
Eviction of the partition region can only select local-destroy or
overflow-to-disk. On the other hand, it is written that the expire chapter of
the document can not use local-destroy, local-invalidate in the partition
region. Likewise, I think that data inconsistency will occur even with the
settings like this time.
Below is the test code:
[https://github.com/masaki-yamakawa/geode/blob/bug-partition-local-destroy/geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/BugExpireAndEvictionDUnitTest.java]
[jira] [Updated] (GEODE-5144) CI failure: org.apache.geode.internal.cache.wan.serial.SerialWANPropagationsFeatureDUnitTest > testReplicatedSerialPropagationWithFilter
[
https://issues.apache.org/jira/browse/GEODE-5144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xiaojian zhou updated GEODE-5144:
-
Fix Version/s: 1.7.0
> CI failure:
> org.apache.geode.internal.cache.wan.serial.SerialWANPropagationsFeatureDUnitTest
> > testReplicatedSerialPropagationWithFilter
>
>
> Key: GEODE-5144
> URL: https://issues.apache.org/jira/browse/GEODE-5144
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.6.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: xiaojian zhou
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This failure occurred during CI:
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/release-1.6.0/jobs/DistributedTest/builds/12
> {noformat}
> org.apache.geode.internal.cache.wan.serial.SerialWANPropagationsFeatureDUnitTest
> > testReplicatedSerialPropagationWithFilter FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 3199
> [error 2018/04/26 03:50:06.755 UTC 172.17.0.5(414):32774 shared ordered uid=20 port=60094> tid=309]
> Exception occurred in CacheListener
> java.util.concurrent.RejectedExecutionException: Task
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor$2@471694c6
> rejected from java.util.concurrent.ThreadPoolExecutor@c955b3b[Shutting down,
> pool size = 1, active threads = 0, queued tasks = 0, completed tasks = 1778]
> at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.handlePrimaryDestroy(SerialGatewaySenderEventProcessor.java:611)
> at
> org.apache.geode.internal.cache.wan.serial.SerialSecondaryGatewayListener.afterDestroy(SerialSecondaryGatewayListener.java:91)
> at
> org.apache.geode.internal.cache.EnumListenerEvent$AFTER_DESTROY.dispatchEvent(EnumListenerEvent.java:151)
> at
> org.apache.geode.internal.cache.LocalRegion.dispatchEvent(LocalRegion.java:8468)
> at
> org.apache.geode.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:6969)
> at
> org.apache.geode.internal.cache.LocalRegion.invokeDestroyCallbacks(LocalRegion.java:6778)
> at
> org.apache.geode.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2381)
> at
> org.apache.geode.internal.cache.entries.AbstractRegionEntry.dispatchListenerEvents(AbstractRegionEntry.java:170)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroyPart2(LocalRegion.java:6717)
> at
> org.apache.geode.internal.cache.map.RegionMapDestroy.destroyExistingEntry(RegionMapDestroy.java:409)
> at
> org.apache.geode.internal.cache.map.RegionMapDestroy.handleExistingRegionEntry(RegionMapDestroy.java:238)
> at
> org.apache.geode.internal.cache.map.RegionMapDestroy.destroy(RegionMapDestroy.java:149)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.destroy(AbstractRegionMap.java:1093)
> at
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6504)
> at
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6478)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.destroyExistingEntry(LocalRegionDataView.java:56)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroy(LocalRegion.java:6430)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicDestroy(DistributedRegion.java:1599)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderQueue$SerialGatewaySenderQueueMetaRegion.basicDestroy(SerialGatewaySenderQueue.java:1279)
> at
> org.apache.geode.internal.cache.LocalRegion.localDestroy(LocalRegion.java:2186)
> at
> org.apache.geode.internal.cache.DistributedRegion.localDestroy(DistributedRegion.java:964)
> at
> org.apache.geode.internal.cache.wan.serial.BatchDestroyOperation$DestroyMessage.operateOnRegion(BatchDestroyOperation.java:120)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.basicProcess(DistributedCacheOperation.java:1191)
> at
>
[jira] [Resolved] (GEODE-5144) CI failure: org.apache.geode.internal.cache.wan.serial.SerialWANPropagationsFeatureDUnitTest > testReplicatedSerialPropagationWithFilter
[
https://issues.apache.org/jira/browse/GEODE-5144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
xiaojian zhou resolved GEODE-5144.
--
Resolution: Fixed
> CI failure:
> org.apache.geode.internal.cache.wan.serial.SerialWANPropagationsFeatureDUnitTest
> > testReplicatedSerialPropagationWithFilter
>
>
> Key: GEODE-5144
> URL: https://issues.apache.org/jira/browse/GEODE-5144
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.6.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: xiaojian zhou
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This failure occurred during CI:
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/release-1.6.0/jobs/DistributedTest/builds/12
> {noformat}
> org.apache.geode.internal.cache.wan.serial.SerialWANPropagationsFeatureDUnitTest
> > testReplicatedSerialPropagationWithFilter FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 3199
> [error 2018/04/26 03:50:06.755 UTC 172.17.0.5(414):32774 shared ordered uid=20 port=60094> tid=309]
> Exception occurred in CacheListener
> java.util.concurrent.RejectedExecutionException: Task
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor$2@471694c6
> rejected from java.util.concurrent.ThreadPoolExecutor@c955b3b[Shutting down,
> pool size = 1, active threads = 0, queued tasks = 0, completed tasks = 1778]
> at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.handlePrimaryDestroy(SerialGatewaySenderEventProcessor.java:611)
> at
> org.apache.geode.internal.cache.wan.serial.SerialSecondaryGatewayListener.afterDestroy(SerialSecondaryGatewayListener.java:91)
> at
> org.apache.geode.internal.cache.EnumListenerEvent$AFTER_DESTROY.dispatchEvent(EnumListenerEvent.java:151)
> at
> org.apache.geode.internal.cache.LocalRegion.dispatchEvent(LocalRegion.java:8468)
> at
> org.apache.geode.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:6969)
> at
> org.apache.geode.internal.cache.LocalRegion.invokeDestroyCallbacks(LocalRegion.java:6778)
> at
> org.apache.geode.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2381)
> at
> org.apache.geode.internal.cache.entries.AbstractRegionEntry.dispatchListenerEvents(AbstractRegionEntry.java:170)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroyPart2(LocalRegion.java:6717)
> at
> org.apache.geode.internal.cache.map.RegionMapDestroy.destroyExistingEntry(RegionMapDestroy.java:409)
> at
> org.apache.geode.internal.cache.map.RegionMapDestroy.handleExistingRegionEntry(RegionMapDestroy.java:238)
> at
> org.apache.geode.internal.cache.map.RegionMapDestroy.destroy(RegionMapDestroy.java:149)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.destroy(AbstractRegionMap.java:1093)
> at
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6504)
> at
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6478)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.destroyExistingEntry(LocalRegionDataView.java:56)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroy(LocalRegion.java:6430)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicDestroy(DistributedRegion.java:1599)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderQueue$SerialGatewaySenderQueueMetaRegion.basicDestroy(SerialGatewaySenderQueue.java:1279)
> at
> org.apache.geode.internal.cache.LocalRegion.localDestroy(LocalRegion.java:2186)
> at
> org.apache.geode.internal.cache.DistributedRegion.localDestroy(DistributedRegion.java:964)
> at
> org.apache.geode.internal.cache.wan.serial.BatchDestroyOperation$DestroyMessage.operateOnRegion(BatchDestroyOperation.java:120)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.basicProcess(DistributedCacheOperation.java:1191)
> at
>
[jira] [Created] (GEODE-5205) Refactor ThinClientPdxTests to eliminate looping, decrease run time
Blake Bender created GEODE-5205: --- Summary: Refactor ThinClientPdxTests to eliminate looping, decrease run time Key: GEODE-5205 URL: https://issues.apache.org/jira/browse/GEODE-5205 Project: Geode Issue Type: Improvement Components: native client Reporter: Blake Bender On a slower VM, this test is taking > 2000 sec (~34 minutes!) to complete, so tests runs are timing out. We need to break it up or eliminate some redundant work to improve this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-3563) SSL socket handling problems in TCPConduit run
[ https://issues.apache.org/jira/browse/GEODE-3563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472462#comment-16472462 ] Bruce Schuchardt commented on GEODE-3563: - There was a problem with the fix for this ticket. The changes caused all sockets, ssl & non-ssl, to have timeouts established. This was causing idle TCPConduit connections to time out after a minute, whereas before they did not timeout. I'm modifying the fix to establish timeouts in the callers of the method and am changing the method itself to override the timeout for the duration of the handshake and then restore it to its old value. > SSL socket handling problems in TCPConduit run > -- > > Key: GEODE-3563 > URL: https://issues.apache.org/jira/browse/GEODE-3563 > Project: Geode > Issue Type: Bug > Components: messaging >Reporter: Vahram Aharonyan >Assignee: Galen O'Sullivan >Priority: Critical > Labels: pull-request-available > Fix For: 1.6.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Here are two cases that seems to problematic in TCPConduit.run flow: > 1. TCPConduit.run() has no action performed for the case when SSLException is > thrown from sslSocket.startHandshake(), as a result the socket remains open. > Catch block from the end of configureServerSSLSocket() will just report a > fatal error(even it seem that this portion is going to be removed in 1.2.1 > according to GEODE-3393) and re-throw the exception. > 2. configureServerSSLSocket call is performed without setting socket timeout > before that. This can bring to run thread blocking case if read initiated > from the SSL handshake flow will not return. Linking to similar issues > observed with other acceptors previously: GEODE-2898, GEODE-3023. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-3563) SSL socket handling problems in TCPConduit run
[ https://issues.apache.org/jira/browse/GEODE-3563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt reassigned GEODE-3563: --- Assignee: Bruce Schuchardt (was: Galen O'Sullivan) > SSL socket handling problems in TCPConduit run > -- > > Key: GEODE-3563 > URL: https://issues.apache.org/jira/browse/GEODE-3563 > Project: Geode > Issue Type: Bug > Components: messaging >Reporter: Vahram Aharonyan >Assignee: Bruce Schuchardt >Priority: Critical > Labels: pull-request-available > Fix For: 1.6.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Here are two cases that seems to problematic in TCPConduit.run flow: > 1. TCPConduit.run() has no action performed for the case when SSLException is > thrown from sslSocket.startHandshake(), as a result the socket remains open. > Catch block from the end of configureServerSSLSocket() will just report a > fatal error(even it seem that this portion is going to be removed in 1.2.1 > according to GEODE-3393) and re-throw the exception. > 2. configureServerSSLSocket call is performed without setting socket timeout > before that. This can bring to run thread blocking case if read initiated > from the SSL handshake flow will not return. Linking to similar issues > observed with other acceptors previously: GEODE-2898, GEODE-3023. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5187) clients can miss events when servers recycled, possibly due to null eventId in ClientUpdateMessageImpl
[ https://issues.apache.org/jira/browse/GEODE-5187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5187: -- Labels: pull-request-available (was: ) > clients can miss events when servers recycled, possibly due to null eventId > in ClientUpdateMessageImpl > -- > > Key: GEODE-5187 > URL: https://issues.apache.org/jira/browse/GEODE-5187 > Project: Geode > Issue Type: Bug > Components: client queues >Reporter: Shelley Lynn Hughes-Godfrey >Assignee: Shelley Lynn Hughes-Godfrey >Priority: Major > Labels: pull-request-available > > HARegionQueues may have an issue where messages are lost due to the eventId > (threadId and sequenceId) being null ... which prevents them from being > dispatched to the client. > This may be due to the ClientUpdateMessageImpl no longer including the > eventId when serialized over the wire between servers. Now the receiving > side must use eventId from the HAEventWrapper to re-populate this field in > the ClientUpdateMessage. > If the null eventId is detected by HARegionQueue.putGIIDataInRegion, the > corresponding event is silently dropped. This occurs when processing the > InitialImage of the HARegionQueue from another server. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5011) Refactor Commands to use *ResultModel
[ https://issues.apache.org/jira/browse/GEODE-5011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472429#comment-16472429 ] ASF subversion and git services commented on GEODE-5011: Commit 4f330c3e6e6a5fafff3d5d32852c320b9729277b in geode's branch refs/heads/feature/GEODE-5087 from [~jens.deppe] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4f330c3 ] Revert "GEODE-5011: Convert 'Data' commands to ResultModel (#1945)" This reverts commit f1c6b560442f2f23aa9240b3550d9d664e094c7c. > Refactor Commands to use *ResultModel > - > > Key: GEODE-5011 > URL: https://issues.apache.org/jira/browse/GEODE-5011 > Project: Geode > Issue Type: Sub-task > Components: gfsh >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5200) Correct docs for use-cluster-configuration property
[ https://issues.apache.org/jira/browse/GEODE-5200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472433#comment-16472433 ] ASF subversion and git services commented on GEODE-5200: Commit 4c851fc6cf49d62abf6683491b6646b12d00b93a in geode's branch refs/heads/feature/GEODE-5087 from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4c851fc ] GEODE-5200 Correct docs for use-cluster-configuration property (#1949) > Correct docs for use-cluster-configuration property > --- > > Key: GEODE-5200 > URL: https://issues.apache.org/jira/browse/GEODE-5200 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > > In the section titled gemfire.properties and gfsecurity.properties (Geode > Properties), it says that the "use-cluster-configuration" property is only > applicable for data members (non-client and non-locator) in "Definition" > column. That does not match with what is in the 3rd column, which says which > components are affected. Instead of "L," the column should say "S." > File affected is reference/topics/gemfire_properties.html > This is a 1-character change to fix the docs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5187) clients can miss events when servers recycled, possibly due to null eventId in ClientUpdateMessageImpl
[ https://issues.apache.org/jira/browse/GEODE-5187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472427#comment-16472427 ] ASF subversion and git services commented on GEODE-5187: Commit 74cbcc515781ef79b5413e8af4b3b37eb95ebbc9 in geode's branch refs/heads/feature/GEODE-5187 from [~lhughesgodfrey] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=74cbcc5 ] GEODE-5187: clients can miss events when servers recycled * When draining events from the giiQueue, the msg field of HAEventWrapper may be null. Update the HAEventWrapper to point to the message in the HAContainer vs. calling putEventInHARegion with the original HAContainer message (a ClientUpdateMessageImpl). This is necessary as the ClientUpdateMessageImpl does not have the eventId (this is not serialized/deserialized in toData/fromData). The HAEventWrapper is required on the remote side to reconstruct the event. * Updated log messages to include the HARegionQueue.regionName * Added corresponding IntegrationTest > clients can miss events when servers recycled, possibly due to null eventId > in ClientUpdateMessageImpl > -- > > Key: GEODE-5187 > URL: https://issues.apache.org/jira/browse/GEODE-5187 > Project: Geode > Issue Type: Bug > Components: client queues >Reporter: Shelley Lynn Hughes-Godfrey >Assignee: Shelley Lynn Hughes-Godfrey >Priority: Major > > HARegionQueues may have an issue where messages are lost due to the eventId > (threadId and sequenceId) being null ... which prevents them from being > dispatched to the client. > This may be due to the ClientUpdateMessageImpl no longer including the > eventId when serialized over the wire between servers. Now the receiving > side must use eventId from the HAEventWrapper to re-populate this field in > the ClientUpdateMessage. > If the null eventId is detected by HARegionQueue.putGIIDataInRegion, the > corresponding event is silently dropped. This occurs when processing the > InitialImage of the HARegionQueue from another server. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5144) CI failure: org.apache.geode.internal.cache.wan.serial.SerialWANPropagationsFeatureDUnitTest > testReplicatedSerialPropagationWithFilter
[
https://issues.apache.org/jira/browse/GEODE-5144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472434#comment-16472434
]
ASF subversion and git services commented on GEODE-5144:
Commit df89f93bd8923f45977848fef1fc59c54f2c9e34 in geode's branch
refs/heads/feature/GEODE-5087 from Xiaojian Zhou
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=df89f93 ]
GEODE-5144: The test should wait for secondary queue to drain (#1947)
remove the test only method
> CI failure:
> org.apache.geode.internal.cache.wan.serial.SerialWANPropagationsFeatureDUnitTest
> > testReplicatedSerialPropagationWithFilter
>
>
> Key: GEODE-5144
> URL: https://issues.apache.org/jira/browse/GEODE-5144
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.6.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: xiaojian zhou
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This failure occurred during CI:
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/release-1.6.0/jobs/DistributedTest/builds/12
> {noformat}
> org.apache.geode.internal.cache.wan.serial.SerialWANPropagationsFeatureDUnitTest
> > testReplicatedSerialPropagationWithFilter FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 3199
> [error 2018/04/26 03:50:06.755 UTC 172.17.0.5(414):32774 shared ordered uid=20 port=60094> tid=309]
> Exception occurred in CacheListener
> java.util.concurrent.RejectedExecutionException: Task
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor$2@471694c6
> rejected from java.util.concurrent.ThreadPoolExecutor@c955b3b[Shutting down,
> pool size = 1, active threads = 0, queued tasks = 0, completed tasks = 1778]
> at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.handlePrimaryDestroy(SerialGatewaySenderEventProcessor.java:611)
> at
> org.apache.geode.internal.cache.wan.serial.SerialSecondaryGatewayListener.afterDestroy(SerialSecondaryGatewayListener.java:91)
> at
> org.apache.geode.internal.cache.EnumListenerEvent$AFTER_DESTROY.dispatchEvent(EnumListenerEvent.java:151)
> at
> org.apache.geode.internal.cache.LocalRegion.dispatchEvent(LocalRegion.java:8468)
> at
> org.apache.geode.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:6969)
> at
> org.apache.geode.internal.cache.LocalRegion.invokeDestroyCallbacks(LocalRegion.java:6778)
> at
> org.apache.geode.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2381)
> at
> org.apache.geode.internal.cache.entries.AbstractRegionEntry.dispatchListenerEvents(AbstractRegionEntry.java:170)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroyPart2(LocalRegion.java:6717)
> at
> org.apache.geode.internal.cache.map.RegionMapDestroy.destroyExistingEntry(RegionMapDestroy.java:409)
> at
> org.apache.geode.internal.cache.map.RegionMapDestroy.handleExistingRegionEntry(RegionMapDestroy.java:238)
> at
> org.apache.geode.internal.cache.map.RegionMapDestroy.destroy(RegionMapDestroy.java:149)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.destroy(AbstractRegionMap.java:1093)
> at
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6504)
> at
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6478)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.destroyExistingEntry(LocalRegionDataView.java:56)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroy(LocalRegion.java:6430)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicDestroy(DistributedRegion.java:1599)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderQueue$SerialGatewaySenderQueueMetaRegion.basicDestroy(SerialGatewaySenderQueue.java:1279)
> at
> org.apache.geode.internal.cache.LocalRegion.localDestroy(LocalRegion.java:2186)
> at
> org.apache.geode.internal.cache.DistributedRegion.localDestroy(DistributedRegion.java:964)
> at
>
[jira] [Commented] (GEODE-5198) NPE in DataSerializer registration when forming a client/server connection during handshake
[
https://issues.apache.org/jira/browse/GEODE-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472431#comment-16472431
]
ASF subversion and git services commented on GEODE-5198:
Commit a60b8d4237f0d27b9b31af304ae6ec3bfcdc077c in geode's branch
refs/heads/feature/GEODE-5087 from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a60b8d4 ]
GEODE-5198 NPE in DataSerializer registration when forming a client/server
connection during handshake
If a holder can't be found do not record supported classes for it.
Absense of the holder, which had just been inserted into the
idsToHolders collection, means that another thread has resolved the
holder into an actual DataSerializer class and has removed the holder
and its supported classes.
This closes #1943
> NPE in DataSerializer registration when forming a client/server connection
> during handshake
> ---
>
> Key: GEODE-5198
> URL: https://issues.apache.org/jira/browse/GEODE-5198
> Project: Geode
> Issue Type: Improvement
> Components: client/server, serialization
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Attachments: DataSerializerHolderJUnitTest.java
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Someone hit an NPE when forming a connection to a server in an application
> making heavy use of custom DataSerializers. I wrote a unit test to reproduce
> the problem (attached) which produces this:
> {noformat}
> java.lang.NullPointerException
> at
> java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011)
> at
> java.util.concurrent.ConcurrentHashMap.putIfAbsent(ConcurrentHashMap.java:1535)
> at
> org.apache.geode.internal.InternalDataSerializer.updateSupportedClassesMap(InternalDataSerializer.java:1079)
> at
> org.apache.geode.internal.DataSerializerHolderJUnitTest$1.run(DataSerializerHolderJUnitTest.java:72)
> {noformat}
> The problem is in the idsToHolders map in InternalDataSerializer. This map is
> initialized with a "holder" object that knows the name and ID of a
> DataSerializer. During tcp/ip connection formation one of these is created
> when processing a list of DataSerializers sent to the client by the server as
> part of the handshake. Then the server sends a map of the names of classes
> supported by the serializers. It's in this second step that we're hitting the
> NPE because some other thread has resolved the holder into an actual class
> and has removed the holder from the idsToHolders map. This can be done in any
> of three other methods in InternalDataSerializer that are used as a matter of
> course in serializing/deserializing objects.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5011) Refactor Commands to use *ResultModel
[ https://issues.apache.org/jira/browse/GEODE-5011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472428#comment-16472428 ] ASF subversion and git services commented on GEODE-5011: Commit f1c6b560442f2f23aa9240b3550d9d664e094c7c in geode's branch refs/heads/feature/GEODE-5087 from [~jens.deppe] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f1c6b56 ] GEODE-5011: Convert 'Data' commands to ResultModel (#1945) > Refactor Commands to use *ResultModel > - > > Key: GEODE-5011 > URL: https://issues.apache.org/jira/browse/GEODE-5011 > Project: Geode > Issue Type: Sub-task > Components: gfsh >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5011) Refactor Commands to use *ResultModel
[ https://issues.apache.org/jira/browse/GEODE-5011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472430#comment-16472430 ] ASF subversion and git services commented on GEODE-5011: Commit 8ed21ab9e2ffc3d40d5909d1d124930a93282e9c in geode's branch refs/heads/feature/GEODE-5087 from [~jens.deppe] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8ed21ab ] GEODE-5011: Convert 'Data' commands to ResultModel (#1945) > Refactor Commands to use *ResultModel > - > > Key: GEODE-5011 > URL: https://issues.apache.org/jira/browse/GEODE-5011 > Project: Geode > Issue Type: Sub-task > Components: gfsh >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5087) SerialGatewaySenderOperationsDUnitTest.testRestartSerialGatewaySendersWhilePutting intermittently fail
[ https://issues.apache.org/jira/browse/GEODE-5087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472435#comment-16472435 ] ASF subversion and git services commented on GEODE-5087: Commit 4bd303084e39d9aa9ebedbef94b44ccf668fff65 in geode's branch refs/heads/feature/GEODE-5087 from zhouxh [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4bd3030 ] GEODE-5087: send a BatchDestroyOperation for each dropped event at serial primary sender > SerialGatewaySenderOperationsDUnitTest.testRestartSerialGatewaySendersWhilePutting > intermittently fail > --- > > Key: GEODE-5087 > URL: https://issues.apache.org/jira/browse/GEODE-5087 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: xiaojian zhou >Assignee: xiaojian zhou >Priority: Major > Labels: pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > > I introduced this dunit test for GEODE-4942, while GEODE-4942 is for parallel > gateway sender, the test is for serial gateway sender. And I did reproduce > the issue: event is dropped at primary sender (because it's not running yet), > but event has been put into unprocessedEventsMap at secondary sender's queue > and will stay there forever. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5172) AbstractRegionMap.txApplyPut should be refactored to use RegionMapPut
[ https://issues.apache.org/jira/browse/GEODE-5172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472432#comment-16472432 ] ASF subversion and git services commented on GEODE-5172: Commit 6839dca5b3c63f2a068998d890ee56cf3c21e5ef in geode's branch refs/heads/feature/GEODE-5087 from [~dschneider] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6839dca ] GEODE-5172: refactor txApplyPut to reuse RegionMapPut (#1917) AbstractRegionMapPut has been introduced and has the common code used for both a non-tx put (RegionMapPut) and a transaction put being committed (RegionMapCommitPut). RegionMapCommitPut is used by txApplyPut. > AbstractRegionMap.txApplyPut should be refactored to use RegionMapPut > - > > Key: GEODE-5172 > URL: https://issues.apache.org/jira/browse/GEODE-5172 > Project: Geode > Issue Type: Sub-task > Components: transactions >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 50m > Remaining Estimate: 0h > > RegionMapPut (currently used for a non-tx put) and txApplyPut share much the > same code. > txApplyPut should be refactored to use the code in RegionMapPut. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-3845) As a user, I want to be able to do a distributed destroy action from a local region
[
https://issues.apache.org/jira/browse/GEODE-3845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Vallely updated GEODE-3845:
Description:
I use entry-idle-time and eviction together in a partition region that holds
one redundant copy.
Details of setting are as follows:
{code:xml}
{code}
In this setting, the data held by the cache server is different. Then,
inconsistent results are returned depending on the server to be connected.
Eviction of the partition region can only select local-destroy or
overflow-to-disk. On the other hand, it is written that the expire chapter of
the document can not use local-destroy, local-invalidate in the partition
region. Likewise, I think that data inconsistency will occur even with the
settings like this time.
Below is the test code:
[https://github.com/masaki-yamakawa/geode/blob/bug-partition-local-destroy/geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/BugExpireAndEvictionDUnitTest.java]
I think that it is necessary to add a check at the time of region creation or
write it in the document.
**
Problem: currently eviction-action currently must be either 'local-destroy' or
'overflow-to-disk'
ex:
Solution: This story is to add the additional option "distributed-destroy" as
an action setting for expiration-attributes.
This will enable a local destroy action to be distributed across the cluster
(currently this does not exist)
Acceptance: can set this on region configuration via cache.xml, API or gfsh
gfsh help and docs have been updated
was:
I use entry-idle-time and eviction together in a partition region that holds
one redundant copy.
Details of setting are as follows:
{code:xml}
{code}
In this setting, the data held by the cache server is different. Then,
inconsistent results are returned depending on the server to be connected.
Eviction of the partition region can only select local-destroy or
overflow-to-disk. On the other hand, it is written that the expire chapter of
the document can not use local-destroy, local-invalidate in the partition
region. Likewise, I think that data inconsistency will occur even with the
settings like this time.
Below is the test code:
https://github.com/masaki-yamakawa/geode/blob/bug-partition-local-destroy/geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/BugExpireAndEvictionDUnitTest.java
I think that it is necessary to add a check at the time of region creation or
write it in the document.
> As a user, I want to be able to do a distributed destroy action from a local
> region
> ---
>
> Key: GEODE-3845
> URL: https://issues.apache.org/jira/browse/GEODE-3845
> Project: Geode
> Issue Type: New Feature
> Components: docs, eviction
>Reporter: Masaki Yamakawa
>Priority: Major
>
> I use entry-idle-time and eviction together in a partition region that holds
> one redundant copy.
> Details of setting are as follows:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
> {code}
> In this setting, the data held by the cache server is different. Then,
> inconsistent results are returned depending on the server to be connected.
> Eviction of the partition region can only select local-destroy or
> overflow-to-disk. On the other hand, it is written that the expire chapter of
> the document can not use local-destroy, local-invalidate in the partition
> region. Likewise, I think that data inconsistency will occur even with the
> settings like this time.
> Below is the test code:
> [https://github.com/masaki-yamakawa/geode/blob/bug-partition-local-destroy/geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/BugExpireAndEvictionDUnitTest.java]
> I think that it is necessary to add a check at the time of region creation or
> write it in the document.
>
> **
> Problem: currently eviction-action currently must be either 'local-destroy'
> or 'overflow-to-disk'
> ex:
> Solution: This story is to add the additional option "distributed-destroy" as
> an action setting for expiration-attributes.
> This will enable a local destroy action to be distributed across the cluster
> (currently this does not exist)
>
> Acceptance: can set this on region configuration via cache.xml, API or gfsh
> gfsh help and docs have been updated
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-2113) Implement SSL over NIO
[ https://issues.apache.org/jira/browse/GEODE-2113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472379#comment-16472379 ] Galen O'Sullivan commented on GEODE-2113: - There is a real win here for TcpConduit. TcpConduit uses oio for SSL and nio for non-SSL, which results in different behavior in those two cases. If we switched SSL to nio, we could eliminate a lot of code, make cluster messaging more consistent, and make cluster messaging faster. Perhaps we can create separate subtasks for TcpConduit, CacheServer, TcpServer (and maybe even the client?) > Implement SSL over NIO > -- > > Key: GEODE-2113 > URL: https://issues.apache.org/jira/browse/GEODE-2113 > Project: Geode > Issue Type: Improvement > Components: messaging >Reporter: Addison >Priority: Major > > Java now has a nifty javax.net.ssl.SSLSocketFactory that can produce an > SSLSocket from an existing Socket. This will let us create an SSLSocket that > has an NIO SocketChannel and get rid of all of the "Old IO" code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5144) CI failure: org.apache.geode.internal.cache.wan.serial.SerialWANPropagationsFeatureDUnitTest > testReplicatedSerialPropagationWithFilter
[
https://issues.apache.org/jira/browse/GEODE-5144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472365#comment-16472365
]
ASF subversion and git services commented on GEODE-5144:
Commit df89f93bd8923f45977848fef1fc59c54f2c9e34 in geode's branch
refs/heads/develop from Xiaojian Zhou
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=df89f93 ]
GEODE-5144: The test should wait for secondary queue to drain (#1947)
remove the test only method
> CI failure:
> org.apache.geode.internal.cache.wan.serial.SerialWANPropagationsFeatureDUnitTest
> > testReplicatedSerialPropagationWithFilter
>
>
> Key: GEODE-5144
> URL: https://issues.apache.org/jira/browse/GEODE-5144
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.6.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: xiaojian zhou
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This failure occurred during CI:
>
> https://concourse.apachegeode-ci.info/teams/main/pipelines/release-1.6.0/jobs/DistributedTest/builds/12
> {noformat}
> org.apache.geode.internal.cache.wan.serial.SerialWANPropagationsFeatureDUnitTest
> > testReplicatedSerialPropagationWithFilter FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 3199
> [error 2018/04/26 03:50:06.755 UTC 172.17.0.5(414):32774 shared ordered uid=20 port=60094> tid=309]
> Exception occurred in CacheListener
> java.util.concurrent.RejectedExecutionException: Task
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor$2@471694c6
> rejected from java.util.concurrent.ThreadPoolExecutor@c955b3b[Shutting down,
> pool size = 1, active threads = 0, queued tasks = 0, completed tasks = 1778]
> at
> java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2063)
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:830)
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1379)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderEventProcessor.handlePrimaryDestroy(SerialGatewaySenderEventProcessor.java:611)
> at
> org.apache.geode.internal.cache.wan.serial.SerialSecondaryGatewayListener.afterDestroy(SerialSecondaryGatewayListener.java:91)
> at
> org.apache.geode.internal.cache.EnumListenerEvent$AFTER_DESTROY.dispatchEvent(EnumListenerEvent.java:151)
> at
> org.apache.geode.internal.cache.LocalRegion.dispatchEvent(LocalRegion.java:8468)
> at
> org.apache.geode.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:6969)
> at
> org.apache.geode.internal.cache.LocalRegion.invokeDestroyCallbacks(LocalRegion.java:6778)
> at
> org.apache.geode.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2381)
> at
> org.apache.geode.internal.cache.entries.AbstractRegionEntry.dispatchListenerEvents(AbstractRegionEntry.java:170)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroyPart2(LocalRegion.java:6717)
> at
> org.apache.geode.internal.cache.map.RegionMapDestroy.destroyExistingEntry(RegionMapDestroy.java:409)
> at
> org.apache.geode.internal.cache.map.RegionMapDestroy.handleExistingRegionEntry(RegionMapDestroy.java:238)
> at
> org.apache.geode.internal.cache.map.RegionMapDestroy.destroy(RegionMapDestroy.java:149)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.destroy(AbstractRegionMap.java:1093)
> at
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6504)
> at
> org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6478)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.destroyExistingEntry(LocalRegionDataView.java:56)
> at
> org.apache.geode.internal.cache.LocalRegion.basicDestroy(LocalRegion.java:6430)
> at
> org.apache.geode.internal.cache.DistributedRegion.basicDestroy(DistributedRegion.java:1599)
> at
> org.apache.geode.internal.cache.wan.serial.SerialGatewaySenderQueue$SerialGatewaySenderQueueMetaRegion.basicDestroy(SerialGatewaySenderQueue.java:1279)
> at
> org.apache.geode.internal.cache.LocalRegion.localDestroy(LocalRegion.java:2186)
> at
> org.apache.geode.internal.cache.DistributedRegion.localDestroy(DistributedRegion.java:964)
> at
>
[jira] [Commented] (GEODE-5187) clients can miss events when servers recycled, possibly due to null eventId in ClientUpdateMessageImpl
[ https://issues.apache.org/jira/browse/GEODE-5187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472353#comment-16472353 ] ASF subversion and git services commented on GEODE-5187: Commit 98c7eaec4cb656e36a1a165a7bb0ec57b0603c90 in geode's branch refs/heads/feature/GEODE-5187 from [~lhughesgodfrey] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=98c7eae ] GEODE-5187: clients can miss events when servers recycled * When draining events from the giiQueue, the msg field of HAEventWrapper may be null. Update the HAEventWrapper to point to the message in the HAContainer vs. calling putEventInHARegion with the original HAContainer message (a ClientUpdateMessageImpl). This is necessary as the ClientUpdateMessageImpl does not have the eventId (this is not serialized/deserialized in toData/fromData). The HAEventWrapper is required on the remote side to reconstruct the event. * Updated log messages to include the HARegionQueue.regionName * Added corresponding IntegrationTest > clients can miss events when servers recycled, possibly due to null eventId > in ClientUpdateMessageImpl > -- > > Key: GEODE-5187 > URL: https://issues.apache.org/jira/browse/GEODE-5187 > Project: Geode > Issue Type: Bug > Components: client queues >Reporter: Shelley Lynn Hughes-Godfrey >Assignee: Shelley Lynn Hughes-Godfrey >Priority: Major > > HARegionQueues may have an issue where messages are lost due to the eventId > (threadId and sequenceId) being null ... which prevents them from being > dispatched to the client. > This may be due to the ClientUpdateMessageImpl no longer including the > eventId when serialized over the wire between servers. Now the receiving > side must use eventId from the HAEventWrapper to re-populate this field in > the ClientUpdateMessage. > If the null eventId is detected by HARegionQueue.putGIIDataInRegion, the > corresponding event is silently dropped. This occurs when processing the > InitialImage of the HARegionQueue from another server. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5200) Correct docs for use-cluster-configuration property
[ https://issues.apache.org/jira/browse/GEODE-5200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller resolved GEODE-5200. Resolution: Fixed Assignee: Karen Smoler Miller Fix Version/s: 1.7.0 > Correct docs for use-cluster-configuration property > --- > > Key: GEODE-5200 > URL: https://issues.apache.org/jira/browse/GEODE-5200 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 20m > Remaining Estimate: 0h > > In the section titled gemfire.properties and gfsecurity.properties (Geode > Properties), it says that the "use-cluster-configuration" property is only > applicable for data members (non-client and non-locator) in "Definition" > column. That does not match with what is in the 3rd column, which says which > components are affected. Instead of "L," the column should say "S." > File affected is reference/topics/gemfire_properties.html > This is a 1-character change to fix the docs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5204) Add 'get/set cluster-config' gfsh command
[
https://issues.apache.org/jira/browse/GEODE-5204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-5204:
--
Description:
Add a new gfsh command to update an existing cluster config xml.
The command should only update the cluster configuration and not affect the
config of running servers (this will be added later).
The set command should take options {{\-\-group}}, {{\-\-xml}} and
{{\-\-properties}}. The default group should be {{"cluster"}}.
The command should only need to be run on a single locator and have changes
propagated to all other locators.
was:
Add a new gfsh command to update an existing cluster config xml.
The command should only update the cluster configuration and not affect the
config of running servers (this will be added later).
The set command should take options {{\-\-group}}, {{\-\-xml}} and
{{\-\-properties}}. The default group should be {{cluster}}.
The command should only need to be run on a single locator and have changes
propagated to all other locators.
> Add 'get/set cluster-config' gfsh command
> -
>
> Key: GEODE-5204
> URL: https://issues.apache.org/jira/browse/GEODE-5204
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Jens Deppe
>Priority: Major
>
> Add a new gfsh command to update an existing cluster config xml.
> The command should only update the cluster configuration and not affect the
> config of running servers (this will be added later).
> The set command should take options {{\-\-group}}, {{\-\-xml}} and
> {{\-\-properties}}. The default group should be {{"cluster"}}.
> The command should only need to be run on a single locator and have changes
> propagated to all other locators.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5204) Add 'get/set cluster-config' gfsh command
[
https://issues.apache.org/jira/browse/GEODE-5204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-5204:
--
Description:
Add a new gfsh command to update an existing cluster config xml.
The command should only update the cluster configuration and not affect the
config of running servers (this will be added later).
The set command should take options {{\-\-group}}, {{\-\-xml}} and
{{\-\-properties}}. The default group should be {{cluster}}.
The command should only need to be run on a single locator and have changes
propagated to all other locators.
was:
Add a new gfsh command to update an existing cluster config xml.
The command should only update the cluster configuration and not affect the
config of running servers (this will be added later).
The set command should take options {{--group}}, {{--xml}} and
{{--properties}}. The default group should be {{cluster}}.
The command should only need to be run on a single locator and have changes
propagated to all other locators.
> Add 'get/set cluster-config' gfsh command
> -
>
> Key: GEODE-5204
> URL: https://issues.apache.org/jira/browse/GEODE-5204
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Jens Deppe
>Priority: Major
>
> Add a new gfsh command to update an existing cluster config xml.
> The command should only update the cluster configuration and not affect the
> config of running servers (this will be added later).
> The set command should take options {{\-\-group}}, {{\-\-xml}} and
> {{\-\-properties}}. The default group should be {{cluster}}.
> The command should only need to be run on a single locator and have changes
> propagated to all other locators.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5204) Add 'get/set cluster-config' gfsh command
Jens Deppe created GEODE-5204:
-
Summary: Add 'get/set cluster-config' gfsh command
Key: GEODE-5204
URL: https://issues.apache.org/jira/browse/GEODE-5204
Project: Geode
Issue Type: Improvement
Components: gfsh
Reporter: Jens Deppe
Add a new gfsh command to update an existing cluster config xml.
The command should only update the cluster configuration and not affect the
config of running servers (this will be added later).
The set command should take options {{--group}}, {{--xml}} and
{{--properties}}. The default group should be {{cluster}}.
The command should only need to be run on a single locator and have changes
propagated to all other locators.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5203) User Guide - clarify that client SSL setting descriptions are for Java clients only
[ https://issues.apache.org/jira/browse/GEODE-5203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes reassigned GEODE-5203: -- Assignee: Dave Barnes > User Guide - clarify that client SSL setting descriptions are for Java > clients only > --- > > Key: GEODE-5203 > URL: https://issues.apache.org/jira/browse/GEODE-5203 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > > In Managing -> Security -> SSL -> Configuring SSL, the explanation of SSL > settings for clients applies only to Java clients. > Settings for C++ or .NET clients (developed using the in-the-works > geode-native API) may differ from the Java settings. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5203) User Guide - clarify that client SSL setting descriptions are for Java clients only
Dave Barnes created GEODE-5203: -- Summary: User Guide - clarify that client SSL setting descriptions are for Java clients only Key: GEODE-5203 URL: https://issues.apache.org/jira/browse/GEODE-5203 Project: Geode Issue Type: Improvement Components: docs Reporter: Dave Barnes In Managing -> Security -> SSL -> Configuring SSL, the explanation of SSL settings for clients applies only to Java clients. Settings for C++ or .NET clients (developed using the in-the-works geode-native API) may differ from the Java settings. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5202) Refactor TXApplyDestroy
[ https://issues.apache.org/jira/browse/GEODE-5202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Vallely updated GEODE-5202: Labels: AbstractRegionMap (was: ) > Refactor TXApplyDestroy > --- > > Key: GEODE-5202 > URL: https://issues.apache.org/jira/browse/GEODE-5202 > Project: Geode > Issue Type: Sub-task > Components: transactions >Reporter: Nick Vallely >Priority: Major > Labels: AbstractRegionMap > > Refactor the TXApplyDestroy to lay groundwork for Distributed Destroy > capability (GEODE-3845) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5202) Refactor TXApplyDestroy
Nick Vallely created GEODE-5202: --- Summary: Refactor TXApplyDestroy Key: GEODE-5202 URL: https://issues.apache.org/jira/browse/GEODE-5202 Project: Geode Issue Type: Sub-task Components: transactions Reporter: Nick Vallely Refactor the TXApplyDestroy to lay groundwork for Distributed Destroy capability (GEODE-3845) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-3845) As a user, I want to be able to do a distributed destroy action from a local region
[
https://issues.apache.org/jira/browse/GEODE-3845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Vallely updated GEODE-3845:
Labels: (was: geode-150)
> As a user, I want to be able to do a distributed destroy action from a local
> region
> ---
>
> Key: GEODE-3845
> URL: https://issues.apache.org/jira/browse/GEODE-3845
> Project: Geode
> Issue Type: New Feature
> Components: docs, eviction
>Reporter: Masaki Yamakawa
>Priority: Major
>
> I use entry-idle-time and eviction together in a partition region that holds
> one redundant copy.
> Details of setting are as follows:
> {code:xml}
>
>
>
>
>
>
>
>
>
>
>
> {code}
> In this setting, the data held by the cache server is different. Then,
> inconsistent results are returned depending on the server to be connected.
> Eviction of the partition region can only select local-destroy or
> overflow-to-disk. On the other hand, it is written that the expire chapter of
> the document can not use local-destroy, local-invalidate in the partition
> region. Likewise, I think that data inconsistency will occur even with the
> settings like this time.
> Below is the test code:
> https://github.com/masaki-yamakawa/geode/blob/bug-partition-local-destroy/geode-core/src/test/java/org/apache/geode/internal/cache/partitioned/BugExpireAndEvictionDUnitTest.java
> I think that it is necessary to add a check at the time of region creation or
> write it in the document.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5198) NPE in DataSerializer registration when forming a client/server connection during handshake
[
https://issues.apache.org/jira/browse/GEODE-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruce Schuchardt resolved GEODE-5198.
-
Resolution: Fixed
> NPE in DataSerializer registration when forming a client/server connection
> during handshake
> ---
>
> Key: GEODE-5198
> URL: https://issues.apache.org/jira/browse/GEODE-5198
> Project: Geode
> Issue Type: Improvement
> Components: client/server, serialization
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Attachments: DataSerializerHolderJUnitTest.java
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Someone hit an NPE when forming a connection to a server in an application
> making heavy use of custom DataSerializers. I wrote a unit test to reproduce
> the problem (attached) which produces this:
> {noformat}
> java.lang.NullPointerException
> at
> java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011)
> at
> java.util.concurrent.ConcurrentHashMap.putIfAbsent(ConcurrentHashMap.java:1535)
> at
> org.apache.geode.internal.InternalDataSerializer.updateSupportedClassesMap(InternalDataSerializer.java:1079)
> at
> org.apache.geode.internal.DataSerializerHolderJUnitTest$1.run(DataSerializerHolderJUnitTest.java:72)
> {noformat}
> The problem is in the idsToHolders map in InternalDataSerializer. This map is
> initialized with a "holder" object that knows the name and ID of a
> DataSerializer. During tcp/ip connection formation one of these is created
> when processing a list of DataSerializers sent to the client by the server as
> part of the handshake. Then the server sends a map of the names of classes
> supported by the serializers. It's in this second step that we're hitting the
> NPE because some other thread has resolved the holder into an actual class
> and has removed the holder from the idsToHolders map. This can be done in any
> of three other methods in InternalDataSerializer that are used as a matter of
> course in serializing/deserializing objects.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5201) Categorize all DUnit and integration tests by component
[ https://issues.apache.org/jira/browse/GEODE-5201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5201: -- Labels: pull-request-available (was: ) > Categorize all DUnit and integration tests by component > --- > > Key: GEODE-5201 > URL: https://issues.apache.org/jira/browse/GEODE-5201 > Project: Geode > Issue Type: Task >Reporter: Alexander Murmann >Assignee: Alexander Murmann >Priority: Major > Labels: pull-request-available > > DUnit and Integration tests are expensive to run. While working on a > particular component, I want a way to only run tests directly related to that > component. Categorizing these tests will enable that and also allow for > pipeline jobs dedicated to a specific component. This makes it easier to > identify what might have broken and also can be used as a way of introducing > more parallelism to our long running pipeline. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5200) Correct docs for use-cluster-configuration property
[ https://issues.apache.org/jira/browse/GEODE-5200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472230#comment-16472230 ] ASF subversion and git services commented on GEODE-5200: Commit 4c851fc6cf49d62abf6683491b6646b12d00b93a in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4c851fc ] GEODE-5200 Correct docs for use-cluster-configuration property (#1949) > Correct docs for use-cluster-configuration property > --- > > Key: GEODE-5200 > URL: https://issues.apache.org/jira/browse/GEODE-5200 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > In the section titled gemfire.properties and gfsecurity.properties (Geode > Properties), it says that the "use-cluster-configuration" property is only > applicable for data members (non-client and non-locator) in "Definition" > column. That does not match with what is in the 3rd column, which says which > components are affected. Instead of "L," the column should say "S." > File affected is reference/topics/gemfire_properties.html > This is a 1-character change to fix the docs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5172) AbstractRegionMap.txApplyPut should be refactored to use RegionMapPut
[ https://issues.apache.org/jira/browse/GEODE-5172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-5172. - Resolution: Fixed Fix Version/s: 1.7.0 > AbstractRegionMap.txApplyPut should be refactored to use RegionMapPut > - > > Key: GEODE-5172 > URL: https://issues.apache.org/jira/browse/GEODE-5172 > Project: Geode > Issue Type: Sub-task > Components: transactions >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.7.0 > > Time Spent: 50m > Remaining Estimate: 0h > > RegionMapPut (currently used for a non-tx put) and txApplyPut share much the > same code. > txApplyPut should be refactored to use the code in RegionMapPut. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5172) AbstractRegionMap.txApplyPut should be refactored to use RegionMapPut
[ https://issues.apache.org/jira/browse/GEODE-5172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472211#comment-16472211 ] ASF subversion and git services commented on GEODE-5172: Commit 6839dca5b3c63f2a068998d890ee56cf3c21e5ef in geode's branch refs/heads/develop from [~dschneider] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=6839dca ] GEODE-5172: refactor txApplyPut to reuse RegionMapPut (#1917) AbstractRegionMapPut has been introduced and has the common code used for both a non-tx put (RegionMapPut) and a transaction put being committed (RegionMapCommitPut). RegionMapCommitPut is used by txApplyPut. > AbstractRegionMap.txApplyPut should be refactored to use RegionMapPut > - > > Key: GEODE-5172 > URL: https://issues.apache.org/jira/browse/GEODE-5172 > Project: Geode > Issue Type: Sub-task > Components: transactions >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > RegionMapPut (currently used for a non-tx put) and txApplyPut share much the > same code. > txApplyPut should be refactored to use the code in RegionMapPut. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5198) NPE in DataSerializer registration when forming a client/server connection during handshake
[
https://issues.apache.org/jira/browse/GEODE-5198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472174#comment-16472174
]
ASF subversion and git services commented on GEODE-5198:
Commit a60b8d4237f0d27b9b31af304ae6ec3bfcdc077c in geode's branch
refs/heads/develop from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a60b8d4 ]
GEODE-5198 NPE in DataSerializer registration when forming a client/server
connection during handshake
If a holder can't be found do not record supported classes for it.
Absense of the holder, which had just been inserted into the
idsToHolders collection, means that another thread has resolved the
holder into an actual DataSerializer class and has removed the holder
and its supported classes.
This closes #1943
> NPE in DataSerializer registration when forming a client/server connection
> during handshake
> ---
>
> Key: GEODE-5198
> URL: https://issues.apache.org/jira/browse/GEODE-5198
> Project: Geode
> Issue Type: Improvement
> Components: client/server, serialization
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Attachments: DataSerializerHolderJUnitTest.java
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Someone hit an NPE when forming a connection to a server in an application
> making heavy use of custom DataSerializers. I wrote a unit test to reproduce
> the problem (attached) which produces this:
> {noformat}
> java.lang.NullPointerException
> at
> java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011)
> at
> java.util.concurrent.ConcurrentHashMap.putIfAbsent(ConcurrentHashMap.java:1535)
> at
> org.apache.geode.internal.InternalDataSerializer.updateSupportedClassesMap(InternalDataSerializer.java:1079)
> at
> org.apache.geode.internal.DataSerializerHolderJUnitTest$1.run(DataSerializerHolderJUnitTest.java:72)
> {noformat}
> The problem is in the idsToHolders map in InternalDataSerializer. This map is
> initialized with a "holder" object that knows the name and ID of a
> DataSerializer. During tcp/ip connection formation one of these is created
> when processing a list of DataSerializers sent to the client by the server as
> part of the handshake. Then the server sends a map of the names of classes
> supported by the serializers. It's in this second step that we're hitting the
> NPE because some other thread has resolved the holder into an actual class
> and has removed the holder from the idsToHolders map. This can be done in any
> of three other methods in InternalDataSerializer that are used as a matter of
> course in serializing/deserializing objects.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5200) Correct docs for use-cluster-configuration property
[ https://issues.apache.org/jira/browse/GEODE-5200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-5200: -- Labels: pull-request-available (was: ) > Correct docs for use-cluster-configuration property > --- > > Key: GEODE-5200 > URL: https://issues.apache.org/jira/browse/GEODE-5200 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > > In the section titled gemfire.properties and gfsecurity.properties (Geode > Properties), it says that the "use-cluster-configuration" property is only > applicable for data members (non-client and non-locator) in "Definition" > column. That does not match with what is in the 3rd column, which says which > components are affected. Instead of "L," the column should say "S." > File affected is reference/topics/gemfire_properties.html > This is a 1-character change to fix the docs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4814) Categorize FunctionService Tests
[ https://issues.apache.org/jira/browse/GEODE-4814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-4814: - Issue Type: Sub-task (was: Task) Parent: GEODE-5201 > Categorize FunctionService Tests > > > Key: GEODE-4814 > URL: https://issues.apache.org/jira/browse/GEODE-4814 > Project: Geode > Issue Type: Sub-task > Components: functions >Reporter: Jason Huynh >Assignee: Jason Huynh >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > add a new FunctionServiceTest interface and categorize all relevant dunit and > integration tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4779) Categorize OQL Query and Index Tests
[ https://issues.apache.org/jira/browse/GEODE-4779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-4779: - Issue Type: Sub-task (was: Task) Parent: GEODE-5201 > Categorize OQL Query and Index Tests > > > Key: GEODE-4779 > URL: https://issues.apache.org/jira/browse/GEODE-4779 > Project: Geode > Issue Type: Sub-task > Components: querying >Reporter: Jason Huynh >Assignee: Jason Huynh >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > Add a new category for tests and mark query and index tests appropriately -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4813) Categorize register interest tests
[ https://issues.apache.org/jira/browse/GEODE-4813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-4813: - Issue Type: Sub-task (was: Task) Parent: GEODE-5201 > Categorize register interest tests > -- > > Key: GEODE-4813 > URL: https://issues.apache.org/jira/browse/GEODE-4813 > Project: Geode > Issue Type: Sub-task > Components: client queues >Reporter: Jason Huynh >Assignee: Jason Huynh >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Add the ClientSubscription category to all register interest tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4783) Categorize Management tests
[ https://issues.apache.org/jira/browse/GEODE-4783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-4783: - Issue Type: Sub-task (was: Task) Parent: GEODE-5201 > Categorize Management tests > --- > > Key: GEODE-4783 > URL: https://issues.apache.org/jira/browse/GEODE-4783 > Project: Geode > Issue Type: Sub-task > Components: management >Affects Versions: 1.5.0 >Reporter: Kenneth Howe >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Add Category annotation for management integration and distributed tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4784) Categorize Security tests
[ https://issues.apache.org/jira/browse/GEODE-4784?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-4784: - Issue Type: Sub-task (was: Task) Parent: GEODE-5201 > Categorize Security tests > - > > Key: GEODE-4784 > URL: https://issues.apache.org/jira/browse/GEODE-4784 > Project: Geode > Issue Type: Sub-task > Components: security >Affects Versions: 1.5.0 >Reporter: Kenneth Howe >Priority: Major > > Add Category annotation for security integration and distributed tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4780) Categorize CQ tests
[ https://issues.apache.org/jira/browse/GEODE-4780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-4780: - Issue Type: Sub-task (was: Task) Parent: GEODE-5201 > Categorize CQ tests > --- > > Key: GEODE-4780 > URL: https://issues.apache.org/jira/browse/GEODE-4780 > Project: Geode > Issue Type: Sub-task > Components: cq >Reporter: Jason Huynh >Assignee: Jason Huynh >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Add a CQTest category and categorize all cq tests -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4940) Categorize REST admin tests
[ https://issues.apache.org/jira/browse/GEODE-4940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-4940: - Issue Type: Sub-task (was: Task) Parent: GEODE-5201 > Categorize REST admin tests > --- > > Key: GEODE-4940 > URL: https://issues.apache.org/jira/browse/GEODE-4940 > Project: Geode > Issue Type: Sub-task > Components: rest (admin) >Affects Versions: 1.5.0 >Reporter: Kenneth Howe >Assignee: Kenneth Howe >Priority: Major > > Add Category annotation for Admin REST integration and distributed tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5201) Categorize all DUnit and integration tests by component
[ https://issues.apache.org/jira/browse/GEODE-5201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann reassigned GEODE-5201: Assignee: Alexander Murmann > Categorize all DUnit and integration tests by component > --- > > Key: GEODE-5201 > URL: https://issues.apache.org/jira/browse/GEODE-5201 > Project: Geode > Issue Type: Task >Reporter: Alexander Murmann >Assignee: Alexander Murmann >Priority: Major > > DUnit and Integration tests are expensive to run. While working on a > particular component, I want a way to only run tests directly related to that > component. Categorizing these tests will enable that and also allow for > pipeline jobs dedicated to a specific component. This makes it easier to > identify what might have broken and also can be used as a way of introducing > more parallelism to our long running pipeline. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5011) Refactor Commands to use *ResultModel
[ https://issues.apache.org/jira/browse/GEODE-5011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16472000#comment-16472000 ] ASF subversion and git services commented on GEODE-5011: Commit 8ed21ab9e2ffc3d40d5909d1d124930a93282e9c in geode's branch refs/heads/develop from [~jens.deppe] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=8ed21ab ] GEODE-5011: Convert 'Data' commands to ResultModel (#1945) > Refactor Commands to use *ResultModel > - > > Key: GEODE-5011 > URL: https://issues.apache.org/jira/browse/GEODE-5011 > Project: Geode > Issue Type: Sub-task > Components: gfsh >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-5011) Refactor Commands to use *ResultModel
[ https://issues.apache.org/jira/browse/GEODE-5011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16471905#comment-16471905 ] ASF subversion and git services commented on GEODE-5011: Commit 4f330c3e6e6a5fafff3d5d32852c320b9729277b in geode's branch refs/heads/develop from [~jens.deppe] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4f330c3 ] Revert "GEODE-5011: Convert 'Data' commands to ResultModel (#1945)" This reverts commit f1c6b560442f2f23aa9240b3550d9d664e094c7c. > Refactor Commands to use *ResultModel > - > > Key: GEODE-5011 > URL: https://issues.apache.org/jira/browse/GEODE-5011 > Project: Geode > Issue Type: Sub-task > Components: gfsh >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
