Alexey Kukushkin created IGNITE-5966:
----------------------------------------
Summary: 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)
