Fork me on GitHub
#clojure-russia
<
2016-02-28
>
dottedmag00:02:15

@leov: У @prepor есть враппер к компоненту, который делает его мягким и шелковистым.

mike_ananev07:02:50

@leov: я использую и mount и component. в последнее время делаю все на mount, получается быстрее. а в чем вопрос?

kronos_vano12:02:56

Мужики, мне нужно сделать простой мэповый кешер: ко мне приходят запросики, если в кеше нет я их считаю сохраняю и возвращаю, если есть то сразу возвращаю, экспайрить их не надо. Я так подумал, что можно взять core.cache и не париться?

serioga12:02:32

возьми и не парься simple_smile

serioga12:02:49

даже если экспайрить надо

a.espolov13:02:57

парни пользовался кто onyx’ом?

Kira Sotnikov13:02:06

a.espolov: ты про фреймворк?

Kira Sotnikov13:02:09

Он у нас в проде

Kira Sotnikov13:02:34

тут есть #C051WKSP3 там сидят авторы

Kira Sotnikov13:02:16

a.espolov: мы сейчас пилим кластер как раз

Kira Sotnikov13:02:29

у нас сингл-нода пока в проде

Kira Sotnikov13:02:01

могу попробовать ответить на вопросы, но я не программирую )

a.espolov13:02:23

у него есть кластерный кэш.

a.espolov13:02:59

джоба получила данные и запихала в кэш, который будет доступен на всех нодах?

Kira Sotnikov14:02:54

это я не отвечу 😞

kronos_vano14:02:38

Как в org.httpkit.client поймать timeout? Он callback не вызывает если таймаутится :thinking_face:

kronos_vano14:02:25

видимо сам и ловит

kronos_vano14:02:02

хм, в минимальном примере все ок

prepor15:02:00

> он же ексепшн кидает как асинхронная пижня может кинуть эксепшен, м?

prepor15:02:15

коллбэк вызовется

prepor15:02:20

с error параметром

kronos_vano15:02:19

Дадада, с этим понятно.

kronos_vano15:02:50

У меня теперь проблема как убить горутинку через X времени если она мне ничего в канал так и не отдала

kronos_vano15:02:16

на таймаут http-kit клиента не получается полагаться. ставлю 2 секунды, он отваливается через 3,5

serioga15:02:46

> как убить горутинку через X времени если она мне ничего в канал так и не отдала надо завести ещё timeout канал и забирать результат из обоих через alt!

dottedmag15:02:53

Господа, а чем вы пользуетесь для координации? Какой-нибудь обёрткой вокруг Zookeeper? Или вокруг etcd? Или что-нибудь самопальное?

mike_ananev15:02:06

@kronos_vano: но в последнее время я использую другой кэш - на удаленной jvm - Hazelcast

mike_ananev15:02:19

вот удобная библиотека работы с ним https://github.com/tolitius/chazel

kronos_vano15:02:26

Immutant-овский смотрится круто. А что у него с конкурентностью? Ключи я удалять и экспайрить не буду, но буду писать в него из разных потоков

prepor15:02:44

> Господа, а чем вы пользуетесь для координации? Какой-нибудь обёрткой вокруг Zookeeper? Или вокруг etcd? Или что-нибудь самопальное? я curator просто юзаю

prepor15:02:56

есть еще реализация raft-а atomix, для него есть кложа-интерфейс https://github.com/atomix/trinity, но я не пробовал. @dottedmag

mike_ananev15:02:04

hazelcast предоставляет конкурентный кэш + возможность организации транзакций

mike_ananev15:02:22

а immutant'овский ща гляну

mike_ananev15:02:54

immutant' овский тоже конкурентный

mike_ananev15:02:15

в главе Writing

kronos_vano16:02:29

отл, спс

prepor16:02:30

@mike1452: @kronos_vano тащить хазелькаст в проект только для организации удаленного кеша это как-то страаааано )

mike_ananev16:02:25

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

mike_ananev16:02:17

immutant'овский кэш я перестал использовать только потому, что для выноса кэша из jvm приложения придется ставить кластер wildfly и настраивать infinispan там. я покопался в документации infinispan и у меня создалось такое впечатление, что продукт очень не плохой, но документировать его разрабы не торопятся. при внешне доступной документации шаг вправо или влево расстрел. я так понимаю это внутренний продукт redhat, который они используют вовсю внутри, но при этом документируют не все.

kronos_vano16:02:27

@prepor: нене, мне нужно что-то простое и конкуррентное в памяти. core.cache или immutant возьму

kronos_vano16:02:41

Мужики, нужно ваше "фи": https://gist.github.com/kronos/dc2cc12c50700d066afa. Поясню: по адресу url, будет "плохой" бекенд который может отвечать 500/403/etc, а может возвращать ответ с большим таймаутом. Мне на ответ дается 2 секунды, поэтому я 2 секунды долблюсь по url, а по таймауту отдаю стандартный пустой ответ. В конце сниппета let блок, но в конечном счете это будет отдаваться catacumb-ой: (http/ok ch)

mike_ananev16:02:17

