[jira] [Updated] (GEODE-10411) XSS vulnerabiltiy in Pulse data browser

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-10411:
---
Affects Version/s: 1.13.8
   1.13.9

> XSS vulnerabiltiy in Pulse data browser
> ---
>
> Key: GEODE-10411
> URL: https://issues.apache.org/jira/browse/GEODE-10411
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Affects Versions: 1.12.9, 1.12.10, 1.13.8, 1.13.9, 1.14.4, 1.14.5, 1.15.0, 
> 1.15.1, 1.16.0
>Reporter: Joris Melchior
>Assignee: Joris Melchior
>Priority: Major
>  Labels: needsTriage, pull-request-available
> Fix For: 1.12.10, 1.13.9, 1.14.5, 1.15.1, 1.16.0
>
>
> # Description:
> Stored XSS via data injection into Geode database, the injected
> payload eventually gets executed on Pulse web application when the
> admin querying data from Geode.
> # PoC:
> Step 1: With Geode up and running, run gfsh command to get into
> interactive mode:
>    shell$ gfsh
> Step 2: In gfsh console, execute the following command to insert a
> data entry into regionA (assume that regionA is created before). Note
> that the value of this data entry contains JavaScript code:
>    gfsh> put --region=regionA --key="test" --value="alert(1)"
> Step 3: Open browser to query editor of Pulse web application at
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.168.93.153%3A7070%2Fpulse%2FdataBrowser.htmldata=05%7C01%7Cbakera%40vmware.com%7Cc06e6de8d92c4519303708da54fa7d03%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637915732081233095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=ykaOkxe1hlaE7xl8XQNgBQz2%2Ful1QPxrUChoBkuaeyY%3Dreserved=0
>  (assume that already
> logged in as admin), execute the following query:
> SELECT * FROM /regionA
> Step 4: Data from regionA will be retrieved, the XSS payload
> eventually get executed
> # Why this is an issue?
> Developer maybe saves user-controlled data to Geode database, users
> maybe submit data via an arbitrary client application (for example, a
> web application), the use of gfsh console just simplifies the PoC.
> # IMPACT:
> Exploiting this XSS vulnerability, an attacker can steal the admin's
> session cookie, therefore take over the admin account.
> # CVSS: 7.6 HIGH
> (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.first.org%2Fcvss%2Fcalculator%2F3.0%23CVSS%3A3.0%2FAV%3AN%2FAC%3AL%2FPR%3AN%2FUI%3AR%2FS%3AU%2FC%3AH%2FI%3AL%2FA%3ALdata=05%7C01%7Cbakera%40vmware.com%7Cc06e6de8d92c4519303708da54fa7d03%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637915732081233095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=W5dDA8kMdT1IVeUVX6mhWHhZ2HnAZbXErEB%2F0Tjs5hg%3Dreserved=0
>  )
> (re-calculate if not correct)
> # Fix:
> The Pulse web application must URL encode data retrieved from Geode database.
> # Credit:
> The issue is found by Nguyen Thai Hung (@nth347), Viettel Cyber Security.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (GEODE-10411) XSS vulnerabiltiy in Pulse data browser

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-10411:
---
Labels: pull-request-available  (was: needsTriage pull-request-available)

> XSS vulnerabiltiy in Pulse data browser
> ---
>
> Key: GEODE-10411
> URL: https://issues.apache.org/jira/browse/GEODE-10411
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Affects Versions: 1.12.9, 1.12.10, 1.13.8, 1.13.9, 1.14.4, 1.14.5, 1.15.0, 
> 1.15.1, 1.16.0
>Reporter: Joris Melchior
>Assignee: Joris Melchior
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.12.10, 1.13.9, 1.14.5, 1.15.1, 1.16.0
>
>
> # Description:
> Stored XSS via data injection into Geode database, the injected
> payload eventually gets executed on Pulse web application when the
> admin querying data from Geode.
> # PoC:
> Step 1: With Geode up and running, run gfsh command to get into
> interactive mode:
>    shell$ gfsh
> Step 2: In gfsh console, execute the following command to insert a
> data entry into regionA (assume that regionA is created before). Note
> that the value of this data entry contains JavaScript code:
>    gfsh> put --region=regionA --key="test" --value="alert(1)"
> Step 3: Open browser to query editor of Pulse web application at
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.168.93.153%3A7070%2Fpulse%2FdataBrowser.htmldata=05%7C01%7Cbakera%40vmware.com%7Cc06e6de8d92c4519303708da54fa7d03%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637915732081233095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=ykaOkxe1hlaE7xl8XQNgBQz2%2Ful1QPxrUChoBkuaeyY%3Dreserved=0
>  (assume that already
> logged in as admin), execute the following query:
> SELECT * FROM /regionA
> Step 4: Data from regionA will be retrieved, the XSS payload
> eventually get executed
> # Why this is an issue?
> Developer maybe saves user-controlled data to Geode database, users
> maybe submit data via an arbitrary client application (for example, a
> web application), the use of gfsh console just simplifies the PoC.
> # IMPACT:
> Exploiting this XSS vulnerability, an attacker can steal the admin's
> session cookie, therefore take over the admin account.
> # CVSS: 7.6 HIGH
> (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.first.org%2Fcvss%2Fcalculator%2F3.0%23CVSS%3A3.0%2FAV%3AN%2FAC%3AL%2FPR%3AN%2FUI%3AR%2FS%3AU%2FC%3AH%2FI%3AL%2FA%3ALdata=05%7C01%7Cbakera%40vmware.com%7Cc06e6de8d92c4519303708da54fa7d03%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637915732081233095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=W5dDA8kMdT1IVeUVX6mhWHhZ2HnAZbXErEB%2F0Tjs5hg%3Dreserved=0
>  )
> (re-calculate if not correct)
> # Fix:
> The Pulse web application must URL encode data retrieved from Geode database.
> # Credit:
> The issue is found by Nguyen Thai Hung (@nth347), Viettel Cyber Security.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (GEODE-10411) XSS vulnerabiltiy in Pulse data browser

[Joris Melchior (Jira)]

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

Joris Melchior resolved GEODE-10411.

Resolution: Fixed

Fix created and back ported to maintenance branches.

> XSS vulnerabiltiy in Pulse data browser
> ---
>
> Key: GEODE-10411
> URL: https://issues.apache.org/jira/browse/GEODE-10411
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Affects Versions: 1.12.9, 1.12.10, 1.14.4, 1.14.5, 1.15.0, 1.15.1, 1.16.0
>Reporter: Joris Melchior
>Assignee: Joris Melchior
>Priority: Major
>  Labels: needsTriage, pull-request-available
>
> # Description:
> Stored XSS via data injection into Geode database, the injected
> payload eventually gets executed on Pulse web application when the
> admin querying data from Geode.
> # PoC:
> Step 1: With Geode up and running, run gfsh command to get into
> interactive mode:
>    shell$ gfsh
> Step 2: In gfsh console, execute the following command to insert a
> data entry into regionA (assume that regionA is created before). Note
> that the value of this data entry contains JavaScript code:
>    gfsh> put --region=regionA --key="test" --value="alert(1)"
> Step 3: Open browser to query editor of Pulse web application at
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.168.93.153%3A7070%2Fpulse%2FdataBrowser.htmldata=05%7C01%7Cbakera%40vmware.com%7Cc06e6de8d92c4519303708da54fa7d03%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637915732081233095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=ykaOkxe1hlaE7xl8XQNgBQz2%2Ful1QPxrUChoBkuaeyY%3Dreserved=0
>  (assume that already
> logged in as admin), execute the following query:
> SELECT * FROM /regionA
> Step 4: Data from regionA will be retrieved, the XSS payload
> eventually get executed
> # Why this is an issue?
> Developer maybe saves user-controlled data to Geode database, users
> maybe submit data via an arbitrary client application (for example, a
> web application), the use of gfsh console just simplifies the PoC.
> # IMPACT:
> Exploiting this XSS vulnerability, an attacker can steal the admin's
> session cookie, therefore take over the admin account.
> # CVSS: 7.6 HIGH
> (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.first.org%2Fcvss%2Fcalculator%2F3.0%23CVSS%3A3.0%2FAV%3AN%2FAC%3AL%2FPR%3AN%2FUI%3AR%2FS%3AU%2FC%3AH%2FI%3AL%2FA%3ALdata=05%7C01%7Cbakera%40vmware.com%7Cc06e6de8d92c4519303708da54fa7d03%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637915732081233095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=W5dDA8kMdT1IVeUVX6mhWHhZ2HnAZbXErEB%2F0Tjs5hg%3Dreserved=0
>  )
> (re-calculate if not correct)
> # Fix:
> The Pulse web application must URL encode data retrieved from Geode database.
> # Credit:
> The issue is found by Nguyen Thai Hung (@nth347), Viettel Cyber Security.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (GEODE-10411) XSS vulnerabiltiy in Pulse data browser

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-10411:
---
Fix Version/s: 1.12.10
   1.13.9
   1.14.5
   1.15.1
   1.16.0

> XSS vulnerabiltiy in Pulse data browser
> ---
>
> Key: GEODE-10411
> URL: https://issues.apache.org/jira/browse/GEODE-10411
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Affects Versions: 1.12.9, 1.12.10, 1.14.4, 1.14.5, 1.15.0, 1.15.1, 1.16.0
>Reporter: Joris Melchior
>Assignee: Joris Melchior
>Priority: Major
>  Labels: needsTriage, pull-request-available
> Fix For: 1.12.10, 1.13.9, 1.14.5, 1.15.1, 1.16.0
>
>
> # Description:
> Stored XSS via data injection into Geode database, the injected
> payload eventually gets executed on Pulse web application when the
> admin querying data from Geode.
> # PoC:
> Step 1: With Geode up and running, run gfsh command to get into
> interactive mode:
>    shell$ gfsh
> Step 2: In gfsh console, execute the following command to insert a
> data entry into regionA (assume that regionA is created before). Note
> that the value of this data entry contains JavaScript code:
>    gfsh> put --region=regionA --key="test" --value="alert(1)"
> Step 3: Open browser to query editor of Pulse web application at
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.168.93.153%3A7070%2Fpulse%2FdataBrowser.htmldata=05%7C01%7Cbakera%40vmware.com%7Cc06e6de8d92c4519303708da54fa7d03%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637915732081233095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=ykaOkxe1hlaE7xl8XQNgBQz2%2Ful1QPxrUChoBkuaeyY%3Dreserved=0
>  (assume that already
> logged in as admin), execute the following query:
> SELECT * FROM /regionA
> Step 4: Data from regionA will be retrieved, the XSS payload
> eventually get executed
> # Why this is an issue?
> Developer maybe saves user-controlled data to Geode database, users
> maybe submit data via an arbitrary client application (for example, a
> web application), the use of gfsh console just simplifies the PoC.
> # IMPACT:
> Exploiting this XSS vulnerability, an attacker can steal the admin's
> session cookie, therefore take over the admin account.
> # CVSS: 7.6 HIGH
> (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.first.org%2Fcvss%2Fcalculator%2F3.0%23CVSS%3A3.0%2FAV%3AN%2FAC%3AL%2FPR%3AN%2FUI%3AR%2FS%3AU%2FC%3AH%2FI%3AL%2FA%3ALdata=05%7C01%7Cbakera%40vmware.com%7Cc06e6de8d92c4519303708da54fa7d03%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637915732081233095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=W5dDA8kMdT1IVeUVX6mhWHhZ2HnAZbXErEB%2F0Tjs5hg%3Dreserved=0
>  )
> (re-calculate if not correct)
> # Fix:
> The Pulse web application must URL encode data retrieved from Geode database.
> # Credit:
> The issue is found by Nguyen Thai Hung (@nth347), Viettel Cyber Security.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (GEODE-10411) XSS vulnerabiltiy in Pulse data browser

[Joris Melchior (Jira)]

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

Joris Melchior commented on GEODE-10411:


Fix and PR submitted for develop branch. Will back-port once the fix is merged 
into develop.

> XSS vulnerabiltiy in Pulse data browser
> ---
>
> Key: GEODE-10411
> URL: https://issues.apache.org/jira/browse/GEODE-10411
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Affects Versions: 1.12.9, 1.12.10, 1.14.4, 1.14.5, 1.15.0, 1.15.1, 1.16.0
>Reporter: Joris Melchior
>Assignee: Joris Melchior
>Priority: Major
>  Labels: needsTriage, pull-request-available
>
> # Description:
> Stored XSS via data injection into Geode database, the injected
> payload eventually gets executed on Pulse web application when the
> admin querying data from Geode.
> # PoC:
> Step 1: With Geode up and running, run gfsh command to get into
> interactive mode:
>    shell$ gfsh
> Step 2: In gfsh console, execute the following command to insert a
> data entry into regionA (assume that regionA is created before). Note
> that the value of this data entry contains JavaScript code:
>    gfsh> put --region=regionA --key="test" --value="alert(1)"
> Step 3: Open browser to query editor of Pulse web application at
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.168.93.153%3A7070%2Fpulse%2FdataBrowser.htmldata=05%7C01%7Cbakera%40vmware.com%7Cc06e6de8d92c4519303708da54fa7d03%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637915732081233095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=ykaOkxe1hlaE7xl8XQNgBQz2%2Ful1QPxrUChoBkuaeyY%3Dreserved=0
>  (assume that already
> logged in as admin), execute the following query:
> SELECT * FROM /regionA
> Step 4: Data from regionA will be retrieved, the XSS payload
> eventually get executed
> # Why this is an issue?
> Developer maybe saves user-controlled data to Geode database, users
> maybe submit data via an arbitrary client application (for example, a
> web application), the use of gfsh console just simplifies the PoC.
> # IMPACT:
> Exploiting this XSS vulnerability, an attacker can steal the admin's
> session cookie, therefore take over the admin account.
> # CVSS: 7.6 HIGH
> (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.first.org%2Fcvss%2Fcalculator%2F3.0%23CVSS%3A3.0%2FAV%3AN%2FAC%3AL%2FPR%3AN%2FUI%3AR%2FS%3AU%2FC%3AH%2FI%3AL%2FA%3ALdata=05%7C01%7Cbakera%40vmware.com%7Cc06e6de8d92c4519303708da54fa7d03%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637915732081233095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=W5dDA8kMdT1IVeUVX6mhWHhZ2HnAZbXErEB%2F0Tjs5hg%3Dreserved=0
>  )
> (re-calculate if not correct)
> # Fix:
> The Pulse web application must URL encode data retrieved from Geode database.
> # Credit:
> The issue is found by Nguyen Thai Hung (@nth347), Viettel Cyber Security.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (GEODE-10411) XSS vulnerabiltiy in Pulse data browser

[Joris Melchior (Jira)]

Joris Melchior created GEODE-10411:
--

 Summary: XSS vulnerabiltiy in Pulse data browser
 Key: GEODE-10411
 URL: https://issues.apache.org/jira/browse/GEODE-10411
 Project: Geode
  Issue Type: Bug
  Components: pulse
Affects Versions: 1.15.0, 1.14.4, 1.12.9, 1.12.10, 1.14.5, 1.15.1, 1.16.0
Reporter: Joris Melchior


# Description:

Stored XSS via data injection into Geode database, the injected
payload eventually gets executed on Pulse web application when the
admin querying data from Geode.

# PoC:

Step 1: With Geode up and running, run gfsh command to get into
interactive mode:

   shell$ gfsh

Step 2: In gfsh console, execute the following command to insert a
data entry into regionA (assume that regionA is created before). Note
that the value of this data entry contains JavaScript code:

   gfsh> put --region=regionA --key="test" --value="alert(1)"

Step 3: Open browser to query editor of Pulse web application at
https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.168.93.153%3A7070%2Fpulse%2FdataBrowser.htmldata=05%7C01%7Cbakera%40vmware.com%7Cc06e6de8d92c4519303708da54fa7d03%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637915732081233095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=ykaOkxe1hlaE7xl8XQNgBQz2%2Ful1QPxrUChoBkuaeyY%3Dreserved=0
 (assume that already
logged in as admin), execute the following query:

SELECT * FROM /regionA

Step 4: Data from regionA will be retrieved, the XSS payload
eventually get executed

# Why this is an issue?

Developer maybe saves user-controlled data to Geode database, users
maybe submit data via an arbitrary client application (for example, a
web application), the use of gfsh console just simplifies the PoC.

# IMPACT:

Exploiting this XSS vulnerability, an attacker can steal the admin's
session cookie, therefore take over the admin account.

# CVSS: 7.6 HIGH
(https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.first.org%2Fcvss%2Fcalculator%2F3.0%23CVSS%3A3.0%2FAV%3AN%2FAC%3AL%2FPR%3AN%2FUI%3AR%2FS%3AU%2FC%3AH%2FI%3AL%2FA%3ALdata=05%7C01%7Cbakera%40vmware.com%7Cc06e6de8d92c4519303708da54fa7d03%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637915732081233095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=W5dDA8kMdT1IVeUVX6mhWHhZ2HnAZbXErEB%2F0Tjs5hg%3Dreserved=0
 )
(re-calculate if not correct)

# Fix:

The Pulse web application must URL encode data retrieved from Geode database.

# Credit:

The issue is found by Nguyen Thai Hung (@nth347), Viettel Cyber Security.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (GEODE-10411) XSS vulnerabiltiy in Pulse data browser

[Joris Melchior (Jira)]

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

Joris Melchior reassigned GEODE-10411:
--

Assignee: Joris Melchior

