[jira] Created: (AXIS2C-1064) Errors written to the log file in param_container.c file
Errors written to the log file in param_container.c file - Key: AXIS2C-1064 URL: https://issues.apache.org/jira/browse/AXIS2C-1064 Project: Axis2-C Issue Type: Improvement Reporter: Manoj Pushpakumara Priority: Minor Attachments: param_container.diff Errors written to the log file and remove the spacing problem.Please review and apply the attached patch. -- 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-1064) Errors written to the log file in param_container.c file
[ https://issues.apache.org/jira/browse/AXIS2C-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manoj Pushpakumara updated AXIS2C-1064: --- Attachment: param_container.diff > Errors written to the log file in param_container.c file > - > > Key: AXIS2C-1064 > URL: https://issues.apache.org/jira/browse/AXIS2C-1064 > Project: Axis2-C > Issue Type: Improvement >Reporter: Manoj Pushpakumara >Priority: Minor > Attachments: param_container.diff > > > Errors written to the log file and remove the spacing problem.Please review > and apply the attached patch. -- 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: Caching support for large attachments
On Tue, 2008-03-18 at 03:49 +0530, Samisa Abeysinghe wrote: > Thilina Gunarathne wrote: > >> However, the real issue is how are we going to implement "parse it for > >> MIME, and then cache it and move on". I still think that it is better to > >> stick to Thilina's viewpoint in having each attachment cached as a > >> separate file. And, each attachment should be cached, even if it is small > >> or large, when the content-length exceeds the threshold. > >> > > What I proposed is not based on the content-length.. It's based on the > > size of a particular attachment. We calculate the size while parsing. > > If the size exceeds a certain limit then put everything to file. > > > > Also you might want to consider deferred parsing of attachments. That > > means read the attachment for the stream only when needed. Similar in > > concept to StAX parsing of XML. > > > > > >> This is because > >> many small attachments == one big attachment. > >> > > Good point.. > > > I do not think so. You do not get mime boundaries in the middle. So the > parsing and buffering implications are different. When there are multiple attachments don't you get mime boundaries in the middle of the message ? > > Samisa... > > > - > 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: Caching support for large attachments
Hi Samisa, Senaka and Thilina, These are my view points on caching and how it can be done in Axis2/C. For me the main purpose of caching is to support any size of attachment which depends only on the folder size the attachment is going to be stored. In the current implementation (Axis2/C 1.3) we read the whole message and parse. Before 1.3 the same thing was done (I mean always parse full buffers not partially read buffers) in a very inefficient manner. Now to implement caching we need to change the current logic. In simple steps these are the things we need to do. 1. First parse the part containing the soap-envelope 2. Then Read up to some threshold and search for the mime_boundary 3. If it is not found then move one half of the buffer to the file and append some content equal to that part from stream and parse The step 3 is needed because in case of multiple attachments the mime boundaries can be there in the middle of the message. We need above step to fully support caching when there are multiple attachments. If we assume we have only one attachment then we can write whole content without parsing after it exceeds a certain threshold. Otherwise we need step 3. So that will require to change the current logic. Above I described is option 1. Option 2 is as I suggested previously keep the current logic and after parsing if the attachment exceeds the limit write it to a file. Please read the first mail in this thread for more on this. But this will not achieve the main purpose of caching as I mentioned in the beginning. Thanks, -Manjula. On Tue, 2008-03-18 at 03:47 +0530, Samisa Abeysinghe wrote: > Senaka Fernando wrote: > >> Manjula Peiris wrote: > >> > >>> On Sun, 2008-03-16 at 16:26 +0530, Samisa Abeysinghe wrote: > >>> > >>> > >>> > We have an efficient parsing mechanism already, tested and proven to > work, with 1.3. Why on earth are we discussing this over and over > again? > > Does caching get affected by the mime parser logic? IMHO no. They are > two separate concerns, so ahy are we wasting time discussing parsing > while the problem at had is not parsing but caching? > > > >>> No, the current implementation starts parsing after reading the whole > >>> stream. Because of that the parsing is simple and efficient. And for > >>> considerable size of large attachments(eg : 100MB) also it is working > >>> well. The only problem it has is the attachment size will depend on the > >>> available system memory. > >>> > >>> > >> Still, my argument on the separation of concerns on caching vs. parsing > >> holds. > >> It is a question about what takes precedence over the other. If the > >> attachment is too large, we need to interleave the concepts, where you > >> read a considerable amount that is ideal in size in terms of caching, > >> parse it for MIME, and then cache it and move on. > >> > > > > Parsing will always be choice No. 1. We cache only if we can't handle it. > > > > However, the real issue is how are we going to implement "parse it for > > MIME, and then cache it and move on". I still think that it is better to > > stick to Thilina's viewpoint in having each attachment cached as a > > separate file. And, each attachment should be cached, even if it is small > > or large, when the content-length exceeds the threshold. This is because > > many small attachments == one big attachment. Thus, I'm still on the > > parse_1st->cache_1st->parse_2nd->cache_2nd->... approach. I don't think > > that a cache all at once will give us desirable results. > > > > I do not think you seem to understand what I am talking about. Seperate > attachments do need to go to seperate files. There is no question about > that. The queestion here is not about multiple attachments. The > question is about "very large attachment". > > Samisa... > > > > - > 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]
[jira] Resolved: (AXIS2C-1061) Ability for Simple Axis2 HTTP Server to specify Date and Server headers
[ https://issues.apache.org/jira/browse/AXIS2C-1061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Senaka Fernando resolved AXIS2C-1061. - Resolution: Fixed Fixed Issue > Ability for Simple Axis2 HTTP Server to specify Date and Server headers > --- > > Key: AXIS2C-1061 > URL: https://issues.apache.org/jira/browse/AXIS2C-1061 > Project: Axis2-C > Issue Type: Improvement > Components: transport/http >Affects Versions: Current (Nightly) >Reporter: Senaka Fernando >Assignee: Senaka Fernando > Fix For: Current (Nightly) > > > Ability for Simple Axis2 HTTP Server to specify Date and Server headers. The > Apache Module already has this support. -- 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: [jira] Updated: (AXIS2C-1062) modified the network_handler.c file
Hi Manoj, When creating a JIRA please try to be specific about the JIRA summary, In this case you could have been more specific about the change. thanks, Dinesh "Manoj Pushpakumara (JIRA)" <[EMAIL PROTECTED]> writes: > [ > https://issues.apache.org/jira/browse/AXIS2C-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel > ] > > Manoj Pushpakumara updated AXIS2C-1062: > --- > > Attachment: network_handler.diff > >> modified the network_handler.c file >> --- >> >> Key: AXIS2C-1062 >> URL: https://issues.apache.org/jira/browse/AXIS2C-1062 >> Project: Axis2-C >> Issue Type: Improvement >>Reporter: Manoj Pushpakumara >>Priority: Minor >> Attachments: network_handler.diff >> >> >> modified the network_handler.c file. Please view and apply the attached >> patch. > > -- > 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] > -- http://nethu.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Caching support for large attachments
> Well, the Java folks have the luxury of streams. C has to manage this at > socket level. So my question was, how are we supposed to do that with C > network handler? I'm not familiar with the workings of the C network handler. But for us the only useful part of the input stream was the read() method, which returns the filtered bytes according to the function of the wrapper.. I'm sure you smart people would be able to simulate that easily.. ~Thilina > > Samisa... > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Thilina Gunarathne - http://thilinag.blogspot.com
Re: Caching support for large attachments
Thilina Gunarathne wrote: >> Also you might want to consider deferred parsing of attachments. That >> means read the attachment for the stream only when needed. This is what the Java does. That's why I proposed you people to consider doing it in C :).. In Axis2/Java we first parse only the SOAP part (MIME part containing the SOAP envelope) and build the OM tree. when building we create place holder OMText elements whenever we encounter elements. These OMText's contain the content-id for the attachment, which will be used when buildWithAttachments() or getDataHandler() is called on these objects. At that point we parse the rest of the MIME message up to that particular attachment and return the datahandler for that. Also in Axis2/Java we placed the attachment caching code in between the builder.getDataHandler() method presented to the Axis2 engine and the MIME parser. The MIME parser, which has a InputStream interface, returns data belongs to a Have a look at the following.. http://svn.apache.org/viewvc/webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/attachments/Attachments.java?view=markup specifically the getPart() method. Our MIME parsing logic is effectively a set of InputStream wrappers.* MIMEBodyPartInputStream which is at the end of this set of wrappers only returns bytes belongs to a particular MIME part. We cache the data which we get through this Stream, in other words already parsed MIME part. * Well, the Java folks have the luxury of streams. C has to manage this at socket level. So my question was, how are we supposed to do that with C network handler? Samisa... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Caching support for large attachments
>> Also you might want to consider deferred parsing of attachments. That > >> means read the attachment for the stream only when needed. > > This is what the Java does. That's why I proposed you people to consider doing it in C :).. In Axis2/Java we first parse only the SOAP part (MIME part containing the SOAP envelope) and build the OM tree. when building we create place holder OMText elements whenever we encounter elements. These OMText's contain the content-id for the attachment, which will be used when buildWithAttachments() or getDataHandler() is called on these objects. At that point we parse the rest of the MIME message up to that particular attachment and return the datahandler for that. Also in Axis2/Java we placed the attachment caching code in between the builder.getDataHandler() method presented to the Axis2 engine and the MIME parser. The MIME parser, which has a InputStream interface, returns data belongs to a Have a look at the following.. http://svn.apache.org/viewvc/webservices/commons/trunk/modules/axiom/modules/axiom-api/src/main/java/org/apache/axiom/attachments/Attachments.java?view=markup specifically the getPart() method. Our MIME parsing logic is effectively a set of InputStream wrappers.* MIMEBodyPartInputStream which is at the end of this set of wrappers only returns bytes belongs to a particular MIME part. We cache the data which we get through this Stream, in other words already parsed MIME part. thanks, Thilina * > How can you do this in C? > > Samisa... > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Thilina Gunarathne - http://thilinag.blogspot.com
Re: Caching support for large attachments
Also you might want to consider deferred parsing of attachments. That means read the attachment for the stream only when needed. This is what the Java does. How can you do this in C? Samisa... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Caching support for large attachments
Senaka Fernando wrote: Ideally it should be either the Content-Length or if Chunked then we'll have to read until the end of chunks. So, if you see Content-Length, then no need to calculate size while parsing. You already know it. But, your proposal is valid for the Chunked case. I'm talking about calculating the size for a individual MIME part.. I think I made it clear (+how we do it in Axis2/java) at the beginning of this thread... Probably you need to reread this thread. Yep, true. The point is, as I said earlier, several small attachments == one big attachment. Thus, Buffering will have to happen anyway, if the Content-Length exceeds the threshold rather than a single attachment exceeding the threshold. No this is a flawed view. You cannot overlay parsing and caching in the right manner with this view. We have parsing in place, what needs to be figured out is the overlay. We are going back and forth in this discussion and we are not addressing the real issue because the discussion is dragged over and over again into parsing problems. If there are parsing problems, could you please point out where they are exactly so that we can fix those and be done with it. Else we are wasting time on an already solved problem. Rather we should move and solve the problem at hand which is caching and overlaying it on current parsing logic. Samisa... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Caching support for large attachments
Thilina Gunarathne wrote: However, the real issue is how are we going to implement "parse it for MIME, and then cache it and move on". I still think that it is better to stick to Thilina's viewpoint in having each attachment cached as a separate file. And, each attachment should be cached, even if it is small or large, when the content-length exceeds the threshold. What I proposed is not based on the content-length.. It's based on the size of a particular attachment. We calculate the size while parsing. If the size exceeds a certain limit then put everything to file. Also you might want to consider deferred parsing of attachments. That means read the attachment for the stream only when needed. Similar in concept to StAX parsing of XML. This is because many small attachments == one big attachment. Good point.. I do not think so. You do not get mime boundaries in the middle. So the parsing and buffering implications are different. Samisa... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Caching support for large attachments
Senaka Fernando wrote: Manjula Peiris wrote: On Sun, 2008-03-16 at 16:26 +0530, Samisa Abeysinghe wrote: We have an efficient parsing mechanism already, tested and proven to work, with 1.3. Why on earth are we discussing this over and over again? Does caching get affected by the mime parser logic? IMHO no. They are two separate concerns, so ahy are we wasting time discussing parsing while the problem at had is not parsing but caching? No, the current implementation starts parsing after reading the whole stream. Because of that the parsing is simple and efficient. And for considerable size of large attachments(eg : 100MB) also it is working well. The only problem it has is the attachment size will depend on the available system memory. Still, my argument on the separation of concerns on caching vs. parsing holds. It is a question about what takes precedence over the other. If the attachment is too large, we need to interleave the concepts, where you read a considerable amount that is ideal in size in terms of caching, parse it for MIME, and then cache it and move on. Parsing will always be choice No. 1. We cache only if we can't handle it. However, the real issue is how are we going to implement "parse it for MIME, and then cache it and move on". I still think that it is better to stick to Thilina's viewpoint in having each attachment cached as a separate file. And, each attachment should be cached, even if it is small or large, when the content-length exceeds the threshold. This is because many small attachments == one big attachment. Thus, I'm still on the parse_1st->cache_1st->parse_2nd->cache_2nd->... approach. I don't think that a cache all at once will give us desirable results. I do not think you seem to understand what I am talking about. Seperate attachments do need to go to seperate files. There is no question about that. The queestion here is not about multiple attachments. The question is about "very large attachment". Samisa... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Resolved: (AXIS2C-1063) modified the md5.c file
[ https://issues.apache.org/jira/browse/AXIS2C-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Senaka Fernando resolved AXIS2C-1063. - Resolution: Fixed Fix Version/s: Current (Nightly) Assignee: Senaka Fernando Fixed Issue > modified the md5.c file > - > > Key: AXIS2C-1063 > URL: https://issues.apache.org/jira/browse/AXIS2C-1063 > Project: Axis2-C > Issue Type: Improvement >Reporter: Manoj Pushpakumara >Assignee: Senaka Fernando >Priority: Minor > Fix For: Current (Nightly) > > Attachments: md5.diff > > > modified the md5.c file. Please review and apply the patch. -- 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-1063) modified the md5.c file
modified the md5.c file - Key: AXIS2C-1063 URL: https://issues.apache.org/jira/browse/AXIS2C-1063 Project: Axis2-C Issue Type: Improvement Reporter: Manoj Pushpakumara Priority: Minor Attachments: md5.diff modified the md5.c file. Please review and apply the patch. -- 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-1063) modified the md5.c file
[ https://issues.apache.org/jira/browse/AXIS2C-1063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manoj Pushpakumara updated AXIS2C-1063: --- Attachment: md5.diff > modified the md5.c file > - > > Key: AXIS2C-1063 > URL: https://issues.apache.org/jira/browse/AXIS2C-1063 > Project: Axis2-C > Issue Type: Improvement >Reporter: Manoj Pushpakumara >Priority: Minor > Attachments: md5.diff > > > modified the md5.c file. Please review and apply the patch. -- 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-1062) modified the network_handler.c file
[ https://issues.apache.org/jira/browse/AXIS2C-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjaya Ratnaweera resolved AXIS2C-1062. Resolution: Fixed Fix Version/s: Current (Nightly) Patch applied. Thanks Manoj for the patch. > modified the network_handler.c file > --- > > Key: AXIS2C-1062 > URL: https://issues.apache.org/jira/browse/AXIS2C-1062 > Project: Axis2-C > Issue Type: Improvement >Reporter: Manoj Pushpakumara >Assignee: Sanjaya Ratnaweera >Priority: Minor > Fix For: Current (Nightly) > > Attachments: network_handler.diff > > > modified the network_handler.c file. Please view and apply the attached > patch. -- 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-1062) modified the network_handler.c file
[ https://issues.apache.org/jira/browse/AXIS2C-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sanjaya Ratnaweera reassigned AXIS2C-1062: -- Assignee: Sanjaya Ratnaweera > modified the network_handler.c file > --- > > Key: AXIS2C-1062 > URL: https://issues.apache.org/jira/browse/AXIS2C-1062 > Project: Axis2-C > Issue Type: Improvement >Reporter: Manoj Pushpakumara >Assignee: Sanjaya Ratnaweera >Priority: Minor > Attachments: network_handler.diff > > > modified the network_handler.c file. Please view and apply the attached > patch. -- 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-1062) modified the network_handler.c file
[ https://issues.apache.org/jira/browse/AXIS2C-1062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manoj Pushpakumara updated AXIS2C-1062: --- Attachment: network_handler.diff > modified the network_handler.c file > --- > > Key: AXIS2C-1062 > URL: https://issues.apache.org/jira/browse/AXIS2C-1062 > Project: Axis2-C > Issue Type: Improvement >Reporter: Manoj Pushpakumara >Priority: Minor > Attachments: network_handler.diff > > > modified the network_handler.c file. Please view and apply the attached > patch. -- 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-1062) modified the network_handler.c file
modified the network_handler.c file --- Key: AXIS2C-1062 URL: https://issues.apache.org/jira/browse/AXIS2C-1062 Project: Axis2-C Issue Type: Improvement Reporter: Manoj Pushpakumara Priority: Minor Attachments: network_handler.diff modified the network_handler.c file. Please view and apply the attached patch. -- 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]
Regarding Axis2C architecture
Hi All, Currently I am working on the Axis2c 1.2 to make it communicate with a legacy system. I have gone through the architecture given in the manual on the website. But from that I am not able to get the exact idea of the flow of the request. Kindly let me know the architecture of the Axis2 C and how the request flows from the client to the server and the response coming beck from the server to the client. Thanks in advance. Regards, Rinil Baxi
