[jira] [Resolved] (GEODE-4101) Replace Redirection Sytem Properties by --redirect-output flag in GFSH commands
[
https://issues.apache.org/jira/browse/GEODE-4101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Barnes resolved GEODE-4101.
Resolution: Fixed
Documented
> Replace Redirection Sytem Properties by --redirect-output flag in GFSH
> commands
> ---
>
> Key: GEODE-4101
> URL: https://issues.apache.org/jira/browse/GEODE-4101
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh
>Reporter: Juan José Ramos Cassella
>Assignee: Dave Barnes
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.5.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently GEODE is "swallowing" all output sent to stdout and stderr by
> default and there's no way of changing this behavior when starting members
> through gfsh.
> This, between other things, prevents users from playing around with
> {{System.out.println()}} during development phases, there could even be
> certain scenarios where some critical piece of information that comes out
> through stdout somehow bypassed all the logging frameworks. Not only that,
> but this also prevents the user from getting thread dumps by executing a
> plain {{kill -3}} or {{kill -QUIT}} using the processId, which is critical in
> troubleshooting.
> Currently there are two internal flags that can be used to prevent this
> default behavior, both have to be used at the same time and both are very
> counterintuitive {{gemfire.OSProcess.ENABLE_OUTPUT_REDIRECTION=true}} and
> {{gemfire.OSProcess.DISABLE_OUTPUT_REDIRECTION=false}}. These flags, however,
> don't work at all when starting members through {{gfsh}}, and that's because
> the relevant commands wrongly assume that the flags are already part of the
> system properties too early in the lifecylce execution of the command:
> {code:title=StartLocatorCommand.java|borderStyle=solid}
> @CliCommand(value = CliStrings.START_LOCATOR, help =
> CliStrings.START_LOCATOR__HELP)
> @CliMetaData(shellOnly = true, relatedTopic =
> {CliStrings.TOPIC_GEODE_LOCATOR, CliStrings.TOPIC_GEODE_LIFECYCLE})
> public Result startLocator(...) throws Exception {
> (...)
> final boolean redirectOutput =
> Boolean.getBoolean(OSProcess.ENABLE_OUTPUT_REDIRECTION_PROPERTY);
> LocatorLauncher.Builder locatorLauncherBuilder =
> new LocatorLauncher.Builder()
> .setRedirectOutput(redirectOutput)
> (...)
> }
> {code}
> {code:title=StartServerCommand.java|borderStyle=solid}
> @CliCommand(value = CliStrings.START_SERVER, help =
> CliStrings.START_SERVER__HELP)
> @CliMetaData(shellOnly = true, relatedTopic = {CliStrings.TOPIC_GEODE_SERVER,
> CliStrings.TOPIC_GEODE_LIFECYCLE})
> public Result startServer(...) throws Exception {
> (...)
> final boolean redirectOutput =
> Boolean.getBoolean(OSProcess.ENABLE_OUTPUT_REDIRECTION_PROPERTY);
> ServerLauncher.Builder serverLauncherBuilder =
> new ServerLauncher.Builder()
> .setRedirectOutput(redirectOutput)
> (...)
> {code}
> At this stage during the execution, the system properties used when starting
> the members haven't been fully parsed yet and the flags only present within
> the {{sun.java.command}} system property, so
> {{Boolean.getBoolean(OSProcess.ENABLE_OUTPUT_REDIRECTION_PROPERTY)}} will
> always return {{false}}.
> The goal of the current JIRA is to add a {{--redirect-ouput}} flag to the
> start commands in {{GFSH}} and deprecate the properties
> {{OSProcess.DISABLE_OUTPUT_REDIRECTION}} and
> {{OSProcess.ENABLE_OUTPUT_REDIRECTION}}; unfortunately they can't be directly
> deleted because, even when they are internal, they've been referenced several
> times in external articles to workaround older issues.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4101) Replace Redirection Sytem Properties by --redirect-output flag in GFSH commands
[
https://issues.apache.org/jira/browse/GEODE-4101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381493#comment-16381493
]
ASF subversion and git services commented on GEODE-4101:
Commit 25a0d6e3cc1cce930f50c68120b738862f8488c5 in geode's branch
refs/heads/develop from [~dbarnes97]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=25a0d6e ]
GEODE-4101: User Guide - incorporate review comments
> Replace Redirection Sytem Properties by --redirect-output flag in GFSH
> commands
> ---
>
> Key: GEODE-4101
> URL: https://issues.apache.org/jira/browse/GEODE-4101
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh
>Reporter: Juan José Ramos Cassella
>Assignee: Dave Barnes
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.5.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently GEODE is "swallowing" all output sent to stdout and stderr by
> default and there's no way of changing this behavior when starting members
> through gfsh.
> This, between other things, prevents users from playing around with
> {{System.out.println()}} during development phases, there could even be
> certain scenarios where some critical piece of information that comes out
> through stdout somehow bypassed all the logging frameworks. Not only that,
> but this also prevents the user from getting thread dumps by executing a
> plain {{kill -3}} or {{kill -QUIT}} using the processId, which is critical in
> troubleshooting.
> Currently there are two internal flags that can be used to prevent this
> default behavior, both have to be used at the same time and both are very
> counterintuitive {{gemfire.OSProcess.ENABLE_OUTPUT_REDIRECTION=true}} and
> {{gemfire.OSProcess.DISABLE_OUTPUT_REDIRECTION=false}}. These flags, however,
> don't work at all when starting members through {{gfsh}}, and that's because
> the relevant commands wrongly assume that the flags are already part of the
> system properties too early in the lifecylce execution of the command:
> {code:title=StartLocatorCommand.java|borderStyle=solid}
> @CliCommand(value = CliStrings.START_LOCATOR, help =
> CliStrings.START_LOCATOR__HELP)
> @CliMetaData(shellOnly = true, relatedTopic =
> {CliStrings.TOPIC_GEODE_LOCATOR, CliStrings.TOPIC_GEODE_LIFECYCLE})
> public Result startLocator(...) throws Exception {
> (...)
> final boolean redirectOutput =
> Boolean.getBoolean(OSProcess.ENABLE_OUTPUT_REDIRECTION_PROPERTY);
> LocatorLauncher.Builder locatorLauncherBuilder =
> new LocatorLauncher.Builder()
> .setRedirectOutput(redirectOutput)
> (...)
> }
> {code}
> {code:title=StartServerCommand.java|borderStyle=solid}
> @CliCommand(value = CliStrings.START_SERVER, help =
> CliStrings.START_SERVER__HELP)
> @CliMetaData(shellOnly = true, relatedTopic = {CliStrings.TOPIC_GEODE_SERVER,
> CliStrings.TOPIC_GEODE_LIFECYCLE})
> public Result startServer(...) throws Exception {
> (...)
> final boolean redirectOutput =
> Boolean.getBoolean(OSProcess.ENABLE_OUTPUT_REDIRECTION_PROPERTY);
> ServerLauncher.Builder serverLauncherBuilder =
> new ServerLauncher.Builder()
> .setRedirectOutput(redirectOutput)
> (...)
> {code}
> At this stage during the execution, the system properties used when starting
> the members haven't been fully parsed yet and the flags only present within
> the {{sun.java.command}} system property, so
> {{Boolean.getBoolean(OSProcess.ENABLE_OUTPUT_REDIRECTION_PROPERTY)}} will
> always return {{false}}.
> The goal of the current JIRA is to add a {{--redirect-ouput}} flag to the
> start commands in {{GFSH}} and deprecate the properties
> {{OSProcess.DISABLE_OUTPUT_REDIRECTION}} and
> {{OSProcess.ENABLE_OUTPUT_REDIRECTION}}; unfortunately they can't be directly
> deleted because, even when they are internal, they've been referenced several
> times in external articles to workaround older issues.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4101) Replace Redirection Sytem Properties by --redirect-output flag in GFSH commands
[
https://issues.apache.org/jira/browse/GEODE-4101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381492#comment-16381492
]
ASF subversion and git services commented on GEODE-4101:
Commit 291c4e5576d4faaa9b2cbc21444da8561d761cde in geode's branch
refs/heads/develop from [~dbarnes97]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=291c4e5 ]
GEODE-4101: User Guide - document the --redirect-output flag in GFSH commands
> Replace Redirection Sytem Properties by --redirect-output flag in GFSH
> commands
> ---
>
> Key: GEODE-4101
> URL: https://issues.apache.org/jira/browse/GEODE-4101
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh
>Reporter: Juan José Ramos Cassella
>Assignee: Dave Barnes
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.5.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently GEODE is "swallowing" all output sent to stdout and stderr by
> default and there's no way of changing this behavior when starting members
> through gfsh.
> This, between other things, prevents users from playing around with
> {{System.out.println()}} during development phases, there could even be
> certain scenarios where some critical piece of information that comes out
> through stdout somehow bypassed all the logging frameworks. Not only that,
> but this also prevents the user from getting thread dumps by executing a
> plain {{kill -3}} or {{kill -QUIT}} using the processId, which is critical in
> troubleshooting.
> Currently there are two internal flags that can be used to prevent this
> default behavior, both have to be used at the same time and both are very
> counterintuitive {{gemfire.OSProcess.ENABLE_OUTPUT_REDIRECTION=true}} and
> {{gemfire.OSProcess.DISABLE_OUTPUT_REDIRECTION=false}}. These flags, however,
> don't work at all when starting members through {{gfsh}}, and that's because
> the relevant commands wrongly assume that the flags are already part of the
> system properties too early in the lifecylce execution of the command:
> {code:title=StartLocatorCommand.java|borderStyle=solid}
> @CliCommand(value = CliStrings.START_LOCATOR, help =
> CliStrings.START_LOCATOR__HELP)
> @CliMetaData(shellOnly = true, relatedTopic =
> {CliStrings.TOPIC_GEODE_LOCATOR, CliStrings.TOPIC_GEODE_LIFECYCLE})
> public Result startLocator(...) throws Exception {
> (...)
> final boolean redirectOutput =
> Boolean.getBoolean(OSProcess.ENABLE_OUTPUT_REDIRECTION_PROPERTY);
> LocatorLauncher.Builder locatorLauncherBuilder =
> new LocatorLauncher.Builder()
> .setRedirectOutput(redirectOutput)
> (...)
> }
> {code}
> {code:title=StartServerCommand.java|borderStyle=solid}
> @CliCommand(value = CliStrings.START_SERVER, help =
> CliStrings.START_SERVER__HELP)
> @CliMetaData(shellOnly = true, relatedTopic = {CliStrings.TOPIC_GEODE_SERVER,
> CliStrings.TOPIC_GEODE_LIFECYCLE})
> public Result startServer(...) throws Exception {
> (...)
> final boolean redirectOutput =
> Boolean.getBoolean(OSProcess.ENABLE_OUTPUT_REDIRECTION_PROPERTY);
> ServerLauncher.Builder serverLauncherBuilder =
> new ServerLauncher.Builder()
> .setRedirectOutput(redirectOutput)
> (...)
> {code}
> At this stage during the execution, the system properties used when starting
> the members haven't been fully parsed yet and the flags only present within
> the {{sun.java.command}} system property, so
> {{Boolean.getBoolean(OSProcess.ENABLE_OUTPUT_REDIRECTION_PROPERTY)}} will
> always return {{false}}.
> The goal of the current JIRA is to add a {{--redirect-ouput}} flag to the
> start commands in {{GFSH}} and deprecate the properties
> {{OSProcess.DISABLE_OUTPUT_REDIRECTION}} and
> {{OSProcess.ENABLE_OUTPUT_REDIRECTION}}; unfortunately they can't be directly
> deleted because, even when they are internal, they've been referenced several
> times in external articles to workaround older issues.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4182) JDBC connector exception handling needs improvement
[ https://issues.apache.org/jira/browse/GEODE-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-4182: -- Labels: pull-request-available (was: ) > JDBC connector exception handling needs improvement > --- > > Key: GEODE-4182 > URL: https://issues.apache.org/jira/browse/GEODE-4182 > Project: Geode > Issue Type: Improvement > Components: extensions >Reporter: Darrel Schneider >Assignee: Nick Reich >Priority: Major > Labels: pull-request-available > > The JDBC connector currently has multiple places it catches SQLException and > turns around and throws IllegalStateException. It should instead throw a new > exception that is dedicated to the jdbc connector. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4755) Jar deploy fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-4755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jens Deppe updated GEODE-4755:
--
Description:
Fails with this exception:
{noformat}
java.lang.UnsupportedOperationException: 'posix:permissions' not supported as
initial attribute
at
sun.nio.fs.WindowsSecurityDescriptor.fromAttribute(WindowsSecurityDescriptor.java:358)
at
sun.nio.fs.WindowsFileSystemProvider.createDirectory(WindowsFileSystemProvider.java:492)
at java.nio.file.Files.createDirectory(Files.java:674)
at java.nio.file.TempFileHelper.create(TempFileHelper.java:136)
at
java.nio.file.TempFileHelper.createTempDirectory(TempFileHelper.java:173)
at java.nio.file.Files.createTempDirectory(Files.java:991)
at
org.apache.geode.management.internal.beans.FileUploader.uploadFile(FileUploader.java:77)
{noformat}
Potential classes affected:
{noformat}
org.apache.geode.distributed.internal.ClusterConfigurationService
org.apache.geode.internal.cache.ClusterConfigurationLoader
org.apache.geode.management.internal.beans.FileUploader
org.apache.geode.management.internal.cli.functions.DeployFunction
org.apache.geode.management.internal.web.controllers.AbstractCommandsController
{noformat}
Posixness can be checked with
{{FileSystems.getDefault().supportedFileAttributeViews().contains(“posix”);}}
was:
Fails with this exception:
{noformat}
java.lang.UnsupportedOperationException: 'posix:permissions' not supported as
initial attribute
at
sun.nio.fs.WindowsSecurityDescriptor.fromAttribute(WindowsSecurityDescriptor.java:358)
at
sun.nio.fs.WindowsFileSystemProvider.createDirectory(WindowsFileSystemProvider.java:492)
at java.nio.file.Files.createDirectory(Files.java:674)
at java.nio.file.TempFileHelper.create(TempFileHelper.java:136)
at
java.nio.file.TempFileHelper.createTempDirectory(TempFileHelper.java:173)
at java.nio.file.Files.createTempDirectory(Files.java:991)
at
org.apache.geode.management.internal.beans.FileUploader.uploadFile(FileUploader.java:77)
{noformat}
Potential classes affected:
{noformat}
org.apache.geode.distributed.internal.ClusterConfigurationService
org.apache.geode.internal.cache.ClusterConfigurationLoader
org.apache.geode.management.internal.beans.FileUploader
org.apache.geode.management.internal.cli.functions.DeployFunction
org.apache.geode.management.internal.web.controllers.AbstractCommandsController
{noformat}
> Jar deploy fails on Windows
> ---
>
> Key: GEODE-4755
> URL: https://issues.apache.org/jira/browse/GEODE-4755
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Priority: Major
>
> Fails with this exception:
> {noformat}
> java.lang.UnsupportedOperationException: 'posix:permissions' not supported as
> initial attribute
>at
> sun.nio.fs.WindowsSecurityDescriptor.fromAttribute(WindowsSecurityDescriptor.java:358)
>at
> sun.nio.fs.WindowsFileSystemProvider.createDirectory(WindowsFileSystemProvider.java:492)
>at java.nio.file.Files.createDirectory(Files.java:674)
>at java.nio.file.TempFileHelper.create(TempFileHelper.java:136)
>at
> java.nio.file.TempFileHelper.createTempDirectory(TempFileHelper.java:173)
>at java.nio.file.Files.createTempDirectory(Files.java:991)
>at
> org.apache.geode.management.internal.beans.FileUploader.uploadFile(FileUploader.java:77)
> {noformat}
> Potential classes affected:
> {noformat}
> org.apache.geode.distributed.internal.ClusterConfigurationService
> org.apache.geode.internal.cache.ClusterConfigurationLoader
> org.apache.geode.management.internal.beans.FileUploader
> org.apache.geode.management.internal.cli.functions.DeployFunction
> org.apache.geode.management.internal.web.controllers.AbstractCommandsController
> {noformat}
> Posixness can be checked with
> {{FileSystems.getDefault().supportedFileAttributeViews().contains(“posix”);}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-4755) Jar deploy fails on Windows
Jens Deppe created GEODE-4755:
-
Summary: Jar deploy fails on Windows
Key: GEODE-4755
URL: https://issues.apache.org/jira/browse/GEODE-4755
Project: Geode
Issue Type: Bug
Components: gfsh
Reporter: Jens Deppe
Fails with this exception:
{noformat}
java.lang.UnsupportedOperationException: 'posix:permissions' not supported as
initial attribute
at
sun.nio.fs.WindowsSecurityDescriptor.fromAttribute(WindowsSecurityDescriptor.java:358)
at
sun.nio.fs.WindowsFileSystemProvider.createDirectory(WindowsFileSystemProvider.java:492)
at java.nio.file.Files.createDirectory(Files.java:674)
at java.nio.file.TempFileHelper.create(TempFileHelper.java:136)
at
java.nio.file.TempFileHelper.createTempDirectory(TempFileHelper.java:173)
at java.nio.file.Files.createTempDirectory(Files.java:991)
at
org.apache.geode.management.internal.beans.FileUploader.uploadFile(FileUploader.java:77)
{noformat}
Potential classes affected:
{noformat}
org.apache.geode.distributed.internal.ClusterConfigurationService
org.apache.geode.internal.cache.ClusterConfigurationLoader
org.apache.geode.management.internal.beans.FileUploader
org.apache.geode.management.internal.cli.functions.DeployFunction
org.apache.geode.management.internal.web.controllers.AbstractCommandsController
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4625) Create region with the same name on different groups in gfsh should fail early
[ https://issues.apache.org/jira/browse/GEODE-4625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-4625: -- Fix Version/s: 1.5.0 > Create region with the same name on different groups in gfsh should fail early > -- > > Key: GEODE-4625 > URL: https://issues.apache.org/jira/browse/GEODE-4625 > Project: Geode > Issue Type: Improvement > Components: docs, gfsh >Reporter: Jinmei Liao >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 2.5h > Remaining Estimate: 0h > > 1. creating non-proxy region: check to see if there is a non-proxy region > with the same name on the entire cluster or not. If yes, abort the creation. > 2. creating proxy region: check to see if there is any region with the same > name on the group or not, if yes, abort the creation. > email thread: > http://mail-archives.apache.org/mod_mbox/geode-user/201802.mbox/%3ccaheksukj65m+-lc-hser01djvggeq6up0ondq0pxemi1tbm...@mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4406) Improve granularity of permissions for new client protocol
[ https://issues.apache.org/jira/browse/GEODE-4406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381183#comment-16381183 ] ASF subversion and git services commented on GEODE-4406: Commit fa1f2ac98070bf445f24ea3b2a8f3ce5cf6b5b7d in geode's branch refs/heads/feature/GEODE-4685 from [~WireBaron] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=fa1f2ac ] GEODE-4406: Improve authorization granularity for protobuf (#1514) > Improve granularity of permissions for new client protocol > -- > > Key: GEODE-4406 > URL: https://issues.apache.org/jira/browse/GEODE-4406 > Project: Geode > Issue Type: New Feature > Components: client/server >Reporter: Galen O'Sullivan >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 1h > Remaining Estimate: 0h > > Currently, the new client protocol requires all DATA:READ permissions to do a > region.get() . If a user only has DATA:READ:regionName , they won't be > permitted to execute commands on the region, even though they have > permissions. We should fix this for all the other operations too. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4736) New protocol should consistently record statistics
[ https://issues.apache.org/jira/browse/GEODE-4736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381181#comment-16381181 ] ASF subversion and git services commented on GEODE-4736: Commit be8140dadb386adfb5b18503ef0878d7f7376f56 in geode's branch refs/heads/feature/GEODE-4685 from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=be8140d ] GEODE-4736: Updating statistics in ProtobufOpsProcessor Updating statistics in one place, rather than in each operation. > New protocol should consistently record statistics > -- > > Key: GEODE-4736 > URL: https://issues.apache.org/jira/browse/GEODE-4736 > Project: Geode > Issue Type: Task > Components: client/server >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Some of the ProtobufOperationHandler classes update statistics by calling > startOperation and endOperation on the statistics class. We should update the > statistics consistently at a higher level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4685) Replace setPdxReadSerialized in org.apache.geode.cache.lucene.internal
[ https://issues.apache.org/jira/browse/GEODE-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381191#comment-16381191 ] ASF subversion and git services commented on GEODE-4685: Commit 74c4461476d128eab5abf650c47cbf313b032e6f in geode's branch refs/heads/feature/GEODE-4685 from Udo [ https://gitbox.apache.org/repos/asf?p=geode.git;h=74c4461 ] GEODE-4685: Moving of static DefaultQuery.setPdxReadSerialized to the TypeRegistry. Cleaned up the overriding of readSerialized to reset to previous value. Added cache to AbstractJdbcCallback.java so that children classes can access it. Replaced AtomicLong with LongAdder. > Replace setPdxReadSerialized in org.apache.geode.cache.lucene.internal > -- > > Key: GEODE-4685 > URL: https://issues.apache.org/jira/browse/GEODE-4685 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: nabarun >Assignee: Udo Kohlmeyer >Priority: Major > > Replace with the solution from GEODE-4679 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4625) Create region with the same name on different groups in gfsh should fail early
[ https://issues.apache.org/jira/browse/GEODE-4625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381185#comment-16381185 ] ASF subversion and git services commented on GEODE-4625: Commit 42485b6faf204c621f7a31aa100c19ed4e0c2d10 in geode's branch refs/heads/feature/GEODE-4685 from [~jinmeiliao] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=42485b6 ] GEODE-4625: rework name collision check logic and add more tests (#1505) * GEODE-4625: rework name collision check logic and add more tests > Create region with the same name on different groups in gfsh should fail early > -- > > Key: GEODE-4625 > URL: https://issues.apache.org/jira/browse/GEODE-4625 > Project: Geode > Issue Type: Improvement > Components: docs, gfsh >Reporter: Jinmei Liao >Priority: Major > Labels: pull-request-available > Time Spent: 2.5h > Remaining Estimate: 0h > > 1. creating non-proxy region: check to see if there is a non-proxy region > with the same name on the entire cluster or not. If yes, abort the creation. > 2. creating proxy region: check to see if there is any region with the same > name on the group or not, if yes, abort the creation. > email thread: > http://mail-archives.apache.org/mod_mbox/geode-user/201802.mbox/%3ccaheksukj65m+-lc-hser01djvggeq6up0ondq0pxemi1tbm...@mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4404) Update Gfsh command to pass BackupDestination object
[ https://issues.apache.org/jira/browse/GEODE-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381187#comment-16381187 ] ASF subversion and git services commented on GEODE-4404: Commit f4433fcc6ce2d28568b7bf08b9b936ad08d3d1bf in geode's branch refs/heads/feature/GEODE-4685 from [~nreich] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f4433fc ] GEODE-4404: Move BackupWriter creation (#1521) * to facilitate future creation of backup plugins, the BackupWriter is created using generic information passed from gfsh > Update Gfsh command to pass BackupDestination object > > > Key: GEODE-4404 > URL: https://issues.apache.org/jira/browse/GEODE-4404 > Project: Geode > Issue Type: Sub-task > Components: persistence >Reporter: Nick Reich >Assignee: Nick Reich >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Gfsh backup command passes File destination as the target location. To > support any destination other than the file system for the target location to > save the backup, we need to be able to pass alternate information in the > backup messages. Having the backup command provide an implementation of > BackupDestination (in this case, FileSystemBackupDestination) will allow for > the future creation of gfsh commands that utilize a different destination. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4743) Code Cleanup: Remove dead classes DebuggerSupport, SingletonCallable, SingletonValue, StackTraceCollector, DebuggerUtils
[ https://issues.apache.org/jira/browse/GEODE-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381188#comment-16381188 ] ASF subversion and git services commented on GEODE-4743: Commit 7980b1c4fa9fb5a233ed77706a7f5885516a86cc in geode's branch refs/heads/feature/GEODE-4685 from [~prhomberg] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=7980b1c ] GEODE-4743: Removed five dead classes. * Remove classes: DebuggerSupport, SingletonCallable, SingletonValue, StackTraceCollector, DebuggerUtils. * Remove commented-out code that mentions one of these classes * Remove commented-out code from surrounding area. * Remove test that has been ignored since 2008. * Remove SingletonValue from sanctioned serializables. * Update AnalyzeSerializablesJUnitTest for more meaningful failure. > Code Cleanup: Remove dead classes DebuggerSupport, SingletonCallable, > SingletonValue, StackTraceCollector, DebuggerUtils > > > Key: GEODE-4743 > URL: https://issues.apache.org/jira/browse/GEODE-4743 > Project: Geode > Issue Type: Bug >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > These classes appear to be remnants of the dark and dreadful time before IDE > debuggers. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4625) Create region with the same name on different groups in gfsh should fail early
[ https://issues.apache.org/jira/browse/GEODE-4625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381186#comment-16381186 ] ASF subversion and git services commented on GEODE-4625: Commit 42485b6faf204c621f7a31aa100c19ed4e0c2d10 in geode's branch refs/heads/feature/GEODE-4685 from [~jinmeiliao] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=42485b6 ] GEODE-4625: rework name collision check logic and add more tests (#1505) * GEODE-4625: rework name collision check logic and add more tests > Create region with the same name on different groups in gfsh should fail early > -- > > Key: GEODE-4625 > URL: https://issues.apache.org/jira/browse/GEODE-4625 > Project: Geode > Issue Type: Improvement > Components: docs, gfsh >Reporter: Jinmei Liao >Priority: Major > Labels: pull-request-available > Time Spent: 2.5h > Remaining Estimate: 0h > > 1. creating non-proxy region: check to see if there is a non-proxy region > with the same name on the entire cluster or not. If yes, abort the creation. > 2. creating proxy region: check to see if there is any region with the same > name on the group or not, if yes, abort the creation. > email thread: > http://mail-archives.apache.org/mod_mbox/geode-user/201802.mbox/%3ccaheksukj65m+-lc-hser01djvggeq6up0ondq0pxemi1tbm...@mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4744) Allow java.util.Map#get in OQL when security is enabled
[
https://issues.apache.org/jira/browse/GEODE-4744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381189#comment-16381189
]
ASF subversion and git services commented on GEODE-4744:
Commit 967b9dba0576b43a00280528e0ff4a53eb1d1bf3 in geode's branch
refs/heads/feature/GEODE-4685 from [~masaki.yamakawa]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=967b9db ]
GEODE-4744: Allow java.util.Map#get in OQL when security is enabled
> Allow java.util.Map#get in OQL when security is enabled
> ---
>
> Key: GEODE-4744
> URL: https://issues.apache.org/jira/browse/GEODE-4744
> Project: Geode
> Issue Type: Improvement
> Components: querying
>Affects Versions: 1.3.0
>Reporter: Masaki Yamakawa
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I am migrating from GemFire 7.x to Geode. After migration, An exception is
> now thrown in OQL when security is enabled.
> The OQL in which the exception occurs is as follows:
> {code:sql}
> select * from /RegionA a where a['intData']=1 and a['strData1']='ABC' and
> a.get(1)=98 and a.get('strData2')='DEF'
> {code}
> {code:sql}
> select * from /RegionB where mapField.get('mapData1')='ZZZ' and
> mapField.get(0)=123
> {code}
> * The value of Region A is java.util.Map, the value of Region B is its domain
> object, and it holds the public field of java.util.Map called mapField.
> I would like to allow java.util.Map#get in OQL.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4753) Protobuf GetServer request has wrong permission set
[ https://issues.apache.org/jira/browse/GEODE-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381190#comment-16381190 ] ASF subversion and git services commented on GEODE-4753: Commit 92278d466d2721f03b7d1430a549f52930e032a7 in geode's branch refs/heads/feature/GEODE-4685 from [~WireBaron] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=92278d4 ] GEODE-4753: fix permission for GetServer operation (#1524) > Protobuf GetServer request has wrong permission set > --- > > Key: GEODE-4753 > URL: https://issues.apache.org/jira/browse/GEODE-4753 > Project: Geode > Issue Type: Bug >Reporter: Brian Rowe >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 20m > Remaining Estimate: 0h > > A recent change accidently changed this from a cluster scope permission to > data scope. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-3875) gfsh command to create jndi binding
[
https://issues.apache.org/jira/browse/GEODE-3875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381182#comment-16381182
]
ASF subversion and git services commented on GEODE-3875:
Commit 40fb4bd8fe7b644350a3b4a3e444d1c7f8a78e96 in geode's branch
refs/heads/feature/GEODE-4685 from [~sai.boorlaga...@gmail.com]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=40fb4bd ]
GEODE-3875: gfsh command to create jndi binding (#1507)
Reworked on a response message text based on review.
> gfsh command to create jndi binding
> ---
>
> Key: GEODE-3875
> URL: https://issues.apache.org/jira/browse/GEODE-3875
> Project: Geode
> Issue Type: Sub-task
> Components: docs, gfsh
>Reporter: Swapnil Bawaskar
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.5.0
>
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> In cache.xml user can specify jndi binding like so:
> {code:java}
>
> jdbc-driver-class="org.postgresql.Driver" user-name="gpadmin"
> password="changeme"
> connection-url="jdbc:postgresql://localhost:5432/gemfire_db">
>
>
> {code}
> A user should be able to create a datasource using the gfsh command {{create
> jndi-binding }}
> Then a datasource will be created with the supplied options and the binding
> will be created without the user having to restart the existing server(s)
> Please look at Geode's schema for a list of attributes that can be set:
> [https://github.com/apache/geode-site/blob/master/website/content/schema/cache/cache-1.0.xsd#L1331]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4685) Replace setPdxReadSerialized in org.apache.geode.cache.lucene.internal
[ https://issues.apache.org/jira/browse/GEODE-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381177#comment-16381177 ] ASF subversion and git services commented on GEODE-4685: Commit f7cff199bef1a1d38e05a3b27d462f4077703851 in geode's branch refs/heads/feature/GEODE-4685 from Udo [ https://gitbox.apache.org/repos/asf?p=geode.git;h=f7cff19 ] GEODE-4685: added check to handle a null type registry > Replace setPdxReadSerialized in org.apache.geode.cache.lucene.internal > -- > > Key: GEODE-4685 > URL: https://issues.apache.org/jira/browse/GEODE-4685 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: nabarun >Assignee: Udo Kohlmeyer >Priority: Major > > Replace with the solution from GEODE-4679 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4721) Being invoked within JTA Region.values() (and all iteration related operations) does return empty collection
[
https://issues.apache.org/jira/browse/GEODE-4721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381171#comment-16381171
]
Eric Shu commented on GEODE-4721:
-
So far I could not reproduce the issue mentioned unless JTA and set operation
is on a client proxy region.
Can you share your function body, and how it was invoked -- using onMember or
onRegion?
Please note, if you set gemfire.restoreSetOperationTransactionBehavior=true,
and then in the function you perform some entry operations. If you then access
the set (values, entrySet), JTA/transaction will fail with
IllegalStateException of "The Region collection is not transactional but is
being used in a transaction".
> Being invoked within JTA Region.values() (and all iteration related
> operations) does return empty collection
>
>
> Key: GEODE-4721
> URL: https://issues.apache.org/jira/browse/GEODE-4721
> Project: Geode
> Issue Type: Bug
> Components: regions, transactions
>Reporter: Vadim Lotarev
>Assignee: Eric Shu
>Priority: Critical
>
> {{Region.values()}} returns empty collection being invoked within JTA. Other
> operations returns data, for example this workaround works (though less
> efficient): {{region.getAll(region.keySet()).values()}}, also
> {{Region.size()}} returns correct value.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-4725) LuceneEventListener should set pdxReadSerialized back to original value
[ https://issues.apache.org/jira/browse/GEODE-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun closed GEODE-4725. -- > LuceneEventListener should set pdxReadSerialized back to original value > --- > > Key: GEODE-4725 > URL: https://issues.apache.org/jira/browse/GEODE-4725 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Jason Huynh >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 40m > Remaining Estimate: 0h > > In LuceneEventListener.process, we set the value of pdx read serialized to > true: > DefaultQuery.setPdxReadSerialized(true); > > In the finally block, we end up setting it to false. > This is incorrect, we should store the original value before setting to true > and set the value back to the original value in the finally block. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4745) CI Failure : entriesFlushedToIndexAfterWaitForFlushCalled
[ https://issues.apache.org/jira/browse/GEODE-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun closed GEODE-4745. -- > CI Failure : entriesFlushedToIndexAfterWaitForFlushCalled > - > > Key: GEODE-4745 > URL: https://issues.apache.org/jira/browse/GEODE-4745 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: nabarun >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 20m > Remaining Estimate: 0h > > org.apache.geode.cache.lucene.LuceneIndexMaintenanceIntegrationTest > > entriesFlushedToIndexAfterWaitForFlushCalled FAILED > java.lang.AssertionError: expected:<8> but was:<7> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at org.junit.Assert.assertEquals(Assert.java:631) > at > org.apache.geode.cache.lucene.LuceneIndexMaintenanceIntegrationTest.entriesFlushedToIndexAfterWaitForFlushCalled(LuceneIndexMaintenanceIntegrationTest.java:277) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (GEODE-4740) CI Failure: LuceneIndexCommandsDUnitTest.listIndexWithStatsShouldReturnCorrectStats
[ https://issues.apache.org/jira/browse/GEODE-4740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun closed GEODE-4740. -- > CI Failure: > LuceneIndexCommandsDUnitTest.listIndexWithStatsShouldReturnCorrectStats > --- > > Key: GEODE-4740 > URL: https://issues.apache.org/jira/browse/GEODE-4740 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Jason Huynh >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This test failed in a recent concourse run > org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommandsDUnitTest > > listIndexWithStatsShouldReturnCorrectStats FAILED > java.lang.AssertionError: > Expecting: > <["3"]> > to contain exactly in any order: > <["2"]> > elements not found: > <["2"]> > and elements not expected: > <["3"]> > at > org.apache.geode.test.junit.assertions.CommandResultAssert.tableHasColumnWithExactValuesInAnyOrder(CommandResultAssert.java:179) > at > org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommandsDUnitTest.listIndexWithStatsShouldReturnCorrectStats(LuceneIndexCommandsDUnitTest.java:154) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4740) CI Failure: LuceneIndexCommandsDUnitTest.listIndexWithStatsShouldReturnCorrectStats
[ https://issues.apache.org/jira/browse/GEODE-4740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun resolved GEODE-4740. Resolution: Fixed Fix Version/s: 1.5.0 > CI Failure: > LuceneIndexCommandsDUnitTest.listIndexWithStatsShouldReturnCorrectStats > --- > > Key: GEODE-4740 > URL: https://issues.apache.org/jira/browse/GEODE-4740 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Jason Huynh >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 20m > Remaining Estimate: 0h > > This test failed in a recent concourse run > org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommandsDUnitTest > > listIndexWithStatsShouldReturnCorrectStats FAILED > java.lang.AssertionError: > Expecting: > <["3"]> > to contain exactly in any order: > <["2"]> > elements not found: > <["2"]> > and elements not expected: > <["3"]> > at > org.apache.geode.test.junit.assertions.CommandResultAssert.tableHasColumnWithExactValuesInAnyOrder(CommandResultAssert.java:179) > at > org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommandsDUnitTest.listIndexWithStatsShouldReturnCorrectStats(LuceneIndexCommandsDUnitTest.java:154) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4745) CI Failure : entriesFlushedToIndexAfterWaitForFlushCalled
[ https://issues.apache.org/jira/browse/GEODE-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] nabarun resolved GEODE-4745. Resolution: Fixed Fix Version/s: 1.5.0 > CI Failure : entriesFlushedToIndexAfterWaitForFlushCalled > - > > Key: GEODE-4745 > URL: https://issues.apache.org/jira/browse/GEODE-4745 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: nabarun >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 20m > Remaining Estimate: 0h > > org.apache.geode.cache.lucene.LuceneIndexMaintenanceIntegrationTest > > entriesFlushedToIndexAfterWaitForFlushCalled FAILED > java.lang.AssertionError: expected:<8> but was:<7> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at org.junit.Assert.assertEquals(Assert.java:631) > at > org.apache.geode.cache.lucene.LuceneIndexMaintenanceIntegrationTest.entriesFlushedToIndexAfterWaitForFlushCalled(LuceneIndexMaintenanceIntegrationTest.java:277) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4276) CI Failure: ClientPostAuthorizationDUnitTest.testAllOpsNotifications unexpected EntryDestroyedException
[
https://issues.apache.org/jira/browse/GEODE-4276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-4276:
--
Labels: Ci (was: )
> CI Failure: ClientPostAuthorizationDUnitTest.testAllOpsNotifications
> unexpected EntryDestroyedException
> ---
>
> Key: GEODE-4276
> URL: https://issues.apache.org/jira/browse/GEODE-4276
> Project: Geode
> Issue Type: Bug
> Components: security
>Affects Versions: 1.5.0
>Reporter: Kenneth Howe
>Priority: Major
> Labels: Ci
> Attachments: GEODE-4276.txt
>
>
> Failed once in apachegeode-ci FlakyTest run #99
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/FlakyTest/builds/99
> {code}
> org.apache.geode.security.ClientPostAuthorizationDUnitTest >
> testAllOpsNotifications FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 3 running on Host
> a3027d61-cf20-45c3-4086-3e7239ee26f6 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:393)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:363)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:296)
> at
> org.apache.geode.security.ClientAuthorizationTestCase.executeOpBlock(ClientAuthorizationTestCase.java:848)
> at
> org.apache.geode.security.ClientPostAuthorizationDUnitTest.testAllOpsNotifications(ClientPostAuthorizationDUnitTest.java:162)
> {code}
> {code:title=Stack trace from remote VM showing the Exception}
> [vm3] java.lang.AssertionError: Unexpected exception
> [vm3] at org.apache.geode.test.dunit.Assert.fail(Assert.java:66)
> [vm3] at
> org.apache.geode.security.SecurityTestUtils$2.done(SecurityTestUtils.java:636)
> [vm3] at
> org.apache.geode.test.dunit.Wait.waitForCriterion(Wait.java:171)
> [vm3] at
> org.apache.geode.security.SecurityTestUtils.waitForCondition(SecurityTestUtils.java:646)
> [vm3] at
> org.apache.geode.security.SecurityTestUtils.waitForCondition(SecurityTestUtils.java:625)
> [vm3] at
> org.apache.geode.security.ClientAuthorizationTestCase.doOp(ClientAuthorizationTestCase.java:414)
> [vm3] at
> org.apache.geode.security.ClientAuthorizationTestCase.lambda$executeOpBlock$15146308$1(ClientAuthorizationTestCase.java:849)
> [vm3] at
> org.apache.geode.test.dunit.NamedRunnable.run(NamedRunnable.java:31)
> [vm3] at sun.reflect.GeneratedMethodAccessor166.invoke(Unknown Source)
> [vm3] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm3] at java.lang.reflect.Method.invoke(Method.java:498)
> [vm3] at hydra.MethExecutor.executeObject(MethExecutor.java:244)
> [vm3] at
> org.apache.geode.test.dunit.standalone.RemoteDUnitVM.executeMethodOnObject(RemoteDUnitVM.java:70)
> [vm3] at sun.reflect.GeneratedMethodAccessor164.invoke(Unknown Source)
> [vm3] at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> [vm3] at java.lang.reflect.Method.invoke(Method.java:498)
> [vm3] at
> sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:357)
> [vm3] at sun.rmi.transport.Transport$1.run(Transport.java:200)
> [vm3] at sun.rmi.transport.Transport$1.run(Transport.java:197)
> [vm3] at java.security.AccessController.doPrivileged(Native Method)
> [vm3] at sun.rmi.transport.Transport.serviceCall(Transport.java:196)
> [vm3] at
> sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:568)
> [vm3] at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:826)
> [vm3] at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.lambda$run$0(TCPTransport.java:683)
> [vm3] at java.security.AccessController.doPrivileged(Native Method)
> [vm3] at
> sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:682)
> [vm3] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [vm3] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [vm3] at java.lang.Thread.run(Thread.java:748)
> [vm3] Caused by: org.apache.geode.cache.EntryDestroyedException: key1
> [vm3] at
> org.apache.geode.internal.cache.LocalRegion$NonTXEntry.basicGetEntry(LocalRegion.java:8677)
> [vm3] at
> org.apache.geode.internal.cache.LocalRegion$NonTXEntry.getValue(LocalRegion.java:8704)
> [vm3] at
> org.apache.geode.internal.cache.LocalRegion$NonTXEntry.getValue(LocalRegion.java:8700)
> [vm3] at
>
[jira] [Resolved] (GEODE-3252) Refactor all gfsh commands into separate classes
[
https://issues.apache.org/jira/browse/GEODE-3252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-3252.
---
Resolution: Fixed
Fix Version/s: 1.3.0
> Refactor all gfsh commands into separate classes
>
>
> Key: GEODE-3252
> URL: https://issues.apache.org/jira/browse/GEODE-3252
> Project: Geode
> Issue Type: Improvement
> Components: gfsh
>Reporter: Emily Yeh
>Priority: Minor
> Fix For: 1.3.0
>
>
> Many gfsh command classes are huge because they contain multiple commands and
> the methods they share. Code quality could be improved by refactoring all of
> these commands into their own separate classes and moving the methods they
> share to other appropriately named classes. The tests associated with these
> giant classes should also be split into smaller tests that deal with separate
> commands.
> Below is a list of classes that may need to be refactored:
> {noformat}
> ClientCommands
> ConfigCommands
> CreateAlterDestroyRegionCommands
> DataCommands
> DeployCommands
> DiskStoreCommands
> DurableClientCommands
> ExportImportClusterConfigurationCommands
> FunctionCommands
> GfshHelpCommands
> IndexCommands
> LauncherLifecycleCommands
> MemberCommands
> MiscellaneousCommands
> PDXCommands
> QueueCommands
> RegionCommands
> ShellCommands
> StatusCommands
> WanCommands
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-2143) JSON deserialization fails if a String contains an apostrophe
[
https://issues.apache.org/jira/browse/GEODE-2143?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381150#comment-16381150
]
Barbara Pruijn commented on GEODE-2143:
---
See GEODE-2380
> JSON deserialization fails if a String contains an apostrophe
> -
>
> Key: GEODE-2143
> URL: https://issues.apache.org/jira/browse/GEODE-2143
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jared Stewart
>Assignee: Kevin Duling
>Priority: Major
>
> Testing revealed this causes an issue when a String value contains a single
> apostrophe in it. For example: {{Customer customer = new Customer(1L,
> "Galen", "O'Sullivan", "555-11-");}}
> If you create a region and put in a value which is an instance of
> org.apache.geode.rest.internal.web.controllers.Customer, then gfsh blows up
> when attempting to display the value:
> {code}
> gfsh>query --query="select * from /customers"
> Result : true
> startCount : 0
> endCount : 20
> Rows : 1
> Value
> ---
> Error getting bean properties Expected a ',' or '}' at 86 [character 87 line
> 1]
> {code}
> It would be good to determine why this occurs to prevent the same error from
> arising with user-provided classes.
> The error occurs in the GfJsonObject, which will be replaced in an upcoming
> release.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-2200) add a "show cluster-config" to output the current cluster config info
[ https://issues.apache.org/jira/browse/GEODE-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn resolved GEODE-2200. --- Resolution: Fixed There is a gfsh describe config: Display configuration details of a member or members. > add a "show cluster-config" to output the current cluster config info > - > > Key: GEODE-2200 > URL: https://issues.apache.org/jira/browse/GEODE-2200 > Project: Geode > Issue Type: Sub-task > Components: docs, management >Reporter: Jinmei Liao >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4740) CI Failure: LuceneIndexCommandsDUnitTest.listIndexWithStatsShouldReturnCorrectStats
[ https://issues.apache.org/jira/browse/GEODE-4740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381103#comment-16381103 ] ASF subversion and git services commented on GEODE-4740: Commit 1c901de2e6b53016727031089d42a3422cde671f in geode's branch refs/heads/develop from [~nnag] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=1c901de ] GEODE-4740: Removed the stat checks * Commit and update stats are removed as they are not deterministic. * Depends when the afterPrimary or the Lucene bucket listeners are kicked off > CI Failure: > LuceneIndexCommandsDUnitTest.listIndexWithStatsShouldReturnCorrectStats > --- > > Key: GEODE-4740 > URL: https://issues.apache.org/jira/browse/GEODE-4740 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: Jason Huynh >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > This test failed in a recent concourse run > org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommandsDUnitTest > > listIndexWithStatsShouldReturnCorrectStats FAILED > java.lang.AssertionError: > Expecting: > <["3"]> > to contain exactly in any order: > <["2"]> > elements not found: > <["2"]> > and elements not expected: > <["3"]> > at > org.apache.geode.test.junit.assertions.CommandResultAssert.tableHasColumnWithExactValuesInAnyOrder(CommandResultAssert.java:179) > at > org.apache.geode.cache.lucene.internal.cli.LuceneIndexCommandsDUnitTest.listIndexWithStatsShouldReturnCorrectStats(LuceneIndexCommandsDUnitTest.java:154) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-2378) CI Failure: PulseAutomatedTest > clickHostShowsMemberTest
[
https://issues.apache.org/jira/browse/GEODE-2378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-2378:
--
Labels: Ci (was: )
> CI Failure: PulseAutomatedTest > clickHostShowsMemberTest
> -
>
> Key: GEODE-2378
> URL: https://issues.apache.org/jira/browse/GEODE-2378
> Project: Geode
> Issue Type: Bug
> Components: pulse
>Reporter: Kevin Duling
>Priority: Major
> Labels: Ci
>
> {noformat}
> org.apache.geode.tools.pulse.tests.ui.PulseAutomatedTest >
> clickHostShowsMemberTest FAILED
> org.openqa.selenium.StaleElementReferenceException:
> {"errorMessage":"Element is no longer attached to the
> DOM","request":{"headers":{"Accept-Encoding":"gzip,deflate","Connection":"Keep-Alive","Content-Length":"27","Content-Type":"application/json;
>
> charset=utf-8","Host":"localhost:19328","User-Agent":"Apache-HttpClient/4.5.1
> (Java/1.8.0_111)"},"httpVersion":"1.1","method":"POST","post":"{\"id\":\":wdc:1485543486264\"}","url":"/click","urlParsed":{"anchor":"","query":"","file":"click","directory":"/","path":"/click","relative":"/click","port":"","host":"","password":"","user":"","userInfo":"","authority":"","protocol":"","source":"/click","queryKey":{},"chunks":["click"]},"urlOriginal":"/session/87cf7fd0-e4c2-11e6-b328-1d4499c52347/element/:wdc:1485543486264/click"}}
> Command duration or timeout: 201 milliseconds
> For documentation on this error, please visit:
> http://seleniumhq.org/exceptions/stale_element_reference.html
> Build info: version: '2.53.1', revision:
> 'a36b8b1cd5757287168e54b817830adce9b0158d', time: '2016-06-30 19:26:09'
> System info: host: 'ad4c26dc-5ee5-4c87-46b4-956ec441bb60', ip:
> '10.254.0.46', os.name: 'Linux', os.arch: 'amd64', os.version:
> '3.19.0-64-generic', java.version: '1.8.0_111'
> Driver info: org.openqa.selenium.phantomjs.PhantomJSDriver
> Capabilities [{applicationCacheEnabled=false, rotatable=false,
> handlesAlerts=false, databaseEnabled=false, version=2.1.1, platform=LINUX,
> browserConnectionEnabled=false, proxy={proxyType=direct}, nativeEvents=true,
> acceptSslCerts=false, driverVersion=1.2.0,
> phantomjs.page.settings.userAgent=Mozilla/5.0 (Windows NT 6.1; Win64; x64;
> rv:16.0) Gecko/20121026 Firefox/16.0, locationContextEnabled=false,
> webStorageEnabled=false, browserName=phantomjs, takesScreenshot=true,
> driverName=ghostdriver, javascriptEnabled=true, cssSelectorsEnabled=true}]
> Session ID: 87cf7fd0-e4c2-11e6-b328-1d4499c52347
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.openqa.selenium.remote.ErrorHandler.createThrowable(ErrorHandler.java:206)
> at
> org.openqa.selenium.remote.ErrorHandler.throwIfResponseFailed(ErrorHandler.java:158)
> at
> org.openqa.selenium.remote.RemoteWebDriver.execute(RemoteWebDriver.java:678)
> at
> org.openqa.selenium.remote.RemoteWebElement.execute(RemoteWebElement.java:327)
> at
> org.openqa.selenium.remote.RemoteWebElement.click(RemoteWebElement.java:85)
> at
> org.apache.geode.tools.pulse.tests.ui.PulseAutomatedTest.clickHostShowsMemberTest(PulseAutomatedTest.java:212)
> Caused by:
> org.openqa.selenium.remote.ScreenshotException: Screen shot has been
> taken
> Build info: version: '2.53.1', revision:
> 'a36b8b1cd5757287168e54b817830adce9b0158d', time: '2016-06-30 19:26:09'
> System info: host: 'ad4c26dc-5ee5-4c87-46b4-956ec441bb60', ip:
> '10.254.0.46', os.name: 'Linux', os.arch: 'amd64', os.version:
> '3.19.0-64-generic', java.version: '1.8.0_111'
> Driver info: driver.version: RemoteWebDriver
> at
> org.openqa.selenium.remote.ErrorHandler.throwIfResponseFailed(ErrorHandler.java:138)
> ... 4 more
> Caused by:
> org.openqa.selenium.StaleElementReferenceException:
> {"errorMessage":"Element is no longer attached to the
> DOM","request":{"headers":{"Accept-Encoding":"gzip,deflate","Connection":"Keep-Alive","Content-Length":"27","Content-Type":"application/json;
>
> charset=utf-8","Host":"localhost:19328","User-Agent":"Apache-HttpClient/4.5.1
>
[jira] [Updated] (GEODE-2254) SharedConfigurationUsingDirDUnitTest - all tests fail on Windows with suspect strings
[
https://issues.apache.org/jira/browse/GEODE-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-2254:
--
Labels: Ci (was: )
> SharedConfigurationUsingDirDUnitTest - all tests fail on Windows with suspect
> strings
> -
>
> Key: GEODE-2254
> URL: https://issues.apache.org/jira/browse/GEODE-2254
> Project: Geode
> Issue Type: Bug
> Components: configuration
>Reporter: Bruce Schuchardt
>Priority: Major
> Labels: Ci
>
> Running with revision 6992fcf3438f0d5de246579400bdf8f44928429e, all of the
> tests in this class fail with a suspect string that looks like this
> functionality does not work correctly on Windows. It looks like cluster
> configuration creates a file name based on java.sql.Timestamp.toString()
> which has characters in it that Windows does not like:
> {noformat}
> [error 2016/12/28 08:17:38.475 PST tid=0x75]
> cluster-config-2016-12-28 08:17:38.474.zip (The filename, directory name, or
> volume label syntax is incorrect)
> java.io.FileNotFoundException: cluster-config-2016-12-28 08:17:38.474.zip
> (The filename, directory name, or volume label syntax is incorrect)
> at java.io.FileOutputStream.open0(Native Method)
> at java.io.FileOutputStream.open(FileOutputStream.java:270)
> at java.io.FileOutputStream.(FileOutputStream.java:213)
> at java.io.FileOutputStream.(FileOutputStream.java:162)
> at
> org.apache.geode.management.internal.configuration.utils.ZipUtils.zip(ZipUtils.java:48)
> at
> org.apache.geode.distributed.internal.SharedConfiguration.initSharedConfiguration(SharedConfiguration.java:264)
> at
> org.apache.geode.distributed.internal.InternalLocator$SharedConfigurationRunnable.run(InternalLocator.java:650)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:621)
> at
> org.apache.geode.distributed.internal.DistributionManager$4$1.run(DistributionManager.java:878)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> All of the tests fail with the same symptom. This is likely a product issue
> and not a test problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-4754) remove com.sun.proxy from the serialization white-list
Bruce Schuchardt created GEODE-4754: --- Summary: remove com.sun.proxy from the serialization white-list Key: GEODE-4754 URL: https://issues.apache.org/jira/browse/GEODE-4754 Project: Geode Issue Type: Task Components: serialization Reporter: Bruce Schuchardt Someone added com.sun.proxy.* to the serialization whitelist in InternalDataSerializer. It looks like it was part of the jar deployer work that introduced RMIIO. We should remove this from the whitelist. I removed it and ran precheckin, and found that only one test, LuceneIndexCommandsDUnitTest.searchShouldReturnCorrectResults, failed. That test was using as cache values instances of an inner class. That caused the whole test instance to be serialized and put in the cache, including instances of VM. These are RMI stubs that reference com.sun.proxy.Proxy instances. Changing the value class to be static will make it pass without needing com.sun.proxy to be whitelisted. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-3188) CI failure (windows): org.apache.geode.internal.statistics.GemFireStatSamplerIntegrationTest.testBasics failed with java.lang.AssertionError: ProcessStats were not create
[
https://issues.apache.org/jira/browse/GEODE-3188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-3188:
--
Labels: Ci IntegrationTest Windows (was: IntegrationTest Windows)
> CI failure (windows):
> org.apache.geode.internal.statistics.GemFireStatSamplerIntegrationTest.testBasics
> failed with java.lang.AssertionError: ProcessStats were not created on
> Windows Server
> -
>
> Key: GEODE-3188
> URL: https://issues.apache.org/jira/browse/GEODE-3188
> Project: Geode
> Issue Type: Bug
> Components: statistics, tests
> Environment: Windows
>Reporter: Lynn Gallinat
>Priority: Major
> Labels: Ci, IntegrationTest, Windows
>
> {noformat}
> org.apache.geode.internal.statistics.GemFireStatSamplerIntegrationTest >
> testBasics FAILED
> java.lang.AssertionError: ProcessStats were not created on Windows Server
> 2012 R2
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at org.junit.Assert.assertNotNull(Assert.java:712)
> at
> org.apache.geode.internal.statistics.GemFireStatSamplerIntegrationTest.testBasics(GemFireStatSamplerIntegrationTest.java:145)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-3326) ConcurrentDeployDUnitTest fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-3326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-3326:
--
Labels: Ci (was: )
> ConcurrentDeployDUnitTest fails intermittently
> --
>
> Key: GEODE-3326
> URL: https://issues.apache.org/jira/browse/GEODE-3326
> Project: Geode
> Issue Type: Bug
> Components: management, tests
>Reporter: Jared Stewart
>Assignee: Jared Stewart
>Priority: Major
> Labels: Ci
>
> {noformat}
> One of my precheckins from yesterday core dumped after
> ConcurrentDeployDUnitTest failed...
> org.apache.geode.management.internal.cli.commands.ConcurrentDeployDUnitTest >
> testMultipleGfshClientToOneServer FAILED
> java.lang.AssertionError: java.util.concurrent.TimeoutException: Timed
> out waiting 6 milliseconds for AsyncInvocation to complete.
> at
> org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:366)
> at
> org.apache.geode.management.internal.cli.commands.ConcurrentDeployDUnitTest.testMultipleGfshClientToOneServer(ConcurrentDeployDUnitTest.java:67)
> Caused by:
> java.util.concurrent.TimeoutException: Timed out waiting 6
> milliseconds for AsyncInvocation to complete.
> at
> org.apache.geode.test.dunit.AsyncInvocation.timeoutIfAlive(AsyncInvocation.java:471)
> at
> org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:340)
> at
> org.apache.geode.test.dunit.AsyncInvocation.await(AsyncInvocation.java:364)
> ... 1 more
> [CodeBlob (0x7fedb7fd1d50)]
> Framesize: 2
> Runtime Stub (0x7fedb7fd1d50): handle_exception_from_callee Runtime1 stub
> Could not load hsdis-amd64.so; library not loadable; PrintAssembly is disabled
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # Internal Error (sharedRuntime.cpp:834), pid=1, tid=0x7fed6c6ec700
> # fatal error: exception happened outside interpreter, nmethods and vtable
> stubs at pc 0x7fedb7fd1e31
> #
> # JRE version: Java(TM) SE Runtime Environment (8.0_131-b11) (build
> 1.8.0_131-b11)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.131-b11 mixed mode
> linux-amd64 compressed oops)
> # Failed to write core dump. Core dumps have been disabled. To enable core
> dumping, try "ulimit -c unlimited" before starting Java again
> #
> # An error report file with more information is saved as:
> #
> /tmp/build/ae3c03f4/geode/geode-core/build/distributedTest937/hs_err_pid1.log
> #
> # If you would like to submit a bug report, please visit:
> # http://bugreport.java.com/bugreport/crash.jsp
> #
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-3498) CreateAndDestroyGatewaySenderCommandsDUnitTest.testCreateDestroyGatewaySender_Group fails with AssertionError
[
https://issues.apache.org/jira/browse/GEODE-3498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-3498:
--
Labels: Ci (was: )
> CreateAndDestroyGatewaySenderCommandsDUnitTest.testCreateDestroyGatewaySender_Group
> fails with AssertionError
> -
>
> Key: GEODE-3498
> URL: https://issues.apache.org/jira/browse/GEODE-3498
> Project: Geode
> Issue Type: Bug
> Components: jmx
>Reporter: Barry Oglesby
>Priority: Major
> Labels: Ci
> Attachments:
> TEST-org.apache.geode.internal.cache.wan.wancommand.CreateAndDestroyGatewaySenderCommandsDUnitTest.xml
>
>
> The headless gfsh command can't connect to the JMX manager in the
> {{testCreateDestroyGatewaySender_Group}} test. One interesting thing I see is
> the {{jmx-manager-port}} is re-used from the previous test.
> Here are the tests and ports. The
> {{testCreateDestroyGatewaySenderWithDefault}} and
> {{testCreateDestroyGatewaySender_Group}} use the same {{jmx-manager-port}}.
> {noformat}
> [setup] START TEST
> CreateAndDestroyGatewaySenderCommandsDUnitTest.testCreateDestroyGatewaySender_Group_Scenario2
> [vm0] distributed system properties: {name=Manager, http-service-port=23522,
> jmx-manager=true, jmx-manager-bind-address=8fe46d83e29f,
> jmx-manager-port=26506, ...
> .
> [setup] START TEST
> CreateAndDestroyGatewaySenderCommandsDUnitTest.testCreateDestroyGatewaySenderWithGatewayTransportFilters.
> [vm0] distributed system properties: {name=Manager, http-service-port=28751,
> jmx-manager=true, jmx-manager-bind-address=8fe46d83e29f,
> jmx-manager-port=27582, ...
> .
> [setup] START TEST
> CreateAndDestroyGatewaySenderCommandsDUnitTest.testCreateDestroyParallelGatewaySender.
> [vm0] distributed system properties: {name=Manager, http-service-port=21269,
> jmx-manager=true, jmx-manager-bind-address=8fe46d83e29f,
> jmx-manager-port=20691, ...
> .
> [setup] START TEST
> CreateAndDestroyGatewaySenderCommandsDUnitTest.testCreateDestroyGatewaySender.
> [vm0] distributed system properties: {name=Manager, http-service-port=25758,
> jmx-manager=true, jmx-manager-bind-address=8fe46d83e29f,
> jmx-manager-port=23804, ...
> .
> [setup] START TEST
> CreateAndDestroyGatewaySenderCommandsDUnitTest.testCreateDestroyGatewaySenderWithDefault.
> [vm0] distributed system properties: {name=Manager, http-service-port=25296,
> jmx-manager=true, jmx-manager-bind-address=8fe46d83e29f,
> jmx-manager-port=24205, ...
> .
> [setup] START TEST
> CreateAndDestroyGatewaySenderCommandsDUnitTest.testCreateDestroyGatewaySender_Group.
> [vm0] distributed system properties: {name=Manager, http-service-port=28525,
> jmx-manager=true, jmx-manager-bind-address=8fe46d83e29f,
> jmx-manager-port=24205, ...
> .
> [setup] START TEST
> CreateAndDestroyGatewaySenderCommandsDUnitTest.testCreateDestroyGatewaySender_OnMember.
> [vm0] distributed system properties: {name=Manager, http-service-port=29682,
> jmx-manager=true, jmx-manager-bind-address=8fe46d83e29f,
> jmx-manager-port=21355, ...
> .
> [setup] START TEST
> CreateAndDestroyGatewaySenderCommandsDUnitTest.testCreateDestroyGatewaySenderWithGatewayEventFilters.
> [vm0] distributed system properties: {name=Manager, http-service-port=23557,
> jmx-manager=true, jmx-manager-bind-address=8fe46d83e29f,
> jmx-manager-port=23434, ...
> {noformat}
> The {{testCreateDestroyGatewaySenderWithDefault}} test connects successfully:
> {noformat}
> CreateAndDestroyGatewaySenderCommandsDUnitTest using endpoint:
> 8fe46d83e29f[24205]
> [info 2017/08/18 20:01:10.604 UTC tid=0x16] Successfully
> connected to managing node using JMX
> {noformat}
> But the {{testCreateDestroyGatewaySender_Group}} test does not:
> {noformat}
> CreateAndDestroyGatewaySenderCommandsDUnitTest using endpoint:
> 8fe46d83e29f[24205]
> {noformat}
> If I run the test locally, all the ports are unique, and it works fine.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-3506) LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles fails intermittently with IllegalStateException: Failed to read status file
[
https://issues.apache.org/jira/browse/GEODE-3506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-3506:
--
Labels: CI (was: Ci)
> LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles fails
> intermittently with IllegalStateException: Failed to read status file
> --
>
> Key: GEODE-3506
> URL: https://issues.apache.org/jira/browse/GEODE-3506
> Project: Geode
> Issue Type: Bug
> Components: gfsh, management
>Reporter: Kirk Lund
>Priority: Major
> Labels: CI
>
> {noformat}
> org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest >
> startDeletesStaleControlFiles FAILED
> java.lang.IllegalStateException: Failed to read status file
> {noformat}
> Full stack trace:
> {noformat}
> java.lang.IllegalStateException: Failed to read status file
> at
> org.apache.geode.internal.process.FileProcessController.status(FileProcessController.java:152)
> at
> org.apache.geode.internal.process.FileProcessController.status(FileProcessController.java:89)
> at
> org.apache.geode.distributed.LocatorLauncher.statusWithWorkingDirectory(LocatorLauncher.java:940)
> at
> org.apache.geode.distributed.LocatorLauncher.status(LocatorLauncher.java:868)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.lambda$awaitStart$1(LocatorLauncherRemoteIntegrationTestCase.java:196)
> at
> org.awaitility.core.AssertionCondition$1.eval(AssertionCondition.java:55)
> at
> org.awaitility.core.ConditionAwaiter$ConditionPoller.run(ConditionAwaiter.java:215)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-3506) LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles fails intermittently with IllegalStateException: Failed to read status file
[
https://issues.apache.org/jira/browse/GEODE-3506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-3506:
--
Labels: Ci (was: )
> LocatorLauncherRemoteFileIntegrationTest.startDeletesStaleControlFiles fails
> intermittently with IllegalStateException: Failed to read status file
> --
>
> Key: GEODE-3506
> URL: https://issues.apache.org/jira/browse/GEODE-3506
> Project: Geode
> Issue Type: Bug
> Components: gfsh, management
>Reporter: Kirk Lund
>Priority: Major
> Labels: Ci
>
> {noformat}
> org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest >
> startDeletesStaleControlFiles FAILED
> java.lang.IllegalStateException: Failed to read status file
> {noformat}
> Full stack trace:
> {noformat}
> java.lang.IllegalStateException: Failed to read status file
> at
> org.apache.geode.internal.process.FileProcessController.status(FileProcessController.java:152)
> at
> org.apache.geode.internal.process.FileProcessController.status(FileProcessController.java:89)
> at
> org.apache.geode.distributed.LocatorLauncher.statusWithWorkingDirectory(LocatorLauncher.java:940)
> at
> org.apache.geode.distributed.LocatorLauncher.status(LocatorLauncher.java:868)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.lambda$awaitStart$1(LocatorLauncherRemoteIntegrationTestCase.java:196)
> at
> org.awaitility.core.AssertionCondition$1.eval(AssertionCondition.java:55)
> at
> org.awaitility.core.ConditionAwaiter$ConditionPoller.run(ConditionAwaiter.java:215)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4746) Protobuf server should catch Exceptions and return a reasonable response message to clients
[ https://issues.apache.org/jira/browse/GEODE-4746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381037#comment-16381037 ] ASF subversion and git services commented on GEODE-4746: Commit efc413ad68a73f581e9a84856c6ea379016e8b3d in geode's branch refs/heads/develop from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=efc413a ] GEODE-4746: Handle exceptions and return failures to protobuf clients Catching exceptions that happen before sending a response to the protobuf client and sending an error message to the client instead of closing the connection. Cleaning up extraneous catch blocks. > Protobuf server should catch Exceptions and return a reasonable response > message to clients > --- > > Key: GEODE-4746 > URL: https://issues.apache.org/jira/browse/GEODE-4746 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Whenever possible, the protobuf server should catch exceptions and send a > response message back to the client. Currently, any exception on the server > is causing the server to close the socket, even for trivial things like a > typo in a query string. From the client side there is no information about > why the socket was closed. > We should catch exceptions and return the error message to the client without > closing the socket. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4746) Protobuf server should catch Exceptions and return a reasonable response message to clients
[ https://issues.apache.org/jira/browse/GEODE-4746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-4746. -- Resolution: Fixed > Protobuf server should catch Exceptions and return a reasonable response > message to clients > --- > > Key: GEODE-4746 > URL: https://issues.apache.org/jira/browse/GEODE-4746 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > Whenever possible, the protobuf server should catch exceptions and send a > response message back to the client. Currently, any exception on the server > is causing the server to close the socket, even for trivial things like a > typo in a query string. From the client side there is no information about > why the socket was closed. > We should catch exceptions and return the error message to the client without > closing the socket. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-3465) GetServerRequest on Locator accepts group
[ https://issues.apache.org/jira/browse/GEODE-3465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-3465: -- Labels: pull-request-available (was: ) > GetServerRequest on Locator accepts group > - > > Key: GEODE-3465 > URL: https://issues.apache.org/jira/browse/GEODE-3465 > Project: Geode > Issue Type: New Feature > Components: client/server >Reporter: Alexander Murmann >Assignee: Michael Dodge >Priority: Major > Labels: pull-request-available > > The user should be able to specify a group for which they want to receive a > server from the locator. > Acceptance Criteria: > When making a ProtoBuf request to the locator I can pass a group to the > available server method, receiving back a server from that group or an error > if none exist. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4685) Replace setPdxReadSerialized in org.apache.geode.cache.lucene.internal
[ https://issues.apache.org/jira/browse/GEODE-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380969#comment-16380969 ] ASF subversion and git services commented on GEODE-4685: Commit cf7d083a842c11d76c9c8331df97e1b35b0cd6eb in geode's branch refs/heads/feature/GEODE-4685 from Udo [ https://gitbox.apache.org/repos/asf?p=geode.git;h=cf7d083 ] GEODE-4685: spotless > Replace setPdxReadSerialized in org.apache.geode.cache.lucene.internal > -- > > Key: GEODE-4685 > URL: https://issues.apache.org/jira/browse/GEODE-4685 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: nabarun >Assignee: Udo Kohlmeyer >Priority: Major > > Replace with the solution from GEODE-4679 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4685) Replace setPdxReadSerialized in org.apache.geode.cache.lucene.internal
[ https://issues.apache.org/jira/browse/GEODE-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380961#comment-16380961 ] ASF subversion and git services commented on GEODE-4685: Commit 883480bdff7fb7b36a9bf00faf3a8ac535181175 in geode's branch refs/heads/feature/GEODE-4685 from Udo [ https://gitbox.apache.org/repos/asf?p=geode.git;h=883480b ] GEODE-4685: added check to handle a null type registry > Replace setPdxReadSerialized in org.apache.geode.cache.lucene.internal > -- > > Key: GEODE-4685 > URL: https://issues.apache.org/jira/browse/GEODE-4685 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: nabarun >Assignee: Udo Kohlmeyer >Priority: Major > > Replace with the solution from GEODE-4679 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-3126) Add ad hoc query execution to new protocol
[ https://issues.apache.org/jira/browse/GEODE-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380959#comment-16380959 ] ASF subversion and git services commented on GEODE-3126: Commit c373f371ed530d5ddea8ea432dea174dd71a23d2 in geode's branch refs/heads/develop from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c373f37 ] GEODE-3126: Adding a query command to the experimental driver Adding a QueryService and query operations to the experimental client. > Add ad hoc query execution to new protocol > -- > > Key: GEODE-3126 > URL: https://issues.apache.org/jira/browse/GEODE-3126 > Project: Geode > Issue Type: New Feature > Components: client/server >Reporter: Brian Baynes >Priority: Major > Labels: pull-request-available > Time Spent: 2h 40m > Remaining Estimate: 0h > > As a Geode developer using the new client/server protocol, I need to be able > to send queries and receive expected results. > Add ad hoc query execution to new protocol. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3126) Add ad hoc query execution to new protocol
[ https://issues.apache.org/jira/browse/GEODE-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Smith resolved GEODE-3126. -- Resolution: Fixed > Add ad hoc query execution to new protocol > -- > > Key: GEODE-3126 > URL: https://issues.apache.org/jira/browse/GEODE-3126 > Project: Geode > Issue Type: New Feature > Components: client/server >Reporter: Brian Baynes >Priority: Major > Labels: pull-request-available > Time Spent: 2h 40m > Remaining Estimate: 0h > > As a Geode developer using the new client/server protocol, I need to be able > to send queries and receive expected results. > Add ad hoc query execution to new protocol. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-3752) Rolling upgrade dunit test timed out reading cluster config
[
https://issues.apache.org/jira/browse/GEODE-3752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-3752:
--
Labels: Ci (was: )
> Rolling upgrade dunit test timed out reading cluster config
> ---
>
> Key: GEODE-3752
> URL: https://issues.apache.org/jira/browse/GEODE-3752
> Project: Geode
> Issue Type: Bug
> Components: management
>Reporter: Barry Oglesby
>Priority: Major
> Labels: Ci
> Attachments: Test results - Class
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.html, Test
> results - Class
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.webarchive
>
>
> {noformat}
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit >
> luceneQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion[0]
> FAILED
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit$6.run in VM
> 0 running on Host 22736e3d23d7 with 4 VMs with version 120
> at org.apache.geode.test.dunit.VM.execute(VM.java:469)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:386)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:363)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:308)
> at
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.invokeRunnableInVMs(LuceneSearchWithRollingUpgradeDUnit.java:560)
> at
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.executeLuceneQueryWithServerRollOvers(LuceneSearchWithRollingUpgradeDUnit.java:427)
> at
> org.apache.geode.cache.lucene.LuceneSearchWithRollingUpgradeDUnit.luceneQueryReturnsCorrectResultsAfterServersRollOverOnPartitionRegion(LuceneSearchWithRollingUpgradeDUnit.java:132)
> Caused by:
> java.rmi.UnmarshalException: error unmarshalling return; nested
> exception is:
> java.lang.ClassNotFoundException:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException
> (no security manager: RMI class loader disabled)
> at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:194)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invokeRemoteMethod(RemoteObjectInvocationHandler.java:227)
> at
> java.rmi.server.RemoteObjectInvocationHandler.invoke(RemoteObjectInvocationHandler.java:179)
> at com.sun.proxy.$Proxy37.executeMethodOnObject(Unknown Source)
> at org.apache.geode.test.dunit.VM.execute(VM.java:466)
> ... 6 more
> Caused by:
> java.lang.ClassNotFoundException:
> org.apache.geode.internal.process.ClusterConfigurationNotAvailableException
> (no security manager: RMI class loader disabled)
> at
> sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:396)
> at
> sun.rmi.server.LoaderHandler.loadClass(LoaderHandler.java:186)
> at
> java.rmi.server.RMIClassLoader$2.loadClass(RMIClassLoader.java:637)
> at
> java.rmi.server.RMIClassLoader.loadClass(RMIClassLoader.java:264)
> at
> sun.rmi.server.MarshalInputStream.resolveClass(MarshalInputStream.java:219)
> at
> java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1826)
> at
> java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1713)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2000)
> at
> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535)
> at
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2245)
> at
> java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:552)
> at java.lang.Throwable.readObject(Throwable.java:914)
> 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
> java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:1058)
> at
> java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:2136)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:2027)
> at
> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1535)
> at
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:2245)
> at
>
[jira] [Updated] (GEODE-3692) Intermittent test failure: ClientAuthDUnitTest
[
https://issues.apache.org/jira/browse/GEODE-3692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-3692:
--
Labels: Ci (was: )
> Intermittent test failure: ClientAuthDUnitTest
> --
>
> Key: GEODE-3692
> URL: https://issues.apache.org/jira/browse/GEODE-3692
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.2.1
>Reporter: Kenneth Howe
>Priority: Major
> Labels: Ci
>
> This {{authWithCorrectPasswordShouldPass}} fails intermittently in Geode
> nightly builds.
> {code}
> [vm1] [info 2017/09/19 21:27:57.967 UTC tid=0x1bc]
> Error prefilling connections :
> org.apache.geode.security.AuthenticationFailedException: No SecurityManager
> accessible to the calling code, either bound to the
> org.apache.shiro.util.ThreadContext or as a vm static singleton. This is an
> invalid application configuration.
> [vm1] org.apache.geode.security.AuthenticationFailedException: No
> SecurityManager accessible to the calling code, either bound to the
> org.apache.shiro.util.ThreadContext or as a vm static singleton. This is an
> invalid application configuration.
> [vm1] at
> org.apache.geode.internal.cache.tier.sockets.HandShake.verifyCredentials(HandShake.java:1696)
> [vm1] at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.setCredentials(ServerConnection.java:1029)
> [vm1] at
> org.apache.geode.internal.cache.tier.sockets.command.PutUserCredentials.cmdExecute(PutUserCredentials.java:52)
> [vm1] at
> org.apache.geode.internal.cache.tier.sockets.BaseCommand.execute(BaseCommand.java:162)
> [vm1] at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.doNormalMsg(ServerConnection.java:785)
> [vm1] at
> org.apache.geode.internal.cache.tier.sockets.LegacyServerConnection.doOneMessage(LegacyServerConnection.java:85)
> [vm1] at
> org.apache.geode.internal.cache.tier.sockets.ServerConnection.run(ServerConnection.java:1166)
> [vm1] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [vm1] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [vm1] at
> org.apache.geode.internal.cache.tier.sockets.AcceptorImpl$1$1.run(AcceptorImpl.java:557)
> [vm1] at java.lang.Thread.run(Thread.java:748)
> [vm1] Caused by: org.apache.shiro.UnavailableSecurityManagerException: No
> SecurityManager accessible to the calling code, either bound to the
> org.apache.shiro.util.ThreadContext or as a vm static singleton. This is an
> invalid application configuration.
> [vm1] at
> org.apache.shiro.SecurityUtils.getSecurityManager(SecurityUtils.java:123)
> [vm1] at
> org.apache.shiro.subject.Subject$Builder.(Subject.java:627)
> [vm1] at
> org.apache.shiro.SecurityUtils.getSubject(SecurityUtils.java:56)
> [vm1] at
> org.apache.geode.internal.security.IntegratedSecurityService.login(IntegratedSecurityService.java:133)
> [vm1] at
> org.apache.geode.internal.cache.tier.sockets.HandShake.verifyCredentials(HandShake.java:1686)
> [vm1] ... 10 more
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-3663) Remove test hook from DSClock
[ https://issues.apache.org/jira/browse/GEODE-3663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-3663: -- Labels: Ci (was: ) > Remove test hook from DSClock > - > > Key: GEODE-3663 > URL: https://issues.apache.org/jira/browse/GEODE-3663 > Project: Geode > Issue Type: Sub-task > Components: general, management, tests >Reporter: Patrick Rhomberg >Priority: Major > Labels: Ci > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-3778) FileProcessControllerIntegrationTest.status_withStatusRequestFileExists_doesNotFail fails intermittently
[
https://issues.apache.org/jira/browse/GEODE-3778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-3778:
--
Labels: Ci (was: )
> FileProcessControllerIntegrationTest.status_withStatusRequestFileExists_doesNotFail
> fails intermittently
>
>
> Key: GEODE-3778
> URL: https://issues.apache.org/jira/browse/GEODE-3778
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Kirk Lund
>Priority: Major
> Labels: Ci
>
> FileProcessControllerIntegrationTest tests FileProcessController which GFSH
> uses to control running Locator and Server processes.
> So far this test has failed 3 times in CI with 2 different stacks:
> {noformat}
> org.apache.geode.internal.process.FileProcessControllerIntegrationTest >
> status_withStatusRequestFileExists_doesNotFail FAILED
> java.lang.AssertionError:
> Expecting file:
>
> to exist.
> at
> org.apache.geode.internal.process.io.StringFileWriter.writeToFile(StringFileWriter.java:40)
> at
> org.apache.geode.internal.process.FileProcessControllerIntegrationTest.status_withStatusRequestFileExists_doesNotFail(FileProcessControllerIntegrationTest.java:212)
> {noformat}
> {noformat}
> org.apache.geode.internal.process.FileProcessControllerIntegrationTest >
> status_withStatusRequestFileExists_doesNotFail FAILED
> java.lang.InterruptedException: sleep interrupted
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.geode.internal.process.FileProcessController.status(FileProcessController.java:143)
> at
> org.apache.geode.internal.process.FileProcessController.status(FileProcessController.java:89)
> at
> org.apache.geode.internal.process.FileProcessControllerIntegrationTest.lambda$status_withStatusRequestFileExists_doesNotFail$4(FileProcessControllerIntegrationTest.java:206)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-3720) CI Failure: ConnectCommandWithSSLTest failed
[ https://issues.apache.org/jira/browse/GEODE-3720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-3720: -- Labels: ci (was: ) > CI Failure: ConnectCommandWithSSLTest failed > > > Key: GEODE-3720 > URL: https://issues.apache.org/jira/browse/GEODE-3720 > Project: Geode > Issue Type: Bug >Affects Versions: 1.2.1 >Reporter: Jinmei Liao >Assignee: Kenneth Howe >Priority: Major > Labels: ci > > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest > > connectWithSSL FAILED > org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithSSL(ConnectCommandWithSSLTest.java:198) > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest > > connectWithNoSSL FAILED > org.junit.ComparisonFailure: expected:<[fals]e> but was:<[tru]e> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithNoSSL(ConnectCommandWithSSLTest.java:177) > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest > > connectWithClusterAndJmxSSL FAILED > org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithClusterAndJmxSSL(ConnectCommandWithSSLTest.java:309) > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest > > connectWithSSLAndThenWithNoSSL FAILED > org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithSSLAndThenWithNoSSL(ConnectCommandWithSSLTest.java:320) > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest > > connectWithHttpSSLAndSkipSSLValidation FAILED > org.junit.ComparisonFailure: expected:<[fals]e> but was:<[tru]e> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithHttpSSLAndSkipSSLValidation(ConnectCommandWithSSLTest.java:286) > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest > > connectWithClusterSSL FAILED > org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e> > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest.connectWithClusterSSL(ConnectCommandWithSSLTest.java:246) > org.apache.geode.management.internal.cli.commands.ConnectCommandWithSSLTest > > connectWithJmxSSL FAILED > java.lang.AssertionError: > Expecting: > <"_ __ >/ _/ __/ __/ // / > / / __/ /___ /_ / _ / > / /__/ / / _/ / // / > /__/_/ /__/_//_/0.0.0 > > Monitor and Manage Pivotal GemFire > Connecting to
[jira] [Updated] (GEODE-3917) [CI Failure] [Nightly #995] org.apache.geode.internal.cache.wan.misc.NewWanAuthenticationDUnitTest.testWanAuthValidCredentials
[
https://issues.apache.org/jira/browse/GEODE-3917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-3917:
--
Labels: Ci (was: )
> [CI Failure] [Nightly #995]
> org.apache.geode.internal.cache.wan.misc.NewWanAuthenticationDUnitTest.testWanAuthValidCredentials
> --
>
> Key: GEODE-3917
> URL: https://issues.apache.org/jira/browse/GEODE-3917
> Project: Geode
> Issue Type: Bug
> Components: security
>Affects Versions: 1.4.0
>Reporter: nabarun
>Priority: Major
> Labels: Ci
>
> Error Message
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.misc.NewWanAuthenticationDUnitTest$$Lambda$73/735044920.run
> in VM 2 running on Host 7c4d06bbbc13 with 8 VMs
> {noformat}
> Stacktrace
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.misc.NewWanAuthenticationDUnitTest$$Lambda$73/735044920.run
> in VM 2 running on Host 7c4d06bbbc13 with 8 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:393)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:363)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:308)
> at
> org.apache.geode.internal.cache.wan.misc.NewWanAuthenticationDUnitTest.testWanAuthValidCredentials(NewWanAuthenticationDUnitTest.java:113)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java: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.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> 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.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:109)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
[jira] [Updated] (GEODE-3835) DistributedSystemBridgeJUnitTest should use TemporaryFolder
[ https://issues.apache.org/jira/browse/GEODE-3835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-3835: -- Labels: Ci starter (was: starter) > DistributedSystemBridgeJUnitTest should use TemporaryFolder > --- > > Key: GEODE-3835 > URL: https://issues.apache.org/jira/browse/GEODE-3835 > Project: Geode > Issue Type: Improvement > Components: jmx, management, tests >Reporter: Kirk Lund >Priority: Major > Labels: Ci, starter > > DistributedSystemBridgeJUnitTest should use TemporaryFolder instead of "/tmp". > [separated DistributedSystemBridgeJUnitTest from GEODE-1338] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-3939) CI Failure: DeprecatedCacheServerLauncherIntegrationTest
[
https://issues.apache.org/jira/browse/GEODE-3939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-3939:
--
Labels: Ci (was: CI)
> CI Failure: DeprecatedCacheServerLauncherIntegrationTest
>
>
> Key: GEODE-3939
> URL: https://issues.apache.org/jira/browse/GEODE-3939
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Priority: Trivial
> Labels: Ci
>
> {noformat}
> org.apache.geode.internal.cache.DeprecatedCacheServerLauncherIntegrationTest
> > testCreateBuckets FAILED
> java.lang.AssertionError: Timed out waiting for output "CacheServer pid:
> \d+ status: running" after 12 ms. Output:
> Starting CacheServer with pid: 0
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.test.process.ProcessWrapper.waitForOutputToMatch(ProcessWrapper.java:222)
> at
> org.apache.geode.internal.cache.DeprecatedCacheServerLauncherIntegrationTest.execAndValidate(DeprecatedCacheServerLauncherIntegrationTest.java:435)
> at
> org.apache.geode.internal.cache.DeprecatedCacheServerLauncherIntegrationTest.testCreateBuckets(DeprecatedCacheServerLauncherIntegrationTest.java:285)
> {noformat}
> STDOUT:
> {noformat}
> java.lang.AssertionError: Timed out waiting for output "CacheServer pid: \d+
> status: running" after 12 ms. Output:
> Starting CacheServer with pid: 0
> at org.junit.Assert.fail(Assert.java:88)
> at
> org.apache.geode.test.process.ProcessWrapper.waitForOutputToMatch(ProcessWrapper.java:222)
> at
> org.apache.geode.internal.cache.DeprecatedCacheServerLauncherIntegrationTest.execAndValidate(DeprecatedCacheServerLauncherIntegrationTest.java:435)
> at
> org.apache.geode.internal.cache.DeprecatedCacheServerLauncherIntegrationTest.testCreateBuckets(DeprecatedCacheServerLauncherIntegrationTest.java:285)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java: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.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> 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.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
>
[jira] [Updated] (GEODE-3918) [CI Failure][Nightly #995] org.apache.geode.internal.cache.wan.misc.NewWanAuthenticationDUnitTest.testWanAuthValidCredentialsWithServer
[
https://issues.apache.org/jira/browse/GEODE-3918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-3918:
--
Labels: Ci (was: )
> [CI Failure][Nightly #995]
> org.apache.geode.internal.cache.wan.misc.NewWanAuthenticationDUnitTest.testWanAuthValidCredentialsWithServer
>
>
>
> Key: GEODE-3918
> URL: https://issues.apache.org/jira/browse/GEODE-3918
> Project: Geode
> Issue Type: Bug
> Components: security
>Reporter: nabarun
>Priority: Major
> Labels: Ci
>
> Error Message
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.misc.NewWanAuthenticationDUnitTest$$Lambda$98/282340316.run
> in VM 2 running on Host 7c4d06bbbc13 with 8 VMs
> {noformat}
> Stacktrace
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.internal.cache.wan.misc.NewWanAuthenticationDUnitTest$$Lambda$98/282340316.run
> in VM 2 running on Host 7c4d06bbbc13 with 8 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:393)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:363)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:308)
> at
> org.apache.geode.internal.cache.wan.misc.NewWanAuthenticationDUnitTest.testWanAuthValidCredentialsWithServer(NewWanAuthenticationDUnitTest.java:411)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java: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.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> 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.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:109)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
[jira] [Resolved] (GEODE-4695) PluckStacks utility is confused by Attach Listener thread dump
[ https://issues.apache.org/jira/browse/GEODE-4695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt resolved GEODE-4695. - Resolution: Fixed Fix Version/s: 1.5.0 > PluckStacks utility is confused by Attach Listener thread dump > -- > > Key: GEODE-4695 > URL: https://issues.apache.org/jira/browse/GEODE-4695 > Project: Geode > Issue Type: Bug > Components: general >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 50m > Remaining Estimate: 0h > > If a thread dump has an Attach Listener stack it will usually contain no > stack and will confuse PluckStacks, resulting in no stacks being found. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4695) PluckStacks utility is confused by Attach Listener thread dump
[ https://issues.apache.org/jira/browse/GEODE-4695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380936#comment-16380936 ] ASF subversion and git services commented on GEODE-4695: Commit 4fd969ee0d74e3d896fba328e63ed799117cd346 in geode's branch refs/heads/develop from [~bschuchardt] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=4fd969e ] GEODE-4695 PluckStacks utility is confused by Attach Listener thread dump Adding unit tests for the PluckStacks utility and fixing it to work with gfsh-exported dumps as well as jstack-generated dumps. This closes #1471 > PluckStacks utility is confused by Attach Listener thread dump > -- > > Key: GEODE-4695 > URL: https://issues.apache.org/jira/browse/GEODE-4695 > Project: Geode > Issue Type: Bug > Components: general >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > If a thread dump has an Attach Listener stack it will usually contain no > stack and will confuse PluckStacks, resulting in no stacks being found. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-4182) JDBC connector exception handling needs improvement
[ https://issues.apache.org/jira/browse/GEODE-4182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Reich reassigned GEODE-4182: - Assignee: Nick Reich (was: Kirk Lund) > JDBC connector exception handling needs improvement > --- > > Key: GEODE-4182 > URL: https://issues.apache.org/jira/browse/GEODE-4182 > Project: Geode > Issue Type: Improvement > Components: extensions >Reporter: Darrel Schneider >Assignee: Nick Reich >Priority: Major > > The JDBC connector currently has multiple places it catches SQLException and > turns around and throws IllegalStateException. It should instead throw a new > exception that is dedicated to the jdbc connector. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (GEODE-4451) When a gateway sender is created using gfsh and fails to connect due to AuthenticationFailedException, it is left in an inconsistent state
[
https://issues.apache.org/jira/browse/GEODE-4451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16350828#comment-16350828
]
Diane Hardman edited comment on GEODE-4451 at 2/28/18 7:35 PM:
---
If the gateway sender fails authentication with the receiver, the exception
should be thrown and the gateway sender should retry to connection.
was (Author: dhardman):
If the gateway sender fails authentication with the receiver, the exception
should be thrown and the gateway sender should be destroyed.
> When a gateway sender is created using gfsh and fails to connect due to
> AuthenticationFailedException, it is left in an inconsistent state
> --
>
> Key: GEODE-4451
> URL: https://issues.apache.org/jira/browse/GEODE-4451
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barry Oglesby
>Priority: Major
>
> If I attempt to create a gateway sender with invalid credentials using gfsh,
> it fails like:
> {noformat}
> (2) Executing - create gateway-sender --remote-distributed-system-id=1
> --id=ny --dispatcher-threads=1 --parallel=true
> Member | Status
> -- |
> --
> ln-1 | ERROR: Could not start a gateway sender ny because of exception Could
> not start a gateway sender 84 because of exception
> org.apache.geode.security.AuthenticationFailedException: Authentication
> error. Please check your credentials.
> {noformat}
> The 84 should be the gateway sender id; instead its the thread id (from
> \{{ConcurrentParallelGatewaySenderEventProcessor.waitForRunningStatus}}.
> In the server log, I see 5 AuthenticationFailedException stacks like (one per
> dispatcher-thread):
> {noformat}
> [severe 2018/01/31 16:13:12.638 PST ln-1 GatewaySender_ny_0> tid=0x55] Message dispatch failed due to unexpected
> exception..
> org.apache.geode.internal.cache.wan.GatewaySenderException:
> org.apache.geode.security.AuthenticationFailedException: Authentication
> error. Please check your credentials., caused by
> org.apache.geode.security.AuthenticationFailedException: Authentication
> error. Please check your credentials.
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:432)
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:75)
> at
> org.apache.geode.internal.cache.wan.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemoteParallelGatewaySenderEventProcessor.java:74)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.setRunningStatus(AbstractGatewaySenderEventProcessor.java:1078)
> at
> org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.run(AbstractGatewaySenderEventProcessor.java:1050)
> Caused by: org.apache.geode.security.AuthenticationFailedException:
> Authentication error. Please check your credentials.
> at
> org.apache.geode.internal.cache.tier.sockets.HandShake.readMessage(HandShake.java:1397)
> at
> org.apache.geode.internal.cache.tier.sockets.HandShake.handshakeWithServer(HandShake.java:1253)
> at
> org.apache.geode.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:118)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:136)
> at
> org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:259)
> at
> org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:206)
> at
> org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:902)
> at
> org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:388)
> ... 4 more
> {noformat}
> A thread dump shows the Event Processor threads are gone, but 5
> BatchRemovalThreads like this exist:
> {noformat}
> "BatchRemovalThread" #96 daemon prio=10 os_prio=31 tid=0x7fc1dd009000
> nid=0xcb03 waiting on condition [0x7e245000]
> java.lang.Thread.State: TIMED_WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x0007a04043c8> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
> at
>
[jira] [Commented] (GEODE-3948) Improve CQ performance under flaky network conditions
[ https://issues.apache.org/jira/browse/GEODE-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380917#comment-16380917 ] ASF subversion and git services commented on GEODE-3948: Commit 0a6eebdffc9dd1f0393629e43e1f33ff8c71a7f7 in geode's branch refs/heads/develop from [~bschuchardt] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0a6eebd ] GEODE-3948 Improve CQ performance under flaky network conditions Adding new pool setting to XSD so it can be configured in cache.xml This closes #1520 > Improve CQ performance under flaky network conditions > - > > Key: GEODE-3948 > URL: https://issues.apache.org/jira/browse/GEODE-3948 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Galen O'Sullivan >Assignee: Dave Barnes >Priority: Minor > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Client CQ connections occasionally stop receiving messages and become blocked > indefinitely. > This can be caused by a server that hangs or dies without sending a close > message, or by some firewalls. > The client already gets ping messages from the server, but currently ignores > them. Let's use those messages to detect a failed connection and close it. > Probably the client should follow the same logic and send ping messages if it > has sent no acks for a while, so that the server can also detect and close a > broken connection. > The timeout could be specified as a number and time interval, the ping > interval and the number of missed pings after which to fail. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4411) Normalize AttributesFactory to match other factories.
[
https://issues.apache.org/jira/browse/GEODE-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-4411:
--
Labels: pull-request-available (was: )
> Normalize AttributesFactory to match other factories.
> -
>
> Key: GEODE-4411
> URL: https://issues.apache.org/jira/browse/GEODE-4411
> Project: Geode
> Issue Type: Task
> Components: native client
>Reporter: Jacob S. Barrett
>Priority: Major
> Labels: pull-request-available
>
> {{AttributesFactory::createRegionAttributes}} should be renamed to {{create}}
> and should return a value rather than a pointer.
> {{AttributesFactory}} constructor should probably take value of
> {{RegionAttributes}} and not pointer.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-3126) Add ad hoc query execution to new protocol
[ https://issues.apache.org/jira/browse/GEODE-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380906#comment-16380906 ] ASF subversion and git services commented on GEODE-3126: Commit b730a430b50b5d847ae8c029a5c7ac12cbc315b7 in geode's branch refs/heads/develop from Dan Smith [ https://gitbox.apache.org/repos/asf?p=geode.git;h=b730a43 ] GEODE-3126: Adding a query message to the protobuf protocol Adding an oql query request and response to the new protocol. > Add ad hoc query execution to new protocol > -- > > Key: GEODE-3126 > URL: https://issues.apache.org/jira/browse/GEODE-3126 > Project: Geode > Issue Type: New Feature > Components: client/server >Reporter: Brian Baynes >Priority: Major > Labels: pull-request-available > Time Spent: 2.5h > Remaining Estimate: 0h > > As a Geode developer using the new client/server protocol, I need to be able > to send queries and receive expected results. > Add ad hoc query execution to new protocol. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4362) view preparation throws uncaught RuntimeException
[
https://issues.apache.org/jira/browse/GEODE-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380878#comment-16380878
]
ASF subversion and git services commented on GEODE-4362:
Commit 0afb75bbaef7dfba7bfba70d8de0617c30db99c2 in geode's branch
refs/heads/develop from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0afb75b ]
GEODE-4362: view preparation throws uncaught RuntimeException
The problem was happening when a new member joined with a coordinator that
suddenly shuts down before other members have been told to install the
new membership view. They've received a "prepare for view change" message
containing the new view but have not been told to commit that change.
Another member then becomes coordinator and sees that there was a new member
in the prepared view. It picks this up and adds it to the new view it
sends out.
The problem was that the public encryption keys of the members weren't
being transferred from the old view to the new view and when looking for
public keys we were fishing them out of GMSEncrypt instead of getting
them from the membership view. This caused an NPE to be thrown when trying
to fish out the public key of the new member - GMSEncrypt didn't know about
this new member because the view containing it was never installed - it
was only prepared.
The fix is to transfer the public keys from the old view to the new one and
to look for public keys in the view instead of GMSEncrypt.
This closes #1520
> view preparation throws uncaught RuntimeException
> -
>
> Key: GEODE-4362
> URL: https://issues.apache.org/jira/browse/GEODE-4362
> Project: Geode
> Issue Type: Bug
> Components: membership
>Reporter: Bruce Schuchardt
>Assignee: Galen O'Sullivan
>Priority: Major
>
> I put a pause in Services.installView() before the view is passed to the
> Messenger service and ran
> LocatorUDPSecurityDUnitTest.testCollocatedLocatorWithSecurity() and
> encountered a RuntimeException:
> {noformat}
> [vm1] java.lang.RuntimeException: Not found public key for member
> 10.118.20.12(68202):32773
> [vm1] at
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPublicKey(GMSEncrypt.java:178)
> [vm1] at
> org.apache.geode.distributed.internal.membership.gms.messenger.JGroupsMessenger.getPublicKey(JGroupsMessenger.java:1367)
> [vm1] at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.addPublicKeysToView(GMSJoinLeave.java:933)
> [vm1] at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.sendView(GMSJoinLeave.java:896)
> [vm1] at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave.prepareView(GMSJoinLeave.java:838)
> [vm1] at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.prepareAndSendView(GMSJoinLeave.java:2385)
> [vm1] at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.sendInitialView(GMSJoinLeave.java:2031)
> [vm1] at
> org.apache.geode.distributed.internal.membership.gms.membership.GMSJoinLeave$ViewCreator.run(GMSJoinLeave.java:2091)
> [vm1] Caused by: java.lang.NullPointerException
> [vm1] at
> java.security.spec.EncodedKeySpec.(EncodedKeySpec.java:56)
> [vm1] at
> java.security.spec.X509EncodedKeySpec.(X509EncodedKeySpec.java:64)
> [vm1] at
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPublicKey(GMSEncrypt.java:545)
> [vm1] at
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt$PeerEncryptor.(GMSEncrypt.java:377)
> [vm1] at
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.createPeerEncryptor(GMSEncrypt.java:301)
> [vm1] at
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPeerEncryptor(GMSEncrypt.java:259)
> [vm1] at
> org.apache.geode.distributed.internal.membership.gms.messenger.GMSEncrypt.getPublicKey(GMSEncrypt.java:176)
> [vm1] ... 7 more
> {noformat}
> Since GMSJoinLeave already had the new view installed and JGroupsMessenger
> did not have the new view installed we were unable to find the public key for
> one of the recipients of the new view. View preparation should probably be
> synchronized with view installation so that both aren't done in parallel.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4672) Geode fails to start with JDK 9 if validate-serializable-objects is set
[
https://issues.apache.org/jira/browse/GEODE-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380871#comment-16380871
]
ASF subversion and git services commented on GEODE-4672:
Commit aa381d8d0c2c8eb18dded96a038b2bb59e36b67d in geode's branch
refs/heads/feature/GEODE-4672 from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=aa381d8 ]
GEODE-4672 spot removal
> Geode fails to start with JDK 9 if validate-serializable-objects is set
>
>
> Key: GEODE-4672
> URL: https://issues.apache.org/jira/browse/GEODE-4672
> Project: Geode
> Issue Type: Sub-task
> Components: serialization
>Reporter: Dan Smith
>Priority: Major
> Labels: pull-request-available
>
> If the validate-serializable-objects property is set, Geode fails to start
> with the below exception. This is problematic for running the geode tests
> with JDK 9 because our tests set this property
> {noformat}
> java.lang.RuntimeException: Unable to launch dunit VMs
> at
> org.apache.geode.test.dunit.standalone.DUnitLauncher.launchIfNeeded(DUnitLauncher.java:162)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.initializeDistributedTestCase(JUnit4DistributedTestCase.java:128)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> 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.RunBefores.evaluate(RunBefores.java:24)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: java.lang.RuntimeException: Failed to start locator
> at
> org.apache.geode.test.dunit.standalone.DUnitLauncher.startLocator(DUnitLauncher.java:331)
> at
> org.apache.geode.test.dunit.standalone.DUnitLauncher.launch(DUnitLauncher.java:241)
> at
> org.apache.geode.test.dunit.standalone.DUnitLauncher.launchIfNeeded(DUnitLauncher.java:160)
> ... 15 more
> Caused by: org.apache.geode.GemFireConfigException: A serialization filter
> has been specified but this version of Java does not support serialization
> filters - sun.misc.ObjectInputFilter is not available
> at
> org.apache.geode.internal.InternalDataSerializer.initialize(InternalDataSerializer.java:235)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:691)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:340)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:320)
> at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:211)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:634)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:309)
> at org.apache.geode.distributed.Locator.startLocator(Locator.java:253)
> at
> org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:140)
> at
> org.apache.geode.test.dunit.standalone.DUnitLauncher$2.call(DUnitLauncher.java:320)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4745) CI Failure : entriesFlushedToIndexAfterWaitForFlushCalled
[ https://issues.apache.org/jira/browse/GEODE-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380867#comment-16380867 ] ASF subversion and git services commented on GEODE-4745: Commit 0e36a99205bee12e29a99e9e82e59e889161a0be in geode's branch refs/heads/develop from [~nnag] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=0e36a99 ] GEODE-4745: Stat check asserts modified * The assert check for the lucene commit checks have been modified to address the fact that it is not deterministic * The reindex thread may be faster than the puts being done by the test hence the number of commits may different depending on whether the puts were faster or the reindexing thread. > CI Failure : entriesFlushedToIndexAfterWaitForFlushCalled > - > > Key: GEODE-4745 > URL: https://issues.apache.org/jira/browse/GEODE-4745 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: nabarun >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > org.apache.geode.cache.lucene.LuceneIndexMaintenanceIntegrationTest > > entriesFlushedToIndexAfterWaitForFlushCalled FAILED > java.lang.AssertionError: expected:<8> but was:<7> > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.failNotEquals(Assert.java:834) > at org.junit.Assert.assertEquals(Assert.java:645) > at org.junit.Assert.assertEquals(Assert.java:631) > at > org.apache.geode.cache.lucene.LuceneIndexMaintenanceIntegrationTest.entriesFlushedToIndexAfterWaitForFlushCalled(LuceneIndexMaintenanceIntegrationTest.java:277) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4733) Replace and remove trivial methods from ObjectUtils
[
https://issues.apache.org/jira/browse/GEODE-4733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380869#comment-16380869
]
ASF subversion and git services commented on GEODE-4733:
Commit 4ad633773b1fffe9ce5a71ea95fc5410d54d90fc in geode's branch
refs/heads/develop from [~prhomberg]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=4ad6337 ]
GEODE-4733: Remove unused and inline trivial ObjectUtils methods.
> Replace and remove trivial methods from ObjectUtils
> ---
>
> Key: GEODE-4733
> URL: https://issues.apache.org/jira/browse/GEODE-4733
> Project: Geode
> Issue Type: Sub-task
>Reporter: Patrick Rhomberg
>Assignee: Patrick Rhomberg
>Priority: Major
> Labels: pull-request-available
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> For instance, {{defaultIfNull(T... values)}} is exclusively called with two
> input parameters, while the method name and signature makes it unclear that
> the second value is meant to be the default value if the first parameter is
> null.
> This method can be cleanly replaced by a ternary {{v1 != null ? v1 : v2}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4685) Replace setPdxReadSerialized in org.apache.geode.cache.lucene.internal
[ https://issues.apache.org/jira/browse/GEODE-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380853#comment-16380853 ] ASF subversion and git services commented on GEODE-4685: Commit c8ddf7e4dac572fd60c9d6eddcd4c7419f60f4c3 in geode's branch refs/heads/feature/GEODE-4685 from Udo [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c8ddf7e ] GEODE-4685: Spotless > Replace setPdxReadSerialized in org.apache.geode.cache.lucene.internal > -- > > Key: GEODE-4685 > URL: https://issues.apache.org/jira/browse/GEODE-4685 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: nabarun >Assignee: Udo Kohlmeyer >Priority: Major > > Replace with the solution from GEODE-4679 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-3465) GetServerRequest on Locator accepts group
[ https://issues.apache.org/jira/browse/GEODE-3465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dodge reassigned GEODE-3465: Assignee: Michael Dodge > GetServerRequest on Locator accepts group > - > > Key: GEODE-3465 > URL: https://issues.apache.org/jira/browse/GEODE-3465 > Project: Geode > Issue Type: New Feature > Components: client/server >Reporter: Alexander Murmann >Assignee: Michael Dodge >Priority: Major > > The user should be able to specify a group for which they want to receive a > server from the locator. > Acceptance Criteria: > When making a ProtoBuf request to the locator I can pass a group to the > available server method, receiving back a server from that group or an error > if none exist. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4672) Geode fails to start with JDK 9 if validate-serializable-objects is set
[
https://issues.apache.org/jira/browse/GEODE-4672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380804#comment-16380804
]
ASF subversion and git services commented on GEODE-4672:
Commit eccd68974317c6f1d7d7fb27c115282cdab13f2f in geode's branch
refs/heads/feature/GEODE-4672 from [~bschuchardt]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=eccd689 ]
GEODE-4672 Geode fails to start with JDK 9 if validate-serializable-objects is
set
The ObjectInputFilter wrapper now uses reflection and a dynamic
proxy to interact with the serialization filter classes. A dynamic
proxy is needed since we have to implement a method specified in
a class whose package has changed in the JDK. The logic of the filter
has not been changed.
I also replaced a couple of recently added white-list wildcards with specific
classes and added a javadoc for the whitelist in InternalDataSerializer.
I opened a new JIRA ticket concerning another wildcard that was recently
added for the JDBC connector and left a TODO in place for this.
> Geode fails to start with JDK 9 if validate-serializable-objects is set
>
>
> Key: GEODE-4672
> URL: https://issues.apache.org/jira/browse/GEODE-4672
> Project: Geode
> Issue Type: Sub-task
> Components: serialization
>Reporter: Dan Smith
>Priority: Major
>
> If the validate-serializable-objects property is set, Geode fails to start
> with the below exception. This is problematic for running the geode tests
> with JDK 9 because our tests set this property
> {noformat}
> java.lang.RuntimeException: Unable to launch dunit VMs
> at
> org.apache.geode.test.dunit.standalone.DUnitLauncher.launchIfNeeded(DUnitLauncher.java:162)
> at
> org.apache.geode.test.dunit.internal.JUnit4DistributedTestCase.initializeDistributedTestCase(JUnit4DistributedTestCase.java:128)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> 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.RunBefores.evaluate(RunBefores.java:24)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:68)
> at
> com.intellij.rt.execution.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:47)
> at
> com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:242)
> at
> com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:70)
> Caused by: java.lang.RuntimeException: Failed to start locator
> at
> org.apache.geode.test.dunit.standalone.DUnitLauncher.startLocator(DUnitLauncher.java:331)
> at
> org.apache.geode.test.dunit.standalone.DUnitLauncher.launch(DUnitLauncher.java:241)
> at
> org.apache.geode.test.dunit.standalone.DUnitLauncher.launchIfNeeded(DUnitLauncher.java:160)
> ... 15 more
> Caused by: org.apache.geode.GemFireConfigException: A serialization filter
> has been specified but this version of Java does not support serialization
> filters - sun.misc.ObjectInputFilter is not available
> at
> org.apache.geode.internal.InternalDataSerializer.initialize(InternalDataSerializer.java:235)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:691)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:340)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:326)
> at
> org.apache.geode.distributed.internal.InternalDistributedSystem.newInstance(InternalDistributedSystem.java:320)
> at
> org.apache.geode.distributed.DistributedSystem.connect(DistributedSystem.java:211)
> at
> org.apache.geode.distributed.internal.InternalLocator.startDistributedSystem(InternalLocator.java:634)
> at
> org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:309)
> at org.apache.geode.distributed.Locator.startLocator(Locator.java:253)
>
[jira] [Resolved] (GEODE-4402) Log exceptions to server log
[ https://issues.apache.org/jira/browse/GEODE-4402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dodge resolved GEODE-4402. -- Resolution: Fixed Fix Version/s: 1.5.0 > Log exceptions to server log > > > Key: GEODE-4402 > URL: https://issues.apache.org/jira/browse/GEODE-4402 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Brian Baynes >Assignee: Michael Dodge >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 20m > Remaining Estimate: 0h > > When the new protocol handles an exception, it should write the exception to > the server log (even if it only sends back an error to the client) -- this > will help in debugging efforts. > All exceptions handled by the new protocol should be logged to the server log. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4638) review protobuf server error responses and logging for region-not-found
[ https://issues.apache.org/jira/browse/GEODE-4638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dodge resolved GEODE-4638. -- Resolution: Fixed Fix Version/s: 1.5.0 > review protobuf server error responses and logging for region-not-found > --- > > Key: GEODE-4638 > URL: https://issues.apache.org/jira/browse/GEODE-4638 > Project: Geode > Issue Type: Task > Components: client/server >Reporter: Bruce Schuchardt >Assignee: Michael Dodge >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Some operation handlers log region-not-found problems at error level and some > at warning level. Some return a SERVER_ERROR error code and some return an > INVALID_REQUEST error code. These should probably all behave in the same way. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4233) Create new geode-example about transactions
[ https://issues.apache.org/jira/browse/GEODE-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dodge resolved GEODE-4233. -- Resolution: Fixed > Create new geode-example about transactions > --- > > Key: GEODE-4233 > URL: https://issues.apache.org/jira/browse/GEODE-4233 > Project: Geode > Issue Type: New Feature > Components: examples >Reporter: Michael Dodge >Assignee: Michael Dodge >Priority: Major > Labels: pull-request-available > Time Spent: 2.5h > Remaining Estimate: 0h > > Create a new example that demonstrates transactions. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4646) Enhance instructions for adding an example
[ https://issues.apache.org/jira/browse/GEODE-4646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dodge resolved GEODE-4646. -- Resolution: Fixed > Enhance instructions for adding an example > -- > > Key: GEODE-4646 > URL: https://issues.apache.org/jira/browse/GEODE-4646 > Project: Geode > Issue Type: Improvement > Components: examples >Reporter: Michael Dodge >Assignee: Michael Dodge >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > The instructions for adding an example ought to include a reminder to ensure > that the `runAll` target from the top-level succeeds as a pre-condition for > submitting the new example. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4744) Allow java.util.Map#get in OQL when security is enabled
[
https://issues.apache.org/jira/browse/GEODE-4744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nabarun resolved GEODE-4744.
Resolution: Fixed
> Allow java.util.Map#get in OQL when security is enabled
> ---
>
> Key: GEODE-4744
> URL: https://issues.apache.org/jira/browse/GEODE-4744
> Project: Geode
> Issue Type: Improvement
> Components: querying
>Affects Versions: 1.3.0
>Reporter: Masaki Yamakawa
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I am migrating from GemFire 7.x to Geode. After migration, An exception is
> now thrown in OQL when security is enabled.
> The OQL in which the exception occurs is as follows:
> {code:sql}
> select * from /RegionA a where a['intData']=1 and a['strData1']='ABC' and
> a.get(1)=98 and a.get('strData2')='DEF'
> {code}
> {code:sql}
> select * from /RegionB where mapField.get('mapData1')='ZZZ' and
> mapField.get(0)=123
> {code}
> * The value of Region A is java.util.Map, the value of Region B is its domain
> object, and it holds the public field of java.util.Map called mapField.
> I would like to allow java.util.Map#get in OQL.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (GEODE-4744) Allow java.util.Map#get in OQL when security is enabled
[
https://issues.apache.org/jira/browse/GEODE-4744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
nabarun closed GEODE-4744.
--
> Allow java.util.Map#get in OQL when security is enabled
> ---
>
> Key: GEODE-4744
> URL: https://issues.apache.org/jira/browse/GEODE-4744
> Project: Geode
> Issue Type: Improvement
> Components: querying
>Affects Versions: 1.3.0
>Reporter: Masaki Yamakawa
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I am migrating from GemFire 7.x to Geode. After migration, An exception is
> now thrown in OQL when security is enabled.
> The OQL in which the exception occurs is as follows:
> {code:sql}
> select * from /RegionA a where a['intData']=1 and a['strData1']='ABC' and
> a.get(1)=98 and a.get('strData2')='DEF'
> {code}
> {code:sql}
> select * from /RegionB where mapField.get('mapData1')='ZZZ' and
> mapField.get(0)=123
> {code}
> * The value of Region A is java.util.Map, the value of Region B is its domain
> object, and it holds the public field of java.util.Map called mapField.
> I would like to allow java.util.Map#get in OQL.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4685) Replace setPdxReadSerialized in org.apache.geode.cache.lucene.internal
[ https://issues.apache.org/jira/browse/GEODE-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380789#comment-16380789 ] ASF subversion and git services commented on GEODE-4685: Commit 27a0d8786f8f5e873446af31985b54ea3b43c355 in geode's branch refs/heads/feature/GEODE-4685 from Udo [ https://gitbox.apache.org/repos/asf?p=geode.git;h=27a0d87 ] GEODE-4685: Amended JDBC connector code to pass in a Cache for testing > Replace setPdxReadSerialized in org.apache.geode.cache.lucene.internal > -- > > Key: GEODE-4685 > URL: https://issues.apache.org/jira/browse/GEODE-4685 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: nabarun >Assignee: Udo Kohlmeyer >Priority: Major > > Replace with the solution from GEODE-4679 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4753) Protobuf GetServer request has wrong permission set
[ https://issues.apache.org/jira/browse/GEODE-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380780#comment-16380780 ] ASF subversion and git services commented on GEODE-4753: Commit 92278d466d2721f03b7d1430a549f52930e032a7 in geode's branch refs/heads/develop from [~WireBaron] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=92278d4 ] GEODE-4753: fix permission for GetServer operation (#1524) > Protobuf GetServer request has wrong permission set > --- > > Key: GEODE-4753 > URL: https://issues.apache.org/jira/browse/GEODE-4753 > Project: Geode > Issue Type: Bug >Reporter: Brian Rowe >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 20m > Remaining Estimate: 0h > > A recent change accidently changed this from a cluster scope permission to > data scope. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-2869) CI Failure: org.apache.geode.management.internal.cli.commands.ConfigCommandsDUnitTest
[ https://issues.apache.org/jira/browse/GEODE-2869?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn resolved GEODE-2869. --- Resolution: Won't Do > CI Failure: > org.apache.geode.management.internal.cli.commands.ConfigCommandsDUnitTest > - > > Key: GEODE-2869 > URL: https://issues.apache.org/jira/browse/GEODE-2869 > Project: Geode > Issue Type: Bug > Components: management >Reporter: Jared Stewart >Priority: Major > > testAlterRuntimeConfigOnAllMembers and testAlterUpdatesSharedConfig failed in > the nightly build > (https://builds.apache.org/blue/organizations/jenkins/Geode-nightly/detail/Geode-nightly/824/tests) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4753) Protobuf GetServer request has wrong permission set
[ https://issues.apache.org/jira/browse/GEODE-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-4753: -- Labels: pull-request-available (was: ) > Protobuf GetServer request has wrong permission set > --- > > Key: GEODE-4753 > URL: https://issues.apache.org/jira/browse/GEODE-4753 > Project: Geode > Issue Type: Bug >Reporter: Brian Rowe >Priority: Major > Labels: pull-request-available > > A recent change accidently changed this from a cluster scope permission to > data scope. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4498) CI failure: org.apache.geode.management.internal.cli.commands.DestroyAsyncEventQueueCommandDUnitTest > destroyAeqWhenQueueDoesNotExist_deafultReturnsError FAILED
[
https://issues.apache.org/jira/browse/GEODE-4498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-4498:
--
Labels: CI (was: )
> CI failure:
> org.apache.geode.management.internal.cli.commands.DestroyAsyncEventQueueCommandDUnitTest
> > destroyAeqWhenQueueDoesNotExist_deafultReturnsError FAILED
> -
>
> Key: GEODE-4498
> URL: https://issues.apache.org/jira/browse/GEODE-4498
> Project: Geode
> Issue Type: Bug
> Components: gfsh, wan
>Affects Versions: 1.4.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Priority: Major
> Labels: CI
>
> Occurred in CI on geode 1.4:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/release-1.4.0/jobs/DistributedTest/builds/16
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.rules.MemberVM$$Lambda$43/465470667.run in VM 0
> running on Host 39e2a1b72a9e with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:393)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:363)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:308)
> at
> org.apache.geode.test.dunit.rules.MemberVM.waitTillAsyncEventQueuesAreReadyOnServers(MemberVM.java:126)
> at
> org.apache.geode.management.internal.cli.commands.DestroyAsyncEventQueueCommandDUnitTest.destroyAeqWhenQueueDoesNotExist_deafultReturnsError(DestroyAsyncEventQueueCommandDUnitTest.java:90)
> Caused by:
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in org.apache.geode.test.junit.rules.MemberStarterRule was not
> fulfilled within 2 seconds.
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-4753) Protobuf GetServer request has wrong permission set
Brian Rowe created GEODE-4753: - Summary: Protobuf GetServer request has wrong permission set Key: GEODE-4753 URL: https://issues.apache.org/jira/browse/GEODE-4753 Project: Geode Issue Type: Bug Reporter: Brian Rowe A recent change accidently changed this from a cluster scope permission to data scope. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4744) Allow java.util.Map#get in OQL when security is enabled
[
https://issues.apache.org/jira/browse/GEODE-4744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380744#comment-16380744
]
ASF subversion and git services commented on GEODE-4744:
Commit 967b9dba0576b43a00280528e0ff4a53eb1d1bf3 in geode's branch
refs/heads/develop from [~masaki.yamakawa]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=967b9db ]
GEODE-4744: Allow java.util.Map#get in OQL when security is enabled
> Allow java.util.Map#get in OQL when security is enabled
> ---
>
> Key: GEODE-4744
> URL: https://issues.apache.org/jira/browse/GEODE-4744
> Project: Geode
> Issue Type: Improvement
> Components: querying
>Affects Versions: 1.3.0
>Reporter: Masaki Yamakawa
>Priority: Major
> Labels: pull-request-available
> Time Spent: 50m
> Remaining Estimate: 0h
>
> I am migrating from GemFire 7.x to Geode. After migration, An exception is
> now thrown in OQL when security is enabled.
> The OQL in which the exception occurs is as follows:
> {code:sql}
> select * from /RegionA a where a['intData']=1 and a['strData1']='ABC' and
> a.get(1)=98 and a.get('strData2')='DEF'
> {code}
> {code:sql}
> select * from /RegionB where mapField.get('mapData1')='ZZZ' and
> mapField.get(0)=123
> {code}
> * The value of Region A is java.util.Map, the value of Region B is its domain
> object, and it holds the public field of java.util.Map called mapField.
> I would like to allow java.util.Map#get in OQL.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4729) Rearrange Geode Native Quickstarts and Examples
[ https://issues.apache.org/jira/browse/GEODE-4729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380729#comment-16380729 ] ASF subversion and git services commented on GEODE-4729: Commit 3ac343524ea3233ecb39bb700361ddca2ab486ca in geode-native's branch refs/heads/develop from Addison Huddy [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=3ac3435 ] GEODE-4729: Restructured docs (#226) > Rearrange Geode Native Quickstarts and Examples > --- > > Key: GEODE-4729 > URL: https://issues.apache.org/jira/browse/GEODE-4729 > Project: Geode > Issue Type: Sub-task > Components: native client >Reporter: Addison >Priority: Major > Labels: pull-request-available > Time Spent: 1h 10m > Remaining Estimate: 0h > > The goal of this ticket is to restructure the Geode Native docs to make the > addition of examples easier. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3496) ExportLogsIntegrationTest fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-3496.
---
Resolution: Won't Do
> ExportLogsIntegrationTest fails on Windows
> --
>
> Key: GEODE-3496
> URL: https://issues.apache.org/jira/browse/GEODE-3496
> Project: Geode
> Issue Type: Bug
> Components: gfsh, tests
> Environment: Windows
>Reporter: Kirk Lund
>Priority: Major
> Labels: IntegrationTest, Windows
>
> {noformat}
> org.apache.geode.management.internal.cli.commands.ExportLogsIntegrationTest >
> withFiles_savedToLocatorSpecifiedRelativeDir FAILED
> java.lang.AssertionError:
> Expecting actual not to be empty
> at
> org.apache.geode.management.internal.cli.commands.ExportLogsIntegrationTest.withFiles_savedToLocatorSpecifiedRelativeDir(ExportLogsIntegrationTest.java:81)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4685) Replace setPdxReadSerialized in org.apache.geode.cache.lucene.internal
[ https://issues.apache.org/jira/browse/GEODE-4685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380716#comment-16380716 ] ASF subversion and git services commented on GEODE-4685: Commit 5b3b6cde3a951631263eef96962ab93903055958 in geode's branch refs/heads/feature/GEODE-4685 from Udo [ https://gitbox.apache.org/repos/asf?p=geode.git;h=5b3b6cd ] GEODE-4685: Moving of static DefaultQuery.setPdxReadSerialized to the TypeRegistry. Cleaned up the overriding of readSerialized to reset to previous value. Added cache to AbstractJdbcCallback.java so that children classes can access it. Replaced AtomicLong with LongAdder. > Replace setPdxReadSerialized in org.apache.geode.cache.lucene.internal > -- > > Key: GEODE-4685 > URL: https://issues.apache.org/jira/browse/GEODE-4685 > Project: Geode > Issue Type: Bug > Components: lucene >Reporter: nabarun >Assignee: Udo Kohlmeyer >Priority: Major > > Replace with the solution from GEODE-4679 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3483) Pulse integration tests fail on Windows
[ https://issues.apache.org/jira/browse/GEODE-3483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn resolved GEODE-3483. --- Resolution: Won't Do > Pulse integration tests fail on Windows > --- > > Key: GEODE-3483 > URL: https://issues.apache.org/jira/browse/GEODE-3483 > Project: Geode > Issue Type: Bug > Components: pulse, security, tests > Environment: Windows >Reporter: Kirk Lund >Priority: Major > Labels: IntegrationTest, Windows > > Various Pulse integration tests are failing on Windows. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3484) PulseDataExportTest fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-3484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-3484.
---
Resolution: Won't Do
> PulseDataExportTest fails on Windows
>
>
> Key: GEODE-3484
> URL: https://issues.apache.org/jira/browse/GEODE-3484
> Project: Geode
> Issue Type: Sub-task
> Components: pulse, tests
> Environment: Windows
>Reporter: Kirk Lund
>Priority: Major
> Labels: IntegrationTest, Windows
>
> {noformat}
> org.apache.geode.tools.pulse.PulseDataExportTest >
> dataBrowserExportWorksAsExpected FAILED
> org.junit.ComparisonFailure: expected:<[302]> but was:<[503]>
> 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.dunit.rules.HttpClientRule.loginToPulseAndVerify(HttpClientRule.java:73)
> at
> org.apache.geode.tools.pulse.PulseDataExportTest.dataBrowserExportWorksAsExpected(PulseDataExportTest.java:53)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-3485) PulseSecurityTest fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-3485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-3485.
---
Resolution: Won't Do
> PulseSecurityTest fails on Windows
> --
>
> Key: GEODE-3485
> URL: https://issues.apache.org/jira/browse/GEODE-3485
> Project: Geode
> Issue Type: Sub-task
> Components: pulse, security, tests
> Environment: Windows
>Reporter: Kirk Lund
>Priority: Major
> Labels: IntegrationTest, Security, Windows
>
> {noformat}
> org.apache.geode.tools.pulse.PulseSecurityTest > loginWithIncorrectPassword
> FAILED
> org.junit.ComparisonFailure: expected:<[302]> but was:<[503]>
> 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.tools.pulse.PulseSecurityTest.loginWithIncorrectPassword(PulseSecurityTest.java:53)
> org.apache.geode.tools.pulse.PulseSecurityTest > loginAllAccess FAILED
> org.junit.ComparisonFailure: expected:<[302]> but was:<[503]>
> 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.dunit.rules.HttpClientRule.loginToPulseAndVerify(HttpClientRule.java:73)
> at
> org.apache.geode.tools.pulse.PulseSecurityTest.loginAllAccess(PulseSecurityTest.java:76)
> org.apache.geode.tools.pulse.PulseSecurityTest > loginWithDataOnly FAILED
> org.junit.ComparisonFailure: expected:<[302]> but was:<[503]>
> 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.dunit.rules.HttpClientRule.loginToPulseAndVerify(HttpClientRule.java:73)
> at
> org.apache.geode.tools.pulse.PulseSecurityTest.loginWithDataOnly(PulseSecurityTest.java:62)
> org.apache.geode.tools.pulse.PulseSecurityTest > loginWithClusterOnly FAILED
> org.junit.ComparisonFailure: expected:<[302]> but was:<[503]>
> 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.dunit.rules.HttpClientRule.loginToPulseAndVerify(HttpClientRule.java:73)
> at
> org.apache.geode.tools.pulse.PulseSecurityTest.loginWithClusterOnly(PulseSecurityTest.java:87)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4743) Code Cleanup: Remove dead classes DebuggerSupport, SingletonCallable, SingletonValue, StackTraceCollector, DebuggerUtils
[ https://issues.apache.org/jira/browse/GEODE-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16380715#comment-16380715 ] ASF subversion and git services commented on GEODE-4743: Commit 7980b1c4fa9fb5a233ed77706a7f5885516a86cc in geode's branch refs/heads/develop from [~prhomberg] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=7980b1c ] GEODE-4743: Removed five dead classes. * Remove classes: DebuggerSupport, SingletonCallable, SingletonValue, StackTraceCollector, DebuggerUtils. * Remove commented-out code that mentions one of these classes * Remove commented-out code from surrounding area. * Remove test that has been ignored since 2008. * Remove SingletonValue from sanctioned serializables. * Update AnalyzeSerializablesJUnitTest for more meaningful failure. > Code Cleanup: Remove dead classes DebuggerSupport, SingletonCallable, > SingletonValue, StackTraceCollector, DebuggerUtils > > > Key: GEODE-4743 > URL: https://issues.apache.org/jira/browse/GEODE-4743 > Project: Geode > Issue Type: Bug >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > These classes appear to be remnants of the dark and dreadful time before IDE > debuggers. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3486) PulseSecurityWithSSLTest fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-3486.
---
Resolution: Won't Do
> PulseSecurityWithSSLTest fails on Windows
> -
>
> Key: GEODE-3486
> URL: https://issues.apache.org/jira/browse/GEODE-3486
> Project: Geode
> Issue Type: Sub-task
> Components: pulse, security, tests
> Environment: Windows
>Reporter: Kirk Lund
>Priority: Major
> Labels: IntegrationTest, Security, Windows
>
> {noformat}
> org.apache.geode.tools.pulse.PulseSecurityWithSSLTest >
> loginWithIncorrectPassword FAILED
> org.junit.ComparisonFailure: expected:<[302]> but was:<[503]>
> 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.tools.pulse.PulseSecurityWithSSLTest.loginWithIncorrectPassword(PulseSecurityWithSSLTest.java:76)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-3492) ServerLauncherRemoteFileIntegrationTest fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-3492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-3492.
---
Resolution: Won't Do
> ServerLauncherRemoteFileIntegrationTest fails on Windows
>
>
> Key: GEODE-3492
> URL: https://issues.apache.org/jira/browse/GEODE-3492
> Project: Geode
> Issue Type: Sub-task
> Components: gfsh, tests
> Environment: Windows
>Reporter: Kirk Lund
>Priority: Major
> Labels: IntegrationTest, Windows
>
> {noformat}
> org.apache.geode.distributed.ServerLauncherRemoteFileIntegrationTest >
> stopWithPidReturnsStopped FAILED
> org.awaitility.core.ConditionTimeoutException: Condition defined as a
> lambda expression in
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase that
> uses org.apache.geode.distributed.ServerLauncher expected:<[online]> but
> was:<[not responding]> within 2 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:198)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:177)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:188)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.givenRunningServer(ServerLauncherRemoteIntegrationTestCase.java:114)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.givenRunningServer(ServerLauncherRemoteIntegrationTestCase.java:110)
> at
> org.apache.geode.distributed.ServerLauncherRemoteFileIntegrationTest.stopWithPidReturnsStopped(ServerLauncherRemoteFileIntegrationTest.java:75)
> org.apache.geode.distributed.ServerLauncherRemoteFileIntegrationTest >
> stopWithPidDeletesPidFile FAILED
> org.awaitility.core.ConditionTimeoutException: Condition defined as a
> lambda expression in
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase that
> uses org.apache.geode.distributed.ServerLauncher expected:<[online]> but
> was:<[not responding]> within 2 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:198)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:177)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:188)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.givenRunningServer(ServerLauncherRemoteIntegrationTestCase.java:114)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.givenRunningServer(ServerLauncherRemoteIntegrationTestCase.java:110)
> at
> org.apache.geode.distributed.ServerLauncherRemoteFileIntegrationTest.stopWithPidDeletesPidFile(ServerLauncherRemoteFileIntegrationTest.java:63)
> org.apache.geode.distributed.ServerLauncherRemoteFileIntegrationTest >
> stopWithPidStopsServerProcess FAILED
> org.awaitility.core.ConditionTimeoutException: Condition defined as a
> lambda expression in
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase that
> uses org.apache.geode.distributed.ServerLauncher expected:<[online]> but
> was:<[not responding]> within 2 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
> at
>
[jira] [Resolved] (GEODE-3491) LocatorLauncherRemoteWithCustomLoggingIntegrationTest fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-3491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-3491.
---
Resolution: Won't Do
> LocatorLauncherRemoteWithCustomLoggingIntegrationTest fails on Windows
> --
>
> Key: GEODE-3491
> URL: https://issues.apache.org/jira/browse/GEODE-3491
> Project: Geode
> Issue Type: Sub-task
> Components: gfsh, tests
> Environment: Windows
>Reporter: Kirk Lund
>Priority: Major
> Labels: IntegrationTest, Windows
>
> {noformat}
> org.apache.geode.distributed.LocatorLauncherRemoteWithCustomLoggingIntegrationTest
> > startWithCustomLoggingConfiguration FAILED
> org.awaitility.core.ConditionTimeoutException: Condition defined as a
> lambda expression in
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase that
> uses org.apache.geode.distributed.LocatorLauncher expected:<[online]> but
> was:<[not responding]> within 2 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.awaitStart(LocatorLauncherRemoteIntegrationTestCase.java:196)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.awaitStart(LocatorLauncherRemoteIntegrationTestCase.java:179)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.startLocator(LocatorLauncherRemoteIntegrationTestCase.java:149)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteWithCustomLoggingIntegrationTest.startWithCustomLoggingConfiguration(LocatorLauncherRemoteWithCustomLoggingIntegrationTest.java:56)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-3493) ServerLauncherRemoteIntegrationTest fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-3493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-3493.
---
Resolution: Won't Do
> ServerLauncherRemoteIntegrationTest fails on Windows
>
>
> Key: GEODE-3493
> URL: https://issues.apache.org/jira/browse/GEODE-3493
> Project: Geode
> Issue Type: Sub-task
> Components: gfsh, tests
> Environment: Windows
>Reporter: Kirk Lund
>Priority: Major
> Labels: IntegrationTest, Windows
>
> {noformat}
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTest >
> statusForDisableDefaultServerHasEmptyPort FAILED
> org.awaitility.core.ConditionTimeoutException: Condition defined as a
> lambda expression in
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase that
> uses org.apache.geode.distributed.ServerLauncher expected:<[online]> but
> was:<[not responding]> within 2 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:198)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:177)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:188)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.givenRunningServer(ServerLauncherRemoteIntegrationTestCase.java:114)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTest.statusForDisableDefaultServerHasEmptyPort(ServerLauncherRemoteIntegrationTest.java:177)
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTest >
> pidFileContainsServerPid FAILED
> org.awaitility.core.ConditionTimeoutException: Condition defined as a
> lambda expression in
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase that
> uses org.apache.geode.distributed.ServerLauncher expected:<[online]> but
> was:<[not responding]> within 2 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:198)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:177)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.awaitStart(ServerLauncherRemoteIntegrationTestCase.java:188)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.startServer(ServerLauncherRemoteIntegrationTestCase.java:127)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase.startServer(ServerLauncherRemoteIntegrationTestCase.java:123)
> at
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTest.pidFileContainsServerPid(ServerLauncherRemoteIntegrationTest.java:61)
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTest >
> startWithForceOverwritesExistingPidFile FAILED
> org.awaitility.core.ConditionTimeoutException: Condition defined as a
> lambda expression in
> org.apache.geode.distributed.ServerLauncherRemoteIntegrationTestCase that
> uses org.apache.geode.distributed.ServerLauncher expected:<[online]> but
> was:<[not responding]> within 2 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
> at
>
[jira] [Resolved] (GEODE-3488) LocatorLauncherJmxManagerRemoteRegressionTest fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-3488.
---
Resolution: Won't Do
> LocatorLauncherJmxManagerRemoteRegressionTest fails on Windows
> --
>
> Key: GEODE-3488
> URL: https://issues.apache.org/jira/browse/GEODE-3488
> Project: Geode
> Issue Type: Sub-task
> Components: gfsh, tests
> Environment: Windows
>Reporter: Kirk Lund
>Priority: Major
> Labels: IntegrationTest, Windows
>
> {noformat}
> org.apache.geode.distributed.LocatorLauncherJmxManagerRemoteRegressionTest >
> locatorProcessWithZeroJmxPortExitsWhenStopped FAILED
> org.awaitility.core.ConditionTimeoutException: Condition defined as a
> lambda expression in
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase that
> uses org.apache.geode.distributed.LocatorLauncher expected:<[online]> but
> was:<[not responding]> within 2 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.awaitStart(LocatorLauncherRemoteIntegrationTestCase.java:196)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.awaitStart(LocatorLauncherRemoteIntegrationTestCase.java:179)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.awaitStart(LocatorLauncherRemoteIntegrationTestCase.java:189)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.givenRunningLocator(LocatorLauncherRemoteIntegrationTestCase.java:114)
> at
> org.apache.geode.distributed.LocatorLauncherJmxManagerRemoteRegressionTest.locatorProcessWithZeroJmxPortExitsWhenStopped(LocatorLauncherJmxManagerRemoteRegressionTest.java:53)
> org.apache.geode.distributed.LocatorLauncherJmxManagerRemoteRegressionTest >
> locatorProcessWithNonZeroJmxPortExitsWhenStopped FAILED
> org.awaitility.core.ConditionTimeoutException: Condition defined as a
> lambda expression in
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase that
> uses org.apache.geode.distributed.LocatorLauncher expected:<[online]> but
> was:<[not responding]> within 2 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.awaitStart(LocatorLauncherRemoteIntegrationTestCase.java:196)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.awaitStart(LocatorLauncherRemoteIntegrationTestCase.java:179)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.awaitStart(LocatorLauncherRemoteIntegrationTestCase.java:189)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.givenRunningLocator(LocatorLauncherRemoteIntegrationTestCase.java:114)
> at
> org.apache.geode.distributed.LocatorLauncherJmxManagerRemoteRegressionTest.locatorProcessWithNonZeroJmxPortExitsWhenStopped(LocatorLauncherJmxManagerRemoteRegressionTest.java:64)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-3489) LocatorLauncherRemoteFileIntegrationTest fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-3489.
---
Resolution: Won't Do
> LocatorLauncherRemoteFileIntegrationTest fails on Windows
> -
>
> Key: GEODE-3489
> URL: https://issues.apache.org/jira/browse/GEODE-3489
> Project: Geode
> Issue Type: Sub-task
> Components: gfsh, tests
> Environment: Windows
>Reporter: Kirk Lund
>Priority: Major
> Labels: IntegrationTest, Windows
>
> {noformat}
> org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest >
> stopWithPidStopsLocatorProcess FAILED
> org.awaitility.core.ConditionTimeoutException: Condition defined as a
> lambda expression in
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase that
> uses org.apache.geode.distributed.LocatorLauncher expected:<[online]> but
> was:<[not responding]> within 2 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.awaitStart(LocatorLauncherRemoteIntegrationTestCase.java:196)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.awaitStart(LocatorLauncherRemoteIntegrationTestCase.java:179)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.awaitStart(LocatorLauncherRemoteIntegrationTestCase.java:189)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.givenRunningLocator(LocatorLauncherRemoteIntegrationTestCase.java:114)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.givenRunningLocator(LocatorLauncherRemoteIntegrationTestCase.java:110)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest.stopWithPidStopsLocatorProcess(LocatorLauncherRemoteFileIntegrationTest.java:77)
> org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest >
> stopWithPidReturnsStopped FAILED
> org.awaitility.core.ConditionTimeoutException: Condition defined as a
> lambda expression in
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase that
> uses org.apache.geode.distributed.LocatorLauncher expected:<[online]> but
> was:<[not responding]> within 2 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:809)
> at
> org.awaitility.core.ConditionFactory.until(ConditionFactory.java:648)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.awaitStart(LocatorLauncherRemoteIntegrationTestCase.java:196)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.awaitStart(LocatorLauncherRemoteIntegrationTestCase.java:179)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.awaitStart(LocatorLauncherRemoteIntegrationTestCase.java:189)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.givenRunningLocator(LocatorLauncherRemoteIntegrationTestCase.java:114)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase.givenRunningLocator(LocatorLauncherRemoteIntegrationTestCase.java:110)
> at
> org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest.stopWithPidReturnsStopped(LocatorLauncherRemoteFileIntegrationTest.java:68)
> org.apache.geode.distributed.LocatorLauncherRemoteFileIntegrationTest >
> stopWithPidDeletesPidFile FAILED
> org.awaitility.core.ConditionTimeoutException: Condition defined as a
> lambda expression in
> org.apache.geode.distributed.LocatorLauncherRemoteIntegrationTestCase that
> uses org.apache.geode.distributed.LocatorLauncher expected:<[online]> but
> was:<[not responding]> within 2 minutes.
> at
> org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:104)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:117)
> at
> org.awaitility.core.AssertionCondition.await(AssertionCondition.java:32)
> at
>
[jira] [Updated] (GEODE-3475) Geode REST API integration tests fail on Windows
[ https://issues.apache.org/jira/browse/GEODE-3475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Barbara Pruijn updated GEODE-3475: -- Component/s: (was: security) > Geode REST API integration tests fail on Windows > > > Key: GEODE-3475 > URL: https://issues.apache.org/jira/browse/GEODE-3475 > Project: Geode > Issue Type: Bug > Components: rest (dev), tests > Environment: Windows >Reporter: Kirk Lund >Priority: Major > Labels: IntegrationTest, Windows > > Various Geode REST API integration tests are failing on Windows. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3479) RestSecurityPostProcessorTest fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-3479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-3479.
---
Resolution: Won't Do
> RestSecurityPostProcessorTest fails on Windows
> --
>
> Key: GEODE-3479
> URL: https://issues.apache.org/jira/browse/GEODE-3479
> Project: Geode
> Issue Type: Sub-task
> Components: rest (dev), security, tests
> Environment: Windows
>Reporter: Kirk Lund
>Priority: Major
> Labels: IntegrationTest, Windows
>
> {noformat}
> org.apache.geode.rest.internal.web.RestSecurityPostProcessorTest > namedQuery
> FAILED
> java.lang.AssertionError: expected:<201> but was:<503>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.geode.rest.internal.web.RestSecurityPostProcessorTest.namedQuery(RestSecurityPostProcessorTest.java:162)
> org.apache.geode.rest.internal.web.RestSecurityPostProcessorTest >
> getRegionKey FAILED
> java.lang.AssertionError: expected:<200> but was:<503>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.geode.rest.internal.web.RestSecurityPostProcessorTest.getRegionKey(RestSecurityPostProcessorTest.java:77)
> org.apache.geode.rest.internal.web.RestSecurityPostProcessorTest > getRegion
> FAILED
> java.lang.AssertionError: expected:<200> but was:<503>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.geode.rest.internal.web.RestSecurityPostProcessorTest.getRegion(RestSecurityPostProcessorTest.java:121)
> org.apache.geode.rest.internal.web.RestSecurityPostProcessorTest > adhocQuery
> FAILED
> java.lang.AssertionError: expected:<200> but was:<503>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.geode.rest.internal.web.RestSecurityPostProcessorTest.adhocQuery(RestSecurityPostProcessorTest.java:140)
> org.apache.geode.rest.internal.web.RestSecurityPostProcessorTest >
> getMultipleRegionKeys FAILED
> java.lang.AssertionError: expected:<200> but was:<503>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.geode.rest.internal.web.RestSecurityPostProcessorTest.getMultipleRegionKeys(RestSecurityPostProcessorTest.java:102)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-3478) RestSecurityIntegrationTest fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-3478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-3478.
---
Resolution: Won't Do
> RestSecurityIntegrationTest fails on Windows
>
>
> Key: GEODE-3478
> URL: https://issues.apache.org/jira/browse/GEODE-3478
> Project: Geode
> Issue Type: Sub-task
> Components: rest (dev), security, tests
> Environment: Windows
>Reporter: Kirk Lund
>Priority: Major
> Labels: IntegrationTest, Windows
>
> {noformat}
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest > testPutQuery
> FAILED
> java.lang.AssertionError: expected:<401> but was:<503>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.testPutQuery(RestSecurityIntegrationTest.java:135)
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest >
> testDeleteQuery FAILED
> java.lang.AssertionError: expected:<401> but was:<503>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.testDeleteQuery(RestSecurityIntegrationTest.java:146)
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest > putRegionKey
> FAILED
> java.lang.AssertionError: expected:<401> but was:<503>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.putRegionKey(RestSecurityIntegrationTest.java:346)
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest >
> testPostQuery FAILED
> java.lang.AssertionError: expected:<401> but was:<503>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.testPostQuery(RestSecurityIntegrationTest.java:110)
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest > testPing
> FAILED
> java.lang.AssertionError: expected:<200> but was:<503>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.testPing(RestSecurityIntegrationTest.java:173)
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest >
> postRegionKey FAILED
> java.lang.AssertionError: expected:<401> but was:<503>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.postRegionKey(RestSecurityIntegrationTest.java:320)
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest > deleteRegion
> FAILED
> java.lang.AssertionError: expected:<401> but was:<503>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.deleteRegion(RestSecurityIntegrationTest.java:255)
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest > getRegionKey
> FAILED
> java.lang.AssertionError: expected:<200> but was:<503>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest.getRegionKey(RestSecurityIntegrationTest.java:284)
> org.apache.geode.rest.internal.web.RestSecurityIntegrationTest > testQueries
> FAILED
> java.lang.AssertionError: expected:<401> but was:<503>
> at
[jira] [Resolved] (GEODE-3482) SwaggerVerificationIntegrationTest fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-3482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-3482.
---
Resolution: Won't Do
> SwaggerVerificationIntegrationTest fails on Windows
> ---
>
> Key: GEODE-3482
> URL: https://issues.apache.org/jira/browse/GEODE-3482
> Project: Geode
> Issue Type: Sub-task
> Components: rest (dev), security, tests
> Environment: Windows
>Reporter: Kirk Lund
>Priority: Major
> Labels: IntegrationTest, Windows
>
> {noformat}
> org.apache.geode.rest.internal.web.SwaggerVerificationIntegrationTest >
> isSwaggerRunning FAILED
> java.lang.AssertionError:
> Expected: is <200>
> but: was <503>
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> at org.junit.Assert.assertThat(Assert.java:956)
> at org.junit.Assert.assertThat(Assert.java:923)
> at
> org.apache.geode.rest.internal.web.SwaggerVerificationIntegrationTest.isSwaggerRunning(SwaggerVerificationIntegrationTest.java:44)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-3480) RestSecurityWithSSLTest fails on Windows
[
https://issues.apache.org/jira/browse/GEODE-3480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn resolved GEODE-3480.
---
Resolution: Won't Do
> RestSecurityWithSSLTest fails on Windows
>
>
> Key: GEODE-3480
> URL: https://issues.apache.org/jira/browse/GEODE-3480
> Project: Geode
> Issue Type: Sub-task
> Components: rest (dev), security, tests
> Environment: Windows
>Reporter: Kirk Lund
>Priority: Major
> Labels: IntegrationTest, Windows
>
> {noformat}
> org.apache.geode.rest.internal.web.RestSecurityWithSSLTest >
> testRestSecurityWithSSL FAILED
> java.lang.AssertionError: expected:<200> but was:<503>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.geode.rest.internal.web.RestSecurityWithSSLTest.testRestSecurityWithSSL(RestSecurityWithSSLTest.java:61)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-4331) Inject BackupDestination into a BackupManager
[ https://issues.apache.org/jira/browse/GEODE-4331?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Reich resolved GEODE-4331. --- Resolution: Duplicate > Inject BackupDestination into a BackupManager > - > > Key: GEODE-4331 > URL: https://issues.apache.org/jira/browse/GEODE-4331 > Project: Geode > Issue Type: Sub-task > Components: persistence >Reporter: Nick Reich >Priority: Major > > To allow for different implementation of BackupDestination to be used for > backups, inject the destination to use into the constructor for the > BackupManager. This will require in the existing code providing the existing > BackupDestination, FileSystemBackupDestination. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4404) Update Gfsh command to pass BackupDestination object
[ https://issues.apache.org/jira/browse/GEODE-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nick Reich resolved GEODE-4404. --- Resolution: Fixed Fix Version/s: 1.5.0 > Update Gfsh command to pass BackupDestination object > > > Key: GEODE-4404 > URL: https://issues.apache.org/jira/browse/GEODE-4404 > Project: Geode > Issue Type: Sub-task > Components: persistence >Reporter: Nick Reich >Assignee: Nick Reich >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Gfsh backup command passes File destination as the target location. To > support any destination other than the file system for the target location to > save the backup, we need to be able to pass alternate information in the > backup messages. Having the backup command provide an implementation of > BackupDestination (in this case, FileSystemBackupDestination) will allow for > the future creation of gfsh commands that utilize a different destination. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