> XSS vulnerabiltiy in Pulse data browser
> ---
>
> Key: GEODE-10411
> URL: https://issues.apache.org/jira/browse/GEODE-10411
> Project: Geode
>  Issue Type: Bug
>  Components: pulse
>Affects Versions: 1.12.9, 1.12.10, 1.14.4, 1.14.5, 1.15.0, 1.15.1, 1.16.0
>Reporter: Joris Melchior
>Assignee: Joris Melchior
>Priority: Major
>  Labels: needsTriage
>
> # Description:
> Stored XSS via data injection into Geode database, the injected
> payload eventually gets executed on Pulse web application when the
> admin querying data from Geode.
> # PoC:
> Step 1: With Geode up and running, run gfsh command to get into
> interactive mode:
>    shell$ gfsh
> Step 2: In gfsh console, execute the following command to insert a
> data entry into regionA (assume that regionA is created before). Note
> that the value of this data entry contains JavaScript code:
>    gfsh> put --region=regionA --key="test" --value="alert(1)"
> Step 3: Open browser to query editor of Pulse web application at
> https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2F192.168.93.153%3A7070%2Fpulse%2FdataBrowser.htmldata=05%7C01%7Cbakera%40vmware.com%7Cc06e6de8d92c4519303708da54fa7d03%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637915732081233095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=ykaOkxe1hlaE7xl8XQNgBQz2%2Ful1QPxrUChoBkuaeyY%3Dreserved=0
>  (assume that already
> logged in as admin), execute the following query:
> SELECT * FROM /regionA
> Step 4: Data from regionA will be retrieved, the XSS payload
> eventually get executed
> # Why this is an issue?
> Developer maybe saves user-controlled data to Geode database, users
> maybe submit data via an arbitrary client application (for example, a
> web application), the use of gfsh console just simplifies the PoC.
> # IMPACT:
> Exploiting this XSS vulnerability, an attacker can steal the admin's
> session cookie, therefore take over the admin account.
> # CVSS: 7.6 HIGH
> (https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.first.org%2Fcvss%2Fcalculator%2F3.0%23CVSS%3A3.0%2FAV%3AN%2FAC%3AL%2FPR%3AN%2FUI%3AR%2FS%3AU%2FC%3AH%2FI%3AL%2FA%3ALdata=05%7C01%7Cbakera%40vmware.com%7Cc06e6de8d92c4519303708da54fa7d03%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637915732081233095%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=W5dDA8kMdT1IVeUVX6mhWHhZ2HnAZbXErEB%2F0Tjs5hg%3Dreserved=0
>  )
> (re-calculate if not correct)
> # Fix:
> The Pulse web application must URL encode data retrieved from Geode database.
> # Credit:
> The issue is found by Nguyen Thai Hung (@nth347), Viettel Cyber Security.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (GEODE-10393) RegionEntryFactory.getEntryClass() return type should have generic type

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-10393:
---
Affects Version/s: 1.14.4
   1.12.9
   1.15.1

> RegionEntryFactory.getEntryClass() return type should have generic type
> ---
>
> Key: GEODE-10393
> URL: https://issues.apache.org/jira/browse/GEODE-10393
> Project: Geode
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.12.9, 1.14.4, 1.15.1, 1.16.0
>Reporter: Joris Melchior
>Assignee: Joris Melchior
>Priority: Minor
>
> The interface `RegionEntryFactory.getEntryClass()` returns a class without a 
> generic type. Because of this there are compiler warnings.
> By adding a generic type we can reduce the number of warnings we get in our 
> code.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Updated] (GEODE-10393) RegionEntryFactory.getEntryClass() return type should have generic type

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-10393:
---
Priority: Minor  (was: Major)

> RegionEntryFactory.getEntryClass() return type should have generic type
> ---
>
> Key: GEODE-10393
> URL: https://issues.apache.org/jira/browse/GEODE-10393
> Project: Geode
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.16.0
>Reporter: Joris Melchior
>Assignee: Joris Melchior
>Priority: Minor
>
> The interface `RegionEntryFactory.getEntryClass()` returns a class without a 
> generic type. Because of this there are compiler warnings.
> By adding a generic type we can reduce the number of warnings we get in our 
> code.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Assigned] (GEODE-10393) RegionEntryFactory.getEntryClass() return type should have generic type

[Joris Melchior (Jira)]

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

Joris Melchior reassigned GEODE-10393:
--

Assignee: Joris Melchior

> RegionEntryFactory.getEntryClass() return type should have generic type
> ---
>
> Key: GEODE-10393
> URL: https://issues.apache.org/jira/browse/GEODE-10393
> Project: Geode
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 1.16.0
>Reporter: Joris Melchior
>Assignee: Joris Melchior
>Priority: Major
>
> The interface `RegionEntryFactory.getEntryClass()` returns a class without a 
> generic type. Because of this there are compiler warnings.
> By adding a generic type we can reduce the number of warnings we get in our 
> code.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Created] (GEODE-10393) RegionEntryFactory.getEntryClass() return type should have generic type

[Joris Melchior (Jira)]

Joris Melchior created GEODE-10393:
--

 Summary: RegionEntryFactory.getEntryClass() return type should 
have generic type
 Key: GEODE-10393
 URL: https://issues.apache.org/jira/browse/GEODE-10393
 Project: Geode
  Issue Type: Improvement
  Components: core
Affects Versions: 1.16.0
Reporter: Joris Melchior


The interface `RegionEntryFactory.getEntryClass()` returns a class without a 
generic type. Because of this there are compiler warnings.

By adding a generic type we can reduce the number of warnings we get in our 
code.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Resolved] (GEODE-10301) Allow users to have java.time.* types (like LocalDateTime, LocalDate, and LocalTime) in their query result fields.

[Joris Melchior (Jira)]

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

Joris Melchior resolved GEODE-10301.

Fix Version/s: 1.16.0
   Resolution: Fixed

> Allow users to have java.time.* types (like LocalDateTime, LocalDate, and 
> LocalTime) in their query result fields. 
> ---
>
> Key: GEODE-10301
> URL: https://issues.apache.org/jira/browse/GEODE-10301
> Project: Geode
>  Issue Type: Improvement
>Reporter: John Martin
>Assignee: Joris Melchior
>Priority: Major
>  Labels: blocks-1.15.0, pull-request-available
> Fix For: 1.16.0
>
>
> Users with java.time.* types (like LocalDateTime, LocalDate, and LocalTime) 
> in their query result fields will need to have, *jackson-datatype-jsr310* 
> and/or *jackson-datatype-joda* in the runtime classpath to have the proper 
> formatting. This currently requires users to manually add these classes.
>  
> To improve the user experience we should include these in the release.  We 
> should match the version of jackson-core that we release with.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Created] (GEODE-10345) Unable to bind port in DUnit test with LocatorLauncher

[Joris Melchior (Jira)]

Joris Melchior created GEODE-10345:
--

 Summary: Unable to bind port in DUnit test with LocatorLauncher
 Key: GEODE-10345
 URL: https://issues.apache.org/jira/browse/GEODE-10345
 Project: Geode
  Issue Type: Test
  Components: locator, tests
Affects Versions: 1.16.0
Reporter: Joris Melchior


> Task :geode-assembly:distributedTest

StartLocatorCommandDUnitTest > startLocatorRespectsHostnameForClients FAILED
org.opentest4j.AssertionFailedError: [The Locator process terminated 
unexpectedly with exit status 1. Please refer to the log file in 
/tmp/junit4420570198856523478/junit1807706233748416943 for full details.

Exception in thread "main" java.lang.RuntimeException: An IO error occurred 
while starting a Locator in 
/tmp/junit4420570198856523478/junit1807706233748416943 on 
heavy-lifter-2a24cff8-0d64-55e0-9585-2d6391f92533.c.apachegeode-ci.internal[10339]:
 Network is unreachable; port (10339) is not available on localhost.

  at 
org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:801)

  at 
org.apache.geode.distributed.LocatorLauncher.run(LocatorLauncher.java:685)

  at 
org.apache.geode.distributed.LocatorLauncher.main(LocatorLauncher.java:222)

Caused by: java.net.BindException: Network is unreachable; port (10339) is 
not available on localhost.

  at 
org.apache.geode.distributed.AbstractLauncher.assertPortAvailable(AbstractLauncher.java:142)

  at 
org.apache.geode.distributed.LocatorLauncher.start(LocatorLauncher.java:773)

  ... 2 more

] 
expected: OK
 but was: ERROR
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at 
org.apache.geode.test.junit.assertions.CommandResultAssert.statusIsSuccess(CommandResultAssert.java:108)
at 
org.apache.geode.management.internal.cli.commands.StartLocatorCommandDUnitTest.startLocatorRespectsHostnameForClients(StartLocatorCommandDUnitTest.java:256)

372 tests completed, 1 failed

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=  Test Results URI 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0261/test-results/distributedTest/1653765462/
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Test report artifacts from this job are available at:

http://files.apachegeode-ci.info/builds/apache-develop-mass-test-run/1.16.0-build.0261/test-artifacts/1653765462/distributedtestfiles-openjdk8-1.16.0-build.0261.tgz



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Assigned] (GEODE-10301) Allow users to have java.time.* types (like LocalDateTime, LocalDate, and LocalTime) in their query result fields.

[Joris Melchior (Jira)]

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

Joris Melchior reassigned GEODE-10301:
--

Assignee: Joris Melchior

> Allow users to have java.time.* types (like LocalDateTime, LocalDate, and 
> LocalTime) in their query result fields. 
> ---
>
> Key: GEODE-10301
> URL: https://issues.apache.org/jira/browse/GEODE-10301
> Project: Geode
>  Issue Type: Improvement
>Reporter: John Martin
>Assignee: Joris Melchior
>Priority: Major
>  Labels: blocks-1.15.0
>
> Users with java.time.* types (like LocalDateTime, LocalDate, and LocalTime) 
> in their query result fields will need to have, *jackson-datatype-jsr310* 
> and/or *jackson-datatype-joda* in the runtime classpath to have the proper 
> formatting. This currently requires users to manually add these classes.
>  
> To improve the user experience we should include these in the release.  We 
> should match the version of jackson-core that we release with.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Updated] (GEODE-10261) VMProvider.invokeAsync does not consistently use Generic types

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-10261:
---
Description: 
In the VMProvider class there are several invokeAsync methods with various 
signatures and in some cases they come with Generic type parameters and in some 
cases they don't.

It's possible that some of this is influenced by the use of 
SerializableCallableIF vs. SerializableRunnableIF so we need to dig a little 
deeper to find out to what degree we need to or can  make changes here.

  was:
In the VMProvider class there are several invokeAsync methods with various 
signatures and in some cases they come with Generic type parameters and in some 
cases they don't.

It's possible that some of this is influenced by the use of 
SerializableCallableIF vs. SerializableRunnableIF so we need to dig a little 
deeper to find out to what degree we need to make changes here.


> VMProvider.invokeAsync does not consistently use Generic types
> --
>
> Key: GEODE-10261
> URL: https://issues.apache.org/jira/browse/GEODE-10261
> Project: Geode
>  Issue Type: Improvement
>  Components: tests
>Affects Versions: 1.14.4
>Reporter: Joris Melchior
>Priority: Minor
>  Labels: needsTriage
>
> In the VMProvider class there are several invokeAsync methods with various 
> signatures and in some cases they come with Generic type parameters and in 
> some cases they don't.
> It's possible that some of this is influenced by the use of 
> SerializableCallableIF vs. SerializableRunnableIF so we need to dig a little 
> deeper to find out to what degree we need to or can  make changes here.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Updated] (GEODE-10261) VMProvider.invokeAsync does not consistently use Generic types

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-10261:
---
Labels: needsTriage  (was: )

> VMProvider.invokeAsync does not consistently use Generic types
> --
>
> Key: GEODE-10261
> URL: https://issues.apache.org/jira/browse/GEODE-10261
> Project: Geode
>  Issue Type: Improvement
>  Components: tests
>Affects Versions: 1.14.4
>Reporter: Joris Melchior
>Priority: Minor
>  Labels: needsTriage
>
> In the VMProvider class there are several invokeAsync methods with various 
> signatures and in some cases they come with Generic type parameters and in 
> some cases they don't.
> It's possible that some of this is influenced by the use of 
> SerializableCallableIF vs. SerializableRunnableIF so we need to dig a little 
> deeper to find out to what degree we need to make changes here.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Updated] (GEODE-10261) VMProvider.invokeAsync does not consistently use Generic types

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-10261:
---
Priority: Minor  (was: Major)

> VMProvider.invokeAsync does not consistently use Generic types
> --
>
> Key: GEODE-10261
> URL: https://issues.apache.org/jira/browse/GEODE-10261
> Project: Geode
>  Issue Type: Improvement
>  Components: tests
>Affects Versions: 1.14.4
>Reporter: Joris Melchior
>Priority: Minor
>
> In the VMProvider class there are several invokeAsync methods with various 
> signatures and in some cases they come with Generic type parameters and in 
> some cases they don't.
> It's possible that some of this is influenced by the use of 
> SerializableCallableIF vs. SerializableRunnableIF so we need to dig a little 
> deeper to find out to what degree we need to make changes here.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Created] (GEODE-10261) VMProvider.invokeAsync does not consistently use Generic types

[Joris Melchior (Jira)]

Joris Melchior created GEODE-10261:
--

 Summary: VMProvider.invokeAsync does not consistently use Generic 
types
 Key: GEODE-10261
 URL: https://issues.apache.org/jira/browse/GEODE-10261
 Project: Geode
  Issue Type: Improvement
  Components: tests
Affects Versions: 1.14.4
Reporter: Joris Melchior


In the VMProvider class there are several invokeAsync methods with various 
signatures and in some cases they come with Generic type parameters and in some 
cases they don't.

It's possible that some of this is influenced by the use of 
SerializableCallableIF vs. SerializableRunnableIF so we need to dig a little 
deeper to find out to what degree we need to make changes here.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Created] (GEODE-10219) CI Failure: geode-assembly:acceptanceTest failing for support/1.12 and support/1.13

[Joris Melchior (Jira)]

Joris Melchior created GEODE-10219:
--

 Summary: CI Failure: geode-assembly:acceptanceTest failing for 
support/1.12 and support/1.13
 Key: GEODE-10219
 URL: https://issues.apache.org/jira/browse/GEODE-10219
 Project: Geode
  Issue Type: Bug
  Components: gfsh
Affects Versions: 1.12.10, 1.13.9
Reporter: Joris Melchior


Repeated failure of `acceptance-test-openjdk11` with tests being unable to 
properly shut down members as part of the tests.

See 
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-12-main/jobs/acceptance-test-openjdk11/builds/51]

See 
[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-support-1-13-main/jobs/acceptance-test-openjdk11/builds/42]

 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-10163) AuthExpirationTransactionUpgradeTest fails with older versions of Geode due to changes to TXId class

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-10163:
---
Description: 
AuthExpirationTransactionUpgradeTest fails with older versions of Geode due to 
changes to TXId class that have taken place over time.

 

When running the test attempting to run against client versions of Geode older 
than 1.14 the test suffers from serialization errors due to changes to the TXId 
class.

  was:
AuthExpirationTransactionUpgradeTest fails with older versions of Geode due to 
changes to TXId class that have taken place over time.

 

When running the test attempting to run against versions of Geode older than 
1.14 the test suffers from serialization errors due to changes to the TXId 
class.


> AuthExpirationTransactionUpgradeTest fails with older versions of Geode due 
> to changes to TXId class
> 
>
> Key: GEODE-10163
> URL: https://issues.apache.org/jira/browse/GEODE-10163
> Project: Geode
>  Issue Type: Bug
>  Components: security
>Affects Versions: 1.15.0
>Reporter: Joris Melchior
>Assignee: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> AuthExpirationTransactionUpgradeTest fails with older versions of Geode due 
> to changes to TXId class that have taken place over time.
>  
> When running the test attempting to run against client versions of Geode 
> older than 1.14 the test suffers from serialization errors due to changes to 
> the TXId class.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-10163) AuthExpirationTransactionUpgradeTest fails with older versions of Geode due to changes to TXId class

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-10163:
---
Description: 
AuthExpirationTransactionUpgradeTest fails with older versions of Geode due to 
changes to TXId class that have taken place over time.

 

When running the test attempting to run against versions of Geode older than 
1.14 the test suffers from serialization errors due to changes to the TXId 
class.

  was:
AuthExpirationTransactionUpgradeTest fails with older versions of Geode due to 
changes to TXId class;

 

When running the test attempting to run against versions of Geode older than 
1.14 the test suffers from serialization errors due to changes to the TXId 
class.


> AuthExpirationTransactionUpgradeTest fails with older versions of Geode due 
> to changes to TXId class
> 
>
> Key: GEODE-10163
> URL: https://issues.apache.org/jira/browse/GEODE-10163
> Project: Geode
>  Issue Type: Bug
>  Components: security
>Affects Versions: 1.15.0
>Reporter: Joris Melchior
>Assignee: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI, needsTriage
>
> AuthExpirationTransactionUpgradeTest fails with older versions of Geode due 
> to changes to TXId class that have taken place over time.
>  
> When running the test attempting to run against versions of Geode older than 
> 1.14 the test suffers from serialization errors due to changes to the TXId 
> class.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-10163) AuthExpirationTransactionUpgradeTest fails with older versions of Geode due to changes to TXId class

[Joris Melchior (Jira)]

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

Joris Melchior commented on GEODE-10163:


Analysis shows that we can change the test so that it will not serialize the 
TXId class any longer. Instead we can exchange a String between the VMs that 
represents the TXId and where needed reconstitute the ID from the 
InternalDistributedMember and the Unique ID on the fly.

> AuthExpirationTransactionUpgradeTest fails with older versions of Geode due 
> to changes to TXId class
> 
>
> Key: GEODE-10163
> URL: https://issues.apache.org/jira/browse/GEODE-10163
> Project: Geode
>  Issue Type: Bug
>  Components: security
>Affects Versions: 1.15.0
>Reporter: Joris Melchior
>Assignee: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI, needsTriage
>
> AuthExpirationTransactionUpgradeTest fails with older versions of Geode due 
> to changes to TXId class;
>  
> When running the test attempting to run against versions of Geode older than 
> 1.14 the test suffers from serialization errors due to changes to the TXId 
> class.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Assigned] (GEODE-10163) AuthExpirationTransactionUpgradeTest fails with older versions of Geode due to changes to TXId class

[Joris Melchior (Jira)]

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

Joris Melchior reassigned GEODE-10163:
--

Assignee: Joris Melchior

