C++ CORBA DII issues

Question

Could all those CORBA experts out there please help me with this one.

I have a multithreaded application with some code that sends a message to a server and waits for a response back. I can see that the server is sending the response back however the application doesnt seem to receive it.

Heres part of my code.

  // Create a request object for the given message
  msg.request = serverRef->_request("receiveCoreMessageVia");
  msg.request->set_return_type (CORBA::_tc_short);

  msg.request->add_in_arg() <<= msg.sourceGateway;
  msg.request->add_in_arg() <<= msg.octetSeq;

  msg.request->send_deferred();

  ...
  // The following code is in a while loop in a different function. It uses the request reference to check the response.
  // Check if the request has completed
  if (!msg->request->poll_response())
  {
    clssendlog << debug << "Polling..." << endl;

    return false; // No response yet
  }

  // Get the returned result
  clssendlog << debug << "Get response..." << endl;
  msg->request->get_response();

  clssendlog << debug << "Reading the returned response value" << endl;
  CORBA::Short tmp = 0;
  msg->request->return_value () >>= tmp;

The result is that it keeps saying Polling even if the server responds. This is a basic DII invocation and I am actually testing the code on ACE/TAO 5.7.9. This exact code works perfectly on omniORB 4.1.4. However, I really want this to work on ACE/TAO.

Answer 1

I'm not too sure about this but it appears to me that you will exit this function if the first poll response fails. Then, when you come back in, you'll send another message (with the send_deferred() call), independent from the first.

That means that, unless you strike it lucky and a response appears before you call poll_response(), you'll always get a polling message.

Answer 2

Managed to fix by changing object reference from _ptr to _var. I wrote a small test application to verify this. After changing the pointer type its behaving as expected serving the responses. So the problem was getting the initial reference to the interface.