Spliting Lucene segments in Infinispan Directory
by Łukasz Moreń
Hi,
The JBoss Cache directory for Lucene splits each Lucene segment into pieces
- chunks. Similar solutions exists in Lucene RamDirectory implementation.
Are there some pros to use such splitting approach in Infinispan directory
case? Some buffer size is recommended?
Lukasz
14 years, 8 months
Vacation till 17th of August
by Hardy Ferentschik
Hi there,
just letting you know that I will be on vacation as of now.
Trying to reach me will be futile since I will be in the North of Sweden
completely unplugged :)
Enjoy!
Hardy
14 years, 8 months
Fences API to threadsafely initialize no-argument constructor objects
by Sanne Grinovero
Hi Hardy,
sorry for the late answer, I remember some discussions between us
about the coming of an API to help us with threadsafe objects
which couldn't use contructor initialization (and hence final fields)
but wasn't able to find the API back I spoke about.
The javadoc for jsr166y : http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166ydocs/
but the API I was most interested in somehow disappeared and I
couldn't remember the name.
It is called Fences (at list the article back) and is an extension of jsr166y
Quoting part of the javadoc:
"With care, a fence may be used to obtain the memory safety effects of
final for a field that cannot be declared as final, because its
primary initialization cannot be performed in a constructor, in turn
because it is used in a framework requiring that all classes have a
no-argument constructor. "
http://gee.cs.oswego.edu/dl/jsr166/dist/docs/java/util/concurrent/atomic/...
the problem is that jsr166y is a preview of the concurrency APIs of
Java7, and as such can be backported
(there's a jar already you could depend on to make it work on JDK 5
and 6), but the Fences
rely on JVM support so they can't be backported: so they are not
included in jsr166y.
That makes it quite useless for Search and Bean Validation :-( but
it's still interesting to read about it
as Fences documentation is a good reference for all the pitfalls in
design of a "framework requiring that all classes have a no-argument
constructor".
regards,
Sanne
14 years, 9 months
Re: [hibernate-dev] @Cacheable
by Emmanuel Bernard
On Jul 15, 2009, at 22:01, Steve Ebersole wrote:
> On Wed, 2009-07-15 at 16:26 -0400, Emmanuel Bernard wrote:
>> The spec made an incursion into caching metadata and allow to cache
>> some classes and not others. So far so good. But that includes the
>> scenario where these classes are inside the same class hierarchy
>>
>> Case 1
>>
>> @Cacheable(false)
>> class Person {}
>>
>> @Cacheable(true)
>> class customer extends Person {}
>>
>> Case 2
>>
>> @Cacheable(true)
>> class Person {}
>>
>> @Cacheable(false)
>> class customer extends Person {}
>>
>> Can we support that?
> We store hierarchy in a single region based on the root entity. In
> other words, in this case Person is root entity; that is the cache
> region for both Person and for Customer in this example. That's what
> allows us to serve from the cache properly when they say "load
> Person X"
> given that that data might identify either a Person or a Customer.
> Supporting this mixing would destroy that Hibernate feature and take a
> lot of time to do so to boot.
Let me try and parse that properly.
Let's assume two scenarii:
1. we still enforce one region per class hierarchy
in this case, would it hurt to have a given class / subclass not
cached whereas others are?
we are still looking for a single region
2. we don't enforce one region per class hierarchy
in this case, we need to precompute the list of regions for a given
class hierarchy and ask each region to answer the question the way
Hibernate does today.
I can see that as slow(er)
Also you have more regions to start and that's the slowness you are
referring to at boot time, right?
>
>> Second problem, they want "easy" caching ootb but do not define
>> caching strategies. What would be a good caching strategy default
>> if a
>> class is marked as cached but no caching strategy is defined?
> Well the answer as to the best default AccessStrategy to use is
> unfortunately going to depend. It depends on the RegionFactory
> defined
> and various other configuration choices.
>
> Let's assume that user still needs to define the RegionFactory. I can
> see delegating this choice to the defined RegionFactory. It would
> still
> depend on other variables like are we using some form of JTA-based
> transactions and have access to the TransactionManager, etc. But its
> much better than Hibernate code needing to intrinsically understand
> the
> capabilities of all RegionFactory impls (what about a custom
> RegionFactory???). Maybe this looks something like a new
> RegionFactory
> method: AccessType getDefaultAccessType(???) (AccessType is the enum
> for
> TRANSACTIONAL, READ_ONLY, etc). Not sure what all we would need to
> pass
> in to the method; probably the TransactionFactory and the
> TransactionmanagerLookup; others?
I am concerned about the idea of having this value changing depending
on your environment (JTA or not).
Do you think this will provide values to customers or is it a
marketing / shineware feature.
>
>
> --
> Steve Ebersole <steve(a)hibernate.org>
> Hibernate.org
>
14 years, 9 months
Re: [hibernate-dev] [BV] How can a Bean Validation provider have its own Validation implementation
by Emmanuel Bernard
IM log
If you look at the spec, I've [...] the implementation details.
Anybody is free to "implement" the API
Which is what we did for JPA-API, Persistence.java is implemented
differently in Sun's and our implementation
The spec defines the public (and protected) contract of the APIs incl
Validation not the implementation
Hardy Ferentschik
what's about the test harness then?
to be an official BV implementation you have to pass the tests against
our javax.validation, right?
Emmanuel Bernard
I don't think so. you could put yours. actually that's the case
because the test harness is supposed to test for sig conformance
On Jul 16, 2009, at 06:08, Hardy Ferentschik wrote:
> Hi,
>
> the current spec says section 4.4.5 Validation:
>
> "The Validation implementation provided by the Bean Validation
> provider must not contain any non private attrib-
> ute or method aside from the three public static bootstrap
> methods: ... "
>
> Given that Validation is not an interface and part of the API - how
> can an implementor provide its own implementation?
> Shouldn't this whole pragraph be removed?
>
> --Hardy
14 years, 9 months
Hibernate Search alternative Directory distribution
by Emmanuel Bernard
Here is the concall notes on how to cluster and copy Hibernate indexes
using non file system approaches.
Forget JBoss Cache, forget plain JGroups and focus on Infinispan
Start with Infinispan in replication mode (the most stable code) and
then try distribution. It should be interesting to test the dist algo
and see how well L1 cache behaves in a search environment.
For the architecture, we will try the following approach in decreasing
interest )If the first one works like a charm we stick with it):
1. share the same grid cache between the master and the slaves
2. have a local cache on the master where indexing is done and
manually copy over the chuncks of changed data to the grid
This requires to store some metadata (namely the list of chunks for a
given index and the lastupdate for each chunk) to implement the same
algorithm as the one implemented in FSMaster/SlaveDirectoryProvider
(incremental copy).
3. have a local cache on the master where indexing is done and
manually copy over the chuncks of changed data to the grid. Each slave
copy from the grid to a local version of the index and use the local
version for search.
When writing the InfinispanDirectory (inspired by the RAMDirectory and
the JBossCacheDirectory), one need to consider than Infinispan has a
flat structure. The key has to contain:
- the index name
- the chunk name
Both with essentially be the unique identifier.
Each chunk should have its size limited (Lucene does that already AFAIK)
Question on the metadata. one need ot keep the last update and the
list of chuncks. Because Infinispan is not queryable, we need to store
that as metadata:
- should it be on each chunk (ie last time on each chunk, the size
of a chunk)
- on a dedicated metadata chunk ie one metadata chunk per chunk + a
chink containing the list
- on a single metadata chunk (I fear conflicts and inconsistencies)
On changes or read explore the use of Infinispan transaction to ensure
RR semantic. Is it necessary? A file system does not guarantee that
anyway.
In the case of replication, make sure a FD back end can be activated
in case the grid goes to the unreachable clouds of total inactivity.
Question to Manik: do you have a cluster to play with once we reach
this stage?
Good luck Lukasz,a nd ask for help if you are stuck or unsure of a
decision :)
14 years, 9 months
Help with first patch
by Nikolas Everett
I'm being bitten by HHH-3919 and figured I'd just fix it.
So I wrote a patch and had all kinds of fun trying to test it. Is there
some page that tells me what I should do to get started?
For references I'm on Ubuntu 8.10 with:
neverett@neverett-laptop:~$ mvn -version
Maven version: 2.0.9
Java version: 1.6.0_10
OS name: "linux" version: "2.6.27-14-generic" arch: "amd64" Family: "unix"
neverett@neverett-laptop:~$ svn --version
svn, version 1.5.1 (r32289)
compiled Jul 31 2008, 09:45:20
Here is what I did:
svn co http://anonsvn.jboss.org/repos/hibernate/core/trunk
<edit ~/.m2/settings.xml and add jboss repositories>
cd trunk
<Make changes>
mvn clean install
That failed because I'm on Java 1.6 and there are JDBC incompatibilities.
I'm not sure how I'd have known that other than the comment at the bottom of
https://www.hibernate.org/422.html . So I installed Java 1.5 and tried
again:
JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun/ mvn clean install
That failed in testsuite with:
Failed tests:
testProxyReuse(org.hibernate.test.legacy.ParentChildTest)
testPaginationWithPolymorphicQuery(org.hibernate.test.hql.ASTParserLoadingTest)
testMultipleBagFetchesFail(org.hibernate.test.hql.ASTParserLoadingTest)
testDuplicateImplicitJoinInSelect(org.hibernate.test.hql.HQLTest)
Tests in error:
testLoadingAndSerializationOfConfiguration(org.hibernate.test.cfg.ConfigurationPerformanceTest)
testSessionFactoryCreationTime(org.hibernate.test.cfg.ConfigurationPerformanceTest)
testComplexCriteria(org.hibernate.test.legacy.ParentChildTest)
Where should I go from here? Is there some kind of script I can follow?
Thanks,
Nik Everett
14 years, 9 months
Hibernate core 3.2.7 not on maven repo
by Alaa Mohsen
Hello All,
Couldn't help to notice that Hibernate Core 3.2.7 which was released on
June 4th was not deployed to JBOSS maven repository (and still isn't in
central). When would this be added to JBOSS repo? Thanks
Regards
Alaa Nassef
14 years, 9 months
