A bugfix release for Hibernate Search 4.1 ! Some of you have been reporting reduced performance after migrating from 3.4 or 4.0, which was not expected at all as the internals got smarter at each release. It turns out there was a quite critical bug: file handle leaks.

Big thanks to Bostjan Lah for reporting this problem and providing a nice test to let me reproduce the problem, and to Jan Slezak for all the help verifying the solution. Also Michael Heinrichs reported an issue with programmatic configuration and fixed it, awesome!

What changed compared to 4.1.0.Final?

Besides the important bugfixes, not much changed as expected for minor releases: mostly documentation clarifications, some classloader issues which would affect you only when embedding it in a JBoss Module. For a detailed list see the JIRA changelogs.

We strongly recommend to upgrade; see also the Migration Guide.

The usual links:

• Download it from Sourceforge or via Maven artifacts
• Get in touch on the forums or on the mailing list
• Help out: have a look at JIRA and get the code from GitHub

Another CR for Hibernate Search 4.1 is ready! Even being in candidate release phase, we introduced something more than the usual minor bugfixes, as the following improvements are too nice to delay and technically not very risky.

Depending on Hibernate 4.1

Hibernate Search was updated to work with Hibernate ORM 4.1, as it was still using 4.0.

Rethinking the JGroups integration

The JGroups Channel is the communication transport used when connecting multiple nodes in cluster using JGroups; before 4.1.0.CR3, Hibernate Search would expect you to configure a Channel for each clustered index, but having to configure multiple JGroups Channel is tedious: for example, each channel should use a different set of network ports.

The Channel is now a service shared across all indexes: every index configured to use JGroups will share the same Channel instance. This simplifies configuration, network administration and speeds up initialization.

Configuration details are described in the JGroups configuration paragraph.

If you were using JGroups before, please see the Migration Guide.

JGroups channel injection

It is now possible to have Hibernate Search use an existing JGroups Channel, injecting the instance in the configuration. This was primarily introduced for other frameworks integrating our search engine, such as CapeDwarf, so they can control the Channel lifecycle and make use of alternative initialization options. Remember however: Search installs it's own message Receiver, it's not going to share the channel with other services!

import org.hibernate.search.backend.impl.jgroups.JGroupsChannelProvider;

