问题标签 [vertx-verticle]

我已经实现了一个 Verticle，如下所述。Verticle 按预期工作。现在我正在尝试为这个 Verticle 编写 Junit 测试用例，它可以测试 start 方法、处理程序方法 handleRequest() 以及返回 Future 的处理程序内部的方法 getSomeData()。测试所有三种方法的单个测试用例或测试单个方法的单个测试用例都应该没问题。我知道为同步代码编写 Junit 测试用例，但不知道如何在异步的 vert.x 中为 Verticle 编写 Junit TC。有人可以在这里指导我吗？我也有路由器verticle，我从它向这个消费者verticle MyVerticle 发送消息，但我想先为这个消费者verticle 编写Jnuit 测试用例。请帮忙。

}

我正在尝试创建autowired内部类的模拟实例，Verticle但我将它作为空值。对于同步代码，工作方式看起来对Vert.x.

垂直是：

依赖组件是：

测试用例是：

autowired如果我不使用实例调用方法来获取日期，上面的测试用例效果很好。但是如果使用它（我必须这样做才能获取数据），它会MyVerticle->getSomeData()在尝试将serviceExecutor对象用作模拟对象时给出 NPE at 方法。这种方法非常适用于同步代码流，但Vert.x看起来无济于事。所以这里需要帮助来模拟里面的autowired实例。serviceExecutorVerticle

我最近一直在做一些关于 HA 模式下 Vert.x 和 Verticle 的行为的实验。我观察到 Vert.x 如何在各个节点上分配负载的一些弱点。

1.集群中的一个节点崩溃

想象一个配置有一些 Vert.x 节点（比如 4 或 5、10 等）的集群，每个节点都有数百或数千个 Verticle。如果一个节点崩溃，剩下的节点中只有一个会重启所有已经部署在崩溃节点上的 Verticle。此外，不能保证它将是部署的 Verticle 数量最少的节点。这是不公平的，在最坏的情况下，同一个节点会从之前崩溃的节点中获取所有的 Verticle，这可能会导致多米诺骨牌崩溃的情况。

2. 向负载较重的集群添加节点

将节点添加到负载较重的集群并不能帮助减少其他节点上的负载。现有的 verticles 不会在新节点上重新分配，新的 verticles 会在调用vertx.deployVerticle().

虽然第一点允许在一定限度内实现高可用性，但第二点打破了简单水平可扩展性的承诺。

我很可能是错的：我可能误解了某些东西，或者我的配置可能有问题。这个问题是关于确认这种行为以及你如何处理它或指出我的错误的建议。感谢您的反馈。

这就是我创建vertx对象的方式：

这就是我创建我的verticles的方式：

2019 年 12 月 25 日编辑：阅读 Alexey 的评论后，我相信我可能并不清楚。

1. 通过承诺简单的水平可扩展性，我并不是说在插入新节点时重新分配负载很简单。我的意思是 Vert.x 向开发人员承诺，他需要做的就是让他的应用程序水平扩展很简单。Scale是 Vert.x 主页上的第一个参数，但是，您是对的，在仔细阅读之后，新添加的节点上没有任何关于水平缩放的内容。我相信我受 Elixir 或 Erlang 的影响太大了。也许 Akka 在 JVM 上提供了这个，但我没有尝试。

2. 关于第二条评论，它不是（仅）关于每秒请求的数量。我在这里考虑的负载只是“什么都不做，等待消息”的verticles的数量。在进一步的实验中，我可以让这个 Verticle 做一些工作，然后我会发送一个更新。目前，想象一下在内存中代表实际连接的后端用户会话的长寿 Verticle。该系统在 3 个（或任何数量）集群节点上运行，每个节点托管数千个（或更多）会话/垂直。从这个状态开始，我添加了一个新节点并等待它完全集成到集群中。然后我杀死了前 3 个节点中的一个。所有 verticles 都可以正常重启，但只能在一个节点上重新启动，而且不能保证成为“空”的人。目标节点实际上似乎是随机选择的：我做了几次测试，我什至观察到所有被杀死节点的顶点在同一个节点上重新启动。在具有足够负载的真实平台上，这可能会导致全局崩溃。

