TRANSIENT or COMM_FAILURE
Serguei Kolos
I have an impression that Corba 3.0.2 provides very week specification
for the circumstances in which TRANSIENT and COMM_FAILURE exceptions
have to be thrown.
For example consider the following situation:
Client invokes two times the same remote method on the same server.
The first invocation is successful. Then the server dies before the
client
started the second invocation. Does CORBA spec. provide a clear
requirement
to which exception must be thrown?
Practically I noticed that different ORBs throw different exceptions in
this case.
Is it a problem with some of them or the CORBA spec. does not allow to relay
on a certain behavior in this case?
Any comments are greatly appreciated.
Cheers,
Sergei
CORBA 3.0.2 says:
4.12.3.5 COMM_FAILURE This exception is raised if communication is lost
while an
operation is in progress, after the request was sent by the client, but
before the
reply from the server has been returned to the client.
4.12.3.18 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.
Michi Henning
"Serguei Kolos" <Sergue...@cern.ch> wrote in message
news:3FAFC0DA...@cern.ch...
>
> I have an impression that Corba 3.0.2 provides very week specification
> for the circumstances in which TRANSIENT and COMM_FAILURE exceptions
> have to be thrown.
Well, those words were written by me some years ago (for version 2.1, from
memory). Prior to that, the spec had words about the system exceptions
at all.
> For example consider the following situation:
> Client invokes two times the same remote method on the same server.
> The first invocation is successful. Then the server dies before the
> client
> started the second invocation. Does CORBA spec. provide a clear
> requirement
> to which exception must be thrown?
TRANSIENT. It means "nobody home".
> Practically I noticed that different ORBs throw different exceptions in
> this case.
You mean they throw COMM_FAILURE? In that case, the ORB isn't
compliant. COMM_FAILURE is specifically reserved for the case
where communication is lost while the client has the reply to a
request outstanding. This alerts the client to the fact that the request
may have been received (and processed) by the server, or, alternatively,
that the connection may have failed just after the client sent the request,
but before the server received it, meaning that the request wasn't processed.
If indeed, as you say, the server goes down *between* invocations, not during
an invocation, the correct exception is TRANSIENT.
Cheers,
Michi.
--
Michi Henning Ph: +61 4 1118-2700
ZeroC, Inc. http://www.zeroc.com
Jonathan Biggar
> If indeed, as you say, the server goes down *between* invocations, not during
> an invocation, the correct exception is TRANSIENT.
For some definition of "between". Since we are talking about
distributed invocation here, time lags between the server crashing and
the client ORB noticing can affect whether a TRANSIENT or COMM_FAILURE
exception is returned.
Some ORBs don't notice that a connection to a server has died until the
next time a request is sent. Such an ORB is likely to return COMM_FAILURE.
--
Jon Biggar
Floorboard Software
j...@floorboard.com
j...@biggar.org
Michi Henning
news:E3Vrb.9690$aX....@newssvr25.news.prodigy.com...
> Michi Henning wrote:
> > If indeed, as you say, the server goes down *between* invocations, not
during
> > an invocation, the correct exception is TRANSIENT.
>
> For some definition of "between". Since we are talking about
> distributed invocation here, time lags between the server crashing and
> the client ORB noticing can affect whether a TRANSIENT or COMM_FAILURE
> exception is returned.
>
> Some ORBs don't notice that a connection to a server has died until the
> next time a request is sent. Such an ORB is likely to return COMM_FAILURE.
Hmmm... Not sure I understand. If a client has a reply outstanding on a
connection and
tries to read the reply and gets an error from the socket, the correct
exception
is COMM_FAILURE. Now, if another thread uses the same connection and realizes
that the connection is broken when it tries to send a request, the correct
exception is
TRANSIENT, but just for that thread. (The other thread should still raise
COMM_FAILURE when *it* tries to read its reply.)
So, I don't see, off-hand, how something that should be COMM_FAILURE could
be reported as TRANSIENT.
Duncan Grisby
Michi Henning <mi...@triodia.com> wrote:
>"Jonathan Biggar" <j...@floorboard.com> wrote in message
>> Some ORBs don't notice that a connection to a server has died until the
>> next time a request is sent. Such an ORB is likely to return COMM_FAILURE.
>
>Hmmm... Not sure I understand. If a client has a reply outstanding on
>a connection and tries to read the reply and gets an error from the
>socket, the correct exception is COMM_FAILURE. Now, if another thread
>uses the same connection and realizes that the connection is broken
>when it tries to send a request, the correct exception is TRANSIENT,
>but just for that thread. (The other thread should still raise
>COMM_FAILURE when *it* tries to read its reply.)
>
>So, I don't see, off-hand, how something that should be COMM_FAILURE
>could be reported as TRANSIENT.
That's not what Jon said. The situation is that what you might expect
to be a TRANSIENT ends up as a COMM_FAILURE. If a client is reusing an
existing network connection, it is quite possible for it to do the
socket send for an entire request without any errors. It is only when
it tries to do a socket receive that it is told about the error. In
that situation, it is quite proper for the ORB to throw COMM_FAILURE.
Cheers,
Duncan.
--
-- Duncan Grisby --
-- dun...@grisby.org --
-- http://www.grisby.org --
Ke Jin
> Michi Henning wrote:
> > If indeed, as you say, the server goes down *between* invocations, not during
> > an invocation, the correct exception is TRANSIENT.
>
> For some definition of "between". Since we are talking about
> distributed invocation here, time lags between the server crashing and
> the client ORB noticing can affect whether a TRANSIENT or COMM_FAILURE
> exception is returned.
>
> Some ORBs don't notice that a connection to a server has died until the
> next time a request is sent. Such an ORB is likely to return COMM_FAILURE.
Yes, if server is _crashed_, client may see either TRANSIENT or
COMM_FAILURE. If server went down _gracefully_ and sent out the GIOP
CloseConnection (and assume received by clients), client applications
will see TRANSIENT exception only. B/c, in this case, client will fail
on reestablishing connection rather than on receiving reply.
Regards,
Ke
Michi Henning
news:co5sb.2661$Tc2....@newsfep4-glfd.server.ntli.net...
>
> That's not what Jon said. The situation is that what you might expect
> to be a TRANSIENT ends up as a COMM_FAILURE. If a client is reusing an
> existing network connection, it is quite possible for it to do the
> socket send for an entire request without any errors. It is only when
> it tries to do a socket receive that it is told about the error. In
> that situation, it is quite proper for the ORB to throw COMM_FAILURE.
Right. OK, misunderstanding on my part. I agree. if the send on the socket
completes and the client realizes that the server is down only when it tries
to read the reply, COMM_FAILURE will result, even though the server
went down "in between" invocations. From the client's perspective, that's
exactly the right thing though, because the client cannot know whether
the request was received by the server or not.