Worrying intermittent run-time problem

I have the following intermittent run-time error that is worrying me:

My open method in Bank_impl.cc basically looks like this:


Account_ptr
Bank_implpen( const char* name, const char* password )
throw(::CORBA:ystemException,
::Bank::NotAuthorized)
{
Account_ptr ret_ptr;
.
.
.


cout << "Returning requested account: " << name << endl;
myAccount = i->second;
cout << "name : " << i->first << endl;
cout << "password: " << myAccount.pass << endl;
cout << "balance : " << myAccount.pAccount->balance() << endl;

ret_ptr = myAccount.pAccount;
return ret_ptr;
}


From the above code you can see that I am dumping the status of the
requested account to the server screen at run-time. BE ASSURED THAT
THIS ALWAYS WORKS PROPERLY. This assures you that the variables
are properly assigned.

One of the instructions in my client requests reference to the
previously opened account but I OFTEN get the following error
when running the client:

Access existing account...
IDLmg.org/CORBA/TRANSIENT:1.0 (0, maybe-completed)

both the server and client terminating abnormally.
I have put OFTEN in capitals because it sometimes works properly
as intended, especially when I restart the server.

Can anyone please tell me what's wrong?
What I can say specifically is that everything works properly up
to the point where the Bank_implpen method returns the ret_val
pointer to the client, but the ret_val pointer is not being
reliably returned and I don't know why.

I've done a bit of research into the CORBA definition of Transient exception and come up with the following:



"TRANSIENT indicates that the ORB attempted to reach an object and failed. It is not an indication that an object does not exist. Instead, it simply means that no further determination of an object's status was possible because it could not be reached. This exception is raised if an attempt to establish a connection fails, for example, because the server or the implementation repository is down."

TRANSIENT is thrown so that the client is made known of the problems in reaching the remote object. The problem could be due to firewall, network glitch or something else beside the remote object's absence. Since the ORB can not explicitly determine the cause of the problem, CORBA specifies to throw TRANSIENT.

The CORBA TRANSIENT exception, which is thrown by the server to signal a transient failure that might not occur again if the request is retried. It contains a minor code, which gives more detailed information about what caused the exception, and a completion status. It may also contain a string describing the exception.


TRANSIENT constructor detail:
public TRANSIENT(int minor,CompletionStatus completed)
Constructs a TRANSIENT exception with the specified minor code and completion status.
Parameters:
minor - the minor code
completed - the completion status

The minor code for the Exception object:
The minor field is an implementation-specific value used by the ORB to
identify the exception. The BEA Tuxedo minor field definitions can be
found in the file orbminor.h. (I tried accessing the BEA website, but you need a password to access this file).

Getting back to my original problem, can anyone tell me what the mico CORBA minor code 0 means?

Does it crash on the second time that you call open for an account? I do not really know the assignment question this year, but maybe try:

return Account::_duplicate(ret_ptr);

Transient errors often get thrown when the communication with the server is disrupted. A minor code 0 simply means no minor code has been set.

No, not necessarily the second time. It seems to be random, but getting more frequent. What does _duplicate() do?

I tried your suggestion and it worked like a charm! Please let me know your reasoning behind this fix and thanks very much. Intermittent problems can be very difficult to solve and I hope this one does not re-surface later on.

When you pass the account to the Orb to marshall back to the client, it takes control of that variable and delete it when it is finished with it, after doing the marshalling. This is so that you can construct an arbitrary complex reply and then it will be deleted by the Orb after use to prevent a memory leak in the server. It has to work that way, because you never get a chance to call delete after the member function has returned.

The problem is that if you give the Orb the instance from your map (or whatever you use to store it), that you want to keep permanently, that instance gets deleted and when another call comes it, you give back something that is already deleted, causing a crash. The _duplicate call hands back a copy to the orb, so your original stays safe in the map.

Thanks Gustav. Good to hear you're still around.

Pleasure. And good luck with the new job. I think the students are going to miss you badly.