[infinispan-dev] Reliability of return values

2014-05-12 Thread Radim Vansa
Hi, recently I've stumbled upon one already expected behaviour (one instance is [1]), but which did not got much attention. In non-tx cache, when the primary owner fails after the request has been replicated to backup owner, the request is retried in the new topology. Then, the operation is

Re: [infinispan-dev] New ISPN github sub-repositories for OData server and ispn-cakery

2014-05-12 Thread Galder ZamarreƱo
Thanks Sanne for getting this up and running, and thanks Tomas for the excellent work with the OData server! Looking forward to seeing how Cakery works :) Cheers, On 06 May 2014, at 13:35, Sanne Grinovero sa...@infinispan.org wrote: Hi all, that looks great! freshly created: -

Re: [infinispan-dev] Reliability of return values

2014-05-12 Thread Dan Berindei
Radim, I would contend that the first and foremost guarantee that put() makes is to leave the cache in a consistent state. So we can't just throw an exception and give up, leaving k=v on one owner and k=null on another. Secondly, put(k, v) being atomic means that it either succeeds, it writes k=v

Re: [infinispan-dev] Reliability of return values

2014-05-12 Thread Sanne Grinovero
I don't think we are in a position to decide what is a reasonable compromise; we can do better. For example - as Radim suggested - it might seem reasonable to have the older value around for a little while. We'll need a little bit of history of values and tombstones anyway for many other reasons.

[infinispan-dev] Infinispan REST CacheStore - OOM

2014-05-12 Thread Sanne Grinovero
Hi all, I'm unable to run the Infinispan testsuite because of OOM exceptions hapening in the testsuite of Infinispan REST CacheStore. Anyone else has seen the same problem? Cheers, Sanne ___ infinispan-dev mailing list infinispan-dev@lists.jboss.org

Re: [infinispan-dev] Reliability of return values

2014-05-12 Thread Radim Vansa
@Dan: It's absolutely correct to do the further writes in order to make the cache consistent, I am not arguing against that. You've fixed the outcome (state of cache) well. My point was that we should let the user know that the value he gets is not 100% correct when we already know that - and

[infinispan-dev] [Search] Handling of mutual dependency with Infinispan

2014-05-12 Thread Sanne Grinovero
Now that finally Infinispan moved to build (and require) Java7, I'm preparing to upgrade the Lucene Directory to Apache Lucene 4.8. Sometimes it's trivial, some others we're out of luck and this is one of such situations: the new Lucene code expects some new methods to create and validate a CRC32

Re: [infinispan-dev] [hibernate-dev] [Search] Handling of mutual dependency with Infinispan

2014-05-12 Thread Emmanuel Bernard
I am not sure I understand everything you said. how about you take 20 mins tomorrow during our Hibernate NoORM team meeting on IRC? Be careful, 20 mins run fast in practice :) On 12 May 2014, at 17:38, Sanne Grinovero sa...@hibernate.org wrote: Now that finally Infinispan moved to build (and

Re: [infinispan-dev] Where's the roadmap?

2014-05-12 Thread Sanne Grinovero
Hi, I think you mentioned having created the roadmap page but I can't find it, and people keep asking about it so I'm probably not the only one not finding it: https://community.jboss.org/message/870798 Could we make it more visible on the website? Cheers, Sanne On 25 February 2014 17:09,