Indexing a field results in internal Exception

I have an application that I have been converting from JPA/MySQL to JDO/ObjectDB and I have hit a problem with indexing. An index on a String field is required to give good performance but if I add the @Index annotation to the field I eventually end up with an ObjectDB internal exception.  This is reproducible, as is the program running to completion (slowly) if I remove the @Index annotation.  Is there anything I can look for that might result in this exception?

More details are required. Please follow the posting instructions. If you got an exception please post the full stack trace. If it is reproducible, try to create and post a test case that demonstrates the problem.

If you are working in client-server mode, you should try to restart the server after schema change.

After adding an index to an existing entity class with instances in the database, run the ObjectDB Doctor (in fix mode) to build the index (otherwise the index will not be used).

By the way, why do you convert the application from MySQL/JPA to ObjectDB/JDO and not to ObjectDB/JPA?

This is the stack trace through ObjectDB classes.

[ObjectDB 2.5.0_01] Unexpected exception (Error 990)
  Generated by Java HotSpot(TM) 64-Bit Server VM 1.7.0_11 (on Linux 3.5.0-27-generic).
Please report this error on http://www.objectdb.com/database/issue/new
com.objectdb.o.InternalException: null
com.objectdb.o.InternalException
at com.objectdb.o.BYR.s(BYR.java:113)
at com.objectdb.o.BYR.A(BYR.java:206)
at com.objectdb.o.VUT.j(VUT.java:346)
at com.objectdb.o.ACN.UX(ACN.java:162)
at com.objectdb.o.RTT.H(RTT.java:282)
at com.objectdb.o.RST.C(RST.java:183)
at com.objectdb.o.RTT.l(RTT.java:134)
at com.objectdb.o.RST.l(RST.java:24)
at com.objectdb.o.RTT.D(RTT.java:179)
at com.objectdb.o.RST.s(RST.java:121)
at com.objectdb.o.PGT.q(PGT.java:109)
at com.objectdb.o.RST.B(RST.java:93)
at com.objectdb.o.RTT.l(RTT.java:132)
at com.objectdb.o.RST.l(RST.java:24)
at com.objectdb.o.TSK.i(TSK.java:146)
at com.objectdb.o.TSK.f(TSK.java:95)
at com.objectdb.o.MST.aV(MST.java:568)
at com.objectdb.o.MST.U4(MST.java:527)
at com.objectdb.o.BTP.U4(BTP.java:588)
at com.objectdb.o.TAI.A(TAI.java:200)
at com.objectdb.o.TAI.Uu(TAI.java:134)
at com.objectdb.o.PRG.ag(PRG.java:679)
at com.objectdb.o.PRG.af(PRG.java:553)
at com.objectdb.o.QRM.U6(QRM.java:264)
at com.objectdb.o.MST.U6(MST.java:933)
at com.objectdb.o.WRA.U6(WRA.java:293)
at com.objectdb.o.WSM.U6(WSM.java:113)
at com.objectdb.o.QRR.g(QRR.java:244)
at com.objectdb.o.QRR.f(QRR.java:153)
at com.objectdb.jdo.JdoQuery.execute0(JdoQuery.java:811)
at com.objectdb.jdo.JdoQuery.executeWithArray(JdoQuery.java:771)

It might take a while to prepare a test case as it's a large codebase, but I'll get started,

As for why JDO. I have long been a fan of JDO as it's a hugely easer API and gets work done with a lot less metadata. 

Unfortunately the information in the stack trace is not sufficient in this case and a test will be needed.

Regarding JPA/JDO, when using ObjectDB no need to use much metadata in either of them, so you can stay with JPA and just remove the ORM metadata when switching to ObjectDB.

We have been very long-term supporters of JDO, through JDO1, JDO2, and newer versions, as we have had positive experiences of the performances of object databases and JDO seemed such a good fit.  However, your JPA implementation is also potentially very important to us on an extremely large JPA project where we may be migrating away from a large commercial database.  This does mean that we need to get things like this indexing bug sorted out soon.  If we can fix such glitches, I can see objectdb being our primary database for development and deployment.  So, I will supply a test case for you as soon as I can.

I have pinned down the case where this happens and logged it as an issue:

https://www.objectdb.com/issue/1107

OK. Thanks. Discussion will continue in that issue thread.