据我了解,MLCP转换和触发器均可用于修改提取的文档。区别在于,内容转换在摄取期间对内存中的文档对象进行操作,而触发器可以在创建文档后触发。
所以在我看来,没有理由我不能将两者同时使用。我的用例是,在将文档的某些节点提取到数据库之后,我需要对其进行更新。我使用触发器的原因是,使用in-mem-update
模块在MLCP转换中运行相同的逻辑总是会导致提取失败,这大概是由于文件大小过大以及我尝试更新的节点数量众多。
2018-08-22 23:02:24错误TransformWriter:546-异常:解析HTTP标头时出错:连接尝试失败,因为一段时间后连接方未正确响应,或者由于连接的主机而建立的连接失败没有回应
到目前为止,我还不能结合使用内容转换和触发器。当我在MLCP提取期间启用转换时,未触发该触发器。当我禁用转换时,触发器可以正常工作。
我不能同时使用它们吗?还是与我的配置有关的问题?谢谢!
编辑:
我想根据@ ElijahBernstein-Cooper,@ MadsHansen和@grtjn的建议为澄清和报告结果提供一些背景信息(谢谢!)。我正在使用MarkLogic Data Hub Framework将PDF文件(有些文件很大)作为二进制文件提取,并将文本提取为XML。除了使用xdmp:pdf-convert
而不是xdmp:document-filter
:https://github.com/marklogic/marklogic-data-hub/blob/master/examples/load-binaries/plugins/entities/Guides/input/LoadAsXml/content/content.xqy
尽管xdmp:pdf-convert
似乎比xdmp:document-filter
保留了更好的PDF结构,但它还包括一些样式节点(<link>
和<style>
)和属性({{1} }和class
)。在尝试删除它们时,我探索了两种不同的方法:
style
模块从上述in-mem-update
脚本中的内存文档表示中删除不需要的节点,作为内容转换流程的一部分。问题在于该过程可能会非常缓慢,正如@grtjn指出的那样,我必须限制并行化以避免超时。 content.xqy
来修改文档。但是,当触发条件设置为xdmp:node-delete
时,触发器不会触发。如果我将条件更改为document-content("create")
,它确实会触发,但是由于某种原因,我无法使用document-content("modify")
来访问文档,类似于该SO问题(MarkLogic 9 sjs trigger not able to acces post-commit() document data)。答案 0 :(得分:2)
MLCP转换和触发器独立运行。这些转换中没有什么可以阻止触发器本身的工作。
触发器是事件触发的触发器。通常,我会同时使用创建和修改触发器来涵盖第二次导入相同文件(例如出于测试目的)的情况。
触发器也有作用域。它们被配置为查找目录或集合。确保您的MLCP配置与Trigger范围匹配,并且您的Transform不会以这种方式不再与目录范围匹配的方式影响URI。
更仔细地查看错误消息,我想这是由于超时引起的。超时可能同时发生在服务器端(默认为10分钟)和客户端(可能取决于客户端设置,但可能更小)。该消息基本上说服务器响应时间太长,所以我要说您正面临客户端超时。
超时可能是由于时间限制太小造成的。您可以尝试增加服务器端(xdmp:set-request-time-limit()
)和客户端(不确定如何在Java中执行此操作)的超时设置。
不过,更常见的是,您只是试图同时做太多事情。 MLCP打开事务,并尝试在该事务(即transaction_size
)内执行许多批处理。每一批包含许多batch_size
大小的文档。默认情况下,MLCP会尝试每笔交易处理10 x 100 = 1000个文档。
默认情况下,它也运行10个线程,因此通常会同时打开10个事务,并尝试运行10个线程以并行处理1000个文档。用简单的插入物就可以了。在转换或预提交触发器中进行更繁重的处理时,这可能成为瓶颈,尤其是当线程开始争用内存和cpu等服务器资源时。
诸如xdmp:pdf-convert
之类的功能通常会相当慢。它取决于初学者的外部插件,但还可以想象它必须处理200页的PDF。二进制文件可能很大。您将需要降低处理速度。如果使用-transaction_size 1 -batch_size 1 -thread_count 1
使转换工作正常,则说明您确实面临超时,并且可能正在泛滥服务器。从那里可以看到增加一些数字,但是二进制大小可能是不可预测的,因此要保守一点。
也许值得一提的是异步进行繁重的处理,例如使用CPF Content Processing Framework。这是用于处理内容的非常强大的实现,旨在在服务器重新启动后幸免。
HTH!