Magma July 2005

magma@lists.squeakfoundation.org

5 participants
8 discussions

Monticello remote repository template bug
by Michael Roberts 27 Jul '05

27 Jul '05

Hi, the template for the remote repository MCRemoteMagmaRepository class host: 'localhost' port: 51969 incorrectly sends #host:port: to Metaclass. Do you want to drop the sending of #species in #creationTemplate? If you manually change it it works fine. Cheers Mike

2 2

A quick DNU question
by Michael Roberts 27 Jul '05

27 Jul '05

Hi, I've loaded Magma client (125) and server (105) from Monticello into separate 3.8 images and I get a DNU in the client image when I try and connect. The client eventually ends up in MaOidManager>>getNextOid which sends #lastUserObjectOid to MaOidCalculator. This isn't defined in my client image. However, it seems that it is extended in Magma server. Does this need to be pushed down into Magma client? Also, is there a way of knowing which versions are considered stable? I just grabbed the latest versions but I would grab more 'blessed' versions if these numbers were indicated somewhere? Thanks! Mike

2 5

Magma-tester.cmm.162
by Chris Muller 27 Jul '05

27 Jul '05

I have posted a new version with the four bug fixes integrated. Thanks Brent and Michael. - Chris

1 0

[BUG] [FIX] MaIntegerIndex >> keySize
by Brent Pinkney 27 Jul '05

27 Jul '05

Hi Chris, Can you please ensure that MaIntegerIndex implements #keySize. Cerrently it is not implemented, but the parent class MaIndexDefinition calls #subclassResponsibility in its implementation of #keySize. Something like: MaIntegerIndex >> keySize ^ keySize ! Thanks Brent Pinkney

2 1

Re: memory
by Chris Muller 26 Jul '05

26 Jul '05

> 2. Traversing a Reader 'hogs' memory on the server > -------------------------------------------------- > This is our biggest problem. If I have a script which iterates over a > reader, doing something with the tree reachable each object and then > stubbing it out at the bottom of the loop, the server image's memory > footprint just keeps growing. The client image's memory is stable. > > e.g. > > | reader | > reader := (session root things read: #name). > 1 to: reader size do: [ :i | | thing | > thing := reader at: i. > "do other things with thing here..." > "materialize a lot of objects but no transactions" > session stubOut: thing. > session finalizeOids. > Smalltalk garbageCollect. > ]. I did find a memory "leak" that occurs for commits, I'll explain. We must now re-serialize commit-packages to support disaster-recovery, I was not "finalizingOids" of the serializer that takes care of this work. The attached change-set corrects this. (Note, in this case, you'll see I was actually able to use #resetOidManager, which is quicker for clean-up than #finalizeOids, but you not usable for a MagmaSessions serializer..). I was not able to reproduce the case above only enumerating a reader to cause the server to leak memory.. Let me share my test scripts and, if it is still happening for you, perhaps you can modify the scripts such that they recreate the problem and then send them back to me.. ** Script 1 - Create a huge MagmaSet of UUID's, indexed on #asString36. | path s set | path _ 'c:\temp\bigger'. MagmaRepositoryController create: path root: (MagmaSet equivalenceIndex: ((MaSearchStringIndexDefinition attribute: #asString36) keySize: 192 ; yourself)). s _ MagmaSession openLocal: path. s connectAs: 'cmm'. s begin. set _ s root. 1 to: 1000000 do: [ : n | set add: UUID new. n \\ 100 = 0 ifTrue: [ s commitAndBegin ; finalizeOids ] ]. s commit. s NOTE, in the interests of time, I broke this after it had added 493000+ UUID's to run the next scripts.. ** Script 2 - Start the server ** path _ 'c:\temp\bigger'. MagmaServerConsole new open: path ; processOn: 1010 ** Script 3 - Enumerate (separate image) ** | path s set reader | path _ 'c:\temp\bigger'. s _ MagmaSession hostAddress: #(127 0 0 1) asByteArray port: 1010. s connectAs: 'chris'. set _ s root. reader := (s root read: #asString36). 1 to: reader size do: [ :i | | thing | thing := reader at: i. "do other things with thing here..." "materialize a lot of objects but no transactions" i\\1000=0 ifTrue: [ Transcript show: '.' ]. ]. s I let this run but the server hovered at 30MB constant for several minutes before I interrupted it. My guess is you probably had the commit memory-leak affecting you. The attached change-set seems to fix it. I hope it fixes your memory-leak issue.. - Chris

1 0

Magma update
by Chris Muller 26 Jul '05

26 Jul '05

I just thought I'd describe where Magma is these days. Besides significant improvement in stability, the last year has seen several features added: == near-Universal object support == Almost any kind of object is supported. The only ones I still need to fix are subclasses of Set and Dictionary (such as PluggableSet and PluggableDictionary). However, Blocks and variableWord and even Morphs and Projects seem to work. == Collaborative development == You can run your image "out-of-sync" with respect to class definitions in repository's you're connected to. Instance variables, like standard Smalltalk, are mapped by name. Magma will even warn you if you are about to truncate an instance variable on account of your in-image definition not having a particular instance variable. You can also use Magma as a code-repository. Classes, ChangeSets and Monticello packages can be saved to a special area that does not require a connection in order to download and install the code. This way repositories can/should be built to contain all the objects AND code needed to access those objects (self contained repository). The Monticello GUI can be used to directly load/save packages. == Remote proxies == Magma is intended to run client/server AND peer-to-peer simultaneously. You can have your own personal database in which you may wish to loosely reference an object in another repository. Just send #maAsForwardingProxy to the remote object and commit the result to your repository. Then, any messages you send to that will cause automatic connection to the remote repository and send the message. == Large-collection enhancements == A lot of work has gone into large-collections. Thanks to Brent Pinkney, we now has MagmaSet and MagmaDictionary. These are two classes that act like their Smalltalk brothers, except can hold millions of objects and endure high-concurrency. We also have MagmaArray, which provides fast-access to a very-large Array structure. All large-collections now work before they are persistent, as well as seamlessly integrating uncommitted objects added during a transaction. Despite these major improvements, add-speed of MagmaCollections has been improved about 400% in the last year. Read-speed was always fast and remains fast. == Disaster/recovery support == It is now (believed to be) impossible* for the repository to become corrupted should a power-outage occur, however the last few seconds (dictated by #cacheFlushFrequency) of commits could be lost unless you set flushAggressively: true, which will affect performance. == leaner and faster == Between WriteBarrier support, a smaller buffer format, large-collection improvements, Magma has maintained a peak commit rate of 24 per second on my machine. MagmaBenchmarker was developed as a basis for assessing performance limitations. Magma certainly does not have light code-base, but it is better-factored than its ever been. At least two users who have delved into the code have been able to understand it well. == * (no warranty see http://minnow.cc.gatech.edu/squeak/5725, evaluate the design and decide for yourself at http://minnow.cc.gatech.edu/squeak/5724)

1 0

being mailing list
by Chris Muller 25 Jul '05

25 Jul '05

This list is a place to discuss Magma, an object database for Squeak. Thank you, Ken Causey and squeakfoundation, for setting up and hosting this list. - Chris

1 0

Test
by Ken Causey 25 Jul '05

25 Jul '05

Hey, sorry for the noise. Making sure the list is accepting messages. Ken

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Magma July 2005