[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] catching exceptions with publishOneway
Michael Atighetchi wrote:
I'm using publishOney to publish messages asynchronously to a
xmlblaster node. When the connection to the node goes down, I see the
following stack trace in the client
org.omg.CORBA.TRANSIENT: Retries exceeded, couldn't reconnect to xxx.xxx.xxx.xxx:56061 vmcid: 0x0 minor code: 0 completed: No
as the stack trace shows us it is deeply nested inside a JacORB thread.
In other words: The exception never reaches xmlBlaster code for
oneway CORBA invocations. So we have no chance to detect this.
The client dispatcher framework handles the rest well:
o If you wait some seconds the ping() will fail
o The fail safe code changes to POLLING
o When the server is available again it will reconnect to xmlBlaster
-> You loose silently all oneway messages until the ping detects a problem
-> In POLLING state the client side queue will storte savely all oneway
-> All queued oneway publish messages will be sent on reconnect
Try playing (with newest cvs):
java org.xmlBlaster.Main -call[core] true
java javaclients.HelloWorldPublish -numPublish 100 -oneway true
and shutdown/restart the server during interactive publishing
I didn't check the CORBA spec if hiding the exception of oneway errors
is OK or if there are any configuration possibilities.
PS: If you use the SOCKET protocol it works fine.
However, neither reachedDead for this connection is called, nor
does the publishOneway call throw an exception.
Could we change the connection handling of publishOneway to be exactly
the same as for publish, i.e. throwing exceptions and calling