YAMI server throwing yami::yami_logic_error

[Alin Stanciu]

Could someone explain what the following error could be caused by:

"Connection closed on server: tcp://<ip address:port>

terminate called after throwing an instance of 'yami::yami_logic_error' 

 what(): No such index."

Particularly, what does "No such index" in the error response refer to? Could it be that the "value" is invalid?

Thanks in advance.

[Maciej Sobczak]

Could someone explain what the following error could be caused by:

"Connection closed on server: tcp://<ip address:port>

terminate called after throwing an instance of 'yami::yami_logic_error' 

 what(): No such index."

Note that program termination might indicate that you do not have a try/catch structure to properly handle exceptions and some exception propagated up the stack, outside of the main() function.

The yami_logic_error exception is thrown when there is a problem in how the library was used by the program (contrary to yami_runtime_error, which is about I/O errors that are outside of the program's control). In other words, this exception was designed to indicate logic bugs in the program and "No such index" means that you have tried to refer to something that was already removed or has never existed.

Is it possible for you to reduce your program to some minimal version that still has the same problem? Can you post it here?

-- 

Maciej Sobczak * http://www.inspirel.com

[Alin Stanciu]

Thank you for the response. My program becomes non-responsive after a while (several hours)  once the wait_for_transmission() function is called. Would a try/catch structure ensure that any errors/problems in calling wait_for_transmission() are trapped so my program doesn't hang? I already have a try/catch in place for yami_runtime_error, but not for yami_logic_error. Example code:

try

{

yami::parameters params;

uuid_generate( aUuid );

char lAux[ char_for_uuid ];

uuid_unparse( aUuid, lAux );

params.set_string( "Guid", lAux );

ConnectionClientEventCallbacks lCallbacks;

yami::agent lYamiClient( lCallbacks );

auto_ptr<yami::outgoing_message> config_om( lYamiClient.send( server_address, server_name, function_to_send, params) );

        config_om->wait_for_transmission(); // After several hours of uninterrupted operation, this is were my program seems to hang. Perhaps a try/catch around this call?

// Check the state of config_om

if( true == sent )

{

   yami::message_state lState = config_om->get_state();

   if ( (yami::rejected == lState) || (yami::abandoned == lState))

     {

       cout << "function_to_send: ERROR" << endl;

       lResult = false;

   }

}

else

{

   cout << "function_to_send timed out" << endl;

}

// Wait for the Server to send Results back

yami::parameters lRetValParams;

if( true == lResult )

{

   lRetValParams = WaitForMessage( aUuid, 100, lResult);

}

// Process the Results (if any) and send them back to the client application

if( true == lResult )

{

}

}

// YAMI4 runtime errors (e.g. due to resource constraints or communication problems)

catch(const yami::yami_runtime_error & aYamiException)

{

        //Push the YAMI

cout << "Yami runtime error in function_to_send): " << aYamiException.what() << endl;

stringstream lAux;

lAux << aYamiException.what() << " (runtime) in  function_to_send";

throw yami::yami_runtime_error(lAux.str().c_str());

}

}

Many thanks

[Alin Stanciu]

Also, since the intention is to send a message and receive a response, should "wait_for_completion()" be used rather than "wait_for_transmission()"? Is there any value in using a timeout?

Many thanks in advance.

[Maciej Sobczak]

Thank you for the response. My program becomes non-responsive after a while (several hours)  once the wait_for_transmission() function is called. Would a try/catch structure ensure that any errors/problems in calling wait_for_transmission() are trapped so my program doesn't hang?

No, a try/catch structure will help you handle exceptions, but will not ensure that any function call will not hang.
The call to wait_for_transmission() hangs if the outgoing queue or outgoing socket buffer is full and is not being consumed - this is usually the case if the receiver (a server) does not consume incoming messages fast enough or even not at all. Can you check, on the server side, if the messages are properly received?
Using a timeout parameter will allow you to break the waiting, but will not help overall if the buffer is full.
 
Calling the wait_for_completion() (with or without a timeout) makes sense if the message is replied to by the server - the wait_for_completion() function returns when the response is sent back. You can use this approach to see if the problem persists, but note that if you process messages in a simple loop, then you will not benefit from the ability of the system to keep multiple messages in the pipeline and the total throughput might be slower.
In any case, try to diagnose this on the receiver side as well, you will see if the messages are properly transmitted.