[jira] [Created] (GEODE-9369) Command to copy region entries from a WAN site to another.

2021-06-10 Thread Alberto Gomez (Jira)
Alberto Gomez created GEODE-9369:


 Summary: Command to copy region entries from a WAN site to another.
 Key: GEODE-9369
 URL: https://issues.apache.org/jira/browse/GEODE-9369
 Project: Geode
  Issue Type: New Feature
  Components: wan
Reporter: Alberto Gomez


As described in RFC: 
[https://cwiki.apache.org/confluence/display/GEODE/Geode+Command+to+replicate+region+data+from+one+site+to+another+connected+via+WAN]

it is proposed to implement a command that copies the entries of a region in 
WAN site to the same region in another WAN site by using WAN replication.

 

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (GEODE-9369) Command to copy region entries from a WAN site to another.

2021-06-10 Thread Alberto Gomez (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alberto Gomez reassigned GEODE-9369:


Assignee: Alberto Gomez

> Command to copy region entries from a WAN site to another.
> --
>
> Key: GEODE-9369
> URL: https://issues.apache.org/jira/browse/GEODE-9369
> Project: Geode
>  Issue Type: New Feature
>  Components: wan
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
>
> As described in RFC: 
> [https://cwiki.apache.org/confluence/display/GEODE/Geode+Command+to+replicate+region+data+from+one+site+to+another+connected+via+WAN]
> it is proposed to implement a command that copies the entries of a region in 
> WAN site to the same region in another WAN site by using WAN replication.
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-9369) Command to copy region entries from a WAN site to another.

2021-06-10 Thread Alberto Gomez (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alberto Gomez updated GEODE-9369:
-
Description: 
As described in RFC: 
[https://cwiki.apache.org/confluence/display/GEODE/Geode+Command+to+replicate+region+data+from+one+site+to+another+connected+via+WAN]

it is proposed to implement a command that copies the entries of a region in a 
WAN site to the same region in another WAN site by using WAN replication.

 

 

  was:
As described in RFC: 
[https://cwiki.apache.org/confluence/display/GEODE/Geode+Command+to+replicate+region+data+from+one+site+to+another+connected+via+WAN]

it is proposed to implement a command that copies the entries of a region in 
WAN site to the same region in another WAN site by using WAN replication.

 

 


> Command to copy region entries from a WAN site to another.
> --
>
> Key: GEODE-9369
> URL: https://issues.apache.org/jira/browse/GEODE-9369
> Project: Geode
>  Issue Type: New Feature
>  Components: wan
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
>
> As described in RFC: 
> [https://cwiki.apache.org/confluence/display/GEODE/Geode+Command+to+replicate+region+data+from+one+site+to+another+connected+via+WAN]
> it is proposed to implement a command that copies the entries of a region in 
> a WAN site to the same region in another WAN site by using WAN replication.
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-9369) Command to copy region entries from a WAN site to another.

2021-06-10 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-9369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-9369:
--
Labels: pull-request-available  (was: )

> Command to copy region entries from a WAN site to another.
> --
>
> Key: GEODE-9369
> URL: https://issues.apache.org/jira/browse/GEODE-9369
> Project: Geode
>  Issue Type: New Feature
>  Components: wan
>Reporter: Alberto Gomez
>Assignee: Alberto Gomez
>Priority: Major
>  Labels: pull-request-available
>
> As described in RFC: 
> [https://cwiki.apache.org/confluence/display/GEODE/Geode+Command+to+replicate+region+data+from+one+site+to+another+connected+via+WAN]
> it is proposed to implement a command that copies the entries of a region in 
> a WAN site to the same region in another WAN site by using WAN replication.
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (GEODE-9370) Remove unnecessary serialization constructs from Radish classes

2021-06-10 Thread Jens Deppe (Jira)
Jens Deppe created GEODE-9370:
-

 Summary: Remove unnecessary serialization constructs from Radish 
classes
 Key: GEODE-9370
 URL: https://issues.apache.org/jira/browse/GEODE-9370
 Project: Geode
  Issue Type: Improvement
  Components: redis
Reporter: Jens Deppe


Since we're not performing function execution anymore, a few of our classes 
don't need to implement any serialization mechanics:

SetOptions
SortedSetOptions



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-9307) When a server is force disconnected, its regions can still be referenced

2021-06-10 Thread Nabarun Nag (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-9307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nabarun Nag updated GEODE-9307:
---
Fix Version/s: 1.15.0
   1.14.0
   1.13.3

> When a server is force disconnected, its regions can still be referenced
> 
>
> Key: GEODE-9307
> URL: https://issues.apache.org/jira/browse/GEODE-9307
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.12.3, 1.13.3, 1.14.0, 1.15.0
>
>
> When a server is force disconnected, any of its DistributedRegions will not 
> be GCed after they are closed. This is really only a problem if the 
> GemFireCacheImpl is referenced in something other than the 
> ClusterDistributionManager.cache field (in my test, I used a static field of 
> a Function)
> The GemFireCacheImpl references a ClusterDistributionManager in the final 
> field called dm.
> The DistributedRegion creates and references a DistributionAdvisor in the 
> final field called distAdvisor. The DistributionAdvisor creates a 
> MembershipListener and adds it to the ClusterDistributionManager's 
> membershipListeners.
> When the GemFireCacheImpl is closed due to force disconnect, its regions are 
> also closed.
> When a DistributedRegion is closed, its DistributionAdvisor is also closed.
> DistributionAdvisor.close attempts to remove the MembershipListener
> {noformat}
> try {
>   getDistributionManager().removeMembershipListener(membershipListener);
> } catch (CancelException e) {
>   // if distribution has stopped, above is a no-op.
> } ...
> {noformat}
> That call fails with a CancelException, and the MembershipListener is not 
> removed, so the ClusterDistributionManager references both the 
> GemFireCacheImpl and the MembershipListener. The MembershipListener 
> references the DistributionAdvisor which references the DistributedRegion.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (GEODE-9307) When a server is force disconnected, its regions can still be referenced

2021-06-10 Thread Nabarun Nag (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-9307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nabarun Nag closed GEODE-9307.
--

> When a server is force disconnected, its regions can still be referenced
> 
>
> Key: GEODE-9307
> URL: https://issues.apache.org/jira/browse/GEODE-9307
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.12.3, 1.13.3, 1.14.0, 1.15.0
>
>
> When a server is force disconnected, any of its DistributedRegions will not 
> be GCed after they are closed. This is really only a problem if the 
> GemFireCacheImpl is referenced in something other than the 
> ClusterDistributionManager.cache field (in my test, I used a static field of 
> a Function)
> The GemFireCacheImpl references a ClusterDistributionManager in the final 
> field called dm.
> The DistributedRegion creates and references a DistributionAdvisor in the 
> final field called distAdvisor. The DistributionAdvisor creates a 
> MembershipListener and adds it to the ClusterDistributionManager's 
> membershipListeners.
> When the GemFireCacheImpl is closed due to force disconnect, its regions are 
> also closed.
> When a DistributedRegion is closed, its DistributionAdvisor is also closed.
> DistributionAdvisor.close attempts to remove the MembershipListener
> {noformat}
> try {
>   getDistributionManager().removeMembershipListener(membershipListener);
> } catch (CancelException e) {
>   // if distribution has stopped, above is a no-op.
> } ...
> {noformat}
> That call fails with a CancelException, and the MembershipListener is not 
> removed, so the ClusterDistributionManager references both the 
> GemFireCacheImpl and the MembershipListener. The MembershipListener 
> references the DistributionAdvisor which references the DistributedRegion.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-9307) When a server is force disconnected, its regions can still be referenced

2021-06-10 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-9307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17361058#comment-17361058
 ] 

ASF subversion and git services commented on GEODE-9307:


Commit 1f0eda2768c1ad1f0feb2b418a84c2de931d9d89 in geode's branch 
refs/heads/support/1.13 from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=1f0eda2 ]

GEODE-9307: Removed MembershipListener after force disconnect (#6515)

(cherry picked from commit 2bc4bd93a6c24ea32c3a44c502fcb20c0a255cb4)


> When a server is force disconnected, its regions can still be referenced
> 
>
> Key: GEODE-9307
> URL: https://issues.apache.org/jira/browse/GEODE-9307
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.12.3, 1.13.3, 1.14.0, 1.15.0
>
>
> When a server is force disconnected, any of its DistributedRegions will not 
> be GCed after they are closed. This is really only a problem if the 
> GemFireCacheImpl is referenced in something other than the 
> ClusterDistributionManager.cache field (in my test, I used a static field of 
> a Function)
> The GemFireCacheImpl references a ClusterDistributionManager in the final 
> field called dm.
> The DistributedRegion creates and references a DistributionAdvisor in the 
> final field called distAdvisor. The DistributionAdvisor creates a 
> MembershipListener and adds it to the ClusterDistributionManager's 
> membershipListeners.
> When the GemFireCacheImpl is closed due to force disconnect, its regions are 
> also closed.
> When a DistributedRegion is closed, its DistributionAdvisor is also closed.
> DistributionAdvisor.close attempts to remove the MembershipListener
> {noformat}
> try {
>   getDistributionManager().removeMembershipListener(membershipListener);
> } catch (CancelException e) {
>   // if distribution has stopped, above is a no-op.
> } ...
> {noformat}
> That call fails with a CancelException, and the MembershipListener is not 
> removed, so the ClusterDistributionManager references both the 
> GemFireCacheImpl and the MembershipListener. The MembershipListener 
> references the DistributionAdvisor which references the DistributedRegion.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (GEODE-9307) When a server is force disconnected, its regions can still be referenced

2021-06-10 Thread Nabarun Nag (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-9307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nabarun Nag resolved GEODE-9307.

Resolution: Fixed

> When a server is force disconnected, its regions can still be referenced
> 
>
> Key: GEODE-9307
> URL: https://issues.apache.org/jira/browse/GEODE-9307
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.12.3, 1.13.3, 1.14.0, 1.15.0
>
>
> When a server is force disconnected, any of its DistributedRegions will not 
> be GCed after they are closed. This is really only a problem if the 
> GemFireCacheImpl is referenced in something other than the 
> ClusterDistributionManager.cache field (in my test, I used a static field of 
> a Function)
> The GemFireCacheImpl references a ClusterDistributionManager in the final 
> field called dm.
> The DistributedRegion creates and references a DistributionAdvisor in the 
> final field called distAdvisor. The DistributionAdvisor creates a 
> MembershipListener and adds it to the ClusterDistributionManager's 
> membershipListeners.
> When the GemFireCacheImpl is closed due to force disconnect, its regions are 
> also closed.
> When a DistributedRegion is closed, its DistributionAdvisor is also closed.
> DistributionAdvisor.close attempts to remove the MembershipListener
> {noformat}
> try {
>   getDistributionManager().removeMembershipListener(membershipListener);
> } catch (CancelException e) {
>   // if distribution has stopped, above is a no-op.
> } ...
> {noformat}
> That call fails with a CancelException, and the MembershipListener is not 
> removed, so the ClusterDistributionManager references both the 
> GemFireCacheImpl and the MembershipListener. The MembershipListener 
> references the DistributionAdvisor which references the DistributedRegion.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-9307) When a server is force disconnected, its regions can still be referenced

2021-06-10 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-9307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17361060#comment-17361060
 ] 

ASF subversion and git services commented on GEODE-9307:


Commit c6af575607eaad4bbb0fd9f7143b85a66dfbe405 in geode's branch 
refs/heads/support/1.14 from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=c6af575 ]

GEODE-9307: Removed MembershipListener after force disconnect (#6515)

(cherry picked from commit 2bc4bd93a6c24ea32c3a44c502fcb20c0a255cb4)


> When a server is force disconnected, its regions can still be referenced
> 
>
> Key: GEODE-9307
> URL: https://issues.apache.org/jira/browse/GEODE-9307
> Project: Geode
>  Issue Type: Bug
>  Components: regions
>Reporter: Barrett Oglesby
>Assignee: Barrett Oglesby
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.12.3, 1.13.3, 1.14.0, 1.15.0
>
>
> When a server is force disconnected, any of its DistributedRegions will not 
> be GCed after they are closed. This is really only a problem if the 
> GemFireCacheImpl is referenced in something other than the 
> ClusterDistributionManager.cache field (in my test, I used a static field of 
> a Function)
> The GemFireCacheImpl references a ClusterDistributionManager in the final 
> field called dm.
> The DistributedRegion creates and references a DistributionAdvisor in the 
> final field called distAdvisor. The DistributionAdvisor creates a 
> MembershipListener and adds it to the ClusterDistributionManager's 
> membershipListeners.
> When the GemFireCacheImpl is closed due to force disconnect, its regions are 
> also closed.
> When a DistributedRegion is closed, its DistributionAdvisor is also closed.
> DistributionAdvisor.close attempts to remove the MembershipListener
> {noformat}
> try {
>   getDistributionManager().removeMembershipListener(membershipListener);
> } catch (CancelException e) {
>   // if distribution has stopped, above is a no-op.
> } ...
> {noformat}
> That call fails with a CancelException, and the MembershipListener is not 
> removed, so the ClusterDistributionManager references both the 
> GemFireCacheImpl and the MembershipListener. The MembershipListener 
> references the DistributionAdvisor which references the DistributedRegion.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Assigned] (GEODE-9371) Change stress-new-tasks jobs from required to non-required

2021-06-10 Thread Kirk Lund (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-9371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Lund reassigned GEODE-9371:


Assignee: Kirk Lund

> Change stress-new-tasks jobs from required to non-required
> --
>
> Key: GEODE-9371
> URL: https://issues.apache.org/jira/browse/GEODE-9371
> Project: Geode
>  Issue Type: Wish
>  Components: build
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>
> Change stress-new-tasks jobs from required to non-required.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (GEODE-9371) Change stress-new-tasks jobs from required to non-required

2021-06-10 Thread Kirk Lund (Jira)
Kirk Lund created GEODE-9371:


 Summary: Change stress-new-tasks jobs from required to non-required
 Key: GEODE-9371
 URL: https://issues.apache.org/jira/browse/GEODE-9371
 Project: Geode
  Issue Type: Wish
  Components: build
Reporter: Kirk Lund


Change stress-new-tasks jobs from required to non-required.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-9371) Change stress-new-tasks jobs from required to non-required

2021-06-10 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-9371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-9371:
--
Labels: pull-request-available  (was: )

> Change stress-new-tasks jobs from required to non-required
> --
>
> Key: GEODE-9371
> URL: https://issues.apache.org/jira/browse/GEODE-9371
> Project: Geode
>  Issue Type: Wish
>  Components: build
>Reporter: Kirk Lund
>Assignee: Kirk Lund
>Priority: Major
>  Labels: pull-request-available
>
> Change stress-new-tasks jobs from required to non-required.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8772) Make tests assign necessary ports in test JVM [PERMANENT]

2021-06-10 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-8772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17361126#comment-17361126
 ] 

ASF subversion and git services commented on GEODE-8772:


Commit f0d918e77fd2d1d6089d5f6bbe44ee02579c0363 in geode's branch 
refs/heads/develop from Dale Emery
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=f0d918e ]

