Q: adavantage of ServantActivator

Q: adavantage of ServantActivator

Post by zhou » Thu, 10 Jul 2003 23:43:55



Hi there,

1) Assume a servant is derived from RefCountServantBase, does deactivate_object() eventually causes POA to call
_remove_ref() on the servant?

2) It is said that the best way to clean up servants with a RETAIN POA is to use ServantActivator. I donot see how.
Assume servant dervies from RefCountServantBase,

Without ServantActivator, POA invokes _remove_ref() on the servant after ALL method calls on it complete. If the ref.
count drops to 0, delete is called on the servant. This should guarantee that servant is cleaned up properly. I donot
see the value added by ServantActivator? Did I miss anything?

Thanks.

Yan

 
 
 

Q: adavantage of ServantActivator

Post by Michi Hennin » Fri, 11 Jul 2003 20:31:33



> Hi there,

> 1) Assume a servant is derived from RefCountServantBase, does deactivate_object() eventually causes POA to call
> _remove_ref() on the servant?

Yes. Reference-counted servants disappear once the last reference to
them is dropped. If you have a reference-counted servant in the AOM,
it will disappear once the last request drains out of the servant.

Quote:> 2) It is said that the best way to clean up servants with a RETAIN POA is to use ServantActivator.

Who says that? First thing I've heard of this.

Quote:> I donot see how.

Me neither :-)

Quote:> Assume servant dervies from RefCountServantBase,

> Without ServantActivator, POA invokes _remove_ref() on the servant after ALL method calls on it complete. If the ref.
> count drops to 0, delete is called on the servant. This should guarantee that servant is cleaned up properly. I donot
> see the value added by ServantActivator? Did I miss anything?

No, a servant activator adds no value to this scenario. In fact,
servant activators in general add comparatively little value:
they allow you to perform incremental initialization, which can be
useful if servants are expensive to initialize. But servant activators
to not improve scalability because, if the server runs for long enough,
eventually, all objects will be touched by one client or another,
meaning that you end up with servants for all objects in memory anyway.

For that reason, servant activators are rarely used. (Servant locators
are much more flexible.)

Cheers,

Michi.

--
Michi Henning                Ph: +61 4 1118-2700
ZeroC, Inc.                  http://www.zeroc.com

 
 
 

Q: adavantage of ServantActivator

Post by zhou » Sat, 12 Jul 2003 05:00:39


Quote:> > 2) It is said that the best way to clean up servants with a RETAIN POA is to use ServantActivator.

> Who says that? First thing I've heard of this.

It is from your book "Advanced CORBA with C++"  :-)
p. 501, last statement of the second paragraph

Quote:> > Assume servant dervies from RefCountServantBase,

> > Without ServantActivator, POA invokes _remove_ref() on the servant after ALL method calls on it complete. If the
ref.
> > count drops to 0, delete is called on the servant. This should guarantee that servant is cleaned up properly. I
donot
> > see the value added by ServantActivator? Did I miss anything?

> No, a servant activator adds no value to this scenario. In fact,
> servant activators in general add comparatively little value:
> they allow you to perform incremental initialization, which can be
> useful if servants are expensive to initialize. But servant activators
> to not improve scalability because, if the server runs for long enough,
> eventually, all objects will be touched by one client or another,
> meaning that you end up with servants for all objects in memory anyway.

If that is the case, Evictor can be used to ensure scalability, right?

Yan

 
 
 

Q: adavantage of ServantActivator

Post by Duncan Grisb » Sat, 12 Jul 2003 06:01:17




Quote:>No, a servant activator adds no value to this scenario. In fact,
>servant activators in general add comparatively little value:
>they allow you to perform incremental initialization, which can be
>useful if servants are expensive to initialize. But servant activators
>to not improve scalability because, if the server runs for long enough,
>eventually, all objects will be touched by one client or another,
>meaning that you end up with servants for all objects in memory anyway.

