InOnly is just setting the Message Exchange pattern, I don't think it will effect the completions handing over things.
BTW, If we don't hand over the completions, we still find a way to call the onComplete method. In most case, the user doesn't need to know any thing about it, but if there are some transaction work need to do, the onComplete method is a good start point. How about we add a option to let the Seda or VM endpoint to call the onComplete method once it send the exchange to the queue? -- Willem Jiang Red Hat, Inc. FuseSource is now part of Red Hat Web: http://www.fusesource.com | http://www.redhat.com Blog: http://willemjiang.blogspot.com (http://willemjiang.blogspot.com/) (English) http://jnn.iteye.com (http://jnn.javaeye.com/) (Chinese) Twitter: willemjiang Weibo: 姜宁willem On Monday, February 25, 2013 at 10:11 PM, Raul Kripalani wrote: > > > > > > > > The safest option is to convert the body to a String, and either use the > > > threads DSL or inOnly(vm:...) to modify the exchange pattern onwards. > > > > > > I've converted the body to a String, and then send the exchange to vm > > endpoint using in only patters. At this point I expected to use VM endpoint > > as an inmemory VM queue for exchanges, but cannot do that, because the > > completions are also handled to that queue. Do I miss something here? > > > > > That sounds fishy. Functionally speaking, I'd expect an InOnly dispatch to > not hand over any completions, as we explicitly tell Camel we don't care > what happens thereafter by using inOnly(); but then again, on some level > it's sensible to provide the guarantee that whatever is behind the VM > endpoint won't find an incoherent state whenever it executes. > > If this is really like this, it would make sense to add a > handoverCompletions option to the Seda endpoint. > > For your immediate problem, did you try using the threads() DSL? > > Regards, > > *Raúl Kripalani* > Apache Camel Committer > Enterprise Architect, Program Manager, Open Source Integration specialist > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani > http://blog.raulkr.net | twitter: @raulvk <http://twitter.com/raulvk> > > On Mon, Feb 25, 2013 at 11:21 AM, Bilgin Ibryam <bibr...@gmail.com > (mailto:bibr...@gmail.com)> wrote: > > > On 25 February 2013 10:45, Raul Kripalani <r...@evosent.com > > (mailto:r...@evosent.com)> wrote: > > > > > Well, it's not safe to execute the completions before the Vm consumer has > > > finished processing, because the InputStream could be closed by the time > > > the Vm consumer starts processing the exchange. > > > > > > I agree with Willem that the current implement is correct. > > > > I see, you both are right here, but what I actually do is exactly your > > example below: > > > > > > > > > > The safest option is to convert the body to a String, and either use the > > > threads DSL or inOnly(vm:...) to modify the exchange pattern onwards. > > > > > > I've converted the body to a String, and then send the exchange to vm > > endpoint using in only patters. At this point I expected to use VM endpoint > > as an inmemory VM queue for exchanges, but cannot do that, because the > > completions are also handled to that queue. Do I miss something here? > > > > Thanks for your help guys. > > Bilgin > > > > > > > Raúl. > > > On 21 Feb 2013 17:13, "Bilgin Ibryam" <bibr...@gmail.com > > > (mailto:bibr...@gmail.com)> wrote: > > > > > > > Hi, > > > > > > > > I have a route where I consume from a file endpoint and put them in VM > > > > endpoint, so that another camel route from different camel app can > > > > > > > > > process > > > > it a little later asynchronously. > > > > > > > > The file endpoint has move=processed for removing the processed files, > > > but > > > > even the exchanges are delivered to VM endpoint, the exchange is not > > > > considered completed, so the original file stays locked and cannot > > > > > > > > > process > > > > other files before I start the second camel application and process the > > > > exchanges from VM endpoint. > > > > > > > > SEDA has waitForTaskToComplete option, which controls whether the > > caller > > > > should wait for the async task to complete or not before continuing. > > > > > > > > > But > > > > even when waitForTaskToComplete=Never is set, the completions are > > > > > > > > > handed > > > > over to VM queue, so it is not possible to complete the exchange. > > > > > > > > Is there a way to complete the exchange when it is put in VM queue? Or > > > > there is a possibility for extending SEDA component with additional > > > > > > > > > option > > > > for not handling over the completions when waitForTaskToComplete=Never > > > > > > > > > is > > > > set? > > > > > > > > WDYT > > > > Bilgin > > > > > >
