MLCP 内容转换和触发器可以在文档摄取期间一起使用吗？
Could MLCP Content Transformation and Triggers be used together during document ingestion?
据我了解，MLCP 转换和触发器均可用于修改摄取的文档。不同之处在于内容转换在摄取期间对内存中的文档对象进行操作，而触发器可以在创建文档后触发。
所以在我看来，我没有理由不能同时使用它们。我的用例是我需要在将文档摄取到数据库后更新文档的某些节点。我使用触发器的原因是因为 运行 使用 in-mem-update 模块的 MLCP 转换中的相同逻辑总是导致摄取失败，大概是由于我尝试更新的文件大小和节点数量很大。
2018-08-22 23:02:24 ERROR TransformWriter:546 - Exception:Error parsing HTTP headers: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
到目前为止，我还不能将内容转换和触发器结合起来。当我在 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>）和属性（class 和 style) 我不需要。在尝试删除它们时，我探索了两种不同的方法：
- 第一种方法是使用
in-mem-update 模块从上述 content.xqy 脚本中的内存文档表示中删除不需要的节点，作为内容转换流程的一部分。问题是这个过程可能会很慢，正如@grtjn 指出的那样，我必须限制并行化以避免超时。
- 第二种方法是使用 post-commit 触发器函数在文档被引入数据库后使用
xdmp:node-delete 修改文档。但是，当触发条件设置为 document-content("create") 时，触发器不会触发。如果我将条件更改为 document-content("modify")，它确实会触发，但由于某种原因，我无法使用类似于此 SO 问题 (MarkLogic 9 sjs trigger not able to acces post-commit() document data) 的 fn:document($trgr:uri) 访问文档。
MLCP 转换和触发器独立运行。这些转换中没有任何东西可以阻止触发器本身工作。
触发器是由事件触发的。我通常同时使用创建触发器和修改触发器来涵盖我第二次导入相同文件的情况（例如出于测试目的）。
触发器也有作用域。它们被配置为查找目录或集合。确保您的 MLCP 配置与触发器范围匹配，并且您的转换不会影响 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！
据我了解，MLCP 转换和触发器均可用于修改摄取的文档。不同之处在于内容转换在摄取期间对内存中的文档对象进行操作，而触发器可以在创建文档后触发。
所以在我看来，我没有理由不能同时使用它们。我的用例是我需要在将文档摄取到数据库后更新文档的某些节点。我使用触发器的原因是因为 运行 使用 in-mem-update 模块的 MLCP 转换中的相同逻辑总是导致摄取失败，大概是由于我尝试更新的文件大小和节点数量很大。
2018-08-22 23:02:24 ERROR TransformWriter:546 - Exception:Error parsing HTTP headers: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
到目前为止，我还不能将内容转换和触发器结合起来。当我在 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>）和属性（class 和 style) 我不需要。在尝试删除它们时，我探索了两种不同的方法：
- 第一种方法是使用
in-mem-update模块从上述content.xqy脚本中的内存文档表示中删除不需要的节点，作为内容转换流程的一部分。问题是这个过程可能会很慢，正如@grtjn 指出的那样，我必须限制并行化以避免超时。 - 第二种方法是使用 post-commit 触发器函数在文档被引入数据库后使用
xdmp:node-delete修改文档。但是，当触发条件设置为document-content("create")时，触发器不会触发。如果我将条件更改为document-content("modify")，它确实会触发，但由于某种原因，我无法使用类似于此 SO 问题 (MarkLogic 9 sjs trigger not able to acces post-commit() document data) 的fn:document($trgr:uri)访问文档。
MLCP 转换和触发器独立运行。这些转换中没有任何东西可以阻止触发器本身工作。
触发器是由事件触发的。我通常同时使用创建触发器和修改触发器来涵盖我第二次导入相同文件的情况（例如出于测试目的）。
触发器也有作用域。它们被配置为查找目录或集合。确保您的 MLCP 配置与触发器范围匹配，并且您的转换不会影响 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！