0

据我了解，MLCP 转换和触发器都可用于修改摄取的文档。不同之处在于内容转换在摄取期间对内存中的文档对象进行操作，而触发器可以在创建文档后触发。

所以在我看来，我没有理由不能同时使用它们。我的用例是在将文档提取到数据库后，我需要更新文档的某些节点。我使用触发器的原因是因为在使用in-mem-update模块的 MLCP 转换中运行相同的逻辑总是导致摄取失败，大概是由于文件大小过大和我尝试更新的节点数量过多。

2018-08-22 23:02:24 错误 TransformWriter:546 - 异常：解析 HTTP 标头时出错：连接尝试失败，因为连接方在一段时间后没有正确响应，或者建立连接失败，因为连接的主机无法连接回应

到目前为止，我还不能将内容转换和触发器结合起来。当我在 MLCP 摄取期间启用转换时，触发器未触发。当我禁用转换时，触发器没有问题。

我不能同时使用它们有什么内在原因吗？还是与我的配置有关的问题？谢谢！

编辑：

我想根据@ElijahBernstein-Cooper、@MadsHansen 和@grtjn（谢谢！）的建议，提供一些澄清和报告结果的背景。我正在使用 MarkLogic 数据中心框架将 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/内容/内容.xqy

虽然xdmp:pdf-convert似乎比 更好地保留了 PDF 结构xdmp:document-filter，但它还包括一些我不需要的样式节点 ( <link>and <style>) 和属性 ( classand )。style在尝试删除它们时，我探索了两种不同的方法：

  1. 第一种方法是使用该in-mem-update模块从上述content.xqy脚本中的内存文档表示中删除不需要的节点，作为内容转换流程的一部分。问题是这个过程可能很慢，正如@grtjn 指出的那样，我必须限制并行化以避免超时。
  2. 第二种方法是使用提交后触发器功能在文档xdmp:node-delete被提取到数据库后使用它们来修改它们。但是，当触发条件设置为 时，触发器不会触发document-content("create")。如果我将条件更改为，它确实会触发document-content("modify")，但由于某种原因，我无法使用fn:document($trgr:uri)类似于此 SO 问题的方式访问文档（MarkLogic 9 sjs 触发器无法访问 post-commit() 文档数据）。
4

1 回答 1

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，内容处理框架。它是处理内容的非常健壮的实现，旨在在服务器重新启动后继续存在。

！

于 2018-08-24T07:24:35.147 回答