I disagree. I've often used servant activators for this kind of thing,
coupled with timeouts to deactivate idle objects. In a lot of
situations, that is much easier to manage than servant locators, and
more efficient too, since the POA doesn't have to call into servant
locator code on every incoming call to a regularly used object.

Cheers,

Duncan.

--
 -- Duncan Grisby         --

   -- http://www.grisby.org --

 
 
 

Q: adavantage of ServantActivator

Post by Michi Hennin » Sat, 12 Jul 2003 07:50:23



> > > 2) It is said that the best way to clean up servants with a RETAIN POA is to use ServantActivator.

> > Who says that? First thing I've heard of this.

> It is from your book "Advanced CORBA with C++"  :-)
> p. 501, last statement of the second paragraph

Gee, there are all sorts of things in this book I didn't know about :-)
Besides, Steve wrote that bit -- I don't know what he was smoking at the
time ;-)

But, seriously, this was written before RefCountServantBase was
finalized. (From memory, we had considered adding reference counting to
servants at that point, the proposal was in draft stage and all the
details hadn't been worked out yet.) Prior to RefcountServantBase, the
advice made sense because, otherwise, there was no way to reliably know
when a servant was no longer used by the server-side run time.

Quote:> > No, a servant activator adds no value to this scenario. In fact,
> > servant activators in general add comparatively little value:
> > they allow you to perform incremental initialization, which can be
> > useful if servants are expensive to initialize. But servant activators
> > to not improve scalability because, if the server runs for long enough,
> > eventually, all objects will be touched by one client or another,
> > meaning that you end up with servants for all objects in memory anyway.

> If that is the case, Evictor can be used to ensure scalability, right?

Yes, that's one of the main reasons to use an evictor (or, if you can
afford the extra initialization and finalization cost per request, a
default servant). Evictors are also useful to clean up objects that are
abandonded by clients and need to be reaped by the server.

Cheers,

Michi.

--
Michi Henning                Ph: +61 4 1118-2700
ZeroC, Inc.                  http://www.zeroc.com

 
 
 

Q: adavantage of ServantActivator

Post by Michi Hennin » Sat, 12 Jul 2003 07:55:01





> >No, a servant activator adds no value to this scenario. In fact,
> >servant activators in general add comparatively little value:
> >they allow you to perform incremental initialization, which can be
> >useful if servants are expensive to initialize. But servant activators
> >to not improve scalability because, if the server runs for long enough,
> >eventually, all objects will be touched by one client or another,
> >meaning that you end up with servants for all objects in memory anyway.

> I disagree. I've often used servant activators for this kind of thing,
> coupled with timeouts to deactivate idle objects. In a lot of
> situations, that is much easier to manage than servant locators,

Hmmm... If you compare the evictor implementation using a servant
locator with the evictor implementation using a servant activator in our
book, I think you'll agree that the servant locator version is much
cleaner. Yes, you can use timeouts for eviction but, as we point out in
the life cycle chapter, timeouts come with their own share of problems.
Personally, I prefer a servant locator to do this sort of thing.

Quote:> and
> more efficient too, since the POA doesn't have to call into servant
> locator code on every incoming call to a regularly used object.

I don't think that makes any difference at all. If the adapter
uses the ASM, it has to do a lookup in the ASM. In practice, the code
will most likely put that code into a function. If a servant locator is
used, the run time just calls a function that was written by the
developer instead of its own. There is no difference in performance here
because, either way, the functions have to perform a lookup into a map
of some kind.

Cheers,

Michi.

--
Michi Henning                Ph: +61 4 1118-2700
ZeroC, Inc.                  http://www.zeroc.com

 
 
 

Q: adavantage of ServantActivator

Post by Duncan Grisb » Sat, 12 Jul 2003 22:36:42




Quote:>Hmmm... If you compare the evictor implementation using a servant
>locator with the evictor implementation using a servant activator in our
>book, I think you'll agree that the servant locator version is much
>cleaner.

