Le 10/05/16 16:28, Kristinn Örn Sigurðsson a écrit : > Hi Emmanuel and thank you for your reply. > > Your points are 100% valid and I actually did think about them before I > made the patch. > > However, it's not sufficient to be able to fix the issue at hand (at least > in my case). > > I don't know beforehand what kind of connectivity the machine will be able > to facilitate. So listing all addresses on the machine and/or enforcing the > system to prefer ipv6 is not an option for me (which also has lots of side > effects in terms of other components of the service we are developing).
There are 6 use cases : - the client is IPV4 only and the server is IPV4 only : all is fine, you will only get an IPV4 address whe doing a getAllByName(). - the client is IPV4 and the server is supporting both IPV4/IPV6. If you can't enforce the "java.net.preferIPv6Addresses" option on the client, you know you have to use the server's IPV4 address - the client is IPV4 and the server is only supporting IPV6 : you are screwed... Same but with a client being IPV6 and the server IPV4, 3 more use cases, symetric to the previous ones. Bottom line, you can detect the client's capabilities, and behave accordingly by processing the getAllByName() addresses for the 4 working use cases, without trying to open a connection, right ? > > I would assume others might be in the same situation. We did some > benchmarking and the performance hit by this patch is very minimal. It was > not an extensive burst performance test though. > > Developers that are creating software that needs to be shipped to others as > part of an appliance will most likely run into similar issues as I have - > since I don't know what type of connectivity the appliance will have access. yes, but that can be determinated without having to create multiple connections...