GEODE-8772: Fix ClusterComms test port conflicts (#6583)

Change `ClusterCommunicationsDUnitTest.performARollingUpgrade()` to
disable the HTTP service.

BACKGROUND

I am working on a project to allow Geode tests to run in parallel
outside of Docker. Running in parallel outside of Docker requires that
tests not start services using default ports.

This commit prepares for those changes.

PROBLEMS

When `ClusterCommunicationsDUnitTest.performARollingUpgrade()` upgrades
the locator, it starts the new locator with HTTP service enabled on the
default port (7070). If another test running in parallel also uses this
default port, at least one will throw an exception when it attempts to
bind.

THIS COMMIT

Change `ClusterCommunicationsDUnitTest` to start the upgraded locator
with HTTP service disabled. The test does not use the HTTP service.

> Make tests assign necessary ports in test JVM [PERMANENT]
> -
>
> Key: GEODE-8772
> URL: https://issues.apache.org/jira/browse/GEODE-8772
> Project: Geode
>  Issue Type: Test
>  Components: tests
>Affects Versions: 1.14.0
>Reporter: Dale Emery
>Assignee: Dale Emery
>Priority: Major
>  Labels: GeodeOperationAPI, pull-request-available
>
> *Make tests assign all necessary ports.* Many distributed tests and upgrade 
> tests (and sometimes others) launch members with default ports, especially 
> for JMX (1099) and HTTP service (7070). When run in parallel outside of 
> docker, these tests often fail because the default port is already in use in 
> another test.
> Except when specifically testing the product's use of the defaults, every 
> test should assign ports from a pool of ports known to be available. For many 
> tests, we can accomplish this by changing the test framework to assign 
> available ports. Other tests may require changes in the test code.
> *Assign ports only in test JVMs, and not in child VMs.* The 
> {{AvailablePortHelper}} class occasionally gains new features to improve its 
> assignment of ports when tests run in parallel. For these improvements to 
> work, each test must use the latest {{AvailablePortHelper}} implementation 
> for all port assignments. Child VMs that run older versions of Geode may not 
> include the latest implementation of {{AvailablePortHelper}}. For this 
> reason, tests should invoke {{AvailablePortHelper}} only in the test JVM and 
> not in child VMs.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-9203) Implement NUMSUB Subcommand