> AuthExpirationTransactionUpgradeTest fails with older versions of Geode due 
> to changes to TXId class
> 
>
> Key: GEODE-10163
> URL: https://issues.apache.org/jira/browse/GEODE-10163
> Project: Geode
>  Issue Type: Bug
>  Components: security
>Affects Versions: 1.15.0
>Reporter: Joris Melchior
>Assignee: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI, needsTriage
>
> AuthExpirationTransactionUpgradeTest fails with older versions of Geode due 
> to changes to TXId class;
>  
> When running the test attempting to run against versions of Geode older than 
> 1.14 the test suffers from serialization errors due to changes to the TXId 
> class.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-10163) AuthExpirationTransactionUpgradeTest fails with older versions of Geode due to changes to TXId class

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-10163:
---
Labels: GeodeOperationAPI needsTriage  (was: needsTriage)

> AuthExpirationTransactionUpgradeTest fails with older versions of Geode due 
> to changes to TXId class
> 
>
> Key: GEODE-10163
> URL: https://issues.apache.org/jira/browse/GEODE-10163
> Project: Geode
>  Issue Type: Bug
>  Components: security
>Affects Versions: 1.15.0
>Reporter: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI, needsTriage
>
> AuthExpirationTransactionUpgradeTest fails with older versions of Geode due 
> to changes to TXId class;
>  
> When running the test attempting to run against versions of Geode older than 
> 1.14 the test suffers from serialization errors due to changes to the TXId 
> class.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (GEODE-10163) AuthExpirationTransactionUpgradeTest fails with older versions of Geode due to changes to TXId class

[Joris Melchior (Jira)]

Joris Melchior created GEODE-10163:
--

 Summary: AuthExpirationTransactionUpgradeTest fails with older 
versions of Geode due to changes to TXId class
 Key: GEODE-10163
 URL: https://issues.apache.org/jira/browse/GEODE-10163
 Project: Geode
  Issue Type: Bug
  Components: security
Affects Versions: 1.15.0
Reporter: Joris Melchior


AuthExpirationTransactionUpgradeTest fails with older versions of Geode due to 
changes to TXId class;

 

When running the test attempting to run against versions of Geode older than 
1.14 the test suffers from serialization errors due to changes to the TXId 
class.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-10142) StatArchiveHandlerConfig.getArchiveFileName returns File and should be named appropriately

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-10142:
---
Labels: GeodeOperationAPI  (was: )

> StatArchiveHandlerConfig.getArchiveFileName returns File and should be named 
> appropriately
> --
>
> Key: GEODE-10142
> URL: https://issues.apache.org/jira/browse/GEODE-10142
> Project: Geode
>  Issue Type: Improvement
>  Components: statistics
>Affects Versions: 1.14.4
>Reporter: Joris Melchior
>Priority: Minor
>  Labels: GeodeOperationAPI
>
> The interface `StatArchiveHandlerConfig` declares the method 
> `getArchiveFileName` that returns a `File` object and not a name as the 
> method name indicates. 
> It makes sense to rename the method to match the functionality.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-10143) ClusterStartupRule.withLogFile does not seem to work as described in comment

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-10143:
---
Labels: GeodeOperationAPI needsTriage  (was: needsTriage)

> ClusterStartupRule.withLogFile does not seem to work as described in comment
> 
>
> Key: GEODE-10143
> URL: https://issues.apache.org/jira/browse/GEODE-10143
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Affects Versions: 1.14.4
>Reporter: Joris Melchior
>Priority: Minor
>  Labels: GeodeOperationAPI, needsTriage
>
> ClusterStartupRule.withLogFile method comment describes that using the flag 
> will redirect output from standard out to log files. When used this does not 
> seem to be the case.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-10143) ClusterStartupRule.withLogFile does not seem to work as described in comment

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-10143:
---
Priority: Minor  (was: Major)

> ClusterStartupRule.withLogFile does not seem to work as described in comment
> 
>
> Key: GEODE-10143
> URL: https://issues.apache.org/jira/browse/GEODE-10143
> Project: Geode
>  Issue Type: Bug
>  Components: tests
>Affects Versions: 1.14.4
>Reporter: Joris Melchior
>Priority: Minor
>  Labels: needsTriage
>
> ClusterStartupRule.withLogFile method comment describes that using the flag 
> will redirect output from standard out to log files. When used this does not 
> seem to be the case.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (GEODE-10143) ClusterStartupRule.withLogFile does not seem to work as described in comment

[Joris Melchior (Jira)]

Joris Melchior created GEODE-10143:
--

 Summary: ClusterStartupRule.withLogFile does not seem to work as 
described in comment
 Key: GEODE-10143
 URL: https://issues.apache.org/jira/browse/GEODE-10143
 Project: Geode
  Issue Type: Bug
  Components: tests
Affects Versions: 1.14.4
Reporter: Joris Melchior


ClusterStartupRule.withLogFile method comment describes that using the flag 
will redirect output from standard out to log files. When used this does not 
seem to be the case.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-10142) StatArchiveHandlerConfig.getArchiveFileName returns File and should be named appropriately

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-10142:
---
Description: 
The interface `StatArchiveHandlerConfig` declares the method 
`getArchiveFileName` that returns a `File` object and not a name as the method 
name indicates. 

It makes sense to rename the method to match the functionality.

  was:
The interface `StatArchiveHandlerConfig` declares the method 
`getArchiveFileName` returns a `File` object and not a name as the method name 
indicates. 

It makes sense to rename the method to match the the functionality.


> StatArchiveHandlerConfig.getArchiveFileName returns File and should be named 
> appropriately
> --
>
> Key: GEODE-10142
> URL: https://issues.apache.org/jira/browse/GEODE-10142
> Project: Geode
>  Issue Type: Improvement
>  Components: statistics
>Affects Versions: 1.14.4
>Reporter: Joris Melchior
>Priority: Minor
>
> The interface `StatArchiveHandlerConfig` declares the method 
> `getArchiveFileName` that returns a `File` object and not a name as the 
> method name indicates. 
> It makes sense to rename the method to match the functionality.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-10142) StatArchiveHandlerConfig.getArchiveFileName returns File and should be named appropriately

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-10142:
---
Priority: Minor  (was: Major)

> StatArchiveHandlerConfig.getArchiveFileName returns File and should be named 
> appropriately
> --
>
> Key: GEODE-10142
> URL: https://issues.apache.org/jira/browse/GEODE-10142
> Project: Geode
>  Issue Type: Improvement
>  Components: statistics
>Affects Versions: 1.14.4
>Reporter: Joris Melchior
>Priority: Minor
>
> The interface `StatArchiveHandlerConfig` declares the method 
> `getArchiveFileName` returns a `File` object and not a name as the method 
> name indicates. 
> It makes sense to rename the method to match the the functionality.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (GEODE-10142) StatArchiveHandlerConfig.getArchiveFileName returns File and should be named appropriately

[Joris Melchior (Jira)]

Joris Melchior created GEODE-10142:
--

 Summary: StatArchiveHandlerConfig.getArchiveFileName returns File 
and should be named appropriately
 Key: GEODE-10142
 URL: https://issues.apache.org/jira/browse/GEODE-10142
 Project: Geode
  Issue Type: Improvement
  Components: statistics
Affects Versions: 1.14.4
Reporter: Joris Melchior


The interface `StatArchiveHandlerConfig` declares the method 
`getArchiveFileName` returns a `File` object and not a name as the method name 
indicates. 

It makes sense to rename the method to match the the functionality.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-9990) Geode should handle certain DiskAccessException due to CacheClosedException when creating bucket

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-9990:
--
Labels: GeodeOperationAPI pull-request-available  (was: GeodeOperationAPI 
blocks-1.15.0​ pull-request-available)

> Geode should handle certain DiskAccessException due to CacheClosedException 
> when creating bucket
> 
>
> Key: GEODE-9990
> URL: https://issues.apache.org/jira/browse/GEODE-9990
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 1.15.0
>Reporter: Eric Shu
>Assignee: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI, pull-request-available
>
> This exception is thrown to the node that tries to create the bucket to 
> prevent it trying to create the bucket to next available server and fail the 
> entry operation.
> {noformat}
> org.apache.geode.cache.DiskAccessException: For DiskStore: diskStore: The 
> disk store is closed
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.DiskInitFile.writeIFRecord(DiskInitFile.java:1313)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.DiskInitFile.writeIFRecord(DiskInitFile.java:916)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.DiskInitFile.markInitialized(DiskInitFile.java:2158)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.DiskStoreImpl.setInitialized(DiskStoreImpl.java:3057)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.AbstractDiskRegion.setInitialized(AbstractDiskRegion.java:606)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.setOnline(PersistenceAdvisorImpl.java:392)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.BucketPersistenceAdvisor.endBucketCreation(BucketPersistenceAdvisor.java:467)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.PRHARedundancyProvider.endBucketCreationLocally(PRHARedundancyProvider.java:854)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.PRHARedundancyProvider.endBucketCreation(PRHARedundancyProvider.java:813)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.PRHARedundancyProvider.createBucketAtomically(PRHARedundancyProvider.java:701)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.partitioned.CreateBucketMessage.operateOnPartitionedRegion(CreateBucketMessage.java:150)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:333)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at Remote Member 
> 

[jira] [Assigned] (GEODE-9910) Failure to auto-reconnect upon network partition

[Joris Melchior (Jira)]

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

Joris Melchior reassigned GEODE-9910:
-

Assignee: Barrett Oglesby  (was: Joris Melchior)

> Failure to auto-reconnect upon network partition
> 
>
> Key: GEODE-9910
> URL: https://issues.apache.org/jira/browse/GEODE-9910
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Surya Mudundi
>Assignee: Barrett Oglesby
>Priority: Major
>  Labels: GeodeOperationAPI, blocks-1.15.0​, needsTriage
> Attachments: geode-logs.zip
>
>
> Two node cluster with embedded locators failed to auto-reconnect when node-1 
> experienced network outage for couple of minutes and when node-1 recovered 
> from the outage, node-2 failed to auto-reconnect.
> node-2 tried to re-connect to node-1 as:
> [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread]
>  [] Attempting to reconnect to the distributed system.  This is attempt #1.
> [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread]
>  [] Attempting to reconnect to the distributed system.  This is attempt #2.
> [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread]
>  [] Attempting to reconnect to the distributed system.  This is attempt #3.
> Finally reported below error after 3 attempts as:
> INFO  
> [org.apache.geode.logging.internal.LoggingProviderLoader]-[ReconnectThread] 
> [] Using org.apache.geode.logging.internal.SimpleLoggingProvider for service 
> org.apache.geode.logging.internal.spi.LoggingProvider
> INFO  [org.apache.geode.internal.InternalDataSerializer]-[ReconnectThread] [] 
> initializing InternalDataSerializer with 0 services
> INFO  
> [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread]
>  [] performing a quorum check to see if location services can be started early
> INFO  
> [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread]
>  [] Quorum check passed - allowing location services to start early
> WARN  
> [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread]
>  [] Exception occurred while trying to connect the system during reconnect
> java.lang.IllegalStateException: A locator can not be created because one 
> already exists in this JVM.
>         at 
> org.apache.geode.distributed.internal.InternalLocator.createLocator(InternalLocator.java:298)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalLocator.createLocator(InternalLocator.java:273)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.startInitLocator(InternalDistributedSystem.java:916)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:768)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3034)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2605)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2424)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1275)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:2326)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.uncleanShutdown(GMSMembership.java:1187)
>  ~[geode-membership-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$forceDisconnect$0(GMSMembership.java:1811)
>  ~[geode-membership-1.14.0.jar:?]
>         at java.lang.Thread.run(Thread.java:829) [?:?]
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Assigned] (GEODE-9910) Failure to auto-reconnect upon network partition

[Joris Melchior (Jira)]

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

Joris Melchior reassigned GEODE-9910:
-

Assignee: Joris Melchior  (was: Barrett Oglesby)

> Failure to auto-reconnect upon network partition
> 
>
> Key: GEODE-9910
> URL: https://issues.apache.org/jira/browse/GEODE-9910
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Surya Mudundi
>Assignee: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI, blocks-1.15.0​, needsTriage
> Attachments: geode-logs.zip
>
>
> Two node cluster with embedded locators failed to auto-reconnect when node-1 
> experienced network outage for couple of minutes and when node-1 recovered 
> from the outage, node-2 failed to auto-reconnect.
> node-2 tried to re-connect to node-1 as:
> [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread]
>  [] Attempting to reconnect to the distributed system.  This is attempt #1.
> [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread]
>  [] Attempting to reconnect to the distributed system.  This is attempt #2.
> [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread]
>  [] Attempting to reconnect to the distributed system.  This is attempt #3.
> Finally reported below error after 3 attempts as:
> INFO  
> [org.apache.geode.logging.internal.LoggingProviderLoader]-[ReconnectThread] 
> [] Using org.apache.geode.logging.internal.SimpleLoggingProvider for service 
> org.apache.geode.logging.internal.spi.LoggingProvider
> INFO  [org.apache.geode.internal.InternalDataSerializer]-[ReconnectThread] [] 
> initializing InternalDataSerializer with 0 services
> INFO  
> [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread]
>  [] performing a quorum check to see if location services can be started early
> INFO  
> [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread]
>  [] Quorum check passed - allowing location services to start early
> WARN  
> [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread]
>  [] Exception occurred while trying to connect the system during reconnect
> java.lang.IllegalStateException: A locator can not be created because one 
> already exists in this JVM.
>         at 
> org.apache.geode.distributed.internal.InternalLocator.createLocator(InternalLocator.java:298)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalLocator.createLocator(InternalLocator.java:273)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.startInitLocator(InternalDistributedSystem.java:916)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:768)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3034)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2605)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2424)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1275)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:2326)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.uncleanShutdown(GMSMembership.java:1187)
>  ~[geode-membership-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$forceDisconnect$0(GMSMembership.java:1811)
>  ~[geode-membership-1.14.0.jar:?]
>         at java.lang.Thread.run(Thread.java:829) [?:?]
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-9910) Failure to auto-reconnect upon network partition

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-9910:
--
Labels: GeodeOperationAPI blocks-1.15.0​ needsTriage  (was: blocks-1.15.0​)

> Failure to auto-reconnect upon network partition
> 
>
> Key: GEODE-9910
> URL: https://issues.apache.org/jira/browse/GEODE-9910
> Project: Geode
>  Issue Type: Bug
>Affects Versions: 1.14.0
>Reporter: Surya Mudundi
>Priority: Major
>  Labels: GeodeOperationAPI, blocks-1.15.0​, needsTriage
>
> Two node cluster with embedded locators failed to auto-reconnect when node-1 
> experienced network outage for couple of minutes and when node-1 recovered 
> from the outage, node-2 failed to auto-reconnect.
> node-2 tried to re-connect to node-1 as:
> [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread]
>  [] Attempting to reconnect to the distributed system.  This is attempt #1.
> [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread]
>  [] Attempting to reconnect to the distributed system.  This is attempt #2.
> [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread]
>  [] Attempting to reconnect to the distributed system.  This is attempt #3.
> Finally reported below error after 3 attempts as:
> INFO  
> [org.apache.geode.logging.internal.LoggingProviderLoader]-[ReconnectThread] 
> [] Using org.apache.geode.logging.internal.SimpleLoggingProvider for service 
> org.apache.geode.logging.internal.spi.LoggingProvider
> INFO  [org.apache.geode.internal.InternalDataSerializer]-[ReconnectThread] [] 
> initializing InternalDataSerializer with 0 services
> INFO  
> [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread]
>  [] performing a quorum check to see if location services can be started early
> INFO  
> [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread]
>  [] Quorum check passed - allowing location services to start early
> WARN  
> [org.apache.geode.distributed.internal.InternalDistributedSystem]-[ReconnectThread]
>  [] Exception occurred while trying to connect the system during reconnect
> java.lang.IllegalStateException: A locator can not be created because one 
> already exists in this JVM.
>         at 
> org.apache.geode.distributed.internal.InternalLocator.createLocator(InternalLocator.java:298)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalLocator.createLocator(InternalLocator.java:273)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.startInitLocator(InternalDistributedSystem.java:916)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.initialize(InternalDistributedSystem.java:768)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.access$200(InternalDistributedSystem.java:135)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem$Builder.build(InternalDistributedSystem.java:3034)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.connectInternal(InternalDistributedSystem.java:290)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2605)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2424)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1275)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:2326)
>  ~[geode-core-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.membership.gms.GMSMembership.uncleanShutdown(GMSMembership.java:1187)
>  ~[geode-membership-1.14.0.jar:?]
>         at 
> org.apache.geode.distributed.internal.membership.gms.GMSMembership$ManagerImpl.lambda$forceDisconnect$0(GMSMembership.java:1811)
>  ~[geode-membership-1.14.0.jar:?]
>         at java.lang.Thread.run(Thread.java:829) [?:?]
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Commented] (GEODE-9261) Fix PartitionedRegionClearWithConcurrentOperationsDUnitTest validateRegionVersionVectorsConsistency

[Joris Melchior (Jira)]

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

Joris Melchior commented on GEODE-9261:
---

It appears that this DUnit test no longer exists. [~klund] can you confirm if 
this issue is still something that needs to be fixed?

> Fix PartitionedRegionClearWithConcurrentOperationsDUnitTest 
> validateRegionVersionVectorsConsistency
> ---
>
> Key: GEODE-9261
> URL: https://issues.apache.org/jira/browse/GEODE-9261
> Project: Geode
>  Issue Type: Sub-task
>  Components: regions
>Reporter: Kirk Lund
>Assignee: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI
>
> The validateRegionVersionVectorsConsistency method should be fixed to fetch 
> rvv2Members from rvv2 instead of rvv1. Unfortunately, the validation breaks 
> if this change is made. The test needs to be fixed and the underlying problem 
> needs to be identified and fixed before GEODE-7665 can be merged to develop.
> {noformat}
>   /**
>* Asserts that the RegionVersionVectors for both buckets are consistent.
>*
>* @param bucketId Id of the bucket to compare.
>* @param bucketDump1 First bucketDump.
>* @param bucketDump2 Second bucketDump.
>*/
>   private void validateRegionVersionVectorsConsistency(int bucketId, 
> BucketDump bucketDump1,
>   BucketDump bucketDump2) {
> RegionVersionVector rvv1 = bucketDump1.getRvv();
> RegionVersionVector rvv2 = bucketDump2.getRvv();
> Map, RegionVersionHolder> rvv2Members =
> new HashMap<>(rvv1.getMemberToVersion()); // TODO: getting 
> rvv2Members from rvv1 is wrong
> Map, RegionVersionHolder> rvv1Members =
> new HashMap<>(rvv1.getMemberToVersion());
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Assigned] (GEODE-9261) Fix PartitionedRegionClearWithConcurrentOperationsDUnitTest validateRegionVersionVectorsConsistency

