Re: WebCAT has the devil in it!

This WebDNA talk-list message is from

2003


It keeps the original formatting.
numero = 54067
interpreted = N
texte = >Sounds great Scott, but one hanging question... If I do turn it off, >which I >may not, what ultimately am I losing in functionality? Well, the engine will revert to pre 4.5.1 behavior. Meaning that if the server or WebDNA crashes during a database write, you will lose those database records that were not yet written to disk. >PS... I would wager that any developer in my position would have >probably >rather WebCAT stop duplicating the files after a certain number(perhaps >a >pref setting). The uncontrollable nature of this scared me...jmho That was one of the improvements to the 5.0 version of the 'Safe Write' code. It will roll the index of the tmp filename after 10. So, there will never be more than 10 tmp files for any given database. Preferably, of course, we would never want to see any tmp db files left on disk. Having re-visited the code today, I can see where we can improve on the existing algorithm to 'recover' from a dangling '...-oRiGiNaL-' file. Yet another 'to-do' for the 5.2 release. -----Original Message----- From: Alex McCombie [mailto:alex@newworldmedia.com] Sent: Thursday, November 13, 2003 10:45 AM To: WebDNA Talk Subject: Re: WebCAT has the devil in it! On 11/13/03 1:34 PM, "Scott Anderson" wrote: >> 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. Bingo, there was a file created by WebCAT in there with the original in the name... Causing the continuing failure. > 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. Interestingly enough, the true original file (something.db) had all the updated data as the largest increment. Which would be slightly different than you mention but still worked for us. > 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. This assumes that the 'crash' had anything to do with webcat, which I do not believe it did. Certainly untimely and for the record the one and only occurrence of this I have ever seen! > Also, it is always a good idea to perform frequent backups of your db files. We do, and thankfully I coded those backups by exact name and not by directory. Imagine that ..lol > We will continue to improve the 'Safe Write' code for future releases, as it > is a beneficial feature. Sounds great Scott, but one hanging question... If I do turn it off, which I may not, what ultimately am I losing in functionality? PS... I would wager that any developer in my position would have probably rather WebCAT stop duplicating the files after a certain number(perhaps a pref setting). The uncontrollable nature of this scared me...jmho 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:

    
  1. Re: WebCAT has the devil in it! ( Alex McCombie 2003)
  2. Re: WebCAT has the devil in it! ( Glenn Busbin 2003)
  3. Re: WebCAT has the devil in it! ( WJ Starck 2003)
  4. Re: WebCAT has the devil in it! ( Brian Fries 2003)
  5. Re: WebCAT has the devil in it! ( Kenneth Grome 2003)
  6. Re: WebCAT has the devil in it! ( "Scott Anderson" 2003)
  7. Re: WebCAT has the devil in it! ( Alex McCombie 2003)
  8. Re: WebCAT has the devil in it! ( "Scott Anderson" 2003)
  9. Re: WebCAT has the devil in it! ( Alex McCombie 2003)
  10. Re: WebCAT has the devil in it! ( "Scott Anderson" 2003)
  11. Re: WebCAT has the devil in it! ( Alex McCombie 2003)
  12. Re: WebCAT has the devil in it! ( John Peacock 2003)
  13. Re: WebCAT has the devil in it! ( Alex McCombie 2003)
  14. Re: WebCAT has the devil in it! ( John Peacock 2003)
  15. WebCAT has the devil in it! ( Alex McCombie 2003)
>Sounds great Scott, but one hanging question... If I do turn it off, >which I >may not, what ultimately am I losing in functionality? Well, the engine will revert to pre 4.5.1 behavior. Meaning that if the server or WebDNA crashes during a database write, you will lose those database records that were not yet written to disk. >PS... I would wager that any developer in my position would have >probably >rather WebCAT stop duplicating the files after a certain number(perhaps >a >pref setting). The uncontrollable nature of this scared me...jmho That was one of the improvements to the 5.0 version of the 'Safe Write' code. It will roll the index of the tmp filename after 10. So, there will never be more than 10 tmp files for any given database. Preferably, of course, we would never want to see any tmp db files left on disk. Having re-visited the code today, I can see where we can improve on the existing algorithm to 'recover' from a dangling '...-oRiGiNaL-' file. Yet another 'to-do' for the 5.2 release. -----Original Message----- From: Alex McCombie [mailto:alex@newworldmedia.com] Sent: Thursday, November 13, 2003 10:45 AM To: WebDNA Talk Subject: Re: WebCAT has the devil in it! On 11/13/03 1:34 PM, "Scott Anderson" wrote: >> 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. Bingo, there was a file created by WebCAT in there with the original in the name... Causing the continuing failure. > 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. Interestingly enough, the true original file (something.db) had all the updated data as the largest increment. Which would be slightly different than you mention but still worked for us. > 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. This assumes that the 'crash' had anything to do with webcat, which I do not believe it did. Certainly untimely and for the record the one and only occurrence of this I have ever seen! > Also, it is always a good idea to perform frequent backups of your db files. We do, and thankfully I coded those backups by exact name and not by directory. Imagine that ..lol > We will continue to improve the 'Safe Write' code for future releases, as it > is a beneficial feature. Sounds great Scott, but one hanging question... If I do turn it off, which I may not, what ultimately am I losing in functionality? PS... I would wager that any developer in my position would have probably rather WebCAT stop duplicating the files after a certain number(perhaps a pref setting). The uncontrollable nature of this scared me...jmho 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:

[WebDNA] Google like search (2016) SetHeader not Working (2006) WebCatalog for guestbook ? (1997) Problems getting parameters passed into email. (1997) Email Formatting (1998) Major bug report on rootbeer (1997) Re:WebCatalog f2 Installation (1997) [OT] Test - THE ANSWER (2003) grouped fields? (1999) WebCat2b14MacPlugIn - [include] doesn't hide the search string (1997) [isfile] ? (1997) textarea data entry and display (2000) Bit off subject -- Faxing orders (1997) Dumb Question about Docs (1997) [shell] (2002) Protecting webdelivery (1997) search results through frames (2000) WebCat editing, SiteGuard WAS:SiteAssociative lookup style? (1997) Protecting databases (1999) [OT] Who's got a cool link (2002)