小编lmk*_*lmk的帖子

我想知道 Java Collection接口没有使用类似于Stream接口上的谓词allMatch()的直接, anyMatch()& noneMatch()API是否有原因。

在我看来，除了不需要使用 Streams 来执行这些操作之外，将这些放在 Collection 接口上（也）将为我们带来与其他 Collection 接口方法（甚至）contains()相同containsAll的优势。removeIf

我本来打算使用一个薄包装实用程序来实现此目的，但想听听上述人士的意见……这是否只是 OpenJDK 社区考虑到工作负载的优先事项，或者是否涉及其他设计考虑因素。

谢谢

正如本文档建议的那样，可以通过设置执行 SqlQuery 时设置超时，https://ignite.apache.org/releases/2.4.0/javadoc/org/apache/ignite/cache/query/SqlQuery.html#setTimeout- int-java.util.concurrent.TimeUnit-

QueryCancelledException 的文档还提到，如果查询在执行时被取消或超时，则会引发已检查的异常，https: //ignite.apache.org/releases/2.4.0/javadoc/org/apache/ignite/cache/query /QueryCancelledException.html

这里提到了同样的方法作为取消/超时长时间运行的查询的方法， https://apacheignite-sql.readme.io/v2.4/docs/query-cancellation

但奇怪的是所有 IgniteCache.query(..) 方法的 java 文档，https://ignite.apache.org/releases/2.4.0/javadoc/org/apache/ignite/IgniteCache.html#query-org。 apache.ignite.cache.query.Query-不声明此已检查异常，或者就此而言，抛出任何已检查异常（与 QueryCursor.getAll() 方法相同），导致对查询超时处理的位置和方式进行编码的混乱。

我编写了下面的代码，但无法使查询超时以快速测试我的代码路径的该部分并查看其是否正确。我希望在 IgniteCache.query(..) 方法和 QueryCursor.getAll() 及其相关方法中都会抛出异常。

显然，SqlQuery.setTimeout(int timeout, TimeUnit timeUnit) 的最小超时粒度是 TimeUnit.MILLISECONDS，我在初始测试期间意识到，这使得强制测试超时变得更加困难。

下面的代码看起来正确吗？（我想避免游标方法并依赖在 try-with-resources 中调用的 IgniteCache.query(..) 来检测超时）。这行得通吗？

@Scheduled(fixedDelayString = "${checkInterval}", initialDelayString = "${checkDelay}")
private final void monitorHealth() {
    if(!isReady) {
        return;
    }
    try (QueryCursor<Entry<Integer, FabricInfo>> cursor = fabricInfoCache.query(SQL_QUERY)) {
        cursor.iterator();
        // Reset the query time out counter..
        if(retryCount != 0) {
            retryCount = 0;
            LOGGER.warn("Client health check query executed without …