axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick van Beem" <>
Subject Multi-threading
Date Thu, 11 Dec 2008 10:46:05 GMT

I'm experiencing serious limitations while using axis in a multi-threading environment. I
know axis is not fully designed (yet?) for multi-threading, but I think some 'small' changes
might make it more usable. One can't deny multi-threading. Here my 2 cents:

* Callback and resources
In a multi-threading environment, an asynchronous job is often responsible for freeing it's
own resources (in this case, the environment, the stub and possible extra application dependent
data). In the axis framework, this can't be done in the callback, since the framework will
use the stub after the callback is finished. This makes it impossible for an application to
free resources after a call has finished (because you never know exactly when the call (including
the framework part of it) is finished. This makes the asynchronous implementation of axis
useless in a job-oriented multi-threading environment.
Improvements might include adding an extra callback to free resources, that is made when axis
has freed all its resources and does not need any resources the user might free.

* Environment vs stub
Since every thread needs it's own environment and stub in axis and (as stated above) in a
multi-threaded environment a job is often responsible of it's own resources, every job needs
to allocate and initialize it's environment and stub for each call (or keep one set initialized
for every thread, but that's not feasible when one thread can be used for multiple purposes
/ jobs and/or threads can be added dynamically). And free it after the job is finished.
Apart from the (slight) performance drawback, this poses another problem: Part of the stub
initialization includes reading the configuration file. When two threads try to do this simultaneously,
the last one who tries this, fails.
Solutions to this problem might include:
- Create a clone function for the stub, so all threads can clone from template stub, instead
of reading from disk.
- Separate the state information from the stub and put it in the environment, so the stub
can be used read-only and shared by threads.

* Async model
The asynchronous call implementation of axis is based on creating new threads that just wait
on a response. Threads are a rather expensive resource to use for just waiting on an IO completion
(and then performing some small task). It might be better that the waiting on all outstanding
IO is done by one single thread. The work after the IO completed can then be done by either
that thread, or a (small and static) thread pool. That way, no threads have to be created
/ deleted on the flow, not more than one thread is waiting on IO and no high amount of threads
will exist when a lot of asynchronous calls exist in parallel.
My axis knowledge is not enough to see solutions for this within axis right now.

What do you all think about these points?



Patrick van Beem
Sr. Software engineer
T +31 (0) 73 691 07 39
F +31 (0) 73 691 07 54
M +31 (0) 06 15 01 65 83

This message contains information that may be privileged or confidential and is the property
of Quintiq. It is only intended for the person to whom it is addressed. If you are not the
intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute
or use this message or any part thereof. If you have received this message in error, please
notify the sender immediately and delete all copies of this message. Please note that e-mails
are susceptible to change, therefore they are not binding.

View raw message