[Joris Melchior (Jira)]

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

Joris Melchior reassigned GEODE-9261:
-

Assignee: Joris Melchior

> Fix PartitionedRegionClearWithConcurrentOperationsDUnitTest 
> validateRegionVersionVectorsConsistency
> ---
>
> Key: GEODE-9261
> URL: https://issues.apache.org/jira/browse/GEODE-9261
> Project: Geode
>  Issue Type: Sub-task
>  Components: regions
>Reporter: Kirk Lund
>Assignee: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI
>
> The validateRegionVersionVectorsConsistency method should be fixed to fetch 
> rvv2Members from rvv2 instead of rvv1. Unfortunately, the validation breaks 
> if this change is made. The test needs to be fixed and the underlying problem 
> needs to be identified and fixed before GEODE-7665 can be merged to develop.
> {noformat}
>   /**
>* Asserts that the RegionVersionVectors for both buckets are consistent.
>*
>* @param bucketId Id of the bucket to compare.
>* @param bucketDump1 First bucketDump.
>* @param bucketDump2 Second bucketDump.
>*/
>   private void validateRegionVersionVectorsConsistency(int bucketId, 
> BucketDump bucketDump1,
>   BucketDump bucketDump2) {
> RegionVersionVector rvv1 = bucketDump1.getRvv();
> RegionVersionVector rvv2 = bucketDump2.getRvv();
> Map, RegionVersionHolder> rvv2Members =
> new HashMap<>(rvv1.getMemberToVersion()); // TODO: getting 
> rvv2Members from rvv1 is wrong
> Map, RegionVersionHolder> rvv1Members =
> new HashMap<>(rvv1.getMemberToVersion());
> {noformat}



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (GEODE-9990) Geode should handle certain DiskAccessException due to CacheClosedException when creating bucket

[Joris Melchior (Jira)]

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

Joris Melchior resolved GEODE-9990.
---
Resolution: Fixed

PR merged

> Geode should handle certain DiskAccessException due to CacheClosedException 
> when creating bucket
> 
>
> Key: GEODE-9990
> URL: https://issues.apache.org/jira/browse/GEODE-9990
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 1.15.0
>Reporter: Eric Shu
>Assignee: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI, blocks-1.15.0​, pull-request-available
>
> This exception is thrown to the node that tries to create the bucket to 
> prevent it trying to create the bucket to next available server and fail the 
> entry operation.
> {noformat}
> org.apache.geode.cache.DiskAccessException: For DiskStore: diskStore: The 
> disk store is closed
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.DiskInitFile.writeIFRecord(DiskInitFile.java:1313)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.DiskInitFile.writeIFRecord(DiskInitFile.java:916)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.DiskInitFile.markInitialized(DiskInitFile.java:2158)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.DiskStoreImpl.setInitialized(DiskStoreImpl.java:3057)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.AbstractDiskRegion.setInitialized(AbstractDiskRegion.java:606)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.setOnline(PersistenceAdvisorImpl.java:392)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.BucketPersistenceAdvisor.endBucketCreation(BucketPersistenceAdvisor.java:467)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.PRHARedundancyProvider.endBucketCreationLocally(PRHARedundancyProvider.java:854)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.PRHARedundancyProvider.endBucketCreation(PRHARedundancyProvider.java:813)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.PRHARedundancyProvider.createBucketAtomically(PRHARedundancyProvider.java:701)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.partitioned.CreateBucketMessage.operateOnPartitionedRegion(CreateBucketMessage.java:150)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:333)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> 

[jira] [Assigned] (GEODE-9990) Geode should handle certain DiskAccessException due to CacheClosedException when creating bucket

[Joris Melchior (Jira)]

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

Joris Melchior reassigned GEODE-9990:
-

Assignee: Joris Melchior

> Geode should handle certain DiskAccessException due to CacheClosedException 
> when creating bucket
> 
>
> Key: GEODE-9990
> URL: https://issues.apache.org/jira/browse/GEODE-9990
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 1.15.0
>Reporter: Eric Shu
>Assignee: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI, needsTriage
>
> This exception is thrown to the node that tries to create the bucket to 
> prevent it trying to create the bucket to next available server and fail the 
> entry operation.
> {noformat}
> org.apache.geode.cache.DiskAccessException: For DiskStore: diskStore: The 
> disk store is closed
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.DiskInitFile.writeIFRecord(DiskInitFile.java:1313)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.DiskInitFile.writeIFRecord(DiskInitFile.java:916)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.DiskInitFile.markInitialized(DiskInitFile.java:2158)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.DiskStoreImpl.setInitialized(DiskStoreImpl.java:3057)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.AbstractDiskRegion.setInitialized(AbstractDiskRegion.java:606)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.setOnline(PersistenceAdvisorImpl.java:392)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.BucketPersistenceAdvisor.endBucketCreation(BucketPersistenceAdvisor.java:467)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.PRHARedundancyProvider.endBucketCreationLocally(PRHARedundancyProvider.java:854)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.PRHARedundancyProvider.endBucketCreation(PRHARedundancyProvider.java:813)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.PRHARedundancyProvider.createBucketAtomically(PRHARedundancyProvider.java:701)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.partitioned.CreateBucketMessage.operateOnPartitionedRegion(CreateBucketMessage.java:150)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:333)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> 

[jira] [Updated] (GEODE-9990) Geode should handle certain DiskAccessException due to CacheClosedException when creating bucket

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-9990:
--
Labels: GeodeOperationAPI needsTriage  (was: needsTriage)

> Geode should handle certain DiskAccessException due to CacheClosedException 
> when creating bucket
> 
>
> Key: GEODE-9990
> URL: https://issues.apache.org/jira/browse/GEODE-9990
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 1.15.0
>Reporter: Eric Shu
>Priority: Major
>  Labels: GeodeOperationAPI, needsTriage
>
> This exception is thrown to the node that tries to create the bucket to 
> prevent it trying to create the bucket to next available server and fail the 
> entry operation.
> {noformat}
> org.apache.geode.cache.DiskAccessException: For DiskStore: diskStore: The 
> disk store is closed
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.DiskInitFile.writeIFRecord(DiskInitFile.java:1313)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.DiskInitFile.writeIFRecord(DiskInitFile.java:916)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.DiskInitFile.markInitialized(DiskInitFile.java:2158)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.DiskStoreImpl.setInitialized(DiskStoreImpl.java:3057)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.AbstractDiskRegion.setInitialized(AbstractDiskRegion.java:606)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.setOnline(PersistenceAdvisorImpl.java:392)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.BucketPersistenceAdvisor.endBucketCreation(BucketPersistenceAdvisor.java:467)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.PRHARedundancyProvider.endBucketCreationLocally(PRHARedundancyProvider.java:854)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.PRHARedundancyProvider.endBucketCreation(PRHARedundancyProvider.java:813)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.PRHARedundancyProvider.createBucketAtomically(PRHARedundancyProvider.java:701)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.partitioned.CreateBucketMessage.operateOnPartitionedRegion(CreateBucketMessage.java:150)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.internal.cache.partitioned.PartitionMessage.process(PartitionMessage.java:333)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:376)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:441)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at Remote Member 
> 'rs-FullRegression21837175a0i3large-hydra-client-49(dataStoregemfire2_host1_31566:31566):41002'
>  in 
> 

[jira] [Resolved] (GEODE-9933) Update Geode documentation

[Joris Melchior (Jira)]

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

Joris Melchior resolved GEODE-9933.
---
Fix Version/s: 1.15.0
   Resolution: Fixed

The documentation has been updated to reflect the changes introduced by 
authentication expiry.

> Update Geode documentation
> --
>
> Key: GEODE-9933
> URL: https://issues.apache.org/jira/browse/GEODE-9933
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Joris Melchior
>Assignee: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> Create needed updates to `geode-docs` module
>  * New exceptions thrown in SecurityManager
>  * New Samples for implementation of security manager
>  * Some general mention of token based authentication and authorisation



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-9933) Update Geode documentation

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-9933:
--
Labels: GeodeOperationAPI  (was: )

> Update Geode documentation
> --
>
> Key: GEODE-9933
> URL: https://issues.apache.org/jira/browse/GEODE-9933
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Joris Melchior
>Assignee: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI
>
> Create needed updates to `geode-docs` module
>  * New exceptions thrown in SecurityManager
>  * New Samples for implementation of security manager
>  * Some general mention of token based authentication and authorisation



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Assigned] (GEODE-9933) Update Geode documentation

[Joris Melchior (Jira)]

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

Joris Melchior reassigned GEODE-9933:
-

Assignee: Joris Melchior

> Update Geode documentation
> --
>
> Key: GEODE-9933
> URL: https://issues.apache.org/jira/browse/GEODE-9933
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Joris Melchior
>Assignee: Joris Melchior
>Priority: Major
>
> Create needed updates to `geode-docs` module
>  * New exceptions thrown in SecurityManager
>  * New Samples for implementation of security manager
>  * Some general mention of token based authentication and authorisation



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (GEODE-9933) Update Geode documentation

[Joris Melchior (Jira)]

Joris Melchior created GEODE-9933:
-

 Summary: Update Geode documentation
 Key: GEODE-9933
 URL: https://issues.apache.org/jira/browse/GEODE-9933
 Project: Geode
  Issue Type: Sub-task
Reporter: Joris Melchior


Create needed updates to `geode-docs` module
 * New exceptions thrown in SecurityManager
 * New Samples for implementation of security manager
 * Some general mention of token based authentication and authorisation



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (GEODE-9900) Make sure all commands are sending back AuthenticationExpiredException as is

[Joris Melchior (Jira)]

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

Joris Melchior resolved GEODE-9900.
---
Resolution: Fixed

Updated the StopCQ and CloseCQ commands and added unit and dunit tests to 
confirm behaviour.

> Make sure all commands are sending back AuthenticationExpiredException as is
> 
>
> Key: GEODE-9900
> URL: https://issues.apache.org/jira/browse/GEODE-9900
> Project: Geode
>  Issue Type: Bug
>  Components: client/server, security
>Affects Versions: 1.15.0
>Reporter: Jinmei Liao
>Assignee: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI, needsTriage, pull-request-available
> Fix For: 1.15.0
>
>
> As we have discovered in GEODE-9820, some commands (especially CQ commands) 
> are not sending back `AuthenticationExpiredException` to the client with 
> MessageType.EXCEPTION, hence causing the client not wrapping it in the 
> correct form (See `AbstractOp around L300), We need to:
> 1. go over all the commands and find out what commands are NOT handling the 
> `AuthenticationExpiredExcpetion` correctly.
> 2. fix these commands, catch `AuthenticationExpiredException` specifically 
> and do a `writeException` (leave all other exception handling intact)
> 3. write tests to make sure we are sending the exception to the client.
> #1 would help us determine how many commands are in need of this fix and size 
> this story correctly.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-9900) Make sure all commands are sending back AuthenticationExpiredException as is

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-9900:
--
Labels: GeodeOperationAPI needsTriage  (was: ne)

> Make sure all commands are sending back AuthenticationExpiredException as is
> 
>
> Key: GEODE-9900
> URL: https://issues.apache.org/jira/browse/GEODE-9900
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Jinmei Liao
>Priority: Major
>  Labels: GeodeOperationAPI, needsTriage
>
> As we have discovered in GEODE-9820, some commands (especially CQ commands) 
> are not sending back `AuthenticationExpiredException` to the client with 
> MessageType.EXCEPTION, hence causing the client not wrapping it in the 
> correct form (See `AbstractOp around L300), We need to:
> 1. go over all the commands and find out what commands are NOT handling the 
> `AuthenticationExpiredExcpetion` correctly.
> 2. fix these commands, catch `AuthenticationExpiredException` specifically 
> and do a `writeException` (leave all other exception handling intact)
> 3. write tests to make sure we are sending the exception to the client.
> #1 would help us determine how many commands are in need of this fix and size 
> this story correctly.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-9900) Make sure all commands are sending back AuthenticationExpiredException as is

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-9900:
--
Labels: ne  (was: )

