Процессор компонента Univocity, демонстрирующий противоречивое поведение в распределенной системе - PullRequest
0 голосов
/ 29 июня 2018

Я использую bean-процессор univocity для анализа файлов. Я смог успешно использовать его на своем локальном ящике. Но при развертывании одного и того же кода в среде с несколькими узлами анализатор демонстрирует противоречивое поведение. Скажем, для недопустимых файлов, это не ошибка обработки, а также для правильных файлов, это не удается обработать несколько раз.

Хотелось бы узнать, подходит ли реализация процессора EJB для многопоточной распределенной среды.

Пример кода:

private void validateFile(@Nonnull final File inputFile) throws NonRetriableException {

    try {
        final BeanProcessor<TargetingInputBean> rowProcessor = new BeanProcessor<TargetingInputBean>(
                TargetingInputBean.class) {

            @Override
            public void beanProcessed(@Nonnull final TargetingInputBean targetingInputBean,
                    @Nonnull final ParsingContext context) {

                final String customerId = targetingInputBean.getCustomerId();
                final String segmentId = targetingInputBean.getSegmentId();
                log.debug("Validating customerId {} segmentId {}  for {} file", customerId, segmentId, inputFile
                        .getAbsolutePath());
                if (StringUtils.isBlank(customerId) || StringUtils.isBlank(segmentId)) {
                    throw new DataProcessingException("customerId or segmentId is blank");
                }

                try {
                    someValidation(customerId);
                } catch (IllegalArgumentException ex) {
                    throw new DataProcessingException(
                            String.format("customerId %s is not in required format. Exception"
                                    + " message %s", customerId, ex.getMessage()),
                            ex);
                }

            }
        };

        rowProcessor.setStrictHeaderValidationEnabled(true);

        final CsvParser parser = new CsvParser(getCSVParserSettings(rowProcessor));
        parser.parse(inputFile);
    } catch (TextParsingException ex) {
        throw new NonRetriableException(
                String.format("Exception=%s occurred while getting & parsing targeting file "
                        + "contents, error=%s", ex.getClass(), ex.getMessage()),
                ex);
    }

}

private CsvParserSettings getCSVParserSettings(@Nonnull final BeanProcessor<TargetingInputBean> rowProcessor) {

    final CsvParserSettings parserSettings = new CsvParserSettings();
    parserSettings.setProcessor(rowProcessor);
    parserSettings.setHeaderExtractionEnabled(true);
    parserSettings.getFormat().setDelimiter(AIRCubeTargetingFileConstants.FILE_SEPARATOR);
    return parserSettings;
}

TargetingInputBean:

public class TargetingInputBean {

@Parsed(field = "CustomerId")
private String customerId;

@Parsed(field = "SegmentId")
private String segmentId;
}

1 Ответ

0 голосов
/ 04 июля 2018

Вы используете последнюю версию?

Я только что понял, что вы, вероятно, затронуты ошибкой, появившейся в версии 2.5.0, которая была исправлена ​​в версии 2.5.6, если я не ошибаюсь. Это мучило меня некоторое время, так как это была внутренняя проблема параллелизма, которую было трудно отследить. В основном, когда вы передаете файл без явной кодировки, он попытается найти маркер UTF BOM во входных данных (эффективно используя первый символ), чтобы автоматически определить кодировку. Это произошло только для InputStreams и Files.

В любом случае, это было исправлено, поэтому простое обновление до последней версии должно избавить вас от проблемы (пожалуйста, дайте мне знать, если вы не используете версию 2.5.something)

Если вы хотите остаться с текущей версией, которая у вас есть, ошибка исчезнет, ​​если вы позвоните

parser.parse(inputFile, Charset.defaultCharset());

Это предотвратит попытку парсера выяснить, есть ли в вашем файле маркер спецификации, что позволит избежать этой неприятной ошибки.

Надеюсь, это поможет

...