[omniORB] omniORB.installTransientExceptionHandler -> python abort?

[Ridgway, Richard (London)]

Hi,

I am using omniORB 4.1.0 , omniORBpy 3.0, python 2.5 on rhel4.0 gcc 3.3
or solaris9.
I experimented recently with the exception handler functions, with mixed
results.

def transientRetryFunction(cookie, retries, exc):
print "\nRetrying transient %s:%i\n" % (repr(exc),retries)
return False
_cookie = "don't care for now"
omniORB.installTransientExceptionHandler(_cookie,
transientRetryFunction)

I expected the simple return False to allow the application to carry on
as would be expected with no exception handler installed at all. Indeed,
this is what I see for my more general SystemExceptionHandler.
However when I encounter a LOCATION_FORWARD exception, the world ends.
In the output below (with trace on 10 - 50 doesn't give much more use
that I can tell), ServerObj is an (persistent) object reference pulled
out of names, which I know is dead and can't be restarted.

ServerObj._narrow(ServerInterface)

omniORB: AsyncInvoker: thread id = 2 has started. Total threads = 1
omniORB: Creating ref to remote:
key<....NUP...9........RootPOA.OnDemandRisk.MultiServer.453.1H.AdminPOA.
........MultiSrvAdmin>
target id : IDL:omg.org/CORBA/Object:1.0
most derived id:
omniORB: GIOP::LOCATION_FORWARD -- retry request.
omniORB: Unable to open new connection: giop:tcp:elonxapodrp453:53305
omniORB: throw giopStream::CommFailure from
giopStream.cc:1148(0,NO,TRANSIENT_ConnectFailed)
omniORB: Reverting object reference to original profile

Retrying transient CORBA.TRANSIENT(omniORB.TRANSIENT_FailedOnForwarded,
CORBA.COMPLETED_NO):0

Abort


And the python interpreter dies without a trace. The relevant section
from the documentation is:
When a TRANSIENT exception occurs, the function is called, passing the
cookie object, a count of how many times the operation has been retried,
and the TRANSIENT exception object itself. If the function returns true,
the operation is retried; if it returns false, the original exception is
raised in the application. In the case of a TRANSIENT exception due to a
failed location forward, the exception propagated to the application is
the original exception that caused the TRANSIENT (e.g. a COMM_FAILURE or
OBJECT_NOT_EXIST), rather than the TRANSIENT exception.

Anyone have any ideas what I am doing wrong / if this functionality
works as I am expecting / what further I can do to pin the problem down
and fix it?


Thanks,

Richard
--------------------------------------------------------

If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Click here for important additional terms relating to this e-mail. http://www.ml.com/email_terms/
--------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20070131/5cfc9d14/attachment.htm

[Duncan Grisby]

Post by Ridgway, Richard (London)
I experimented recently with the exception handler functions, with mixed
results.
print "\nRetrying transient %s:%i\n" % (repr(exc),retries)
return False
_cookie = "don't care for now"
omniORB.installTransientExceptionHandler(_cookie,
transientRetryFunction)

[...]

Post by Ridgway, Richard (London)
omniORB: Reverting object reference to original profile
Retrying transient CORBA.TRANSIENT(omniORB.TRANSIENT_FailedOnForwarded,
CORBA.COMPLETED_NO):0
Abort

Can you run inside gdb and get a stack trace of where it dies? And
please run with traceLevel 25 and send me the log.

Cheers,

Duncan.