[omniORB] Lost one-way calls

[Zurek, Jan]

Duncan,

thanks for your reply. We are a little confused because in on one of =
the
e-mails in the archive Sai-Lai Lo states the following:

"Oneway call is just like request-reply except that there is no reply =
from
the other end. If the ORB detects the connection is broken when the =
request
is being sent, it does the following:

If the broken connection is a cache connection, i.e. it has been used
previously for other invocations, the ORB would quietly try to =
reconnect
to the remote address space and retry the request again.

If the reconnect fails, it would throw a COMM_FAILURE. ..."

What is correct now? The caller of a one-way "function" should be able =
to
recognize that the call could not be submitted and therefore the caller
should be able to perform some action (e.g. throw an exception).

Regards
Jan Zurek
Dresdner Kleinwort Benson
J=FCrgen-Ponto-Platz 1
D-60301 Frankfurt am Main
Tel: +49 69 263 6318
Fax: +49 69 263 11454
e-mail: Jan.Zurek@dresdner-bank.com


> -----Original Message-----
> From:	Duncan Grisby [SMTP:dgrisby@uk.research.att.com]
> Sent:	22 April 1999 13:39
> To:	omniorb-list@orl.co.uk
> Subject:	Re: [omniORB] Lost one-way calls=20
>=20
> On Thursday 22 April, "Neykov, Plamen" wrote:
>=20
> > We are developing a distributed calculation engine and the problem
> occurs
> > during the assignment of calculation tasks.=20
> > A coordination server, which knows the whole task is assigning =
pieces of
> > work to the calculation servers which are ready with their prior =
task.
> The
> > assignment is realized through a one-way call. Some of the =
calc-servers
> > after completing the task don't receive the call from the =
coordination
> > server, but the coordinator doesn't get any exception after the =
one-way
> call
> > (we would expect COMM_FAILURE to be thrown). As far as we can see, =
some
> of
> > the one-way calls are simply lost ...
>=20
> Oneway calls cannot throw any sort of exceptions, so if they fail you
> never get to know about it. In fact, there are no guarantees that a
> oneway call will actually happen. That said, omniORB does try quite
> hard to send oneway calls -- can you give more details about what you
> are doing when this problem occurs?  Also, is there a good reason why
> you're using oneways rather than normal operations?
>=20
> Cheers,
>=20
> Duncan.
>=20
> --=20
>  -- Duncan Grisby  \  Research Engineer  --
>   -- AT&T Laboratories Cambridge          --
>    -- http://www.uk.research.att.com/~dpg1 --