Can you get a single thread working? Just start one thread with one
service client instance and see if that works.
Also, did you set axis2_options_set_xml_parser_reset option setting to
AXIS2_FALSE?
Can you post the code in a Jira issue so that I can have a look into the
code?
Thanks,
Samisa...
Stefano Pettini wrote:
Thanks again Samisa for your answer.
I'm still tracking the countinous problems and crashes with absolutely
no progress. I don't know what to think or do :-(
Has anybody even tried to run multiple svc_clients in parallel?
Is axis2_svc_client_create thread safe?
Is the one-environment-per-thread solution thread safe? Not sure about
shared error_t structures...
This is a typical result of my test, just to prove you I'm not dreaming.
Heap corruption detected at 00EA42E0
First-chance exception in Manager.exe (NTDLL.DLL): 0xC0000005: Access
Violation.
Heap corruption detected at 00EA7210
HEAP[Manager.exe]: HEAP: Free Heap block ea7208 modified at ea721c
after it was freed
got randomly during parallel calls to axis2_svc_client_create, that
fail with AXIS2_ERROR_CREATING_XML_STREAM_READER :-(
If I don't solve this problem, I'll have to abandon Axis2 and look for
something else able to send an XML string to a SOAP endpoint and to
give back the response as XML string.
Any suggestion?
Thanks!
Stefano
Samisa Abeysinghe wrote:
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...
---------------------------------------------------------------------
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]