Onerror指令不适用于Solr数据导入处理程序/ PDFBox

时间:2018-08-21 19:46:14

标签: solr pdfbox dataimporthandler

我们正尝试针对一个MySQL表索引约10,000个PDF。我们正在使用Solr 5.2.1,Tika 1.7和PDFBox 1.8.8。数据导入处理程序不断给出各种错误,从而终止了整个过程。大多数错误与内容不可读或找不到PDF文件有关。我理解这一点,并希望该过程继续进行或跳过问题文件。但是,无论我如何设置onerror指令,它似乎都不起作用。我们已经使用相同的方法索引了较小的PDF集,这没有问题。但是,这家大商店的连续错误使我们无法自拔!我将不胜感激。

这是data-config.xml中的实体:

<entity name="proceedings" dataSource="proceedings_db" onerror="skip"
    query="SELECT productID, title, fileName, buildDate
    FROM products 
    WHERE status = '1' 
">
    <field column="productID" name="uid" />
    <field column="title" name="paper_title" />
    <field column="fileName" name="filename" />
    <field column="buildDate" name="builddate" />

    <entity name="file" dataSource="proceedings_files" processor="TikaEntityProcessor" url="${proceedings.filename}" format="text" onerror="skip"> 
    </entity>
</entity>

我尝试为外部实体,内部实体以及两者设置onerror(如上所述)。我尝试跳过并继续所有这些组合。似乎没有影响。

这是我收到的一个错误示例:

ERROR FlateFilter FlateFilter: stop reading corrupt stream due to a DataFormatException

java.io.EOFException
    at org.apache.fontbox.ttf.MemoryTTFDataStream.readSignedShort(MemoryTTFDataStream.java:139)
    at org.apache.fontbox.ttf.HorizontalMetricsTable.initData(HorizontalMetricsTable.java:62)
    at org.apache.fontbox.ttf.TrueTypeFont.initializeTable(TrueTypeFont.java:280)
    at org.apache.fontbox.ttf.AbstractTTFParser.parseTables(AbstractTTFParser.java:128)
    at org.apache.fontbox.ttf.TTFParser.parseTables(TTFParser.java:80)
    at org.apache.fontbox.ttf.AbstractTTFParser.parseTTF(AbstractTTFParser.java:109)
    at org.apache.fontbox.ttf.AbstractTTFParser.parseTTF(AbstractTTFParser.java:84)
    at org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.getTTFFont(PDTrueTypeFont.java:632)
    at org.apache.pdfbox.pdmodel.font.PDTrueTypeFont.getFontWidth(PDTrueTypeFont.java:673)
    at org.apache.pdfbox.pdmodel.font.PDSimpleFont.getFontWidth(PDSimpleFont.java:231)
    at org.apache.pdfbox.util.PDFStreamEngine.processEncodedText(PDFStreamEngine.java:411)
    at org.apache.pdfbox.util.operator.ShowTextGlyph.process(ShowTextGlyph.java:62)
    at org.apache.pdfbox.util.PDFStreamEngine.processOperator(PDFStreamEngine.java:557)
    at org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:268)
    at org.apache.pdfbox.util.PDFStreamEngine.processSubStream(PDFStreamEngine.java:235)
    at org.apache.pdfbox.util.PDFStreamEngine.processStream(PDFStreamEngine.java:215)
    at org.apache.pdfbox.util.PDFTextStripper.processPage(PDFTextStripper.java:460)
    at org.apache.pdfbox.util.PDFTextStripper.processPages(PDFTextStripper.java:385)
    at org.apache.pdfbox.util.PDFTextStripper.writeText(PDFTextStripper.java:344)
    at org.apache.tika.parser.pdf.PDF2XHTML.process(PDF2XHTML.java:134)
    at org.apache.tika.parser.pdf.PDFParser.parse(PDFParser.java:146)
    at org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:256)
    at org.apache.tika.parser.CompositeParser.parse(CompositeParser.java:256)
    at org.apache.tika.parser.AutoDetectParser.parse(AutoDetectParser.java:120)
    at org.apache.solr.handler.dataimport.TikaEntityProcessor.nextRow(TikaEntityProcessor.java:162)
    at org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:243)
    at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:475)
    at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:514)
    at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:414)
    at org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:329)
    at org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:232)
    at org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:416)
    at org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:480)
    at org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:461)

请注意,这些不是唯一的错误,但它们具有代表性。我宁愿不要搜寻并破坏每个有问题的PDF,但是如果那样做的话就可以了。但是,与上面的错误一样,即使我扩大了日志输出设置,我也没有得到文件名。有时我会这么做,并且我会破坏该文件,但是不会每次都发生。

我想我似乎不明白onerror设置的作用是什么,这似乎是唯一的选择!再说一次,对于我做错了什么,我将是最感激的。

谢谢!

1 个答案:

答案 0 :(得分:0)

在真实的产品环境中使用DIH为大量PDF文件编制索引不是一个好主意:

  1. 无论如何,都将无法提取某些pdf。如果您需要通过任何方式提取内容,则应捕获错误的内容并使用第二个提取库(与PDFBox不同),因为没有两个库会因同一组文件而失败。
  2. 与上面相同,一些OOM会在过程继续时根据需要尝试其他库。
  3. 更糟的是,某些PDF会在提取时挂起。您需要设置一些基础结构以找到这些情况,并终止提取过程,以便继续进行下一个。如果您愿意,可以在第二个库中找到同上。

最重要的是,您应该通过使用一些ETL工具来使用其他设置,或者只是编写一些自定义代码来进行提取,然后再考虑到上述建议,将其索引到Solr中。