Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Received-SPF: neutral (nike.apache.org: 209.68.5.16 is neither permitted nor
 denied by domain of damitha23@gmail.com)
Message-ID: <495F1B25.3080507@gmail.com>
Date: Sat, 03 Jan 2009 13:30:37 +0530
From: Damitha Kumarage <damitha23@gmail.com>
User-Agent: Thunderbird 2.0.0.18 (X11/20081125)
MIME-Version: 1.0
To: Apache AXIS C Developers List <axis-c-dev@ws.apache.org>
Subject: Re: Multi-threading
References: <08CEB0908629C64AB48367CEF2DD012901B1E4D3@smmtl102.axa.ca>
 <007e01c95bb7$27944120$76bcc360$@rr.com> <4947ACA6.6E68.0040.0@quintiq.com>
In-Reply-To: <4947ACA6.6E68.0040.0@quintiq.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Patrick van Beem wrote:
> Hello Bill
>
>   
>> Patrick, when building a multi-threaded Axis2C client I too was 
>> concerned about the multiple environments.  Although your 
>> statement is correct in a sense that each thread needs its own 
>> environment/stub, these environments can in fact share much of 
>> the underlying structures.  In practice, each thread needs its 
>> own error stack, but it can certainly share the allocator and 
>> logger.  And the configuration information is associated with 
>> the allocator.  There is a primitive function 
>> axutil_env_create_with_error_log_thread_pool() that lets you 
>> share the substructures already created for the "global" environment 
>> created once for the application.  This way the configuration 
>> information is read only once.  Axutil_env_free_masked() lets 
>> each thread free just its error stack upon termination, leaving 
>> the allocator et.al. intact.  
>>     
>
> Correct. I already use these. But afaik the configuration file is read when creating the stub. And that should be done for each thread / call. So while many resources can indeed be shared, the one needing the most (time-consuming) initialization (I think), can't. I think this would be a great improvement for the future.
>   
I think adding this functionality to the stub creation is straight 
forward. Just add the stub creation function
axis2_stub_create_with_conf_ctx_and_endpoint_ref_and_client_home(const 
axutil_env_t * env, axis2_conf_ctx_t *con_ctx, axis2_endpoint_ref_t * 
endpoint_ref, const axis2_char_t * client_home));

which in turn call already available api function

axis2_svc_client_create_with_conf_ctx_and_svc(
        const axutil_env_t * env,
        const axis2_char_t * client_home,
        axis2_conf_ctx_t * conf_ctx,
        axis2_svc_t * svc);

>   
>> I was not dealing with asynchronous operation in my application, 
>> so I don't know if you might need a separate thread-pool for 
>> each created environment.  
>>     
>
> The current implementation of a thread pool in axis is no thread pool but a collection of thread creation and deletion methods... So no...
>   
But when creating environment you can pass your own thread pool. Would 
that not help?
thanks,

thanks,
Damitha
> Thank you for your input.
>
>   


-- 
__________________________________________________________________

Damitha Kumarage
http://people.apache.org/
__________________________________________________________________