Archived
This forum has been archived. Please start a new discussion on GitHub.
Adapter ID not registered with Ice Storm
in Help Center
I am making the following call from a server ...
communicator()->createObjectAdapterWithEndpoints( adapterName, "default" );
Where adapterID is retrieved from a database and could be different depending on the host the server is started on.
If I specifically include the following line ...
hts_hemlock.AdapterId=hts_hemlock
into the Ice Config file, where "hts_hemlock" is "adapterName" from the above, the adapter gets registered with the Ice Grid/Locator. If I don't include the line, the adapter does not. Since the adapter names are dynamically generated from the DB, I would prefer not to have to hard-code the AdapterIDs into the Ice Config file. Is there a way to do this?
communicator()->createObjectAdapterWithEndpoints( adapterName, "default" );
Where adapterID is retrieved from a database and could be different depending on the host the server is started on.
If I specifically include the following line ...
hts_hemlock.AdapterId=hts_hemlock
into the Ice Config file, where "hts_hemlock" is "adapterName" from the above, the adapter gets registered with the Ice Grid/Locator. If I don't include the line, the adapter does not. Since the adapter names are dynamically generated from the DB, I would prefer not to have to hard-code the AdapterIDs into the Ice Config file. Is there a way to do this?
0
Comments
-
Hi Robert,
You should be careful with adapter names and adapter IDs, as they are not the same:
- an adapter name uniquely identifies an object adapter within an Ice communicator; the communicator uses this name to look up the object adapter's configuration
A communicator has usually 1 or a few object adapters, so you can use simple names that you hard-code in your application source files.
- an adapter ID uniquely identifies an object adapter within an IceGrid deployment; to ensure uniqueness, these IDs are often longer and more complicated than object adapter names.
Then, if you use IceGrid - and adapter IDs - you usually also use IceGrid to:
- generate the Ice config file for your servers, from your server description in IceGrid
- start these servers (using this generated config)
- monitor these servers
It's possible but unusual to use IceGrid without generated config for your servers. If that's what you're doing, is there any reason for not using the more common setup?
Best regards,
Bernard0 -
So let me explain my intentions a bit further ...
I'd like clients to use a well known name like "channel_1" and get a proxy back to the appropriate servant which may be on any number of hosts. I know Ice supports well known names, put would prefer not to pollute it's name space with 100+ names.
So the idea is for all clients to first pass a well known name to a special service, which simply returns a proxy to some other service. The special service queries our database for a proxy string associated with that well known name, calls stringToProxy and returns that proxy to the client. This is similar to what the IceGrid/Locator service does.
A channel server will start on every host where there's hardware. Each server reads the database for its object adapter and the channels it will add to that object adapter. This is why I was trying to avoid putting the objectAdapter in the server Ice config file. I would also like to use one Ice Config file for all channel servers.
I wasn't going to use IceGrid to start up the channel servers, because I did not want to introduce any additional command latency. Instead, the servers will start at computer boot time and run forever.
This is the proposed plan anyways ...0 -
I'd like clients to use a well known name like "channel_1" and get a proxy back to the appropriate servant which may be on any number of hosts. I know Ice supports well known names, put would prefer not to pollute it's name space with 100+ names.
So the idea is for all clients to first pass a well known name to a special service, which simply returns a proxy to some other service. The special service queries our database for a proxy string associated with that well known name, calls stringToProxy and returns that proxy to the client. This is similar to what the IceGrid/Locator service does.
Yes. You could use IceGrid to map these 100+ well-known names to proxies, or implement such a service yourself, it's up to you.A channel server will start on every host where there's hardware. Each server reads the database for its object adapter and the channels it will add to that object adapter. This is why I was trying to avoid putting the objectAdapter in the server Ice config file. I would also like to use one Ice Config file for all channel servers.
All these config files could be similar; in particular they can probably contain properties for a single object adapter with a simple name like "Channel". But they can't be identical since these adapters needs unique IDs, e.g.
# server 1
Channel.AdapterID=server1-Channel
#server2
Channel.AdapterID=server2-Channel
etc.I wasn't going to use IceGrid to start up the channel servers, because I did not want to introduce any additional command latency. Instead, the servers will start at computer boot time and run forever.
This is the proposed plan anyways ...
You should reconsider, since using IceGrid to start these servers would simplify greatly configuration, and would not introduce any latency.
You can configure IceGrid to immediately start a server and automatically restart this server in case of a crash ... use the 'always' activation policy: Server Activation
You would just need to install icegridnode on all your computers, and configure icegridnode to start at boot-time. We provide the corresponding daemon scripts for Red Hat and SuSE Linux.
Best regards,
Bernard0 -
Thanks Bernard, that was helpful.0
