You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ignite.apache.org by "aaron@tophold.com" <aa...@tophold.com> on 2017/11/08 10:52:10 UTC
When client node query a cache with JDBC storage, report miss the dataSourceBean
hi All,
My server side cache configuration with JDBC storage as back-end. whose data source refer to a bean "serverDatasource" from server spring context.
While a pure client node to fetch data from the server, it always report:
GridCachePartitionExchangeManager - Failed to process custom exchange task: ClientCacheChangeDummyDiscoveryMessage [reqId=1ffc2697-6548-49b3-9c
ac-a3c8a8672770, cachesToClose=null, startCaches=[ProductEntry]]
org.apache.ignite.IgniteException: Failed to load bean in application context [beanName=serverDatasource, igniteConfig=org.springframework.boot.context.embedded.AnnotationConfigEmbeddedWebApplicationContex
t@2667f029: startup date [Wed Nov 08 10:36:06 UTC 2017]; root of context hierarchy]
at org.apache.ignite.cache.store.jdbc.CacheJdbcPojoStoreFactory.create(CacheJdbcPojoStoreFactory.java:183) ~[ignite-core-2.3.0.jar!/:2.3.0]
at org.apache.ignite.cache.store.jdbc.CacheJdbcPojoStoreFactory.create(CacheJdbcPojoStoreFactory.java:100) ~[ignite-core-2.3.0.jar!/:2.3.0]
at org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCache(GridCacheProcessor.java:1318) ~[ignite-core-2.3.0.jar!/:2.3.0]
at org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1799) ~[ignite-core-2.3.0.jar!/:2.3.0]
at org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCacheStartRequests(CacheAffinitySharedManager.java:428) ~[ignite-core-2.3.0.jar!/:2.3.0]
at org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCachesChanges(CacheAffinitySharedManager.java:611) ~[ignite-core-2.3.0.jar!/:2.3.0]
at org.apache.ignite.internal.processors.cache.GridCacheProcessor.processCustomExchangeTask(GridCacheProcessor.java:338) ~[ignite-core-2.3.0.jar!/:2.3.0]
at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.processCustomTask(GridCachePartitionExchangeManager.java:2142) ~[ignite-core-2.3.0.jar!/:2.3.0]
at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2231) ~[ignite-core-2.3.0.jar!/:2.3.0]
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) ~[ignite-core-2.3.0.jar!/:2.3.0]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_131]
The client side never ever should have this "serverDatasource" in its context, also client suppose not to touch this DB.
Client as : <property name="clientMode" value="true"/>
Could you please advice, how suppose can we stop this check? even trigger a read/write through, this suppose performed by the Server side? not the client right?
BTW I already set: System.setProperty(org.apache.ignite.IgniteSystemProperties.IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK, "true"); but this not work.
Thanks for your time
Regards
Aaron
aaron@tophold.com
Re: Re: When client node query a cache with JDBC storage, report miss
the dataSourceBean
Posted by Ilya Kasnacheev <il...@gmail.com>.
Hello Aaron!
You can use thin JDBC driver for query only without the need to instantiate
cacheStoreFactory on client.
Regards,
--
Ilya Kasnacheev
2017-11-09 4:34 GMT+03:00 aaron@tophold.com <aa...@tophold.com>:
> Got it thanks Ilya!
>
> So if we try to totally isolate the client from server, may need start a
> facade to supply query only service.
>
> Regards
> Aaron
> ------------------------------
> aaron@tophold.com
>
>
> *From:* Ilya Kasnacheev <il...@gmail.com>
> *Date:* 2017-11-08 19:57
> *To:* user <us...@ignite.apache.org>
> *Subject:* Re: When client node query a cache with JDBC storage, report
> miss the dataSourceBean
> Hello Aaron!
>
> - In Ignite, client nodes are always aware of backed storage
> (cacheStoreFactory) of all caches. This is by design.
>
> - In Ignite, client nodes perform operations on backed storage DB for
> transactional caches.
> The reasoning here is that transaction commit has to happen in one place,
> and that place is the client which initiated transaction.
> Otherwise there's no reliable way to make sure that backing
> non-distributed DB is updated (or rolled back) properly.
>
> - For atomic caches, client nodes should not be using cacheStore to talk
> to DB but still instantiate it in full.
>
> Please make sure that client has all the beans required for cacheStore
> operation.
>
> --
> Ilya Kasnacheev
>
> 2017-11-08 13:52 GMT+03:00 aaron@tophold.com <aa...@tophold.com>:
>
>> hi All,
>>
>> My server side cache configuration with JDBC storage as back-end. whose
>> data source refer to a bean "serverDatasource" from server spring context.
>>
>> While a pure client node to fetch data from the server, it always report:
>>
>>
>> GridCachePartitionExchangeManager -
>> * Failed to process custom exchange task*: ClientCacheCha
>> ngeDummyDiscoveryMessage [reqId=1ffc2697-6548-49b3-9c
>> ac-a3c8a8672770, cachesToClose=null, startCaches=[ProductEntry]]
>> org.apache.ignite.IgniteException: Failed to load bean in
>> application context [beanName=*serverDatasource*,
>> igniteConfig=org.springframework.boot.context.embedded.Annot
>> ationConfigEmbeddedWebApplicationContex
>> t@2667f029: startup date [Wed Nov 08 10:36:06 UTC 2017]; roo
>> t of context hierarchy]
>> at org.apache.ignite.cache.store.jdbc.CacheJdbcPojoStoreFact
>> ory.create(CacheJdbcPojoStoreFactory.java:183) ~[ignite-
>> core-2.3.0.jar!/:2.3.0]
>> at org.apache.ignite.cache.store.jdbc.CacheJdbcPojoStoreFact
>> ory.create(CacheJdbcPojoStoreFactory.java:100) ~[ignite-
>> core-2.3.0.jar!/:2.3.0]
>> at org.apache.ignite.internal.processors.cache.GridCacheProc
>> essor.createCache(GridCacheProcessor.java:1318) ~[ignite-
>> core-2.3.0.jar!/:2.3.0]
>> at org.apache.ignite.internal.processors.cache.GridCacheProc
>> essor.prepareCacheStart(GridCacheProcessor.java:1799) ~[
>> ignite-core-2.3.0.jar!/:2.3.0]
>> at org.apache.ignite.internal.processors.cache.CacheAffinity
>> SharedManager.processClientCacheStartRequests(
>> CacheAffinitySharedManager.java:428) ~[ignite-core-2.3.0.jar!/:2.3.0]
>> at org.apache.ignite.internal.processors.cache.CacheAffinity
>> SharedManager.processClientCachesChanges(CacheAffinityShared
>> Manager.java:611) ~[ignite-core-2.3.0.jar!/:2.3.0]
>> at org.apache.ignite.internal.processors.cache.GridCacheProc
>> essor.processCustomExchangeTask(GridCacheProcessor.java:338)
>> ~[ignite-core-2.3.0.jar!/:2.3.0]
>> at org.apache.ignite.internal.processors.cache.GridCachePart
>> itionExchangeManager$ExchangeWorker.processCustomTa
>> sk(GridCachePartitionExchangeManager.java:2142) ~[ignite-
>> core-2.3.0.jar!/:2.3.0]
>> at org.apache.ignite.internal.processors.cache.GridCachePart
>> itionExchangeManager$ExchangeWorker.body(GridCacheP
>> artitionExchangeManager.java:2231) ~[ignite-core-2.3.0.jar!/:2.3.0]
>> at org.apache.ignite.internal.util.worker.GridWorker.run(Gri
>> dWorker.java:110) ~[ignite-core-2.3.0.jar!/:2.3.0]
>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_131]
>>
>> The client side never ever should have this "serverDatasource" in its
>> context, also client suppose not to touch this DB.
>>
>> Client as : <property name="clientMode" value="true"/>
>>
>> Could you please advice, how suppose can we stop this check? even
>> trigger a read/write through, this suppose performed by the Server side?
>> not the client right?
>>
>> BTW I already set: System.setProperty(org.ap
>> ache.ignite.IgniteSystemProperties.IGNITE_SKIP_CONFIGURATION_CONSISTENCY_
>> CHECK, "true"); but this not work.
>>
>> Thanks for your time
>>
>> Regards
>> Aaron
>> ------------------------------
>> aaron@tophold.com
>>
>
>
Re: Re: When client node query a cache with JDBC storage, report miss the dataSourceBean
Posted by "aaron@tophold.com" <aa...@tophold.com>.
Got it thanks Ilya!
So if we try to totally isolate the client from server, may need start a facade to supply query only service.
Regards
Aaron
aaron@tophold.com
From: Ilya Kasnacheev
Date: 2017-11-08 19:57
To: user
Subject: Re: When client node query a cache with JDBC storage, report miss the dataSourceBean
Hello Aaron!
- In Ignite, client nodes are always aware of backed storage (cacheStoreFactory) of all caches. This is by design.
- In Ignite, client nodes perform operations on backed storage DB for transactional caches.
The reasoning here is that transaction commit has to happen in one place, and that place is the client which initiated transaction.
Otherwise there's no reliable way to make sure that backing non-distributed DB is updated (or rolled back) properly.
- For atomic caches, client nodes should not be using cacheStore to talk to DB but still instantiate it in full.
Please make sure that client has all the beans required for cacheStore operation.
--
Ilya Kasnacheev
2017-11-08 13:52 GMT+03:00 aaron@tophold.com <aa...@tophold.com>:
hi All,
My server side cache configuration with JDBC storage as back-end. whose data source refer to a bean "serverDatasource" from server spring context.
While a pure client node to fetch data from the server, it always report:
GridCachePartitionExchangeManager - Failed to process custom exchange task: ClientCacheChangeDummyDiscoveryMessage [reqId=1ffc2697-6548-49b3-9c
ac-a3c8a8672770, cachesToClose=null, startCaches=[ProductEntry]]
org.apache.ignite.IgniteException: Failed to load bean in application context [beanName=serverDatasource, igniteConfig=org.springframework.boot.context.embedded.AnnotationConfigEmbeddedWebApplicationContex
t@2667f029: startup date [Wed Nov 08 10:36:06 UTC 2017]; root of context hierarchy]
at org.apache.ignite.cache.store.jdbc.CacheJdbcPojoStoreFactory.create(CacheJdbcPojoStoreFactory.java:183) ~[ignite-core-2.3.0.jar!/:2.3.0]
at org.apache.ignite.cache.store.jdbc.CacheJdbcPojoStoreFactory.create(CacheJdbcPojoStoreFactory.java:100) ~[ignite-core-2.3.0.jar!/:2.3.0]
at org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCache(GridCacheProcessor.java:1318) ~[ignite-core-2.3.0.jar!/:2.3.0]
at org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1799) ~[ignite-core-2.3.0.jar!/:2.3.0]
at org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCacheStartRequests(CacheAffinitySharedManager.java:428) ~[ignite-core-2.3.0.jar!/:2.3.0]
at org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processClientCachesChanges(CacheAffinitySharedManager.java:611) ~[ignite-core-2.3.0.jar!/:2.3.0]
at org.apache.ignite.internal.processors.cache.GridCacheProcessor.processCustomExchangeTask(GridCacheProcessor.java:338) ~[ignite-core-2.3.0.jar!/:2.3.0]
at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.processCustomTask(GridCachePartitionExchangeManager.java:2142) ~[ignite-core-2.3.0.jar!/:2.3.0]
at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2231) ~[ignite-core-2.3.0.jar!/:2.3.0]
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110) ~[ignite-core-2.3.0.jar!/:2.3.0]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_131]
The client side never ever should have this "serverDatasource" in its context, also client suppose not to touch this DB.
Client as : <property name="clientMode" value="true"/>
Could you please advice, how suppose can we stop this check? even trigger a read/write through, this suppose performed by the Server side? not the client right?
BTW I already set: System.setProperty(org.apache.ignite.IgniteSystemProperties.IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK, "true"); but this not work.
Thanks for your time
Regards
Aaron
aaron@tophold.com
Re: When client node query a cache with JDBC storage, report miss the dataSourceBean
Posted by Ilya Kasnacheev <il...@gmail.com>.
Hello Aaron!
- In Ignite, client nodes are always aware of backed storage
(cacheStoreFactory) of all caches. This is by design.
- In Ignite, client nodes perform operations on backed storage DB for
transactional caches.
The reasoning here is that transaction commit has to happen in one place,
and that place is the client which initiated transaction.
Otherwise there's no reliable way to make sure that backing non-distributed
DB is updated (or rolled back) properly.
- For atomic caches, client nodes should not be using cacheStore to talk to
DB but still instantiate it in full.
Please make sure that client has all the beans required for cacheStore
operation.
--
Ilya Kasnacheev
2017-11-08 13:52 GMT+03:00 aaron@tophold.com <aa...@tophold.com>:
> hi All,
>
> My server side cache configuration with JDBC storage as back-end. whose
> data source refer to a bean "serverDatasource" from server spring context.
>
> While a pure client node to fetch data from the server, it always report:
>
>
> GridCachePartitionExchangeManager -
> * Failed to process custom exchange task*: ClientCacheChangeDummyDiscover
> yMessage [reqId=1ffc2697-6548-49b3-9c
> ac-a3c8a8672770, cachesToClose=null, startCaches=[ProductEntry]]
> org.apache.ignite.IgniteException: Failed to load bean in application
> context [beanName=*serverDatasource*, igniteConfig=org.
> springframework.boot.context.embedded.AnnotationConfigEmbeddedWebApp
> licationContex
> t@2667f029: startup date [Wed Nov 08 10:36:06 UTC 2017];
> root of context hierarchy]
> at org.apache.ignite.cache.store.jdbc.CacheJdbcPojoStoreFactory.create(
> CacheJdbcPojoStoreFactory.java:183) ~[ignite-core-2.3.0.jar!/:2.3.0]
> at org.apache.ignite.cache.store.jdbc.CacheJdbcPojoStoreFactory.create(
> CacheJdbcPojoStoreFactory.java:100) ~[ignite-core-2.3.0.jar!/:2.3.0]
> at org.apache.ignite.internal.processors.cache.GridCacheProcessor.
> createCache(GridCacheProcessor.java:1318) ~[ignite-core-2.3.0.jar!/:2.3.0]
> at org.apache.ignite.internal.processors.cache.GridCacheProcessor.
> prepareCacheStart(GridCacheProcessor.java:1799)
> ~[ignite-core-2.3.0.jar!/:2.3.0]
> at org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.
> processClientCacheStartRequests(CacheAffinitySharedManager.
> java:428) ~[ignite-core-2.3.0.jar!/:2.3.0]
> at org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.
> processClientCachesChanges(CacheAffinitySharedManager.
> java:611) ~[ignite-core-2.3.0.jar!/:2.3.0]
> at org.apache.ignite.internal.processors.cache.GridCacheProcessor.
> processCustomExchangeTask(GridCacheProcessor.java:338) ~
> [ignite-core-2.3.0.jar!/:2.3.0]
> at org.apache.ignite.internal.processors.cache.
> GridCachePartitionExchangeManager$ExchangeWorker.processCustomTask(
> GridCachePartitionExchangeManager.java:2142) ~[ignite-core-
> 2.3.0.jar!/:2.3.0]
> at org.apache.ignite.internal.processors.cache.
> GridCachePartitionExchangeManager$ExchangeWorker.body(
> GridCachePartitionExchangeManager.java:2231) ~[ignite-core-
> 2.3.0.jar!/:2.3.0]
> at org.apache.ignite.internal.util.worker.GridWorker.run(
> GridWorker.java:110) ~[ignite-core-2.3.0.jar!/:2.3.0]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_131]
>
> The client side never ever should have this "serverDatasource" in its
> context, also client suppose not to touch this DB.
>
> Client as : <property name="clientMode" value="true"/>
>
> Could you please advice, how suppose can we stop this check? even trigger
> a read/write through, this suppose performed by the Server side? not the
> client right?
>
> BTW I already set: System.setProperty(org.apache.ignite.
> IgniteSystemProperties.IGNITE_SKIP_CONFIGURATION_CONSISTENCY_CHECK, "true"
> ); but this not work.
>
> Thanks for your time
>
> Regards
> Aaron
> ------------------------------
> aaron@tophold.com
>