[jira] [Updated] (GEODE-4270) [CI Failure] org.apache.geode.cache.query.cq.dunit.CqSecurityAuthorizedUserDUnitTest > cqExecuteWithInitialResultsWithMethodInvocationWithUnpopulatedRegionAndFollowedByAP
[
https://issues.apache.org/jira/browse/GEODE-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Baynes updated GEODE-4270:
Component/s: client/server
> [CI Failure]
> org.apache.geode.cache.query.cq.dunit.CqSecurityAuthorizedUserDUnitTest >
> cqExecuteWithInitialResultsWithMethodInvocationWithUnpopulatedRegionAndFollowedByAPutShouldTriggerCqError[0]
> FAILED
> --
>
> Key: GEODE-4270
> URL: https://issues.apache.org/jira/browse/GEODE-4270
> Project: Geode
> Issue Type: Bug
> Components: client/server, security
>Reporter: nabarun
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> org.apache.geode.cache.query.cq.dunit.CqSecurityAuthorizedUserDUnitTest >
> cqExecuteWithInitialResultsWithMethodInvocationWithUnpopulatedRegionAndFollowedByAPutShouldTriggerCqError[0]
> FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.query.QuerySecurityBase$$Lambda$50/1990038369.run
> in VM 1 running on Host 6b888a694193 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:393)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:363)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:308)
> at
> org.apache.geode.security.query.QuerySecurityBase.putIntoRegion(QuerySecurityBase.java:202)
> at
> org.apache.geode.cache.query.cq.dunit.CqSecurityAuthorizedUserDUnitTest.cqExecuteWithInitialResultsWithMethodInvocationWithUnpopulatedRegionAndFollowedByAPutShouldTriggerCqError(CqSecurityAuthorizedUserDUnitTest.java:138)
> Caused by:
> org.apache.geode.cache.client.ServerOperationException: remote server
> on 6b888a694193(153:loner):32936:ced4ccdc:
> org.apache.geode.security.GemFireSecurityException: Error: Anonymous User
> Caused by:
> org.apache.geode.security.GemFireSecurityException: Error:
> Anonymous User
> {noformat}
> *+Test logs+*
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/70#L5a4ed7fc:654
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4270) [CI Failure] org.apache.geode.cache.query.cq.dunit.CqSecurityAuthorizedUserDUnitTest > cqExecuteWithInitialResultsWithMethodInvocationWithUnpopulatedRegionAndFollowedByAP
[
https://issues.apache.org/jira/browse/GEODE-4270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-4270:
--
Labels: pull-request-available (was: )
> [CI Failure]
> org.apache.geode.cache.query.cq.dunit.CqSecurityAuthorizedUserDUnitTest >
> cqExecuteWithInitialResultsWithMethodInvocationWithUnpopulatedRegionAndFollowedByAPutShouldTriggerCqError[0]
> FAILED
> --
>
> Key: GEODE-4270
> URL: https://issues.apache.org/jira/browse/GEODE-4270
> Project: Geode
> Issue Type: Bug
> Components: security
>Reporter: nabarun
>Priority: Major
> Labels: pull-request-available
>
> {noformat}
> org.apache.geode.cache.query.cq.dunit.CqSecurityAuthorizedUserDUnitTest >
> cqExecuteWithInitialResultsWithMethodInvocationWithUnpopulatedRegionAndFollowedByAPutShouldTriggerCqError[0]
> FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.security.query.QuerySecurityBase$$Lambda$50/1990038369.run
> in VM 1 running on Host 6b888a694193 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:393)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:363)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:308)
> at
> org.apache.geode.security.query.QuerySecurityBase.putIntoRegion(QuerySecurityBase.java:202)
> at
> org.apache.geode.cache.query.cq.dunit.CqSecurityAuthorizedUserDUnitTest.cqExecuteWithInitialResultsWithMethodInvocationWithUnpopulatedRegionAndFollowedByAPutShouldTriggerCqError(CqSecurityAuthorizedUserDUnitTest.java:138)
> Caused by:
> org.apache.geode.cache.client.ServerOperationException: remote server
> on 6b888a694193(153:loner):32936:ced4ccdc:
> org.apache.geode.security.GemFireSecurityException: Error: Anonymous User
> Caused by:
> org.apache.geode.security.GemFireSecurityException: Error:
> Anonymous User
> {noformat}
> *+Test logs+*
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/70#L5a4ed7fc:654
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4078) Display full path when locator0vIews.log cannot be opened
[
https://issues.apache.org/jira/browse/GEODE-4078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-4078:
-
Fix Version/s: (was: 1.4.0)
1.5.0
> Display full path when locator0vIews.log cannot be opened
> -
>
> Key: GEODE-4078
> URL: https://issues.apache.org/jira/browse/GEODE-4078
> Project: Geode
> Issue Type: Improvement
> Components: locator, logging
>Reporter: Jens Deppe
>Assignee: Jens Deppe
>Priority: Major
> Fix For: 1.5.0
>
>
> Tests are often failing with an error such as:
> {{Could not open log file "locator0views.log"}}
> Just add the absolute path to help with debugging.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-2676) RegionMBean statistics wrong on partitioned regions
[
https://issues.apache.org/jira/browse/GEODE-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-2676.
---
Resolution: Fixed
> RegionMBean statistics wrong on partitioned regions
> ---
>
> Key: GEODE-2676
> URL: https://issues.apache.org/jira/browse/GEODE-2676
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Fred Krone
>Priority: Minor
> Labels: jmx
> Fix For: 1.4.0
>
>
> RegionMBean attributes hitCount, hitRatio, missCount, lastAccessedTime, and
> lastModifiedTime will always be 0 for an mbean that represents an partitioned
> region.
> The gettors for these methods may call getStatistics() which on a PR always
> throws UnsupportedOperationException. So this exception might even get
> exposed to customers.
> The initialization of RegionMBeanBridge calls getStatisticsEnabled() which
> returns true on a PartitionedRegion. This does have meaning on a PR but it
> does not mean that getStatistics() is a supported operation. On a PR setting
> statistics-enabled causes each region-entry to also keep track of its last
> access time.
> It is true that if getStatisticsEnabled() is false then you should not call
> getStatistics. But the opposite is not true. Since we currently have regions
> that do not support getStatistics(), the code in RegionMBeanBridge should
> catch UnsupportedOperationException and handle it. I would suggest that the
> constructor be changed that initializes the "isStatisticsEnabled" field.
> Instead of only calling getStatisticsEnabled() it should also call
> getStatistics(). Something like this:
> {noformat}
> {
> boolean useGetStatistics = regAttrs.getStatisticsEnabled();
> if (useGetStatistics) {
> try {
> region.getStatistics();
> } catch (UnsupportedOperationException ex) {
> useGetStatistics = false;
> }
> }
> this.isStatisticsEnabled = useGetStatistics;
> }
> {noformat}
> That way in a future release if PRs are changed to support getStatistics this
> code will start calling it without having a direct dependency on the
> implementation of PartitionedRegion.
> https://issues.apache.org/jira/browse/GEODE-2685 is a request to support
> getStatistics on PRs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-2676) RegionMBean statistics wrong on partitioned regions
[
https://issues.apache.org/jira/browse/GEODE-2676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-2676:
--
Fix Version/s: 1.4.0
> RegionMBean statistics wrong on partitioned regions
> ---
>
> Key: GEODE-2676
> URL: https://issues.apache.org/jira/browse/GEODE-2676
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Fred Krone
>Priority: Minor
> Labels: jmx
> Fix For: 1.4.0
>
>
> RegionMBean attributes hitCount, hitRatio, missCount, lastAccessedTime, and
> lastModifiedTime will always be 0 for an mbean that represents an partitioned
> region.
> The gettors for these methods may call getStatistics() which on a PR always
> throws UnsupportedOperationException. So this exception might even get
> exposed to customers.
> The initialization of RegionMBeanBridge calls getStatisticsEnabled() which
> returns true on a PartitionedRegion. This does have meaning on a PR but it
> does not mean that getStatistics() is a supported operation. On a PR setting
> statistics-enabled causes each region-entry to also keep track of its last
> access time.
> It is true that if getStatisticsEnabled() is false then you should not call
> getStatistics. But the opposite is not true. Since we currently have regions
> that do not support getStatistics(), the code in RegionMBeanBridge should
> catch UnsupportedOperationException and handle it. I would suggest that the
> constructor be changed that initializes the "isStatisticsEnabled" field.
> Instead of only calling getStatisticsEnabled() it should also call
> getStatistics(). Something like this:
> {noformat}
> {
> boolean useGetStatistics = regAttrs.getStatisticsEnabled();
> if (useGetStatistics) {
> try {
> region.getStatistics();
> } catch (UnsupportedOperationException ex) {
> useGetStatistics = false;
> }
> }
> this.isStatisticsEnabled = useGetStatistics;
> }
> {noformat}
> That way in a future release if PRs are changed to support getStatistics this
> code will start calling it without having a direct dependency on the
> implementation of PartitionedRegion.
> https://issues.apache.org/jira/browse/GEODE-2685 is a request to support
> getStatistics on PRs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-4043) Add system property to opt into new algorithm
[ https://issues.apache.org/jira/browse/GEODE-4043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-4043. --- > Add system property to opt into new algorithm > - > > Key: GEODE-4043 > URL: https://issues.apache.org/jira/browse/GEODE-4043 > Project: Geode > Issue Type: Sub-task > Components: eviction >Reporter: Fred Krone >Priority: Major > Fix For: 1.4.0 > > > We'd like to check in our eviction code update (GEODE-3869) and allow users > to opt into using it so we can GA it. > The default behavior (if system property is not set) would be to use the > current eviction algorithm. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4051) Two server jvms crashed at same time and caused some primary and redundant buckets to be cleared. Causing some buckets to get locked and not able to recover also after bou
[ https://issues.apache.org/jira/browse/GEODE-4051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-4051. --- > Two server jvms crashed at same time and caused some primary and redundant > buckets to be cleared. Causing some buckets to get locked and not able to > recover also after bouncing all servers > > > Key: GEODE-4051 > URL: https://issues.apache.org/jira/browse/GEODE-4051 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.2.0 >Reporter: Igor Barchak >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.4.0 > > > "Pooled Waiting Message Processor 5" tid=0x162 > java.lang.Thread.State: TIMED_WAITING > at sun.misc.Unsafe.park(Native Method) > - waiting on java.util.concurrent.CountDownLatch$Sync@1993a5 > at > java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1037) > at > java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1328) > at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:277) > at > org.apache.geode.internal.util.concurrent.StoppableCountDownLatch.await(StoppableCountDownLatch.java:64) > at > org.apache.geode.distributed.internal.ReplyProcessor21.basicWait(ReplyProcessor21.java:715) > at > org.apache.geode.distributed.internal.ReplyProcessor21.waitForReplies(ReplyProcessor21.java:644) > at > org.apache.geode.distributed.internal.ReplyProcessor21.waitForReplies(ReplyProcessor21.java:624) > at > org.apache.geode.distributed.internal.ReplyProcessor21.waitForReplies(ReplyProcessor21.java:519) > at > org.apache.geode.internal.cache.StateFlushOperation.flush(StateFlushOperation.java:243) > at > org.apache.geode.internal.cache.InitialImageOperation.getFromOne(InitialImageOperation.java:349) > at > org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1168) > at > org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1023) > at > org.apache.geode.internal.cache.BucketRegion.initialize(BucketRegion.java:253) > at > org.apache.geode.internal.cache.LocalRegion.createSubregion(LocalRegion.java:962) > at > org.apache.geode.internal.cache.PartitionedRegionDataStore.createBucketRegion(PartitionedRegionDataStore.java:726) > at > org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucket(PartitionedRegionDataStore.java:414) > - locked org.apache.geode.internal.cache.ProxyBucketRegion@6820a0b6 > at > org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucketRecursively(PartitionedRegionDataStore.java:272) > at > org.apache.geode.internal.cache.PartitionedRegionDataStore.grabBucket(PartitionedRegionDataStore.java:2815) > at > org.apache.geode.internal.cache.partitioned.ManageBackupBucketMessage.operateOnPartitionedRegion(ManageBackupBucketMessage.java:148) > at > org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:332) > Seems like it was introduced in this fix > https://github.com/apache/geode/commit/3a1062e245b3ded52ea3f6b6de0aff94ce846fa3?diff=split > See StateMarkerMessage.process > The first if condition doesn't have a finally block. > The else has a finally block. > The first if condition didn't have a 'waitFor' operation earlier - it was > introduced in this commit -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3792) Improve test coverage of PartitionedRegion lifecycle
[ https://issues.apache.org/jira/browse/GEODE-3792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3792. --- > Improve test coverage of PartitionedRegion lifecycle > > > Key: GEODE-3792 > URL: https://issues.apache.org/jira/browse/GEODE-3792 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Fix For: 1.4.0 > > > Verify behavior when a PartitionedRegion is: a) closed in one member, b) > closed and then recreated in one member, c) locally destroyed in one member > -- while the PartitionedRegion continues to exist in other members of the > cluster. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4017) Implement alter jdbc-connection command
[
https://issues.apache.org/jira/browse/GEODE-4017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-4017.
---
> Implement alter jdbc-connection command
> ---
>
> Key: GEODE-4017
> URL: https://issues.apache.org/jira/browse/GEODE-4017
> Project: Geode
> Issue Type: Sub-task
> Components: docs, regions
>Reporter: Kirk Lund
>Assignee: Lynn Gallinat
>Priority: Major
> Fix For: 1.4.0
>
>
> Need to be able to alter an existing JDBC connection via GFSH.
> {noformat}
> NAME
> alter jdbc-connection
> SYNOPSIS
> This provides the ability to alter the parameters necessary to
> communicate with a database through JDBC.
> SYNTAX
> alter jdbc-connection [--url=value] [--user=value] [--password=value]
> [--params=key:value[,key:value...]]
> PARAMETERS
> url
> Change the url location for the database
> Required: false
> user
> Change name of user to connect to database as
> Required: false
> password
> Change the password to use when connecting to database
> Required: false
> Params
> Change the additional parameters to use when connecting to database.
> No parameters are yet supported
> Required: false
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-4125) Add correct runner to query and wan tests
[ https://issues.apache.org/jira/browse/GEODE-4125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-4125. --- > Add correct runner to query and wan tests > - > > Key: GEODE-4125 > URL: https://issues.apache.org/jira/browse/GEODE-4125 > Project: Geode > Issue Type: Sub-task > Components: tests >Reporter: Jason Huynh >Assignee: Jason Huynh >Priority: Major > Fix For: 1.4.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3961) Show metrics disregards specified --categories for CacheServer (--port option related) metrics
[
https://issues.apache.org/jira/browse/GEODE-3961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-3961.
---
> Show metrics disregards specified --categories for CacheServer (--port option
> related) metrics
> ---
>
> Key: GEODE-3961
> URL: https://issues.apache.org/jira/browse/GEODE-3961
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Fix For: 1.4.0
>
>
> Those CacheServer metric categories ({{query}}, {{notification}}, and
> {{cache-server}}) are not checked against those categories specified by the
> user and are only checked against the cache server bean being non-null
> (implicitly: that the port was provided and valid).
> For unification and consistency, these categories should not be displayed
> when the {{--categories}} option is specified and excludes them.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-3819) Refactor CreateRegionCommandDUnitTest to use gfsh rules
[ https://issues.apache.org/jira/browse/GEODE-3819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3819. --- > Refactor CreateRegionCommandDUnitTest to use gfsh rules > --- > > Key: GEODE-3819 > URL: https://issues.apache.org/jira/browse/GEODE-3819 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Jens Deppe >Priority: Major > Fix For: 1.4.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4192) GetServer request should return error if no servers found
[ https://issues.apache.org/jira/browse/GEODE-4192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-4192. --- > GetServer request should return error if no servers found > - > > Key: GEODE-4192 > URL: https://issues.apache.org/jira/browse/GEODE-4192 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Brian Baynes >Priority: Major > Fix For: 1.4.0 > > > When a GetServer message is received but no servers are found, we should send > back an error (rather than success and a null value for server location). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-551) CI Failure: MemoryThresholdsOffHeapDUnitTest.testPRLoadRejection failed
[ https://issues.apache.org/jira/browse/GEODE-551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-551. -- > CI Failure: MemoryThresholdsOffHeapDUnitTest.testPRLoadRejection failed > --- > > Key: GEODE-551 > URL: https://issues.apache.org/jira/browse/GEODE-551 > Project: Geode > Issue Type: Bug > Components: offheap >Reporter: Hitesh Khamesra >Assignee: Eric Shu >Priority: Major > Labels: CI, Flaky > Fix For: 1.4.0 > > > dunit.RMIException: While invoking > com.gemstone.gemfire.cache.management.MemoryThresholdsOffHeapDUnitTest$35.call > in VM 1 running on Host zambia.gemstone.com with 4 VMs > at dunit.VM.invoke(VM.java:369) > at dunit.VM.invoke(VM.java:312) > at dunit.VM.invoke(VM.java:280) > at > com.gemstone.gemfire.cache.management.MemoryThresholdsOffHeapDUnitTest.testPRLoadRejection(MemoryThresholdsOffHeapDUnitTest.java:1068) > 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:497) > at junit.framework.TestCase.runTest(TestCase.java:176) > at junit.framework.TestCase.runBare(TestCase.java:141) > at junit.framework.TestResult$1.protect(TestResult.java:122) > at junit.framework.TestResult.runProtected(TestResult.java:142) > at junit.framework.TestResult.run(TestResult.java:125) > at junit.framework.TestCase.run(TestCase.java:129) > at junit.framework.TestSuite.runTest(TestSuite.java:252) > at junit.framework.TestSuite.run(TestSuite.java:247) > at > org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50) > 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:497) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) > at > org.gradle.messaging.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:106) > 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:497) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360) > at > org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54) > at > org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: junit.framework.AssertionFailedError > at junit.framework.Assert.fail(Assert.java:55) > at junit.framework.Assert.assertTrue(Assert.java:22) > at junit.framework.Assert.assertTrue(Assert.java:31) > at junit.framework.TestCase.assertTrue(TestCase.java:201) > at > com.gemstone.gemfire.cache.management.MemoryThresholdsOffHeapDUnitTest$35.call(MemoryThresholdsOffHeapDUnitTest.java:1094) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[jira] [Closed] (GEODE-4103) Distributed Tests should fork for every test
[ https://issues.apache.org/jira/browse/GEODE-4103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-4103. --- > Distributed Tests should fork for every test > > > Key: GEODE-4103 > URL: https://issues.apache.org/jira/browse/GEODE-4103 > Project: Geode > Issue Type: Test > Components: build >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Fix For: 1.4.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3521) Allow region set op to bootstrap JTA and transaction
[ https://issues.apache.org/jira/browse/GEODE-3521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3521. --- > Allow region set op to bootstrap JTA and transaction > > > Key: GEODE-3521 > URL: https://issues.apache.org/jira/browse/GEODE-3521 > Project: Geode > Issue Type: Improvement > Components: docs, transactions >Affects Versions: 1.2.0 >Reporter: Fred Krone >Assignee: Eric Shu >Priority: Major > Fix For: 1.4.0 > > > Allow region set op to bootstrap the transaction. To allow backward > compatibility, introduce a new GemFire property to allow the old behavior. > AC: > 1) set operation bootstraps transaction > 2) provide a GemFire property (boolean) to opt out of this behavior for > backwards compatibility > 3) update unit tests notes accordingly > 4) update documentation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3980) Windows test failures in AvailablePidTest due to TestTimedOutException in findAvailablePids
[
https://issues.apache.org/jira/browse/GEODE-3980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-3980.
---
> Windows test failures in AvailablePidTest due to TestTimedOutException in
> findAvailablePids
>
>
> Key: GEODE-3980
> URL: https://issues.apache.org/jira/browse/GEODE-3980
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
> Fix For: 1.4.0
>
>
> Stack trace from pipeline failure:
> {code:title=findAvailablePidsShouldReturnNoDuplicatedPids}
> org.junit.runners.model.TestTimedOutException: test timed out after 20 seconds
> at java.io.WinNTFileSystem.list(Native Method)
> at java.io.File.list(File.java:1122)
> at java.io.File.listFiles(File.java:1248)
> at
> sun.jvmstat.perfdata.monitor.protocol.local.LocalVmManager.activeVms(LocalVmManager.java:186)
> at
> sun.jvmstat.perfdata.monitor.protocol.local.MonitoredHostProvider.activeVms(MonitoredHostProvider.java:150)
> at
> sun.tools.attach.HotSpotAttachProvider.listVirtualMachines(HotSpotAttachProvider.java:81)
> at
> sun.tools.attach.WindowsAttachProvider.listVirtualMachines(WindowsAttachProvider.java:76)
> at com.sun.tools.attach.VirtualMachine.list(VirtualMachine.java:147)
> at
> org.apache.geode.internal.process.AttachProcessUtils.isProcessAlive(AttachProcessUtils.java:35)
> at
> org.apache.geode.internal.process.ProcessUtils.isProcessAlive(ProcessUtils.java:81)
> at
> org.apache.geode.internal.process.lang.AvailablePid.findAvailablePid(AvailablePid.java:131)
> at
> org.apache.geode.internal.process.lang.AvailablePid.findAvailablePids(AvailablePid.java:148)
> at
> org.apache.geode.internal.process.lang.AvailablePidTest.findAvailablePidsShouldReturnNoDuplicatedPids(AvailablePidTest.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.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.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298)
> at
> org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-4193) Using JMX password file to secure JMX manager results in connection error.
[ https://issues.apache.org/jira/browse/GEODE-4193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-4193. --- > Using JMX password file to secure JMX manager results in connection error. > -- > > Key: GEODE-4193 > URL: https://issues.apache.org/jira/browse/GEODE-4193 > Project: Geode > Issue Type: Bug > Components: gfsh, security >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Fix For: 1.4.0 > > > Steps to reproduce: > gfsh>start locator --name=locator > --J=-Dgemfire.jmx-manager-password-file=password.properties > gfsh>connect > stack trace in gfsh log: > [info 2018/01/04 08:57:36.498 PST Gfsh Launcher tid=0x1f] (msgTID=31 msgSN=6) > Authentication failed! Credentials should be String[] instead of > java.util.Properties > java.lang.SecurityException: Authentication failed! Credentials should be > String[] instead of java.util.Properties > at > com.sun.jmx.remote.security.JMXPluggableAuthenticator.authenticationFailure(JMXPluggableAuthenticator.java:211) > at > com.sun.jmx.remote.security.JMXPluggableAuthenticator.authenticate(JMXPluggableAuthenticator.java:168) > at > javax.management.remote.rmi.RMIServerImpl.doNewClient(RMIServerImpl.java:232) > at > javax.management.remote.rmi.RMIServerImpl.newClient(RMIServerImpl.java:199) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357) > at sun.rmi.transport.Transport$1.run(Transport.java:200) > at sun.rmi.transport.Transport$1.run(Transport.java:197) > at java.security.AccessController.doPrivileged(Native Method) > at sun.rmi.transport.Transport.serviceCall(Transport.java:196) > at > sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568) > at > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826) > at > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683) > at java.security.AccessController.doPrivileged(Native Method) > at > sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682) > at > 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) > at > sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:283) > at > sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:260) > at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:161) > at javax.management.remote.rmi.RMIServerImpl_Stub.newClient(Unknown > Source) > at > javax.management.remote.rmi.RMIConnector.getConnection(RMIConnector.java:2430) > at > javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:308) > at > javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270) > at > org.apache.geode.management.internal.cli.shell.JmxOperationInvoker.(JmxOperationInvoker.java:142) > at > org.apache.geode.management.internal.cli.commands.StartLocatorCommand.doAutoConnect(StartLocatorCommand.java:336) > at > org.apache.geode.management.internal.cli.commands.StartLocatorCommand.startLocator(StartLocatorCommand.java:296) > 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.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:216) > at > org.apache.geode.management.internal.cli.remote.CommandExecutor.invokeCommand(CommandExecutor.java:97) > at > org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:45) > at > org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:39) > at > org.apache.geode.management.internal.cli.shell.GfshExecutionStrategy.execute(GfshExecutionStrategy.java:79) > at > org.springframework.shell.core.AbstractShell.executeCommand(AbstractShell.java:134) > at > org.apache.geode.management.internal.cli.shell.Gfsh.promptLoop(Gfsh.java:1008) > at
[jira] [Closed] (GEODE-3956) The JMX RegionMBean listRegionAttributes operation doesn't include the async-event-queue-ids or gateway-sender-ids
[
https://issues.apache.org/jira/browse/GEODE-3956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-3956.
---
> The JMX RegionMBean listRegionAttributes operation doesn't include the
> async-event-queue-ids or gateway-sender-ids
> --
>
> Key: GEODE-3956
> URL: https://issues.apache.org/jira/browse/GEODE-3956
> Project: Geode
> Issue Type: Improvement
> Components: jmx
>Reporter: Barry Oglesby
>Priority: Major
> Fix For: 1.4.0
>
>
> That would be a modification to the
> {{org.apache.geode.management.internal.beans.RegionMBeanCompositeDataFactory
> getRegionAttributesData}} method and the
> {{org.apache.geode.management.RegionAttributesData}} class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-3763) Refactor ListIndexCommandDUnitTest to use rules instead of CliCommandTestBase
[ https://issues.apache.org/jira/browse/GEODE-3763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3763. --- > Refactor ListIndexCommandDUnitTest to use rules instead of CliCommandTestBase > - > > Key: GEODE-3763 > URL: https://issues.apache.org/jira/browse/GEODE-3763 > Project: Geode > Issue Type: Test > Components: gfsh >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Fix For: 1.4.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3815) Entries are incorrectly removed from the index map during parallel gateway queue conflation
[
https://issues.apache.org/jira/browse/GEODE-3815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-3815.
---
> Entries are incorrectly removed from the index map during parallel gateway
> queue conflation
> ---
>
> Key: GEODE-3815
> URL: https://issues.apache.org/jira/browse/GEODE-3815
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barry Oglesby
>Priority: Major
> Fix For: 1.4.0
>
>
> When an event is sent to a {{Gateway}} queue, it does a put into a map of
> indexes tracking realKey to queueKey if conflation is enabled. This put
> returns the previous queueKey which sent to a separate {{WAN Queue Conflation
> Thread}} thread to be removed from the queue. The {{WAN Queue Conflation
> Thread}} also removes the key from the map of indexes. This is not correct
> behavior. Its always going to remove a current index.
> Here is some logging that shows the behavior. In this case, the
> {{ServerConnection}} thread is updating key=0. The previousTailKey=726 (thats
> the key in the queue), which the {{WAN Queue Conflation Thread}} removes from
> the queue. It also removes index=839 from the index map. This causes the next
> update for key=0 into the queue to not find anything in the index map
> (previousTailKey=null), so the previous event is not removed from the queue.
> {noformat}
> ServerConnection on port 60268 Thread 1: BucketRegionQueue.conflateOldEntry
> putting keyToConflate=0; tailKey=839
> ServerConnection on port 60268 Thread 1: BucketRegionQueue.conflateOldEntry
> previousTailKey=726
> WAN Queue Conflation Thread: ConflationHandler.run previousTailKey=726
> WAN Queue Conflation Thread: ParallelGatewaySenderQueue.destroyEventFromQueue
> about to destroyKey key=726
> WAN Queue Conflation Thread: BucketRegionQueue.removeIndex index=839
> WAN Queue Conflation Thread: ParallelGatewaySenderQueue.destroyEventFromQueue
> done destroyKey key=726
> ServerConnection on port 60268 Thread 1: BucketRegionQueue.conflateOldEntry
> putting keyToConflate=0; tailKey=952
> ServerConnection on port 60268 Thread 1: BucketRegionQueue.conflateOldEntry
> previousTailKey=null
> {noformat}
> If I remove this code from {{BucketRegionQueue.basicDestroy}} which is called
> by the {{WAN Queue Conflation Thread}}, conflation works fine:
> {noformat}
> if (getPartitionedRegion().isConflationEnabled()) {
> removeIndex((Long)event.getKey());
> }
> {noformat}
> The {{WAN Queue Conflation Thread}} handles {{EntryNotFoundException}}, so if
> the entry doesn't exist (meaning it already was sent), its ok. Since this
> method is also called during normal queue removal, I'm not sure if there are
> consequences to removing this code, though. Also, I haven't looked to see if
> the serial queue has this same issue.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-3869) Refactor eviction code
[ https://issues.apache.org/jira/browse/GEODE-3869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3869. --- > Refactor eviction code > -- > > Key: GEODE-3869 > URL: https://issues.apache.org/jira/browse/GEODE-3869 > Project: Geode > Issue Type: Improvement > Components: eviction >Reporter: Kirk Lund >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.4.0 > > > Refactor eviction: > * repackage internal.cache.lru as internal.cache.eviction [1] > * remove collision between interfaces LRUClockNode and RegionEntry [2] > [1] I want to repackage org.apache.geode.internal.cache.lru as > org.apache.geode.internal.cache.eviction to prepare for renaming LRU classes > to be Eviction classes. > [2] both interfaces define `void setRecentlyUsed();` -- both of which are > implemented by region entries -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3622) The first HeapLRU evictions on large region can consume high amounts of CPU
[ https://issues.apache.org/jira/browse/GEODE-3622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3622. --- > The first HeapLRU evictions on large region can consume high amounts of CPU > --- > > Key: GEODE-3622 > URL: https://issues.apache.org/jira/browse/GEODE-3622 > Project: Geode > Issue Type: Improvement > Components: eviction >Reporter: Darrel Schneider >Assignee: Kirk Lund >Priority: Major > Fix For: 1.4.0 > > > If you have a region configured for HeapLRU eviction and are able to put a > large number of entries in it before hitting the eviction threshold, then the > first evictions will consume much more CPU than subsequent evictions. The > reason for this is that the eviction list is not initialized until the first > eviction is done. At that time a scan is done of all the existing entries > marking each one as not having been recently used. This can touch a large > number of memory pages and also hits some common synchronization locks. You > can see that this is happening by looking at the HeapLRUStats.lruEvaluations > stat. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3990) Implement alter jdbc-region-mapping command
[
https://issues.apache.org/jira/browse/GEODE-3990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-3990.
---
> Implement alter jdbc-region-mapping command
> ---
>
> Key: GEODE-3990
> URL: https://issues.apache.org/jira/browse/GEODE-3990
> Project: Geode
> Issue Type: Sub-task
> Components: regions
>Reporter: Fred Krone
>Assignee: Nick Reich
>Priority: Major
> Fix For: 1.4.0
>
>
> SYNTAX
> alter jdbc-mapping --region=value [--data-source=value]
> [--pdx-name=value][--table=value] [--id=value[,value...]]
> [--add-field=('name': value, ['column': value,] ['class': value,] ['type':
> value])] [--remove-field=value]
> PARAMETERS
> data-source
> for JDBC connection.
> Required: false
> pdx-name
> for GemFire PDX to parse the PDX fields.
> Required: false
> region
> Name/path of the region to be associated with DB table.
> Required: true
> Table
> to be associated with GemFire region.
> Required: false
> id
> the key in the identification of a GemFire object.
> Required: false
> add-field
> JSON text specifying the mapping from a GemFire PdxInstance field to a DB
> column.
> Required: false
> remove-field
> Name of existing PdxInstance field to remove
> required: false
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-3799) Create plugin system for specifying where a backup is stored
[ https://issues.apache.org/jira/browse/GEODE-3799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3799. --- > Create plugin system for specifying where a backup is stored > > > Key: GEODE-3799 > URL: https://issues.apache.org/jira/browse/GEODE-3799 > Project: Geode > Issue Type: Sub-task > Components: persistence >Reporter: Nick Reich >Assignee: Nick Reich >Priority: Major > Fix For: 1.4.0 > > > The current logic merges the moving/copying of files with the determining of > what to backup. To make it possible to store a backup in cloud storage or > other locations, we need to separate these concerns, putting the variable, > location-based logic, into a plugin architecture. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3363) Refactor CreateGatewaySenderCommandDUnitTest to use test rules
[
https://issues.apache.org/jira/browse/GEODE-3363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-3363.
---
> Refactor CreateGatewaySenderCommandDUnitTest to use test rules
> --
>
> Key: GEODE-3363
> URL: https://issues.apache.org/jira/browse/GEODE-3363
> Project: Geode
> Issue Type: Sub-task
> Components: tests
>Reporter: Emily Yeh
>Assignee: Shelley Lynn Hughes-Godfrey
>Priority: Major
> Fix For: 1.4.0
>
>
> {{CreateGatewaySenderCommandDUnitTest}} is using {{CliCommandTestBase}},
> which is a deprecated class. It should be refactored to use more current test
> rules.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-4176) locator creates "locator0view.dat" file when started with port 0
[ https://issues.apache.org/jira/browse/GEODE-4176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-4176. --- > locator creates "locator0view.dat" file when started with port 0 > > > Key: GEODE-4176 > URL: https://issues.apache.org/jira/browse/GEODE-4176 > Project: Geode > Issue Type: Bug > Components: membership, tests >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt >Priority: Major > Fix For: 1.4.0 > > > The locator was modified some time ago to allow unit tests to start it with > port 0 so that it will do a wildcard bind. When that was done the startup > sequence wasn't changed to allow the peer-to-peer TcpHandler to know the > bound port number & so it creates its persistent view file with port 0 > instead of the bound port number. It's possible that if such a file is left > around a subsequent test that starts a locator with port 0 will pick up an > old locator0view.dat file and attempt to join a distributed system that no > longer exists. > The startup sequence needs to be modified to allow the handlers to know the > bound port number when they are initialized. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4161) gfsh describe jdbc-mapping command errors describing a valid mapping
[ https://issues.apache.org/jira/browse/GEODE-4161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-4161. --- > gfsh describe jdbc-mapping command errors describing a valid mapping > > > Key: GEODE-4161 > URL: https://issues.apache.org/jira/browse/GEODE-4161 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.4.0 >Reporter: Fred Krone >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.4.0 > > > Steps to reproduce issue: > 1) create a jdbc-mapping > 2) describe that jdbc-mapping > 3) you get an error even though the mapping exists (via list mapping, etc) > gfsh>describe jdbc-mapping --region=employee > Could not process command due to error. Error while processing command > Reason : null -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3239) Lucene indexing/searching for nested objects
[ https://issues.apache.org/jira/browse/GEODE-3239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3239. --- > Lucene indexing/searching for nested objects > > > Key: GEODE-3239 > URL: https://issues.apache.org/jira/browse/GEODE-3239 > Project: Geode > Issue Type: New Feature > Components: docs, lucene >Reporter: Dan Smith >Assignee: Diane Hardman >Priority: Major > Fix For: 1.4.0 > > > Some Geode users create data models that include nested and complex > objects. The current Geode Lucene integration supports indexing and > querying only the top-level fields in the data object. The objective of > this proposal is to support indexing and querying an arbitrary depth of > nested objects. > Add support for nested objects as proposed in this wiki page: > https://cwiki.apache.org/confluence/display/GEODE/Lucene+Text+Search+on+Nested+Object > And this associated email thread: > http://markmail.org/thread/kgkcd6slqi4uhywg -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3782) Implement CacheWriter for PDX to JDBC
[ https://issues.apache.org/jira/browse/GEODE-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3782. --- > Implement CacheWriter for PDX to JDBC > - > > Key: GEODE-3782 > URL: https://issues.apache.org/jira/browse/GEODE-3782 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Fred Krone >Assignee: Kirk Lund >Priority: Major > Fix For: 1.4.0 > > > This is for write through from the backend-db --- region.put that should be > synchronously written through to the DB > Most actions are the same as on GEODE-3783 -- except this is a synchronous > operation so if the DB update fails in any way the region.put should also > fail and return na error. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4029) Deployed jars may not be correct when multiple locators are in use
[ https://issues.apache.org/jira/browse/GEODE-4029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-4029. --- > Deployed jars may not be correct when multiple locators are in use > -- > > Key: GEODE-4029 > URL: https://issues.apache.org/jira/browse/GEODE-4029 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Fix For: 1.4.0 > > > When we have more than one locator, if a jar is re-deployed it will not be > propagated correctly to the 'remote' locators. i.e. the locators which are > not directly executing the 'deploy' command. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3970) Disable travis default _JAVA_OPTIONS
[ https://issues.apache.org/jira/browse/GEODE-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3970. --- > Disable travis default _JAVA_OPTIONS > > > Key: GEODE-3970 > URL: https://issues.apache.org/jira/browse/GEODE-3970 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Fix For: 1.4.0 > > > Travis sets _JAVA_OPTIONS="-Xmx2048m -Xms512m" which is causing builds to > fail with exit code 137. If unset, the builds pass. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3920) Add test for validating lucene 6 to 7 upgrade
[ https://issues.apache.org/jira/browse/GEODE-3920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3920. --- > Add test for validating lucene 6 to 7 upgrade > - > > Key: GEODE-3920 > URL: https://issues.apache.org/jira/browse/GEODE-3920 > Project: Geode > Issue Type: Test > Components: lucene >Reporter: Barry Oglesby >Priority: Major > Fix For: 1.4.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3739) Amend current protocol Username / password to mimic the current SecurityManager implementation
[ https://issues.apache.org/jira/browse/GEODE-3739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3739. --- > Amend current protocol Username / password to mimic the current > SecurityManager implementation > -- > > Key: GEODE-3739 > URL: https://issues.apache.org/jira/browse/GEODE-3739 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Udo Kohlmeyer >Assignee: Galen O'Sullivan >Priority: Major > Fix For: 1.4.0 > > > The current implementation of the simple username password authentication has > a very specific message. The SimpleUsernamePassword authentication class then > processes that messages and populates very specific properties and passes > that through to the SecurityManager. > Given that the securityManager implementation is custom this approach is very > limiting. The new implementation would need to better mimic the generic > properties that are passed through without having to manually set any > properties. > A suggestion is to use a more generic Properties-based authenticator, that > will take the properties that a client sets and pass them through directly to > the SecurityManager without interfering with the message other than > deserializing it from a hash into properties. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3987) Enforce the uniqueness of a single gateway-receiver per member
[
https://issues.apache.org/jira/browse/GEODE-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-3987.
---
> Enforce the uniqueness of a single gateway-receiver per member
> --
>
> Key: GEODE-3987
> URL: https://issues.apache.org/jira/browse/GEODE-3987
> Project: Geode
> Issue Type: Bug
>Reporter: Juan José Ramos Cassella
>Assignee: Juan José Ramos Cassella
>Priority: Major
> Fix For: 1.4.0
>
>
> Within the documentation, both in [Configure Gateway
> Receivers|http://geode.apache.org/docs/guide/13/topologies_and_comm/multi_site_configuration/setting_up_a_multisite_system.html#setting_up_a_multisite_system__section_E3A44F85359046C7ADD12861D261637B]
> and [gfsh create
> gateway-receiver|http://geode.apache.org/docs/guide/13/tools_modules/gfsh/command-pages/create.html#topic_a4x_pb1_dk],
> we state that only one {{gateway-receiver}} is allowed per member. However,
> there is no enforcement of this rule within the code nor within the schema
> for the {{cache.xml}} file, so the user might end up having more than one
> {{gateway-receiver}} per host.
> It's unknown which {{gateway-receiver}} is going to be used after a restart,
> making it hard to configure firewall rules between clusters, if any. The
> following exception is also printed in the logs whenever we try to register
> (only the first one is succesfull) the MBean for the {{gateway-receiver}}:
> {noformat}
> [warning 2017/11/16 15:27:46.156 PST host1-server1 Processor1> tid=0x44] javax.management.InstanceAlreadyExistsException:
> GemFire:service=GatewayReceiver,type=Member,member=host1-server1
> org.apache.geode.management.ManagementException:
> javax.management.InstanceAlreadyExistsException:
> GemFire:service=GatewayReceiver,type=Member,member=host1-server1
> at
> org.apache.geode.management.internal.MBeanJMXAdapter.registerMBean(MBeanJMXAdapter.java:110)
> at
> org.apache.geode.management.internal.SystemManagementService.registerInternalMBean(SystemManagementService.java:368)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.createGatewayReceiverMBean(ManagementAdapter.java:471)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleGatewayReceiverStart(ManagementAdapter.java:493)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:134)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2175)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:562)
> at
> org.apache.geode.internal.cache.wan.GatewayReceiverImpl.start(GatewayReceiverImpl.java:194)
> at
> org.apache.geode.internal.cache.wan.GatewayReceiverFactoryImpl.create(GatewayReceiverFactoryImpl.java:141)
> at
> org.apache.geode.management.internal.cli.functions.GatewayReceiverCreateFunction.createGatewayReceiver(GatewayReceiverCreateFunction.java:164)
> at
> org.apache.geode.management.internal.cli.functions.GatewayReceiverCreateFunction.execute(GatewayReceiverCreateFunction.java:63)
> at
> org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:186)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:374)
> at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:440)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:668)
> at
> org.apache.geode.distributed.internal.DistributionManager$9$1.run(DistributionManager.java:1114)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: javax.management.InstanceAlreadyExistsException:
> GemFire:service=GatewayReceiver,type=Member,member=host1-server1
> at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:437)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerWithRepository(DefaultMBeanServerInterceptor.java:1898)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:966)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:900)
> at
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:324)
> at
>
[jira] [Closed] (GEODE-3338) Refactor CreateAndDestroyGatewaySenderCommandsDUnitTest.java to use test rules
[
https://issues.apache.org/jira/browse/GEODE-3338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-3338.
---
> Refactor CreateAndDestroyGatewaySenderCommandsDUnitTest.java to use test rules
> --
>
> Key: GEODE-3338
> URL: https://issues.apache.org/jira/browse/GEODE-3338
> Project: Geode
> Issue Type: Sub-task
> Components: tests
>Reporter: Patrick Rhomberg
>Assignee: Shelley Lynn Hughes-Godfrey
>Priority: Major
> Fix For: 1.4.0
>
>
> {{CreateAndDestroyGatewaySenderCommandsDUnitTest}} is using
> {{CliCommandTestBase}}, which is a deprecated class. It should be refactored
> to use more current test rules.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-3691) Create new geode-example about cache writers
[ https://issues.apache.org/jira/browse/GEODE-3691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3691. --- > Create new geode-example about cache writers > > > Key: GEODE-3691 > URL: https://issues.apache.org/jira/browse/GEODE-3691 > Project: Geode > Issue Type: New Feature > Components: examples >Reporter: Michael Dodge >Assignee: Michael Dodge >Priority: Major > Fix For: 1.4.0 > > > Create an example of a cache writer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3955) The gfsh 'describe region' command doesn't include asyncEventQueueIds or gatewaySenderIds
[
https://issues.apache.org/jira/browse/GEODE-3955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-3955.
---
> The gfsh 'describe region' command doesn't include asyncEventQueueIds or
> gatewaySenderIds
> -
>
> Key: GEODE-3955
> URL: https://issues.apache.org/jira/browse/GEODE-3955
> Project: Geode
> Issue Type: Improvement
> Components: management
>Reporter: Barry Oglesby
>Priority: Minor
> Fix For: 1.4.0
>
> Attachments: geode-3955.diff
>
>
> The {{constructor}} and {{getNonDefaultAttributes}} methods in
> {{org.apache.geode.management.internal.cli.domain.RegionAttributesInfo}}
> class would have to be modified to include the {{asyncEventQueueIds}} and
> {{gatewaySenderIds}}.
> I did a quick modification of this class (attached).
> With these changes, 'describe region' looks like:
> {noformat}
> gfsh>describe region --name=/data
> ..
> Name: data
> Data Policy : partition
> Hosting Members : ln-1
> Non-Default Attributes Shared By Hosting Members
> Type| Name | Value
> - | - | -
> Region| data-policy | PARTITION
> | async-event-queue-ids | db
> | size | 0
> | gateway-sender-ids| ny
> Partition | redundant-copies | 1
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-4020) Implement list jdbc-connection command
[
https://issues.apache.org/jira/browse/GEODE-4020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-4020.
---
> Implement list jdbc-connection command
> --
>
> Key: GEODE-4020
> URL: https://issues.apache.org/jira/browse/GEODE-4020
> Project: Geode
> Issue Type: Sub-task
> Components: docs, regions
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.4.0
>
>
> Need to be able to list all existing JDBC connections via GFSH.
> {noformat}
> NAME
> list jdbc-connection
> SYNOPSIS
> Display jdbc connections for all members.
> SYNTAX
> list jdbc-connection
> PARAMETERS
> none
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-4229) CI failure due to suspect string: "Locator socket was closed unexpectedly"
[
https://issues.apache.org/jira/browse/GEODE-4229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-4229.
---
> CI failure due to suspect string: "Locator socket was closed unexpectedly"
> --
>
> Key: GEODE-4229
> URL: https://issues.apache.org/jira/browse/GEODE-4229
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Bruce Schuchardt
>Priority: Major
> Fix For: 1.4.0
>
>
> This is a new error-level log message that was recently introduced
> {noformat}
> :geode-wan:distributedTest
> org.apache.geode.internal.cache.wan.serial.SerialWANPersistenceEnabledGatewaySenderDUnitTest
> > testPersistentReplicatedRegionWithGatewaySender_Restart 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 3971
> [error 2018/01/05 02:46:24.098 UTC localhost/127.0.0.1> tid=167] Locator socket was closed unexpectedly - server
> thread is exiting.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-3982) MemoryIndexStoreIterator should not call GemFireCacheImpl.getInstance
[ https://issues.apache.org/jira/browse/GEODE-3982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3982. --- > MemoryIndexStoreIterator should not call GemFireCacheImpl.getInstance > - > > Key: GEODE-3982 > URL: https://issues.apache.org/jira/browse/GEODE-3982 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Jason Huynh >Assignee: Jason Huynh >Priority: Major > Fix For: 1.4.0 > > > This call should be removed from the constructor and instead be passed in. > There is already a handle to the cache from the memory index store itself. > The current call can also lead to an NPE when the cache is closing and query > is executed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3895) Add Handshake/Message version byte
[ https://issues.apache.org/jira/browse/GEODE-3895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3895. --- > Add Handshake/Message version byte > -- > > Key: GEODE-3895 > URL: https://issues.apache.org/jira/browse/GEODE-3895 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Brian Baynes >Priority: Major > Fix For: 1.4.0 > > > Add an extra protocol version byte so that the first two bytes will > (initially) be 110 followed by 1. The '1' byte will be increased when the > HandshakeRequest or Message changes in such a way that we can't make the > handshake backward-compatible. > Ensure that clients on newer versions will have their connections terminated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3897) Geode should not use pauseTransaction when the thread will start a new transaction to register pdx type
[
https://issues.apache.org/jira/browse/GEODE-3897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-3897.
---
> Geode should not use pauseTransaction when the thread will start a new
> transaction to register pdx type
> ---
>
> Key: GEODE-3897
> URL: https://issues.apache.org/jira/browse/GEODE-3897
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Affects Versions: 1.4.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Fix For: 1.4.0
>
>
> This could occur when putting pdx into a partitioned region in a transaction.
> Here is a failed stack with a newly added unit test.
> {noformat}
> [vm0] [info 2017/10/23 16:46:20.857 PDT
> tid=19] Got result: EXCEPTION_OCCURRED
> [vm0] org.apache.geode.ToDataException: toData failed on PdxSerializable
> class org.apache.geode.pdx.SimpleClass
> [vm0] at
> org.apache.geode.internal.InternalDataSerializer.writePdx(InternalDataSerializer.java:3007)
> [vm0] at
> org.apache.geode.internal.InternalDataSerializer.basicWriteObject(InternalDataSerializer.java:2077)
> [vm0] at
> org.apache.geode.DataSerializer.writeObject(DataSerializer.java:2936)
> [vm0] at
> org.apache.geode.internal.tcp.MsgStreamer.writeAsSerializedByteArray(MsgStreamer.java:926)
> [vm0] at
> org.apache.geode.DataSerializer.writeObjectAsByteArray(DataSerializer.java:1302)
> [vm0] at
> org.apache.geode.internal.cache.DistributedCacheOperation.writeValue(DistributedCacheOperation.java:125)
> [vm0] at
> org.apache.geode.internal.cache.partitioned.PutMessage.toData(PutMessage.java:623)
> [vm0] at
> org.apache.geode.internal.InternalDataSerializer.invokeToData(InternalDataSerializer.java:2299)
> [vm0] at
> org.apache.geode.internal.InternalDataSerializer.writeDSFID(InternalDataSerializer.java:1406)
> [vm0] at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:232)
> [vm0] at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:377)
> [vm0] at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:237)
> [vm0] at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:603)
> [vm0] at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.directChannelSend(GMSMembershipManager.java:1714)
> [vm0] at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.send(GMSMembershipManager.java:1904)
> [vm0] at
> org.apache.geode.distributed.internal.DistributionChannel.send(DistributionChannel.java:82)
> [vm0] at
> org.apache.geode.distributed.internal.DistributionManager.sendOutgoing(DistributionManager.java:3464)
> [vm0] at
> org.apache.geode.distributed.internal.DistributionManager.sendMessage(DistributionManager.java:3501)
> [vm0] at
> org.apache.geode.distributed.internal.DistributionManager.putOutgoing(DistributionManager.java:1877)
> [vm0] at
> org.apache.geode.internal.cache.partitioned.PutMessage.send(PutMessage.java:386)
> [vm0] at
> org.apache.geode.internal.cache.PartitionedRegion.putRemotely(PartitionedRegion.java:3190)
> [vm0] at
> org.apache.geode.internal.cache.tx.PartitionedTXRegionStub.putEntry(PartitionedTXRegionStub.java:367)
> [vm0] at
> org.apache.geode.internal.cache.TXStateStub.putEntry(TXStateStub.java:525)
> [vm0] at
> org.apache.geode.internal.cache.TXStateProxyImpl.putEntry(TXStateProxyImpl.java:577)
> [vm0] at
> org.apache.geode.internal.cache.LocalRegion.basicPut(LocalRegion.java:5030)
> [vm0] at
> org.apache.geode.internal.cache.LocalRegion.validatedPut(LocalRegion.java:1574)
> [vm0] at
> org.apache.geode.internal.cache.LocalRegion.put(LocalRegion.java:1561)
> [vm0] at
> org.apache.geode.internal.cache.AbstractRegion.put(AbstractRegion.java:325)
> [vm0] at
> org.apache.geode.pdx.PdxSerializableDUnitTest.doSimplePut(PdxSerializableDUnitTest.java:433)
> [vm0] at
> org.apache.geode.pdx.PdxSerializableDUnitTest.lambda$5(PdxSerializableDUnitTest.java:113)
> [vm0] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> [vm0] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> [vm0] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm0] at java.lang.reflect.Method.invoke(Method.java:498)
> [vm0] at hydra.MethExecutor.executeObject(MethExecutor.java:245)
> [vm0] at
>
[jira] [Closed] (GEODE-2046) Tests should not use org.mockito.internal.stubbing.answers.CallsRealMethods
[
https://issues.apache.org/jira/browse/GEODE-2046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-2046.
---
> Tests should not use org.mockito.internal.stubbing.answers.CallsRealMethods
> ---
>
> Key: GEODE-2046
> URL: https://issues.apache.org/jira/browse/GEODE-2046
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.4.0
>
>
> CallsRealMethods is an internal class that should never be used in test code.
> Tests should instead use org.mockito.Mockito.CALLS_REAL_METHODS:
> import static org.mockito.Mockito.*;
> ...
> Foo foo = mock(Foo.class, CALLS_REAL_METHODS);
> when(foo.bar()).thenAnswer("bar");
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-3824) Implement create jdbc-connection command
[
https://issues.apache.org/jira/browse/GEODE-3824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-3824.
---
> Implement create jdbc-connection command
>
>
> Key: GEODE-3824
> URL: https://issues.apache.org/jira/browse/GEODE-3824
> Project: Geode
> Issue Type: Sub-task
> Components: docs, regions
>Reporter: Fred Krone
>Assignee: Nick Reich
>Priority: Major
> Fix For: 1.4.0
>
>
> Need to be able to configure establish a JDBC connection via GFSH and
> reference it when tying a region to a DB via PDX-JDBC.
> {noformat}
> NAME
> create jdbc-connection
> SYNOPSIS
> Create a connection for communicating with a database through JDBC.
> SYNTAX
> create jdbc-connection --name=value --url=value [--user=value]
> [--password=value] [--params=key:value[,key:value...]]
> PARAMETERS
> name
> Name of the connection to be created.
> Required: true
> url
> URL location for the database.
> Required: true
> user
> User name to use when connecting to database.
> Required: false
> password
> Password to use when connecting to database.
> Required: false
> params
> Additional parameters to use when connecting to database.
> Required: false
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-4009) Use connection pooling JDBC library for PDX-JDBC
[ https://issues.apache.org/jira/browse/GEODE-4009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-4009. --- > Use connection pooling JDBC library for PDX-JDBC > > > Key: GEODE-4009 > URL: https://issues.apache.org/jira/browse/GEODE-4009 > Project: Geode > Issue Type: Improvement > Components: regions >Reporter: Fred Krone >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.4.0 > > > We need a JDBC library for connection pooling, etc. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-2349) Region.values() doesn't work properly inside JTA
[
https://issues.apache.org/jira/browse/GEODE-2349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-2349.
---
> Region.values() doesn't work properly inside JTA
>
>
> Key: GEODE-2349
> URL: https://issues.apache.org/jira/browse/GEODE-2349
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Reporter: Vadim Lotarev
>Assignee: Eric Shu
>Priority: Major
> Fix For: 1.4.0
>
>
> I experienced rather strange error invoking Region.values() within JTA
> transaction: {{java.lang.IllegalStateException: The Region collection is not
> transactional but is being used in a transaction}}.
> Doing some investigation I think I understand what is the cause of this
> error. Everything works if {{Region.values()}} invoked alone in transaction
> but failed if you invoke, say, {{get()}} on another (or the same) region
> before starting iteration over the collection returned by {{values()}}. I
> think that the reason of this error is the absence of {{discoverJTA()}} in
> {{values()}} method. So, when {{values()}} invoked first time {{EntriesSet}}
> is created with {{myTX = null}} since no transaction is determined (as soon
> as {{discoverJTA()}} is not invoked). If you are iterating immediately
> everything works as soon as there are no transaction on a region still
> ({{EntriesSet.myTx = null && topRegion.isTX() = false}}). But as soon as you
> invoke {{get()}} (or any other method where {{discoverJTA()}} is invoked)
> than all regions became transactional and next execution of
> {{EntriesSet.iterator()}} failed ({{EntriesSet.myTx = null &&
> topRegion.isTX() = true}}).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-4298) ServerLauncher.waitOnServer has inadvertent public API change
[ https://issues.apache.org/jira/browse/GEODE-4298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-4298. --- > ServerLauncher.waitOnServer has inadvertent public API change > - > > Key: GEODE-4298 > URL: https://issues.apache.org/jira/browse/GEODE-4298 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Fix For: 1.4.0 > > > A public method was made package protected. This should be returned to > public until a major release, if at all. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3701) Improve docs on hash index performance
[ https://issues.apache.org/jira/browse/GEODE-3701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3701. --- > Improve docs on hash index performance > -- > > Key: GEODE-3701 > URL: https://issues.apache.org/jira/browse/GEODE-3701 > Project: Geode > Issue Type: Improvement >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Fix For: 1.3.0, 1.4.0 > > > Stronger language is warranted for hash indexes. > In a simple test, there was an order of magnitude difference in load and GII > performance between the two types of indexes. > Range: > Client: Loaded 2,000,000 entries in 20,487 ms > Server 1 Size: 1,272,322,680 bytes > Server 2: GIIed in 12,523 ms > Server 2 Size: 1,272,088,544 bytes > Hash: > Client: Loaded 2,000,000 entries in 257,016 ms > Server 1 Size: 1,228,010,280 bytes > Server 2: GIIed in 218,983 ms > Server 2 Size: 1,228,161,664 bytes > So, the difference in size was ~45MB, but the difference in time was an order > of magnitude. > Better wording suggested for file > developing/query_index/creating_hash_indexes.html: > Using hash index will degrade put performance and recovery time > substantially. If memory is not a concern, it is recommended that you use > range index. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-2567) gfsh destroy disk-store should be idempotent
[
https://issues.apache.org/jira/browse/GEODE-2567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-2567.
---
> gfsh destroy disk-store should be idempotent
>
>
> Key: GEODE-2567
> URL: https://issues.apache.org/jira/browse/GEODE-2567
> Project: Geode
> Issue Type: Sub-task
> Components: gfsh
>Reporter: Swapnil Bawaskar
>Priority: Major
> Fix For: 1.4.0
>
>
> Currently, gfsh {{destroy disk-store}} does *not* throw an error when run
> multiple times:
> {{{
> gfsh>destroy disk-store --name=foo
> Member | Result
> -- | ---
> serv1 | Disk store not found on this member
> serv2 | Disk store not found on this member
> }}}
> However, for a uniform user experience, it should. We should then add a
> {{--if-exists}} option to the command to make it idempotent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-4077) HASlowReceiverDUnitTest.testSlowClient fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-4077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-4077.
---
> HASlowReceiverDUnitTest.testSlowClient fails intermittently
> ---
>
> Key: GEODE-4077
> URL: https://issues.apache.org/jira/browse/GEODE-4077
> Project: Geode
> Issue Type: Bug
> Components: client queues
>Reporter: Dan Smith
>Assignee: Shelley Lynn Hughes-Godfrey
>Priority: Major
> Fix For: 1.4.0
>
>
> This test is failing intermittently in precheckin with revision
> fa2687c76a5fd93d968449a40450c28e8814ee58.
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.ha.HASlowReceiverDUnitTest$$Lambda$355/783772242.run
> in VM 3 running on Host fbaa7686d027 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:393)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:363)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:308)
> at
> org.apache.geode.internal.cache.ha.HASlowReceiverDUnitTest.testSlowClient(HASlowReceiverDUnitTest.java:252)
> 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.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 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.GeneratedMethodAccessor341.invoke(Unknown Source)
> 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.GeneratedMethodAccessor340.invoke(Unknown Source)
> 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
>
[jira] [Closed] (GEODE-4163) clean up DistributionManager code
[ https://issues.apache.org/jira/browse/GEODE-4163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-4163. --- > clean up DistributionManager code > - > > Key: GEODE-4163 > URL: https://issues.apache.org/jira/browse/GEODE-4163 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Bruce Schuchardt >Priority: Major > Fix For: 1.4.0 > > > DistributionManager has a large number of methods that are marked public but > should be private. > It has a lot of methods and instance variables that aren't used and a lot of > commented-out code. > There are also other classes that cast a DM to DistributionManager in order > to use methods marked public instead of adding those methods to the DM > interface. > DistributionManager also has instance variable sprinkled throughout the file > and lots of raw, untyped collections. > There are also a lot of methods that have InternalDistributedMember in their > signatures that were extracted into the DM interface. These should be > changed to DistributedMember, the interface that most of our code should use. > All of these problems should be fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3837) MultiVMRegionTestCase.testOrderedUpdates should be fixed and reenabled
[ https://issues.apache.org/jira/browse/GEODE-3837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3837. --- > MultiVMRegionTestCase.testOrderedUpdates should be fixed and reenabled > -- > > Key: GEODE-3837 > URL: https://issues.apache.org/jira/browse/GEODE-3837 > Project: Geode > Issue Type: Test > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Fix For: 1.4.0 > > > MultiVMRegionTestCase.testOrderedUpdates is currently disabled with @Ignore. > According to the comment, it's been disabled since 2004. The test should be > fixed and reenabled or simply deleted if it's no longer relevant. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4080) Improve JSON encoding for new protocol
[
https://issues.apache.org/jira/browse/GEODE-4080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-4080.
---
> Improve JSON encoding for new protocol
> --
>
> Key: GEODE-4080
> URL: https://issues.apache.org/jira/browse/GEODE-4080
> Project: Geode
> Issue Type: Improvement
> Components: client/server
>Reporter: Galen O'Sullivan
>Assignee: Galen O'Sullivan
>Priority: Major
> Fix For: 1.4.0
>
>
> One of the encoding types in the new protobuf protocol is called
> {{CustomEncodedValue}}. However, users aren't really free to encode their own
> types. Also, packing JSON into a byte array is going to be harder for users
> than just sending ti as a string. Let's make the JSON type a string and put
> the custom value type in later when we actually have support for custom
> encoding.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-2263) CliUtil.getRegionAssociatedMembers()'s returnAll parameter is not used
[ https://issues.apache.org/jira/browse/GEODE-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-2263. --- > CliUtil.getRegionAssociatedMembers()'s returnAll parameter is not used > -- > > Key: GEODE-2263 > URL: https://issues.apache.org/jira/browse/GEODE-2263 > Project: Geode > Issue Type: Bug >Reporter: xiaojian zhou >Priority: Major > Fix For: 1.4.0 > > > And DataCommands has a same name method which did use returnAll parameter. I > think the DataCommands's one should be moved to replace the CliUtil's. We > should not have 2 methods doing the same thing in 2 different class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3963) DM.getCache is not thread safe
[ https://issues.apache.org/jira/browse/GEODE-3963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3963. --- > DM.getCache is not thread safe > -- > > Key: GEODE-3963 > URL: https://issues.apache.org/jira/browse/GEODE-3963 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.4.0 > > > The new DM.getCache method is not thread safe. > The cache is stored in a non-volatile instance variable so reads from other > threads may not see a write. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4109) if the experimental eviction code is being used then a log message should say so
[ https://issues.apache.org/jira/browse/GEODE-4109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-4109. --- > if the experimental eviction code is being used then a log message should say > so > > > Key: GEODE-4109 > URL: https://issues.apache.org/jira/browse/GEODE-4109 > Project: Geode > Issue Type: Sub-task > Components: eviction >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.4.0 > > > If the new experimental eviction code is configured, then a log message > should say so. > This will help diagnose issues caused by using the experimental feature. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-1910) revise membership properties in internal/cache/properties.html
[ https://issues.apache.org/jira/browse/GEODE-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-1910. --- > revise membership properties in internal/cache/properties.html > -- > > Key: GEODE-1910 > URL: https://issues.apache.org/jira/browse/GEODE-1910 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Bruce Schuchardt >Assignee: Joey McAllister >Priority: Major > Fix For: 1.4.0 > > > The properties.html file has a number of old properties refering to > com.gemstone.org.jgroups. These need to be removed and the new GMS > properties should be added in their place. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3823) Implement CacheLoader for JDBC to PDX
[ https://issues.apache.org/jira/browse/GEODE-3823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3823. --- > Implement CacheLoader for JDBC to PDX > - > > Key: GEODE-3823 > URL: https://issues.apache.org/jira/browse/GEODE-3823 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Fred Krone >Assignee: Kirk Lund >Priority: Major > Fix For: 1.4.0 > > > This is for a 'read through' to the DB scenario when the entry is not found > in a Region. This implementation should take a result set and convert to PDX > for the cache. > Make a SQL statement to query by the key provided. dbName must match the > Region name. > Check each ResultSet field for type and convert. Create a PDXInstance insert > values. Region can (should?) have its type set so we'll know what the type > is. > > If the value is not in the cache it should take configured JDBC credentials > and connect to DB > Should log any connection error and retry x amount of times > On connect should execute query using the provided key as UID > On successful query should create PDX object, map JDBC values to PDX object, > put PDX object in the cache, return value > Should only return one value -- multiple values should be logged and error > JDBC execution errors should be logged -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4022) Implement destroy jdbc-connection command
[
https://issues.apache.org/jira/browse/GEODE-4022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-4022.
---
> Implement destroy jdbc-connection command
> -
>
> Key: GEODE-4022
> URL: https://issues.apache.org/jira/browse/GEODE-4022
> Project: Geode
> Issue Type: Sub-task
> Components: docs, regions
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.4.0
>
>
> Need to be able to destroy an existing JDBC connection via GFSH.
> {noformat}
> NAME
> destroy jdbc-connection
> SYNOPSIS
> Destroy/Remove the specified jdbc connection.
> SYNTAX
> destroy jdbc-connection --name=value
> PARAMETERS
> name
> Name of the jdbc connection to be destroyed.
> Required: true
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-4116) Can't get PDX objects using the new protocol
[
https://issues.apache.org/jira/browse/GEODE-4116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-4116.
---
> Can't get PDX objects using the new protocol
>
>
> Key: GEODE-4116
> URL: https://issues.apache.org/jira/browse/GEODE-4116
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Dan Smith
>Priority: Major
> Fix For: 1.4.0
>
> Attachments: pdx_get_failure.diff
>
>
> The new client protocol doesn't correctly support PDX objects. The
> GetRequestOperationHandler directly calls region.get, which will
> *deserialize* the value stored in the region. The operation handler is
> expecting to get a PdxInstance back, but that will only happen if the cache
> has read-serialized set to true.
> I've attached a unit test that demonstrates this issue. If a region contains
> PDX objects and read-serialized is set to false (the default), the new
> protocol will throw exceptions if you try to get a value.
> {noformat}
> [error 2017/12/18 15:00:23.302 PST
> tid=51] Received Get request with unsupported encoding: {}
> org.apache.geode.internal.protocol.serialization.exception.UnsupportedEncodingTypeException:
> We cannot translate: class
> org.apache.geode.internal.protocol.protobuf.v1.acceptance.CacheOperationsJUnitTest$TestPdxObject
> into a specific Protobuf Encoding
> at
> org.apache.geode.internal.protocol.protobuf.v1.EncodingTypeTranslator.getEncodingTypeForObject(EncodingTypeTranslator.java:63)
> at
> org.apache.geode.internal.protocol.protobuf.v1.utilities.ProtobufUtilities.createEncodedValue(ProtobufUtilities.java:64)
> at
> org.apache.geode.internal.protocol.protobuf.v1.operations.GetRequestOperationHandler.process(GetRequestOperationHandler.java:66)
> at
> org.apache.geode.internal.protocol.protobuf.v1.operations.GetRequestOperationHandler.process(GetRequestOperationHandler.java:40)
> at
> org.apache.geode.internal.protocol.protobuf.v1.ProtobufOpsProcessor.processOperation(ProtobufOpsProcessor.java:83)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-4370) jar deployment should not require additional ports to be opened
[ https://issues.apache.org/jira/browse/GEODE-4370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-4370. --- > jar deployment should not require additional ports to be opened > --- > > Key: GEODE-4370 > URL: https://issues.apache.org/jira/browse/GEODE-4370 > Project: Geode > Issue Type: Bug > Components: gfsh, jmx >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.4.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > The way we're currently using the new rmi-io library ends up opening > ephemeral ports on the locator/manager. We should be able to piggy-back off > the existing default JMX/RMI port. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-1333) ClusterConfigurationDUnitTest.testDestroyExtensions failed
[ https://issues.apache.org/jira/browse/GEODE-1333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-1333. --- > ClusterConfigurationDUnitTest.testDestroyExtensions failed > -- > > Key: GEODE-1333 > URL: https://issues.apache.org/jira/browse/GEODE-1333 > Project: Geode > Issue Type: Bug > Components: configuration, gfsh >Reporter: Hitesh Khamesra >Assignee: Shelley Lynn Hughes-Godfrey >Priority: Major > Labels: ClusterConfig, CreateRegionCommand, Flaky, gfsh > Fix For: 1.4.0 > > > java.lang.AssertionError: expected: but was: > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:118) > at org.junit.Assert.assertEquals(Assert.java:144) > at > com.gemstone.gemfire.management.internal.configuration.ClusterConfigurationDUnitTest.executeAndVerifyCommand(ClusterConfigurationDUnitTest.java:853) > at > com.gemstone.gemfire.management.internal.configuration.ClusterConfigurationDUnitTest.createRegion(ClusterConfigurationDUnitTest.java:744) > at > com.gemstone.gemfire.management.internal.configuration.ClusterConfigurationDUnitTest.testDestroyExtensions(ClusterConfigurationDUnitTest.java:335) > 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:497) > 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.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > 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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50) > 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:497) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) > at > org.gradle.messaging.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:106) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at >
[jira] [Closed] (GEODE-3882) ClusterConfiguration needs to support GatewayReceiver hostnameForSenders
[ https://issues.apache.org/jira/browse/GEODE-3882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3882. --- > ClusterConfiguration needs to support GatewayReceiver hostnameForSenders > > > Key: GEODE-3882 > URL: https://issues.apache.org/jira/browse/GEODE-3882 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.3.0, 1.4.0 >Reporter: Shelley Lynn Hughes-Godfrey >Assignee: Shelley Lynn Hughes-Godfrey >Priority: Major > Fix For: 1.4.0 > > > Currently the WANClusterConfigurationDUnitTest just verifies that the cluster > configuration includes a gateway receiver, but does not verify any of the > GatewayReceiver attributes. While improving this test (to verify the > GatewayReceiver attributes), I found that the hostnameForSenders is not saved > in ClusterConfiguration as there was no support for this in the > CacheXmlGenerator. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3365) Refactor PauseGatewaySenderCommandDUnitTest to use test rules
[
https://issues.apache.org/jira/browse/GEODE-3365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-3365.
---
> Refactor PauseGatewaySenderCommandDUnitTest to use test rules
> -
>
> Key: GEODE-3365
> URL: https://issues.apache.org/jira/browse/GEODE-3365
> Project: Geode
> Issue Type: Sub-task
> Components: tests
>Reporter: Emily Yeh
>Assignee: Shelley Lynn Hughes-Godfrey
>Priority: Major
> Fix For: 1.4.0
>
>
> {{PauseGatewaySenderCommandDUnitTest}} is using {{CliCommandTestBase}}, which
> is a deprecated class. It should be refactored to use more current test rules.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-3026) If a region defining lucene indexes cannot be created, it leaves an AEQ behind
[
https://issues.apache.org/jira/browse/GEODE-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-3026.
---
> If a region defining lucene indexes cannot be created, it leaves an AEQ behind
> --
>
> Key: GEODE-3026
> URL: https://issues.apache.org/jira/browse/GEODE-3026
> Project: Geode
> Issue Type: Bug
> Components: docs, lucene
>Reporter: Barry Oglesby
>Priority: Major
> Fix For: 1.4.0
>
>
> This is ok if the member is started with xml, because it will fail to start,
> but if the region is attempted to be created using java API or gfsh, then the
> server will be in an inconsistent state.
> It will have defined the AEQ like:
> {noformat}
> [info 2017/06/02 13:02:15.047 PDT tid=0x1] Started
> ParallelGatewaySender{id=AsyncEventQueue_full_index#_data,remoteDsId=-1,isRunning
> =true}
> {noformat}
> But will fail to create the region (in this case I created the region with a
> different number of buckets):
> {noformat}
> [warning 2017/06/02 13:02:15.126 PDT tid=0x1] Initialization failed
> for Region /data
> java.lang.IllegalStateException: The total number of buckets found in
> PartitionAttributes ( 16 ) is incompatible with the total number of buckets
> used by other distributed members. Set the number of buckets to 66
> at
> org.apache.geode.internal.cache.PartitionRegionConfigValidator.validatePartitionAttrsFromPRConfig(PartitionRegionConfigValidator.java:102)
> at
> org.apache.geode.internal.cache.PartitionedRegion.registerPartitionedRegion(PartitionedRegion.java:1337)
> at
> org.apache.geode.internal.cache.PartitionedRegion.initPRInternals(PartitionedRegion.java:987)
> at
> org.apache.geode.internal.cache.PartitionedRegion.initialize(PartitionedRegion.java:1157)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3104)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:3004)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:2992)
> at org.apache.geode.cache.RegionFactory.create(RegionFactory.java:758)
> at TestServer.createIndexAndRegionUsingAPI(TestServer.java:104)
> at TestServer.main(TestServer.java:47)
> {noformat}
> So, at the end of the GemFireCacheImpl.createVMRegion call, the AEQ exists
> but the region doesn't.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-3880) Typo in Java doc for PersistentMemberManager.addRevocationListener
[ https://issues.apache.org/jira/browse/GEODE-3880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3880. --- > Typo in Java doc for PersistentMemberManager.addRevocationListener > -- > > Key: GEODE-3880 > URL: https://issues.apache.org/jira/browse/GEODE-3880 > Project: Geode > Issue Type: Bug > Components: persistence >Reporter: Srikanth Manvi >Assignee: Srikanth Manvi >Priority: Trivial > Fix For: 1.4.0 > > > The java doc for the method PersistentMemberManager.addRevocationListener has > couple of typos. > revokation to be spelled as revocation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4070) SnapshotPerformanceDUnitTest is dirtying the environment for other tests
[
https://issues.apache.org/jira/browse/GEODE-4070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-4070.
---
> SnapshotPerformanceDUnitTest is dirtying the environment for other tests
>
>
> Key: GEODE-4070
> URL: https://issues.apache.org/jira/browse/GEODE-4070
> Project: Geode
> Issue Type: Bug
> Components: snapshot
>Reporter: Jens Deppe
>Priority: Major
> Fix For: 1.4.0
>
>
> In particular, when this test runs before
> {{ClusterConfigDistributionDUnitTest}} then that test fails.
> After consulting with the storage team I'm disabling this test for now (it
> also appears to not really provide any value as it does not assert anything).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-3947) geode-dependency.jar does not have all the dependencies needed for deserializing custom object
[ https://issues.apache.org/jira/browse/GEODE-3947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3947. --- > geode-dependency.jar does not have all the dependencies needed for > deserializing custom object > -- > > Key: GEODE-3947 > URL: https://issues.apache.org/jira/browse/GEODE-3947 > Project: Geode > Issue Type: Bug >Affects Versions: 1.3.0 >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Blocker > Fix For: 1.4.0 > > > JsonUtil recently added a dependency to common-beanutil, we need to include > that in geode-dependency.jar -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3783) Implement AsyncEventListener for PDX to JDBC
[ https://issues.apache.org/jira/browse/GEODE-3783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3783. --- > Implement AsyncEventListener for PDX to JDBC > > > Key: GEODE-3783 > URL: https://issues.apache.org/jira/browse/GEODE-3783 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Fred Krone >Assignee: Kirk Lund >Priority: Major > Fix For: 1.4.0 > > > This is to implement an AsyncEventListener for a write behind caching > scenario. Something was put or updated in the Region and it should be > persisted into a DB asynchronously. > Should take the JDBC configuration from cache.xml and connect to the DB > Should log a DB connection failure and retry x number of times > Should take the PDX object and convert it to a JDBC statement for DB > update/insert > Should retry on a fail > Should log all failed DB attempts -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3683) CacheConnectionTimeoutJUnitTest failing intermittently in CI.
[ https://issues.apache.org/jira/browse/GEODE-3683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3683. --- > CacheConnectionTimeoutJUnitTest failing intermittently in CI. > - > > Key: GEODE-3683 > URL: https://issues.apache.org/jira/browse/GEODE-3683 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Galen O'Sullivan >Assignee: Bruce Schuchardt >Priority: Major > Fix For: 1.4.0 > > > The `testUnresponsiveClientsGetDisconnected` test is failing. I think this is > because the Awaitility condition is broken. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3913) CI Failure: org.apache.geode.internal.cache.ClientServerTransactionCCEDUnitTest > testRollbackWithPRAccessor FAILED
[
https://issues.apache.org/jira/browse/GEODE-3913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-3913.
---
> CI Failure:
> org.apache.geode.internal.cache.ClientServerTransactionCCEDUnitTest >
> testRollbackWithPRAccessor FAILED
> ---
>
> Key: GEODE-3913
> URL: https://issues.apache.org/jira/browse/GEODE-3913
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Affects Versions: 1.4.0
>Reporter: Eric Shu
>Assignee: Eric Shu
>Priority: Major
> Fix For: 1.4.0
>
>
> {noformat}
> org.apache.geode.internal.cache.ClientServerTransactionCCEDUnitTest >
> testRollbackWithPRAccessor FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.ClientServerTransactionDUnitTest$61.call in
> VM 2 running on Host 38fc14dc5fe4 with 4 VMs
> Caused by:
> java.lang.IllegalStateException: Thread does not have an active
> transaction
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.RemoteTransactionDUnitTest$2.call in VM 0
> running on Host 38fc14dc5fe4 with 4 VMs
> Caused by:
> java.lang.AssertionError: Event never occurred after 3 ms:
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-4011) ConcurrentDeployDUnitTest is polluting test VMs
[ https://issues.apache.org/jira/browse/GEODE-4011?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-4011. --- > ConcurrentDeployDUnitTest is polluting test VMs > --- > > Key: GEODE-4011 > URL: https://issues.apache.org/jira/browse/GEODE-4011 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Jens Deppe >Assignee: Jens Deppe >Priority: Major > Fix For: 1.4.0 > > > This test launches gfsh from within 3 separate VMs. gfsh does some logger > manipulation which results in stdout being redirected. Subsequent tests then > may fail if they produce 'scary' suspect messages in the logs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3440) Create new geode-example about using functions
[ https://issues.apache.org/jira/browse/GEODE-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3440. --- > Create new geode-example about using functions > -- > > Key: GEODE-3440 > URL: https://issues.apache.org/jira/browse/GEODE-3440 > Project: Geode > Issue Type: New Feature > Components: examples >Reporter: Michael Dodge >Assignee: Michael Dodge >Priority: Major > Fix For: 1.4.0 > > > The more examples, the better. . . > Create an example that demonstrates how to use a function. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4146) geode-connectors restarting server in gfsh throws exception with jdbc mapping config
[
https://issues.apache.org/jira/browse/GEODE-4146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-4146.
---
> geode-connectors restarting server in gfsh throws exception with jdbc mapping
> config
>
>
> Key: GEODE-4146
> URL: https://issues.apache.org/jira/browse/GEODE-4146
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Anilkumar Gingade
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.4.0
>
>
> Restarting a server with previously configured jdbc connection and region
> mapping throws exception and exits the server start.
> Exception with jdbc config:
> Exception in thread "main" org.apache.geode.InternalGemFireException:
> org.apache.geode.connectors.jdbc.internal.ConnectionConfigExistsException:
> {noformat}
> ConnectionConfiguration derbyDB exists
> at
> org.apache.geode.connectors.jdbc.internal.xml.JdbcServiceConfiguration.createConnectionConfig(JdbcServiceConfiguration.java:69)
> at
> org.apache.geode.connectors.jdbc.internal.xml.JdbcServiceConfiguration.lambda$onCreate$0(JdbcServiceConfiguration.java:60)
> {noformat}
> Exception with Region Mapping:
> {noformat}
> The Cache Server process terminated unexpectedly with exit status 1. Please
> refer to the log file in /Users/agingade/gem/gemfire/s1 for full details.
> Exception in thread "main" org.apache.geode.InternalGemFireException:
> org.apache.geode.connectors.jdbc.internal.RegionMappingExistsException:
> RegionMapping for region employee exists
> at
> org.apache.geode.connectors.jdbc.internal.xml.JdbcServiceConfiguration.createRegionMapping(JdbcServiceConfiguration.java:78)
> at
> org.apache.geode.connectors.jdbc.internal.xml.JdbcServiceConfiguration.lambda$onCreate$1(JdbcServiceConfiguration.java:61)
> at java.util.ArrayList.forEach(ArrayList.java:1249)
> at
> org.apache.geode.connectors.jdbc.internal.xml.JdbcServiceConfiguration.onCreate(JdbcServiceConfiguration.java:61)
> at
> org.apache.geode.internal.cache.extension.SimpleExtensionPoint.fireCreate(SimpleExtensionPoint.java:83)
> at
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:557)
> at
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:338)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4318)
> at
> org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:141)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1206)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:778)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:764)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:175)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:222)
> at
> org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
> at
> org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:844)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-4084) rename handshake.proto
[ https://issues.apache.org/jira/browse/GEODE-4084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-4084. --- > rename handshake.proto > -- > > Key: GEODE-4084 > URL: https://issues.apache.org/jira/browse/GEODE-4084 > Project: Geode > Issue Type: Task > Components: client/server >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt >Priority: Major > Fix For: 1.4.0 > > > We envision having another handshake between client & server in the future. > Since the current Handshake is going to remain fixed in content for the > foreseeable future we should rename it to something more like > "NewConnectionVersion" or something. Then we can introduce a Handshake with > more information exchange in the future. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4170) Make index docs easier to locate
[ https://issues.apache.org/jira/browse/GEODE-4170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-4170. --- > Make index docs easier to locate > > > Key: GEODE-4170 > URL: https://issues.apache.org/jira/browse/GEODE-4170 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Karen Smoler Miller >Assignee: Karen Smoler Miller >Priority: Major > Fix For: 1.4.0 > > > The sections on indexing are buried under the Querying section called > Advanced Querying. They shouldn't be. > Promote the indexing section to a first class subsection of Querying. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3888) Add lucene queries with the java API to the lucene example
[ https://issues.apache.org/jira/browse/GEODE-3888?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3888. --- > Add lucene queries with the java API to the lucene example > -- > > Key: GEODE-3888 > URL: https://issues.apache.org/jira/browse/GEODE-3888 > Project: Geode > Issue Type: Bug > Components: examples >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Fix For: 1.4.0 > > > The lucene example does not actually demonstrate the java API. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3798) Move logic for information in restore script to own class
[ https://issues.apache.org/jira/browse/GEODE-3798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3798. --- > Move logic for information in restore script to own class > - > > Key: GEODE-3798 > URL: https://issues.apache.org/jira/browse/GEODE-3798 > Project: Geode > Issue Type: Sub-task > Components: persistence >Reporter: Nick Reich >Assignee: Nick Reich >Priority: Major > Fix For: 1.4.0 > > > Currently, the BackupManager contains all the logic for what files need to be > included in the backup script. This logic should be moved out into its own > class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3598) refactor org.apache.geode.internal.cache.DestroyRegionOperation.DestroyRegionMessage.getRegionFromPath(InternalDistributedSystem, String) to not call CacheFactory.getinsta
[ https://issues.apache.org/jira/browse/GEODE-3598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3598. --- > refactor > org.apache.geode.internal.cache.DestroyRegionOperation.DestroyRegionMessage.getRegionFromPath(InternalDistributedSystem, > String) to not call CacheFactory.getinstance > -- > > Key: GEODE-3598 > URL: https://issues.apache.org/jira/browse/GEODE-3598 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.4.0 > > > DestroyRegionOperation.DestroyRegionMessage.getRegionFromPath(InternalDistributedSystem, > String) should be changed to call "dm.getCache" instead of > CacheFactory.getInstance. > Note that it should also be changed to take a DM instead of > InternalDistributedSystem since the only caller currently has the dm and this > code wants that instead of the InternalDistributedSystem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4034) CreateGatewaySender command does not report errors correctly
[
https://issues.apache.org/jira/browse/GEODE-4034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-4034.
---
> CreateGatewaySender command does not report errors correctly
>
>
> Key: GEODE-4034
> URL: https://issues.apache.org/jira/browse/GEODE-4034
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Jinmei Liao
>Priority: Major
> Fix For: 1.4.0
>
>
> For example, trying to create a gateway sender when no remote distributed
> system is available produces the following:
> {noformat}
> Command result for --remote-distributed-system-id=1>:
> Member | Status
> -- |
> server | ERROR: WAN service is not available.
> {noformat}
> However, the result code from gfsh is still SUCCESS.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-3827) SecurityManager is leaked from one Cache to another
[
https://issues.apache.org/jira/browse/GEODE-3827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-3827.
---
> SecurityManager is leaked from one Cache to another
> ---
>
> Key: GEODE-3827
> URL: https://issues.apache.org/jira/browse/GEODE-3827
> Project: Geode
> Issue Type: Bug
> Components: configuration, security
>Reporter: Galen O'Sullivan
>Assignee: Jared Stewart
>Priority: Major
> Fix For: 1.4.0
>
>
> After creating and closing Cache, the SecurityManager is visible to the next
> Cache created. This only happens if CacheServer.setSecurityManager is called,
> not if the class is specified via property. This is causing failure of some
> integration tests we'd like to add.
> I've created a minimal working example, also visible on branch
> {{SecurityManager-integration-test}} of https://github.com/galen-pivotal/geode
> {code}
> package org.apache.geode.security;
> import static org.apache.geode.distributed.ConfigurationProperties.LOCATORS;
> import static org.apache.geode.distributed.ConfigurationProperties.MCAST_PORT;
> import static
> org.apache.geode.distributed.ConfigurationProperties.SECURITY_MANAGER;
> import static org.assertj.core.api.Assertions.assertThat;
> import java.util.Properties;
> import org.junit.Test;
> import org.apache.geode.cache.CacheFactory;
> import org.apache.geode.examples.SimpleSecurityManager;
> import org.apache.geode.internal.cache.InternalCache;
> import org.apache.geode.internal.security.SecurityService;
> /**
> * This test verifies that when a SecurityManager is set, it does not persist
> between Cache
> * creations.
> *
> * We had seen this issue, and it broke integration tests.
> */
> public class SecurityManagerPersistenceIntegrationTest {
> private static final Properties defaultProperties;
> static {
> Properties properties = new Properties();
> properties.setProperty(MCAST_PORT, "0");
> properties.setProperty(LOCATORS, "");
> defaultProperties = properties;
> }
> @Test
> public void doesNotPersistWhenSetViaCacheFactoryJavaApi() {
> CacheFactory firstCacheFactory = new CacheFactory(new
> Properties(defaultProperties));
> SecurityManager securityManager = new SimpleSecurityManager();
> firstCacheFactory.setSecurityManager(securityManager);
> InternalCache firstCache = (InternalCache) firstCacheFactory.create();
> firstCache.close();
> CacheFactory cacheFactory = new CacheFactory(new
> Properties(defaultProperties));
> try (InternalCache cache = (InternalCache) cacheFactory.create()) {
> assertCacheHasNoSecurity(cache);
> }
> }
> @Test
> public void doesNotPersistWhenSetWithProperty() {
> Properties properties = new Properties(defaultProperties);
> properties.setProperty(SECURITY_MANAGER,
> SimpleSecurityManager.class.getName());
> CacheFactory firstCacheFactory = new CacheFactory(properties);
> InternalCache firstCache = (InternalCache) firstCacheFactory.create();
> firstCache.close();
> // Make sure we're using a fresh CacheFactory, so the test is valid.
> CacheFactory cacheFactory = new CacheFactory(new
> Properties(defaultProperties));
> try (InternalCache cache = (InternalCache) cacheFactory.create()) {
> assertCacheHasNoSecurity(cache);
> }
> }
> private void assertCacheHasNoSecurity(InternalCache cache) {
> SecurityService securityService = cache.getSecurityService();
> assertThat(securityService.isIntegratedSecurity()).isFalse();
> assertThat(securityService.isClientSecurityRequired()).isFalse();
> assertThat(securityService.isPeerSecurityRequired()).isFalse();
> // We expect null if it's not set, but there could be a default security
> manager if
> // implementation details change.
> if (securityService.getSecurityManager() != null) {
> assertThat(securityService.getSecurityManager())
> .describedAs("Security manager is not the same as the previously
> existing Cache")
> .isNotInstanceOf(SpySecurityManager.class);
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-4185) Create http endpoint that contains the SHA that most recently passed concourse CI
[ https://issues.apache.org/jira/browse/GEODE-4185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-4185. --- > Create http endpoint that contains the SHA that most recently passed > concourse CI > - > > Key: GEODE-4185 > URL: https://issues.apache.org/jira/browse/GEODE-4185 > Project: Geode > Issue Type: Task > Components: ci >Reporter: Sean Goller >Priority: Major > Fix For: 1.4.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3606) LuceneSerializer should take a LuceneIndex as a parameter
[
https://issues.apache.org/jira/browse/GEODE-3606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-3606.
---
> LuceneSerializer should take a LuceneIndex as a parameter
> -
>
> Key: GEODE-3606
> URL: https://issues.apache.org/jira/browse/GEODE-3606
> Project: Geode
> Issue Type: Sub-task
> Components: lucene
>Reporter: Dan Smith
>Priority: Major
> Fix For: 1.4.0
>
>
> The LuceneSerializer API is currently specified as
> {code}
> LuceneSerializer {
> Collection toDocuments(Object value);
> }
> {code}
> Unfortunately, that means the serializer doesn't have access to the list of
> fields and analyzers configured on the index. We should change the API to be
> {code}
> LuceneSerializer {
> Collection toDocuments(LuceneIndex index, Object value);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-3599) refactor Message classes process methods to not call CacheFactory.getInstance
[ https://issues.apache.org/jira/browse/GEODE-3599?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3599. --- > refactor Message classes process methods to not call CacheFactory.getInstance > - > > Key: GEODE-3599 > URL: https://issues.apache.org/jira/browse/GEODE-3599 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Fix For: 1.4.0 > > > The following message classes all call CacheFactory.getInstance from their > process methods but should instead call "dm.getCache": > org.apache.geode.internal.cache.CreateRegionProcessor.CreateRegionMessage.process(DistributionManager) > org.apache.geode.internal.cache.persistence.MembershipFlushRequest.process(DistributionManager) > org.apache.geode.internal.cache.persistence.MembershipViewRequest.process(DistributionManager) > org.apache.geode.internal.cache.persistence.PersistentStateQueryMessage.process(DistributionManager) > org.apache.geode.internal.cache.persistence.PrepareNewPersistentMemberMessage.process(DistributionManager) > org.apache.geode.internal.cache.persistence.RemovePersistentMemberMessage.process(DistributionManager) > org.apache.geode.internal.cache.SearchLoadAndWriteProcessor.NetWriteRequestMessage.process(DistributionManager) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3894) Create HandshakeRequest
[ https://issues.apache.org/jira/browse/GEODE-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3894. --- > Create HandshakeRequest > --- > > Key: GEODE-3894 > URL: https://issues.apache.org/jira/browse/GEODE-3894 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Brian Baynes >Priority: Major > Fix For: 1.4.0 > > > Make Handshake a HandshakeRequest that is contained in a Message the same way > other requests are handled. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3789) Create an example to be used for training and documentation using new flattening LuceneSerializer
[ https://issues.apache.org/jira/browse/GEODE-3789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3789. --- > Create an example to be used for training and documentation using new > flattening LuceneSerializer > - > > Key: GEODE-3789 > URL: https://issues.apache.org/jira/browse/GEODE-3789 > Project: Geode > Issue Type: Sub-task > Components: docs, lucene >Reporter: Diane Hardman >Priority: Major > Fix For: 1.4.0 > > > For documentation and training purposes we need an example of how to use the > new Lucene index API with the flattening LuceneSerializer. Also the new > serializer can be used as an example to anyone wanting to create a customer > serializer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4047) User Guide: Update Lucene docs to include nested objects
[ https://issues.apache.org/jira/browse/GEODE-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-4047. --- > User Guide: Update Lucene docs to include nested objects > > > Key: GEODE-4047 > URL: https://issues.apache.org/jira/browse/GEODE-4047 > Project: Geode > Issue Type: New Feature > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Fix For: 1.4.0 > > > GEODE-3239 added support for nested objects as proposed in this wiki page: > https://cwiki.apache.org/confluence/display/GEODE/Lucene+Text+Search+on+Nested+Object > This needs to be added to the User Guide. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3907) Create an example of using the LuceneSerializer for spatial queries
[ https://issues.apache.org/jira/browse/GEODE-3907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3907. --- > Create an example of using the LuceneSerializer for spatial queries > --- > > Key: GEODE-3907 > URL: https://issues.apache.org/jira/browse/GEODE-3907 > Project: Geode > Issue Type: Sub-task > Components: docs, lucene >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Fix For: 1.4.0 > > > It would be nice to have an example that shows how to use the new > LuceneSerializer API to customize how objects are written to the lucene > index. A good example would be using the serializer to enable spatial > indexing and querying using the lucene spatial APIs. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4137) Skipped DistributedTest CacheServerSSLConnectionDUnitTest fails with NoAvailableServersException
[
https://issues.apache.org/jira/browse/GEODE-4137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-4137.
---
> Skipped DistributedTest CacheServerSSLConnectionDUnitTest fails with
> NoAvailableServersException
>
>
> Key: GEODE-4137
> URL: https://issues.apache.org/jira/browse/GEODE-4137
> Project: Geode
> Issue Type: Sub-task
> Components: client/server
>Reporter: Patrick Rhomberg
>Priority: Major
> Fix For: 1.4.0
>
>
> Test method {{testNonSSLClient}} fails in both parameter cases with
> {{java.lang.AssertionError: Unexpected Exception:
> org.apache.geode.cache.client.NoAvailableServersException expected: class
> org.apache.geode.security.AuthenticationRequiredException}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-3867) mutual SSL authentication with a bad client cert is not being tested
[ https://issues.apache.org/jira/browse/GEODE-3867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3867. --- > mutual SSL authentication with a bad client cert is not being tested > > > Key: GEODE-3867 > URL: https://issues.apache.org/jira/browse/GEODE-3867 > Project: Geode > Issue Type: Bug > Components: messaging >Reporter: Bruce Schuchardt >Priority: Major > Fix For: 1.4.0 > > > While checking out the client/server mutual authentication implementation I > couldn't find a test that showed a server rejecting a client that is not > trusted. We should add a test for that. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3650) Create new geode-example about persistence
[ https://issues.apache.org/jira/browse/GEODE-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3650. --- > Create new geode-example about persistence > -- > > Key: GEODE-3650 > URL: https://issues.apache.org/jira/browse/GEODE-3650 > Project: Geode > Issue Type: New Feature > Components: examples >Reporter: Michael Dodge >Assignee: Michael Dodge >Priority: Minor > Fix For: 1.4.0 > > > Create an example that demonstrates persistence. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3374) Refactor WAN tests to use test rules and remove WANCommandTestBase
[
https://issues.apache.org/jira/browse/GEODE-3374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-3374.
---
> Refactor WAN tests to use test rules and remove WANCommandTestBase
> --
>
> Key: GEODE-3374
> URL: https://issues.apache.org/jira/browse/GEODE-3374
> Project: Geode
> Issue Type: Sub-task
> Components: tests
>Reporter: Emily Yeh
>Assignee: Shelley Lynn Hughes-Godfrey
>Priority: Major
> Fix For: 1.4.0
>
>
> {{WANCommandTestBase}} extends {{CliCommandTestBase}}, which is a deprecated
> class. Tests using this class should be refactored, after which this class
> should be removed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-4014) CacheRuleTest fails intermittently if prior test used more than default 4 DUnit VMs
[
https://issues.apache.org/jira/browse/GEODE-4014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-4014.
---
> CacheRuleTest fails intermittently if prior test used more than default 4
> DUnit VMs
> ---
>
> Key: GEODE-4014
> URL: https://issues.apache.org/jira/browse/GEODE-4014
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Fix For: 1.4.0
>
>
> {noformat}
> org.apache.geode.test.dunit.rules.tests.CacheRuleTest >
> createCacheInAllCreatesCluster FAILED
> java.lang.AssertionError: java.lang.AssertionError:
> Expected size:<6> but was:<7> in:
> <[172.17.0.5(63:locator):32769,
> 172.17.0.5(1):32770,
> 172.17.0.5(172):32771,
> 172.17.0.5(176):32772,
> 172.17.0.5(182):32773,
> 172.17.0.5(215):32774,
> 172.17.0.5(739):32775]>
> at
> org.apache.geode.test.junit.runners.TestRunner.runTestWithValidation(TestRunner.java:45)
> at
> org.apache.geode.test.dunit.rules.tests.CacheRuleTest.createCacheInAllCreatesCluster(CacheRuleTest.java:75)
> Caused by:
> java.lang.AssertionError:
> Expected size:<6> but was:<7> in:
> <[172.17.0.5(63:locator):32769,
> 172.17.0.5(1):32770,
> 172.17.0.5(172):32771,
> 172.17.0.5(176):32772,
> 172.17.0.5(182):32773,
> 172.17.0.5(215):32774,
> 172.17.0.5(739):32775]>
> at
> org.apache.geode.test.dunit.rules.tests.CacheRuleTest$CreateCacheInAllCreatesCluster.createCacheInAll_createsCluster(CacheRuleTest.java:230)
> 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.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:37)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> 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.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> org.apache.geode.test.junit.runners.TestRunner.runTestWithValidation(TestRunner.java:40)
> ... 1 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-3711) Create new geode-example about cache listeners
[ https://issues.apache.org/jira/browse/GEODE-3711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3711. --- > Create new geode-example about cache listeners > -- > > Key: GEODE-3711 > URL: https://issues.apache.org/jira/browse/GEODE-3711 > Project: Geode > Issue Type: New Feature > Components: examples >Reporter: Michael Dodge >Assignee: Michael Dodge >Priority: Major > Fix For: 1.4.0 > > > Create an example about cache listeners. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3873) User Guide: Drop-down menu for earlier versions doesn't work
[ https://issues.apache.org/jira/browse/GEODE-3873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-3873. --- > User Guide: Drop-down menu for earlier versions doesn't work > > > Key: GEODE-3873 > URL: https://issues.apache.org/jira/browse/GEODE-3873 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Fix For: 1.1.0, 1.2.1, 1.4.0 > > > The User Guide header contains a drop-down menu showing earlier versions of > the manual, but the links don't work. Also, the drop-down for v1.1 doesn't > have a link for the newer version, 1.2. > This is both a currently broken implementation and a future maintenance > headache. > Since all (currently 3) versions are accessible from the Geode website's Docs > page, let's just eliminate the version drop-down menu altogether. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4145) Clean up error code handling in protobuf
[ https://issues.apache.org/jira/browse/GEODE-4145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-4145. --- > Clean up error code handling in protobuf > > > Key: GEODE-4145 > URL: https://issues.apache.org/jira/browse/GEODE-4145 > Project: Geode > Issue Type: Task > Components: client/server >Reporter: Brian Rowe >Assignee: Brian Rowe >Priority: Major > Fix For: 1.4.0 > > > We currently have some unused error codes in ProtocolErrorCode: > UNSUPPORTED_VERSION(1101), > HANDSHAKE_REQUIRED(1104), > LOW_MEMORY(1300), <-- maybe this one should be used? > BAD_QUERY(2001), > QUERY_PARAMETER_MISMATCH(2200), > QUERY_BIND_FAILURE(2201), > QUERY_NOT_PERMITTED(2202), > QUERY_TIMEOUT(2203); > We also have a strange and incomplete list of exceptions that we catch and in > some cases incorrectly map to some of these error codes. For example > GetAllRequestOperationHandler catches "CacheLoaderException" and reports that > as DATA_UNREACHABLE, which is not what a CacheLoaderException means. > We need to review the exceptions we catch and the error codes we want to > support and clean them up consistently across all operations. > We may want to change the default behavior for unknown exceptions - it seems > like maybe we just close the connection to the client without reporting the > error message to the client for exceptions we haven't handled. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3958) TomcatSessionBackwardsCompatibilityTest fails to shutdown server due to non daemon client queue initialization thread
[
https://issues.apache.org/jira/browse/GEODE-3958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-3958.
---
> TomcatSessionBackwardsCompatibilityTest fails to shutdown server due to non
> daemon client queue initialization thread
> -
>
> Key: GEODE-3958
> URL: https://issues.apache.org/jira/browse/GEODE-3958
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Dan Smith
>Priority: Major
> Fix For: 1.4.0
>
>
> TomcatSessionBackwardsCompatibilityTest has been failing the nightly builds
> with the below error message.
> {noformat}
> org.junit.ComparisonFailure: [The Cache Server process terminated
> unexpectedly with exit status 1. Please refer to the log file in
> /Users/dsmith/Documents/Code/gemfire/open/geode-assembly/build/distributedTest/server
> for full details.
> Exception in thread "main" java.lang.RuntimeException: A PID file already
> exists and a Server may be running in
> /Users/dsmith/Documents/Code/gemfire/open/geode-assembly/build/distributedTest/server
> on 10.118.19.21[0].
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:810)
> at
> org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:692)
> at
> org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:226)
> Caused by: org.apache.geode.internal.process.FileAlreadyExistsException: Pid
> file already exists:
> /Users/dsmith/Documents/Code/gemfire/open/geode-assembly/build/distributedTest/server/vf.gf.server.pid
> for process 4524
> at
> org.apache.geode.internal.process.LocalProcessLauncher.checkOtherPid(LocalProcessLauncher.java:151)
> at
> org.apache.geode.internal.process.LocalProcessLauncher.writePid(LocalProcessLauncher.java:122)
> at
> org.apache.geode.internal.process.LocalProcessLauncher.(LocalProcessLauncher.java:70)
> at
> org.apache.geode.internal.process.ControllableProcess.createLocalProcessLauncher(ControllableProcess.java:158)
> at
> org.apache.geode.internal.process.ControllableProcess.(ControllableProcess.java:55)
> at
> org.apache.geode.internal.process.ControllableProcess.(ControllableProcess.java:47)
> at
> org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:746)
> ... 2 more
> {noformat}
> I was able to reproduce this failure locally. What's happening is that the
> first test runs successfully, and then the remaining tests fail with this
> error because there is a server process running. The test is using gfsh to
> start and stop the server in the same directory.
> I got a stack trace and logsfrom the running server. From the the logs of the
> server, it did get the shutdown message.
> {noformat}
> [info 2017/11/06 17:57:49.690 PST server tid=0x74]
> DistributionManager stopped in 109ms.
> [info 2017/11/06 17:57:49.691 PST server tid=0x74] Marking
> DistributionManager 10.118.19.21(server:4524):1025 as closed.
> {noformat}
> However, the process did not die because there is still a non daemon thread
> running
> {noformat}
> "Client Queue Initialization Thread 0" #89 prio=5 os_prio=31
> tid=0x7f8b1be8f800 nid=0xb903 waiting on condition [0x7bf17000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00076b5ea308> (a
> java.util.concurrent.SynchronousQueue$TransferStack)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.SynchronousQueue$TransferStack.awaitFulfill(SynchronousQueue.java:458)
> at
> java.util.concurrent.SynchronousQueue$TransferStack.transfer(SynchronousQueue.java:362)
> at java.util.concurrent.SynchronousQueue.take(SynchronousQueue.java:924)
> at
> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$3$1.run(AcceptorImpl.java:610)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This thread was added recently for GEODE-3637. It needs to be cleaned up as
> part of member shutdown.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-183) Warning message about multiple replies logged when performing a backup
[
https://issues.apache.org/jira/browse/GEODE-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Swapnil Bawaskar closed GEODE-183.
--
> Warning message about multiple replies logged when performing a backup
> --
>
> Key: GEODE-183
> URL: https://issues.apache.org/jira/browse/GEODE-183
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Dan Smith
>Priority: Minor
> Fix For: 1.4.0
>
>
> This warning message is logged when issuing a backup command through gfsh.
> [warning 2015/07/30 17:57:03.950 PDT locator1 Connection(5)-127.0.0.1> tid=0x69] Received reply from member
> 172.16.115.205(locator1:105277:locator):54895 but was not expecting one.
> More than one reply may have been received. The reply that was not expected
> is: com.gemstone.gemfire.admin.internal.FinishBackupResponse:
> [91384a78-4703-416e-881f-f17c6b85ec4e
> [172.16.115.205:/home/dsmith/data/manual_test/locator1/ConfigDiskDir_locator1]]
> To reproduce
> {noformat}
> gfsh start locator --name=locator1 --port=55221
> gfsh start server --name=server1 --J=-Dgemfire.locators=localhost[55221]
> --J=-Dgemfire.mcast-port=0
> gfsh create region --name=region1 --type=REPLICATE_PERSISTENT
> gfsh backup disk-store --dir=/tmp/backup1
> {noformat}
> Looking at the code in FinishBackupRequest, the issue is that the locator
> performing the backup locally on any disk stores present on the locator. It
> passes the result of that backup into the reply processor. The reply
> processor logs this warning because it was only initialized to expect replies
> from the other members, not from the locator itself.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-4134) RegionVersionVectorTest.doesNotHangIfOtherThreadChangedVersion has potential to hang
[ https://issues.apache.org/jira/browse/GEODE-4134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Swapnil Bawaskar closed GEODE-4134. --- > RegionVersionVectorTest.doesNotHangIfOtherThreadChangedVersion has potential > to hang > > > Key: GEODE-4134 > URL: https://issues.apache.org/jira/browse/GEODE-4134 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Fix For: 1.4.0 > > > RegionVersionVectorTest.doesNotHangIfOtherThreadChangedVersion has potential > to hang if the bug is reintroduced. The reason is that CompletableFuture > cancel(true) does not interrupt the thread executing the task. Specifying an > ExecutorService and invoking shutdownNow fixes this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
