Re: [mv] 15 orders missing

[Kyle Hayes <kyle540@quicknet.net>]

On Wed, 06 Oct 1999, you wrote:
> ******    message to minivend-users from mikeh@minivend.com     ******
[losing orders]
> It's pretty hard, but it can be done. Usual reason is running out of
> disk space; there is not much I can do there. The best thing to do is
> keep session file space, database file space, and tracking files on
> different partitions.

The usual problem I had was crashing tags that I wrote :-(

> Many ISPs are very tricky about clearing no-space errors and not
> letting anyone know, so having space when you discover the problem
> is not necessarily an indicator.

Since we run our own servers, this is not a problem.

> > Losing orders is bad.  Losing them after you have charged the customer's
> > credit card is Really Bad(tm).
> 
> If you use CyberCash, that should be hard too.

We use Signio (ne PaymentNet).  I always do an authorization first and
then at shipping time, we actually perform the delayed capture.  This is
both to protect the customer and for legal reasons.  You cannot charge a
credit card unless you ship the product within 24 hours.  Since we get
orders throughout the weekend, but only ship Monday through Friday, we
divide the process up.

This protects the customer because uncaptured funds are returned to the
customers credit bin after a fairly short period of time (a week or a
month, I can't remember).  Thus, even if we have a major disk crash or
something, we will only charge those customers for which we shipped
product.  This makes the legal folks happy :-)

> If you find yourself losing orders, then do this just before running
> expire:
> 
>   bin/dump -c yourcatalog | gzip -c | sessions.`date '+%Y%m%d%H%M'`.gz
> 
> That will keep the raw sessions in a file for later reconstructions
> if you have problems. Again, if you have run out of disk space
> then there is not much that can be done.

This brings up a question I had about sessions.  Do sessions timeout and
disappear, or is it the nightly 'expireall' that actually removes them? 
Is there are way to put sessions into a database table?

> Catalogs I have run have now taken about a million orders without
> losing one -- except to out-of-disk-space errors. Even then, if your
> mail is on a different partition there should be a mailed report.
> 
> If no one has ever mentioned this before, One Big Partition is bad
> boogie on a production system. Yet I see it done all the time.

It depends on the OS.  If you truly want to make sure that MV has its own
little playpen, then it should be in its own partition.  I tend to handle
this by having only one service per machine.  I.e. a machine will run MV
and absolutely nothing else.  My orders are stored into a separate
database server, so I certainly hope I can fit more than 1M in it.  That
40GB of space should hold more than that!  I like to store high-growth
data on very specialized servers where I can watch it constantly.  By
doing this, I have found that most of the disk use on the MV server is
from system (not even MV) log files.

I am not a fan of renting space on someone else's machine.  I agree with
Mike above that ISPs can cause problems that you can't track down.

Best,
Kyle