[ASIDE: I tried posting to your blog, btw, but it's erroring out....]

I thought about various approaches to address this before posting my idea, and the alternate solution does not fully address things.

The point of email is that the <client can access it>. That sounds silly, eh?

There are situations where the mailfile on the server is too slow to respond due to performance or network issues that --> the server doesn't know about <--, and therefore can't actually address.

Suppose you have a cluster pair, one in New Orleans, one in Dallas.

The user typically uses the one in New Orleans, but for whatever reason, the link to NOLA is too slow and times-out. (what with all the partying last night)

In this scenario, the client should NOT display an error about "not responding", it should either automatically or prompt the user to fail over to Dallas.

The New Orleans server really can't be expected to know that the client is having trouble in this scenario.

BUT, unlike stupid web-browsers, we have SMART client that can figure things out, if we design it such.


{ Link }

I really should say that I agree with this idea and have promoted it.

There are just certain other situations that it doesn't fully address.

Craig,

I'm not saying that this is the whole solution.

But it's probably easier to put a shared library in which checks if the server is a cluster, and if it is then marks the DB as Out of Service before working on it. They can then just call that library before fixup/compact works.

This is the kind of small improvement that could be put into an incremental release (albeit turned off by default).

Re-writing the client failover code would be more of a next-big-release job, I'd have thought. It needs a lot of testing, and probably requires more hassle.

I see your point about widely distributed clusters over a WAN, but 95% of these failover issues are likely caused by compact/fixup. Why not fix those the obvious, easy way? Then the last 5% can be dealt with by your suggestion (which I voted for, by the way).

A smart client would be great. I'd like the server to be smart too, though. I can't help that - I'm an Administrator, after all! ;-)

Why not just use the -o or -z (depending upon your needs) with Fixup to take the DBs offline? That should solve half of this problem.

For compact, that's different, and I could see Lotus expanding the capability to add an offline option for that feature. Know that as @2 mentioned, there are some circumstances where one wants the DB to remain on-line--even in a cluster. Particularly if the time to switch over is longer than the time the Domino server would be touching the file.