how to trace the problem about in or out parameter?

huaciom

I defined one ice file as below:
module Sample
{
interface test
{
void doRequest(string request,out string response, out ByteSeq responseIMG);
}
}

and I create one server like this:

class CTestImpl:public ::Sample::test
{
void doRequest(string request,out string response, out ByteSeq responseIMG)
{ cout << request << endl;
//other server implement omitted
}
}

then in the main function, I create one servant and atached to the adapter and activated,it's all right;

but in the client ,I created one proxy of the servant and invoke the method
,the server has no any affect.

My question is whether the in or out parameter have any effect,I know if there is only one in parameter the application run fine;

I run both server and client in the same host,and Ice2.1

Help me!

benoit

The parameters shouldn't matter, if you invoke this method on the proxy in the client, you should see the tracing if the invocation succeeds (i.e.: no exceptions).

It's difficult to say what could be wrong without more information. You could try to enable Ice tracing to see if the client is invoking the method and if the server correctly receives it. You can do this by setting the property Ice.Trace.Protocol to 1.

Benoit.

huaciom

It's a strange problem!

I want to ask you one question that if there is Exception when I run the Server which throw an exception which is caused by other DLLs and omit it and the server is run fine,then I invoke one method of ICE,would the execption has any affect?

I write a very simple implement of Server just to print out the IN parameter which is string type,the server is run fine ,and the invoke is no problem.

In my Client,I trace that the invoke catch such an exception as below:
::Ice::NonRepeatable ,when will the Ice throw such exception


below is the result of Trace in the client:

matthew

Sorry, I'm don't understand your question.

"unknown c++ exception" means exactly that... your server side threw an exception that was unknown to the Ice runtime. Quite often under Windows this type of exception is actually an access violation. An access violation is actually a structured exception which is caught by a "catch(...)". One way to fine out what is actually causing the access violation is to run the server in the debugger. Then in Debug/Exceptions change the default behavior of "access violation" from "stop if not handled" to "stop always".

Regards, Matthew