> Make sure all commands are sending back AuthenticationExpiredException as is
> 
>
> Key: GEODE-9900
> URL: https://issues.apache.org/jira/browse/GEODE-9900
> Project: Geode
>  Issue Type: Bug
>  Components: client/server
>Reporter: Jinmei Liao
>Priority: Major
>  Labels: ne
>
> As we have discovered in GEODE-9820, some commands (especially CQ commands) 
> are not sending back `AuthenticationExpiredException` to the client with 
> MessageType.EXCEPTION, hence causing the client not wrapping it in the 
> correct form (See `AbstractOp around L300), We need to:
> 1. go over all the commands and find out what commands are NOT handling the 
> `AuthenticationExpiredExcpetion` correctly.
> 2. fix these commands, catch `AuthenticationExpiredException` specifically 
> and do a `writeException` (leave all other exception handling intact)
> 3. write tests to make sure we are sending the exception to the client.
> #1 would help us determine how many commands are in need of this fix and size 
> this story correctly.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-9811) When a node is stopped using nice_exit or its cache is closing, client may fail due to UnavailableSecurityManagerException

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-9811:
--
Component/s: security

> When a node is stopped using nice_exit or its cache is closing, client may 
> fail due to UnavailableSecurityManagerException
> --
>
> Key: GEODE-9811
> URL: https://issues.apache.org/jira/browse/GEODE-9811
> Project: Geode
>  Issue Type: Bug
>  Components: core, security
>Affects Versions: 1.14.0
>Reporter: Joris Melchior
>Assignee: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI, pull-request-available
>
> Due to the sequence of events occurring when a server is shutting down it's 
> possible for some transactions to not be able to get the security manager 
> while performing an operation.
> Currently the operation fails without retry while the correct behaviour would 
> be to try and retry the operation at least once on another member.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-9811) When a node is stopped using nice_exit or its cache is closing, client may fail due to UnavailableSecurityManagerException

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-9811:
--
Labels: GeodeOperationAPI  (was: )

> When a node is stopped using nice_exit or its cache is closing, client may 
> fail due to UnavailableSecurityManagerException
> --
>
> Key: GEODE-9811
> URL: https://issues.apache.org/jira/browse/GEODE-9811
> Project: Geode
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.14.0
>Reporter: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI
>
> Due to the sequence of events occurring when a server is shutting down it's 
> possible for some transactions to not be able to get the security manager 
> while performing an operation.
> Currently the operation fails without retry while the correct behaviour would 
> be to try and retry the operation at least once on another member.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Assigned] (GEODE-9811) When a node is stopped using nice_exit or its cache is closing, client may fail due to UnavailableSecurityManagerException

[Joris Melchior (Jira)]

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

Joris Melchior reassigned GEODE-9811:
-

Assignee: Joris Melchior

> When a node is stopped using nice_exit or its cache is closing, client may 
> fail due to UnavailableSecurityManagerException
> --
>
> Key: GEODE-9811
> URL: https://issues.apache.org/jira/browse/GEODE-9811
> Project: Geode
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.14.0
>Reporter: Joris Melchior
>Assignee: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI
>
> Due to the sequence of events occurring when a server is shutting down it's 
> possible for some transactions to not be able to get the security manager 
> while performing an operation.
> Currently the operation fails without retry while the correct behaviour would 
> be to try and retry the operation at least once on another member.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Updated] (GEODE-9811) When a node is stopped using nice_exit or its cache is closing, client may fail due to UnavailableSecurityManagerException

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-9811:
--
Labels:   (was: needsTriage)

> When a node is stopped using nice_exit or its cache is closing, client may 
> fail due to UnavailableSecurityManagerException
> --
>
> Key: GEODE-9811
> URL: https://issues.apache.org/jira/browse/GEODE-9811
> Project: Geode
>  Issue Type: Bug
>  Components: core
>Affects Versions: 1.14.0
>Reporter: Joris Melchior
>Priority: Major
>
> Due to the sequence of events occurring when a server is shutting down it's 
> possible for some transactions to not be able to get the security manager 
> while performing an operation.
> Currently the operation fails without retry while the correct behaviour would 
> be to try and retry the operation at least once on another member.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Created] (GEODE-9811) When a node is stopped using nice_exit or its cache is closing, client may fail due to UnavailableSecurityManagerException

[Joris Melchior (Jira)]

Joris Melchior created GEODE-9811:
-

 Summary: When a node is stopped using nice_exit or its cache is 
closing, client may fail due to UnavailableSecurityManagerException
 Key: GEODE-9811
 URL: https://issues.apache.org/jira/browse/GEODE-9811
 Project: Geode
  Issue Type: Bug
  Components: core
Affects Versions: 1.14.0
Reporter: Joris Melchior


Due to the sequence of events occurring when a server is shutting down it's 
possible for some transactions to not be able to get the security manager while 
performing an operation.

Currently the operation fails without retry while the correct behaviour would 
be to try and retry the operation at least once on another member.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

[jira] [Resolved] (GEODE-7898) error happen when start the second server before restarting the first server, in case of REPLICATE_PERSISTENT data region

[Joris Melchior (Jira)]

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

Joris Melchior resolved GEODE-7898.
---
Resolution: Not A Problem

> error happen when start the second server before restarting the first server, 
> in case of REPLICATE_PERSISTENT data region
> -
>
> Key: GEODE-7898
> URL: https://issues.apache.org/jira/browse/GEODE-7898
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 1.15.0
>Reporter: Guoxiang Zu
>Assignee: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI, needsTriage
>
> Just one step different(the server2 is started before the restarting of 
> server1) with the quick start tutorial 
> [https://geode.apache.org/docs/guide/11/getting_started/15_minute_quickstart_gfsh.html]
> the steps are as following:
> "
> gfsh
> start locator --name=locator1
> start server --name=server1 --server-port=40411
> create region --name=regionA --type=REPLICATE_PERSISTENT
> put --region=regionA --key="1" --value="one"
> stop server --name=server1
> start server --name=server2 --server-port=40412
> start server --name=server1 --server-port=40411
> "
> Got the following error:
> "
> tarting a Geode Server in /home/ezuxguo/install_geode/my_geode/server1...
> The Cache Server process terminated unexpectedly with exit status 1. Please 
> refer to the log file in /home/ezuxguo/install_geode/my_geode/server1 for 
> full details.
> Exception in thread "main" 
> org.apache.geode.cache.persistence.ConflictingPersistentDataException: Region 
> /regionB remote member 192.168.240.1(server2:29316):41001 with persistent 
> data /192.168.240.1:/home/ezuxguo/install_geode/my_geode/server2/. created at 
> timestamp 1584793471853 version 0 diskStoreId 
> 609fc92b54d54334-ae4afa44b63cd641 name server2 was not part of the same 
> distributed system as the local data from 
> /192.168.240.1:/home/ezuxguo/install_geode/my_geode/server1/. created at 
> timestamp 1584792633397 version 0 diskStoreId 
> f1a472367a3141b9-b2c1f9287f14981d name server1
> at 
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.checkMyStateOnMembers(PersistenceAdvisorImpl.java:526)
> at 
> org.apache.geode.internal.cache.persistence.PersistenceInitialImageAdvisor.removeReplicatesIfWeAreEqualToAnyOrElseClearEqualMembers(PersistenceInitialImageAdvisor.java:179)
> at 
> org.apache.geode.internal.cache.persistence.PersistenceInitialImageAdvisor.getAdvice(PersistenceInitialImageAdvisor.java:67)
> at 
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.getInitialImageAdvice(PersistenceAdvisorImpl.java:833)
> at 
> org.apache.geode.internal.cache.persistence.CreatePersistentRegionProcessor.getInitialImageAdvice(CreatePersistentRegionProcessor.java:52)
> at 
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1195)
> at 
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1080)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3040)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:2928)
> at 
> org.apache.geode.internal.cache.xmlcache.RegionCreation.createRoot(RegionCreation.java:237)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheCreation.initializeRegions(CacheCreation.java:634)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:580)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:338)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4296)
> at 
> org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:200)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1256)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1224)
> at 
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> at 
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at 
> org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
> at 
> org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:894)
> at org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:809)
> at org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:739)
> at 

[jira] [Commented] (GEODE-7898) error happen when start the second server before restarting the first server, in case of REPLICATE_PERSISTENT data region

[Joris Melchior (Jira)]

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

Joris Melchior commented on GEODE-7898:
---

Investigation shows that the behaviour shown in the description of the ticket 
is expected. The system has a distributed test that confirms this behaviour. 
`{color:#00}PersistentRecoveryOrderDUnitTest.{color}{color:#00627a}testRecoverAfterConflict(){color}`
 simulates this with the same expected outcome.

Given that this behaviour is expected and documented in test we should close 
this ticket.

> error happen when start the second server before restarting the first server, 
> in case of REPLICATE_PERSISTENT data region
> -
>
> Key: GEODE-7898
> URL: https://issues.apache.org/jira/browse/GEODE-7898
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 1.15.0
>Reporter: Guoxiang Zu
>Assignee: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI, needsTriage
>
> Just one step different(the server2 is started before the restarting of 
> server1) with the quick start tutorial 
> [https://geode.apache.org/docs/guide/11/getting_started/15_minute_quickstart_gfsh.html]
> the steps are as following:
> "
> gfsh
> start locator --name=locator1
> start server --name=server1 --server-port=40411
> create region --name=regionA --type=REPLICATE_PERSISTENT
> put --region=regionA --key="1" --value="one"
> stop server --name=server1
> start server --name=server2 --server-port=40412
> start server --name=server1 --server-port=40411
> "
> Got the following error:
> "
> tarting a Geode Server in /home/ezuxguo/install_geode/my_geode/server1...
> The Cache Server process terminated unexpectedly with exit status 1. Please 
> refer to the log file in /home/ezuxguo/install_geode/my_geode/server1 for 
> full details.
> Exception in thread "main" 
> org.apache.geode.cache.persistence.ConflictingPersistentDataException: Region 
> /regionB remote member 192.168.240.1(server2:29316):41001 with persistent 
> data /192.168.240.1:/home/ezuxguo/install_geode/my_geode/server2/. created at 
> timestamp 1584793471853 version 0 diskStoreId 
> 609fc92b54d54334-ae4afa44b63cd641 name server2 was not part of the same 
> distributed system as the local data from 
> /192.168.240.1:/home/ezuxguo/install_geode/my_geode/server1/. created at 
> timestamp 1584792633397 version 0 diskStoreId 
> f1a472367a3141b9-b2c1f9287f14981d name server1
> at 
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.checkMyStateOnMembers(PersistenceAdvisorImpl.java:526)
> at 
> org.apache.geode.internal.cache.persistence.PersistenceInitialImageAdvisor.removeReplicatesIfWeAreEqualToAnyOrElseClearEqualMembers(PersistenceInitialImageAdvisor.java:179)
> at 
> org.apache.geode.internal.cache.persistence.PersistenceInitialImageAdvisor.getAdvice(PersistenceInitialImageAdvisor.java:67)
> at 
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.getInitialImageAdvice(PersistenceAdvisorImpl.java:833)
> at 
> org.apache.geode.internal.cache.persistence.CreatePersistentRegionProcessor.getInitialImageAdvice(CreatePersistentRegionProcessor.java:52)
> at 
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1195)
> at 
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1080)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3040)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:2928)
> at 
> org.apache.geode.internal.cache.xmlcache.RegionCreation.createRoot(RegionCreation.java:237)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheCreation.initializeRegions(CacheCreation.java:634)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:580)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:338)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4296)
> at 
> org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:200)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1256)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1224)
> at 
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> at 
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at 
> 

[jira] [Assigned] (GEODE-9770) CI Failure: ConflictingPersistentDataException in PersistentRecoveryOrderDUnitTest > testRecoverAfterConflict

[Joris Melchior (Jira)]

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

Joris Melchior reassigned GEODE-9770:
-

Assignee: Joris Melchior

> CI Failure: ConflictingPersistentDataException in 
> PersistentRecoveryOrderDUnitTest > testRecoverAfterConflict
> -
>
> Key: GEODE-9770
> URL: https://issues.apache.org/jira/browse/GEODE-9770
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 1.15.0
>Reporter: Nabarun Nag
>Assignee: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI, needsTriage
>
> This ConflictingPersistentDataException has popped up multiple number of 
> times.
> GEODE-6975
> GEODE-7898
>  
> {noformat}
> PersistentRecoveryOrderDUnitTest > testRecoverAfterConflict FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest$$Lambda$477/1255368072.run
>  in VM 0 running on Host 
> heavy-lifter-7860ae84-3be2-5775-9a40-47a7abc4e64d.c.apachegeode-ci.internal 
> with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:631)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:448)
> at 
> org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest.testRecoverAfterConflict(PersistentRecoveryOrderDUnitTest.java:1328)
> Caused by:
> org.apache.geode.cache.CacheClosedException: Region 
> /PersistentRecoveryOrderDUnitTest_testRecoverAfterConflictRegion remote 
> member heavy-lifter-7860ae84-3be2-5775-9a40-47a7abc4e64d(585689):51002 
> with persistent data 
> /10.0.0.50:/tmp/junit4736556655757609006/rootDir-testRecoverAfterConflict/vm-1
>  created at timestamp 1635009815552 version 0 diskStoreId 
> bf4774f44f2e4dcd-aa6c79424132a2e4 name  was not part of the same distributed 
> system as the local data from 
> /10.0.0.50:/tmp/junit4736556655757609006/rootDir-testRecoverAfterConflict/vm-0
>  created at timestamp 1635009814986 version 0 diskStoreId 
> cc4c64d81e9d4119-9e7320b29f540199 name , caused by 
> org.apache.geode.cache.persistence.ConflictingPersistentDataException: Region 
> /PersistentRecoveryOrderDUnitTest_testRecoverAfterConflictRegion remote 
> member heavy-lifter-7860ae84-3be2-5775-9a40-47a7abc4e64d(585689):51002 
> with persistent data 
> /10.0.0.50:/tmp/junit4736556655757609006/rootDir-testRecoverAfterConflict/vm-1
>  created at timestamp 1635009815552 version 0 diskStoreId 
> bf4774f44f2e4dcd-aa6c79424132a2e4 name  was not part of the same distributed 
> system as the local data from 
> /10.0.0.50:/tmp/junit4736556655757609006/rootDir-testRecoverAfterConflict/vm-0
>  created at timestamp 1635009814986 version 0 diskStoreId 
> cc4c64d81e9d4119-9e7320b29f540199 name 
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl$Stopper.generateCancelledException(GemFireCacheImpl.java:5223)
> at 
> org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.getInternalResourceManager(GemFireCacheImpl.java:4259)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.getInternalResourceManager(GemFireCacheImpl.java:4253)
> at 
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1175)
> at 
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1095)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3108)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:3002)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createRegion(GemFireCacheImpl.java:2986)
> at 
> org.apache.geode.cache.RegionFactory.create(RegionFactory.java:773)
> at 
> org.apache.geode.internal.cache.InternalRegionFactory.create(InternalRegionFactory.java:75)
> at 
> org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest.createReplicateRegion(PersistentRecoveryOrderDUnitTest.java:1358)
> at 
> org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest.createReplicateRegion(PersistentRecoveryOrderDUnitTest.java:1362)
> at 
> org.apache.geode.internal.cache.persistence.PersistentRecoveryOrderDUnitTest.lambda$testRecoverAfterConflict$bb17a952$5(PersistentRecoveryOrderDUnitTest.java:1330)
> Caused by:
> 
> org.apache.geode.cache.persistence.ConflictingPersistentDataException: Region 
> /PersistentRecoveryOrderDUnitTest_testRecoverAfterConflictRegion 

[jira] [Commented] (GEODE-7898) error happen when start the second server before restarting the first server, in case of REPLICATE_PERSISTENT data region

[Joris Melchior (Jira)]

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

Joris Melchior commented on GEODE-7898:
---

Replicated in version 1.15.0 (current development) but given the age of the 
ticket happened in earlier version(s) too.

> error happen when start the second server before restarting the first server, 
> in case of REPLICATE_PERSISTENT data region
> -
>
> Key: GEODE-7898
> URL: https://issues.apache.org/jira/browse/GEODE-7898
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 1.15.0
>Reporter: Guoxiang Zu
>Assignee: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI, needsTriage
>
> Just one step different(the server2 is started before the restarting of 
> server1) with the quick start tutorial 
> [https://geode.apache.org/docs/guide/11/getting_started/15_minute_quickstart_gfsh.html]
> the steps are as following:
> "
> gfsh
> start locator --name=locator1
> start server --name=server1 --server-port=40411
> create region --name=regionA --type=REPLICATE_PERSISTENT
> put --region=regionA --key="1" --value="one"
> stop server --name=server1
> start server --name=server2 --server-port=40412
> start server --name=server1 --server-port=40411
> "
> Got the following error:
> "
> tarting a Geode Server in /home/ezuxguo/install_geode/my_geode/server1...
> The Cache Server process terminated unexpectedly with exit status 1. Please 
> refer to the log file in /home/ezuxguo/install_geode/my_geode/server1 for 
> full details.
> Exception in thread "main" 
> org.apache.geode.cache.persistence.ConflictingPersistentDataException: Region 
> /regionB remote member 192.168.240.1(server2:29316):41001 with persistent 
> data /192.168.240.1:/home/ezuxguo/install_geode/my_geode/server2/. created at 
> timestamp 1584793471853 version 0 diskStoreId 
> 609fc92b54d54334-ae4afa44b63cd641 name server2 was not part of the same 
> distributed system as the local data from 
> /192.168.240.1:/home/ezuxguo/install_geode/my_geode/server1/. created at 
> timestamp 1584792633397 version 0 diskStoreId 
> f1a472367a3141b9-b2c1f9287f14981d name server1
> at 
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.checkMyStateOnMembers(PersistenceAdvisorImpl.java:526)
> at 
> org.apache.geode.internal.cache.persistence.PersistenceInitialImageAdvisor.removeReplicatesIfWeAreEqualToAnyOrElseClearEqualMembers(PersistenceInitialImageAdvisor.java:179)
> at 
> org.apache.geode.internal.cache.persistence.PersistenceInitialImageAdvisor.getAdvice(PersistenceInitialImageAdvisor.java:67)
> at 
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.getInitialImageAdvice(PersistenceAdvisorImpl.java:833)
> at 
> org.apache.geode.internal.cache.persistence.CreatePersistentRegionProcessor.getInitialImageAdvice(CreatePersistentRegionProcessor.java:52)
> at 
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1195)
> at 
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1080)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3040)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:2928)
> at 
> org.apache.geode.internal.cache.xmlcache.RegionCreation.createRoot(RegionCreation.java:237)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheCreation.initializeRegions(CacheCreation.java:634)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:580)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:338)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4296)
> at 
> org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:200)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1256)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1224)
> at 
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> at 
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at 
> org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
> at 
> org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:894)
> at 

[jira] [Updated] (GEODE-7898) error happen when start the second server before restarting the first server, in case of REPLICATE_PERSISTENT data region

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-7898:
--
  Component/s: persistence
Affects Version/s: 1.15.0
   Labels: GeodeOperationAPI needsTriage  (was: )

> error happen when start the second server before restarting the first server, 
> in case of REPLICATE_PERSISTENT data region
> -
>
> Key: GEODE-7898
> URL: https://issues.apache.org/jira/browse/GEODE-7898
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 1.15.0
>Reporter: Guoxiang Zu
>Priority: Major
>  Labels: GeodeOperationAPI, needsTriage
>
> Just one step different(the server2 is started before the restarting of 
> server1) with the quick start tutorial 
> [https://geode.apache.org/docs/guide/11/getting_started/15_minute_quickstart_gfsh.html]
> the steps are as following:
> "
> gfsh
> start locator --name=locator1
> start server --name=server1 --server-port=40411
> create region --name=regionA --type=REPLICATE_PERSISTENT
> put --region=regionA --key="1" --value="one"
> stop server --name=server1
> start server --name=server2 --server-port=40412
> start server --name=server1 --server-port=40411
> "
> Got the following error:
> "
> tarting a Geode Server in /home/ezuxguo/install_geode/my_geode/server1...
> The Cache Server process terminated unexpectedly with exit status 1. Please 
> refer to the log file in /home/ezuxguo/install_geode/my_geode/server1 for 
> full details.
> Exception in thread "main" 
> org.apache.geode.cache.persistence.ConflictingPersistentDataException: Region 
> /regionB remote member 192.168.240.1(server2:29316):41001 with persistent 
> data /192.168.240.1:/home/ezuxguo/install_geode/my_geode/server2/. created at 
> timestamp 1584793471853 version 0 diskStoreId 
> 609fc92b54d54334-ae4afa44b63cd641 name server2 was not part of the same 
> distributed system as the local data from 
> /192.168.240.1:/home/ezuxguo/install_geode/my_geode/server1/. created at 
> timestamp 1584792633397 version 0 diskStoreId 
> f1a472367a3141b9-b2c1f9287f14981d name server1
> at 
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.checkMyStateOnMembers(PersistenceAdvisorImpl.java:526)
> at 
> org.apache.geode.internal.cache.persistence.PersistenceInitialImageAdvisor.removeReplicatesIfWeAreEqualToAnyOrElseClearEqualMembers(PersistenceInitialImageAdvisor.java:179)
> at 
> org.apache.geode.internal.cache.persistence.PersistenceInitialImageAdvisor.getAdvice(PersistenceInitialImageAdvisor.java:67)
> at 
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.getInitialImageAdvice(PersistenceAdvisorImpl.java:833)
> at 
> org.apache.geode.internal.cache.persistence.CreatePersistentRegionProcessor.getInitialImageAdvice(CreatePersistentRegionProcessor.java:52)
> at 
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1195)
> at 
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1080)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3040)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:2928)
> at 
> org.apache.geode.internal.cache.xmlcache.RegionCreation.createRoot(RegionCreation.java:237)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheCreation.initializeRegions(CacheCreation.java:634)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:580)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:338)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4296)
> at 
> org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:200)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1256)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1224)
> at 
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> at 
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at 
> org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
> at 
> org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:894)
> at org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:809)
> at 

[jira] [Assigned] (GEODE-7898) error happen when start the second server before restarting the first server, in case of REPLICATE_PERSISTENT data region

[Joris Melchior (Jira)]

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

Joris Melchior reassigned GEODE-7898:
-

Assignee: Joris Melchior

