Design Guidance balancing ClassLoader conflicts, Cluster Configuration Service and Not Bouncing Clusters

[Real Wes Williams <Th...@outlook.com>]

What is an optimal configuration for a cluster to avoid shutting down the grid every time domain objects change?

Given a domain object DailyPrice with an interface Price in domain.jar and a function reading the domain object using its interface:

This works but requires the cluster to be shut down:
Scenario 1: domain.jar on system CLASSPATH, cluster shut down, domain.jar copied into locator/cluster_config/cluster, cluster restart
Results: Geode deploys the domain.jar and everything works fine.
Cost: Need to shut down rather than simply undeploy/ deploy.

Scenario 2: domain.jar on system CLASSPATH, cluster stays up, AND domain.jar undeploy/ deploy
Results: com.company.domain.DailyPrice cannot be cast to com.company.domain.Price

Scenario 3: domain.jar on gfsh start server —classpath=domain.jar AND domain.jar undeploy/ deploy
Results: com.company.domain.DailyPrice cannot be cast to com.company.domain.Price

Scenario 4: No classpath AND domain.jar undeploy/ deploy
Results: com.company.domain.DailyPrice cannot be cast to com.company.domain.Price

Scenario 5: no classpath, cluster shut down, domain.jar copied into locator/cluster_config/cluster, cluster restart
Results: com.company.domain.DailyPrice cannot be cast to com.company.domain.Price

Is there a way to avoid the class path conflict and avoid bouncing the cluster?

Thanks,
Wes

Re: Design Guidance balancing ClassLoader conflicts, Cluster Configuration Service and Not Bouncing Clusters

[Real Wes Williams <Th...@outlook.com>]

Jens,

PDX is turned on in both client and server.  I intentionally do not use read-serialized to keep PDX concerns out of the domain. 

Since PDX is turned on throughout the cluster with the auto serializer, I would expect serialization to occur automatically, even without read-serialized=true, since there are no changes in instance variables whether new adds, deletes or name changes.

I never had this trouble with using plain objects. However, introducing inheritance and interfaces seems to create a new wrinkle.  I’ll test using read-serialized = true but even if that works it seems that there’s a decision tradeoff in using interfaces vs the added effort of dealing with PDXInstance in code.

Thanks,
Wes Williams


> On Apr 1, 2016, at 7:19 PM, Jens Deppe <jd...@pivotal.io> wrote:
> 
> Wes,
> 
> In order to be able to update domain classes you will have to use PDX and read-serialized=true. Is that the case here?
> 
> With non-PDX setups, ensuring the serialized state of a domain object is not deterministic. Basically there is no way to always ensure that an object is in a particular state. As soon as an object is in a deserialized state, it is obviously associated with a class and thus with a specific classloader. If a new class is deployed that particular object will not automatically be rebuilt with the new class and classloader. That is why you're getting the cast exceptions.
> 
> In order to have more control you will have to use PDX. That way an object will be serialized every time getObject() is called on the PdxInstance. This would allow for updated domain classes to be used when the object is referenced/retrieved in this way.
> 
> HTH.
> 
> --Jens
> 
> 
> On Fri, Apr 1, 2016 at 12:59 PM, Real Wes Williams <TheRealWes@outlook.com <ma...@outlook.com>> wrote:
> 
> What is an optimal configuration for a cluster to avoid shutting down the grid every time domain objects change?
> 
> Given a domain object DailyPrice with an interface Price in domain.jar and a function reading the domain object using its interface:
> 
> This works but requires the cluster to be shut down:
> Scenario 1: domain.jar on system CLASSPATH, cluster shut down, domain.jar copied into locator/cluster_config/cluster, cluster restart
> Results: Geode deploys the domain.jar and everything works fine.
> Cost: Need to shut down rather than simply undeploy/ deploy.
> 
> Scenario 2: domain.jar on system CLASSPATH, cluster stays up, AND domain.jar undeploy/ deploy
> Results: com.company.domain.DailyPrice cannot be cast to com.company.domain.Price
> 
> Scenario 3: domain.jar on gfsh start server —classpath=domain.jar AND domain.jar undeploy/ deploy
> Results: com.company.domain.DailyPrice cannot be cast to com.company.domain.Price
> 
> Scenario 4: No classpath AND domain.jar undeploy/ deploy
> Results: com.company.domain.DailyPrice cannot be cast to com.company.domain.Price
> 
> Scenario 5: no classpath, cluster shut down, domain.jar copied into locator/cluster_config/cluster, cluster restart
> Results: com.company.domain.DailyPrice cannot be cast to com.company.domain.Price
> 
> Is there a way to avoid the class path conflict and avoid bouncing the cluster?
> 
> Thanks,
> Wes
> 

Re: Design Guidance balancing ClassLoader conflicts, Cluster Configuration Service and Not Bouncing Clusters

[Jens Deppe <jd...@pivotal.io>]

Wes,

In order to be able to update domain classes you will have to use PDX and
read-serialized=true. Is that the case here?

With non-PDX setups, ensuring the serialized state of a domain object is
not deterministic. Basically there is no way to always ensure that an
object is in a particular state. As soon as an object is in a deserialized
state, it is obviously associated with a class and thus with a specific
classloader. If a new class is deployed that particular object will not
automatically be rebuilt with the new class and classloader. That is why
you're getting the cast exceptions.

In order to have more control you will have to use PDX. That way an object
will be serialized every time getObject() is called on the PdxInstance.
This would allow for updated domain classes to be used when the object is
referenced/retrieved in this way.

HTH.

--Jens


On Fri, Apr 1, 2016 at 12:59 PM, Real Wes Williams <Th...@outlook.com>
wrote:

>
> What is an optimal configuration for a cluster to avoid shutting down the
> grid every time domain objects change?
>
> Given a domain object DailyPrice with an interface Price in domain.jar and
> a function reading the domain object using its interface:
>
> This works but requires the cluster to be shut down:
> *Scenario 1: domain.jar on system CLASSPATH, cluster shut down, domain.jar
> copied into locator/cluster_config/cluster**, cluster restart*
> *Results: *Geode deploys the domain.jar and everything works fine.
> *Cost:* Need to shut down rather than simply undeploy/ deploy.
>
> *Scenario 2: domain.jar on system CLASSPATH, cluster stays up, **AND
> domain.jar undeploy/ deploy*
> *Results: *com.company.domain.DailyPrice cannot be cast to
> com.company.domain.Price
>
> *Scenario 3: domain.jar on gfsh start server —classpath=domain.jar AND
> domain.jar undeploy/ deploy*
> *Results: *com.company.domain.DailyPrice cannot be cast to
> com.company.domain.Price
>
> *Scenario 4: No classpath AND domain.jar undeploy/ deploy*
> *Results: *com.company.domain.DailyPrice cannot be cast to
> com.company.domain.Price
>
> *Scenario 5: no **classpath**, cluster shut down, domain.jar copied into
> locator/cluster_config/cluster, cluster restart*
> *Results: *com.company.domain.DailyPrice cannot be cast to
> com.company.domain.Price
>
> Is there a way to avoid the class path conflict and avoid bouncing the
> cluster?
>
> Thanks,
> Wes
>