geode-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darrel Schneider (Jira)" <>
Subject [jira] [Commented] (GEODE-7394) Gfsh `configure pdx` command is non-intuitive and currently has a bad user experience
Date Fri, 01 Nov 2019 20:52:00 GMT


Darrel Schneider commented on GEODE-7394:

I don't think this statement is true: "Without a PdxSerializer the command essentially serves
no purpose nor has any effect".
Pdx serialization can be used without a PdxSerializer. Domain classes can implement the PdxSerializable
Also, even if you are using a PdxSerializer, you may not need to have it on your server. If
you set --read-serialized=true on the server then it should never need to use the PdxSerializer
on the server even though it is used on the client.
In the above use cases you may still want to set --read-serialized or --ignore-unread-fields
or the pdx disk store and the configure pdx command allows you to do that.

The ReflectionBasedAutoSerializer is the easiest way to use pdx provided by geode. My understanding
is that one of the Spring projects has its own PdxSerializer that works better with Spring
than the ReflectionBasedAutoSerializer. I know we have had requests before for the default
to be ReflectionBasedAutoSerializer with the .* REGEX. But I think one of the current problems
we have with that is that if you have a ReflectionBasedAutoSerializer whose regex matches
that class name then that serialization takes precedence over other forms of serialization.
So you could have a JDK class that has its own special serialization code suddenly ignored
by geode serialization and instead it would be serialized by PDX. That could cause performance
issues, correctness issues, and compatibility issues.
Maybe we could enhance the PdxSerializer to have two stages in the serialization precedence.
The first state would ask it early if it wants to serialize a class before all other serialization
frameworks. If that request is turned down it would then check the other ways of doing serialization
like it currently does. But a new stage at the end could be added after we have not found
any way to serialize an object. That would be to ask the PdxSerializer to attempt serialization
as a last ditch attempt. Maybe this "last ditch attempt" could just be hardcoded into our
serialization precedence with no need for the user to even configure a PdxSerializer. We could
just try all the current ways we have and if none of them work ask our built in ReflectionBasedAutoSerializer
with a REGEX of .* to give it a try.

> Gfsh `configure pdx` command is non-intuitive and currently has a bad user experience
> -------------------------------------------------------------------------------------
>                 Key: GEODE-7394
>                 URL:
>             Project: Geode
>          Issue Type: Bug
>          Components: serialization
>            Reporter: John Blum
>            Priority: Major
> The _Gfsh_ {{configure pdx}} command does *not* register a {{PdxSerializer}} (e.g. {{ReflectionBasedAutoSerializer}},
or otherwise) unless the {{--auto-serializable-classes}} option is explicitly specified. 
Without a {{PdxSerializer}} the command essentially serves no purpose nor has any effect.
 Effectively, the command is useless.
> For example, doing something like `gfsh> configure pdx --read-serialized=false` or
`gfsh> configure pdx --ignore-unread-fields` by itself is *pointless* since ultimately
there would be no `PdxSerializer` registered in this case.
> _Gfsh_ should minimally register a `PdxSerializer` anytime the `configure pdx` command
is used regardless of the options provided, especially if it returns successfully without
incident.  For instance, it could register the `ReflectionBaseAutoSerializer` with the REGEX
{{.*}} (de/serializing all types, regardless of whether that is optimal or not).
> Alternatively, if we decide not to register the {{ReflectionBasedAutoSerialier}} with
a generic REGEX (e.g. {{.*}}), then we should _fail-fast_ and the command should report that
{{--[portable-]-auto-serializable-classes}} is required!

This message was sent by Atlassian Jira

View raw message