[Search] CollectionUpdateEventTest fails
by Davide D'Alto
Hi,
I've just pull the changes from the hibernate-search repository and
when I run maven the test
org.hibernate.search.test.engine.optimizations.CollectionUpdateEventTest fails
testWithClassBridge(org.hibernate.search.test.engine.optimizations.CollectionUpdateEventTest):
[catalogItems should have been initialized] expected:<[tru]e> but
was:<[fals]e>
Am I missing anything?
Thanks,
Davide
12 years
Using AS7 prepared Statement caching and Hibernate 4.0.0.Beta4 + 4.0.0.Beta5
by Scott Marlow
https://issues.jboss.org/browse/AS7-1461 reflects a problem reported by
two users. One user reported, that in a transaction that included
multiple different entities being created, that Hibernate is trying to
use a closed prepared statement.
My question at this point is, what would happen if the AS7 prepared
statement cache were to close a prepared statement during a transaction.
For example, assuming that the prepared statement cache was configured
to a very low limit, like two. After two unique sql statements are in
the prepared statement cache, when a third unique sql statement is
created, one of the two cached statements will be closed. Could
Hibernate be holding onto one of these cached prepared statements (for
reuse in the transaction) that are closed?
Example execution order from user report:
1. insert into ASSEMBLIES (NAME, A_ID) values (?, ?)
2. other sql statements are executed.
3. insert into ASSEMBLIES (NAME, A_ID) values (?, ?)
4. other sql statements are executed.
5. At this point, I believe that "insert into ASSEMBLIES (NAME, A_ID)
values (?, ?)" could be aged out of the AS7 prepared statement cache.
6. "insert into ASSEMBLIES (NAME, A_ID) values (?, ?)" fails to execute
because of error
"com.mysql.jdbc.exceptions.jdbc4.MySQLNonTransientConnectionException:
No operations allowed after statement closed"
For my local testing, I'm using H2 and get error
"org.h2.jdbc.JdbcSQLException: The object is already closed [90007-145]"
Does/should Hibernate check the prepared statement to see if its have
been closed before its reused in a transaction? Or should users disable
the AS7 prepared statement cache (current workaround)?
If Hibernate is currently checking if the prepared statement is closed
before reusing it, I must of missed that code in my inspection.
At this point, I'm still trying to find the root cause and answer the
above question as well.
Scott
12 years
Developer meetings day/time
by Steve Ebersole
Due to a change in schedule I can no longer do the meetings on Monday at
the same time. To keep it on Monday we would need to move it back an
hour which really is not reasonable for Strong or anyone in Europe for
that matter. Assuming we keep it at about the same time, Wednesday is
also out for me. Which leaves Tuesday, Thursday and Friday. So far the
consensus from talking to people on IRC was Tuesday. Does that work for
everyone?
--
steve(a)hibernate.org
http://hibernate.org
12 years
[Search] Sharding and access to (subsets) of index readers and Lucene directories in HS 4.0
by Elmer van Chastelet
Hi all,
Yesterday I had a discussion with Sanne on irc [3] about the new api to
access index readers in HS4.0. We couldn't complete our discussion
yesterday, so let's continue here.
As explained in the forum [1], there is currently no good solution for
getting a reader with a subset of the indexes in a sharded environment.
Currently two basic ideas came to mind:
A - Have a SearchFactory.openIndexReader(Class<?> c,
FullTextFilterImplementor...): This is similar to how the IndexManager's
are gathered at query time, and is probably therefore easy to understand
B - (to be further reviewed) Have something like
searchFactory.indexReaders().withShardingOptions( X, Y
).includeType(Class<?> z).openIndexReader(). This also adds the ability
to get an IndexReader for multiple classes. But we need to think about
the .withShardingOptions (or something similar), what input should we
support here? Sharding properties are mostly based on some entity
property(/ies), probably easy to be encode as String. The (custom)
sharding strategy may use such String to select the proper index
managers. Using a String object for identifying which index managers to
use looks fine to me. It will be compatible with current implementation
of custom sharding strategies where one might use the Lucene document at
addition time, or if an entity instance will also be passed (see
discussion [2]), the properties of that entity can probably encoded to
some String. And if HS will cover the mapping/have support for Strings
as identifiers for sharding instead of a user defined mapping of the
index (integer) in the array of IndexManagers, that would be awesome :)
(Relieves the pain of having some mapping that should be stored
somewhere, which I currently do).
Still, we need to know the use cases there might be, i.e. which
flexibility the API should offer.
As is also mentioned in [1], there is currently no direct access to the
index managers, so getting a FSDirectory is currently not possible in
4.0alpha1. I think HS should support this to offer the flexibility to
work on the Lucene indexes directly (for example, to build an auto
completion/spell check index from an existing index)
Let's start by setting up some requirements?
---------
*1 Have access to IndexReader for one class
*2 Have access to IndexReader with a subset of IndexManagers based on
sharding strategy. Sharding strategies are mostly based on some
propert(y/ies) of an entity instance, which can likely be encoded to
some String.
*3 Have access to index directories (FSDirectory/...). Unlike previous
versions (< HS4.0) it would be nice if this uses the ShardingStrategy
instance in use, so mapping is completely and exclusively done in a
ShardingStrategy
* ...
---------
Please extend/modify the list of requirements if you think something is
missing/incorrect and drop your ideas/thoughts about the mentioned
ideas.
Elmer
[1] https://forum.hibernate.org/viewtopic.php?p=2448000#p2448000
[2]
http://www.mailinglistarchive.com/html/hibernate-dev@lists.jboss.org/2011...
[3] IRC log:
<elmervc> sannegrinovero, have you read/did you have time to think about
https://forum.hibernate.org/viewtopic.php?p=2448000#p2448000
<sannegrinovero> hi elmervc , yes I've read it. my next thing on the
todo is to make some prototype, as I'm not happy with the current ideas:
<sannegrinovero> elmervc, are you blocked by this? the workaround is
very simple
<sannegrinovero> generally, I'm wondering if we can avoid having to
expose the DirectoryProviders. I would want them gone from the public
API, but of course limitations like this are not acceptable.
<elmervc> sannegrinovero, I'm branching this migration, so it's not
really blocking. But I would like to try the new H core/search, so for
that to work I need access to the subset of indices
<elmervc> What workaround were you thinking about ?
<elmervc> Just construct an index reader/FSDirs myself using 'hardcoded'
paths ?
<sannegrinovero> nono that's ugly..
<sannegrinovero> elmervc, all logic to open this IR is in
org.hibernate.search.impl.ImmutableSearchFactory.openIndexReader(Class<?>...)
<sannegrinovero> elmervc, and it's just a couple of lines to change ;)
<sannegrinovero> the problem is more how to make it easy to consume
<elmervc> Ok, I'll look into that :)
<elmervc> Using filters is not a good idea?
<sannegrinovero> yes I liked your suggestion. but is it enough ?
<sannegrinovero> and how would the methods look like?
<sannegrinovero> (i.e. the signature)
<elmervc> SearchFactory.openIndexReader(Class<?> c,
FullTextFilterImplementor[] filters) , or what do you mean?
<sannegrinovero> I'd prefer SearchFactory.openIndexReader(Class<?> c,
FullTextFilterImplementor... filters)
<elmervc> But I'm not sure if this covers all use cases of sharding
<sannegrinovero> elmervc, the methods don't need necessarily be defined
on the SearchFactory. We can think of something like
searchFactory.indexReaders().withShardingOptions( X, Y
).includeType(Class<?> z).openIndexReader() .. how does that look like?
<sannegrinovero> I'm just tossing out some ideas, but then we should
bring this up to the mailing list.
<elmervc> the .includeType , do you mean that multiple classes can be
included?
<sannegrinovero> yes
<sannegrinovero> basically the indexReaders() method would open a
context, private to this invocation chain only. (i.e. not affecting
other threads invoking .indexReaders() )
<elmervc> Sounds cool. But then we need to think about
the .withShardingOptions, or something similar. For transparancy it's
best to have something similar to the methods in the ShardingStrategy
interface
<elmervc> Or something similar to what is done @ querytime, i.e.
FullTextFilterImplementors
<elmervc> The point is, we need to know what other use cases one might
have
<elmervc> That's related to how sharding is done, i.e. ... might be a
field in the doc , full text filter, ...
<elmervc> (doc = doc to be added)
<sannegrinovero> yes exactly I need use cases to understand this, that's
why your feedback is very much appreciated :)
<elmervc> sannegrinovero, For example, our sharding strategy is based on
some field in an entity that is added to the Lucene Document (actually,
it has a @Field anno, and this field is removed from the Lucene Document
in the shardingstrategy.getDirectoryProviderForAddition(...)
<sannegrinovero> elmervc, lol that prooves another discussion I had
recently in proposing that we should pass the entity instance and not
the document to the sharding strategy.
<elmervc> It might be usefull indeed, but in our case it's easier to use
a Field in the doc, because that field will always have the same name,
i.e. we can reuse the same sharding strategy.
<sannegrinovero> elmervc, this discussion is very interesting but I'm
busy in other chats now which I can't postpone. Could you please
synthesize this and send a mail to the developer list?
12 years
AS7 management console and Hibernate management statistics/operations...
by Scott Marlow
I'm wondering what Hibernate related information would be good to
include in the AS7 management console. Perhaps for each
SessionFactory/EntityManagerFactory, we could show statistics and some
factory/EntityManagerFactory operations.
I'm leaning towards not using JMX internally to collect the Hibernate
statistics/invoke factory operations.
Please respond here or on IRC, if you have feedback or are interested in
helping to get Hibernate/JPA in the AS7 management console.
Scott
12 years
MassIndexer have any known issues when InfinispanDirectory is used?
by Tom Waterhouse
I'm trying to setup clustering of entities and Lucene indexes for our app
with Hibernate 3.6.5, Hibernate Search 3.4.0, Infinispan 5.0. I'm using
FileCacheStore for the Infinispan cache loader
(InfinispanDirectoryProvider).
MassIndexerImpl.startAndWait() never returns with this configuration. A
lock is never able to be obtained, see the stack from a thread dump below.
The same MassIndexer call works fine when using FSDirectoryProvider.
Should MassIndexer work with Infinispan as the directory?
Tom
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at org.apache.lucene.store.Lock.obtain(Lock.java:91)
at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1097)
at
org.hibernate.search.backend.Workspace.createNewIndexWriter(Workspace.java:202)
at
org.hibernate.search.backend.Workspace.getIndexWriter(Workspace.java:175)
- locked <7793180e8> (a org.hibernate.search.backend.Workspace)
12 years
Problem involving Commons Annotations 4.0.0.CR1, Core annotation processors and Gradle
by Emmanuel Bernard
Hibernate Commons Annotations now uses JBoss Logging.
I tried to upgrade the library for Search without problem.
For Core unfortunately, I am having trouble. When I run
./gradlew clean install
I have a compilation error which I think is a come back of http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512707
The commit is here https://github.com/emmanuelbernard/hibernate-core-ogm/commit/5507b18aec3a...
I have no idea on how to try and fix that with Gradle. Does that ring a bell to anyone. In Hibernate Search, we used to have such problem and fixed it with some maven-compiler-plugin configuration but I am not even familiar with that work.
Log trace below
[...]
[ant:null] ANTLR Parser Generator Version 2.7.7 (20060906) 1989-2005
[ant:null] ANTLR Parser Generator Version 2.7.7 (20060906) 1989-2005
[ant:null] ANTLR Parser Generator Version 2.7.7 (20060906) 1989-2005
[ant:null] ANTLR Parser Generator Version 2.7.7 (20060906) 1989-2005
[ant:null] ANTLR Parser Generator Version 2.7.7 (20060906) 1989-2005
:hibernate-core:generateMainLoggingClasses
:hibernate-core:jaxb
:hibernate-core:compileJava
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
:hibernate-core:processResources
:hibernate-core:classes
:hibernate-core:jar
:hibernate-core:sourcesJar
:hibernate-c3p0:generateMainLoggingClasses
:hibernate-c3p0:compileJava
:hibernate-c3p0:processResources UP-TO-DATE
:hibernate-c3p0:classes
:hibernate-c3p0:jar
:hibernate-c3p0:sourcesJar
:hibernate-c3p0:assemble
:hibernate-testing:generateMainLoggingClasses
:hibernate-testing:compileJava
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
:hibernate-testing:processResources UP-TO-DATE
:hibernate-testing:classes
:hibernate-testing:jar
:hibernate-testing:sourcesJar
:hibernate-c3p0:compileTestJava UP-TO-DATE
:hibernate-c3p0:processTestResources UP-TO-DATE
:hibernate-c3p0:testClasses UP-TO-DATE
:hibernate-c3p0:test
:hibernate-c3p0:check
:hibernate-c3p0:build
:hibernate-core:assemble
:hibernate-core:generateMatrixGrammarSource UP-TO-DATE
:hibernate-core:generateTestGrammarSource UP-TO-DATE
:hibernate-core:compileTestJava
/Users/manu/projects/notbackedup/git/privatebuild/core/hibernate-core/src/test/java/org/hibernate/metamodel/source/annotations/entity/Resources.java:45: incompatible types
found : javax.persistence.SharedCacheMode
required: javax.persistence.SharedCacheMode
SharedCacheMode cacheMode() default SharedCacheMode.ENABLE_SELECTIVE;
^
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 error
FAILURE: Build failed with an exception.
12 years
[Search] proposing an alternative to depth in @IndexedEmbedded
by Sanne Grinovero
Hi all,
I just noticed this proposal on the forum:
https://forum.hibernate.org/viewtopic.php?f=9&t=1012303
I think it's very reasonable, as people don't usually care for the
depth but for the fields they can or can not search.
In addition to a better API, for the sake of the Query Parser
something like that will be very useful: I'll need to be able to
figure out how to map the entities to the index starting from the
known (named) queries.
Also this should play nicely with
HSEARCH-638 - Limit graph traversal by @ContainedIn to the minimum
required path
(optimistically scheduled for the next alpha)
Sanne
12 years
Question about Hibernate 4.0 Infinispan second level cache usage...
by Scott Marlow
I'm looking at o.h.c.i.InfinispanRegionFactory and wondering how best to
configure the 2lc for AS 7.1. After a recent forum discussion and
opening AS7-1544, I need to make some corrections to properly
accommodate multiple JPA persistence units sharing the same underlying
cache definition or having their own.
Currently, with AS 7.0/7.0.1, I think each application should have its
own Infinispan cache definition. In theory, the same cache definition
could be shared if entity class names are unique across all persistence
units (within apps and across different applications). This can be
accommodated currently by adding additional Infinispan configuration
entries to the AS7 standalone.xml (or domain.xml).
One question that I have, is could we add an additional key for
identifying the 2lc cache. The additional key that I have at the time
of creating the container managed entity manager, is the "application
name scoped persistence unit name" (includes the PU name and the
application/containing jar name). Perhaps that could be passed into
InfinispanRegionFactory via a property representing a unique way to
refer to all 2lc entries for a specific applications persistence unit
definition. I'm not sure how desirable it would be to further qualify
the cache entries with this additional information (especially if it
increases the payload transferred during replication).
I think the alternative would be to have each application, configure
their own cache definition (either to share with all applications PU or
create a separate definition per PU). This might be close to what I
already described as a workaround in the
http://community.jboss.org/message/620903 forum post.
What do you think?
Scott
12 years, 1 month
