Uploaded image for project: 'Camel'
  1. Camel
  2. CAMEL-9202

Flatpack: Body reader never closed

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Resolved
    • Major
    • Resolution: Fixed
    • 2.14.3
    • 2.15.5, 2.16.2, 2.17.0
    • camel-flatpack
    • None
    • Novice

    Description

      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

      Attachments

        1. patchfile.diff
          11 kB
          MykhailoVlakh
        2. patchfile2.diff
          3 kB
          MykhailoVlakh

        Issue Links

          Activity

            People

              davsclaus Claus Ibsen
              mvlakh MykhailoVlakh
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: