Drv/Ip/TcpClientSocket.cpp prints errors when intentionally not connected.

[timcanham]

F´ Version	3.0.0
Affected Component	`Drv/Ip/TcpClientSocket.cpp

---

Problem Description

A description of the problem with sufficient detail to understand the issue.

How to Reproduce

1. Start deployment with no host/port
2. Look at stdout
3. You will see endlessly repeated:

[ERROR] Failed to send framed data: 0
[ERROR] Failed to send framed data: 0
[ERROR] Failed to send framed data: 0

Expected Behavior

If the socket has not been configured, this call should return SEND_OK:

Drv::SendStatus TcpClientComponentImpl::send_handler(const NATIVE_INT_TYPE portNum, Fw::Buffer& fwBuffer) {
    Drv::SocketIpStatus status = m_socket.send(fwBuffer.getData(), fwBuffer.getSize());
    // Always return the buffer
    deallocate_out(0, fwBuffer);
    if ((status == SOCK_DISCONNECTED) || (status == SOCK_INTERRUPTED_TRY_AGAIN)) {
        return SendStatus::SEND_RETRY;
    } else if (status != SOCK_SUCCESS) {
        return SendStatus::SEND_ERROR;
    }
    return SendStatus::SEND_OK;
}

Specifically, this call is printing the message based on the above error code:

void FramerComponentImpl ::send(Fw::Buffer& outgoing) {
    Drv::SendStatus sendStatus = framedOut_out(0, outgoing);
    if (sendStatus.e != Drv::SendStatus::SEND_OK) {
        // Note: if there is a data sending problem, an EVR likely wouldn't make it down. Log the issue in hopes that
        // someone will see it.
        Fw::Logger::logMsg("[ERROR] Failed to send framed data: %d\n", sendStatus.e);
    }
}

[LeStarch]

We should set this up to log once, and then only log again when it transitions from OK to error again.

[LeStarch]

@timcanham with the addition of the ComQueue component to Ref this is now fixed. Data queues up and you get a minimal set of EVRs indicating overflow. The incessant printing now only happens if you choose to skip the ComQueue/ComStub pairing.

Can we close or is there more we want to discuss here?

[timcanham]

Are the overflow events for the ComQueue throttled? If not, will it do the same thing eventually?

[LeStarch]

@timcanham yes it is throttled. Is this sufficient?

[thomas-bc]

Fixed in #2950