[omniORB] The thread-specific data destroyed in tread-pool policy thread model.

[Michal Misiaszek]

Thank you for answer. We have developed a patch for 4.0.6 which allows to
configure that idle timeout. I think it should be included in 4.1.0 version.
The patch is attached and description below:

Put attached patch to directory 'patches' which exists in home directory for
OmniORB 
Start command 'patch -c -p0 < patches/fix_for_omniORB-4.0.6.patch' from home
OmniORB directory 
Rebuild all binaries 
 
I added new global parameter 'idleAsyncInvokerTimeout' which can have valid
values = (n >= 0 in seconds).
Short description for this parameter:
No of seconds before an idle thread has to wait before it exits.
Default is 10 seconds.
But my proposal is to set this value to 600 seconds.

Regards
Michal


-----Original Message-----
From: Duncan Grisby [mailto:duncan at grisby.org] 
Sent: Wednesday, March 29, 2006 7:30 PM
To: misiaszek at computaris.com
Cc: omniorb-list at omniorb-support.com
Subject: Re: [omniORB] The thread-specific data destroyed in tread-pool
policy thread model. 

On Monday 27 March, "Michal Misiaszek" wrote:

> I have following problem. In our server we are using thread specific 
> data structure to keep some information.
> We are using thread-pool policy model in server and we are having many 
> clients connected to it. Recently we have strange problem with 
> application which was identified as destruction of thread specific 
> data between client calls. I beloved that in case of thread-pool 
> threads are not destroyed but only created when necessary (as pool is 
> not initialized). Did I get something wrong ?

Yes, you misunderstood. See section 8.4.2 of the omniORB manual:

  "The thread pool is not pre-initialised. Instead, threads are started
   on demand, and idle threads are stopped after a period of inactivity"

The default timeout for idle threads is 10 seconds. If you really need to
prevent threads being stopped, you can set omniAsyncInvoker::idle_timeout to
a much larger number of seconds.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix_for_omniORB-4.0.6.patch
Type: application/octet-stream
Size: 4222 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20060330/8dddd5e2/fix_for_omniORB-4.0.6.obj