а почему я одну из них не могу оставить как есть?

можешь

одну зашейдил, другую нет

ну вот я так делаю

так убери из списка то йоптыть)

зачем ты ее в список для шейда пихаешь тогда? )

error] deduplicate: different file contents found in the following: [error] /Users/folex/.ivy2/cache/io.netty/netty-handler/jars/netty-handler-4.1.1.Final.jar:shadednetty/handler/traffic/GlobalChannelTrafficShapingHandler.class [error] /Users/folex/.ivy2/cache/io.netty/netty-all/jars/netty-all-4.1.6.Final.jar:shadednetty/handler/traffic/GlobalChannelTrafficShapingHandler.class

забудь про это соощение, это я показал как inAll у меня работает

а зачем ты две версии добавлял

в списке только 4.1.1 и 4.037, моя желательная версия нетти 4.1.6

и переименовывал их в одно и тоже

.inLibrary("io.netty" % "netty-handler" % "4.1.1.Final") .inLibrary("io.netty" % "netty-handler" % "4.0.37.Final")

убери отсюда 4.0.37

я давно очень вляпывался, но вроде можно кастомно имена для шейда делать, не?

ей другое имя дай)

я давно очень вляпывался, но вроде можно кастомно имена для шейда делать, не?

да как угодно можно)

а, ок

я понял о чем вы

у меня в итоге ~5 версий нетти в проекте :))

видать для всех свой шейд надо делать

)) как-то грустно

да

для каждой отдельно переименовывай и сомтри чтоб все либы знали что ты переименовал

причем одна версия просто зашита в драйвер к одной из бд, прям код туда скопирован, такая беда

ну так и шейди все версии, кроме одной. только каждую версию под отдельный шейд. но вобще - это клиника конечно)

соглашусь

крипота какая..

это что у вас там клешнулось то у всех что 3 и 4 нетти в одном проекте?

ну разные либы тянут

3й не мешает

а вот зоопарк четвертых -- очень

ну ничо, щас может основной версией сделаю 4.1.1, и будет счастье...

extract as microservice, не?

выделить в микросервис часть приложения, которая зависит от библиотеки?

ну, это не везде возможно + лишний сервис мне не нужен

ну я не эксперт в этом вопросе , но почему-то мне кажется что если у приложения есть зависимости от двух трех разных нетти, значит это приложение что-то дохрена на себя берет :)

почему? Ну вот у тебя есть у приложения скажем 3 места куда надо сходить по сети, это много?

3 каких-нибудь сервиса. Например AMQP какое-нибудь, база и кеш

у каждого есть своя либа-драйвер

у них своя версия нетти

+ приложение бэкенд, поэтому надо слушать порт, там тоже нетти

вот уже 4 версии

ну вот давай спросим тут у народонаселения

о чем? :)

а у либ которые используют старые версии нетти - нет обновлений?

их сложно назвать старыми, 4.1.1 не такая уж старая

у кассандровского драйвера есть обновление кстати, щас обновим, посмотрим

4.1.5 теперь :) хех

\o/

все равно не 4.1.6!

а откатить то что тащит 4.1.6 до того что потащит 4.1.5 ? :)

кассандра дривер тащит 4.0.37

оно эвиктится видать

это значит pushy вытянуло 4.1.5, я еще не смотрел кто

идея резолвит зависимости, хорошо хоть в чат писать могу

я обычно dependency graph'ом смотрю кто что тянет

он также отображает что на что было заэвикчено

угу, я его прост не запускаю тк идея

но щас вот уже всё

@pomadchin 3.1.2 вроде 4.1.5 тянет

[info] +-io.netty:netty-handler:4.1.5.Final [info] +-com.datastax.cassandra:cassandra-driver-core:3.1.2

https://mvnrepository.com/artifact/com.datastax.cassandra/cassandra-driver-core/3.1.2

и не написано evicted

