Re: WebCAT has the devil in it!
This WebDNA talk-list message is from 2003
It keeps the original formatting.
numero = 54065
interpreted = N
texte = We are a bit out of sync on our posts ;) >It appears that when WebCAT went to do a safe write, that it saw a >tempDB >already there and as such created a new one with an incremented number. This is correct. >However, this time, instead of deleting the tmp file after the safe >write it >left it. What is supposed to happen is that the original db file gets renamed to something like "my.db-oRiGiNaL-". If the rename succeeds, then the new temp db file is renamed to the original db name. And if that rename succeeds, the "my.db-oRiGiNaL-" is deleted. I suspect that an 'very' untimely crash occurred during the rename process (which would be pretty rare) and left a dangling "...-oRiGiNaL-" file. This would prevent the first rename step from completing, and would lead to the new incremented tmp file being left in place. IF this happens, delete the '...-oRiGiNaL-' file, backup your original db file, and replace it with the tmp db file with the largest increment. If this happens fairly frequently on your server, the only option that I see would be for you to turn off that Safe Write feature. I would also make sure that error logging is enabled, and check the error logs to track and fix templates bugs. You can also enable the 'Technical Support Information' pref. This will log every hit that comes into the server to a file called WebCatalog.debug. Using this file, you have a good chance of tracking the last template requested before each crash. You can then examine that template code for any errors. That debug log can get pretty big, very fast, so only enable it when you are able to spend some time examining the entries. If resolving template bugs improves engine stability, then you can try re-enabling the SafeWrite pref. Also, it is always a good idea to perform frequent backups of your db files. We will continue to improve the 'Safe Write' code for future releases, as it is a beneficial feature. -----Original Message----- From: Alex McCombie [mailto:alex@newworldmedia.com] Sent: Thursday, November 13, 2003 9:20 AM To: WebDNA Talk Subject: Re: WebCAT has the devil in it! On 11/13/03 11:53 AM, "John Peacock"
wrote: > That is exactly the kind of behavior you might see if a spider was hitting > your > site. The fact that it stopped just before you noticed is, IMHO, coincidence. > The fact that the tmp files started showing up at a specific time and stopped > at > a specific time certainly suggests that it was an outside agent... Ok some research and checking and this is what I "believe" happened. I need SMSI to confirm my assumptions on the TMP file issue below to know for sure though. On Tues. noonish, there appears to have been an unscheduled restart. (crash). Apparently WebCAT was in the process of updating the DB with a safe write... Hence the first creation of the tmp file. This disruption in the DB update left an 'orphaned' tmp file in the DIR. Then I have been able to coordinate (roughly) the creation of other TMP db's with traffic for visiting users. Each visit updates the DB. This seems to explain the need for safe write. NOW THE ASSUMPTIONS: It appears that when WebCAT went to do a safe write, that it saw a tempDB already there and as such created a new one with an incremented number. However, this time, instead of deleting the tmp file after the safe write it left it. Then each safe write later, at random times and coordinated with traffic to the area, it created a new incremented tmp file and left it. The last tmp file created was just 9 minutes before I discovered it! I seem to have broken the chain by removing (trashing) all the tmp file in the DIR, thus allowing WebCAT to safe write as expected. If I hadn't removed them I am betting the cycle would have continued. BUT QUESTION TO SMSI Shouldn't the safe write delete the temp file in question if it successfully writes to the db as it does when it doesn't find a tmp file in its way? In other words, it seems a logic flaw is at work here. If DNA finds no tmp file in its way, then it creates one, and safe writes and then deletes it. However, if it find a tmp file 'in its way' it creates an incremented one and succeeds in its safe write, BUT DOES NOT DELETE the incremented version...thus starting on the never ending path to a dead machine. Scott, can you take these questions and assumptions to someone there to confirm or deny them. It appears that I have a real good grip on how and why it occurred, and even how it stopped, but if I am right, then it would seem that the safe write logic of never deleting tmp files is a potential time bomb... And notice I say potential as this is obviously not something that is easily replicated. Basically I am just trying to get a grip on how this happened so that I can devise some strategy for an early warning system in the future. Some my DB's are quite large and the time it would take to have those east the HD would be much much less. Thank Alex Alex J McCombie New World Media Chief Information Officer Box 124 888/892.6379 MartVille, NY 13111 Alex@NewWorldMedia.com http://OurClients.com Interface Designer WebDNA Programmer Database Designer ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/
Associated Messages, from the most recent to the oldest:
We are a bit out of sync on our posts ;) >It appears that when WebCAT went to do a safe write, that it saw a >tempDB >already there and as such created a new one with an incremented number. This is correct. >However, this time, instead of deleting the tmp file after the safe >write it >left it. What is supposed to happen is that the original db file gets renamed to something like "my.db-oRiGiNaL-". If the rename succeeds, then the new temp db file is renamed to the original db name. And if that rename succeeds, the "my.db-oRiGiNaL-" is deleted. I suspect that an 'very' untimely crash occurred during the rename process (which would be pretty rare) and left a dangling "...-oRiGiNaL-" file. This would prevent the first rename step from completing, and would lead to the new incremented tmp file being left in place. IF this happens, delete the '...-oRiGiNaL-' file, backup your original db file, and replace it with the tmp db file with the largest increment. If this happens fairly frequently on your server, the only option that I see would be for you to turn off that Safe Write feature. I would also make sure that error logging is enabled, and check the error logs to track and fix templates bugs. You can also enable the 'Technical Support Information' pref. This will log every hit that comes into the server to a file called WebCatalog.debug. Using this file, you have a good chance of tracking the last template requested before each crash. You can then examine that template code for any errors. That debug log can get pretty big, very fast, so only enable it when you are able to spend some time examining the entries. If resolving template bugs improves engine stability, then you can try re-enabling the SafeWrite pref. Also, it is always a good idea to perform frequent backups of your db files. We will continue to improve the 'Safe Write' code for future releases, as it is a beneficial feature. -----Original Message----- From: Alex McCombie [mailto:alex@newworldmedia.com] Sent: Thursday, November 13, 2003 9:20 AM To: WebDNA Talk Subject: Re: WebCAT has the devil in it! On 11/13/03 11:53 AM, "John Peacock" wrote: > That is exactly the kind of behavior you might see if a spider was hitting > your > site. The fact that it stopped just before you noticed is, IMHO, coincidence. > The fact that the tmp files started showing up at a specific time and stopped > at > a specific time certainly suggests that it was an outside agent... Ok some research and checking and this is what I "believe" happened. I need SMSI to confirm my assumptions on the TMP file issue below to know for sure though. On Tues. noonish, there appears to have been an unscheduled restart. (crash). Apparently WebCAT was in the process of updating the DB with a safe write... Hence the first creation of the tmp file. This disruption in the DB update left an 'orphaned' tmp file in the DIR. Then I have been able to coordinate (roughly) the creation of other TMP db's with traffic for visiting users. Each visit updates the DB. This seems to explain the need for safe write. NOW THE ASSUMPTIONS: It appears that when WebCAT went to do a safe write, that it saw a tempDB already there and as such created a new one with an incremented number. However, this time, instead of deleting the tmp file after the safe write it left it. Then each safe write later, at random times and coordinated with traffic to the area, it created a new incremented tmp file and left it. The last tmp file created was just 9 minutes before I discovered it! I seem to have broken the chain by removing (trashing) all the tmp file in the DIR, thus allowing WebCAT to safe write as expected. If I hadn't removed them I am betting the cycle would have continued. BUT QUESTION TO SMSI Shouldn't the safe write delete the temp file in question if it successfully writes to the db as it does when it doesn't find a tmp file in its way? In other words, it seems a logic flaw is at work here. If DNA finds no tmp file in its way, then it creates one, and safe writes and then deletes it. However, if it find a tmp file 'in its way' it creates an incremented one and succeeds in its safe write, BUT DOES NOT DELETE the incremented version...thus starting on the never ending path to a dead machine. Scott, can you take these questions and assumptions to someone there to confirm or deny them. It appears that I have a real good grip on how and why it occurred, and even how it stopped, but if I am right, then it would seem that the safe write logic of never deleting tmp files is a potential time bomb... And notice I say potential as this is obviously not something that is easily replicated. Basically I am just trying to get a grip on how this happened so that I can devise some strategy for an early warning system in the future. Some my DB's are quite large and the time it would take to have those east the HD would be much much less. Thank Alex Alex J McCombie New World Media Chief Information Officer Box 124 888/892.6379 MartVille, NY 13111 Alex@NewWorldMedia.com http://OurClients.com Interface Designer WebDNA Programmer Database Designer ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/ ------------------------------------------------------------- This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: To switch to the DIGEST mode, E-mail to Web Archive of this list is at: http://webdna.smithmicro.com/
"Scott Anderson"
DOWNLOAD WEBDNA NOW!
Top Articles:
Talk List
The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...
Related Readings:
Um. silly question perhaps...but I don't know, so I'm askin'.. (2001)
Multiple Users.db Possible? (1997)
Nested tags count question (1997)
Emailer (1997)
It just Does't add up!!! (1997)
Time math (2002)
Updating Prices in Online Database (1999)
rotating thumbnails (1997)
THE ANSWER - why .HTML pages no processing? (2000)
PCS Customer submissions ? (1997)
password authentication schemes (2003)
Initiating NewCart (1997)
AccountAuthorizer doesn't seem to work (1997)
DDE feature in webcat (1998)
primer/tutorial question (2004)
[append] (1998)
Removing [showif] makes a big difference in speed (1997)
tabs as delimiters (2004)
Search in 2 or more catalogs (1997)
Bad File: DeleteCommand.html (1998)