Agent.send often does not send nor return any value

Feature Requests & Bug Reports
1

Hello,

I am using the RETURN_ON_ERROR timeout policy. My callback in my connect calls looks like the code below. The sendStateLog() function is one that simply logs the send error according to the code returned. What sometimes happens is that the device logs the “Connecting due to: SendData” and does not log anything else until it disconnects on connect timeout. Sometimes this timeout also extends for some mysterious 9 minutes (the timeout was put to 5 seconds). But what concerns me the most is this apparent blocking while sending. So the Agent’s on.device() callback is not firing, the sendStateLog() function is not logging anything and I assume that it is because the agent.send() is not returning any value nor sending any message.

This only happens sometimes. Most of the times it goes as it should.

Do you know anything about this?

Thank you truly for your attention!

`function connectCallback(state){
local connectReasons = split(nv.connectReasons, “&&”);
local afterSendSleep = true;
local updatedConnectReasons = “”;
local failedAnySend = false;

if(state == SERVER_CONNECTED){
    for(local i = 0; i < connectReasons.len(); i++){
        server.log("Connecting due to: " + connectReasons[i]);
        
        if(connectReasons[i] == "SendData"){
            if(sendStateLog(agent.send("EGGYHourlyFridgeData", nv.bulkdataString)) == 0){
                server.log("Accumulated data sent to agent!");
            
                //Flushes the bulk data string
                nv.bulkdataString = "";
            }
            else{
                failedAnySend = true;
                updatedConnectReasons = updatedConnectReasons + "SendData" + "&&";
            }
        }
        
        [...]

    }
    
    //Updates connect reasons
    //(Flushes it if no error occurred)
    nv.connectReasons = updatedConnectReasons;
    
    //If all sents were successfull
    if(!failedAnySend)
        nv.failedConnect = false;
    else
        nv.failedConnect = true;
        
    if(afterSendSleep){
        server.disconnect();
        
        //Waits 1000ms just to assure the sending of the agent messages before deep sleeping
        imp.sleep(1);
        
        imp.onidle(function(){ imp.deepsleepfor(nv.sleepPeriod) });
    }
}
else{
    nv.failedConnect = true;
    
    server.disconnect();
    imp.onidle(function(){ imp.deepsleepfor(nv.sleepPeriod) });
}

}
`

2

What you describe does sound exactly like the behaviour without RETURN_ON_ERROR – are you certain that this policy is always set before attempting any agent.send()s?

Peter

3

I just understood that this is even stranger, because the line after sending, in which a String is flushed, is run when the no-sending phenomena happens. It seems that only the server related functions (server.log() and agent.send()) cannot communicate with the server, although the state is set to SERVER_CONNECTED and the agent.send is returning 0 for SUCCESS (proven because its flushing that String). Please help!

4

Peter,

Thank you for your feedback. I am sure. Is the first thing to be done in every awakening.

5

Can’t stress strongly enough that if you rely on RETURN_ON_ERROR, put it as the FIRST line in your code. We’ve seen many people have issues where a class instantiation or other side effect was causing server traffic which executed with the default SUSPEND_ON_ERROR policy and was confusing the customer.

You may also want to use WAIT_FOR_ACK so a success code means the packet has made it to the imp servers. This will reduce throughput, though.

6

SERVER_CONNECTED is not a real-time indicator of the link being ok; a TCP link is assumed to be up even when no traffic is flowing. The link may in fact be down already (eg packet loss or a NAT table entry in the path to the servers may now be preventing communication).

7

If you want to be certain the agent (or, at least, the server) has received the data, you could use WAIT_FOR_ACK. Otherwise it’s possible that sometimes the send returns 0 for success, the data is in the imp’s output buffers, and then the connection drops and the data is lost. Or to make even more certain than that, flush the string on receipt of an acknowledgement message from the agent.

Peter