> error happen when start the second server before restarting the first server, 
> in case of REPLICATE_PERSISTENT data region
> -
>
> Key: GEODE-7898
> URL: https://issues.apache.org/jira/browse/GEODE-7898
> Project: Geode
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 1.15.0
>Reporter: Guoxiang Zu
>Assignee: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI, needsTriage
>
> Just one step different(the server2 is started before the restarting of 
> server1) with the quick start tutorial 
> [https://geode.apache.org/docs/guide/11/getting_started/15_minute_quickstart_gfsh.html]
> the steps are as following:
> "
> gfsh
> start locator --name=locator1
> start server --name=server1 --server-port=40411
> create region --name=regionA --type=REPLICATE_PERSISTENT
> put --region=regionA --key="1" --value="one"
> stop server --name=server1
> start server --name=server2 --server-port=40412
> start server --name=server1 --server-port=40411
> "
> Got the following error:
> "
> tarting a Geode Server in /home/ezuxguo/install_geode/my_geode/server1...
> The Cache Server process terminated unexpectedly with exit status 1. Please 
> refer to the log file in /home/ezuxguo/install_geode/my_geode/server1 for 
> full details.
> Exception in thread "main" 
> org.apache.geode.cache.persistence.ConflictingPersistentDataException: Region 
> /regionB remote member 192.168.240.1(server2:29316):41001 with persistent 
> data /192.168.240.1:/home/ezuxguo/install_geode/my_geode/server2/. created at 
> timestamp 1584793471853 version 0 diskStoreId 
> 609fc92b54d54334-ae4afa44b63cd641 name server2 was not part of the same 
> distributed system as the local data from 
> /192.168.240.1:/home/ezuxguo/install_geode/my_geode/server1/. created at 
> timestamp 1584792633397 version 0 diskStoreId 
> f1a472367a3141b9-b2c1f9287f14981d name server1
> at 
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.checkMyStateOnMembers(PersistenceAdvisorImpl.java:526)
> at 
> org.apache.geode.internal.cache.persistence.PersistenceInitialImageAdvisor.removeReplicatesIfWeAreEqualToAnyOrElseClearEqualMembers(PersistenceInitialImageAdvisor.java:179)
> at 
> org.apache.geode.internal.cache.persistence.PersistenceInitialImageAdvisor.getAdvice(PersistenceInitialImageAdvisor.java:67)
> at 
> org.apache.geode.internal.cache.persistence.PersistenceAdvisorImpl.getInitialImageAdvice(PersistenceAdvisorImpl.java:833)
> at 
> org.apache.geode.internal.cache.persistence.CreatePersistentRegionProcessor.getInitialImageAdvice(CreatePersistentRegionProcessor.java:52)
> at 
> org.apache.geode.internal.cache.DistributedRegion.getInitialImageAndRecovery(DistributedRegion.java:1195)
> at 
> org.apache.geode.internal.cache.DistributedRegion.initialize(DistributedRegion.java:1080)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.createVMRegion(GemFireCacheImpl.java:3040)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.basicCreateRegion(GemFireCacheImpl.java:2928)
> at 
> org.apache.geode.internal.cache.xmlcache.RegionCreation.createRoot(RegionCreation.java:237)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheCreation.initializeRegions(CacheCreation.java:634)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheCreation.create(CacheCreation.java:580)
> at 
> org.apache.geode.internal.cache.xmlcache.CacheXmlParser.create(CacheXmlParser.java:338)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.loadCacheXml(GemFireCacheImpl.java:4296)
> at 
> org.apache.geode.internal.cache.ClusterConfigurationLoader.applyClusterXmlConfiguration(ClusterConfigurationLoader.java:200)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.applyJarAndXmlFromClusterConfig(GemFireCacheImpl.java:1256)
> at 
> org.apache.geode.internal.cache.GemFireCacheImpl.initialize(GemFireCacheImpl.java:1224)
> at 
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:191)
> at 
> org.apache.geode.internal.cache.InternalCacheBuilder.create(InternalCacheBuilder.java:158)
> at org.apache.geode.cache.CacheFactory.create(CacheFactory.java:142)
> at 
> org.apache.geode.distributed.internal.DefaultServerLauncherCacheProvider.createCache(DefaultServerLauncherCacheProvider.java:52)
> at 
> org.apache.geode.distributed.ServerLauncher.createCache(ServerLauncher.java:894)
> at org.apache.geode.distributed.ServerLauncher.start(ServerLauncher.java:809)
> at org.apache.geode.distributed.ServerLauncher.run(ServerLauncher.java:739)
> at 

[jira] [Resolved] (GEODE-9723) Add test to cover transaction based operations when re-authentication happens.

[Joris Melchior (Jira)]

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

Joris Melchior resolved GEODE-9723.
---
Fix Version/s: 1.15.0
   Resolution: Fixed

> Add test to cover transaction based operations when re-authentication happens.
> --
>
> Key: GEODE-9723
> URL: https://issues.apache.org/jira/browse/GEODE-9723
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Jinmei Liao
>Assignee: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI, pull-request-available
> Fix For: 1.15.0
>
>
> add test scenario for when a transaction has multiple operations, what would 
> happen when auth expired in the middle of a transaction. Would the 
> transaction continue if re-auth succeeds? Would the resources be cleared up 
> with re-auth failed? 



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

[jira] [Assigned] (GEODE-9723) Add test to cover transaction based operations when re-authentication happens.

[Joris Melchior (Jira)]

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

Joris Melchior reassigned GEODE-9723:
-

Assignee: Joris Melchior

> Add test to cover transaction based operations when re-authentication happens.
> --
>
> Key: GEODE-9723
> URL: https://issues.apache.org/jira/browse/GEODE-9723
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Jinmei Liao
>Assignee: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI
>
> add test scenario for when a transaction has multiple operations, what would 
> happen when auth expired in the middle of a transaction. Would the 
> transaction continue if re-auth succeeds? Would the resources be cleared up 
> with re-auth failed? 



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

[jira] [Updated] (GEODE-9460) add tests for multi-user mode when one user expires

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-9460:
--
Description: 
Current state:

Currently an established client connection does not time out

New state:

Client connections can be subject to time out depending on the security manager 
implementation and client code should be able to handle re-authentication of 
client connections.

Things to test:
 * Test multi-user connections and ensure that when one specific user times out 
this user is forced to re-authenticate
 * Confirm re-authentication on both new version and versions of the client in 
pre 1.13.3 releases
 * Confirm the behaviour in single and multi-server environments

 

  was:
make sure the behavior matches expectations

 

make sure to include tests in multi-server cases


> add tests for multi-user mode when one user expires
> ---
>
> Key: GEODE-9460
> URL: https://issues.apache.org/jira/browse/GEODE-9460
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Jinmei Liao
>Assignee: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI, pull-request-available
>
> Current state:
> Currently an established client connection does not time out
> New state:
> Client connections can be subject to time out depending on the security 
> manager implementation and client code should be able to handle 
> re-authentication of client connections.
> Things to test:
>  * Test multi-user connections and ensure that when one specific user times 
> out this user is forced to re-authenticate
>  * Confirm re-authentication on both new version and versions of the client 
> in pre 1.13.3 releases
>  * Confirm the behaviour in single and multi-server environments
>  



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

[jira] [Assigned] (GEODE-9460) add tests for multi-user mode when one user expires

[Joris Melchior (Jira)]

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

Joris Melchior reassigned GEODE-9460:
-

Assignee: Joris Melchior

> add tests for multi-user mode when one user expires
> ---
>
> Key: GEODE-9460
> URL: https://issues.apache.org/jira/browse/GEODE-9460
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Jinmei Liao
>Assignee: Joris Melchior
>Priority: Major
>  Labels: GeodeOperationAPI, pull-request-available
>
> make sure the behavior matches expectations
>  
> make sure to include tests in multi-server cases



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

[jira] [Commented] (GEODE-9459) add tests for wan connection when authentication expires

[Joris Melchior (Jira)]

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

Joris Melchior commented on GEODE-9459:
---

Do we allow WAN connections of clusters with different versions? Do we handle 
upgrades of clusters on the fly?

> add tests for wan connection when authentication expires
> 
>
> Key: GEODE-9459
> URL: https://issues.apache.org/jira/browse/GEODE-9459
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Jinmei Liao
>Priority: Major
>  Labels: GeodeOperationAPI
>
> Current state:
> WAN connections do not time out and once established remain in place once 
> authenticated
> New state:
> WAN connections may be subject to timeout and when a WAN connection times out 
> it will receive a `AuthenticationExpiredException` exception in response to 
> an attempt to send a batch of events from a Gateway sender to a Gateway 
> receiver.
> Testing tasks:
>  * Confirm the new state behaviour on both newer systems and systems of 
> version 1.13.3 and older.
>  * On newer systems the Gateway sender should automatically re-authenticate 
> when getting the `AuthenticationExpiredException`
>  * On older systems the Gateway sender should receive an 
> `AuthenticationRequiredException` as the `server` side recognizes an older 
> `client` and translates the `AuthenticationExpiredException`. The Gateway 
> sender should automatically authenticate in this case too.



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

[jira] [Updated] (GEODE-9459) add tests for wan connection when authentication expires

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-9459:
--
Description: 
Current state:

WAN connections do not time out and once established remain in place once 
authenticated

New state:

WAN connections may be subject to timeout and when a WAN connection times out 
it will receive a `AuthenticationExpiredException` exception in response to an 
attempt to send a batch of events from a Gateway sender to a Gateway receiver.

Testing tasks:
 * Confirm the new state behaviour on both newer systems and systems of version 
1.13.3 and older.
 * On newer systems the Gateway sender should automatically re-authenticate 
when getting the `AuthenticationExpiredException`
 * On older systems the Gateway sender should receive an 
`AuthenticationRequiredException` as the `server` side recognizes an older 
`client` and translates the `AuthenticationExpiredException`. The Gateway 
sender should automatically authenticate in this case too.

  was:make sure the behavior matches expections.


> add tests for wan connection when authentication expires
> 
>
> Key: GEODE-9459
> URL: https://issues.apache.org/jira/browse/GEODE-9459
> Project: Geode
>  Issue Type: Sub-task
>Reporter: Jinmei Liao
>Priority: Major
>  Labels: GeodeOperationAPI
>
> Current state:
> WAN connections do not time out and once established remain in place once 
> authenticated
> New state:
> WAN connections may be subject to timeout and when a WAN connection times out 
> it will receive a `AuthenticationExpiredException` exception in response to 
> an attempt to send a batch of events from a Gateway sender to a Gateway 
> receiver.
> Testing tasks:
>  * Confirm the new state behaviour on both newer systems and systems of 
> version 1.13.3 and older.
>  * On newer systems the Gateway sender should automatically re-authenticate 
> when getting the `AuthenticationExpiredException`
>  * On older systems the Gateway sender should receive an 
> `AuthenticationRequiredException` as the `server` side recognizes an older 
> `client` and translates the `AuthenticationExpiredException`. The Gateway 
> sender should automatically authenticate in this case too.



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

[jira] [Updated] (GEODE-9453) The server, once a user expires, should clean the user attributes from the server.

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-9453:
--
Labels: GeodeOperationAPI  (was: )

> The server, once a user expires, should clean the user attributes from the 
> server.
> --
>
> Key: GEODE-9453
> URL: https://issues.apache.org/jira/browse/GEODE-9453
> Project: Geode
>  Issue Type: Sub-task
>  Components: core, security
>Reporter: Jinmei Liao
>Priority: Major
>  Labels: GeodeOperationAPI
>
> ClientUserAuths maintains a map of clientID to its user attributes (the 
> logged in shiro subject etc), when user expires, we need to remove that entry 
> from that map and log the shiro subject out to avoid resource leak.



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

[jira] [Updated] (GEODE-9454) The client, if multiple operations are in flight, should not flood the authentication server with re-authentication requests.

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-9454:
--
Labels: GeodeOperationAPI  (was: )

> The client, if multiple operations are in flight, should not flood the 
> authentication server with re-authentication requests.
> -
>
> Key: GEODE-9454
> URL: https://issues.apache.org/jira/browse/GEODE-9454
> Project: Geode
>  Issue Type: Sub-task
>  Components: core, security
>Reporter: Jinmei Liao
>Priority: Major
>  Labels: GeodeOperationAPI
>
> the blocking should only be for one client only
> Having a test with multiple clients with multiple thread doing cache 
> operations
> The test should also cover the multi-user authentication mode



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

[jira] [Updated] (GEODE-9452) The older version client should receive the AuthenticationRequiredException when authentication expires

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-9452:
--
Labels: GeodeOperationAPI  (was: )

> The older version client should receive the AuthenticationRequiredException 
> when authentication expires
> ---
>
> Key: GEODE-9452
> URL: https://issues.apache.org/jira/browse/GEODE-9452
> Project: Geode
>  Issue Type: Sub-task
>  Components: core, security
>Reporter: Jinmei Liao
>Priority: Major
>  Labels: GeodeOperationAPI
>
> Currently, for older client, it's receiving a ClassNotFoundException, we need 
> to add the serialization code to convert the AuthenticationExpiredException 
> into this old exception type that the older clients can understand.
>  
> Note: when converting the exception, if we have the message to match what the 
> older client expects, it can do re-authentication automatically, but we lost 
> the original message that server has thrown. (Need to consult the PM on what 
> kind of behavior they want).



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

[jira] [Closed] (GEODE-8283) REST API for creating diskstores

[Joris Melchior (Jira)]

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

Joris Melchior closed GEODE-8283.
-

PR merged into develop

> REST API for creating diskstores
> 
>
> Key: GEODE-8283
> URL: https://issues.apache.org/jira/browse/GEODE-8283
> Project: Geode
>  Issue Type: New Feature
>  Components: rest (admin)
>Reporter: Jason Huynh
>Assignee: Joris Melchior
>Priority: Major
> Fix For: 1.14.0
>
>
> This is a feature to add a REST API to allow someone to create a diskstore.  
> This may include creating a diskstore, deleting a disk store, listing a 
> diskstore and possibly revoking a diskstore.



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

[jira] [Resolved] (GEODE-8283) REST API for creating diskstores

[Joris Melchior (Jira)]

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

Joris Melchior resolved GEODE-8283.
---
Fix Version/s: 1.14.0
   Resolution: Delivered

Pull request merged into develop.

> REST API for creating diskstores
> 
>
> Key: GEODE-8283
> URL: https://issues.apache.org/jira/browse/GEODE-8283
> Project: Geode
>  Issue Type: New Feature
>  Components: rest (admin)
>Reporter: Jason Huynh
>Assignee: Joris Melchior
>Priority: Major
> Fix For: 1.14.0
>
>
> This is a feature to add a REST API to allow someone to create a diskstore.  
> This may include creating a diskstore, deleting a disk store, listing a 
> diskstore and possibly revoking a diskstore.



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

[jira] [Resolved] (GEODE-8027) Provide raw swagger JSON for managment API

[Joris Melchior (Jira)]

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

Joris Melchior resolved GEODE-8027.
---
Resolution: Fixed

> Provide raw swagger JSON for managment API
> --
>
> Key: GEODE-8027
> URL: https://issues.apache.org/jira/browse/GEODE-8027
> Project: Geode
>  Issue Type: Task
>  Components: management
>Reporter: Joris Melchior
>Assignee: Joris Melchior
>Priority: Major
> Fix For: 1.13.0
>
>
> For our management API we have a wiki page with Swagger HTML documentation 
> for each version of our API.
> They can be found here:
> https://cwiki.apache.org/confluence/display/GEODE/1.10.0+Management+REST+API+-+v1
> https://cwiki.apache.org/confluence/display/GEODE/1.11.0+Management+REST+API+-+v1
> https://cwiki.apache.org/confluence/display/GEODE/1.12.0+Management+REST+API+-+v1
> https://cwiki.apache.org/confluence/display/GEODE/1.13.0+Management+REST+API+-+v1
> For consumers of the API the pages should provide an attachment with raw 
> Swagger JSON that can be consumed by code generators.



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

[jira] [Assigned] (GEODE-8027) Provide raw swagger JSON for managment API

[Joris Melchior (Jira)]

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

Joris Melchior reassigned GEODE-8027:
-

Assignee: Joris Melchior

> Provide raw swagger JSON for managment API
> --
>
> Key: GEODE-8027
> URL: https://issues.apache.org/jira/browse/GEODE-8027
> Project: Geode
>  Issue Type: Task
>  Components: management
>Reporter: Joris Melchior
>Assignee: Joris Melchior
>Priority: Major
> Fix For: 1.13.0
>
>
> For our management API we have a wiki page with Swagger HTML documentation 
> for each version of our API.
> They can be found here:
> https://cwiki.apache.org/confluence/display/GEODE/1.10.0+Management+REST+API+-+v1
> https://cwiki.apache.org/confluence/display/GEODE/1.11.0+Management+REST+API+-+v1
> https://cwiki.apache.org/confluence/display/GEODE/1.12.0+Management+REST+API+-+v1
> https://cwiki.apache.org/confluence/display/GEODE/1.13.0+Management+REST+API+-+v1
> For consumers of the API the pages should provide an attachment with raw 
> Swagger JSON that can be consumed by code generators.



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

[jira] [Created] (GEODE-8027) Provide raw swagger JSON for managment API

[Joris Melchior (Jira)]

Joris Melchior created GEODE-8027:
-

 Summary: Provide raw swagger JSON for managment API
 Key: GEODE-8027
 URL: https://issues.apache.org/jira/browse/GEODE-8027
 Project: Geode
  Issue Type: Task
  Components: management
Reporter: Joris Melchior
 Fix For: 1.13.0


For our management API we have a wiki page with Swagger HTML documentation for 
each version of our API.
They can be found here:
https://cwiki.apache.org/confluence/display/GEODE/1.10.0+Management+REST+API+-+v1
https://cwiki.apache.org/confluence/display/GEODE/1.11.0+Management+REST+API+-+v1
https://cwiki.apache.org/confluence/display/GEODE/1.12.0+Management+REST+API+-+v1
https://cwiki.apache.org/confluence/display/GEODE/1.13.0+Management+REST+API+-+v1

For consumers of the API the pages should provide an attachment with raw 
Swagger JSON that can be consumed by code generators.




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

[jira] [Resolved] (GEODE-7974) CI Failure: RestAccessControllerTest > getSpecificKeysUsingQueryParamWithNonExistentKey

[Joris Melchior (Jira)]

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

Joris Melchior resolved GEODE-7974.
---
Fix Version/s: 1.13.0
   Resolution: Fixed

PR - https://github.com/apache/geode/pull/4952

