[jira] [Assigned] (GEODE-7123) Allow the creation of a cluster-configuration disk-store record without creating store directories and files
[
https://issues.apache.org/jira/browse/GEODE-7123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reassigned GEODE-7123:
---
Assignee: Kenneth Howe
> Allow the creation of a cluster-configuration disk-store record without
> creating store directories and files
>
>
> Key: GEODE-7123
> URL: https://issues.apache.org/jira/browse/GEODE-7123
> Project: Geode
> Issue Type: Improvement
> Components: management
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
>
> This enhancement provides support for configuring PDX persistence using
> non-DEFAULT disk-store.
> The recommendation is to use a user-specified disk-store for PDX persistence
> as per this excerpt from the Geode docs:
> {code:
> title=https://geode.apache.org/docs/guide/19/developing/data_serialization/persist_pdx_metadata_to_disk.html}
> If you are using PDX serialized objects as region entry keys and you are
> using persistent regions, then you must configure your PDX disk store to be a
> different one than the disk store used by the persistent regions.
> {code}
> PDX persistence can be configured using {{gfsh}}:
> {code}
> configure pdx --read-serialized=true --disk-store=
> {code}
> The previous should only be run on an otherwise non-configured cluster so
> that the PDX configuration will be adopted be servers as they join the
> cluster. However, to use a non default diskstore, the cluster currently must
> have at least one server member and the disk-store must already be created.
> *Proposed Enhancement*
> Add an option to the {{gfsh}} {{create disk-store}} command to only add the
> cluster-configuration record for the disk-store. Server members will then
> create the disk-store when they join.
> {code}
> gfsh>help create disk-store
> NAME
> create disk-store
> . . .
> stage-configuration
> Only create the cluster configuration element for the disk-store. The
> disk-store will be created on any future servers to join the cluster.
> Required: false
> Default (if the parameter is specified without value): true
> Default (if the parameter is not specified): false
> gfsh>create disk-store --name=PDXSTORE --dir=pdxstore --stage-configuration
> {code}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-7123) Allow the creation of a cluster-configuration disk-store record without creating store directories and files
[
https://issues.apache.org/jira/browse/GEODE-7123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe updated GEODE-7123:
Description:
This enhancement provides support for configuring PDX persistence using
non-DEFAULT disk-store.
The recommendation is to use a user-specified disk-store for PDX persistence as
per this excerpt from the Geode docs:
{code:
title=https://geode.apache.org/docs/guide/19/developing/data_serialization/persist_pdx_metadata_to_disk.html}
If you are using PDX serialized objects as region entry keys and you are using
persistent regions, then you must configure your PDX disk store to be a
different one than the disk store used by the persistent regions.
{code}
PDX persistence can be configured using {{gfsh}}:
{code}
configure pdx --read-serialized=true --disk-store=
{code}
The previous should only be run on an otherwise non-configured cluster so that
the PDX configuration will be adopted be servers as they join the cluster.
However, to use a non default diskstore, the cluster currently must have at
least one server member and the disk-store must already be created.
*Proposed Enhancement*
Add an option to the {{gfsh}} {{create disk-store}} command to only add the
cluster-configuration record for the disk-store. Server members will then
create the disk-store when they join.
{code}
gfsh>help create disk-store
NAME
create disk-store
. . .
stage-configuration
Only create the cluster configuration element for the disk-store. The
disk-store will be created on any future servers to join the cluster.
Required: false
Default (if the parameter is specified without value): true
Default (if the parameter is not specified): false
gfsh>create disk-store --name=PDXSTORE --dir=pdxstore --stage-configuration
{code}
was:
This enhancement provides support for configuring PDX persistence using
non-DEFAULT disk-store.
The recommendation is to use a user-specified disk-store for PDX persistence as
per this excerpt from the Geode docs:
{code:
title=https://geode.apache.org/docs/guide/19/developing/data_serialization/persist_pdx_metadata_to_disk.html}
If you are using PDX serialized objects as region entry keys and you are using
persistent regions, then you must configure your PDX disk store to be a
different one than the disk store used by the persistent regions.
{code}
PDX persistence can be configured using {{gfsh}}:
{code}
configure pdx --read-serialized=true --disk-store=
{code}
The previous should only be run on an otherwise non-configured cluster so that
the PDX configuration will be adopted be servers as they join the cluster.
However, to use a non default diskstore, the cluster currently must have at
least one server member and the disk-store must already be created.
*Proposed Enhancement*
Add an option to the {{gfsh}} {{create disk-store}} command to only add the
cluster-configuration record for the disk-store. Server members will then
create the disk-store when they join.
{code}
gfsh>help create disk-store
NAME
create disk-store
. . .
stage-configuration
Only create the cluster configuration element for the disk-store. The
disk-store will be created on any future servers to join the cluster.
Required: false
Default (if the parameter is specified without value): true
Default (if the parameter is not specified): false
gfsh>create disk-store --name=PDXSTORE --dir=pdxstore --stage-configuration
{code}
I will push a proof-of-concept branch to my geode fork
> Allow the creation of a cluster-configuration disk-store record without
> creating store directories and files
>
>
> Key: GEODE-7123
> URL: https://issues.apache.org/jira/browse/GEODE-7123
> Project: Geode
> Issue Type: Improvement
> Components: management
>Reporter: Kenneth Howe
>Priority: Major
>
> This enhancement provides support for configuring PDX persistence using
> non-DEFAULT disk-store.
> The recommendation is to use a user-specified disk-store for PDX persistence
> as per this excerpt from the Geode docs:
> {code:
> title=https://geode.apache.org/docs/guide/19/developing/data_serialization/persist_pdx_metadata_to_disk.html}
> If you are using PDX serialized objects as region entry keys and you are
> using persistent regions, then you must configure your PDX disk store to be a
> different one than the disk store used by the persistent regions.
> {code}
> PDX persistence can be configured using {{gfsh}}:
> {code}
> configure pdx --read-serialized=true --disk-store=
> {code}
> The previous should only be run on an otherwise non-configured cluster so
> that the PDX configuration will be adopted be servers as they join the
> cluster. However, to
[jira] [Commented] (GEODE-7123) Allow the creation of a cluster-configuration disk-store record without creating store directories and files
[
https://issues.apache.org/jira/browse/GEODE-7123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16916017#comment-16916017
]
Kenneth Howe commented on GEODE-7123:
-
Proof-of-concept for adding {{--stage-configuration}} option to {{create
disk-store}} command:
https://github.com/pdxrunner/geode/tree/feature/GEODE-7123-stage-disk-store-config
> Allow the creation of a cluster-configuration disk-store record without
> creating store directories and files
>
>
> Key: GEODE-7123
> URL: https://issues.apache.org/jira/browse/GEODE-7123
> Project: Geode
> Issue Type: Improvement
> Components: management
>Reporter: Kenneth Howe
>Priority: Major
>
> This enhancement provides support for configuring PDX persistence using
> non-DEFAULT disk-store.
> The recommendation is to use a user-specified disk-store for PDX persistence
> as per this excerpt from the Geode docs:
> {code:
> title=https://geode.apache.org/docs/guide/19/developing/data_serialization/persist_pdx_metadata_to_disk.html}
> If you are using PDX serialized objects as region entry keys and you are
> using persistent regions, then you must configure your PDX disk store to be a
> different one than the disk store used by the persistent regions.
> {code}
> PDX persistence can be configured using {{gfsh}}:
> {code}
> configure pdx --read-serialized=true --disk-store=
> {code}
> The previous should only be run on an otherwise non-configured cluster so
> that the PDX configuration will be adopted be servers as they join the
> cluster. However, to use a non default diskstore, the cluster currently must
> have at least one server member and the disk-store must already be created.
> *Proposed Enhancement*
> Add an option to the {{gfsh}} {{create disk-store}} command to only add the
> cluster-configuration record for the disk-store. Server members will then
> create the disk-store when they join.
> {code}
> gfsh>help create disk-store
> NAME
> create disk-store
> . . .
> stage-configuration
> Only create the cluster configuration element for the disk-store. The
> disk-store will be created on any future servers to join the cluster.
> Required: false
> Default (if the parameter is specified without value): true
> Default (if the parameter is not specified): false
> gfsh>create disk-store --name=PDXSTORE --dir=pdxstore --stage-configuration
> {code}
> I will push a proof-of-concept branch to my geode fork
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Created] (GEODE-7123) Allow the creation of a cluster-configuration disk-store record without creating store directories and files
Kenneth Howe created GEODE-7123:
---
Summary: Allow the creation of a cluster-configuration disk-store
record without creating store directories and files
Key: GEODE-7123
URL: https://issues.apache.org/jira/browse/GEODE-7123
Project: Geode
Issue Type: Improvement
Components: management
Reporter: Kenneth Howe
This enhancement provides support for configuring PDX persistence using
non-DEFAULT disk-store.
The recommendation is to use a user-specified disk-store for PDX persistence as
per this excerpt from the Geode docs:
{code:
title=https://geode.apache.org/docs/guide/19/developing/data_serialization/persist_pdx_metadata_to_disk.html}
If you are using PDX serialized objects as region entry keys and you are using
persistent regions, then you must configure your PDX disk store to be a
different one than the disk store used by the persistent regions.
{code}
PDX persistence can be configured using {{gfsh}}:
{code}
configure pdx --read-serialized=true --disk-store=
{code}
The previous should only be run on an otherwise non-configured cluster so that
the PDX configuration will be adopted be servers as they join the cluster.
However, to use a non default diskstore, the cluster currently must have at
least one server member and the disk-store must already be created.
*Proposed Enhancement*
Add an option to the {{gfsh}} {{create disk-store}} command to only add the
cluster-configuration record for the disk-store. Server members will then
create the disk-store when they join.
{code}
gfsh>help create disk-store
NAME
create disk-store
. . .
stage-configuration
Only create the cluster configuration element for the disk-store. The
disk-store will be created on any future servers to join the cluster.
Required: false
Default (if the parameter is specified without value): true
Default (if the parameter is not specified): false
gfsh>create disk-store --name=PDXSTORE --dir=pdxstore --stage-configuration
{code}
I will push a proof-of-concept branch to my geode fork
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Assigned] (GEODE-6499) PersistentColocatedPartitionedRegionDUnitTest: Timed out waiting 60000 milliseconds for AsyncInvocation to complete.
[
https://issues.apache.org/jira/browse/GEODE-6499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reassigned GEODE-6499:
---
Assignee: (was: Kenneth Howe)
> PersistentColocatedPartitionedRegionDUnitTest: Timed out waiting 6
> milliseconds for AsyncInvocation to complete.
>
>
> Key: GEODE-6499
> URL: https://issues.apache.org/jira/browse/GEODE-6499
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Mark Hanson
>Priority: Major
> Attachments: PersistentColocatedPartitionedRegionDUnitTest.tgz
>
>
> {noformat}
>
> Task :geode-core:distributedTest
>
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest
> > testHierarchyOfColocatedChildPRsMissingGrandchild FAILED
> java.util.concurrent.TimeoutException: Timed out waiting 6 milliseconds
> for AsyncInvocation to complete.
> at
> org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:462)
> at org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:412)
> at
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testHierarchyOfColocatedChildPRsMissingGrandchild(PersistentColocatedPartitionedRegionDUnitTest.java:979)
>
>
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest
> > testMultipleColocatedChildPRsMissingWithSequencedStart FAILED
> java.util.concurrent.TimeoutException: Timed out waiting 6 milliseconds
> for AsyncInvocation to complete.
> at
> org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:462)
> at org.apache.geode.test.dunit.AsyncInvocation.get(AsyncInvocation.java:412)
> at
> org.apache.geode.internal.cache.partitioned.PersistentColocatedPartitionedRegionDUnitTest.testMultipleColocatedChildPRsMissingWithSequencedStart(PersistentColocatedPartitionedRegionDUnitTest.java:865)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
[jira] [Updated] (GEODE-6740) TLS endpoint identification fails using hostnames
[
https://issues.apache.org/jira/browse/GEODE-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe updated GEODE-6740:
Labels: security (was: )
> TLS endpoint identification fails using hostnames
> -
>
> Key: GEODE-6740
> URL: https://issues.apache.org/jira/browse/GEODE-6740
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.8.0
>Reporter: Kenneth Howe
>Priority: Major
> Labels: security
>
> Tried to start a cluster with the following Geode security properties.
> {code}
> ssl-enabled-components=cluster,web,jmx,locator,server
> ssl-endpoint-identification-enabled=true
> {code}
> The certificate has the valid hostname wildcard as the SAN list.
> All the Geode config files and parameters use this hostname.
> {code}
> -Dgemfire.locators=3177423e-d7dd-4b27-932d-d33b4bdf5783.locator.jackson-services-subnet.service-instance-ec7f6a7b-eb04-45e7-9f1f-eaff60a5be25.bosh[55221],983d2e55-988e-437d-8b10-8b3dffc8cc82.locator.jackson-services-subnet.service-instance-ec7f6a7b-eb04-45e7-9f1f-eaff60a5be25.bosh[55221],8c222f26-22da-4e42-8d1e-e13a86808600.locator.jackson-services-subnet.service-instance-ec7f6a7b-eb04-45e7-9f1f-eaff60a5be25.bosh[55221]
> {code}
> {code}
> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number:
> 21:fc:3f:07:bc:47:5b:46:e3:07:da:c3:39:27:45:c4:83:67:39:4d
> Signature Algorithm: sha256WithRSAEncryption
> Issuer: CN=gemfire-ssl
> Validity
> Not Before: May 2 21:43:51 2019 GMT
> Not After : May 1 21:43:51 2020 GMT
> Subject: CN=gemfire-locator-ssl
> Subject Public Key Info:
> Public Key Algorithm: rsaEncryption
> Public-Key: (2048 bit)
> Exponent: 65537 (0x10001)
> X509v3 extensions:
> X509v3 Subject Key Identifier:
> B8:84:1E:B6:74:C3:B4:BC:61:88:93:52:27:71:E2:92:EA:72:85:C4
> X509v3 Subject Alternative Name:
>
> DNS:*.locator.jackson-services-subnet.service-instance-ec7f6a7b-eb04-45e7-9f1f-eaff60a5be25.bosh
> X509v3 Authority Key Identifier:
>
> keyid:41:33:74:8E:ED:6D:94:2E:B1:9C:01:68:9B:6F:3C:B7:AF:5A:ED:6C
> X509v3 Basic Constraints: critical
> CA:FALSE
> {code}
> This resulted in the error starting up the locators
> {code}
> [severe 2019/05/02 19:45:54.422 UTC
> locator-707059cc-9aad-47a9-8fa9-b045a14d5b80 tid=0x1] SSL Error in
> connecting to peer /10.0.8.9[55222].
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 10.0.8.9 found
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:1069)
> at
> org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:932)
> at
> org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:894)
> at
> org.apache.geode.internal.net.SocketCreator.connectForServer(SocketCreator.java:873)
> at org.apache.geode.internal.tcp.Connection.(Connection.java:1264)
> at
> org.apache.geode.internal.tcp.Connection.createSender(Connection.java:1066)
> at
> org.apache.geode.internal.tcp.ConnectionTable.handleNewPendingConnection(ConnectionTable.java:305)
> at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:413)
> at
> org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:598)
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:947)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:557)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:336)
> at
>
[jira] [Updated] (GEODE-6740) TLS endpoint identification fails using hostnames
[
https://issues.apache.org/jira/browse/GEODE-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe updated GEODE-6740:
Affects Version/s: 1.8.0
> TLS endpoint identification fails using hostnames
> -
>
> Key: GEODE-6740
> URL: https://issues.apache.org/jira/browse/GEODE-6740
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.8.0
>Reporter: Kenneth Howe
>Priority: Major
>
> Tried to start a cluster with the following Geode security properties.
> {code}
> ssl-enabled-components=cluster,web,jmx,locator,server
> ssl-endpoint-identification-enabled=true
> {code}
> The certificate has the valid hostname wildcard as the SAN list.
> All the Geode config files and parameters use this hostname.
> {code}
> -Dgemfire.locators=3177423e-d7dd-4b27-932d-d33b4bdf5783.locator.jackson-services-subnet.service-instance-ec7f6a7b-eb04-45e7-9f1f-eaff60a5be25.bosh[55221],983d2e55-988e-437d-8b10-8b3dffc8cc82.locator.jackson-services-subnet.service-instance-ec7f6a7b-eb04-45e7-9f1f-eaff60a5be25.bosh[55221],8c222f26-22da-4e42-8d1e-e13a86808600.locator.jackson-services-subnet.service-instance-ec7f6a7b-eb04-45e7-9f1f-eaff60a5be25.bosh[55221]
> {code}
> {code}
> Certificate:
> Data:
> Version: 3 (0x2)
> Serial Number:
> 21:fc:3f:07:bc:47:5b:46:e3:07:da:c3:39:27:45:c4:83:67:39:4d
> Signature Algorithm: sha256WithRSAEncryption
> Issuer: CN=gemfire-ssl
> Validity
> Not Before: May 2 21:43:51 2019 GMT
> Not After : May 1 21:43:51 2020 GMT
> Subject: CN=gemfire-locator-ssl
> Subject Public Key Info:
> Public Key Algorithm: rsaEncryption
> Public-Key: (2048 bit)
> Exponent: 65537 (0x10001)
> X509v3 extensions:
> X509v3 Subject Key Identifier:
> B8:84:1E:B6:74:C3:B4:BC:61:88:93:52:27:71:E2:92:EA:72:85:C4
> X509v3 Subject Alternative Name:
>
> DNS:*.locator.jackson-services-subnet.service-instance-ec7f6a7b-eb04-45e7-9f1f-eaff60a5be25.bosh
> X509v3 Authority Key Identifier:
>
> keyid:41:33:74:8E:ED:6D:94:2E:B1:9C:01:68:9B:6F:3C:B7:AF:5A:ED:6C
> X509v3 Basic Constraints: critical
> CA:FALSE
> {code}
> This resulted in the error starting up the locators
> {code}
> [severe 2019/05/02 19:45:54.422 UTC
> locator-707059cc-9aad-47a9-8fa9-b045a14d5b80 tid=0x1] SSL Error in
> connecting to peer /10.0.8.9[55222].
> javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
> No subject alternative names matching IP address 10.0.8.9 found
> at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
> at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
> at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
> at
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
> at
> sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
> at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
> at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
> at
> sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
> at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
> at
> org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:1069)
> at
> org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:932)
> at
> org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:894)
> at
> org.apache.geode.internal.net.SocketCreator.connectForServer(SocketCreator.java:873)
> at org.apache.geode.internal.tcp.Connection.(Connection.java:1264)
> at
> org.apache.geode.internal.tcp.Connection.createSender(Connection.java:1066)
> at
> org.apache.geode.internal.tcp.ConnectionTable.handleNewPendingConnection(ConnectionTable.java:305)
> at
> org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:413)
> at
> org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:598)
> at
> org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:947)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:557)
> at
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:336)
> at
>
[jira] [Created] (GEODE-6740) TLS endpoint identification fails using hostnames
Kenneth Howe created GEODE-6740:
---
Summary: TLS endpoint identification fails using hostnames
Key: GEODE-6740
URL: https://issues.apache.org/jira/browse/GEODE-6740
Project: Geode
Issue Type: Bug
Components: core
Reporter: Kenneth Howe
Tried to start a cluster with the following Geode security properties.
{code}
ssl-enabled-components=cluster,web,jmx,locator,server
ssl-endpoint-identification-enabled=true
{code}
The certificate has the valid hostname wildcard as the SAN list.
All the Geode config files and parameters use this hostname.
{code}
-Dgemfire.locators=3177423e-d7dd-4b27-932d-d33b4bdf5783.locator.jackson-services-subnet.service-instance-ec7f6a7b-eb04-45e7-9f1f-eaff60a5be25.bosh[55221],983d2e55-988e-437d-8b10-8b3dffc8cc82.locator.jackson-services-subnet.service-instance-ec7f6a7b-eb04-45e7-9f1f-eaff60a5be25.bosh[55221],8c222f26-22da-4e42-8d1e-e13a86808600.locator.jackson-services-subnet.service-instance-ec7f6a7b-eb04-45e7-9f1f-eaff60a5be25.bosh[55221]
{code}
{code}
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
21:fc:3f:07:bc:47:5b:46:e3:07:da:c3:39:27:45:c4:83:67:39:4d
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN=gemfire-ssl
Validity
Not Before: May 2 21:43:51 2019 GMT
Not After : May 1 21:43:51 2020 GMT
Subject: CN=gemfire-locator-ssl
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
B8:84:1E:B6:74:C3:B4:BC:61:88:93:52:27:71:E2:92:EA:72:85:C4
X509v3 Subject Alternative Name:
DNS:*.locator.jackson-services-subnet.service-instance-ec7f6a7b-eb04-45e7-9f1f-eaff60a5be25.bosh
X509v3 Authority Key Identifier:
keyid:41:33:74:8E:ED:6D:94:2E:B1:9C:01:68:9B:6F:3C:B7:AF:5A:ED:6C
X509v3 Basic Constraints: critical
CA:FALSE
{code}
This resulted in the error starting up the locators
{code}
[severe 2019/05/02 19:45:54.422 UTC
locator-707059cc-9aad-47a9-8fa9-b045a14d5b80 tid=0x1] SSL Error in
connecting to peer /10.0.8.9[55222].
javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException:
No subject alternative names matching IP address 10.0.8.9 found
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1946)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:316)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:310)
at
sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1639)
at
sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:223)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:1037)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:965)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1064)
at
sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1367)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1395)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1379)
at
org.apache.geode.internal.net.SocketCreator.configureClientSSLSocket(SocketCreator.java:1069)
at
org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:932)
at
org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:894)
at
org.apache.geode.internal.net.SocketCreator.connectForServer(SocketCreator.java:873)
at org.apache.geode.internal.tcp.Connection.(Connection.java:1264)
at
org.apache.geode.internal.tcp.Connection.createSender(Connection.java:1066)
at
org.apache.geode.internal.tcp.ConnectionTable.handleNewPendingConnection(ConnectionTable.java:305)
at
org.apache.geode.internal.tcp.ConnectionTable.getSharedConnection(ConnectionTable.java:413)
at
org.apache.geode.internal.tcp.ConnectionTable.get(ConnectionTable.java:598)
at
org.apache.geode.internal.tcp.TCPConduit.getConnection(TCPConduit.java:947)
at
org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:557)
at
org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:336)
at
org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:251)
at
org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:616)
at
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.directChannelSend(GMSMembershipManager.java:1686)
at
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.send(GMSMembershipManager.java:1864)
at
[jira] [Updated] (GEODE-6723) gfsh backup disk-store has misleading error message when target dir is not writeable
[
https://issues.apache.org/jira/browse/GEODE-6723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe updated GEODE-6723:
Description:
The {{backup disk-store --dir=/tmp/backup}} failed with the a message
indicating that disk stores were offline when they were online:
{code}
Cluster-5 gfsh>backup disk-store --dir=/tmp/backup
The following disk stores were backed up successfully
Member | UUID
| Directory | Host
|
| - |
-
cacheserver-8f44e736-5283-4ddf-93a5-d16356117d02 |
037db448-a8db-458c-b976-90f60fc3e439 | /var/vcap/store.. |
8f44e736-5283-4ddf-93a5..
|
ea332b03-f96e-4a03-b0a6-984b7637b558 | /var/vcap/store.. |
8f44e736-5283-4ddf-93a5..
cacheserver-8dd03c09-cf22-4b6c-bf2c-73a84ae25d66 |
8a203bb1-23ae-49cb-8c92-22ff98a316e5 | /var/vcap/store.. |
8dd03c09-cf22-4b6c-bf2c..
|
51310d54-8545-4f94-b976-feb333955f24 | /var/vcap/store.. |
8dd03c09-cf22-4b6c-bf2c..
cacheserver-efc97da3-6863-440e-bd43-dd4c6140a079 |
5207eed0-5aab-47c9-acfe-0b48d0462d8d | /var/vcap/store.. |
efc97da3-6863-440e-bd43..
|
71d01e58-2bf7-45cc-a64e-96ef0d2fc7f1 | /var/vcap/store.. |
efc97da3-6863-440e-bd43..
locator-72ef23fb-9804-4c80-8470-41628d7dcff5 |
745f3572-51f3-417d-b8c9-0f103def8da7 | /var/vcap/store.. |
72ef23fb-9804-4c80-8470..
locator-cf097956-a79a-402c-8cf6-b1d170a2fac3 |
9fd5bc17-5ab7-41cb-af52-242d7dc8c6c8 | /var/vcap/store.. |
cf097956-a79a-402c-8cf6..
locator-11620bd9-3dd9-48a4-a456-a987bb1cb557 |
54756556-4565-4ae3-bcf3-839a47621a82 | /var/vcap/store.. |
11620bd9-3dd9-48a4-a456..
The backup may be incomplete. The following disk stores are not online
UUID | Host
| Directory
|
-- |
8040125f-2e81-4e1c-8645-dfb8e6f40c62 |
dcf2c449-4169-4d42-a112-dce23e13d608.server.campbell.. |
/var/vcap/store/gemfire-server/diskstore
9d44d38b-c152-4ae2-9076-040578aaffeb |
dcf2c449-4169-4d42-a112-dce23e13d608.server.campbell.. |
/var/vcap/store/gemfire-server/.
{code}
{{show missing-disk-stores}} did not show any errors and all operations using
the disk-stores were successful.
After logging in to the server it was found that the {{backup disk-stores}}
target directory was not writeable by the process writing the backup files.
A more descriptive message from {{gfsh}} is needed.
was:
The {{backup disk-store --dir=/tmp/backup}} failed with the message:
{code}
Cluster-5 gfsh>backup disk-store --dir=/tmp/backup
The following disk stores were backed up successfully
Member | UUID
| Directory | Host
|
| - |
-
cacheserver-8f44e736-5283-4ddf-93a5-d16356117d02 |
037db448-a8db-458c-b976-90f60fc3e439 | /var/vcap/store.. |
8f44e736-5283-4ddf-93a5..
|
ea332b03-f96e-4a03-b0a6-984b7637b558 | /var/vcap/store.. |
8f44e736-5283-4ddf-93a5..
cacheserver-8dd03c09-cf22-4b6c-bf2c-73a84ae25d66 |
8a203bb1-23ae-49cb-8c92-22ff98a316e5 | /var/vcap/store.. |
8dd03c09-cf22-4b6c-bf2c..
|
51310d54-8545-4f94-b976-feb333955f24 | /var/vcap/store.. |
8dd03c09-cf22-4b6c-bf2c..
cacheserver-efc97da3-6863-440e-bd43-dd4c6140a079 |
5207eed0-5aab-47c9-acfe-0b48d0462d8d | /var/vcap/store.. |
efc97da3-6863-440e-bd43..
|
71d01e58-2bf7-45cc-a64e-96ef0d2fc7f1 | /var/vcap/store.. |
efc97da3-6863-440e-bd43..
locator-72ef23fb-9804-4c80-8470-41628d7dcff5 |
745f3572-51f3-417d-b8c9-0f103def8da7 | /var/vcap/store.. |
72ef23fb-9804-4c80-8470..
locator-cf097956-a79a-402c-8cf6-b1d170a2fac3 |
9fd5bc17-5ab7-41cb-af52-242d7dc8c6c8 | /var/vcap/store.. |
cf097956-a79a-402c-8cf6..
locator-11620bd9-3dd9-48a4-a456-a987bb1cb557 |
54756556-4565-4ae3-bcf3-839a47621a82 | /var/vcap/store.. |
11620bd9-3dd9-48a4-a456..
The backup may be incomplete. The following disk stores are not online
UUID | Host
| Directory
|
-- |
8040125f-2e81-4e1c-8645-dfb8e6f40c62 |
dcf2c449-4169-4d42-a112-dce23e13d608.server.campbell.. |
[jira] [Updated] (GEODE-6723) gfsh backup disk-store has misleading error message when target dir is not writeable
[
https://issues.apache.org/jira/browse/GEODE-6723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe updated GEODE-6723:
Affects Version/s: 1.8.0
> gfsh backup disk-store has misleading error message when target dir is not
> writeable
>
>
> Key: GEODE-6723
> URL: https://issues.apache.org/jira/browse/GEODE-6723
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.8.0
>Reporter: Kenneth Howe
>Priority: Major
>
> The {{backup disk-store --dir=/tmp/backup}} failed with the message:
> {code}
> Cluster-5 gfsh>backup disk-store --dir=/tmp/backup
> The following disk stores were backed up successfully
> Member | UUID
> | Directory | Host
> |
> | - |
> -
> cacheserver-8f44e736-5283-4ddf-93a5-d16356117d02 |
> 037db448-a8db-458c-b976-90f60fc3e439 | /var/vcap/store.. |
> 8f44e736-5283-4ddf-93a5..
> |
> ea332b03-f96e-4a03-b0a6-984b7637b558 | /var/vcap/store.. |
> 8f44e736-5283-4ddf-93a5..
> cacheserver-8dd03c09-cf22-4b6c-bf2c-73a84ae25d66 |
> 8a203bb1-23ae-49cb-8c92-22ff98a316e5 | /var/vcap/store.. |
> 8dd03c09-cf22-4b6c-bf2c..
> |
> 51310d54-8545-4f94-b976-feb333955f24 | /var/vcap/store.. |
> 8dd03c09-cf22-4b6c-bf2c..
> cacheserver-efc97da3-6863-440e-bd43-dd4c6140a079 |
> 5207eed0-5aab-47c9-acfe-0b48d0462d8d | /var/vcap/store.. |
> efc97da3-6863-440e-bd43..
> |
> 71d01e58-2bf7-45cc-a64e-96ef0d2fc7f1 | /var/vcap/store.. |
> efc97da3-6863-440e-bd43..
> locator-72ef23fb-9804-4c80-8470-41628d7dcff5 |
> 745f3572-51f3-417d-b8c9-0f103def8da7 | /var/vcap/store.. |
> 72ef23fb-9804-4c80-8470..
> locator-cf097956-a79a-402c-8cf6-b1d170a2fac3 |
> 9fd5bc17-5ab7-41cb-af52-242d7dc8c6c8 | /var/vcap/store.. |
> cf097956-a79a-402c-8cf6..
> locator-11620bd9-3dd9-48a4-a456-a987bb1cb557 |
> 54756556-4565-4ae3-bcf3-839a47621a82 | /var/vcap/store.. |
> 11620bd9-3dd9-48a4-a456..
> The backup may be incomplete. The following disk stores are not online
> UUID | Host
> | Directory
> |
> -- |
>
> 8040125f-2e81-4e1c-8645-dfb8e6f40c62 |
> dcf2c449-4169-4d42-a112-dce23e13d608.server.campbell.. |
> /var/vcap/store/gemfire-server/diskstore
> 9d44d38b-c152-4ae2-9076-040578aaffeb |
> dcf2c449-4169-4d42-a112-dce23e13d608.server.campbell.. |
> /var/vcap/store/gemfire-server/.
> {code}
> {{show missing-disk-stores}} did not show any errors and all operations using
> the disk-stores were successful.
> After logging in to the server it was found that the {{backup disk-stores}}
> target directory was not writeable by the process writing the backup files.
> A more descriptive message from {{gfsh}} is needed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6723) gfsh backup disk-store has misleading error message when target dir is not writeable
Kenneth Howe created GEODE-6723:
---
Summary: gfsh backup disk-store has misleading error message when
target dir is not writeable
Key: GEODE-6723
URL: https://issues.apache.org/jira/browse/GEODE-6723
Project: Geode
Issue Type: Bug
Components: gfsh
Reporter: Kenneth Howe
The {{backup disk-store --dir=/tmp/backup}} failed with the message:
{code}
Cluster-5 gfsh>backup disk-store --dir=/tmp/backup
The following disk stores were backed up successfully
Member | UUID
| Directory | Host
|
| - |
-
cacheserver-8f44e736-5283-4ddf-93a5-d16356117d02 |
037db448-a8db-458c-b976-90f60fc3e439 | /var/vcap/store.. |
8f44e736-5283-4ddf-93a5..
|
ea332b03-f96e-4a03-b0a6-984b7637b558 | /var/vcap/store.. |
8f44e736-5283-4ddf-93a5..
cacheserver-8dd03c09-cf22-4b6c-bf2c-73a84ae25d66 |
8a203bb1-23ae-49cb-8c92-22ff98a316e5 | /var/vcap/store.. |
8dd03c09-cf22-4b6c-bf2c..
|
51310d54-8545-4f94-b976-feb333955f24 | /var/vcap/store.. |
8dd03c09-cf22-4b6c-bf2c..
cacheserver-efc97da3-6863-440e-bd43-dd4c6140a079 |
5207eed0-5aab-47c9-acfe-0b48d0462d8d | /var/vcap/store.. |
efc97da3-6863-440e-bd43..
|
71d01e58-2bf7-45cc-a64e-96ef0d2fc7f1 | /var/vcap/store.. |
efc97da3-6863-440e-bd43..
locator-72ef23fb-9804-4c80-8470-41628d7dcff5 |
745f3572-51f3-417d-b8c9-0f103def8da7 | /var/vcap/store.. |
72ef23fb-9804-4c80-8470..
locator-cf097956-a79a-402c-8cf6-b1d170a2fac3 |
9fd5bc17-5ab7-41cb-af52-242d7dc8c6c8 | /var/vcap/store.. |
cf097956-a79a-402c-8cf6..
locator-11620bd9-3dd9-48a4-a456-a987bb1cb557 |
54756556-4565-4ae3-bcf3-839a47621a82 | /var/vcap/store.. |
11620bd9-3dd9-48a4-a456..
The backup may be incomplete. The following disk stores are not online
UUID | Host
| Directory
|
-- |
8040125f-2e81-4e1c-8645-dfb8e6f40c62 |
dcf2c449-4169-4d42-a112-dce23e13d608.server.campbell.. |
/var/vcap/store/gemfire-server/diskstore
9d44d38b-c152-4ae2-9076-040578aaffeb |
dcf2c449-4169-4d42-a112-dce23e13d608.server.campbell.. |
/var/vcap/store/gemfire-server/.
{code}
{{show missing-disk-stores}} did not show any errors and all operations using
the disk-stores were successful.
After logging in to the server it was found that the {{backup disk-stores}}
target directory was not writeable by the process writing the backup files.
A more descriptive message from {{gfsh}} is needed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-6666) SocketTiemoutException in TcpServer on openssl connection
[
https://issues.apache.org/jira/browse/GEODE-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe resolved GEODE-.
-
Resolution: Fixed
Fix Version/s: 1.10.0
> SocketTiemoutException in TcpServer on openssl connection
> -
>
> Key: GEODE-
> URL: https://issues.apache.org/jira/browse/GEODE-
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.8.0
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
> Fix For: 1.10.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The locator log contains the following stack trace when {{openssl s_client
> -quiet -connect localhost:}} is executed from a shell. Repeated
> {{openssl}} connections, such as when monitoring the locator health in a
> watchdog script, results in a lot of data in the logs, that is not indicative
> of a real problem.
> {code:java}
> [info 2019/04/17 15:34:48.198 UTC
> locator-9fa6036e-923c-4268-ad03-0d7183b0721f
> tid=0x1a19] Exception in processing request from 127.0.0.1
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
> at java.net.SocketInputStream.read(SocketInputStream.java:171)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
> at sun.security.ssl.InputRecord.read(InputRecord.java:503)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:975)
> at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:933)
> at sun.security.ssl.AppInputStream.read(AppInputStream.java:105)
> at sun.security.ssl.AppInputStream.read(AppInputStream.java:71)
> at java.io.DataInputStream.readUnsignedByte(DataInputStream.java:288)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:357)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6666) SocketTiemoutException in TcpServer on openssl connection
[
https://issues.apache.org/jira/browse/GEODE-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reassigned GEODE-:
---
Assignee: Kenneth Howe
> SocketTiemoutException in TcpServer on openssl connection
> -
>
> Key: GEODE-
> URL: https://issues.apache.org/jira/browse/GEODE-
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.8.0
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
>
> The locator log contains the following stack trace when {{openssl s_client
> -quiet -connect localhost:}} is executed from a shell. Repeated
> {{openssl}} connections, such as when monitoring the locator health in a
> watchdog script, results in a lot of data in the logs, that is not indicative
> of a real problem.
> {code:java}
> [info 2019/04/17 15:34:48.198 UTC
> locator-9fa6036e-923c-4268-ad03-0d7183b0721f
> tid=0x1a19] Exception in processing request from 127.0.0.1
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
> at java.net.SocketInputStream.read(SocketInputStream.java:171)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
> at sun.security.ssl.InputRecord.read(InputRecord.java:503)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:975)
> at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:933)
> at sun.security.ssl.AppInputStream.read(AppInputStream.java:105)
> at sun.security.ssl.AppInputStream.read(AppInputStream.java:71)
> at java.io.DataInputStream.readUnsignedByte(DataInputStream.java:288)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:357)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6666) SocketTiemoutException in TcpServer on openssl connection
[
https://issues.apache.org/jira/browse/GEODE-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe updated GEODE-:
Affects Version/s: 1.8.0
> SocketTiemoutException in TcpServer on openssl connection
> -
>
> Key: GEODE-
> URL: https://issues.apache.org/jira/browse/GEODE-
> Project: Geode
> Issue Type: Bug
> Components: core
>Affects Versions: 1.8.0
>Reporter: Kenneth Howe
>Priority: Major
>
> The locator log contains the following stack trace when {{openssl s_client
> -quiet -connect localhost:}} is executed from a shell. Repeated
> {{openssl}} connections, such as when monitoring the locator health in a
> watchdog script, results in a lot of data in the logs, that is not indicative
> of a real problem.
> {code:java}
> [info 2019/04/17 15:34:48.198 UTC
> locator-9fa6036e-923c-4268-ad03-0d7183b0721f
> tid=0x1a19] Exception in processing request from 127.0.0.1
> java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
> at java.net.SocketInputStream.read(SocketInputStream.java:171)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
> at sun.security.ssl.InputRecord.read(InputRecord.java:503)
> at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:975)
> at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:933)
> at sun.security.ssl.AppInputStream.read(AppInputStream.java:105)
> at sun.security.ssl.AppInputStream.read(AppInputStream.java:71)
> at java.io.DataInputStream.readUnsignedByte(DataInputStream.java:288)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:357)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6666) SocketTiemoutException in TcpServer on openssl connection
Kenneth Howe created GEODE-:
---
Summary: SocketTiemoutException in TcpServer on openssl connection
Key: GEODE-
URL: https://issues.apache.org/jira/browse/GEODE-
Project: Geode
Issue Type: Bug
Components: core
Reporter: Kenneth Howe
The locator log contains the following stack trace when {{openssl s_client
-quiet -connect localhost:}} is executed from a shell. Repeated
{{openssl}} connections, such as when monitoring the locator health in a
watchdog script, results in a lot of data in the logs, that is not indicative
of a real problem.
{code:java}
[info 2019/04/17 15:34:48.198 UTC locator-9fa6036e-923c-4268-ad03-0d7183b0721f
tid=0x1a19] Exception in processing request from
127.0.0.1
java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:465)
at sun.security.ssl.InputRecord.read(InputRecord.java:503)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:975)
at sun.security.ssl.SSLSocketImpl.readDataRecord(SSLSocketImpl.java:933)
at sun.security.ssl.AppInputStream.read(AppInputStream.java:105)
at sun.security.ssl.AppInputStream.read(AppInputStream.java:71)
at java.io.DataInputStream.readUnsignedByte(DataInputStream.java:288)
at
org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:357)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6370) JDK8/11: GfshConsoleModeUnitTest > consoleModeShouldRedirectOnlyJDKLoggers failed
[ https://issues.apache.org/jira/browse/GEODE-6370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenneth Howe reassigned GEODE-6370: --- Assignee: Jens Deppe > JDK8/11: GfshConsoleModeUnitTest > consoleModeShouldRedirectOnlyJDKLoggers > failed > - > > Key: GEODE-6370 > URL: https://issues.apache.org/jira/browse/GEODE-6370 > Project: Geode > Issue Type: Bug > Components: tests >Reporter: Mark Hanson >Assignee: Jens Deppe >Priority: Major > Labels: pull-request-available > Fix For: 1.9.0 > > Attachments: unittestfiles-OpenJDK11-1.9.0-SNAPSHOT.0416.tgz, > unittestfiles-OpenJDK8-1.9.0-SNAPSHOT.0420.tgz > > Time Spent: 0.5h > Remaining Estimate: 0h > > Failure in builds: > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UnitTestOpenJDK11/builds/372] > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UnitTestOpenJDK8/builds/375] > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UnitTestOpenJDK11/builds/372] > > java.lang.AssertionError: Expecting: > <"org.apache.geode.management.internal.cli.LogWrapper"> not to end with: > <"LogWrapper"> at > org.apache.geode.management.internal.cli.shell.GfshConsoleModeUnitTest.consoleModeShouldRedirectOnlyJDKLoggers(GfshConsoleModeUnitTest.java:54) > at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at > jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:566) at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) at > org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) at > org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) at > org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) at > org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) at > org.junit.runners.ParentRunner.run(ParentRunner.java:363) at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38) > at > org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java: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] [Assigned] (GEODE-6343) ImportClusterConfigTest.importWouldNotShutDownServer fails with org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
[
https://issues.apache.org/jira/browse/GEODE-6343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reassigned GEODE-6343:
---
Assignee: Kenneth Howe
> ImportClusterConfigTest.importWouldNotShutDownServer fails with
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
> -
>
> Key: GEODE-6343
> URL: https://issues.apache.org/jira/browse/GEODE-6343
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Affects Versions: 1.9.0
>Reporter: Kirk Lund
>Assignee: Kenneth Howe
>Priority: Major
>
> ImportClusterConfigTest.importWouldNotShutDownServer seems to be a flaky test.
> [Precheckin that hit this
> failure|https://concourse.apachegeode-ci.info/builds/34064]
> Failure stack:
> {noformat}
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshExecution.awaitTermination(GfshExecution.java:125)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:125)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:133)
> at
> org.apache.geode.management.internal.cli.commands.ImportClusterConfigTest.importWouldNotShutDownServer(ImportClusterConfigTest.java:41)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
> at
> org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java: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
>
[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] [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] [Resolved] (GEODE-6219) NetstatDUnitTest is not not detecting failures in executing OS netstat command
[
https://issues.apache.org/jira/browse/GEODE-6219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe resolved GEODE-6219.
-
Resolution: Fixed
Fix Version/s: 1.9.0
> NetstatDUnitTest is not not detecting failures in executing OS netstat command
> --
>
> Key: GEODE-6219
> URL: https://issues.apache.org/jira/browse/GEODE-6219
> Project: Geode
> Issue Type: Bug
> Components: ci, gfsh, tests
>Affects Versions: 1.7.0
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.9.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> The tests in {{NetstatDUnitTest}} are all passing in CI. However, the logs
> show that the OS command that is run on the servers in the cluster is failing:
> {code}
> Command result for --file=/tmp/junit5019199898297364101/junit8715261921376128635/command.log.txt>:
>
> Saved netstat output in the file
> /tmp/junit5019199898297364101/junit8715261921376128635/command.log.txt.
> Command result for :
> ##
> Host: 1dcb8055baac
> OS: Linux 4.9.0-8-amd64 amd64
> Member(s):
> server-1, locator-0, server-2
> ##
> Could not execute "netstat". Reason: Cannot run program "netstat": error=2,
> No such file or directory
> {code}
> That {{netstat}} is missing from the CI test workers is being addressed in
> PR#3014.
> The {{netstat}} tests need to verify the the OS commands run, in addition to
> verifying that the gfsh command tried to run on the expected servers.
> Suggest adding a check such as:
> {code}
> @@ -168,20 +187,24 @@ public class NetstatDUnitTest {
>@Test
>public void testConnectToLocatorWithLargeCommandResponse() throws
> Exception {
> gfsh.connect(server0.getEmbeddedLocatorPort(),
> GfshCommandRule.PortType.locator);
> -gfsh.executeAndAssertThat(netStatLsofCommand).statusIsSuccess();
> +gfsh.executeAndAssertThat(netStatLsofCommand).statusIsSuccess()
> +.doesNotContainOutput("Could not execute");
>}
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6228) LSOF output causes out of memory exceptions in tests
[
https://issues.apache.org/jira/browse/GEODE-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe updated GEODE-6228:
Description:
Gfsh tests of {{netstat --with-lsof}} create a large String object that
contains the complete output from {{lsof}}. On smaller JVM's that are typical
of those used in CI test environment, the large object causes
OutOfMemoryExceptions when preparing the string for streaming from the server
to the locator.
This is a long standing problem that has existed from the beginning of the
project.
We need to have a solution for streaming large Strings between members in the
cluster.
Following is a typical stack trace from a test failure.
{code}
org.apache.geode.management.internal.cli.NetstatDUnitTest >
testOutputToConsoleWithLsofForOneMember FAILED
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:3332)
at
java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
at
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:649)
at java.lang.StringBuilder.append(StringBuilder.java:202)
at org.json.JSONStringer.string(JSONStringer.java:369)
at org.json.JSONStringer.value(JSONStringer.java:262)
at org.json.JSONArray.writeTo(JSONArray.java:732)
at org.json.JSONStringer.value(JSONStringer.java:231)
at org.json.JSONObject.writeTo(JSONObject.java:882)
at org.json.JSONStringer.value(JSONStringer.java:235)
at org.json.JSONObject.writeTo(JSONObject.java:882)
at org.json.JSONObject.toString(JSONObject.java:849)
at
org.apache.geode.management.internal.cli.json.GfJsonObject.toString(GfJsonObject.java:292)
at java.lang.String.valueOf(String.java:2994)
at java.lang.StringBuilder.append(StringBuilder.java:131)
at
org.apache.geode.management.internal.cli.result.LegacyCommandResult.toString(LegacyCommandResult.java:501)
at
org.apache.geode.management.internal.cli.NetstatDUnitTest.testOutputToConsoleWithLsofForOneMember(NetstatDUnitTest.java:111)
{code}
was:
Gfsh tests of {{netstat --with-lsof}} create a large String object that
contains the complete output from {{lsof}}. On smaller JVM's that are typical
of those used in CI test environment, the large object causes
OutOfMemoryExceptions when preparing the string for streaming from the server
to the locator.
We need to have a solution for streaming large Strings between members in the
cluster.
Following is a typical stack trace from a test failure.
{code}
org.apache.geode.management.internal.cli.NetstatDUnitTest >
testOutputToConsoleWithLsofForOneMember FAILED
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:3332)
at
java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
at
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:649)
at java.lang.StringBuilder.append(StringBuilder.java:202)
at org.json.JSONStringer.string(JSONStringer.java:369)
at org.json.JSONStringer.value(JSONStringer.java:262)
at org.json.JSONArray.writeTo(JSONArray.java:732)
at org.json.JSONStringer.value(JSONStringer.java:231)
at org.json.JSONObject.writeTo(JSONObject.java:882)
at org.json.JSONStringer.value(JSONStringer.java:235)
at org.json.JSONObject.writeTo(JSONObject.java:882)
at org.json.JSONObject.toString(JSONObject.java:849)
at
org.apache.geode.management.internal.cli.json.GfJsonObject.toString(GfJsonObject.java:292)
at java.lang.String.valueOf(String.java:2994)
at java.lang.StringBuilder.append(StringBuilder.java:131)
at
org.apache.geode.management.internal.cli.result.LegacyCommandResult.toString(LegacyCommandResult.java:501)
at
org.apache.geode.management.internal.cli.NetstatDUnitTest.testOutputToConsoleWithLsofForOneMember(NetstatDUnitTest.java:111)
{code}
> LSOF output causes out of memory exceptions in tests
>
>
> Key: GEODE-6228
> URL: https://issues.apache.org/jira/browse/GEODE-6228
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.1.0
>Reporter: Kenneth Howe
>Priority: Major
>
> Gfsh tests of {{netstat --with-lsof}} create a large String object that
> contains the complete output from {{lsof}}. On smaller JVM's that are typical
> of those used in CI
[jira] [Updated] (GEODE-6228) LSOF output causes out of memory exceptions in tests
[
https://issues.apache.org/jira/browse/GEODE-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe updated GEODE-6228:
Affects Version/s: 1.1.0
> LSOF output causes out of memory exceptions in tests
>
>
> Key: GEODE-6228
> URL: https://issues.apache.org/jira/browse/GEODE-6228
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.1.0
>Reporter: Kenneth Howe
>Priority: Major
>
> Gfsh tests of {{netstat --with-lsof}} create a large String object that
> contains the complete output from {{lsof}}. On smaller JVM's that are typical
> of those used in CI test environment, the large object causes
> OutOfMemoryExceptions when preparing the string for streaming from the server
> to the locator.
> We need to have a solution for streaming large Strings between members in the
> cluster.
> Following is a typical stack trace from a test failure.
> {code}
> org.apache.geode.management.internal.cli.NetstatDUnitTest >
> testOutputToConsoleWithLsofForOneMember FAILED
>
> java.lang.OutOfMemoryError: Java heap space
>
> at java.util.Arrays.copyOf(Arrays.java:3332)
>
> at
> java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
>
> at
> java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:649)
>
> at java.lang.StringBuilder.append(StringBuilder.java:202)
>
> at org.json.JSONStringer.string(JSONStringer.java:369)
>
> at org.json.JSONStringer.value(JSONStringer.java:262)
>
> at org.json.JSONArray.writeTo(JSONArray.java:732)
>
> at org.json.JSONStringer.value(JSONStringer.java:231)
>
> at org.json.JSONObject.writeTo(JSONObject.java:882)
>
> at org.json.JSONStringer.value(JSONStringer.java:235)
>
> at org.json.JSONObject.writeTo(JSONObject.java:882)
>
> at org.json.JSONObject.toString(JSONObject.java:849)
>
> at
> org.apache.geode.management.internal.cli.json.GfJsonObject.toString(GfJsonObject.java:292)
>
> at java.lang.String.valueOf(String.java:2994)
>
> at java.lang.StringBuilder.append(StringBuilder.java:131)
>
> at
> org.apache.geode.management.internal.cli.result.LegacyCommandResult.toString(LegacyCommandResult.java:501)
>
> at
> org.apache.geode.management.internal.cli.NetstatDUnitTest.testOutputToConsoleWithLsofForOneMember(NetstatDUnitTest.java:111)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6228) LSOF output causes out of memory exceptions in tests
Kenneth Howe created GEODE-6228:
---
Summary: LSOF output causes out of memory exceptions in tests
Key: GEODE-6228
URL: https://issues.apache.org/jira/browse/GEODE-6228
Project: Geode
Issue Type: Bug
Components: gfsh
Reporter: Kenneth Howe
Gfsh tests of {{netstat --with-lsof}} create a large String object that
contains the complete output from {{lsof}}. On smaller JVM's that are typical
of those used in CI test environment, the large object causes
OutOfMemoryExceptions when preparing the string for streaming from the server
to the locator.
We need to have a solution for streaming large Strings between members in the
cluster.
Following is a typical stack trace from a test failure.
{code}
org.apache.geode.management.internal.cli.NetstatDUnitTest >
testOutputToConsoleWithLsofForOneMember FAILED
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Arrays.java:3332)
at
java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
at
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:649)
at java.lang.StringBuilder.append(StringBuilder.java:202)
at org.json.JSONStringer.string(JSONStringer.java:369)
at org.json.JSONStringer.value(JSONStringer.java:262)
at org.json.JSONArray.writeTo(JSONArray.java:732)
at org.json.JSONStringer.value(JSONStringer.java:231)
at org.json.JSONObject.writeTo(JSONObject.java:882)
at org.json.JSONStringer.value(JSONStringer.java:235)
at org.json.JSONObject.writeTo(JSONObject.java:882)
at org.json.JSONObject.toString(JSONObject.java:849)
at
org.apache.geode.management.internal.cli.json.GfJsonObject.toString(GfJsonObject.java:292)
at java.lang.String.valueOf(String.java:2994)
at java.lang.StringBuilder.append(StringBuilder.java:131)
at
org.apache.geode.management.internal.cli.result.LegacyCommandResult.toString(LegacyCommandResult.java:501)
at
org.apache.geode.management.internal.cli.NetstatDUnitTest.testOutputToConsoleWithLsofForOneMember(NetstatDUnitTest.java:111)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6222) CI Failure: GemFireDeadlockDetectorDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-6222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe updated GEODE-6222:
Affects Version/s: 1.9.0
> CI Failure: GemFireDeadlockDetectorDUnitTest
>
>
> Key: GEODE-6222
> URL: https://issues.apache.org/jira/browse/GEODE-6222
> Project: Geode
> Issue Type: Bug
> Components: distributed lock service
>Affects Versions: 1.9.0
>Reporter: Kenneth Howe
>Priority: Major
>
> Flaky test failure in
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/247]
> {code:java}
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
> > testDistributedDeadlockWithDLock FAILED
> java.lang.AssertionError
> at org.junit.Assert.fail(Assert.java:86)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertTrue(Assert.java:52)
> at
> org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock(GemFireDeadlockDetectorDUnitTest.java:199)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6222) CI Failure: GemFireDeadlockDetectorDUnitTest
Kenneth Howe created GEODE-6222:
---
Summary: CI Failure: GemFireDeadlockDetectorDUnitTest
Key: GEODE-6222
URL: https://issues.apache.org/jira/browse/GEODE-6222
Project: Geode
Issue Type: Bug
Components: distributed lock service
Reporter: Kenneth Howe
Flaky test failure in
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/247]
{code:java}
org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest
> testDistributedDeadlockWithDLock FAILED
java.lang.AssertionError
at org.junit.Assert.fail(Assert.java:86)
at org.junit.Assert.assertTrue(Assert.java:41)
at org.junit.Assert.assertTrue(Assert.java:52)
at
org.apache.geode.distributed.internal.deadlock.GemFireDeadlockDetectorDUnitTest.testDistributedDeadlockWithDLock(GemFireDeadlockDetectorDUnitTest.java:199)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6221) CI Failure: LocatorConnectionDUnitTest.testInvalidOperationReturnsFailure statistics verification failed for bytesSent
[ https://issues.apache.org/jira/browse/GEODE-6221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenneth Howe updated GEODE-6221: Affects Version/s: 1.9.0 Description: Seen in the most recent CI run, so don't know if this is a nee consistent failure or some previously unseen flaky failure. Test failure found in [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/253] was: Test failure found in [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/253] > CI Failure: LocatorConnectionDUnitTest.testInvalidOperationReturnsFailure > statistics verification failed for bytesSent > -- > > Key: GEODE-6221 > URL: https://issues.apache.org/jira/browse/GEODE-6221 > Project: Geode > Issue Type: Bug >Affects Versions: 1.9.0 >Reporter: Kenneth Howe >Priority: Major > > Seen in the most recent CI run, so don't know if this is a nee consistent > failure or some previously unseen flaky failure. > Test failure found in > [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/253] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-6221) CI Failure: LocatorConnectionDUnitTest.testInvalidOperationReturnsFailure statistics verification failed for bytesSent
Kenneth Howe created GEODE-6221: --- Summary: CI Failure: LocatorConnectionDUnitTest.testInvalidOperationReturnsFailure statistics verification failed for bytesSent Key: GEODE-6221 URL: https://issues.apache.org/jira/browse/GEODE-6221 Project: Geode Issue Type: Bug Reporter: Kenneth Howe Test failure found in [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK8/builds/253] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-6219) NetstatDUnitTest is not not detecting failures in executing OS netstat command
[
https://issues.apache.org/jira/browse/GEODE-6219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe updated GEODE-6219:
Affects Version/s: 1.7.0
> NetstatDUnitTest is not not detecting failures in executing OS netstat command
> --
>
> Key: GEODE-6219
> URL: https://issues.apache.org/jira/browse/GEODE-6219
> Project: Geode
> Issue Type: Bug
> Components: ci, gfsh, tests
>Affects Versions: 1.7.0
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
>
> The tests in {{NetstatDUnitTest}} are all passing in CI. However, the logs
> show that the OS command that is run on the servers in the cluster is failing:
> {code}
> Command result for --file=/tmp/junit5019199898297364101/junit8715261921376128635/command.log.txt>:
>
> Saved netstat output in the file
> /tmp/junit5019199898297364101/junit8715261921376128635/command.log.txt.
> Command result for :
> ##
> Host: 1dcb8055baac
> OS: Linux 4.9.0-8-amd64 amd64
> Member(s):
> server-1, locator-0, server-2
> ##
> Could not execute "netstat". Reason: Cannot run program "netstat": error=2,
> No such file or directory
> {code}
> That {{netstat}} is missing from the CI test workers is being addressed in
> PR#3014.
> The {{netstat}} tests need to verify the the OS commands run, in addition to
> verifying that the gfsh command tried to run on the expected servers.
> Suggest adding a check such as:
> {code}
> @@ -168,20 +187,24 @@ public class NetstatDUnitTest {
>@Test
>public void testConnectToLocatorWithLargeCommandResponse() throws
> Exception {
> gfsh.connect(server0.getEmbeddedLocatorPort(),
> GfshCommandRule.PortType.locator);
> -gfsh.executeAndAssertThat(netStatLsofCommand).statusIsSuccess();
> +gfsh.executeAndAssertThat(netStatLsofCommand).statusIsSuccess()
> +.doesNotContainOutput("Could not execute");
>}
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6219) NetstatDUnitTest is not not detecting failures in executing OS netstat command
Kenneth Howe created GEODE-6219:
---
Summary: NetstatDUnitTest is not not detecting failures in
executing OS netstat command
Key: GEODE-6219
URL: https://issues.apache.org/jira/browse/GEODE-6219
Project: Geode
Issue Type: Bug
Components: ci, gfsh, tests
Reporter: Kenneth Howe
The tests in {{NetstatDUnitTest}} are all passing in CI. However, the logs show
that the OS command that is run on the servers in the cluster is failing:
{code}
Command result for :
Saved netstat output in the file
/tmp/junit5019199898297364101/junit8715261921376128635/command.log.txt.
Command result for :
##
Host: 1dcb8055baac
OS: Linux 4.9.0-8-amd64 amd64
Member(s):
server-1, locator-0, server-2
##
Could not execute "netstat". Reason: Cannot run program "netstat": error=2, No
such file or directory
{code}
That {{netstat}} is missing from the CI test workers is being addressed in
PR#3014.
The {{netstat}} tests need to verify the the OS commands run, in addition to
verifying that the gfsh command tried to run on the expected servers.
Suggest adding a check such as:
{code}
@@ -168,20 +187,24 @@ public class NetstatDUnitTest {
@Test
public void testConnectToLocatorWithLargeCommandResponse() throws Exception {
gfsh.connect(server0.getEmbeddedLocatorPort(),
GfshCommandRule.PortType.locator);
-gfsh.executeAndAssertThat(netStatLsofCommand).statusIsSuccess();
+gfsh.executeAndAssertThat(netStatLsofCommand).statusIsSuccess()
+.doesNotContainOutput("Could not execute");
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6219) NetstatDUnitTest is not not detecting failures in executing OS netstat command
[
https://issues.apache.org/jira/browse/GEODE-6219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reassigned GEODE-6219:
---
Assignee: Kenneth Howe
> NetstatDUnitTest is not not detecting failures in executing OS netstat command
> --
>
> Key: GEODE-6219
> URL: https://issues.apache.org/jira/browse/GEODE-6219
> Project: Geode
> Issue Type: Bug
> Components: ci, gfsh, tests
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
>
> The tests in {{NetstatDUnitTest}} are all passing in CI. However, the logs
> show that the OS command that is run on the servers in the cluster is failing:
> {code}
> Command result for --file=/tmp/junit5019199898297364101/junit8715261921376128635/command.log.txt>:
>
> Saved netstat output in the file
> /tmp/junit5019199898297364101/junit8715261921376128635/command.log.txt.
> Command result for :
> ##
> Host: 1dcb8055baac
> OS: Linux 4.9.0-8-amd64 amd64
> Member(s):
> server-1, locator-0, server-2
> ##
> Could not execute "netstat". Reason: Cannot run program "netstat": error=2,
> No such file or directory
> {code}
> That {{netstat}} is missing from the CI test workers is being addressed in
> PR#3014.
> The {{netstat}} tests need to verify the the OS commands run, in addition to
> verifying that the gfsh command tried to run on the expected servers.
> Suggest adding a check such as:
> {code}
> @@ -168,20 +187,24 @@ public class NetstatDUnitTest {
>@Test
>public void testConnectToLocatorWithLargeCommandResponse() throws
> Exception {
> gfsh.connect(server0.getEmbeddedLocatorPort(),
> GfshCommandRule.PortType.locator);
> -gfsh.executeAndAssertThat(netStatLsofCommand).statusIsSuccess();
> +gfsh.executeAndAssertThat(netStatLsofCommand).statusIsSuccess()
> +.doesNotContainOutput("Could not execute");
>}
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-6204) Add unit tests for gfsh command "netstat --with-lsof"
[
https://issues.apache.org/jira/browse/GEODE-6204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe updated GEODE-6204:
Affects Version/s: 1.7.0
> Add unit tests for gfsh command "netstat --with-lsof"
> -
>
> Key: GEODE-6204
> URL: https://issues.apache.org/jira/browse/GEODE-6204
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Affects Versions: 1.7.0
>Reporter: Kenneth Howe
>Priority: Major
>
> Create a unit test for gfsh command {{netstat --with-lsof}} to verify that
> the correct options are added to the OS commands ({{netstat}} and {{lsof}})
> that are run. The added options should disable DNS and port name lookups.
> Tests using the command option {{--with-lsof}} currently exist as DUnit
> tests. This means that the command is run on at least one of the JVMs started
> up as part of the distributed test infrastructure. When using {{lsof}}, the
> command output can be very large, and take a long time (even when using
> {{-n}} option on the underlying shell command to not do DNS lookups). This
> all may result in flaky test results, either due to timeouts waiting for a
> response or due to OutOfMemoryExceptions caused by the massive Java objects
> created to hold the shell command output as a String.
> The purpose of NetStatDUnitTest.testOutputToConsoleWithLsofForOneMember is
> ensure that the underlybing OS shell commands created by the gfsh command
> have the {{-n}} option applied for {{netstat}} and {{-nP}} for {{lsof}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6204) Add unit tests for gfsh command "netstat --with-lsof"
Kenneth Howe created GEODE-6204:
---
Summary: Add unit tests for gfsh command "netstat --with-lsof"
Key: GEODE-6204
URL: https://issues.apache.org/jira/browse/GEODE-6204
Project: Geode
Issue Type: Improvement
Components: gfsh
Reporter: Kenneth Howe
Create a unit test for gfsh command {{netstat --with-lsof}} to verify that the
correct options are added to the OS commands ({{netstat}} and {{lsof}}) that
are run. The added options should disable DNS and port name lookups.
Tests using the command option {{--with-lsof}} currently exist as DUnit tests.
This means that the command is run on at least one of the JVMs started up as
part of the distributed test infrastructure. When using {{lsof}}, the command
output can be very large, and take a long time (even when using {{-n}} option
on the underlying shell command to not do DNS lookups). This all may result in
flaky test results, either due to timeouts waiting for a response or due to
OutOfMemoryExceptions caused by the massive Java objects created to hold the
shell command output as a String.
The purpose of NetStatDUnitTest.testOutputToConsoleWithLsofForOneMember is
ensure that the underlybing OS shell commands created by the gfsh command have
the {{-n}} option applied for {{netstat}} and {{-nP}} for {{lsof}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6161) AbstractDistributionConfig.checkAttribute hides underlying cause of when throwing Internal GemFireException
Kenneth Howe created GEODE-6161:
---
Summary: AbstractDistributionConfig.checkAttribute hides
underlying cause of when throwing Internal GemFireException
Key: GEODE-6161
URL: https://issues.apache.org/jira/browse/GEODE-6161
Project: Geode
Issue Type: Improvement
Components: configuration
Reporter: Kenneth Howe
Locator failed to start, and threw InternalGemfireException. However the
underlying cause of the exception was not included in the exception message as
seen in the following code snippet
{code}
try {
return checker.invoke(this, value);
} catch (Exception e) {
if (e instanceof RuntimeException) {
throw (RuntimeException) e;
}
if (e.getCause() instanceof RuntimeException) {
throw (RuntimeException) e.getCause();
} else {
throw new InternalGemFireException(
"error invoking " + checker.getName() + " with value " + value);
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6027) Separate ConfigObject from the ResultModel for configuration persistence
[
https://issues.apache.org/jira/browse/GEODE-6027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reassigned GEODE-6027:
---
Assignee: Kenneth Howe
> Separate ConfigObject from the ResultModel for configuration persistence
>
>
> Key: GEODE-6027
> URL: https://issues.apache.org/jira/browse/GEODE-6027
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
>
> Evolving the {{CommandExector}} class/workflow; as we're refactoring more
> classes, making the following changes seems appropriate:
> - Have {{updateClusterConfig}} return a boolean value indicating whether a
> change was made or not
> - Have {{updateClusterConfig}} receive the {{ResultModel}} as input
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6027) Separate ConfigObject from the ResultModel for configuration persistence
Kenneth Howe created GEODE-6027:
---
Summary: Separate ConfigObject from the ResultModel for
configuration persistence
Key: GEODE-6027
URL: https://issues.apache.org/jira/browse/GEODE-6027
Project: Geode
Issue Type: Improvement
Components: gfsh
Reporter: Kenneth Howe
Evolving the {{CommandExector}} class/workflow; as we're refactoring more
classes, making the following changes seems appropriate:
- Have {{updateClusterConfig}} return a boolean value indicating whether a
change was made or not
- Have {{updateClusterConfig}} receive the {{ResultModel}} as input
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-6002) Member specific configuration is not persisted in the cluster configuration
[
https://issues.apache.org/jira/browse/GEODE-6002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16677356#comment-16677356
]
Kenneth Howe commented on GEODE-6002:
-
The following commands have a {{--member}} option and may affect the
configuration:
{code}
DestroyGatewayReceiverCommand.java
CreateGatewayReceiverCommand.java
StartGatewayReceiverCommand.java
DestroyIndexCommand.java
CreateDefinedIndexesCommand.java
DestroyFunctionCommand.java
CreateIndexCommand.java
AlterRuntimeConfigCommand.java
CreateGatewaySenderCommand.java
DestroyGatewaySenderCommand.java
StartGatewaySenderCommand.java
{code}
> Member specific configuration is not persisted in the cluster configuration
> ---
>
> Key: GEODE-6002
> URL: https://issues.apache.org/jira/browse/GEODE-6002
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.7.0
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
>
> Some commands, such as {{create gateway-receiver}} have an option
> ({{--member}}) to restrict the command to a single server member in the
> cluster. This member specific action now creates the object on the server but
> does not store the configuration information in the cluster configuration.
> The same command, when used without the {{--member}} option will save the
> information as an entry in the cluster configuration.
> If a member with specific configuration shuts down and is then restarted, the
> object (e.g. gateway-receiver) will not be recreated because there is no
> persisted record of it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-6002) Member specific configuration is not persisted in the cluster configuration
[
https://issues.apache.org/jira/browse/GEODE-6002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reassigned GEODE-6002:
---
Assignee: Kenneth Howe
Affects Version/s: 1.7.0
> Member specific configuration is not persisted in the cluster configuration
> ---
>
> Key: GEODE-6002
> URL: https://issues.apache.org/jira/browse/GEODE-6002
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.7.0
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
>
> Some commands, such as {{create gateway-receiver}} have an option
> ({{--member}}) to restrict the command to a single server member in the
> cluster. This member specific action now creates the object on the server but
> does not store the configuration information in the cluster configuration.
> The same command, when used without the {{--member}} option will save the
> information as an entry in the cluster configuration.
> If a member with specific configuration shuts down and is then restarted, the
> object (e.g. gateway-receiver) will not be recreated because there is no
> persisted record of it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-6002) Member specific configuration is not persisted in the cluster configuration
Kenneth Howe created GEODE-6002:
---
Summary: Member specific configuration is not persisted in the
cluster configuration
Key: GEODE-6002
URL: https://issues.apache.org/jira/browse/GEODE-6002
Project: Geode
Issue Type: Bug
Components: gfsh
Reporter: Kenneth Howe
Some commands, such as {{create gateway-receiver}} have an option
({{--member}}) to restrict the command to a single server member in the
cluster. This member specific action now creates the object on the server but
does not store the configuration information in the cluster configuration. The
same command, when used without the {{--member}} option will save the
information as an entry in the cluster configuration.
If a member with specific configuration shuts down and is then restarted, the
object (e.g. gateway-receiver) will not be recreated because there is no
persisted record of it.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5701) CI Failure: StopServerWithSecurityAcceptanceTest
[
https://issues.apache.org/jira/browse/GEODE-5701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reassigned GEODE-5701:
---
Assignee: Kenneth Howe
> CI Failure: StopServerWithSecurityAcceptanceTest
>
>
> Key: GEODE-5701
> URL: https://issues.apache.org/jira/browse/GEODE-5701
> Project: Geode
> Issue Type: Bug
>Reporter: Helena Bales
>Assignee: Kenneth Howe
>Priority: Major
> Labels: swat
>
> Several tests in StopServerWithSecurityAcceptanceTest fail on CI:
> {code:java}
> org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest
> > cannotStopServerAsClusterReaderOverJmx FAILED
>
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:117)
>
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:135)
>
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:106)
>
> at
> org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest.startCluster(StopServerWithSecurityAcceptanceTest.java:110)
>
> at
> org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest.cannotStopServerAsClusterReaderOverJmx(StopServerWithSecurityAcceptanceTest.java:87)
>
>
> org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest
> > cannotStopServerAsDataReaderOverHttp FAILED
>
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:117)
>
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:135)
>
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:106)
>
> at
> org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest.startCluster(StopServerWithSecurityAcceptanceTest.java:110)
>
> at
> org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest.cannotStopServerAsDataReaderOverHttp(StopServerWithSecurityAcceptanceTest.java:57)
>
>
> org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest
> > cannotStopServerAsDataReaderOverJmx FAILED
>
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:117)
>
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:135)
>
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:106)
>
> at
> org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest.startCluster(StopServerWithSecurityAcceptanceTest.java:110)
>
> at
> org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest.cannotStopServerAsDataReaderOverJmx(StopServerWithSecurityAcceptanceTest.java:72)
>
>
> org.apache.geode.management.internal.cli.commands.StopServerWithSecurityAcceptanceTest
> > canStopServerAsClusterAdminOverHttp FAILED
>
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
>
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>
> at
>
[jira] [Assigned] (GEODE-5760) CI failure: Expected exception Not found in QueryMonitorDUnitTest.testQueryMonitorRegionWithIndex
[
https://issues.apache.org/jira/browse/GEODE-5760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reassigned GEODE-5760:
---
Assignee: Kenneth Howe
> CI failure: Expected exception Not found in
> QueryMonitorDUnitTest.testQueryMonitorRegionWithIndex
> -
>
> Key: GEODE-5760
> URL: https://issues.apache.org/jira/browse/GEODE-5760
> Project: Geode
> Issue Type: Bug
> Components: cq
>Reporter: Bill
>Assignee: Kenneth Howe
>Priority: Major
> Labels: swat
>
> In
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/415
> {code}
> > Task :geode-cq:distributedTest
> org.apache.geode.cache.query.dunit.QueryMonitorDUnitTest >
> testQueryMonitorRegionWithIndex FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.query.dunit.QueryMonitorDUnitTest$$Lambda$104/648688972.run
> in VM 4 running on Host 17a0abd8c00d with 5 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:450)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:419)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:362)
> at
> org.apache.geode.test.junit.rules.VMProvider.invoke(VMProvider.java:70)
> at
> org.apache.geode.cache.query.dunit.QueryMonitorDUnitTest.testQueryMonitorRegionWithIndex(QueryMonitorDUnitTest.java:239)
> Caused by:
> java.lang.AssertionError: Expected exception Not found. Expected
> exception with message:
> "Query execution taking more than the max execution time"
> Found
> Pool unexpected socket timed out on client connection=Pooled
> Connection to localhost:37885: Connection[localhost:37885]@176708196). Server
> unreachable: could not connect after 1 attempts
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.cache.query.dunit.QueryMonitorDUnitTest.verifyException(QueryMonitorDUnitTest.java:410)
> at
> org.apache.geode.cache.query.dunit.QueryMonitorDUnitTest.exuteQuery(QueryMonitorDUnitTest.java:363)
> at
> org.apache.geode.cache.query.dunit.QueryMonitorDUnitTest.lambda$testQueryMonitorRegionWithIndex$bb17a952$3(QueryMonitorDUnitTest.java:239)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-3620) Gfsh 'alter runtime -- log-disk-space-limit' throws NPE if log-file-size-limit is not set
[
https://issues.apache.org/jira/browse/GEODE-3620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe resolved GEODE-3620.
-
Resolution: Fixed
Fix Version/s: 1.4.0
> Gfsh 'alter runtime -- log-disk-space-limit' throws NPE if
> log-file-size-limit is not set
> -
>
> Key: GEODE-3620
> URL: https://issues.apache.org/jira/browse/GEODE-3620
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.2.0
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
> Fix For: 1.4.0
>
>
> Steps to reproduce:
> * With gfsh, start a locator and server
> {code}
> $ gfsh
> _ __
>/ _/ __/ __/ // /
> / / __/ /___ /_ / _ /
> / /__/ / / _/ / // /
> /__/_/ /__/_//_/1.3.0-SNAPSHOT
> Monitor and Manage Apache Geode
> gfsh>start locator --name=locator1 --port=12345
> Starting a Geode Locator in /Users/khowe/work/GEM-1632/locator1...
> ...
> Successfully connected to: JMX Manager [host=10.118.33.251, port=1099]
> Cluster configuration service is up and running.
> gfsh>start server --name=server1 --server-port=54321
> Starting a Geode Server in /Users/khowe/work/GEM-1632/server1...
> ...
> Server in /Users/khowe/work/GEM-1632/server1 on 10.118.33.251[54321] as
> server1 is currently online.
> ...
> {code}
> * Still connected in gfsh, try to set the log-disk-space-limit
> {code}
> gfsh>alter runtime --log-disk-space-limit=1000
> Could not process command due to error. Error while processing command
> <[GfshParseResult@ac4bae8 method =
> alterRuntimeConfig@AlterRuntimeConfigCommand, instance =
> org.apache.geode.management.internal.cli.commands.AlterRuntimeConfigCommand@4e406694,
> arguments =
> 'null,null,null,null,1000,null,null,null,null,null,null,null,null,null,null']>
> Reason : java.lang.NullPointerException
> at java.util.TreeMap.compare(TreeMap.java:1294)
> at java.util.TreeMap.put(TreeMap.java:538)
> at java.util.TreeSet.add(TreeSet.java:255)
> at
> org.apache.geode.management.internal.cli.commands.AlterRuntimeConfigCommand.alterRuntimeConfig(AlterRuntimeConfigCommand.java:193)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.springframework.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:216)
> at
> org.apache.geode.management.internal.cli.remote.CommandExecutor.invokeCommand(CommandExecutor.java:54)
> at
> org.apache.geode.management.internal.cli.remote.CommandExecutor.execute(CommandExecutor.java:37)
> at
> org.apache.geode.management.internal.cli.remote.OnlineCommandProcessor.executeCommand(OnlineCommandProcessor.java:131)
> at
> org.apache.geode.management.internal.beans.MemberMBeanBridge.processCommand(MemberMBeanBridge.java:1577)
> at
> org.apache.geode.management.internal.beans.MemberMBean.processCommand(MemberMBean.java:406)
> ...
> {code}
> Running a version of gfsh with some addtional debug code added I am able to
> see the NPE on the server. From {{server1/server1.log}}:
> {code}
> [error 2017/09/14 10:30:49.363 PDT server1
> tid=0x4b] Exception happened on : 10.118.33.251(server1:14796):1025
> java.lang.NullPointerException
> at
> org.apache.geode.internal.io.MainWithChildrenRollingFileHandler.findChildrenExcept(MainWithChildrenRollingFileHandler.java:235)
> at
> org.apache.geode.internal.io.MainWithChildrenRollingFileHandler.checkDiskSpace(MainWithChildrenRollingFileHandler.java:138)
> at
> org.apache.geode.internal.io.MainWithChildrenRollingFileHandler.checkDiskSpace(MainWithChildrenRollingFileHandler.java:130)
> at
> org.apache.geode.internal.logging.ManagerLogWriter.checkDiskSpace(ManagerLogWriter.java:345)
> at
> org.apache.geode.internal.logging.ManagerLogWriter.switchLogs(ManagerLogWriter.java:288)
> at
> org.apache.geode.internal.logging.ManagerLogWriter.configChanged(ManagerLogWriter.java:124)
> at
> org.apache.geode.internal.logging.log4j.LogWriterAppender.configChanged(LogWriterAppender.java:212)
> at
> org.apache.geode.internal.logging.log4j.LogWriterAppenders.configChanged(LogWriterAppenders.java:284)
> at
> org.apache.geode.distributed.internal.RuntimeDistributionConfigImpl.setLogDiskSpaceLimit(RuntimeDistributionConfigImpl.java:118)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
[jira] [Resolved] (GEODE-5455) ClassCastException in MemberMBean.showOSMetrics, OSMetrics is not reconstructible from CompositeData
[
https://issues.apache.org/jira/browse/GEODE-5455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe resolved GEODE-5455.
-
Resolution: Fixed
Fix Version/s: 1.7.0
> ClassCastException in MemberMBean.showOSMetrics, OSMetrics is not
> reconstructible from CompositeData
>
>
> Key: GEODE-5455
> URL: https://issues.apache.org/jira/browse/GEODE-5455
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Affects Versions: 1.4.0
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.7.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The following code snippet throws
> {code}
> Exception in thread "main" java.lang.ClassCastException:
> javax.management.openmbean.CompositeDataSupport cannot be cast to
> org.apache.geode.management.OSMetrics at
> com.sun.proxy.$Proxy0.showOSMetrics(Unknown Source)
> {code}
> {code:java}
> public static MBeanServerConnection getLocalMBeanServerConnectionStatic(int
> pid) {
> try {
> String address = ConnectorAddressLink.importFrom(pid);
> JMXServiceURL jmxUrl = new JMXServiceURL(address);
> return JMXConnectorFactory.connect(jmxUrl).getMBeanServerConnection();
> } catch (IOException e) {
> throw new RuntimeException(
> "Of course you still have to implement a good connection handling");
> }
> }
> public static void main(String[] args) throws IOException,
> MalformedObjectNameException, InstanceNotFoundException,
> ReflectionException {
> MBeanServerConnection mbeanServerConnection =
> getLocalMBeanServerConnectionStatic(127510);
> ObjectName mbeanName = new
> ObjectName("GemFire:type=Member,member=server1");
> MemberMXBean
> memberbeanInstance =
> (MemberMXBean) MBeanServerInvocationHandler
> .newProxyInstance(mbeanServerConnection, mbeanName,
> MemberMXBean.class, Boolean.TRUE);
> System.out.println(Arrays.toString(memberbeanInstance.listRegions()));
> OSMetrics cdOSMetrics = memberbeanInstance.showOSMetrics();
> //.
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5741) StartLocatorCommandDUnitTest relative directory tests are not build environment independant
[ https://issues.apache.org/jira/browse/GEODE-5741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenneth Howe resolved GEODE-5741. - Resolution: Fixed Fix Version/s: 1.8.0 > StartLocatorCommandDUnitTest relative directory tests are not build > environment independant > --- > > Key: GEODE-5741 > URL: https://issues.apache.org/jira/browse/GEODE-5741 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Kenneth Howe >Assignee: Kenneth Howe >Priority: Major > Labels: pull-request-available, swat > Fix For: 1.8.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > The tests that attempt to start locators from paths at the file system root, > '/', expect to fail directory creation due to no write permission. However, > if the tests are run as root, then directory creation succeeds. > These tests furthermore use paths with hardcoded '/' in the paths so they > will not run properly on Windows. > The tests shold be made system and build/test environment independent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5741) StartLocatorCommandDUnitTest relative directory tests are not build environment independant
Kenneth Howe created GEODE-5741: --- Summary: StartLocatorCommandDUnitTest relative directory tests are not build environment independant Key: GEODE-5741 URL: https://issues.apache.org/jira/browse/GEODE-5741 Project: Geode Issue Type: Bug Components: gfsh Reporter: Kenneth Howe The tests that attempt to start locators from paths at the file system root, '/', expect to fail directory creation due to no write permission. However, if the tests are run as root, then directory creation succeeds. These tests furthermore use paths with hardcoded '/' in the paths so they will not run properly on Windows. The tests shold be made system and build/test environment independent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5741) StartLocatorCommandDUnitTest relative directory tests are not build environment independant
[ https://issues.apache.org/jira/browse/GEODE-5741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenneth Howe updated GEODE-5741: Labels: swat (was: ) > StartLocatorCommandDUnitTest relative directory tests are not build > environment independant > --- > > Key: GEODE-5741 > URL: https://issues.apache.org/jira/browse/GEODE-5741 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Kenneth Howe >Assignee: Kenneth Howe >Priority: Major > Labels: swat > > The tests that attempt to start locators from paths at the file system root, > '/', expect to fail directory creation due to no write permission. However, > if the tests are run as root, then directory creation succeeds. > These tests furthermore use paths with hardcoded '/' in the paths so they > will not run properly on Windows. > The tests shold be made system and build/test environment independent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5741) StartLocatorCommandDUnitTest relative directory tests are not build environment independant
[ https://issues.apache.org/jira/browse/GEODE-5741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenneth Howe reassigned GEODE-5741: --- Assignee: Kenneth Howe > StartLocatorCommandDUnitTest relative directory tests are not build > environment independant > --- > > Key: GEODE-5741 > URL: https://issues.apache.org/jira/browse/GEODE-5741 > Project: Geode > Issue Type: Bug > Components: gfsh >Reporter: Kenneth Howe >Assignee: Kenneth Howe >Priority: Major > Labels: swat > > The tests that attempt to start locators from paths at the file system root, > '/', expect to fail directory creation due to no write permission. However, > if the tests are run as root, then directory creation succeeds. > These tests furthermore use paths with hardcoded '/' in the paths so they > will not run properly on Windows. > The tests shold be made system and build/test environment independent. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5728) Suspect string (NullPointerException) found in LocatorDUnitTest.testStartTwoLocators
[
https://issues.apache.org/jira/browse/GEODE-5728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe updated GEODE-5728:
Component/s: membership
> Suspect string (NullPointerException) found in
> LocatorDUnitTest.testStartTwoLocators
>
>
> Key: GEODE-5728
> URL: https://issues.apache.org/jira/browse/GEODE-5728
> Project: Geode
> Issue Type: Bug
> Components: membership, swat
>Reporter: Kenneth Howe
>Priority: Major
>
> DistributedTest failure in
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/379
> {code}
> 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 1241
> [fatal 2018/09/11 00:04:32.409 UTC tid=0x676]
> Exception in processing request from 172.17.0.20
> java.lang.NullPointerException
> at
> org.apache.geode.distributed.internal.membership.gms.locator.GMSLocator.processFindCoordinatorRequest(GMSLocator.java:309)
> at
> org.apache.geode.distributed.internal.membership.gms.locator.GMSLocator.processRequest(GMSLocator.java:205)
> at
> org.apache.geode.distributed.internal.InternalLocator$PrimaryHandler.processRequest(InternalLocator.java:1194)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.processOneConnection(TcpServer.java:484)
> at
> org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:378)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> The test doesn't have a history of (flaky) failures that I've discovered, and
> I haven't gotten it to fail locally.
> The NPE comes from a null return from {{v.getCoordinator()}}.
> {code}
> synchronized (registrants) {
> if (isCoordinator) {
> coordinator = localAddress;
> if (v != null && !v.getCoordinator().equals(localAddress)) {
> logger.info("This member is becoming coordinator since view {}", v);
> v = null;
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5728) Suspect string (NullPointerException) found in LocatorDUnitTest.testStartTwoLocators
Kenneth Howe created GEODE-5728:
---
Summary: Suspect string (NullPointerException) found in
LocatorDUnitTest.testStartTwoLocators
Key: GEODE-5728
URL: https://issues.apache.org/jira/browse/GEODE-5728
Project: Geode
Issue Type: Bug
Components: swat
Reporter: Kenneth Howe
DistributedTest failure in
https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/379
{code}
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 1241
[fatal 2018/09/11 00:04:32.409 UTC tid=0x676]
Exception in processing request from 172.17.0.20
java.lang.NullPointerException
at
org.apache.geode.distributed.internal.membership.gms.locator.GMSLocator.processFindCoordinatorRequest(GMSLocator.java:309)
at
org.apache.geode.distributed.internal.membership.gms.locator.GMSLocator.processRequest(GMSLocator.java:205)
at
org.apache.geode.distributed.internal.InternalLocator$PrimaryHandler.processRequest(InternalLocator.java:1194)
at
org.apache.geode.distributed.internal.tcpserver.TcpServer.processOneConnection(TcpServer.java:484)
at
org.apache.geode.distributed.internal.tcpserver.TcpServer.lambda$processRequest$0(TcpServer.java:378)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
The test doesn't have a history of (flaky) failures that I've discovered, and I
haven't gotten it to fail locally.
The NPE comes from a null return from {{v.getCoordinator()}}.
{code}
synchronized (registrants) {
if (isCoordinator) {
coordinator = localAddress;
if (v != null && !v.getCoordinator().equals(localAddress)) {
logger.info("This member is becoming coordinator since view {}", v);
v = null;
}
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5676) ClusterConfigLocatorRestartDUnitTest hung in CI
[
https://issues.apache.org/jira/browse/GEODE-5676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reassigned GEODE-5676:
---
Assignee: Kenneth Howe
> ClusterConfigLocatorRestartDUnitTest hung in CI
> ---
>
> Key: GEODE-5676
> URL: https://issues.apache.org/jira/browse/GEODE-5676
> Project: Geode
> Issue Type: Bug
>Reporter: Dan Smith
>Assignee: Kenneth Howe
>Priority: Major
> Labels: swat
> Attachments: callstacks.txt
>
>
> This test hung in a couple of runs of DistributedTest
>
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds//430
>
> https://concourse.apachegeode-ci.info/teams/staging/pipelines/concourse-staging/jobs/DistributedTest/builds//370
> {noformat}
> Started @ 2018-08-30 04:23:46.599 +
> 2018-08-30 04:48:33.135 +
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest
> serverRestartsAfterLocatorReconnects
> Ended @ 2018-08-30 05:21:34.897 +
> {noformat}
> It seems to be stuck in tear down
> {noformat}
> "ReconnectThread" #416 prio=5 os_prio=0 tid=0x7fa86cad2000 nid=0xd07 in
> Object.wait() [0x7fa744ecd000]
>java.lang.Thread.State: TIMED_WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2697)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2558)
> - locked <0xe00bedc8> (a java.lang.Object)
> - locked <0xe07af498> (a java.lang.Class for
> org.apache.geode.internal.cache.GemFireCacheImpl)
> - locked <0xe00bedd8> (a java.lang.Class for
> org.apache.geode.cache.CacheFactory)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1041)
> at
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:3987)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.uncleanShutdown(GMSMembershipManager.java:1552)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.lambda$forceDisconnect$1(GMSMembershipManager.java:2564)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager$$Lambda$81/1816825082.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:748)
>Locked ownable synchronizers:
> - None
> "RMI TCP Connection(8)-172.17.0.13" #32 daemon prio=5 os_prio=0
> tid=0x7fa874001800 nid=0x2ff waiting for monitor entry
> [0x7fa8f0d15000]
>java.lang.Thread.State: BLOCKED (on object monitor)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1367)
> - waiting to lock <0xe07af498> (a java.lang.Class for
> org.apache.geode.internal.cache.GemFireCacheImpl)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1022)
> at
> org.apache.geode.test.junit.rules.MemberStarterRule.disconnectDSIfAny(MemberStarterRule.java:182)
> at
> org.apache.geode.test.junit.rules.MemberStarterRule.after(MemberStarterRule.java:129)
> at
> org.apache.geode.test.dunit.rules.ClusterStartupRule.stopElementInsideVM(ClusterStartupRule.java:385)
> at
> org.apache.geode.test.junit.rules.VMProvider.lambda$stop$fe0d42dc$1(VMProvider.java:42)
> at
> org.apache.geode.test.junit.rules.VMProvider$$Lambda$77/1844235204.run(Unknown
> Source)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at hydra.MethExecutor.executeObject(MethExecutor.java:244)
> at
> org.apache.geode.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:70)
> at sun.reflect.GeneratedMethodAccessor116.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> at sun.rmi.transport.Transport$1.run(Transport.java:200)
> at sun.rmi.transport.Transport$1.run(Transport.java:197)
> at java.security.AccessController.doPrivileged(Native Method)
> at
[jira] [Resolved] (GEODE-5399) Remove the flaky category
[ https://issues.apache.org/jira/browse/GEODE-5399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenneth Howe resolved GEODE-5399. - Resolution: Fixed Fix Version/s: 1.8.0 > Remove the flaky category > - > > Key: GEODE-5399 > URL: https://issues.apache.org/jira/browse/GEODE-5399 > Project: Geode > Issue Type: Task >Reporter: Dan Smith >Assignee: Kenneth Howe >Priority: Major > Labels: pull-request-available, swat > Fix For: 1.8.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Based on discussion on the dev list, we want to completely remove the flaky > category. > We should > * Run all flaky tests and establish which ones are still failing > (GEODE-5371). Update the associated JIRAs > * Remove the Flaky category from all tests marked as flaky > * Remove the flakyTest target from gradle > * Remove the FlakyTest job from the concourse pipeline. > Relevant discussion on the dev list > https://markmail.org/thread/n4boyumlzvhrlqpq -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5399) Remove the flaky category
[ https://issues.apache.org/jira/browse/GEODE-5399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenneth Howe reassigned GEODE-5399: --- Assignee: Kenneth Howe > Remove the flaky category > - > > Key: GEODE-5399 > URL: https://issues.apache.org/jira/browse/GEODE-5399 > Project: Geode > Issue Type: Task >Reporter: Dan Smith >Assignee: Kenneth Howe >Priority: Major > Labels: swat > > Based on discussion on the dev list, we want to completely remove the flaky > category. > We should > * Run all flaky tests and establish which ones are still failing > (GEODE-5371). Update the associated JIRAs > * Remove the Flaky category from all tests marked as flaky > * Remove the flakyTest target from gradle > * Remove the FlakyTest job from the concourse pipeline. > Relevant discussion on the dev list > https://markmail.org/thread/n4boyumlzvhrlqpq -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-5551) Flaky unit test LoginHandlerInterceptorJUnitTest > testHandlerInterceptorThreadSafety
[
https://issues.apache.org/jira/browse/GEODE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe resolved GEODE-5551.
-
Resolution: Fixed
Fix Version/s: 1.8.0
Fixed via b73f8bbde3e19942093e14f090789ee7bec5a299 on GEODE-5607
> Flaky unit test LoginHandlerInterceptorJUnitTest >
> testHandlerInterceptorThreadSafety
> -
>
> Key: GEODE-5551
> URL: https://issues.apache.org/jira/browse/GEODE-5551
> 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:test
> org.apache.geode.management.internal.web.controllers.support.LoginHandlerInterceptorJUnitTest
> > testHandlerInterceptorThreadSafety FAILED
> junit.framework.AssertionFailedError: expected:<0> but was:<3>
> not all expectations were satisfied
> expectations:
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameterNames();
> returns
>
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getHeader("security-username");
> returns "admin"
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getHeader("security-password");
> returns "password"
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameter("vf.gf.env.STAGE");
> returns "test"
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameter("vf.gf.env.GEODE_HOME");
> returns "/path/to/gemfire/700"
> expected once, already invoked 1 time: securityService.login(not null);
> returns a default value
> expected once, already invoked 1 time: securityService.logout()
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameterNames();
> returns
>
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-username");
> returns "admin"
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-password");
> returns "password"
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.HOST");
> returns "localhost"
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.GEODE_HOME");
> returns "/path/to/gemfire/75"
> ! expected once, never invoked: securityService.login(not null);
> returns a default value
> ! expected once, never invoked: securityService.logout()
> what happened before this:
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameterNames()
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.HOST")
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.GEODE_HOME")
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-username")
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-password")
> securityService.login(<{security-username=admin,
> security-password=password}>)
> securityService.logout()
> at
> org.jmock.api.ExpectationError.notAllSatisfied(ExpectationError.java:27)
> at org.jmock.Mockery.assertIsSatisfied(Mockery.java:213)
> at
> org.apache.geode.management.internal.web.controllers.support.LoginHandlerInterceptorJUnitTest.tearDown(LoginHandlerInterceptorJUnitTest.java:70)
> {noformat}
> Failing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/Build/builds/558
> Passing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/Build/builds/559
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5551) Flaky unit test LoginHandlerInterceptorJUnitTest > testHandlerInterceptorThreadSafety
[
https://issues.apache.org/jira/browse/GEODE-5551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reassigned GEODE-5551:
---
Assignee: Kenneth Howe
> Flaky unit test LoginHandlerInterceptorJUnitTest >
> testHandlerInterceptorThreadSafety
> -
>
> Key: GEODE-5551
> URL: https://issues.apache.org/jira/browse/GEODE-5551
> Project: Geode
> Issue Type: Bug
> Components: tests
>Affects Versions: 1.8.0
>Reporter: Jacob S. Barrett
>Assignee: Kenneth Howe
>Priority: Major
> Labels: flaky, swat
>
> {noformat}
> > Task :geode-web:test
> org.apache.geode.management.internal.web.controllers.support.LoginHandlerInterceptorJUnitTest
> > testHandlerInterceptorThreadSafety FAILED
> junit.framework.AssertionFailedError: expected:<0> but was:<3>
> not all expectations were satisfied
> expectations:
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameterNames();
> returns
>
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getHeader("security-username");
> returns "admin"
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getHeader("security-password");
> returns "password"
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameter("vf.gf.env.STAGE");
> returns "test"
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameter("vf.gf.env.GEODE_HOME");
> returns "/path/to/gemfire/700"
> expected once, already invoked 1 time: securityService.login(not null);
> returns a default value
> expected once, already invoked 1 time: securityService.logout()
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameterNames();
> returns
>
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-username");
> returns "admin"
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-password");
> returns "password"
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.HOST");
> returns "localhost"
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.GEODE_HOME");
> returns "/path/to/gemfire/75"
> ! expected once, never invoked: securityService.login(not null);
> returns a default value
> ! expected once, never invoked: securityService.logout()
> what happened before this:
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameterNames()
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.HOST")
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.GEODE_HOME")
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-username")
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-password")
> securityService.login(<{security-username=admin,
> security-password=password}>)
> securityService.logout()
> at
> org.jmock.api.ExpectationError.notAllSatisfied(ExpectationError.java:27)
> at org.jmock.Mockery.assertIsSatisfied(Mockery.java:213)
> at
> org.apache.geode.management.internal.web.controllers.support.LoginHandlerInterceptorJUnitTest.tearDown(LoginHandlerInterceptorJUnitTest.java:70)
> {noformat}
> Failing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/Build/builds/558
> Passing:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/Build/builds/559
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5601) AcceptanceTests are run in parallel without using containers, resulting in port conflicts
[
https://issues.apache.org/jira/browse/GEODE-5601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe resolved GEODE-5601.
-
Resolution: Fixed
Fix Version/s: 1.7.0
Closing this as fixed, although there is still room for improving
AcceptanceTest runs. After merging this fix, the total runtime for this
category increased by about 4 min (22 -> 26).
> AcceptanceTests are run in parallel without using containers, resulting in
> port conflicts
> -
>
> Key: GEODE-5601
> URL: https://issues.apache.org/jira/browse/GEODE-5601
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Jacob S. Barrett
>Assignee: Kenneth Howe
>Priority: Major
> Labels: flaky, pull-request-available, swat
> Fix For: 1.7.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> {noformat}
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest >
> deployLargeSetOfJars FAILED
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:117)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:135)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:106)
> at
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest.deployLargeSetOfJars(DeployWithLargeJarTest.java:41)
> {noformat}
> Passes:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/AcceptanceTest/builds/721
> Fails:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/AcceptanceTest/builds/728
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5663) Flaky: LoginHandlerInterceptorJUnitTest.testHandlerInterceptorThreadSafety intermittent failures
[
https://issues.apache.org/jira/browse/GEODE-5663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe resolved GEODE-5663.
-
Resolution: Duplicate
> Flaky: LoginHandlerInterceptorJUnitTest.testHandlerInterceptorThreadSafety
> intermittent failures
>
>
> Key: GEODE-5663
> URL: https://issues.apache.org/jira/browse/GEODE-5663
> Project: Geode
> Issue Type: Test
> Components: ci
>Affects Versions: 1.7.0
>Reporter: Kenneth Howe
>Priority: Major
> Labels: flaky, swat
>
> This test has failed in the CI Build pipeline 3 times in the last ~6 days.
> {code:java}
> > Task :geode-web:test
> org.apache.geode.management.internal.web.controllers.support.LoginHandlerInterceptorJUnitTest
> > testHandlerInterceptorThreadSafety FAILED
> junit.framework.AssertionFailedError: expected:<0> but was:<3>
> not all expectations were satisfied
> expectations:
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameterNames();
> returns
>
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getHeader("security-username");
> returns "admin"
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getHeader("security-password");
> returns "password"
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameter("vf.gf.env.STAGE");
> returns "test"
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameter("vf.gf.env.GEODE_HOME");
> returns "/path/to/gemfire/700"
> expected once, already invoked 1 time: securityService.login(not null);
> returns a default value
> ! expected once, never invoked: securityService.logout()
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameterNames();
> returns
>
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-username");
> returns "admin"
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-password");
> returns "password"
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.HOST");
> returns "localhost"
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.GEODE_HOME");
> returns "/path/to/gemfire/75"
> ! expected once, never invoked: securityService.login(not null);
> returns a default value
> ! expected once, never invoked: securityService.logout()
> what happened before this:
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameterNames()
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.HOST")
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.GEODE_HOME")
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-username")
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-password")
> securityService.login(<{security-username=admin,
> security-password=password}>)
> at
> org.jmock.api.ExpectationError.notAllSatisfied(ExpectationError.java:27)
> at org.jmock.Mockery.assertIsSatisfied(Mockery.java:215)
> at
> org.apache.geode.management.internal.web.controllers.support.LoginHandlerInterceptorJUnitTest.tearDown(LoginHandlerInterceptorJUnitTest.java:70)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5663) Flaky: LoginHandlerInterceptorJUnitTest.testHandlerInterceptorThreadSafety intermittent failures
[
https://issues.apache.org/jira/browse/GEODE-5663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe updated GEODE-5663:
Affects Version/s: 1.7.0
Labels: flaky swat (was: )
> Flaky: LoginHandlerInterceptorJUnitTest.testHandlerInterceptorThreadSafety
> intermittent failures
>
>
> Key: GEODE-5663
> URL: https://issues.apache.org/jira/browse/GEODE-5663
> Project: Geode
> Issue Type: Test
> Components: ci
>Affects Versions: 1.7.0
>Reporter: Kenneth Howe
>Priority: Major
> Labels: flaky, swat
>
> This test has failed in the CI Build pipeline 3 times in the last ~6 days.
> {code:java}
> > Task :geode-web:test
> org.apache.geode.management.internal.web.controllers.support.LoginHandlerInterceptorJUnitTest
> > testHandlerInterceptorThreadSafety FAILED
> junit.framework.AssertionFailedError: expected:<0> but was:<3>
> not all expectations were satisfied
> expectations:
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameterNames();
> returns
>
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getHeader("security-username");
> returns "admin"
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getHeader("security-password");
> returns "password"
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameter("vf.gf.env.STAGE");
> returns "test"
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameter("vf.gf.env.GEODE_HOME");
> returns "/path/to/gemfire/700"
> expected once, already invoked 1 time: securityService.login(not null);
> returns a default value
> ! expected once, never invoked: securityService.logout()
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameterNames();
> returns
>
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-username");
> returns "admin"
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-password");
> returns "password"
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.HOST");
> returns "localhost"
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.GEODE_HOME");
> returns "/path/to/gemfire/75"
> ! expected once, never invoked: securityService.login(not null);
> returns a default value
> ! expected once, never invoked: securityService.logout()
> what happened before this:
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameterNames()
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.HOST")
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.GEODE_HOME")
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-username")
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-password")
> securityService.login(<{security-username=admin,
> security-password=password}>)
> at
> org.jmock.api.ExpectationError.notAllSatisfied(ExpectationError.java:27)
> at org.jmock.Mockery.assertIsSatisfied(Mockery.java:215)
> at
> org.apache.geode.management.internal.web.controllers.support.LoginHandlerInterceptorJUnitTest.tearDown(LoginHandlerInterceptorJUnitTest.java:70)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5663) Flaky: LoginHandlerInterceptorJUnitTest.testHandlerInterceptorThreadSafety intermittent failures
[
https://issues.apache.org/jira/browse/GEODE-5663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe updated GEODE-5663:
Summary: Flaky:
LoginHandlerInterceptorJUnitTest.testHandlerInterceptorThreadSafety
intermittent failures (was: Flaky: LoginHandlerInterceptorJUnitTest >
testHandlerInterceptorThreadSafety)
> Flaky: LoginHandlerInterceptorJUnitTest.testHandlerInterceptorThreadSafety
> intermittent failures
>
>
> Key: GEODE-5663
> URL: https://issues.apache.org/jira/browse/GEODE-5663
> Project: Geode
> Issue Type: Test
> Components: ci
>Reporter: Kenneth Howe
>Priority: Major
>
> This test has failed in the CI Build pipeline 3 times in the last ~6 days.
> {code:java}
> > Task :geode-web:test
> org.apache.geode.management.internal.web.controllers.support.LoginHandlerInterceptorJUnitTest
> > testHandlerInterceptorThreadSafety FAILED
> junit.framework.AssertionFailedError: expected:<0> but was:<3>
> not all expectations were satisfied
> expectations:
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameterNames();
> returns
>
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getHeader("security-username");
> returns "admin"
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getHeader("security-password");
> returns "password"
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameter("vf.gf.env.STAGE");
> returns "test"
> ! expected once, never invoked:
> testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameter("vf.gf.env.GEODE_HOME");
> returns "/path/to/gemfire/700"
> expected once, already invoked 1 time: securityService.login(not null);
> returns a default value
> ! expected once, never invoked: securityService.logout()
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameterNames();
> returns
>
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-username");
> returns "admin"
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-password");
> returns "password"
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.HOST");
> returns "localhost"
> expected once, already invoked 1 time:
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.GEODE_HOME");
> returns "/path/to/gemfire/75"
> ! expected once, never invoked: securityService.login(not null);
> returns a default value
> ! expected once, never invoked: securityService.logout()
> what happened before this:
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameterNames()
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.HOST")
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.GEODE_HOME")
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-username")
>
> testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-password")
> securityService.login(<{security-username=admin,
> security-password=password}>)
> at
> org.jmock.api.ExpectationError.notAllSatisfied(ExpectationError.java:27)
> at org.jmock.Mockery.assertIsSatisfied(Mockery.java:215)
> at
> org.apache.geode.management.internal.web.controllers.support.LoginHandlerInterceptorJUnitTest.tearDown(LoginHandlerInterceptorJUnitTest.java:70)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5663) Flaky: LoginHandlerInterceptorJUnitTest > testHandlerInterceptorThreadSafety
Kenneth Howe created GEODE-5663:
---
Summary: Flaky: LoginHandlerInterceptorJUnitTest >
testHandlerInterceptorThreadSafety
Key: GEODE-5663
URL: https://issues.apache.org/jira/browse/GEODE-5663
Project: Geode
Issue Type: Test
Components: ci
Reporter: Kenneth Howe
This test has failed in the CI Build pipeline 3 times in the last ~6 days.
{code:java}
> Task :geode-web:test
org.apache.geode.management.internal.web.controllers.support.LoginHandlerInterceptorJUnitTest
> testHandlerInterceptorThreadSafety FAILED
junit.framework.AssertionFailedError: expected:<0> but was:<3>
not all expectations were satisfied
expectations:
! expected once, never invoked:
testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameterNames();
returns
! expected once, never invoked:
testHandlerInterceptorThreadSafety.HttpServletRequest.1.getHeader("security-username");
returns "admin"
! expected once, never invoked:
testHandlerInterceptorThreadSafety.HttpServletRequest.1.getHeader("security-password");
returns "password"
! expected once, never invoked:
testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameter("vf.gf.env.STAGE");
returns "test"
! expected once, never invoked:
testHandlerInterceptorThreadSafety.HttpServletRequest.1.getParameter("vf.gf.env.GEODE_HOME");
returns "/path/to/gemfire/700"
expected once, already invoked 1 time: securityService.login(not null);
returns a default value
! expected once, never invoked: securityService.logout()
expected once, already invoked 1 time:
testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameterNames();
returns
expected once, already invoked 1 time:
testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-username");
returns "admin"
expected once, already invoked 1 time:
testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-password");
returns "password"
expected once, already invoked 1 time:
testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.HOST");
returns "localhost"
expected once, already invoked 1 time:
testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.GEODE_HOME");
returns "/path/to/gemfire/75"
! expected once, never invoked: securityService.login(not null); returns
a default value
! expected once, never invoked: securityService.logout()
what happened before this:
testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameterNames()
testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.HOST")
testHandlerInterceptorThreadSafety.HttpServletRequest.2.getParameter("vf.gf.env.GEODE_HOME")
testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-username")
testHandlerInterceptorThreadSafety.HttpServletRequest.2.getHeader("security-password")
securityService.login(<{security-username=admin,
security-password=password}>)
at
org.jmock.api.ExpectationError.notAllSatisfied(ExpectationError.java:27)
at org.jmock.Mockery.assertIsSatisfied(Mockery.java:215)
at
org.apache.geode.management.internal.web.controllers.support.LoginHandlerInterceptorJUnitTest.tearDown(LoginHandlerInterceptorJUnitTest.java:70)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5601) AcceptanceTests are run in parallel without using containers, resulting in port conflicts
[
https://issues.apache.org/jira/browse/GEODE-5601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16591786#comment-16591786
]
Kenneth Howe commented on GEODE-5601:
-
Work on containerizing {{AcceptanceTests}} is in progress on PR#2368, against
GEODE-5590 which is now tagged as a duplicate of this JIRA
> AcceptanceTests are run in parallel without using containers, resulting in
> port conflicts
> -
>
> Key: GEODE-5601
> URL: https://issues.apache.org/jira/browse/GEODE-5601
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Jacob S. Barrett
>Assignee: Kenneth Howe
>Priority: Major
> Labels: flaky, swat
>
> {noformat}
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest >
> deployLargeSetOfJars FAILED
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:117)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:135)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:106)
> at
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest.deployLargeSetOfJars(DeployWithLargeJarTest.java:41)
> {noformat}
> Passes:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/AcceptanceTest/builds/721
> Fails:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/AcceptanceTest/builds/728
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5601) AcceptanceTests are run in parallel without using containers, resulting in port conflicts
[
https://issues.apache.org/jira/browse/GEODE-5601?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16591781#comment-16591781
]
Kenneth Howe commented on GEODE-5601:
-
A bit more detail ...
Acceptance tests by design use default ports for running servers and locators,
so when tests run in parallel without the isolation of containers there are
inevitably port conflicts. Failures typically show error logs something like
{code:java}
[INFO 01:35:33.190 UTC] (cluster-setup): (2) Executing - start server
--name=server
--security-properties-file=/tmp/junit1230333947702514837/security.properties
[INFO 01:35:33.191 UTC] (cluster-setup):
[ERROR 01:35:35.320 UTC] (cluster-setup): The Cache Server process terminated
unexpectedly with exit status 1. Please refer to the log file in
/tmp/junit1230333947702514837/cluster-setup/server for full details.
[ERROR 01:35:35.321 UTC] (cluster-setup):
[ERROR 01:35:35.321 UTC] (cluster-setup): Exception in thread "main"
java.lang.RuntimeException: An IO error occurred while starting a Server in
/tmp/junit1230333947702514837/cluster-setup/server on
build-develop-acceptancetest-319.c.apachegeode-ci.internal[40404]: Network is
unreachable; port (40404) is not available on localhost.
{code}
Some of the {{AcceptanceTests}} require external services such as mysql or
postgres which are in docker containers. To avoid docker-in-docker problems CI
for these tests are not containerized.
> AcceptanceTests are run in parallel without using containers, resulting in
> port conflicts
> -
>
> Key: GEODE-5601
> URL: https://issues.apache.org/jira/browse/GEODE-5601
> Project: Geode
> Issue Type: Bug
> Components: tests
>Reporter: Jacob S. Barrett
>Assignee: Kenneth Howe
>Priority: Major
> Labels: flaky, swat
>
> {noformat}
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest >
> deployLargeSetOfJars FAILED
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:117)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:135)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:106)
> at
> org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest.deployLargeSetOfJars(DeployWithLargeJarTest.java:41)
> {noformat}
> Passes:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/AcceptanceTest/builds/721
> Fails:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/pr-develop/jobs/AcceptanceTest/builds/728
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5590) CI Failure: PutCommandWithJsonTest > putWithJsonString Fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-5590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reassigned GEODE-5590:
---
Assignee: Kenneth Howe
> CI Failure: PutCommandWithJsonTest > putWithJsonString Fails intermittently
>
>
> Key: GEODE-5590
> URL: https://issues.apache.org/jira/browse/GEODE-5590
> Project: Geode
> Issue Type: Bug
>Reporter: Helena Bales
>Assignee: Kenneth Howe
>Priority: Major
> Labels: swat
>
> {code:java}
> org.apache.geode.management.internal.cli.commands.PutCommandWithJsonTest >
> putWithJsonString FAILED
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:117)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:135)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:106)
> at
> org.apache.geode.management.internal.cli.commands.PutCommandWithJsonTest.putWithJsonString(PutCommandWithJsonTest.java:55)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GEODE-5590) CI Failure: PutCommandWithJsonTest > putWithJsonString Fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-5590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16587636#comment-16587636
]
Kenneth Howe edited comment on GEODE-5590 at 8/21/18 4:06 PM:
--
Digging in to the code from the stack trace above for
{{AbstractLauncher.assertPortAvailable}}, we do
{{server.setReuseAddress(true)}} for the port being tested. This should
eliminate a lingering TIME_WAIT state on the socket causing the failure.
Member shutdown is done on an async thread
({{MemberMBeanBridge.shutDownMember()}}, so maybe we're just starting a server
in the new test too fast for the previous shutdown to complete?
was (Author: khowe):
Digging in to the code from the stack trace above for
{{AbstractLauncher.assertPortAvailable}}, we do
{{server.setReuseAddress(true)}} for the port being tested. This should
eliminate a lingering TIME_WAIT state on the socket causing the failure.
Member shutdown is done on an async thread
({{MemberMBeanBridge.shutDownMember()}} which includes a
{{Thread.sleep(1000)}}, so maybe we're just starting a server in the new test
too fast foir the previous shutdown to complete?
> CI Failure: PutCommandWithJsonTest > putWithJsonString Fails intermittently
>
>
> Key: GEODE-5590
> URL: https://issues.apache.org/jira/browse/GEODE-5590
> Project: Geode
> Issue Type: Bug
>Reporter: Helena Bales
>Priority: Major
> Labels: swat
>
> {code:java}
> org.apache.geode.management.internal.cli.commands.PutCommandWithJsonTest >
> putWithJsonString FAILED
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:117)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:135)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:106)
> at
> org.apache.geode.management.internal.cli.commands.PutCommandWithJsonTest.putWithJsonString(PutCommandWithJsonTest.java:55)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5590) CI Failure: PutCommandWithJsonTest > putWithJsonString Fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-5590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16587636#comment-16587636
]
Kenneth Howe commented on GEODE-5590:
-
Digging in to the code from the stack trace above for
{{AbstractLauncher.assertPortAvailable}}, we do
{{server.setReuseAddress(true)}} for the port being tested. This should
eliminate a lingering TIME_WAIT state on the socket causing the failure.
Member shutdown is done on an async thread
({{MemberMBeanBridge.shutDownMember()}} which includes a
{{Thread.sleep(1000)}}, so maybe we're just starting a server in the new test
too fast foir the previous shutdown to complete?
> CI Failure: PutCommandWithJsonTest > putWithJsonString Fails intermittently
>
>
> Key: GEODE-5590
> URL: https://issues.apache.org/jira/browse/GEODE-5590
> Project: Geode
> Issue Type: Bug
>Reporter: Helena Bales
>Priority: Major
> Labels: swat
>
> {code:java}
> org.apache.geode.management.internal.cli.commands.PutCommandWithJsonTest >
> putWithJsonString FAILED
> org.junit.ComparisonFailure: expected:<[0]> but was:<[1]>
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.awaitIfNecessary(GfshScript.java:117)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshRule.execute(GfshRule.java:135)
> at
> org.apache.geode.test.junit.rules.gfsh.GfshScript.execute(GfshScript.java:106)
> at
> org.apache.geode.management.internal.cli.commands.PutCommandWithJsonTest.putWithJsonString(PutCommandWithJsonTest.java:55)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-5595) CI: DeltaPropagationDUnit.testBug40165ClientReconnects - NoSubscriptionServersAvailableException
[
https://issues.apache.org/jira/browse/GEODE-5595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16584095#comment-16584095
]
Kenneth Howe commented on GEODE-5595:
-
Not able to reproduce locally and there are limited test artifacts are
available, but this snippet from the logs may be of some help:
{code}
[info 2018/08/17 01:36:05.013 UTC tid=0x19] Running in local mode
since no locators were specified.
[info 2018/08/17 01:36:05.016 UTC tid=0x19] Initializing region
_monitoringRegion_172.17.0.110
[info 2018/08/17 01:36:05.016 UTC tid=0x19] Initialization of
region _monitoringRegion_172.17.0.110 completed
[info 2018/08/17 01:36:05.100 UTC tid=0x19] Loading previously
deployed jars
[info 2018/08/17 01:36:05.109 UTC tid=0x19] Updating membership
port. Port changed from 0 to 41,776. ID is now
2c33e0b1be22(1:loner):0:8b778645
[vm0] [info 2018/08/17 01:36:05.117 UTC
tid=0x703] :Cache server: Initializing primary server-to-client communication
socket: Socket[addr=/127.0.0.1,port=41784,localport=25231]
[vm0] [warn 2018/08/17 01:36:05.120 UTC
tid=0x703] A previous connection attempt from this client is still being
processed:
identity(172.17.0.11(1:loner):41776:8b778645,connection=1,durableAttributes=
DurableClientAttributes[id=testBug40165ClientReconnects_client; timeout=60])
[vm0] [warn 2018/08/17 01:36:05.120 UTC
tid=0x703] CacheClientNotifier: Unsuccessfully registered client with
identifier
identity(172.17.0.11(1:loner):41776:8b778645,connection=1,durableAttributes=DurableClientAttributes[id=testBug40165ClientReconnects_client;
timeout=60]) and response code 60
[warn 2018/08/17 01:36:05.121 UTC tid=0x19] Cache Client Updater
Thread on 2c33e0b1be22(366):32770 port 25231 (localhost:25231): Caught
following exception while attempting to create a server-to-client communication
socket and will exit:
org.apache.geode.cache.client.ServerRefusedConnectionException: :25231 refused connection: A previous connection attempt from this
client is still being processed:
identity(172.17.0.11(1:loner):41776:8b778645,connection=1,durableAttributes=DurableClientAttributes[id=testBug40165ClientReconnects_client;
timeout=60])
[vm0] [info 2018/08/17 01:36:05.122 UTC tid=0x709] Server connection from
[identity(172.17.0.11(1:loner):41776:8b778645,connection=1,durableAttributes=DurableClientAttributes[id=testBug40165ClientReconnects_client;
timeout=60]); port=41780]: connection disconnect detected by EOF.
[error 2018/08/17 01:36:05.122 UTC tid=0x19] Could not find any
server to create primary client queue on. Number of excluded servers is 1 and
exception is no exception.
[error 2018/08/17 01:36:05.122 UTC tid=0x19] Could not initialize
a primary queue on startup. No queue servers available.
[info 2018/08/17 01:36:05.123 UTC tid=0x19] Pool
DeltaPropagationDUnitTest started with multiuser-authentication=false
{code}
> CI: DeltaPropagationDUnit.testBug40165ClientReconnects -
> NoSubscriptionServersAvailableException
>
>
> Key: GEODE-5595
> URL: https://issues.apache.org/jira/browse/GEODE-5595
> Project: Geode
> Issue Type: Test
> Components: ci, swat
>Reporter: Kenneth Howe
>Priority: Major
>
> {code:java}
> org.apache.geode.internal.cache.DeltaPropagationDUnitTest >
> testBug40165ClientReconnects FAILED
>
> org.apache.geode.cache.NoSubscriptionServersAvailableException:
> org.apache.geode.cache.NoSubscriptionServersAvailableException: Could not
> initialize a primary queue on startup. No queue servers available.
>
> at
> org.apache.geode.cache.client.internal.QueueManagerImpl.getAllConnections(QueueManagerImpl.java:187)
>
> at
> org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnQueuesAndReturnPrimaryResult(OpExecutorImpl.java:548)
>
> at
> org.apache.geode.cache.client.internal.PoolImpl.executeOnQueuesAndReturnPrimaryResult(PoolImpl.java:855)
>
> at
> org.apache.geode.cache.client.internal.RegisterInterestOp.execute(RegisterInterestOp.java:58)
>
> at
> org.apache.geode.cache.client.internal.ServerRegionProxy.registerInterest(ServerRegionProxy.java:355)
>
> at
> org.apache.geode.internal.cache.LocalRegion.processSingleInterest(LocalRegion.java:3797)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3888)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3686)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3681)
>
> at
> org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3676)
>
> at
>
[jira] [Created] (GEODE-5595) CI: DeltaPropagationDUnit.testBug40165ClientReconnects - NoSubscriptionServersAvailableException
Kenneth Howe created GEODE-5595:
---
Summary: CI: DeltaPropagationDUnit.testBug40165ClientReconnects -
NoSubscriptionServersAvailableException
Key: GEODE-5595
URL: https://issues.apache.org/jira/browse/GEODE-5595
Project: Geode
Issue Type: Test
Components: ci, swat
Reporter: Kenneth Howe
{code:java}
org.apache.geode.internal.cache.DeltaPropagationDUnitTest >
testBug40165ClientReconnects FAILED
org.apache.geode.cache.NoSubscriptionServersAvailableException:
org.apache.geode.cache.NoSubscriptionServersAvailableException: Could not
initialize a primary queue on startup. No queue servers available.
at
org.apache.geode.cache.client.internal.QueueManagerImpl.getAllConnections(QueueManagerImpl.java:187)
at
org.apache.geode.cache.client.internal.OpExecutorImpl.executeOnQueuesAndReturnPrimaryResult(OpExecutorImpl.java:548)
at
org.apache.geode.cache.client.internal.PoolImpl.executeOnQueuesAndReturnPrimaryResult(PoolImpl.java:855)
at
org.apache.geode.cache.client.internal.RegisterInterestOp.execute(RegisterInterestOp.java:58)
at
org.apache.geode.cache.client.internal.ServerRegionProxy.registerInterest(ServerRegionProxy.java:355)
at
org.apache.geode.internal.cache.LocalRegion.processSingleInterest(LocalRegion.java:3797)
at
org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3888)
at
org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3686)
at
org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3681)
at
org.apache.geode.internal.cache.LocalRegion.registerInterest(LocalRegion.java:3676)
at
org.apache.geode.internal.cache.DeltaPropagationDUnitTest.createDurableCacheClient(DeltaPropagationDUnitTest.java:1305)
at
org.apache.geode.internal.cache.DeltaPropagationDUnitTest.testBug40165ClientReconnects(DeltaPropagationDUnitTest.java:647)
Caused by:
org.apache.geode.cache.NoSubscriptionServersAvailableException: Could
not initialize a primary queue on startup. No queue servers available.
at
org.apache.geode.cache.client.internal.QueueManagerImpl.initializeConnections(QueueManagerImpl.java:585)
at
org.apache.geode.cache.client.internal.QueueManagerImpl.start(QueueManagerImpl.java:296)
at
org.apache.geode.cache.client.internal.PoolImpl.start(PoolImpl.java:352)
at
org.apache.geode.cache.client.internal.PoolImpl.finishCreate(PoolImpl.java:176)
at
org.apache.geode.cache.client.internal.PoolImpl.create(PoolImpl.java:162)
at
org.apache.geode.internal.cache.PoolFactoryImpl.create(PoolFactoryImpl.java:349)
at
org.apache.geode.internal.cache.DeltaPropagationDUnitTest.createDurableCacheClient(DeltaPropagationDUnitTest.java:1295)
... 1 more
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (GEODE-5590) CI Failure: PutCommandWithJsonTest > putWithJsonString Fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-5590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583052#comment-16583052
]
Kenneth Howe edited comment on GEODE-5590 at 8/16/18 8:57 PM:
--
Similar failures found in recent AcceptanceTest CI failures for
{{[DeployWithLargeJarTest|http://files.apachegeode-ci.info/builds/1.8.0-build.1288/test-results/acceptanceTest/1534356362/classes/org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest.html]}}
and
{{[StopServerAcceptanceTest|http://files.apachegeode-ci.info/builds/1.8.0-build.1288/test-results/acceptanceTest/1534356362/classes/org.apache.geode.management.internal.cli.commands.StopServerAcceptanceTest.html]}}.
Examination of the console log for the failures shows that when starting the
cluster the default server port (40404) is in use.
{code:java}
[INFO 01:35:12.899 UTC] (3865e9d1bca85f4a): (2) Executing - stop server
--name=server
[INFO 01:35:12.899 UTC] (3865e9d1bca85f4a):
[INFO 01:35:14.553 UTC] (3865e9d1bca85f4a): ...
[INFO 01:35:16.362 UTC] (teardown-stop-locator):
[INFO 01:35:16.363 UTC] (teardown-stop-locator): (1) Executing - stop locator
--dir="/tmp/junit6893862426879423309/cluster-setup/locator"
[INFO 01:35:16.363 UTC] (teardown-stop-locator):
[INFO 01:35:18.540 UTC] (teardown-stop-locator): ..
[INFO 01:35:20.183 UTC] (cluster-setup):
[INFO 01:35:20.183 UTC] (cluster-setup): (1) Executing - start locator
--name=locator
--security-properties-file=/tmp/junit1230333947702514837/security.properties
[INFO 01:35:20.183 UTC] (cluster-setup):
[INFO 01:35:25.963 UTC] (cluster-setup): .
[INFO 01:35:33.189 UTC] (cluster-setup): Locator in
/tmp/junit1230333947702514837/cluster-setup/locator on
build-develop-acceptancetest-319.c.apachegeode-ci.internal[10334] as locator is
currently online.
[INFO 01:35:33.189 UTC] (cluster-setup): Process ID: 6533
[INFO 01:35:33.189 UTC] (cluster-setup): Uptime: 5 seconds
[INFO 01:35:33.189 UTC] (cluster-setup): Geode Version: 1.8.0-SNAPSHOT
[INFO 01:35:33.189 UTC] (cluster-setup): Java Version: 1.8.0_181
[INFO 01:35:33.189 UTC] (cluster-setup): Log File:
/tmp/junit1230333947702514837/cluster-setup/locator/locator.log
[INFO 01:35:33.190 UTC] (cluster-setup): JVM Arguments:
-DgemfireSecurityPropertyFile=/tmp/junit1230333947702514837/security.properties
-Dgemfire.enable-cluster-configuration=true
-Dgemfire.load-cluster-configuration-from-dir=false
-Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
-Dsun.rmi.dgc.server.gcInterval=9223372036854775806
[INFO 01:35:33.190 UTC] (cluster-setup): Class-Path:
/home/geode/geode/geode-assembly/build/install/apache-geode/lib/geode-core-1.8.0-SNAPSHOT.jar:/home/geode/geode/geode-assembly/build/install/apache-geode/lib/geode-dependencies.jar
[INFO 01:35:33.190 UTC] (cluster-setup):
[INFO 01:35:33.190 UTC] (cluster-setup): Successfully connected to: JMX
Manager [host=build-develop-acceptancetest-319.c.apachegeode-ci.internal,
port=1099]
[INFO 01:35:33.190 UTC] (cluster-setup):
[INFO 01:35:33.190 UTC] (cluster-setup): Cluster configuration service is up
and running.
[INFO 01:35:33.190 UTC] (cluster-setup):
[INFO 01:35:33.190 UTC] (cluster-setup):
[INFO 01:35:33.190 UTC] (cluster-setup): (2) Executing - start server
--name=server
--security-properties-file=/tmp/junit1230333947702514837/security.properties
[INFO 01:35:33.191 UTC] (cluster-setup):
[ERROR 01:35:35.320 UTC] (cluster-setup): The Cache Server process terminated
unexpectedly with exit status 1. Please refer to the log file in
/tmp/junit1230333947702514837/cluster-setup/server for full details.
[ERROR 01:35:35.321 UTC] (cluster-setup):
[ERROR 01:35:35.321 UTC] (cluster-setup): Exception in thread "main"
java.lang.RuntimeException: An IO error occurred while starting a Server in
/tmp/junit1230333947702514837/cluster-setup/server on
build-develop-acceptancetest-319.c.apachegeode-ci.internal[40404]: Network is
unreachable; port (40404) is not available on localhost.
[ERROR 01:35:35.321 UTC] (cluster-setup):
[ERROR 01:35:35.321 UTC] (cluster-setup): at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:816)
[ERROR 01:35:35.322 UTC] (cluster-setup):
[ERROR 01:35:35.322 UTC] (cluster-setup): at
org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:704)
[ERROR 01:35:35.322 UTC] (cluster-setup):
[ERROR 01:35:35.322 UTC] (cluster-setup): at
org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:224)
[ERROR 01:35:35.322 UTC] (cluster-setup):
[ERROR 01:35:35.322 UTC] (cluster-setup): Caused by: java.net.BindException:
Network is unreachable; port (40404) is not available on localhost.
[ERROR 01:35:35.322 UTC] (cluster-setup):
[ERROR 01:35:35.325 UTC] (cluster-setup): at
org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:129)
[jira] [Commented] (GEODE-5590) CI Failure: PutCommandWithJsonTest > putWithJsonString Fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-5590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16583052#comment-16583052
]
Kenneth Howe commented on GEODE-5590:
-
Similar failures found in recent AcceptanceTest CI failures for
{{[DeployWithLargeJarTest|http://files.apachegeode-ci.info/builds/1.8.0-build.1288/test-results/acceptanceTest/1534356362/classes/org.apache.geode.management.internal.cli.commands.DeployWithLargeJarTest.html]}}
and
{{[StopServerAcceptanceTest|http://files.apachegeode-ci.info/builds/1.8.0-build.1288/test-results/acceptanceTest/1534356362/classes/org.apache.geode.management.internal.cli.commands.StopServerAcceptanceTest.html]}}.
Examination of the console log for the failures shows that when starting the
cluster the default server port (40404) is in use.
{code:java}
[INFO 01:35:12.899 UTC] (3865e9d1bca85f4a): (2) Executing - stop server
--name=server
[INFO 01:35:12.899 UTC] (3865e9d1bca85f4a):
[INFO 01:35:14.553 UTC] (3865e9d1bca85f4a): ...
[INFO 01:35:16.362 UTC] (teardown-stop-locator):
[INFO 01:35:16.363 UTC] (teardown-stop-locator): (1) Executing - stop locator
--dir="/tmp/junit6893862426879423309/cluster-setup/locator"
[INFO 01:35:16.363 UTC] (teardown-stop-locator):
[INFO 01:35:18.540 UTC] (teardown-stop-locator): ..
[INFO 01:35:20.183 UTC] (cluster-setup):
[INFO 01:35:20.183 UTC] (cluster-setup): (1) Executing - start locator
--name=locator
--security-properties-file=/tmp/junit1230333947702514837/security.properties
[INFO 01:35:20.183 UTC] (cluster-setup):
[INFO 01:35:25.963 UTC] (cluster-setup): .
[INFO 01:35:33.189 UTC] (cluster-setup): Locator in
/tmp/junit1230333947702514837/cluster-setup/locator on
build-develop-acceptancetest-319.c.apachegeode-ci.internal[10334] as locator is
currently online.
[INFO 01:35:33.189 UTC] (cluster-setup): Process ID: 6533
[INFO 01:35:33.189 UTC] (cluster-setup): Uptime: 5 seconds
[INFO 01:35:33.189 UTC] (cluster-setup): Geode Version: 1.8.0-SNAPSHOT
[INFO 01:35:33.189 UTC] (cluster-setup): Java Version: 1.8.0_181
[INFO 01:35:33.189 UTC] (cluster-setup): Log File:
/tmp/junit1230333947702514837/cluster-setup/locator/locator.log
[INFO 01:35:33.190 UTC] (cluster-setup): JVM Arguments:
-DgemfireSecurityPropertyFile=/tmp/junit1230333947702514837/security.properties
-Dgemfire.enable-cluster-configuration=true
-Dgemfire.load-cluster-configuration-from-dir=false
-Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
-Dsun.rmi.dgc.server.gcInterval=9223372036854775806
[INFO 01:35:33.190 UTC] (cluster-setup): Class-Path:
/home/geode/geode/geode-assembly/build/install/apache-geode/lib/geode-core-1.8.0-SNAPSHOT.jar:/home/geode/geode/geode-assembly/build/install/apache-geode/lib/geode-dependencies.jar
[INFO 01:35:33.190 UTC] (cluster-setup):
[INFO 01:35:33.190 UTC] (cluster-setup): Successfully connected to: JMX
Manager [host=build-develop-acceptancetest-319.c.apachegeode-ci.internal,
port=1099]
[INFO 01:35:33.190 UTC] (cluster-setup):
[INFO 01:35:33.190 UTC] (cluster-setup): Cluster configuration service is up
and running.
[INFO 01:35:33.190 UTC] (cluster-setup):
[INFO 01:35:33.190 UTC] (cluster-setup):
[INFO 01:35:33.190 UTC] (cluster-setup): (2) Executing - start server
--name=server
--security-properties-file=/tmp/junit1230333947702514837/security.properties
[INFO 01:35:33.191 UTC] (cluster-setup):
[ERROR 01:35:35.320 UTC] (cluster-setup): The Cache Server process terminated
unexpectedly with exit status 1. Please refer to the log file in
/tmp/junit1230333947702514837/cluster-setup/server for full details.
[ERROR 01:35:35.321 UTC] (cluster-setup):
[ERROR 01:35:35.321 UTC] (cluster-setup): Exception in thread "main"
java.lang.RuntimeException: An IO error occurred while starting a Server in
/tmp/junit1230333947702514837/cluster-setup/server on
build-develop-acceptancetest-319.c.apachegeode-ci.internal[40404]: Network is
unreachable; port (40404) is not available on localhost.
[ERROR 01:35:35.321 UTC] (cluster-setup):
[ERROR 01:35:35.321 UTC] (cluster-setup): at
org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:816)
[ERROR 01:35:35.322 UTC] (cluster-setup):
[ERROR 01:35:35.322 UTC] (cluster-setup): at
org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:704)
[ERROR 01:35:35.322 UTC] (cluster-setup):
[ERROR 01:35:35.322 UTC] (cluster-setup): at
org.apache.geode.distributed.ServerLauncher.main(ServerLauncher.java:224)
[ERROR 01:35:35.322 UTC] (cluster-setup):
[ERROR 01:35:35.322 UTC] (cluster-setup): Caused by: java.net.BindException:
Network is unreachable; port (40404) is not available on localhost.
[ERROR 01:35:35.322 UTC] (cluster-setup):
[ERROR 01:35:35.325 UTC] (cluster-setup): at
org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:129)
[ERROR 01:35:35.325 UTC] (cluster-setup):
[ERROR
[jira] [Assigned] (GEODE-5581) Gfsh command extensions should not expose internal APIs
[
https://issues.apache.org/jira/browse/GEODE-5581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reassigned GEODE-5581:
---
Assignee: Kenneth Howe
> Gfsh command extensions should not expose internal APIs
> ---
>
> Key: GEODE-5581
> URL: https://issues.apache.org/jira/browse/GEODE-5581
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Affects Versions: 1.6.0
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
>
> Adding custom gfsh commands by extending the public API classes. currently
> exposes internal APIs ({{ResultModel}} and {{CliFunctionResult}})
> The example below is from one of the internal commands, but shows a typical
> implementation that may be used to write custom Gfsh commands.
> {{GfshCommand}} and {{SingleGfshCommand}} are documented as public APIs to
> make it easy to implement Geode command line extensions.
> {code:title=Command example, executing function on cluster members}
> public class CreateGatewayReceiverCommand extends SingleGfshCommand {
> ...
> public ResultModel createGatewayReceiver(@CliOption(key =
> {CliStrings.GROUP, CliStrings.GROUPS},
> ...
> List gatewayReceiverCreateResults =
> executeAndGetFunctionResult(GatewayReceiverCreateFunction.INSTANCE,
> gatewayReceiverFunctionArgs, membersToCreateGatewayReceiverOn);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-5581) Gfsh command extensions should not expose internal APIs
[
https://issues.apache.org/jira/browse/GEODE-5581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe updated GEODE-5581:
Affects Version/s: 1.6.0
> Gfsh command extensions should not expose internal APIs
> ---
>
> Key: GEODE-5581
> URL: https://issues.apache.org/jira/browse/GEODE-5581
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Affects Versions: 1.6.0
>Reporter: Kenneth Howe
>Priority: Major
>
> Adding custom gfsh commands by extending the public API classes. currently
> exposes internal APIs ({{ResultModel}} and {{CliFunctionResult}})
> The example below is from one of the internal commands, but shows a typical
> implementation that may be used to write custom Gfsh commands.
> {{GfshCommand}} and {{SingleGfshCommand}} are documented as public APIs to
> make it easy to implement Geode command line extensions.
> {code:title=Command example, executing function on cluster members}
> public class CreateGatewayReceiverCommand extends SingleGfshCommand {
> ...
> public ResultModel createGatewayReceiver(@CliOption(key =
> {CliStrings.GROUP, CliStrings.GROUPS},
> ...
> List gatewayReceiverCreateResults =
> executeAndGetFunctionResult(GatewayReceiverCreateFunction.INSTANCE,
> gatewayReceiverFunctionArgs, membersToCreateGatewayReceiverOn);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5581) Gfsh command extensions should not expose internal APIs
Kenneth Howe created GEODE-5581:
---
Summary: Gfsh command extensions should not expose internal APIs
Key: GEODE-5581
URL: https://issues.apache.org/jira/browse/GEODE-5581
Project: Geode
Issue Type: Improvement
Components: gfsh
Reporter: Kenneth Howe
Adding custom gfsh commands by extending the public API classes. currently
exposes internal APIs ({{ResultModel}} and {{CliFunctionResult}})
The example below is from one of the internal commands, but shows a typical
implementation that may be used to write custom Gfsh commands. {{GfshCommand}}
and {{SingleGfshCommand}} are documented as public APIs to make it easy to
implement Geode command line extensions.
{code:title=Command example, executing function on cluster members}
public class CreateGatewayReceiverCommand extends SingleGfshCommand {
...
public ResultModel createGatewayReceiver(@CliOption(key = {CliStrings.GROUP,
CliStrings.GROUPS},
...
List gatewayReceiverCreateResults =
executeAndGetFunctionResult(GatewayReceiverCreateFunction.INSTANCE,
gatewayReceiverFunctionArgs, membersToCreateGatewayReceiverOn);
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5558) DistributedLockServiceDUnitTest.testGrantTokenCleanup should not return early
[ https://issues.apache.org/jira/browse/GEODE-5558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenneth Howe reassigned GEODE-5558: --- Assignee: Kenneth Howe > DistributedLockServiceDUnitTest.testGrantTokenCleanup should not return early > - > > Key: GEODE-5558 > URL: https://issues.apache.org/jira/browse/GEODE-5558 > Project: Geode > Issue Type: Task > Components: distributed lock service, tests >Reporter: Galen O'Sullivan >Assignee: Kenneth Howe >Priority: Major > > This test is marked with a TODO to finish the test after an ancient > (pre-Geode) bug is fixed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5513) Clients may miss PR region events due to race during registerInterest
[ https://issues.apache.org/jira/browse/GEODE-5513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenneth Howe updated GEODE-5513: Affects Version/s: 1.6.0 > Clients may miss PR region events due to race during registerInterest > - > > Key: GEODE-5513 > URL: https://issues.apache.org/jira/browse/GEODE-5513 > Project: Geode > Issue Type: Bug > Components: client queues >Affects Versions: 1.6.0 >Reporter: Kenneth Howe >Assignee: Kenneth Howe >Priority: Major > > Here is the scenario: > Consider two servers and client: > - Server1 hosting the primary bucket > - Server2 hosting secondary bucket and also primary queue for the Client2 > - Client1 Doing remove operation > - Client2 doing register interest > - The Client1 starts remove-all operation > - At the same time Client2 is registering interest > - Server1 receives the remove-all operation processes it, and sends the > adjunct message to the Server2 (Its still not yet received the interest info > from server1) > - While the remove-all to server2 in flight > - Server2 sends interest profile info to Server1 for client2; and then > Server2 (as it is hosting the primary queue) starts building the initial > image snapshot for the interest. When building initial image for PR > preference is given to collect data from local node. During this time the > removal message is still in flight and hasn't applied on Server2. The initial > image for interest registration calculates the snapshot from local data, and > sends it to client, missing the remove-all op. > This could happen with non-bulk ops; but it gets worse with bulk ops as the > time taken to replicate the bulk ops will take more time. > The solution is to build the initial register interest response by getting > the data from primary bucket. This will add little overhead in building the > interest response; but considering that most or always the register response > will involve remote node, this may be negligible. > Clients registering interest in a region -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-5513) Clients may miss PR region events due to race during registerInterest
[ https://issues.apache.org/jira/browse/GEODE-5513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenneth Howe reassigned GEODE-5513: --- Assignee: Kenneth Howe > Clients may miss PR region events due to race during registerInterest > - > > Key: GEODE-5513 > URL: https://issues.apache.org/jira/browse/GEODE-5513 > Project: Geode > Issue Type: Bug > Components: client queues >Reporter: Kenneth Howe >Assignee: Kenneth Howe >Priority: Major > > Here is the scenario: > Consider two servers and client: > - Server1 hosting the primary bucket > - Server2 hosting secondary bucket and also primary queue for the Client2 > - Client1 Doing remove operation > - Client2 doing register interest > - The Client1 starts remove-all operation > - At the same time Client2 is registering interest > - Server1 receives the remove-all operation processes it, and sends the > adjunct message to the Server2 (Its still not yet received the interest info > from server1) > - While the remove-all to server2 in flight > - Server2 sends interest profile info to Server1 for client2; and then > Server2 (as it is hosting the primary queue) starts building the initial > image snapshot for the interest. When building initial image for PR > preference is given to collect data from local node. During this time the > removal message is still in flight and hasn't applied on Server2. The initial > image for interest registration calculates the snapshot from local data, and > sends it to client, missing the remove-all op. > This could happen with non-bulk ops; but it gets worse with bulk ops as the > time taken to replicate the bulk ops will take more time. > The solution is to build the initial register interest response by getting > the data from primary bucket. This will add little overhead in building the > interest response; but considering that most or always the register response > will involve remote node, this may be negligible. > Clients registering interest in a region -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-5513) Clients may miss PR region events due to race during registerInterest
Kenneth Howe created GEODE-5513: --- Summary: Clients may miss PR region events due to race during registerInterest Key: GEODE-5513 URL: https://issues.apache.org/jira/browse/GEODE-5513 Project: Geode Issue Type: Bug Components: client queues Reporter: Kenneth Howe Here is the scenario: Consider two servers and client: - Server1 hosting the primary bucket - Server2 hosting secondary bucket and also primary queue for the Client2 - Client1 Doing remove operation - Client2 doing register interest - The Client1 starts remove-all operation - At the same time Client2 is registering interest - Server1 receives the remove-all operation processes it, and sends the adjunct message to the Server2 (Its still not yet received the interest info from server1) - While the remove-all to server2 in flight - Server2 sends interest profile info to Server1 for client2; and then Server2 (as it is hosting the primary queue) starts building the initial image snapshot for the interest. When building initial image for PR preference is given to collect data from local node. During this time the removal message is still in flight and hasn't applied on Server2. The initial image for interest registration calculates the snapshot from local data, and sends it to client, missing the remove-all op. This could happen with non-bulk ops; but it gets worse with bulk ops as the time taken to replicate the bulk ops will take more time. The solution is to build the initial register interest response by getting the data from primary bucket. This will add little overhead in building the interest response; but considering that most or always the register response will involve remote node, this may be negligible. Clients registering interest in a region -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-5455) ClassCastException in MemberMBean.showOSMetrics, OSMetrics is not reconstructible from CompositeData
[
https://issues.apache.org/jira/browse/GEODE-5455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe updated GEODE-5455:
Affects Version/s: 1.4.0
> ClassCastException in MemberMBean.showOSMetrics, OSMetrics is not
> reconstructible from CompositeData
>
>
> Key: GEODE-5455
> URL: https://issues.apache.org/jira/browse/GEODE-5455
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Affects Versions: 1.4.0
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
>
> The following code snippet throws
> {code}
> Exception in thread "main" java.lang.ClassCastException:
> javax.management.openmbean.CompositeDataSupport cannot be cast to
> org.apache.geode.management.OSMetrics at
> com.sun.proxy.$Proxy0.showOSMetrics(Unknown Source)
> {code}
> {code:java}
> public static MBeanServerConnection getLocalMBeanServerConnectionStatic(int
> pid) {
> try {
> String address = ConnectorAddressLink.importFrom(pid);
> JMXServiceURL jmxUrl = new JMXServiceURL(address);
> return JMXConnectorFactory.connect(jmxUrl).getMBeanServerConnection();
> } catch (IOException e) {
> throw new RuntimeException(
> "Of course you still have to implement a good connection handling");
> }
> }
> public static void main(String[] args) throws IOException,
> MalformedObjectNameException, InstanceNotFoundException,
> ReflectionException {
> MBeanServerConnection mbeanServerConnection =
> getLocalMBeanServerConnectionStatic(127510);
> ObjectName mbeanName = new
> ObjectName("GemFire:type=Member,member=server1");
> MemberMXBean
> memberbeanInstance =
> (MemberMXBean) MBeanServerInvocationHandler
> .newProxyInstance(mbeanServerConnection, mbeanName,
> MemberMXBean.class, Boolean.TRUE);
> System.out.println(Arrays.toString(memberbeanInstance.listRegions()));
> OSMetrics cdOSMetrics = memberbeanInstance.showOSMetrics();
> //.
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5455) ClassCastException in MemberMBean.showOSMetrics, OSMetrics is not reconstructible from CompositeData
Kenneth Howe created GEODE-5455:
---
Summary: ClassCastException in MemberMBean.showOSMetrics,
OSMetrics is not reconstructible from CompositeData
Key: GEODE-5455
URL: https://issues.apache.org/jira/browse/GEODE-5455
Project: Geode
Issue Type: Bug
Components: jmx
Reporter: Kenneth Howe
The following code snippet throws
{code}
Exception in thread "main" java.lang.ClassCastException:
javax.management.openmbean.CompositeDataSupport cannot be cast to
org.apache.geode.management.OSMetrics at
com.sun.proxy.$Proxy0.showOSMetrics(Unknown Source)
{code}
{code:java}
public static MBeanServerConnection getLocalMBeanServerConnectionStatic(int
pid) {
try {
String address = ConnectorAddressLink.importFrom(pid);
JMXServiceURL jmxUrl = new JMXServiceURL(address);
return JMXConnectorFactory.connect(jmxUrl).getMBeanServerConnection();
} catch (IOException e) {
throw new RuntimeException(
"Of course you still have to implement a good connection handling");
}
}
public static void main(String[] args) throws IOException,
MalformedObjectNameException, InstanceNotFoundException,
ReflectionException {
MBeanServerConnection mbeanServerConnection =
getLocalMBeanServerConnectionStatic(127510);
ObjectName mbeanName = new ObjectName("GemFire:type=Member,member=server1");
MemberMXBean
memberbeanInstance =
(MemberMXBean) MBeanServerInvocationHandler
.newProxyInstance(mbeanServerConnection, mbeanName,
MemberMXBean.class, Boolean.TRUE);
System.out.println(Arrays.toString(memberbeanInstance.listRegions()));
OSMetrics cdOSMetrics = memberbeanInstance.showOSMetrics();
//.
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5455) ClassCastException in MemberMBean.showOSMetrics, OSMetrics is not reconstructible from CompositeData
[
https://issues.apache.org/jira/browse/GEODE-5455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reassigned GEODE-5455:
---
Assignee: Kenneth Howe
> ClassCastException in MemberMBean.showOSMetrics, OSMetrics is not
> reconstructible from CompositeData
>
>
> Key: GEODE-5455
> URL: https://issues.apache.org/jira/browse/GEODE-5455
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Affects Versions: 1.4.0
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
>
> The following code snippet throws
> {code}
> Exception in thread "main" java.lang.ClassCastException:
> javax.management.openmbean.CompositeDataSupport cannot be cast to
> org.apache.geode.management.OSMetrics at
> com.sun.proxy.$Proxy0.showOSMetrics(Unknown Source)
> {code}
> {code:java}
> public static MBeanServerConnection getLocalMBeanServerConnectionStatic(int
> pid) {
> try {
> String address = ConnectorAddressLink.importFrom(pid);
> JMXServiceURL jmxUrl = new JMXServiceURL(address);
> return JMXConnectorFactory.connect(jmxUrl).getMBeanServerConnection();
> } catch (IOException e) {
> throw new RuntimeException(
> "Of course you still have to implement a good connection handling");
> }
> }
> public static void main(String[] args) throws IOException,
> MalformedObjectNameException, InstanceNotFoundException,
> ReflectionException {
> MBeanServerConnection mbeanServerConnection =
> getLocalMBeanServerConnectionStatic(127510);
> ObjectName mbeanName = new
> ObjectName("GemFire:type=Member,member=server1");
> MemberMXBean
> memberbeanInstance =
> (MemberMXBean) MBeanServerInvocationHandler
> .newProxyInstance(mbeanServerConnection, mbeanName,
> MemberMXBean.class, Boolean.TRUE);
> System.out.println(Arrays.toString(memberbeanInstance.listRegions()));
> OSMetrics cdOSMetrics = memberbeanInstance.showOSMetrics();
> //.
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5281) Race between registering and unregistering CustomMXBeans in concurrent thread may result in NPE
[
https://issues.apache.org/jira/browse/GEODE-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe resolved GEODE-5281.
-
Resolution: Fixed
Fix Version/s: 1.8.0
> Race between registering and unregistering CustomMXBeans in concurrent thread
> may result in NPE
> ---
>
> Key: GEODE-5281
> URL: https://issues.apache.org/jira/browse/GEODE-5281
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Affects Versions: 1.0.0-incubating
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.8.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Stack trace from an example of the unexpected NullPointerException in
> {{MBeanProxyFactory.createProxy()}}
> {code:java}
> [warning 2018/02/03 17:32:13.561 UTC
> managing_1_gemfire2_79a23c4a-f5e3-4c9f-6455-149c397ce13c_38199
> tid=0x5e] Create Proxy failed for
> GemFire:type=CustomMXBean213,member=locator_managing_gemfire1_79a23c4a-f5e3-4c9f-6455-149c397ce13c_37116
> with exception null
> java.lang.NullPointerException
> at
> org.apache.geode.management.internal.MBeanProxyFactory.createProxy(MBeanProxyFactory.java:83)
> at
> org.apache.geode.management.internal.MBeanProxyFactory.createAllProxies(MBeanProxyFactory.java:137)
> at
> org.apache.geode.management.internal.FederatingManager$GIITask.call(FederatingManager.java:457)
> at
> org.apache.geode.management.internal.FederatingManager$GIITask.call(FederatingManager.java:341)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> {code}
> The registering thread enters
> {code}
> public void createProxy(DistributedMember member, ObjectName objectName,
> Region monitoringRegion, Object newVal) {
> {code}
> with the {{objectName}} existing in the {{_monitoringRegion}}. A few lines
> further the entry is retrieved from the region, but is now {{null}} due to it
> being removed by the unregistering thread.
> {code}
> String name = objectName.toString();
> FederationComponent federationComponent = (FederationComponent)
> monitoringRegion.get(name);
> String interfaceClassName =
> federationComponent.getMBeanInterfaceClass();
> {code}
> {{federationComponent == null}} results in the NPE.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-5333) Failed connection objects may be retained indefinitely - can lead to OutOfMemoryError
[
https://issues.apache.org/jira/browse/GEODE-5333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe resolved GEODE-5333.
-
Resolution: Fixed
Fix Version/s: 1.8.0
commit 13087e2a23983ea43f5406512e9eef1fae1876c0 (HEAD -> develop,
origin/develop)
Author: Kenneth Howe
Date: Thu Jun 21 09:04:41 2018 -0700
GEODE-5333: Destroy failed connection in ConnectionConnector (#2072)
> Failed connection objects may be retained indefinitely - can lead to
> OutOfMemoryError
> --
>
> Key: GEODE-5333
> URL: https://issues.apache.org/jira/browse/GEODE-5333
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.7.0
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
> Labels: pull-request-available, regression
> Fix For: 1.8.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> After refactoring of {{ConnectionFactoryImpl}} and {{ConnectionConnector}}
> (GEODE-5261), connections that fail during connect due to an execption (for
> example, {{GemfireSecurityException}}) are not destroyed
> ({{connection.destroy()}}).
> Prior to refactoring, the {{connect()}} was performed in a try/catch/finally
> in {{ConnectionFactoryImpl.createClientToServerConnection()}}
> {code:java}
> public Connection createClientToServerConnection(ServerLocation location,
> boolean forQueue)
> throws GemFireSecurityException {
> ConnectionImpl connection = new ConnectionImpl(this.ds,
> this.cancelCriterion);
> ...
> try {
> ClientSideHandshake connHandShake = new
> ClientSideHandshakeImpl(handshake);
> connection.connect(endpointManager, location, connHandShake,
> socketBufferSize,
> handshakeTimeout, readTimeout, getCommMode(forQueue),
> this.gatewaySender,
> this.socketCreator);
> ...
> } catch (... e) {
> throw e;
> ...
> } finally {
> if (!initialized) {
> connection.destroy();
> failureTracker.addFailure();
> connection = null;
> }
> }
> {code}
> After the refactoring, the connect is performed in
> {{ConnectionConnector.connectClientToServer}}. If {{connect()}} throws an
> exception back to the {{ConnectionFactoryImpl}}, the connection object in
> {{ConnectionConnector}} isn't destroyed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5333) Failed connection objects may be retained indefinitely - can lead to OutOfMemoryError
[
https://issues.apache.org/jira/browse/GEODE-5333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reassigned GEODE-5333:
---
Assignee: Kenneth Howe
Affects Version/s: 1.7.0
Labels: regression (was: )
Component/s: client/server
> Failed connection objects may be retained indefinitely - can lead to
> OutOfMemoryError
> --
>
> Key: GEODE-5333
> URL: https://issues.apache.org/jira/browse/GEODE-5333
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Affects Versions: 1.7.0
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
> Labels: regression
>
> After refactoring of {{ConnectionFactoryImpl}} and {{ConnectionConnector}}
> (GEODE-5261), connections that fail during connect due to an execption (for
> example, {{GemfireSecurityException}}) are not destroyed
> ({{connection.destroy()}}).
> Prior to refactoring, the {{connect()}} was performed in a try/catch/finally
> in {{ConnectionFactoryImpl.createClientToServerConnection()}}
> {code:java}
> public Connection createClientToServerConnection(ServerLocation location,
> boolean forQueue)
> throws GemFireSecurityException {
> ConnectionImpl connection = new ConnectionImpl(this.ds,
> this.cancelCriterion);
> ...
> try {
> ClientSideHandshake connHandShake = new
> ClientSideHandshakeImpl(handshake);
> connection.connect(endpointManager, location, connHandShake,
> socketBufferSize,
> handshakeTimeout, readTimeout, getCommMode(forQueue),
> this.gatewaySender,
> this.socketCreator);
> ...
> } catch (... e) {
> throw e;
> ...
> } finally {
> if (!initialized) {
> connection.destroy();
> failureTracker.addFailure();
> connection = null;
> }
> }
> {code}
> After the refactoring, the connect is performed in
> {{ConnectionConnector.connectClientToServer}}. If {{connect()}} throws an
> exception back to the {{ConnectionFactoryImpl}}, the connection object in
> {{ConnectionConnector}} isn't destroyed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5333) Failed connection objects may be retained indefinitely - can lead to OutOfMemoryError
Kenneth Howe created GEODE-5333:
---
Summary: Failed connection objects may be retained indefinitely -
can lead to OutOfMemoryError
Key: GEODE-5333
URL: https://issues.apache.org/jira/browse/GEODE-5333
Project: Geode
Issue Type: Bug
Reporter: Kenneth Howe
After refactoring of {{ConnectionFactoryImpl}} and {{ConnectionConnector}}
(GEODE-5261), connections that fail during connect due to an execption (for
example, {{GemfireSecurityException}}) are not destroyed
({{connection.destroy()}}).
Prior to refactoring, the {{connect()}} was performed in a try/catch/finally in
{{ConnectionFactoryImpl.createClientToServerConnection()}}
{code:java}
public Connection createClientToServerConnection(ServerLocation location,
boolean forQueue)
throws GemFireSecurityException {
ConnectionImpl connection = new ConnectionImpl(this.ds,
this.cancelCriterion);
...
try {
ClientSideHandshake connHandShake = new
ClientSideHandshakeImpl(handshake);
connection.connect(endpointManager, location, connHandShake,
socketBufferSize,
handshakeTimeout, readTimeout, getCommMode(forQueue),
this.gatewaySender,
this.socketCreator);
...
} catch (... e) {
throw e;
...
} finally {
if (!initialized) {
connection.destroy();
failureTracker.addFailure();
connection = null;
}
}
{code}
After the refactoring, the connect is performed in
{{ConnectionConnector.connectClientToServer}}. If {{connect()}} throws an
exception back to the {{ConnectionFactoryImpl}}, the connection object in
{{ConnectionConnector}} isn't destroyed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-5281) Race between registering and unregistering CustomMXBeans in concurrent thread may result in NPE
[
https://issues.apache.org/jira/browse/GEODE-5281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reassigned GEODE-5281:
---
Assignee: Kenneth Howe
Affects Version/s: 1.0.0-incubating
Issue Type: Bug (was: Improvement)
> Race between registering and unregistering CustomMXBeans in concurrent thread
> may result in NPE
> ---
>
> Key: GEODE-5281
> URL: https://issues.apache.org/jira/browse/GEODE-5281
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Affects Versions: 1.0.0-incubating
>Reporter: Kenneth Howe
>Assignee: Kenneth Howe
>Priority: Major
>
> Stack trace from an example of the unexpected NullPointerException in
> {{MBeanProxyFactory.createProxy()}}
> {code:java}
> [warning 2018/02/03 17:32:13.561 UTC
> managing_1_gemfire2_79a23c4a-f5e3-4c9f-6455-149c397ce13c_38199
> tid=0x5e] Create Proxy failed for
> GemFire:type=CustomMXBean213,member=locator_managing_gemfire1_79a23c4a-f5e3-4c9f-6455-149c397ce13c_37116
> with exception null
> java.lang.NullPointerException
> at
> org.apache.geode.management.internal.MBeanProxyFactory.createProxy(MBeanProxyFactory.java:83)
> at
> org.apache.geode.management.internal.MBeanProxyFactory.createAllProxies(MBeanProxyFactory.java:137)
> at
> org.apache.geode.management.internal.FederatingManager$GIITask.call(FederatingManager.java:457)
> at
> org.apache.geode.management.internal.FederatingManager$GIITask.call(FederatingManager.java:341)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> {code}
> The registering thread enters
> {code}
> public void createProxy(DistributedMember member, ObjectName objectName,
> Region monitoringRegion, Object newVal) {
> {code}
> with the {{objectName}} existing in the {{_monitoringRegion}}. A few lines
> further the entry is retrieved from the region, but is now {{null}} due to it
> being removed by the unregistering thread.
> {code}
> String name = objectName.toString();
> FederationComponent federationComponent = (FederationComponent)
> monitoringRegion.get(name);
> String interfaceClassName =
> federationComponent.getMBeanInterfaceClass();
> {code}
> {{federationComponent == null}} results in the NPE.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5281) Race between registering and unregistering CustomMXBeans in concurrent thread may result in NPE
Kenneth Howe created GEODE-5281:
---
Summary: Race between registering and unregistering CustomMXBeans
in concurrent thread may result in NPE
Key: GEODE-5281
URL: https://issues.apache.org/jira/browse/GEODE-5281
Project: Geode
Issue Type: Improvement
Components: jmx
Reporter: Kenneth Howe
Stack trace from an example of the unexpected NullPointerException in
{{MBeanProxyFactory.createProxy()}}
{code:java}
[warning 2018/02/03 17:32:13.561 UTC
managing_1_gemfire2_79a23c4a-f5e3-4c9f-6455-149c397ce13c_38199
tid=0x5e] Create Proxy failed for
GemFire:type=CustomMXBean213,member=locator_managing_gemfire1_79a23c4a-f5e3-4c9f-6455-149c397ce13c_37116
with exception null
java.lang.NullPointerException
at
org.apache.geode.management.internal.MBeanProxyFactory.createProxy(MBeanProxyFactory.java:83)
at
org.apache.geode.management.internal.MBeanProxyFactory.createAllProxies(MBeanProxyFactory.java:137)
at
org.apache.geode.management.internal.FederatingManager$GIITask.call(FederatingManager.java:457)
at
org.apache.geode.management.internal.FederatingManager$GIITask.call(FederatingManager.java:341)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
{code}
The registering thread enters
{code}
public void createProxy(DistributedMember member, ObjectName objectName,
Region monitoringRegion, Object newVal) {
{code}
with the {{objectName}} existing in the {{_monitoringRegion}}. A few lines
further the entry is retrieved from the region, but is now {{null}} due to it
being removed by the unregistering thread.
{code}
String name = objectName.toString();
FederationComponent federationComponent = (FederationComponent)
monitoringRegion.get(name);
String interfaceClassName = federationComponent.getMBeanInterfaceClass();
{code}
{{federationComponent == null}} results in the NPE.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-5194) Relax Gfsh version checking on connect, allow connecting to different patch versions
Kenneth Howe created GEODE-5194:
---
Summary: Relax Gfsh version checking on connect, allow connecting
to different patch versions
Key: GEODE-5194
URL: https://issues.apache.org/jira/browse/GEODE-5194
Project: Geode
Issue Type: Improvement
Components: gfsh
Reporter: Kenneth Howe
Currently Gfsh, {{connect}} command will only connect to locator with the same
exact version. Patch versions should not add or change functionality of
commands, so for Gfsh version {{x.y.z}} connection to locator with same major
and minor, {{x.y}}, version with a different patch, {{.z}}, should be allowed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-2668) Add gfsh command to destroy gateway receiver
[
https://issues.apache.org/jira/browse/GEODE-2668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reassigned GEODE-2668:
---
Assignee: Kenneth Howe
> Add gfsh command to destroy gateway receiver
>
>
> Key: GEODE-2668
> URL: https://issues.apache.org/jira/browse/GEODE-2668
> Project: Geode
> Issue Type: Sub-task
> Components: docs, gfsh
>Reporter: Swapnil Bawaskar
>Assignee: Kenneth Howe
>Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Currently, there is a {{create gateway-receiver}} command, but no
> corresponding destroy command.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-3096) Refactor and unify GFSH http clients
[ https://issues.apache.org/jira/browse/GEODE-3096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenneth Howe resolved GEODE-3096. - Resolution: Fixed > Refactor and unify GFSH http clients > > > Key: GEODE-3096 > URL: https://issues.apache.org/jira/browse/GEODE-3096 > Project: Geode > Issue Type: Improvement > Components: gfsh, management >Reporter: Jared Stewart >Assignee: Jared Stewart >Priority: Major > > We currently have at least two separate HTTP clients used by GFSH over HTTP. > (See SimpleHttpRequester, AbstractHttpOperationInvoker, > RestHttpOperationInvoker, SimpleHttpOperationInvoker). This results in a lot > of duplicated and inconsistent logic. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-3096) Refactor and unify GFSH http clients
[ https://issues.apache.org/jira/browse/GEODE-3096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenneth Howe closed GEODE-3096. --- > Refactor and unify GFSH http clients > > > Key: GEODE-3096 > URL: https://issues.apache.org/jira/browse/GEODE-3096 > Project: Geode > Issue Type: Improvement > Components: gfsh, management >Reporter: Jared Stewart >Assignee: Jared Stewart >Priority: Major > > We currently have at least two separate HTTP clients used by GFSH over HTTP. > (See SimpleHttpRequester, AbstractHttpOperationInvoker, > RestHttpOperationInvoker, SimpleHttpOperationInvoker). This results in a lot > of duplicated and inconsistent logic. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3946) Attempting to connect an older version gfsh to a newer version JMX manager should fail
[
https://issues.apache.org/jira/browse/GEODE-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe resolved GEODE-3946.
-
Resolution: Fixed
> Attempting to connect an older version gfsh to a newer version JMX manager
> should fail
> --
>
> Key: GEODE-3946
> URL: https://issues.apache.org/jira/browse/GEODE-3946
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Barry Oglesby
>Assignee: Kenneth Howe
>Priority: Trivial
>
> Currently, an older version of gfsh can connect to a newer version JMX
> manager, but when a command is invoked, it'll fail with a cryptic message.
> An example is:
> 9.1.1 JMX manager
> 9.0.3 gfsh
> Attempting to execute a query with this scenario logs a 'Could not parse
> command string' message:
> {noformat}
> gfsh>query --query='SELECT sauce FROM /data' --interactive=true
> Could not parse command string. query --query='SELECT sauce FROM /data'
> --interactive=true --step-name=SELECT_EXEC
> {noformat}
> Instead, gfsh should fail at connect time with an
> {{IncompatibleVersionException}} or something similar.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-3946) Attempting to connect an older version gfsh to a newer version JMX manager should fail
[
https://issues.apache.org/jira/browse/GEODE-3946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe closed GEODE-3946.
---
> Attempting to connect an older version gfsh to a newer version JMX manager
> should fail
> --
>
> Key: GEODE-3946
> URL: https://issues.apache.org/jira/browse/GEODE-3946
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Barry Oglesby
>Assignee: Kenneth Howe
>Priority: Trivial
>
> Currently, an older version of gfsh can connect to a newer version JMX
> manager, but when a command is invoked, it'll fail with a cryptic message.
> An example is:
> 9.1.1 JMX manager
> 9.0.3 gfsh
> Attempting to execute a query with this scenario logs a 'Could not parse
> command string' message:
> {noformat}
> gfsh>query --query='SELECT sauce FROM /data' --interactive=true
> Could not parse command string. query --query='SELECT sauce FROM /data'
> --interactive=true --step-name=SELECT_EXEC
> {noformat}
> Instead, gfsh should fail at connect time with an
> {{IncompatibleVersionException}} or something similar.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-2984) Gfsh command error handling should use exceptions rather than status returns
[ https://issues.apache.org/jira/browse/GEODE-2984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenneth Howe resolved GEODE-2984. - Resolution: Not A Problem > Gfsh command error handling should use exceptions rather than status returns > > > Key: GEODE-2984 > URL: https://issues.apache.org/jira/browse/GEODE-2984 > Project: Geode > Issue Type: Task > Components: gfsh >Reporter: Jared Stewart >Assignee: Kenneth Howe >Priority: Major > > Currently, a given gfsh command either returns an InfoResultData (in the > happy case) or an ErrorResultData (in the exceptional case). This requires > putting error handling code inside of *each* command separately. It would > be far better to instead allow gfsh commands throw an exception, and to have > GfshExecutionStrategy (or somewhere similar) handle wrapping up any exception > into an ErrorResultData in a generic fashion. > It may also be worth looking at the built-in mechanism in Spring Shell for > this strategy (see afterThrowingInvocation): > http://docs.spring.io/autorepo/docs/spring-shell/1.2.0.M1/api/org/springframework/shell/core/ExecutionProcessor.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-2984) Gfsh command error handling should use exceptions rather than status returns
[ https://issues.apache.org/jira/browse/GEODE-2984?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenneth Howe closed GEODE-2984. --- > Gfsh command error handling should use exceptions rather than status returns > > > Key: GEODE-2984 > URL: https://issues.apache.org/jira/browse/GEODE-2984 > Project: Geode > Issue Type: Task > Components: gfsh >Reporter: Jared Stewart >Assignee: Kenneth Howe >Priority: Major > > Currently, a given gfsh command either returns an InfoResultData (in the > happy case) or an ErrorResultData (in the exceptional case). This requires > putting error handling code inside of *each* command separately. It would > be far better to instead allow gfsh commands throw an exception, and to have > GfshExecutionStrategy (or somewhere similar) handle wrapping up any exception > into an ErrorResultData in a generic fashion. > It may also be worth looking at the built-in mechanism in Spring Shell for > this strategy (see afterThrowingInvocation): > http://docs.spring.io/autorepo/docs/spring-shell/1.2.0.M1/api/org/springframework/shell/core/ExecutionProcessor.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-2981) Fix the line feed code of the test expected value
[ https://issues.apache.org/jira/browse/GEODE-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenneth Howe closed GEODE-2981. --- > Fix the line feed code of the test expected value > - > > Key: GEODE-2981 > URL: https://issues.apache.org/jira/browse/GEODE-2981 > Project: Geode > Issue Type: Test > Components: management, tests >Reporter: Masaki Yamakawa >Assignee: Jinmei Liao >Priority: Minor > > I mainly use the Windows. When I run the test on Windows, because Assertion > fails due to the difference in line feed code, I want to change this so that > it does not depend on the runtime environment. > The target classes are as follows: > - org.apache.geode.management.internal.cli.shell.GfshJunitTest > - org.apache.geode.management.internal.cli.help.HelpBlockUnitTest > - org.apache.geode.management.internal.cli.help.HelperUnitTest -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-2981) Fix the line feed code of the test expected value
[ https://issues.apache.org/jira/browse/GEODE-2981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenneth Howe resolved GEODE-2981. - Resolution: Fixed > Fix the line feed code of the test expected value > - > > Key: GEODE-2981 > URL: https://issues.apache.org/jira/browse/GEODE-2981 > Project: Geode > Issue Type: Test > Components: management, tests >Reporter: Masaki Yamakawa >Assignee: Jinmei Liao >Priority: Minor > > I mainly use the Windows. When I run the test on Windows, because Assertion > fails due to the difference in line feed code, I want to change this so that > it does not depend on the runtime environment. > The target classes are as follows: > - org.apache.geode.management.internal.cli.shell.GfshJunitTest > - org.apache.geode.management.internal.cli.help.HelpBlockUnitTest > - org.apache.geode.management.internal.cli.help.HelperUnitTest -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4936) Update version dependency for jackson-databind
[ https://issues.apache.org/jira/browse/GEODE-4936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kenneth Howe resolved GEODE-4936. - Resolution: Duplicate Fix Version/s: 1.6.0 > Update version dependency for jackson-databind > -- > > Key: GEODE-4936 > URL: https://issues.apache.org/jira/browse/GEODE-4936 > Project: Geode > Issue Type: Bug > Components: build, pulse >Affects Versions: 1.5.0 >Reporter: Kenneth Howe >Priority: Major > Fix For: 1.6.0 > > > jackson-databind version 2.9.5 fixes an incomplete fix in version 2.9.4 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4915) ClusterConfigLocatorRestartDUnitTest fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-4915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe resolved GEODE-4915.
-
Resolution: Fixed
> ClusterConfigLocatorRestartDUnitTest fails intermittently
> -
>
> Key: GEODE-4915
> URL: https://issues.apache.org/jira/browse/GEODE-4915
> Project: Geode
> Issue Type: Bug
> Components: configuration, gfsh
>Reporter: Jens Deppe
>Assignee: Kenneth Howe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.6.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> This test has timing issues and needs to be more robust.
> Adding test name and failure details from
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/254
> {noformat}
> org.apache.geode.management.internal.configuration.ClusterConfigLocatorRestartDUnitTest
> > serverRestartsAfterLocatorReconnects 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 1217
> [fatal 2018/04/06 05:00:39.119 UTC 172.17.0.7(server-2:182):32772 shared unordered uid=10 port=37516>
> tid=0x65] Uncaught exception in thread Thread[P2P message reader for
> 172.17.0.7(server-2:182):32772 shared unordered uid=10 port=37516,10,P2P
> Reader Threads]
> org.apache.geode.distributed.DistributedSystemDisconnectedException:
> org.apache.geode.ForcedDisconnectException: for testing
> at
> org.apache.geode.distributed.internal.membership.gms.Services$Stopper.generateCancelledException(Services.java:402)
> at
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.remove(GMSJoinLeave.java:1645)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.inlineCheckIfAvailable(GMSHealthMonitor.java:1328)
> at
> org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.checkIfAvailable(GMSHealthMonitor.java:616)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.verifyMember(GMSMembershipManager.java:1674)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.suspectMember(GMSMembershipManager.java:1657)
> at
> org.apache.geode.internal.tcp.Connection.initiateSuspicionIfSharedUnordered(Connection.java:1917)
> at org.apache.geode.internal.tcp.Connection.run(Connection.java:1697)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Reopened] (GEODE-4915) ClusterConfigLocatorRestartDUnitTest fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-4915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe reopened GEODE-4915:
-
Assignee: Kenneth Howe (was: Jens Deppe)
Test failed in CI pipeline with:
{code:java}
[fatal 2018/04/06 05:00:39.119 UTC :32772 shared unordered uid=10 port=37516>
tid=0x65] Uncaught exception in thread Thread[P2P message reader for
172.17.0.7(server-2:182):32772 shared unordered uid=10 port=37516,10,P2P
Reader Threads]
org.apache.geode.distributed.DistributedSystemDisconnectedException:
org.apache.geode.ForcedDisconnectException: for testing
at
org.apache.geode.distributed.internal.membership.gms.Services$Stopper.generateCancelledException(Services.java:402)
at
org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
at
org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.remove(GMSJoinLeave.java:1645)
at
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.inlineCheckIfAvailable(GMSHealthMonitor.java:1328)
at
org.apache.geode.distributed.internal.membership.gms.fd.GMSHealthMonitor.checkIfAvailable(GMSHealthMonitor.java:616)
at
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.verifyMember(GMSMembershipManager.java:1674)
at
org.apache.geode.distributed.internal.membership.gms.mgr.GMSMembershipManager.suspectMember(GMSMembershipManager.java:1657)
at
org.apache.geode.internal.tcp.Connection.initiateSuspicionIfSharedUnordered(Connection.java:1917)
at org.apache.geode.internal.tcp.Connection.run(Connection.java:1697)
at java.lang.Thread.run(Thread.java:748)
{code}
> ClusterConfigLocatorRestartDUnitTest fails intermittently
> -
>
> Key: GEODE-4915
> URL: https://issues.apache.org/jira/browse/GEODE-4915
> Project: Geode
> Issue Type: Bug
> Components: configuration, gfsh
>Reporter: Jens Deppe
>Assignee: Kenneth Howe
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.6.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This test has timing issues and needs to be more robust.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-3003) Geode doesn't start after cluster restart when using cluster-configuration
[
https://issues.apache.org/jira/browse/GEODE-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe updated GEODE-3003:
Fix Version/s: 1.5.0
> Geode doesn't start after cluster restart when using cluster-configuration
> --
>
> Key: GEODE-3003
> URL: https://issues.apache.org/jira/browse/GEODE-3003
> Project: Geode
> Issue Type: Bug
> Components: configuration, membership
>Reporter: Anton Mironenko
>Assignee: Kenneth Howe
>Priority: Major
> Fix For: 1.5.0
>
> Attachments: 20170522-geode-klyazma.zip, 20170522-geode-vyazma.zip,
> 20170608-host1-locator0.zip, 20170608-host2-locator0.zip, geode-host1.zip,
> geode-host2.zip, readme.txt
>
>
> There is a two-host Geode cluster with locator and server on each host.
> First start of all nodes goes well.
> Then all nodes are gracefully stopped (kill [locator-PID] [server-PID]).
> The second start goes wrong: the locator on the first host always doesn't
> join the rest of the cluster with the error in the locator log:
> "Region /_ConfigurationRegion has potentially stale data. It is waiting for
> another member to recover the latest data."
> And sometimes (once per 5 starts) some server shuts down just after start
> with the error
> "org.apache.geode.GemFireConfigException: cluster configuration service not
> available".
> This bug started appearing only when we moved to Geode 1.1.1. And it totally
> blocks us.
> On GemFire 8.2.1 there was no such a bug.
> This is very easy to reproduce.
> Test preparation:
> -
> Here are two attached zip files - "geode-host1.zip" and "geode-host2.zip"
> 1) unzip "geode-host1.zip" into some folder on your first host
> 2) in start-locator.sh change the IPs of locators to the values of your host1
> and host2
> "--locators=10.50.3.38[20236],10.50.3.14[20236]"
> 3) in start-server.sh
> "locators=10.50.3.38[20236],10.50.3.14[20236]" change the IPs of locators to
> the values of your host1 and host2
> 4) do the bullets 1)-3) for host2, the folder where you unzip the file should
> be the same as on the first host
> Test running:
> ---
> 1) rm -rf {locator0,server1}
> 2) run ./start-locator.sh; ./start-server.sh on host1, then on host2. See
> that this cluster start is successful.
> 3) kill locator and server processes first on host1, then on host2
> kill [locator-PID] [server-PID]
> 4) run
> ./start-locator.sh; ./start-server.sh
> on host1, then on host2. Make sure the interval between this command run on
> two hosts is less than 1 second!
> 5) see via gfsh that actually there are two clusters: "host1-locator" and
> "host1-server, host2-locator, host2-server" instead of one cluster. And
> sometimes there is no "host1-server", because it shutdown with the error
> "Region /_ConfigurationRegion has potentially stale data. It is waiting for
> another member to recover the latest data.".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-3003) Geode doesn't start after cluster restart when using cluster-configuration
[
https://issues.apache.org/jira/browse/GEODE-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kenneth Howe resolved GEODE-3003.
-
Resolution: Fixed
> Geode doesn't start after cluster restart when using cluster-configuration
> --
>
> Key: GEODE-3003
> URL: https://issues.apache.org/jira/browse/GEODE-3003
> Project: Geode
> Issue Type: Bug
> Components: configuration, membership
>Reporter: Anton Mironenko
>Assignee: Kenneth Howe
>Priority: Major
> Attachments: 20170522-geode-klyazma.zip, 20170522-geode-vyazma.zip,
> 20170608-host1-locator0.zip, 20170608-host2-locator0.zip, geode-host1.zip,
> geode-host2.zip, readme.txt
>
>
> There is a two-host Geode cluster with locator and server on each host.
> First start of all nodes goes well.
> Then all nodes are gracefully stopped (kill [locator-PID] [server-PID]).
> The second start goes wrong: the locator on the first host always doesn't
> join the rest of the cluster with the error in the locator log:
> "Region /_ConfigurationRegion has potentially stale data. It is waiting for
> another member to recover the latest data."
> And sometimes (once per 5 starts) some server shuts down just after start
> with the error
> "org.apache.geode.GemFireConfigException: cluster configuration service not
> available".
> This bug started appearing only when we moved to Geode 1.1.1. And it totally
> blocks us.
> On GemFire 8.2.1 there was no such a bug.
> This is very easy to reproduce.
> Test preparation:
> -
> Here are two attached zip files - "geode-host1.zip" and "geode-host2.zip"
> 1) unzip "geode-host1.zip" into some folder on your first host
> 2) in start-locator.sh change the IPs of locators to the values of your host1
> and host2
> "--locators=10.50.3.38[20236],10.50.3.14[20236]"
> 3) in start-server.sh
> "locators=10.50.3.38[20236],10.50.3.14[20236]" change the IPs of locators to
> the values of your host1 and host2
> 4) do the bullets 1)-3) for host2, the folder where you unzip the file should
> be the same as on the first host
> Test running:
> ---
> 1) rm -rf {locator0,server1}
> 2) run ./start-locator.sh; ./start-server.sh on host1, then on host2. See
> that this cluster start is successful.
> 3) kill locator and server processes first on host1, then on host2
> kill [locator-PID] [server-PID]
> 4) run
> ./start-locator.sh; ./start-server.sh
> on host1, then on host2. Make sure the interval between this command run on
> two hosts is less than 1 second!
> 5) see via gfsh that actually there are two clusters: "host1-locator" and
> "host1-server, host2-locator, host2-server" instead of one cluster. And
> sometimes there is no "host1-server", because it shutdown with the error
> "Region /_ConfigurationRegion has potentially stale data. It is waiting for
> another member to recover the latest data.".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-3003) Geode doesn't start after cluster restart when using cluster-configuration
[
https://issues.apache.org/jira/browse/GEODE-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426229#comment-16426229
]
Kenneth Howe commented on GEODE-3003:
-
I reproduced the problem in Geode v1.1.0 using the steps noted above. Then
using the same steps verified that it is fixed in Geode v1.5.0.
> Geode doesn't start after cluster restart when using cluster-configuration
> --
>
> Key: GEODE-3003
> URL: https://issues.apache.org/jira/browse/GEODE-3003
> Project: Geode
> Issue Type: Bug
> Components: configuration, membership
>Reporter: Anton Mironenko
>Assignee: Kenneth Howe
>Priority: Major
> Attachments: 20170522-geode-klyazma.zip, 20170522-geode-vyazma.zip,
> 20170608-host1-locator0.zip, 20170608-host2-locator0.zip, geode-host1.zip,
> geode-host2.zip, readme.txt
>
>
> There is a two-host Geode cluster with locator and server on each host.
> First start of all nodes goes well.
> Then all nodes are gracefully stopped (kill [locator-PID] [server-PID]).
> The second start goes wrong: the locator on the first host always doesn't
> join the rest of the cluster with the error in the locator log:
> "Region /_ConfigurationRegion has potentially stale data. It is waiting for
> another member to recover the latest data."
> And sometimes (once per 5 starts) some server shuts down just after start
> with the error
> "org.apache.geode.GemFireConfigException: cluster configuration service not
> available".
> This bug started appearing only when we moved to Geode 1.1.1. And it totally
> blocks us.
> On GemFire 8.2.1 there was no such a bug.
> This is very easy to reproduce.
> Test preparation:
> -
> Here are two attached zip files - "geode-host1.zip" and "geode-host2.zip"
> 1) unzip "geode-host1.zip" into some folder on your first host
> 2) in start-locator.sh change the IPs of locators to the values of your host1
> and host2
> "--locators=10.50.3.38[20236],10.50.3.14[20236]"
> 3) in start-server.sh
> "locators=10.50.3.38[20236],10.50.3.14[20236]" change the IPs of locators to
> the values of your host1 and host2
> 4) do the bullets 1)-3) for host2, the folder where you unzip the file should
> be the same as on the first host
> Test running:
> ---
> 1) rm -rf {locator0,server1}
> 2) run ./start-locator.sh; ./start-server.sh on host1, then on host2. See
> that this cluster start is successful.
> 3) kill locator and server processes first on host1, then on host2
> kill [locator-PID] [server-PID]
> 4) run
> ./start-locator.sh; ./start-server.sh
> on host1, then on host2. Make sure the interval between this command run on
> two hosts is less than 1 second!
> 5) see via gfsh that actually there are two clusters: "host1-locator" and
> "host1-server, host2-locator, host2-server" instead of one cluster. And
> sometimes there is no "host1-server", because it shutdown with the error
> "Region /_ConfigurationRegion has potentially stale data. It is waiting for
> another member to recover the latest data.".
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
