[jira] Assigned: (AXIS2C-858) Apache runs out of memory and crashes with a simple mtom service test run in a loop
[ https://issues.apache.org/jira/browse/AXIS2C-858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manjula Peiris reassigned AXIS2C-858: - Assignee: Manjula Peiris > Apache runs out of memory and crashes with a simple mtom service test run in > a loop > --- > > Key: AXIS2C-858 > URL: https://issues.apache.org/jira/browse/AXIS2C-858 > Project: Axis2-C > Issue Type: Bug > Components: core/engine >Affects Versions: 1.1.0 > Environment: Linux 2.6 kernel >Reporter: Subra A Narayanan >Assignee: Manjula Peiris > > I have a simple mtom service written in Axis2/C which receives requests from > clients with attachments. I wrote a client to consume this service and ran a > test in a loop with 4 mb attachments. I noticed that the apache server ran > out of memory and became very unresponsive after about 45 mins and then core > dumped. The server response seemed to improve after some of the > threads/processes died due to lack of memory and new threads were created to > process the request. > -- 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-861) Enable client session management through http cookies in libcurl
[ https://issues.apache.org/jira/browse/AXIS2C-861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-861: - Attachment: libcurl_diff The attached diff file builds upon the changes suggested in AXIS2C-830, wherein are changes to make the libcurl interface multithreaded with a separate libcurl object for each http transport sender. Building on the changes there, enabling client session management through HTTP session cookies is fairly straightforward. In the msg_ctx, we need to propagate the manage_session flag already made accessible to the client in the options. Then in axis2_libcurl_send, we need to enable the curl cookie engine if manage_session is true, and then discard all cookies if manage_session later is set false. I've included the changes from AXIS2C-830 with these, to make it easier to integrate all at once, and to avoid the problem of the line numbers changing when one is integrated without the other. The only incremental changes are to msg_ctx.c/.h and the code in axis2_libcurl.c to remember the cookie state in the curl structure and to call curl_easy_setopt as needed. Of course, a simple fix would be to enable cookie management all the time in the libcurl interface. In fact, this has been how I have been accessing a service that requires cookies for several weeks now. But since the Java and C++ implementations of Axis controlled this through the maintain_session option, it seems worthwhile to preserve the user control and enable or disable cookie management under the control of the manage_session option here. > Enable client session management through http cookies in libcurl > > > Key: AXIS2C-861 > URL: https://issues.apache.org/jira/browse/AXIS2C-861 > Project: Axis2-C > Issue Type: Improvement > Components: transport/http >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, libxml, libcurl >Reporter: Bill Mitchell > Attachments: libcurl_diff > > > Many existing SOAP services maintain session context through HTTP cookies. > This can be seen in the prevalence of some mechanism to enable client cookies > in various SOAP stacks, including the Axis versions in Java and C++. Without > re-implementing all of this in the Axis2C http transport, it would be easy > and convenient to provide this support for Axis2C clients built with libcurl. > Libcurl already provides the underlying cookie support, all that is needed > is some mechanism to enable/disable this support with, say, the defined but > unused maintain_session option. -- 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-861) Enable client session management through http cookies in libcurl
Enable client session management through http cookies in libcurl Key: AXIS2C-861 URL: https://issues.apache.org/jira/browse/AXIS2C-861 Project: Axis2-C Issue Type: Improvement Components: transport/http Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, libxml, libcurl Reporter: Bill Mitchell Many existing SOAP services maintain session context through HTTP cookies. This can be seen in the prevalence of some mechanism to enable client cookies in various SOAP stacks, including the Axis versions in Java and C++. Without re-implementing all of this in the Axis2C http transport, it would be easy and convenient to provide this support for Axis2C clients built with libcurl. Libcurl already provides the underlying cookie support, all that is needed is some mechanism to enable/disable this support with, say, the defined but unused maintain_session option. -- 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-858) Apache runs out of memory and crashes with a simple mtom service test run in a loop
[ https://issues.apache.org/jira/browse/AXIS2C-858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12555058 ] Subra A Narayanan commented on AXIS2C-858: -- Samisa, I apologize for the delay. I will try to get you the server and client code asap. I was using my own code for the testing. Although I did borrow some code from the MTOM sample of yours. I think we should be able to reproduce the problem with the mtom sample with a 4 meg file. But I will send u my test code anyways. Wish you a very happy new year!! Subra > Apache runs out of memory and crashes with a simple mtom service test run in > a loop > --- > > Key: AXIS2C-858 > URL: https://issues.apache.org/jira/browse/AXIS2C-858 > Project: Axis2-C > Issue Type: Bug > Components: core/engine >Affects Versions: 1.1.0 > Environment: Linux 2.6 kernel >Reporter: Subra A Narayanan > > I have a simple mtom service written in Axis2/C which receives requests from > clients with attachments. I wrote a client to consume this service and ran a > test in a loop with 4 mb attachments. I noticed that the apache server ran > out of memory and became very unresponsive after about 45 mins and then core > dumped. The server response seemed to improve after some of the > threads/processes died due to lack of memory and new threads were created to > process the request. > -- 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-858) Apache runs out of memory and crashes with a simple mtom service test run in a loop
[ https://issues.apache.org/jira/browse/AXIS2C-858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12555053 ] Samisa Abeysinghe commented on AXIS2C-858: -- I was wondering if we should be able to reproduce this with the MTOM sample that we have, with a 4MB file. Did you use the sample that comes with Axis2/C or wrote your own? > Apache runs out of memory and crashes with a simple mtom service test run in > a loop > --- > > Key: AXIS2C-858 > URL: https://issues.apache.org/jira/browse/AXIS2C-858 > Project: Axis2-C > Issue Type: Bug > Components: core/engine >Affects Versions: 1.1.0 > Environment: Linux 2.6 kernel >Reporter: Subra A Narayanan > > I have a simple mtom service written in Axis2/C which receives requests from > clients with attachments. I wrote a client to consume this service and ran a > test in a loop with 4 mb attachments. I noticed that the apache server ran > out of memory and became very unresponsive after about 45 mins and then core > dumped. The server response seemed to improve after some of the > threads/processes died due to lack of memory and new threads were created to > process the request. > -- 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-848) Generated stub for unbounded sequence of type any does not pass any elements to client
[ https://issues.apache.org/jira/browse/AXIS2C-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dimuthu Gamage resolved AXIS2C-848. --- Resolution: Fixed Fixed. (SVN 607594) > Generated stub for unbounded sequence of type any does not pass any elements > to client > -- > > Key: AXIS2C-848 > URL: https://issues.apache.org/jira/browse/AXIS2C-848 > Project: Axis2-C > Issue Type: Bug > Components: code generation >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila parser, > libcurl, using WSDL2C from nightly build of 12/19/07 >Reporter: Bill Mitchell >Assignee: Dimuthu Gamage > Attachments: adb_exemplar_type0.c, adb_exemplar_type0.orig.c, > adb_exemplar_type0.single.c, adb_instance_type1.c, adb_instance_type1.orig.c, > any_test.tar.gz, case26.tar.gz, service.wsdl, unrolled.wsdl > > > Where a complexType is defined as an unbounded sequence of type any, as in > the wsdl fragment below, the generated stub implements no code to handle the > elements themselves, with the comment that it is "imposible to handle the > request type - so please do it manually". Yet, for the same sequence with a > maxOccurs = 1, the generated stub is perfectly willing to return the single > element of type any in a property of type axiom_node_t *, by detaching the > node from the response document and making it a property of the stub object. > It would be useful and reasonable in the case of multiple any items to return > an array of axiom_node_t*, by detaching each from the response message, as is > done in the case of a single any element. > > > > > > maxOccurs="1"> > > > minOccurs="1" maxOccurs="unbounded"/> > > type="string" use="required"/> > > > > use="optional" default="0"/> > use="optional"/> > type="fw:MethodListType" use="optional"/> > > > > -- 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-848) Generated stub for unbounded sequence of type any does not pass any elements to client
[ https://issues.apache.org/jira/browse/AXIS2C-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dimuthu Gamage updated AXIS2C-848: -- Attachment: any_test.tar.gz Fixed. Attachment contain the stub, skel source used to test. Thanks Dimuthu > Generated stub for unbounded sequence of type any does not pass any elements > to client > -- > > Key: AXIS2C-848 > URL: https://issues.apache.org/jira/browse/AXIS2C-848 > Project: Axis2-C > Issue Type: Bug > Components: code generation >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila parser, > libcurl, using WSDL2C from nightly build of 12/19/07 >Reporter: Bill Mitchell >Assignee: Dimuthu Gamage > Attachments: adb_exemplar_type0.c, adb_exemplar_type0.orig.c, > adb_exemplar_type0.single.c, adb_instance_type1.c, adb_instance_type1.orig.c, > any_test.tar.gz, case26.tar.gz, service.wsdl, unrolled.wsdl > > > Where a complexType is defined as an unbounded sequence of type any, as in > the wsdl fragment below, the generated stub implements no code to handle the > elements themselves, with the comment that it is "imposible to handle the > request type - so please do it manually". Yet, for the same sequence with a > maxOccurs = 1, the generated stub is perfectly willing to return the single > element of type any in a property of type axiom_node_t *, by detaching the > node from the response document and making it a property of the stub object. > It would be useful and reasonable in the case of multiple any items to return > an array of axiom_node_t*, by detaching each from the response message, as is > done in the case of a single any element. > > > > > > maxOccurs="1"> > > > minOccurs="1" maxOccurs="unbounded"/> > > type="string" use="required"/> > > > > use="optional" default="0"/> > use="optional"/> > type="fw:MethodListType" use="optional"/> > > > > -- 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-826) Generated deserialize method does not handle a nested in a
[
https://issues.apache.org/jira/browse/AXIS2C-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dimuthu Gamage resolved AXIS2C-826.
---
Resolution: Fixed
Fixed in the Axis2/Java SVN. (Revision 607594)
> Generated deserialize method does not handle a nested in a
> --
>
> Key: AXIS2C-826
> URL: https://issues.apache.org/jira/browse/AXIS2C-826
> Project: Axis2-C
> Issue Type: Improvement
> Components: code generation
>Reporter: Michael Mole
>Assignee: Dimuthu Gamage
> Attachments: choice_test.tar.gz
>
>
> I have a schema with a complex type as follows:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> The generated deserialize method looks like this (this is a snippet):
>/*
> * because elements are not ordered we should
> surf all the sibling to pick the right one
> */
>for (current_node = first_node; current_node
> != NULL;
> current_node =
> axiom_node_get_next_sibling(current_node, env))
>{
> current_element = (axiom_element_t
> *)axiom_node_get_data_element(current_node, env);
> qname =
> axiom_element_get_qname(current_element, env, current_node);
>
> element_qname = axutil_qname_create(env,
> "FooResponseSequence_type0", "http://ibm.com/ws";, NULL);
> if (axutil_qname_equals(element_qname, env,
> qname))
> {
>/* found the requried element */
>break;
> }
>}
> The generated code is looking for the a qname containing
> "FooResponseSequence_type0" which is the generated name for the adb sequence
> struct. It should not be looking for this though. It should actually be
> looking for the first element in the sequence, "changed-value".
> Admittedly, I don't know exactly how this should be formed, but I printed up
> the value of qname and it looks like this: changed-value|http://ibm.com/ws|WSX
> Please let me know if further explanation is needed, and I'll try to supply
> more.
--
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-826) Generated deserialize method does not handle a nested in a
[
https://issues.apache.org/jira/browse/AXIS2C-826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dimuthu Gamage updated AXIS2C-826:
--
Attachment: choice_test.tar.gz
The wsdl in the attached gzip (case27/res/Choice_new.wsdl) contain all the
scenarios mentioned in the JIRA. Please reopen this JIRA, if this doesnt work
for other scenarios related with 'choice' elements.
Thanks
Dimuthu
> Generated deserialize method does not handle a nested in a
> --
>
> Key: AXIS2C-826
> URL: https://issues.apache.org/jira/browse/AXIS2C-826
> Project: Axis2-C
> Issue Type: Improvement
> Components: code generation
>Reporter: Michael Mole
>Assignee: Dimuthu Gamage
> Attachments: choice_test.tar.gz
>
>
> I have a schema with a complex type as follows:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> The generated deserialize method looks like this (this is a snippet):
>/*
> * because elements are not ordered we should
> surf all the sibling to pick the right one
> */
>for (current_node = first_node; current_node
> != NULL;
> current_node =
> axiom_node_get_next_sibling(current_node, env))
>{
> current_element = (axiom_element_t
> *)axiom_node_get_data_element(current_node, env);
> qname =
> axiom_element_get_qname(current_element, env, current_node);
>
> element_qname = axutil_qname_create(env,
> "FooResponseSequence_type0", "http://ibm.com/ws";, NULL);
> if (axutil_qname_equals(element_qname, env,
> qname))
> {
>/* found the requried element */
>break;
> }
>}
> The generated code is looking for the a qname containing
> "FooResponseSequence_type0" which is the generated name for the adb sequence
> struct. It should not be looking for this though. It should actually be
> looking for the first element in the sequence, "changed-value".
> Admittedly, I don't know exactly how this should be formed, but I printed up
> the value of qname and it looks like this: changed-value|http://ibm.com/ws|WSX
> Please let me know if further explanation is needed, and I'll try to supply
> more.
--
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-860) generated message stubs omit code for attributes in a named attribute group
generated message stubs omit code for attributes in a named attribute group --- Key: AXIS2C-860 URL: https://issues.apache.org/jira/browse/AXIS2C-860 Project: Axis2-C Issue Type: Bug Components: code generation Affects Versions: Current (Nightly) Environment: Windows XP, Visual Studio 2005, libxml, libcurl Reporter: Bill Mitchell Priority: Minor Attachments: service.wsdl, unrolled_attrgrp.wsdl When a message has attributes defined via an AttributeGroup, no properties are generated in the stubs that reflect the attributes. If the attributes are defined directly in the message without using a group, everything works fine. For example, in my service.wsdl file there is a response message defined, in part, by: No properties for responseCode nor ResponseMessage appear in the generated adb_getExemplarResponseType.c. If the attributes are replicated in each message rather than using an AttributeGroup, as below, the generated stub has all the properties: -- 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-860) generated message stubs omit code for attributes in a named attribute group
[ https://issues.apache.org/jira/browse/AXIS2C-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-860: - Attachment: unrolled_attrgrp.wsdl service.wsdl For the attached service.wsdl, the generated stubs omit the properties for the attributes in the attribute group. For the attached unrolled_attrgrp.wsdl, that differs only by including the attributes inline instead of in a group, the generated stubs are complete. > generated message stubs omit code for attributes in a named attribute group > --- > > Key: AXIS2C-860 > URL: https://issues.apache.org/jira/browse/AXIS2C-860 > Project: Axis2-C > Issue Type: Bug > Components: code generation >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, libxml, libcurl >Reporter: Bill Mitchell >Priority: Minor > Attachments: service.wsdl, unrolled_attrgrp.wsdl > > > When a message has attributes defined via an AttributeGroup, no properties > are generated in the stubs that reflect the attributes. If the attributes > are defined directly in the message without using a group, everything works > fine. > For example, in my service.wsdl file there is a response message defined, in > part, by: > > > > > > > > use="optional"/> > > > > > default="0"/> > > > No properties for responseCode nor ResponseMessage appear in the generated > adb_getExemplarResponseType.c. > If the attributes are replicated in each message rather than using an > AttributeGroup, as below, the generated stub has all the properties: > > > > > > > default="0"/> > use="optional"/> > use="optional"/> > > > -- 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-848) Generated stub for unbounded sequence of type any does not pass any elements to client
[ https://issues.apache.org/jira/browse/AXIS2C-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bill Mitchell updated AXIS2C-848: - Attachment: service.wsdl > Generated stub for unbounded sequence of type any does not pass any elements > to client > -- > > Key: AXIS2C-848 > URL: https://issues.apache.org/jira/browse/AXIS2C-848 > Project: Axis2-C > Issue Type: Bug > Components: code generation >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila parser, > libcurl, using WSDL2C from nightly build of 12/19/07 >Reporter: Bill Mitchell >Assignee: Dimuthu Gamage > Attachments: adb_exemplar_type0.c, adb_exemplar_type0.orig.c, > adb_exemplar_type0.single.c, adb_instance_type1.c, adb_instance_type1.orig.c, > case26.tar.gz, service.wsdl, unrolled.wsdl > > > Where a complexType is defined as an unbounded sequence of type any, as in > the wsdl fragment below, the generated stub implements no code to handle the > elements themselves, with the comment that it is "imposible to handle the > request type - so please do it manually". Yet, for the same sequence with a > maxOccurs = 1, the generated stub is perfectly willing to return the single > element of type any in a property of type axiom_node_t *, by detaching the > node from the response document and making it a property of the stub object. > It would be useful and reasonable in the case of multiple any items to return > an array of axiom_node_t*, by detaching each from the response message, as is > done in the case of a single any element. > > > > > > maxOccurs="1"> > > > minOccurs="1" maxOccurs="unbounded"/> > > type="string" use="required"/> > > > > use="optional" default="0"/> > use="optional"/> > type="fw:MethodListType" use="optional"/> > > > > -- 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] Reopened: (AXIS2C-848) Generated stub for unbounded sequence of type any does not pass any elements to client
[
https://issues.apache.org/jira/browse/AXIS2C-848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bill Mitchell reopened AXIS2C-848:
--
On a more recent build, I have verified that there is no compilation error in
the generated stub for the unrolled.wsdl. Thanks, Dimuthu. So I tried going
back to the original service.wsdl to see if all the problems are fixed there as
well. Although in the case of anonymous types the code is correct, there is
still a problem with named types.
The new code for the anonymous type in adb_instance_type1.c is:
{
axiom_node_t *current_property_node = current_node;
current_node = axiom_node_get_next_sibling(current_node, env);
axiom_node_detach(current_property_node, env);
axutil_array_list_add_at(arr_list, env, i,
(void*)current_property_node);
}
When I generate effectively the same service from service.wsdl, I see in
adb_InstanceType.c:
{
axiom_node_t *current_property_node = current_node;
current_node = axiom_node_get_next_sibling(current_node, env);
axiom_node_detach(current_property_node, env);
axutil_array_list_add_at(arr_list, env, i,
(void*)current_property_node);
status = adb_InstanceType_set_extraElement(_InstanceType, env,
current_property_node);
}
The extra _set_extraElement call doesn't work, and fortunately doesn't compile.
> Generated stub for unbounded sequence of type any does not pass any elements
> to client
> --
>
> Key: AXIS2C-848
> URL: https://issues.apache.org/jira/browse/AXIS2C-848
> Project: Axis2-C
> Issue Type: Bug
> Components: code generation
>Affects Versions: Current (Nightly)
> Environment: Windows XP, Visual Studio 2005, guththila parser,
> libcurl, using WSDL2C from nightly build of 12/19/07
>Reporter: Bill Mitchell
>Assignee: Dimuthu Gamage
> Attachments: adb_exemplar_type0.c, adb_exemplar_type0.orig.c,
> adb_exemplar_type0.single.c, adb_instance_type1.c, adb_instance_type1.orig.c,
> case26.tar.gz, unrolled.wsdl
>
>
> Where a complexType is defined as an unbounded sequence of type any, as in
> the wsdl fragment below, the generated stub implements no code to handle the
> elements themselves, with the comment that it is "imposible to handle the
> request type - so please do it manually". Yet, for the same sequence with a
> maxOccurs = 1, the generated stub is perfectly willing to return the single
> element of type any in a property of type axiom_node_t *, by detaching the
> node from the response document and making it a property of the stub object.
> It would be useful and reasonable in the case of multiple any items to return
> an array of axiom_node_t*, by detaching each from the response message, as is
> done in the case of a single any element.
>
>
>
>
>
> maxOccurs="1">
>
>
> minOccurs="1" maxOccurs="unbounded"/>
>
> type="string" use="required"/>
>
>
>
> use="optional" default="0"/>
> use="optional"/>
> type="fw:MethodListType" use="optional"/>
>
>
>
>
--
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-855) Generated stubs leak memory associated with string/array properties
[
https://issues.apache.org/jira/browse/AXIS2C-855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12555011
]
Bill Mitchell commented on AXIS2C-855:
--
I regenerated with a new build and verified that the reset code is now correct
in all of them. Thanks.
> Generated stubs leak memory associated with string/array properties
> ---
>
> Key: AXIS2C-855
> URL: https://issues.apache.org/jira/browse/AXIS2C-855
> Project: Axis2-C
> Issue Type: Bug
> Components: code generation
>Affects Versions: Current (Nightly)
> Environment: Windows XP, Visual Studio 2005, guththila parser, libcurl
>Reporter: Bill Mitchell
>
> The generated adb__free methods leak memory associated with string or
> array properties, i.e., any property with associated memory. The free
> routine correctly calls the reset routine to actually free the memory. But
> the reset routine has an incorrectly written guard to verify its passed
> pointer, such that it always returns without freeing anything.
> Here is a sample of the generated reset routine for a constraint property
> that is a string.
>axis2_status_t AXIS2_CALL
>adb_conditionInstance_type0_reset_constraint(
>adb_conditionInstance_type0_t* _conditionInstance_type0,
>const axutil_env_t *env)
>{
>int i = 0;
>int count = 0;
>void *element = NULL;
>AXIS2_ENV_CHECK(env, AXIS2_FAILURE);
>AXIS2_PARAM_CHECK(env->error, _conditionInstance_type0,
> AXIS2_FAILURE);
>if(NULL != _conditionInstance_type0)
>{
>return AXIS2_FAILURE;
>}
> if(_conditionInstance_type0->property_constraint != NULL)
> {
> AXIS2_FREE(env-> allocator,
> _conditionInstance_type0->property_constraint);
> _conditionInstance_type0->property_constraint = NULL;
> }
> _conditionInstance_type0->is_valid_constraint = AXIS2_FALSE;
>return AXIS2_SUCCESS;
>}
> As you can see, after using AXIS2_PARAM_CHECK to return an error if the
> passed _conditionInstance_type0 pointer is zero, the generated code then
> returns an error if the pointer is nonzero. Although one could simply fix
> the != comparison to be ==, the second test is redundant thanks to the
> AXIS2_PARAM_CHECK and could best be removed entirely.
> This error is present in all of the adb__reset routines, but causes a
> memory leak only for types represented by allocated memory.
--
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: [Vote] [Axis2-C] Vote for Apache Axis2/C 1.2.0 Release - Take 2
Hi, I tested binary distribution on Ubuntu 7.10. Binary distribution worked well. All samples were successfully executed. But when trying to compile the source distribution following command ./axis2c_build.sh /home/milinda/axis2c-src-1.2.0/deploy failed with following error message. checking whether to build dynamic invocation client... yes checking To Use Axis2 C . This is a compulsory module to build Axis2 C samples... yes configure: error: could not find axis2. stop make: *** No targets specified and no makefile found. Stop. make: *** No rule to make target `install'. Stop. Also there were some error messages like this which I have never seen when building from the source: make[3]: Entering directory `/home/milinda/axis2c-src-1.2.0/util' Making all in src make[4]: Entering directory `/home/milinda/axis2c-src-1.2.0/util/src' Makefile:327: .deps/allocator.Plo: No such file or directory Makefile:328: .deps/array_list.Plo: No such file or directory Makefile:329: .deps/base64.Plo: No such file or directory Makefile:330: .deps/base64_binary.Plo: No such file or directory Makefile:331: .deps/class_loader.Plo: No such file or directory Makefile:332: .deps/date_time.Plo: No such file or directory Makefile:333: .deps/date_time_util.Plo: No such file or directory Makefile:334: .deps/dir_handler.Plo: No such file or directory Makefile:335: .deps/dll_desc.Plo: No such file or directory Makefile:336: .deps/duration.Plo: No such file or directory Makefile:337: .deps/env.Plo: No such file or directory Makefile:338: .deps/error.Plo: No such file or directory Makefile:339: .deps/file.Plo: No such file or directory Makefile:340: .deps/file_handler.Plo: No such file or directory Makefile:341: .deps/generic_obj.Plo: No such file or directory Makefile:342: .deps/hash.Plo: No such file or directory Makefile:343: .deps/linked_list.Plo: No such file or directory Makefile:344: .deps/log.Plo: No such file or directory Makefile:345: .deps/network_handler.Plo: No such file or directory Makefile:346: .deps/param.Plo: No such file or directory Makefile:347: .deps/param_container.Plo: No such file or directory Makefile:348: .deps/properties.Plo: No such file or directory Makefile:349: .deps/property.Plo: No such file or directory Makefile:350: .deps/qname.Plo: No such file or directory Makefile:351: .deps/rand.Plo: No such file or directory Makefile:352: .deps/stack.Plo: No such file or directory Makefile:353: .deps/stream.Plo: No such file or directory Makefile:354: .deps/string.Plo: No such file or directory Makefile:355: .deps/string_util.Plo: No such file or directory Makefile:356: .deps/thread_pool.Plo: No such file or directory Makefile:357: .deps/types.Plo: No such file or directory Makefile:358: .deps/uri.Plo: No such file or directory Makefile:359: .deps/url.Plo: No such file or directory Makefile:360: .deps/utils.Plo: No such file or directory Makefile:361: .deps/uuid_gen.Plo: No such file or directory Makefile:362: .deps/version.Plo: No such file or directory make[4]: *** No rule to make target `.deps/version.Plo'. Stop. make[4]: Leaving directory `/home/milinda/axis2c-src-1.2.0/util/src' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/milinda/axis2c-src-1.2.0/util' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/milinda/axis2c-src-1.2.0/util' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/milinda/axis2c-src-1.2.0' make: *** [all] Error 2 Making install in util make[1]: Entering directory `/home/milinda/axis2c-src-1.2.0/util' Making install in src make[2]: Entering directory `/home/milinda/axis2c-src-1.2.0/util/src' Makefile:327: .deps/allocator.Plo: No such file or directory Makefile:328: .deps/array_list.Plo: No such file or directory Makefile:329: .deps/base64.Plo: No such file or directory Makefile:330: .deps/base64_binary.Plo: No such file or directory Makefile:331: .deps/class_loader.Plo: No such file or directory Makefile:332: .deps/date_time.Plo: No such file or directory Makefile:333: .deps/date_time_util.Plo: No such file or directory Makefile:334: .deps/dir_handler.Plo: No such file or directory Makefile:335: .deps/dll_desc.Plo: No such file or directory Makefile:336: .deps/duration.Plo: No such file or directory Makefile:337: .deps/env.Plo: No such file or directory Makefile:338: .deps/error.Plo: No such file or directory Makefile:339: .deps/file.Plo: No such file or directory Makefile:340: .deps/file_handler.Plo: No such file or directory Makefile:341: .deps/generic_obj.Plo: No such file or directory Makefile:342: .deps/hash.Plo: No such file or directory Makefile:343: .deps/linked_list.Plo: No such file or directory Makefile:344: .deps/log.Plo: No such file or directory Makefile:345: .deps/network_handler.Plo: No such file or directory Makefile:346: .deps/param.Plo: No such file or directory Makefile:347: .deps/param_container.Plo: No such file or directory Makefile:348: .deps/properties.Plo: No such file or directory Makefile:349: .deps/prop
Re: [Vote] [Axis2-C] Vote for Apache Axis2/C 1.2.0 Release - Take 2
Hi, I tested the binary packages and they were working fine. But in the source package when I try to ./configure it in linux, I got the following error. config.status: error: cannot find input file: src/minizip/Makefile.in configure: error: ./configure failed for util There the minizip directory doesn't exist. It doesn't work with "./configure --with-archive=no" as well. Since it is hard-coded in the configure.ac. After copying the minizip directory I was able to build the source. So I think this should be fixed. Thanks Dimuthu. On Dec 30, 2007 8:30 AM, Damitha Kumarage <[EMAIL PROTECTED]> wrote: > Hi Devs, > > I have re-packaged and uploaded the Apache Axis2/C 1.2.0 release > artifacts at [1]. > The key used to sign the release artifacts can be found at [2]. > > The changes from the previous release artifacts are > 1. Compltely stripped binaries and all libraries(including services and > modules) in linux binary distribution. Previously they were > stripped using strip -g option or not stripped at all. > 2. Added axis configuration file into the linux binary distribution. > 3. Removed binaries from the samples folder of the linux binary > distribution. It should contain only sample source and > configuration/build files. > 4. Removed pkgconfig directory from the lib dir of the linux binary > distribution. > > Please test, review and vote on these latest release artifacts for > Apache Axis2/C 1.2.0 release. > > I have tested and reviewed them and here is my vote: +1 > > Thanks, > Damitha > > [1]http://people.apache.org/~damitha/release/axis2/1.2.0/ > [2]http://people.apache.org/~damitha/release/axis2/1.2.0/KEYS > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [jira] Created: (AXIS2C-859) guththila parser fails to handle escape sequences for ampersand, less than, greater than
> guththila parser fails to handle escape sequences for ampersand, less > than, greater than > > > Key: AXIS2C-859 > URL: https://issues.apache.org/jira/browse/AXIS2C-859 > Project: Axis2-C > Issue Type: Bug > Components: guththila > Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila parser, > libcurl > Reporter: Bill Mitchell > > > When an incoming message contains within text the escaped ampersand > sequence, "&", this sequence is being passed to the client as raw text > without being converted to the single ampersand character. Clearly, this > action must take place at the level of the parser, as only the parser > knows whether it is seeing simple text, and conversion is required, or > text embedded in a CDATA section, where conversion is not allowed. I have > tested the build with the libxml parser, and of course the libxml parser > behaves correctly: the text passed to the client contains only the single > ampersand character, not the escaped sequence. (See section 2.4 of XML > 1.0 spec.) > > Looking at the code, I expect the same problem occurs with all escaped > sequences, less than and greater than as well as ampersand, on both input > and output. I also don't see where CDATA sections are handled, but as I > am not seeing CDATA in the messages from the service I am hitting, I have > not tested this case. I'm +1 for a fix. It is the parser's responsibility to figure this out. Regards, Senaka > > -- > 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] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Proxy authentication
> Hi Devs, > > I was testing the proxy authentication functionality the other day and it > did > not work at all - I've tried to debug and it seemed to me that in the > http_sender.c the msg_ctx doesn't contain anymore the authentication > credentials - neither the ones from the config file nor the credentials > supplied via the API. > > Does someone have tried the proxy authentication stuff recently? > > Thanks, > Plamen Hi Plamen, We have added proxy authentication into the axis2/c svn head, and it will be available with axis2/c 1.2.0 AFAIK. If not please obtain a checkout from https://svn.apache.org/repos/asf/webservices/axis2/trunk/c. If you already have a checkout please update it to the latest revision. Then make sure to rebuild your source. There also is a sample, echo_blocking_auth (samples/user_guide/clients/echo_blocking_auth.c) that demonstrates proxy authentication as well as http basic authentication. Also please note that we have only added support for Basic Authentication and not Digest Authentication as yet. This applies both HTTP and Proxy Authentication schemes. Also, AFAIK, most of the changes that we added are backward compatible, and you should be able to see what you saw before in a debug session in most cases. We have tested proxy authentication against a SQUID proxy running on a remote machine, and http authentication against an APACHE server instance with authentication support. Also, note that you can find help on how to set-up proxy authentication on the Axis2/C Manual, which is not as yet published on the internet, but, which is found in the xdocs folder (xdocs/docs/axis2c_manual.html) of the svn checkout. The updated manual will be published on the internet once the 1.2.0 release as been made. If you find any further issues regarding this matter please let us know. Regards, Senaka. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
