Legacy Issue Number: 5587
Source: Floorboard Software ( Jonathan Biggar)
> REBIND is raised when the current effective RebindPolicy, as described in
> Section 188.8.131.52, interface RebindPolicy on page 22-5, has a value of
> NO_REBIND or NO_RECONNECT and an invocation on a bound object reference results
> in a LocateReply message with status OBJECT_FORWARD or a Reply message with
> status LOCATION_FORWARD. This exception is also raised if the current effective
> RebindPolicy has a value of NO_RECONNECT and a connection must be re-opened.
> The invocation can be retried once the effective RebindPolicy is changed to
> TRANSPARENT or binding is re-established through an invocation of
but 184.108.40.206 says:
> If the effective Policy of this type has a rebind_mode value of NO_REBIND, the
> ORB will raise a REBIND system exception if any rebind handling would cause a
> client-visible change in policies. This could happen under the following
> o The client receives a LocateReply message with an OBJECT_FORWARD status and a
> new IOR that has policy requirements incompatible with the effective policies
> currently in use.
> o The client receives a Reply message with LOCATION_FORWARD status and a new
> IOR that has policy requirements incompatible with the effective policies
> currently in use.
So the former says that a REBIND exception always occurs a rebind is
necessary (and NO_REBIND is set), but the latter says that a REBIND
exception only occurs when any client-visible policies would change.
Which one is correct?
Also, it is not clear from the specification whether an invocation on a
new object reference that has never been bound must fail if RebindMode
is not TRANSPARENT, forcing the use of validate_connection, or whether
the first initial binding can proceed without the use of
Reported: CORBA 3.0 — Tue, 20 Aug 2002 04:00 GMT
Disposition: Resolved — CORBA 3.0.2
Updated: Fri, 6 Mar 2015 20:58 GMT
CORBA3 — Inconsistent definition of semantics of RebindPolicy?
- Key: CORBA3-68
- OMG Task Force: Core 2002 RTF