потоке, а не прыгать между разными потоками? Если указать WorkerPoolSize = 1 для всего Vertx, то больше не получится использовать другие Worker Verticle, т.к. они могут быть заблокированы. Это нужно для записи в HBase из event bus.
DeploymentOptions можно при развертывании Verticle указать: https://vertx.io/docs/apidocs/io/vertx/core/Vertx.html#deployVerticle-java.lang.String-io.vertx.core.DeploymentOptions-io.vertx.core.Handler- пример: https://medium.com/@pvub/https-medium-com-pvub-vert-x-workers-6a8df9b2b9ee
Не срабатывает. Используются разные потоки. В примерах при создании Vertx используют.
io.vertx.core.impl.DeploymentManager#doDeploy отдельный пул и отдельный executor создается для Verticle. соответственно, пул можно с одним тредом запустить.
А я немного не понял проблему. Вроде как можно писать из отдельного вертикла, специально заточенного под чтение шины и работы с базой.
Но каждый message, пришедший в вертикл может быть обработан в разных потоках пула.
А зачем привязываться к потокам? Если будет только 1 вертикал, что будет обрабатывать, то проблем быть не должно. Ну или я не очень понял архитектуру вашего приложения)
Есть непотокобезопасный компонент - HBase client Table. Сейчас сделал костыль: 1. WorkerVirticle получает message из event bus, пишет его в блокирующую очередь. 2. Отдельный JVM поток читает блокирующую очередь и пишет в HBase.
ну так поток всегда будет один ведь. Или у вас в кластере несколько клиентов hbase?
В том то и дело, что каждое сообщение обрабатывается в отдельном потоке. Проверял через вывод названия потока в stdout при получении сообщения. Работать то оно может и будет, но есть риск словить ошибку.
У меня все в одной JVM, не кластер.
Блин. А это я не проверял. Да, тогда может быть проблема. Но смысл костыля верный - запулить все в одну очередь и ее разгребать.
Обсуждают сегодня