branched for 4.2.x
by Mircea Markus
Hi,
I've taken a new branch[1] for development on 4.2. This was taken out of 4.1.x branch today. I will merge everything developed in 4.1.x after the branch was take into 4.2.x before any release we'll do on 4.2.x.
We'll also port all the stuff from 4.1.x to trunk.
Cheers,
Mircea
[1] https://svn.jboss.org/repos/infinispan/branches/4.2.x.
16 years, 1 month
big patch about imports and typos
by Sanne Grinovero
Hello,
I've been browsing through the sources of all core and some other
modules, and while reading I couldn't stop my compulsion for fixing
some typos in javadoc and code comments, and removing the unused
import statements.
In some cases the imports are also binding to Sun's JRE, for example:
import com.sun.corba.se.impl.orb.ORBConfiguratorImpl;
So this patch got quite large and all-around, would this be a good
timing to apply it, or should I isolate and apply only the
non-standard imports fix?
Also this makes me think we should setup a CI server to compile
Infinispan on a non-sun JVM, as these import statements are introduced
by intelliJ AFAIK.
Sanne
16 years, 1 month
Hibernate OGM step 1: CRUD
by Emmanuel Bernard
Hibernate OGM does CRUD over Infinispan :)
I've push to GitHub the first version of Hibernate OGM that does CRUD operations on simple entities.
A simple entity is defined as:
- no inheritance
- no embeddable object
- no association
- support for a subset of the JDK basic types (thought that's trivial to enhance)
But that will come.
So far I have little to no change to hibernate Core (though some duplication / quasi-duplication).
Emmanuel
16 years, 2 months
Rehash process
by Israel Lacerra
Hello everyone...
I'm trying to understand how rehash happens. Could someone give me a little
clue? Is there a wiki about this?
thanks!
Israel Lacerra
16 years, 2 months
codename for 4.2
by Mircea Markus
Hi,
Shall we continue the beer tradition?
I'll go for the beer I've grown up with, which is Ursus.
Other suggestions?
Cheers,
Mircea
16 years, 2 months
Future: async marshalling should be false by default
by Galder Zamarreño
Hi,
I'm in the middle of writing a wiki on the different asynchronous options, including the effect they have on reordering, and I was considering the following:
For 5.0, we should make async marshalling should be turned off by default. When it's on, there's risk of reordering and when it's off, async is slower. I'd rather have a slower solution by default rather than one that can cause data consistency issues in applications that make multiple modifications on the same key. If you only make one modification per k/v, you're fine, otherwise the reordering risk is there.
Thoughts?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
16 years, 2 months
Passivation + eviction with new bounded data containers
by Manik Surtani
Guys,
A problem with eviction, passivation and the new data container has been reported in ISPN-582. A quick summary, eviction now takes place within the data container as containers are naturally bounded. This means once a size threshold is reached entries are automatically removed. More accurately, they are just stored in a separate collection and the eviction thread picks them off this collection and calls evict() on each one. Now we have some issues here:
1) This means notifications are often dispatched later than when the actual eviction takes place. No biggie though, eviction is best-effort.
2) Passivation too is delayed. This is huge. This means there is a window where a thread may ask for an entry but the entry is in limbo - not in the data container, not yet passivated to a cache store.
I am currently testing a fix for this, where the data container handles notification + passivation (if enabled) directly, when an entry is evicted from the primary data collection. So far this seems to work, however this all happens on the caller's thread now. So in a sense, I wonder if the EvictionThreadPolicy is relevant.
However, my fix is only a temporary one - since it still doesn't work when using LIRS, as LIRS maintains 2 separate stacks and only the LIR stack is queried on a get and not the HIR stack. So for now we should consider LIRS + Passivation as an invalid configuration.
https://jira.jboss.org/browse/ISPN-598
Anyway the key thing is, it all works fine now, so lets open this discussion again when Vladimir is back from vacation.
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
16 years, 2 months
TwoWayKey2StringMapper and keys which are never stored
by Sanne Grinovero
Hello,
While implementing a TwoWayKey2StringMapper for the Lucene Directory I
noticed that
it's mandatory to implement two-way conversions also for keys which
I'm not going to ever store.
This directory has some different keys types, some need to be
eventually storable (if a Store is configured),
while some others are always handled with the Flag.SKIP_CACHE_STORE
and should never be stored.
Still if I don't implement conversion of this type, I get a stacktrace
about this type being not supported by
the LuceneKey2StringMapper during rehashing.
I'm not able to grasp the reason for this two-way key conversion to be
needed for rehashing - I can only guess that you have good reasons for
that - but I'm totally lost at why this implementation is being called
for keys which I actually want to make sure they are never stored.
Could this limitation be removed, or am I mandated to use two
differently configured caches to store this information?
Regards,
Sanne
16 years, 2 months
