ObjectNotFoundException still thrown in FullTextSession?

wiedmann · **Joined:** Wed Jan 09, 2008 4:00 pm **Posts:** 11

Due to an unrelated indexing issue, I ended up with an object in the full-text index that was no longer in the database. From reading the Hibernate Search source code, it seems like the intent is not to throw an exception if a search returns this hit, but I'm still getting an exception with the attached stack trace. Is this intentional? Is there some problem with my environment or configuration that may be causing this?

I understand that ideally the index would never get out of synch with the database, and can probably avoid it in most cases. It's just that the effect of this exception is that any search that matches the missing item fails, which seems like a fairly severe symptom.

Code:

org.hibernate.ObjectNotFoundException: No row with the given identifier exists: 
[com.lawtrust.server.Document#ca533472193932230119394006b0004f]
        at org.hibernate.impl.SessionFactoryImpl$1.handleEntityNotFound(SessionFactoryImpl.java:377)
        at org.hibernate.event.def.DefaultLoadEventListener.returnNarrowedProxy(DefaultLoadEventListener.java:223)
        at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:187)
        at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:103)
        at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:878)
        at org.hibernate.impl.SessionImpl.get(SessionImpl.java:815)
        at org.hibernate.impl.SessionImpl.get(SessionImpl.java:808)
        at org.hibernate.search.engine.ObjectLoader.load(ObjectLoader.java:27)
        at org.hibernate.search.engine.ProjectionLoader.load(ProjectionLoader.java:54)
        at org.hibernate.search.query.FullTextQueryImpl.list(FullTextQueryImpl.java:244)
        at com.lawtrust.server.bl.spring.service.impl.SearchServiceImpl.find(SearchServiceImpl.java:94)

sanne.grinovero · **Posted:** Tue May 06, 2008 1:54 pm

Hi,

Quote:

Due to an unrelated indexing issue

What do you mean? due to a Hibernate Search Bug? Are you writing the indexes on your own?

Quote:

Is this intentional?

Yes I think it is, the index should be kept at sync with your DB;
doing otherwise would have severe effects on performance.

If you are having this problem with very limited frequency I would suggest you to catch the exception and purge the broken entity from your index, then repeat the query:

http://www.hibernate.org/hib_docs/search/reference/en/html_single/#d0e2316

(ObjectNotFoundException has a nice getIdentifier() method )

Of course, if you have many entities with this problem you don't know how expensive this method could be; the only recommended solution is to try to avoid it. That's exactly the reason to use Search: it keeps them synched ;-)

regards,

wiedmann · **Joined:** Wed Jan 09, 2008 4:00 pm **Posts:** 11

s.grinovero wrote:

Hi,

Quote:

Due to an unrelated indexing issue

What do you mean? due to a Hibernate Search Bug? Are you writing the indexes on your own?

No - it was actually that someone had accidentally purged the database (by hand) without purging the indexes. What I'm trying to fix is not the root issue, but the symptom that the exception prevented the search on legitimate data added after the purge from working.

s.grinovero wrote:

Quote:

Is this intentional?

Yes I think it is, the index should be kept at sync with your DB;
doing otherwise would have severe effects on performance.

I understand the goal. What's confusing is that ObjectNotFoundException is caught and suppressed in other places in ObjectLoader.load, just not at the particular line in this stack trace. It seems inconsistent that some cases are caught and others not.

s.grinovero wrote:

If you are having this problem with very limited frequency I would suggest you to catch the exception and purge the broken entity from your index, then repeat the query:

http://www.hibernate.org/hib_docs/search/reference/en/html_single/#d0e2316

(ObjectNotFoundException has a nice getIdentifier() method )

Of course, if you have many entities with this problem you don't know how expensive this method could be; the only recommended solution is to try to avoid it. That's exactly the reason to use Search: it keeps them synched ;-)

regards,

Thanks for this workaround. It looks like it will solve my problem, since it is not a regular occurrence.[/quote]

sanne.grinovero · **Posted:** Tue May 06, 2008 6:54 pm

wiedmann wrote:

Quote:

I understand the goal. What's confusing is that ObjectNotFoundException is caught and suppressed in other places in ObjectLoader.load, just not at the particular line in this stack trace. It seems inconsistent that some cases are caught and others not.

Good point; could you give some reference? Class+method names? maybe there's something that could need some improvements.

wiedmann · **Joined:** Wed Jan 09, 2008 4:00 pm **Posts:** 11

