[SNMP4J] Problem with DefaultTCPTransportMapping

[Brice Fines]

Hi Frank,

First of all, thank you for the quick answer.

I downloaded the snapshot version of SNMP4J 1.10 (dated 07-Oct-2009 22:48 
in your repository) and tried it.
It works, i.e. the SNMP commands over TCP keeps working after a 
communication failure. I hope your fix will make it for the next release 
of SNMP4J (1.10.2?).

I noticed the following, but I suppose it is the correct behavior for 
SNMP4J: if TCP transport is not closed manually after sending a SNMP 
command that failed due to communication failure, the TCP transport cannot 
be recovered until connection timeout occurs (in that case, SNMP commands 
after timeout works OK, but does not work before timeout).

For example, client A is listening for SNMP over TCP, client B is not 
listening for SNMP over TCP.

Without closing manually TCP transport connection, we have (I will provide 
logs for that case in  a separate answer so you can check out it is 
correct):
_send command to client A, result OK
_send command to client B, fail due to connection problem
_send command to client A, fail because TCP transport has not recovered 
yet
_connection timeout occurs for failed client B TCP connection and close 
gracefully
_send command to client A, result OK

Witht closing manually TCP transport connection, we have:
_send command to client A, result OK
_send command to client B, fail due to connection problem
_send command to client A, result OK

To close manually, I use the following code:

try{
//blablabla
final ResponseEvent responseEvent = snmp.send(pdu, target);
//blablabla
}
catch(blablabla){
//blablabla
}
finally {
                if (transportMapping instanceof TcpTransportMapping) {
                        try {
                                ((TcpTransportMapping) 
transportMapping).close(target
                                                .getAddress());
                        } catch (IOException exception) {
                                exception.printStackTrace();
                        }
                }
        }

I am now facing another problem (seems to be related with closing TCP 
connection in some environment), but I will try to gather more information 
to report it correctly.

Regards