MarkLogic - XDMP-NEWSTAMP异常

Question

我们使用的是XDMP-NEWSTAMP (有三个节点--每个节点有两个林)，并且经常面临MarkLogic-8异常。我们有default merge policy，不使用任何point in time查询。但是我们确实使用了xdmp:eval和xdmp:invoke-fuction(在代码中经常使用)来避免只在update transactions中读取文档(查询模式)上的locks。

在XDMP-NEWSTAMP文档中也没有关于MarkLogic的非常全面的信息，除了XDMP-NEWSTAMP和App developer guide's point in time查询部分中提到的信息；这两个方面都做过，但都没有帮助。

请帮助我理解这个异常(如果任何文档有与此相关的详细信息，请与我分享)。下面是一个供参考的日志片段：

2020-07-16 03:07:31.712 Warning: Forest XXX-YY-003 fast query timestamp (15948687770144645) lags commit timestamp (15948688205890165) by 43574 ms
2020-07-16 03:08:03.583 Warning: Forest XXX-YY-003 fast query timestamp (15948687770144645) lags commit timestamp (15948688803306468) by 103316 ms
2020-07-16 03:08:03.632 Info: Merging 2 MB from G:\Forests\xxxx03\000048af to G:\Forests\xxxx03\000048b1, timestamp=15948682803306468
2020-07-16 03:08:03.933 Debug: OnDiskStand G:\Forests\xxxx03\000048b1, disk=3MB, memory=1MB
2020-07-16 03:08:03.934 Info: Merged 3 MB at 10 MB/sec to G:\Forests\xxxx03\000048b1
2020-07-16 03:08:03.960 Debug: Forest xxxx03 setting minQueryTimestamp to 15948682803306468 due to merge
2020-07-16 03:08:04.936 Debug: ~OnDiskStand G:\Forests\xxxx03\000048af
2020-07-16 03:08:07.166 Info: Deleted 2 MB at 703 MB/sec G:\Forests\xxxx03\000048af
2020-07-16 03:08:17.617 Debug: Forest XXX-YY-003 participant 1232761274262892690 not found in participantBumpMinCommitTimestamp()

2020-07-16 03:22:23.750 Info: XXX-WorkApi: Status 500: XDMP-NEWSTAMP: Timestamp too new for forest XXX-YY-003 (15948695621461959)
2020-07-16 03:22:23.750 Info: XXX-WorkApi: Status 500: XDMP-NEWSTAMP: Timestamp too new for forest XXX-YY-003 (15948695621461959)

Answer 1

这可能是由于一些长期运行的查询。

在XDMP-NEWSTAMP之前，该林中记录了“快速查询时间戳”消息：https://help.marklogic.com/knowledgebase/article/View/437/0/warning-messages-for-lagging-operations。

每个森林都有“快速查询时间戳”的概念，有时也称为“非阻塞时间戳”。这是查询可以运行的最大时间戳，而无需等待林的时间戳提前；它指示森林有完整状态回答查询的最新时间。森林之所以有这样的时间戳，有几个原因。第一个问题与事务提交有关，在此期间，林中将手指指向提交期间的提交时间戳。这样做的目的是确保查询认为提交的事务是原子的。在任何给定的时间点，都可以有多个(甚至很多)事务，用手指在不同的时间戳上进行处理。此警告将有助于标记过长的事务可能会阻塞查询的任何问题。该警告有助于更早而不是更晚地标记滞后问题。

Answer 2

将App配置distribute timestamps更改为strict (之前设置为fast)，现在XDMP-NEWSTAMP的出现明显减少。是否会有任何可能的负面影响，由于这一变化；增加的network load是一个，我期待。还有其他的吗？