@ru_python

Страница 8079 из 9768

John

13.02.2019
10:13:45

Парни, подскажите пожалуйста: https://github.com/ngoduykhanh/PowerDNS-Admin/blob/63b872f62705136b707ffc9f977d5395036a96c2/app/lib/utils.py строка 226 и ниже, там есть own_url = '' а откуда он должен браться этот самый own_url? Строка 247 использует own_url, и в логе он почему-то http, а система ожидает https. Сам сервис тоже работает на https, но https организован nginx'ом, а не flask'ом

Nikolay

13.02.2019
10:18:59

Господа, у меня стоит задача гарантированно и упорядоченно доставлять JSON на сервер с белым IP от машины, которая может терять коннект с этим сервером и перезагружаться. Есть устоявшиеся какие-то подходы и протоколы? Сейчас вижу только способ сохранять данные в SQLite и хранить их там до тех пор, пока не удастся отправить самое старое сообщение. Но может кто-то уже придумал более удачно решение за меня?

Tishka17

13.02.2019
10:25:18

Любая база

Это и есть устоявшийся подход

Google

Tishka17

13.02.2019
10:26:21

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

Vasia

13.02.2019
10:35:11

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

Nikolay

13.02.2019
10:54:16

Это и есть устоявшийся подход

Я думал, есть какая-то штука, типо RabbitMQ, которая позволяет создавать исходящую персистентную очередь

Tishka17

13.02.2019
10:54:38

Ну он позволяет, да

Nikolay

13.02.2019
10:54:39

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

Да в JSON таймстемп будет обязательно

Boriskas

13.02.2019
10:55:13

Я думал, есть какая-то штука, типо RabbitMQ, которая позволяет создавать исходящую персистентную очередь

Больше поебешься с такой штукой

Nikolay

13.02.2019
10:55:20

Ну он позволяет, да

Разве? Я не видел такого. Через Pika просто теряю связь с сервером и сообщения теряются, если их руками не сохранять

Tishka17

13.02.2019
10:55:29

Кажется, для твоего кейса это оверинжениринг

Nikolay

13.02.2019
10:56:18

Да, наверное вы правы. Буду велосипедить)

Boriskas

13.02.2019
10:56:41

чем проще тем лучше обычно

Tishka17

13.02.2019
10:56:44

Разве? Я не видел такого. Через Pika просто теряю связь с сервером и сообщения теряются, если их руками не сохранять

Так стоп, если будешь юзать рэббит, тебе надо гарантированно все в него класть, а дальше он позаботится

Vasia

13.02.2019
10:56:48

просто используй скулайт ин мемори, люк

Tishka17

13.02.2019
10:57:05

То есть кролик должен быть там где у тебя клиент

Google

Nikolay

13.02.2019
10:57:40

Так стоп, если будешь юзать рэббит, тебе надо гарантированно все в него класть, а дальше он позаботится

А, класть надо в локального кролика и из множества кроликов надо делать кластер?

Не, так не нравится

Точно оверинженеринг

Tishka17

13.02.2019
10:58:21

А, класть надо в локального кролика и из множества кроликов надо делать кластер?

Насчёт кластера хз. Так ты можешь и обычную базу реплицировать

А, класть надо в локального кролика и из множества кроликов надо делать кластер?

Ну не локального. Просто кролик не может гарантировать отсутствие потерь данных, которые он не получил

Nikolay

13.02.2019
10:59:12

просто используй скулайт ин мемори, люк

Это когда база в RAM? Как это поможет сохранять данные между перезагрузками и доставлять данные до сервера? Или я не о том подумал?

Vasia

13.02.2019
10:59:37

ну ты говоришь, что клиент не всегда доступен, а данные копятся

Nikolay

13.02.2019
10:59:49

Ну не локального. Просто кролик не может гарантировать отсутствие потерь данных, которые он не получил

Ну то есть проблема доставки до кролика все равно существует в случае, если сервер кролика временно недоступен...

ну ты говоришь, что клиент не всегда доступен, а данные копятся

Ну да. Но клиент еще и ребутнуться может, а данные, пришедшие до ребута", с него тоже надо стянуть

Vasia

13.02.2019
11:00:30

эм, тут лучше перефразируй

с него - с клиента?

Владимир

13.02.2019
11:01:05

Ну то есть проблема доставки до кролика все равно существует в случае, если сервер кролика временно недоступен...

Храни часть локально, помечай отправленные, помечай доставлены ли они. Если были отправки, но не пришло подтверждение в заданный период времени — повторная отправку

Terminator

13.02.2019
11:01:21

Максим будет жить. Поприветствуем!

Nikolay

13.02.2019
11:03:13

эм, тут лучше перефразируй

Ну смотри. Есть железка, она собирает лог событий и отправляет эти события на сервер по одному. Иногда свзяь с интернетом рвется и железка должна копить данные в себе, чтобы потом отправить их на сервер. Но пользователь железки может подумать "что-то я данные давно не получал... не ребутнуть ли мне железку?" и ребутет железку, которая уже накопила лог событий. После ребута проходит еще какое-то время, события продолжают копиться. И вот провайдер снова включает интернет и жалезка должна отправить все данные, что накопились с момент потери интернета.

Но, видимо, вариант с SQLite + любой транспорт самый просто и удачный

его и заюзаю

чем помочь то?

Vladislav

13.02.2019
11:06:18

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

Nikolay

13.02.2019
11:07:01

Классно. Ты написал бота? Можно нажать кнопку Start?

Я помог?)

Google

Cykooz

13.02.2019
11:07:17

Ну смотри. Есть железка, она собирает лог событий и отправляет эти события на сервер по одному. Иногда свзяь с интернетом рвется и железка должна копить данные в себе, чтобы потом отправить их на сервер. Но пользователь железки может подумать "что-то я данные давно не получал... не ребутнуть ли мне железку?" и ребутет железку, которая уже накопила лог событий. После ребута проходит еще какое-то время, события продолжают копиться. И вот провайдер снова включает интернет и жалезка должна отправить все данные, что накопились с момент потери интернета.

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

Denis

13.02.2019
11:07:58

Здравствуйте. У меня кризис идей. Можете посоветовать идею для простенькой консольной проги

Владимир

13.02.2019
11:08:28

РО @fahreeve просится

Nikolay

13.02.2019
11:08:47

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

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

Спасибо, мне на основной работе больше платят

Cykooz

13.02.2019
11:09:20

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

Но это ведь всё равно логи? Это ведь не бинарные файлы по 5 Гб каждый?

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

Логи - это просто некие записи о случившихся событиях

Nikolay

13.02.2019
11:10:26

Но это ведь всё равно логи? Это ведь не бинарные файлы по 5 Гб каждый?

Нет, это JSON формата {"device":"123, "door_id":777, "opened":True, "time":1234567890}

Значит я мент