[SNMP4J] Closing DefaultUdpTransportMapping takes up to socketTimeout to complete

[Andy O'Neill]

I am using v1.8.2. I noticed that that when calling close on my Snmp 
instance, it will take up to whatever was set to the socket timeout for 
the DefaultUdpTransportMapping to complete. (And possibly hang forever 
if the timeout was set to 0.) A simple example is demonstrated below:
----
import org.snmp4j.Snmp;
import org.snmp4j.transport.DefaultUdpTransportMapping;

public class Test {
    public static void main(String[] args) throws Exception {
        DefaultUdpTransportMapping transport = new 
DefaultUdpTransportMapping();
        Snmp snmp = new Snmp(transport);
        snmp.listen();
        long start = System.currentTimeMillis();
        // Wait just a moment to make sure listening thread is running
        Thread.sleep(50);
        snmp.close();
        long stop = System.currentTimeMillis();
        System.out.println("First run took " + (stop - start) + " 
milliseconds");
        
        transport = new DefaultUdpTransportMapping();
        transport.setSocketTimeout(15000);
        snmp = new Snmp(transport);
        snmp.listen();
        start = System.currentTimeMillis();
        // Wait just a moment to make sure listening thread is running
        Thread.sleep(50);
        snmp.close();
        stop = System.currentTimeMillis();
        System.out.println("Second run took " + (stop - start) + " 
milliseconds");
    }
}
----
Sample output is:
First run took 1008 milliseconds
Second run took 15006 milliseconds

Looking at the close() method for DefaultUdpTransportMapping, it looks 
like interrupt() and join() are called on the thread with the socket. I 
believe the intention of interrupt() is to cause the socket.receive(...) 
operation to be interrupted, but this is not true. I think the only way 
to interrupt a blocking socket like this is to call close() on the socket.

Am I missing something? Thanks for any help.