Re: JDK 16 Support?

2021-05-10 Thread John Blum 
Found (encountered) another JDK 16 problem with Apache Geode (see StackTrace 
below).

Setting another (--add-opens JVM option to 'java.base/java.util=ALL-UNNAMED') 
resolves this issue for now.

2021-05-10 15:10:25,458 ERROR xecutors.LoggingUncaughtExceptionHandler:  92 - 
Uncaught exception in thread Thread[LonerDistributionManagerThread8,5,main]
java.lang.reflect.InaccessibleObjectException: Unable to make field private 
static final jdk.internal.access.JavaLangAccess java.util.UUID.jla accessible: 
module java.base does not "opens java.util" to unnamed module @7960847b
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.Field.checkCanSetAccessible(Field.java:177)
at java.base/java.lang.reflect.Field.setAccessible(Field.java:171)
at 
org.apache.geode.internal.size.ObjectTraverser.buildFieldSet(ObjectTraverser.java:117)
at 
org.apache.geode.internal.size.ObjectTraverser.cacheFieldSet(ObjectTraverser.java:92)
at 
org.apache.geode.internal.size.ObjectTraverser.doSearch(ObjectTraverser.java:65)
at 
org.apache.geode.internal.size.ObjectTraverser.breadthFirstSearch(ObjectTraverser.java:54)
at 
org.apache.geode.internal.size.ObjectGraphSizer.size(ObjectGraphSizer.java:101)
at 
org.apache.geode.internal.size.ReflectionObjectSizer.sizeof(ReflectionObjectSizer.java:76)
at 
org.apache.geode.internal.size.SizeClassOnceObjectSizer.sizeof(SizeClassOnceObjectSizer.java:63)
at 
org.apache.geode.internal.cache.TombstoneService$Tombstone.getSize(TombstoneService.java:398)
at 
org.apache.geode.internal.cache.TombstoneService$TombstoneSweeper.scheduleTombstone(TombstoneService.java:982)
at 
org.apache.geode.internal.cache.TombstoneService.scheduleTombstone(TombstoneService.java:196)
at 
org.apache.geode.internal.cache.LocalRegion.scheduleTombstone(LocalRegion.java:3298)
at 
org.apache.geode.internal.cache.entries.AbstractRegionEntry.makeTombstone(AbstractRegionEntry.java:265)
at 
org.apache.geode.internal.cache.entries.AbstractRegionEntry.destroy(AbstractRegionEntry.java:879)
at 
org.apache.geode.internal.cache.map.RegionMapDestroy.destroyEntry(RegionMapDestroy.java:734)
at 
org.apache.geode.internal.cache.map.RegionMapDestroy.destroyExistingEntry(RegionMapDestroy.java:392)
at 
org.apache.geode.internal.cache.map.RegionMapDestroy.handleExistingRegionEntry(RegionMapDestroy.java:244)
at 
org.apache.geode.internal.cache.map.RegionMapDestroy.destroy(RegionMapDestroy.java:152)
at 
org.apache.geode.internal.cache.AbstractRegionMap.destroy(AbstractRegionMap.java:968)
at org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6499)
at org.apache.geode.internal.cache.LocalRegion.mapDestroy(LocalRegion.java:6473)
at 
org.apache.geode.internal.cache.BucketRegion.basicDestroy(BucketRegion.java:1194)
at 
org.apache.geode.internal.cache.LocalRegion.validatedDestroy(LocalRegion.java:1127)
at 
org.apache.geode.internal.cache.DistributedRegion.validatedDestroy(DistributedRegion.java:940)
at org.apache.geode.internal.cache.LocalRegion.destroy(LocalRegion.java:1112)
at 
org.apache.geode.cache.lucene.internal.partition.BucketTargetingMap.remove(BucketTargetingMap.java:59)
at 
org.apache.geode.cache.lucene.internal.filesystem.FileSystem.deleteFile(FileSystem.java:125)
at 
org.apache.geode.cache.lucene.internal.directory.RegionDirectory.deleteFile(RegionDirectory.java:66)
at 
org.apache.lucene.store.LockValidatingDirectoryWrapper.deleteFile(LockValidatingDirectoryWrapper.java:38)
at 
org.apache.lucene.index.IndexFileDeleter.deleteFile(IndexFileDeleter.java:723)
at 
org.apache.lucene.index.IndexFileDeleter.deleteFiles(IndexFileDeleter.java:717)
at 
org.apache.lucene.index.IndexFileDeleter.deleteNewFiles(IndexFileDeleter.java:693)
at org.apache.lucene.index.IndexWriter.deleteNewFiles(IndexWriter.java:4965)
at 
org.apache.lucene.index.DocumentsWriter$DeleteNewFilesEvent.process(DocumentsWriter.java:771)
at org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:5043)
at org.apache.lucene.index.IndexWriter.processEvents(IndexWriter.java:5034)
at 
org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:3019)
at org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:3244)
at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:3207)
at 
org.apache.geode.cache.lucene.internal.repository.IndexRepositoryImpl.commit(IndexRepositoryImpl.java:169)
at 
org.apache.geode.cache.lucene.internal.IndexRepositoryFactory.reindexUserDataRegion(IndexRepositoryFactory.java:196)
at 
org.apache.geode.cache.lucene.internal.IndexRepositoryFactory.finishComputingRepository(IndexRepositoryFactory.java:128)
at 
org.apache.geode.cache.lucene.internal.IndexRepositoryFactory.computeIndexRepository(IndexRepositoryFactory.java:66)
at 
org.apache.geode.cache.lucene.internal.PartitionedRepositoryManager.computeRepository(PartitionedRepositoryMan

Re: JDK 16 Support?

2021-05-10 Thread John Blum 
Thanks Bill (everyone) for the information.

For clarification, SDG primarily builds on Apache Geode GA versions (e.g. 
1.13.2). This is true for 3rd party libs as well. We rarely, if ever, use 
milestones or release candidates, much less snapshots, for any non-controlled 
dependency, in the mainline. This is necessary to always keep SD[G] in a 
releasable state when/if needed (e.g. critical CVE).

As an exception, we additionally build SDG (master-next) on the most recent 
1.14 snapshots (i.e. mainline version +1, e.g. main is set to 1.13 [1] and 
master-next is set to 1.14 [2], even if an Apache Geode 1.15 branch were cut) 
to prepare SDG for the next version when it becomes GA so we are ready to 
upgrade to that version and get it into a release ASAP.

All of this is to say, any changes to support JDK 16 or above, would need to be 
either in a Geode 1.13.3+ release and/or 1.14 when available for SDG to be 
fully JDK 16+ compatible.

Thx,
-j


[1] 
https://github.com/spring-projects/spring-data-geode/blob/main/spring-data-geode/pom.xml#L23
[2] 
https://github.com/spring-projects/spring-data-geode/blob/master-next/spring-data-geode/pom.xml#L23


From: Bill Burcham 
Sent: Monday, May 10, 2021 10:54 AM
To: dev@geode.apache.org 
Cc: u...@geode.apache.org 
Subject: Re: JDK 16 Support?

John, this doesn't speak to the general question of JDK version support. But 
the particular stack trace you showed makes me wonder if the fix for GEODE-9081 
(landed on 3/30/21 on the develop branch) might get you a little bit further. 
That commit 7ac9d7e4f0d04c99298067ca0611d9326e96d9cf eliminated the reflective 
field access in favor of some simpler down-casting.

On Wed, May 5, 2021 at 9:06 AM John Blum 
mailto:jb...@vmware.com>> wrote:
Hi Anthony-

Thank you for the quick reply.

The Spring Data Team is currently looking ahead towards Java 16 when building 
and running Spring Data examples to get a sense for what works and what 
doesn't, now that Java 16 is GA along with anticipation for users with 
questions or problems.

Spring Framework itself aligns and is based on LTS Java versions only, 
currently Java 8 with Spring Framework 5.  Spring Framework 6 will likely move 
the baseline to Java 11 or possibly even Java 17, we are not sure which yet.

Just want to share our findings and give advanced notice.

Thanks,
John


From: Anthony Baker mailto:bak...@vmware.com>>
Sent: Wednesday, May 5, 2021 8:14 AM
To: u...@geode.apache.org 
mailto:u...@geode.apache.org>>
Cc: geode mailto:dev@geode.apache.org>>
Subject: Re: JDK 16 Support?

Thanks for reporting this John.  The next LTS version of Java (17) is due later 
this year.  I think Geode needs to at least support every LTS version of Java 
and clearly we would need to fix errors like this. Do you see a need to support 
Java 16 now?

Anthony


On May 5, 2021, at 7:57 AM, John Blum 
mailto:jb...@vmware.com>>>
 wrote:

What is the plan to support Java 16 for Apache Geode?  Timeframe?

Running Apache Geode on a Java 16 Runtime produces errors like the following:


- 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

Re: JDK 16 Support?

2021-05-10 Thread Bill Burcham 
John, this doesn't speak to the general question of JDK version support.
But the particular stack trace you showed makes me wonder if the fix for
GEODE-9081 (landed on 3/30/21 on the develop branch) might get you a little
bit further. That commit 7ac9d7e4f0d04c99298067ca0611d9326e96d9cf
eliminated the reflective field access in favor of some simpler
down-casting.

On Wed, May 5, 2021 at 9:06 AM John Blum  wrote:

> Hi Anthony-
>
> Thank you for the quick reply.
>
> The Spring Data Team is currently looking ahead towards Java 16 when
> building and running Spring Data examples to get a sense for what works and
> what doesn't, now that Java 16 is GA along with anticipation for users with
> questions or problems.
>
> Spring Framework itself aligns and is based on LTS Java versions only,
> currently Java 8 with Spring Framework 5.  Spring Framework 6 will likely
> move the baseline to Java 11 or possibly even Java 17, we are not sure
> which yet.
>
> Just want to share our findings and give advanced notice.
>
> Thanks,
> John
>
> 
> From: Anthony Baker 
> Sent: Wednesday, May 5, 2021 8:14 AM
> To: u...@geode.apache.org 
> Cc: geode 
> Subject: Re: JDK 16 Support?
>
> Thanks for reporting this John.  The next LTS version of Java (17) is due
> later this year.  I think Geode needs to at least support every LTS version
> of Java and clearly we would need to fix errors like this. Do you see a
> need to support Java 16 now?
>
> Anthony
>
>
> On May 5, 2021, at 7:57 AM, John Blum  jb...@vmware.com>> wrote:
>
> What is the plan to support Java 16 for Apache Geode?  Timeframe?
>
> Running Apache Geode on a Java 16 Runtime produces errors like the
> following:
>
>
> - 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