Disclaimer: This repository is a git-svn mirror of the project found at http://java.net/projects/jsip whose original repository is developed collaboratively by the Advanced Networking Technologies Division at the National Institute of Standards and Technology (NIST) - an agency of the United States Department of Commerce and by a community of individual and enterprise contributors. TeleStax, Inc. will perform some productization work, new features experimentation branches, etc for its TelScale jSIP product that doesn't concern the community from the main repository hence this git repository.
We have a scenario where binding an IP address fails with IOException in createListeningPoint. The reason for that is that the network device with the given IP address is not there for some reason.
Our application has a mechanismn to retry binding after some time repeatedly because the missing network device will be added after some time and the next try to bind may be successful.
This will not work with the current implementation.
I've found out that the next try to call createListeningPoint() will not fail anymore although the network device is still not there and the IP address is therefore still not bindable. Even in the case where the IP address is bindable on the second try, a bind will not take place and we will end up in a listening point that does not work.
This happens because the implementation of createListeningPoint() stores the key for the listening point to a map called listeningPoints before the bind takes place (in messageProcessor.start()).
An IOExecption will be thrown but the map entry will not be removed. The next time createListeningPoint is called, it will find this map entry to returns it without starting the message processor.
My suggested fix is to store the listening point key to the map after having successfully called the messageProcessor.start() method to avoid having an orphaned entry in the listening points map.
We have a scenario where binding an IP address fails with IOException in createListeningPoint. The reason for that is that the network device with the given IP address is not there for some reason. Our application has a mechanismn to retry binding after some time repeatedly because the missing network device will be added after some time and the next try to bind may be successful. This will not work with the current implementation. I've found out that the next try to call createListeningPoint() will not fail anymore although the network device is still not there and the IP address is therefore still not bindable. Even in the case where the IP address is bindable on the second try, a bind will not take place and we will end up in a listening point that does not work. This happens because the implementation of createListeningPoint() stores the key for the listening point to a map called listeningPoints before the bind takes place (in messageProcessor.start()). An IOExecption will be thrown but the map entry will not be removed. The next time createListeningPoint is called, it will find this map entry to returns it without starting the message processor.
My suggested fix is to store the listening point key to the map after having successfully called the messageProcessor.start() method to avoid having an orphaned entry in the listening points map.