Patch for adding SO_REUSEPORT socket option

[Lu, Yingqi]

Hi Alan,

Sorry for the confusion. Let me be more detailed on the issue.

In previous version of the patch, I added an initializer in SocketImpl.java to load the libnet.so since the isReusePortAvailable and its native implementation were there. Then, this time, I tried to move isReusePortAvailable and its native implementation declaration down to AbstractPlainSocketImpl therefore I removed the initializer block from SocketImpl.java as well. Inside AbstractPlainSocketImpl.java, there is already an initializer there by default to load the libnet.so. I was assuming it would just load the library and the code would work. However, I found out the initializer inside the AbstractPlainSocketimpl does not execute. After I add back the initializer to SocketImpl, the code works.

My question is: Is this a reasonable approach to do it by keeping both initializers? 

Thanks very much for your help,
Lucy

-----Original Message-----
From: Alan Bateman [mailto:Alan.Bateman at oracle.com] 
Sent: Tuesday, January 05, 2016 8:00 AM
To: Lu, Yingqi <yingqi.lu at intel.com>; Volker Simonis <volker.simonis at gmail.com>
Cc: net-dev at openjdk.java.net; Viswanathan, Sandhya <sandhya.viswanathan at intel.com>; Kharbas, Kishor <kishor.kharbas at intel.com>; Aundhe, Shirish <shirish.aundhe at intel.com>; Kaczmarek, Eric <eric.kaczmarek at intel.com>
Subject: Re: Patch for adding SO_REUSEPORT socket option



On 05/01/2016 04:32, Lu, Yingqi wrote:
> Hi Alan/Volker,
>
> I just found out that the code works by adding the same static block (net library loading) into SocketImpl.java although isReusePortAvailable() is being defined in its subclass AbstractPlainSocketIml.java. I use a print statement to confirm that both static blocks from SocketImpl and AbstractSocketImpl are being executed.
>
> Is this a reasonable way to implement? Or, we can remove the block from AbstractPlainSocketImpl, only have it in SocketImpl if you think that is better. Please let us know.
>
I'm not sure that I understand the issue you are seeing.

When a Socket is created then it will invoke setImpl to set the underlying SocketImpl and that should cause the configured SocketImpl to be loaded and initialize. Are you saying that the initializer isn't run?

BTW:  The reason for putting this into the concrete implementation of SocketImpl is that the Socket API is somewhat pluggable via the legacy (and probably rarely used) SocketImplFactory mechanism. This means that some SocketImpl implementations might know about the new socket options, some might not.

-Alan