[GitHub] [geode] mivanac closed pull request #7841: GEODE-10339: Configurable IF file compaction mode
mivanac closed pull request #7841: GEODE-10339: Configurable IF file compaction mode URL: https://github.com/apache/geode/pull/7841 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [geode] mivanac opened a new pull request, #7866: GEODE-10425: add new option
mivanac opened a new pull request, #7866: URL: https://github.com/apache/geode/pull/7866 ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Has your PR been rebased against the latest commit within the target branch (typically `develop`)? - [ ] Is your initial contribution a single, squashed commit? - [ ] Does `gradlew build` run cleanly? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [geode] albertogpz opened a new pull request, #7865: [DRAFT DO NOT REVIEW] Wip limit max threads to server
albertogpz opened a new pull request, #7865: URL: https://github.com/apache/geode/pull/7865 ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Has your PR been rebased against the latest commit within the target branch (typically `develop`)? - [ ] Is your initial contribution a single, squashed commit? - [ ] Does `gradlew build` run cleanly? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [geode] albertogpz closed pull request #7864: [DRAFT DO NOT REVIEW] Limit the number of threads to destinations
albertogpz closed pull request #7864: [DRAFT DO NOT REVIEW] Limit the number of threads to destinations URL: https://github.com/apache/geode/pull/7864 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [geode] albertogpz opened a new pull request, #7864: [DRAFT DO NOT REVIEW] Limit the number of threads to destinations
albertogpz opened a new pull request, #7864: URL: https://github.com/apache/geode/pull/7864 ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Has your PR been rebased against the latest commit within the target branch (typically `develop`)? - [ ] Is your initial contribution a single, squashed commit? - [ ] Does `gradlew build` run cleanly? - [ ] Have you written or updated unit tests to verify your changes? - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [geode] albertogpz commented on a diff in pull request #7861: GEODE-10423: Document the system property “ON_DISCONNECT_CLEAR_PDXTYP…
albertogpz commented on code in PR #7861: URL: https://github.com/apache/geode/pull/7861#discussion_r983280085 ## geode-docs/developing/data_serialization/PDX_Serialization_Features.html.md.erb: ## @@ -31,6 +31,33 @@ When you serialize an object using PDX, <%=vars.product_name%> stores the object This centralization of object type information is advantageous for client/server installations in which clients and servers are written in different languages. Clients pass registry information to servers automatically when they store a PDX serialized object. Clients can run queries and functions against the data in the servers without compatibility between server and the stored objects. One client can store data on the server to be retrieved by another client, with no requirements on the part of the server. +**Note:** +There are situations where some of the information in the central registry of the PDX domain object metadata is lost, e.g. when restoring an old backup with an outdated central registry. + +When that happens, new clients connecting to the cluster for the first time will get outdated PDX type information from the central registry, but, since information in the central registry is cached by clients, old clients may have fresher information about PDX types than the central registry does. That will result into inconsistent information about PDX types spread across the system: + +- old clients have fresh information +- the central registry has outdated information +- new clients have outdated information + +If old clients write entries of a PDX type they know but the central registry doesn't, new clients will get "Unknown PDX type" errors when they read those objects. + +To avoid this problem, clients may be configured with the system property in the table below to clear their PDX type cache when they disconnect from the cluster. After clearing their cache, old clients will re-generate type information for all PDX types, including the types the central registry "forgot". Since new PDX type information will be written in the central registry before entries of that type are written in the cluster, the central registry and all clients, old and new, will store consistent PDX type information. + +| Name | Description | Default | +|---|-|-| +| `gemfire.ON_DISCONNECT_CLEAR_PDXTYPEIDS` | Clear pdxType ids when client disconnects from servers. | `false` | +- In the API, set the System properties before the cache creation call. Example: + +``` pre +System.setProperty(PoolImpl.ON_DISCONNECT_CLEAR_PDXTYPEIDS, "true"); +``` +- At the java command line, pass in System properties using the -D switch. Example: + +``` pre +java -Dgemfire.ON_DISCONNECT_CLEAR_PDXTYPEIDS=true +``` + Review Comment: It would probably be better to add this variable and description to the corresponding documents of the Java and Native clients: https://geode.apache.org/docs/geode-native/cpp/115/configuring/sysprops.html https://geode.apache.org/docs/guide/115/reference/topics/gemfire_properties.html -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [geode] albertogpz commented on a diff in pull request #7861: GEODE-10423: Document the system property “ON_DISCONNECT_CLEAR_PDXTYP…
albertogpz commented on code in PR #7861: URL: https://github.com/apache/geode/pull/7861#discussion_r983275654 ## geode-docs/developing/data_serialization/PDX_Serialization_Features.html.md.erb: ## @@ -31,6 +31,33 @@ When you serialize an object using PDX, <%=vars.product_name%> stores the object This centralization of object type information is advantageous for client/server installations in which clients and servers are written in different languages. Clients pass registry information to servers automatically when they store a PDX serialized object. Clients can run queries and functions against the data in the servers without compatibility between server and the stored objects. One client can store data on the server to be retrieved by another client, with no requirements on the part of the server. +**Note:** Review Comment: I suggest to add a new line after the Note so that it is clear that the contents of the note are several paragraphs and not only the first one. ## geode-docs/developing/data_serialization/PDX_Serialization_Features.html.md.erb: ## @@ -31,6 +31,33 @@ When you serialize an object using PDX, <%=vars.product_name%> stores the object This centralization of object type information is advantageous for client/server installations in which clients and servers are written in different languages. Clients pass registry information to servers automatically when they store a PDX serialized object. Clients can run queries and functions against the data in the servers without compatibility between server and the stored objects. One client can store data on the server to be retrieved by another client, with no requirements on the part of the server. +**Note:** +There are situations where some of the information in the central registry of the PDX domain object metadata is lost, e.g. when restoring an old backup with an outdated central registry. + +When that happens, new clients connecting to the cluster for the first time will get outdated PDX type information from the central registry, but, since information in the central registry is cached by clients, old clients may have fresher information about PDX types than the central registry does. That will result into inconsistent information about PDX types spread across the system: + +- old clients have fresh information +- the central registry has outdated information +- new clients have outdated information + +If old clients write entries of a PDX type they know but the central registry doesn't, new clients will get "Unknown PDX type" errors when they read those objects. + +To avoid this problem, clients may be configured with the system property in the table below to clear their PDX type cache when they disconnect from the cluster. After clearing their cache, old clients will re-generate type information for all PDX types, including the types the central registry "forgot". Since new PDX type information will be written in the central registry before entries of that type are written in the cluster, the central registry and all clients, old and new, will store consistent PDX type information. + +| Name | Description | Default | +|---|-|-| +| `gemfire.ON_DISCONNECT_CLEAR_PDXTYPEIDS` | Clear pdxType ids when client disconnects from servers. | `false` | +- In the API, set the System properties before the cache creation call. Example: + +``` pre +System.setProperty(PoolImpl.ON_DISCONNECT_CLEAR_PDXTYPEIDS, "true"); +``` +- At the java command line, pass in System properties using the -D switch. Example: + +``` pre +java -Dgemfire.ON_DISCONNECT_CLEAR_PDXTYPEIDS=true +``` + Review Comment: I would not include here how to set the variable in the different clients. Otherwise, you would also have to add the way to set the property in the native client. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [geode] wabp2005 commented on a diff in pull request #7861: GEODE-10423: Document the system property “ON_DISCONNECT_CLEAR_PDXTYP…
wabp2005 commented on code in PR #7861: URL: https://github.com/apache/geode/pull/7861#discussion_r983108512 ## geode-docs/developing/data_serialization/PDX_Serialization_Features.html.md.erb: ## @@ -31,6 +31,31 @@ When you serialize an object using PDX, <%=vars.product_name%> stores the object This centralization of object type information is advantageous for client/server installations in which clients and servers are written in different languages. Clients pass registry information to servers automatically when they store a PDX serialized object. Clients can run queries and functions against the data in the servers without compatibility between server and the stored objects. One client can store data on the server to be retrieved by another client, with no requirements on the part of the server. +**Note:** +In some cases pdx registry may be lost, the cases include but not limited to the following: + +- A backup was restored, and such backup is missing pdx registry. Review Comment: Hi Miguel, thanks for your comment, I have pushed the new commit according to your suggestion. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@geode.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
