> > > > > 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> wrote: > On 25 February 2013 10:45, Raul Kripalani <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> 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 > > > > > >
