Re: [axis2/c] When to free what resources in an async adb call?

[Patrick van Beem <pa...@quintiq.com>]

Hello,

> You can keep a global flag to set when the callback is finish calling. and
> may be in a while loop you can check that flag and free if it is set. I'm

No, I can't. Because the axis framework / generated code is using the stub data after the user-callback. So when signaling another thread to cleanup, you run the risk the other thread cleans up before the framework stops using the data -> crash.

> not sure whether this fit to your application. Another option is passing
> stub as the data in the callback and free it.

That's just what I tried, but that has the same result: The framwork is using the stub after the usser callback. So freeing the stub data in the user callback will result in a crash.
 
> But you can't free the env variable either way. That's should be created at
> the start of the app and free at the end of it. Anyway if you want to do

Our application highly relies on multi-threading. The environment can't be shared between threads (the error structure is in it). So each thread needs to allocate it's own environment. Since it can't be predicted which worker thread is going to call what and when, we create an environment for each call and free it after that call, using axutil_env_create_with_error_log_thread_pool() and axutil_env_free_masked() so we only allocate and free the error structure.
A strange thing I noticed is that the refcount for the environment is never 1 after a call...

> that you may have to edit the generated stub call.

I think the problem is not only the generated code (that uses only the allocator, and we can get around that by changing the code to free the call-back data prior to calling the callback). But the framwork is using that data too.
 
Regards,

-- 

 
Patrick van Beem
Sr. Software engineer
 
Quintiq
 
T +31 (0) 73 691 07 39
F +31 (0) 73 691 07 54
M +31 (0) 06 15 01 65 83
E patrick.van.beem@quintiq.com
I www.quintiq.com



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.

---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-user-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-user-help@ws.apache.org

Re: re[2]: Issues running service client on AIX 5L

[Uthaiyashankar <sh...@wso2.com>]

Thank you very much. I have applied your patch. Looking forward to get more
contribution :)

Regards,
Shankar

On Thu, Dec 11, 2008 at 10:43 PM, Dominic Smith <d....@querix.co.uk>wrote:

> > Hi,
>
> > Thank you very much for sharing this information. It was very useful. It
> > would be great help if you could provide a patch?
>
> Patch as follows (I notice in the current source the libaxis2_http_receiver
> module has already been addressed):
>
> Index: src/core/transport/http/sender/Makefile.am
> ===================================================================
> --- src/core/transport/http/sender/Makefile.am (revision 725683)
> +++ src/core/transport/http/sender/Makefile.am (working copy)
> @@ -32,6 +32,7 @@
> $(top_builddir)/src/core/transport/http/util/libaxis2_http_util.la\
> $(top_builddir)/axiom/src/om/libaxis2_axiom.la\
> $(top_builddir)/util/src/libaxutil.la\
> + $(top_builddir)/src/core/engine/libaxis2_engine.la\
> $(LIBCURL_LIBS)\
> $(SSL_LIBS)
> Index: axiom/src/parser/guththila/Makefile.am
> ===================================================================
> --- axiom/src/parser/guththila/Makefile.am (revision 725683)
> +++ axiom/src/parser/guththila/Makefile.am (working copy)
> @@ -1,6 +1,7 @@
> lib_LTLIBRARIES = libaxis2_parser.la
> -libaxis2_parser_la_LIBADD = ../../../../guththila/src/libguththila.la
> +libaxis2_parser_la_LIBADD = ../../../../guththila/src/libguththila.la \
> + ../../../../util/src/libaxutil.la
> libaxis2_parser_la_SOURCES = ../xml_reader.c ../xml_writer.c
> guththila_xml_writer_wrapper.c \
> guththila_xml_reader_wrapper.c
> Index: axiom/src/parser/libxml2/Makefile.am
> ===================================================================
> --- axiom/src/parser/libxml2/Makefile.am (revision 725683)
> +++ axiom/src/parser/libxml2/Makefile.am (working copy)
> @@ -4,7 +4,8 @@
> libaxis2_parser_la_SOURCES = ../xml_reader.c ../xml_writer.c \
> libxml2_reader_wrapper.c libxml2_writer_wrapper.c
> -libaxis2_parser_la_LIBADD = @LIBXML2_LIBS@
> +libaxis2_parser_la_LIBADD = @LIBXML2_LIBS@ \
> + ../../../../util/src/libaxutil.la
> libaxis2_parser_la_LDFLAGS = -version-info $(VERSION_NO)
> libaxis2_libxml2_la_LDFLAGS = -version-info $(VERSION_NO)
>
>