2021-06-10 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-9203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-9203:
--
Labels: pull-request-available  (was: )

> Implement NUMSUB Subcommand
> ---
>
> Key: GEODE-9203
> URL: https://issues.apache.org/jira/browse/GEODE-9203
> Project: Geode
>  Issue Type: Sub-task
>  Components: redis
>Reporter: Wayne
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.15.0
>
>
> Implement the 
> [NUMSUB|https://redis.io/commands/pubsub#codepubsub-numsub-channel-1--channel-ncode]
>  subcommand.
>  
> +Acceptance Criteria+
> The NUMSUB subcommand has been implemented along with unit tests to assert 
> that the subcommand correctly returns the number of subscribers (not counting 
> clients subscribed to patterns) for the specified channels.
> h5. Return value
> [Array reply|https://redis.io/topics/protocol#array-reply]: a list of 
> channels and number of subscribers for every channel. The format is channel, 
> count, channel, count, ..., so the list is flat. The order in which the 
> channels are listed is the same as the order of the channels specified in the 
> command call.
> Note that it is valid to call this command without channels. In this case it 
> will just return an empty list.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-9303) Implement the DUMP and Restore Commands

2021-06-10 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-9303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-9303:
--
Labels: pull-request-available redis  (was: redis)

> Implement the DUMP and Restore Commands
> ---
>
> Key: GEODE-9303
> URL: https://issues.apache.org/jira/browse/GEODE-9303
> Project: Geode
>  Issue Type: New Feature
>  Components: redis
>Affects Versions: 1.15.0
>Reporter: Wayne
>Priority: Major
>  Labels: pull-request-available, redis
>
> Implement the [DUMP|https://redis.io/commands/dump] and 
> [RESTORE|https://redis.io/commands/restore] commands as compatible with Redis.
>  
> +Acceptance Criteria+
> The DUMP and RESTORE commands have been implemented as specified, with 
> adequate unit and integration tests.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-9364) Spelling mistake in the CqQuery

2021-06-10 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-9364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17361216#comment-17361216
 ] 

ASF subversion and git services commented on GEODE-9364:


Commit eaceefbf4cbb1e2024414d74b0e909ce9948feee in geode-native's branch 
refs/heads/develop from jupiternightingale
[ https://gitbox.apache.org/repos/asf?p=geode-native.git;h=eaceefb ]

GEODE-9364 - Fixed spelling mistake in Api documentation. (#818)



> Spelling mistake in the CqQuery
> ---
>
> Key: GEODE-9364
> URL: https://issues.apache.org/jira/browse/GEODE-9364
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Affects Versions: 1.13.2
>Reporter: Charlie Black
>Assignee: Charlie Black
>Priority: Major
>  Labels: pull-request-available
>
> In `CqQuery` class the method `getQuery` has a spelling mistake:
> `Get teh query object ...`
> should read as
> `Get the query object...`



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-9364) Spelling mistake in the CqQuery

2021-06-10 Thread ASF GitHub Bot (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-9364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17361217#comment-17361217
 ] 

ASF GitHub Bot commented on GEODE-9364:
---

pdxcodemonkey merged pull request #818:
URL: https://github.com/apache/geode-native/pull/818


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> Spelling mistake in the CqQuery
> ---
>
> Key: GEODE-9364
> URL: https://issues.apache.org/jira/browse/GEODE-9364
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Affects Versions: 1.13.2
>Reporter: Charlie Black
>Assignee: Charlie Black
>Priority: Major
>  Labels: pull-request-available
>
> In `CqQuery` class the method `getQuery` has a spelling mistake:
> `Get teh query object ...`
> should read as
> `Get the query object...`



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Closed] (GEODE-9364) Spelling mistake in the CqQuery

2021-06-10 Thread Blake Bender (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-9364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Blake Bender closed GEODE-9364.
---

> Spelling mistake in the CqQuery
> ---
>
> Key: GEODE-9364
> URL: https://issues.apache.org/jira/browse/GEODE-9364
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Affects Versions: 1.13.2
>Reporter: Charlie Black
>Assignee: Charlie Black
>Priority: Major
>  Labels: pull-request-available
>
> In `CqQuery` class the method `getQuery` has a spelling mistake:
> `Get teh query object ...`
> should read as
> `Get the query object...`



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (GEODE-9364) Spelling mistake in the CqQuery

2021-06-10 Thread Blake Bender (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-9364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Blake Bender resolved GEODE-9364.
-
Resolution: Fixed

> Spelling mistake in the CqQuery
> ---
>
> Key: GEODE-9364
> URL: https://issues.apache.org/jira/browse/GEODE-9364
> Project: Geode
>  Issue Type: Bug
>  Components: native client
>Affects Versions: 1.13.2
>Reporter: Charlie Black
>Assignee: Charlie Black
>Priority: Major
>  Labels: pull-request-available
>
> In `CqQuery` class the method `getQuery` has a spelling mistake:
> `Get teh query object ...`
> should read as
> `Get the query object...`



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-9350) MemberJoinedEvent should be triggered after new view is installed

2021-06-10 Thread Kamilla Aslami (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-9350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kamilla Aslami updated GEODE-9350:
--
Summary: MemberJoinedEvent should be triggered after new view is installed  
(was: New member is being shunned after joining the cluster)

> MemberJoinedEvent should be triggered after new view is installed
> -
>
> Key: GEODE-9350
> URL: https://issues.apache.org/jira/browse/GEODE-9350
> Project: Geode
>  Issue Type: Bug
>  Components: membership
>Affects Versions: 1.14.0, 1.15.0
>Reporter: Kamilla Aslami
>Assignee: Kamilla Aslami
>Priority: Major
>  Labels: pull-request-available, release-blocker
>
> While investigating GEODE-9070, we noticed a problem when a server tries to 
> join a cluster, and soon after, membership fails with ShunnedMemberException:
> {noformat}
> org.apache.geode.distributed.internal.direct.ShunnedMemberException: Member 
> is being shunned: ccf730fb2b62(161):41002
>  at 
> org.apache.geode.distributed.internal.direct.DirectChannel.getConnections(DirectChannel.java:469)
>  at 
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToMany(DirectChannel.java:283)
>  at 
> org.apache.geode.distributed.internal.direct.DirectChannel.sendToOne(DirectChannel.java:190)
>  at 
> org.apache.geode.distributed.internal.direct.DirectChannel.send(DirectChannel.java:550)
>  at 
> org.apache.geode.distributed.internal.DistributionImpl.directChannelSend(DistributionImpl.java:354)
>  at 
> org.apache.geode.distributed.internal.DistributionImpl.send(DistributionImpl.java:296)
>  at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendViaMembershipManager(ClusterDistributionManager.java:2068)
>  at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendOutgoing(ClusterDistributionManager.java:1983)
>  at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.sendMessage(ClusterDistributionManager.java:2028)
>  at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.putOutgoing(ClusterDistributionManager.java:1085)
>  at 
> org.apache.geode.internal.cache.execute.StreamingFunctionOperation.getFunctionResultFrom(StreamingFunctionOperation.java:113)
>  at 
> org.apache.geode.internal.cache.execute.MemberFunctionExecutor.executeFunction(MemberFunctionExecutor.java:149)
>  at 
> org.apache.geode.internal.cache.execute.MemberFunctionExecutor.executeFunction(MemberFunctionExecutor.java:191)
>  at 
> org.apache.geode.internal.cache.execute.AbstractExecution.execute(AbstractExecution.java:397)
>  at 
> org.apache.geode.internal.cache.execute.AbstractExecution.execute(AbstractExecution.java:402)
>  at 
> org.apache.geode.modules.util.BootstrappingFunction.bootstrapMember(BootstrappingFunction.java:170)
>  at 
> org.apache.geode.modules.util.BootstrappingFunction.memberJoined(BootstrappingFunction.java:240)
>  at 
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberJoinedEvent.handleEvent(ClusterDistributionManager.java:2498)
>  at 
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEvent.handleEvent(ClusterDistributionManager.java:2451)
>  at 
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEvent.handleEvent(ClusterDistributionManager.java:2440)
>  at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.handleMemberEvent(ClusterDistributionManager.java:1406)
>  at 
> org.apache.geode.distributed.internal.ClusterDistributionManager.access$200(ClusterDistributionManager.java:109)
>  at 
> org.apache.geode.distributed.internal.ClusterDistributionManager$MemberEventInvoker.run(ClusterDistributionManager.java:1438)
>  at java.base/java.lang.Thread.run(Thread.java:834){noformat}
> Further analysis showed that ShunnedMemberException is thrown because 
> GMSMembership.memberExists() method returns false, which means that the 
> member ccf730fb2b62(161):41002 was not in the view. Looking at the 
> stacktrace, we noticed that BootstrappingFunction.bootstrapMember() gets 
> executed on MemberJoinedEvent, which is triggered by 
> MembershipListener.newMemberConnected(). newMemberConnected() is called in 
> GMSMembership.processView() before the new view is installed, so it's likely 
> that the failure happens because BootstrappingFunction receives the event 
> before the view was actually updated. Possible solution for this problem 
> could be to change GMSMembership.processView() to call 
> MembershipListener.newMemberConnected() only after the new view is installed.
> This issue was introduced by the fix for GEODE-7245 which removed latestView 
> lock from GMSMembership.memberExists(). Before GEODE-7245, this method was 
> waiting until GMSMembership.processView() released the lock, so the proble

[jira] [Commented] (GEODE-9248) Server hosting cq subscription queue uneccessary fills bucketToTempQueueMap while in multi site split brain

2021-06-10 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-9248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17361233#comment-17361233
 ] 

ASF subversion and git services commented on GEODE-9248:


Commit 32d74989eb84b409969f855ae9c898649f1c3169 in geode's branch 
refs/heads/develop from BenjaminPerryRoss
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=32d7498 ]

Revert "GEODE-9248: Server hosting CQ queue uneccessary fills bucketToTempQue… 
(#6477)" (#6603)

This reverts commit 7289b77b2ccad9423e5b7dd7e7367951d8574007.

> Server hosting cq subscription queue uneccessary fills bucketToTempQueueMap 
> while in multi site split brain
> ---
>
> Key: GEODE-9248
> URL: https://issues.apache.org/jira/browse/GEODE-9248
> Project: Geode
>  Issue Type: Bug
>Reporter: Jakov Varenina
>Assignee: Jakov Varenina
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.15.0
>
>
> The problem reproduces when you use transactions and have more servers than 
> redundant copies of the partition region, and also events are queued in 
> parallel gateway-senders due to ongoing multi-site split brain. In this case 
> all members send events to the member with subscription queue, which then 
> fills variable *bucketToTempQueueMap* with traffic intended for the buckets 
> that it doesn't host.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-8825) CI failure: GatewayReceiverMBeanDUnitTest > testMBeanAndProxiesForGatewayReceiverAreRemovedOnDestroy

2021-06-10 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-8825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated GEODE-8825:
--
Labels: GeodeOperationAPI flaky pull-request-available  (was: 
GeodeOperationAPI flaky)

> CI failure: GatewayReceiverMBeanDUnitTest > 
> testMBeanAndProxiesForGatewayReceiverAreRemovedOnDestroy
> 
>
> Key: GEODE-8825
> URL: https://issues.apache.org/jira/browse/GEODE-8825
> Project: Geode
>  Issue Type: Bug
>  Components: tests, wan
>Reporter: Jianxia Chen
>Assignee: Barrett Oglesby
>Priority: Major
>  Labels: GeodeOperationAPI, flaky, pull-request-available
>
> {code:java}
> org.apache.geode.internal.cache.wan.GatewayReceiverMBeanDUnitTest > 
> testMBeanAndProxiesForGatewayReceiverAreRemovedOnDestroy FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.wan.GatewayReceiverMBeanDUnitTest$$Lambda$202/0x0001008f0c40.run
>  in VM 0 running on Host c3e48bdac460 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:447)
> at 
> org.apache.geode.internal.cache.wan.GatewayReceiverMBeanDUnitTest.testMBeanAndProxiesForGatewayReceiverAreRemovedOnDestroy(GatewayReceiverMBeanDUnitTest.java:76)
> Caused by:
> java.lang.AssertionError: expected null, but was: GemFire:service=GatewayReceiver,type=Member,member=172.17.0.18(183)-41002>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotNull(Assert.java:756)
> at org.junit.Assert.assertNull(Assert.java:738)
> at org.junit.Assert.assertNull(Assert.java:748)
> at 
> org.apache.geode.internal.cache.wan.GatewayReceiverMBeanDUnitTest.verifyMBeanProxiesDoesNotExist(GatewayReceiverMBeanDUnitTest.java:106)
> at 
> org.apache.geode.internal.cache.wan.GatewayReceiverMBeanDUnitTest.lambda$testMBeanAndProxiesForGatewayReceiverAreRemovedOnDestroy$bb17a952$3(GatewayReceiverMBeanDUnitTest.java:76)
>  {code}
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/704
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=  Test Results URI 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0601/test-results/distributedTest/1610390301/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0601/test-artifacts/1610390301/distributedtestfiles-OpenJDK11-1.14.0-build.0601.tgz



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8825) CI failure: GatewayReceiverMBeanDUnitTest > testMBeanAndProxiesForGatewayReceiverAreRemovedOnDestroy

