[jira] Commented: (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:comment-tabpanel&focusedCommentId=12555247#action_12555247 ] Bill Mitchell commented on AXIS2C-848: -- I regenerated the stubs with the later build and the issue with named types has been resolved. 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] Commented: (AXIS2C-849) Generated stub for SimpleType List of String returns no contents
[ https://issues.apache.org/jira/browse/AXIS2C-849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12555246#action_12555246 ] Bill Mitchell commented on AXIS2C-849: -- Great, Dimuthu. I rebuilt the stubs, adapted my client to the changed names, and everything worked fine. I only used strtok() because the Microsoft Visual Studio documentation suggested it was thread safe, just not usable for different strings at the same time. That may be unique to Microsoft, though. Regardless of whether it is thread-safe, you are correct that it is not a good idea in a library routine where the client might be using strtok for his own purposes. So avoiding its use is a definite improvement. > Generated stub for SimpleType List of String returns no contents > > > Key: AXIS2C-849 > URL: https://issues.apache.org/jira/browse/AXIS2C-849 > Project: Axis2-C > Issue Type: Improvement > Components: code generation >Affects Versions: Current (Nightly) > Environment: Windows XP, Visual Studio 2005, guththila parser, > libcurl, WSDL2C from nightly build of 12/19/07 >Reporter: Bill Mitchell > Attachments: adb_MethodListType.c, adb_MethodListType.h, > adb_MethodListType.orig.c, simple_type_list.tar.gz, unrolled.wsdl > > > The WSDL fragment below illustrates a SimpleType declared as a list of > strings that is returned as an attribute in a response message. In the > generated stubs, the deserialize routine in adb_getExemplarResponse.c nicely > expects the MethodListType to deserialize the attribute string into an object > and stores the returned MethodListType object as a property of the response. > Yet the generated adb_MethodListType.c doesn't have any properties and has > essentially empty routines for the deserialize_from_string and > serialize_to_string procedures. > > > > ... > > > > > > 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-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&focusedCommentId=12555244#action_12555244 ] Manjula Peiris commented on AXIS2C-858: --- For the observations above my settings in the httpd.conf are the following. LoadModule axis2_module /usr/local/apache2/modules/mod_axis2.so Axis2RepoPath /home/manjula/axis2/c/deploy Axis2LogFile /tmp/axis2.log Axis2MaxLogFileSize 1 Axis2LogLevel 2 SetHandler axis2_module But when I changed the settings to the following the observations changed. Axis2MaxLogFileSize 10 Axis2LogLevel crit Now the request processing happened at the same speed and memory total usage remains between 85-90% when I ran mtom client with 4MB attachment in a loop from 3 shells. > 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] 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&focusedCommentId=12555245#action_12555245 ] Manjula Peiris commented on AXIS2C-858: --- Please note I am using Axis2/c from current svn. > 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] 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&focusedCommentId=12555243#action_12555243 ] Subra A Narayanan commented on AXIS2C-858: -- Samisa, I am Apache 2.0.61 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 >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] 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&focusedCommentId=12555242#action_12555242 ] Samisa Abeysinghe commented on AXIS2C-858: -- Manjula, what Axis2/C configurations are you having in your httpd.conf? > 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]
Re: [Vote] [Axis2-C] Vote for Apache Axis2/C 1.2.0 Release - Take 3
1. In the Generated site , it says Docs for 1.1.0 release. I think this should update in project.properties file. The fix for this is to update the axis2_version in project.properties file to 1.2.0 Thanks, Samisa... - 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 3
Hi, Damitha Kumarage <[EMAIL PROTECTED]> writes: > 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 only change from the previous release artifacts is fixing the > source build failure which was due to a mistake in the script I used > to build the source ribution. I see some minor mistakes in the documentation. I'm not sure whether they have any impact at all :) 1. In the Generated site , it says Docs for 1.1.0 release. I think this should update in project.properties file. 2. In generated site latest release stated as 1.1.0 3. In generated site project team is not completed. 4. In NOTICE file we need to add 2008 for copyright years. (I'm not very much sure about it , please correct me if I'm mistaken) 5. There is some commented phase information in axis2.xml that we ship with release, those information not related to Axis2/C. Eg: Although we don't ship RM (sandesha) with Axis2/C, that axis2.xml has some values (commented) related to RM. other than these minor issues it works well. Here is my +1 ! thanks, Dinesh - 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_12555208 ] Manjula Peiris commented on AXIS2C-858: --- I did some testing with the mtom sample in Axis2/c and Apache 2.6 . I consumed the mtom service in a loop with 3 shells . First I tested it with 4 MB attachments and noticed a significant memory growth. Following are some observations in my machine. 1. Before the loop memory usage is 29%, and it increased to 70% immediately after starting the loop. And it will grow up to 90% memory usage and request handling became very slow. The other thing is when I stopped the loop the memory usage is remained same and does not decreased. It only decreased when I stopped Apache server. 2. I did the same with simple axis2 server and memory usage remained between 40-43%. And there is no significant memory growth at the start of the loop. 3. I also tested Apache2 with a small attachment (<< 4MB) and the memory usage increased gradually , But not a significant increase at the start of the loop. BTW I didn't notice any crash in the server. But i think there is some memory leak in the axis2 httpd module. Valgrind output does not show any thing but I will try to find where the problem is. > 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]