-- 
S.Uthaiyashankar
Software Architect
WSO2 Inc.
http://wso2.com/ - "The Open Source SOA Company"

re[2]: Issues running service client on AIX 5L

[Dominic Smith <d....@querix.co.uk>]

> Hi, 

> Thank you very much for sharing this information. It was very useful. It
> would be great help if you could provide a patch? 

Patch as follows (I notice in the current source the libaxis2_http_receiver 
module has already been addressed):

Index: src/core/transport/http/sender/Makefile.am
===================================================================
--- src/core/transport/http/sender/Makefile.am (revision 725683)
+++ src/core/transport/http/sender/Makefile.am (working copy)
@@ -32,6 +32,7 @@
$(top_builddir)/src/core/transport/http/util/libaxis2_http_util.la\
$(top_builddir)/axiom/src/om/libaxis2_axiom.la\
$(top_builddir)/util/src/libaxutil.la\
+ $(top_builddir)/src/core/engine/libaxis2_engine.la\
$(LIBCURL_LIBS)\
$(SSL_LIBS)
Index: axiom/src/parser/guththila/Makefile.am
===================================================================
--- axiom/src/parser/guththila/Makefile.am (revision 725683)
+++ axiom/src/parser/guththila/Makefile.am (working copy)
@@ -1,6 +1,7 @@
lib_LTLIBRARIES = libaxis2_parser.la
-libaxis2_parser_la_LIBADD = ../../../../guththila/src/libguththila.la
+libaxis2_parser_la_LIBADD = ../../../../guththila/src/libguththila.la \
+ ../../../../util/src/libaxutil.la
libaxis2_parser_la_SOURCES = ../xml_reader.c ../xml_writer.c 
guththila_xml_writer_wrapper.c \
guththila_xml_reader_wrapper.c 
Index: axiom/src/parser/libxml2/Makefile.am
===================================================================
--- axiom/src/parser/libxml2/Makefile.am (revision 725683)
+++ axiom/src/parser/libxml2/Makefile.am (working copy)
@@ -4,7 +4,8 @@
libaxis2_parser_la_SOURCES = ../xml_reader.c ../xml_writer.c \
libxml2_reader_wrapper.c libxml2_writer_wrapper.c
-libaxis2_parser_la_LIBADD = @LIBXML2_LIBS@
+libaxis2_parser_la_LIBADD = @LIBXML2_LIBS@ \
+ ../../../../util/src/libaxutil.la
libaxis2_parser_la_LDFLAGS = -version-info $(VERSION_NO)
libaxis2_libxml2_la_LDFLAGS = -version-info $(VERSION_NO)

Re: Issues running service client on AIX 5L

[Uthaiyashankar <sh...@wso2.com>]

Hi,

Thank you very much for sharing this information. It was very useful. It
would be great help if you could provide a patch?

Regards,
Shankar.

On Tue, Dec 9, 2008 at 10:36 PM, Dominic Smith <d....@querix.co.uk> wrote:

> Hello,
>
> We've just about got the Axis2/C service client running on AIX 5L (using
> Axis2/C 1.4.0), however there were a number of issues in getting this
> platform
> working. I notice there have been previous posts concerning AIX 5L, however
> I
> didn't see anything addressing this particular issue, so I figure it's best
> I
> bring this up.
>
> The crux of the problem is that when running the service client, the
> modules
> libaxis_http_receiver.a and libaxis2_http_sender.a will crash when trying
> to
> access methods within libaxis2_engine.a (e.g. the call to
> axis2_transport_in_desc_param_container() called from
> axis2_http_server_init()
> in http_receiver.c).
>
> The main reason for this is that the modules libaxis2_http_sender.a and
> libaxis2_http_receiver.a are not explicitly linked against
> libaxis2_engine.a,
> so if you look at the imports list for these modules, you'll see the
> dynamic
> linker is expecting to perform dynamic binding (but is failing to do so).
> Similarly, a problem exists in libaxis2_parser.a, as it is not explicitly
> linked against libaxutil.a.
>
> For example, take a look at the output of dump -HTv on libaxis2_parser -
> notice
> the '..' marking the symbol as being undefined.
>
> [155] 0x20001228 .data EXP DS SECdef [noIMid] axiom_xml_reader_init
> [156] 0x20001240 .data EXP DS SECdef [noIMid]
> axiom_xml_reader_create_for_memory
> [157] 0x20001258 .data EXP DS SECdef [noIMid]
> axiom_xml_reader_create_for_io
> [158] 0x20001270 .data EXP DS SECdef [noIMid]
> axiom_xml_reader_create_for_file
> [159] 0x00000000 undef IMP DS EXTref .. axutil_error_set_error_number
> [160] 0x00000000 undef IMP DS EXTref .. axutil_error_set_status_code
>
> By explicitly linking libaxutil into libaxis2_parser, we see this becomes
> more
> like one would expect:
>
> [44] 0x00000000 undef IMP DS EXTref
> /builddeps/64/axis2/lib/libaxutil.a(libaxutil.so.0)
> axutil_error_set_error_number
>
> In addition to the problems noted on AIX, we ran into a number of minor
> issues
> porting to HP-UX (PA-RISC in 64-bit mode). The main being in the header
> axutil_unix.h, we define:
>
> #define AXIS2_LIB_SUFFIX ".so"
>
> unfortunately, under HP-UX (for PA-RISC) the shared library extension is
> ".sl"
> (HP-UX on Itanium uses .so for libraries built for the IA64 architecture,
> and
> ..sl for libraries built for the PA-RISC architecture).
>
> We have noted a number of memory leaks in the 1.5.0 branch, however due to
> time
> constraints we haven't had a real chance to pinpoint these. Hopefully we'll
> be
> able to bring some information on this at a later point.
>
>


-- 
S.Uthaiyashankar
Software Architect
WSO2 Inc.
http://wso2.com/ - "The Open Source SOA Company"

Issues running service client on AIX 5L

[Dominic Smith <d....@querix.co.uk>]

Hello, 

We've just about got the Axis2/C service client running on AIX 5L (using 
Axis2/C 1.4.0), however there were a number of issues in getting this platform 
working. I notice there have been previous posts concerning AIX 5L, however I 
didn't see anything addressing this particular issue, so I figure it's best I 
bring this up. 

The crux of the problem is that when running the service client, the modules 
libaxis_http_receiver.a and libaxis2_http_sender.a will crash when trying to 
access methods within libaxis2_engine.a (e.g. the call to 
axis2_transport_in_desc_param_container() called from axis2_http_server_init() 
in http_receiver.c). 

The main reason for this is that the modules libaxis2_http_sender.a and 
libaxis2_http_receiver.a are not explicitly linked against libaxis2_engine.a, 
so if you look at the imports list for these modules, you'll see the dynamic 
linker is expecting to perform dynamic binding (but is failing to do so). 
Similarly, a problem exists in libaxis2_parser.a, as it is not explicitly 
linked against libaxutil.a. 

For example, take a look at the output of dump -HTv on libaxis2_parser - notice 
the '..' marking the symbol as being undefined. 

[155] 0x20001228 .data EXP DS SECdef [noIMid] axiom_xml_reader_init
[156] 0x20001240 .data EXP DS SECdef [noIMid] 
axiom_xml_reader_create_for_memory
[157] 0x20001258 .data EXP DS SECdef [noIMid] axiom_xml_reader_create_for_io
[158] 0x20001270 .data EXP DS SECdef [noIMid] axiom_xml_reader_create_for_file
[159] 0x00000000 undef IMP DS EXTref .. axutil_error_set_error_number
[160] 0x00000000 undef IMP DS EXTref .. axutil_error_set_status_code

By explicitly linking libaxutil into libaxis2_parser, we see this becomes more 
like one would expect: 

[44] 0x00000000 undef IMP DS EXTref 
/builddeps/64/axis2/lib/libaxutil.a(libaxutil.so.0) 
axutil_error_set_error_number

In addition to the problems noted on AIX, we ran into a number of minor issues 
porting to HP-UX (PA-RISC in 64-bit mode). The main being in the header 
axutil_unix.h, we define:

#define AXIS2_LIB_SUFFIX ".so"

unfortunately, under HP-UX (for PA-RISC) the shared library extension is ".sl" 
(HP-UX on Itanium uses .so for libraries built for the IA64 architecture, and 
..sl for libraries built for the PA-RISC architecture). 

We have noted a number of memory leaks in the 1.5.0 branch, however due to time 
constraints we haven't had a real chance to pinpoint these. Hopefully we'll be 
able to bring some information on this at a later point.