2021-06-10 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-8825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17361235#comment-17361235
 ] 

ASF subversion and git services commented on GEODE-8825:


Commit 0bd4be0d247ee5d1f5b4669c3fb540b8d81920df in geode's branch 
refs/heads/develop from Barry Oglesby
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=0bd4be0 ]

GEODE-8825: Modified test to wait for proxies to be created (#6591)



> CI failure: GatewayReceiverMBeanDUnitTest > 
> testMBeanAndProxiesForGatewayReceiverAreRemovedOnDestroy
> 
>
> Key: GEODE-8825
> URL: https://issues.apache.org/jira/browse/GEODE-8825
> Project: Geode
>  Issue Type: Bug
>  Components: tests, wan
>Reporter: Jianxia Chen
>Assignee: Barrett Oglesby
>Priority: Major
>  Labels: GeodeOperationAPI, flaky, pull-request-available
>
> {code:java}
> org.apache.geode.internal.cache.wan.GatewayReceiverMBeanDUnitTest > 
> testMBeanAndProxiesForGatewayReceiverAreRemovedOnDestroy FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.wan.GatewayReceiverMBeanDUnitTest$$Lambda$202/0x0001008f0c40.run
>  in VM 0 running on Host c3e48bdac460 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:447)
> at 
> org.apache.geode.internal.cache.wan.GatewayReceiverMBeanDUnitTest.testMBeanAndProxiesForGatewayReceiverAreRemovedOnDestroy(GatewayReceiverMBeanDUnitTest.java:76)
> Caused by:
> java.lang.AssertionError: expected null, but was: GemFire:service=GatewayReceiver,type=Member,member=172.17.0.18(183)-41002>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotNull(Assert.java:756)
> at org.junit.Assert.assertNull(Assert.java:738)
> at org.junit.Assert.assertNull(Assert.java:748)
> at 
> org.apache.geode.internal.cache.wan.GatewayReceiverMBeanDUnitTest.verifyMBeanProxiesDoesNotExist(GatewayReceiverMBeanDUnitTest.java:106)
> at 
> org.apache.geode.internal.cache.wan.GatewayReceiverMBeanDUnitTest.lambda$testMBeanAndProxiesForGatewayReceiverAreRemovedOnDestroy$bb17a952$3(GatewayReceiverMBeanDUnitTest.java:76)
>  {code}
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/704
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=  Test Results URI 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0601/test-results/distributedTest/1610390301/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0601/test-artifacts/1610390301/distributedtestfiles-OpenJDK11-1.14.0-build.0601.tgz



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (GEODE-8825) CI failure: GatewayReceiverMBeanDUnitTest > testMBeanAndProxiesForGatewayReceiverAreRemovedOnDestroy

