Discussion:
[omniORB] [Q] how to perge dead services from Naming service
V S P
2009-04-21 10:48:11 UTC
Permalink
Hi,
I am working on a simple
'load balancing' for my client side.

I have servant object's named 'OTRQ'
when they register with the naming service they register
as OTRQ__hostnm__ProcessId

Then the client asks the naming service for a list of registered
servants (hopefully the naming convention above makes them unique -- I
could not come up with anything 'brigher' that this)
And then it randomly selects one -- and works with that.

The problem is, when traversing the list of servants I see dead
servants (that is those processes are not running)
-- I do not want them. When I restart the servants, of course,
the chance that they will bind to a 'dead' name is slim (but I still
support it by calling rebind).

Is there something I can configure in the naming service to
'automagically remove' dead servants as soon as possible?
or is there a more standard load-balancing scheme?

omni 4.1.3

thank you,
Vlad
--
V S P
***@fastmail.fm
--
http://www.fastmail.fm - Faster than the air-speed velocity of an
unladen european swallow
V S P
2009-04-21 23:27:11 UTC
Permalink
Just as a follow up to my question

if there is no way to achieve what I am looking for,
does anybody have
an example of a program that
'pings' all the entries in the naming service
and then asks them to be destroyed if they are not
valid

May be this is a more standard way... but I am stuck now.

Thank you in advance,
Vlad
Post by V S P
Hi,
I am working on a simple
'load balancing' for my client side.
I have servant object's named 'OTRQ'
when they register with the naming service they register
as OTRQ__hostnm__ProcessId
Then the client asks the naming service for a list of registered
servants (hopefully the naming convention above makes them unique -- I
could not come up with anything 'brigher' that this)
And then it randomly selects one -- and works with that.
The problem is, when traversing the list of servants I see dead
servants (that is those processes are not running)
-- I do not want them. When I restart the servants, of course,
the chance that they will bind to a 'dead' name is slim (but I still
support it by calling rebind).
Is there something I can configure in the naming service to
'automagically remove' dead servants as soon as possible?
or is there a more standard load-balancing scheme?
omni 4.1.3
thank you,
Vlad
--
V S P
--
http://www.fastmail.fm - Faster than the air-speed velocity of an
unladen european swallow
_______________________________________________
omniORB-list mailing list
http://www.omniorb-support.com/mailman/listinfo/omniorb-list
--
V S P
***@fastmail.fm
--
http://www.fastmail.fm - The way an email service should be
Duncan Grisby
2009-04-28 19:49:55 UTC
Permalink
Post by V S P
I have servant object's named 'OTRQ'
when they register with the naming service they register
as OTRQ__hostnm__ProcessId
Then the client asks the naming service for a list of registered
servants (hopefully the naming convention above makes them unique -- I
could not come up with anything 'brigher' that this)
And then it randomly selects one -- and works with that.
The problem is, when traversing the list of servants I see dead
servants (that is those processes are not running)
-- I do not want them. When I restart the servants, of course,
the chance that they will bind to a 'dead' name is slim (but I still
support it by calling rebind).
Is there something I can configure in the naming service to
'automagically remove' dead servants as soon as possible?
or is there a more standard load-balancing scheme?
That's not really the way the CORBA naming service is intended to be
used. It is just a simple lookup mechanism from names to object
references. It doesn't make any judgement about whether the object
references correspond to objects that are currently active or not.

You would be much better off implementing your own simple object
registry that your objects register with. The registry can then
periodically ping the objects (or the objects periodically ping the
registry if that's more appropriate).

Cheers,

Duncan.
--
-- Duncan Grisby --
-- ***@grisby.org --
-- http://www.grisby.org --
V S P
2009-04-29 01:27:01 UTC
Permalink
Hi
thank you

that's what I ended up to doing
I have in every server now a 'ping' method

then I implemented a new client that periodically pins
everything in the naming service within a mutex lock
(that has my name pattern)
if ping does not work, I then remove the object
from the naming service by calling unbind
at first I was trying to do 'unbind' and then 'destroy'
but I do not think 'destroy' would work on object that is already
not active

(unlike delete NULL in C++ that does not crash if ptr is NULL)

so I just left unbind.
Post by Duncan Grisby
Post by V S P
I have servant object's named 'OTRQ'
when they register with the naming service they register
as OTRQ__hostnm__ProcessId
Then the client asks the naming service for a list of registered
servants (hopefully the naming convention above makes them unique -- I
could not come up with anything 'brigher' that this)
And then it randomly selects one -- and works with that.
The problem is, when traversing the list of servants I see dead
servants (that is those processes are not running)
-- I do not want them. When I restart the servants, of course,
the chance that they will bind to a 'dead' name is slim (but I still
support it by calling rebind).
Is there something I can configure in the naming service to
'automagically remove' dead servants as soon as possible?
or is there a more standard load-balancing scheme?
That's not really the way the CORBA naming service is intended to be
used. It is just a simple lookup mechanism from names to object
references. It doesn't make any judgement about whether the object
references correspond to objects that are currently active or not.
You would be much better off implementing your own simple object
registry that your objects register with. The registry can then
periodically ping the objects (or the objects periodically ping the
registry if that's more appropriate).
Cheers,
Duncan.
--
-- Duncan Grisby --
-- http://www.grisby.org --
--
V S P
***@fastmail.fm
--
http://www.fastmail.fm - Choose from over 50 domains or use your own
Loading...