Вчера обнаружил что у меня где-то тормозятся события от мыши, а потом выстреливают пачкой. Тормозятся довольно ощутимо. Но занят был другим делом и не стал вникать. Сегодня все пропало, как не было.
Тем временем переделал серверную часть. В место программного поллинга сокетов (который грузил сервер на 100% просто так, ничего не делая) использовал SocketChannel. Серверу сразу полегчало. Вполне возможно что и мышиные проблемы росли оттудова же. Поскольку сервер и клиент на одной машине.
Отдельного доброго слова заслуживают разработчики ObjectInputStream. Конструктор, блокирующий исполнение - это что-то новое в моей небогатой практике. Они не могли потерпеть и выполнить первое чтение из InputStream при первом обращении к функции чтения? Пока писал, понял почему не захотели. Функций чтения у ObjectInputStream много, не хотелось им в каждую вставлять лишнюю строчку вида if (!checkInputHeader()) throw new BadDataException().
А вот авторам этих двух туториалов настоящее спасибо:
Действительно помогли разобраться
Вообще с этими объектными потоками проблем было больше чем с каналами. Очевидно им не хватает простой, очевидной вещи - буфферизации и функции isObjectReady(). Т.е. при вызове этой функции из потока должен считываться очередной объект, и если он полностью считан, то возвращается true. Если нет - естественно false. А готовый объект, или некие промежуточные недочитанные данные ложатся в буфер для дальнейшей обработки.
Короче - нужен неблокирующий аналог ObjectInputStream.readObject, иначе весь поллинг идет к чертям собачьим. Сейчас я выкрутился через ж, но по хорошему нужно переписать ObjectInputStream по своему
Комментариев нет:
Отправить комментарий