From dpg1@grisby.org Fri Nov 29 16:23:54 2002 Received: from pc3-cmbg4-5-cust109 (pc3-cmbg4-5-cust109.cmbg.cable.ntl.com [81.96.74.109]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id gATGNs830524 for ; Fri, 29 Nov 2002 16:23:54 GMT Received: from grisby.org (dpg1@localhost) by pc3-cmbg4-5-cust109 (8.11.2/8.11.2) with ESMTP id gATGNum18341 for ; Fri, 29 Nov 2002 16:23:56 GMT Message-Id: <200211291623.gATGNum18341@pc3-cmbg4-5-cust109> X-Authentication-Warning: pc3-cmbg4-5-cust109: dpg1 owned process doing -bs To: omniorb-dev@omniorb-support.com From: Duncan Grisby Date: Fri, 29 Nov 2002 16:23:56 +0000 Subject: [omniORB-dev] Test Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Hello! -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From kendall@drakealumni.net Wed Jan 22 16:25:36 2003 Received: from sccmmhc01.mchsi.com (sccmmhc01.mchsi.com [204.127.203.183]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0MGPZ815322 for ; Wed, 22 Jan 2003 16:25:36 GMT Received: from drakealumni.net ([12.216.164.190]) by sccmmhc01.mchsi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030122162531.ROTE2338.sccmmhc01.mchsi.com@drakealumni.net> for ; Wed, 22 Jan 2003 16:25:31 +0000 Message-ID: <3E2E6AA7.4070905@drakealumni.net> Date: Wed, 22 Jan 2003 03:55:51 -0600 From: kendall bailey User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: omniorb-dev@omniorb-support.com Content-Type: multipart/mixed; boundary="------------070002050106060109060005" Subject: [omniORB-dev] ImR idl proposal Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --------------070002050106060109060005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Attached is some IDL I've written which covers what I believe has been discussed as capabilities of the portable ImR for use with omniORB. I've verified it compiles, but haven't implemented anything yet. I'm putting this out for comment. Kendall --------------070002050106060109060005 Content-Type: text/plain; name="imr.idl" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="imr.idl" #ifndef omni_implementation_repository_idl_ #define omni_implementation_repository_idl_ /** * Interface of a portable implementation repository. */ module omniImR { typedef string Process_t; interface ProcessManager; interface LoadManager; //------------------------------------------------------------ exception UnknownName { string name; }; //------------------------------------------------------------ exception WrongProcess { }; //------------------------------------------------------------ exception DuplicateName { string name; }; //------------------------------------------------------------ exception BadRegex { }; //------------------------------------------------------------ typedef sequence string_list; //------------------------------------------------------------ /** * defines a name/value pair where the value is * a numeric measure of some load */ struct LoadInfo { string metric; double value; }; typedef sequence LoadInfo_list; //------------------------------------------------------------ /** * defines a simple 1:N mapping of pysical process name to * logical program names. It's likely each program name will * correspond to a POA name. If a process is thought to be * running, it's manager is included, otherwise it is nil. */ struct ProgramMapping { string process_name; ProcessManager manager; string_list program_names; }; typedef sequence ProgramMapping_list; //------------------------------------------------------------ /** * defines a single member of a replica group. */ struct GroupMember { ProcessManager manager; string program; Object ref; }; typedef sequence Group_list; //------------------------------------------------------------ /** * defines a complete group of replicas */ struct GroupMapping { string group_name; Group_list members; }; typedef sequence GroupMapping_list; //------------------------------------------------------------ /** * Allows administration of the ImR. */ interface ImplementationRepositoryAdmin { /** * Make the ImR aware of a physical process that it can * potentially start/stop. * * start_command may have a @imr_ior@ token where * the ImR can plug in it's own IOR on the command line. * * stop_command may have a @pm_ior@ token where the * ProcessManager's ior is placed. */ void registerProcess( in string process_name, in string start_command, in string stop_command ) raises( DuplicateName ); /** add a logical program to a physical process. * This tells the ImR that when requests come in for * the given program, it should ensure the associated * process is started */ void addProgramToProcess( in string process_name, in string program_name ) raises( DuplicateName ); /** * Permenantly remove a program from a process. This * should be done prior to adding the same program to * another process. */ void removeProgramFromProcess( in string process_name, in string program_name ) raises( UnknownName ); /** * Generate a persistent reference. It's not necessary * for the process or program to be registered in advance. * This just generates an appropriate reference for future use * without adding to the persistent state of the ImR at all. */ Object generatePersistent( in string program_name, in string object_name); /** * Find all processes which match the expression and return * all mappings of process -> programs. The format of the * regular expression is an implementation detail. For example, * if the the ImR is implemented in Python, then the Python re * module may be used to match program names. In any case, an * empty string should return the complete process list. * note: an iterator based method may be needed here too, if the * returned list may get very large. */ ProgramMapping_list getMappings( in string process_name_exp) raises( BadRegex ); /** * Find all processes which have a program which matches the * expression. See getMappings() above. Each ProgramMapping * instance should have only those program names which match * the expression listed in the program_names field. To get * full listings, use getMappings(). An empty expression * should return all of the mappings. * note: an iterator based method may be needed here too. */ ProgramMapping_list getProcesses( in string program_name_exp) raises( BadRegex ); /** * Returns the groups which match the expression. * An empty expression should return all groups. */ GroupMapping_list getGroups( in string group_name_exp) raises( BadRegex ); }; //------------------------------------------------------------ interface ImplementationRepository { /** * Upon startup, a process should register. * The ImR returns a process_id that the process should * use to identify itself with each request. */ Process_t rebindProcess( in string process_name, in ProcessManager manager ); /** * Notify the ImR that the process is shutting down */ void unbindProcess( in Process_t process_id); /** * Returns an indirect reference for an object hosted * by the named program. The program must already be * registered with the process. The process * calling this must have notified the ImR that it started * and supply the ImR assigned process_id. * * An ImR implementation is free to handle URI's * of the form corbaloc:::/# * but it isn't required. */ Object makePersistent( in Process_t process_id, in string program_name, in string obj_name ) raises( UnknownName, WrongProcess ); /** * Tells the ImR that a specific object is part of a group of * replicas. If the group doesn't already exist, it will be * created. The indirect reference returned will utilize load * balancing mechanisms when selecting a member of the group. * Group names need to be globally unique, not just within a program * since group members will naturally reside in multiple programs. */ Object addToPersistentGroup( in Process_t process_id, in string program_name, in string group_name, in Object ref) raises( UnknownName, WrongProcess ); }; //------------------------------------------------------------ /** An interface that the ImR uses to manage a running * process. When a process starts, it should supply one of these * to the ImR to enable redirection of requests. */ interface ProcessManager { /** When handling an indirect reference, the ImR uses * this to find the direct reference. Object getDirectReference( in string program_name, in string object_name) raises (UnknownName); /** Each process is assigned an temporary id when it * starts. This should return that id. */ string getProcessId(); /** * Each process must return a LoadManager (or nil if it * doesn't support load balancing) so the ImR can make * load balancing decisions. */ LoadManager getLoadManager(); /** * return a platform dependent description of the processes * identity. This could be as simple as a pid, or as complex * as the result of a detailed Unix "ps" command. * Recommended is something like: * example: "123.456.7.8 1345 myServer" * This makes it easy for tools to show info about all running processes * that the ImR knows about. */ string getProcessInfo(); }; /** * An interface for gathering load information. * some info may be process specific, and some may be host * specific. */ interface LoadManager { /** * get a name for the host. There may be multiple load managers * to a host, and some load data may need to be collected only * once from a particular host. This name allows the ImR to * avoid redundant load queries. */ string getHostName(); /** * The ImR will query the LoadManager for a measure of some * metrics. The LoadManager is responsible for returning * as many as it knows how to in a timely manner. * The ImR implementation will determine what metrics are * important and which are process vs. host level metrics. */ LoadInfo_list queryLoad( in string_list load_metrics ); }; }; #endif --------------070002050106060109060005-- From lockhart@fourpalms.org Wed Jan 22 19:30:19 2003 Received: from myst.fourpalms.org (myst.jpl.nasa.gov [137.78.15.105]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0MJUJ824319 for ; Wed, 22 Jan 2003 19:30:19 GMT Received: from fourpalms.org (localhost.localdomain [127.0.0.1]) by myst.fourpalms.org (Postfix) with ESMTP id 78113346073A; Wed, 22 Jan 2003 14:30:16 -0500 (EST) Message-ID: <3E2EF148.3040505@fourpalms.org> Date: Wed, 22 Jan 2003 11:30:16 -0800 From: Thomas Lockhart Organization: Yes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Duncan Grisby Cc: baileyk@schneider.com, omniorb-dev@omniorb-support.com References: <200301201123.h0KBNWa26062@grisby.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [omniORB-dev] Re: [omniORB] Implementation Repository Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: (redirected to the omniorb-dev mailing list) > I think the ImR should work with flat files, to avoid dependencies on > external applications, and to make it easy to install. It could have > an option to use a database, but I think it should work without one. If it is implemented in python (which sounds good to me; note that omniIDL requires it anyway and we haven't yet demonstrated how to use this with another orb) then we should probably use an XML representation for the flat file since the interfaces ship with python. >>Anyone else interested in this, how should we start to hammer out the IDL >>for the ImR and management interfaces? Will be posting comments. The IDL posted by Kendall has a lot of content not directly related to fundamental ImR interactions (e.g. load information etc) and I'd like to split the discussion to focus on the fundamental features first... - Tom From kendall@drakealumni.net Wed Jan 22 19:56:18 2003 Received: from sccmmhc01.mchsi.com (sccmmhc01.mchsi.com [204.127.203.183]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0MJuI825555 for ; Wed, 22 Jan 2003 19:56:18 GMT Received: from drakealumni.net ([12.216.164.190]) by sccmmhc01.mchsi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030122195615.THDH2338.sccmmhc01.mchsi.com@drakealumni.net>; Wed, 22 Jan 2003 19:56:15 +0000 Message-ID: <3E2E9C0A.8030006@drakealumni.net> Date: Wed, 22 Jan 2003 07:26:34 -0600 From: kendall bailey User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Lockhart , omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] Re: [omniORB] Implementation Repository References: <200301201123.h0KBNWa26062@grisby.dyndns.org> <3E2EF148.3040505@fourpalms.org> In-Reply-To: <3E2EF148.3040505@fourpalms.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Thomas Lockhart wrote: > If it is implemented in python (which sounds good to me; note that > omniIDL requires it anyway and we haven't yet demonstrated how to use > this with another orb) then we should probably use an XML > representation for the flat file since the interfaces ship with python. The fact that omniIDL is implemented with Python shouldn't constrain the implementation of the ImR. If I use Java or C++ and only the standard CORBA APIs, then the ImR should be portable to other ORBs which don't use Python in their IDL compiler. I plan to use Python just because Python is fun and omniORBpy is a great ORB. I think the details that Duncan has spelled out as far as the encoding of data in the object ids and how the ImR would interact with a server process to handle the indirect binding has already shown how this could be used with another orb. Are there still open questions? I'm not convinced that XML is appropriate for ImR data storage needs. My experience with it has been that parsing it is quite slow. I like what omniNames does for persistence. It's simple and it works. I'd though I might try to generalize the approach for the ImR persistence needs. In particular I'm not sure how to have a well formed XML document that can have data added incrementally just by appending more lines of text. > > Will be posting comments. The IDL posted by Kendall has a lot of > content not directly related to fundamental ImR interactions (e.g. > load information etc) and I'd like to split the discussion to focus on > the fundamental features first... > The load balancing stuff is critical for me, which is why I've included it in my first go. I tried to keep it quite simple in the interfaces I've defined and allow for varying levels of implementation. It seems natural to me to put it in the ImR since both the ImR and an active load balancing service need to do indirect binding. I'll look forward to your comments. Thanks, Kendall From lockhart@fourpalms.org Wed Jan 22 20:13:32 2003 Received: from myst.fourpalms.org (myst.jpl.nasa.gov [137.78.15.105]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0MKDV826387 for ; Wed, 22 Jan 2003 20:13:31 GMT Received: from fourpalms.org (localhost.localdomain [127.0.0.1]) by myst.fourpalms.org (Postfix) with ESMTP id 18D21346073A; Wed, 22 Jan 2003 15:13:34 -0500 (EST) Message-ID: <3E2EFB6D.1030007@fourpalms.org> Date: Wed, 22 Jan 2003 12:13:33 -0800 From: Thomas Lockhart Organization: Yes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kendall bailey Cc: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] ImR idl proposal References: <3E2E6AA7.4070905@drakealumni.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: > Attached is some IDL I've written which covers what I believe has been > discussed as capabilities of the portable ImR for use with omniORB. I've > verified it compiles, but haven't implemented anything yet. I'm putting > this out for comment. OK, here are some comments :) 1) The IDL is for a "portable implementation repository". How about naming the module "ImplRepo" or ?? rather than "omniImR" which sounds rather specific to omniORB? 2) There are interfaces for several features including load monitoring etc which are not fundamental to the operation of an ImR. We should separate those out into separate IDL files to allow minimalist ORB implementations to ignore those interfaces. And perhaps to allow us to ignore them for our first implementation ;) 3) Programs, processes, POAs, and objects need to be kept straight. I'm not sure that the distinction between "program" and "process" is necessary, and "object" does not really appear in the IDL but matching clients to server *objects* is my simplistic view of what the ImR does. H&V use "server application" and "object"; "POA" is mentioned too. I'd suggest using H&V (specifically chapter 14) for guidance on terminology. 4) I like the idea of allowing one "server application" to host multiple "objects", so the extra layers in the IDL to support this is worth the effort. More comments later... - Tom From kendall@drakealumni.net Wed Jan 22 21:35:15 2003 Received: from sccmmhc02.mchsi.com (sccmmhc02.mchsi.com [204.127.203.184]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0MLZF830321 for ; Wed, 22 Jan 2003 21:35:15 GMT Received: from drakealumni.net ([12.216.164.190]) by sccmmhc02.mchsi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030122213513.UYDC5896.sccmmhc02.mchsi.com@drakealumni.net>; Wed, 22 Jan 2003 21:35:13 +0000 Message-ID: <3E2F0E12.8010806@drakealumni.net> Date: Wed, 22 Jan 2003 15:33:06 -0600 From: kendall bailey User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Lockhart CC: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] ImR idl proposal References: <3E2E6AA7.4070905@drakealumni.net> <3E2EFB6D.1030007@fourpalms.org> In-Reply-To: <3E2EFB6D.1030007@fourpalms.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Thomas Lockhart wrote: > > OK, here are some comments :) > > 1) The IDL is for a "portable implementation repository". How about > naming the module "ImplRepo" or ?? rather than "omniImR" which sounds > rather specific to omniORB? Possibly. It's too early to worry much about that. I suppose I'm hoping that this become a standard part of the omniORB family. Still free to work with other orbs, but an official omni* sub-project like omniNotify. We'll see. > > 2) There are interfaces for several features including load monitoring > etc which are not fundamental to the operation of an ImR. We should > separate those out into separate IDL files to allow minimalist ORB > implementations to ignore those interfaces. And perhaps to allow us to > ignore them for our first implementation ;) I don't understand the "several". What else besides the load balancing? My next pass will try to split this out. > > 3) Programs, processes, POAs, and objects need to be kept straight. > I'm not sure that the distinction between "program" and "process" is > necessary, and "object" does not really appear in the IDL but matching > clients to server *objects* is my simplistic view of what the ImR > does. H&V use "server application" and "object"; "POA" is mentioned > too. I'd suggest using H&V (specifically chapter 14) for guidance on > terminology. I've read H&V. It assumes the POA will interact directly with the ImR. In fact, it makes the assumption that a portable ImR is impossible. I agreed, until Duncan described what he had in mind. Indirect binding won't be as seamless as H&V assumes it should be, but it should work just as well. Duncan's approach was so similar to the load balancing service I've worked on that the two seemed made for each other. I wasn't too thrilled with the term "program" either. I couldn't use "adapter" as H&V does. However, there should be some logical grouping of objects so that a bunch can be migrated all at once. The ImR could be told that program X is now hosted in process Y rather than Z, and the thousands of objects that once would have auto-started process Z now will start process Y. The ImR will not store the identity of those thousands of objects. Rather it knows only the "program" aka "adapter" in H&V lingo. With a portable ImR there is no need to make all those objects share a POA though. H&V table 14.1 has "Logical Server Name", "POA Name", and host/port. I'm replacing these with process, program and an IOR for a ProcessManager. You're welcome to suggest better names. Now that I review H&V, even though 14.4.2 doesn't list load balancing, 14.4.1 does. It might therefore be considered "fundamental"... > > 4) I like the idea of allowing one "server application" to host > multiple "objects", so the extra layers in the IDL to support this is > worth the effort. > > More comments later... I'll see what I can do with the IDL. Thanks, Kendall From lockhart@fourpalms.org Thu Jan 23 00:35:31 2003 Received: from myst.fourpalms.org (dhcp-78-77-226.jpl.nasa.gov [137.78.77.226]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0N0ZU806460 for ; Thu, 23 Jan 2003 00:35:30 GMT Received: from fourpalms.org (localhost.localdomain [127.0.0.1]) by myst.fourpalms.org (Postfix) with ESMTP id 3EA75346073A; Wed, 22 Jan 2003 19:35:29 -0500 (EST) Message-ID: <3E2F38D1.40700@fourpalms.org> Date: Wed, 22 Jan 2003 16:35:29 -0800 From: Thomas Lockhart Organization: Yes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kendall bailey Cc: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] ImR idl proposal References: <3E2E6AA7.4070905@drakealumni.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: More comments: The ImplementationRepositoryAdmin interface is used by meta-clients to manipulate the ImR. The ImplementationRepository interface is used by servers to interact with the ImR. The ProcessManager interface is used by the ImR to interact with a server. 4b) The ImplementationRepositoryAdmin interface is not used by simple servers, so should be split out to allow servers to ignore the definitions. 4c) The ImplementationRepository and ProcessManager interfaces are used between ImR and server, so could be mixed into the same IDL file; no need to decouple them. Unless one could imagine a very simple server which does not bother to implement any ProcessManager functionality, which would then force the ImR to use more brute-force methods (suggested by Duncan earlier) to manipulate the server. So these should be separated also. 4d) Same with the LoadManager interface. I'm not certain where the server object for load information is required to live; I could imagine that one could get fine-grained statistics by distributing some server functions into application servers then asking the ImR to collate these for an integrated report. 5) registerProcess() could return a "process object", which can be used subsequently for operations like addProgramToProcess(). Seems to be cleaner and more CORBA-like than stringifying everything. 6) There is no corresponding unregisterProcess(). The IDL as-written allows "programs" to be added and removed, but not "processes". More comments later :) - Tom From kendall@drakealumni.net Thu Jan 23 03:41:19 2003 Received: from sccmmhc02.mchsi.com (sccmmhc02.mchsi.com [204.127.203.184]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0N3fJ815357 for ; Thu, 23 Jan 2003 03:41:19 GMT Received: from drakealumni.net ([12.216.164.190]) by sccmmhc02.mchsi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030123034118.ZIOG5896.sccmmhc02.mchsi.com@drakealumni.net>; Thu, 23 Jan 2003 03:41:18 +0000 Message-ID: <3E2F63DF.2030805@drakealumni.net> Date: Wed, 22 Jan 2003 21:39:11 -0600 From: kendall bailey User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Lockhart CC: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] ImR idl proposal References: <3E2E6AA7.4070905@drakealumni.net> <3E2F38D1.40700@fourpalms.org> In-Reply-To: <3E2F38D1.40700@fourpalms.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Thomas Lockhart wrote: > More comments: > > The ImplementationRepositoryAdmin interface is used by meta-clients to > manipulate the ImR. The ImplementationRepository interface is used by > servers to interact with the ImR. The ProcessManager interface is used > by the ImR to interact with a server. > > 4b) The ImplementationRepositoryAdmin interface is not used by simple > servers, so should be split out to allow servers to ignore the > definitions. ... Would you like to suggest idl file names, modules names and so on? I typically don't split modules across idl files, just by habit. More often I end up with one module per application. If you suggest an organization, I'll see if I can follow it. I've alread eliminated the load balancing stuff and subclassed the interfaces to add it in within another module. > > 5) registerProcess() could return a "process object", which can be > used subsequently for operations like addProgramToProcess(). Seems to > be cleaner and more CORBA-like than stringifying everything. I'm not sure what this buys. It certainly seems "more OO", but that isn't such a strong motivation for me. During my brief use of the Orbix 2000 ImR I didn't see such OO interfaces. The itadmin tool's commands seemed fairly relational (textual keys to relate things). > > 6) There is no corresponding unregisterProcess(). The IDL as-written > allows "programs" to be added and removed, but not "processes". Yep. That was overlooked. Thanks, Kendall From pesco@gmx.de Thu Jan 23 08:23:13 2003 Received: from arctic.sol.local (pD9004504.dip.t-dialin.net [217.0.69.4]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0N8NC829097 for ; Thu, 23 Jan 2003 08:23:12 GMT Received: by arctic.sol.local (Postfix, from userid 1000) id 2E28144D06; Thu, 23 Jan 2003 09:23:10 +0100 (CET) Date: Thu, 23 Jan 2003 09:23:10 +0100 From: pesco@gmx.de To: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] ImR idl proposal Message-ID: <20030123082309.GA6733@arctic.sol.local> References: <3E2E6AA7.4070905@drakealumni.net> <3E2EFB6D.1030007@fourpalms.org> <3E2F0E12.8010806@drakealumni.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E2F0E12.8010806@drakealumni.net> User-Agent: Mutt/1.4i Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: On Wed, Jan 22, 2003 at 03:33:06PM -0600, kendall bailey wrote: > > I wasn't too thrilled with the term "program" either. I couldn't use > "adapter" as H&V does. However, there should be some logical grouping > of objects so that a bunch can be migrated all at once. The ImR could > be told that program X is now hosted in process Y rather than Z, and the > thousands of objects that once would have auto-started process Z now > will start process Y. Why can't we use adapters to group objects? > With a portable ImR there is no need to make all those > objects share a POA though. I don't think there's a need for a lot of objects to share the same POA if we group by POA because the objects themselves could reside in children of the POA registered in the ImR... > H&V table 14.1 has "Logical Server Name", "POA Name", and host/port. > I'm replacing these with process, program and an IOR for a > ProcessManager. You're welcome to suggest better names. This reminds me of another question. Which information about an object should comprise its identity within the location domain? If administered by adapter, the object key within the target ORB, or some resemblence thereof (assuming we can't get at the key in a portable way) would work? -Sven Moritz From kendall@drakealumni.net Thu Jan 23 15:14:58 2003 Received: from sccmmhc01.mchsi.com (sccmmhc01.mchsi.com [204.127.203.183]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0NFEv816447 for ; Thu, 23 Jan 2003 15:14:58 GMT Received: from drakealumni.net ([12.216.164.190]) by sccmmhc01.mchsi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030123151453.TLH2338.sccmmhc01.mchsi.com@drakealumni.net>; Thu, 23 Jan 2003 15:14:53 +0000 Message-ID: <3E30066E.6060501@drakealumni.net> Date: Thu, 23 Jan 2003 09:12:46 -0600 From: kendall bailey User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: pesco@gmx.de CC: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] ImR idl proposal References: <3E2E6AA7.4070905@drakealumni.net> <3E2EFB6D.1030007@fourpalms.org> <3E2F0E12.8010806@drakealumni.net> <20030123082309.GA6733@arctic.sol.local> In-Reply-To: <20030123082309.GA6733@arctic.sol.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: pesco@gmx.de wrote: >On Wed, Jan 22, 2003 at 03:33:06PM -0600, kendall bailey wrote: > > >>I wasn't too thrilled with the term "program" either. I couldn't use >>"adapter" as H&V does. However, there should be some logical grouping >>of objects so that a bunch can be migrated all at once. The ImR could >>be told that program X is now hosted in process Y rather than Z, and the >>thousands of objects that once would have auto-started process Z now >>will start process Y. >> >> > >Why can't we use adapters to group objects? > > > The design of the ImR I'm pursueing is based on some of Duncan's suggestions. Rather than look at object keys and tie objects to POA names, the ImR relies on the server application to generate the direct reference on demand when passed a couple identifiers. With this approach there is no reason to limit a server app to use an adapter name as one of the identifiers, and so I didn't want the terminology used to suggest that should be the case. >I don't think there's a need for a lot of objects to share the same >POA if we group by POA because the objects themselves could reside in >children of the POA registered in the ImR... > > > Related POAs will still generate different object keys, so if the ImR is going to see them all as one logical group, it still needs a single identifier. It can't recognize the related POAs by decoding object keys. > > >>H&V table 14.1 has "Logical Server Name", "POA Name", and host/port. >>I'm replacing these with process, program and an IOR for a >>ProcessManager. You're welcome to suggest better names. >> >> > >This reminds me of another question. Which information about an object >should comprise its identity within the location domain? If >administered by adapter, the object key within the target ORB, or some >resemblence thereof (assuming we can't get at the key in a portable way) >would work? > > > The assumption I am working with is that 2 identifiers are enough to uniquely find an object. A "program" name (or subsystem, or adapter, or logical_server) and an object name. The ImR must be told which physical process the program lives in at any particular time. With that it can start the process if needed, and ask the process to generate a direct reference to the object with the given program and object name. The server process is responsible for activating any POA required. I expect the program name will often be an adapter name like "rootPOA/subPOA1/subPOA2", and then the server program may trigger adapter activators via find_POA() calls to get the right POA, then generate an IOR from the object name with create_reference_with_id(). Of course it could do something more direct than that. An ImR client lib might need a callback hook to let it look up the repository id associated with a given object too. I haven't got that far. This approach costs an additional round trip between the ImR and the server process, but it avoids tinkering with object keys. Kendall From lockhart@fourpalms.org Thu Jan 23 16:36:20 2003 Received: from myst.fourpalms.org (golem.fourpalms.org [64.3.68.148]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0NGaK820421 for ; Thu, 23 Jan 2003 16:36:20 GMT Received: from fourpalms.org (localhost.localdomain [127.0.0.1]) by myst.fourpalms.org (Postfix) with ESMTP id 499EC346073A for ; Thu, 23 Jan 2003 11:36:11 -0500 (EST) Message-ID: <3E3019FA.4060408@fourpalms.org> Date: Thu, 23 Jan 2003 08:36:10 -0800 From: Thomas Lockhart Organization: Yes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: omniORB development list Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [omniORB-dev] Server support for ImR interfaces Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Duncan has indicated that he would like to see no implicit support for the ImR within the omniORB orb. So a server interacting with an ImR would have explicit calls. What would a complete solution look like from an application server point of view? I'd like to see a suggested code snippet or at least a sequence of operations required by a server. And this should include managing object and POA startup/creation and shutdown/destruction, since those need to coordinate with an ImR and could be initiated by either the ImR or by the application server itself. I just reviewed the TAO docs for their ImR and notice that the implementation changed recently to support a more distributed model than before. They have the ImplRepo_Service application as always, but now the ImR_Activator does most of the heavy lifting, with the ImplRepo_Service being simply a single point of contact for a client, then delegating the work to an ImR_Activator running on the host for the target server. We should certainly examine the IDL associated with these applications (actually, the files are ".pidl" since they require a bit of massaging). For example, I was thinking about the need for the ImR to test for the health of a server and notice that the TAO IDL include a ping() method for just this purpose. And we should examine IDL from other ORB implementations to get guidance where they overlap with our goals. - Tom From lockhart@fourpalms.org Thu Jan 23 16:45:24 2003 Received: from myst.fourpalms.org (www.fourpalms.org [64.3.68.148]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0NGjN820869 for ; Thu, 23 Jan 2003 16:45:24 GMT Received: from fourpalms.org (localhost.localdomain [127.0.0.1]) by myst.fourpalms.org (Postfix) with ESMTP id 281E3346073A; Thu, 23 Jan 2003 11:45:25 -0500 (EST) Message-ID: <3E301C24.1090207@fourpalms.org> Date: Thu, 23 Jan 2003 08:45:24 -0800 From: Thomas Lockhart Organization: Yes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: kendall bailey Cc: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] ImR idl proposal References: <3E2E6AA7.4070905@drakealumni.net> <3E2F38D1.40700@fourpalms.org> <3E2F63DF.2030805@drakealumni.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: > Would you like to suggest idl file names, modules names and so on? I > typically don't split modules across idl files, just by habit. More > often I end up with one module per application. If you suggest an > organization, I'll see if I can follow it. I've alread eliminated the > load balancing stuff and subclassed the interfaces to add it in within > another module. OK, will do. I'm a bit unclear on how we will proceed with development, but we should have a consensus on the initial framework before diving in. Incremental development is the way to go imho, so having specific goals for the first round of implementation will be important. For example, any ImR needs to start and stop processes, and to redirect queries. Our first round should do just that, with a module framework that allows expansion into the other areas of interest such as load balancing and object remapping. > I'm not sure what this buys. It certainly seems "more OO", but that > isn't such a strong motivation for me. During my brief use of the Orbix > 2000 ImR I didn't see such OO interfaces. The itadmin tool's commands > seemed fairly relational (textual keys to relate things). Well, design style should be based on something. May as well smell like OO if all else is equal ;) - Tom From kendall@drakealumni.net Thu Jan 23 17:37:20 2003 Received: from sccmmhc01.mchsi.com (sccmmhc01.mchsi.com [204.127.203.183]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0NHbK823379 for ; Thu, 23 Jan 2003 17:37:20 GMT Received: from drakealumni.net ([12.216.164.190]) by sccmmhc01.mchsi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030123173717.CBYM2338.sccmmhc01.mchsi.com@drakealumni.net>; Thu, 23 Jan 2003 17:37:17 +0000 Message-ID: <3E3027CD.3000404@drakealumni.net> Date: Thu, 23 Jan 2003 11:35:09 -0600 From: kendall bailey User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Lockhart CC: omniORB development list Subject: Re: [omniORB-dev] Server support for ImR interfaces References: <3E3019FA.4060408@fourpalms.org> In-Reply-To: <3E3019FA.4060408@fourpalms.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Thomas Lockhart wrote: > Duncan has indicated that he would like to see no implicit support for > the ImR within the omniORB orb. So a server interacting with an ImR > would have explicit calls. What would a complete solution look like > from an application server point of view? I'd like to see a suggested > code snippet or at least a sequence of operations required by a > server. And this should include managing object and POA > startup/creation and shutdown/destruction, since those need to > coordinate with an ImR and could be initiated by either the ImR or by > the application server itself. I think something like what you are asking for was posted to the omniORB list. I posted a sequence of steps and Duncan patched it up a bit. sequence: 1. server starts up. 2. server finds a reference to the ImR (either from command line or in configuration file or...) 3. server instantiates a ProcessManager and activates it 4. server sends ImR the persistent process name and the ProcessManager reference and receives a temporary identity from the ImR. The temporary identity is my idea just to keep multiple servers from using the same persistent name and confusing the ImR. At this point the server can start POAs, activate objects, register objects in a name service or whatever. If the server is started in "prepare" mode, then: 5. server asks the ImR to create persistent references to any objects it wishes to puplish persistent references for. 6. server publishes the references (in a name service, to a file, to stdout, or wherever) I'll inject some steps for replica groups here, but if you aren't interested, just skip it. 7. server activates replica instances. How these replicas share/transfer state, if necessary, does not involve the ImR, except the ImR may be called on to get a list of all replica members. 8. server adds the replica object references to named groups known to the ImR. 9. The ImR returns the group persistent reference to the server 10. ImR stores the groups of replicas, so that invocations can be forwarded according to a balancing strategy. When a client invokes on an ImR generated persistent reference: 11. ImR determines whether it is a replica group reference or not. If so, it selects* a member and replies with a location forward. 12. Otherwise, the ImR determines the process identity, and checks to see if the process is up. 13. If not and the ImR can start it, then it does so. 14. Once the ImR has a reference to the appropriate ProcessManager, the ImR requests a direct reference based on the program and object identities. 15. server does whatever it needs to do (start POAs, activate objects, or whatever) to generate the reference and return it. 16. ImR returns a location forward to the client with the direct reference. * The selection process may test object health and/or system load Step 14 may take a while, if the server process needs to start up. I was thinking part of registering a start command must also tell the ImR the acceptable time limit. If no ProcessManager registers in that time, the client would get a TRANSIENT exception. Step 15 may involve adapter activators, as I described in a previous post. A C++ and/or Python library may be included with the ImR that clients can use to simplify the implementation of a ProcessManager. Shutdown should be simple. If the ImR is told to stop a server (I don't think I have an interface for that yet...), it fires the stop_command and waits. If we have a ping() method I suppose it could keep pinging the ProcessManager until it fails, or give up and report an error. Otherwise it waits for the ProcessManager to tell it that it's going down. Any replica object known to be in that process are removed from any groups they are in. Server processes can shut down any POAs any time they choose, or shut down completely. The ImR does not act on POAs directly, just processes. Processes should notify the ImR of shutdown. If a process crashes, the ImR will need logic to determine when a restart should be attempted. Getting OBJECT_NOT_EXIT during a call to the ProcessManager may be enough or we may need the ping() you mentioned. The decision to fire the start_command should be configurable. > > I just reviewed the TAO docs for their ImR and notice that the > implementation changed recently to support a more distributed model > than before. They have the ImplRepo_Service application as always, but > now the ImR_Activator does most of the heavy lifting, with the > ImplRepo_Service being simply a single point of contact for a client, > then delegating the work to an ImR_Activator running on the host for > the target server. We should certainly examine the IDL associated with > these applications (actually, the files are ".pidl" since they require > a bit of massaging). For example, I was thinking about the need for > the ImR to test for the health of a server and notice that the TAO IDL > include a ping() method for just this purpose. And we should examine > IDL from other ORB implementations to get guidance where they overlap > with our goals. I don't have TAO installed at the moment. Could you post a link to just the IDL of interest, or just send it to me (or the list) directly if it's not too big? Splitting responsibilities between a single service process and an additional process per host obviously has advantages. I'd like to get an all-in-one solution working before federating the thing though. For the first go, if the ImR needs to start a process on another host, I think the start_command should use rsh, ssh or something else to get the process going (as described in H&V). Kendall From kendall@drakealumni.net Thu Jan 23 17:39:58 2003 Received: from sccmmhc02.mchsi.com (sccmmhc02.mchsi.com [204.127.203.184]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0NHdw823511 for ; Thu, 23 Jan 2003 17:39:58 GMT Received: from drakealumni.net ([12.216.164.190]) by sccmmhc02.mchsi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030123173955.EYFM5896.sccmmhc02.mchsi.com@drakealumni.net>; Thu, 23 Jan 2003 17:39:55 +0000 Message-ID: <3E30286B.7080504@drakealumni.net> Date: Thu, 23 Jan 2003 11:37:47 -0600 From: kendall bailey User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thomas Lockhart CC: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] ImR idl proposal References: <3E2E6AA7.4070905@drakealumni.net> <3E2F38D1.40700@fourpalms.org> <3E2F63DF.2030805@drakealumni.net> <3E301C24.1090207@fourpalms.org> In-Reply-To: <3E301C24.1090207@fourpalms.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Thomas Lockhart wrote: > > Well, design style should be based on something. May as well smell > like OO if all else is equal ;) > > - Tom > I guess the design style I like is: K.I.S.S. Kendall From krbailey6@mchsi.com Mon Jan 27 22:10:30 2003 Received: from sccmmhc01.mchsi.com (sccmmhc01.mchsi.com [204.127.203.183]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0RMAT823353 for ; Mon, 27 Jan 2003 22:10:29 GMT Received: from sccqwbc04 ([204.127.203.164]) by sccmmhc01.mchsi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20030127221028.ODCT2338.sccmmhc01.mchsi.com@sccqwbc04> for ; Mon, 27 Jan 2003 22:10:28 +0000 Received: from [12.216.164.190] by sccqwbc04; Mon, 27 Jan 2003 22:10:27 +0000 From: krbailey6@mchsi.com To: omniorb-dev@omniorb-support.com Date: Mon, 27 Jan 2003 22:10:27 +0000 X-Mailer: AT&T Message Center Version 1 (Nov 13 2002) X-Authenticated-Sender: a3JiYWlsZXk2QG1jaHNpLmNvbQ== MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="NextPart_Webmail_9m3u9jl4l_16169_1043705427" Message-Id: <20030127221028.ODCT2338.sccmmhc01.mchsi.com@sccqwbc04> Subject: [omniORB-dev] ImR prototype/proof-of-concept Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: --NextPart_Webmail_9m3u9jl4l_16169_1043705427 Content-Type: text/plain Content-Transfer-Encoding: 8bit The code contained here is meant to be a prototype/proof-of-concept *only*. It's purpose is to further the discussion among the omniORB-dev group with respect to the development of a portable Implementation Repository (ImR) service for use in omniORB or mixed ORB environments (or even to replace another ORB's ImR if so desired). Some known/intentional problems/ommissions: ============================================ 1) little/no error handling 2) not thread safe. No locking, and no use of synchronization primitive to coordinate needed communication between threads. Saving of ImR state is not thread-safe at all. 3) no graceful way to shut down ImR.py or test/server.py 4) persistence of ImR state is inefficient. Any change to the state causes the full state to get re-serialized using cPickle. Topics for discussion: ======================= - Correctness/completeness of imr.idl and imradmin.idl - Persistence strategy for the ImR - Details of the server auto-start mechanism. Local vs. remote process launching. The right way/portable way to start a daemon process / Windows Service? - Logging, graceful shutdown, error handling, other boiler-plate. Kendall --NextPart_Webmail_9m3u9jl4l_16169_1043705427 Content-Type: application/x-tar; name="imr.tgz" Content-Transfer-Encoding: base64 H4sIAImlNT4AA+w97XIbN5LeX1dh1b0DlrqUh16aIilKuqIt7SqJkuOtLblk5ZItx8UazoAkVsOZ ucFQspJK3cvcu+zT3Dtcd+NjMOSQoh1Jm81yqiyTGKDRaDQa3Y1GU8yy3ScP/LTbvfbh/j78324f HpT/188TKOjs73W7B+2DJ+1OZ7/Te8L2HxoxfOYy9zPGnlyNfBHx25X17nr/D/oImH/41xJh9GB9 tDvt9kGvt2r+9w/3e2r+4eNhF8o7e22c//aDYeQ8/+TzX9sR4zjkY5bMYjEUszTiMx7nfi6SeJjx NJEiT7LbIfDHsLYDFUXMN6pb2332rPaMDeKcZ2M/gEZj5rM0yXJ/FHFWbs2K1q3as93aLAnnkepn MLtgP9VqjLH8NuWIqcwzEU/YmywJuJTD/AW9FbYj/eK1H/sTnqm3u7vPf8GDEPiHgKeE67fxVZzc xGf+jANmjB6NUwxlL7Do5/vv9rssiSd6bKrfB+jkq3kaicDP+WOP7gs/vOAT/uGeR1ZwxaDEcBeW 3+wggV+Z/viMfZsCTigZ8nnaRL7VdJfTZB6FwK4TIQFyyza4nGIXF/Amn2exLJrAamD51M/hD18A YxvPJWd5wkQI6InxLRO55NGY3Yh8yrgfTAHqf8+5zG13u/qDXQMG84yPRBzqYk8XEh3MJJrHoIeT 2ixVLK8fNtP/N9ScKEpZ1M8SwjjXw18aqcDBzvMcuw5h1SyO4DoRhg7zeCXuxThLuIuwGqkLMwkx NA5FxoMcKDPmGY+BE8ZJhm+S0V+xfJrARBZTMVJjQaqE2M8k82ctRtOrv7EZbBnMjzLuh7dsxG1T wxTQkGbOIUMBAb/ZFoEfRUiYfApkIrBT/xo6R5oKHpapKnLFkA6yfhwyOU/TqJgAX0oxiRXumkaW a2y7k5jqLshgwGGcceLEKUAG+fvtxeBpgS0IcOwFyDdjQZKN/CgJ+v2XSMDj/kuU7Me7LzWRiK2O d14CkdXHgsBzGoqQ8dOc+Bqmp0Bx1zDyuZod/W3mX/E3PJNI3zj32ArmKMbcrGJ9F7fKCgbbype4 RQ1C1ijewZP5QnLpuXtCsyypG/crMVFKncSOXLMrDmcUBInE+VNrFoRQNo9jQL5GpC+Y8bspj12p hnwlm8RiSsBprkpirqddcgUDgFuuTBiPaTOHGaRFhlwE1bW0kjSrekpXbc8l8UtoEe8hwStXb7M0 VstVtIIAIVBP1LJZbLckOhWD6S8Tnn9FDS5M/UrZuQkDARB632AVjMI8h1FKsoudopx3pKZdyECG nM9gefmwWcFmcoNEErkdupo8kjDC2aBQAmrBES4NXqNbjF5PyiD0qiWqhgcsE/k5SYCQpzzGDQs+ ySATqZl9R+w5E6T2tvzW4BkQmiPgUcCZBBF+AviwdhkKaKyCxR8KaScJdsblPMqVOhnyHLXyENaf +MDqqaxjK+D+YsiwGWAR4hrSbpTMOHALjD4SV7zPlPxiL6Fj+BvMwkJU8Q8+YtBn9U53r9XbP2gd tv6ddfZ6+2x2+5Zn1zyrOwoAynCQUxKXEfflLW00eZJExJkwMTfAKeOE+aNkjhtIZFZnBblKqxo5 Rqpmq2bSmULowiuEDv7bgcGLca1Wpf+j/YdYj4GMD2Vj3GH/dXo9a/93egcdtP+67YOt/fcYTw0s Kh/WUx8ZslZ78+dvjnA1on48GAe1GpT22Q/EbP/mwdsGegvQwmult+XyaFRZDNX9cCZi87L2mReA iIb94QVUeX3y59NGA/r9y+CrV18ekcUHFTUI8zwfpbf5FMTLQvF3o9QPrmAbOVKdwfval99/vxLU 81Hw4UOp4LuRX/r+pQJUq1Vj32emAB0mTDtOap9BbRpAo/TeheICqGhTqm4p2WfRyO2oDN2BoKq5 /bWm01JfmixVnVHVOzqyzZd7UvV0d5W0cft2iBNE3I/7tc92Qe3fhR3leTY2TPOsgksY1Qf9qxaC GthXX1W9Vou9YGLM3rHnY+o4n/zI3kNZjnulhV+8ewGKgjPtUBFkQPBjUQH+h44+q5aZv6VH+f/s gn8QXzD5fw839P92SP4fdve2/t/HeHD+QccAYfNwfeD+v2b+8a2e/w5UA17odPdBDdju/4/w7Pye xCOPr5naY2u1cZbMmJEJLfyA38C8Z4XXrOl8PkGRXtNVvjy/+OKkyeQtmJO5mHHQPj/F0kU/78wX sdfoo5hOshE7UrBb8GcoYpF72EnLzybXuCdAJdpaoNoCZh40btYlqeut9CqqN2zllg8267Wfc09B QBO/BMCjag3zzqnPlEs6gz3amFHQTws0ek9Zfsq12dfvUjDnqEUK6nrO6iWfWF0PsYWlWOC1qUuk X0tGnKfefuMTCQm74pDs0eGQHR2x+nCIZB0O64xQUzT+7W9z22fFg/If1ayHPATefP/vHPbwLBDk f7u73f8f47Hz/4BOgDvs/3avp89/O93ewQHu/73OYXe7/z/Gs8b+vwS2qHIA8GCaaAO19uu13B0s +wy/LNrMtuwOQ/S3vTna9W/I8QB90Po/WL3+u12z/tHvh/E/uF9s1/9jPDb+A31UyAidcqjHQrGJ zLDFtZ/KpzunwEZYshA6IHkces5ByYxLiSdU1lF9l596+zzMY9e/5Pk8fRg3wF32Pyx8rf+193s9 9P/0uu297fp/jKfC/teWfCKbYGDX0IKsD15fXJyfX9ZxBSeyBbVFlsRkQaIRnvr5tOWnKS3y4v07 2+49mujkV0ikcSZgo5LXwHwpnT98lCPgXaf/XjsDjKsZapNdzmUSXXOqL/xoaM+FpVcf6P7IW6C8 A05r67MGKzrLkhvPxa+1KqqIYC2g0jIBIsshLvTUSWUhqVpvssWXu9Nkxnc1F+6G/JpHu87iVd6N 2+WGe+0mq9eZdlhYXPwQI23wNPsy2QSfxXf6KBzItdrFsPUw/Pofy0Ku1n/PzoCP9/+DJdje2v+P 8SyLkPvv4479fx9m2/H/7OH+v3ewjf9+lGft/o8ba+W2vUYpYB+pFazTAFAWtaypgQFAAnSCtZWG wzfnJ1hz5EtepVGUTjegwIxLx5pT+09XO9LE30DjuEiSHLpRugY0aQ0nPB/mU46d68A4r7F4OjGb ZAC7HD7nUY9GZ/kIZafutMFD74/SbphFyOo0HsFS5SGn439zQLJ0PMLWHZBUnINgUQiTmyW3HhXU Pu0wpHQwEkTQ4xI1XS5oLUQqKlZAzhgSaYdDD8O0mzgFDTMOLGkpLoC/biEKWD/OJbz56eeaBaX9 b9ghgbOQdMidAWhbWIqrzjFSodS5CPWUlmPBF9RLqjrEsEmYkIYFXhEIqcfohj6W4hxN5/UBxVIz n0mw8KMiXhqjnHnInurvTyls+Ye4brx39RsRRSzIOLA6tlZ0oug5Cn7HcA8RB7mJ2MZeTdwdyCEX M/b7o0I17Rc6K0VfmvX7xX+efnk5PDu/HJ5+P3h76TUKWM64MAqbHBaluXNgll68c1q+B/qjG8Sz c1ciGGuwihmuBGQmyJ2eIlJzJbeIsKoBxgVWNskzD6TzHHv0Gg32B1bv1+GvLgcIqQg9DNK6r0Wn iIMCuoUf1y6sJisx2erlRaQ9otpucZDMgZeOWPsXrDhyXimMtN+qjI/q4w9HrFMGVP9cep+HjT77 XNbZ58wrEG06DZuFM+weKLzGGEPkdlS4sIq1DX0+ww1f875swZK7AnFgJbZsDfkH2OnaDd14hLG0 3Ikcn2TJPGUR90NO8h6aSJ5LZBj9dT7z5ZUH+p+BMUlMEHkG26AO1IZNBd/G/OYGxZfiu+BGg7mZ gurl6bewxEmzkGmEm7AqbLxrv2d2VgwYpx4VUS2NVzCFnm1zjdsZx1sXCQuiBOQFhugmoL4wPBcD bQjlVi44kDAUcRP/o0BevISRw/gzBQOao3m+G8+jqMXYQOrgdBjwjX+Lr8OEifyPWHscttVosRuv btuBgIbC8+HFV+dnr/7SUFU7a6t+d2Grao0G1YB5FtByiBMcAwAwhUjfLBIzII0tung1eD1Ayfj1 4NWp6hRksEApmPnxBGeAwBCtLZcA6wgjLN/BgJqI6ntXUjpKgGUsorAn3Ch5rRAoVUDVCudp10Mq NdussVDWaXYqyrq2TPVAJF4q6tgZH4sYpplita/ougNIqFxFrmyyLNg/uoPD2n9BJEDR+3vYf51e V/t/uwftfSwH+2+vvbX/HuO52/77Ndl6H+8S/vW5g80lMwDmebB1xp7BtcGOGUgmtaNY2/J9A+/D 1JEsQ2hbV8FoYxeXCY95Btqzc0Vulb+2WXHHTYvxgLSx1vDszbDAfBBqW0/rKKBSnLDX6otGBS+K 4caCSixMv1GRnGi3AapQef+HWClCuoZTQV2mIVhCX5+0tamD+1A+t37qikfnf7Bh+Q/Rxx3xP/BR yf/e3mEHdgA6/+9s7/88yrNp/gd7C2bjLBBOC+gkDqJ5yFldXwupP0B+iPUZIGz2CLycCpL+pYpE ONYRCcMIBOd9XtLF/58xRSpJThG65Njpn4GoSVO6LTqGPVeKwI+sPUUbQ56oxlEyMS/JkYIv8aLn IH8q6fYiCF6ur43aCgy9Kap9kGSw0aVJTDaNz9AzilUQxNgx4sg6SeaTaY71Rvqmr76ciLeCn0qb BQDq6rnEe5pg1GQ36FqhG90sFpF75xcoOw9yps8ZX+tRL0SG2MdNSPBC11nwwBksXpRA0NQZENYV JN1710uTX8bpeAFHwwz3xg2KoidRRBc5cWFAB5nvXpnFSxiKdmVeXq9S/OReIdYfn7HX/hUvMgLc +JlZXdMFdjOJBQLfJmaAJYgKhCCriJwFuzJP0uUkAvRuqK/bwszcquQFPvsTXXdLsj8BN12B9XwD TFJkSTBoQZcsjeYT1CiJw5KbmA3OL8AIozoGcATrp6rzJK3sO50tdY3gbMMyR0G3IiGmTiMg9vJF aUxPUbjrysf35SwExRXxFWk1TCSUS7ZyjSih9aBqoAmazPMVMJzRVyckKCdyaWhmZou3umfJtevO QXjo9QjmIDniHDgAbPEkEADHZsMoLinTUYrLu4uU0x/n8erIh2rKla/G+yFgtSQNSaQtcrSbkAXF Go8iWU6jQdfnTYYCRu4swAFM/BKHTsQ1VNNduYkReCzniqVc0hSLx0l7Uk7WUcVRVUEYn8ZVJSf4 phyxzBBgQICo8WnmXeYggtN0+04WCSRxsSKn5kZ/iG4UUOzp9juOUaU44Uxix8702bZ+TDvJ0iRW 8JLCSlPta8BoU5b6VLK52Z6qifaNtr6QNtYAczJP6A0bXWQxR3x85eykxpQjwMmXk2QuhUbczSoD ePvhte9ms1Bs/ldMHWOMQEp7A/tYlsAcIFrlzDfjeY4MPJeFTERzizyZeqqUd9YZC7Byzp2NivmU v+CunBprjNJPy6mxJi9L9dR8LbRAsxkW0JcMGtPMzwOVoYd/SEFJkrgTo/RTrvuCM6GtVtck6Wt6 mp4fW3Goc/tgUgw/10RyJOxkHoF94fQiVF6isn6rElkAqK/x1EvlnWhaKEJR3lBfyKK5Yos35Lpp qvvOWE0VQPfFItM6M26WI5r/UGWKyRcUSNIwkRi3sEdLjm5vC4PP0vzW7kILqUa4ztiRF9yMelTB q7ACeJ8GnyNnwEjxDAj2bw7IhgazmHNM1aF27iRp6tFbKEYOYK88pC6o6YTn7JpntwzoPVnO91Kh 4VlGzXXp3VJkCBNZLSdsAjPDiR/Djlp7MdPg8CiXpcEXfASz9JbzEvINzBFyjQKHksmUR1wwUwzL GaWBnj/qO4kphxSeepR4wUWltEE6DI2kVGyYF1mylA7OxoJHIa6QBDEtpN4ciBDRue5ENin/WWkg 0OIk1tzm9LS42ZisNHhOo5aIWau/kOk24Z7l7Dl8Jf9YimzOP5skb7mHB/0/KqfDA3Xw5G7/T0/H /+0dHHT3D+n+98E2/8vjPMv+H/LhDKPED4cjP0JJka3w+6ysWeXvKRVZd6PxA5VcOq8A4hca4JJv B1/ec2pPa6AX3hpcq7vXfjQHgeaLrDAkmSpUiu8zrDmf8UwEIE98sgxAEGGKKYZkKex57QpB5DEQ A4sW/CAgjwCM8WyEyRy9YNSZcWSwCj+GAXhsQd+3I2vZj0XBPTM+G8HskFuB3PaBr4IBjAPI9QB9 gy9eqxZm2Np31+9Xp5ssu3jY0qOFqqmm0wUuPaD7rvUDOZgdKzQfmn5WR1KhE5Quj8gnl7hFIbfe bUZQSj6zYhT0VU2UXMdEbj/HpV5dYlgvFrE2Myu+Wp/NnEwRI2Va6BWjg7hKPCONzUGJ2UyaNwNB tVN8ISt9ZK7AUH6x/uI1CIfh1nrU3JVZlVKUnAMK59WWRKF9VGkxy8qLArikdCzNRKFx0KtqdaPg iNXKhqWFq3WwB8m7WxLmnzItbNWUXC47d0A8pTwQY5DHms/QtYcBTySozJJzzDO19JRH3M4tiF9O +UlNllf+AahPbiCKVRw5ZpWKWwy1FViRbtZaKtR0notI/FhsDwRDrSW1CwRTPxZyJpWjSvII82pi NkxH5FpEC0YjhtA6e6yjmADNSZSMyJM7jwWs9iZ5IchdgEa/iAujo9CtBWKt6KCFh0I99mEgBAw4 WYTkN5vNo1ykRbDnMhOXfAIgBi6TwiFASJeZeHFbuIesrsWCKL8+N5JofMciKSV3taWLWV5X+arI SfXbHDKzEqO83he29P7qRV+uubDSi0VWSo5KiZJtQlJHH2QeWHexiCgkLS9am9WMSW0xmsTZv4BY DdDXSqcSmAnDti3XhX08ECjEl/ncwaMQ006h59h1zN1O3WS+6KCb+OgLpQSl2DemDEXPktlWnin1 kjKJauPVpvHVsk9FKlI1XQMDs3VjXaelFLSqnbQiM68lBzpZlHZsPZcIW0m/zPZnxQINQat0TnZT dN1jOwdTqhn6uU8wHBEWJBHKQPiOTgoLIyGHpnZJg4QXATnaLDZCH6b66tDNSVpcOPfIF5/xcB6H GHFOKICUzASXyxmp1dIq5vY/oKczipkuHVYU25PukWQnQlVJul0KUybyRcuhcNiRRWD8i247GJs6 2JUCrQQEo9aD6+fx6dD2liKpcp1DFnPQYqJ5XDh4wASyHOrEVYnsFxQ6GkUIems2QxvwBndbjSDz neM9FbCF1MSZVSoSnj8aHr2G8dA1gQhvsNoxVq0ma83oMqIhvlghPt3TYDJKDX6NF7q2Xn/bXAPF 4+Z/fKgcUBvf/+weHux1DzH/415nf3v/8zGe0vyb6xet9Da4xz7uyv/Swc86/wtwAN7/3T/Y5n94 lOf5//1r7W//2zmm+f4d/JP/An/+58mT8MmTtx4WnHn4auGPbMKfVSkJqvhJIqg/QsO/wxi3z+pn 1XzdZx93rf/2XlvHf3a7e5gLtrPfa2/zvz7KU9vRcf9MJ2Sjy05bveif5Smtf/zwADeA1q//bmdv z9H/aP33Drrb/I+P8lTcsGm5l+DXpFIw9Rbu6pRu97zR8dzqgkd1qUq5oF8Fb0RwpX4MJr2KFu4i qZTSTTB2q7NS3NcF5cUoW31Z+Y7bPatuMWP+aZbm06bODnGWxM6teX0FCX3CKoBBrDlMabnX5pm6 +/Sc2uEnsOz1L8npy/RAV7nYBBCBJkgvimdaCPJaqg0Yqw6QF/Sv0ghp3eAmRQX6qRbbareJjQss hcdhfgVyuiM1VNxSZXN8azozrnaoaMNr1GVtGMwRjswtVPfC4K9bmKnMGx+bo8N2t+PkKZiPniN5 0PuCZNe/HIdz95yShZd/kQnDbCyQEinSJBIB/jDSCQxz+QCB/Ctm7BaCjr0F+Lh4VCkAgoG9K7wj 7pBbCsJQh74OtUMGPSYKgfKVsfISbX379nT49vTiv07OLoevT85Ovjm9aDTXd6QzGkCHFE+exJv0 c3Z+Nrw4vTwZnN0FXoRD9RNZuE42HMLFcPDVXXAjMeYy9TfC9s3pxdvB28vTs8sGe28jrHfQ/xwn tHZu8Oet8LfUBN6XMLxTjs8EFtctMZsFNIJJpVXh+M3xonIm84L7kImR82a3OIiiImDdRSb4+LFt MMjFO4OfPjd3TRKQs6jjkEHfF6R+6CTEz9QS8utuLZKzVZhhzoclRHbqZld7Q+BMehTTtjI7zzIt doj2jRfuZFg87hI3tJeevXUkjgawWW4gMxF2ICTjNqGAHftmoyYh0ygJ36psHGuBlH5GQdNOhSWC AEQZGiUBRerZ4OiKsGrpuPLBhkmQL0ZgwmBsMv16KrzWBNdnweb8YYmJdHd1dwAGBfVrEK/UN680 OEUvSwwDVvJ8JVRnejBPhpWRM5N/yO17IT2P0wV6t/VdkpzXmSM98Bo2HVZLz+yMjaWkNSZIUk+4 ObrFWbyKWgjcoyQTBkKzntUbdqp4JPlHgPTYTz+zJv6xfI3/r9LUjA5lWURnOcJ0HpZV1dXsIt9H /UTXVjuiPvq3P8KqLnP8f3tXGhvHkZ2rZ3iOhiJlXZYlrybKZj10SMqSHW8sWbtRVt6IsFdSRHod U2aI0Rxkh0ePp3skcVdyI0sHMIIggJELMLIJ4JzICTg3sjkAZ38Ym8BJAAcwkAtGEsB/EuSHg03g hfO+V0dX93QPh6RsBwjbFtnsrq6u+urVe69ev3pv+oJxUSWK1V/2I5VDSVgZ8yKIDxuHVKolqN6Q 8YJyUccLifeVS8hhqGijl762YrGWol5djTyrWam2nArYX8Z0lbcYyO+iMZ0s6pzZjhFPOcs+sFO6 r4n4N9TthcCLuFTZgKGCiW7Wr94j7fRKFbX2ajNeE/bBM7EaTXCidOLmCUNsoGh+qlTuRqjE2KKZ 3FCBQnodvfjeJkmwFouN7UKxb2RtBcvcARbb+BWPQaT7dS32uhJiUZWxtT/uwJwhjDuPjB003Q/1 PuvD/tTCmrvSEZo287g2X0rVNdKOTBA3fygF4O4P2bvuYgsQprDxXqilcy8c00sGuURkrgPxdB3s aw/NTzVj/vcWn0ZUvhjNX6MatZplbmZVndLbnth4yg63bh1OXDc9MUA0F1mqxNtq19AJgvWkCVGS uvErgU6szHz3l6YRQ2/MI2M728cEklu7BTUAUNFKtH4rAymQCwpdo/LzpSQNGQjtZ7dLQSnbyFKw SXOHytg5pjeMpUbOs/Qzs15W4s+I9xR2caJ59ux3+PgnA71lRktM52smtXhvgEQbZbpRCXt/mk7e wKJQj0E6N7GZhQvSnGLf1nKyUtLGxuMuXa0bZmLFac6dl7HC4lC3bvTa0WhjTbcx77mnRi21/VCT jTfU684bet9aw6V0kQGVrfCZpok6/sO5NI5jWK0qhZmqgy+cyxKt6pHqKhRV/eCp+Sn4t1ZIczth 9uR3RHLnwyxRFamS2ie9acpqWrTGjUKlIvagj+iEJHkEi6S360IIA7hOk3W1zG0ySyRcb1Zurt3g IFFXFi5dfub89OwEClE/J2KFk7HndLdOW4H+SrEkeafGYwQMV1cZFsr1AVK5E1FaG5Wu0zxfjpZQ PTxhrc8lGBfcGvsXApOpqSnLFGEHHp29ev7SzPQTl1TE0V4oqdmqu2s3vGW9DPKwspABRSOKD9ab ksCY00Afdmsq6uGJs2eNOaE3qovH6lMoppAiTE8dV4kWvbUFXn+CTye4hIxzas8N+Wpr1GRcq5SK U+LSWl3WNcRDCpc4GmOLQy7KqJduUNhKa/BsgtHtrH1pTcwmEsM1+XbCUPZ5r3Wz0qpdldbcMres N/nR9LDtMoOoaAp63rLLAUrZNBGtRpUde62OSF3wA5VxfTWxywDOO/0AYxp71ypKftHZ5FuO4i29 vd4sdOMffGTS0NjyTIeP499dhyn9DV3NIZYlJMtcITfc9Wq06HhQxgmXxi9D4N3JLb0fGaYOWweL mpptf9jWm+1o2L2q15rrZ4hu2dZN1kypgnw15ipuVRYtJSNc7Gq30fX2Wi9dd2tb7SWNxA6Ulc4+ b71ncNXvvjDo3EbRbbmw2VrBMujriWEWDB/lcqKntcT/ZV5sDOoprgBTM1L0qDIS/BMnTpxH+JNK M6izIbMhBSBLIbN/MPlNXvI4enbHPJ3lI+eH7iEWucojjV/bePFWrKZbq7onddJ+C3/Hjp6KPVDq au/KaEBC90B9qI4UD6V3JNWOztZEVWQ/veu/1uuR5v91N32/cWzi//Xoww+dSvj/P/Lp3fy/H83B /t+3v0v6f+fpn//Pgv2/wxxcwJeJQhwxlxNhnv/MC7dPzPWLsI//HBBzAyLs5/NBMTcowgE+HxJz QyIc5PNhMVcQ4RCf7xFze/ikKOaKfDIi5kb4ZK+Y2yvCYVFzUGxlVMyNCiekezlRzwl3TDQcUcuL F4XYEOLZuX0ifEPU+vjePXyv39zbL8L3RG1A1IeEe4DvDZp7B6Vj+5CAYzv7u/fRD3w39UfpJCFA GJUc/ed/HaiMiECIOUeEe/FeaumLhE1ehBfRSjSO/uwT4WU0jF4InJ5WDQNOz6JROCecFlSjgNOq qA3x+bAI26I2zOeE2QuiVuDzPSJ8SdT28HlRhC+LWpHPR0T4iqiN8DmB96qo7eXzURG+JmqjfD4m wtdFbYzP94mrM+V96Hq1TwyIfhpw/68IBOpPSM8cFLdz4rYQC3TlkLjt8DkN/WGcu3l0eENepE4e wwkRg9svggHhDqpbuDLEV4atKwW+sse6UuQrI7iy2CfuEFJlcTsvgjHxQ0PCe5aG/sGUop3VLebE HWrNw3wrx63M4fodGpZHUCNRBw28ux8/nTWHKn5UV3MAY6bOudTtfrHBVxYOivC78TTOCZnHYsVU ZeE5ERxSN+jnhsTusAg/yxcPCvdePjks3CN4YAMv/14R3Cfco3yDL3lTdPVzIjgm3PtF8Al1gwho g/vxnKz1OP8sibVjVPoJsSTwfyOXvE20NlMeAFV/i35szbUQArcXf0KU28SJsFDaouegZZbp2V0w eibNR7DA+1iUE58PdSDysPEx+7XQ440prUvlbwNqYIDUN+YJUDn4AkHh34dCme47/C7lFeKX6Hwz Xzt/LxWKq77+frqU4mbnH4/qy3Kp4/5FrnP+0eiRNFcsbq7ytPIPRWUT7mFca+T9JcHxVtTvCoOE 4ZAc1Fs5zV1I8fhhvPV4c62RL5K/xxoL/be1QuC2KocYrj/Fbcbvx3tBXREzxySQjjCyvcsrfA/O LXwCnwFul17W8h/aKCrnUAcVaPKwEeCOK2is/VH4uen+KKVv8av1emOv8E9AFDv5gaJTdA72f39x LDc5fNA5nHsgV3QO9d2bO5Y/5Ezl/BELOSmtIKnyYOrYnUVSKZwW4ZOakdOVpyIuKS8Sj3GIq8+U c2jzRfqxfU+auP/MpTKjh3rdWhxJIHfYooikJSoXw17WsBNk9XsuCqYKQpZwrBIzZrR4vpLIDq+I 8Crj4wAinOTBgGcifH6QSXOHPjldPXEUah1wjTIIMWuYBsaxH9guTMPM3lTNl2V9wIlRcoAStAZS ZsIvKohmrP2BubQ2352GFTEzrAXx05Kk8hg/ReugWlKtwjkoZ5K+oaiQXkCK2jURsIqC6wP8cxBi 8zYXcMLnWLMZYnHOHULll1gk3CwP6w4wr4j3j5gACjVizAVmrGyewlxKOhbFAeOKtguQfu+zmrgP Osedaj/pdn0A50mAsyDCGsChYaPuhg0+Z00+XBSLgnWeHGs7faLBugwpb1Ty8XCZ/yhE+MgB36Nl pduoSlEW8y7iUbNtlrqMZQnkhsMayGws5sRjXVEeOlyh7X4TgReDW4NR7o8B3NGc7bxyuwM0ylMr 5vKzILjZ+f4iMaLjfVVJyDRaMxitVRF64taEmmc0DEeInI/QeF2g6/P7xR3SyJt8tx/Ddu75o+KZ 8Pmo+Lmwpcg9TtUud2AwhkwMvVSYYk4iTKpunKoN5vnumPOj2wUR3KfDc2pVsC6Rz90rhp19zohT zTPRE5BXAWRbhLc6UcTCYJ0XBgwfK+VfsopJHkF3Hg+/zJeT3EHiOLwjHFlxWCT0MGel94F+LCqV DnNfd5g7atGv2i700LlSvLjaiobzh50x5zCg75fidBbQvyDCH06BnhjOV8BkDPQYjA1cofE4F76o 8AZVhz+i+FAa+IW7Az64BHs5daLGzK12K2MMNmEvmbXtdCzuZV6S7jH2gpoNNCD3OAXMhj7RJ4XA gxiSl0T4Y5F6U+OBIaBJGB4Kfxz4k0CcsWQgCNx8hkjow0mdHe3K+r7RiQaetlyieA7IrxbpxN3T k9tE9B4q3Olh9pLSgPqO5Ig5KxQbQPFlEf4ERCYI9yfFrWmlcFygP+bPMmv+Ka1xMLwEqnecOMxP M8cZVMXpBs8JMB+YJJ4/Qiz8Z1BkJknqIEBWeVo3Mihe8mQuUmeSZq8tfyxBlXCSsthNAurU0lbN N7YL8B4G2HisvSx4VPO5YWeEuPYh59udCGHW5F4R4c9qhL8qbn2nQfirYv5+RvjnGMs+C8sNjeHP RxhKTaU/Cz4zqWUnNwMm5mt2V4ApSmCMh9srWppJZI4CF6XE5WGie1WEv2CxVPDSX1SkBs22D1P6 yMKgCH+J/yBUiJPWCMRfVoyU1DicsNUM2jEh+SuwMwUjihkf+r6L4a+KYK9wR41k/DVx6xKMcqiy n4G+QNfmH+Ph+XUR3ANjWE0V/g0RHIDdSzVG2gSL3hDfusKE/qM0SL+ZVsw7SqV+CwZSasVvc4lD 4P1fcQQe5CEdNNPC5cUFWJRxbGNKs7zSXFayoX0lvLPKhzukR4zD4w+2OugZllB0U5VYWV5eHJRc CY53xnIwFnEu41snK15t8e/qao1/0y0mLE/qBtKLjqc1u8Ep0sN7oajyDXZ+4zNekfJz0n+NEYo8 iuJiy/RVv15WbfV8J6Rte1a9KvxjIG3SFA7Rv6MkoMZyB4jI6VwUnfucIQirYam6wXAZvibC3+Gl maOMzs/lYSO+M8g6xO/q5dwgzYMBEf6eWJ8T4e+L2wOa7ovNfcKJ/pRqhHeASOwP1IrmNlOdNAj/ ofUkzQ+6dZvNr3eGxDNrtLL8I+E4TvjH8SfDr4n1kgj/pNuzR0T4p/zsn2GWuXsjgv4B/Av/XASj +LRxewhV0h0m8zzLXxDB2bNSCED9laRE8pRHEd59fCVYb8ZHkqgsg7htmrbpdYSJ2HLc6xhAJSaT Lm78PhL4Fu3FCC7NyolLCd+1uCqtu6lNHzwZmqZrus92Z2L9p/bsxApiPna/JtjomydyHXMGnE85 B5ySM5DDOf2GyjsgBqRtBACGr4vwL0T4dRGZi5jPpDvNqZhKKVbGzp6jkPy8zZ1Wts/t9rHAletP 6K8bU49TxhgrS6RMksllFxZkYHb609h7bXNl3LYbsyN1GG8iI0nKojh9jZe1/OiqCmdodUldpEME d9J9jCIS2CUjYm3ZKpD41jgi/E/Q1WFn9MzoYHGg2Ef/9haHisPFAv0bprOx4j5uQ/Rg9H3yi6DB N/T3yW/wx0nBH27ftD5OktB+S3+cJEb6tv442S/Cd/THSWKo7+qPk4P4YMjfStm2zAs8jAi9IPzL yLCctAX286BRnyL7X9zkZQrcDYv5N7RNMPZdJzKGn0eD3xThX1uW8L+JLOHQJI0xPPxbZVnZ0LbE hQG7ezwDk0btqLs9mLcTc0TpAB+a0ftNbRcsOkeSRu+3RPh30ZLQ1d9CN5xOFbpLXz9S2/Rbxv5r bD08vG+L8O8t4z0UZKL1f1B2TVaNicb/UReRtrHwn1CyY8k1mNHh7naGLOnaq+EmqUHuUAcbYdQs v8+3tcFmP8mzMScyOn4P8HtHhP+SwI9Yx7+KgFcX0iDGKA6J8N90wV6MMxnwFazu05zYibqdYYDM fsNOII250r6j5lZuP+m11X5SB3i59hgAfVeE/x4BCv+G/9Ash5c9kjDZ+vKfSmXMtr4MZUCatMPo Kbk1ewxq1z6ltklloBuevdZiPgdtE/S9PG62l++7CvX+UedITkLTTWvpVVnpmDCd453SmB0pAXFZ /oY0jQznin2jkP7DxcHkx3AVpJPE/QXQ2HtK3NekoP8vEX5Ty31ifu9D7itB/4FynYKgzzlKARiA cGfuDordtndtFVyEhQo8FagJ4X9bgvZ/tE9RzhajPFXtr+hmRQqqScxkuxzf3ibcNiV8Uyu+6ktw 9I3zfRF+6+P9xvm+kXHGgltCyz4QIS1qLR4techG3OIVn7Uas4Qmm77USPn4nFJom72MNeAD00Us ogbQxU+hizknzKd0ER8ISCXrj3V0KL2jcSV9i4uqj31BlnMUMFIL6cbYBvnPmldNMrmOZdeHtopJ sKf3pAlzFA4WfcV8MV+GcxFLo6zwgtzY2AWgjx1avM5IeYz7rc+1rhAZIDIcq1K2GXBFKtyg+Yyv TG/MgNb9yM6mzOvGveh+OukaDjBthcdIZD2VkAbckfhGiCTcZRSxup70nEpUmNagLGhSUDRQaGws SHi89FgYjCwsCdrt0hjHjSaJd4B+3+OMOkX13wPOWN+xrx2Dp9Pusf0DmF994vyFLzzx4b2ju/// qVMPP/pp6f//8GlO/PjQqdOPPLQb//0jOQqznLe3hh/Ek9w1nQWVndKQx0NmYeE8UYGH3HEn6cxr TNL/VSRhaQalB5GZ5cGpAue5brZbTeSRdVlvbLRbnNob+mPN9attlWp51VNJwcHKiX1NEgtQSaew UCkgvwlcD5XqyQzCa4JvylReTcWdSnF+aumopTJJiHHex+zK1DoFeDOrjCH0St7D7t6iDuOP+toN t+Wxm6zPiYTqcHXkIHL8KcckKafC1MsC50hBxhZqm++26rXxqUJhBplsOHPSSeTUYR9dmZyemrrq n/RWV10GwD9TKpzbwlE4NV5acYNgpX5yzSvVWy1q4FJlrQYPwsLpcd6lHyzBEbPkVxpIAXzJQwS6 Zbovk+ysSWduJJlZX6suUVfdL0nImi131aU1kfT09rxWzV2j9RH8q1VaXLhAtdeQPB7lr9eDm3XO M433IT/NTOUGZ+pucOYYmS3c9a1GTaJRJmv4w2gvDTah2mivlG5W5Bb9pXZQqhF0qIQ4P4aHVmnB SWmLpSuFR8Yjn/BqveN9RLyNhlt1CXdOILxeQjK1xbomIlmwWmn7MqsypyFGN+WNgHMU03hP0hul 33yNMEPPlJpAI1z4vIeEQrgoEx/6S4g/TDRQbblNxoeatVxf5zjq/pYGGeNsJ0ctTVqZmYIoSRXH /awHlcnqisvkWiioNKvdnpAwRqmnCwWZ95ee8duLi3VO4pxId1W/RUgzvVq1yYREREucORqDfJ3I wQoaEc9Nzv6thnkUCmp0J03joobBmgByggnej92nGYwhJVAxXznks9kpEL1ZerrLzFE84Gru33Ar GKpJmrp1Ws1zrEgdyGsF6YwqrcU2WmxtRHhaE0m0bwAhfpVeTZQAQwDGmHoS7V7gvpfMLbCPtmQ4 QNqTjsM4ldRRsBRcU8+VeDz+mttSyQ0RHpge9YP2dZ/ntFwLqADB3mqT6gTkgTcV1awVKVSvWLxv AhVbjFOlFdSAg/Pzdl3OB58WM0ZnikLdauxUbvEAYW35JXL3CHEAswlFD2ahwHO7Xl3yFBHyAGoE py88lUiLVmFmoIjlpKR8tUNF1ZUYkEq3YdDvVY/69aDdVCDJR6PpZc8j7oz8QCXzlUZN4gFJZlOM Hyrlooah3lJv10M1i9omEdy3kwLYq57aboa5gwpMVxS35JrsBpZrlTqJ3fEpGZcaWbiYg7XXViAA qM61ts4wCXwm/WB9pZ4y9iqc6pRMy1fjNO4kqtVmAd6arvb7SNTUNhhkv1XBrTvrjLnRk/CnOebL PGVr9ZsRRZpkm/xqfRmt9VMqhbcfksbKwLBmF4PdUDlqVa8NYsMGaclh1ExVFWhqlQQhsT1fRYeo atIKsglGVS+vqymG1qoxmeps83RQMvKJa2BTW4yr60+b8S1SNoKd1VYkzcc2J/A2KvMy84oJlbYt aLmLMLDrpnRWagLrRCTNIYPqkDAVUsG4+/6yfV/H9JWU0IUQIAjqdVsFUHwgIWs5Fd0SO29xU1v1 FFRnlRBiLqXTJoK7ydGPiwLuF+dJXLfopbNSENCZUimiimulx6ksLn8G8cARz52TSioxTe9rr9Zj uSavg7m1kSkPxNklQPS4LKE8hwonpk3sF7Tc/Kki42qQT0ejCjb+DKCaJiWLdZcVUrz8aAC1YDbT xMf8iMnMRddrngmqzTNnHocI/oyRm3KgazXF8wGkXyAUV9e1sj1VbSyy0DtDGgB17ypHUtLNPlf1 WqR1eNUzZ7DXawW8Sb3DcMeUx7i3vTwrUzsXmApueq1lX2W5DSIRJmnKThepuAurPkrsS4HjWksX qRkQg5iVMkay3AlgzBqm1hbPFCaJ0YKjS8FBa04WTcj4yMnlJ0rTDxC9VGUMbGonuP4np79w9erl y7MTMkcpjd4nv6wu3YG5hJj4CifW7ugIve48jUeiOIYpfukkSwjq1rrXbpWuPDt78fKlK+dnL9Lz 1WTZszI16iR3VKtxXemjTNohTRHuDz3k631jRJ91LPbWauOqodwBNcArMlX6dU8uSbhles1GKkzD XWy3pNLCEFINJAJ5ssZkud6+usTZJ5tg79iwCu4cF5SqURJ68M6EE4rqMcqkgBe9sIzl8PgmpSNu Ueb0nGxTGydmofbHciTziVLUOu1C5N0Et6CqkeUTynCt5qr1JUOrpIupv6Ao2jwfaI5OcLXq1hvM kmACugCydBLkyFi+QoupYL20jL21hah8WcoHfmuFpTorFhpHCFs1uNTMJ125zQ2kR/xNOWgWOmee qhWsC33NIBc7nQZWkTTDK8SbPVutQqWySfT+yw1I95ZPE8xt6FeqxakCc8Ji4dhHXGhU3BU2XrjI TqvrpEk+3WBoGBBzfUIKUlVZfBBKlUXsulaN9jn/KhtcpL4BM0edp98p3VeYG9YtxWPWayKHKWCJ 7CfgJp/zWpCgNFX8k9AKV7ApGINHhKCXgwDdXlHSY1esBTRJE1IjFteNvICUnyxdIF3GXTEUpfXb dgCVENLCZCmfQqZWmjec1hXuWEGU6XWl0l6rLoFWC3KtQMS3FGC1f9IYb/TSn2s1dKRrOFl6hgYA 7HhGrho+S417yltc5DEz9gMYDmA3mEjYRSZK0mBz3SMu0ZpsrvDWdE7TsRseZvfYPXaP3WP32D12 j91j99g9do/dY/fYPXaP3WP3+P9x/C+228kqAPAAAA== --NextPart_Webmail_9m3u9jl4l_16169_1043705427-- From duncan@grisby.org Tue Jan 28 12:48:46 2003 Received: from grisby.dyndns.org (pc2-cmbg4-5-cust211.cmbg.cable.ntl.com [81.96.73.211]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0SCmk801126 for ; Tue, 28 Jan 2003 12:48:46 GMT Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h0SCmQj16097 for ; Tue, 28 Jan 2003 12:48:27 GMT Message-Id: <200301281248.h0SCmQj16097@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust211.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] ImR idl proposal In-Reply-To: Message from kendall bailey of "Wed, 22 Jan 2003 15:33:06 CST." <3E2F0E12.8010806@drakealumni.net> From: Duncan Grisby Date: Tue, 28 Jan 2003 12:48:26 +0000 Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: On Wednesday 22 January, kendall bailey wrote: > Possibly. It's too early to worry much about that. I suppose I'm > hoping that this become a standard part of the omniORB family. Still > free to work with other orbs, but an official omni* sub-project like > omniNotify. We'll see. I think it would be good for there to be an omniImR that is part of the omniORB suite, so I'm happy to go with that name. > I wasn't too thrilled with the term "program" either. I couldn't use > "adapter" as H&V does. However, there should be some logical grouping > of objects so that a bunch can be migrated all at once. The ImR could > be told that program X is now hosted in process Y rather than Z, and the > thousands of objects that once would have auto-started process Z now > will start process Y. The ImR will not store the identity of those > thousands of objects. Rather it knows only the "program" aka "adapter" > in H&V lingo. With a portable ImR there is no need to make all those > objects share a POA though. I haven't completely followed the discussion up to here, so this idea might be irrelevant, but I've been imagining a scheme where object identifiers are slash separated strings, like foo/bar/baz/wibble. The ImR keeps a mapping from partial names to programs (that are running or it can start). For example, the ImR might know that all names starting foo/bar are serviced by program A. When a request for foo/bar/baz/wibble comes in, it kicks A into action, and asks it for object baz/wibble. Later, the ImR might be reconfigured so that a single program supports all objects under name foo, meaning that now the program would be asked for bar/baz/wibble. I think this kind of scheme would avoid having to come up with names for the different kinds of entities. You just have simple strings, part of which are interpreted by the ImR, the other part by the programs it controls. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From krbailey6@mchsi.com Tue Jan 28 16:07:33 2003 Received: from sccmmhc02.mchsi.com (sccmmhc02.mchsi.com [204.127.203.184]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0SG7X811029 for ; Tue, 28 Jan 2003 16:07:33 GMT Received: from sccqwbc03 ([204.127.203.163]) by sccmmhc02.mchsi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20030128160730.FOAR5896.sccmmhc02.mchsi.com@sccqwbc03> for ; Tue, 28 Jan 2003 16:07:30 +0000 Received: from [12.216.165.141] by sccqwbc03; Tue, 28 Jan 2003 16:07:30 +0000 From: krbailey6@mchsi.com To: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] ImR idl proposal Date: Tue, 28 Jan 2003 16:07:30 +0000 X-Mailer: AT&T Message Center Version 1 (Nov 13 2002) X-Authenticated-Sender: a3JiYWlsZXk2QG1jaHNpLmNvbQ== Message-Id: <20030128160730.FOAR5896.sccmmhc02.mchsi.com@sccqwbc03> Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: I thought there would be some value to keeping part of the server identity out of the IOR's that the ImR generated. How would your scheme deal with migration of objects from one part of the tree to another? Say that all foo/bar objects need to move to the process B that also hosts abc/xyz objects? The IORs are already published, but now the IOR with foo/bar/baz/wibble really ought to be abc/xyz/baz/wibble in order to trigger startup of process B. This is why I thought a process name could be associated with one or more (possibly related in a hierarchy) subsystem names (I've dubbed them 'programs' so far). The IORs would carry only the subsystem names and object names, and the ImR would look up the current host process name. Your scheme could combine the subsytem/object name pair into a single structured string as you've described, but not eliminate the need for process names. If that's what you meant, then I can agree with that. My motivation for splitting subsystem names from object names was to avoid imposing any structure on the names' formats. If there is to be hierarchical structure, is it advisable to use delimiter characters as you suggest, or should we use a structured type similar to the way CosNaming does with NameComponent sequences?? I find myself always using the string representation of CosNaming::NameComponent sequences anyway, so structured strings are fine with me. In any case, I think the server process should see the whole identifier, and not just the trailing portion. The initial portions may correspond to POA names that the ProcessManager can use to traverse the POA hierarchy. Kendall > I haven't completely followed the discussion up to here, so this idea > might be irrelevant, but I've been imagining a scheme where object > identifiers are slash separated strings, like foo/bar/baz/wibble. The > ImR keeps a mapping from partial names to programs (that are running > or it can start). For example, the ImR might know that all names > starting foo/bar are serviced by program A. When a request for > foo/bar/baz/wibble comes in, it kicks A into action, and asks it for > object baz/wibble. Later, the ImR might be reconfigured so that a > single program supports all objects under name foo, meaning that now > the program would be asked for bar/baz/wibble. > > I think this kind of scheme would avoid having to come up with names > for the different kinds of entities. You just have simple strings, > part of which are interpreted by the ImR, the other part by the > programs it controls. > > Cheers, > > Duncan. From duncan@grisby.org Tue Jan 28 17:34:37 2003 Received: from grisby.dyndns.org (pc2-cmbg4-5-cust211.cmbg.cable.ntl.com [81.96.73.211]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0SHYa815386 for ; Tue, 28 Jan 2003 17:34:36 GMT Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h0SHYEr25206; Tue, 28 Jan 2003 17:34:15 GMT Message-Id: <200301281734.h0SHYEr25206@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust211.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: krbailey6@mchsi.com cc: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] ImR idl proposal In-Reply-To: Message from krbailey6@mchsi.com of "Tue, 28 Jan 2003 16:07:30 GMT." <20030128160730.FOAR5896.sccmmhc02.mchsi.com@sccqwbc03> From: Duncan Grisby Date: Tue, 28 Jan 2003 17:34:14 +0000 Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: On Tuesday 28 January, krbailey6@mchsi.com wrote: > I thought there would be some value to keeping part of the server > identity out of the IOR's that the ImR generated. How would your > scheme deal with migration of objects from one part of the tree to > another? Say that all foo/bar objects need to move to the process B > that also hosts abc/xyz objects? The IORs are already published, > but now the IOR with foo/bar/baz/wibble really ought to be > abc/xyz/baz/wibble in order to trigger startup of process B. That could be handled by just putting more than one entry for process B in the ImR, one for abc/xyz and one for foo/bar. > Your scheme could combine the subsytem/object name pair into a > single structured string as you've described, but not eliminate the > need for process names. If that's what you meant, then I can agree > with that. That's what I meant. > My motivation for splitting subsystem names from object > names was to avoid imposing any structure on the names' formats. I'm torn between whether that's a good idea or not. On the one hand, imposing structure on the names limits the things that programs can do with them; on the other hand, imposing structure makes everything easier to use, and opens the possibility for changing the level in the hierarchy at which the programs live. I'm not sure it will make much difference in the long run either way. > If there is to be hierarchical structure, is it advisable to use > delimiter characters as you suggest, or should we use a structured > type similar to the way CosNaming does with NameComponent > sequences?? I find myself always using the string representation of > CosNaming::NameComponent sequences anyway, so structured strings are > fine with me. I think the experience of NameComponents shows that using a sequence is a real pain to program, especially for C++. I think flat strings are much easier for everyone to deal with. Again, it's not a big deal either way. > In any case, I think the server process should see the whole > identifier, and not just the trailing portion. The initial portions > may correspond to POA names that the ProcessManager can use to > traverse the POA hierarchy. I think it would be sensible to give the process both the full name, and the bit that the ImR hasn't resolved. I can see situations where either would be useful. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From lockhart@fourpalms.org Thu Jan 30 00:36:56 2003 Received: from myst.fourpalms.org (dhcp-78-180-241.jpl.nasa.gov [137.78.180.241]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0U0at807567; Thu, 30 Jan 2003 00:36:55 GMT Received: from fourpalms.org (localhost.localdomain [127.0.0.1]) by myst.fourpalms.org (Postfix) with ESMTP id 88B24346073A; Wed, 29 Jan 2003 19:36:56 -0500 (EST) Message-ID: <3E3873A8.9070600@fourpalms.org> Date: Wed, 29 Jan 2003 16:36:56 -0800 From: Thomas Lockhart Organization: Yes User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Waller Cc: omniorb-list@omniorb-support.com, omniORB development list References: <20030129235636.69782.qmail@web13006.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [omniORB-dev] Re: [omniORB] Implementation Repository Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: > I'm very interested in joining this discussion as I > have been working on an Implementation Repository for > omniORB for almost 3 months now... Welcome. But the discussion has moved to omniorb-dev so you should subscribe to that; check the archives for the last couple of weeks for details. > I will send some IDL in my next posting; is it okay to > attach files to mailing list posts? Sure; IDL is not very big. - Tom From jwaller6@yahoo.co.uk Thu Jan 30 01:39:11 2003 Received: from web13001.mail.yahoo.com (web13001.mail.yahoo.com [216.136.174.11]) by raq2100.uk2net.com (8.10.2/8.10.2) with SMTP id h0U1dA810598 for ; Thu, 30 Jan 2003 01:39:10 GMT Message-ID: <20030130013914.51987.qmail@web13001.mail.yahoo.com> Received: from [69.4.163.56] by web13001.mail.yahoo.com via HTTP; Thu, 30 Jan 2003 01:39:14 GMT Date: Thu, 30 Jan 2003 01:39:14 +0000 (GMT) From: =?iso-8859-1?q?James=20Waller?= To: omniorb-dev@omniorb-support.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [omniORB-dev] Implementation Repository Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: Originally posted to the other mailing list by mistake... Will be posting some extra stuff soon; looks like there's been a lot of progress here lately, and I'm coming in a little bit late. I am hoping the work I've done may be of some help! --- James Waller wrote: > Date: Wed, 29 Jan 2003 23:56:36 +0000 (GMT) > From: James Waller > Subject: Implementation Repository > To: omniorb-list@omniorb-support.com > > Hello, > > First I'd like to apologise for waiting until now > before posting anything on this subject. I was > unable > to discover the recent interest on this topic until > now because I've been without an internet connection > for the first half of this month! > > I'm very interested in joining this discussion as I > have been working on an Implementation Repository > for > omniORB for almost 3 months now. It is nearly at the > point where it is usable; a working ImR daemon and > server interface library are just around the corner > (about two or three weeks before I have some code to > demonstrate). I intend to add an administration tool > as well. It only compiles on Linux at present and > its > makefiles are independent of the autoconf system. > > This ImR works in a very similar way to the one > described in the Henning paper and the "Advanced > CORBA > Programming with C++" book. Server programs are > registered with the ImR by name, then one or more > POAs > are registered with the ImR for each server. Any > object references created in those POAs at the > server > are translated to references to the ImR. Each server > has configurable parameters such as command-line > arguments, activation mode, user, group and so on; > calls are present in the ImR interface for accessing > this information. > > When a server starts up, it makes a call to the ImR > to > notify the ImR of its availability. A "manager" > object > is created in the ImR for each server with a > corresponding proxy object in the server itself, > provided by the server interface library. The > manager > object is responsible for sending "ping" requests to > the server (to check if it is still alive at certain > points) and sending instructions telling servers to > terminate themselves in an orderly fashion. The > corresponding proxy object receives these requests > and > deals with them in the appropriate way. > > I will send some IDL in my next posting; is it okay > to > attach files to mailing list posts? > > Cheers, > James Waller > > __________________________________________________ > Do You Yahoo!? > Everything you'll ever need on one web page > from News and Sport to Email and Music Charts > http://uk.my.yahoo.com > __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com From jwaller6@yahoo.co.uk Thu Jan 30 17:07:17 2003 Received: from web13007.mail.yahoo.com (web13007.mail.yahoo.com [216.136.174.17]) by raq2100.uk2net.com (8.10.2/8.10.2) with SMTP id h0UH7H823352 for ; Thu, 30 Jan 2003 17:07:17 GMT Message-ID: <20030130170719.86253.qmail@web13007.mail.yahoo.com> Received: from [69.4.163.56] by web13007.mail.yahoo.com via HTTP; Thu, 30 Jan 2003 17:07:19 GMT Date: Thu, 30 Jan 2003 17:07:19 +0000 (GMT) From: =?iso-8859-1?q?James=20Waller?= Subject: Re: [omniORB-dev] Implementation Repository To: omniorb-dev@omniorb-support.com In-Reply-To: <20030130013914.51987.qmail@web13001.mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-237453258-1043946439=:79013" Content-Transfer-Encoding: 8bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: --0-237453258-1043946439=:79013 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Id: Content-Disposition: inline Judging from what I've been reading so far, there is one major difference between the design I have worked on and the one being agreed here. That is, my ImR works on the premise that you don't register each and every object with the ImR, instead you register the POAs that contain the objects (as described in the Henning paper). My rationale for taking this approach is that if a server contains tens, hundreds or even more objects, the system can handle them in a more scalable fashion as there are fewer calls to the ImR. The disadvantage, of course, is that your servers (or more specifically, the library you link with your servers) has to mess around with object keys and is hence not portable between ORBs. Originally I felt that the advantages of that approach outweighed the disadvantages. With hindsight, the other approach would have made my ImR *much* simpler (there's quite a bit of code in there for manipulating object references, POAs and so on). Maybe the ImR could make both methods available, the register-every-object way for portable servers and the register-every-POA way for more scalable (but non-portable) servers. Comments anyone? I have attached the IDL for the Implementation Repository I have been working on. Basically the Repository interface contains the general administrative interface, and the Server interface is implemented by both the manager objects in the ImR and the proxy objects in the servers. Cheers, James [original message snipped] __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com --0-237453258-1043946439=:79013 Content-Type: application/octet-stream; name="omniImR.idl" Content-Transfer-Encoding: base64 Content-Description: omniImR.idl Content-Disposition: attachment; filename="omniImR.idl" bW9kdWxlIG9tbmlJbVIKewogICAgZXhjZXB0aW9uIEV4ZWNGYWlsdXJlCiAg ICB7CiAgICAgICAgc3RyaW5nIHdoYXQ7CiAgICB9OwoKICAgIGV4Y2VwdGlv biBCYWRQYXJhbQogICAgewogICAgICAgIHN0cmluZyB3aGF0OwogICAgfTsK CiAgICB0eXBlZGVmIHNlcXVlbmNlPHN0cmluZz4gU3RyaW5nU2VxOwoKICAg IHN0cnVjdCBTZXJ2ZXJEZXNjCiAgICB7CiAgICAgICAgc3RyaW5nIG5hbWU7 CiAgICAgICAgYm9vbGVhbiBhY3RpdmU7CiAgICAgICAgU3RyaW5nU2VxIHBv YV9uYW1lczsKICAgICAgICBTdHJpbmdTZXEgY21kbGluZTsKICAgICAgICBT dHJpbmdTZXEgcGFyYW1zOwogICAgfTsKCiAgICB0eXBlZGVmIHNlcXVlbmNl PFNlcnZlckRlc2M+IFNlcnZlckRlc2NTZXE7CgogICAgaW50ZXJmYWNlIFNl cnZlcgogICAgewogICAgICAgIG9uZXdheSB2b2lkIHBpbmcoKTsKICAgICAg ICBvbmV3YXkgdm9pZCBkZWFjdGl2YXRlTm90aWZ5KCk7CiAgICB9OwoKICAg IGludGVyZmFjZSBSZXBvc2l0b3J5CiAgICB7CiAgICAgICAgZW51bSBTdGF0 dXMKICAgICAgICB7CiAgICAgICAgICAgIFNVQ0NFU1MsCiAgICAgICAgICAg IFNWUl9OT1RfUkVHLAogICAgICAgICAgICBTVlJfUkVHLAogICAgICAgICAg ICBQT0FfTk9UX1JFRywKICAgICAgICAgICAgUE9BX1JFRywKICAgICAgICAg ICAgU1ZSX0FDVElWQVRJTkcsCiAgICAgICAgICAgIFNWUl9BQ1RJVkUsCiAg ICAgICAgICAgIFNWUl9JTkFDVElWRSwKICAgICAgICAgICAgVElNRU9VVCwK ICAgICAgICAgICAgSU5URVJOQUxfRVJST1IKICAgICAgICB9OwoKICAgICAg ICBTdGF0dXMgcmVnaXN0ZXJQT0EoaW4gc3RyaW5nIHN2cl9uYW1lLCBpbiBz dHJpbmcgcG9hX25hbWUpOwogICAgICAgIFN0YXR1cyBkZXJlZ2lzdGVyUE9B KGluIHN0cmluZyBwb2FfbmFtZSk7CgogICAgICAgIFN0YXR1cyByZWdpc3Rl clNlcnZlcihpbiBzdHJpbmcgc3ZyX25hbWUsCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGluIFN0cmluZ1NlcSBjbWRsaW5lLCBpbiBTdHJpbmdT ZXEgcGFyYW1zKQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICByYWlz ZXMoQmFkUGFyYW0pOwoKICAgICAgICBTdGF0dXMgZGVyZWdpc3RlclNlcnZl cihpbiBzdHJpbmcgc3ZyX25hbWUpOwoKICAgICAgICBTdGF0dXMgc2VydmVy UmVhZHkoaW4gc3RyaW5nIHN2cl9uYW1lLCBpbiBTZXJ2ZXIgcmVtb3RlX3N2 ciwKICAgICAgICAgICAgICAgICAgICAgICAgICAgb3V0IFNlcnZlciBzdnJf cHJveHkpOwoKICAgICAgICBTdGF0dXMgbW9kaWZ5U2VydmVyQ29tbWFuZChp biBzdHJpbmcgc3ZyX25hbWUsIGluIFN0cmluZ1NlcSBjbWRsaW5lKTsKICAg ICAgICBTdGF0dXMgbW9kaWZ5U2VydmVyUGFyYW1zKGluIHN0cmluZyBzdnJf bmFtZSwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluIFN0 cmluZ1NlcSBwYXJhbXMpIHJhaXNlcyhCYWRQYXJhbSk7CgogICAgICAgIFNl cnZlckRlc2NTZXEgZ2V0U2VydmVycygpOwoKICAgICAgICBTdGF0dXMgYWN0 aXZhdGVTZXJ2ZXIoaW4gc3RyaW5nIHN2cl9uYW1lKSByYWlzZXMoRXhlY0Zh aWx1cmUpOwogICAgICAgIFN0YXR1cyBkZWFjdGl2YXRlU2VydmVyKGluIHN0 cmluZyBzdnJfbmFtZSk7CiAgICB9Owp9Owo= --0-237453258-1043946439=:79013-- From kendall@drakealumni.net Thu Jan 30 18:36:45 2003 Received: from sccmmhc02.mchsi.com (sccmmhc02.mchsi.com [204.127.203.184]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0UIac827609 for ; Thu, 30 Jan 2003 18:36:45 GMT Received: from drakealumni.net ([12.216.164.190]) by sccmmhc02.mchsi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030130183635.FIAE5896.sccmmhc02.mchsi.com@drakealumni.net>; Thu, 30 Jan 2003 18:36:35 +0000 Message-ID: <3E397027.5010609@drakealumni.net> Date: Thu, 30 Jan 2003 12:34:16 -0600 From: kendall bailey User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Waller CC: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] Implementation Repository References: <20030130170719.86253.qmail@web13007.mail.yahoo.com> In-Reply-To: <20030130170719.86253.qmail@web13007.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: James Waller wrote: >Judging from what I've been reading so far, there is >one major difference between the design I have worked >on and the one being agreed here. That is, my ImR >works on the premise that you don't register each and >every object with the ImR, instead you register the >POAs that contain the objects (as described in the >Henning paper). > > Not quite. Each IOR for a persistent object must be generated by the ImR, that much is true. But the ImR does not store per-object information. That would not scale well. Some load balancing ideas I'm working on in parallel with this ImR work would require the ImR to store object references for all *active* replica objects. I don't see any way around that. The ImR prototype and IDL I've posted has 2 ways to create a persistent reference. The generatePersistent is used to create a reference based solely on the info passed in. The ImR does not remember anything about the call. makePersistent must be called from a currently registered server process, but even then, the ImR does not add anything to it's persistent store when creating the indirect reference. All of the needed info is encoded into the indirect reference itself. The difference I see in your IDL is that you tie things to POA identities. That's perfect if the POAs themselves cooperate. If not, I see no reason to force the concept of a POA identity into the ImR. Its still a valid partitioning of the location domain, but perhaps not the only one. >Originally I felt that the advantages of that approach >outweighed the disadvantages. With hindsight, the >other approach would have made my ImR *much* simpler >(there's quite a bit of code in there for manipulating >object references, POAs and so on). Maybe the ImR >could make both methods available, the >register-every-object way for portable servers and the >register-every-POA way for more scalable (but >non-portable) servers. Comments anyone? > > Are you saying you've modified the POA itself? You may have to convince Duncan to merge your code if so. I like the portable approach, since I don't see the explicit creation of the persistent references to be much of a burden. Portable Helper libraries to ease the job of the server processes should be part of the ImR project. Are you planning to release your ImR under an open license? I'd be interested in seeing the code. Kendall From jwaller6@yahoo.co.uk Thu Jan 30 19:22:34 2003 Received: from web13001.mail.yahoo.com (web13001.mail.yahoo.com [216.136.174.11]) by raq2100.uk2net.com (8.10.2/8.10.2) with SMTP id h0UJMX829812 for ; Thu, 30 Jan 2003 19:22:33 GMT Message-ID: <20030130192236.42392.qmail@web13001.mail.yahoo.com> Received: from [69.4.163.56] by web13001.mail.yahoo.com via HTTP; Thu, 30 Jan 2003 19:22:36 GMT Date: Thu, 30 Jan 2003 19:22:36 +0000 (GMT) From: =?iso-8859-1?q?James=20Waller?= Subject: Re: [omniORB-dev] Implementation Repository To: kendall bailey Cc: omniorb-dev@omniorb-support.com In-Reply-To: <3E397027.5010609@drakealumni.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: > Not quite. Each IOR for a persistent object must be > generated by the > ImR, that much is true. But the ImR does not store > per-object > information. That would not scale well. > [snip] Right, but I believe that even having to make a separate call to the ImR to get an IOR for every object (regardless of whether the ImR stores anything) will adversely affect scalability. If a server wants to publish a ton of object references, that's still a lot of calls to the ImR which makes it become more of a bottleneck. However, maybe a way to (at least partially) alleviate this would be to allow the server to get IORs en masse by making one call to the ImR with a whole load of object references. I haven't looked at your prototype yet, but I will as soon as I have time. This load-balancing idea sounds interesting. My ImR does not go into the realm of load-balancing as I tried to limit the initial scope of the thing. > Are you saying you've modified the POA itself? No. This ImR does not rely on any special modifications to omniORB itself. What happens is as follows: the ImR registers the fully-qualified name of each POA internally and creates an actual CORBA POA to match (if this isn't done, LocateRequest messages fail). It then uses an interceptor to catch incoming requests, get the POA names from their object keys, match them to a registered POA and redirect the call to the server under which that POA is registered. Of course, if the server/POA combination is registered, the ImR will reply with an OBJECT_NOT_EXIST exception. The server interface library works by using an encodeIOR interceptor to detect when an IOR is encoded for an object that belongs to one of the registered POAs. In this case the interceptor takes the IOR and replaces the address information with that of the ImR. Again this means analysing the object keys which makes the server library non-portable between ORBs, as does the use of the interceptor. But this takes place entirely within the server and does not involve the ImR at all. > Are you planning to release your ImR under an open > license? I'd be > interested in seeing the code. > Yes, absolutely. It's not usable yet, though. I need a little more time to complete some essential parts and do some further testing - probably a couple of weeks. By then it should consist of a feature-complete, alpha quality ImR daemon, server library and admin client program. I would like it if we can pool our ideas and that (at least some of) the work I've done could become part of an 'official' omniORB Implementation Repository. Cheers, James __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com From kendall@drakealumni.net Thu Jan 30 20:12:49 2003 Received: from sccmmhc01.mchsi.com (sccmmhc01.mchsi.com [204.127.203.183]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h0UKCn832223 for ; Thu, 30 Jan 2003 20:12:49 GMT Received: from drakealumni.net ([12.216.164.190]) by sccmmhc01.mchsi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20030130201246.TBTI2338.sccmmhc01.mchsi.com@drakealumni.net>; Thu, 30 Jan 2003 20:12:46 +0000 Message-ID: <3E3986B3.9080105@drakealumni.net> Date: Thu, 30 Jan 2003 14:10:27 -0600 From: kendall bailey User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Waller CC: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] Implementation Repository References: <20030130192236.42392.qmail@web13001.mail.yahoo.com> In-Reply-To: <20030130192236.42392.qmail@web13001.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: James Waller wrote: >Right, but I believe that even having to make a >separate call to the ImR to get an IOR for every >object (regardless of whether the ImR stores anything) >will adversely affect scalability. If a server wants >to publish a ton of object references, that's still a >lot of calls to the ImR which makes it become more of >a bottleneck. However, maybe a way to (at least >partially) alleviate this would be to allow the server >to get IORs en masse by making one call to the ImR >with a whole load of object references. > > Each time a distinct client uses one of the indirect references, it hits the ImR first. I would think this would happen as much or more often than generation of the references in the first place, and so you may be avoiding a small percentage of the load the ImR will face. I just measured my prototype at 600 indirect reference creations/sec. That's on a 450 MHz pII running lots of other desktop stuff too. I like the batch request idea. If the result of a database request is to be returned as a bunch of indirect persistent references, then it makes a lot of sense for the ImR to handle them in one go. But hey, if the interceptor is already written to do the job, I won't argue. One of my goals is for the ImR to work with C++ and Python servers. Can the interceptor be installed in a Python server? Kendall From jwaller6@yahoo.co.uk Thu Jan 30 20:32:15 2003 Received: from web13006.mail.yahoo.com (web13006.mail.yahoo.com [216.136.174.16]) by raq2100.uk2net.com (8.10.2/8.10.2) with SMTP id h0UKWE800704 for ; Thu, 30 Jan 2003 20:32:14 GMT Message-ID: <20030130203217.43474.qmail@web13006.mail.yahoo.com> Received: from [69.4.163.56] by web13006.mail.yahoo.com via HTTP; Thu, 30 Jan 2003 20:32:17 GMT Date: Thu, 30 Jan 2003 20:32:17 +0000 (GMT) From: =?iso-8859-1?q?James=20Waller?= Subject: Re: [omniORB-dev] Implementation Repository To: kendall bailey Cc: omniorb-dev In-Reply-To: <3E3986B3.9080105@drakealumni.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: > Each time a distinct client uses one of the indirect > references, it hits > the ImR first. I would think this would happen as > much or more often > than generation of the references in the first > place, and so you may be > avoiding a small percentage of the load the ImR will > face. [snip] Well, I'm starting to come around to the idea; it imposes less restrictions from an ORB portability standpoint and it doesn't tie the ImR to the POA, i.e. it would work with old BOA-based servers. That's something I started to think about recently. Plus it would allow me to shave a whole lot of code off what I've got now! > But hey, if the interceptor is already written to do > the job, I won't > argue. One of my goals is for the ImR to work with > C++ and Python > servers. Can the interceptor be installed in a > Python server? > > Kendall > You got me there. My current implementation does not support Python, that would probably require a Python-based implementation of the server helper library. That's assuming the interceptor stuff is still available. I've dabbled a little bit with Python but I'm not familiar with omniORB's Python API. It's something that I intended to do later; I wanted to get something working with C++ to start with. By switching my design to require explicit publishing of IORs to the ImR, this would remove the need for the interceptor stuff from the server side hence trimming down the server helper library and making it easier to port to other languages. I need to do some serious thinking about all this. Cheers, James __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com From jwaller6@yahoo.co.uk Fri Jan 31 18:59:49 2003 Received: from web13006.mail.yahoo.com (web13006.mail.yahoo.com [216.136.174.16]) by raq2100.uk2net.com (8.10.2/8.10.2) with SMTP id h0VIxn800774 for ; Fri, 31 Jan 2003 18:59:49 GMT Message-ID: <20030131185951.34881.qmail@web13006.mail.yahoo.com> Received: from [69.4.163.56] by web13006.mail.yahoo.com via HTTP; Fri, 31 Jan 2003 18:59:51 GMT Date: Fri, 31 Jan 2003 18:59:51 +0000 (GMT) From: =?iso-8859-1?q?James=20Waller?= To: sveta@txcorp.com Cc: omniorb-dev In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [omniORB-dev] RE: [omniORB] Implementation Repository Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: > I have been using omiifr which works pretty well > with > omniORB. I think we might be talking about different things here. I believe omniifr is an Interface Repository (something I know nothing about :-), whereas this is about creating an Implementation Repository which is a completely different thing. > Is your implementation independent? Yes - at the moment it is built completely separately from the omniORB package, although it does depend on it. Cheers, James __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com From Christian.Perez@irisa.fr Thu Feb 20 17:16:32 2003 Received: from w3ext.irisa.fr (w3ext.irisa.fr [131.254.254.10]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h1KHGW832305 for ; Thu, 20 Feb 2003 17:16:32 GMT Received: from irisa.fr (parasolier.irisa.fr [131.254.12.48]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by w3ext.irisa.fr (Postfix) with ESMTP id BD27730450 for ; Thu, 20 Feb 2003 18:16:34 +0100 (MET) Message-ID: <3E550ED3.A06F27DE@irisa.fr> Date: Thu, 20 Feb 2003 18:22:27 +0100 From: Christian Perez X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18-19.7.x i686) X-Accept-Language: en, fr, es MIME-Version: 1.0 To: omniorb-dev@omniorb-support.com Content-Type: multipart/mixed; boundary="------------D90DEE9F698B8409A5F9EDCB" Subject: [omniORB-dev] Removing an entry from proxyObjectFactory Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. --------------D90DEE9F698B8409A5F9EDCB Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hello, We would like to dynamically be able to load/unload code into a server. It appears to work fine except for the management of proxyObjectFactory. The proxyObjectFactory global variables in the IDL generated files correctly register themself thanks to their constructor. However, there is no destructor. When such a code is unloaded from the memory, the list of registered proxyObjectFactory is incorrect because it contains dangling pointers. A solution is to implement the destructor of proxyObjectFactory. Hence, proxyObjectFactory are going to be correctly removed. In attachement, you'll find such an implementation of proxyFactory.cc derived from omniORB3 (location src/lib/omniORB2/orbcore/proxyFactory.cc). This implementation is based on the used of the map of the C++ STL. As the proxyObjectFactory API is the same in omniORB4, the same modification should work. It would be very nice if such a patch can be applied to omniORB. Best regards, Christian Pérez -- Research scientist - PARIS Project - IRISA/INRIA http://www.irisa.fr/paris/ --------------D90DEE9F698B8409A5F9EDCB Content-Type: text/plain; charset=us-ascii; name="proxyFactory-fix.cc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="proxyFactory-fix.cc" #include #ifdef HAS_pch #pragma hdrstop #endif #include #include typedef map ofl_t; // We used a pointer because we do not know how to control // the initialization of global variables. static ofl_t *_ofl; proxyObjectFactory::~proxyObjectFactory() { _ofl->erase(pd_repoId); } proxyObjectFactory::proxyObjectFactory(const char* repoId) { // The first time such an object is build, it has to // initialize the _ofl object. So, we are ablt to control // the order of initialization./ if (_ofl == 0) { _ofl = new ofl_t(); } OMNIORB_ASSERT(repoId); pd_repoId = CORBA::string_dup(repoId); // This code could be concurrently called with a lookup. // It should be protected with a mutex ofl_t::iterator it = _ofl->find(pd_repoId); if (it != _ofl->end() ) { it->second = this; if( omniORB::trace(15) ) omniORB::logf("Replaced proxyObjectFactory for %s.", repoId); } else { (*_ofl)[repoId] = this; } } void proxyObjectFactory::shutdown() { _ofl->clear(); } proxyObjectFactory* proxyObjectFactory::lookup(const char* repoId) { // This code has should be concurrently called with an constructor. // It should be protected with mutex OMNIORB_ASSERT(repoId); ofl_t::iterator it = _ofl->find(repoId); if ( it != _ofl->end() ) return it->second; else return 0; } --------------D90DEE9F698B8409A5F9EDCB-- From duncan@grisby.org Tue Feb 25 15:21:05 2003 Received: from grisby.dyndns.org (pc2-cmbg4-5-cust210.cmbg.cable.ntl.com [81.96.73.210]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h1PFL5819355 for ; Tue, 25 Feb 2003 15:21:05 GMT Received: from grisby.org (dpg1@localhost) by grisby.dyndns.org (8.11.6/8.11.6) with ESMTP id h1PFKRi19787; Tue, 25 Feb 2003 15:20:28 GMT Message-Id: <200302251520.h1PFKRi19787@grisby.dyndns.org> X-Authentication-Warning: pc2-cmbg4-5-cust210.cmbg.cable.ntl.com: dpg1 owned process doing -bs To: Christian Perez cc: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] Removing an entry from proxyObjectFactory In-Reply-To: Message from Christian Perez of "Thu, 20 Feb 2003 18:22:27 +0100." <3E550ED3.A06F27DE@irisa.fr> From: Duncan Grisby Date: Tue, 25 Feb 2003 15:20:26 +0000 Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: , List-Archive: On Thursday 20 February, Christian Perez wrote: > The proxyObjectFactory global variables in the IDL generated files correctly > register themself thanks to their constructor. However, there is > no destructor. When such a code is unloaded from the memory, > the list of registered proxyObjectFactory is incorrect because it contains > dangling pointers. There are fundamental difficulties with unloading stubs, which is why it is not implemented. To unload stubs, it is essential that there are no object references from those stubs instantiated. There is a race condition, however, where a thread may be receiving an object reference that unexpectedly claims to be of a type supported in the stubs that are being unloaded. In that case, a new object reference could be created just as the stubs are being unloaded. If you can convince yourself that that situation will never arise in your application, it would be safe to unload stubs, and unregister their proxyObjectFactories. [...] > In attachement, you'll find such an implementation of proxyFactory.cc > derived from omniORB3 (location src/lib/omniORB2/orbcore/proxyFactory.cc). > This implementation is based on the used of the map of the C++ STL. There are two problems here. First, your suggestion is not thread safe. Second, it is not possible to use STL within omniORB, since it is not available everywhere. Cheers, Duncan. -- -- Duncan Grisby -- -- duncan@grisby.org -- -- http://www.grisby.org -- From Christian.Perez@irisa.fr Wed Feb 26 15:53:23 2003 Received: from w3ext.irisa.fr (w3ext.irisa.fr [131.254.254.10]) by raq2100.uk2net.com (8.10.2/8.10.2) with ESMTP id h1QFrN825254 for ; Wed, 26 Feb 2003 15:53:23 GMT Received: from irisa.fr (parasolier.irisa.fr [131.254.12.48]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by w3ext.irisa.fr (Postfix) with ESMTP id 016343046E for ; Wed, 26 Feb 2003 16:53:24 +0100 (MET) Message-ID: <3E5CE4A1.22AA9EA@irisa.fr> Date: Wed, 26 Feb 2003 17:00:33 +0100 From: Christian Perez X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.18-19.7.x i686) X-Accept-Language: en, fr, es MIME-Version: 1.0 Cc: omniorb-dev@omniorb-support.com Subject: Re: [omniORB-dev] Removing an entry from proxyObjectFactory References: <200302251520.h1PFKRi19787@grisby.dyndns.org> Content-Type: multipart/mixed; boundary="------------30269C50EFB09E59EDDFEC71" Sender: omniorb-dev-admin@omniorb-support.com Errors-To: omniorb-dev-admin@omniorb-support.com X-BeenThere: omniorb-dev@omniorb-support.com X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion of omniORB development List-Unsubscribe: ,