Description
Methods such as
aeron/aeron-client/src/main/c/aeron_socket.c
Line 137 in 8d8096d
EAGAIN, EWOULDBLOCK, ECONNREFUSED, EINTR. This results in methods that check for short sends with logic equivalent to 0 <= result && bytes_sent < (int64_t)iov.iov_len erroneously reporting a short send. This is notably problematic for aeron_network_publication_setup_message_check and aeron_network_publication_heartbeat_message_check, as ECONNREFUSED is a likely status in both cases when using multicast.
aeron/aeron-driver/src/main/c/aeron_network_publication.c
Lines 471 to 477 in bf3af7c
aeron/aeron-driver/src/main/c/aeron_network_publication.c
Lines 526 to 533 in bf3af7c
I'm happy to submit a patch for this, but I'd appreciate guidance on the preferred approach to fixing it. Threading errno through the relevant functions, e.g.
aeron_network_publication_setup_message_check
aeron_network_publication_do_send
aeron_send_channel_send
aeron_udp_channel_transport_send
aeron_udp_channel_transport_send_connected
aeron_send
will break many function signatures, and changing the semantics of the send and receive return codes is similarly evasive. Checking errno at the caller as part of the guard clauses around calls to aeron_counter_get(*->short_sends_counter) would work, as I don't see anything in the call stack clobbering errno, but it's a little fragile. Reclassifying short sends as 0 <= result && bytes_sent > 0 && bytes_sent < (int64_t)iov.iov_len would work, but trade false positives for false negatives.