[jira] [Commented] (GEODE-10023) Security and management classes have broken javadocs
[ https://issues.apache.org/jira/browse/GEODE-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17523015#comment-17523015 ] ASF subversion and git services commented on GEODE-10023: - Commit ab5010005f0acb2777968b585723e3ca455195fb in geode's branch refs/heads/develop from Donal Evans [ https://gitbox.apache.org/repos/asf?p=geode.git;h=ab5010005f ] GEODE-10023: Fix javadocs (#7594) This commit reduces the number of errors reported in the gradle build log due to javadocs from over 3000 to 0. It also reduces the number of warnings reported in the gradle build log due to javadocs from over 4000 to 0. After these changes, all published javadocs are now syntactically correct, although no guarantee is made as to the content of the documentation. Javadocs in classes that did not produce warnings or errors in the gradle build log were not touched. For classes in the geode-dunit, geode-junit, geode-assembly and geode-concurrency-test modules, if a javadoc could be converted to a non-javadoc comment without losing any formatting or tags, it was converted, since those classes are not intended for use by Geode users The changes made were: - Add missing @return, @param and @throws tags - Fix all errors due to incorrect HTML - Fix all errors due to improperly escaped characters - Fix all broken @link tags - Several minor spelling errors and typos fixed where spotted In addition to this clean-up, the compiler settings were modified so that javadocs warnings and errors will be output in the gradle build log, and if any are present, the build will fail. Authored-by: Donal Evans Co-authored-by: Patrick Johnson > Security and management classes have broken javadocs > > > Key: GEODE-10023 > URL: https://issues.apache.org/jira/browse/GEODE-10023 > Project: Geode > Issue Type: Bug > Components: management, security >Affects Versions: 1.15.0 >Reporter: Kirk Lund >Assignee: Donal Evans >Priority: Major > Labels: needsTriage, pull-request-available > > This ticket specifically refers to the javadoc warnings in the build output > about various broken links and similar details about management classes and > security classed that are generated when building Geode on the command-line > with gradle. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9759) User Guide: gfsh command pages - problem with double-hyphens
[ https://issues.apache.org/jira/browse/GEODE-9759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522991#comment-17522991 ] ASF subversion and git services commented on GEODE-9759: Commit e7be6be0e0f47f47e2deadb4a6a3c97c9c12a9eb in geode's branch refs/heads/support/1.14 from Max Hufnagel [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e7be6be0e0 ] GEODE-9759: replaces double-hyphens with (#7597) > User Guide: gfsh command pages - problem with double-hyphens > > > Key: GEODE-9759 > URL: https://issues.apache.org/jira/browse/GEODE-9759 > Project: Geode > Issue Type: Bug > Components: docs >Affects Versions: 1.14.0 >Reporter: Dave Barnes >Assignee: Max Hufnagel >Priority: Major > Labels: pull-request-available > > In the tables of gfsh command options, double-hyphen prefixes are often (but > not always) collapsed to a single hyphen. > This is a format issue with dozens (possibly hundreds?) of occurrences. > See, for example, the `alter` command page, > http://geode.apache.org/docs/guide/114/tools_modules/gfsh/command-pages/alter.html. > Note the difference between the entry for > `--entry-idle-time-expiration-action` and the following entry > `-entry-time-to-live-expiration`. The tricky bit is that the source code in > both cases uses the same HTML construct: `\-\-entry-time-to-live-expiration`, but the results > differ. > One likely remedy is to replace the hyphen pair with the code for two > non-breaking hyphens: ``. > Behavior may differ depending on whether the entry occurs in an HTML table, a > nested HTML table, or a Markdown table. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9476) VMStats processCpuTime, fdLimit, and fdsOpen will always be zero on java 16 and later
[
https://issues.apache.org/jira/browse/GEODE-9476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522987#comment-17522987
]
Darrel Schneider commented on GEODE-9476:
-
this is an issue for geode 1.15 because the setAccessible call is made to a jdk
class. For these stats to work on jdk17 our server and locator process need
"sun.management" opened to the unnamed module.
> VMStats processCpuTime, fdLimit, and fdsOpen will always be zero on java 16
> and later
> -
>
> Key: GEODE-9476
> URL: https://issues.apache.org/jira/browse/GEODE-9476
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Reporter: Darrel Schneider
>Priority: Major
> Labels: Java16, Java17
>
> VMStats processCpuTime, fdLimit, and fdsOpen will always be zero on java 16
> and later.
> This is because it calls Method.setAccessible which is not allowed under
> normal conditions starting with java 16 (see:
> https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16).
> A workaround for this bug is to start the jvm with --illegal-access=permit
> The setAccessible call is in the static initializer for:
> org.apache.geode.internal.stats50.VMStats50
> It turns out the following works for calling processCpuTime:
> {code:java}
> OperatingSystemMXBean osBean =
> ManagementFactory.getOperatingSystemMXBean();
> com.sun.management.OperatingSystemMXBean sunBean =
> (com.sun.management.OperatingSystemMXBean) osBean;
> System.out.println("getProcessCpuTime=" +
> sunBean.getProcessCpuTime());
> {code}
> so we can get rid of the setAccessible call
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10243) Old clients with durable queues should fail early if AuthenticationExpiredException is thrown
[
https://issues.apache.org/jira/browse/GEODE-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-10243:
---
Labels: pull-request-available (was: )
> Old clients with durable queues should fail early if
> AuthenticationExpiredException is thrown
> -
>
> Key: GEODE-10243
> URL: https://issues.apache.org/jira/browse/GEODE-10243
> Project: Geode
> Issue Type: Improvement
> Components: client queues
>Reporter: Dan Smith
>Assignee: Dan Smith
>Priority: Major
> Labels: pull-request-available
>
> As part of the changes for GEODE-9457, when an AuthenticationExpiredException
> is thrown from the SecurityManager during message dispatching, we send a
> message to 1.15 and newer clients asking them to re-authenticate.
> For 1.14 and older clients, we do not send a message. Instead, we just wait
> for the {color:#00875a}reauthenticate.wait.time{color} to elapse and then
> close the connection.
> The net effect of this is that if users are doing cache operations from 1.14
> and older clients, and their SecurityManager expires the credentials of the
> old clients, they will sometimes see their clients re-authenticate themselves
> in that time window. This will mislead users into thinking that
> re-authentication works with old clients and client queues, even though we
> [have documented that we don't support
> it|https://github.com/apache/geode/blob/09b8b46ef2fa1d463be885c6fa39dbfe1f0e3e83/geode-docs/managing/security/implementing_authentication_expiry.html.md.erb#L35].
> Instead of allowing re-authentication to sometimes work in this unsupported
> use case, we should always fail so that is clear to users that this use case
> is not supported.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-9476) VMStats processCpuTime, fdLimit, and fdsOpen will always be zero on java 16 and later
[
https://issues.apache.org/jira/browse/GEODE-9476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider updated GEODE-9476:
Labels: Java16 Java17 (was: Java16)
> VMStats processCpuTime, fdLimit, and fdsOpen will always be zero on java 16
> and later
> -
>
> Key: GEODE-9476
> URL: https://issues.apache.org/jira/browse/GEODE-9476
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Reporter: Darrel Schneider
>Priority: Major
> Labels: Java16, Java17
>
> VMStats processCpuTime, fdLimit, and fdsOpen will always be zero on java 16
> and later.
> This is because it calls Method.setAccessible which is not allowed under
> normal conditions starting with java 16 (see:
> https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16).
> A workaround for this bug is to start the jvm with --illegal-access=permit
> The setAccessible call is in the static initializer for:
> org.apache.geode.internal.stats50.VMStats50
> It turns out the following works for calling processCpuTime:
> {code:java}
> OperatingSystemMXBean osBean =
> ManagementFactory.getOperatingSystemMXBean();
> com.sun.management.OperatingSystemMXBean sunBean =
> (com.sun.management.OperatingSystemMXBean) osBean;
> System.out.println("getProcessCpuTime=" +
> sunBean.getProcessCpuTime());
> {code}
> so we can get rid of the setAccessible call
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10243) Old clients with durable queues should fail early if AuthenticationExpiredException is thrown
[
https://issues.apache.org/jira/browse/GEODE-10243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith reassigned GEODE-10243:
-
Assignee: Dan Smith
> Old clients with durable queues should fail early if
> AuthenticationExpiredException is thrown
> -
>
> Key: GEODE-10243
> URL: https://issues.apache.org/jira/browse/GEODE-10243
> Project: Geode
> Issue Type: Improvement
> Components: client queues
>Reporter: Dan Smith
>Assignee: Dan Smith
>Priority: Major
>
> As part of the changes for GEODE-9457, when an AuthenticationExpiredException
> is thrown from the SecurityManager during message dispatching, we send a
> message to 1.15 and newer clients asking them to re-authenticate.
> For 1.14 and older clients, we do not send a message. Instead, we just wait
> for the {color:#00875a}reauthenticate.wait.time{color} to elapse and then
> close the connection.
> The net effect of this is that if users are doing cache operations from 1.14
> and older clients, and their SecurityManager expires the credentials of the
> old clients, they will sometimes see their clients re-authenticate themselves
> in that time window. This will mislead users into thinking that
> re-authentication works with old clients and client queues, even though we
> [have documented that we don't support
> it|https://github.com/apache/geode/blob/09b8b46ef2fa1d463be885c6fa39dbfe1f0e3e83/geode-docs/managing/security/implementing_authentication_expiry.html.md.erb#L35].
> Instead of allowing re-authentication to sometimes work in this unsupported
> use case, we should always fail so that is clear to users that this use case
> is not supported.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9468) tomcat session state management will not work on java 16
[ https://issues.apache.org/jira/browse/GEODE-9468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522986#comment-17522986 ] Darrel Schneider commented on GEODE-9468: - These setAccessible class should not be an issue for geode 1.15 because the tomcat code is in the same unnamed module that geode is in so all the tomcat packages are open to geode. > tomcat session state management will not work on java 16 > > > Key: GEODE-9468 > URL: https://issues.apache.org/jira/browse/GEODE-9468 > Project: Geode > Issue Type: Bug > Components: http session >Reporter: Darrel Schneider >Priority: Major > Labels: Java16 > > The class org.apache.geode.modules.session.catalina.DeltaSession calls > Field.setAccessible in a static block. It is getting access to a field in the > super class which was private in tomcat 7 (see GEODE-3434). Because of this > tomcat session state management will not work on java 16 (see > [https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16/)] > unless jvm args are used to permit the call (for example > "--illegal-access=permit"). > If we can drop support for tomcat 7 then this reflection would no longer be > needed. It might also be possible to only call setAccessible if the field is > private which would mean only tomcat 7 would not work on java 16. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9470) Some geode queries will fail on java 16 and later
[ https://issues.apache.org/jira/browse/GEODE-9470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522985#comment-17522985 ] Darrel Schneider commented on GEODE-9470: - These setAccessible calls should not be an issue with geode 1.15 since any domain classes added by the user to the server's class path will need to not be in named modules so they will automatically be open to geode since both will be in the unnamed module. > Some geode queries will fail on java 16 and later > - > > Key: GEODE-9470 > URL: https://issues.apache.org/jira/browse/GEODE-9470 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Darrel Schneider >Priority: Major > Labels: Java16 > > In some cases a geode query uses reflection to read a field or call a > function. > If that happens on java 16 then the query will fail throwing a > RuntimeException that is an instance of > java.lang.reflect.InaccessibleObjectException. See: > https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16. > To workaround this failure set the JVM command line option: > --illegal-access=permit > The query code that calls setAccessible is in two places: > org.apache.geode.cache.query.internal.AttributeDescriptor#getReadMember > org.apache.geode.cache.query.internal.MethodDispatch#MethodDispatch -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9477) Geode membership will have issues on java 16 and later
[ https://issues.apache.org/jira/browse/GEODE-9477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522984#comment-17522984 ] Darrel Schneider commented on GEODE-9477: - I think none of these setAccessible calls are an issue for geode 1.15 because the jgroups we ship with geode is in the same unnamed module as geode so everything in jgroups is open to geode code. > Geode membership will have issues on java 16 and later > -- > > Key: GEODE-9477 > URL: https://issues.apache.org/jira/browse/GEODE-9477 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Darrel Schneider >Priority: Major > Labels: Java16 > > Geode membership uses setAccessible in a number of places to access jgroups > internals. > This will not work on java 16 and later (see: > https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16). > A workaround for this bug is to start the jvm with --illegal-access=permit > The places that call setAccessible in membership are: > * > org.apache.geode.distributed.internal.membership.gms.messenger.AddressManager#findPingDataMethod > (the catch in this method will not catch the RuntimeException thrown by > setAccessible) > * > org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger#setChannelReceiver > * > org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger#start > * > org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger#checkForIPv6 > * > org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger#establishLocalAddress -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10242) Same tail key can be generated for different events on (different colocated regions) from different servers
[ https://issues.apache.org/jira/browse/GEODE-10242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10242: --- Labels: GeodeOperationAPI blocks-1.15.0 needsTriage pull-request-available (was: GeodeOperationAPI blocks-1.15.0 needsTriage) > Same tail key can be generated for different events on (different colocated > regions) from different servers > --- > > Key: GEODE-10242 > URL: https://issues.apache.org/jira/browse/GEODE-10242 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.12.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, needsTriage, > pull-request-available > > For colocated partition regions with parallel wan queue, rebalance could > cause primary to be moved. This can lead to a case that one server has the > primary bucket for the parent region, but another has the primary bucket for > the child region. As colocated regions show the same parallel wan queue, both > server will generate next tail key for different events. This will cause some > event not dispatched to the other wan site and thus event lost. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-9474) the Geode offheap feature will fail on java 16
[ https://issues.apache.org/jira/browse/GEODE-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522983#comment-17522983 ] Darrel Schneider commented on GEODE-9474: - For Java17 we need to server to have "java.nio" opened for offheap to work. I think we should just add this to the list of opens needed by geode features. > the Geode offheap feature will fail on java 16 > -- > > Key: GEODE-9474 > URL: https://issues.apache.org/jira/browse/GEODE-9474 > Project: Geode > Issue Type: Bug > Components: offheap >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > > In two different places geode offheap calls setAccessible. In one place it is > to call the "address" method. In the other it is to call the DIrectByteBuffer > constructor that passes an address in to the constructor. These will not work > on java 16 and later because it calls Method.setAccessible which is not > allowed under normal conditions starting with java 16 (see: > https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16 ). > To workaround this failure set the JVM command line option: > --illegal-access=permit or use --add-opens. > The places that make the calls: > * > org.apache.geode.internal.offheap.AddressableMemoryManager#getDirectByteBufferAddress > * > org.apache.geode.internal.offheap.AddressableMemoryManager#createDirectByteBuffer > The "address" call does not need to use reflection and setAccessible but can > instead do it with casting. See > org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer for how this is done. > The constructor issue is a bigger problem. This constructor can be called > from JNI NewDirectByteBuffer but needing to add native code to geode does not > seem worth the trouble. If some other solution can not be found then the > above workaround would need to be used if offheap is. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-9474) the Geode offheap feature will fail on java 16
[ https://issues.apache.org/jira/browse/GEODE-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-9474: Labels: Java16 Java17 (was: Java16) > the Geode offheap feature will fail on java 16 > -- > > Key: GEODE-9474 > URL: https://issues.apache.org/jira/browse/GEODE-9474 > Project: Geode > Issue Type: Bug > Components: offheap >Reporter: Darrel Schneider >Priority: Major > Labels: Java16, Java17 > > In two different places geode offheap calls setAccessible. In one place it is > to call the "address" method. In the other it is to call the DIrectByteBuffer > constructor that passes an address in to the constructor. These will not work > on java 16 and later because it calls Method.setAccessible which is not > allowed under normal conditions starting with java 16 (see: > https://softwaregarden.dev/en/posts/new-java/illegal-access-in-java-16 ). > To workaround this failure set the JVM command line option: > --illegal-access=permit or use --add-opens. > The places that make the calls: > * > org.apache.geode.internal.offheap.AddressableMemoryManager#getDirectByteBufferAddress > * > org.apache.geode.internal.offheap.AddressableMemoryManager#createDirectByteBuffer > The "address" call does not need to use reflection and setAccessible but can > instead do it with casting. See > org.apache.geode.unsafe.internal.sun.nio.ch.DirectBuffer for how this is done. > The constructor issue is a bigger problem. This constructor can be called > from JNI NewDirectByteBuffer but needing to add native code to geode does not > seem worth the trouble. If some other solution can not be found then the > above workaround would need to be used if offheap is. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10197) OutOfMemoryDUnitTest fails on java 17 because CMSInitiatingOccupancyFraction no longer exists
[ https://issues.apache.org/jira/browse/GEODE-10197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10197: --- Labels: Java17 pull-request-available (was: Java17) > OutOfMemoryDUnitTest fails on java 17 because CMSInitiatingOccupancyFraction > no longer exists > - > > Key: GEODE-10197 > URL: https://issues.apache.org/jira/browse/GEODE-10197 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: Java17, pull-request-available > > This test is explicitly adding CMSInitiatingOccupancyFraction but cms has > been removed in later java releases. > OutOfMemoryDUnitTest > initializationError FAILED > org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple > Failures (2 failures) > org.opentest4j.AssertionFailedError: [The Cache Server process > terminated unexpectedly with exit status 1. > Unrecognized VM option 'CMSInitiatingOccupancyFraction=45' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10197) OutOfMemoryDUnitTest fails on java 17 because CMSInitiatingOccupancyFraction no longer exists
[ https://issues.apache.org/jira/browse/GEODE-10197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-10197: Assignee: Darrel Schneider > OutOfMemoryDUnitTest fails on java 17 because CMSInitiatingOccupancyFraction > no longer exists > - > > Key: GEODE-10197 > URL: https://issues.apache.org/jira/browse/GEODE-10197 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: Java17 > > This test is explicitly adding CMSInitiatingOccupancyFraction but cms has > been removed in later java releases. > OutOfMemoryDUnitTest > initializationError FAILED > org.gradle.internal.exceptions.DefaultMultiCauseException: Multiple > Failures (2 failures) > org.opentest4j.AssertionFailedError: [The Cache Server process > terminated unexpectedly with exit status 1. > Unrecognized VM option 'CMSInitiatingOccupancyFraction=45' > Error: Could not create the Java Virtual Machine. > Error: A fatal exception has occurred. Program will exit. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10243) Old clients with durable queues should fail early if AuthenticationExpiredException is thrown
Dan Smith created GEODE-10243:
-
Summary: Old clients with durable queues should fail early if
AuthenticationExpiredException is thrown
Key: GEODE-10243
URL: https://issues.apache.org/jira/browse/GEODE-10243
Project: Geode
Issue Type: Improvement
Components: client queues
Reporter: Dan Smith
As part of the changes for GEODE-9457, when an AuthenticationExpiredException
is thrown from the SecurityManager during message dispatching, we send a
message to 1.15 and newer clients asking them to re-authenticate.
For 1.14 and older clients, we do not send a message. Instead, we just wait for
the {color:#00875a}reauthenticate.wait.time{color} to elapse and then close the
connection.
The net effect of this is that if users are doing cache operations from 1.14
and older clients, and their SecurityManager expires the credentials of the old
clients, they will sometimes see their clients re-authenticate themselves in
that time window. This will mislead users into thinking that re-authentication
works with old clients and client queues, even though we [have documented that
we don't support
it|https://github.com/apache/geode/blob/09b8b46ef2fa1d463be885c6fa39dbfe1f0e3e83/geode-docs/managing/security/implementing_authentication_expiry.html.md.erb#L35].
Instead of allowing re-authentication to sometimes work in this unsupported use
case, we should always fail so that is clear to users that this use case is not
supported.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10242) Same tail key can be generated for different events on (different colocated regions) from different servers
[ https://issues.apache.org/jira/browse/GEODE-10242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10242: - Labels: GeodeOperationAPI blocks-1.15.0 needsTriage (was: blocks-1.15.0 needsTriage) > Same tail key can be generated for different events on (different colocated > regions) from different servers > --- > > Key: GEODE-10242 > URL: https://issues.apache.org/jira/browse/GEODE-10242 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.12.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: GeodeOperationAPI, blocks-1.15.0, needsTriage > > For colocated partition regions with parallel wan queue, rebalance could > cause primary to be moved. This can lead to a case that one server has the > primary bucket for the parent region, but another has the primary bucket for > the child region. As colocated regions show the same parallel wan queue, both > server will generate next tail key for different events. This will cause some > event not dispatched to the other wan site and thus event lost. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (GEODE-10242) Same tail key can be generated for different events on (different colocated regions) from different servers
[ https://issues.apache.org/jira/browse/GEODE-10242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu reassigned GEODE-10242: Assignee: Eric Shu > Same tail key can be generated for different events on (different colocated > regions) from different servers > --- > > Key: GEODE-10242 > URL: https://issues.apache.org/jira/browse/GEODE-10242 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.12.0 >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: blocks-1.15.0, needsTriage > > For colocated partition regions with parallel wan queue, rebalance could > cause primary to be moved. This can lead to a case that one server has the > primary bucket for the parent region, but another has the primary bucket for > the child region. As colocated regions show the same parallel wan queue, both > server will generate next tail key for different events. This will cause some > event not dispatched to the other wan site and thus event lost. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10242) Same tail key can be generated for different events on (different colocated regions) from different servers
[ https://issues.apache.org/jira/browse/GEODE-10242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10242: - Labels: blocks-1.15.0 needsTriage (was: needsTriage) > Same tail key can be generated for different events on (different colocated > regions) from different servers > --- > > Key: GEODE-10242 > URL: https://issues.apache.org/jira/browse/GEODE-10242 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Eric Shu >Priority: Major > Labels: blocks-1.15.0, needsTriage > > For colocated partition regions with parallel wan queue, rebalance could > cause primary to be moved. This can lead to a case that one server has the > primary bucket for the parent region, but another has the primary bucket for > the child region. As colocated regions show the same parallel wan queue, both > server will generate next tail key for different events. This will cause some > event not dispatched to the other wan site and thus event lost. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10242) Same tail key can be generated for different events on (different colocated regions) from different servers
[ https://issues.apache.org/jira/browse/GEODE-10242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10242: -- Labels: needsTriage (was: ) > Same tail key can be generated for different events on (different colocated > regions) from different servers > --- > > Key: GEODE-10242 > URL: https://issues.apache.org/jira/browse/GEODE-10242 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Eric Shu >Priority: Major > Labels: needsTriage > > For colocated partition regions with parallel wan queue, rebalance could > cause primary to be moved. This can lead to a case that one server has the > primary bucket for the parent region, but another has the primary bucket for > the child region. As colocated regions show the same parallel wan queue, both > server will generate next tail key for different events. This will cause some > event not dispatched to the other wan site and thus event lost. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10242) Same tail key can be generated for different events on (different colocated regions) from different servers
Eric Shu created GEODE-10242: Summary: Same tail key can be generated for different events on (different colocated regions) from different servers Key: GEODE-10242 URL: https://issues.apache.org/jira/browse/GEODE-10242 Project: Geode Issue Type: Bug Components: wan Reporter: Eric Shu For colocated partition regions with parallel wan queue, rebalance could cause primary to be moved. This can lead to a case that one server has the primary bucket for the parent region, but another has the primary bucket for the child region. As colocated regions show the same parallel wan queue, both server will generate next tail key for different events. This will cause some event not dispatched to the other wan site and thus event lost. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10242) Same tail key can be generated for different events on (different colocated regions) from different servers
[ https://issues.apache.org/jira/browse/GEODE-10242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Shu updated GEODE-10242: - Affects Version/s: 1.12.0 > Same tail key can be generated for different events on (different colocated > regions) from different servers > --- > > Key: GEODE-10242 > URL: https://issues.apache.org/jira/browse/GEODE-10242 > Project: Geode > Issue Type: Bug > Components: wan >Affects Versions: 1.12.0 >Reporter: Eric Shu >Priority: Major > Labels: blocks-1.15.0, needsTriage > > For colocated partition regions with parallel wan queue, rebalance could > cause primary to be moved. This can lead to a case that one server has the > primary bucket for the parent region, but another has the primary bucket for > the child region. As colocated regions show the same parallel wan queue, both > server will generate next tail key for different events. This will cause some > event not dispatched to the other wan site and thus event lost. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-5337) Geode1.5 end-port is not exclusive when creating a gateway-receiver
[
https://issues.apache.org/jira/browse/GEODE-5337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Owen Nichols updated GEODE-5337:
Fix Version/s: 1.12.10
1.14.5
> Geode1.5 end-port is not exclusive when creating a gateway-receiver
>
>
> Key: GEODE-5337
> URL: https://issues.apache.org/jira/browse/GEODE-5337
> Project: Geode
> Issue Type: Bug
> Components: docs
>Reporter: Cui Chenxiao
>Assignee: Alberto Bustamante Reyes
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.10, 1.14.5, 1.15.0
>
>
> When created, a gateway-receiver shall be assign a range of port to use.
> In document
> [http://geode.apache.org/docs/guide/16/tools_modules/gfsh/command-pages/create.html#topic_a4x_pb1_dk],
> the description for --end-port says "The {{ENDPORT}} value is exclusive
> while the {{STARTPORT}} value is inclusive. ".
>
> However, sometimes, the port number of endport is also assigned to receiver
> anyway. Besides, in code for gatewayreceiver, the endport will be randomly
> assigned to receiver.
>
> I supposed this shall be a document bug.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-4709) Sample output missing in gfsh docs for 'list gateways'
[ https://issues.apache.org/jira/browse/GEODE-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Owen Nichols updated GEODE-4709: Fix Version/s: 1.12.10 1.14.5 > Sample output missing in gfsh docs for 'list gateways' > -- > > Key: GEODE-4709 > URL: https://issues.apache.org/jira/browse/GEODE-4709 > Project: Geode > Issue Type: Bug > Components: docs >Reporter: Diane Hardman >Assignee: Alberto Bustamante Reyes >Priority: Minor > Labels: pull-request-available > Fix For: 1.12.10, 1.14.5, 1.15.0 > > > It looks like all other 'list' commands have both Example commands and Sample > Output except for 'list gateways'. Please add. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10241) Need to temporarily disable "reAuthenticateWithDurable" test
[ https://issues.apache.org/jira/browse/GEODE-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522948#comment-17522948 ] ASF subversion and git services commented on GEODE-10241: - Commit 51a7ad4972665ab9f0d5231f3a603150caecf303 in geode-native's branch refs/heads/develop from Blake Bender [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=51a7ad497 ] GEODE-10241: disable re-auth test until we can implement properly (#961) > Need to temporarily disable "reAuthenticateWithDurable" test > > > Key: GEODE-10241 > URL: https://issues.apache.org/jira/browse/GEODE-10241 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: needsTriage, pull-request-available > > This test is verifying geode-native works with a feature which is not yet > released (forthcoming in Geode 1.15), and whose implementation has recently > changed. The test is now failing, and needs to be implemented properly > according to the spec for the token authentication feature. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10241) Need to temporarily disable "reAuthenticateWithDurable" test
[ https://issues.apache.org/jira/browse/GEODE-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522947#comment-17522947 ] ASF GitHub Bot commented on GEODE-10241: pdxcodemonkey merged PR #961: URL: https://github.com/apache/geode-native/pull/961 > Need to temporarily disable "reAuthenticateWithDurable" test > > > Key: GEODE-10241 > URL: https://issues.apache.org/jira/browse/GEODE-10241 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: needsTriage, pull-request-available > > This test is verifying geode-native works with a feature which is not yet > released (forthcoming in Geode 1.15), and whose implementation has recently > changed. The test is now failing, and needs to be implemented properly > according to the spec for the token authentication feature. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10148) [CI Failure] : JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer FAILED
[
https://issues.apache.org/jira/browse/GEODE-10148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522937#comment-17522937
]
Barrett Oglesby commented on GEODE-10148:
-
I think here is where the problem is:
{{LocalManager.startLocalManagement}} runs the {{ManagementTask}} once right
when it starts.
With logging added, the call to {{managementTask.get().run()}} returns right
away. Even though the comment says its a synchronous call, it isn't.
{noformat}
[vm3] [warn 2022/03/23 16:16:02.173 PDT server-3 tid=0x12] XXX LocalManager.startLocalManagement about
to run managementTask
[vm3] [warn 2022/03/23 16:16:02.173 PDT server-3 tid=0x12] XXX LocalManager.startLocalManagement done
managementTask
{noformat}
Then, {{LocalManager.markForFederation}} adds the mbeans to the
{{federatedComponentMap}}:
{noformat}
[vm3] [warn 2022/03/23 16:16:02.209 PDT server-3 tid=0x12] XXX LocalManager.markForFederation about to
add to federatedComponentMap objName=GemFire:type=Member,member=server-3
[vm3] [warn 2022/03/23 16:16:02.364 PDT server-3 tid=0x12] XXX LocalManager.markForFederation about to
add to federatedComponentMap
objName=GemFire:service=Region,name="/test-region-1",type=Member,member=server-3
[vm3] [warn 2022/03/23 16:16:02.437 PDT server-3 tid=0x12] XXX LocalManager.markForFederation about to
add to federatedComponentMap
objName=GemFire:service=CacheServer,port=20017,type=Member,member=server-3
{noformat}
The CacheServer mbean above is the one that is missing in the failed run.
Then, the {{Management Task}} thread runs the {{ManagementTask}} started above
to put the mbeans into the region:
{noformat}
[vm3] [warn 2022/03/23 16:16:04.177 PDT server-3 tid=0x46]
XXX LocalManager.doManagementTask about to putAll
replicaMap={GemFire:service=CacheServer,port=20017,type=Member,member=server-3=ObjectName
= GemFire:service=CacheServer,port=20017,type=Member,member=server-3,
GemFire:service=Region,name="/test-region-1",type=Member,member=server-3=ObjectName
= GemFire:service=Region,name="/test-region-1",type=Member,member=server-3,
GemFire:type=Member,member=server-3=ObjectName =
GemFire:type=Member,member=server-3}
[vm3] [warn 2022/03/23 16:16:04.211 PDT server-3 tid=0x46]
XXX LocalManager.doManagementTask done putAll
replicaMap={GemFire:service=CacheServer,port=20017,type=Member,member=server-3=ObjectName
= GemFire:service=CacheServer,port=20017,type=Member,member=server-3,
GemFire:service=Region,name="/test-region-1",type=Member,member=server-3=ObjectName
= GemFire:service=Region,name="/test-region-1",type=Member,member=server-3,
GemFire:type=Member,member=server-3=ObjectName =
GemFire:type=Member,member=server-3}
{noformat}
If the {{Management Task}} thread runs between the added Region and CacheServer
mbeans, this issue would reproduce.
> [CI Failure] : JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer
> FAILED
> --
>
> Key: GEODE-10148
> URL: https://issues.apache.org/jira/browse/GEODE-10148
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Priority: Major
> Labels: test-stability
>
> JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer FAILED
> java.lang.AssertionError:
> Expecting actual:
> ["GemFire:service=AccessControl,type=Distributed",
> "GemFire:service=CacheServer,port=20842,type=Member,member=server-1",
> "GemFire:service=CacheServer,port=20846,type=Member,member=server-2",
>
> "GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-one",
> "GemFire:service=FileUploader,type=Distributed",
> "GemFire:service=Locator,type=Member,member=locator-one",
>
> "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed",
>
> "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-one",
> "GemFire:service=Manager,type=Member,member=locator-one",
> "GemFire:service=Region,name="/test-region-1",type=Distributed",
>
> "GemFire:service=Region,name="/test-region-1",type=Member,member=server-1",
>
> "GemFire:service=Region,name="/test-region-1",type=Member,member=server-2",
>
> "GemFire:service=Region,name="/test-region-1",type=Member,member=server-3",
> "GemFire:service=System,type=Distributed",
> "GemFire:type=Member,member=locator-one",
> "GemFire:type=Member,member=server-1",
> "GemFire:type=Member,member=server-2",
> "GemFire:type=Member,member=server-3"]
> to contain exactly (and in same order):
> ["GemFire:service=AccessControl,type=Distributed",
> "GemFire:service=CacheServer,port=20842,type=Member,member=server-1",
>
[jira] [Updated] (GEODE-10236) Compatibility issues while upgrading Jgroups to versions 4.0+
[
https://issues.apache.org/jira/browse/GEODE-10236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10236:
--
Labels: (was: needsTriage)
> Compatibility issues while upgrading Jgroups to versions 4.0+
> -
>
> Key: GEODE-10236
> URL: https://issues.apache.org/jira/browse/GEODE-10236
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.4
>Reporter: Rohan Jagtap
>Priority: Major
>
> According to a recent CVE:
> {quote}CVE-2016-2141
> NVD: 2016/06/30 - CVSS v2 Base Score: 7.5 - CVSS v3.1 Base Score: 9.8
> JGroups before 4.0 does not require the proper headers for the ENCRYPT and
> AUTH protocols from nodes joining the cluster, which allows remote attackers
> to bypass security restrictions and send and receive messages within the
> cluster via unspecified vectors.
>
> {quote}
> Hence we intend to upgrade jgroups to a recommended version.
> However, even the latest version of apache geode ([geode-core
> 1.14.4|https://mvnrepository.com/artifact/org.apache.geode/geode-core/1.14.4])
> uses jgroups 3.6.14 which has the aforementioned vulnerability.
> Overriding the jgroups dependency to anything over 4.0+ gives the following
> issue on running:
> {{Caused by: org.springframework.beans.factory.BeanCreationException: Error
> creating bean with name 'gemfireCache': FactoryBean threw exception on object
> creation; nested exception is java.lang.ExceptionInInitializerError}}
> {{ at
> org.springframework.beans.factory.support.FactoryBeanRegistrySupport.doGetObjectFromFactoryBean(FactoryBeanRegistrySupport.java:176)}}
> {{ at
> org.springframework.beans.factory.support.FactoryBeanRegistrySupport.getObjectFromFactoryBean(FactoryBeanRegistrySupport.java:101)}}
> {{ at
> org.springframework.beans.factory.support.AbstractBeanFactory.getObjectForBeanInstance(AbstractBeanFactory.java:1828)}}
> {{ at
> org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.getObjectForBeanInstance(AbstractAutowireCapableBeanFactory.java:1265)}}
> {{ at
> org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:334)}}
> {{ at
> org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:202)}}
> {{ at
> org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveReference(BeanDefinitionValueResolver.java:330)}}
> {{ ... 32 common frames omitted}}
> {{Caused by: java.lang.ExceptionInInitializerError: null}}
> {{ at
> org.apache.geode.distributed.internal.membership.gms.Services.(Services.java:155)}}
> {{ at
> org.apache.geode.distributed.internal.membership.gms.MembershipBuilderImpl.create(MembershipBuilderImpl.java:114)}}
> {{ at
> org.apache.geode.distributed.internal.DistributionImpl.(DistributionImpl.java:150)}}
> {{ at
> org.apache.geode.distributed.internal.DistributionImpl.createDistribution(DistributionImpl.java:217)}}
> {{ at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:464)}}
> {{ at
> org.apache.geode.distributed.internal.ClusterDistributionManager.(ClusterDistributionManager.java:497)}}
> {{ at
> org.apache.geode.distributed.internal.ClusterDistributionManager.create(ClusterDistributionManager.java:326)}}
> {{ at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:779)}}
> {{ at
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)}}
> {{ at
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3036)}}
> {{ at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)}}
> {{ at
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:216)}}
> {{ at
> org.apache.geode.internal.cache.InternalCacheBuilder.createInternalDistributedSystem(InternalCacheBuilder.java:346)}}
> {{ at java.base/java.util.Optional.orElseGet(Optional.java:369)}}
> {{ at
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:157)}}
> {{ at
> org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)}}
> {{ at
> org.springframework.data.gemfire.CacheFactoryBean.createCache(CacheFactoryBean.java:472)}}
> {{ at
> org.springframework.data.gemfire.CacheFactoryBean.resolveCache(CacheFactoryBean.java:326)}}
> {{ at
> org.springframework.data.gemfire.CacheFactoryBean.init(CacheFactoryBean.java:270)}}
> {{ at
[jira] [Updated] (GEODE-10223) BlockingCommandListenerTest > testTimeoutIsAdjusted fails on Windows due to timeout not changing
[
https://issues.apache.org/jira/browse/GEODE-10223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10223:
--
Fix Version/s: 1.15.0
(was: 1.12.10)
> BlockingCommandListenerTest > testTimeoutIsAdjusted fails on Windows due to
> timeout not changing
>
>
> Key: GEODE-10223
> URL: https://issues.apache.org/jira/browse/GEODE-10223
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Anthony Baker
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> > Task :geode-for-redis:integrationTest
> BlockingCommandListenerTest > testTimeoutIsAdjusted FAILED
> java.lang.AssertionError:
> Expecting actual:
> 1.0
> to be less than:
> 1.0
> at
> org.apache.geode.redis.internal.eventing.BlockingCommandListenerTest.testTimeoutIsAdjusted(BlockingCommandListenerTest.java:61){noformat}
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}= Test Results URI
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}=
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1081/test-results/integrationTest/1649299123/]
>
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1081/test-artifacts/1649299123/windows-integrationtestfiles-openjdk11-1.15.0-build.1081.tgz]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10074) Remove ACE remains
[ https://issues.apache.org/jira/browse/GEODE-10074?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522925#comment-17522925 ] ASF GitHub Bot commented on GEODE-10074: gaussianrecurrence commented on PR #928: URL: https://github.com/apache/geode-native/pull/928#issuecomment-1100278048 > @gaussianrecurrence please rebase to resolve conflicts, and I will merge ASAP. Thanks! Sorry for the huge delay. I've updated the branch and solved the conflict. > Remove ACE remains > -- > > Key: GEODE-10074 > URL: https://issues.apache.org/jira/browse/GEODE-10074 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Mario Salazar de Torres >Assignee: Mario Salazar de Torres >Priority: Major > Labels: obliterate-ace, pull-request-available > > *AS A* geode-native contributor > *I WANT TO* remove all the ACE remaining > *SO THAT* geode-native does not depend on ACE anymore -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10224) geode-connectors:acceptanceTest task hang in CI with no tests started
[
https://issues.apache.org/jira/browse/GEODE-10224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charlie Black updated GEODE-10224:
--
Labels: test (was: )
> geode-connectors:acceptanceTest task hang in CI with no tests started
> -
>
> Key: GEODE-10224
> URL: https://issues.apache.org/jira/browse/GEODE-10224
> Project: Geode
> Issue Type: Bug
> Components: ci
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
> Labels: test
>
> A hang was observed in a CI run of acceptance-test-openjdk8:
> {noformat}
> 20:37:25> Task :geode-deployment:geode-deployment-legacy:publishToMavenLocal
> 20:37:55> Task :geode-assembly:acceptanceTest
> 21:44:13> Task :geode-common:compileAcceptanceTestJava NO-SOURCE
> 21:44:13> Task :geode-common:processAcceptanceTestResources NO-SOURCE
> 21:44:13> Task :geode-common:acceptanceTestClasses UP-TO-DATE
> 21:44:13> Task :geode-common:acceptanceTest NO-SOURCE
> 21:44:13> Task :geode-concurrency-test:compileAcceptanceTestJava NO-SOURCE
> 21:44:13> Task :geode-concurrency-test:processAcceptanceTestResources
> NO-SOURCE
> 21:44:13> Task :geode-concurrency-test:acceptanceTestClasses UP-TO-DATE
> 21:44:13> Task :geode-concurrency-test:acceptanceTest NO-SOURCE
> 21:44:16> Task :geode-connectors:compileAcceptanceTestJava
> 21:44:16> Task :geode-connectors:processAcceptanceTestResources
> 21:44:16> Task :geode-connectors:acceptanceTestClasses
> 21:44:46> Task :geode-connectors:acceptanceTest
> 21:44:46
> timeout exceeded{noformat}
> The geode-common:acceptanceTest task was able to complete normally, but the
> test result artifacts for the run, linked below, show no
> acceptanceTest-progress.txt in the {{geode-connectors/build/acceptanceTest}}
> directory, and no output in
> {{{}geode-connectors/build/test-results/acceptanceTest/binary/output.bin{}}},
> indicating that no tests from geode-connectors were able to start.
> A subsequent run of the job passed with no issue.
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}= Test Results URI
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}=
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1082/test-results/acceptanceTest/1649316934/]
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1082/test-artifacts/1649316934/acceptancetestfiles-openjdk8-1.15.0-build.1082.tgz]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-10223) BlockingCommandListenerTest > testTimeoutIsAdjusted fails on Windows due to timeout not changing
[
https://issues.apache.org/jira/browse/GEODE-10223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker reassigned GEODE-10223:
-
Assignee: Anthony Baker
> BlockingCommandListenerTest > testTimeoutIsAdjusted fails on Windows due to
> timeout not changing
>
>
> Key: GEODE-10223
> URL: https://issues.apache.org/jira/browse/GEODE-10223
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Anthony Baker
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.12.10
>
>
> {noformat}
> > Task :geode-for-redis:integrationTest
> BlockingCommandListenerTest > testTimeoutIsAdjusted FAILED
> java.lang.AssertionError:
> Expecting actual:
> 1.0
> to be less than:
> 1.0
> at
> org.apache.geode.redis.internal.eventing.BlockingCommandListenerTest.testTimeoutIsAdjusted(BlockingCommandListenerTest.java:61){noformat}
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}= Test Results URI
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}=
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1081/test-results/integrationTest/1649299123/]
>
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1081/test-artifacts/1649299123/windows-integrationtestfiles-openjdk11-1.15.0-build.1081.tgz]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10223) BlockingCommandListenerTest > testTimeoutIsAdjusted fails on Windows due to timeout not changing
[
https://issues.apache.org/jira/browse/GEODE-10223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-10223:
--
Labels: pull-request-available (was: needsTriage pull-request-available)
> BlockingCommandListenerTest > testTimeoutIsAdjusted fails on Windows due to
> timeout not changing
>
>
> Key: GEODE-10223
> URL: https://issues.apache.org/jira/browse/GEODE-10223
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Assignee: Anthony Baker
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.12.10
>
>
> {noformat}
> > Task :geode-for-redis:integrationTest
> BlockingCommandListenerTest > testTimeoutIsAdjusted FAILED
> java.lang.AssertionError:
> Expecting actual:
> 1.0
> to be less than:
> 1.0
> at
> org.apache.geode.redis.internal.eventing.BlockingCommandListenerTest.testTimeoutIsAdjusted(BlockingCommandListenerTest.java:61){noformat}
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}= Test Results URI
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}=
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1081/test-results/integrationTest/1649299123/]
>
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1081/test-artifacts/1649299123/windows-integrationtestfiles-openjdk11-1.15.0-build.1081.tgz]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-10223) BlockingCommandListenerTest > testTimeoutIsAdjusted fails on Windows due to timeout not changing
[
https://issues.apache.org/jira/browse/GEODE-10223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charlie Black resolved GEODE-10223.
---
Fix Version/s: 1.12.10
Resolution: Fixed
Pull request merged.
> BlockingCommandListenerTest > testTimeoutIsAdjusted fails on Windows due to
> timeout not changing
>
>
> Key: GEODE-10223
> URL: https://issues.apache.org/jira/browse/GEODE-10223
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
> Labels: needsTriage, pull-request-available
> Fix For: 1.12.10
>
>
> {noformat}
> > Task :geode-for-redis:integrationTest
> BlockingCommandListenerTest > testTimeoutIsAdjusted FAILED
> java.lang.AssertionError:
> Expecting actual:
> 1.0
> to be less than:
> 1.0
> at
> org.apache.geode.redis.internal.eventing.BlockingCommandListenerTest.testTimeoutIsAdjusted(BlockingCommandListenerTest.java:61){noformat}
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}= Test Results URI
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}=
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1081/test-results/integrationTest/1649299123/]
>
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1081/test-artifacts/1649299123/windows-integrationtestfiles-openjdk11-1.15.0-build.1081.tgz]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10228) CI Failure: DurableClientTestCase > testDurableHAFailover times out in await for failover
[
https://issues.apache.org/jira/browse/GEODE-10228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522923#comment-17522923
]
Geode Integration commented on GEODE-10228:
---
Seen in [distributed-test-openjdk8
#314|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/distributed-test-openjdk8/builds/314]
... see [test
results|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1110/test-results/distributedTest/1650043297/]
or download
[artifacts|http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1110/test-artifacts/1650043297/distributedtestfiles-openjdk8-1.15.0-build.1110.tgz].
> CI Failure: DurableClientTestCase > testDurableHAFailover times out in await
> for failover
> -
>
> Key: GEODE-10228
> URL: https://issues.apache.org/jira/browse/GEODE-10228
> Project: Geode
> Issue Type: Bug
> Components: client/server, tests
>Reporter: Kirk Lund
>Assignee: Mark Hanson
>Priority: Major
> Labels: needsTriage
> Fix For: 1.15.0
>
>
> {{testDurableHAFailover}} has a history of flakiness, thought the stacks do
> seem to have changed some since the older versions of the but were resolved.
> {noformat}
> urableClientTestCase > testDurableHAFailover FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.internal.IdentifiableRunnable.run in VM 2 running
> on Host
> heavy-lifter-7bbf0b58-8bc0-5ca8-840d-7bcf83293b6d.c.apachegeode-ci.internal
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:435)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.durableFailover(DurableClientTestCase.java:520)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.testDurableHAFailover(DurableClientTestCase.java:439)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Assertion condition
> defined as a lambda expression in
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase
> expected: null
> but was: "0"="0" within 5 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> 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:985)
> at
> org.awaitility.core.ConditionFactory.untilAsserted(ConditionFactory.java:769)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$durableFailover$3f73998b$1(DurableClientTestCase.java:521)
> Caused by:
> org.opentest4j.AssertionFailedError:
> expected: null
> but was: "0"="0"
> at
> sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.internal.cache.tier.sockets.DurableClientTestCase.lambda$null$2(DurableClientTestCase.java:525)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-8760) P2pPartitionedPutBenchmark fails with UnmarshalException
[
https://issues.apache.org/jira/browse/GEODE-8760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522922#comment-17522922
]
Geode Integration commented on GEODE-8760:
--
Seen in [benchmark-base
#288|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/benchmark-base/builds/288].
> P2pPartitionedPutBenchmark fails with UnmarshalException
>
>
> Key: GEODE-8760
> URL: https://issues.apache.org/jira/browse/GEODE-8760
> Project: Geode
> Issue Type: Bug
> Components: benchmarks
>Affects Versions: 1.14.0
>Reporter: Bill Burcham
>Priority: Major
>
> {code:java}
> > Task :geode-benchmarks:benchmark
> org.apache.geode.benchmark.tests.P2pPartitionedPutBenchmark > run() FAILED
> java.util.concurrent.CompletionException: java.lang.RuntimeException:
> java.rmi.UnmarshalException: Error unmarshaling return header; nested
> exception is:
> java.io.EOFException
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:273)
> at
> java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:280)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1643)
> 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)
> Caused by:
> java.lang.RuntimeException: java.rmi.UnmarshalException: Error
> unmarshaling return header; nested exception is:
> java.io.EOFException
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:89)
> at
> java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1640)
> ... 3 more
> Caused by:
> java.rmi.UnmarshalException: Error unmarshaling return header;
> nested exception is:
> java.io.EOFException
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:254)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:164)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:235)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:180)
> at com.sun.proxy.$Proxy13.execute(Unknown Source)
> at
> org.apache.geode.perftest.jvms.rmi.Controller.lambda$onWorker$0(Controller.java:87)
> ... 4 more
> Caused by:
> java.io.EOFException
> at
> java.io.DataInputStream.readByte(DataInputStream.java:267)
> at
> sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:240)
> ... 9 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (GEODE-10148) [CI Failure] : JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer FAILED
[ https://issues.apache.org/jira/browse/GEODE-10148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charlie Black updated GEODE-10148: -- Labels: test-stability (was: ) > [CI Failure] : JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer > FAILED > -- > > Key: GEODE-10148 > URL: https://issues.apache.org/jira/browse/GEODE-10148 > Project: Geode > Issue Type: Bug > Components: jmx >Affects Versions: 1.15.0 >Reporter: Nabarun Nag >Priority: Major > Labels: test-stability > > JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer FAILED > java.lang.AssertionError: > Expecting actual: > ["GemFire:service=AccessControl,type=Distributed", > "GemFire:service=CacheServer,port=20842,type=Member,member=server-1", > "GemFire:service=CacheServer,port=20846,type=Member,member=server-2", > > "GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-one", > "GemFire:service=FileUploader,type=Distributed", > "GemFire:service=Locator,type=Member,member=locator-one", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-one", > "GemFire:service=Manager,type=Member,member=locator-one", > "GemFire:service=Region,name="/test-region-1",type=Distributed", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-1", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-2", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-3", > "GemFire:service=System,type=Distributed", > "GemFire:type=Member,member=locator-one", > "GemFire:type=Member,member=server-1", > "GemFire:type=Member,member=server-2", > "GemFire:type=Member,member=server-3"] > to contain exactly (and in same order): > ["GemFire:service=AccessControl,type=Distributed", > "GemFire:service=CacheServer,port=20842,type=Member,member=server-1", > "GemFire:service=CacheServer,port=20846,type=Member,member=server-2", > "GemFire:service=CacheServer,port=20850,type=Member,member=server-3", > > "GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-one", > "GemFire:service=FileUploader,type=Distributed", > "GemFire:service=Locator,type=Member,member=locator-one", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-one", > "GemFire:service=Manager,type=Member,member=locator-one", > "GemFire:service=Region,name="/test-region-1",type=Distributed", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-1", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-2", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-3", > "GemFire:service=System,type=Distributed", > "GemFire:type=Member,member=locator-one", > "GemFire:type=Member,member=server-1", > "GemFire:type=Member,member=server-2", > "GemFire:type=Member,member=server-3"] > but could not find the following elements: > ["GemFire:service=CacheServer,port=20850,type=Member,member=server-3"] > at > org.apache.geode.management.internal.JMXMBeanFederationDUnitTest.MBeanFederationAddRemoveServer(JMXMBeanFederationDUnitTest.java:130) > 8352 tests completed, 1 failed, 414 skipped -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10240) CI Failure: CreateMappingCommandInterceptorTest. preExecutionGivenDirectoryAsPdxClassFileReturnsError
[
https://issues.apache.org/jira/browse/GEODE-10240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charlie Black updated GEODE-10240:
--
Labels: test-stability (was: )
> CI Failure: CreateMappingCommandInterceptorTest.
> preExecutionGivenDirectoryAsPdxClassFileReturnsError
> -
>
> Key: GEODE-10240
> URL: https://issues.apache.org/jira/browse/GEODE-10240
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Priority: Major
> Labels: test-stability
>
> {noformat}
> java.io.IOException: a folder with the name 'tempFolder' already exists
> at org.junit.rules.TemporaryFolder.newFolder(TemporaryFolder.java:100)
> at org.junit.rules.TemporaryFolder.newFolder(TemporaryFolder.java:86)
> at
> org.apache.geode.connectors.jdbc.internal.cli.CreateMappingCommandInterceptorTest.preExecutionGivenDirectoryAsPdxClassFileReturnsError(CreateMappingCommandInterceptorTest.java:62)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
>
[jira] [Updated] (GEODE-10240) CI Failure: CreateMappingCommandInterceptorTest. preExecutionGivenDirectoryAsPdxClassFileReturnsError
[
https://issues.apache.org/jira/browse/GEODE-10240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charlie Black updated GEODE-10240:
--
Labels: (was: needsTriage)
> CI Failure: CreateMappingCommandInterceptorTest.
> preExecutionGivenDirectoryAsPdxClassFileReturnsError
> -
>
> Key: GEODE-10240
> URL: https://issues.apache.org/jira/browse/GEODE-10240
> Project: Geode
> Issue Type: Bug
>Reporter: Jianxia Chen
>Priority: Major
>
> {noformat}
> java.io.IOException: a folder with the name 'tempFolder' already exists
> at org.junit.rules.TemporaryFolder.newFolder(TemporaryFolder.java:100)
> at org.junit.rules.TemporaryFolder.newFolder(TemporaryFolder.java:86)
> at
> org.apache.geode.connectors.jdbc.internal.cli.CreateMappingCommandInterceptorTest.preExecutionGivenDirectoryAsPdxClassFileReturnsError(CreateMappingCommandInterceptorTest.java:62)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
>
[jira] [Updated] (GEODE-10148) [CI Failure] : JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer FAILED
[ https://issues.apache.org/jira/browse/GEODE-10148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charlie Black updated GEODE-10148: -- Labels: (was: needsTriage) > [CI Failure] : JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer > FAILED > -- > > Key: GEODE-10148 > URL: https://issues.apache.org/jira/browse/GEODE-10148 > Project: Geode > Issue Type: Bug > Components: jmx >Affects Versions: 1.15.0 >Reporter: Nabarun Nag >Priority: Major > > JMXMBeanFederationDUnitTest > MBeanFederationAddRemoveServer FAILED > java.lang.AssertionError: > Expecting actual: > ["GemFire:service=AccessControl,type=Distributed", > "GemFire:service=CacheServer,port=20842,type=Member,member=server-1", > "GemFire:service=CacheServer,port=20846,type=Member,member=server-2", > > "GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-one", > "GemFire:service=FileUploader,type=Distributed", > "GemFire:service=Locator,type=Member,member=locator-one", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-one", > "GemFire:service=Manager,type=Member,member=locator-one", > "GemFire:service=Region,name="/test-region-1",type=Distributed", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-1", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-2", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-3", > "GemFire:service=System,type=Distributed", > "GemFire:type=Member,member=locator-one", > "GemFire:type=Member,member=server-1", > "GemFire:type=Member,member=server-2", > "GemFire:type=Member,member=server-3"] > to contain exactly (and in same order): > ["GemFire:service=AccessControl,type=Distributed", > "GemFire:service=CacheServer,port=20842,type=Member,member=server-1", > "GemFire:service=CacheServer,port=20846,type=Member,member=server-2", > "GemFire:service=CacheServer,port=20850,type=Member,member=server-3", > > "GemFire:service=DiskStore,name=cluster_config,type=Member,member=locator-one", > "GemFire:service=FileUploader,type=Distributed", > "GemFire:service=Locator,type=Member,member=locator-one", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Distributed", > > "GemFire:service=LockService,name=__CLUSTER_CONFIG_LS,type=Member,member=locator-one", > "GemFire:service=Manager,type=Member,member=locator-one", > "GemFire:service=Region,name="/test-region-1",type=Distributed", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-1", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-2", > > "GemFire:service=Region,name="/test-region-1",type=Member,member=server-3", > "GemFire:service=System,type=Distributed", > "GemFire:type=Member,member=locator-one", > "GemFire:type=Member,member=server-1", > "GemFire:type=Member,member=server-2", > "GemFire:type=Member,member=server-3"] > but could not find the following elements: > ["GemFire:service=CacheServer,port=20850,type=Member,member=server-3"] > at > org.apache.geode.management.internal.JMXMBeanFederationDUnitTest.MBeanFederationAddRemoveServer(JMXMBeanFederationDUnitTest.java:130) > 8352 tests completed, 1 failed, 414 skipped -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10224) geode-connectors:acceptanceTest task hang in CI with no tests started
[
https://issues.apache.org/jira/browse/GEODE-10224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Charlie Black updated GEODE-10224:
--
Labels: (was: needsTriage)
> geode-connectors:acceptanceTest task hang in CI with no tests started
> -
>
> Key: GEODE-10224
> URL: https://issues.apache.org/jira/browse/GEODE-10224
> Project: Geode
> Issue Type: Bug
> Components: ci
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
>
> A hang was observed in a CI run of acceptance-test-openjdk8:
> {noformat}
> 20:37:25> Task :geode-deployment:geode-deployment-legacy:publishToMavenLocal
> 20:37:55> Task :geode-assembly:acceptanceTest
> 21:44:13> Task :geode-common:compileAcceptanceTestJava NO-SOURCE
> 21:44:13> Task :geode-common:processAcceptanceTestResources NO-SOURCE
> 21:44:13> Task :geode-common:acceptanceTestClasses UP-TO-DATE
> 21:44:13> Task :geode-common:acceptanceTest NO-SOURCE
> 21:44:13> Task :geode-concurrency-test:compileAcceptanceTestJava NO-SOURCE
> 21:44:13> Task :geode-concurrency-test:processAcceptanceTestResources
> NO-SOURCE
> 21:44:13> Task :geode-concurrency-test:acceptanceTestClasses UP-TO-DATE
> 21:44:13> Task :geode-concurrency-test:acceptanceTest NO-SOURCE
> 21:44:16> Task :geode-connectors:compileAcceptanceTestJava
> 21:44:16> Task :geode-connectors:processAcceptanceTestResources
> 21:44:16> Task :geode-connectors:acceptanceTestClasses
> 21:44:46> Task :geode-connectors:acceptanceTest
> 21:44:46
> timeout exceeded{noformat}
> The geode-common:acceptanceTest task was able to complete normally, but the
> test result artifacts for the run, linked below, show no
> acceptanceTest-progress.txt in the {{geode-connectors/build/acceptanceTest}}
> directory, and no output in
> {{{}geode-connectors/build/test-results/acceptanceTest/binary/output.bin{}}},
> indicating that no tests from geode-connectors were able to start.
> A subsequent run of the job passed with no issue.
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}= Test Results URI
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}=
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1082/test-results/acceptanceTest/1649316934/]
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1082/test-artifacts/1649316934/acceptancetestfiles-openjdk8-1.15.0-build.1082.tgz]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-10238) Jetty9CachingClientServerTest fails on java 17
[
https://issues.apache.org/jira/browse/GEODE-10238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-10238.
--
Fix Version/s: 1.15.0
Resolution: Fixed
> Jetty9CachingClientServerTest fails on java 17
> --
>
> Key: GEODE-10238
> URL: https://issues.apache.org/jira/browse/GEODE-10238
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java17, pull-request-available
> Fix For: 1.15.0
>
>
> {noformat}
> Jetty9CachingClientServerTest > shouldCacheSessionOnClient FAILED
> org.opentest4j.AssertionFailedError:
> expected: ""
> but was: "Error in servlet:
> java.lang.reflect.InaccessibleObjectException: Unable to make field private
> transient sun.security.provider.AbstractDrbg sun.security.provider.DRBG.impl
> accessible: module java.base does not "opens sun.security.provider" to
> unnamed module @47874b25"
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:59)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10238) Jetty9CachingClientServerTest fails on java 17
[
https://issues.apache.org/jira/browse/GEODE-10238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522886#comment-17522886
]
ASF subversion and git services commented on GEODE-10238:
-
Commit 4f74e6de9d9768520a2282c0dc5b69c611779f7d in geode's branch
refs/heads/develop from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=4f74e6de9d ]
GEODE-10238: add open for jetty9 on java 17 (#7593)
* added open for sun.security.provider for jetty9
* test now expects stack to contain "Connection refused" instead of "Connection
refused "
> Jetty9CachingClientServerTest fails on java 17
> --
>
> Key: GEODE-10238
> URL: https://issues.apache.org/jira/browse/GEODE-10238
> Project: Geode
> Issue Type: Improvement
> Components: tests
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Labels: Java17, pull-request-available
>
> {noformat}
> Jetty9CachingClientServerTest > shouldCacheSessionOnClient FAILED
> org.opentest4j.AssertionFailedError:
> expected: ""
> but was: "Error in servlet:
> java.lang.reflect.InaccessibleObjectException: Unable to make field private
> transient sun.security.provider.AbstractDrbg sun.security.provider.DRBG.impl
> accessible: module java.base does not "opens sun.security.provider" to
> unnamed module @47874b25"
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
> at
> org.apache.geode.session.tests.Jetty9CachingClientServerTest.shouldCacheSessionOnClient(Jetty9CachingClientServerTest.java:59)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-10241) Need to temporarily disable "reAuthenticateWithDurable" test
[ https://issues.apache.org/jira/browse/GEODE-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522882#comment-17522882 ] ASF GitHub Bot commented on GEODE-10241: mmartell commented on PR #961: URL: https://github.com/apache/geode-native/pull/961#issuecomment-1100206744 Seems prudent to disable for now. Don't want to block PRs. > Need to temporarily disable "reAuthenticateWithDurable" test > > > Key: GEODE-10241 > URL: https://issues.apache.org/jira/browse/GEODE-10241 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: needsTriage > > This test is verifying geode-native works with a feature which is not yet > released (forthcoming in Geode 1.15), and whose implementation has recently > changed. The test is now failing, and needs to be implemented properly > according to the spec for the token authentication feature. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10241) Need to temporarily disable "reAuthenticateWithDurable" test
[ https://issues.apache.org/jira/browse/GEODE-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-10241: --- Labels: needsTriage pull-request-available (was: needsTriage) > Need to temporarily disable "reAuthenticateWithDurable" test > > > Key: GEODE-10241 > URL: https://issues.apache.org/jira/browse/GEODE-10241 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: needsTriage, pull-request-available > > This test is verifying geode-native works with a feature which is not yet > released (forthcoming in Geode 1.15), and whose implementation has recently > changed. The test is now failing, and needs to be implemented properly > according to the spec for the token authentication feature. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (GEODE-10241) Need to temporarily disable "reAuthenticateWithDurable" test
[ https://issues.apache.org/jira/browse/GEODE-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Murmann updated GEODE-10241: -- Labels: needsTriage (was: ) > Need to temporarily disable "reAuthenticateWithDurable" test > > > Key: GEODE-10241 > URL: https://issues.apache.org/jira/browse/GEODE-10241 > Project: Geode > Issue Type: Bug > Components: native client >Reporter: Blake Bender >Priority: Major > Labels: needsTriage > > This test is verifying geode-native works with a feature which is not yet > released (forthcoming in Geode 1.15), and whose implementation has recently > changed. The test is now failing, and needs to be implemented properly > according to the spec for the token authentication feature. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (GEODE-10241) Need to temporarily disable "reAuthenticateWithDurable" test
Blake Bender created GEODE-10241: Summary: Need to temporarily disable "reAuthenticateWithDurable" test Key: GEODE-10241 URL: https://issues.apache.org/jira/browse/GEODE-10241 Project: Geode Issue Type: Bug Components: native client Reporter: Blake Bender This test is verifying geode-native works with a feature which is not yet released (forthcoming in Geode 1.15), and whose implementation has recently changed. The test is now failing, and needs to be implemented properly according to the spec for the token authentication feature. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (GEODE-10223) BlockingCommandListenerTest > testTimeoutIsAdjusted fails on Windows due to timeout not changing
[
https://issues.apache.org/jira/browse/GEODE-10223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17522860#comment-17522860
]
ASF subversion and git services commented on GEODE-10223:
-
Commit 9faaf49189c32417d4cdea789aede2daca39 in geode's branch
refs/heads/develop from Bala Kaza Venkata
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9faaf49189 ]
GEODE-10223: Fix BlockingCommandListnerTest to be less flaky. (#7592)
* GEODE-10223: Fix BlockingCommandListnerTest to be less flaky.
testTimeoutIsAdjusted is flaky on windows machines. Adding a delay will make it
less flaky.
Authored-by: Bala Kaza Venkata
> BlockingCommandListenerTest > testTimeoutIsAdjusted fails on Windows due to
> timeout not changing
>
>
> Key: GEODE-10223
> URL: https://issues.apache.org/jira/browse/GEODE-10223
> Project: Geode
> Issue Type: Bug
> Components: redis
>Affects Versions: 1.15.0
>Reporter: Donal Evans
>Priority: Major
> Labels: needsTriage, pull-request-available
>
> {noformat}
> > Task :geode-for-redis:integrationTest
> BlockingCommandListenerTest > testTimeoutIsAdjusted FAILED
> java.lang.AssertionError:
> Expecting actual:
> 1.0
> to be less than:
> 1.0
> at
> org.apache.geode.redis.internal.eventing.BlockingCommandListenerTest.testTimeoutIsAdjusted(BlockingCommandListenerTest.java:61){noformat}
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}= Test Results URI
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}=
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1081/test-results/integrationTest/1649299123/]
>
> ={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}={-}=
> Test report artifacts from this job are available at:
> [http://files.apachegeode-ci.info/builds/apache-develop-main/1.15.0-build.1081/test-artifacts/1649299123/windows-integrationtestfiles-openjdk11-1.15.0-build.1081.tgz]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
