[jira] [Commented] (GEODE-748) Unexpected version string returned from gfsh
[
https://issues.apache.org/jira/browse/GEODE-748?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15301212#comment-15301212
]
ASF subversion and git services commented on GEODE-748:
---
Commit 525cd811217a32895dee2518ad851a50a6499332 in incubator-geode's branch
refs/heads/develop from [~kduling]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=525cd81 ]
GEODE-748: Unexpected version string returned from gfsh
> Unexpected version string returned from gfsh
>
>
> Key: GEODE-748
> URL: https://issues.apache.org/jira/browse/GEODE-748
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Kevin Duling
>
> {{gfsh version}} returns a version number with a prepended 'v'. This is
> inconsistent with the actual versioning which never includes a 'v'.
> The {{v}} should be removed from the specific gfsh command.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-16) Provide distributed transactions in Geode
[ https://issues.apache.org/jira/browse/GEODE-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15301154#comment-15301154 ] Alexandre Arnaudy commented on GEODE-16: Hi, I am currently out of office and returning on May 31rst. For any urgent issues please forward your messages to coretech-service-framework. Regards, Alexandre *** This e-mail contains information for the intended recipient only. It may contain proprietary material or confidential information. If you are not the intended recipient you are not authorised to distribute, copy or use this e-mail or any attachment to it. Murex cannot guarantee that it is virus free and accepts no responsibility for any loss or damage arising from its use. If you have received this e-mail in error please notify immediately the sender and delete the original email received, any attachments and all copies from your system. > Provide distributed transactions in Geode > - > > Key: GEODE-16 > URL: https://issues.apache.org/jira/browse/GEODE-16 > Project: Geode > Issue Type: New Feature > Components: docs, transactions >Reporter: Shirish Deshmukh >Assignee: Swapnil Bawaskar > Attachments: DistributedTransactionDesign.pdf > > > This is a feature that has been under design for GemFire but was not part of > the initial drop of code for geode. > Currently in Geode a transactional operation can only be applied on colocated > data i.e. all the key-value pairs affected in a transaction should be on > single VM. > We should allow operations on multiple VMs simultaneously in a single > transaction, which would eliminate current restrictions. > Some of the implicit requirements for this feature are: > Provide distributed transaction feature that would also be scalable > Continue to support existing transaction functionalities (transactions on > colocated data) > Do not affect performance of existing features > Support backward compatibility and rolling upgrade (with immediate previous > Geode release) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1441) Distributed transaction unit tests confusing
[
https://issues.apache.org/jira/browse/GEODE-1441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15301151#comment-15301151
]
Darrel Schneider commented on GEODE-1441:
-
These unit tests are part of GEODE-16.
The current plan, as I understand it, was to leave the partial implementation
of GEODE-16 in the develop branch.
These tests are part of that partial implementation and they do provide test
coverage of it.
I think the idea was to have unit tests that use the partial implementation of
GEODE-16 so that it would not rot. If that is correct then these tests should
not be removed but left as is.
> Distributed transaction unit tests confusing
>
>
> Key: GEODE-1441
> URL: https://issues.apache.org/jira/browse/GEODE-1441
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Reporter: Kirk Lund
>
> Fix this mess...
> {noformat}
> @Category(DistributedTest.class)
> public class PRDistTXWithVersionsDUnitTest extends
> PRTransactionWithVersionsDUnitTest {
> @Override
> public Properties getDistributedSystemProperties() {
> Properties props = super.getDistributedSystemProperties();
> props.setProperty(DistributionConfig.DISTRIBUTED_TRANSACTIONS_NAME,
> "true");
> return props;
> }
>
> @Ignore("[DISTTX] TODO test overridden and intentionally left blank as they
> fail.")
> @Test
> public void testBasicPRTransactionRedundancy0() {
> }
> @Ignore("[DISTTX] TODO test overridden and intentionally left blank as they
> fail.")
> @Test
> public void testBasicPRTransactionRedundancy1() {
> }
> @Ignore("[DISTTX] TODO test overridden and intentionally left blank as they
> fail.")
> @Test
> public void testBasicPRTransactionRedundancy2() {
> }
> @Ignore("[DISTTX] TODO test overridden and intentionally left blank as they
> fail.")
> @Test
> public void testBasicPRTransactionNoDataRedundancy0() {
> }
> @Ignore("[DISTTX] TODO test overridden and intentionally left blank as they
> fail.")
> @Test
> public void testBasicPRTransactionNoDataRedundancy1() {
> }
> @Ignore("[DISTTX] TODO test overridden and intentionally left blank as they
> fail.")
> @Test
> public void testBasicPRTransactionNoDataRedundancy2() {
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-16) Provide distributed transactions in Geode
[ https://issues.apache.org/jira/browse/GEODE-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-16: -- Component/s: (was: core) transactions > Provide distributed transactions in Geode > - > > Key: GEODE-16 > URL: https://issues.apache.org/jira/browse/GEODE-16 > Project: Geode > Issue Type: New Feature > Components: docs, transactions >Reporter: Shirish Deshmukh >Assignee: Swapnil Bawaskar > Attachments: DistributedTransactionDesign.pdf > > > This is a feature that has been under design for GemFire but was not part of > the initial drop of code for geode. > Currently in Geode a transactional operation can only be applied on colocated > data i.e. all the key-value pairs affected in a transaction should be on > single VM. > We should allow operations on multiple VMs simultaneously in a single > transaction, which would eliminate current restrictions. > Some of the implicit requirements for this feature are: > Provide distributed transaction feature that would also be scalable > Continue to support existing transaction functionalities (transactions on > colocated data) > Do not affect performance of existing features > Support backward compatibility and rolling upgrade (with immediate previous > Geode release) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-1459) "java.lang.InternalError: Memory Pool not found" on client
Swapnil Bawaskar created GEODE-1459:
---
Summary: "java.lang.InternalError: Memory Pool not found" on client
Key: GEODE-1459
URL: https://issues.apache.org/jira/browse/GEODE-1459
Project: Geode
Issue Type: Bug
Components: statistics
Reporter: Swapnil Bawaskar
"Memory Pool not found" exception is thrown with the below stack trace:
{noformat}
Caused by: java.lang.InternalError: Memory Pool not found
at sun.management.MemoryPoolImpl.getUsage0(Native Method)
at sun.management.MemoryPoolImpl.getUsage(MemoryPoolImpl.java:96)
at
com.gemstone.gemfire.internal.stats50.VMStats50.refreshMemoryPools(VMStats50.java:502)
at com.gemstone.gemfire.internal.stats50.VMStats50.refresh(VMStats50.java:631)
at
com.gemstone.gemfire.internal.HostStatSampler.sampleSpecialStats(HostStatSampler.java:501)
at com.gemstone.gemfire.internal.HostStatSampler.run(HostStatSampler.java:195)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1453) if field value is null, creating index will fail with NPE
[ https://issues.apache.org/jira/browse/GEODE-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15301004#comment-15301004 ] ASF subversion and git services commented on GEODE-1453: Commit 31096fbf927e75ba30c25deea985c2b40af75f75 in incubator-geode's branch refs/heads/feature/GEODE-835 from zhouxh [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=31096fb ] GEODE-1453: when parsing field value, should consider it is null > if field value is null, creating index will fail with NPE > - > > Key: GEODE-1453 > URL: https://issues.apache.org/jira/browse/GEODE-1453 > Project: Geode > Issue Type: Bug >Reporter: xiaojian zhou >Assignee: xiaojian zhou > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1410) Fix artifacts published for modules
[ https://issues.apache.org/jira/browse/GEODE-1410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15301000#comment-15301000 ] ASF subversion and git services commented on GEODE-1410: Commit 46eeb39cef78ce6c0e1c0b0546a14eb64cc65c9b in incubator-geode's branch refs/heads/feature/GEODE-835 from [~jens.deppe] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=46eeb39 ] GEODE-1410: Fix artifacts published for modules > Fix artifacts published for modules > --- > > Key: GEODE-1410 > URL: https://issues.apache.org/jira/browse/GEODE-1410 > Project: Geode > Issue Type: Bug > Components: http session >Reporter: Jens Deppe >Assignee: Jens Deppe > Fix For: 1.0.0-incubating.M3 > > > Currently, the :extensions/geode-modules-session subproject produces 2 jars, > one of which is classified as 'internal'. This is because maven poms can only > have a single artifact (implicitly) classified as 'jar'. > We should try and produce a separate pom for the 'internal' jar - preferrably > without having to break up the submodule into 2 submodules. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-835) Replace joptsimple source with a binary dependency
[ https://issues.apache.org/jira/browse/GEODE-835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15301009#comment-15301009 ] ASF subversion and git services commented on GEODE-835: --- Commit c9aac5a335ffc0c41e80f26b1cf194765613118d in incubator-geode's branch refs/heads/feature/GEODE-835 from [~apa...@the9muses.net] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=c9aac5a ] Merge remote-tracking branch 'origin/develop' into feature/GEODE-835 > Replace joptsimple source with a binary dependency > -- > > Key: GEODE-835 > URL: https://issues.apache.org/jira/browse/GEODE-835 > Project: Geode > Issue Type: Bug > Components: build, gfsh >Reporter: Anthony Baker >Assignee: Kirk Lund > Fix For: 1.0.0-incubating.M3 > > Attachments: joptsimple.patch > > > The gemfire-jopsimple folder contains modified source code from the > joptsimple library. We should replace this with a binary dependency. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1458) Sequence logger thread can die on startup and should not be enabled by default
[ https://issues.apache.org/jira/browse/GEODE-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15301007#comment-15301007 ] ASF subversion and git services commented on GEODE-1458: Commit 1d11d94dfe600b99007ccdc28f178d98fd86fd30 in incubator-geode's branch refs/heads/feature/GEODE-835 from [~upthewaterspout] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=1d11d94 ] GEODE-1458: Prevent sequence logger from launching and closing a thread The sequence logger code was launching a thread from a static block, even if it was not enabled. The thread was then immediately dying. Fixing the code to not launch the thread unless it is enabled, and to not die immediately if it is. > Sequence logger thread can die on startup and should not be enabled by default > -- > > Key: GEODE-1458 > URL: https://issues.apache.org/jira/browse/GEODE-1458 > Project: Geode > Issue Type: Bug >Reporter: Dan Smith >Assignee: Dan Smith > Fix For: 1.0.0-incubating.M3 > > > The SequenceLoggerImpl class always creates a thread in the static block. > However, if the logger class is loaded before the cache, the thread dies > immediately. > Since sequence logging is usually not enabled, we shouldn't even start this > thread unless it is enabled and in that case it should not die if a cache is > not present. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1428) Cache close will log a warning and not dispatch the cache close event if the sys prop gemfire.Cache.ASYNC_EVENT_LISTENERS is set to true
[
https://issues.apache.org/jira/browse/GEODE-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15301006#comment-15301006
]
ASF subversion and git services commented on GEODE-1428:
Commit fa6e722e727a6f40788014aa6cac17890f6a64c9 in incubator-geode's branch
refs/heads/feature/GEODE-835 from [~dschneider]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=fa6e722 ]
GEODE-1428: deliver event synchronously if it is rejected
Changed unit test to use close instead of emergencyClose.
Doing this caused an event to be sent after the async thread
pool was shutdown which resulted in a suspect warning without
this fix.
> Cache close will log a warning and not dispatch the cache close event if the
> sys prop gemfire.Cache.ASYNC_EVENT_LISTENERS is set to true
>
>
> Key: GEODE-1428
> URL: https://issues.apache.org/jira/browse/GEODE-1428
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.0.0-incubating.M3
>
>
> If you enable async cache listeners then during cache close the dispatch of
> the cache close event will be rejected because the pool has already shutdown.
> The code that uses the async pool currently catches
> RejectedExecutionException and logs it. It should instead just do a
> synchronous invocation of the listener.
> Here is the stack you will see:
> [warn 2016/05/20 17:16:07.107 PDT tid=0x1] {0} Event not dispatched
> due to rejected execution
> java.util.concurrent.RejectedExecutionException: executor has been shutdown
> at
> com.gemstone.gemfire.distributed.internal.PooledExecutorWithDMStats$BufferHandler.rejectedExecution(PooledExecutorWithDMStats.java:220)
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> at
> com.gemstone.gemfire.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:7591)
> at
> com.gemstone.gemfire.internal.cache.LocalRegion.sendPendingRegionDestroyEvents(LocalRegion.java:7850)
> at
> com.gemstone.gemfire.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6853)
> at
> com.gemstone.gemfire.internal.cache.DistributedRegion.basicDestroyRegion(DistributedRegion.java:1917)
> at
> com.gemstone.gemfire.internal.cache.LocalRegion.handleCacheClose(LocalRegion.java:7934)
> at
> com.gemstone.gemfire.internal.cache.DistributedRegion.handleCacheClose(DistributedRegion.java:2825)
> at
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2149)
> at
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1856)
> at
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1852)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1296) OffHeapStoredObject.getRawBytes should assert that it is not called on compressed data
[
https://issues.apache.org/jira/browse/GEODE-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15301008#comment-15301008
]
ASF subversion and git services commented on GEODE-1296:
Commit 6c626b7ebc134d85160ff2d253ed12762fe49728 in incubator-geode's branch
refs/heads/feature/GEODE-835 from [~khowe]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=6c626b7 ]
GEODE-1296: change conditional in getRawBytes to assert
> OffHeapStoredObject.getRawBytes should assert that it is not called on
> compressed data
> --
>
> Key: GEODE-1296
> URL: https://issues.apache.org/jira/browse/GEODE-1296
> Project: Geode
> Issue Type: Bug
> Components: offheap
>Reporter: Darrel Schneider
>Assignee: Kenneth Howe
> Fix For: 1.0.0-incubating.M3
>
>
> The current code does this:
> if (isCompressed()) {
> throw new UnsupportedOperationException();
> }
> It would be more clear if it just did this:
> assert !isCompressed();
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1413) ParallelGatewaySenderOperationsDUnitTest.testParallelPropagationSenderStartAfterStop_Scenario2
[
https://issues.apache.org/jira/browse/GEODE-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15301003#comment-15301003
]
ASF subversion and git services commented on GEODE-1413:
Commit bd892f531aaaeb14361df1a71fb7341f04034749 in incubator-geode's branch
refs/heads/feature/GEODE-835 from [~nnag]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=bd892f5 ]
GEODE-1413: Replaced wait with awaitility clause on receiver regionSize
* Replaced the wait for 2 seconds with awaitility clause which waits for the
receiver region size to become the expected size.
This closes #146
> ParallelGatewaySenderOperationsDUnitTest.testParallelPropagationSenderStartAfterStop_Scenario2
> --
>
> Key: GEODE-1413
> URL: https://issues.apache.org/jira/browse/GEODE-1413
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Sai Boorlagadda
>Assignee: nabarun
> Labels: CI
>
> {noformat}
> Error Message
> com.gemstone.gemfire.test.dunit.RMIException: While invoking
> com.gemstone.gemfire.internal.cache.wan.parallel.ParallelGatewaySenderOperationsDUnitTest$$Lambda$1041/2063794856.run
> in VM 4 running on Host zambia.gemstone.com with 8 VMs
> Stacktrace
> com.gemstone.gemfire.test.dunit.RMIException: While invoking
> com.gemstone.gemfire.internal.cache.wan.parallel.ParallelGatewaySenderOperationsDUnitTest$$Lambda$1041/2063794856.run
> in VM 4 running on Host zambia.gemstone.com with 8 VMs
> at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:389)
> at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:355)
> at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:293)
> at
> com.gemstone.gemfire.internal.cache.wan.parallel.ParallelGatewaySenderOperationsDUnitTest.testParallelPropagationSenderStartAfterStop_Scenario2(ParallelGatewaySenderOperationsDUnitTest.java:358)
> 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:112)
> 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:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java: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: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:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(R
[jira] [Commented] (GEODE-1121) CI failure: ConcurrentWANPropogation_2_DUnitTest.testSerialReplicatedWanWithOverflow
[ https://issues.apache.org/jira/browse/GEODE-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15301002#comment-15301002 ] ASF subversion and git services commented on GEODE-1121: Commit b5585679391b9412515106327c30bfeed18d4a70 in incubator-geode's branch refs/heads/feature/GEODE-835 from [~nnag] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=b558567 ] GEODE-1121: Reduced the memory configurations in the overflow tests. * Reduced the sender's max memory to 1MB. * Reduced the amount of puts to 5MB. * Introduced a listener to sleep on create event in the receiver to slow down the sender. * Modified the addListenerToSleepOnCreate function signature to take region name as a parameter. This closes #147 > CI failure: > ConcurrentWANPropogation_2_DUnitTest.testSerialReplicatedWanWithOverflow > > > Key: GEODE-1121 > URL: https://issues.apache.org/jira/browse/GEODE-1121 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Bruce Schuchardt > Labels: CI, Flaky > > Revision 8645fe03811c9b959e0ea9e6257126ee5e0be255 > Test failed with this exception: > com.gemstone.gemfire.test.dunit.RMIException: While invoking > com.gemstone.gemfire.internal.cache.wan.concurrent.ConcurrentWANPropogation_2_DUnitTest$$Lambda$1461/978635401.run > in VM 2 running on Host venezuela.gemstone.com with 8 VMs > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:440) > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:382) > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:318) > at > com.gemstone.gemfire.internal.cache.wan.concurrent.ConcurrentWANPropogation_2_DUnitTest.testSerialReplicatedWanWithOverflow(ConcurrentWANPropogation_2_DUnitTest.java:86) > 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)
[jira] [Commented] (GEODE-11) Lucene Integration
[ https://issues.apache.org/jira/browse/GEODE-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15301001#comment-15301001 ] ASF subversion and git services commented on GEODE-11: -- Commit 777c42ee08866caf63c39a20072c7930bbbd2fc5 in incubator-geode's branch refs/heads/feature/GEODE-835 from zhouxh [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=777c42e ] GEODE-11: let query to use index's analyzer; add tests for customized analyzer and analyzer per field > Lucene Integration > -- > > Key: GEODE-11 > URL: https://issues.apache.org/jira/browse/GEODE-11 > Project: Geode > Issue Type: New Feature > Components: querying >Reporter: Dan Smith >Assignee: xiaojian zhou > > This is a feature that has been under development for GemFire but was not > part of the initial drop of code for geode. > Allow Lucene indexes to be stored in Geode regions allowing users to do text > searches on data stored in Geode. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1425) PartitionRegionHelper local data methods return a Region whose get(key, callbackArg) method does not correctly handle the callback argument
[ https://issues.apache.org/jira/browse/GEODE-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15301005#comment-15301005 ] ASF subversion and git services commented on GEODE-1425: Commit cae8f7fecf893ea4a31f7b06c22130fb646407bb in incubator-geode's branch refs/heads/feature/GEODE-835 from [~dschneider] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=cae8f7f ] GEODE-1425: fix callback arg parameter order > PartitionRegionHelper local data methods return a Region whose get(key, > callbackArg) method does not correctly handle the callback argument > --- > > Key: GEODE-1425 > URL: https://issues.apache.org/jira/browse/GEODE-1425 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Darrel Schneider >Assignee: Darrel Schneider > Fix For: 1.0.0-incubating.M3 > > > PartitionRegionHelper has the methods: getLocalData and getLocalPrimaryData. > They both return an instance of Region. > The get(key, callbackArg) does not do the following with the callbackArg: > 1. It does not check if the callbackArg is an instanceof PartitionResolver. > So you can not use the callbackArg in this case to specify the resolver. > Instead use the resolver region attribute or the key. > 2. The EntryOperation passed to the resolver getRoutingObject method will > return the callbackArg from getNewValue and null from getCallbackArgument and > false from isCallbackArgumentAvailable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1296) OffHeapStoredObject.getRawBytes should assert that it is not called on compressed data
[
https://issues.apache.org/jira/browse/GEODE-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300960#comment-15300960
]
ASF GitHub Bot commented on GEODE-1296:
---
Github user pdxrunner commented on the pull request:
https://github.com/apache/incubator-geode/pull/145#issuecomment-221722725
This was checked in by dschneider. Closing the PR
> OffHeapStoredObject.getRawBytes should assert that it is not called on
> compressed data
> --
>
> Key: GEODE-1296
> URL: https://issues.apache.org/jira/browse/GEODE-1296
> Project: Geode
> Issue Type: Bug
> Components: offheap
>Reporter: Darrel Schneider
>Assignee: Kenneth Howe
> Fix For: 1.0.0-incubating.M3
>
>
> The current code does this:
> if (isCompressed()) {
> throw new UnsupportedOperationException();
> }
> It would be more clear if it just did this:
> assert !isCompressed();
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1296) OffHeapStoredObject.getRawBytes should assert that it is not called on compressed data
[
https://issues.apache.org/jira/browse/GEODE-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300961#comment-15300961
]
ASF GitHub Bot commented on GEODE-1296:
---
Github user pdxrunner closed the pull request at:
https://github.com/apache/incubator-geode/pull/145
> OffHeapStoredObject.getRawBytes should assert that it is not called on
> compressed data
> --
>
> Key: GEODE-1296
> URL: https://issues.apache.org/jira/browse/GEODE-1296
> Project: Geode
> Issue Type: Bug
> Components: offheap
>Reporter: Darrel Schneider
>Assignee: Kenneth Howe
> Fix For: 1.0.0-incubating.M3
>
>
> The current code does this:
> if (isCompressed()) {
> throw new UnsupportedOperationException();
> }
> It would be more clear if it just did this:
> assert !isCompressed();
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-835) Replace joptsimple source with a binary dependency
[ https://issues.apache.org/jira/browse/GEODE-835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300954#comment-15300954 ] Kirk Lund commented on GEODE-835: - The two tests closest to the jopt-simple OptionParser code are JoptOptionParserTest and GfshParserJUnitTest. > Replace joptsimple source with a binary dependency > -- > > Key: GEODE-835 > URL: https://issues.apache.org/jira/browse/GEODE-835 > Project: Geode > Issue Type: Bug > Components: build, gfsh >Reporter: Anthony Baker >Assignee: Kirk Lund > Fix For: 1.0.0-incubating.M3 > > Attachments: joptsimple.patch > > > The gemfire-jopsimple folder contains modified source code from the > joptsimple library. We should replace this with a binary dependency. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1296) OffHeapStoredObject.getRawBytes should assert that it is not called on compressed data
[
https://issues.apache.org/jira/browse/GEODE-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300956#comment-15300956
]
ASF subversion and git services commented on GEODE-1296:
Commit 6c626b7ebc134d85160ff2d253ed12762fe49728 in incubator-geode's branch
refs/heads/develop from [~khowe]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=6c626b7 ]
GEODE-1296: change conditional in getRawBytes to assert
> OffHeapStoredObject.getRawBytes should assert that it is not called on
> compressed data
> --
>
> Key: GEODE-1296
> URL: https://issues.apache.org/jira/browse/GEODE-1296
> Project: Geode
> Issue Type: Bug
> Components: offheap
>Reporter: Darrel Schneider
>Assignee: Kenneth Howe
>
> The current code does this:
> if (isCompressed()) {
> throw new UnsupportedOperationException();
> }
> It would be more clear if it just did this:
> assert !isCompressed();
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (GEODE-1296) OffHeapStoredObject.getRawBytes should assert that it is not called on compressed data
[
https://issues.apache.org/jira/browse/GEODE-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-1296.
-
Resolution: Fixed
Fix Version/s: 1.0.0-incubating.M3
> OffHeapStoredObject.getRawBytes should assert that it is not called on
> compressed data
> --
>
> Key: GEODE-1296
> URL: https://issues.apache.org/jira/browse/GEODE-1296
> Project: Geode
> Issue Type: Bug
> Components: offheap
>Reporter: Darrel Schneider
>Assignee: Kenneth Howe
> Fix For: 1.0.0-incubating.M3
>
>
> The current code does this:
> if (isCompressed()) {
> throw new UnsupportedOperationException();
> }
> It would be more clear if it just did this:
> assert !isCompressed();
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-1452) Annotate disabled test methods with @Ignore
[ https://issues.apache.org/jira/browse/GEODE-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-1452: - Description: Some of the older tests have test methods which were disabled by renaming the test method from JUnit 3 syntax to something like "public void _testMethod" or "public void disabled_testMethod". Most of these tests were then updated to JUnit 4, but the disabled tests remain without @Ignore or @Test annotations. We should annotate these test methods with @Ignore and @Test so they are correctly counted as skipped tests. Tickets should then be filed to analyze whether these tests should be fixed or deleted. was: Some of the older tests have test methods which were disabled by renaming the test method from JUnit 3 syntax to something like "public void _testMethod" or "public void disabled_testMethod". Most of these tests were then updated to JUnit 4, but the disabled tests rename without @Ignore or @Test annotations. We should annotate these test methods with @Ignore and @Test so they are correctly counted as skipped tests. Tickets should then be filed to analyze whether these tests should be fixed or deleted. > Annotate disabled test methods with @Ignore > --- > > Key: GEODE-1452 > URL: https://issues.apache.org/jira/browse/GEODE-1452 > Project: Geode > Issue Type: Test > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund > > Some of the older tests have test methods which were disabled by renaming the > test method from JUnit 3 syntax to something like "public void _testMethod" > or "public void disabled_testMethod". > Most of these tests were then updated to JUnit 4, but the disabled tests > remain without @Ignore or @Test annotations. > We should annotate these test methods with @Ignore and @Test so they are > correctly counted as skipped tests. Tickets should then be filed to analyze > whether these tests should be fixed or deleted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1452) Annotate disabled test methods with @Ignore
[ https://issues.apache.org/jira/browse/GEODE-1452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300945#comment-15300945 ] ASF subversion and git services commented on GEODE-1452: Commit ff8348e030aa099c950a81f206c28a4d7305c5e7 in incubator-geode's branch refs/heads/feature/GEODE-1452 from [~apa...@the9muses.net] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=ff8348e ] Merge remote-tracking branch 'origin/develop' into feature/GEODE-1452 > Annotate disabled test methods with @Ignore > --- > > Key: GEODE-1452 > URL: https://issues.apache.org/jira/browse/GEODE-1452 > Project: Geode > Issue Type: Test > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund > > Some of the older tests have test methods which were disabled by renaming the > test method from JUnit 3 syntax to something like "public void _testMethod" > or "public void disabled_testMethod". > Most of these tests were then updated to JUnit 4, but the disabled tests > rename without @Ignore or @Test annotations. > We should annotate these test methods with @Ignore and @Test so they are > correctly counted as skipped tests. Tickets should then be filed to analyze > whether these tests should be fixed or deleted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1246) GemFireCacheImpl's eventThreadPool only uses one thread for asynchronously invoking CacheListener callbacks
[
https://issues.apache.org/jira/browse/GEODE-1246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300913#comment-15300913
]
Darrel Schneider commented on GEODE-1246:
-
The unit test also introduced GEODE-1456
> GemFireCacheImpl's eventThreadPool only uses one thread for asynchronously
> invoking CacheListener callbacks
> ---
>
> Key: GEODE-1246
> URL: https://issues.apache.org/jira/browse/GEODE-1246
> Project: Geode
> Issue Type: Bug
> Components: core, regions
>Reporter: Barry Oglesby
>Assignee: Darrel Schneider
> Fix For: 1.0.0-incubating.M3
>
>
> After enabling asynchronous {{CacheListener}} callbacks, the
> {{CacheListener}} callbacks are processed serially by the same {{Message
> Event Thread}} thread even though the {{eventThreadPool}} is configured with
> 16 threads.
> Configure asynchronous {{CacheListener}} callbacks like:
> {noformat}
> --J=-Dgemfire.Cache.ASYNC_EVENT_LISTENERS=true
> {noformat}
> The {{eventThreadPool}} is currently created like:
> {noformat}
> ArrayBlockingQueue q = new ArrayBlockingQueue(EVENT_QUEUE_LIMIT);
> this.eventThreadPool = new PooledExecutorWithDMStats(q, 16,
> this.cachePerfStats.getEventPoolHelper(), tf, 1000, new CallerRunsPolicy());
> {noformat}
> At Darrel's suggestion, I replaced the {{eventThreadPool's
> ArrayBlockingQueue}} with a {{SynchronousQueue}}, and that is working as
> expected (all 16 threads are used):
> {noformat}
> this.eventThreadPool = new PooledExecutorWithDMStats(new SynchronousQueue(),
> 16, this.cachePerfStats.getEventPoolHelper(), tf, 1000, new
> CallerRunsPolicy());
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1428) Cache close will log a warning and not dispatch the cache close event if the sys prop gemfire.Cache.ASYNC_EVENT_LISTENERS is set to true
[
https://issues.apache.org/jira/browse/GEODE-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300943#comment-15300943
]
ASF subversion and git services commented on GEODE-1428:
Commit fa6e722e727a6f40788014aa6cac17890f6a64c9 in incubator-geode's branch
refs/heads/feature/GEODE-1452 from [~dschneider]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=fa6e722 ]
GEODE-1428: deliver event synchronously if it is rejected
Changed unit test to use close instead of emergencyClose.
Doing this caused an event to be sent after the async thread
pool was shutdown which resulted in a suspect warning without
this fix.
> Cache close will log a warning and not dispatch the cache close event if the
> sys prop gemfire.Cache.ASYNC_EVENT_LISTENERS is set to true
>
>
> Key: GEODE-1428
> URL: https://issues.apache.org/jira/browse/GEODE-1428
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.0.0-incubating.M3
>
>
> If you enable async cache listeners then during cache close the dispatch of
> the cache close event will be rejected because the pool has already shutdown.
> The code that uses the async pool currently catches
> RejectedExecutionException and logs it. It should instead just do a
> synchronous invocation of the listener.
> Here is the stack you will see:
> [warn 2016/05/20 17:16:07.107 PDT tid=0x1] {0} Event not dispatched
> due to rejected execution
> java.util.concurrent.RejectedExecutionException: executor has been shutdown
> at
> com.gemstone.gemfire.distributed.internal.PooledExecutorWithDMStats$BufferHandler.rejectedExecution(PooledExecutorWithDMStats.java:220)
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> at
> com.gemstone.gemfire.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:7591)
> at
> com.gemstone.gemfire.internal.cache.LocalRegion.sendPendingRegionDestroyEvents(LocalRegion.java:7850)
> at
> com.gemstone.gemfire.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6853)
> at
> com.gemstone.gemfire.internal.cache.DistributedRegion.basicDestroyRegion(DistributedRegion.java:1917)
> at
> com.gemstone.gemfire.internal.cache.LocalRegion.handleCacheClose(LocalRegion.java:7934)
> at
> com.gemstone.gemfire.internal.cache.DistributedRegion.handleCacheClose(DistributedRegion.java:2825)
> at
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2149)
> at
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1856)
> at
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1852)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1458) Sequence logger thread can die on startup and should not be enabled by default
[ https://issues.apache.org/jira/browse/GEODE-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300944#comment-15300944 ] ASF subversion and git services commented on GEODE-1458: Commit 1d11d94dfe600b99007ccdc28f178d98fd86fd30 in incubator-geode's branch refs/heads/feature/GEODE-1452 from [~upthewaterspout] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=1d11d94 ] GEODE-1458: Prevent sequence logger from launching and closing a thread The sequence logger code was launching a thread from a static block, even if it was not enabled. The thread was then immediately dying. Fixing the code to not launch the thread unless it is enabled, and to not die immediately if it is. > Sequence logger thread can die on startup and should not be enabled by default > -- > > Key: GEODE-1458 > URL: https://issues.apache.org/jira/browse/GEODE-1458 > Project: Geode > Issue Type: Bug >Reporter: Dan Smith >Assignee: Dan Smith > Fix For: 1.0.0-incubating.M3 > > > The SequenceLoggerImpl class always creates a thread in the static block. > However, if the logger class is loaded before the cache, the thread dies > immediately. > Since sequence logging is usually not enabled, we shouldn't even start this > thread unless it is enabled and in that case it should not die if a cache is > not present. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1453) if field value is null, creating index will fail with NPE
[ https://issues.apache.org/jira/browse/GEODE-1453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300941#comment-15300941 ] ASF subversion and git services commented on GEODE-1453: Commit 31096fbf927e75ba30c25deea985c2b40af75f75 in incubator-geode's branch refs/heads/feature/GEODE-1452 from zhouxh [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=31096fb ] GEODE-1453: when parsing field value, should consider it is null > if field value is null, creating index will fail with NPE > - > > Key: GEODE-1453 > URL: https://issues.apache.org/jira/browse/GEODE-1453 > Project: Geode > Issue Type: Bug >Reporter: xiaojian zhou >Assignee: xiaojian zhou > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1425) PartitionRegionHelper local data methods return a Region whose get(key, callbackArg) method does not correctly handle the callback argument
[ https://issues.apache.org/jira/browse/GEODE-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300942#comment-15300942 ] ASF subversion and git services commented on GEODE-1425: Commit cae8f7fecf893ea4a31f7b06c22130fb646407bb in incubator-geode's branch refs/heads/feature/GEODE-1452 from [~dschneider] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=cae8f7f ] GEODE-1425: fix callback arg parameter order > PartitionRegionHelper local data methods return a Region whose get(key, > callbackArg) method does not correctly handle the callback argument > --- > > Key: GEODE-1425 > URL: https://issues.apache.org/jira/browse/GEODE-1425 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Darrel Schneider >Assignee: Darrel Schneider > Fix For: 1.0.0-incubating.M3 > > > PartitionRegionHelper has the methods: getLocalData and getLocalPrimaryData. > They both return an instance of Region. > The get(key, callbackArg) does not do the following with the callbackArg: > 1. It does not check if the callbackArg is an instanceof PartitionResolver. > So you can not use the callbackArg in this case to specify the resolver. > Instead use the resolver region attribute or the key. > 2. The EntryOperation passed to the resolver getRoutingObject method will > return the callbackArg from getNewValue and null from getCallbackArgument and > false from isCallbackArgumentAvailable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1331) gfsh.bat on Windows is incorrect
[
https://issues.apache.org/jira/browse/GEODE-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300893#comment-15300893
]
Kevin Duling commented on GEODE-1331:
-
When DOS does an @set within a batch file, it normally populates that change
out in to the general system environment. This behavior is disabled with the
@setlocal command at the beginning of the script. So, when CLASSPATH is being
set within the script, it is only changed within the script and processes
launched from that script. This is why the CLASSPATH environment variable
doesn't continue to become longer and longer with each subsequent run of a
batch file.
I've removed the code that was adding the gfsh-dependency.jar to the temporary
classpath twice. To avoid confusion, I've renamed the CLASSPATH variable
within the script to DEPENDENCIES and pass it in with the -classpath option.
> gfsh.bat on Windows is incorrect
>
>
> Key: GEODE-1331
> URL: https://issues.apache.org/jira/browse/GEODE-1331
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Kevin Duling
> Fix For: 1.0.0-incubating.M3
>
>
> Initial report:
> {noformat}
> I am doing testing in windows STS. I am not adding these dependencies jars,
> gfsh.bat is what doing this.
>
> C:\DEV\Pivotal\GemFire_v82014\bin\gfsh.bat has below code, which is setting
> gemfire, antlr, gfsh-dependencies and pulse-dependencies jars in classpath.
> Line 26 to 29
> @set
> GEMFIRE_JARS=%GEMFIRE%\lib\gemfire.jar;%GEMFIRE%\lib\antlr.jar;%GEMFIRE%\lib\gfsh-dependencies.jar;%GEMFIRE%\lib\pulse-dependencies.jar
> @if defined CLASSPATH (
> @set GEMFIRE_JARS=%GEMFIRE_JARS%;%CLASSPATH%
> )
> C:\DEV\Pivotal\GemFire_v82014\lib\gemfire.jar // DUPLICATE
> C:\DEV\Pivotal\GemFire_v82014\lib\antlr.jar
> C:\DEV\Pivotal\GemFire_v82014\lib\gfsh-dependencies.jar // DUPLICATE
> C:\DEV\Pivotal\GemFire_v82014\lib\pulse-dependencies.jar
>
> Unix C:\DEV\Pivotal\GemFire_v82014\bin script, does not set these jars in
> classpath.
>
>
> Another observation is that, if I pass --include-system-classpath to gfsh
> start server command, then it is prepending
> gemfire.jar and gfsh-dependencies.jar to the system classpath and adding that
> to the server, that is what is shown in logs
> Class Path:
> C:\DEV\Pivotal\GemFire_v82014\lib\gemfire.jar
> C:\DEV\Pivotal\GemFire_v82014\lib\gfsh-dependencies.jar
>
> ………..
> C:\Program Files\Java\jdk1.7.0_67\lib\tools.jar
> C:\DEV\Pivotal\GemFire_v82014\lib\server-dependencies.jar
>
> start server \
> --name=${NAME} --server-port=${PORT} \
> --properties-file=${GEMFIRE_PWD}/resources/cache.properties \
> --J=-Dgemfire.distributed-system-id=${DISTRIBUTED_SYSTEM_ID} \
> --J=-Dgemfire.bind-address=${HOST_NAME}
> --J=-Dgemfire.server-bind-address=${HOST_NAME} \
> --J=-Dgemfire.locators=${HOST_NAME}[${LOCATOR_PORT}] \
> --J=-Dgemfire.OSProcess.ENABLE_OUTPUT_REDIRECTION=true \
> --include-system-classpath
>
> If I don’t pass this parameter, then it does not add gfsh-dependencies
> Class Path:
> C:\DEV\Pivotal\GemFire_v82014\lib\gemfire.jar
> C:\DEV\Pivotal\GemFire_v82014\lib\server-dependencies.jar
>
> I am trying to do testing without using –include-system-classpath instead add
> jars in to the start server –classpath as a work around.
> {noformat}
> And a subsequent reply from John Blum:
> {noformat}
> My apologies. I was not aware that you were launching your GemFire process
> (e.g. Server) using Gfsh, and specifically with gfsh.bat on Windows.
> I just confirmed the line(s) you were looking at in gfsh.bat, and indeed the
> BAT file is wrong! Specifically, the classpath for the GemFire process
> is being constructed from the following lines...
> @set
> GEMFIRE_JARS=%GEMFIRE%\lib\gemfire.jar;%GEMFIRE%\lib\antlr.jar;%GEMFIRE%\lib\gfsh-dependencies.jar;%GEMFIRE%\lib\pulse-dependencies.jar
> ...
> @set GFSH_JARS=;%GEMFIRE%\lib\gfsh-dependencies.jar
> @set CLASSPATH=%GFSH_JARS%;%GEMFIRE_JARS%
> The Windows BAT file is also inconsistent with the Bash shell version (gfsh),
> which rightfully only contains...
> GEMFIRE_JARS=$GEMFIRE/lib/gfsh-dependencies.jar
> if [ "x$CLASSPATH" != "x" ]; then
> GEMFIRE_JARS=$GEMFIRE_JARS:$CLASSPATH
> fi
> CLASSPATH=$GEMFIRE_JARS
> In addition, the Bash shell version launches the Gfsh process using the java
> -classpath option...
> "$GF_JAVA" -Dgfsh=true
> -Dlog4j.configurationFile=/com/gemstone/gemfire/internal/logging/log4j/log4j2-cli.xml
> ${JLINE_TERMINAL} -classpath "${CLASSPATH}" $JAVA_ARGS $LAUNCHER "$@"
> Which does not "export", or rather, set the global System CLASSPATH
> environment variable. Here it is only setting the Java System property
> to the Java process, where as, I believe, the Window BAT file is actually
> setting the System CLASSPATH
[jira] [Updated] (GEODE-985) gfsh help text: rebrand for open source
[ https://issues.apache.org/jira/browse/GEODE-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe updated GEODE-985: - Component/s: docs > gfsh help text: rebrand for open source > --- > > Key: GEODE-985 > URL: https://issues.apache.org/jira/browse/GEODE-985 > Project: Geode > Issue Type: Bug > Components: docs, gfsh >Reporter: Dave Barnes > > The gfsh help text is full of Gemfire references. Needs rewriting to be > generic to both Gemfire and Geode. > See > gemfire-core/src/main/java/com/gemstone/gemfire/management/internal/cli/i18n/CliStrings.java -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-1408) gfsh help alter region output defaults say "__DEFAULT__"
[
https://issues.apache.org/jira/browse/GEODE-1408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-1408:
--
Component/s: docs
> gfsh help alter region output defaults say "__DEFAULT__"
>
>
> Key: GEODE-1408
> URL: https://issues.apache.org/jira/browse/GEODE-1408
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh
>Reporter: Karen Smoler Miller
>
> To observe, see the output of `gfsh help alter region`.
> The specification of the default for several options is the string
> {noformat}__DEFAULT__{noformat}
> This string is wrong.
> The options that show this string are
> - entry-idle-time-expiration-action
> - entry-time-to-live-expiration-action
> - region-idle-time-expiration-action
> - region-time-to-live-expiration-action
> - cache-loader
> - cache-writer
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (GEODE-1331) gfsh.bat on Windows is incorrect
[
https://issues.apache.org/jira/browse/GEODE-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Duling reassigned GEODE-1331:
---
Assignee: Kevin Duling
> gfsh.bat on Windows is incorrect
>
>
> Key: GEODE-1331
> URL: https://issues.apache.org/jira/browse/GEODE-1331
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Kevin Duling
> Fix For: 1.0.0-incubating.M3
>
>
> Initial report:
> {noformat}
> I am doing testing in windows STS. I am not adding these dependencies jars,
> gfsh.bat is what doing this.
>
> C:\DEV\Pivotal\GemFire_v82014\bin\gfsh.bat has below code, which is setting
> gemfire, antlr, gfsh-dependencies and pulse-dependencies jars in classpath.
> Line 26 to 29
> @set
> GEMFIRE_JARS=%GEMFIRE%\lib\gemfire.jar;%GEMFIRE%\lib\antlr.jar;%GEMFIRE%\lib\gfsh-dependencies.jar;%GEMFIRE%\lib\pulse-dependencies.jar
> @if defined CLASSPATH (
> @set GEMFIRE_JARS=%GEMFIRE_JARS%;%CLASSPATH%
> )
> C:\DEV\Pivotal\GemFire_v82014\lib\gemfire.jar // DUPLICATE
> C:\DEV\Pivotal\GemFire_v82014\lib\antlr.jar
> C:\DEV\Pivotal\GemFire_v82014\lib\gfsh-dependencies.jar // DUPLICATE
> C:\DEV\Pivotal\GemFire_v82014\lib\pulse-dependencies.jar
>
> Unix C:\DEV\Pivotal\GemFire_v82014\bin script, does not set these jars in
> classpath.
>
>
> Another observation is that, if I pass --include-system-classpath to gfsh
> start server command, then it is prepending
> gemfire.jar and gfsh-dependencies.jar to the system classpath and adding that
> to the server, that is what is shown in logs
> Class Path:
> C:\DEV\Pivotal\GemFire_v82014\lib\gemfire.jar
> C:\DEV\Pivotal\GemFire_v82014\lib\gfsh-dependencies.jar
>
> ………..
> C:\Program Files\Java\jdk1.7.0_67\lib\tools.jar
> C:\DEV\Pivotal\GemFire_v82014\lib\server-dependencies.jar
>
> start server \
> --name=${NAME} --server-port=${PORT} \
> --properties-file=${GEMFIRE_PWD}/resources/cache.properties \
> --J=-Dgemfire.distributed-system-id=${DISTRIBUTED_SYSTEM_ID} \
> --J=-Dgemfire.bind-address=${HOST_NAME}
> --J=-Dgemfire.server-bind-address=${HOST_NAME} \
> --J=-Dgemfire.locators=${HOST_NAME}[${LOCATOR_PORT}] \
> --J=-Dgemfire.OSProcess.ENABLE_OUTPUT_REDIRECTION=true \
> --include-system-classpath
>
> If I don’t pass this parameter, then it does not add gfsh-dependencies
> Class Path:
> C:\DEV\Pivotal\GemFire_v82014\lib\gemfire.jar
> C:\DEV\Pivotal\GemFire_v82014\lib\server-dependencies.jar
>
> I am trying to do testing without using –include-system-classpath instead add
> jars in to the start server –classpath as a work around.
> {noformat}
> And a subsequent reply from John Blum:
> {noformat}
> My apologies. I was not aware that you were launching your GemFire process
> (e.g. Server) using Gfsh, and specifically with gfsh.bat on Windows.
> I just confirmed the line(s) you were looking at in gfsh.bat, and indeed the
> BAT file is wrong! Specifically, the classpath for the GemFire process
> is being constructed from the following lines...
> @set
> GEMFIRE_JARS=%GEMFIRE%\lib\gemfire.jar;%GEMFIRE%\lib\antlr.jar;%GEMFIRE%\lib\gfsh-dependencies.jar;%GEMFIRE%\lib\pulse-dependencies.jar
> ...
> @set GFSH_JARS=;%GEMFIRE%\lib\gfsh-dependencies.jar
> @set CLASSPATH=%GFSH_JARS%;%GEMFIRE_JARS%
> The Windows BAT file is also inconsistent with the Bash shell version (gfsh),
> which rightfully only contains...
> GEMFIRE_JARS=$GEMFIRE/lib/gfsh-dependencies.jar
> if [ "x$CLASSPATH" != "x" ]; then
> GEMFIRE_JARS=$GEMFIRE_JARS:$CLASSPATH
> fi
> CLASSPATH=$GEMFIRE_JARS
> In addition, the Bash shell version launches the Gfsh process using the java
> -classpath option...
> "$GF_JAVA" -Dgfsh=true
> -Dlog4j.configurationFile=/com/gemstone/gemfire/internal/logging/log4j/log4j2-cli.xml
> ${JLINE_TERMINAL} -classpath "${CLASSPATH}" $JAVA_ARGS $LAUNCHER "$@"
> Which does not "export", or rather, set the global System CLASSPATH
> environment variable. Here it is only setting the Java System property
> to the Java process, where as, I believe, the Window BAT file is actually
> setting the System CLASSPATH environment variable, since there is no
> java -classpath option present in the command to launch Gfsh...
> @"%GF_JAVA%" -Dgfsh=true
> -Dlog4j.configurationFile=/com/gemstone/gemfire/internal/logging/log4j/log4j2-cli.xml
> %JAVA_ARGS% %LAUNCHER% %*
> Regarding...
> > I think we need Pivotal Engineering team to look into gfsh.bat and
> > –include-system-classpath behavior.
> Not exactly. --include-system-classpath basically functions such that it
> appends the value of the System CLASSPATH environment variable
> to the forked GemFire process launched from Gfsh if the user has set the
> global variable per environment and wishes to use it.
> In a nutshell, GemFire documentation use to erroneously recommend users to
> set
[jira] [Commented] (GEODE-1456) CI Failure: GemFireCacheImplTest.checkThatAsyncEventListenersUseAllThreadsInPool
[ https://issues.apache.org/jira/browse/GEODE-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300639#comment-15300639 ] Darrel Schneider commented on GEODE-1456: - The unit test has a race in it. The problem is that when the GemFireCacheImpl is created is always create a pdx TypeRegistry. The TypeRegistry creates a region which cause an async event to be scheduled. The race in the test is with this async event. If it did not complete early then it can cause the completedTaskCount that the test expects to be one more than it expects. So it never sees the count it expects and fails. > CI Failure: > GemFireCacheImplTest.checkThatAsyncEventListenersUseAllThreadsInPool > > > Key: GEODE-1456 > URL: https://issues.apache.org/jira/browse/GEODE-1456 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Darrel Schneider >Assignee: Darrel Schneider > Labels: CI > > com.gemstone.gemfire.internal.cache.GemFireCacheImplTest > > checkThatAsyncEventListenersUseAllThreadsInPool FAILED > com.jayway.awaitility.core.ConditionTimeoutException: Condition with > lambda expression in com.gemstone.gemfire.internal.cache.GemFireCacheImplTest > that uses java.util.concurrent.ThreadPoolExecutor, > java.util.concurrent.ThreadPoolExecutorint, intlong was not fulfilled within > 15 seconds. > at > com.jayway.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:122) > at > com.jayway.awaitility.core.CallableCondition.await(CallableCondition.java:79) > at > com.jayway.awaitility.core.CallableCondition.await(CallableCondition.java:27) > at > com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:764) > at > com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:741) > at > com.gemstone.gemfire.internal.cache.GemFireCacheImplTest.checkThatAsyncEventListenersUseAllThreadsInPool(GemFireCacheImplTest.java:60) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (GEODE-1456) CI Failure: GemFireCacheImplTest.checkThatAsyncEventListenersUseAllThreadsInPool
[ https://issues.apache.org/jira/browse/GEODE-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-1456: --- Assignee: Darrel Schneider > CI Failure: > GemFireCacheImplTest.checkThatAsyncEventListenersUseAllThreadsInPool > > > Key: GEODE-1456 > URL: https://issues.apache.org/jira/browse/GEODE-1456 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Darrel Schneider >Assignee: Darrel Schneider > Labels: CI > > com.gemstone.gemfire.internal.cache.GemFireCacheImplTest > > checkThatAsyncEventListenersUseAllThreadsInPool FAILED > com.jayway.awaitility.core.ConditionTimeoutException: Condition with > lambda expression in com.gemstone.gemfire.internal.cache.GemFireCacheImplTest > that uses java.util.concurrent.ThreadPoolExecutor, > java.util.concurrent.ThreadPoolExecutorint, intlong was not fulfilled within > 15 seconds. > at > com.jayway.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:122) > at > com.jayway.awaitility.core.CallableCondition.await(CallableCondition.java:79) > at > com.jayway.awaitility.core.CallableCondition.await(CallableCondition.java:27) > at > com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:764) > at > com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:741) > at > com.gemstone.gemfire.internal.cache.GemFireCacheImplTest.checkThatAsyncEventListenersUseAllThreadsInPool(GemFireCacheImplTest.java:60) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1296) OffHeapStoredObject.getRawBytes should assert that it is not called on compressed data
[
https://issues.apache.org/jira/browse/GEODE-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300493#comment-15300493
]
ASF GitHub Bot commented on GEODE-1296:
---
Github user dschneider-pivotal commented on the pull request:
https://github.com/apache/incubator-geode/pull/145#issuecomment-221650434
The travis failure is a know intermittent issue in a new unit test.
This change looks good. I will pull it in.
> OffHeapStoredObject.getRawBytes should assert that it is not called on
> compressed data
> --
>
> Key: GEODE-1296
> URL: https://issues.apache.org/jira/browse/GEODE-1296
> Project: Geode
> Issue Type: Bug
> Components: offheap
>Reporter: Darrel Schneider
>Assignee: Kenneth Howe
>
> The current code does this:
> if (isCompressed()) {
> throw new UnsupportedOperationException();
> }
> It would be more clear if it just did this:
> assert !isCompressed();
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-1458) Sequence logger thread can die on startup and should not be enabled by default
[ https://issues.apache.org/jira/browse/GEODE-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith updated GEODE-1458: - Fix Version/s: 1.0.0-incubating.M3 > Sequence logger thread can die on startup and should not be enabled by default > -- > > Key: GEODE-1458 > URL: https://issues.apache.org/jira/browse/GEODE-1458 > Project: Geode > Issue Type: Bug >Reporter: Dan Smith >Assignee: Dan Smith > Fix For: 1.0.0-incubating.M3 > > > The SequenceLoggerImpl class always creates a thread in the static block. > However, if the logger class is loaded before the cache, the thread dies > immediately. > Since sequence logging is usually not enabled, we shouldn't even start this > thread unless it is enabled and in that case it should not die if a cache is > not present. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (GEODE-1458) Sequence logger thread can die on startup and should not be enabled by default
[ https://issues.apache.org/jira/browse/GEODE-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith reassigned GEODE-1458: Assignee: Dan Smith > Sequence logger thread can die on startup and should not be enabled by default > -- > > Key: GEODE-1458 > URL: https://issues.apache.org/jira/browse/GEODE-1458 > Project: Geode > Issue Type: Bug >Reporter: Dan Smith >Assignee: Dan Smith > Fix For: 1.0.0-incubating.M3 > > > The SequenceLoggerImpl class always creates a thread in the static block. > However, if the logger class is loaded before the cache, the thread dies > immediately. > Since sequence logging is usually not enabled, we shouldn't even start this > thread unless it is enabled and in that case it should not die if a cache is > not present. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-1458) Sequence logger thread can die on startup and should not be enabled by default
[ https://issues.apache.org/jira/browse/GEODE-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-1458. -- Resolution: Fixed > Sequence logger thread can die on startup and should not be enabled by default > -- > > Key: GEODE-1458 > URL: https://issues.apache.org/jira/browse/GEODE-1458 > Project: Geode > Issue Type: Bug >Reporter: Dan Smith >Assignee: Dan Smith > > The SequenceLoggerImpl class always creates a thread in the static block. > However, if the logger class is loaded before the cache, the thread dies > immediately. > Since sequence logging is usually not enabled, we shouldn't even start this > thread unless it is enabled and in that case it should not die if a cache is > not present. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1458) Sequence logger thread can die on startup and should not be enabled by default
[ https://issues.apache.org/jira/browse/GEODE-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300450#comment-15300450 ] ASF subversion and git services commented on GEODE-1458: Commit 1d11d94dfe600b99007ccdc28f178d98fd86fd30 in incubator-geode's branch refs/heads/develop from [~upthewaterspout] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=1d11d94 ] GEODE-1458: Prevent sequence logger from launching and closing a thread The sequence logger code was launching a thread from a static block, even if it was not enabled. The thread was then immediately dying. Fixing the code to not launch the thread unless it is enabled, and to not die immediately if it is. > Sequence logger thread can die on startup and should not be enabled by default > -- > > Key: GEODE-1458 > URL: https://issues.apache.org/jira/browse/GEODE-1458 > Project: Geode > Issue Type: Bug >Reporter: Dan Smith > Fix For: 1.0.0-incubating.M3 > > > The SequenceLoggerImpl class always creates a thread in the static block. > However, if the logger class is loaded before the cache, the thread dies > immediately. > Since sequence logging is usually not enabled, we shouldn't even start this > thread unless it is enabled and in that case it should not die if a cache is > not present. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-1428) Cache close will log a warning and not dispatch the cache close event if the sys prop gemfire.Cache.ASYNC_EVENT_LISTENERS is set to true
[
https://issues.apache.org/jira/browse/GEODE-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-1428.
-
Resolution: Fixed
Fix Version/s: 1.0.0-incubating.M3
> Cache close will log a warning and not dispatch the cache close event if the
> sys prop gemfire.Cache.ASYNC_EVENT_LISTENERS is set to true
>
>
> Key: GEODE-1428
> URL: https://issues.apache.org/jira/browse/GEODE-1428
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
> Fix For: 1.0.0-incubating.M3
>
>
> If you enable async cache listeners then during cache close the dispatch of
> the cache close event will be rejected because the pool has already shutdown.
> The code that uses the async pool currently catches
> RejectedExecutionException and logs it. It should instead just do a
> synchronous invocation of the listener.
> Here is the stack you will see:
> [warn 2016/05/20 17:16:07.107 PDT tid=0x1] {0} Event not dispatched
> due to rejected execution
> java.util.concurrent.RejectedExecutionException: executor has been shutdown
> at
> com.gemstone.gemfire.distributed.internal.PooledExecutorWithDMStats$BufferHandler.rejectedExecution(PooledExecutorWithDMStats.java:220)
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> at
> com.gemstone.gemfire.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:7591)
> at
> com.gemstone.gemfire.internal.cache.LocalRegion.sendPendingRegionDestroyEvents(LocalRegion.java:7850)
> at
> com.gemstone.gemfire.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6853)
> at
> com.gemstone.gemfire.internal.cache.DistributedRegion.basicDestroyRegion(DistributedRegion.java:1917)
> at
> com.gemstone.gemfire.internal.cache.LocalRegion.handleCacheClose(LocalRegion.java:7934)
> at
> com.gemstone.gemfire.internal.cache.DistributedRegion.handleCacheClose(DistributedRegion.java:2825)
> at
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2149)
> at
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1856)
> at
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1852)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1428) Cache close will log a warning and not dispatch the cache close event if the sys prop gemfire.Cache.ASYNC_EVENT_LISTENERS is set to true
[
https://issues.apache.org/jira/browse/GEODE-1428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300436#comment-15300436
]
ASF subversion and git services commented on GEODE-1428:
Commit fa6e722e727a6f40788014aa6cac17890f6a64c9 in incubator-geode's branch
refs/heads/develop from [~dschneider]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=fa6e722 ]
GEODE-1428: deliver event synchronously if it is rejected
Changed unit test to use close instead of emergencyClose.
Doing this caused an event to be sent after the async thread
pool was shutdown which resulted in a suspect warning without
this fix.
> Cache close will log a warning and not dispatch the cache close event if the
> sys prop gemfire.Cache.ASYNC_EVENT_LISTENERS is set to true
>
>
> Key: GEODE-1428
> URL: https://issues.apache.org/jira/browse/GEODE-1428
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>
> If you enable async cache listeners then during cache close the dispatch of
> the cache close event will be rejected because the pool has already shutdown.
> The code that uses the async pool currently catches
> RejectedExecutionException and logs it. It should instead just do a
> synchronous invocation of the listener.
> Here is the stack you will see:
> [warn 2016/05/20 17:16:07.107 PDT tid=0x1] {0} Event not dispatched
> due to rejected execution
> java.util.concurrent.RejectedExecutionException: executor has been shutdown
> at
> com.gemstone.gemfire.distributed.internal.PooledExecutorWithDMStats$BufferHandler.rejectedExecution(PooledExecutorWithDMStats.java:220)
> at
> java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:823)
> at
> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1369)
> at
> com.gemstone.gemfire.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:7591)
> at
> com.gemstone.gemfire.internal.cache.LocalRegion.sendPendingRegionDestroyEvents(LocalRegion.java:7850)
> at
> com.gemstone.gemfire.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6853)
> at
> com.gemstone.gemfire.internal.cache.DistributedRegion.basicDestroyRegion(DistributedRegion.java:1917)
> at
> com.gemstone.gemfire.internal.cache.LocalRegion.handleCacheClose(LocalRegion.java:7934)
> at
> com.gemstone.gemfire.internal.cache.DistributedRegion.handleCacheClose(DistributedRegion.java:2825)
> at
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2149)
> at
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1856)
> at
> com.gemstone.gemfire.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:1852)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (GEODE-1458) Sequence logger thread can die on startup and should not be enabled by default
Dan Smith created GEODE-1458: Summary: Sequence logger thread can die on startup and should not be enabled by default Key: GEODE-1458 URL: https://issues.apache.org/jira/browse/GEODE-1458 Project: Geode Issue Type: Bug Reporter: Dan Smith The SequenceLoggerImpl class always creates a thread in the static block. However, if the logger class is loaded before the cache, the thread dies immediately. Since sequence logging is usually not enabled, we shouldn't even start this thread unless it is enabled and in that case it should not die if a cache is not present. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1425) PartitionRegionHelper local data methods return a Region whose get(key, callbackArg) method does not correctly handle the callback argument
[ https://issues.apache.org/jira/browse/GEODE-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300430#comment-15300430 ] ASF subversion and git services commented on GEODE-1425: Commit cae8f7fecf893ea4a31f7b06c22130fb646407bb in incubator-geode's branch refs/heads/develop from [~dschneider] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=cae8f7f ] GEODE-1425: fix callback arg parameter order > PartitionRegionHelper local data methods return a Region whose get(key, > callbackArg) method does not correctly handle the callback argument > --- > > Key: GEODE-1425 > URL: https://issues.apache.org/jira/browse/GEODE-1425 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Darrel Schneider > Fix For: 1.0.0-incubating.M3 > > > PartitionRegionHelper has the methods: getLocalData and getLocalPrimaryData. > They both return an instance of Region. > The get(key, callbackArg) does not do the following with the callbackArg: > 1. It does not check if the callbackArg is an instanceof PartitionResolver. > So you can not use the callbackArg in this case to specify the resolver. > Instead use the resolver region attribute or the key. > 2. The EntryOperation passed to the resolver getRoutingObject method will > return the callbackArg from getNewValue and null from getCallbackArgument and > false from isCallbackArgumentAvailable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (GEODE-1425) PartitionRegionHelper local data methods return a Region whose get(key, callbackArg) method does not correctly handle the callback argument
[ https://issues.apache.org/jira/browse/GEODE-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-1425: --- Assignee: Darrel Schneider > PartitionRegionHelper local data methods return a Region whose get(key, > callbackArg) method does not correctly handle the callback argument > --- > > Key: GEODE-1425 > URL: https://issues.apache.org/jira/browse/GEODE-1425 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Darrel Schneider >Assignee: Darrel Schneider > Fix For: 1.0.0-incubating.M3 > > > PartitionRegionHelper has the methods: getLocalData and getLocalPrimaryData. > They both return an instance of Region. > The get(key, callbackArg) does not do the following with the callbackArg: > 1. It does not check if the callbackArg is an instanceof PartitionResolver. > So you can not use the callbackArg in this case to specify the resolver. > Instead use the resolver region attribute or the key. > 2. The EntryOperation passed to the resolver getRoutingObject method will > return the callbackArg from getNewValue and null from getCallbackArgument and > false from isCallbackArgumentAvailable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-1425) PartitionRegionHelper local data methods return a Region whose get(key, callbackArg) method does not correctly handle the callback argument
[ https://issues.apache.org/jira/browse/GEODE-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-1425. - Resolution: Fixed Fix Version/s: 1.0.0-incubating.M3 > PartitionRegionHelper local data methods return a Region whose get(key, > callbackArg) method does not correctly handle the callback argument > --- > > Key: GEODE-1425 > URL: https://issues.apache.org/jira/browse/GEODE-1425 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Darrel Schneider >Assignee: Darrel Schneider > Fix For: 1.0.0-incubating.M3 > > > PartitionRegionHelper has the methods: getLocalData and getLocalPrimaryData. > They both return an instance of Region. > The get(key, callbackArg) does not do the following with the callbackArg: > 1. It does not check if the callbackArg is an instanceof PartitionResolver. > So you can not use the callbackArg in this case to specify the resolver. > Instead use the resolver region attribute or the key. > 2. The EntryOperation passed to the resolver getRoutingObject method will > return the callbackArg from getNewValue and null from getCallbackArgument and > false from isCallbackArgumentAvailable -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-1413) ParallelGatewaySenderOperationsDUnitTest.testParallelPropagationSenderStartAfterStop_Scenario2
[
https://issues.apache.org/jira/browse/GEODE-1413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith updated GEODE-1413:
-
Assignee: nabarun
> ParallelGatewaySenderOperationsDUnitTest.testParallelPropagationSenderStartAfterStop_Scenario2
> --
>
> Key: GEODE-1413
> URL: https://issues.apache.org/jira/browse/GEODE-1413
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Sai Boorlagadda
>Assignee: nabarun
> Labels: CI
>
> {noformat}
> Error Message
> com.gemstone.gemfire.test.dunit.RMIException: While invoking
> com.gemstone.gemfire.internal.cache.wan.parallel.ParallelGatewaySenderOperationsDUnitTest$$Lambda$1041/2063794856.run
> in VM 4 running on Host zambia.gemstone.com with 8 VMs
> Stacktrace
> com.gemstone.gemfire.test.dunit.RMIException: While invoking
> com.gemstone.gemfire.internal.cache.wan.parallel.ParallelGatewaySenderOperationsDUnitTest$$Lambda$1041/2063794856.run
> in VM 4 running on Host zambia.gemstone.com with 8 VMs
> at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:389)
> at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:355)
> at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:293)
> at
> com.gemstone.gemfire.internal.cache.wan.parallel.ParallelGatewaySenderOperationsDUnitTest.testParallelPropagationSenderStartAfterStop_Scenario2(ParallelGatewaySenderOperationsDUnitTest.java:358)
> 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:112)
> 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:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java: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: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: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$W
[jira] [Updated] (GEODE-1456) CI Failure: GemFireCacheImplTest.checkThatAsyncEventListenersUseAllThreadsInPool
[ https://issues.apache.org/jira/browse/GEODE-1456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-1456: Labels: CI (was: ) > CI Failure: > GemFireCacheImplTest.checkThatAsyncEventListenersUseAllThreadsInPool > > > Key: GEODE-1456 > URL: https://issues.apache.org/jira/browse/GEODE-1456 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Darrel Schneider > Labels: CI > > com.gemstone.gemfire.internal.cache.GemFireCacheImplTest > > checkThatAsyncEventListenersUseAllThreadsInPool FAILED > com.jayway.awaitility.core.ConditionTimeoutException: Condition with > lambda expression in com.gemstone.gemfire.internal.cache.GemFireCacheImplTest > that uses java.util.concurrent.ThreadPoolExecutor, > java.util.concurrent.ThreadPoolExecutorint, intlong was not fulfilled within > 15 seconds. > at > com.jayway.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:122) > at > com.jayway.awaitility.core.CallableCondition.await(CallableCondition.java:79) > at > com.jayway.awaitility.core.CallableCondition.await(CallableCondition.java:27) > at > com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:764) > at > com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:741) > at > com.gemstone.gemfire.internal.cache.GemFireCacheImplTest.checkThatAsyncEventListenersUseAllThreadsInPool(GemFireCacheImplTest.java:60) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-1456) CI Failure: GemFireCacheImplTest.checkThatAsyncEventListenersUseAllThreadsInPool
Darrel Schneider created GEODE-1456: --- Summary: CI Failure: GemFireCacheImplTest.checkThatAsyncEventListenersUseAllThreadsInPool Key: GEODE-1456 URL: https://issues.apache.org/jira/browse/GEODE-1456 Project: Geode Issue Type: Bug Components: regions Reporter: Darrel Schneider com.gemstone.gemfire.internal.cache.GemFireCacheImplTest > checkThatAsyncEventListenersUseAllThreadsInPool FAILED com.jayway.awaitility.core.ConditionTimeoutException: Condition with lambda expression in com.gemstone.gemfire.internal.cache.GemFireCacheImplTest that uses java.util.concurrent.ThreadPoolExecutor, java.util.concurrent.ThreadPoolExecutorint, intlong was not fulfilled within 15 seconds. at com.jayway.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:122) at com.jayway.awaitility.core.CallableCondition.await(CallableCondition.java:79) at com.jayway.awaitility.core.CallableCondition.await(CallableCondition.java:27) at com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:764) at com.jayway.awaitility.core.ConditionFactory.until(ConditionFactory.java:741) at com.gemstone.gemfire.internal.cache.GemFireCacheImplTest.checkThatAsyncEventListenersUseAllThreadsInPool(GemFireCacheImplTest.java:60) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-1457) Allow for starting a locator on an ephemeral port
[ https://issues.apache.org/jira/browse/GEODE-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe resolved GEODE-1457. --- Resolution: Fixed Fix Version/s: 1.0.0-incubating.M3 > Allow for starting a locator on an ephemeral port > - > > Key: GEODE-1457 > URL: https://issues.apache.org/jira/browse/GEODE-1457 > Project: Geode > Issue Type: Sub-task > Components: configuration >Reporter: Jens Deppe > Fix For: 1.0.0-incubating.M3 > > > When starting a locator with port == 0, the locator should start on an > ephemeral port. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1457) Allow for starting a locator on an ephemeral port
[ https://issues.apache.org/jira/browse/GEODE-1457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300385#comment-15300385 ] Jens Deppe commented on GEODE-1457: --- This was completed as the initial checkin for GEODE-1243 > Allow for starting a locator on an ephemeral port > - > > Key: GEODE-1457 > URL: https://issues.apache.org/jira/browse/GEODE-1457 > Project: Geode > Issue Type: Sub-task > Components: configuration >Reporter: Jens Deppe > Fix For: 1.0.0-incubating.M3 > > > When starting a locator with port == 0, the locator should start on an > ephemeral port. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-1457) Allow for starting a locator on an ephemeral port
Jens Deppe created GEODE-1457: - Summary: Allow for starting a locator on an ephemeral port Key: GEODE-1457 URL: https://issues.apache.org/jira/browse/GEODE-1457 Project: Geode Issue Type: Sub-task Components: configuration Reporter: Jens Deppe When starting a locator with port == 0, the locator should start on an ephemeral port. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1454) Have "region" attribute, in JSONAuthorization json file be an array
[ https://issues.apache.org/jira/browse/GEODE-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300335#comment-15300335 ] Jens Deppe commented on GEODE-1454: --- Dave, This is just an internal test change and doesn't require an doc updates. --Jens > Have "region" attribute, in JSONAuthorization json file be an array > --- > > Key: GEODE-1454 > URL: https://issues.apache.org/jira/browse/GEODE-1454 > Project: Geode > Issue Type: Task > Components: security >Reporter: Jens Deppe > > Currently the region attribute is defined as a comma separated list in string > form: > "regions": "region1,region2" > This should be converted to a JSON array. > This would also apply to ExampleJSONAuthorization -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-1454) Have "region" attribute, in JSONAuthorization json file be an array
[ https://issues.apache.org/jira/browse/GEODE-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe updated GEODE-1454: -- Component/s: (was: docs) > Have "region" attribute, in JSONAuthorization json file be an array > --- > > Key: GEODE-1454 > URL: https://issues.apache.org/jira/browse/GEODE-1454 > Project: Geode > Issue Type: Task > Components: security >Reporter: Jens Deppe > > Currently the region attribute is defined as a comma separated list in string > form: > "regions": "region1,region2" > This should be converted to a JSON array. > This would also apply to ExampleJSONAuthorization -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1296) OffHeapStoredObject.getRawBytes should assert that it is not called on compressed data
[
https://issues.apache.org/jira/browse/GEODE-1296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15300295#comment-15300295
]
ASF GitHub Bot commented on GEODE-1296:
---
Github user pdxrunner commented on the pull request:
https://github.com/apache/incubator-geode/pull/145#issuecomment-221624715
Precheckin passed with my most recent update. I think this one is ready to
go now.
> OffHeapStoredObject.getRawBytes should assert that it is not called on
> compressed data
> --
>
> Key: GEODE-1296
> URL: https://issues.apache.org/jira/browse/GEODE-1296
> Project: Geode
> Issue Type: Bug
> Components: offheap
>Reporter: Darrel Schneider
>Assignee: Kenneth Howe
>
> The current code does this:
> if (isCompressed()) {
> throw new UnsupportedOperationException();
> }
> It would be more clear if it just did this:
> assert !isCompressed();
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-1454) Have "region" attribute, in JSONAuthorization json file be an array
[ https://issues.apache.org/jira/browse/GEODE-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dave Barnes updated GEODE-1454: --- Component/s: docs > Have "region" attribute, in JSONAuthorization json file be an array > --- > > Key: GEODE-1454 > URL: https://issues.apache.org/jira/browse/GEODE-1454 > Project: Geode > Issue Type: Task > Components: docs, security >Reporter: Jens Deppe > > Currently the region attribute is defined as a comma separated list in string > form: > "regions": "region1,region2" > This should be converted to a JSON array. > This would also apply to ExampleJSONAuthorization -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-1455) Add SecurityTest JUnit category to outstanding gfsh / JMX security tests
Jens Deppe created GEODE-1455: - Summary: Add SecurityTest JUnit category to outstanding gfsh / JMX security tests Key: GEODE-1455 URL: https://issues.apache.org/jira/browse/GEODE-1455 Project: Geode Issue Type: Task Components: gfsh, jmx Reporter: Jens Deppe -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-1454) Have "region" attribute, in JSONAuthorization json file be an array
Jens Deppe created GEODE-1454: - Summary: Have "region" attribute, in JSONAuthorization json file be an array Key: GEODE-1454 URL: https://issues.apache.org/jira/browse/GEODE-1454 Project: Geode Issue Type: Task Reporter: Jens Deppe Currently the region attribute is defined as a comma separated list in string form: "regions": "region1,region2" This should be converted to a JSON array. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-1454) Have "region" attribute, in JSONAuthorization json file be an array
[ https://issues.apache.org/jira/browse/GEODE-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe updated GEODE-1454: -- Component/s: security > Have "region" attribute, in JSONAuthorization json file be an array > --- > > Key: GEODE-1454 > URL: https://issues.apache.org/jira/browse/GEODE-1454 > Project: Geode > Issue Type: Task > Components: security >Reporter: Jens Deppe > > Currently the region attribute is defined as a comma separated list in string > form: > "regions": "region1,region2" > This should be converted to a JSON array. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-1454) Have "region" attribute, in JSONAuthorization json file be an array
[ https://issues.apache.org/jira/browse/GEODE-1454?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jens Deppe updated GEODE-1454: -- Description: Currently the region attribute is defined as a comma separated list in string form: "regions": "region1,region2" This should be converted to a JSON array. This would also apply to ExampleJSONAuthorization was: Currently the region attribute is defined as a comma separated list in string form: "regions": "region1,region2" This should be converted to a JSON array. > Have "region" attribute, in JSONAuthorization json file be an array > --- > > Key: GEODE-1454 > URL: https://issues.apache.org/jira/browse/GEODE-1454 > Project: Geode > Issue Type: Task > Components: security >Reporter: Jens Deppe > > Currently the region attribute is defined as a comma separated list in string > form: > "regions": "region1,region2" > This should be converted to a JSON array. > This would also apply to ExampleJSONAuthorization -- This message was sent by Atlassian JIRA (v6.3.4#6332)
