[jira] [Assigned] (GEODE-7305) Update some dependecies due to security vulnerabilities
[ https://issues.apache.org/jira/browse/GEODE-7305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo reassigned GEODE-7305: - Assignee: (was: Mario Kevo) > Update some dependecies due to security vulnerabilities > --- > > Key: GEODE-7305 > URL: https://issues.apache.org/jira/browse/GEODE-7305 > Project: Geode > Issue Type: Task > Components: security >Reporter: Mario Kevo >Priority: Major > > After some security vulnerability testing we found some issues. To avoid it > we need to update: > Lucene: 6.6.2 -> *8.2.0* > Jackson-databind: 2.9.8 -> *2.10.0* > Apache Common Beanutils: 1.9.3 -> *1.9.4* > Jetty: 9.4.12.v20180830 -> *9.4.21.v20190926* > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GEODE-7309) Upgrade Lucene from 6.6.2 to 8.2.0
[ https://issues.apache.org/jira/browse/GEODE-7309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo reassigned GEODE-7309: - Assignee: (was: Mario Kevo) > Upgrade Lucene from 6.6.2 to 8.2.0 > -- > > Key: GEODE-7309 > URL: https://issues.apache.org/jira/browse/GEODE-7309 > Project: Geode > Issue Type: Sub-task >Reporter: Mario Kevo >Priority: Major > Labels: pull-request-available > Time Spent: 5.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GEODE-10038) Trying to access the QueryService results in NPE on server restart from deployed Jar
[
https://issues.apache.org/jira/browse/GEODE-10038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo reassigned GEODE-10038:
--
Assignee: (was: Mario Kevo)
> Trying to access the QueryService results in NPE on server restart from
> deployed Jar
>
>
> Key: GEODE-10038
> URL: https://issues.apache.org/jira/browse/GEODE-10038
> Project: Geode
> Issue Type: Bug
> Components: functions
>Affects Versions: 1.12.8, 1.13.7, 1.14.3, 1.15.0
>Reporter: Udo Kohlmeyer
>Priority: Major
>
> After deploying a jar which contains a Function, restarting the server causes
> an NPE.
> Using the Function definition of:
> {code:java}
> public class CustomFunction implements Function {
> private GemFireCache cache;
> private QueryService queryService;
> public CustomFunction() {
> this.cache = CacheFactory.getAnyInstance();
> this.queryService = cache.getQueryService();
> }
> {code}
> Due to the startup flow
> https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1404
> the registration of Functions are initialized from cluster configuration
> [here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1419].
> There is a dependency on the `QueryService` to be available at Function
> construction time, but given that the services are only initialized
> [here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1435],
> the call to the `cache.getQueryService` fails with an NPE
> [here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQueryService.java#L116-L117]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GEODE-9918) Distributed transaction is not a supported feature in geode
[ https://issues.apache.org/jira/browse/GEODE-9918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo reassigned GEODE-9918: - Assignee: (was: Mario Kevo) > Distributed transaction is not a supported feature in geode > --- > > Key: GEODE-9918 > URL: https://issues.apache.org/jira/browse/GEODE-9918 > Project: Geode > Issue Type: Bug > Components: transactions >Reporter: Eric Shu >Priority: Major > Labels: GeodeOperationAPI > > Geode should throw UnsupportedOperationException when > CacheTransactionManager.setDistributed(true) is invoked. As the feature is > currently not supported. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10423) Document the system property “ON_DISCONNECT_CLEAR_PDXTYPEIDS“
[ https://issues.apache.org/jira/browse/GEODE-10423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo updated GEODE-10423: --- Fix Version/s: 1.16.0 (was: 1.15.2) > Document the system property “ON_DISCONNECT_CLEAR_PDXTYPEIDS“ > - > > Key: GEODE-10423 > URL: https://issues.apache.org/jira/browse/GEODE-10423 > Project: Geode > Issue Type: Improvement > Components: docs >Reporter: Tim Zhang >Assignee: Tim Zhang >Priority: Minor > Labels: pull-request-available > Fix For: 1.16.0 > > > Document the java system property “ON_DISCONNECT_CLEAR_PDXTYPEIDS“, this > property is used by Java client. add instructions for using this property. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10420) Handle WAN event when interrupted
[ https://issues.apache.org/jira/browse/GEODE-10420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo updated GEODE-10420: --- Component/s: wan > Handle WAN event when interrupted > - > > Key: GEODE-10420 > URL: https://issues.apache.org/jira/browse/GEODE-10420 > Project: Geode > Issue Type: Bug > Components: wan >Reporter: Alberto Gomez >Assignee: Alberto Gomez >Priority: Major > Labels: needsTriage, pull-request-available > Fix For: 1.15.1, 1.16.0 > > > It is possible that an event of which a gateway sender is to be notified is > lost if during the process the thread is interrupted. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10412) Destroy region command doesn't clear the region related expired tombstones
[
https://issues.apache.org/jira/browse/GEODE-10412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo updated GEODE-10412:
---
Component/s: expiration
> Destroy region command doesn't clear the region related expired tombstones
> --
>
> Key: GEODE-10412
> URL: https://issues.apache.org/jira/browse/GEODE-10412
> Project: Geode
> Issue Type: Bug
> Components: expiration
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.1, 1.16.0
>
>
> Tombstones in geode are kept on two maps: expiredTombstones and tombstones
> (non-expired ones). When a region is destroyed, it must clear all the related
> expired and non-expired tombstones from memory. Due to the below code bug,
> expired tombstones aren't cleared when non-expired tombstones are available
> during the region destruction:
> {code:java}
> private boolean removeIf(Predicate predicate) {
> return removeUnexpiredIf(predicate) || removeExpiredIf(predicate);
> }
> {code}
> Because of the above, non-expired tombstones are never removed from memory,
> preventing other tombstones from being cleared. Since other tombstones never
> expire, the compaction is not done, and therefore the disk is filled, causing
> the issues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GEODE-10281) Internal conflict replicated region resolution causes data inconsistency between two sites
[
https://issues.apache.org/jira/browse/GEODE-10281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo updated GEODE-10281:
---
Component/s: wan
> Internal conflict replicated region resolution causes data inconsistency
> between two sites
> --
>
> Key: GEODE-10281
> URL: https://issues.apache.org/jira/browse/GEODE-10281
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.1, 1.16.0
>
>
> {color:#0e101a}It seems that the following PR
> {color}[{color:#4a6ee0}[https://github.com/apache/geode/pull/3044]{color}]{color:#0e101a}
> has not taken into consideration that event with a flag
> isConcurrencyConflict=true could delete the valid event from the queue due to
> conflation.{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GEODE-10390) User guide: update authentication expiry instructions
[ https://issues.apache.org/jira/browse/GEODE-10390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo updated GEODE-10390: --- Component/s: docs > User guide: update authentication expiry instructions > - > > Key: GEODE-10390 > URL: https://issues.apache.org/jira/browse/GEODE-10390 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.15.0 >Reporter: Dave Barnes >Assignee: Dave Barnes >Priority: Major > Labels: pull-request-available > Fix For: 1.15.0, 1.15.1 > > > In "Implementing Authentication" indicate that "A SecurityManager > implementation that supports reauthentication using expiring credentials must > also support non-expiring credentials for cluster members” > In "Implementing Authentication Expiry", indicate that "Authentication expiry > is supported only with client connections." -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10415) CVEs detected in latest geode
[
https://issues.apache.org/jira/browse/GEODE-10415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo updated GEODE-10415:
---
Component/s: build
> CVEs detected in latest geode
> -
>
> Key: GEODE-10415
> URL: https://issues.apache.org/jira/browse/GEODE-10415
> Project: Geode
> Issue Type: Bug
> Components: build
>Affects Versions: 1.15.0
>Reporter: Shruti
>Assignee: Mario Kevo
>Priority: Blocker
> Labels: pull-request-available
> Fix For: 1.15.1, 1.16.0
>
>
> We are detecting the following CVEs with geode
> High or critical vulnerabilities: 21
> The spring-core is likely Not Affected. But we would like to know about the
> rest of these listed CVEs. Any info is appreciated
> {{ }}
> {{NAME INSTALLED FIXED-IN TYPE
> VULNERABILITY SEVERITY}}
> {{jetty-security 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-server 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-servlet 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util-ajax 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-webapp 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-xml 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jgroups 3.6.14.Final 4.0.0
> java-archive GHSA-rc7h-x6cq-988q Critical}}
> {{shiro-cache 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-ogdl 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-core 1.9.0 1.9.1
> java-archive GHSA-4cf5-xmhp-3xj7 Critical}}
> {{shiro-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-cipher 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-hash 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-event 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-lang 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{spring-core 5.3.20
> java-archive CVE-2016-127 Critical}}
> {{jetty-http 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-io 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GEODE-10415) CVEs detected in latest geode
[
https://issues.apache.org/jira/browse/GEODE-10415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo updated GEODE-10415:
---
Labels: pull-request-available (was: needsTriage pull-request-available)
> CVEs detected in latest geode
> -
>
> Key: GEODE-10415
> URL: https://issues.apache.org/jira/browse/GEODE-10415
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Shruti
>Assignee: Mario Kevo
>Priority: Blocker
> Labels: pull-request-available
> Fix For: 1.15.1, 1.16.0
>
>
> We are detecting the following CVEs with geode
> High or critical vulnerabilities: 21
> The spring-core is likely Not Affected. But we would like to know about the
> rest of these listed CVEs. Any info is appreciated
> {{ }}
> {{NAME INSTALLED FIXED-IN TYPE
> VULNERABILITY SEVERITY}}
> {{jetty-security 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-server 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-servlet 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util-ajax 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-webapp 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-xml 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jgroups 3.6.14.Final 4.0.0
> java-archive GHSA-rc7h-x6cq-988q Critical}}
> {{shiro-cache 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-ogdl 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-core 1.9.0 1.9.1
> java-archive GHSA-4cf5-xmhp-3xj7 Critical}}
> {{shiro-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-cipher 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-hash 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-event 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-lang 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{spring-core 5.3.20
> java-archive CVE-2016-127 Critical}}
> {{jetty-http 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-io 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GEODE-10038) Trying to access the QueryService results in NPE on server restart from deployed Jar
[
https://issues.apache.org/jira/browse/GEODE-10038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo reassigned GEODE-10038:
--
Assignee: Mario Kevo (was: Jakov Varenina)
> Trying to access the QueryService results in NPE on server restart from
> deployed Jar
>
>
> Key: GEODE-10038
> URL: https://issues.apache.org/jira/browse/GEODE-10038
> Project: Geode
> Issue Type: Bug
> Components: functions
>Affects Versions: 1.12.8, 1.13.7, 1.14.3, 1.15.0
>Reporter: Udo Kohlmeyer
>Assignee: Mario Kevo
>Priority: Major
>
> After deploying a jar which contains a Function, restarting the server causes
> an NPE.
> Using the Function definition of:
> {code:java}
> public class CustomFunction implements Function {
> private GemFireCache cache;
> private QueryService queryService;
> public CustomFunction() {
> this.cache = CacheFactory.getAnyInstance();
> this.queryService = cache.getQueryService();
> }
> {code}
> Due to the startup flow
> https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1404
> the registration of Functions are initialized from cluster configuration
> [here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1419].
> There is a dependency on the `QueryService` to be available at Function
> construction time, but given that the services are only initialized
> [here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/internal/cache/GemFireCacheImpl.java#L1435],
> the call to the `cache.getQueryService` fails with an NPE
> [here|https://github.com/apache/geode/blob/develop/geode-core/src/main/java/org/apache/geode/cache/query/internal/DefaultQueryService.java#L116-L117]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (GEODE-9918) Distributed transaction is not a supported feature in geode
[ https://issues.apache.org/jira/browse/GEODE-9918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo reassigned GEODE-9918: - Assignee: Mario Kevo (was: Jakov Varenina) > Distributed transaction is not a supported feature in geode > --- > > Key: GEODE-9918 > URL: https://issues.apache.org/jira/browse/GEODE-9918 > Project: Geode > Issue Type: Bug > Components: transactions >Reporter: Eric Shu >Assignee: Mario Kevo >Priority: Major > Labels: GeodeOperationAPI > > Geode should throw UnsupportedOperationException when > CacheTransactionManager.setDistributed(true) is invoked. As the feature is > currently not supported. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GEODE-10395) TXLockIdImpl memory leak after CommitConflictException from another node
[
https://issues.apache.org/jira/browse/GEODE-10395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo resolved GEODE-10395.
Fix Version/s: 1.16.0
Resolution: Fixed
> TXLockIdImpl memory leak after CommitConflictException from another node
>
>
> Key: GEODE-10395
> URL: https://issues.apache.org/jira/browse/GEODE-10395
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Eugene Nedzvetsky
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> org.apache.geode.internal.cache.locks.TXLockServiceImpl#txLock:120 adds
> TXLockIdImpl objects to TXLockServiceImpl#txLockIdList.
> {code:java}
> synchronized (txLockIdList) {
> txLockId = new TXLockIdImpl(dlock.getDistributionManager().getId());
> txLockIdList.add(txLockId);
> }
> {code}
> These objects will not be removed from this list if dlock.acquireTryLocks
> returned false.
> {code:java}
> gotLocks = dlock.acquireTryLocks(batch, TIMEOUT_MILLIS, LEASE_MILLIS,
> keyIfFail);
> if (gotLocks) { // ...otherwise race can occur between tryLocks and
> readLock
> acquireRecoveryReadLock();
> } else if (keyIfFail[0] != null) {
> throw new CommitConflictException(
> String.format("Concurrent transaction commit detected %s",
> keyIfFail[0]));
> } else {
> throw new CommitConflictException(
> String.format("Failed to request try locks from grantor: %s",
> dlock.getLockGrantorId()));
> }
> {code}
> It throws CommitConflictException and after that system doesn't have a
> txLockId reference and this txLockId will be never removed from this list.
> It produces critical performance degradation. txLockIdList has a few hundred
> thousand txLocks after a few weeks and TXLockServiceImpl#release iterates
> this list 2 times on every tx commit and the same time "synchronized
> (txLockIdList)" locks other threads.
> TXLockIdImpl#equals works really slow because it checks bunch of variables in
> memberId.equals(that.memberId).
> {code:java}
> public void release(TXLockId txLockId) {
> synchronized (txLockIdList) {
> if (!txLockIdList.contains(txLockId)) {
> // TXLockService.destroyServices can be invoked in cache.close().
> // Other P2P threads could process message such as TXCommitMessage
> afterwards,
> // and invoke TXLockService.createDTLS(). It could create a new
> TXLockService
> // which will have a new empty list (txLockIdList) and it will not
> // contain the originally added txLockId
> throw new IllegalArgumentException(
> String.format("Invalid txLockId not found: %s",
> txLockId));
> }
> dlock.releaseTryLocks(txLockId, () -> {
> return recovering;
> });
> txLockIdList.remove(txLockId);
> releaseRecoveryReadLock();
> }
> }
> {code}
> I think TXLockServiceImpl#txLock should remove this txLockId from
> TXLockServiceImpl#txLockIdList in case of CommitConflictException:
> {code:java}
> if (gotLocks) { // ...otherwise race can occur between tryLocks and readLock
> acquireRecoveryReadLock();
> } else if (keyIfFail[0] != null) {
> synchronized (this.txLockIdList) {
> this.txLockIdList.remove(txLockId);
> }
> throw new CommitConflictException(
> String.format("Concurrent transaction commit detected
> %s",
> keyIfFail[0]));
> } else {
> synchronized (this.txLockIdList) {
> this.txLockIdList.remove(txLockId);
> }
> throw new CommitConflictException(
> String.format("Failed to request try locks from
> grantor: %s",
> this.dlock.getLockGrantorId()));
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GEODE-10415) CVEs detected in latest geode
[
https://issues.apache.org/jira/browse/GEODE-10415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo resolved GEODE-10415.
Resolution: Fixed
> CVEs detected in latest geode
> -
>
> Key: GEODE-10415
> URL: https://issues.apache.org/jira/browse/GEODE-10415
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Shruti
>Assignee: Mario Kevo
>Priority: Blocker
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.1, 1.16.0
>
>
> We are detecting the following CVEs with geode
> High or critical vulnerabilities: 21
> The spring-core is likely Not Affected. But we would like to know about the
> rest of these listed CVEs. Any info is appreciated
> {{ }}
> {{NAME INSTALLED FIXED-IN TYPE
> VULNERABILITY SEVERITY}}
> {{jetty-security 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-server 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-servlet 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util-ajax 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-webapp 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-xml 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jgroups 3.6.14.Final 4.0.0
> java-archive GHSA-rc7h-x6cq-988q Critical}}
> {{shiro-cache 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-ogdl 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-core 1.9.0 1.9.1
> java-archive GHSA-4cf5-xmhp-3xj7 Critical}}
> {{shiro-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-cipher 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-hash 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-event 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-lang 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{spring-core 5.3.20
> java-archive CVE-2016-127 Critical}}
> {{jetty-http 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-io 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GEODE-10406) Update shiro-core to version 1.9.1 for CVE-2022-32532
[ https://issues.apache.org/jira/browse/GEODE-10406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo resolved GEODE-10406. Resolution: Duplicate > Update shiro-core to version 1.9.1 for CVE-2022-32532 > -- > > Key: GEODE-10406 > URL: https://issues.apache.org/jira/browse/GEODE-10406 > Project: Geode > Issue Type: Bug >Affects Versions: 1.13.7 >Reporter: Ankush Mittal >Assignee: Mario Kevo >Priority: Major > Labels: needsTriage > > As per [https://nvd.nist.gov/vuln/detail/CVE-2022-32532] > "Apache Shiro before 1.9.1, A RegexRequestMatcher can be misconfigured to be > bypassed on some servlet containers. Applications using RegExPatternMatcher > with `.` in the regular expression are possibly vulnerable to an > authorization bypass." > Geode bundles version 1.8.0 of shiro-core jar which is vulnerable as per the > CVE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GEODE-10406) Update shiro-core to version 1.9.1 for CVE-2022-32532
[ https://issues.apache.org/jira/browse/GEODE-10406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo reassigned GEODE-10406: -- Assignee: Mario Kevo > Update shiro-core to version 1.9.1 for CVE-2022-32532 > -- > > Key: GEODE-10406 > URL: https://issues.apache.org/jira/browse/GEODE-10406 > Project: Geode > Issue Type: Bug >Affects Versions: 1.13.7 >Reporter: Ankush Mittal >Assignee: Mario Kevo >Priority: Major > Labels: needsTriage > > As per [https://nvd.nist.gov/vuln/detail/CVE-2022-32532] > "Apache Shiro before 1.9.1, A RegexRequestMatcher can be misconfigured to be > bypassed on some servlet containers. Applications using RegExPatternMatcher > with `.` in the regular expression are possibly vulnerable to an > authorization bypass." > Geode bundles version 1.8.0 of shiro-core jar which is vulnerable as per the > CVE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10415) CVEs detected in latest geode
[
https://issues.apache.org/jira/browse/GEODE-10415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo updated GEODE-10415:
---
Fix Version/s: 1.15.1
1.16.0
> CVEs detected in latest geode
> -
>
> Key: GEODE-10415
> URL: https://issues.apache.org/jira/browse/GEODE-10415
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Shruti
>Assignee: Mario Kevo
>Priority: Blocker
> Labels: needsTriage, pull-request-available
> Fix For: 1.15.1, 1.16.0
>
>
> We are detecting the following CVEs with geode
> High or critical vulnerabilities: 21
> The spring-core is likely Not Affected. But we would like to know about the
> rest of these listed CVEs. Any info is appreciated
> {{ }}
> {{NAME INSTALLED FIXED-IN TYPE
> VULNERABILITY SEVERITY}}
> {{jetty-security 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-server 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-servlet 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util-ajax 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-webapp 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-xml 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jgroups 3.6.14.Final 4.0.0
> java-archive GHSA-rc7h-x6cq-988q Critical}}
> {{shiro-cache 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-ogdl 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-core 1.9.0 1.9.1
> java-archive GHSA-4cf5-xmhp-3xj7 Critical}}
> {{shiro-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-cipher 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-hash 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-event 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-lang 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{spring-core 5.3.20
> java-archive CVE-2016-127 Critical}}
> {{jetty-http 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-io 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GEODE-10422) Add doc for using parallel recovery disk store
[ https://issues.apache.org/jira/browse/GEODE-10422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo resolved GEODE-10422. Resolution: Fixed > Add doc for using parallel recovery disk store > -- > > Key: GEODE-10422 > URL: https://issues.apache.org/jira/browse/GEODE-10422 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.14.0, 1.15.0 >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Labels: pull-request-available > Fix For: 1.15.1, 1.16.0 > > > There are missing part for parallel recovery of disk stores. > It isn't specified that in case the user use the same disk store for the pdx > and the region, disk store recovery will go in the sequential mode. So in > case you want to use parallel disk store recovery it should be different disk > stores for the pdx and the disk store. Otherwise, it will go sequentially, > despite of default behavior to run in the parallel mode. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10422) Add doc for using parallel recovery disk store
[ https://issues.apache.org/jira/browse/GEODE-10422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo updated GEODE-10422: --- Fix Version/s: 1.15.1 > Add doc for using parallel recovery disk store > -- > > Key: GEODE-10422 > URL: https://issues.apache.org/jira/browse/GEODE-10422 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.14.0, 1.15.0 >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Labels: pull-request-available > Fix For: 1.15.1, 1.16.0 > > > There are missing part for parallel recovery of disk stores. > It isn't specified that in case the user use the same disk store for the pdx > and the region, disk store recovery will go in the sequential mode. So in > case you want to use parallel disk store recovery it should be different disk > stores for the pdx and the disk store. Otherwise, it will go sequentially, > despite of default behavior to run in the parallel mode. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10422) Add doc for using parallel recovery disk store
[ https://issues.apache.org/jira/browse/GEODE-10422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo updated GEODE-10422: --- Fix Version/s: 1.16.0 > Add doc for using parallel recovery disk store > -- > > Key: GEODE-10422 > URL: https://issues.apache.org/jira/browse/GEODE-10422 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.14.0, 1.15.0 >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > There are missing part for parallel recovery of disk stores. > It isn't specified that in case the user use the same disk store for the pdx > and the region, disk store recovery will go in the sequential mode. So in > case you want to use parallel disk store recovery it should be different disk > stores for the pdx and the disk store. Otherwise, it will go sequentially, > despite of default behavior to run in the parallel mode. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10281) Internal conflict replicated region resolution causes data inconsistency between two sites
[
https://issues.apache.org/jira/browse/GEODE-10281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo updated GEODE-10281:
---
Fix Version/s: 1.15.1
> Internal conflict replicated region resolution causes data inconsistency
> between two sites
> --
>
> Key: GEODE-10281
> URL: https://issues.apache.org/jira/browse/GEODE-10281
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.1, 1.16.0
>
>
> {color:#0e101a}It seems that the following PR
> {color}[{color:#4a6ee0}[https://github.com/apache/geode/pull/3044]{color}]{color:#0e101a}
> has not taken into consideration that event with a flag
> isConcurrencyConflict=true could delete the valid event from the queue due to
> conflation.{color}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (GEODE-10422) Add doc for using parallel recovery disk store
Mario Kevo created GEODE-10422: -- Summary: Add doc for using parallel recovery disk store Key: GEODE-10422 URL: https://issues.apache.org/jira/browse/GEODE-10422 Project: Geode Issue Type: Improvement Components: docs Affects Versions: 1.15.0, 1.14.0 Reporter: Mario Kevo There are missing part for parallel recovery of disk stores. It isn't specified that in case the user use the same disk store for the pdx and the region, disk store recovery will go in the sequential mode. So in case you want to use parallel disk store recovery it should be different disk stores for the pdx and the disk store. Otherwise, it will go sequentially, despite of default behavior to run in the parallel mode. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GEODE-10422) Add doc for using parallel recovery disk store
[ https://issues.apache.org/jira/browse/GEODE-10422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo reassigned GEODE-10422: -- Assignee: Mario Kevo > Add doc for using parallel recovery disk store > -- > > Key: GEODE-10422 > URL: https://issues.apache.org/jira/browse/GEODE-10422 > Project: Geode > Issue Type: Improvement > Components: docs >Affects Versions: 1.14.0, 1.15.0 >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > > There are missing part for parallel recovery of disk stores. > It isn't specified that in case the user use the same disk store for the pdx > and the region, disk store recovery will go in the sequential mode. So in > case you want to use parallel disk store recovery it should be different disk > stores for the pdx and the disk store. Otherwise, it will go sequentially, > despite of default behavior to run in the parallel mode. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GEODE-10415) CVEs detected in latest geode
[
https://issues.apache.org/jira/browse/GEODE-10415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo reassigned GEODE-10415:
--
Assignee: Mario Kevo (was: Weijie Xu)
> CVEs detected in latest geode
> -
>
> Key: GEODE-10415
> URL: https://issues.apache.org/jira/browse/GEODE-10415
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.15.0
>Reporter: Shruti
>Assignee: Mario Kevo
>Priority: Blocker
> Labels: needsTriage
>
> We are detecting the following CVEs with geode
> High or critical vulnerabilities: 21
> The spring-core is likely Not Affected. But we would like to know about the
> rest of these listed CVEs. Any info is appreciated
> {{ }}
> {{NAME INSTALLED FIXED-IN TYPE
> VULNERABILITY SEVERITY}}
> {{jetty-security 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-server 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-servlet 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-util-ajax 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-webapp 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-xml 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jgroups 3.6.14.Final 4.0.0
> java-archive GHSA-rc7h-x6cq-988q Critical}}
> {{shiro-cache 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-config-ogdl 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-core 1.9.0 1.9.1
> java-archive GHSA-4cf5-xmhp-3xj7 Critical}}
> {{shiro-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-cipher 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-core 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-crypto-hash 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-event 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{shiro-lang 1.9.0
> java-archive CVE-2022-32532 Critical}}
> {{spring-core 5.3.20
> java-archive CVE-2016-127 Critical}}
> {{jetty-http 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
> {{jetty-io 9.4.46.v20220331
> java-archive CVE-2022-2048 High}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GEODE-10418) Uplift Jetty to a newer version
[ https://issues.apache.org/jira/browse/GEODE-10418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo closed GEODE-10418. -- > Uplift Jetty to a newer version > --- > > Key: GEODE-10418 > URL: https://issues.apache.org/jira/browse/GEODE-10418 > Project: Geode > Issue Type: Bug >Reporter: Mario Kevo >Priority: Major > Labels: needsTriage > > The uplift of Eclipse Jetty to version 9.4.47 is needed due to high > vulnerability (CVE-2022-2048). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GEODE-10418) Uplift Jetty to a newer version
[ https://issues.apache.org/jira/browse/GEODE-10418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo resolved GEODE-10418. Resolution: Duplicate > Uplift Jetty to a newer version > --- > > Key: GEODE-10418 > URL: https://issues.apache.org/jira/browse/GEODE-10418 > Project: Geode > Issue Type: Bug >Reporter: Mario Kevo >Priority: Major > Labels: needsTriage > > The uplift of Eclipse Jetty to version 9.4.47 is needed due to high > vulnerability (CVE-2022-2048). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (GEODE-10418) Uplift Jetty to a newer version
[ https://issues.apache.org/jira/browse/GEODE-10418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17601374#comment-17601374 ] Mario Kevo commented on GEODE-10418: Yes, didn't see it. Thanks! > Uplift Jetty to a newer version > --- > > Key: GEODE-10418 > URL: https://issues.apache.org/jira/browse/GEODE-10418 > Project: Geode > Issue Type: Bug >Reporter: Mario Kevo >Priority: Major > Labels: needsTriage > > The uplift of Eclipse Jetty to version 9.4.47 is needed due to high > vulnerability (CVE-2022-2048). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GEODE-10418) Uplift Jetty to a newer version
Mario Kevo created GEODE-10418: -- Summary: Uplift Jetty to a newer version Key: GEODE-10418 URL: https://issues.apache.org/jira/browse/GEODE-10418 Project: Geode Issue Type: Bug Reporter: Mario Kevo The uplift of Eclipse Jetty to version 9.4.47 is needed due to high vulnerability (CVE-2022-2048). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GEODE-10395) TXLockIdImpl memory leak after CommitConflictException from another node
[
https://issues.apache.org/jira/browse/GEODE-10395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo reassigned GEODE-10395:
--
Assignee: Mario Kevo
> TXLockIdImpl memory leak after CommitConflictException from another node
>
>
> Key: GEODE-10395
> URL: https://issues.apache.org/jira/browse/GEODE-10395
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Eugene Nedzvetsky
>Assignee: Mario Kevo
>Priority: Major
> Labels: needsTriage
>
> org.apache.geode.internal.cache.locks.TXLockServiceImpl#txLock:120 adds
> TXLockIdImpl objects to TXLockServiceImpl#txLockIdList.
> {code:java}
> synchronized (txLockIdList) {
> txLockId = new TXLockIdImpl(dlock.getDistributionManager().getId());
> txLockIdList.add(txLockId);
> }
> {code}
> These objects will not be removed from this list if dlock.acquireTryLocks
> returned false.
> {code:java}
> gotLocks = dlock.acquireTryLocks(batch, TIMEOUT_MILLIS, LEASE_MILLIS,
> keyIfFail);
> if (gotLocks) { // ...otherwise race can occur between tryLocks and
> readLock
> acquireRecoveryReadLock();
> } else if (keyIfFail[0] != null) {
> throw new CommitConflictException(
> String.format("Concurrent transaction commit detected %s",
> keyIfFail[0]));
> } else {
> throw new CommitConflictException(
> String.format("Failed to request try locks from grantor: %s",
> dlock.getLockGrantorId()));
> }
> {code}
> It throws CommitConflictException and after that system doesn't have a
> txLockId reference and this txLockId will be never removed from this list.
> It produces critical performance degradation. txLockIdList has a few hundred
> thousand txLocks after a few weeks and TXLockServiceImpl#release iterates
> this list 2 times on every tx commit and the same time "synchronized
> (txLockIdList)" locks other threads.
> TXLockIdImpl#equals works really slow because it checks bunch of variables in
> memberId.equals(that.memberId).
> {code:java}
> public void release(TXLockId txLockId) {
> synchronized (txLockIdList) {
> if (!txLockIdList.contains(txLockId)) {
> // TXLockService.destroyServices can be invoked in cache.close().
> // Other P2P threads could process message such as TXCommitMessage
> afterwards,
> // and invoke TXLockService.createDTLS(). It could create a new
> TXLockService
> // which will have a new empty list (txLockIdList) and it will not
> // contain the originally added txLockId
> throw new IllegalArgumentException(
> String.format("Invalid txLockId not found: %s",
> txLockId));
> }
> dlock.releaseTryLocks(txLockId, () -> {
> return recovering;
> });
> txLockIdList.remove(txLockId);
> releaseRecoveryReadLock();
> }
> }
> {code}
> I think TXLockServiceImpl#txLock should remove this txLockId from
> TXLockServiceImpl#txLockIdList in case of CommitConflictException:
> {code:java}
> if (gotLocks) { // ...otherwise race can occur between tryLocks and readLock
> acquireRecoveryReadLock();
> } else if (keyIfFail[0] != null) {
> synchronized (this.txLockIdList) {
> this.txLockIdList.remove(txLockId);
> }
> throw new CommitConflictException(
> String.format("Concurrent transaction commit detected
> %s",
> keyIfFail[0]));
> } else {
> synchronized (this.txLockIdList) {
> this.txLockIdList.remove(txLockId);
> }
> throw new CommitConflictException(
> String.format("Failed to request try locks from
> grantor: %s",
> this.dlock.getLockGrantorId()));
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GEODE-10395) TXLockIdImpl memory leak after CommitConflictException from another node
[
https://issues.apache.org/jira/browse/GEODE-10395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo updated GEODE-10395:
---
Labels: (was: needsTriage)
> TXLockIdImpl memory leak after CommitConflictException from another node
>
>
> Key: GEODE-10395
> URL: https://issues.apache.org/jira/browse/GEODE-10395
> Project: Geode
> Issue Type: Bug
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Eugene Nedzvetsky
>Assignee: Mario Kevo
>Priority: Major
>
> org.apache.geode.internal.cache.locks.TXLockServiceImpl#txLock:120 adds
> TXLockIdImpl objects to TXLockServiceImpl#txLockIdList.
> {code:java}
> synchronized (txLockIdList) {
> txLockId = new TXLockIdImpl(dlock.getDistributionManager().getId());
> txLockIdList.add(txLockId);
> }
> {code}
> These objects will not be removed from this list if dlock.acquireTryLocks
> returned false.
> {code:java}
> gotLocks = dlock.acquireTryLocks(batch, TIMEOUT_MILLIS, LEASE_MILLIS,
> keyIfFail);
> if (gotLocks) { // ...otherwise race can occur between tryLocks and
> readLock
> acquireRecoveryReadLock();
> } else if (keyIfFail[0] != null) {
> throw new CommitConflictException(
> String.format("Concurrent transaction commit detected %s",
> keyIfFail[0]));
> } else {
> throw new CommitConflictException(
> String.format("Failed to request try locks from grantor: %s",
> dlock.getLockGrantorId()));
> }
> {code}
> It throws CommitConflictException and after that system doesn't have a
> txLockId reference and this txLockId will be never removed from this list.
> It produces critical performance degradation. txLockIdList has a few hundred
> thousand txLocks after a few weeks and TXLockServiceImpl#release iterates
> this list 2 times on every tx commit and the same time "synchronized
> (txLockIdList)" locks other threads.
> TXLockIdImpl#equals works really slow because it checks bunch of variables in
> memberId.equals(that.memberId).
> {code:java}
> public void release(TXLockId txLockId) {
> synchronized (txLockIdList) {
> if (!txLockIdList.contains(txLockId)) {
> // TXLockService.destroyServices can be invoked in cache.close().
> // Other P2P threads could process message such as TXCommitMessage
> afterwards,
> // and invoke TXLockService.createDTLS(). It could create a new
> TXLockService
> // which will have a new empty list (txLockIdList) and it will not
> // contain the originally added txLockId
> throw new IllegalArgumentException(
> String.format("Invalid txLockId not found: %s",
> txLockId));
> }
> dlock.releaseTryLocks(txLockId, () -> {
> return recovering;
> });
> txLockIdList.remove(txLockId);
> releaseRecoveryReadLock();
> }
> }
> {code}
> I think TXLockServiceImpl#txLock should remove this txLockId from
> TXLockServiceImpl#txLockIdList in case of CommitConflictException:
> {code:java}
> if (gotLocks) { // ...otherwise race can occur between tryLocks and readLock
> acquireRecoveryReadLock();
> } else if (keyIfFail[0] != null) {
> synchronized (this.txLockIdList) {
> this.txLockIdList.remove(txLockId);
> }
> throw new CommitConflictException(
> String.format("Concurrent transaction commit detected
> %s",
> keyIfFail[0]));
> } else {
> synchronized (this.txLockIdList) {
> this.txLockIdList.remove(txLockId);
> }
> throw new CommitConflictException(
> String.format("Failed to request try locks from
> grantor: %s",
> this.dlock.getLockGrantorId()));
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GEODE-10412) Destry region command doesn't clear the region related expired tombstones
[
https://issues.apache.org/jira/browse/GEODE-10412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo updated GEODE-10412:
---
Labels: (was: needsTriage)
> Destry region command doesn't clear the region related expired tombstones
> -
>
> Key: GEODE-10412
> URL: https://issues.apache.org/jira/browse/GEODE-10412
> Project: Geode
> Issue Type: Bug
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
>
> Tombstones in geode are kept on two maps: expiredTombstones and tombstones
> (non-expired ones). When a region is destroyed, it must clear all the related
> expired and non-expired tombstones from memory. Due to the below code bug,
> expired tombstones aren't cleared when non-expired tombstones are available
> during the region destruction:
> {code:java}
> private boolean removeIf(Predicate predicate) {
> return removeUnexpiredIf(predicate) || removeExpiredIf(predicate);
> }
> {code}
> Because of the above, non-expired tombstones are never removed from memory,
> preventing other tombstones from being cleared. Since other tombstones never
> expire, the compaction is not done, and therefore the disk is filled, causing
> the issues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GEODE-9632) Wrong output for the range query with wildcard character
[
https://issues.apache.org/jira/browse/GEODE-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo resolved GEODE-9632.
---
Fix Version/s: 1.16.0
Resolution: Fixed
> Wrong output for the range query with wildcard character
>
>
> Key: GEODE-9632
> URL: https://issues.apache.org/jira/browse/GEODE-9632
> Project: Geode
> Issue Type: Bug
> Components: querying
>Affects Versions: 1.13.1, 1.14.0
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> We are using a range index on an attribute that is defined as HashMap.
> The problem is when we are using wildcard character(%), there is no results
> for the query despite of there are some entries that meet the condition we
> are checking.
> There is an example:
>
> {code:java}
> gfsh>query --query="SELECT e.key, e.value from
> /example-region.entrySet e where e.value.positions['SUN'] LIKE
> '342234525745'"
> Result : true
> Limit : 100
> Rows: 1
> Query Trace : Query Executed in 9.082156 ms; indexesUsed(1):index1(Results: 1)
> gfsh>query --query="SELECT e.key, e.value from
> /example-region.entrySet e where e.value.positions['SUN'] LIKE
> '34223452574%'"
> Result : true
> Limit : 100
> Rows: 0
> Query Trace : Query Executed in 4.677162 ms; indexesUsed(1):index1(Results:
> 100)
> {code}
> As we are using indexes to have a better performance of executing a query it
> first need to check how many entries has that field which we are looking for.
> It stores it in index results and then check how many of them meet condition
> we defined in our query.
> The problem is that there is parameter INDEX_THRESHOLD_SIZE which default
> value is 100. If there is a lot of entries in the region it will write just
> first 100 entries that is found.
> This parameter can be changed while starting servers by adding
> *-Dgemfire.Query.INDEX_THRESHOLD_SIZE=*, but if we set it to a higher
> value than the limit in the query is, it will overwrite it. So there should
> be some changes to take this attribute into account.
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (GEODE-9101) Attribute VisibleNodes in MemberMXBean is incorrect
[
https://issues.apache.org/jira/browse/GEODE-9101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo updated GEODE-9101:
--
Labels: pull-request-available (was: needs-review pull-request-available)
> Attribute VisibleNodes in MemberMXBean is incorrect
> ---
>
> Key: GEODE-9101
> URL: https://issues.apache.org/jira/browse/GEODE-9101
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> In documentation states:
> _The current number of nodes in this distributed system visible to this
> member._
> But checking the value of the attribute we have a difference between locator
> and server.
> For example, we have the following system:
> {code:java}
>
> gfsh>list members
> Member Count : 4
> Name | Id
> | -
> locator1 | 192.168.0.145(locator1:26377:locator):41000 [Coordinator]
> locator2 | 192.168.0.145(locator2:26509:locator):41001
> server1 | 192.168.0.145(server1:26648):41002
> server2 | 192.168.0.145(server2:26768):41003
>
> {code}
>
> For locators visibleNodes = 2, but for servers visibleNodes = 3.
> Locators see only servers as visible nodes(In this case it sees *server1* and
> *server2*).
> Servers see first locator and all servers, including itself(In this case
> server1 sees *locator1*, *server1* and *server2*).
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GEODE-9101) Attribute VisibleNodes in MemberMXBean is incorrect
[
https://issues.apache.org/jira/browse/GEODE-9101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo resolved GEODE-9101.
---
Fix Version/s: 1.16.0
Resolution: Fixed
> Attribute VisibleNodes in MemberMXBean is incorrect
> ---
>
> Key: GEODE-9101
> URL: https://issues.apache.org/jira/browse/GEODE-9101
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> In documentation states:
> _The current number of nodes in this distributed system visible to this
> member._
> But checking the value of the attribute we have a difference between locator
> and server.
> For example, we have the following system:
> {code:java}
>
> gfsh>list members
> Member Count : 4
> Name | Id
> | -
> locator1 | 192.168.0.145(locator1:26377:locator):41000 [Coordinator]
> locator2 | 192.168.0.145(locator2:26509:locator):41001
> server1 | 192.168.0.145(server1:26648):41002
> server2 | 192.168.0.145(server2:26768):41003
>
> {code}
>
> For locators visibleNodes = 2, but for servers visibleNodes = 3.
> Locators see only servers as visible nodes(In this case it sees *server1* and
> *server2*).
> Servers see first locator and all servers, including itself(In this case
> server1 sees *locator1*, *server1* and *server2*).
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GEODE-10353) Change IndexThresholdSize default value
[
https://issues.apache.org/jira/browse/GEODE-10353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo resolved GEODE-10353.
Resolution: Won't Fix
> Change IndexThresholdSize default value
> ---
>
> Key: GEODE-10353
> URL: https://issues.apache.org/jira/browse/GEODE-10353
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> When doing range queries with the wildcard character(%), there are no result.
> The problem is that when we are doing a range query like this:
> {code:java}
> query --query="SELECT e.key, e.value from /example-region.entrySet e
> where e.value.positions['SUN'] LIKE 'abc%'"
> {code}
> The printed results will be null.
> The comparison will be divided into two comparison >='abc' and <'abd'.
> First it checks all entries that are lower than 'abd' and store them in the
> intermediate results. There are all entries which attribute 'SUN' is lower
> than 'abd' which can be a very high number. It iterates through all entries
> and store first 100 entries in the intermediate results. The limit is 100, it
> can be changed if an user sets the indexThresholdSize to higher value when
> starting servers, but in many cases the user couldn't know how many entries
> will be in the region.
> So the best way is to set this indexThresholdSize to Integer.MAX_VALUE by
> default so the query will always give the correct results.
> The limit which is set in query is not the same as this limit, so with this
> change it will still put limit on printing results.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (GEODE-10398) TotalBucketCount are not updated after restart
[ https://issues.apache.org/jira/browse/GEODE-10398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo resolved GEODE-10398. Fix Version/s: 1.16.0 Resolution: Fixed > TotalBucketCount are not updated after restart > -- > > Key: GEODE-10398 > URL: https://issues.apache.org/jira/browse/GEODE-10398 > Project: Geode > Issue Type: Bug > Components: statistics >Affects Versions: 1.13.8, 1.14.4, 1.15.0 >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Labels: pull-request-available > Fix For: 1.16.0 > > > Steps to reproduce the issue: > # start locator and 4 servers(static sampling enabled) > # create disk stores for gw sender and region > # create parallel gw sender with disk store > # create the region with gw sender and disk store > # initialize buckets > # shutdown servers > # get up all servers > # check the member stats > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GEODE-10398) TotalBucketCount are not updated after restart
[ https://issues.apache.org/jira/browse/GEODE-10398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo reassigned GEODE-10398: -- Assignee: Mario Kevo > TotalBucketCount are not updated after restart > -- > > Key: GEODE-10398 > URL: https://issues.apache.org/jira/browse/GEODE-10398 > Project: Geode > Issue Type: Bug > Components: statistics >Affects Versions: 1.13.8, 1.14.4, 1.15.0 >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Labels: needsTriage, pull-request-available > > Steps to reproduce the issue: > # start locator and 4 servers(static sampling enabled) > # create disk stores for gw sender and region > # create parallel gw sender with disk store > # create the region with gw sender and disk store > # initialize buckets > # shutdown servers > # get up all servers > # check the member stats > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (GEODE-10398) TotalBucketCount are not updated after restart
[ https://issues.apache.org/jira/browse/GEODE-10398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo updated GEODE-10398: --- Labels: pull-request-available (was: needsTriage pull-request-available) > TotalBucketCount are not updated after restart > -- > > Key: GEODE-10398 > URL: https://issues.apache.org/jira/browse/GEODE-10398 > Project: Geode > Issue Type: Bug > Components: statistics >Affects Versions: 1.13.8, 1.14.4, 1.15.0 >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Labels: pull-request-available > > Steps to reproduce the issue: > # start locator and 4 servers(static sampling enabled) > # create disk stores for gw sender and region > # create parallel gw sender with disk store > # create the region with gw sender and disk store > # initialize buckets > # shutdown servers > # get up all servers > # check the member stats > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (GEODE-10055) AbstractLauncher print info and debug with stderr instead of stdout
[
https://issues.apache.org/jira/browse/GEODE-10055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo resolved GEODE-10055.
Fix Version/s: 1.16.0
Resolution: Fixed
> AbstractLauncher print info and debug with stderr instead of stdout
> ---
>
> Key: GEODE-10055
> URL: https://issues.apache.org/jira/browse/GEODE-10055
> Project: Geode
> Issue Type: Bug
> Components: logging
>Affects Versions: 1.12.8, 1.13.7, 1.14.3
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> The problem happened with locator/server launcher logs which are printed with
> stderr in both cases, for info and debug.
> {code:java}
> protected void info(final Object message, final Object... args) {
> if (args != null && args.length > 0) {
> System.err.printf(message.toString(), args);
> } else {
> System.err.print(message);
> }
> }
> {code}
> And when it is redirected to some tools it represents it like an error as it
> is printed with stderr, instead of stdout.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (GEODE-10398) TotalBucketCount are not updated after restart
Mario Kevo created GEODE-10398: -- Summary: TotalBucketCount are not updated after restart Key: GEODE-10398 URL: https://issues.apache.org/jira/browse/GEODE-10398 Project: Geode Issue Type: Bug Components: statistics Affects Versions: 1.15.0, 1.14.4, 1.13.8 Reporter: Mario Kevo Steps to reproduce the issue: # start locator and 4 servers(static sampling enabled) # create disk stores for gw sender and region # create parallel gw sender with disk store # create the region with gw sender and disk store # initialize buckets # shutdown servers # get up all servers # check the member stats -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (GEODE-9876) SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest > testSerialGatewaySenderThreadsConnectToSameReceiver FAILED
[
https://issues.apache.org/jira/browse/GEODE-9876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo reassigned GEODE-9876:
-
Assignee: (was: Mario Kevo)
> SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest >
> testSerialGatewaySenderThreadsConnectToSameReceiver FAILED
> -
>
> Key: GEODE-9876
> URL: https://issues.apache.org/jira/browse/GEODE-9876
> Project: Geode
> Issue Type: Bug
> Components: wan
>Affects Versions: 1.15.0
>Reporter: Mark Hanson
>Priority: Major
>
>
> {noformat}
> java.lang.AssertionError: Error parsing gfsh output. 'Senders Connected'
> column header not found
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.assertTrue(Assert.java:42)
> at org.junit.Assert.assertNotNull(Assert.java:713)
> at
> org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.parseSendersConnectedFromGfshOutput(SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.java:236)
> at
> org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.allDispatchersConnectedToSameReceiver(SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.java:208)
> at
> org.apache.geode.cache.wan.SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.testSerialGatewaySenderThreadsConnectToSameReceiver(SeveralGatewayReceiversWithSamePortAndHostnameForSendersTest.java:176)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.geode.test.dunit.rules.AbstractDistributedRule$1.evaluate(AbstractDistributedRule.java:59)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.apache.geode.rules.DockerComposeRule$1.evaluate(DockerComposeRule.java:104)
> at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:54)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at
> org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:43)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:193)
> at java.util.Iterator.forEachRemaining(Iterator.java:116)
> at
> java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at
> java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at
> java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:485)
> at
>
[jira] [Resolved] (GEODE-10267) Create gw sender with non-existent disk store does not fail
[
https://issues.apache.org/jira/browse/GEODE-10267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo resolved GEODE-10267.
Fix Version/s: 1.16.0
Resolution: Fixed
> Create gw sender with non-existent disk store does not fail
> ---
>
> Key: GEODE-10267
> URL: https://issues.apache.org/jira/browse/GEODE-10267
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.14.4
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> While creating a parallel gw sender with a non-existing disk store, the
> command passed successfully but shouldn't.
> {code:java}
> gfsh>create gateway-sender --id=ln --remote-distributed-system-id=2
> --parallel=true --disk-store-name=nonExistingDiskStore
> Member | Status | Message
> --- | -- | ---
> server1 | OK | GatewaySender "ln" created on "server1"
> server2 | OK | GatewaySender "ln" created on "server2"
> Cluster configuration for group 'cluster' is updated.
> gfsh>list disk-stores
> No Disk Stores Found
> {code}
> For the serial gw sender, it throws that disk-store is not found as expected.
> {code:java}
> gfsh>create gateway-sender --id=ln-serial --remote-distributed-system-id=2
> --parallel=false --disk-store-name=nonExistingDiskStore
> Member | Status | Message
> --- | -- |
> ---
> server1 | ERROR | java.lang.IllegalStateException: Disk store
> nonExistingDiskStore not found
> server2 | ERROR | java.lang.IllegalStateException: Disk store
> nonExistingDiskStore not found
> {code}
> But after the above command for the serial gw sender is failed, execute list
> gateways and got that the serial gw sender is created.
> {code:java}
> gfsh>list gateways
> GatewaySender Section
> GatewaySender Id | Member | Remote Cluster Id
> | Type | Status| Queued Events | Receiver Location
> | -- | -
> | -- | --- | - | -
> ln2 | 192.168.0.145(server1:10868):41001 | 2
> | Serial | Not Running | 0 |
> ln2 | 192.168.0.145(server2:10963):41002 | 2
> | Serial | Not Running | 0 |
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-7875) The gfsh create index command sometimes fails with 'Index already exists. Create failed due to duplicate name.' message
[
https://issues.apache.org/jira/browse/GEODE-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo resolved GEODE-7875.
---
Fix Version/s: 1.16.0
Resolution: Fixed
> The gfsh create index command sometimes fails with 'Index already exists.
> Create failed due to duplicate name.' message
> ---
>
> Key: GEODE-7875
> URL: https://issues.apache.org/jira/browse/GEODE-7875
> Project: Geode
> Issue Type: Bug
> Components: gfsh, querying
>Reporter: Barrett Oglesby
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.16.0
>
>
> Here is output from the connect, list indexes, create index commands:
> {noformat}
> (1) Executing - connect --locator=localhost[23456]
> Connecting to Locator at [host=localhost, port=23456] ..
> Connecting to Manager at [host=boglesbymac.local, port=1099] ..
> Successfully connected to: [host=boglesbymac.local, port=1099]
> (2) Executing - list indexes
> No Indexes Found
> (3) Executing - create index --name=cusip_index_1 --expression=cusip
> --region=/Trades
>Member| Status | Message
> | -- |
> ---
> 192.168.1.4(server1:88452):41001 | ERROR | Index "cusip_index_1" already
> exists. Create failed due to duplicate name.
> 192.168.1.4(server2:88465):41002 | OK | Index successfully created
> 192.168.1.4(server3:88473):41003 | ERROR | Index "cusip_index_1" already
> exists. Create failed due to duplicate name.
> 192.168.1.4(server4:88480):41004 | ERROR | Index "cusip_index_1" already
> exists. Create failed due to duplicate name.
> {noformat}
> Here is some logging that shows the behavior:
> server2 executes the CreateIndexFunction and creates the index locally:
> {noformat}
> [warn 2020/03/12 16:18:11.273 PDT tid=0x54]
> XXX CreateIndexFunction.execute indexName=cusip_index_1
> [info 2020/03/12 16:18:11.297 PDT tid=0x54]
> Created index locally, sending index creation message to all members, and
> will be waiting for response Index [ Name=cusip_index_1 Type =FUNCTIONAL
> IdxExp=cusip From=/Trades Proj=*]imports : null.
> {noformat}
> It sends the IndexCreationMsg to servers 1, 3 and 4 and processes the
> response:
> {noformat}
> [warn 2020/03/12 16:18:11.297 PDT tid=0x54]
> XXX IndexCreationMsg.send indMsg=cusip_index_1
> [warn 2020/03/12 16:18:11.298 PDT tid=0x54]
> XXX PartitionedRegion.createIndex
> response= from [192.168.1.4(server1:88452):41001,
> 192.168.1.4(server3:88473):41003, 192.168.1.4(server4:88480):41004]>
> {noformat}
> servers 1, 3 and 4 receive the IndexCreationMsg, creates the index and
> respond:
> {noformat}
> [warn 2020/03/12 16:18:11.298 PDT
> tid=0x4b] XXX IndexCreationMsg.operateOnPartitionedRegion about to
> createIndexes
> [warn 2020/03/12 16:18:11.304 PDT
> tid=0x4b] XXX IndexCreationMsg.operateOnPartitionedRegion done createIndexes
> {noformat}
> Then they execute the CreateIndexFunction to create the index locally which
> fails:
> {noformat}
> [warn 2020/03/12 16:18:11.501 PDT tid=0x4e]
> XXX CreateIndexFunction.execute indexName=cusip_index_1
> [warn 2020/03/12 16:18:11.521 PDT tid=0x4e]
> XXX CreateIndexFunction.execute failed due to IndexNameConflictException:
> org.apache.geode.cache.query.IndexNameConflictException: Index named '
> cusip_index_1 ' already exists.
> at
> org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8453)
> at
> org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8403)
> at
> org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:245)
> at
> org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:203)
> at
> org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:274)
> at
> org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:177)
> at
> org.apache.geode.management.internal.cli.functions.CreateIndexFunction.execute(CreateIndexFunction.java:62)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-8655) Not handling exception on SNIHostName
[
https://issues.apache.org/jira/browse/GEODE-8655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo resolved GEODE-8655.
---
Fix Version/s: 1.15.0
Resolution: Fixed
> Not handling exception on SNIHostName
> -
>
> Key: GEODE-8655
> URL: https://issues.apache.org/jira/browse/GEODE-8655
> Project: Geode
> Issue Type: Bug
> Components: locator, security
>Affects Versions: 1.13.0
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> If we start locator with ipv6 and TLS enabled we got following error for
> status locator command:
>
> {quote}mkevo@mkevo-XPS-15-9570:~/apache-geode-1.13.0/bin/locator$
> _/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java -server -classpath
> /home/mkevo/apache-geode-1.13.0/lib/geode-core-1.13.0.jar:/home/mkevo/apache-geode-1.13.0/lib/geode-dependencies.jar
> -Djava.net.preferIPv6Addresses=true
> -DgemfireSecurityPropertyFile=/home/mkevo/geode-examples/clientSecurity/example_security.properties
> -Dgemfire.enable-cluster-configuration=true
> -Dgemfire.load-cluster-configuration-from-dir=false
> -Dgemfire.launcher.registerSignalHandlers=true -Djava.awt.headless=true
> -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
> org.apache.geode.distributed.LocatorLauncher start locator --port=10334_
>
> gfsh>_status locator --dir=/home/mkevo/apache-geode-1.13.0/bin/locator
> --security-properties-file=/home/mkevo/geode-examples/clientSecurity/example_security.properties_
> *Locator in /home/mkevo/apache-geode-1.13.0/bin/locator on
> mkevo-XPS-15-9570[10334] is currently not responding.*
> {quote}
>
> From locator logs we found only this:
> {quote}Exception in processing request from fe80:0:0:0:f83e:ce0f:5143:f9ee%2:
> Read timed out
> {quote}
>
> After adding some logs we found the following:
> {quote}{color:#1d1c1d}TcpClient.stop(): exception connecting to locator
> HostAndPort[/0:0:0:0:0:0:0:0:10334]java.lang.IllegalArgumentException:
> Contains non-LDH ASCII characters{color}
> {quote}
> **
> It fails on creating SNIHostName from hostName(_setServerNames_ in
> SocketCreator.java) as it not handling above exception.
>
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10353) Change IndexThresholdSize default value
[
https://issues.apache.org/jira/browse/GEODE-10353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo reassigned GEODE-10353:
--
Assignee: Mario Kevo
> Change IndexThresholdSize default value
> ---
>
> Key: GEODE-10353
> URL: https://issues.apache.org/jira/browse/GEODE-10353
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: needsTriage
>
> When doing range queries with the wildcard character(%), there are no result.
> The problem is that when we are doing a range query like this:
> {code:java}
> query --query="SELECT e.key, e.value from /example-region.entrySet e
> where e.value.positions['SUN'] LIKE 'abc%'"
> {code}
> The printed results will be null.
> The comparison will be divided into two comparison >='abc' and <'abd'.
> First it checks all entries that are lower than 'abd' and store them in the
> intermediate results. There are all entries which attribute 'SUN' is lower
> than 'abd' which can be a very high number. It iterates through all entries
> and store first 100 entries in the intermediate results. The limit is 100, it
> can be changed if an user sets the indexThresholdSize to higher value when
> starting servers, but in many cases the user couldn't know how many entries
> will be in the region.
> So the best way is to set this indexThresholdSize to Integer.MAX_VALUE by
> default so the query will always give the correct results.
> The limit which is set in query is not the same as this limit, so with this
> change it will still put limit on printing results.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10353) Change IndexThresholdSize default value
Mario Kevo created GEODE-10353:
--
Summary: Change IndexThresholdSize default value
Key: GEODE-10353
URL: https://issues.apache.org/jira/browse/GEODE-10353
Project: Geode
Issue Type: Bug
Components: querying
Reporter: Mario Kevo
When doing range queries with the wildcard character(%), there are no result.
The problem is that when we are doing a range query like this:
{code:java}
query --query="SELECT e.key, e.value from /example-region.entrySet e
where e.value.positions['SUN'] LIKE 'abc%'"
{code}
The printed results will be null.
The comparison will be divided into two comparison >='abc' and <'abd'.
First it checks all entries that are lower than 'abd' and store them in the
intermediate results. There are all entries which attribute 'SUN' is lower than
'abd' which can be a very high number. It iterates through all entries and
store first 100 entries in the intermediate results. The limit is 100, it can
be changed if an user sets the indexThresholdSize to higher value when starting
servers, but in many cases the user couldn't know how many entries will be in
the region.
So the best way is to set this indexThresholdSize to Integer.MAX_VALUE by
default so the query will always give the correct results.
The limit which is set in query is not the same as this limit, so with this
change it will still put limit on printing results.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (GEODE-10317) Range query with wildcard character doing wrong comparison
[ https://issues.apache.org/jira/browse/GEODE-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo resolved GEODE-10317. Resolution: Not A Problem The issue is not in the comparison. If we changed as it is agreed on the dev list, it will give us the wrong result. > Range query with wildcard character doing wrong comparison > -- > > Key: GEODE-10317 > URL: https://issues.apache.org/jira/browse/GEODE-10317 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Labels: pull-request-available > > The problem is when we are using the wildcard character(%), there are no > results for the query as it is being turned in two comparisons, GE(>=) and > LT(<), with AND junction. > This will lead to the wrong output for these queries. > The same thing happened for both queries when they had wildcard character % > in the middle or at the end of the compared string. > As discussed on the [dev > list|https://markmail.org/search/?q=Question+about+INDEX_THRESHOLD_SIZE#query:Question%20about%20INDEX_THRESHOLD_SIZE+page:1+mid:y2upza72ufjrd33b+state:results], > the correct way to use, like comparison with the string that contains > wildcard character % at the end will be just GE(>=). > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10317) Range query with wildcard character doing wrong comparison
[ https://issues.apache.org/jira/browse/GEODE-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo updated GEODE-10317: --- Summary: Range query with wildcard character doing wrong comparison (was: Range query with wildcard character(%) doing wrong comparison) > Range query with wildcard character doing wrong comparison > -- > > Key: GEODE-10317 > URL: https://issues.apache.org/jira/browse/GEODE-10317 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Labels: needsTriage > > The problem is when we are using the wildcard character(%), there are no > results for the query as it is being turned in two comparisons, GE(>=) and > LT(<), with AND junction. > This will lead to the wrong output for these queries. > The same thing happened for both queries when they had wildcard character % > in the middle or at the end of the compared string. > As discussed on the [dev > list|https://markmail.org/search/?q=Question+about+INDEX_THRESHOLD_SIZE#query:Question%20about%20INDEX_THRESHOLD_SIZE+page:1+mid:y2upza72ufjrd33b+state:results], > the correct way to use, like comparison with the string that contains > wildcard character % at the end will be just GE(>=). > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (GEODE-10317) Range query with wildcard character(%) doing wrong comparison
[ https://issues.apache.org/jira/browse/GEODE-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo reassigned GEODE-10317: -- Assignee: Mario Kevo > Range query with wildcard character(%) doing wrong comparison > - > > Key: GEODE-10317 > URL: https://issues.apache.org/jira/browse/GEODE-10317 > Project: Geode > Issue Type: Bug > Components: querying >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Labels: needsTriage > > The problem is when we are using the wildcard character(%), there are no > results for the query as it is being turned in two comparisons, GE(>=) and > LT(<), with AND junction. > This will lead to the wrong output for these queries. > The same thing happened for both queries when they had wildcard character % > in the middle or at the end of the compared string. > As discussed on the [dev > list|https://markmail.org/search/?q=Question+about+INDEX_THRESHOLD_SIZE#query:Question%20about%20INDEX_THRESHOLD_SIZE+page:1+mid:y2upza72ufjrd33b+state:results], > the correct way to use, like comparison with the string that contains > wildcard character % at the end will be just GE(>=). > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (GEODE-10317) Range query with wildcard character(%) doing wrong comparison
Mario Kevo created GEODE-10317: -- Summary: Range query with wildcard character(%) doing wrong comparison Key: GEODE-10317 URL: https://issues.apache.org/jira/browse/GEODE-10317 Project: Geode Issue Type: Bug Components: querying Reporter: Mario Kevo The problem is when we are using the wildcard character(%), there are no results for the query as it is being turned in two comparisons, GE(>=) and LT(<), with AND junction. This will lead to the wrong output for these queries. The same thing happened for both queries when they had wildcard character % in the middle or at the end of the compared string. As discussed on the [dev list|https://markmail.org/search/?q=Question+about+INDEX_THRESHOLD_SIZE#query:Question%20about%20INDEX_THRESHOLD_SIZE+page:1+mid:y2upza72ufjrd33b+state:results], the correct way to use, like comparison with the string that contains wildcard character % at the end will be just GE(>=). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (GEODE-8546) Colocated regions missing some buckets after restart
[ https://issues.apache.org/jira/browse/GEODE-8546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo resolved GEODE-8546. --- Resolution: Fixed > Colocated regions missing some buckets after restart > > > Key: GEODE-8546 > URL: https://issues.apache.org/jira/browse/GEODE-8546 > Project: Geode > Issue Type: Bug > Components: regions >Affects Versions: 1.11.0, 1.12.0, 1.13.0 >Reporter: Mario Kevo >Assignee: Mario Kevo >Priority: Major > Labels: pull-request-available > > After restart all servers at the same time, some colocation regions missing > some buckets. > This issue exist for a long time and become visible from 1.11.0 by > introducing this changes GEODE-7042 . > How to reproduce the issue: > # Start two locators and two servers > # Create PARTITION_REDUNDANT_PERSISTENT region with redundant-copies=1 > # Create few PARTITION_REDUNDANT regions(I used six regions) colocated with > persistent region and redundant-copies=1 > # Put some entries. > # Restart servers(you can simply run "kill -15 " and then from > two terminals start both of them at the same time) > # It will take a time to get server startup finished and for the latest > region bucketCount will be lower than expected on one member -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (GEODE-10267) Create gw sender with non-existent disk store does not fail
[
https://issues.apache.org/jira/browse/GEODE-10267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo updated GEODE-10267:
---
Description:
While creating a parallel gw sender with a non-existing disk store, the command
passed successfully but shouldn't.
{code:java}
gfsh>create gateway-sender --id=ln --remote-distributed-system-id=2
--parallel=true --disk-store-name=nonExistingDiskStore
Member | Status | Message
--- | -- | ---
server1 | OK | GatewaySender "ln" created on "server1"
server2 | OK | GatewaySender "ln" created on "server2"
Cluster configuration for group 'cluster' is updated.
gfsh>list disk-stores
No Disk Stores Found
{code}
For the serial gw sender, it throws that disk-store is not found as expected.
{code:java}
gfsh>create gateway-sender --id=ln-serial --remote-distributed-system-id=2
--parallel=false --disk-store-name=nonExistingDiskStore
Member | Status | Message
--- | -- |
---
server1 | ERROR | java.lang.IllegalStateException: Disk store
nonExistingDiskStore not found
server2 | ERROR | java.lang.IllegalStateException: Disk store
nonExistingDiskStore not found
{code}
But after the above command for the serial gw sender is failed, execute list
gateways and got that the serial gw sender is created.
{code:java}
gfsh>list gateways
GatewaySender Section
GatewaySender Id | Member | Remote Cluster Id |
Type | Status| Queued Events | Receiver Location
| -- | - |
-- | --- | - | -
ln2 | 192.168.0.145(server1:10868):41001 | 2 |
Serial | Not Running | 0 |
ln2 | 192.168.0.145(server2:10963):41002 | 2 |
Serial | Not Running | 0 |
{code}
was:
While creating a parallel gw sender with a non-existing disk store, the command
passed successfully but shouldn't.
{code:java}
gfsh>create gateway-sender --id=ln --remote-distributed-system-id=2
--parallel=true --disk-store-name=nonExistingDiskStore
Member | Status | Message
--- | -- | ---
server1 | OK | GatewaySender "ln" created on "server1"
server2 | OK | GatewaySender "ln" created on "server2"
Cluster configuration for group 'cluster' is updated.
gfsh>list disk-stores
No Disk Stores Found
{code}
For the serial gw sender, it throws that disk-store is not found as expected.
{code:java}
gfsh>create gateway-sender --id=ln-serial --remote-distributed-system-id=2
--parallel=false --disk-store-name=nonExistingDiskStore
Member | Status | Message
--- | -- |
---
server1 | ERROR | java.lang.IllegalStateException: Disk store
nonExistingDiskStore not found
server2 | ERROR | java.lang.IllegalStateException: Disk store
nonExistingDiskStore not found
{code}
> Create gw sender with non-existent disk store does not fail
> ---
>
> Key: GEODE-10267
> URL: https://issues.apache.org/jira/browse/GEODE-10267
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.14.4
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> While creating a parallel gw sender with a non-existing disk store, the
> command passed successfully but shouldn't.
> {code:java}
> gfsh>create gateway-sender --id=ln --remote-distributed-system-id=2
> --parallel=true --disk-store-name=nonExistingDiskStore
> Member | Status | Message
> --- | -- | ---
> server1 | OK | GatewaySender "ln" created on "server1"
> server2 | OK | GatewaySender "ln" created on "server2"
> Cluster configuration for group 'cluster' is updated.
> gfsh>list disk-stores
> No Disk Stores Found
> {code}
> For the serial gw sender, it throws that disk-store is not found as expected.
> {code:java}
> gfsh>create gateway-sender --id=ln-serial --remote-distributed-system-id=2
> --parallel=false --disk-store-name=nonExistingDiskStore
> Member | Status | Message
> --- | -- |
> ---
> server1 | ERROR | java.lang.IllegalStateException: Disk store
> nonExistingDiskStore not found
> server2 | ERROR | java.lang.IllegalStateException: Disk store
> nonExistingDiskStore not found
> {code}
> But after the above command for the serial gw sender is failed, execute list
> gateways and got that the serial gw sender is created.
> {code:java}
> gfsh>list gateways
> GatewaySender Section
>
[jira] [Updated] (GEODE-10267) Create gw sender with non-existent disk store does not fail
[
https://issues.apache.org/jira/browse/GEODE-10267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo updated GEODE-10267:
---
Summary: Create gw sender with non-existent disk store does not fail (was:
Create parallel gw sender with non-existent disk store does not fail)
> Create gw sender with non-existent disk store does not fail
> ---
>
> Key: GEODE-10267
> URL: https://issues.apache.org/jira/browse/GEODE-10267
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.14.4
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
>
> While creating a parallel gw sender with a non-existing disk store, the
> command passed successfully but shouldn't.
> {code:java}
> gfsh>create gateway-sender --id=ln --remote-distributed-system-id=2
> --parallel=true --disk-store-name=nonExistingDiskStore
> Member | Status | Message
> --- | -- | ---
> server1 | OK | GatewaySender "ln" created on "server1"
> server2 | OK | GatewaySender "ln" created on "server2"
> Cluster configuration for group 'cluster' is updated.
> gfsh>list disk-stores
> No Disk Stores Found
> {code}
> For the serial gw sender, it throws that disk-store is not found as expected.
> {code:java}
> gfsh>create gateway-sender --id=ln-serial --remote-distributed-system-id=2
> --parallel=false --disk-store-name=nonExistingDiskStore
> Member | Status | Message
> --- | -- |
> ---
> server1 | ERROR | java.lang.IllegalStateException: Disk store
> nonExistingDiskStore not found
> server2 | ERROR | java.lang.IllegalStateException: Disk store
> nonExistingDiskStore not found
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (GEODE-10267) Create parallel gw sender with non-existent disk store does not fail
Mario Kevo created GEODE-10267:
--
Summary: Create parallel gw sender with non-existent disk store
does not fail
Key: GEODE-10267
URL: https://issues.apache.org/jira/browse/GEODE-10267
Project: Geode
Issue Type: Bug
Components: gfsh
Affects Versions: 1.14.4
Reporter: Mario Kevo
While creating a parallel gw sender with a non-existing disk store, the command
passed successfully but shouldn't.
{code:java}
gfsh>create gateway-sender --id=ln --remote-distributed-system-id=2
--parallel=true --disk-store-name=nonExistingDiskStore
Member | Status | Message
--- | -- | ---
server1 | OK | GatewaySender "ln" created on "server1"
server2 | OK | GatewaySender "ln" created on "server2"
Cluster configuration for group 'cluster' is updated.
gfsh>list disk-stores
No Disk Stores Found
{code}
For the serial gw sender, it throws that disk-store is not found as expected.
{code:java}
gfsh>create gateway-sender --id=ln-serial --remote-distributed-system-id=2
--parallel=false --disk-store-name=nonExistingDiskStore
Member | Status | Message
--- | -- |
---
server1 | ERROR | java.lang.IllegalStateException: Disk store
nonExistingDiskStore not found
server2 | ERROR | java.lang.IllegalStateException: Disk store
nonExistingDiskStore not found
{code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10267) Create parallel gw sender with non-existent disk store does not fail
[
https://issues.apache.org/jira/browse/GEODE-10267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo reassigned GEODE-10267:
--
Assignee: Mario Kevo
> Create parallel gw sender with non-existent disk store does not fail
>
>
> Key: GEODE-10267
> URL: https://issues.apache.org/jira/browse/GEODE-10267
> Project: Geode
> Issue Type: Bug
> Components: gfsh
>Affects Versions: 1.14.4
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: needsTriage
>
> While creating a parallel gw sender with a non-existing disk store, the
> command passed successfully but shouldn't.
> {code:java}
> gfsh>create gateway-sender --id=ln --remote-distributed-system-id=2
> --parallel=true --disk-store-name=nonExistingDiskStore
> Member | Status | Message
> --- | -- | ---
> server1 | OK | GatewaySender "ln" created on "server1"
> server2 | OK | GatewaySender "ln" created on "server2"
> Cluster configuration for group 'cluster' is updated.
> gfsh>list disk-stores
> No Disk Stores Found
> {code}
> For the serial gw sender, it throws that disk-store is not found as expected.
> {code:java}
> gfsh>create gateway-sender --id=ln-serial --remote-distributed-system-id=2
> --parallel=false --disk-store-name=nonExistingDiskStore
> Member | Status | Message
> --- | -- |
> ---
> server1 | ERROR | java.lang.IllegalStateException: Disk store
> nonExistingDiskStore not found
> server2 | ERROR | java.lang.IllegalStateException: Disk store
> nonExistingDiskStore not found
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (GEODE-10055) AbstractLauncher print info and debug with stderr instead of stdout
[
https://issues.apache.org/jira/browse/GEODE-10055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo reassigned GEODE-10055:
--
Assignee: Mario Kevo
> AbstractLauncher print info and debug with stderr instead of stdout
> ---
>
> Key: GEODE-10055
> URL: https://issues.apache.org/jira/browse/GEODE-10055
> Project: Geode
> Issue Type: Bug
> Components: logging
>Affects Versions: 1.12.8, 1.13.7, 1.14.3
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: needsTriage
>
> The problem happened with locator/server launcher logs which are printed with
> stderr in both cases, for info and debug.
> {code:java}
> protected void info(final Object message, final Object... args) {
> if (args != null && args.length > 0) {
> System.err.printf(message.toString(), args);
> } else {
> System.err.print(message);
> }
> }
> {code}
> And when it is redirected to some tools it represents it like an error as it
> is printed with stderr, instead of stdout.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-10055) AbstractLauncher print info and debug with stderr instead of stdout
Mario Kevo created GEODE-10055:
--
Summary: AbstractLauncher print info and debug with stderr instead
of stdout
Key: GEODE-10055
URL: https://issues.apache.org/jira/browse/GEODE-10055
Project: Geode
Issue Type: Bug
Components: logging
Affects Versions: 1.14.3, 1.13.7, 1.12.8
Reporter: Mario Kevo
The problem happened with locator/server launcher logs which are printed with
stderr in both cases, for info and debug.
{code:java}
protected void info(final Object message, final Object... args) {
if (args != null && args.length > 0) {
System.err.printf(message.toString(), args);
} else {
System.err.print(message);
}
}
{code}
And when it is redirected to some tools it represents it like an error as it is
printed with stderr, instead of stdout.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (GEODE-9969) The region name starting with underscore lead to missing disk store after restart
Mario Kevo created GEODE-9969:
-
Summary: The region name starting with underscore lead to missing
disk store after restart
Key: GEODE-9969
URL: https://issues.apache.org/jira/browse/GEODE-9969
Project: Geode
Issue Type: Bug
Components: regions
Affects Versions: 1.14.2, 1.13.6, 1.12.8, 1.15.0
Reporter: Mario Kevo
The problem is when using the region with a name starting with an
underscore(allowed by documentation
[region_naming|https://geode.apache.org/docs/guide/114/basic_config/data_regions/region_naming.html]).
If we stop one of the members and then rename the working dir(include disk
store dir) to some new name and start the server with the name like renamed
working dir, it will lead that we have the same disk-store-id in the listed
disk-stores and in the missing disk store.
This happens only if we are using the region with an underscore at the
beginning.
Steps to reproduce:
Run locator and 4 servers, create region with name starting by underscore
# start locator --name=locator
# start server --name=server1 --server-port=40401
# start server --name=server2 --server-port=40402
# start server --name=server3 --server-port=40403
# start server --name=server4 --server-port=40404
# create region --name=_test-region --type=PARTITION_REDUNDANT_PERSISTENT
--redundant-copies=1 --total-num-buckets=10 --enable-synchronous-disk=false
# query --query="select * from /_test-region"
>From another terminal (Kill server and rename working dir)
# kill -9 $(cat server4/vf.gf.server.pid)
# mv server4/ server5
{code:java}
gfsh>list disk-stores
Member Name | Member Id | Disk Store Name | Disk
Store ID
--- | -- | --- |
server1 | 192.168.0.145(server1:16916):41001 | DEFAULT |
d5d17b43-4a06-408b-917f-08e5b2533ebe
server2 | 192.168.0.145(server2:17004):41002 | DEFAULT |
31d47cb4-718e-4b58-bde3-ae15b4657910
server3 | 192.168.0.145(server3:17094):41003 | DEFAULT |
f12850c6-a73b-443e-9ee0-87f0819ae6bc
server5 | 192.168.0.145(server5:17428):41004 | DEFAULT |
7a552fb3-e43d-4fa8-baa8-f6dc794cbf74
gfsh>show missing-disk-stores
Missing Disk Stores
Disk Store ID | Host | Directory
| - |
7a552fb3-e43d-4fa8-baa8-f6dc794cbf74 | 192.168.0.145 |
/home/mkevo/apache-geode-1.15.0-build.0/bin/server4/.
No missing colocated region found
{code}
Start a new server with a name like you rename your working dir from the
restarted server.
# start server --name=server5 --server-port=40405
Now we have the following output:
{code:java}
gfsh>list disk-stores
Member Name | Member Id| Disk Store Name | Disk
Store ID
--- | -- | --- |
server1 | 192.168.0.145(server1:16916):41001 | DEFAULT |
d5d17b43-4a06-408b-917f-08e5b2533ebe
server2 | 192.168.0.145(server2:17004):41002 | DEFAULT |
31d47cb4-718e-4b58-bde3-ae15b4657910
server3 | 192.168.0.145(server3:17094):41003 | DEFAULT |
f12850c6-a73b-443e-9ee0-87f0819ae6bc
server5 | 192.168.0.145(server5:17428):41004 | DEFAULT |
7a552fb3-e43d-4fa8-baa8-f6dc794cbf74
gfsh>show missing-disk-stores
Missing Disk Stores
Disk Store ID | Host | Directory
| - |
7a552fb3-e43d-4fa8-baa8-f6dc794cbf74 | 192.168.0.145 |
/home/mkevo/apache-geode-1.15.0-build.0/bin/server4/.
No missing colocated region found
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (GEODE-9969) The region name starting with underscore lead to missing disk store after restart
[
https://issues.apache.org/jira/browse/GEODE-9969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo reassigned GEODE-9969:
-
Assignee: Mario Kevo
> The region name starting with underscore lead to missing disk store after
> restart
> -
>
> Key: GEODE-9969
> URL: https://issues.apache.org/jira/browse/GEODE-9969
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.12.8, 1.13.6, 1.14.2, 1.15.0
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: needsTriage
>
> The problem is when using the region with a name starting with an
> underscore(allowed by documentation
> [region_naming|https://geode.apache.org/docs/guide/114/basic_config/data_regions/region_naming.html]).
> If we stop one of the members and then rename the working dir(include disk
> store dir) to some new name and start the server with the name like renamed
> working dir, it will lead that we have the same disk-store-id in the listed
> disk-stores and in the missing disk store.
> This happens only if we are using the region with an underscore at the
> beginning.
> Steps to reproduce:
> Run locator and 4 servers, create region with name starting by underscore
> # start locator --name=locator
> # start server --name=server1 --server-port=40401
> # start server --name=server2 --server-port=40402
> # start server --name=server3 --server-port=40403
> # start server --name=server4 --server-port=40404
> # create region --name=_test-region --type=PARTITION_REDUNDANT_PERSISTENT
> --redundant-copies=1 --total-num-buckets=10 --enable-synchronous-disk=false
> # query --query="select * from /_test-region"
> From another terminal (Kill server and rename working dir)
> # kill -9 $(cat server4/vf.gf.server.pid)
> # mv server4/ server5
> {code:java}
> gfsh>list disk-stores
> Member Name | Member Id | Disk Store Name | Disk
> Store ID
> --- | -- | --- |
>
> server1 | 192.168.0.145(server1:16916):41001 | DEFAULT |
> d5d17b43-4a06-408b-917f-08e5b2533ebe
> server2 | 192.168.0.145(server2:17004):41002 | DEFAULT |
> 31d47cb4-718e-4b58-bde3-ae15b4657910
> server3 | 192.168.0.145(server3:17094):41003 | DEFAULT |
> f12850c6-a73b-443e-9ee0-87f0819ae6bc
> server5 | 192.168.0.145(server5:17428):41004 | DEFAULT |
> 7a552fb3-e43d-4fa8-baa8-f6dc794cbf74
> gfsh>show missing-disk-stores
> Missing Disk Stores
> Disk Store ID | Host | Directory
> | - |
>
> 7a552fb3-e43d-4fa8-baa8-f6dc794cbf74 | 192.168.0.145 |
> /home/mkevo/apache-geode-1.15.0-build.0/bin/server4/.
> No missing colocated region found
> {code}
> Start a new server with a name like you rename your working dir from the
> restarted server.
> # start server --name=server5 --server-port=40405
> Now we have the following output:
> {code:java}
> gfsh>list disk-stores
> Member Name | Member Id| Disk Store Name | Disk
> Store ID
> --- | -- | --- |
>
> server1 | 192.168.0.145(server1:16916):41001 | DEFAULT |
> d5d17b43-4a06-408b-917f-08e5b2533ebe
> server2 | 192.168.0.145(server2:17004):41002 | DEFAULT |
> 31d47cb4-718e-4b58-bde3-ae15b4657910
> server3 | 192.168.0.145(server3:17094):41003 | DEFAULT |
> f12850c6-a73b-443e-9ee0-87f0819ae6bc
> server5 | 192.168.0.145(server5:17428):41004 | DEFAULT |
> 7a552fb3-e43d-4fa8-baa8-f6dc794cbf74
> gfsh>show missing-disk-stores
> Missing Disk Stores
>Disk Store ID | Host | Directory
> | - |
>
> 7a552fb3-e43d-4fa8-baa8-f6dc794cbf74 | 192.168.0.145 |
> /home/mkevo/apache-geode-1.15.0-build.0/bin/server4/.
> No missing colocated region found
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-7875) The gfsh create index command sometimes fails with 'Index already exists. Create failed due to duplicate name.' message
[
https://issues.apache.org/jira/browse/GEODE-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17463081#comment-17463081
]
Mario Kevo commented on GEODE-7875:
---
When creating an index on the partitioned region, the create index is sent to
all members to create an index on all buckets.
After that, it checks on all members if there is already an index created or
the creation is in progress.
In case it is already created it will respond with returning index in case the
request is remotely originated. In case the request is locally it will throw
exception IndexNameConflictException.
In case it is not already created, it checks if it has FutureTask, which means
that index creation is in progress. If there is no FutureTask for this
indexTask it will create it locally and send it to all members and wait for
their response.
In case the index creation is in progress on some of the threads, it will wait
until it is initialized from that thread. If the request was remotely
originated it will return ind to the server from which the request comes to
know that it is created on that server.
In case the request is local, it will also wait until the index creation is
finished by some thread which already started creation, before this request
comes, and throw IndexNameConflictException as it is already created.
In that case, the command is not successful and the cluster config is not
updated.
The mail discussion is available on the dev list.
https://markmail.org/message/uxhlysb2nx3u7p6y#query:+page:1+mid:v367uwf67hlpcr7t+state:results
> The gfsh create index command sometimes fails with 'Index already exists.
> Create failed due to duplicate name.' message
> ---
>
> Key: GEODE-7875
> URL: https://issues.apache.org/jira/browse/GEODE-7875
> Project: Geode
> Issue Type: Bug
> Components: gfsh, querying
>Reporter: Barrett Oglesby
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
>
> Here is output from the connect, list indexes, create index commands:
> {noformat}
> (1) Executing - connect --locator=localhost[23456]
> Connecting to Locator at [host=localhost, port=23456] ..
> Connecting to Manager at [host=boglesbymac.local, port=1099] ..
> Successfully connected to: [host=boglesbymac.local, port=1099]
> (2) Executing - list indexes
> No Indexes Found
> (3) Executing - create index --name=cusip_index_1 --expression=cusip
> --region=/Trades
>Member| Status | Message
> | -- |
> ---
> 192.168.1.4(server1:88452):41001 | ERROR | Index "cusip_index_1" already
> exists. Create failed due to duplicate name.
> 192.168.1.4(server2:88465):41002 | OK | Index successfully created
> 192.168.1.4(server3:88473):41003 | ERROR | Index "cusip_index_1" already
> exists. Create failed due to duplicate name.
> 192.168.1.4(server4:88480):41004 | ERROR | Index "cusip_index_1" already
> exists. Create failed due to duplicate name.
> {noformat}
> Here is some logging that shows the behavior:
> server2 executes the CreateIndexFunction and creates the index locally:
> {noformat}
> [warn 2020/03/12 16:18:11.273 PDT tid=0x54]
> XXX CreateIndexFunction.execute indexName=cusip_index_1
> [info 2020/03/12 16:18:11.297 PDT tid=0x54]
> Created index locally, sending index creation message to all members, and
> will be waiting for response Index [ Name=cusip_index_1 Type =FUNCTIONAL
> IdxExp=cusip From=/Trades Proj=*]imports : null.
> {noformat}
> It sends the IndexCreationMsg to servers 1, 3 and 4 and processes the
> response:
> {noformat}
> [warn 2020/03/12 16:18:11.297 PDT tid=0x54]
> XXX IndexCreationMsg.send indMsg=cusip_index_1
> [warn 2020/03/12 16:18:11.298 PDT tid=0x54]
> XXX PartitionedRegion.createIndex
> response= from [192.168.1.4(server1:88452):41001,
> 192.168.1.4(server3:88473):41003, 192.168.1.4(server4:88480):41004]>
> {noformat}
> servers 1, 3 and 4 receive the IndexCreationMsg, creates the index and
> respond:
> {noformat}
> [warn 2020/03/12 16:18:11.298 PDT
> tid=0x4b] XXX IndexCreationMsg.operateOnPartitionedRegion about to
> createIndexes
> [warn 2020/03/12 16:18:11.304 PDT
> tid=0x4b] XXX IndexCreationMsg.operateOnPartitionedRegion done createIndexes
> {noformat}
> Then they execute the CreateIndexFunction to create the index locally which
> fails:
> {noformat}
> [warn 2020/03/12 16:18:11.501 PDT tid=0x4e]
> XXX CreateIndexFunction.execute indexName=cusip_index_1
> [warn 2020/03/12 16:18:11.521 PDT tid=0x4e]
> XXX CreateIndexFunction.execute failed due to IndexNameConflictException:
>
[jira] [Assigned] (GEODE-7875) The gfsh create index command sometimes fails with 'Index already exists. Create failed due to duplicate name.' message
[
https://issues.apache.org/jira/browse/GEODE-7875?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo reassigned GEODE-7875:
-
Assignee: Mario Kevo
> The gfsh create index command sometimes fails with 'Index already exists.
> Create failed due to duplicate name.' message
> ---
>
> Key: GEODE-7875
> URL: https://issues.apache.org/jira/browse/GEODE-7875
> Project: Geode
> Issue Type: Bug
> Components: gfsh, querying
>Reporter: Barrett Oglesby
>Assignee: Mario Kevo
>Priority: Major
>
> Here is output from the connect, list indexes, create index commands:
> {noformat}
> (1) Executing - connect --locator=localhost[23456]
> Connecting to Locator at [host=localhost, port=23456] ..
> Connecting to Manager at [host=boglesbymac.local, port=1099] ..
> Successfully connected to: [host=boglesbymac.local, port=1099]
> (2) Executing - list indexes
> No Indexes Found
> (3) Executing - create index --name=cusip_index_1 --expression=cusip
> --region=/Trades
>Member| Status | Message
> | -- |
> ---
> 192.168.1.4(server1:88452):41001 | ERROR | Index "cusip_index_1" already
> exists. Create failed due to duplicate name.
> 192.168.1.4(server2:88465):41002 | OK | Index successfully created
> 192.168.1.4(server3:88473):41003 | ERROR | Index "cusip_index_1" already
> exists. Create failed due to duplicate name.
> 192.168.1.4(server4:88480):41004 | ERROR | Index "cusip_index_1" already
> exists. Create failed due to duplicate name.
> {noformat}
> Here is some logging that shows the behavior:
> server2 executes the CreateIndexFunction and creates the index locally:
> {noformat}
> [warn 2020/03/12 16:18:11.273 PDT tid=0x54]
> XXX CreateIndexFunction.execute indexName=cusip_index_1
> [info 2020/03/12 16:18:11.297 PDT tid=0x54]
> Created index locally, sending index creation message to all members, and
> will be waiting for response Index [ Name=cusip_index_1 Type =FUNCTIONAL
> IdxExp=cusip From=/Trades Proj=*]imports : null.
> {noformat}
> It sends the IndexCreationMsg to servers 1, 3 and 4 and processes the
> response:
> {noformat}
> [warn 2020/03/12 16:18:11.297 PDT tid=0x54]
> XXX IndexCreationMsg.send indMsg=cusip_index_1
> [warn 2020/03/12 16:18:11.298 PDT tid=0x54]
> XXX PartitionedRegion.createIndex
> response= from [192.168.1.4(server1:88452):41001,
> 192.168.1.4(server3:88473):41003, 192.168.1.4(server4:88480):41004]>
> {noformat}
> servers 1, 3 and 4 receive the IndexCreationMsg, creates the index and
> respond:
> {noformat}
> [warn 2020/03/12 16:18:11.298 PDT
> tid=0x4b] XXX IndexCreationMsg.operateOnPartitionedRegion about to
> createIndexes
> [warn 2020/03/12 16:18:11.304 PDT
> tid=0x4b] XXX IndexCreationMsg.operateOnPartitionedRegion done createIndexes
> {noformat}
> Then they execute the CreateIndexFunction to create the index locally which
> fails:
> {noformat}
> [warn 2020/03/12 16:18:11.501 PDT tid=0x4e]
> XXX CreateIndexFunction.execute indexName=cusip_index_1
> [warn 2020/03/12 16:18:11.521 PDT tid=0x4e]
> XXX CreateIndexFunction.execute failed due to IndexNameConflictException:
> org.apache.geode.cache.query.IndexNameConflictException: Index named '
> cusip_index_1 ' already exists.
> at
> org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8453)
> at
> org.apache.geode.internal.cache.PartitionedRegion.createIndex(PartitionedRegion.java:8403)
> at
> org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:245)
> at
> org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:203)
> at
> org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:274)
> at
> org.apache.geode.cache.query.internal.DefaultQueryService.createIndex(DefaultQueryService.java:177)
> at
> org.apache.geode.management.internal.cli.functions.CreateIndexFunction.execute(CreateIndexFunction.java:62)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (GEODE-9632) Wrong output for the range query with wildcard character
[
https://issues.apache.org/jira/browse/GEODE-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo resolved GEODE-9632.
---
Fix Version/s: 1.15.0
Resolution: Fixed
> Wrong output for the range query with wildcard character
>
>
> Key: GEODE-9632
> URL: https://issues.apache.org/jira/browse/GEODE-9632
> Project: Geode
> Issue Type: Bug
> Components: querying
>Affects Versions: 1.13.1, 1.14.0
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> We are using a range index on an attribute that is defined as HashMap.
> The problem is when we are using wildcard character(%), there is no results
> for the query despite of there are some entries that meet the condition we
> are checking.
> There is an example:
>
> {code:java}
> gfsh>query --query="SELECT e.key, e.value from
> /example-region.entrySet e where e.value.positions['SUN'] LIKE
> '342234525745'"
> Result : true
> Limit : 100
> Rows: 1
> Query Trace : Query Executed in 9.082156 ms; indexesUsed(1):index1(Results: 1)
> gfsh>query --query="SELECT e.key, e.value from
> /example-region.entrySet e where e.value.positions['SUN'] LIKE
> '34223452574%'"
> Result : true
> Limit : 100
> Rows: 0
> Query Trace : Query Executed in 4.677162 ms; indexesUsed(1):index1(Results:
> 100)
> {code}
> As we are using indexes to have a better performance of executing a query it
> first need to check how many entries has that field which we are looking for.
> It stores it in index results and then check how many of them meet condition
> we defined in our query.
> The problem is that there is parameter INDEX_THRESHOLD_SIZE which default
> value is 100. If there is a lot of entries in the region it will write just
> first 100 entries that is found.
> This parameter can be changed while starting servers by adding
> *-Dgemfire.Query.INDEX_THRESHOLD_SIZE=*, but if we set it to a higher
> value than the limit in the query is, it will overwrite it. So there should
> be some changes to take this attribute into account.
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (GEODE-9632) Wrong output for the range query with wildcard character
[
https://issues.apache.org/jira/browse/GEODE-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428647#comment-17428647
]
Mario Kevo commented on GEODE-9632:
---
Hi [~amurmann], we tested it against 1.13.1 and 1.14.0 versions. But think that
this is also a bug in all earlier versions.
> Wrong output for the range query with wildcard character
>
>
> Key: GEODE-9632
> URL: https://issues.apache.org/jira/browse/GEODE-9632
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
>
> We are using a range index on an attribute that is defined as HashMap.
> The problem is when we are using wildcard character(%), there is no results
> for the query despite of there are some entries that meet the condition we
> are checking.
> There is an example:
>
> {code:java}
> gfsh>query --query="SELECT e.key, e.value from
> /example-region.entrySet e where e.value.positions['SUN'] LIKE
> '342234525745'"
> Result : true
> Limit : 100
> Rows: 1
> Query Trace : Query Executed in 9.082156 ms; indexesUsed(1):index1(Results: 1)
> gfsh>query --query="SELECT e.key, e.value from
> /example-region.entrySet e where e.value.positions['SUN'] LIKE
> '34223452574%'"
> Result : true
> Limit : 100
> Rows: 0
> Query Trace : Query Executed in 4.677162 ms; indexesUsed(1):index1(Results:
> 100)
> {code}
> As we are using indexes to have a better performance of executing a query it
> first need to check how many entries has that field which we are looking for.
> It stores it in index results and then check how many of them meet condition
> we defined in our query.
> The problem is that there is parameter INDEX_THRESHOLD_SIZE which default
> value is 100. If there is a lot of entries in the region it will write just
> first 100 entries that is found.
> This parameter can be changed while starting servers by adding
> *-Dgemfire.Query.INDEX_THRESHOLD_SIZE=*, but if we set it to a higher
> value than the limit in the query is, it will overwrite it. So there should
> be some changes to take this attribute into account.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (GEODE-9718) The region is not created on all servers if commands are run in parallel
[ https://issues.apache.org/jira/browse/GEODE-9718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17428644#comment-17428644 ] Mario Kevo commented on GEODE-9718: --- Hi [~amurmann], we tested it against 1.13.1 and 1.14.0, but this can happens on all versions. > The region is not created on all servers if commands are run in parallel > > > Key: GEODE-9718 > URL: https://issues.apache.org/jira/browse/GEODE-9718 > Project: Geode > Issue Type: Bug > Components: regions >Reporter: Mario Kevo >Priority: Major > Labels: needsTriage > > We are using a system with a large number of servers. > While starting all servers, in parallel, we create a region through gfsh. > The problem is that on one of the servers region is not created. > It is started after the "create region" command is started, so it will not > get information to create a region on itself from the locator. Also, the > cluster configuration doesn't have that information yet, so the server cannot > read it from the received cluster configuration. > So, the problem is in changing cluster configuration whilst servers are > coming up. > The solutions are: > # Add to the documentation to not running commands that doing some changes > on cluster configuration while the server is in starting phase. > # Redesign all commands that can edit the cluster configuration to first > wrote changes to the cluster config and then distribute the commands to all > servers. > The second solution can lead to some problems. When the "create region" > command is executed it got all servers from the view and sends all of them to > start creating a region with parameters specified in the command. > The region creating is started on all servers and after it is finished, it > is added to the cluster configuration. In case there are some problems with > creating a region(wrong parameter used or something else) it will not create > a region on the existing servers and will not write anything in a cluster > configuration. > In case we decide to change order, it will write in the cluster config > before the command is successful, and then we should have some backup to > rollback cluster configuration. Also, this will affects all commands that do > changes in cluster config. > > Mail discussion: [Region is not created on one of the > servers|https://markmail.org/message/q4zanaklz7osgx4j#query:+page:1+mid:q4zanaklz7osgx4j+state:results] > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9718) The region is not created on all servers if commands are run in parallel
[ https://issues.apache.org/jira/browse/GEODE-9718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo updated GEODE-9718: -- Description: We are using a system with a large number of servers. While starting all servers, in parallel, we create a region through gfsh. The problem is that on one of the servers region is not created. It is started after the "create region" command is started, so it will not get information to create a region on itself from the locator. Also, the cluster configuration doesn't have that information yet, so the server cannot read it from the received cluster configuration. So, the problem is in changing cluster configuration whilst servers are coming up. The solutions are: # Add to the documentation to not running commands that doing some changes on cluster configuration while the server is in starting phase. # Redesign all commands that can edit the cluster configuration to first wrote changes to the cluster config and then distribute the commands to all servers. The second solution can lead to some problems. When the "create region" command is executed it got all servers from the view and sends all of them to start creating a region with parameters specified in the command. The region creating is started on all servers and after it is finished, it is added to the cluster configuration. In case there are some problems with creating a region(wrong parameter used or something else) it will not create a region on the existing servers and will not write anything in a cluster configuration. In case we decide to change order, it will write in the cluster config before the command is successful, and then we should have some backup to rollback cluster configuration. Also, this will affects all commands that do changes in cluster config. Mail discussion: [Region is not created on one of the servers|https://markmail.org/message/q4zanaklz7osgx4j#query:+page:1+mid:q4zanaklz7osgx4j+state:results] was: We are using a system with a large number of servers. While starting all servers, in parallel, we create a region through gfsh. The problem is that on one of the servers region is not created. It is started after the "create region" command is started, so it will not get information to create a region on itself from the locator. Also, the cluster configuration doesn't have that information yet, so the server cannot read it from the received cluster configuration. So, the problem is in changing cluster configuration whilst servers are coming up. The solutions are: # Add to the documentation to not running commands that doing some changes on cluster configuration while the server is in starting phase. # Redesign all commands that can edit the cluster configuration to first wrote changes to the cluster config and then distribute the commands to all servers. The second solution can lead to some problems. When the "create region" command is executed it got all servers from the view and sends all of them to start creating a region with parameters specified in the command. The region creating is started on all servers and after it is finished, it is added to the cluster configuration. In case there are some problems with creating a region(wrong parameter used or something else) it will not create a region on the existing servers and will not write anything in a cluster configuration. In case we decide to change order, it will write in the cluster config before the command is successful, and then we should have some backup to rollback cluster configuration. Also, this will affects all commands that do changes in cluster config. > The region is not created on all servers if commands are run in parallel > > > Key: GEODE-9718 > URL: https://issues.apache.org/jira/browse/GEODE-9718 > Project: Geode > Issue Type: Bug >Reporter: Mario Kevo >Priority: Major > Labels: needsTriage > > We are using a system with a large number of servers. > While starting all servers, in parallel, we create a region through gfsh. > The problem is that on one of the servers region is not created. > It is started after the "create region" command is started, so it will not > get information to create a region on itself from the locator. Also, the > cluster configuration doesn't have that information yet, so the server cannot > read it from the received cluster configuration. > So, the problem is in changing cluster configuration whilst servers are > coming up. > The solutions are: > # Add to the documentation to not running commands that doing some changes > on cluster configuration while the server is in starting phase. > # Redesign all commands that can edit the cluster configuration to first > wrote changes to the cluster
[jira] [Created] (GEODE-9718) The region is not created on all servers if commands are run in parallel
Mario Kevo created GEODE-9718: - Summary: The region is not created on all servers if commands are run in parallel Key: GEODE-9718 URL: https://issues.apache.org/jira/browse/GEODE-9718 Project: Geode Issue Type: Bug Reporter: Mario Kevo We are using a system with a large number of servers. While starting all servers, in parallel, we create a region through gfsh. The problem is that on one of the servers region is not created. It is started after the "create region" command is started, so it will not get information to create a region on itself from the locator. Also, the cluster configuration doesn't have that information yet, so the server cannot read it from the received cluster configuration. So, the problem is in changing cluster configuration whilst servers are coming up. The solutions are: # Add to the documentation to not running commands that doing some changes on cluster configuration while the server is in starting phase. # Redesign all commands that can edit the cluster configuration to first wrote changes to the cluster config and then distribute the commands to all servers. The second solution can lead to some problems. When the "create region" command is executed it got all servers from the view and sends all of them to start creating a region with parameters specified in the command. The region creating is started on all servers and after it is finished, it is added to the cluster configuration. In case there are some problems with creating a region(wrong parameter used or something else) it will not create a region on the existing servers and will not write anything in a cluster configuration. In case we decide to change order, it will write in the cluster config before the command is successful, and then we should have some backup to rollback cluster configuration. Also, this will affects all commands that do changes in cluster config. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9632) Wrong output for the range query with wildcard character
[
https://issues.apache.org/jira/browse/GEODE-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo updated GEODE-9632:
--
Description:
We are using a range index on an attribute that is defined as HashMap.
The problem is when we are using wildcard character(%), there is no results for
the query despite of there are some entries that meet the condition we are
checking.
There is an example:
{code:java}
gfsh>query --query="SELECT e.key, e.value from /example-region.entrySet
e where e.value.positions['SUN'] LIKE '342234525745'"
Result : true
Limit : 100
Rows: 1
Query Trace : Query Executed in 9.082156 ms; indexesUsed(1):index1(Results: 1)
gfsh>query --query="SELECT e.key, e.value from /example-region.entrySet
e where e.value.positions['SUN'] LIKE '34223452574%'"
Result : true
Limit : 100
Rows: 0
Query Trace : Query Executed in 4.677162 ms; indexesUsed(1):index1(Results: 100)
{code}
As we are using indexes to have a better performance of executing a query it
first need to check how many entries has that field which we are looking for.
It stores it in index results and then check how many of them meet condition we
defined in our query.
The problem is that there is parameter INDEX_THRESHOLD_SIZE which default value
is 100. If there is a lot of entries in the region it will write just first 100
entries that is found.
This parameter can be changed while starting servers by adding
*-Dgemfire.Query.INDEX_THRESHOLD_SIZE=*, but if we set it to a higher
value than the limit in the query is, it will overwrite it. So there should be
some changes to take this attribute into account.
was:
We are using a range index on an attribute that is defined as HashMap.
The problem is when we are using wildcard character(%), there is no results for
the query despite of there are some entries that meet the condition we are
checking.
There is an example:
{code:java}
gfsh>query --query="SELECT e.key, e.value from /example-region.entrySet
e where e.value.positions['SUN'] LIKE '342234525745'"
Result : true
Limit : 100
Rows: 1
Query Trace : Query Executed in 9.082156 ms; indexesUsed(1):index1(Results: 1)
gfsh>query --query="SELECT e.key, e.value from /example-region.entrySet
e where e.value.positions['SUN'] LIKE '34223452574%'"
Result : true
Limit : 100
Rows: 0
Query Trace : Query Executed in 4.677162 ms; indexesUsed(1):index1(Results: 100)
{code}
As we are using indexes to have a better performance of executing a query it
first need to check how many entries has that field which we are looking for.
It stores it in index results and then check how many of them meet condition we
defined in our query.
The problem is that there is parameter INDEX_THRESHOLD_SIZE which default value
is 100. If there is a lot of entries in the region it will write just first 100
entries that is found.
This parameter can be changed while starting servers by adding
*-Dgemfire.Query.INDEX_THRESHOLD_SIZE=*, but if we set it to a higher
value than the limit is, it will overwrite it. So there should be some changes
to take this attribute into account.
> Wrong output for the range query with wildcard character
>
>
> Key: GEODE-9632
> URL: https://issues.apache.org/jira/browse/GEODE-9632
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
>
> We are using a range index on an attribute that is defined as HashMap.
> The problem is when we are using wildcard character(%), there is no results
> for the query despite of there are some entries that meet the condition we
> are checking.
> There is an example:
>
> {code:java}
> gfsh>query --query="SELECT e.key, e.value from
> /example-region.entrySet e where e.value.positions['SUN'] LIKE
> '342234525745'"
> Result : true
> Limit : 100
> Rows: 1
> Query Trace : Query Executed in 9.082156 ms; indexesUsed(1):index1(Results: 1)
> gfsh>query --query="SELECT e.key, e.value from
> /example-region.entrySet e where e.value.positions['SUN'] LIKE
> '34223452574%'"
> Result : true
> Limit : 100
> Rows: 0
> Query Trace : Query Executed in 4.677162 ms; indexesUsed(1):index1(Results:
> 100)
> {code}
> As we are using indexes to have a better performance of executing a query it
> first need to check how many entries has that field which we are looking for.
> It stores it in index results and then check how many of them meet condition
> we defined in our query.
> The problem is that there is parameter INDEX_THRESHOLD_SIZE which default
> value is 100. If there is a lot of entries in the region it will write just
> first 100 entries that is found.
> This
[jira] [Updated] (GEODE-9632) Wrong output for the range query with wildcard character
[
https://issues.apache.org/jira/browse/GEODE-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo updated GEODE-9632:
--
Description:
We are using a range index on an attribute that is defined as HashMap.
The problem is when we are using wildcard character(%), there is no results for
the query despite of there are some entries that meet the condition we are
checking.
There is an example:
{code:java}
gfsh>query --query="SELECT e.key, e.value from /example-region.entrySet
e where e.value.positions['SUN'] LIKE '342234525745'"
Result : true
Limit : 100
Rows: 1
Query Trace : Query Executed in 9.082156 ms; indexesUsed(1):index1(Results: 1)
gfsh>query --query="SELECT e.key, e.value from /example-region.entrySet
e where e.value.positions['SUN'] LIKE '34223452574%'"
Result : true
Limit : 100
Rows: 0
Query Trace : Query Executed in 4.677162 ms; indexesUsed(1):index1(Results: 100)
{code}
As we are using indexes to have a better performance of executing a query it
first need to check how many entries has that field which we are looking for.
It stores it in index results and then check how many of them meet condition we
defined in our query.
The problem is that there is parameter INDEX_THRESHOLD_SIZE which default value
is 100. If there is a lot of entries in the region it will write just first 100
entries that is found.
This parameter can be changed while starting servers by adding
*-Dgemfire.Query.INDEX_THRESHOLD_SIZE=*, but if we set it to a higher
value than the limit is, it will overwrite it. So there should be some changes
to take this attribute into account.
was:
We are using a range index on an attribute that is defined as HashMap.
The problem is when we are using wildcard characters the Results field in
QueryTrace is 100, but should be 0 as there is no attribute with that value or
something similar.
There is an example:
{code:java}
gfsh>query --query="SELECT e.key, e.value from /example-region.entrySet
e where e.value.positions['SUN'] LIKE '342234525745'"
Result : true
Limit : 100
Rows : 1
Query Trace : Query Executed in 8.95536 ms; indexesUsed(1):index1(Results: 1)
gfsh>query --query="SELECT e.key, e.value from /example-region.entrySet
e where e.value.positions['SUN'] LIKE 'something%'"
Result : true
Limit : 100
Rows : 0
Query Trace : Query Executed in 17.171972 ms; indexesUsed(1):index1(Results:
100)
{code}
{color:#1d1c1d}When we are using it without range index we got this:{color}
{code:java}
gfsh>query --query="SELECT e.key, e.value from /example-region.entrySet
e where e.value.positions['SUN'] LIKE 'something%'"
Result : true
Limit : 100
Rows : 0
Query Trace : Query Executed in 14049.559 ms; indexesUsed(0){code}
> Wrong output for the range query with wildcard character
>
>
> Key: GEODE-9632
> URL: https://issues.apache.org/jira/browse/GEODE-9632
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
>
> We are using a range index on an attribute that is defined as HashMap.
> The problem is when we are using wildcard character(%), there is no results
> for the query despite of there are some entries that meet the condition we
> are checking.
> There is an example:
>
> {code:java}
> gfsh>query --query="SELECT e.key, e.value from
> /example-region.entrySet e where e.value.positions['SUN'] LIKE
> '342234525745'"
> Result : true
> Limit : 100
> Rows: 1
> Query Trace : Query Executed in 9.082156 ms; indexesUsed(1):index1(Results: 1)
> gfsh>query --query="SELECT e.key, e.value from
> /example-region.entrySet e where e.value.positions['SUN'] LIKE
> '34223452574%'"
> Result : true
> Limit : 100
> Rows: 0
> Query Trace : Query Executed in 4.677162 ms; indexesUsed(1):index1(Results:
> 100)
> {code}
> As we are using indexes to have a better performance of executing a query it
> first need to check how many entries has that field which we are looking for.
> It stores it in index results and then check how many of them meet condition
> we defined in our query.
> The problem is that there is parameter INDEX_THRESHOLD_SIZE which default
> value is 100. If there is a lot of entries in the region it will write just
> first 100 entries that is found.
> This parameter can be changed while starting servers by adding
> *-Dgemfire.Query.INDEX_THRESHOLD_SIZE=*, but if we set it to a higher
> value than the limit is, it will overwrite it. So there should be some
> changes to take this attribute into account.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9632) Wrong output for the range query with wildcard character
[
https://issues.apache.org/jira/browse/GEODE-9632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo reassigned GEODE-9632:
-
Assignee: Mario Kevo
> Wrong output for the range query with wildcard character
>
>
> Key: GEODE-9632
> URL: https://issues.apache.org/jira/browse/GEODE-9632
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
>
> We are using a range index on an attribute that is defined as HashMap.
> The problem is when we are using wildcard characters the Results field in
> QueryTrace is 100, but should be 0 as there is no attribute with that value
> or something similar.
> There is an example:
>
> {code:java}
> gfsh>query --query="SELECT e.key, e.value from
> /example-region.entrySet e where e.value.positions['SUN'] LIKE '342234525745'"
> Result : true
> Limit : 100
> Rows : 1
> Query Trace : Query Executed in 8.95536 ms; indexesUsed(1):index1(Results: 1)
> gfsh>query --query="SELECT e.key, e.value from
> /example-region.entrySet e where e.value.positions['SUN'] LIKE 'something%'"
> Result : true
> Limit : 100
> Rows : 0
> Query Trace : Query Executed in 17.171972 ms; indexesUsed(1):index1(Results:
> 100)
> {code}
>
> {color:#1d1c1d}When we are using it without range index we got this:{color}
> {code:java}
> gfsh>query --query="SELECT e.key, e.value from
> /example-region.entrySet e where e.value.positions['SUN'] LIKE 'something%'"
> Result : true
> Limit : 100
> Rows : 0
> Query Trace : Query Executed in 14049.559 ms; indexesUsed(0){code}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9632) Wrong output for the range query with wildcard character
Mario Kevo created GEODE-9632:
-
Summary: Wrong output for the range query with wildcard character
Key: GEODE-9632
URL: https://issues.apache.org/jira/browse/GEODE-9632
Project: Geode
Issue Type: Bug
Components: querying
Reporter: Mario Kevo
We are using a range index on an attribute that is defined as HashMap.
The problem is when we are using wildcard characters the Results field in
QueryTrace is 100, but should be 0 as there is no attribute with that value or
something similar.
There is an example:
{code:java}
gfsh>query --query="SELECT e.key, e.value from /example-region.entrySet
e where e.value.positions['SUN'] LIKE '342234525745'"
Result : true
Limit : 100
Rows : 1
Query Trace : Query Executed in 8.95536 ms; indexesUsed(1):index1(Results: 1)
gfsh>query --query="SELECT e.key, e.value from /example-region.entrySet
e where e.value.positions['SUN'] LIKE 'something%'"
Result : true
Limit : 100
Rows : 0
Query Trace : Query Executed in 17.171972 ms; indexesUsed(1):index1(Results:
100)
{code}
{color:#1d1c1d}When we are using it without range index we got this:{color}
{code:java}
gfsh>query --query="SELECT e.key, e.value from /example-region.entrySet
e where e.value.positions['SUN'] LIKE 'something%'"
Result : true
Limit : 100
Rows : 0
Query Trace : Query Executed in 14049.559 ms; indexesUsed(0){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9409) NullPointerException while create region during server restart
[
https://issues.apache.org/jira/browse/GEODE-9409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo resolved GEODE-9409.
---
Fix Version/s: 1.15.0
Resolution: Fixed
> NullPointerException while create region during server restart
> --
>
> Key: GEODE-9409
> URL: https://issues.apache.org/jira/browse/GEODE-9409
> Project: Geode
> Issue Type: Bug
> Components: gfsh, regions
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> If the "create region" command is executed while the Geode server is
> restarting it will fail with NullPointerException on that server.
> It happens for persistent regions as it tries to findDiskStore but in that
> method, it first tries to get PdxRegistry from the cache and create a
> persistent Region on that. But in that case, when the cache is creating(it
> takes some more time if the server is restarting), if the command is executed
> fast it happened that creating cache is not finished and pdxRegistry is null,
> so every method executed on that will throw NullPointerException.
>
> {code:java}
> gfsh>create region --name=/test_region2 --type=PARTITION_REDUNDANT_PERSISTENT
> --total-num-buckets=113 --disk-store=dataDiskStore
> --enable-synchronous-disk=false
> Member | Status | Message
> --- | -- |
> ---
> server1 | OK | Region "/test_region2" created on "server1"
> server2 | OK | Region "/test_region2" created on "server2"
> server3 | ERROR | java.lang.NullPointerException
> at
> org.apache.geode.internal.cache.LocalRegion.findDiskStore(LocalRegion.java:7498)
> at
> org.apache.geode.internal.cache.PartitionedRegion.findDiskStore(PartitionedRe..
> Cluster configuration for group 'cluster' is updated.
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9173) Bump Swagger2 to newer version
[ https://issues.apache.org/jira/browse/GEODE-9173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo reassigned GEODE-9173: - Assignee: (was: Mario Kevo) > Bump Swagger2 to newer version > -- > > Key: GEODE-9173 > URL: https://issues.apache.org/jira/browse/GEODE-9173 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Udo Kohlmeyer >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (GEODE-9409) NullPointerException while create region during server restart
[
https://issues.apache.org/jira/browse/GEODE-9409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo updated GEODE-9409:
--
Description:
If the "create region" command is executed while the Geode server is restarting
it will fail with NullPointerException on that server.
It happens for persistent regions as it tries to findDiskStore but in that
method, it first tries to get PdxRegistry from the cache and create a
persistent Region on that. But in that case, when the cache is creating(it
takes some more time if the server is restarting), if the command is executed
fast it happened that creating cache is not finished and pdxRegistry is null,
so every method executed on that will throw NullPointerException.
{code:java}
gfsh>create region --name=/test_region2 --type=PARTITION_REDUNDANT_PERSISTENT
--total-num-buckets=113 --disk-store=dataDiskStore
--enable-synchronous-disk=false
Member | Status | Message
--- | -- |
---
server1 | OK | Region "/test_region2" created on "server1"
server2 | OK | Region "/test_region2" created on "server2"
server3 | ERROR | java.lang.NullPointerException
at
org.apache.geode.internal.cache.LocalRegion.findDiskStore(LocalRegion.java:7498)
at
org.apache.geode.internal.cache.PartitionedRegion.findDiskStore(PartitionedRe..
Cluster configuration for group 'cluster' is updated.
{code}
was:
If the "create region" command is executed while the Geode server is starting
it will fail with NullPointerException on that server.
It happens for persistent regions as it tries to findDiskStore but in that
method, it first tries to get PdxRegistry from the cache and create a
persistent Region on that. But in that case, when the cache is creating, if the
command is executed fast it happened that creating cache is not finished and
pdxRegistry is null, so every method executed on that will throw
NulPointerException.
{code:java}
gfsh>create region --name=/test_region2 --type=PARTITION_REDUNDANT_PERSISTENT
--total-num-buckets=113 --disk-store=dataDiskStore
--enable-synchronous-disk=false
Member | Status | Message
--- | -- |
---
server1 | OK | Region "/test_region2" created on "server1"
server2 | OK | Region "/test_region2" created on "server2"
server3 | ERROR | java.lang.NullPointerException
at
org.apache.geode.internal.cache.LocalRegion.findDiskStore(LocalRegion.java:7498)
at
org.apache.geode.internal.cache.PartitionedRegion.findDiskStore(PartitionedRe..
Cluster configuration for group 'cluster' is updated.
{code}
> NullPointerException while create region during server restart
> --
>
> Key: GEODE-9409
> URL: https://issues.apache.org/jira/browse/GEODE-9409
> Project: Geode
> Issue Type: Bug
> Components: gfsh, regions
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
>
> If the "create region" command is executed while the Geode server is
> restarting it will fail with NullPointerException on that server.
> It happens for persistent regions as it tries to findDiskStore but in that
> method, it first tries to get PdxRegistry from the cache and create a
> persistent Region on that. But in that case, when the cache is creating(it
> takes some more time if the server is restarting), if the command is executed
> fast it happened that creating cache is not finished and pdxRegistry is null,
> so every method executed on that will throw NullPointerException.
>
> {code:java}
> gfsh>create region --name=/test_region2 --type=PARTITION_REDUNDANT_PERSISTENT
> --total-num-buckets=113 --disk-store=dataDiskStore
> --enable-synchronous-disk=false
> Member | Status | Message
> --- | -- |
> ---
> server1 | OK | Region "/test_region2" created on "server1"
> server2 | OK | Region "/test_region2" created on "server2"
> server3 | ERROR | java.lang.NullPointerException
> at
> org.apache.geode.internal.cache.LocalRegion.findDiskStore(LocalRegion.java:7498)
> at
> org.apache.geode.internal.cache.PartitionedRegion.findDiskStore(PartitionedRe..
> Cluster configuration for group 'cluster' is updated.
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9409) NullPointerException while create region during server restart
[
https://issues.apache.org/jira/browse/GEODE-9409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo updated GEODE-9409:
--
Summary: NullPointerException while create region during server restart
(was: NullPointerException while create region during server start)
> NullPointerException while create region during server restart
> --
>
> Key: GEODE-9409
> URL: https://issues.apache.org/jira/browse/GEODE-9409
> Project: Geode
> Issue Type: Bug
> Components: gfsh, regions
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
>
> If the "create region" command is executed while the Geode server is starting
> it will fail with NullPointerException on that server.
> It happens for persistent regions as it tries to findDiskStore but in that
> method, it first tries to get PdxRegistry from the cache and create a
> persistent Region on that. But in that case, when the cache is creating, if
> the command is executed fast it happened that creating cache is not finished
> and pdxRegistry is null, so every method executed on that will throw
> NulPointerException.
>
> {code:java}
> gfsh>create region --name=/test_region2 --type=PARTITION_REDUNDANT_PERSISTENT
> --total-num-buckets=113 --disk-store=dataDiskStore
> --enable-synchronous-disk=false
> Member | Status | Message
> --- | -- |
> ---
> server1 | OK | Region "/test_region2" created on "server1"
> server2 | OK | Region "/test_region2" created on "server2"
> server3 | ERROR | java.lang.NullPointerException
> at
> org.apache.geode.internal.cache.LocalRegion.findDiskStore(LocalRegion.java:7498)
> at
> org.apache.geode.internal.cache.PartitionedRegion.findDiskStore(PartitionedRe..
> Cluster configuration for group 'cluster' is updated.
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9409) NullPointerException while create region during server start
[
https://issues.apache.org/jira/browse/GEODE-9409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo reassigned GEODE-9409:
-
Assignee: Mario Kevo
> NullPointerException while create region during server start
>
>
> Key: GEODE-9409
> URL: https://issues.apache.org/jira/browse/GEODE-9409
> Project: Geode
> Issue Type: Bug
> Components: gfsh, regions
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
>
> If the "create region" command is executed while the Geode server is starting
> it will fail with NullPointerException on that server.
> It happens for persistent regions as it tries to findDiskStore but in that
> method, it first tries to get PdxRegistry from the cache and create a
> persistent Region on that. But in that case, when the cache is creating, if
> the command is executed fast it happened that creating cache is not finished
> and pdxRegistry is null, so every method executed on that will throw
> NulPointerException.
>
> {code:java}
> gfsh>create region --name=/test_region2 --type=PARTITION_REDUNDANT_PERSISTENT
> --total-num-buckets=113 --disk-store=dataDiskStore
> --enable-synchronous-disk=false
> Member | Status | Message
> --- | -- |
> ---
> server1 | OK | Region "/test_region2" created on "server1"
> server2 | OK | Region "/test_region2" created on "server2"
> server3 | ERROR | java.lang.NullPointerException
> at
> org.apache.geode.internal.cache.LocalRegion.findDiskStore(LocalRegion.java:7498)
> at
> org.apache.geode.internal.cache.PartitionedRegion.findDiskStore(PartitionedRe..
> Cluster configuration for group 'cluster' is updated.
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9409) NullPointerException while create region during server start
Mario Kevo created GEODE-9409:
-
Summary: NullPointerException while create region during server
start
Key: GEODE-9409
URL: https://issues.apache.org/jira/browse/GEODE-9409
Project: Geode
Issue Type: Bug
Components: gfsh, regions
Reporter: Mario Kevo
If the "create region" command is executed while the Geode server is starting
it will fail with NullPointerException on that server.
It happens for persistent regions as it tries to findDiskStore but in that
method, it first tries to get PdxRegistry from the cache and create a
persistent Region on that. But in that case, when the cache is creating, if the
command is executed fast it happened that creating cache is not finished and
pdxRegistry is null, so every method executed on that will throw
NulPointerException.
{code:java}
gfsh>create region --name=/test_region2 --type=PARTITION_REDUNDANT_PERSISTENT
--total-num-buckets=113 --disk-store=dataDiskStore
--enable-synchronous-disk=false
Member | Status | Message
--- | -- |
---
server1 | OK | Region "/test_region2" created on "server1"
server2 | OK | Region "/test_region2" created on "server2"
server3 | ERROR | java.lang.NullPointerException
at
org.apache.geode.internal.cache.LocalRegion.findDiskStore(LocalRegion.java:7498)
at
org.apache.geode.internal.cache.PartitionedRegion.findDiskStore(PartitionedRe..
Cluster configuration for group 'cluster' is updated.
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-9281) No results for the query with multiple indexes used
[
https://issues.apache.org/jira/browse/GEODE-9281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo resolved GEODE-9281.
---
Fix Version/s: 1.15.0
Resolution: Fixed
> No results for the query with multiple indexes used
> ---
>
> Key: GEODE-9281
> URL: https://issues.apache.org/jira/browse/GEODE-9281
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> While running a basic query which is using 2 indexes, there are no results
> displayed.
> {code:java}
> gfsh>query --query="SELECT value FROM /example-region.entrySet WHERE
> value.ExpiredTime >= 0 AND value.ExpiredTime < 1719592199000L AND
> (value.status = 'SUSPENDED' or value.status = 'REGISTERED')"
> Result : true
> Limit : 100
> Rows : 0
> Query Trace : Query Executed in 29.131016 ms;
> indexesUsed(2):ExpiredTimeIndex(Results: 500),StatusIndex(Results: 250){code}
> While using just one index it works correctly.
> {code:java}
> gfsh>query --query="SELECT value FROM /example-region.entrySet WHERE
> value.ExpiredTime >= 0 AND value.ExpiredTime < 1719592199000L"
> Result : true
> Limit : 100
> Rows : 100
> Query Trace : Query Executed in 15.422983 ms;
> indexesUsed(1):ExpiredTimeIndex(Results: 500){code}
>
> Steps to reproduce the issue:
> # start locator --name=locator1
> # configure pdx --read-serialized=true --disk-store
> # start server --name=server1 --server-port=0
> # start server --name=server2 --server-port=0
> # create region --name=example-region --type=PARTITION_PERSISTENT
> --redundant-copies=1
> # put entries
> # create index --name=ExpiredTimeIndex --expression=value.ExpiredTime
> --region="/example-region.entrySet" --type=range
> # create index --name=StatusIndex --expression=value.Status
> --region="/example-region.entrySet" --type=range
> # query --query="SELECT value FROM /example-region.entrySet WHERE
> value.ExpiredTime >= 0 AND value.ExpiredTime < 1719592199000L AND
> (value.Status = 'SUSPENDED' or value.Status = 'REGISTERED')"
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9281) No results for the query with multiple indexes used
[
https://issues.apache.org/jira/browse/GEODE-9281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo updated GEODE-9281:
--
Description:
While running a basic query which is using 2 indexes, there are no results
displayed.
{code:java}
gfsh>query --query="SELECT value FROM /example-region.entrySet WHERE
value.ExpiredTime >= 0 AND value.ExpiredTime < 1719592199000L AND (value.status
= 'SUSPENDED' or value.status = 'REGISTERED')"
Result : true
Limit : 100
Rows : 0
Query Trace : Query Executed in 29.131016 ms;
indexesUsed(2):ExpiredTimeIndex(Results: 500),StatusIndex(Results: 250){code}
While using just one index it works correctly.
{code:java}
gfsh>query --query="SELECT value FROM /example-region.entrySet WHERE
value.ExpiredTime >= 0 AND value.ExpiredTime < 1719592199000L"
Result : true
Limit : 100
Rows : 100
Query Trace : Query Executed in 15.422983 ms;
indexesUsed(1):ExpiredTimeIndex(Results: 500){code}
Steps to reproduce the issue:
# start locator --name=locator1
# configure pdx --read-serialized=true --disk-store
# start server --name=server1 --server-port=0
# start server --name=server2 --server-port=0
# create region --name=example-region --type=PARTITION_PERSISTENT
--redundant-copies=1
# put entries
# create index --name=ExpiredTimeIndex --expression=value.ExpiredTime
--region="/example-region.entrySet" --type=range
# create index --name=StatusIndex --expression=value.Status
--region="/example-region.entrySet" --type=range
# query --query="SELECT value FROM /example-region.entrySet WHERE
value.ExpiredTime >= 0 AND value.ExpiredTime < 1719592199000L AND (value.Status
= 'SUSPENDED' or value.Status = 'REGISTERED')"
was:
While running a basic query which is using 2 indexes, there are no results
displayed.
{code:java}
gfsh>query --query="SELECT value FROM /example-region.entrySet WHERE
value.ExpiredTime >= 0 AND value.ExpiredTime < 1719592199000L AND (value.status
= 'SUSPENDED' or value.status = 'REGISTERED')"
Result : true
Limit : 100
Rows : 0
Query Trace : Query Executed in 29.131016 ms;
indexesUsed(2):ExpiredTimeIndex(Results: 500),StatusIndex(Results: 250){code}
While using just one index it works correctly.
{code:java}
gfsh>query --query="SELECT value FROM /example-region.entrySet WHERE
value.ExpiredTime >= 0 AND value.ExpiredTime < 1719592199000L"
Result : true
Limit : 100
Rows : 100
Query Trace : Query Executed in 15.422983 ms;
indexesUsed(1):ExpiredTimeIndex(Results: 500){code}
> No results for the query with multiple indexes used
> ---
>
> Key: GEODE-9281
> URL: https://issues.apache.org/jira/browse/GEODE-9281
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
>
> While running a basic query which is using 2 indexes, there are no results
> displayed.
> {code:java}
> gfsh>query --query="SELECT value FROM /example-region.entrySet WHERE
> value.ExpiredTime >= 0 AND value.ExpiredTime < 1719592199000L AND
> (value.status = 'SUSPENDED' or value.status = 'REGISTERED')"
> Result : true
> Limit : 100
> Rows : 0
> Query Trace : Query Executed in 29.131016 ms;
> indexesUsed(2):ExpiredTimeIndex(Results: 500),StatusIndex(Results: 250){code}
> While using just one index it works correctly.
> {code:java}
> gfsh>query --query="SELECT value FROM /example-region.entrySet WHERE
> value.ExpiredTime >= 0 AND value.ExpiredTime < 1719592199000L"
> Result : true
> Limit : 100
> Rows : 100
> Query Trace : Query Executed in 15.422983 ms;
> indexesUsed(1):ExpiredTimeIndex(Results: 500){code}
>
> Steps to reproduce the issue:
> # start locator --name=locator1
> # configure pdx --read-serialized=true --disk-store
> # start server --name=server1 --server-port=0
> # start server --name=server2 --server-port=0
> # create region --name=example-region --type=PARTITION_PERSISTENT
> --redundant-copies=1
> # put entries
> # create index --name=ExpiredTimeIndex --expression=value.ExpiredTime
> --region="/example-region.entrySet" --type=range
> # create index --name=StatusIndex --expression=value.Status
> --region="/example-region.entrySet" --type=range
> # query --query="SELECT value FROM /example-region.entrySet WHERE
> value.ExpiredTime >= 0 AND value.ExpiredTime < 1719592199000L AND
> (value.Status = 'SUSPENDED' or value.Status = 'REGISTERED')"
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9281) No results for the query with multiple indexes used
[
https://issues.apache.org/jira/browse/GEODE-9281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo reassigned GEODE-9281:
-
Assignee: Mario Kevo
> No results for the query with multiple indexes used
> ---
>
> Key: GEODE-9281
> URL: https://issues.apache.org/jira/browse/GEODE-9281
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
>
> While running a basic query which is using 2 indexes, there are no results
> displayed.
> {code:java}
> gfsh>query --query="SELECT value FROM /example-region.entrySet WHERE
> value.ExpiredTime >= 0 AND value.ExpiredTime < 1719592199000L AND
> (value.status = 'SUSPENDED' or value.status = 'REGISTERED')"
> Result : true
> Limit : 100
> Rows : 0
> Query Trace : Query Executed in 29.131016 ms;
> indexesUsed(2):ExpiredTimeIndex(Results: 500),StatusIndex(Results: 250){code}
> While using just one index it works correctly.
> {code:java}
> gfsh>query --query="SELECT value FROM /example-region.entrySet WHERE
> value.ExpiredTime >= 0 AND value.ExpiredTime < 1719592199000L"
> Result : true
> Limit : 100
> Rows : 100
> Query Trace : Query Executed in 15.422983 ms;
> indexesUsed(1):ExpiredTimeIndex(Results: 500){code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9281) No results for the query with multiple indexes used
Mario Kevo created GEODE-9281:
-
Summary: No results for the query with multiple indexes used
Key: GEODE-9281
URL: https://issues.apache.org/jira/browse/GEODE-9281
Project: Geode
Issue Type: Bug
Components: querying
Reporter: Mario Kevo
While running a basic query which is using 2 indexes, there are no results
displayed.
{code:java}
gfsh>query --query="SELECT value FROM /example-region.entrySet WHERE
value.ExpiredTime >= 0 AND value.ExpiredTime < 1719592199000L AND (value.status
= 'SUSPENDED' or value.status = 'REGISTERED')"
Result : true
Limit : 100
Rows : 0
Query Trace : Query Executed in 29.131016 ms;
indexesUsed(2):ExpiredTimeIndex(Results: 500),StatusIndex(Results: 250){code}
While using just one index it works correctly.
{code:java}
gfsh>query --query="SELECT value FROM /example-region.entrySet WHERE
value.ExpiredTime >= 0 AND value.ExpiredTime < 1719592199000L"
Result : true
Limit : 100
Rows : 100
Query Trace : Query Executed in 15.422983 ms;
indexesUsed(1):ExpiredTimeIndex(Results: 500){code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9173) Bump Swagger2 to newer version
[ https://issues.apache.org/jira/browse/GEODE-9173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mario Kevo reassigned GEODE-9173: - Assignee: Mario Kevo > Bump Swagger2 to newer version > -- > > Key: GEODE-9173 > URL: https://issues.apache.org/jira/browse/GEODE-9173 > Project: Geode > Issue Type: Improvement > Components: management >Reporter: Udo Kohlmeyer >Assignee: Mario Kevo >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (GEODE-9174) The result of a gfsh query containing a UUID may not be displayed properly
[
https://issues.apache.org/jira/browse/GEODE-9174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo resolved GEODE-9174.
---
Fix Version/s: 1.15.0
Resolution: Fixed
> The result of a gfsh query containing a UUID may not be displayed properly
> --
>
> Key: GEODE-9174
> URL: https://issues.apache.org/jira/browse/GEODE-9174
> Project: Geode
> Issue Type: Bug
> Components: gfsh, querying
>Reporter: Barrett Oglesby
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> For example, if the key is a UUID, then a query like this won't show the
> results even though there is one:
> {noformat}
> gfsh>query --query="select key from /data.entries where value.id =
> '55e907b6-a1fe-42ea-90a2-6a5698e9b27c'"
> Result : true
> Limit : 100
> Rows : 1
> {noformat}
> But a query like this will:
> {noformat}
> gfsh>query --query="select key,value from /data.entries where value.id =
> '55e907b6-a1fe-42ea-90a2-6a5698e9b27c'"
> Result : true
> Limit : 100
> Rows : 1
> key | value
> -- |
> ---
> "55e907b6-a1fe-42ea-90a2-6a5698e9b27c" |
> {"id":"55e907b6-a1fe-42ea-90a2-6a5698e9b27c","cusip":"AAPL","shares":22,"price":352.32}
> {noformat}
> Thats because of the way {{DataCommandResult.resolveObjectToColumns}} works.
> {noformat}
> private void resolveObjectToColumns(Map columnData, Object
> value) {
> if (value instanceof PdxInstance) {
> resolvePdxToColumns(columnData, (PdxInstance) value);
> } else if (value instanceof Struct) {
> resolveStructToColumns(columnData, (StructImpl) value);
> } else {
> ObjectMapper mapper = new ObjectMapper();
> JsonNode node = mapper.valueToTree(value);
> node.fieldNames().forEachRemaining(field -> {
> ...
> columnData.put(field, mapper.writeValueAsString(node.get(field)));
> });
> }
> }
> {noformat}
> The value in the first query is a {{UUID}} so the last else clause is
> invoked. In this case, a {{JsonNode}} is used to determine the columns.
> {{ObjectMapper.valueToTree}} converts a {{UUID}} to a {{TextNode}}.
> {{TextNodes}} have no fieldNames, and {{JsonNode.fieldNames}} returns an
> {{EmptyIterator}} by default:
> {noformat}
> public Iterator fieldNames() {
> return ClassUtil.emptyIterator();
> }
> {noformat}
> So, {{resolveObjectToColumns}} doesn't fill in columnData, which causes the
> {{DataCommandResult.buildTable}} in the locator to not add any rows to the
> table.
> The value in the second query is a {{Struct}} so the second else clause is
> invoked. The {{resolveStructToColumns}} method does:
> {noformat}
> private void resolveStructToColumns(Map columnData,
> StructImpl struct) {
> for (String field : struct.getFieldNames()) {
> columnData.put(field, valueToJson(struct.get(field)));
> }
> }
> {noformat}
> I'm not sure if there is a way to make {{ObjectMapper.valueToTree}} handle
> {{UUIDs}} differently, but they can easily be special-cased like
> {{PdxInstances}} and {{Structs}}:
> {noformat}
> } else if (value instanceof UUID) {
> columnData.put("uuid", valueToJson(value));
> {noformat}
> I'm not sure if this is the best solution, but it works. With this clause
> added, the query does:
> {noformat}
> gfsh>query --query="select key from /data.entries where value.id =
> '55e907b6-a1fe-42ea-90a2-6a5698e9b27c'"
> Result : true
> Limit : 100
> Rows : 1
> uuid
> --
> "55e907b6-a1fe-42ea-90a2-6a5698e9b27c"
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9174) The result of a gfsh query containing a UUID may not be displayed properly
[
https://issues.apache.org/jira/browse/GEODE-9174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo reassigned GEODE-9174:
-
Assignee: Mario Kevo
> The result of a gfsh query containing a UUID may not be displayed properly
> --
>
> Key: GEODE-9174
> URL: https://issues.apache.org/jira/browse/GEODE-9174
> Project: Geode
> Issue Type: Bug
> Components: gfsh, querying
>Reporter: Barrett Oglesby
>Assignee: Mario Kevo
>Priority: Major
>
> For example, if the key is a UUID, then a query like this won't show the
> results even though there is one:
> {noformat}
> gfsh>query --query="select key from /data.entries where value.id =
> '55e907b6-a1fe-42ea-90a2-6a5698e9b27c'"
> Result : true
> Limit : 100
> Rows : 1
> {noformat}
> But a query like this will:
> {noformat}
> gfsh>query --query="select key,value from /data.entries where value.id =
> '55e907b6-a1fe-42ea-90a2-6a5698e9b27c'"
> Result : true
> Limit : 100
> Rows : 1
> key | value
> -- |
> ---
> "55e907b6-a1fe-42ea-90a2-6a5698e9b27c" |
> {"id":"55e907b6-a1fe-42ea-90a2-6a5698e9b27c","cusip":"AAPL","shares":22,"price":352.32}
> {noformat}
> Thats because of the way {{DataCommandResult.resolveObjectToColumns}} works.
> {noformat}
> private void resolveObjectToColumns(Map columnData, Object
> value) {
> if (value instanceof PdxInstance) {
> resolvePdxToColumns(columnData, (PdxInstance) value);
> } else if (value instanceof Struct) {
> resolveStructToColumns(columnData, (StructImpl) value);
> } else {
> ObjectMapper mapper = new ObjectMapper();
> JsonNode node = mapper.valueToTree(value);
> node.fieldNames().forEachRemaining(field -> {
> ...
> columnData.put(field, mapper.writeValueAsString(node.get(field)));
> });
> }
> }
> {noformat}
> The value in the first query is a {{UUID}} so the last else clause is
> invoked. In this case, a {{JsonNode}} is used to determine the columns.
> {{ObjectMapper.valueToTree}} converts a {{UUID}} to a {{TextNode}}.
> {{TextNodes}} have no fieldNames, and {{JsonNode.fieldNames}} returns an
> {{EmptyIterator}} by default:
> {noformat}
> public Iterator fieldNames() {
> return ClassUtil.emptyIterator();
> }
> {noformat}
> So, {{resolveObjectToColumns}} doesn't fill in columnData, which causes the
> {{DataCommandResult.buildTable}} in the locator to not add any rows to the
> table.
> The value in the second query is a {{Struct}} so the second else clause is
> invoked. The {{resolveStructToColumns}} method does:
> {noformat}
> private void resolveStructToColumns(Map columnData,
> StructImpl struct) {
> for (String field : struct.getFieldNames()) {
> columnData.put(field, valueToJson(struct.get(field)));
> }
> }
> {noformat}
> I'm not sure if there is a way to make {{ObjectMapper.valueToTree}} handle
> {{UUIDs}} differently, but they can easily be special-cased like
> {{PdxInstances}} and {{Structs}}:
> {noformat}
> } else if (value instanceof UUID) {
> columnData.put("uuid", valueToJson(value));
> {noformat}
> I'm not sure if this is the best solution, but it works. With this clause
> added, the query does:
> {noformat}
> gfsh>query --query="select key from /data.entries where value.id =
> '55e907b6-a1fe-42ea-90a2-6a5698e9b27c'"
> Result : true
> Limit : 100
> Rows : 1
> uuid
> --
> "55e907b6-a1fe-42ea-90a2-6a5698e9b27c"
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9101) Attribute VisibleNodes in MemberMXBean is incorrect
[
https://issues.apache.org/jira/browse/GEODE-9101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo updated GEODE-9101:
--
Labels: needs-review pull-request-available (was: pull-request-available)
> Attribute VisibleNodes in MemberMXBean is incorrect
> ---
>
> Key: GEODE-9101
> URL: https://issues.apache.org/jira/browse/GEODE-9101
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: needs-review, pull-request-available
>
> In documentation states:
> _The current number of nodes in this distributed system visible to this
> member._
> But checking the value of the attribute we have a difference between locator
> and server.
> For example, we have the following system:
> {code:java}
>
> gfsh>list members
> Member Count : 4
> Name | Id
> | -
> locator1 | 192.168.0.145(locator1:26377:locator):41000 [Coordinator]
> locator2 | 192.168.0.145(locator2:26509:locator):41001
> server1 | 192.168.0.145(server1:26648):41002
> server2 | 192.168.0.145(server2:26768):41003
>
> {code}
>
> For locators visibleNodes = 2, but for servers visibleNodes = 3.
> Locators see only servers as visible nodes(In this case it sees *server1* and
> *server2*).
> Servers see first locator and all servers, including itself(In this case
> server1 sees *locator1*, *server1* and *server2*).
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9101) Attribute VisibleNodes in MemberMXBean is incorrect
[
https://issues.apache.org/jira/browse/GEODE-9101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo updated GEODE-9101:
--
Description:
In documentation states:
_The current number of nodes in this distributed system visible to this member._
But checking the value of the attribute we have a difference between locator
and server.
For example, we have the following system:
{code:java}
gfsh>list members
Member Count : 4
Name | Id
| -
locator1 | 192.168.0.145(locator1:26377:locator):41000 [Coordinator]
locator2 | 192.168.0.145(locator2:26509:locator):41001
server1 | 192.168.0.145(server1:26648):41002
server2 | 192.168.0.145(server2:26768):41003
{code}
For locators visibleNodes = 2, but for servers visibleNodes = 3.
Locators see only servers as visible nodes(In this case it sees *server1* and
*server2*).
Servers see first locator and all servers, including itself(In this case
server1 sees *locator1*, *server1* and *server2*).
was:
In documentation states:
_The current number of nodes in this distributed system visible to this member._
But checking the value of the attribute we have a difference between locator
and server.
For example, we have the following system:
{code:java}
gfsh>list members
Member Count : 4
Name | Id
| -
locator1 | 192.168.0.145(locator1:26377:locator):41000 [Coordinator]
locator2 | 192.168.0.145(locator2:26509:locator):41001
server1 | 192.168.0.145(server1:26648):41002
server2 | 192.168.0.145(server2:26768):41003
{code}
For locators visibleNodes = 2, but for servers visibleNodes = 3.
Locators see only servers as visible nodes(In this case it sees *server1* and
*server2*).
Servers see first locator and all servers, including himself(In this case
server1 sees *locator1*, *server1* and *server2*).
> Attribute VisibleNodes in MemberMXBean is incorrect
> ---
>
> Key: GEODE-9101
> URL: https://issues.apache.org/jira/browse/GEODE-9101
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
>
> In documentation states:
> _The current number of nodes in this distributed system visible to this
> member._
> But checking the value of the attribute we have a difference between locator
> and server.
> For example, we have the following system:
> {code:java}
>
> gfsh>list members
> Member Count : 4
> Name | Id
> | -
> locator1 | 192.168.0.145(locator1:26377:locator):41000 [Coordinator]
> locator2 | 192.168.0.145(locator2:26509:locator):41001
> server1 | 192.168.0.145(server1:26648):41002
> server2 | 192.168.0.145(server2:26768):41003
>
> {code}
>
> For locators visibleNodes = 2, but for servers visibleNodes = 3.
> Locators see only servers as visible nodes(In this case it sees *server1* and
> *server2*).
> Servers see first locator and all servers, including itself(In this case
> server1 sees *locator1*, *server1* and *server2*).
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-9101) Attribute VisibleNodes in MemberMXBean is incorrect
[
https://issues.apache.org/jira/browse/GEODE-9101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo reassigned GEODE-9101:
-
Assignee: Mario Kevo
> Attribute VisibleNodes in MemberMXBean is incorrect
> ---
>
> Key: GEODE-9101
> URL: https://issues.apache.org/jira/browse/GEODE-9101
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
>
> In documentation states:
> _The current number of nodes in this distributed system visible to this
> member._
> But checking the value of the attribute we have a difference between locator
> and server.
> For example, we have the following system:
> {code:java}
>
> gfsh>list members
> Member Count : 4
> Name | Id
> | -
> locator1 | 192.168.0.145(locator1:26377:locator):41000 [Coordinator]
> locator2 | 192.168.0.145(locator2:26509:locator):41001
> server1 | 192.168.0.145(server1:26648):41002
> server2 | 192.168.0.145(server2:26768):41003
>
> {code}
>
> For locators visibleNodes = 2, but for servers visibleNodes = 3.
> Locators see only servers as visible nodes(In this case it sees *server1* and
> *server2*).
> Servers see first locator and all servers, including himself(In this case
> server1 sees *locator1*, *server1* and *server2*).
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (GEODE-9101) Attribute VisibleNodes in MemberMXBean is incorrect
[
https://issues.apache.org/jira/browse/GEODE-9101?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo updated GEODE-9101:
--
Description:
In documentation states:
_The current number of nodes in this distributed system visible to this member._
But checking the value of the attribute we have a difference between locator
and server.
For example, we have the following system:
{code:java}
gfsh>list members
Member Count : 4
Name | Id
| -
locator1 | 192.168.0.145(locator1:26377:locator):41000 [Coordinator]
locator2 | 192.168.0.145(locator2:26509:locator):41001
server1 | 192.168.0.145(server1:26648):41002
server2 | 192.168.0.145(server2:26768):41003
{code}
For locators visibleNodes = 2, but for servers visibleNodes = 3.
Locators see only servers as visible nodes(In this case it sees *server1* and
*server2*).
Servers see first locator and all servers, including himself(In this case
server1 sees *locator1*, *server1* and *server2*).
was:
In documentation states:
_The current number of nodes in this distributed system visible to this member._
But checking the value of the attribute we have a difference between locator
and server.
For example, we have the following system:
{code:java}
gfsh>list members
Member Count : 4
Name | Id
| -
locator1 | 192.168.0.145(locator1:26377:locator):41000 [Coordinator]
locator2 | 192.168.0.145(locator2:26509:locator):41001
server1 | 192.168.0.145(server1:26648):41002
server2 | 192.168.0.145(server2:26768):41003
{code}
For locators visibleNodes = 2, but for servers visibleNodes = 3.
> Attribute VisibleNodes in MemberMXBean is incorrect
> ---
>
> Key: GEODE-9101
> URL: https://issues.apache.org/jira/browse/GEODE-9101
> Project: Geode
> Issue Type: Bug
> Components: statistics
>Reporter: Mario Kevo
>Priority: Major
>
> In documentation states:
> _The current number of nodes in this distributed system visible to this
> member._
> But checking the value of the attribute we have a difference between locator
> and server.
> For example, we have the following system:
> {code:java}
>
> gfsh>list members
> Member Count : 4
> Name | Id
> | -
> locator1 | 192.168.0.145(locator1:26377:locator):41000 [Coordinator]
> locator2 | 192.168.0.145(locator2:26509:locator):41001
> server1 | 192.168.0.145(server1:26648):41002
> server2 | 192.168.0.145(server2:26768):41003
>
> {code}
>
> For locators visibleNodes = 2, but for servers visibleNodes = 3.
> Locators see only servers as visible nodes(In this case it sees *server1* and
> *server2*).
> Servers see first locator and all servers, including himself(In this case
> server1 sees *locator1*, *server1* and *server2*).
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-9101) Attribute VisibleNodes in MemberMXBean is incorrect
Mario Kevo created GEODE-9101:
-
Summary: Attribute VisibleNodes in MemberMXBean is incorrect
Key: GEODE-9101
URL: https://issues.apache.org/jira/browse/GEODE-9101
Project: Geode
Issue Type: Bug
Components: statistics
Reporter: Mario Kevo
In documentation states:
_The current number of nodes in this distributed system visible to this member._
But checking the value of the attribute we have a difference between locator
and server.
For example, we have the following system:
{code:java}
gfsh>list members
Member Count : 4
Name | Id
| -
locator1 | 192.168.0.145(locator1:26377:locator):41000 [Coordinator]
locator2 | 192.168.0.145(locator2:26509:locator):41001
server1 | 192.168.0.145(server1:26648):41002
server2 | 192.168.0.145(server2:26768):41003
{code}
For locators visibleNodes = 2, but for servers visibleNodes = 3.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8918) Geode replication event forwarding does not honor GW sender state
[
https://issues.apache.org/jira/browse/GEODE-8918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo resolved GEODE-8918.
---
Fix Version/s: 1.15.0
Resolution: Fixed
> Geode replication event forwarding does not honor GW sender state
> -
>
> Key: GEODE-8918
> URL: https://issues.apache.org/jira/browse/GEODE-8918
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> {color:#172b4d}With 3+ geo-red systems Geode replication has the forwarding
> feature which means that receiving cluster will forward the event it just got
> to all clusters it is connected to that have not yet received the
> event.{color}
> {color:#172b4d}This is possible because the originating cluster is setting
> metadata in the replication event like this:
> GatewaySenderEventCallbackArgument
> [originalCallbackArg=null;originatingSenderId=1;recipientGatewayReceivers=
> {color}{color:#172b4d}{3, 2}{color}{color:#172b4d}]
>
> Site receiving this event thus knows which is the originating site and which
> sites should have received this event. All others will have this event
> forwarded to. All this is legacy Geode behavior.
>
> However, originating site does not care if GW sender to a destination is
> stopped or not - only the fact GW sender is *created and attached* to a
> region is enough. This means if e.g. GW sender from Site1 to Site 3 is
> stopped (and has been stopped for a while - so this has nothing to do with
> timing) at the moment an event hits the replication it is only going to be
> sent to Site 2 *but with the same metadata*_._ Hence Site 2 will not forward
> to Site 3 (assuming it has a connection to it).{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8955) WAN location service uses DistributedLocatorId.toString() to represent a locator
[
https://issues.apache.org/jira/browse/GEODE-8955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo resolved GEODE-8955.
---
Fix Version/s: 1.15.0
Resolution: Fixed
> WAN location service uses DistributedLocatorId.toString() to represent a
> locator
>
>
> Key: GEODE-8955
> URL: https://issues.apache.org/jira/browse/GEODE-8955
> Project: Geode
> Issue Type: Improvement
> Components: wan
>Reporter: Bruce J Schuchardt
>Assignee: Mario Kevo
>Priority: Minor
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> This code in LocatorHelper, and probably code in other parts of the WAN
> location service, uses DistributionLocatorId.toString() to track whether
> other locators have the WAN location service available. It should use the
> DistributionLocatorId.marshal() method instead. We should never use the
> toString() representation of an object in this way as it may change over time.
>
> {code:java}
> private static void addServerLocator(Integer distributedSystemId,
> LocatorMembershipListener locatorListener, DistributionLocatorId locator)
> {
> ConcurrentHashMap> allServerLocatorsInfo =
> (ConcurrentHashMap>)
> locatorListener.getAllServerLocatorsInfo();
> Set locatorsSet = new CopyOnWriteHashSet();
> locatorsSet.add(locator.toString());
> Set existingValue =
> allServerLocatorsInfo.putIfAbsent(distributedSystemId, locatorsSet);
> if (existingValue != null) {
> if (!existingValue.contains(locator.toString())) {
> existingValue.add(locator.toString());
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8962) Not possible to escape "$" character in query using LIKE operator
[
https://issues.apache.org/jira/browse/GEODE-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo resolved GEODE-8962.
---
Fix Version/s: 1.15.0
Resolution: Fixed
> Not possible to escape "$" character in query using LIKE operator
> -
>
> Key: GEODE-8962
> URL: https://issues.apache.org/jira/browse/GEODE-8962
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.15.0
>
>
> {color:#00}If one query tries to match a string containg "$" character by
> a "=" or a "contains" operation, it works, and if data contains a "$"
> character and expression of query looks for it, works as expected.{color}
> {color:#172b4d} {color}
>
> {code:java}
> gfsh>query --query="select e.key from /example-region.entrySet e where
> e.key='aa$b'"
> Result : true
> Limit : 100
> Rows : 1
> Result
> --
> aa$b{code}
>
>
> {color:#00}But if we replace the "=" operator in the Geode query by a
> "LIKE" operator, and a wildcard is added, then it seems the regular
> expression mode is somehow triggered and the "$" character starts behaving
> like endline character. That is expected. {color}{color:#172b4d}
> {color}
> {color:#172b4d} {color}
>
> {code:java}
> gfsh>query --query="select e.key from /example-region.entrySet e where e.key
> like 'aa$b'"
> Result : true
> Limit : 100
> Rows : 0
> {code}
>
>
> {color:#00}There is no way to escape "$" character.{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8955) WAN location service uses DistributedLocatorId.toString() to represent a locator
[
https://issues.apache.org/jira/browse/GEODE-8955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo reassigned GEODE-8955:
-
Assignee: Mario Kevo
> WAN location service uses DistributedLocatorId.toString() to represent a
> locator
>
>
> Key: GEODE-8955
> URL: https://issues.apache.org/jira/browse/GEODE-8955
> Project: Geode
> Issue Type: Improvement
> Components: wan
>Reporter: Bruce J Schuchardt
>Assignee: Mario Kevo
>Priority: Minor
>
> This code in LocatorHelper, and probably code in other parts of the WAN
> location service, uses DistributionLocatorId.toString() to track whether
> other locators have the WAN location service available. It should use the
> DistributionLocatorId.marshal() method instead. We should never use the
> toString() representation of an object in this way as it may change over time.
>
> {code:java}
> private static void addServerLocator(Integer distributedSystemId,
> LocatorMembershipListener locatorListener, DistributionLocatorId locator)
> {
> ConcurrentHashMap> allServerLocatorsInfo =
> (ConcurrentHashMap>)
> locatorListener.getAllServerLocatorsInfo();
> Set locatorsSet = new CopyOnWriteHashSet();
> locatorsSet.add(locator.toString());
> Set existingValue =
> allServerLocatorsInfo.putIfAbsent(distributedSystemId, locatorsSet);
> if (existingValue != null) {
> if (!existingValue.contains(locator.toString())) {
> existingValue.add(locator.toString());
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8962) Not possible to escape "$" character in query using LIKE operator
[
https://issues.apache.org/jira/browse/GEODE-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo reassigned GEODE-8962:
-
Assignee: Mario Kevo
> Not possible to escape "$" character in query using LIKE operator
> -
>
> Key: GEODE-8962
> URL: https://issues.apache.org/jira/browse/GEODE-8962
> Project: Geode
> Issue Type: Bug
> Components: querying
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
>
> {color:#00}If one query tries to match a string containg "$" character by
> a "=" or a "contains" operation, it works, and if data contains a "$"
> character and expression of query looks for it, works as expected.{color}
> {color:#172b4d} {color}
>
> {code:java}
> gfsh>query --query="select e.key from /example-region.entrySet e where
> e.key='aa$b'"
> Result : true
> Limit : 100
> Rows : 1
> Result
> --
> aa$b{code}
>
>
> {color:#00}But if we replace the "=" operator in the Geode query by a
> "LIKE" operator, and a wildcard is added, then it seems the regular
> expression mode is somehow triggered and the "$" character starts behaving
> like endline character. That is expected. {color}{color:#172b4d}
> {color}
> {color:#172b4d} {color}
>
> {code:java}
> gfsh>query --query="select e.key from /example-region.entrySet e where e.key
> like 'aa$b'"
> Result : true
> Limit : 100
> Rows : 0
> {code}
>
>
> {color:#00}There is no way to escape "$" character.{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8962) Not possible to escape "$" character in query using LIKE operator
Mario Kevo created GEODE-8962:
-
Summary: Not possible to escape "$" character in query using LIKE
operator
Key: GEODE-8962
URL: https://issues.apache.org/jira/browse/GEODE-8962
Project: Geode
Issue Type: Bug
Components: querying
Reporter: Mario Kevo
{color:#00}If one query tries to match a string containg "$" character by a
"=" or a "contains" operation, it works, and if data contains a "$" character
and expression of query looks for it, works as expected.{color}
{color:#172b4d} {color}
{code:java}
gfsh>query --query="select e.key from /example-region.entrySet e where
e.key='aa$b'"
Result : true
Limit : 100
Rows : 1
Result
--
aa$b{code}
{color:#00}But if we replace the "=" operator in the Geode query by a
"LIKE" operator, and a wildcard is added, then it seems the regular expression
mode is somehow triggered and the "$" character starts behaving like endline
character. That is expected. {color}{color:#172b4d}
{color}
{color:#172b4d} {color}
{code:java}
gfsh>query --query="select e.key from /example-region.entrySet e where e.key
like 'aa$b'"
Result : true
Limit : 100
Rows : 0
{code}
{color:#00}There is no way to escape "$" character.{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8918) Geode replication event forwarding does not honor GW sender state
[
https://issues.apache.org/jira/browse/GEODE-8918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo reassigned GEODE-8918:
-
Assignee: Mario Kevo
> Geode replication event forwarding does not honor GW sender state
> -
>
> Key: GEODE-8918
> URL: https://issues.apache.org/jira/browse/GEODE-8918
> Project: Geode
> Issue Type: Bug
> Components: wan
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
>
> {color:#172b4d}With 3+ geo-red systems Geode replication has the forwarding
> feature which means that receiving cluster will forward the event it just got
> to all clusters it is connected to that have not yet received the
> event.{color}
> {color:#172b4d}This is possible because the originating cluster is setting
> metadata in the replication event like this:
> GatewaySenderEventCallbackArgument
> [originalCallbackArg=null;originatingSenderId=1;recipientGatewayReceivers=
> {color}{color:#172b4d}{3, 2}{color}{color:#172b4d}]
>
> Site receiving this event thus knows which is the originating site and which
> sites should have received this event. All others will have this event
> forwarded to. All this is legacy Geode behavior.
>
> However, originating site does not care if GW sender to a destination is
> stopped or not - only the fact GW sender is *created and attached* to a
> region is enough. This means if e.g. GW sender from Site1 to Site 3 is
> stopped (and has been stopped for a while - so this has nothing to do with
> timing) at the moment an event hits the replication it is only going to be
> sent to Site 2 *but with the same metadata*_._ Hence Site 2 will not forward
> to Site 3 (assuming it has a connection to it).{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8918) Geode replication event forwarding does not honor GW sender state
Mario Kevo created GEODE-8918:
-
Summary: Geode replication event forwarding does not honor GW
sender state
Key: GEODE-8918
URL: https://issues.apache.org/jira/browse/GEODE-8918
Project: Geode
Issue Type: Bug
Components: wan
Reporter: Mario Kevo
{color:#172b4d}With 3+ geo-red systems Geode replication has the forwarding
feature which means that receiving cluster will forward the event it just got
to all clusters it is connected to that have not yet received the event.{color}
{color:#172b4d}This is possible because the originating cluster is setting
metadata in the replication event like this:
GatewaySenderEventCallbackArgument
[originalCallbackArg=null;originatingSenderId=1;recipientGatewayReceivers=
{color}{color:#172b4d}{3, 2}{color}{color:#172b4d}]
Site receiving this event thus knows which is the originating site and which
sites should have received this event. All others will have this event
forwarded to. All this is legacy Geode behavior.
However, originating site does not care if GW sender to a destination is
stopped or not - only the fact GW sender is *created and attached* to a region
is enough. This means if e.g. GW sender from Site1 to Site 3 is stopped (and
has been stopped for a while - so this has nothing to do with timing) at the
moment an event hits the replication it is only going to be sent to Site 2 *but
with the same metadata*_._ Hence Site 2 will not forward to Site 3 (assuming it
has a connection to it).{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (GEODE-8876) Statistics not collecting correct value for gets when transaction is used
Mario Kevo created GEODE-8876:
-
Summary: Statistics not collecting correct value for gets when
transaction is used
Key: GEODE-8876
URL: https://issues.apache.org/jira/browse/GEODE-8876
Project: Geode
Issue Type: Bug
Components: statistics, transactions
Reporter: Mario Kevo
{color:#172b4d}We were running traffic with reads and updates using
transactions. After traffic finished we collected statistic file from the
server pods.{color}
{color:#172b4d}After opening stats file we got the following:{color}
* {color:#172b4d}In the CacheSeverStats statistics, counters for getRequest
and putRequest are showing correct number of get and put operations requested
by client.{color}
* {color:#172b4d}In the *CachePerfStats*, graph for puts during traffic time
is showing expected number of put operation, but the graph for *gets* was
*empty* in that period!{color}
{color:#172b4d}We tried to check the same statistics for traffic generated
without using transactions and statistic for gets was showing correct number of
operations.{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (GEODE-8835) Incrementing connections despite of creation failed
[
https://issues.apache.org/jira/browse/GEODE-8835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo resolved GEODE-8835.
---
Fix Version/s: 1.14.0
Resolution: Fixed
> Incrementing connections despite of creation failed
> ---
>
> Key: GEODE-8835
> URL: https://issues.apache.org/jira/browse/GEODE-8835
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.14.0
>
>
> {color:#172b4d}Geode client in function OpExecutorImpl.execute() borrow
> connection from availableConnectionManager, but execute fail, then execute
> connectionManager.exchangeConnection(conn, attemptedServers), in this
> function will borrow again from availableConnectionManager again, but fail,
> then execute forceCreateConnection(excludedServers), in
> forceCreateConnection, it first add the connection
> "connectionAccounting.create()", but later create connection fail. So report
> "Unable to create a connection in the allowed time". and geode not process
> this abnormal case to dec the connectionAccounting. so it make the geode
> client think all connection in used and can't create connection again.{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (GEODE-8835) Incrementing connections despite of creation failed
[
https://issues.apache.org/jira/browse/GEODE-8835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mario Kevo reassigned GEODE-8835:
-
Assignee: Mario Kevo
> Incrementing connections despite of creation failed
> ---
>
> Key: GEODE-8835
> URL: https://issues.apache.org/jira/browse/GEODE-8835
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Mario Kevo
>Assignee: Mario Kevo
>Priority: Major
>
> {color:#172b4d}Geode client in function OpExecutorImpl.execute() borrow
> connection from availableConnectionManager, but execute fail, then execute
> connectionManager.exchangeConnection(conn, attemptedServers), in this
> function will borrow again from availableConnectionManager again, but fail,
> then execute forceCreateConnection(excludedServers), in
> forceCreateConnection, it first add the connection
> "connectionAccounting.create()", but later create connection fail. So report
> "Unable to create a connection in the allowed time". and geode not process
> this abnormal case to dec the connectionAccounting. so it make the geode
> client think all connection in used and can't create connection again.{color}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