Here's the example that's in my stack trace - ObjectLoader line 25. Note that the initial get is not part of the try block. This seems to be where the exception is thrown in my case. It seems like it may not be expected that the get throws ObjectNotFoundException.

Code:

   public Object load(EntityInfo entityInfo) {
      //be sure to get an initialized object
      Object maybeProxy = session.get( entityInfo.clazz, entityInfo.id );
      try {
         Hibernate.initialize( maybeProxy );
      }
      catch (ObjectNotFoundException e) {
         log.debug( "Object found in Search index but not in database: "
               + e.getEntityName() + " wih id " + e.getIdentifier() );
         maybeProxy = null;
      }
      return maybeProxy;
   }

sanne.grinovero · **Posted:** Wed May 07, 2008 4:15 am

Hi,

I'm not sure why they are managed differently, I would prefer to see it always throw an expection... also returning null appears to break other code.

Are you sure about the line? you sayd 25 but your stacktrace shows 27..

wiedmann · **Joined:** Wed Jan 09, 2008 4:00 pm **Posts:** 11

Sorry for the unclear message - I meant to say line 25 was the beginning of the excerpt, not the line at which the exception was thrown.

Here is a message that implies the intent is not to throw the error:
http://forum.hibernate.org/viewtopic.ph ... dexception

I wonder if this has changed since that message has been posted.

sanne.grinovero · **Posted:** Wed May 07, 2008 4:19 pm

Hi wiedmann,
Yes I think you are right; Emmanuel's post in the other thread confirms your thoughts and there is more code in Search (look at iterators) that shows some effort to "skip" unexistent results. (e.g. IteratorImpl hasNext() ).

But there still is a problem: the code in ObjectLoader
is catching ObjectNotFoundException exceptions at line 27,
so if you are having this problem thrown at line 27 (and not 25) then the problem is actually about the Eception type not being recognized;
there's and "if" there that swallows all ObjectNotFoundException both from JPA or Hibernate core, but throws all other type of exceptions.

Code:

25        Object maybeProxy = session.get( entityInfo.clazz, entityInfo.id );
26      try {
27         Hibernate.initialize( maybeProxy );
      }
      catch (RuntimeException e) {
         if ( LoaderHelper.isObjectNotFoundException( e ) ) {
            log.debug( "Object found in Search index but not in database: "
                  + entityInfo.clazz + " wih id " + entityInfo.id );
            maybeProxy = null;
         }
         else {
            throw e;
         }
      }

So maybe you have a classloader problem; are you sure you don't have different copies of the same jar / classes, from different versions or multiple copies of the same one?
Could you please verify this?

wiedmann · **Joined:** Wed Jan 09, 2008 4:00 pm **Posts:** 11

Actually, these are the correct line numbers:

Code:

25 public Object load(EntityInfo entityInfo) {
26       //be sure to get an initialized object
27       Object maybeProxy = session.get( entityInfo.clazz, entityInfo.id );
28       try {
29          Hibernate.initialize( maybeProxy );
30      }

Note that the exception is caught for initialize(), but not for get(). I wonder if the core Hibernate has changed its behavior since the code was originally written.

sanne.grinovero · **Posted:** Wed May 07, 2008 5:07 pm

Quote:

Actually, these are the correct line numbers:

So this is it, we are not looking at the same code
This is related to :

http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-146

but the latest (unreleased) patch is only related to JPA, you are having a similar issue with plain hibernate, right?

Please, open a new JIRA for this.
Also if you want to patches and junit tests are welcome.

wiedmann · **Joined:** Wed Jan 09, 2008 4:00 pm **Posts:** 11

Ah, that makes sense. I think the issue you're referring to has already been fixed in SVN - when I looked at the code there it was a little different than what I'm looking at, but it still wasn't catching exceptions from the get.

I am just using plain hibernate.

I'll enter a JIRA issue for my version of the problem. Thanks for the help.

sanne.grinovero · **Posted:** Wed May 07, 2008 5:15 pm

cool!
thanks to you.

sanne.grinovero · **Posted:** Sun May 11, 2008 11:27 am

I found your issue,
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-196

could I ask you for a test case? It would help a lot.

wiedmann · **Joined:** Wed Jan 09, 2008 4:00 pm **Posts:** 11

s.grinovero wrote:

I found your issue,
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-196

could I ask you for a test case? It would help a lot.

I'll try to make a simple test case - it might take me a few days. I'll post back here when I have it.

emmanuel · **Posted:** Tue Jun 03, 2008 4:10 pm

I've fixed the issue. I should have use s.load rather than s.get