[info] +-io.netty:netty-handler:4.0.37.Final (evicted by: 4.1.5.Final) [info] | +-com.datastax.cassandra:cassandra-driver-core:3.1.2 а, написано

После сведения почти всего к 4.1.5 вроде все работает, осталось только проверить что epoll реально работает

https://github.com/non/kind-projector кто-нибудь это использует?

многие используют

использую

и я использую

а вот расскажите мне как правильно на акторах делать транзакционную целостность? у меня есть кошельки, один в одном акторе, другой в другом. есть у меня что-то типа супервизора, который одному актору говорит "добавить", а второму "убавить". но! если у меня один актор уже добавил, а второй просто сдох, то первому надо как-то откатить изменение. как это делается? 2/3 phase commit в вики я прочитал, но либы под это дело нет что ли?

при работе с финансами и такой организации правильно не откатывать(ролбек дб транзакции) действие, а совершать дополнительную транзакцию возвращающую средства на первый кошелек. но имхо - акторы как и многое другое часто путают с манной небесной и начинают приплетать для все, что ни попадя. но имхо делать под каждый кошелек актор - не самое удачное решение)

ну почему под один. если у нас их 10 лямов, то их было бы неполохо разнести хотя бы на 10 акторов и по хешу слать им команды, не?

но! да. я понял идею, зачет :)

разносить 10 лямов по 10 акторам по хешу - уже не имеет смысла. потому что это ни туда ни сюда. при таком направлении надо делать именно тредед воркеры и хеши не требуются, просто первый свободный выполняет - исключительно для параллелизации. а коллизии можно устранять на уровне супервизора

но тут тоже встает вопрос, допустим мы хотим отправить первому "убавь", а он у нас тоже помер. под это дело нужен целый loop какой-то?

да это игровой пример, ну что вы в самом деле :)

тогда зачем обсуждать, если это все равно не важно? ))

важно сделать транзакцию между акторами, чтоб в одном убавилось, в другом добавилось или все вернулось как было, вот в чем вопрос.

а вот расскажите мне как правильно на акторах делать транзакционную целостность? у меня есть кошельки, один в одном акторе, другой в другом. есть у меня что-то типа супервизора, который одному актору говорит "добавить", а второму "убавить". но! если у меня один актор уже добавил, а второй просто сдох, то первому надо как-то откатить изменение. как это делается? 2/3 phase commit в вики я прочитал, но либы под это дело нет что ли?

Это будет eventual consistent действие, и тебе нужен process manager / saga для этого

Который реагирует на события или на ответы акторов и двигает процесс

То есть ты сначала делаешь холд на списание, потом шлешь пополнение, после этого коммитишь холд

У меня в aecor.io есть пример проведения транзакции с процсс менеджером

Вообще когда работаешь с акторами представь как бы ты делал это с людьми

Где персистентные акторы это люди у которых есть ручка и блокнот и они его после смерти могут передать следующему человеку )

Люди офигенно распределенная система

И делали транзакции до компьютеров

важно сделать транзакцию между акторами, чтоб в одном убавилось, в другом добавилось или все вернулось как было, вот в чем вопрос.

можно но это будет не атомарное действие

С людьми плохой пример, обычно люди умеют делать много вещей)

Не мешай людям ошибаться, это снижает конкуренцию)

С людьми плохой пример, обычно люди умеют делать много вещей)

абстрагируйся от многих вещей

смысл в коммуникации обменом сообщениями

я понял новую схему версионирования akka http. X -> XX -> XXX -> XXXX

Semver done right

смысл в коммуникации обменом сообщениями

обмен сообщениями - средство коммуникации, а не смысл)

"Коммуникация обменом сообщениями"

Перечитай еще раз :-)

Перечитай еще раз :-)

Ну все же поняли

Михаил не понял:-)

Путем обмена сообщениями

Видимо прочитал как "смысл коммуникации в обмене сообщениям"