Re: Ignite for Configuration Database
Clay, thanks for clarifying. That's Ignite's use case. I'm aware of some companies that use Ignite similarly but cannot disclose the names. How are you planning to query data - SQL, compute tasks any other APIs? - Denis On Wed, Jan 8, 2020 at 4:29 PM Clay Teahouse wrote: > Hello Denis, > > I mean a database that hosts the information about sites (e.g., hotels) > and devices located the sites (e.g., hardware, software, configuration, > labels, geolocation), there can be 1000s of sites with each site having > many devices, totaling 100s of 1000s entries. The data is not volatile and > we don't have to keep track of the changes in the same database. > > thanks > Clay > > On Wed, Jan 8, 2020 at 3:12 PM Denis Magda wrote: > >> Hi Clay, >> >> Could you please elaborate on the technical requirements of this usage >> scenario? >> >> - >> Denis >> >> >> On Wed, Jan 8, 2020 at 8:30 AM Clay Teahouse >> wrote: >> >>> Hello All, >>> >>> What are the pros and cons of using ignite as an asset and configuration >>> database? >>> >>> thanks, >>> Clay >>> >>
Re: Ignite for Configuration Database
Hello Denis, I mean a database that hosts the information about sites (e.g., hotels) and devices located the sites (e.g., hardware, software, configuration, labels, geolocation), there can be 1000s of sites with each site having many devices, totaling 100s of 1000s entries. The data is not volatile and we don't have to keep track of the changes in the same database. thanks Clay On Wed, Jan 8, 2020 at 3:12 PM Denis Magda wrote: > Hi Clay, > > Could you please elaborate on the technical requirements of this usage > scenario? > > - > Denis > > > On Wed, Jan 8, 2020 at 8:30 AM Clay Teahouse > wrote: > >> Hello All, >> >> What are the pros and cons of using ignite as an asset and configuration >> database? >> >> thanks, >> Clay >> >
cache.get and cache.isExists causes "Failed to process invalid partitions response" exception even though the cache message finished processing
Hi,
We have a cluster with 4 server nodes and 4 client nodes. Each VM is running
one server and one client node in their own JVMs.
*We are getting the following exception when I call
cache.get("WORK_ORDER_MESSAGE_TOPIC")
cache is an instance of IgniteCache*
javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException:
Failed to process invalid partitions response (remote node reported invalid
partitions but remote topology version does not differ from local)
[topVer=AffinityTopologyVersion [topVer=58, minorTopVer=0],
rmtTopVer=AffinityTopologyVersion [topVer=58, minorTopVer=0], part=729,
nodeId=01220042-7d29-4fea-bca1-270abc356a38]
*Trace is as follows:*
Caused by: org.apache.ignite.IgniteCheckedException: Failed to process
invalid partitions response (remote node reported invalid partitions but
remote topology version does not differ from local)
[topVer=AffinityTopologyVersion [topVer=58, minorTopVer=0],
rmtTopVer=AffinityTopologyVersion [topVer=58, minorTopVer=0], part=729,
nodeId=01220042-7d29-4fea-bca1-270abc356a38]
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.checkError(GridPartitionedSingleGetFuture.java:611)
~[kernel.jar:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridPartitionedSingleGetFuture.onResult(GridPartitionedSingleGetFuture.java:520)
~[kernel.jar:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter.processNearSingleGetResponse(GridDhtCacheAdapter.java:368)
~[kernel.jar:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache.access$100(GridDhtColocatedCache.java:87)
~[kernel.jar:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache$2.apply(GridDhtColocatedCache.java:132)
~[kernel.jar:?]
at
org.apache.ignite.internal.processors.cache.distributed.dht.colocated.GridDhtColocatedCache$2.apply(GridDhtColocatedCache.java:130)
~[kernel.jar:?]
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1056)
~[kernel.jar:?]
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:581)
~[kernel.jar:?]
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:380)
~[kernel.jar:?]
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:306)
~[kernel.jar:?]
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
~[kernel.jar:?]
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:295)
~[kernel.jar:?]
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1569)
~[kernel.jar:?]
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1197)
~[kernel.jar:?]
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
~[kernel.jar:?]
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1093)
~[kernel.jar:?]
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:505)
~[kernel.jar:?]
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
~[kernel.jar:?]
*Ignite client node logs are as follows:*
2020-Jan-07 Tue 13:04:48.780 DEBUG [main] -
org.apache.ignite.internal.processors.cache.GridCacheIoManager - Sending
cache message [msg=GridNearSingleGetRequest [futId=1578402251656,
key=UserKeyCacheObjectImpl [part=729, val=WORK_ORDER_MESSAGE_TOPIC,
hasValBytes=true], flags=1, topVer=AffinityTopologyVersion [topVer=58,
minorTopVer=0], subjId=81046742-907a-4ebc-ad37-cd5daabbf1fd, taskNameHash=0,
createTtl=-1, accessTtl=-1, mvccSnapshot=null], node=ClusterNode
[id=01220042-7d29-4fea-bca1-270abc356a38, order=55, addr=[172.31.42.183],
daemon=false]]
2020-Jan-07 Tue 13:04:48.780 TRACE [main] -
org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi - Sending
message with ack to node [node=TcpDiscoveryNode
[id=01220042-7d29-4fea-bca1-270abc356a38, addrs=[172.31.42.183],
sockAddrs=[SRV-CR04.aalab.local/172.31.42.183:47500], discPort=47500,
order=55, intOrder=31, lastExchangeTime=1578402259264, loc=false,
ver=2.7.0#20181130-sha1:256ae401, isClient=false], msg=GridIoMessage [plc=2,
topic=TOPIC_CACHE, topicOrd=8, ordered=false, timeout=0,
skipOnTimeout=false, msg=GridNearSingleGetRequest [futId=1578402251656,
key=UserKeyCacheObjectImpl [part=729, val=WORK_ORDER_MESSAGE_TOPIC,
hasValBytes=true], flags=1, topVer=AffinityTopologyVersion [topVer=58,
minorTopVer=0], subjId=81046742-907a-4ebc-ad37-cd5daabbf1fd, taskNameHash=0,
createTtl=-1, accessTtl=-1, mvccSnapshot=null]]]
Re: Ignite Persistence: Baseline Topology
Denis, it's not about the size - the size could be different. It's about having different configured DataRegions and creating caches without NodeFilter. If newly added node has new DataRegion and cache created for this region - it will lead to the cluster failure. Evgenii ср, 8 янв. 2020 г. в 13:15, Denis Magda : > Andrey, > > Are you saying we require to have regions of the same size preconfigured > across the nodes? Hope I misunderstood you. > > - > Denis > > > On Mon, Jan 6, 2020 at 7:18 AM Andrei Aleksandrov > wrote: > >> Hi, >> >> I guess that every data node should have have the same data regions. I >> checked that in case if you have for example 2 nodes with persistence >> region in BLT and then start a new node (that isn't the part of BLT) >> with new region and some cache in this new region then it will produce >> next exception: >> >> [17:53:30,446][SEVERE][exchange-worker-#48][GridDhtPartitionsExchangeFuture] >> >> Failed to reinitialize local partitions (rebalancing will be stopped): >> GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=3, >> minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode >> [id=44c8ba83-4a4d-4b0e-b4b6-530a23b25d24, addrs=[0:0:0:0:0:0:0:1, >> 10.0.1.1, 10.0.75.1, 127.0.0.1, 172.25.4.231, 192.168.244.113, >> 192.168.56.1], >> sockAddrs=[LAPTOP-I5CE4BEI.mshome.net/192.168.244.113:47502, >> /192.168.56.1:47502, host.docker.internal/172.25.4.231:47502, >> LAPTOP-I5CE4BEI/10.0.75.1:47502, /0:0:0:0:0:0:0:1:47502, >> /10.0.1.1:47502, /127.0.0.1:47502], discPort=47502, order=3, intOrder=3, >> lastExchangeTime=1578322410223, loc=false, >> ver=2.7.2#20191202-sha1:2e9d1c89, isClient=false], topVer=3, >> nodeId8=f581f039, msg=Node joined: TcpDiscoveryNode >> [id=44c8ba83-4a4d-4b0e-b4b6-530a23b25d24, addrs=[0:0:0:0:0:0:0:1, >> 10.0.1.1, 10.0.75.1, 127.0.0.1, 172.25.4.231, 192.168.244.113, >> 192.168.56.1], >> sockAddrs=[LAPTOP-I5CE4BEI.mshome.net/192.168.244.113:47502, >> /192.168.56.1:47502, host.docker.internal/172.25.4.231:47502, >> LAPTOP-I5CE4BEI/10.0.75.1:47502, /0:0:0:0:0:0:0:1:47502, >> /10.0.1.1:47502, /127.0.0.1:47502], discPort=47502, order=3, intOrder=3, >> lastExchangeTime=1578322410223, loc=false, >> ver=2.7.2#20191202-sha1:2e9d1c89, isClient=false], type=NODE_JOINED, >> tstamp=1578322410400], nodeId=44c8ba83, evt=NODE_JOINED] >> class org.apache.ignite.IgniteCheckedException: Requested DataRegion is >> not configured: 1GB_Region_Eviction >> at >> >> org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.dataRegion(IgniteCacheDatabaseSharedManager.java:729) >> >> BR, >> Andrei >> >> 1/6/2020 2:52 PM, djm132 пишет: >> > You can also look to this topic, probably related to yours with code >> sample >> > >> http://apache-ignite-users.70518.x6.nabble.com/Embedded-ignite-and-baseline-upgrade-questions-td30822.html >> > >> > >> > >> > -- >> > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >> >
Re: Ignite Persistence: Baseline Topology
Andrey, Are you saying we require to have regions of the same size preconfigured across the nodes? Hope I misunderstood you. - Denis On Mon, Jan 6, 2020 at 7:18 AM Andrei Aleksandrov wrote: > Hi, > > I guess that every data node should have have the same data regions. I > checked that in case if you have for example 2 nodes with persistence > region in BLT and then start a new node (that isn't the part of BLT) > with new region and some cache in this new region then it will produce > next exception: > > [17:53:30,446][SEVERE][exchange-worker-#48][GridDhtPartitionsExchangeFuture] > > Failed to reinitialize local partitions (rebalancing will be stopped): > GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=3, > minorTopVer=0], discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode > [id=44c8ba83-4a4d-4b0e-b4b6-530a23b25d24, addrs=[0:0:0:0:0:0:0:1, > 10.0.1.1, 10.0.75.1, 127.0.0.1, 172.25.4.231, 192.168.244.113, > 192.168.56.1], > sockAddrs=[LAPTOP-I5CE4BEI.mshome.net/192.168.244.113:47502, > /192.168.56.1:47502, host.docker.internal/172.25.4.231:47502, > LAPTOP-I5CE4BEI/10.0.75.1:47502, /0:0:0:0:0:0:0:1:47502, > /10.0.1.1:47502, /127.0.0.1:47502], discPort=47502, order=3, intOrder=3, > lastExchangeTime=1578322410223, loc=false, > ver=2.7.2#20191202-sha1:2e9d1c89, isClient=false], topVer=3, > nodeId8=f581f039, msg=Node joined: TcpDiscoveryNode > [id=44c8ba83-4a4d-4b0e-b4b6-530a23b25d24, addrs=[0:0:0:0:0:0:0:1, > 10.0.1.1, 10.0.75.1, 127.0.0.1, 172.25.4.231, 192.168.244.113, > 192.168.56.1], > sockAddrs=[LAPTOP-I5CE4BEI.mshome.net/192.168.244.113:47502, > /192.168.56.1:47502, host.docker.internal/172.25.4.231:47502, > LAPTOP-I5CE4BEI/10.0.75.1:47502, /0:0:0:0:0:0:0:1:47502, > /10.0.1.1:47502, /127.0.0.1:47502], discPort=47502, order=3, intOrder=3, > lastExchangeTime=1578322410223, loc=false, > ver=2.7.2#20191202-sha1:2e9d1c89, isClient=false], type=NODE_JOINED, > tstamp=1578322410400], nodeId=44c8ba83, evt=NODE_JOINED] > class org.apache.ignite.IgniteCheckedException: Requested DataRegion is > not configured: 1GB_Region_Eviction > at > > org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.dataRegion(IgniteCacheDatabaseSharedManager.java:729) > > BR, > Andrei > > 1/6/2020 2:52 PM, djm132 пишет: > > You can also look to this topic, probably related to yours with code > sample > > > http://apache-ignite-users.70518.x6.nabble.com/Embedded-ignite-and-baseline-upgrade-questions-td30822.html > > > > > > > > -- > > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ >
Re: Ignite for Configuration Database
Hi Clay, Could you please elaborate on the technical requirements of this usage scenario? - Denis On Wed, Jan 8, 2020 at 8:30 AM Clay Teahouse wrote: > Hello All, > > What are the pros and cons of using ignite as an asset and configuration > database? > > thanks, > Clay >
Re: Custom Java Objects as Key in IgniteCache with persistence enabled
Hi, No, equals/hashCode from Objects are not used by Ignite. For example, to calculate hashCode for the object, Ignite uses BinaryArrayIdentityResolver which calculates hashCode from serialized object. As for key equity - it compares serialised forms of the objects. Best Regards, Evgenii пн, 30 дек. 2019 г. в 09:22, Mitchell Rathbun (BLOOMBERG/ 731 LEX) < mrathb...@bloomberg.net>: > Sorry for the delayed response, I have not since been able to reproduce > this. In general how does key equality work with Ignite, given that the > keys in the cache must be serialized? Does equals/hashCode even come into > play? > > From: user@ignite.apache.org At: 12/19/19 04:27:04 > To: user@ignite.apache.org > Subject: Re: Custom Java Objects as Key in IgniteCache with persistence > enabled > > Hi, Mitchell! > > I can't reproduce your case, i.e. key objects are put correctly in my case. > Could you send a link to your code, for example on github? > > Here is my attempt to reproduce: > > https://github.com/shishkovilja/ignite/blob/d35ec9ee05f61692f1e3301ca3258fbe86f9 > > b4f7/modules/core/src/test/java/org/apache/ignite/userlist/CustomObjectTest.java > > > > -- > Sent from: http://apache-ignite-users.70518.x6.nabble.com/ > > >
Ignite for Configuration Database
Hello All, What are the pros and cons of using ignite as an asset and configuration database? thanks, Clay
