[jira] Created: (AXIS2C-1420) Support to talk to a TLS1 only server

[Damitha Kumarage (JIRA)]

Support to talk to a TLS1 only server
-

 Key: AXIS2C-1420
 URL: https://issues.apache.org/jira/browse/AXIS2C-1420
 Project: Axis2-C
  Issue Type: Improvement
Reporter: Damitha Kumarage


Axis2/C transport security implementation use the SSLv23_method() which cannot 
communicate with a TLS1 only server. It is desirable to add the support to talk 
to  TLS1 only server as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Implementing Http Keep Alive and Transport level session support for Axis2/C

[Damitha Kumarage]

Danushka Menikkumbura wrote:

Hi Damitha,

A couple of questions ...
 


A service could support session by creating a hash table filling
it with key value pairs and setting it to the message context.


Since this is done at the service level - a higher level - I thinks 
its nicer to have a simple API call to set session data rather than 
having to create a new hash table and set that in the message context. 
(e.g. msg_ctx_set_session_data(key, value) or something like that)
This is good improvement. However my initial thought was to avoid api 
changes as much as possible.
 


Then it add the Set-Cookie header into the response message which
has the cookie header value of session id and expiration time.


Is the expiration time configurable?
You can change AXIS2_TRANSPORT_SESSION_EXPIRE_DURATION in header file 
which is defaulted to 60 seconds. However deployment time configuration 
is not possible yet.
 


In the client side the sessions are stored in a session map
against the server.


What do you mean by storing sessions against the server?
cookies are stored in a hash table with key as server:port and value as 
the cookie value.


Are there any plans to make the session data persistent so that we can 
have persistent sessions?.
Sessions are made persistent at server side by storing them using dbd 
apache module. No plan yet to make them persistent at client side.
 


Http Keep Alive support for Axis2/C client side.


 Do we support Keep Alive on the server side?.
This support is provided by Apache. However it is not yet implementd for 
stand alone Axis2/C server. It just send back connection close header in 
HTTP1.1 case and no connection headre in HTTP1.0 case.
IIRC the HTTP transport receiver closes the connection on the server 
side?.


From there onwards it will reuse this http client for sending the
messages.


The main issue in reusing an HTTP client and hence the persisted 
connection is that in case the server goes down and maybe comes up 
again, the persisted connections that we have are no longer valid. If 
you now try to reuse these connections, the behavior is undefined. 
Therefore you have to do a socket select to check the validity of a 
persisted connection prior to reusing it. How do you handle this 
situation in your implementation?.
Are you talking about tcp keep alive support?. Adding that to Axis2/C is 
a good option.


Thanks,
Damitha


Danushka

--
Danushka Menikkumbura
Technical Lead, WSO2 Inc.

blog : http://danushka-menikkumbura.blogspot.com/

http://wso2.com/ - "The Open Source SOA Company"





--
______

Damitha Kumarage
Technical Lead; WSO2 Inc.
"Oxygenating the Web Service Platform; " http://www.wso2.com/

blog: " http://damithakumarage.wordpress.com/
__

Re: Implementing Http Keep Alive and Transport level session support for Axis2/C

[Damitha Kumarage]

Deepal jayasinghe wrote:

Damitha,

Did you get a chance to check with Axis2/Java?  it would be a good
interoperability testing.
  

Will do Deepal,
Thanks,
Damitha

Thanks,
Deepal
  

Samisa Abeysinghe wrote:


Looks good.
Have you committed?
  

Yes it is in svn

Thanks,
Damitha


Samisa...


On Tue, Dec 15, 2009 at 11:58 AM, Damitha Kumarage mailto:dami...@wso2.com>> wrote:

Hi,
I have implemented Http keep alive support and Cookie session
support for Axis2/C and commited to svn.
Following is a brief introduction into how I implemented it.

Cookie session support.

I use Apache mod_dbd module to store sessions at server side. The
functions for storing and retrieving session can be accessed
through Axis2/C environment. I have
implemented this for Apache module. Plan to implement this for
Axis2/C standalone server soon(which is trivial)
A service could support session by creating a hash table filling
it with key value pairs and setting it to the message context.
Then when this message context reach the server side sender it
extract the values from the hash table and make a session string
from that. It then generate a session id and
store the session string against the id generated(using the above
mentioned function in environment).
Then it add the Set-Cookie header into the response message which
has the cookie header value of session id and expiration time.

In the client side the sessions are stored in a session map
against the server.

When the server get the Cookie header it will retrieve the session
value by calling the environment function mentioned above and
create a hash table and set it to the message context.

Http Keep Alive support for Axis2/C client side.

Here implementation is as following.
When http transport sender is initialized it will mark whether
keep alive is supported when sending messages. This is the default
behaviour. However user can change this(in HTTP1.0) by
keep alive transport sender parameter in axis2.xml.
Now when http sender send the message for the first time it will
store the http_client in the keep alive map in the configuration
context, against the server.  From there
onwards it will reuse this http client for sending the messages.
In http 1.0 case it will set the http keep alive header when
sending the messages.
The implementation handle session close messages from the server
in http 1.1 case and keep alive header from server side in http
1.0 case.

Attached is the patch for the changes to implement above.

Thanks,
Damitha
--
__


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




--
Samisa Abeysinghe
Director, Engineering - WSO2 Inc.

http://www.wso2.com/ - "The Open Source SOA Company"
  




  



--
______

Damitha Kumarage
Technical Lead; WSO2 Inc.
"Oxygenating the Web Service Platform; " http://www.wso2.com/

blog: " http://damithakumarage.wordpress.com/
__

Re: Implementing Http Keep Alive and Transport level session support for Axis2/C

[Damitha Kumarage]

Samisa Abeysinghe wrote:
Looks good. 


Have you committed?

Yes it is in svn

Thanks,
Damitha


Samisa...


On Tue, Dec 15, 2009 at 11:58 AM, Damitha Kumarage <mailto:dami...@wso2.com>> wrote:


Hi,
I have implemented Http keep alive support and Cookie session
support for Axis2/C and commited to svn.
Following is a brief introduction into how I implemented it.

Cookie session support.

I use Apache mod_dbd module to store sessions at server side. The
functions for storing and retrieving session can be accessed
through Axis2/C environment. I have
implemented this for Apache module. Plan to implement this for
Axis2/C standalone server soon(which is trivial)
A service could support session by creating a hash table filling
it with key value pairs and setting it to the message context.
Then when this message context reach the server side sender it
extract the values from the hash table and make a session string
from that. It then generate a session id and
store the session string against the id generated(using the above
mentioned function in environment).
Then it add the Set-Cookie header into the response message which
has the cookie header value of session id and expiration time.

In the client side the sessions are stored in a session map
against the server.

When the server get the Cookie header it will retrieve the session
value by calling the environment function mentioned above and
create a hash table and set it to the message context.

Http Keep Alive support for Axis2/C client side.

Here implementation is as following.
When http transport sender is initialized it will mark whether
keep alive is supported when sending messages. This is the default
behaviour. However user can change this(in HTTP1.0) by
keep alive transport sender parameter in axis2.xml.
Now when http sender send the message for the first time it will
store the http_client in the keep alive map in the configuration
context, against the server.  From there
onwards it will reuse this http client for sending the messages.
In http 1.0 case it will set the http keep alive header when
sending the messages.
The implementation handle session close messages from the server
in http 1.1 case and keep alive header from server side in http
1.0 case.

Attached is the patch for the changes to implement above.

Thanks,
Damitha
-- 
__


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




--
Samisa Abeysinghe
Director, Engineering - WSO2 Inc.

http://www.wso2.com/ - "The Open Source SOA Company"



--
______

Damitha Kumarage
Technical Lead; WSO2 Inc.
"Oxygenating the Web Service Platform; " http://www.wso2.com/

blog: " http://damithakumarage.wordpress.com/
__

[jira] Commented: (AXIS2C-1279) A soap fault of "No Error" return

