ST
для опроса чужих апи? 😊
Size: a a a
2020 January 22
ST
И частота нужна секунда и меньше
для опроса чужих апи? 😊
расскажи, что получилось, когда сделаешь
расскажи, что получилось, когда сделаешь
MB
для опроса чужих апи? 😊
расскажи, что получилось, когда сделаешь
расскажи, что получилось, когда сделаешь
Ага, ну я на самом деле для одного букмекера уже на nodejs сделал :) Интересно, как это на кложуре бы выглядело
ST
И частота нужна секунда и меньше
если частота нужна минимальная, то я бы просто привязывался к длительности процедуры получения данных
получил данные, обработал, ушёл в новый цикл, и так без конца
если нужно немного подождать, то добавить Thread/sleep
получил данные, обработал, ушёл в новый цикл, и так без конца
если нужно немного подождать, то добавить Thread/sleep
MB
Кстати, если кому интересно, клиентская библиотека rabbitmq на nodejs совсем плохая. Она синхронно посылает сообщения в очередь, поэтому nodejs быстро сходит с ума, если много сообщений туда кидать 😁
MB
40 сообщений в секунду мне было достаточно, чтобы у меня хип переполнялся
ST
Сергей Суржик
можешь прописать полную конструкцию? я уже плыву после трех часов clojure
можно и update-in, но будет выглядеть странно
(swap! app-state update-in [:servers :dev] #(assoc % :status 200))
ST
можно и update-in, но будет выглядеть странно
(swap! app-state update-in [:servers :dev] #(assoc % :status 200))
но в случае, когда у тебя уже есть функция для выставления статуса в объект, то тогда в самый раз
MB
если частота нужна минимальная, то я бы просто привязывался к длительности процедуры получения данных
получил данные, обработал, ушёл в новый цикл, и так без конца
если нужно немного подождать, то добавить Thread/sleep
получил данные, обработал, ушёл в новый цикл, и так без конца
если нужно немного подождать, то добавить Thread/sleep
Вроде тоже рабочий вариант, но я боюсь, что тут как-то ресурсы неконтролируемо будут потребляться
MB
Скажем, идёт 100 матчей, на каждый из них я создаю такой цикл. Кажется, что это будет жрать или слишком много процессора, но скорее слишком много io :)
ST
Вроде тоже рабочий вариант, но я боюсь, что тут как-то ресурсы неконтролируемо будут потребляться
вот тут как раз никаких вопросов — один поток с циклом, даже никаких вопросов с асинхронным выполнением
MB
Ну в целом да, я думал сделать на кложуровских future
MB
Вроде очень просто получается
ST
Скажем, идёт 100 матчей, на каждый из них я создаю такой цикл. Кажется, что это будет жрать или слишком много процессора, но скорее слишком много io :)
в самый раз для core async pipeline
ST
Ну в целом да, я думал сделать на кложуровских future
а вот это в самый раз для «Кажется, что это будет жрать или слишком много процессора, но скорее слишком много io :)» 😊
MB
в самый раз для core async pipeline
Наверное, надо все таки грокнуть уже core.async :)
MB
а вот это в самый раз для «Кажется, что это будет жрать или слишком много процессора, но скорее слишком много io :)» 😊
Ну идея была сделать таймер только для списка, а сходить по всем матчам фьючерами
MB
А не городить кучу таймеров
D
Сергей Суржик
(def app-state (atom {:servers {:dev {:url "url-dev" :status nil} :test {:url "url-test" :status nil}}}))
(swap! app-state assoc-in [:servers :dev] {:status 200})при таком апдейте сносится url
(swap! app-state update-in [:servers :dev] merge {:status 200})
ST
Ну идея была сделать таймер только для списка, а сходить по всем матчам фьючерами
есть чего сказать, но нужно работать 😊