[jira] [Updated] (GEODE-9397) Gfsh `deploy jar` should introspect, identify, and invoke/initialize all Declarable objects
[ https://issues.apache.org/jira/browse/GEODE-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-9397: - Priority: Minor (was: Major) > Gfsh `deploy jar` should introspect, identify, and invoke/initialize all > Declarable objects > --- > > Key: GEODE-9397 > URL: https://issues.apache.org/jira/browse/GEODE-9397 > Project: Geode > Issue Type: New Feature > Components: core >Affects Versions: 1.13.2 >Reporter: John Blum >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9397) Gfsh `deploy jar` should introspect, identify, and invoke/initialize all Declarable objects
[ https://issues.apache.org/jira/browse/GEODE-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17367703#comment-17367703 ] John Blum commented on GEODE-9397: -- This is actually a more generalized request to [GEODE-2083|https://issues.apache.org/jira/browse/GEODE-2083]. > Gfsh `deploy jar` should introspect, identify, and invoke/initialize all > Declarable objects > --- > > Key: GEODE-9397 > URL: https://issues.apache.org/jira/browse/GEODE-9397 > Project: Geode > Issue Type: New Feature > Components: core >Affects Versions: 1.13.2 >Reporter: John Blum >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9397) Gfsh `deploy jar` should introspect, identify, and invoke/initialize all Declarable objects
[ https://issues.apache.org/jira/browse/GEODE-9397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-9397: - Summary: Gfsh `deploy jar` should introspect, identify, and invoke/initialize all Declarable objects (was: Gfsh `deploy jar` should introspect, find, invoke and initialize all Declarable objects) > Gfsh `deploy jar` should introspect, identify, and invoke/initialize all > Declarable objects > --- > > Key: GEODE-9397 > URL: https://issues.apache.org/jira/browse/GEODE-9397 > Project: Geode > Issue Type: New Feature > Components: core >Affects Versions: 1.13.2 >Reporter: John Blum >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9397) Gfsh `deploy jar` should introspect, find, invoke and initialize all Declarable objects
John Blum created GEODE-9397: Summary: Gfsh `deploy jar` should introspect, find, invoke and initialize all Declarable objects Key: GEODE-9397 URL: https://issues.apache.org/jira/browse/GEODE-9397 Project: Geode Issue Type: New Feature Components: core Affects Versions: 1.13.2 Reporter: John Blum -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9393) Apache Geode does not run on Java 16
[
https://issues.apache.org/jira/browse/GEODE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-9393:
-
Priority: Blocker (was: Major)
> Apache Geode does not run on Java 16
>
>
> Key: GEODE-9393
> URL: https://issues.apache.org/jira/browse/GEODE-9393
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.13.2
>Reporter: John Blum
>Priority: Blocker
>
> Due to Java 16 tightened restrictions, Apache Geode fails to run on a Java 16
> Runtime (JRE).
> Exceptions like the following are thrown:
> {code}
> - org.apache.geode.InternalGemFireException: unable to retrieve underlying
> byte buffer
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> - at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> - at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> - at org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:100)
> - at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:256)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:306)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:511)
> - at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> - at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2050)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1978)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2015)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> - at
> org.apache.geode.distributed.internal.StartupMessage.process(StartupMessage.java:279)
> - at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> - at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:441)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doWaitingThread(ClusterOperationExecutors.java:410)
> - at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> - at java.base/java.lang.Thread.run(Thread.java:831)
> - Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @40f9161a
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> - at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> - at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
> - ... 22 common frames omitted
> - 2021-04-30 14:57:13,638 INFO ributed.internal.membership.gms.Services: 606
> - received leave request from
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> for
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> - 2021-04-30 14:57:13,640 INFO ributed.internal.membership.gms.Services: 617
> - JoinLeave.processMessage(LeaveRequestMessage) invoked. isCoordinator=true;
> isStopping=false; cancelInProgress=false
> - 2021-04-30 14:57:13,647 ERROR xecutors.LoggingUncaughtExceptionHandler: 92
> - Uncaught exception in thread Thread[P2P message reader for
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> shared unordered uid=1 local port=53039 remote port=64063,10,main]
> - org.apache.geode.InternalGemFireException: unable to retrieve underlying
> byte buffer
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> - at
> org.apache.geode.internal.net.BufferPool
[jira] [Updated] (GEODE-9395) Support Deltas with PDX serialization
[ https://issues.apache.org/jira/browse/GEODE-9395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-9395: - Summary: Support Deltas with PDX serialization (was: Support Deltas with PDX) > Support Deltas with PDX serialization > - > > Key: GEODE-9395 > URL: https://issues.apache.org/jira/browse/GEODE-9395 > Project: Geode > Issue Type: Improvement > Components: serialization >Affects Versions: 1.13.2 >Reporter: John Blum >Priority: Major > > While possible, it is not technically correct to do so, which is to implement > Deltas with PDX. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9394) Apache Geode does not properly cleanup it's SSL context between runs
[
https://issues.apache.org/jira/browse/GEODE-9394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-9394:
-
Priority: Critical (was: Major)
> Apache Geode does not properly cleanup it's SSL context between runs
>
>
> Key: GEODE-9394
> URL: https://issues.apache.org/jira/browse/GEODE-9394
> Project: Geode
> Issue Type: Bug
> Components: security
>Reporter: John Blum
>Priority: Critical
>
> Because Geode internally uses may statics to maintain state and to pass
> configuration between components in a non-Object Oriented fashion, I believe
> stale SSL configuration is being retained between Geode instance runs,
> leading to Exceptions thrown of the following nature:
> {code}
> Caused by: org.apache.geode.GemFireConfigException: Error configuring GemFire
> ssl
> at
> org.apache.geode.internal.net.SocketCreator.initialize(SocketCreator.java:249)
> at
> org.apache.geode.internal.net.SocketCreator.(SocketCreator.java:180)
> at
> org.apache.geode.internal.net.SocketCreatorFactory.createSSLSocketCreator(SocketCreatorFactory.java:114)
> at
> org.apache.geode.internal.net.SocketCreatorFactory.getSSLSocketCreator(SocketCreatorFactory.java:88)
> at
> org.apache.geode.internal.net.SocketCreatorFactory.getOrCreateSocketCreatorForSSLEnabledComponent(SocketCreatorFactory.java:104)
> at
> org.apache.geode.internal.net.SocketCreatorFactory.getSocketCreatorForComponent(SocketCreatorFactory.java:74)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.(ConnectionFactoryImpl.java:84)
> at
> org.apache.geode.cache.client.internal.PoolImpl.(PoolImpl.java:261)
> at
> org.apache.geode.cache.client.internal.PoolImpl.create(PoolImpl.java:161)
> at
> org.apache.geode.internal.cache.PoolFactoryImpl.create(PoolFactoryImpl.java:374)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.determineDefaultPool(GemFireCacheImpl.java:2835)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getDefaultPool(GemFireCacheImpl.java:1321)
> at
> org.apache.geode.cache.client.internal.ClientRegionFactoryImpl.getDefaultPool(ClientRegionFactoryImpl.java:101)
> at
> org.apache.geode.cache.client.internal.ClientRegionFactoryImpl.createRegionAttributes(ClientRegionFactoryImpl.java:249)
> at
> org.apache.geode.cache.client.internal.ClientRegionFactoryImpl.create(ClientRegionFactoryImpl.java:232)
> at
> org.springframework.data.gemfire.client.ClientRegionFactoryBean.newRegion(ClientRegionFactoryBean.java:193)
> at
> org.springframework.data.gemfire.client.ClientRegionFactoryBean.createRegion(ClientRegionFactoryBean.java:164)
> at
> org.springframework.data.gemfire.ResolvableRegionFactoryBean.afterPropertiesSet(ResolvableRegionFactoryBean.java:96)
> at
> org.springframework.data.gemfire.config.annotation.support.CacheTypeAwareRegionFactoryBean.newClientRegion(CacheTypeAwareRegionFactoryBean.java:181)
> at
> org.springframework.data.gemfire.config.annotation.support.CacheTypeAwareRegionFactoryBean.createRegion(CacheTypeAwareRegionFactoryBean.java:141)
> at
> org.springframework.data.gemfire.ResolvableRegionFactoryBean.afterPropertiesSet(ResolvableRegionFactoryBean.java:96)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1858)
> at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1795)
> ... 69 more
> Caused by: java.security.UnrecoverableKeyException: Password must not be null
> at
> sun.security.provider.JavaKeyStore.engineGetKey(JavaKeyStore.java:134)
> at
> sun.security.provider.JavaKeyStore$JKS.engineGetKey(JavaKeyStore.java:57)
> at
> sun.security.provider.KeyStoreDelegator.engineGetKey(KeyStoreDelegator.java:96)
> at
> sun.security.provider.JavaKeyStore$DualFormatJKS.engineGetKey(JavaKeyStore.java:71)
> at java.security.KeyStore.getKey(KeyStore.java:1023)
> at
> sun.security.ssl.SunX509KeyManagerImpl.(SunX509KeyManagerImpl.java:145)
> at
> sun.security.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:70)
> at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:256)
> at
> org.apache.geode.internal.net.SocketCreator.getKeyManagers(SocketCreator.java:422)
> at
> org.apache.geode.internal.net.SocketCreator.createAndConfigureSSLContext(SocketCreator.java:292)
> at
> org.apache.geode.internal.net.SocketCreator.initialize(SocketCreator.java:246)
> ... 91 more
> {code}
> In the StackTrace above, SSL was not even configured between the Geode client
[jira] [Created] (GEODE-9395) Support Deltas with PDX
John Blum created GEODE-9395: Summary: Support Deltas with PDX Key: GEODE-9395 URL: https://issues.apache.org/jira/browse/GEODE-9395 Project: Geode Issue Type: Improvement Components: serialization Affects Versions: 1.13.2 Reporter: John Blum While possible, it is not technically correct to do so, which is to implement Deltas with PDX. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9394) Apache Geode does not properly cleanup it's SSL context between runs
John Blum created GEODE-9394:
Summary: Apache Geode does not properly cleanup it's SSL context
between runs
Key: GEODE-9394
URL: https://issues.apache.org/jira/browse/GEODE-9394
Project: Geode
Issue Type: Bug
Components: security
Reporter: John Blum
Because Geode internally uses may statics to maintain state and to pass
configuration between components in a non-Object Oriented fashion, I believe
stale SSL configuration is being retained between Geode instance runs, leading
to Exceptions thrown of the following nature:
{code}
Caused by: org.apache.geode.GemFireConfigException: Error configuring GemFire
ssl
at
org.apache.geode.internal.net.SocketCreator.initialize(SocketCreator.java:249)
at
org.apache.geode.internal.net.SocketCreator.(SocketCreator.java:180)
at
org.apache.geode.internal.net.SocketCreatorFactory.createSSLSocketCreator(SocketCreatorFactory.java:114)
at
org.apache.geode.internal.net.SocketCreatorFactory.getSSLSocketCreator(SocketCreatorFactory.java:88)
at
org.apache.geode.internal.net.SocketCreatorFactory.getOrCreateSocketCreatorForSSLEnabledComponent(SocketCreatorFactory.java:104)
at
org.apache.geode.internal.net.SocketCreatorFactory.getSocketCreatorForComponent(SocketCreatorFactory.java:74)
at
org.apache.geode.cache.client.internal.ConnectionFactoryImpl.(ConnectionFactoryImpl.java:84)
at
org.apache.geode.cache.client.internal.PoolImpl.(PoolImpl.java:261)
at
org.apache.geode.cache.client.internal.PoolImpl.create(PoolImpl.java:161)
at
org.apache.geode.internal.cache.PoolFactoryImpl.create(PoolFactoryImpl.java:374)
at
org.apache.geode.internal.cache.GemFireCacheImpl.determineDefaultPool(GemFireCacheImpl.java:2835)
at
org.apache.geode.internal.cache.GemFireCacheImpl.getDefaultPool(GemFireCacheImpl.java:1321)
at
org.apache.geode.cache.client.internal.ClientRegionFactoryImpl.getDefaultPool(ClientRegionFactoryImpl.java:101)
at
org.apache.geode.cache.client.internal.ClientRegionFactoryImpl.createRegionAttributes(ClientRegionFactoryImpl.java:249)
at
org.apache.geode.cache.client.internal.ClientRegionFactoryImpl.create(ClientRegionFactoryImpl.java:232)
at
org.springframework.data.gemfire.client.ClientRegionFactoryBean.newRegion(ClientRegionFactoryBean.java:193)
at
org.springframework.data.gemfire.client.ClientRegionFactoryBean.createRegion(ClientRegionFactoryBean.java:164)
at
org.springframework.data.gemfire.ResolvableRegionFactoryBean.afterPropertiesSet(ResolvableRegionFactoryBean.java:96)
at
org.springframework.data.gemfire.config.annotation.support.CacheTypeAwareRegionFactoryBean.newClientRegion(CacheTypeAwareRegionFactoryBean.java:181)
at
org.springframework.data.gemfire.config.annotation.support.CacheTypeAwareRegionFactoryBean.createRegion(CacheTypeAwareRegionFactoryBean.java:141)
at
org.springframework.data.gemfire.ResolvableRegionFactoryBean.afterPropertiesSet(ResolvableRegionFactoryBean.java:96)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.invokeInitMethods(AbstractAutowireCapableBeanFactory.java:1858)
at
org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1795)
... 69 more
Caused by: java.security.UnrecoverableKeyException: Password must not be null
at
sun.security.provider.JavaKeyStore.engineGetKey(JavaKeyStore.java:134)
at
sun.security.provider.JavaKeyStore$JKS.engineGetKey(JavaKeyStore.java:57)
at
sun.security.provider.KeyStoreDelegator.engineGetKey(KeyStoreDelegator.java:96)
at
sun.security.provider.JavaKeyStore$DualFormatJKS.engineGetKey(JavaKeyStore.java:71)
at java.security.KeyStore.getKey(KeyStore.java:1023)
at
sun.security.ssl.SunX509KeyManagerImpl.(SunX509KeyManagerImpl.java:145)
at
sun.security.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:70)
at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:256)
at
org.apache.geode.internal.net.SocketCreator.getKeyManagers(SocketCreator.java:422)
at
org.apache.geode.internal.net.SocketCreator.createAndConfigureSSLContext(SocketCreator.java:292)
at
org.apache.geode.internal.net.SocketCreator.initialize(SocketCreator.java:246)
... 91 more
{code}
In the StackTrace above, SSL was not even configured between the Geode client
and server even though Geode thinks it was.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9393) Apache Geode does not run on Java 16
[
https://issues.apache.org/jira/browse/GEODE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17367646#comment-17367646
]
John Blum commented on GEODE-9393:
--
Also see [question/discussion|http://markmail.org/message/7gzlhmu2rbnjkrri] on
the Apache Geode developer mailing list.
> Apache Geode does not run on Java 16
>
>
> Key: GEODE-9393
> URL: https://issues.apache.org/jira/browse/GEODE-9393
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.13.2
>Reporter: John Blum
>Priority: Major
>
> Due to Java 16 tightened restrictions, Apache Geode fails to run on a Java 16
> Runtime (JRE).
> Exceptions like the following are thrown:
> {code}
> - org.apache.geode.InternalGemFireException: unable to retrieve underlying
> byte buffer
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> - at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> - at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> - at org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:100)
> - at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:256)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:306)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:511)
> - at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> - at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2050)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1978)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2015)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> - at
> org.apache.geode.distributed.internal.StartupMessage.process(StartupMessage.java:279)
> - at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> - at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:441)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doWaitingThread(ClusterOperationExecutors.java:410)
> - at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> - at java.base/java.lang.Thread.run(Thread.java:831)
> - Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @40f9161a
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> - at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> - at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
> - ... 22 common frames omitted
> - 2021-04-30 14:57:13,638 INFO ributed.internal.membership.gms.Services: 606
> - received leave request from
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> for
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> - 2021-04-30 14:57:13,640 INFO ributed.internal.membership.gms.Services: 617
> - JoinLeave.processMessage(LeaveRequestMessage) invoked. isCoordinator=true;
> isStopping=false; cancelInProgress=false
> - 2021-04-30 14:57:13,647 ERROR xecutors.LoggingUncaughtExceptionHandler: 92
> - Uncaught exception in thread Thread[P2P message reader for
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> shared unordered uid=1 local port=53039 remote port=64063,10,main]
> - org.apache.geode.InternalGemFireException: unable to retrieve underlying
> byte buffer
>
[jira] [Commented] (GEODE-9393) Apache Geode does not run on Java 16
[
https://issues.apache.org/jira/browse/GEODE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17367645#comment-17367645
]
John Blum commented on GEODE-9393:
--
While declaring/specifying the {{--add-opens}} JVM option is a temporary
workaround (to an extent), this is not a good long-term solution.
Additionally, declaring the {{--add-opens}} JVM option does not work with
Java's {{Runtime}} API.
> Apache Geode does not run on Java 16
>
>
> Key: GEODE-9393
> URL: https://issues.apache.org/jira/browse/GEODE-9393
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.13.2
>Reporter: John Blum
>Priority: Major
>
> Due to Java 16 tightened restrictions, Apache Geode fails to run on a Java 16
> Runtime (JRE).
> Exceptions like the following are thrown:
> {code}
> - org.apache.geode.InternalGemFireException: unable to retrieve underlying
> byte buffer
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> - at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> - at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> - at org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:100)
> - at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:256)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:306)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:511)
> - at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> - at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2050)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1978)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2015)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> - at
> org.apache.geode.distributed.internal.StartupMessage.process(StartupMessage.java:279)
> - at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> - at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:441)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doWaitingThread(ClusterOperationExecutors.java:410)
> - at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> - at java.base/java.lang.Thread.run(Thread.java:831)
> - Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @40f9161a
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> - at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> - at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
> - ... 22 common frames omitted
> - 2021-04-30 14:57:13,638 INFO ributed.internal.membership.gms.Services: 606
> - received leave request from
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> for
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> - 2021-04-30 14:57:13,640 INFO ributed.internal.membership.gms.Services: 617
> - JoinLeave.processMessage(LeaveRequestMessage) invoked. isCoordinator=true;
> isStopping=false; cancelInProgress=false
> - 2021-04-30 14:57:13,647 ERROR xecutors.LoggingUncaughtExceptionHandler: 92
> - Uncaught exception in thread Thread[P2P message reader for
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> shared unordered uid=1 local port=53039 r
[jira] [Created] (GEODE-9393) Apache Geode does not run on Java 16
John Blum created GEODE-9393:
Summary: Apache Geode does not run on Java 16
Key: GEODE-9393
URL: https://issues.apache.org/jira/browse/GEODE-9393
Project: Geode
Issue Type: Improvement
Components: core
Affects Versions: 1.13.2
Reporter: John Blum
Due to Java 16 tightened restrictions, Apache Geode fails to run on a Java 16
Runtime (JRE).
Exceptions like the following are thrown:
{code}
- org.apache.geode.InternalGemFireException: unable to retrieve underlying byte
buffer
- at
org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
- at
org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
- at
org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
- at org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:100)
- at
org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:256)
- at
org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:306)
- at
org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
- at
org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:511)
- at
org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
- at
org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
- at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2050)
- at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1978)
- at
org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2015)
- at
org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
- at
org.apache.geode.distributed.internal.StartupMessage.process(StartupMessage.java:279)
- at
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
- at
org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
- at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
- at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
- at
org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:441)
- at
org.apache.geode.distributed.internal.ClusterOperationExecutors.doWaitingThread(ClusterOperationExecutors.java:410)
- at
org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
- at java.base/java.lang.Thread.run(Thread.java:831)
- Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
module java.base does not "opens java.nio" to unnamed module @40f9161a
- at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
- at
java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
- at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
- at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
- at
org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
- ... 22 common frames omitted
- 2021-04-30 14:57:13,638 INFO ributed.internal.membership.gms.Services: 606 -
received leave request from
10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
for
10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
- 2021-04-30 14:57:13,640 INFO ributed.internal.membership.gms.Services: 617 -
JoinLeave.processMessage(LeaveRequestMessage) invoked. isCoordinator=true;
isStopping=false; cancelInProgress=false
- 2021-04-30 14:57:13,647 ERROR xecutors.LoggingUncaughtExceptionHandler: 92 -
Uncaught exception in thread Thread[P2P message reader for
10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
shared unordered uid=1 local port=53039 remote port=64063,10,main]
- org.apache.geode.InternalGemFireException: unable to retrieve underlying byte
buffer
- at
org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
- at
org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
- at
org.apache.geode.internal.net.BufferPool.releaseReceiveBuffer(BufferPool.java:217)
- at
org.apache.geode.internal.tcp.Connection.releaseInputBuffer(Connection.java:1512)
- at org.apache.geode.internal.tcp.Connection.run(Connection.java:1495)
- at java.base/java.lang.Thread.run(Thread.java:831)
- Caused by: java.lang.reflect.Inaccessi
[jira] [Updated] (GEODE-8286) The Geode JVM Shutdown Hook should not be enabled by default
[ https://issues.apache.org/jira/browse/GEODE-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-8286: - Issue Type: Bug (was: Improvement) > The Geode JVM Shutdown Hook should not be enabled by default > > > Key: GEODE-8286 > URL: https://issues.apache.org/jira/browse/GEODE-8286 > Project: Geode > Issue Type: Bug > Components: configuration, general, management >Reporter: John Blum >Priority: Critical > Labels: JSON-PDX > > Apache Geode registers a JVM Shutdown Hook in > [InternalDistributedSystem|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L2190-L] > that ensures the Apache Geode Cache and associated DistributedSystem are > shutdown properly when the JVM exits. > However, this JVM Shutdown Hook and interfere with Frameworks and Tooling > that have their own Lifecycle Management capabilities. The Spring Framework > and Container is one such example. > Any managed environment, be that Micronaut, Quarkus, Pivotal Platform > (PCF/TAS), Kubernetes, AWS, Azure, GCP, etc, etc, are going to have lifecycle > management capabilities. > It is very important that the environment manage the lifecycle of all actors > in the fully "integrated" system. > In Spring's case, it must coordinate the lifecycle of application components > along with integrated systems, like Geode, in an effort to shut all > components down in a coordinated, correct fashion. > If Geode's JVM Shutdown Hook is permitted to do as it pleases, then this can > circumvent the Framework/Container, Tool, or other's lifecycle management > capabilities, leaving the system or application in an inconsistent/incorrect > state. > To make matters worse, the [JVM System > Property|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L2191] > (and specifically, > [this|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L391-L392]) > controlling the enablement of the JVM Shutdown Hook, is non-public and [not > documented|https://geode.apache.org/docs/guide/112/reference/topics/gemfire_properties.html]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8618) OQL grammar specification in docs is incomplete
[
https://issues.apache.org/jira/browse/GEODE-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8618:
-
Issue Type: Bug (was: Improvement)
> OQL grammar specification in docs is incomplete
> ---
>
> Key: GEODE-8618
> URL: https://issues.apache.org/jira/browse/GEODE-8618
> Project: Geode
> Issue Type: Bug
> Components: docs, querying
>Affects Versions: 1.11.0, 1.12.0, 1.13.0
>Reporter: John Blum
>Priority: Minor
>
> For example, there are no rules for the {{ORDER BY}} and {{LIMIT}} clauses.
> Referring to this section in the docs:
> https://geode.apache.org/docs/guide/113/developing/querying_basics/query_grammar_and_reserved_words.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8618) OQL grammar specification in docs is incomplete
[
https://issues.apache.org/jira/browse/GEODE-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8618:
-
Priority: Major (was: Minor)
> OQL grammar specification in docs is incomplete
> ---
>
> Key: GEODE-8618
> URL: https://issues.apache.org/jira/browse/GEODE-8618
> Project: Geode
> Issue Type: Bug
> Components: docs, querying
>Affects Versions: 1.11.0, 1.12.0, 1.13.0
>Reporter: John Blum
>Priority: Major
>
> For example, there are no rules for the {{ORDER BY}} and {{LIMIT}} clauses.
> Referring to this section in the docs:
> https://geode.apache.org/docs/guide/113/developing/querying_basics/query_grammar_and_reserved_words.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8257) The Jackson ObjectMapper used by a PdxInstance cannot handle typed JSON Objects
[
https://issues.apache.org/jira/browse/GEODE-8257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8257:
-
Priority: Critical (was: Major)
> The Jackson ObjectMapper used by a PdxInstance cannot handle typed JSON
> Objects
> ---
>
> Key: GEODE-8257
> URL: https://issues.apache.org/jira/browse/GEODE-8257
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Affects Versions: 1.10.0, 1.9.2, 1.11.0, 1.12.0
>Reporter: John Blum
>Priority: Critical
> Labels: JSON-PDX
>
> When Jackson has be configured to be explicit about the types contained in
> the JSON document, Geode's {{ObjectMapper}} configuration fails to handle the
> type metadata properly.
> See
> [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/java/org/springframework/geode/data/json/JsonCacheDataImporterExporterIntegrationTests.java#L621-L663]
> for an example test case illustrating the issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8258) Cannot implement PdxInstance and store in a Region
[
https://issues.apache.org/jira/browse/GEODE-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8258:
-
Issue Type: Bug (was: Improvement)
> Cannot implement PdxInstance and store in a Region
> --
>
> Key: GEODE-8258
> URL: https://issues.apache.org/jira/browse/GEODE-8258
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Affects Versions: 1.10.0, 1.9.2, 1.11.0, 1.12.0
>Reporter: John Blum
>Priority: Minor
> Labels: JSON-PDX
>
> Given the type coupling in Geode between a {{PdxInstance}} and the PDX type
> registry, it is not currently possible to implement the
> [{{PdxInstance}}|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/PdxInstance.html]
> interface and store this {{PdxInstance}} object in a Region.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8256) The Jackson ObjectMapper used by a PdxInstance does not properly handle Java 8 Types
[
https://issues.apache.org/jira/browse/GEODE-8256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8256:
-
Priority: Critical (was: Major)
> The Jackson ObjectMapper used by a PdxInstance does not properly handle Java
> 8 Types
>
>
> Key: GEODE-8256
> URL: https://issues.apache.org/jira/browse/GEODE-8256
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Affects Versions: 1.10.0, 1.9.2, 1.11.0, 1.12.0
>Reporter: John Blum
>Priority: Critical
> Labels: JSON-PDX
>
> The Jackson {{ObjectMapper}} in the {{PdxInstanceImpl}} class (see
> [here|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/pdx/internal/PdxInstanceImpl.java#L68-L75])is
> not properly configured.
> Specifically, it cannot handle *Java 8* types since these types are not
> included in Jackson 2, by default, primarily because Jackson 2 is based on
> Java 6 (not Java 8). However, that does not mean Jackson 2 cannot handle
> Java 8 types, when configured properly with extension modules.
> To make matters worse, the {{ObjectMapper}} used by PDX, and specifically the
> {{PdxInstance}} implementation, violates the _Open/Closed_ software design
> principle, so there is literally no way to modify (i.e. override/extend) the
> configuration of the {{ObjectMapper}} as required by the application.
> See
> [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/java/org/springframework/geode/data/json/JsonCacheDataImporterExporterIntegrationTests.java#L583-L618]
> for a test case demonstrating the issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8255) JSONFormatter does not properly generate the @type metadata field
[
https://issues.apache.org/jira/browse/GEODE-8255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8255:
-
Priority: Critical (was: Major)
> JSONFormatter does not properly generate the @type metadata field
> -
>
> Key: GEODE-8255
> URL: https://issues.apache.org/jira/browse/GEODE-8255
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Affects Versions: 1.10.0, 1.9.2, 1.11.0, 1.12.0
>Reporter: John Blum
>Priority: Critical
> Labels: JSON-PDX
>
> The Apache Geode
> [JSONFormatter|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html]
> class is not symmetric.
> While it can parse JSON content and properly resolve JSON Objects as POJOs
> (from {{PdxInstance.getObject()}} when the {{@type}} metadata field is
> present in the JSON content, the {{JSONFormatter}} does not properly set the
> {{@type}} metadata field, particularly when a {{PdxInstance}} has a valid
> class name as determined by
> [PdxInstance.getClassName()|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/PdxInstance.html#getClassName--].
> A test case illustrating this issue can be found
> [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/java/org/springframework/geode/data/json/JsonCacheDataImporterExporterIntegrationTests.java#L546-L580].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8235) Server should not be required to have an available PDX type registry for ClientCache applications
[
https://issues.apache.org/jira/browse/GEODE-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8235:
-
Priority: Major (was: Critical)
> Server should not be required to have an available PDX type registry for
> ClientCache applications
> -
>
> Key: GEODE-8235
> URL: https://issues.apache.org/jira/browse/GEODE-8235
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: John Blum
>Priority: Major
> Labels: JSON-PDX
>
> As an application developer using Apache Geode, if I create a {{ClientCache}}
> application that contains client {{LOCAL}}
> Regions only (i.e. with {{ClientRegionShortcut.LOCAL}}) and I attempt to
> store objects in PDX serialized format, then Geode will throw an
> inappropriate {{Exception}}:
> ACTUAL:
> {code}
> Caused by: org.apache.geode.pdx.JSONFormatterException: Could not parse JSON
> document: [Source:
> (String)"{"@type":"example.app.model.Customer","id":1,"name":"Jon Doe"}";
> line: 1, column: 63]
> at
> org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:206)
> ~[geode-core-1.12.0.jar:na]
> at org.apache.geode.pdx.JSONFormatter.fromJSON(JSONFormatter.java:134)
> ~[geode-core-1.12.0.jar:na]
> at ...
> ... 39 common frames omitted
> Caused by: org.apache.geode.cache.CacheClosedException: Client pools have
> been closed so the PDX type registry is not available.
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1630)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1619)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.ClientTypeRegistration.getAllPools(ClientTypeRegistration.java:153)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.ClientTypeRegistration.defineType(ClientTypeRegistration.java:63)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.TypeRegistry.defineType(TypeRegistry.java:202)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.TypeRegistry.defineLocalType(TypeRegistry.java:250)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.PdxWriterImpl.completeByteStreamGeneration(PdxWriterImpl.java:540)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.PdxInstanceFactoryImpl.create(PdxInstanceFactoryImpl.java:64)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.json.PdxInstanceHelper.endObjectField(PdxInstanceHelper.java:209)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.JSONFormatter.getPdxInstance(JSONFormatter.java:309)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:199)
> ~[geode-core-1.12.0.jar:na]
> ... 55 common frames omitted
> {code}
> First of all this is not even an appropriate Exception!
> {{CacheCloseException}} because my client had no open Pools to an available
> server with a PDX type registry.
> 1. Creating client local-only applications not connected to an entire cluster
> or server is a very useful and practical arrangement during development.
> 2. My application should not have to be a peer {{Cache}} to have an available
> PDX type registry to store PDX instances in client {{LOCAL}} Regions.
> 3. It is actually highly useful to run my application in local-only mode, in
> a local-only context (i.e. with only client {{LOCAL}} Regions) without a
> cluster or server for development, testing and debugging purposes.
> 4. It is also really useful if my application can also store PDX bytes, even
> in client {{LOCAL}} (only) Regions for development, testing and debugging
> purposes.
> Some find it hard to imagine why an application would want to do this, store
> PDX instead of POJOs. However, consider the fact that my application might
> be part of a larger Microservices architecture that communicate via a RESTful
> interfaces. They pass JSON back and forth, which might either be complex or
> unstructured. Either way, it is possible I don't have or don't want to
> create POJOs (types) matching the JSON that my Microservice consumes. I
> simply want access to certain bits of information which PDX is adequately
> suited for. These client LOCAL Regions might even be temporary. When
> connected, I might even want to share this data (or aggregated data) with
> Native Clients which most certainly won't have Java types matching the JSON
> content, raw or summarized.
> EXPECTED:
> As a developer using Apache Geode, I expected to be able to develop
> (primarily) {{ClientCache}} applicati
[jira] [Updated] (GEODE-8254) JSONFormatter cannot parse JSON Arrays
[ https://issues.apache.org/jira/browse/GEODE-8254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-8254: - Issue Type: Bug (was: Improvement) > JSONFormatter cannot parse JSON Arrays > -- > > Key: GEODE-8254 > URL: https://issues.apache.org/jira/browse/GEODE-8254 > Project: Geode > Issue Type: Bug > Components: serialization >Affects Versions: 1.10.0, 1.9.2, 1.11.0, 1.12.0 >Reporter: John Blum >Priority: Major > Labels: JSON-PDX > > The Apache Geode > [JSONFormatter|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html] > class is not capable of parsing/processing JSON Arrays, making it less than > adequate to process JSON documents and content. > This leaves the responsibility and burden on the user, which requires the > user to inspect the individual array elements. > A test case reproducing this issue can be found > [here|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html]. > The matching JSON document is > [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/resources/data-example-doefamily.json]. > JSON Arrays are a very common JSON data type, as > [specified|https://www.json.org/json-en.html]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8235) Server should not be required to have an available PDX type registry for ClientCache applications
[
https://issues.apache.org/jira/browse/GEODE-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8235:
-
Priority: Critical (was: Major)
> Server should not be required to have an available PDX type registry for
> ClientCache applications
> -
>
> Key: GEODE-8235
> URL: https://issues.apache.org/jira/browse/GEODE-8235
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: John Blum
>Priority: Critical
> Labels: JSON-PDX
>
> As an application developer using Apache Geode, if I create a {{ClientCache}}
> application that contains client {{LOCAL}}
> Regions only (i.e. with {{ClientRegionShortcut.LOCAL}}) and I attempt to
> store objects in PDX serialized format, then Geode will throw an
> inappropriate {{Exception}}:
> ACTUAL:
> {code}
> Caused by: org.apache.geode.pdx.JSONFormatterException: Could not parse JSON
> document: [Source:
> (String)"{"@type":"example.app.model.Customer","id":1,"name":"Jon Doe"}";
> line: 1, column: 63]
> at
> org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:206)
> ~[geode-core-1.12.0.jar:na]
> at org.apache.geode.pdx.JSONFormatter.fromJSON(JSONFormatter.java:134)
> ~[geode-core-1.12.0.jar:na]
> at ...
> ... 39 common frames omitted
> Caused by: org.apache.geode.cache.CacheClosedException: Client pools have
> been closed so the PDX type registry is not available.
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1630)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1619)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.ClientTypeRegistration.getAllPools(ClientTypeRegistration.java:153)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.ClientTypeRegistration.defineType(ClientTypeRegistration.java:63)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.TypeRegistry.defineType(TypeRegistry.java:202)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.TypeRegistry.defineLocalType(TypeRegistry.java:250)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.PdxWriterImpl.completeByteStreamGeneration(PdxWriterImpl.java:540)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.PdxInstanceFactoryImpl.create(PdxInstanceFactoryImpl.java:64)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.json.PdxInstanceHelper.endObjectField(PdxInstanceHelper.java:209)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.JSONFormatter.getPdxInstance(JSONFormatter.java:309)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:199)
> ~[geode-core-1.12.0.jar:na]
> ... 55 common frames omitted
> {code}
> First of all this is not even an appropriate Exception!
> {{CacheCloseException}} because my client had no open Pools to an available
> server with a PDX type registry.
> 1. Creating client local-only applications not connected to an entire cluster
> or server is a very useful and practical arrangement during development.
> 2. My application should not have to be a peer {{Cache}} to have an available
> PDX type registry to store PDX instances in client {{LOCAL}} Regions.
> 3. It is actually highly useful to run my application in local-only mode, in
> a local-only context (i.e. with only client {{LOCAL}} Regions) without a
> cluster or server for development, testing and debugging purposes.
> 4. It is also really useful if my application can also store PDX bytes, even
> in client {{LOCAL}} (only) Regions for development, testing and debugging
> purposes.
> Some find it hard to imagine why an application would want to do this, store
> PDX instead of POJOs. However, consider the fact that my application might
> be part of a larger Microservices architecture that communicate via a RESTful
> interfaces. They pass JSON back and forth, which might either be complex or
> unstructured. Either way, it is possible I don't have or don't want to
> create POJOs (types) matching the JSON that my Microservice consumes. I
> simply want access to certain bits of information which PDX is adequately
> suited for. These client LOCAL Regions might even be temporary. When
> connected, I might even want to share this data (or aggregated data) with
> Native Clients which most certainly won't have Java types matching the JSON
> content, raw or summarized.
> EXPECTED:
> As a developer using Apache Geode, I expected to be able to develop
> (primarily) {{ClientCache}} applic
[jira] [Updated] (GEODE-7797) Deprecate old Apache Geode logging properties
[
https://issues.apache.org/jira/browse/GEODE-7797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-7797:
-
Priority: Minor (was: Major)
> Deprecate old Apache Geode logging properties
> -
>
> Key: GEODE-7797
> URL: https://issues.apache.org/jira/browse/GEODE-7797
> Project: Geode
> Issue Type: Bug
>Reporter: John Blum
>Priority: Minor
>
> The old Apache Geode logging properties (e.g. `log-level`) no longer have any
> effect. Effectively, these properties are rendered useless as of Apache
> Geode {{1.9.2}} since the logging capabilities in Apache Geode was properly
> separated and modularized in Apache Geode {{1.9.2}}, between Log4j API usage
> vs. using Log4j, and specifically, {{log4j-core}}, as a logging provider,
> which as been encapsulated in the new {{geode-log4j}} module.
> Apache Geode properties that effectively useless are:
> * {{log-diskspace-limit}}
> * {{log-file}}
> * {{log-file-size-limit}}
> * {{log-level}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7382) ReflectionBasedAutoSerializer should use the greediest domain object constructor it can find to satisfy the values of the domain object
[ https://issues.apache.org/jira/browse/GEODE-7382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-7382: - Summary: ReflectionBasedAutoSerializer should use the greediest domain object constructor it can find to satisfy the values of the domain object (was: ReflectionBasedAutoSerializer should consider using the greediest application domain object type constructor it can find to satisfy the values of the domain object) > ReflectionBasedAutoSerializer should use the greediest domain object > constructor it can find to satisfy the values of the domain object > --- > > Key: GEODE-7382 > URL: https://issues.apache.org/jira/browse/GEODE-7382 > Project: Geode > Issue Type: Improvement >Reporter: John Blum >Priority: Major > > ... Regardless of whether or not... > 1. There exists a public, no-arg constructor or NOT (since a default, public, > no-arg constructor is not required in Java). > 2. And whether or not that constructor is public or not (which also does not > matter in Java) > 3. And simply because constructors provide initialization safety that setters > and field injection simply cannot as specified by the JVM spec. > Also, consider what happens when the object class type is _immutable_. That > is, all object initialization must happen through a constructor since the > object is immutable, which are inherently Thread-safe. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7376) AsyncEventQueueFactory.pauseEventDispatching() & AsyncEventQueue.resumeEventDispatching() is missing from the API Javadoc
[
https://issues.apache.org/jira/browse/GEODE-7376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-7376:
-
Priority: Minor (was: Major)
> AsyncEventQueueFactory.pauseEventDispatching() &
> AsyncEventQueue.resumeEventDispatching() is missing from the API Javadoc
> -
>
> Key: GEODE-7376
> URL: https://issues.apache.org/jira/browse/GEODE-7376
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: John Blum
>Priority: Minor
>
> The {{AsyncEventQueueFactory.pauseEventDispatching()}} is present in the
> Pivotal GemFire API Javadoc here:
> http://gemfire-98-javadocs.docs.pivotal.io/org/apache/geode/cache/asyncqueue/AsyncEventQueueFactory.html#pauseEventDispatching--
> The {{AsyncEventQueue.resumeEventDispatching()}} is present in the Pivotal
> GemFire API Javadoc here:
> http://gemfire-98-javadocs.docs.pivotal.io/org/apache/geode/cache/asyncqueue/AsyncEventQueue.html#resumeEventDispatching--
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7382) ReflectionBasedAutoSerializer should consider using the greediest application domain object type constructor it can find to satisfy the values of the domain object
[ https://issues.apache.org/jira/browse/GEODE-7382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-7382: - Summary: ReflectionBasedAutoSerializer should consider using the greediest application domain object type constructor it can find to satisfy the values of the domain object (was: ReflectionBasedSerializer should consider using the greediest application domain object type constructor it can find to satisfy the values of the domain object) > ReflectionBasedAutoSerializer should consider using the greediest application > domain object type constructor it can find to satisfy the values of the > domain object > --- > > Key: GEODE-7382 > URL: https://issues.apache.org/jira/browse/GEODE-7382 > Project: Geode > Issue Type: Improvement >Reporter: John Blum >Priority: Major > > ... Regardless of whether or not... > 1. There exists a public, no-arg constructor or NOT (since a default, public, > no-arg constructor is not required in Java). > 2. And whether or not that constructor is public or not (which also does not > matter in Java) > 3. And simply because constructors provide initialization safety that setters > and field injection simply cannot as specified by the JVM spec. > Also, consider what happens when the object class type is _immutable_. That > is, all object initialization must happen through a constructor since the > object is immutable, which are inherently Thread-safe. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-2083) Geode should call Declarable.init() when the SecurityManager component implements Declarable.
[
https://issues.apache.org/jira/browse/GEODE-2083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-2083:
-
Issue Type: Bug (was: Improvement)
> Geode should call Declarable.init() when the SecurityManager component
> implements Declarable.
> -
>
> Key: GEODE-2083
> URL: https://issues.apache.org/jira/browse/GEODE-2083
> Project: Geode
> Issue Type: Bug
> Components: security
>Affects Versions: 1.0.0-incubating
>Reporter: John Blum
>Assignee: Jinmei Liao
>Priority: Major
> Labels: affects-spring
>
> Though, going forward (i.e. post {{1.0.0-incubating}}), there will be
> multiple ways to configure Apache Geode's {{SecurityManager}} implementation
> in effect, for instance, and most notably, [GEODE-2030], in addition to the
> Geode {{security-manager}} (System) property, it would be highly valuable if
> Apache Geode called
> [Declarable.init()|http://geode.incubator.apache.org/releases/latest/javadoc/org/apache/geode/cache/Declarable.html#init-java.util.Properties-]
> on the custom, application-specific, Geode-based {{SecurityManager}}
> implementation providing the custom, application-specific, Geode-based
> [SecurityManager|http://geode.incubator.apache.org/releases/latest/javadoc/org/apache/geode/security/SecurityManager.html]
> implementation implemented the Geode
> [Declarable|http://geode.incubator.apache.org/releases/latest/javadoc/org/apache/geode/cache/Declarable.html]
> interface.
> This would be especially beneficial in situations where any post-construction
> initialization logic needed to be invoked after the constructor, particularly
> where the custom {{SecurityManager}} **this** reference needs to be accessed
> by other classes/components in the {{init()}} method outside the
> {{SecurityManager}} instance, which if done from/within a constructor during
> construction would allow the **this** reference to escape (not good in a
> multi-threaded environment).
> This is also useful in situations where the GemFire {{security-manager}}
> (System) property is still being used, as I suspect will be the case in some
> situations/environments.
> Tracing this through, the {{IntegratedSecurityService}} [delegates
> |https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating/geode-core/src/main/java/org/apache/geode/internal/security/IntegratedSecurityService.java#L335]
> to the {{SecurityService.getObjectOfTypeFromClass(..)}} method. This
> [method|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating/geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java#L67-L91]
> (along with [similar supporting
> methods|https://github.com/apache/incubator-geode/blob/rel/v1.0.0-incubating/geode-core/src/main/java/org/apache/geode/internal/security/SecurityService.java#L93-L129])
> could Introspect the class type and determine whether the custom,
> application-specific, Geode-based {{SecurityManager}} implementation
> implements the {{Declarable}} interface, invoking the {{init()}} method
> before returning, if it does.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-167) Leverage the @ConditionalIgnore annotation and corresponding JUnit Rule to setup conditional test exclusions in the test suite based on timestamp or complex condition imp
[
https://issues.apache.org/jira/browse/GEODE-167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum reassigned GEODE-167:
---
Assignee: (was: John Blum)
> Leverage the @ConditionalIgnore annotation and corresponding JUnit Rule to
> setup conditional test exclusions in the test suite based on timestamp or
> complex condition implemented with IgnoreCondition.
>
>
> Key: GEODE-167
> URL: https://issues.apache.org/jira/browse/GEODE-167
> Project: Geode
> Issue Type: Improvement
> Components: general
> Environment: Apache Geode test infrastructure
>Reporter: John Blum
>Priority: Minor
> Labels: ApacheGeode, ConditionalIgnore, Test, UnitTest
> Attachments: ConditionalIgnoreRule.java, ConditionalIgnoreRule.java,
> DefaultIgnoreCondition.java, IgnoreCondition.java,
> IgnoreConditionEvaluationException.java
>
> Original Estimate: 8h
> Remaining Estimate: 8h
>
> Make use of the {{@ConditionalIgnore}} annotation and corresponding JUnit
> {{ConditionalIgnoreRule}} to ignore tests on a case-by-case basis using a
> specific set of criteria (a.k.a. {{IgnoreCondition}}).
> This could be used for instance to ignore offending tests causing failure or
> hangs in the test suite downstream or to conditional ignore a test based on
> specific environmental/context requirements.
> See attached source code for reference.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-126) Provide pre-canned Geode Functions out-of-the-box for useful, common Geode operations.
[
https://issues.apache.org/jira/browse/GEODE-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-126:
Priority: Minor (was: Major)
> Provide pre-canned Geode Functions out-of-the-box for useful, common Geode
> operations.
> --
>
> Key: GEODE-126
> URL: https://issues.apache.org/jira/browse/GEODE-126
> Project: Geode
> Issue Type: Improvement
> Components: functions
>Affects Versions: 1.0.0-incubating
> Environment: Apache Geode + Cache Clients
>Reporter: John Blum
>Priority: Minor
> Labels: ApacheGeode, Canned, Functions, Out-of-the-Box,
> affects-spring, docs
>
> There were many useful _Geode_
> [Function(s)|https://github.com/apache/incubator-geode/blob/develop/gemfire-core/src/main/java/com/gemstone/gemfire/cache/execute/Function.java]
> created to implement many of _Geode's_ features.
> For instance, _Gfsh_ commands were nearly all implemented with _Geode_
> [Functions|https://github.com/apache/incubator-geode/tree/develop/gemfire-core/src/main/java/com/gemstone/gemfire/management/internal/cli/functions].
> Some of these {{Functions}} should be provided out-of-the-box, as pre-canned
> {{Functions}} that users can use and documented as such.
> One good +example+ of such a {{Function}} is the _Gfsh's_ {{list functions}}
> command {{Function}}...
> [ListFunctionFunction|https://github.com/apache/incubator-geode/blob/develop/gemfire-core/src/main/java/com/gemstone/gemfire/management/internal/cli/functions/ListFunctionFunction.java].
> There are many more like
> [ListFunctionFunction|https://github.com/apache/incubator-geode/blob/develop/gemfire-core/src/main/java/com/gemstone/gemfire/management/internal/cli/functions/ListFunctionFunction.java]
> that would be equally useful to provide in a non-internal API, supported by
> Geode out-of-the-box.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8699) Expose the OQL Parser as a public API
John Blum created GEODE-8699: Summary: Expose the OQL Parser as a public API Key: GEODE-8699 URL: https://issues.apache.org/jira/browse/GEODE-8699 Project: Geode Issue Type: Wish Components: querying Reporter: John Blum This is a request to have the OQL Parser API used by Apache Geode under the hood be exposed as a public API, consumable by Frameworks and Tooling. While applications may not have a need to use the OQL Parser API, Frameworks and Tooling most certainly do. For instance, Spring Data for Apache Geode (SDG) is currently parsing and generating OQL queries in the Spring Data Repository infrastructure. Currently, there is no easy way to consistently parse or generate OQL statements given the API to parse OQL is "internal". This leaves Framework and Tool designers to have to either 1) create a Grammar for OQL and generating a Parser using JavaCC or ANTLR (thereby reinventing the wheel) or 2) resorting to a poor mans recursive descent parser or using simple REGEX and String parsing/concatenation. #1 is dangerous if Geode's Grammar for OQL ever changes. #2 is error prone at best. Please consider making the OQL Parser API along with the model for the OQL query components (e.g. projection, predicates, etc) public. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8618) OQL grammar specification in docs is incomplete
[
https://issues.apache.org/jira/browse/GEODE-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17219953#comment-17219953
]
John Blum commented on GEODE-8618:
--
The doc also does not specify the grammar for {{GROUP BY}}.
> OQL grammar specification in docs is incomplete
> ---
>
> Key: GEODE-8618
> URL: https://issues.apache.org/jira/browse/GEODE-8618
> Project: Geode
> Issue Type: Improvement
> Components: docs, querying
>Affects Versions: 1.11.0, 1.12.0, 1.13.0
>Reporter: John Blum
>Priority: Minor
>
> For example, there are no rules for the {{ORDER BY}} and {{LIMIT}} clauses.
> Referring to this section in the docs:
> https://geode.apache.org/docs/guide/113/developing/querying_basics/query_grammar_and_reserved_words.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8618) OQL grammar specification in docs is incomplete
[
https://issues.apache.org/jira/browse/GEODE-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8618:
-
Component/s: docs
> OQL grammar specification in docs is incomplete
> ---
>
> Key: GEODE-8618
> URL: https://issues.apache.org/jira/browse/GEODE-8618
> Project: Geode
> Issue Type: Improvement
> Components: docs, querying
>Affects Versions: 1.11.0, 1.12.0, 1.13.0
>Reporter: John Blum
>Priority: Minor
>
> For example, there are no rules for the {{ORDER BY}} and {{LIMIT}} clauses.
> Referring to this section in the docs:
> https://geode.apache.org/docs/guide/113/developing/querying_basics/query_grammar_and_reserved_words.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8618) OQL grammar specification in docs is incomplete
[
https://issues.apache.org/jira/browse/GEODE-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8618:
-
Summary: OQL grammar specification in docs is incomplete (was: OQL Grammar
specification in docs is incomplete)
> OQL grammar specification in docs is incomplete
> ---
>
> Key: GEODE-8618
> URL: https://issues.apache.org/jira/browse/GEODE-8618
> Project: Geode
> Issue Type: Improvement
> Components: querying
>Affects Versions: 1.11.0, 1.12.0, 1.13.0
>Reporter: John Blum
>Priority: Minor
>
> For example, there are no rules for the {{ORDER BY}} and {{LIMIT}} clauses.
> Referring to this section in the docs:
> https://geode.apache.org/docs/guide/113/developing/querying_basics/query_grammar_and_reserved_words.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8286) The Geode JVM Shutdown Hook should not be enabled by default
[ https://issues.apache.org/jira/browse/GEODE-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-8286: - Priority: Critical (was: Minor) > The Geode JVM Shutdown Hook should not be enabled by default > > > Key: GEODE-8286 > URL: https://issues.apache.org/jira/browse/GEODE-8286 > Project: Geode > Issue Type: Improvement > Components: configuration, general, management >Reporter: John Blum >Priority: Critical > Labels: JSON-PDX > > Apache Geode registers a JVM Shutdown Hook in > [InternalDistributedSystem|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L2190-L] > that ensures the Apache Geode Cache and associated DistributedSystem are > shutdown properly when the JVM exits. > However, this JVM Shutdown Hook and interfere with Frameworks and Tooling > that have their own Lifecycle Management capabilities. The Spring Framework > and Container is one such example. > Any managed environment, be that Micronaut, Quarkus, Pivotal Platform > (PCF/TAS), Kubernetes, AWS, Azure, GCP, etc, etc, are going to have lifecycle > management capabilities. > It is very important that the environment manage the lifecycle of all actors > in the fully "integrated" system. > In Spring's case, it must coordinate the lifecycle of application components > along with integrated systems, like Geode, in an effort to shut all > components down in a coordinated, correct fashion. > If Geode's JVM Shutdown Hook is permitted to do as it pleases, then this can > circumvent the Framework/Container, Tool, or other's lifecycle management > capabilities, leaving the system or application in an inconsistent/incorrect > state. > To make matters worse, the [JVM System > Property|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L2191] > (and specifically, > [this|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L391-L392]) > controlling the enablement of the JVM Shutdown Hook, is non-public and [not > documented|https://geode.apache.org/docs/guide/112/reference/topics/gemfire_properties.html]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8618) OQL Grammar specification in docs is incomplete
[
https://issues.apache.org/jira/browse/GEODE-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8618:
-
Priority: Minor (was: Major)
> OQL Grammar specification in docs is incomplete
> ---
>
> Key: GEODE-8618
> URL: https://issues.apache.org/jira/browse/GEODE-8618
> Project: Geode
> Issue Type: Improvement
> Components: querying
>Affects Versions: 1.11.0, 1.12.0, 1.13.0
>Reporter: John Blum
>Priority: Minor
>
> For example, there are no rules for the {{ORDER BY}} and {{LIMIT}} clauses.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8618) OQL Grammar specification in docs is incomplete
[
https://issues.apache.org/jira/browse/GEODE-8618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8618:
-
Description:
For example, there are no rules for the {{ORDER BY}} and {{LIMIT}} clauses.
Referring to this section in the docs:
https://geode.apache.org/docs/guide/113/developing/querying_basics/query_grammar_and_reserved_words.html
was:For example, there are no rules for the {{ORDER BY}} and {{LIMIT}}
clauses.
> OQL Grammar specification in docs is incomplete
> ---
>
> Key: GEODE-8618
> URL: https://issues.apache.org/jira/browse/GEODE-8618
> Project: Geode
> Issue Type: Improvement
> Components: querying
>Affects Versions: 1.11.0, 1.12.0, 1.13.0
>Reporter: John Blum
>Priority: Minor
>
> For example, there are no rules for the {{ORDER BY}} and {{LIMIT}} clauses.
> Referring to this section in the docs:
> https://geode.apache.org/docs/guide/113/developing/querying_basics/query_grammar_and_reserved_words.html
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8286) The Geode JVM Shutdown Hook should not be enabled by default
[ https://issues.apache.org/jira/browse/GEODE-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-8286: - Priority: Minor (was: Major) > The Geode JVM Shutdown Hook should not be enabled by default > > > Key: GEODE-8286 > URL: https://issues.apache.org/jira/browse/GEODE-8286 > Project: Geode > Issue Type: Improvement > Components: configuration, general, management >Reporter: John Blum >Priority: Minor > Labels: JSON-PDX > > Apache Geode registers a JVM Shutdown Hook in > [InternalDistributedSystem|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L2190-L] > that ensures the Apache Geode Cache and associated DistributedSystem are > shutdown properly when the JVM exits. > However, this JVM Shutdown Hook and interfere with Frameworks and Tooling > that have their own Lifecycle Management capabilities. The Spring Framework > and Container is one such example. > Any managed environment, be that Micronaut, Quarkus, Pivotal Platform > (PCF/TAS), Kubernetes, AWS, Azure, GCP, etc, etc, are going to have lifecycle > management capabilities. > It is very important that the environment manage the lifecycle of all actors > in the fully "integrated" system. > In Spring's case, it must coordinate the lifecycle of application components > along with integrated systems, like Geode, in an effort to shut all > components down in a coordinated, correct fashion. > If Geode's JVM Shutdown Hook is permitted to do as it pleases, then this can > circumvent the Framework/Container, Tool, or other's lifecycle management > capabilities, leaving the system or application in an inconsistent/incorrect > state. > To make matters worse, the [JVM System > Property|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L2191] > (and specifically, > [this|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L391-L392]) > controlling the enablement of the JVM Shutdown Hook, is non-public and [not > documented|https://geode.apache.org/docs/guide/112/reference/topics/gemfire_properties.html]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8618) OQL Grammar specification in docs is incomplete
John Blum created GEODE-8618:
Summary: OQL Grammar specification in docs is incomplete
Key: GEODE-8618
URL: https://issues.apache.org/jira/browse/GEODE-8618
Project: Geode
Issue Type: Improvement
Components: querying
Affects Versions: 1.13.0, 1.12.0, 1.11.0
Reporter: John Blum
For example, there are no rules for the {{ORDER BY}} and {{LIMIT}} clauses.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GEODE-7200) Geode should not try to prefill any declared Pool (e.g. DEFAULT, or otherwise) if a client is running in a local-only capacity
[ https://issues.apache.org/jira/browse/GEODE-7200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206506#comment-17206506 ] John Blum edited comment on GEODE-7200 at 10/2/20, 8:40 PM: If the client is running completely in LOCAL-only mode, then configuring any connections is a moot point. Having clients run in local-only mode is highly useful for testing purpose, among other things. was (Author: jblum): If the client is running completely in LOCAL-only mode, then configuring any connections is a moot point. > Geode should not try to prefill any declared Pool (e.g. DEFAULT, or > otherwise) if a client is running in a local-only capacity > -- > > Key: GEODE-7200 > URL: https://issues.apache.org/jira/browse/GEODE-7200 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: John Blum >Priority: Major > Labels: affects-spring > > See https://github.com/spring-projects/spring-boot-data-geode/issues/53 for > more details. > This really client-only and not the traditional client/server topology, which > is a very valid and useful client arrangement. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GEODE-7200) Geode should not try to prefill any declared Pool (e.g. DEFAULT, or otherwise) if a client is running in a local-only capacity
[ https://issues.apache.org/jira/browse/GEODE-7200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206506#comment-17206506 ] John Blum edited comment on GEODE-7200 at 10/2/20, 8:40 PM: If the client is running completely in LOCAL-only mode, then configuring any connections is a moot point. Having clients run in local-only mode is highly useful for testing purposes, among other things. was (Author: jblum): If the client is running completely in LOCAL-only mode, then configuring any connections is a moot point. Having clients run in local-only mode is highly useful for testing purpose, among other things. > Geode should not try to prefill any declared Pool (e.g. DEFAULT, or > otherwise) if a client is running in a local-only capacity > -- > > Key: GEODE-7200 > URL: https://issues.apache.org/jira/browse/GEODE-7200 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: John Blum >Priority: Major > Labels: affects-spring > > See https://github.com/spring-projects/spring-boot-data-geode/issues/53 for > more details. > This really client-only and not the traditional client/server topology, which > is a very valid and useful client arrangement. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7200) Geode should not try to prefill any declared Pool (e.g. DEFAULT, or otherwise) if a client is running in a local-only capacity
[ https://issues.apache.org/jira/browse/GEODE-7200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17206506#comment-17206506 ] John Blum commented on GEODE-7200: -- If the client is running completely in LOCAL-only mode, then configuring any connections is a moot point. > Geode should not try to prefill any declared Pool (e.g. DEFAULT, or > otherwise) if a client is running in a local-only capacity > -- > > Key: GEODE-7200 > URL: https://issues.apache.org/jira/browse/GEODE-7200 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: John Blum >Priority: Major > Labels: affects-spring > > See https://github.com/spring-projects/spring-boot-data-geode/issues/53 for > more details. > This really client-only and not the traditional client/server topology, which > is a very valid and useful client arrangement. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-8286) The Geode JVM Shutdown Hook should not be enabled by default
[ https://issues.apache.org/jira/browse/GEODE-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17140754#comment-17140754 ] John Blum commented on GEODE-8286: -- Of course, changing the registration of the Geode, JVM Shutdown Hook to "opt-in" rather than the currently positioned, "opt-out", is a change in behavior could adversely affect users. This would be an acceptable change in a major version. The only other alternative is if Geode provided an SPI that made it context aware. > The Geode JVM Shutdown Hook should not be enabled by default > > > Key: GEODE-8286 > URL: https://issues.apache.org/jira/browse/GEODE-8286 > Project: Geode > Issue Type: Improvement > Components: configuration, general, management >Reporter: John Blum >Priority: Major > Labels: JSON-PDX > > Apache Geode registers a JVM Shutdown Hook in > [InternalDistributedSystem|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L2190-L] > that ensures the Apache Geode Cache and associated DistributedSystem are > shutdown properly when the JVM exits. > However, this JVM Shutdown Hook and interfere with Frameworks and Tooling > that have their own Lifecycle Management capabilities. The Spring Framework > and Container is one such example. > Any managed environment, be that Micronaut, Quarkus, Pivotal Platform > (PCF/TAS), Kubernetes, AWS, Azure, GCP, etc, etc, are going to have lifecycle > management capabilities. > It is very important that the environment manage the lifecycle of all actors > in the fully "integrated" system. > In Spring's case, it must coordinate the lifecycle of application components > along with integrated systems, like Geode, in an effort to shut all > components down in a coordinated, correct fashion. > If Geode's JVM Shutdown Hook is permitted to do as it pleases, then this can > circumvent the Framework/Container, Tool, or other's lifecycle management > capabilities, leaving the system or application in an inconsistent/incorrect > state. > To make matters worse, the [JVM System > Property|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L2191] > (and specifically, > [this|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L391-L392]) > controlling the enablement of the JVM Shutdown Hook, is non-public and [not > documented|https://geode.apache.org/docs/guide/112/reference/topics/gemfire_properties.html]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8286) The Geode JVM Shutdown Hook should not be enabled by default
John Blum created GEODE-8286: Summary: The Geode JVM Shutdown Hook should not be enabled by default Key: GEODE-8286 URL: https://issues.apache.org/jira/browse/GEODE-8286 Project: Geode Issue Type: Improvement Components: configuration, general, management Reporter: John Blum Apache Geode registers a JVM Shutdown Hook in [InternalDistributedSystem|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L2190-L] that ensures the Apache Geode Cache and associated DistributedSystem are shutdown properly when the JVM exits. However, this JVM Shutdown Hook and interfere with Frameworks and Tooling that have their own Lifecycle Management capabilities. The Spring Framework and Container is one such example. Any managed environment, be that Micronaut, Quarkus, Pivotal Platform (PCF/TAS), Kubernetes, AWS, Azure, GCP, etc, etc, are going to have lifecycle management capabilities. It is very important that the environment manage the lifecycle of all actors in the fully "integrated" system. In Spring's case, it must coordinate the lifecycle of application components along with integrated systems, like Geode, in an effort to shut all components down in a coordinated, correct fashion. If Geode's JVM Shutdown Hook is permitted to do as it pleases, then this can circumvent the Framework/Container, Tool, or other's lifecycle management capabilities, leaving the system or application in an inconsistent/incorrect state. To make matters worse, the [JVM System Property|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L2191] (and specifically, [this|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L391-L392]) controlling the enablement of the JVM Shutdown Hook, is non-public and [not documented|https://geode.apache.org/docs/guide/112/reference/topics/gemfire_properties.html]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8286) The Geode JVM Shutdown Hook should not be enabled by default
[ https://issues.apache.org/jira/browse/GEODE-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-8286: - Labels: JSON-PDX (was: ) > The Geode JVM Shutdown Hook should not be enabled by default > > > Key: GEODE-8286 > URL: https://issues.apache.org/jira/browse/GEODE-8286 > Project: Geode > Issue Type: Improvement > Components: configuration, general, management >Reporter: John Blum >Priority: Major > Labels: JSON-PDX > > Apache Geode registers a JVM Shutdown Hook in > [InternalDistributedSystem|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L2190-L] > that ensures the Apache Geode Cache and associated DistributedSystem are > shutdown properly when the JVM exits. > However, this JVM Shutdown Hook and interfere with Frameworks and Tooling > that have their own Lifecycle Management capabilities. The Spring Framework > and Container is one such example. > Any managed environment, be that Micronaut, Quarkus, Pivotal Platform > (PCF/TAS), Kubernetes, AWS, Azure, GCP, etc, etc, are going to have lifecycle > management capabilities. > It is very important that the environment manage the lifecycle of all actors > in the fully "integrated" system. > In Spring's case, it must coordinate the lifecycle of application components > along with integrated systems, like Geode, in an effort to shut all > components down in a coordinated, correct fashion. > If Geode's JVM Shutdown Hook is permitted to do as it pleases, then this can > circumvent the Framework/Container, Tool, or other's lifecycle management > capabilities, leaving the system or application in an inconsistent/incorrect > state. > To make matters worse, the [JVM System > Property|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L2191] > (and specifically, > [this|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/distributed/internal/InternalDistributedSystem.java#L391-L392]) > controlling the enablement of the JVM Shutdown Hook, is non-public and [not > documented|https://geode.apache.org/docs/guide/112/reference/topics/gemfire_properties.html]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8255) JSONFormatter does not properly generate the @type metadata field
[
https://issues.apache.org/jira/browse/GEODE-8255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8255:
-
Issue Type: Bug (was: Improvement)
> JSONFormatter does not properly generate the @type metadata field
> -
>
> Key: GEODE-8255
> URL: https://issues.apache.org/jira/browse/GEODE-8255
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Affects Versions: 1.10.0, 1.9.2, 1.11.0, 1.12.0
>Reporter: John Blum
>Priority: Major
> Labels: JSON-PDX
>
> The Apache Geode
> [JSONFormatter|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html]
> class is not symmetric.
> While it can parse JSON content and properly resolve JSON Objects as POJOs
> (from {{PdxInstance.getObject()}} when the {{@type}} metadata field is
> present in the JSON content, the {{JSONFormatter}} does not properly set the
> {{@type}} metadata field, particularly when a {{PdxInstance}} has a valid
> class name as determined by
> [PdxInstance.getClassName()|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/PdxInstance.html#getClassName--].
> A test case illustrating this issue can be found
> [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/java/org/springframework/geode/data/json/JsonCacheDataImporterExporterIntegrationTests.java#L546-L580].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8257) The Jackson ObjectMapper used by a PdxInstance cannot handle typed JSON Objects
[
https://issues.apache.org/jira/browse/GEODE-8257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8257:
-
Issue Type: Bug (was: Improvement)
> The Jackson ObjectMapper used by a PdxInstance cannot handle typed JSON
> Objects
> ---
>
> Key: GEODE-8257
> URL: https://issues.apache.org/jira/browse/GEODE-8257
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Affects Versions: 1.10.0, 1.9.2, 1.11.0, 1.12.0
>Reporter: John Blum
>Priority: Major
> Labels: JSON-PDX
>
> When Jackson has be configured to be explicit about the types contained in
> the JSON document, Geode's {{ObjectMapper}} configuration fails to handle the
> type metadata properly.
> See
> [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/java/org/springframework/geode/data/json/JsonCacheDataImporterExporterIntegrationTests.java#L621-L663]
> for an example test case illustrating the issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8256) The Jackson ObjectMapper used by a PdxInstance does not properly handle Java 8 Types
[
https://issues.apache.org/jira/browse/GEODE-8256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8256:
-
Issue Type: Bug (was: Improvement)
> The Jackson ObjectMapper used by a PdxInstance does not properly handle Java
> 8 Types
>
>
> Key: GEODE-8256
> URL: https://issues.apache.org/jira/browse/GEODE-8256
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Affects Versions: 1.10.0, 1.9.2, 1.11.0, 1.12.0
>Reporter: John Blum
>Priority: Major
> Labels: JSON-PDX
>
> The Jackson {{ObjectMapper}} in the {{PdxInstanceImpl}} class (see
> [here|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/pdx/internal/PdxInstanceImpl.java#L68-L75])is
> not properly configured.
> Specifically, it cannot handle *Java 8* types since these types are not
> included in Jackson 2, by default, primarily because Jackson 2 is based on
> Java 6 (not Java 8). However, that does not mean Jackson 2 cannot handle
> Java 8 types, when configured properly with extension modules.
> To make matters worse, the {{ObjectMapper}} used by PDX, and specifically the
> {{PdxInstance}} implementation, violates the _Open/Closed_ software design
> principle, so there is literally no way to modify (i.e. override/extend) the
> configuration of the {{ObjectMapper}} as required by the application.
> See
> [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/java/org/springframework/geode/data/json/JsonCacheDataImporterExporterIntegrationTests.java#L583-L618]
> for a test case demonstrating the issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8258) Cannot implement PdxInstance and store in a Region
[
https://issues.apache.org/jira/browse/GEODE-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8258:
-
Labels: JSON-PDX (was: )
> Cannot implement PdxInstance and store in a Region
> --
>
> Key: GEODE-8258
> URL: https://issues.apache.org/jira/browse/GEODE-8258
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Affects Versions: 1.10.0, 1.9.2, 1.11.0, 1.12.0
>Reporter: John Blum
>Priority: Major
> Labels: JSON-PDX
>
> Given the type coupling in Geode between a {{PdxInstance}} and the PDX type
> registry, it is not currently possible to implement the
> [{{PdxInstance}}|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/PdxInstance.html]
> interface and store this {{PdxInstance}} object in a Region.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8258) Cannot implement PdxInstance and store in a Region
John Blum created GEODE-8258:
Summary: Cannot implement PdxInstance and store in a Region
Key: GEODE-8258
URL: https://issues.apache.org/jira/browse/GEODE-8258
Project: Geode
Issue Type: Improvement
Reporter: John Blum
Given the type coupling in Geode between a {{PdxInstance}} and the PDX type
registry, it is not currently possible to implement the
[{{PdxInstance}}|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/PdxInstance.html]
interface and store this {{PdxInstance}} object in a Region.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8258) Cannot implement PdxInstance and store in a Region
[
https://issues.apache.org/jira/browse/GEODE-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8258:
-
Component/s: serialization
> Cannot implement PdxInstance and store in a Region
> --
>
> Key: GEODE-8258
> URL: https://issues.apache.org/jira/browse/GEODE-8258
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Reporter: John Blum
>Priority: Major
>
> Given the type coupling in Geode between a {{PdxInstance}} and the PDX type
> registry, it is not currently possible to implement the
> [{{PdxInstance}}|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/PdxInstance.html]
> interface and store this {{PdxInstance}} object in a Region.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8258) Cannot implement PdxInstance and store in a Region
[
https://issues.apache.org/jira/browse/GEODE-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8258:
-
Priority: Minor (was: Major)
> Cannot implement PdxInstance and store in a Region
> --
>
> Key: GEODE-8258
> URL: https://issues.apache.org/jira/browse/GEODE-8258
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Affects Versions: 1.10.0, 1.9.2, 1.11.0, 1.12.0
>Reporter: John Blum
>Priority: Minor
> Labels: JSON-PDX
>
> Given the type coupling in Geode between a {{PdxInstance}} and the PDX type
> registry, it is not currently possible to implement the
> [{{PdxInstance}}|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/PdxInstance.html]
> interface and store this {{PdxInstance}} object in a Region.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8258) Cannot implement PdxInstance and store in a Region
[
https://issues.apache.org/jira/browse/GEODE-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8258:
-
Affects Version/s: 1.10.0
1.9.2
1.11.0
1.12.0
> Cannot implement PdxInstance and store in a Region
> --
>
> Key: GEODE-8258
> URL: https://issues.apache.org/jira/browse/GEODE-8258
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Affects Versions: 1.10.0, 1.9.2, 1.11.0, 1.12.0
>Reporter: John Blum
>Priority: Major
>
> Given the type coupling in Geode between a {{PdxInstance}} and the PDX type
> registry, it is not currently possible to implement the
> [{{PdxInstance}}|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/PdxInstance.html]
> interface and store this {{PdxInstance}} object in a Region.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8257) The Jackson ObjectMapper used by a PdxInstance cannot handle typed JSON Objects
[
https://issues.apache.org/jira/browse/GEODE-8257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8257:
-
Affects Version/s: 1.10.0
1.9.2
1.11.0
1.12.0
> The Jackson ObjectMapper used by a PdxInstance cannot handle typed JSON
> Objects
> ---
>
> Key: GEODE-8257
> URL: https://issues.apache.org/jira/browse/GEODE-8257
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Affects Versions: 1.10.0, 1.9.2, 1.11.0, 1.12.0
>Reporter: John Blum
>Priority: Major
> Labels: JSON-PDX
>
> When Jackson has be configured to be explicit about the types contained in
> the JSON document, Geode's {{ObjectMapper}} configuration fails to handle the
> type metadata properly.
> See
> [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/java/org/springframework/geode/data/json/JsonCacheDataImporterExporterIntegrationTests.java#L621-L663]
> for an example test case illustrating the issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8257) The Jackson ObjectMapper used by a PdxInstance cannot handle typed JSON Objects
[
https://issues.apache.org/jira/browse/GEODE-8257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8257:
-
Labels: JSON-PDX (was: )
> The Jackson ObjectMapper used by a PdxInstance cannot handle typed JSON
> Objects
> ---
>
> Key: GEODE-8257
> URL: https://issues.apache.org/jira/browse/GEODE-8257
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Reporter: John Blum
>Priority: Major
> Labels: JSON-PDX
>
> When Jackson has be configured to be explicit about the types contained in
> the JSON document, Geode's {{ObjectMapper}} configuration fails to handle the
> type metadata properly.
> See
> [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/java/org/springframework/geode/data/json/JsonCacheDataImporterExporterIntegrationTests.java#L621-L663]
> for an example test case illustrating the issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8257) The Jackson ObjectMapper used by a PdxInstance cannot handle typed JSON Objects
John Blum created GEODE-8257:
Summary: The Jackson ObjectMapper used by a PdxInstance cannot
handle typed JSON Objects
Key: GEODE-8257
URL: https://issues.apache.org/jira/browse/GEODE-8257
Project: Geode
Issue Type: Improvement
Components: serialization
Reporter: John Blum
When Jackson has be configured to be explicit about the types contained in the
JSON document, Geode's {{ObjectMapper}} configuration fails to handle the type
metadata properly.
See
[here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/java/org/springframework/geode/data/json/JsonCacheDataImporterExporterIntegrationTests.java#L621-L663]
for an example test case illustrating the issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8255) JSONFormatter does not properly generate the @type metadata field
[
https://issues.apache.org/jira/browse/GEODE-8255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8255:
-
Affects Version/s: 1.10.0
1.9.2
1.11.0
1.12.0
> JSONFormatter does not properly generate the @type metadata field
> -
>
> Key: GEODE-8255
> URL: https://issues.apache.org/jira/browse/GEODE-8255
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Affects Versions: 1.10.0, 1.9.2, 1.11.0, 1.12.0
>Reporter: John Blum
>Priority: Major
> Labels: JSON-PDX
>
> The Apache Geode
> [JSONFormatter|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html]
> class is not symmetric.
> While it can parse JSON content and properly resolve JSON Objects as POJOs
> (from {{PdxInstance.getObject()}} when the {{@type}} metadata field is
> present in the JSON content, the {{JSONFormatter}} does not properly set the
> {{@type}} metadata field, particularly when a {{PdxInstance}} has a valid
> class name as determined by
> [PdxInstance.getClassName()|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/PdxInstance.html#getClassName--].
> A test case illustrating this issue can be found
> [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/java/org/springframework/geode/data/json/JsonCacheDataImporterExporterIntegrationTests.java#L546-L580].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8256) The Jackson ObjectMapper used by a PdxInstance does not properly handle Java 8 Types
[
https://issues.apache.org/jira/browse/GEODE-8256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8256:
-
Labels: JSON-PDX (was: )
> The Jackson ObjectMapper used by a PdxInstance does not properly handle Java
> 8 Types
>
>
> Key: GEODE-8256
> URL: https://issues.apache.org/jira/browse/GEODE-8256
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Affects Versions: 1.10.0, 1.9.2, 1.11.0, 1.12.0
>Reporter: John Blum
>Priority: Major
> Labels: JSON-PDX
>
> The Jackson {{ObjectMapper}} in the {{PdxInstanceImpl}} class (see
> [here|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/pdx/internal/PdxInstanceImpl.java#L68-L75])is
> not properly configured.
> Specifically, it cannot handle *Java 8* types since these types are not
> included in Jackson 2, by default, primarily because Jackson 2 is based on
> Java 6 (not Java 8). However, that does not mean Jackson 2 cannot handle
> Java 8 types, when configured properly with extension modules.
> To make matters worse, the {{ObjectMapper}} used by PDX, and specifically the
> {{PdxInstance}} implementation, violates the _Open/Closed_ software design
> principle, so there is literally no way to modify (i.e. override/extend) the
> configuration of the {{ObjectMapper}} as required by the application.
> See
> [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/java/org/springframework/geode/data/json/JsonCacheDataImporterExporterIntegrationTests.java#L583-L618]
> for a test case demonstrating the issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8254) JSONFormatter cannot parse JSON Arrays
[ https://issues.apache.org/jira/browse/GEODE-8254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-8254: - Affects Version/s: 1.10.0 1.9.2 1.11.0 1.12.0 > JSONFormatter cannot parse JSON Arrays > -- > > Key: GEODE-8254 > URL: https://issues.apache.org/jira/browse/GEODE-8254 > Project: Geode > Issue Type: Improvement > Components: serialization >Affects Versions: 1.10.0, 1.9.2, 1.11.0, 1.12.0 >Reporter: John Blum >Priority: Major > Labels: JSON-PDX > > The Apache Geode > [JSONFormatter|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html] > class is not capable of parsing/processing JSON Arrays, making it less than > adequate to process JSON documents and content. > This leaves the responsibility and burden on the user, which requires the > user to inspect the individual array elements. > A test case reproducing this issue can be found > [here|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html]. > The matching JSON document is > [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/resources/data-example-doefamily.json]. > JSON Arrays are a very common JSON data type, as > [specified|https://www.json.org/json-en.html]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8256) The Jackson ObjectMapper used by a PdxInstance does not properly handle Java 8 Types
[
https://issues.apache.org/jira/browse/GEODE-8256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8256:
-
Affects Version/s: 1.10.0
1.9.2
1.11.0
1.12.0
> The Jackson ObjectMapper used by a PdxInstance does not properly handle Java
> 8 Types
>
>
> Key: GEODE-8256
> URL: https://issues.apache.org/jira/browse/GEODE-8256
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Affects Versions: 1.10.0, 1.9.2, 1.11.0, 1.12.0
>Reporter: John Blum
>Priority: Major
>
> The Jackson {{ObjectMapper}} in the {{PdxInstanceImpl}} class (see
> [here|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/pdx/internal/PdxInstanceImpl.java#L68-L75])is
> not properly configured.
> Specifically, it cannot handle *Java 8* types since these types are not
> included in Jackson 2, by default, primarily because Jackson 2 is based on
> Java 6 (not Java 8). However, that does not mean Jackson 2 cannot handle
> Java 8 types, when configured properly with extension modules.
> To make matters worse, the {{ObjectMapper}} used by PDX, and specifically the
> {{PdxInstance}} implementation, violates the _Open/Closed_ software design
> principle, so there is literally no way to modify (i.e. override/extend) the
> configuration of the {{ObjectMapper}} as required by the application.
> See
> [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/java/org/springframework/geode/data/json/JsonCacheDataImporterExporterIntegrationTests.java#L583-L618]
> for a test case demonstrating the issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8256) The Jackson ObjectMapper used by a PdxInstance does not properly handle Java 8 Types
[
https://issues.apache.org/jira/browse/GEODE-8256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8256:
-
Component/s: serialization
> The Jackson ObjectMapper used by a PdxInstance does not properly handle Java
> 8 Types
>
>
> Key: GEODE-8256
> URL: https://issues.apache.org/jira/browse/GEODE-8256
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Reporter: John Blum
>Priority: Major
>
> The Jackson {{ObjectMapper}} in the {{PdxInstanceImpl}} class (see
> [here|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/pdx/internal/PdxInstanceImpl.java#L68-L75])is
> not properly configured.
> Specifically, it cannot handle *Java 8* types since these types are not
> included in Jackson 2, by default, primarily because Jackson 2 is based on
> Java 6 (not Java 8). However, that does not mean Jackson 2 cannot handle
> Java 8 types, when configured properly with extension modules.
> To make matters worse, the {{ObjectMapper}} used by PDX, and specifically the
> {{PdxInstance}} implementation, violates the _Open/Closed_ software design
> principle, so there is literally no way to modify (i.e. override/extend) the
> configuration of the {{ObjectMapper}} as required by the application.
> See
> [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/java/org/springframework/geode/data/json/JsonCacheDataImporterExporterIntegrationTests.java#L583-L618]
> for a test case demonstrating the issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8256) The Jackson ObjectMapper used by a PdxInstance does not properly handle Java 8 Types
John Blum created GEODE-8256:
Summary: The Jackson ObjectMapper used by a PdxInstance does not
properly handle Java 8 Types
Key: GEODE-8256
URL: https://issues.apache.org/jira/browse/GEODE-8256
Project: Geode
Issue Type: Improvement
Reporter: John Blum
The Jackson {{ObjectMapper}} in the {{PdxInstanceImpl}} class (see
[here|https://github.com/apache/geode/blob/rel/v1.12.0/geode-core/src/main/java/org/apache/geode/pdx/internal/PdxInstanceImpl.java#L68-L75])is
not properly configured.
Specifically, it cannot handle *Java 8* types since these types are not
included in Jackson 2, by default, primarily because Jackson 2 is based on Java
6 (not Java 8). However, that does not mean Jackson 2 cannot handle Java 8
types, when configured properly with extension modules.
To make matters worse, the {{ObjectMapper}} used by PDX, and specifically the
{{PdxInstance}} implementation, violates the _Open/Closed_ software design
principle, so there is literally no way to modify (i.e. override/extend) the
configuration of the {{ObjectMapper}} as required by the application.
See
[here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/java/org/springframework/geode/data/json/JsonCacheDataImporterExporterIntegrationTests.java#L583-L618]
for a test case demonstrating the issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8255) JSONFormatter does not properly generate the @type metadata field
John Blum created GEODE-8255:
Summary: JSONFormatter does not properly generate the @type
metadata field
Key: GEODE-8255
URL: https://issues.apache.org/jira/browse/GEODE-8255
Project: Geode
Issue Type: Improvement
Components: serialization
Reporter: John Blum
The Apache Geode
[JSONFormatter|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html]
class is not symmetric.
While it can parse JSON content and properly resolve JSON Objects as POJOs
(from {{PdxInstance.getObject()}} when the {{@type}} metadata field is present
in the JSON content, the {{JSONFormatter}} does not properly set the {{@type}}
metadata field, particularly when a {{PdxInstance}} has a valid class name as
determined by
[PdxInstance.getClassName()|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/PdxInstance.html#getClassName--].
A test case illustrating this issue can be found
[here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/java/org/springframework/geode/data/json/JsonCacheDataImporterExporterIntegrationTests.java#L546-L580].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8255) JSONFormatter does not properly generate the @type metadata field
[
https://issues.apache.org/jira/browse/GEODE-8255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8255:
-
Labels: JSON-PDX (was: )
> JSONFormatter does not properly generate the @type metadata field
> -
>
> Key: GEODE-8255
> URL: https://issues.apache.org/jira/browse/GEODE-8255
> Project: Geode
> Issue Type: Improvement
> Components: serialization
>Reporter: John Blum
>Priority: Major
> Labels: JSON-PDX
>
> The Apache Geode
> [JSONFormatter|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html]
> class is not symmetric.
> While it can parse JSON content and properly resolve JSON Objects as POJOs
> (from {{PdxInstance.getObject()}} when the {{@type}} metadata field is
> present in the JSON content, the {{JSONFormatter}} does not properly set the
> {{@type}} metadata field, particularly when a {{PdxInstance}} has a valid
> class name as determined by
> [PdxInstance.getClassName()|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/PdxInstance.html#getClassName--].
> A test case illustrating this issue can be found
> [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/java/org/springframework/geode/data/json/JsonCacheDataImporterExporterIntegrationTests.java#L546-L580].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-8254) JSONFormatter cannot parse JSON Arrays
[ https://issues.apache.org/jira/browse/GEODE-8254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-8254: - Description: The Apache Geode [JSONFormatter|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html] class is not capable of parsing/processing JSON Arrays, making it less than adequate to process JSON documents and content. This leaves the responsibility and burden on the user, which requires the user to inspect the individual array elements. A test case reproducing this issue can be found [here|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html]. Matching JSON document is [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/resources/data-example-doefamily.json]. JSON Arrays are a very common JSON data type, as [specified|https://www.json.org/json-en.html]. was: The Apache Geode [JSONFormatter|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html] class is not capable of parsing/processing JSON Arrays, making it less than adequate to process JSON documents and content. This leave the responsibility and burden on the user, which requires the user to inspect the individual array elements. A test case reproducing this issue can be found [here|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html]. Matching JSON document is [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/resources/data-example-doefamily.json]. JSON Arrays are a very common JSON data type, as [specified|https://www.json.org/json-en.html]. > JSONFormatter cannot parse JSON Arrays > -- > > Key: GEODE-8254 > URL: https://issues.apache.org/jira/browse/GEODE-8254 > Project: Geode > Issue Type: Improvement > Components: serialization >Reporter: John Blum >Priority: Major > Labels: JSON-PDX > > The Apache Geode > [JSONFormatter|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html] > class is not capable of parsing/processing JSON Arrays, making it less than > adequate to process JSON documents and content. > This leaves the responsibility and burden on the user, which requires the > user to inspect the individual array elements. > A test case reproducing this issue can be found > [here|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html]. > Matching JSON document is > [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/resources/data-example-doefamily.json]. > JSON Arrays are a very common JSON data type, as > [specified|https://www.json.org/json-en.html]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8254) JSONFormatter cannot parse JSON Arrays
[ https://issues.apache.org/jira/browse/GEODE-8254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-8254: - Labels: JSON-PDX (was: ) > JSONFormatter cannot parse JSON Arrays > -- > > Key: GEODE-8254 > URL: https://issues.apache.org/jira/browse/GEODE-8254 > Project: Geode > Issue Type: Improvement > Components: serialization >Reporter: John Blum >Priority: Major > Labels: JSON-PDX > > The Apache Geode > [JSONFormatter|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html] > class is not capable of parsing/processing JSON Arrays, making it less than > adequate to process JSON documents and content. > This leave the responsibility and burden on the user, which requires the user > to inspect the individual array elements. > A test case reproducing this issue can be found > [here|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html]. > Matching JSON document is > [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/resources/data-example-doefamily.json]. > JSON Arrays are a very common JSON data type, as > [specified|https://www.json.org/json-en.html]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8254) JSONFormatter cannot parse JSON Arrays
[ https://issues.apache.org/jira/browse/GEODE-8254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-8254: - Description: The Apache Geode [JSONFormatter|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html] class is not capable of parsing/processing JSON Arrays, making it less than adequate to process JSON documents and content. This leaves the responsibility and burden on the user, which requires the user to inspect the individual array elements. A test case reproducing this issue can be found [here|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html]. The matching JSON document is [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/resources/data-example-doefamily.json]. JSON Arrays are a very common JSON data type, as [specified|https://www.json.org/json-en.html]. was: The Apache Geode [JSONFormatter|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html] class is not capable of parsing/processing JSON Arrays, making it less than adequate to process JSON documents and content. This leaves the responsibility and burden on the user, which requires the user to inspect the individual array elements. A test case reproducing this issue can be found [here|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html]. Matching JSON document is [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/resources/data-example-doefamily.json]. JSON Arrays are a very common JSON data type, as [specified|https://www.json.org/json-en.html]. > JSONFormatter cannot parse JSON Arrays > -- > > Key: GEODE-8254 > URL: https://issues.apache.org/jira/browse/GEODE-8254 > Project: Geode > Issue Type: Improvement > Components: serialization >Reporter: John Blum >Priority: Major > Labels: JSON-PDX > > The Apache Geode > [JSONFormatter|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html] > class is not capable of parsing/processing JSON Arrays, making it less than > adequate to process JSON documents and content. > This leaves the responsibility and burden on the user, which requires the > user to inspect the individual array elements. > A test case reproducing this issue can be found > [here|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html]. > The matching JSON document is > [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/resources/data-example-doefamily.json]. > JSON Arrays are a very common JSON data type, as > [specified|https://www.json.org/json-en.html]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-8254) JSONFormatter cannot parse JSON Arrays
John Blum created GEODE-8254: Summary: JSONFormatter cannot parse JSON Arrays Key: GEODE-8254 URL: https://issues.apache.org/jira/browse/GEODE-8254 Project: Geode Issue Type: Improvement Components: serialization Reporter: John Blum The Apache Geode [JSONFormatter|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html] class is not capable of parsing/processing JSON Arrays, making it less than adequate to process JSON documents and content. This leave the responsibility and burden on the user, which requires the user to inspect the individual array elements. A test case reproducing this issue can be found [here|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/pdx/JSONFormatter.html]. Matching JSON document is [here|https://github.com/spring-projects/spring-boot-data-geode/blob/1.3.0.RELEASE/spring-geode/src/test/resources/data-example-doefamily.json]. JSON Arrays are a very common JSON data type, as [specified|https://www.json.org/json-en.html]. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (GEODE-8235) Server should not be required to have an available PDX type registry for ClientCache applications
[
https://issues.apache.org/jira/browse/GEODE-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17129896#comment-17129896
]
John Blum edited comment on GEODE-8235 at 6/9/20, 11:59 PM:
I also encounter this {{Exception}} as well, but this, like the
{{CacheClosedException}} is not helpful/useful:
{code}
Caused by: org.apache.geode.pdx.JSONFormatterException: Could not parse JSON
document: [Source:
(String)"{"@type":"example.app.golf.model.Golfer","id":1,"name":"John
Blum","handicap":9}"; line: 1, column: 81]
at
org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:206)
at org.apache.geode.pdx.JSONFormatter.fromJSON(JSONFormatter.java:134)
at
org.springframework.geode.data.json.converter.support.JSONFormatterJsonToPdxConverter.jsonFormatterFromJson(JSONFormatterJsonToPdxConverter.java:69)
at
org.springframework.geode.data.json.converter.support.JSONFormatterJsonToPdxConverter.convertJsonToPdx(JSONFormatterJsonToPdxConverter.java:57)
at
org.springframework.geode.data.json.converter.support.JSONFormatterJsonToPdxConverter.convert(JSONFormatterJsonToPdxConverter.java:42)
at
org.springframework.geode.data.json.converter.support.JSONFormatterJsonToPdxConverter.convert(JSONFormatterJsonToPdxConverter.java:35)
at
org.springframework.geode.data.json.converter.support.JacksonJsonToPdxConverter.convert(JacksonJsonToPdxConverter.java:124)
at
org.springframework.geode.data.json.converter.support.JacksonJsonToPdxConverter.convert(JacksonJsonToPdxConverter.java:52)
at
org.springframework.geode.data.json.converter.JsonToPdxArrayConverter.convert(JsonToPdxArrayConverter.java:48)
at
org.springframework.geode.data.json.JsonCacheDataImporterExporter.toPdxArray(JsonCacheDataImporterExporter.java:479)
at java.util.Optional.map(Optional.java:215)
at
org.springframework.geode.data.json.JsonCacheDataImporterExporter.doImportInto(JsonCacheDataImporterExporter.java:222)
at
org.springframework.geode.data.AbstractCacheDataImporterExporter.importInto(AbstractCacheDataImporterExporter.java:294)
at java.lang.Iterable.forEach(Iterable.java:75)
at
java.util.Collections$SynchronizedCollection.forEach(Collections.java:2064)
at
org.springframework.geode.data.support.LifecycleAwareCacheDataImporterExporter.start(LifecycleAwareCacheDataImporterExporter.java:238)
at
org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:182)
... 38 more
Caused by: org.apache.geode.cache.client.NoAvailableServersException
at
org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:277)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:125)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:108)
at
org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:774)
at
org.apache.geode.cache.client.internal.GetPDXIdForTypeOp.execute(GetPDXIdForTypeOp.java:38)
at
org.apache.geode.pdx.internal.ClientTypeRegistration.defineType(ClientTypeRegistration.java:69)
at
org.apache.geode.pdx.internal.TypeRegistry.defineType(TypeRegistry.java:202)
at
org.apache.geode.pdx.internal.TypeRegistry.defineLocalType(TypeRegistry.java:250)
at
org.apache.geode.pdx.internal.PdxWriterImpl.completeByteStreamGeneration(PdxWriterImpl.java:540)
at
org.apache.geode.pdx.internal.PdxInstanceFactoryImpl.create(PdxInstanceFactoryImpl.java:64)
at
org.apache.geode.pdx.internal.json.PdxInstanceHelper.endObjectField(PdxInstanceHelper.java:209)
at
org.apache.geode.pdx.JSONFormatter.getPdxInstance(JSONFormatter.java:309)
at
org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:199)
... 54 more
{code}
I know there are not servers because that was deliberate given my
{{ClientCache}} (application) configuration only contains client {{LOCAL}}
Regions.
This also proves that relying on either the thrown {{Exception}} or (naively)
the message is not reliable.
was (Author: jblum):
I also encounter this {{Exception}} as well, but this, like the
{{CacheClosedException}} is not helpful/useful:
{code}
Caused by: org.apache.geode.pdx.JSONFormatterException: Could not parse JSON
document: [Source:
(String)"{"@type":"example.app.golf.model.Golfer","id":1,"name":"John
Blum","handicap":9}"; line: 1, column: 81]
at
org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:206)
at org.apache.geode.pdx.JSONFormatter.fromJSON(JSONFormatter.java:134)
at
org.springframework.geode.data.json.converter.support.JSONFormatterJsonToPdxConverter.jsonFormatterFromJson(JSONFormatterJsonToPdxCo
[jira] [Comment Edited] (GEODE-8235) Server should not be required to have an available PDX type registry for ClientCache applications
[
https://issues.apache.org/jira/browse/GEODE-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17129896#comment-17129896
]
John Blum edited comment on GEODE-8235 at 6/9/20, 11:59 PM:
I also encounter this {{Exception}} as well, but this, like the
{{CacheClosedException}} is not helpful/useful:
{code}
Caused by: org.apache.geode.pdx.JSONFormatterException: Could not parse JSON
document: [Source:
(String)"{"@type":"example.app.golf.model.Golfer","id":1,"name":"John
Blum","handicap":9}"; line: 1, column: 81]
at
org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:206)
at org.apache.geode.pdx.JSONFormatter.fromJSON(JSONFormatter.java:134)
at
org.springframework.geode.data.json.converter.support.JSONFormatterJsonToPdxConverter.jsonFormatterFromJson(JSONFormatterJsonToPdxConverter.java:69)
at
org.springframework.geode.data.json.converter.support.JSONFormatterJsonToPdxConverter.convertJsonToPdx(JSONFormatterJsonToPdxConverter.java:57)
at
org.springframework.geode.data.json.converter.support.JSONFormatterJsonToPdxConverter.convert(JSONFormatterJsonToPdxConverter.java:42)
at
org.springframework.geode.data.json.converter.support.JSONFormatterJsonToPdxConverter.convert(JSONFormatterJsonToPdxConverter.java:35)
at
org.springframework.geode.data.json.converter.support.JacksonJsonToPdxConverter.convert(JacksonJsonToPdxConverter.java:124)
at
org.springframework.geode.data.json.converter.support.JacksonJsonToPdxConverter.convert(JacksonJsonToPdxConverter.java:52)
at
org.springframework.geode.data.json.converter.JsonToPdxArrayConverter.convert(JsonToPdxArrayConverter.java:48)
at
org.springframework.geode.data.json.JsonCacheDataImporterExporter.toPdxArray(JsonCacheDataImporterExporter.java:479)
at java.util.Optional.map(Optional.java:215)
at
org.springframework.geode.data.json.JsonCacheDataImporterExporter.doImportInto(JsonCacheDataImporterExporter.java:222)
at
org.springframework.geode.data.AbstractCacheDataImporterExporter.importInto(AbstractCacheDataImporterExporter.java:294)
at java.lang.Iterable.forEach(Iterable.java:75)
at
java.util.Collections$SynchronizedCollection.forEach(Collections.java:2064)
at
org.springframework.geode.data.support.LifecycleAwareCacheDataImporterExporter.start(LifecycleAwareCacheDataImporterExporter.java:238)
at
org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:182)
... 38 more
Caused by: org.apache.geode.cache.client.NoAvailableServersException
at
org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:277)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:125)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:108)
at
org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:774)
at
org.apache.geode.cache.client.internal.GetPDXIdForTypeOp.execute(GetPDXIdForTypeOp.java:38)
at
org.apache.geode.pdx.internal.ClientTypeRegistration.defineType(ClientTypeRegistration.java:69)
at
org.apache.geode.pdx.internal.TypeRegistry.defineType(TypeRegistry.java:202)
at
org.apache.geode.pdx.internal.TypeRegistry.defineLocalType(TypeRegistry.java:250)
at
org.apache.geode.pdx.internal.PdxWriterImpl.completeByteStreamGeneration(PdxWriterImpl.java:540)
at
org.apache.geode.pdx.internal.PdxInstanceFactoryImpl.create(PdxInstanceFactoryImpl.java:64)
at
org.apache.geode.pdx.internal.json.PdxInstanceHelper.endObjectField(PdxInstanceHelper.java:209)
at
org.apache.geode.pdx.JSONFormatter.getPdxInstance(JSONFormatter.java:309)
at
org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:199)
... 54 more
{code}
I know there are not servers because that was deliberate given my
{{ClientCache}} (application) configuration only contains client {{LOCAL}}
Regions.
This also proves that relying on the thrown {{Exception}} or the message is not
reliable.
was (Author: jblum):
I also encounter this {{Exception}} as well, but this, like the
{{CacheClosedException}} is not helpful/useful:
{code}
Caused by: org.apache.geode.pdx.JSONFormatterException: Could not parse JSON
document: [Source:
(String)"{"@type":"example.app.golf.model.Golfer","id":1,"name":"John
Blum","handicap":9}"; line: 1, column: 81]
at
org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:206)
at org.apache.geode.pdx.JSONFormatter.fromJSON(JSONFormatter.java:134)
at
org.springframework.geode.data.json.converter.support.JSONFormatterJsonToPdxConverter.jsonFormatterFromJson(JSONFormatterJsonToPdxConverter.java:69)
[jira] [Commented] (GEODE-8235) Server should not be required to have an available PDX type registry for ClientCache applications
[
https://issues.apache.org/jira/browse/GEODE-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17129896#comment-17129896
]
John Blum commented on GEODE-8235:
--
I also encounter this {{Exception}} as well, but this, like the
{{CacheClosedException}} is not helpful/useful:
{code}
Caused by: org.apache.geode.pdx.JSONFormatterException: Could not parse JSON
document: [Source:
(String)"{"@type":"example.app.golf.model.Golfer","id":1,"name":"John
Blum","handicap":9}"; line: 1, column: 81]
at
org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:206)
at org.apache.geode.pdx.JSONFormatter.fromJSON(JSONFormatter.java:134)
at
org.springframework.geode.data.json.converter.support.JSONFormatterJsonToPdxConverter.jsonFormatterFromJson(JSONFormatterJsonToPdxConverter.java:69)
at
org.springframework.geode.data.json.converter.support.JSONFormatterJsonToPdxConverter.convertJsonToPdx(JSONFormatterJsonToPdxConverter.java:57)
at
org.springframework.geode.data.json.converter.support.JSONFormatterJsonToPdxConverter.convert(JSONFormatterJsonToPdxConverter.java:42)
at
org.springframework.geode.data.json.converter.support.JSONFormatterJsonToPdxConverter.convert(JSONFormatterJsonToPdxConverter.java:35)
at
org.springframework.geode.data.json.converter.support.JacksonJsonToPdxConverter.convert(JacksonJsonToPdxConverter.java:124)
at
org.springframework.geode.data.json.converter.support.JacksonJsonToPdxConverter.convert(JacksonJsonToPdxConverter.java:52)
at
org.springframework.geode.data.json.converter.JsonToPdxArrayConverter.convert(JsonToPdxArrayConverter.java:48)
at
org.springframework.geode.data.json.JsonCacheDataImporterExporter.toPdxArray(JsonCacheDataImporterExporter.java:479)
at java.util.Optional.map(Optional.java:215)
at
org.springframework.geode.data.json.JsonCacheDataImporterExporter.doImportInto(JsonCacheDataImporterExporter.java:222)
at
org.springframework.geode.data.AbstractCacheDataImporterExporter.importInto(AbstractCacheDataImporterExporter.java:294)
at java.lang.Iterable.forEach(Iterable.java:75)
at
java.util.Collections$SynchronizedCollection.forEach(Collections.java:2064)
at
org.springframework.geode.data.support.LifecycleAwareCacheDataImporterExporter.start(LifecycleAwareCacheDataImporterExporter.java:238)
at
org.springframework.context.support.DefaultLifecycleProcessor.doStart(DefaultLifecycleProcessor.java:182)
... 38 more
Caused by: org.apache.geode.cache.client.NoAvailableServersException
at
org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:277)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:125)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.execute(OpExecutorImpl.java:108)
at
org.apache.geode.cache.client.internal.PoolImpl.execute(PoolImpl.java:774)
at
org.apache.geode.cache.client.internal.GetPDXIdForTypeOp.execute(GetPDXIdForTypeOp.java:38)
at
org.apache.geode.pdx.internal.ClientTypeRegistration.defineType(ClientTypeRegistration.java:69)
at
org.apache.geode.pdx.internal.TypeRegistry.defineType(TypeRegistry.java:202)
at
org.apache.geode.pdx.internal.TypeRegistry.defineLocalType(TypeRegistry.java:250)
at
org.apache.geode.pdx.internal.PdxWriterImpl.completeByteStreamGeneration(PdxWriterImpl.java:540)
at
org.apache.geode.pdx.internal.PdxInstanceFactoryImpl.create(PdxInstanceFactoryImpl.java:64)
at
org.apache.geode.pdx.internal.json.PdxInstanceHelper.endObjectField(PdxInstanceHelper.java:209)
at
org.apache.geode.pdx.JSONFormatter.getPdxInstance(JSONFormatter.java:309)
at
org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:199)
... 54 more
{code}
I know there are not servers because that was deliberate given my
{{ClientCache}} (application) configuration only contains client {{LOCAL}}
Regions.
> Server should not be required to have an available PDX type registry for
> ClientCache applications
> -
>
> Key: GEODE-8235
> URL: https://issues.apache.org/jira/browse/GEODE-8235
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: John Blum
>Priority: Major
> Labels: JSON-PDX
>
> As an application developer using Apache Geode, if I create a {{ClientCache}}
> application that contains client {{LOCAL}}
> Regions only (i.e. with {{ClientRegionShortcut.LOCAL}}) and I attempt to
> store objects in PDX serialized format, then Geode will throw an
> inappropriate {{Exception}}:
> ACTUAL:
> {code}
>
[jira] [Comment Edited] (GEODE-8235) Server should not be required to have an available PDX type registry for ClientCache applications
[
https://issues.apache.org/jira/browse/GEODE-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17129890#comment-17129890
]
John Blum edited comment on GEODE-8235 at 6/9/20, 11:35 PM:
The reason why the {{Exception}}, and specifically the {{CacheClosedException}}
is "inappropriate" (essentially unhelpful and useless) in this case is because
an application developer could possibly "catch" and handle this situation in
his/her application by converting the JSON to an Object, or some other form.
But, a {{CacheClosedException}} could be thrown by Geode for countless reasons,
which leaves a developer to have to parse the clumsy {{Exception}} message,
which is naive and error prone.
A more appropriate {{PdxTypeRegistryNotAvailableException}} (a
{{RuntimeException}}) would have been more appropriate, even if wrapped in a
{{CacheClosedException}} because perhaps the {{ClientCache}} is closing.
However, I would argue that a {{region.put(key, pdxBytes);}} should not cause a
{{ClientCache}} application failure and subsequently close the cache
unnecessarily from underneath the app, especially since this condition IS
recoverable.
was (Author: jblum):
The reason why the {{Exception}}, and specifically the {{CacheClosedException}}
is "inappropriate" (essentially unhelpful and useless) in this case is because,
I could possibly handle this situation in my application by converting the JSON
to an Object or some other form, but a {{CacheClosedException}} could be thrown
by Geode for countless reasons, which leaves a developer to have to parse the
clumsy {{Exception}} message, which is naive and error prone.
A more appropriate {{PdxTypeRegistryNotAvailableException}} (a
{{RuntimeException}}) would have been more appropriate, even if wrapped in a
{{CacheClosedException}} because perhaps the {{ClientCache}} is closing.
However, I would argue that a {{region.put(key, pdxBytes);}} should not cause a
{{ClientCache}} application failure and subsequently close the cache
unnecessarily from underneath the app, especially since this condition IS
recoverable.
> Server should not be required to have an available PDX type registry for
> ClientCache applications
> -
>
> Key: GEODE-8235
> URL: https://issues.apache.org/jira/browse/GEODE-8235
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: John Blum
>Priority: Major
> Labels: JSON-PDX
>
> As an application developer using Apache Geode, if I create a {{ClientCache}}
> application that contains client {{LOCAL}}
> Regions only (i.e. with {{ClientRegionShortcut.LOCAL}}) and I attempt to
> store objects in PDX serialized format, then Geode will throw an
> inappropriate {{Exception}}:
> ACTUAL:
> {code}
> Caused by: org.apache.geode.pdx.JSONFormatterException: Could not parse JSON
> document: [Source:
> (String)"{"@type":"example.app.model.Customer","id":1,"name":"Jon Doe"}";
> line: 1, column: 63]
> at
> org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:206)
> ~[geode-core-1.12.0.jar:na]
> at org.apache.geode.pdx.JSONFormatter.fromJSON(JSONFormatter.java:134)
> ~[geode-core-1.12.0.jar:na]
> at ...
> ... 39 common frames omitted
> Caused by: org.apache.geode.cache.CacheClosedException: Client pools have
> been closed so the PDX type registry is not available.
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1630)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1619)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.ClientTypeRegistration.getAllPools(ClientTypeRegistration.java:153)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.ClientTypeRegistration.defineType(ClientTypeRegistration.java:63)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.TypeRegistry.defineType(TypeRegistry.java:202)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.TypeRegistry.defineLocalType(TypeRegistry.java:250)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.PdxWriterImpl.completeByteStreamGeneration(PdxWriterImpl.java:540)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.PdxInstanceFactoryImpl.create(PdxInstanceFactoryImpl.java:64)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.json.PdxInstanceHelper.endObjectField(PdxInstanceHelper.java:209)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.JSONFormatter.getPdxInstance(JSONFormatter.java:309)
> ~[geode-core-1.
[jira] [Commented] (GEODE-8235) Server should not be required to have an available PDX type registry for ClientCache applications
[
https://issues.apache.org/jira/browse/GEODE-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17129890#comment-17129890
]
John Blum commented on GEODE-8235:
--
The reason why the {{Exception}}, and specifically the {{CacheClosedException}}
is "inappropriate" (essentially unhelpful and useless) in this case is because,
I could possibly handle this situation in my application by converting the JSON
to an Object or some other form, but a {{CacheClosedException}} could be thrown
by Geode for countless reasons, which leaves a developer to have to parse the
clumsy {{Exception}} message, which is naive and error prone.
A more appropriate {{PdxTypeRegistryNotAvailableException}} (a
{{RuntimeException}}) would have been more appropriate, even if wrapped in a
{{CacheClosedException}} because perhaps the {{ClientCache}} is closing.
However, I would argue that a {{region.put(key, pdxBytes);}} should not cause a
{{ClientCache}} application failure and subsequently close the cache
unnecessarily from underneath the app, especially since this condition IS
recoverable.
> Server should not be required to have an available PDX type registry for
> ClientCache applications
> -
>
> Key: GEODE-8235
> URL: https://issues.apache.org/jira/browse/GEODE-8235
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: John Blum
>Priority: Major
> Labels: JSON-PDX
>
> As an application developer using Apache Geode, if I create a {{ClientCache}}
> application that contains client {{LOCAL}}
> Regions only (i.e. with {{ClientRegionShortcut.LOCAL}}) and I attempt to
> store objects in PDX serialized format, then Geode will throw an
> inappropriate {{Exception}}:
> ACTUAL:
> {code}
> Caused by: org.apache.geode.pdx.JSONFormatterException: Could not parse JSON
> document: [Source:
> (String)"{"@type":"example.app.model.Customer","id":1,"name":"Jon Doe"}";
> line: 1, column: 63]
> at
> org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:206)
> ~[geode-core-1.12.0.jar:na]
> at org.apache.geode.pdx.JSONFormatter.fromJSON(JSONFormatter.java:134)
> ~[geode-core-1.12.0.jar:na]
> at ...
> ... 39 common frames omitted
> Caused by: org.apache.geode.cache.CacheClosedException: Client pools have
> been closed so the PDX type registry is not available.
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1630)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1619)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.ClientTypeRegistration.getAllPools(ClientTypeRegistration.java:153)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.ClientTypeRegistration.defineType(ClientTypeRegistration.java:63)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.TypeRegistry.defineType(TypeRegistry.java:202)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.TypeRegistry.defineLocalType(TypeRegistry.java:250)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.PdxWriterImpl.completeByteStreamGeneration(PdxWriterImpl.java:540)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.PdxInstanceFactoryImpl.create(PdxInstanceFactoryImpl.java:64)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.json.PdxInstanceHelper.endObjectField(PdxInstanceHelper.java:209)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.JSONFormatter.getPdxInstance(JSONFormatter.java:309)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:199)
> ~[geode-core-1.12.0.jar:na]
> ... 55 common frames omitted
> {code}
> First of all this is not even an appropriate Exception!
> {{CacheCloseException}} because my client had no open Pools to an available
> server with a PDX type registry.
> 1. Creating client local-only applications not connected to an entire cluster
> or server is a very useful and practical arrangement during development.
> 2. My application should not have to be a peer {{Cache}} to have an available
> PDX type registry to store PDX instances in client {{LOCAL}} Regions.
> 3. It is actually highly useful to run my application in local-only mode, in
> a local-only context (i.e. with only client {{LOCAL}} Regions) without a
> cluster or server for development, testing and debugging purposes.
> 4. It is also really useful if my application can also store PDX bytes, even
> in client {{LOCAL}} (only) Regions for development, testing and debugging
[jira] [Updated] (GEODE-8235) Server should not be required to have an available PDX type registry for ClientCache applications
[
https://issues.apache.org/jira/browse/GEODE-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8235:
-
Description:
As an application developer using Apache Geode, if I create a {{ClientCache}}
application that contains client {{LOCAL}}
Regions only (i.e. with {{ClientRegionShortcut.LOCAL}}) and I attempt to store
objects in PDX serialized format, then Geode will throw an inappropriate
{{Exception}}:
ACTUAL:
{code}
Caused by: org.apache.geode.pdx.JSONFormatterException: Could not parse JSON
document: [Source:
(String)"{"@type":"example.app.model.Customer","id":1,"name":"Jon Doe"}"; line:
1, column: 63]
at
org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:206)
~[geode-core-1.12.0.jar:na]
at org.apache.geode.pdx.JSONFormatter.fromJSON(JSONFormatter.java:134)
~[geode-core-1.12.0.jar:na]
at ...
... 39 common frames omitted
Caused by: org.apache.geode.cache.CacheClosedException: Client pools have been
closed so the PDX type registry is not available.
at
org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1630)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1619)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.internal.ClientTypeRegistration.getAllPools(ClientTypeRegistration.java:153)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.internal.ClientTypeRegistration.defineType(ClientTypeRegistration.java:63)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.internal.TypeRegistry.defineType(TypeRegistry.java:202)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.internal.TypeRegistry.defineLocalType(TypeRegistry.java:250)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.internal.PdxWriterImpl.completeByteStreamGeneration(PdxWriterImpl.java:540)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.internal.PdxInstanceFactoryImpl.create(PdxInstanceFactoryImpl.java:64)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.internal.json.PdxInstanceHelper.endObjectField(PdxInstanceHelper.java:209)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.JSONFormatter.getPdxInstance(JSONFormatter.java:309)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:199)
~[geode-core-1.12.0.jar:na]
... 55 common frames omitted
{code}
First of all this is not even an appropriate Exception!
{{CacheCloseException}} because my client had no open Pools to an available
server with a PDX type registry.
1. Creating client local-only applications not connected to an entire cluster
or server is a very useful and practical arrangement during development.
2. My application should not have to be a peer {{Cache}} to have an available
PDX type registry to store PDX instances in client {{LOCAL}} Regions.
3. It is actually highly useful to run my application in local-only mode, in a
local-only context (i.e. with only client {{LOCAL}} Regions) without a cluster
or server for development, testing and debugging purposes.
4. It is also really useful if my application can also store PDX bytes, even in
client {{LOCAL}} (only) Regions for development, testing and debugging purposes.
Some find it hard to imagine why an application would want to do this, store
PDX instead of POJOs. However, consider the fact that my application might be
part of a larger Microservices architecture that communicate via a RESTful
interfaces. They pass JSON back and forth, which might either be complex or
unstructured. Either way, it is possible I don't have or don't want to create
POJOs (types) matching the JSON that my Microservice consumes. I simply want
access to certain bits of information which PDX is adequately suited for.
These client LOCAL Regions might even be temporary. When connected, I might
even want to share this data (or aggregated data) with Native Clients which
most certainly won't have Java types matching the JSON content, raw or
summarized.
EXPECTED:
As a developer using Apache Geode, I expected to be able to develop (primarily)
{{ClientCache}} applications, run them locally with client {{LOCAL}} Regions,
storing data in PDX format as necessary, all without requiring a complex setup
(e.g. such as a cluster or a server).
was:
As application developer using Apache Geode, if I create a {{ClientCache}}
application that contains client {{LOCAL}} (only) Regions (i.e. with
{{ClientRegionShortcut.LOCAL}} and I attempt to store objects in PDX serialized
form, then Geode will throw an Exception:
ACTUAL:
{code}
Caused by: org.apache.geode.pdx.JSONFormatterException: Could not parse JSON
document: [Source:
(String)"{"@type":"example.app.model.Customer","id":1,"name":"Jon Doe"}"; line
[jira] [Updated] (GEODE-8235) Server should not be required to have an available PDX type registry for ClientCache applications
[
https://issues.apache.org/jira/browse/GEODE-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8235:
-
Labels: JSON-PDX (was: )
> Server should not be required to have an available PDX type registry for
> ClientCache applications
> -
>
> Key: GEODE-8235
> URL: https://issues.apache.org/jira/browse/GEODE-8235
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: John Blum
>Priority: Major
> Labels: JSON-PDX
>
> As application developer using Apache Geode, if I create a {{ClientCache}}
> application that contains client {{LOCAL}} (only) Regions (i.e. with
> {{ClientRegionShortcut.LOCAL}} and I attempt to store objects in PDX
> serialized form, then Geode will throw an Exception:
> ACTUAL:
> {code}
> Caused by: org.apache.geode.pdx.JSONFormatterException: Could not parse JSON
> document: [Source:
> (String)"{"@type":"example.app.model.Customer","id":1,"name":"Jon Doe"}";
> line: 1, column: 63]
> at
> org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:206)
> ~[geode-core-1.12.0.jar:na]
> at org.apache.geode.pdx.JSONFormatter.fromJSON(JSONFormatter.java:134)
> ~[geode-core-1.12.0.jar:na]
> at ...
> ... 39 common frames omitted
> Caused by: org.apache.geode.cache.CacheClosedException: Client pools have
> been closed so the PDX type registry is not available.
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1630)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1619)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.ClientTypeRegistration.getAllPools(ClientTypeRegistration.java:153)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.ClientTypeRegistration.defineType(ClientTypeRegistration.java:63)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.TypeRegistry.defineType(TypeRegistry.java:202)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.TypeRegistry.defineLocalType(TypeRegistry.java:250)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.PdxWriterImpl.completeByteStreamGeneration(PdxWriterImpl.java:540)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.PdxInstanceFactoryImpl.create(PdxInstanceFactoryImpl.java:64)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.json.PdxInstanceHelper.endObjectField(PdxInstanceHelper.java:209)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.JSONFormatter.getPdxInstance(JSONFormatter.java:309)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:199)
> ~[geode-core-1.12.0.jar:na]
> ... 55 common frames omitted
> {code}
> First of all this is not even an appropriate Exception!
> {{CacheCloseException}} because my client had no open Pools to an available
> server with a PDX type registry.
> 1. Creating client local-only applications not connected to an entire cluster
> or server is a very useful and practical arrangement during development.
> 2. My application should not have to be a peer {{Cache}} to have an available
> PDX type registry to store PDX instances in client {{LOCAL}} Regions.
> 3. It is actually highly useful to run my application in local-only mode, in
> a local-only context (i.e. with only client {{LOCAL}} Regions) without a
> cluster or server for development, testing and debugging purposes.
> 4. It is also really useful if my application can also store PDX bytes, even
> in client {{LOCAL}} (only) Regions for development, testing and debugging
> purposes.
> Some find it hard to imagine why an application would want to do this, store
> PDX instead of POJOs. However, consider the fact that my application might
> be part of a larger Microservices architecture that communicate via a RESTful
> interfaces. They pass JSON back and forth, which might either be complex or
> unstructured. Either way, it is possible I don't have or don't want to
> create POJOs (types) matching the JSON that my Microservice consumes. I
> simply want access to certain bits of information which PDX is adequately
> suited for. These client LOCAL Regions might even be temporary. When
> connected, I might even want to share this data (or aggregated data) with
> Native Clients which most certainly won't have Java types matching the JSON
> content, raw or summarized.
> EXPECTED:
> As a developer using Apache Geode, I expected to be able to develop
> (primarily) {{ClientCache}} applications, run them locally with clien
[jira] [Updated] (GEODE-8235) Server should not be required to have an available PDX type registry for ClientCache applications
[
https://issues.apache.org/jira/browse/GEODE-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8235:
-
Summary: Server should not be required to have an available PDX type
registry for ClientCache applications (was: Server should not be required to
have available a PDX type registry in ClientCache applications)
> Server should not be required to have an available PDX type registry for
> ClientCache applications
> -
>
> Key: GEODE-8235
> URL: https://issues.apache.org/jira/browse/GEODE-8235
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: John Blum
>Priority: Major
>
> As application developer using Apache Geode, if I create a {{ClientCache}}
> application that contains client {{LOCAL}} (only) Regions (i.e. with
> {{ClientRegionShortcut.LOCAL}} and I attempt to store objects in PDX
> serialized form, then Geode will throw an Exception:
> ACTUAL:
> {code}
> Caused by: org.apache.geode.pdx.JSONFormatterException: Could not parse JSON
> document: [Source:
> (String)"{"@type":"example.app.model.Customer","id":1,"name":"Jon Doe"}";
> line: 1, column: 63]
> at
> org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:206)
> ~[geode-core-1.12.0.jar:na]
> at org.apache.geode.pdx.JSONFormatter.fromJSON(JSONFormatter.java:134)
> ~[geode-core-1.12.0.jar:na]
> at ...
> ... 39 common frames omitted
> Caused by: org.apache.geode.cache.CacheClosedException: Client pools have
> been closed so the PDX type registry is not available.
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1630)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1619)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.ClientTypeRegistration.getAllPools(ClientTypeRegistration.java:153)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.ClientTypeRegistration.defineType(ClientTypeRegistration.java:63)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.TypeRegistry.defineType(TypeRegistry.java:202)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.TypeRegistry.defineLocalType(TypeRegistry.java:250)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.PdxWriterImpl.completeByteStreamGeneration(PdxWriterImpl.java:540)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.PdxInstanceFactoryImpl.create(PdxInstanceFactoryImpl.java:64)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.json.PdxInstanceHelper.endObjectField(PdxInstanceHelper.java:209)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.JSONFormatter.getPdxInstance(JSONFormatter.java:309)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:199)
> ~[geode-core-1.12.0.jar:na]
> ... 55 common frames omitted
> {code}
> First of all this is not even an appropriate Exception!
> {{CacheCloseException}} because my client had no open Pools to an available
> server with a PDX type registry.
> 1. Creating client local-only applications not connected to an entire cluster
> or server is a very useful and practical arrangement during development.
> 2. My application should not have to be a peer {{Cache}} to have an available
> PDX type registry to store PDX instances in client {{LOCAL}} Regions.
> 3. It is actually highly useful to run my application in local-only mode, in
> a local-only context (i.e. with only client {{LOCAL}} Regions) without a
> cluster or server for development, testing and debugging purposes.
> 4. It is also really useful if my application can also store PDX bytes, even
> in client {{LOCAL}} (only) Regions for development, testing and debugging
> purposes.
> Some find it hard to imagine why an application would want to do this, store
> PDX instead of POJOs. However, consider the fact that my application might
> be part of a larger Microservices architecture that communicate via a RESTful
> interfaces. They pass JSON back and forth, which might either be complex or
> unstructured. Either way, it is possible I don't have or don't want to
> create POJOs (types) matching the JSON that my Microservice consumes. I
> simply want access to certain bits of information which PDX is adequately
> suited for. These client LOCAL Regions might even be temporary. When
> connected, I might even want to share this data (or aggregated data) with
> Native Clients which most certainly won't have Java types matching the JSON
> content, raw or summarized.
[jira] [Commented] (GEODE-8235) Server should not be required to have available a PDX type registry in ClientCache applications
[
https://issues.apache.org/jira/browse/GEODE-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17129885#comment-17129885
]
John Blum commented on GEODE-8235:
--
The following test case reproduces the problem:
{code:java}
@Test
public void jsonToPdxProcessingUsingApacheGeodeApi() {
ClientCache clientCache = null;
try {
Customer jonDoe = Customer.create(1L, "Jon Doe");
clientCache = new ClientCacheFactory().create();
Region customers =
clientCache.createClientRegionFactory(ClientRegionShortcut.LOCAL)
.create("Customers");
String json = "{"
+ " \"@type\": \"example.app.model.Customer\","
+ " \"id\": 1,"
+ " \"name\": \"Jon Doe\""
+ "}";
PdxInstance pdxInstance = JSONFormatter.fromJSON(json);
customers.put(1, pdxInstance);
Object value = customers.get(1);
assertThat(value).isInstanceOf(PdxInstance.class);
assertThat(((PdxInstance)
value).getObject()).isEqualTo(jonDoe);
}
finally {
Optional.ofNullable(clientCache).ifPresent(ClientCache::close);
}
}
{code}
The {{Customer}} class definition is simple:
{code:java}
package example.app.model;
import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.NoArgsConstructor;
import lombok.ToString;
@Data
@ToString(of = "name")
@NoArgsConstructor
@AllArgsConstructor(staticName = "create")
public class Customer {
private Long id;
private String name;
}
{code}
While I do have a {{Customer}} class definition to match the JSON (Customer)
object in this case, that is not always the case, but I also wanted to test
another problem with {{PdxInstance.getObject()}}.
> Server should not be required to have available a PDX type registry in
> ClientCache applications
> ---
>
> Key: GEODE-8235
> URL: https://issues.apache.org/jira/browse/GEODE-8235
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: John Blum
>Priority: Major
>
> As application developer using Apache Geode, if I create a {{ClientCache}}
> application that contains client {{LOCAL}} (only) Regions (i.e. with
> {{ClientRegionShortcut.LOCAL}} and I attempt to store objects in PDX
> serialized form, then Geode will throw an Exception:
> ACTUAL:
> {code}
> Caused by: org.apache.geode.pdx.JSONFormatterException: Could not parse JSON
> document: [Source:
> (String)"{"@type":"example.app.model.Customer","id":1,"name":"Jon Doe"}";
> line: 1, column: 63]
> at
> org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:206)
> ~[geode-core-1.12.0.jar:na]
> at org.apache.geode.pdx.JSONFormatter.fromJSON(JSONFormatter.java:134)
> ~[geode-core-1.12.0.jar:na]
> at ...
> ... 39 common frames omitted
> Caused by: org.apache.geode.cache.CacheClosedException: Client pools have
> been closed so the PDX type registry is not available.
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1630)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1619)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.ClientTypeRegistration.getAllPools(ClientTypeRegistration.java:153)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.ClientTypeRegistration.defineType(ClientTypeRegistration.java:63)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.TypeRegistry.defineType(TypeRegistry.java:202)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.TypeRegistry.defineLocalType(TypeRegistry.java:250)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.PdxWriterImpl.completeByteStreamGeneration(PdxWriterImpl.java:540)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.PdxInstanceFactoryImpl.create(PdxInstanceFactoryImpl.java:64)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.json.PdxInstanceHelper.endObjectField(PdxInstanceHelper.java:209)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.JSONFormatter.getPdxInstance(JSONFormatter.java:309)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.JSONFormatter.toPdxInstance(
[jira] [Updated] (GEODE-8235) Server should not be required to have available a PDX type registry in ClientCache applications
[
https://issues.apache.org/jira/browse/GEODE-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8235:
-
Description:
As application developer using Apache Geode, if I create a {{ClientCache}}
application that contains client {{LOCAL}} (only) Regions (i.e. with
{{ClientRegionShortcut.LOCAL}} and I attempt to store objects in PDX serialized
form, then Geode will throw an Exception:
ACTUAL:
{code}
Caused by: org.apache.geode.pdx.JSONFormatterException: Could not parse JSON
document: [Source:
(String)"{"@type":"example.app.model.Customer","id":1,"name":"Jon Doe"}"; line:
1, column: 63]
at
org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:206)
~[geode-core-1.12.0.jar:na]
at org.apache.geode.pdx.JSONFormatter.fromJSON(JSONFormatter.java:134)
~[geode-core-1.12.0.jar:na]
at ...
... 39 common frames omitted
Caused by: org.apache.geode.cache.CacheClosedException: Client pools have been
closed so the PDX type registry is not available.
at
org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1630)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1619)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.internal.ClientTypeRegistration.getAllPools(ClientTypeRegistration.java:153)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.internal.ClientTypeRegistration.defineType(ClientTypeRegistration.java:63)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.internal.TypeRegistry.defineType(TypeRegistry.java:202)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.internal.TypeRegistry.defineLocalType(TypeRegistry.java:250)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.internal.PdxWriterImpl.completeByteStreamGeneration(PdxWriterImpl.java:540)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.internal.PdxInstanceFactoryImpl.create(PdxInstanceFactoryImpl.java:64)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.internal.json.PdxInstanceHelper.endObjectField(PdxInstanceHelper.java:209)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.JSONFormatter.getPdxInstance(JSONFormatter.java:309)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:199)
~[geode-core-1.12.0.jar:na]
... 55 common frames omitted
{code}
First of all this is not even an appropriate Exception!
{{CacheCloseException}} because my client had no open Pools to an available
server with a PDX type registry.
1. Creating client local-only applications not connected to an entire cluster
or server is a very useful and practical arrangement during development.
2. My application should not have to be a peer {{Cache}} to have an available
PDX type registry to store PDX instances in client {{LOCAL}} Regions.
3. It is actually highly useful to run my application in local-only mode, in a
local-only context (i.e. with only client {{LOCAL}} Regions) without a cluster
or server for development, testing and debugging purposes.
4. It is also really useful if my application can also store PDX bytes, even in
client {{LOCAL}} (only) Regions for development, testing and debugging purposes.
Some find it hard to imagine why an application would want to do this, store
PDX instead of POJOs. However, consider the fact that my application might be
part of a larger Microservices architecture that communicate via a RESTful
interfaces. They pass JSON back and forth, which might either be complex or
unstructured. Either way, it is possible I don't have or don't want to create
POJOs (types) matching the JSON that my Microservice consumes. I simply want
access to certain bits of information which PDX is adequately suited for.
These client LOCAL Regions might even be temporary. When connected, I might
even want to share this data (or aggregated data) with Native Clients which
most certainly won't have Java types matching the JSON content, raw or
summarized.
EXPECTED:
As a developer using Apache Geode, I expected to be able to develop (primarily)
{{ClientCache}} applications, run them locally with client {{LOCAL}} Regions,
storing data in PDX format as necessary, all without requiring a complex setup
(e.g. such as a cluster or a server).
was:
As application developer using Apache Geode, if I create a {{ClientCache}}
application that contains client {{LOCAL}} (only) Regions (i.e. with
{{ClientRegionShortcut.LOCAL}} and I attempt to store objects in PDX serialized
form, then Geode will throw an Exception:
{code}
Caused by: org.apache.geode.pdx.JSONFormatterException: Could not parse JSON
document: [Source:
(String)"{"@type":"example.app.model.Customer","id":1,"name":"Jon Doe"}"; line:
1, column: 63]
at
or
[jira] [Updated] (GEODE-8235) Server should not be required to have available a PDX type registry in ClientCache applications
[
https://issues.apache.org/jira/browse/GEODE-8235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-8235:
-
Summary: Server should not be required to have available a PDX type
registry in ClientCache applications (was: Server should not be required to
have available a PDX type registry)
> Server should not be required to have available a PDX type registry in
> ClientCache applications
> ---
>
> Key: GEODE-8235
> URL: https://issues.apache.org/jira/browse/GEODE-8235
> Project: Geode
> Issue Type: Bug
> Components: serialization
>Reporter: John Blum
>Priority: Major
>
> As application developer using Apache Geode, if I create a {{ClientCache}}
> application that contains client {{LOCAL}} (only) Regions (i.e. with
> {{ClientRegionShortcut.LOCAL}} and I attempt to store objects in PDX
> serialized form, then Geode will throw an Exception:
> {code}
> Caused by: org.apache.geode.pdx.JSONFormatterException: Could not parse JSON
> document: [Source:
> (String)"{"@type":"example.app.model.Customer","id":1,"name":"Jon Doe"}";
> line: 1, column: 63]
> at
> org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:206)
> ~[geode-core-1.12.0.jar:na]
> at org.apache.geode.pdx.JSONFormatter.fromJSON(JSONFormatter.java:134)
> ~[geode-core-1.12.0.jar:na]
> at ...
> ... 39 common frames omitted
> Caused by: org.apache.geode.cache.CacheClosedException: Client pools have
> been closed so the PDX type registry is not available.
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1630)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1619)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.ClientTypeRegistration.getAllPools(ClientTypeRegistration.java:153)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.ClientTypeRegistration.defineType(ClientTypeRegistration.java:63)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.TypeRegistry.defineType(TypeRegistry.java:202)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.TypeRegistry.defineLocalType(TypeRegistry.java:250)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.PdxWriterImpl.completeByteStreamGeneration(PdxWriterImpl.java:540)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.PdxInstanceFactoryImpl.create(PdxInstanceFactoryImpl.java:64)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.internal.json.PdxInstanceHelper.endObjectField(PdxInstanceHelper.java:209)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.JSONFormatter.getPdxInstance(JSONFormatter.java:309)
> ~[geode-core-1.12.0.jar:na]
> at
> org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:199)
> ~[geode-core-1.12.0.jar:na]
> ... 55 common frames omitted
> {code}
> First of all this is not even an appropriate Exception!
> {{CacheCloseException}} because my client had no open Pools to an available
> server with a PDX type registry.
> 1. Creating client local-only applications not connected to an entire cluster
> or server is a very useful and practical arrangement during development.
> 2. My application should not have to be a peer {{Cache}} to have an available
> PDX type registry to store PDX instances in client {{LOCAL}} Regions.
> 3. It is actually highly useful to run my application in local-only mode, in
> a local-only context (i.e. with only client {{LOCAL}} Regions) without a
> cluster or server for development, testing and debugging purposes.
> 4. It is also really useful if my application can also store PDX bytes, even
> in client {{LOCAL}} (only) Regions for development, testing and debugging
> purposes.
> Some find it hard to imagine why an application would want to do this, store
> PDX instead of POJOs. However, consider the fact that my application might
> be part of a larger Microservices architecture that communicate via a RESTful
> interfaces. They pass JSON back and forth, which might either be complex or
> unstructured. Either way, it is possible I don't have or don't want to
> create POJOs (types) matching the JSON that my Microservice consumes. I
> simply want access to certain bits of information which PDX is adequately
> suited for. These client LOCAL Regions might even be temporary. When
> connected, I might even want to share this data (or aggregated data) with
> Native Clients which most certainly won't have Java types matching the JSON
> content, raw or summarized.
--
This message was sent by Atlassian Ji
[jira] [Created] (GEODE-8235) Server should not be required to have available a PDX type registry
John Blum created GEODE-8235:
Summary: Server should not be required to have available a PDX
type registry
Key: GEODE-8235
URL: https://issues.apache.org/jira/browse/GEODE-8235
Project: Geode
Issue Type: Bug
Components: serialization
Reporter: John Blum
As application developer using Apache Geode, if I create a {{ClientCache}}
application that contains client {{LOCAL}} (only) Regions (i.e. with
{{ClientRegionShortcut.LOCAL}} and I attempt to store objects in PDX serialized
form, then Geode will throw an Exception:
{code}
Caused by: org.apache.geode.pdx.JSONFormatterException: Could not parse JSON
document: [Source:
(String)"{"@type":"example.app.model.Customer","id":1,"name":"Jon Doe"}"; line:
1, column: 63]
at
org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:206)
~[geode-core-1.12.0.jar:na]
at org.apache.geode.pdx.JSONFormatter.fromJSON(JSONFormatter.java:134)
~[geode-core-1.12.0.jar:na]
at ...
... 39 common frames omitted
Caused by: org.apache.geode.cache.CacheClosedException: Client pools have been
closed so the PDX type registry is not available.
at
org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1630)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.internal.cache.GemFireCacheImpl.getCacheClosedException(GemFireCacheImpl.java:1619)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.internal.ClientTypeRegistration.getAllPools(ClientTypeRegistration.java:153)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.internal.ClientTypeRegistration.defineType(ClientTypeRegistration.java:63)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.internal.TypeRegistry.defineType(TypeRegistry.java:202)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.internal.TypeRegistry.defineLocalType(TypeRegistry.java:250)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.internal.PdxWriterImpl.completeByteStreamGeneration(PdxWriterImpl.java:540)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.internal.PdxInstanceFactoryImpl.create(PdxInstanceFactoryImpl.java:64)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.internal.json.PdxInstanceHelper.endObjectField(PdxInstanceHelper.java:209)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.JSONFormatter.getPdxInstance(JSONFormatter.java:309)
~[geode-core-1.12.0.jar:na]
at
org.apache.geode.pdx.JSONFormatter.toPdxInstance(JSONFormatter.java:199)
~[geode-core-1.12.0.jar:na]
... 55 common frames omitted
{code}
First of all this is not even an appropriate Exception!
{{CacheCloseException}} because my client had no open Pools to an available
server with a PDX type registry.
1. Creating client local-only applications not connected to an entire cluster
or server is a very useful and practical arrangement during development.
2. My application should not have to be a peer {{Cache}} to have an available
PDX type registry to store PDX instances in client {{LOCAL}} Regions.
3. It is actually highly useful to run my application in local-only mode, in a
local-only context (i.e. with only client {{LOCAL}} Regions) without a cluster
or server for development, testing and debugging purposes.
4. It is also really useful if my application can also store PDX bytes, even in
client {{LOCAL}} (only) Regions for development, testing and debugging purposes.
Some find it hard to imagine why an application would want to do this, store
PDX instead of POJOs. However, consider the fact that my application might be
part of a larger Microservices architecture that communicate via a RESTful
interfaces. They pass JSON back and forth, which might either be complex or
unstructured. Either way, it is possible I don't have or don't want to create
POJOs (types) matching the JSON that my Microservice consumes. I simply want
access to certain bits of information which PDX is adequately suited for.
These client LOCAL Regions might even be temporary. When connected, I might
even want to share this data (or aggregated data) with Native Clients which
most certainly won't have Java types matching the JSON content, raw or
summarized.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7201) Useless and unhelpful Exception inappropriately logged at ERROR
[
https://issues.apache.org/jira/browse/GEODE-7201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-7201:
-
Description:
For testing, it is valid that I might register interests on a client Region
where the server-side Region is a PARTITION Region, yet I am not using either
mcast-port or Locators since I only need a single server for my tests!
Therefore this Exception is not helpful in anyway and only adds confusion to
the user...
{code}
08:59:51 Caused by: java.lang.IllegalStateException: Should not register
interest for a partitioned region when mcast-port is 0 and no locator is present
08:59:51at
org.apache.geode.internal.cache.tier.sockets.command.RegisterInterest61.cmdExecute(RegisterInterest61.java:257)
08:59:51at
org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)
08:59:51at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
08:59:51at
org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
08:59:51at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
08:59:51at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
08:59:51at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
08:59:51at
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
08:59:51at
org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
08:59:51... 1 more
{code}
So, I "should" not...
> "_Should not register interest for a partitioned region when mcast-port is 0
> and no locator is present_"
Why not?
And, why does this message need to be logged at ERROR? WARN would suffice,
especially since "_should_" implies a "_recommendation_" and not a strict, hard
rule or requirement, which would rather be appropriately stated as "_Must not
register interest..._".
was:
For testing, it is valid that I might register interests on a client Region
where the server-side Region is a PARTITION Region, yet I am not using either
mcast-port or Locators since I only need a single server for my tests!
Therefore this Exception is not helpful in anyway and only adds confusion to
the user...
{code}
08:59:51 Caused by: java.lang.IllegalStateException: Should not register
interest for a partitioned region when mcast-port is 0 and no locator is present
08:59:51at
org.apache.geode.internal.cache.tier.sockets.command.RegisterInterest61.cmdExecute(RegisterInterest61.java:257)
08:59:51at
org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)
08:59:51at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
08:59:51at
org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
08:59:51at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
08:59:51at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
08:59:51at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
08:59:51at
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
08:59:51at
org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
08:59:51... 1 more
{code}
So, I "should" not...
> "_Should not register interest for a partitioned region when mcast-port is 0
> and no locator is present_"
Why not?
And, why does this message need to be logged at ERROR? WARN would suffice,
especially since "_should_" implies a "_recommendation_" and not a strict, hard
rule or requirement, which would be appropriate states as "_Must not register
interest..._".
> Useless and unhelpful Exception inappropriately logged at ERROR
> ---
>
> Key: GEODE-7201
> URL: https://issues.apache.org/jira/browse/GEODE-7201
> Project: Geode
> Issue Type: Bug
>Reporter: John Blum
>Priority: Major
> Labels: affects-spring
>
> For testing, it is valid that I might register interests on a client Region
> where the server-side Region is a PARTITION Region, yet I am not using either
> mcast-port or Locators since I only need a single server for my tests!
> Therefore this Exception is not helpful in anyway and only adds confusion to
> the user...
> {code}
> 08:59:51 Caused
[jira] [Updated] (GEODE-7382) ReflectionBasedSerializer should consider using the greediest application domain object type constructor it can find to satisfy the values of the domain object
[ https://issues.apache.org/jira/browse/GEODE-7382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-7382: - Summary: ReflectionBasedSerializer should consider using the greediest application domain object type constructor it can find to satisfy the values of the domain object (was: ReflectionBasedSerializer should consider using the greediest application domain type constructor it can find to satisfy the values of the domain object) > ReflectionBasedSerializer should consider using the greediest application > domain object type constructor it can find to satisfy the values of the > domain object > --- > > Key: GEODE-7382 > URL: https://issues.apache.org/jira/browse/GEODE-7382 > Project: Geode > Issue Type: Improvement >Reporter: John Blum >Priority: Major > > ... Regardless of whether or not... > 1. There exists a public, no-arg constructor or NOT (since a default, public, > no-arg constructor is not required in Java). > 2. And whether or not that constructor is public or not (which also does not > matter in Java) > 3. And simply because constructors provide initialization safety that setters > and field injection simply cannot as specified by the JVM spec. > Also, consider what happens when the object class type is _immutable_. That > is, all object initialization must happen through a constructor since the > object is immutable, which are inherently Thread-safe. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-7201) Useless and unhelpful Exception inappropriately logged at ERROR
[
https://issues.apache.org/jira/browse/GEODE-7201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-7201:
-
Description:
For testing, it is valid that I might register interests on a client Region
where the server-side Region is a PARTITION Region, yet I am not using either
mcast-port or Locators since I only need a single server for my tests!
Therefore this Exception is not helpful in anyway and only adds confusion to
the user...
{code}
08:59:51 Caused by: java.lang.IllegalStateException: Should not register
interest for a partitioned region when mcast-port is 0 and no locator is present
08:59:51at
org.apache.geode.internal.cache.tier.sockets.command.RegisterInterest61.cmdExecute(RegisterInterest61.java:257)
08:59:51at
org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)
08:59:51at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:848)
08:59:51at
org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:72)
08:59:51at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1212)
08:59:51at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
08:59:51at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
08:59:51at
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:676)
08:59:51at
org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
08:59:51... 1 more
{code}
So, I "should" not...
> "_Should not register interest for a partitioned region when mcast-port is 0
> and no locator is present_"
Why not?
And, why does this message need to be logged at ERROR? WARN would suffice,
especially since "_should_" implies a "_recommendation_" and not a strict, hard
rule or requirement, which would be appropriate states as "_Must not register
interest..._".
was:
For testing, it is valid that I might register interests on a client Region
where the server-side Region is a PARTITION Region, yet I am not using either
mcast-port or Locators since I only need a single server for my tests!
Therefore this Exception is not helpful in anyway and only adds confusion to
the user...
{code}
at
org.apache.geode.internal.cache.tier.sockets.command.RegisterInterest61.cmdExecute(RegisterInterest61.java:257)
at
org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:183)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:851)
at
org.apache.geode.internal.cache.tier.sockets.OriginalServerConnection.doOneMessage(OriginalServerConnection.java:75)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1227)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:616)
at
org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121)
... 1 common frames omitted
{code}
So, I "should" not...
> "_Should not register interest for a partitioned region when mcast-port is 0
> and no locator is present_"
Why not?
And, why does this message need to be logged at ERROR? WARN would suffice,
especially since "_should_" implies a "_recommendation_" and not a strict, hard
rule or requirement, which would be appropriate states as "_Must not register
interest..._".
> Useless and unhelpful Exception inappropriately logged at ERROR
> ---
>
> Key: GEODE-7201
> URL: https://issues.apache.org/jira/browse/GEODE-7201
> Project: Geode
> Issue Type: Bug
>Reporter: John Blum
>Priority: Major
> Labels: affects-spring
>
> For testing, it is valid that I might register interests on a client Region
> where the server-side Region is a PARTITION Region, yet I am not using either
> mcast-port or Locators since I only need a single server for my tests!
> Therefore this Exception is not helpful in anyway and only adds confusion to
> the user...
> {code}
> 08:59:51 Caused by: java.lang.IllegalStateException: Should not register
> interest for a partitioned region when mcast-port is 0 and no locator is
> present
> 08:59:51 at
> org.apache.geode.internal.cache.tier.sockets.command.RegisterInterest61.
[jira] [Updated] (GEODE-7891) User Guide refers to non-valid GemFire Properties
[
https://issues.apache.org/jira/browse/GEODE-7891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-7891:
-
Description:
The following properties in [GemFire
Properties|https://geode.apache.org/docs/guide/111/reference/topics/gemfire_properties.html]
are *NOT* valid (distributed system/config properties) according to the
[ConfigurationProperties|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java]
and
[DistributionConfig|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionConfig.java]
classes!
Properties include:
{code:java}
"geode.disallow-internal-messages-without-credentials"
"tombstone-gc-threshold"
{code}
was:
The following properties in [GemFire
Properties|https://geode.apache.org/docs/guide/111/reference/topics/gemfire_properties.html]
are *NOT* valid (distributed system/config properties) according to the
[ConfigurationProperties|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java]
and
[DistributionConfig|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionConfig.java]
classes!
> User Guide refers to non-valid GemFire Properties
> -
>
> Key: GEODE-7891
> URL: https://issues.apache.org/jira/browse/GEODE-7891
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: John Blum
>Priority: Major
>
> The following properties in [GemFire
> Properties|https://geode.apache.org/docs/guide/111/reference/topics/gemfire_properties.html]
> are *NOT* valid (distributed system/config properties) according to the
> [ConfigurationProperties|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java]
> and
> [DistributionConfig|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionConfig.java]
> classes!
> Properties include:
> {code:java}
> "geode.disallow-internal-messages-without-credentials"
> "tombstone-gc-threshold"
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7891) User Guide refers to non-valid GemFire Properties
[ https://issues.apache.org/jira/browse/GEODE-7891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Blum updated GEODE-7891: - Summary: User Guide refers to non-valid GemFire Properties (was: User Guide contains non-valid GemFire Properties) > User Guide refers to non-valid GemFire Properties > - > > Key: GEODE-7891 > URL: https://issues.apache.org/jira/browse/GEODE-7891 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: John Blum >Priority: Major > > The following properties in [GemFire > Properties|https://geode.apache.org/docs/guide/111/reference/topics/gemfire_properties.html] > are *NOT* valid (distributed system/config properties) according to the > [ConfigurationProperties|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java] > and > [DistributionConfig|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionConfig.java] > classes! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-7891) User Guide contains non-valid GemFire Properties
John Blum created GEODE-7891: Summary: User Guide contains non-valid GemFire Properties Key: GEODE-7891 URL: https://issues.apache.org/jira/browse/GEODE-7891 Project: Geode Issue Type: Bug Components: docs Reporter: John Blum The following properties in [GemFire Properties|https://geode.apache.org/docs/guide/111/reference/topics/gemfire_properties.html] are *NOT* valid (distributed system/config properties) according to the [ConfigurationProperties|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java] and [DistributionConfig|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/internal/DistributionConfig.java] classes! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-7890) @Deprecated ConfigurationProperties should be applied consistently
[
https://issues.apache.org/jira/browse/GEODE-7890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17061362#comment-17061362
]
John Blum commented on GEODE-7890:
--
By my account the following property constants (by name) in
{{ConfigurationProperties}} are not properly annotated with {{@Deprecated}},
however their _Javadoc_ includes the {{@deprecated}} meta Javadoc tag:
{code:java}
private static final Set deprecatedGemFireProperties =
Collections.unmodifiableSet(new HashSet<>(Arrays.asList(
"cluster-ssl-ciphers", // all 'cluster-ssl-*' properties
replaced by 'ssl-*' properties
"cluster-ssl-enabled",
"cluster-ssl-keystore",
"cluster-ssl-keystore-password",
"cluster-ssl-keystore-type",
"cluster-ssl-protocols",
"cluster-ssl-require-authentication",
"cluster-ssl-truststore",
"cluster-ssl-truststore-password",
"jmx-manager-http-port", // replaced by 'http-service-port'
property
"roles",
"security-client-accessor", // replaced by SecurityManager
"security-client-accessor-pp", // replaced by SecurityManager
"security-client-authenticator", // replaced by SecurityManager
"security-client-dhalgo", // use SSL instead
"security-peer-authenticator" // replaced by SecurityManager
)));
{code}
> @Deprecated ConfigurationProperties should be applied consistently
> --
>
> Key: GEODE-7890
> URL: https://issues.apache.org/jira/browse/GEODE-7890
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Priority: Minor
>
> The {{@Deprecated}} annotation was *not* appropriately and consistently
> applied to ALL
> [org.apache.geode.distributed.ConfigurationProperties|http://example.com]
> constants representing Apache Geode properties!
> For instance, all {{cluster-ssl-\*}} properties have been *deprecated* as
> indicated by the
> [CLUSTER_SSL_PREFIX|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L169-L170]
> as well as the _Javadoc_ comments for individual {{CLUSTER_SSL_\*}} property
> constants, for
> [instance|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L210].
> However, the actually
> [constant|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L212]
> is *NOT* properly annotated with {{@Deprecated}}.
> This is unlike other property constants which have been properly *deprecated*
> using the {{@Deprecated}} annotation. For instance, the
> [Javadoc|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L559-L560]
> and the {{@Deprecated}}
> [Annotation|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L562-L563]
> applied to the constant.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7890) @Deprecated ConfigurationProperties should be applied consistently
[
https://issues.apache.org/jira/browse/GEODE-7890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-7890:
-
Priority: Minor (was: Major)
> @Deprecated ConfigurationProperties should be applied consistently
> --
>
> Key: GEODE-7890
> URL: https://issues.apache.org/jira/browse/GEODE-7890
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Priority: Minor
>
> The {{@Deprecated}} annotation was *not* appropriately and consistently
> applied to ALL
> [org.apache.geode.distributed.ConfigurationProperties|http://example.com]
> constants representing Apache Geode properties!
> For instance, all {{cluster-ssl-\*}} properties have been *deprecated* as
> indicated by the
> [CLUSTER_SSL_PREFIX|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L169-L170]
> as well as the _Javadoc_ comments for individual {{CLUSTER_SSL_\*}} property
> constants, for
> [instance|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L210].
> However, the actually
> [constant|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L212]
> is *NOT* properly annotated with {{@Deprecated}}.
> This is unlike other property constants which have been properly *deprecated*
> using the {{@Deprecated}} annotation. For instance, the
> [Javadoc|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L559-L560]
> and the {{@Deprecated}}
> [Annotation|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L562-L563]
> applied to the constant.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7890) @Deprecated ConfigurationProperties should be applied consistently
[
https://issues.apache.org/jira/browse/GEODE-7890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-7890:
-
Description:
The {{@Deprecated}} annotation was *not* appropriately and consistently applied
to ALL
[org.apache.geode.distributed.ConfigurationProperties|http://example.com]
constants representing Apache Geode properties!
For instance, all {{cluster-ssl-\*}} properties have been *deprecated* as
indicated by the
[CLUSTER_SSL_PREFIX|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L169-L170]
as well as the _Javadoc_ comments for individual {{CLUSTER_SSL_\*}} property
constants, for
[instance|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L210].
However, the actually
[constant|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L212]
is *NOT* properly annotated with {{@Deprecated}}.
This is unlike other property constants which have been properly *deprecated*
using the {{@Deprecated}} annotation. For instance, the
[Javadoc|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L559-L560]
and the {{@Deprecated}}
[Annotation|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L562-L563]
applied to the constant.
was:
The {{@Deprecated}} annotation was *not* appropriately and consistently applied
to ALL
[org.apache.geode.distributed.ConfigurationProperties|http://example.com]
constants representing Apache Geode properties!
For instance, all {{cluster-ssl-\*}} properties have been *deprecated* as
indicated by the
[CLUSTER_SSL_PREFIX|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L169-L170]
as well as the _Javadoc_ comments for individual {{CLUSTER_SSL_\*}} property
constants, for
[instance|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L210].
However, the actually
[constant|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L212]
is *NOT* properly annotated with {{@Deprecated}}.
This is unlike other property constants which have been properly *deprecated*
using the {{@Deprecated}} annotation. For instance, the
[Javadoc|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L559-L560]
and the {{@Deprecated}}
[annotation|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L562-L563]
applied to the constant.
> @Deprecated ConfigurationProperties should be applied consistently
> --
>
> Key: GEODE-7890
> URL: https://issues.apache.org/jira/browse/GEODE-7890
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Priority: Major
>
> The {{@Deprecated}} annotation was *not* appropriately and consistently
> applied to ALL
> [org.apache.geode.distributed.ConfigurationProperties|http://example.com]
> constants representing Apache Geode properties!
> For instance, all {{cluster-ssl-\*}} properties have been *deprecated* as
> indicated by the
> [CLUSTER_SSL_PREFIX|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L169-L170]
> as well as the _Javadoc_ comments for individual {{CLUSTER_SSL_\*}} property
> constants, for
> [instance|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L210].
> However, the actually
> [constant|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L212]
> is *NOT* properly annotated with {{@Deprecated}}.
> This is unlike other property constants which have been properly *deprecated*
> using the {{@Deprecated}} annotation. For instance, the
> [Javadoc|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L559-L560]
> and the {{@Deprecated}}
> [Annotation|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L562-L563]
> applied to the constant.
--
This message was sent by Atlass
[jira] [Updated] (GEODE-7890) @Deprecated ConfigurationProperties should be applied consistently
[
https://issues.apache.org/jira/browse/GEODE-7890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-7890:
-
Description:
The {{@Deprecated}} annotation was *not* appropriately and consistently applied
to ALL
[org.apache.geode.distributed.ConfigurationProperties|http://example.com]
constants representing Apache Geode properties!
For instance, all {{cluster-ssl-\*}} properties have been *deprecated* as
indicated by the
[CLUSTER_SSL_PREFIX|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L169-L170]
as well as the _Javadoc_ comments for individual {{CLUSTER_SSL_\*}} property
constants, for
[instance|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L210].
However, the actually
[constant|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L212]
is *NOT* properly annotated with {{@Deprecated}}.
This is unlike other property constants which have been properly *deprecated*
using the {{@Deprecated}} annotation. For instance, the
[Javadoc|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L559-L560]
and the {{@Deprecated}}
[annotation|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L562-L563]
applied to the constant.
was:
The {{@Deprecated}} annotation was *not* appropriately and consistently applied
to ALL
[org.apache.geode.distributed.ConfigurationProperties|http://example.com]
constants representing Apache Geode properties!
For instance, all {{cluster-ssl-\*}} properties have been *deprecated* as
indicated by the
[CLUSTER_SSL_PREFIX|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L169-L170]
as well as the _Javadoc_ comments for individual {{CLUSTER_SSL_\*}} property
constants, for
[instance|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L210].
However, the actually
[constant|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L212]
is *NOT* properly annotated with {{@Deprecated}}.
This is unlike other property constants which have been properly *deprecated*
using the {{@Deprecated}} annotation. For instance, the
[Javadoc|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L559-L560]
and the
[annotation|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L562-L563].
> @Deprecated ConfigurationProperties should be applied consistently
> --
>
> Key: GEODE-7890
> URL: https://issues.apache.org/jira/browse/GEODE-7890
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Priority: Major
>
> The {{@Deprecated}} annotation was *not* appropriately and consistently
> applied to ALL
> [org.apache.geode.distributed.ConfigurationProperties|http://example.com]
> constants representing Apache Geode properties!
> For instance, all {{cluster-ssl-\*}} properties have been *deprecated* as
> indicated by the
> [CLUSTER_SSL_PREFIX|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L169-L170]
> as well as the _Javadoc_ comments for individual {{CLUSTER_SSL_\*}} property
> constants, for
> [instance|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L210].
> However, the actually
> [constant|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L212]
> is *NOT* properly annotated with {{@Deprecated}}.
> This is unlike other property constants which have been properly *deprecated*
> using the {{@Deprecated}} annotation. For instance, the
> [Javadoc|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L559-L560]
> and the {{@Deprecated}}
> [annotation|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L562-L563]
> applied to the constant.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7890) @Deprecated ConfigurationProperties should be applied consistently
[
https://issues.apache.org/jira/browse/GEODE-7890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-7890:
-
Description:
The {{@Deprecated}} annotation was *not* appropriately and consistently applied
to ALL
[org.apache.geode.distributed.ConfigurationProperties|http://example.com]
constants representing Apache Geode properties!
For instance, all {{cluster-ssl-\*}} properties have been *deprecated* as
indicated by the
[CLUSTER_SSL_PREFIX|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L169-L170]
as well as the _Javadoc_ comments for individual {{CLUST_SSL_*}} property
constants, for
[instance|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L210].
However, the actually
[constant|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L212]
is *NOT* properly annotated with {{@Deprecated}}.
This is unlike other property constants which have been properly *deprecated*
using the {{@Deprecated}} annotation. For instance, the
[Javadoc|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L559-L560]
and the
[annotation|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L562-L563].
was:
The {{@Deprecated}} annotation was *not* appropriately and consistently applied
to ALL
[org.apache.geode.distributed.ConfigurationProperties|http://example.com]
constants representing Apache Geode properties!
For instance, all {{cluster-ssl-*}} properties have been *deprecated* as
indicated by the
[CLUSTER_SSL_PREFIX|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L169-L170]
as well as the _Javadoc_ comments for individual {{CLUST_SSL_*}} property
constants, for
[instance|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L210].
However, the actually
[constant|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L212]
is *NOT* properly annotated with {{@Deprecated}}.
This is unlike other property constants which have been properly *deprecated*
using the {{@Deprecated}} annotation. For instance, the
[Javadoc|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L559-L560]
and the
[annotation|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L562-L563].
> @Deprecated ConfigurationProperties should be applied consistently
> --
>
> Key: GEODE-7890
> URL: https://issues.apache.org/jira/browse/GEODE-7890
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Priority: Major
>
> The {{@Deprecated}} annotation was *not* appropriately and consistently
> applied to ALL
> [org.apache.geode.distributed.ConfigurationProperties|http://example.com]
> constants representing Apache Geode properties!
> For instance, all {{cluster-ssl-\*}} properties have been *deprecated* as
> indicated by the
> [CLUSTER_SSL_PREFIX|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L169-L170]
> as well as the _Javadoc_ comments for individual {{CLUST_SSL_*}} property
> constants, for
> [instance|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L210].
> However, the actually
> [constant|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L212]
> is *NOT* properly annotated with {{@Deprecated}}.
> This is unlike other property constants which have been properly *deprecated*
> using the {{@Deprecated}} annotation. For instance, the
> [Javadoc|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L559-L560]
> and the
> [annotation|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L562-L563].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-7890) @Deprecated ConfigurationProperties should be applied consistently
[
https://issues.apache.org/jira/browse/GEODE-7890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Blum updated GEODE-7890:
-
Description:
The {{@Deprecated}} annotation was *not* appropriately and consistently applied
to ALL
[org.apache.geode.distributed.ConfigurationProperties|http://example.com]
constants representing Apache Geode properties!
For instance, all {{cluster-ssl-\*}} properties have been *deprecated* as
indicated by the
[CLUSTER_SSL_PREFIX|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L169-L170]
as well as the _Javadoc_ comments for individual {{CLUSTER_SSL_\*}} property
constants, for
[instance|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L210].
However, the actually
[constant|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L212]
is *NOT* properly annotated with {{@Deprecated}}.
This is unlike other property constants which have been properly *deprecated*
using the {{@Deprecated}} annotation. For instance, the
[Javadoc|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L559-L560]
and the
[annotation|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L562-L563].
was:
The {{@Deprecated}} annotation was *not* appropriately and consistently applied
to ALL
[org.apache.geode.distributed.ConfigurationProperties|http://example.com]
constants representing Apache Geode properties!
For instance, all {{cluster-ssl-\*}} properties have been *deprecated* as
indicated by the
[CLUSTER_SSL_PREFIX|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L169-L170]
as well as the _Javadoc_ comments for individual {{CLUST_SSL_*}} property
constants, for
[instance|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L210].
However, the actually
[constant|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L212]
is *NOT* properly annotated with {{@Deprecated}}.
This is unlike other property constants which have been properly *deprecated*
using the {{@Deprecated}} annotation. For instance, the
[Javadoc|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L559-L560]
and the
[annotation|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L562-L563].
> @Deprecated ConfigurationProperties should be applied consistently
> --
>
> Key: GEODE-7890
> URL: https://issues.apache.org/jira/browse/GEODE-7890
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: John Blum
>Priority: Major
>
> The {{@Deprecated}} annotation was *not* appropriately and consistently
> applied to ALL
> [org.apache.geode.distributed.ConfigurationProperties|http://example.com]
> constants representing Apache Geode properties!
> For instance, all {{cluster-ssl-\*}} properties have been *deprecated* as
> indicated by the
> [CLUSTER_SSL_PREFIX|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L169-L170]
> as well as the _Javadoc_ comments for individual {{CLUSTER_SSL_\*}} property
> constants, for
> [instance|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L210].
> However, the actually
> [constant|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L212]
> is *NOT* properly annotated with {{@Deprecated}}.
> This is unlike other property constants which have been properly *deprecated*
> using the {{@Deprecated}} annotation. For instance, the
> [Javadoc|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L559-L560]
> and the
> [annotation|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L562-L563].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-7890) @Deprecated ConfigurationProperties should be applied consistently
John Blum created GEODE-7890:
Summary: @Deprecated ConfigurationProperties should be applied
consistently
Key: GEODE-7890
URL: https://issues.apache.org/jira/browse/GEODE-7890
Project: Geode
Issue Type: Bug
Components: configuration
Reporter: John Blum
The {{@Deprecated}} annotation was *not* appropriately and consistently applied
to ALL
[org.apache.geode.distributed.ConfigurationProperties|http://example.com]
constants representing Apache Geode properties!
For instance, all {{cluster-ssl-*}} properties have been *deprecated* as
indicated by the
[CLUSTER_SSL_PREFIX|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L169-L170]
as well as the _Javadoc_ comments for individual {{CLUST_SSL_*}} property
constants, for
[instance|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L210].
However, the actually
[constant|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L212]
is *NOT* properly annotated with {{@Deprecated}}.
This is unlike other property constants which have been properly *deprecated*
using the {{@Deprecated}} annotation. For instance, the
[Javadoc|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L559-L560]
and the
[annotation|https://github.com/apache/geode/blob/rel/v1.11.0/geode-core/src/main/java/org/apache/geode/distributed/ConfigurationProperties.java#L562-L563].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044881#comment-17044881
]
John Blum edited comment on GEODE-7763 at 2/25/20 9:15 PM:
---
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
accessed from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have client clustered
environments (e.g. multiple Kubernetes Nodes running instances of their _Spring
Session_ enabled Web applications), which is even further exasperated by the
users/customers Web applications making multiple HTTP client requests per
single "logical" HTTP request (such as is the case when a user loads a Web page
that contains AJAX calls, all of which are accessing the same logical Session
object (by ID)).
Anyway, all of this is to say, it would be extremely bad if the Session object
itself changed while being serialized, which is why the GemFire {{Session}} and
{{SessionAttibute}} object implementations in SSDG were carefully crafted with
intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true*.
Technically, it should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
was (Author: jblum):
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
accessed from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have client clustered
environments (e.g. multiple Kubernetes Nodes running instances of their _Spring
Session_ enabled Web applications), which is even further exasperated by the
users/customers Web applications making multiple HTTP client requests per
single "logical" HTTP request (such as is the case when a user loads a Web page
that contains AJAX calls, all of which are accessing the same logical Session
object (by ID)).
Anyway, all of this is to say, it would be extremely bad if the Session object
itself changed while being serialized, which is why the GemFire {{Session}} and
{{SessionAttibute}} object implementations in SSDG were carefully crafted with
intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
> Apache Geode 1.11 severely and negatively impacts perfor
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044881#comment-17044881
]
John Blum edited comment on GEODE-7763 at 2/25/20 9:14 PM:
---
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
accessed from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have client clustered
environments (e.g. multiple Kubernetes Nodes running instances of their _Spring
Session_ enabled Web applications), which is even further exasperated by the
users/customers Web applications making multiple HTTP client requests per
single "logical" HTTP request (such as is the case when a user loads a Web page
that contains AJAX calls, all of which are accessing the same logical Session
object (by ID)).
Anyway, all of this is to say, it would be extremely bad if the Session object
itself changed while being serialized, which is why the GemFire {{Session}} and
{{SessionAttibute}} object implementations in SSDG were carefully crafted with
intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
was (Author: jblum):
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
accessed from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have client clustered
environments (e.g. multiple Kubernetes Nodes running instances of their _Spring
Session_ enabled Web applications), which is even further exasperated by the
users/customers Web applications making multiple HTTP client requests per
single "logical" HTTP request (such as is the case when a user loads a Web page
that contains AJAX calls, all of which are accessing the same logical Session
object (by ID)).
Anyway, all of this is to say, that is would be extremely bad if the Session
object itself changed while being serialized, which is why the GemFire
{{Session}} and {{SessionAttibute}} object implementations in SSDG were
carefully crafted with intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
> Apache Geode 1.11 severely and negatively impacts performance and
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044881#comment-17044881
]
John Blum edited comment on GEODE-7763 at 2/25/20 9:13 PM:
---
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
accessed from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have client clustered
environments (e.g. multiple Kubernetes Nodes running instances of their _Spring
Session_ enabled Web applications) and even further exasperated by the
users/customers Web applications making multiple HTTP client requests per
single "logical" HTTP request (such as is the case when a user loads a Web page
that contains AJAX calls, all of which are accessing the same logical Session
object (by ID)).
Anyway, all of this is to say, that is would be extremely bad if the Session
object itself changed while being serialized, which is why the GemFire
{{Session}} and {{SessionAttibute}} object implementations in SSDG were
carefully crafted with intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
was (Author: jblum):
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
accessed from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have a client clustered
environments (e.g. multiple Kubernetes Nodes running instances of their _Spring
Session_ enabled Web applications) and even further exasperated by the
users/customers Web applications making multiple HTTP client requests per
single "logical" HTTP request (such as is the case when a user loads a Web page
that contains AJAX calls, all of which are accessing the same logical Session
object (by ID)).
Anyway, all of this is to say, that is would be extremely bad if the Session
object itself changed while being serialized, which is why the GemFire
{{Session}} and {{SessionAttibute}} object implementations in SSDG were
carefully crafted with intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
> Apache Geode 1.11 severely and negatively impacts performance and resou
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044881#comment-17044881
]
John Blum edited comment on GEODE-7763 at 2/25/20 9:13 PM:
---
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
accessed from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have client clustered
environments (e.g. multiple Kubernetes Nodes running instances of their _Spring
Session_ enabled Web applications), which is even further exasperated by the
users/customers Web applications making multiple HTTP client requests per
single "logical" HTTP request (such as is the case when a user loads a Web page
that contains AJAX calls, all of which are accessing the same logical Session
object (by ID)).
Anyway, all of this is to say, that is would be extremely bad if the Session
object itself changed while being serialized, which is why the GemFire
{{Session}} and {{SessionAttibute}} object implementations in SSDG were
carefully crafted with intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
was (Author: jblum):
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
accessed from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have client clustered
environments (e.g. multiple Kubernetes Nodes running instances of their _Spring
Session_ enabled Web applications) and even further exasperated by the
users/customers Web applications making multiple HTTP client requests per
single "logical" HTTP request (such as is the case when a user loads a Web page
that contains AJAX calls, all of which are accessing the same logical Session
object (by ID)).
Anyway, all of this is to say, that is would be extremely bad if the Session
object itself changed while being serialized, which is why the GemFire
{{Session}} and {{SessionAttibute}} object implementations in SSDG were
carefully crafted with intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
> Apache Geode 1.11 severely and negatively impacts performance and r
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044881#comment-17044881
]
John Blum edited comment on GEODE-7763 at 2/25/20 9:13 PM:
---
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
accessed from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have a client clustered
environments (e.g. multiple Kubernetes Nodes running instances of their _Spring
Session_ enabled Web applications) and even further exasperated by the
users/customers Web applications making multiple HTTP client requests per
single "logical" HTTP request (such as is the case when a user loads a Web page
that contains AJAX calls, all of which are accessing the same logical Session
object (by ID)).
Anyway, all of this is to say, that is would be extremely bad if the Session
object itself changed while being serialized, which is why the GemFire
{{Session}} and {{SessionAttibute}} object implementations in SSDG were
carefully crafted with intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
was (Author: jblum):
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
accessed from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have a client clustered
environment (e.g. Kubernetes Nodes running multiple instances of their Web
application) and even further exasperated by the users/customers Web
applications making multiple HTTP client requests per single "logical" HTTP
request (such as is the case when a user loads a Web page that contains AJAX
calls, all of which are accessing the same logical Session object (by ID)).
Anyway, all of this is to say, that is would be extremely bad if the Session
object itself changed while being serialized, which is why the GemFire
{{Session}} and {{SessionAttibute}} object implementations in SSDG were
carefully crafted with intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> -
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044881#comment-17044881
]
John Blum edited comment on GEODE-7763 at 2/25/20 9:12 PM:
---
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
accessed from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have a client clustered
environment (e.g. Kubernetes Nodes running multiple instances of their Web
application) and even further exasperated by the users/customers Web
applications making multiple HTTP client requests per single "logical" HTTP
request (such as is the case when a user loads a Web page that contains AJAX
calls, all of which are accessing the same logical Session object (by ID)).
Anyway, all of this is to say, that is would be extremely bad if the Session
object itself changed while being serialized, which is why the GemFire
{{Session}} and {{SessionAttibute}} object implementations in SSDG were
carefully crafted with intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
was (Author: jblum):
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
access from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have a client clustered
environment (e.g. Kubernetes Nodes running multiple instances of their Web
application) and even further exasperated by the users/customers Web
applications making multiple HTTP client requests per single "logical" HTTP
request (such as is the case when a user loads a Web page that contains AJAX
calls, all of which are accessing the same logical Session object (by ID)).
Anyway, all of this is to say, that is would be extremely bad if the Session
object itself changed while being serialized, which is why the GemFire
{{Session}} and {{SessionAttibute}} object implementations in SSDG were
carefully crafted with intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> ---
[jira] [Comment Edited] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044881#comment-17044881
]
John Blum edited comment on GEODE-7763 at 2/25/20 9:11 PM:
---
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
access from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have a client clustered
environment (e.g. Kubernetes Nodes running multiple instances of their Web
application) and even further exasperated by the users/customers Web
applications making multiple HTTP client requests per single "logical" HTTP
request (such as is the case when a user loads a Web page that contains AJAX
calls, all of which are accessing the same logical Session object (by ID)).
Anyway, all of this is to say, that is would be extremely bad if the Session
object itself changed while being serialized, which is why the GemFire
{{Session}} and {{SessionAttibute}} object implementations in SSDG were
carefully crafted with intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
was (Author: jblum):
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside a multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
access from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have a client clustered
environment (e.g. Kubernetes Nodes running multiple instances of their Web
application) and even further exasperated by the users/customers Web
applications making multiple HTTP client requests per single "logical" HTTP
request (such as is the case when a user loads a Web page that contains AJAX
calls, all of which are accessing the same logical Session object (by ID)).
Anyway, all of this is to say, that is would be extremely bad if the Session
object itself changed while being serialized, which is why the GemFire
{{Session}} and {{SessionAttibute}} object implementations in SSDG were
carefully crafted with intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> ---
[jira] [Commented] (GEODE-7763) Apache Geode 1.11 severely and negatively impacts performance and resource utilization
[
https://issues.apache.org/jira/browse/GEODE-7763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17044881#comment-17044881
]
John Blum commented on GEODE-7763:
--
Regarding the last
[comment|https://issues.apache.org/jira/browse/GEODE-7763?focusedCommentId=17039248&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17039248]...
The only feedback I can offer here is that {{Session}} object (and its
contained {{SessionAttributes}} helper object) must be properly guarded (i.e.
synchronized) inside a multi-Threaded environments, such as a Web/Servlet
container, where each HTTP request is processed by a separate Thread, which
means that the {{Session}} object (and {{SessionAttributes}} object) will be
access from multiple Threads, per HTTP client request. This is further
exasperated by the fact the some users/customers have a client clustered
environment (e.g. Kubernetes Nodes running multiple instances of their Web
application) and even further exasperated by the users/customers Web
applications making multiple HTTP client requests per single "logical" HTTP
request (such as is the case when a user loads a Web page that contains AJAX
calls, all of which are accessing the same logical Session object (by ID)).
Anyway, all of this is to say, that is would be extremely bad if the Session
object itself changed while being serialized, which is why the GemFire
{{Session}} and {{SessionAttibute}} object implementations in SSDG were
carefully crafted with intentional synchronization in mind.
While SSDG takes care to ensure (as much as possible) the GemFire {{Session}}
and {{SessionAttributes}} object implementations are Thread-safe, it is on the
users to ensure any object they stick in the {{Session}} (e.g. as a Session
attribute value) is Thread-safe.
I hope all this makes sense.
I am on the commit path for the changes [~boglesby] identified in SSDG,
specifically regarding cache Region entry LOCAL_LOAD_CREATE events. I have
already observed an improved SSDG build time.
I am going to do some more experiments with the
{{MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests}}
test class. I have already removed the {{copyOnRead}} setting of *true* it
should no longer be necessary with respect to [GEODE-6152].
I will report back once I have checked in, if you wish to continue the
test/analysis effort with the new SSDG bits.
Thanks!
> Apache Geode 1.11 severely and negatively impacts performance and resource
> utilization
> --
>
> Key: GEODE-7763
> URL: https://issues.apache.org/jira/browse/GEODE-7763
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.10.0, 1.11.0
>Reporter: John Blum
>Priority: Critical
> Labels: performance
> Attachments: 1.11-client-stats.gfs, 1.11-server-stats.gfs,
> 1.11_thread_dumps.rtf, 1.9-client-stats.gfs, 1.9-server-stats.gfs, 1.9.log,
> apache-geode-1.10-client-server-interaction-output.txt,
> apache-geode-1.10-client-server-startup-output.txt,
> apache-geode-1.11-client-server-interaction-output.txt,
> apache-geode-1.11-client-server-startup-output.txt,
> geode-7763-geode-changes.diff, geode-7763-ssdg-changes.diff
>
>
> This problem was first observed in Apache Geode 1.11.0. The problem was not
> present in Apache Geode 1.9.2. This problem is an issue for Apache Geode
> 1.10 as well!
> After upgrading _Spring Session for Apache Geode_ (SSDG) 2.3 to _Spring Data
> for Apache Geode_ (SDG) Neumann/2.3, which is based on Apache Geode 1.11,
> this problem with SSDG's test suite started occurring.
> _Spring Session for Apache Geode_ (SSDG) 2.2, which is based on _Spring Data
> for Apache Geode_ (SDG) Moore/2.2, pulls in Apache Geode 1.9.2. This problem
> did not occur in SSDG 2.2. with Apache Geode 1.9.2.
> Out of curiosity, I wondered whether this problem affects (i.e. was actually
> introduced in) Apache Geode 1.10.0. So, I configured SSDG 2.3 to pull in SDG
> Moore/2.2 but run with Apache Geode 1.10. The problem occurred with Apache
> Geode 1.10 as well!
> The SSDG test class in question, affected by Geode's deficiencies, is the
> [MultiThreadedHighlyConcurrentClientServerSessionOperationsIntegrationTests|https://github.com/spring-projects/spring-session-data-geode/blob/2.2.2.RELEASE/spring-session-data-geode/src/integration-test/java/org/springframework/session/data/gemfire/MultiThreadedHighlyConcurrentClientServerHttpSessionAccessIntegrationTests.java].
> The test class was modeled after a customer UC, who were using Spring Session
> and Apache Geode/Pivotal GemFire as the HTTP Session state management
> provider, therefore it simulates their highly concurrent environment.
> The test c
