Re[2]: [Declude.JunkMail] Log Corruption

2005-03-01 Thread Pete McNeil
On Tuesday, March 1, 2005, 5:38:54 PM, Darrell wrote:

Dsic I though Pete had some locking mechanism built in to prevent overlapping.

Dsic Pete? 

Yes. This is it. (quite a lot of locking actually)

This is a pet peeve of mine so I'm going to go just slightly off topic
- it might help someone else out there writing code like this...

There are a number of things in Win32 land that are not atomic like
they should be. (Atomic meaning - they complete all at once before
anything else can happen.)

One of these that caused a lot of extra work in SNF peer-server code
is rename(). The other is appended writes to a file.

As a result, it is possible for more than one thread to believe it has
renamed a single file successfully - which is supposed to be
impossible.

Thread A tries to rename file JOB.QUE to JOB.AAA and succeeds.

Thread B tries to rename file JOB.QUE to JOB.BBB and succeeds!!!

The actual file name at the end - flip a coin and pick one - JOB.BBB
or JOB.AAA.

Appended writes work the same way.

Thread A opens a file for Append and writes

Thread A stuff and only thread A stuff so there!\n

Thread B opens the same file for Append and writes:

Thread B, thread B, what a silly thread I B!\n

Both writes succeed happily.

Unfortunate sleep deprived programmer sure that he is going stark
raving mad opens up the file and sees:

Thread A stufead B, what a silly th\n I B! there...

where ... is following on to some other unrelated log entry...

(sigh)

Luckily, it seems that creating a file is atomic, so there is a way
out. This is what I use for some simple inter-process locking (that,
by the way, is cross-platform [posix] compatible):

open(LockName.c_str(),O_WRONLY|O_CREAT|O_EXCL);

--- The actual code I use for locking is bigger than this of course.
I'm attaching an excerpt from logger.cpp that takes care of it.

Hope this helps,

_M



win32lock.cpp
Description: Binary data


Re[2]: [Declude.JunkMail] Log Corruption

2005-03-01 Thread Pete McNeil
On Tuesday, March 1, 2005, 5:48:17 PM, Andrew wrote:

CA (Pete isn't here much)

:-(

I do usually lurk though...

I'll try to post more often...

;-)

_M



---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type unsubscribe Declude.JunkMail.  The archives can be found
at http://www.mail-archive.com.


Re[2]: [Declude.JunkMail] Log Corruption

2005-03-01 Thread Pete McNeil
On Tuesday, March 1, 2005, 7:14:31 PM, Darin wrote:

DC I disagree with the struggling server logic.  We saw the log corruption in a
DC test environment a year ago that had minimal traffic, say a couple thousand
DC messages a day.  It was a dual 1.4GHz processor with 1 GB RAM and 10k RPM
DC SCSI drives.  Load was only about 1-5% during testing.

Heavier loads will cause more processes to collide and so log
corruption is likely to be more pronounced in those situations.

_M



---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type unsubscribe Declude.JunkMail.  The archives can be found
at http://www.mail-archive.com.


Re: Re[2]: [Declude.JunkMail] Log Corruption

2005-03-01 Thread Darin Cox
Correct.  What I was saying I disagreed with was the concept that it only
occurred on struggling servers.  This test machine was very lightly loaded
and we saw log corruption.

Darin.


- Original Message - 
From: Pete McNeil [EMAIL PROTECTED]
To: Darin Cox Declude.JunkMail@declude.com
Sent: Tuesday, March 01, 2005 7:30 PM
Subject: Re[2]: [Declude.JunkMail] Log Corruption


On Tuesday, March 1, 2005, 7:14:31 PM, Darin wrote:

DC I disagree with the struggling server logic.  We saw the log corruption
in a
DC test environment a year ago that had minimal traffic, say a couple
thousand
DC messages a day.  It was a dual 1.4GHz processor with 1 GB RAM and 10k
RPM
DC SCSI drives.  Load was only about 1-5% during testing.

Heavier loads will cause more processes to collide and so log
corruption is likely to be more pronounced in those situations.

_M



---
[This E-mail was scanned for viruses by Declude Virus
(http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type unsubscribe Declude.JunkMail.  The archives can be found
at http://www.mail-archive.com.

---
[This E-mail was scanned for viruses by Declude Virus (http://www.declude.com)]

---
This E-mail came from the Declude.JunkMail mailing list.  To
unsubscribe, just send an E-mail to [EMAIL PROTECTED], and
type unsubscribe Declude.JunkMail.  The archives can be found
at http://www.mail-archive.com.