2021-06-10 Thread Barrett Oglesby (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-8825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Barrett Oglesby resolved GEODE-8825.

Fix Version/s: 1.15.0
   Resolution: Fixed

> CI failure: GatewayReceiverMBeanDUnitTest > 
> testMBeanAndProxiesForGatewayReceiverAreRemovedOnDestroy
> 
>
> Key: GEODE-8825
> URL: https://issues.apache.org/jira/browse/GEODE-8825
> Project: Geode
>  Issue Type: Bug
>  Components: tests, wan
>Reporter: Jianxia Chen
>Assignee: Barrett Oglesby
>Priority: Major
>  Labels: GeodeOperationAPI, flaky, pull-request-available
> Fix For: 1.15.0
>
>
> {code:java}
> org.apache.geode.internal.cache.wan.GatewayReceiverMBeanDUnitTest > 
> testMBeanAndProxiesForGatewayReceiverAreRemovedOnDestroy FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.wan.GatewayReceiverMBeanDUnitTest$$Lambda$202/0x0001008f0c40.run
>  in VM 0 running on Host c3e48bdac460 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:623)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:447)
> at 
> org.apache.geode.internal.cache.wan.GatewayReceiverMBeanDUnitTest.testMBeanAndProxiesForGatewayReceiverAreRemovedOnDestroy(GatewayReceiverMBeanDUnitTest.java:76)
> Caused by:
> java.lang.AssertionError: expected null, but was: GemFire:service=GatewayReceiver,type=Member,member=172.17.0.18(183)-41002>
> at org.junit.Assert.fail(Assert.java:89)
> at org.junit.Assert.failNotNull(Assert.java:756)
> at org.junit.Assert.assertNull(Assert.java:738)
> at org.junit.Assert.assertNull(Assert.java:748)
> at 
> org.apache.geode.internal.cache.wan.GatewayReceiverMBeanDUnitTest.verifyMBeanProxiesDoesNotExist(GatewayReceiverMBeanDUnitTest.java:106)
> at 
> org.apache.geode.internal.cache.wan.GatewayReceiverMBeanDUnitTest.lambda$testMBeanAndProxiesForGatewayReceiverAreRemovedOnDestroy$bb17a952$3(GatewayReceiverMBeanDUnitTest.java:76)
>  {code}
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/704
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=  Test Results URI 
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0601/test-results/distributedTest/1610390301/
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Test report artifacts from this job are available at:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.14.0-build.0601/test-artifacts/1610390301/distributedtestfiles-OpenJDK11-1.14.0-build.0601.tgz



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-8980) bump dependencies for 1.15.0 [PERMANENT]

