You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by bvahdat <ba...@swissonline.ch> on 2011/12/02 15:22:47 UTC

Riding on org.apache.camel.language.TokenPairPredicateTest

Hi,

today I had a chance to look @ the test failure I mentioned in [1], and my
concern isn't really why the file renaming fails with the following log
message:

2011-12-02 14:37:37,679 [e://target/pair] ERROR GenericFileOnCompletion       
- Caused by:
[org.apache.camel.component.file.GenericFileOperationFailedException - Error
renaming file from
D:\Data\eclipse-workspace\camel-trunk\camel-core\target\pair\hello.xml to
target\pair\ok\hello.xml]

but more than that why the route defined there behaves like this?

Per default it seems that the FileConsumer (as a polling one) has
LoggingExceptionHandler wired into it which get's kicked through
getExceptionHandler().handleException(xyz) in the case of an encountered
exception which logs the error at the ERROR level. And then the message
routing CONTINUES further. To me this behaviour is as if there's an
onException() clause on the route like:

onException(java.lang.Exception).handled(true);

which is not the case!

So the routing of payload just simply continues until it reaches the mock
endpoint, as adding the check:

        getMockEndpoint("mock:result").expectedMessageCount(1);

before the line

				assertMockEndpointsSatisfied();

passed on my box.

I'm just thinking on a production system where routing continuation of such
(failed) payloads in such cases would cause side effects. I admit, one can
still wire his own ExceptionHandler into the FileConsumer which maybe would
rethrow the exception and whatnot, however to me the usage of
LoggingExceptionHandler as the default is too "risky". Or do I miss
something?

By the way the test fails on two boxes of me (win-xp & win-vista) by both
I've got admin right. On the other hand as I've already got a
swiss-made-jura-coffe-machine in place in my apartment (;-)) this Christmas
I intend to gift myself a mac-box...

[1] https://issues.apache.org/jira/browse/CAMEL-4687

Babak

