Monday, August 18, 2008

Locking the ILM Database

Seems that most blog entries trumpet the brilliance of the blogger. This post, not so much.

In short:
never create files in the .\Extensions folder unelss you have a VERY good reason. Doing so can make ILM very busy since it watches this folder for changes. Anytime the folder contents change, ILM sucks up the folder contents into the ILM database. Do it a couple times and you'll probably get away with it. Do this a lot, and you'll see locks and retries, and things will perform miserably. Make it happen on every password set operation, and you're just asking for it.

Longer story:
My favorite tool is my handy XMA and this time I have managed to use it to bring ILM to its knees. Oops. An XMA I'm working on was happily running imports, exports and password sync but the constraints changed forcing me to do some of the import work during my export routines. This work introduced a neat little bug which I'll desribe here in hopes of somebody not doing the same thing. If I get to do another ILM extensibility talk next year, I think this little nugget will make my 'worst practices' slide.

So my Export routines had to be changed to produce the Import file (another blog post). All worked fine, so it seemed. The exports ran and did their work while also producing the delta import file.

Things started to go wrong when we saw another file appear in the Extensions folder. A search of the Export code turned up no reference to this file, so I thought my XMA was innocent. Also, all of our tests were passing without issue. Performance was a little slow at times on perf tests but we could easily blame the web service since it was the obvious choke point. A while later, we saw this file getting created so much that it had to be generated by my XMA.

Another look at the code and pouring over trace logs revealed the file was being created by our XMA's password extension. Even worse, it was getting created on every password set. So if created 5000 objects, that file was getting created 5000 files, which was asking ILM to copy the Extensions folder to the ILM database 5000 times. Bob Tucker was kind enough to show me the SQL Profiler log indicating that this was happening, A LOT.

The fix was simple, but the lesson an embarassing one. No trumpeting for me, just a dunce cap this time around.

Monday, August 04, 2008

ILM Drop Files and the XMA 'ChangedAttributes' Array

Drop files were one of my favourite features in MMS 3.0 when I first saw it, largely because everything in MMS 2.2 was based on files (except for the ADMA). Why are drop files cool? They are cool because they are the same format across all managment agents in ILM, and contain the same kinds of data, so you can easily use them for reporting. It gets better, you can also create a drop file on one machine, then play it into an MA on another machine. Great for trying to repro a rules problem.

A couple years ago I stumbled upon an issue where drop files worked but caused an issue in my XMA. The result was that I had to decide on drop files, or the feature in the XMA I was trying to use.

First a quick look a the XMA's ExportEntry() method:
public void ExportEntry(
ModificationType modificationType,
string[] changedAttributes,
CSEntry csentry
// TODO: Remove this throw statement if you implement this method
throw new EntryPointNotImplementedException();

The code snippet above is the code generated by the ILM UI, except I have placed in a line to raise the debugger for me. Pretty plain so far, so I'm not introducing any bugs of my own.

Now the problem. Notice the changedAttributes array. When drop files are NOT turned on, this array behaves normally. You can expect to see in there a list of attributes that are changed. One might use this to send changed attributes to the target system.

Turning on drop files in an XMA causes this array to be empty. I can repro this by watching the array in the debugger using an Export run profile to turn drop files on and off.

Drop files turned on causes the array to have no items (looks like a bug).
Drop files turned off causes the array to have items (expected behaviour).

Moral of the story is, drop files good, bug in XMA not so good, proceed with caution and use the features accordingly. If you really need this one solved, raise it to PSS and let them know somebody needs this fixed.