Added, thanks
Kamil
--
View this message in context:
http://apache-ignite-users.70518.x6.nabble.com/SpiQuery-fails-with-exception-tp3615p3646.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Hi Val -
There are a few more potential issues we noticed when using Spi indexing in
1.5.0.final:
- method query() in IndexingSpi interface returns
Iterator> but elements of type Map.Entry are expected
further down the stack (i.e. in IgniteCacheProxy:528). We had to create type
that extends both
Hi Val,
Exception is thrown every time we run a query or, more specifically, when we
start to iterate on result QueryCursor.
Please find server and client node code snippet with configuration and SPI
query.
// server node
Ignite igniteServerNode = Ignitions.start(new IgniteConfiguration()
(.
Hi,
We’ve setup custom IndexSpi but when trying to run SpiQuery exception below
shows up. Is there anything we’re missing?
Worth adding that after excluding this validation for SPI queries (at
GridCacheQueryManager.java:663) all seem to be working as expected. Ignite
version - 1.5.0.final.
cla
Thanks Vladmir. Unfortunately we need write-through to guarantee persistence.
Which means we'll need to modify approach so that client nodes are allowed
to write to the store.
You also wrote that ATOMIC cache doesn't give any transactional guarantees.
Does it mean that if we have write-through cac
Makes sense, thanks.
Kamil
--
View this message in context:
http://apache-ignite-users.70518.x6.nabble.com/CacheStore-handles-persistence-in-client-node-for-transactional-cache-tp3428p3575.html
Sent from the Apache Ignite Users mailing list archive at Nabble.com.
Hi,
We configured partitioned, transactional cache with server and client nodes
and CacheStore which handles write-through persistence. It seems that,
however, in such model persistence logic (i.e. CacheStore.write() methods)
can be invoked in client node for certain scenarios.
After browsing p
