[jira] [Commented] (GEODE-1471) GatewayEventFilter callbacks are not invoked when an AsyncEventQueues is configured using xml
[
https://issues.apache.org/jira/browse/GEODE-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319738#comment-15319738
]
ASF subversion and git services commented on GEODE-1471:
Commit 001a4e167d287e66a944edf45ac9591b09104954 in incubator-geode's branch
refs/heads/feature/GEODE-835 from [~barry.oglesby]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=001a4e1 ]
GEODE-1471: GatewayEventFilter callbacks are now invoked on AsyncEventQueues
> GatewayEventFilter callbacks are not invoked when an AsyncEventQueues is
> configured using xml
> -
>
> Key: GEODE-1471
> URL: https://issues.apache.org/jira/browse/GEODE-1471
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>
> None of the {{GatewayEventFilter}} callbacks are invoked when configuring
> {{AsyncEventQueues}} using xml.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1331) gfsh.bat on Windows is incorrect
[
https://issues.apache.org/jira/browse/GEODE-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319736#comment-15319736
]
ASF subversion and git services commented on GEODE-1331:
Commit 8e21638ce336aee07bec33d140500c76d1cedc53 in incubator-geode's branch
refs/heads/feature/GEODE-835 from [~kduling]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=8e21638 ]
GEODE-1331: gfsh.bat on Windows is incorrect.
* Renamed internal variable from CLASSPATH to DEPENDENCIES.
* Verified @setlocal was not altering the System environment variables for the
shell.
* Launch with -classpath param like the bash script does.
* Ensured command-line arguments match bash script's order of arguments.
* This closes #149
> gfsh.bat on Windows is incorrect
>
>
> Key: GEODE-1331
> URL: https://issues.apache.org/jira/browse/GEODE-1331
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Kevin Duling
> Fix For: 1.0.0-incubating.M3
>
>
> Initial report:
> {noformat}
> I am doing testing in windows STS. I am not adding these dependencies jars,
> gfsh.bat is what doing this.
>
> C:\DEV\Pivotal\GemFire_v82014\bin\gfsh.bat has below code, which is setting
> gemfire, antlr, gfsh-dependencies and pulse-dependencies jars in classpath.
> Line 26 to 29
> @set
> GEMFIRE_JARS=%GEMFIRE%\lib\gemfire.jar;%GEMFIRE%\lib\antlr.jar;%GEMFIRE%\lib\gfsh-dependencies.jar;%GEMFIRE%\lib\pulse-dependencies.jar
> @if defined CLASSPATH (
> @set GEMFIRE_JARS=%GEMFIRE_JARS%;%CLASSPATH%
> )
> C:\DEV\Pivotal\GemFire_v82014\lib\gemfire.jar // DUPLICATE
> C:\DEV\Pivotal\GemFire_v82014\lib\antlr.jar
> C:\DEV\Pivotal\GemFire_v82014\lib\gfsh-dependencies.jar // DUPLICATE
> C:\DEV\Pivotal\GemFire_v82014\lib\pulse-dependencies.jar
>
> Unix C:\DEV\Pivotal\GemFire_v82014\bin script, does not set these jars in
> classpath.
>
>
> Another observation is that, if I pass --include-system-classpath to gfsh
> start server command, then it is prepending
> gemfire.jar and gfsh-dependencies.jar to the system classpath and adding that
> to the server, that is what is shown in logs
> Class Path:
> C:\DEV\Pivotal\GemFire_v82014\lib\gemfire.jar
> C:\DEV\Pivotal\GemFire_v82014\lib\gfsh-dependencies.jar
>
> ………..
> C:\Program Files\Java\jdk1.7.0_67\lib\tools.jar
> C:\DEV\Pivotal\GemFire_v82014\lib\server-dependencies.jar
>
> start server \
> --name=${NAME} --server-port=${PORT} \
> --properties-file=${GEMFIRE_PWD}/resources/cache.properties \
> --J=-Dgemfire.distributed-system-id=${DISTRIBUTED_SYSTEM_ID} \
> --J=-Dgemfire.bind-address=${HOST_NAME}
> --J=-Dgemfire.server-bind-address=${HOST_NAME} \
> --J=-Dgemfire.locators=${HOST_NAME}[${LOCATOR_PORT}] \
> --J=-Dgemfire.OSProcess.ENABLE_OUTPUT_REDIRECTION=true \
> --include-system-classpath
>
> If I don’t pass this parameter, then it does not add gfsh-dependencies
> Class Path:
> C:\DEV\Pivotal\GemFire_v82014\lib\gemfire.jar
> C:\DEV\Pivotal\GemFire_v82014\lib\server-dependencies.jar
>
> I am trying to do testing without using –include-system-classpath instead add
> jars in to the start server –classpath as a work around.
> {noformat}
> And a subsequent reply from John Blum:
> {noformat}
> My apologies. I was not aware that you were launching your GemFire process
> (e.g. Server) using Gfsh, and specifically with gfsh.bat on Windows.
> I just confirmed the line(s) you were looking at in gfsh.bat, and indeed the
> BAT file is wrong! Specifically, the classpath for the GemFire process
> is being constructed from the following lines...
> @set
> GEMFIRE_JARS=%GEMFIRE%\lib\gemfire.jar;%GEMFIRE%\lib\antlr.jar;%GEMFIRE%\lib\gfsh-dependencies.jar;%GEMFIRE%\lib\pulse-dependencies.jar
> ...
> @set GFSH_JARS=;%GEMFIRE%\lib\gfsh-dependencies.jar
> @set CLASSPATH=%GFSH_JARS%;%GEMFIRE_JARS%
> The Windows BAT file is also inconsistent with the Bash shell version (gfsh),
> which rightfully only contains...
> GEMFIRE_JARS=$GEMFIRE/lib/gfsh-dependencies.jar
> if [ "x$CLASSPATH" != "x" ]; then
> GEMFIRE_JARS=$GEMFIRE_JARS:$CLASSPATH
> fi
> CLASSPATH=$GEMFIRE_JARS
> In addition, the Bash shell version launches the Gfsh process using the java
> -classpath option...
> "$GF_JAVA" -Dgfsh=true
> -Dlog4j.configurationFile=/com/gemstone/gemfire/internal/logging/log4j/log4j2-cli.xml
> ${JLINE_TERMINAL} -classpath "${CLASSPATH}" $JAVA_ARGS $LAUNCHER "$@"
> Which does not "export", or rather, set the global System CLASSPATH
> environment variable. Here it is only setting the Java System property
> to the Java process, where as, I believe, the Window BAT file is actually
> setting the System CLASSPATH environment variable, since there is no
> java -classpath option present in the command to launch Gfsh...
> @"%GF_JAVA%" -Dgfsh=tru
[jira] [Commented] (GEODE-1464) remove sqlfire references from geode-core
[ https://issues.apache.org/jira/browse/GEODE-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319742#comment-15319742 ] ASF subversion and git services commented on GEODE-1464: Commit 103a6bcdf9932dfe0ed5c34c71d942db0e2e02e1 in incubator-geode's branch refs/heads/feature/GEODE-835 from [~dschneider] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=103a6bc ] GEODE-1464: fix AnalyzeSerializablesJUnitTest > remove sqlfire references from geode-core > - > > Key: GEODE-1464 > URL: https://issues.apache.org/jira/browse/GEODE-1464 > Project: Geode > Issue Type: Task > Components: regions >Reporter: Darrel Schneider >Assignee: Darrel Schneider > Fix For: 1.0.0-incubating.M3 > > > Currently the geode-core has 307 lines that reference "sqlf". This should all > be dead code that can be cleaned up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-744) Incorrect use of APP_FETCH_SIZE in GFSH
[
https://issues.apache.org/jira/browse/GEODE-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319743#comment-15319743
]
ASF subversion and git services commented on GEODE-744:
---
Commit ec466fc38e8cc5fc65450362b8d313c35e6ea14f in incubator-geode's branch
refs/heads/feature/GEODE-835 from [~kduling]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=ec466fc ]
GEODE-744: Incorrect use of APP_FETCH_SIZE in GFSH
This closes #151
> Incorrect use of APP_FETCH_SIZE in GFSH
> ---
>
> Key: GEODE-744
> URL: https://issues.apache.org/jira/browse/GEODE-744
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Kevin Duling
> Attachments: workspace (1).zip
>
>
> A customer is facing an easily reproducible issue when executing queries from
> GFSH. It appears that the APP_FETCH_SIZE is being set only when parts of the
> query are in lower case. It happens in 7.0.X, 8.0.X and 8.1.X.
> Attached to the TRAC is the reproducible scenario, steps to reproduce:
> Uncompress the file.
> Modify variables "GEMFIRE" and "JAVA_HOME" in file setenv.txt.
> Execute "./start_cluster.sh".
> Exceute "./run.sh". This script inserts 1500 entries in the region and,
> afterwards, executes two queries, one using lower case and other using upper
> case. You can see from the console that ouput is different, one returns the
> actual size (1500) and the other one returns the default APP_FETCH_SIZE
> (1000).
> Exceute "./stop_cluster.sh".
> The fix seems pretty easy to implement, the method "addLimit" of the inner
> class "SelectExecStep?" in "DataCommandFunction?" class should be modified to
> compare strings without using the actual word case. Is not enough to add more
> "or" to the comparison like we are currently doing with since keywords like
> "Count" or "coUn" will still break the functionallity. We should compare
> everything using lower case or upper case, it doesn't matter which one, or at
> least make sure that gfsh converts the query to upper/lower case before
> actually executing them.
> The actual code with the problem is below:
> {noformat}
> private String addLimit(String query) {
> boolean containsLimitOrAggregate = query.contains(" limit")
> query.contains(" LIMIT") query.contains("count(*)");
> if (!containsLimitOrAggregate){
> String limitQuery = query + " limit " + getFetchSize();
> return limitQuery;
> } else {
> return query;
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1464) remove sqlfire references from geode-core
[ https://issues.apache.org/jira/browse/GEODE-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319741#comment-15319741 ] ASF subversion and git services commented on GEODE-1464: Commit 880f86483f6b75775f34e6821046ba18deb933f0 in incubator-geode's branch refs/heads/feature/GEODE-835 from [~dschneider] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=880f864 ] GEODE-1464: remove sqlf code > remove sqlfire references from geode-core > - > > Key: GEODE-1464 > URL: https://issues.apache.org/jira/browse/GEODE-1464 > Project: Geode > Issue Type: Task > Components: regions >Reporter: Darrel Schneider >Assignee: Darrel Schneider > Fix For: 1.0.0-incubating.M3 > > > Currently the geode-core has 307 lines that reference "sqlf". This should all > be dead code that can be cleaned up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1491) A rollback command could fail with IllegalStateException if the client failed over and the transaction has been rolled back.
[
https://issues.apache.org/jira/browse/GEODE-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319739#comment-15319739
]
ASF subversion and git services commented on GEODE-1491:
Commit 0815e1b6e9f11881b03780ac730856ee5db36c9c in incubator-geode's branch
refs/heads/feature/GEODE-835 from [~eshu]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=0815e1b ]
GEODE-1491: Make sure when checking if a transaction is completed from
isHostedTxRecentlyCompleted() method, the rolled back transaction is considered
as well.
> A rollback command could fail with IllegalStateException if the client failed
> over and the transaction has been rolled back.
>
>
> Key: GEODE-1491
> URL: https://issues.apache.org/jira/browse/GEODE-1491
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Reporter: Eric Shu
>
> {noformat}
> The TXManagerImpl rollback() method executes the followings.
> setTXState(null);
> tx.rollback();
> saveTXStateForClientFailover(tx);
> cleanup(tx.getTransactionId());
> noteRollbackSuccess(opStart, lifeTime, tx);
> In saveTXStateForClientFailover(), the txid is put into failovermap for
> failover operation. However as it is a rollback, tx.getCommitMessage()
> returns null.
> private void saveTXStateForClientFailover(TXStateProxy tx) {
> if (tx.isOnBehalfOfClient() && tx.isRealDealLocal()) {
> failoverMap.put(tx.getTxId(), tx.getCommitMessage());
> if (logger.isDebugEnabled()) {
> logger.debug("TX: storing client initiated transaction:{}; now there
> are {} entries in the failoverMap",
> tx.getTxId(), failoverMap.size());
> }
> }
> }
> If the proxyserver send the rollback message to the host server, but the
> client then failover to another proxy. The retry of rollback checks to see if
> the transaction is completed, before retries the rollback operation.
> @Override
> protected boolean operateOnTx(TXId txId,DistributionManager dm) {
> GemFireCacheImpl cache = GemFireCacheImpl.getInstance();
> if (cache == null) {
> throw new
> CacheClosedException(LocalizedStrings.CacheFactory_A_CACHE_HAS_NOT_YET_BEEN_CREATED.toLocalizedString());
> }
> TXManagerImpl txMgr = cache.getTXMgr();
> if (logger.isDebugEnabled()) {
> logger.debug("TX: Rolling back :{}", txId);
> }
> try {
> if (!txMgr.isHostedTxRecentlyCompleted(txId)) {
> txMgr.rollback();
> }
> } finally {
> txMgr.removeHostedTXState(txId);
> }
> return true;
> }
> The isHostedTxRecentlyCompleted() only checks if the transaction completed
> with a commit message.
> public boolean isHostedTxRecentlyCompleted(TXId txId) {
> TXCommitMessage msg = failoverMap.remove(txId);
> if (msg != null) {
> failoverMap.put(txId, msg);
> return true;
> }
> return false;
> }
> This could leads to a rollback command from a client failed with
> IllegalStateException: Thread does not have an active transaction
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-835) Replace joptsimple source with a binary dependency
[ https://issues.apache.org/jira/browse/GEODE-835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319744#comment-15319744 ] ASF subversion and git services commented on GEODE-835: --- Commit c66252eb1f7a55ea0b953cf53b098862e27dfb51 in incubator-geode's branch refs/heads/feature/GEODE-835 from [~apa...@the9muses.net] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=c66252e ] Merge remote-tracking branch 'origin/develop' into feature/GEODE-835 > Replace joptsimple source with a binary dependency > -- > > Key: GEODE-835 > URL: https://issues.apache.org/jira/browse/GEODE-835 > Project: Geode > Issue Type: Bug > Components: build, gfsh >Reporter: Anthony Baker >Assignee: Kirk Lund > Fix For: 1.0.0-incubating.M3 > > Attachments: joptsimple.patch > > > The gemfire-jopsimple folder contains modified source code from the > joptsimple library. We should replace this with a binary dependency. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1498) CI Failure: DurableClientCommandsDUnitTest.testCloseDurableClients
[ https://issues.apache.org/jira/browse/GEODE-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319740#comment-15319740 ] ASF subversion and git services commented on GEODE-1498: Commit 6967ac19f2a53cf4c71b69ae06ff8fb39003de4f in incubator-geode's branch refs/heads/feature/GEODE-835 from [~jchen21] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=6967ac1 ] GEODE-1498 CI Failure: DurableClientCommandsDUnitTest.testCloseDurableClients Use port 0 for cache server and return a random available port for durable client. > CI Failure: DurableClientCommandsDUnitTest.testCloseDurableClients > -- > > Key: GEODE-1498 > URL: https://issues.apache.org/jira/browse/GEODE-1498 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Jason Huynh >Assignee: Jianxia Chen > Labels: ci > Fix For: 1.0.0-incubating.M3 > > > Failed with the following: > com.gemstone.gemfire.test.dunit.RMIException: While invoking > com.gemstone.gemfire.management.internal.cli.commands.DurableClientCommandsDUnitTest$3.call > in VM 1 running on Host cc2-ub.gemstone.com with 4 VMs > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:389) > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:355) > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:320) > at > com.gemstone.gemfire.management.internal.cli.commands.DurableClientCommandsDUnitTest.startCacheServer(DurableClientCommandsDUnitTest.java:309) > at > com.gemstone.gemfire.management.internal.cli.commands.DurableClientCommandsDUnitTest.setupSystem(DurableClientCommandsDUnitTest.java:249) > at > com.gemstone.gemfire.management.internal.cli.commands.DurableClientCommandsDUnitTest.testCloseDurableClients(DurableClientCommandsDUnitTest.java:95) > 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 > 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.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:112) > 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:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.GeneratedMethodAccessor273.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(ContextClassLoade
[jira] [Commented] (GEODE-11) Lucene Integration
[ https://issues.apache.org/jira/browse/GEODE-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319737#comment-15319737 ] ASF subversion and git services commented on GEODE-11: -- Commit c742c4e54c0b3ab16ce7845e2534e746cefbbce1 in incubator-geode's branch refs/heads/feature/GEODE-835 from [~barry.oglesby] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=c742c4e ] GEODE-11: Added support for lucene index profile exchange > Lucene Integration > -- > > Key: GEODE-11 > URL: https://issues.apache.org/jira/browse/GEODE-11 > Project: Geode > Issue Type: New Feature > Components: querying >Reporter: Dan Smith >Assignee: xiaojian zhou > > This is a feature that has been under development for GemFire but was not > part of the initial drop of code for geode. > Allow Lucene indexes to be stored in Geode regions allowing users to do text > searches on data stored in Geode. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-744) Incorrect use of APP_FETCH_SIZE in GFSH
[
https://issues.apache.org/jira/browse/GEODE-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319711#comment-15319711
]
Kevin Duling commented on GEODE-744:
I saw a problem with the queries and consulted [~huynhja]. After talking with
him, I've a followup change. The issue is that there are more varieties of
count than simply * within the count(). Specifically, one can do:
{{count(distinct(field))}} or {{count(field)}}
This makes checking for only {{count( * )}} incorrect. My proposed solution is
to search for {{" count("}} like we now search for {{" limit"}}
> Incorrect use of APP_FETCH_SIZE in GFSH
> ---
>
> Key: GEODE-744
> URL: https://issues.apache.org/jira/browse/GEODE-744
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Kevin Duling
> Attachments: workspace (1).zip
>
>
> A customer is facing an easily reproducible issue when executing queries from
> GFSH. It appears that the APP_FETCH_SIZE is being set only when parts of the
> query are in lower case. It happens in 7.0.X, 8.0.X and 8.1.X.
> Attached to the TRAC is the reproducible scenario, steps to reproduce:
> Uncompress the file.
> Modify variables "GEMFIRE" and "JAVA_HOME" in file setenv.txt.
> Execute "./start_cluster.sh".
> Exceute "./run.sh". This script inserts 1500 entries in the region and,
> afterwards, executes two queries, one using lower case and other using upper
> case. You can see from the console that ouput is different, one returns the
> actual size (1500) and the other one returns the default APP_FETCH_SIZE
> (1000).
> Exceute "./stop_cluster.sh".
> The fix seems pretty easy to implement, the method "addLimit" of the inner
> class "SelectExecStep?" in "DataCommandFunction?" class should be modified to
> compare strings without using the actual word case. Is not enough to add more
> "or" to the comparison like we are currently doing with since keywords like
> "Count" or "coUn" will still break the functionallity. We should compare
> everything using lower case or upper case, it doesn't matter which one, or at
> least make sure that gfsh converts the query to upper/lower case before
> actually executing them.
> The actual code with the problem is below:
> {noformat}
> private String addLimit(String query) {
> boolean containsLimitOrAggregate = query.contains(" limit")
> query.contains(" LIMIT") query.contains("count(*)");
> if (!containsLimitOrAggregate){
> String limitQuery = query + " limit " + getFetchSize();
> return limitQuery;
> } else {
> return query;
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-744) Incorrect use of APP_FETCH_SIZE in GFSH
[
https://issues.apache.org/jira/browse/GEODE-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319689#comment-15319689
]
ASF GitHub Bot commented on GEODE-744:
--
Github user asfgit closed the pull request at:
https://github.com/apache/incubator-geode/pull/151
> Incorrect use of APP_FETCH_SIZE in GFSH
> ---
>
> Key: GEODE-744
> URL: https://issues.apache.org/jira/browse/GEODE-744
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Kevin Duling
> Attachments: workspace (1).zip
>
>
> A customer is facing an easily reproducible issue when executing queries from
> GFSH. It appears that the APP_FETCH_SIZE is being set only when parts of the
> query are in lower case. It happens in 7.0.X, 8.0.X and 8.1.X.
> Attached to the TRAC is the reproducible scenario, steps to reproduce:
> Uncompress the file.
> Modify variables "GEMFIRE" and "JAVA_HOME" in file setenv.txt.
> Execute "./start_cluster.sh".
> Exceute "./run.sh". This script inserts 1500 entries in the region and,
> afterwards, executes two queries, one using lower case and other using upper
> case. You can see from the console that ouput is different, one returns the
> actual size (1500) and the other one returns the default APP_FETCH_SIZE
> (1000).
> Exceute "./stop_cluster.sh".
> The fix seems pretty easy to implement, the method "addLimit" of the inner
> class "SelectExecStep?" in "DataCommandFunction?" class should be modified to
> compare strings without using the actual word case. Is not enough to add more
> "or" to the comparison like we are currently doing with since keywords like
> "Count" or "coUn" will still break the functionallity. We should compare
> everything using lower case or upper case, it doesn't matter which one, or at
> least make sure that gfsh converts the query to upper/lower case before
> actually executing them.
> The actual code with the problem is below:
> {noformat}
> private String addLimit(String query) {
> boolean containsLimitOrAggregate = query.contains(" limit")
> query.contains(" LIMIT") query.contains("count(*)");
> if (!containsLimitOrAggregate){
> String limitQuery = query + " limit " + getFetchSize();
> return limitQuery;
> } else {
> return query;
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-744) Incorrect use of APP_FETCH_SIZE in GFSH
[
https://issues.apache.org/jira/browse/GEODE-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319688#comment-15319688
]
ASF subversion and git services commented on GEODE-744:
---
Commit ec466fc38e8cc5fc65450362b8d313c35e6ea14f in incubator-geode's branch
refs/heads/develop from [~kduling]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=ec466fc ]
GEODE-744: Incorrect use of APP_FETCH_SIZE in GFSH
This closes #151
> Incorrect use of APP_FETCH_SIZE in GFSH
> ---
>
> Key: GEODE-744
> URL: https://issues.apache.org/jira/browse/GEODE-744
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Kevin Duling
> Attachments: workspace (1).zip
>
>
> A customer is facing an easily reproducible issue when executing queries from
> GFSH. It appears that the APP_FETCH_SIZE is being set only when parts of the
> query are in lower case. It happens in 7.0.X, 8.0.X and 8.1.X.
> Attached to the TRAC is the reproducible scenario, steps to reproduce:
> Uncompress the file.
> Modify variables "GEMFIRE" and "JAVA_HOME" in file setenv.txt.
> Execute "./start_cluster.sh".
> Exceute "./run.sh". This script inserts 1500 entries in the region and,
> afterwards, executes two queries, one using lower case and other using upper
> case. You can see from the console that ouput is different, one returns the
> actual size (1500) and the other one returns the default APP_FETCH_SIZE
> (1000).
> Exceute "./stop_cluster.sh".
> The fix seems pretty easy to implement, the method "addLimit" of the inner
> class "SelectExecStep?" in "DataCommandFunction?" class should be modified to
> compare strings without using the actual word case. Is not enough to add more
> "or" to the comparison like we are currently doing with since keywords like
> "Count" or "coUn" will still break the functionallity. We should compare
> everything using lower case or upper case, it doesn't matter which one, or at
> least make sure that gfsh converts the query to upper/lower case before
> actually executing them.
> The actual code with the problem is below:
> {noformat}
> private String addLimit(String query) {
> boolean containsLimitOrAggregate = query.contains(" limit")
> query.contains(" LIMIT") query.contains("count(*)");
> if (!containsLimitOrAggregate){
> String limitQuery = query + " limit " + getFetchSize();
> return limitQuery;
> } else {
> return query;
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-744) Incorrect use of APP_FETCH_SIZE in GFSH
[
https://issues.apache.org/jira/browse/GEODE-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319683#comment-15319683
]
ASF GitHub Bot commented on GEODE-744:
--
Github user jinmeiliao commented on the issue:
https://github.com/apache/incubator-geode/pull/151
+1
> Incorrect use of APP_FETCH_SIZE in GFSH
> ---
>
> Key: GEODE-744
> URL: https://issues.apache.org/jira/browse/GEODE-744
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Kevin Duling
> Attachments: workspace (1).zip
>
>
> A customer is facing an easily reproducible issue when executing queries from
> GFSH. It appears that the APP_FETCH_SIZE is being set only when parts of the
> query are in lower case. It happens in 7.0.X, 8.0.X and 8.1.X.
> Attached to the TRAC is the reproducible scenario, steps to reproduce:
> Uncompress the file.
> Modify variables "GEMFIRE" and "JAVA_HOME" in file setenv.txt.
> Execute "./start_cluster.sh".
> Exceute "./run.sh". This script inserts 1500 entries in the region and,
> afterwards, executes two queries, one using lower case and other using upper
> case. You can see from the console that ouput is different, one returns the
> actual size (1500) and the other one returns the default APP_FETCH_SIZE
> (1000).
> Exceute "./stop_cluster.sh".
> The fix seems pretty easy to implement, the method "addLimit" of the inner
> class "SelectExecStep?" in "DataCommandFunction?" class should be modified to
> compare strings without using the actual word case. Is not enough to add more
> "or" to the comparison like we are currently doing with since keywords like
> "Count" or "coUn" will still break the functionallity. We should compare
> everything using lower case or upper case, it doesn't matter which one, or at
> least make sure that gfsh converts the query to upper/lower case before
> actually executing them.
> The actual code with the problem is below:
> {noformat}
> private String addLimit(String query) {
> boolean containsLimitOrAggregate = query.contains(" limit")
> query.contains(" LIMIT") query.contains("count(*)");
> if (!containsLimitOrAggregate){
> String limitQuery = query + " limit " + getFetchSize();
> return limitQuery;
> } else {
> return query;
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-744) Incorrect use of APP_FETCH_SIZE in GFSH
[
https://issues.apache.org/jira/browse/GEODE-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319681#comment-15319681
]
ASF GitHub Bot commented on GEODE-744:
--
Github user jinmeiliao commented on the issue:
https://github.com/apache/incubator-geode/pull/151
Not sure if this works, the example it gives are those queries
echo "query --query=\"select count(*) from /replicatedRegion.keySet\"" >>
query_region.gfsh
echo "query --query=\"SELECT COUNT(*) FROM /replicatedRegion.keySet\"" >>
query_region.gfsh
would count() be the same as count(*)?
> Incorrect use of APP_FETCH_SIZE in GFSH
> ---
>
> Key: GEODE-744
> URL: https://issues.apache.org/jira/browse/GEODE-744
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Kevin Duling
> Attachments: workspace (1).zip
>
>
> A customer is facing an easily reproducible issue when executing queries from
> GFSH. It appears that the APP_FETCH_SIZE is being set only when parts of the
> query are in lower case. It happens in 7.0.X, 8.0.X and 8.1.X.
> Attached to the TRAC is the reproducible scenario, steps to reproduce:
> Uncompress the file.
> Modify variables "GEMFIRE" and "JAVA_HOME" in file setenv.txt.
> Execute "./start_cluster.sh".
> Exceute "./run.sh". This script inserts 1500 entries in the region and,
> afterwards, executes two queries, one using lower case and other using upper
> case. You can see from the console that ouput is different, one returns the
> actual size (1500) and the other one returns the default APP_FETCH_SIZE
> (1000).
> Exceute "./stop_cluster.sh".
> The fix seems pretty easy to implement, the method "addLimit" of the inner
> class "SelectExecStep?" in "DataCommandFunction?" class should be modified to
> compare strings without using the actual word case. Is not enough to add more
> "or" to the comparison like we are currently doing with since keywords like
> "Count" or "coUn" will still break the functionallity. We should compare
> everything using lower case or upper case, it doesn't matter which one, or at
> least make sure that gfsh converts the query to upper/lower case before
> actually executing them.
> The actual code with the problem is below:
> {noformat}
> private String addLimit(String query) {
> boolean containsLimitOrAggregate = query.contains(" limit")
> query.contains(" LIMIT") query.contains("count(*)");
> if (!containsLimitOrAggregate){
> String limitQuery = query + " limit " + getFetchSize();
> return limitQuery;
> } else {
> return query;
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-744) Incorrect use of APP_FETCH_SIZE in GFSH
[
https://issues.apache.org/jira/browse/GEODE-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319678#comment-15319678
]
ASF GitHub Bot commented on GEODE-744:
--
Github user jinmeiliao commented on the issue:
https://github.com/apache/incubator-geode/pull/151
I don't think this would fix the problem. The problem is that the following
two queries would return different results. Your change would still make them
do that.
query --query=\"select count(*) from /replicatedRegion.keySet\"
query --query=\"SELECT COUNT(*) FROM /replicatedRegion.keySet\"
I believe what Jens suggests is to convert the query string to
lowercase/uppercase first and then checks for "contains" limit or count.
> Incorrect use of APP_FETCH_SIZE in GFSH
> ---
>
> Key: GEODE-744
> URL: https://issues.apache.org/jira/browse/GEODE-744
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Kevin Duling
> Attachments: workspace (1).zip
>
>
> A customer is facing an easily reproducible issue when executing queries from
> GFSH. It appears that the APP_FETCH_SIZE is being set only when parts of the
> query are in lower case. It happens in 7.0.X, 8.0.X and 8.1.X.
> Attached to the TRAC is the reproducible scenario, steps to reproduce:
> Uncompress the file.
> Modify variables "GEMFIRE" and "JAVA_HOME" in file setenv.txt.
> Execute "./start_cluster.sh".
> Exceute "./run.sh". This script inserts 1500 entries in the region and,
> afterwards, executes two queries, one using lower case and other using upper
> case. You can see from the console that ouput is different, one returns the
> actual size (1500) and the other one returns the default APP_FETCH_SIZE
> (1000).
> Exceute "./stop_cluster.sh".
> The fix seems pretty easy to implement, the method "addLimit" of the inner
> class "SelectExecStep?" in "DataCommandFunction?" class should be modified to
> compare strings without using the actual word case. Is not enough to add more
> "or" to the comparison like we are currently doing with since keywords like
> "Count" or "coUn" will still break the functionallity. We should compare
> everything using lower case or upper case, it doesn't matter which one, or at
> least make sure that gfsh converts the query to upper/lower case before
> actually executing them.
> The actual code with the problem is below:
> {noformat}
> private String addLimit(String query) {
> boolean containsLimitOrAggregate = query.contains(" limit")
> query.contains(" LIMIT") query.contains("count(*)");
> if (!containsLimitOrAggregate){
> String limitQuery = query + " limit " + getFetchSize();
> return limitQuery;
> } else {
> return query;
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-68) GFSH SYS_HOST_NAME variable should report hostname if available
[
https://issues.apache.org/jira/browse/GEODE-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319675#comment-15319675
]
Kevin Duling commented on GEODE-68:
---
[~markito] can you comment on this? When you refer to the hostname, are you
expecting the name of the box or the name of the dominant network interface?
> GFSH SYS_HOST_NAME variable should report hostname if available
> ---
>
> Key: GEODE-68
> URL: https://issues.apache.org/jira/browse/GEODE-68
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: William Markito Oliveira
>Assignee: Kevin Duling
>Priority: Minor
> Labels: gfsh
>
> SYS_HOST_NAME is actually displaying SYS_USER_HOME.
> This is very useful for automation scripts.
> {code}
> gfsh>echo --string=$*
>Property| Value
> -- |
> --
> APP_COLLECTION_LIMIT | 20
> APP_FETCH_SIZE | 1000
> APP_LAST_EXIT_STATUS | 0
> APP_LOGGING_ENABLED| false
> APP_LOG_FILE | /Users/wmarkito/gfsh-%u_%g.log
> APP_NAME | gfsh
> APP_PWD| /Users/wmarkito
> APP_QUERY_RESULTS_DISPLAY_MODE | table
> APP_QUIET_EXECUTION| false
> APP_RESULT_VIEWER | basic
> SYS_CLASSPATH |
> /Users/wmarkito/Pivotal/GemFire/sources/github/gemfire/build-artifacts/mac/product/lib/gfsh-dependencies.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home/lib/tools.jar
> SYS_GEMFIRE_DIR| /Users/wmarkito/...
> SYS_HOST_NAME | wmarkito
> SYS_JAVA_VERSION | 1.7.0_72
> SYS_OS | Mac OS X
> SYS_OS_LINE_SEPARATOR |
> SYS_USER | wmarkito
> SYS_USER_HOME | /Users/wmarkito
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1498) CI Failure: DurableClientCommandsDUnitTest.testCloseDurableClients
[ https://issues.apache.org/jira/browse/GEODE-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319519#comment-15319519 ] ASF subversion and git services commented on GEODE-1498: Commit 6967ac19f2a53cf4c71b69ae06ff8fb39003de4f in incubator-geode's branch refs/heads/feature/GEODE-837 from [~jchen21] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=6967ac1 ] GEODE-1498 CI Failure: DurableClientCommandsDUnitTest.testCloseDurableClients Use port 0 for cache server and return a random available port for durable client. > CI Failure: DurableClientCommandsDUnitTest.testCloseDurableClients > -- > > Key: GEODE-1498 > URL: https://issues.apache.org/jira/browse/GEODE-1498 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Jason Huynh >Assignee: Jianxia Chen > Labels: ci > Fix For: 1.0.0-incubating.M3 > > > Failed with the following: > com.gemstone.gemfire.test.dunit.RMIException: While invoking > com.gemstone.gemfire.management.internal.cli.commands.DurableClientCommandsDUnitTest$3.call > in VM 1 running on Host cc2-ub.gemstone.com with 4 VMs > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:389) > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:355) > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:320) > at > com.gemstone.gemfire.management.internal.cli.commands.DurableClientCommandsDUnitTest.startCacheServer(DurableClientCommandsDUnitTest.java:309) > at > com.gemstone.gemfire.management.internal.cli.commands.DurableClientCommandsDUnitTest.setupSystem(DurableClientCommandsDUnitTest.java:249) > at > com.gemstone.gemfire.management.internal.cli.commands.DurableClientCommandsDUnitTest.testCloseDurableClients(DurableClientCommandsDUnitTest.java:95) > 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 > 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.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:112) > 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:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.GeneratedMethodAccessor273.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(ContextClassLoade
[jira] [Commented] (GEODE-1491) A rollback command could fail with IllegalStateException if the client failed over and the transaction has been rolled back.
[
https://issues.apache.org/jira/browse/GEODE-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319518#comment-15319518
]
ASF subversion and git services commented on GEODE-1491:
Commit 0815e1b6e9f11881b03780ac730856ee5db36c9c in incubator-geode's branch
refs/heads/feature/GEODE-837 from [~eshu]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=0815e1b ]
GEODE-1491: Make sure when checking if a transaction is completed from
isHostedTxRecentlyCompleted() method, the rolled back transaction is considered
as well.
> A rollback command could fail with IllegalStateException if the client failed
> over and the transaction has been rolled back.
>
>
> Key: GEODE-1491
> URL: https://issues.apache.org/jira/browse/GEODE-1491
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Reporter: Eric Shu
>
> {noformat}
> The TXManagerImpl rollback() method executes the followings.
> setTXState(null);
> tx.rollback();
> saveTXStateForClientFailover(tx);
> cleanup(tx.getTransactionId());
> noteRollbackSuccess(opStart, lifeTime, tx);
> In saveTXStateForClientFailover(), the txid is put into failovermap for
> failover operation. However as it is a rollback, tx.getCommitMessage()
> returns null.
> private void saveTXStateForClientFailover(TXStateProxy tx) {
> if (tx.isOnBehalfOfClient() && tx.isRealDealLocal()) {
> failoverMap.put(tx.getTxId(), tx.getCommitMessage());
> if (logger.isDebugEnabled()) {
> logger.debug("TX: storing client initiated transaction:{}; now there
> are {} entries in the failoverMap",
> tx.getTxId(), failoverMap.size());
> }
> }
> }
> If the proxyserver send the rollback message to the host server, but the
> client then failover to another proxy. The retry of rollback checks to see if
> the transaction is completed, before retries the rollback operation.
> @Override
> protected boolean operateOnTx(TXId txId,DistributionManager dm) {
> GemFireCacheImpl cache = GemFireCacheImpl.getInstance();
> if (cache == null) {
> throw new
> CacheClosedException(LocalizedStrings.CacheFactory_A_CACHE_HAS_NOT_YET_BEEN_CREATED.toLocalizedString());
> }
> TXManagerImpl txMgr = cache.getTXMgr();
> if (logger.isDebugEnabled()) {
> logger.debug("TX: Rolling back :{}", txId);
> }
> try {
> if (!txMgr.isHostedTxRecentlyCompleted(txId)) {
> txMgr.rollback();
> }
> } finally {
> txMgr.removeHostedTXState(txId);
> }
> return true;
> }
> The isHostedTxRecentlyCompleted() only checks if the transaction completed
> with a commit message.
> public boolean isHostedTxRecentlyCompleted(TXId txId) {
> TXCommitMessage msg = failoverMap.remove(txId);
> if (msg != null) {
> failoverMap.put(txId, msg);
> return true;
> }
> return false;
> }
> This could leads to a rollback command from a client failed with
> IllegalStateException: Thread does not have an active transaction
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-11) Lucene Integration
[ https://issues.apache.org/jira/browse/GEODE-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319517#comment-15319517 ] ASF subversion and git services commented on GEODE-11: -- Commit c742c4e54c0b3ab16ce7845e2534e746cefbbce1 in incubator-geode's branch refs/heads/feature/GEODE-837 from [~barry.oglesby] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=c742c4e ] GEODE-11: Added support for lucene index profile exchange > Lucene Integration > -- > > Key: GEODE-11 > URL: https://issues.apache.org/jira/browse/GEODE-11 > Project: Geode > Issue Type: New Feature > Components: querying >Reporter: Dan Smith >Assignee: xiaojian zhou > > This is a feature that has been under development for GemFire but was not > part of the initial drop of code for geode. > Allow Lucene indexes to be stored in Geode regions allowing users to do text > searches on data stored in Geode. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-837) Jenkins is not picking up test results
[
https://issues.apache.org/jira/browse/GEODE-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319522#comment-15319522
]
ASF subversion and git services commented on GEODE-837:
---
Commit 5c048b388d61ca3685af5f9425e53e406ee080cf in incubator-geode's branch
refs/heads/feature/GEODE-837 from [~apa...@the9muses.net]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=5c048b3 ]
Merge remote-tracking branch 'origin/develop' into feature/GEODE-837
> Jenkins is not picking up test results
> --
>
> Key: GEODE-837
> URL: https://issues.apache.org/jira/browse/GEODE-837
> Project: Geode
> Issue Type: Bug
> Components: build
>Reporter: Dan Smith
>Assignee: Kirk Lund
>
> After c5efb80518abc2a2c7390af1d46e7c5892801e55, where we stopped searching
> for specific test names, jenkins is no longer reporting dunit test results.
> The tests are still being run, but the XML reports that jenkins uses are
> empty.
> I tracked the issue down partially. It looks like what is happening is the
> dunit tests are running and reporting results, but then when the integration
> tests run, it generates new XML files that overrwrite the dunit results in
> gemfire-core/build/test-results with files that look like this (see how there
> are no test results reported)
> {noformat}
> tests="0" skipped="0" failures="0" errors="0" timestamp="1970-01-01T00:00:00"
> hostname="dsmith-virtual" time="0.0">
> {noformat}
> It looks like this has something to do with the junit category stuff. Unit
> tests files aren't getting stomped on like this, but dunit test files are.
> Perhaps something to do with the DistributedTestCase hierarchy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1331) gfsh.bat on Windows is incorrect
[
https://issues.apache.org/jira/browse/GEODE-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319516#comment-15319516
]
ASF subversion and git services commented on GEODE-1331:
Commit 8e21638ce336aee07bec33d140500c76d1cedc53 in incubator-geode's branch
refs/heads/feature/GEODE-837 from [~kduling]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=8e21638 ]
GEODE-1331: gfsh.bat on Windows is incorrect.
* Renamed internal variable from CLASSPATH to DEPENDENCIES.
* Verified @setlocal was not altering the System environment variables for the
shell.
* Launch with -classpath param like the bash script does.
* Ensured command-line arguments match bash script's order of arguments.
* This closes #149
> gfsh.bat on Windows is incorrect
>
>
> Key: GEODE-1331
> URL: https://issues.apache.org/jira/browse/GEODE-1331
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Kevin Duling
> Fix For: 1.0.0-incubating.M3
>
>
> Initial report:
> {noformat}
> I am doing testing in windows STS. I am not adding these dependencies jars,
> gfsh.bat is what doing this.
>
> C:\DEV\Pivotal\GemFire_v82014\bin\gfsh.bat has below code, which is setting
> gemfire, antlr, gfsh-dependencies and pulse-dependencies jars in classpath.
> Line 26 to 29
> @set
> GEMFIRE_JARS=%GEMFIRE%\lib\gemfire.jar;%GEMFIRE%\lib\antlr.jar;%GEMFIRE%\lib\gfsh-dependencies.jar;%GEMFIRE%\lib\pulse-dependencies.jar
> @if defined CLASSPATH (
> @set GEMFIRE_JARS=%GEMFIRE_JARS%;%CLASSPATH%
> )
> C:\DEV\Pivotal\GemFire_v82014\lib\gemfire.jar // DUPLICATE
> C:\DEV\Pivotal\GemFire_v82014\lib\antlr.jar
> C:\DEV\Pivotal\GemFire_v82014\lib\gfsh-dependencies.jar // DUPLICATE
> C:\DEV\Pivotal\GemFire_v82014\lib\pulse-dependencies.jar
>
> Unix C:\DEV\Pivotal\GemFire_v82014\bin script, does not set these jars in
> classpath.
>
>
> Another observation is that, if I pass --include-system-classpath to gfsh
> start server command, then it is prepending
> gemfire.jar and gfsh-dependencies.jar to the system classpath and adding that
> to the server, that is what is shown in logs
> Class Path:
> C:\DEV\Pivotal\GemFire_v82014\lib\gemfire.jar
> C:\DEV\Pivotal\GemFire_v82014\lib\gfsh-dependencies.jar
>
> ………..
> C:\Program Files\Java\jdk1.7.0_67\lib\tools.jar
> C:\DEV\Pivotal\GemFire_v82014\lib\server-dependencies.jar
>
> start server \
> --name=${NAME} --server-port=${PORT} \
> --properties-file=${GEMFIRE_PWD}/resources/cache.properties \
> --J=-Dgemfire.distributed-system-id=${DISTRIBUTED_SYSTEM_ID} \
> --J=-Dgemfire.bind-address=${HOST_NAME}
> --J=-Dgemfire.server-bind-address=${HOST_NAME} \
> --J=-Dgemfire.locators=${HOST_NAME}[${LOCATOR_PORT}] \
> --J=-Dgemfire.OSProcess.ENABLE_OUTPUT_REDIRECTION=true \
> --include-system-classpath
>
> If I don’t pass this parameter, then it does not add gfsh-dependencies
> Class Path:
> C:\DEV\Pivotal\GemFire_v82014\lib\gemfire.jar
> C:\DEV\Pivotal\GemFire_v82014\lib\server-dependencies.jar
>
> I am trying to do testing without using –include-system-classpath instead add
> jars in to the start server –classpath as a work around.
> {noformat}
> And a subsequent reply from John Blum:
> {noformat}
> My apologies. I was not aware that you were launching your GemFire process
> (e.g. Server) using Gfsh, and specifically with gfsh.bat on Windows.
> I just confirmed the line(s) you were looking at in gfsh.bat, and indeed the
> BAT file is wrong! Specifically, the classpath for the GemFire process
> is being constructed from the following lines...
> @set
> GEMFIRE_JARS=%GEMFIRE%\lib\gemfire.jar;%GEMFIRE%\lib\antlr.jar;%GEMFIRE%\lib\gfsh-dependencies.jar;%GEMFIRE%\lib\pulse-dependencies.jar
> ...
> @set GFSH_JARS=;%GEMFIRE%\lib\gfsh-dependencies.jar
> @set CLASSPATH=%GFSH_JARS%;%GEMFIRE_JARS%
> The Windows BAT file is also inconsistent with the Bash shell version (gfsh),
> which rightfully only contains...
> GEMFIRE_JARS=$GEMFIRE/lib/gfsh-dependencies.jar
> if [ "x$CLASSPATH" != "x" ]; then
> GEMFIRE_JARS=$GEMFIRE_JARS:$CLASSPATH
> fi
> CLASSPATH=$GEMFIRE_JARS
> In addition, the Bash shell version launches the Gfsh process using the java
> -classpath option...
> "$GF_JAVA" -Dgfsh=true
> -Dlog4j.configurationFile=/com/gemstone/gemfire/internal/logging/log4j/log4j2-cli.xml
> ${JLINE_TERMINAL} -classpath "${CLASSPATH}" $JAVA_ARGS $LAUNCHER "$@"
> Which does not "export", or rather, set the global System CLASSPATH
> environment variable. Here it is only setting the Java System property
> to the Java process, where as, I believe, the Window BAT file is actually
> setting the System CLASSPATH environment variable, since there is no
> java -classpath option present in the command to launch Gfsh...
> @"%GF_JAVA%" -Dgfsh=tru
[jira] [Commented] (GEODE-1464) remove sqlfire references from geode-core
[ https://issues.apache.org/jira/browse/GEODE-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319521#comment-15319521 ] ASF subversion and git services commented on GEODE-1464: Commit 103a6bcdf9932dfe0ed5c34c71d942db0e2e02e1 in incubator-geode's branch refs/heads/feature/GEODE-837 from [~dschneider] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=103a6bc ] GEODE-1464: fix AnalyzeSerializablesJUnitTest > remove sqlfire references from geode-core > - > > Key: GEODE-1464 > URL: https://issues.apache.org/jira/browse/GEODE-1464 > Project: Geode > Issue Type: Task > Components: regions >Reporter: Darrel Schneider >Assignee: Darrel Schneider > Fix For: 1.0.0-incubating.M3 > > > Currently the geode-core has 307 lines that reference "sqlf". This should all > be dead code that can be cleaned up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1464) remove sqlfire references from geode-core
[ https://issues.apache.org/jira/browse/GEODE-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319520#comment-15319520 ] ASF subversion and git services commented on GEODE-1464: Commit 880f86483f6b75775f34e6821046ba18deb933f0 in incubator-geode's branch refs/heads/feature/GEODE-837 from [~dschneider] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=880f864 ] GEODE-1464: remove sqlf code > remove sqlfire references from geode-core > - > > Key: GEODE-1464 > URL: https://issues.apache.org/jira/browse/GEODE-1464 > Project: Geode > Issue Type: Task > Components: regions >Reporter: Darrel Schneider >Assignee: Darrel Schneider > Fix For: 1.0.0-incubating.M3 > > > Currently the geode-core has 307 lines that reference "sqlf". This should all > be dead code that can be cleaned up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-68) GFSH SYS_HOST_NAME variable should report hostname if available
[
https://issues.apache.org/jira/browse/GEODE-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319479#comment-15319479
]
ASF GitHub Bot commented on GEODE-68:
-
Github user kjduling commented on a diff in the pull request:
https://github.com/apache/incubator-geode/pull/152#discussion_r66156949
--- Diff:
geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/shell/Gfsh.java
---
@@ -279,7 +281,12 @@ protected Gfsh(boolean launchShell, String[] args,
GfshConfig gfshConfig) throws
private void initializeEnvironment() {
env.put(ENV_SYS_USER, System.getProperty("user.name"));
env.put(ENV_SYS_USER_HOME, System.getProperty("user.home"));
-env.put(ENV_SYS_HOST_NAME, System.getProperty("user.name"));
+try {
+ env.put(ENV_SYS_HOST_NAME,
InetAddress.getLocalHost().getHostName());
--- End diff --
I think we might need to back up and define exactly what is meant by
hostname. Are we talking about the name of the machine or the DNS value for a
specific NIC?
For example,
If I run the 'hostname' command from the terminal, I get one name for my
system.
If I run the java code above, I receive the same name. This is equivalent
to calling the C lib gethostname(3).
If I run this with the suggested call, I receive the name of my en4
interface, or my 'default', which is not the same value.
Which is the expected behavior? The name of the machine or the name of the
NIC on the default route?
> GFSH SYS_HOST_NAME variable should report hostname if available
> ---
>
> Key: GEODE-68
> URL: https://issues.apache.org/jira/browse/GEODE-68
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: William Markito Oliveira
>Assignee: Kevin Duling
>Priority: Minor
> Labels: gfsh
>
> SYS_HOST_NAME is actually displaying SYS_USER_HOME.
> This is very useful for automation scripts.
> {code}
> gfsh>echo --string=$*
>Property| Value
> -- |
> --
> APP_COLLECTION_LIMIT | 20
> APP_FETCH_SIZE | 1000
> APP_LAST_EXIT_STATUS | 0
> APP_LOGGING_ENABLED| false
> APP_LOG_FILE | /Users/wmarkito/gfsh-%u_%g.log
> APP_NAME | gfsh
> APP_PWD| /Users/wmarkito
> APP_QUERY_RESULTS_DISPLAY_MODE | table
> APP_QUIET_EXECUTION| false
> APP_RESULT_VIEWER | basic
> SYS_CLASSPATH |
> /Users/wmarkito/Pivotal/GemFire/sources/github/gemfire/build-artifacts/mac/product/lib/gfsh-dependencies.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home/lib/tools.jar
> SYS_GEMFIRE_DIR| /Users/wmarkito/...
> SYS_HOST_NAME | wmarkito
> SYS_JAVA_VERSION | 1.7.0_72
> SYS_OS | Mac OS X
> SYS_OS_LINE_SEPARATOR |
> SYS_USER | wmarkito
> SYS_USER_HOME | /Users/wmarkito
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1450) Move ExampleJSONAuthorization out of 'test' and into 'main'
[ https://issues.apache.org/jira/browse/GEODE-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319389#comment-15319389 ] ASF subversion and git services commented on GEODE-1450: Commit 1aa39174daa8ab2b2017013a62ff297fda7362e4 in incubator-geode's branch refs/heads/feature/GEODE-837 from [~jens.deppe] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=1aa3917 ] GEODE-1450: Move ExampleJSONAuthorization out of 'test' and into 'main' > Move ExampleJSONAuthorization out of 'test' and into 'main' > --- > > Key: GEODE-1450 > URL: https://issues.apache.org/jira/browse/GEODE-1450 > Project: Geode > Issue Type: Task > Components: security >Reporter: Jens Deppe >Assignee: Jens Deppe > > Adding a wiki page and I'd like to be able to reference this class as an > example. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1450) Move ExampleJSONAuthorization out of 'test' and into 'main'
[ https://issues.apache.org/jira/browse/GEODE-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319388#comment-15319388 ] ASF subversion and git services commented on GEODE-1450: Commit d24a5fb1329a9bcc7f6148a883fef298da2c4a8e in incubator-geode's branch refs/heads/feature/GEODE-837 from [~jens.deppe] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=d24a5fb ] GEODE-1450: Move ExampleJSONAuthorization out of 'test' and into 'main' - This also renames the class to SampleJsonAuthorization (it's already in an 'examples' package so I figured the original name was a bit redundant). - Once we have an 'examples' submodule this class could be refactored a bit more and moved there (or simply extended there with a thin wrapper). > Move ExampleJSONAuthorization out of 'test' and into 'main' > --- > > Key: GEODE-1450 > URL: https://issues.apache.org/jira/browse/GEODE-1450 > Project: Geode > Issue Type: Task > Components: security >Reporter: Jens Deppe >Assignee: Jens Deppe > > Adding a wiki page and I'd like to be able to reference this class as an > example. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1468) client/server messaging can create large objects
[ https://issues.apache.org/jira/browse/GEODE-1468?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319391#comment-15319391 ] ASF subversion and git services commented on GEODE-1468: Commit 61ad7e4451aa5504c2f5d92b5d41ce1ffbcec239 in incubator-geode's branch refs/heads/feature/GEODE-837 from [~bschuchardt] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=61ad7e4 ] GEODE-1468 client/server messaging can create large objects After a Message has been sent we invoke clear() on each Part contained by the Message. This was nulling out the "part" variable of the Part objects but if one of these "parts" was a HeapDataOutputStream it might hold a list of large buffers. This change set alters Part to close these streams so that their buffers can be cleared. > client/server messaging can create large objects > > > Key: GEODE-1468 > URL: https://issues.apache.org/jira/browse/GEODE-1468 > Project: Geode > Issue Type: Bug > Components: serialization >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt > Fix For: 1.0.0-incubating.M3 > > > Client/server messaging uses a Message object containint Parts. Each Part > holds a HeapDataOutputStream that serializes the item placed in that Part. > Once the Message finishes transmitting its contents it clears the "parts" > array, setting it to null, but this array may consume a sizeable amount of > heap - mainly in the byte-buffer "chunks" list held in the > HeapDataOutputStreams. It would help with GC if these "chunks" lists were > cleared as part of Message clean-up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1377) Move DistributionConfig constants to a public package
[ https://issues.apache.org/jira/browse/GEODE-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319387#comment-15319387 ] ASF subversion and git services commented on GEODE-1377: Commit 653eaf28cf032545936ac9462fe8361ebfe88de1 in incubator-geode's branch refs/heads/feature/GEODE-837 from [~huynhja] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=653eaf2 ] GEODE-1377: Changed property for spark tests to use new DistributedSystemConfigProperties > Move DistributionConfig constants to a public package > - > > Key: GEODE-1377 > URL: https://issues.apache.org/jira/browse/GEODE-1377 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Bruce Schuchardt >Assignee: Udo Kohlmeyer > > DistributionConfig contains the names of all distributed-system properties > and their default values. The configuration constants in this class should > be moved to a public interface so that applications can reference the > property names and so not have to spell them out. For instance, > DistributionConfig.LOCATORS_NAME instead of "locators". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1469) gfsh multi-step commands fail using http
[
https://issues.apache.org/jira/browse/GEODE-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319390#comment-15319390
]
ASF subversion and git services commented on GEODE-1469:
Commit 711fc3518eb802d9400e740a4011a189ca0fd372 in incubator-geode's branch
refs/heads/feature/GEODE-837 from [~jinmeiliao]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=711fc35 ]
GEODE-1469: correctly handle the step arguements in http request
> gfsh multi-step commands fail using http
>
>
> Key: GEODE-1469
> URL: https://issues.apache.org/jira/browse/GEODE-1469
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jinmei Liao
>Assignee: Jinmei Liao
>
> An example is querying.
> Connect using http:
> {noformat}
> gfsh>connect --use-http --url=http://localhost:7070/gemfire/v1
> Successfully connected to: GemFire Manager HTTP service @
> http://localhost:7070/gemfire/v1
> {noformat}
> Execute query:
> {noformat}
> gfsh>query --query="SELECT id, cusip FROM /data"
> Result : true
> startCount : 0
> endCount : 20
> Rows : 1000
> id | cusip
> --- | -
> 877 | YGE
> ...
> 790 | GGB
> Press n to move to next page, q to quit and p to previous page : n
> {noformat}
> Selecting 'n' logs this message:
> {noformat}
> Exception occurred. Map has no value for '"startCount"'
> {noformat}
> With fine logging enabled, the gfsh log shows:
> {noformat}
> [warning 2016/05/20 17:01:03.694 PDT Gfsh Launcher tid=0xc] (msgTID=12
> msgSN=68) Exception occurred. Map has no value for '"startCount"'
> java.lang.IllegalArgumentException: Map has no value for '"startCount"'
> at
> org.springframework.web.util.UriComponents$MapTemplateVariables.getValue(UriComponents.java:252)
> at
> org.springframework.web.util.UriComponents.expandUriComponent(UriComponents.java:210)
> at
> org.springframework.web.util.HierarchicalUriComponents.expandInternal(HierarchicalUriComponents.java:314)
> at
> org.springframework.web.util.HierarchicalUriComponents.expandInternal(HierarchicalUriComponents.java:46)
> at
> org.springframework.web.util.UriComponents.expand(UriComponents.java:152)
> at
> com.gemstone.gemfire.management.internal.web.http.ClientHttpRequest.getURL(ClientHttpRequest.java:273)
> at
> com.gemstone.gemfire.management.internal.web.shell.AbstractHttpOperationInvoker.send(AbstractHttpOperationInvoker.java:537)
> at
> com.gemstone.gemfire.management.internal.web.shell.RestHttpOperationInvoker.processCommand(RestHttpOperationInvoker.java:350)
> at
> com.gemstone.gemfire.management.internal.web.shell.RestHttpOperationInvoker.processCommand(RestHttpOperationInvoker.java:53)
> at
> com.gemstone.gemfire.management.internal.cli.multistep.CLIMultiStepHelper.executeStep(CLIMultiStepHelper.java:118)
> at
> com.gemstone.gemfire.management.internal.cli.multistep.CLIMultiStepHelper.execCLISteps(CLIMultiStepHelper.java:66)
> at
> com.gemstone.gemfire.management.internal.cli.shell.GfshExecutionStrategy.execute(GfshExecutionStrategy.java:82)
> at
> org.springframework.shell.core.AbstractShell.executeCommand(AbstractShell.java:223)
> at
> com.gemstone.gemfire.management.internal.cli.shell.Gfsh.executeCommand(Gfsh.java:414)
> at
> com.gemstone.gemfire.management.internal.cli.shell.Gfsh.promptLoop(Gfsh.java:863)
> at org.springframework.shell.core.JLineShell.run(JLineShell.java:158)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> Debugging in {{ClientHttpRequest}} shows the {{queryParams}} include a
> {{vf.gf.env.stepArgs}} entry containing {{startCount}}, but there is not an
> entry for {{startCount}} itself:
> {noformat}
> [severe 2016/05/20 17:01:03.694 PDT Gfsh Launcher tid=0xc] (msgTID=12
> msgSN=66) XXX ClientHttpRequest getURL queryParams: {interactive=[true],
> step-name=[SELECT_PAGE_MOVE], query=["SELECT id, cusip FROM /data"],
> vf.gf.env.APP_COLLECTION_LIMIT=[20], vf.gf.env.APP_FETCH_SIZE=[1000],
> vf.gf.env.APP_LAST_EXIT_STATUS=[0], vf.gf.env.APP_LOGGING_ENABLED=[true],
> vf.gf.env.APP_LOG_FILE=[/Users/boglesby/Dev/Tests/client-server/basic/8x/pdx/gfsh/gfsh-%u_%g.log],
> vf.gf.env.APP_NAME=[gfsh],
> vf.gf.env.APP_PWD=[/Users/boglesby/Dev/Tests/client-server/basic/8x/pdx],
> vf.gf.env.APP_QUERY_RESULTS_DISPLAY_MODE=[table],
> vf.gf.env.APP_QUIET_EXECUTION=[false], vf.gf.env.APP_RESULT_VIEWER=[basic],
> vf.gf.env.stepArgs=[{"startCount":20,"endCount":40}]}
> {noformat}
> A different but similar exception occurs in the 'q' case. If 'q' is selected,
> then the next query execution (or actually any command) produces this message:
> {noformat}
> Press n to move to next page, q to quit and p to previous page : q
> NEXT_STEP_NAME : END
> gfsh>query --query="S
[jira] [Commented] (GEODE-1185) typo in gfsh help on alter disk-store
[ https://issues.apache.org/jira/browse/GEODE-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319385#comment-15319385 ] ASF subversion and git services commented on GEODE-1185: Commit 557fae159707d00d7e7ea2cab9c629dca6d26baf in incubator-geode's branch refs/heads/feature/GEODE-837 from [~jens.deppe] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=557fae1 ] GEODE-1185: typo in gfsh help on alter disk-store > typo in gfsh help on alter disk-store > - > > Key: GEODE-1185 > URL: https://issues.apache.org/jira/browse/GEODE-1185 > Project: Geode > Issue Type: Bug > Components: docs, gfsh >Reporter: Darrel Schneider >Assignee: Jens Deppe > Fix For: 1.0.0-incubating.M3 > > > In the gfsh help for alter disk-store "algorthm" should be changed to > "algorithm". The "i" is missing. > CliStrings.java: public static final String > ALTER_DISK_STORE__LRU__EVICTION__ALGORITHM = "lru-algorthm"; > Also this test has the wrong spelling: > CommandHelpText.java:+ " alter disk-store --name=value > --region=value --disk-dirs=value(,value)* [--lru-algorthm=value]\n" > closed/gemfire-CommandHelpText.java:+ " lru-algorthm\n" -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1463) Legacy OperationContexts do not set the appropriate Shiro permission tuple
[ https://issues.apache.org/jira/browse/GEODE-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319386#comment-15319386 ] ASF subversion and git services commented on GEODE-1463: Commit 670fae4b3950fa1ce302461312dd1251d8ea2d8a in incubator-geode's branch refs/heads/feature/GEODE-837 from [~jens.deppe] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=670fae4 ] GEODE-1463: Legacy OperationContexts do not set the appropriate Shiro permission tuple - Moved ResourceOperationContext into a 'public' package. - Converted OperationContext into an interface. - Cleaned up the hierarchy of everything that previously extended OperationContext. - Marked GetOperationContext as abstract seeing that GetOperationContextImpl extends it and there are no uses of GetOperationContext anywhere. (So why does it still exist?). > Legacy OperationContexts do not set the appropriate Shiro permission tuple > -- > > Key: GEODE-1463 > URL: https://issues.apache.org/jira/browse/GEODE-1463 > Project: Geode > Issue Type: Bug > Components: security >Reporter: Jens Deppe >Assignee: Jens Deppe > > Also need to move ResourceOperationContext out of 'internal' as it is a > user-visible class. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-68) GFSH SYS_HOST_NAME variable should report hostname if available
[
https://issues.apache.org/jira/browse/GEODE-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319337#comment-15319337
]
ASF GitHub Bot commented on GEODE-68:
-
Github user bschuchardt commented on a diff in the pull request:
https://github.com/apache/incubator-geode/pull/152#discussion_r66147139
--- Diff:
geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/shell/Gfsh.java
---
@@ -279,7 +281,12 @@ protected Gfsh(boolean launchShell, String[] args,
GfshConfig gfshConfig) throws
private void initializeEnvironment() {
env.put(ENV_SYS_USER, System.getProperty("user.name"));
env.put(ENV_SYS_USER_HOME, System.getProperty("user.home"));
-env.put(ENV_SYS_HOST_NAME, System.getProperty("user.name"));
+try {
+ env.put(ENV_SYS_HOST_NAME,
InetAddress.getLocalHost().getHostName());
--- End diff --
Use SocketCreator.getLocalHost() and SocketCreator.getHostName().
SocketCreator caches host names to avoid going to DNS when the host name is
already known.
> GFSH SYS_HOST_NAME variable should report hostname if available
> ---
>
> Key: GEODE-68
> URL: https://issues.apache.org/jira/browse/GEODE-68
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: William Markito Oliveira
>Assignee: Kevin Duling
>Priority: Minor
> Labels: gfsh
>
> SYS_HOST_NAME is actually displaying SYS_USER_HOME.
> This is very useful for automation scripts.
> {code}
> gfsh>echo --string=$*
>Property| Value
> -- |
> --
> APP_COLLECTION_LIMIT | 20
> APP_FETCH_SIZE | 1000
> APP_LAST_EXIT_STATUS | 0
> APP_LOGGING_ENABLED| false
> APP_LOG_FILE | /Users/wmarkito/gfsh-%u_%g.log
> APP_NAME | gfsh
> APP_PWD| /Users/wmarkito
> APP_QUERY_RESULTS_DISPLAY_MODE | table
> APP_QUIET_EXECUTION| false
> APP_RESULT_VIEWER | basic
> SYS_CLASSPATH |
> /Users/wmarkito/Pivotal/GemFire/sources/github/gemfire/build-artifacts/mac/product/lib/gfsh-dependencies.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home/lib/tools.jar
> SYS_GEMFIRE_DIR| /Users/wmarkito/...
> SYS_HOST_NAME | wmarkito
> SYS_JAVA_VERSION | 1.7.0_72
> SYS_OS | Mac OS X
> SYS_OS_LINE_SEPARATOR |
> SYS_USER | wmarkito
> SYS_USER_HOME | /Users/wmarkito
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-68) GFSH SYS_HOST_NAME variable should report hostname if available
[
https://issues.apache.org/jira/browse/GEODE-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319323#comment-15319323
]
ASF GitHub Bot commented on GEODE-68:
-
Github user metatype commented on a diff in the pull request:
https://github.com/apache/incubator-geode/pull/152#discussion_r66146482
--- Diff:
geode-core/src/main/java/com/gemstone/gemfire/management/internal/cli/shell/Gfsh.java
---
@@ -279,7 +281,12 @@ protected Gfsh(boolean launchShell, String[] args,
GfshConfig gfshConfig) throws
private void initializeEnvironment() {
env.put(ENV_SYS_USER, System.getProperty("user.name"));
env.put(ENV_SYS_USER_HOME, System.getProperty("user.home"));
-env.put(ENV_SYS_HOST_NAME, System.getProperty("user.name"));
+try {
+ env.put(ENV_SYS_HOST_NAME,
InetAddress.getLocalHost().getHostName());
--- End diff --
@bschuchardt Do we have utility code for doing hostname lookup? Do you see
any problems with timeouts or DNS failures here?
> GFSH SYS_HOST_NAME variable should report hostname if available
> ---
>
> Key: GEODE-68
> URL: https://issues.apache.org/jira/browse/GEODE-68
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: William Markito Oliveira
>Assignee: Kevin Duling
>Priority: Minor
> Labels: gfsh
>
> SYS_HOST_NAME is actually displaying SYS_USER_HOME.
> This is very useful for automation scripts.
> {code}
> gfsh>echo --string=$*
>Property| Value
> -- |
> --
> APP_COLLECTION_LIMIT | 20
> APP_FETCH_SIZE | 1000
> APP_LAST_EXIT_STATUS | 0
> APP_LOGGING_ENABLED| false
> APP_LOG_FILE | /Users/wmarkito/gfsh-%u_%g.log
> APP_NAME | gfsh
> APP_PWD| /Users/wmarkito
> APP_QUERY_RESULTS_DISPLAY_MODE | table
> APP_QUIET_EXECUTION| false
> APP_RESULT_VIEWER | basic
> SYS_CLASSPATH |
> /Users/wmarkito/Pivotal/GemFire/sources/github/gemfire/build-artifacts/mac/product/lib/gfsh-dependencies.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home/lib/tools.jar
> SYS_GEMFIRE_DIR| /Users/wmarkito/...
> SYS_HOST_NAME | wmarkito
> SYS_JAVA_VERSION | 1.7.0_72
> SYS_OS | Mac OS X
> SYS_OS_LINE_SEPARATOR |
> SYS_USER | wmarkito
> SYS_USER_HOME | /Users/wmarkito
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-68) GFSH SYS_HOST_NAME variable should report hostname if available
[
https://issues.apache.org/jira/browse/GEODE-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319275#comment-15319275
]
ASF GitHub Bot commented on GEODE-68:
-
GitHub user kjduling opened a pull request:
https://github.com/apache/incubator-geode/pull/152
GEODE-68: GFSH SYS_HOST_NAME variable should report hostname if avail…
Populate the SYS_HOST_NAME variable with the system host name if possible.
Otherwise, set it to localhost.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/kjduling/incubator-geode feature/GEODE-68
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-geode/pull/152.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #152
commit 32b75112ff51e6dda35635f82bdcf47a6afdaee8
Author: Kevin J. Duling
Date: 2016-06-07T20:06:58Z
GEODE-68: GFSH SYS_HOST_NAME variable should report hostname if available
> GFSH SYS_HOST_NAME variable should report hostname if available
> ---
>
> Key: GEODE-68
> URL: https://issues.apache.org/jira/browse/GEODE-68
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: William Markito Oliveira
>Assignee: Kevin Duling
>Priority: Minor
> Labels: gfsh
>
> SYS_HOST_NAME is actually displaying SYS_USER_HOME.
> This is very useful for automation scripts.
> {code}
> gfsh>echo --string=$*
>Property| Value
> -- |
> --
> APP_COLLECTION_LIMIT | 20
> APP_FETCH_SIZE | 1000
> APP_LAST_EXIT_STATUS | 0
> APP_LOGGING_ENABLED| false
> APP_LOG_FILE | /Users/wmarkito/gfsh-%u_%g.log
> APP_NAME | gfsh
> APP_PWD| /Users/wmarkito
> APP_QUERY_RESULTS_DISPLAY_MODE | table
> APP_QUIET_EXECUTION| false
> APP_RESULT_VIEWER | basic
> SYS_CLASSPATH |
> /Users/wmarkito/Pivotal/GemFire/sources/github/gemfire/build-artifacts/mac/product/lib/gfsh-dependencies.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home/lib/tools.jar
> SYS_GEMFIRE_DIR| /Users/wmarkito/...
> SYS_HOST_NAME | wmarkito
> SYS_JAVA_VERSION | 1.7.0_72
> SYS_OS | Mac OS X
> SYS_OS_LINE_SEPARATOR |
> SYS_USER | wmarkito
> SYS_USER_HOME | /Users/wmarkito
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (GEODE-68) GFSH SYS_HOST_NAME variable should report hostname if available
[
https://issues.apache.org/jira/browse/GEODE-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Duling updated GEODE-68:
--
Summary: GFSH SYS_HOST_NAME variable should report hostname if available
(was: GFSH SYS_HOST_NAME variable have value)
> GFSH SYS_HOST_NAME variable should report hostname if available
> ---
>
> Key: GEODE-68
> URL: https://issues.apache.org/jira/browse/GEODE-68
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: William Markito Oliveira
>Assignee: Kevin Duling
>Priority: Minor
> Labels: gfsh
>
> SYS_HOST_NAME is actually displaying SYS_USER_HOME.
> This is very useful for automation scripts.
> {code}
> gfsh>echo --string=$*
>Property| Value
> -- |
> --
> APP_COLLECTION_LIMIT | 20
> APP_FETCH_SIZE | 1000
> APP_LAST_EXIT_STATUS | 0
> APP_LOGGING_ENABLED| false
> APP_LOG_FILE | /Users/wmarkito/gfsh-%u_%g.log
> APP_NAME | gfsh
> APP_PWD| /Users/wmarkito
> APP_QUERY_RESULTS_DISPLAY_MODE | table
> APP_QUIET_EXECUTION| false
> APP_RESULT_VIEWER | basic
> SYS_CLASSPATH |
> /Users/wmarkito/Pivotal/GemFire/sources/github/gemfire/build-artifacts/mac/product/lib/gfsh-dependencies.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home/lib/tools.jar
> SYS_GEMFIRE_DIR| /Users/wmarkito/...
> SYS_HOST_NAME | wmarkito
> SYS_JAVA_VERSION | 1.7.0_72
> SYS_OS | Mac OS X
> SYS_OS_LINE_SEPARATOR |
> SYS_USER | wmarkito
> SYS_USER_HOME | /Users/wmarkito
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (GEODE-68) GFSH SYS_HOST_NAME variable have value
[
https://issues.apache.org/jira/browse/GEODE-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Duling reassigned GEODE-68:
-
Assignee: Kevin Duling (was: Tushar Khairnar)
> GFSH SYS_HOST_NAME variable have value
> --
>
> Key: GEODE-68
> URL: https://issues.apache.org/jira/browse/GEODE-68
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: William Markito Oliveira
>Assignee: Kevin Duling
>Priority: Minor
> Labels: gfsh
>
> SYS_HOST_NAME is actually displaying SYS_USER_HOME.
> This is very useful for automation scripts.
> {code}
> gfsh>echo --string=$*
>Property| Value
> -- |
> --
> APP_COLLECTION_LIMIT | 20
> APP_FETCH_SIZE | 1000
> APP_LAST_EXIT_STATUS | 0
> APP_LOGGING_ENABLED| false
> APP_LOG_FILE | /Users/wmarkito/gfsh-%u_%g.log
> APP_NAME | gfsh
> APP_PWD| /Users/wmarkito
> APP_QUERY_RESULTS_DISPLAY_MODE | table
> APP_QUIET_EXECUTION| false
> APP_RESULT_VIEWER | basic
> SYS_CLASSPATH |
> /Users/wmarkito/Pivotal/GemFire/sources/github/gemfire/build-artifacts/mac/product/lib/gfsh-dependencies.jar:/Library/Java/JavaVirtualMachines/jdk1.7.0_71.jdk/Contents/Home/lib/tools.jar
> SYS_GEMFIRE_DIR| /Users/wmarkito/...
> SYS_HOST_NAME | wmarkito
> SYS_JAVA_VERSION | 1.7.0_72
> SYS_OS | Mac OS X
> SYS_OS_LINE_SEPARATOR |
> SYS_USER | wmarkito
> SYS_USER_HOME | /Users/wmarkito
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-744) Incorrect use of APP_FETCH_SIZE in GFSH
[
https://issues.apache.org/jira/browse/GEODE-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319191#comment-15319191
]
ASF GitHub Bot commented on GEODE-744:
--
GitHub user kjduling opened a pull request:
https://github.com/apache/incubator-geode/pull/151
GEODE-744: Incorrect use of APP_FETCH_SIZE in GFSH
Changed the test to be case-insensitive.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/kjduling/incubator-geode feature/GEODE-744
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-geode/pull/151.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #151
commit c02dd1c1f2d176b5ce6316516278a064d8b2afaa
Author: Kevin J. Duling
Date: 2016-06-07T19:29:19Z
GEODE-744: Incorrect use of APP_FETCH_SIZE in GFSH
> Incorrect use of APP_FETCH_SIZE in GFSH
> ---
>
> Key: GEODE-744
> URL: https://issues.apache.org/jira/browse/GEODE-744
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Kevin Duling
> Attachments: workspace (1).zip
>
>
> A customer is facing an easily reproducible issue when executing queries from
> GFSH. It appears that the APP_FETCH_SIZE is being set only when parts of the
> query are in lower case. It happens in 7.0.X, 8.0.X and 8.1.X.
> Attached to the TRAC is the reproducible scenario, steps to reproduce:
> Uncompress the file.
> Modify variables "GEMFIRE" and "JAVA_HOME" in file setenv.txt.
> Execute "./start_cluster.sh".
> Exceute "./run.sh". This script inserts 1500 entries in the region and,
> afterwards, executes two queries, one using lower case and other using upper
> case. You can see from the console that ouput is different, one returns the
> actual size (1500) and the other one returns the default APP_FETCH_SIZE
> (1000).
> Exceute "./stop_cluster.sh".
> The fix seems pretty easy to implement, the method "addLimit" of the inner
> class "SelectExecStep?" in "DataCommandFunction?" class should be modified to
> compare strings without using the actual word case. Is not enough to add more
> "or" to the comparison like we are currently doing with since keywords like
> "Count" or "coUn" will still break the functionallity. We should compare
> everything using lower case or upper case, it doesn't matter which one, or at
> least make sure that gfsh converts the query to upper/lower case before
> actually executing them.
> The actual code with the problem is below:
> {noformat}
> private String addLimit(String query) {
> boolean containsLimitOrAggregate = query.contains(" limit")
> query.contains(" LIMIT") query.contains("count(*)");
> if (!containsLimitOrAggregate){
> String limitQuery = query + " limit " + getFetchSize();
> return limitQuery;
> } else {
> return query;
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (GEODE-744) Incorrect use of APP_FETCH_SIZE in GFSH
[
https://issues.apache.org/jira/browse/GEODE-744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Duling reassigned GEODE-744:
--
Assignee: Kevin Duling
> Incorrect use of APP_FETCH_SIZE in GFSH
> ---
>
> Key: GEODE-744
> URL: https://issues.apache.org/jira/browse/GEODE-744
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Kevin Duling
> Attachments: workspace (1).zip
>
>
> A customer is facing an easily reproducible issue when executing queries from
> GFSH. It appears that the APP_FETCH_SIZE is being set only when parts of the
> query are in lower case. It happens in 7.0.X, 8.0.X and 8.1.X.
> Attached to the TRAC is the reproducible scenario, steps to reproduce:
> Uncompress the file.
> Modify variables "GEMFIRE" and "JAVA_HOME" in file setenv.txt.
> Execute "./start_cluster.sh".
> Exceute "./run.sh". This script inserts 1500 entries in the region and,
> afterwards, executes two queries, one using lower case and other using upper
> case. You can see from the console that ouput is different, one returns the
> actual size (1500) and the other one returns the default APP_FETCH_SIZE
> (1000).
> Exceute "./stop_cluster.sh".
> The fix seems pretty easy to implement, the method "addLimit" of the inner
> class "SelectExecStep?" in "DataCommandFunction?" class should be modified to
> compare strings without using the actual word case. Is not enough to add more
> "or" to the comparison like we are currently doing with since keywords like
> "Count" or "coUn" will still break the functionallity. We should compare
> everything using lower case or upper case, it doesn't matter which one, or at
> least make sure that gfsh converts the query to upper/lower case before
> actually executing them.
> The actual code with the problem is below:
> {noformat}
> private String addLimit(String query) {
> boolean containsLimitOrAggregate = query.contains(" limit")
> query.contains(" LIMIT") query.contains("count(*)");
> if (!containsLimitOrAggregate){
> String limitQuery = query + " limit " + getFetchSize();
> return limitQuery;
> } else {
> return query;
> }
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-308) Separate hydra from dunit and junit tests in gemfire-core
[ https://issues.apache.org/jira/browse/GEODE-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319142#comment-15319142 ] ASF subversion and git services commented on GEODE-308: --- Commit fb719d0a1a5d2a33045c210807b4b4b5c1d80afe in incubator-geode's branch refs/heads/feature/GEODE-1372 from [~kduling] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=fb719d0 ] GEODE-308: Separate hydra from dunit and junit tests in gemfire-core Removed hydra classes. Merge branch 'feature/GEODE-308' of https://github.com/kjduling/incubator-geode into pull > Separate hydra from dunit and junit tests in gemfire-core > - > > Key: GEODE-308 > URL: https://issues.apache.org/jira/browse/GEODE-308 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.0.0-incubating >Reporter: Kirk Lund > Labels: hydra > > Usage of Hydra needs to be removed from dunit and junit tests in gemfire-core > and any other project. > The following hydra classes in gemfire-core should be removed (and replaced > if needed by dunit/junit tests): > src/test/java/hydra/GsRandom.java > src/test/java/hydra/HydraRuntimeException.java > src/test/java/hydra/Log.java > src/test/java/hydra/LogVersionHelper.java > src/test/java/hydra/MethExecutor.java > src/test/java/hydra/MethExecutorResult.java > src/test/java/hydra/SchedulingOrder.java > src/test/java/hydra/log/AnyLogWriter.java > src/test/java/hydra/log/CircularOutputStream.java > The following are also not com.gemstone packages and should be removed if > they're specific to Hydra (or Hydra tests) or repackaged if they're actually > used in dunit/junit tests: > src/test/java/batterytest/greplogs/ExpectedStrings.java > src/test/java/batterytest/greplogs/LogConsumer.java > src/test/java/cacheRunner/Portfolio.java > src/test/java/cacheRunner/Position.java > src/test/java/parReg/query/unittest/NewPortfolio.java > src/test/java/parReg/query/unittest/Position.java > src/test/java/perffmwk/Formatter.java > src/test/java/templates/security/DummyAuthenticator.java > src/test/java/templates/security/DummyAuthorization.java > src/test/java/templates/security/FunctionSecurityPrmsHolder.java > src/test/java/templates/security/LdapUserAuthenticator.java > src/test/java/templates/security/PKCSAuthenticator.java > src/test/java/templates/security/PKCSAuthInt.java > src/test/java/templates/security/PKCSPrincipal.java > src/test/java/templates/security/UsernamePrincipal.java > src/test/java/templates.security/UserPasswordAuthInit.java > src/test/java/templates.security/XmlAuthorization.java > src/test/java/templates.security/XmlErrorHandler.java > src/test/java/util/TestException.java > The following are Hydra-related resources in src/test/resources that also > need to be removed: > src/test/resources/jta/cachejta.xml > src/test/resources/ssl/trusted.keystore > src/test/resources/templates/security/authz5_5.dtd > src/test/resources/templates/security/authz6_0.dtd -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1471) GatewayEventFilter callbacks are not invoked when an AsyncEventQueues is configured using xml
[
https://issues.apache.org/jira/browse/GEODE-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319145#comment-15319145
]
ASF subversion and git services commented on GEODE-1471:
Commit 001a4e167d287e66a944edf45ac9591b09104954 in incubator-geode's branch
refs/heads/feature/GEODE-1372 from [~barry.oglesby]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=001a4e1 ]
GEODE-1471: GatewayEventFilter callbacks are now invoked on AsyncEventQueues
> GatewayEventFilter callbacks are not invoked when an AsyncEventQueues is
> configured using xml
> -
>
> Key: GEODE-1471
> URL: https://issues.apache.org/jira/browse/GEODE-1471
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Barry Oglesby
>Assignee: Barry Oglesby
>
> None of the {{GatewayEventFilter}} callbacks are invoked when configuring
> {{AsyncEventQueues}} using xml.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-308) Separate hydra from dunit and junit tests in gemfire-core
[ https://issues.apache.org/jira/browse/GEODE-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319141#comment-15319141 ] ASF subversion and git services commented on GEODE-308: --- Commit fb719d0a1a5d2a33045c210807b4b4b5c1d80afe in incubator-geode's branch refs/heads/feature/GEODE-1372 from [~kduling] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=fb719d0 ] GEODE-308: Separate hydra from dunit and junit tests in gemfire-core Removed hydra classes. Merge branch 'feature/GEODE-308' of https://github.com/kjduling/incubator-geode into pull > Separate hydra from dunit and junit tests in gemfire-core > - > > Key: GEODE-308 > URL: https://issues.apache.org/jira/browse/GEODE-308 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.0.0-incubating >Reporter: Kirk Lund > Labels: hydra > > Usage of Hydra needs to be removed from dunit and junit tests in gemfire-core > and any other project. > The following hydra classes in gemfire-core should be removed (and replaced > if needed by dunit/junit tests): > src/test/java/hydra/GsRandom.java > src/test/java/hydra/HydraRuntimeException.java > src/test/java/hydra/Log.java > src/test/java/hydra/LogVersionHelper.java > src/test/java/hydra/MethExecutor.java > src/test/java/hydra/MethExecutorResult.java > src/test/java/hydra/SchedulingOrder.java > src/test/java/hydra/log/AnyLogWriter.java > src/test/java/hydra/log/CircularOutputStream.java > The following are also not com.gemstone packages and should be removed if > they're specific to Hydra (or Hydra tests) or repackaged if they're actually > used in dunit/junit tests: > src/test/java/batterytest/greplogs/ExpectedStrings.java > src/test/java/batterytest/greplogs/LogConsumer.java > src/test/java/cacheRunner/Portfolio.java > src/test/java/cacheRunner/Position.java > src/test/java/parReg/query/unittest/NewPortfolio.java > src/test/java/parReg/query/unittest/Position.java > src/test/java/perffmwk/Formatter.java > src/test/java/templates/security/DummyAuthenticator.java > src/test/java/templates/security/DummyAuthorization.java > src/test/java/templates/security/FunctionSecurityPrmsHolder.java > src/test/java/templates/security/LdapUserAuthenticator.java > src/test/java/templates/security/PKCSAuthenticator.java > src/test/java/templates/security/PKCSAuthInt.java > src/test/java/templates/security/PKCSPrincipal.java > src/test/java/templates/security/UsernamePrincipal.java > src/test/java/templates.security/UserPasswordAuthInit.java > src/test/java/templates.security/XmlAuthorization.java > src/test/java/templates.security/XmlErrorHandler.java > src/test/java/util/TestException.java > The following are Hydra-related resources in src/test/resources that also > need to be removed: > src/test/resources/jta/cachejta.xml > src/test/resources/ssl/trusted.keystore > src/test/resources/templates/security/authz5_5.dtd > src/test/resources/templates/security/authz6_0.dtd -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1464) remove sqlfire references from geode-core
[ https://issues.apache.org/jira/browse/GEODE-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319149#comment-15319149 ] ASF subversion and git services commented on GEODE-1464: Commit 103a6bcdf9932dfe0ed5c34c71d942db0e2e02e1 in incubator-geode's branch refs/heads/feature/GEODE-1372 from [~dschneider] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=103a6bc ] GEODE-1464: fix AnalyzeSerializablesJUnitTest > remove sqlfire references from geode-core > - > > Key: GEODE-1464 > URL: https://issues.apache.org/jira/browse/GEODE-1464 > Project: Geode > Issue Type: Task > Components: regions >Reporter: Darrel Schneider >Assignee: Darrel Schneider > Fix For: 1.0.0-incubating.M3 > > > Currently the geode-core has 307 lines that reference "sqlf". This should all > be dead code that can be cleaned up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1491) A rollback command could fail with IllegalStateException if the client failed over and the transaction has been rolled back.
[
https://issues.apache.org/jira/browse/GEODE-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319146#comment-15319146
]
ASF subversion and git services commented on GEODE-1491:
Commit 0815e1b6e9f11881b03780ac730856ee5db36c9c in incubator-geode's branch
refs/heads/feature/GEODE-1372 from [~eshu]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=0815e1b ]
GEODE-1491: Make sure when checking if a transaction is completed from
isHostedTxRecentlyCompleted() method, the rolled back transaction is considered
as well.
> A rollback command could fail with IllegalStateException if the client failed
> over and the transaction has been rolled back.
>
>
> Key: GEODE-1491
> URL: https://issues.apache.org/jira/browse/GEODE-1491
> Project: Geode
> Issue Type: Bug
> Components: transactions
>Reporter: Eric Shu
>
> {noformat}
> The TXManagerImpl rollback() method executes the followings.
> setTXState(null);
> tx.rollback();
> saveTXStateForClientFailover(tx);
> cleanup(tx.getTransactionId());
> noteRollbackSuccess(opStart, lifeTime, tx);
> In saveTXStateForClientFailover(), the txid is put into failovermap for
> failover operation. However as it is a rollback, tx.getCommitMessage()
> returns null.
> private void saveTXStateForClientFailover(TXStateProxy tx) {
> if (tx.isOnBehalfOfClient() && tx.isRealDealLocal()) {
> failoverMap.put(tx.getTxId(), tx.getCommitMessage());
> if (logger.isDebugEnabled()) {
> logger.debug("TX: storing client initiated transaction:{}; now there
> are {} entries in the failoverMap",
> tx.getTxId(), failoverMap.size());
> }
> }
> }
> If the proxyserver send the rollback message to the host server, but the
> client then failover to another proxy. The retry of rollback checks to see if
> the transaction is completed, before retries the rollback operation.
> @Override
> protected boolean operateOnTx(TXId txId,DistributionManager dm) {
> GemFireCacheImpl cache = GemFireCacheImpl.getInstance();
> if (cache == null) {
> throw new
> CacheClosedException(LocalizedStrings.CacheFactory_A_CACHE_HAS_NOT_YET_BEEN_CREATED.toLocalizedString());
> }
> TXManagerImpl txMgr = cache.getTXMgr();
> if (logger.isDebugEnabled()) {
> logger.debug("TX: Rolling back :{}", txId);
> }
> try {
> if (!txMgr.isHostedTxRecentlyCompleted(txId)) {
> txMgr.rollback();
> }
> } finally {
> txMgr.removeHostedTXState(txId);
> }
> return true;
> }
> The isHostedTxRecentlyCompleted() only checks if the transaction completed
> with a commit message.
> public boolean isHostedTxRecentlyCompleted(TXId txId) {
> TXCommitMessage msg = failoverMap.remove(txId);
> if (msg != null) {
> failoverMap.put(txId, msg);
> return true;
> }
> return false;
> }
> This could leads to a rollback command from a client failed with
> IllegalStateException: Thread does not have an active transaction
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (GEODE-1498) CI Failure: DurableClientCommandsDUnitTest.testCloseDurableClients
[ https://issues.apache.org/jira/browse/GEODE-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319147#comment-15319147 ] ASF subversion and git services commented on GEODE-1498: Commit 6967ac19f2a53cf4c71b69ae06ff8fb39003de4f in incubator-geode's branch refs/heads/feature/GEODE-1372 from [~jchen21] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=6967ac1 ] GEODE-1498 CI Failure: DurableClientCommandsDUnitTest.testCloseDurableClients Use port 0 for cache server and return a random available port for durable client. > CI Failure: DurableClientCommandsDUnitTest.testCloseDurableClients > -- > > Key: GEODE-1498 > URL: https://issues.apache.org/jira/browse/GEODE-1498 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Jason Huynh >Assignee: Jianxia Chen > Labels: ci > Fix For: 1.0.0-incubating.M3 > > > Failed with the following: > com.gemstone.gemfire.test.dunit.RMIException: While invoking > com.gemstone.gemfire.management.internal.cli.commands.DurableClientCommandsDUnitTest$3.call > in VM 1 running on Host cc2-ub.gemstone.com with 4 VMs > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:389) > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:355) > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:320) > at > com.gemstone.gemfire.management.internal.cli.commands.DurableClientCommandsDUnitTest.startCacheServer(DurableClientCommandsDUnitTest.java:309) > at > com.gemstone.gemfire.management.internal.cli.commands.DurableClientCommandsDUnitTest.setupSystem(DurableClientCommandsDUnitTest.java:249) > at > com.gemstone.gemfire.management.internal.cli.commands.DurableClientCommandsDUnitTest.testCloseDurableClients(DurableClientCommandsDUnitTest.java:95) > 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 > 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.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:112) > 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:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.GeneratedMethodAccessor273.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(ContextClassLoad
[jira] [Commented] (GEODE-11) Lucene Integration
[ https://issues.apache.org/jira/browse/GEODE-11?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319144#comment-15319144 ] ASF subversion and git services commented on GEODE-11: -- Commit c742c4e54c0b3ab16ce7845e2534e746cefbbce1 in incubator-geode's branch refs/heads/feature/GEODE-1372 from [~barry.oglesby] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=c742c4e ] GEODE-11: Added support for lucene index profile exchange > Lucene Integration > -- > > Key: GEODE-11 > URL: https://issues.apache.org/jira/browse/GEODE-11 > Project: Geode > Issue Type: New Feature > Components: querying >Reporter: Dan Smith >Assignee: xiaojian zhou > > This is a feature that has been under development for GemFire but was not > part of the initial drop of code for geode. > Allow Lucene indexes to be stored in Geode regions allowing users to do text > searches on data stored in Geode. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1464) remove sqlfire references from geode-core
[ https://issues.apache.org/jira/browse/GEODE-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319148#comment-15319148 ] ASF subversion and git services commented on GEODE-1464: Commit 880f86483f6b75775f34e6821046ba18deb933f0 in incubator-geode's branch refs/heads/feature/GEODE-1372 from [~dschneider] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=880f864 ] GEODE-1464: remove sqlf code > remove sqlfire references from geode-core > - > > Key: GEODE-1464 > URL: https://issues.apache.org/jira/browse/GEODE-1464 > Project: Geode > Issue Type: Task > Components: regions >Reporter: Darrel Schneider >Assignee: Darrel Schneider > Fix For: 1.0.0-incubating.M3 > > > Currently the geode-core has 307 lines that reference "sqlf". This should all > be dead code that can be cleaned up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1372) Geode UDP communications are not secure when SSL is configured
[ https://issues.apache.org/jira/browse/GEODE-1372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319150#comment-15319150 ] ASF subversion and git services commented on GEODE-1372: Commit ba436185945a293dd38321929ebeaae06506e98c in incubator-geode's branch refs/heads/feature/GEODE-1372 from [~hitesh.khamesra] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=ba43618 ] Merge branch 'GEODE-1372' into develop > Geode UDP communications are not secure when SSL is configured > -- > > Key: GEODE-1372 > URL: https://issues.apache.org/jira/browse/GEODE-1372 > Project: Geode > Issue Type: New Feature > Components: membership >Reporter: Bruce Schuchardt >Assignee: Hitesh Khamesra > > Gemfire servers use UDP requests to communicate membership views, suspect > processing and other information. When gemfire SSL is enabled, only the TCP > requests are encrypted and UDP requests are not. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1331) gfsh.bat on Windows is incorrect
[
https://issues.apache.org/jira/browse/GEODE-1331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15319143#comment-15319143
]
ASF subversion and git services commented on GEODE-1331:
Commit 8e21638ce336aee07bec33d140500c76d1cedc53 in incubator-geode's branch
refs/heads/feature/GEODE-1372 from [~kduling]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=8e21638 ]
GEODE-1331: gfsh.bat on Windows is incorrect.
* Renamed internal variable from CLASSPATH to DEPENDENCIES.
* Verified @setlocal was not altering the System environment variables for the
shell.
* Launch with -classpath param like the bash script does.
* Ensured command-line arguments match bash script's order of arguments.
* This closes #149
> gfsh.bat on Windows is incorrect
>
>
> Key: GEODE-1331
> URL: https://issues.apache.org/jira/browse/GEODE-1331
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Reporter: Jens Deppe
>Assignee: Kevin Duling
> Fix For: 1.0.0-incubating.M3
>
>
> Initial report:
> {noformat}
> I am doing testing in windows STS. I am not adding these dependencies jars,
> gfsh.bat is what doing this.
>
> C:\DEV\Pivotal\GemFire_v82014\bin\gfsh.bat has below code, which is setting
> gemfire, antlr, gfsh-dependencies and pulse-dependencies jars in classpath.
> Line 26 to 29
> @set
> GEMFIRE_JARS=%GEMFIRE%\lib\gemfire.jar;%GEMFIRE%\lib\antlr.jar;%GEMFIRE%\lib\gfsh-dependencies.jar;%GEMFIRE%\lib\pulse-dependencies.jar
> @if defined CLASSPATH (
> @set GEMFIRE_JARS=%GEMFIRE_JARS%;%CLASSPATH%
> )
> C:\DEV\Pivotal\GemFire_v82014\lib\gemfire.jar // DUPLICATE
> C:\DEV\Pivotal\GemFire_v82014\lib\antlr.jar
> C:\DEV\Pivotal\GemFire_v82014\lib\gfsh-dependencies.jar // DUPLICATE
> C:\DEV\Pivotal\GemFire_v82014\lib\pulse-dependencies.jar
>
> Unix C:\DEV\Pivotal\GemFire_v82014\bin script, does not set these jars in
> classpath.
>
>
> Another observation is that, if I pass --include-system-classpath to gfsh
> start server command, then it is prepending
> gemfire.jar and gfsh-dependencies.jar to the system classpath and adding that
> to the server, that is what is shown in logs
> Class Path:
> C:\DEV\Pivotal\GemFire_v82014\lib\gemfire.jar
> C:\DEV\Pivotal\GemFire_v82014\lib\gfsh-dependencies.jar
>
> ………..
> C:\Program Files\Java\jdk1.7.0_67\lib\tools.jar
> C:\DEV\Pivotal\GemFire_v82014\lib\server-dependencies.jar
>
> start server \
> --name=${NAME} --server-port=${PORT} \
> --properties-file=${GEMFIRE_PWD}/resources/cache.properties \
> --J=-Dgemfire.distributed-system-id=${DISTRIBUTED_SYSTEM_ID} \
> --J=-Dgemfire.bind-address=${HOST_NAME}
> --J=-Dgemfire.server-bind-address=${HOST_NAME} \
> --J=-Dgemfire.locators=${HOST_NAME}[${LOCATOR_PORT}] \
> --J=-Dgemfire.OSProcess.ENABLE_OUTPUT_REDIRECTION=true \
> --include-system-classpath
>
> If I don’t pass this parameter, then it does not add gfsh-dependencies
> Class Path:
> C:\DEV\Pivotal\GemFire_v82014\lib\gemfire.jar
> C:\DEV\Pivotal\GemFire_v82014\lib\server-dependencies.jar
>
> I am trying to do testing without using –include-system-classpath instead add
> jars in to the start server –classpath as a work around.
> {noformat}
> And a subsequent reply from John Blum:
> {noformat}
> My apologies. I was not aware that you were launching your GemFire process
> (e.g. Server) using Gfsh, and specifically with gfsh.bat on Windows.
> I just confirmed the line(s) you were looking at in gfsh.bat, and indeed the
> BAT file is wrong! Specifically, the classpath for the GemFire process
> is being constructed from the following lines...
> @set
> GEMFIRE_JARS=%GEMFIRE%\lib\gemfire.jar;%GEMFIRE%\lib\antlr.jar;%GEMFIRE%\lib\gfsh-dependencies.jar;%GEMFIRE%\lib\pulse-dependencies.jar
> ...
> @set GFSH_JARS=;%GEMFIRE%\lib\gfsh-dependencies.jar
> @set CLASSPATH=%GFSH_JARS%;%GEMFIRE_JARS%
> The Windows BAT file is also inconsistent with the Bash shell version (gfsh),
> which rightfully only contains...
> GEMFIRE_JARS=$GEMFIRE/lib/gfsh-dependencies.jar
> if [ "x$CLASSPATH" != "x" ]; then
> GEMFIRE_JARS=$GEMFIRE_JARS:$CLASSPATH
> fi
> CLASSPATH=$GEMFIRE_JARS
> In addition, the Bash shell version launches the Gfsh process using the java
> -classpath option...
> "$GF_JAVA" -Dgfsh=true
> -Dlog4j.configurationFile=/com/gemstone/gemfire/internal/logging/log4j/log4j2-cli.xml
> ${JLINE_TERMINAL} -classpath "${CLASSPATH}" $JAVA_ARGS $LAUNCHER "$@"
> Which does not "export", or rather, set the global System CLASSPATH
> environment variable. Here it is only setting the Java System property
> to the Java process, where as, I believe, the Window BAT file is actually
> setting the System CLASSPATH environment variable, since there is no
> java -classpath option present in the command to launch Gfsh...
> @"%GF_JAVA%" -Dgfsh=tr
[jira] [Updated] (GEODE-308) Separate hydra from dunit and junit tests in gemfire-core
[ https://issues.apache.org/jira/browse/GEODE-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kevin Duling updated GEODE-308: --- Assignee: (was: Kevin Duling) > Separate hydra from dunit and junit tests in gemfire-core > - > > Key: GEODE-308 > URL: https://issues.apache.org/jira/browse/GEODE-308 > Project: Geode > Issue Type: Bug > Components: tests >Affects Versions: 1.0.0-incubating >Reporter: Kirk Lund > Labels: hydra > > Usage of Hydra needs to be removed from dunit and junit tests in gemfire-core > and any other project. > The following hydra classes in gemfire-core should be removed (and replaced > if needed by dunit/junit tests): > src/test/java/hydra/GsRandom.java > src/test/java/hydra/HydraRuntimeException.java > src/test/java/hydra/Log.java > src/test/java/hydra/LogVersionHelper.java > src/test/java/hydra/MethExecutor.java > src/test/java/hydra/MethExecutorResult.java > src/test/java/hydra/SchedulingOrder.java > src/test/java/hydra/log/AnyLogWriter.java > src/test/java/hydra/log/CircularOutputStream.java > The following are also not com.gemstone packages and should be removed if > they're specific to Hydra (or Hydra tests) or repackaged if they're actually > used in dunit/junit tests: > src/test/java/batterytest/greplogs/ExpectedStrings.java > src/test/java/batterytest/greplogs/LogConsumer.java > src/test/java/cacheRunner/Portfolio.java > src/test/java/cacheRunner/Position.java > src/test/java/parReg/query/unittest/NewPortfolio.java > src/test/java/parReg/query/unittest/Position.java > src/test/java/perffmwk/Formatter.java > src/test/java/templates/security/DummyAuthenticator.java > src/test/java/templates/security/DummyAuthorization.java > src/test/java/templates/security/FunctionSecurityPrmsHolder.java > src/test/java/templates/security/LdapUserAuthenticator.java > src/test/java/templates/security/PKCSAuthenticator.java > src/test/java/templates/security/PKCSAuthInt.java > src/test/java/templates/security/PKCSPrincipal.java > src/test/java/templates/security/UsernamePrincipal.java > src/test/java/templates.security/UserPasswordAuthInit.java > src/test/java/templates.security/XmlAuthorization.java > src/test/java/templates.security/XmlErrorHandler.java > src/test/java/util/TestException.java > The following are Hydra-related resources in src/test/resources that also > need to be removed: > src/test/resources/jta/cachejta.xml > src/test/resources/ssl/trusted.keystore > src/test/resources/templates/security/authz5_5.dtd > src/test/resources/templates/security/authz6_0.dtd -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (GEODE-1508) client subscription to an off-heap region that has small byte array value fails with IllegalStateException
[ https://issues.apache.org/jira/browse/GEODE-1508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider reassigned GEODE-1508: --- Assignee: Darrel Schneider > client subscription to an off-heap region that has small byte array value > fails with IllegalStateException > -- > > Key: GEODE-1508 > URL: https://issues.apache.org/jira/browse/GEODE-1508 > Project: Geode > Issue Type: Bug > Components: offheap >Reporter: Darrel Schneider >Assignee: Darrel Schneider > > If a client subscribes to an off-heap region that has small byte array value > then the server will fail to push the value to the client. The server log > will contain this exception: java.lang.IllegalStateException: Expected > importNewBytes to be called. > The call stack:at > com.gemstone.gemfire.internal.cache.tier.sockets.ClientUpdateMessageImpl.importNewObject(ClientUpdateMessageImpl.java:1705) > at > com.gemstone.gemfire.internal.cache.EntryEventImpl.exportNewValue(EntryEventImpl.java:1288) > at > com.gemstone.gemfire.internal.cache.tier.sockets.CacheClientNotifier.initializeMessage(CacheClientNotifier.java:1140) > at > com.gemstone.gemfire.internal.cache.tier.sockets.CacheClientNotifier.constructClientMessage(CacheClientNotifier.java:761) > at > com.gemstone.gemfire.internal.cache.tier.sockets.CacheClientNotifier.singletonNotifyClients(CacheClientNotifier.java:824) > at > com.gemstone.gemfire.internal.cache.tier.sockets.CacheClientNotifier.notifyClients(CacheClientNotifier.java:776) > at > com.gemstone.gemfire.internal.cache.LocalRegion.notifyBridgeClients(LocalRegion.java:6496) > at > com.gemstone.gemfire.internal.cache.LocalRegion.invokePutCallbacks(LocalRegion.java:6244) > at > com.gemstone.gemfire.internal.cache.BucketRegion.invokePutCallbacks(BucketRegion.java:1668) > at > com.gemstone.gemfire.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2513) > at > com.gemstone.gemfire.internal.cache.AbstractRegionEntry.dispatchListenerEvents(AbstractRegionEntry.java:144) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (GEODE-1464) remove sqlfire references from geode-core
[ https://issues.apache.org/jira/browse/GEODE-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318879#comment-15318879 ] ASF subversion and git services commented on GEODE-1464: Commit 103a6bcdf9932dfe0ed5c34c71d942db0e2e02e1 in incubator-geode's branch refs/heads/develop from [~dschneider] [ https://git-wip-us.apache.org/repos/asf?p=incubator-geode.git;h=103a6bc ] GEODE-1464: fix AnalyzeSerializablesJUnitTest > remove sqlfire references from geode-core > - > > Key: GEODE-1464 > URL: https://issues.apache.org/jira/browse/GEODE-1464 > Project: Geode > Issue Type: Task > Components: regions >Reporter: Darrel Schneider >Assignee: Darrel Schneider > Fix For: 1.0.0-incubating.M3 > > > Currently the geode-core has 307 lines that reference "sqlf". This should all > be dead code that can be cleaned up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
