Re: WebCAT has the devil in it!
This WebDNA talk-list message is from 2003
It keeps the original formatting.
numero = 54062
interpreted = N
texte = 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/
Associated Messages, from the most recent to the oldest:
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/
Alex McCombie
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:
Frames and WebCat (1997)
Search context not finding recent entries (1998)
TCPConnect to query for Domain expiration (2000)
Protect and Serve (1999)
RAM variables (1997)
WebCat2: multiple currency support (1997)
I want a 404 (2005)
Format of Required fields error message (1997)
100% CPU (2003)
WebCat Performance Issue (2000)
WebCat2b13MacPlugin - nested [xxx] contexts (1997)
[WebDNA] WebDNA version 7 feature list? (2011)
WebCat2b13MacPlugIn - More limits on [include] (1997)
(1997)
tcpsend formatting issue ... (2004)
Nested Includes (2001)
Separate SSL Server (1997)
Upgrading old WebCat Database Files (1997)
Summing fields (1997)
New to WebDNA.. Dreamweaver Extensions? (2005)