But that's because you are using the servant activator to implement
the evictor pattern. I agree that if you want the evictor pattern, you
should do it with a servant locator. What I was talking about is using
a different pattern, where you don't explicitly limit the number of
activated servants, so you don't need to maintain an evictor queue at
all.

Quote:>   Yes, you can use timeouts for eviction but, as we point out in
>the life cycle chapter, timeouts come with their own share of problems.

You seem to have two objections to timeouts. One, they are hard to do
without threads. I agree, but I'd also suggest that many many things
in distributed systems are hard to do without threads. All my CORBA
servers end up being multi-threaded anyway, so that problem does not
exist. Your second objection is that you have to use asynchronous
timers provided by the OS, which might go off at any time, and might
be limited in number. That problem also doesn't exist if you have
threads.

The easy way to do timeouts is to maintain a flag in each servant,
which is set true on each invocation. Then, a scavenger thread
periodically scans the list of activated servants. For each servant,
if the flag is true, it sets it false; if the flag is false, it
deactivates the servant. That's all there is to it. If different
servants need different timeouts, the flag becomes a count that is set
to an initial value, and decremented each time the scavenger runs.

Quote:>I don't think that makes any difference at all. If the adapter
>uses the ASM, it has to do a lookup in the ASM. In practice, the code
>will most likely put that code into a function. If a servant locator is
>used, the run time just calls a function that was written by the
>developer instead of its own. There is no difference in performance here
>because, either way, the functions have to perform a lookup into a map
>of some kind.

Well, there are several reasons a servant locator is likely to be less
efficient. In a multi-threaded application, the map has to be
protected by a mutex. The chances are that at dispatch time, the POA
already has to acquire a mutex to protect its own state, so it can
access its object map without any extra locking overhead. It's quite
likely that during the dispatch, the POA has already done some of the
work to decode the object id, and is therefore likely to be able to do
a faster look-up. Certainly in omniORB, a hash value for the object
key is required for other purposes, so a lookup in its object map is
almost free. A call to a servant locator is at least a virtual
function call, and at worst a call through a POA (since local
interfaces are a recent thing), whereas a lookup in the POA's map is
probably either a non-virtual function call, or just inline code.

Having said all that, it's probably not a big deal, and most
applications wouldn't notice the difference.

Cheers,

Duncan.

--
 -- Duncan Grisby         --

   -- http://www.grisby.org --

 
 
 

Q: adavantage of ServantActivator

Post by Michi Hennin » Tue, 15 Jul 2003 20:31:26




> >Hmmm... If you compare the evictor implementation using a servant
> >locator with the evictor implementation using a servant activator in our
> >book, I think you'll agree that the servant locator version is much
> >cleaner.

> But that's because you are using the servant activator to implement
> the evictor pattern. I agree that if you want the evictor pattern, you
> should do it with a servant locator. What I was talking about is using
> a different pattern, where you don't explicitly limit the number of
> activated servants, so you don't need to maintain an evictor queue at
> all.

Fair enough.

Quote:> >   Yes, you can use timeouts for eviction but, as we point out in
> >the life cycle chapter, timeouts come with their own share of problems.

> You seem to have two objections to timeouts. One, they are hard to do
> without threads. I agree, but I'd also suggest that many many things
> in distributed systems are hard to do without threads. All my CORBA
> servers end up being multi-threaded anyway, so that problem does not
> exist. Your second objection is that you have to use asynchronous
> timers provided by the OS, which might go off at any time, and might
> be limited in number. That problem also doesn't exist if you have
> threads.

> The easy way to do timeouts is to maintain a flag in each servant,
> which is set true on each invocation. Then, a scavenger thread
> periodically scans the list of activated servants. For each servant,
> if the flag is true, it sets it false; if the flag is false, it
> deactivates the servant. That's all there is to it. If different
> servants need different timeouts, the flag becomes a count that is set
> to an initial value, and decremented each time the scavenger runs.

