camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Edoardo Causarano <>
Subject Re: OOMs with Dropbox Camel module
Date Thu, 17 Nov 2016 21:38:50 GMT
Hi there, I've done some work on this but I'd like to know a couple things

Should I branch from master and you take care of cherry picking?

What language level should I use? Can I go with Java8?

Does it need to be 100% backwards compatible with the existing component?
Some of the headers in the current impl can be improved IMHO but current
usage would break if I changed them arbitrarily... is there a deprecation
mechanism for headers?

Advice on testing: Dropbox doesn't provide a testing module, is there a
robust way to create a test harness? Some sort of record/replay tool


On Thu, 10 Nov 2016 at 14:56, Claus Ibsen <> wrote:

> Hi
> Yeah you can take a look at how some of the dataformats does that as
> they have out of bands streaming support with Camel's stream caching
> We love contributions, so you are very welcome to look into this and
> provide a PR / patch. And to log a JIRA ticket.
> On Thu, Nov 10, 2016 at 11:50 AM, Edoardo Causarano
> <> wrote:
> > Hi all,
> >
> > just moved code from dev to testing and found that in real-life the
> DropBox component blows apart in OOMs. Seems that it’s using plain BAOS
> (sic) to buffer remote data which is not a particularly good idea when you
> have no idea how big the files will be (or you’re pretty certain they’re in
> the multiple GB range.)
> >
> > I’d rather not implement a client from scratch so I’d appreciate some
> guidance on how to fix the existing camel-dropbox component to use
> stream-caching.
> >
> >
> > Best,
> > Edoardo
> --
> Claus Ibsen
> -----------------
> @davsclaus
> Camel in Action 2:

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