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 from
> C:\source\workspace\3.3-BoiseU3\integrations\camel\test-output\filedrop\test2.txt
> to test-output\filedrop\.done\test2.txt
> at
> org.apache.camel.component.file.FileOperations.renameFile(FileOperations.java:77)
> at
> org.apache.camel.component.file.strategy.GenericFileProcessStrategySupport.renameFile(GenericFileProcessStrategySupport.java:113)
> at
> org.apache.camel.component.file.strategy.GenericFileRenameProcessStrategy.commit(GenericFileRenameProcessStrategy.java:88)
> 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)
> Caused by: java.io.IOException: Renaming file from
> 'C:\source\workspace\3.3-BoiseU3\integrations\camel\test-output\filedrop\test2.txt'
> to 'test-output\filedrop\.done\test2.txt' failed: Cannot delete file
> 'C:\source\workspace\3.3-BoiseU3\integrations\camel\test-output\filedrop\test2.txt'
> after copy succeeded
> at
> org.apache.camel.util.FileUtil.renameFileUsingCopy(FileUtil.java:471)
> at org.apache.camel.util.FileUtil.renameFile(FileUtil.java:443)
> at
> org.apache.camel.component.file.FileOperations.renameFile(FileOperations.java:74)
>
> here is the method in GenericFileRenameProcessStrategy:
> @Override
> public void commit(GenericFileOperations<T> operations,
> GenericFileEndpoint<T> endpoint, Exchange exchange, GenericFile<T> file)
> throws Exception {
> try {
> if (commitRenamer != null) {
> // create a copy and bind the file to the exchange to be
> used by the renamer to evaluate the file name
> Exchange copy = exchange.copy();
> file.bindToExchange(copy);
> // must preserve message id
> copy.getIn().setMessageId(exchange.getIn().getMessageId());
> copy.setExchangeId(exchange.getExchangeId());
>
> GenericFile<T> newName = commitRenamer.renameFile(copy,
> file);
> renameFile(operations, file, newName);
> }
> } finally {
> // must invoke super
> super.commit(operations, endpoint, exchange, file);
> }
> }
>
> super.commit is what does the lock release, unfortunately you have to
> release the lock before deleting the file.
>
> There is no easy fix for this (short of ripping open the jar and replacing
> the code ) because this rename strategy doesn't appear to be pluggable
> piece.
>
> I can fix/avoid the issue by simply not releasing the lock during release
> and avoiding the error with my own version of the filelock strategy, but
> what's the point of creating a locking strategy that doesn't bother to keep
> its lock?
>
> I assume this has to be a bug. Any advice would be helpful.
>
> Any advice here would be helpful
>
>
>
>
>
>
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/FileLockExclusiveReadLockStrategy-doesn-t-hold-lock-and-error-on-commit-tp5762668.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/
