Bug #4367


metacat didn't update xml_path_index table while a document was updated

Added by Jing Tao almost 15 years ago. Updated over 14 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


Hi Jing:

Marissa Bauer, working on the POD project, created a new data package
using Morpho - she has created about 25 of them so far. The latest
accession # is mbauer.42.9.
Unlike the rest of the packages, this one is not included in the results of
an NCEAS Data Repository search on the string 'POD!'. KNB portal
and Morpho searches both to find the package.
Initially, Marissa did not include an organizationName field with NCEAS: 12192
string in it,so I added that with the Morpho editor.
In any case, can you take a look at the DP (mbauer.42.9) and let me know what might be missing?
Rick R
Hi, Rick:
Since you can find the mbauer.42.9 by searching in knb page and morpho, I thought this is a nceas skin filter issue. I looked the
mbauser.42.9 and found it has the filter - organizationName="National Center for Ecological Analysis and Synthesis". I am confused
- NCEAS skin should find it.
I carefully checked the nceas skin sql query and the metacat database, it turned out that xml_path_index table hasn't been updated
since mbauer.42.5. When I run "select * from xml_path_index where docid like 'mbauer.42';", I got:
4196745 | mbauer.42 | @packageId | � � � � � � � � 0 | � �304886418 | mbauer.42.5
4196773 | mbauer.42 | organizationName | � � � � � � � � 0 | � �304886527 | NCEAS
You see, in xml_path_index table, the organizationName is "NCEAS", rather than "National Center for Ecological Analysis and
Synthesis", so the nceas skin query couldn't catch the docid. Also we can see the package id is still mbauer.42.5. But the package
id is mbauer.42.9 in document mbauer.42.9.
So I think it is a metacat bug - the xml_path_index table wasn't updated while the document was updated. In your case, the current
document is mbauser.42.9, but the in xml_path_index is still mbuaser.42.5.

Related issues

Blocks Metacat - Bug #4680: Geoserver StringIndexOutOfBoundsExceptionResolvedMichael Daigle01/20/2010

Actions #1

Updated by Michael Daigle over 14 years ago

I haven't been able to reproduce this using the dev skin in metacat. I'll try using morpho.

Actions #2

Updated by Michael Daigle over 14 years ago

So far I haven't been able to reproduce this with the dev skin or morpho.

Actions #3

Updated by Michael Daigle over 14 years ago

I should test this by reindexing doc via api and looking for errors

Actions #4

Updated by Michael Daigle over 14 years ago

Forcing index via the API causes a StringIndexOutOfBoundsException when processing spatial coordinates. See bug 4680 which addresses this issue.

In the meantime, I added a catch in DocumentImpl.buildIndex that logs the exception and continues on.

Actions #5

Updated by Michael Daigle over 14 years ago

Hmm, there is also a foreign key constraint violation. Inserting into xml_index violates a constraint on xml_nodes.nodeid. This may be a race condition. I've seen it happen during unit testing and then go away.

I think the geoserver issue is unrelated.

Actions #6

Updated by Michael Daigle over 14 years ago

It looks like this is a race condition. The xml_nodes insertion commit must still be going on when the indexing kicks off. However, the failed index should get readded to the indexing queue for retry (up to 25 times).

In this case the SQLException was being caught and reported, but not passed on. I rethrow the exception in DocumentImpl.buildIndex() so it gets readded to the indexing queue and retried.

Actions #7

Updated by Redmine Admin over 11 years ago

Original Bugzilla ID was 4367


Also available in: Atom PDF