[Damitha Kumarage (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761210#action_12761210
 ] 

Damitha Kumarage commented on AXIS2C-1279:
--

When a service return NULL without setting error code(a common mistake that 
could happen by service writer) then this fault occur. I have fixed this 
perticuler problem by checking for "No Error" in the message receiver. This 
could be considered as the 3rd solution to the above problem

> A soap fault of "No Error" return
> -
>
> Key: AXIS2C-1279
> URL: https://issues.apache.org/jira/browse/AXIS2C-1279
> Project: Axis2-C
>  Issue Type: Bug
>  Components: core/engine
>Reporter: Damitha Kumarage
> Fix For: Next Version
>
>
> A soap fault with reason "No Error" return for certain errors at server side. 
> The reason is that some times failures happen at server side but error code 
> is not set for these. When at later times code see the status failure and 
> call axutil_error_get_message() then it give the wrong message "No Error".
> To avoid this there are two solutions
> 1. Whenever there is an error make sure to call set_error_code(). Fix this in 
> the current code.
> 2. Avoid using axutil_eror_get_message() function. 
> Ideally the solution should be the first one. Two is only a temporary hack.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: axis2C vs axis2C++

[Damitha Kumarage]

It is actually Axis/C++ not Axis2/C++. Some of the reason could be 
pointed as below
- QOS support. It is difficult to extend the Axis2 architecture to 
support QOS like RM, Security, Eventing etc. Axis2 architecture is 
designed with this in mind.

- Supporting WS on scripting languages, browsers
- Performance
- Infact there is WSF/C++ that wraps over Axis2/C which provides C++ 
support for WS. There is also WSF/PHP, WSF/Ruby etc which provides WS 
for PHP, Ruby respectively. All these scripting language stacks are 
based on Axis2/C


thanks,
Damitha

pankaj singh wrote:

Dear,
 
Could you please tell me the reasone why did we make Axis2/C in C as 
we had already Axis2/C++.
 
if you have any help regarding why and when we use C over C++.

Any help will be gr8 help to me.
 
Thanks

Pankaj Singh



--
__

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

Re: get IP from client

[Damitha Kumarage]

Hi,
From the message context get the property AXIS2_SVR_PEER_IP_ADDR

thanks,
Damitha
Maria de los Angeles Cifuentes wrote:

Hi:
I need to know the IP address from the client in a web service, how 
can I know it?


Thanks
Maria de los Angeles Cifuentes




--
__

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

Re: Axis2/C and lighttpd

[Damitha Kumarage]

Hi,
See whether this [1] help. AFAIK someone started developing a lighttpd 
module for Axis2/C few months back. Don't know how far it went.


thanks,
Damitha

[1] http://mohanjith.net/blog/2008/01/wso2-wsfphp-with-lighttpd.html

Feltraco, Fabio (R&D Brazil) wrote:

Hi,

 Looking at the axis/src/core/transport/http/server/ (for Axis2/C) we have:
   IIS/ (Microsoft IIS Server)
   apache2/ (Apache HTTP Server)
   simple_axis2_server/

 I would like to know if someone have already developed a Lighttpd module f=
or server side (or for any other light weight http server).

 As I have just started working with Axis2/C I also would like to know if t=
here is a cookbook explaining how to use Axis2/C with different http server=
s.

 In our case we intend to use Axis2/C in an embedded system (limited memory=
, rom, etc) and we cannot use Apache or IIS servers. And Simple Axis2 Serve=
r is not intended for production.

 Regards.

Fabio

  



--
______

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

Re: Implementing Keep-alive/ Persistent Connection support in Axis2/C

[Damitha Kumarage]

Hi Manjula,
It is used in WSF/C wsclient to retrieve response.

thanks,
Damitha

thanks,
Damitha
Manjula Peiris wrote:

Hi,

The HTTP 1.1 by defaults specifies using persistent connections. But
Axis2/C HTTP transport does not have this support. 
In the current implementation in the client side for each

axis2_svc_client_send_receive we are creating a TCP connection. This is
an overhead and we can achieve a huge performance gain by keeping a
connection pool.
I am proposing to keep a map which keeps an arraylist of connection for
a particular url.
Before implementing this stuff I have some concerns. 
In the current code we are storing the http_client instance in the

msg_ctx. Is there any reason for this ?

please send your thoughts on this.

Thanks,
-Manjula



  



--
__

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

[jira] Created: (AXIS2C-1378) operation name is corruputed by the time it reaches dispatcher

[Damitha Kumarage (JIRA)]

operation name is corruputed by the time it reaches dispatcher
--

 Key: AXIS2C-1378
 URL: https://issues.apache.org/jira/browse/AXIS2C-1378
 Project: Axis2-C
  Issue Type: Bug
  Components: core/engine
Reporter: Damitha Kumarage


I have following valgrind info when running Axis2/C with Apache  module. 

==8599== Invalid read of size 1
==8599==at 0x40276E8: strlen (mc_replace_strmem.c:242)
==8599==by 0x41866D7: vfprintf (in /lib/tls/i686/cmov/libc-2.9.so)
==8599==by 0x423E771: __vsnprintf_chk (in /lib/tls/i686/cmov/libc-2.9.so)
==8599==by 0x47A824E: axutil_log_impl_log_debug (stdio2.h:78)
==8599==by 0x46DE5DA: axis2_addr_disp_find_op (addr_disp.c:192)
==8599==by 0x46FFD6A: axis2_msg_ctx_find_op (msg_ctx.c:2094)
==8599==by 0x46DF6BA: axis2_disp_find_svc_and_op (disp.c:165)
==8599==by 0x46DE330: axis2_addr_disp_invoke (addr_disp.c:269)
==8599==by 0x46D784C: axis2_handler_invoke (handler.c:91)
==8599==by 0x46DD783: axis2_phase_invoke (phase.c:230)
==8599==by 0x46E0FFD: axis2_engine_invoke_phases (engine.c:691)
==8599==by 0x46E1A98: axis2_engine_receive (engine.c:249)
==8599==  Address 0x4412ae0 is 6,800 bytes inside a block of size 8,192 free'd
==8599==at 0x4025DFA: free (vg_replace_malloc.c:323)
==8599==by 0x40D7289: apr_allocator_destroy (apr_pools.c:134)
==8599==by 0x46AEB35: axis2_handler (mod_axis2.c:381)
==8599==by 0x8081520: ap_run_handler (config.c:157)
==8599==by 0x8081C70: ap_invoke_handler (config.c:372)
==8599==by 0x80B78D3: ap_process_request (http_request.c:258)
==8599==by 0x80B46EC: ap_process_http_connection (http_core.c:190)
==8599==by 0x808A192: ap_run_process_connection (connection.c:43)
==8599==by 0x808A612: ap_process_connection (connection.c:178)
==8599==by 0x80F4C36: child_main (prefork.c:650)
==8599==by 0x80F4D29: make_child (prefork.c:690)
==8599==by 0x80F52CD: ap_mpm_run (prefork.c:966)

You can reproduce this by running echo sample with the following code added to 
addr_disp.c

if(op)
{
axutil_qname_t *qname = (axutil_qname_t *) axis2_op_get_qname(op, env);
AXIS2_LOG_DEBUG(env->log, AXIS2_LOG_SI, "opname:%s", 
axutil_qname_to_string(qname, env));
}



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (AXIS2C-1377) switching to global/local pools when used with apache module

[Damitha Kumarage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damitha Kumarage resolved AXIS2C-1377.
--

Resolution: Fixed

Attached patch solve the issue

> switching to global/local pools when used with apache module
> 
>
> Key: AXIS2C-1377
> URL: https://issues.apache.org/jira/browse/AXIS2C-1377
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: util
> Environment: all
>Reporter: Damitha Kumarage
>    Assignee: Damitha Kumarage
> Attachments: allocator_switching.diff
>
>
> When Axis2/C is used with the httpd module to allocate memory in apache 
> global pools one need to call the axutil function 
> axutil_allocator_switch_to_global_pool. To switch back again to use apache 
> local pool(request level allocation) one need to call the 
> axutil_allocator_swith_to_local_pool.
> However there could be problematic situations if used this carelessly. For 
> example consider the following scenario.
> swith_to_global
> ...do something...
> switch_to_global
> ...do something
> swith_to_local
> !!! Now am I using global memory or local memory?.  Ideally now I should 
> still be using global memory. But accoring to current Axis2/C implementation 
> at this stage I'm using local memory. This could lead to unavoidable problems.
> Attached patch fix this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (AXIS2C-1377) switching to global/local pools when used with apache module

[Damitha Kumarage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damitha Kumarage updated AXIS2C-1377:
-

Attachment: allocator_switching.diff

Patch providing the solution

> switching to global/local pools when used with apache module
> 
>
> Key: AXIS2C-1377
> URL: https://issues.apache.org/jira/browse/AXIS2C-1377
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: util
> Environment: all
>Reporter: Damitha Kumarage
>    Assignee: Damitha Kumarage
> Attachments: allocator_switching.diff
>
>
> When Axis2/C is used with the httpd module to allocate memory in apache 
> global pools one need to call the axutil function 
> axutil_allocator_switch_to_global_pool. To switch back again to use apache 
> local pool(request level allocation) one need to call the 
> axutil_allocator_swith_to_local_pool.
> However there could be problematic situations if used this carelessly. For 
> example consider the following scenario.
> swith_to_global
> ...do something...
> switch_to_global
> ...do something
> swith_to_local
> !!! Now am I using global memory or local memory?.  Ideally now I should 
> still be using global memory. But accoring to current Axis2/C implementation 
> at this stage I'm using local memory. This could lead to unavoidable problems.
> Attached patch fix this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (AXIS2C-1377) switching to global/local pools when used with apache module

[Damitha Kumarage (JIRA)]

switching to global/local pools when used with apache module


 Key: AXIS2C-1377
 URL: https://issues.apache.org/jira/browse/AXIS2C-1377
 Project: Axis2-C
  Issue Type: Improvement
  Components: util
 Environment: all
Reporter: Damitha Kumarage
Assignee: Damitha Kumarage


When Axis2/C is used with the httpd module to allocate memory in apache global 
pools one need to call the axutil function 
axutil_allocator_switch_to_global_pool. To switch back again to use apache 
local pool(request level allocation) one need to call the 
axutil_allocator_swith_to_local_pool.
However there could be problematic situations if used this carelessly. For 
example consider the following scenario.

swith_to_global

...do something...

switch_to_global

...do something

swith_to_local

!!! Now am I using global memory or local memory?.  Ideally now I should still 
be using global memory. But accoring to current Axis2/C implementation at this 
stage I'm using local memory. This could lead to unavoidable problems.

Attached patch fix this.




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE][Rampart/C] Apache Rampart/C 1.3.0 Release

[Damitha Kumarage]

+1
Damitha
Uthaiyashankar wrote:

Hi,

I have uploaded the Apache Rampart/C 1.3.0 release artifacts here:
http://people.apache.org/~shankar/rampartc/1_3_0/take1/

The key is here:
http://people.apache.org/~shankar/rampartc/1_3_0/take1/KEYS


Please test, review and vote on the release artifacts for Apache
Rampart/C 1.3.0 release.
Please test it with Apache Axis2/C 1.6.0, which can be downloaded from here:
http://ws.apache.org/axis2/c/download.cgi

Here is my vote +1.

Regards,
Shankar

  



--
__

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

Re: [VOTE][AXIS2]Apache Axis2/C 1.6.0 Release artificats - Take2

[Damitha Kumarage]

I tested both source and binary in Ubuntu with Sandesha2/C and Savan/C.
Here is my +1

Thanks,
Damitha
Manjula Peiris wrote:

Hi,

I have uploaded the Apache Axis2/C 1.6.0 release artifacts here.

http://people.apache.org/~manjula/release/1.6.0/

The keys are here.

http://people.apache.org/~manjula/release/1.6.0/KEYS

If the release artifacts are fine please vote for Axis2/C 1.6.0 release.

Here is my vote +1.

Thanks,
-Manjula



  



--
__

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

Re: Axis2/C 1.6.0 RC3

[Damitha Kumarage]

Hi Manjula,
I tested both binary and source in Ubuntu with following(For Apache2 and 
Axis2/C server)


Sandesha2/C
Savan/C
All Axis2/C samples

They work fine.
However I have small issue. I find autogen.sh script in samples folder 
but not in root folder. Is this intentional?


thanks,
Damitha


Manjula Peiris wrote:

Hi all,

I have packed and uploaded Apache Axis2/C 1.6.0 RC3 here [1]. Please
test and send your feedback.

[1] http://people.apache.org/~manjula/release/1.6.0/rc3/

Thanks,
-Manjula.


  



--
__

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

[jira] Created: (AXIS2C-1361) xpath fails when chile elements are prefixed

[Damitha Kumarage (JIRA)]

xpath fails when chile elements are prefixed


 Key: AXIS2C-1361
 URL: https://issues.apache.org/jira/browse/AXIS2C-1361
 Project: Axis2-C
  Issue Type: Bug
  Components: xml/om
Reporter: Damitha Kumarage


xpath 
Envelope/Header/Topic

does not work for following


http://schemas.xmlsoap.org/soap/envelope/";>
  http://www.w3.org/2005/08/addressing";>
 http://apache.org/aip";>synapse/event/test
 .
 .

But work for
http://schemas.xmlsoap.org/soap/envelope/";>
  http://www.w3.org/2005/08/addressing";>
 http://apache.org/aip";>synapse/event/test
 .
 .





-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (AXIS2C-1355) Changing service client options between messages

[Damitha Kumarage (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12680766#action_12680766
 ] 

Damitha Kumarage commented on AXIS2C-1355:
--

The best thing is take the options struct from svc_client in your subsequence 
uses of svc_client and set the new options there. Also there there is a 
function you can try called svc_client_set_override_options(). However I 
haven't used that and don't know whether it work.

I could reproduce the problem you mentioned. Yes there is a bug there. After 
options struct is freed from the service client it tries to access an option 
from within the same options struct set to op_client.

> Changing service client options between messages
> 
>
> Key: AXIS2C-1355
> URL: https://issues.apache.org/jira/browse/AXIS2C-1355
> Project: Axis2-C
>  Issue Type: Bug
>  Components: core/clientapi
>Affects Versions: 1.6.0
> Environment: Axis2/C from svn (26 Feb 2009)
> Linux 2.6.9-42.ELsmp #1 SMP Wed Jul 12 23:27:17 EDT 2006 i686 i686 i386 
> GNU/Linux
>Reporter: Rutger van Eerd
>
> I want to use a single service client to send multiple messages, with 
> different options (i.e. SOAP action). Basicly I do the following.
> 1. Create service client object.
> 2. Create options object and set options.
> 3. Set options to service client (axis2_svc_client_set_options).
> 4. Execute message (axis2_svc_client_send_receive).
> 5. Create new options object and set new options.
> 6. Set new options to service client (axis2_svc_client_set_options).
> 7. Execute new message (axis2_svc_client_send_receive).
> When doing step 7, I get the following message when running under Valgrind.
> ==3630== Invalid read of size 4
> ==3630==at 0x40954A2: axis2_options_get_xml_parser_reset (options.c:883)
> ==3630==by 0x4095E02: axis2_op_client_free (op_client.c:655)
> ==3630==by 0x4097D2E: axis2_svc_client_create_op_client 
> (svc_client.c:1072)
> ==3630==by 0x4099735: axis2_svc_client_send_receive_with_op_qname 
> (svc_client.c:835)
> ==3630==by 0x4099A1C: axis2_svc_client_send_receive (svc_client.c:939)
> ==3630==by 0x80496BA: main (client.cpp:273)
> ==3630==  Address 0x427CD4C is 60 bytes inside a block of size 64 free'd
> ==3630==at 0x4004EFA: free (vg_replace_malloc.c:235)
> ==3630==by 0x4010E82: axutil_allocator_free_impl (allocator.c:92)
> ==3630==by 0x40951D8: axis2_options_free (options.c:787)
> ==3630==by 0x409785D: axis2_svc_client_set_options (svc_client.c:376)
> ==3630==by 0x804961F: main (client.cpp:261)
> My guess is that the op_client tries to access the old options object from 
> step 2/3. This is no longer valid as it has been freed when setting the new 
> options (step 6).
> Or is svc_client not designed to send multiple messages with different 
> options?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (AXIS2C-1349) Time Duration related functions does not work

[Damitha Kumarage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damitha Kumarage resolved AXIS2C-1349.
--

Resolution: Fixed

This is fixed

> Time Duration related functions does not work
> -
>
> Key: AXIS2C-1349
> URL: https://issues.apache.org/jira/browse/AXIS2C-1349
> Project: Axis2-C
>  Issue Type: Bug
>    Reporter: Damitha Kumarage
>
> axis2_char_t *duration_str = "P19Y6M4DT12H30M5S";
> axutil_duration_t *duration = NULL;
> axis2_char_t *result = NULL;
> duration = axutil_duration_create_from_string(env, duration_str);
> result = axutil_duration_serialize_duration(duration, env);
> printf("result:%s\n", result);
> Above code does not work as there is always exception hit in the code. By 
> commenting the following check in code
> it works.
> while (seq < sizeof(desig))
> {
> if (*cur == desig[seq])
> {
> num_type = 0;
> /*if (seq < (sizeof(desig) - 1))
> {
> duration->is_negative = AXIS2_FALSE;
> duration->years = duration->months = duration->days = 
> duration->hours = duration->mins = 0;
> duration->secs = 0;
> AXIS2_ERROR_SET(env->error, AXIS2_ERROR_NONE,
> AXIS2_FAILURE);
> return AXIS2_FAILURE;
> }*/

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (AXIS2C-1354) new function axis2_svc_client_get_conf_ctx() needed.

[Damitha Kumarage (JIRA)]

new function axis2_svc_client_get_conf_ctx() needed.


 Key: AXIS2C-1354
 URL: https://issues.apache.org/jira/browse/AXIS2C-1354
 Project: Axis2-C
  Issue Type: Bug
Reporter: Damitha Kumarage


It is desired to have above function for the service client api to retrieve the 
configuration context. In some instances after first service client is created 
we should be able to retrieve the configuration context from that service 
client and create new service cients passing that configuraiton context using 
axis2_svc_client_create_with_conf_ctx_and_svc() function.
This is very useful since creating configuration context is very expensive task 
since this reads all configuration files again and again.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (AXIS2C-1353) Externally passed configuration context and service should not be freed within service client

[Damitha Kumarage (JIRA)]

Externally passed configuration context and service should not be freed within 
service client
-

 Key: AXIS2C-1353
 URL: https://issues.apache.org/jira/browse/AXIS2C-1353
 Project: Axis2-C
  Issue Type: Bug
Reporter: Damitha Kumarage


We have axis2_svc_client_create_with_conf_ctx_and_svc function to create a 
service client using existing configuration context and service. Currently when 
service client is freed these are freed as well. However according to the 
memory handling conventions of Axis2/C these should be freed by the caller 
function, not by the service client.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Axis2/C 1.6.0 RC1

[Damitha Kumarage]

Hi,

Currently $AXIS2C_HOME/samples contain samples source code only which is 
useful for users of the binary dist. I don't think it is wise to move 
bins and libraries into this.

Instead I suggest to keep
$AXIS2C_HOME/bin/samples and
add $AXIS2C_HOME/lib/samples for libraries

thanks
Damitha,

Supun Kamburugamuva wrote:
How about moving the samples folder from the bin directory and put it 
to the root level. I know this is a hard thing to do, but it seems to 
be the right thing :)


Supun

On Thu, Mar 5, 2009 at 9:43 AM, Uthaiyashankar <mailto:shan...@wso2.com>> wrote:


Hi Dinesh,

On Thu, Mar 5, 2009 at 9:34 AM, Dinesh Premalal
mailto:xydin...@gmail.com>> wrote:

Hi,

Manjula Peiris mailto:manj...@wso2.com>>
writes:
> Even though they are libraries those are samples. For example in
> Rampart/C we installed passwordcallback libraries in
bin/samples. Shall
> I make them to be installed in bin/samples or is there any
other better
> place ?

1. 'bin' directory

  I think it should contains executables only. In this case those
  directories contains shared libraries therefore it is not
the right
  place.

2. 'lib' directory

  This is the place shared library should place. However these are
  just shared libraries of a sample(ie. it is not a part of
  Axis2/C core).

Due to these reason I think those directories should place under
samples/lib. Please correct me If I'm mistaken.



What you are suggesting is $AXIS2C_HOME/bin/samples/lib or
$AXIS2C_HOME/samples/lib?

I think, it is better to put it inside
$AXIS2C_HOME/bin/samples/lib (we don't have $AXIS2C_HOME/samples
upto now)

Regards,
Shankar

 




thanks,
Dinesh




-- 
S.Uthaiyashankar

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





--
Software Engineer, WSO2 Inc
http://wso2.org
supunk.blogspot.com <http://supunk.blogspot.com>





--
__

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

Re: Axis2/C 1.6.0 RC1

[Damitha Kumarage]

Uthaiyashankar wrote:

Hi Dinesh,

On Thu, Mar 5, 2009 at 9:34 AM, Dinesh Premalal <mailto:xydin...@gmail.com>> wrote:


Hi,

Manjula Peiris mailto:manj...@wso2.com>> writes:
> Even though they are libraries those are samples. For example in
> Rampart/C we installed passwordcallback libraries in
bin/samples. Shall
> I make them to be installed in bin/samples or is there any other
better
> place ?

1. 'bin' directory

  I think it should contains executables only. In this case those
  directories contains shared libraries therefore it is not the right
  place.

2. 'lib' directory

  This is the place shared library should place. However these are
  just shared libraries of a sample(ie. it is not a part of
  Axis2/C core).

Due to these reason I think those directories should place under
samples/lib. Please correct me If I'm mistaken.



What you are suggesting is $AXIS2C_HOME/bin/samples/lib or 
$AXIS2C_HOME/samples/lib?


I think, it is better to put it inside $AXIS2C_HOME/bin/samples/lib 
(we don't have $AXIS2C_HOME/samples upto now)

We have $AXIS2C_HOME/samples(At least in linux install :) )


Regards,
Shankar

 




thanks,
Dinesh




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





--
______

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

Savan/C 1.0 Release

[Damitha Kumarage]

Hi devs,

I propose we do a Apache Savan/C 1.0 release. I would like to be the 
release manager.

Currently following features are implemented

 1. Support for WS-Eventing Specification August 2004.
 2. Support for Subscribe, Unsubscribe, Renew and GetStatus operations.
 3. Support for subscription management endpoint which could be the
 Event Source itself or separate subscription management endpoint.
 4. Pluggable storage managers. Currently support three storage 
managers namely

  - Sqlite based embedded storage manager
  - Service based storage manager.
  - WSO2 registry based storage manager.

 5. Pluggable filtering support for server side.
 6. Interoperability with Apache Savan/Java implementation.
 7. Interoperablity with WSO2 ESB/Eventing stack. 
 6. Support for both SOAP 1.1 and 1.2.

 7. Comprehensive samples to test scenarios.
 8. Documentation

Your suggestions are welcome.

Thanks,
Damitha.
--
__

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

Re: Axis2/C 1.6.0 RC1

[Damitha Kumarage]

Manjula Peiris wrote:

On Wed, 2009-03-04 at 01:50 -0500, Dinesh Premalal wrote:
  

Hi, Manjula,

   I test axis2c-src-1.6.0 and one thing I noticed is, once we
   installed there are two directories under bin/ directory called
   'mtom_caching_callback' and 'mtom_sending_callback'. Those
   directories contains some libraries. 


   I feel like 'bin' directory is not a right place for them because so far
   we had only executables in the 'bin' folder.



Even though they are libraries those are samples. For example in
Rampart/C we installed passwordcallback libraries in bin/samples. Shall
I make them to be installed in bin/samples or is there any other better
place ? 
  

Moving it to the bin/samples is the right thing to do.
thanks,
Damitha


  

   What do you think ?

thanks,
Dinesh

Manjula Peiris  writes:



Hi all,

I have packed and uploaded Apache Axis2/C 1.6.0 RC1 here [1]. Please
test and send your feedback.

[1] http://people.apache.org/~manjula/release/1.6.0/rc1/

Thanks,
-Manjula.



--
Manjula Peiris
Senior Software Engineer
WSO2 Inc.
Oxygenating the Web Service Platform.
http://wso2.org/
Blog: http://manjula-peiris.blogspot.com/
  



  



--
______

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

[jira] Created: (AXIS2C-1350) Adding hours/mins/secs etc to the duration does not add up correctly

[Damitha Kumarage (JIRA)]

Adding hours/mins/secs etc to the duration does not add up correctly


 Key: AXIS2C-1350
 URL: https://issues.apache.org/jira/browse/AXIS2C-1350
 Project: Axis2-C
  Issue Type: Bug
Reporter: Damitha Kumarage


axis2_char_t *duration_str = "P19Y6M4DT12H30M5S";
printf("input:%s\n",  duration_str);
axutil_duration_t *duration = NULL;
axis2_char_t *result = NULL;

duration = axutil_duration_create_from_string(env, duration_str);
int hours = axutil_duration_get_hours(duration, env);
axutil_duration_set_hours(duration, env, hours + 13);
result = axutil_duration_serialize_duration(duration, env);
printf("result:%s\n", result);


The output of the above program should ideally be
input:P19Y6M4DT12H30M5S
result:P19Y6M5DT1H30M5.00S

But it is actually is
input:P19Y6M4DT12H30M5S
result:P19Y6M4DT25H30M5.00S

When hours exceed 24 it should be counted as 1 days and 1 hour instead of 25 
hours. This problem is there for other time units as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (AXIS2C-1349) Time Duration related functions does not work

[Damitha Kumarage (JIRA)]

Time Duration related functions does not work
-

 Key: AXIS2C-1349
 URL: https://issues.apache.org/jira/browse/AXIS2C-1349
 Project: Axis2-C
  Issue Type: Bug
Reporter: Damitha Kumarage


axis2_char_t *duration_str = "P19Y6M4DT12H30M5S";
axutil_duration_t *duration = NULL;
axis2_char_t *result = NULL;

duration = axutil_duration_create_from_string(env, duration_str);
result = axutil_duration_serialize_duration(duration, env);
printf("result:%s\n", result);

Above code does not work as there is always exception hit in the code. By 
commenting the following check in code
it works.

while (seq < sizeof(desig))
{
if (*cur == desig[seq])
{
num_type = 0;
/*if (seq < (sizeof(desig) - 1))
{
duration->is_negative = AXIS2_FALSE;
duration->years = duration->months = duration->days = 
duration->hours = duration->mins = 0;
duration->secs = 0;

AXIS2_ERROR_SET(env->error, AXIS2_ERROR_NONE,
AXIS2_FAILURE);
return AXIS2_FAILURE;
}*/

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (AXIS2C-1348) Redundancy in Date/Time functions

[Damitha Kumarage (JIRA)]

Redundancy in Date/Time functions
-

 Key: AXIS2C-1348
 URL: https://issues.apache.org/jira/browse/AXIS2C-1348
 Project: Axis2-C
  Issue Type: Bug
Reporter: Damitha Kumarage


In axis2 time handling functions there are lot of unneccessary redundancies 
which in my view complicate the life of developer unneccessarily. For example 
following five functions
axutil_date_time_deserialize_date()
axutil_date_time_deserialize_time()
axutil_date_time_deserialize_date_time()
axutil_date_time_deserialize_time_with_time_zone()
axutil_date_time_deserialize_date_time_with_time_zone()

could be reduced into one function called 
axutil_date_time_deserialize_date_time(). Within the function the date time 
string should be analized to see whether it is date time, date, time, date/time 
with time zone etc etc.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (AXIS2C-1329) There should be a stub creation api function that take axis2 configuration context as parameter

[Damitha Kumarage (JIRA)]

There should be a stub creation api function that take axis2 configuration 
context as parameter
---

 Key: AXIS2C-1329
 URL: https://issues.apache.org/jira/browse/AXIS2C-1329
 Project: Axis2-C
  Issue Type: Improvement
Reporter: Damitha Kumarage


It is desired to have the above api function so that when creating a stub an 
existing configuration context could be used.

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);

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (AXIS2C-1328) Implementing new transport to optimize Axis2/C when used in a multi-threading client environment.

[Damitha Kumarage (JIRA)]

Implementing new transport to optimize Axis2/C when used in a multi-threading 
client environment.
-

 Key: AXIS2C-1328
 URL: https://issues.apache.org/jira/browse/AXIS2C-1328
 Project: Axis2-C
  Issue Type: Improvement
  Components: core/transport
Reporter: Damitha Kumarage
Priority: Minor


I would like to highlight the following discussion in mailing thread[1].

Patric:
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.

Carl:
My reason for responding though is really to comment on this phrase:"Threads 
are a rather expensive resource to use for just waiting on an IO completion".  
It may be my lack of understanding, but I am pretty
sure that -- at least in the win32 tcp/ip stack -- once your thread goes into 
asynchronous communication on a socket, you do not see it again until there is 
some result.  This means if there is a timeout your
thread is inactive for a long time.  How can one thread wait on more than one 
asychronous communication?  I admit this would be a far better solution, 
however from my understanding of winsock2 it is not possible.

Seen this way, one thread per socket communication is maybe expensive in 
resources, but it is the only way to ensure your main thread continues to 
operate in a timely fashion.

Patric: 
With the fd_set in winsock and the select() function, you can wait at a maximum 
of 64 (current implementation) sockets at once. With I/O Completion Ports you 
can use one thread for an infinite number of ports (though a pool of threads 
might be a good idea if the number of sockets grows large). This is also used 
by the well known boost (C++) library. Mechanisms like these would be a much 
better implementation. But I think they don't fit well in the modular 
(transportation) design of axis, since they require knowledge about the lower 
level transportation on a higher level.

Carl:That's very interesting.  I'm curious as to more of the details of how 
this functions... If you have one thread waiting on 12 sockets and want to make 
a new call, can this thread begin the next call, or does a second thread open 
the socket and pass the job of waiting on it to the first thread?

I think we would all agree that your use case would benefit from adding this 
capability to Axis2/C.  You mention a potential conflict with the modular 
design of Axis; there is also the idea that making such a powerful feature 
accessible to the average programmer using Axis could be a challenge.  Maybe 
the solution would be to add a new communication mode instead of changing all 
asynchronous communication to one-thread-multi-socket.  I wish I understood the 
Axis2/C architecture
more fully because this would be an interesting area to contribute.

Patric:
But one implementation might be to add another 'configuration structure' (like 
the allocator and thread pool) for socket IO and make that responsible for all 
IO. That implementation can then decide to use one or multiple threads for IO. 
It can use call-backs to signal the completion (or failure or timeout) of the 
IO. The async calls can then be implemented as writing data (by the new io 
struct) and exiting that start-call. Finished. Nothing more to do. No extra 
thread, nothing. Then, when finished, the call-back can be used to parse the 
result and call the user call-back for the result. The io struct (module) 
should probably use a (real!) thread pool for this to prevent one 
time-consuming call to block other calls. But a simple implementation might to 
for the 'average' user. This pattern mimics the io completion port / boost 
interface, so users of axis can easily use these for their async IO.

--
By looking at the above discussion I suggest implementing a new transport for 
Axis2/C using boost library[2] or some other good library that would do the 
job. Boost is based on  Reactor/Proactor I/O design patterns [3]. However this 
would require some changes to Axis2/C engine internals.

Note: In the start of the discussion Carl says "The asynchronous call 
implementation of axis is based on creating new threads that just wait on a 
response";

[jira] Created: (AXIS2C-1327) Providing resource free callback in Dual channel non blocking scenarios

[Damitha Kumarage (JIRA)]

Providing resource free callback in Dual channel non blocking scenarios
---

 Key: AXIS2C-1327
 URL: https://issues.apache.org/jira/browse/AXIS2C-1327
 Project: Axis2-C
  Issue Type: Improvement
  Components: core/engine
Reporter: Damitha Kumarage


In dual channel non blocking scenarios user pass callback with callback on 
complete function set. However in case where
application programmer need to free resources(like stub, axis2 environment) per 
call basis he cannot do so even after his
on complete function is called because shared resources still may be used by 
Axis2/C engine. To avoid this it is suggested
in the mail thread[1] that a second resource free callback may be provided by 
the client application programmer
which will be called by the Axis2/C engine once it is ready to free resources.

[1] http://marc.info/?t=12289924781&r=1&w=2

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (AXIS2C-1326) Improvment to Axis2/C client side thread pool

[Damitha Kumarage (JIRA)]

Improvment to Axis2/C client side thread pool
-

 Key: AXIS2C-1326
 URL: https://issues.apache.org/jira/browse/AXIS2C-1326
 Project: Axis2-C
  Issue Type: Improvement
  Components: core/clientapi
Reporter: Damitha Kumarage


Currently Axis2/C client engine don't make use of the thread pool facility even 
if we pass one.
It just request threads from the thread pool and may exhaust all available 
threads until
blocking the main thread at some point waiting for new thread which is not what
the user desire by passing a thread pool. This limitation could be addressed by 
not requesting
threads from the passed thread pool but instead passing the job to the thread 
pool(probably thread
method and data). Then the thread pool handle the jobs without never blocking 
the main thread.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Can I always assume axis2_desc_t children are axis2_msg_t ?

[Damitha Kumarage]

Manjula Peiris wrote:

Hi,

While fixing https://issues.apache.org/jira/browse/AXIS2C-1313
I came across $subject. Currently axis2_desc_add_child() method call
only from op.c. But according to the Axis2 architecture it shouldn't
only be axis2_msg_t. WDYT ?
  
AFAIK it could be only axis2_msg_t. Perhaps you are wondering why in 
that method signature child is a void pointer without specifically being 
a axis2_msg_t. And as I remember this was originally designed to be used 
for any parent in the description hierarchy to add a child. However it 
was not used in that way.
So may be to avoid confusion we may pass axis2_msg_t there instead of 
void pointer.


thanks,
Damitha

Thanks,
-Manjula

 
  



--
______

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

Re: Multi-threading

[Damitha Kumarage]

Hi Patrick
Patrick van Beem wrote:

No. The current implementation of axis relies on an infinite number of 
available threads. It assumes that when it requests a thread, it's getting one 
and it then starts the thread with a thread method / data. But in reality, a 
thread pool would have a finite number of (re-used) threads. In the case of 
axis, this would mean that the thread requesting the new thread would block 
until a new thread is available. This is not what you want. For axis to work 
with  a finite number of threads, the way it uses threads should change. It 
should not request a thread, but it should submit a job (probably the thread 
method and data) to the thread pool. The submitting thread can then continue an 
the thread pool can decide when the job is performed by which thread.

Thanks for the explanation. I agree with it.
thanks,
Damitha

--
______

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

Re: RE : Multi-threading

[Damitha Kumarage]

Patrick van Beem wrote:

Hello Carl,

  

What Axis does well is freeing resources (once we figure out how to set
everything up right!) so I am a little confused as to where exactly the
limitations are.  You say the callback system provided is not good in
terms of freeing resources, but have you tried freeing your resources
from another function which itself waits for the callback to occur?
(either error callback or success callback)  I think this is the way
Axis was designed with as implied by Dimuthu: wait in a loop in your
main thread while the callbacks are outstanding, do no cleanup in the
callback itself, let that thread exit completely and after it is done,
then from your main thread detect that the callback ocurred and do the
cleanup there.  



Correct. But I think the design is missing one thing. If I allocate the stub and env and then do an async call, I'm not allowed to free those two resources in the callback, because they're used by the axis framework. But if I signal the main thread from the callback, to free the resources, the callback might be switched out directly after this signal, and the main thread might free the resources before the callback ended and the axis framework used them. As you indicate, the only safe way is to wait until the thread is finished. But the axis framework does not provide an api to find out which thread is processing you request. And it shouldn't, because the thread mechanism is an implementation detail of the axis framework. Future versions might re-use the thread or even use no threading at all for asynchronous calls. So the only safe way to free resources is for the axis framework to signal the caller that the resources are no longer needed. A (second?) callback is the most used (elegant) way to do this. 
Yes, this problem exists in the current implementation. A second 
callback as you said is the ideal solution.

thanks,
Damitha

Right now, the framework does not provide a safe way of freeing resources in 
async calls.

  

My reason for responding though is really to comment on this phrase:
"Threads are a rather expensive resource to use for just waiting on an
IO completion".  It may be my lack of understanding, but I am pretty
sure that -- at least in the win32 tcp/ip stack -- once your thread goes
into asynchronous communication on a socket, you do not see it again
until there is some result.  This means if there is a timeout your
thread is inactive for a long time.  



Correct. So if I've got a couple of hundred outstanding calls, they all consume 
precious memory. In our case, this is a lot of memory, since we have a heavy 
server applications with a greedy memory allocation strategy per thread (for 
performance) and a rather large default stacks. Of course, both can be 
optimized for the 'just waiting on io-completion'-threads...
CPU-wise, it's no problem.

  

How can one thread wait on more
than one asychronous communication?  I admit this would be a far better
solution, however from my understanding of winsock2 it is not possible.



With the fd_set in winsock and the select() function, you can wait at a maximum 
of 64 (current implementation) sockets at once. With I/O Completion Ports you 
can use one thread for an infinite number of ports (though a pool of threads 
might be a good idea if the number of sockets grows large). This is also used 
by the well known boost (C++) library. Mechanisms like these would be a much 
better implementation. But I think they don't fit well in the modular 
(transportation) design of axis, since they require knowledge about the lower 
level transportation on a higher level.
 
  

Seen this way, one thread per socket communication is maybe expensive in
resources, but it is the only way to ensure your main thread continues
to operate in a timely fashion.



But prone to explode with a log of async calls. As a 'workaround' I've now my 
own static-sized thread pool that perform synchronous calls. If there are more 
async calls then threads in the pool, they're queued.
  
Thank you for your input.


  



--
__

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

Re: Multi-threading

[Damitha Kumarage]

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/
__

Re: RE : RE : Multi-threading

[Damitha Kumarage]

onality through environment structure seems 
inappropriate. Also it is not clear to me how to implement it in that 
way. WDYT?.


thanks,
Damitha

[1] 
http://www.boost.org/doc/libs/1_37_0/doc/html/boost_asio/overview/core/async.html


--
__

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

[jira] Resolved: (AXIS2C-1301) Can not change the axis2c logger.

[Damitha Kumarage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damitha Kumarage resolved AXIS2C-1301.
--

Resolution: Fixed

This is fixed

> Can not change the axis2c logger.
> -
>
> Key: AXIS2C-1301
> URL: https://issues.apache.org/jira/browse/AXIS2C-1301
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: util
>Affects Versions: 1.5.0
> Environment: Linux SuSe 10, Intel Xeon 64 bits, Axis2c 1.5.0
>Reporter: Leonardo Kausilas
>Priority: Minor
> Fix For: 1.6.0
>
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> Can not change the axis2c logger because the macros AXIS2_LOG_DEBUG, 
> AXIS2_LOG_INFO, etc calls directly to axutil_log_impl_log_debug, 
> axutil_log_impl_log_info, etc and never calls to axutil_log_ops_t.write 
> function pointer.
> If the macros calls a generic function that calls the axutil_log_ops_t.write 
> function pointer, everyone who wants to change the logger could create a new 
> axutil_log_ops_t struct initializing it with your own pointers, like the XML 
> parser, allocator, etc.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (AXIS2C-1301) Can not change the axis2c logger.

[Damitha Kumarage (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652301#action_12652301
 ] 

Damitha Kumarage commented on AXIS2C-1301:
--

Please se AXIS2C-1286 is related to your issue

> Can not change the axis2c logger.
> -
>
> Key: AXIS2C-1301
> URL: https://issues.apache.org/jira/browse/AXIS2C-1301
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: util
>Affects Versions: 1.5.0
> Environment: Linux SuSe 10, Intel Xeon 64 bits, Axis2c 1.5.0
>Reporter: Leonardo Kausilas
>Priority: Minor
>   Original Estimate: 3h
>  Remaining Estimate: 3h
>
> Can not change the axis2c logger because the macros AXIS2_LOG_DEBUG, 
> AXIS2_LOG_INFO, etc calls directly to axutil_log_impl_log_debug, 
> axutil_log_impl_log_info, etc and never calls to axutil_log_ops_t.write 
> function pointer.
> If the macros calls a generic function that calls the axutil_log_ops_t.write 
> function pointer, everyone who wants to change the logger could create a new 
> axutil_log_ops_t struct initializing it with your own pointers, like the XML 
> parser, allocator, etc.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Axis2] VOTE Danushka Menikkumbura as Commiter

[Damitha Kumarage]

Hi Devs,

I would like to nominate Danushka Menikkumbura to be an Axis2/C commiter.

Danushka has implemented AMQP transport for Axis2/C project and he has 
applied several patches to the Axis2/C code base for the same purpose. 
He has also contributed patches to Sandesha2/C and has been active in 
mailing lists.


I am confident that Danushka will continue to be an valuble contributor 
to Axis2/C project.


Following are the links to the patches he submitted for Axis2/C and 
Sandesha2/C projects.


Here is my vote. +1

Thanks,
Damitha

Axis2/C
=

[1]https://issues.apache.org/jira/browse/AXIS2C-1300
[2]https://issues.apache.org/jira/browse/AXIS2C-1299
[3]https://issues.apache.org/jira/browse/AXIS2C-1298
[4]https://issues.apache.org/jira/browse/AXIS2C-1293
[5]https://issues.apache.org/jira/browse/AXIS2C-1292
[6]https://issues.apache.org/jira/browse/AXIS2C-1291
[7]https://issues.apache.org/jira/browse/AXIS2C-1193
[8]https://issues.apache.org/jira/browse/AXIS2C-1191
[9]https://issues.apache.org/jira/browse/AXIS2C-1131
[10]https://issues.apache.org/jira/browse/AXIS2C-1104

Sandesha2/C


[1]https://issues.apache.org/jira/browse/SANDESHA2C-71
[2]https://issues.apache.org/jira/browse/SANDESHA2C-70
[3]https://issues.apache.org/jira/browse/SANDESHA2C-69
--
__

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: The addressing dispatch problem

[Damitha Kumarage]

Hi Andriy,
Please try with latest svn sources and let me know the results. Here you 
can find links [1]

thanks,
Damitha

[1] http://wso2.org/projects

Andriy Vitkovskyy wrote:

Hi Damitha

I set variable AXIS2C_HOME and library exist  
...\modules\addressing\axis2_mod_addr.dll  
...\modules\addressing\module.xml and add to config-file axis2.xml  



axis2_http_server.exe crash  when savan services send request 
(download from http://ws.apache.org/savan/c/download.cgi)


2008/11/24 Damitha Kumarage <[EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]>>


Hi Andriy,

Have you set AXIS2C_HOME environment variable to the repository
folder?. If so make sure you have addressing module in
/modules/addressing.

thanks,
Damitha

Andriy Vitkovskyy wrote:

Hi

I use Apache Axis2/C 1.5.0 version with savan module.
I have a problem with addressing dispatch.
Module.xml


  
  
  
  
  

Axis2_htt_server.exe crash after request subscribe (request
WS-Eventing, use subscriber.exe - client)

Log

..
[Fri Nov 21 21:43:12 2008] [debug]
..\..\samples\server\publisher\publisher_skeleton.c(259)
[SAVAN] Inside while loop
[Fri Nov 21 21:43:12 2008] [debug]
..\..\src\client\savan_publishing_client.c(96) [savan]
Start:savan_publishing_client_publish
[Fri Nov 21 21:43:12 2008] [debug]
..\..\src\client\savan_publishing_client.c(167) [savan]
End:savan_publishing_client_publish
[Fri Nov 21 21:43:17 2008] [debug]
..\..\samples\server\publisher\publisher_skeleton.c(259)
[SAVAN] Inside while loop
[Fri Nov 21 21:43:17 2008] [debug]
..\..\src\client\savan_publishing_client.c(96) [savan]
Start:savan_publishing_client_publish
[Fri Nov 21 21:43:17 2008] [debug]
..\..\src\client\savan_publishing_client.c(167) [savan]
End:savan_publishing_client_publish
[Fri Nov 21 21:43:22 2008] [debug]
..\..\samples\server\publisher\publisher_skeleton.c(259)
[SAVAN] Inside while loop
[Fri Nov 21 21:43:22 2008] [debug]
..\..\src\client\savan_publishing_client.c(96) [savan]
Start:savan_publishing_client_publish
[Fri Nov 21 21:43:22 2008] [debug]
..\..\src\client\savan_publishing_client.c(162) [savan][out
handler] Publishing to 76af55cd-6c91-4c94-8764-d0daddb59b3
[Fri Nov 21 21:43:22 2008] [debug]
..\..\src\subscribers\savan_subscriber.c(387) [savan]
Start:savan_subscriber_publish
[Fri Nov 21 21:43:22 2008] [debug]
..\..\src\core\engine\phase.c(121) axis2_handler_t
*request_uri_based_dispatcher added to the index 0 of the
phase Transport
[Fri Nov 21 21:43:22 2008] [debug]
..\..\src\core\engine\phase.c(121) axis2_handler_t
*addressing_based_dispatcher added to the index 1 of the phase
Transport

How fixed its?

With respect, Andriy.



-- 
__


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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>





--
______

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: The addressing dispatch problem

[Damitha Kumarage]

Hi Andriy,

Have you set AXIS2C_HOME environment variable to the repository folder?. 
If so make sure you have addressing module in 
/modules/addressing.


thanks,
Damitha
Andriy Vitkovskyy wrote:

Hi

I use Apache Axis2/C 1.5.0 version with savan module.
I have a problem with addressing dispatch.
Module.xml


   
   
   
   
   

Axis2_htt_server.exe crash after request subscribe (request 
WS-Eventing, use subscriber.exe - client)


Log
..
[Fri Nov 21 21:43:12 2008] [debug] 
..\..\samples\server\publisher\publisher_skeleton.c(259) [SAVAN] 
Inside while loop
[Fri Nov 21 21:43:12 2008] [debug] 
..\..\src\client\savan_publishing_client.c(96) [savan] 
Start:savan_publishing_client_publish
[Fri Nov 21 21:43:12 2008] [debug] 
..\..\src\client\savan_publishing_client.c(167) [savan] 
End:savan_publishing_client_publish
[Fri Nov 21 21:43:17 2008] [debug] 
..\..\samples\server\publisher\publisher_skeleton.c(259) [SAVAN] 
Inside while loop
[Fri Nov 21 21:43:17 2008] [debug] 
..\..\src\client\savan_publishing_client.c(96) [savan] 
Start:savan_publishing_client_publish
[Fri Nov 21 21:43:17 2008] [debug] 
..\..\src\client\savan_publishing_client.c(167) [savan] 
End:savan_publishing_client_publish
[Fri Nov 21 21:43:22 2008] [debug] 
..\..\samples\server\publisher\publisher_skeleton.c(259) [SAVAN] 
Inside while loop
[Fri Nov 21 21:43:22 2008] [debug] 
..\..\src\client\savan_publishing_client.c(96) [savan] 
Start:savan_publishing_client_publish
[Fri Nov 21 21:43:22 2008] [debug] 
..\..\src\client\savan_publishing_client.c(162) [savan][out handler] 
Publishing to 76af55cd-6c91-4c94-8764-d0daddb59b3
[Fri Nov 21 21:43:22 2008] [debug] 
..\..\src\subscribers\savan_subscriber.c(387) [savan] 
Start:savan_subscriber_publish
[Fri Nov 21 21:43:22 2008] [debug] ..\..\src\core\engine\phase.c(121) 
axis2_handler_t *request_uri_based_dispatcher added to the index 0 of 
the phase Transport
[Fri Nov 21 21:43:22 2008] [debug] ..\..\src\core\engine\phase.c(121) 
axis2_handler_t *addressing_based_dispatcher added to the index 1 of 
the phase Transport


How fixed its?

With respect, Andriy.




--
__

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: REST URL Mapping - The changes done in pattern matching Algorithm

[Damitha Kumarage]

Thiago Rafael Becker wrote:

Hi, all

I was looking at the recursive functions and below are my findings.

In the case of axis2_core_utils_internal_build_rest_map_recursively,
which is a tail-recursive function, seems easy to convert it to a
iterative function.

In the case of axis2_core_utils_internal_infer_op_from_rest_map_recursively,
which is not a tail-recursive function, seems harder to do. Also, it
spans for about 250 lines, it's complicated to find how to convert it.
Did you ever thought about switching from ansi c to iso99 c? You can
do some things to reduce the line span of functions (static inline
functions) that you can't do with ansi c. What do you think about it?
  

How about portability if we adopt C99?
thanks
Damitha

--
______

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: REST URL Mapping - The changes done in pattern matching Algorithm

[Damitha Kumarage]

  
 
op_desc (NULL)
  
  
|
 

consts_map (empty hash)
  
 
 |
 

params_map (hash)
  
  
  |
  
 
 "{subject_id}" --- axutil_core_utils_map_internal_t

(instance)
  
 
  |
 
 
op_desc (axis2_op_t* for "GET

students/{student_id}/marks/{subject_id}" op)
  
|
   
consts_map / params_map (Both NULL)
  




So at the Dispatching URL we can clearly sort out the operation
and the parameter values.

For matching patterns like {student_id}, {subject_id} and more
complex matching like xx{p}yy{q}zz{r} the logic uses the function
axis2_core_utils_match_url_component_with_pattern ( in
src/core/util/core_utils.c)
This is O(n^2) order (in worse case) algorithm.

And what I want to discuss is the point whether the above
described logic is better than the early logic which sequentilly
checks all the mapping.

Calculating the approximate time complexity takng n =numbe of
operations, p =  average URL mapping length
The early logic  = n/2 (<--go through all the operation in
average)  * O(p^2) (<--the complexity of
axis2_core_utils_match_url_component_with_pattern) =>O (n*p^2)

For the second logic it is really complex to do a methematical
analysis of the tiime complexity. Assuming (being optimistic:)
average length of the url component is d (d <= p) and the average
parameters in a url is k (k <=p/d) and taking hash search is O(1)

The new logic = log(n) (<-- long n number of hash search)
*(k*O(d^2)) (<-- assuming k parameters have to execute the
function axis2_core_utils_match_url_component_with_pattern)  =>
O(logn * k* d^2)

Clearly O(logn *k *d ^2)  < O(n*p^2)   (taking logn < n and d <=p
and k <=p/d)

Anyway the new logic contain some recursive functions and hash
functions heavily which may slow down things at little n (number
of operations), littld k (little number of url components) and
little d (small length urls).

So my question is do we need to favor on the smal number of
operation so go back to old logic(after correcting bugs) or do we
stay with the current logic?. Your opinions?



-- 
Thanks,

Dimuthu Gamage

http://www.dimuthu.org
http://www.wso2.org




--
Thanks,
Dimuthu Gamage

http://www.dimuthu.org
http://www.wso2.org



--
__

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: checking if axis server has started

[Damitha Kumarage]

Hi,

[EMAIL PROTECTED] wrote:

Hi!
Is there a way to check if axis server has started?
  
You can always do that by checking the return status. If this does not 
help please send what you have tried to see whether I can be of any help

thanks
Damitha

I have two threads, one initiates the axis server and gets stuck which
also makes the main thread to stop. I would like to somehow check if the
server has started and then let the main thread know so it can continue
running.

Regards
Indra


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  



--
__

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1286) Improve the logging facilities to let the client specify their own logging mechanism

[Damitha Kumarage (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12646518#action_12646518
 ] 

Damitha Kumarage commented on AXIS2C-1286:
--

However my small change to your patch wont' change the idea. If you provide the 
log structure and implement your own write function then whether critical log 
message is always written or not is under your control.

> Improve the logging facilities to let the client specify their own logging 
> mechanism
> 
>
> Key: AXIS2C-1286
> URL: https://issues.apache.org/jira/browse/AXIS2C-1286
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: util
>Affects Versions: 1.5.0
>Reporter: Dmitry Goncharov
> Attachments: axis2_log.patch, axis2_log_test.patch
>
>
> The current logging mechanism implemented in util/src/log.c makes the client 
> to provide a file for the library to output logging info to.
> This mechnism can be improved in such a way the the client can provide their 
> own struct axutil_log_t.
> By the means of a custom axutil_log_t the client can make the library do the 
> logging the way the client needs.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (AXIS2C-1286) Improve the logging facilities to let the client specify their own logging mechanism

[Damitha Kumarage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damitha Kumarage resolved AXIS2C-1286.
--

Resolution: Fixed

Patch applied. Thanks Dmitry for the patch. I have done only small change. That 
is, write the critical log messages to the log if the log is enabled 
irrespective of the log level set.

> Improve the logging facilities to let the client specify their own logging 
> mechanism
> 
>
> Key: AXIS2C-1286
> URL: https://issues.apache.org/jira/browse/AXIS2C-1286
> Project: Axis2-C
>  Issue Type: Improvement
>  Components: util
>Affects Versions: 1.5.0
>Reporter: Dmitry Goncharov
> Attachments: axis2_log.patch, axis2_log_test.patch
>
>
> The current logging mechanism implemented in util/src/log.c makes the client 
> to provide a file for the library to output logging info to.
> This mechnism can be improved in such a way the the client can provide their 
> own struct axutil_log_t.
> By the means of a custom axutil_log_t the client can make the library do the 
> logging the way the client needs.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (AXIS2C-1284) Savan/C build fails when --enable-filtering=no

[Damitha Kumarage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damitha Kumarage resolved AXIS2C-1284.
--

Resolution: Fixed

This is fixed now


> Savan/C build fails when --enable-filtering=no
> --
>
> Key: AXIS2C-1284
> URL: https://issues.apache.org/jira/browse/AXIS2C-1284
> Project: Axis2-C
>  Issue Type: Bug
>  Components: build system (Unix/Linux)
>Affects Versions: Current (Nightly)
>Reporter: Sanjaya Ratnaweera
> Fix For: Current (Nightly)
>
>
> Savan/C build fails with the configure option --enable-filtering=no. The 
> variable "filtered_payload" declared and initialized only if filtering 
> enabled, but it used even filtering is disabled. Here's the error message. 
> -g -O2 -D_LARGEFILE64_SOURCE -ansi -Wall -Wno-implicit-function-declaration 
> -MT savan_subscriber.lo -MD -MP -MF .deps/savan_subscriber.Tpo -c 
> savan_subscriber.c  -fPIC -DPIC -o .libs/savan_subscriber.o
> savan_subscriber.c: In function 'savan_subscriber_publish':
> savan_subscriber.c:431: error: 'filtered_payload' undeclared (first use in 
> this function)
> savan_subscriber.c:431: error: (Each undeclared identifier is reported only 
> once
> savan_subscriber.c:431: error: for each function it appears in.)
> savan_subscriber.c:385: warning: unused variable 'is_filtered'
> make: *** [savan_subscriber.lo] Error 1

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: changes to the axutil log functions

[Damitha Kumarage]

HI Dmitry,
   I am interested in  reviewing the patch you mentioned on axutil log. 
Please send it as an jira attachment.

thanks,
Damitha
Dmitry Goncharov wrote:

Hi,

You can make axis to do logging the way you need w/o making changes in 
the axis code.
Have a look at util/src/log.c. Function 
axutil_log_impl_write_to_file() is used to do logging.
All you need to do is to make your own shared library with only one 
function: axutil_log_impl_write_to_file().

The function has to have the same signature as the one in util/src/log.c.
Then use LD_PRELOAD to preload this new library when starting you 
application.
That's it. The axis code will invoke you implementation of 
axutil_log_impl_write_to_file().



Your proposed fix to pass a FILE* instead of a filename has the same 
restrictions as the current code. It makes the client do logging the 
way library wants.
The library already provides the interface to do logging the way the 
client needs.
You can  allocate an instance of axutil_log_t and set ops.free and 
ops.write to your own functions.
The you can replace the log object in your env struct with your 
customized log object.

Unfortunately, axis doesn't use ops.write.
The correct fix would be to change util/src/log.c to use ops.write() 
and ops.free().
I considered providing a patch, but finally decided not to (because 
the library maintainers dont seem to be willing to apply patches) and 
used the LD_PRELOAD method described above.


BR, Dmitry


Haszlakiewicz, Eric wrote:

I have a need to use axis within an existing system that has it's own
ways of opening/closing/rotating logs and I've found the existing axis
log interfaces to be a bit lacking.  I have some patches, but before I
submit a issue in jira I wanted to run the changes past some people to
see if what I'm doing makes sense.

There are two issues that I'm fixing:
  1) the log functions don't keep track of whether the filedescriptor
was opened by axis, so if you create a env using axutil_env_create() it
ends up closing stderr when you try to set a new log file.

  2) There's no way to tell axis to log to a filedescriptor rather than
to a named file.

I added two functions to axutil_log_default.h:

One to create a axutil_log_t using an existing FILE * as returned from
fopen:
AXIS2_EXTERN axutil_log_t *AXIS2_CALL
axutil_log_create_fp(
axutil_allocator_t *allocator,
axutil_log_ops_t *ops,
void *stream,
int close_stream);
I also factored out a static axutil_log_create_common() function, which
is used by both axutil_log_create_fp() and the original
axutil_log_create().

And, one to switch the FILE pointer on an existing log structure:
AXIS2_EXTERN void AXIS2_CALL
axutil_log_set_stream(
axutil_allocator_t *allocator,
axutil_log_t *log,
void *stream,
int close_stream);

In both of these, the close_stream flag indicates whether axis is
allowed to close the stream when a new one is set or when the log
structure is cleaned up.  That is stored in a new field in the
axutil_log_impl structure.

Does this seem reasonable?  Should I send the full patch to the list?

eric

(btw, I created a couple of other jira issues (AXIS2C-1271, AXIS2C-1280)
w/ patches attached.  About how long can I expect before they are
applied?)

-
To unsubscribe, e-mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>

  



--
______

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Help needed with Axiom Navigator

[Damitha Kumarage]

Hi,
Shivam must be referring to include/axiom_navigator.h. Does this api 
supposed to provide Axiom/Java like navigation functionality?. If it is 
not working and if we don't need the use of it let's remove it from code 
base so as to avoid confusion.


thanks
Damitha.
Nandika Jayawardana wrote:
As you said, axiom_navigator is not used in the rest of the code. I 
think it is best to use the methods in axiom_node.h and the iterators 
available in axiom, if your want to traverse an axiom tree.
 
Regards

Nandika
 

 
On Thu, Nov 6, 2008 at 11:52 AM, Gupta, Shivam <[EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]>> wrote:


Hi,
 
   I have an issue where I need to use the Axiom Navigator class

in Axis2/C. I have read the Axiom Tutorial but still am not very
comfortable using the Navigator. I also found that the Axis2/C
does not use the same anywhere in the project.
 
   So if someone could give me some sample code that may guide me

in how to use this class to travesrse an Om node in a C program
would really be useful.
 
Thanks,

Shivam.




--
______

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (AXIS2C-1277) Must use empty header in request

[Damitha Kumarage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damitha Kumarage updated AXIS2C-1277:
-

Attachment: get_version
version_client.zip
version_service.zip

I could not reproduce the problem. When I run the attached version sample 
client and service it works fine. Attached also is the tcpmon messages. Make 
sure that your Axis2/C code have the patch applied.

> Must use empty header in request
> 
>
> Key: AXIS2C-1277
> URL: https://issues.apache.org/jira/browse/AXIS2C-1277
> Project: Axis2-C
>  Issue Type: Bug
>Reporter: Ruth Struck
> Attachments: get_version, screenshot-1.jpg, soap_header.c.diff, 
> version_client.zip, version_service.zip
>
>
> Why must an empty  element be included in the SOAP request in order 
> to use axis? I have two implementations of a web service, one is gsoap and 
> the other is Axis2C - both have the same SOAP request - the gsoap 
> implementation does not require the empty header element in the request, the 
> Axis2C service does. How can I get around that requirement?
> The SOAP request:
> http://schemas.xmlsoap.org/soap/envelope/"; 
> xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"; 
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
> xmlns:ns1="http://localhost:80/axisae/aewebservices71.wsdl";>
> 
> 
> 
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (AXIS2C-1277) Must use empty header in request

[Damitha Kumarage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damitha Kumarage updated AXIS2C-1277:
-

Attachment: soap_header.c.diff

File attached has the desired solution. If there is no soap headers to be added 
then serialized envelope don't have a empty soap header. In the server side 
also it correctly handles when there is no soap header elemen present.
Can someone who is more familier with Axiom review this patch?

> Must use empty header in request
> 
>
> Key: AXIS2C-1277
> URL: https://issues.apache.org/jira/browse/AXIS2C-1277
> Project: Axis2-C
>  Issue Type: Bug
>Reporter: Ruth Struck
> Attachments: soap_header.c.diff
>
>
> Why must an empty  element be included in the SOAP request in order 
> to use axis? I have two implementations of a web service, one is gsoap and 
> the other is Axis2C - both have the same SOAP request - the gsoap 
> implementation does not require the empty header element in the request, the 
> Axis2C service does. How can I get around that requirement?
> The SOAP request:
> http://schemas.xmlsoap.org/soap/envelope/"; 
> xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"; 
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
> xmlns:ns1="http://localhost:80/axisae/aewebservices71.wsdl";>
> 
> 
> 
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (AXIS2C-1279) A soap fault of "No Error" return

[Damitha Kumarage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damitha Kumarage updated AXIS2C-1279:
-

Description: 
A soap fault with reason "No Error" return for certain errors at server side. 
The reason is that some times failures happen at server side but error code is 
not set for these. When at later times code see the status failure and call 
axutil_error_get_message() then it give the wrong message "No Error".
To avoid this there are two solutions
1. Whenever there is an error make sure to call set_error_code(). Fix this in 
the current code.
2. Avoid using axutil_eror_get_message() function. 

Ideally the solution should be the first one. Two is only a temporary hack.

  was:A soap fault with reason "No Error" return when a request without soap 
header is sent. In addition server seg faults.


> A soap fault of "No Error" return
> -
>
> Key: AXIS2C-1279
> URL: https://issues.apache.org/jira/browse/AXIS2C-1279
> Project: Axis2-C
>  Issue Type: Bug
>Reporter: Damitha Kumarage
>
> A soap fault with reason "No Error" return for certain errors at server side. 
> The reason is that some times failures happen at server side but error code 
> is not set for these. When at later times code see the status failure and 
> call axutil_error_get_message() then it give the wrong message "No Error".
> To avoid this there are two solutions
> 1. Whenever there is an error make sure to call set_error_code(). Fix this in 
> the current code.
> 2. Avoid using axutil_eror_get_message() function. 
> Ideally the solution should be the first one. Two is only a temporary hack.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (AXIS2C-1279) A soap fault of "No Error" return

[Damitha Kumarage (JIRA)]

A soap fault of "No Error" return
-

 Key: AXIS2C-1279
 URL: https://issues.apache.org/jira/browse/AXIS2C-1279
 Project: Axis2-C
  Issue Type: Bug
Reporter: Damitha Kumarage


A soap fault with reason "No Error" return when a request without soap header 
is sent. In addition server seg faults.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1277) Must use empty header in request

[Damitha Kumarage (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12641736#action_12641736
 ] 

Damitha Kumarage commented on AXIS2C-1277:
--

I could reproduce this. Will fix asap

> Must use empty header in request
> 
>
> Key: AXIS2C-1277
> URL: https://issues.apache.org/jira/browse/AXIS2C-1277
> Project: Axis2-C
>  Issue Type: Bug
>Reporter: Ruth Struck
>
> Why must an empty  element be included in the SOAP request in order 
> to use axis? I have two implementations of a web service, one is gsoap and 
> the other is Axis2C - both have the same SOAP request - the gsoap 
> implementation does not require the empty header element in the request, the 
> Axis2C service does. How can I get around that requirement?
> The SOAP request:
> http://schemas.xmlsoap.org/soap/envelope/"; 
> xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"; 
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
> xmlns:ns1="http://localhost:80/axisae/aewebservices71.wsdl";>
> 
> 
> 
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Properties in Configuration Context

[Damitha Kumarage]

Hi Danushka,
We could easily wrap the  base context functions in conf_ctx, op_ctx, 
svc_ctx, svc_grp_ctx and msg_ctx. But this considerbly increase the 
lines of code. As I remember this was the main reason for not doing it 
previously. However I also agree that it is nice to have these wrapper 
functions in main contexts.


Thanks,
Damitha

Danushka Menikkumbura wrote:

Hi Devs,
   We have been using the base context of conf_ctx to keep custom 
properties. What we normally do is, get the base context and use its 
(axis2_ctx) API to set/get properties. And we use external mutexes for 
synchronization. Why don't we have get/set calls in conf_ctx API 
itself so that we can set/get properties without any hassle. And that 
way we can use the mutex in conf_ctx to handle synchronization. I 
think that is the cleaner way of accessing the base.


Any thoughts?

Danushka

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
______

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (AXIS2C-1274) Savan/C seg faults when run with Apache2

[Damitha Kumarage (JIRA)]

Savan/C seg faults when run with Apache2


 Key: AXIS2C-1274
 URL: https://issues.apache.org/jira/browse/AXIS2C-1274
 Project: Axis2-C
  Issue Type: Bug
Reporter: Damitha Kumarage


When running with Apache2 following seg fault occurs with following

#0  0xb7f52410 in __kernel_vsyscall ()
#1  0xb7d18085 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7d19a01 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0xb7d50b7c in ?? () from /lib/tls/i686/cmov/libc.so.6
#4  0xb7d5c61b in free () from /lib/tls/i686/cmov/libc.so.6
#5  0xb795d5d2 in savan_util_apply_filter (subscriber=0x82b2e20, env=0xe, 
payload=0x82a21f0) at savan_util.c:256
#6  0xb795aeb1 in savan_subscriber_publish (subscriber=0x82b2e20, 
env=0x82a1908, payload=0x82a21f0)
at savan_subscriber.c:425
#7  0xb795a6ce in savan_publishing_client_publish (client=0x82a2188, 
env=0x82a1908, payload=0x82a21f0)
at savan_publishing_client.c:178
#8  0xb7b0f03e in publisher_worker_func (thrd=0x82a18e0, data=0x82a18d8) at 
publisher_skeleton.c:258
#9  0xb7c431b6 in dummy_worker (opaque=0x82a18e0) at thread_unix.c:93
#10 0xb7e454fb in start_thread () from /lib/tls/i686/cmov/libpthread.so.0
#11 0xb7dc3e5e in clone () from /lib/tls/i686/cmov/libc.so.6

Valgrind shows

 Thread 2:
==13943== Invalid free() / delete / delete[]
==13943==at 0x402265C: free (vg_replace_malloc.c:323)
==13943==by 0x49CC5D1: savan_util_apply_filter (savan_util.c:256)
==13943==by 0x49C9EB0: savan_subscriber_publish (savan_subscriber.c:425)
==13943==by 0x49C96CD: savan_publishing_client_publish 
(savan_publishing_client.c:178)
==13943==by 0x486703D: publisher_worker_func (publisher_skeleton.c:258)
==13943==by 0x47481B5: dummy_worker (thread_unix.c:93)
==13943==by 0x41244FA: start_thread (in 
/lib/tls/i686/cmov/libpthread-2.7.so)
==13943==by 0x4211E5D: clone (in /lib/tls/i686/cmov/libc-2.7.so)
==13943==  Address 0x45d6668 is 17,464 bytes inside a block of size 20,480 
alloc'd
==13943==at 0x4022AB8: malloc (vg_replace_malloc.c:207)
==13943==by 0x40D05FD: allocator_alloc (apr_pools.c:323)
==13943==by 0x40D0A26: apr_palloc (apr_pools.c:653)
==13943==by 0x4692A08: axis2_module_malloc (mod_axis2.c:389)
==13943==by 0x4029204: guththila_buffer_init (guththila_buffer.c:37)
==13943==by 0x40317AD: guththila_create_xml_stream_writer_for_memory 
(guththila_xml_writer.c:185)
==13943==by 0x476BFB9: axiom_xml_writer_create_for_memory 
(guththila_xml_writer_wrapper.c:311)
==13943==by 0x4711C45: axiom_node_to_string (om_node.c:1200)
==13943==by 0x49CC4BF: savan_util_apply_filter (savan_util.c:210)
==13943==by 0x49C9EB0: savan_subscriber_publish (savan_subscriber.c:425)
==13943==by 0x49C96CD: savan_publishing_client_publish 
(savan_publishing_client.c:178)
==13943==by 0x486703D: publisher_worker_func (publisher_skeleton.c:258)



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (AXIS2C-1273) In Savan/C filter template path is hard coded in to the code.

[Damitha Kumarage (JIRA)]

In Savan/C filter template path is hard coded in to the code.
-

 Key: AXIS2C-1273
 URL: https://issues.apache.org/jira/browse/AXIS2C-1273
 Project: Axis2-C
  Issue Type: Bug
Reporter: Damitha Kumarage


To avoid the $subect I plan to add a module parameter called 
savan_filter_template_path which has the filter template path as parameter value

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ver 1.6

[Damitha Kumarage]

+1 for Manjula
thanks
Damitha

Manjula Peiris wrote:

On Mon, 2008-10-13 at 09:10 +0530, Samisa Abeysinghe wrote:
  

Any volunteers to play 1.6 release manager role?



I would like to be the release manager for 1.6

-Manjula.

  

Samisa...

Samisa Abeysinghe wrote:


If we can have Xpath and CGI, then we might go for 1.6.

I also had a look into the Jira, and looks like we have 87 open 
issues. We might also want to fix some of these also, before the release.


Thanks,
Samisa...

Dumindu Pallewela wrote:
  

Hi,

I have started on the XPath integration. I sent a separate email 
regarding that. It will take some time to get it properly tested.


Regards,
Dumindu.

On Wed, Oct 8, 2008 at 5:24 PM, Samisa Abeysinghe <[EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]>> wrote:


Uthaiyashankar wrote:

Nandika Jayawardana wrote:

The code developed under for the two GSOC projects are
also there.


XPath support is still not integrated. We have to integrate
and test it. We are currently working on that. I think, it
will take some time.


The other one was CGI, is that complete as well?

Thanks,
Samisa...


Regards,
Shankar.

 Thanks
Nandika

On Wed, Oct 8, 2008 at 3:25 PM, Manjula Peiris
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote:


   On Wed, 2008-10-08 at 14:11 +0530, Samisa Abeysinghe 
wrote:

   > Subra Aswathanarayanan wrote:
   > > Hello,
   > >
   > > Do you guys know when you are going to release
Axis2/C ver 1.6?
   >
   > We have not got any major features to be released as
1.6 right
   now. In
   > fact, the developer community has not discussed any
plans for
   post 1.5
   > releases as of now. May be it should be 1.5.1.
<http://1.5.1.> <http://1.5.1./>

   We have MTOM caching support. This enhanced the
functionality of
   MTOM to
   send very large attachments with a very low memory usage.


   >
   > Devs, any thoughts...
   >
   > Thanks,
   > Samisa...
   >


  
-

   To unsubscribe, e-mail:
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
   <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
   For additional commands, e-mail:
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
   <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>




-- http://nandikajayawardana.blogspot.com/
WSO2 Inc: http://www.wso2.com








No virus found in this incoming message.
Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus
Database: 270.7.6/1714 - Release Date: 10/8/2008 7:01 AM





-- Samisa Abeysinghe Director, Engineering; WSO2 Inc.

http://www.wso2.com/ - "The Open Source SOA Company"



-

To unsubscribe, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>

For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>




--
Dumindu Pallewela
Cinergix - "Share, Reuse, Innovate"
cinergix.com <http://cinergix.com>



No virus found in this incoming message.
Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus 
Database: 270.7.6/1714 - Release Date: 10/8/2008 7:01 AM


  





No virus found in this incoming message.
Checked by AVG - http://www.avg.com 
Version: 8.0.173 / Virus Database: 270.7.6/1714 - Release Date: 10/8/2008 7:01 AM


  
  




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  



--
__

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ver 1.6

[Damitha Kumarage]

Hi,
Sandesha2/C and Savan/C depend on some fixes in Axis2/C which are done 
after 1.5.

I'm +1 for a 1.5.1 with these fixes.
thanks,
Damitha


Nandika Jayawardana wrote:



On Wed, Oct 8, 2008 at 4:49 PM, Samisa Abeysinghe <[EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]>> wrote:


Nandika Jayawardana wrote:

The code developed under for the two GSOC projects are also there.


But AFAIK, they are yet to be integrated and tested.

 
Yes, they need to be tested.
 
Thanks

Nandika



Thanks,
Samisa...

 Thanks
Nandika


On Wed, Oct 8, 2008 at 3:25 PM, Manjula Peiris
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote:


   On Wed, 2008-10-08 at 14:11 +0530, Samisa Abeysinghe wrote:
   > Subra Aswathanarayanan wrote:
   > > Hello,
   > >
   > > Do you guys know when you are going to release Axis2/C
ver 1.6?
   >
   > We have not got any major features to be released as 1.6
right
   now. In
   > fact, the developer community has not discussed any plans for
   post 1.5
   > releases as of now. May be it should be 1.5.1.
<http://1.5.1./> <http://1.5.1./>


   We have MTOM caching support. This enhanced the
functionality of
   MTOM to
   send very large attachments with a very low memory usage.


   >
   > Devs, any thoughts...
   >
   > Thanks,
   > Samisa...
   >


 
 -

   To unsubscribe, e-mail:
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
   <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>

   For additional commands, e-mail:
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
   <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>





-- 
http://nandikajayawardana.blogspot.com/

WSO2 Inc: http://www.wso2.com <http://www.wso2.com/>



No virus found in this incoming message.
Checked by AVG - http://www.avg.com <http://www.avg.com/>
Version: 8.0.173 / Virus Database: 270.7.6/1713 - Release
Date: 10/7/2008 6:40 PM

 




-- 
Samisa Abeysinghe Director, Engineering; WSO2 Inc.


http://www.wso2.com/ - "The Open Source SOA Company"


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
    For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>





--
__

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ver 1.6

[Damitha Kumarage]

Hi,
Sandesha2/C and Savan/C depend on some fixes in Axis2/C which are done 
after 1.5.

I'm +1 for a 1.5.1 with these fixes.
thanks,
Damitha
Samisa Abeysinghe wrote:

If we can have Xpath and CGI, then we might go for 1.6.

I also had a look into the Jira, and looks like we have 87 open 
issues. We might also want to fix some of these also, before the release.


Thanks,
Samisa...

Dumindu Pallewela wrote:

Hi,

I have started on the XPath integration. I sent a separate email 
regarding that. It will take some time to get it properly tested.


Regards,
Dumindu.

On Wed, Oct 8, 2008 at 5:24 PM, Samisa Abeysinghe <[EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]>> wrote:


Uthaiyashankar wrote:

Nandika Jayawardana wrote:

The code developed under for the two GSOC projects are
also there.


XPath support is still not integrated. We have to integrate
and test it. We are currently working on that. I think, it
will take some time.


The other one was CGI, is that complete as well?

Thanks,
Samisa...


Regards,
Shankar.

 Thanks
Nandika

On Wed, Oct 8, 2008 at 3:25 PM, Manjula Peiris
<[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
<mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote:


   On Wed, 2008-10-08 at 14:11 +0530, Samisa Abeysinghe 
wrote:

   > Subra Aswathanarayanan wrote:
   > > Hello,
   > >
   > > Do you guys know when you are going to release
Axis2/C ver 1.6?
   >
   > We have not got any major features to be released as
1.6 right
   now. In
   > fact, the developer community has not discussed any
plans for
   post 1.5
   > releases as of now. May be it should be 1.5.1.
<http://1.5.1.> <http://1.5.1./>

   We have MTOM caching support. This enhanced the
functionality of
   MTOM to
   send very large attachments with a very low memory usage.


   >
   > Devs, any thoughts...
   >
   > Thanks,
   > Samisa...
   >


  
-

   To unsubscribe, e-mail:
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
   <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
   For additional commands, e-mail:
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
   <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>




-- http://nandikajayawardana.blogspot.com/
WSO2 Inc: http://www.wso2.com








No virus found in this incoming message.
Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus
Database: 270.7.6/1714 - Release Date: 10/8/2008 7:01 AM





-- Samisa Abeysinghe Director, Engineering; WSO2 Inc.

http://www.wso2.com/ - "The Open Source SOA Company"



-

To unsubscribe, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>

For additional commands, e-mail: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>




--
Dumindu Pallewela
Cinergix - "Share, Reuse, Innovate"
cinergix.com <http://cinergix.com>



No virus found in this incoming message.
Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus 
Database: 270.7.6/1714 - Release Date: 10/8/2008 7:01 AM


  






--
__

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Memory fault in Axis2C

[Damitha Kumarage]

Hi Shivam,
Are you running simple axis2c server or running axis2 apache module in 
Apache2?.  I am asking this because the code line

*axutil_allocator_switch_to_local_pool(env->allocator);
*
has meaning when only running as an Apache2 module. If you are running 
in Apache2 please run in simple axis2 server and tell us what happen. 
Also make sure to run your server with trace enabled (Build axis2/C with 
trace enabled and run server with option -l6) and send us the resulting 
server log file.


thanks,
Damitha

Gupta, Shivam wrote:

Hello,
 
   We are trying to run Axis on Unix platform. However, when we try to 
invoke the 'echo' webservice, the Axis server crashes giving a memory 
fault. In the mail below I have explained the findings I derived after 
debugging Axis2c:
 
1). I had built the libecho.so file using the following files : 
echo.c, echo.h and echo_skeleton.c
 
2). The Axis2 Log clearly states that the "libecho.so loaded 
successfully".
 
3). The processing of the request proceeds till the statement : 


File: /msg_recv.c/

Function: /axis2_msg_recv_make_new_svc_obj Code Lines:/

* if (impl_class) *

* { *

* AXIS2_SVC_SKELETON_INIT((axis2_svc_skeleton_t *) impl_class, env); } 
axutil_allocator_switch_to_local_pool(env->allocator); *


*4). *the Code exits and the Axis server crashes. I have also made 
sure that the functions are built inside the libecho.so file. It is 
not an empty linkable.


Please help me out here. I am not able to figure out waht is going 
wrong here.


Regards,

Shivam.

 

 

* * 




--
______

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

CGI Makefile.am is missing

[Damitha Kumarage]

Hi,
src/core/transport/http/server/CGI/Makefile
entry is added to main configure.ac but apprarently whoever put that 
entry has forgotten to commit the corresponding Makefile.am. This cause 
automake failure


thanks
Damitha
--
__

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (AXIS2C-1261) When several fire and forget sends are done using svc client it segfaults

[Damitha Kumarage (JIRA)]

When several fire and forget sends are done using svc client it segfaults
-

 Key: AXIS2C-1261
 URL: https://issues.apache.org/jira/browse/AXIS2C-1261
 Project: Axis2-C
  Issue Type: Bug
Reporter: Damitha Kumarage


$Subject happens because in operation client the sending is done using separate 
thread. Before the first request completes it could happen that the second 
request free the operation client that is used to send the first message.

When operation client execute is called from services clients fire and forget 
function it set send blokcing to true. When I fixed this to false the above 
segfaut and the problem causing it dissapear. This is because no more thread 
are spawned and sends are done sequentially.

Following the diff of my simple fix. If there is no objection I will commit the 
change

Index: src/core/clientapi/svc_client.c
===
--- src/core/clientapi/svc_client.c (revision 693316)
+++ src/core/clientapi/svc_client.c (working copy)
@@ -663,7 +663,7 @@
 }

 axis2_op_client_add_out_msg_ctx(svc_client->op_client, env, msg_ctx);
-axis2_op_client_execute(svc_client->op_client, env, AXIS2_FALSE);
+axis2_op_client_execute(svc_client->op_client, env, AXIS2_TRUE);
 axis2_svc_client_set_http_info(svc_client, env, msg_ctx);
 svc_client->auth_failed = axis2_msg_ctx_get_auth_failed(msg_ctx, env);
 svc_client->required_auth_is_http =

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Service client options to set custom HTTP headers

[Damitha Kumarage]

Oh I got it all wrong. I had soap headers in mind.

thanks
Damitha
Manjula Peiris wrote:

On Sat, 2008-08-30 at 22:20 +0530, Damitha Kumarage wrote:
  

Hatim Daginawala wrote:


At what point will these headers get freed and who will be responsible
for freeing them?

Currently, I add http headers right before axis2_svc_client_send_receive
and free them right after axis2_svc_client_send_receive
  
  
Currently headers are added into a array list as axiom nodes. When these 
headers are added into the main header node they are removed from the 
array list. When envelope is freed these headers nodes are get freed(Am 
I right here?) . So why you need to free them from your client?.



I think Hatim is talking about http_headers. They are not added as
axiom_nodes.


  

Even the array list is get freed in svc_client_free function.
thanks,
Damitha


Thanks

-Original Message-
From: Danushka Menikkumbura [mailto:[EMAIL PROTECTED] 
Sent: Friday, August 29, 2008 9:49 AM

To: Apache AXIS C Developers List
Subject: Re: Service client options to set custom HTTP headers


  
  

But then the user need to create axis2_http_header_t instances. Can we


  
  
use an string key value pair and covert them to the header type 
internally?





No he doesn't have to. The interface call accepts the name and the value

and it in turn creates the header instance.

The interface call :
axis2_options_add_custom_http_header(
axis2_options_t*options,
const axutil_env_t*env,
const axis2_char_t*name,
const axis2_char_t*value);

Danushka

  
  




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  



--
______

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Service client options to set custom HTTP headers

[Damitha Kumarage]

Hatim Daginawala wrote:

At what point will these headers get freed and who will be responsible
for freeing them?

Currently, I add http headers right before axis2_svc_client_send_receive
and free them right after axis2_svc_client_send_receive
  
Currently headers are added into a array list as axiom nodes. When these 
headers are added into the main header node they are removed from the 
array list. When envelope is freed these headers nodes are get freed(Am 
I right here?) . So why you need to free them from your client?.


Even the array list is get freed in svc_client_free function.
thanks,
Damitha

Thanks

-Original Message-
From: Danushka Menikkumbura [mailto:[EMAIL PROTECTED] 
Sent: Friday, August 29, 2008 9:49 AM

To: Apache AXIS C Developers List
Subject: Re: Service client options to set custom HTTP headers


  

But then the user need to create axis2_http_header_t instances. Can we



  
use an string key value pair and covert them to the header type 
internally?




No he doesn't have to. The interface call accepts the name and the value

and it in turn creates the header instance.

The interface call :
axis2_options_add_custom_http_header(
axis2_options_t*options,
const axutil_env_t*env,
const axis2_char_t*name,
const axis2_char_t*value);

Danushka

  



--
______

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Service client options to set custom HTTP headers

[Damitha Kumarage]

Hi Danushka,

override options come into play when we reuse operation client. Say 
after sending some application messages you need to override some 
options. Then you create new options struct and called svc client's 
set_override_options. What happens is that existing options struct 
becomes parent and your override options become operations clients' 
options struct.


However I have never used this functionality.

thanks
Damitha
Danushka Menikkumbura wrote:


If you need more control you can directly use operation client 
bypassing service client. Then you can be smarter :)
It is imperative that I use the service client. So, it is not possible 
to talk to operation client directly. :)


The other issue that was found when I was going through the 
/axis2_svc_client_create_op_client /method is that there is a 
possibility of the operation client options being overridden by 
/override_options/. Could you please explain the impact of this on 
using the service client options to pass data to operation client? 
What is the purpose if overriding operation client options and how 
often is it used?


Danushka




--
______

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1254) Information set by the Client options axis2_options_set_transport_info function is not used

[Damitha Kumarage (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626893#action_12626893
 ] 

Damitha Kumarage commented on AXIS2C-1254:
--

I had a look at your patch. Is not it better first try to infer transport from 
url and if it fails then look for client options?. In that way if client do any 
mistake by providing mismatching transport option and url we can avoid 
consequences easily.

> Information set by the Client options axis2_options_set_transport_info 
> function is not used
> ---
>
> Key: AXIS2C-1254
> URL: https://issues.apache.org/jira/browse/AXIS2C-1254
> Project: Axis2-C
>  Issue Type: Bug
>Reporter: Supun Kamburugamuva
>Assignee: Supun Kamburugamuva
> Attachments: axis2c-1254.patch
>
>
> axis2_options_set_transport_info function allows the client to set the 
> transport for sending and receiving messages. But at the moment Axis2/C 
> ignores this information and always try to use the TO url for inferring the 
> transport which is not possible in all the cases.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Service client options to set custom HTTP headers

[Damitha Kumarage]

Danushka Menikkumbura wrote:

Hi Devs,
   There is a requirement to have support for custom HTTP headers in 
Axis2/C. To do that we need to let the operation client know the 
header details. One options is to set headers in service client 
options and pass them on to operation client as the operation client 
uses the service client options. This is how we pass things like soap 
action and various addressing parameters to operation client at the 
moment.
   Can we make it smarter than that?. And do you see any hidden 
pitfalls in it?
If you need more control you can directly use operation client bypassing 
service client. Then you can be smarter :)


thanks
Damitha


Danushka




--
__

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Sending and receiving separate messages from a module

[Damitha Kumarage]

You can use engine_send if you need to make your message go through all 
the phases. If not you can use transport_sender_invoke. Using svc_client 
from a handler is a overkill.


thanks
Damitha
Supun Kamburugamuva wrote:

Hi all,

I have a module which has a handler in the out flow. When a message is 
sent by a client, this module needs to send separate messages prior to 
sending the the original message. What is the best way to send these 
messages? Should I use the service client, operation client or any 
other means of sending a message through axis2/C?


Thanks,
Supun.
Software Engineer, WSO2 Inc



--
__

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to add a file to AXIS Makefile project

[Damitha Kumarage]

Hi Gupta,
Custom message receivers are loaded into the Axis2/C dynamically. What 
you need to do is build your receiver as a dynamically loadable module. 
You can refer to echo service's Makefile.am to see how to do that. If 
your dll name is libcustom_receiver.so. Then the class in the following 
code section is "custom_receiver" Once you have your receiver library 
ready you can put an entry into your service.xml  as






Also put your receiver dll into the Axis2/C repository's lib folder.

Now when requests for your_op endup hitting custom_receiver.
Hope this will help, If you still have problems send me your message 
receiver's Makefile.am


thanks,
Damitha


Gupta, Shivam wrote:

Hello,
 
   I am working with the AXIS2/C Makefile project. I have developed a 
custom message receiver and am trying to add it to the existing 
AXIS2/C Makefile project. But I have been unsuccessful till now. Could 
someone guide me as to how I may do this.
 
Regards,

Shivam.



--
__________

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (AXIS2C-1250) Memory leak in axiom_soap_header_remove_header_block() function

[Damitha Kumarage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damitha Kumarage closed AXIS2C-1250.


Resolution: Fixed

This is fixed now

> Memory leak in axiom_soap_header_remove_header_block() function
> ---
>
> Key: AXIS2C-1250
> URL: https://issues.apache.org/jira/browse/AXIS2C-1250
> Project: Axis2-C
>  Issue Type: Bug
> Environment: linux
>    Reporter: Damitha Kumarage
>Assignee: Damitha Kumarage
> Attachments: soap_header.tar.gz
>
>
> When axiom_soap_header_remove_header_block() function is called it cause 
> memory leak. The sample I used is attached herewith. Following is the leak 
> summary.
> ==31236== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 25 from 1)
> ==31236== malloc/free: in use at exit: 16 bytes in 1 blocks.
> ==31236== malloc/free: 195 allocs, 194 frees, 203,462 bytes allocated.
> ==31236== For counts of detected errors, rerun with: -v
> ==31236== searching for pointers to 1 not-freed blocks.
> ==31236== checked 126,060 bytes.
> ==31236== 
> ==31236== 16 bytes in 1 blocks are definitely lost in loss record 1 of 1
> ==31236==at 0x4023D6E: malloc (vg_replace_malloc.c:207)
> ==31236==by 0x40309DC: axutil_allocator_malloc_impl (allocator.c:75)
> ==31236==by 0x402FE75: axutil_hash_first (hash.c:161)
> ==31236==by 0x4065779: axiom_soap_header_remove_header_block 
> (soap_header.c:550)
> ==31236==by 0x80489BF: main (test.c:35)
> ==31236== 
> ==31236== LEAK SUMMARY:
> ==31236==definitely lost: 16 bytes in 1 blocks.
> ==31236==  possibly lost: 0 bytes in 0 blocks.
> ==31236==still reachable: 0 bytes in 0 blocks.
> ==31236== suppressed: 0 bytes in 0 blocks.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Assigned: (AXIS2C-1250) Memory leak in axiom_soap_header_remove_header_block() function

[Damitha Kumarage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damitha Kumarage reassigned AXIS2C-1250:


Assignee: Damitha Kumarage

> Memory leak in axiom_soap_header_remove_header_block() function
> ---
>
> Key: AXIS2C-1250
> URL: https://issues.apache.org/jira/browse/AXIS2C-1250
> Project: Axis2-C
>  Issue Type: Bug
> Environment: linux
>    Reporter: Damitha Kumarage
>Assignee: Damitha Kumarage
> Attachments: soap_header.tar.gz
>
>
> When axiom_soap_header_remove_header_block() function is called it cause 
> memory leak. The sample I used is attached herewith. Following is the leak 
> summary.
> ==31236== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 25 from 1)
> ==31236== malloc/free: in use at exit: 16 bytes in 1 blocks.
> ==31236== malloc/free: 195 allocs, 194 frees, 203,462 bytes allocated.
> ==31236== For counts of detected errors, rerun with: -v
> ==31236== searching for pointers to 1 not-freed blocks.
> ==31236== checked 126,060 bytes.
> ==31236== 
> ==31236== 16 bytes in 1 blocks are definitely lost in loss record 1 of 1
> ==31236==at 0x4023D6E: malloc (vg_replace_malloc.c:207)
> ==31236==by 0x40309DC: axutil_allocator_malloc_impl (allocator.c:75)
> ==31236==by 0x402FE75: axutil_hash_first (hash.c:161)
> ==31236==by 0x4065779: axiom_soap_header_remove_header_block 
> (soap_header.c:550)
> ==31236==by 0x80489BF: main (test.c:35)
> ==31236== 
> ==31236== LEAK SUMMARY:
> ==31236==definitely lost: 16 bytes in 1 blocks.
> ==31236==  possibly lost: 0 bytes in 0 blocks.
> ==31236==still reachable: 0 bytes in 0 blocks.
> ==31236== suppressed: 0 bytes in 0 blocks.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Closed: (AXIS2C-1249) Memory leak in notify client sample

[Damitha Kumarage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damitha Kumarage closed AXIS2C-1249.


Resolution: Fixed

This is fixed

> Memory leak in notify client sample
> ---
>
> Key: AXIS2C-1249
> URL: https://issues.apache.org/jira/browse/AXIS2C-1249
> Project: Axis2-C
>  Issue Type: Bug
>    Reporter: Damitha Kumarage
>    Assignee: Damitha Kumarage
>
> In current svn following memory leak is detected
> ==6296== 1,064 (268 direct, 796 indirect) bytes in 1 blocks are definitely 
> lost in loss record 6 of 6
> ==6296==at 0x4023D6E: malloc (vg_replace_malloc.c:207)
> ==6296==by 0x40309DC: axutil_allocator_malloc_impl (allocator.c:75)
> ==6296==by 0x40B99E5: axis2_msg_ctx_create (msg_ctx.c:232)
> ==6296==by 0x40BFAB9: axis2_op_client_two_way_send (op_client.c:1193)
> ==6296==by 0x40C12B0: axis2_op_client_execute (op_client.c:504)
> ==6296==by 0x40C37DC: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:593)
> ==6296==by 0x40C38E2: axis2_svc_client_send_robust (svc_client.c:618)
> ==6296==by 0x8048C83: main (notify_client.c:99)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Assigned: (AXIS2C-1249) Memory leak in notify client sample

[Damitha Kumarage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damitha Kumarage reassigned AXIS2C-1249:


Assignee: Damitha Kumarage

> Memory leak in notify client sample
> ---
>
> Key: AXIS2C-1249
> URL: https://issues.apache.org/jira/browse/AXIS2C-1249
> Project: Axis2-C
>  Issue Type: Bug
>    Reporter: Damitha Kumarage
>    Assignee: Damitha Kumarage
>
> In current svn following memory leak is detected
> ==6296== 1,064 (268 direct, 796 indirect) bytes in 1 blocks are definitely 
> lost in loss record 6 of 6
> ==6296==at 0x4023D6E: malloc (vg_replace_malloc.c:207)
> ==6296==by 0x40309DC: axutil_allocator_malloc_impl (allocator.c:75)
> ==6296==by 0x40B99E5: axis2_msg_ctx_create (msg_ctx.c:232)
> ==6296==by 0x40BFAB9: axis2_op_client_two_way_send (op_client.c:1193)
> ==6296==by 0x40C12B0: axis2_op_client_execute (op_client.c:504)
> ==6296==by 0x40C37DC: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:593)
> ==6296==by 0x40C38E2: axis2_svc_client_send_robust (svc_client.c:618)
> ==6296==by 0x8048C83: main (notify_client.c:99)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Updated: (AXIS2C-1250) Memory leak in axiom_soap_header_remove_header_block() function

[Damitha Kumarage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damitha Kumarage updated AXIS2C-1250:
-

Attachment: soap_header.tar.gz

Use this sample to reproduce the memory leak

> Memory leak in axiom_soap_header_remove_header_block() function
> ---
>
> Key: AXIS2C-1250
> URL: https://issues.apache.org/jira/browse/AXIS2C-1250
> Project: Axis2-C
>  Issue Type: Bug
> Environment: linux
>    Reporter: Damitha Kumarage
> Attachments: soap_header.tar.gz
>
>
> When axiom_soap_header_remove_header_block() function is called it cause 
> memory leak. The sample I used is attached herewith. Following is the leak 
> summary.
> ==31236== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 25 from 1)
> ==31236== malloc/free: in use at exit: 16 bytes in 1 blocks.
> ==31236== malloc/free: 195 allocs, 194 frees, 203,462 bytes allocated.
> ==31236== For counts of detected errors, rerun with: -v
> ==31236== searching for pointers to 1 not-freed blocks.
> ==31236== checked 126,060 bytes.
> ==31236== 
> ==31236== 16 bytes in 1 blocks are definitely lost in loss record 1 of 1
> ==31236==at 0x4023D6E: malloc (vg_replace_malloc.c:207)
> ==31236==by 0x40309DC: axutil_allocator_malloc_impl (allocator.c:75)
> ==31236==by 0x402FE75: axutil_hash_first (hash.c:161)
> ==31236==by 0x4065779: axiom_soap_header_remove_header_block 
> (soap_header.c:550)
> ==31236==by 0x80489BF: main (test.c:35)
> ==31236== 
> ==31236== LEAK SUMMARY:
> ==31236==definitely lost: 16 bytes in 1 blocks.
> ==31236==  possibly lost: 0 bytes in 0 blocks.
> ==31236==still reachable: 0 bytes in 0 blocks.
> ==31236== suppressed: 0 bytes in 0 blocks.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (AXIS2C-1250) Memory leak in axiom_soap_header_remove_header_block() function

[Damitha Kumarage (JIRA)]

Memory leak in axiom_soap_header_remove_header_block() function
---

 Key: AXIS2C-1250
 URL: https://issues.apache.org/jira/browse/AXIS2C-1250
 Project: Axis2-C
  Issue Type: Bug
 Environment: linux
Reporter: Damitha Kumarage


When axiom_soap_header_remove_header_block() function is called it cause memory 
leak. The sample I used is attached herewith. Following is the leak summary.

==31236== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 25 from 1)
==31236== malloc/free: in use at exit: 16 bytes in 1 blocks.
==31236== malloc/free: 195 allocs, 194 frees, 203,462 bytes allocated.
==31236== For counts of detected errors, rerun with: -v
==31236== searching for pointers to 1 not-freed blocks.
==31236== checked 126,060 bytes.
==31236== 
==31236== 16 bytes in 1 blocks are definitely lost in loss record 1 of 1
==31236==at 0x4023D6E: malloc (vg_replace_malloc.c:207)
==31236==by 0x40309DC: axutil_allocator_malloc_impl (allocator.c:75)
==31236==by 0x402FE75: axutil_hash_first (hash.c:161)
==31236==by 0x4065779: axiom_soap_header_remove_header_block 
(soap_header.c:550)
==31236==by 0x80489BF: main (test.c:35)
==31236== 
==31236== LEAK SUMMARY:
==31236==definitely lost: 16 bytes in 1 blocks.
==31236==  possibly lost: 0 bytes in 0 blocks.
==31236==still reachable: 0 bytes in 0 blocks.
==31236== suppressed: 0 bytes in 0 blocks.



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1249) Memory leak in notify client sample

[Damitha Kumarage (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1249?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12618953#action_12618953
 ] 

Damitha Kumarage commented on AXIS2C-1249:
--

The reason is response message context is not freed in case of send_robust. 
Freeing this make the leaks to zero

> Memory leak in notify client sample
> ---
>
> Key: AXIS2C-1249
> URL: https://issues.apache.org/jira/browse/AXIS2C-1249
> Project: Axis2-C
>  Issue Type: Bug
>    Reporter: Damitha Kumarage
>
> In current svn following memory leak is detected
> ==6296== 1,064 (268 direct, 796 indirect) bytes in 1 blocks are definitely 
> lost in loss record 6 of 6
> ==6296==at 0x4023D6E: malloc (vg_replace_malloc.c:207)
> ==6296==by 0x40309DC: axutil_allocator_malloc_impl (allocator.c:75)
> ==6296==by 0x40B99E5: axis2_msg_ctx_create (msg_ctx.c:232)
> ==6296==by 0x40BFAB9: axis2_op_client_two_way_send (op_client.c:1193)
> ==6296==by 0x40C12B0: axis2_op_client_execute (op_client.c:504)
> ==6296==by 0x40C37DC: axis2_svc_client_send_robust_with_op_qname 
> (svc_client.c:593)
> ==6296==by 0x40C38E2: axis2_svc_client_send_robust (svc_client.c:618)
> ==6296==by 0x8048C83: main (notify_client.c:99)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Created: (AXIS2C-1249) Memory leak in notify client sample

[Damitha Kumarage (JIRA)]

Memory leak in notify client sample
---

 Key: AXIS2C-1249
 URL: https://issues.apache.org/jira/browse/AXIS2C-1249
 Project: Axis2-C
  Issue Type: Bug
Reporter: Damitha Kumarage


In current svn following memory leak is detected

==6296== 1,064 (268 direct, 796 indirect) bytes in 1 blocks are definitely lost 
in loss record 6 of 6
==6296==at 0x4023D6E: malloc (vg_replace_malloc.c:207)
==6296==by 0x40309DC: axutil_allocator_malloc_impl (allocator.c:75)
==6296==by 0x40B99E5: axis2_msg_ctx_create (msg_ctx.c:232)
==6296==by 0x40BFAB9: axis2_op_client_two_way_send (op_client.c:1193)
==6296==by 0x40C12B0: axis2_op_client_execute (op_client.c:504)
==6296==by 0x40C37DC: axis2_svc_client_send_robust_with_op_qname 
(svc_client.c:593)
==6296==by 0x40C38E2: axis2_svc_client_send_robust (svc_client.c:618)
==6296==by 0x8048C83: main (notify_client.c:99)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Switching back to httpd request pool

[Damitha Kumarage]

Manjula Peiris wrote:

Hi,

In Axis2/C 1.4 and 1.5 releases we have changed the logic in mod_axis2
to create our own apr_pool from our own apr_allocator for a particular
request. This change was done to handle requests with relatively large
attachment for a longer period of time in order to prevent
swapping.Since we have attachment caching logic in place we no longer
need this and we can switch back to using httpd request pool as find in
releases prior to 1.4. Also use of httpd request pool has more
performance than the current model. WDYT ?
  
It is a good thing switching back to request pool. I did a performance 
test for 1.5 with and without request pool change and it showed about 
1000tps performance gain with request pool.


thanks,
Damitha

Thanks,
-Manjula 
  



--
__

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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using Apache2 global mutex

[Damitha Kumarage]

Uthaiyashankar wrote:



Hi devs,

Suppose  two requests come to Axis2/C sequentially. Say the first 
request is served by one apache process and the next request is 
served by another process. Then problem is you cannot access the 
previous requests configuration context from your next request 
because each process has it's own configuration context. We recently 
solved this problem using shared memory. But as should be expected 
this is extremely inefficient.


Yes, it is about 10 times slower than non-shared memory implementation.



The other and more effiecient solution is using a database that could 
be shared among your processes. Sandesha2/C uses this approach. 


We have to test the performance of this to decide whether it is worth
doing. I guess the performance will be higher than shared memory
implementation. Only problem is how to solve concurrency issue, without
global mutex.


To solve concurrency issues when using this approach we can use 
Apache2 golbal mutex which could be used when accessing global 
resources like system files and databases. 


Shared memory implementation is very slow because of global mutex :).
Since you implemented it and has good understanding I may ask following 
questions to understand the situation well.


-Did you use apr_shm/apr_rmm or apr_dbm in your implementation?

-If you used apr_shm/apr_rmm then using apache thread_mutex to protect 
axis2 contexts is not enough?. AFAIK they are less expensive than global 
mutexts.


-Is using apr_dbm more expensive?. I guess the answer is yes.

-In the database option can't we use mod_dbd which manages a pool of 
database connections efficiently. It is using apr_reslist. Can we use 
apr_reslist directly without mod_dbd?


thanks,
Damitha

So, if we introduce it here, then again we are going to have same issue
as in shared memory implementation. Can't we have database level
concurrency protection to solve this?

Shall we have a comparision of database implementation Vs shared memory
- with and without global mutex to see whether it is worth doing?

Regards,
Shankar.

But the problem is how we could pass this global mutext from Axis2 
apache module to be accessible from other parts of the code, for 
example from a Axis2/C module. We currently pass Apache2 pools 
through axis2_env_t environment. How about using the same in passing 
this as well?


thanks,
Damitha




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
*______*

Damitha Kumarage
http://people.apache.org/
*__*

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Using Apache2 global mutex

[Damitha Kumarage]

Hi devs,

Suppose  two requests come to Axis2/C sequentially. Say the first 
request is served by one apache process and the next request is served 
by another process. Then problem is you cannot access the previous 
requests configuration context from your next request because each 
process has it's own configuration context. We recently solved this 
problem using shared memory. But as should be expected this is extremely 
inefficient.


The other and more effiecient solution is using a database that could be 
shared among your processes. Sandesha2/C uses this approach. To solve 
concurrency issues when using this approach we can use Apache2 golbal 
mutex which could be used when accessing global resources like system 
files and databases. But the problem is how we could pass this global 
mutext from Axis2 apache module to be accessible from other parts of the 
code, for example from a Axis2/C module. We currently pass Apache2 pools 
through axis2_env_t environment. How about using the same in passing 
this as well?


thanks,
Damitha

--
*__*

Damitha Kumarage
http://people.apache.org/
*__*

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE][Axis2]Apache Axis2/C 1.5.0 Release

[Damitha Kumarage]

Hi Supun,
I tested in dabian with Sandesha2/C and Savan/C. It works fine.
Here is my +1

Damitha
Supun Kamburugamuva wrote:

Hi Devs,

I have uploaded the Apache Axis2/C 1.5.0 release artifacts here
http://people.apache.org/~supun/axis2/release_1_5/1.5.0 



The key to verify the release artifacts can be found at
http://people.apache.org/~supun/axis2/release_1_5/1.5.0/KEYS 



If the released artifacts are fine, please vote for the Apache Axis2/C 
1.5.0 release.

Here is my +1.

Thanks,
Supun



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1236) Memory issues in Axis2/C service client

