Results 1 to 3 of 3

Thread: Limitation of collocation

  1. #1
    chaukmean is offline Registered User
    Join Date
    Nov 2003
    Posts
    8

    Limitation of collocation

    Hi,

    I read the ICE documentation and it seems that ICE doesn't actually support collocation :
    - if two objects share the same Communicator, the "communication" bypasses the object adaptor, thus the client thread is used to execute the servant code... This also prevents the use of AMI and AMH ... It's a very restrictive or extreme collocation strategy
    - if two objects use different Communicators, the communication behaves like the objects are hosted by different processes with the implied marshalling/demarshalling ... There is no collocation at all here.

    Am I right ?
    Do you intend to support a more usual collocation strategy that bypasses the marshalling/demarshalling process but still uses the object adaptor ?

    Happy New Year to Zero C team !

    Chauk-Mean.

  2. #2
    marc's Avatar
    marc is offline ZeroC Staff
    Name: Marc Laukien
    Organization: ZeroC, Inc.
    Project: The Internet Communications Engine
    Join Date
    Feb 2003
    Location
    Florida
    Posts
    1,860
    Two communicators are a way to completely separate two programs that use Ice in one executable. I think it's only logical that in such case, there is no collocation optimization, as collocation optimization can have side effects (as described in the manual). If you do not wish to completely separate two Ice programs in one executable, just use only one communicator. This then allows you to use collocation optimization.

    AMI and AMD rely on certain threading properties which are provided by our thread pools. E.g., if you send a request with AMI, then such request cannot be dispatched in the caller thread (as it's done with collocation optimization), but must be dispatched and the result be returned in a different thread (otherwise it wouldn't be asynchronous). The thread pool, however, is strongly coupled with the network layer for efficiency. It's a leader-follower model, with the leader always waiting in select(), and is therefore not suitable for dispatching collocation-optimized AMI callbacks. We could add a special thread pool just for such cases. However, this would increase complexity in Ice, as we would introduce a second collocation optimizaton mode, with different threading properties.

  3. #3
    chaukmean is offline Registered User
    Join Date
    Nov 2003
    Posts
    8
    Thanks for the reply.

    I completely understand that you take care to keep the implementation of ICE as simple as possible. Nevertheless, efficiency and performance may be worth increasing the complexity of ICE code .
    In the context of component based development, it is useful to deploy some components as a local assembly (collocation of connected components) in order to improve performance.
    Having the full power of ICE (AMI, AMD) but without the collocation optimization doesn't seem to be a solution in this context.
    Likewise having a collocation optimization but without the full power of ICE doesn't seem to be good solution either.

    Anyway, I like ICE.

    Chauk-Mean.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Using Collocation with IceGrid
    By anuragkumars in forum Help Center
    Replies: 1
    Last Post: 08-07-2009, 04:37 AM
  2. default collocation optmization
    By Greenhippo in forum Help Center
    Replies: 3
    Last Post: 07-14-2007, 04:52 AM
  3. collocation optimization per object
    By jli125 in forum Help Center
    Replies: 1
    Last Post: 07-10-2007, 11:12 PM
  4. Collocation
    By mwilson in forum Help Center
    Replies: 1
    Last Post: 07-28-2005, 04:31 PM
  5. Replies: 3
    Last Post: 11-05-2003, 11:29 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •