Close race condition in removeSocket

[rkday]

While doing some testing, I (rarely) saw a NullPointerException on line 110 of IOHandler.java. From a quick code read, I think I can see a race condition here: socketCreationMap.get(key) could return non-null for Thread 1 on line 109, Thread 2 could then reach line 111 and call socketCreationMap.remove(key), and it could return null on 110 for Thread 1.

This should fix that issue.

[rkday]

Stack trace for the issue, by the way:

java.lang.NullPointerException
    at gov.nist.javax.sip.stack.IOHandler.removeSocket(IOHandler.java:110)
    at gov.nist.javax.sip.stack.TCPMessageChannel.close(TCPMessageChannel.java:197)
    at gov.nist.javax.sip.stack.ConnectionOrientedMessageChannel.close(ConnectionOrientedMessageChannel.java:126)
    at gov.nist.javax.sip.stack.TCPMessageProcessor.stop(TCPMessageProcessor.java:172)
    at gov.nist.javax.sip.stack.SIPTransactionStack.removeMessageProcessor(SIPTransactionStack.java:2398)
    at gov.nist.javax.sip.stack.SIPTransactionStack.stopStack(SIPTransactionStack.java:2086)
    at gov.nist.javax.sip.SipStackImpl.stop(SipStackImpl.java:1711)

[jaimecasero]

This kinf of preliminar checking use to be done to enhance performance. After initial light checking, it needs to recheck in proper critical section, which its what is missing here, hence NPE