[Glass] 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 Martinez Peck via Glass]

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).

Cheers,


On Wed, Nov 4, 2015 at 3:16 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

>
>
> On 10/28/2015 06:47 PM, Mariano Martinez Peck wrote:
>
> OK Dale, I think I found out what is going on.
>
> Please, read carefully steps 1 to 3 from my original email. With that in
> mind, the problem is this. I run this code:
>
>
>
> | collectionsWithBadIndexes |
> "Run a query so that to be sure we use indexes"
> Object new assert: ((UserGlobals at: #IndexesBugReport) select: { :each |
> each.testSelector = 'aString' }) size = 1.
> "Check health of indexes"
> [[
> IndexManager current removeAllIncompleteIndexes.
> collectionsWithBadIndexes := IndexManager current nscsWithBadIndexes.
> Transcript show: 'There are ' , collectionsWithBadIndexes size asString, '
> collections with bad indexes.'; cr.
> Transcript show: 'The following are the OOPs of such collections: '.
> collectionsWithBadIndexes do: [ :each | Transcript show: ' - ' , each
> asOop asString.  ].
> Transcript cr.
> ] on: Error do: [ :err | Transcript show: ' Original error: ' , err
> description; cr. ]
> ] ensure: [ System commit ]
>
> It seems that #nscsWithBadIndexes let things in a very bad state. The
> original error is the
>
> *" Original error: a InternalError occurred (error 2261), The object with
> object ID 20 is corrupt. Reason: 'relops: encrypt (no Unicode collator) --
> Unicode strings encountered'*
>
> *AUTOCOMMIT DISABLED"*
>
> And the one trying to do the last commit is the
>
> *"'a TransactionError occurred (error 2249), Further commits have been
> disabled for this session because: ''CorruptObj error''. "*
>
> *Okay I think I discussed these things in my earlier response ...*
>
>
> So..why did I get in seaside request?
>
> Yes! ... this is still a mystery...
>
> I think because #seasideProcessRequestWithRetry:resultBlock:    tries
> again and so, the problem.
> Why do I got  with loading Seaside from metacello? again, because it tries
> 3 times (when it fails, it tries again).
> So it seems that the error "'a TransactionError occurred (error 2249),
> Further commits have been disabled for this session because: ''CorruptObj
> error''. This session m..."    comes when you try to commit again after
> getting the error " 'a InternalError occurred (error 2261), The object
> with object ID 20 is corrupt. Reason: ''relops: encrypt (no Unicode
> collator) -- Unicode ..."
> Maybe this is related to the "Autocommit disabled" ?
>
> Yes Seaside will try to commit when encountering an error (to record
> things in the object log), but commit prohibiting errors don't allow the
> commit and you get to where the commit fails ...
>
> And yes, Seaside continues to retry on commit failures and if somehow the
> ensuing requests don't trigger the index error you will be allowed to
> commit again
>
>
> As for Seaside I imagine I only got the last error and not the original,
> and that's why I couldn't see the original stack.
>
> Does any of this make sense?
>
>
> Yes ... and now I need to look into things for indexes to see if I can
> avoid issuing a corrupt obj error when you are doing read only operations
> ... I think my original logic, is that obviously the index is corrupt if
> the collator is missing, but I anticipate that in an upgrade scenario it
> will be "normal" to have a collator-less index containing Unicode strings
> ...
>
> So will submit a bug ... I'm not sure that I will be able to safely fix
> this bug, but the bug report (and bug notes with wrokaround) are worth
> having ...
>
> Thanks for you effort,
>
> Dale
>



-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20151104/1adb5a5b/attachment.html>