[jira] [Commented] (GEODE-6277) CI failure: DistributedNoAckRegionDUnitTest.testNBRegionDestructionDuringGetInitialImage
[
https://issues.apache.org/jira/browse/GEODE-6277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744736#comment-16744736
]
ASF subversion and git services commented on GEODE-6277:
Commit 666176caf3ea47682e1f31ffd468094ba21c3aa0 in geode's branch
refs/heads/feature/GEODE-6277 from zhouxh
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=666176c ]
GEODE-6277: use await() instead of hard-coded sleep(3000) in the test
> CI failure:
> DistributedNoAckRegionDUnitTest.testNBRegionDestructionDuringGetInitialImage
>
>
> Key: GEODE-6277
> URL: https://issues.apache.org/jira/browse/GEODE-6277
> Project: Geode
> Issue Type: Bug
> Components: membership, regions
>Affects Versions: 1.9.0
>Reporter: Ryan McMahon
>Assignee: xiaojian zhou
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
>
> {code:java}
> org.apache.geode.cache30.DistributedNoAckRegionDUnitTest >
> testNBRegionDestructionDuringGetInitialImage FAILED
> java.lang.AssertionError: asyncGII failed
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> {code}
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/288|http://example.com/]
> This appears to be part of a larger flakey failure ticket, but this
> particular failure was not addressed. Original flakey failure ticket:
> [https://issues.apache.org/jira/browse/GEODE-5412?jql=text%20~%20%22testNBRegionDestructionDuringGetInitialImage%22|http://example.com/]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6285) MBean names in Loner are not stable when member name is empty
[
https://issues.apache.org/jira/browse/GEODE-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-6285:
--
Labels: pull-request-available (was: )
> MBean names in Loner are not stable when member name is empty
> -
>
> Key: GEODE-6285
> URL: https://issues.apache.org/jira/browse/GEODE-6285
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
> Labels: pull-request-available
>
> When the default member name is empty, Geode uses DistributedMember.getId()
> instead of DistributedMember.getName() in the MBean names. If the member is a
> Loner (no cluster) then it will mutate the string returned from
> DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
> created and started.
> Example:
> When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with
> the ObjectName
> *GemFire:service=CacheServer,port=\{0\},type=Member,member=\{1\}*. The
> *\{1\}* parameter value is *10.118.20.84(28927-loner)-0-6ea32c5* which
> contains a zero where the membership port would normally be displayed:
> {noformat}
> GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
> {noformat}
> Then when the GatewayReceiver is started, Geode fails to update the
> GatewayReceiverMXBean state to reflect that it's running because the simple
> act of starting the GatewayReceiver resulted in the changing of
> DistributedMember.getId() to replace the membership port of zero with the
> port that the GatewayReceiver is now listening on:
> {noformat}
> GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
> {noformat}
> Internally the code tries to find an existing GatewayReceiverMXBean with that
> ObjectName and returns null. The code after that doesn't expect the MBean to
> be null, so updating it fails. Later if the GatewayReceiver is destroyed, it
> also fails to unregister the MBean as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6277) CI failure: DistributedNoAckRegionDUnitTest.testNBRegionDestructionDuringGetInitialImage
[
https://issues.apache.org/jira/browse/GEODE-6277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744569#comment-16744569
]
ASF subversion and git services commented on GEODE-6277:
Commit 55062cf31843f0439b57b0c2587a64a517ac9e66 in geode's branch
refs/heads/feature/GEODE-6277 from zhouxh
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=55062cf ]
GEODE-6277: use await() instead of hard-coded sleep(3000) in the test
> CI failure:
> DistributedNoAckRegionDUnitTest.testNBRegionDestructionDuringGetInitialImage
>
>
> Key: GEODE-6277
> URL: https://issues.apache.org/jira/browse/GEODE-6277
> Project: Geode
> Issue Type: Bug
> Components: membership, regions
>Affects Versions: 1.9.0
>Reporter: Ryan McMahon
>Assignee: xiaojian zhou
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
>
> {code:java}
> org.apache.geode.cache30.DistributedNoAckRegionDUnitTest >
> testNBRegionDestructionDuringGetInitialImage FAILED
> java.lang.AssertionError: asyncGII failed
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> {code}
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/288|http://example.com/]
> This appears to be part of a larger flakey failure ticket, but this
> particular failure was not addressed. Original flakey failure ticket:
> [https://issues.apache.org/jira/browse/GEODE-5412?jql=text%20~%20%22testNBRegionDestructionDuringGetInitialImage%22|http://example.com/]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6285) MBean names in Loner are not stable when member name is empty
[
https://issues.apache.org/jira/browse/GEODE-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-6285:
-
Description:
When the default member name is empty, Geode uses DistributedMember.getId()
instead of DistributedMember.getName() in the MBean names. If the member is a
Loner (no cluster) then it will mutate the string returned from
DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
created and started.
Example:
When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with the
ObjectName *GemFire:service=CacheServer,port=\{0\},type=Member,member=\{1\}*.
The *\{1\}* parameter value is *10.118.20.84(28927-loner)-0-6ea32c5* which
contains a zero where the membership port would normally be displayed:
{noformat}
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
{noformat}
Then when the GatewayReceiver is started, Geode fails to update the
GatewayReceiverMXBean state to reflect that it's running because the simple act
of starting the GatewayReceiver resulted in the changing of
DistributedMember.getId() to replace the membership port of zero with the port
that the GatewayReceiver is now listening on:
{noformat}
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
{noformat}
Internally the code tries to find an existing GatewayReceiverMXBean with that
ObjectName and returns null. The code after that doesn't expect the MBean to be
null, so updating it fails. Later if the GatewayReceiver is destroyed, it also
fails to unregister the MBean as well.
was:
When the default member name is empty, Geode uses DistributedMember.getId()
instead of DistributedMember.getName() in the MBean names. If the member is a
Loner (no cluster) then it will mutate the string returned from
DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
created and started.
Example:
When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with the
ObjectName `"GemFire:service=CacheServer,port=\{0\},type=Member,member=\{1\}"`.
The ```{1`}`` parameter value is ``10.118.20.84(28927-loner)-0-6ea32c5`` which
contains a zero where the membership port would normally be displayed:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
Then when the GatewayReceiver is started, Geode fails to update the
GatewayReceiverMXBean state to reflect that it's running because the simple act
of starting the GatewayReceiver resulted in the changing of
DistributedMember.getId() to replace the membership port of zero with the port
that the GatewayReceiver is now listening on:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
Internally the code tries to find an existing GatewayReceiverMXBean with that
ObjectName and returns null. The code after that doesn't expect the MBean to be
null, so updating it fails. Later if the GatewayReceiver is destroyed, it also
fails to unregister the MBean as well.
> MBean names in Loner are not stable when member name is empty
> -
>
> Key: GEODE-6285
> URL: https://issues.apache.org/jira/browse/GEODE-6285
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Kirk Lund
>Priority: Major
>
> When the default member name is empty, Geode uses DistributedMember.getId()
> instead of DistributedMember.getName() in the MBean names. If the member is a
> Loner (no cluster) then it will mutate the string returned from
> DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
> created and started.
> Example:
> When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with
> the ObjectName
> *GemFire:service=CacheServer,port=\{0\},type=Member,member=\{1\}*. The
> *\{1\}* parameter value is *10.118.20.84(28927-loner)-0-6ea32c5* which
> contains a zero where the membership port would normally be displayed:
> {noformat}
> GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
> {noformat}
> Then when the GatewayReceiver is started, Geode fails to update the
> GatewayReceiverMXBean state to reflect that it's running because the simple
> act of starting the GatewayReceiver resulted in the changing of
> DistributedMember.getId() to replace the membership port of zero with the
> port that the GatewayReceiver is now listening on:
> {noformat}
> GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
> {noformat}
> Internally the code tries to find an existing GatewayReceiverMXBean with that
> ObjectName and returns null. The code after that doesn't expect the MBean to
> be null, so updating it fails. Later if the GatewayReceiver is
[jira] [Resolved] (GEODE-6275) Benchmarks CI job silently fails
[ https://issues.apache.org/jira/browse/GEODE-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Helena Bales resolved GEODE-6275. - Resolution: Fixed Fix Version/s: 1.9.0 > Benchmarks CI job silently fails > > > Key: GEODE-6275 > URL: https://issues.apache.org/jira/browse/GEODE-6275 > Project: Geode > Issue Type: Bug > Components: benchmarks >Reporter: Helena Bales >Assignee: Helena Bales >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 40m > Remaining Estimate: 0h > > The benchmark task in CI silently fails when it fails to build geode or get > resources. The benchmark job should go red when it fails to build geode or > fails to get resources from Maven. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6285) MBean names in Loner are not stable when member name is empty
[
https://issues.apache.org/jira/browse/GEODE-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund reassigned GEODE-6285:
Assignee: Kirk Lund
> MBean names in Loner are not stable when member name is empty
> -
>
> Key: GEODE-6285
> URL: https://issues.apache.org/jira/browse/GEODE-6285
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> When the default member name is empty, Geode uses DistributedMember.getId()
> instead of DistributedMember.getName() in the MBean names. If the member is a
> Loner (no cluster) then it will mutate the string returned from
> DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
> created and started.
> Example:
> When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with
> the ObjectName
> *GemFire:service=CacheServer,port=\{0\},type=Member,member=\{1\}*. The
> *\{1\}* parameter value is *10.118.20.84(28927-loner)-0-6ea32c5* which
> contains a zero where the membership port would normally be displayed:
> {noformat}
> GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
> {noformat}
> Then when the GatewayReceiver is started, Geode fails to update the
> GatewayReceiverMXBean state to reflect that it's running because the simple
> act of starting the GatewayReceiver resulted in the changing of
> DistributedMember.getId() to replace the membership port of zero with the
> port that the GatewayReceiver is now listening on:
> {noformat}
> GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
> {noformat}
> Internally the code tries to find an existing GatewayReceiverMXBean with that
> ObjectName and returns null. The code after that doesn't expect the MBean to
> be null, so updating it fails. Later if the GatewayReceiver is destroyed, it
> also fails to unregister the MBean as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6285) MBean names in Loner are not stable when member name is empty
[
https://issues.apache.org/jira/browse/GEODE-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-6285:
-
Description:
When the default member name is empty, Geode uses DistributedMember.getId()
instead of DistributedMember.getName() in the MBean names. If the member is a
Loner (no cluster) then it will mutate the string returned from
DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
created and started.
Example:
When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with the
ObjectName `"GemFire:service=CacheServer,port=\{0\},type=Member,member=\{1\}"`.
The ```{1`}`` parameter value is ``10.118.20.84(28927-loner)-0-6ea32c5`` which
contains a zero where the membership port would normally be displayed:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
Then when the GatewayReceiver is started, Geode fails to update the
GatewayReceiverMXBean state to reflect that it's running because the simple act
of starting the GatewayReceiver resulted in the changing of
DistributedMember.getId() to replace the membership port of zero with the port
that the GatewayReceiver is now listening on:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
Internally the code tries to find an existing GatewayReceiverMXBean with that
ObjectName and returns null. The code after that doesn't expect the MBean to be
null, so updating it fails. Later if the GatewayReceiver is destroyed, it also
fails to unregister the MBean as well.
was:
When the default member name is empty, Geode uses DistributedMember.getId()
instead of DistributedMember.getName() in the MBean names. If the member is a
Loner (no cluster) then it will mutate the string returned from
DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
created and started.
Example:
When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with the
ObjectName
{quote}"GemFire:service=CacheServer,port=\{0\},type=Member,member=\{1\}"{quote}.
The ```{1`}`` parameter value is ``10.118.20.84(28927-loner)-0-6ea32c5`` which
contains a zero where the membership port would normally be displayed:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
Then when the GatewayReceiver is started, Geode fails to update the
GatewayReceiverMXBean state to reflect that it's running because the simple act
of starting the GatewayReceiver resulted in the changing of
DistributedMember.getId() to replace the membership port of zero with the port
that the GatewayReceiver is now listening on:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
Internally the code tries to find an existing GatewayReceiverMXBean with that
ObjectName and returns null. The code after that doesn't expect the MBean to be
null, so updating it fails. Later if the GatewayReceiver is destroyed, it also
fails to unregister the MBean as well.
> MBean names in Loner are not stable when member name is empty
> -
>
> Key: GEODE-6285
> URL: https://issues.apache.org/jira/browse/GEODE-6285
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Kirk Lund
>Priority: Major
>
> When the default member name is empty, Geode uses DistributedMember.getId()
> instead of DistributedMember.getName() in the MBean names. If the member is a
> Loner (no cluster) then it will mutate the string returned from
> DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
> created and started.
> Example:
> When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with
> the ObjectName
> `"GemFire:service=CacheServer,port=\{0\},type=Member,member=\{1\}"`. The
> ```{1`}`` parameter value is ``10.118.20.84(28927-loner)-0-6ea32c5`` which
> contains a zero where the membership port would normally be displayed:
> bq.
> GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
> Then when the GatewayReceiver is started, Geode fails to update the
> GatewayReceiverMXBean state to reflect that it's running because the simple
> act of starting the GatewayReceiver resulted in the changing of
> DistributedMember.getId() to replace the membership port of zero with the
> port that the GatewayReceiver is now listening on:
> bq.
> GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
> Internally the code tries to find an existing GatewayReceiverMXBean with that
> ObjectName and returns null. The code after that doesn't expect the MBean to
> be null, so updating it fails. Later if the GatewayReceiver is destroyed, it
> also fails to unregister the
[jira] [Updated] (GEODE-6285) MBean names in Loner are not stable when member name is empty
[
https://issues.apache.org/jira/browse/GEODE-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-6285:
-
Description:
When the default member name is empty, Geode uses DistributedMember.getId()
instead of DistributedMember.getName() in the MBean names. If the member is a
Loner (no cluster) then it will mutate the string returned from
DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
created and started.
Example:
When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with the
ObjectName
{quote}"GemFire:service=CacheServer,port=\{0\},type=Member,member=\{1\}"{quote}.
The ```{1`}`` parameter value is ``10.118.20.84(28927-loner)-0-6ea32c5`` which
contains a zero where the membership port would normally be displayed:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
Then when the GatewayReceiver is started, Geode fails to update the
GatewayReceiverMXBean state to reflect that it's running because the simple act
of starting the GatewayReceiver resulted in the changing of
DistributedMember.getId() to replace the membership port of zero with the port
that the GatewayReceiver is now listening on:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
Internally the code tries to find an existing GatewayReceiverMXBean with that
ObjectName and returns null. The code after that doesn't expect the MBean to be
null, so updating it fails. Later if the GatewayReceiver is destroyed, it also
fails to unregister the MBean as well.
was:
When the default member name is empty, Geode uses DistributedMember.getId()
instead of DistributedMember.getName() in the MBean names. If the member is a
Loner (no cluster) then it will mutate the string returned from
DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
created and started.
Example:
When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with the
ObjectName
``"GemFire:service=CacheServer,port=\{0\},type=Member,member=\{1\}"``. The
```{1`}`` parameter value is ``10.118.20.84(28927-loner)-0-6ea32c5`` which
contains a zero where the membership port would normally be displayed:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
Then when the GatewayReceiver is started, Geode fails to update the
GatewayReceiverMXBean state to reflect that it's running because the simple act
of starting the GatewayReceiver resulted in the changing of
DistributedMember.getId() to replace the membership port of zero with the port
that the GatewayReceiver is now listening on:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
Internally the code tries to find an existing GatewayReceiverMXBean with that
ObjectName and returns null. The code after that doesn't expect the MBean to be
null, so updating it fails. Later if the GatewayReceiver is destroyed, it also
fails to unregister the MBean as well.
> MBean names in Loner are not stable when member name is empty
> -
>
> Key: GEODE-6285
> URL: https://issues.apache.org/jira/browse/GEODE-6285
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Kirk Lund
>Priority: Major
>
> When the default member name is empty, Geode uses DistributedMember.getId()
> instead of DistributedMember.getName() in the MBean names. If the member is a
> Loner (no cluster) then it will mutate the string returned from
> DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
> created and started.
> Example:
> When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with
> the ObjectName
> {quote}"GemFire:service=CacheServer,port=\{0\},type=Member,member=\{1\}"{quote}.
> The ```{1`}`` parameter value is ``10.118.20.84(28927-loner)-0-6ea32c5``
> which contains a zero where the membership port would normally be displayed:
> bq.
> GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
> Then when the GatewayReceiver is started, Geode fails to update the
> GatewayReceiverMXBean state to reflect that it's running because the simple
> act of starting the GatewayReceiver resulted in the changing of
> DistributedMember.getId() to replace the membership port of zero with the
> port that the GatewayReceiver is now listening on:
> bq.
> GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
> Internally the code tries to find an existing GatewayReceiverMXBean with that
> ObjectName and returns null. The code after that doesn't expect the MBean to
> be null, so updating it fails. Later if the GatewayReceiver is destroyed, it
> also fails to
[jira] [Updated] (GEODE-6285) MBean names in Loner are not stable when member name is empty
[
https://issues.apache.org/jira/browse/GEODE-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-6285:
-
Description:
When the default member name is empty, Geode uses DistributedMember.getId()
instead of DistributedMember.getName() in the MBean names. If the member is a
Loner (no cluster) then it will mutate the string returned from
DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
created and started.
Example:
When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with the
ObjectName
``"GemFire:service=CacheServer,port=\{0\},type=Member,member=\{1\}"``. The
```{1`}`` parameter value is ``10.118.20.84(28927-loner)-0-6ea32c5`` which
contains a zero where the membership port would normally be displayed:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
Then when the GatewayReceiver is started, Geode fails to update the
GatewayReceiverMXBean state to reflect that it's running because the simple act
of starting the GatewayReceiver resulted in the changing of
DistributedMember.getId() to replace the membership port of zero with the port
that the GatewayReceiver is now listening on:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
Internally the code tries to find an existing GatewayReceiverMXBean with that
ObjectName and returns null. The code after that doesn't expect the MBean to be
null, so updating it fails. Later if the GatewayReceiver is destroyed, it also
fails to unregister the MBean as well.
was:
When the default member name is empty, Geode uses DistributedMember.getId()
instead of DistributedMember.getName() in the MBean names. If the member is a
Loner (no cluster) then it will mutate the string returned from
DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
created and started.
Example:
When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with the
ObjectName
``"GemFire:service=CacheServer,port=`{0`},type=Member,member=`{1`}"``. The
```{1`}`` parameter value is ``10.118.20.84(28927-loner)-0-6ea32c5`` which
contains a zero where the membership port would normally be displayed:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
Then when the GatewayReceiver is started, Geode fails to update the
GatewayReceiverMXBean state to reflect that it's running because the simple act
of starting the GatewayReceiver resulted in the changing of
DistributedMember.getId() to replace the membership port of zero with the port
that the GatewayReceiver is now listening on:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
Internally the code tries to find an existing GatewayReceiverMXBean with that
ObjectName and returns null. The code after that doesn't expect the MBean to be
null, so updating it fails. Later if the GatewayReceiver is destroyed, it also
fails to unregister the MBean as well.
> MBean names in Loner are not stable when member name is empty
> -
>
> Key: GEODE-6285
> URL: https://issues.apache.org/jira/browse/GEODE-6285
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Kirk Lund
>Priority: Major
>
> When the default member name is empty, Geode uses DistributedMember.getId()
> instead of DistributedMember.getName() in the MBean names. If the member is a
> Loner (no cluster) then it will mutate the string returned from
> DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
> created and started.
> Example:
> When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with
> the ObjectName
> ``"GemFire:service=CacheServer,port=\{0\},type=Member,member=\{1\}"``. The
> ```{1`}`` parameter value is ``10.118.20.84(28927-loner)-0-6ea32c5`` which
> contains a zero where the membership port would normally be displayed:
> bq.
> GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
> Then when the GatewayReceiver is started, Geode fails to update the
> GatewayReceiverMXBean state to reflect that it's running because the simple
> act of starting the GatewayReceiver resulted in the changing of
> DistributedMember.getId() to replace the membership port of zero with the
> port that the GatewayReceiver is now listening on:
> bq.
> GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
> Internally the code tries to find an existing GatewayReceiverMXBean with that
> ObjectName and returns null. The code after that doesn't expect the MBean to
> be null, so updating it fails. Later if the GatewayReceiver is destroyed, it
> also fails to unregister the MBean
[jira] [Updated] (GEODE-6285) MBean names in Loner are not stable when member name is empty
[
https://issues.apache.org/jira/browse/GEODE-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-6285:
-
Description:
When the default member name is empty, Geode uses DistributedMember.getId()
instead of DistributedMember.getName() in the MBean names. If the member is a
Loner (no cluster) then it will mutate the string returned from
DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
created and started.
Example:
When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with the
ObjectName ``"GemFire:service=CacheServer,port={0},type=Member,member={1}"``.
The ``{1}`` parameter value is ``10.118.20.84(28927-loner)-0-6ea32c5`` which
contains a zero where the membership port would normally be displayed:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
Then when the GatewayReceiver is started, Geode fails to update the
GatewayReceiverMXBean state to reflect that it's running because the simple act
of starting the GatewayReceiver resulted in the changing of
DistributedMember.getId() to replace the membership port of zero with the port
that the GatewayReceiver is now listening on:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
Internally the code tries to find an existing GatewayReceiverMXBean with that
ObjectName and returns null. The code after that doesn't expect the MBean to be
null, so updating it fails. Later if the GatewayReceiver is destroyed, it also
fails to unregister the MBean as well.
was:
When the default member name is empty, Geode uses DistributedMember.getId()
instead of DistributedMember.getName() in the MBean names. If the member is a
Loner (no cluster) then it will mutate the string returned from
DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
created and started.
Example:
When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with the
ObjectName "GemFire:service=CacheServer,port={0},type=Member,member={1}". The
{1} parameter value is {quote}10.118.20.84(28927-loner)-0-6ea32c5{quote} which
contains a zero where the membership port would normally be displayed:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
Then when the GatewayReceiver is started, Geode fails to update the
GatewayReceiverMXBean state to reflect that it's running because the simple act
of starting the GatewayReceiver resulted in the changing of
DistributedMember.getId() to replace the membership port of zero with the port
that the GatewayReceiver is now listening on:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
Internally the code tries to find an existing GatewayReceiverMXBean with that
ObjectName and returns null. The code after that doesn't expect the MBean to be
null, so updating it fails. Later if the GatewayReceiver is destroyed, it also
fails to unregister the MBean as well.
> MBean names in Loner are not stable when member name is empty
> -
>
> Key: GEODE-6285
> URL: https://issues.apache.org/jira/browse/GEODE-6285
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Kirk Lund
>Priority: Major
>
> When the default member name is empty, Geode uses DistributedMember.getId()
> instead of DistributedMember.getName() in the MBean names. If the member is a
> Loner (no cluster) then it will mutate the string returned from
> DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
> created and started.
> Example:
> When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with
> the ObjectName
> ``"GemFire:service=CacheServer,port={0},type=Member,member={1}"``. The
> ``{1}`` parameter value is ``10.118.20.84(28927-loner)-0-6ea32c5`` which
> contains a zero where the membership port would normally be displayed:
> bq.
> GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
> Then when the GatewayReceiver is started, Geode fails to update the
> GatewayReceiverMXBean state to reflect that it's running because the simple
> act of starting the GatewayReceiver resulted in the changing of
> DistributedMember.getId() to replace the membership port of zero with the
> port that the GatewayReceiver is now listening on:
> bq.
> GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
> Internally the code tries to find an existing GatewayReceiverMXBean with that
> ObjectName and returns null. The code after that doesn't expect the MBean to
> be null, so updating it fails. Later if the GatewayReceiver is destroyed, it
> also fails to unregister the MBean as well.
--
[jira] [Updated] (GEODE-6285) MBean names in Loner are not stable when member name is empty
[
https://issues.apache.org/jira/browse/GEODE-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-6285:
-
Description:
When the default member name is empty, Geode uses DistributedMember.getId()
instead of DistributedMember.getName() in the MBean names. If the member is a
Loner (no cluster) then it will mutate the string returned from
DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
created and started.
Example:
When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with the
ObjectName
``"GemFire:service=CacheServer,port=`{0`},type=Member,member=`{1`}"``. The
```{1`}`` parameter value is ``10.118.20.84(28927-loner)-0-6ea32c5`` which
contains a zero where the membership port would normally be displayed:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
Then when the GatewayReceiver is started, Geode fails to update the
GatewayReceiverMXBean state to reflect that it's running because the simple act
of starting the GatewayReceiver resulted in the changing of
DistributedMember.getId() to replace the membership port of zero with the port
that the GatewayReceiver is now listening on:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
Internally the code tries to find an existing GatewayReceiverMXBean with that
ObjectName and returns null. The code after that doesn't expect the MBean to be
null, so updating it fails. Later if the GatewayReceiver is destroyed, it also
fails to unregister the MBean as well.
was:
When the default member name is empty, Geode uses DistributedMember.getId()
instead of DistributedMember.getName() in the MBean names. If the member is a
Loner (no cluster) then it will mutate the string returned from
DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
created and started.
Example:
When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with the
ObjectName ``"GemFire:service=CacheServer,port={0},type=Member,member={1}"``.
The ``{1}`` parameter value is ``10.118.20.84(28927-loner)-0-6ea32c5`` which
contains a zero where the membership port would normally be displayed:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
Then when the GatewayReceiver is started, Geode fails to update the
GatewayReceiverMXBean state to reflect that it's running because the simple act
of starting the GatewayReceiver resulted in the changing of
DistributedMember.getId() to replace the membership port of zero with the port
that the GatewayReceiver is now listening on:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
Internally the code tries to find an existing GatewayReceiverMXBean with that
ObjectName and returns null. The code after that doesn't expect the MBean to be
null, so updating it fails. Later if the GatewayReceiver is destroyed, it also
fails to unregister the MBean as well.
> MBean names in Loner are not stable when member name is empty
> -
>
> Key: GEODE-6285
> URL: https://issues.apache.org/jira/browse/GEODE-6285
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Kirk Lund
>Priority: Major
>
> When the default member name is empty, Geode uses DistributedMember.getId()
> instead of DistributedMember.getName() in the MBean names. If the member is a
> Loner (no cluster) then it will mutate the string returned from
> DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
> created and started.
> Example:
> When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with
> the ObjectName
> ``"GemFire:service=CacheServer,port=`{0`},type=Member,member=`{1`}"``. The
> ```{1`}`` parameter value is ``10.118.20.84(28927-loner)-0-6ea32c5`` which
> contains a zero where the membership port would normally be displayed:
> bq.
> GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
> Then when the GatewayReceiver is started, Geode fails to update the
> GatewayReceiverMXBean state to reflect that it's running because the simple
> act of starting the GatewayReceiver resulted in the changing of
> DistributedMember.getId() to replace the membership port of zero with the
> port that the GatewayReceiver is now listening on:
> bq.
> GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
> Internally the code tries to find an existing GatewayReceiverMXBean with that
> ObjectName and returns null. The code after that doesn't expect the MBean to
> be null, so updating it fails. Later if the GatewayReceiver is destroyed, it
> also fails to unregister the MBean as
[jira] [Updated] (GEODE-6285) MBean names in Loner are not stable when member name is empty
[
https://issues.apache.org/jira/browse/GEODE-6285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-6285:
-
Description:
When the default member name is empty, Geode uses DistributedMember.getId()
instead of DistributedMember.getName() in the MBean names. If the member is a
Loner (no cluster) then it will mutate the string returned from
DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
created and started.
Example:
When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with the
ObjectName "GemFire:service=CacheServer,port={0},type=Member,member={1}". The
{1} parameter value is {quote}10.118.20.84(28927-loner)-0-6ea32c5{quote} which
contains a zero where the membership port would normally be displayed:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
Then when the GatewayReceiver is started, Geode fails to update the
GatewayReceiverMXBean state to reflect that it's running because the simple act
of starting the GatewayReceiver resulted in the changing of
DistributedMember.getId() to replace the membership port of zero with the port
that the GatewayReceiver is now listening on:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
Internally the code tries to find an existing GatewayReceiverMXBean with that
ObjectName and returns null. The code after that doesn't expect the MBean to be
null, so updating it fails. Later if the GatewayReceiver is destroyed, it also
fails to unregister the MBean as well.
was:
When the default member name is empty, Geode uses DistributedMember.getId()
instead of DistributedMember.getName() in the MBean names. If the member is a
Loner (no cluster) then it will mutate the string returned from
DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
created and started.
Example:
When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with the
ObjectName
{quote}"GemFire:service=CacheServer,port={0},type=Member,member={1}"{quote}.
The {quote}{1}{quote} parameter value is
{quote}10.118.20.84(28927-loner)-0-6ea32c5{quote} which contains a zero where
the membership port would normally be displayed:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
Then when the GatewayReceiver is started, Geode fails to update the
GatewayReceiverMXBean state to reflect that it's running because the simple act
of starting the GatewayReceiver resulted in the changing of
DistributedMember.getId() to replace the membership port of zero with the port
that the GatewayReceiver is now listening on:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
Internally the code tries to find an existing GatewayReceiverMXBean with that
ObjectName and returns null. The code after that doesn't expect the MBean to be
null, so updating it fails. Later if the GatewayReceiver is destroyed, it also
fails to unregister the MBean as well.
> MBean names in Loner are not stable when member name is empty
> -
>
> Key: GEODE-6285
> URL: https://issues.apache.org/jira/browse/GEODE-6285
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Kirk Lund
>Priority: Major
>
> When the default member name is empty, Geode uses DistributedMember.getId()
> instead of DistributedMember.getName() in the MBean names. If the member is a
> Loner (no cluster) then it will mutate the string returned from
> DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
> created and started.
> Example:
> When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with
> the ObjectName "GemFire:service=CacheServer,port={0},type=Member,member={1}".
> The {1} parameter value is {quote}10.118.20.84(28927-loner)-0-6ea32c5{quote}
> which contains a zero where the membership port would normally be displayed:
> bq.
> GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
> Then when the GatewayReceiver is started, Geode fails to update the
> GatewayReceiverMXBean state to reflect that it's running because the simple
> act of starting the GatewayReceiver resulted in the changing of
> DistributedMember.getId() to replace the membership port of zero with the
> port that the GatewayReceiver is now listening on:
> bq.
> GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
> Internally the code tries to find an existing GatewayReceiverMXBean with that
> ObjectName and returns null. The code after that doesn't expect the MBean to
> be null, so updating it fails. Later if the GatewayReceiver is destroyed, it
> also fails to
[jira] [Created] (GEODE-6285) MBean names in Loner are not stable when member name is empty
Kirk Lund created GEODE-6285:
Summary: MBean names in Loner are not stable when member name is
empty
Key: GEODE-6285
URL: https://issues.apache.org/jira/browse/GEODE-6285
Project: Geode
Issue Type: Bug
Components: jmx
Reporter: Kirk Lund
When the default member name is empty, Geode uses DistributedMember.getId()
instead of DistributedMember.getName() in the MBean names. If the member is a
Loner (no cluster) then it will mutate the string returned from
DistributedMember.getId() at runtime if a CacheServer or GatewayReceiver is
created and started.
Example:
When GatewayReceiver is created, Geode creates a GatewayReceiverMXBean with the
ObjectName
{quote}"GemFire:service=CacheServer,port={0},type=Member,member={1}"{quote}.
The {quote}{1}{quote} parameter value is
{quote}10.118.20.84(28927-loner)-0-6ea32c5{quote} which contains a zero where
the membership port would normally be displayed:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-0-6ea32c59
Then when the GatewayReceiver is started, Geode fails to update the
GatewayReceiverMXBean state to reflect that it's running because the simple act
of starting the GatewayReceiver resulted in the changing of
DistributedMember.getId() to replace the membership port of zero with the port
that the GatewayReceiver is now listening on:
bq.
GemFire:service=GatewayReceiver,type=Member,member=10.118.20.84(28927-loner)-5362-6ea32c59
Internally the code tries to find an existing GatewayReceiverMXBean with that
ObjectName and returns null. The code after that doesn't expect the MBean to be
null, so updating it fails. Later if the GatewayReceiver is destroyed, it also
fails to unregister the MBean as well.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6277) CI failure: DistributedNoAckRegionDUnitTest.testNBRegionDestructionDuringGetInitialImage
[
https://issues.apache.org/jira/browse/GEODE-6277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-6277:
--
Labels: pull-request-available (was: )
> CI failure:
> DistributedNoAckRegionDUnitTest.testNBRegionDestructionDuringGetInitialImage
>
>
> Key: GEODE-6277
> URL: https://issues.apache.org/jira/browse/GEODE-6277
> Project: Geode
> Issue Type: Bug
> Components: membership, regions
>Affects Versions: 1.9.0
>Reporter: Ryan McMahon
>Assignee: xiaojian zhou
>Priority: Major
> Labels: pull-request-available
>
>
> {code:java}
> org.apache.geode.cache30.DistributedNoAckRegionDUnitTest >
> testNBRegionDestructionDuringGetInitialImage FAILED
> java.lang.AssertionError: asyncGII failed
> Caused by:
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> {code}
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/288|http://example.com/]
> This appears to be part of a larger flakey failure ticket, but this
> particular failure was not addressed. Original flakey failure ticket:
> [https://issues.apache.org/jira/browse/GEODE-5412?jql=text%20~%20%22testNBRegionDestructionDuringGetInitialImage%22|http://example.com/]
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6265) Rename TestingOnly annotation to VisibleForTesting
[ https://issues.apache.org/jira/browse/GEODE-6265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund resolved GEODE-6265. -- Resolution: Fixed Fix Version/s: 1.9.0 > Rename TestingOnly annotation to VisibleForTesting > -- > > Key: GEODE-6265 > URL: https://issues.apache.org/jira/browse/GEODE-6265 > Project: Geode > Issue Type: Wish > Components: tests >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This was discussed recently on the dev-list and we decided to rename our > custom annotation TestingOnly which means that the annotated entity is > visible only for testing. For example, a method might be package-private > instead of private to allow unit tests to invoke it. > Guava and AssertJ both use a similar annotation called VisibleForTesting. The > name is more descriptive and less ambiguous. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6152) Client PROXY Regions may return the same Object instance on get(key) and cause Thread-safety issues
[
https://issues.apache.org/jira/browse/GEODE-6152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anthony Baker updated GEODE-6152:
-
Labels: SmallFeature (was: Proxy Region client)
> Client PROXY Regions may return the same Object instance on get(key) and
> cause Thread-safety issues
> ---
>
> Key: GEODE-6152
> URL: https://issues.apache.org/jira/browse/GEODE-6152
> Project: Geode
> Issue Type: Bug
> Components: client/server, regions
>Affects Versions: 1.1.0, 1.1.1, 1.3.0, 1.2.1, 1.4.0, 1.5.0, 1.6.0, 1.7.0
>Reporter: John Blum
>Priority: Critical
> Labels: SmallFeature
>
> According to Apache Geode's documentation (e.g.
> [Javadoc|http://geode.apache.org/releases/latest/javadoc/org/apache/geode/cache/client/ClientRegionShortcut.html#PROXY]),
> client PROXY Regions are expected to return a new Object for each value on
> each {{Region.get(key)}} invocation.
> The documentation states:
> {quote}
> A PROXY region has no local state and forwards all operations to a server.
> {quote}
> Given the client cache (i.e. Region) contains "no local state" and "all
> operations are forwarded to a server", then this implies that the object, the
> Region's value mapped to the key, is serialized when sent to a server and
> deserialized when received from a server. The act of de/serialization
> constitutes a new object every, single, time.
> However, in a highly concurrent application (e.g. a Web application), with
> multiple Threads in the application potentially making concurrent data
> requests for the same "logical" domain object stored in Apache Geode, it is
> possible for the same object reference to be returned, even for a client
> {{PROXY}} Region.
> This is to be expected when using a {{CACHING_PROXY}}, since the client then
> has "local state", but for a client {{PROXY}} Region, there is, or should be
> no "local state".
> It turns out that internally, Geode applies an optimization wherein, if 2 or
> more Threads are concurrently making a data request for the same "logical"
> object, then only 1 Thread is allowed to proceed with the request while the
> other Threads will wait for the response that the permitted, requesting
> Thread received, thereby sharing the same object reference.
> This poses grave danger (race conditions due to lost updates, or incorrect
> decisions made due to stale state) if the non-unique object type is not
> Thread-safe. Under other conditions/configurations (e.g. when sending
> {{Deltas}}), it is even possible to "lose data" due to competing and
> conflicting data access operations, which results in a "_last-one-wins_"
> scenario.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6276) Benchmark CI should fetch versions and build develop
[ https://issues.apache.org/jira/browse/GEODE-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-6276: -- Labels: pull-request-available (was: ) > Benchmark CI should fetch versions and build develop > > > Key: GEODE-6276 > URL: https://issues.apache.org/jira/browse/GEODE-6276 > Project: Geode > Issue Type: Bug >Reporter: Helena Bales >Assignee: Helena Bales >Priority: Major > Labels: pull-request-available > > The benchmark ci job should build all non-release branches and fetch geode > releases. This avoids the cost of rebuilding released versions of Geode and > illiminates the challenge of the build parameters diverging between old > versions and develop. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6247) HostStatSampler posts suspect string stemming from native code in JDK11, causing failure in NetstatDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-6247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund resolved GEODE-6247.
--
Resolution: Fixed
Fix Version/s: 1.9.0
Fixed by GEODE-6253
> HostStatSampler posts suspect string stemming from native code in JDK11,
> causing failure in NetstatDUnitTest
> -
>
> Key: GEODE-6247
> URL: https://issues.apache.org/jira/browse/GEODE-6247
> Project: Geode
> Issue Type: Bug
>Reporter: Patrick Rhomberg
>Assignee: Scott Jewell
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> In JDK11 run
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/278:
> {noformat}
> org.apache.geode.management.internal.cli.NetstatDUnitTest > classMethod FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 2183
> [fatal 2019/01/04 00:15:19.050 UTC tid=67] committed =
> 538968064 should be < max = 536870912
> java.lang.IllegalArgumentException: committed = 538968064 should be < max
> = 536870912
> at
> java.management/java.lang.management.MemoryUsage.(MemoryUsage.java:166)
> at java.management/sun.management.MemoryImpl.getMemoryUsage0(Native
> Method)
> at
> java.management/sun.management.MemoryImpl.getHeapMemoryUsage(MemoryImpl.java:71)
> at
> org.apache.geode.internal.stats50.VMStats50.refresh(VMStats50.java:624)
> at
> org.apache.geode.internal.statistics.HostStatSampler.sampleSpecialStats(HostStatSampler.java:562)
> at
> org.apache.geode.internal.statistics.HostStatSampler.run(HostStatSampler.java:235)
> at java.base/java.lang.Thread.run(Thread.java:834)
> ---
> Found suspect string in log4j at line 2193
> [fatal 2019/01/04 00:15:19.055 UTC tid=67] Uncaught
> exception in thread Thread[StatSampler,10,RMI Runtime]
> java.lang.IllegalArgumentException: committed = 538968064 should be < max
> = 536870912
> at
> java.management/java.lang.management.MemoryUsage.(MemoryUsage.java:166)
> at java.management/sun.management.MemoryImpl.getMemoryUsage0(Native
> Method)
> at
> java.management/sun.management.MemoryImpl.getHeapMemoryUsage(MemoryImpl.java:71)
> at
> org.apache.geode.internal.stats50.VMStats50.refresh(VMStats50.java:624)
> at
> org.apache.geode.internal.statistics.HostStatSampler.sampleSpecialStats(HostStatSampler.java:562)
> at
> org.apache.geode.internal.statistics.HostStatSampler.run(HostStatSampler.java:235)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
> Test report at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-build.320/test-results/distributedTest/1546563376/
> Artifacts at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.9.0-build.320/test-artifacts/1546563376/distributedtestfiles-OpenJDK11-1.9.0-build.320.tgz
> This appears to be identical to the failure in GEODE-6046.
> We note that the difference in reported values is exactly 2MB.
> We note additionally that the suspect string itself appears during the
> class-rule startup, but before any class test is executed.
> Also possibly related to GEODE-6079, regarding how logs are written and the
> possibility of buffers not flushing properly before suspect strings are
> detected. It is not obvious that this suspect string failure does not truly
> belong to another test.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6284) CI Failure: RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.test[from_v1X0, with reindex=false]
[
https://issues.apache.org/jira/browse/GEODE-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon updated GEODE-6284:
Affects Version/s: 1.9.0
> CI Failure:
> RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.test[from_v1X0,
> with reindex=false]
>
>
> Key: GEODE-6284
> URL: https://issues.apache.org/jira/browse/GEODE-6284
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.9.0
>Reporter: Ryan McMahon
>Priority: Major
>
>
> {code:java}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 1 running on Host
> 34bae3263b09 with 4 VMs at
> org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:537) at
> org.apache.geode.test.dunit.VM.invoke(VM.java:352) at
> org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:57) at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:496)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:484)
> 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.RunAfters.evaluate(RunAfters.java:33)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) 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.junit.runners.Suite.runChild(Suite.java:128) at
> org.junit.runners.Suite.runChild(Suite.java:27) 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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 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:66)
> 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
>
[jira] [Updated] (GEODE-6284) CI Failure: RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.test[from_v1X0, with reindex=false]
[
https://issues.apache.org/jira/browse/GEODE-6284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon updated GEODE-6284:
Description:
{code:java}
org.apache.geode.test.dunit.RMIException: While invoking
org.apache.geode.test.dunit.NamedRunnable.run in VM 1 running on Host
34bae3263b09 with 4 VMs at
org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:537) at
org.apache.geode.test.dunit.VM.invoke(VM.java:352) at
org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:57) at
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:496)
at
org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:484)
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.RunAfters.evaluate(RunAfters.java:33)
at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) 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.junit.runners.Suite.runChild(Suite.java:128) at
org.junit.runners.Suite.runChild(Suite.java:27) 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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
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:66)
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
org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:175)
at
[jira] [Created] (GEODE-6284) CI Failure: RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.test[from_v1X0, with reindex=false]
Ryan McMahon created GEODE-6284: --- Summary: CI Failure: RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.test[from_v1X0, with reindex=false] Key: GEODE-6284 URL: https://issues.apache.org/jira/browse/GEODE-6284 Project: Geode Issue Type: Bug Reporter: Ryan McMahon ``` org.apache.geode.test.dunit.RMIException: While invoking org.apache.geode.test.dunit.NamedRunnable.run in VM 1 running on Host 34bae3263b09 with 4 VMs at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:537) at org.apache.geode.test.dunit.VM.invoke(VM.java:352) at org.apache.geode.test.dunit.Invoke.invokeInEveryVM(Invoke.java:57) at org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.doTearDownDistributedTestCase(JUnit4DistributedTestCase.java:496) at org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.tearDownDistributedTestCase(JUnit4DistributedTestCase.java:484) 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.RunAfters.evaluate(RunAfters.java:33) at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) 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.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:27) 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.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) 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:66) 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
[jira] [Updated] (GEODE-6281) RegionHelper.generateCacheXml should not include entry values in the generated xml
[ https://issues.apache.org/jira/browse/GEODE-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao updated GEODE-6281: --- Fix Version/s: 1.9.0 > RegionHelper.generateCacheXml should not include entry values in the > generated xml > -- > > Key: GEODE-6281 > URL: https://issues.apache.org/jira/browse/GEODE-6281 > Project: Geode > Issue Type: Bug > Components: configuration >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > If the cache holds lots of data, this would leads to OOME. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6281) RegionHelper.generateCacheXml should not include entry values in the generated xml
[ https://issues.apache.org/jira/browse/GEODE-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jinmei Liao resolved GEODE-6281. Resolution: Fixed > RegionHelper.generateCacheXml should not include entry values in the > generated xml > -- > > Key: GEODE-6281 > URL: https://issues.apache.org/jira/browse/GEODE-6281 > Project: Geode > Issue Type: Bug > Components: configuration >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > If the cache holds lots of data, this would leads to OOME. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6281) RegionHelper.generateCacheXml should not include entry values in the generated xml
[ https://issues.apache.org/jira/browse/GEODE-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744481#comment-16744481 ] ASF subversion and git services commented on GEODE-6281: Commit 4f300f91f06961189192980d958a7149a873d191 in geode's branch refs/heads/develop from jinmeiliao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4f300f9 ] GEODE-6281: RegionHelper.generateCacheXml should not include entry va… (#3080) * GEODE-6281: RegionHelper.generateCacheXml should not include entry values in the generated xml to avoid OOME. > RegionHelper.generateCacheXml should not include entry values in the > generated xml > -- > > Key: GEODE-6281 > URL: https://issues.apache.org/jira/browse/GEODE-6281 > Project: Geode > Issue Type: Bug > Components: configuration >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > If the cache holds lots of data, this would leads to OOME. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6281) RegionHelper.generateCacheXml should not include entry values in the generated xml
[ https://issues.apache.org/jira/browse/GEODE-6281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744480#comment-16744480 ] ASF subversion and git services commented on GEODE-6281: Commit 4f300f91f06961189192980d958a7149a873d191 in geode's branch refs/heads/develop from jinmeiliao [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4f300f9 ] GEODE-6281: RegionHelper.generateCacheXml should not include entry va… (#3080) * GEODE-6281: RegionHelper.generateCacheXml should not include entry values in the generated xml to avoid OOME. > RegionHelper.generateCacheXml should not include entry values in the > generated xml > -- > > Key: GEODE-6281 > URL: https://issues.apache.org/jira/browse/GEODE-6281 > Project: Geode > Issue Type: Bug > Components: configuration >Reporter: Jinmei Liao >Assignee: Jinmei Liao >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > If the cache holds lots of data, this would leads to OOME. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6187) describe jdbc-mapping should show if mapping is synchronous or not
[ https://issues.apache.org/jira/browse/GEODE-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider updated GEODE-6187: Fix Version/s: 1.9.0 > describe jdbc-mapping should show if mapping is synchronous or not > -- > > Key: GEODE-6187 > URL: https://issues.apache.org/jira/browse/GEODE-6187 > Project: Geode > Issue Type: Improvement > Components: extensions, gfsh >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 1h > Remaining Estimate: 0h > > When a jdbc-mapping is created it is marked as synchronous or async. The > describe jdbc-mapping should also show this information. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6267) Subjects are not logged out when a client departs causing a memory leak
[
https://issues.apache.org/jira/browse/GEODE-6267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1670#comment-1670
]
ASF subversion and git services commented on GEODE-6267:
Commit 9a1e4c801c3385bceec2727d35ef9ec1235803ae in geode's branch
refs/heads/feature/GEODE-6267 from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9a1e4c8 ]
GEODE-6267: Logged out subject
> Subjects are not logged out when a client departs causing a memory leak
> ---
>
> Key: GEODE-6267
> URL: https://issues.apache.org/jira/browse/GEODE-6267
> Project: Geode
> Issue Type: Bug
> Components: security
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When a client with security enabled connects to a server, the
> IntegratedSecurityService logs in a Subject. This causes a SimpleSession to
> be created.
> The Subject is stored in ClientUserAuths.uniqueIdVsSubject.
> Here is a stack showing the SimpleSession creation:
> {noformat}
> [warning 2019/01/08 18:02:42.993 PST server1 Thread 0> tid=0x4e] SimpleSession. invoked:
> java.lang.Exception
> at org.apache.shiro.session.mgt.SimpleSession.(SimpleSession.java:99)
> at
> org.apache.shiro.session.mgt.SimpleSessionFactory.createSession(SimpleSessionFactory.java:44)
> at
> org.apache.shiro.session.mgt.DefaultSessionManager.newSessionInstance(DefaultSessionManager.java:163)
> at
> org.apache.shiro.session.mgt.DefaultSessionManager.doCreateSession(DefaultSessionManager.java:154)
> at
> org.apache.shiro.session.mgt.AbstractValidatingSessionManager.createSession(AbstractValidatingSessionManager.java:136)
> at
> org.apache.shiro.session.mgt.AbstractNativeSessionManager.start(AbstractNativeSessionManager.java:99)
> at
> org.apache.shiro.mgt.SessionsSecurityManager.start(SessionsSecurityManager.java:152)
> at
> org.apache.shiro.subject.support.DelegatingSubject.getSession(DelegatingSubject.java:336)
> at
> org.apache.shiro.subject.support.DelegatingSubject.getSession(DelegatingSubject.java:312)
> at
> org.apache.shiro.mgt.DefaultSubjectDAO.mergePrincipals(DefaultSubjectDAO.java:204)
> at
> org.apache.shiro.mgt.DefaultSubjectDAO.saveToSession(DefaultSubjectDAO.java:166)
> at org.apache.shiro.mgt.DefaultSubjectDAO.save(DefaultSubjectDAO.java:147)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.save(DefaultSecurityManager.java:383)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.createSubject(DefaultSecurityManager.java:350)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.createSubject(DefaultSecurityManager.java:183)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.login(DefaultSecurityManager.java:283)
> at
> org.apache.shiro.subject.support.DelegatingSubject.login(DelegatingSubject.java:256)
> at
> org.apache.geode.internal.security.IntegratedSecurityService.login(IntegratedSecurityService.java:139)
> at
> org.apache.geode.internal.cache.tier.sockets.HandShake.verifyCredentials(HandShake.java:1688)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.setCredentials(ServerConnection.java:1044)
> at
> org.apache.geode.internal.cache.tier.sockets.command.PutUserCredentials.cmdExecute(PutUserCredentials.java:52)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:163)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:797)
> at
> org.apache.geode.internal.cache.tier.sockets.LegacyServerConnection.doOneMessage(LegacyServerConnection.java:85)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1179)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$4$1.run(AcceptorImpl.java:641)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> When the client disconnects, the ClientUserAuths is cleaned up (in cleanup),
> but the Subjects are not logged out.
> With subscription-enabled=true, an additional Subject is created and stored
> in the CacheClientProxy subject. This Subject is not logged out either.
> Here is a stack showing the SimpleSession creation:
> {noformat}
> [warning 2019/01/08 18:02:43.023 PST server1 Thread 0> tid=0x52] SimpleSession. invoked:
> java.lang.Exception
> at org.apache.shiro.session.mgt.SimpleSession.(SimpleSession.java:99)
> at
> org.apache.shiro.session.mgt.SimpleSessionFactory.createSession(SimpleSessionFactory.java:44)
> at
>
[jira] [Commented] (GEODE-6187) describe jdbc-mapping should show if mapping is synchronous or not
[ https://issues.apache.org/jira/browse/GEODE-6187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744438#comment-16744438 ] ASF subversion and git services commented on GEODE-6187: Commit f38389928e575cf2d18825c93ac4f69b7edae3c9 in geode's branch refs/heads/develop from BenjaminPerryRoss [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f383899 ] GEODE-6187: Added sorting and hid empty attributes for DescribeMappingCommand (#3079) Co-authored-by: Ben Ross Co-authored-by: Rob Day-Reynolds > describe jdbc-mapping should show if mapping is synchronous or not > -- > > Key: GEODE-6187 > URL: https://issues.apache.org/jira/browse/GEODE-6187 > Project: Geode > Issue Type: Improvement > Components: extensions, gfsh >Reporter: Darrel Schneider >Assignee: Darrel Schneider >Priority: Major > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > When a jdbc-mapping is created it is marked as synchronous or async. The > describe jdbc-mapping should also show this information. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-6272) the JDBC connector should use PDX instances instead of JSON for composite keys
[
https://issues.apache.org/jira/browse/GEODE-6272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Darrel Schneider resolved GEODE-6272.
-
Resolution: Fixed
Fix Version/s: 1.9.0
> the JDBC connector should use PDX instances instead of JSON for composite keys
> --
>
> Key: GEODE-6272
> URL: https://issues.apache.org/jira/browse/GEODE-6272
> Project: Geode
> Issue Type: Improvement
> Components: docs, extensions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> *As a* GemFire user with composite keys
> *I want to* to replace JSON with PDX for these keys
> *so that I can* support any order for the keys and have minimal memory impact.
>
> *Acceptance Criteria:*
> *Given* a jdbc-mapping uses a composite key
> *When* I do CRUD operations on data in the region
> *Then* I must specify the key as a "stable" PDX instance that contains fields
> that match those specified by {{--id}}.
> *Given* an existing cache with a jdbc-mapping that uses a composite key
> *When* I want to specify a composite key for a CRUD operation
> *Then* I have a method on the cache to create a "stable" PDX instance.
> *Given* an existing cache with a jdbc-mapping that uses a composite key
> *When* I want to specify a composite key for a CRUD operation
> *Then* I have a method on the cache to create a "stable" PDX instance and the
> order of fields in the composite key doesn't matter.
> *Given* an existing cache with pdx-read-serialized is set to false
> *When* I do an operation that triggers deserialization of a "stable" PDX
> instance
> *Then* the "stable" PDX instance will be deserialized as the same "stable"
> PDX instance.
> *Given* a "stable" PDX instance
> *When* I call its getObject method
> *Then* it will return the same "stable" PDX instance.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6272) the JDBC connector should use PDX instances instead of JSON for composite keys
[
https://issues.apache.org/jira/browse/GEODE-6272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744434#comment-16744434
]
ASF subversion and git services commented on GEODE-6272:
Commit 56fda39a8ab41fc9ffeddb3da13322eaa1516084 in geode's branch
refs/heads/develop from Darrel Schneider
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=56fda39 ]
GEODE-6272: change jdbc to use pdx as keys instead of json (#3076)
Composite keys for the jdbc connector must now be PdxInstances created with
"neverDeserialize".
* added PdxInstanceFactory.neverDeserialize and PdxInstance.isDeserializable as
new external APIs.
* improved the InternalPdxInstance interface to include Sendable.
Also this interface is now implemented by the pdx enum classes.
So now all classes that implement PdxInstance also implement InternalPdxInstance
* getCacheObject is now on the InternalPdxInstance interface.
* getRawField is now in the InternalPdxInstance interface.
A method that was on PdxInstanceImpl but only used by AttributeDescriptor
and that did not use any PdxInstanceImpl data is now on AttributeDescriptor.
This also got rid of a singleton lookup of the cache.
* removed unused FieldNotFoundInPdxVersion
* removed PdxFieldNotFoundException
> the JDBC connector should use PDX instances instead of JSON for composite keys
> --
>
> Key: GEODE-6272
> URL: https://issues.apache.org/jira/browse/GEODE-6272
> Project: Geode
> Issue Type: Improvement
> Components: docs, extensions
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> *As a* GemFire user with composite keys
> *I want to* to replace JSON with PDX for these keys
> *so that I can* support any order for the keys and have minimal memory impact.
>
> *Acceptance Criteria:*
> *Given* a jdbc-mapping uses a composite key
> *When* I do CRUD operations on data in the region
> *Then* I must specify the key as a "stable" PDX instance that contains fields
> that match those specified by {{--id}}.
> *Given* an existing cache with a jdbc-mapping that uses a composite key
> *When* I want to specify a composite key for a CRUD operation
> *Then* I have a method on the cache to create a "stable" PDX instance.
> *Given* an existing cache with a jdbc-mapping that uses a composite key
> *When* I want to specify a composite key for a CRUD operation
> *Then* I have a method on the cache to create a "stable" PDX instance and the
> order of fields in the composite key doesn't matter.
> *Given* an existing cache with pdx-read-serialized is set to false
> *When* I do an operation that triggers deserialization of a "stable" PDX
> instance
> *Then* the "stable" PDX instance will be deserialized as the same "stable"
> PDX instance.
> *Given* a "stable" PDX instance
> *When* I call its getObject method
> *Then* it will return the same "stable" PDX instance.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6267) Subjects are not logged out when a client departs causing a memory leak
[
https://issues.apache.org/jira/browse/GEODE-6267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-6267:
--
Labels: pull-request-available (was: )
> Subjects are not logged out when a client departs causing a memory leak
> ---
>
> Key: GEODE-6267
> URL: https://issues.apache.org/jira/browse/GEODE-6267
> Project: Geode
> Issue Type: Bug
> Components: security
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>Priority: Major
> Labels: pull-request-available
>
> When a client with security enabled connects to a server, the
> IntegratedSecurityService logs in a Subject. This causes a SimpleSession to
> be created.
> The Subject is stored in ClientUserAuths.uniqueIdVsSubject.
> Here is a stack showing the SimpleSession creation:
> {noformat}
> [warning 2019/01/08 18:02:42.993 PST server1 Thread 0> tid=0x4e] SimpleSession. invoked:
> java.lang.Exception
> at org.apache.shiro.session.mgt.SimpleSession.(SimpleSession.java:99)
> at
> org.apache.shiro.session.mgt.SimpleSessionFactory.createSession(SimpleSessionFactory.java:44)
> at
> org.apache.shiro.session.mgt.DefaultSessionManager.newSessionInstance(DefaultSessionManager.java:163)
> at
> org.apache.shiro.session.mgt.DefaultSessionManager.doCreateSession(DefaultSessionManager.java:154)
> at
> org.apache.shiro.session.mgt.AbstractValidatingSessionManager.createSession(AbstractValidatingSessionManager.java:136)
> at
> org.apache.shiro.session.mgt.AbstractNativeSessionManager.start(AbstractNativeSessionManager.java:99)
> at
> org.apache.shiro.mgt.SessionsSecurityManager.start(SessionsSecurityManager.java:152)
> at
> org.apache.shiro.subject.support.DelegatingSubject.getSession(DelegatingSubject.java:336)
> at
> org.apache.shiro.subject.support.DelegatingSubject.getSession(DelegatingSubject.java:312)
> at
> org.apache.shiro.mgt.DefaultSubjectDAO.mergePrincipals(DefaultSubjectDAO.java:204)
> at
> org.apache.shiro.mgt.DefaultSubjectDAO.saveToSession(DefaultSubjectDAO.java:166)
> at org.apache.shiro.mgt.DefaultSubjectDAO.save(DefaultSubjectDAO.java:147)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.save(DefaultSecurityManager.java:383)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.createSubject(DefaultSecurityManager.java:350)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.createSubject(DefaultSecurityManager.java:183)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.login(DefaultSecurityManager.java:283)
> at
> org.apache.shiro.subject.support.DelegatingSubject.login(DelegatingSubject.java:256)
> at
> org.apache.geode.internal.security.IntegratedSecurityService.login(IntegratedSecurityService.java:139)
> at
> org.apache.geode.internal.cache.tier.sockets.HandShake.verifyCredentials(HandShake.java:1688)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.setCredentials(ServerConnection.java:1044)
> at
> org.apache.geode.internal.cache.tier.sockets.command.PutUserCredentials.cmdExecute(PutUserCredentials.java:52)
> at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:163)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:797)
> at
> org.apache.geode.internal.cache.tier.sockets.LegacyServerConnection.doOneMessage(LegacyServerConnection.java:85)
> at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1179)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$4$1.run(AcceptorImpl.java:641)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> When the client disconnects, the ClientUserAuths is cleaned up (in cleanup),
> but the Subjects are not logged out.
> With subscription-enabled=true, an additional Subject is created and stored
> in the CacheClientProxy subject. This Subject is not logged out either.
> Here is a stack showing the SimpleSession creation:
> {noformat}
> [warning 2019/01/08 18:02:43.023 PST server1 Thread 0> tid=0x52] SimpleSession. invoked:
> java.lang.Exception
> at org.apache.shiro.session.mgt.SimpleSession.(SimpleSession.java:99)
> at
> org.apache.shiro.session.mgt.SimpleSessionFactory.createSession(SimpleSessionFactory.java:44)
> at
> org.apache.shiro.session.mgt.DefaultSessionManager.newSessionInstance(DefaultSessionManager.java:163)
> at
> org.apache.shiro.session.mgt.DefaultSessionManager.doCreateSession(DefaultSessionManager.java:154)
> at
> org.apache.shiro.session.mgt.AbstractValidatingSessionManager.createSession(AbstractValidatingSessionManager.java:136)
> at
[jira] [Updated] (GEODE-6280) Create new public module for the Management API
[ https://issues.apache.org/jira/browse/GEODE-6280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-6280: -- Labels: pull-request-available (was: ) > Create new public module for the Management API > --- > > Key: GEODE-6280 > URL: https://issues.apache.org/jira/browse/GEODE-6280 > Project: Geode > Issue Type: New Feature > Components: configuration >Reporter: Jens Deppe >Priority: Major > Labels: pull-request-available > > We will need a new public module for the Management API. This separate > module, once compiled, will produce a jar that developers can download (via > Maven or otherwise) to access the Management API. Thus it is required that > any dependencies we have that are currently "internal" need to be moved into > this public module. > h3. Acceptance Criteria > *Given* I am a java developer > *and* configured my `build.gradle` to pull down the Geode Management API > module > *When* I do a gradlew build > *Then* I can write a java application that uses components inside this module > *and* the module is self contained and does not have other geode dependencies. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-1837) RemoteQueryDUnitTest.testRemoteComplexQueries needs to be rewritten
[ https://issues.apache.org/jira/browse/GEODE-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Huynh reassigned GEODE-1837: -- Assignee: (was: Jason Huynh) > RemoteQueryDUnitTest.testRemoteComplexQueries needs to be rewritten > --- > > Key: GEODE-1837 > URL: https://issues.apache.org/jira/browse/GEODE-1837 > Project: Geode > Issue Type: Test > Components: tests >Affects Versions: 1.0.0-incubating >Reporter: Kirk Lund >Priority: Major > Labels: query > > RemoteQueryDUnitTest.testRemoteComplexQueries is disabled and needs to be > rewritten using the Portfolio and Position classes in the package > com.gemstone.gemfire.cache.query.data. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6060) CacheListener example in Geode Examples does not properly register listener
[ https://issues.apache.org/jira/browse/GEODE-6060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon updated GEODE-6060: Fix Version/s: 1.9.0 > CacheListener example in Geode Examples does not properly register listener > --- > > Key: GEODE-6060 > URL: https://issues.apache.org/jira/browse/GEODE-6060 > Project: Geode > Issue Type: Bug > Components: examples >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 40m > Remaining Estimate: 0h > > The CacheListener example does not actually register the > ExampleCacheListener() so the callback methods are not invoked which print to > the console. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-6283) The v2 REST conrtoller have a LocatorClusterManagementService instance injected and created
[
https://issues.apache.org/jira/browse/GEODE-6283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reassigned GEODE-6283:
---
Assignee: Jinmei Liao
> The v2 REST conrtoller have a LocatorClusterManagementService instance
> injected and created
> ---
>
> Key: GEODE-6283
> URL: https://issues.apache.org/jira/browse/GEODE-6283
> Project: Geode
> Issue Type: Sub-task
> Components: configuration
>Reporter: Kenneth Howe
>Assignee: Jinmei Liao
>Priority: Major
>
> As originally implemented, the controller is a noop. Inject a
> {ClusterManagementService}} into the controller and call it's {{create}}
> method.
> The result of this implementation should be:
> When: {{curl :7070/geode-management/v2}} with a cache element
> with region name and type
>
> Then: {{gfsh list regions}} should show that the region was created in the
> cluster
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6283) The v2 REST conrtoller have a LocatorClusterManagementService instance injected and created
Kenneth Howe created GEODE-6283:
---
Summary: The v2 REST conrtoller have a
LocatorClusterManagementService instance injected and created
Key: GEODE-6283
URL: https://issues.apache.org/jira/browse/GEODE-6283
Project: Geode
Issue Type: Sub-task
Components: configuration
Reporter: Kenneth Howe
As originally implemented, the controller is a noop. Inject a
{ClusterManagementService}} into the controller and call it's {{create}} method.
The result of this implementation should be:
When: {{curl :7070/geode-management/v2}} with a cache element
with region name and type
Then: {{gfsh list regions}} should show that the region was created in the
cluster
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-250) In PartitionedRegionQueryEvaluator, the ResultsCollector may be changed to just a flat Collection
[ https://issues.apache.org/jira/browse/GEODE-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Huynh reassigned GEODE-250: - Assignee: (was: Jason Huynh) > In PartitionedRegionQueryEvaluator, the ResultsCollector may be changed to > just a flat Collection > - > > Key: GEODE-250 > URL: https://issues.apache.org/jira/browse/GEODE-250 > Project: Geode > Issue Type: Improvement > Components: querying >Reporter: Jason Huynh >Priority: Minor > > Currently there is a Collection resultsCollector used in various > places. We end up iterating through the collection of collections and adding > all elements to a result set. I think we should be able to change this to a > flat collection and remove some lines of code iterating/combining this thing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-147) Unable to match iterator for indexed query using alias when update in progress
[
https://issues.apache.org/jira/browse/GEODE-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Huynh reassigned GEODE-147:
-
Assignee: (was: Jason Huynh)
> Unable to match iterator for indexed query using alias when update in progress
> --
>
> Key: GEODE-147
> URL: https://issues.apache.org/jira/browse/GEODE-147
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Jason Huynh
>Priority: Minor
>
> The problem occurs when there is an update in progress and a query that uses
> an index has an alias in the from clause of a query and not in the where
> clause.
> For example:
> select p.id from /portfolios p.entriesSet entry where value.score = $1
> A possible fix would be to also match the indexed expression with the path
> name.
> if(path.getType() == OQLLexerTokenTypes.Identifier
> || itr.getName().equals(pathName) ||
> info._getIndex().getIndexedExpression().startsWith(pathName + ".")) {
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-4825) Lucene Index sets pdx read serialized to true
[ https://issues.apache.org/jira/browse/GEODE-4825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Huynh resolved GEODE-4825. Resolution: Fixed > Lucene Index sets pdx read serialized to true > - > > Key: GEODE-4825 > URL: https://issues.apache.org/jira/browse/GEODE-4825 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Jason Huynh >Assignee: Jason Huynh >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > In IndexRepositoryFactory, there is a call to set the pdx read serialized to > true, but it is only unset if the index failed to be created. Instead it > should be pulled out of the if block. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-2266) index creation with value constraint of PdxInstance should not validate indexed field
[ https://issues.apache.org/jira/browse/GEODE-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Huynh reassigned GEODE-2266: -- Assignee: (was: Jason Huynh) > index creation with value constraint of PdxInstance should not validate > indexed field > - > > Key: GEODE-2266 > URL: https://issues.apache.org/jira/browse/GEODE-2266 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Jason Huynh >Priority: Major > > When creating an index on a region with a value constraint, we validate that > the indexed field exists as a value for the value constraint object type. It > makes sense to validate this field exists on a user domain object as the > index would be useless if the field did not exist for the only object type > for this region. However if the value constraint is a PdxInstance, we should > not validate this field exists and instead treat it similar to a non value > constrained region. This is because the PdxInstance can represent any object > type and the field is not specifically a field on the PdxInstance object but > rather a field on the pdx serialized object. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5678) Primary Key index results should work correctly with cq results
[ https://issues.apache.org/jira/browse/GEODE-5678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Huynh resolved GEODE-5678. Resolution: Fixed Fix Version/s: 1.8.0 > Primary Key index results should work correctly with cq results > --- > > Key: GEODE-5678 > URL: https://issues.apache.org/jira/browse/GEODE-5678 > Project: Geode > Issue Type: Bug > Components: cq, querying >Reporter: Jason Huynh >Assignee: Jason Huynh >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 20m > Remaining Estimate: 0h > > When a cq is executed and the query ends up using a primary key index, the > result is not being wrapped in a cq entry. This causes a class cast > exception. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5137) clean up oql.g build warnings
[ https://issues.apache.org/jira/browse/GEODE-5137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Huynh reassigned GEODE-5137: -- Assignee: (was: Jason Huynh) > clean up oql.g build warnings > - > > Key: GEODE-5137 > URL: https://issues.apache.org/jira/browse/GEODE-5137 > Project: Geode > Issue Type: Task > Components: querying >Reporter: Jason Huynh >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > when building Geode, we see oql.g warning about nondeterminism in our > grammar. This is a ticket to address those issues. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4999) support for tcserver requires specific tomcat 8 and 85 directories
[ https://issues.apache.org/jira/browse/GEODE-4999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Huynh resolved GEODE-4999. Resolution: Fixed > support for tcserver requires specific tomcat 8 and 85 directories > -- > > Key: GEODE-4999 > URL: https://issues.apache.org/jira/browse/GEODE-4999 > Project: Geode > Issue Type: Bug > Components: http session >Reporter: Jason Huynh >Assignee: Jason Huynh >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > currently we support tomcat 7 and tomcat 8 along with tcserver. For tcserver > to move to geode, it requires specific tomcat 85 directories to be created. > Currently tomcat 8 modules do support 8.5 and above but tcserver requires > explicit artifacts to be created -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5806) Create new example for durable client subscriptions
[ https://issues.apache.org/jira/browse/GEODE-5806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon updated GEODE-5806: Fix Version/s: 1.9.0 > Create new example for durable client subscriptions > --- > > Key: GEODE-5806 > URL: https://issues.apache.org/jira/browse/GEODE-5806 > Project: Geode > Issue Type: New Feature > Components: examples >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Create a new example for durable messaging with client subscriptions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5565) Release off heap entry during gii if Region has been destroyed
[ https://issues.apache.org/jira/browse/GEODE-5565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Huynh resolved GEODE-5565. Resolution: Fixed Fix Version/s: 1.8.0 > Release off heap entry during gii if Region has been destroyed > --- > > Key: GEODE-5565 > URL: https://issues.apache.org/jira/browse/GEODE-5565 > Project: Geode > Issue Type: Bug > Components: offheap >Affects Versions: 1.0.0-incubating >Reporter: Jason Huynh >Assignee: Jason Huynh >Priority: Major > Labels: pull-request-available > Fix For: 1.8.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > A RegionDestroyedException can occur at the following stack trace > at > org.apache.geode.internal.cache.DiskStoreImpl.acquireReadLock(DiskStoreImpl.java:1170) > at > org.apache.geode.internal.cache.DiskRegion.acquireReadLock(DiskRegion.java:649) > at > org.apache.geode.internal.cache.entries.DiskEntry$Helper.update(DiskEntry.java:856) > at > org.apache.geode.internal.cache.entries.AbstractDiskRegionEntry.setValue(AbstractDiskRegionEntry.java:38) > at > org.apache.geode.internal.cache.entries.AbstractDiskRegionEntry.setValue(AbstractDiskRegionEntry.java:32) > at > org.apache.geode.internal.cache.entries.AbstractRegionEntry.initialImageInit(AbstractRegionEntry.java:747) > at > org.apache.geode.internal.cache.AbstractRegionMap.initialImagePut(AbstractRegionMap.java:949) > at > org.apache.geode.internal.cache.InitialImageOperation.processChunk(InitialImageOperation.java:978) > at > org.apache.geode.internal.cache.InitialImageOperation$ImageProcessor.process(InitialImageOperation.java:1308) > at > org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:209) > at > org.apache.geode.internal.cache.InitialImageOperation$ImageReplyMessage.process(InitialImageOperation.java:2796) > at > org.apache.geode.distributed.internal.ReplyMessage.dmProcess(ReplyMessage.java:193) > at > org.apache.geode.distributed.internal.ReplyMessage.process(ReplyMessage.java:186) > at > org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:369) > at > org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:435) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:1136) > at > org.apache.geode.distributed.internal.ClusterDistributionManager.access$000(ClusterDistributionManager.java:112) > at > org.apache.geode.distributed.internal.ClusterDistributionManager$5$1.run(ClusterDistributionManager.java:849) > at java.lang.Thread.run(Thread.java:748) > This ends up with an off heap reference, although the region is no longer > there. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5625) CI Failure: RollingUpgradeRollServersOnPartitionedRegion_dataserializable
[
https://issues.apache.org/jira/browse/GEODE-5625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Huynh reassigned GEODE-5625:
--
Assignee: (was: Jason Huynh)
> CI Failure: RollingUpgradeRollServersOnPartitionedRegion_dataserializable
> -
>
> Key: GEODE-5625
> URL: https://issues.apache.org/jira/browse/GEODE-5625
> Project: Geode
> Issue Type: Bug
> Components: ci
>Reporter: Sai Boorlagadda
>Priority: Major
> Labels: swat
>
> [https://concourse.apachegeode-ci.info/builds/19873]
> Build artifacts:
> [http://files.apachegeode-ci.info/builds/geode-pr-2357/test-results/upgradeTest/1534894392/]
>
> {code:java}
> org.apache.geode.internal.cache.rollingupgrade.RollingUpgradeRollServersOnPartitionedRegion_dataserializable
> > testRollServersOnPartitionedRegion_dataserializable[from_v120] FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 6207
> [fatal 2018/08/21 23:09:52.169 UTC
> tid=225] Possible loss of quorum due to the loss of 1 cache processes:
> [172.17.0.27(5931):32771]
> ---
> Found suspect string in log4j at line 6222
> [fatal 2018/08/21 23:09:53.171 UTC
> tid=225] Membership service failure: Exiting due to possible network
> partition event due to loss of 1 cache processes:
> [172.17.0.27(5931):32771]
> org.apache.geode.ForcedDisconnectException: Exiting due to possible
> network partition event due to loss of 1 cache processes:
> [172.17.0.27(5931):32771]
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.forceDisconnect(GMSMembershipManager.java:2534)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.forceDisconnect(GMSJoinLeave.java:1054)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.access$1500(GMSJoinLeave.java:92)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.prepareAndSendView(GMSJoinLeave.java:2507)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.sendInitialView(GMSJoinLeave.java:2136)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.run(GMSJoinLeave.java:2214){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6278) CI failure: org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest. testRangeIndex
[
https://issues.apache.org/jira/browse/GEODE-6278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Huynh reassigned GEODE-6278:
--
Assignee: (was: Jason Huynh)
> CI failure:
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest.
> testRangeIndex
> --
>
> Key: GEODE-6278
> URL: https://issues.apache.org/jira/browse/GEODE-6278
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Aditya Anchuri
>Priority: Major
>
> {code:java}
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest >
> testRangeIndex FAILED
>
> java.lang.AssertionError: Thread did not terminate after 200 ms: Thread[run
> invoked on an instance of
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest$6,5,]
>
> at org.junit.Assert.fail(Assert.java:88)
>
> at org.apache.geode.test.dunit.ThreadUtils.join(ThreadUtils.java:147)
>
> at org.apache.geode.test.dunit.ThreadUtils.join(ThreadUtils.java:110)
>
> at
> org.apache.geode.cache.query.dunit.QueryDataInconsistencyDUnitTest.testRangeIndex(QueryDataInconsistencyDUnitTest.java:304){code}
> Seems like a flakey test.
> http://concourse.gemfire.pivotal.io/teams/main/pipelines/gemfire-9.3/jobs/DistributedTest/builds/18
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6060) CacheListener example in Geode Examples does not properly register listener
[ https://issues.apache.org/jira/browse/GEODE-6060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon resolved GEODE-6060. - Resolution: Fixed Fix Version/s: 1.9.0 > CacheListener example in Geode Examples does not properly register listener > --- > > Key: GEODE-6060 > URL: https://issues.apache.org/jira/browse/GEODE-6060 > Project: Geode > Issue Type: Bug > Components: examples >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Time Spent: 40m > Remaining Estimate: 0h > > The CacheListener example does not actually register the > ExampleCacheListener() so the callback methods are not invoked which print to > the console. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-670) The size of the GatewaySenderEvent is sometimes calculated by serializing its value rather than using the Sizeable interface
[
https://issues.apache.org/jira/browse/GEODE-670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barry Oglesby resolved GEODE-670.
-
Resolution: Fixed
> The size of the GatewaySenderEvent is sometimes calculated by serializing its
> value rather than using the Sizeable interface
>
>
> Key: GEODE-670
> URL: https://issues.apache.org/jira/browse/GEODE-670
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>Priority: Major
>
> {{BucketRegion calcMemSize}} special-cases {{GatewaySenderEventImpl}} to get
> just its value. In most cases, the value is a byte[], so the size is just the
> length of the byte[]. If the {{GatewayEventSubstitutionFilter}} is used, then
> the event's value is null and its valueObject is a java object. In this case,
> the valueObject is serialized and returned. {{BucketRegion calcMemSize}} then
> just returns the length of that byte{} using {{CachedDeserializableFactory
> calcMemSize}}.
> {{GatewaySenderEventImpl}} shouldn't be special-cased. It can be sized using
> {{CachedDeserializableFactory calcMemSize}} just like other values. This will
> invoke {{GatewaySenderEventImpl getSizeInBytes}} which does the right thing
> for the valueObject by invoking {{CachedDeserializableFactory calcMemSize}}
> on it. This method uses the {{Sizeable}} interface if appropriate. The
> resulting size will be a bit bigger but more accurate than what is currently
> reported.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6246) An EntryNotFoundException can be thrown by BucketRegionQueue.basicDestroy during GatewaySender queue initialization
[
https://issues.apache.org/jira/browse/GEODE-6246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barry Oglesby resolved GEODE-6246.
--
Resolution: Fixed
> An EntryNotFoundException can be thrown by BucketRegionQueue.basicDestroy
> during GatewaySender queue initialization
> ---
>
> Key: GEODE-6246
> URL: https://issues.apache.org/jira/browse/GEODE-6246
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> An EntryNotFoundException like below can be thrown by
> BucketRegionQueue.basicDestroy during GatewaySender queue initialization:
> {noformat}
> [warn 2019/01/03 15:53:00.423 PST
> tid=0x56] Task failed with exception
> org.apache.geode.cache.EntryNotFoundException: 57546
> at
> org.apache.geode.internal.cache.BucketRegionQueue.basicDestroy(BucketRegionQueue.java:368)
> at
> org.apache.geode.internal.cache.BucketRegionQueue.destroyKey(BucketRegionQueue.java:564)
> at
> org.apache.geode.internal.cache.BucketRegionQueue.destroyFailedBatchRemovalMessageKeys(BucketRegionQueue.java:181)
> at
> org.apache.geode.internal.cache.BucketRegionQueue.initializeEventSeqNumQueue(BucketRegionQueue.java:151)
> at
> org.apache.geode.internal.cache.BucketRegionQueue.cleanUpDestroyedTokensAndMarkGIIComplete(BucketRegionQueue.java:89)
> at
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1220)
> at
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1071)
> at
> org.apache.geode.internal.cache.BucketRegion.initialize(BucketRegion.java:256)
> at
> org.apache.geode.internal.cache.LocalRegion.createSubregion(LocalRegion.java:1012)
> at
> org.apache.geode.internal.cache.PartitionedRegionDataStore.createBucketRegion(PartitionedRegionDataStore.java:776)
> at
> org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucket(PartitionedRegionDataStore.java:451)
> at
> org.apache.geode.internal.cache.PartitionedRegionDataStore.grabFreeBucketRecursively(PartitionedRegionDataStore.java:310)
> at
> org.apache.geode.internal.cache.PartitionedRegionDataStore.grabBucket(PartitionedRegionDataStore.java:2881)
> at
> org.apache.geode.internal.cache.PRHARedundancyProvider.createBackupBucketOnMember(PRHARedundancyProvider.java:1122)
> at
> org.apache.geode.internal.cache.partitioned.PartitionedRegionRebalanceOp.createRedundantBucketForRegion(PartitionedRegionRebalanceOp.java:511)
> at
> org.apache.geode.internal.cache.partitioned.rebalance.BucketOperatorImpl.createRedundantBucket(BucketOperatorImpl.java:54)
> at
> org.apache.geode.internal.cache.partitioned.rebalance.BucketOperatorWrapper.createRedundantBucket(BucketOperatorWrapper.java:100)
> at
> org.apache.geode.internal.cache.partitioned.rebalance.ParallelBucketOperator$1.run(ParallelBucketOperator.java:91)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.runUntilShutdown(ClusterDistributionManager.java:956)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager.doWaitingThread(ClusterDistributionManager.java:846)
> at
> org.apache.geode.internal.logging.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:121)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6060) CacheListener example in Geode Examples does not properly register listener
[ https://issues.apache.org/jira/browse/GEODE-6060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon updated GEODE-6060: Fix Version/s: (was: 1.9.0) > CacheListener example in Geode Examples does not properly register listener > --- > > Key: GEODE-6060 > URL: https://issues.apache.org/jira/browse/GEODE-6060 > Project: Geode > Issue Type: Bug > Components: examples >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > The CacheListener example does not actually register the > ExampleCacheListener() so the callback methods are not invoked which print to > the console. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-5806) Create new example for durable client subscriptions
[ https://issues.apache.org/jira/browse/GEODE-5806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon closed GEODE-5806. --- > Create new example for durable client subscriptions > --- > > Key: GEODE-5806 > URL: https://issues.apache.org/jira/browse/GEODE-5806 > Project: Geode > Issue Type: New Feature > Components: examples >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > Create a new example for durable messaging with client subscriptions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5806) Create new example for durable client subscriptions
[ https://issues.apache.org/jira/browse/GEODE-5806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McMahon resolved GEODE-5806. - Resolution: Fixed > Create new example for durable client subscriptions > --- > > Key: GEODE-5806 > URL: https://issues.apache.org/jira/browse/GEODE-5806 > Project: Geode > Issue Type: New Feature > Components: examples >Reporter: Ryan McMahon >Assignee: Ryan McMahon >Priority: Major > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > Create a new example for durable messaging with client subscriptions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-394) Casting FunctionContext to RegionFunctionContext is an ugly API
[
https://issues.apache.org/jira/browse/GEODE-394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith reassigned GEODE-394:
---
Assignee: (was: Dan Smith)
> Casting FunctionContext to RegionFunctionContext is an ugly API
> ---
>
> Key: GEODE-394
> URL: https://issues.apache.org/jira/browse/GEODE-394
> Project: Geode
> Issue Type: Improvement
> Components: functions
>Reporter: Dan Smith
>Priority: Major
>
> If a function is invoked on a region, it's common to try to get at the local
> data set for the function.
> The API do this is is pretty ugly. It should be cleaned up
> {code}
> RegionFunctionContext ctx = (RegionFunctionContext) context;
> Region data = PartitionRegionHelper.getLocalDataForContext(ctx);
> {code}
> Instead of this, functions that are invoked on regions should probably
> implement a different interface that gets passed the local data they are
> interested in.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5863) CqDataDUnitTest.testMultipleExecuteWithInitialResults ignores assertion failures
[
https://issues.apache.org/jira/browse/GEODE-5863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith reassigned GEODE-5863:
Assignee: (was: Dan Smith)
> CqDataDUnitTest.testMultipleExecuteWithInitialResults ignores assertion
> failures
>
>
> Key: GEODE-5863
> URL: https://issues.apache.org/jira/browse/GEODE-5863
> Project: Geode
> Issue Type: Improvement
>Reporter: Dan Smith
>Priority: Major
> Labels: pull-request-available, swat
> Time Spent: 40m
> Remaining Estimate: 0h
>
> This test has assertions in an asynchronous thread. However, it never
> actually checks the results from that thread, it just asserts that the thread
> finishes. In practice, processCqs always throws an Awaitility exception,
> which is ignored and the test passes.
> This is the problematic code. ThreadUtils.join does not check the result of
> the async invocation:
> {code}
> ThreadUtils.join(processCqs, 60 * 1000);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-1762) FunctionService throws exceptions from different places for clients and peers
[
https://issues.apache.org/jira/browse/GEODE-1762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith reassigned GEODE-1762:
Assignee: (was: Dan Smith)
> FunctionService throws exceptions from different places for clients and peers
> -
>
> Key: GEODE-1762
> URL: https://issues.apache.org/jira/browse/GEODE-1762
> Project: Geode
> Issue Type: Bug
> Components: functions
>Reporter: Dan Smith
>Priority: Major
>
> If a function throws an exception, the exception gets passed back to the
> caller from a different location if the function is executed from a client or
> a peer.
> From a peer, the exception is thrown from the result collector
> From
> [FunctionServiceBase|https://github.com/apache/incubator-geode/blob/aca7b288f378ec05e00ec3a9277265d1a9679b4a/geode-core/src/test/java/com/gemstone/gemfire/internal/cache/execute/FunctionServiceBase.java]:
> {code}
> @Test()
> public void
> defaultCollectorThrowsExceptionAfterFunctionThrowsIllegalState() {
> final Host host = Host.getHost(0);
> ResultCollector rc = getExecution().execute((context) -> {throw new
> IllegalStateException();});
> //On a peer the exception is thrown from the rc.getResult call, below
> final Object result = rc.getResult();
> }
> {code}
> However, from a client executing the exact same code, the exception gets
> thrown from the Execution.execute() method instead.
> {code}
> @Test()
> public void
> defaultCollectorThrowsExceptionAfterFunctionThrowsIllegalState() {
> final Host host = Host.getHost(0);
> //On a client the exception is thrown from the execute call, below
> ResultCollector rc = getExecution().execute((context) -> {throw new
> IllegalStateException();});
> }
> {code}
> The exception handling should be consistent between clients and peers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-729) Create new RegionFunction MemberFunction interfaces
[ https://issues.apache.org/jira/browse/GEODE-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith reassigned GEODE-729: --- Assignee: (was: Dan Smith) > Create new RegionFunction MemberFunction interfaces > --- > > Key: GEODE-729 > URL: https://issues.apache.org/jira/browse/GEODE-729 > Project: Geode > Issue Type: Improvement >Reporter: Dan Smith >Priority: Major > > See the > https://cwiki.apache.org/confluence/display/GEODE/Function+Service+Usability+Improvments#FunctionServiceUsabilityImprovments-TheFunctioninterfaceshouldreturnavalue > We need to create these new interfaces - RegionFunction and MemberFunction. > We also need to add instance methods to the FunctionService class and > deprecate the static methods, as described in the wiki page. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-404) Using AttributesMutator.addAsyncEventQueueId in a system with concurrent operations will cause failures
[ https://issues.apache.org/jira/browse/GEODE-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith reassigned GEODE-404: --- Assignee: (was: Dan Smith) > Using AttributesMutator.addAsyncEventQueueId in a system with concurrent > operations will cause failures > --- > > Key: GEODE-404 > URL: https://issues.apache.org/jira/browse/GEODE-404 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Dan Smith >Priority: Major > > It's possible to add an async event queue after a region is created using > AttributesMutator.addAsyncEventQueueId. > However, this code appears to have some issues if there are concurrent > operations executing. Every put goes through > LocalRegion.checkSameSenderIdsAvailableOnAllNodes. This method will throw an > exception if the async queue is not added on all nodes. > Since the AsyncEventQueue will not be added at exactly the same time on all > nodes, there will be a window of time when puts will throw exceptions when > adding an AsyncEventQueue. > In addition, this may be intentional, but *new* members that join a system > *must* have the AEQ defined in their region attributes before creating the > region. They cannot add the AEQ later. So the mutator is not useful as part > of the initialization of a member. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-498) Callback argument size is not reflected in bucket size for parallel queues
[
https://issues.apache.org/jira/browse/GEODE-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith reassigned GEODE-498:
---
Assignee: (was: Dan Smith)
> Callback argument size is not reflected in bucket size for parallel queues
> --
>
> Key: GEODE-498
> URL: https://issues.apache.org/jira/browse/GEODE-498
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Dan Smith
>Priority: Major
>
> I found this while tracking down GEODE-244. This appears to be a new problem
> that was introduced by the off heap changes. This is problematic because this
> size is used for rebalancing calculations, so bugs in the reported size could
> cause rebalancing issues.
> The issue is that the size reported by BucketRegion.getTotalBytes() is
> incorrect for parallel async event queues. The size does not include the size
> of the callback argument.
> I tracked this down to this code in BucketRegion.calcMemSize, which looks
> like it was added for offheap:
> {code}
> static int calcMemSize(Object value) {
> if (value != null && (value instanceof GatewaySenderEventImpl)) {
> return ((GatewaySenderEventImpl)value).getSerializedValueSize();
> }
> ...
> }
> {code}
> Interestingly, it looks like for the purposes of eviction, we do include the
> callback argument size, because the MemLRUCapacityController calls
> GatewaySenderEventImpl.getSizeInBytes
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-625) A function's ResultCollector throws ClassCastException when ResultSender.sendException is invoked
[
https://issues.apache.org/jira/browse/GEODE-625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith reassigned GEODE-625:
---
Assignee: (was: Dan Smith)
> A function's ResultCollector throws ClassCastException when
> ResultSender.sendException is invoked
> -
>
> Key: GEODE-625
> URL: https://issues.apache.org/jira/browse/GEODE-625
> Project: Geode
> Issue Type: Bug
> Components: functions
>Reporter: Ashvin
>Priority: Major
>
> For e.g. If LuceneFunction.execute invokes resultSender.sendException, the
> following error is generated.
> {code}
> java.lang.ClassCastException: java.lang.IllegalArgumentException cannot be
> cast to com.gemstone.gemfire.cache.lucene.int
> ernal.distributed.TopEntriesCollector
> at
> com.gemstone.gemfire.cache.lucene.internal.distributed.TopEntriesFunctionCollector.addResult(TopEntriesFunctionColle
> ctor.java:1)
> at
> com.gemstone.gemfire.internal.cache.execute.LocalResultCollectorImpl.addResult(LocalResultCollectorImpl.java:76)
> at
> com.gemstone.gemfire.internal.cache.execute.PartitionedRegionFunctionResultSender.lastResult(PartitionedRegionFuncti
> onResultSender.java:208)
> at
> com.gemstone.gemfire.internal.cache.execute.PartitionedRegionFunctionResultSender.lastResult(PartitionedRegionFuncti
> onResultSender.java:166)
> at
> com.gemstone.gemfire.internal.cache.execute.PartitionedRegionFunctionResultSender.sendException(PartitionedRegionFun
> ctionResultSender.java:301)
> at
> com.gemstone.gemfire.cache.lucene.internal.distributed.LuceneFunction.execute(LuceneFunction.java:52)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-727) Move isHA, isHA, hasResult, optimizeForWrite from the Function interface to the Execution interface
[
https://issues.apache.org/jira/browse/GEODE-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith reassigned GEODE-727:
---
Assignee: (was: Dan Smith)
> Move isHA, isHA, hasResult, optimizeForWrite from the Function interface to
> the Execution interface
> ---
>
> Key: GEODE-727
> URL: https://issues.apache.org/jira/browse/GEODE-727
> Project: Geode
> Issue Type: Improvement
>Reporter: Dan Smith
>Priority: Major
>
> sHA, hasResult, and optimizeForWrite are methods on Function that the user
> can override. However, that makes it harder to write lambda expressions for
> functions, because if you want to set one of these parameters you can now
> longer use a lambda.
> Also the function service API provides a way to invoke functions using a
> string id. For example FunctionService.onServer().execute("MY_FUNCTION_ID").
> If we remove these extra methods from the Function interface, this code will
> no longer need to look up the Function on the client and the Function class
> will not have to exist on the client any more.
> We will add isHA(boolean), hasResult(Boolean) and optimizeForWrite(boolean)
> to the Execution interface. These methods will be deprecated on the function
> interface and be given default values. Unfortunately, if someone invokes a
> function on a client given the string id, we will still need to look up the
> function class for now in case they have specified these parameters on their
> function. But in another release we can remove the deprecated parameters and
> stop using them.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-726) Add a getLocalDataSet to RegionFunctionContext and deprecate PartitionRegionHelper.getLocalData(RegionFunctionContext)
[
https://issues.apache.org/jira/browse/GEODE-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith reassigned GEODE-726:
---
Assignee: (was: Dan Smith)
> Add a getLocalDataSet to RegionFunctionContext and deprecate
> PartitionRegionHelper.getLocalData(RegionFunctionContext)
> --
>
> Key: GEODE-726
> URL: https://issues.apache.org/jira/browse/GEODE-726
> Project: Geode
> Issue Type: Improvement
>Reporter: Dan Smith
>Priority: Major
>
> From
> https://cwiki.apache.org/confluence/display/GEODE/Function+Service+Usability+Improvments#FunctionServiceUsabilityImprovments-RegionFunctionContextshouldprovidethelocaldataset
> :
> If you want to operate on the local data set for a function, you have to do
> this
> {code}
> public void execute(FunctionContext context) {
>RegionFunctionContext ctx = (RegionFunctionContext) context;
>//This actually doesn't give you the local data set
>Region wholePartitionedRegion = ctx.getDataSet();
>
>//This does, using a static function call
>Region localData = PartitionRegionHelper.getLocalDataForContext(ctx);
>
>//This is a bad idea, because it may include some buckets that are also
> being processed on other nodes
>Region localDataDontDoThis =
> PartitionRegionHelper.getLocalData(ctx.getDataSet());
> {code}
>
> There are several problems with this approach.
> * It's not clear that ctx.getDataSet does not return the local data.
> * The local data set is not mockable for unit tests, because this static
> function call extracts it using internal APIs on concrete classes. This
> prevents this sort of function from being tested in a pure unit test.
> * The user has to know that PartitionRegionHelper exists; the API is not
> obvious
> * The various methods on PartitionRegionHelper are confusing, specifically
> it's unclear to a user why they should use getLocalDataForContext instead of
> getLocalData
>
> RegionFunctionContext should just provide a getLocalDataSet method. We should
> add this new method to the RegionFunctionContext interface. We should
> deprecate the PartitionRegionHelper.getLocalDataForContext.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6082) Add tests of Memory Overhead
[ https://issues.apache.org/jira/browse/GEODE-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith reassigned GEODE-6082: Assignee: (was: Dan Smith) > Add tests of Memory Overhead > > > Key: GEODE-6082 > URL: https://issues.apache.org/jira/browse/GEODE-6082 > Project: Geode > Issue Type: New Feature > Components: benchmarks >Reporter: Dan Smith >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5816) ClusterStartupRule fails to launch JMX manager (port already in use)
[
https://issues.apache.org/jira/browse/GEODE-5816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dan Smith resolved GEODE-5816.
--
Resolution: Duplicate
Fix Version/s: 1.9.0
The locatorProperties method I mentioned in my earlier comments still is making
it's own getRandomAvailableTCPPort, but Brian's fixes in GEODE-5674 should
prevent that port from conflicting with other ports picked by the
ClusterStartupRule, so this issue is fixed.
> ClusterStartupRule fails to launch JMX manager (port already in use)
>
>
> Key: GEODE-5816
> URL: https://issues.apache.org/jira/browse/GEODE-5816
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Bill Burcham
>Assignee: Dan Smith
>Priority: Major
> Labels: swat
> Fix For: 1.9.0
>
>
> We see these related failures on a couple tests in
> RegionMembershipMBeanOverHttpDUnitTest from our recent mass-test-run.
> From looking at the stack traces though, we surmise that the problem occurs
> in the ClusterStartupRule _before_ the actual tests run. Since it occurs
> before the tests run, we think the problem lies outside the
> RegionMembershipMBeanOverHttpDUnitTest class.
> {noformat}
> 4 failures (99.600% success
> rate)org.apache.geode.management.internal.cli.commands.RegionMembershipMBeanOverHttpDUnitTest
> | .testAddRmNewMemberWithReplicatedRegionsAndSubregions: 1 failures
> (99.900% success rate)
> | | Failed build 24 at
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/24
> | .testMultiplePartitionedRegions: 3 failures (99.700% success rate)
> | | Failed build 982 at
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/982
> | | Failed build 256 at
> https://concourse.apachegeode-ci.info/teams/main/pipelines/mass-test-run/jobs/DistributedTest/builds/256
> {noformat}
> Here's a stack trace:
> {noformat}
> java.lang.AssertionError: Suspicious strings were written to the log during
> this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 358
> [error 2018/10/01 06:28:30.869 UTC
> tid=0x20] Jmx manager could not be started because
> java.rmi.server.ExportException: Port already in use: 25305; nested exception
> is:
> java.net.BindException: Failed to create server socket on
> ffd50f3577c5/172.17.0.20[25305]
> org.apache.geode.management.ManagementException:
> java.rmi.server.ExportException: Port already in use: 25305; nested exception
> is:
> java.net.BindException: Failed to create server socket on
> ffd50f3577c5/172.17.0.20[25305]
> at
> org.apache.geode.management.internal.ManagementAgent.startAgent(ManagementAgent.java:162)
> at
> org.apache.geode.management.internal.SystemManagementService.startManager(SystemManagementService.java:435)
> at
> org.apache.geode.management.internal.beans.ManagementAdapter.handleCacheCreation(ManagementAdapter.java:173)
> at
> org.apache.geode.management.internal.beans.ManagementListener.handleEvent(ManagementListener.java:118)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.notifyResourceEventListeners(InternalDistributedSystem.java:2201)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.handleResourceEvent(InternalDistributedSystem.java:591)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1218)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreate(GemFireCacheImpl.java:793)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.create(GemFireCacheImpl.java:779)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:177)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:224)
> at
> org.apache.geode.distributed.internal.InternalLocator.startCache(InternalLocator.java:662)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:649)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:311)
> at org.apache.geode.distributed.Locator.startLocator(Locator.java:253)
> at
> org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:140)
> at
> org.apache.geode.test.junit.rules.LocatorStarterRule.startLocator(LocatorStarterRule.java:87)
> at
> org.apache.geode.test.junit.rules.LocatorStarterRule.before(LocatorStarterRule.java:68)
> at
>
[jira] [Commented] (GEODE-6279) CI: PR Test results URI is valid but unintentionally mangled. Many scripts reproduce effort.
[
https://issues.apache.org/jira/browse/GEODE-6279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744298#comment-16744298
]
ASF subversion and git services commented on GEODE-6279:
Commit 0d904c49f569877150d6deb90330981f66202c97 in geode's branch
refs/heads/GEODE-6279 from Patrick Rhomberg
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0d904c4 ]
GEODE-6279 Correct pull-request-id encoding in URL
* Extract common semver version parsing to shared_utilities.sh
* Fix use of pull-request resource to get PR number
* Cleanup pointlessly used buildid version file ; use modified input as obvious
output.
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
> CI: PR Test results URI is valid but unintentionally mangled. Many scripts
> reproduce effort.
> -
>
> Key: GEODE-6279
> URL: https://issues.apache.org/jira/browse/GEODE-6279
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> For instance, the test run
> [here|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-pr/jobs/UpgradeTestOpenJDK8/builds/704]
> contains the following output in the {{archive_results}} step:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-{"pr":"3032","commit":"a9a03f033e90b39aceab07b56919e6a4fef1e43d","committed":"2019-01-10T20:13:25Z"}/test-results/upgradeTest/1547153318/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> {noformat}
> This is a consequence of the diff-set for GEODE-6259 using the concourse
> version as the (Concourse) source of truth for versioning and expecting the
> version file to only contain the version string.
> Another underlying issue is that many of these scripts are (a) used in both
> the main pipeline as well as the PR pipeline and (b) nearly-but-imperfectly
> duplicate a great deal fo work between each script. These common tasks
> should be unified to a shared utilities that can be accessed by any of our
> scripts so that these pitfalls do not snare future developers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6212) Need to add unit test on checkEquals method in ValueComparisonHelper class
[ https://issues.apache.org/jira/browse/GEODE-6212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-6212: -- Labels: pull-request-available (was: ) > Need to add unit test on checkEquals method in ValueComparisonHelper class > -- > > Key: GEODE-6212 > URL: https://issues.apache.org/jira/browse/GEODE-6212 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > Labels: pull-request-available > > The method was moved from AbstractRegionEntry. Need to add unit test coverage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6212) Need to add unit test on checkEquals method in ValueComparisonHelper class
[ https://issues.apache.org/jira/browse/GEODE-6212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744297#comment-16744297 ] ASF subversion and git services commented on GEODE-6212: Commit 9c814d1bb138163ee393c83d189dd2b23c13aaae in geode's branch refs/heads/feature/GEODE-6212 from eshu [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9c814d1 ] GEODE-6212: Add unit test coverage for ValueComparisonHelper * fixed an error in the helper class when adding test coverage. > Need to add unit test on checkEquals method in ValueComparisonHelper class > -- > > Key: GEODE-6212 > URL: https://issues.apache.org/jira/browse/GEODE-6212 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Eric Shu >Assignee: Eric Shu >Priority: Major > > The method was moved from AbstractRegionEntry. Need to add unit test coverage. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-6279) CI: PR Test results URI is valid but unintentionally mangled. Many scripts reproduce effort.
[
https://issues.apache.org/jira/browse/GEODE-6279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744280#comment-16744280
]
ASF subversion and git services commented on GEODE-6279:
Commit d9945a13fff439e4e4c77b59472b2d3668b05424 in geode's branch
refs/heads/develop from Robert Houghton
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=d9945a1 ]
GEODE-6279 Correct pull-request-id encoding in URL (#3081)
* Extract common semver version parsing to shared_utilities.sh
* Fix use of pull-request resource to get PR number
* Cleanup pointlessly used buildid version file ; use modified input as obvious
output.
Co-authored-by: Patrick Rhomberg
Co-authored-by: Robert Houghton
> CI: PR Test results URI is valid but unintentionally mangled. Many scripts
> reproduce effort.
> -
>
> Key: GEODE-6279
> URL: https://issues.apache.org/jira/browse/GEODE-6279
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> For instance, the test run
> [here|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-pr/jobs/UpgradeTestOpenJDK8/builds/704]
> contains the following output in the {{archive_results}} step:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-{"pr":"3032","commit":"a9a03f033e90b39aceab07b56919e6a4fef1e43d","committed":"2019-01-10T20:13:25Z"}/test-results/upgradeTest/1547153318/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> {noformat}
> This is a consequence of the diff-set for GEODE-6259 using the concourse
> version as the (Concourse) source of truth for versioning and expecting the
> version file to only contain the version string.
> Another underlying issue is that many of these scripts are (a) used in both
> the main pipeline as well as the PR pipeline and (b) nearly-but-imperfectly
> duplicate a great deal fo work between each script. These common tasks
> should be unified to a shared utilities that can be accessed by any of our
> scripts so that these pitfalls do not snare future developers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6279) CI: PR Test results URI is valid but unintentionally mangled. Many scripts reproduce effort.
[
https://issues.apache.org/jira/browse/GEODE-6279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-6279:
--
Labels: pull-request-available (was: )
> CI: PR Test results URI is valid but unintentionally mangled. Many scripts
> reproduce effort.
> -
>
> Key: GEODE-6279
> URL: https://issues.apache.org/jira/browse/GEODE-6279
> Project: Geode
> Issue Type: Improvement
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
>
> For instance, the test run
> [here|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-pr/jobs/UpgradeTestOpenJDK8/builds/704]
> contains the following output in the {{archive_results}} step:
> {noformat}
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-= Test Results URI
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-pr/geode-pr-{"pr":"3032","commit":"a9a03f033e90b39aceab07b56919e6a4fef1e43d","committed":"2019-01-10T20:13:25Z"}/test-results/upgradeTest/1547153318/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> {noformat}
> This is a consequence of the diff-set for GEODE-6259 using the concourse
> version as the (Concourse) source of truth for versioning and expecting the
> version file to only contain the version string.
> Another underlying issue is that many of these scripts are (a) used in both
> the main pipeline as well as the PR pipeline and (b) nearly-but-imperfectly
> duplicate a great deal fo work between each script. These common tasks
> should be unified to a shared utilities that can be accessed by any of our
> scripts so that these pitfalls do not snare future developers.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (GEODE-5552) Flaky test ConnectCommandWithSSLTest > connectWithJmxSSL
[
https://issues.apache.org/jira/browse/GEODE-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McMahon updated GEODE-5552:
Comment: was deleted
(was: Failed in:
http://concourse.gemfire.pivotal.io/teams/main/pipelines/gemfire-9.6/jobs/DistributedTest/builds/40)
> Flaky test ConnectCommandWithSSLTest > connectWithJmxSSL
>
>
> Key: GEODE-5552
> URL: https://issues.apache.org/jira/browse/GEODE-5552
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.8.0
>Reporter: Jacob S. Barrett
>Assignee: Kenneth Howe
>Priority: Major
> Labels: flaky, swat
> Fix For: 1.8.0
>
>
> {noformat}
> > Task :geode-web:distributedTest
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest >
> connectWithJmxSSL FAILED
> java.lang.AssertionError:
> Expecting:
> <"_ __
>/ _/ __/ __/ // /
> / / __/ /___ /_ / _ /
> / /__/ / / _/ / // /
> /__/_/ /__/_//_/1.8.0-SNAPSHOT
>
> Monitor and Manage Apache Geode
> Connecting to Locator at [host=localhost, port=42647] ..
> Connection reset
> ">
> to contain:
> <"trying to connect a non-SSL-enabled client to an SSL-enabled locator">
> at
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithJmxSSL(ConnectCommandWithSSLTest.java:219)
> {noformat}
> Failing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/DistributedTest/builds/521
> Passing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/DistributedTest/builds/522
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5552) Flaky test ConnectCommandWithSSLTest > connectWithJmxSSL
[
https://issues.apache.org/jira/browse/GEODE-5552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe resolved GEODE-5552.
-
Resolution: Fixed
Fix Version/s: 1.8.0
This test was fixed on GEODE-3720 via commit
da5bd9c6d5d64ef63db610c176a9208bec66c82b
> Flaky test ConnectCommandWithSSLTest > connectWithJmxSSL
>
>
> Key: GEODE-5552
> URL: https://issues.apache.org/jira/browse/GEODE-5552
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.8.0
>Reporter: Jacob S. Barrett
>Assignee: Kenneth Howe
>Priority: Major
> Labels: flaky, swat
> Fix For: 1.8.0
>
>
> {noformat}
> > Task :geode-web:distributedTest
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest >
> connectWithJmxSSL FAILED
> java.lang.AssertionError:
> Expecting:
> <"_ __
>/ _/ __/ __/ // /
> / / __/ /___ /_ / _ /
> / /__/ / / _/ / // /
> /__/_/ /__/_//_/1.8.0-SNAPSHOT
>
> Monitor and Manage Apache Geode
> Connecting to Locator at [host=localhost, port=42647] ..
> Connection reset
> ">
> to contain:
> <"trying to connect a non-SSL-enabled client to an SSL-enabled locator">
> at
> org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithJmxSSL(ConnectCommandWithSSLTest.java:219)
> {noformat}
> Failing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/DistributedTest/builds/521
> Passing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/DistributedTest/builds/522
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6274) CreateRegionCommand.java:248 Produces a build warning
[
https://issues.apache.org/jira/browse/GEODE-6274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16744157#comment-16744157
]
ASF subversion and git services commented on GEODE-6274:
Commit 8cd574cd6b886b59200a68c2e109b1333523a124 in geode's branch
refs/heads/develop from Jens Deppe
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=8cd574c ]
GEODE-6274: Removes CreateRegionCommand build warning
Signed-off-by: Peter Tran
> CreateRegionCommand.java:248 Produces a build warning
> -
>
> Key: GEODE-6274
> URL: https://issues.apache.org/jira/browse/GEODE-6274
> Project: Geode
> Issue Type: Improvement
>Reporter: Peter Tran
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> When building geode, the following error occurs for the CreateRegionCommand
>
>
> /Users/pivotal/workspace/geode/geode-core/src/main/java/org/apache/geode/management/internal/cli/commands/CreateRegionCommand.java:248:
> warning: non-varargs call of varargs method with inexact argument type for
> last parameter;
> new String[] {prColocatedWith}));
> ^
> cast to Object for a varargs call
> cast to Object[] for a non-varargs call and to suppress this warning
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
