[jira] [Commented] (GEODE-420) locator ssl configuration
[ https://issues.apache.org/jira/browse/GEODE-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15544029#comment-15544029 ] ASF subversion and git services commented on GEODE-420: --- Commit e04519dc3eced1254f58eaebee9c241ee335dbab in incubator-geode's branch refs/heads/develop from [~jinmeiliao] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=e04519d ] GEODE-420: fix Pulse test when not using any SSLConfig > locator ssl configuration > - > > Key: GEODE-420 > URL: https://issues.apache.org/jira/browse/GEODE-420 > Project: Geode > Issue Type: New Feature > Components: docs, locator >Reporter: Darrel Schneider >Assignee: Udo Kohlmeyer > Fix For: 1.0.0-incubating > > > We currently allow separate SSL configuration for cluster, server, gateway, > jmx-manager, and http-service. > The "server" attributes configure the ssl connections from clients to a cache > server. > The "gateway" attributes configure the ssl connections between a gateway > sender and receiver. > The "jmx-manager" attributes configure the ssl connections between an admin > client (for example gfsh) and the jmx-manager. > The "http-service" attributes configure the ssl connections between REST > clients and the http-service. > The "cluster" attributes configure the ssl connections between the members of > a distributed system (peer-to-peer connections) AND to the locators. > Using "cluster" for the connections to a locator can be a problem. > Say you trust all your members of a distributed system since they are running > on your private network. So no need for ssl on the p2p connections. > So you disable cluster-ssl. These means that your peers are locators are all > using unsecure connections. > But some of these members are hosting a cache server and have clients > connecting to them. So you configure "server" ssl for the client to server > connections. But for your clients to find you servers they need to talk to > the locator. Since the clients are coming from the outside world you want > them to use SSL. So you configure "server" ssl on them for when they connect > to the cache server and "cluster" SSL on them for when they connect to the > locator. But your locators are configured with "cluster" SSL disabled so that > the p2p connects on the internal network will not be SSL. > So you are either forced to have you client to locator connections to be > unsecure or you need to secure all the cluster connections forcing the peers > to also use SSL. > I think we should introduce "locator" SSL configuration options that would > allow you to have just the locator and server using SSL and the "cluster" to > have SSL disabled. > Something else to consider would be for the locator to be able to use SSL for > clients but non-SSL for locator-to-locator and peers-to-locator connections. > I think this would be more complicated because we would need to have > different ports that the locator listens on (one for clients and one for > locators and members). > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (GEODE-1841) Map indexes are not removing keys that are no longer present after an update
[ https://issues.apache.org/jira/browse/GEODE-1841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Huynh resolved GEODE-1841. Resolution: Fixed Duplicate of GEODE-1864 > Map indexes are not removing keys that are no longer present after an update > > > Key: GEODE-1841 > URL: https://issues.apache.org/jira/browse/GEODE-1841 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Jason Huynh > > When an map in an object is updated and put into a region, any keys that "old > keys" that were previously indexed but no longer part of the new map, are not > removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-1948) geode.properties should be the default filename
[ https://issues.apache.org/jira/browse/GEODE-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Duling updated GEODE-1948: Description: geode.properties should be the new default filename. If geode.properties cannot be located, fall back to look for an old gemfire.properties. (was: geode.properties should be the new default filename. If gemfire.properties is specified on startup and cannot be located, fall back to geode.properties and try to open that file before presenting an error.) > geode.properties should be the default filename > --- > > Key: GEODE-1948 > URL: https://issues.apache.org/jira/browse/GEODE-1948 > Project: Geode > Issue Type: Sub-task > Components: docs >Reporter: Kevin Duling >Assignee: Kevin Duling > Labels: branding, configuration, docs > Fix For: 1.0.0-incubating > > > geode.properties should be the new default filename. If geode.properties > cannot be located, fall back to look for an old gemfire.properties. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-1948) geode.properties should be the default filename
[ https://issues.apache.org/jira/browse/GEODE-1948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Duling updated GEODE-1948: Summary: geode.properties should be the default filename (was: Open geode.properties if gemfire.properties is not found) > geode.properties should be the default filename > --- > > Key: GEODE-1948 > URL: https://issues.apache.org/jira/browse/GEODE-1948 > Project: Geode > Issue Type: Sub-task > Components: docs >Reporter: Kevin Duling >Assignee: Kevin Duling > Labels: branding, configuration, docs > Fix For: 1.0.0-incubating > > > geode.properties should be the new default filename. If gemfire.properties > is specified on startup and cannot be located, fall back to geode.properties > and try to open that file before presenting an error. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1935) gfsh start locator command prints endless dots when starting inside docker
[
https://issues.apache.org/jira/browse/GEODE-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15543322#comment-15543322
]
Abhijat Upadhyay commented on GEODE-1935:
-
I meant if I run docker using --net=host then everything works.
{code}
docker run --rm -it --net=host\
-e INSTANCE_TYPE=locator \
-e ADDRESS=$(hostname -i) \
-p 10334:10334 \
-p 1099:1099 \
-p 7070:7070 \
-p 47000:47000 \
-p 47001-47100:47001-47100 \
-v /opt/data/gemfire/generic/work:/var/gemfire/work \
-v /opt/data/gemfire/generic/logs:/var/gemfire/logs \
-v /opt/data/gemfire/generic/stats:/var/gemfire/stats \
-v /opt/data/gemfire/generic/conf:/etc/opt/gemfire \
gemfire8 bash
{code}
> gfsh start locator command prints endless dots when starting inside docker
> --
>
> Key: GEODE-1935
> URL: https://issues.apache.org/jira/browse/GEODE-1935
> Project: Geode
> Issue Type: Bug
>Reporter: Abhijat Upadhyay
> Attachments: docker-gemfire8.zip
>
>
> I have built a docker container using gemfire 8.2.1.2. When I try to start
> locator it keeps printing endless dots. I read about this @
> https://discuss.pivotal.io/hc/en-us/articles/223525728-GFSH-hang-issue-when-using-gfsh-start-or-gfsh-status-command
> and thus using gemfire 8.2.1.2. I raised a ticket for Pivotal as well
> https://support.pivotal.io/tickets/38301 but since it is an issue I see
> inside docker, and they do not officially support dockerized gemfire yet, I
> thought I will report it here as well.
> I see that you have containerized gemfire as well on github source repo but
> not sure if you have seen this issue. I can provide you with my source code
> as well if that helps in reproducing this issue.
> Any help/guidance is much appreciated.
> Thank you,
> AU
> ==
> I have attached my docker project with this ticket. And instructions to run
> it are given in the "Comments" section below.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1935) gfsh start locator command prints endless dots when starting inside docker
[ https://issues.apache.org/jira/browse/GEODE-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15543287#comment-15543287 ] Jens Deppe commented on GEODE-1935: --- Could you elaborate a bit please...? > gfsh start locator command prints endless dots when starting inside docker > -- > > Key: GEODE-1935 > URL: https://issues.apache.org/jira/browse/GEODE-1935 > Project: Geode > Issue Type: Bug >Reporter: Abhijat Upadhyay > Attachments: docker-gemfire8.zip > > > I have built a docker container using gemfire 8.2.1.2. When I try to start > locator it keeps printing endless dots. I read about this @ > https://discuss.pivotal.io/hc/en-us/articles/223525728-GFSH-hang-issue-when-using-gfsh-start-or-gfsh-status-command > and thus using gemfire 8.2.1.2. I raised a ticket for Pivotal as well > https://support.pivotal.io/tickets/38301 but since it is an issue I see > inside docker, and they do not officially support dockerized gemfire yet, I > thought I will report it here as well. > I see that you have containerized gemfire as well on github source repo but > not sure if you have seen this issue. I can provide you with my source code > as well if that helps in reproducing this issue. > Any help/guidance is much appreciated. > Thank you, > AU > == > I have attached my docker project with this ticket. And instructions to run > it are given in the "Comments" section below. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-1961) Deprecate the ability of individual members to opt in/out of using cluster configuration
[ https://issues.apache.org/jira/browse/GEODE-1961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-1961: - Priority: Minor (was: Major) > Deprecate the ability of individual members to opt in/out of using cluster > configuration > > > Key: GEODE-1961 > URL: https://issues.apache.org/jira/browse/GEODE-1961 > Project: Geode > Issue Type: Improvement > Components: configuration >Reporter: Diane Hardman >Priority: Minor > > Once cluster config is selected when starting the locator, this should > automatically apply to all members. There is no reason an individual member > should be opting out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-1961) Deprecate the ability of individual members to opt in/out of using cluster configuration
Diane Hardman created GEODE-1961: Summary: Deprecate the ability of individual members to opt in/out of using cluster configuration Key: GEODE-1961 URL: https://issues.apache.org/jira/browse/GEODE-1961 Project: Geode Issue Type: Improvement Components: configuration Reporter: Diane Hardman Once cluster config is selected when starting the locator, this should automatically apply to all members. There is no reason an individual member should be opting out. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-1960) Provide protection against malicious developer jars deployed as functions
[ https://issues.apache.org/jira/browse/GEODE-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-1960: - Priority: Minor (was: Major) > Provide protection against malicious developer jars deployed as functions > - > > Key: GEODE-1960 > URL: https://issues.apache.org/jira/browse/GEODE-1960 > Project: Geode > Issue Type: Improvement > Components: functions, security >Reporter: Diane Hardman >Priority: Minor > > Provide protection for functions that might contain malicious calls like > System.exit(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-1960) Provide protection against malicious developer jars deployed as functions
Diane Hardman created GEODE-1960: Summary: Provide protection against malicious developer jars deployed as functions Key: GEODE-1960 URL: https://issues.apache.org/jira/browse/GEODE-1960 Project: Geode Issue Type: Improvement Components: functions, security Reporter: Diane Hardman Provide protection for functions that might contain malicious calls like System.exit(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-1959) Prompt for username and password when adding a member
Diane Hardman created GEODE-1959: Summary: Prompt for username and password when adding a member Key: GEODE-1959 URL: https://issues.apache.org/jira/browse/GEODE-1959 Project: Geode Issue Type: Improvement Components: security Reporter: Diane Hardman When you have SecurityManager configured as part of starting a locator, the administrator currently needs to have either AuthInitialize implemented or have stored credentials (in plain text) in geode.properties file. In the case where neither AuthInitialize is implemented NOR are there any credentials stored in geode.properties, then the administrator should be prompted for username and password when attempting to start another member in the distributed system. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (GEODE-1958) Remove PasswordUtil
[ https://issues.apache.org/jira/browse/GEODE-1958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Diane Hardman updated GEODE-1958: - Priority: Minor (was: Major) > Remove PasswordUtil > > > Key: GEODE-1958 > URL: https://issues.apache.org/jira/browse/GEODE-1958 > Project: Geode > Issue Type: Bug > Components: security >Reporter: Diane Hardman >Priority: Minor > > PasswordUtil was used to encrypt a password to be stored in cache.xml. This > was not secure since anyone could copy the "encrypted" string to another > cache.xml to gain access. Therefore this utility was not particularly useful > and should be removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (GEODE-1958) Remove PasswordUtil
Diane Hardman created GEODE-1958: Summary: Remove PasswordUtil Key: GEODE-1958 URL: https://issues.apache.org/jira/browse/GEODE-1958 Project: Geode Issue Type: Bug Components: security Reporter: Diane Hardman PasswordUtil was used to encrypt a password to be stored in cache.xml. This was not secure since anyone could copy the "encrypted" string to another cache.xml to gain access. Therefore this utility was not particularly useful and should be removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1935) gfsh start locator command prints endless dots when starting inside docker
[ https://issues.apache.org/jira/browse/GEODE-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15543112#comment-15543112 ] Abhijat Upadhyay commented on GEODE-1935: - FYI... I can get my original setup working if I use docker network as host instead of the default bridge. > gfsh start locator command prints endless dots when starting inside docker > -- > > Key: GEODE-1935 > URL: https://issues.apache.org/jira/browse/GEODE-1935 > Project: Geode > Issue Type: Bug >Reporter: Abhijat Upadhyay > Attachments: docker-gemfire8.zip > > > I have built a docker container using gemfire 8.2.1.2. When I try to start > locator it keeps printing endless dots. I read about this @ > https://discuss.pivotal.io/hc/en-us/articles/223525728-GFSH-hang-issue-when-using-gfsh-start-or-gfsh-status-command > and thus using gemfire 8.2.1.2. I raised a ticket for Pivotal as well > https://support.pivotal.io/tickets/38301 but since it is an issue I see > inside docker, and they do not officially support dockerized gemfire yet, I > thought I will report it here as well. > I see that you have containerized gemfire as well on github source repo but > not sure if you have seen this issue. I can provide you with my source code > as well if that helps in reproducing this issue. > Any help/guidance is much appreciated. > Thank you, > AU > == > I have attached my docker project with this ticket. And instructions to run > it are given in the "Comments" section below. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1935) gfsh start locator command prints endless dots when starting inside docker
[
https://issues.apache.org/jira/browse/GEODE-1935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15543050#comment-15543050
]
Jens Deppe commented on GEODE-1935:
---
I've looked at this a bit and can get to a partial solution. When running a
locator instance in a Docker container I first start the container and expose
ports {{1099}} (default JMX port) and {{10334}} (default locator port). Then I
start gfsh with this command:
{noformat}
gfsh start locator --name=locator1 \
--J=-Dcom.sun.management.jmxremote.rmi.port=1099 \
--J=-Djava.rmi.server.hostname=localhost \
--J=-Dgemfire.jmx-manager-hostname-for-clients=localhost
{noformat}
Notice the use of {{-Dcom.sun.management.jmxremote.rmi.port=1099}}. This forces
all "ephemeral" RMI client stub ports to be the specified port. With this
config I can connect to the locator from the docker host. {{gfsh -e "connect
locator=localhost[10334]"}}.
However, this limits the use of gfsh to the docker host. When I try and replace
{{localhost}}, in the above gfsh command, with my host's local IP, I get
similar behavior to the original bug. The problem appears to be that there is
still some use of ephemeral ports which prevents this. Of interest is debugging
into {{MBeanProcessController.getJMXServiceURL}} and the eventual {{connect}}
deep inside RMI. More investigation is required...
> gfsh start locator command prints endless dots when starting inside docker
> --
>
> Key: GEODE-1935
> URL: https://issues.apache.org/jira/browse/GEODE-1935
> Project: Geode
> Issue Type: Bug
>Reporter: Abhijat Upadhyay
> Attachments: docker-gemfire8.zip
>
>
> I have built a docker container using gemfire 8.2.1.2. When I try to start
> locator it keeps printing endless dots. I read about this @
> https://discuss.pivotal.io/hc/en-us/articles/223525728-GFSH-hang-issue-when-using-gfsh-start-or-gfsh-status-command
> and thus using gemfire 8.2.1.2. I raised a ticket for Pivotal as well
> https://support.pivotal.io/tickets/38301 but since it is an issue I see
> inside docker, and they do not officially support dockerized gemfire yet, I
> thought I will report it here as well.
> I see that you have containerized gemfire as well on github source repo but
> not sure if you have seen this issue. I can provide you with my source code
> as well if that helps in reproducing this issue.
> Any help/guidance is much appreciated.
> Thank you,
> AU
> ==
> I have attached my docker project with this ticket. And instructions to run
> it are given in the "Comments" section below.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (GEODE-706) CI failure: DiskDistributedNoAckAsyncRegionDUnitTest.testEntryIdleDestroy
[
https://issues.apache.org/jira/browse/GEODE-706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hitesh Khamesra reassigned GEODE-706:
-
Assignee: Hitesh Khamesra
> CI failure: DiskDistributedNoAckAsyncRegionDUnitTest.testEntryIdleDestroy
> -
>
> Key: GEODE-706
> URL: https://issues.apache.org/jira/browse/GEODE-706
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.0.0-incubating
>Reporter: Jens Deppe
>Assignee: Hitesh Khamesra
> Labels: CI, Flaky
>
> git rev e3d24d77150382f363f334b3e2d6622c6e02e8bc build #948
> {noformat}
> Error Message
> com.gemstone.gemfire.InternalGemFireError: Entry failed to destroy
> Stacktrace
> com.gemstone.gemfire.InternalGemFireError: Entry failed to destroy
> at com.gemstone.gemfire.internal.Assert.throwError(Assert.java:91)
> at com.gemstone.gemfire.internal.Assert.assertTrue(Assert.java:115)
> at
> com.gemstone.gemfire.cache30.RegionTestCase.waitForDestroy(RegionTestCase.java:2074)
> at
> com.gemstone.gemfire.cache30.RegionTestCase.waitForDestroy(RegionTestCase.java:2034)
> at
> com.gemstone.gemfire.cache30.RegionTestCase.testEntryIdleDestroy(RegionTestCase.java:3569)
> 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:497)
> at junit.framework.TestCase.runTest(TestCase.java:176)
> at junit.framework.TestCase.runBare(TestCase.java:141)
> at junit.framework.TestResult$1.protect(TestResult.java:122)
> at junit.framework.TestResult.runProtected(TestResult.java:142)
> at junit.framework.TestResult.run(TestResult.java:125)
> at junit.framework.TestCase.run(TestCase.java:129)
> at junit.framework.TestSuite.runTest(TestSuite.java:252)
> at junit.framework.TestSuite.run(TestSuite.java:247)
> at
> org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:86)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:105)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:64)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:50)
> at sun.reflect.GeneratedMethodAccessor73.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.messaging.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:106)
> at sun.reflect.GeneratedMethodAccessor72.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360)
> at
> org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54)
> at
> org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Standard Output
> Previously run tests: [IndexCommandsDUnitTest, ConfigCommandsDUnitTest,
> FunctionCommandsDUnitTest, ListAndDescribeDiskStoreCommandsDUnitTest,
> MiscellaneousCommandsExportLogsPart4DUnitTest,
> MiscellaneousCommandsExportLogsPart2DUnitTest,
>
[jira] [Issue Comment Deleted] (GEODE-1907) QueryDataFunction does not add LIMIT clause if space is missing after FROM clause
[
https://issues.apache.org/jira/browse/GEODE-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jared Stewart updated GEODE-1907:
-
Comment: was deleted
(was: I was unable to reproduce:
{code}
gfsh>query --region=regionA --query="select * from /regionA"
Result : true
startCount : 0
endCount : 20
Rows : 3
Result
--
3
2
1
NEXT_STEP_NAME : END
gfsh>query --region=regionA --query="select * from /regionA limit 2"
Result : true
startCount : 0
endCount : 20
Rows : 2
Result
--
3
1
NEXT_STEP_NAME : END
gfsh>query --region=regionA --query="select * from/regionA limit 2"
Result : true
startCount : 0
endCount : 20
Rows : 2
Result
--
3
1
NEXT_STEP_NAME : END
{code}
The query without a space after FROM also worked properly in pulse as well.)
> QueryDataFunction does not add LIMIT clause if space is missing after FROM
> clause
> -
>
> Key: GEODE-1907
> URL: https://issues.apache.org/jira/browse/GEODE-1907
> Project: Geode
> Issue Type: Bug
> Components: management, querying
>Reporter: Kirk Lund
>Assignee: Jared Stewart
>Priority: Minor
> Fix For: 1.0.0-incubating
>
>
> Apparently "SELECT * FROM/MyRegion" is a valid query in Geode, however if
> this query is used from GFSH or Pulse, then QueryDataFunction will fail to
> add a LIMIT clause because there is no space between FROM and the region name.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (GEODE-1907) QueryDataFunction does not add LIMIT clause if space is missing after FROM clause
[ https://issues.apache.org/jira/browse/GEODE-1907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jared Stewart resolved GEODE-1907. -- Resolution: Fixed Fix Version/s: 1.0.0-incubating > QueryDataFunction does not add LIMIT clause if space is missing after FROM > clause > - > > Key: GEODE-1907 > URL: https://issues.apache.org/jira/browse/GEODE-1907 > Project: Geode > Issue Type: Bug > Components: management, querying >Reporter: Kirk Lund >Assignee: Jared Stewart >Priority: Minor > Fix For: 1.0.0-incubating > > > Apparently "SELECT * FROM/MyRegion" is a valid query in Geode, however if > this query is used from GFSH or Pulse, then QueryDataFunction will fail to > add a LIMIT clause because there is no space between FROM and the region name. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1808) gemstone.gemfire.internal.cache.MinimumSystemRequirements can't handle java version 1.7.0_101
[
https://issues.apache.org/jira/browse/GEODE-1808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15542415#comment-15542415
]
Sergio Valenti commented on GEODE-1808:
---
Yes, we are using an extended support version of JDK7.
> gemstone.gemfire.internal.cache.MinimumSystemRequirements can't handle java
> version 1.7.0_101
> -
>
> Key: GEODE-1808
> URL: https://issues.apache.org/jira/browse/GEODE-1808
> Project: Geode
> Issue Type: Bug
> Components: general
>Reporter: Sergio Valenti
>
> We have recently updated out Java version to 1.7.0_101 on our server.
> However, after starting our java component which runs Gemfire version 8, we
> get the following log line:
> | FATAL | 20160821 18:05:30,626 | main |
> gemstone.gemfire.internal.cache.MinimumSystemRequirements | Java version
> older than 1.7.0_72.
> After looking at the source, it is apparent that the issue is in
> com.gemstone.gemfire.internal.lang.SystemUtils when dealing with java
> revisions which are 3 digits long
> public static boolean isJavaVersionAtLeast(String expectedVersion)
> {
> String actualVersionDigits =
> StringUtils.getDigitsOnly(System.getProperty("java.version"));
> String expectedVersionDigits =
> StringUtils.padEnding(StringUtils.getDigitsOnly(expectedVersion), '0',
> actualVersionDigits.length());
> try
> {
> return Long.parseLong(actualVersionDigits) >=
> Long.parseLong(expectedVersionDigits);
> }
> catch(NumberFormatException ignore)
> {
> return false;
> }
> }
> If you walk through this code with an expected version of java: 1.7.0_72 and
> an actual version of java: 1.7.0_101, it will create the following two long
> variables and compare them:
> actualVersionDigits "170101"
> expectedVersionDigits "170720"
> Which causes the comparison check to fail.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
