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

@leov: https://github.com/prepor/defcomponent

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

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

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

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

или вот так http://funclojure.tumblr.com/post/113550674318/clojure-cache-and-memoize-with-guavacache

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

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

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

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

Ага

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

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

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

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

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

@lowl4tency: ?

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

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

он же ексепшн кидает https://github.com/http-kit/http-kit/blob/73619b7d6cd3fb02da03ed420099764db26fedbf/src/java/org/httpkit/client/HttpClient.java#L76

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

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

чудеса

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

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

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

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

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

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

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

@kronos_vano: посмотри сюда - очень удобный кэш http://immutant.org/documentation/current/apidoc/guide-caching.html

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

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

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

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

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

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

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

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

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

в главе Writing

отл, спс

@prepor: thnx

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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.

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

@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 нравится больше?

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

@mike1452: привет https://clojars.org/chazel/versions/0.1.8

свежак

)) спасибо!!

да, конечно

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

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

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

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