Starting caches in parallel
by Dan Berindei
Hi guys
I've found a deadlock with transactions spanning multiple caches
during rehashing if the joiner's caches are started sequentially (for
more details see https://gist.github.com/1124740)
After discussing a bit on IRC with Manik and Galderz it appears the
only solution for 5.0.0.FINAL would be to have a mechanism to start
all the caches in parallel.
There are several options to implement that. All of them require the
users to know that they should create the caches in parallel at
application startup to avoid problems.
1. Advise the users about the problem, but let them create their own
threads and call EmbeddedCacheManager.getCache() on those threads.
2. Add a method EmbeddedCacheManager.getCaches() to start multiple
caches in parallel.
This is not as straightforward as it may seem, first there is a
question of whether to use template parameters or not:
2.a. Set<Cache> getCaches(String... cacheNames);
vs
2.b. Set<Cache<K, V>> getCaches(String... cacheNames);
I don't think having the same K and V for all the caches is going to
be very common, so I'd go with 2.a.
Then there is the problem of how to request the default cache. I think
"" should be fine, but we'd need to document it and also change the
regular getCache() methods to accept it.
3. Add an async version of EmbeddedCacheManager.getCache():
Future<Cache<K, V>> getCacheAsync(String cacheName);
Future<Cache<K, V>> getCacheAsync();
This nicely sidesteps the generics issue in solution 2 and it's also
easier for the users than solution 1, so it's currently my favourite.
What do you think?
Dan
15 years, 1 month
BeanUtils.getterMethod
by Sanne Grinovero
Hello all,
could anybody explain why the ComponentRegistry is performing the
following operation ?
The method
AbstractComponentRegistry#getFromConfiguration(Class<T>)
which invokes:
org.infinispan.util.BeanUtils.getterMethod(Class, Class)
and this one throws thousands of NoSuchMethodException if you have a
rather large number of caches to see if it can find a matching
element, and seems to slow down startup significantly in some cases.
Throwing such an exception seems to be expected since it's inspecting
Configuration.class (statically!) - it always returns null.
I've tried to remove all those methods and short-circuit a nicely
performing "return null": not a single test failed.
(No test failed -> useless code, or missing tests)
Shall I remove the code?
Cheers,
Sanne
15 years, 1 month
build failures on jenkins
by Sanne Grinovero
Hi,
it seems that the Infinispan-lucene-master task relies on deployed
snapshots of core, and since there aren't any for 5.1, it's failing.
https://infinispan.ci.cloudbees.com/job/Infinispan-lucene-master-TRACE/73...
So even if I deploy a snapshot, it means the tests are always run
against an older core version, whatever happened to be deployed,
instead of reporting about the last version.
Would it be reasonable to have the primary job
(Infinispan-master-JDK6-tcp) deploy snapshots at each execution? I'd
like it to deploy to jboss.org, but it might generate quite some load
and would need us to give him permissions.
I see there is an option "Deploy artifacts to my Private CloudBees
Repository", not sure if we have such a thing, nor if the secondary
module will find it from there.
Cheers,
Sanne
15 years, 1 month
changes introduced by optimistic transactions
by Mircea Markus
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: optimistic(default) and pessimistic. If pessimistic is specified then this hase the same meaning as "useEagerLocking=true" (useEagerLocking to be deprecated).
The fluent API looks as follows:
- config.fluent().transaction().lockingModeOptimistic();
- config.fluent().transaction().lockingModePessimistic();
2.
An important restriction introduced by ISPN-1131 is the fact that a cache cannot be used in a mixed mode: i.e. all operations run within transactions or non does.
- by specifying a "transactionManagerLookup" the user marks the cache as transactional.
- there also is an "autoCommit" attribute: <transaction autoCommit="true"/>
- if true (default), then user doesn't have to explicitly start and finish single-operation transactions, but a transaction is started under the hood on user's behalf
- if false and a call is made out of a transaction's scope then an exception is thrown
- if the cache is not transactional then autoCommit is ignored
- a cache that supports batch operations is implicitly transactional. That's because batching is based on transactions.
and the fluent API:
config.fluent().transaction().autoCommit(true);
Cheers,
Mircea
15 years, 1 month
Documentation versioning
by Pete Muir
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 minor version (x.y) of Infinispan we will clone the Infinispan space. I would envisage this happening shortly after a release.
The .org team will add a couple of plugins to Confluence to make this work nicely. The first is a plugin to actually clone the space. The second allows us to display spaces hierarchically, so that we can something like:
Infinispan:
| - 4.0
| - 4.1
| - 4.2
| - 5.0
\ - HEAD
This means there is no need to indicate in the text the releases the page is relevant for. You may still wish to add a note (admonition) that the feature was introduced in a particular version to guide the reader. I will add an example of this to the style guide.
HTH
Pete
=========================================================
Use markup inline (feature available since XXX)
------------------------
- Fixes are very hard
- Will get messy quickly
- Error prone
- hard for use to read
+ No infrastructure needed
Conclusion: Not suitable, it's just too messy
Export to static format (PDF/HTML)
----------------------------------------------
+ Confluence / Scroll Wiki make this easy to achieve
- docs cannot then be fixed post release
Conclusion: Not suitable, lack of post release edit is a killer
Export to docbook
------------------------
+ Good idea in principle, as it allows us to use existing infra such as git to store docs from then on
- Requires two different approaches to edit docs depending on what version they work on, which is confusing for people
- current process is very manual (export manually, transform manually, add release info manually)
- requires "double qa" - we check all the docs on confluence to make sure they look nice and then have to do so again for the exported version
Conclusion: Not suitable, it's good idea, but current process is too manual, will re-evaluate when this is improved
Copy subtree of pages
------------------------------
+ Fit's structure well as it keeps everything within a space
+ Allows post release editing within confluence
- Plugin for this looks unsupported
- Would need to be configurable to rename pages and update all links including includes etc.
Conclusion: Not suitable, plugin isn't mature enough, otherwise a good approach
Copy space
---------------
+ Structure is fine
+ Allows post release editing within confluence
+ Plugin looks stable, no naming issues
+ This is the approach taken by others who use confluence for docs (including atlassian)
Conclusion: This looks like the best option open right now.
15 years, 1 month
