Mixing Unicode and String instances in Indexes [WAS] Re: Further commits have been disabled for this session because: 'CorruptObj error'. This session must logout.

Mariano,

Issue #45812 mainly had to do with the fact that the Transaction error did not provide enough information to really debug the root cause ... Before the fix the error message would have been:

  a IndexingErrorPreventingCommit occurred (error 2726), errors during index maintenance; commit will be disallowed

After the fix, you get better information reporting that there is a missing unicode collator for the index (which you are getting now) --- the solution to this problem is to rebuild the affected index and IIRC when you originally reported this bug, you ended up rebuilding the index ... the rebuild of indexes is required for upgrades from 3.1.x to 3.2.x or 3.1.x to 3.3.x --- the upgradeStone script should be performing these upgrades automatically.

The upgrade from 3.2 to 3.3 does not require any rebuilding of indexes (the upgradeSTone script does resort SortedCollections), so I am wondering if this problem is present in the pre-upgraded extent (3.2.x) and went undetected until now ...

Dale

Hi Dale,

I am seeing again this problem (issue 45812) when upgrading from 3.2.9 to 3.3.1. It happens when I reload all my app code. On the console, I see:

ERROR 2249 , a TransactionError occurred (error 2249), Further commits have been disabled for this session because: 'CorruptObj, relops: encrypt (no Unicode collator) -- Unicode strings encountered'. This session must logout. (TransactionError)

topaz 1>

topaz 1> commit

ERROR 2249 , a TransactionError occurred (error 2249), Further commits have been disabled for this session because: 'CorruptObj, relops: encrypt (no Unicode collator) -- Unicode strings encountered'. This session must logout. (TransactionError)

topaz 1> logout

--- 11/18/2016 14:53:59.924 EST Logging out

Do you know if 45812 was integrated in 3.3.1 ?

On Wed, Nov 4, 2015 at 10:17 PM, Mariano Martinez Peck <[hidden email]> wrote:

On Wed, Nov 4, 2015 at 9:09 PM, Dale Henrichs <[hidden email]> wrote:

On 11/04/2015 04:00 PM, Mariano Martinez Peck wrote:

On Wed, Nov 4, 2015 at 8:49 PM, Dale Henrichs <[hidden email]> wrote:

On 11/04/2015 11:02 AM, Mariano Martinez Peck wrote:

Hi Dale,

Thanks for all the answers and explanations. Hopefully this was worth.

If you open an internal bug please simply let me know the internal bug number since I am keeping a list of the issues I found (with their state).

bug 45812 covers this report ... as I said before I'm still not sure that I can get rid of the corrutp obj error, but I am pretty that I can improve the error message produced by the IndexingErrorPreventingCommit error (a IndexingErrorPreventingCommit occurred (error 2726), errors during index maintenance; commit will be disallowed) by including the root error in the error message ...

Great. Thanks for letting me know. 

 

This was definitely worth it ...

BTW, sometimes we take things for granted without realizing it...did you see how difficult it was for me to reproduce the problem with gsDevKit_home? With 3 lines of code I was able to get a fresh 3.1.0.6 stone, create indexes,  upgrade it to 3.2.9, and then reproduce the bug.

Honestly, without gsDevKit_home I would have not tried to reproduce this as the effort would have been huge. 

Haha, no kidding ... I used the GsDevKit_home bash scripts plus the attached index script to my internal bug report with the following instructions:

1) $GS_HOME/bin/createStone -f gs_3106 3.1.0.6

2)in tODE using the attached tODE script:

   /home/index --clean --create --query --edit
  
3) $GS_HOMEbin/upgradeStone -f gs_3106 gs_329 3.2.9

4) then in tODE using attached tODE script:

   /home/index --boom   # to get the root error
or
   /home/index --update # to get the IndexingErrorPreventingCommit error

(of course you have to move the .ston file to $GS_HOME/sys/local/server/home to see it)

Dale

And right before submitting the bug, I went through the whole sequence just to make sure that it broke the way it was supposed to

Sweet :)

Next time I will try to write such a script!

--

Mariano
http://marianopeck.wordpress.com

--

Mariano
http://marianopeck.wordpress.com

On Mon, Nov 21, 2016 at 4:23 PM, Dale Henrichs <[hidden email]> wrote:

Mariano,

Issue #45812 mainly had to do with the fact that the Transaction error did not provide enough information to really debug the root cause ... Before the fix the error message would have been:

  a IndexingErrorPreventingCommit occurred (error 2726), errors during index maintenance; commit will be disallowed

After the fix, you get better information reporting that there is a missing unicode collator for the index (which you are getting now) --- the solution to this problem is to rebuild the affected index and IIRC when you originally reported this bug, you ended up rebuilding the index ... the rebuild of indexes is required for upgrades from 3.1.x to 3.2.x or 3.1.x to 3.3.x --- the upgradeStone script should be performing these upgrades automatically.

Thanks for the explanation.

 

The upgrade from 3.2 to 3.3 does not require any rebuilding of indexes (the upgradeSTone script does resort SortedCollections), so I am wondering if this problem is present in the pre-upgraded extent (3.2.x) and went undetected until now ...

OK, and how can I check if this problem was already present in the pre-upgraded extent (3.2.x) ? Should I try rebuilding the index there?