Re: RejectedExecutionException: Task rejected due queue size limit reached
You can try set a custom executorServiceRef on your error handler, by
default the maxQueueSize is 1000, mind that you don't run OOM.
Here's the relevant code and comments from DefaultThreadPoolFactory;
// need to wrap the thread pool in a sized to guard against the
problem that the
// JDK created thread pool has an unbounded queue (see class
javadoc), which mean
// we could potentially keep adding tasks, and run out of memory.
if (profile.getMaxPoolSize() 0) {
return new SizedScheduledExecutorService(answer,
profile.getMaxQueueSize());
} else {
return answer;
}
Taariq
On Thu, Feb 12, 2015 at 9:29 AM, Behrad behr...@gmail.com wrote:
I don't think it be a SEDA queue size problem, since my SEDA endpoint queue
size is a very big number in logs, there should be something with
redelivery/errorHandler task queue !?
2015-02-12 10:23 GMT+03:30 Taariq Levack taar...@gmail.com:
Hi
SEDA queue size is unbounded by default, you can try the unit test[1]
with
a very large number, works for me in 2.14.1 and trunk.
Check all your endpoints with that name, the first one to load is setting
the size.
[1]
https://github.com/apache/camel/blob/master/camel-core/src/test/java/org/apache/camel/component/seda/SedaDefaultUnboundedQueueSizeTest.java
Taariq
On Thu, Feb 12, 2015 at 7:33 AM, Behrad behr...@gmail.com wrote:
When my SEDA producer peaks seems I'm getting ExecusionService queue
limit
with this trace:
at
org.apache.camel.util.concurrent.SizedScheduledExecutorService.schedule(SizedScheduledExecutorService.java:74)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:367)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at org.apache.camel.processor.Pipeline.process(Pipeline.java:118)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.ChoiceProcessor.process(ChoiceProcessor.java:111)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.idempotent.IdempotentConsumer.process(IdempotentConsumer.java:123)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at org.apache.camel.processor.Pipeline.process(Pipeline.java:118)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.component.seda.SedaConsumer.sendToConsumers(SedaConsumer.java:291)
[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.component.seda.SedaConsumer.doRun(SedaConsumer.java:200)
[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.component.seda.SedaConsumer.run(SedaConsumer.java:147)
[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[na:1.8.0]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[na:1.8.0]
at java.lang.Thread.run(Thread.java:744) [na:1.8.0]
How can I config the task queue bigger or disable the limit? 150K
messages
seems not that big to me :(
--
--Behrad
--
--Behrad
Camel java dsl: try/catch+stop = finally is not evaluated
I'm thinking to stop execution in case of exception, but I do want to perform some logging in finally block. The .stop() definition looks like does what I need but it stops finally definition as well. https://github.com/vasilievip/camel-spring-boot/blob/master/src/main/java/cameltest/CamelConfiguration.java#L35 Is this expected behavior? Am I missing something? Thanks -- View this message in context: http://camel.465427.n5.nabble.com/Camel-java-dsl-try-catch-stop-finally-is-not-evaluated-tp5762683.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: request-reply with ActiveMQ and Camel
Thanks for the replies Camel is only used to consume the request queue and post the replies, the requestor is a .NET app based on NMS and the aggregation part works fine as the setup works fine when using a standard queue on JMSReplyTo header: camel is sending the multiple replies to the queue and the requestor (.net) receives/aggregates them. At the moment the request is processed using InOut, the processing of the exchange is creating a DefaultProducer to send all chunks of the reply up to the second-last and the last is sent using standard routing. the problem occurs when qualifying a temporary queue as JMSReplyTo as the consumer is only receiving the last chunk (the one pushed by InOut routing), I've figured out the remaining messages (1:N-1) where being sent to a standard queue named temp-queue://ID:crive-50476-635594189841567445-1:0:1 so I thought camel was not interpreting correctly the destination prefix when used in my producer template. I than changed it so it was using camel temp queue naming by using a string replace so that the producer template could use temp:queue: instead of temp-queue://, so in my example the destination would have been: temp:queue:ID:crive-50476-635594189841567445-1:0:1. By looking into the logs I can see the producer sending messages to a different temp queue temp-queue://ID:crive-50473-1423818570510-3:1:1. It looks like camel generates a new temporary queue name for some reason endpoint uri: temp:queue:ID:crive-50476-635594189841567445-1:0:1 queue used by camel: temp-queue://ID:crive-50473-1423818570510-3:1:1 I have tried to look into Camel source code to see how camel handles the InOut but haven't found it yet, anyone can give me any pointer? Thanks! -- View this message in context: http://camel.465427.n5.nabble.com/request-reply-with-ActiveMQ-and-Camel-tp5762666p5762684.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel java dsl: try/catch+stop = finally is not evaluated
stop() stops the route so i thinks in my opinion this is expected behavior. What happens if you remove stop() from doCatch() and put it at the end of the doFinally() ? On 13/02/2015 10:42, vasilievip wrote: I'm thinking to stop execution in case of exception, but I do want to perform some logging in finally block. The .stop() definition looks like does what I need but it stops finally definition as well. https://github.com/vasilievip/camel-spring-boot/blob/master/src/main/java/cameltest/CamelConfiguration.java#L35 Is this expected behavior? Am I missing something? Thanks -- View this message in context: http://camel.465427.n5.nabble.com/Camel-java-dsl-try-catch-stop-finally-is-not-evaluated-tp5762683.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: RejectedExecutionException: Task rejected due queue size limit reached
I'd have preferred to set maxQueueSize to 1 or 10 instead of
rolling a new executorService, isn't that configurable?
2015-02-13 12:33 GMT+03:30 Taariq Levack taar...@gmail.com:
You can try set a custom executorServiceRef on your error handler, by
default the maxQueueSize is 1000, mind that you don't run OOM.
Here's the relevant code and comments from DefaultThreadPoolFactory;
// need to wrap the thread pool in a sized to guard against the
problem that the
// JDK created thread pool has an unbounded queue (see class
javadoc), which mean
// we could potentially keep adding tasks, and run out of memory.
if (profile.getMaxPoolSize() 0) {
return new SizedScheduledExecutorService(answer,
profile.getMaxQueueSize());
} else {
return answer;
}
Taariq
On Thu, Feb 12, 2015 at 9:29 AM, Behrad behr...@gmail.com wrote:
I don't think it be a SEDA queue size problem, since my SEDA endpoint
queue
size is a very big number in logs, there should be something with
redelivery/errorHandler task queue !?
2015-02-12 10:23 GMT+03:30 Taariq Levack taar...@gmail.com:
Hi
SEDA queue size is unbounded by default, you can try the unit test[1]
with
a very large number, works for me in 2.14.1 and trunk.
Check all your endpoints with that name, the first one to load is
setting
the size.
[1]
https://github.com/apache/camel/blob/master/camel-core/src/test/java/org/apache/camel/component/seda/SedaDefaultUnboundedQueueSizeTest.java
Taariq
On Thu, Feb 12, 2015 at 7:33 AM, Behrad behr...@gmail.com wrote:
When my SEDA producer peaks seems I'm getting ExecusionService queue
limit
with this trace:
at
org.apache.camel.util.concurrent.SizedScheduledExecutorService.schedule(SizedScheduledExecutorService.java:74)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:367)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at org.apache.camel.processor.Pipeline.process(Pipeline.java:118)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.ChoiceProcessor.process(ChoiceProcessor.java:111)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.idempotent.IdempotentConsumer.process(IdempotentConsumer.java:123)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at org.apache.camel.processor.Pipeline.process(Pipeline.java:118)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.component.seda.SedaConsumer.sendToConsumers(SedaConsumer.java:291)
[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.component.seda.SedaConsumer.doRun(SedaConsumer.java:200)
[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.component.seda.SedaConsumer.run(SedaConsumer.java:147)
[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[na:1.8.0]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[na:1.8.0]
at java.lang.Thread.run(Thread.java:744) [na:1.8.0]
How can I
Re: Camel java dsl: try/catch+stop = finally is not evaluated
Hi Yes a stop is a hard stop, doFinally was intended about an exception was thrown, but you want to call some logic. It may further complicate routing engine if a stop is not a stop but should continue under special use-cases. On Fri, Feb 13, 2015 at 10:42 AM, vasilievip vasilie...@gmail.com wrote: I'm thinking to stop execution in case of exception, but I do want to perform some logging in finally block. The .stop() definition looks like does what I need but it stops finally definition as well. https://github.com/vasilievip/camel-spring-boot/blob/master/src/main/java/cameltest/CamelConfiguration.java#L35 Is this expected behavior? Am I missing something? Thanks -- View this message in context: http://camel.465427.n5.nabble.com/Camel-java-dsl-try-catch-stop-finally-is-not-evaluated-tp5762683.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen - Red Hat, Inc. Email: cib...@redhat.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen hawtio: http://hawt.io/ fabric8: http://fabric8.io/
Re: RejectedExecutionException: Task rejected due queue size limit reached
Hi
See
http://camel.apache.org/threading-model.html
On Fri, Feb 13, 2015 at 10:58 AM, Behrad behr...@gmail.com wrote:
I'd have preferred to set maxQueueSize to 1 or 10 instead of
rolling a new executorService, isn't that configurable?
2015-02-13 12:33 GMT+03:30 Taariq Levack taar...@gmail.com:
You can try set a custom executorServiceRef on your error handler, by
default the maxQueueSize is 1000, mind that you don't run OOM.
Here's the relevant code and comments from DefaultThreadPoolFactory;
// need to wrap the thread pool in a sized to guard against the
problem that the
// JDK created thread pool has an unbounded queue (see class
javadoc), which mean
// we could potentially keep adding tasks, and run out of memory.
if (profile.getMaxPoolSize() 0) {
return new SizedScheduledExecutorService(answer,
profile.getMaxQueueSize());
} else {
return answer;
}
Taariq
On Thu, Feb 12, 2015 at 9:29 AM, Behrad behr...@gmail.com wrote:
I don't think it be a SEDA queue size problem, since my SEDA endpoint
queue
size is a very big number in logs, there should be something with
redelivery/errorHandler task queue !?
2015-02-12 10:23 GMT+03:30 Taariq Levack taar...@gmail.com:
Hi
SEDA queue size is unbounded by default, you can try the unit test[1]
with
a very large number, works for me in 2.14.1 and trunk.
Check all your endpoints with that name, the first one to load is
setting
the size.
[1]
https://github.com/apache/camel/blob/master/camel-core/src/test/java/org/apache/camel/component/seda/SedaDefaultUnboundedQueueSizeTest.java
Taariq
On Thu, Feb 12, 2015 at 7:33 AM, Behrad behr...@gmail.com wrote:
When my SEDA producer peaks seems I'm getting ExecusionService queue
limit
with this trace:
at
org.apache.camel.util.concurrent.SizedScheduledExecutorService.schedule(SizedScheduledExecutorService.java:74)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:367)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at org.apache.camel.processor.Pipeline.process(Pipeline.java:118)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.ChoiceProcessor.process(ChoiceProcessor.java:111)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.idempotent.IdempotentConsumer.process(IdempotentConsumer.java:123)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:398)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at org.apache.camel.processor.Pipeline.process(Pipeline.java:118)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at org.apache.camel.processor.Pipeline.process(Pipeline.java:80)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191)
~[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.component.seda.SedaConsumer.sendToConsumers(SedaConsumer.java:291)
[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.component.seda.SedaConsumer.doRun(SedaConsumer.java:200)
[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
org.apache.camel.component.seda.SedaConsumer.run(SedaConsumer.java:147)
[org.apache.camel.camel-core-2.14.0.jar:2.14.0]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[na:1.8.0]
at
Re: FileLockExclusiveReadLockStrategy doesn't hold lock and error on commit
Hi Windows file system works different than unix based and therefore you can hit issue like that, that otherwise works on unix systems. Its a bit wonky having to add logic to cater for this on windows. The other read locks works better on windows. And using readLock=fileLock is not guaranteed to work globally, meaning you can have another JVM that can also grab a fileLock on the same file. Using marker files / changed is better. On Thu, Feb 12, 2015 at 6:56 PM, wrusch wru...@loftware.com wrote: The built in FileLockExclusiveReadLockStrategy for camel errors on every message commit: WARN - MarkerIgnoringBase.warn(136) | Error during commit. Exchange[test2.txt]. Caused by: [java.nio.channels.ClosedChannelException - null] java.nio.channels.ClosedChannelException at sun.nio.ch.FileLockImpl.release(FileLockImpl.java:58) at org.apache.camel.component.file.strategy.FileLockExclusiveReadLockStrategy.releaseExclusiveReadLock(FileLockStrategy.java:137) at org.apache.camel.component.file.strategy.GenericFileProcessStrategySupport.commit(GenericFileProcessStrategySupport.java:75) at org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy.commit(GenericFileRenameProcessStrategy.java:92) at org.apache.camel.component.file.GenericFileOnCompletion.processStrategyCommit(GenericFileOnCompletion.java:124) at org.apache.camel.component.file.GenericFileOnCompletion.onCompletion(GenericFileOnCompletion.java:80) at org.apache.camel.component.file.GenericFileOnCompletion.onComplete(GenericFileOnCompletion.java:54) at org.apache.camel.util.UnitOfWorkHelper.doneSynchronizations(UnitOfWorkHelper.java:104) at org.apache.camel.impl.DefaultUnitOfWork.done(DefaultUnitOfWork.java:229) at org.apache.camel.util.UnitOfWorkHelper.doneUow(UnitOfWorkHelper.java:65) at org.apache.camel.processor.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:642) at org.apache.camel.processor.CamelInternalProcessor$UnitOfWorkProcessorAdvice.after(CamelInternalProcessor.java:610) at org.apache.camel.processor.CamelInternalProcessor$InternalCallback.done(CamelInternalProcessor.java:240) at org.apache.camel.processor.CamelInternalProcessor$InternalCallback.done(CamelInternalProcessor.java:251) at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:447) at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191) at org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:191) at org.apache.camel.component.file.GenericFileConsumer.processExchange(GenericFileConsumer.java:433) at org.apache.camel.component.file.GenericFileConsumer.processBatch(GenericFileConsumer.java:211) at org.apache.camel.component.file.GenericFileConsumer.poll(GenericFileConsumer.java:175) at org.apache.camel.impl.ScheduledPollConsumer.doRun(ScheduledPollConsumer.java:187) at org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:114) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) I spent a fair amount of time looking at this and basically the lock is getting created and released immediately at lines 120,121 where the lock is aquired. This means that the release is not only pointless it generates errors because the channel is closed already and the lock has been released. I thought that an easy fix would be to simply not close the channel in the finally clause of acquireExclusiveReadLock method, so that it could be closed properly in the releaseExclusiveReadLock method. However when I try and do this it breaks the rename strategy because for some reason the rename strategy thinks it can rename a file that is locked and tries to release the lock after trying to rename the file. Error: WARN - MarkerIgnoringBase.warn(136) | Error during commit. Exchange[test2.txt]. Caused by: [org.apache.camel.component.file.GenericFileOperationFailedException - Error renaming file from C:\source\workspace\3.3-BoiseU3\integrations\camel\test-output\filedrop\test2.txt to test-output\filedrop\.done\test2.txt] org.apache.camel.component.file.GenericFileOperationFailedException: Error renaming file
Re: breadcrumbId does not survive http call
Hello Claus, I have logged https://issues.apache.org/jira/browse/CAMEL-8351. Thanks! Ralf Claus Ibsen-2 wrote You are welcome to log a JIRA. I think spring-ws has some ways of telling it to include HTTP headers too. -- View this message in context: http://camel.465427.n5.nabble.com/breadcrumbId-does-not-survive-http-call-tp5762528p5762704.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: breadcrumbId does not survive http call
On Fri, Feb 13, 2015 at 1:43 PM, rsteppac2 r...@steppacher.name wrote: I absolutely require a log correlation ID that never changes for a request across all our components. The breadcrumb looked like a good fit for that. Yeah lets see if we can get that dude safe across camel-spring-ws. You are welcome to log a JIRA. I think spring-ws has some ways of telling it to include HTTP headers too. James Carman wrote Do you absolutely require that the breadcrumb's match between the proxy and your web service? -- View this message in context: http://camel.465427.n5.nabble.com/breadcrumbId-does-not-survive-http-call-tp5762528p5762701.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen - Red Hat, Inc. Email: cib...@redhat.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen hawtio: http://hawt.io/ fabric8: http://fabric8.io/
Re: FileLockExclusiveReadLockStrategy doesn't hold lock and error on commit
I don't think this is a platform issue. It could be that the filelock strategy as a whole is simply not compatible with the rename file strategy at all and what is currently there is just a hack pretending to do it correctly. The error is happening because the lock is being released immediately and not during commit. During the commit it tries to release it again so you get the error. Nothing OS specific about that unless you are saying that on linux they just swallow the errors or flat out don't honor the locks. The problem here is I can't fix it on my end because the component I need access to(the rename strategy) is not a pluggable component. The main point is if you need to release a lock before you can rename a file, the rename strategy needs to do that in the correct order. Instead of rename file - then release lock release lock - then rename file I cannot fix this. Which means I cannot fix the strategy as a whole. The only thing I can do is hide the original problem without fixing it. The original problem being that the file lock strategy doesn't hold the lock till commit, it releases it immediately. What OS specific issue do you see here? -- View this message in context: http://camel.465427.n5.nabble.com/FileLockExclusiveReadLockStrategy-doesn-t-hold-lock-and-error-on-commit-tp5762668p5762706.html Sent from the Camel - Users mailing list archive at Nabble.com.
Archiving Files after sending records to Queue
We would like to process a set of files, batch the records into small batches, send to queue and archive the files to another folder. We are using Apache Camel Framework. Also We are validating CamelSplitComplete property to check whether we can perform archival of the files. The files are not getting archived in some cases (but records are sent to MQ) and inconsistent. Can you provide some insight to this property and how it can be leveraged? -- View this message in context: http://camel.465427.n5.nabble.com/Archiving-Files-after-sending-records-to-Queue-tp5762709.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Camel can't Route Topic
Try destinationName injection: to uri=quot;jms:queue?destinationName=lt;b#deadQueue*amp;jmsMessageType=Text/ -- View this message in context: http://camel.465427.n5.nabble.com/Camel-can-t-Route-Topic-tp5762517p5762712.html Sent from the Camel - Users mailing list archive at Nabble.com.
request-reply with RabitMQ and Camel
Hi, I'm trying to convert to from ActiveMQ to RabbitMQ (with the RabbitMQ component) but I cant seem to get reply's working. When using the ActiveMQ component on an inOut route I see the TemporaryQueueReplyManager and jmsreplyto header automatically handle the response for me. However I cant seem to get the RabbitMQ component to wait for a response. Can someone confirm that the RabbitMQ component does not support inOut? I am leaning towards using the AMQP component with RabbitMQ which I assume would support inOut? -- View this message in context: http://camel.465427.n5.nabble.com/request-reply-with-RabitMQ-and-Camel-tp5762713.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: request-reply with ActiveMQ and Camel
The source code for InOut over JMS is all in the camel-jms component. Mind there is a lighter alternative component called camel-sjms, but its not as battle tested or feature rich as camel-jms (which uses spring jms). On Fri, Feb 13, 2015 at 10:56 AM, Marco Crivellaro marco.cr...@gmail.com wrote: Thanks for the replies Camel is only used to consume the request queue and post the replies, the requestor is a .NET app based on NMS and the aggregation part works fine as the setup works fine when using a standard queue on JMSReplyTo header: camel is sending the multiple replies to the queue and the requestor (.net) receives/aggregates them. At the moment the request is processed using InOut, the processing of the exchange is creating a DefaultProducer to send all chunks of the reply up to the second-last and the last is sent using standard routing. the problem occurs when qualifying a temporary queue as JMSReplyTo as the consumer is only receiving the last chunk (the one pushed by InOut routing), I've figured out the remaining messages (1:N-1) where being sent to a standard queue named temp-queue://ID:crive-50476-635594189841567445-1:0:1 so I thought camel was not interpreting correctly the destination prefix when used in my producer template. I than changed it so it was using camel temp queue naming by using a string replace so that the producer template could use temp:queue: instead of temp-queue://, so in my example the destination would have been: temp:queue:ID:crive-50476-635594189841567445-1:0:1. By looking into the logs I can see the producer sending messages to a different temp queue temp-queue://ID:crive-50473-1423818570510-3:1:1. It looks like camel generates a new temporary queue name for some reason endpoint uri: temp:queue:ID:crive-50476-635594189841567445-1:0:1 queue used by camel: temp-queue://ID:crive-50473-1423818570510-3:1:1 I have tried to look into Camel source code to see how camel handles the InOut but haven't found it yet, anyone can give me any pointer? Thanks! -- View this message in context: http://camel.465427.n5.nabble.com/request-reply-with-ActiveMQ-and-Camel-tp5762666p5762684.html Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen - Red Hat, Inc. Email: cib...@redhat.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen hawtio: http://hawt.io/ fabric8: http://fabric8.io/
Re: breadcrumbId does not survive http call
I absolutely require a log correlation ID that never changes for a request across all our components. The breadcrumb looked like a good fit for that. James Carman wrote Do you absolutely require that the breadcrumb's match between the proxy and your web service? -- View this message in context: http://camel.465427.n5.nabble.com/breadcrumbId-does-not-survive-http-call-tp5762528p5762701.html Sent from the Camel - Users mailing list archive at Nabble.com.
