-
1. Re: Synchronous Cache
rvansa Jan 23, 2015 9:11 AM (in response to mvpratap)1 of 1 people found this helpfulUse transactional cache with pessimistic transactions. You can lock the keys after the transaction is started. However, regarding reads, you have to use flag FORCE_WRITE_LOCK in order to block them:
cache.getAdvancedCache().withFlags(FORCE_WRITE_LOCK).get(myKey);
-
2. Re: Synchronous Cache
mvpratap Jan 27, 2015 1:28 AM (in response to rvansa)Thanks for reply..
Two more questions ,
1.We are Getting WARN [TCP] (Timer-11,Mycluster,ITFS-54313) JGRP000032: GD-54313: no physical address for 65cdd4er-594c-cd21-20e3-1f983a27b531, dropping message
Does it cause any problems,How to solve this.?
2.How to get the data stored on the same node(which is the primary owner)..When we use KeySet() it is giving whole data.We want to get the data which is Actually stored on that node(primary owner)data.?
Thanks.
-
3. Re: Synchronous Cache
nadirx Jan 27, 2015 3:36 AM (in response to mvpratap)You need to use flags as follows:
cache.getAdvancedCache().withFlags(Flag.CACHE_MODE_LOCAL).keySet()
-
4. Re: Synchronous Cache
rvansa Jan 27, 2015 3:45 AM (in response to mvpratap)Another option is cache.getAdvancedCache().getDataContainer().keySet(), but see the JavaDoc - this is more low level (but possibly faster) approach.
-
5. Re: Synchronous Cache
mvpratap Jan 27, 2015 4:33 AM (in response to rvansa)Thanks for Quick Response.
what about this.
1.We are Getting WARN [TCP] (Timer-11,Mycluster,ITFS-54313) JGRP000032: GD-54313: no physical address for 65cdd4er-594c-cd21-20e3-1f983a27b531, dropping message
Does it cause any problems,How to solve this.?
Thanks.
-
6. Re: Synchronous Cache
rvansa Jan 27, 2015 4:37 AM (in response to mvpratap)I have seen those warnings, too, but as the cluster is working fine, this is probably a minor bug in JGroups. As the consequence is dropped message, it's not very harmful - application messages can be usually resent (if you use UNICASTx or NAKACK2 protocols).
The only thing that puzzles me is that it occurs in Timer thread. As long as it does not produce tons of messages, I wouldn't worry.
-
7. Re: Synchronous Cache
mvpratap Jan 27, 2015 8:54 AM (in response to rvansa)Thanks for reply.
2.How to get the data stored on the same node(which is the primary owner)..When we use KeySet() it is giving whole data.We want to get the data which is Actually stored on that node(primary owner)data.?
I am using replica mode,
Node1 has added 2 entries in to cache and Node2 has added 5 entries in to cache.
when I use keySet() in Node1 it should give 2 entries only..But i am getting 7.
when I use keySet() in Node2 it should give 5 entries only..But i am getting 7.
I tried both the ways
cache.getAdvancedCache().withFlags(Flag.CACHE_MODE_LOCAL).keySet()
cache.getAdvancedCache().getDataContainer().keySet()
But still getting both nodes data.
This is my configuration
--------------------------------
<infinispan
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:infinispan:config:6.0 http://www.infinispan.org/schemas/infinispan-config-6.0.xsd"
xmlns="urn:infinispan:config:6.0">
<global>
<transport clusterName="Mycluster">
<properties>
<property name="configurationFile" value="jgroups.xml"/>
</properties>
</transport>
</global>
<default>
<locking useLockStriping="false"/>
<clustering mode="replication">
<sync/>
</clustering>
</default>
<namedCache name="cache"/>
</infinispan>
could u please help.
Thanks.
-
8. Re: Synchronous Cache
nadirx Jan 27, 2015 9:00 AM (in response to mvpratap)In replicated mode all nodes are "owners", and therefore the behaviour is correct: all nodes "own" all entries and have their own copy of the data.
Also, the fact that you "put" an entry on a node, does not mean that node is the owner of the data, unless you are using the KeyAffinityService. Normally the key is hashed (using the consistent hash algorithm). Using the hash, the owning segment is determined. The node where that segment "lives" is determined by the DistributionManager.
-
9. Re: Re: Synchronous Cache
mvpratap Jan 28, 2015 1:15 AM (in response to nadirx)Thanks for Reply,
Ok,I will try with KeyAffinityService.
I have one more doubt.
I am using Infininispan in replication mode.The Ping response between two nodes is 300ms.But when i am adding elements to cache it takes around 3seconds.
Which causes bad performances.How to improve performance?
Thanks.
-
jgroups.xml 2.2 KB
-
-
10. Re: Synchronous Cache
nadirx Jan 28, 2015 2:06 AM (in response to mvpratap)No, you have misunderstood me:
The KeyAffinityService will not do anything in a replicated cache, since all nodes will be owners.
Also those timings are terrible. What's the network between the nodes ? Even the ping is bad, you should be getting sub-millisecond pings.
On my home network with a (cheapo) 1Gb switch I get 0.220ms average ping response times.
Tristan
-
11. Re: Synchronous Cache
mvpratap Jan 28, 2015 2:45 AM (in response to nadirx)Tristan,Thanks for the reply.
Then How Can i distribute the Infinispan nodes across the globe.The ping response times should be always less than 1ms.(should i use faster networks for this)
Currently one node is in U.S and another node is in U.K..the ping response is 300ms.
Geo-graphical distribution of nodes means atleast some milliseconds delay will be there right?
So,Can't i use infinispan with these ping response times.
Thanks.
-
12. Re: Synchronous Cache
nadirx Jan 28, 2015 2:56 AM (in response to mvpratap)Ah, I didn't know you wanted geographical distribution. As the latency between nodes grows higher you need to take that into account when setting timeouts and such.
Have you considered using Cross-Site replication instead ? It works more as a backup, i.e. you would have a local cache at each site, which is backed up to another cache on a remote site. It is a potentially more robust solution for your problem. Obviously your code would need to take into consideration the fact that you have two caches.