Here is the log output at DEBUG level:
2011-12-02 14:37:32,194 [main           ] DEBUG SharedProducerServicePool     
- Starting service pool:
org.apache.camel.impl.SharedProducerServicePool@867e89
2011-12-02 14:37:32,241 [main           ] DEBUG TokenPairPredicateTest        
- Using created route builder: Routes: []
2011-12-02 14:37:32,241 [main           ] DEBUG DefaultCamelContext           
- Adding routes from builder: Routes: []
2011-12-02 14:37:32,366 [main           ] INFO  DefaultCamelContext           
- Apache Camel  (CamelContext: camel-1) is starting
2011-12-02 14:37:32,413 [main           ] INFO 
AnnotationTypeConverterLoader  - Found 3 packages with 15 @Converter classes
to load
2011-12-02 14:37:32,459 [main           ] INFO  LazyLoadingTypeConverter      
- Loaded 166 core type converters (total 166 type converters)
2011-12-02 14:37:32,475 [main           ] DEBUG DefaultComponentResolver      
- Found component: file in registry: null
2011-12-02 14:37:32,475 [main           ] DEBUG DefaultComponentResolver      
- Found component: file via type:
org.apache.camel.component.file.FileComponent via:
META-INF/services/org/apache/camel/component/file
2011-12-02 14:37:32,475 [main           ] DEBUG DefaultComponent              
- Creating endpoint uri=[file://target/pair?move=ok], path=[target/pair],
parameters=[{move=ok}]
2011-12-02 14:37:32,538 [main           ] DEBUG DefaultCamelContext           
- file://target/pair?move=ok converted to endpoint:
Endpoint[file://target/pair?move=ok] by component:
org.apache.camel.component.file.FileComponent@1db699b
2011-12-02 14:37:32,569 [main           ] DEBUG DefaultComponentResolver      
- Found component: mock in registry: null
2011-12-02 14:37:32,569 [main           ] DEBUG DefaultComponentResolver      
- Found component: mock via type:
org.apache.camel.component.mock.MockComponent via:
META-INF/services/org/apache/camel/component/mock
2011-12-02 14:37:32,569 [main           ] DEBUG DefaultComponent              
- Creating endpoint uri=[mock://result], path=[result], parameters=[{}]
2011-12-02 14:37:32,569 [main           ] DEBUG DefaultCamelContext           
- mock://result converted to endpoint: Endpoint[mock://result] by component:
org.apache.camel.component.mock.MockComponent@10e790c
2011-12-02 14:37:32,584 [main           ] DEBUG DefaultChannel                
- Initialize channel for target: 'To[mock:result]'
2011-12-02 14:37:32,616 [main           ] DEBUG DefaultChannel                
- Initialize channel for target: 'Choice[[When[tokenize{} ->
[To[mock:result]]]]]'
2011-12-02 14:37:32,631 [main           ] DEBUG DefaultCamelContext           
- Warming up route id: route1 having autoStartup=true
2011-12-02 14:37:32,631 [main           ] DEBUG RouteService                  
- Starting services on route: route1
2011-12-02 14:37:32,631 [main           ] DEBUG FileEndpoint                  
- Creating non existing starting directory: target\pair
2011-12-02 14:37:32,631 [main           ] DEBUG
DefaultExecutorServiceManager  - Created new ScheduledThreadPool for source:
Consumer[file://target/pair?move=ok] with name: file://target/pair?move=ok.
-> java.util.concurrent.ScheduledThreadPoolExecutor@d1fa5
2011-12-02 14:37:32,631 [main           ] DEBUG RouteService                  
- Starting child service on route: route1 ->
Instrumentation:route[UnitOfWork(Channel[choice{when tokenize[body() using
tokens: <hello>...</hello>]: Channel[sendTo(Endpoint[mock://result])],
otherwise: Processor is null}])]
2011-12-02 14:37:32,631 [main           ] DEBUG MockEndpoint$1                
- Starting producer: Producer[mock://result]
2011-12-02 14:37:32,631 [main           ] DEBUG ProducerCache                 
- Adding to producer cache with key: Endpoint[mock://result] for producer:
Producer[mock://result]
2011-12-02 14:37:32,631 [main           ] DEBUG
DefaultExecutorServiceManager  - Created new ScheduledThreadPool for source:
DefaultErrorHandler[TraceInterceptor[To[mock:result]]] with name:
ErrorHandlerRedeliveryTask. ->
java.util.concurrent.ScheduledThreadPoolExecutor@1bd2664
2011-12-02 14:37:32,631 [main           ] DEBUG DefaultErrorHandler           
- Redelivery enabled: false on error handler:
DefaultErrorHandler[TraceInterceptor[To[mock:result]]]
2011-12-02 14:37:32,631 [main           ] DEBUG DefaultErrorHandler           
- Redelivery enabled: false on error handler:
DefaultErrorHandler[TraceInterceptor[Choice[[When[tokenize{} ->
[To[mock:result]]]]]]]
2011-12-02 14:37:32,647 [main           ] DEBUG RouteService                  
- Starting child service on route: route1 -> UnitOfWork(Channel[choice{when
tokenize[body() using tokens: <hello>...</hello>]:
Channel[sendTo(Endpoint[mock://result])], otherwise: Processor is null}])
2011-12-02 14:37:32,647 [main           ] DEBUG RouteService                  
- Starting child service on route: route1 -> Channel[choice{when
tokenize[body() using tokens: <hello>...</hello>]:
Channel[sendTo(Endpoint[mock://result])], otherwise: Processor is null}]
2011-12-02 14:37:32,647 [main           ] DEBUG RouteService                  
- Starting child service on route: route1 -> choice{when tokenize[body()
using tokens: <hello>...</hello>]: Channel[sendTo(Endpoint[mock://result])],
otherwise: Processor is null}
2011-12-02 14:37:32,647 [main           ] DEBUG RouteService                  
- Starting child service on route: route1 -> Filter[if: tokenize[body()
using tokens: <hello>...</hello>] do:
Channel[sendTo(Endpoint[mock://result])]]
2011-12-02 14:37:32,647 [main           ] DEBUG RouteService                  
- Starting child service on route: route1 ->
Channel[sendTo(Endpoint[mock://result])]
2011-12-02 14:37:32,647 [main           ] DEBUG RouteService                  
- Starting child service on route: route1 -> sendTo(Endpoint[mock://result])
2011-12-02 14:37:32,647 [main           ] DEBUG RouteService                  
- Starting child service on route: route1 -> Processor is null
2011-12-02 14:37:32,647 [main           ] DEBUG DefaultCamelContext           
- Route: route1 >>>
EventDrivenConsumerRoute[Endpoint[file://target/pair?move=ok] ->
Instrumentation:route[UnitOfWork(Channel[choice{when tokenize[body() using
tokens: <hello>...</hello>]: Channel[sendTo(Endpoint[mock://result])],
otherwise: Processor is null}])]]
2011-12-02 14:37:32,647 [main           ] DEBUG DefaultCamelContext           
- Starting consumer (order: 1000) on route: route1
2011-12-02 14:37:32,647 [main           ] DEBUG FileConsumer                  
- Starting consumer: Consumer[file://target/pair?move=ok]
2011-12-02 14:37:32,647 [main           ] DEBUG ScheduledPollConsumer         
- Scheduling poll (fixed delay) with initialDelay: 1000, delay: 500
(milliseconds) for: Endpoint[file://target/pair?move=ok]
2011-12-02 14:37:32,647 [main           ] DEBUG FileEndpoint                  
- Parameters for Generic file process strategy {readLock=markerFile,
readLockTimeout=10000, move=${file:parent}\ok\${file:onlyname},
readLockCheckInterval=1000}
2011-12-02 14:37:32,647 [main           ] DEBUG FileEndpoint                  
- Using Generic file process strategy:
org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy@1a52fdf
2011-12-02 14:37:32,647 [main           ] DEBUG
rFileExclusiveReadLockStrategy - Prepare on startup by deleting orphaned
lock files from: target\pair
2011-12-02 14:37:32,647 [main           ] INFO  DefaultCamelContext           
- Route: route1 started and consuming from:
Endpoint[file://target/pair?move=ok]
2011-12-02 14:37:32,647 [main           ] INFO  DefaultCamelContext           
- Total 1 routes, of which 1 is started.
2011-12-02 14:37:32,647 [main           ] INFO  DefaultCamelContext           
- Apache Camel  (CamelContext: camel-1) started in 0.328 seconds
2011-12-02 14:37:32,647 [main           ] DEBUG DefaultComponent              
- Creating endpoint uri=[file://target/pair], path=[target/pair],
parameters=[{}]
2011-12-02 14:37:32,647 [main           ] DEBUG DefaultCamelContext           
- file://target/pair converted to endpoint: Endpoint[file://target/pair] by
component: org.apache.camel.component.file.FileComponent@1db699b
2011-12-02 14:37:32,647 [main           ] DEBUG GenericFileProducer           
- Starting producer: Producer[file://target/pair]
2011-12-02 14:37:32,647 [main           ] DEBUG ProducerCache                 
- Adding to producer cache with key: Endpoint[file://target/pair] for
producer: Producer[file://target/pair]
2011-12-02 14:37:32,663 [main           ] DEBUG ProducerCache                 
- >>>> Endpoint[file://target/pair] Exchange[Message: <hello>world!</hello>]
2011-12-02 14:37:32,678 [main           ] DEBUG GenericFileProducer           
- Wrote [target\pair\hello.xml] to [Endpoint[file://target/pair]]
2011-12-02 14:37:32,678 [main           ] INFO  MockEndpoint                  
- Asserting: Endpoint[mock://result] is satisfied
2011-12-02 14:37:32,678 [main           ] DEBUG MockEndpoint                  
- Waiting on the latch for: 0 millis
2011-12-02 14:37:33,647 [e://target/pair] DEBUG FileConsumer                  
- Took 0.000 seconds to poll: target\pair
2011-12-02 14:37:33,647 [e://target/pair] DEBUG FileConsumer                  
- Total 1 files to consume
2011-12-02 14:37:33,647 [e://target/pair] DEBUG FileConsumer                  
- About to process file: GenericFile[hello.xml] using exchange:
Exchange[hello.xml]
2011-12-02 14:37:33,663 [e://target/pair] DEBUG ChoiceProcessor               
- #0 - tokenize[body() using tokens: <hello>...</hello>] matches: true for:
Exchange[hello.xml]
2011-12-02 14:37:33,663 [e://target/pair] DEBUG SendProcessor                 
- >>>> Endpoint[mock://result] Exchange[hello.xml]
2011-12-02 14:37:33,663 [e://target/pair] DEBUG MockEndpoint                  
- mock://result >>>> 0 : Exchange[null] with body: GenericFile[hello.xml]
and
headers:{CamelFileAbsolutePath=D:\Data\eclipse-workspace\camel-trunk\camel-core\target\pair\hello.xml,
CamelFilePath=target\pair\hello.xml, CamelFileLastModified=Fri Dec 02
14:37:32 CET 2011, CamelFileRelativePath=hello.xml,
breadcrumbId=ID-w01b3j3e-2675-1322833052053-0-4,
CamelFileNameOnly=hello.xml, CamelFileName=hello.xml,
CamelFileParent=target\pair, CamelFileLength=21, CamelFileAbsolute=false}
2011-12-02 14:37:33,663 [main           ] DEBUG MockEndpoint                  
- Took 985 millis to complete latch
2011-12-02 14:37:33,663 [e://target/pair] DEBUG GenericFileOnCompletion       
- Done processing file: GenericFile[hello.xml] using exchange:
Exchange[hello.xml]
2011-12-02 14:37:33,663 [e://target/pair] DEBUG FileUtil                      
- Retrying attempt 0 to delete file:
D:\Data\eclipse-workspace\camel-trunk\camel-core\target\pair\hello.xml.camelLock
2011-12-02 14:37:33,663 [e://target/pair] DEBUG FileUtil                      
- Tried 1 to delete file:
D:\Data\eclipse-workspace\camel-trunk\camel-core\target\pair\hello.xml.camelLock
with result: true
2011-12-02 14:37:33,663 [e://target/pair] DEBUG
nericFileRenameProcessStrategy - Renaming file: GenericFile[hello.xml] to:
GenericFile[ok\hello.xml]
2011-12-02 14:37:33,663 [e://target/pair] DEBUG FileUtil                      
- Retrying attempt 1 to rename file from:
D:\Data\eclipse-workspace\camel-trunk\camel-core\target\pair\hello.xml to:
target\pair\ok\hello.xml
2011-12-02 14:37:34,663 [e://target/pair] DEBUG FileUtil                      
- Retrying attempt 2 to rename file from:
D:\Data\eclipse-workspace\camel-trunk\camel-core\target\pair\hello.xml to:
target\pair\ok\hello.xml
2011-12-02 14:37:35,663 [e://target/pair] DEBUG FileUtil                      
- Cannot rename file from:
D:\Data\eclipse-workspace\camel-trunk\camel-core\target\pair\hello.xml to:
target\pair\ok\hello.xml, will now use a copy/delete approach instead
2011-12-02 14:37:35,678 [e://target/pair] DEBUG FileUtil                      
- Retrying attempt 0 to delete file:
D:\Data\eclipse-workspace\camel-trunk\camel-core\target\pair\hello.xml
2011-12-02 14:37:35,678 [e://target/pair] DEBUG FileUtil                      
- Retrying attempt 1 to delete file:
D:\Data\eclipse-workspace\camel-trunk\camel-core\target\pair\hello.xml
2011-12-02 14:37:36,678 [e://target/pair] DEBUG FileUtil                      
- Retrying attempt 2 to delete file:
D:\Data\eclipse-workspace\camel-trunk\camel-core\target\pair\hello.xml
2011-12-02 14:37:37,679 [e://target/pair] DEBUG FileUtil                      
- Tried 3 to delete file:
D:\Data\eclipse-workspace\camel-trunk\camel-core\target\pair\hello.xml with
result: false
2011-12-02 14:37:37,679 [e://target/pair] ERROR GenericFileOnCompletion       
- Caused by:
[org.apache.camel.component.file.GenericFileOperationFailedException - Error
renaming file from
D:\Data\eclipse-workspace\camel-trunk\camel-core\target\pair\hello.xml to
target\pair\ok\hello.xml]
org.apache.camel.component.file.GenericFileOperationFailedException: Error
renaming file from
D:\Data\eclipse-workspace\camel-trunk\camel-core\target\pair\hello.xml to
target\pair\ok\hello.xml
	at
org.apache.camel.component.file.FileOperations.renameFile(FileOperations.java:68)[file:/D:/Data/eclipse-workspace/camel-trunk/camel-core/target/classes/:]
	at
org.apache.camel.component.file.strategy.GenericFileProcessStrategySupport.renameFile(GenericFileProcessStrategySupport.java:96)[file:/D:/Data/eclipse-workspace/camel-trunk/camel-core/target/classes/:]
	at
org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy.commit(GenericFileRenameProcessStrategy.java:86)[file:/D:/Data/eclipse-workspace/camel-trunk/camel-core/target/classes/:]
	at
org.apache.camel.component.file.GenericFileOnCompletion.processStrategyCommit(GenericFileOnCompletion.java:132)[file:/D:/Data/eclipse-workspace/camel-trunk/camel-core/target/classes/:]
	at
org.apache.camel.component.file.GenericFileOnCompletion.onCompletion(GenericFileOnCompletion.java:82)[file:/D:/Data/eclipse-workspace/camel-trunk/camel-core/target/classes/:]
	at
org.apache.camel.component.file.GenericFileOnCompletion.onComplete(GenericFileOnCompletion.java:53)[file:/D:/Data/eclipse-workspace/camel-trunk/camel-core/target/classes/:]
	at
org.apache.camel.util.UnitOfWorkHelper.doneSynchronizations(UnitOfWorkHelper.java:56)[file:/D:/Data/eclipse-workspace/camel-trunk/camel-core/target/classes/:]
	at
org.apache.camel.impl.DefaultUnitOfWork.done(DefaultUnitOfWork.java:208)[file:/D:/Data/eclipse-workspace/camel-trunk/camel-core/target/classes/:]
	at
org.apache.camel.processor.UnitOfWorkProcessor.doneUow(UnitOfWorkProcessor.java:188)[file:/D:/Data/eclipse-workspace/camel-trunk/camel-core/target/classes/:]
	at
org.apache.camel.processor.UnitOfWorkProcessor.access$0(UnitOfWorkProcessor.java:184)[file:/D:/Data/eclipse-workspace/camel-trunk/camel-core/target/classes/:]
	at
org.apache.camel.processor.UnitOfWorkProcessor$1.done(UnitOfWorkProcessor.java:146)[file:/D:/Data/eclipse-workspace/camel-trunk/camel-core/target/classes/:]
	at
org.apache.camel.processor.interceptor.DefaultChannel$1.done(DefaultChannel.java:315)[file:/D:/Data/eclipse-workspace/camel-trunk/camel-core/target/classes/:]
	at
org.apache.camel.processor.RedeliveryErrorHandler.processErrorHandler(RedeliveryErrorHandler.java:352)[file:/D:/Data/eclipse-workspace/camel-trunk/camel-core/target/classes/:]
	at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:212)[file:/D:/Data/eclipse-workspace/camel-trunk/camel-core/target/classes/:]
	at
org.apache.camel.processor.interceptor.DefaultChannel.process(DefaultChannel.java:304)[file:/D:/Data/eclipse-workspace/camel-trunk/camel-core/target/classes/:]
	at
org.apache.camel.processor.UnitOfWorkProcessor.processAsync(UnitOfWorkProcessor.java:139)[file:/D:/Data/eclipse-workspace/camel-trunk/camel-core/target/classes/:]
	at
org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcessor.java:106)[file:/D:/Data/eclipse-workspace/camel-trunk/camel-core/target/classes/:]
	at
org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73)[file:/D:/Data/eclipse-workspace/camel-trunk/camel-core/target/classes/:]
	at
org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99)[file:/D:/Data/eclipse-workspace/camel-trunk/camel-core/target/classes/:]
	at
org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90)[file:/D:/Data/eclipse-workspace/camel-trunk/camel-core/target/classes/:]
	at
org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:71)[file:/D:/Data/eclipse-workspace/camel-trunk/camel-core/target/classes/:]
	at
org.apache.camel.component.file.GenericFileConsumer.processExchange(GenericFileConsumer.java:352)[file:/D:/Data/eclipse-workspace/camel-trunk/camel-core/target/classes/:]
	at
org.apache.camel.component.file.GenericFileConsumer.processBatch(GenericFileConsumer.java:175)[file:/D:/Data/eclipse-workspace/camel-trunk/camel-core/target/classes/:]
	at
org.apache.camel.component.file.GenericFileConsumer.poll(GenericFileConsumer.java:136)[file:/D:/Data/eclipse-workspace/camel-trunk/camel-core/target/classes/:]
	at
org.apache.camel.impl.ScheduledPollConsumer.doRun(ScheduledPollConsumer.java:140)[file:/D:/Data/eclipse-workspace/camel-trunk/camel-core/target/classes/:]
	at
org.apache.camel.impl.ScheduledPollConsumer.run(ScheduledPollConsumer.java:92)[file:/D:/Data/eclipse-workspace/camel-trunk/camel-core/target/classes/:]
	at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)[:1.6.0_29]
	at
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)[:1.6.0_29]
	at
java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)[:1.6.0_29]
	at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)[:1.6.0_29]
	at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)[:1.6.0_29]
	at
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)[:1.6.0_29]
	at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)[:1.6.0_29]
	at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)[:1.6.0_29]
	at java.lang.Thread.run(Thread.java:662)[:1.6.0_29]
2011-12-02 14:37:37,679 [main           ] DEBUG TokenPairPredicateTest        
- tearDown test: testTokenPairPredicate
2011-12-02 14:37:37,679 [main           ] DEBUG GenericFileProducer           
- Stopping producer: Producer[file://target/pair]
2011-12-02 14:37:37,679 [main           ] INFO  DefaultCamelContext           
- Apache Camel  (CamelContext: camel-1) is shutting down
2011-12-02 14:37:37,679 [main           ] INFO  DefaultShutdownStrategy       
- Starting to graceful shutdown 1 routes (timeout 10 seconds)
2011-12-02 14:37:37,679 [main           ] DEBUG
DefaultExecutorServiceManager  - Created new ThreadPool for source:
org.apache.camel.impl.DefaultShutdownStrategy@5e176f with name:
ShutdownTask. -> java.util.concurrent.ThreadPoolExecutor@1549f94
2011-12-02 14:37:37,694 [ - ShutdownTask] DEBUG DefaultShutdownStrategy       
- There are 1 routes to shutdown
2011-12-02 14:37:37,694 [ - ShutdownTask] DEBUG DefaultShutdownStrategy       
- Route: route1 suspended and shutdown deferred, was consuming from:
Endpoint[file://target/pair?move=ok]
2011-12-02 14:37:37,694 [ - ShutdownTask] DEBUG DefaultShutdownStrategy       
- Route: route1 preparing to shutdown complete.
2011-12-02 14:37:37,694 [ - ShutdownTask] DEBUG ScheduledPollConsumer         
- This consumer is stopping, so cancelling scheduled task:
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask@c980c9
2011-12-02 14:37:37,694 [ - ShutdownTask] DEBUG FileConsumer                  
- Stopping consumer: Consumer[file://target/pair?move=ok]
2011-12-02 14:37:37,694 [ - ShutdownTask] DEBUG MockEndpoint$1                
- Stopping producer: Producer[mock://result]
2011-12-02 14:37:37,694 [ - ShutdownTask] INFO  DefaultShutdownStrategy       
- Route: route1 shutdown complete, was consuming from:
Endpoint[file://target/pair?move=ok]
2011-12-02 14:37:37,694 [main           ] INFO  DefaultShutdownStrategy       
- Graceful shutdown of 1 routes completed in 0 seconds
2011-12-02 14:37:37,694 [main           ] DEBUG RouteService                  
- Stopping services on route: route1
2011-12-02 14:37:37,694 [main           ] DEBUG RouteService                  
- Stopping child service on route: route1 ->
Consumer[file://target/pair?move=ok]
2011-12-02 14:37:37,694 [main           ] DEBUG RouteService                  
- Stopping child service on route: route1 ->
Instrumentation:route[UnitOfWork(Channel[choice{when tokenize[body() using
tokens: <hello>...</hello>]: Channel[sendTo(Endpoint[mock://result])],
otherwise: Processor is null}])]
2011-12-02 14:37:37,694 [main           ] DEBUG RouteService                  
- Stopping child service on route: route1 -> UnitOfWork(Channel[choice{when
tokenize[body() using tokens: <hello>...</hello>]:
Channel[sendTo(Endpoint[mock://result])], otherwise: Processor is null}])
2011-12-02 14:37:37,694 [main           ] DEBUG RouteService                  
- Stopping child service on route: route1 -> Channel[choice{when
tokenize[body() using tokens: <hello>...</hello>]:
Channel[sendTo(Endpoint[mock://result])], otherwise: Processor is null}]
2011-12-02 14:37:37,694 [main           ] DEBUG RouteService                  
- Stopping child service on route: route1 -> choice{when tokenize[body()
using tokens: <hello>...</hello>]: Channel[sendTo(Endpoint[mock://result])],
otherwise: Processor is null}
2011-12-02 14:37:37,694 [main           ] DEBUG RouteService                  
- Stopping child service on route: route1 -> Filter[if: tokenize[body()
using tokens: <hello>...</hello>] do:
Channel[sendTo(Endpoint[mock://result])]]
2011-12-02 14:37:37,694 [main           ] DEBUG RouteService                  
- Stopping child service on route: route1 ->
Channel[sendTo(Endpoint[mock://result])]
2011-12-02 14:37:37,694 [main           ] DEBUG RouteService                  
- Stopping child service on route: route1 -> sendTo(Endpoint[mock://result])
2011-12-02 14:37:37,694 [main           ] DEBUG RouteService                  
- Stopping child service on route: route1 -> Processor is null
2011-12-02 14:37:37,694 [main           ] DEBUG
DefaultExecutorServiceManager  - ShutdownNow ExecutorService:
java.util.concurrent.ThreadPoolExecutor@1549f94
2011-12-02 14:37:37,694 [main           ] INFO  DefaultInflightRepository     
- Shutting down with no inflight exchanges.
2011-12-02 14:37:37,694 [main           ] DEBUG SharedProducerServicePool     
- Stopping service pool:
org.apache.camel.impl.SharedProducerServicePool@867e89
2011-12-02 14:37:37,694 [main           ] DEBUG
DefaultExecutorServiceManager  - ShutdownNow ExecutorService:
java.util.concurrent.ScheduledThreadPoolExecutor@d1fa5
2011-12-02 14:37:37,694 [main           ] DEBUG
DefaultExecutorServiceManager  - ShutdownNow ExecutorService:
java.util.concurrent.ScheduledThreadPoolExecutor@1bd2664
2011-12-02 14:37:37,694 [main           ] INFO  DefaultCamelContext           
- Uptime: 5.375 seconds
2011-12-02 14:37:37,694 [main           ] INFO  DefaultCamelContext           
- Apache Camel  (CamelContext: camel-1) is shutdown in 0.015 seconds


--
View this message in context: http://camel.465427.n5.nabble.com/Riding-on-org-apache-camel-language-TokenPairPredicateTest-tp5041981p5041981.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Riding on org.apache.camel.language.TokenPairPredicateTest

Posted by bvahdat <ba...@swissonline.ch>.
@Claus

Would appreciate any update on the exception swallowing behaviour I
mentioned in [1] if you could spare time for it.

BTW that would be great if you could review the provided patch by [2], which
also contains the fix I mentioned in [3].

[1]
http://camel.465427.n5.nabble.com/Riding-on-org-apache-camel-language-TokenPairPredicateTest-tp5041981p5049061.html
[2] https://issues.apache.org/jira/browse/CAMEL-4687
[3]
http://camel.465427.n5.nabble.com/svn-commit-r1209404-in-camel-trunk-camel-core-src-main-java-org-apache-camel-impl-main-java-org-apac-td5041426.html#a5041639

Babak

--
View this message in context: http://camel.465427.n5.nabble.com/Riding-on-org-apache-camel-language-TokenPairPredicateTest-tp5041981p5051502.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Riding on org.apache.camel.language.TokenPairPredicateTest

Posted by Claus Ibsen <cl...@gmail.com>.
On Wed, Dec 7, 2011 at 9:41 AM, bvahdat <ba...@swissonline.ch> wrote:
> Good morning Claus,
>
> If you would go through all of my posts in this thread and read them
> carefully you will realize that my concern was *not* the failed unit test at
> all but the *behaviour* of the file consumer. Nevertheless if you still want
> it to be in that way I would be more than happy to do that, should I?
>

Yes posting in a new thread to avoid discussing 2+ things in the same
thread, is good practice.
Also a new thread with a better matching title, would attract other
Camel end users to read and participate.
They would normally not care about a failed unit test, and thus skip
reading the mails.



> Babak
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Riding-on-org-apache-camel-language-TokenPairPredicateTest-tp5041981p5054859.html
> Sent from the Camel - Users mailing list archive at Nabble.com.



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Riding on org.apache.camel.language.TokenPairPredicateTest

Posted by bvahdat <ba...@swissonline.ch>.
Good morning Claus,

If you would go through all of my posts in this thread and read them
carefully you will realize that my concern was *not* the failed unit test at
all but the *behaviour* of the file consumer. Nevertheless if you still want
it to be in that way I would be more than happy to do that, should I?

Babak

--
View this message in context: http://camel.465427.n5.nabble.com/Riding-on-org-apache-camel-language-TokenPairPredicateTest-tp5041981p5054859.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Riding on org.apache.camel.language.TokenPairPredicateTest

Posted by Claus Ibsen <cl...@gmail.com>.
Start a new thread if you start a new discussion. This thread was
about a failed unit test from camel-core on Windows.


On Mon, Dec 5, 2011 at 3:44 PM, bvahdat <ba...@swissonline.ch> wrote:
> Hi
>
> The fix you provided indeed did mitigated the issue I had on Windows
> (TokenPairPredicateTest now passes as well), however my viewpoint as I
> shared in [1] is still pending. Effectively what I would expect to have in
> LoggingExceptionHandler is the code below, which *per default* rethrows the
> exception after it logs it. However making that change in my workspace (of
> course) now causes side effects by other unit-tests to fail. So I assume to
> fix LoggingExceptionHandler *to not just swallow* the thrown exceptions will
> be not that trivial!
>
> Just as an example imagine a simple billing-system having a single camel
> context with two routes in it. One route produces the monthly bills and dump
> them into a xml-file (using the file producer), the other one reads that
> xml-file (through the file consumer), splits the bill-entries and send the
> bills to the consumers by mail. Now with that exception swalling behaviour
> of LoggingExceptionHandler in place, if generating/renaming/moving of the
> xml-file by the first route fails in between, for example just because of
> the possible:
>
> - disk out of space issue
> - maximum unix quota has been already reached issue
>
> Then the second route would wait & wait & wait forever and there will be not
> even an invocation of possible onException clause (if any) at all. So the
> operation guys will not realize any problem (not even through JMX or
> whatnot)...So happy free-service for the customers...
>
> How do you see this? Am I missing something?
>
> [1]
> http://camel.465427.n5.nabble.com/Riding-on-org-apache-camel-language-TokenPairPredicateTest-td5041981.html
>
> Babak
>
> public class LoggingExceptionHandler implements ExceptionHandler {
>    private final CamelLogger logger;
>    private final boolean rethrowException;
>
>    public LoggingExceptionHandler(Class<?> ownerType) {
>        this(new CamelLogger(LoggerFactory.getLogger(ownerType)), true);
>    }
>
>    public LoggingExceptionHandler(Class<?> ownerType, LoggingLevel level) {
>        this(new CamelLogger(LoggerFactory.getLogger(ownerType), level),
> true);
>    }
>
>    public LoggingExceptionHandler(Class<?> ownerType, boolean
> rethrowException) {
>        this(new CamelLogger(LoggerFactory.getLogger(ownerType),
> LoggingLevel.ERROR), rethrowException);
>    }
>
>    public LoggingExceptionHandler(Class<?> ownerType, LoggingLevel level,
> boolean rethrowException) {
>        this(new CamelLogger(LoggerFactory.getLogger(ownerType), level),
> rethrowException);
>    }
>
>    public LoggingExceptionHandler(CamelLogger logger, boolean
> rethrowException) {
>        this.logger = logger;
>        this.rethrowException = rethrowException;
>    }
>
>    public void handleException(Throwable exception) {
>        handleException(null, null, exception);
>    }
>
>    public void handleException(String message, Throwable exception) {
>        handleException(message, null, exception);
>    }
>
>    public void handleException(String message, Exchange exchange, Throwable
> exception) {
>        try {
>            String msg =
> CamelExchangeException.createExceptionMessage(message, exchange, exception);
>            if (isCausedByRollbackExchangeException(exception)) {
>                // do not log stacktrace for intended rollbacks
>                logger.log(msg);
>            } else {
>                logger.log(msg, exception);
>            }
>        } catch (Throwable e) {
>            // the logging exception handler must not cause new exceptions
> to occur
>        }
>
>        // rethrow the exception (wrapped by RuntimeCamelException) if we're
> asked to do so
>        if (rethrowException) {
>            throw ObjectHelper.wrapRuntimeCamelException(exception);
>        }
>    }
>
>    protected boolean isCausedByRollbackExchangeException(Throwable
> exception) {
>        if (exception instanceof RollbackExchangeException) {
>            return true;
>        } else if (exception.getCause() != null) {
>            // recursive children
>            return
> isCausedByRollbackExchangeException(exception.getCause());
>        }
>
>        return false;
>    }
> }
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Riding-on-org-apache-camel-language-TokenPairPredicateTest-tp5041981p5049061.html
> Sent from the Camel - Users mailing list archive at Nabble.com.



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Riding on org.apache.camel.language.TokenPairPredicateTest

Posted by bvahdat <ba...@swissonline.ch>.
Hi

The fix you provided indeed did mitigated the issue I had on Windows
(TokenPairPredicateTest now passes as well), however my viewpoint as I
shared in [1] is still pending. Effectively what I would expect to have in
LoggingExceptionHandler is the code below, which *per default* rethrows the
exception after it logs it. However making that change in my workspace (of
course) now causes side effects by other unit-tests to fail. So I assume to
fix LoggingExceptionHandler *to not just swallow* the thrown exceptions will
be not that trivial!

Just as an example imagine a simple billing-system having a single camel
context with two routes in it. One route produces the monthly bills and dump
them into a xml-file (using the file producer), the other one reads that
xml-file (through the file consumer), splits the bill-entries and send the
bills to the consumers by mail. Now with that exception swalling behaviour
of LoggingExceptionHandler in place, if generating/renaming/moving of the
xml-file by the first route fails in between, for example just because of
the possible:

- disk out of space issue
- maximum unix quota has been already reached issue 

Then the second route would wait & wait & wait forever and there will be not
even an invocation of possible onException clause (if any) at all. So the
operation guys will not realize any problem (not even through JMX or
whatnot)...So happy free-service for the customers...

How do you see this? Am I missing something?

[1]
http://camel.465427.n5.nabble.com/Riding-on-org-apache-camel-language-TokenPairPredicateTest-td5041981.html

Babak

public class LoggingExceptionHandler implements ExceptionHandler {
    private final CamelLogger logger;
    private final boolean rethrowException;

    public LoggingExceptionHandler(Class<?> ownerType) {
        this(new CamelLogger(LoggerFactory.getLogger(ownerType)), true);
    }

    public LoggingExceptionHandler(Class<?> ownerType, LoggingLevel level) {
        this(new CamelLogger(LoggerFactory.getLogger(ownerType), level),
true);
    }

    public LoggingExceptionHandler(Class<?> ownerType, boolean
rethrowException) {
        this(new CamelLogger(LoggerFactory.getLogger(ownerType),
LoggingLevel.ERROR), rethrowException);
    }

    public LoggingExceptionHandler(Class<?> ownerType, LoggingLevel level,
boolean rethrowException) {
        this(new CamelLogger(LoggerFactory.getLogger(ownerType), level),
rethrowException);
    }

    public LoggingExceptionHandler(CamelLogger logger, boolean
rethrowException) {
        this.logger = logger;
        this.rethrowException = rethrowException;
    }

    public void handleException(Throwable exception) {
        handleException(null, null, exception);
    }

    public void handleException(String message, Throwable exception) {
        handleException(message, null, exception);
    }

    public void handleException(String message, Exchange exchange, Throwable
exception) {
        try {
            String msg =
CamelExchangeException.createExceptionMessage(message, exchange, exception);
            if (isCausedByRollbackExchangeException(exception)) {
                // do not log stacktrace for intended rollbacks
                logger.log(msg);
            } else {
                logger.log(msg, exception);
            }
        } catch (Throwable e) {
            // the logging exception handler must not cause new exceptions
to occur
        }

        // rethrow the exception (wrapped by RuntimeCamelException) if we're
asked to do so
        if (rethrowException) {
            throw ObjectHelper.wrapRuntimeCamelException(exception);
        }
    }

    protected boolean isCausedByRollbackExchangeException(Throwable
exception) {
        if (exception instanceof RollbackExchangeException) {
            return true;
        } else if (exception.getCause() != null) {
            // recursive children
            return
isCausedByRollbackExchangeException(exception.getCause());
        }

        return false;
    }
}


--
View this message in context: http://camel.465427.n5.nabble.com/Riding-on-org-apache-camel-language-TokenPairPredicateTest-tp5041981p5049061.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Riding on org.apache.camel.language.TokenPairPredicateTest

Posted by Claus Ibsen <cl...@gmail.com>.
I created a ticket
https://issues.apache.org/jira/browse/CAMEL-4742

And have a fix for this in testing.



On Mon, Dec 5, 2011 at 10:01 AM, bvahdat <ba...@swissonline.ch> wrote:
>> Yeah could be OS specific. Do you use Windows?
>
> the issue is indeed OS specific which is Windows, just saw the retries logic
> in org.apache.camel.util.FileUtil.renameFile() as well as a lot of hits on
> Google...
>
> But as I've already mentioned in this thread that's not my concern at all
> but the way exchange routing behaves by the file component, as if there were
> no problem. It seems to me as if there is an onException claus on the route
> like:
>
> onException(java.lang.Exception.class).handled(true).continued(true);
>
> Which is not!
>
> Any thoughts?
>
> Babak
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Riding-on-org-apache-camel-language-TokenPairPredicateTest-tp5041981p5048255.html
> Sent from the Camel - Users mailing list archive at Nabble.com.



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Riding on org.apache.camel.language.TokenPairPredicateTest

Posted by bvahdat <ba...@swissonline.ch>.
> Yeah could be OS specific. Do you use Windows? 

the issue is indeed OS specific which is Windows, just saw the retries logic
in org.apache.camel.util.FileUtil.renameFile() as well as a lot of hits on
Google...

But as I've already mentioned in this thread that's not my concern at all
but the way exchange routing behaves by the file component, as if there were
no problem. It seems to me as if there is an onException claus on the route
like:

onException(java.lang.Exception.class).handled(true).continued(true);

Which is not!

Any thoughts?

Babak

--
View this message in context: http://camel.465427.n5.nabble.com/Riding-on-org-apache-camel-language-TokenPairPredicateTest-tp5041981p5048255.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Re: Riding on org.apache.camel.language.TokenPairPredicateTest

Posted by Claus Ibsen <cl...@gmail.com>.
Yeah could be OS specific. Do you use Windows?


On Fri, Dec 2, 2011 at 3:52 PM, bvahdat <ba...@swissonline.ch> wrote:
> BTW, on the CI-Servers the test passed by the last build [1], so that maybe
> it could be an OS issue as well.
>
> [1]
> https://builds.apache.org/job/Camel.trunk.fulltest/org.apache.camel$camel-core/576/testReport/org.apache.camel.language/TokenPairPredicateTest/
>
> Babak
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Riding-on-org-apache-camel-language-TokenPairPredicateTest-tp5041981p5042086.html
> Sent from the Camel - Users mailing list archive at Nabble.com.



-- 
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/

Re: Riding on org.apache.camel.language.TokenPairPredicateTest

Posted by bvahdat <ba...@swissonline.ch>.
BTW, on the CI-Servers the test passed by the last build [1], so that maybe
it could be an OS issue as well.

[1]
https://builds.apache.org/job/Camel.trunk.fulltest/org.apache.camel$camel-core/576/testReport/org.apache.camel.language/TokenPairPredicateTest/

Babak

--
View this message in context: http://camel.465427.n5.nabble.com/Riding-on-org-apache-camel-language-TokenPairPredicateTest-tp5041981p5042086.html
Sent from the Camel - Users mailing list archive at Nabble.com.