Magma November 2008

magma@lists.squeakfoundation.org

6 participants
7 discussions

[ANN] Magma release 41.1
by Chris Muller 01 Dec '08

01 Dec '08

I have just posted release 41.1 of Magma to both squeakmap and the "Magma" project of squeaksource. There is no new functionality, but 41.1 contains some important factorings and improvements in preparation for release 42. There are also some important fixes to a couple of unfortunate bugs that crept into release 41. I recommend anyone using 41 to upgrade to 41.1. - Chris

2 1

[ANN] r42Alpha1
by Chris Muller 29 Nov '08

29 Nov '08

I am pleased to announce the first alpha release of Magma 42. 42 adds the ability to start the repository which was output from MagmaRepositoryController>>#fullBackupTo:, at which point it will automatically "join" the MagmaNode of which the original repository is a part, and becoming a read-only "warm backup" that is updated continuously by the original server running at the #primaryLocation. A MagmaNode is simply an Array of MagmaRemoteLocations that act as a cluster of servers each supporting their own physical copy of one logical repository. Besides the improved read-scale, we get continuous, automatic backups, 24x7x365 operation, and the ability for the Node to crawl from one data-center to another without ever bringing the system down. This alpha release passes the entire legacy test-suite and has been manually unit-tested for a variety of the MagmaNode test cases. Some day I will adjust the automated test suite to include these tests. Enjoy, Chris

1 1

Unable to realize Orphaned MagmaMutatingProxy
by Phil＠Work 29 Nov '08

29 Nov '08

Hi All, I occasionally get this message: Unable to realize Orphaned MagmaMutatingProxy What causes this? I believe i'm referring to a legitimate committed object. Thanks, Phil ------------------------ Phil Blake Information Systems Retail Information Systems Pty Ltd Level 2, 35 Spring Street Bondi Junction, NSW, 2022 Cell: 0438 55 0000 Fax: 1300 747 001

3 2

Such useful information! (was: Re: so many processes)
by Chris Muller 25 Nov '08

25 Nov '08

Hi Keith, I'm copying the list on my reply. Magma, for years has included a simple tool (MagmaBenchmarker) that reports the rate of its operations in a micro way. From this report, it is feasible to guess what kind of application performance can be expected. Still, questions continued to be asked like, "how fast is Magma?", "which is faster, Magma or database-X?", "why is my Magma application so slow?" The only way I knew to probe deeper into these questions was to integrate detailed self-monitoring. Even beyond these questions, though, is the need for Magma to monitor and reports its own health and load vs. capacity for industrial-strength systems based on it. The stats, which were a major part of the 41 release, capture timings for each part of the request lifecycle, as well as other operations on both the client and server side, that make this possible. There is already an option, #snapshotInterval:, available to the user to change the default rate and duration of the captured stats (which is every five minutes of the last half-hour). Beyond that, I decided to just make the stats as non-intrusive as possible rather than an additional boolean check all throughout the code. The processes are in 5-minute #waits at the end of which they run probably less than 1 milliseconds worth of code, so they have no noticiable impact on performance. I've also now put them at userInterruptPriority+1 (= 51), so they are separated out in the Process browser (which is just a ui tool that could be customized anyway). Regards, Chris On Mon, Nov 24, 2008 at 11:42 PM, Keith Hodges <keith_hodges(a)yahoo.co.uk> wrote: > Chris, > > can the stats be turned off? 44 processes per client, what are they all > for? Is this in the server only? > > Keith >

1 0

so many processes
by Phil＠Work 25 Nov '08

25 Nov '08

Hi All, I've seen this answered in the archive a couple of months back, however the solution isn't working for me. I have around 3000 processes that appear to be defunct timers - ie i've shutdown magma, thrown away the magma directory, started up squeak again, and... many thousands of magma processes - at one stage around 5000 processes! (50s) Time to process MaRepositoryConnectionRequest: Process>>terminate (50s) Time to process MaAbortTransactionRequest: Process>>terminate (50s) Time to process MaReadRequest: Process>>terminate (50) Time to process MaRepositoryDisconnectRequest: Delay>>wait (50) Time to process MaRepositoryDisconnectRequest: Delay>>wait (50) Time waiting for MaRepositoryDisconnectRequest requests: Delay>>wait (50) Time waiting for MagmaIdRequest requests: Delay>>wait (50) Time to process MaReadRequest: Delay>>wait (50) Time to process MaRepositoryDisconnectRequest: Delay>>wait (50) Time to process MaRepositoryConnectionRequest: Delay>>wait (50) Time to process MaAbortTransactionRequest: Delay>>wait ...and so on. The solution i tried was: MagmaSession cleanUp result: 'MagmaSession instances (before->after): 0->0' still many thousands of processes. Does anyone know how to clean up the mess? Thanks in advance, Phil ------------------------ Phil Blake Information Systems Retail Information Systems Pty Ltd Level 2, 35 Spring Street Bondi Junction, NSW, 2022 Cell: 0438 55 0000 Fax: 1300 747 001

5 7

[ANN] Magma release 41.1
by Chris Muller 24 Nov '08

24 Nov '08

1 0

Sequence numbering problem... solved.
by Göran Krampe 22 Nov '08

22 Nov '08

Hi! As Chris knows we need sequence numbers in Gjallar. Chris implemented #serverPerform:withArguments: but I admit being slightly stumped with it. I think the idea is that you add methods to MagmaRepositoryController like for example: q2CounterInitialize: anId | sess counter | counter := 0. sess := self session. sess cacheAt: anId put: counter. ^sess commit: [ sess root environment at: anId put: counter ] q2CounterNext: anId | sess | sess := self session. ^sess commit: [ sess root environment at: anId put: (sess root environment at: anId) + 1] q2CounterValue: anId | sess | sess := self session. ^sess commit: [ sess root environment at: anId ] ...and then we call them, right? Soo... today I ended up getting errors about serialization: "MaMalformedRequestError: No createProxyBlock specified. See MaObjectSerializer>>toCreateProxies:" Aha... I think I realized this now - the id above is a UUID but we are sending a MaMutatingProxy instead. So I added just a little call like "{id yourself}" to make sure it gets faulted - and then it seems to work. regards, Göran

3 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Magma November 2008