[omniORB] How to guard against endless loops in the server?

[Duncan Grisby]

On Wednesday 26 November, "Bhatia, Neeraj" wrote:

> I've a related question. To my understanding, omniORB scavenger
> thread checks for running server threads and kill them at
> serverCallTimeOutPeriod.

No, it doesn't. Read the message you quoted.

> Is there anyway to get a notification that a thread has been killed?

Threads are never killed. You can hook thread creation and destruction
using the interceptors documented in the omniORB manual, but threads
only exit when they choose to.

Cheers,

Duncan.

> -----Original Message-----
> From: Duncan Grisby [mailto:duncan at grisby.org] 
> Sent: Tuesday, February 25, 2003 7:21 AM
> To: Daniel Pfeiffer
> Cc: omniorb-list at omniorb-support.com
> Subject: Re: [omniORB] How to guard against endless loops in the server? 
> 
> On Wednesday 19 February, Daniel Pfeiffer wrote:
> 
> > We want to guard against endless loops in the server with a server
> > side timeout.  I would expect this to work by interrupting the
> > server method and sending an exception to the client (which is
> > operating with a longer timeout).
> 
> There is no safe way to interrupt a running thread, so there is no way
> for the ORB to do this.
> 
> The serverCallTimeOutPeriod is used to cope with the situation that a
> client starts sending a request, but never finishes. In that case,
> without the timeout, a server thread would sit for ever waiting for
> the end of the request to arrive. The timeout has no effect once the
> request has been received.
> 
> > The documentation of serverCallTimeOutPeriod in version 4, sounds like the
> > semantics have completely changed since version 3.0.5.  Anyway: What is the
> > correct way to guard against runaway server methods in both 3.0.5 and 4.0?
> 
> The behaviour has not changed between 3.0.x and 4.0.x. The
> documentation has been clarified.
> 
> To do what you want, you should make sure your operation
> implementations check how long they have been running for every so
> often, and explicitly give up if they take too long.
> 
> Cheers,
> 
> Duncan.
> 
> -- 
>  -- Duncan Grisby         --
>   -- duncan at grisby.org     --
>    -- http://www.grisby.org --
> _______________________________________________
> omniORB-list mailing list
> omniORB-list at omniorb-support.com
> http://www.omniorb-support.com/mailman/listinfo/omniorb-list



-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --