1

It does not crash so there is no core to analyse. It simply stops.

I have experimented multiple times. It stops exactly after 2 hours.
OS : qnx6.5.0
LIBs : ZeroMQ and Protobuf

I just have a single thread, it looks something like this :

dummyFrontEnd::dummyFrontEnd():context(1),socket(context,ZMQ_PUB) {

}

void dummyFrontEnd::Init()
{
    socket.connect("tcp://127.0.0.1:5555");
    cout << "Connecting .... " << endl;
}

void dummyFrontEnd::SendCANalyserTable(const std::string& filename)
{
    ...

    zmq::message_t create_values( protoTable.ByteSizeLong()
                                + sizeof(uint16_t)
                                  );

    *((uint16_t*)create_values.data()) = TABLEMSG_ID;       // ID

    protoTable.SerializeToArray( create_values.data()
                               + sizeof(uint16_t),
                                 protoTable.ByteSizeLong()
                                 );

    try {
            socket.send(create_values,ZMQ_NOBLOCK);
           }
    catch (int e){
            std::cout << "SPD exception e : "
                      <<  e
                      << std::endl;
           }

    protoTable.clear_columnvalues();
    usleep(1);

    }

}

void main(){
...

...
  while(1) {
    if (arguments.canalyser_filename != "") {
        dmyFntEnd.SendCANalyserTable(arguments.canalyser_filename);

        if (arguments.verbose) {
            cout << "DummyFrontEnd"
                 << "completed sending CANalyser table"
                 <<  endl;
        }
    }
  }
...
...
}
user3666197
  • 1
  • 6
  • 50
  • 92
user6868820
  • 75
  • 1
  • 1
  • 7
  • Would you mind to post the ZeroMQ version ( major#, minor#, patch# ). Thank you. – user3666197 May 26 '20 at 14:05
  • You could be reaching the "high water mark" because you are sending data faster than it is received. Or it is no longer received at all. I would expect your program to block or hang in this case, not "stop", unless you have some custom terminate or unhandled exception handler. – rveerd May 26 '20 at 14:51
  • Do you have a `while(1)` loop in your thread **and** in your `main()`? – rveerd May 26 '20 at 14:52
  • 2
    @rveerd the hypothesis with **`SND_HWM`** is not supported from the published ZeroMQ API documentation. The **`ZMQ_PUB`** Archetype simply drops any new items **`.send()`**-ing tries to enqueue, so no, this is not the root cause of the problem. – user3666197 May 26 '20 at 16:36
  • 1
    @ user3666197 thanks for replying to my questions , it gave me more clarity .ZeroMQ version is 4.3.2 – user6868820 May 27 '20 at 04:52
  • @rveerd data speed is 1 data per millisecond. at the end when I check the receiver log , its received all the data transmitted. I have a while (1) only in my main – user6868820 May 27 '20 at 04:58
  • 1
    @user3666197 I found the root cause for this problem. I was ssh'ing into the qnx box off VPN. and used to start the binary as ./flightrecorder This command got bound to my terminal session. I was loosing my session every two hours . so the binary also stopped . Now I am running it as ./flightrecorder & --> this unassociate the binary with my terminal session . With the above change , the binary is running for many hours now this link was helpful . https://unix.stackexchange.com/questions/4004/how-can-i-run-a-command-which-will-survive-terminal-close Thanks – user6868820 May 27 '20 at 12:58
  • 1
    **`nohup process &`** got me `:o)` **Anyway, stay tuned** ... the last case with connection drop I recall with GSM-operator mobile modem connections, they forgot to delete a configuration line for 120 minute forced connection-drop for data-services. That obscure setting was required by the TELCO-regulator to "protect" voice-service consumers ( ROFL ) ... *somewhere deep back in 90-ies* – user3666197 May 27 '20 at 14:00

0 Answers0