Yes, this works. The only problem I can see with this is that it
requires examination of every servant when the timer goes off. That not
only takes O(n) time, it also means to acquire and release locks (either
a single global lock, or a lock per servant). Either way, this easily
becomes too expensive as the number of servants gets large. But, yes,
it's an approach that can work, depending on the requirements of the
application.

- Show quoted text -

Quote:> >I don't think that makes any difference at all. If the adapter
> >uses the ASM, it has to do a lookup in the ASM. In practice, the code
> >will most likely put that code into a function. If a servant locator is
> >used, the run time just calls a function that was written by the
> >developer instead of its own. There is no difference in performance here
> >because, either way, the functions have to perform a lookup into a map
> >of some kind.

> Well, there are several reasons a servant locator is likely to be less
> efficient. In a multi-threaded application, the map has to be
> protected by a mutex. The chances are that at dispatch time, the POA
> already has to acquire a mutex to protect its own state, so it can
> access its object map without any extra locking overhead. It's quite
> likely that during the dispatch, the POA has already done some of the
> work to decode the object id, and is therefore likely to be able to do
> a faster look-up. Certainly in omniORB, a hash value for the object
> key is required for other purposes, so a lookup in its object map is
> almost free. A call to a servant locator is at least a virtual
> function call, and at worst a call through a POA (since local
> interfaces are a recent thing), whereas a lookup in the POA's map is
> probably either a non-virtual function call, or just inline code.

> Having said all that, it's probably not a big deal, and most
> applications wouldn't notice the difference.

I agree. If the operation does any reasonable amount of work, the cost
of the extra function call and/or lock is insignificant.

Cheers,

Michi.

--
Michi Henning                Ph: +61 4 1118-2700
ZeroC, Inc.                  http://www.zeroc.com

 
 
 

Q: adavantage of ServantActivator

Post by zhou » Thu, 17 Jul 2003 03:06:48


I think that you meant for "if you can NOT affort the extra initialization ..., a default servant), right?

Yan

Quote:

> Yes, that's one of the main reasons to use an evictor (or, if you can
> afford the extra initialization and finalization cost per request, a
> default servant). Evictors are also useful to clean up objects that are
> abandonded by clients and need to be reaped by the server.

 
 
 

1. Strange problems with OmniORB (3.0.5/4.0.1) ServantActivator

I'm testing a new CORBA server (both on 3.0.5 and 4.0.1) on my Windows 2000
(IBM laptop), and I get some strange results:

The server is basically a factory for creating three CORBA objects. These
three objects in turn are activated and incarnated through three
ServantActivators.

My testprogram obtains the factory, and gets a _var to the servants, invoces
a test-method, and closes.

The strange thing is that as long as I activate one servant, and invoes some
test methods on the servant, I can repeat the the testprogram as long as I
like.

BUT, trying to obtain (and activate) all three at the same time, the
testprogram succeeds the first time, but then gets errors upon the next try
(different errors).

I have to shutdown and restart the CORBA server in order to run the test
sucessfully (the first time).

I then tried to obtain the servant _var three times in a row in the server,
and got the same errors after 7 or 8 invocations.

It seems there can be some synchronisity problems (threads, or what do I
know) trying to activate too many servants in too short a time?

Could it have something to do with the TCP/IP implementations on Windows
2000?

It is really a very uncomfortable problem, since now it works, now it
doesn't.

If it is of any interest, I could email the source code!

Any help greatly appreciated!

Ares

2. Generate ISDN PRI Trafffic.

3. ForwardRequest on ServantActivator

4. Installlling printer problems (continued)

5. Question regarding ServantActivator design approach

6. web service fails to run when using another DLL

7. Can a POA have more than one ServantActivator?

8. automaticly rename documents

9. Factories vs ServantActivators.

10. evictor, ServantActivator and ServantLocator

11. POA with ServantActivator/Locator or AdapterActivator?

12. ServantActivators & ties?

13. ServantLocator vs. ServantActivator