Summary of "Magma notes" issues

Chris Muller afunkyobject at yahoo.com
Sat Jul 10 17:37:09 UTC 2004


Hi Avi, I've now had time to go through all three "Magma notes" and thought it
would be easier to summarize my findings in one note.  After reviewing all
notes in detail and attempting to reproduce everything, the quick, summary
answer is, I discovered no significant issues.  All the tests that you
performed either worked for me or your expectations differed from how it works.

My main purpose in reporting this is to clarify that the current release,
"1.0gamma7" truly is "gamma" quality IMO, not "alpha" or "beta" quality as has
been characterized, at least somewhat, by the poor experience you had.

> Chris, if there are particular issues I found that you want help in 
> reproducing, just let me know.

Yes, I think the next step is to try to establish reproducibility in some of
the issues you encountered.  Some kind of straight-run script that demonstrates
a particular problem.  My guess is, you will not be able to produce a script
that locks the image, corrupts data, produces inconsistent results, or anything
else really bad like that unless you go outside the bounds of what Magma
"supports".  (I plan to add a Swiki page later this weekend that spells out
Magma's boundaries and limitations, hopefully that will help clarify the air
too).

> is it possible for me to corrupt the database?
Yes, there is no transaction logging, so a hardware failure in mid-write would
leave half a transaction committed.  It is planned for the future, but not the
top priority on my list just yet.

> How easy is it to lose data?
Actually, not too easy, as long as hardware doesn't fail.  But it is advisable
to take some care, of course.

Also, another good "platform test" would be to run the Magma test cases on your
Mac.  I always ensure they run on Windows before I post to SqueakMap so if it
can't get through those, then there may be a platform-specific bug in Squeak
somewhere.  They take a while to run, and it's not just a click in TestRunner
browser so let me know if you need any assistance getting it set up.

And this also brings up a good point.  The test-cases are pretty stringent,
covering lots of weird combinations and scenarios.  By studying those, you can
see exactly what Magma is capable of, because it *does* get through them all.  
Ok, what follows are the boring details for each set of notes.

Magma notes 1:

Here the entire problem is that Magma does not support "relative path" file
names.  There are just three or four messages in the entire API that call for a
filename and I always use fully-qualified names.  I will add improving this to
my list but, in the mean time, use fully-qualified names and all these problems
should go away.

MaFilename is a facade for accessing the parts of filenames.  I hope that
changing its implementation to rely more heavily on what FileDirectory (you
said FileStream, I presume you meant FileDirectory) will help relative
filenames work on all platforms.  If I've duplicated functionality I probably
just didn't see it.  I'll research that and add that to my list of
improvements.

Magma notes 2:

In this one, the only anomaly I was able to reproduce was the apparent lack of
commit-conflict detection.  I was very surprised by this at first, but I now
see why.  I had my MaClientServerPreferences debug set to true, which turns off
the resignaling of the exceptions that occurred in the server (the
MagmaCommitError) and simply returns them instead (hmm, now I'm trying to
remember why I wanted that behavior..).

Please see if you, too, have yours turned on and, if so, execute this:

  MaClientServerPreferences debug: false.
  MagmaPreferences debug: false

and then it will signal the commit error instead of just returning it.

Magma notes 3:

Basically, everything you were doing here was simulating what you want to do
for a web app.  I want to be clear when I say I have never used nor tested
Magma for this purpose, but, based on how its coded, I think it *should* work. 
 Let me try in Windows.

Ok, I just tried the test where you commit the clock continously:

  [[mySession commit: [mySession root at: 'now' put: Time now]] repeat] 
fork

and, in the mySession2 inspector:

  [ [ self abort. Transcript cr; show: (self root at: 'now') ] repeat ] fork

I let it run all night long.  This morning, both processes were still chugging
and the server console shows #objectCount at 84302, so an average of about
three commits per second.

> Lesson learned: do not save and quit a running magma server.

No, this works too.  In fact, I just killed the server (save and exit image). 
However, there *was* a problem killing the clients after the server because
they automatically try to disconnect and wait for the server response.  I've
already fixed that in 1.0beta8.  But bringing the server back up and then
connecting with clients did work just fine.

> Ok, can connect, but can't get the root - same old strange 
> silent-failure business.

There is no no silent-failure business.  If you can't get the root then one of
the server processes must've gotten killed, so you're going to be flailing in a
rut for anything you try going forward.

> Just out of curiosity, try to use the client session while the server 
> is down.  My image locks up.  After a while, I manage to interrupt it, 
> inside a critical section in MaTcpRequestServerLink>>submit:.

A ha!  You ARE in debug mode because otherwise the timeout should have occurred
after 30 seconds.  When in debug mode it is set to 2 days so I have plenty of
time to debug.  You are running in debug mode.

> Open the ProcessBrowser to try to kill the process

This is a good way to get Magma in a funky state and, quite possibly, stuck in
a rut.

 - Chris



More information about the Squeak-dev mailing list