Dealing with a Magma index that's out of step

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Dealing with a Magma index that's out of step

Nick Brown
Hi Chris and all,

I have Magma in a small Seaside application, used internally at my
workplace. It's running on Pharo 1.3 using the 1.3 patch and load script
from the Squeak wiki.

Primarily we keep domain objects inside a MagmaCollection, with various
indexes, and occasionally a commit will cause an indexed value to
change, and of course we use #noteOldKeysFor: to ensure the indexes get
updated when this happens.

A couple of days ago we had an incident where a runaway process on a
server cause it to become largely unresponsive. This server also holds
the Magma repository. It appears that as a result of Magma operating
through this incident, a commit on a domain object succeeded, but the
index update failed, so the index continued to reflect the old state of
the object. (I can't prove this is the cause, but it seems to me
likely.)

Hitting Google for advice on fixing the Magma index, I found a thread on
this list [1] where the given solution to this sort of index problem is
to remove and re-add the object to the collection. However, when I
remove the object from the collection, it doesn't get removed from the
index (presumably because the index entry removal depends upon the state
of the object being correspondent, which of course in this case, it
isn't.)

On re-adding the object to the collection, it gets indexed with its
correct state, but this is in *addition* to the old index entry. So that
didn't fix my problem.

I did subsequently fix it by reverting the state of the domain object to
match the index, then progressing the object forward through its normal
process, successfully updating the index as it went.

So, the questions are:
 1 - Is there another way of fixing the problem, that I missed?
 2 - Ought there to be clearly defined interfaces for forcing in & out
 particular index entries, or forcing entire index rebuilds?

Thanks,
Nick


[1]
http://thread.gmane.org/gmane.comp.lang.smalltalk.squeak.magma/914/focus=914
_______________________________________________
Magma mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/magma
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dealing with a Magma index that's out of step

Chris Muller-3
Hi Nick,

> A couple of days ago we had an incident where a runaway process on a
> server cause it to become largely unresponsive. This server also holds
> the Magma repository. It appears that as a result of Magma operating
> through this incident, a commit on a domain object succeeded, but the
> index update failed, so the index continued to reflect the old state of
> the object. (I can't prove this is the cause, but it seems to me
> likely.)

Hm, this should never happen.  Magma writes to the DB atomically,
including index updates.  Strange.

> Hitting Google for advice on fixing the Magma index, I found a thread on
> this list [1] where the given solution to this sort of index problem is
> to remove and re-add the object to the collection. However, when I
> remove the object from the collection, it doesn't get removed from the
> index (presumably because the index entry removal depends upon the state
> of the object being correspondent, which of course in this case, it
> isn't.)

Yes, that appears to be true.  See
MagmaCollectionManager>>#processRemovesIn: for the method that
actually does this.  I wonder if temporarily removing the "didRemove"
guard would have worked for you?  Hm, I'm actually wondering whether
that guard is really necessary..

> On re-adding the object to the collection, it gets indexed with its
> correct state, but this is in *addition* to the old index entry. So that
> didn't fix my problem.

Just a note:  Objects can be added multiple times to a
MagmaCollection, so if it was in there more than once it would be
indexed more than once too.  Doesn't sound like that was the case this
time but, just fyi.

> I did subsequently fix it by reverting the state of the domain object to
> match the index, then progressing the object forward through its normal
> process, successfully updating the index as it went.
>
> So, the questions are:
>  1 - Is there another way of fixing the problem, that I missed?
>  2 - Ought there to be clearly defined interfaces for forcing in & out
>  particular index entries, or forcing entire index rebuilds?

You could do a #removeIndexNamed: followed by #addIndex: to force a
full rebuild.

 - Chris
_______________________________________________
Magma mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/magma
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Dealing with a Magma index that's out of step

Nick Brown


On Tue, Nov 13, 2012, at 04:07 PM, Chris Muller wrote:

> Hi Nick,
>
> > A couple of days ago we had an incident where a runaway process on a
> > server cause it to become largely unresponsive. This server also holds
> > the Magma repository. It appears that as a result of Magma operating
> > through this incident, a commit on a domain object succeeded, but the
> > index update failed, so the index continued to reflect the old state of
> > the object. (I can't prove this is the cause, but it seems to me
> > likely.)
>
> Hm, this should never happen.  Magma writes to the DB atomically,
> including index updates.  Strange.
>
> > Hitting Google for advice on fixing the Magma index, I found a thread on
> > this list [1] where the given solution to this sort of index problem is
> > to remove and re-add the object to the collection. However, when I
> > remove the object from the collection, it doesn't get removed from the
> > index (presumably because the index entry removal depends upon the state
> > of the object being correspondent, which of course in this case, it
> > isn't.)
>
> Yes, that appears to be true.  See
> MagmaCollectionManager>>#processRemovesIn: for the method that
> actually does this.  I wonder if temporarily removing the "didRemove"
> guard would have worked for you?  Hm, I'm actually wondering whether
> that guard is really necessary..
>
> > On re-adding the object to the collection, it gets indexed with its
> > correct state, but this is in *addition* to the old index entry. So that
> > didn't fix my problem.
>
> Just a note:  Objects can be added multiple times to a
> MagmaCollection, so if it was in there more than once it would be
> indexed more than once too.  Doesn't sound like that was the case this
> time but, just fyi.
>
> > I did subsequently fix it by reverting the state of the domain object to
> > match the index, then progressing the object forward through its normal
> > process, successfully updating the index as it went.
> >
> > So, the questions are:
> >  1 - Is there another way of fixing the problem, that I missed?
> >  2 - Ought there to be clearly defined interfaces for forcing in & out
> >  particular index entries, or forcing entire index rebuilds?
>
> You could do a #removeIndexNamed: followed by #addIndex: to force a
> full rebuild.
>
>  - Chris

Thanks Chris.

For some reason I had it in my head that indexes only captured
collection contents added *after* the creation of the index, but I'm
glad to see I'm totally wrong about that.

If this problem should ever happen again, hopefully I'll be able to do a
bit more of a postmortem on it. In the meantime I'll add a method to my
application to recreate the indexes, per your suggestion.

Cheers,
Nick
_______________________________________________
Magma mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/magma
Loading...