[infinispan-dev] Infinispan Server repository
Hi devs, as we agreed a while ago, I have renamed the infinispan/jdg repository on GitHub to infinispan/infinispan-server. I will also issue pull requests soon to remove any references to jdg from the code/docs/examples. Please update your local remotes to point to: g...@github.com:infinispan/infinispan-server.git Tristan ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Branch completion in zsh for remove_topic_branch
Great stuff! I've been wanting one of these for a while. I gave it a go and seems to autocomplete very nicely :) I can see other scripts benefiting from this! Cheers Dan :) On Jan 31, 2013, at 6:37 PM, Dan Berindei wrote: > Hi guys > > I hated the fact that I didn't have branch name completions for > remove_topic_branch in zsh, so I wrote an auto-completion script for it: > https://github.com/danberindei/scripts/blob/master/zsh/_remove_topic_branch > > Just save it to any directory and then add the directory to fpath in your > .zshrc/.zshenv, like this: > > fpath=( $fpath ) > > or like this > > FPATH=$FPATH: > > > Hope this helps. > > Cheers > Dan > > ___ > 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
Re: [infinispan-dev] Conditional cache operations useless with Optimistic locking?
On Mar 8, 2013, at 1:50 PM, Sanne Grinovero wrote: > Hi Galder, > I think using conditional operations is very useful even with > optimistic locking: the single conditional operation might not make > sense, but a transaction might include more operations and some of > these operations might depend on the result of the conditional > operation. > > I'd expect the conditional operation to only return the value based on > current state (a prediction), and the transaction would fail if this > value is no longer valid at commit time. So no locks need to be taken > during the evaluation. ^ That's indeed what's happening, but as you can see, it confuses users (Jim, are you there?)… And I can see why they get confused. The conditional operations, such as replace, are rooted in enabling CAS-like operation, and an attempt to replace a value in a collection without having to synchronize or use locks… You can do what you say above with put/get operations. It will create more boiler plate code for sure, but the expectations of what the code does might be easier to understand for users. So, on one side, conditional operations can help reduce the code-size (by doing multiple operations in one go), but users expect them to behave in a way which does not really happen when you use transactions + OL. I'm in two minds on this… Cheers, > > Sanne > > On 6 March 2013 14:45, Galder Zamarreño wrote: >> Hi, >> >> Re: https://issues.jboss.org/browse/ISPN-2891 >> >> Not sure what previous Infinispan version the AS instance Immutant guys used >> (5.1?), but seems like they're having more issues with the clojure test >> linked in the JIRA. >> >> Again, we're talking about issues with replace(), but in a single node >> environment. They seem to have issues with PL and OL, but let's focus on OL >> for which there are logs attached. >> >> Do conditional operations make any sense at all with OL? For example, can >> the return of replace() be taken a truthful in a transaction with OL? >> >> As shown in the bad.log, this is not possible because lock acquisition and >> write skew checks are only done when the transaction is committed. So, >> what's the point of the conditional operations with OL? Their returns >> provide no guarantees whatsoever. >> >> If this is known thing, I'm not aware of any docu on the topic. >> >> Thoughts? >> >> Cheers, >> -- >> 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 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] old workaround in CacheImpl
Hi, does anyone know what issue is the unused (but injected) CacheImpl.responseGenerator field supposed to cure? See here: https://github.com/anistor/infinispan/blob/master/core/src/main/java/org/infinispan/CacheImpl.java#L139 The accompanying comment does not seem to be valid anymore. There is no jira for it and the tests run fine without it. Can't we just remove it? Cheers ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Conditional cache operations useless with Optimistic locking?
On 6 Mar 2013, at 14:45, Galder Zamarreño wrote: > Hi, > > Re: https://issues.jboss.org/browse/ISPN-2891 > > Not sure what previous Infinispan version the AS instance Immutant guys used > (5.1?), but seems like they're having more issues with the clojure test > linked in the JIRA. The CO in 5.1.x were broken in many ways. Moving to 5.2.x should fix this. > > Again, we're talking about issues with replace(), but in a single node > environment. They seem to have issues with PL and OL, but let's focus on OL > for which there are logs attached. > > Do conditional operations make any sense at all with OL? For example, can the > return of replace() be taken a truthful in a transaction with OL? I think they do. With optimistic transactions the result of a replace is indeed calculated at operation time (vs as lock acquisition time). But if you need to make sure that the old value hasn't changed in between, then enable write skew check and your transaction would fail (well that's actually still something to look at ISPN-2840). > > As shown in the bad.log, this is not possible because lock acquisition and > write skew checks are only done when the transaction is committed. So, what's > the point of the conditional operations with OL? Their returns provide no > guarantees whatsoever. > > If this is known thing, I'm not aware of any docu on the topic. > > Thoughts? > > Cheers, > -- > 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 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] Conditional cache operations useless with Optimistic locking?
On 8 Mar 2013, at 12:50, Sanne Grinovero wrote: > I think using conditional operations is very useful even with > optimistic locking: the single conditional operation might not make > sense, but a transaction might include more operations and some of > these operations might depend on the result of the conditional > operation. > > I'd expect the conditional operation to only return the value based on > current state (a prediction), and the transaction would fail if this > value is no longer valid at commit time. So no locks need to be taken > during the evaluation. that's only if you have write skew check enabled. 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] old workaround in CacheImpl
And this is how it looked in 5.1.x https://github.com/anistor/infinispan/blob/5.1.x/core/src/main/java/org/infinispan/CacheImpl.java#L139 On 03/12/2013 01:40 PM, Adrian Nistor wrote: > Hi, > > does anyone know what issue is the unused (but injected) > CacheImpl.responseGenerator field supposed to cure? See here: > https://github.com/anistor/infinispan/blob/master/core/src/main/java/org/infinispan/CacheImpl.java#L139 > > > The accompanying comment does not seem to be valid anymore. There is no > jira for it and the tests run fine without it. Can't we just remove it? > > 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] old workaround in CacheImpl
git annotate points to Mr. Surtani :-) On 12 Mar 2013, at 11:43, Adrian Nistor wrote: > And this is how it looked in 5.1.x > https://github.com/anistor/infinispan/blob/5.1.x/core/src/main/java/org/infinispan/CacheImpl.java#L139 > > On 03/12/2013 01:40 PM, Adrian Nistor wrote: >> Hi, >> >> does anyone know what issue is the unused (but injected) >> CacheImpl.responseGenerator field supposed to cure? See here: >> https://github.com/anistor/infinispan/blob/master/core/src/main/java/org/infinispan/CacheImpl.java#L139 >> >> >> The accompanying comment does not seem to be valid anymore. There is no >> jira for it and the tests run fine without it. Can't we just remove it? >> >> 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 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] old workaround in CacheImpl
I think the field was needed because InboundInvocationHandlerImpl was using ComponentRegistry.getComponent(ResponseGenerator.class), and there wasn't anyone actually creating the ResponseGenerator component. Since https://issues.jboss.org/browse/ISPN-1793, ComponentRegistry creates the ResponseGenerator component explicitly, so the field in CacheImpl is no longer needed. On Tue, Mar 12, 2013 at 1:53 PM, Mircea Markus wrote: > git annotate points to Mr. Surtani :-) > > On 12 Mar 2013, at 11:43, Adrian Nistor wrote: > > > And this is how it looked in 5.1.x > > > https://github.com/anistor/infinispan/blob/5.1.x/core/src/main/java/org/infinispan/CacheImpl.java#L139 > > > > On 03/12/2013 01:40 PM, Adrian Nistor wrote: > >> Hi, > >> > >> does anyone know what issue is the unused (but injected) > >> CacheImpl.responseGenerator field supposed to cure? See here: > >> > https://github.com/anistor/infinispan/blob/master/core/src/main/java/org/infinispan/CacheImpl.java#L139 > >> > >> > >> The accompanying comment does not seem to be valid anymore. There is no > >> jira for it and the tests run fine without it. Can't we just remove it? > >> > >> 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 > > 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] Conditional cache operations useless with Optimistic locking?
On Tue, Mar 12, 2013 at 1:32 PM, Galder Zamarreño wrote: > > On Mar 8, 2013, at 1:50 PM, Sanne Grinovero wrote: > > > Hi Galder, > > I think using conditional operations is very useful even with > > optimistic locking: the single conditional operation might not make > > sense, but a transaction might include more operations and some of > > these operations might depend on the result of the conditional > > operation. > > > > I'd expect the conditional operation to only return the value based on > > current state (a prediction), and the transaction would fail if this > > value is no longer valid at commit time. So no locks need to be taken > > during the evaluation. > > ^ That's indeed what's happening, but as you can see, it confuses users > (Jim, are you there?)… > > And I can see why they get confused. The conditional operations, such as > replace, are rooted in enabling CAS-like operation, and an attempt to > replace a value in a collection without having to synchronize or use locks… > > You can do what you say above with put/get operations. It will create more > boiler plate code for sure, but the expectations of what the code does > might be easier to understand for users. > > So, on one side, conditional operations can help reduce the code-size (by > doing multiple operations in one go), but users expect them to behave in a > way which does not really happen when you use transactions + OL. > > I'm in two minds on this… > > I remember having a discussion about conditional operations with optimistic locking a long time ago (Edinburgh?) and concluding that they should be allowed to "lie" - pretend that they did the put/replace/remove and check again on prepare if the condition still holds (with write skew check enabled). I think the other option on the table was treat conditional operations as "non-transactional" - if putIfAbsent(k, v) returned true, then v would be stored in the cache even if the current transaction was rolled back. I don't remember if we considered acquiring locks for conditional operations even with optimistic locking at the time or not. It would be a bit of a hack, but it would make a lot more sense than the current behaviour with the default configuration (optimistic locking with write skew check disabled, which makes conditional operations pretty much useless). Off-topic: is it just me, or is it a little odd that the locking mode is configured via TransactionConfigurationBuilder and the isolation level/write skew check are configured via LockingConfigurationBuilder? Cheers Dan Cheers, > > > > > Sanne > > > > On 6 March 2013 14:45, Galder Zamarreño wrote: > >> Hi, > >> > >> Re: https://issues.jboss.org/browse/ISPN-2891 > >> > >> Not sure what previous Infinispan version the AS instance Immutant guys > used (5.1?), but seems like they're having more issues with the clojure > test linked in the JIRA. > >> > >> Again, we're talking about issues with replace(), but in a single node > environment. They seem to have issues with PL and OL, but let's focus on OL > for which there are logs attached. > >> > >> Do conditional operations make any sense at all with OL? For example, > can the return of replace() be taken a truthful in a transaction with OL? > >> > >> As shown in the bad.log, this is not possible because lock acquisition > and write skew checks are only done when the transaction is committed. So, > what's the point of the conditional operations with OL? Their returns > provide no guarantees whatsoever. > >> > >> If this is known thing, I'm not aware of any docu on the topic. > >> > >> Thoughts? > >> > >> Cheers, > >> -- > >> 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 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 mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Infinispan Server repository
Cool! When are we moving the server modules to the infinispan-server project? ;) On Tue, Mar 12, 2013 at 10:10 AM, Tristan Tarrant wrote: > Hi devs, > > as we agreed a while ago, I have renamed the infinispan/jdg repository > on GitHub to infinispan/infinispan-server. > I will also issue pull requests soon to remove any references to jdg > from the code/docs/examples. > > Please update your local remotes to point to: > > g...@github.com:infinispan/infinispan-server.git > > Tristan > ___ > 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] Infinispan Server repository
On 03/12/2013 04:09 PM, Dan Berindei wrote: > Cool! When are we moving the server modules to the infinispan-server > project? ;) > As soon as we have CI to check that Dan's commits to Infinispan don't break Infinispan Server :) Tristan ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Infinispan Server repository
On 12 Mar 2013, at 15:11, Tristan Tarrant wrote: > On 03/12/2013 04:09 PM, Dan Berindei wrote: >> Cool! When are we moving the server modules to the infinispan-server >> project? ;) >> > As soon as we have CI to check that Dan's commits to Infinispan don't > break Infinispan Server :) Speaking of CI, where are we with that? -- Manik Surtani ma...@jboss.org twitter.com/maniksurtani Platform Architect, JBoss Data Grid http://red.ht/data-grid ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
Re: [infinispan-dev] Infinispan Server repository
On 12 Mar 2013, at 16:08, Manik Surtani wrote: > On 12 Mar 2013, at 15:11, Tristan Tarrant wrote: > >> On 03/12/2013 04:09 PM, Dan Berindei wrote: >>> Cool! When are we moving the server modules to the infinispan-server >>> project? ;) >>> >> As soon as we have CI to check that Dan's commits to Infinispan don't >> break Infinispan Server :) > > Speaking of CI, where are we with that? I'm looking into it as we speak. 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] Conditional cache operations useless with Optimistic locking?
FWIW, I do have write skew check enabled, along with versioning (simple) enabled, and isolation level of REPEATABLE_READ. Thanks, Jim Mircea Markus writes: > On 8 Mar 2013, at 12:50, Sanne Grinovero wrote: > >> I think using conditional operations is very useful even with >> optimistic locking: the single conditional operation might not make >> sense, but a transaction might include more operations and some of >> these operations might depend on the result of the conditional >> operation. >> >> I'd expect the conditional operation to only return the value based on >> current state (a prediction), and the transaction would fail if this >> value is no longer valid at commit time. So no locks need to be taken >> during the evaluation. > that's only if you have write skew check enabled. > > Cheers, ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