> CI Failure: RestAccessControllerTest > 
> getSpecificKeysUsingQueryParamWithNonExistentKey
> ---
>
> Key: GEODE-7974
> URL: https://issues.apache.org/jira/browse/GEODE-7974
> Project: Geode
>  Issue Type: Bug
>  Components: rest (dev)
>Reporter: Ernest Burghardt
>Assignee: Joris Melchior
>Priority: Major
> Fix For: 1.13.0
>
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK11/builds/27]
>  
> {code:java}
> > Task :geode-web-api:integrationTest
> org.apache.geode.rest.internal.web.controllers.RestAccessControllerTest > 
> getSpecificKeysUsingQueryParamWithNonExistentKey FAILED
> java.lang.AssertionError: Response content expected:<{
>   "customers" : [ {
> "@type" : "org.apache.geode.rest.internal.web.controllers.Customer",
> "customerId" : 101,
> "firstName" : "Vishal",
> "lastName" : "Roa"
>   }, null ]
> }> but was:<{
>   "customers" : [ {
> "@type" : "org.apache.geode.rest.internal.web.controllers.Customer",
> "customerId" : 101,
> "firstName" : "Vishal",
> "lastName" : "Roa"
>   }, null ]
> }>
> {code}



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

[jira] [Assigned] (GEODE-7974) CI Failure: RestAccessControllerTest > getSpecificKeysUsingQueryParamWithNonExistentKey

[Joris Melchior (Jira)]

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

Joris Melchior reassigned GEODE-7974:
-

Assignee: Joris Melchior

> CI Failure: RestAccessControllerTest > 
> getSpecificKeysUsingQueryParamWithNonExistentKey
> ---
>
> Key: GEODE-7974
> URL: https://issues.apache.org/jira/browse/GEODE-7974
> Project: Geode
>  Issue Type: Bug
>  Components: rest (dev)
>Reporter: Ernest Burghardt
>Assignee: Joris Melchior
>Priority: Major
>
> [https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK11/builds/27]
>  
> {code:java}
> > Task :geode-web-api:integrationTest
> org.apache.geode.rest.internal.web.controllers.RestAccessControllerTest > 
> getSpecificKeysUsingQueryParamWithNonExistentKey FAILED
> java.lang.AssertionError: Response content expected:<{
>   "customers" : [ {
> "@type" : "org.apache.geode.rest.internal.web.controllers.Customer",
> "customerId" : 101,
> "firstName" : "Vishal",
> "lastName" : "Roa"
>   }, null ]
> }> but was:<{
>   "customers" : [ {
> "@type" : "org.apache.geode.rest.internal.web.controllers.Customer",
> "customerId" : 101,
> "firstName" : "Vishal",
> "lastName" : "Roa"
>   }, null ]
> }>
> {code}



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

[jira] [Assigned] (GEODE-7906) GfshCommandIntegrationTest failing in Windows testing JDK8 and JDK11

[Joris Melchior (Jira)]

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

Joris Melchior reassigned GEODE-7906:
-

Assignee: Darrel Schneider

> GfshCommandIntegrationTest failing in Windows testing JDK8 and JDK11
> 
>
> Key: GEODE-7906
> URL: https://issues.apache.org/jira/browse/GEODE-7906
> Project: Geode
>  Issue Type: Bug
>  Components: management
>Reporter: Joris Melchior
>Assignee: Darrel Schneider
>Priority: Major
>
> Failed in CI:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK11/builds/1344#L5e3ada01:364:370
> Test results:
> http://files.apachegeode-ci.info/builds/apache-develop-main/1.13.0-SNAPSHOT.0115/test-results/integrationTest/1585078363/
> {noformat}
> org.apache.geode.management.internal.cli.commands.GfshCommandIntegrationTest 
> > invalidCommandWhenConnected FAILED
> org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>
> at 
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at 
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at 
> org.apache.geode.test.junit.rules.GfshCommandRule.connectAndVerify(GfshCommandRule.java:163)
> at 
> org.apache.geode.management.internal.cli.commands.GfshCommandIntegrationTest.invalidCommandWhenConnected(GfshCommandIntegrationTest.java:71)
> {noformat}



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

[jira] [Created] (GEODE-7906) GfshCommandIntegrationTest failing in Windows testing JDK8 and JDK11

[Joris Melchior (Jira)]

Joris Melchior created GEODE-7906:
-

 Summary: GfshCommandIntegrationTest failing in Windows testing 
JDK8 and JDK11
 Key: GEODE-7906
 URL: https://issues.apache.org/jira/browse/GEODE-7906
 Project: Geode
  Issue Type: Bug
  Components: management
Reporter: Joris Melchior


Failed in CI:
https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/WindowsIntegrationTestOpenJDK11/builds/1344#L5e3ada01:364:370

Test results:
http://files.apachegeode-ci.info/builds/apache-develop-main/1.13.0-SNAPSHOT.0115/test-results/integrationTest/1585078363/

{noformat}
org.apache.geode.management.internal.cli.commands.GfshCommandIntegrationTest > 
invalidCommandWhenConnected FAILED

org.junit.ComparisonFailure: expected:<[tru]e> but was:<[fals]e>

at 
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)

at 
jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)

at 
jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)

at 
org.apache.geode.test.junit.rules.GfshCommandRule.connectAndVerify(GfshCommandRule.java:163)

at 
org.apache.geode.management.internal.cli.commands.GfshCommandIntegrationTest.invalidCommandWhenConnected(GfshCommandIntegrationTest.java:71)

{noformat}




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

[jira] [Created] (GEODE-7904) ClusterCommunicationsDUnitTest > performARollingUpgrade[UNSHARED_CONNECTIONS_WITH_SSL]

[Joris Melchior (Jira)]

Joris Melchior created GEODE-7904:
-

 Summary: ClusterCommunicationsDUnitTest > 
performARollingUpgrade[UNSHARED_CONNECTIONS_WITH_SSL]
 Key: GEODE-7904
 URL: https://issues.apache.org/jira/browse/GEODE-7904
 Project: Geode
  Issue Type: Bug
  Components: membership
Reporter: Joris Melchior


Failed CI job: [Distributed test 
1654|https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1654#L5e3ace7f:641:656]
{noformat}
org.apache.geode.ClusterCommunicationsDUnitTest > 
performARollingUpgrade[UNSHARED_CONNECTIONS_WITH_SSL] 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 3455


[fatal 2020/03/24 08:01:43.101 GMT  tid=82] Uncaught 
exception in thread Thread[unused p2p reader,10,RMI Runtime]

org.apache.geode.distributed.DistributedSystemDisconnectedException: 
Distribution manager on 172.17.0.20(vm0:4181:locator):41001 started at 
Tue Mar 24 08:01:24 GMT 2020: Message distribution has terminated

at 
org.apache.geode.distributed.internal.ClusterDistributionManager$Stopper.generateCancelledException(ClusterDistributionManager.java:2873)

at 
org.apache.geode.internal.tcp.TCPConduit$Stopper.generateCancelledException(TCPConduit.java:1004)

at 
org.apache.geode.CancelCriterion.checkCancelInProgress(CancelCriterion.java:83)

at 
org.apache.geode.internal.tcp.Connection.readMessages(Connection.java:1670)

at org.apache.geode.internal.tcp.Connection.run(Connection.java:1450)

at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)

at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)

at java.base/java.lang.Thread.run(Thread.java:834)

{noformat}




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

[jira] [Commented] (GEODE-7901) Redis testGetSet_shouldBeAtomic and testGetRange_rangePastEndOfValue_returnsEmptyString tests failing

[Joris Melchior (Jira)]

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

Joris Melchior commented on GEODE-7901:
---

Failed again in build #1624

> Redis testGetSet_shouldBeAtomic and 
> testGetRange_rangePastEndOfValue_returnsEmptyString tests failing
> -
>
> Key: GEODE-7901
> URL: https://issues.apache.org/jira/browse/GEODE-7901
> Project: Geode
>  Issue Type: Bug
>  Components: redis
>Reporter: Bill Burcham
>Assignee: Bill Burcham
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Three CI failures recently e.g. 
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK11/builds/1615
> {code}
> org.apache.geode.redis.StringsIntegrationTest > testGetSet_shouldBeAtomic 
> FAILED
> java.util.concurrent.TimeoutException
> at java.util.concurrent.FutureTask.get(FutureTask.java:204)
> at 
> org.apache.geode.redis.StringsIntegrationTest.testGetSet_shouldBeAtomic(StringsIntegrationTest.java:284)
> java.lang.ClassCastException: class java.lang.Long cannot be cast to 
> class [B (java.lang.Long and [B are in module java.base of loader 'bootstrap')
> at 
> redis.clients.jedis.Connection.getStatusCodeReply(Connection.java:236)
> at redis.clients.jedis.BinaryJedis.flushAll(BinaryJedis.java:599)
> at 
> org.apache.geode.redis.StringsIntegrationTest.flushAll(StringsIntegrationTest.java:82)
> org.apache.geode.redis.StringsIntegrationTest > 
> testGetRange_rangePastEndOfValue_returnsEmptyString FAILED
> org.junit.ComparisonFailure: expected:<"[]"> but was:<"[OK]">
> at 
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at 
> jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at 
> jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at 
> org.apache.geode.redis.StringsIntegrationTest.testGetRange_rangePastEndOfValue_returnsEmptyString(StringsIntegrationTest.java:209)
> {code}
> a couple more CI failures:
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK11/builds/1613
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/IntegrationTestOpenJDK11/builds/1616



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

[jira] [Updated] (GEODE-7821) DestroyRegionDuringGIIDistributedTest > testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION FAILED

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-7821:
--
Priority: Minor  (was: Major)

> DestroyRegionDuringGIIDistributedTest > 
> testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION
>  FAILED
> -
>
> Key: GEODE-7821
> URL: https://issues.apache.org/jira/browse/GEODE-7821
> Project: Geode
>  Issue Type: Bug
>  Components: core, tests
>Reporter: Joris Melchior
>Priority: Minor
> Fix For: 1.13.0
>
>
> Seen this fail in a couple of places. Failures do not seem to have a direct 
> relation to the pull request for the job.
> https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1581
> org.apache.geode.internal.cache.DestroyRegionDuringGIIDistributedTest > 
> testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION
>  FAILED
> org.apache.geode.test.dunit.RMIException: While invoking 
> org.apache.geode.internal.cache.DestroyRegionDuringGIIDistributedTest$$Lambda$179/0x000840c73840.run
>  in VM 2 running on Host 8f4bff2410d5 with 4 VMs
> at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)
> at org.apache.geode.test.dunit.VM.invoke(VM.java:437)
> at 
> org.apache.geode.internal.cache.DestroyRegionDuringGIIDistributedTest.testNBRegionInvalidationDuringGetInitialImage(DestroyRegionDuringGIIDistributedTest.java:414)
> Caused by:
> org.junit.ComparisonFailure: expected: but was:<[66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
> 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 

[jira] [Created] (GEODE-7821) DestroyRegionDuringGIIDistributedTest > testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION FAILED

[Joris Melchior (Jira)]

Joris Melchior created GEODE-7821:
-

 Summary: DestroyRegionDuringGIIDistributedTest > 
testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION 
FAILED
 Key: GEODE-7821
 URL: https://issues.apache.org/jira/browse/GEODE-7821
 Project: Geode
  Issue Type: Bug
  Components: core, tests
Reporter: Joris Melchior
 Fix For: 1.13.0


Seen this fail in a couple of places. Failures do not seem to have a direct 
relation to the pull request for the job.

https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/DistributedTestOpenJDK11/builds/1581

org.apache.geode.internal.cache.DestroyRegionDuringGIIDistributedTest > 
testNBRegionInvalidationDuringGetInitialImage_HEAP_DISTRIBUTED_ACK_COMPRESSION 
FAILED

org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.internal.cache.DestroyRegionDuringGIIDistributedTest$$Lambda$179/0x000840c73840.run
 in VM 2 running on Host 8f4bff2410d5 with 4 VMs

at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)

at org.apache.geode.test.dunit.VM.invoke(VM.java:437)

at 
org.apache.geode.internal.cache.DestroyRegionDuringGIIDistributedTest.testNBRegionInvalidationDuringGetInitialImage(DestroyRegionDuringGIIDistributedTest.java:414)


Caused by:

org.junit.ComparisonFailure: expected: but was:<[66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 
66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 66, 

[jira] [Commented] (GEODE-6284) CI Failure: RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated.test[from_v1X0, with reindex=false]

[Joris Melchior (Jira)]

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

Joris Melchior commented on GEODE-6284:
---

Additional failure:

[https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-develop-main/jobs/UpgradeTestOpenJDK8/builds/1558]

 
org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOverAllBucketsCreated
 > test[from_v1.9.2, with reindex=false, singleHopEnabled=true] 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 9011


  
/home/geode/.gradle/caches/modules-2/files-2.1/com.google.guava/failureaccess/1.0.1/1dcf1de382a0bf95a3d8b0849546c8[info
 2020/02/27 07:25:56.286 GMT  tid=80] Communication with 
locator /172.17.0.37:24573 failed with java.io.EOFException: Locator at 
/172.17.0.37:24573 did not respond. This is normal if the locator was shutdown. 
If it wasn't check its log for exceptions..

java.io.EOFException: Locator at /172.17.0.37:24573 did not respond. This 
is normal if the locator was shutdown. If it wasn't check its log for 
exceptions.

at 
org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:232)

at 
org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:209)

at 
org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:199)

at 
org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:287)

at 
org.apache.geode.cache.client.internal.AutoConnectionSourceImpl$UpdateLocatorListTask.run2(AutoConnectionSourceImpl.java:500)

at 
org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1371)

at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)

at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)

at 
org.apache.geode.internal.ScheduledThreadPoolExecutorWithKeepAlive$DelegatingScheduledFuture.run(ScheduledThreadPoolExecutorWithKeepAlive.java:276)

at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)

at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)

at java.lang.Thread.run(Thread.java:748)

Caused by: java.io.EOFException

at java.io.DataInputStream.readByte(DataInputStream.java:267)

at 
org.apache.geode.internal.InternalDataSerializer.basicReadObject(InternalDataSerializer.java:2775)

at org.apache.geode.DataSerializer.readObject(DataSerializer.java:2978)

at 
org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:227)

... 11 more


org.apache.geode.cache.lucene.RollingUpgradeQueryReturnsCorrectResultsAfterClientAndServersAreRolledOver
 > 
luceneQueryReturnsCorrectResultsAfterClientAndServersAreRolledOver[from_v1.9.0, 
with reindex=true, singleHopEnabled=true] 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 8587


  
/home/geode/.gradle/caches/modules-2/files-2.1/com.google.guava/failureaccess/1.0.1/1dcf1de382a0bf95a3d8b0849546c8[info
 2020/02/27 07:26:07.784 GMT  tid=51] Communication with 
locator /172.17.0.12:25434 failed with java.io.EOFException: Locator at 
/172.17.0.12:25434 did not respond. This is normal if the locator was shutdown. 
If it wasn't check its log for exceptions..

java.io.EOFException: Locator at /172.17.0.12:25434 did not respond. This 
is normal if the locator was shutdown. If it wasn't check its log for 
exceptions.

at 
org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:232)

at 
org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:209)

at 
org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:199)

at 
org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:287)

at 
org.apache.geode.cache.client.internal.AutoConnectionSourceImpl$UpdateLocatorListTask.run2(AutoConnectionSourceImpl.java:500)

at 
org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1371)

at 

[jira] [Created] (GEODE-7809) Distributed management operation enhancements

[Joris Melchior (Jira)]

Joris Melchior created GEODE-7809:
-

 Summary: Distributed management operation enhancements
 Key: GEODE-7809
 URL: https://issues.apache.org/jira/browse/GEODE-7809
 Project: Geode
  Issue Type: Improvement
  Components: management
Reporter: Joris Melchior
 Fix For: 1.13.0


Distributed management operations need the following improvements:
 * Operations that have no end-date will currently be cleaned up. We should 
pick a set time after the start of an operation that the record will have to 
live in the Region of record. This way even operations without and end-date 
will get cleaned up at some point.
 * Currently operations will be cleaned out of the Region of record 2 hours 
after completion. This is considered too quick so we need to pick a longer time 
period and change it to that. We can also consider making this time 
configurable.
 * When the locator on which the operation is started disappears for any reason 
before the distributed operation has finished the end of the operation will not 
be recorded. We should find a way to make sure that we can record an end of an 
operation even if the original request locator disappears before the operation 
completion. (this assumes that the cluster has more than one locator running)



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

[jira] [Updated] (GEODE-7809) Distributed management operation enhancements

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-7809:
--
Priority: Minor  (was: Major)

> Distributed management operation enhancements
> -
>
> Key: GEODE-7809
> URL: https://issues.apache.org/jira/browse/GEODE-7809
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Joris Melchior
>Priority: Minor
> Fix For: 1.13.0
>
>
> Distributed management operations need the following improvements:
>  * Operations that have no end-date will currently be cleaned up. We should 
> pick a set time after the start of an operation that the record will have to 
> live in the Region of record. This way even operations without and end-date 
> will get cleaned up at some point.
>  * Currently operations will be cleaned out of the Region of record 2 hours 
> after completion. This is considered too quick so we need to pick a longer 
> time period and change it to that. We can also consider making this time 
> configurable.
>  * When the locator on which the operation is started disappears for any 
> reason before the distributed operation has finished the end of the operation 
> will not be recorded. We should find a way to make sure that we can record an 
> end of an operation even if the original request locator disappears before 
> the operation completion. (this assumes that the cluster has more than one 
> locator running)



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

[jira] [Resolved] (GEODE-7574) Fix javadoc warnings

[Joris Melchior (Jira)]

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

Joris Melchior resolved GEODE-7574.
---
Resolution: Fixed

