Bug 3047 - Spec non-compliant servant generation
Summary: Spec non-compliant servant generation
Status: NEW
Alias: None
Product: CIAO
Classification: Unclassified
Component: CIAO Container Implementation (show other bugs)
Version: 0.7.8
Hardware: All All
: P3 enhancement
Assignee: DOC Center Support List (internal)
URL:
Depends on:
Blocks: 3253
  Show dependency tree
 
Reported: 2007-08-16 16:37 CDT by Abdul Sowayan
Modified: 2010-04-23 09:00 CDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Abdul Sowayan 2007-08-16 16:37:02 CDT
Hi,

I would appreciatte if you can help me clarifying some doubts about facet objects behavior. The get_facet_name in the component executor returns to the container an facet executor. If in my component executor I have a method implemented like that: 

::App::CCM_IFooFacet_ptr Foo_exec_i::get_foo_facet ()
  {
    // Your code here.
   return ( new IFooFacet_exec_i () );
  }

And If I have two receptacles connected to the same component facet by DAnCE using the following deployment content: 

<connection>
    <name>foo_client1</name>
    <internalEndpoint>
      <portName>foo_facet</portName>
      <kind>Facet</kind>
      <instance>Foo-idd</instance> 
    </internalEndpoint>
    <internalEndpoint>
      <portName>foo_rec</portName>
      <kind>SimplexReceptacle</kind>
      <instance>Client1-idd</instance> 
    </internalEndpoint>
  </connection>

<connection>
    <name>foo_client2</name>
    <internalEndpoint>
      <portName>foo_facet</portName>
      <kind>Facet</kind> 
      <instance>Foo-idd</instance>
    </internalEndpoint>
    <internalEndpoint>
      <portName>foo_rec</portName>
      <kind>SimplexReceptacle</kind>
      <instance>Client2-idd</instance>
    </internalEndpoint>
  </connection>

Will I have two diferent servants for the same facet? Will the reference received by the Client1 receptacle point to a different object than that received by Client2? Will it be created one IfooFacet_exec_i executor for each connection? 

Thank you very much.

Santos
Comment 1 Abdul Sowayan 2007-08-16 16:48:59 CDT
Santos,

I don't know 100% the answer to your question. But I think every time the container get a request to obtain an object reference to the facet, it will call into your get_foo_facet () method.

Personally speaking, I think you're just asking for trouble here. I usually instantiate the facet into a CCM_IFooFacet_var type (say my_foo_var), and do the following in the get_foo_facet() method

::App::CCM_IFooFacet_ptr Foo_exec_i::get_foo_facet ()
  {
    // Your code here.
   return ::App::CCM_IFooFacet::_duplicate(my_foo_var.in());
  }

That way, everything is clear and safe. There will be one instantiation for the Foo Facet.

Thanks,
Abdul
Comment 2 Abdul Sowayan 2007-08-16 16:52:32 CDT
Right now, the servant code caches the first result of get_foo_facet,  
so each connection will be served by a common facet executor.

hth,
/-Will
Comment 3 Abdul Sowayan 2007-08-16 16:53:15 CDT
Hmmm, that seems counter intuitive to me. Is this spec compliant or
CIAO-specific behavior?

Thanks,
Abdul
Comment 4 Abdul Sowayan 2007-08-16 16:53:42 CDT
Insofar as I know, it is an implementation decision - I don't think  
the spec says one way or the other.  It would be a relatively simple  
matter to patch this into CIDLC, if someone were so inclined.

Thanks,
/-Will
Comment 5 Abdul Sowayan 2007-08-16 16:54:09 CDT
Hi Abdul -

To  follow up, I found the following nugget on page 14 of 06-04-01

 > In general, a component instance shall be prepared to return  
object references for facets throughout the instance’s life
 > cycle. A component implementation may, as part of its advertised  
behavior, return a nil object reference as the result of
 > a provide_<name> operation.

This certainly suggests that the intuitive behavior (ie, servant  
queries the executor each time) is the behavior mandated by the spec.

hth,
/-Will
Comment 6 Johnny Willemsen 2007-08-17 02:45:47 CDT
clear target mileston
Comment 7 Johnny Willemsen 2009-07-01 11:50:49 CDT
updated version
Comment 8 Johnny Willemsen 2010-04-23 03:36:38 CDT
Will, what is the status of this?
Comment 9 Johnny Willemsen 2010-04-23 03:36:55 CDT
reassign
Comment 10 Johnny Willemsen 2010-04-23 03:52:58 CDT
It looks we are still only caching, is this something we want to change now?
Comment 11 Will Otte 2010-04-23 08:36:38 CDT
Yes, we still cache.  I think we should update this behavior as part of the servant code rework.  
Comment 12 Johnny Willemsen 2010-04-23 09:00:16 CDT
I will create some devportal tasks for this