[
https://issues.apache.org/jira/browse/IGNITE-5966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-5966:
------------------------------------
Fix Version/s: (was: 2.3)
> IgniteCache#get() fails with "Requesting mapping from grid failed" when
> deserialising binary object loaded from CacheJdbcPojoStoreFactory
> -----------------------------------------------------------------------------------------------------------------------------------------
>
> Key: IGNITE-5966
> URL: https://issues.apache.org/jira/browse/IGNITE-5966
> Project: Ignite
> Issue Type: Bug
> Environment: Ignite 2.1.4
> Reporter: Alexey Kukushkin
> Assignee: Alexey Kukushkin
>
> STEPS TO REPRODUCE
> 1. A running MySQL database with at least one table with an Integer key and
> some data
> 2. Use WebConsole to automatically generate an Ignite project from the RDBMS.
> In the WebConsole add a cache for the table containing data
> 3. Build the project
> 4. Start the cluster (run ServerNodeSpringStartup)
> 5. Load the data (run LoadCaches)
> 6. Run simple "get data" code against the running cluster with the data
> loaded. Make sure you do NOT keep binary and do NOT put anything to the cache
> except loading data on step #5. For example, if the cache is "AircraftCache",
> the type is "Aircraft" and a row with ID 1 exists in the DB, then:
> IgniteCache<Integer, Aircraft> aircraftCache =
> ignite.getOrCreateCache("AircraftCache");
> System.out.format("1->%s\n", aircraftCache.get(1));
> EXPECTED:
> 1...5: Project is generated, cluster runs, data is loaded
> 6: The entry with ID 1 is output to the console
> ACTUAL:"
> 1..5: As expected
> 6: javax.cache.CacheException: class
> org.apache.ignite.IgniteCheckedException: Requesting mapping from grid failed
> for [platformId=0, typeId=-1267085398]
> ANALYSIS
> The “typeId -> MappedName” mappings are stored in the
> MarshallerContextImpl$allCaches[platformId] map.
> My understanding is according to the existing implementations it is expected
> the mapping will always be registered when BinaryContext#descriptorForClass()
> -> MarshallerContextImpl#registerClassName(typeId) is called either from
> BinaryWriterExImpl or BinaryReaderExImpl.
> However, that mechanism is never called when
> CacheJdbcPojoStore@buildBinaryObject builds the object, calling
> BinaryObjectBuilderImpl#build(). The latter method still requests
> BinaryContext#updateMetadata, which updates
> CacheObjectBinaryProcessorImpl#metadataFileStore on all server nodes. But the
> metadataFileStore is not the place where MarshallerContextImpl get mappings
> from.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