> Fix javadoc warnings
> 
>
> Key: GEODE-7574
> URL: https://issues.apache.org/jira/browse/GEODE-7574
> Project: Geode
>  Issue Type: Task
>  Components: management
>Reporter: Joris Melchior
>Assignee: Joris Melchior
>Priority: Major
> Fix For: 1.12.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Task :geode-management:javadoc
> /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/AutoSerializer.java:34:
>  warning - Tag @link: reference not found: 
> org.apache.geode.pdx.ReflectionBasedAutoSerializer
> /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/ClassName.java:36:
>  warning - Tag @link: reference not found: org.apache.geode.cache.Declarable
> /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/ClassName.java:68:
>  warning - Tag @link: reference not found: 
> org.apache.geode.cache.Declarable#initialize
> /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/ClassName.java:93:
>  warning - Tag @link: reference not found: 
> org.apache.geode.cache.Declarable#initialize
> /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/Pdx.java:78:
>  warning - Tag @link: reference not found: org.apache.geode.pdx.PdxInstance
> /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/Pdx.java:78:
>  warning - Tag @link: reference not found: org.apache.geode.pdx.PdxInstance
> /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/Pdx.java:91:
>  warning - Tag @link: reference not found: org.apache.geode.pdx.PdxSerializer
> /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/AutoSerializer.java:34:
>  warning - Tag @link: reference not found: 
> org.apache.geode.pdx.ReflectionBasedAutoSerializer
> /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/AutoSerializer.java:34:
>  warning - Tag @link: reference not found: 
> org.apache.geode.pdx.ReflectionBasedAutoSerializer
> /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/Pdx.java:78:
>  warning - Tag @link: reference not found: org.apache.geode.pdx.PdxInstance



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

[jira] [Resolved] (GEODE-7504) support creating regions with eviction

[Joris Melchior (Jira)]

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

Joris Melchior resolved GEODE-7504.
---
Fix Version/s: 1.12.0
   Resolution: Fixed

> support creating regions with eviction
> --
>
> Key: GEODE-7504
> URL: https://issues.apache.org/jira/browse/GEODE-7504
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Darrel Schneider
>Assignee: Joris Melchior
>Priority: Major
> Fix For: 1.12.0
>
>  Time Spent: 4h
>  Remaining Estimate: 0h
>
> The new rest api supports creating regions but they can not be configured for 
> eviction.
> Support for eviction should be added.



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

[jira] [Resolved] (GEODE-7463) Ability: have an endpoint to show all the version info of REST API for Management

[Joris Melchior (Jira)]

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

Joris Melchior resolved GEODE-7463.
---
Fix Version/s: 1.12.0
   Resolution: Fixed

> Ability: have an endpoint to show all the version info of REST API for 
> Management
> -
>
> Key: GEODE-7463
> URL: https://issues.apache.org/jira/browse/GEODE-7463
> Project: Geode
>  Issue Type: New Feature
>  Components: management, rest (admin)
>Reporter: Gang Yan
>Assignee: Joris Melchior
>Priority: Major
> Fix For: 1.12.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> # WHY
>1.  have a universal endpoint for all the versions of REST API for 
> Management
>2. stop showing 404 for users, when they try to do some experiment
>3. show more helpful information to users
>
> # WHAT
>1. url:  [GET] /management/
>  2.  response:  show all the api-docs for all "available" versions. such 
> as:  
> http://localhost:7070/management/v1/api-docs
> http://localhost:7070/management/v2/api-docs
> http://localhost:7070/management/v3/api-docs
> # NOTE
> [1] response body:
> {code:json}
> {
> latest:"http://localhost:7070/management/v3/api-docs;,
>supported:["http://localhost:7070/management/v1/api-docs;,
> "http://localhost:7070/management/v2/api-docs;, 
> "http://localhost:7070/management/v3/api-docs;
>   ]
> }
> {code}



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

[jira] [Assigned] (GEODE-7463) Ability: have an endpoint to show all the version info of REST API for Management

[Joris Melchior (Jira)]

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

Joris Melchior reassigned GEODE-7463:
-

Assignee: Joris Melchior

> Ability: have an endpoint to show all the version info of REST API for 
> Management
> -
>
> Key: GEODE-7463
> URL: https://issues.apache.org/jira/browse/GEODE-7463
> Project: Geode
>  Issue Type: New Feature
>  Components: management, rest (admin)
>Reporter: Gang Yan
>Assignee: Joris Melchior
>Priority: Major
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> # WHY
>1.  have a universal endpoint for all the versions of REST API for 
> Management
>2. stop showing 404 for users, when they try to do some experiment
>3. show more helpful information to users
>
> # WHAT
>1. url:  [GET] /management/
>  2.  response:  show all the api-docs for all "available" versions. such 
> as:  
> http://localhost:7070/management/v1/api-docs
> http://localhost:7070/management/v2/api-docs
> http://localhost:7070/management/v3/api-docs
> # NOTE
> [1] response body:
> {code:json}
> {
> latest:"http://localhost:7070/management/v3/api-docs;,
>supported:["http://localhost:7070/management/v1/api-docs;,
> "http://localhost:7070/management/v2/api-docs;, 
> "http://localhost:7070/management/v3/api-docs;
>   ]
> }
> {code}



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

[jira] [Assigned] (GEODE-7428) adjustment: set the log-lvl of REST API of Management from info to debug

[Joris Melchior (Jira)]

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

Joris Melchior reassigned GEODE-7428:
-

Assignee: Joris Melchior

> adjustment: set the log-lvl of REST API of Management from info to debug
> 
>
> Key: GEODE-7428
> URL: https://issues.apache.org/jira/browse/GEODE-7428
> Project: Geode
>  Issue Type: Improvement
>  Components: management, rest (admin)
>Reporter: Gang Yan
>Assignee: Joris Melchior
>Priority: Major
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> # WHY
>  1. too many logs in the log file,  that is a customer concern
>  2. broker team call RESTAPI for Management for healthcheck per 10 seconds. 
> it will produce too many logs.
> # WHAT 
>  1. change every log which is produced by RESTAPI for management to be DEBUG.



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

[jira] [Resolved] (GEODE-7428) adjustment: set the log-lvl of REST API of Management from info to debug

[Joris Melchior (Jira)]

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

Joris Melchior resolved GEODE-7428.
---
Fix Version/s: 1.12.0
   Resolution: Fixed

> adjustment: set the log-lvl of REST API of Management from info to debug
> 
>
> Key: GEODE-7428
> URL: https://issues.apache.org/jira/browse/GEODE-7428
> Project: Geode
>  Issue Type: Improvement
>  Components: management, rest (admin)
>Reporter: Gang Yan
>Assignee: Joris Melchior
>Priority: Major
> Fix For: 1.12.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> # WHY
>  1. too many logs in the log file,  that is a customer concern
>  2. broker team call RESTAPI for Management for healthcheck per 10 seconds. 
> it will produce too many logs.
> # WHAT 
>  1. change every log which is produced by RESTAPI for management to be DEBUG.



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

[jira] [Created] (GEODE-7723) CI Failure: WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover

[Joris Melchior (Jira)]

Joris Melchior created GEODE-7723:
-

 Summary: CI Failure: 
WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover
 Key: GEODE-7723
 URL: https://issues.apache.org/jira/browse/GEODE-7723
 Project: Geode
  Issue Type: Bug
  Components: wan
Reporter: Joris Melchior
 Fix For: 1.12.0


{quote}> Task :geode-wan:upgradeTest

org.apache.geode.cache.wan.WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover
 > testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover[from_v1.7.0] 
FAILED

org.apache.geode.test.dunit.RMIException: While invoking 
org.apache.geode.cache.wan.WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover$$Lambda$56/206470689.run
 in VM 4 running on Host 544e089331af with 7 VMs

at org.apache.geode.test.dunit.VM.executeMethodOnObject(VM.java:610)

at org.apache.geode.test.dunit.VM.invoke(VM.java:437)

at 
org.apache.geode.cache.wan.WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover.testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover(WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover.java:73)

Caused by:

java.net.BindException: Failed to create server socket on 
544e089331af/172.17.0.5[25118]

at 
org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:626)

at 
org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:584)

at 
org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:551)

at 
org.apache.geode.distributed.internal.membership.adapter.TcpSocketCreatorAdapter.createServerSocket(TcpSocketCreatorAdapter.java:52)

at 
org.apache.geode.distributed.internal.tcpserver.TcpServer.initializeServerSocket(TcpServer.java:186)

at 
org.apache.geode.distributed.internal.tcpserver.TcpServer.startServerThread(TcpServer.java:176)

at 
org.apache.geode.distributed.internal.tcpserver.TcpServer.start(TcpServer.java:171)

at 
org.apache.geode.distributed.internal.membership.gms.locator.MembershipLocatorImpl.start(MembershipLocatorImpl.java:101)

at 
org.apache.geode.distributed.internal.InternalLocator.startPeerLocation(InternalLocator.java:635)

at 
org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:378)

at 
org.apache.geode.distributed.internal.InternalLocator.startLocator(InternalLocator.java:333)

at org.apache.geode.distributed.Locator.startLocator(Locator.java:253)

at org.apache.geode.distributed.Locator.startLocatorAndDS(Locator.java:140)

at 
org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest.startLocator(WANRollingUpgradeDUnitTest.java:105)

at 
org.apache.geode.cache.wan.WANRollingUpgradeDUnitTest.startLocator(WANRollingUpgradeDUnitTest.java:97)

at 
org.apache.geode.cache.wan.WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover.lambda$testSecondaryEventsNotReprocessedAfterOldSiteMemberFailover$67afc7f8$1(WANRollingUpgradeSecondaryEventsNotReprocessedAfterOldSiteMemberFailover.java:73)

Caused by:

java.net.BindException: Address already in use (Bind failed)

at java.net.PlainSocketImpl.socketBind(Native Method)

at java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)

at java.net.ServerSocket.bind(ServerSocket.java:390)

at 
org.apache.geode.internal.net.SocketCreator.createServerSocket(SocketCreator.java:623)

... 15 more
{quote}



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

[jira] [Updated] (GEODE-7701) un-deprecate IndexType ENUM

[Joris Melchior (Jira)]

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

Joris Melchior updated GEODE-7701:
--
Priority: Minor  (was: Major)

> un-deprecate IndexType ENUM
> ---
>
> Key: GEODE-7701
> URL: https://issues.apache.org/jira/browse/GEODE-7701
> Project: Geode
>  Issue Type: Improvement
>  Components: core
>Reporter: Joris Melchior
>Priority: Minor
> Fix For: 1.12.0
>
>
> {{The org.apache.geode.cache.query.IndexType ENUM type has been deprecated 
> without a clear replacement. This causes some issues with warnings during 
> compilation and a lack of clarity on how to properly use the code.}}
> A 
> [proposal|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135863477]
>  was written up and discussed to address this. 
> This issue is opened to implement the proposal.



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

[jira] [Assigned] (GEODE-7701) un-deprecate IndexType ENUM

[Joris Melchior (Jira)]

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

Joris Melchior reassigned GEODE-7701:
-

Assignee: Joris Melchior

> un-deprecate IndexType ENUM
> ---
>
> Key: GEODE-7701
> URL: https://issues.apache.org/jira/browse/GEODE-7701
> Project: Geode
>  Issue Type: Improvement
>  Components: core
>Reporter: Joris Melchior
>Assignee: Joris Melchior
>Priority: Minor
> Fix For: 1.12.0
>
>
> {{The org.apache.geode.cache.query.IndexType ENUM type has been deprecated 
> without a clear replacement. This causes some issues with warnings during 
> compilation and a lack of clarity on how to properly use the code.}}
> A 
> [proposal|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135863477]
>  was written up and discussed to address this. 
> This issue is opened to implement the proposal.



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

[jira] [Created] (GEODE-7701) un-deprecate IndexType ENUM

[Joris Melchior (Jira)]

Joris Melchior created GEODE-7701:
-

 Summary: un-deprecate IndexType ENUM
 Key: GEODE-7701
 URL: https://issues.apache.org/jira/browse/GEODE-7701
 Project: Geode
  Issue Type: Improvement
  Components: core
Reporter: Joris Melchior
 Fix For: 1.12.0


{{The org.apache.geode.cache.query.IndexType ENUM type has been deprecated 
without a clear replacement. This causes some issues with warnings during 
compilation and a lack of clarity on how to properly use the code.}}

A 
[proposal|https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=135863477]
 was written up and discussed to address this. 

This issue is opened to implement the proposal.



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

[jira] [Created] (GEODE-7608) Member information shows size information without units

[Joris Melchior (Jira)]

Joris Melchior created GEODE-7608:
-

 Summary: Member information shows size information without units
 Key: GEODE-7608
 URL: https://issues.apache.org/jira/browse/GEODE-7608
 Project: Geode
  Issue Type: Improvement
  Components: management
Reporter: Joris Melchior


When doing a list members call on the management API the returned JSON shows 
the numbers for heapUsage, maxHeapSize and initHeapSize without indicating what 
the unit of measure is.

Change the returned information so that the user can determine the unit of 
measure without guessing by either changing the field names to include a unit 
indicator such as `heapUsageMb` or have the value carry such an indicator in it.



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

[jira] [Created] (GEODE-7574) Fix javadoc warnings

[Joris Melchior (Jira)]

Joris Melchior created GEODE-7574:
-

 Summary: Fix javadoc warnings
 Key: GEODE-7574
 URL: https://issues.apache.org/jira/browse/GEODE-7574
 Project: Geode
  Issue Type: Task
  Components: management
Reporter: Joris Melchior
 Fix For: 1.12.0


Task :geode-management:javadoc
/Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/AutoSerializer.java:34:
 warning - Tag @link: reference not found: 
org.apache.geode.pdx.ReflectionBasedAutoSerializer
/Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/ClassName.java:36:
 warning - Tag @link: reference not found: org.apache.geode.cache.Declarable
/Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/ClassName.java:68:
 warning - Tag @link: reference not found: 
org.apache.geode.cache.Declarable#initialize
/Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/ClassName.java:93:
 warning - Tag @link: reference not found: 
org.apache.geode.cache.Declarable#initialize
/Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/Pdx.java:78:
 warning - Tag @link: reference not found: org.apache.geode.pdx.PdxInstance
/Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/Pdx.java:78:
 warning - Tag @link: reference not found: org.apache.geode.pdx.PdxInstance
/Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/Pdx.java:91:
 warning - Tag @link: reference not found: org.apache.geode.pdx.PdxSerializer
/Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/AutoSerializer.java:34:
 warning - Tag @link: reference not found: 
org.apache.geode.pdx.ReflectionBasedAutoSerializer
/Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/AutoSerializer.java:34:
 warning - Tag @link: reference not found: 
org.apache.geode.pdx.ReflectionBasedAutoSerializer
/Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/Pdx.java:78:
 warning - Tag @link: reference not found: org.apache.geode.pdx.PdxInstance



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

[jira] [Assigned] (GEODE-7574) Fix javadoc warnings

[Joris Melchior (Jira)]

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

Joris Melchior reassigned GEODE-7574:
-

Assignee: Joris Melchior

> Fix javadoc warnings
> 
>
> Key: GEODE-7574
> URL: https://issues.apache.org/jira/browse/GEODE-7574
> Project: Geode
>  Issue Type: Task
>  Components: management
>Reporter: Joris Melchior
>Assignee: Joris Melchior
>Priority: Major
> Fix For: 1.12.0
>
>
> Task :geode-management:javadoc
> /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/AutoSerializer.java:34:
>  warning - Tag @link: reference not found: 
> org.apache.geode.pdx.ReflectionBasedAutoSerializer
> /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/ClassName.java:36:
>  warning - Tag @link: reference not found: org.apache.geode.cache.Declarable
> /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/ClassName.java:68:
>  warning - Tag @link: reference not found: 
> org.apache.geode.cache.Declarable#initialize
> /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/ClassName.java:93:
>  warning - Tag @link: reference not found: 
> org.apache.geode.cache.Declarable#initialize
> /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/Pdx.java:78:
>  warning - Tag @link: reference not found: org.apache.geode.pdx.PdxInstance
> /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/Pdx.java:78:
>  warning - Tag @link: reference not found: org.apache.geode.pdx.PdxInstance
> /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/Pdx.java:91:
>  warning - Tag @link: reference not found: org.apache.geode.pdx.PdxSerializer
> /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/AutoSerializer.java:34:
>  warning - Tag @link: reference not found: 
> org.apache.geode.pdx.ReflectionBasedAutoSerializer
> /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/AutoSerializer.java:34:
>  warning - Tag @link: reference not found: 
> org.apache.geode.pdx.ReflectionBasedAutoSerializer
> /Users/jbarrett/Develop/geode/geode-management/src/main/java/org/apache/geode/management/configuration/Pdx.java:78:
>  warning - Tag @link: reference not found: org.apache.geode.pdx.PdxInstance



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

[jira] [Assigned] (GEODE-7504) support creating regions with eviction

[Joris Melchior (Jira)]

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

Joris Melchior reassigned GEODE-7504:
-

Assignee: Joris Melchior  (was: Darrel Schneider)

> support creating regions with eviction
> --
>
> Key: GEODE-7504
> URL: https://issues.apache.org/jira/browse/GEODE-7504
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Darrel Schneider
>Assignee: Joris Melchior
>Priority: Major
>
> The new rest api supports creating regions but they can not be configured for 
> eviction.
> Support for eviction should be added.



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

[jira] [Assigned] (GEODE-7504) support creating regions with eviction

[Joris Melchior (Jira)]

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

Joris Melchior reassigned GEODE-7504:
-

Assignee: Darrel Schneider

> support creating regions with eviction
> --
>
> Key: GEODE-7504
> URL: https://issues.apache.org/jira/browse/GEODE-7504
> Project: Geode
>  Issue Type: Improvement
>  Components: management
>Reporter: Darrel Schneider
>Assignee: Darrel Schneider
>Priority: Major
>
> The new rest api supports creating regions but they can not be configured for 
> eviction.
> Support for eviction should be added.



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

[jira] [Commented] (GEODE-7264) Jackson-databind vulnerabilities

[Joris Melchior (Jira)]

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

Joris Melchior commented on GEODE-7264:
---

The linked issue fix resolves this issue as well.

> Jackson-databind vulnerabilities
> 
>
> Key: GEODE-7264
> URL: https://issues.apache.org/jira/browse/GEODE-7264
> Project: Geode
>  Issue Type: Bug
>  Components: rest (admin)
>Reporter: Gang Yan
>Priority: Major
>
> In case it is by when the customer can expect a patch that addresses these 
> vulnerabilities?
> [1] [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12814]
> [2] [https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12384]



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