Rudolph van Graan
Mon Jan 2 15:09:10 CET 2006
Haven't spoken to you for a while...!
We have an internal rule that it is illegal to have *any* side
effects apart from mnesia calls inside the transaction funs. Side
1. Sending/receiving messages
2. Any socket calls
3. Any file accesses
4. Any calls to gen_server processes
5. Any ets/dets calls etc
Also look for nested transactions (dirty access context over
syncronous transactions access contexts) etc. They can crash mnesia
We have been bitten a number of times by caused by side-effects which
by nature is very difficult to trace. Symptoms include infinite
recursions, deadlocks, hangs etc etc. Nasty stuff.
A good rule of thumb is to think what will happen when the
transaction fun is executed more than once. Will it change the
result? If so, you have side effects.
On 02 Jan 2006, at 1:36 PM, Adam Aquilon wrote:
> Thank you Dan and Klacke!
> We're currently looking at both using R10 and finding any potential
> deadlocks in transactions. See below for comments:
> Dan Gudmundsson wrote:
>> Oh No, don't use 4.1.12 (precompiled) and don't use the compiler from
>> that release, that compiler produced broken code on mnesia_tm which
>> wrote garbage on the heap (or somewhere else) which could
>> cause really
>> strange problems.
>> Try upgrading compiler, recompile mnesia and try again.
>> Other than that mnesia have had a couple fixes since 4.1.12 :-)
>> it could be worth upgrading to something later.
>> Nowadays the compiler have an inbuilt beam validator that checks that
>> the produced code don't have such problems anymore.
> Thanks for the tip!
> We haven't upgraded before because of some extra packages that we
> must compile into the release (we make our own RPM's) which is a
> bit of a bother. Also, "the devil you know" is better than new,
> uncharted functionality when it comes to releases.
> But now it seems that it is time to start using R10 after all.
> Klacke wrote:
>> So - tip no 1, check for gen_server:calls inside your transactions.
>> Look closely on your user process (i.e <0.932.1> )
>> and figure our what it's waiting for and why. What's the message
>> in the queue for that process !!! very suspicious.
> Unfortunately the VM ran out of memory during sunday morning and
> was autorestarted, so I can no longer examine the processes again
> without forcing another hang.
> I checked the crash dump and there weren't very many processes in
> the system, around 2300. Granted, this is more than normal, but not
> an enormous amount. This indicates that some process(es) were eating
> large gobs of heap space.
> Doesn't this speak against having a pure deadlock situation?
> (We are looking for receive stuff inside transactions anyway, just
> to be sure.)
More information about the erlang-questions