wabp2005 commented on code in PR #7861:
URL: https://github.com/apache/geode/pull/7861#discussion_r984280585
##########
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:
Regarding Java client, there are two kinds of properties:
- GemFire Properties, user can define this kind of properties either in
gemfire.properties file or programmatically (such as:
clientCacheFactory.set(key, value)).
- GemFire System Properties, user can only define this kind properties by
setting Java System Properties.
The property `gemfire.ON_DISCONNECT_CLEAR_PDXTYPEIDS` is the Java System
Property, it cannot be set with API or in file `gemfire.properties`, so I think
this property should not be added in the `gemfire_properties.html`, since they
have the different way to be set, it would make user confused.
But regarding the native client, there is only one way to set properties,
all the properties could be found in `apache::geode::client::SystemProperties`,
and the properties could be define either programmatically (such as:
`CacheFactory().set("on-client-disconnect-clear-pdxType-Ids", "true")`
) or in a geode.properties file, so I suggest that we only list the
property here, but not include how to set it, how do you think?
I have pushed the new change, please take a look at it ,thanks!
--
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
