MarkLogic - XDMP-NEWSTAMP 异常

Question

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

MarkLogic文档中也没有关于XDMP-NEWSTAMP的非常全面的信息，除了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

每个森林都有一个“快速查询时间戳”的概念，有时也称为“非阻塞时间戳”。 这是查询可以在不等待森林时间戳推进的情况下运行的最大时间戳； 它指示森林已完成 state 以回答查询的最新时间。 森林有这个时间戳有几个原因。

第一个与事务提交有关，在此期间，森林在提交期间将手指放在提交时间戳上。 这样做的目的是确保查询将提交的事务视为原子的。 在任何给定的时间点，都可能有多个（甚至很多）事务与各种时间戳有关。

此警告将有助于标记可能阻碍查询的过长事务的任何问题。 该警告有助于更早地而不是更晚地标记滞后问题。

Answer 2

将 App 服务器配置distribute timestamps更改为strict （之前设置为fast ），现在XDMP-NEWSTAMP的出现显着减少。 这种变化是否会产生任何可能的负面影响？ 增加的network load是我所期待的。 还有其他的吗？