[jira] [Resolved] (GEODE-10374) Starting Locator through Spring Data Geode not working in JDK17
[
https://issues.apache.org/jira/browse/GEODE-10374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer resolved GEODE-10374.
---
Resolution: Not A Problem
> Starting Locator through Spring Data Geode not working in JDK17
> ---
>
> Key: GEODE-10374
> URL: https://issues.apache.org/jira/browse/GEODE-10374
> Project: Geode
> Issue Type: Sub-task
> Components: locator
>Affects Versions: 1.15.0
>Reporter: Udo Kohlmeyer
>Priority: Major
> Labels: jdk17
>
> The starting of a Locator with Spring is failing in JDK17 with
> {code:java}
> 2022-06-09 12:47:42,695 ERROR xecutors.LoggingUncaughtExceptionHandler: 92 -
> Uncaught exception in thread Thread[P2P message reader for
> 10.99.199.28(SpringBasedLocatorApplication:9908:locator):41000
> unshared ordered sender uid=1 dom #1 local port=52238 remote
> port=55993,10,main]
> java.lang.IllegalAccessError: class
> org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer (in unnamed module
> @0x7276c8cd) cannot access class sun.nio.ch.DirectBuffer (in module
> java.base) because module java.base does not export sun.nio.ch to unnamed
> module @0x7276c8cd
> at
> org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer.attachment(DirectBuffer.java:29)
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:338)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:313)
> at
> org.apache.geode.internal.net.BufferPool.releaseReceiveBuffer(BufferPool.java:220)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:301)
> at
> org.apache.geode.internal.net.ByteBufferVendor$ByteBufferSharingInternalImpl.releaseBuffer(ByteBufferVendor.java:219)
> at
> org.apache.geode.internal.net.ByteBufferVendor.dropReference(ByteBufferVendor.java:150)
> at
> org.apache.geode.internal.net.ByteBufferVendor.destruct(ByteBufferVendor.java:115)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1523)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833) {code}
> even with the added recommended add-opens options of
> {code:java}
> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED
> --add-exports=java.management/com.sun.jmx.remote.security=ALL-UNNAMED
> --add-opens=java.base/java.lang=ALL-UNNAMED
> --add-opens=java.base/java.nio=ALL-UNNAMED
> --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED {code}
> as can be seen here
> {code:java}
> /Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home/bin/java -server
> -ea --add-opens java.base/java.lang=ALL-UNNAMED --add-opens,
> java.base/java.nio=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED
> --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED
> --add-exports java.base/sun.nio.ch=ALL-UNNAMED --add-exports
> java.management/com.sun.jmx.remote.security=ALL-UNNAMED, -classpath ...
> -Dspring.data.gemfire.locator.port=56039,
> -Dgemfire.enable-cluster-configuration=false,
> org.springframework.data.gemfire.config.annotation.PeerCacheApplicationWithAddedCacheServerIntegrationTests$TestLocatorConfiguration
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10374) Starting Locator through Spring Data Geode not working in JDK17
[
https://issues.apache.org/jira/browse/GEODE-10374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10374:
--
Labels: jdk17 (was: blocks-1.15.0 jdk17 needsTriage)
> Starting Locator through Spring Data Geode not working in JDK17
> ---
>
> Key: GEODE-10374
> URL: https://issues.apache.org/jira/browse/GEODE-10374
> Project: Geode
> Issue Type: Sub-task
> Components: locator
>Affects Versions: 1.15.0
>Reporter: Udo Kohlmeyer
>Priority: Major
> Labels: jdk17
>
> The starting of a Locator with Spring is failing in JDK17 with
> {code:java}
> 2022-06-09 12:47:42,695 ERROR xecutors.LoggingUncaughtExceptionHandler: 92 -
> Uncaught exception in thread Thread[P2P message reader for
> 10.99.199.28(SpringBasedLocatorApplication:9908:locator):41000
> unshared ordered sender uid=1 dom #1 local port=52238 remote
> port=55993,10,main]
> java.lang.IllegalAccessError: class
> org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer (in unnamed module
> @0x7276c8cd) cannot access class sun.nio.ch.DirectBuffer (in module
> java.base) because module java.base does not export sun.nio.ch to unnamed
> module @0x7276c8cd
> at
> org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer.attachment(DirectBuffer.java:29)
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:338)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:313)
> at
> org.apache.geode.internal.net.BufferPool.releaseReceiveBuffer(BufferPool.java:220)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:301)
> at
> org.apache.geode.internal.net.ByteBufferVendor$ByteBufferSharingInternalImpl.releaseBuffer(ByteBufferVendor.java:219)
> at
> org.apache.geode.internal.net.ByteBufferVendor.dropReference(ByteBufferVendor.java:150)
> at
> org.apache.geode.internal.net.ByteBufferVendor.destruct(ByteBufferVendor.java:115)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1523)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833) {code}
> even with the added recommended add-opens options of
> {code:java}
> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED
> --add-exports=java.management/com.sun.jmx.remote.security=ALL-UNNAMED
> --add-opens=java.base/java.lang=ALL-UNNAMED
> --add-opens=java.base/java.nio=ALL-UNNAMED
> --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED {code}
> as can be seen here
> {code:java}
> /Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home/bin/java -server
> -ea --add-opens java.base/java.lang=ALL-UNNAMED --add-opens,
> java.base/java.nio=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED
> --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED
> --add-exports java.base/sun.nio.ch=ALL-UNNAMED --add-exports
> java.management/com.sun.jmx.remote.security=ALL-UNNAMED, -classpath ...
> -Dspring.data.gemfire.locator.port=56039,
> -Dgemfire.enable-cluster-configuration=false,
> org.springframework.data.gemfire.config.annotation.PeerCacheApplicationWithAddedCacheServerIntegrationTests$TestLocatorConfiguration
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10374) Starting Locator through Spring Data Geode not working in JDK17
[
https://issues.apache.org/jira/browse/GEODE-10374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17552497#comment-17552497
]
Udo Kohlmeyer commented on GEODE-10374:
---
This seems to have been a problem in how the Surefire plugin in Spring Data
Geode was configured.
> Starting Locator through Spring Data Geode not working in JDK17
> ---
>
> Key: GEODE-10374
> URL: https://issues.apache.org/jira/browse/GEODE-10374
> Project: Geode
> Issue Type: Sub-task
> Components: locator
>Affects Versions: 1.15.0
>Reporter: Udo Kohlmeyer
>Priority: Major
> Labels: blocks-1.15.0, jdk17, needsTriage
>
> The starting of a Locator with Spring is failing in JDK17 with
> {code:java}
> 2022-06-09 12:47:42,695 ERROR xecutors.LoggingUncaughtExceptionHandler: 92 -
> Uncaught exception in thread Thread[P2P message reader for
> 10.99.199.28(SpringBasedLocatorApplication:9908:locator):41000
> unshared ordered sender uid=1 dom #1 local port=52238 remote
> port=55993,10,main]
> java.lang.IllegalAccessError: class
> org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer (in unnamed module
> @0x7276c8cd) cannot access class sun.nio.ch.DirectBuffer (in module
> java.base) because module java.base does not export sun.nio.ch to unnamed
> module @0x7276c8cd
> at
> org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer.attachment(DirectBuffer.java:29)
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:338)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:313)
> at
> org.apache.geode.internal.net.BufferPool.releaseReceiveBuffer(BufferPool.java:220)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:301)
> at
> org.apache.geode.internal.net.ByteBufferVendor$ByteBufferSharingInternalImpl.releaseBuffer(ByteBufferVendor.java:219)
> at
> org.apache.geode.internal.net.ByteBufferVendor.dropReference(ByteBufferVendor.java:150)
> at
> org.apache.geode.internal.net.ByteBufferVendor.destruct(ByteBufferVendor.java:115)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1523)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833) {code}
> even with the added recommended add-opens options of
> {code:java}
> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED
> --add-exports=java.management/com.sun.jmx.remote.security=ALL-UNNAMED
> --add-opens=java.base/java.lang=ALL-UNNAMED
> --add-opens=java.base/java.nio=ALL-UNNAMED
> --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED {code}
> as can be seen here
> {code:java}
> /Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home/bin/java -server
> -ea --add-opens java.base/java.lang=ALL-UNNAMED --add-opens,
> java.base/java.nio=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED
> --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED
> --add-exports java.base/sun.nio.ch=ALL-UNNAMED --add-exports
> java.management/com.sun.jmx.remote.security=ALL-UNNAMED, -classpath ...
> -Dspring.data.gemfire.locator.port=56039,
> -Dgemfire.enable-cluster-configuration=false,
> org.springframework.data.gemfire.config.annotation.PeerCacheApplicationWithAddedCacheServerIntegrationTests$TestLocatorConfiguration
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10374) Starting Locator through Spring Data Geode not working in JDK17
[
https://issues.apache.org/jira/browse/GEODE-10374?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17552467#comment-17552467
]
Udo Kohlmeyer commented on GEODE-10374:
---
[~klund] I don't have it, but I will liase with my team member who encountered
it and see what we can provide
> Starting Locator through Spring Data Geode not working in JDK17
> ---
>
> Key: GEODE-10374
> URL: https://issues.apache.org/jira/browse/GEODE-10374
> Project: Geode
> Issue Type: Sub-task
> Components: locator
>Affects Versions: 1.15.0
>Reporter: Udo Kohlmeyer
>Priority: Major
> Labels: blocks-1.15.0, jdk17, needsTriage
>
> The starting of a Locator with Spring is failing in JDK17 with
> {code:java}
> 2022-06-09 12:47:42,695 ERROR xecutors.LoggingUncaughtExceptionHandler: 92 -
> Uncaught exception in thread Thread[P2P message reader for
> 10.99.199.28(SpringBasedLocatorApplication:9908:locator):41000
> unshared ordered sender uid=1 dom #1 local port=52238 remote
> port=55993,10,main]
> java.lang.IllegalAccessError: class
> org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer (in unnamed module
> @0x7276c8cd) cannot access class sun.nio.ch.DirectBuffer (in module
> java.base) because module java.base does not export sun.nio.ch to unnamed
> module @0x7276c8cd
> at
> org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer.attachment(DirectBuffer.java:29)
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:338)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:313)
> at
> org.apache.geode.internal.net.BufferPool.releaseReceiveBuffer(BufferPool.java:220)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:301)
> at
> org.apache.geode.internal.net.ByteBufferVendor$ByteBufferSharingInternalImpl.releaseBuffer(ByteBufferVendor.java:219)
> at
> org.apache.geode.internal.net.ByteBufferVendor.dropReference(ByteBufferVendor.java:150)
> at
> org.apache.geode.internal.net.ByteBufferVendor.destruct(ByteBufferVendor.java:115)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1523)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833) {code}
> even with the added recommended add-opens options of
> {code:java}
> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED
> --add-exports=java.management/com.sun.jmx.remote.security=ALL-UNNAMED
> --add-opens=java.base/java.lang=ALL-UNNAMED
> --add-opens=java.base/java.nio=ALL-UNNAMED
> --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED {code}
> as can be seen here
> {code:java}
> /Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home/bin/java -server
> -ea --add-opens java.base/java.lang=ALL-UNNAMED --add-opens,
> java.base/java.nio=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED
> --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED
> --add-exports java.base/sun.nio.ch=ALL-UNNAMED --add-exports
> java.management/com.sun.jmx.remote.security=ALL-UNNAMED, -classpath ...
> -Dspring.data.gemfire.locator.port=56039,
> -Dgemfire.enable-cluster-configuration=false,
> org.springframework.data.gemfire.config.annotation.PeerCacheApplicationWithAddedCacheServerIntegrationTests$TestLocatorConfiguration
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10374) Starting Locator through Spring Data Geode not working in JDK17
[
https://issues.apache.org/jira/browse/GEODE-10374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10374:
--
Affects Version/s: 1.15.0
> Starting Locator through Spring Data Geode not working in JDK17
> ---
>
> Key: GEODE-10374
> URL: https://issues.apache.org/jira/browse/GEODE-10374
> Project: Geode
> Issue Type: Sub-task
> Components: locator
>Affects Versions: 1.15.0
>Reporter: Udo Kohlmeyer
>Priority: Major
> Labels: blocks-1.15.0, jdk17, needsTriage
>
> The starting of a Locator with Spring is failing in JDK17 with
> {code:java}
> 2022-06-09 12:47:42,695 ERROR xecutors.LoggingUncaughtExceptionHandler: 92 -
> Uncaught exception in thread Thread[P2P message reader for
> 10.99.199.28(SpringBasedLocatorApplication:9908:locator):41000
> unshared ordered sender uid=1 dom #1 local port=52238 remote
> port=55993,10,main]
> java.lang.IllegalAccessError: class
> org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer (in unnamed module
> @0x7276c8cd) cannot access class sun.nio.ch.DirectBuffer (in module
> java.base) because module java.base does not export sun.nio.ch to unnamed
> module @0x7276c8cd
> at
> org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer.attachment(DirectBuffer.java:29)
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:338)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:313)
> at
> org.apache.geode.internal.net.BufferPool.releaseReceiveBuffer(BufferPool.java:220)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:301)
> at
> org.apache.geode.internal.net.ByteBufferVendor$ByteBufferSharingInternalImpl.releaseBuffer(ByteBufferVendor.java:219)
> at
> org.apache.geode.internal.net.ByteBufferVendor.dropReference(ByteBufferVendor.java:150)
> at
> org.apache.geode.internal.net.ByteBufferVendor.destruct(ByteBufferVendor.java:115)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1523)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833) {code}
> even with the added recommended add-opens options of
> {code:java}
> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED
> --add-exports=java.management/com.sun.jmx.remote.security=ALL-UNNAMED
> --add-opens=java.base/java.lang=ALL-UNNAMED
> --add-opens=java.base/java.nio=ALL-UNNAMED
> --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED {code}
> as can be seen here
> {code:java}
> /Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home/bin/java -server
> -ea --add-opens java.base/java.lang=ALL-UNNAMED --add-opens,
> java.base/java.nio=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED
> --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED
> --add-exports java.base/sun.nio.ch=ALL-UNNAMED --add-exports
> java.management/com.sun.jmx.remote.security=ALL-UNNAMED, -classpath ...
> -Dspring.data.gemfire.locator.port=56039,
> -Dgemfire.enable-cluster-configuration=false,
> org.springframework.data.gemfire.config.annotation.PeerCacheApplicationWithAddedCacheServerIntegrationTests$TestLocatorConfiguration
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10374) Starting Locator through Spring Data Geode not working in JDK17
[
https://issues.apache.org/jira/browse/GEODE-10374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10374:
--
Labels: blocks-1.15.0 jdk17 needsTriage (was: blocks-1.15.0 needsTriage)
> Starting Locator through Spring Data Geode not working in JDK17
> ---
>
> Key: GEODE-10374
> URL: https://issues.apache.org/jira/browse/GEODE-10374
> Project: Geode
> Issue Type: Sub-task
> Components: locator
>Reporter: Udo Kohlmeyer
>Priority: Major
> Labels: blocks-1.15.0, jdk17, needsTriage
>
> The starting of a Locator with Spring is failing in JDK17 with
> {code:java}
> 2022-06-09 12:47:42,695 ERROR xecutors.LoggingUncaughtExceptionHandler: 92 -
> Uncaught exception in thread Thread[P2P message reader for
> 10.99.199.28(SpringBasedLocatorApplication:9908:locator):41000
> unshared ordered sender uid=1 dom #1 local port=52238 remote
> port=55993,10,main]
> java.lang.IllegalAccessError: class
> org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer (in unnamed module
> @0x7276c8cd) cannot access class sun.nio.ch.DirectBuffer (in module
> java.base) because module java.base does not export sun.nio.ch to unnamed
> module @0x7276c8cd
> at
> org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer.attachment(DirectBuffer.java:29)
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:338)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:313)
> at
> org.apache.geode.internal.net.BufferPool.releaseReceiveBuffer(BufferPool.java:220)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:301)
> at
> org.apache.geode.internal.net.ByteBufferVendor$ByteBufferSharingInternalImpl.releaseBuffer(ByteBufferVendor.java:219)
> at
> org.apache.geode.internal.net.ByteBufferVendor.dropReference(ByteBufferVendor.java:150)
> at
> org.apache.geode.internal.net.ByteBufferVendor.destruct(ByteBufferVendor.java:115)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1523)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833) {code}
> even with the added recommended add-opens options of
> {code:java}
> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED
> --add-exports=java.management/com.sun.jmx.remote.security=ALL-UNNAMED
> --add-opens=java.base/java.lang=ALL-UNNAMED
> --add-opens=java.base/java.nio=ALL-UNNAMED
> --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED {code}
> as can be seen here
> {code:java}
> /Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home/bin/java -server
> -ea --add-opens java.base/java.lang=ALL-UNNAMED --add-opens,
> java.base/java.nio=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED
> --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED
> --add-exports java.base/sun.nio.ch=ALL-UNNAMED --add-exports
> java.management/com.sun.jmx.remote.security=ALL-UNNAMED, -classpath ...
> -Dspring.data.gemfire.locator.port=56039,
> -Dgemfire.enable-cluster-configuration=false,
> org.springframework.data.gemfire.config.annotation.PeerCacheApplicationWithAddedCacheServerIntegrationTests$TestLocatorConfiguration
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10374) Starting Locator through Spring Data Geode not working in JDK17
Udo Kohlmeyer created GEODE-10374:
-
Summary: Starting Locator through Spring Data Geode not working in
JDK17
Key: GEODE-10374
URL: https://issues.apache.org/jira/browse/GEODE-10374
Project: Geode
Issue Type: Bug
Reporter: Udo Kohlmeyer
The starting of a Locator with Spring is failing in JDK17 with
{code:java}
2022-06-09 12:47:42,695 ERROR xecutors.LoggingUncaughtExceptionHandler: 92 -
Uncaught exception in thread Thread[P2P message reader for
10.99.199.28(SpringBasedLocatorApplication:9908:locator):41000 unshared
ordered sender uid=1 dom #1 local port=52238 remote port=55993,10,main]
java.lang.IllegalAccessError: class
org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer (in unnamed module
@0x7276c8cd) cannot access class sun.nio.ch.DirectBuffer (in module java.base)
because module java.base does not export sun.nio.ch to unnamed module
@0x7276c8cd
at
org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer.attachment(DirectBuffer.java:29)
at
org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:338)
at
org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:313)
at
org.apache.geode.internal.net.BufferPool.releaseReceiveBuffer(BufferPool.java:220)
at
org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:301)
at
org.apache.geode.internal.net.ByteBufferVendor$ByteBufferSharingInternalImpl.releaseBuffer(ByteBufferVendor.java:219)
at
org.apache.geode.internal.net.ByteBufferVendor.dropReference(ByteBufferVendor.java:150)
at
org.apache.geode.internal.net.ByteBufferVendor.destruct(ByteBufferVendor.java:115)
at org.apache.geode.internal.tcp.Connection.run(Connection.java:1523)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833) {code}
even with the added recommended add-opens options of
{code:java}
--add-exports=java.base/sun.nio.ch=ALL-UNNAMED
--add-exports=java.management/com.sun.jmx.remote.security=ALL-UNNAMED
--add-opens=java.base/java.lang=ALL-UNNAMED
--add-opens=java.base/java.nio=ALL-UNNAMED
--add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED {code}
as can be seen here
{code:java}
/Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home/bin/java -server -ea
--add-opens java.base/java.lang=ALL-UNNAMED --add-opens,
java.base/java.nio=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED
--add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED
--add-exports java.base/sun.nio.ch=ALL-UNNAMED --add-exports
java.management/com.sun.jmx.remote.security=ALL-UNNAMED, -classpath ...
-Dspring.data.gemfire.locator.port=56039,
-Dgemfire.enable-cluster-configuration=false,
org.springframework.data.gemfire.config.annotation.PeerCacheApplicationWithAddedCacheServerIntegrationTests$TestLocatorConfiguration
{code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10374) Starting Locator through Spring Data Geode not working in JDK17
[
https://issues.apache.org/jira/browse/GEODE-10374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10374:
--
Parent: GEODE-10003
Issue Type: Sub-task (was: Bug)
> Starting Locator through Spring Data Geode not working in JDK17
> ---
>
> Key: GEODE-10374
> URL: https://issues.apache.org/jira/browse/GEODE-10374
> Project: Geode
> Issue Type: Sub-task
>Reporter: Udo Kohlmeyer
>Priority: Major
> Labels: needsTriage
>
> The starting of a Locator with Spring is failing in JDK17 with
> {code:java}
> 2022-06-09 12:47:42,695 ERROR xecutors.LoggingUncaughtExceptionHandler: 92 -
> Uncaught exception in thread Thread[P2P message reader for
> 10.99.199.28(SpringBasedLocatorApplication:9908:locator):41000
> unshared ordered sender uid=1 dom #1 local port=52238 remote
> port=55993,10,main]
> java.lang.IllegalAccessError: class
> org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer (in unnamed module
> @0x7276c8cd) cannot access class sun.nio.ch.DirectBuffer (in module
> java.base) because module java.base does not export sun.nio.ch to unnamed
> module @0x7276c8cd
> at
> org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer.attachment(DirectBuffer.java:29)
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:338)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:313)
> at
> org.apache.geode.internal.net.BufferPool.releaseReceiveBuffer(BufferPool.java:220)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:301)
> at
> org.apache.geode.internal.net.ByteBufferVendor$ByteBufferSharingInternalImpl.releaseBuffer(ByteBufferVendor.java:219)
> at
> org.apache.geode.internal.net.ByteBufferVendor.dropReference(ByteBufferVendor.java:150)
> at
> org.apache.geode.internal.net.ByteBufferVendor.destruct(ByteBufferVendor.java:115)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1523)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833) {code}
> even with the added recommended add-opens options of
> {code:java}
> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED
> --add-exports=java.management/com.sun.jmx.remote.security=ALL-UNNAMED
> --add-opens=java.base/java.lang=ALL-UNNAMED
> --add-opens=java.base/java.nio=ALL-UNNAMED
> --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED {code}
> as can be seen here
> {code:java}
> /Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home/bin/java -server
> -ea --add-opens java.base/java.lang=ALL-UNNAMED --add-opens,
> java.base/java.nio=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED
> --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED
> --add-exports java.base/sun.nio.ch=ALL-UNNAMED --add-exports
> java.management/com.sun.jmx.remote.security=ALL-UNNAMED, -classpath ...
> -Dspring.data.gemfire.locator.port=56039,
> -Dgemfire.enable-cluster-configuration=false,
> org.springframework.data.gemfire.config.annotation.PeerCacheApplicationWithAddedCacheServerIntegrationTests$TestLocatorConfiguration
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10374) Starting Locator through Spring Data Geode not working in JDK17
[
https://issues.apache.org/jira/browse/GEODE-10374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10374:
--
Labels: blocks-1.15.0 needsTriage (was: needsTriage)
> Starting Locator through Spring Data Geode not working in JDK17
> ---
>
> Key: GEODE-10374
> URL: https://issues.apache.org/jira/browse/GEODE-10374
> Project: Geode
> Issue Type: Sub-task
>Reporter: Udo Kohlmeyer
>Priority: Major
> Labels: blocks-1.15.0, needsTriage
>
> The starting of a Locator with Spring is failing in JDK17 with
> {code:java}
> 2022-06-09 12:47:42,695 ERROR xecutors.LoggingUncaughtExceptionHandler: 92 -
> Uncaught exception in thread Thread[P2P message reader for
> 10.99.199.28(SpringBasedLocatorApplication:9908:locator):41000
> unshared ordered sender uid=1 dom #1 local port=52238 remote
> port=55993,10,main]
> java.lang.IllegalAccessError: class
> org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer (in unnamed module
> @0x7276c8cd) cannot access class sun.nio.ch.DirectBuffer (in module
> java.base) because module java.base does not export sun.nio.ch to unnamed
> module @0x7276c8cd
> at
> org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer.attachment(DirectBuffer.java:29)
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:338)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:313)
> at
> org.apache.geode.internal.net.BufferPool.releaseReceiveBuffer(BufferPool.java:220)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:301)
> at
> org.apache.geode.internal.net.ByteBufferVendor$ByteBufferSharingInternalImpl.releaseBuffer(ByteBufferVendor.java:219)
> at
> org.apache.geode.internal.net.ByteBufferVendor.dropReference(ByteBufferVendor.java:150)
> at
> org.apache.geode.internal.net.ByteBufferVendor.destruct(ByteBufferVendor.java:115)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1523)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833) {code}
> even with the added recommended add-opens options of
> {code:java}
> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED
> --add-exports=java.management/com.sun.jmx.remote.security=ALL-UNNAMED
> --add-opens=java.base/java.lang=ALL-UNNAMED
> --add-opens=java.base/java.nio=ALL-UNNAMED
> --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED {code}
> as can be seen here
> {code:java}
> /Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home/bin/java -server
> -ea --add-opens java.base/java.lang=ALL-UNNAMED --add-opens,
> java.base/java.nio=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED
> --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED
> --add-exports java.base/sun.nio.ch=ALL-UNNAMED --add-exports
> java.management/com.sun.jmx.remote.security=ALL-UNNAMED, -classpath ...
> -Dspring.data.gemfire.locator.port=56039,
> -Dgemfire.enable-cluster-configuration=false,
> org.springframework.data.gemfire.config.annotation.PeerCacheApplicationWithAddedCacheServerIntegrationTests$TestLocatorConfiguration
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10374) Starting Locator through Spring Data Geode not working in JDK17
[
https://issues.apache.org/jira/browse/GEODE-10374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10374:
--
Component/s: locator
> Starting Locator through Spring Data Geode not working in JDK17
> ---
>
> Key: GEODE-10374
> URL: https://issues.apache.org/jira/browse/GEODE-10374
> Project: Geode
> Issue Type: Sub-task
> Components: locator
>Reporter: Udo Kohlmeyer
>Priority: Major
> Labels: blocks-1.15.0, needsTriage
>
> The starting of a Locator with Spring is failing in JDK17 with
> {code:java}
> 2022-06-09 12:47:42,695 ERROR xecutors.LoggingUncaughtExceptionHandler: 92 -
> Uncaught exception in thread Thread[P2P message reader for
> 10.99.199.28(SpringBasedLocatorApplication:9908:locator):41000
> unshared ordered sender uid=1 dom #1 local port=52238 remote
> port=55993,10,main]
> java.lang.IllegalAccessError: class
> org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer (in unnamed module
> @0x7276c8cd) cannot access class sun.nio.ch.DirectBuffer (in module
> java.base) because module java.base does not export sun.nio.ch to unnamed
> module @0x7276c8cd
> at
> org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer.attachment(DirectBuffer.java:29)
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:338)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:313)
> at
> org.apache.geode.internal.net.BufferPool.releaseReceiveBuffer(BufferPool.java:220)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:301)
> at
> org.apache.geode.internal.net.ByteBufferVendor$ByteBufferSharingInternalImpl.releaseBuffer(ByteBufferVendor.java:219)
> at
> org.apache.geode.internal.net.ByteBufferVendor.dropReference(ByteBufferVendor.java:150)
> at
> org.apache.geode.internal.net.ByteBufferVendor.destruct(ByteBufferVendor.java:115)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1523)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
> at java.base/java.lang.Thread.run(Thread.java:833) {code}
> even with the added recommended add-opens options of
> {code:java}
> --add-exports=java.base/sun.nio.ch=ALL-UNNAMED
> --add-exports=java.management/com.sun.jmx.remote.security=ALL-UNNAMED
> --add-opens=java.base/java.lang=ALL-UNNAMED
> --add-opens=java.base/java.nio=ALL-UNNAMED
> --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED {code}
> as can be seen here
> {code:java}
> /Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home/bin/java -server
> -ea --add-opens java.base/java.lang=ALL-UNNAMED --add-opens,
> java.base/java.nio=ALL-UNNAMED --add-opens java.base/java.util=ALL-UNNAMED
> --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED
> --add-exports java.base/sun.nio.ch=ALL-UNNAMED --add-exports
> java.management/com.sun.jmx.remote.security=ALL-UNNAMED, -classpath ...
> -Dspring.data.gemfire.locator.port=56039,
> -Dgemfire.enable-cluster-configuration=false,
> org.springframework.data.gemfire.config.annotation.PeerCacheApplicationWithAddedCacheServerIntegrationTests$TestLocatorConfiguration
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10364) DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
[
https://issues.apache.org/jira/browse/GEODE-10364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10364:
--
Priority: Minor (was: Major)
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> --
>
> Key: GEODE-10364
> URL: https://issues.apache.org/jira/browse/GEODE-10364
> Project: Geode
> Issue Type: Bug
> Components: management
>Affects Versions: 1.15.0
>Reporter: Udo Kohlmeyer
>Priority: Minor
> Labels: needsTriage
>
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> is failing with unexpected log entries.
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2671
> {code:java}
> DeploymentManagementRedployDUnitTest >
> hotDeployShouldNotResultInAnyFailedFunctionExecutions FAILED
> 01:44:15java.lang.AssertionError: Suspicious strings were written to the
> log during this run.
> 01:44:15Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 01:44:15
> ---
> 01:44:15Found suspect string in 'dunit_suspect-vm0.log' at line 531
> 01:44:15
> 01:44:15
> PK{}?T)???DeployCommandRedeployDUnitFunctionA.class???n?@??IhChh?:??Bp+B??E
>
> EP5P$n??J?r?h?F?g???P9?? 01:44:15??`?2??G??%%?^
> 01:44:15O?C
> 01:44:15
> ??i?.w?Y???M??y;???Kdl??8u1???OZB#??k?-Nay0=??7??N+?5?^??)???*Er:F?c4]I}N?+?o???5zR?H?i?[X???[l?#?P??#??eN!:?
>
> v?v??u?2?W?r?$?Kqu??YnS??+V}E.???j-?{?7PK??4|'?=???PK??{}?T4|'?=???)?DeployCommandRedeployDUnitFunctionA.classPK??[???j?
> 01:44:15--cvFOdAqPh74YsEftzj4GE_lSmdgeMggm6mUZS8E
> 01:44:15Content-Disposition: form-data; name="config"
> 01:44:15Content-Type: application/json
> 01:44:15
> 01:44:15
> ---
> 01:44:15Found suspect string in 'dunit_suspect-vm0.log' at line 550
> 01:44:15
> 01:44:15
> PK{}?T)???DeployCommandRedeployDUnitFunctionA.class???n?@??IhChh?:???p+B??E
>
> EP5P$n??J?r?h?F?g???P9?? 01:44:15??`?2??G??%%?^
> 01:44:15O?C
> 01:44:15
> ??i?.w?Y???M??y;???Kdl??8u1???OZB#??k?-Nay0=??7??N+?5?^??)???*Er:F?c4]I}N?+?o???5zR?H?i?[X???[l?#?P??#??eN!:?
>
> v?v??u?2?W?r?$?Kqu??YnS??+V}E.???j-?{?7PK??=???PK??{}?T=???)?DeployCommandRedeployDUnitFunctionA.classPK??[???j?
> 01:44:15---UjSGLHVgaMcjtjM7IJfWJ3fPZEhjOGN
> 01:44:15Content-Disposition: form-data; name="config"
> 01:44:15Content-Type: application/json {code}
> In order to resolve this issue the ManagementLoggingFilter needs to be a
> little more discriminant on what it logs out, as it currently is serializing
> the jar file contents as a String, which is causing this issue.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10364) DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
[
https://issues.apache.org/jira/browse/GEODE-10364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10364:
--
Component/s: tests
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> --
>
> Key: GEODE-10364
> URL: https://issues.apache.org/jira/browse/GEODE-10364
> Project: Geode
> Issue Type: Bug
> Components: management, tests
>Affects Versions: 1.15.0
>Reporter: Udo Kohlmeyer
>Priority: Minor
> Labels: needsTriage
>
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> is failing with unexpected log entries.
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2671
> {code:java}
> DeploymentManagementRedployDUnitTest >
> hotDeployShouldNotResultInAnyFailedFunctionExecutions FAILED
> 01:44:15java.lang.AssertionError: Suspicious strings were written to the
> log during this run.
> 01:44:15Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 01:44:15
> ---
> 01:44:15Found suspect string in 'dunit_suspect-vm0.log' at line 531
> 01:44:15
> 01:44:15
> PK{}?T)???DeployCommandRedeployDUnitFunctionA.class???n?@??IhChh?:??Bp+B??E
>
> EP5P$n??J?r?h?F?g???P9?? 01:44:15??`?2??G??%%?^
> 01:44:15O?C
> 01:44:15
> ??i?.w?Y???M??y;???Kdl??8u1???OZB#??k?-Nay0=??7??N+?5?^??)???*Er:F?c4]I}N?+?o???5zR?H?i?[X???[l?#?P??#??eN!:?
>
> v?v??u?2?W?r?$?Kqu??YnS??+V}E.???j-?{?7PK??4|'?=???PK??{}?T4|'?=???)?DeployCommandRedeployDUnitFunctionA.classPK??[???j?
> 01:44:15--cvFOdAqPh74YsEftzj4GE_lSmdgeMggm6mUZS8E
> 01:44:15Content-Disposition: form-data; name="config"
> 01:44:15Content-Type: application/json
> 01:44:15
> 01:44:15
> ---
> 01:44:15Found suspect string in 'dunit_suspect-vm0.log' at line 550
> 01:44:15
> 01:44:15
> PK{}?T)???DeployCommandRedeployDUnitFunctionA.class???n?@??IhChh?:???p+B??E
>
> EP5P$n??J?r?h?F?g???P9?? 01:44:15??`?2??G??%%?^
> 01:44:15O?C
> 01:44:15
> ??i?.w?Y???M??y;???Kdl??8u1???OZB#??k?-Nay0=??7??N+?5?^??)???*Er:F?c4]I}N?+?o???5zR?H?i?[X???[l?#?P??#??eN!:?
>
> v?v??u?2?W?r?$?Kqu??YnS??+V}E.???j-?{?7PK??=???PK??{}?T=???)?DeployCommandRedeployDUnitFunctionA.classPK??[???j?
> 01:44:15---UjSGLHVgaMcjtjM7IJfWJ3fPZEhjOGN
> 01:44:15Content-Disposition: form-data; name="config"
> 01:44:15Content-Type: application/json {code}
> In order to resolve this issue the ManagementLoggingFilter needs to be a
> little more discriminant on what it logs out, as it currently is serializing
> the jar file contents as a String, which is causing this issue.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-10364) DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
[
https://issues.apache.org/jira/browse/GEODE-10364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10364:
--
Component/s: rest (admin)
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> --
>
> Key: GEODE-10364
> URL: https://issues.apache.org/jira/browse/GEODE-10364
> Project: Geode
> Issue Type: Bug
> Components: management, rest (admin), tests
>Affects Versions: 1.15.0
>Reporter: Udo Kohlmeyer
>Priority: Minor
> Labels: needsTriage
>
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> is failing with unexpected log entries.
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2671
> {code:java}
> DeploymentManagementRedployDUnitTest >
> hotDeployShouldNotResultInAnyFailedFunctionExecutions FAILED
> 01:44:15java.lang.AssertionError: Suspicious strings were written to the
> log during this run.
> 01:44:15Fix the strings or use IgnoredException.addIgnoredException to
> ignore.
> 01:44:15
> ---
> 01:44:15Found suspect string in 'dunit_suspect-vm0.log' at line 531
> 01:44:15
> 01:44:15
> PK{}?T)???DeployCommandRedeployDUnitFunctionA.class???n?@??IhChh?:??Bp+B??E
>
> EP5P$n??J?r?h?F?g???P9?? 01:44:15??`?2??G??%%?^
> 01:44:15O?C
> 01:44:15
> ??i?.w?Y???M??y;???Kdl??8u1???OZB#??k?-Nay0=??7??N+?5?^??)???*Er:F?c4]I}N?+?o???5zR?H?i?[X???[l?#?P??#??eN!:?
>
> v?v??u?2?W?r?$?Kqu??YnS??+V}E.???j-?{?7PK??4|'?=???PK??{}?T4|'?=???)?DeployCommandRedeployDUnitFunctionA.classPK??[???j?
> 01:44:15--cvFOdAqPh74YsEftzj4GE_lSmdgeMggm6mUZS8E
> 01:44:15Content-Disposition: form-data; name="config"
> 01:44:15Content-Type: application/json
> 01:44:15
> 01:44:15
> ---
> 01:44:15Found suspect string in 'dunit_suspect-vm0.log' at line 550
> 01:44:15
> 01:44:15
> PK{}?T)???DeployCommandRedeployDUnitFunctionA.class???n?@??IhChh?:???p+B??E
>
> EP5P$n??J?r?h?F?g???P9?? 01:44:15??`?2??G??%%?^
> 01:44:15O?C
> 01:44:15
> ??i?.w?Y???M??y;???Kdl??8u1???OZB#??k?-Nay0=??7??N+?5?^??)???*Er:F?c4]I}N?+?o???5zR?H?i?[X???[l?#?P??#??eN!:?
>
> v?v??u?2?W?r?$?Kqu??YnS??+V}E.???j-?{?7PK??=???PK??{}?T=???)?DeployCommandRedeployDUnitFunctionA.classPK??[???j?
> 01:44:15---UjSGLHVgaMcjtjM7IJfWJ3fPZEhjOGN
> 01:44:15Content-Disposition: form-data; name="config"
> 01:44:15Content-Type: application/json {code}
> In order to resolve this issue the ManagementLoggingFilter needs to be a
> little more discriminant on what it logs out, as it currently is serializing
> the jar file contents as a String, which is causing this issue.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-8983) CI Failure: DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
[
https://issues.apache.org/jira/browse/GEODE-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550693#comment-17550693
]
Udo Kohlmeyer commented on GEODE-8983:
--
created https://issues.apache.org/jira/browse/GEODE-10364 to track the new issue
> CI Failure:
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> --
>
> Key: GEODE-8983
> URL: https://issues.apache.org/jira/browse/GEODE-8983
> Project: Geode
> Issue Type: Bug
> Components: functions, management
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Udo Kohlmeyer
>Priority: Minor
>
> {noformat}
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest
> > hotDeployShouldNotResultInAnyFailedFunctionExecutions FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest$$Lambda$422/0x00010059f840.run
> in VM 1 running on Host 91f54af25dd2 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> at
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions(DeploymentManagementRedployDUnitTest.java:184)
> Caused by:
> org.apache.geode.cache.execute.FunctionException: Function named
> DeployCommandRedeployDUnitFunctionA is not registered to FunctionService
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614547395/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614547395/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
> This failure was also seen in a previous run, along with an instance of
> GEODE-8984. Artifacts for that failure can be found here:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614538872/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614538872/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10364) DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
Udo Kohlmeyer created GEODE-10364:
-
Summary:
DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
Key: GEODE-10364
URL: https://issues.apache.org/jira/browse/GEODE-10364
Project: Geode
Issue Type: Bug
Components: management
Affects Versions: 1.15.0
Reporter: Udo Kohlmeyer
DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
is failing with unexpected log entries.
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/2671
{code:java}
DeploymentManagementRedployDUnitTest >
hotDeployShouldNotResultInAnyFailedFunctionExecutions FAILED
01:44:15java.lang.AssertionError: Suspicious strings were written to the
log during this run.
01:44:15Fix the strings or use IgnoredException.addIgnoredException to
ignore.
01:44:15
---
01:44:15Found suspect string in 'dunit_suspect-vm0.log' at line 531
01:44:15
01:44:15
PK{}?T)???DeployCommandRedeployDUnitFunctionA.class???n?@??IhChh?:??Bp+B??E
EP5P$n??J?r?h?F?g???P9??
[jira] [Commented] (GEODE-8983) CI Failure: DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
[
https://issues.apache.org/jira/browse/GEODE-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550692#comment-17550692
]
Udo Kohlmeyer commented on GEODE-8983:
--
Seems the fuzzy logic has picked the wrong ticket to assign a failure to. The
above failures are not caused by the issue this ticket was opened for.
> CI Failure:
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> --
>
> Key: GEODE-8983
> URL: https://issues.apache.org/jira/browse/GEODE-8983
> Project: Geode
> Issue Type: Bug
> Components: functions, management
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Udo Kohlmeyer
>Priority: Minor
>
> {noformat}
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest
> > hotDeployShouldNotResultInAnyFailedFunctionExecutions FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest$$Lambda$422/0x00010059f840.run
> in VM 1 running on Host 91f54af25dd2 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> at
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions(DeploymentManagementRedployDUnitTest.java:184)
> Caused by:
> org.apache.geode.cache.execute.FunctionException: Function named
> DeployCommandRedeployDUnitFunctionA is not registered to FunctionService
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614547395/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614547395/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
> This failure was also seen in a previous run, along with an instance of
> GEODE-8984. Artifacts for that failure can be found here:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614538872/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614538872/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-8983) CI Failure: DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
[
https://issues.apache.org/jira/browse/GEODE-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer resolved GEODE-8983.
--
Resolution: Fixed
> CI Failure:
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> --
>
> Key: GEODE-8983
> URL: https://issues.apache.org/jira/browse/GEODE-8983
> Project: Geode
> Issue Type: Bug
> Components: functions, management
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Udo Kohlmeyer
>Priority: Minor
>
> {noformat}
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest
> > hotDeployShouldNotResultInAnyFailedFunctionExecutions FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest$$Lambda$422/0x00010059f840.run
> in VM 1 running on Host 91f54af25dd2 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> at
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions(DeploymentManagementRedployDUnitTest.java:184)
> Caused by:
> org.apache.geode.cache.execute.FunctionException: Function named
> DeployCommandRedeployDUnitFunctionA is not registered to FunctionService
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614547395/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614547395/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
> This failure was also seen in a previous run, along with an instance of
> GEODE-8984. Artifacts for that failure can be found here:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614538872/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614538872/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-8983) CI Failure: DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
[
https://issues.apache.org/jira/browse/GEODE-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-8983:
-
Labels: (was: pull-request-available)
> CI Failure:
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> --
>
> Key: GEODE-8983
> URL: https://issues.apache.org/jira/browse/GEODE-8983
> Project: Geode
> Issue Type: Bug
> Components: functions, management
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Udo Kohlmeyer
>Priority: Minor
>
> {noformat}
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest
> > hotDeployShouldNotResultInAnyFailedFunctionExecutions FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest$$Lambda$422/0x00010059f840.run
> in VM 1 running on Host 91f54af25dd2 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> at
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions(DeploymentManagementRedployDUnitTest.java:184)
> Caused by:
> org.apache.geode.cache.execute.FunctionException: Function named
> DeployCommandRedeployDUnitFunctionA is not registered to FunctionService
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614547395/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614547395/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
> This failure was also seen in a previous run, along with an instance of
> GEODE-8984. Artifacts for that failure can be found here:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614538872/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614538872/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (GEODE-8983) CI Failure: DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
[
https://issues.apache.org/jira/browse/GEODE-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-8983:
-
Priority: Minor (was: Major)
> CI Failure:
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> --
>
> Key: GEODE-8983
> URL: https://issues.apache.org/jira/browse/GEODE-8983
> Project: Geode
> Issue Type: Bug
> Components: functions, management
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Udo Kohlmeyer
>Priority: Minor
> Labels: pull-request-available
>
> {noformat}
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest
> > hotDeployShouldNotResultInAnyFailedFunctionExecutions FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest$$Lambda$422/0x00010059f840.run
> in VM 1 running on Host 91f54af25dd2 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> at
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions(DeploymentManagementRedployDUnitTest.java:184)
> Caused by:
> org.apache.geode.cache.execute.FunctionException: Function named
> DeployCommandRedeployDUnitFunctionA is not registered to FunctionService
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614547395/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614547395/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
> This failure was also seen in a previous run, along with an instance of
> GEODE-8984. Artifacts for that failure can be found here:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614538872/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614538872/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (GEODE-8983) CI Failure: DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
[ https://issues.apache.org/jira/browse/GEODE-8983 ]
Udo Kohlmeyer deleted comment on GEODE-8983:
--
was (Author: ukohlmeyer):
dropping severity on this bug. Given that the problem has to do with the
content that is being logged out (logging the jar file bytes) into the log.
This is causing the DUnit's log watcher to be upset.
> CI Failure:
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> --
>
> Key: GEODE-8983
> URL: https://issues.apache.org/jira/browse/GEODE-8983
> Project: Geode
> Issue Type: Bug
> Components: functions, management
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Udo Kohlmeyer
>Priority: Minor
>
> {noformat}
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest
> > hotDeployShouldNotResultInAnyFailedFunctionExecutions FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest$$Lambda$422/0x00010059f840.run
> in VM 1 running on Host 91f54af25dd2 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> at
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions(DeploymentManagementRedployDUnitTest.java:184)
> Caused by:
> org.apache.geode.cache.execute.FunctionException: Function named
> DeployCommandRedeployDUnitFunctionA is not registered to FunctionService
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614547395/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614547395/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
> This failure was also seen in a previous run, along with an instance of
> GEODE-8984. Artifacts for that failure can be found here:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614538872/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614538872/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-8983) CI Failure: DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
[
https://issues.apache.org/jira/browse/GEODE-8983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17550691#comment-17550691
]
Udo Kohlmeyer commented on GEODE-8983:
--
dropping severity on this bug. Given that the problem has to do with the
content that is being logged out (logging the jar file bytes) into the log.
This is causing the DUnit's log watcher to be upset.
> CI Failure:
> DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions
> --
>
> Key: GEODE-8983
> URL: https://issues.apache.org/jira/browse/GEODE-8983
> Project: Geode
> Issue Type: Bug
> Components: functions, management
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Udo Kohlmeyer
>Priority: Major
> Labels: pull-request-available
>
> {noformat}
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest
> > hotDeployShouldNotResultInAnyFailedFunctionExecutions FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest$$Lambda$422/0x00010059f840.run
> in VM 1 running on Host 91f54af25dd2 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:94)
> at
> org.apache.geode.management.internal.rest.DeploymentManagementRedployDUnitTest.hotDeployShouldNotResultInAnyFailedFunctionExecutions(DeploymentManagementRedployDUnitTest.java:184)
> Caused by:
> org.apache.geode.cache.execute.FunctionException: Function named
> DeployCommandRedeployDUnitFunctionA is not registered to FunctionService
> 371 tests completed, 1 failed
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614547395/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614547395/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
> This failure was also seen in a previous run, along with an instance of
> GEODE-8984. Artifacts for that failure can be found here:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-results/distributedTest/1614538872/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.0021/test-artifacts/1614538872/distributedtestfiles-OpenJDK11-1.15.0-build.0021.tgz
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17511525#comment-17511525
]
Udo Kohlmeyer commented on GEODE-10045:
---
relates to https://issues.apache.org/jira/browse/GEODE-10159
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10045:
--
Issue Type: Improvement (was: Bug)
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10045:
--
Labels: Micrometer (was: Micrometer blocks-1.15.0)
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10045:
--
Parent: (was: GEODE-10003)
Issue Type: Bug (was: Sub-task)
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Major
> Labels: Micrometer, blocks-1.15.0
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0, Spring Boot 3.0 and the rest of the Spring portfolio, 1 of the new and
> major topics is Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10159) Upgrade to Micrometer 1.9
Udo Kohlmeyer created GEODE-10159: - Summary: Upgrade to Micrometer 1.9 Key: GEODE-10159 URL: https://issues.apache.org/jira/browse/GEODE-10159 Project: Geode Issue Type: Sub-task Components: statistics Reporter: Udo Kohlmeyer Micrometer 2.x introduces a new set of issues: * Not being released in time for 9.15 * Package name restructuring * External public API's directly exposing the Micrometer classes, need to be updated, and in so any external projects depending the exposed API In order to avoid this revolutionary change from Micrometer 1.x -> 2.x, Micrometer is releasing 1.9 version that will be the bridge between 1.x and 2.x. Spring Data Geode has already tested that updating to this version resolves the issues that it has when integrating with Spring Boot 3.0, and deems this version to be good. Micrometer 1.9 has not made GA yet, but it is expected to be released around May, given that Spring Boot 2.7 is dependent on Micrometer 1.9, and is scheduled to be released in the May time frame. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10045) Upgrade to Micrometer 2.0
[
https://issues.apache.org/jira/browse/GEODE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10045:
--
Parent: GEODE-10003
Issue Type: Sub-task (was: Improvement)
> Upgrade to Micrometer 2.0
> -
>
> Key: GEODE-10045
> URL: https://issues.apache.org/jira/browse/GEODE-10045
> Project: Geode
> Issue Type: Sub-task
> Components: core
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Blocker
> Labels: Micrometer
>
> As part of the ongoing story and themes in Spring Framework 6, Spring Data
> 3.0 and the rest of the Spring portfolio, 1 of the new and major topics is
> Observability (Monitoring with Metrics, Tracing, and so on).
> As part of that effort, Micrometer is undergoing a major revision change from
> 1.x to 2.0. Many of their APIs have changed, and as a result, Apache Geode
> no longer runs (or even will build) with Micrometer 2.0.
> Either Micrometer should be upgraded to 2.0 (most likely in the next major
> version of Geode, i.e. 2.0) or Micrometer should be an optional dependency,
> perhaps only enabled when Micrometer is on the classpath.
> Still a cleaner separation is needed if [Spring] Apache Geode users require
> and use a newer version of Micrometer (e.g. 2.0) and Apache Geode remains on
> Micrometer 1.x (currently
> [1.6.3|https://github.com/apache/geode/blob/rel/v1.14.3/boms/geode-all-bom/src/test/resources/expected-pom.xml#L226-L231]
> in Apache Geode {{1.14.3}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10007) Make o.a.geode.cache.internal.HttpService SPI part of the non-internal, public API
[
https://issues.apache.org/jira/browse/GEODE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10007:
--
Parent: GEODE-10003
Issue Type: Sub-task (was: Improvement)
> Make o.a.geode.cache.internal.HttpService SPI part of the non-internal,
> public API
> --
>
> Key: GEODE-10007
> URL: https://issues.apache.org/jira/browse/GEODE-10007
> Project: Geode
> Issue Type: Sub-task
>Reporter: John Blum
>Priority: Minor
>
> The {{HttpService}} interface is defined and used as a _Service Provider
> Interface_ (SPI) inside Apache Geode and even loaded as such using the _Java_
> {{ServerLoader}}
> ([Javadoc|https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/ServiceLoader.html])
> class in order to locate and load provider implementations.
> An SPI is not much good if "providers" are not allowed to "provide" an
> implementation of the service interfaces used to extend or customize Apache
> Geode. This allows any application, framework, tool or product a degree of
> extensibility and flexibility, afforded to users without intervention, by
> being able to "provide" a custom implementation or extension as needed by the
> application, framework, tool or product.
> 1 such example would be to be able to supply a Jakarta EE 9 (spec) compliant
> implementation of an embedded HTTP server (e.g. Jetty, Tomcat or even
> Undertow) used by Geode to bootstrap the embedded HTTP service hosting the
> Geode provided Web apps (e.g. Pulse, Management/Admin REST API, Developer
> REST API) when external hosting is not an option. Of course, these Web apps
> need to be updated as well (to use the new Jakarta EE 9 specs).
> There are other examples of SPIs used in Apache Geode, which are part of the
> non-internal, public API.
> For example, the
> [ServerLaucherCacheProvider|https://geode.apache.org/releases/latest/javadoc/org/apache/geode/distributed/ServerLauncherCacheProvider.html]
> interface, with 1 such
> [implementation|https://docs.spring.io/spring-data/geode/docs/current/api/org/springframework/data/gemfire/support/SpringServerLauncherCacheProvider.html]
> provided by _Spring Data for Apache Geode_ (SDG) even.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9657) Javadoc errors occur on Java 17 due to split packages in Geode
[
https://issues.apache.org/jira/browse/GEODE-9657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-9657:
-
Parent: GEODE-10003
Issue Type: Sub-task (was: Bug)
> Javadoc errors occur on Java 17 due to split packages in Geode
> --
>
> Key: GEODE-9657
> URL: https://issues.apache.org/jira/browse/GEODE-9657
> Project: Geode
> Issue Type: Sub-task
> Components: core
>Affects Versions: 1.13.4, 1.14.0
>Reporter: John Blum
>Priority: Major
>
> When trying to build any library, framework (e.g. _Spring Data for Apache
> Geode_ (SDG)) or application with Apache Geode on Java 17, Javadoc errors
> occur.
> For example:
> {code}
> 22:36:52 [ERROR]
> /opt/jenkins/data/workspace/spring-data-geode_3.0.x/spring-data-geode/src/main/java/org/springframework/data/gemfire/function/PojoFunctionWrapper.java:53:
> error: cannot access Identifiable
> 22:36:52 [ERROR] public class PojoFunctionWrapper implements Function {
> 22:36:52 [ERROR]^
> 22:36:52 [ERROR] class file for org.apache.geode.lang.Identifiable not
> found
> {code}
> As it turns out, in Java 17, the _Javadoc_ tool now uses _Java_ modules.
> _Javadoc_ is started with:
> {code}
> javadoc … --add-modules ALL-MODULE-PATH --module-path --patch-module …
> {code}
> {{geode-core-1.14.0.jar}} ships
> {{org.apache.geode.lang.AttachAPINotFoundException}} and
> {{geode-common-1.14.0.jar}} ships {{org.apache.geode.lang.Identifiable}}. Due
> to this split-package arrangement, _Javadoc_ isn’t discovering
> {{Identifiable}} because it has found the package {{org.apache.geode.lang}}
> in {{geode-core-1.14.0.jar}}.
> The best course of action is to make sure all {{org.apache.geode.lang}}
> sub-packages and class are in 1 JAR (e.g. {{geode-common}}) or the other
> (i.e. {{geode-core}}).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10036) Joining Locators in a cluster is not possible on Java 17
[
https://issues.apache.org/jira/browse/GEODE-10036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10036:
--
Parent: GEODE-10003
Issue Type: Sub-task (was: Bug)
> Joining Locators in a cluster is not possible on Java 17
>
>
> Key: GEODE-10036
> URL: https://issues.apache.org/jira/browse/GEODE-10036
> Project: Geode
> Issue Type: Sub-task
>Affects Versions: 1.14.3
>Reporter: John Blum
>Priority: Critical
> Labels: needsTriage
>
> When trying to add multiple _Locators_ to the same cluster, particularly when
> "_direct_" {{ByteBuffers}} are used, the following Exception is thrown:
> {code:java}
> Caused by: org.apache.geode.SystemConnectException: One or more peers
> generated exceptions during connection attempt
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1634)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:361)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:756)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:132)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3011)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:282)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:746)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:392)
> at
> org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:716)
> at
> org.springframework.data.gemfire.LocatorFactoryBean.init(LocatorFactoryBean.java:120)
> ... 44 more
> Caused by: org.apache.geode.InternalGemFireException: unable to retrieve
> underlying byte buffer
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:346)
> at
> org.apache.geode.internal.net.BufferPool.releaseBuffer(BufferPool.java:310)
> at
> org.apache.geode.internal.net.BufferPool.releaseSenderBuffer(BufferPool.java:213)
> at
> org.apache.geode.internal.tcp.MsgStreamer.release(MsgStreamer.java:101)
> at
> org.apache.geode.internal.tcp.MsgStreamer.writeMessage(MsgStreamer.java:258)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:318)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:187)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:525)
> at
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:348)
> at
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:293)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2064)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1991)
> at
> org.apache.geode.distributed.internal.StartupOperation.sendStartupMessage(StartupOperation.java:75)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendStartupMessage(ClusterDistributionManager.java:1631)
> ... 56 more
> Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make
> public java.lang.Object java.nio.DirectByteBuffer.attachment() accessible:
> module java.base does not "opens java.nio" to unnamed module @2e0fa5d3
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)
> at
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
> at
> java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:199)
> at java.base/java.lang.reflect.Method.setAccessible(Method.java:193)
> at
> org.apache.geode.internal.net.BufferPool.getPoolableBuffer(BufferPool.java:343)
> ... 69 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9393) Apache Geode does not build/run on Java 16/17
[
https://issues.apache.org/jira/browse/GEODE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-9393:
-
Parent: GEODE-10003
Issue Type: Sub-task (was: Improvement)
> Apache Geode does not build/run on Java 16/17
> -
>
> Key: GEODE-9393
> URL: https://issues.apache.org/jira/browse/GEODE-9393
> Project: Geode
> Issue Type: Sub-task
> Components: core
>Affects Versions: 1.13.2
>Reporter: John Blum
>Priority: Blocker
> Labels: Java16, Java17
>
> 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
>
[jira] [Updated] (GEODE-9393) Apache Geode does not build/run on Java 16/17
[
https://issues.apache.org/jira/browse/GEODE-9393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-9393:
-
Labels: Java16 Java17 (was: Java16)
> Apache Geode does not build/run on Java 16/17
> -
>
> 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, Java17
>
> 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
>
[jira] [Created] (GEODE-10071) Remove the dependency that WanCopyRegionFunction has on WanCopyRegionCommand
Udo Kohlmeyer created GEODE-10071: - Summary: Remove the dependency that WanCopyRegionFunction has on WanCopyRegionCommand Key: GEODE-10071 URL: https://issues.apache.org/jira/browse/GEODE-10071 Project: Geode Issue Type: Improvement Components: wan Affects Versions: 1.15.0, 1.16.0 Reporter: Udo Kohlmeyer There is a cyclical dependency between the Command and the implementing function for the Wan copy feature. Logically, the command needs to have a dependency on the function. The error messages currently defined in the Command class need to be moved to the function class where they are used. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10070) Add method onto InternalGatewaySender to send batch
Udo Kohlmeyer created GEODE-10070: - Summary: Add method onto InternalGatewaySender to send batch Key: GEODE-10070 URL: https://issues.apache.org/jira/browse/GEODE-10070 Project: Geode Issue Type: Improvement Components: wan Affects Versions: 1.15.0, 1.16.0 Reporter: Udo Kohlmeyer In the current Wan Copy feature, the `WanCopyRegionFunctionDelegate` has to: # Create a ConnectionState # retrieve the GatewaySenderEventDispatcher off the AbstractGatewaySender # Send batch and handle all exception handling related to the sending of a batch This functionality is really something that needs to be consolidated into a single location for reuse. Having the ability to get into guts of the system to send batches and possibly affect how errors are handled in an inconsistent manner (in comparison to the normal GatewaySender flow) can lead to many problems. Not exposing the sendBatch logic and complexity would be much simpler and more consistent in behavior. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10069) WanCopyRegionCommand currently targets all members in cluster
Udo Kohlmeyer created GEODE-10069: - Summary: WanCopyRegionCommand currently targets all members in cluster Key: GEODE-10069 URL: https://issues.apache.org/jira/browse/GEODE-10069 Project: Geode Issue Type: Improvement Components: wan Affects Versions: 1.15.0, 1.16.0 Reporter: Udo Kohlmeyer The current implementation of `WanCopyRegionCommand` will execute on all members. This could possibly be improved by targeting a single member, which then has the ability to determine if the wan copy functionality needs to run on a single member (in the case of Replicate regions) or across multiple members (in the case of Partitioned Regions). In addition, initiating function also has the ability to invoke the function using `onRegion` which then allows for the targeting of primary data only vs the current implementation which (perceivably) targets primary and redundant bucket data -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10068) Make WanCopyRegionFunctionService thread pool configurable through configuration or property
Udo Kohlmeyer created GEODE-10068: - Summary: Make WanCopyRegionFunctionService thread pool configurable through configuration or property Key: GEODE-10068 URL: https://issues.apache.org/jira/browse/GEODE-10068 Project: Geode Issue Type: Improvement Components: wan Affects Versions: 1.15.0, 1.16.0 Reporter: Udo Kohlmeyer The current implementation of `WanCopyRegionFunctionService` creates a fixed thread pool of size 10. This is possibly something that one would like to be able to configure. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10067) WANCopyRegionFunctionDelegate needs to be optimized to handle large regions
Udo Kohlmeyer created GEODE-10067: - Summary: WANCopyRegionFunctionDelegate needs to be optimized to handle large regions Key: GEODE-10067 URL: https://issues.apache.org/jira/browse/GEODE-10067 Project: Geode Issue Type: Improvement Components: wan Affects Versions: 1.15.0, 1.16.0 Reporter: Udo Kohlmeyer The current WanCopyRegionFunctionDelegate may cause significant memory issues in with really large regions. The [getEntries|https://github.com/apache/geode/blob/develop/geode-wan/src/main/java/org/apache/geode/management/internal/cli/functions/WanCopyRegionFunctionDelegate.java#L102] method returns both primary and redundant Region Entries for local server. The invocation of getEntries from the PartitionedRegionDataStore will cause all entries to be deserialized https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/PartitionedRegionDataStore.java#L2501-L2515 The [createBatch|https://github.com/apache/geode/blob/develop/geode-wan/src/main/java/org/apache/geode/management/internal/cli/functions/WanCopyRegionFunctionDelegate.java#L107-L108] method creates a List equally that of the local Region size. Essentially ... In a system with VERY large regions this might cause significant memory issues -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9859) Mass-Test-Run: WanCopyRegionCommandDUnitTest.testRegionDestroyedDuringExecution(false, false) [0] FAILED
[
https://issues.apache.org/jira/browse/GEODE-9859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-9859:
-
Labels: pull-request-available (was: needsTriage pull-request-available)
> Mass-Test-Run:
> WanCopyRegionCommandDUnitTest.testRegionDestroyedDuringExecution(false,
> false) [0] FAILED
>
>
> Key: GEODE-9859
> URL: https://issues.apache.org/jira/browse/GEODE-9859
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Assignee: Alberto Gomez
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> Looks like this might be failing from the original PR. I have linked to
> GEODE-9369 as the most likely origination.
>
> {noformat}
> WanCopyRegionCommandDUnitTest > testRegionDestroyedDuringExecution(false,
> false) [0] FAILED
> java.lang.AssertionError:
> Expecting elements:
> ["Execution failed. Error:
> org.apache.geode.cache.EntryDestroyedException: 937"]
> to have exactly 1 times execution error
> at
> org.apache.geode.cache.wan.internal.cli.commands.WanCopyRegionCommandDUnitTest.testRegionDestroyedDuringExecution(WanCopyRegionCommandDUnitTest.java:450)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9984) Mass-Test-Run: WanCopyRegionCommandDUnitTest > testCommandDoesNotCopyEntriesUpdatedAfterCommandStarted FAILED
[ https://issues.apache.org/jira/browse/GEODE-9984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-9984: - Labels: flaky-test pull-request-available (was: needsTriage pull-request-available) > Mass-Test-Run: WanCopyRegionCommandDUnitTest > > testCommandDoesNotCopyEntriesUpdatedAfterCommandStarted FAILED > - > > Key: GEODE-9984 > URL: https://issues.apache.org/jira/browse/GEODE-9984 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Kristen >Assignee: Alberto Gomez >Priority: Major > Labels: flaky-test, pull-request-available > > WanCopyRegionCommandDUnitTest > > testCommandDoesNotCopyEntriesUpdatedAfterCommandStarted(true, true) [0] FAILED > org.opentest4j.AssertionFailedError: > expected: 5 > but was: 50001 > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.cache.wan.internal.cli.commands.WanCopyRegionCommandDUnitTest.testCommandDoesNotCopyEntriesUpdatedAfterCommandStarted(WanCopyRegionCommandDUnitTest.java:884) > 948 tests completed, 1 failed, 59 skipped > Test report artifacts from this job are available at: > [*http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.15.0-build.0806/test-artifacts/1642850654/distributedtestfiles-openjdk8-1.15.0-build.0806.tgz*] > > > > May be an issue similar or related to > https://issues.apache.org/jira/browse/GEODE-9859. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-8705) Using JBoss Modules to implement classloader isolated jar deployment
[ https://issues.apache.org/jira/browse/GEODE-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-8705: - Description: Introduce Classloader isolation into Geode, to avoid the potential conflict of custom code dependencies, from deploy jar, and the dependencies of the Geode system. This problem because evident when Geode was still dependent on Spring framework 4.3 and users wanted to deploy custom jars that used Spring framework 5. This caused many library version conflicts. This problem is not limited to the usage of Spring in the system but to ANY dependent library that Geode and any potential custom jar would use. The end goal is to have a system that is Classloader isolated and allows for the usage of libraries of different versions within the Geode without any conflicts. See RFC [https://cwiki.apache.org/confluence/display/GEODE/ClassLoader+Isolation] for further details was: Introduce Classloader isolation into Geode, to avoid the potential conflict of custom code dependencies, from deploy jar, and the dependencies of the Geode system. This problem because evident when Geode was still dependent on Spring framework 4.3 and users wanted to deploy custom jars that used Spring framework 5. This caused many library version conflicts. This problem is not limited to the usage of Spring in the system but to ANY dependent library that Geode and any potential custom jar would use. The end goal is to have a system that is Classloader isolated and allows for the usage of libraries of different versions within the Geode without any conflicts. > Using JBoss Modules to implement classloader isolated jar deployment > > > Key: GEODE-8705 > URL: https://issues.apache.org/jira/browse/GEODE-8705 > Project: Geode > Issue Type: New Feature >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > Introduce Classloader isolation into Geode, to avoid the potential conflict > of custom code dependencies, from deploy jar, and the dependencies of the > Geode system. > This problem because evident when Geode was still dependent on Spring > framework 4.3 and users wanted to deploy custom jars that used Spring > framework 5. This caused many library version conflicts. > This problem is not limited to the usage of Spring in the system but to ANY > dependent library that Geode and any potential custom jar would use. > The end goal is to have a system that is Classloader isolated and allows for > the usage of libraries of different versions within the Geode without any > conflicts. > > See RFC > [https://cwiki.apache.org/confluence/display/GEODE/ClassLoader+Isolation] for > further details -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (GEODE-8705) Using JBoss Modules to implement classloader isolated jar deployment
[
https://issues.apache.org/jira/browse/GEODE-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491783#comment-17491783
]
Udo Kohlmeyer edited comment on GEODE-8705 at 2/14/22, 4:10 AM:
The new ClassLoader isolation will be accomplished by using JBoss Modules. In
order to make sure that the modular environment is correctly bootstrapped, it
needs to be the first thing that is bootstrapped. To achieve this, the current
approach to start the system, with all library dependencies declared on the
root Classloader, will be replaced with the newer approach, which only has the
jboss-modules library and a library which provides a custom ModuleLoader (a
JBoss Modules construct) as the Boot Module loader for JBoss Modules.
The new bootstrapping mechanism will also require a module.xml file to
bootstrap the modules. In the current implementation there is one module.xml
file that describes all the libraries, main class (entry class) and
import/export restrictions of classes/packages.
In order to avoid significant changes, the current approach (even if
bootstrapped through org.jboss.modules.Main) takes the same command line
parameters that one would pass to the Locator/Server Launcher. The Main class
from JBoss modules just acts as a pass through and passes through all
parameters to the main classes defined in the module.xml file. (in this case
ServerLauncher).
There is a current project structure for deployment:
* geode-deployment-acceptence (Acceptence tests to ensure that no
functionality is broken between the two classloader mechanisms)
* geode-deployment-jboss-modules - JBoss modules classloader implementation
* geode-deployment-chained-classloader - Previous classloader implementation
* geode-deployment-test - Test project to create a Spring project that uses
conflicting libraries to main project
* geode-jboss-extensions - Project to provide extensions to the JBoss Modules
framework, that needs to be on the root Classloader.
In order to minimize the module.xml maintenance, a Gradle Plugin has been
written to generate the module.xml file from the gradle dependencies.
Also, to limit the initial scope of the Classloader isolation, Classloader
isolation will only be available if you start a Locator or Server when they are
started through {_}gfsh{_}. Using the "{_}--enable-classloader-isolation{_}"
flag will start the component as either classloader isolated or default
classloader mechanism.
was (Author: ukohlmeyer):
The new ClassLoader isolation will be accomplished by using JBoss Modules. In
order to make sure that the modular environment is correctly bootstrapped, it
needs to be the first thing that is bootstrapped. To achieve this, the current
approach to start the system, with all library dependencies declared on the
root Classloader, will be replaced with the newer approach, which only has the
jboss-modules library and a library which provides a custom ModuleLoader (a
JBoss Modules construct) as the Boot Module loader for JBoss Modules.
The new bootstrapping mechanism will also require a module.xml file to
bootstrap the modules. In the current implementation there is one module.xml
file that describes all the libraries, main class (entry class) and
import/export restrictions of classes/packages.
In order to avoid significant changes, the current approach (even if
bootstrapped through org.jboss.modules.Main) takes the same command line
parameters that one would pass to the Locator/Server Launcher. The Main class
from JBoss modules just acts as a pass through and passes through all
parameters to the main classes defined in the module.xml file. (in this case
ServerLauncher).
There is a current project structure for deployment:
* geode-deployment-acceptence (Acceptence tests to ensure that no
functionality is broken between the two classloader mechanisms)
* geode-deployment-jboss-modules - JBoss modules classloader implementation
* geode-deployment-chained-classloader - Previous classloader implementation
* geode-deployment-test - Test project to create a Spring project that uses
conflicting libraries to main project
* geode-jboss-extensions - Project to provide extensions to the JBoss Modules
framework, that needs to be on the root Classloader.
In order to minimize the module.xml maintenance, a Gradle Plugin has been
written to generate the module.xml file from the gradle dependencies.
> Using JBoss Modules to implement classloader isolated jar deployment
>
>
> Key: GEODE-8705
> URL: https://issues.apache.org/jira/browse/GEODE-8705
> Project: Geode
> Issue Type: New Feature
>Reporter: Udo Kohlmeyer
>Assignee: Udo Kohlmeyer
>Priority: Major
> Labels: pull-request-available
>
> Introduce
[jira] [Commented] (GEODE-8705) Using JBoss Modules to implement classloader isolated jar deployment
[ https://issues.apache.org/jira/browse/GEODE-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491786#comment-17491786 ] Udo Kohlmeyer commented on GEODE-8705: -- Completed work to complete testing in Hydra in a classloader isolated manner.. > Using JBoss Modules to implement classloader isolated jar deployment > > > Key: GEODE-8705 > URL: https://issues.apache.org/jira/browse/GEODE-8705 > Project: Geode > Issue Type: New Feature >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > Introduce Classloader isolation into Geode, to avoid the potential conflict > of custom code dependencies, from deploy jar, and the dependencies of the > Geode system. > This problem because evident when Geode was still dependent on Spring > framework 4.3 and users wanted to deploy custom jars that used Spring > framework 5. This caused many library version conflicts. > This problem is not limited to the usage of Spring in the system but to ANY > dependent library that Geode and any potential custom jar would use. > The end goal is to have a system that is Classloader isolated and allows for > the usage of libraries of different versions within the Geode without any > conflicts. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-8705) Using JBoss Modules to implement classloader isolated jar deployment
[ https://issues.apache.org/jira/browse/GEODE-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491784#comment-17491784 ] Udo Kohlmeyer commented on GEODE-8705: -- Modified DUnit testing framework to be able to run either Classloader isolated or the default classloader mechanism. > Using JBoss Modules to implement classloader isolated jar deployment > > > Key: GEODE-8705 > URL: https://issues.apache.org/jira/browse/GEODE-8705 > Project: Geode > Issue Type: New Feature >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > Introduce Classloader isolation into Geode, to avoid the potential conflict > of custom code dependencies, from deploy jar, and the dependencies of the > Geode system. > This problem because evident when Geode was still dependent on Spring > framework 4.3 and users wanted to deploy custom jars that used Spring > framework 5. This caused many library version conflicts. > This problem is not limited to the usage of Spring in the system but to ANY > dependent library that Geode and any potential custom jar would use. > The end goal is to have a system that is Classloader isolated and allows for > the usage of libraries of different versions within the Geode without any > conflicts. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-8705) Using JBoss Modules to implement classloader isolated jar deployment
[ https://issues.apache.org/jira/browse/GEODE-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17491783#comment-17491783 ] Udo Kohlmeyer commented on GEODE-8705: -- The new ClassLoader isolation will be accomplished by using JBoss Modules. In order to make sure that the modular environment is correctly bootstrapped, it needs to be the first thing that is bootstrapped. To achieve this, the current approach to start the system, with all library dependencies declared on the root Classloader, will be replaced with the newer approach, which only has the jboss-modules library and a library which provides a custom ModuleLoader (a JBoss Modules construct) as the Boot Module loader for JBoss Modules. The new bootstrapping mechanism will also require a module.xml file to bootstrap the modules. In the current implementation there is one module.xml file that describes all the libraries, main class (entry class) and import/export restrictions of classes/packages. In order to avoid significant changes, the current approach (even if bootstrapped through org.jboss.modules.Main) takes the same command line parameters that one would pass to the Locator/Server Launcher. The Main class from JBoss modules just acts as a pass through and passes through all parameters to the main classes defined in the module.xml file. (in this case ServerLauncher). There is a current project structure for deployment: * geode-deployment-acceptence (Acceptence tests to ensure that no functionality is broken between the two classloader mechanisms) * geode-deployment-jboss-modules - JBoss modules classloader implementation * geode-deployment-chained-classloader - Previous classloader implementation * geode-deployment-test - Test project to create a Spring project that uses conflicting libraries to main project * geode-jboss-extensions - Project to provide extensions to the JBoss Modules framework, that needs to be on the root Classloader. In order to minimize the module.xml maintenance, a Gradle Plugin has been written to generate the module.xml file from the gradle dependencies. > Using JBoss Modules to implement classloader isolated jar deployment > > > Key: GEODE-8705 > URL: https://issues.apache.org/jira/browse/GEODE-8705 > Project: Geode > Issue Type: New Feature >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > Introduce Classloader isolation into Geode, to avoid the potential conflict > of custom code dependencies, from deploy jar, and the dependencies of the > Geode system. > This problem because evident when Geode was still dependent on Spring > framework 4.3 and users wanted to deploy custom jars that used Spring > framework 5. This caused many library version conflicts. > This problem is not limited to the usage of Spring in the system but to ANY > dependent library that Geode and any potential custom jar would use. > The end goal is to have a system that is Classloader isolated and allows for > the usage of libraries of different versions within the Geode without any > conflicts. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-8705) Using JBoss Modules to implement classloader isolated jar deployment
[ https://issues.apache.org/jira/browse/GEODE-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-8705: - Description: Introduce Classloader isolation into Geode, to avoid the potential conflict of custom code dependencies, from deploy jar, and the dependencies of the Geode system. This problem because evident when Geode was still dependent on Spring framework 4.3 and users wanted to deploy custom jars that used Spring framework 5. This caused many library version conflicts. This problem is not limited to the usage of Spring in the system but to ANY dependent library that Geode and any potential custom jar would use. The end goal is to have a system that is Classloader isolated and allows for the usage of libraries of different versions within the Geode without any conflicts. was: In order to convert the current ClassLoader Isolation work to use `java -jar jboss-modules` one would like to have `module.xml` files that standard jboss-modules knows how to handle. > Using JBoss Modules to implement classloader isolated jar deployment > > > Key: GEODE-8705 > URL: https://issues.apache.org/jira/browse/GEODE-8705 > Project: Geode > Issue Type: New Feature >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > Introduce Classloader isolation into Geode, to avoid the potential conflict > of custom code dependencies, from deploy jar, and the dependencies of the > Geode system. > This problem because evident when Geode was still dependent on Spring > framework 4.3 and users wanted to deploy custom jars that used Spring > framework 5. This caused many library version conflicts. > This problem is not limited to the usage of Spring in the system but to ANY > dependent library that Geode and any potential custom jar would use. > The end goal is to have a system that is Classloader isolated and allows for > the usage of libraries of different versions within the Geode without any > conflicts. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-8705) Using JBoss Modules to implement classloader isolated jar deployment
[ https://issues.apache.org/jira/browse/GEODE-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-8705: - Summary: Using JBoss Modules to implement classloader isolated jar deployment (was: Modify java.gradle to generate module.xml as well as the Manifest file) > Using JBoss Modules to implement classloader isolated jar deployment > > > Key: GEODE-8705 > URL: https://issues.apache.org/jira/browse/GEODE-8705 > Project: Geode > Issue Type: New Feature >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > In order to convert the current ClassLoader Isolation work to use `java -jar > jboss-modules` one would like to have `module.xml` files that standard > jboss-modules knows how to handle. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10038) Trying to access the QueryService results in NPE on server restart from deployed Jar
Udo Kohlmeyer created GEODE-10038:
-
Summary: Trying to access the QueryService results in NPE on
server restart from deployed Jar
Key: GEODE-10038
URL: https://issues.apache.org/jira/browse/GEODE-10038
Project: Geode
Issue Type: Bug
Components: functions
Affects Versions: 1.14.3, 1.13.7, 1.12.8, 1.15.0
Reporter: Udo Kohlmeyer
After deploying a jar which contains a Function, restarting the server causes
an NPE.
Using the Function definition of:
{code:java}
public class CustomFunction implements Function {
private GemFireCache cache;
private QueryService queryService;
public CustomFunction() {
this.cache = CacheFactory.getAnyInstance();
this.queryService = cache.getQueryService();
}
{code}
Due to the startup flow
https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1404
the registration of Functions are initialized from cluster configuration
[here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1419].
There is a dependency on the `QueryService` to be available at Function
construction time, but given that the services are only initialized
[here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1435],
the call to the `cache.getQueryService` fails with an NPE
[here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQueryService.java#L116-L117]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10038) Trying to access the QueryService results in NPE on server restart from deployed Jar
[
https://issues.apache.org/jira/browse/GEODE-10038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-10038:
--
Labels: (was: needsTriage)
> Trying to access the QueryService results in NPE on server restart from
> deployed Jar
>
>
> Key: GEODE-10038
> URL: https://issues.apache.org/jira/browse/GEODE-10038
> Project: Geode
> Issue Type: Bug
> Components: functions
>Affects Versions: 1.12.8, 1.13.7, 1.14.3, 1.15.0
>Reporter: Udo Kohlmeyer
>Priority: Major
>
> After deploying a jar which contains a Function, restarting the server causes
> an NPE.
> Using the Function definition of:
> {code:java}
> public class CustomFunction implements Function {
> private GemFireCache cache;
> private QueryService queryService;
> public CustomFunction() {
> this.cache = CacheFactory.getAnyInstance();
> this.queryService = cache.getQueryService();
> }
> {code}
> Due to the startup flow
> https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1404
> the registration of Functions are initialized from cluster configuration
> [here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1419].
> There is a dependency on the `QueryService` to be available at Function
> construction time, but given that the services are only initialized
> [here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1435],
> the call to the `cache.getQueryService` fails with an NPE
> [here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQueryService.java#L116-L117]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10005) Upgrade to Eclipse Jetty 11.0.x
[
https://issues.apache.org/jira/browse/GEODE-10005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17489918#comment-17489918
]
Udo Kohlmeyer commented on GEODE-10005:
---
[~jblum] currently Apache Geode has a baseline of JDK8, from we've not decided
to move from yet. Given that Jetty 10.x and 11.x has a baseline of JDK11, there
is no way for Apache Geode to use the newer Jetty version until we move the JDK
baseline to at least JDK 11+.
> Upgrade to Eclipse Jetty 11.0.x
> ---
>
> Key: GEODE-10005
> URL: https://issues.apache.org/jira/browse/GEODE-10005
> Project: Geode
> Issue Type: Improvement
>Reporter: John Blum
>Priority: Blocker
>
> In order to release _Spring Boot for Apache Geode_ (SBDG) {{2.0}}, based on
> _Spring Boot_ {{3.0}}, the transitive dependency must minimally match _Spring
> Boot's_ minimum [(major.mionr)
> version|https://github.com/spring-projects/spring-boot/blob/v3.0.0-M1/spring-boot-project/spring-boot-dependencies/build.gradle#L645-L651]
> requirement for *Eclipse Jetty*.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9995) GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
[
https://issues.apache.org/jira/browse/GEODE-9995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer reassigned GEODE-9995:
Assignee: Jens Deppe
> GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
> ---
>
> Key: GEODE-9995
> URL: https://issues.apache.org/jira/browse/GEODE-9995
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Assignee: Jens Deppe
>Priority: Major
> Labels: backport, needsTriage, pull-request-available
>
> Seen in a PR pre-checkin run of acceptance tests:
> {code:java}
> GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenRedisEnabled FAILED
> 11:17:56org.opentest4j.AssertionFailedError: [Exit value from process
> started by [9f25fbcaa567203a: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true]]
> 11:17:56expected: 0
> 11:17:56 but was: 1
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:56at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:56at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenRedisEnabled(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:113)
> 11:17:59
> 11:17:59GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenCustomPort FAILED
> 11:17:59org.opentest4j.AssertionFailedError: [Exit value from process
> started by [3159039b25fb45f2: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true
> --J=-Dgemfire.geode-for-redis-port=20001]]
> 11:17:59expected: 0
> 11:17:59 but was: 1
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:59at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:59at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenCustomPort(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:127)
> {code}
> {code:java}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-results/acceptanceTest/1643311601/
> 11:26:56=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56
> 11:26:56Test report artifacts from this job are available at:
> 11:26:56
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-artifacts/1643311601/acceptancetestfiles-geode-pr-7315.tgz
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9995) GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
[
https://issues.apache.org/jira/browse/GEODE-9995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17485014#comment-17485014
]
Udo Kohlmeyer commented on GEODE-9995:
--
assigning to [~jens.deppe], given the submitted PR.
> GeodeRedisServerStartupUsingGfshAcceptanceTest is flaky
> ---
>
> Key: GEODE-9995
> URL: https://issues.apache.org/jira/browse/GEODE-9995
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0, 1.16.0
>Reporter: Donal Evans
>Assignee: Jens Deppe
>Priority: Major
> Labels: backport, needsTriage, pull-request-available
>
> Seen in a PR pre-checkin run of acceptance tests:
> {code:java}
> GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenRedisEnabled FAILED
> 11:17:56org.opentest4j.AssertionFailedError: [Exit value from process
> started by [9f25fbcaa567203a: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true]]
> 11:17:56expected: 0
> 11:17:56 but was: 1
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:56at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:56at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:56at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:56at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenRedisEnabled(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:113)
> 11:17:59
> 11:17:59GeodeRedisServerStartupUsingGfshAcceptanceTest >
> gfshStartsRedisServer_whenCustomPort FAILED
> 11:17:59org.opentest4j.AssertionFailedError: [Exit value from process
> started by [3159039b25fb45f2: gfsh -e start server
> --J=-Dgemfire.geode-for-redis-enabled=true
> --J=-Dgemfire.geode-for-redis-port=20001]]
> 11:17:59expected: 0
> 11:17:59 but was: 1
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> 11:17:59at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> 11:17:59at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:103)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:143)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:152)
> 11:17:59at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:118)
> 11:17:59at
> org.apache.geode.redis.internal.commands.executor.GeodeRedisServerStartupUsingGfshAcceptanceTest.gfshStartsRedisServer_whenCustomPort(GeodeRedisServerStartupUsingGfshAcceptanceTest.java:127)
> {code}
> {code:java}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-results/acceptanceTest/1643311601/
> 11:26:56=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 11:26:56
> 11:26:56Test report artifacts from this job are available at:
> 11:26:56
> 11:26:56http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-7315/test-artifacts/1643311601/acceptancetestfiles-geode-pr-7315.tgz
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-9974) CI: removingGatewayReceiverUsingReplicatedRegionShouldRemoveCacheServerFlagFromProfile FAILED
[ https://issues.apache.org/jira/browse/GEODE-9974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-9974. -- Resolution: Cannot Reproduce > CI: > removingGatewayReceiverUsingReplicatedRegionShouldRemoveCacheServerFlagFromProfile > FAILED > - > > Key: GEODE-9974 > URL: https://issues.apache.org/jira/browse/GEODE-9974 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Kristen >Assignee: Udo Kohlmeyer >Priority: Major > > > Task :geode-wan:distributedTest > GatewayReceiverDUnitTest > > removingGatewayReceiverUsingReplicatedRegionShouldRemoveCacheServerFlagFromProfile > FAILED > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in 'dunit_suspect-vm3.log' at line 673 > [fatal 2022/01/15 02:19:08.273 UTC > tid=88] Possible loss of quorum due to the loss of 1 cache processes: > [heavy-lifter-f3db8ae7-2766-5a80-a4c9-993976bf93f3(887047):49336] > --- > Found suspect string in 'dunit_suspect-vm3.log' at line 675 > [fatal 2022/01/15 02:19:09.275 UTC > tid=88] Membership service failure: Exiting due to possible network partition > event due to loss of 1 cache processes: > [heavy-lifter-f3db8ae7-2766-5a80-a4c9-993976bf93f3(887047):49336] > > org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException: > Exiting due to possible network partition event due to loss of 1 cache > processes: > [heavy-lifter-f3db8ae7-2766-5a80-a4c9-993976bf93f3(887047):49336] > at > org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:1807) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1122) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.access$1300(GMSJoinLeave.java:80) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.prepareAndSendView(GMSJoinLeave.java:2610) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.sendInitialView(GMSJoinLeave.java:2226) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.run(GMSJoinLeave.java:2308) > at org.junit.Assert.fail(Assert.java:89) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:551) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:498) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:481) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at
[jira] [Updated] (GEODE-9974) CI: removingGatewayReceiverUsingReplicatedRegionShouldRemoveCacheServerFlagFromProfile FAILED
[ https://issues.apache.org/jira/browse/GEODE-9974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-9974: - Labels: (was: needsTriage) > CI: > removingGatewayReceiverUsingReplicatedRegionShouldRemoveCacheServerFlagFromProfile > FAILED > - > > Key: GEODE-9974 > URL: https://issues.apache.org/jira/browse/GEODE-9974 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Kristen >Assignee: Udo Kohlmeyer >Priority: Major > > > Task :geode-wan:distributedTest > GatewayReceiverDUnitTest > > removingGatewayReceiverUsingReplicatedRegionShouldRemoveCacheServerFlagFromProfile > FAILED > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in 'dunit_suspect-vm3.log' at line 673 > [fatal 2022/01/15 02:19:08.273 UTC > tid=88] Possible loss of quorum due to the loss of 1 cache processes: > [heavy-lifter-f3db8ae7-2766-5a80-a4c9-993976bf93f3(887047):49336] > --- > Found suspect string in 'dunit_suspect-vm3.log' at line 675 > [fatal 2022/01/15 02:19:09.275 UTC > tid=88] Membership service failure: Exiting due to possible network partition > event due to loss of 1 cache processes: > [heavy-lifter-f3db8ae7-2766-5a80-a4c9-993976bf93f3(887047):49336] > > org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException: > Exiting due to possible network partition event due to loss of 1 cache > processes: > [heavy-lifter-f3db8ae7-2766-5a80-a4c9-993976bf93f3(887047):49336] > at > org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:1807) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1122) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.access$1300(GMSJoinLeave.java:80) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.prepareAndSendView(GMSJoinLeave.java:2610) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.sendInitialView(GMSJoinLeave.java:2226) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.run(GMSJoinLeave.java:2308) > at org.junit.Assert.fail(Assert.java:89) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:551) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:498) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:481) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at
[jira] [Commented] (GEODE-9974) CI: removingGatewayReceiverUsingReplicatedRegionShouldRemoveCacheServerFlagFromProfile FAILED
[ https://issues.apache.org/jira/browse/GEODE-9974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17480785#comment-17480785 ] Udo Kohlmeyer commented on GEODE-9974: -- Looking at this issue, is seems that there could have been an underlying infrastructural issue that occurred. Since the failed run 601, there have been no new failures since then (last run checked [800|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-mass-test-run/jobs/distributed-test-openjdk8/builds/800] > CI: > removingGatewayReceiverUsingReplicatedRegionShouldRemoveCacheServerFlagFromProfile > FAILED > - > > Key: GEODE-9974 > URL: https://issues.apache.org/jira/browse/GEODE-9974 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Kristen >Assignee: Udo Kohlmeyer >Priority: Major > Labels: needsTriage > > > Task :geode-wan:distributedTest > GatewayReceiverDUnitTest > > removingGatewayReceiverUsingReplicatedRegionShouldRemoveCacheServerFlagFromProfile > FAILED > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in 'dunit_suspect-vm3.log' at line 673 > [fatal 2022/01/15 02:19:08.273 UTC > tid=88] Possible loss of quorum due to the loss of 1 cache processes: > [heavy-lifter-f3db8ae7-2766-5a80-a4c9-993976bf93f3(887047):49336] > --- > Found suspect string in 'dunit_suspect-vm3.log' at line 675 > [fatal 2022/01/15 02:19:09.275 UTC > tid=88] Membership service failure: Exiting due to possible network partition > event due to loss of 1 cache processes: > [heavy-lifter-f3db8ae7-2766-5a80-a4c9-993976bf93f3(887047):49336] > > org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException: > Exiting due to possible network partition event due to loss of 1 cache > processes: > [heavy-lifter-f3db8ae7-2766-5a80-a4c9-993976bf93f3(887047):49336] > at > org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:1807) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1122) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.access$1300(GMSJoinLeave.java:80) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.prepareAndSendView(GMSJoinLeave.java:2610) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.sendInitialView(GMSJoinLeave.java:2226) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.run(GMSJoinLeave.java:2308) > at org.junit.Assert.fail(Assert.java:89) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:551) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:498) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:481) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at
[jira] [Assigned] (GEODE-9974) CI: removingGatewayReceiverUsingReplicatedRegionShouldRemoveCacheServerFlagFromProfile FAILED
[ https://issues.apache.org/jira/browse/GEODE-9974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-9974: Assignee: Udo Kohlmeyer > CI: > removingGatewayReceiverUsingReplicatedRegionShouldRemoveCacheServerFlagFromProfile > FAILED > - > > Key: GEODE-9974 > URL: https://issues.apache.org/jira/browse/GEODE-9974 > Project: Geode > Issue Type: Bug >Affects Versions: 1.15.0 >Reporter: Kristen >Assignee: Udo Kohlmeyer >Priority: Major > Labels: needsTriage > > > Task :geode-wan:distributedTest > GatewayReceiverDUnitTest > > removingGatewayReceiverUsingReplicatedRegionShouldRemoveCacheServerFlagFromProfile > FAILED > java.lang.AssertionError: Suspicious strings were written to the log > during this run. > Fix the strings or use IgnoredException.addIgnoredException to ignore. > --- > Found suspect string in 'dunit_suspect-vm3.log' at line 673 > [fatal 2022/01/15 02:19:08.273 UTC > tid=88] Possible loss of quorum due to the loss of 1 cache processes: > [heavy-lifter-f3db8ae7-2766-5a80-a4c9-993976bf93f3(887047):49336] > --- > Found suspect string in 'dunit_suspect-vm3.log' at line 675 > [fatal 2022/01/15 02:19:09.275 UTC > tid=88] Membership service failure: Exiting due to possible network partition > event due to loss of 1 cache processes: > [heavy-lifter-f3db8ae7-2766-5a80-a4c9-993976bf93f3(887047):49336] > > org.apache.geode.distributed.internal.membership.api.MemberDisconnectedException: > Exiting due to possible network partition event due to loss of 1 cache > processes: > [heavy-lifter-f3db8ae7-2766-5a80-a4c9-993976bf93f3(887047):49336] > at > org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.forceDisconnect(GMSMembership.java:1807) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1122) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.access$1300(GMSJoinLeave.java:80) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.prepareAndSendView(GMSJoinLeave.java:2610) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.sendInitialView(GMSJoinLeave.java:2226) > at > org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.run(GMSJoinLeave.java:2308) > at org.junit.Assert.fail(Assert.java:89) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:422) > at > org.apache.geode.test.dunit.internal.DUnitLauncher.closeAndCheckForSuspects(DUnitLauncher.java:438) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.cleanupAllVms(JUnit4DistributedTestCase.java:551) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:498) > at > org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:481) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56) > at > org.junit.internal.runners.statements.RunAfters.invokeMethod(RunAfters.java:46) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:33) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61) > at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306) > at > org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63) > at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331) > at
[jira] [Updated] (GEODE-9857) ShowMissingDiskStoreCommandDUnitTest. stopAllMembersAndStart2ndLocator
[
https://issues.apache.org/jira/browse/GEODE-9857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer updated GEODE-9857:
-
Labels: GeodeOperationAPI (was: GeodeOperationAPI needsTriage)
> ShowMissingDiskStoreCommandDUnitTest. stopAllMembersAndStart2ndLocator
> --
>
> Key: GEODE-9857
> URL: https://issues.apache.org/jira/browse/GEODE-9857
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: GeodeOperationAPI
>
> {noformat}
> ShowMissingDiskStoreCommandDUnitTest > stopAllMembersAndStart2ndLocator FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest
>
> Expecting value to be true but was false within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest.stopAllMembersAndStart2ndLocator(ShowMissingDiskStoreCommandDUnitTest.java:201)
> Caused by:
> org.opentest4j.AssertionFailedError:
> Expecting value to be true but was false
> at sun.reflect.GeneratedConstructorAccessor23.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.GfshCommandRule.connectAndVerify(GfshCommandRule.java:153)
> at
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest.lambda$stopAllMembersAndStart2ndLocator$3(ShowMissingDiskStoreCommandDUnitTest.java:201)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9857) ShowMissingDiskStoreCommandDUnitTest. stopAllMembersAndStart2ndLocator
[
https://issues.apache.org/jira/browse/GEODE-9857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460283#comment-17460283
]
Udo Kohlmeyer commented on GEODE-9857:
--
This test also has not failed since. Last available build is build 61 where
this test has not failed since the failure in build 24.
> ShowMissingDiskStoreCommandDUnitTest. stopAllMembersAndStart2ndLocator
> --
>
> Key: GEODE-9857
> URL: https://issues.apache.org/jira/browse/GEODE-9857
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage
>
> {noformat}
> ShowMissingDiskStoreCommandDUnitTest > stopAllMembersAndStart2ndLocator FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest
>
> Expecting value to be true but was false within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest.stopAllMembersAndStart2ndLocator(ShowMissingDiskStoreCommandDUnitTest.java:201)
> Caused by:
> org.opentest4j.AssertionFailedError:
> Expecting value to be true but was false
> at sun.reflect.GeneratedConstructorAccessor23.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.GfshCommandRule.connectAndVerify(GfshCommandRule.java:153)
> at
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest.lambda$stopAllMembersAndStart2ndLocator$3(ShowMissingDiskStoreCommandDUnitTest.java:201)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9857) ShowMissingDiskStoreCommandDUnitTest. stopAllMembersAndStart2ndLocator
[
https://issues.apache.org/jira/browse/GEODE-9857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17460282#comment-17460282
]
Udo Kohlmeyer commented on GEODE-9857:
--
This seems to be a one time failure of this test. It seems the locator had not
stopped before the restarting of the locator was attempted. In future this
problem might be resolved by waiting for the locator to have stopped correctly
before trying to restart it.
> ShowMissingDiskStoreCommandDUnitTest. stopAllMembersAndStart2ndLocator
> --
>
> Key: GEODE-9857
> URL: https://issues.apache.org/jira/browse/GEODE-9857
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
> Labels: GeodeOperationAPI, needsTriage
>
> {noformat}
> ShowMissingDiskStoreCommandDUnitTest > stopAllMembersAndStart2ndLocator FAILED
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest
>
> Expecting value to be true but was false within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:166)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:119)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:31)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:939)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:723)
> at
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest.stopAllMembersAndStart2ndLocator(ShowMissingDiskStoreCommandDUnitTest.java:201)
> Caused by:
> org.opentest4j.AssertionFailedError:
> Expecting value to be true but was false
> at sun.reflect.GeneratedConstructorAccessor23.newInstance(Unknown
> Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.GfshCommandRule.connectAndVerify(GfshCommandRule.java:153)
> at
> org.apache.geode.management.internal.cli.commands.ShowMissingDiskStoreCommandDUnitTest.lambda$stopAllMembersAndStart2ndLocator$3(ShowMissingDiskStoreCommandDUnitTest.java:201)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9841) Move internal packages to conform to new internal package structure
[ https://issues.apache.org/jira/browse/GEODE-9841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reassigned GEODE-9841: Assignee: Udo Kohlmeyer > Move internal packages to conform to new internal package structure > --- > > Key: GEODE-9841 > URL: https://issues.apache.org/jira/browse/GEODE-9841 > Project: Geode > Issue Type: Improvement >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > > Both ClassLoader and Deployment are in the `internal.classloader` and > `internal.deployment` package structure, which would make more sense (and > conform to newer thinking) to be `classloader.internal` and > `deployment.internal`. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-9841) Move internal packages to conform to new internal package structure
Udo Kohlmeyer created GEODE-9841: Summary: Move internal packages to conform to new internal package structure Key: GEODE-9841 URL: https://issues.apache.org/jira/browse/GEODE-9841 Project: Geode Issue Type: Improvement Reporter: Udo Kohlmeyer Both ClassLoader and Deployment are in the `internal.classloader` and `internal.deployment` package structure, which would make more sense (and conform to newer thinking) to be `classloader.internal` and `deployment.internal`. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9630) Gateway sender has public setter methods that should not be exposed
[ https://issues.apache.org/jira/browse/GEODE-9630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17424756#comment-17424756 ] Udo Kohlmeyer commented on GEODE-9630: -- [~mivanac], Would this be something that you could look at and resolve? > Gateway sender has public setter methods that should not be exposed > --- > > Key: GEODE-9630 > URL: https://issues.apache.org/jira/browse/GEODE-9630 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.15.0 >Reporter: Udo Kohlmeyer >Priority: Blocker > Labels: needsTriage > > Looking at the GatewaySender interface I noticed there are numerous public > setter methods. Geode should not allow for the ability to directly change > GatewaySender functionality without proper process. > This is largely to avoid the introduction of side effects into the system. A > prime example of this is, the ability to call `setGroupTransactionEvents`, > which from what I understand should NEVER be allowed to be changed in just 1 > server instead of cluster-wide. This by writing a function and changing the > setting on only 1 server can run the risk of the whole system behaving > incorrectly causing failures which would be close to impossible to track down. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (GEODE-9630) Gateway sender has public setter methods that should not be exposed
[ https://issues.apache.org/jira/browse/GEODE-9630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17421086#comment-17421086 ] Udo Kohlmeyer commented on GEODE-9630: -- Hi there Mario, I apologize that this was missed in the PR review. As for the RFC, it does not mention that there would be public setters on the GatewaySender class. My intent is not to remove / impact the functionality, but rather to make the changes in a more "correct" manner. e.g not on the public API and possibly through a framework that can track lifecycles and make the necessary validations BEFORE the changes are applied. I think we need to think about issues that changes like this could cause in production cases. Where one is able to directly access the GatewaySender and amend its behavior on one server vs the cluster. What does that mean for the system behavior. Also, if we think about each component to be more immutable and making changes at runtime to be less of the norm, the better. Also, without ANY process tracking any runtime changes to the system, would make it a nightmare to possible track down behavioral changes that were caused by runtime changes that were not tracked and/or are auditable. I also believe that we need to come up with a pattern/framework that we can apply to these kind of runtime changes for all components. WAN/GatewaySender might unfortunately might be the first implementor of said framework. Either way, let's work on this, in order to resolve the issues. > Gateway sender has public setter methods that should not be exposed > --- > > Key: GEODE-9630 > URL: https://issues.apache.org/jira/browse/GEODE-9630 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.15.0 >Reporter: Udo Kohlmeyer >Priority: Blocker > Labels: blocks-1.15.0 > > Looking at the GatewaySender interface I noticed there are numerous public > setter methods. Geode should not allow for the ability to directly change > GatewaySender functionality without proper process. > This is largely to avoid the introduction of side effects into the system. A > prime example of this is, the ability to call `setGroupTransactionEvents`, > which from what I understand should NEVER be allowed to be changed in just 1 > server instead of cluster-wide. This by writing a function and changing the > setting on only 1 server can run the risk of the whole system behaving > incorrectly causing failures which would be close to impossible to track down. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9630) Gateway sender has public setter methods that should not be exposed
Udo Kohlmeyer created GEODE-9630: Summary: Gateway sender has public setter methods that should not be exposed Key: GEODE-9630 URL: https://issues.apache.org/jira/browse/GEODE-9630 Project: Geode Issue Type: Improvement Components: wan Affects Versions: 1.15.0 Reporter: Udo Kohlmeyer Looking at the GatewaySender interface I noticed there are numerous public setter methods. Geode should not allow for the ability to directly change GatewaySender functionality without proper process. This is largely to avoid the introduction of side effects into the system. A prime example of this is, the ability to call `setGroupTransactionEvents`, which from what I understand should NEVER be allowed to be changed in just 1 server instead of cluster-wide. This by writing a function and changing the setting on only 1 server can run the risk of the whole system behaving incorrectly causing failures which would be close to impossible to track down. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9630) Gateway sender has public setter methods that should not be exposed
[ https://issues.apache.org/jira/browse/GEODE-9630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-9630: - Priority: Blocker (was: Major) > Gateway sender has public setter methods that should not be exposed > --- > > Key: GEODE-9630 > URL: https://issues.apache.org/jira/browse/GEODE-9630 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.15.0 >Reporter: Udo Kohlmeyer >Priority: Blocker > > Looking at the GatewaySender interface I noticed there are numerous public > setter methods. Geode should not allow for the ability to directly change > GatewaySender functionality without proper process. > This is largely to avoid the introduction of side effects into the system. A > prime example of this is, the ability to call `setGroupTransactionEvents`, > which from what I understand should NEVER be allowed to be changed in just 1 > server instead of cluster-wide. This by writing a function and changing the > setting on only 1 server can run the risk of the whole system behaving > incorrectly causing failures which would be close to impossible to track down. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9629) GatewaySender.setRetriesToGetTransactionEventsFromQueue on public API
Udo Kohlmeyer created GEODE-9629: Summary: GatewaySender.setRetriesToGetTransactionEventsFromQueue on public API Key: GEODE-9629 URL: https://issues.apache.org/jira/browse/GEODE-9629 Project: Geode Issue Type: Improvement Components: wan Affects Versions: 1.15.0 Reporter: Udo Kohlmeyer GatewaySender.setRetriesToGetTransactionEventsFromQueue is defined on the public API. The problem with this is that Geode should not allow for the simple modification of settings for a GatewaySender. Without proper process / management around the changing of the properties it would be too simple to introduce side-effects by changing settings on the GatewaySender. We (Geode) should NOT allow for the direct manipulation of configuration of ANY component without it having gone through a controlled process, to ensure that there aren't any side effects resulting from the change. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9629) GatewaySender.setRetriesToGetTransactionEventsFromQueue on public API
[ https://issues.apache.org/jira/browse/GEODE-9629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-9629: - Priority: Blocker (was: Major) > GatewaySender.setRetriesToGetTransactionEventsFromQueue on public API > - > > Key: GEODE-9629 > URL: https://issues.apache.org/jira/browse/GEODE-9629 > Project: Geode > Issue Type: Improvement > Components: wan >Affects Versions: 1.15.0 >Reporter: Udo Kohlmeyer >Priority: Blocker > > GatewaySender.setRetriesToGetTransactionEventsFromQueue is defined on the > public API. > The problem with this is that Geode should not allow for the simple > modification of settings for a GatewaySender. Without proper process / > management around the changing of the properties it would be too simple to > introduce side-effects by changing settings on the GatewaySender. > We (Geode) should NOT allow for the direct manipulation of configuration of > ANY component without it having gone through a controlled process, to ensure > that there aren't any side effects resulting from the change. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9091) Remove Package Splitting
[ https://issues.apache.org/jira/browse/GEODE-9091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-9091. -- Fix Version/s: 1.15.0 Resolution: Fixed > Remove Package Splitting > > > Key: GEODE-9091 > URL: https://issues.apache.org/jira/browse/GEODE-9091 > Project: Geode > Issue Type: Improvement >Reporter: Udo Kohlmeyer >Priority: Major > Fix For: 1.15.0 > > > Geode project modules have packages split across them. Splitting packages > across modules is not allowed in Java 9+ and will cause problems when > GEODE-8705 is committed. > This ticket is here to track the removal of package splitting -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9098) Package splitting geode-membership
[ https://issues.apache.org/jira/browse/GEODE-9098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-9098. -- Fix Version/s: 1.15.0 Resolution: Fixed > Package splitting geode-membership > -- > > Key: GEODE-9098 > URL: https://issues.apache.org/jira/browse/GEODE-9098 > Project: Geode > Issue Type: Sub-task >Reporter: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9097) Package splitting geode-management
[ https://issues.apache.org/jira/browse/GEODE-9097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-9097: - Fix Version/s: 1.15.0 > Package splitting geode-management > -- > > Key: GEODE-9097 > URL: https://issues.apache.org/jira/browse/GEODE-9097 > Project: Geode > Issue Type: Sub-task >Reporter: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9097) Package splitting geode-management
[ https://issues.apache.org/jira/browse/GEODE-9097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-9097. -- Resolution: Fixed > Package splitting geode-management > -- > > Key: GEODE-9097 > URL: https://issues.apache.org/jira/browse/GEODE-9097 > Project: Geode > Issue Type: Sub-task >Reporter: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9099) Package splitting geode-protobuf
[ https://issues.apache.org/jira/browse/GEODE-9099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-9099. -- Resolution: Won't Fix > Package splitting geode-protobuf > > > Key: GEODE-9099 > URL: https://issues.apache.org/jira/browse/GEODE-9099 > Project: Geode > Issue Type: Sub-task >Reporter: Udo Kohlmeyer >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9227) CI Failure: distributed tests running longer now after the package changes
[ https://issues.apache.org/jira/browse/GEODE-9227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-9227: - Issue Type: Improvement (was: Bug) > CI Failure: distributed tests running longer now after the package changes > -- > > Key: GEODE-9227 > URL: https://issues.apache.org/jira/browse/GEODE-9227 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Eric Shu >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > > Test artifacts can be found here: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/181.3 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9219) CI: multiple CI jobs fail with "timeout exceeded"
[
https://issues.apache.org/jira/browse/GEODE-9219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer resolved GEODE-9219.
--
Fix Version/s: 1.15.0
Resolution: Fixed
> CI: multiple CI jobs fail with "timeout exceeded"
> -
>
> Key: GEODE-9219
> URL: https://issues.apache.org/jira/browse/GEODE-9219
> Project: Geode
> Issue Type: Bug
> Components: ci
>Reporter: Kamilla Aslami
>Assignee: Udo Kohlmeyer
>Priority: Major
> Fix For: 1.15.0
>
>
> DistributedTestOpenJDK8, WindowsIntegrationTestOpenJDK8, and
> WindowsGfshDistributedTestOpenJDK11 jobs occasionally fail because they
> exceed their timeouts.
> These failures (or some of them) might be caused by GEODE-9079.
> In DistributedTestOpenJDK8 failures, artifacts show a thread stuck in
> ClassGraph code:
> {noformat}
> "Test worker" #25 prio=5 os_prio=0 tid=0x7fe464a96800 nid=0x5e waiting on
> condition [0x7fe316ccc000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xd3ec4580> (a
> java.util.concurrent.FutureTask)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
> at java.util.concurrent.FutureTask.get(FutureTask.java:191)
> at io.github.classgraph.ClassGraph.scan(ClassGraph.java:1548)
> at io.github.classgraph.ClassGraph.scan(ClassGraph.java:1587)
> at
> org.apache.geode.management.internal.util.ClasspathScanLoadHelper.(ClasspathScanLoadHelper.java:41)
> at
> org.apache.geode.management.internal.cli.CommandManager.loadCommands(CommandManager.java:185)
> at
> org.apache.geode.management.internal.cli.CommandManager.(CommandManager.java:89)
> at
> org.apache.geode.management.internal.cli.remote.OnlineCommandProcessor.init(OnlineCommandProcessor.java:147)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeServices(GemFireCacheImpl.java:1508)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1435)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> - locked <0xd0258b78> (a java.lang.Class for
> org.apache.geode.internal.cache.GemFireCacheImpl)
> - locked <0xd0965568> (a java.lang.Class for
> org.apache.geode.internal.cache.InternalCacheBuilder)
> at
> org.apache.geode.internal.cache.CacheFactoryStatics.create(CacheFactoryStatics.java:61)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:352)
> at
> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.createCache(JUnit4CacheTestCase.java:120)
> - locked <0xd01d2b20> (a java.lang.Class for
> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase)
> at
> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.getCache(JUnit4CacheTestCase.java:222)
> - locked <0xd01d2b20> (a java.lang.Class for
> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase)
> at
> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.getCache(JUnit4CacheTestCase.java:209)
> at
> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.getCache(JUnit4CacheTestCase.java:196)
> at
> org.apache.geode.cache30.CacheXml66DUnitTest.testPartitionedRegionXML(CacheXml66DUnitTest.java:2737)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableTemporaryFolder$1.evaluate(SerializableTemporaryFolder.java:130)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at
[jira] [Resolved] (GEODE-9227) CI Failure: distributed tests running longer now after the package changes
[ https://issues.apache.org/jira/browse/GEODE-9227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-9227. -- Fix Version/s: 1.15.0 Resolution: Fixed > CI Failure: distributed tests running longer now after the package changes > -- > > Key: GEODE-9227 > URL: https://issues.apache.org/jira/browse/GEODE-9227 > Project: Geode > Issue Type: Improvement > Components: ci >Reporter: Eric Shu >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Test artifacts can be found here: > https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/181.3 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9219) CI: multiple CI jobs fail with "timeout exceeded"
[
https://issues.apache.org/jira/browse/GEODE-9219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer reassigned GEODE-9219:
Assignee: Udo Kohlmeyer
> CI: multiple CI jobs fail with "timeout exceeded"
> -
>
> Key: GEODE-9219
> URL: https://issues.apache.org/jira/browse/GEODE-9219
> Project: Geode
> Issue Type: Bug
> Components: ci
>Reporter: Kamilla Aslami
>Assignee: Udo Kohlmeyer
>Priority: Major
>
> DistributedTestOpenJDK8, WindowsIntegrationTestOpenJDK8, and
> WindowsGfshDistributedTestOpenJDK11 jobs occasionally fail because they
> exceed their timeouts.
> These failures (or some of them) might be caused by GEODE-9079.
> In DistributedTestOpenJDK8 failures, artifacts show a thread stuck in
> ClassGraph code:
> {noformat}
> "Test worker" #25 prio=5 os_prio=0 tid=0x7fe464a96800 nid=0x5e waiting on
> condition [0x7fe316ccc000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0xd3ec4580> (a
> java.util.concurrent.FutureTask)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at java.util.concurrent.FutureTask.awaitDone(FutureTask.java:429)
> at java.util.concurrent.FutureTask.get(FutureTask.java:191)
> at io.github.classgraph.ClassGraph.scan(ClassGraph.java:1548)
> at io.github.classgraph.ClassGraph.scan(ClassGraph.java:1587)
> at
> org.apache.geode.management.internal.util.ClasspathScanLoadHelper.(ClasspathScanLoadHelper.java:41)
> at
> org.apache.geode.management.internal.cli.CommandManager.loadCommands(CommandManager.java:185)
> at
> org.apache.geode.management.internal.cli.CommandManager.(CommandManager.java:89)
> at
> org.apache.geode.management.internal.cli.remote.OnlineCommandProcessor.init(OnlineCommandProcessor.java:147)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initializeServices(GemFireCacheImpl.java:1508)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1435)
> at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> - locked <0xd0258b78> (a java.lang.Class for
> org.apache.geode.internal.cache.GemFireCacheImpl)
> - locked <0xd0965568> (a java.lang.Class for
> org.apache.geode.internal.cache.InternalCacheBuilder)
> at
> org.apache.geode.internal.cache.CacheFactoryStatics.create(CacheFactoryStatics.java:61)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:352)
> at
> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.createCache(JUnit4CacheTestCase.java:120)
> - locked <0xd01d2b20> (a java.lang.Class for
> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase)
> at
> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.getCache(JUnit4CacheTestCase.java:222)
> - locked <0xd01d2b20> (a java.lang.Class for
> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase)
> at
> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.getCache(JUnit4CacheTestCase.java:209)
> at
> org.apache.geode.test.dunit.cache.internal.JUnit4CacheTestCase.getCache(JUnit4CacheTestCase.java:196)
> at
> org.apache.geode.cache30.CacheXml66DUnitTest.testPartitionedRegionXML(CacheXml66DUnitTest.java:2737)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
> at
> org.apache.geode.test.junit.rules.serializable.SerializableTemporaryFolder$1.evaluate(SerializableTemporaryFolder.java:130)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
> at
[jira] [Resolved] (GEODE-9092) Package splitting geode-common
[ https://issues.apache.org/jira/browse/GEODE-9092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-9092. -- Fix Version/s: 1.15.0 Resolution: Fixed > Package splitting geode-common > -- > > Key: GEODE-9092 > URL: https://issues.apache.org/jira/browse/GEODE-9092 > Project: Geode > Issue Type: Sub-task >Reporter: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9093) Package splitting geode-connectors
[ https://issues.apache.org/jira/browse/GEODE-9093?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-9093. -- Fix Version/s: 1.15.0 Resolution: Fixed > Package splitting geode-connectors > -- > > Key: GEODE-9093 > URL: https://issues.apache.org/jira/browse/GEODE-9093 > Project: Geode > Issue Type: Sub-task >Reporter: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9095) Package splitting geode-http-service
[ https://issues.apache.org/jira/browse/GEODE-9095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-9095. -- Fix Version/s: 1.15.0 Resolution: Fixed > Package splitting geode-http-service > > > Key: GEODE-9095 > URL: https://issues.apache.org/jira/browse/GEODE-9095 > Project: Geode > Issue Type: Sub-task >Reporter: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9173) Bump Swagger2 to newer version
Udo Kohlmeyer created GEODE-9173: Summary: Bump Swagger2 to newer version Key: GEODE-9173 URL: https://issues.apache.org/jira/browse/GEODE-9173 Project: Geode Issue Type: Improvement Components: management Reporter: Udo Kohlmeyer -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9121) Regression Introduced Through GEODE-8905
[
https://issues.apache.org/jira/browse/GEODE-9121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer resolved GEODE-9121.
--
Resolution: Won't Fix
This issue seems to have been resolved with the commit of GEODE-9065
> Regression Introduced Through GEODE-8905
>
>
> Key: GEODE-9121
> URL: https://issues.apache.org/jira/browse/GEODE-9121
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Assignee: Udo Kohlmeyer
>Priority: Major
> Attachments: workspace.zip
>
>
> The new implementation of the {{JarDeploymentService}} seems to be deleting
> resources when a member is gracefully shutdown, which in turns generates a
> race condition if there are functions being executed on the member during
> that time.
> In previous versions, a client application would simply retry the operation
> and no exception or loss of availability would be seen, right now the
> following exception is thrown on the client instead:
> {noformat}
> Exception in thread "main" org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.cache.client.ServerOperationException: remote server on
> 192.168.0.73(3985:loner):49836:c9f57ea7: The function, , has not been
> registered
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:237)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeFunction(ServerRegionFunctionExecutor.java:184)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:388)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:351)
> at test.TestClient.main(TestClient.java:20)
> Caused by: org.apache.geode.cache.client.ServerOperationException: remote
> server on 192.168.0.73(3985:loner):49836:c9f57ea7: The function, ,
> has not been registered
> at
> org.apache.geode.cache.client.internal.ExecuteRegionFunctionSingleHopOp$ExecuteRegionFunctionSingleHopOpImpl.processResponse(ExecuteRegionFunctionSingleHopOp.java:370)
> at
> org.apache.geode.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:224)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:197)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:384)
> at
> org.apache.geode.cache.client.internal.AbstractOpWithTimeout.attempt(AbstractOpWithTimeout.java:45)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:284)
> at
> org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:355)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:756)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnServer(OpExecutorImpl.java:335)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeOn(OpExecutorImpl.java:304)
> at
> org.apache.geode.cache.client.internal.PoolImpl.executeOn(PoolImpl.java:840)
> at
> org.apache.geode.cache.client.internal.SingleHopOperationCallable.call(SingleHopOperationCallable.java:49)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This seems to be a regression introduced through GEODE-8905. I've tested the
> same scenario with version {{1.13.2}} (released), branch {{support/1.14}} and
> commit [b80094ec5e|https://github.com/apache/geode/commit/b80094ec5e] with no
> problems at all. When testing using commit
> [6f764a7046|https://github.com/apache/geode/commit/6f764a7046], on the other
> hand, the problem is easily reproducible.
> —
> How to reproduce the issue:
> 1. Download and extract {{workspace.zip}}.
> 2. Execute the {{reproduce.sh}} script and follow the instructions on screen.
> The version of {{Geode}} to use on server side can be changed through the
> {{GEMFIRE}} variable within the {{reproduce.sh}} script.
> The version of {{Geode}} to use on client side can be changed through the
> {{GEODE_VERSION}} variable within the {{launch_client.sh}} script.
> The client application simply executes the {{TestFunction}} forever. When
> running the scenario using a version of {{Geode}} that doesn't include commit
>
[jira] [Resolved] (GEODE-9065) Create a ClasspathService interface to back ClassPathLoader
[ https://issues.apache.org/jira/browse/GEODE-9065?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-9065. -- Fix Version/s: 1.15.0 Resolution: Fixed > Create a ClasspathService interface to back ClassPathLoader > --- > > Key: GEODE-9065 > URL: https://issues.apache.org/jira/browse/GEODE-9065 > Project: Geode > Issue Type: Improvement >Affects Versions: 1.15.0 >Reporter: Patrick Johnsn >Assignee: Patrick Johnsn >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > The ClasspathService will encapsulate the differences between classloading in > JBoss modules compared to the current way of working. There will be an > implementation for JBoss and another for legacy. This interface will be used > to back the ClassPathLoader so it will behave appropriately in both worlds. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (GEODE-9121) Regression Introduced Through GEODE-8905
[
https://issues.apache.org/jira/browse/GEODE-9121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Kohlmeyer reassigned GEODE-9121:
Assignee: Udo Kohlmeyer
> Regression Introduced Through GEODE-8905
>
>
> Key: GEODE-9121
> URL: https://issues.apache.org/jira/browse/GEODE-9121
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.15.0
>Reporter: Juan Ramos
>Assignee: Udo Kohlmeyer
>Priority: Major
> Attachments: workspace.zip
>
>
> The new implementation of the {{JarDeploymentService}} seems to be deleting
> resources when a member is gracefully shutdown, which in turns generates a
> race condition if there are functions being executed on the member during
> that time.
> In previous versions, a client application would simply retry the operation
> and no exception or loss of availability would be seen, right now the
> following exception is thrown on the client instead:
> {noformat}
> Exception in thread "main" org.apache.geode.cache.execute.FunctionException:
> org.apache.geode.cache.client.ServerOperationException: remote server on
> 192.168.0.73(3985:loner):49836:c9f57ea7: The function, , has not been
> registered
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeOnServer(ServerRegionFunctionExecutor.java:237)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.executeFunction(ServerRegionFunctionExecutor.java:184)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:388)
> at
> org.apache.geode.internal.cache.execute.ServerRegionFunctionExecutor.execute(ServerRegionFunctionExecutor.java:351)
> at test.TestClient.main(TestClient.java:20)
> Caused by: org.apache.geode.cache.client.ServerOperationException: remote
> server on 192.168.0.73(3985:loner):49836:c9f57ea7: The function, ,
> has not been registered
> at
> org.apache.geode.cache.client.internal.ExecuteRegionFunctionSingleHopOp$ExecuteRegionFunctionSingleHopOpImpl.processResponse(ExecuteRegionFunctionSingleHopOp.java:370)
> at
> org.apache.geode.cache.client.internal.AbstractOp.processResponse(AbstractOp.java:224)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attemptReadResponse(AbstractOp.java:197)
> at
> org.apache.geode.cache.client.internal.AbstractOp.attempt(AbstractOp.java:384)
> at
> org.apache.geode.cache.client.internal.AbstractOpWithTimeout.attempt(AbstractOpWithTimeout.java:45)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.execute(ConnectionImpl.java:284)
> at
> org.apache.geode.cache.client.internal.pooling.PooledConnection.execute(PooledConnection.java:355)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeWithPossibleReAuthentication(OpExecutorImpl.java:756)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnServer(OpExecutorImpl.java:335)
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeOn(OpExecutorImpl.java:304)
> at
> org.apache.geode.cache.client.internal.PoolImpl.executeOn(PoolImpl.java:840)
> at
> org.apache.geode.cache.client.internal.SingleHopOperationCallable.call(SingleHopOperationCallable.java:49)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> This seems to be a regression introduced through GEODE-8905. I've tested the
> same scenario with version {{1.13.2}} (released), branch {{support/1.14}} and
> commit [b80094ec5e|https://github.com/apache/geode/commit/b80094ec5e] with no
> problems at all. When testing using commit
> [6f764a7046|https://github.com/apache/geode/commit/6f764a7046], on the other
> hand, the problem is easily reproducible.
> —
> How to reproduce the issue:
> 1. Download and extract {{workspace.zip}}.
> 2. Execute the {{reproduce.sh}} script and follow the instructions on screen.
> The version of {{Geode}} to use on server side can be changed through the
> {{GEMFIRE}} variable within the {{reproduce.sh}} script.
> The version of {{Geode}} to use on client side can be changed through the
> {{GEODE_VERSION}} variable within the {{launch_client.sh}} script.
> The client application simply executes the {{TestFunction}} forever. When
> running the scenario using a version of {{Geode}} that doesn't include commit
> [6f764a7046|https://github.com/apache/geode/commit/6f764a7046], the client
>
[jira] [Resolved] (GEODE-9094) Package splitting geode-gfsh
[ https://issues.apache.org/jira/browse/GEODE-9094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-9094. -- Fix Version/s: 1.15.0 Resolution: Fixed > Package splitting geode-gfsh > > > Key: GEODE-9094 > URL: https://issues.apache.org/jira/browse/GEODE-9094 > Project: Geode > Issue Type: Sub-task >Reporter: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9096) Package splitting geode-lucene
[ https://issues.apache.org/jira/browse/GEODE-9096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-9096. -- Fix Version/s: 1.15.0 Resolution: Fixed > Package splitting geode-lucene > -- > > Key: GEODE-9096 > URL: https://issues.apache.org/jira/browse/GEODE-9096 > Project: Geode > Issue Type: Sub-task >Reporter: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9100) Package splitting geode-wan
[ https://issues.apache.org/jira/browse/GEODE-9100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-9100. -- Fix Version/s: 1.15.0 Resolution: Fixed > Package splitting geode-wan > --- > > Key: GEODE-9100 > URL: https://issues.apache.org/jira/browse/GEODE-9100 > Project: Geode > Issue Type: Sub-task >Reporter: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9099) Package splitting geode-protobuf
Udo Kohlmeyer created GEODE-9099: Summary: Package splitting geode-protobuf Key: GEODE-9099 URL: https://issues.apache.org/jira/browse/GEODE-9099 Project: Geode Issue Type: Sub-task Reporter: Udo Kohlmeyer -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9100) Package splitting geode-wan
Udo Kohlmeyer created GEODE-9100: Summary: Package splitting geode-wan Key: GEODE-9100 URL: https://issues.apache.org/jira/browse/GEODE-9100 Project: Geode Issue Type: Sub-task Reporter: Udo Kohlmeyer -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9098) Package splitting geode-membership
Udo Kohlmeyer created GEODE-9098: Summary: Package splitting geode-membership Key: GEODE-9098 URL: https://issues.apache.org/jira/browse/GEODE-9098 Project: Geode Issue Type: Sub-task Reporter: Udo Kohlmeyer -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9096) Package splitting geode-lucene
Udo Kohlmeyer created GEODE-9096: Summary: Package splitting geode-lucene Key: GEODE-9096 URL: https://issues.apache.org/jira/browse/GEODE-9096 Project: Geode Issue Type: Sub-task Reporter: Udo Kohlmeyer -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9095) Package splitting geode-http-service
Udo Kohlmeyer created GEODE-9095: Summary: Package splitting geode-http-service Key: GEODE-9095 URL: https://issues.apache.org/jira/browse/GEODE-9095 Project: Geode Issue Type: Sub-task Reporter: Udo Kohlmeyer -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9097) Package splitting geode-management
Udo Kohlmeyer created GEODE-9097: Summary: Package splitting geode-management Key: GEODE-9097 URL: https://issues.apache.org/jira/browse/GEODE-9097 Project: Geode Issue Type: Sub-task Reporter: Udo Kohlmeyer -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9093) Package splitting geode-connectors
Udo Kohlmeyer created GEODE-9093: Summary: Package splitting geode-connectors Key: GEODE-9093 URL: https://issues.apache.org/jira/browse/GEODE-9093 Project: Geode Issue Type: Sub-task Reporter: Udo Kohlmeyer -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9094) Package splitting geode-gfsh
Udo Kohlmeyer created GEODE-9094: Summary: Package splitting geode-gfsh Key: GEODE-9094 URL: https://issues.apache.org/jira/browse/GEODE-9094 Project: Geode Issue Type: Sub-task Reporter: Udo Kohlmeyer -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9092) Package splitting geode-common
Udo Kohlmeyer created GEODE-9092: Summary: Package splitting geode-common Key: GEODE-9092 URL: https://issues.apache.org/jira/browse/GEODE-9092 Project: Geode Issue Type: Sub-task Reporter: Udo Kohlmeyer -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9091) Remove Package Splitting
Udo Kohlmeyer created GEODE-9091: Summary: Remove Package Splitting Key: GEODE-9091 URL: https://issues.apache.org/jira/browse/GEODE-9091 Project: Geode Issue Type: Improvement Reporter: Udo Kohlmeyer Geode project modules have packages split across them. Splitting packages across modules is not allowed in Java 9+ and will cause problems when GEODE-8705 is committed. This ticket is here to track the removal of package splitting -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-8905) Introduce JarDeploymentService
[ https://issues.apache.org/jira/browse/GEODE-8905?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer resolved GEODE-8905. -- Fix Version/s: 1.15.0 Resolution: Fixed > Introduce JarDeploymentService > -- > > Key: GEODE-8905 > URL: https://issues.apache.org/jira/browse/GEODE-8905 > Project: Geode > Issue Type: Improvement > Components: gfsh, management >Reporter: Patrick Johnsn >Assignee: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0 > > > Introduce a JarDeploymentService interface that will allow us to interchange > the current way of deploying jars with the new modular approach. > > There will be an implementation that delegates to the existing JarDeployer > and will maintain current behavior. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9077) GFSH commands invoke functions using execute(Function) rather than execute(ID)
Udo Kohlmeyer created GEODE-9077: Summary: GFSH commands invoke functions using execute(Function) rather than execute(ID) Key: GEODE-9077 URL: https://issues.apache.org/jira/browse/GEODE-9077 Project: Geode Issue Type: Improvement Components: gfsh Reporter: Udo Kohlmeyer GFSH currently executes functions using the method, `execute(Function)` rather than a more acceptable `execute(ID)`. In both cases the function is required to be on the server-side, BUT the main difference is that for the first case the function does not need to be registered. Which makes no sense, as the function as to be present on the server side. This approach makes it difficult to move functions (package) or replace them with better versions at runtime, as the function versions have to match up for it to be able to deserialize correctly. In the approach of `execute(ID)` the problem exists that the functions need to be registered which means that possibly they might become "public" when listing them with `list functions`. But the benefits are larger, as they are registered by name and thus invocation from the client side is against the ID and not the Function itself. In addition, this approach allows for the updating of the function, without having to update the client, as the implementation does not have to live in GFSH. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (GEODE-9076) GeodeClusterManagementServiceBuilder is based on internal API from another module.
Udo Kohlmeyer created GEODE-9076: Summary: GeodeClusterManagementServiceBuilder is based on internal API from another module. Key: GEODE-9076 URL: https://issues.apache.org/jira/browse/GEODE-9076 Project: Geode Issue Type: Bug Components: configuration Reporter: Udo Kohlmeyer GeodeClusterManagementServiceBuilder is extending BaseManagementServiceBuilder, which is in the internal namespace. Which means that we now expose internal API's into the public API space. This is not only technically incorrect, but also ethically and morally. Can we please address this. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-8705) Modify java.gradle to generate module.xml as well as the Manifest file
[ https://issues.apache.org/jira/browse/GEODE-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer updated GEODE-8705: - Parent: (was: GEODE-8067) Issue Type: New Feature (was: Sub-task) > Modify java.gradle to generate module.xml as well as the Manifest file > -- > > Key: GEODE-8705 > URL: https://issues.apache.org/jira/browse/GEODE-8705 > Project: Geode > Issue Type: New Feature >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > > In order to convert the current ClassLoader Isolation work to use `java -jar > jboss-modules` one would like to have `module.xml` files that standard > jboss-modules knows how to handle. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Reopened] (GEODE-8705) Modify java.gradle to generate module.xml as well as the Manifest file
[ https://issues.apache.org/jira/browse/GEODE-8705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Kohlmeyer reopened GEODE-8705: -- > Modify java.gradle to generate module.xml as well as the Manifest file > -- > > Key: GEODE-8705 > URL: https://issues.apache.org/jira/browse/GEODE-8705 > Project: Geode > Issue Type: New Feature >Reporter: Udo Kohlmeyer >Assignee: Udo Kohlmeyer >Priority: Major > > In order to convert the current ClassLoader Isolation work to use `java -jar > jboss-modules` one would like to have `module.xml` files that standard > jboss-modules knows how to handle. -- This message was sent by Atlassian Jira (v8.3.4#803005)
