jxcoderПрактикуется ли такое в реальных проектах?
Нет, конечно же. Все через один Stream и пишут, и читают.

jxcoderя говорю о Thread'ах.

;)

jxcoderМожете дать небольшой пример или как-то более полно раскрыть мысль?
Да, какой ещё пример. Нормальный подход, как для чтения. Нужен, ли отдельный поток на запись - вотпрос открытый. Если у вас буфер для записи есть, то все в него пишут, а один потом читает, то есть смысл. Если же у вас запись - событие не частое, то можно просто через synchronized метод пакеты слать.

jxcoder,

Просто чтобы было? А то как-то слишком просто выходит без этого? Лучше бы тогда на селекторы переписали.

Ну, если у клиентской части в этом есть необходимость, то да. Но я бы не возился с сокетами, а сразу смотрел HTTP/2 и gRPC. Там, скорее всего, это уже реализовано.

jxcoderЯ вот только пока не понимаю как можно после такой смены архитектуры на клиенте сделать вызов блокирующим. То есть в идеале хочется чтобы клиентский код выглядел бы как обычный вызов метода и получение результата. Такое вообще возможно?
Ой. Это вообще довольно большой и спорный вопрос.
То есть у вас клиент уже многопоточный что вы так легко хотите блокировать? Например, если у вас UI, то блокировать основной поток, как бы, не очень хорошо.
Посмотрите как работают Future, ExecutorService в JCU. Можно несколько разных вариантов рассмотреть.
- Блокироваться на пуле сообщений от сервера. Будить все потоки, когда пришел любой ответ. Потоки проверяют наличие их ID. Если такового нет, то засыпают.
- Можно хранить Map<ID, Thread> и будить поток, когда придёт сообщение по ID.
В обоих случаях желательно предусмотреть Timeout.
- Можно извратится и вместо блокировки потока прикрутить continuation. Но в Java внятной реализации для него нет. Тут надо бы смотреть на архитекуру клиента, потому как пока что не понятно как у вас устроена его многопоточность.

andmed, piped stream-ы имеют свои косяки и к теме вопроса вообще никаким боком не относятся.

andmedну ок. мы организовали обработку картинок таким образом. на косяки пока не нарвались
Это объясняет какое отношение оно имеет к первоначальному вопросу. :)
А если серьезно, я тут тоже попробовал на днях. Для экономии памяти. Оказалось, что проще тупо заюзать временные файлы, чем аккуратно обработать все закрытия и убедится что потоки не утекают.