Stefano Pettini wrote:
Hi Samisa,
thank you for your reply.
May you tell me if these pseudo-code fragments are conceptually right?
When you are using threads, each thread should have its own env. Hence
Fragment 1 looks the more correct one.
Fragment 2 and 3 are likely yo fail, because they use the same env
across threads.
Fragment 1)
Main thread:
start threads 1...N
Thread n:
create environment env[n]
create service client client_a[n] from env[n]
create service client client_b[n] from env[n]
create service client client_c[n] from env[n]
use service client client_a[n]
use service client client_b[n]
use service client client_c[n]
Fragment 2)
Main thread:
create environment env
start threads 1...N
Thread n:
create service client client_a[n] from env
create service client client_b[n] from env
create service client client_c[n] from env
use service client client_a[n]
use service client client_b[n]
use service client client_c[n]
Fragment 3)
Main thread:
create environment env
create service client client_a from env
create service client client_b from env
create service client client_c from env
start threads 1...N
Thread n:
use service client client_a
use service client client_b
use service client client_c
Whatever option I try, I still have A LOT of errors during C-Runtime
library function invocations. malloc returning null, user exceptions,
null pointers, heap corruption messages, ...
I still think there's something I'm missing, like calling an
initialization function at the beginning of a thread.
I develop on MFC framework, so I use CWinThread and AfxBeginThreads
(that encapsulate native Win32's CreateThread) to spawn new threads.
Another question, probably linked with heap corruption: strings! I use
axutil_string_create whenever I have to pass an axis's string, and I
pass string literal constants ("hello") or const char* whenever a
function needs an axis'2 char_t. I saw a similar usage in examples,
but these days, reading the mailing list, I saw you instead suggest
strdup and similar... What's the official "correct" way of handling
string (and in general, memory management)? I can't find it explained
anywhere, and I think it's a key point for every user/developer to
avoid memory leaks.
axutil_string_t wraps axis2_char_t. You can choose to use whatever you
like.
Handling axis2_char_t pointers is similar to handling char* in C, if you
choose to use axis2_char_t.
When you are using axutil_string_t, you have to use the correct create
method, depending on the way you want to handle the buffer you pass to
the create method. axutil_string_create creates a deep copy, so the
buffer you pass to the create method is your responsibility, meaning you
have to free it. axutil_string_create_assume_ownership assumes the
ownership of the buffer, meaning when the string is freed, it will free
the buffer you pass and you do not have to free it.
axutil_string_create_const makes a shallow copy and also do not assume
the ownership of the buffer, you have to be responsible to manage the
buffer and have to ensure the buffer you pass goes out of scope after
the string is freed. Please have a look into the implementation for
further details.
Thanks,
Samisa...
Thanks!
Stefano
Samisa Abeysinghe wrote:
If you are using multiple service clients in the same program in
threads, you may have to disable the resetting on the libxml2 parser,
whenever you free the service client.
You can do this by using the method
axis2_options_set_xml_parser_reset and set that to AXIS2_FALSE.
HTH
Thanks,
Samisa...
Stefano Pettini wrote:
Hi,
I've just subscribed this mailing list since I really need your help
to better understand how to use Axis2/C in a multi-thread environment.
I only use the client side, and server side services are disabled in
axis2.xml.
I think there must be something I ignore about memory management and
threading support.
My web service client runs fine in a single-thread helloworld, but
crashes ALL THE TIME if I run a multi-thread software. In
particular, I believe I'm using Axis2's environments, allocator, and
error structures in an incorrect way, that's why I'm asking for more
info. Just to know the correct way of using _create, _free,
AXIS2_FREE an so on, if solves my problem.
Is it right to create an environment in each thread? Or should I
create a single environment and then create svc_clients in each
thread? Or create everything in the root thread and then invoke the
svc_clients from different threads?
I really did a lot of test: shared / not shared error_t structures,
a custom allocator with functions protected by a shared mutex,
single environment, many environments, but the results are always
the same: continuous random crashes in different points. After
studying the problem for 2 days, I've discovered malloc, realloc and
free, of both the custom and default allocator, sometimes fail
returning null. So I have null pointer exceptions everywhere randomly!
And I'm not doing anything special! I've setup 3 svc_clients in each
thread, 10 threads, without executing anything else, without even
calling the services! I can't imagine what happens if I execute the
send_receive!
I really don't know what to think. I defined a custom allocator,
shared among all the environments, with functions protected by a
mutex. malloc/free crashes were solved, but now I have readdir and
other function crashing all the time (crashing means int 3, user
exception and heap corruption), continuously and randomly.
Libxml2 is initialized by the main thread, as specified in libxml2's
documentation about multi-threading support.
I'm working with Win2003 x86, VC6 and the multi-thread debug dll C
runtime MSVCRTD.dll.
I run on a Core2 Duo, maybe it's too much multi-threading :-)
Thanks a lot if you can help me or suggest what to do next.
I have tons of info since I've studied Axis2 source very deeply.
If you want to know something more, just ask.
Cheers,
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Samisa Abeysinghe : http://www.wso2.org/ (WSO2 Oxygen Tank - Web Services
Developers' Portal)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