2021-06-10 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-8980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17361307#comment-17361307
 ] 

ASF subversion and git services commented on GEODE-8980:


Commit 193cddc8c075a5c71d25c28e7110129c41ed2d17 in geode's branch 
refs/heads/develop from Owen Nichols
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=193cddc ]

GEODE-8980: bumps deps (#6600)

* Bump annotations from 20.1.0 to 21.0.1
* Bump awaitility from 4.0.3 to 4.1.0
* Bump bcpkix-jdk15on from 1.68 to 1.69
* Bump ben-manes.versions from 0.38.0 to 0.39.0
* Bump cargo-core-uberjar from 1.9.3 to 1.9.4
* Bump classgraph from 4.8.104 to 4.8.108
* Bump docker-java from 3.2.7 to 3.2.8
* Bump jetty from 9.4.40.v20210413 to 9.4.42.v20210604
* Bump jproc from 2.6.0 to 2.6.2
* Bump json-path from 2.5.0 to 2.6.0
* Bump lettuce-core from 6.1.1.RELEASE to 6.1.2.RELEASE
* Bump maven-artifact from 3.6.3 to 3.8.1
* Bump micrometer-core from 1.6.6 to 1.7.0
* Bump mockito-core from 3.9.0 to 3.11.0
* Bump mysql-connector-java from 8.0.23 to 8.0.25
* Bump nebula.lint from 16.17.1 to 16.23.0
* Bump pmd from 6.33.0 to 6.35.0
* Bump sonarqube from 3.1.1 to 3.2.0
* Bump spotless from 5.11.1 to 5.12.5
* Bump spring from 5.3.7 to 5.3.8
* Bump spring-boot-starter from 2.4.5 to 2.5.0
* Bump spring-hateoas from 1.3.0 to 1.3.1
* Bump spring-security from 5.4.6 to 5.5.0
* Bump spring-session-data-redis from 2.4.3 to 2.5.0
* Bump tomcat from 9.0.45 to 9.0.46
* Bump tomcat-catalina from 7.0.108 to 7.0.109
* Bump tomcat-catalina from 8.5.65 to 8.5.66

> bump dependencies for 1.15.0 [PERMANENT]
> 
>
> Key: GEODE-8980
> URL: https://issues.apache.org/jira/browse/GEODE-8980
> Project: Geode
>  Issue Type: Improvement
>  Components: build
>Affects Versions: 1.15.0
>Reporter: Owen Nichols
>Priority: Major
>  Labels: pull-request-available
>
> keeping up with the latest versions of 3rd-party libraries used by Geode is a 
> proactive way to reduce bugs and avoid security vulnerabilities.  this ticket 
> will be used for ~monthly dependency bumps on develop until we get close to 
> cutting support/1.15



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-9289) Configuration Class cannot be deserialized in old locators

