camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Tombs <cyan.s...@gmail.com>
Subject Re: Freeing objects returned by type converter
Date Fri, 07 Jan 2011 16:45:18 GMT
On Fri, Jan 7, 2011 at 10:39 AM, Claus Ibsen <claus.ibsen@gmail.com> wrote:

>  On Fri, Jan 7, 2011 at 4:14 PM, David Tombs <cyan.spam@gmail.com> wrote:
> > On 1/7/11, James Strachan <james@fusesource.com> wrote:
> >> On 7 January 2011 14:51, David Tombs <cyan.spam@gmail.com> wrote:
> >>> Hello all,
> >>>
> >>> I have recently started using camel and it's fantastic. Thanks for all
> >>> your hard work, committers.
> >>
> >> Thanks!
> >>
> >>> One issue I came across is whether I should free or close objects
> >>> returned by a type converter. For example, I have a class that reads
> >>> some binary data from an InputStream so I wrote a custom Processor
> >>> that does this:
> >>>
> >>> InputStream productStream =
> exchange.getIn().getBody(InputStream.class);
> >>>
> >>> It appears that I need to call close() on productStream or else my
> >>> file consumer was leaving open handles to the source files. Is this
> >>> always the case? If the body was already an InputStream, would calling
> >>> close() be harmful? Am I doing something wrong?
> >>>
> >>> I couldn't find anything in the documentation regarding this--type
> >>> converters were always used to convert to Strings in examples.
> >>
> >> Once you've created the stream, its up to you to close it. So you
> >> might want to create a little helper class to make sure you always
> >> call close on it. I guess we could add a little helper class to Camel
> >> to make it a bit easier to use streams and ensure they get closed.
> >>
> >> --
> >>
> >> --
> >> James
> >
> > Thanks for the quick reply, James.
> >
> > One remaining question: how does this work if the body was already an
> > InputStream? Would a type converter even be used in that case? Would
> > the IS I get back be a clone of the "real" IS or something like that?
> >
>
> If the body is already the type you want to convert to, then its returned
> as is.


Then is closing it is harmful.

I just tested converting the body to an InputStream before sending it to my
Processor as below:

         <from
uri="file:messages/radarIn?delete=true&amp;exclude=.*.tmp&amp;readLock=none"
/>
         <convertBodyTo type="java.io.InputStream" />
         <!-- Add dynamic routing properties -->
         <process ref="radarPropertyAdder" />
         <to uri="jms:topic:HPWC.IN?testConnectionOnStartup=true" />

The producer endpoint then kept throwing NullPointerExceptions.

So what's the general solution here? Does one have to figure out what type
the body will be then bake that assumption into the code? A more reasonable
alternative would be to have getBody() always return an object that the user
owns, but that would require cloning objects like InputStream that don't
support clone().

I suppose a workaround for now could be:

      if (productStream != exchange.getIn().getBody())
      {
         productStream.close();
      }

That should avoid the harmful close, right?

Thanks again,
David

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message