Hi!
We've been trying to migrate the data of our Iliad webapp to Voyage, and so far everything was going great, until the garbage collector collected objects it shouldn't have... Here's what we did:
We used to have all objects stored in an Instances classVar belonging to their own classes, so:
So, should we actually keep references to our instances in the image? I doubt this is the case, cos that'd mean we still have the 2Gb storage limitation, and then having an external DB would not be helping much...
Thanks a lot in advance! Bernat. p.s. I've also tried saving copies of my objects, but the result's been the same, after garbage-collecting, I lose references.
Bernat Romagosa. |
Hi, Voyage should keep a weak cache... objects should be disposed as soon as they are not used anymore. Now... it is saying "Reference not found", or "Lazy reference not found"? Esteban On Feb 8, 2013, at 11:46 AM, Bernat Romagosa <[hidden email]> wrote:
|
It says "Reference not found", and the method signaling the error is VOMongoMaterializer >> #missingContentFor:id: I can try to set up a minimal test case and sent it to you, would that help?
Thanks! 2013/2/8 Esteban Lorenzano <[hidden email]>
Bernat Romagosa. |
In reply to this post by Bernat Romagosa
Hi, I'm not particulary knowledgeable of inner workings of Iliad or voyage. But I think you should have a look at ghostproxy http://rmod.lille.inria.fr/web/pier/software/Marea/GhostProxies. The idea being that after storing your objects you should keep proxies to them in the image. These proxies would replace your objects and have knowledge of how to retrieve them from voyage. Something like that is done by the marea project. http://rmod.lille.inria.fr/web/pier/software/Marea Cheers On Feb 8, 2013 11:48 AM, "Bernat Romagosa" <[hidden email]> wrote:
|
In reply to this post by Bernat Romagosa
yes, this is what happens:
You have a graph that can look like this: A->b->c->D where A and D represent roots of voyage (#isVoyageRoot = true) you removed D, but A is not updated (the logic for auto update references is too complex, and this is a known limitation of voyage). So, in a next cycle you try to bring A to the image, and A is trying to load eagerly an instance of D... which does not exists anymore, so you have the error. To prevent this kind of problems, I use something that I call "eventual integrity" :) you can configure your collection to not fail when you try to get it and it does not exists. For achieve that, you have to add a setting to the class you want to take as "lazy deletable" (is a very dangerous property to just allow it by defect). You have to do something like this: D class>>#mongoContainer <mongoContainer> ^VOMongoContainer new enableMissingContent; yourself note that who is enabling missing content is D, not A :) hope it helps. Cheers, Esteban ps: y si no se entiende nada, mandame un mail privado y lo explico en español :) On Feb 8, 2013, at 12:12 PM, Bernat Romagosa <[hidden email]> wrote:
|
Hmm I'm not sure I understand. Now I've tried not even having the objects stored in a classvar at all, but saving them from a materialized fuel file straight away: (FLMaterializer materializeFromFileNamed: 'mongodb.obj') do: [ :each | each save ]. It's all ok and working, until I do Smalltalk garbageCollect and there goes the "Reference not found" error again, without me having removed any object.
Would making ALL of my classes respond true to #isVoyageRoot fix the issue? Thanks again! Bernat.
p.s. se entiende el idioma, no el contenido, pero eso es culpa mía! jeje 2013/2/8 Esteban Lorenzano <[hidden email]>
Bernat Romagosa. |
(I've tried making all objects be voyageRoot and still no luck) 2013/2/8 Bernat Romagosa <[hidden email]>
Bernat Romagosa. |
In reply to this post by Bernat Romagosa
no, isVoyageRoot mark the objects of the graph that you want as roots. All the others are just embedded objects.
Just try adding enableMissingContent to class "D" (I don't know what is the real name in your case :) Esteban
On Feb 8, 2013, at 12:39 PM, Bernat Romagosa <[hidden email]> wrote:
|
OK! It looks like it's working now! Thank you so much! :) Bernat. p.s. After garbage collection, #selectAll is really slow. I guess this is normal as all objects have to be retrieved all over from the DB, is this right?
2013/2/8 Esteban Lorenzano <[hidden email]>
Bernat Romagosa. |
it depends on the amount of objects, but yes... you can play with lazy/eager ways of retrieve subcollections but if you have 10k objects, it will take some time to bring them all :)
Esteban
On Feb 8, 2013, at 12:59 PM, Bernat Romagosa <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |