Re: [infinispan-dev] Build script for ISPN
I think it's a good idea. Amongst other things, it'd allow for a settings.xml file to be provided without littering the pom.xml files. Navin, have you written one already? Cheers, On Jun 14, 2013, at 4:04 AM, Navin Surtani wrote: > Greetings all, > > I had this idea yesterday that it might be useful for ISPN to have a build.sh > (and similar .bat) script for compiling - rather like WildFly. > > My reasons for this is that since different projects around JBoss tend to > have different tweaks and requirements when it comes to MAVEN_OPTS and also > the Maven settings.xml file, I figured it might be useful to be able to > provide the Infinispan specific settings through this approach. Galder > mentioned that the MAVEN_OPTS may not be required anymore due to some changes > in the testsuite over the past couple of months, but I have a feeling that it > might prove useful to have this script nonetheless. > > WDYT? > > > Navin Surtani > > Software Engineer > JBoss SET > JBoss EAP > > Twitter: @navssurtani > Blog: navssurtani.blogspot.com > > ___ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño gal...@redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
[infinispan-dev] Doubts about TxDistributionInterceptor and possible break in transaction isolation
Hi guys, I've been looking at TxDistributionInterceptor and I have a couple of questions (assuming REPEATABLE_READ isolation level): #1. why are we doing a remote get each time we write on a key? (huge perform impact if the key was previously read) #2. why are we doing a dataContainer.get() if the remote get returns a null value? Shouldn't the interactions with data container be performed only in the (Versioned)EntryWrappingInterceptor? #3. (I didn't verify this) why are we acquire the lock is the remote get is performed for a write? This looks correct for pessimistic locking but not for optimistic... After this analysis, it is possible to break the isolation between transaction if I do a get on the key that does not exist: tm.begin() cache.get(k) //returns null //in the meanwhile a transaction writes on k and commits cache.get(k) //return the new value. IMO, this is not valid for REPEATABLE_READ isolation level! wdyt? Thanks. Cheers, Pedro Ruivo ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Doubts about TxDistributionInterceptor and possible break in transaction isolation
On 17 Jun 2013, at 11:52, Pedro Ruivo wrote: > I've been looking at TxDistributionInterceptor and I have a couple of > questions (assuming REPEATABLE_READ isolation level): > > #1. why are we doing a remote get each time we write on a key? (huge > perform impact if the key was previously read) indeed this is suboptimal for transactions that write the same key repeatedly and repeatable read. Can you please create a JIRA for this? > > #2. why are we doing a dataContainer.get() if the remote get returns a > null value? Shouldn't the interactions with data container be performed > only in the (Versioned)EntryWrappingInterceptor? This was added in the scope of ISPN-2688 and covers the scenario in which a state transfer is in progress, the remote get returns null as the remote value was dropped (no longer owner) and this node has become the owner in between. > > #3. (I didn't verify this) why are we acquire the lock is the remote get > is performed for a write? This looks correct for pessimistic locking but > not for optimistic... I think that, given that the local node is not owner, the lock acquisition is redundant even for pessimistic caches. Mind creating a test to check if dropping that lock acquisition doesn't break things? > > After this analysis, it is possible to break the isolation between > transaction if I do a get on the key that does not exist: > > tm.begin() > cache.get(k) //returns null > //in the meanwhile a transaction writes on k and commits > cache.get(k) //return the new value. IMO, this is not valid for > REPEATABLE_READ isolation level! Indeed sounds like a bug, well spotted. Can you please add a UT to confirm it and raise a JIRA? Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Doubts about TxDistributionInterceptor and possible break in transaction isolation
On 06/17/2013 12:56 PM, Mircea Markus wrote: > > On 17 Jun 2013, at 11:52, Pedro Ruivo wrote: > >> I've been looking at TxDistributionInterceptor and I have a couple of >> questions (assuming REPEATABLE_READ isolation level): >> >> #1. why are we doing a remote get each time we write on a key? (huge >> perform impact if the key was previously read) > indeed this is suboptimal for transactions that write the same key repeatedly > and repeatable read. Can you please create a JIRA for this? created: https://issues.jboss.org/browse/ISPN-3235 >> >> #2. why are we doing a dataContainer.get() if the remote get returns a >> null value? Shouldn't the interactions with data container be performed >> only in the (Versioned)EntryWrappingInterceptor? > This was added in the scope of ISPN-2688 and covers the scenario in which a > state transfer is in progress, the remote get returns null as the remote > value was dropped (no longer owner) and this node has become the owner in > between. > ok :) >> >> #3. (I didn't verify this) why are we acquire the lock is the remote get >> is performed for a write? This looks correct for pessimistic locking but >> not for optimistic... > I think that, given that the local node is not owner, the lock acquisition is > redundant even for pessimistic caches. > Mind creating a test to check if dropping that lock acquisition doesn't break > things? I created a JIRA with low priority since it does not affect the transaction outcome/isolation and I believe the performance impact should be lower (you can increase the priority if you want). https://issues.jboss.org/browse/ISPN-3237 >> >> After this analysis, it is possible to break the isolation between >> transaction if I do a get on the key that does not exist: >> >> tm.begin() >> cache.get(k) //returns null >> //in the meanwhile a transaction writes on k and commits >> cache.get(k) //return the new value. IMO, this is not valid for >> REPEATABLE_READ isolation level! > > Indeed sounds like a bug, well spotted. > Can you please add a UT to confirm it and raise a JIRA? created: https://issues.jboss.org/browse/ISPN-3236 IMO, this should be the correct behaviour (I'm going to add the test cases later): tm.begin() cache.get(k) //returns null (op#1) //in the meanwhile a transaction writes on k and commits write operation performed: * put: must return the same value as op#1 * conditional put //if op#1 returns null the operation should be always successful (i.e. the key is updated, return true). Otherwise, the key remains unchanged (return false) * replace: must return the same value as op#1 * conditional replace: replace should be successful if checked with the op#1 return value (return true). Otherwise, the key must remain unchanged (return false). * remote: must return the same value as op#1 * conditional remove: the key should be removed if checked with the op#1 return value (return true). Otherwise, the key must remain unchanged (return false) Also, the description above should be valid after a removal of a key. > > Cheers, > ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Doubts about TxDistributionInterceptor and possible break in transaction isolation
On 17 Jun 2013, at 13:58, Pedro Ruivo wrote: >>> >>> After this analysis, it is possible to break the isolation between >>> transaction if I do a get on the key that does not exist: >>> >>> tm.begin() >>> cache.get(k) //returns null >>> //in the meanwhile a transaction writes on k and commits >>> cache.get(k) //return the new value. IMO, this is not valid for >>> REPEATABLE_READ isolation level! >> >> Indeed sounds like a bug, well spotted. >> Can you please add a UT to confirm it and raise a JIRA? > > created: https://issues.jboss.org/browse/ISPN-3236 > > IMO, this should be the correct behaviour (I'm going to add the test > cases later): > > tm.begin() > cache.get(k) //returns null (op#1) > //in the meanwhile a transaction writes on k and commits > write operation performed: > * put: must return the same value as op#1 > * conditional put //if op#1 returns null the operation should be always > successful (i.e. the key is updated, return true). Otherwise, the key > remains unchanged (return false) > * replace: must return the same value as op#1 > * conditional replace: replace should be successful if checked with the > op#1 return value (return true). Otherwise, the key must remain > unchanged (return false). all the conditional operation should consider as existing value whatever was previously read (op#1) or more correctly whatever it is in the context: e.g. //start k = null tx.begin() cache.put(k,v1); cache.replace(k,v1, v2) -> should succeed as the context sees v1 associated to k > * remote: must return the same value as op#1 you mean remove? remove should use whatever is in the context > * conditional remove: the key should be removed if checked with the op#1 > return value (return true). Otherwise, the key must remain unchanged > (return false) same.. > > Also, the description above should be valid after a removal of a key. Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Doubts about TxDistributionInterceptor and possible break in transaction isolation
On Mon, Jun 17, 2013 at 3:58 PM, Pedro Ruivo wrote: > > > On 06/17/2013 12:56 PM, Mircea Markus wrote: > > > > On 17 Jun 2013, at 11:52, Pedro Ruivo wrote: > > > >> I've been looking at TxDistributionInterceptor and I have a couple of > >> questions (assuming REPEATABLE_READ isolation level): > >> > >> #1. why are we doing a remote get each time we write on a key? (huge > >> perform impact if the key was previously read) > > indeed this is suboptimal for transactions that write the same key > repeatedly and repeatable read. Can you please create a JIRA for this? > > created: https://issues.jboss.org/browse/ISPN-3235 > > Oops... when I fixed https://issues.jboss.org/browse/ISPN-3124 I removed the SKIP_REMOTE_LOOKUP, thinking that the map is already in the invocation context so there shouldn't be any perf penalty. I can't put the SKIP_REMOTE_LOOKUP flag back, otherwise delta writes won't have the previous value during state transfer, so +1 to fixing ISPN-3235. > >> > >> #2. why are we doing a dataContainer.get() if the remote get returns a > >> null value? Shouldn't the interactions with data container be performed > >> only in the (Versioned)EntryWrappingInterceptor? > > This was added in the scope of ISPN-2688 and covers the scenario in > which a state transfer is in progress, the remote get returns null as the > remote value was dropped (no longer owner) and this node has become the > owner in between. > > > > ok :) > > Yeah, this should be correct as long as we check if we already have the key in the invocation context before doing the remote + local get. > >> > >> #3. (I didn't verify this) why are we acquire the lock is the remote get > >> is performed for a write? This looks correct for pessimistic locking but > >> not for optimistic... > > I think that, given that the local node is not owner, the lock > acquisition is redundant even for pessimistic caches. > > Mind creating a test to check if dropping that lock acquisition doesn't > break things? > > I created a JIRA with low priority since it does not affect the > transaction outcome/isolation and I believe the performance impact > should be lower (you can increase the priority if you want). > > https://issues.jboss.org/browse/ISPN-3237 > If we don't lock the L1 entry, I think something like this could happen: tx1@A: remote get(k1) from B - stores k1=v1 in invocation context tx2@A: write(k1, v2) tx2@A: commit - writes k1=v2 in L1 tx1@A: commit - overwrites k1=v1 in L1 >> > >> After this analysis, it is possible to break the isolation between > >> transaction if I do a get on the key that does not exist: > >> > >> tm.begin() > >> cache.get(k) //returns null > >> //in the meanwhile a transaction writes on k and commits > >> cache.get(k) //return the new value. IMO, this is not valid for > >> REPEATABLE_READ isolation level! > > > > Indeed sounds like a bug, well spotted. > > Can you please add a UT to confirm it and raise a JIRA? > > created: https://issues.jboss.org/browse/ISPN-3236 > > IMO, this should be the correct behaviour (I'm going to add the test > cases later): > > tm.begin() > cache.get(k) //returns null (op#1) > //in the meanwhile a transaction writes on k and commits > write operation performed: > * put: must return the same value as op#1 > * conditional put //if op#1 returns null the operation should be always > successful (i.e. the key is updated, return true). Otherwise, the key > remains unchanged (return false) > * replace: must return the same value as op#1 > * conditional replace: replace should be successful if checked with the > op#1 return value (return true). Otherwise, the key must remain > unchanged (return false). > * remote: must return the same value as op#1 > * conditional remove: the key should be removed if checked with the op#1 > return value (return true). Otherwise, the key must remain unchanged > (return false) > > Also, the description above should be valid after a removal of a key. > > > > > Cheers, > > > ___ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Doubts about TxDistributionInterceptor and possible break in transaction isolation
On Mon, Jun 17, 2013 at 11:11 AM, Dan Berindei wrote: > > > > On Mon, Jun 17, 2013 at 3:58 PM, Pedro Ruivo wrote: > >> >> >> On 06/17/2013 12:56 PM, Mircea Markus wrote: >> > >> > On 17 Jun 2013, at 11:52, Pedro Ruivo wrote: >> > >> >> I've been looking at TxDistributionInterceptor and I have a couple of >> >> questions (assuming REPEATABLE_READ isolation level): >> >> >> >> #1. why are we doing a remote get each time we write on a key? (huge >> >> perform impact if the key was previously read) >> > indeed this is suboptimal for transactions that write the same key >> repeatedly and repeatable read. Can you please create a JIRA for this? >> >> created: https://issues.jboss.org/browse/ISPN-3235 >> >> > Oops... when I fixed https://issues.jboss.org/browse/ISPN-3124 I removed > the SKIP_REMOTE_LOOKUP, thinking that the map is already in the invocation > context so there shouldn't be any perf penalty. I can't put the > SKIP_REMOTE_LOOKUP flag back, otherwise delta writes won't have the > previous value during state transfer, so +1 to fixing ISPN-3235. > > > >> >> >> >> #2. why are we doing a dataContainer.get() if the remote get returns a >> >> null value? Shouldn't the interactions with data container be performed >> >> only in the (Versioned)EntryWrappingInterceptor? >> > This was added in the scope of ISPN-2688 and covers the scenario in >> which a state transfer is in progress, the remote get returns null as the >> remote value was dropped (no longer owner) and this node has become the >> owner in between. >> > >> >> ok :) >> >> > Yeah, this should be correct as long as we check if we already have the > key in the invocation context before doing the remote + local get. > > > >> >> >> >> #3. (I didn't verify this) why are we acquire the lock is the remote >> get >> >> is performed for a write? This looks correct for pessimistic locking >> but >> >> not for optimistic... >> > I think that, given that the local node is not owner, the lock >> acquisition is redundant even for pessimistic caches. >> > Mind creating a test to check if dropping that lock acquisition doesn't >> break things? >> >> I created a JIRA with low priority since it does not affect the >> transaction outcome/isolation and I believe the performance impact >> should be lower (you can increase the priority if you want). >> >> https://issues.jboss.org/browse/ISPN-3237 >> > > If we don't lock the L1 entry, I think something like this could happen: > > tx1@A: remote get(k1) from B - stores k1=v1 in invocation context > tx2@A: write(k1, v2) > tx2@A: commit - writes k1=v2 in L1 > tx1@A: commit - overwrites k1=v1 in L1 > This one is just like here: referenced in https://issues.jboss.org/browse/ISPN-2965?focusedCommentId=12779780&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12779780 And even locking doesn't help in this case since it doesn't lock the key for a remote get only a remote get in the context of a write - which means the L1 could be updated concurrently in either order - causing possibly an inconsistency. This will be solved when I port the same fix I have for https://issues.jboss.org/browse/ISPN-3197 for tx caches. > > > >> >> >> After this analysis, it is possible to break the isolation between >> >> transaction if I do a get on the key that does not exist: >> >> >> >> tm.begin() >> >> cache.get(k) //returns null >> >> //in the meanwhile a transaction writes on k and commits >> >> cache.get(k) //return the new value. IMO, this is not valid for >> >> REPEATABLE_READ isolation level! >> > >> > Indeed sounds like a bug, well spotted. >> > Can you please add a UT to confirm it and raise a JIRA? >> >> created: https://issues.jboss.org/browse/ISPN-3236 >> >> IMO, this should be the correct behaviour (I'm going to add the test >> cases later): >> >> tm.begin() >> cache.get(k) //returns null (op#1) >> //in the meanwhile a transaction writes on k and commits >> write operation performed: >> * put: must return the same value as op#1 >> * conditional put //if op#1 returns null the operation should be always >> successful (i.e. the key is updated, return true). Otherwise, the key >> remains unchanged (return false) >> * replace: must return the same value as op#1 >> * conditional replace: replace should be successful if checked with the >> op#1 return value (return true). Otherwise, the key must remain >> unchanged (return false). >> * remote: must return the same value as op#1 >> * conditional remove: the key should be removed if checked with the op#1 >> return value (return true). Otherwise, the key must remain unchanged >> (return false) >> >> Also, the description above should be valid after a removal of a key. >> >> > >> > Cheers, >> > >> ___ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > > > ___ > infinispan-dev mailing list > infinispan
Re: [infinispan-dev] Doubts about TxDistributionInterceptor and possible break in transaction isolation
On 17 Jun 2013, at 16:11, Dan Berindei wrote: > > I think that, given that the local node is not owner, the lock acquisition > > is redundant even for pessimistic caches. > > Mind creating a test to check if dropping that lock acquisition doesn't > > break things? > > I created a JIRA with low priority since it does not affect the > transaction outcome/isolation and I believe the performance impact > should be lower (you can increase the priority if you want). > > https://issues.jboss.org/browse/ISPN-3237 > > If we don't lock the L1 entry, I think something like this could happen: There is a lock happening *without* L1 enabled. > > tx1@A: remote get(k1) from B - stores k1=v1 in invocation context > tx2@A: write(k1, v2) > tx2@A: commit - writes k1=v2 in L1 > tx1@A: commit - overwrites k1=v1 in L1 > > Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] NPE in MapReduceTask running in cluster
@Matej, are you still having issues with this? I've created a test and I'm unable to get this to fail any more... Cheers, On Oct 3, 2012, at 10:25 PM, Mircea Markus wrote: > Thanks for raising this Vladimir, I've commented on the JIRA. > > On 1 Oct 2012, at 10:19, Vladimir Blagojevic wrote: > >> Ok, I recommend closing of https://issues.jboss.org/browse/ISPN-2353 to >> project lead! This startup issue will be addressed separately I am sure. >> >> On 12-10-01 8:02 AM, Thomas Fromm wrote: >>> Am 30.09.2012 23:08, schrieb Matej Lazar: NPE was caused by not configured/started cache on the second node. It would be great to detect such situation and throw an other exception instead of NPE. >>> Why throwing an Exception in general? >>> >>> I'd be fine if the execution is ignored on the node where cache not >>> exists/started. The node is not part of the cluster of this cache. >>> >>> ___ >>> infinispan-dev mailing list >>> infinispan-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> >> ___ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > Cheers, > -- > Mircea Markus > Infinispan lead (www.infinispan.org) > > > > > ___ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Galder Zamarreño gal...@redhat.com twitter.com/galderz Project Lead, Escalante http://escalante.io Engineer, Infinispan http://infinispan.org ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
[infinispan-dev] Infinispan 5.3.0.CR2 is out!
More about it here: http://infinispan.blogspot.de/2013/06/infinispan-530cr2-is-out.html Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
[infinispan-dev] 5.3.x branch was cut
Hi, Master was updated to point to 6.0.0. Please port any pending 5.3.x fixes to both master and the 5.3.x branch. Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
[infinispan-dev] release name for Infinispan 6.0.0
Hi, Following the tradition, each Infinispan release is code is a beer. Suggestions? I'll start: - Infinium Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
[infinispan-dev] moving to the new configuration
Hi Navin, The master now pointing to 6.0.0 so whenever you have the time for test migration you can go ahead Tristan is also working on repackaging, but starting with the following should avoid the two of you overlapping. After that please ping Tristan on what can be done next. And again - thanks for looking into this. tools query tree lucene lucene/lucene-directory lucene/lucene-v4 lucene/lucene-v3 rhq-plugin upgrade-tools spring cli/cli-client demos/gui demos/ec2 demos/distexec demos/ec2-ui demos/directory demos/lucene-directory-demo demos/gridfs-webdav demos/nearcache demos/nearcache-client cdi/extension as-modules integrationtests/luceneintegration integrationtests/as-integration integrationtests/compatibility-mode-it jcache Cheers, -- Mircea Markus Infinispan lead (www.infinispan.org) ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] release name for Infinispan 6.0.0
Human Fish * https://www.facebook.com/HumanFishBrewery On Jun 17, 2013, at 10:37 PM, Mircea Markus wrote: > Hi, > > Following the tradition, each Infinispan release is code is a beer. > Suggestions? > > I'll start: > - Infinium > > > Cheers, > -- > Mircea Markus > Infinispan lead (www.infinispan.org) > > > > > ___ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] release name for Infinispan 6.0.0
Seriously Bad Elf (or have ya'll already used that?) http://beeradvocate.com/beer/profile/7944/26887 -- View this message in context: http://infinispan-developer-list.980875.n3.nabble.com/infinispan-dev-release-name-for-Infinispan-6-0-0-tp4027428p4027431.html Sent from the Infinispan Developer List mailing list archive at Nabble.com. ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
