BiTel

да, точно ..работает

это похоже проблема перловых библиотек работы с сетью ..Либо надо как-то manad переписать

А мы уж подумали, что сетевыми настройками вы в ЛС обменялись.

Какой код ошибки при закрытии сокета?

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

И вы, в качестве walkaround'a увеличили размер системного буфера, дабы манад думал, что уже все отправилось и не расстраивался?
Если мы сумеем воспроизвести такую картинку на фреебсд, попробуем подкрутить манад.

Надо просто перед началом отправки данных запросить макс. размер у системы, и нарезать свои данные на кусочки если они превышают системный размер.

Или отказаться от неблокирующих сетевых вызовов.

Наш шлюз "удержал" примерно 6800 договоров.
После модификации manad - все 10000.
Суть патча - включить блокирующий режим сокета перед отправкой данных обратно на биллинг.

достаточно убрать вызовы команд nonbloсk и все

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

За основу серверной части, взят пример один в один из учебника по перл, там и было всё сделано на неблокирующих сокетах. Так что думаю что над этим никто не задумывался при реализации.

Этого никто не знает ..Более того, никто не помнит кто это делал вначале

убрал неблокирующие вызовы , выложил новую сборку обоих манадов

можно ссылку на эти сборки?

_________________

using billingClient.BGB 4.6;
using server.Ubuntu server 9.10;
using server.Java "1.6.0_15";
using client.Ubuntu 10.04;

в документации по manad для freebsd