Hi Amit, In fact this is expected behavior because once an object is serialized and stored in a cache it’s metadata is placed in one of the internal caches and won’t be cleaned out of there until the cluster is fully restarted. The reason of this is because an object type is not bound to a particular cache meaning that a serialized object can be stored in different caches or just being transferred between cluster nodes.
Answering on your questions. > 1. I wanted to understand if this is the same bug as noted here - > https://issues.apache.org/jira/browse/IGNITE-2779 > No, it’s not related to this issues and this is not a bug as I described above. > 2. It seems ignite starts reading the metadata in the background even before > Ignite instance is created. Where does it read the metadata from? > Metadata is accessed whenever an object is being serialized (and its metadata hash number has changed ) or deserialized. > 3. Is this metadata cache created only for ignite client nodes? > Metadata cache is a replicated cache stored on all the server nodes. In addition client nodes and server nodes store a local map of this metadata cache for faster access. > 4. Would this issue be seen only when dealing with binary objects? Correct. — Denis > On Jun 22, 2016, at 4:50 PM, pragmaticbigdata <[email protected]> wrote: > > I think I came across a bug while working with binary objects in ignite > (version 1.6). The steps are > > 1. Create a cache with BinaryObject as the value. Add a field and a String > value in it. > 2. Destroy the cache using ignite.destroyCache(c) > 3. Create the same cache but this time add the same field with a Double > value in it. > > Ignite fails with an exception > > Exception in thread "main" class > org.apache.ignite.binary.BinaryObjectException: Wrong value has been set > [typeName=BinaryCacheTest_Type, fieldName=F1, fieldType=String, > assignedValueType=double] > at > org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.checkMetadata(BinaryObjectBuilderImpl.java:397) > at > org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.serializeTo(BinaryObjectBuilderImpl.java:313) > at > org.apache.ignite.internal.binary.builder.BinaryObjectBuilderImpl.build(BinaryObjectBuilderImpl.java:180) > > The code to reproduce this issue is > > private void load(Ignite ignite) { > String cacheName = "BinaryCacheTest"; > CacheConfiguration<String, BinaryObject> cfg = > getCacheConfig(cacheName); > IgniteCache<String, BinaryObject> igniteCache = > ignite.getOrCreateCache(cfg).withKeepBinary(); > BinaryObjectBuilder builder = ignite.binary().builder(cacheName + > "_Type"); > builder.setField("F1", 0.5d); > igniteCache.put(UUID.randomUUID().toString(), builder.build()); > } > > private CacheConfiguration<String, BinaryObject> getCacheConfig(String > cacheName) { > CacheConfiguration<String, BinaryObject> cfg = new > CacheConfiguration<>(); > cfg.setName(cacheName); > return cfg; > } > > > > 1. I wanted to understand if this is the same bug as noted here - > https://issues.apache.org/jira/browse/IGNITE-2779 > > 2. It seems ignite starts reading the metadata in the background even before > Ignite instance is created. Where does it read the metadata from? > > 3. Is this metadata cache created only for ignite client nodes? > > 4. Would this issue be seen only when dealing with binary objects? > > Thanks, > Amit. > > > > -- > View this message in context: > http://apache-ignite-users.70518.x6.nabble.com/Ignite-client-reads-old-metadata-even-after-cache-is-destroyed-and-recreated-tp5800.html > Sent from the Apache Ignite Users mailing list archive at Nabble.com.