org.jgroups.JChannel channel = ...//initialize or lookup the channel directly
Map<String,String> properties = new HashMap<String,String>();
properties.put( JGroupsChannelProvider.CHANNEL_INJECT, channel );
properties.put( //...other options
EntityManagerFactory emf = Persistence.createEntityManagerFactory( "userPU", properties );

Plans for next...

We're working as well on making the master/slave an automatic election process, but that's too big of a change for a CR, so consider it just a teaser for upcoming 4.2 ! Of course, you can help starting to test it today if you're willing to participate in the coding and try the bleeding edge.

The usual links

• Download it from Sourceforge or via Maven artifacts
• Get in touch on the forums or on the mailing list
• Help out: have a look at JIRA and get the code from GitHub

Hibernate Search 4.1.0.Beta2 is released, and contains a very interesting improvement: it is now possible to precisely express which paths will be indexed when using @IndexedEmbedded.

Previously, when using @IndexedEmbedded, we would walk the entity graph up to the specified depth to index all the traversed branches. We would index to the same depth all paths, until the specified maximum depth is reached or a smaller value for depth was encountered. In a complex model it could become complex to control what exactly would get indexed.

On the forums Zach Kurey, who was having this problem, asked me just out of curiosity why we didn't provide an explicit paths-to-be-included option. Surely, he wrote, there must be a reason. Truth be told, there was no reason: we just hadn't thought about it.

So, if you have suggestions, don't think we know better. Get in touch! Our role is to protect the quality of the code and catalyse the experience of many clever users: we need to hear from you to keep on improving.

After a long discussion about the API and implementation details, this release makes the new @IndexedEmbedded(includePaths) feature available for everyone to use. Thanks to Zach and Davide D'Alto, as after contributing to the design they also provided the patches and tests, making this brilliant idea available to everyone.

How does it work?

In the following Indexed Entity we declare that when indexing each Person we want to index the name and surname fields, and its parents as well by using the well known @IndexedEmbedded annotation:

@Entity
@Indexed
public class Person {

   @Id
   public int id;

   @Field
   public String name;

   @Field
   public String surname;

   @OneToMany
   @IndexedEmbedded(includePaths = { "name" })
   public Set<Person> parents;

   @ContainedIn
   @ManyToOne
   public Person child;

    ...//other fields omitted
}

The news is the attribute includePaths of the annotation, which points out that we don't want to recursively index all fields for the parent Person, but only its name field.

This was a very simple example; the reference documentation contains more examples and details. In short, it provides better control on which fields will be indexed, avoiding to index unnecessary objects. Of course this improves overall performance.

Hibernate Search 4.1.0.Beta2 awaits you!

Of course this release contains some more bugfixes and improvements, for more details check the release notes.

The links

• Download it from Sourceforge or via Maven artifacts.
• Get in touch on the forums or on the mailing list.
• Help out: have a look at JIRA and get the code from GitHub.

Hibernate Search version 4.1.0.Beta1 was tagged; the most essential change compared to January's release 4.1.0.Alpha1 was HSEARCH-1034, made to allow Infinispan Query to use the fluent Programmatic Mapping API as already available to Hibernate users.

More changes are being developed: stay tuned for new MassIndexer improvements, some new performance improving tricks, and a fierce discussion is going on to provide a new pragmatic way to define index mappings starting from the Query use cases.

Integrations with Infinispan

The Infinispan project released a new milestone version 5.1.1.FINAL, which is relevant to Hibernate Search users in many ways:

• Hibernate Search can use Infinispan to distribute the index among several clustered nodes.
• JBoss AS 7.1 will use this version as the fundamental clustering technology.
• Hibernate OGM can map JPA entities to Infinispan instead of a database, and use Hibernate Search as query engine and replicate the indexes storing them in Infinispan.
• Infinispan Query uses the Hibernate Search Engine component to make it possible to search across the values stored in Infinispan. All you need to do is add the dependency to infinispan-query, enable indexing in the configuration and either annotate the objects you store in the grid like you would do with Hibernate Search entitites, or define the mappings using the programmatic API.

More details on Infinispan Query can be found in the Infinispan reference, but if you're familiar with Hibernate Search there's not much to learn as they share most features and configuration options as defined on the Hibernate Search reference manual.

The usual links

• Download from Sourceforge.
• or get it via Maven artifacts.
• User forums.
• New ideas and suggestions via the mailing list.
• Issue tracker is JIRA; bug reports are welcome, especially those providing patches and/or tests.
• Source code is on GitHub, pull requests welcome.

We tagged Hibernate Search 4.1.0.Alpha1, and artifacts are now ready to be downloaded. 4.1 is meant to mainly upgrade the core dependencies and will have a quick development cycle.

Upgraded dependencies

• Apache Lucene 3.5
• Infinispan 5.1
• JGroups 3.0

To use the above versions, upgrading is required as each of the mentioned projects changed some of its API used by Hibernate Search. Of course Hibernate Search shields you from these changes being fully backwards compatible.

MassIndexer performance

The MassIndexer is quick again! To be honest this is not an improvement but is a bugfix of a performance regression. If you noticed a performance drop in mass indexing using 4.0.0.Final, please try again with this new release and you will see a significant improvement. While working towards 4.1 final we're going to improve it's features and possibly performance even more, finally taking advantage of the new internal design provided by 4.0.

Great contributions

Guillaume Smet identified and fixed a regression for which dirty collections would not be re-indexed when having a custom FieldBridge instead of the standard @IndexedEmbedded.

Davide D'Alto improved the algorithm identifying the elements which need to be loaded and re-indexed: it's now able to avoid some unnecessary database loads in specific use cases having complex relations, consequently also reducing the index size.

The usual links

As always distribution bundles are available from Sourceforge, or you can get it via Maven artifacts. User questions are welcome on the forums, bugs and improvements can be discussed on the mailing list or posted to JIRA directly, possibly with unit tests.

Complete details of all changes are tracked on JIRA.