logging - MarkLogic - XDMP-NEWSTAMP 异常

Question

我们正在使用 MarkLogic-8 (三个节点 - 每个节点有两个森林)并且一直面对 XDMP-NEWSTAMP 异常频繁。
我们有 default merge policy并且不要使用任何 point in time查询。
但我们确实使用 xdmp:eval和 xdmp:invoke-fuction (在代码中大量使用)避免 locks在 update transactions 中仅被读取的文档(查询模式) .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

Every forest has a notion of a "fast query timestamp", also sometimes referred to as a "nonblocking timestamp". This is the maximum timestamp at which a query can run without waiting for the forest's timestamp to advance; it indicates the most current time at which the forest has complete state to answer a query. There are several reasons for forests to have this timestamp.

The first has to do with transaction commits, during which the forest places a finger on the commit timestamp for the duration of the commit. The point of this is to ensure that queries perceive committed transactions to be atomic. There can be multiple (even many) transactions with a finger on various timestamps at any given point in time.

This warning will help flag any problems with overly long transactions that can hold up queries. The warning helps flag the lag issue earlier, rather than later.