2021-06-10 Thread Owen Nichols (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-9289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Owen Nichols updated GEODE-9289:

Fix Version/s: 1.13.3

> Configuration Class cannot be deserialized in old locators
> --
>
> Key: GEODE-9289
> URL: https://issues.apache.org/jira/browse/GEODE-9289
> Project: Geode
>  Issue Type: Bug
>  Components: serialization
>Reporter: Nabarun Nag
>Priority: Major
>  Labels: blocks-1.14.0​, pull-request-available
> Fix For: 1.12.3, 1.13.3
>
>
> * Locators post version 1.12.0 when send out the Configuration to old version 
> locators
>  * Old locators are not able to interpret the null jarNames sent by the new 
> locators
>  * This causes a lot of NPEs in the old locators
>  * This clears out the jarNames in the configuration and if a server joins 
> the cluster and requests the cluster configuration from the oldest locator, 
> then it does not the jars deployed in the cluster.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-9289) Configuration Class cannot be deserialized in old locators

2021-06-10 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-9289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17361319#comment-17361319
 ] 

ASF subversion and git services commented on GEODE-9289:


Commit 9ab1beb2f7c0a3a717914245e7062348db731d2f in geode's branch 
refs/heads/support/1.13 from Nabarun Nag
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=9ab1beb ]

