[jira] [Created] (GEODE-4451) When a gateway sender is created using gfsh and fails to connect due to AuthenticationFailedException, it is left in an inconsistent state
Barry Oglesby created GEODE-4451:
Summary: When a gateway sender is created using gfsh and fails to
connect due to AuthenticationFailedException, it is left in an inconsistent
state
Key: GEODE-4451
URL: https://issues.apache.org/jira/browse/GEODE-4451
Project: Geode
Issue Type: Bug
Components: wan
Reporter: Barry Oglesby
If I attempt to create a gateway sender with invalid credentials using gfsh, it
fails like:
{noformat}
(2) Executing - create gateway-sender --remote-distributed-system-id=1 --id=ny
--dispatcher-threads=1 --parallel=true
Member | Status
-- |
--
ln-1 | ERROR: Could not start a gateway sender ny because of exception Could
not start a gateway sender 84 because of exception
org.apache.geode.security.AuthenticationFailedException: Authentication error.
Please check your credentials.
{noformat}
The 84 should be the gateway sender id; instead its the thread id (from
\{{ConcurrentParallelGatewaySenderEventProcessor.waitForRunningStatus}}.
In the server log, I see 5 AuthenticationFailedException stacks like (one per
dispatcher-thread):
{noformat}
[severe 2018/01/31 16:13:12.638 PST ln-1 tid=0x55] Message dispatch failed due to unexpected
exception..
org.apache.geode.internal.cache.wan.GatewaySenderException:
org.apache.geode.security.AuthenticationFailedException: Authentication error.
Please check your credentials., caused by
org.apache.geode.security.AuthenticationFailedException: Authentication error.
Please check your credentials.
at
org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:432)
at
org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.(GatewaySenderEventRemoteDispatcher.java:75)
at
org.apache.geode.internal.cache.wan.parallel.RemoteParallelGatewaySenderEventProcessor.initializeEventDispatcher(RemoteParallelGatewaySenderEventProcessor.java:74)
at
org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.setRunningStatus(AbstractGatewaySenderEventProcessor.java:1078)
at
org.apache.geode.internal.cache.wan.AbstractGatewaySenderEventProcessor.run(AbstractGatewaySenderEventProcessor.java:1050)
Caused by: org.apache.geode.security.AuthenticationFailedException:
Authentication error. Please check your credentials.
at
org.apache.geode.internal.cache.tier.sockets.HandShake.readMessage(HandShake.java:1397)
at
org.apache.geode.internal.cache.tier.sockets.HandShake.handshakeWithServer(HandShake.java:1253)
at
org.apache.geode.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:118)
at
org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:136)
at
org.apache.geode.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:259)
at
org.apache.geode.cache.client.internal.pooling.ConnectionManagerImpl.borrowConnection(ConnectionManagerImpl.java:206)
at
org.apache.geode.cache.client.internal.PoolImpl.acquireConnection(PoolImpl.java:902)
at
org.apache.geode.internal.cache.wan.GatewaySenderEventRemoteDispatcher.initializeConnection(GatewaySenderEventRemoteDispatcher.java:388)
... 4 more
{noformat}
A thread dump shows the Event Processor threads are gone, but 5
BatchRemovalThreads like this exist:
{noformat}
"BatchRemovalThread" #96 daemon prio=10 os_prio=31 tid=0x7fc1dd009000
nid=0xcb03 waiting on condition [0x7e245000]
java.lang.Thread.State: TIMED_WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for <0x0007a04043c8> (a
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2163)
at
org.apache.geode.internal.util.concurrent.StoppableCondition.await(StoppableCondition.java:61)
at
org.apache.geode.internal.cache.wan.parallel.ParallelGatewaySenderQueue$BatchRemovalThread.run(ParallelGatewaySenderQueue.java:1613)
{noformat}
list gateways shows the sender in the \{{Not Running}} state:
{noformat}
GatewaySender Id | Member | Remote Cluster Id | Type | Status | Queued Events |
Receiver Location
| | - |
| --- | - | -
ny | 192.168.2.4(ln-1:13883):1027 | 1 | Parallel | Not Running | 0 | null
{noformat}
The sender is left in an inconsistent state. It should either be completely
gone or retrying to connect.
{\{GatewaySende
[jira] [Commented] (GEODE-3948) Improve CQ performance under flaky network conditions
[ https://issues.apache.org/jira/browse/GEODE-3948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347830#comment-16347830 ] ASF subversion and git services commented on GEODE-3948: Commit e093db0ff293e07f1ab6700adfa633dd93bf in geode's branch refs/heads/feature/GEODE-3948 from [~bschuchardt] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=e093db0 ] GEODE-3948 Improve CQ performance under flaky network conditions Addressing review comments. > Improve CQ performance under flaky network conditions > - > > Key: GEODE-3948 > URL: https://issues.apache.org/jira/browse/GEODE-3948 > Project: Geode > Issue Type: Improvement > Components: cq, messaging >Reporter: Galen O'Sullivan >Assignee: Galen O'Sullivan >Priority: Minor > Labels: pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > > Client CQ connections occasionally stop receiving messages and become blocked > indefinitely. > This can be caused by a server that hangs or dies without sending a close > message, or by some firewalls. > The client already gets ping messages from the server, but currently ignores > them. Let's use those messages to detect a failed connection and close it. > Probably the client should follow the same logic and send ping messages if it > has sent no acks for a while, so that the server can also detect and close a > broken connection. > The timeout could be specified as a number and time interval, the ping > interval and the number of missed pings after which to fail. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3834) BackupJUnitTest should use TemporaryFolder
[
https://issues.apache.org/jira/browse/GEODE-3834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Reich resolved GEODE-3834.
---
Resolution: Fixed
> BackupJUnitTest should use TemporaryFolder
> --
>
> Key: GEODE-3834
> URL: https://issues.apache.org/jira/browse/GEODE-3834
> Project: Geode
> Issue Type: Improvement
> Components: persistence, tests
>Reporter: Kirk Lund
>Assignee: Nick Reich
>Priority: Major
> Labels: pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> BackupJUnitTest should use TemporaryFolder instead of
> System.getProperty("java.io.tmpdir").
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-3834) BackupJUnitTest should use TemporaryFolder
[
https://issues.apache.org/jira/browse/GEODE-3834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347826#comment-16347826
]
ASF subversion and git services commented on GEODE-3834:
Commit a5068fff507d776a3efa9664ff38bed2479ef125 in geode's branch
refs/heads/develop from [~nreich]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=a5068ff ]
GEODE-3834: Use TemporaryFolder rule in backup tests that did not yet use it
(#1373)
> BackupJUnitTest should use TemporaryFolder
> --
>
> Key: GEODE-3834
> URL: https://issues.apache.org/jira/browse/GEODE-3834
> Project: Geode
> Issue Type: Improvement
> Components: persistence, tests
>Reporter: Kirk Lund
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.5.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> BackupJUnitTest should use TemporaryFolder instead of
> System.getProperty("java.io.tmpdir").
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-3834) BackupJUnitTest should use TemporaryFolder
[
https://issues.apache.org/jira/browse/GEODE-3834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Reich updated GEODE-3834:
--
Fix Version/s: 1.5.0
> BackupJUnitTest should use TemporaryFolder
> --
>
> Key: GEODE-3834
> URL: https://issues.apache.org/jira/browse/GEODE-3834
> Project: Geode
> Issue Type: Improvement
> Components: persistence, tests
>Reporter: Kirk Lund
>Assignee: Nick Reich
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.5.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> BackupJUnitTest should use TemporaryFolder instead of
> System.getProperty("java.io.tmpdir").
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-3834) BackupJUnitTest should use TemporaryFolder
[
https://issues.apache.org/jira/browse/GEODE-3834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Reich reassigned GEODE-3834:
-
Assignee: Nick Reich
> BackupJUnitTest should use TemporaryFolder
> --
>
> Key: GEODE-3834
> URL: https://issues.apache.org/jira/browse/GEODE-3834
> Project: Geode
> Issue Type: Improvement
> Components: persistence, tests
>Reporter: Kirk Lund
>Assignee: Nick Reich
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.5.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> BackupJUnitTest should use TemporaryFolder instead of
> System.getProperty("java.io.tmpdir").
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-4373) gfsh 'describe region' not showing accessor region description
[
https://issues.apache.org/jira/browse/GEODE-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sai Boorlagadda reassigned GEODE-4373:
--
Assignee: Dave Barnes (was: Sai Boorlagadda)
> gfsh 'describe region' not showing accessor region description
> --
>
> Key: GEODE-4373
> URL: https://issues.apache.org/jira/browse/GEODE-4373
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh
>Reporter: Sai Boorlagadda
>Assignee: Dave Barnes
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.5.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> gfsh not displaying accessor region description.
> on Develop:
> {noformat}
> Command result for :
> ..
> Name : testRegion
> Data Policy : persistent replicate
> Hosting Members : server-5
> server-4
> server-3
> server-2
> Non-Default Attributes Shared By Hosting Members
> Type | Name| Value
> -- | --- |
> Region | data-policy | PERSISTENT_REPLICATE
>| disk-store-name | testDiskStore
>| size| 0
>| scope | distributed-ack{noformat}
>
> But in v1.3.0 it used to display accessor region description as a separate
> table.
> {noformat}
> Command result for :
> ...
> Name: testRegion
> Data Policy : persistent replicate
> Hosting Members : server-3
> server-2
> Non-Default Attributes Shared By Hosting Members
> Type | Name | Value
> -- | --- |
> Region | data-policy | PERSISTENT_REPLICATE
>| disk-store-name | testDiskStore
>| size| 0
>| scope | distributed-ack
> ...
> Name : testRegion
> Data Policy : empty
> Accessor Members : server-1
> Non-Default Attributes Shared By Accessor Members
> Type |Name | Value
> -- | --- | ---
> Region | data-policy | EMPTY
>| size| 0
>| scope | distributed-ack
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4439) Refactor HandShake.java
[ https://issues.apache.org/jira/browse/GEODE-4439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-4439: -- Labels: pull-request-available (was: ) > Refactor HandShake.java > --- > > Key: GEODE-4439 > URL: https://issues.apache.org/jira/browse/GEODE-4439 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt >Priority: Major > Labels: pull-request-available > > Class HandShake is used by both clients and servers to exchange information > and perform encryption/decryption (which is being deprecated). Many methods > are used only by clients and others by servers. These sometimes even have > comments to that effect. This class should be refactored into two classes, > one for clients and one for servers. > Oh, and please rename it to "Handshake". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4373) gfsh 'describe region' not showing accessor region description
[
https://issues.apache.org/jira/browse/GEODE-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-4373:
--
Fix Version/s: 1.5.0
> gfsh 'describe region' not showing accessor region description
> --
>
> Key: GEODE-4373
> URL: https://issues.apache.org/jira/browse/GEODE-4373
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh
>Reporter: Sai Boorlagadda
>Assignee: Sai Boorlagadda
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.5.0
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> gfsh not displaying accessor region description.
> on Develop:
> {noformat}
> Command result for :
> ..
> Name : testRegion
> Data Policy : persistent replicate
> Hosting Members : server-5
> server-4
> server-3
> server-2
> Non-Default Attributes Shared By Hosting Members
> Type | Name| Value
> -- | --- |
> Region | data-policy | PERSISTENT_REPLICATE
>| disk-store-name | testDiskStore
>| size| 0
>| scope | distributed-ack{noformat}
>
> But in v1.3.0 it used to display accessor region description as a separate
> table.
> {noformat}
> Command result for :
> ...
> Name: testRegion
> Data Policy : persistent replicate
> Hosting Members : server-3
> server-2
> Non-Default Attributes Shared By Hosting Members
> Type | Name | Value
> -- | --- |
> Region | data-policy | PERSISTENT_REPLICATE
>| disk-store-name | testDiskStore
>| size| 0
>| scope | distributed-ack
> ...
> Name : testRegion
> Data Policy : empty
> Accessor Members : server-1
> Non-Default Attributes Shared By Accessor Members
> Type |Name | Value
> -- | --- | ---
> Region | data-policy | EMPTY
>| size| 0
>| scope | distributed-ack
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-3877) gfsh command to set TransactionListener/Writer
[
https://issues.apache.org/jira/browse/GEODE-3877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Barbara Pruijn updated GEODE-3877:
--
Description:
Currently users cannot specify a TransactionWriter and TransactionListener from
gfsh. We should add a {{configure transaction-manager}} gfsh command which will
enable us to specify the callbacks like so:
{noformat}
alter transaction-manager --add-transaction-listener=class1,class2
--remove-transaction-listener=class1,class2 --transaction-writer=only1class
{noformat}
was:
Currently users cannot specify a TransactionWriter and TransactionListener from
gfsh. We should add a {{configure transaction-manager}} gfsh command which will
enable us to specify the callbacks like so:
{noformat}
configure transaction-manager --transaction-listener=class1,class2
--transaction-writer=only1class
{noformat}
> gfsh command to set TransactionListener/Writer
> --
>
> Key: GEODE-3877
> URL: https://issues.apache.org/jira/browse/GEODE-3877
> Project: Geode
> Issue Type: Sub-task
> Components: docs, gfsh
>Reporter: Swapnil Bawaskar
>Priority: Major
>
> Currently users cannot specify a TransactionWriter and TransactionListener
> from gfsh. We should add a {{configure transaction-manager}} gfsh command
> which will enable us to specify the callbacks like so:
> {noformat}
> alter transaction-manager --add-transaction-listener=class1,class2
> --remove-transaction-listener=class1,class2 --transaction-writer=only1class
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4186) Replace all decayed array parameters (Type *) with std::vector.
[
https://issues.apache.org/jira/browse/GEODE-4186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347800#comment-16347800
]
ASF subversion and git services commented on GEODE-4186:
Commit 519d87fbd4fdabef412ce15da9c762faa0f7a734 in geode-native's branch
refs/heads/develop from [~dkimura]
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=519d87f ]
GEODE-4186: Replace decayed array paremeters with std::vector (#194)
> Replace all decayed array parameters (Type *) with std::vector.
> ---
>
> Key: GEODE-4186
> URL: https://issues.apache.org/jira/browse/GEODE-4186
> Project: Geode
> Issue Type: Improvement
> Components: native client
>Reporter: Jacob S. Barrett
>Priority: Major
> Labels: pull-request-available
> Time Spent: 5h 20m
> Remaining Estimate: 0h
>
> Replace all decayed array parameters (Type *) with std::vector. For example
> {code}
> void writeIntArray(int32_t* array, size_t length);
> int32_t* readIntArray(size_t& length);
> {code}
> to
> {code}
> void writeIntArray(const std::vector& array);
> std::vector readIntArray();
> {code}
> This removes the ambiguity around memory ownership, makes the method
> functional (no out param), collocates the length and other array attributes
> with the vector, and removes null.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (GEODE-3800) Create backup service
[ https://issues.apache.org/jira/browse/GEODE-3800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade reassigned GEODE-3800: Assignee: Anilkumar Gingade (was: Nick Reich) > Create backup service > - > > Key: GEODE-3800 > URL: https://issues.apache.org/jira/browse/GEODE-3800 > Project: Geode > Issue Type: Sub-task > Components: persistence >Reporter: Nick Reich >Assignee: Anilkumar Gingade >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > > Instead of creating a backup management class for each backup request, create > a service to which the requests are made and handles the logic of launching > the backup and what to do if more than one backup is requested at a time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-4407) Separate incremental backup logic from backup task and oplog
[ https://issues.apache.org/jira/browse/GEODE-4407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anilkumar Gingade reassigned GEODE-4407: Assignee: Anilkumar Gingade > Separate incremental backup logic from backup task and oplog > > > Key: GEODE-4407 > URL: https://issues.apache.org/jira/browse/GEODE-4407 > Project: Geode > Issue Type: Sub-task > Components: persistence >Reporter: Nick Reich >Assignee: Anilkumar Gingade >Priority: Major > > Incremental backup examines the oplog from current destination to the > previously backed up destination to generate oplogs to be backed up. This > logic is present in both backup task and oplog. We need to separate this out > so the logic can be used for different backup destinations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4353) Deprecate security-client-dhalgo property
[
https://issues.apache.org/jira/browse/GEODE-4353?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347733#comment-16347733
]
Bruce Schuchardt commented on GEODE-4353:
-
This feature has apparently been broken since at least 2008. See GEODE-4450.
There are no tests for this feature.
> Deprecate security-client-dhalgo property
> -
>
> Key: GEODE-4353
> URL: https://issues.apache.org/jira/browse/GEODE-4353
> Project: Geode
> Issue Type: Bug
> Components: client/server
>Reporter: Dan Smith
>Priority: Major
>
> {{security-client-dhalgo}}{\{ should be deprecated in favor of using the
> ssl-* settings.}}
>
> [{{[https://geode.apache.org/docs/guide/10/managing/security/encrypting_with_diffie_helman.html]}}]{{}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-4450) setting a client/server diffie-hellman algorithm breaks client/server subscriptions
Bruce Schuchardt created GEODE-4450: --- Summary: setting a client/server diffie-hellman algorithm breaks client/server subscriptions Key: GEODE-4450 URL: https://issues.apache.org/jira/browse/GEODE-4450 Project: Geode Issue Type: Improvement Components: client/server Reporter: Bruce Schuchardt Having found that there are no tests for the security-client-dhalgo setting I modified a test to use it. The client/server handshake in the subscription thread (cache client updater) hung on the server side trying to read client credentials. I tracked this down to CacheClientNotifier.registerClient, which sends a 105 byte to the client along with some other bytes in its writeMessage() method. The client isn't expecting this message and interprets the 105 as a failure to register with the server. The client then abandons the handshake and the server hangs until its read times out. See also GEODE-4353, which wants to deprecate this broken feature. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4308) Should be able to create two caches in the same JVM
[ https://issues.apache.org/jira/browse/GEODE-4308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347727#comment-16347727 ] Dan Smith commented on GEODE-4308: -- [~agingade] - I think multitenancy is really a separate issue. These changes are really just making it easier for someone to create multiple caches in the same JVM. If a user wants some sort of in JVM level isolation that is a separate issue which it is up to the user to implement. We don't do anything to protect access to data in the cache from code in the same JVM with or without these changes. > Should be able to create two caches in the same JVM > --- > > Key: GEODE-4308 > URL: https://issues.apache.org/jira/browse/GEODE-4308 > Project: Geode > Issue Type: Sub-task > Components: messaging >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Users should be able to create two or more caches in the same JVM. > Currently this is impossible because we have a static instance variable that > only allows a single cache. > We should add a feature flag to let us start getting multiple caches to work > if that feature flag is enabled. For this task we will add the feature flag > and enable creating multiple caches in the same JVM. Not all cache features > will work yet, just the CacheFactory.create(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4439) Refactor HandShake.java
[ https://issues.apache.org/jira/browse/GEODE-4439?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347724#comment-16347724 ] ASF subversion and git services commented on GEODE-4439: Commit fc5a8be7afc68dc5b1ba65d505b6dff8185dbbbe in geode's branch refs/heads/feature/GEODE-4439 from [~bschuchardt] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=fc5a8be ] GEODE-4439 Refactor HandShake.java fixing test failures > Refactor HandShake.java > --- > > Key: GEODE-4439 > URL: https://issues.apache.org/jira/browse/GEODE-4439 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Bruce Schuchardt >Assignee: Bruce Schuchardt >Priority: Major > > Class HandShake is used by both clients and servers to exchange information > and perform encryption/decryption (which is being deprecated). Many methods > are used only by clients and others by servers. These sometimes even have > comments to that effect. This class should be refactored into two classes, > one for clients and one for servers. > Oh, and please rename it to "Handshake". -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4390) CI failure: PersistPRKRFDUnitTest.testCloseDiskStoreWhenPut fails with DiskAccessException
[
https://issues.apache.org/jira/browse/GEODE-4390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Reich resolved GEODE-4390.
---
Resolution: Fixed
Fix Version/s: 1.5.0
> CI failure: PersistPRKRFDUnitTest.testCloseDiskStoreWhenPut fails with
> DiskAccessException
> --
>
> Key: GEODE-4390
> URL: https://issues.apache.org/jira/browse/GEODE-4390
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Nick Reich
>Assignee: Nick Reich
>Priority: Major
> Labels: Flaky, pull-request-available
> Fix For: 1.5.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Contents of the failure:
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 0 running on Host
> 7e1c6381c949 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:393)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:363)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:296)
> at
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionTestBase.checkData(PersistentPartitionedRegionTestBase.java:124)
> at
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionTestBase.checkData(PersistentPartitionedRegionTestBase.java:119)
> at
> org.apache.geode.internal.cache.partitioned.PersistPRKRFDUnitTest.testCloseDiskStoreWhenPut(PersistPRKRFDUnitTest.java:198)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
> at sun.reflect.NativeMethodAcc
[jira] [Assigned] (GEODE-4390) CI failure: PersistPRKRFDUnitTest.testCloseDiskStoreWhenPut fails with DiskAccessException
[
https://issues.apache.org/jira/browse/GEODE-4390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Reich reassigned GEODE-4390:
-
Assignee: Nick Reich
> CI failure: PersistPRKRFDUnitTest.testCloseDiskStoreWhenPut fails with
> DiskAccessException
> --
>
> Key: GEODE-4390
> URL: https://issues.apache.org/jira/browse/GEODE-4390
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Nick Reich
>Assignee: Nick Reich
>Priority: Major
> Labels: Flaky, pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Contents of the failure:
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 0 running on Host
> 7e1c6381c949 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:393)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:363)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:296)
> at
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionTestBase.checkData(PersistentPartitionedRegionTestBase.java:124)
> at
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionTestBase.checkData(PersistentPartitionedRegionTestBase.java:119)
> at
> org.apache.geode.internal.cache.partitioned.PersistPRKRFDUnitTest.testCloseDiskStoreWhenPut(PersistPRKRFDUnitTest.java:198)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.
[jira] [Commented] (GEODE-4390) CI failure: PersistPRKRFDUnitTest.testCloseDiskStoreWhenPut fails with DiskAccessException
[
https://issues.apache.org/jira/browse/GEODE-4390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347711#comment-16347711
]
ASF subversion and git services commented on GEODE-4390:
Commit 4a7514883515ed804b6c5e905e11627395036db9 in geode's branch
refs/heads/develop from [~nreich]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=4a75148 ]
GEODE-4390: Replace flaky test with new tests (#1371)
> CI failure: PersistPRKRFDUnitTest.testCloseDiskStoreWhenPut fails with
> DiskAccessException
> --
>
> Key: GEODE-4390
> URL: https://issues.apache.org/jira/browse/GEODE-4390
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Nick Reich
>Priority: Major
> Labels: Flaky, pull-request-available
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Contents of the failure:
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 0 running on Host
> 7e1c6381c949 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:393)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:363)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:296)
> at
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionTestBase.checkData(PersistentPartitionedRegionTestBase.java:124)
> at
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionTestBase.checkData(PersistentPartitionedRegionTestBase.java:119)
> at
> org.apache.geode.internal.cache.partitioned.PersistPRKRFDUnitTest.testCloseDiskStoreWhenPut(PersistPRKRFDUnitTest.java:198)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> a
[jira] [Commented] (GEODE-4373) gfsh 'describe region' not showing accessor region description
[
https://issues.apache.org/jira/browse/GEODE-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347682#comment-16347682
]
ASF subversion and git services commented on GEODE-4373:
Commit 26153323ccc2e874cf444ddf1630e471f6f176f1 in geode's branch
refs/heads/develop from [~sai.boorlaga...@gmail.com]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=2615332 ]
GEODE-4373: gfsh 'describe region' not showing accessor region description
(#1365)
Fixed describe region to return region descriptions from all members
that host the region and from accessors(if any).
> gfsh 'describe region' not showing accessor region description
> --
>
> Key: GEODE-4373
> URL: https://issues.apache.org/jira/browse/GEODE-4373
> Project: Geode
> Issue Type: Bug
> Components: docs, gfsh
>Reporter: Sai Boorlagadda
>Assignee: Sai Boorlagadda
>Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> gfsh not displaying accessor region description.
> on Develop:
> {noformat}
> Command result for :
> ..
> Name : testRegion
> Data Policy : persistent replicate
> Hosting Members : server-5
> server-4
> server-3
> server-2
> Non-Default Attributes Shared By Hosting Members
> Type | Name| Value
> -- | --- |
> Region | data-policy | PERSISTENT_REPLICATE
>| disk-store-name | testDiskStore
>| size| 0
>| scope | distributed-ack{noformat}
>
> But in v1.3.0 it used to display accessor region description as a separate
> table.
> {noformat}
> Command result for :
> ...
> Name: testRegion
> Data Policy : persistent replicate
> Hosting Members : server-3
> server-2
> Non-Default Attributes Shared By Hosting Members
> Type | Name | Value
> -- | --- |
> Region | data-policy | PERSISTENT_REPLICATE
>| disk-store-name | testDiskStore
>| size| 0
>| scope | distributed-ack
> ...
> Name : testRegion
> Data Policy : empty
> Accessor Members : server-1
> Non-Default Attributes Shared By Accessor Members
> Type |Name | Value
> -- | --- | ---
> Region | data-policy | EMPTY
>| size| 0
>| scope | distributed-ack
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4448) Refactor ExpirationAction to enum class
[ https://issues.apache.org/jira/browse/GEODE-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347676#comment-16347676 ] ASF subversion and git services commented on GEODE-4448: Commit ba5fffd01f7acb29c43a410c437a762e6d9e0659 in geode-native's branch refs/heads/develop from Jacob Barrett [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=ba5fffd ] GEODE-4448: Refactors ExpirationAction to enum class. (#203) > Refactor ExpirationAction to enum class > --- > > Key: GEODE-4448 > URL: https://issues.apache.org/jira/browse/GEODE-4448 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Jacob S. Barrett >Assignee: Jacob S. Barrett >Priority: Major > Labels: pull-request-available > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-3834) BackupJUnitTest should use TemporaryFolder
[
https://issues.apache.org/jira/browse/GEODE-3834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-3834:
--
Labels: pull-request-available (was: )
> BackupJUnitTest should use TemporaryFolder
> --
>
> Key: GEODE-3834
> URL: https://issues.apache.org/jira/browse/GEODE-3834
> Project: Geode
> Issue Type: Improvement
> Components: persistence, tests
>Reporter: Kirk Lund
>Priority: Major
> Labels: pull-request-available
>
> BackupJUnitTest should use TemporaryFolder instead of
> System.getProperty("java.io.tmpdir").
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-4308) Should be able to create two caches in the same JVM
[ https://issues.apache.org/jira/browse/GEODE-4308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347655#comment-16347655 ] Alexander Murmann commented on GEODE-4308: -- Many of the issues we will run into making it possible to run multiple caches in one JVM are due to questionable design decisions. There is no doubt in my mind that the Geode codebase will be in better state once there is nothing left that prohibits us from running more than one cache in a JVM. So this goal might be a great guiding start for future refactors. The testing benefit of multiple caches in the same JVM also has come up in prior refactoring discussions. I agree with Anil though that exposing multiple caches in one JVM to the user is a discussion that should be done with care. > Should be able to create two caches in the same JVM > --- > > Key: GEODE-4308 > URL: https://issues.apache.org/jira/browse/GEODE-4308 > Project: Geode > Issue Type: Sub-task > Components: messaging >Reporter: Dan Smith >Assignee: Dan Smith >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Users should be able to create two or more caches in the same JVM. > Currently this is impossible because we have a static instance variable that > only allows a single cache. > We should add a feature flag to let us start getting multiple caches to work > if that feature flag is enabled. For this task we will add the feature flag > and enable creating multiple caches in the same JVM. Not all cache features > will work yet, just the CacheFactory.create(). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4449) Replace macro-templates with plain templates
David Kimura created GEODE-4449: --- Summary: Replace macro-templates with plain templates Key: GEODE-4449 URL: https://issues.apache.org/jira/browse/GEODE-4449 Project: Geode Issue Type: Improvement Components: native client Reporter: David Kimura Replace macro-templates in CacheableBuiltins.hpp from... _GEODE_CACHEABLE_ARRAY_TYPE_(int8_t, CacheableBytes); _GEODE_CACHEABLE_ARRAY_TYPE_(std::shared_ptr, CacheableStringArray); into... using CacheableBytes = CacheableArray; using CacheableStringArray = CacheableArray, GeodeTypeIds::CacheableStringArray>; It also makes the code debuggable since most debuggers can step through templates, but not macros. It also removes an unnecessary level of indirection by the preprocessor. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4434) Need an API to confirm recovery is finished
[ https://issues.apache.org/jira/browse/GEODE-4434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347643#comment-16347643 ] Fred Krone commented on GEODE-4434: --- I haven't been able to get any feedback from the field on what this command should look like for the user. Any suggestions? gfsh --check-redundancy ? > Need an API to confirm recovery is finished > --- > > Key: GEODE-4434 > URL: https://issues.apache.org/jira/browse/GEODE-4434 > Project: Geode > Issue Type: New Feature > Components: persistence >Reporter: xiaojian zhou >Priority: Major > > This feature is expected especially when we need to decide if it's safe to > shutdown one member. So far we were using following workarrounds instead: > > 1) wait until cacheserver is listening on the port (to make sure all > replicated regions have finished recovery) > 2) call rebalance() to make sure the defined redundancy are satisfied (for PR) > > we need to introduce a boolean parameter into rebalance() to only check > redundancy, not to do real rebalance. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-4448) Refactor ExpirationAction to enum class
[ https://issues.apache.org/jira/browse/GEODE-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob S. Barrett reassigned GEODE-4448: --- Assignee: Jacob S. Barrett > Refactor ExpirationAction to enum class > --- > > Key: GEODE-4448 > URL: https://issues.apache.org/jira/browse/GEODE-4448 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Jacob S. Barrett >Assignee: Jacob S. Barrett >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4448) Refactor ExpirationAction to enum class
[ https://issues.apache.org/jira/browse/GEODE-4448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-4448: -- Labels: pull-request-available (was: ) > Refactor ExpirationAction to enum class > --- > > Key: GEODE-4448 > URL: https://issues.apache.org/jira/browse/GEODE-4448 > Project: Geode > Issue Type: Improvement > Components: native client >Reporter: Jacob S. Barrett >Priority: Major > Labels: pull-request-available > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4448) Refactor ExpirationAction to enum class
Jacob S. Barrett created GEODE-4448: --- Summary: Refactor ExpirationAction to enum class Key: GEODE-4448 URL: https://issues.apache.org/jira/browse/GEODE-4448 Project: Geode Issue Type: Improvement Components: native client Reporter: Jacob S. Barrett -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4431) Remove redundant modifiers from geode-core:internal (excluding cache)
[ https://issues.apache.org/jira/browse/GEODE-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg resolved GEODE-4431. - Resolution: Fixed Assignee: Patrick Rhomberg Fix Version/s: 1.5.0 > Remove redundant modifiers from geode-core:internal (excluding cache) > - > > Key: GEODE-4431 > URL: https://issues.apache.org/jira/browse/GEODE-4431 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4433) Remove redundant modifiers from non geode-core
[ https://issues.apache.org/jira/browse/GEODE-4433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg resolved GEODE-4433. - Resolution: Fixed Assignee: Patrick Rhomberg Fix Version/s: 1.5.0 > Remove redundant modifiers from non geode-core > -- > > Key: GEODE-4433 > URL: https://issues.apache.org/jira/browse/GEODE-4433 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4432) Remove redundant modifiers from geode-core (excluding cache and internal)
[ https://issues.apache.org/jira/browse/GEODE-4432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg resolved GEODE-4432. - Resolution: Fixed Assignee: Patrick Rhomberg Fix Version/s: 1.5.0 > Remove redundant modifiers from geode-core (excluding cache and internal) > - > > Key: GEODE-4432 > URL: https://issues.apache.org/jira/browse/GEODE-4432 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-2980) Code Cleanup : Remove redundant modifier from the Interface definition
[
https://issues.apache.org/jira/browse/GEODE-2980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Rhomberg resolved GEODE-2980.
-
Resolution: Fixed
Fix Version/s: 1.5.0
> Code Cleanup : Remove redundant modifier from the Interface definition
> --
>
> Key: GEODE-2980
> URL: https://issues.apache.org/jira/browse/GEODE-2980
> Project: Geode
> Issue Type: Task
>Reporter: Avinash Dongre
>Assignee: Avinash Dongre
>Priority: Major
> Labels: pull-request-available
> Fix For: 1.5.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> All methods in an interface are implicitly {{public}} and {{abstract}}
> All fields in an interface are implicitly {{public}}, {{static}} and
> {{final}}.
> We have almost in all the interface public modifier for all the methods in
> the Interfaces, we should remove the same.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-4430) Remove redundant modifiers from geode-core:internal.cache
[ https://issues.apache.org/jira/browse/GEODE-4430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg resolved GEODE-4430. - Resolution: Fixed Assignee: Patrick Rhomberg Fix Version/s: 1.5.0 > Remove redundant modifiers from geode-core:internal.cache > - > > Key: GEODE-4430 > URL: https://issues.apache.org/jira/browse/GEODE-4430 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4429) Remove redundant modifiers from geode-core:cache
[ https://issues.apache.org/jira/browse/GEODE-4429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg resolved GEODE-4429. - Resolution: Fixed Fix Version/s: 1.5.0 > Remove redundant modifiers from geode-core:cache > > > Key: GEODE-4429 > URL: https://issues.apache.org/jira/browse/GEODE-4429 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (GEODE-4429) Remove redundant modifiers from geode-core:cache
[ https://issues.apache.org/jira/browse/GEODE-4429?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Rhomberg reassigned GEODE-4429: --- Assignee: Patrick Rhomberg > Remove redundant modifiers from geode-core:cache > > > Key: GEODE-4429 > URL: https://issues.apache.org/jira/browse/GEODE-4429 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Assignee: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4430) Remove redundant modifiers from geode-core:internal.cache
[ https://issues.apache.org/jira/browse/GEODE-4430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347531#comment-16347531 ] ASF subversion and git services commented on GEODE-4430: Commit 9438685cbf1440af9005c8935ed67cef4639d33e in geode's branch refs/heads/develop from [~prhomberg] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9438685 ] GEODE-4430: Remove unnecessary modifiers from interfaces in geode-core:internal.cache * This closes #529 > Remove redundant modifiers from geode-core:internal.cache > - > > Key: GEODE-4430 > URL: https://issues.apache.org/jira/browse/GEODE-4430 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4429) Remove redundant modifiers from geode-core:cache
[ https://issues.apache.org/jira/browse/GEODE-4429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347518#comment-16347518 ] ASF subversion and git services commented on GEODE-4429: Commit 751735d8a13481860a5f4fead15a8360b99cb764 in geode's branch refs/heads/develop from [~prhomberg] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=751735d ] GEODE-4432: Remove unnecessary modifiers from interfaces in geode-core * This excludes those interfaces in cache (covered in GEODE-4429) and internal (GEODE-4430 and GEODE-4431) > Remove redundant modifiers from geode-core:cache > > > Key: GEODE-4429 > URL: https://issues.apache.org/jira/browse/GEODE-4429 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4431) Remove redundant modifiers from geode-core:internal (excluding cache)
[ https://issues.apache.org/jira/browse/GEODE-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347520#comment-16347520 ] ASF subversion and git services commented on GEODE-4431: Commit 751735d8a13481860a5f4fead15a8360b99cb764 in geode's branch refs/heads/develop from [~prhomberg] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=751735d ] GEODE-4432: Remove unnecessary modifiers from interfaces in geode-core * This excludes those interfaces in cache (covered in GEODE-4429) and internal (GEODE-4430 and GEODE-4431) > Remove redundant modifiers from geode-core:internal (excluding cache) > - > > Key: GEODE-4431 > URL: https://issues.apache.org/jira/browse/GEODE-4431 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4432) Remove redundant modifiers from geode-core (excluding cache and internal)
[ https://issues.apache.org/jira/browse/GEODE-4432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347517#comment-16347517 ] ASF subversion and git services commented on GEODE-4432: Commit 751735d8a13481860a5f4fead15a8360b99cb764 in geode's branch refs/heads/develop from [~prhomberg] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=751735d ] GEODE-4432: Remove unnecessary modifiers from interfaces in geode-core * This excludes those interfaces in cache (covered in GEODE-4429) and internal (GEODE-4430 and GEODE-4431) > Remove redundant modifiers from geode-core (excluding cache and internal) > - > > Key: GEODE-4432 > URL: https://issues.apache.org/jira/browse/GEODE-4432 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4430) Remove redundant modifiers from geode-core:internal.cache
[ https://issues.apache.org/jira/browse/GEODE-4430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347519#comment-16347519 ] ASF subversion and git services commented on GEODE-4430: Commit 751735d8a13481860a5f4fead15a8360b99cb764 in geode's branch refs/heads/develop from [~prhomberg] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=751735d ] GEODE-4432: Remove unnecessary modifiers from interfaces in geode-core * This excludes those interfaces in cache (covered in GEODE-4429) and internal (GEODE-4430 and GEODE-4431) > Remove redundant modifiers from geode-core:internal.cache > - > > Key: GEODE-4430 > URL: https://issues.apache.org/jira/browse/GEODE-4430 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-1910) revise membership properties in internal/cache/properties.html
[ https://issues.apache.org/jira/browse/GEODE-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bruce Schuchardt resolved GEODE-1910. - Resolution: Fixed Fix Version/s: 1.4.0 I fixed this when addressing GEODE-4148 > revise membership properties in internal/cache/properties.html > -- > > Key: GEODE-1910 > URL: https://issues.apache.org/jira/browse/GEODE-1910 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Bruce Schuchardt >Assignee: Joey McAllister >Priority: Major > Fix For: 1.4.0 > > > The properties.html file has a number of old properties refering to > com.gemstone.org.jgroups. These need to be removed and the new GMS > properties should be added in their place. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4433) Remove redundant modifiers from non geode-core
[ https://issues.apache.org/jira/browse/GEODE-4433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347503#comment-16347503 ] ASF subversion and git services commented on GEODE-4433: Commit 9cf05c18b638dd47fbae881e6e2bec1722f97508 in geode's branch refs/heads/develop from [~prhomberg] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=9cf05c1 ] GEODE-4433: Remove unnecessary modifiers from interfaces outside geode-core > Remove redundant modifiers from non geode-core > -- > > Key: GEODE-4433 > URL: https://issues.apache.org/jira/browse/GEODE-4433 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4371) Dump stacks when ci pipeline is hung
[ https://issues.apache.org/jira/browse/GEODE-4371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347490#comment-16347490 ] ASF subversion and git services commented on GEODE-4371: Commit adfd511b5e36f949c80e45925427e104e4f925f2 in geode's branch refs/heads/develop from [~smgoller] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=adfd511 ] [GEODE-4371] Add lurker process that captures callstacks. (#1337) * Add callstacks capture script that waits until an hour before the job times out then captures all callstacks and writes them out to the output container. Signed-off-by: Owen Nichols > Dump stacks when ci pipeline is hung > > > Key: GEODE-4371 > URL: https://issues.apache.org/jira/browse/GEODE-4371 > Project: Geode > Issue Type: Bug > Components: build >Reporter: Jason Huynh >Priority: Major > Labels: pull-request-available > Time Spent: 50m > Remaining Estimate: 0h > > When a test is hung and causes the pipeline to fail, it would be nice to have > stacks be dumped into a location for post-mortem analysis -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4447) Write unit tests for AbstractRegionMap.basicPut
Kirk Lund created GEODE-4447: Summary: Write unit tests for AbstractRegionMap.basicPut Key: GEODE-4447 URL: https://issues.apache.org/jira/browse/GEODE-4447 Project: Geode Issue Type: Sub-task Components: regions Reporter: Kirk Lund Write unit tests for AbstractRegionMap.basicPut -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-1747) UnusedServerMonitor creates pool connections
[
https://issues.apache.org/jira/browse/GEODE-1747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347489#comment-16347489
]
Galen O'Sullivan commented on GEODE-1747:
-
[~bschuchardt] I see nothing in the history about UnusedServerMonitor, and the
class doesn't seem to be present anymore. Can we delete this TODO?
> UnusedServerMonitor creates pool connections
>
>
> Key: GEODE-1747
> URL: https://issues.apache.org/jira/browse/GEODE-1747
> Project: Geode
> Issue Type: Task
> Components: client/server
>Reporter: Bruce Schuchardt
>Priority: Major
>
> This TODO in ExplicitConnectionSourceImpl needs to be addressed
> {noformat}
> * TODO - the UnusedServerMonitor basically will force the pool to
> * have at least one connection to each server. Maybe we need to have it
> * create connections that are outside the pool?
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (GEODE-4446) Extract many methods from BasicPut basicPut
Kirk Lund created GEODE-4446: Summary: Extract many methods from BasicPut basicPut Key: GEODE-4446 URL: https://issues.apache.org/jira/browse/GEODE-4446 Project: Geode Issue Type: Sub-task Components: regions Reporter: Kirk Lund Extract many methods from BasicPut basicPut. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4445) Move all RegionMap classes to org.apache.geode.internal.cache.map package
Kirk Lund created GEODE-4445: Summary: Move all RegionMap classes to org.apache.geode.internal.cache.map package Key: GEODE-4445 URL: https://issues.apache.org/jira/browse/GEODE-4445 Project: Geode Issue Type: Sub-task Components: regions Reporter: Kirk Lund Move all RegionMap classes to org.apache.geode.internal.cache.map package. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-4444) Extract basicPut operation to its own class
[ https://issues.apache.org/jira/browse/GEODE-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund updated GEODE-: - Description: Extract body of AbstractRegionMap.basicPut method to new BasicPut class in org.apache.geode.internal.cache.map package. > Extract basicPut operation to its own class > --- > > Key: GEODE- > URL: https://issues.apache.org/jira/browse/GEODE- > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Kirk Lund >Priority: Major > > Extract body of AbstractRegionMap.basicPut method to new BasicPut class in > org.apache.geode.internal.cache.map package. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (GEODE-4444) Extract basicPut operation to its own class
Kirk Lund created GEODE-: Summary: Extract basicPut operation to its own class Key: GEODE- URL: https://issues.apache.org/jira/browse/GEODE- Project: Geode Issue Type: Sub-task Components: regions Reporter: Kirk Lund -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4431) Remove redundant modifiers from geode-core:internal (excluding cache)
[ https://issues.apache.org/jira/browse/GEODE-4431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347482#comment-16347482 ] ASF subversion and git services commented on GEODE-4431: Commit a6ac1863412bbc3beb17e78984408c16202a0d8a in geode's branch refs/heads/develop from [~prhomberg] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a6ac186 ] GEODE-4431: Remove unnecessary modifiers from interfaces in geode-core:internal * This excludes those interfaces in internal.cache, covered in GEODE-4430. > Remove redundant modifiers from geode-core:internal (excluding cache) > - > > Key: GEODE-4431 > URL: https://issues.apache.org/jira/browse/GEODE-4431 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4364) Extract destroy operation to its own class
[ https://issues.apache.org/jira/browse/GEODE-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirk Lund resolved GEODE-4364. -- Resolution: Fixed Fix Version/s: 1.5.0 > Extract destroy operation to its own class > -- > > Key: GEODE-4364 > URL: https://issues.apache.org/jira/browse/GEODE-4364 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Extract body of AbstractRegionMap.destroy method to new RegionMapDestroy > class in org.apache.geode.internal.cache.map package. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4430) Remove redundant modifiers from geode-core:internal.cache
[ https://issues.apache.org/jira/browse/GEODE-4430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347483#comment-16347483 ] ASF subversion and git services commented on GEODE-4430: Commit a6ac1863412bbc3beb17e78984408c16202a0d8a in geode's branch refs/heads/develop from [~prhomberg] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=a6ac186 ] GEODE-4431: Remove unnecessary modifiers from interfaces in geode-core:internal * This excludes those interfaces in internal.cache, covered in GEODE-4430. > Remove redundant modifiers from geode-core:internal.cache > - > > Key: GEODE-4430 > URL: https://issues.apache.org/jira/browse/GEODE-4430 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (GEODE-3800) Create backup service
[ https://issues.apache.org/jira/browse/GEODE-3800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-3800: -- Labels: pull-request-available (was: ) > Create backup service > - > > Key: GEODE-3800 > URL: https://issues.apache.org/jira/browse/GEODE-3800 > Project: Geode > Issue Type: Sub-task > Components: persistence >Reporter: Nick Reich >Assignee: Nick Reich >Priority: Major > Labels: pull-request-available > > Instead of creating a backup management class for each backup request, create > a service to which the requests are made and handles the logic of launching > the backup and what to do if more than one backup is requested at a time. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4434) Need an API to confirm recovery is finished
[ https://issues.apache.org/jira/browse/GEODE-4434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347477#comment-16347477 ] Barry Oglesby commented on GEODE-4434: -- We also use the ResourceObserver afterRecovery callback to determine that recovery is completed. This would be a really nice API to make public. > Need an API to confirm recovery is finished > --- > > Key: GEODE-4434 > URL: https://issues.apache.org/jira/browse/GEODE-4434 > Project: Geode > Issue Type: New Feature > Components: persistence >Reporter: xiaojian zhou >Priority: Major > > This feature is expected especially when we need to decide if it's safe to > shutdown one member. So far we were using following workarrounds instead: > > 1) wait until cacheserver is listening on the port (to make sure all > replicated regions have finished recovery) > 2) call rebalance() to make sure the defined redundancy are satisfied (for PR) > > we need to introduce a boolean parameter into rebalance() to only check > redundancy, not to do real rebalance. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-1763) CI failure: PartitionedRegionSingleHopDUnitTest.testMetadataIsSameOnAllServersAndClients
[ https://issues.apache.org/jira/browse/GEODE-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Baynes resolved GEODE-1763. - Resolution: Resolved Marked flaky. > CI failure: > PartitionedRegionSingleHopDUnitTest.testMetadataIsSameOnAllServersAndClients > > > Key: GEODE-1763 > URL: https://issues.apache.org/jira/browse/GEODE-1763 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Hitesh Khamesra >Priority: Major > Labels: CI > > java.lang.AssertionError: Event never occurred after 6 ms: bucket copies > are not created > Stacktrace > java.lang.AssertionError: Event never occurred after 6 ms: bucket copies > are not created > at org.junit.Assert.fail(Assert.java:88) > at com.gemstone.gemfire.test.dunit.Wait.waitForCriterion(Wait.java:185) > at > com.gemstone.gemfire.internal.cache.PartitionedRegionSingleHopDUnitTest.testMetadataIsSameOnAllServersAndClients(PartitionedRegionSingleHopDUnitTest.java:807) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) > at > org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93) > at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) > at > org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(R
[jira] [Commented] (GEODE-921) InternalGemFireError: No cache client proxy on this node
[ https://issues.apache.org/jira/browse/GEODE-921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347466#comment-16347466 ] Galen O'Sullivan commented on GEODE-921: This looks like an old issue and it's a private build, so I'm not going to try to reproduce. If you see an issue with a recent Geode build, please let us know! > InternalGemFireError: No cache client proxy on this node > > > Key: GEODE-921 > URL: https://issues.apache.org/jira/browse/GEODE-921 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Darrel Schneider >Assignee: William Markito Oliveira >Priority: Major > > On a private build of git rev ab25e41c6281ef90f04c7534e4d65ba4f24d7fc9 this > test CqDataUsingPoolOptimizedExecuteDUnitTest.testCQHAWithState failed with > the following suspect string. InternalGemFireError should never happen so > this bug should have a higher priority than most suspect string failures. > [vm_2][info 2016/02/05 06:11:28.175 UTC > tid=0x2d9] ### Close CacheServer. ### > [vm_3][info 2016/02/05 06:11:28.175 UTC ip-10-32-38-194(18458):1027 port 21058> tid=0x1e2] Redundant > subscription endpoint ip-10-32-38-194.ore1.vpc.pivotal.io:21058 crashed. > Scheduling recovery. > [vm_3][info 2016/02/05 06:11:28.175 UTC > tid=0x1e4] SubscriptionManager redundancy satisfier - primary endpoint has > been lost. Attempting to recover. > [vm_3][info 2016/02/05 06:11:28.177 UTC ip-10-32-38-194(18458):1027 port 21058> tid=0x1e2] Cache client > updater for Queue on endpoint ip-10-32-38-194.ore1.vpc.pivotal.io:21058 > exiting. Scheduling recovery. > [vm_2][info 2016/02/05 06:11:28.177 UTC > tid=0x2d9] Cache server on port 27,672 is shutting down. > [vm_3][warn 2016/02/05 06:11:28.178 UTC > tid=0x1e0] Could not connect to: ip-10-32-38-194.ore1.vpc.pivotal.io:27672 > [vm_3]java.io.EOFException > [vm_3]at java.io.DataInputStream.readBoolean(DataInputStream.java:244) > [vm_3]at > com.gemstone.gemfire.internal.cache.tier.sockets.HandShake.greet(HandShake.java:1343) > [vm_3]at > com.gemstone.gemfire.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:115) > [vm_3]at > com.gemstone.gemfire.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:144) > [vm_3]at > com.gemstone.gemfire.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:261) > [vm_3]at > com.gemstone.gemfire.cache.client.internal.pooling.ConnectionManagerImpl.prefillConnection(ConnectionManagerImpl.java:805) > [vm_3]at > com.gemstone.gemfire.cache.client.internal.pooling.ConnectionManagerImpl.prefill(ConnectionManagerImpl.java:748) > [vm_3]at > com.gemstone.gemfire.cache.client.internal.pooling.ConnectionManagerImpl$PrefillConnectionsTask.run2(ConnectionManagerImpl.java:899) > [vm_3]at > com.gemstone.gemfire.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1259) > [vm_3]at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [vm_3]at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [vm_3]at java.lang.Thread.run(Thread.java:745) > [vm_3][info 2016/02/05 06:11:28.179 UTC ip-10-32-38-194(18472):1028 port 27672> tid=0x1e7] Redundant > subscription endpoint ip-10-32-38-194.ore1.vpc.pivotal.io:27672 crashed. > Scheduling recovery. > [vm_3][warn 2016/02/05 06:11:28.179 UTC > tid=0x1e4] Pool unexpected closed socket on server > connection=Connection[ip-10-32-38-194.ore1.vpc.pivotal.io:27672]@211338577). > Server unreachable: could not connect after 1 attempts > [vm_3][info 2016/02/05 06:11:28.180 UTC > tid=0x1e4] SubscriptionManager redundancy satisfier - redundant endpoint has > been lost. Attempting to recover. > [vm_3][error 2016/02/05 06:11:28.180 UTC > tid=0x1e4] Could not find any server to create redundant client queue on. > Number of excluded servers is 3 and exception is no exception. > [vm_3][info 2016/02/05 06:11:28.180 UTC > tid=0x1e4] Redundancy level 1 is not satisfied, but there are no more servers > available. Redundancy is currently 0. > [vm_3][info 2016/02/05 06:11:28.181 UTC ip-10-32-38-194(18472):1028 port 27672> tid=0x1e7] Cache client > updater for Queue on endpoint ip-10-32-38-194.ore1.vpc.pivotal.io:27672 > exiting. Scheduling recovery. > [vm_2][fatal 2016/02/05 06:11:28.186 UTC Thread 0> tid=0x571] Server connection from > [identity(ip-10-32-38-194(18478):1029,connection=1; port=36151] : > Unexpected Error on server > [vm_2]com.gemstone.gemfire.InternalGemFireError: No cache client proxy on > this node for proxyId > identity(ip-10-32-38-194(18478):1029,connection=1 > [vm_2
[jira] [Resolved] (GEODE-921) InternalGemFireError: No cache client proxy on this node
[ https://issues.apache.org/jira/browse/GEODE-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Baynes resolved GEODE-921. Resolution: Cannot Reproduce > InternalGemFireError: No cache client proxy on this node > > > Key: GEODE-921 > URL: https://issues.apache.org/jira/browse/GEODE-921 > Project: Geode > Issue Type: Bug > Components: client/server >Reporter: Darrel Schneider >Assignee: William Markito Oliveira >Priority: Major > > On a private build of git rev ab25e41c6281ef90f04c7534e4d65ba4f24d7fc9 this > test CqDataUsingPoolOptimizedExecuteDUnitTest.testCQHAWithState failed with > the following suspect string. InternalGemFireError should never happen so > this bug should have a higher priority than most suspect string failures. > [vm_2][info 2016/02/05 06:11:28.175 UTC > tid=0x2d9] ### Close CacheServer. ### > [vm_3][info 2016/02/05 06:11:28.175 UTC ip-10-32-38-194(18458):1027 port 21058> tid=0x1e2] Redundant > subscription endpoint ip-10-32-38-194.ore1.vpc.pivotal.io:21058 crashed. > Scheduling recovery. > [vm_3][info 2016/02/05 06:11:28.175 UTC > tid=0x1e4] SubscriptionManager redundancy satisfier - primary endpoint has > been lost. Attempting to recover. > [vm_3][info 2016/02/05 06:11:28.177 UTC ip-10-32-38-194(18458):1027 port 21058> tid=0x1e2] Cache client > updater for Queue on endpoint ip-10-32-38-194.ore1.vpc.pivotal.io:21058 > exiting. Scheduling recovery. > [vm_2][info 2016/02/05 06:11:28.177 UTC > tid=0x2d9] Cache server on port 27,672 is shutting down. > [vm_3][warn 2016/02/05 06:11:28.178 UTC > tid=0x1e0] Could not connect to: ip-10-32-38-194.ore1.vpc.pivotal.io:27672 > [vm_3]java.io.EOFException > [vm_3]at java.io.DataInputStream.readBoolean(DataInputStream.java:244) > [vm_3]at > com.gemstone.gemfire.internal.cache.tier.sockets.HandShake.greet(HandShake.java:1343) > [vm_3]at > com.gemstone.gemfire.cache.client.internal.ConnectionImpl.connect(ConnectionImpl.java:115) > [vm_3]at > com.gemstone.gemfire.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:144) > [vm_3]at > com.gemstone.gemfire.cache.client.internal.ConnectionFactoryImpl.createClientToServerConnection(ConnectionFactoryImpl.java:261) > [vm_3]at > com.gemstone.gemfire.cache.client.internal.pooling.ConnectionManagerImpl.prefillConnection(ConnectionManagerImpl.java:805) > [vm_3]at > com.gemstone.gemfire.cache.client.internal.pooling.ConnectionManagerImpl.prefill(ConnectionManagerImpl.java:748) > [vm_3]at > com.gemstone.gemfire.cache.client.internal.pooling.ConnectionManagerImpl$PrefillConnectionsTask.run2(ConnectionManagerImpl.java:899) > [vm_3]at > com.gemstone.gemfire.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1259) > [vm_3]at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > [vm_3]at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > [vm_3]at java.lang.Thread.run(Thread.java:745) > [vm_3][info 2016/02/05 06:11:28.179 UTC ip-10-32-38-194(18472):1028 port 27672> tid=0x1e7] Redundant > subscription endpoint ip-10-32-38-194.ore1.vpc.pivotal.io:27672 crashed. > Scheduling recovery. > [vm_3][warn 2016/02/05 06:11:28.179 UTC > tid=0x1e4] Pool unexpected closed socket on server > connection=Connection[ip-10-32-38-194.ore1.vpc.pivotal.io:27672]@211338577). > Server unreachable: could not connect after 1 attempts > [vm_3][info 2016/02/05 06:11:28.180 UTC > tid=0x1e4] SubscriptionManager redundancy satisfier - redundant endpoint has > been lost. Attempting to recover. > [vm_3][error 2016/02/05 06:11:28.180 UTC > tid=0x1e4] Could not find any server to create redundant client queue on. > Number of excluded servers is 3 and exception is no exception. > [vm_3][info 2016/02/05 06:11:28.180 UTC > tid=0x1e4] Redundancy level 1 is not satisfied, but there are no more servers > available. Redundancy is currently 0. > [vm_3][info 2016/02/05 06:11:28.181 UTC ip-10-32-38-194(18472):1028 port 27672> tid=0x1e7] Cache client > updater for Queue on endpoint ip-10-32-38-194.ore1.vpc.pivotal.io:27672 > exiting. Scheduling recovery. > [vm_2][fatal 2016/02/05 06:11:28.186 UTC Thread 0> tid=0x571] Server connection from > [identity(ip-10-32-38-194(18478):1029,connection=1; port=36151] : > Unexpected Error on server > [vm_2]com.gemstone.gemfire.InternalGemFireError: No cache client proxy on > this node for proxyId > identity(ip-10-32-38-194(18478):1029,connection=1 > [vm_2]at > com.gemstone.gemfire.internal.cache.tier.sockets.CacheClientNotifier.makePrimary(CacheClientNotifier.java:711) > [vm_2]at > com.gemstone.gemfire.internal.cache.tier.soc
[jira] [Updated] (GEODE-4390) CI failure: PersistPRKRFDUnitTest.testCloseDiskStoreWhenPut fails with DiskAccessException
[
https://issues.apache.org/jira/browse/GEODE-4390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated GEODE-4390:
--
Labels: Flaky pull-request-available (was: Flaky)
> CI failure: PersistPRKRFDUnitTest.testCloseDiskStoreWhenPut fails with
> DiskAccessException
> --
>
> Key: GEODE-4390
> URL: https://issues.apache.org/jira/browse/GEODE-4390
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Nick Reich
>Priority: Major
> Labels: Flaky, pull-request-available
>
> Contents of the failure:
> {noformat}
> org.apache.geode.test.dunit.RMIException: While invoking
> org.apache.geode.test.dunit.NamedRunnable.run in VM 0 running on Host
> 7e1c6381c949 with 4 VMs
> at org.apache.geode.test.dunit.VM.invoke(VM.java:393)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:363)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:296)
> at
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionTestBase.checkData(PersistentPartitionedRegionTestBase.java:124)
> at
> org.apache.geode.internal.cache.partitioned.PersistentPartitionedRegionTestBase.checkData(PersistentPartitionedRegionTestBase.java:119)
> at
> org.apache.geode.internal.cache.partitioned.PersistPRKRFDUnitTest.testCloseDiskStoreWhenPut(PersistPRKRFDUnitTest.java:198)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57)
> at
> org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66)
> at
> org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
> at
> org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
> at
> org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
> at
> org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
> at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
> at
> org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
[jira] [Updated] (GEODE-4397) Extract many methods from RegionMapDestroy destroy
[ https://issues.apache.org/jira/browse/GEODE-4397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated GEODE-4397: -- Labels: pull-request-available (was: ) > Extract many methods from RegionMapDestroy destroy > -- > > Key: GEODE-4397 > URL: https://issues.apache.org/jira/browse/GEODE-4397 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > > Extract many methods from RegionMapDestroy destroy. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-1725) Need to look perf issue with InternalDistributedMember compare function
[ https://issues.apache.org/jira/browse/GEODE-1725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Baynes resolved GEODE-1725. - Resolution: Not A Problem No perf issues have been seen. Can reopen if this changes. > Need to look perf issue with InternalDistributedMember compare function > --- > > Key: GEODE-1725 > URL: https://issues.apache.org/jira/browse/GEODE-1725 > Project: Geode > Issue Type: Bug > Components: membership >Reporter: Hitesh Khamesra >Priority: Major > > Recently we removed the stub class, which was wrapper around > InternalDistributedMember. Need to investigate whether that caused some perf > issue. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4429) Remove redundant modifiers from geode-core:cache
[ https://issues.apache.org/jira/browse/GEODE-4429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347436#comment-16347436 ] ASF subversion and git services commented on GEODE-4429: Commit de9d814ea1a313a2ad36ab062d8b4e1225b766d0 in geode's branch refs/heads/develop from [~prhomberg] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=de9d814 ] GEODE-4429: Remove unnecessary modifiers from interfaces in geode-core:cache * This excludes those interfaces in geode-core:internal.cache, as covered in GEODE-4430 > Remove redundant modifiers from geode-core:cache > > > Key: GEODE-4429 > URL: https://issues.apache.org/jira/browse/GEODE-4429 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4430) Remove redundant modifiers from geode-core:internal.cache
[ https://issues.apache.org/jira/browse/GEODE-4430?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347437#comment-16347437 ] ASF subversion and git services commented on GEODE-4430: Commit de9d814ea1a313a2ad36ab062d8b4e1225b766d0 in geode's branch refs/heads/develop from [~prhomberg] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=de9d814 ] GEODE-4429: Remove unnecessary modifiers from interfaces in geode-core:cache * This excludes those interfaces in geode-core:internal.cache, as covered in GEODE-4430 > Remove redundant modifiers from geode-core:internal.cache > - > > Key: GEODE-4430 > URL: https://issues.apache.org/jira/browse/GEODE-4430 > Project: Geode > Issue Type: Sub-task >Reporter: Patrick Rhomberg >Priority: Major > Labels: pull-request-available > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-2151) PartitionedRegionLoadModelJUnitTest fails depending on /etc/hosts config
[
https://issues.apache.org/jira/browse/GEODE-2151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan resolved GEODE-2151.
-
Resolution: Workaround
Not sure if this is fixed or not, but the workaround seems to have been working.
> PartitionedRegionLoadModelJUnitTest fails depending on /etc/hosts config
>
>
> Key: GEODE-2151
> URL: https://issues.apache.org/jira/browse/GEODE-2151
> Project: Geode
> Issue Type: Bug
> Components: membership, messaging
>Reporter: Galen O'Sullivan
>Priority: Major
>
> I was getting the following error while running the unit tests:
> {code}
> org.apache.geode.internal.cache.partitioned.PartitionedRegionLoadModelJUnitTest
> > testRedundancySatisfactionPreferRemoteIp FAILED
> java.lang.AssertionError:
> expected:<[Create[member=192.168.1.50(41227):3,bucketId=0],
> Create[member=192.168.1.50(41227):3,bucketId=1],
> Create[member=192.168.1.50(41227):3,bucketId=2]]> but
> was:<[Create[member=192.168.1.50(41227):3,bucketId=0],
> Create[member=192.168.1.50(41227):1,bucketId=1],
> Create[member=192.168.1.50(41227):3,bucketId=2]]>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at
> org.apache.geode.internal.cache.partitioned.PartitionedRegionLoadModelJUnitTest.testRedundancySatisfactionPreferRemoteIp(PartitionedRegionLoadModelJUnitTest.java:227)
> 2931 tests completed, 1 failed, 10 skipped
> {code}
> My `/etc/hosts` file had the following line:
> {code}
> 127.0.0.1 localhost gosullivan-mbpro
> {code}
> Changing it to this fixed the problem:
> {code}
> 127.0.0.1 localhost
> 255.255.255.255 broadcasthost
> ::1 localhost
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-1550) CI Failure: MembershipJUnitTest.testMultipleManagersInSameProcess assertion failure
[ https://issues.apache.org/jira/browse/GEODE-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Baynes resolved GEODE-1550. - Resolution: Fixed > CI Failure: MembershipJUnitTest.testMultipleManagersInSameProcess assertion > failure > --- > > Key: GEODE-1550 > URL: https://issues.apache.org/jira/browse/GEODE-1550 > Project: Geode > Issue Type: Bug > Components: membership, messaging >Reporter: Scott Jewell >Priority: Major > Labels: CI > > java.lang.AssertionError: Expected a multicast message to be received > at org.junit.Assert.fail(Assert.java:88) > at > com.gemstone.gemfire.distributed.internal.membership.MembershipJUnitTest.testMultipleManagersInSameProcess(MembershipJUnitTest.java:178) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:112) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:56) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.messaging.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) > at > org.gradle.messaging.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93) > at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) > at > org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.messaging.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:360) > at > org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:54) > at > org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableExecutorImpl.java:40) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at > java.util.concurrent.Thread
[jira] [Commented] (GEODE-4364) Extract destroy operation to its own class
[ https://issues.apache.org/jira/browse/GEODE-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347409#comment-16347409 ] ASF subversion and git services commented on GEODE-4364: Commit 21e2e0ae73a155b0c072e385544f3fb0d382c4e0 in geode's branch refs/heads/develop from [~apa...@the9muses.net] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=21e2e0a ] GEODE-4364: extract RegionMapDestroy and add RegionMapDestroyTest (#1347) > Extract destroy operation to its own class > -- > > Key: GEODE-4364 > URL: https://issues.apache.org/jira/browse/GEODE-4364 > Project: Geode > Issue Type: Sub-task > Components: regions >Reporter: Kirk Lund >Assignee: Kirk Lund >Priority: Major > Labels: pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > > Extract body of AbstractRegionMap.destroy method to new RegionMapDestroy > class in org.apache.geode.internal.cache.map package. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3464) If multiple MessageHandlers are found user should see exception
[ https://issues.apache.org/jira/browse/GEODE-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan resolved GEODE-3464. - Resolution: Invalid I think this ticket is about new-client-protocol code; We changed the ops registry to be static rather than dynamic, so this is no longer an issue. > If multiple MessageHandlers are found user should see exception > --- > > Key: GEODE-3464 > URL: https://issues.apache.org/jira/browse/GEODE-3464 > Project: Geode > Issue Type: New Feature > Components: client/server >Reporter: Alexander Murmann >Assignee: Udo Kohlmeyer >Priority: Major > > Currently the system will use the first MessageHandler it finds. If there are > multiple it's unclear which one will be used, resulting in potentially > nondeterministic behavior. Instead a exception should be thrown if multiple > handlers are present. That behavior is still not ideal, but at least it's > deterministic. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3285) New protocol authentication with SASL
[ https://issues.apache.org/jira/browse/GEODE-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Baynes resolved GEODE-3285. - Resolution: Won't Do Implemented basic auth that works with Geode's existing security manager. > New protocol authentication with SASL > - > > Key: GEODE-3285 > URL: https://issues.apache.org/jira/browse/GEODE-3285 > Project: Geode > Issue Type: Wish > Components: client/server >Reporter: Brian Baynes >Priority: Major > > As a user of the new client/server protocol, I need to be able to > authenticate clients to my grid. Using a standard framework with minimal > upfront setup would be most preferred. > Implement client authentication using SASL (Simple Authentication and > Security Layer) and the PLAIN mechanism. SASL should tie into existing > security manager for processing auth. Protocol clients should be able to > pass user/pass and authenticate the socket in use. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-1807) CI Failure: RedisDistDUnitTest.testConcListOps
[ https://issues.apache.org/jira/browse/GEODE-1807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan resolved GEODE-1807. - Resolution: Duplicate > CI Failure: RedisDistDUnitTest.testConcListOps > -- > > Key: GEODE-1807 > URL: https://issues.apache.org/jira/browse/GEODE-1807 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: nabarun >Priority: Major > Labels: CI > > com.gemstone.gemfire.test.dunit.RMIException: While invoking > org.apache.geode.redis.RedisDistDUnitTest$1ConcListOps.call in VM 3 running > on Host rooktwo.gemstone.com with 4 VMs > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:389) > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:355) > at com.gemstone.gemfire.test.dunit.VM.invoke(VM.java:320) > at > org.apache.geode.redis.RedisDistDUnitTest.testConcListOps(RedisDistDUnitTest.java:137) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55) > at org.junit.rules.RunRules.evaluate(RunRules.java:20) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) > at > org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93) > at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) > at > org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:377) > at
[jira] [Resolved] (GEODE-2435) Redis adapter MULTI behavior is different from Redis
[
https://issues.apache.org/jira/browse/GEODE-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan resolved GEODE-2435.
-
Resolution: Later
No one is working on Redis support right now (or is expected to for the
forseeable future), this can be reopened if someone wants to work on it.
> Redis adapter MULTI behavior is different from Redis
>
>
> Key: GEODE-2435
> URL: https://issues.apache.org/jira/browse/GEODE-2435
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: Galen O'Sullivan
>Priority: Major
>
> {{WATCH}} isn't implemented properly, but this is about returning an error
> instead of nil when we have a {{MULTI}} fail:
> {code}
> $ redis-cli -p 11212
> 127.0.0.1:11212> set a b
> OK
> 127.0.0.1:11212> watch a
> (error) ERR Keys cannot be watched or unwatched because GemFire watches all
> keys by default for transactions
> 127.0.0.1:11212> lpush la boo
> (integer) 1
> (2.09s)
> 127.0.0.1:11212> multi
> OK
> 127.0.0.1:11212> lpush la z
> QUEUED
> 127.0.0.1:11212> lpush la x
> QUEUED
> {code}
> At this point, we {{lpush la foo}} in a different client, then:
> {code}
> 127.0.0.1:11212> exec
> 1) (error) ERR The server had an internal error please try again
> 2) (error) ERR The server had an internal error please try again
> 127.0.0.1:11212>
> {code}
> whereas a Redis instance will simply return nil instead of an error.
> Looking in the logs, I see this:
> {code}
> [error 2017/02/06 13:21:39.493 PST server2
> tid=0x2a] GeodeRedisServer-Unexpected error handler for [id: 0x3ddf9f21,
> /127.0.0.1:58862 => /127.0.0.1:11212]
> java.lang.UnsupportedOperationException: Operations on persist-backup regions
> are not allowed because this thread has an active transaction
> at
> org.apache.geode.internal.cache.TXRegionState.(TXRegionState.java:60)
> at
> org.apache.geode.internal.cache.TXBucketRegionState.(TXBucketRegionState.java:29)
> at org.apache.geode.internal.cache.TXState.writeRegion(TXState.java:252)
> at
> org.apache.geode.internal.cache.TXState.txWriteRegion(TXState.java:1110)
> at
> org.apache.geode.internal.cache.TXState.txReadEntry(TXState.java:1365)
> at
> org.apache.geode.internal.cache.TXState.txReadEntry(TXState.java:1344)
> at
> org.apache.geode.internal.cache.TXState.getDeserializedValue(TXState.java:1414)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.getDeserializedValue(TXStateProxyImpl.java:352)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1394)
> at
> org.apache.geode.internal.cache.PartitionedRegionDataStore.getLocally(PartitionedRegionDataStore.java:2047)
> at
> org.apache.geode.internal.cache.PartitionedRegion.getFromBucket(PartitionedRegion.java:4022)
> at
> org.apache.geode.internal.cache.PartitionedRegion.findObjectInSystem(PartitionedRegion.java:3399)
> at org.apache.geode.internal.cache.TXState.findObject(TXState.java:1540)
> at
> org.apache.geode.internal.cache.TXStateProxyImpl.findObject(TXStateProxyImpl.java:614)
> at
> org.apache.geode.internal.cache.PartitionedRegion.get(PartitionedRegion.java:3160)
> at
> org.apache.geode.internal.cache.LocalRegion.get(LocalRegion.java:1330)
> at
> org.apache.geode.internal.cache.AbstractRegion.get(AbstractRegion.java:282)
> at
> org.apache.geode.redis.internal.executor.list.ListExecutor.pushElements(ListExecutor.java:70)
> at
> org.apache.geode.redis.internal.executor.list.PushExecutor.executeCommand(PushExecutor.java:47)
> at
> org.apache.geode.redis.internal.ExecutionHandlerContext.executeWithTransaction(ExecutionHandlerContext.java:244)
> at
> org.apache.geode.redis.internal.ExecutionHandlerContext.executeCommand(ExecutionHandlerContext.java:191)
> at
> org.apache.geode.redis.internal.ExecutionHandlerContext.channelRead(ExecutionHandlerContext.java:137)
> at
> io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:368)
> at
> io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:353)
> at
> io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:173)
> at
> io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:368)
> at
> io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:353)
> at
> io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:780)
> at
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:100)
> at
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:497)
> at
[jira] [Resolved] (GEODE-2447) Breakout redisMetaRegion to improve performance
[ https://issues.apache.org/jira/browse/GEODE-2447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan resolved GEODE-2447. - Resolution: Won't Fix No one is working on Redis support right now (or is expected to for the forseeable future), this can be reopened if someone wants to work on it. > Breakout redisMetaRegion to improve performance > --- > > Key: GEODE-2447 > URL: https://issues.apache.org/jira/browse/GEODE-2447 > Project: Geode > Issue Type: Sub-task > Components: redis >Reporter: Addison >Priority: Major > > Currently, we have a metadata region that st ores each key inserted by Redis > and its type. There is an additional region where all strings are stored, and > one where hyperLogLogs are stored. Each list/set/hash creates a table with > its name. > Consider resolving into a single table or at least namespacing -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-2450) Redis Adapter should align with Redis defaults
[ https://issues.apache.org/jira/browse/GEODE-2450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan resolved GEODE-2450. - Resolution: Won't Fix No one is working on Redis support right now (or is expected to for the forseeable future), this can be reopened if someone wants to work on it. > Redis Adapter should align with Redis defaults > -- > > Key: GEODE-2450 > URL: https://issues.apache.org/jira/browse/GEODE-2450 > Project: Geode > Issue Type: Sub-task > Components: redis >Reporter: Addison >Priority: Major > > 1. Persistent disk > ... investigate other defaults -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-2449) Move redis adapter to extension framework
[ https://issues.apache.org/jira/browse/GEODE-2449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan resolved GEODE-2449. - Resolution: Won't Fix No one is working on Redis support right now (or is expected to for the forseeable future), this can be reopened if someone wants to work on it. > Move redis adapter to extension framework > - > > Key: GEODE-2449 > URL: https://issues.apache.org/jira/browse/GEODE-2449 > Project: Geode > Issue Type: Sub-task > Components: redis >Reporter: Addison >Assignee: Udo Kohlmeyer >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-1942) CI Failure: org.apache.geode.redis.HashesJUnitTest.testHIncrBy
[ https://issues.apache.org/jira/browse/GEODE-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan resolved GEODE-1942. - Resolution: Won't Fix No one is working on Redis support right now (or is expected to for the forseeable future), this can be reopened if someone wants to work on it. > CI Failure: org.apache.geode.redis.HashesJUnitTest.testHIncrBy > -- > > Key: GEODE-1942 > URL: https://issues.apache.org/jira/browse/GEODE-1942 > Project: Geode > Issue Type: Bug > Components: redis >Reporter: Bruce Schuchardt >Priority: Major > Labels: CI > > Error Message > redis.clients.jedis.exceptions.JedisConnectionException: > java.net.SocketTimeoutException: Read timed out > Stacktrace > redis.clients.jedis.exceptions.JedisConnectionException: > java.net.SocketTimeoutException: Read timed out > at > redis.clients.util.RedisInputStream.ensureFill(RedisInputStream.java:201) > at > redis.clients.util.RedisInputStream.readByte(RedisInputStream.java:40) > at redis.clients.jedis.Protocol.process(Protocol.java:132) > at redis.clients.jedis.Protocol.read(Protocol.java:196) > at > redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:288) > at redis.clients.jedis.Connection.getIntegerReply(Connection.java:213) > at redis.clients.jedis.Jedis.hincrBy(Jedis.java:675) > at > org.apache.geode.redis.HashesJUnitTest.testHIncrBy(HashesJUnitTest.java:143) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.runTestClass(JUnitTestClassExecuter.java:114) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecuter.execute(JUnitTestClassExecuter.java:57) > at > org.gradle.api.internal.tasks.testing.junit.JUnitTestClassProcessor.processTestClass(JUnitTestClassProcessor.java:66) > at > org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35) > at > org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24) > at > org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32) > at > org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93) > at com.sun.proxy.$Proxy2.processTestClass(Unknown Source) > at > org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:109) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.
[jira] [Resolved] (GEODE-1113) Redis Adapter region creation performance problems
[
https://issues.apache.org/jira/browse/GEODE-1113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan resolved GEODE-1113.
-
Resolution: Duplicate
No one is working on Redis support right now (or is expected to for the
forseeable future), this can be reopened if someone wants to work on it.
> Redis Adapter region creation performance problems
> --
>
> Key: GEODE-1113
> URL: https://issues.apache.org/jira/browse/GEODE-1113
> Project: Geode
> Issue Type: Bug
> Components: redis
>Reporter: William Markito Oliveira
>Priority: Major
> Labels: gsoc2016, low-hanging-fruit
>
> {code}com.gemstone.gemfire.internal.redis.RegionProvider.java{code} is using
> gfsh command to create region which is slow and caused some perf. problems
> for Redis operations.
> The attached patch replace it with {code}RegionFactory{code} which fix the
> perf problem but doesn't work with cluster config.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-2528) modify redis server threads to use thread-owned resources
[ https://issues.apache.org/jira/browse/GEODE-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan resolved GEODE-2528. - Resolution: Later No one is working on Redis support right now (or is expected to for the forseeable future), this can be reopened if someone wants to work on it. > modify redis server threads to use thread-owned resources > - > > Key: GEODE-2528 > URL: https://issues.apache.org/jira/browse/GEODE-2528 > Project: Geode > Issue Type: Sub-task > Components: redis >Reporter: Bruce Schuchardt >Priority: Major > > The Redis adapter's server threads are not configured for thread-owned > resources so they are all contending for the same sockets when replicating or > performing one-hop operations. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-2495) Determine which Redis commands are implemented
[ https://issues.apache.org/jira/browse/GEODE-2495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan resolved GEODE-2495. - Resolution: Later No one is working on Redis support right now (or is expected to for the forseeable future), this can be reopened if someone wants to work on it. > Determine which Redis commands are implemented > -- > > Key: GEODE-2495 > URL: https://issues.apache.org/jira/browse/GEODE-2495 > Project: Geode > Issue Type: Sub-task > Components: redis >Reporter: Bruce Schuchardt >Priority: Major > > The documentation for the Geode redis adapter does not spell out which > commands are supported and which are not supported. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-2473) redis-cli hangs if Geode unable to process command properly
[ https://issues.apache.org/jira/browse/GEODE-2473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan resolved GEODE-2473. - Resolution: Later No one is working on Redis support right now, this can be reopened if someone wants to work on it. > redis-cli hangs if Geode unable to process command properly > --- > > Key: GEODE-2473 > URL: https://issues.apache.org/jira/browse/GEODE-2473 > Project: Geode > Issue Type: Sub-task > Components: redis >Reporter: Hitesh Khamesra >Priority: Major > > Here is the command "HSET companies:1000 name "John Smith"" > "GeodeRedisServer-WorkerThread-1" #86 prio=5 os_prio=0 tid=0x7f1a20002800 > nid=0x4750 sleeping[0x7f1bf0dd9000] >java.lang.Thread.State: TIMED_WAITING (sleeping) > at java.lang.Thread.sleep(Native Method) > at > org.apache.geode.management.internal.cli.commands.CreateAlterDestroyRegionCommands.verifyDistributedRegionMbean(CreateAlterDestroyRegionCommands.java:410) > at > org.apache.geode.management.internal.cli.commands.CreateAlterDestroyRegionCommands.createRegion(CreateAlterDestroyRegionCommands.java:371) > at > org.apache.geode.redis.internal.RegionProvider.createRegionGlobally(RegionProvider.java:405) > at > org.apache.geode.redis.internal.RegionProvider.getOrCreateRegion0(RegionProvider.java:292) > at > org.apache.geode.redis.internal.RegionProvider.getOrCreateRegion(RegionProvider.java:212) > at > org.apache.geode.redis.internal.executor.hash.HashExecutor.getOrCreateRegion(HashExecutor.java:31) > at > org.apache.geode.redis.internal.executor.hash.HSetExecutor.executeCommand(HSetExecutor.java:48) > at > org.apache.geode.redis.internal.ExecutionHandlerContext.executeWithoutTransaction(ExecutionHandlerContext.java:235) > at > org.apache.geode.redis.internal.ExecutionHandlerContext.executeCommand(ExecutionHandlerContext.java:199) > at > org.apache.geode.redis.internal.ExecutionHandlerContext.channelRead(ExecutionHandlerContext.java:139) > at > io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:368) > at > io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:353) > at > io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:173) > at > io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:368) > at > io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:353) > at > io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:780) > at > io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:100) > at > io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:497) > at > io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:465) > at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:359) > at > io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101) > at java.lang.Thread.run(Thread.java:745) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-2469) Redis adapter Hash key support
[
https://issues.apache.org/jira/browse/GEODE-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan resolved GEODE-2469.
-
Resolution: Won't Fix
No one is working on Redis support right now, this can be reopened if someone
wants to work on it.
> Redis adapter Hash key support
> --
>
> Key: GEODE-2469
> URL: https://issues.apache.org/jira/browse/GEODE-2469
> Project: Geode
> Issue Type: Sub-task
> Components: redis
>Reporter: Gregory Green
>Assignee: Hitesh Khamesra
>Priority: Major
>
> The Redis adapter does not appear to handle hash keys correctly.
> The following Example: Redis CLI works.
> localhost:11211> HSET companies name "John Smith"
> Using a HSET :id .. produces an error
> Example:
> localhost:11211> HSET companies:1000 name "John Smith"
> [Server error]
> [fine 2017/02/10 16:04:33.289 EST server1
> tid=0x6a] Region names may only be alphanumeric and may contain hyphens or
> underscores: companies: 1000
> java.lang.IllegalArgumentException: Region names may only be alphanumeric and
> may contain hyphens or underscores: companies: 1000
> at
> org.apache.geode.internal.cache.LocalRegion.validateRegionName(LocalRegion.java:7618)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3201)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:3181)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:3169)
> at org.apache.geode.cache.RegionFactory.create(RegionFactory.java:762)
> at
> org.apache.geode.management.internal.cli.functions.RegionCreateFunction.createRegion(RegionCreateFunction.java:355)
> at
> org.apache.geode.management.internal.cli.functions.RegionCreateFunction.execute(RegionCreateFunction.java:90)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution.executeFunctionLocally(AbstractExecution.java:333)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution$2.run(AbstractExecution.java:303)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:621)
> at
> org.apache.geode.distributed.internal.DistributionManager$9$1.run(DistributionManager.java:1067)
> at java.lang.Thread.run(Thread.java:745)
> //Example Spring Data Redis Object sample
> @Data
> @EqualsAndHashCode()
> @RedisHash(value="companies")
> @NoArgsConstructor
> public class Company
> {
> private @Id String id;
>
> //Repository
> public interface CompanyRepository extends CrudRepository
> {
>
> }
> //When saving using a repository
> repository.save(this.myCompany);
> [Same Server error]
> java.lang.IllegalArgumentException: Region names may only be alphanumeric and
> may contain hyphens or underscores:
> companies:f05405c2-86f2-4aaf-bd0c-6fecd483bf28
> at
> org.apache.geode.internal.cache.LocalRegion.validateRegionName(LocalRegion.java:7618)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3201)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:3181)
> at
> org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:3169)
> at org.apache.geode.cache.RegionFactory.create(RegionFactory.java:762)
> at
> org.apache.geode.management.internal.cli.functions.RegionCreateFunction.createRegion(RegionCreateFunction.java:355)
> at
> org.apache.geode.management.internal.cli.functions.RegionCreateFunction.execute(RegionCreateFunction.java:90)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution.executeFunctionLocally(AbstractExecution.java:333)
> at
> org.apache.geode.internal.cache.execute.AbstractExecution$2.run(AbstractExecution.java:303)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at
> org.apache.geode.distributed.internal.DistributionManager.runUntilShutdown(DistributionManager.java:621)
> at
> org.apache.geode.distributed.internal.DistributionManager$9$1.run(DistributionManager.java:1067)
> at java.lang.Thread.run(Thread.java:745)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-2464) Review Redis tests
[
https://issues.apache.org/jira/browse/GEODE-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan resolved GEODE-2464.
-
Resolution: Later
No one is working on Redis support right now, this can be reopened if someone
wants to work on it.
> Review Redis tests
> --
>
> Key: GEODE-2464
> URL: https://issues.apache.org/jira/browse/GEODE-2464
> Project: Geode
> Issue Type: Sub-task
> Components: redis
>Reporter: Galen O'Sullivan
>Priority: Major
>
> The existing Redis tests could use some cleanup and probably expansion.
> * [~ukohlmeyer] and I ([~gosullivan]) did some common test code with
> `RedisTestBase`; there is probably some room for improvement there.
> * There is a lot of repetition in the test code for the Redis adapter. We can
> improve this.
> * Randomization: use junit-quickcheck {{@Property}} tests?
> * Make sure every Redis command gets tested.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (GEODE-3862) setbit command with redis adaptor kills the server when using WAN replication
[
https://issues.apache.org/jira/browse/GEODE-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347345#comment-16347345
]
Brian Baynes commented on GEODE-3862:
-
No one is working on Redis support right now – this can be reopened if someone
wants to work on it.
> setbit command with redis adaptor kills the server when using WAN replication
> -
>
> Key: GEODE-3862
> URL: https://issues.apache.org/jira/browse/GEODE-3862
> Project: Geode
> Issue Type: Bug
> Components: redis, wan
>Affects Versions: 1.2.1
>Reporter: shivam mitra
>Priority: Major
>
> I have created a WAN cluster with redis adaptor over cache servers.
> Everything works well except for the setbit command.
> /*
> * To change this license header, choose License Headers in Project
> Properties.
> * To change this template file, choose Tools | Templates
> * and open the template in the editor.
> */
> package test;
> import redis.clients.jedis.*;
> import redis.clients.jedis.exceptions.JedisException;
> import java.util.HashMap;
> import java.util.Map;
> import java.util.Set;
> import redis.clients.jedis.exceptions.JedisException;
> public class Test {
> //address of your redis server
> private static final String redisHost = "redis_ip";
> private static final Integer redisPort = 11211;
> public void addSets() {
> JedisPoolConfig poolConfig = new JedisPoolConfig();
> poolConfig.setMaxIdle(50);
> poolConfig.setMaxTotal(1000);
> poolConfig.setTestOnBorrow(true);
> poolConfig.setTestOnReturn(true);
> JedisPool pool = new JedisPool(poolConfig,redisHost, redisPort);
> Jedis jedis= null;
> String key = "xT|0|BloomFilter";
> long [] bits =
> {1464236631,12373513,1488983657,1329373495,147236649,1623846793,1194510359,282099785,1758709929,1059647223,416962921,1893573065,924784087,551826057,2028436201};
>
>
> //get a jedis connection jedis connection pool
> try {
> jedis = pool.getResource();
> Pipeline pipeline = jedis.pipelined();
> for (long b : bits) {
>
> pipeline.setbit(key, b, true);
> }
> pipeline.multi();
> pipeline.exec();
> } finally {
> if (jedis != null) {
> jedis.close();
> }
> }
>
> }
> public static void main(String[] args){
> Test main = new Test();
> main.addSets();
> //main.addHash();
> }
> }
> But the server crashes and I get the following error in java program.
> Exception in thread "main" redis.clients.jedis.exceptions.JedisException:
> Could not return the resource to the pool
> at redis.clients.jedis.JedisPool.returnResource(JedisPool.java:256)
> at redis.clients.jedis.JedisPool.returnResource(JedisPool.java:16)
> at redis.clients.jedis.Jedis.close(Jedis.java:3409)
> at test.Test.addSets(Test.java:47)
> at test.Test.main(Test.java:54)
> Caused by: redis.clients.jedis.exceptions.JedisConnectionException:
> java.net.SocketTimeoutException: Read timed out
> at
> redis.clients.util.RedisInputStream.ensureFill(RedisInputStream.java:202)
> at
> redis.clients.util.RedisInputStream.readByte(RedisInputStream.java:40)
> at redis.clients.jedis.Protocol.process(Protocol.java:151)
> at redis.clients.jedis.Protocol.read(Protocol.java:215)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:340)
> at redis.clients.jedis.Connection.getAll(Connection.java:310)
> at redis.clients.jedis.Connection.getAll(Connection.java:302)
> at redis.clients.jedis.Pipeline.sync(Pipeline.java:99)
> at redis.clients.jedis.Pipeline.clear(Pipeline.java:85)
> at redis.clients.jedis.BinaryJedis.resetState(BinaryJedis.java:1781)
> at redis.clients.jedis.JedisPool.returnResource(JedisPool.java:252)
> ... 4 more
> Caused by: java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
> at java.net.SocketInputStream.read(SocketInputStream.java:171)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at java.net.SocketInputStream.read(SocketInputStream.java:127)
> at
> redis.clients.util.RedisInputStream.ensureFill(RedisInputStream.java:196)
> ... 14 more
> I get the following in redis.logs:
> [finest 2017/10/18 11:21:40.947 UTC redis GatewaySender_dc1.3> tid=0x58] SerialGatewaySender queue
> :dc1.3_SERIAL_GATEWAY_SENDER_QUEUE: Determined tail key: 0
> [fine 2017/10/18 11:21:40.947 UTC redis G
[jira] [Resolved] (GEODE-2463) Review Netty shutdown in GeodeRedisServiceImpl
[
https://issues.apache.org/jira/browse/GEODE-2463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Galen O'Sullivan resolved GEODE-2463.
-
Resolution: Fixed
No one is working on Redis support right now, this can be reopened if someone
wants to work on it.
> Review Netty shutdown in GeodeRedisServiceImpl
> --
>
> Key: GEODE-2463
> URL: https://issues.apache.org/jira/browse/GEODE-2463
> Project: Geode
> Issue Type: Sub-task
> Components: redis
>Reporter: Galen O'Sullivan
>Priority: Major
>
> Do this after [GEODE-2449].
> in {{GeodeRedisServiceImpl.stop()}}:
> The old code used to call {{syncUninterruptibly}} on the workerGroup,
> bossGroup, and serverChannel. However, the close method is likely being
> called as the result of a shutdown message on the channel future, and we
> can't call netty sync / await on an I/O thread. We saw deadlocks in testing.
> Look into this and make sure we're shutting down right.
> http://netty.io/wiki/index.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (GEODE-2444) Making Redis Adapter easier to use and more robust
[ https://issues.apache.org/jira/browse/GEODE-2444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan resolved GEODE-2444. - Resolution: Later No one is working on Redis support right now, this can be reopened if someone wants to work on it. > Making Redis Adapter easier to use and more robust > -- > > Key: GEODE-2444 > URL: https://issues.apache.org/jira/browse/GEODE-2444 > Project: Geode > Issue Type: Wish > Components: redis >Reporter: Addison >Priority: Major > > The goal of this effort is to further test and complete the Redis Adapter to > make the code more readable and performant. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-2451) Improve storage of key/values
[ https://issues.apache.org/jira/browse/GEODE-2451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan resolved GEODE-2451. - Resolution: Later No one is working on Redis support right now, this can be reopened if someone wants to work on it. > Improve storage of key/values > - > > Key: GEODE-2451 > URL: https://issues.apache.org/jira/browse/GEODE-2451 > Project: Geode > Issue Type: Sub-task > Components: redis >Reporter: Addison >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-2448) Improve performance of redis command lookup
[ https://issues.apache.org/jira/browse/GEODE-2448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan resolved GEODE-2448. - Resolution: Later No one is working on Redis support right now, this can be reopened if someone wants to work on it. > Improve performance of redis command lookup > --- > > Key: GEODE-2448 > URL: https://issues.apache.org/jira/browse/GEODE-2448 > Project: Geode > Issue Type: Sub-task > Components: redis >Reporter: Addison >Priority: Major > > Consensus seems to be that we should convert to String when we take commands > in, to avoid extra work. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3862) setbit command with redis adaptor kills the server when using WAN replication
[
https://issues.apache.org/jira/browse/GEODE-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Baynes resolved GEODE-3862.
-
Resolution: Won't Fix
> setbit command with redis adaptor kills the server when using WAN replication
> -
>
> Key: GEODE-3862
> URL: https://issues.apache.org/jira/browse/GEODE-3862
> Project: Geode
> Issue Type: Bug
> Components: redis, wan
>Affects Versions: 1.2.1
>Reporter: shivam mitra
>Priority: Major
>
> I have created a WAN cluster with redis adaptor over cache servers.
> Everything works well except for the setbit command.
> /*
> * To change this license header, choose License Headers in Project
> Properties.
> * To change this template file, choose Tools | Templates
> * and open the template in the editor.
> */
> package test;
> import redis.clients.jedis.*;
> import redis.clients.jedis.exceptions.JedisException;
> import java.util.HashMap;
> import java.util.Map;
> import java.util.Set;
> import redis.clients.jedis.exceptions.JedisException;
> public class Test {
> //address of your redis server
> private static final String redisHost = "redis_ip";
> private static final Integer redisPort = 11211;
> public void addSets() {
> JedisPoolConfig poolConfig = new JedisPoolConfig();
> poolConfig.setMaxIdle(50);
> poolConfig.setMaxTotal(1000);
> poolConfig.setTestOnBorrow(true);
> poolConfig.setTestOnReturn(true);
> JedisPool pool = new JedisPool(poolConfig,redisHost, redisPort);
> Jedis jedis= null;
> String key = "xT|0|BloomFilter";
> long [] bits =
> {1464236631,12373513,1488983657,1329373495,147236649,1623846793,1194510359,282099785,1758709929,1059647223,416962921,1893573065,924784087,551826057,2028436201};
>
>
> //get a jedis connection jedis connection pool
> try {
> jedis = pool.getResource();
> Pipeline pipeline = jedis.pipelined();
> for (long b : bits) {
>
> pipeline.setbit(key, b, true);
> }
> pipeline.multi();
> pipeline.exec();
> } finally {
> if (jedis != null) {
> jedis.close();
> }
> }
>
> }
> public static void main(String[] args){
> Test main = new Test();
> main.addSets();
> //main.addHash();
> }
> }
> But the server crashes and I get the following error in java program.
> Exception in thread "main" redis.clients.jedis.exceptions.JedisException:
> Could not return the resource to the pool
> at redis.clients.jedis.JedisPool.returnResource(JedisPool.java:256)
> at redis.clients.jedis.JedisPool.returnResource(JedisPool.java:16)
> at redis.clients.jedis.Jedis.close(Jedis.java:3409)
> at test.Test.addSets(Test.java:47)
> at test.Test.main(Test.java:54)
> Caused by: redis.clients.jedis.exceptions.JedisConnectionException:
> java.net.SocketTimeoutException: Read timed out
> at
> redis.clients.util.RedisInputStream.ensureFill(RedisInputStream.java:202)
> at
> redis.clients.util.RedisInputStream.readByte(RedisInputStream.java:40)
> at redis.clients.jedis.Protocol.process(Protocol.java:151)
> at redis.clients.jedis.Protocol.read(Protocol.java:215)
> at
> redis.clients.jedis.Connection.readProtocolWithCheckingBroken(Connection.java:340)
> at redis.clients.jedis.Connection.getAll(Connection.java:310)
> at redis.clients.jedis.Connection.getAll(Connection.java:302)
> at redis.clients.jedis.Pipeline.sync(Pipeline.java:99)
> at redis.clients.jedis.Pipeline.clear(Pipeline.java:85)
> at redis.clients.jedis.BinaryJedis.resetState(BinaryJedis.java:1781)
> at redis.clients.jedis.JedisPool.returnResource(JedisPool.java:252)
> ... 4 more
> Caused by: java.net.SocketTimeoutException: Read timed out
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
> at java.net.SocketInputStream.read(SocketInputStream.java:171)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at java.net.SocketInputStream.read(SocketInputStream.java:127)
> at
> redis.clients.util.RedisInputStream.ensureFill(RedisInputStream.java:196)
> ... 14 more
> I get the following in redis.logs:
> [finest 2017/10/18 11:21:40.947 UTC redis GatewaySender_dc1.3> tid=0x58] SerialGatewaySender queue
> :dc1.3_SERIAL_GATEWAY_SENDER_QUEUE: Determined tail key: 0
> [fine 2017/10/18 11:21:40.947 UTC redis GatewaySender_dc1.3> tid=0x58] SerialGatewaySender queue
> :dc1.3_SERIAL_GATEWAY_SENDER_QUEUE: Peeked 0->null
> [finest 2017/10/18
[jira] [Resolved] (GEODE-4375) Mismatch deserialization of TxCommitMessage
[ https://issues.apache.org/jira/browse/GEODE-4375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darrel Schneider resolved GEODE-4375. - Resolution: Fixed Fix Version/s: 1.5.0 > Mismatch deserialization of TxCommitMessage > --- > > Key: GEODE-4375 > URL: https://issues.apache.org/jira/browse/GEODE-4375 > Project: Geode > Issue Type: Bug > Components: serialization, transactions >Reporter: Masaki Yamakawa >Priority: Major > Labels: pull-request-available > Fix For: 1.5.0 > > Time Spent: 1h > Remaining Estimate: 0h > > I am migrating from GemFire 7.x to Geode. After migration, An exception is > now thrown in transaction commit. I would like to fix this problem. > There are the following three patterns as a communication of a transaction. > In this last pattern, a deserialization exception is thrown. > * CacheServer (transaction) -> CacheServer > * Client (transaction) -> CacheServer > * CacheServer via Pool (transaction) -> CacheServer > In toData of TxCommitMessage.RegionCommit.FarSideEntryOp it is decided > whether or not to serialize ShadowKey depending on whether ClientVersion > exists or not. In the case of the last pattern, it is serialized because > ClientVersion exists. In fromData case, it decides whether or not to > deserialize by whether it is a Loner or not. In the case of the last pattern, > it is not Loner. As a result, a deserialization exception is thrown. > Therefore, instead of judging by the internal status of each process, I'd > like to send a flag as to whether ShadowKey exists or not. > Note: The disadvantage is that bytes are increased slightly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4375) Mismatch deserialization of TxCommitMessage
[ https://issues.apache.org/jira/browse/GEODE-4375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347332#comment-16347332 ] ASF subversion and git services commented on GEODE-4375: Commit c6ce06713142ede2beabb4f2aaef4b08dbb6fccf in geode's branch refs/heads/develop from [~masaki.yamakawa] [ https://gitbox.apache.org/repos/asf?p=geode.git;h=c6ce067 ] GEODE-4375: Fix problem that an exception occurs when transaction from CacheServer via Pool (#1363) > Mismatch deserialization of TxCommitMessage > --- > > Key: GEODE-4375 > URL: https://issues.apache.org/jira/browse/GEODE-4375 > Project: Geode > Issue Type: Bug > Components: serialization, transactions >Reporter: Masaki Yamakawa >Priority: Major > Labels: pull-request-available > Time Spent: 1h > Remaining Estimate: 0h > > I am migrating from GemFire 7.x to Geode. After migration, An exception is > now thrown in transaction commit. I would like to fix this problem. > There are the following three patterns as a communication of a transaction. > In this last pattern, a deserialization exception is thrown. > * CacheServer (transaction) -> CacheServer > * Client (transaction) -> CacheServer > * CacheServer via Pool (transaction) -> CacheServer > In toData of TxCommitMessage.RegionCommit.FarSideEntryOp it is decided > whether or not to serialize ShadowKey depending on whether ClientVersion > exists or not. In the case of the last pattern, it is serialized because > ClientVersion exists. In fromData case, it decides whether or not to > deserialize by whether it is a Loner or not. In the case of the last pattern, > it is not Loner. As a result, a deserialization exception is thrown. > Therefore, instead of judging by the internal status of each process, I'd > like to send a flag as to whether ShadowKey exists or not. > Note: The disadvantage is that bytes are increased slightly. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3533) Connections to new Locator endpoint get timed out after n seconds of inactivity
[ https://issues.apache.org/jira/browse/GEODE-3533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan resolved GEODE-3533. - Resolution: Won't Fix We won't fix this until we have more advanced load balancing in the new protocol. > Connections to new Locator endpoint get timed out after n seconds of > inactivity > --- > > Key: GEODE-3533 > URL: https://issues.apache.org/jira/browse/GEODE-3533 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Alexander Murmann >Priority: Major > > When I have a connection to the new Locator endpoint > And I do not make a request via the connections for `n` seconds > Then the connection gets closed by the Locator. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3532) New Locator endpoint responds to ListAllAvailableServers
[ https://issues.apache.org/jira/browse/GEODE-3532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan resolved GEODE-3532. - Resolution: Duplicate We have a single getServer request implemented. > New Locator endpoint responds to ListAllAvailableServers > > > Key: GEODE-3532 > URL: https://issues.apache.org/jira/browse/GEODE-3532 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Alexander Murmann >Priority: Major > > When I make a ListAllAvailableServers to the Locators new endpoint (the one > that doesn't close connections) > Then I receive back a list of all available servers -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3531) Locator accepts echo request on new endpoint
[ https://issues.apache.org/jira/browse/GEODE-3531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan resolved GEODE-3531. - Resolution: Won't Fix Never implemented echo, don't want to have it. > Locator accepts echo request on new endpoint > > > Key: GEODE-3531 > URL: https://issues.apache.org/jira/browse/GEODE-3531 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Alexander Murmann >Priority: Major > > I can make a echo request to the Locator on a new endpoint. > The echo request is submitted in protobuf format similar to requests we make > to the Server > The connection does not get closed by the server > Note: The echo functionality is just there to drive out the stack for the new > endpoint and for handling protobuf requests. The echo request will be removed > before this feature set is complete -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-3537) New Locator endpoint does not respond to `echo` requests
[ https://issues.apache.org/jira/browse/GEODE-3537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Galen O'Sullivan resolved GEODE-3537. - Resolution: Fixed Never implemented echo, don't want to have it. > New Locator endpoint does not respond to `echo` requests > > > Key: GEODE-3537 > URL: https://issues.apache.org/jira/browse/GEODE-3537 > Project: Geode > Issue Type: Improvement > Components: client/server >Reporter: Alexander Murmann >Priority: Major > > The new locator endpoint should no longer respond to `echo` requests. At this > point we should have the architecture driven out and have other, real > operation(s) we handle. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Reopened] (GEODE-4396) Refactor Message into two concrete classes
[ https://issues.apache.org/jira/browse/GEODE-4396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Baynes reopened GEODE-4396: - > Refactor Message into two concrete classes > -- > > Key: GEODE-4396 > URL: https://issues.apache.org/jira/browse/GEODE-4396 > Project: Geode > Issue Type: Task > Components: messaging >Reporter: Bruce Schuchardt >Priority: Major > > Message is currently used for client->server and server->client > communications. It should be separated into two classes, one for the > client->server and one for the server->client. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4395) Refactor Handshake into two concrete classes
[ https://issues.apache.org/jira/browse/GEODE-4395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Baynes resolved GEODE-4395. - Resolution: Duplicate > Refactor Handshake into two concrete classes > > > Key: GEODE-4395 > URL: https://issues.apache.org/jira/browse/GEODE-4395 > Project: Geode > Issue Type: Task > Components: messaging >Reporter: Bruce Schuchardt >Priority: Major > > Handshake is currently used for client->server and server->client handshake. > It should be separated into two classes, one for the client-side and one for > the server-side. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4396) Refactor Message into two concrete classes
[ https://issues.apache.org/jira/browse/GEODE-4396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Baynes resolved GEODE-4396. - Resolution: Duplicate > Refactor Message into two concrete classes > -- > > Key: GEODE-4396 > URL: https://issues.apache.org/jira/browse/GEODE-4396 > Project: Geode > Issue Type: Task > Components: messaging >Reporter: Bruce Schuchardt >Priority: Major > > Message is currently used for client->server and server->client > communications. It should be separated into two classes, one for the > client->server and one for the server->client. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4416) Make CqState an enum class
[ https://issues.apache.org/jira/browse/GEODE-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob S. Barrett resolved GEODE-4416. - Resolution: Fixed > Make CqState an enum class > -- > > Key: GEODE-4416 > URL: https://issues.apache.org/jira/browse/GEODE-4416 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Jacob S. Barrett >Assignee: Jacob S. Barrett >Priority: Major > Labels: pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > > Currently a class with an enum without scope. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4413) Convert CqOperation to scoped enum class.
[ https://issues.apache.org/jira/browse/GEODE-4413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacob S. Barrett resolved GEODE-4413. - Resolution: Fixed > Convert CqOperation to scoped enum class. > - > > Key: GEODE-4413 > URL: https://issues.apache.org/jira/browse/GEODE-4413 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Jacob S. Barrett >Assignee: Jacob S. Barrett >Priority: Major > Labels: pull-request-available > Time Spent: 40m > Remaining Estimate: 0h > > Currently CqOperation is a class with an internal scopeless CqOperationType > enum. C++11 allows us to make CqOperation an enum class. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (GEODE-4416) Make CqState an enum class
[ https://issues.apache.org/jira/browse/GEODE-4416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347265#comment-16347265 ] ASF subversion and git services commented on GEODE-4416: Commit 41d7101caed797086fbb635c18dc6190f1da2e10 in geode-native's branch refs/heads/develop from Jacob Barrett [ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=41d7101 ] GEODE-4416: Converts CqState to enum class. (#197) > Make CqState an enum class > -- > > Key: GEODE-4416 > URL: https://issues.apache.org/jira/browse/GEODE-4416 > Project: Geode > Issue Type: Task > Components: native client >Reporter: Jacob S. Barrett >Assignee: Jacob S. Barrett >Priority: Major > Labels: pull-request-available > Time Spent: 1.5h > Remaining Estimate: 0h > > Currently a class with an enum without scope. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (GEODE-4219) CI suspect string: java.lang.AssertionError: The put operation in queue did not succeed due to CacheClosedException
[
https://issues.apache.org/jira/browse/GEODE-4219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Huynh resolved GEODE-4219.
Resolution: Fixed
Assignee: Jason Huynh
Test was not currently being run depending on whether the static field toCnt
was set in another test or not.
Modified test to guarantee operations occur before continuing test - instead of
an arbitrary "fingers-crossed" wait.
The listener will no longer apply puts into the region if the test is shutting
down.
> CI suspect string: java.lang.AssertionError: The put operation in queue did
> not succeed due to CacheClosedException
>
>
> Key: GEODE-4219
> URL: https://issues.apache.org/jira/browse/GEODE-4219
> Project: Geode
> Issue Type: Bug
> Components: client queues
>Affects Versions: 1.4.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Assignee: Jason Huynh
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This suspect string was seen during CI:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/60
> {noformat}
> org.apache.geode.internal.cache.ha.HARegionQueueDUnitTest >
> testConcurrentOperationsDunitTestOnNonBlockingQueueWithDNoAckRegion FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 2338
> [error 2018/01/04 20:20:27.909 UTC 172.17.0.3(164):32773 shared ordered uid=9 port=47318> tid=0x2a6]
> Exception occurred in CacheListener
> java.lang.AssertionError: The put operation in queue did not succeed due
> to exception =
> at org.apache.geode.test.dunit.Assert.fail(Assert.java:66)
> at
> org.apache.geode.internal.cache.ha.HARegionQueueDUnitTest$6$1.afterUpdate(HARegionQueueDUnitTest.java:602)
> at
> org.apache.geode.internal.cache.EnumListenerEvent$AFTER_UPDATE.dispatchEvent(EnumListenerEvent.java:119)
> at
> org.apache.geode.internal.cache.LocalRegion.dispatchEvent(LocalRegion.java:8450)
> at
> org.apache.geode.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:6953)
> at
> org.apache.geode.internal.cache.LocalRegion.invokePutCallbacks(LocalRegion.java:5926)
> at
> org.apache.geode.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2339)
> at
> org.apache.geode.internal.cache.entries.AbstractRegionEntry.dispatchListenerEvents(AbstractRegionEntry.java:171)
> at
> org.apache.geode.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5784)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2864)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5622)
> at
> org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:369)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:152)
> at
> org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5603)
> at
> org.apache.geode.internal.cache.AbstractUpdateOperation.doPutOrCreate(AbstractUpdateOperation.java:165)
> at
> org.apache.geode.internal.cache.AbstractUpdateOperation$AbstractUpdateMessage.basicOperateOnRegion(AbstractUpdateOperation.java:272)
> at
> org.apache.geode.internal.cache.AbstractUpdateOperation$AbstractUpdateMessage.operateOnRegion(AbstractUpdateOperation.java:243)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.basicProcess(DistributedCacheOperation.java:1189)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.process(DistributedCacheOperation.java:1090)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382)
> at
> org.apache.geode.distributed.internal.DistributionMessage.schedule(DistributionMessage.java:440)
> at
> org.apache.geode.distributed.internal.DistributionManager.scheduleIncomingMessage(DistributionManager.java:3209)
> at
> org.apache.geode.distributed.internal.DistributionManager.handleIncomingDMsg(DistributionManager.java:2871)
> at
> org.apache.geode.distributed.internal.DistributionManager.access$1500(DistributionManager.java:108)
> at
> org.apache.geode.distributed.internal.DistributionManager$DMListener.messageReceived(DistributionManager.java:3987)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSMe
[jira] [Commented] (GEODE-4219) CI suspect string: java.lang.AssertionError: The put operation in queue did not succeed due to CacheClosedException
[
https://issues.apache.org/jira/browse/GEODE-4219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16347214#comment-16347214
]
ASF subversion and git services commented on GEODE-4219:
Commit 0d4940ddc1c49e910603a0e9c8f4f1dd918056ef in geode's branch
refs/heads/develop from [~huynhja]
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0d4940d ]
GEODE-4219: Test will properly shutdown listeners (#1325)
* Removed sleep
* Added check that each thread has done at least one operation
> CI suspect string: java.lang.AssertionError: The put operation in queue did
> not succeed due to CacheClosedException
>
>
> Key: GEODE-4219
> URL: https://issues.apache.org/jira/browse/GEODE-4219
> Project: Geode
> Issue Type: Bug
> Components: client queues
>Affects Versions: 1.4.0
>Reporter: Shelley Lynn Hughes-Godfrey
>Priority: Major
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This suspect string was seen during CI:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/develop/jobs/DistributedTest/builds/60
> {noformat}
> org.apache.geode.internal.cache.ha.HARegionQueueDUnitTest >
> testConcurrentOperationsDunitTestOnNonBlockingQueueWithDNoAckRegion FAILED
> java.lang.AssertionError: Suspicious strings were written to the log
> during this run.
> Fix the strings or use IgnoredException.addIgnoredException to ignore.
> ---
> Found suspect string in log4j at line 2338
> [error 2018/01/04 20:20:27.909 UTC 172.17.0.3(164):32773 shared ordered uid=9 port=47318> tid=0x2a6]
> Exception occurred in CacheListener
> java.lang.AssertionError: The put operation in queue did not succeed due
> to exception =
> at org.apache.geode.test.dunit.Assert.fail(Assert.java:66)
> at
> org.apache.geode.internal.cache.ha.HARegionQueueDUnitTest$6$1.afterUpdate(HARegionQueueDUnitTest.java:602)
> at
> org.apache.geode.internal.cache.EnumListenerEvent$AFTER_UPDATE.dispatchEvent(EnumListenerEvent.java:119)
> at
> org.apache.geode.internal.cache.LocalRegion.dispatchEvent(LocalRegion.java:8450)
> at
> org.apache.geode.internal.cache.LocalRegion.dispatchListenerEvent(LocalRegion.java:6953)
> at
> org.apache.geode.internal.cache.LocalRegion.invokePutCallbacks(LocalRegion.java:5926)
> at
> org.apache.geode.internal.cache.EntryEventImpl.invokeCallbacks(EntryEventImpl.java:2339)
> at
> org.apache.geode.internal.cache.entries.AbstractRegionEntry.dispatchListenerEvents(AbstractRegionEntry.java:171)
> at
> org.apache.geode.internal.cache.LocalRegion.basicPutPart2(LocalRegion.java:5784)
> at
> org.apache.geode.internal.cache.AbstractRegionMap.basicPut(AbstractRegionMap.java:2864)
> at
> org.apache.geode.internal.cache.LocalRegion.virtualPut(LocalRegion.java:5622)
> at
> org.apache.geode.internal.cache.DistributedRegion.virtualPut(DistributedRegion.java:369)
> at
> org.apache.geode.internal.cache.LocalRegionDataView.putEntry(LocalRegionDataView.java:152)
> at
> org.apache.geode.internal.cache.LocalRegion.basicUpdate(LocalRegion.java:5603)
> at
> org.apache.geode.internal.cache.AbstractUpdateOperation.doPutOrCreate(AbstractUpdateOperation.java:165)
> at
> org.apache.geode.internal.cache.AbstractUpdateOperation$AbstractUpdateMessage.basicOperateOnRegion(AbstractUpdateOperation.java:272)
> at
> org.apache.geode.internal.cache.AbstractUpdateOperation$AbstractUpdateMessage.operateOnRegion(AbstractUpdateOperation.java:243)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.basicProcess(DistributedCacheOperation.java:1189)
> at
> org.apache.geode.internal.cache.DistributedCacheOperation$CacheOperationMessage.process(DistributedCacheOperation.java:1090)
> at
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:382)
> at
> org.apache.geode.distributed.internal.DistributionMessage.schedule(DistributionMessage.java:440)
> at
> org.apache.geode.distributed.internal.DistributionManager.scheduleIncomingMessage(DistributionManager.java:3209)
> at
> org.apache.geode.distributed.internal.DistributionManager.handleIncomingDMsg(DistributionManager.java:2871)
> at
> org.apache.geode.distributed.internal.DistributionManager.access$1500(DistributionManager.java:108)
> at
> org.apache.geode.distributed.internal.DistributionManager$DMListener.messageReceived(DistributionManager.java:3987)
> at
> org.apache.geode.distributed.internal.membership.gms.mgr.GMSM