[Damitha Kumarage (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12614650#action_12614650
 ] 

Damitha Kumarage commented on AXIS2C-1236:
--

Are you using libxml2 parser?. If  so use
axis2_options_set_xml_parser_reset() from client api. 
See
https://issues.apache.org/jira/browse/AXIS2C-884

Is this issue related to your issue?

> Memory issues in Axis2/C service client
> ---
>
> Key: AXIS2C-1236
> URL: https://issues.apache.org/jira/browse/AXIS2C-1236
> Project: Axis2-C
>  Issue Type: Bug
>  Components: core/clientapi
>Affects Versions: 1.4.0
> Environment: Linux, Axis2/C 1.4.0, Rampart/C 1.2.0
>Reporter: Chris Rose
>
> Some memory errors are cropping up when I run the client API through 
> valgrind, some of which are leaks, others of which are problems with 
> accessing previously-freed memory.
> When calling axis2_svc_client_send_receive, there is an invalid read from a 
> previously-freed AXIOM node structure.  This occurs during SOAP fault 
> processing:
> ==17373== Invalid read of size 4
> ==17373==at 0x4544A82: axiom_node_is_complete (om_node.c:991)
> ==17373==by 0x454E5FE: axiom_stax_builder_end_element 
> (om_stax_builder.c:755)
> ==17373==by 0x454EF51: axiom_stax_builder_next_with_token 
> (om_stax_builder.c:1154)
> ==17373==by 0x4558F9D: axiom_soap_builder_next (soap_builder.c:300)
> ==17373==by 0x455099D: axiom_soap_fault_get_reason (soap_fault.c:274)
> ==17373==by 0x4557791: axiom_soap_body_convert_fault_to_soap11 
> (soap_body.c:422)
> ==17373==by 0x45BF00C: axis2_svc_client_send_receive_with_op_qname 
> (svc_client.c:932)
> ==17373==by 0x45BF082: axis2_svc_client_send_receive (svc_client.c:949)
> ==17373==by 0x44F7DBF: Axis2c_cmd_svc_client (axis2c_api.c:487)
> ==17373==by 0x402FA62: TclEvalObjvInternal (tclBasic.c:3084)
> ==17373==by 0x40618BB: TclExecuteByteCode (tclExecute.c:1404)
> ==17373==by 0x4060A55: TclCompEvalObj (tclExecute.c:982)
> ==17373==  Address 0x4455bb8 is 32 bytes inside a block of size 40 free'd
> ==17373==at 0x400543C: free (vg_replace_malloc.c:323)
> ==17373==by 0x4519EA3: axutil_allocator_free_impl (allocator.c:91)
> ==17373==by 0x4543886: axiom_node_free_detached_subtree (om_node.c:154)
> ==17373==by 0x4543760: axiom_node_free_detached_subtree (om_node.c:106)
> ==17373==by 0x45438BC: axiom_node_free_tree (om_node.c:178)
> ==17373==by 0x4557765: axiom_soap_body_convert_fault_to_soap11 
> (soap_body.c:413)
> ==17373==by 0x45BF00C: axis2_svc_client_send_receive_with_op_qname 
> (svc_client.c:932)
> ==17373==by 0x45BF082: axis2_svc_client_send_receive (svc_client.c:949)
> ==17373==by 0x44F7DBF: Axis2c_cmd_svc_client (axis2c_api.c:487)
> ==17373==by 0x402FA62: TclEvalObjvInternal (tclBasic.c:3084)
> ==17373==by 0x40618BB: TclExecuteByteCode (tclExecute.c:1404)
> ==17373==by 0x4060A55: TclCompEvalObj (tclExecute.c:982)
> ==17373== 
> ==17373== Invalid read of size 4
> ==17373==at 0x4544883: axiom_node_get_parent (om_node.c:876)
> ==17373==by 0x454E617: axiom_stax_builder_end_element 
> (om_stax_builder.c:757)
> ==17373==by 0x454EF51: axiom_stax_builder_next_with_token 
> (om_stax_builder.c:1154)
> ==17373==by 0x4558F9D: axiom_soap_builder_next (soap_builder.c:300)
> ==17373==by 0x455099D: axiom_soap_fault_get_reason (soap_fault.c:274)
> ==17373==by 0x4557791: axiom_soap_body_convert_fault_to_soap11 
> (soap_body.c:422)
> ==17373==by 0x45BF00C: axis2_svc_client_send_receive_with_op_qname 
> (svc_client.c:932)
> ==17373==by 0x45BF082: axis2_svc_client_send_receive (svc_client.c:949)
> ==17373==by 0x44F7DBF: Axis2c_cmd_svc_client (axis2c_api.c:487)
> ==17373==by 0x402FA62: TclEvalObjvInternal (tclBasic.c:3084)
> ==17373==by 0x40618BB: TclExecuteByteCode (tclExecute.c:1404)
> ==17373==by 0x4060A55: TclCompEvalObj (tclExecute.c:982)
> ==17373==  Address 0x4455ba0 is 8 bytes inside a block of size 40 free'd
> ==17373==at 0x400543C: free (vg_replace_malloc.c:323)
> ==17373==by 0x4519EA3: axutil_allocator_free_impl (allocator.c:91)
> ==17373==by 0x4543886: axiom_node_free_detached_subtree (om_node.c:154)
> ==17373==by 0x4543760: axiom_node_free_detached_subtree (om_node.c:106)
> ==17373==by 0x45438BC: axiom_node_free_tree (om_node.c:178)
> ==17373==by 0x4557765: axiom_soap_body_convert_fault_to_soap11 
> (soap_body.c:413)
> ==17373==by 0x45BF00C: axis2_svc_client_send_receive_with_op_qname 
> (svc_client.c:932)
> ==17373==

[jira] Assigned: (AXIS2C-1227) engine not freed when server return an error

[Damitha Kumarage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damitha Kumarage reassigned AXIS2C-1227:


Assignee: Damitha Kumarage

> engine not freed when server return an error
> 
>
> Key: AXIS2C-1227
> URL: https://issues.apache.org/jira/browse/AXIS2C-1227
> Project: Axis2-C
>  Issue Type: Bug
>  Components: transport/http
>Affects Versions: Current (Nightly)
> Environment: linux fc6
>Reporter: Frederic Heem
>    Assignee: Damitha Kumarage
> Attachments: http_worker.patch
>
>
> In http_worker.c at line 1181, the engine is created but not destroyed, this 
> happens when the server returns a fault.
> ==17539== 12 bytes in 3 blocks are definitely lost in loss record 4 of 103
> ==17539==at 0x4005858: malloc (vg_replace_malloc.c:207)
> ==17539==by 0x4091E75: axis2_engine_create (engine.c:52)
> ==17539==by 0x4016B40: axis2_http_worker_process_request 
> (http_worker.c:1181)
> ==17539==by 0x4123ED0: axis2_svr_thread_worker_func 
> (http_svr_thread.c:259)
> ==17539==by 0x405EEE5: dummy_worker (thread_unix.c:93)
> ==17539==by 0x8E145A: start_thread (in /lib/libpthread-2.5.so)
> ==17539==by 0x71323D: clone (in /lib/libc-2.5.so)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Assigned: (AXIS2C-1223) Ws-Addressing Module, extracting information from EPR

[Damitha Kumarage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damitha Kumarage reassigned AXIS2C-1223:


Assignee: Damitha Kumarage

> Ws-Addressing Module, extracting information from EPR
> -
>
> Key: AXIS2C-1223
> URL: https://issues.apache.org/jira/browse/AXIS2C-1223
> Project: Axis2-C
>  Issue Type: Bug
>  Components: core/addressing
>Affects Versions: 1.4.0, 1.4.1
> Environment: Linux, Windows
>Reporter: Julien Billon
>    Assignee: Damitha Kumarage
>   Original Estimate: 0.17h
>  Remaining Estimate: 0.17h
>
> According to the WS-Addressing specification, an EndPoint Reference (EPR) can 
> be specified in the  node. In the WS-Addressing Module, the 
> function axis2_addr_in_extract_epr_information() is responsible for 
> extracting the datas from an EPR.
> But if we look more closely at this function (around line 600), we see that 
> the reference parameters are parsed and ... that's all ! these parameters are 
> never stored in the EPR structure.
> Example :
> With a message like
> http://www.w3.org/2003/05/soap-envelope\"; 
> xmlns:wsa="http://www.w3.org/2005/08/addressing";>
>  
>   http://example.com/services/echo
>   http://example.com/OTA_PINGRQ
>   6dc6e535-1a70-4544-9715-26f06cdcf7bb
>   
>http://requester.com
>
> example
>   
>  
>  XMLBody
> 
> We call the ws-addressing module to extract information from the soap header. 
> Then if we call axis2_msg_ctx_get_reply_to() and 
> axis2_endpoint_ref_get_ref_param_list() this last function always return NULL.
> Patch :
> File addr_in_handler.c Line 600
> REPLACE om_ele = (axiom_element_t *) axiom_node_get_data_element(om_node, 
> env); 
> BY axis2_endpoint_ref_add_ref_param(endpoint_ref, env, om_node);

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1156) memory leak in savanc

[Damitha Kumarage (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12613110#action_12613110
 ] 

Damitha Kumarage commented on AXIS2C-1156:
--

I found that leak details for server side actually caused by publisher sample. 
publisher sample publish data in a loop within a thread. We need to study it 
and fix the leaks

> memory leak in savanc
> -
>
> Key: AXIS2C-1156
> URL: https://issues.apache.org/jira/browse/AXIS2C-1156
> Project: Axis2-C
>  Issue Type: Bug
>Affects Versions: 1.4.0
> Environment: linux fc5
>Reporter: Frederic Heem
>    Assignee: Damitha Kumarage
> Fix For: 1.4.1
>
> Attachments: in_handler.patch, sub_processor.patch
>
>
> In savan_in_handler_invoke(), a processor is created by 
> savan_sub_processor_create()  but it is not freed, actually, there isn't a 
> function to free it (savan_sub_processor_free() ?)
> Also there is a mix of tab and spaces in the file which makes it difficult to 
> read and maintain.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1156) memory leak in savanc

[Damitha Kumarage (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12613039#action_12613039
 ] 

Damitha Kumarage commented on AXIS2C-1156:
--

Hi Diluka,
Applied your patch.
But still valgrind show a context error an leaks in client side. It is good to 
know whether this context error is caused by Savan/C.

==32284== Invalid free() / delete / delete[]
==32284==at 0x4022B8A: free (vg_replace_malloc.c:323)
==32284==by 0x4296C4B: (within /lib/i686/cmov/libc-2.7.so)
==32284==by 0x4296773: __libc_freeres (in /lib/i686/cmov/libc-2.7.so)
==32284==by 0x401E216: _vgnU_freeres (vg_preloaded.c:60)
==32284==by 0x4214EC3: _Exit (in /lib/i686/cmov/libc-2.7.so)
==32284==by 0x4195457: (below main) (in /lib/i686/cmov/libc-2.7.so)
==32284==  Address 0x417a580 is not stack'd, malloc'd or (recently) free'd
==32284==
==32284== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 75 from 2)
==32284== malloc/free: in use at exit: 1,436 bytes in 17 blocks.
==32284== malloc/free: 17,255 allocs, 17,239 frees, 870,840 bytes allocated.
==32284== For counts of detected errors, rerun with: -v
==32284== searching for pointers to 17 not-freed blocks.
==32284== checked 204,184 bytes.
==32284==
==32284==
==32284== 864 (48 direct, 816 indirect) bytes in 2 blocks are definitely lost 
in loss record 6 of 6
==32284==at 0x4023D6E: malloc (vg_replace_malloc.c:207)
==32284==by 0x4030A8C: axutil_allocator_malloc_impl (in 
/axis2c/deploy/lib/libaxutil.so.0.5.0)
==32284==by 0x40308FB: axutil_hash_make (in 
/axis2c/deploy/lib/libaxutil.so.0.5.0)
==32284==by 0x80491BD: main (subscriber.c:89)
==32284==
==32284== LEAK SUMMARY:
==32284==definitely lost: 48 bytes in 2 blocks.
==32284==indirectly lost: 816 bytes in 11 blocks.
==32284==  possibly lost: 0 bytes in 0 blocks.
==32284==still reachable: 572 bytes in 4 blocks.



Also in the server side there are leaks.

==32379== 136 bytes in 1 blocks are possibly lost in loss record 4 of 12
==32379==at 0x4021E22: calloc (vg_replace_malloc.c:397)
==32379==by 0x4010627: (within /lib/ld-2.7.so)
==32379==by 0x40106EB: _dl_allocate_tls (in /lib/ld-2.7.so)
==32379==by 0x4152C3C: pthread_create@@GLIBC_2.1 (in 
/lib/i686/cmov/libpthread-2.7.so)
==32379==by 0x407DBF6: axutil_thread_create (in 
/axis2c/deploy/lib/libaxutil.so.0.5.0)
==32379==by 0x40747C4: axutil_thread_pool_get_thread (in 
/axis2c/deploy/lib/libaxutil.so.0.5.0)
==32379==by 0x4734114: ???
==32379==by 0x40E0DF8: (within /axis2c/deploy/lib/libaxis2_engine.so.0.5.0)
==32379==by 0x40E1235: axis2_build_conf_ctx (in 
/axis2c/deploy/lib/libaxis2_engine.so.0.5.0)
==32379==by 0x411FE3A: axis2_http_server_create (in 
/axis2c/deploy/lib/libaxis2_http_receiver.so.0.5.0)
==32379==by 0x8057A47: (within /axis2c/deploy/bin/axis2_http_server)
==32379==by 0x419544F: (below main) (in /lib/i686/cmov/libc-2.7.so)
==32379==
==32379==
==32379== 440 bytes in 10 blocks are definitely lost in loss record 7 of 12
==32379==at 0x4023D6E: malloc (vg_replace_malloc.c:207)
==32379==by 0x46E4483: ???
==32379==by 0x4701A85: ???
==32379==by 0x4723E56: ???
==32379==by 0x46DB01A: ???
==32379==by 0x46D74C7: ???
==32379==by 0x46D7B4E: ???
==32379==by 0x46D7B4E: ???
==32379==by 0x40BAF3C: axis2_handler_invoke (in 
/axis2c/deploy/lib/libaxis2_engine.so.0.5.0)
==32379==by 0x40C0C22: axis2_phase_invoke (in 
/axis2c/deploy/lib/libaxis2_engine.so.0.5.0)
==32379==by 0x40C440D: axis2_engine_invoke_phases (in 
/axis2c/deploy/lib/libaxis2_engine.so.0.5.0)
==32379==by 0x40C4F71: axis2_engine_receive (in 
/axis2c/deploy/lib/libaxis2_engine.so.0.5.0)
==32379==by 0x409AEFA: axis2_http_transport_utils_process_http_post_request 
(in /axis2c/deploy/lib/libaxis2_http_common.so.0.5.0)
==32379==
==32379==
==32379== 528 bytes in 12 blocks are definitely lost in loss record 8 of 12
==32379==at 0x4023D6E: malloc (vg_replace_malloc.c:207)
==32379==by 0x4897B63: ???
==32379==by 0x48B5165: ???
==32379==by 0x48D7F50: ???
==32379==by 0x488C0F4: ???
==32379==by 0x473403D: ???
==32379==by 0x407D7E5: (within /axis2c/deploy/lib/libaxutil.so.0.5.0)
==32379==by 0x41524FA: start_thread (in /lib/i686/cmov/libpthread-2.7.so)
==32379==by 0x4255D7D: clone (in /lib/i686/cmov/libc-2.7.so)
==32379==
==32379==
==32379== 9,725 (1,866 direct, 7,859 indirect) bytes in 35 blocks are 
definitely lost in loss record 12 of 12
==32379==at 0x4023D6E: malloc (vg_replace_malloc.c:207)
==32379==by 0x406BA8C: axutil_allocator_malloc_impl (in 
/axis2c/deploy/lib/libaxutil.so.0.5.0)
==32379==by 0x40334A8: axiom_node_create (in 
/axis2c/deploy/lib/libaxis2_axiom.so.0.5.0)
==32379==by 0x4038B44: axiom_element_create (in 
/axis2c/deploy/lib/libaxis2_axiom.so.0.5.0)
==32379==by 0x4733F47: ???
==32379==by

Re: [Axis2]Axis2/C 1.5.0 RC2

[Damitha Kumarage]

Hi supun,

Tested binary/source on debian with Sandesha2/C. +1
thanks
Damitha
Supun Kamburugamuva wrote:

Hi All,

I have re-packed and uploaded Apache Axis2/C 1.5.0 RC2 here [1]. 
Please test and send your feedback.


[1] http://people.apache.org/~supun/axis2/release_1_5/rc2/ 



Thanks,
Supun.. 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Assigned: (AXIS2C-1219) Savan remote subs_mgr gives an internal server error

[Damitha Kumarage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damitha Kumarage reassigned AXIS2C-1219:


Assignee: Damitha Kumarage

> Savan remote subs_mgr gives an internal server error
> 
>
> Key: AXIS2C-1219
> URL: https://issues.apache.org/jira/browse/AXIS2C-1219
> Project: Axis2-C
>  Issue Type: Bug
> Environment: Ubuntu 7.04
>Reporter: Diluka Moratuwage
>Assignee: Damitha Kumarage
> Attachments: subs_mgr.patch
>
>
> When there is no subscriber is registered with savan_sub_mgr, the 
> get_subscriber_list gives an internal server error. And we have to set MEP of 
> subs_mgr service's add_subscriber operation to in-only, in order to avoid 
> internal server error, when it's used.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (AXIS2C-1219) Savan remote subs_mgr gives an internal server error

[Damitha Kumarage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damitha Kumarage resolved AXIS2C-1219.
--

Resolution: Fixed

Patch applied. Thanks Diluka

> Savan remote subs_mgr gives an internal server error
> 
>
> Key: AXIS2C-1219
> URL: https://issues.apache.org/jira/browse/AXIS2C-1219
> Project: Axis2-C
>  Issue Type: Bug
> Environment: Ubuntu 7.04
>Reporter: Diluka Moratuwage
>Assignee: Damitha Kumarage
> Attachments: subs_mgr.patch
>
>
> When there is no subscriber is registered with savan_sub_mgr, the 
> get_subscriber_list gives an internal server error. And we have to set MEP of 
> subs_mgr service's add_subscriber operation to in-only, in order to avoid 
> internal server error, when it's used.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Fwd: Specifying MEP in services.xml for in-only operations should be mandatory

[Damitha Kumarage]

+1 for making including MEP mandatory in services xml.
thanks
Damitha
Supun Kamburugamuva wrote:

Hi all,

Discard the previous mail as its subject is incorrect.

Previously it wasn't mandatory to specify the MEP in the services XML 
for operations. But due to the recent fixes non in-out message 
patterns are not working properly without the MEP in some scenarios. 
The need arises in case of fault messages. If the service business 
logic is not implemented for an in-out MEP, withought the MEP Axis2/C 
cannot deside weather the behaviour is logical or not. This happens 
because for a in-only message the service doesn't return a value.


Now we are checking the MEP in the message receiver. So if a in-only 
operation doesn't specify the MEP in the service XML it will fail. 
Also we need to add this to code generation as well.


Here are the Jiras that are related to this

https://issues.apache.org/jira/browse/AXIS2C-1215
https://issues.apache.org/jira/browse/AXIS2C-1213
https://issues.apache.org/jira/browse/AXIS2C-1154

Regards,
Supun..




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Axis2]Code Freeze for Axis2/C 1.5.0 Release

[Damitha Kumarage]

+1
Damitha
Supun Kamburugamuva wrote:


Hi All,

Since we are planning for Axis2/C 1.5.0 Release soon , I think it is 
time to call for a code freeze. Please refrain from doing major 
changes and adding new features to the svn head, until we do the release.


thanks,
Supun.




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (AXIS2C-1211) Improving the AXIS2_SVC_SKELETON_INIT_WITH_CONF

[Damitha Kumarage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damitha Kumarage resolved AXIS2C-1211.
--

Resolution: Fixed

Diluka,
I applied the patch and it seems ok. Thanks for the patch.

> Improving the AXIS2_SVC_SKELETON_INIT_WITH_CONF
> ---
>
> Key: AXIS2C-1211
> URL: https://issues.apache.org/jira/browse/AXIS2C-1211
> Project: Axis2-C
>  Issue Type: Bug
> Environment: Ubuntu 7.04
>Reporter: Diluka Moratuwage
> Attachments: conf_ctx.patch
>
>
>I have some problem with AXIS2_SVC_SKELETON_INIT_WITH_CONF macro. 
> Apparently it allows the service to use the configuration, within the 
> service, when it's starting up. But, by the time this function is called 
> (when loading services), we have already created the conf_ctx. And as I have 
> seen the very usage of this comes when a service have to be started up. But 
> in order to use it, we have to create conf_ctx within the service most 
> probably.
> So I think it will be appropriate to send the conf_ctx instead of conf 
> into a service. So if the service has any need of the conf, still it can get 
> the conf from the conf_ctx.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1213) server returns HTTP/1.1 500 Internal Server Error for In-Only message

[Damitha Kumarage (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609472#action_12609472
 ] 

Damitha Kumarage commented on AXIS2C-1213:
--

Hi Frederic,
To solve your problem Set the operation mep attribute in services.xml. For 
example

http://www.w3.org/2004/08/wsdl/in-only";>
   http://ws.apache.org/axis2/c/samples/notify
   

Yesterday's Supun's fix require that the mep is provided in services.xml. 
Default is in-out.
We should document this in Axis2/C documentations. 



> server returns HTTP/1.1 500 Internal Server Error for In-Only message
> -
>
> Key: AXIS2C-1213
> URL: https://issues.apache.org/jira/browse/AXIS2C-1213
> Project: Axis2-C
>  Issue Type: Bug
>Affects Versions: Current (Nightly)
> Environment: linux fc6
>Reporter: Frederic Heem
>Priority: Blocker
>
> After upgrading from svn, In-Only messages stop working correctly: 
> * the server returns HTTP/1.1 500 Internal Server Error
> * the client returns successfully even though the server returns an error:
> Here the conversation between and server:
> POST /axis2/services/zigbee HTTP/1.1
> User-Agent: Axis2C/1.4.0
> SOAPAction: ""
> Content-Length: 507
> Content-Type: text/xml;charset=UTF-8
> Host: localhost:9090
>  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";> xmlns:wsa="http://www.w3.org/2005/08/addressing";>http://localhost:9090/axis2/services/zigbeePermitJoining5b6a6c86-46b8-1dd1-3722-0014c2e176e7  
> xmlns:n="http://www.telsey.com/DPWS/2008/03/Zigbee";>50
> HTTP/1.1 500 Internal Server Error
> Date: Mon Jun 30 16:22:31 2008 GMT
> Server: Axis2C/1.4.0 (Simple Axis2 HTTP Server)
> Content-Type: text/xml;charset=UTF-8
> Content-Length: 370
>  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>soapenv:SenderNULL
>  parameter was passed when a non NULL parameter was 
> expected

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1215) incorrect MEP on the server side

[Damitha Kumarage (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609471#action_12609471
 ] 

Damitha Kumarage commented on AXIS2C-1215:
--

Also please note that if you don't set the mep in operation the default is 
taken as in-out. This explains Frederic's problem

> incorrect MEP on the server side
> 
>
> Key: AXIS2C-1215
> URL: https://issues.apache.org/jira/browse/AXIS2C-1215
> Project: Axis2-C
>  Issue Type: Bug
>Affects Versions: Current (Nightly)
> Environment: linux fc6
>Reporter: Frederic Heem
>
> On the server side, the MEP is set in the generated code in the function 
> axis2_stub_populate_services_for_myService, some of my message are set to 
> AXIS2_MEP_URI_OUT_ONLY. However, when printing the MEP in 
> axis2_raw_xml_in_out_msg_recv_invoke_business_logic_sync(), the MEP is 
> http://www.w3.org/2004/08/wsdl/in-out. Therefore, the new code which is based 
> on the MEP value doesn't work as expected. Please note that this issue is 
> related to AXIS2C-1213.
> Best Regards,

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1215) incorrect MEP on the server side

[Damitha Kumarage (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609470#action_12609470
 ] 

Damitha Kumarage commented on AXIS2C-1215:
--

You can set your mep as an operation attribute in your services.xml. See below. 

http://www.w3.org/2004/08/wsdl/in-only";>  
   
http://ws.apache.org/axis2/c/samples/notify
   

After yesterdays Supun's changes I had problem with some of my one way messages 
in savan(internal server error). After adding the above mep attribute it works 
fine.

> incorrect MEP on the server side
> 
>
> Key: AXIS2C-1215
> URL: https://issues.apache.org/jira/browse/AXIS2C-1215
> Project: Axis2-C
>  Issue Type: Bug
>Affects Versions: Current (Nightly)
> Environment: linux fc6
>Reporter: Frederic Heem
>
> On the server side, the MEP is set in the generated code in the function 
> axis2_stub_populate_services_for_myService, some of my message are set to 
> AXIS2_MEP_URI_OUT_ONLY. However, when printing the MEP in 
> axis2_raw_xml_in_out_msg_recv_invoke_business_logic_sync(), the MEP is 
> http://www.w3.org/2004/08/wsdl/in-out. Therefore, the new code which is based 
> on the MEP value doesn't work as expected. Please note that this issue is 
> related to AXIS2C-1213.
> Best Regards,

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1213) server returns HTTP/1.1 500 Internal Server Error for In-Only message

[Damitha Kumarage (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609296#action_12609296
 ] 

Damitha Kumarage commented on AXIS2C-1213:
--

According to soap 1.1 specication

"The header field value of empty string ("") means that the intent of the SOAP 
message is
provided by the HTTP Request-URI. No value means that there is no indication of 
the intent
of the message."

Also according to the same spec

"An HTTP client MUST use the SOAPAction header field when issuing a SOAP HTTP 
Request"

In soap 1.2 media type application/soap+xml optionally defines action parameter.

According to the WSDL version 2.0 Soap 1.1 binding extension

"A SOAP Binding is identified as a SOAP 1.1 binding by assigning the value 
"1.1" to the {soap version}
property of the Binding component."

According to same extension

"SOAP Action. If the Binding Operation component does NOT have a {soap action} 
property defined, then
the quoted empty string value ("") value is used for the SOAP 1.1 SOAPAction 
HTTP Header Field (see [SOAP11])."

Note that for soap 1.2 action is optional. So for wsdl2.0 there could be {soap 
action} not defined.

Read more about this extension
http://www.w3.org/TR/wsdl20-soap11-binding/#soap11-binding


Also accroding to WSDL 1.1 soap 1.2 binding

In binding element

"
   "
...


In operation element
" ?"

where you need to define 
xmlns:wsoap12="http://schemas.xmlsoap.org/wsdl/soap12/"; in wsdl:definitions
 section.

Since SOAPAction is mandatory when soap 1.1 is used wsdl should have an empty 
SOAPAction string 

> server returns HTTP/1.1 500 Internal Server Error for In-Only message
> -
>
> Key: AXIS2C-1213
> URL: https://issues.apache.org/jira/browse/AXIS2C-1213
> Project: Axis2-C
>  Issue Type: Bug
>Affects Versions: Current (Nightly)
> Environment: linux fc6
>Reporter: Frederic Heem
>Priority: Blocker
>
> After upgrading from svn, In-Only messages stop working correctly: 
> * the server returns HTTP/1.1 500 Internal Server Error
> * the client returns successfully even though the server returns an error:
> Here the conversation between and server:
> POST /axis2/services/zigbee HTTP/1.1
> User-Agent: Axis2C/1.4.0
> SOAPAction: ""
> Content-Length: 507
> Content-Type: text/xml;charset=UTF-8
> Host: localhost:9090
>  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";> xmlns:wsa="http://www.w3.org/2005/08/addressing";>http://localhost:9090/axis2/services/zigbeePermitJoining5b6a6c86-46b8-1dd1-3722-0014c2e176e7  
> xmlns:n="http://www.telsey.com/DPWS/2008/03/Zigbee";>50
> HTTP/1.1 500 Internal Server Error
> Date: Mon Jun 30 16:22:31 2008 GMT
> Server: Axis2C/1.4.0 (Simple Axis2 HTTP Server)
> Content-Type: text/xml;charset=UTF-8
> Content-Length: 370
>  xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/";>soapenv:SenderNULL
>  parameter was passed when a non NULL parameter was 
> expected

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Resolved: (AXIS2C-1212) incorrect debug message in axis2_raw_xml_in_out_msg_recv_invoke_business_logic_sync

[Damitha Kumarage (JIRA)]

 [ 
https://issues.apache.org/jira/browse/AXIS2C-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Damitha Kumarage resolved AXIS2C-1212.
--

Resolution: Fixed

This is fixed by calling and printing the fault details base nodes to_string 
function.

> incorrect debug message in 
> axis2_raw_xml_in_out_msg_recv_invoke_business_logic_sync
> ---
>
> Key: AXIS2C-1212
> URL: https://issues.apache.org/jira/browse/AXIS2C-1212
> Project: Axis2-C
>  Issue Type: Bug
>  Components: core/receivers
>Affects Versions: Current (Nightly)
> Environment: linux fc6
>Reporter: Frederic Heem
>
> In the function axis2_raw_xml_in_out_msg_recv_invoke_business_logic_sync at 
> line 394, the fault details is incorrelty prints, it it not a string but the 
> formatter %s is used. 
> Here is the valgrind output:
> =30186== Thread 3:
> ==30186== Invalid read of size 1
> ==30186==at 0x4006773: strlen (mc_replace_strmem.c:242)
> ==30186==by 0x6841FE: vfprintf (in /lib/libc-2.5.so)
> ==30186==by 0x6A2F63: vsnprintf (in /lib/libc-2.5.so)
> ==30186==by 0x40503B2: axutil_log_impl_log_debug (log.c:418)
> ==30186==by 0x409D157: 
> axis2_raw_xml_in_out_msg_recv_invoke_business_logic_sync 
> (raw_xml_in_out_msg_recv.c:394)
> ==30186==by 0x409C243: axis2_msg_recv_invoke_business_logic 
> (msg_recv.c:397)
> ==30186==by 0x409C873: axis2_msg_recv_receive_impl (msg_recv.c:319)
> ==30186==by 0x409C2C3: axis2_msg_recv_receive (msg_recv.c:436)
> ==30186==by 0x4091A83: axis2_engine_receive (engine.c:318)
> ==30186==by 0x4019DAD: 
> axis2_http_transport_utils_process_http_post_request 
> (http_transport_utils.c:658)
> ==30186==by 0x4016B03: axis2_http_worker_process_request 
> (http_worker.c:908)
> ==30186==by 0x4123ED0: axis2_svr_thread_worker_func 
> (http_svr_thread.c:259)
> ==30186==  Address 0x43e0bfc is 0 bytes after a block of size 4 alloc'd
> ==30186==at 0x4005858: malloc (vg_replace_malloc.c:207)
> ==30186==by 0x4036075: axiom_soap_fault_detail_create 
> (soap_fault_detail.c:36)
> ==30186==by 0x4036125: axiom_soap_fault_detail_create_with_parent 
> (soap_fault_detail.c:67)
> ==30186==by 0x409D12D: 
> axis2_raw_xml_in_out_msg_recv_invoke_business_logic_sync 
> (raw_xml_in_out_msg_recv.c:392)
> ==30186==by 0x409C243: axis2_msg_recv_invoke_business_logic 
> (msg_recv.c:397)
> ==30186==by 0x409C873: axis2_msg_recv_receive_impl (msg_recv.c:319)
> ==30186==by 0x409C2C3: axis2_msg_recv_receive (msg_recv.c:436)
> ==30186==by 0x4091A83: axis2_engine_receive (engine.c:318)
> ==30186==by 0x4019DAD: 
> axis2_http_transport_utils_process_http_post_request 
> (http_transport_utils.c:658)
> ==30186==by 0x4016B03: axis2_http_worker_process_request 
> (http_worker.c:908)
> ==30186==by 0x4123ED0: axis2_svr_thread_worker_func 
> (http_svr_thread.c:259)
> ==30186==by 0x405EF55: dummy_worker (thread_unix.c:93)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[jira] Commented: (AXIS2C-1211) Improving the AXIS2_SVC_SKELETON_INIT_WITH_CONF

[Damitha Kumarage (JIRA)]

[ 
https://issues.apache.org/jira/browse/AXIS2C-1211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12609260#action_12609260
 ] 

Damitha Kumarage commented on AXIS2C-1211:
--

Diluka,

Can you show me a specific situation where conf_ctx needed in service 
initialization. In Savan/C
I can see that in publishing client sample and subscription manager service  a 
conf_ctx is created
out of conf passed to init function. But even there it is not neccessary to 
create such a cont_ctx
because it is not used for any useful things. It is created just because 
publishing cliet needs it.
But when you look at publising client code it does not use it either. It jusr 
retrieve conf from it.
It is the only use publishing client has from conf_ctx. So my suggestion is to 
pass just the
conf to the service init as it is now. But in Savan/C we need to change 
publishing client code
not to accept a conf_ctx but a conf.

> Improving the AXIS2_SVC_SKELETON_INIT_WITH_CONF
> ---
>
> Key: AXIS2C-1211
> URL: https://issues.apache.org/jira/browse/AXIS2C-1211
> Project: Axis2-C
>  Issue Type: Bug
> Environment: Ubuntu 7.04
>Reporter: Diluka Moratuwage
>
>I have some problem with AXIS2_SVC_SKELETON_INIT_WITH_CONF macro. 
> Apparently it allows the service to use the configuration, within the 
> service, when it's starting up. But, by the time this function is called 
> (when loading services), we have already created the conf_ctx. And as I have 
> seen the very usage of this comes when a service have to be started up. But 
> in order to use it, we have to create conf_ctx within the service most 
> probably.
> So I think it will be appropriate to send the conf_ctx instead of conf 
> into a service. So if the service has any need of the conf, still it can get 
> the conf from the conf_ctx.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]