小编xab*_*bhi的帖子

Spring Data生成的存储库实现是什么时候？在编译时还是运行时？我可以看到Spring Data生成的实现存储库实现吗？

由于我的 Kafka 制作人的各种原因，我经常收到超时异常。我目前正在使用生产者配置的所有默认值。

我见过以下超时异常：

org.apache.kafka.common.errors.TimeoutException：60000 毫秒后无法更新元数据。

org.apache.kafka.common.errors.TimeoutException：主题 1-​​0 的 1 条记录到期：自上次追加以来已经过去了 30001 毫秒

我有以下问题：

1. 这些超时异常的一般原因是什么？

   1. 临时网络问题
   2. 服务器问题？如果是，那么什么样的服务器问题？

2. 处理超时异常的一般准则是什么？

   1. 设置“重试”配置以便 Kafka API 进行重试？
   2. 增加 'request.timeout.ms' 或 'max.block.ms' ？
   3. 捕获异常并让应用程序层重试发送消息，但这对于异步发送似乎很难，因为消息将被乱序发送？

3. 超时异常是可重试的异常吗？重试它们是否安全？

我正在使用 Kafka v2.1.0 和 Java 11。

提前致谢。

我正在使用 spring 数据 mongodb 并希望在我的应用程序中使用手动引用并根据需要解决它们。我阅读了 spring 数据 mongodb 文档，但找不到 spring 是否支持手动引用？它支持 DBRefs 并急切地解决它们，这是我不想要的。有谁知道如何使用带有弹簧数据的手动引用或者它是否完全支持？我问这个是因为 mongodb docs 推荐这个并且它适合大多数用例。

从https://issues.apache.org/jira/browse/KAFKA-7925交叉发布,因为还没有人回复.

问题: 即使没有任何客户端连接到任何代理,我看到我们的kafka集群中的所有代理都持续100%使用cpu.当发生这种情况时,没有客户端能够连接到kafka经纪人并且他们保持超时.我一直在服务器日志中看到以下异常:

它现在正在成为部署的阻碍者.

例外

java.net.SocketTimeoutException: Failed to connect within 30000 ms
at kafka.server.ReplicaFetcherBlockingSend.sendRequest(ReplicaFetcherBlockingSend.scala:93)
at kafka.server.ReplicaFetcherThread.fetchFromLeader(ReplicaFetcherThread.scala:190)
at kafka.server.AbstractFetcherThread.kafka$server$AbstractFetcherThread$$processFetchRequest(AbstractFetcherThread.scala:241)
at kafka.server.AbstractFetcherThread$$anonfun$maybeFetch$1.apply(AbstractFetcherThread.scala:130)
at kafka.server.AbstractFetcherThread$$anonfun$maybeFetch$1.apply(AbstractFetcherThread.scala:129)
at scala.Option.foreach(Option.scala:257)
at kafka.server.AbstractFetcherThread.maybeFetch(AbstractFetcherThread.scala:129)
at kafka.server.AbstractFetcherThread.doWork(AbstractFetcherThread.scala:111)
at kafka.utils.ShutdownableThread.run(ShutdownableThread.scala:82)
[2019-02-14 09:20:00,617] INFO [ReplicaFetcher replicaId=1, leaderId=6, fetcherId=0] Error sending fetch request (sessionId=841897464, epoch=INITIAL) to node 6: java.net.SocketTimeoutException: Failed to connect within 30000 ms. (org.apache.kafka.clients.FetchSessionHandler)

我看到很多与CLOSE_WAIT状态的其他经纪人的联系(见下文).在线程使用中,我看到这些线程'kafka-network-thread-6-ListenerName(SASL_PLAINTEXT)-SASL_PLAINTEXT-0,kafka-network-thread-6-ListenerName(SASL_PLAINTEXT)-SASL_PLAINTEXT-1,kafka-network-thread- 6-ListenerName(SASL_PLAINTEXT)-SASL_PLAINTEXT-2'在60秒间隔内占用超过90%的CPU时间.

设置细节:

Java version:
openjdk 11.0.2 2019-01-15
OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
Kafka …

我试图了解确认模式在 JMS 中是如何工作的。我正在阅读这个来源，它让我非常困惑，因为它与 Spring 的文档所说的相矛盾。

消息来源说一件事：来自http://www.javaworld.com/article/2074123/java-web-development/transaction-and-redelivery-in-jms.html

当消息从 receive() 方法成功返回时，它会自动确认。如果接收者使用 MessageListener 接口，那么当它从 onMessage() 方法成功返回时会自动确认消息。如果在执行 receive() 方法或 onMessage() 方法时发生故障，消息会自动重新传递。

来自http://www2.sys-con.com/itsg/virtualcd/Java/archives/0604/chappell/index.html

在 AUTO_ACKNOWLEDGE 模式下，确认总是在 onMessage() 处理程序返回后隐式发生的最后一件事。通过在消费会话上指定 CLIENT_ACKNOWLEDGE 模式，接收消息的客户端可以对有保证的消息的传递进行更细粒度的控制。

Spring Docs 说其他事情：来自http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/jms/listener/AbstractMessageListenerContainer.html

侦听器容器提供以下消息确认选项：

“sessionAcknowledgeMode”设置为“AUTO_ACKNOWLEDGE”（默认）：监听器执行前自动确认消息；在抛出异常的情况下不重新发送。“sessionAcknowledgeMode”设置为“CLIENT_ACKNOWLEDGE”：监听器执行成功后自动确认消息；在抛出异常的情况下不重新发送。“sessionAcknowledgeMode”设置为“DUPS_OK_ACKNOWLEDGE”：监听器执行期间或之后的延迟消息确认；抛出异常时的潜在重新交付。“sessionTransacted”设置为“true”：成功监听器执行后的事务确认；在抛出异常的情况下保证重新交付。

我想知道的是，为什么这些消息来源说不同的话？如果一切都是真的，那么我怎么知道我的消息将如何/何时被确认？

1. 为什么有两种不同的属性用于度量报告？是什么让他们与众不同？
2. 如果它们不同，那么什么时候使用哪个？

谢谢，阿比