camel-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "MykhailoVlakh (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CAMEL-9202) Flatpack: Body reader never closed
Date Thu, 08 Oct 2015 15:38:26 GMT
MykhailoVlakh created CAMEL-9202:
------------------------------------

             Summary: Flatpack: Body reader never closed 
                 Key: CAMEL-9202
                 URL: https://issues.apache.org/jira/browse/CAMEL-9202
             Project: Camel
          Issue Type: Bug
    Affects Versions: 2.14.3
            Reporter: MykhailoVlakh


Hello Camel team,

First of all I want to thank you for all great work you do to provide such a powerful tool
as Camel. I really enjoy using it in my work. 

Currently I am working on an application that requires delimited and fixed width parsing tools
and I decided to use Camel Flatpack because we already use some other Camel stuff. We use
Camel 2.14.3 which is not the latest one but forks fine. During my work with Flatpack consumer
I found several issues and some room for improvements and I decided to share my thoughts/findings
with you. Our team have plans to migrate to the latest version of Camel in near future and
we all will be happy if the new version includes fixes/improvements that I am goint to suggest.

The main issue that I found is that flatpack endpoint does not close body reader if an exception
is thrown during parser creation step. As a result the related resource remains opened forever.
For example in my cases when PZMAP files was missing my data file (csv file) was locked and
my file consumer ended in endless loop in which it was trying to move a file to .error folder
but was not able to do this because the file was opened for read.

Another problem that I noticed is that I cannot use allowShortLines and ignoreExtraColumns
attributes if my parser uses inline headers from files. Flatpack simply ignores them in this
case.

Finally I think that there is some  room for improvements:
* It would be nice to have a possibility to provide PZMAP as a bean via JNDI context instead
of having to generate a file. This feature will be very useful and content parsing should
work faster because the XML will be read from memory instead of reading it from a file each
time you parse some content;
* It would be nice to have a possibility to provide content format as an URI attribute instead
of using these ugly URI prefixes that we should use right now. With such possibility in plase
URI will look the same all the time and developers won't need to reformat URI differently
for different content types.

I attached a patch file with code fragments and comments to them that illustrate my findings/thoughts.
Unformtunatelly I don't have enough time to provide real fixes and unit tests so please excuse
me for this. 

Please let me know if something is unclear or require more details.

Looking forward for your feedback,
Mykhailo



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message