[MUD-Dev] Hosting questions

[ceo]

Mike Rozak wrote:
> Scott Jennings wrote:

>> If Windows, you can use VNC or similar programs to run the
>> machine remotely, but if your server hard-locks the machine you
>> will probably need someone on call to press the shiny red
>> emergency button.

> I run WinNT (which many disdain... Is there MTF evidence that NT
> as a server is less stable, or is it anti-Microsoft rhetoric?). I
> don't expect to hard lock the machine.

IME NT is nicely stable *if* you have the right service pack
("right" varies from person to person :P), but very sensitive to
hardware-driver bugs and "latest bumph from MS" bugs (e.g. any
service pack post SP3 you've got a good chance of breaking something
that used to be working :().

I would also point out that w2k is - IME - better *and* has pretty
much the same resource requirements so long as you spend some time
tuning the system, removing any ridiculous unwanted features
(Computer-aided telephony support on by default? Riiiighhhttt...),
etc. Amusingly, early versions of w2k were poor on their checking of
what they were letting you do - I found you could turn off enough
core services that you could no longer load the Services app that
turns on services. e.g. It's fairly easy to get a fully working w2k
install using only 45Mb RAM.

> My biggest concern is a crash that will GP fault my application on
> the server, with said GP fault potentially losing the last few
> lines of debugging information I log, and me not being able to
> trace the fault. James Turner suggested I use visual studio's
> remote

Very much depends what type of fault you're expecting. If you're
aiming at the repeatable ones, it's fairly easy to pessimistically
write-out loglines from a certain breakpoint onwards.

I would humbly submit that if you're facing serious problems with
unrepeatable ones then you have bigger fish to fry than merely
keeping the last few log lines :).

> Because most of my server code is script with reference-counted
> data, the biggest crash culprit is an out-of-memory caused by too
> many strings/objects being created. I can add some extra safety
> code

Real reason I'm responding is to point out an FYI here. After a
certain someone (moi) complained vociferously at certain failings in
Java's handling of OOM situations (read: I found another bug in
their OOM handlers :P) myself and a couple of others pointed out
that Java has the opportunity to cleanly catch OOM errors. At the
moment, if it hits an OOM it:

  1. tries a last-gasp garbage-collect (IIRC - may no longer be the
  case with the funky GC's it uses these days)

  2. crashes.

If you're *really* lucky, you *sometimes* get some stack trace info
printed to std-err. Usually not, though - it has no memory left to
do so (old versions of java would apparently try, and you'd get
error messages with half the text missing and other oddness).

This is silly: it's a virtual machine, meaning it has the ability to
(optionally, I suppose) allocate "a little more memory than asked
for", keeping a small area free for the sole purpose of object
creation needed when throwing + logging an OOM error. I actually
thought it did do that these days, until I started hitting OOM's on
the latest JVM (c.f. first para above ;), and my reactions to
that...).

But I believe Jeff Kesselman's (a sun java developer) is now
proposing internally that this be added as a feature, which would be
handy.

> Anything else that I should watch out for?

I/O libraries that are confusingly not cross platform yet appear to
be, and tutorials and books that talk about an API on one O/S that
has completely unrelated semantics on the O/S that YOU are using :).

Oh, and...I would *strongly* recommend hosting on Debian instead
:P. Not because I'm a linux-lover, but because it's configuration
system is a heck of a lot better than windows (in terms of safety,
and it's ability to roll app-versions forwards and backwards), but
not as daunting as BSD's (which IMHO is superior but too hard for
most normal people to ever quite get around to understanding :( ).

...and don't touch RedHat with a bargepole: failings in their
packaging system make it just like the worst days of NT updates:
it's fairly easy to get your system in a state where it is both
broken AND core programs (e.g. the kernel!) will no longer compile
AND you cannot fix it without manually finding and deleting every
app and kernel module everywhere - even the ones you don't use
(which ought to have no effect, but actually do). Not good.

Adam M
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://kanga.nu/lists/listinfo/mud-dev