Ticket #206 (closed defect: fixed)
An object that is marshaled both as host and client is not interpreted correctly by the marshaler
Reported by: | jasper | Owned by: | jasper |
---|---|---|---|
Priority: | major | Milestone: | Phase III WP1 |
Component: | COBIA Marshalling | Version: | 1.2.0.14 |
Keywords: | Cc: |
Description
The marshaler keeps track of client and host objects by wrapping it in
- a PMCCobiaClientProxyObject that implements ICobiaMarshalClientProxy (derives from CobiaClientProxyObject?)
- a PMECobiaClientProxyObject that implements ICobiaMarshalClientProxy (derives from CobiaClientProxyObject?)
- a CobiaHostProxyObject? (on the PME side) that implements ICobiaMarshalHostProxy
- a PMCCobiaHostProxyObject that implements ICobiaMarshalHostProxy (derives from CobiaHostProxyObject?)
When creating a reference to the object on the other side for a method call, it must be decided whether the object is a local object or a remote object. The marshaler decides that it is a client object in case the QI for ICobiaMarshalClientProxy succeeds.
This mostly works ok.
Except when the object is both. In the situation where an object is remote from the point of view of one marshaler, but local from the point of view of another marshaler, the object is seen as remote. Which is correct for one of the marshalers but not the other.
This scenario happens only when an object is passed over two marshalers (incoming and outgoing). The problem is detected in newly added out-of-process marshaling unit tests, where the setup of the out-of-process PMC creates another PMC (in-process) to do the actual work (the test setup is similar to the OutOfProcessPMC where an out of process PMC implementation borrows the in-process IdealThermoPPM rather than implementing its own), and in the creation process the CreationFlags? are not properly passed, causing the OutOfProcess? marshaler to erroneously wrap the object in a second marshaler. The problematic object is a PME object that is passed to the out-of-process PMC host, where it appears as a remote object, and then passed once more to the in-process marshaler where it appears as a local object - so it is both a remote and local object.
Even though the nature of the setup is resulting of an error in the test implementation, a scenario in which a foreign object can be both remote and local is conceivable, so this is an actual bug.
The solution should consist of checking, instead of "am I a remote object", that "am I a remote object to this marshaler".
Fixed in commit [1f73abfd0dc7b9f248d249e970de7a2c6dacd404]