Possible network issue

[Robert Engels]

I went back and tested this using Java8 and the same behavior using the synchronous socket stream - so I don’t think it has anything to do with changes made for VT.  

Not sure if this is a recent OSX bug or that is has always been there. Seems like a bad one to me. 

> On Nov 8, 2023, at 12:54 PM, Robert Engels <rengels at ix.netcom.com> wrote:
> 
> My research shows that this is the standard behavior on BSD systems - from which osx is derived. Linux and Solaris have different behavior. 
> 
>>> On Nov 8, 2023, at 11:17 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>>> 
>>> On 08/11/2023 12:38, Robert Engels wrote:
>>> The thing is it never denies the memory request - just delays it. I am fairly certain if I raise the mbufs it will work - similar to lowering the transfer size - but I don’t think this is a viable solution. I think it needs to be resolved in the net layer.
>>> 
>> 
>> There is typically network tuning required when trying to support a large number of connections, more so when dealing with high volumes of short lived connections. It's not clear if the temporarily resource exhaustion is telling us that this system needs tuning, it's macOS bug, or macOS expect all applications doing non-blocking I/O to treat ENOBUFS the same as EAGAIN/EWOULDBLOCK. It wouldn't be hard to have the JDK handle ENOBUFS but we concern is that it would introduce spinning, esp. when the socket is reported as ready for writing. The man pages and documentation is insufficient, kinda need someone from Apple to comment.
>> 
>> -Alan.