Tag: nntp

Заопенсорсил NNTP-гейт

Монетизировать NNTP совсем некогда, поэтому код пошел детям в приют:

github.com/rcdesign/vb-nntp

Проверил логи - работает более-менее стабильно. Не считая случая с DDoS, когда памяти не хватило и что-то внутри поехало. С 5 числа падений не было. За 10 дней только 4 странных эксепшена, которые изучу позже. Памяти наело с 13 мегабайт до 23. Будем считать, что не течет.

Да, кстати, вышла стабильная нода 0.4 с новым шустрым движком и кучей вкусностей. Как будет настроение - добью у гейта встроенный TLS, чтобы полностью отказаться от stunnel4.

Выложить что ли NNTP-гейт в опен-сорц?

Проблема. Есть NNTP-гейт для форума:

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

Теоретически я мог бы раздавать и даром, но есть нюанс. Продукт состоит из 2 частей: вебовской (php-шной) и демона на перле. Поэтому дятел его просто так не поставит. А бесплатно отвечать на тупые вопросы у меня желания нет.

Вот, мучаюсь. Хоронить жалко, раздавать впадлу, продавать некогда 😃. Раздумываю, как бы это все похитрее выложить. Типа, код бесплатный, но есть возможность “задорого” сделать платную установку. Хотя тут тоже не ясно, как потом любой ценой избежать последующих вопросов и “фичареквестов”.

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

Составной автоинкрементный индекс в mysql

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

Если группа одна - все просто. Вешаем автоинкрементный индекс и не паримся. Если групп много - ну не хранить же каждую в отдельной таблице. Или если счетчики с номерами последних сообщений хранить отдельно - надо обеспечивать атомарность апдейтов. А это либо транзакции, либо херомантия с процедурами и триггерами. Бяка!

Оказалось, что давно есть относительно простое решение - можно автоинкрементный индекс навесить не на одну колонку, а сразу на две (id сообщения и id группы). Тогда все растет правильно. Почти. Нюанс в том, что если стереть последнее сообщение в группе, то новое будет добавлено с тем же id. Составной автоинкремент, в отличие от обычного, последний “использованный” ID для каждой группы (после удаления строки) хранить не умеет. То есть, пока ничего не удаляем - все хорошо. А если удаляем последнее сообщение в группе - нумерация слетает.

Выход оказался тривиальным - строки не удалять, а только помечать как удаленные. Вроде все пашет. И главное - простой код .