Try this:
MagmaSession initialize
and then run your upgrade.
I've seen this error a couple of times, now I think what's happening is that the class-initialization for MaObjectBuffer got run sometime _after_ MagmaSession. Under normal loading procedures that would not happen, but if a new version of Ma object serialization was loaded after Magma, it could happen.
Let me know, Chris
On Sun, Nov 28, 2010 at 3:50 PM, Facundo Vozzi facundov79@gmail.com wrote:
Sorry, I forgot attach the error. There you go. Thanks, Facu
On Sun, Nov 28, 2010 at 2:57 PM, Chris Muller ma.chris.m@gmail.com wrote:
What error? Screenshot?
On Fri, Nov 26, 2010 at 3:17 PM, Facundo Vozzi facundov79@gmail.com wrote:
Hi Chris, I did it but I'm getting the error that adjunt in the screnshot. Do you know what I'm doing wrong? Thanks you, Facundo On Fri, Nov 26, 2010 at 3:33 PM, Chris Muller asqueaker@gmail.com wrote:
Hi Facundo, please use the "Magma upgrader" package available on the "Magma tester" project of squeaksource.
After loading it:
(MagmaUpgrader source: '/path/to/old/repository') compressTo: '/path/to/upgraded/repository'
- Chris
On Fri, Nov 26, 2010 at 6:54 AM, Facundo Vozzi facundov79@gmail.com wrote:
Hi, how is the way for upgrade my magma repository from version 12 to version 14 in order to use it with the version 1.2a1 of magma? Someone was able to test version 1.2a1 in Pharo 1.1.1? Thanks in advance, Facu
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
Hi, I have a production application, which needs to have a very few amount of objects (less than 2k, in a very short graph of two or tree levels, never more than four, and that is very rare). For that, I configured a Pharo 1.1.1 (dev), with latest magma, and it is running in a very strange linux (I think is suse, but I can't know), with latest unix cog vm. I have two problems, but while I can live with one of them, the other one is killing me :)
First, the most important one: time to time, magma use is crashing the application. I think this is because the memory consumption scales up to 300M very fast, and it shouldn't be like that (at start, the image is around 60M)... so, I try to commit a graph of no more than 10 objects (and not really big), and the image crashes. This behavior was not present before, when I was using a "image persistence" strategy.
Second: performance. Yes, everybody complains about this... and it seems to be some guidelines, that I shouldn't be following... but I'll explain a little my structure, maybe you know what I'm doing wrong. This is what I have:
Root is a MaDictionary, which have a serie of keypairs String, MagmaCollection I have no more than 5 keypairs, and just one of the magma collections have more than 500 objects. Some of the internal objects have a tree form, always having magmacollections for the children, never more than 4 levels.
The read strategy is 0
Any ideas?
Cheers, Esteban
Hi Esteban, please excuse me but... I cannot possibly determine from this description what the problem could be. Could you post at least the stack trace?
Also, I am curious, why did you change the ReadStrategy depth to 0? Someone else did that and then complained of performance problems, and I explained that doing that causes only one object at a time to be retrieved, which I hope is obvious. I guess I am just confused why people are changing the default ReadStrategy for worse?
- Chris
On Tue, Nov 30, 2010 at 3:40 PM, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi, I have a production application, which needs to have a very few amount of objects (less than 2k, in a very short graph of two or tree levels, never more than four, and that is very rare). For that, I configured a Pharo 1.1.1 (dev), with latest magma, and it is running in a very strange linux (I think is suse, but I can't know), with latest unix cog vm. I have two problems, but while I can live with one of them, the other one is killing me :)
First, the most important one: time to time, magma use is crashing the application. I think this is because the memory consumption scales up to 300M very fast, and it shouldn't be like that (at start, the image is around 60M)... so, I try to commit a graph of no more than 10 objects (and not really big), and the image crashes. This behavior was not present before, when I was using a "image persistence" strategy.
Second: performance. Yes, everybody complains about this... and it seems to be some guidelines, that I shouldn't be following... but I'll explain a little my structure, maybe you know what I'm doing wrong. This is what I have:
Root is a MaDictionary, which have a serie of keypairs String, MagmaCollection I have no more than 5 keypairs, and just one of the magma collections have more than 500 objects. Some of the internal objects have a tree form, always having magmacollections for the children, never more than 4 levels.
The read strategy is 0
Any ideas?
Cheers, Esteban_______________________________________________ Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
When you said the "application is crashing" did you mean the VM too? If so, it made me wonder if BlockClosures part of your model; maybe a sortBlock of a SortedCollection? BlockClosures were a problem in 1.1r1 under Cog which which has been fixed in 1.2alpha.
Serialization of all supported object-types can be tested by loading:
Ma object serialization tester-cmm.32
and then:
MaObjectSerializerTestCase suite maDebug
- Chris
On Tue, Nov 30, 2010 at 3:40 PM, Esteban Lorenzano estebanlm@gmail.com wrote:
Hi, I have a production application, which needs to have a very few amount of objects (less than 2k, in a very short graph of two or tree levels, never more than four, and that is very rare). For that, I configured a Pharo 1.1.1 (dev), with latest magma, and it is running in a very strange linux (I think is suse, but I can't know), with latest unix cog vm. I have two problems, but while I can live with one of them, the other one is killing me :)
First, the most important one: time to time, magma use is crashing the application. I think this is because the memory consumption scales up to 300M very fast, and it shouldn't be like that (at start, the image is around 60M)... so, I try to commit a graph of no more than 10 objects (and not really big), and the image crashes. This behavior was not present before, when I was using a "image persistence" strategy.
Second: performance. Yes, everybody complains about this... and it seems to be some guidelines, that I shouldn't be following... but I'll explain a little my structure, maybe you know what I'm doing wrong. This is what I have:
Root is a MaDictionary, which have a serie of keypairs String, MagmaCollection I have no more than 5 keypairs, and just one of the magma collections have more than 500 objects. Some of the internal objects have a tree form, always having magmacollections for the children, never more than 4 levels.
The read strategy is 0
Any ideas?
Cheers, Esteban_______________________________________________ Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
Hi Chris, sorry for the delay, I do MagmaSession initialize and it works perfectly. Thanks.
I couldn't run tests for magma 1.2a on Pharo but my application works fine with it. Is 1.2a ready for production?
Thanks you, again.
See you, Facu
On Mon, Nov 29, 2010 at 9:22 PM, Chris Muller ma.chris.m@gmail.com wrote:
Try this:
MagmaSession initialize
and then run your upgrade.
I've seen this error a couple of times, now I think what's happening is that the class-initialization for MaObjectBuffer got run sometime _after_ MagmaSession. Under normal loading procedures that would not happen, but if a new version of Ma object serialization was loaded after Magma, it could happen.
Let me know, Chris
On Sun, Nov 28, 2010 at 3:50 PM, Facundo Vozzi facundov79@gmail.com wrote:
Sorry, I forgot attach the error. There you go. Thanks, Facu
On Sun, Nov 28, 2010 at 2:57 PM, Chris Muller ma.chris.m@gmail.com
wrote:
What error? Screenshot?
On Fri, Nov 26, 2010 at 3:17 PM, Facundo Vozzi facundov79@gmail.com wrote:
Hi Chris, I did it but I'm getting the error that adjunt in the screnshot. Do
you
know what I'm doing wrong? Thanks you, Facundo On Fri, Nov 26, 2010 at 3:33 PM, Chris Muller asqueaker@gmail.com wrote:
Hi Facundo, please use the "Magma upgrader" package available on the "Magma tester" project of squeaksource.
After loading it:
(MagmaUpgrader source: '/path/to/old/repository') compressTo: '/path/to/upgraded/repository'
- Chris
On Fri, Nov 26, 2010 at 6:54 AM, Facundo Vozzi <facundov79@gmail.com
wrote:
Hi, how is the way for upgrade my magma repository from version 12 to version 14 in order to use it with the version 1.2a1 of magma? Someone was able to test version 1.2a1 in Pharo 1.1.1? Thanks in advance, Facu
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
The only known bug in 1.2a relates to the use of ForwardingProxies, which I doubt you're using.
ForwardingProxies are a way for an object in one repository to refer to an object in another repository. The bug relates to creating multiple new forwarding proxies in a single commit. It is on my list to fix this.
- Chris
On Fri, Dec 3, 2010 at 6:43 AM, Facundo Vozzi facundov79@gmail.com wrote:
Hi Chris, sorry for the delay, I do MagmaSession initialize and it works perfectly. Thanks. I couldn't run tests for magma 1.2a on Pharo but my application works fine with it. Is 1.2a ready for production? Thanks you, again. See you, Facu
On Mon, Nov 29, 2010 at 9:22 PM, Chris Muller ma.chris.m@gmail.com wrote:
Try this:
MagmaSession initialize
and then run your upgrade.
I've seen this error a couple of times, now I think what's happening is that the class-initialization for MaObjectBuffer got run sometime _after_ MagmaSession. Under normal loading procedures that would not happen, but if a new version of Ma object serialization was loaded after Magma, it could happen.
Let me know, Chris
On Sun, Nov 28, 2010 at 3:50 PM, Facundo Vozzi facundov79@gmail.com wrote:
Sorry, I forgot attach the error. There you go. Thanks, Facu
On Sun, Nov 28, 2010 at 2:57 PM, Chris Muller ma.chris.m@gmail.com wrote:
What error? Screenshot?
On Fri, Nov 26, 2010 at 3:17 PM, Facundo Vozzi facundov79@gmail.com wrote:
Hi Chris, I did it but I'm getting the error that adjunt in the screnshot. Do you know what I'm doing wrong? Thanks you, Facundo On Fri, Nov 26, 2010 at 3:33 PM, Chris Muller asqueaker@gmail.com wrote:
Hi Facundo, please use the "Magma upgrader" package available on the "Magma tester" project of squeaksource.
After loading it:
(MagmaUpgrader source: '/path/to/old/repository') compressTo: '/path/to/upgraded/repository'
- Chris
On Fri, Nov 26, 2010 at 6:54 AM, Facundo Vozzi facundov79@gmail.com wrote: > Hi, > how is the way for upgrade my magma repository from version 12 > to version 14 > in order to use it with the version 1.2a1 of magma? > Someone was able to test version 1.2a1 in Pharo 1.1.1? > Thanks in advance, > Facu > > _______________________________________________ > Magma mailing list > Magma@lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/magma > >
You are right, I'm not using it for now. I have only one repository.
See you, Facu
On Fri, Dec 3, 2010 at 12:45 PM, Chris Muller ma.chris.m@gmail.com wrote:
The only known bug in 1.2a relates to the use of ForwardingProxies, which I doubt you're using.
ForwardingProxies are a way for an object in one repository to refer to an object in another repository. The bug relates to creating multiple new forwarding proxies in a single commit. It is on my list to fix this.
- Chris
On Fri, Dec 3, 2010 at 6:43 AM, Facundo Vozzi facundov79@gmail.com wrote:
Hi Chris, sorry for the delay, I do MagmaSession initialize and it works perfectly. Thanks. I couldn't run tests for magma 1.2a on Pharo but my application works
fine
with it. Is 1.2a ready for production? Thanks you, again. See you, Facu
On Mon, Nov 29, 2010 at 9:22 PM, Chris Muller ma.chris.m@gmail.com
wrote:
Try this:
MagmaSession initialize
and then run your upgrade.
I've seen this error a couple of times, now I think what's happening is that the class-initialization for MaObjectBuffer got run sometime _after_ MagmaSession. Under normal loading procedures that would not happen, but if a new version of Ma object serialization was loaded after Magma, it could happen.
Let me know, Chris
On Sun, Nov 28, 2010 at 3:50 PM, Facundo Vozzi facundov79@gmail.com wrote:
Sorry, I forgot attach the error. There you go. Thanks, Facu
On Sun, Nov 28, 2010 at 2:57 PM, Chris Muller ma.chris.m@gmail.com wrote:
What error? Screenshot?
On Fri, Nov 26, 2010 at 3:17 PM, Facundo Vozzi <facundov79@gmail.com
wrote:
Hi Chris, I did it but I'm getting the error that adjunt in the screnshot. Do you know what I'm doing wrong? Thanks you, Facundo On Fri, Nov 26, 2010 at 3:33 PM, Chris Muller <asqueaker@gmail.com
wrote: > > Hi Facundo, please use the "Magma upgrader" package available on
the
> "Magma tester" project of squeaksource. > > After loading it: > > (MagmaUpgrader source: '/path/to/old/repository') compressTo: > '/path/to/upgraded/repository' > > - Chris > > On Fri, Nov 26, 2010 at 6:54 AM, Facundo Vozzi > facundov79@gmail.com > wrote: > > Hi, > > how is the way for upgrade my magma repository from version 12 > > to version 14 > > in order to use it with the version 1.2a1 of magma? > > Someone was able to test version 1.2a1 in Pharo 1.1.1? > > Thanks in advance, > > Facu > > > > _______________________________________________ > > Magma mailing list > > Magma@lists.squeakfoundation.org > > http://lists.squeakfoundation.org/mailman/listinfo/magma > > > >
magma@lists.squeakfoundation.org
-
Chris Muller -
Chris Muller -
Esteban Lorenzano -
Facundo Vozzi