Основываясь на ответе, который я получил здесь, я начал давать commons-pool серьезный взгляд. Мой последний опыт использования был примерно в 2003 году, вероятно, версия 1.1 или 1.2. Его основной пользователь, DBCP, многими считается ошибочным и его следует избегать.
Кто-нибудь использует общий пул в производстве для написания собственного пула? Какой тип бассейна лучше всего использовать? Я планирую хранить в нем клиентские сокеты TCP.
Есть ли другой универсальный пул, который заменяет его?
Кто-нибудь использует общий пул в производстве для написания собственного пула?
Да, и пул поддерживает TCP-соединения, как вы и предполагали. Он подключен через Spring, поэтому, если вы понимаете конфигурацию Spring:
<bean class="com.company.ConnectionSupplier">
<constructor-arg>
<!-- The ConnectionSupplier wraps an object pool -->
<bean class="org.apache.commons.pool.impl.GenericObjectPool">
<constructor-arg>
<!-- The ObjectPool uses a ConnectionFactory to build new connections -->
<bean class="com.company.ConnectionFactory">
<constructor-arg value="server" />
<constructor-arg value="3000" />
</bean>
</constructor-arg>
<property name="maxActive" value="20" />
<property name="testOnBorrow" value="true" />
</bean>
</constructor-arg>
</bean>
ConnectionFactory расширяет BasePoolableObjectFactory и представляет собой небольшую оболочку SocketFactory.
@First comment: конструктор ConnectionFactory принимает сервер и порт. В переопределенном makeObject() создаются сокеты, которые подключаются к этому серверу и порту. Он возвращает объекты Connection, которые обертывают созданный сокет некоторыми удобными методами для связи через сокет.
Соединение проверяется с помощью своего рода «пинга» или «эха», предоставляемого протоколом, используемым для связи через сокет. Если бы это было недоступно, проверка/проверка соединения на самом деле невозможна, за исключением запроса сокета, был ли он закрыт. В этом случае соединение в пуле было бы недействительным, если бы оно вызвало исключение, и каждый метод, использующий соединения, должен быть готов к такому сбою и попытаться выполнить ту же операцию с другим соединением.
Вы должны проверить, что создание экземпляра стоит дороже или выборка из пула. Потому что единственная допустимая ситуация для использования пула — первая.
Вы заглядывали в Netty или Apache MINA? Они оба будут отслеживать ваши TCP-соединения и должны упростить реализацию любого протокола связи, который будут использовать эти сокеты TCP.
Во-первых, не используйте commons-pool 1.3, у него есть серьезные проблемы с многопоточными приложениями.
Во-вторых, пакет параллелизма Java 5 имеет достойную реализацию пула (см. пример здесь)
Ознакомьтесь с MultiThreadedHttpConnectionManager. это менеджер пула соединений Apache Commons HttpClient, который, вероятно, будет соответствовать вашим потребностям прямо из коробки.
