[
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-601?pag...
]
Sanne Grinovero updated HSEARCH-601:
------------------------------------
Fix Version/s: 3.3.0.Beta2
ok, something should be done but this requires some discussion.
I don't like the idea that it could loop very long on many errors, say a
NullPointerException because of a broken fieldbridge shouldn't log me ten millions of
errors;
we could add a maximum allowable errors threshold - not sure if this is brilliant as it
implies another configuration option.
The number of errors should be collected by the progress monitor; maybe we could think in
delegating the exception to it so that the monitor implementation can decide to log or
not, and take the decision if the indexing should be aborted or continued.
What is the kind of errors that you think should cause Search to not abort indexing?
Allow MassIndexer to recover gracefully when individual objects
won't index
---------------------------------------------------------------------------
Key: HSEARCH-601
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-601
Project: Hibernate Search
Issue Type: Improvement
Components: massindexer
Affects Versions: 3.2.0.Final
Environment: Hibernate 3.5.3, SQL Server 2005
Reporter: Ben Dotte
Fix For: 3.3.0.Beta2
Some of our sites take hours to index, so it is critical that initial indexing complete
even if some of the individual entities fail to index properly. Right now, it appears that
the MassIndexer dies if any individual entity throws an exception during indexing, and
does not complete indexing for that type.
I have a workaround for now by overriding EntityConsumerLuceneworkProducer with my own
index() method that catches and logs exceptions from docBuilder.createAddWork():
private void index( Object entity, Session session ) throws InterruptedException {
Serializable id = session.getIdentifier( entity );
Class clazz = Hibernate.getClass( entity );
DocumentBuilderIndexedEntity docBuilder = documentBuilders.get( clazz );
TwoWayFieldBridge idBridge = docBuilder.getIdBridge();
String idInString = idBridge.objectToString( id );
//depending on the complexity of the object graph going to be indexed it's
possible
//that we hit the database several times during work construction.
try
{
AddLuceneWork addWork = docBuilder.createAddWork( clazz, entity, id, idInString, true
);
backend.enqueueAsyncWork( addWork );
}
catch (Exception e)
{
log.error("Error indexing " + clazz + " id " + id, e);
}
}
This has the added benefit that the object type and id that errored is logged, where that
can be tough to track down otherwise.
That may not be the best solution in general since it could hide exceptions from
Hibernate Search itself.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira