Bidirectional vs. Callback

[vit]

Hi there,

I am relatively new to ICE, so please bear with me.
I checked all your examples located under /demo/ice and I have to state that they are couple of things I am still not clear about.
They are as follows:
1. In case of a bidirectional invocation, you implement servant as a Thread (run() method is provided), but in case of a Callback such thread does not exist. Why?
2. In one of the postings regarding bidirectional invocation you mentioned and I quote "...A better solution would be to modify the CallbackSenderI::run() method implementation to not lock the mutex while invoking on the callback receiver proxy" . Would you mind giving an example of that?
3. I am having a problem with bidirectional implementation where calls are dispatched to the wrong clients. Well, I have to say that the initial implementation was synchronous and it worked fine. Later we decided to switch to bidirectional mode (due to firewall considerations) and we adjusted the source code accordingly to get Receiver's proxy via Identity, but no further modifications have been made. Are we doing something wrong?

[benoit]

Hi,

Originally Posted by vit

Hi there,

I am relatively new to ICE, so please bear with me.
I checked all your examples located under /demo/ice and I have to state that they are couple of things I am still not clear about.
They are as follows:
1. In case of a bidirectional invocation, you implement servant as a Thread (run() method is provided), but in case of a Callback such thread does not exist. Why?

There are no particular reasons other than it's not the same demo .

There are no technical reasons that would prevent implementing the callback demo using bi-directional connections (and without a special callback sender thread).

2. In one of the postings regarding bidirectional invocation you mentioned and I quote "...A better solution would be to modify the CallbackSenderI::run() method implementation to not lock the mutex while invoking on the callback receiver proxy" . Would you mind giving an example of that?

The demo used to invoke callback() on the callback receiver with the mutex locked. The demo was fixed since to invoke on the callback receivers with the mutex released, this way other threads can lock the mutex while the sender thread invokes on the callback receivers.

3. I am having a problem with bidirectional implementation where calls are dispatched to the wrong clients. Well, I have to say that the initial implementation was synchronous and it worked fine. Later we decided to switch to bidirectional mode (due to firewall considerations) and we adjusted the source code accordingly to get Receiver's proxy via Identity, but no further modifications have been made. Are we doing something wrong?

It's hard to say without more information. How do you create the proxies for the client callback objects? Could you perhaps post the client and server code? I'll be happy to take a look to see what could be wrong.

Cheers,
Benoit.

[vit]

Here's the server method that gets invoked from the client:
public void remoteCommand( Ice.Identity __identity,
String __command,
Ice.Current __current) throws DakotaException {

_logger.info( "Received command: " + __command );

CallbackReceiverPrx callbackreceiverprx;
Ice.ObjectPrx proxy = null;

try {

proxy = __current.con.createProxy( __identity );
callbackreceiverprx = CallbackReceiverPrxHelper.uncheckedCast( proxy );
String line;

_process = Runtime.getRuntime().exec( __command );
System.out.println("Executing " + __command );
_input = new BufferedReader( new InputStreamReader( _process.getInputStream()) );
String str = null;
while (( str = _input.readLine()) != null) {
callbackreceiverprx.stdout( str + '\n');
}
_logger.info("Process exit value: " + _process.waitFor() );


} catch (Exception e) {

System.out.println("ERROR: " + e.getMessage() );
System.out.println("Caused by: " + Arrays.toString( proxy.ice_getEndpoints() ));
e.printStackTrace();
throw setException( e.getMessage() );

} finally {
try {
callbackreceiverprx = null;
cleanOut( _process, _input);
}catch( Exception ignored ){}

}
}

[vit]

You said "...The demo was fixed since to invoke on the callback receivers with the mutex released". Where do I find this new example? Can you point me out?

[vit]

Here's a snapshot from the client:

Ice.ObjectPrx proxy = communicator.stringToProxy("XXXXXXX:default -h localhost -p 10040");
CallbackPrx callbackprx = CallbackPrxHelper.checkedCast( proxy );

Ice.ObjectAdapter adapter = communicator.createObjectAdapter("");
Ice.Identity ident = new Ice.Identity();
ident.name = Ice.Util.generateUUID();
ident.category = "";
adapter.add(new CallbackReceiverI(), ident);
adapter.activate();
callbackprx.ice_getConnection().setAdapter(adapter );
callbackprx.remoteUnixCommandBidir(ident, _command );
communicator.waitForShutdown();

[benoit]

Originally Posted by vit

You said "...The demo was fixed since to invoke on the callback receivers with the mutex released". Where do I find this new example? Can you point me out?

Checkout the demo/Ice/bidir demo from your Ice 3.2.1 release. The implementation of the CallbackSenderI.run method calls the callback() method outside the synchronization block. This wasn't the case in some previous releases.

Your code looks fine. You could replace the following:

Ice.Identity ident = new Ice.Identity();
ident.name = Ice.Util.generateUUID();
ident.category = "";
adapter.add(new CallbackReceiverI(), ident);

with:

adapter.addWithUUID(new CallbackReceiverI());

Also, proxy.ice_getEndpoints() on a "fixed" proxy (i.e.: a proxy created using Ice.Connection.createProxy()) always returns an empty array of endpoints (a fixed proxy doesn't have any endpoints, it's bound to the incoming connection).

In any case, I don't see how callbacks to clients could get mixed up. Your client is calling remoteUnixCommandBidir but you only provided the implementation of remoteCommand, is this the same method? To investigate this, I suggest that you add an "Ice.Identity" parameter to your stdout() method and pass back the receiver identity to print it in the callback receiver implementation and ensure it's correct.

Cheers,
Benoit.

[matthew]

As a further note the best, and often fastest way, to get help on an issue is to post a complete self-contained compilable example that demonstrates your problem. Posting code-snippets, in 99% of cases, doesn't help track down the problem.