[jira] [Created] (GEODE-4747) CI Failure :org.apache.geode.cache.lucene.internal.repository.IndexRepositoryImplJUnitTest - testUpdateAndRemoveBinaryKeys
nabarun created GEODE-4747:
--
Summary: CI Failure
:org.apache.geode.cache.lucene.internal.repository.IndexRepositoryImplJUnitTest
- testUpdateAndRemoveBinaryKeys
Key: GEODE-4747
URL: https://issues.apache.org/jira/browse/GEODE-4747
Project: Geode
Issue Type: Bug
Components: lucene
Reporter: nabarun
{noformat}
org.apache.geode.InternalGemFireError: java.io.InvalidClassException: filter
status: REJECTED
at
org.apache.geode.cache.lucene.internal.repository.serializer.SerializerUtil.keyFromBytes(SerializerUtil.java:164)
at
org.apache.geode.cache.lucene.internal.repository.serializer.SerializerUtil.getKey(SerializerUtil.java:132)
at
org.apache.geode.cache.lucene.internal.repository.IndexRepositoryImpl.query(IndexRepositoryImpl.java:150)
at
org.apache.geode.cache.lucene.internal.repository.IndexRepositoryImplJUnitTest.checkQuery(IndexRepositoryImplJUnitTest.java:259)
at
org.apache.geode.cache.lucene.internal.repository.IndexRepositoryImplJUnitTest.updateAndRemove(IndexRepositoryImplJUnitTest.java:239)
at
org.apache.geode.cache.lucene.internal.repository.IndexRepositoryImplJUnitTest.testUpdateAndRemoveBinaryKeys(IndexRepositoryImplJUnitTest.java:132)
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
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
at
org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
at
org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
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
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at
org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at
org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
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
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at
org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at
org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:147)
at
org.gradle.internal.remote.internal.hub.MessageHubBackedOb
[jira] [Commented] (GEODE-2667) Need API to destroy gateway receiver
[
https://issues.apache.org/jira/browse/GEODE-2667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377872#comment-16377872
]
ASF subversion and git services commented on GEODE-2667:
Commit c00ce5390b293b8a9e2fa5a42f5d1fd36d7f430d in geode's branch
refs/heads/develop from [~huynhja]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=c00ce53 ]
GEODE-2667: Reword javaDoc for destroy gateway receiver (#1501)
> Need API to destroy gateway receiver
> -
>
> Key: GEODE-2667
> URL: https://issues.apache.org/jira/browse/GEODE-2667
> Project: Geode
> Issue Type: Bug
> Components: docs, wan
>Reporter: Swapnil Bawaskar
>Assignee: Jason Huynh
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.5.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> A {{GatewayReceiver}} can be created from {{GatewayReceiverFactory}},
> however, there is no API for destroying the {{GatewayReceiver}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-3915) supply arguments over gfsh while initializing Declarable
[ https://issues.apache.org/jira/browse/GEODE-3915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller resolved GEODE-3915. Resolution: Fixed > supply arguments over gfsh while initializing Declarable > > > Key: GEODE-3915 > URL: https://issues.apache.org/jira/browse/GEODE-3915 > Project: Geode > Issue Type: Sub-task > Components: docs, gfsh >Reporter: Swapnil Bawaskar >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > User implementations of the Declarable interface may want to pass in > arguments while the class is being initialized. We should provide ability to > pass these arguments from gfsh. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4737) User Guide: Describe addition of JSON specs to gfsh commands
[ https://issues.apache.org/jira/browse/GEODE-4737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karen Smoler Miller resolved GEODE-4737. Resolution: Fixed Fix Version/s: 1.5.0 > User Guide: Describe addition of JSON specs to gfsh commands > > > Key: GEODE-4737 > URL: https://issues.apache.org/jira/browse/GEODE-4737 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Some new gfsh commands can take a JSON spec. Examples include `alter region > --entry-idle-time-custom-expiry` and `create region --cache-listener`. > Add a general description of the syntax to the gfsh section of the manual so > individual command-reference entries can point to a centralized explanation, > rather than repeating the syntax details each time. > One developer has requested that we state that the JSON parser recognizes > double quotes as well as single quotes. Some JSON parsers accept only single > quotes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-3915) supply arguments over gfsh while initializing Declarable
[ https://issues.apache.org/jira/browse/GEODE-3915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377870#comment-16377870 ] ASF subversion and git services commented on GEODE-3915: Commit cd5edfd12c0229ab2f8ee5d516e34e6df5a1c9dd in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=cd5edfd ] GEODE-3915 Document use of JSON spec for gfsh create and alter region (#1502) - cache-listener, cache-loader, and cache-writer command-line options can add a JSON specification to the fq class name that are used to populate the init method's parameter for those classes that implement Declarable - see GEODE-4737 for the task to document what the JSON should look like > supply arguments over gfsh while initializing Declarable > > > Key: GEODE-3915 > URL: https://issues.apache.org/jira/browse/GEODE-3915 > Project: Geode > Issue Type: Sub-task > Components: docs, gfsh >Reporter: Swapnil Bawaskar >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > User implementations of the Declarable interface may want to pass in > arguments while the class is being initialized. We should provide ability to > pass these arguments from gfsh. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4737) User Guide: Describe addition of JSON specs to gfsh commands
[ https://issues.apache.org/jira/browse/GEODE-4737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377871#comment-16377871 ] ASF subversion and git services commented on GEODE-4737: Commit cd5edfd12c0229ab2f8ee5d516e34e6df5a1c9dd in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=cd5edfd ] GEODE-3915 Document use of JSON spec for gfsh create and alter region (#1502) - cache-listener, cache-loader, and cache-writer command-line options can add a JSON specification to the fq class name that are used to populate the init method's parameter for those classes that implement Declarable - see GEODE-4737 for the task to document what the JSON should look like > User Guide: Describe addition of JSON specs to gfsh commands > > > Key: GEODE-4737 > URL: https://issues.apache.org/jira/browse/GEODE-4737 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > Some new gfsh commands can take a JSON spec. Examples include `alter region > --entry-idle-time-custom-expiry` and `create region --cache-listener`. > Add a general description of the syntax to the gfsh section of the manual so > individual command-reference entries can point to a centralized explanation, > rather than repeating the syntax details each time. > One developer has requested that we state that the JSON parser recognizes > double quotes as well as single quotes. Some JSON parsers accept only single > quotes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4685) Replace setPdxReadSerialized in org.apache.geode.cache.lucene.internal
[ https://issues.apache.org/jira/browse/GEODE-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377865#comment-16377865 ] ASF subversion and git services commented on GEODE-4685: Commit 402e063ed4280fc41bfbe9578fdc0ee4edae6f97 in geode's branch refs/heads/feature/GEODE-4685 from Udo [ https://gitbox.apache.org/repos/asf?p=geode.git;h=402e063 ] GEODE-4685: spotless > Replace setPdxReadSerialized in org.apache.geode.cache.lucene.internal > -- > > Key: GEODE-4685 > URL: https://issues.apache.org/jira/browse/GEODE-4685 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: nabarun >Assignee: Udo Kohlmeyer >Priority: Major > > Replace with the solution from GEODE-4679 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4737) User Guide: Describe addition of JSON specs to gfsh commands
[ https://issues.apache.org/jira/browse/GEODE-4737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377868#comment-16377868 ] ASF subversion and git services commented on GEODE-4737: Commit 3eaa095b0e0ba97e83ebce78b1e0163f0e4dba63 in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3eaa095 ] GEODE-4737 Document JSON spec for gfsh command options (#1509) * GEODE-4737 Document JSON spec for gfsh command options * GEODE-4737 Revise gfsh command JSON spec per review > User Guide: Describe addition of JSON specs to gfsh commands > > > Key: GEODE-4737 > URL: https://issues.apache.org/jira/browse/GEODE-4737 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > Some new gfsh commands can take a JSON spec. Examples include `alter region > --entry-idle-time-custom-expiry` and `create region --cache-listener`. > Add a general description of the syntax to the gfsh section of the manual so > individual command-reference entries can point to a centralized explanation, > rather than repeating the syntax details each time. > One developer has requested that we state that the JSON parser recognizes > double quotes as well as single quotes. Some JSON parsers accept only single > quotes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4737) User Guide: Describe addition of JSON specs to gfsh commands
[ https://issues.apache.org/jira/browse/GEODE-4737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377866#comment-16377866 ] ASF subversion and git services commented on GEODE-4737: Commit 3eaa095b0e0ba97e83ebce78b1e0163f0e4dba63 in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3eaa095 ] GEODE-4737 Document JSON spec for gfsh command options (#1509) * GEODE-4737 Document JSON spec for gfsh command options * GEODE-4737 Revise gfsh command JSON spec per review > User Guide: Describe addition of JSON specs to gfsh commands > > > Key: GEODE-4737 > URL: https://issues.apache.org/jira/browse/GEODE-4737 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > Some new gfsh commands can take a JSON spec. Examples include `alter region > --entry-idle-time-custom-expiry` and `create region --cache-listener`. > Add a general description of the syntax to the gfsh section of the manual so > individual command-reference entries can point to a centralized explanation, > rather than repeating the syntax details each time. > One developer has requested that we state that the JSON parser recognizes > double quotes as well as single quotes. Some JSON parsers accept only single > quotes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4737) User Guide: Describe addition of JSON specs to gfsh commands
[ https://issues.apache.org/jira/browse/GEODE-4737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377867#comment-16377867 ] ASF subversion and git services commented on GEODE-4737: Commit 3eaa095b0e0ba97e83ebce78b1e0163f0e4dba63 in geode's branch refs/heads/develop from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3eaa095 ] GEODE-4737 Document JSON spec for gfsh command options (#1509) * GEODE-4737 Document JSON spec for gfsh command options * GEODE-4737 Revise gfsh command JSON spec per review > User Guide: Describe addition of JSON specs to gfsh commands > > > Key: GEODE-4737 > URL: https://issues.apache.org/jira/browse/GEODE-4737 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > Some new gfsh commands can take a JSON spec. Examples include `alter region > --entry-idle-time-custom-expiry` and `create region --cache-listener`. > Add a general description of the syntax to the gfsh section of the manual so > individual command-reference entries can point to a centralized explanation, > rather than repeating the syntax details each time. > One developer has requested that we state that the JSON parser recognizes > double quotes as well as single quotes. Some JSON parsers accept only single > quotes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-3948) Improve CQ performance under flaky network conditions
[ https://issues.apache.org/jira/browse/GEODE-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes reassigned GEODE-3948: -- Assignee: Dave Barnes (was: Joey McAllister) > Improve CQ performance under flaky network conditions > - > > Key: GEODE-3948 > URL: https://issues.apache.org/jira/browse/GEODE-3948 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Galen O'Sullivan >Assignee: Dave Barnes >Priority: Minor > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 2h > Remaining Estimate: 0h > > Client CQ connections occasionally stop receiving messages and become blocked > indefinitely. > This can be caused by a server that hangs or dies without sending a close > message, or by some firewalls. > The client already gets ping messages from the server, but currently ignores > them. Let's use those messages to detect a failed connection and close it. > Probably the client should follow the same logic and send ping messages if it > has sent no acks for a while, so that the server can also detect and close a > broken connection. > The timeout could be specified as a number and time interval, the ping > interval and the number of missed pings after which to fail. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4406) Improve granularity of permissions for new client protocol
[ https://issues.apache.org/jira/browse/GEODE-4406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-4406: -- Labels: pull-request-available (was: ) > Improve granularity of permissions for new client protocol > -- > > Key: GEODE-4406 > URL: https://issues.apache.org/jira/browse/GEODE-4406 > Project: Geode > Issue Type: New Feature > Components: client/server >Reporter: Galen O'Sullivan >Priority: Major > Labels: pull-request-available > > Currently, the new client protocol requires all DATA:READ permissions to do a > region.get() . If a user only has DATA:READ:regionName , they won't be > permitted to execute commands on the region, even though they have > permissions. We should fix this for all the other operations too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4738) EventSeqNum and versionVector in a region are accessed when they are not yet initialized
[
https://issues.apache.org/jira/browse/GEODE-4738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Shu resolved GEODE-4738.
-
Resolution: Fixed
Fix Version/s: 1.5.0
> EventSeqNum and versionVector in a region are accessed when they are not yet
> initialized
>
>
> Key: GEODE-4738
> URL: https://issues.apache.org/jira/browse/GEODE-4738
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.4.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.5.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> It is possible that eventSeqNum and versionVector are accessed when they are
> not initialized yet. This could cause transaction to fail on the node just
> start up.
> {noformat}
> Got unexpected exception org.apache.geode.cache.CommitIncompleteException:
> Incomplete commit of transaction TXId:
> rs-FullRegression-2018-02-10-05-01-42-client-1(bridgegemfire6_rs-FullRegression-2018-02-10-05-01-42-client-1_19376:19376):1030:4865.
> Caused by the following exceptions: From member:
> rs-FullRegression-2018-02-10-05-01-42-client-1(bridgegemfire4_rs-FullRegression-2018-02-10-05-01-42-client-1_15810:15810):1026
> java.lang.NullPointerException
> at
> org.apache.geode.internal.concurrent.Atomics.setIfGreater(Atomics.java:56)
> at
> org.apache.geode.internal.cache.BucketRegion.handleWANEvent(BucketRegion.java:576)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.txHandleWANEvent(AbstractRegionMap.java:2938)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.txApplyPut(AbstractRegionMap.java:2647)
> at
> org.apache.geode.internal.cache.LocalRegion.txApplyPut(LocalRegion.java:5068)
> at
> org.apache.geode.internal.cache.TXCommitMessage$RegionCommit.txApplyEntryOp(TXCommitMessage.java:1287)
> at
> org.apache.geode.internal.cache.TXCommitMessage$RegionCommit$FarSideEntryOp.process(TXCommitMessage.java:1597)
> at
> org.apache.geode.internal.cache.TXCommitMessage.basicProcessOps(TXCommitMessage.java:711)
> at
> org.apache.geode.internal.cache.TXCommitMessage.basicProcess(TXCommitMessage.java:638)
> at
> org.apache.geode.internal.cache.TXCommitMessage$CommitProcessMessage.basicProcess(TXCommitMessage.java:1784)
> at
> org.apache.geode.internal.cache.TXCommitMessage$CommitProcessForTXIdMessage.process(TXCommitMessage.java:1747)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:448)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:1117)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:108)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$4$1.run(ClusterDistributionManager.java:788)
> at java.lang.Thread.run(Thread.java:748).
> at
> org.apache.geode.internal.cache.TXCommitMessage$CommitExceptionCollectingException.handlePotentialCommitFailure(TXCommitMessage.java:2203)
> at
> org.apache.geode.internal.cache.TXCommitMessage$CommitReplyProcessor.waitForCommitCompletion(TXCommitMessage.java:2104)
> at
> org.apache.geode.internal.cache.TXCommitMessage.send(TXCommitMessage.java:418)
> at org.apache.geode.internal.cache.TXState.commit(TXState.java:473)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.commit(TXStateProxyImpl.java:228)
> at
> org.apache.geode.internal.cache.TXManagerImpl.commit(TXManagerImpl.java:405)
> at
> org.apache.geode.internal.cache.TXRemoteCommitMessage.operateOnTx(TXRemoteCommitMessage.java:98)
> at org.apache.geode.internal.cache.TXMessage.process(TXMessage.java:94)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:448)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:1117)
> at
> org.apache.geode.distributed.internal
[jira] [Commented] (GEODE-4738) EventSeqNum and versionVector in a region are accessed when they are not yet initialized
[
https://issues.apache.org/jira/browse/GEODE-4738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377841#comment-16377841
]
ASF subversion and git services commented on GEODE-4738:
Commit 3dad0a3a0a467bd5cf388af31ccfc69ad0c28443 in geode's branch
refs/heads/develop from [~eshu]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3dad0a3 ]
GEODE-4738: move eventSeqNum and versionVector setting in constructors. (#1504)
* GEODE-4738: move eventSeqNum and versionVector setting in constructors.
> EventSeqNum and versionVector in a region are accessed when they are not yet
> initialized
>
>
> Key: GEODE-4738
> URL: https://issues.apache.org/jira/browse/GEODE-4738
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.4.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> It is possible that eventSeqNum and versionVector are accessed when they are
> not initialized yet. This could cause transaction to fail on the node just
> start up.
> {noformat}
> Got unexpected exception org.apache.geode.cache.CommitIncompleteException:
> Incomplete commit of transaction TXId:
> rs-FullRegression-2018-02-10-05-01-42-client-1(bridgegemfire6_rs-FullRegression-2018-02-10-05-01-42-client-1_19376:19376):1030:4865.
> Caused by the following exceptions: From member:
> rs-FullRegression-2018-02-10-05-01-42-client-1(bridgegemfire4_rs-FullRegression-2018-02-10-05-01-42-client-1_15810:15810):1026
> java.lang.NullPointerException
> at
> org.apache.geode.internal.concurrent.Atomics.setIfGreater(Atomics.java:56)
> at
> org.apache.geode.internal.cache.BucketRegion.handleWANEvent(BucketRegion.java:576)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.txHandleWANEvent(AbstractRegionMap.java:2938)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.txApplyPut(AbstractRegionMap.java:2647)
> at
> org.apache.geode.internal.cache.LocalRegion.txApplyPut(LocalRegion.java:5068)
> at
> org.apache.geode.internal.cache.TXCommitMessage$RegionCommit.txApplyEntryOp(TXCommitMessage.java:1287)
> at
> org.apache.geode.internal.cache.TXCommitMessage$RegionCommit$FarSideEntryOp.process(TXCommitMessage.java:1597)
> at
> org.apache.geode.internal.cache.TXCommitMessage.basicProcessOps(TXCommitMessage.java:711)
> at
> org.apache.geode.internal.cache.TXCommitMessage.basicProcess(TXCommitMessage.java:638)
> at
> org.apache.geode.internal.cache.TXCommitMessage$CommitProcessMessage.basicProcess(TXCommitMessage.java:1784)
> at
> org.apache.geode.internal.cache.TXCommitMessage$CommitProcessForTXIdMessage.process(TXCommitMessage.java:1747)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:448)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:1117)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:108)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$4$1.run(ClusterDistributionManager.java:788)
> at java.lang.Thread.run(Thread.java:748).
> at
> org.apache.geode.internal.cache.TXCommitMessage$CommitExceptionCollectingException.handlePotentialCommitFailure(TXCommitMessage.java:2203)
> at
> org.apache.geode.internal.cache.TXCommitMessage$CommitReplyProcessor.waitForCommitCompletion(TXCommitMessage.java:2104)
> at
> org.apache.geode.internal.cache.TXCommitMessage.send(TXCommitMessage.java:418)
> at org.apache.geode.internal.cache.TXState.commit(TXState.java:473)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.commit(TXStateProxyImpl.java:228)
> at
> org.apache.geode.internal.cache.TXManagerImpl.commit(TXManagerImpl.java:405)
> at
> org.apache.geode.internal.cache.TXRemoteCommitMessage.operateOnTx(TXRemoteCommitMessage.java:98)
> at org.apache.geode.internal.cache.TXMessage.process(TXMessage.java:94)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:448)
> at
> java.util.concurrent
[jira] [Commented] (GEODE-4738) EventSeqNum and versionVector in a region are accessed when they are not yet initialized
[
https://issues.apache.org/jira/browse/GEODE-4738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377842#comment-16377842
]
ASF subversion and git services commented on GEODE-4738:
Commit 3dad0a3a0a467bd5cf388af31ccfc69ad0c28443 in geode's branch
refs/heads/develop from [~eshu]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=3dad0a3 ]
GEODE-4738: move eventSeqNum and versionVector setting in constructors. (#1504)
* GEODE-4738: move eventSeqNum and versionVector setting in constructors.
> EventSeqNum and versionVector in a region are accessed when they are not yet
> initialized
>
>
> Key: GEODE-4738
> URL: https://issues.apache.org/jira/browse/GEODE-4738
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.4.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> It is possible that eventSeqNum and versionVector are accessed when they are
> not initialized yet. This could cause transaction to fail on the node just
> start up.
> {noformat}
> Got unexpected exception org.apache.geode.cache.CommitIncompleteException:
> Incomplete commit of transaction TXId:
> rs-FullRegression-2018-02-10-05-01-42-client-1(bridgegemfire6_rs-FullRegression-2018-02-10-05-01-42-client-1_19376:19376):1030:4865.
> Caused by the following exceptions: From member:
> rs-FullRegression-2018-02-10-05-01-42-client-1(bridgegemfire4_rs-FullRegression-2018-02-10-05-01-42-client-1_15810:15810):1026
> java.lang.NullPointerException
> at
> org.apache.geode.internal.concurrent.Atomics.setIfGreater(Atomics.java:56)
> at
> org.apache.geode.internal.cache.BucketRegion.handleWANEvent(BucketRegion.java:576)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.txHandleWANEvent(AbstractRegionMap.java:2938)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.txApplyPut(AbstractRegionMap.java:2647)
> at
> org.apache.geode.internal.cache.LocalRegion.txApplyPut(LocalRegion.java:5068)
> at
> org.apache.geode.internal.cache.TXCommitMessage$RegionCommit.txApplyEntryOp(TXCommitMessage.java:1287)
> at
> org.apache.geode.internal.cache.TXCommitMessage$RegionCommit$FarSideEntryOp.process(TXCommitMessage.java:1597)
> at
> org.apache.geode.internal.cache.TXCommitMessage.basicProcessOps(TXCommitMessage.java:711)
> at
> org.apache.geode.internal.cache.TXCommitMessage.basicProcess(TXCommitMessage.java:638)
> at
> org.apache.geode.internal.cache.TXCommitMessage$CommitProcessMessage.basicProcess(TXCommitMessage.java:1784)
> at
> org.apache.geode.internal.cache.TXCommitMessage$CommitProcessForTXIdMessage.process(TXCommitMessage.java:1747)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:448)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:1117)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:108)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$4$1.run(ClusterDistributionManager.java:788)
> at java.lang.Thread.run(Thread.java:748).
> at
> org.apache.geode.internal.cache.TXCommitMessage$CommitExceptionCollectingException.handlePotentialCommitFailure(TXCommitMessage.java:2203)
> at
> org.apache.geode.internal.cache.TXCommitMessage$CommitReplyProcessor.waitForCommitCompletion(TXCommitMessage.java:2104)
> at
> org.apache.geode.internal.cache.TXCommitMessage.send(TXCommitMessage.java:418)
> at org.apache.geode.internal.cache.TXState.commit(TXState.java:473)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.commit(TXStateProxyImpl.java:228)
> at
> org.apache.geode.internal.cache.TXManagerImpl.commit(TXManagerImpl.java:405)
> at
> org.apache.geode.internal.cache.TXRemoteCommitMessage.operateOnTx(TXRemoteCommitMessage.java:98)
> at org.apache.geode.internal.cache.TXMessage.process(TXMessage.java:94)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:448)
> at
> java.util.concurrent
[jira] [Assigned] (GEODE-4101) Replace Redirection Sytem Properties by --redirect-output flag in GFSH commands
[
https://issues.apache.org/jira/browse/GEODE-4101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Barnes reassigned GEODE-4101:
--
Assignee: Dave Barnes (was: Kenneth Howe)
> Replace Redirection Sytem Properties by --redirect-output flag in GFSH
> commands
> ---
>
> Key: GEODE-4101
> URL: https://issues.apache.org/jira/browse/GEODE-4101
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh
>Reporter: Juan José Ramos Cassella
>Assignee: Dave Barnes
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.5.0
>
>
> Currently GEODE is "swallowing" all output sent to stdout and stderr by
> default and there's no way of changing this behavior when starting members
> through gfsh.
> This, between other things, prevents users from playing around with
> {{System.out.println()}} during development phases, there could even be
> certain scenarios where some critical piece of information that comes out
> through stdout somehow bypassed all the logging frameworks. Not only that,
> but this also prevents the user from getting thread dumps by executing a
> plain {{kill -3}} or {{kill -QUIT}} using the processId, which is critical in
> troubleshooting.
> Currently there are two internal flags that can be used to prevent this
> default behavior, both have to be used at the same time and both are very
> counterintuitive {{gemfire.OSProcess.ENABLE_OUTPUT_REDIRECTION=true}} and
> {{gemfire.OSProcess.DISABLE_OUTPUT_REDIRECTION=false}}. These flags, however,
> don't work at all when starting members through {{gfsh}}, and that's because
> the relevant commands wrongly assume that the flags are already part of the
> system properties too early in the lifecylce execution of the command:
> {code:title=StartLocatorCommand.java|borderStyle=solid}
> @CliCommand(value = CliStrings.START_LOCATOR, help =
> CliStrings.START_LOCATOR__HELP)
> @CliMetaData(shellOnly = true, relatedTopic =
> {CliStrings.TOPIC_GEODE_LOCATOR, CliStrings.TOPIC_GEODE_LIFECYCLE})
> public Result startLocator(...) throws Exception {
> (...)
> final boolean redirectOutput =
> Boolean.getBoolean(OSProcess.ENABLE_OUTPUT_REDIRECTION_PROPERTY);
> LocatorLauncher.Builder locatorLauncherBuilder =
> new LocatorLauncher.Builder()
> .setRedirectOutput(redirectOutput)
> (...)
> }
> {code}
> {code:title=StartServerCommand.java|borderStyle=solid}
> @CliCommand(value = CliStrings.START_SERVER, help =
> CliStrings.START_SERVER__HELP)
> @CliMetaData(shellOnly = true, relatedTopic = {CliStrings.TOPIC_GEODE_SERVER,
> CliStrings.TOPIC_GEODE_LIFECYCLE})
> public Result startServer(...) throws Exception {
> (...)
> final boolean redirectOutput =
> Boolean.getBoolean(OSProcess.ENABLE_OUTPUT_REDIRECTION_PROPERTY);
> ServerLauncher.Builder serverLauncherBuilder =
> new ServerLauncher.Builder()
> .setRedirectOutput(redirectOutput)
> (...)
> {code}
> At this stage during the execution, the system properties used when starting
> the members haven't been fully parsed yet and the flags only present within
> the {{sun.java.command}} system property, so
> {{Boolean.getBoolean(OSProcess.ENABLE_OUTPUT_REDIRECTION_PROPERTY)}} will
> always return {{false}}.
> The goal of the current JIRA is to add a {{--redirect-ouput}} flag to the
> start commands in {{GFSH}} and deprecate the properties
> {{OSProcess.DISABLE_OUTPUT_REDIRECTION}} and
> {{OSProcess.ENABLE_OUTPUT_REDIRECTION}}; unfortunately they can't be directly
> deleted because, even when they are internal, they've been referenced several
> times in external articles to workaround older issues.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-4693) JDBCLoader on region with a pdx-class-name causes exception during deserialization when a get is done
[ https://issues.apache.org/jira/browse/GEODE-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade reassigned GEODE-4693: Assignee: Anilkumar Gingade > JDBCLoader on region with a pdx-class-name causes exception during > deserialization when a get is done > - > > Key: GEODE-4693 > URL: https://issues.apache.org/jira/browse/GEODE-4693 > Project: Geode > Issue Type: Bug > Components: extensions, regions >Affects Versions: 1.4.0 >Reporter: Fred Krone >Assignee: Anilkumar Gingade >Priority: Major > > When Region.get() is performed with JDBCLoader and pdx-class-name, the > JDBCLoader always creates a PdxInstance whose fields are all of type object. > If the domain class has the fields as some other type, for example string or > int, then deserialization will fail. > Workaround at this time is: > # Don't set the pdx-class-name on the jdbc region mapping. This will cause > deserialization to never happen since the data will remain a PdxInstance. > # Have all your domain class fields serialized as pdx object fields. This > can be hard to do with the ReflectionBasedAutoSerializer so the > recommendation is to use PdxSerializable or your own PdxSerializer. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4693) JDBCLoader on region with a pdx-class-name causes exception during deserialization when a get is done
[ https://issues.apache.org/jira/browse/GEODE-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-4693: - Description: When Region.get() is performed with JDBCLoader and pdx-class-name, the JDBCLoader always creates a PdxInstance whose fields are all of type object. If the domain class has the fields as some other type, for example string or int, then deserialization will fail. Workaround at this time is: # Don't set the pdx-class-name on the jdbc region mapping. This will cause deserialization to never happen since the data will remain a PdxInstance. # Have all your domain class fields serialized as pdx object fields. This can be hard to do with the ReflectionBasedAutoSerializer so the recommendation is to use PdxSerializable or your own PdxSerializer. was: Acceptance Criteria: _Given_ I have an empty region with a pdx-type mapped to a jdbc connection _When_ I get an entry from the region _Then_ I it should pull a dataset from the backing db and convert it to the pdx-type associated with the region. When reading from region and the region mapping has a pdx class name and no pdx type exists for that class or it exists but is missing at least one of the fields for the columns on the row. > JDBCLoader on region with a pdx-class-name causes exception during > deserialization when a get is done > - > > Key: GEODE-4693 > URL: https://issues.apache.org/jira/browse/GEODE-4693 > Project: Geode > Issue Type: Bug > Components: extensions, regions >Affects Versions: 1.4.0 >Reporter: Fred Krone >Priority: Major > > When Region.get() is performed with JDBCLoader and pdx-class-name, the > JDBCLoader always creates a PdxInstance whose fields are all of type object. > If the domain class has the fields as some other type, for example string or > int, then deserialization will fail. > Workaround at this time is: > # Don't set the pdx-class-name on the jdbc region mapping. This will cause > deserialization to never happen since the data will remain a PdxInstance. > # Have all your domain class fields serialized as pdx object fields. This > can be hard to do with the ReflectionBasedAutoSerializer so the > recommendation is to use PdxSerializable or your own PdxSerializer. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4693) JDBCLoader on region with a pdx-class-name causes exception during deserialization when a get is done
[ https://issues.apache.org/jira/browse/GEODE-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-4693: - Summary: JDBCLoader on region with a pdx-class-name causes exception during deserialization when a get is done (was: JDBCLoader on region with a pdx-class-name throw exceptions during deserialization) > JDBCLoader on region with a pdx-class-name causes exception during > deserialization when a get is done > - > > Key: GEODE-4693 > URL: https://issues.apache.org/jira/browse/GEODE-4693 > Project: Geode > Issue Type: Bug > Components: extensions, regions >Affects Versions: 1.4.0 >Reporter: Fred Krone >Priority: Major > > Acceptance Criteria: > _Given_ I have an empty region with a pdx-type mapped to a jdbc connection > _When_ I get an entry from the region > _Then_ I it should pull a dataset from the backing db and convert it to the > pdx-type associated with the region. > > When reading from region and the region mapping has a pdx class name and no > pdx type exists for that class or it exists but is missing at least one of > the fields for the columns on the row. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4693) JDBCLoader on region with a pdx-class-name throw exceptions during deserialization
[ https://issues.apache.org/jira/browse/GEODE-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-4693: - Issue Type: Bug (was: Improvement) > JDBCLoader on region with a pdx-class-name throw exceptions during > deserialization > -- > > Key: GEODE-4693 > URL: https://issues.apache.org/jira/browse/GEODE-4693 > Project: Geode > Issue Type: Bug > Components: extensions, regions >Affects Versions: 1.4.0 >Reporter: Fred Krone >Priority: Major > > Acceptance Criteria: > _Given_ I have an empty region with a pdx-type mapped to a jdbc connection > _When_ I get an entry from the region > _Then_ I it should pull a dataset from the backing db and convert it to the > pdx-type associated with the region. > > When reading from region and the region mapping has a pdx class name and no > pdx type exists for that class or it exists but is missing at least one of > the fields for the columns on the row. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4693) JDBCLoader on region with a pdx-class-name throw exceptions during deserialization
[ https://issues.apache.org/jira/browse/GEODE-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-4693: - Affects Version/s: 1.4.0 > JDBCLoader on region with a pdx-class-name throw exceptions during > deserialization > -- > > Key: GEODE-4693 > URL: https://issues.apache.org/jira/browse/GEODE-4693 > Project: Geode > Issue Type: Bug > Components: extensions, regions >Affects Versions: 1.4.0 >Reporter: Fred Krone >Priority: Major > > Acceptance Criteria: > _Given_ I have an empty region with a pdx-type mapped to a jdbc connection > _When_ I get an entry from the region > _Then_ I it should pull a dataset from the backing db and convert it to the > pdx-type associated with the region. > > When reading from region and the region mapping has a pdx class name and no > pdx type exists for that class or it exists but is missing at least one of > the fields for the columns on the row. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4693) JDBCLoader on region with a pdx-class-name throw exceptions during deserialization
[ https://issues.apache.org/jira/browse/GEODE-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-4693: - Summary: JDBCLoader on region with a pdx-class-name throw exceptions during deserialization (was: Convert initial JDBC read with empty region to correct pdx-type) > JDBCLoader on region with a pdx-class-name throw exceptions during > deserialization > -- > > Key: GEODE-4693 > URL: https://issues.apache.org/jira/browse/GEODE-4693 > Project: Geode > Issue Type: Improvement > Components: extensions, regions >Affects Versions: 1.4.0 >Reporter: Fred Krone >Priority: Major > > Acceptance Criteria: > _Given_ I have an empty region with a pdx-type mapped to a jdbc connection > _When_ I get an entry from the region > _Then_ I it should pull a dataset from the backing db and convert it to the > pdx-type associated with the region. > > When reading from region and the region mapping has a pdx class name and no > pdx type exists for that class or it exists but is missing at least one of > the fields for the columns on the row. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4693) Convert initial JDBC read with empty region to correct pdx-type
[ https://issues.apache.org/jira/browse/GEODE-4693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade updated GEODE-4693: - Description: Acceptance Criteria: _Given_ I have an empty region with a pdx-type mapped to a jdbc connection _When_ I get an entry from the region _Then_ I it should pull a dataset from the backing db and convert it to the pdx-type associated with the region. When reading from region and the region mapping has a pdx class name and no pdx type exists for that class or it exists but is missing at least one of the fields for the columns on the row. was: AC _Given_ I have an empty region with a pdx-type mapped to a jdbc connection _When_ I get an entry from the region _Then_ I it should pull a dataset from the backing db and convert it to the pdx-type associated with the region. > Convert initial JDBC read with empty region to correct pdx-type > --- > > Key: GEODE-4693 > URL: https://issues.apache.org/jira/browse/GEODE-4693 > Project: Geode > Issue Type: Improvement > Components: extensions, regions >Reporter: Fred Krone >Priority: Major > > Acceptance Criteria: > _Given_ I have an empty region with a pdx-type mapped to a jdbc connection > _When_ I get an entry from the region > _Then_ I it should pull a dataset from the backing db and convert it to the > pdx-type associated with the region. > > When reading from region and the region mapping has a pdx class name and no > pdx type exists for that class or it exists but is missing at least one of > the fields for the columns on the row. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4746) Protobuf server should catch Exceptions and return a reasonable response message to clients
[ https://issues.apache.org/jira/browse/GEODE-4746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-4746: -- Labels: pull-request-available (was: ) > Protobuf server should catch Exceptions and return a reasonable response > message to clients > --- > > Key: GEODE-4746 > URL: https://issues.apache.org/jira/browse/GEODE-4746 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > > Whenever possible, the protobuf server should catch exceptions and send a > response message back to the client. Currently, any exception on the server > is causing the server to close the socket, even for trivial things like a > typo in a query string. From the client side there is no information about > why the socket was closed. > We should catch exceptions and return the error message to the client without > closing the socket. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4740) CI Failure: LuceneIndexCommandsDUnitTest.listIndexWithStatsShouldReturnCorrectStats
[ https://issues.apache.org/jira/browse/GEODE-4740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-4740: -- Labels: pull-request-available (was: ) > CI Failure: > LuceneIndexCommandsDUnitTest.listIndexWithStatsShouldReturnCorrectStats > --- > > Key: GEODE-4740 > URL: https://issues.apache.org/jira/browse/GEODE-4740 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Jason Huynh >Priority: Major > Labels: pull-request-available > > This test failed in a recent concourse run > org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommandsDUnitTest > > listIndexWithStatsShouldReturnCorrectStats FAILED > java.lang.AssertionError: > Expecting: > <["3"]> > to contain exactly in any order: > <["2"]> > elements not found: > <["2"]> > and elements not expected: > <["3"]> > at > org.apache.geode.test.junit.assertions.CommandResultAssert.tableHasColumnWithExactValuesInAnyOrder(CommandResultAssert.java:179) > at > org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommandsDUnitTest.listIndexWithStatsShouldReturnCorrectStats(LuceneIndexCommandsDUnitTest.java:154) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4675) CI failure (suspect strings): DistributedSystemDisconnectedException: This connection to a distributed system has been disconnected reported as fatal log message during
[
https://issues.apache.org/jira/browse/GEODE-4675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-4675.
-
Resolution: Fixed
Fix Version/s: 1.5.0
> CI failure (suspect strings): DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected reported as fatal
> log message during shutdown
> -
>
> Key: GEODE-4675
> URL: https://issues.apache.org/jira/browse/GEODE-4675
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.5.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Darrel Schneider
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.5.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This failure occurred during CI on geode:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/140
> {noformat}
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderOffHeapDUnitTest
> > testPartitionedParallelPropagationHA 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 9339
> [fatal 2018/02/13 21:12:48.099 UTC tid=891]
> Unexpected exception:
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected.
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:911)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1499)
> at
> org.apache.geode.internal.cache.AbstractRegion.getDistributionManager(AbstractRegion.java:1757)
> at
> org.apache.geode.distributed.internal.DistributionAdvisor.getDistributionManager(DistributionAdvisor.java:380)
> at
> org.apache.geode.distributed.internal.DistributionAdvisor.notifyListenersMemberRemoved(DistributionAdvisor.java:1225)
> at
> org.apache.geode.distributed.internal.DistributionAdvisor.basicRemoveId(DistributionAdvisor.java:897)
> at
> org.apache.geode.distributed.internal.DistributionAdvisor.doRemoveId(DistributionAdvisor.java:964)
> at
> org.apache.geode.distributed.internal.DistributionAdvisor.removeId(DistributionAdvisor.java:926)
> at
> org.apache.geode.internal.cache.CacheDistributionAdvisor.removeId(CacheDistributionAdvisor.java:1183)
> at
> org.apache.geode.internal.cache.partitioned.RegionAdvisor.removeId(RegionAdvisor.java:391)
> at
> org.apache.geode.distributed.internal.DistributionAdvisor$1.memberDeparted(DistributionAdvisor.java:232)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberDepartedEvent.handleEvent(ClusterDistributionManager.java:4198)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEvent.handleEvent(ClusterDistributionManager.java:4127)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEvent.handleEvent(ClusterDistributionManager.java:4116)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.handleMemberEvent(ClusterDistributionManager.java:2218)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.access$900(ClusterDistributionManager.java:109)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEventInvoker.run(ClusterDistributionManager.java:2250)
> at java.lang.Thread.run(Thread.java:748)
> ---
> {noformat}
> According to the logs, this looks like it occurs during shutdown ...
> {noformat}
> [vm1] [info 2018/02/13 21:12:48.075 UTC
> tid=30] Stopping membership services
> [vm0] [info 2018/02/13 21:12:48.077 UTC thread 0> tid=398] GMSHealthMonitor server thread exiting
> [vm0] [info 2018/02/13 21:12:48.078 UTC
> tid=30] GMSHealthMonitor serverSocketExecutor is terminated
> [vm3] [info 2018/02/13 21:12:48.079 UTC
> tid=896] received leave request from 172.17.0.2:32771 for
> 172.17.0.2(180):32771
> [vm0] [info 2018/02/13 21:12:48.084 UTC
> tid=30] DistributionManager stopped in 121ms.
> [vm0] [info 2018/02/13 21:12:48.086 UTC
> tid=30] Marking DistributionManager 172.17.0.2(176):32770 as closed.
> [vm1] [info 2018/02/13 21:12:48.087 UTC
> tid=30] GMSHealthMonitor server socket
[jira] [Commented] (GEODE-4675) CI failure (suspect strings): DistributedSystemDisconnectedException: This connection to a distributed system has been disconnected reported as fatal log message during
[
https://issues.apache.org/jira/browse/GEODE-4675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377589#comment-16377589
]
ASF subversion and git services commented on GEODE-4675:
Commit 889da898b5adf1864dd61a05ab01549ae6edcaf5 in geode's branch
refs/heads/develop from [~dschneider]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=889da89 ]
GEODE-4675: remove checkConnected calls while notifying listeners (#1495)
A call of checkConnected ended up being made from notifyListenersMemberRemoved
which could cause it to throw DistributedSystemDisconnectedException if
the distributed system was being shutdown.
So now the distribution manager is made without this check being done.
Also change to log level from fatal to warn and improved the log message.
> CI failure (suspect strings): DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected reported as fatal
> log message during shutdown
> -
>
> Key: GEODE-4675
> URL: https://issues.apache.org/jira/browse/GEODE-4675
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.5.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Darrel Schneider
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This failure occurred during CI on geode:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/140
> {noformat}
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderOffHeapDUnitTest
> > testPartitionedParallelPropagationHA 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 9339
> [fatal 2018/02/13 21:12:48.099 UTC tid=891]
> Unexpected exception:
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected.
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:911)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1499)
> at
> org.apache.geode.internal.cache.AbstractRegion.getDistributionManager(AbstractRegion.java:1757)
> at
> org.apache.geode.distributed.internal.DistributionAdvisor.getDistributionManager(DistributionAdvisor.java:380)
> at
> org.apache.geode.distributed.internal.DistributionAdvisor.notifyListenersMemberRemoved(DistributionAdvisor.java:1225)
> at
> org.apache.geode.distributed.internal.DistributionAdvisor.basicRemoveId(DistributionAdvisor.java:897)
> at
> org.apache.geode.distributed.internal.DistributionAdvisor.doRemoveId(DistributionAdvisor.java:964)
> at
> org.apache.geode.distributed.internal.DistributionAdvisor.removeId(DistributionAdvisor.java:926)
> at
> org.apache.geode.internal.cache.CacheDistributionAdvisor.removeId(CacheDistributionAdvisor.java:1183)
> at
> org.apache.geode.internal.cache.partitioned.RegionAdvisor.removeId(RegionAdvisor.java:391)
> at
> org.apache.geode.distributed.internal.DistributionAdvisor$1.memberDeparted(DistributionAdvisor.java:232)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberDepartedEvent.handleEvent(ClusterDistributionManager.java:4198)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEvent.handleEvent(ClusterDistributionManager.java:4127)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEvent.handleEvent(ClusterDistributionManager.java:4116)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.handleMemberEvent(ClusterDistributionManager.java:2218)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.access$900(ClusterDistributionManager.java:109)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEventInvoker.run(ClusterDistributionManager.java:2250)
> at java.lang.Thread.run(Thread.java:748)
> ---
> {noformat}
> According to the logs, this looks like it occurs during shutdown ...
> {noformat}
> [vm1] [info 2018/02/13 21:12:48.075 UTC
> tid=30] Stopping membership services
> [vm0] [info 2018/02/13 21:12:48.077 UT
[jira] [Commented] (GEODE-4738) EventSeqNum and versionVector in a region are accessed when they are not yet initialized
[
https://issues.apache.org/jira/browse/GEODE-4738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377561#comment-16377561
]
ASF subversion and git services commented on GEODE-4738:
Commit f61718845961f825047a8f184bc37d891eb06abe in geode's branch
refs/heads/feature/GEODE-4738 from [~eshu]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f617188 ]
Merge remote-tracking branch 'origin/develop' into feature/GEODE-4738
> EventSeqNum and versionVector in a region are accessed when they are not yet
> initialized
>
>
> Key: GEODE-4738
> URL: https://issues.apache.org/jira/browse/GEODE-4738
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.4.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> It is possible that eventSeqNum and versionVector are accessed when they are
> not initialized yet. This could cause transaction to fail on the node just
> start up.
> {noformat}
> Got unexpected exception org.apache.geode.cache.CommitIncompleteException:
> Incomplete commit of transaction TXId:
> rs-FullRegression-2018-02-10-05-01-42-client-1(bridgegemfire6_rs-FullRegression-2018-02-10-05-01-42-client-1_19376:19376):1030:4865.
> Caused by the following exceptions: From member:
> rs-FullRegression-2018-02-10-05-01-42-client-1(bridgegemfire4_rs-FullRegression-2018-02-10-05-01-42-client-1_15810:15810):1026
> java.lang.NullPointerException
> at
> org.apache.geode.internal.concurrent.Atomics.setIfGreater(Atomics.java:56)
> at
> org.apache.geode.internal.cache.BucketRegion.handleWANEvent(BucketRegion.java:576)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.txHandleWANEvent(AbstractRegionMap.java:2938)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.txApplyPut(AbstractRegionMap.java:2647)
> at
> org.apache.geode.internal.cache.LocalRegion.txApplyPut(LocalRegion.java:5068)
> at
> org.apache.geode.internal.cache.TXCommitMessage$RegionCommit.txApplyEntryOp(TXCommitMessage.java:1287)
> at
> org.apache.geode.internal.cache.TXCommitMessage$RegionCommit$FarSideEntryOp.process(TXCommitMessage.java:1597)
> at
> org.apache.geode.internal.cache.TXCommitMessage.basicProcessOps(TXCommitMessage.java:711)
> at
> org.apache.geode.internal.cache.TXCommitMessage.basicProcess(TXCommitMessage.java:638)
> at
> org.apache.geode.internal.cache.TXCommitMessage$CommitProcessMessage.basicProcess(TXCommitMessage.java:1784)
> at
> org.apache.geode.internal.cache.TXCommitMessage$CommitProcessForTXIdMessage.process(TXCommitMessage.java:1747)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:448)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:1117)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:108)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$4$1.run(ClusterDistributionManager.java:788)
> at java.lang.Thread.run(Thread.java:748).
> at
> org.apache.geode.internal.cache.TXCommitMessage$CommitExceptionCollectingException.handlePotentialCommitFailure(TXCommitMessage.java:2203)
> at
> org.apache.geode.internal.cache.TXCommitMessage$CommitReplyProcessor.waitForCommitCompletion(TXCommitMessage.java:2104)
> at
> org.apache.geode.internal.cache.TXCommitMessage.send(TXCommitMessage.java:418)
> at org.apache.geode.internal.cache.TXState.commit(TXState.java:473)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.commit(TXStateProxyImpl.java:228)
> at
> org.apache.geode.internal.cache.TXManagerImpl.commit(TXManagerImpl.java:405)
> at
> org.apache.geode.internal.cache.TXRemoteCommitMessage.operateOnTx(TXRemoteCommitMessage.java:98)
> at org.apache.geode.internal.cache.TXMessage.process(TXMessage.java:94)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:448)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> j
[jira] [Commented] (GEODE-2673) PartitionedRegionMultipleDUnitTest.testPartitionedRegionDestroyAndContainsAPI fails intermittently with ForcedDisconnectException
[
https://issues.apache.org/jira/browse/GEODE-2673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377560#comment-16377560
]
ASF subversion and git services commented on GEODE-2673:
Commit 101fd19ba74a1945265b1dee56327313c3a5c14f in geode's branch
refs/heads/feature/GEODE-4738 from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=101fd19 ]
GEODE-2673: overhaul PartitionedRegion dunit tests (#1486)
* Delete PartitionedRegionDUnitTestCase
* Overhaul every dunit test that extended PartitionedRegionDUnitTestCase
* Fix flakiness in several dunit tests
* Document and update test methods that were named after old TRAC bugs
* Extract regression test methods to new dedicated test classes
* Extract unrelated test methods to new dedicated test classes
* Extract inner classes that are used by multiple test classes
* Change PRIdMap prIdToPR in PartitionedRegion to be private and change tests
to use an accessor to reference it
* Change localBucket2RegionMap in PartitionedRegionDataStore to be private and
change tests to use an accessor to reference it
* Move "Set getSomeKeys(Random rnd)" from PartitionedRegion product code to
PartitionedRegionGetSomeKeys in test code
* Make IgnoredException AutoCloseable so you can use it within try-resource
blocks
* Add "IgnoredException addIgnoredException(final Class exceptionClass)" to
IgnoredException
> PartitionedRegionMultipleDUnitTest.testPartitionedRegionDestroyAndContainsAPI
> fails intermittently with ForcedDisconnectException
> -
>
> Key: GEODE-2673
> URL: https://issues.apache.org/jira/browse/GEODE-2673
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: Flaky, pull-request-available
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Test passes when run by itself:
> {noformat}
> ./gradlew -DdistributedTest.single=PartitionedRegionMultipleDUnitTest
> geode-core:distributedTest
> {noformat}
> But fails intermittently in precheckin:
> {noformat}
> org.apache.geode.internal.cache.PartitionedRegionMultipleDUnitTest >
> testPartitionedRegionDestroyAndContainsAPI FAILED
> java.lang.AssertionError: exception during 0
> at org.apache.geode.test.dunit.Assert.fail(Assert.java:60)
> at
> org.apache.geode.internal.cache.PartitionedRegionMultipleDUnitTest.testPartitionedRegionDestroyAndContainsAPI(PartitionedRegionMultipleDUnitTest.java:231)
> Caused by:
> java.lang.AssertionError: Validation failed for key =
> 0testPartitionedRegionDestroyAndContainsAPI3Value got = null
> 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 1807
> [fatal 2017/03/13 23:48:06.633 UTC
> tid=0xc5] Membership service failure: this member is no longer in the view
> but is initiating connections
> org.apache.geode.ForcedDisconnectException: this member is no longer in
> the view but is initiating connections
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.forceDisconnect(GMSMembershipManager.java:2517)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:998)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processRemoveRequest(GMSJoinLeave.java:635)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:1702)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1286)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:74)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:72)
> at org.jgroups.protocols.T
[jira] [Commented] (GEODE-4675) CI failure (suspect strings): DistributedSystemDisconnectedException: This connection to a distributed system has been disconnected reported as fatal log message during
[
https://issues.apache.org/jira/browse/GEODE-4675?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377475#comment-16377475
]
xiaojian zhou commented on GEODE-4675:
--
{noformat}
Found in CI develop DistributedTest #162
org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderOffHeapDUnitTest
> testParallelPropagationWithUnEqualBucketDivision 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 9083
[fatal 2018/02/24 06:27:04.231 UTC tid=1086] Unexpected
exception:
org.apache.geode.distributed.DistributedSystemDisconnectedException: This
connection to a distributed system has been disconnected.
at
org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:911)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.getDistributionManager(InternalDistributedSystem.java:1493)
at
org.apache.geode.internal.cache.AbstractRegion.getDistributionManager(AbstractRegion.java:1757)
at
org.apache.geode.distributed.internal.DistributionAdvisor.getDistributionManager(DistributionAdvisor.java:380)
at
org.apache.geode.distributed.internal.DistributionAdvisor.notifyListenersMemberRemoved(DistributionAdvisor.java:1225)
at
org.apache.geode.distributed.internal.DistributionAdvisor.basicRemoveId(DistributionAdvisor.java:897)
at
org.apache.geode.distributed.internal.DistributionAdvisor.doRemoveId(DistributionAdvisor.java:964)
at
org.apache.geode.distributed.internal.DistributionAdvisor.removeId(DistributionAdvisor.java:926)
at
org.apache.geode.internal.cache.CacheDistributionAdvisor.removeId(CacheDistributionAdvisor.java:1183)
at
org.apache.geode.internal.cache.partitioned.RegionAdvisor.removeId(RegionAdvisor.java:391)
at
org.apache.geode.distributed.internal.DistributionAdvisor$1.memberDeparted(DistributionAdvisor.java:232)
at
org.apache.geode.distributed.internal.ClusterDistributionManager$MemberDepartedEvent.handleEvent(ClusterDistributionManager.java:4198)
at
org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEvent.handleEvent(ClusterDistributionManager.java:4127)
at
org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEvent.handleEvent(ClusterDistributionManager.java:4116)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.handleMemberEvent(ClusterDistributionManager.java:2218)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.access$900(ClusterDistributionManager.java:109)
at
org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEventInvoker.run(ClusterDistributionManager.java:2250)
at java.lang.Thread.run(Thread.java:748{noformat}
[
|https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/162#L5a6ba88b:628]
> CI failure (suspect strings): DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected reported as fatal
> log message during shutdown
> -
>
> Key: GEODE-4675
> URL: https://issues.apache.org/jira/browse/GEODE-4675
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.5.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Darrel Schneider
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This failure occurred during CI on geode:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/140
> {noformat}
> org.apache.geode.internal.cache.wan.concurrent.ConcurrentParallelGatewaySenderOffHeapDUnitTest
> > testPartitionedParallelPropagationHA 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 9339
> [fatal 2018/02/13 21:12:48.099 UTC tid=891]
> Unexpected exception:
> org.apache.geode.distributed.DistributedSystemDisconnectedException: This
> connection to a distributed system has been disconnected.
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.checkConnected(InternalDistributedSystem.java:911)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.getDis
[jira] [Updated] (GEODE-4745) CI Failure : entriesFlushedToIndexAfterWaitForFlushCalled
[ https://issues.apache.org/jira/browse/GEODE-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-4745: -- Labels: pull-request-available (was: ) > CI Failure : entriesFlushedToIndexAfterWaitForFlushCalled > - > > Key: GEODE-4745 > URL: https://issues.apache.org/jira/browse/GEODE-4745 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: nabarun >Priority: Major > Labels: pull-request-available > > org.apache.geode.cache.lucene.LuceneIndexMaintenanceIntegrationTest > > entriesFlushedToIndexAfterWaitForFlushCalled FAILED > java.lang.AssertionError: expected:<8> but was:<7> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at org.junit.Assert.assertEquals(Assert.java:631) > at > org.apache.geode.cache.lucene.LuceneIndexMaintenanceIntegrationTest.entriesFlushedToIndexAfterWaitForFlushCalled(LuceneIndexMaintenanceIntegrationTest.java:277) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4234) Add ability to enable global copy-on-read via gfsh
[
https://issues.apache.org/jira/browse/GEODE-4234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-4234:
-
Fix Version/s: (was: 1.5.0)
> Add ability to enable global copy-on-read via gfsh
> --
>
> Key: GEODE-4234
> URL: https://issues.apache.org/jira/browse/GEODE-4234
> Project: Geode
> Issue Type: New Feature
> Components: docs, gfsh, transactions
>Reporter: Michael Dodge
>Priority: Major
>
> A cache supports a "copy on read" feature for cache read operations. (See
> [http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/GemFireCache.html#setCopyOnRead-boolean-])
> The documentation for transactions
> ([https://geode.apache.org/docs/guide/11/developing/transactions/run_a_cache_transaction.html])
> recommends enabling this feature. However, the documentation for enabling
> this feature
> ([https://geode.apache.org/docs/guide/11/developing/transactions/working_with_transactions.html#concept_vx2_gs4_5k])
> only shows how to enable it via {{cache.xml}} or Java inside the server.
> There should be a way to enable the "copy on read" feature for a cache using
> {{gfsh}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4310) improve ResourcePermission to take strings as argument for resource and operation
[
https://issues.apache.org/jira/browse/GEODE-4310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-4310:
-
Fix Version/s: (was: 1.5.0)
> improve ResourcePermission to take strings as argument for resource and
> operation
> -
>
> Key: GEODE-4310
> URL: https://issues.apache.org/jira/browse/GEODE-4310
> Project: Geode
> Issue Type: Improvement
> Components: security
>Reporter: Jinmei Liao
>Priority: Major
> Labels: pull-request-available
>
> It would be nice to be able to create {noformat}ResourcePermission("*",
> "*"){noformat} that would mean that this operation requires all permissions.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-3921) Docker image for geode
[ https://issues.apache.org/jira/browse/GEODE-3921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anthony Baker updated GEODE-3921: - Fix Version/s: (was: 1.5.0) > Docker image for geode > -- > > Key: GEODE-3921 > URL: https://issues.apache.org/jira/browse/GEODE-3921 > Project: Geode > Issue Type: Improvement >Reporter: Vaibhav Sood >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > Hi, > Want to check if there is a docker image/Dockerfile for Geode which is > officially supported? I could not find one under dockerhub official images > https://hub.docker.com/explore/ > If not, want to check if there is any plan to add an official Geode image to > dockerhub? > https://docs.docker.com/docker-hub/official_repos/#how-do-i-create-a-new-official-repository -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4737) User Guide: Describe addition of JSON specs to gfsh commands
[ https://issues.apache.org/jira/browse/GEODE-4737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-4737: -- Labels: pull-request-available (was: ) > User Guide: Describe addition of JSON specs to gfsh commands > > > Key: GEODE-4737 > URL: https://issues.apache.org/jira/browse/GEODE-4737 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Dave Barnes >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > > Some new gfsh commands can take a JSON spec. Examples include `alter region > --entry-idle-time-custom-expiry` and `create region --cache-listener`. > Add a general description of the syntax to the gfsh section of the manual so > individual command-reference entries can point to a centralized explanation, > rather than repeating the syntax details each time. > One developer has requested that we state that the JSON parser recognizes > double quotes as well as single quotes. Some JSON parsers accept only single > quotes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-1951) users should be able to deploy jars when no servers are running
[
https://issues.apache.org/jira/browse/GEODE-1951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-1951:
--
Fix Version/s: 1.1.0
> users should be able to deploy jars when no servers are running
> ---
>
> Key: GEODE-1951
> URL: https://issues.apache.org/jira/browse/GEODE-1951
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: Swapnil Bawaskar
>Priority: Major
> Labels: deploy
> Fix For: 1.1.0
>
>
> If I start a locator and then try to deploy a jar file I get the following
> error message:
> {noformat}
> gfsh>deploy --jar=/path/to/some.jar
> No Members Found
> {noformat}
> The behavior desired is that the locator should store the jar file, so that
> when members are started they can get this jar from the locator (through
> cluster configuration). This behavior is desired for adding security
> callbacks to the servers, as they are being started.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4343) Geode Native C# Example (put/get of custom objects using PDXAutoserializer)
[ https://issues.apache.org/jira/browse/GEODE-4343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-4343: -- Labels: pull-request-available (was: ) > Geode Native C# Example (put/get of custom objects using PDXAutoserializer) > --- > > Key: GEODE-4343 > URL: https://issues.apache.org/jira/browse/GEODE-4343 > Project: Geode > Issue Type: Sub-task > Components: native client >Reporter: Addison >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4362) view preparation throws uncaught RuntimeException
[
https://issues.apache.org/jira/browse/GEODE-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377268#comment-16377268
]
ASF subversion and git services commented on GEODE-4362:
Commit fff05c5ba3f84e456f77b47f009347a30e6a51b8 in geode's branch
refs/heads/feature/GEODE-4362 from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=fff05c5 ]
GEODE-4362: view preparation throws uncaught RuntimeException
Galen cleaned up GMSEncrypt and then we worked together to fix this bug.
The problem was happening when a new member joined with a coordinator that
suddenly shuts down before other members have been told to install the
new membership view. They've received a "prepare for view change" message
containing the new view but have not been told to commit that change.
Another member then becomes coordinator and sees that there was a new member
in the prepared view. It picks this up and adds it to the new view it
sends out.
The problem was that the public encryption keys of the members weren't
being transferred from the old view to the new view and when looking for
public keys we were fishing them out of GMSEncrypt instead of getting
them from the membership view. This caused an NPE to be thrown when trying
to fish out the public key of the new member - GMSEncrypt didn't know about
this new member because the view containing it was never installed - it
was only prepared.
The fix is to transfer the public keys from the old view to the new one and
to look for public keys in the view instead of GMSEncrypt.
> view preparation throws uncaught RuntimeException
> -
>
> Key: GEODE-4362
> URL: https://issues.apache.org/jira/browse/GEODE-4362
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Galen O'Sullivan
>Priority: Major
>
> I put a pause in Services.installView() before the view is passed to the
> Messenger service and ran
> LocatorUDPSecurityDUnitTest.testCollocatedLocatorWithSecurity() and
> encountered a RuntimeException:
> {noformat}
> [vm1] java.lang.RuntimeException: Not found public key for member
> 10.118.20.12(68202):32773
> [vm1] at
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPublicKey(GMSEncrypt.java:178)
> [vm1] at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.getPublicKey(JGroupsMessenger.java:1367)
> [vm1] at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.addPublicKeysToView(GMSJoinLeave.java:933)
> [vm1] at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.sendView(GMSJoinLeave.java:896)
> [vm1] at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.prepareView(GMSJoinLeave.java:838)
> [vm1] at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.prepareAndSendView(GMSJoinLeave.java:2385)
> [vm1] at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.sendInitialView(GMSJoinLeave.java:2031)
> [vm1] at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.run(GMSJoinLeave.java:2091)
> [vm1] Caused by: java.lang.NullPointerException
> [vm1] at
> java.security.spec.EncodedKeySpec.(EncodedKeySpec.java:56)
> [vm1] at
> java.security.spec.X509EncodedKeySpec.(X509EncodedKeySpec.java:64)
> [vm1] at
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPublicKey(GMSEncrypt.java:545)
> [vm1] at
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt$PeerEncryptor.(GMSEncrypt.java:377)
> [vm1] at
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.createPeerEncryptor(GMSEncrypt.java:301)
> [vm1] at
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPeerEncryptor(GMSEncrypt.java:259)
> [vm1] at
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPublicKey(GMSEncrypt.java:176)
> [vm1] ... 7 more
> {noformat}
> Since GMSJoinLeave already had the new view installed and JGroupsMessenger
> did not have the new view installed we were unable to find the public key for
> one of the recipients of the new view. View preparation should probably be
> synchronized with view installation so that both aren't done in parallel.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-4746) Protobuf server should catch Exceptions and return a reasonable response message to clients
Dan Smith created GEODE-4746: Summary: Protobuf server should catch Exceptions and return a reasonable response message to clients Key: GEODE-4746 URL: https://issues.apache.org/jira/browse/GEODE-4746 Project: Geode Issue Type: Improvement Components: client/server Reporter: Dan Smith Whenever possible, the protobuf server should catch exceptions and send a response message back to the client. Currently, any exception on the server is causing the server to close the socket, even for trivial things like a typo in a query string. From the client side there is no information about why the socket was closed. We should catch exceptions and return the error message to the client without closing the socket. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-4746) Protobuf server should catch Exceptions and return a reasonable response message to clients
[ https://issues.apache.org/jira/browse/GEODE-4746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith reassigned GEODE-4746: Assignee: Dan Smith > Protobuf server should catch Exceptions and return a reasonable response > message to clients > --- > > Key: GEODE-4746 > URL: https://issues.apache.org/jira/browse/GEODE-4746 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > > Whenever possible, the protobuf server should catch exceptions and send a > response message back to the client. Currently, any exception on the server > is causing the server to close the socket, even for trivial things like a > typo in a query string. From the client side there is no information about > why the socket was closed. > We should catch exceptions and return the error message to the client without > closing the socket. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-3813) Region registerInterest API usage of type parameters is broken
[
https://issues.apache.org/jira/browse/GEODE-3813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377237#comment-16377237
]
ASF subversion and git services commented on GEODE-3813:
Commit 94db6a7d3d473fec40540c510858e60ce47cd741 in geode's branch
refs/heads/feature/GEODE-4738 from [~huynhja]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=94db6a7 ]
GEODE-3813: Improved and fixed formatting in javaDoc for deprecated behavior
(#1500)
> Region registerInterest API usage of type parameters is broken
> --
>
> Key: GEODE-3813
> URL: https://issues.apache.org/jira/browse/GEODE-3813
> Project: Geode
> Issue Type: Bug
> Components: client queues, docs
>Reporter: Kirk Lund
>Assignee: Jason Huynh
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.5.0
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> The registerInterest API works for single key registration but is broken for
> all other types of registration if the Region is declared with type
> parameters:
> Single key (works):
> {noformat}
> Region region = clientRegionFactory.create(regionName);
> region.registerInterest(1);
> {noformat}
> ALL_KEYS token is broken (fails to compile):
> {noformat}
> Region region = clientRegionFactory.create(regionName);
> region.registerInterest("ALL_KEYS");
> {noformat}
> List of keys is broken (fails to compile):
> {noformat}
> Region region = clientRegionFactory.create(regionName);
> List listOfKeys = new ArrayList<>();
> listOfKeys.add(1);
> listOfKeys.add(2);
> region.registerInterest(listOfKeys);
> {noformat}
> When this ticket is fixed and the API is updated, we should consider adding
> support for var args:
> {noformat}
> Region region = clientRegionFactory.create(regionName);
> region.registerInterest(1, 2, 3);
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4638) review protobuf server error responses and logging for region-not-found
[ https://issues.apache.org/jira/browse/GEODE-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377242#comment-16377242 ] ASF subversion and git services commented on GEODE-4638: Commit de2cb20632fb8200a10238bfff206bb70bb97433 in geode's branch refs/heads/feature/GEODE-4738 from [~PivotalSarge] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=de2cb20 ] GEODE-4638: Standardize hanlding of region-not-found errors. (#1492) > review protobuf server error responses and logging for region-not-found > --- > > Key: GEODE-4638 > URL: https://issues.apache.org/jira/browse/GEODE-4638 > Project: Geode > Issue Type: Task > Components: client/server >Reporter: Bruce Schuchardt >Assignee: Michael Dodge >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Some operation handlers log region-not-found problems at error level and some > at warning level. Some return a SERVER_ERROR error code and some return an > INVALID_REQUEST error code. These should probably all behave in the same way. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4722) Code Improvement: Refactor CliUtil
[ https://issues.apache.org/jira/browse/GEODE-4722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377234#comment-16377234 ] ASF subversion and git services commented on GEODE-4722: Commit df093b5b8f2d1bee549e0b76472b4fcdd51ddc7f in geode's branch refs/heads/feature/GEODE-4738 from [~prhomberg] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=df093b5 ] GEODE-4722: Refactor CliUtil (#1487) * Reorder methods, grouped by similar functionality. * Replace .stackTraceToString and .contains with Apache Commons methods. * Moved getClientIdFromCacheClientProxy to only class that calls it. * Move arrayToString from CliUtil to sensible StringUtils. Moved associated test. * Refactor CliUtil methods. > Code Improvement: Refactor CliUtil > -- > > Key: GEODE-4722 > URL: https://issues.apache.org/jira/browse/GEODE-4722 > Project: Geode > Issue Type: Improvement >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > This class could use some cleaning. Many methods are unused, some trivially > replaced by Apache Commons libraries. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4327) OQL Support for Modulus & Other Arithmetic Operators
[ https://issues.apache.org/jira/browse/GEODE-4327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377236#comment-16377236 ] ASF subversion and git services commented on GEODE-4327: Commit c16d1a376592dd5c0169fcb5adaed8cc7e6eb259 in geode's branch refs/heads/feature/GEODE-4738 from Karen Miller [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c16d1a3 ] GEODE-4327 Document new OQL operators (#1491) > OQL Support for Modulus & Other Arithmetic Operators > > > Key: GEODE-4327 > URL: https://issues.apache.org/jira/browse/GEODE-4327 > Project: Geode > Issue Type: Improvement > Components: docs, querying >Reporter: Jason Huynh >Assignee: Karen Smoler Miller >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > It would be nice to be able to do 'mod', '%', '+', '-', '/', '*' in a query > and have the corresponding arithmetic/mod calculation be evaluated in the > query. > > simple example: > "Select * from /region r where r.id % 12 = 1" > or > "Select * from /region r where r.age * 10 = 100" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4407) Separate incremental backup logic from backup task and oplog
[ https://issues.apache.org/jira/browse/GEODE-4407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377239#comment-16377239 ] ASF subversion and git services commented on GEODE-4407: Commit 2dfc8aee602d697702ef57bdaf7e12b4815572cf in geode's branch refs/heads/feature/GEODE-4738 from [~agingade] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=2dfc8ae ] GEODE-4407 (#1499): Refactoring incremental backup logic Removed dependency on target location while fetching backup files from source. > Separate incremental backup logic from backup task and oplog > > > Key: GEODE-4407 > URL: https://issues.apache.org/jira/browse/GEODE-4407 > Project: Geode > Issue Type: Sub-task > Components: persistence >Reporter: Nick Reich >Assignee: Anilkumar Gingade >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Incremental backup examines the oplog from current destination to the > previously backed up destination to generate oplogs to be backed up. This > logic is present in both backup task and oplog. We need to separate this out > so the logic can be used for different backup destinations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4559) Remove singleton calls from product code in org.apache.geode.cache.util
[ https://issues.apache.org/jira/browse/GEODE-4559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377238#comment-16377238 ] ASF subversion and git services commented on GEODE-4559: Commit 3b6a9aaf9d1ae6608a1fd9ffee01b399a6a11452 in geode's branch refs/heads/feature/GEODE-4738 from [~dschneider] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=3b6a9aa ] GEODE-4559: pass the Cache to a Declarable (#1422) * Declarable now has a default method named "initialize(Cache, Properties)". This allows a Declarable to know the cache that created it. Deprecated Declarable.init(Properties). Note that for backwards compatibility, the product calls both these methods. Also the two Declarables that the product implements, AutoBalancer and ReflectionBasedAutoSerializer, implement both these methods but after the first calls subsequent calls of init or initialize will be noops. * initialize on ReflectionBasedAutoSerializer now call setRegionService with the cache. init and initialize can now be called multiple times and each time the properties will be set again. This is for backwards compatibility. * The AutoBalancer no longer looks up the static cache. but instead of given one by the product calling setCache during initialization. > Remove singleton calls from product code in org.apache.geode.cache.util > --- > > Key: GEODE-4559 > URL: https://issues.apache.org/jira/browse/GEODE-4559 > Project: Geode > Issue Type: Sub-task > Components: docs, regions >Reporter: Kirk Lund >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > These product classes in org.apache.geode.cache.util invoke singleton getters. > GemFireCacheImpl.getInstance(): > * AutoBalancer$GeodeCacheFacade -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4703) DestroyGatewayReceiver may cause hang if executed during RollingUpgrade
[ https://issues.apache.org/jira/browse/GEODE-4703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377232#comment-16377232 ] ASF subversion and git services commented on GEODE-4703: Commit 1d1bc3b25dc82412edaf127e5f0e55cee924df6e in geode's branch refs/heads/feature/GEODE-4738 from [~huynhja] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1d1bc3b ] GEODE-4703: Prevent sending RemoveCacheServerProfileMessage to older members (#1468) > DestroyGatewayReceiver may cause hang if executed during RollingUpgrade > --- > > Key: GEODE-4703 > URL: https://issues.apache.org/jira/browse/GEODE-4703 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Jason Huynh >Assignee: Jason Huynh >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > GEODE-2667 introduced the ability to destroy gateway receiver -> destroy > cache server. However if executed in a cluster with mixed servers (servers > prior to 1.5) the distribution of the message causes a DSFID deserialization > failure on the older versions, which causes the sender to wait for replies > infinitely. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4704) GatewaySender batch conflation can incorrectly conflate events causing out of order processing
[
https://issues.apache.org/jira/browse/GEODE-4704?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377241#comment-16377241
]
ASF subversion and git services commented on GEODE-4704:
Commit 147e6bc6b9009aa8e878141ef30e55145732943d in geode's branch
refs/heads/feature/GEODE-4738 from [~barry.oglesby]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=147e6bc ]
GEODE-4704: Modified ConflationKey to use shadowKey when comparing events
> GatewaySender batch conflation can incorrectly conflate events causing out of
> order processing
> --
>
> Key: GEODE-4704
> URL: https://issues.apache.org/jira/browse/GEODE-4704
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barry Oglesby
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.5.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In the current implementation of \{{AbstractGatewaySenderEventProcessor
> conflate}} can incorrectly conflate two create events on the same key.
> The else clause of the conflate method (meaning the event is not conflatable)
> assumes there isn't already a event with the same region, key and operation
> in the map. It just does a put:
> {noformat}
> ConflationKey key = new ConflationKey(gsEvent.getRegion().getFullPath(),
> gsEvent.getKeyToConflate(), gsEvent.getOperation());
> conflatedEventsMap.put(key, gsEvent);
> {noformat}
> In certain cases, there could already be a create event on the same region,
> key and operation in the batch, so the previous one gets replaced by the
> later once which causes the events to be processed out of order.
> These 4 events:
> {noformat}
> SenderEventImpl[id=EventIDid=57bytes;threadID=0x10018|112;sequenceID=100;bucketId=24];operation=CREATE;region=/dataStoreRegion;key=Object_13964;shadowKey=27709]
> SenderEventImpl[id=EventIDid=57bytes;threadID=0x10018|112;sequenceID=101;bucketId=24];operation=CREATE;region=/dataStoreRegion;key=Object_14024;shadowKey=27822]
> SenderEventImpl[id=EventIDid=57bytes;threadID=0x10018|112;sequenceID=102;bucketId=24];operation=DESTROY;region=/dataStoreRegion;key=Object_13964;shadowKey=27935]
> SenderEventImpl[id=EventIDid=57bytes;threadID=0x10018|112;sequenceID=104;bucketId=24];operation=CREATE;region=/dataStoreRegion;key=Object_14024;shadowKey=28161]
> {noformat}
> Become these 3 events:
> {noformat}
> SenderEventImpl[id=EventIDid=57bytes;threadID=0x10018|112;sequenceID=100;bucketId=24];operation=CREATE;region=/dataStoreRegion;key=Object_13964;shadowKey=27709]
> SenderEventImpl[id=EventIDid=57bytes;threadID=0x10018|112;sequenceID=104;bucketId=24];operation=CREATE;region=/dataStoreRegion;key=Object_14024;shadowKey=28161]
> SenderEventImpl[id=EventIDid=57bytes;threadID=0x10018|112;sequenceID=102;bucketId=24];operation=DESTROY;region=/dataStoreRegion;key=Object_13964;shadowKey=27935]
> {noformat}
> Notice the shadowKeys and sequenceIds are out of order after the conflation.
> The fix will be to include the shadow key in hashCode and equals in the case
> where the event is not conflatable.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4738) EventSeqNum and versionVector in a region are accessed when they are not yet initialized
[
https://issues.apache.org/jira/browse/GEODE-4738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377243#comment-16377243
]
ASF subversion and git services commented on GEODE-4738:
Commit 887a0f9fcfce5861d13230e3fdf9ed37005331ca in geode's branch
refs/heads/feature/GEODE-4738 from [~eshu]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=887a0f9 ]
Merge remote-tracking branch 'origin/develop' into feature/GEODE-4738
> EventSeqNum and versionVector in a region are accessed when they are not yet
> initialized
>
>
> Key: GEODE-4738
> URL: https://issues.apache.org/jira/browse/GEODE-4738
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.4.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It is possible that eventSeqNum and versionVector are accessed when they are
> not initialized yet. This could cause transaction to fail on the node just
> start up.
> {noformat}
> Got unexpected exception org.apache.geode.cache.CommitIncompleteException:
> Incomplete commit of transaction TXId:
> rs-FullRegression-2018-02-10-05-01-42-client-1(bridgegemfire6_rs-FullRegression-2018-02-10-05-01-42-client-1_19376:19376):1030:4865.
> Caused by the following exceptions: From member:
> rs-FullRegression-2018-02-10-05-01-42-client-1(bridgegemfire4_rs-FullRegression-2018-02-10-05-01-42-client-1_15810:15810):1026
> java.lang.NullPointerException
> at
> org.apache.geode.internal.concurrent.Atomics.setIfGreater(Atomics.java:56)
> at
> org.apache.geode.internal.cache.BucketRegion.handleWANEvent(BucketRegion.java:576)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.txHandleWANEvent(AbstractRegionMap.java:2938)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.txApplyPut(AbstractRegionMap.java:2647)
> at
> org.apache.geode.internal.cache.LocalRegion.txApplyPut(LocalRegion.java:5068)
> at
> org.apache.geode.internal.cache.TXCommitMessage$RegionCommit.txApplyEntryOp(TXCommitMessage.java:1287)
> at
> org.apache.geode.internal.cache.TXCommitMessage$RegionCommit$FarSideEntryOp.process(TXCommitMessage.java:1597)
> at
> org.apache.geode.internal.cache.TXCommitMessage.basicProcessOps(TXCommitMessage.java:711)
> at
> org.apache.geode.internal.cache.TXCommitMessage.basicProcess(TXCommitMessage.java:638)
> at
> org.apache.geode.internal.cache.TXCommitMessage$CommitProcessMessage.basicProcess(TXCommitMessage.java:1784)
> at
> org.apache.geode.internal.cache.TXCommitMessage$CommitProcessForTXIdMessage.process(TXCommitMessage.java:1747)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:448)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:1117)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:108)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$4$1.run(ClusterDistributionManager.java:788)
> at java.lang.Thread.run(Thread.java:748).
> at
> org.apache.geode.internal.cache.TXCommitMessage$CommitExceptionCollectingException.handlePotentialCommitFailure(TXCommitMessage.java:2203)
> at
> org.apache.geode.internal.cache.TXCommitMessage$CommitReplyProcessor.waitForCommitCompletion(TXCommitMessage.java:2104)
> at
> org.apache.geode.internal.cache.TXCommitMessage.send(TXCommitMessage.java:418)
> at org.apache.geode.internal.cache.TXState.commit(TXState.java:473)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.commit(TXStateProxyImpl.java:228)
> at
> org.apache.geode.internal.cache.TXManagerImpl.commit(TXManagerImpl.java:405)
> at
> org.apache.geode.internal.cache.TXRemoteCommitMessage.operateOnTx(TXRemoteCommitMessage.java:98)
> at org.apache.geode.internal.cache.TXMessage.process(TXMessage.java:94)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:448)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> j
[jira] [Commented] (GEODE-4541) Remove singleton calls from regions product code in org.apache.geode.internal.cache
[ https://issues.apache.org/jira/browse/GEODE-4541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377240#comment-16377240 ] ASF subversion and git services commented on GEODE-4541: Commit d752dceaee450ce4d49dcd06766b3dd665211e16 in geode's branch refs/heads/feature/GEODE-4738 from [~dschneider] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=d752dce ] GEODE-4541: remove singleton calls (#1463) * removed getAnyInstance call from PartitionedRegionHelper * removed getInstance call from CacheServerLauncher * removed getAnyInstance call from EventStateHelper * DistributedPutAllOperation no longer calls GemFireCacheImpl.getInstance * EntryEventImpl no longer calls getInstance. This fix requires that when an EntryEventImpl is deserialized that setRegion will be called on it before the values are accessed. Also encapsulated the "region" field and got rid of getLocalRegion in favor of getRegion. > Remove singleton calls from regions product code in > org.apache.geode.internal.cache > --- > > Key: GEODE-4541 > URL: https://issues.apache.org/jira/browse/GEODE-4541 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Kirk Lund >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 10m > Remaining Estimate: 0h > > These regions product classes in org.apache.geode.internal.cache invoke > singleton getters. > GemFireCacheImpl.getInstance(): > * CacheServerLauncher > * EntryEventImpl > * GemFireCacheImpl > * DistributedPutAllOperation > InternalDistributedSystem.getAnyInstance(): > * EventStateHelper > * GemFireCacheImpl > * PartitionAttributesImpl > * PartitionedRegionHelper -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-2673) PartitionedRegionMultipleDUnitTest.testPartitionedRegionDestroyAndContainsAPI fails intermittently with ForcedDisconnectException
[
https://issues.apache.org/jira/browse/GEODE-2673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377227#comment-16377227
]
ASF subversion and git services commented on GEODE-2673:
Commit 101fd19ba74a1945265b1dee56327313c3a5c14f in geode's branch
refs/heads/develop from [~apa...@the9muses.net]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=101fd19 ]
GEODE-2673: overhaul PartitionedRegion dunit tests (#1486)
* Delete PartitionedRegionDUnitTestCase
* Overhaul every dunit test that extended PartitionedRegionDUnitTestCase
* Fix flakiness in several dunit tests
* Document and update test methods that were named after old TRAC bugs
* Extract regression test methods to new dedicated test classes
* Extract unrelated test methods to new dedicated test classes
* Extract inner classes that are used by multiple test classes
* Change PRIdMap prIdToPR in PartitionedRegion to be private and change tests
to use an accessor to reference it
* Change localBucket2RegionMap in PartitionedRegionDataStore to be private and
change tests to use an accessor to reference it
* Move "Set getSomeKeys(Random rnd)" from PartitionedRegion product code to
PartitionedRegionGetSomeKeys in test code
* Make IgnoredException AutoCloseable so you can use it within try-resource
blocks
* Add "IgnoredException addIgnoredException(final Class exceptionClass)" to
IgnoredException
> PartitionedRegionMultipleDUnitTest.testPartitionedRegionDestroyAndContainsAPI
> fails intermittently with ForcedDisconnectException
> -
>
> Key: GEODE-2673
> URL: https://issues.apache.org/jira/browse/GEODE-2673
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: Flaky, pull-request-available
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Test passes when run by itself:
> {noformat}
> ./gradlew -DdistributedTest.single=PartitionedRegionMultipleDUnitTest
> geode-core:distributedTest
> {noformat}
> But fails intermittently in precheckin:
> {noformat}
> org.apache.geode.internal.cache.PartitionedRegionMultipleDUnitTest >
> testPartitionedRegionDestroyAndContainsAPI FAILED
> java.lang.AssertionError: exception during 0
> at org.apache.geode.test.dunit.Assert.fail(Assert.java:60)
> at
> org.apache.geode.internal.cache.PartitionedRegionMultipleDUnitTest.testPartitionedRegionDestroyAndContainsAPI(PartitionedRegionMultipleDUnitTest.java:231)
> Caused by:
> java.lang.AssertionError: Validation failed for key =
> 0testPartitionedRegionDestroyAndContainsAPI3Value got = null
> 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 1807
> [fatal 2017/03/13 23:48:06.633 UTC
> tid=0xc5] Membership service failure: this member is no longer in the view
> but is initiating connections
> org.apache.geode.ForcedDisconnectException: this member is no longer in
> the view but is initiating connections
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.forceDisconnect(GMSMembershipManager.java:2517)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:998)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processRemoveRequest(GMSJoinLeave.java:635)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.processMessage(GMSJoinLeave.java:1702)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger$JGroupsReceiver.receive(JGroupsMessenger.java:1286)
> at org.jgroups.JChannel.invokeCallback(JChannel.java:816)
> at org.jgroups.JChannel.up(JChannel.java:741)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1030)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:165)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:390)
> at org.jgroups.protocols.UNICAST3.deliverMessage(UNICAST3.java:1070)
> at org.jgroups.protocols.UNICAST3.handleDataReceived(UNICAST3.java:785)
> at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:426)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.up(StatRecorder.java:74)
> at
> org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager.up(AddressManager.java:72)
> at org.jgroups.protocols.TP.passMessa
[jira] [Updated] (GEODE-2727) optimize new 1.8 ConcurrentMap default methods on Region
[ https://issues.apache.org/jira/browse/GEODE-2727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-2727: - Description: In JDK 1.8 ConcurrentMap added the following default methods to the interface: getOrDefault computeIfAbsent computeIfPresent compute merge foreach replaceAll All of the default implementations of these methods have issues with get returning null when the key actually exists. So they do not support invalid region entries. The other problem with all of them (except getOrDefault) is that they will make multiple round trips when done from a proxy. In a distributed environment we should implement these to send the lambda to the primary so that the entire operation can be done with one message and while the RegionEntry is locked. This would require that the lambda parameter by serializable which would be consistent with what we do for other parameters to Region methods (for example "put"). From a performance point of view "foreach" and "replaceAll" are the worst since they bring back to whoever is executing the method all the keys and values from the entire cluster. It is also worth considering how the operations behave in a geode transaction. was: FRED: I can now edit this! In JDK 1.8 ConcurrentMap added the following default methods to the interface: getOrDefault computeIfAbsent computeIfPresent compute merge foreach replaceAll All of the default implementations of these methods have issues with get returning null when the key actually exists. So they do not support invalid region entries. The other problem with all of them (except getOrDefault) is that they will make multiple round trips when done from a proxy. In a distributed environment we should implement these to send the lambda to the primary so that the entire operation can be done with one message and while the RegionEntry is locked. This would require that the lambda parameter by serializable which would be consistent with what we do for other parameters to Region methods (for example "put"). >From a performance point of view "foreach" and "replaceAll" are the worst >since they bring back to whoever is executing the method all the keys and >values from the entire cluster. It is also worth considering how the operations behave in a geode transaction. > optimize new 1.8 ConcurrentMap default methods on Region > > > Key: GEODE-2727 > URL: https://issues.apache.org/jira/browse/GEODE-2727 > Project: Geode > Issue Type: Improvement > Components: regions >Reporter: Darrel Schneider >Priority: Major > Labels: Starter, region_interface, storage_2 > > In JDK 1.8 ConcurrentMap added the following default methods to the interface: > getOrDefault > computeIfAbsent > computeIfPresent > compute > merge > foreach > replaceAll > All of the default implementations of these methods have issues with get > returning null when the key actually exists. So they do not support invalid > region entries. > The other problem with all of them (except getOrDefault) is that they will > make multiple round trips when done from a proxy. In a distributed > environment we should implement these to send the lambda to the primary so > that the entire operation can be done with one message and while the > RegionEntry is locked. > This would require that the lambda parameter by serializable which would be > consistent with what we do for other parameters to Region methods (for > example "put"). > From a performance point of view "foreach" and "replaceAll" are the worst > since they bring back to whoever is executing the method all the keys and > values from the entire cluster. > It is also worth considering how the operations behave in a geode > transaction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-2727) optimize new 1.8 ConcurrentMap default methods on Region
[ https://issues.apache.org/jira/browse/GEODE-2727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-2727: - Labels: Starter region_interface storage_2 (was: region_interface storage_2) > optimize new 1.8 ConcurrentMap default methods on Region > > > Key: GEODE-2727 > URL: https://issues.apache.org/jira/browse/GEODE-2727 > Project: Geode > Issue Type: Improvement > Components: regions >Reporter: Darrel Schneider >Priority: Major > Labels: Starter, region_interface, storage_2 > > In JDK 1.8 ConcurrentMap added the following default methods to the interface: > getOrDefault > computeIfAbsent > computeIfPresent > compute > merge > foreach > replaceAll > All of the default implementations of these methods have issues with get > returning null when the key actually exists. So they do not support invalid > region entries. > The other problem with all of them (except getOrDefault) is that they will > make multiple round trips when done from a proxy. In a distributed > environment we should implement these to send the lambda to the primary so > that the entire operation can be done with one message and while the > RegionEntry is locked. > This would require that the lambda parameter by serializable which would be > consistent with what we do for other parameters to Region methods (for > example "put"). > From a performance point of view "foreach" and "replaceAll" are the worst > since they bring back to whoever is executing the method all the keys and > values from the entire cluster. > It is also worth considering how the operations behave in a geode > transaction. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4658) Expose how much time it takes to write to disk and what is the disk store size
[
https://issues.apache.org/jira/browse/GEODE-4658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-4658:
-
Labels: Starter (was: )
> Expose how much time it takes to write to disk and what is the disk store size
> --
>
> Key: GEODE-4658
> URL: https://issues.apache.org/jira/browse/GEODE-4658
> Project: Geode
> Issue Type: Improvement
> Components: regions
>Reporter: Fred Krone
>Priority: Major
> Labels: Starter
>
> *Given* I have a persistent region with a default disk store
> *When* I write data on the region
> *Then* I can see 2 new metrics {{average write time to disk}} ns time and
> {{size of disk store}} in bytes
> h3. Documentation
> Add this new metric to the docs
>
> This should be a matter of altering the ShowMetricsCommand.java
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-4322) Locator fails to start with NPE during join to the distributed system
[ https://issues.apache.org/jira/browse/GEODE-4322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Baynes resolved GEODE-4322. - Resolution: Won't Fix Following the procedure to delete the .dat files is the best bet until you can upgrade to at least 1.3 (though 1.4 would be recommended because of the additional fix). It would be non-trivial to backport all of the related change from 1.3.0/1.4.0. Closing as "won't fix" for 1.2.0. > Locator fails to start with NPE during join to the distributed system > - > > Key: GEODE-4322 > URL: https://issues.apache.org/jira/browse/GEODE-4322 > Project: Geode > Issue Type: Bug > Components: membership >Affects Versions: 1.2.0 >Reporter: Vahram Aharonyan >Assignee: Brian Baynes >Priority: Major > > Found out that after setting security-udp-dhalgo=AES:128 in prorperties files > sometimes locator is failing to come online with the following Exception: > [severe 2018/01/19 04:22:12.194 PST tid=0x45] > Exception in processing request from 10.144.248.41 > java.lang.RuntimeException: Not found public key for member > 16nodedata6(d4b4f5d4-47d2-44b1-a07c-6a7f5755e52d:11493):10002 > at > org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPublicKey(GMSEncrypt.java:177) > at > org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.getPublicKey(JGroupsMessenger.java:1365) > at > org.apache.geode.distributed.internal.membership.gms.locator.GMSLocator.processRequest(GMSLocator.java:271) > at > org.apache.geode.distributed.internal.InternalLocator$PrimaryHandler.processRequest(InternalLocator.java:1256) > at > org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:401) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.NullPointerException > at > org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPeerEncryptor(GMSEncrypt.java:258) > at > org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPublicKey(GMSEncrypt.java:175) > ... 7 more > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at java.lang.Thread.run(Thread.java:748) > Caused by: java.lang.NullPointerException > at > org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPeerEncryptor(GMSEncrypt.java:258) > at > org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPublicKey(GMSEncrypt.java:175) > ... 7 more > Please note, that generally this issue is hit after cluster restart. This is > important, as during poweroff locator can go offline first and one of other > members will become coordinator and update view file accordingly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4518) make DSCODE an enum
[
https://issues.apache.org/jira/browse/GEODE-4518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Murmann updated GEODE-4518:
-
Labels: Starter (was: )
> make DSCODE an enum
> ---
>
> Key: GEODE-4518
> URL: https://issues.apache.org/jira/browse/GEODE-4518
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Reporter: Galen O'Sullivan
>Priority: Major
> Labels: Starter
>
> From DSCODE:
> {color:#629755}/**
> {color}{color:#629755} * An interface that contains a bunch of static final
> values used for the implementation of
> {color}{color:#629755} * {{color}{color:#629755}@link
> {color}{color:#629755}DataSerializer}. It is basically an Enum and could be
> changed to one once we drop 1.4. The
> {color}{color:#629755} * allowed range of these codes is -128..127 inclusive
> (i.e. byte).
> {color}{color:#629755} *
> {color}{color:#629755} * {color}{color:#629755}@since
> {color}{color:#629755}GemFire 5.7{color}
> {color:#33}Since we no longer support Java 4, let's make this an
> enum.{color}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-3061) DistributedSystem properties specified in cluster config are ignored
[ https://issues.apache.org/jira/browse/GEODE-3061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-3061: -- Component/s: docs > DistributedSystem properties specified in cluster config are ignored > > > Key: GEODE-3061 > URL: https://issues.apache.org/jira/browse/GEODE-3061 > Project: Geode > Issue Type: Bug > Components: configuration, docs >Reporter: Kirk Lund >Priority: Major > > Cluster config is requested and applied during initialization of a > GemFireCacheImpl instance. Since the DistributedSystem instance is created > and fully initialized before the Cache, this means that any > gemfire.properties specified in cluster config that would normally affect the > DistributedSystem instance will be ignored. Default values for those > gemfire.properties will end up being used by the DistributedSystem instance. > Need to add a comment with a comprehensive list of gemfire.properties that > are ignored when using cluster config. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4638) review protobuf server error responses and logging for region-not-found
[ https://issues.apache.org/jira/browse/GEODE-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16377119#comment-16377119 ] ASF subversion and git services commented on GEODE-4638: Commit de2cb20632fb8200a10238bfff206bb70bb97433 in geode's branch refs/heads/develop from [~PivotalSarge] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=de2cb20 ] GEODE-4638: Standardize hanlding of region-not-found errors. (#1492) > review protobuf server error responses and logging for region-not-found > --- > > Key: GEODE-4638 > URL: https://issues.apache.org/jira/browse/GEODE-4638 > Project: Geode > Issue Type: Task > Components: client/server >Reporter: Bruce Schuchardt >Assignee: Michael Dodge >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Some operation handlers log region-not-found problems at error level and some > at warning level. Some return a SERVER_ERROR error code and some return an > INVALID_REQUEST error code. These should probably all behave in the same way. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4745) CI Failure : entriesFlushedToIndexAfterWaitForFlushCalled
nabarun created GEODE-4745: -- Summary: CI Failure : entriesFlushedToIndexAfterWaitForFlushCalled Key: GEODE-4745 URL: https://issues.apache.org/jira/browse/GEODE-4745 Project: Geode Issue Type: Bug Components: lucene Reporter: nabarun org.apache.geode.cache.lucene.LuceneIndexMaintenanceIntegrationTest > entriesFlushedToIndexAfterWaitForFlushCalled FAILED java.lang.AssertionError: expected:<8> but was:<7> at org.junit.Assert.fail(Assert.java:88) at org.junit.Assert.failNotEquals(Assert.java:834) at org.junit.Assert.assertEquals(Assert.java:645) at org.junit.Assert.assertEquals(Assert.java:631) at org.apache.geode.cache.lucene.LuceneIndexMaintenanceIntegrationTest.entriesFlushedToIndexAfterWaitForFlushCalled(LuceneIndexMaintenanceIntegrationTest.java:277) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4744) Allow java.util.Map#get in OQL when security is enabled
[
https://issues.apache.org/jira/browse/GEODE-4744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-4744:
-
Affects Version/s: 1.3.0
> Allow java.util.Map#get in OQL when security is enabled
> ---
>
> Key: GEODE-4744
> URL: https://issues.apache.org/jira/browse/GEODE-4744
> Project: Geode
> Issue Type: Improvement
> Components: querying
>Affects Versions: 1.3.0
>Reporter: Masaki Yamakawa
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am migrating from GemFire 7.x to Geode. After migration, An exception is
> now thrown in OQL when security is enabled.
> The OQL in which the exception occurs is as follows:
> {code:sql}
> select * from /RegionA a where a['intData']=1 and a['strData1']='ABC' and
> a.get(1)=98 and a.get('strData2')='DEF'
> {code}
> {code:sql}
> select * from /RegionB where mapField.get('mapData1')='ZZZ' and
> mapField.get(0)=123
> {code}
> * The value of Region A is java.util.Map, the value of Region B is its domain
> object, and it holds the public field of java.util.Map called mapField.
> I would like to allow java.util.Map#get in OQL.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