GEODE-9289: Configuration compatibile with pre-1.12.0 versions. (#6593)

* This part of the commit was missed as a part of the original commit

(cherry picked from commit c1e59b23a89d4eac89334f525cd4a8bfaebefe1d)

> Configuration Class cannot be deserialized in old locators
> --
>
> Key: GEODE-9289
> URL: https://issues.apache.org/jira/browse/GEODE-9289
> Project: Geode
>  Issue Type: Bug
>  Components: serialization
>Reporter: Nabarun Nag
>Priority: Major
>  Labels: blocks-1.14.0​, pull-request-available
> Fix For: 1.12.3, 1.13.3
>
>
> * Locators post version 1.12.0 when send out the Configuration to old version 
> locators
>  * Old locators are not able to interpret the null jarNames sent by the new 
> locators
>  * This causes a lot of NPEs in the old locators
>  * This clears out the jarNames in the configuration and if a server joins 
> the cluster and requests the cluster configuration from the oldest locator, 
> then it does not the jars deployed in the cluster.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (GEODE-9363) bump spring to recommended version

2021-06-10 Thread ASF subversion and git services (Jira)


[ 
https://issues.apache.org/jira/browse/GEODE-9363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17361356#comment-17361356
 ] 

ASF subversion and git services commented on GEODE-9363:


Commit 5543c2ce841f3db8556c0e2afe987400b1460b90 in geode's branch 
refs/heads/support/1.14 from Owen Nichols
[ https://gitbox.apache.org/repos/asf?p=geode.git;h=5543c2c ]

GEODE-9363: Bump spring from 5.3.3 to 5.3.8


> bump spring to recommended version
> --
>
> Key: GEODE-9363
> URL: https://issues.apache.org/jira/browse/GEODE-9363
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Owen Nichols
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.12.3, 1.13.3, 1.15.0
>
>
> bump spring-core from 5.3.x to 5.3.7 on develop & 1.14 and 5.2.x to 5.2.15 on 
> 1.13 and 1.12



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (GEODE-9363) bump spring to recommended version

2021-06-10 Thread Owen Nichols (Jira)


 [ 
https://issues.apache.org/jira/browse/GEODE-9363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Owen Nichols updated GEODE-9363:

Fix Version/s: 1.14.0

> bump spring to recommended version
> --
>
> Key: GEODE-9363
> URL: https://issues.apache.org/jira/browse/GEODE-9363
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Owen Nichols
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.12.3, 1.13.3, 1.14.0, 1.15.0
>
>
> bump spring-core from 5.3.x to 5.3.7 on develop & 1.14 and 5.2.x to 5.2.15 on 
> 1.13 and 1.12



--
This message was sent by Atlassian Jira
(v8.3.4#803005)