Hi, after taking a closer look on how a bundle update in Karaf does work and how Camel handles the camel contexts I found the reason for why my update of the bundle containing the route didn't work :-)
Some details on this "issue" at first my route didn't contain the needed localWorkDirectory attribute. So I added this and updated my bundle in Karaf. As I thought the update of the bundle does a clean installation of it. But since the camel-context is held (better referenced) by the camel-core bundle this update just didn't help any on my impression of updating the camel-context/route. So instead of trashing the data folder and doing a restart a bundle:refresh on camel-core would have worked already ... It's very logic that it behaves this way but it's not intuitive :) Maybe this can be done differently in the future (have to think on how thought) regards, Achim 2012/10/25 Achim Nierbeck <[email protected]>: > Hmm, interesting ... > need to check the reason for this later ... > > I kept updating my bundle containing this route, which failed, so now > after your suggestion > I did a "clean" run (should have done that earlier, shame on me :) ) > and now it just consumes about 1.5 GB Heap :) > > wonder why it survived the update <bundle-id> > > thanks for giving pointing me that direction :) > I was so sure the update should/would work I didn't think of cleaning > the bundle cache directory. > > regards, Achim > > > 2012/10/25 Claus Ibsen <[email protected]>: >> Digged in the code. >> >> Somehow this returns false according to your stacktrace. So it goes >> for the retrieveFileToStreamInBody instead of the 1st method. >> Can you double check your endpoint is configured correctly. >> >> if (ObjectHelper.isNotEmpty(endpoint.getLocalWorkDirectory())) { >> // local work directory is configured so we should store >> file content as files in this local directory >> return retrieveFileToFileInLocalWorkDirectory(name, exchange); >> } else { >> // store file content directory as stream on the body >> return retrieveFileToStreamInBody(name, exchange); >> } >> >> >> >> On Thu, Oct 25, 2012 at 4:51 PM, Achim Nierbeck <[email protected]> >> wrote: >>> Hi, >>> >>> using Camel 2.10.2 >>> I have a ftp endpoint that downloads a couple of files from a remote >>> FTP server. >>> There are different files located on this server, some of them are >>> about 700 MB size. >>> Now every time I start the route for downloading it gives me a OOM >>> when trying to download this file. >>> The route is configured to use the *localWorkDirectory*. >>> Roughly the route does something like the following: >>> >>> from("ftp://server?noop=true&localWorkDirectory=/myTemp&sendEmptyMessageWhenIdle=true";) >>> .onException() >>> ... ommited the exception part .... >>> .onCompletion() >>> ... omitted the onCompletion part .... >>> .choice() >>> .when(body().isNull()) >>> .... stop the whole thing here ... >>> .otherwise() >>> .to("file:/dropItHere") >>> .setBody(constant("")) >>> .to("seda:doSomeLogging"); >>> >>> I tried to increase the memory up to 3GB for the Heap size with no luck. >>> >>> Following Stacktrace is logged: >>> Camel (rootContext) thread #28 - ftp://usrXXX@ServerXXXX/ >>> at java.lang.OutOfMemoryError.<init>()V (OutOfMemoryError.java:25) >>> at java.util.Arrays.copyOf([BI)[B (Arrays.java:2786) >>> at java.io.ByteArrayOutputStream.write([BII)V >>> (ByteArrayOutputStream.java:94) >>> at >>> org.apache.commons.net.io.Util.copyStream(Ljava/io/InputStream;Ljava/io/OutputStream;IJLorg/apache/commons/net/io/CopyStreamListener;Z)J >>> (Util.java:123) >>> at >>> org.apache.commons.net.ftp.FTPClient._retrieveFile(Ljava/lang/String;Ljava/lang/String;Ljava/io/OutputStream;)Z >>> (FTPClient.java:1695) >>> at >>> org.apache.commons.net.ftp.FTPClient.retrieveFile(Ljava/lang/String;Ljava/io/OutputStream;)Z >>> (FTPClient.java:1669) >>> at >>> org.apache.camel.component.file.remote.FtpOperations.retrieveFileToStreamInBody(Ljava/lang/String;Lorg/apache/camel/Exchange;)Z >>> (FtpOperations.java:328) >>> at >>> org.apache.camel.component.file.remote.FtpOperations.retrieveFile(Ljava/lang/String;Lorg/apache/camel/Exchange;)Z >>> (FtpOperations.java:297) >>> at >>> org.apache.camel.component.file.GenericFileConsumer.processExchange(Lorg/apache/camel/Exchange;)V >>> (GenericFileConsumer.java:317) >>> at >>> org.apache.camel.component.file.remote.RemoteFileConsumer.processExchange(Lorg/apache/camel/Exchange;)V >>> (RemoteFileConsumer.java:94) >>> at >>> org.apache.camel.component.file.GenericFileConsumer.processBatch(Ljava/util/Queue;)I >>> (GenericFileConsumer.java:189) >>> at org.apache.camel.component.file.GenericFileConsumer.poll()I >>> (GenericFileConsumer.java:155) >>> at org.apache.camel.impl.ScheduledPollConsumer.doRun()V >>> (ScheduledPollConsumer.java:139) >>> at org.apache.camel.impl.ScheduledPollConsumer.run()V >>> (ScheduledPollConsumer.java:91) >>> >>> >>> The attached OOM-Camel.PNG shows what the Memory Analysis tells me. >>> >>> Am I missing something critical here? Or do I have to tune up the >>> memory for those kind >>> of cases? >>> >>> >>> Thanks and regards, Achim >>> -- >>> >>> Apache Karaf <http://karaf.apache.org/> Committer & PMC >>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> >>> Committer & Project Lead >>> OPS4J Pax for Vaadin >>> <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project >>> Lead >>> blog <http://notizblog.nierbeck.de/> >> >> >> >> -- >> Claus Ibsen >> ----------------- >> Red Hat, Inc. >> FuseSource is now part of Red Hat >> Email: [email protected] >> Web: http://fusesource.com >> Twitter: davsclaus >> Blog: http://davsclaus.com >> Author of Camel in Action: http://www.manning.com/ibsen > > > > -- > > Apache Karaf <http://karaf.apache.org/> Committer & PMC > OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> > Committer & Project Lead > OPS4J Pax for Vaadin > <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project > Lead > blog <http://notizblog.nierbeck.de/> -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project Lead blog <http://notizblog.nierbeck.de/>
