Если фабрика входящих соединений имеет значение TcpNetServerConnectionFactory, вы можете просто использовать ThreadAffinityClientConnectionFactory, поскольку каждое входящее соединение получает свой собственный поток.
Вы бы позвонили getConnection().Это свяжет соединение с потоком (и вы можете получить идентификатор соединения из него), но вам не нужно отображать заголовок в этом направлении из-за близости потока, вам нужно будет отобразить только путь возврата.
Имейте в виду, однако, если ThreadAffinityClientConnectionFactory обнаружит, что соединение было закрыто, оно создаст новое.Таким образом, вы можете звонить getConnection() в вашем маппере при каждом вызове.Тем не менее, условия гонки все равно будут присутствовать, поэтому вам также может потребоваться прослушать TcpConnectionCloseEvent s и TcpConnectionOpenEvent s.
Если вы используете NIO на входящем или иначе передаете работу другомупотоки через исполнителя, это не сработает.
В этом случае вам понадобится ваша собственная фабрика оберточных соединений - вы можете использовать ThreadAffinityClientConnectionFactory в качестве модели, но вместо хранения соединений в ThreadLocal, вы бы сохранили их на карте.Но вам все равно понадобится ThreadLocal (установить upstream при каждом вызове), чтобы сообщить фабрике, какое соединение следует раздавать, когда адаптер запрашивает его.
Однако есть хитрость, о которой вы должны знать..
На фабрике соединений существует свойство singleUse.Это служит 2 целям;
- Во-первых, он сообщает фабрике, что каждый раз при каждом вызове
getConnection() вместо одного общего общего соединения - секунда создается новое соединение, он сообщает входящему адаптеру о закрытии.соединение после получения ответа
Таким образом, хитрость заключается в том, что вам нужно singleUse=true на реальном заводе (чтобы оно давало вам новое соединение каждый раз, когда вызывается getConnection()), но singleUse=falseна фабрике упаковки, чтобы адаптеры не закрывали соединение.
Я предлагаю вам взглянуть на фабрику соединений ThreadAffinityClientConnectionFactory и CachingClientConnectionFactory, чтобы увидеть, как они работают.
Вероятно, нам следуетрассмотрите возможность разбиения этого на два логических значения;мы могли бы также сделать некоторые улучшения, чтобы избежать необходимости в локальном потоке, добавив что-то вроде getConnection(String connectionId) к клиентскому заводскому контракту и заставив фабрику искать соединение внутри себя;но это потребует работы с адаптерами.
Я пойму проблему для этого и посмотрю, сможем ли мы получить что-то в 5.2.
Скорее длинный ответ, но я надеюсь, что это имеет смысл.