I think it would be a good idea to turn some of these into geode JIRAs.

For the persistent= option, the disk-store= parameter is the gfsh
equivalent. If you specify a disk store, persistence will be true. That
said, maybe having a persistent= option to reduce confusion would be a good
idea.

-Dan

On Fri, Nov 20, 2015 at 4:30 PM, Real Wes Williams <[email protected]>
wrote:

> Thanks for the question Udo.  The real goal of this is to make spinning up
> a cluster simple, simple, simple for admins new to Geode. A secondary goal
> to accomplish this is to dispense with XML to the extent possible and use
> gfsh configuration commands. The direction of Spring has been to move away
> from XML and this one of my motivations. Since this cannot be done
> completely at this point in time, we have to have a mix of overlapping
> commands that seem strange at first glance, which is at the heart of your
> question.
>
> Here are some wish-list items I wrote earlier today while dealing with the
> cluster configuration service and gfsh with PDX:
>
> Needs a list PDX
> Needs to support defining a pdf serializer
> Needs to support a persistent= option in configure pdx
> Stop turning persistent to “false” when configure pdf is run  (Dan
> commented on this).
>
> There is more.  The “simplest for developers” is probably to do everything
> in code.  “Simplest for Admins” is to keep pushing gfsh.
>
> The geode user list has not been sending responses to my email and so
> pardon the late reply. I happened to look online.
>
> Wes
>
>
> Udo wrote:
>
> The question is, what functionality are we expecting to see?
>
> If one has already defined PDX within the cache.xml file, then maybe any
> subsequent pdx calls should be seen as updates... Like adding classes to
> the auto-serialization config.
>
> Or maybe it should throw an exception where you should not be able to
> change the configuration of PDX once deployed.
> Not sure what they right answer should be.
>
> What it seems to be right now, that it replaces the existing
> configuration. So if you change the configuration and not specify the
> correct parameters, you would potentially alter the expected behavior.
>
> --Udo
>
>
>
> On Nov 19, 2015, at 10:48 PM, Real Wes Williams <[email protected]>
> wrote:
>
> resubmitting...
>
> Why does the gfsh> Configure Pdx command automatically revert the setting
> of “persistence” to false?
>
> Is this by design or a bug?
>
> I have pdf defined as persistent in cluster.xml.
>
>   <pdx read-serialized="true" persistent="true">
>     <pdx-serializer>
>
> Later, when executing scripts that include configure pdf, it turns off my
> persistence. I realize that configure pdx does not support
> —persistence=true but why turn it off?
>
> gfsh>configure pdx --read-serialized=true
> --portable-auto-serializable-classes="com.company.domain.*"
>
> The command would only take effect on new data members joining the
> distributed system. It won't affect the existing data members
>
> *persistent = false*
>
> read-serialized = true
>
> ignore-unread-fields = false
>
> PDX Serializer com.gemstone.gemfire.pdx.ReflectionBasedAutoSerializer
>
> Portable classes [com.company.domain.*]
>
>
>

Reply via email to