[dbcp]

["Witte de, Daniel" <D....@nl.steinweg.com>]

Hi List,

 

We are having an issue using commons dbcp to connect to databases
worldwide from our ESB.

We have one in Genua, Italy which has an unstable connection, at times
when we try to insert records in that database our local linux server
starts tcp re-transmitting messages because the database server did not
receive the packages correctly.

After about 16 minutes the package gets trough and the database insert
would have happened anyway however the requestor application requesting
the database insert at that location only allows our ESB 90 seconds to
do so, and disconnects the requests and assumes failure.

We dumped tpc traffic to a log and analyzed using wireshark telling us
that linux tcp tried to retransmit the message every 2 minutes (default)
and finally got through to the database in Genua after 16 minutes.

 

At this point we thought, lets give it some timeouts to stay well within
that time limit:

 

    <bean id="dataSource5"
class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"
lazy-init="true">

        <property name="driverClassName" value="${driverName}" />

        <property name="url" value="${url}" />

        <property name="username" value="${user}"/>

        <property name="password" value="${password}"/>

        <property name="initialSize" value="0"/>

        <property name="maxActive" value="8"/>

        <property name="maxIdle" value="8"/>

        <property name="minIdle" value="0"/>

        <property name="maxWait" value="10000"/>

        <property name="testWhileIdle" value="true"/>

        <property name="testOnBorrow" value="true"/>

        <property name="validationQuery" value="SELECT COUNT(*) FROM
SYSTABLES"/>

        <property name="validationQueryTimeout" value="5"/>

    </bean>

 

As you can see we have max wait defined, when that didn't work we added
testWhileIdle and testOnBorrow, and when we still experienced issues we
also added validationQuery and validationQueryTimeout.

The odd thing is that non of the timeouts kick in, it keeps trying until
the connection is restored, and the tries to report success back to the
requestor, but because the synchronous transaction is broken reports an
error at that time.

This issue is very frustrating because we feel somehow it should not be
possible, when we do a local test blocking a test database inbound with:
iptables -A INPUT -s [ipaddress] -j DROP things work as expected giving
us a timeout after 5 seconds, reporting failure back to the requestor
(as it should)

 

Does anyone have the slightest idea what is going wrong here?

Any input would be greatly appreciated.

 

Regards,

 

Daniel

---
The General Terms and Conditions of C. Steinweg-Handelsveem B.V. ("Steinweg Conditions") are applicable to all our activities. Depending on the nature of the activities general sectoral terms and conditions are also declared applicable in these Steinweg Conditions. Chartering of vessels or other means of transport are exclusively performed in our capacity of forwarder ("expediteur"), even if these services are performed pursuant to a transport order. These Steinweg Conditions confer exclusive jurisdiction to the Court of Rotterdam.

The Steinweg Conditions can be downloaded from http://www.steinweg.com/conditions/, they are filed at the registry of the Court of Rotterdam and at request they will be sent to you free of charge. 

Company Registration No. 24001123 
---