[jira] [Resolved] (GEODE-7251) Incorrect/incomplete instructions on download page
[
https://issues.apache.org/jira/browse/GEODE-7251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sebb resolved GEODE-7251.
-
Resolution: Fixed
Looks OK now
> Incorrect/incomplete instructions on download page
> --
>
> Key: GEODE-7251
> URL: https://issues.apache.org/jira/browse/GEODE-7251
> Project: Geode
> Issue Type: Bug
>Reporter: Sebb
>Priority: Major
>
> There are some issues with the download page instructions.
> It still refers to checking MD5 hashes, but there are none.
> Also the gpg sig check needs a second parameter:
> gpg --verify ${filename}.tar.gz.asc ${filename}.tar.gz
> See https://www.apache.org/info/verification.html#specify_both
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GEODE-7251) Incorrect/incomplete instructions on download page
[
https://issues.apache.org/jira/browse/GEODE-7251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker reassigned GEODE-7251:
Assignee: (was: Anthony Baker)
> Incorrect/incomplete instructions on download page
> --
>
> Key: GEODE-7251
> URL: https://issues.apache.org/jira/browse/GEODE-7251
> Project: Geode
> Issue Type: Bug
>Reporter: Sebb
>Priority: Major
>
> There are some issues with the download page instructions.
> It still refers to checking MD5 hashes, but there are none.
> Also the gpg sig check needs a second parameter:
> gpg --verify ${filename}.tar.gz.asc ${filename}.tar.gz
> See https://www.apache.org/info/verification.html#specify_both
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GEODE-7053) PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration fails intermittently in CI
[
https://issues.apache.org/jira/browse/GEODE-7053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker reassigned GEODE-7053:
Assignee: (was: Anthony Baker)
> PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration
> fails intermittently in CI
> -
>
> Key: GEODE-7053
> URL: https://issues.apache.org/jira/browse/GEODE-7053
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.13.0, 1.15.0
>Reporter: Kirk Lund
>Priority: Major
>
> This test appears to be flaky and fails intermittently with:
> {noformat}
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest >
> readsInOtherMemberShouldPreventExpiration FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest$$Lambda$29/458121042.run
> in VM 0 running on Host 40e899358944 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:579)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:406)
> at
> org.apache.geode.internal.cache.PREntryIdleExpirationDistributedTest.readsInOtherMemberShouldPreventExpiration(PREntryIdleExpirationDistributedTest.java:114)
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> 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.internal.cache.PREntryIdleExpirationDistributedTest.lambda$readsInOtherMemberShouldPreventExpiration$bb17a952$2(PREntryIdleExpirationDistributedTest.java:124)
> {noformat}
> This test depends on a background thread waking up every 10 ms to perform a
> GET which prevents another thread from expiring an entry. I think that would
> be very prone to failing if the thread loses CPU for any reason.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GEODE-1168) geode-dependencies manifest is missing jars that are present in the lib directory
[
https://issues.apache.org/jira/browse/GEODE-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker reassigned GEODE-1168:
Assignee: (was: Anthony Baker)
> geode-dependencies manifest is missing jars that are present in the lib
> directory
> -
>
> Key: GEODE-1168
> URL: https://issues.apache.org/jira/browse/GEODE-1168
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Dan Smith
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> While looking into GEODE-1025, I discovered that we have a number of jars in
> the geode-assembly/build/install/apache-geode/lib directory that do not
> appear in geode-dependencies.jar or gfsh-dependencies.jar.
> I believe that means that these are not actually on the classpath for any
> geode process, which means they either shouldn't be shipped with geode at
> all, or they are supposed to be on the classpath but I getting skipped for
> some reason.
> These are the jars present in the lib directory, but not on the classpath,
> excluding the spring jars (I'm cleaning those up as part of GEODE-1025)
> {noformat}
> activation-1.1.jar
> commons-modeler-2.0.jar
> findbugs-annotations-1.3.9-1.jar
> geode-jca-1.0.0-incubating.M2-SNAPSHOT.rar
> geode-web-1.0.0-incubating.M2-SNAPSHOT.jar
> geode-web-api-1.0.0-incubating.M2-SNAPSHOT.jar
> guava-15.0.jar
> javax.mail-api-1.4.5.jar
> mx4j-3.0.1.jar
> mx4j-remote-3.0.1.jar
> mx4j-tools-3.0.1.jar
> ra.jar
> {noformat}
> Most of these jars appear to be coming from compile dependencies of
> geode-core.
> The jars in the lib directory are controlled by the distributions section of
> geode-assembly/build.gradle. The jars in the geode-dependencies.jar manifest
> are coming from the cp() method in geode-assembly/build.gradle.
> It seems like these two lists ought to be unified - we should only ship jars
> that appear in one of the two manifests, and what goes into the manifest
> should probably be controlled by the configurations of the other projects -
> In other words, if it's part of the runtime configuration of geode-core it
> should be part of the geode-dependencies.jar; it shouldn't be filtered by
> this cp() method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GEODE-2160) gfsh stop server/locator exits with code 0 before server/locator actually stops
[
https://issues.apache.org/jira/browse/GEODE-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker reassigned GEODE-2160:
Assignee: (was: Anthony Baker)
> gfsh stop server/locator exits with code 0 before server/locator actually
> stops
> ---
>
> Key: GEODE-2160
> URL: https://issues.apache.org/jira/browse/GEODE-2160
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.0.0-incubating
>Reporter: Jacob Barrett
>Priority: Major
>
> Executing
> {code}
> gfsh stop server --name=server1
> {code}
> {{gfsh}} exits, with code 0, prior to the server actually being stopped.
> This behavior isn't documented and makes scripting with gfsh difficult. One
> can't assume that the server has stopped after gfsh exits. To verify you must
> parse the server pid and check the status of the proc.
> Simple test:
> {code}
> gfsh start server --name=s2 && sleep 10 && gfsh stop server --dir=s2; echo
> $?; while (kill -0 `cat s2/vf.gf.server.pid`); do date +%s.%N; done
> {code}
> Starts server, waits 10s, stops server, prints exit code, loops until process
> is gone while printing the time since epoch.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
