Looks fine. Approved for jdk8u-dev.
regards,
Sean.
On 08/07/2016 18:04, Ivan Gerasimov wrote:
Hello!
I'd like to backport this fix into jdk8u-dev.
The fix is essentially the same as in jdk9, but could not be used
verbatim because of the code derivation.
Bug: https://bugs.openjdk.java.net/br
On 7/9/2016 10:43 PM, chris...@zoulas.com wrote:
> On Jul 9, 10:22am, xuelei@oracle.com (Xuelei Fan) wrote:
> -- Subject: Code Review Request, JDK-8159009: Useless ExemptionMechanism.fina
>
> | Hi,
> |
> | Please review this simple code cleanup:
> |
> |http://cr.openjdk.java.net/~xuelei/
On Jul 9, 10:22am, xuelei@oracle.com (Xuelei Fan) wrote:
-- Subject: Code Review Request, JDK-8159009: Useless ExemptionMechanism.fina
| Hi,
|
| Please review this simple code cleanup:
|
|http://cr.openjdk.java.net/~xuelei/8159009/webrev.00/
|
| The javax.crypto.ExemptionMechanism.final
I am not sure. If in the first round a free port is chosen for UDP but it's not
available for TCP, how can we avoid the same port being chosen again in the 2nd
round? The DatagramSocket object is closed in the catch block and the port
number is reclaimed by the OS. Will the OS reuse it immediate
Hi Max,
On 2016/7/8 16:19, Wang Weijun wrote:
The reason a loop is needed here is that both the TCT and UDP servers must
listen on the same port number. With your fix, the TCP server finds a free
port, but I doubt if it's free for the UDP server.
Yes, it's possible that the port still be occup
