我正在使用 vert.x 读取文件并进行转换，然后推送到 kafka。 我正在使用 2 个 Verticle，没有使用任何工作线程（我不想更改文件中日志的顺序）。
Verticle 1 : Read the file and filter
Verticle 2 : Publish to kafka
每个文件包含大约 120000 行
但是，我观察到一段时间后，我停止观察 Verticle 1 的日志。 我怀疑事件总线已满，所以消费者仍在消费，但生产者线程正在等待事件总线变空。
所以我的问题是 1. 事件总线的默认大小是多少？在文档中它说
DEFAULT_ACCEPT_BACKLOG
The default accept backlog = 1024
2。如何确认我怀疑发布者线程已被阻止？
【问题讨论】：
标签： java event-handling vert.x
VertX 在内部使用 Netty 的 SingleThreadEventLoop 作为其事件总线 maximum pending tasks allowed is Integer.MAX_VALUE，这可能是 20 亿条消息。
您可能需要尝试VertxOptions.setWarningExceptionTime(long warningExceptionTime) 将值设置为低于默认值（5 秒），以查看是否有任何关于线程阻塞的警告。
【讨论】：
为了补充@iwat 的答案，在我使用的版本中，看起来最大大小是从系统属性中读取的：
protected static final int DEFAULT_MAX_PENDING_TASKS = Math.max(16, SystemPropertyUtil.getInt("io.netty.eventLoop.maxPendingTasks", 2147483647));
因此，您可以通过设置该系统属性来控制 Verticles 前面的队列大小。
如果事件总线已满（NioEventLoop 中的队列达到最大大小），任务将被拒绝。因此，如果您点击它，您应该开始看到对您的消息的错误响应，您不应该看到任何被阻止的生产者。
【讨论】：
我不确定accept-backlog设置对事件总线有什么影响，考虑到它可能与网络服务器有关的文档，但是通过对代码的简短扫描，我没有发现在事件总线。
然而，事件总线确实会立即传递消息，消息不会在某处排队（至少我从代码中理解的是）。所以关于你的第一个问题，它没有任何大小，至少在本地运行时没有（不知道集群版本，但我认为这无论如何都不适用于你的情况）
要确认（事件循环）线程实际上被阻塞很容易，您的日志中应该有大量异常表明事件循环被阻塞。
我猜你的问题出在其他地方，但如果没有任何代码或有意义的日志，这实际上很难说。
【讨论】：