headers
Ryan Barrett | 6 Jul 01:28
Picon

FileSnipStorage.parseSnip(...:298) stacktrace, but no 0-length metadata.properties files

hi all! something got corrupted in my snipsnap last night, and now it's
giving me the infamous FileSnipStorage.parseSnip(...:298) stacktrace when i
try to start it.

i see this once every week or two because of zeroed-out metadata.properties
files. i restore them from backups, and snipsnap happily starts up again.
this time, though, there are no zeroed-out metadata.properties files - or
content.txt files, for that matter.

full stacktrace below; i'm running 1.0b1-uttoxeter, file snip storage, red
hat 9, sun's 1.4.2 jvm.

it's discussed at these links, but all of the discussions point to
zeroed-out metadata.properties and content.txt files. does anyone know
anything else that could cause this problem?

http://www.snipsnap.de/comments/help-me-please
http://snipsnap.org/comments/snipsnap-help#comment-snipsnap-help-85
http://nopaper.net/2004/06/15/downtime-is-my-favorite-time.html

thanks in advance...

==

java.lang.NullPointerException
         at org.snipsnap.snip.storage.FileSnipStorage.parseSnip(FileSnipStorage.java:298)
         at org.snipsnap.snip.storage.FileSnipStorage.traverseFileStore(FileSnipStorage.java:332)
         at org.snipsnap.snip.storage.FileSnipStorage.traverseFileStore(FileSnipStorage.java:341)
         at org.snipsnap.snip.storage.FileSnipStorage.storageAll(FileSnipStorage.java:325)
         at org.snipsnap.snip.storage.MemorySnipStorage.<init>(MemorySnipStorage.java:87)
(Continue reading)

Permalink | Reply |
headers
Ryan Barrett | 6 Jul 22:36
Picon

FIXED: FileSnipStorage.parseSnip(...:298) stacktrace, but no 0-length metadata.properties files

after lots of head-scratching, i figured out the problem. one of my
metadata.properties files was *incomplete*, not zeroed out. it had the
header comment and the snipLinks line, but the other lines were missing.

metadata.properties files routinely get very big; some of mine are over
10MB. so, i can understand how one could only be partially written to disk
if snipsnap died in the middle of flushing it to disk. i'm only surprised it
didn't happen sooner.

i'll put up a page that summarizes the known causes of this stacktrace,
including this one, as well as the shell scripts i use to find and fix the
metadata files.

thanks to everyone who offered help and condolences!

On Wed, 5 Jul 2006, Ryan Barrett wrote:

> hi all! something got corrupted in my snipsnap last night, and now it's
> giving me the infamous FileSnipStorage.parseSnip(...:298) stacktrace when i
> try to start it.
>
> i see this once every week or two because of zeroed-out metadata.properties
> files. i restore them from backups, and snipsnap happily starts up again.
> this time, though, there are no zeroed-out metadata.properties files - or
> content.txt files, for that matter.
>
> full stacktrace below; i'm running 1.0b1-uttoxeter, file snip storage, red
> hat 9, sun's 1.4.2 jvm.
>
> it's discussed at these links, but all of the discussions point to
(Continue reading)

Permalink | Reply |
headers
Ryan Barrett | 7 Jul 05:34
Picon

Re: FIXED: FileSnipStorage.parseSnip(...:298) stacktrace, but no 0-length metadata.properties files

On Thu, 6 Jul 2006, Ryan Barrett wrote:

> i'll put up a page that summarizes the known causes of this stacktrace,
> including this one, as well as the shell scripts i use to find and fix the
> metadata files.

i've posted this:

http://snarfed.org/space/SnipSnap+crash+with+FileSnipStorage+and+bad+metadata.properties

moving forward, i'm inclined to write a patch to add some logging, so when
SnipSnap hits a metadata file it can't parse, you at least know which file
tripped it up. even better, it could attempt to repair itself by archiving
the bad file and restoring it from backup. thoughts?

if the backup is corrupt too, it could restart the metadata from scratch. it
wouldn't have the snip's attachments or metadata, so the snip wouldn't be
entirely functional...but the site would still be up. this isn't as simple,
though, since it'd be difficult to merge the new backlinks, etc, into the
old metadata after it's repaired.

-Ryan

--
http://snarfed.org/
Permalink | Reply |

Gmane