Mule ESB-FileMessageReceiver中的ConcurrentModificationException

Question

我的Mule应用程序处理几个不同的目录，并在其中移动文件。 我有一些文件入站端点和文件连接器。 在某些情况下，我必须轮询不同的文件夹，处理文件，移动它们，再次轮询等。

我在日志中看到此异常：

java.util.ConcurrentModificationException
    at java.util.ArrayList.sort(ArrayList.java:1456)
    at java.util.Collections.sort(Collections.java:175)
    at org.mule.transport.file.FileMessageReceiver.poll(FileMessageReceiver.java:199)
    at org.mule.transport.AbstractPollingMessageReceiver.performPoll(AbstractPollingMessageReceiver.java:216)
    at org.mule.transport.PollingReceiverWorker.poll(PollingReceiverWorker.java:80)
    at org.mule.transport.PollingReceiverWorker.run(PollingReceiverWorker.java:49)
    at org.mule.transport.TrackingWorkManager$TrackeableWork.run(TrackingWorkManager.java:267)
    at org.mule.work.WorkerContext.run(WorkerContext.java:286)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

此处引发异常： http : //grepcode.com/file/repo1.maven.org/maven2/org.mule.transports/mule-transport-file/3.5.0/org/mule/transport/file/FileMessageReceiver。 java＃199

我注意到在这种情况下， http://grepcode.com/file/repo1.maven.org/maven2/org.mule.transports/mule-transport-file/3.5.0/org/mule/transport/file/ FileMessageReceiver.java＃675每次file.isEmpty（）都返回相同的集合对象-这不是理想的选择，很可能是问题的原因。

现在，幸运的是，此异常总体上不会造成破坏，只是它可能使它跳过轮询周期并污染了日志。

有人以前见过这个想法吗？

Answer 1

如果我在文件列表为空时更改listFiles（）实现，则异常消失。

package org.mule.transport.file;

import org.mule.api.MuleException;
import org.mule.api.construct.FlowConstruct;
import org.mule.api.endpoint.InboundEndpoint;
import org.mule.api.lifecycle.CreateException;
import org.mule.api.transport.Connector;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import java.io.File;
import java.util.ArrayList;
import java.util.List;

public class PatchedFileMessageReceiver extends FileMessageReceiver
{
    private static final Logger log = LoggerFactory.getLogger(PatchedFileMessageReceiver.class);

    /**
     *
     * @param connector
     * @param flowConstruct
     * @param endpoint
     * @param readDir
     * @param moveDir
     * @param moveToPattern
     * @param frequency
     * @throws CreateException
     */
    public PatchedFileMessageReceiver(Connector connector, FlowConstruct flowConstruct, InboundEndpoint endpoint, String readDir, String moveDir, String moveToPattern, long frequency) throws CreateException
    {
        super(connector, flowConstruct, endpoint, readDir, moveDir, moveToPattern, frequency);
    }

    /**
     *
     * @return
     * @throws MuleException
     */
    @Override
    List<File> listFiles() throws MuleException
    {
        List<File> list = super.listFiles();

        if(list.isEmpty()) {
            log.trace("List of files is empty, I'm gonna return a new empty ArrayList");
        }

        return ( list.isEmpty() ? new ArrayList<File>() : list );
    }
}

然后像这样在文件连接器上设置自定义FileMessageReceiver

<file:connector name="source-file-connector" autoDelete="false" fileAge="1000" pollingFrequency="1000" >
    <service-overrides messageReceiver="org.mule.transport.file.PatchedFileMessageReceiver" />
</file:connector>

这些东西应该确实固定在上游。 作为用户，人们期望不必处理此类问题。

Answer 2

看起来像个问题，应该确实解决。 我为您创建了一个问题 。 随时关注它，以了解修复进度。

Answer 3

与每次调用listFiles（）（并且没有文件）时返回一个新列表相比，更好的解决方案是对位于http://grepcode.com/file/repo1.maven.org/maven2/org.mule的 NO_FILES使用CopyOnWriteArrayList。 .transports / mule-transport-file / 3.5.0 / org / mule / transport / file / FileMessageReceiver.java＃64

private static final List<File> NO_FILES = new CopyOnWriteArrayList<File>();

这样，您将避免创建实例。