[jira] [Updated] (GEODE-10383) lucene may log many warnings about BucketNotFound during normal operations
[
https://issues.apache.org/jira/browse/GEODE-10383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-10383:
-
Summary: lucene may log many warnings about BucketNotFound during normal
operations (was: lucene may log many warnings about BucketNotFound during
normal opeartions)
> lucene may log many warnings about BucketNotFound during normal operations
> --
>
> Key: GEODE-10383
> URL: https://issues.apache.org/jira/browse/GEODE-10383
> Project: Geode
> Issue Type: Bug
> Components: lucene
>Reporter: Darrel Schneider
>Priority: Major
> Labels: needsTriage
>
> This seems much like GEODE-1557 but it may be this exception is coming from a
> different place. Once again it involves a test that has primaries moving
> around due to new servers starting up.
> I don't see any value in logging the stack trace in this case.
> If we are going to log about this should the message also include an
> explanation as to why it can happen during normal operations?
> Also should it really be a warning since it can occur during normal
> operations? It looks like the fix for GEODE-1557 made it "debug" level.
> I see a bunch of the following warnings logged:
> {noformat}
> .cache.lucene.internal.distributed.LuceneQueryFunction@14894ec8
> org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.internal.cache.execute.InternalFunctionInvocationTargetException:
> org.apache.geode.internal.cache.BucketNotFo
> undException: Unable to find lucene index because no longer primary for
> bucket 326
> at
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResultInternal(PRFunctionStreamingResultCollector.java:126)
> at
> org.apache.geode.internal.cache.execute.ResultCollectorHolder.getResult(ResultCollectorHolder.java:53)
> at
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResult(PRFunctionStreamingResultCollector.java:87)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ExecuteRegionFunctionGeode18.executeFunctionWithResult(ExecuteRegionFunctionGeode18.java:50)
> at
> org.apache.geode.internal.cache.tier.sockets.command.ExecuteRegionFunction66.cmdExecute(ExecuteRegionFunction66.java:203)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:187)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:880)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:1074)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1356)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:690)
> at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by:
> org.apache.geode.internal.cache.execute.InternalFunctionInvocationTargetException:
> org.apache.geode.internal.cache.BucketNotFoundException: Unable to find
> lucene ind
> ex because no longer primary for bucket 326
> at
> org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResultInternal(PRFunctionStreamingResultCollector.java:125)
> ... 13 more
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10383) lucene may log many warnings about BucketNotFound during normal opeartions
Darrel Schneider created GEODE-10383:
Summary: lucene may log many warnings about BucketNotFound during
normal opeartions
Key: GEODE-10383
URL: https://issues.apache.org/jira/browse/GEODE-10383
Project: Geode
Issue Type: Bug
Components: lucene
Reporter: Darrel Schneider
This seems much like GEODE-1557 but it may be this exception is coming from a
different place. Once again it involves a test that has primaries moving around
due to new servers starting up.
I don't see any value in logging the stack trace in this case.
If we are going to log about this should the message also include an
explanation as to why it can happen during normal operations?
Also should it really be a warning since it can occur during normal operations?
It looks like the fix for GEODE-1557 made it "debug" level.
I see a bunch of the following warnings logged:
{noformat}
.cache.lucene.internal.distributed.LuceneQueryFunction@14894ec8
org.apache.geode.cache.execute.FunctionException:
org.apache.geode.internal.cache.execute.InternalFunctionInvocationTargetException:
org.apache.geode.internal.cache.BucketNotFo
undException: Unable to find lucene index because no longer primary for bucket
326
at
org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResultInternal(PRFunctionStreamingResultCollector.java:126)
at
org.apache.geode.internal.cache.execute.ResultCollectorHolder.getResult(ResultCollectorHolder.java:53)
at
org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResult(PRFunctionStreamingResultCollector.java:87)
at
org.apache.geode.internal.cache.tier.sockets.command.ExecuteRegionFunctionGeode18.executeFunctionWithResult(ExecuteRegionFunctionGeode18.java:50)
at
org.apache.geode.internal.cache.tier.sockets.command.ExecuteRegionFunction66.cmdExecute(ExecuteRegionFunction66.java:203)
at
org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:187)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMessage(ServerConnection.java:880)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.doOneMessage(ServerConnection.java:1074)
at
org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1356)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at
org.apache.geode.internal.cache.tier.sockets.AcceptorImpl.lambda$initializeServerConnectionThreadPool$3(AcceptorImpl.java:690)
at
org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:120)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by:
org.apache.geode.internal.cache.execute.InternalFunctionInvocationTargetException:
org.apache.geode.internal.cache.BucketNotFoundException: Unable to find lucene
ind
ex because no longer primary for bucket 326
at
org.apache.geode.internal.cache.partitioned.PRFunctionStreamingResultCollector.getResultInternal(PRFunctionStreamingResultCollector.java:125)
... 13 more
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-8977) Thread monitoring service should also show locked monitors and synchronizers
[ https://issues.apache.org/jira/browse/GEODE-8977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-8977: Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI blocks-1.15.0 pull-request-available) > Thread monitoring service should also show locked monitors and synchronizers > > > Key: GEODE-8977 > URL: https://issues.apache.org/jira/browse/GEODE-8977 > Project: Geode > Issue Type: Improvement > Components: core >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The thread monitoring service shows the call stack of a hung thread but it > does not show the synchronizations obtained by the frames in the call stack > like a normal stack dump does. > It looks like this is available from the ThreadInfo class that the service is > already using by calling getLockedMonitors and getLockedSynchronizers. The > getLockedMonitors returns a MonitorInfo which has information in it about > which frame of the stack obtained it. MonitorInfo subclasses LockInfo which > is what getLockedSynchronizers returns so it is possible that > getLockedSynchronizers does not provide any additional information to be > logged. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-8977) Thread monitoring service should also show locked monitors and synchronizers
[ https://issues.apache.org/jira/browse/GEODE-8977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550710#comment-17550710 ] Darrel Schneider commented on GEODE-8977: - We figured out that getThreadInfo is an expensive VM ThreadDump operation that on most JVMs is done in a global safepoint. This means that all other threads are paused (once each of them reaches a safepoint in their execution) and then the ThreadDump is done. This can cause what appears to be a gc stop the world collection. To reduce the amount of time spend doing the ThreadDump operation, by default geode will not ask for lock/sync info but instead just get the stack trace. Also by default it will do the ThreadDump op on each stuck thread individually instead of with a single call that is passed all the thread ids. This reduces the amount of time spent in the op and on Java 15 and later it uses a thread-local safepoint instead of a global safepoint. To get locks set the system property "gemfire.threadmonitor.showLocks" to "true". To get ThreadInfo on all stuck threads with a single call set the system property "gemfire.threadmonitor.batchCalls" to "true". > Thread monitoring service should also show locked monitors and synchronizers > > > Key: GEODE-8977 > URL: https://issues.apache.org/jira/browse/GEODE-8977 > Project: Geode > Issue Type: Improvement > Components: core >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The thread monitoring service shows the call stack of a hung thread but it > does not show the synchronizations obtained by the frames in the call stack > like a normal stack dump does. > It looks like this is available from the ThreadInfo class that the service is > already using by calling getLockedMonitors and getLockedSynchronizers. The > getLockedMonitors returns a MonitorInfo which has information in it about > which frame of the stack obtained it. MonitorInfo subclasses LockInfo which > is what getLockedSynchronizers returns so it is possible that > getLockedSynchronizers does not provide any additional information to be > logged. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-8977) Thread monitoring service should also show locked monitors and synchronizers
[ https://issues.apache.org/jira/browse/GEODE-8977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-8977. - Fix Version/s: 1.16.0 Resolution: Fixed > Thread monitoring service should also show locked monitors and synchronizers > > > Key: GEODE-8977 > URL: https://issues.apache.org/jira/browse/GEODE-8977 > Project: Geode > Issue Type: Improvement > Components: core >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > The thread monitoring service shows the call stack of a hung thread but it > does not show the synchronizations obtained by the frames in the call stack > like a normal stack dump does. > It looks like this is available from the ThreadInfo class that the service is > already using by calling getLockedMonitors and getLockedSynchronizers. The > getLockedMonitors returns a MonitorInfo which has information in it about > which frame of the stack obtained it. MonitorInfo subclasses LockInfo which > is what getLockedSynchronizers returns so it is possible that > getLockedSynchronizers does not provide any additional information to be > logged. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10359) add a performance test for the ThreadMonitor feature
Darrel Schneider created GEODE-10359: Summary: add a performance test for the ThreadMonitor feature Key: GEODE-10359 URL: https://issues.apache.org/jira/browse/GEODE-10359 Project: Geode Issue Type: Test Components: core Reporter: Darrel Schneider GEODE-8977 found that the thread monitor can impact performance of other healthy threads on a server. We should have a JMH benchmark that measures the impact of the thread monitor on healthy threads. The test would have some number of threads that don't need to be doing anything (i.e. they can be stuck waiting for something). It should keep calling ThreadsMonitoringProcess.getThreadInfoMap at a high frequency. Meanwhile is should have a number of healthy threads that are doing repeated operations. The goal would be for the thread monitor to have minimal impact on the throughput of the healthy threads. The test could also see what the impact is if showLocks and/or batchCalls is true (these are getThreadInfoMap parameters). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Reopened] (GEODE-8977) Thread monitoring service should also show locked monitors and synchronizers
[ https://issues.apache.org/jira/browse/GEODE-8977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reopened GEODE-8977: - It turns out that asking the JVM for the lock info is expensive compared to only asking for the stack. And it also turns out that on at least jdk11 getting ThreadInfo requires a global safepoint which stops all other threads from running. Also doing a large number of threads at once instead of one at a time makes the "stop the world" last longer. Since thread monitoring is on by default, and it may think threads are stuck that are actually just doing an operation that takes a long time, it is important for it to "stop the world" for as short a time as possible. Also, in jdk15 and later, asking for a single thread's info (instead of a batch of threads) does not do a "stop the world" but instead just stops the single thread that might be stuck. > Thread monitoring service should also show locked monitors and synchronizers > > > Key: GEODE-8977 > URL: https://issues.apache.org/jira/browse/GEODE-8977 > Project: Geode > Issue Type: Improvement > Components: core >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: GeodeOperationAPI, pull-request-available > Fix For: 1.15.0 > > > The thread monitoring service shows the call stack of a hung thread but it > does not show the synchronizations obtained by the frames in the call stack > like a normal stack dump does. > It looks like this is available from the ThreadInfo class that the service is > already using by calling getLockedMonitors and getLockedSynchronizers. The > getLockedMonitors returns a MonitorInfo which has information in it about > which frame of the stack obtained it. MonitorInfo subclasses LockInfo which > is what getLockedSynchronizers returns so it is possible that > getLockedSynchronizers does not provide any additional information to be > logged. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10338) LogWriterAppender keeps a InternalDistributedSystem alive after disconnect
Darrel Schneider created GEODE-10338:
Summary: LogWriterAppender keeps a InternalDistributedSystem alive
after disconnect
Key: GEODE-10338
URL: https://issues.apache.org/jira/browse/GEODE-10338
Project: Geode
Issue Type: Bug
Components: logging
Reporter: Darrel Schneider
The LogWriterAppender has a "logWriter" field that can be a ManagerLogWriter.
When stopSession is called on the appender, it closes the ManagerLogWriter's
files but does not release its reference to it and the LogWriterAppender
instance is kept around after disconnect. So this ends up keeping the
InternalDistributedSystem alive.
To fix this change LogWriterAppender.stopSession like so:
{code:java}
public synchronized void stopSession() {
LOGGER.info("Stopping session in {}.", this);
if (logWriter == null) {
// we are probably already paused but make sure we are
pause();
return;
}
logWriter.shuttingDown();
pause();
logWriter.closingLogFile();
logWriter = null;
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10337) SocketCreatorFactory does not null out instance static
Darrel Schneider created GEODE-10337:
Summary: SocketCreatorFactory does not null out instance static
Key: GEODE-10337
URL: https://issues.apache.org/jira/browse/GEODE-10337
Project: Geode
Issue Type: Bug
Components: membership
Reporter: Darrel Schneider
The SocketCreatorFactory has a static "instance" field that keeps the singleton
factory. The factory has a reference in "distributionConfig" that ends up
keeping the InternalDistributedSystem alive after disconnect.
It also has a static close method but the product never calls it.
To fix this leak do the following:
On InternalDistributedSystem.disconnect add to the end of it:
{code:java}
if (!attemptingToReconnect) {
SocketCreatorFactory.close();
}
{code}
Also I think it would be good to change SocketCreatorFactory.getInstance to
null out the static when close it called like so:
{code:java}
private static synchronized SocketCreatorFactory getInstance(boolean closing)
{
SocketCreatorFactory result = instance;
if (result == null && !closing) {
result = new SocketCreatorFactory();
instance = result;
} else if (result != null && closing) {
instance = null;
}
return result;
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10336) ConnectionTable.close does not null out its static lastInstance field
Darrel Schneider created GEODE-10336: Summary: ConnectionTable.close does not null out its static lastInstance field Key: GEODE-10336 URL: https://issues.apache.org/jira/browse/GEODE-10336 Project: Geode Issue Type: Bug Components: membership Reporter: Darrel Schneider The ConnectionTable.close method does a bunch of work but it does not null out the static "lastInstance" atomic. This causes it to keep the ConnectionTable alive which ends up keeping the InternalDistributedSystem alive. The easiest fix is to do this at the end of close: "emergencyClose();". The emergencyClose correctly set the lastInstance atomic to null. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10335) TXManagerImpl.close does not remove itself from the static singeton
Darrel Schneider created GEODE-10335: Summary: TXManagerImpl.close does not remove itself from the static singeton Key: GEODE-10335 URL: https://issues.apache.org/jira/browse/GEODE-10335 Project: Geode Issue Type: Bug Components: transactions Reporter: Darrel Schneider TXManagerImpl.close does not remove itself from the static singleton. This causes it to keep the GemFireCacheImpl alive after it has been closed. The simple fix is to add "currentInstance = null" at the end of the close method. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10331) DistributionImpl.destroyMember keeps cache alive for some number of seconds
Darrel Schneider created GEODE-10331: Summary: DistributionImpl.destroyMember keeps cache alive for some number of seconds Key: GEODE-10331 URL: https://issues.apache.org/jira/browse/GEODE-10331 Project: Geode Issue Type: Bug Components: membership Reporter: Darrel Schneider org.apache.geode.distributed.internal.DistributionImpl.destroyMember creates a thread that will hold onto the DIstributesSystem/Cache through the DirectChannel it has for 3 seconds by default. It could be even longer if p2p.disconnectDelay is set to a value > 3000. This can be a problem if the JVM is trying to reconnect since this old cache uses memory. Instead of creating a new thread for every call of destroyMember, we should just have a single ScheduledExecutor that we schedule the background "closeEndpoint" with. Also since all this code interacts with the DirectChannel all the logic about the executor and scheduling it should belong to DirectChannel, not the DistributionImpl. When the DirectChannel has disconnect called on it, then it should get rid of all the tasks scheduled in the executor since they are no longer needed. I think this issue has been around for a long time because the creation of the thread refers to fixing "Bug 37944" which is on old bug system that is not longer used for geode. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10328) Cache close with partitioned regions does not close all the region's statistics
[ https://issues.apache.org/jira/browse/GEODE-10328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-10328: - Fix Version/s: 1.15.0 > Cache close with partitioned regions does not close all the region's > statistics > --- > > Key: GEODE-10328 > URL: https://issues.apache.org/jira/browse/GEODE-10328 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.16.0 > > > I noticed when looking at hprof memory dumps of a JVM whose cache had been > closed that something was keeping the PartitionedRegion instances from being > garbage collected. It turns out that the region's RegionPerfStats instance > was not closed. Other stats for the region were closed but not the one owned > by PartitionedRegionDataStore's bucketStats instance variable. This > indicates that the PartitionedRegionDataStore.cleanUp method is not being > called. > It looks like the bug is in: PartitionedRegion.postDestroyRegion. It has a > code path that handles Operation.CACHE_CLOSE and Operation.FORCED_DISCONNECT > without calling "closePartitionedRegion" which invokes "dataStore.cleanup". > This buggy code path has its reasons for not calling closePartitionedRegion. > To fix this bug it would be easy and safe to have this code path call > dataStore.getCachePerfStats().close() -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10328) Cache close with partitioned regions does not close all the region's statistics
[ https://issues.apache.org/jira/browse/GEODE-10328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-10328. -- Fix Version/s: 1.16.0 Resolution: Fixed > Cache close with partitioned regions does not close all the region's > statistics > --- > > Key: GEODE-10328 > URL: https://issues.apache.org/jira/browse/GEODE-10328 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > I noticed when looking at hprof memory dumps of a JVM whose cache had been > closed that something was keeping the PartitionedRegion instances from being > garbage collected. It turns out that the region's RegionPerfStats instance > was not closed. Other stats for the region were closed but not the one owned > by PartitionedRegionDataStore's bucketStats instance variable. This > indicates that the PartitionedRegionDataStore.cleanUp method is not being > called. > It looks like the bug is in: PartitionedRegion.postDestroyRegion. It has a > code path that handles Operation.CACHE_CLOSE and Operation.FORCED_DISCONNECT > without calling "closePartitionedRegion" which invokes "dataStore.cleanup". > This buggy code path has its reasons for not calling closePartitionedRegion. > To fix this bug it would be easy and safe to have this code path call > dataStore.getCachePerfStats().close() -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10328) Cache close with partitioned regions does not close all the region's statistics
[ https://issues.apache.org/jira/browse/GEODE-10328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-10328: - Labels: (was: needsTriage) > Cache close with partitioned regions does not close all the region's > statistics > --- > > Key: GEODE-10328 > URL: https://issues.apache.org/jira/browse/GEODE-10328 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > > I noticed when looking at hprof memory dumps of a JVM whose cache had been > closed that something was keeping the PartitionedRegion instances from being > garbage collected. It turns out that the region's RegionPerfStats instance > was not closed. Other stats for the region were closed but not the one owned > by PartitionedRegionDataStore's bucketStats instance variable. This > indicates that the PartitionedRegionDataStore.cleanUp method is not being > called. > It looks like the bug is in: PartitionedRegion.postDestroyRegion. It has a > code path that handles Operation.CACHE_CLOSE and Operation.FORCED_DISCONNECT > without calling "closePartitionedRegion" which invokes "dataStore.cleanup". > This buggy code path has its reasons for not calling closePartitionedRegion. > To fix this bug it would be easy and safe to have this code path call > dataStore.getCachePerfStats().close() -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10328) Cache close with partitioned regions does not close all the region's statistics
[ https://issues.apache.org/jira/browse/GEODE-10328?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-10328: Assignee: Darrel Schneider > Cache close with partitioned regions does not close all the region's > statistics > --- > > Key: GEODE-10328 > URL: https://issues.apache.org/jira/browse/GEODE-10328 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: needsTriage > > I noticed when looking at hprof memory dumps of a JVM whose cache had been > closed that something was keeping the PartitionedRegion instances from being > garbage collected. It turns out that the region's RegionPerfStats instance > was not closed. Other stats for the region were closed but not the one owned > by PartitionedRegionDataStore's bucketStats instance variable. This > indicates that the PartitionedRegionDataStore.cleanUp method is not being > called. > It looks like the bug is in: PartitionedRegion.postDestroyRegion. It has a > code path that handles Operation.CACHE_CLOSE and Operation.FORCED_DISCONNECT > without calling "closePartitionedRegion" which invokes "dataStore.cleanup". > This buggy code path has its reasons for not calling closePartitionedRegion. > To fix this bug it would be easy and safe to have this code path call > dataStore.getCachePerfStats().close() -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10328) Cache close with partitioned regions does not close all the region's statistics
Darrel Schneider created GEODE-10328: Summary: Cache close with partitioned regions does not close all the region's statistics Key: GEODE-10328 URL: https://issues.apache.org/jira/browse/GEODE-10328 Project: Geode Issue Type: Bug Components: core Reporter: Darrel Schneider I noticed when looking at hprof memory dumps of a JVM whose cache had been closed that something was keeping the PartitionedRegion instances from being garbage collected. It turns out that the region's RegionPerfStats instance was not closed. Other stats for the region were closed but not the one owned by PartitionedRegionDataStore's bucketStats instance variable. This indicates that the PartitionedRegionDataStore.cleanUp method is not being called. It looks like the bug is in: PartitionedRegion.postDestroyRegion. It has a code path that handles Operation.CACHE_CLOSE and Operation.FORCED_DISCONNECT without calling "closePartitionedRegion" which invokes "dataStore.cleanup". This buggy code path has its reasons for not calling closePartitionedRegion. To fix this bug it would be easy and safe to have this code path call dataStore.getCachePerfStats().close() -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10287) DistributedRegion.distributedRegionCleanup logic looks wrong
[ https://issues.apache.org/jira/browse/GEODE-10287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17539644#comment-17539644 ] Darrel Schneider commented on GEODE-10287: -- DistributionAdvisor.close calls operationMonitor.close which sets the "closed" field on it to true. So when we call forceNewMembershipVersion it is a noop. waitForCurrentOperations is also a noop because operationsAreInProgress will now always return false because operationMonitor.close set previousVersionOpCount to 0. > DistributedRegion.distributedRegionCleanup logic looks wrong > > > Key: GEODE-10287 > URL: https://issues.apache.org/jira/browse/GEODE-10287 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Assignee: Jinmei Liao >Priority: Major > > DistributedRegion.distributedRegionCleanup does this: distAdvisor.close(). > Then a few lines later it calls "waitForCurrentOperations()". But > waitForCurrentOperations uses the closed distAdvisor. Maybe it is okay to > uses a closed distAdvisor but it seems better to call wait first and then > close distAdvisor. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10315) remove unneeded add-opens from MemberJvmOptions
[ https://issues.apache.org/jira/browse/GEODE-10315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-10315: - Fix Version/s: 1.15.0 > remove unneeded add-opens from MemberJvmOptions > --- > > Key: GEODE-10315 > URL: https://issues.apache.org/jira/browse/GEODE-10315 > Project: Geode > Issue Type: Bug > Components: gfsh >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: Java17, pull-request-available > Fix For: 1.15.0, 1.16.0 > > > Currently when gfsh starts a locator or server it will do an add-opens of > java.management/sun.management=ALL-UNNAMED. It turns out geode does not need > this package to be opened so this one should be removed. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10315) remove unneeded add-opens from MemberJvmOptions
[ https://issues.apache.org/jira/browse/GEODE-10315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-10315. -- Fix Version/s: 1.16.0 Resolution: Fixed > remove unneeded add-opens from MemberJvmOptions > --- > > Key: GEODE-10315 > URL: https://issues.apache.org/jira/browse/GEODE-10315 > Project: Geode > Issue Type: Bug > Components: gfsh >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: Java17, pull-request-available > Fix For: 1.16.0 > > > Currently when gfsh starts a locator or server it will do an add-opens of > java.management/sun.management=ALL-UNNAMED. It turns out geode does not need > this package to be opened so this one should be removed. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10315) remove unneeded add-opens from MemberJvmOptions
[ https://issues.apache.org/jira/browse/GEODE-10315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-10315: - Affects Version/s: 1.15.0 > remove unneeded add-opens from MemberJvmOptions > --- > > Key: GEODE-10315 > URL: https://issues.apache.org/jira/browse/GEODE-10315 > Project: Geode > Issue Type: Bug > Components: gfsh >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: Java17 > > Currently when gfsh starts a locator or server it will do an add-opens of > java.management/sun.management=ALL-UNNAMED. It turns out geode does not need > this package to be opened so this one should be removed. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10315) remove unneeded add-opens from MemberJvmOptions
[ https://issues.apache.org/jira/browse/GEODE-10315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-10315: Assignee: Darrel Schneider > remove unneeded add-opens from MemberJvmOptions > --- > > Key: GEODE-10315 > URL: https://issues.apache.org/jira/browse/GEODE-10315 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: Java17 > > Currently when gfsh starts a locator or server it will do an add-opens of > java.management/sun.management=ALL-UNNAMED. It turns out geode does not need > this package to be opened so this one should be removed. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10315) remove unneeded add-opens from MemberJvmOptions
[ https://issues.apache.org/jira/browse/GEODE-10315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-10315: - Labels: Java17 (was: needsTriage) > remove unneeded add-opens from MemberJvmOptions > --- > > Key: GEODE-10315 > URL: https://issues.apache.org/jira/browse/GEODE-10315 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Darrel Schneider >Priority: Major > Labels: Java17 > > Currently when gfsh starts a locator or server it will do an add-opens of > java.management/sun.management=ALL-UNNAMED. It turns out geode does not need > this package to be opened so this one should be removed. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10315) remove unneeded add-opens from MemberJvmOptions
Darrel Schneider created GEODE-10315: Summary: remove unneeded add-opens from MemberJvmOptions Key: GEODE-10315 URL: https://issues.apache.org/jira/browse/GEODE-10315 Project: Geode Issue Type: Bug Components: gfsh Reporter: Darrel Schneider Currently when gfsh starts a locator or server it will do an add-opens of java.management/sun.management=ALL-UNNAMED. It turns out geode does not need this package to be opened so this one should be removed. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10287) DistributedRegion.distributedRegionCleanup logic looks wrong
[ https://issues.apache.org/jira/browse/GEODE-10287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17537840#comment-17537840 ] Darrel Schneider commented on GEODE-10287: -- I'm okay with not fixing this for 1.15. But something is wrong. At most all waitForCurrentOperations will do is call forceNewMembershipVersion and waitForCurrentOperations on the closed advisor. But both of these methods will do nothing if the advisor is closed because the underlying operationMonitor was also closed. So if the current code is correct then we should not even bother calling waitForCurrentOperations in this method since it is ALWAYS a noop. But I don't know if we actually need to call a functional waitForCurrentOperations here. If we do then the hangs you found would need to be addressed. > DistributedRegion.distributedRegionCleanup logic looks wrong > > > Key: GEODE-10287 > URL: https://issues.apache.org/jira/browse/GEODE-10287 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Assignee: Jinmei Liao >Priority: Major > Labels: needsTriage > > DistributedRegion.distributedRegionCleanup does this: distAdvisor.close(). > Then a few lines later it calls "waitForCurrentOperations()". But > waitForCurrentOperations uses the closed distAdvisor. Maybe it is okay to > uses a closed distAdvisor but it seems better to call wait first and then > close distAdvisor. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10287) DistributedRegion.distributedRegionCleanup logic looks wrong
Darrel Schneider created GEODE-10287: Summary: DistributedRegion.distributedRegionCleanup logic looks wrong Key: GEODE-10287 URL: https://issues.apache.org/jira/browse/GEODE-10287 Project: Geode Issue Type: Bug Components: core Reporter: Darrel Schneider DistributedRegion.distributedRegionCleanup does this: distAdvisor.close(). Then a few lines later it calls "waitForCurrentOperations()". But waitForCurrentOperations uses the closed distAdvisor. Maybe it is okay to uses a closed distAdvisor but it seems better to call wait first and then close distAdvisor. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10286) cache close in response to a forced disconnect with persistent regions may skip some cleanup
Darrel Schneider created GEODE-10286:
Summary: cache close in response to a forced disconnect with
persistent regions may skip some cleanup
Key: GEODE-10286
URL: https://issues.apache.org/jira/browse/GEODE-10286
Project: Geode
Issue Type: Bug
Components: core
Reporter: Darrel Schneider
During a cache close, persistent regions may not cleanup as much as they
should. This is because when the PersistentAdvisor is closed, CancelException
is not handled causing other parts of the close to be skipped. I think the
place to handle it is:
DistributedRegion.distributedRegionCleanup(DistributedRegion.java:2564). Here
is an exception showing what it looks like when this happens:
{noformat}
org.apache.geode.distributed.DistributedSystemDisconnectedException:
Distribution manager on rs-RunItNow-ZH1504a1i3xlarge-hydra-client-10(dataStor
egemfire2_host1_421:421):41004 started at Wed Mar 23 17:11:48 PDT
2022: Member isn't responding to heartbeat requests, caused by org.apac
he.geode.ForcedDisconnectException: Member isn't responding to heartbeat
requests
at
org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:289
3)
at
org.apache.geode.distributed.internal.InternalDistributedSystem$Stopper.generateCancelledException(InternalDistributedSystem.java:1177)
at
org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
at
org.apache.geode.distributed.internal.ClusterElderManager.getElderId(ClusterElderManager.java:76)
at
org.apache.geode.distributed.internal.ClusterDistributionManager.getElderId(ClusterDistributionManager.java:2085)
at
org.apache.geode.distributed.internal.locks.DLockService.getElderId(DLockService.java:254)
at
org.apache.geode.distributed.internal.locks.DLockService.notLockGrantorId(DLockService.java:824)
at
org.apache.geode.distributed.internal.locks.DLockService.unlock(DLockService.java:1807)
at
org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.releaseTieLock(PersistenceAdvisorImpl.java:1181)
at
org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.close(PersistenceAdvisorImpl.java:1158)
at
org.apache.geode.internal.cache.DistributedRegion.distributedRegionCleanup(DistributedRegion.java:2564)
at
org.apache.geode.internal.cache.DistributedRegion.postDestroyRegion(DistributedRegion.java:2657)
at
org.apache.geode.internal.cache.LocalRegion.recursiveDestroyRegion(LocalRegion.java:2732)
at
org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6241)
at
org.apache.geode.internal.cache.DistributedRegion.basicDestroyRegion(DistributedRegion.java:1834)
at
org.apache.geode.internal.cache.LocalRegion.handleCacheClose(LocalRegion.java:7320)
at
org.apache.geode.internal.cache.DistributedRegion.handleCacheClose(DistributedRegion.java:2691)
at
org.apache.geode.internal.cache.GemFireCacheImpl.doClose(GemFireCacheImpl.java:2308)
at
org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2154)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1538)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2545)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2408)
at
org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1254)
at
org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:2329)
at
org.apache.geode.distributed.internal.membership.gms.GMSMembership.uncleanShutdown(GMSMembership.java:1190)
at
org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$uncleanShutdownDS$0(GMSMembership.java:1793)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: org.apache.geode.ForcedDisconnectException: Member isn't responding
to heartbeat requests
at
org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:2319)
... 3 more
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10285) the auto reconnect after a forced disconnect uses more memory than needed
Darrel Schneider created GEODE-10285: Summary: the auto reconnect after a forced disconnect uses more memory than needed Key: GEODE-10285 URL: https://issues.apache.org/jira/browse/GEODE-10285 Project: Geode Issue Type: Improvement Components: core Reporter: Darrel Schneider When a member is forced out of the distributed system, if disable-auto-reconnect=false (the default), then it will attempt to close its cache, disconnect from the cluster, and then reconnect and create a new cache. Because of the way this is implemented, the old cache is kept in memory while the new cache is being created. This can end up causing reconnect to use much more memory then it needs. That memory will be freed after the reconnect completes, but it is possible for this to cause the JVM to run out of memory during the reconnect. So far I have found two places that keep the old cache around: 1. InternalDistributedSystem.tryReconnect is passed the old cache as a parameter. Only one caller exists and only a small block of code in tryReconnect needs the old cache. So it would be easy to fix this by not passing it in as a parameter. 2. InternalDistributedSystem.reconnect (called by tryReconnect) keeps the old cache in a local variable "cache". It only needs it to initialize "cacheXML" and "cacheServerCreation". So once those are initialized it would be easy to drop this ref. But cacheServerCreation also contains references to the old cache through the "cache" instance variable on CacheServerCreation. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10196) Multiple geode-for-redis DUnitTests fail to ignore expected exceptions on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-10196.
--
Resolution: Not A Problem
the redis tests were removed from geode.
> Multiple geode-for-redis DUnitTests fail to ignore expected exceptions on JDK
> 17
>
>
> Key: GEODE-10196
> URL: https://issues.apache.org/jira/browse/GEODE-10196
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java17, pull-request-available
> Fix For: 1.15.0
>
>
> The {{HashesAndCrashesDUnitTest.executeUntilSuccess()}} method (called by all
> of the test in the class) expects exceptions with the message "Connection
> reset by peer", logs them, and retries the operation.
>
> The source of the exception is {{{}SocketChannel.read(){}}}. On JDK 17, the
> exception message is "Connection reset". This is not the expected message,
> and so {{executeUntilSuccess()}} rethrows it instead of ignoring it, causing
> the test to fail.
>
> Incidentally, the type of the exception on JDK 17 {{{}SocketException{}}},
> but on JDK 8 and 11 is {{{}IOException{}}}. This does not affect the test,
> which inspects only the exception message, not the type.
>
> On JDK 17, the stack trace of the exception is:
> {noformat}
> io.lettuce.core.RedisException: java.net.SocketException: Connection reset
> at io.lettuce.core.internal.Exceptions.bubble(Exceptions.java:83)
> at io.lettuce.core.internal.Futures.awaitOrCancel(Futures.java:250)
> at
> io.lettuce.core.cluster.ClusterFutureSyncInvocationHandler.handleInvocation(ClusterFutureSyncInvocationHandler.java:130)
> at
> io.lettuce.core.internal.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:80)
> at jdk.proxy3/jdk.proxy3.$Proxy53.set(Unknown Source)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$setPerformAndVerify$14(HashesAndCrashesDUnitTest.java:257)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.executeUntilSuccess(HashesAndCrashesDUnitTest.java:274)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.setPerformAndVerify(HashesAndCrashesDUnitTest.java:257)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$modifyDataWhileCrashingVMs$11(HashesAndCrashesDUnitTest.java:161)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.net.SocketException: Connection reset
> at
> java.base/sun.nio.ch.SocketChannelImpl.throwConnectionReset(SocketChannelImpl.java:394)
> at java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:426)
> at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:258)
> at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1132)
> at
> io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:151)
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:722)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:658)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:584)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
> at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> ... 1 more
> {noformat}
>
> On JDK 11, the stack trace of the exception is:
> {noformat}
> io.lettuce.core.RedisException: java.io.IOException: Connection reset by peer
> at io.lettuce.core.internal.Exceptions.bubble(Exceptions.java:83)
> at io.lettuce.core.internal.Futures.awaitOrCancel(Futures.java:250)
> at
> io.lettuce.core.cluster.ClusterFutureSyncInvocationHandler.handleInvocation(ClusterFutureSyncInvocationHandler.java:130)
> at
> io.lettuce.core.internal.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:80)
> at com.sun.proxy.$Proxy52.set(Unknown Source)
> at
>
[jira] [Resolved] (GEODE-10206) Geode assumes CMS garbage collector, which JDK 17 lacks
[ https://issues.apache.org/jira/browse/GEODE-10206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-10206. -- Fix Version/s: 1.15.0 Resolution: Fixed The erb doc files still need attention but that will be done on another ticket. > Geode assumes CMS garbage collector, which JDK 17 lacks > --- > > Key: GEODE-10206 > URL: https://issues.apache.org/jira/browse/GEODE-10206 > Project: Geode > Issue Type: Improvement > Components: core, docs, gfsh >Affects Versions: 1.15.0 >Reporter: Dale Emery >Assignee: Darrel Schneider >Priority: Major > Labels: Java17, pull-request-available > Fix For: 1.15.0 > > > Several places in Geode code and documentation assume that Concurrent Mark > Sweet (CMS) garbage collector exists, and that these VM arguments are > meaningful: > - -XX:+UseConcMarkSweepGC > - -XX:CMSInitiatingOccupancyFraction > The CMS garbage collector is not available on JDK 17. JDK 17 warns that it > does not recognize these arguments. > These production classes rely on CMS args at runtime: > - extensions/geode-modules: ResourceManagerValidator.validateSunArguments() > recommends configuring the CMS args. > - geode-gfsh: StartMemberUtils passes the CMS args when max heap is set. > These test classes use the CMS args at runtime: > - geode-for-redis: OutOfMemoryDUnitTest passes a > CMSInitiatingOccupancyFraction arg when starting a server. > User-facing Javadoc comments on these classes refer to the CMS args: > - geode-core: EvictionAttributes > - geode-core: ResourceManager > Code comments in these classes refer to the CMS args: > - geode-modules: AbstractCache > These properties files in geode-modules-assembly define or refer to the CMS > args: > - scripts/setenv.properties > - tcserver/geode-cs/configuration-prompts.properties > - tcserver/geode-p2p/configuration-prompts.properties > These documentation files in geode-docs refer to the CMS args: > - configuring/running/running_the_cacheserver.html.md.erb > - managing/heap_use/heap_management.html.md.erb > - managing/monitor_tune/system_member_performance_garbage.html.md.erb -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-10196) Multiple geode-for-redis DUnitTests fail to ignore expected exceptions on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17531881#comment-17531881
]
Darrel Schneider commented on GEODE-10196:
--
MessageDispatcher.java is not an issue because it handles both "Connection
reset" and "Connection reset by peer".
> Multiple geode-for-redis DUnitTests fail to ignore expected exceptions on JDK
> 17
>
>
> Key: GEODE-10196
> URL: https://issues.apache.org/jira/browse/GEODE-10196
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java17, pull-request-available
> Fix For: 1.15.0
>
>
> The {{HashesAndCrashesDUnitTest.executeUntilSuccess()}} method (called by all
> of the test in the class) expects exceptions with the message "Connection
> reset by peer", logs them, and retries the operation.
>
> The source of the exception is {{{}SocketChannel.read(){}}}. On JDK 17, the
> exception message is "Connection reset". This is not the expected message,
> and so {{executeUntilSuccess()}} rethrows it instead of ignoring it, causing
> the test to fail.
>
> Incidentally, the type of the exception on JDK 17 {{{}SocketException{}}},
> but on JDK 8 and 11 is {{{}IOException{}}}. This does not affect the test,
> which inspects only the exception message, not the type.
>
> On JDK 17, the stack trace of the exception is:
> {noformat}
> io.lettuce.core.RedisException: java.net.SocketException: Connection reset
> at io.lettuce.core.internal.Exceptions.bubble(Exceptions.java:83)
> at io.lettuce.core.internal.Futures.awaitOrCancel(Futures.java:250)
> at
> io.lettuce.core.cluster.ClusterFutureSyncInvocationHandler.handleInvocation(ClusterFutureSyncInvocationHandler.java:130)
> at
> io.lettuce.core.internal.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:80)
> at jdk.proxy3/jdk.proxy3.$Proxy53.set(Unknown Source)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$setPerformAndVerify$14(HashesAndCrashesDUnitTest.java:257)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.executeUntilSuccess(HashesAndCrashesDUnitTest.java:274)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.setPerformAndVerify(HashesAndCrashesDUnitTest.java:257)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$modifyDataWhileCrashingVMs$11(HashesAndCrashesDUnitTest.java:161)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.net.SocketException: Connection reset
> at
> java.base/sun.nio.ch.SocketChannelImpl.throwConnectionReset(SocketChannelImpl.java:394)
> at java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:426)
> at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:258)
> at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1132)
> at
> io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:151)
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:722)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:658)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:584)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
> at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> ... 1 more
> {noformat}
>
> On JDK 11, the stack trace of the exception is:
> {noformat}
> io.lettuce.core.RedisException: java.io.IOException: Connection reset by peer
> at io.lettuce.core.internal.Exceptions.bubble(Exceptions.java:83)
> at io.lettuce.core.internal.Futures.awaitOrCancel(Futures.java:250)
> at
> io.lettuce.core.cluster.ClusterFutureSyncInvocationHandler.handleInvocation(ClusterFutureSyncInvocationHandler.java:130)
> at
> io.lettuce.core.internal.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:80)
> at com.sun.proxy.$Proxy52.set(Unknown Source)
> at
>
[jira] [Assigned] (GEODE-10206) Geode assumes CMS garbage collector, which JDK 17 lacks
[ https://issues.apache.org/jira/browse/GEODE-10206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-10206: Assignee: Darrel Schneider > Geode assumes CMS garbage collector, which JDK 17 lacks > --- > > Key: GEODE-10206 > URL: https://issues.apache.org/jira/browse/GEODE-10206 > Project: Geode > Issue Type: Improvement > Components: core, docs, gfsh >Affects Versions: 1.15.0 >Reporter: Dale Emery >Assignee: Darrel Schneider >Priority: Major > Labels: Java17 > > Several places in Geode code and documentation assume that Concurrent Mark > Sweet (CMS) garbage collector exists, and that these VM arguments are > meaningful: > - -XX:+UseConcMarkSweepGC > - -XX:CMSInitiatingOccupancyFraction > The CMS garbage collector is not available on JDK 17. JDK 17 warns that it > does not recognize these arguments. > These production classes rely on CMS args at runtime: > - extensions/geode-modules: ResourceManagerValidator.validateSunArguments() > recommends configuring the CMS args. > - geode-gfsh: StartMemberUtils passes the CMS args when max heap is set. > These test classes use the CMS args at runtime: > - geode-for-redis: OutOfMemoryDUnitTest passes a > CMSInitiatingOccupancyFraction arg when starting a server. > User-facing Javadoc comments on these classes refer to the CMS args: > - geode-core: EvictionAttributes > - geode-core: ResourceManager > Code comments in these classes refer to the CMS args: > - geode-modules: AbstractCache > These properties files in geode-modules-assembly define or refer to the CMS > args: > - scripts/setenv.properties > - tcserver/geode-cs/configuration-prompts.properties > - tcserver/geode-p2p/configuration-prompts.properties > These documentation files in geode-docs refer to the CMS args: > - configuring/running/running_the_cacheserver.html.md.erb > - managing/heap_use/heap_management.html.md.erb > - managing/monitor_tune/system_member_performance_garbage.html.md.erb -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10263) open and export jdk packages on jdk17 automatically for server and locator that geode features need
[ https://issues.apache.org/jira/browse/GEODE-10263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-10263. -- Resolution: Fixed > open and export jdk packages on jdk17 automatically for server and locator > that geode features need > --- > > Key: GEODE-10263 > URL: https://issues.apache.org/jira/browse/GEODE-10263 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: Java17, pull-request-available > Fix For: 1.15.0 > > > Geode has a number of features that require a specific jdk package to be > opened or exported. These should all be done automatically when geode > launches a JVM for a server or a locator. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Reopened] (GEODE-10263) open and export jdk packages on jdk17 automatically for server and locator that geode features need
[ https://issues.apache.org/jira/browse/GEODE-10263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reopened GEODE-10263: -- found one more open needed by product > open and export jdk packages on jdk17 automatically for server and locator > that geode features need > --- > > Key: GEODE-10263 > URL: https://issues.apache.org/jira/browse/GEODE-10263 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: Java17, pull-request-available > Fix For: 1.15.0 > > > Geode has a number of features that require a specific jdk package to be > opened or exported. These should all be done automatically when geode > launches a JVM for a server or a locator. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-8008) CI failure: GemFireStatSamplerIntegrationTest > testArchiveRemoval failed with ComparisonFailure
[
https://issues.apache.org/jira/browse/GEODE-8008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17530210#comment-17530210
]
Darrel Schneider commented on GEODE-8008:
-
saw this again on a 1.15 PR:
https://concourse.apachegeode-ci.info/builds/49170299
> CI failure: GemFireStatSamplerIntegrationTest > testArchiveRemoval failed
> with ComparisonFailure
>
>
> Key: GEODE-8008
> URL: https://issues.apache.org/jira/browse/GEODE-8008
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Reporter: Barrett Oglesby
>Priority: Major
>
> GemFireStatSamplerIntegrationTest > testArchiveRemoval in
> IntegrationTestOpenJDK8 build 74:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK8/builds/74
> Failed with:
> {noformat}
> org.apache.geode.internal.statistics.GemFireStatSamplerIntegrationTest >
> testArchiveRemoval FAILED
> org.awaitility.core.ConditionTimeoutException: Condition with alias
> 'current archive file and four rollover archive files' didn't complete within
> 5 minutes because assertion condition defined as a lambda expression in
> org.apache.geode.internal.statistics.GemFireStatSamplerIntegrationTest that
> uses java.util.concurrent.atomic.AtomicBoolean,
> java.util.concurrent.atomic.AtomicBooleanjava.io.File,
> java.io.Filejava.util.concurrent.atomic.AtomicBoolean,
> java.util.concurrent.atomic.AtomicBooleanjava.io.File,
> java.io.Filejava.util.concurrent.atomic.AtomicBoolean,
> java.util.concurrent.atomic.AtomicBooleanjava.io.File,
> java.io.Filejava.util.concurrent.atomic.AtomicBoolean,
> java.util.concurrent.atomic.AtomicBooleanjava.io.File,
> java.io.Filejava.util.concurrent.atomic.AtomicBoolean,
> java.util.concurrent.atomic.AtomicBooleanjava.io.File [Waiting for archive
> files to exist: currentArchiveFile=true rolloverArchiveFile1=true
> rolloverArchiveFile2=false rolloverArchiveFile3=true
> rolloverArchiveFile4=true] expected:<[tru]e> but was:<[fals]e>.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:165)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:895)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:679)
> at
> org.apache.geode.internal.statistics.GemFireStatSamplerIntegrationTest.testArchiveRemoval(GemFireStatSamplerIntegrationTest.java:478)
> Caused by:
> org.junit.ComparisonFailure: [Waiting for archive files to exist:
> currentArchiveFile=true rolloverArchiveFile1=true rolloverArchiveFile2=false
> rolloverArchiveFile3=true rolloverArchiveFile4=true] expected:<[tru]e> but
> was:<[fals]e>
> at sun.reflect.GeneratedConstructorAccessor24.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.statistics.GemFireStatSamplerIntegrationTest.lambda$testArchiveRemoval$3(GemFireStatSamplerIntegrationTest.java:495)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Reopened] (GEODE-10249) Add stats for BufferPoolMXBean
[ https://issues.apache.org/jira/browse/GEODE-10249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reopened GEODE-10249: -- Assignee: Darrel Schneider (was: Jacob Barrett) the BufferPoolStats is currently static and its implementation causes it to end up holding onto an old StatisticsRegistry if a JVM closes its cache and creates a new one. This can be fixed by changing BufferPoolStats to not be static. > Add stats for BufferPoolMXBean > -- > > Key: GEODE-10249 > URL: https://issues.apache.org/jira/browse/GEODE-10249 > Project: Geode > Issue Type: Improvement >Reporter: Jacob Barrett >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Java provides information on buffer pools used in the JVM via > BufferPoolMXBean. Add the output of these to the basic set of platform stats > to diagnose buffer pool issues. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (GEODE-9474) the Geode offheap feature will fail on java 16
[ https://issues.apache.org/jira/browse/GEODE-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522983#comment-17522983 ] Darrel Schneider edited comment on GEODE-9474 at 4/28/22 7:41 PM: -- For Java17 we need the server to have "java.nio" opened for offheap to work. I think we should just add this to the list of opens needed by geode features. This open has been added in: GEODE-10263 was (Author: dschneider): For Java17 we need the server to have "java.nio" opened for offheap to work. I think we should just add this to the list of opens needed by geode features. > the Geode offheap feature will fail on java 16 > -- > > Key: GEODE-9474 > URL: https://issues.apache.org/jira/browse/GEODE-9474 > Project: Geode > Issue Type: Bug > Components: offheap >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > > In two different places geode offheap calls setAccessible. In one place it is > to call the "address" method. In the other it is to call the DIrectByteBuffer > constructor that passes an address in to the constructor. These will not work > on java 16 and later because it calls Method.setAccessible which is not > allowed under normal conditions starting with java 16 (see: > https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16 ). > To workaround this failure set the JVM command line option: > --illegal-access=permit or use --add-opens. > The places that make the calls: > * > org.apache.geode.internal.offheap.AddressableMemoryManager#getDirectByteBufferAddress > * > org.apache.geode.internal.offheap.AddressableMemoryManager#createDirectByteBuffer > The "address" call does not need to use reflection and setAccessible but can > instead do it with casting. See > org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer for how this is done. > The constructor issue is a bigger problem. This constructor can be called > from JNI NewDirectByteBuffer but needing to add native code to geode does not > seem worth the trouble. If some other solution can not be found then the > above workaround would need to be used if offheap is. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9474) the Geode offheap feature will fail on java 16
[ https://issues.apache.org/jira/browse/GEODE-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-9474. - Fix Version/s: 1.15.0 Resolution: Fixed > the Geode offheap feature will fail on java 16 > -- > > Key: GEODE-9474 > URL: https://issues.apache.org/jira/browse/GEODE-9474 > Project: Geode > Issue Type: Bug > Components: offheap >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > Fix For: 1.15.0 > > > In two different places geode offheap calls setAccessible. In one place it is > to call the "address" method. In the other it is to call the DIrectByteBuffer > constructor that passes an address in to the constructor. These will not work > on java 16 and later because it calls Method.setAccessible which is not > allowed under normal conditions starting with java 16 (see: > https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16 ). > To workaround this failure set the JVM command line option: > --illegal-access=permit or use --add-opens. > The places that make the calls: > * > org.apache.geode.internal.offheap.AddressableMemoryManager#getDirectByteBufferAddress > * > org.apache.geode.internal.offheap.AddressableMemoryManager#createDirectByteBuffer > The "address" call does not need to use reflection and setAccessible but can > instead do it with casting. See > org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer for how this is done. > The constructor issue is a bigger problem. This constructor can be called > from JNI NewDirectByteBuffer but needing to add native code to geode does not > seem worth the trouble. If some other solution can not be found then the > above workaround would need to be used if offheap is. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9476) VMStats processCpuTime, fdLimit, and fdsOpen will always be zero on java 16 and later
[
https://issues.apache.org/jira/browse/GEODE-9476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-9476.
-
Fix Version/s: 1.15.0
Resolution: Fixed
> VMStats processCpuTime, fdLimit, and fdsOpen will always be zero on java 16
> and later
> -
>
> Key: GEODE-9476
> URL: https://issues.apache.org/jira/browse/GEODE-9476
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Reporter: Darrel Schneider
>Priority: Major
> Labels: Java16, Java17
> Fix For: 1.15.0
>
>
> VMStats processCpuTime, fdLimit, and fdsOpen will always be zero on java 16
> and later.
> This is because it calls Method.setAccessible which is not allowed under
> normal conditions starting with java 16 (see:
> https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16).
> A workaround for this bug is to start the jvm with --illegal-access=permit
> The setAccessible call is in the static initializer for:
> org.apache.geode.internal.stats50.VMStats50
> It turns out the following works for calling processCpuTime:
> {code:java}
> OperatingSystemMXBean osBean =
> ManagementFactory.getOperatingSystemMXBean();
> com.sun.management.OperatingSystemMXBean sunBean =
> (com.sun.management.OperatingSystemMXBean) osBean;
> System.out.println("getProcessCpuTime=" +
> sunBean.getProcessCpuTime());
> {code}
> so we can get rid of the setAccessible call
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (GEODE-9476) VMStats processCpuTime, fdLimit, and fdsOpen will always be zero on java 16 and later
[
https://issues.apache.org/jira/browse/GEODE-9476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522987#comment-17522987
]
Darrel Schneider edited comment on GEODE-9476 at 4/28/22 7:40 PM:
--
this is an issue for geode 1.15 because the setAccessible call is made to a jdk
class. For these stats to work on jdk17 our server and locator process need
"sun.management" opened to the unnamed module.
This was done for 1.15 see: GEODE-10263
was (Author: dschneider):
this is an issue for geode 1.15 because the setAccessible call is made to a jdk
class. For these stats to work on jdk17 our server and locator process need
"sun.management" opened to the unnamed module.
> VMStats processCpuTime, fdLimit, and fdsOpen will always be zero on java 16
> and later
> -
>
> Key: GEODE-9476
> URL: https://issues.apache.org/jira/browse/GEODE-9476
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Reporter: Darrel Schneider
>Priority: Major
> Labels: Java16, Java17
>
> VMStats processCpuTime, fdLimit, and fdsOpen will always be zero on java 16
> and later.
> This is because it calls Method.setAccessible which is not allowed under
> normal conditions starting with java 16 (see:
> https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16).
> A workaround for this bug is to start the jvm with --illegal-access=permit
> The setAccessible call is in the static initializer for:
> org.apache.geode.internal.stats50.VMStats50
> It turns out the following works for calling processCpuTime:
> {code:java}
> OperatingSystemMXBean osBean =
> ManagementFactory.getOperatingSystemMXBean();
> com.sun.management.OperatingSystemMXBean sunBean =
> (com.sun.management.OperatingSystemMXBean) osBean;
> System.out.println("getProcessCpuTime=" +
> sunBean.getProcessCpuTime());
> {code}
> so we can get rid of the setAccessible call
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-9471) gfsh show dead-locks will fail on java 16 and later
[ https://issues.apache.org/jira/browse/GEODE-9471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-9471. - Fix Version/s: 1.15.0 Resolution: Fixed > gfsh show dead-locks will fail on java 16 and later > --- > > Key: GEODE-9471 > URL: https://issues.apache.org/jira/browse/GEODE-9471 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > Fix For: 1.15.0 > > > The gfsh show dead-locks command ends up depending on this class: > org.apache.geode.distributed.internal.deadlock.UnsafeThreadLocal > Most of the time this UnsafeThreadLocal just behaves like a normal jdk > ThreadLocal (its super class). But when the gfsh command is executed it > causes "get" to be called on UnsafeThreadLocal. It uses a bunch of reflection > to prevent "get" from setting an initial value in the case of a miss. This > reflection calls setAccessible which will cause get to fail on java 16 and > later (see: > [https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16]). > To workaround this failure set the JVM command line option: > --illegal-access=permit > The current solution adds get(Thread) to UnsafeThreadLocal which is different > than ThreadLocal.get(). To fix this we probably need to stop using > ThreadLocal and instead keep some kind of collection of the threads waiting > for a resource. It might also be possible to ask the resource what threads > are waiting for it. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (GEODE-9471) gfsh show dead-locks will fail on java 16 and later
[ https://issues.apache.org/jira/browse/GEODE-9471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524628#comment-17524628 ] Darrel Schneider edited comment on GEODE-9471 at 4/28/22 7:37 PM: -- For 1.15 the current implementation requires an add-opens of "java.lang" for the ThreadLocal class's privates. This open has been added see: GEODE-10263 was (Author: dschneider): For 1.15 the current implementation requires an add-opens of "java.lang" for the ThreadLocal class's privates. > gfsh show dead-locks will fail on java 16 and later > --- > > Key: GEODE-9471 > URL: https://issues.apache.org/jira/browse/GEODE-9471 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > > The gfsh show dead-locks command ends up depending on this class: > org.apache.geode.distributed.internal.deadlock.UnsafeThreadLocal > Most of the time this UnsafeThreadLocal just behaves like a normal jdk > ThreadLocal (its super class). But when the gfsh command is executed it > causes "get" to be called on UnsafeThreadLocal. It uses a bunch of reflection > to prevent "get" from setting an initial value in the case of a miss. This > reflection calls setAccessible which will cause get to fail on java 16 and > later (see: > [https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16]). > To workaround this failure set the JVM command line option: > --illegal-access=permit > The current solution adds get(Thread) to UnsafeThreadLocal which is different > than ThreadLocal.get(). To fix this we probably need to stop using > ThreadLocal and instead keep some kind of collection of the threads waiting > for a resource. It might also be possible to ask the resource what threads > are waiting for it. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10263) open and export jdk packages on jdk17 automatically for server and locator that geode features need
[ https://issues.apache.org/jira/browse/GEODE-10263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-10263. -- Fix Version/s: 1.15.0 Resolution: Fixed > open and export jdk packages on jdk17 automatically for server and locator > that geode features need > --- > > Key: GEODE-10263 > URL: https://issues.apache.org/jira/browse/GEODE-10263 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: Java17, pull-request-available > Fix For: 1.15.0 > > > Geode has a number of features that require a specific jdk package to be > opened or exported. These should all be done automatically when geode > launches a JVM for a server or a locator. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10263) open and export jdk packages on jdk17 automatically for server and locator that geode features need
[ https://issues.apache.org/jira/browse/GEODE-10263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-10263: - Summary: open and export jdk packages on jdk17 automatically for server and locator that geode features need (was: open and export jdk packages geode features need automatically for server and locator) > open and export jdk packages on jdk17 automatically for server and locator > that geode features need > --- > > Key: GEODE-10263 > URL: https://issues.apache.org/jira/browse/GEODE-10263 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: Java17 > > Geode has a number of features that require a specific jdk package to be > opened or exported. These should all be done automatically when geode > launches a JVM for a server or a locator. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10263) open and export jdk packages geode features need automatically for server and locator
[ https://issues.apache.org/jira/browse/GEODE-10263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-10263: - Labels: Java17 (was: ) > open and export jdk packages geode features need automatically for server and > locator > - > > Key: GEODE-10263 > URL: https://issues.apache.org/jira/browse/GEODE-10263 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Darrel Schneider >Priority: Major > Labels: Java17 > > Geode has a number of features that require a specific jdk package to be > opened or exported. These should all be done automatically when geode > launches a JVM for a server or a locator. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10263) open and export jdk packages geode features need automatically for server and locator
[ https://issues.apache.org/jira/browse/GEODE-10263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-10263: Assignee: Darrel Schneider > open and export jdk packages geode features need automatically for server and > locator > - > > Key: GEODE-10263 > URL: https://issues.apache.org/jira/browse/GEODE-10263 > Project: Geode > Issue Type: Improvement > Components: gfsh >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: Java17 > > Geode has a number of features that require a specific jdk package to be > opened or exported. These should all be done automatically when geode > launches a JVM for a server or a locator. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10263) open and export jdk packages geode features need automatically for server and locator
Darrel Schneider created GEODE-10263: Summary: open and export jdk packages geode features need automatically for server and locator Key: GEODE-10263 URL: https://issues.apache.org/jira/browse/GEODE-10263 Project: Geode Issue Type: Improvement Components: gfsh Reporter: Darrel Schneider Geode has a number of features that require a specific jdk package to be opened or exported. These should all be done automatically when geode launches a JVM for a server or a locator. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10262) Document what packages geode requires to be opened and exported
[ https://issues.apache.org/jira/browse/GEODE-10262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-10262: - Labels: Java17 (was: ) > Document what packages geode requires to be opened and exported > --- > > Key: GEODE-10262 > URL: https://issues.apache.org/jira/browse/GEODE-10262 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.15.0 >Reporter: Darrel Schneider >Priority: Major > Labels: Java17 > > A number of geode features require certain jdk packages to be opened or > exported. Geode takes care of this when it creates a server JVM in > MemberJvmOptions. But these should all be documented in some way for users > that start up their own JVM. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10262) Document what packages geode requires to be opened and exported
Darrel Schneider created GEODE-10262: Summary: Document what packages geode requires to be opened and exported Key: GEODE-10262 URL: https://issues.apache.org/jira/browse/GEODE-10262 Project: Geode Issue Type: Improvement Components: docs Affects Versions: 1.15.0 Reporter: Darrel Schneider A number of geode features require certain jdk packages to be opened or exported. Geode takes care of this when it creates a server JVM in MemberJvmOptions. But these should all be documented in some way for users that start up their own JVM. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-10036) Joining Locators in a cluster is not possible on Java 17
[
https://issues.apache.org/jira/browse/GEODE-10036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-10036.
--
Fix Version/s: 1.15.0
Resolution: Fixed
since geode MemberJvmOptions exports sun.nio.ch nothing else is needed
> Joining Locators in a cluster is not possible on Java 17
>
>
> Key: GEODE-10036
> URL: https://issues.apache.org/jira/browse/GEODE-10036
> Project: Geode
> Issue Type: Sub-task
>Affects Versions: 1.14.3
>Reporter: John Blum
>Assignee: Darrel Schneider
>Priority: Critical
> Labels: Java17, jdk17, pull-request-available
> Fix For: 1.15.0
>
>
> When trying to add multiple _Locators_ to the same cluster, particularly when
> "_direct_" {{ByteBuffers}} are used, the following Exception is thrown:
> {code:java}
> Caused by: org.apache.geode.SystemConnectException: One or more peers
> generated exceptions during connection attempt
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1634)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at
> org.springframework.data.gemfire.LocatorFactoryBean.init(LocatorFactoryBean.java:120)
> ... 44 more
> Caused by: 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:101)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:258)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:318)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:525)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2064)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1991)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:75)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1631)
> ... 56 more
> 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 @2e0fa5d3
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> 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)
> ... 69 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10036) Joining Locators in a cluster is not possible on Java 17
[
https://issues.apache.org/jira/browse/GEODE-10036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17528915#comment-17528915
]
Darrel Schneider commented on GEODE-10036:
--
For 1.15 we decided to just require the following:
"--add-exports=java.base/sun.nio.ch=ALL-UNNAMED". Geode will do this be default
for a server JVM but users will need to add this to client JVMs.
> Joining Locators in a cluster is not possible on Java 17
>
>
> Key: GEODE-10036
> URL: https://issues.apache.org/jira/browse/GEODE-10036
> Project: Geode
> Issue Type: Sub-task
>Affects Versions: 1.14.3
>Reporter: John Blum
>Assignee: Darrel Schneider
>Priority: Critical
> Labels: Java17, jdk17, pull-request-available
>
> When trying to add multiple _Locators_ to the same cluster, particularly when
> "_direct_" {{ByteBuffers}} are used, the following Exception is thrown:
> {code:java}
> Caused by: org.apache.geode.SystemConnectException: One or more peers
> generated exceptions during connection attempt
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1634)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at
> org.springframework.data.gemfire.LocatorFactoryBean.init(LocatorFactoryBean.java:120)
> ... 44 more
> Caused by: 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:101)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:258)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:318)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:525)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2064)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1991)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:75)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1631)
> ... 56 more
> 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 @2e0fa5d3
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> 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)
> ... 69 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10036) Joining Locators in a cluster is not possible on Java 17
[
https://issues.apache.org/jira/browse/GEODE-10036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider reassigned GEODE-10036:
Assignee: Darrel Schneider
> Joining Locators in a cluster is not possible on Java 17
>
>
> Key: GEODE-10036
> URL: https://issues.apache.org/jira/browse/GEODE-10036
> Project: Geode
> Issue Type: Sub-task
>Affects Versions: 1.14.3
>Reporter: John Blum
>Assignee: Darrel Schneider
>Priority: Critical
> Labels: Java17, jdk17
>
> When trying to add multiple _Locators_ to the same cluster, particularly when
> "_direct_" {{ByteBuffers}} are used, the following Exception is thrown:
> {code:java}
> Caused by: org.apache.geode.SystemConnectException: One or more peers
> generated exceptions during connection attempt
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1634)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at
> org.springframework.data.gemfire.LocatorFactoryBean.init(LocatorFactoryBean.java:120)
> ... 44 more
> Caused by: 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:101)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:258)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:318)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:525)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2064)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1991)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:75)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1631)
> ... 56 more
> 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 @2e0fa5d3
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> 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)
> ... 69 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-9466) ByteBufferInputStream.OffHeapByteSource fails on Java 16 and later
[
https://issues.apache.org/jira/browse/GEODE-9466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-9466.
-
Fix Version/s: 1.15.0
Resolution: Fixed
> ByteBufferInputStream.OffHeapByteSource fails on Java 16 and later
> --
>
> Key: GEODE-9466
> URL: https://issues.apache.org/jira/browse/GEODE-9466
> Project: Geode
> Issue Type: Bug
> Components: offheap
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java16, Java17, pull-request-available
> Fix For: 1.15.0
>
>
> ByteBufferInputStream.OffHeapByteSource has a method determineUnaligned that
> will always fail on java 16 and later. This is because it calls
> Method.setAccessible which is not allowed under normal conditions starting
> with java 16 (see:
> [https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16]).
> The method is called when the class is loaded so it will cause the class load
> to fail. It tries to handle exceptions on return false but the exception java
> 16 throws is a RuntimeException and that is not caught. The exception it will
> fail with is java.lang.reflect.InaccessibleObjectException.
> A workaround for this bug is to start the jvm with --illegal-access=permit
> This causes ByteBufferInputStream to do a bunch of its work a byte at a time
> instead of using the optimal multi-byte methods like readShort, readInt, and
> readLong.
> It would be simple to change determineUnaligned to catch RuntimeException
> from setAccessible and then to read the "os.arch" system property and if it
> is any of the following to return true:
> {code:java}
> arch.equals("i386") || arch.equals("x86")
> || arch.equals("amd64") || arch.equals("x86_64")
> || arch.equals("ppc64") || arch.equals("ppc64le")
> {code}
> This is what the Bits class does in jdk 8. In jdk 16 this logic has moved to
> UnsafeConstants and its value is injected by the JVM so it is unclear if the
> list has grown.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10253) remove prepareForSample from StatisticsImpl
Darrel Schneider created GEODE-10253: Summary: remove prepareForSample from StatisticsImpl Key: GEODE-10253 URL: https://issues.apache.org/jira/browse/GEODE-10253 Project: Geode Issue Type: Improvement Components: statistics Reporter: Darrel Schneider The internal implementation of stats in geode has a prepareForSample method on StatisticsImpl. It used to do something in a subclass but is now always a noop. So it should be removed and the callers of it (in HostStatSampler) can be simplified. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-9466) ByteBufferInputStream.OffHeapByteSource fails on Java 16 and later
[
https://issues.apache.org/jira/browse/GEODE-9466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider reassigned GEODE-9466:
---
Assignee: Darrel Schneider
> ByteBufferInputStream.OffHeapByteSource fails on Java 16 and later
> --
>
> Key: GEODE-9466
> URL: https://issues.apache.org/jira/browse/GEODE-9466
> Project: Geode
> Issue Type: Bug
> Components: offheap
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java16, Java17
>
> ByteBufferInputStream.OffHeapByteSource has a method determineUnaligned that
> will always fail on java 16 and later. This is because it calls
> Method.setAccessible which is not allowed under normal conditions starting
> with java 16 (see:
> [https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16]).
> The method is called when the class is loaded so it will cause the class load
> to fail. It tries to handle exceptions on return false but the exception java
> 16 throws is a RuntimeException and that is not caught. The exception it will
> fail with is java.lang.reflect.InaccessibleObjectException.
> A workaround for this bug is to start the jvm with --illegal-access=permit
> This causes ByteBufferInputStream to do a bunch of its work a byte at a time
> instead of using the optimal multi-byte methods like readShort, readInt, and
> readLong.
> It would be simple to change determineUnaligned to catch RuntimeException
> from setAccessible and then to read the "os.arch" system property and if it
> is any of the following to return true:
> {code:java}
> arch.equals("i386") || arch.equals("x86")
> || arch.equals("amd64") || arch.equals("x86_64")
> || arch.equals("ppc64") || arch.equals("ppc64le")
> {code}
> This is what the Bits class does in jdk 8. In jdk 16 this logic has moved to
> UnsafeConstants and its value is injected by the JVM so it is unclear if the
> list has grown.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-10246) OutOfMemoryDUnitTest throws JedisDataException on JDK17
[
https://issues.apache.org/jira/browse/GEODE-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-10246.
--
Fix Version/s: 1.15.0
Resolution: Fixed
> OutOfMemoryDUnitTest throws JedisDataException on JDK17
> ---
>
> Key: GEODE-10246
> URL: https://issues.apache.org/jira/browse/GEODE-10246
> Project: Geode
> Issue Type: Improvement
> Components: redis, tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java17, pull-request-available
> Fix For: 1.15.0
>
>
> These three OutOfMemoryDUnitTest tests fail on JDK17:
> * shouldAllowWriteOperations_onOtherServer_afterDroppingBelowCriticalThreshold
> * shouldReturnOOMError_forPublish_whenThresholdReached
> * shouldReturnOOMError_forSubscribe_whenThresholdReached
> The Concurrent Mark Sweep (CMS) garbage collector does not exist on JDK17.
> My hunch is that the test code relies on CMS-like behavior to establish "over
> the memory threshold" conditions for the test.
> Example test results here:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7590/test-results/distributedTest/1650326807/
> Example stack trace:
> {noformat}
> org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple Failures
> (2 failures)
> org.opentest4j.AssertionFailedError:
> Expecting message to be:
> "OOM command not allowed when used memory > 'maxmemory'"
> but was:
> "ERR The server had an internal error please try again"
> Throwable that failed the check:
> redis.clients.jedis.exceptions.JedisDataException: ERR The server had an
> internal error please try again
> at redis.clients.jedis.Protocol.processError(Protocol.java:96)
> at redis.clients.jedis.Protocol.process(Protocol.java:137)
> at redis.clients.jedis.Protocol.read(Protocol.java:192)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:316)
> at redis.clients.jedis.Connection.getOne(Connection.java:298)
> at redis.clients.jedis.Connection.executeCommand(Connection.java:123)
> at
> redis.clients.jedis.executors.ClusterCommandExecutor.executeCommand(ClusterCommandExecutor.java:57)
> at
> redis.clients.jedis.UnifiedJedis.executeCommand(UnifiedJedis.java:139)
> at redis.clients.jedis.UnifiedJedis.set(UnifiedJedis.java:491)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.lambda$fillServer1Memory$39(OutOfMemoryDUnitTest.java:359)
> at
> org.assertj.core.api.ThrowableAssert.catchThrowable(ThrowableAssert.java:63)
> at
> org.assertj.core.api.AssertionsForClassTypes.catchThrowable(AssertionsForClassTypes.java:878)
> at org.assertj.core.api.Assertions.catchThrowable(Assertions.java:1337)
> at
> org.assertj.core.api.Assertions.assertThatThrownBy(Assertions.java:1181)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.fillServer1Memory(OutOfMemoryDUnitTest.java:352)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.shouldAllowWriteOperations_onOtherServer_afterDroppingBelowCriticalThreshold(OutOfMemoryDUnitTest.java:289)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at
[jira] [Commented] (GEODE-9466) ByteBufferInputStream.OffHeapByteSource fails on Java 16 and later
[
https://issues.apache.org/jira/browse/GEODE-9466?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524629#comment-17524629
]
Darrel Schneider commented on GEODE-9466:
-
For this code to work on jdk17 in the 1.15 release "java.nio" needs to be
opened.
> ByteBufferInputStream.OffHeapByteSource fails on Java 16 and later
> --
>
> Key: GEODE-9466
> URL: https://issues.apache.org/jira/browse/GEODE-9466
> Project: Geode
> Issue Type: Bug
> Components: offheap
>Reporter: Darrel Schneider
>Priority: Major
> Labels: Java16, Java17
>
> ByteBufferInputStream.OffHeapByteSource has a method determineUnaligned that
> will always fail on java 16 and later. This is because it calls
> Method.setAccessible which is not allowed under normal conditions starting
> with java 16 (see:
> [https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16]).
> The method is called when the class is loaded so it will cause the class load
> to fail. It tries to handle exceptions on return false but the exception java
> 16 throws is a RuntimeException and that is not caught. The exception it will
> fail with is java.lang.reflect.InaccessibleObjectException.
> A workaround for this bug is to start the jvm with --illegal-access=permit
> This causes ByteBufferInputStream to do a bunch of its work a byte at a time
> instead of using the optimal multi-byte methods like readShort, readInt, and
> readLong.
> It would be simple to change determineUnaligned to catch RuntimeException
> from setAccessible and then to read the "os.arch" system property and if it
> is any of the following to return true:
> {code:java}
> arch.equals("i386") || arch.equals("x86")
> || arch.equals("amd64") || arch.equals("x86_64")
> || arch.equals("ppc64") || arch.equals("ppc64le")
> {code}
> This is what the Bits class does in jdk 8. In jdk 16 this logic has moved to
> UnsafeConstants and its value is injected by the JVM so it is unclear if the
> list has grown.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-9466) ByteBufferInputStream.OffHeapByteSource fails on Java 16 and later
[
https://issues.apache.org/jira/browse/GEODE-9466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-9466:
Labels: Java16 Java17 (was: Java16)
> ByteBufferInputStream.OffHeapByteSource fails on Java 16 and later
> --
>
> Key: GEODE-9466
> URL: https://issues.apache.org/jira/browse/GEODE-9466
> Project: Geode
> Issue Type: Bug
> Components: offheap
>Reporter: Darrel Schneider
>Priority: Major
> Labels: Java16, Java17
>
> ByteBufferInputStream.OffHeapByteSource has a method determineUnaligned that
> will always fail on java 16 and later. This is because it calls
> Method.setAccessible which is not allowed under normal conditions starting
> with java 16 (see:
> [https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16]).
> The method is called when the class is loaded so it will cause the class load
> to fail. It tries to handle exceptions on return false but the exception java
> 16 throws is a RuntimeException and that is not caught. The exception it will
> fail with is java.lang.reflect.InaccessibleObjectException.
> A workaround for this bug is to start the jvm with --illegal-access=permit
> This causes ByteBufferInputStream to do a bunch of its work a byte at a time
> instead of using the optimal multi-byte methods like readShort, readInt, and
> readLong.
> It would be simple to change determineUnaligned to catch RuntimeException
> from setAccessible and then to read the "os.arch" system property and if it
> is any of the following to return true:
> {code:java}
> arch.equals("i386") || arch.equals("x86")
> || arch.equals("amd64") || arch.equals("x86_64")
> || arch.equals("ppc64") || arch.equals("ppc64le")
> {code}
> This is what the Bits class does in jdk 8. In jdk 16 this logic has moved to
> UnsafeConstants and its value is injected by the JVM so it is unclear if the
> list has grown.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-9467) pdx ReflectionBasedAutoSerializer will fail on java 16 and later
[ https://issues.apache.org/jira/browse/GEODE-9467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9467: Labels: Java16 Java17 (was: Java16) > pdx ReflectionBasedAutoSerializer will fail on java 16 and later > > > Key: GEODE-9467 > URL: https://issues.apache.org/jira/browse/GEODE-9467 > Project: Geode > Issue Type: Bug > Components: serialization >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > > The pdx ReflectionBasedAutoSerializer will not work on java 16 and later > because it calls Field.setAccessible which is not allowed under normal > conditions starting with java 16 (see: > [https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16|https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16/] > > [).|https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m).] > To workaround this failure set the JVM command line option: > --illegal-access=permit > The call is made in > org.apache.geode.pdx.internal.AutoSerializableManager#getClassInfo and is > required for the auto serializer to function correctly. > > > > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (GEODE-9471) gfsh show dead-locks will fail on java 16 and later
[ https://issues.apache.org/jira/browse/GEODE-9471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17524628#comment-17524628 ] Darrel Schneider commented on GEODE-9471: - For 1.15 the current implementation requires an add-opens of "java.lang" for the ThreadLocal class's privates. > gfsh show dead-locks will fail on java 16 and later > --- > > Key: GEODE-9471 > URL: https://issues.apache.org/jira/browse/GEODE-9471 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > > The gfsh show dead-locks command ends up depending on this class: > org.apache.geode.distributed.internal.deadlock.UnsafeThreadLocal > Most of the time this UnsafeThreadLocal just behaves like a normal jdk > ThreadLocal (its super class). But when the gfsh command is executed it > causes "get" to be called on UnsafeThreadLocal. It uses a bunch of reflection > to prevent "get" from setting an initial value in the case of a miss. This > reflection calls setAccessible which will cause get to fail on java 16 and > later (see: > [https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16]). > To workaround this failure set the JVM command line option: > --illegal-access=permit > The current solution adds get(Thread) to UnsafeThreadLocal which is different > than ThreadLocal.get(). To fix this we probably need to stop using > ThreadLocal and instead keep some kind of collection of the threads waiting > for a resource. It might also be possible to ask the resource what threads > are waiting for it. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-9471) gfsh show dead-locks will fail on java 16 and later
[ https://issues.apache.org/jira/browse/GEODE-9471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9471: Labels: Java16 Java17 (was: Java16) > gfsh show dead-locks will fail on java 16 and later > --- > > Key: GEODE-9471 > URL: https://issues.apache.org/jira/browse/GEODE-9471 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > > The gfsh show dead-locks command ends up depending on this class: > org.apache.geode.distributed.internal.deadlock.UnsafeThreadLocal > Most of the time this UnsafeThreadLocal just behaves like a normal jdk > ThreadLocal (its super class). But when the gfsh command is executed it > causes "get" to be called on UnsafeThreadLocal. It uses a bunch of reflection > to prevent "get" from setting an initial value in the case of a miss. This > reflection calls setAccessible which will cause get to fail on java 16 and > later (see: > [https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16]). > To workaround this failure set the JVM command line option: > --illegal-access=permit > The current solution adds get(Thread) to UnsafeThreadLocal which is different > than ThreadLocal.get(). To fix this we probably need to stop using > ThreadLocal and instead keep some kind of collection of the threads waiting > for a resource. It might also be possible to ask the resource what threads > are waiting for it. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (GEODE-9470) Some geode queries will fail on java 16 and later
[ https://issues.apache.org/jira/browse/GEODE-9470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522985#comment-17522985 ] Darrel Schneider edited comment on GEODE-9470 at 4/19/22 11:29 PM: --- These setAccessible calls should not be an issue with geode 1.15 since any domain classes added by the user to the server's class path will need to not be in named modules so they will automatically be open to geode since both will be in the unnamed module. But we need to decide if we want to support user classes that are in named modules for 1.15. If so then users will need to do an add-opens was (Author: dschneider): These setAccessible calls should not be an issue with geode 1.15 since any domain classes added by the user to the server's class path will need to not be in named modules so they will automatically be open to geode since both will be in the unnamed module. > Some geode queries will fail on java 16 and later > - > > Key: GEODE-9470 > URL: https://issues.apache.org/jira/browse/GEODE-9470 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > > In some cases a geode query uses reflection to read a field or call a > function. > If that happens on java 16 then the query will fail throwing a > RuntimeException that is an instance of > java.lang.reflect.InaccessibleObjectException. See: > https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16. > To workaround this failure set the JVM command line option: > --illegal-access=permit > The query code that calls setAccessible is in two places: > org.apache.geode.cache.query.internal.AttributeDescriptor#getReadMember > org.apache.geode.cache.query.internal.MethodDispatch#MethodDispatch -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-9470) Some geode queries will fail on java 16 and later
[ https://issues.apache.org/jira/browse/GEODE-9470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9470: Labels: Java16 Java17 (was: Java16) > Some geode queries will fail on java 16 and later > - > > Key: GEODE-9470 > URL: https://issues.apache.org/jira/browse/GEODE-9470 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > > In some cases a geode query uses reflection to read a field or call a > function. > If that happens on java 16 then the query will fail throwing a > RuntimeException that is an instance of > java.lang.reflect.InaccessibleObjectException. See: > https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16. > To workaround this failure set the JVM command line option: > --illegal-access=permit > The query code that calls setAccessible is in two places: > org.apache.geode.cache.query.internal.AttributeDescriptor#getReadMember > org.apache.geode.cache.query.internal.MethodDispatch#MethodDispatch -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9468) tomcat session state management will not work on java 16
[ https://issues.apache.org/jira/browse/GEODE-9468?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-9468. - Resolution: Not A Problem > tomcat session state management will not work on java 16 > > > Key: GEODE-9468 > URL: https://issues.apache.org/jira/browse/GEODE-9468 > Project: Geode > Issue Type: Bug > Components: http session >Reporter: Darrel Schneider >Priority: Major > Labels: Java16 > > The class org.apache.geode.modules.session.catalina.DeltaSession calls > Field.setAccessible in a static block. It is getting access to a field in the > super class which was private in tomcat 7 (see GEODE-3434). Because of this > tomcat session state management will not work on java 16 (see > [https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16/)] > unless jvm args are used to permit the call (for example > "--illegal-access=permit"). > If we can drop support for tomcat 7 then this reflection would no longer be > needed. It might also be possible to only call setAccessible if the field is > private which would mean only tomcat 7 would not work on java 16. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-9469) CopyHelper.copy will fail on java 16 and later when copying instances of Clonable
[ https://issues.apache.org/jira/browse/GEODE-9469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9469: Labels: Java16 Java17 (was: Java16) > CopyHelper.copy will fail on java 16 and later when copying instances of > Clonable > - > > Key: GEODE-9469 > URL: https://issues.apache.org/jira/browse/GEODE-9469 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > > CopyHelper.copy is an API that allows geode users to make copies of objects. > It is also used internally by a number of geode features. The copy-on-read > region attribute is one example. If the object being copied is an instance of > Cloneable then on java 16, copy will throw a RuntimeException which is an > instance of java.lang.reflect.InaccessibleObjectException. > The copy code tries to catch exceptions during the clone and instead use > serialization to make a copy but it does not catch RuntimeException which is > what java 16 throws from setAccessible. It would be pretty easy to fix this > exception handling. > The only work arounds are to not implement Cloneable or to start the jvm with > the command line option: --illegal-access=permit. > See: > [https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16|https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16/] > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-9473) Geode deserialization will fail on java 16
[ https://issues.apache.org/jira/browse/GEODE-9473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9473: Labels: Java16 Java17 (was: Java16) > Geode deserialization will fail on java 16 > -- > > Key: GEODE-9473 > URL: https://issues.apache.org/jira/browse/GEODE-9473 > Project: Geode > Issue Type: Bug > Components: serialization >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > > In three different places geode deserialization calls setAccessible in order > to make the constructor callable. This will not work on java 16 and later > because it calls Field.setAccessible which is not allowed under normal > conditions starting with java 16 (see: > https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16 ). > To workaround this failure set the JVM command line option: > --illegal-access=permit or use --add-opens. > The places that make the calls for deserialization are: > * org.apache.geode.internal.InternalDataSerializer#newInstance > * org.apache.geode.internal.InternalDataSerializer#readDataSerializable > * org.apache.geode.internal.InternalInstantiator#newInstance -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-9475) ObjectSizer will fail on java 16 and later
[ https://issues.apache.org/jira/browse/GEODE-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9475: Labels: Java16 Java17 (was: Java16) > ObjectSizer will fail on java 16 and later > -- > > Key: GEODE-9475 > URL: https://issues.apache.org/jira/browse/GEODE-9475 > Project: Geode > Issue Type: Bug > Components: core >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > > The instances of org.apache.geode.cache.util.ObjectSizer, SIZE_CLASS_ONCE, > REFLECTION_SIZE, and DEFAULT will not work on java 16 and later because they > call Field.setAccessible which is not allowed under normal conditions > starting with java 16 (see: > https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16 ). > To workaround this failure set the JVM command line option: > --illegal-access=permit > These ObjectSizer instances are used in a number of places internally by > geode and can also explicitly be configured by users. Internally they are > used by default for eviction (heap or mem), the wan gateway, and tombstone > gc. Most all regions produce tombstones so that is the most likely point of > failure. > The code that calls setAccessible is: > org.apache.geode.internal.size.ObjectTraverser#buildFieldSet and it is not > clear how this code can be changed to do its job without using setAccessible. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (GEODE-9474) the Geode offheap feature will fail on java 16
[ https://issues.apache.org/jira/browse/GEODE-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522983#comment-17522983 ] Darrel Schneider edited comment on GEODE-9474 at 4/19/22 11:25 PM: --- For Java17 we need the server to have "java.nio" opened for offheap to work. I think we should just add this to the list of opens needed by geode features. was (Author: dschneider): For Java17 we need to server to have "java.nio" opened for offheap to work. I think we should just add this to the list of opens needed by geode features. > the Geode offheap feature will fail on java 16 > -- > > Key: GEODE-9474 > URL: https://issues.apache.org/jira/browse/GEODE-9474 > Project: Geode > Issue Type: Bug > Components: offheap >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > > In two different places geode offheap calls setAccessible. In one place it is > to call the "address" method. In the other it is to call the DIrectByteBuffer > constructor that passes an address in to the constructor. These will not work > on java 16 and later because it calls Method.setAccessible which is not > allowed under normal conditions starting with java 16 (see: > https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16 ). > To workaround this failure set the JVM command line option: > --illegal-access=permit or use --add-opens. > The places that make the calls: > * > org.apache.geode.internal.offheap.AddressableMemoryManager#getDirectByteBufferAddress > * > org.apache.geode.internal.offheap.AddressableMemoryManager#createDirectByteBuffer > The "address" call does not need to use reflection and setAccessible but can > instead do it with casting. See > org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer for how this is done. > The constructor issue is a bigger problem. This constructor can be called > from JNI NewDirectByteBuffer but needing to add native code to geode does not > seem worth the trouble. If some other solution can not be found then the > above workaround would need to be used if offheap is. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-9477) Geode membership will have issues on java 16 and later
[ https://issues.apache.org/jira/browse/GEODE-9477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-9477. - Resolution: Not A Problem > Geode membership will have issues on java 16 and later > -- > > Key: GEODE-9477 > URL: https://issues.apache.org/jira/browse/GEODE-9477 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Darrel Schneider >Priority: Major > Labels: Java16 > > Geode membership uses setAccessible in a number of places to access jgroups > internals. > This will not work on java 16 and later (see: > https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16). > A workaround for this bug is to start the jvm with --illegal-access=permit > The places that call setAccessible in membership are: > * > org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager#findPingDataMethod > (the catch in this method will not catch the RuntimeException thrown by > setAccessible) > * > org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger#setChannelReceiver > * > org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger#start > * > org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger#checkForIPv6 > * > org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger#establishLocalAddress -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10246) OutOfMemoryDUnitTest throws JedisDataException on JDK17
[
https://issues.apache.org/jira/browse/GEODE-10246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider reassigned GEODE-10246:
Assignee: Darrel Schneider
> OutOfMemoryDUnitTest throws JedisDataException on JDK17
> ---
>
> Key: GEODE-10246
> URL: https://issues.apache.org/jira/browse/GEODE-10246
> Project: Geode
> Issue Type: Improvement
> Components: redis, tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java17
>
> These three OutOfMemoryDUnitTest tests fail on JDK17:
> * shouldAllowWriteOperations_onOtherServer_afterDroppingBelowCriticalThreshold
> * shouldReturnOOMError_forPublish_whenThresholdReached
> * shouldReturnOOMError_forSubscribe_whenThresholdReached
> The Concurrent Mark Sweep (CMS) garbage collector does not exist on JDK17.
> My hunch is that the test code relies on CMS-like behavior to establish "over
> the memory threshold" conditions for the test.
> Example test results here:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7590/test-results/distributedTest/1650326807/
> Example stack trace:
> {noformat}
> org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple Failures
> (2 failures)
> org.opentest4j.AssertionFailedError:
> Expecting message to be:
> "OOM command not allowed when used memory > 'maxmemory'"
> but was:
> "ERR The server had an internal error please try again"
> Throwable that failed the check:
> redis.clients.jedis.exceptions.JedisDataException: ERR The server had an
> internal error please try again
> at redis.clients.jedis.Protocol.processError(Protocol.java:96)
> at redis.clients.jedis.Protocol.process(Protocol.java:137)
> at redis.clients.jedis.Protocol.read(Protocol.java:192)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:316)
> at redis.clients.jedis.Connection.getOne(Connection.java:298)
> at redis.clients.jedis.Connection.executeCommand(Connection.java:123)
> at
> redis.clients.jedis.executors.ClusterCommandExecutor.executeCommand(ClusterCommandExecutor.java:57)
> at
> redis.clients.jedis.UnifiedJedis.executeCommand(UnifiedJedis.java:139)
> at redis.clients.jedis.UnifiedJedis.set(UnifiedJedis.java:491)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.lambda$fillServer1Memory$39(OutOfMemoryDUnitTest.java:359)
> at
> org.assertj.core.api.ThrowableAssert.catchThrowable(ThrowableAssert.java:63)
> at
> org.assertj.core.api.AssertionsForClassTypes.catchThrowable(AssertionsForClassTypes.java:878)
> at org.assertj.core.api.Assertions.catchThrowable(Assertions.java:1337)
> at
> org.assertj.core.api.Assertions.assertThatThrownBy(Assertions.java:1181)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.fillServer1Memory(OutOfMemoryDUnitTest.java:352)
> at
> org.apache.geode.redis.OutOfMemoryDUnitTest.shouldAllowWriteOperations_onOtherServer_afterDroppingBelowCriticalThreshold(OutOfMemoryDUnitTest.java:289)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at
[jira] [Resolved] (GEODE-10197) OutOfMemoryDUnitTest fails on java 17 because CMSInitiatingOccupancyFraction no longer exists
[ https://issues.apache.org/jira/browse/GEODE-10197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-10197. -- Fix Version/s: 1.15.0 Resolution: Fixed > OutOfMemoryDUnitTest fails on java 17 because CMSInitiatingOccupancyFraction > no longer exists > - > > Key: GEODE-10197 > URL: https://issues.apache.org/jira/browse/GEODE-10197 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: Java17, pull-request-available > Fix For: 1.15.0 > > > This test is explicitly adding CMSInitiatingOccupancyFraction but cms has > been removed in later java releases. > OutOfMemoryDUnitTest > initializationError FAILED > org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple > Failures (2 failures) > org.opentest4j.AssertionFailedError: [The Cache Server process > terminated unexpectedly with exit status 1. > Unrecognized VM option 'CMSInitiatingOccupancyFraction=45' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9476) VMStats processCpuTime, fdLimit, and fdsOpen will always be zero on java 16 and later
[
https://issues.apache.org/jira/browse/GEODE-9476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522987#comment-17522987
]
Darrel Schneider commented on GEODE-9476:
-
this is an issue for geode 1.15 because the setAccessible call is made to a jdk
class. For these stats to work on jdk17 our server and locator process need
"sun.management" opened to the unnamed module.
> VMStats processCpuTime, fdLimit, and fdsOpen will always be zero on java 16
> and later
> -
>
> Key: GEODE-9476
> URL: https://issues.apache.org/jira/browse/GEODE-9476
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Reporter: Darrel Schneider
>Priority: Major
> Labels: Java16, Java17
>
> VMStats processCpuTime, fdLimit, and fdsOpen will always be zero on java 16
> and later.
> This is because it calls Method.setAccessible which is not allowed under
> normal conditions starting with java 16 (see:
> https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16).
> A workaround for this bug is to start the jvm with --illegal-access=permit
> The setAccessible call is in the static initializer for:
> org.apache.geode.internal.stats50.VMStats50
> It turns out the following works for calling processCpuTime:
> {code:java}
> OperatingSystemMXBean osBean =
> ManagementFactory.getOperatingSystemMXBean();
> com.sun.management.OperatingSystemMXBean sunBean =
> (com.sun.management.OperatingSystemMXBean) osBean;
> System.out.println("getProcessCpuTime=" +
> sunBean.getProcessCpuTime());
> {code}
> so we can get rid of the setAccessible call
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9476) VMStats processCpuTime, fdLimit, and fdsOpen will always be zero on java 16 and later
[
https://issues.apache.org/jira/browse/GEODE-9476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-9476:
Labels: Java16 Java17 (was: Java16)
> VMStats processCpuTime, fdLimit, and fdsOpen will always be zero on java 16
> and later
> -
>
> Key: GEODE-9476
> URL: https://issues.apache.org/jira/browse/GEODE-9476
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Reporter: Darrel Schneider
>Priority: Major
> Labels: Java16, Java17
>
> VMStats processCpuTime, fdLimit, and fdsOpen will always be zero on java 16
> and later.
> This is because it calls Method.setAccessible which is not allowed under
> normal conditions starting with java 16 (see:
> https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16).
> A workaround for this bug is to start the jvm with --illegal-access=permit
> The setAccessible call is in the static initializer for:
> org.apache.geode.internal.stats50.VMStats50
> It turns out the following works for calling processCpuTime:
> {code:java}
> OperatingSystemMXBean osBean =
> ManagementFactory.getOperatingSystemMXBean();
> com.sun.management.OperatingSystemMXBean sunBean =
> (com.sun.management.OperatingSystemMXBean) osBean;
> System.out.println("getProcessCpuTime=" +
> sunBean.getProcessCpuTime());
> {code}
> so we can get rid of the setAccessible call
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9468) tomcat session state management will not work on java 16
[ https://issues.apache.org/jira/browse/GEODE-9468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522986#comment-17522986 ] Darrel Schneider commented on GEODE-9468: - These setAccessible class should not be an issue for geode 1.15 because the tomcat code is in the same unnamed module that geode is in so all the tomcat packages are open to geode. > tomcat session state management will not work on java 16 > > > Key: GEODE-9468 > URL: https://issues.apache.org/jira/browse/GEODE-9468 > Project: Geode > Issue Type: Bug > Components: http session >Reporter: Darrel Schneider >Priority: Major > Labels: Java16 > > The class org.apache.geode.modules.session.catalina.DeltaSession calls > Field.setAccessible in a static block. It is getting access to a field in the > super class which was private in tomcat 7 (see GEODE-3434). Because of this > tomcat session state management will not work on java 16 (see > [https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16/)] > unless jvm args are used to permit the call (for example > "--illegal-access=permit"). > If we can drop support for tomcat 7 then this reflection would no longer be > needed. It might also be possible to only call setAccessible if the field is > private which would mean only tomcat 7 would not work on java 16. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9470) Some geode queries will fail on java 16 and later
[ https://issues.apache.org/jira/browse/GEODE-9470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522985#comment-17522985 ] Darrel Schneider commented on GEODE-9470: - These setAccessible calls should not be an issue with geode 1.15 since any domain classes added by the user to the server's class path will need to not be in named modules so they will automatically be open to geode since both will be in the unnamed module. > Some geode queries will fail on java 16 and later > - > > Key: GEODE-9470 > URL: https://issues.apache.org/jira/browse/GEODE-9470 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Darrel Schneider >Priority: Major > Labels: Java16 > > In some cases a geode query uses reflection to read a field or call a > function. > If that happens on java 16 then the query will fail throwing a > RuntimeException that is an instance of > java.lang.reflect.InaccessibleObjectException. See: > https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16. > To workaround this failure set the JVM command line option: > --illegal-access=permit > The query code that calls setAccessible is in two places: > org.apache.geode.cache.query.internal.AttributeDescriptor#getReadMember > org.apache.geode.cache.query.internal.MethodDispatch#MethodDispatch -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9477) Geode membership will have issues on java 16 and later
[ https://issues.apache.org/jira/browse/GEODE-9477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522984#comment-17522984 ] Darrel Schneider commented on GEODE-9477: - I think none of these setAccessible calls are an issue for geode 1.15 because the jgroups we ship with geode is in the same unnamed module as geode so everything in jgroups is open to geode code. > Geode membership will have issues on java 16 and later > -- > > Key: GEODE-9477 > URL: https://issues.apache.org/jira/browse/GEODE-9477 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Darrel Schneider >Priority: Major > Labels: Java16 > > Geode membership uses setAccessible in a number of places to access jgroups > internals. > This will not work on java 16 and later (see: > https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16). > A workaround for this bug is to start the jvm with --illegal-access=permit > The places that call setAccessible in membership are: > * > org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager#findPingDataMethod > (the catch in this method will not catch the RuntimeException thrown by > setAccessible) > * > org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger#setChannelReceiver > * > org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger#start > * > org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger#checkForIPv6 > * > org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger#establishLocalAddress -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9474) the Geode offheap feature will fail on java 16
[ https://issues.apache.org/jira/browse/GEODE-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522983#comment-17522983 ] Darrel Schneider commented on GEODE-9474: - For Java17 we need to server to have "java.nio" opened for offheap to work. I think we should just add this to the list of opens needed by geode features. > the Geode offheap feature will fail on java 16 > -- > > Key: GEODE-9474 > URL: https://issues.apache.org/jira/browse/GEODE-9474 > Project: Geode > Issue Type: Bug > Components: offheap >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > > In two different places geode offheap calls setAccessible. In one place it is > to call the "address" method. In the other it is to call the DIrectByteBuffer > constructor that passes an address in to the constructor. These will not work > on java 16 and later because it calls Method.setAccessible which is not > allowed under normal conditions starting with java 16 (see: > https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16 ). > To workaround this failure set the JVM command line option: > --illegal-access=permit or use --add-opens. > The places that make the calls: > * > org.apache.geode.internal.offheap.AddressableMemoryManager#getDirectByteBufferAddress > * > org.apache.geode.internal.offheap.AddressableMemoryManager#createDirectByteBuffer > The "address" call does not need to use reflection and setAccessible but can > instead do it with casting. See > org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer for how this is done. > The constructor issue is a bigger problem. This constructor can be called > from JNI NewDirectByteBuffer but needing to add native code to geode does not > seem worth the trouble. If some other solution can not be found then the > above workaround would need to be used if offheap is. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9474) the Geode offheap feature will fail on java 16
[ https://issues.apache.org/jira/browse/GEODE-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9474: Labels: Java16 Java17 (was: Java16) > the Geode offheap feature will fail on java 16 > -- > > Key: GEODE-9474 > URL: https://issues.apache.org/jira/browse/GEODE-9474 > Project: Geode > Issue Type: Bug > Components: offheap >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > > In two different places geode offheap calls setAccessible. In one place it is > to call the "address" method. In the other it is to call the DIrectByteBuffer > constructor that passes an address in to the constructor. These will not work > on java 16 and later because it calls Method.setAccessible which is not > allowed under normal conditions starting with java 16 (see: > https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16 ). > To workaround this failure set the JVM command line option: > --illegal-access=permit or use --add-opens. > The places that make the calls: > * > org.apache.geode.internal.offheap.AddressableMemoryManager#getDirectByteBufferAddress > * > org.apache.geode.internal.offheap.AddressableMemoryManager#createDirectByteBuffer > The "address" call does not need to use reflection and setAccessible but can > instead do it with casting. See > org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer for how this is done. > The constructor issue is a bigger problem. This constructor can be called > from JNI NewDirectByteBuffer but needing to add native code to geode does not > seem worth the trouble. If some other solution can not be found then the > above workaround would need to be used if offheap is. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10197) OutOfMemoryDUnitTest fails on java 17 because CMSInitiatingOccupancyFraction no longer exists
[ https://issues.apache.org/jira/browse/GEODE-10197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-10197: Assignee: Darrel Schneider > OutOfMemoryDUnitTest fails on java 17 because CMSInitiatingOccupancyFraction > no longer exists > - > > Key: GEODE-10197 > URL: https://issues.apache.org/jira/browse/GEODE-10197 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: Java17 > > This test is explicitly adding CMSInitiatingOccupancyFraction but cms has > been removed in later java releases. > OutOfMemoryDUnitTest > initializationError FAILED > org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple > Failures (2 failures) > org.opentest4j.AssertionFailedError: [The Cache Server process > terminated unexpectedly with exit status 1. > Unrecognized VM option 'CMSInitiatingOccupancyFraction=45' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10238) Jetty9CachingClientServerTest fails on java 17
[
https://issues.apache.org/jira/browse/GEODE-10238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-10238.
--
Fix Version/s: 1.15.0
Resolution: Fixed
> Jetty9CachingClientServerTest fails on java 17
> --
>
> Key: GEODE-10238
> URL: https://issues.apache.org/jira/browse/GEODE-10238
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java17, pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> Jetty9CachingClientServerTest > shouldCacheSessionOnClient FAILED
> org.opentest4j.AssertionFailedError:
> expected: ""
> but was: "Error in servlet:
> java.lang.reflect.InaccessibleObjectException: Unable to make field private
> transient sun.security.provider.AbstractDrbg sun.security.provider.DRBG.impl
> accessible: module java.base does not "opens sun.security.provider" to
> unnamed module @47874b25"
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:59)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10238) Jetty9CachingClientServerTest fails on java 17
[
https://issues.apache.org/jira/browse/GEODE-10238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-10238:
-
Labels: Java17 (was: )
> Jetty9CachingClientServerTest fails on java 17
> --
>
> Key: GEODE-10238
> URL: https://issues.apache.org/jira/browse/GEODE-10238
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Reporter: Darrel Schneider
>Priority: Major
> Labels: Java17
>
> {noformat}
> Jetty9CachingClientServerTest > shouldCacheSessionOnClient FAILED
> org.opentest4j.AssertionFailedError:
> expected: ""
> but was: "Error in servlet:
> java.lang.reflect.InaccessibleObjectException: Unable to make field private
> transient sun.security.provider.AbstractDrbg sun.security.provider.DRBG.impl
> accessible: module java.base does not "opens sun.security.provider" to
> unnamed module @47874b25"
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:59)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10238) Jetty9CachingClientServerTest fails on java 17
[
https://issues.apache.org/jira/browse/GEODE-10238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider reassigned GEODE-10238:
Assignee: Darrel Schneider
> Jetty9CachingClientServerTest fails on java 17
> --
>
> Key: GEODE-10238
> URL: https://issues.apache.org/jira/browse/GEODE-10238
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java17
>
> {noformat}
> Jetty9CachingClientServerTest > shouldCacheSessionOnClient FAILED
> org.opentest4j.AssertionFailedError:
> expected: ""
> but was: "Error in servlet:
> java.lang.reflect.InaccessibleObjectException: Unable to make field private
> transient sun.security.provider.AbstractDrbg sun.security.provider.DRBG.impl
> accessible: module java.base does not "opens sun.security.provider" to
> unnamed module @47874b25"
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:59)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10238) Jetty9CachingClientServerTest fails on java 17
Darrel Schneider created GEODE-10238:
Summary: Jetty9CachingClientServerTest fails on java 17
Key: GEODE-10238
URL: https://issues.apache.org/jira/browse/GEODE-10238
Project: Geode
Issue Type: Improvement
Components: tests
Reporter: Darrel Schneider
{noformat}
Jetty9CachingClientServerTest > shouldCacheSessionOnClient FAILED
org.opentest4j.AssertionFailedError:
expected: ""
but was: "Error in servlet: java.lang.reflect.InaccessibleObjectException:
Unable to make field private transient sun.security.provider.AbstractDrbg
sun.security.provider.DRBG.impl accessible: module java.base does not "opens
sun.security.provider" to unnamed module @47874b25"
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
at
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
at
org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:59)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-10185) ObjectTraverser cannot traverse a Proxy on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-10185.
--
Fix Version/s: 1.15.0
Resolution: Fixed
> ObjectTraverser cannot traverse a Proxy on JDK 17
> -
>
> Key: GEODE-10185
> URL: https://issues.apache.org/jira/browse/GEODE-10185
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java17, pull-request-available
> Fix For: 1.15.0
>
>
> On JDK 17, {{ObjectTraverser}} cannot make fields of a Proxy object's class
> accessible because the class is in an unopened package. JDK 17 creates proxy
> classes in "dynamic" packages created by the JDK as needed. These packages
> cannot be opened when starting the JVM (via {{{}--add-opens{}}}) because the
> packages do not exist at that time.
> {{MemoryOverheadIntegrationTest}} shows this failure in CI integration test
> tasks on JDK 17.
> * Example failure in CI:
> [https://concourse.apachegeode-ci.info/builds/40607693]
> * Test results:
> [http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7505/test-results/integrationTest/1648496987/]
> Stack trace:
> {noformat}
> java.lang.reflect.InaccessibleObjectException: Unable to make field private
> static final java.lang.reflect.Method jdk.proxy3.$Proxy36.m0 accessible:
> module jdk.proxy3 does not "opens jdk.proxy3" to unnamed module @64c5923
> at
> java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at
> java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
> at java.lang.reflect.Field.setAccessible(Field.java:172)
> at
> org.apache.geode.internal.size.ObjectTraverser.buildFieldSet(ObjectTraverser.java:116)
> 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:96)
> at
> org.apache.geode.redis.internal.data.MemoryOverheadIntegrationTest.getUsedMemory(MemoryOverheadIntegrationTest.java:95)
> at
> org.apache.geode.redis.internal.data.AbstractMemoryOverheadIntegrationTest.measureAndCheckPerEntryOverhead(AbstractMemoryOverheadIntegrationTest.java:284)
> at
> org.apache.geode.redis.internal.data.AbstractMemoryOverheadIntegrationTest.measureOverheadPerHash(AbstractMemoryOverheadIntegrationTest.java:127)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
[jira] [Resolved] (GEODE-10035) The System property condition to use "direct" ByteBuffers in P2P is wrong
[
https://issues.apache.org/jira/browse/GEODE-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-10035.
--
Fix Version/s: 1.15.0
Resolution: Fixed
> The System property condition to use "direct" ByteBuffers in P2P is wrong
> -
>
> Key: GEODE-10035
> URL: https://issues.apache.org/jira/browse/GEODE-10035
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: John Blum
>Assignee: Darrel Schneider
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member
> (static) constant field
> ([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
> which is derived from either the "{{p2p.nodirectBuffers"}} OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
> logic is incorrect!
> It should read (formatted to make it more readable):
> {code:java}
> public static final boolean useDirectBuffers = !(
> Boolean.getBoolean("p2p.nodirectBuffers")
> ||
> Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
> );
> {code}
> Alternatively:
> {code:java}
> public static final boolean useDirectBuffers =
> !Boolean.getBoolean("p2p.nodirectBuffers")
> &&
> !Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
> {code}
> That is, if either the "{{p2p.nodirectBuffers}}" OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then
> DO NOT USE direct ByteBuffers.
> The term "{{useHeapBuffers}}" implies that the buffer should be created on
> the JVM Heap, and not in main memory as a "direct" ByteBuffer.
> Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
> "{{true}}" would result in a direct ByteBuffer allocation as can be seen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
>
> rather than what should happen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
> As the condition currently stands, if the "{{p2p.nodirectBuffers}}" System
> property is not set at all (which results in {{Boolean.getBoolean(..)}}
> returning {{false}}), which negated results in the OR'd condition not even
> being evaluated!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10185) ObjectTraverser cannot traverse a Proxy on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider reassigned GEODE-10185:
Assignee: Darrel Schneider
> ObjectTraverser cannot traverse a Proxy on JDK 17
> -
>
> Key: GEODE-10185
> URL: https://issues.apache.org/jira/browse/GEODE-10185
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java17
>
> On JDK 17, {{ObjectTraverser}} cannot make fields of a Proxy object's class
> accessible because the class is in an unopened package. JDK 17 creates proxy
> classes in "dynamic" packages created by the JDK as needed. These packages
> cannot be opened when starting the JVM (via {{{}--add-opens{}}}) because the
> packages do not exist at that time.
> {{MemoryOverheadIntegrationTest}} shows this failure in CI integration test
> tasks on JDK 17.
> * Example failure in CI:
> [https://concourse.apachegeode-ci.info/builds/40607693]
> * Test results:
> [http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7505/test-results/integrationTest/1648496987/]
> Stack trace:
> {noformat}
> java.lang.reflect.InaccessibleObjectException: Unable to make field private
> static final java.lang.reflect.Method jdk.proxy3.$Proxy36.m0 accessible:
> module jdk.proxy3 does not "opens jdk.proxy3" to unnamed module @64c5923
> at
> java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at
> java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)
> at java.lang.reflect.Field.setAccessible(Field.java:172)
> at
> org.apache.geode.internal.size.ObjectTraverser.buildFieldSet(ObjectTraverser.java:116)
> 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:96)
> at
> org.apache.geode.redis.internal.data.MemoryOverheadIntegrationTest.getUsedMemory(MemoryOverheadIntegrationTest.java:95)
> at
> org.apache.geode.redis.internal.data.AbstractMemoryOverheadIntegrationTest.measureAndCheckPerEntryOverhead(AbstractMemoryOverheadIntegrationTest.java:284)
> at
> org.apache.geode.redis.internal.data.AbstractMemoryOverheadIntegrationTest.measureOverheadPerHash(AbstractMemoryOverheadIntegrationTest.java:127)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:568)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableExternalResource$1.evaluate(SerializableExternalResource.java:38)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at
[jira] [Updated] (GEODE-10159) Upgrade to Micrometer 1.9
[ https://issues.apache.org/jira/browse/GEODE-10159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-10159: - Labels: Java17 (was: ) > Upgrade to Micrometer 1.9 > - > > Key: GEODE-10159 > URL: https://issues.apache.org/jira/browse/GEODE-10159 > Project: Geode > Issue Type: Sub-task > Components: statistics >Reporter: Udo Kohlmeyer >Priority: Major > Labels: Java17 > > Micrometer 2.x introduces a new set of issues: > * Not being released in time for 9.15 > * Package name restructuring > * External public API's directly exposing the Micrometer classes, need to be > updated, and in so any external projects depending the exposed API > In order to avoid this revolutionary change from Micrometer 1.x -> 2.x, > Micrometer is releasing 1.9 version that will be the bridge between 1.x and > 2.x. > Spring Data Geode has already tested that updating to this version resolves > the issues that it has when integrating with Spring Boot 3.0, and deems this > version to be good. > Micrometer 1.9 has not made GA yet, but it is expected to be released around > May, given that Spring Boot 2.7 is dependent on Micrometer 1.9, and is > scheduled to be released in the May time frame. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9657) Javadoc errors occur on Java 17 due to split packages in Geode
[
https://issues.apache.org/jira/browse/GEODE-9657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-9657:
Labels: Java17 (was: )
> Javadoc errors occur on Java 17 due to split packages in Geode
> --
>
> Key: GEODE-9657
> URL: https://issues.apache.org/jira/browse/GEODE-9657
> Project: Geode
> Issue Type: Sub-task
> Components: core
>Affects Versions: 1.13.4, 1.14.0
>Reporter: John Blum
>Priority: Major
> Labels: Java17
>
> When trying to build any library, framework (e.g. _Spring Data for Apache
> Geode_ (SDG)) or application with Apache Geode on Java 17, Javadoc errors
> occur.
> For example:
> {code}
> 22:36:52 [ERROR]
> /opt/jenkins/data/workspace/spring-data-geode_3.0.x/spring-data-geode/src/main/java/org/springframework/data/gemfire/function/PojoFunctionWrapper.java:53:
> error: cannot access Identifiable
> 22:36:52 [ERROR] public class PojoFunctionWrapper implements Function {
> 22:36:52 [ERROR]^
> 22:36:52 [ERROR] class file for org.apache.geode.lang.Identifiable not
> found
> {code}
> As it turns out, in Java 17, the _Javadoc_ tool now uses _Java_ modules.
> _Javadoc_ is started with:
> {code}
> javadoc … --add-modules ALL-MODULE-PATH --module-path --patch-module …
> {code}
> {{geode-core-1.14.0.jar}} ships
> {{org.apache.geode.lang.AttachAPINotFoundException}} and
> {{geode-common-1.14.0.jar}} ships {{org.apache.geode.lang.Identifiable}}. Due
> to this split-package arrangement, _Javadoc_ isn’t discovering
> {{Identifiable}} because it has found the package {{org.apache.geode.lang}}
> in {{geode-core-1.14.0.jar}}.
> The best course of action is to make sure all {{org.apache.geode.lang}}
> sub-packages and class are in 1 JAR (e.g. {{geode-common}}) or the other
> (i.e. {{geode-core}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10035) The System property condition to use "direct" ByteBuffers in P2P is wrong
[
https://issues.apache.org/jira/browse/GEODE-10035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider reassigned GEODE-10035:
Assignee: Darrel Schneider
> The System property condition to use "direct" ByteBuffers in P2P is wrong
> -
>
> Key: GEODE-10035
> URL: https://issues.apache.org/jira/browse/GEODE-10035
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.3
>Reporter: John Blum
>Assignee: Darrel Schneider
>Priority: Minor
>
> In the {{o.a.g.internal.net.ByteBuffer.useDirectBuffers}} class member
> (static) constant field
> ([source|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L82-L83]),
> which is derived from either the "{{p2p.nodirectBuffers"}} OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties, the conditional
> logic is incorrect!
> It should read (formatted to make it more readable):
> {code:java}
> public static final boolean useDirectBuffers = !(
> Boolean.getBoolean("p2p.nodirectBuffers")
> ||
> Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers")
> );
> {code}
> Alternatively:
> {code:java}
> public static final boolean useDirectBuffers =
> !Boolean.getBoolean("p2p.nodirectBuffers")
> &&
> !Boolean.getBoolean(GeodeGlossary.GEMFIRE_PREFIX+"BufferPool.useHeapBuffers");
> {code}
> That is, if either the "{{p2p.nodirectBuffers}}" OR the
> "{{gemfire.BufferPool.useHeapBuffers}}" System properties are {{true}}, then
> DO NOT USE direct ByteBuffers.
> The term "{{useHeapBuffers}}" implies that the buffer should be created on
> the JVM Heap, and not in main memory as a "direct" ByteBuffer.
> Setting the System property "{{gemfire.BufferPool.useHeapBuffers}}" to
> "{{true}}" would result in a direct ByteBuffer allocation as can be seen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L104-L115],
>
> rather than what should happen
> [here|https://github.com/apache/geode/blob/rel/v1.14.3/geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java#L117].
> As the condition currently stands, if the "{{p2p.nodirectBuffers}}" System
> property is not set at all (which results in {{Boolean.getBoolean(..)}}
> returning {{false}}), which negated results in the OR'd condition not even
> being evaluated!
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10036) Joining Locators in a cluster is not possible on Java 17
[
https://issues.apache.org/jira/browse/GEODE-10036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-10036:
-
Labels: Java17 jdk17 (was: jdk17)
> Joining Locators in a cluster is not possible on Java 17
>
>
> Key: GEODE-10036
> URL: https://issues.apache.org/jira/browse/GEODE-10036
> Project: Geode
> Issue Type: Sub-task
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Critical
> Labels: Java17, jdk17
>
> When trying to add multiple _Locators_ to the same cluster, particularly when
> "_direct_" {{ByteBuffers}} are used, the following Exception is thrown:
> {code:java}
> Caused by: org.apache.geode.SystemConnectException: One or more peers
> generated exceptions during connection attempt
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1634)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at
> org.springframework.data.gemfire.LocatorFactoryBean.init(LocatorFactoryBean.java:120)
> ... 44 more
> Caused by: 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:101)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:258)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:318)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:525)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2064)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1991)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:75)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1631)
> ... 56 more
> 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 @2e0fa5d3
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> 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)
> ... 69 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9981) use more portable approach to getting crypto algorithm oid
[
https://issues.apache.org/jira/browse/GEODE-9981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-9981:
Labels: Java17 pull-request-available (was: pull-request-available)
> use more portable approach to getting crypto algorithm oid
> --
>
> Key: GEODE-9981
> URL: https://issues.apache.org/jira/browse/GEODE-9981
> Project: Geode
> Issue Type: Sub-task
>Reporter: Owen Nichols
>Priority: Major
> Labels: Java17, pull-request-available
> Fix For: 1.15.0
>
>
> instead of:
> `new AlgorithmId(AlgorithmId.md5WithRSAEncryption_oid)`
> this works with more jdk versions:
> AlgorithmId.get("MD5withRSA");
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-10165) DatagramSocket can throw SocketException instead of IOException when operation not permitted on JDK17
[
https://issues.apache.org/jira/browse/GEODE-10165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-10165.
--
Fix Version/s: 1.15.0
Resolution: Fixed
> DatagramSocket can throw SocketException instead of IOException when
> operation not permitted on JDK17
> -
>
> Key: GEODE-10165
> URL: https://issues.apache.org/jira/browse/GEODE-10165
> Project: Geode
> Issue Type: Improvement
> Components: membership
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java17, pull-request-available
> Fix For: 1.15.0
>
>
> On JDK 17, a DatagramSocket can throw `SocketException` for "Operation not
> permitted". In the same situation where on JDK11 it would throw `IOException`.
>
> `Transport.doSend()` logs a `SocketException` as an error. It delegates
> handling the `IOException` to its messenger, which logs it as a warning.
> So the exception is logged as an error on JDK17, where on JDK11 it would be
> logged as a warning.
>
> Example failure in CI:
> - Failure in CI (PR precheckin):
> https://concourse.apachegeode-ci.info/builds/39064786
> - Test results:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7475/test-results/distributedTest/1648074003/
> - Test run artifacts:
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7475/test-artifacts/1648074003/distributedtestfiles-geode-pr-7475.tgz
> Example stack trace on JDK17:
> {noformat}
> [vm5] [error 2022/03/23 20:00:06.635 UTC heavy-lifter-1c2c92cd-65e8-5d6a-a2fd-52d05cdafe97(45303):47672>
> tid=0x40d] Exception caught while sending message
> [vm5] java.net.SocketException: Operation not permitted
> [vm5] at java.base/sun.nio.ch.DatagramChannelImpl.send0(Native Method)
> [vm5] at
> java.base/sun.nio.ch.DatagramChannelImpl.sendFromNativeBuffer(DatagramChannelImpl.java:901)
> [vm5] at
> java.base/sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:863)
> [vm5] at
> java.base/sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:821)
> [vm5] at
> java.base/sun.nio.ch.DatagramChannelImpl.blockingSend(DatagramChannelImpl.java:853)
> [vm5] at
> java.base/sun.nio.ch.DatagramSocketAdaptor.send(DatagramSocketAdaptor.java:218)
> [vm5] at java.base/java.net.DatagramSocket.send(DatagramSocket.java:664)
> [vm5] at org.jgroups.protocols.UDP._send(UDP.java:224)
> [vm5] at org.jgroups.protocols.UDP.sendUnicast(UDP.java:215)
> [vm5] at org.jgroups.protocols.TP.sendToSingleMember(TP.java:1985)
> [vm5] at org.jgroups.protocols.TP.doSend(TP.java:1962)
> [vm5] at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport.doSend(Transport.java:85)
> [vm5] at org.jgroups.protocols.TP.send(TP.java:1948)
> [vm5] at
> org.apache.geode.distributed.internal.membership.gms.messenger.Transport._send(Transport.java:57)
> [vm5] at org.jgroups.protocols.TP.down(TP.java:1515)
> [vm5] at org.jgroups.stack.Protocol.down(Protocol.java:439)
> [vm5] at
> org.apache.geode.distributed.internal.membership.gms.messenger.StatRecorder.down(StatRecorder.java:87)
> [vm5] at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:646)
> [vm5] at org.jgroups.protocols.FlowControl.down(FlowControl.java:347)
> [vm5] at org.jgroups.protocols.FRAG2.down(FRAG2.java:136)
> [vm5] at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1039)
> [vm5] at org.jgroups.JChannel.down(JChannel.java:790)
> [vm5] at org.jgroups.JChannel.send(JChannel.java:426)
> [vm5] at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.send(JGroupsMessenger.java:838)
> [vm5] at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.send(JGroupsMessenger.java:681)
> [vm5] at
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.send(GMSMembership.java:1335)
> [vm5] at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> [vm5] at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2067)
> [vm5] at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendShutdownMessage(ClusterDistributionManager.java:1965)
> [vm5] at
> org.apache.geode.distributed.internal.ClusterDistributionManager.lambda$shutdown$2(ClusterDistributionManager.java:1134)
> [vm5] at java.base/java.lang.Thread.run(Thread.java:833)
> {noformat}
>
> Example stack trace on JDK11:
> {noformat}
> [vm7] [warn 2022/03/24 23:40:50.949 UTC dale-dunit(51430):52674> tid=0x2d5] Unable to send message to
> dale-dunit(50205):52673
> [vm7] java.io.IOException: Operation not permitted
> [vm7] at
[jira] [Commented] (GEODE-10206) Geode assumes CMS garbage collector, which JDK 17 lacks
[ https://issues.apache.org/jira/browse/GEODE-10206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17521899#comment-17521899 ] Darrel Schneider commented on GEODE-10206: -- Note that the --max-heap using CMS has been fixed in: https://issues.apache.org/jira/browse/GEODE-10235 > Geode assumes CMS garbage collector, which JDK 17 lacks > --- > > Key: GEODE-10206 > URL: https://issues.apache.org/jira/browse/GEODE-10206 > Project: Geode > Issue Type: Improvement > Components: core, docs, gfsh >Affects Versions: 1.15.0 >Reporter: Dale Emery >Priority: Major > Labels: Java17 > > Several places in Geode code and documentation assume that Concurrent Mark > Sweet (CMS) garbage collector exists, and that these VM arguments are > meaningful: > - -XX:+UseConcMarkSweepGC > - -XX:CMSInitiatingOccupancyFraction > The CMS garbage collector is not available on JDK 17. JDK 17 warns that it > does not recognize these arguments. > These production classes rely on CMS args at runtime: > - extensions/geode-modules: ResourceManagerValidator.validateSunArguments() > recommends configuring the CMS args. > - geode-gfsh: StartMemberUtils passes the CMS args when max heap is set. > These test classes use the CMS args at runtime: > - geode-for-redis: OutOfMemoryDUnitTest passes a > CMSInitiatingOccupancyFraction arg when starting a server. > User-facing Javadoc comments on these classes refer to the CMS args: > - geode-core: EvictionAttributes > - geode-core: ResourceManager > Code comments in these classes refer to the CMS args: > - geode-modules: AbstractCache > These properties files in geode-modules-assembly define or refer to the CMS > args: > - scripts/setenv.properties > - tcserver/geode-cs/configuration-prompts.properties > - tcserver/geode-p2p/configuration-prompts.properties > These documentation files in geode-docs refer to the CMS args: > - configuring/running/running_the_cacheserver.html.md.erb > - managing/heap_use/heap_management.html.md.erb > - managing/monitor_tune/system_member_performance_garbage.html.md.erb -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10235) deployLargeSetOfJars fails with jdk 17
[
https://issues.apache.org/jira/browse/GEODE-10235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-10235.
--
Fix Version/s: 1.15.0
Resolution: Fixed
> deployLargeSetOfJars fails with jdk 17
> --
>
> Key: GEODE-10235
> URL: https://issues.apache.org/jira/browse/GEODE-10235
> Project: Geode
> Issue Type: Improvement
> Components: core
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java17, pull-request-available
> Fix For: 1.15.0
>
>
> The failure is caused by "--max-heap" not working with jdk 17.
> {noformat}
> DeployWithLargeJarTest > deployLargeSetOfJars FAILED
> org.opentest4j.AssertionFailedError: [Exit value from process started by
> [7a912a18dd64e4c9: gfsh -e start locator --name=locator --max-heap=128m -e
> start server --name=server --max-heap=128m --server-port=0 -e sleep --time=1
> -e deploy
> --jars=/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-digester-2.1.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-collections-3.2.2.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-logging-1.2.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-codec-1.15.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-beanutils-1.9.4.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-lang3-3.12.0.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-validator-1.7.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-modeler-2.0.1.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-io-2.11.0.jar]]
>
> expected: 0
> but was: 1
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:163)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:153)
> at
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest.deployLargeSetOfJars(DeployWithLargeJarTest.java:41)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10235) deployLargeSetOfJars fails with jdk 17
[
https://issues.apache.org/jira/browse/GEODE-10235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider reassigned GEODE-10235:
Assignee: Darrel Schneider
> deployLargeSetOfJars fails with jdk 17
> --
>
> Key: GEODE-10235
> URL: https://issues.apache.org/jira/browse/GEODE-10235
> Project: Geode
> Issue Type: Improvement
> Components: core
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java17
>
> The failure is caused by "--max-heap" not working with jdk 17.
> {noformat}
> DeployWithLargeJarTest > deployLargeSetOfJars FAILED
> org.opentest4j.AssertionFailedError: [Exit value from process started by
> [7a912a18dd64e4c9: gfsh -e start locator --name=locator --max-heap=128m -e
> start server --name=server --max-heap=128m --server-port=0 -e sleep --time=1
> -e deploy
> --jars=/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-digester-2.1.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-collections-3.2.2.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-logging-1.2.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-codec-1.15.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-beanutils-1.9.4.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-lang3-3.12.0.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-validator-1.7.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-modeler-2.0.1.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-io-2.11.0.jar]]
>
> expected: 0
> but was: 1
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:163)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:153)
> at
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest.deployLargeSetOfJars(DeployWithLargeJarTest.java:41)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10235) deployLargeSetOfJars fails with jdk 17
[
https://issues.apache.org/jira/browse/GEODE-10235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-10235:
-
Labels: Java17 (was: jdk17)
> deployLargeSetOfJars fails with jdk 17
> --
>
> Key: GEODE-10235
> URL: https://issues.apache.org/jira/browse/GEODE-10235
> Project: Geode
> Issue Type: Improvement
> Components: core
>Reporter: Darrel Schneider
>Priority: Major
> Labels: Java17
>
> The failure is caused by "--max-heap" not working with jdk 17.
> {noformat}
> DeployWithLargeJarTest > deployLargeSetOfJars FAILED
> org.opentest4j.AssertionFailedError: [Exit value from process started by
> [7a912a18dd64e4c9: gfsh -e start locator --name=locator --max-heap=128m -e
> start server --name=server --max-heap=128m --server-port=0 -e sleep --time=1
> -e deploy
> --jars=/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-digester-2.1.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-collections-3.2.2.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-logging-1.2.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-codec-1.15.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-beanutils-1.9.4.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-lang3-3.12.0.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-validator-1.7.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-modeler-2.0.1.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-io-2.11.0.jar]]
>
> expected: 0
> but was: 1
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:163)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:153)
> at
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest.deployLargeSetOfJars(DeployWithLargeJarTest.java:41)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10235) deployLargeSetOfJars fails with jdk 17
[
https://issues.apache.org/jira/browse/GEODE-10235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-10235:
-
Labels: jdk17 (was: )
> deployLargeSetOfJars fails with jdk 17
> --
>
> Key: GEODE-10235
> URL: https://issues.apache.org/jira/browse/GEODE-10235
> Project: Geode
> Issue Type: Improvement
> Components: core
>Reporter: Darrel Schneider
>Priority: Major
> Labels: jdk17
>
> The failure is caused by "--max-heap" not working with jdk 17.
> {noformat}
> DeployWithLargeJarTest > deployLargeSetOfJars FAILED
> org.opentest4j.AssertionFailedError: [Exit value from process started by
> [7a912a18dd64e4c9: gfsh -e start locator --name=locator --max-heap=128m -e
> start server --name=server --max-heap=128m --server-port=0 -e sleep --time=1
> -e deploy
> --jars=/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-digester-2.1.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-collections-3.2.2.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-logging-1.2.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-codec-1.15.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-beanutils-1.9.4.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-lang3-3.12.0.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-validator-1.7.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-modeler-2.0.1.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-io-2.11.0.jar]]
>
> expected: 0
> but was: 1
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:163)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:153)
> at
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest.deployLargeSetOfJars(DeployWithLargeJarTest.java:41)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10235) deployLargeSetOfJars fails with jdk 17
Darrel Schneider created GEODE-10235:
Summary: deployLargeSetOfJars fails with jdk 17
Key: GEODE-10235
URL: https://issues.apache.org/jira/browse/GEODE-10235
Project: Geode
Issue Type: Improvement
Components: core
Reporter: Darrel Schneider
The failure is caused by "--max-heap" not working with jdk 17.
{noformat}
DeployWithLargeJarTest > deployLargeSetOfJars FAILED
org.opentest4j.AssertionFailedError: [Exit value from process started by
[7a912a18dd64e4c9: gfsh -e start locator --name=locator --max-heap=128m -e
start server --name=server --max-heap=128m --server-port=0 -e sleep --time=1 -e
deploy
--jars=/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-digester-2.1.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-collections-3.2.2.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-logging-1.2.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-codec-1.15.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-beanutils-1.9.4.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-lang3-3.12.0.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-validator-1.7.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-modeler-2.0.1.jar,/home/geode/geode/geode-assembly/build/install/apache-geode/lib/commons-io-2.11.0.jar]]
expected: 0
but was: 1
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
at
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at
java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
at
org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
at
org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:154)
at
org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:163)
at
org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:153)
at
org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest.deployLargeSetOfJars(DeployWithLargeJarTest.java:41)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-10141) GMSJoinLeaveJUnitTest is overly specific about the expected exception message
[ https://issues.apache.org/jira/browse/GEODE-10141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-10141. -- Fix Version/s: 1.15.0 Resolution: Fixed > GMSJoinLeaveJUnitTest is overly specific about the expected exception message > - > > Key: GEODE-10141 > URL: https://issues.apache.org/jira/browse/GEODE-10141 > Project: Geode > Issue Type: Improvement > Components: membership, tests >Affects Versions: 1.15.0 >Reporter: Dale Emery >Assignee: Darrel Schneider >Priority: Major > Labels: Java17, pull-request-available > Fix For: 1.15.0 > > > `GMSJoinLeave` throws the correct exception type, with a message correctly > describing its inability to connect to the locators at the specified > unresolved addresses. But the test's assertion is overly specific about the > description of an unresolved address, and fails on JDK 17. > In JDKs up through 13, `toString()` of an unresolved `InetSocketAddress` > returned `"hostname:port"`. Starting with JDK 14 it returns > `"hostname/:port"`. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (GEODE-10196) HashesAndCrashesDUnitTest fails to ignore expected exceptions on JDK 17
[
https://issues.apache.org/jira/browse/GEODE-10196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-10196.
--
Fix Version/s: 1.15.0
Resolution: Fixed
> HashesAndCrashesDUnitTest fails to ignore expected exceptions on JDK 17
> ---
>
> Key: GEODE-10196
> URL: https://issues.apache.org/jira/browse/GEODE-10196
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Dale Emery
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java17, pull-request-available
> Fix For: 1.15.0
>
>
> The {{HashesAndCrashesDUnitTest.executeUntilSuccess()}} method (called by all
> of the test in the class) expects exceptions with the message "Connection
> reset by peer", logs them, and retries the operation.
>
> The source of the exception is {{{}SocketChannel.read(){}}}. On JDK 17, the
> exception message is "Connection reset". This is not the expected message,
> and so {{executeUntilSuccess()}} rethrows it instead of ignoring it, causing
> the test to fail.
>
> Incidentally, the type of the exception on JDK 17 {{{}SocketException{}}},
> but on JDK 8 and 11 is {{{}IOException{}}}. This does not affect the test,
> which inspects only the exception message, not the type.
>
> On JDK 17, the stack trace of the exception is:
> {noformat}
> io.lettuce.core.RedisException: java.net.SocketException: Connection reset
> at io.lettuce.core.internal.Exceptions.bubble(Exceptions.java:83)
> at io.lettuce.core.internal.Futures.awaitOrCancel(Futures.java:250)
> at
> io.lettuce.core.cluster.ClusterFutureSyncInvocationHandler.handleInvocation(ClusterFutureSyncInvocationHandler.java:130)
> at
> io.lettuce.core.internal.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:80)
> at jdk.proxy3/jdk.proxy3.$Proxy53.set(Unknown Source)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$setPerformAndVerify$14(HashesAndCrashesDUnitTest.java:257)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.executeUntilSuccess(HashesAndCrashesDUnitTest.java:274)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.setPerformAndVerify(HashesAndCrashesDUnitTest.java:257)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$modifyDataWhileCrashingVMs$11(HashesAndCrashesDUnitTest.java:161)
> at
> java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.net.SocketException: Connection reset
> at
> java.base/sun.nio.ch.SocketChannelImpl.throwConnectionReset(SocketChannelImpl.java:394)
> at java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:426)
> at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:258)
> at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1132)
> at
> io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:151)
> at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:722)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:658)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:584)
> at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496)
> at
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
> at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
> at
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
> ... 1 more
> {noformat}
>
> On JDK 11, the stack trace of the exception is:
> {noformat}
> io.lettuce.core.RedisException: java.io.IOException: Connection reset by peer
> at io.lettuce.core.internal.Exceptions.bubble(Exceptions.java:83)
> at io.lettuce.core.internal.Futures.awaitOrCancel(Futures.java:250)
> at
> io.lettuce.core.cluster.ClusterFutureSyncInvocationHandler.handleInvocation(ClusterFutureSyncInvocationHandler.java:130)
> at
> io.lettuce.core.internal.AbstractInvocationHandler.invoke(AbstractInvocationHandler.java:80)
> at com.sun.proxy.$Proxy52.set(Unknown Source)
> at
> org.apache.geode.redis.internal.commands.executor.hash.HashesAndCrashesDUnitTest.lambda$setPerformAndVerify$14(HashesAndCrashesDUnitTest.java:257)
> at
>
