[jira] [Created] (GEODE-9465) Add radish test using redisson library
Jens Deppe created GEODE-9465: - Summary: Add radish test using redisson library Key: GEODE-9465 URL: https://issues.apache.org/jira/browse/GEODE-9465 Project: Geode Issue Type: Test Components: redis Reporter: Jens Deppe We should have a test that uses the redisson (https://github.com/redisson/redisson) library to connect to a cluster. Ensure that bucket movements are handled correctly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9462) Dump call stacks from both Dockerized and non-Dockerized java processes
[
https://issues.apache.org/jira/browse/GEODE-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-9462:
--
Labels: GeodeOperationAPI pull-request-available (was: GeodeOperationAPI)
> Dump call stacks from both Dockerized and non-Dockerized java processes
> ---
>
> Key: GEODE-9462
> URL: https://issues.apache.org/jira/browse/GEODE-9462
> Project: Geode
> Issue Type: Improvement
> Components: build
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Currently, {{ci/scripts/capture-call-stacks.sh}} assumes that if
> {{PARALLEL_DUNIT}} is empty, tests were run in plain Java processes, and if
> it is non-empty, tests were run in Docker containers.
> GEODE-8728 violates that assumption: It runs parallel tests in plain Java
> processes, without Docker containers.
> Currently, the script looks in different places for Java processes, depending
> on whether {{PARALLEL_DUNIT}} is empty. If it is empty, the script dumps
> stacks from plain Java processes on the machine, and only those processes. If
> it is non-empty, the script dumps stacks from Java processes running inside
> Docker containers, and only those processes.
> This will not work in builds that include GEODE-8728.
> To allow the script to work both for newer builds that include GEODE-8728 and
> older builds that do not, change it to dump call stacks from both places,
> regardless of whether `PARALLEL_DUNIT` is empty. If `jps` reports any
> processes, dump their stacks. And if `docker ps` reports any containers, dump
> the stacks of the Java processes in each container.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9462) Dump call stacks from both Dockerized and non-Dockerized java processes
[
https://issues.apache.org/jira/browse/GEODE-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17388162#comment-17388162
]
ASF subversion and git services commented on GEODE-9462:
Commit 0fd6201c6295a536205754ae538dffe765e164da in geode's branch
refs/heads/develop from Dale Emery
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0fd6201 ]
GEODE-9462: Capture call stacks from all sources (#6723)
Change `ci/scripts/capture-call-stacks.sh` to capture call stacks from
both Dockerized and non-Dockerized Java processes, regardless of the
value of `PARALLEL_DUNIT`.
If `jps` reports any processes, capture their call stacks. If `docker
ps` reports any Docker containers, capture the call stacks of all Java
processes running in those containers.
This ensures that we capture all call stacks from all lingering Java
test worker processes, regardless of whether the workers were run in
Docker containers.
Co-authored-by: Dale Emery
> Dump call stacks from both Dockerized and non-Dockerized java processes
> ---
>
> Key: GEODE-9462
> URL: https://issues.apache.org/jira/browse/GEODE-9462
> Project: Geode
> Issue Type: Improvement
> Components: build
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
> Labels: GeodeOperationAPI, pull-request-available
>
> Currently, {{ci/scripts/capture-call-stacks.sh}} assumes that if
> {{PARALLEL_DUNIT}} is empty, tests were run in plain Java processes, and if
> it is non-empty, tests were run in Docker containers.
> GEODE-8728 violates that assumption: It runs parallel tests in plain Java
> processes, without Docker containers.
> Currently, the script looks in different places for Java processes, depending
> on whether {{PARALLEL_DUNIT}} is empty. If it is empty, the script dumps
> stacks from plain Java processes on the machine, and only those processes. If
> it is non-empty, the script dumps stacks from Java processes running inside
> Docker containers, and only those processes.
> This will not work in builds that include GEODE-8728.
> To allow the script to work both for newer builds that include GEODE-8728 and
> older builds that do not, change it to dump call stacks from both places,
> regardless of whether `PARALLEL_DUNIT` is empty. If `jps` reports any
> processes, dump their stacks. And if `docker ps` reports any containers, dump
> the stacks of the Java processes in each container.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9466) ByteBufferInputStream slower on Java 9 and later
Darrel Schneider created GEODE-9466:
---
Summary: ByteBufferInputStream slower on Java 9 and later
Key: GEODE-9466
URL: https://issues.apache.org/jira/browse/GEODE-9466
Project: Geode
Issue Type: Improvement
Components: core
Reporter: Darrel Schneider
ByteBufferInputStream has a method determineUnaligned that will always return
false on java 9 and later. This is because it calls Method.setAccessible which
is not allowed under normal conditions starting with java 9 (see:
[https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m).|https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m]
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 in its exception catch block to
read the "os.arch" system property and if it is any of the following to return
true:
arch.equals("i386") || arch.equals("x86")
|| arch.equals("amd64") || arch.equals("x86_64")
|| arch.equals("ppc64") || arch.equals("ppc64le")
This is what the Bits class does. It might be worth checking a more recent jdk
to see if the list of os.arch that support unaligned reads has grown.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9412) App crashes when translating string with certain Unicode characters (exception thrown across managed/native boundary)
[ https://issues.apache.org/jira/browse/GEODE-9412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17388206#comment-17388206 ] ASF subversion and git services commented on GEODE-9412: Commit 8a7436443629381b6be6142b6d2abf7187813309 in geode-native's branch refs/heads/develop from Blake Bender [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=8a74364 ] GEODE-9412: Fix up marshaling of (potential) Unicode strings, where (#833) applicable - region names can be Unicode, cacheable keys/values, etc. Most of the rest don't need this, because they're never Unicode. Co-authored-by: Matthew Reddington > App crashes when translating string with certain Unicode characters > (exception thrown across managed/native boundary) > - > > Key: GEODE-9412 > URL: https://issues.apache.org/jira/browse/GEODE-9412 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: pull-request-available > > tl;dr, we're not translating unicode correctly between .net and C++. > When a unicode string comes into the CLI layer, we use > `marshal_as` to translate, then assume this yields UTF-8. In > fact, what it yields is a string encoded in a) whatever the local code page > is for the system, or b) the default code page for the app, if one exists in > the manifest. In the C++ layer, we then assume the string is UTF-8, and for > a PUT, attempt to translate into Java-modified UTF-8, which ends up throwing > an uncaught exception when it encounters a character that is not a valid > UTF-8 start code. When this exception hits the native/managed boundary, the > app crashes. > To avoid this issue, we need to `marshal_as`, then use `std` > conversion functions to arrive at UTF-8, and pass that down to the C++ layer. > We also need to use the reverse process when sending strings back up to CLI. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9412) App crashes when translating string with certain Unicode characters (exception thrown across managed/native boundary)
[ https://issues.apache.org/jira/browse/GEODE-9412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17388207#comment-17388207 ] ASF GitHub Bot commented on GEODE-9412: --- pdxcodemonkey merged pull request #833: URL: https://github.com/apache/geode-native/pull/833 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > App crashes when translating string with certain Unicode characters > (exception thrown across managed/native boundary) > - > > Key: GEODE-9412 > URL: https://issues.apache.org/jira/browse/GEODE-9412 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: pull-request-available > > tl;dr, we're not translating unicode correctly between .net and C++. > When a unicode string comes into the CLI layer, we use > `marshal_as` to translate, then assume this yields UTF-8. In > fact, what it yields is a string encoded in a) whatever the local code page > is for the system, or b) the default code page for the app, if one exists in > the manifest. In the C++ layer, we then assume the string is UTF-8, and for > a PUT, attempt to translate into Java-modified UTF-8, which ends up throwing > an uncaught exception when it encounters a character that is not a valid > UTF-8 start code. When this exception hits the native/managed boundary, the > app crashes. > To avoid this issue, we need to `marshal_as`, then use `std` > conversion functions to arrive at UTF-8, and pass that down to the C++ layer. > We also need to use the reverse process when sending strings back up to CLI. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9393) Apache Geode does not run on Java 16
[
https://issues.apache.org/jira/browse/GEODE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-9393:
Labels: Java16 (was: )
> Apache Geode does not run on Java 16
>
>
> Key: GEODE-9393
> URL: https://issues.apache.org/jira/browse/GEODE-9393
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.13.2
>Reporter: John Blum
>Priority: Blocker
> Labels: Java16
>
> Due to Java 16 tightened restrictions, Apache Geode fails to run on a Java 16
> Runtime (JRE).
> Exceptions like the following are thrown:
> {code}
> - org.apache.geode.InternalGemFireException: unable to retrieve underlying
> byte buffer
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> - at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> - at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> - at org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:100)
> - at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:256)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:306)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:511)
> - at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> - at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2050)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1978)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2015)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> - at
> org.apache.geode.distributed.internal.StartupMessage.process(StartupMessage.java:279)
> - at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> - at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:441)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doWaitingThread(ClusterOperationExecutors.java:410)
> - at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> - at java.base/java.lang.Thread.run(Thread.java:831)
> - Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @40f9161a
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> - at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> - at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
> - ... 22 common frames omitted
> - 2021-04-30 14:57:13,638 INFO ributed.internal.membership.gms.Services: 606
> - received leave request from
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> for
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> - 2021-04-30 14:57:13,640 INFO ributed.internal.membership.gms.Services: 617
> - JoinLeave.processMessage(LeaveRequestMessage) invoked. isCoordinator=true;
> isStopping=false; cancelInProgress=false
> - 2021-04-30 14:57:13,647 ERROR xecutors.LoggingUncaughtExceptionHandler: 92
> - Uncaught exception in thread Thread[P2P message reader for
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> shared unordered uid=1 local port=53039 remote port=64063,10,main]
> - org.apache.geode.InternalGemFireException: unable to retrieve underlying
> byte buffer
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> - at
> org.
[jira] [Updated] (GEODE-9466) ByteBufferInputStream slower on Java 9 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 (was: )
> ByteBufferInputStream slower on Java 9 and later
>
>
> Key: GEODE-9466
> URL: https://issues.apache.org/jira/browse/GEODE-9466
> Project: Geode
> Issue Type: Improvement
> Components: core
>Reporter: Darrel Schneider
>Priority: Major
> Labels: Java16
>
> ByteBufferInputStream has a method determineUnaligned that will always return
> false on java 9 and later. This is because it calls Method.setAccessible
> which is not allowed under normal conditions starting with java 9 (see:
> [https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m).|https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m]
> 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 in its exception catch block
> to read the "os.arch" system property and if it is any of the following to
> return true:
> arch.equals("i386") || arch.equals("x86")
> || arch.equals("amd64") || arch.equals("x86_64")
> || arch.equals("ppc64") || arch.equals("ppc64le")
> This is what the Bits class does. It might be worth checking a more recent
> jdk to see if the list of os.arch that support unaligned reads has grown.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9466) ByteBufferInputStream slower on Java 9 and later
[
https://issues.apache.org/jira/browse/GEODE-9466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-9466:
Description:
ByteBufferInputStream has a method determineUnaligned that will always return
false on java 9 and later. This is because it calls Method.setAccessible which
is not allowed under normal conditions starting with java 9 (see:
[https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m).|https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m]
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 in its exception catch block 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 it this logic has moved to
UnsafeConstants and its value is injected by the JVM so it is unclear if the
list has grown.
was:
ByteBufferInputStream has a method determineUnaligned that will always return
false on java 9 and later. This is because it calls Method.setAccessible which
is not allowed under normal conditions starting with java 9 (see:
[https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m).|https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m]
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 in its exception catch block to
read the "os.arch" system property and if it is any of the following to return
true:
arch.equals("i386") || arch.equals("x86")
|| arch.equals("amd64") || arch.equals("x86_64")
|| arch.equals("ppc64") || arch.equals("ppc64le")
This is what the Bits class does. It might be worth checking a more recent jdk
to see if the list of os.arch that support unaligned reads has grown.
> ByteBufferInputStream slower on Java 9 and later
>
>
> Key: GEODE-9466
> URL: https://issues.apache.org/jira/browse/GEODE-9466
> Project: Geode
> Issue Type: Improvement
> Components: core
>Reporter: Darrel Schneider
>Priority: Major
> Labels: Java16
>
> ByteBufferInputStream has a method determineUnaligned that will always return
> false on java 9 and later. This is because it calls Method.setAccessible
> which is not allowed under normal conditions starting with java 9 (see:
> [https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m).|https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m]
> 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 in its exception catch block
> 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 it 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.3.4#803005)
[jira] [Updated] (GEODE-9467) pdx ReflectionBasedAutoSerializer will fail on java 9 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 (was: ) > pdx ReflectionBasedAutoSerializer will fail on java 9 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 > > The pdx ReflectionBasedAutoSerializer will not work on java 9 and later > because it calls Field.setAccessible which is not allowed under normal > conditions starting with java 9 (see: > [https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m).] > 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.3.4#803005)
[jira] [Created] (GEODE-9467) pdx ReflectionBasedAutoSerializer will fail on java 9 and later
Darrel Schneider created GEODE-9467: --- Summary: pdx ReflectionBasedAutoSerializer will fail on java 9 and later Key: GEODE-9467 URL: https://issues.apache.org/jira/browse/GEODE-9467 Project: Geode Issue Type: Bug Components: serialization Reporter: Darrel Schneider The pdx ReflectionBasedAutoSerializer will not work on java 9 and later because it calls Field.setAccessible which is not allowed under normal conditions starting with java 9 (see: [https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m).] 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.3.4#803005)
[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: Summary: pdx ReflectionBasedAutoSerializer will fail on java 16 and later (was: pdx ReflectionBasedAutoSerializer will fail on java 9 and later) > 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 > > The pdx ReflectionBasedAutoSerializer will not work on java 9 and later > because it calls Field.setAccessible which is not allowed under normal > conditions starting with java 9 (see: > [https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m).] > 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.3.4#803005)
[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: Description: 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://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m).] The call is made in org.apache.geode.pdx.internal.AutoSerializableManager#getClassInfo and is required for the auto serializer to function correctly. was: The pdx ReflectionBasedAutoSerializer will not work on java 9 and later because it calls Field.setAccessible which is not allowed under normal conditions starting with java 9 (see: [https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m).] The call is made in org.apache.geode.pdx.internal.AutoSerializableManager#getClassInfo and is required for the auto serializer to function correctly. > 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 > > 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://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m).] > 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.3.4#803005)
[jira] [Updated] (GEODE-9466) ByteBufferInputStream slower 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:
Summary: ByteBufferInputStream slower on Java 16 and later (was:
ByteBufferInputStream slower on Java 9 and later)
> ByteBufferInputStream slower on Java 16 and later
> -
>
> Key: GEODE-9466
> URL: https://issues.apache.org/jira/browse/GEODE-9466
> Project: Geode
> Issue Type: Improvement
> Components: core
>Reporter: Darrel Schneider
>Priority: Major
> Labels: Java16
>
> ByteBufferInputStream has a method determineUnaligned that will always return
> false on java 9 and later. This is because it calls Method.setAccessible
> which is not allowed under normal conditions starting with java 9 (see:
> [https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m).|https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m]
> 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 in its exception catch block
> 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 it 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.3.4#803005)
[jira] [Updated] (GEODE-9466) ByteBufferInputStream slower 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:
Description:
ByteBufferInputStream has a method determineUnaligned that will always return
false 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://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m).|https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m]
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 in its exception catch block 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 it this logic has moved to
UnsafeConstants and its value is injected by the JVM so it is unclear if the
list has grown.
was:
ByteBufferInputStream has a method determineUnaligned that will always return
false on java 9 and later. This is because it calls Method.setAccessible which
is not allowed under normal conditions starting with java 9 (see:
[https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m).|https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m]
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 in its exception catch block 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 it this logic has moved to
UnsafeConstants and its value is injected by the JVM so it is unclear if the
list has grown.
> ByteBufferInputStream slower on Java 16 and later
> -
>
> Key: GEODE-9466
> URL: https://issues.apache.org/jira/browse/GEODE-9466
> Project: Geode
> Issue Type: Improvement
> Components: core
>Reporter: Darrel Schneider
>Priority: Major
> Labels: Java16
>
> ByteBufferInputStream has a method determineUnaligned that will always return
> false 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://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m).|https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m]
> 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 in its exception catch block
> 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 it 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.3.4#803005)
[jira] [Comment Edited] (GEODE-9393) Apache Geode does not run on Java 16
[
https://issues.apache.org/jira/browse/GEODE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17387554#comment-17387554
]
Darrel Schneider edited comment on GEODE-9393 at 7/27/21, 7:54 PM:
---
It looks like all of the issues found so far involve geode making calls to
Field.setAccessible. It looks like Method.setAccessible would also be an issue.
For more info on why this started failing see:
[https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16/]
I've confirmed that setting the JVM option "--illegal-access=permit" causes
geode to not fail when setAccessible is called.
was (Author: dschneider):
It looks like all of the issues found so far involve geode making calls to
Field.setAccessible. It looks like Method.setAccessible would also be an issue.
For more info on why this started failing see:
[https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m]
> Apache Geode does not run on Java 16
>
>
> Key: GEODE-9393
> URL: https://issues.apache.org/jira/browse/GEODE-9393
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.13.2
>Reporter: John Blum
>Priority: Blocker
> Labels: Java16
>
> Due to Java 16 tightened restrictions, Apache Geode fails to run on a Java 16
> Runtime (JRE).
> Exceptions like the following are thrown:
> {code}
> - org.apache.geode.InternalGemFireException: unable to retrieve underlying
> byte buffer
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> - at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> - at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> - at org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:100)
> - at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:256)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:306)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:511)
> - at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> - at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2050)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1978)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2015)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> - at
> org.apache.geode.distributed.internal.StartupMessage.process(StartupMessage.java:279)
> - at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> - at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:441)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doWaitingThread(ClusterOperationExecutors.java:410)
> - at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> - at java.base/java.lang.Thread.run(Thread.java:831)
> - Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @40f9161a
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> - at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> - at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
> - ... 22 common frames omitted
> - 2021-04-30 14:57:13,638 INFO ributed.internal.membership.gms.Services: 606
> - received leave request from
> 10.99.1
[jira] [Commented] (GEODE-9393) Apache Geode does not run on Java 16
[
https://issues.apache.org/jira/browse/GEODE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17388272#comment-17388272
]
Darrel Schneider commented on GEODE-9393:
-
[~jblum] you said: Additionally, declaring the {{--add-opens}} JVM option does
not work with Java's {{Runtime}} API.
I'm not sure what that means. How serious of a limitation would not working
with Runtime API be? Is it also true for "--illegal-access=permit"? Do you have
any opinion on which is a better workaround (--add-opens vs.
--illegal-access=permit)? The danger with the --add-opens is that you might
keep finding modules you need to open. The --illegal-access=permit seems to
quickly get you back to java 15 behavior but might allow things you didn't
intend to.
> Apache Geode does not run on Java 16
>
>
> Key: GEODE-9393
> URL: https://issues.apache.org/jira/browse/GEODE-9393
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.13.2
>Reporter: John Blum
>Priority: Blocker
> Labels: Java16
>
> Due to Java 16 tightened restrictions, Apache Geode fails to run on a Java 16
> Runtime (JRE).
> Exceptions like the following are thrown:
> {code}
> - org.apache.geode.InternalGemFireException: unable to retrieve underlying
> byte buffer
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> - at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> - at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> - at org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:100)
> - at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:256)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:306)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:182)
> - at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:511)
> - at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:346)
> - at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:291)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2050)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1978)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2015)
> - at
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1083)
> - at
> org.apache.geode.distributed.internal.StartupMessage.process(StartupMessage.java:279)
> - at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> - at
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
> - at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:630)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:441)
> - at
> org.apache.geode.distributed.internal.ClusterOperationExecutors.doWaitingThread(ClusterOperationExecutors.java:410)
> - at
> org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
> - at java.base/java.lang.Thread.run(Thread.java:831)
> - Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @40f9161a
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
> - at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> - at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> - at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> - at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
> - ... 22 common frames omitted
> - 2021-04-30 14:57:13,638 INFO ributed.internal.membership.gms.Services: 606
> - received leave request from
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> for
> 10.99.199.28(CacheNotUsingSharedConfigurationIntegrationTest:29149):41001
> - 2021-04-30 14:57:13,640 INFO ributed.internal.membership.gms.Services: 617
> -
[jira] [Updated] (GEODE-9466) ByteBufferInputStream slower 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:
Description:
ByteBufferInputStream has a method determineUnaligned that will always return
false 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/[).|https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m]
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 in its exception catch block 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.
was:
ByteBufferInputStream has a method determineUnaligned that will always return
false 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://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m).|https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m]
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 in its exception catch block 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 it this logic has moved to
UnsafeConstants and its value is injected by the JVM so it is unclear if the
list has grown.
> ByteBufferInputStream slower on Java 16 and later
> -
>
> Key: GEODE-9466
> URL: https://issues.apache.org/jira/browse/GEODE-9466
> Project: Geode
> Issue Type: Improvement
> Components: core
>Reporter: Darrel Schneider
>Priority: Major
> Labels: Java16
>
> ByteBufferInputStream has a method determineUnaligned that will always return
> false 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/[).|https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m]
> 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 in its exception catch block
> 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.3.4#803005)
[jira] [Created] (GEODE-9468) tomcat session state management will not work on java 16
Darrel Schneider created GEODE-9468: --- Summary: 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 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.3.4#803005)
[jira] [Updated] (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 updated GEODE-9468: Labels: Java16 (was: ) > 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.3.4#803005)
[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&focusedCommentId=17388307#comment-17388307 ] Darrel Schneider commented on GEODE-9468: - The tomcat 7, 8, and 9 source code we bundle also has a call to setAccessible in org.apache.geode.modules.session.catalina.Tomcat9CommitSessionValve so even if we fix DeltaSession ifTomcat9CommitSessionValve is used it will also fail on java 16. > 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.3.4#803005)
[jira] [Updated] (GEODE-9466) ByteBufferInputStream slower 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:
Description:
ByteBufferInputStream 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|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.
was:
ByteBufferInputStream has a method determineUnaligned that will always return
false 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/[).|https://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m]
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 in its exception catch block 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.
> ByteBufferInputStream slower on Java 16 and later
> -
>
> Key: GEODE-9466
> URL: https://issues.apache.org/jira/browse/GEODE-9466
> Project: Geode
> Issue Type: Improvement
> Components: core
>Reporter: Darrel Schneider
>Priority: Major
> Labels: Java16
>
> ByteBufferInputStream 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|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.3.4#803005)
[jira] [Updated] (GEODE-9466) ByteBufferInputStream slower 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:
Issue Type: Bug (was: Improvement)
> ByteBufferInputStream slower on Java 16 and later
> -
>
> Key: GEODE-9466
> URL: https://issues.apache.org/jira/browse/GEODE-9466
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Darrel Schneider
>Priority: Major
> Labels: Java16
>
> ByteBufferInputStream 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|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.3.4#803005)
[jira] [Updated] (GEODE-9466) ByteBufferInputStream 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:
Summary: ByteBufferInputStream fails on Java 16 and later (was:
ByteBufferInputStream slower on Java 16 and later)
> ByteBufferInputStream fails on Java 16 and later
>
>
> Key: GEODE-9466
> URL: https://issues.apache.org/jira/browse/GEODE-9466
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Darrel Schneider
>Priority: Major
> Labels: Java16
>
> ByteBufferInputStream 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|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.3.4#803005)
[jira] [Updated] (GEODE-9466) ByteBufferInputStream 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:
Description:
ByteBufferInputStream 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:).
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.
was:
ByteBufferInputStream 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|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.
> ByteBufferInputStream fails on Java 16 and later
>
>
> Key: GEODE-9466
> URL: https://issues.apache.org/jira/browse/GEODE-9466
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Darrel Schneider
>Priority: Major
> Labels: Java16
>
> ByteBufferInputStream 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:).
> 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.3.4#803005)
[jira] [Updated] (GEODE-9466) ByteBufferInputStream 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:
Description:
ByteBufferInputStream 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.
was:
ByteBufferInputStream 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:).
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.
> ByteBufferInputStream fails on Java 16 and later
>
>
> Key: GEODE-9466
> URL: https://issues.apache.org/jira/browse/GEODE-9466
> Project: Geode
> Issue Type: Bug
> Components: core
>Reporter: Darrel Schneider
>Priority: Major
> Labels: Java16
>
> ByteBufferInputStream 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.3.4#803005)
[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: Description: 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://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m).] The call is made in org.apache.geode.pdx.internal.AutoSerializableManager#getClassInfo and is required for the auto serializer to function correctly. was: 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://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m).] The call is made in org.apache.geode.pdx.internal.AutoSerializableManager#getClassInfo and is required for the auto serializer to function correctly. > 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 > > 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://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m).] > 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.3.4#803005)
[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: Description: 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. was: 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://stackoverflow.com/questions/41265266/how-to-solve-inaccessibleobjectexception-unable-to-make-member-accessible-m).] The call is made in org.apache.geode.pdx.internal.AutoSerializableManager#getClassInfo and is required for the auto serializer to function correctly. > 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 > > 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.3.4#803005)
[jira] [Created] (GEODE-9469) CopyHelper.copy will fail on java 16 and later when copying instances of Clonable
Darrel Schneider created GEODE-9469: --- Summary: 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 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.3.4#803005)
[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 (was: ) > 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 > > 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.3.4#803005)
[jira] [Commented] (GEODE-8740) increase test job timeouts
[ https://issues.apache.org/jira/browse/GEODE-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17388330#comment-17388330 ] ASF subversion and git services commented on GEODE-8740: Commit 34f681337db24ae934f7b17943755f66a9a0bb7f in geode's branch refs/heads/support/1.12 from Owen Nichols [ https://gitbox.apache.org/repos/asf?p=geode.git;h=34f6813 ] GEODE-8740: increase test job timeouts > increase test job timeouts > -- > > Key: GEODE-8740 > URL: https://issues.apache.org/jira/browse/GEODE-8740 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.13.3, 1.14.0 > > > Recently UpgradeTestOpenJDK8 has been taking ~59 minutes and its job timeout > is 1h. After adding 1.13.1 as old version, it tipped to taking slightly over > an hour on JDK8 (which is why it wasn't caught in PR, which only checks > JDK11). Timeout for this job should be increased to 1h30m as there's no need > to cut it so close. > Recent changes to Benchmarks have also caused longer runs (from 4h -> 7h in > the best case, and much much longer in the worst case). The current job > timeout of 8h is being hit frequently, and after trying a temporary increase > to 16h, we still saw successful runs taking 15h, and still some timing out... > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9470) Some geode queries will fail on java 16 and later
Darrel Schneider created GEODE-9470: --- Summary: 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 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.3.4#803005)
[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 (was: ) > 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.3.4#803005)
[jira] [Updated] (GEODE-8740) increase test job timeouts
[ https://issues.apache.org/jira/browse/GEODE-8740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-8740: Fix Version/s: 1.12.5 > increase test job timeouts > -- > > Key: GEODE-8740 > URL: https://issues.apache.org/jira/browse/GEODE-8740 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Owen Nichols >Priority: Major > Labels: pull-request-available > Fix For: 1.12.5, 1.13.3, 1.14.0 > > > Recently UpgradeTestOpenJDK8 has been taking ~59 minutes and its job timeout > is 1h. After adding 1.13.1 as old version, it tipped to taking slightly over > an hour on JDK8 (which is why it wasn't caught in PR, which only checks > JDK11). Timeout for this job should be increased to 1h30m as there's no need > to cut it so close. > Recent changes to Benchmarks have also caused longer runs (from 4h -> 7h in > the best case, and much much longer in the worst case). The current job > timeout of 8h is being hit frequently, and after trying a temporary increase > to 16h, we still saw successful runs taking 15h, and still some timing out... > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[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 (was: ) > 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 > > 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 iterates all the threads in the jvm checking which are > in the thread local by doing a get. This would cause the thread local to end > up containing all threads. What we could do on these scans (they only happen > when gfsh show dead-locks is executed) is if the get misses for a thread we > could turn around and call ThreadLocal.remove. A bit more expensive than the > current solution but it would be safe and work on java 16. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9471) gfsh show dead-locks will fail on java 16 and later
Darrel Schneider created GEODE-9471: --- Summary: 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 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 iterates all the threads in the jvm checking which are in the thread local by doing a get. This would cause the thread local to end up containing all threads. What we could do on these scans (they only happen when gfsh show dead-locks is executed) is if the get misses for a thread we could turn around and call ThreadLocal.remove. A bit more expensive than the current solution but it would be safe and work on java 16. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[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:
Component/s: (was: core)
offheap
> 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
>
> ByteBufferInputStream 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.3.4#803005)
[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:
Summary: ByteBufferInputStream.OffHeapByteSource fails on Java 16 and later
(was: ByteBufferInputStream fails on Java 16 and later)
> 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: core
>Reporter: Darrel Schneider
>Priority: Major
> Labels: Java16
>
> ByteBufferInputStream 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.3.4#803005)
[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:
Description:
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.
was:
ByteBufferInputStream 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.
> 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
>
> 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.3.4#803005)
[jira] [Commented] (GEODE-9359) add net-core-session to geode-native
[ https://issues.apache.org/jira/browse/GEODE-9359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17388365#comment-17388365 ] ASF subversion and git services commented on GEODE-9359: Commit ff7e02e9a58767bcf24a43b77f9c1a873f6c6c82 in geode-dotnet-core-client's branch refs/heads/AddNonSteeltoeSample from Mike Martell [ https://gitbox.apache.org/repos/asf?p=geode-dotnet-core-client.git;h=ff7e02e ] GEODE-9359: Add netcore-session to geode-native > add net-core-session to geode-native > > > Key: GEODE-9359 > URL: https://issues.apache.org/jira/browse/GEODE-9359 > Project: Geode > Issue Type: New Feature > Components: native client >Reporter: Ernest Burghardt >Priority: Major > > net-core-session shall be added to the top level of geode-native repo and > will produce a separate binary that will be publishable to NuGet > https://docs.microsoft.com/en-us/nuget/create-packages/package-authoring-best-practices -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9464) Add a non-Steeltoe Asp.Net Core SessionState sample app to SessionStateCore
[ https://issues.apache.org/jira/browse/GEODE-9464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17388364#comment-17388364 ] ASF subversion and git services commented on GEODE-9464: Commit 6594f20bb85ac9c9ed6b7d94b6e48dbef3bffee7 in geode-dotnet-core-client's branch refs/heads/AddNonSteeltoeSample from Mike Martell [ https://gitbox.apache.org/repos/asf?p=geode-dotnet-core-client.git;h=6594f20 ] GEODE-9464: Add a non-Steeltoe Asp.Net Core web app > Add a non-Steeltoe Asp.Net Core SessionState sample app to SessionStateCore > --- > > Key: GEODE-9464 > URL: https://issues.apache.org/jira/browse/GEODE-9464 > Project: Geode > Issue Type: Test > Components: native client >Reporter: Michael Martell >Priority: Major > > The current Asp.Net sample app uses Steeltoe for discovery and registration > of our sessionstate provider. We need a non-Steeltoe sample as well, since > not everyone uses Steeltoe. > This will be a good test of our NuGet access to the SessionState Core > artifacts and its dependencies. > Note: Ensure that the web application runs on all platforms. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9359) add net-core-session to geode-native
[ https://issues.apache.org/jira/browse/GEODE-9359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17388366#comment-17388366 ] ASF subversion and git services commented on GEODE-9359: Commit bebc71500e0b987117970b3faa22878b4f310516 in geode-dotnet-core-client's branch refs/heads/AddNonSteeltoeSample from Mike Martell [ https://gitbox.apache.org/repos/asf?p=geode-dotnet-core-client.git;h=bebc715 ] GEODE-9359: Delete Steeltoe sample > add net-core-session to geode-native > > > Key: GEODE-9359 > URL: https://issues.apache.org/jira/browse/GEODE-9359 > Project: Geode > Issue Type: New Feature > Components: native client >Reporter: Ernest Burghardt >Priority: Major > > net-core-session shall be added to the top level of geode-native repo and > will produce a separate binary that will be publishable to NuGet > https://docs.microsoft.com/en-us/nuget/create-packages/package-authoring-best-practices -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9359) add net-core-session to geode-native
[ https://issues.apache.org/jira/browse/GEODE-9359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17388481#comment-17388481 ] ASF GitHub Bot commented on GEODE-9359: --- mmartell opened a new pull request #834: URL: https://github.com/apache/geode-native/pull/834 This PR brings in the NetCore-Session code. Note: There will be a separate PR for adding CI support for NetCore-Session under GEODE-9357. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org > add net-core-session to geode-native > > > Key: GEODE-9359 > URL: https://issues.apache.org/jira/browse/GEODE-9359 > Project: Geode > Issue Type: New Feature > Components: native client >Reporter: Ernest Burghardt >Priority: Major > > net-core-session shall be added to the top level of geode-native repo and > will produce a separate binary that will be publishable to NuGet > https://docs.microsoft.com/en-us/nuget/create-packages/package-authoring-best-practices -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9359) add net-core-session to geode-native
[ https://issues.apache.org/jira/browse/GEODE-9359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-9359: -- Labels: pull-request-available (was: ) > add net-core-session to geode-native > > > Key: GEODE-9359 > URL: https://issues.apache.org/jira/browse/GEODE-9359 > Project: Geode > Issue Type: New Feature > Components: native client >Reporter: Ernest Burghardt >Priority: Major > Labels: pull-request-available > > net-core-session shall be added to the top level of geode-native repo and > will produce a separate binary that will be publishable to NuGet > https://docs.microsoft.com/en-us/nuget/create-packages/package-authoring-best-practices -- This message was sent by Atlassian Jira (v8.3.4#803005)