зато с hazelcast'ом я имею почти обычную мапу внутри clojure. но map'a эта физически хранится на другой машине. если нужно расширить кэш, достаточно просто стартовать новый процесс hazelcast на любой машине и кластер hazelcast может расти и уменьшаться "простым почкованием".

prepor17:02:06

@kronos_vano: судя по всему ты не особо понимаешь как работают блокирующие операции. (go (alt! (timeout 2000) (>! ch empty-response) (search address) ([result] (>! ch result))) (close! ch)) тут ты делаешь через alt таймаут а тут @(http/get блокируешь к хренам весь тред. как это по-твоему будет работать?

prepor17:02:28

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

mike_ananev17:02:05

@prepor: у меня задача разгрузить запросы по статистике - вынести на другую машину. поэтому я сделал удаленный map. data locality мне не нужен, поскольку в статистике read-only информация, которую сам сервер обновляет. Apache Ignite - это первое, что я хотел взять. Только официальный докер образ не запускается на моем mac'е. Ни один docker-образ таких проблем мне не выдавал как ignite. В итоге я плюнул на iginte и взял hazelcast - прямой конкурент. Для hazelcast'а есть и нормальный docker образ, и документация и wrapper для clojure. А большего мне и не надо. Посмотрим как Ignite покажет себя в банке, что-то пока только разговоры

mike_ananev17:02:55

@kronos_vano: на известном торрент сервере лежит курс o'reily от самого создателя core.async. он там в 10 лекциях все разжевал

kronos_vano18:02:06

@mike1452: ну в принципе все стало на свои места, благодарю

rmuslimov20:02:27

а подскажите мне зеленому этот hazelcast or. ignite это ведь такой memcached/redis кластер на стероидах с репликами и даже поддержкой SQL?

rmuslimov20:02:14

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

rmuslimov20:02:18

> with every cluster node owning a portion of the overall data. This way the more cluster nodes we add, the more data we can cache.

rmuslimov20:02:39

а все вижу, невнимательно прочитал

tolitius21:02:19

@prepor > собственно в таких датагридах самый смак все же то, что мап хранится не на другой машине, а на этой же у них несколько интересных применений, и в основном, чем дальше используются gridgain, hazelcast, etc.. от "play projects" тем больше смысла to decouple them from the app JVM. не только потому что упираешься в heap, но и потому что это намного облегчает работу Ops (i.e. rolling restarts, consistency on node failures, ..). я не особо знаком с ignite кроме того что это попытка gridgain'a ребрендаться и войти в мир кеша, но мне очень нравится hazelcast, так как он очень практичный, мощный и простой. а чем тебе ignite нравится больше?

mike_ananev22:02:59

@tolitius: Анатолий, доброй ночи! А когда можно ожидать версию chazel "0.1.8", а не "0.1.8-SNAPSHOT" как сейчас? А то скоро билд делать, а со SNAPSHOT зависимостями lein будет ругаться.

tolitius22:02:24

свежак

mike_ananev22:02:34

)) спасибо!!

tolitius22:02:03

да, конечно

prepor22:02:51

@tolitius я не ипользую ни одну из этих систем сейчас, просто смотрю немного сбоку, так что мое мнение совершенно не авторитетно simple_smile По сравнению с хазелькастом чуваки тут https://ignite.apache.org/use-cases/compare/hazelcast.html вроде все по делу говорят ) У хазелькаста какое-то очень наивное все. > тем больше смысла to decouple them from the app JVM Это все же совершенно разные вещи. Разница между локальным доступ и по сети — тысячи раз, очень многое просто не будет работать в remote режиме. Но что-то да, прекрасно ляжет и на удаленный доступ, но, как я и сказал, это сильно снижает область примемения simple_smile > а чем тебе ignite нравится больше? мне они вообще оба не нравятся ) на мой взгляд правильный подход это примерно то, что делает датомик. Но 1) оно не опенсорсное 2) шардить транзактор и запускать его локально нельзя 😞

tolitius22:02:03

@prepor: я на самом деле и знаю только чуваков из грид гэйна по их матрицам насколько грид гэйн, игнайт лучше всех simple_smile > очень многое просто не будет работать в remote режиме ну есть конечно задачи которые не лягут, но TCP/IP сегодня довольно шустренько работает и ограничение в основном будут у apps (дезайн, locking, blocking, processing) rather than the fact that the cache is remote. > на мой взгляд правильный подход это примерно то, что делает датомик датомик слишком "иностранный" для не кложр людей, а уж тем более для просто кеша. hazelcast прикольный для Java пипл потому что Java datastructures / distributed ExecutorService с аналогичными API, т.д. не утверждаю что он лучший, но точно могу сказать что несколько проектов оч довольны

mike_ananev22:02:51

@prepor: мы попробовали датомик в бою. пришлось отказаться по нескольким причинам. первая - вендор чего-то испугался russia, вторая - из-за транзакционности датомика заливка данных в него очень долгая процедура. что мы только не делали: и 9 серверов кассандра как бэкэнд ставили, тюнили транзактор, загрузчик кода писали 2х проходный (1й проход - построение Spark'ом EDN-структур в соответствии со схемой сущностей в датомике, 2й проход - полученный от вендора код загрузки с пайплайнами и асинхронными вызовами). все равно - лить данные из другой базы это беда

mike_ananev22:02:48

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