我相信在 Vert.xa 中实现 verticles 的公平重启，即根据给定的负载度量（CPU、RAM、#of verticles，...）在所有剩余节点上分配 verticles 会更简单（不简单）而不是在新插入的节点上重新分配负载，因为这可能需要调度程序从另一个节点“窃取”verticles 的能力。

然而，在生产系统上，没有受到集群上某种公平分配工作负载的“保护”可能会导致大问题，并且由于 Vert.x 已经相当成熟，我对我的实验结果感到惊讶，因此认为我是做错事。

我最近开发了一些需要从中进行外部 API 调用的 Verticle。为了优化代码，我将调用 API 的代码移到了一个常见的 Helper 类中。我还将 Vertx 实例从 Verticle 传递给 Helper 类。我现在正在尝试为 Helper 类编写 Junit 测试用例，它看起来像下面的工作代码。

谁能指导我如何为上述代码编写测试用例？

我来这里是因为我注意到 vertx-guice 2.3 不支持 vertx 3.8 并且恰好在 verticle 启动和停止方法中使用了 Promise。

当我使用低于 3.8 的 vertx 版本（使用 Future）时，我的项目运行良好，但是由于我进行了更改以使用 Promise，因此我的 Verticle 不再启动。

当我测试删除使用 vertx-guice 时，它​​可以工作，但我需要它，所以这不是解决方案

有人注意到同样的事情吗？我该如何解决？

我可以在默认位置上传文件。

此主体处理程序将文件放入文件上传中。这是上传文件的代码：

这些是我上传的文件。

file-uploads 文件夹位于我项目的根目录，它是自动创建的。如何访问该文件夹的内容以在我的 html 页面中显示图像？

也很奇怪，他们没有扩展名......

我目前正在开发我的第一个 vert.x 服务，但我对部署的实现方式并不十分自信。

我有几个 Verticle 来接受来自其他服务的请求并将一堆工作委托给其他 Verticle。如何在工作完成后启动每个任务的 Verticle 并杀死它，或者以编程方式将 Verticle 扩展为任务数量。

我目前在启动时生成了十个 Verticle，并使用事件总线将这些任务分布在 Verticle 上。

主垂直

管理垂直 - HTTP 处理程序

更新垂直

我是 vertx 的新手，正在尝试使用 ABCHandler.java 中的 vertx.executeBlocking 执行函数 1

}

ABCHandler 旨在在将请求路由到实际 URI 之前验证一些数据。但是在 routingContext.next(); 之后 我收到 500（内部服务器错误）。

此外，当我运行与非阻塞相同的代码时，它可以工作。

非常感谢这里的任何帮助。

我正在使用运行 HTTP 服务器的基本 vert.x 示例 verticle；

这会启动并响应，所以我想我会通过它进行快速负载测试ab -n 100000 -c 50 http://localhost:8080

每次运行都相对一致，大约有 16,400 个完成的请求超时，给予或接受 10 个。我尝试过使用vertx 选项setWorkerPoolSize，setEventLoopPoolSize但似乎没有任何效果。

我还尝试通过缩放 Verticle--instances 10并确认它确实部署了 10 个 Verticle。奇怪的是，同样的 16,400 是它死亡的地方。

日志显示没有错误或警告，它似乎只是在负载下死了。如果几秒钟后我用浏览器点击它，它会再次愉快地响应。有没有人遇到过这个？我很好奇为什么会发生这种情况，以及如何解决它。

我正在编写一个简单的 vertx Verticle，它在 start 方法中加载一个配置文件：

我最初使用：

但这种方法已被弃用。

我正在使用这段代码：

然后，在被调用的“startService”方法中，我完成了 startPromise。

每隔几秒钟我就会看到两个新线程被创建：

如果我不加载配置文件，这些不会被创建。我是否误解了如何使用 vertx-config 异步加载配置文件？