Archiver auto-imported documents fail conversion (GenWWW)??? :-\

Question

So I'm experiencing an unusual problem where the docs that are sync'd from another server go through "conversion" upon auto-archiver-import even though there isn't an outgoing provider to an IBR, all file formats are set to Passthru, and I have the "Copy Web Content" option turned on for the archive. To make matters worse, the conversion sometimes fails, which prevents documents from becoming released. There's no pattern as to when or why the files (xml, pdf, jpg, bmp, doc, hcsp, etc) fail conversion either; and not every imported doc fails.
Some other symptoms:
- The content info page shows "Indexing failed." under "Conversion Error" (is this as simple as a corrupted collection? we still use Verity)
- The conversion status is "Failed"
- The revision status is "GenWWW"
- Once I resubmit it (via Repository Manager or doc info page), the conversion succeeds about 99% of the time
- The IBR conversion succeeds on the source server
These sync'd docs shouldn't even be going through conversion in the first place...
Any thoughts??

Answer 1

Frank Abela wrote:Not likely an indexer issue. The GENWWW state is valid while the document is going through conversion. Once conversion is complete it is set to Done. Only then is it ready for indexing. You can prove this by switching off the indexer auto update cycle and switching on systemdatabase and services verbose tracing. You can actually trace the inserts of GENWWW and DONE into the database even though no indexing is possible at that point.With all due respect, I'm not trying to sound like a jerk. But it's likely an indexer issue - here's why:
I'd agree with you if we were simply talking about normal checkins and updates with an attached IBR instance. We aren't talking about the normal here.
- You have documents being ingested via archiver, with a webviewable document already present in the archive, so IBR shouldn't be the issue - you aren't "creating" a webviewable in this case. Unless "AlwaysResubmit=1" is being set somewhere, these documents have no need to go back to IBR - plus according to the OP (Andrew, I think), IBR is not even enabled in the target environment.
- stellentpmp wroteOnce I resubmit it (via Repository Manager or doc info page), the conversion succeeds about 99% of the timeIf IBR is broke, doesn't it seem like 99% is a pretty high success rate for a broken system for simply clicking a button - and no IBR is present to do the conversions to boot? (How can IBR be broke in an environment where IBR isn't even present?)
- As I mentioned in my previous post, I saw ALMOST the EXACT same behavior less than a month ago when archiving documents into a system (documents archived had webviewables with no real need for reconversion). The archive imported, but only about 20% of the content indexed. Resubmitting individual items failed sporadically. Forcing collection rebuilds to index everything would start, but stop for no reason. When I looked at the system console output, there would always be a message ("text export timed out") on different items (never the same ones) and once this error was thrown, the entire indexing process stopped cold with no recovery. Increasing the timeout allowed the text export process to finish, and the collection was successfully rebuilt.
Now the reason for the need to increase the timeout is unknown, but that may be due to file system access and the speed of the access to the file system where the text export file is being written, which is probably the "~temp" directory under "vault".
Frank Abela wrote: If you're using pass through, then this is a file copy which is failing for some reason.Again, this would be a function of file system access, which fits with the text export failure scenario mentioned above. It would interesting to see if the behavior is worse at a given time of the day, or is it truly random.