ну мне-то ты чего рассказываешь? расскажи тем, кто видит в gpl3 проблему.

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

Мужик, люди видят проблему в том, что админ из России :)

Но это никакого отношения к фактам не имеет

я рассказываю о том, что считают другие люди.
мне лично вообще без разницы, пока мне не сказал об обратном юрист работодателя.

даже ссылку не я принес

На самом деле идея была конечно в «зарабатываешь деньги - поделись», но потом внезапно стало ясно, что сервисы генерят больше денег чем коробочное по

ну и да, общаться о тонкостях гнушных лицензий и их преимуществе над прочими свободными - это уровень лора, а я себя не на этой помойке нашел

Я на лоре даже админов найти больше не могу :(((

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

Ты как раз описал сценарий появления agpl

Для сервисов есть AGPL 🌚

ЛОР, конечно, ослаб, но называть его помойкой как-то слишком

вообще не понял сейчас аппломба .. ты может контекст упустил, речь была о том, что использовать gpl совт без распространения можно

ты там искал эникейщика вроде? ща скину одному знакомому ссыль.

доброго вам времени суток)

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

ситуация —
спустя некоторое количество походов в базу,
эрланг пул "забивается",
запрос возвращает {error,timeout}

потыкал настройки pgbouncer,
проверил с pgbench,
итого получается войти в postgresql через pgbouncer,
когда на сайте {error,timeout} —
получается с помощью

psql -d databasename -p 6432 -U username

(постгрес слушает 5432, pgbouncer 6432)

значит у меня "ситуевина" не в настройках pgbouncer
+ один сайт с базой ок работает, в то время как у второго пул "забился"

потыкал tsung,
после перезапуска приложения (сайта с пулом),
с настройкой 5 минут и +5 пользователей в секунду —
первый раз так — пул еще не "забился",
второй раз —
где-то на минуте в консоль эрланга уже начинают падать

query timeout ...
get_sock timeout ...

дальше уже каждый запрос к постгресу возвращает

{error,timeout}

это при запуске пула

epgsql_pool:start(my_pool, 10, 50, Params)

заметил отличие:
в описании https://github.com/wgnet/epgsql_pool
пишет —
You can get all possible parameters and their values with call epgsql_pool:get_settings/0:

3> epgsql_pool:get_settings().
 #{connection_timeout => 10000,
   keep_alive_timeout => 60000,
   max_reconnect_timeout => 5000,
   min_reconnect_timeout => 100,
   pooler_get_worker_timeout => 10000,
   pooler_max_queue => 100,
   query_timeout => 10000}

у меня же с этой командой получается такое

#{connect_listener => undefined,
  connection_timeout => 10000,
  disconnect_listener => undefined,
  keep_alive_timeout => 60000,
  max_reconnect_timeout => 5000,
  min_reconnect_timeout => 100,
  pooler_get_worker_timeout => 10000,
  pooler_max_queue => 1000,
  query_timeout => 3000,
  transaction_timeout => 10000}

правильно понимаю, что disconnect_listener не должен быть undefined?

мне сюда смотреть-изучать —
https://github.com/wgnet/epgsql_pool/blob/f9746139d28de6b0652cc5375e319d9b4c59045a/src/epgsql_test.erl#L15

https://github.com/wgnet/epgsql_pool/blob/f9746139d28de6b0652cc5375e319d9b4c59045a/src/epgsql_pool_worker.erl#L120
?

upd. не, не понял, там же просто сообщения выводятся, и все

где же, и почему, может "забиваться" пул?

с одной стороны можно и дальше "костилем подпереть" — увеличить количество соединений, и раз в год(или пол-года) перезапускать аппликуху(как и раньше),
да хочется наконец полностью разобраться, и без костилей, с другой стороны :)

upd2. понял, проще всего убивать пул
epgsql_pool:stop(my_pool)
когда появляется {error,timeout}
и стартовать пул заново

прошу прощения за многобукафф

psql -d databasename -p 6432 -U username

query timeout ...
get_sock timeout ...

{error,timeout}

epgsql_pool:start(my_pool, 10, 50, Params)

3> epgsql_pool:get_settings().
 #{connection_timeout => 10000,
   keep_alive_timeout => 60000,
   max_reconnect_timeout => 5000,
   min_reconnect_timeout => 100,
   pooler_get_worker_timeout => 10000,
   pooler_max_queue => 100,
   query_timeout => 10000}

#{connect_listener => undefined,
  connection_timeout => 10000,
  disconnect_listener => undefined,
  keep_alive_timeout => 60000,
  max_reconnect_timeout => 5000,
  min_reconnect_timeout => 100,
  pooler_get_worker_timeout => 10000,
  pooler_max_queue => 1000,
  query_timeout => 3000,
  transaction_timeout => 10000}

Может у вас все воркеры заняты незакрытыми транзакциями.
Или на вытягивания ответов от бд.

psql -d databasename -p 6432 -U username

query timeout ...
get_sock timeout ...

{error,timeout}

epgsql_pool:start(my_pool, 10, 50, Params)

3> epgsql_pool:get_settings().
 #{connection_timeout => 10000,
   keep_alive_timeout => 60000,
   max_reconnect_timeout => 5000,
   min_reconnect_timeout => 100,
   pooler_get_worker_timeout => 10000,
   pooler_max_queue => 100,
   query_timeout => 10000}

#{connect_listener => undefined,
  connection_timeout => 10000,
  disconnect_listener => undefined,
  keep_alive_timeout => 60000,
  max_reconnect_timeout => 5000,
  min_reconnect_timeout => 100,
  pooler_get_worker_timeout => 10000,
  pooler_max_queue => 1000,
  query_timeout => 3000,
  transaction_timeout => 10000}

Да, скорее всего воркеры не возвращаются в пул. Это может быть, например, из-за исключения внутри транзакции, которое не перехватывается.

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

+ у вчерашнем тесте небыло транзакций

чего гадать - мерять надо,
метрики на количество воркеров, гистограмма времени
запроса итд

ерланг или ликсир? а то можно попробовать какой-нибудь jaeger open trace. мне помогало. полосочки посмотреть