Re: Complex Objects Partially Expiring?

Hi Zac,

This is very unusual behaviour. Are you using the JCS lateral or remote
cache option or are you maintaining independent caches on all servers in
the cluster?

JCS by default uses standard Java serialization to transfer objects
between JVMs, it doesn't look inside your objects or do anything special
to objects as far as I know. Whether you're storing a simple object or
an object to which a large graph of other objects is attached, Java
serialization should take care of it.

It sounds like a serialization/deserialization issue. Do any of your
objects:
- have 'transient' fields
- use weak or soft references
- implement custom readObject or writeObject methods for serialization
- store state in static fields

You can check the items above if you're using JCS clustering or disk
cache options: lateral or remote cache, indexed disk cache etc. These
are JCS options which require that objects leave the JVM and so require
objects to be serialized.

If you've instead configured *independent* JCS object caches on each
server in the cluster then JCS would have no need to serialize your
objects in the first place. Without serialization JCS won't ever be
"copying" your objects. In this case when you "put" an object into the
cache you're really just storing a reference to that object in the
cache. Usually your application should then drop any other references it
holds to that object.

If your application does not drop other references to objects once it
has put them into the cache, then your application code could continue
to modify objects already stored in the cache via another reference.
This would be a bad bug in the application- if your application held
additional references to objects, when the cache evicts objects they
would not be garbage collected defeating the purpose of the cache. But
more to the point, your application could inadvertently continue to
modify objects in the cache causing the behaviour you are seeing.

Actually this last point could apply to situations where you are using
JCS serialization to share objects between servers too. It could affect
"originating" servers; servers which initially "put" objects into the
cache, as within the originating JVM your application could continue to
modify objects in that JVM's cache. Other servers would see an earlier
snapshot of objects, approximately from the point at which they were put
into the cache (it's asynchronous).

To test if your application might be holding references, as a temporary
measure you could try deep-cloning objects before putting them into the
cache. That way you'd be guaranteed that what you put into the cache you
should be able to get out of the cache in all cases:
http://weblogs.java.net/blog/emcmanus/archive/2007/04/cloning_java_ob.html

Anyway above are just suggestions. It could of course be something
entirely different, but anyway I hope you get it sorted.

Kind regards,
Niall

On Tue, 2009-03-10 at 15:01 -0600, Zachary Bradshaw wrote:

> Hi, I'm new to JCS dev and wanted to know if anyone else had  
> experienced this problem:  we've got a cluster of production servers  
> running JCS in LRUMemory mode, which we're using to store fairly  
> dense, heavily nested complex objects.  A strange thing is happening  
> whereby sometimes I will pull an object out of the cache, and one of  
> its child collections is empty, and I was wondering if perhaps JCS was  
> dropping this data due to expiration or space management policies?  It  
> seems strange that only part of a cached object would be released, but  
> I want to be certain one way or another (there are other possibilities  
> I'm looking into too).
> 
> Any feedback is appreciated!
> 
> Thanks,
> Zac
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]