我正在使用 Siddhi [1] 的 Java 库，并且注意到检索和处理由 Siddhi 运行时生成的事件有相当大的延迟。尽管两个Siddhi事件可能具有时间差为X秒的Siddhi事件时间戳，但是在接收Siddhi事件时生成的相关应用级时间戳是在同一秒内生成的。为了说明这一点(所有时间戳都被修剪为秒):
- Siddhi 事件 1 时间戳:
1571059612 Siddhi 事件 2 时间戳:
1571059616接收 Siddhi 事件 1 时的应用程序时间戳:
1571059617- 接收 Siddhi 事件 2 时的应用时间戳:
1571059617
应用程序时间戳是正确的 - 即 Siddhi 事件传播被延迟。此外，已通过将应用程序时间戳设置为等于 Siddhi 事件时间戳来验证 Siddhi 事件时间戳。但是，由于 Siddhi 事件是在一个时间窗口内创建的，因此我无法考虑使用真实但延迟的 Siddhi 时间戳的选项。此行为是意外的，因为事件预计会在生成时被接收。
有问题的应用程序摘录由以下代码示例提取:
running_siddhi_thread.getSiddhi_app_runtime().addCallback(output_stream_name, new StreamCallback() {
@Override
public void receive(Event[] events) {
for (Event event : events) {
//retrieval and processing of event
do_processing_based_on_event(event) //this includes the Application timestamp generation
create_new_message_with_timestamp(params)
}
}
});
触发的 Siddhi 查询的形式为:
from inputstream #window.timeBatch(5 sec )
select avg(attr1) as avg_attr1, avg(attr2) as avg_attr2
having avg_attr1>1000 and avg_attr2>800
insert into output_stream_name;
我验证了在 Siddhi 中，事件在发生的那一秒即显示在日志中，即时间戳 1571059612 和 1571059616。时间戳为 1571059612 的事件表示自 1571059607 以来检查了 attr1 和 attr2 值，并且它们的平均值发现超出了 1571059612 的限制。问题在于，对于 Java 库，事件的发布有延迟。
是否需要设置一个特殊选项(例如在线程级别)以确保来自 Siddhi 的事件以更短的延迟传播？
[1] https://siddhi.io/en/v5.1/docs/siddhi-as-a-java-library/
最佳答案
Siddhi 在管道期间保留原始事件的时间戳。您获得的时间戳将来自事件发送到 siddhi 管道的时间
关于java - 使用 WSO Siddhi Java 库进行事件检索时出现过度延迟，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/58392629/