timeout value

When the Source (not destination) is in a TCP conversation with the Shadow there are many times when the Shadow must communicate which Journal data it needs to the Source. The common times are when a Shadow starts, resumes or retries to transmit Journal data. At these times a Shadow must tell the Source things like at what point it has got up to within the Journals and what it needs next from the Source. This means that the Source will be READing (listening) from the port (TCP connection between the two), waiting for the destination to give it a start point in the Journal. Any READ will have a timeout limit, because in most Operating Systems a TCP connection will have a "KeepAlive" setting (so the connection doesn't ever timeout) and we don't want the READ to wait forever and cause the Shadow to HANG. The timeout for these Source-to-Shadow TCP Reads is 10 seconds, so if there is no response from the Source "request" to the Shadow for information then the Shadow routine is directed to record a nothing read error (as you have seen) and will then retry this part of the conversation.

In your case the destination Shadow is taking too long to send the Journal position or another piece of information that the Source needs before it transmits any Journal data. It could be that one of the processes on the destination Shadow instance is hanging or being held up, so it can't actually hand over the start point or something like it.