As per the feedback from Ondra and Brent the Reducer's API constraint, as
described below, seem to be too limiting for our users.
AFAIR the main reason for Reducer.reduce to consume and return same types of
objects was for some internal optimisations, but the Combiner as described in
the paper
On 3 Jan 2012, at 17:10, Sanne Grinovero wrote:
Hi Galder,
I agree with you, the command looks like a better place to place the
Flags.
+1. The InvocationContext is something local, so if we need remote propagation
the flags should be associated with the command.
The only mismatch is with
On 3 Jan 2012, at 17:31, Galder Zamarreño wrote:
On Jan 3, 2012, at 2:55 PM, Marko Lukša wrote:
Hey guys.
Aleš Justin and I will be using infinispan's grid file system for Capedwarf.
What's Capedwarf? :)
I have fixed a few issues in GFS. Before I issue a pull request, I need
1. tx2 read data1.
2. it performs a PFER with fails for some random reason. With the new
code you put in, that does not rollback the tx and continue as though
nothing happened.
it's not only with the new code, that's part of PFER's contract.
Or do you need something that would force an
On 15 Dec 2011, at 10:28, Galder Zamarreño wrote:
Hi,
Re: https://issues.jboss.org/browse/ISPN-1615,
https://issues.jboss.org/browse/ISPN-1617 and
http://lists.jboss.org/pipermail/infinispan-dev/2011-November/009577.html
I think in Infinispan 5.1, the fact that caches are either
On 13 Dec 2011, at 14:10, Galder Zamarreño gal...@jboss.org wrote:
Hi all,
Re: https://issues.jboss.org/browse/ISPN-1556
Re: https://github.com/infinispan/infinispan/pull/719/files#r288994
The fix I suggest works well with explicit transactions, but if we leave this
as is, implicit
On 13 Dec 2011, at 15:49, Galder Zamarreño gal...@redhat.com wrote:
On Dec 13, 2011, at 2:39 PM, Sanne Grinovero wrote:
Why would you avoid FORCE_WRITE_LOCK ?
Does the following make sense?
tx.begin()
cache.withFlags(FORCE_WRITE_LOCK).get(…)
tx.commit()
It doesn't in my view.
On 13 Dec 2011, at 16:00, Sanne Grinovero wrote:
On 13 December 2011 13:48, Galder Zamarreño gal...@redhat.com wrote:
On Dec 13, 2011, at 2:39 PM, Sanne Grinovero wrote:
Why would you avoid FORCE_WRITE_LOCK ?
Does the following make sense?
tx.begin()
On 13 Dec 2011, at 17:04, Slorg1 wrote:
Hi,
I guess I will troll a little here but it seems to me that the
implicit transactions are the issue.
What Galder suggested does makes sense( that you would want a failure
to put in the cache in some circumstances to have no incidence) but
some
On 14 Dec 2011, at 15:55, Galder Zamarreño wrote:
On Dec 14, 2011, at 2:45 PM, Mircea Markus wrote:
On 13 Dec 2011, at 16:00, Sanne Grinovero wrote:
On 13 December 2011 13:48, Galder Zamarreño gal...@redhat.com wrote:
On Dec 13, 2011, at 2:39 PM, Sanne Grinovero wrote:
Why would
On 13 Dec 2011, at 19:08, Galder Zamarreño wrote:
On Dec 13, 2011, at 4:04 PM, Slorg1 wrote:
Hi,
I guess I will troll a little here but it seems to me that the
implicit transactions are the issue.
What Galder suggested does makes sense( that you would want a failure
to put in the
On 14 Dec 2011, at 13:44, Dan Berindei wrote:
Hi guys
For a little background, see the discussion at
https://issues.jboss.org/browse/ISPN-1586
How do you feel about discarding the contents of the cache store on all cache
(virtual) nodes except the first to start?
I think that's a that
That screams for Josh Block's builder pattern[1] :)
That would also make more consistent the way we build configs between Embedded
and Remote manages.
What do you guys think?
[1]
http://stackoverflow.com/questions/6174419/joshua-blochs-builder-pattern-and-pmd-warnings
On 13 Dec 2011, at 22:10,
I think Manik is referring to the fact that ISPN's MVCC implementation does
not guarantee serializability.
yes.
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
On 29 Nov 2011, at 14:03, Slorg1 wrote:
Hi,
On Tue, Nov 29, 2011 at 09:00, Galder Zamarreño gal...@redhat.com wrote:
On Nov 28, 2011, at 5:00 PM, Mircea Markus wrote:
Hi,
Now that all the 5.1 major work is done I plan to run some benchmarks
comparing 5.1 with 5.0. It's not only tx
Hi,
Now that all the 5.1 major work is done I plan to run some benchmarks comparing
5.1 with 5.0. It's not only tx stuff I'd like to compare, as some other were
made, so here's my plan of action.
Each of the following benchmarks will be run on local, distributed and
replicated caches:
1. non
I've realized that once i've started implementing :)
On 23 Nov 2011, at 13:29, Pete Muir pm...@redhat.com wrote:
This won't work. Until we totally switch over it has to be in both places.
On 23 Nov 2011, at 13:16, Manik Surtani wrote:
+1 to (b)
On 22 Nov 2011, at 15:06, Mircea Markus
On 23 Nov 2011, at 14:15, Pete Muir wrote:
All,
Now that the new config API is in, and the basic teething pains resolved
(thanks to Mircea and Kevin!), this is my plan to eradicate the old config:
perhaps make the internals use the new config would be the first thing to do
IMO - if new
Read more here:
http://infinispan.blogspot.com/2011/11/more-on-transaction-performance.html___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Mainly what is transaction related, i.e. the autoCommit functionality.
On 22 Nov 2011, at 11:02, Manik Surtani wrote:
What functionality do you want to split out between the two impls?
On 22 Nov 2011, at 08:13, Dan Berindei wrote:
Any pros?
On Tue, Nov 22, 2011 at 2:11 AM, Mircea
On 17 Nov 2011, at 15:25, Galder Zamarreño wrote:
For more background info, see:
http://community.jboss.org/message/636797#636797
I also think this might be confusing for users.
What about:
a) don't inject a transaction for PFER. That's an easy change.
b) if autoCommit is off and PFER is not
On 17 Nov 2011, at 15:39, Slorg1 wrote:
Hi all,
See comment below,
On Thu, Nov 17, 2011 at 10:20, Galder Zamarreño gal...@redhat.com wrote:
On Nov 17, 2011, at 2:54 PM, Manik Surtani wrote:
On 17 Nov 2011, at 09:30, Galder Zamarreño wrote:
Hi,
Forcing caches to be either
On 22 Nov 2011, at 19:13, Slorg1 wrote:
Hi,
I would like to take some time and make a proper answer to Galder,
However, for this quick remark please see below:
On Tue, Nov 22, 2011 at 14:07, Mircea Markus mircea.mar...@jboss.com wrote:
On 17 Nov 2011, at 15:25, Galder Zamarreño
By reading the key features seems like they described Infinispan architecture.
Hotrod is a much better name than NoSql database driver :)
On 17 Nov 2011, at 07:45, Tristan Tarrant wrote:
It seems the big guys have produced a NoSQL database. It looks like a
cross between Coherence and
Hi,
The DistributionInterceptor can be simplified significantly now that we are
supporting transactional or non transactional caches.
Looking at it I've found an significant performance issues though: seems like
for each put we do, if the unreliableReturnValues is disabled (that's the
default,
After updating from Git I get the following error[1]
Guess it has to do with the new config changes?
[1]
Generating schema file in
/Users/mmarkus/github/ispn/core/src/main/resources/schema
Failed generating schema file
com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException: 3 counts
On 21 Nov 2011, at 22:26, Manik Surtani wrote:
On 21 Nov 2011, at 18:01, Mircea Markus wrote:
Hi,
The DistributionInterceptor can be simplified significantly now that we are
supporting transactional or non transactional caches.
Looking at it I've found an significant performance
Thank you.
On 21 Nov 2011, at 23:26, Galder Zamarreño wrote:
Fixed:
https://github.com/infinispan/infinispan/commit/8140c22f17ca9b01617bb10f01c7160815187aa7
On Nov 21, 2011, at 10:55 PM, Mircea Markus wrote:
After updating from Git I get the following error[1]
Guess it has to do
Hi,
I'm happy to announce that all the transaction improvements scheduled for 5.1
are now in master:
- optimistic transactions [1]
- single lock owner [2]
- lock reordering (to be released in next BETA) [3]
On top of this some very significant performance improvements were made for
for you.
Cheers,
Sebastiano
Il 10/11/11 01:54, Mircea Markus ha scritto:
On 7 Nov 2011, at 16:22, Sebastiano Peluso wrote:
Il 07/11/11 15:05, Galder Zamarreño ha scritto:
Thx Sebastiano. Would you mind issuing a pull request for your tpcc branch
so that we can integrate
Hi,
Several identical classes are duplicated in both common and api modules.
mvn install still works, but the (some) IDEs have problems building
Infinispan.
This patch[1] removes them from the commons module, as this one already depends
on the api module.
The classes are:
-AdvancedExternalizer
On 7 Nov 2011, at 16:22, Sebastiano Peluso wrote:
Il 07/11/11 15:05, Galder Zamarreño ha scritto:
Thx Sebastiano. Would you mind issuing a pull request for your tpcc branch
so that we can integrate it into Radargun?
Yes of course.
Hi Sebastiano,
if you need any help on this please let
Hi guys,
The single lock owner stuff is ready for review. It's a massive change so I'd
expect the review process to take some days. Can you please take a look and
comment?
JIRA is: https://issues.jboss.org/browse/ISPN-1137
Pull request: https://github.com/infinispan/infinispan/pull/574
On 20 Oct 2011, at 16:18, Sanne Grinovero wrote:
Via twitter and Hibernate forums, @astralbodies seems to be doing some
interesting high performance *writing* stuff with Hibernate Search,
but in his experience Hibernate Search on disk is pretty fast, not so
the Search + Infinispan
And Mircea?
My single lock task won't make it today. Hope it will be finished by Wen
morning.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
That's very good news! You should advertise such changes at least
dropping a line here; indeed you might remember me adding SKIP_LOCK in
many places to prevent this, not sure if I was skipping the ones which
where needed for cacheloaders consistency.. we'll see.
I'll keep that in mind :)
On 18 Oct 2011, at 13:44, Pete Muir wrote:
On 17 Oct 2011, at 23:56, Mircea Markus wrote:
On 14 Oct 2011, at 17:51, Pete Muir wrote:
In doing so I moved all the of the interfaces and classes to be top level.
That is the stuff within FluentConfiguration?
I wish Configuration would
On 18 Oct 2011, at 12:05, Sanne Grinovero wrote:
Not because of the cost of reading the clock, my main motivation is
that we artificially create cache misses which might be very expensive
to the client code.
On top of that, the fact that this check also has a cost - not arguing
how low -
On 17 Oct 2011, at 18:21, Dan Berindei wrote:
On Mon, Oct 17, 2011 at 7:51 PM, Sanne Grinovero sa...@infinispan.org wrote:
I've noticed that every time we perform a get() operation (or any
other retrieval) the value is NOT returned to the client if it's
expired, which is going to receive a
On 17 Oct 2011, at 14:13, Sanne Grinovero wrote:
Very interesting, I knew that in Windows currentTimeMillis() basically
just reads a volatile because I got bit by the 15 millisecond accuracy
issue before, so I thought it would always be very fast. I had no idea
on Linux it would have the
On 17 Oct 2011, at 12:27, Sanne Grinovero wrote:
On 17 October 2011 10:19, Mircea Markus mircea.mar...@jboss.com wrote:
On 17 Oct 2011, at 09:13, Dan Berindei wrote:
[cut]
2) This one is a bit technical. What should we do if tx1 deletes entire
AtomicMap while tx2 updates entries
On 14 Oct 2011, at 21:36, Olaf Bergner wrote:
Hi Ales,
yes, that sounds reasonable.
+1. Guess that would be an overloaded version of the existing method?
In fact, I have been worrying about the user relinquishing control over how
Infinispan handles streaming large objects. One quick
On 14 Oct 2011, at 17:51, Pete Muir wrote:
In doing so I moved all the of the interfaces and classes to be top level.
That is the stuff within FluentConfiguration?
I wish Configuration would have the same fate as well: is always a PITA to
browse/update subclasses in that monster.
On 14 Oct 2011, at 17:40, Pete Muir wrote:
What is the use case for that method? I've never know anyone actually want to
export a running config as XML. So I was planning to loose it.
This option originated was initially requested by a community member [1] who
needed it. There's also
On 14 Oct 2011, at 18:20, Pete Muir wrote:
As I said, for Martin, it's better to test the cache functionality
(end-to-end testing) vs unit testing this.
This is going to be a lot harder to support as we move away from JAXB.
Right, that's a good point.
On 12 Oct 2011, at 22:21, Vladimir Blagojevic wrote:
Hey guys,
After endless hours of super interesting hacking I think this one is
close to integration now. While you guys review it I'll tidy up javadoc
and amend the pull.
I've added my comments to the pull request.
A few notes. I kept
Hey guys,
Re: https://issues.jboss.org/browse/ISPN-1396
While looking into this, I've discovered that we have been creating
executors in cache level components, where we're calling submit from
@Listener implementations.
For example, BaseStateTransferManagerImpl.ViewChangeListener
On 5 Oct 2011, at 22:58, Vladimir Blagojevic wrote:
Hey guys,
I about to integrate FineGrainedAtomicMap into master but before I do I
need your feedback. I particularly need feedback from users who where
eagerly awaiting this feature (Sanne and others) and possibly their
use/test cases
http://infinispan.blogspot.com/2011/10/transaction-remake-in-infinispan-51.html___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
I'll be looking at single node locking mode[1] and if time allows lock
reordering[2]
[1] https://issues.jboss.org/browse/ISPN-1137
[2] https://issues.jboss.org/browse/ISPN-1132
On 4 Oct 2011, at 14:38, Galder Zamarreño wrote:
Infinispan 5.1.0.BETA1 is out, see http://goo.gl/VHWAT
As you
On 4 Oct 2011, at 13:29, Galder Zamarreño wrote:
Thanks Mircea!! Very nicely written. I had a question:
thanks you
It's unclear to the reader which transaction manager is used by default when
TRANSACTIONAL is set. Before you had to manually set the transaction manager,
but this is now
On 3 Oct 2011, at 01:09, Manik Surtani wrote:
On 28 Sep 2011, at 10:56, Dan Berindei wrote:
I'm not sure if the comment is valid though, since the old
StateTransferManager had priority 55 and it also cleared the data
container before applying the state from the coordinator. I'm not sure
On 23 Sep 2009, at 18:23, Manik Surtani wrote:
In general though, the problem with the visitor pattern is that it
does not work well for situations where you have an arbitrary (and
dynamically changing) number of command types. Visitors worked well
for us for invocations since we have
rofl!
I'm a bit beyond with the emails obviously!
On 4 Oct 2011, at 23:01, Mircea Markus wrote:
On 23 Sep 2009, at 18:23, Manik Surtani wrote:
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo
On 30 Sep 2011, at 15:19, Sanne Grinovero wrote:
Hi all,
the master branch is not compiling since the last commit b6de38a,
but even before that it's not very clean: I'm seeing many branch
merges, history is an mess.
You must be referring to:
de98c55 - Mircea Markus, 22 hours ago : Merge
On 30 Sep 2011, at 16:16, Sanne Grinovero wrote:
A decent operating system can do some work in background while not
killing the user capability to do something :)
Try run it on a i2 first :-)
___
infinispan-dev mailing list
2011, at 17:41, David M. Lloyd wrote:
On 09/28/2011 11:35 AM, Mircea Markus wrote:
Hi,
I'm not aware of any convention on using trace vs log.isTraceEnabled() to
guard the trace statements.
if (trace) log.trace(some request related stuff)
vs
if (log.isTraceEnabled()) log.trace(some request
On 28 Sep 2011, at 10:05, Galder Zamarreño wrote:
Thanks Mircea. I've made some comments.
Thanks, I've replied and updated the pull request.
Also added a summary: https://github.com/infinispan/infinispan/pull/551
To all:
If you're gonna submit a big pull req, please use the description
On 28 Sep 2011, at 15:02, Galder Zamarreño wrote:
Thanks Mircea :)
To all: I've had a look and made some comments, but this patch is definitely
worth another look by at least another person.
+1
Manik and Sanne are good candidates.
___
Nice stuff.
Some q:
- When a node CM that has c1 and c2 caches running on it goes down, you'll end
up having REQUEST_LEAVE(c1) and REQUEST_LEAVE(c2) at the same time. Is this
handled in serial or in parallel?
- The view updates can be disabled dynamically (DISABLE_VIEW_UPDATES).
Shouldn't
Hi,
ATM the default cache transaction model in 5.1 is transactional. The main
reason transactional cache was chosen by default was backward compatibility:
existing code that access the cache in a mixed way (i.e. both transactional and
non transactional) would fail if the default mode is non
I haven't seen this on my Mac env.
On 27 Sep 2011, at 08:38, Dan Berindei wrote:
I've seen the same thing on Linux but a lot less often, about 4 times
in the whole test suite with DEBUG logging. I didn't see it at all
when I switched TRACE logging on.
Dan
On Mon, Sep 26, 2011 at 7:22
Hi,
I've issued a pull request for SPN-1131 (Add support for optimistic locking).
My last run brought the same number of test failures in master and in my
branch, so might be a good idea to integrate it first and then continue fixing
tests.
Cheers,
Mircea
On 16 Sep 2011, at 12:49, Manik Surtani wrote:
I'm hoping to see some of the state transfer/rehash stuff as well as the JTA
refactoring pieces here. :)
The Optimistic Locking stuff is not there yet: I had to do some significant
changes to the original design, mainly around auto commit
Hi,
ATM I cannot enable both batching and auto-commit[1] because the way the
batching is implemented:
- it starts a tx, suspends it and and holds it in a thread local so that when a
put arrives it can resume it
- when I do a put in a batch, the auto-commit code which runs first doesn't see
any
On 13 Sep 2011, at 17:22, Galder Zamarreño wrote:
Hi,
I'm looking at this failure http://goo.gl/NQw4h and I'm wondering why
org.infinispan.distribution.RehashInProgressException: Timed out waiting for
the transaction lock is thrown?
This is thrown DistTxInterceptor which is added by
Hi,
ATM a cache is marked as transactional by setting the
transactionalManagerLookup, transactionalManagerLookupClass or enable batching.
This is a bit hard to explain/clumsy and also doesn't work well with the xml
config: if one wants the default cache to be transactional and a named cache
, Mircea Markus mircea.mar...@jboss.com wrote:
Hi,
ATM a cache is marked as transactional by setting the
transactionalManagerLookup, transactionalManagerLookupClass or enable
batching.
This is a bit hard to explain/clumsy and also doesn't work well with the xml
config: if one wants the default
Thank you!
On 12 Sep 2011, at 16:09, Pete Muir wrote:
This area currently under discussion in JSR-107.
https://github.com/jsr107/jsr107spec/issues/16
Perhaps you should raise this on the same issue as a related config issue?
someone else was quicker :)
up in very complex user and maintenance
scenarios.
Cheers,
Mircea
[1] if so we can deprecate these methods as we already achieve the same
functionality in the case of pessimistic locking by using Flag.FORCE_WRITE_LOCK
On 7 Sep 2011, at 17:55, Mircea Markus wrote:
Hi,
Do we want
Hi,
Do we want to support explicit locking within optimistic locking scheme? This
is something that is currently supported, i.e. one can used the advanced
cache's lock method on an optimistic cache.
My concern is mainly related to the existing use cases, is there a need for
allowing this?
Hi,
In default mode, when:
advancedCache.withFlags(Flag.FORCE_WRITE_LOCK).get(k)
gets executed a W lock is acquired on k. With the new optimistic locking
model we only acquire a locks at prepare time, so the semantic of the above
call might need to change.
What I have in mind is to force the W
On 3 Aug 2011, at 19:39, Sanne Grinovero wrote:
Hello all,
could anybody explain why the ComponentRegistry is performing the
following operation ?
The method
AbstractComponentRegistry#getFromConfiguration(ClassT)
which invokes:
org.infinispan.util.BeanUtils.getterMethod(Class, Class)
On 1 Aug 2011, at 17:36, Sanne Grinovero wrote:
Hi Mircea,
what you propose has a strong impact on existing use cases.
Not having batching kills the Lucene performance, and using
transactions is not an option unless the whole state of the index can
fit in memory, which is not the use case
On 1 Aug 2011, at 17:55, Emmanuel Bernard wrote:
On 1 août 2011, at 18:16, Mircea Markus wrote:
Hi,
These is a draft of the config changes I plan to add with ISPN-1131, can you
please comment?
1.
transaction lockingMode=optimistic/
The lockingMode attribute can have two values
On 2 Aug 2011, at 15:44, Manik Surtani wrote:
Guys
I've put together a high level planning doc for 5.1. Please have a look and
see if I've missed out on anything. Any other high-level JIRAs should be
linked to this doc, and if JIRAs for certain things don't exist, please
create them.
I'm afraid we're mixing concerns, I didn't ask to allow both
transactional and non-transactional operations on the same cache, I
understand there are good reasons to not support that.
What I need is control for batching, i.e. be able to send a set of
writes on different keys at one specific
On 1 Aug 2011, at 15:52, Pete Muir wrote:
All,
We've had various bitty discussions about how to handle different versions of
the documentation now that we've moved to Confluence.
We had a discussion on IRC, from which I wrote up the notes below. The short
version is that for each
I've added:
https://docs.jboss.org/author/display/ISPN/JTA+synchronization
https://docs.jboss.org/author/display/ISPN/2-phase+commit
https://docs.jboss.org/author/display/ISPN/XA+resource
I've removed 1PC page as there's no such thing as an 1PC - it's just something
we internally use to refer to
This is isolated and won't break API compatibility so I think it makes sense.
On 19 Jul 2011, at 09:50, Galder Zamarreño wrote:
Hi all,
What do people think of changing the addListener() APIs to be more fluent?
We could either:
1. Change Listenable to be ListenableT and then have:
On 15 Jul 2011, at 20:00, Dan Berindei wrote:
Hi guys
While fixing https://issues.jboss.org/browse/ISPN-1243 I found that in
certain cases state transfer will copy the in-memory data twice: first
when copying the in-memory data and then again while copying the
persistent data.
I was
On 11-07-15 7:53 AM, Mircea Markus wrote:
Hi,
As there is a high community demand for having these operations in place,
and most of these are targeted for post 5.1 releases, I thought about a
workaround for having this functionality in place.
I hijacked Hotrod's put operation and added
On 19 Jul 2011, at 17:35, Bela Ban wrote:
On 7/19/11 5:36 PM, Mircea Markus wrote:
On 19 Jul 2011, at 09:38, Galder Zamarreño wrote:
Hi all,
I've noticed a problem with the way we test state transfer in our
testsuite. For example, take
https://github.com/infinispan/infinispan
On 19 Jul 2011, at 17:39, Bela Ban wrote:
On 7/19/11 5:36 PM, Mircea Markus wrote:
I think that even if you fix this in the unit tests it still might happen in
a real-life situation, i.e. start two nodes and instead of forming a cluster
they'd first form two clusters and then merge
On 19 Jul 2011, at 18:00, Bela Ban wrote:
On 7/19/11 6:49 PM, Mircea Markus wrote:
When there's a merge into {A,B} and A turns out to be the (existing and
new) primary owner of x, then it'll update B.x=1 (*if* B is the backup
owner of x, or else B will remove x).
This is precisely
On 15 Jul 2011, at 13:10, Sanne Grinovero wrote:
Hi,
in the case of Lucene Queries my main concern is about how to a) properly
serialize the query b) how to stream the resusts back, possibly having some
pagination / flow control.
If you want we can have a look together to see wether this
, no timeouts, no undo operations. what am I missing?
Cheers,
Sanne
2011/7/6 Mircea Markus mircea.mar...@jboss.com:
On 6 Jul 2011, at 09:00, Paolo Romano wrote:
On 7/5/11 3:47 PM, Mircea Markus wrote:
On 5 Jul 2011, at 15:39, Manik Surtani wrote:
Good stuff, shame about the RPC count
a call from N1 to
N2
b@N4 (RPC 2) - That corresponds to to 5/6 arrows?
I've also updated this, thanks!
On Jul 5, 2011, at 3:25 PM, Mircea Markus wrote:
Hi,
This is the document describing the incremental optimistic locking Dan and
myself discussed last week:
http
On 8 Jul 2011, at 13:27, Manik Surtani wrote:
Do we want to come up with a list of terms that definitely need defining, at
least from where we stand now? More will be added incrementally, for sure.
* Data Grid
http://www.jroller.com/cpurdy/entry/defining_a_data_grid
It doesn't sound like
On 11 Jul 2011, at 12:27, Sanne Grinovero wrote:
2011/7/11 Mircea Markus mircea.mar...@jboss.com:
On 6 Jul 2011, at 16:41, Sanne Grinovero wrote:
Very nice design, congratulations.
Second picture is missing a final 4 step returning the ACK to N1 right?
yes, this happens when 1a, 1b
On 11 Jul 2011, at 10:45, Manik Surtani wrote:
On 4 Jul 2011, at 07:57, Galder Zamarreño wrote:
I get the feeling that those atomic operations are particularly useful when
transactions are not used cos they allow you to reduce to cache operations
to one, hence avoiding the need to use
On 4 Jul 2011, at 07:57, Galder Zamarreño wrote:
Do these atomic operations really make sense within an (optimitic)
transaction?
For example, putIfAbsent(): it stores a k,v pair if the key is not present.
But the key about it's usability is that the return of putIfAbsent can tell
you
On 5 Jul 2011, at 11:39, Sanne Grinovero wrote:
2011/7/5 Dan Berindei dan.berin...@gmail.com:
On Tue, Jul 5, 2011 at 12:46 PM, Sanne Grinovero sa...@infinispan.org
wrote:
2011/7/5 Galder Zamarreño gal...@redhat.com:
On Jul 4, 2011, at 11:25 AM, Sanne Grinovero wrote:
I agree they
On 5 Jul 2011, at 14:04, Sanne Grinovero wrote:
2011/7/5 Dan Berindei dan.berin...@gmail.com:
On Tue, Jul 5, 2011 at 1:39 PM, Sanne Grinovero sa...@infinispan.org wrote:
2011/7/5 Dan Berindei dan.berin...@gmail.com:
Here is a contrived example:
1. Start tx Tx1
2. cache.get(k) - v0
3.
On 5 Jul 2011, at 11:45, Dan Berindei dan.berin...@gmail.com wrote:
On Tue, Jul 5, 2011 at 12:23 PM, Galder Zamarreño gal...@redhat.com wrote:
On Jul 4, 2011, at 11:25 AM, Sanne Grinovero wrote:
I agree they don't make sense, but only in the sense of exposed API
during a
On 6 Jul 2011, at 09:00, Paolo Romano wrote:
On 7/5/11 3:47 PM, Mircea Markus wrote:
On 5 Jul 2011, at 15:39, Manik Surtani wrote:
Good stuff, shame about the RPC count . ;)
yeah. Still very valid when there are deadlocks, guess figures will tell us
more precisely what the gain is
I
Good stuff!
On 4 Jul 2011, at 18:18, Pete Muir wrote:
First draft is up at
https://docs.jboss.org/author/display/ISPN/Contributing+to+Infinispan#ContributingtoInfinispan-WritingDocumentationandFAQs
Please review it, let me know if you spot any errors ;-)
I've tried to follow my own
On 5 Jul 2011, at 15:39, Manik Surtani wrote:
Good stuff, shame about the RPC count . ;)
yeah. Still very valid when there are deadlocks, guess figures will tell us
more precisely what the gain is
___
infinispan-dev mailing list
On 10 Jun 2011, at 13:42, Manik Surtani wrote:
So I've taken on this sub-task from Sanne (ISPN-1169), and here is the deal:
BCHM analyses whether or not to evict stuff every time an operation (put,
get, replace) is run, based on the configured eviction policy (LIRS, LRU or
NONE). It
2) with async stores, the issue is back. The value is not going to be
found while it's in flight in the async storage queue; so unless you
want to avoid supporting it for now, the actual removal from the
container should be performed from the async cache loader code.
Ugh - yes, I agree.
801 - 900 of 986 matches
Mail list logo
