[jira] [Updated] (CAMEL-11656) Support default directory sorter for FileConsumer

2017-11-10 Thread Claus Ibsen (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-11656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-11656:

Fix Version/s: (was: Future)
   2.21.0

> Support default directory sorter for FileConsumer
> -
>
> Key: CAMEL-11656
> URL: https://issues.apache.org/jira/browse/CAMEL-11656
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Affects Versions: 2.19.0
>Reporter: Viktor Khoroshko
>Priority: Minor
> Fix For: 2.21.0
>
>
> Hello,
> The current way of sorting consumed files isn't very flexible due to how it's 
> implemented:
> Files are sorted AFTER they're added to in progress repository what in 
> combination with *maxMessagesPerPoll* set to be > 0  and 
> *eagerLimitMaxMessagesPerPoll* set to false forces the 
> *removeExcessiveInProgressFiles* call - which in case of persistent 
> idempotent repository used causes redundant calls to a database. 
> This is not only the issue.
> In my case I have a logic in a custom file filter that a file shouldn't be 
> processed if a file with a same prefix is already in progress while still 
> those files should be processed in a specified order. 
> The issue is that since sorting is performed after each file is added to in 
> progress repository and before added there a file should be accepted by a 
> filter but it will be not  - as a previous file with a same prefix has 
> already been added to in progress repo.
> *Example*: files  - test.001, test.002, test.003
> If test.003 is first in a returned file list then it will be added to in 
> progress repository and next files will not be accepted due to the same 
> prefix. 
> Default sorting would solve this issue. 
> It would be great if default sorter can be specified for *FileConsumer* in 
> the pollDirectory method:
> {code:java}
>   log.trace("Polling directory: {}", directory.getPath());
> File[] dirFiles = directory.listFiles();
> if (dirFiles == null || dirFiles.length == 0) {
> // no files in this directory to poll
> if (log.isTraceEnabled()) {
> log.trace("No files found in directory: {}", 
> directory.getPath());
> }
> return true;
> } else {
> // we found some files
> if (log.isTraceEnabled()) {
> log.trace("Found {} in directory: {}", dirFiles.length, 
> directory.getPath());
> }
> }
> List files = Arrays.asList(dirFiles);
>// sort there?
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (CAMEL-11656) Support default directory sorter for FileConsumer

2017-11-10 Thread Claus Ibsen (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-11656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-11656:

Issue Type: Improvement  (was: Wish)

> Support default directory sorter for FileConsumer
> -
>
> Key: CAMEL-11656
> URL: https://issues.apache.org/jira/browse/CAMEL-11656
> Project: Camel
>  Issue Type: Improvement
>  Components: camel-core
>Affects Versions: 2.19.0
>Reporter: Viktor Khoroshko
>Priority: Minor
> Fix For: 2.21.0
>
>
> Hello,
> The current way of sorting consumed files isn't very flexible due to how it's 
> implemented:
> Files are sorted AFTER they're added to in progress repository what in 
> combination with *maxMessagesPerPoll* set to be > 0  and 
> *eagerLimitMaxMessagesPerPoll* set to false forces the 
> *removeExcessiveInProgressFiles* call - which in case of persistent 
> idempotent repository used causes redundant calls to a database. 
> This is not only the issue.
> In my case I have a logic in a custom file filter that a file shouldn't be 
> processed if a file with a same prefix is already in progress while still 
> those files should be processed in a specified order. 
> The issue is that since sorting is performed after each file is added to in 
> progress repository and before added there a file should be accepted by a 
> filter but it will be not  - as a previous file with a same prefix has 
> already been added to in progress repo.
> *Example*: files  - test.001, test.002, test.003
> If test.003 is first in a returned file list then it will be added to in 
> progress repository and next files will not be accepted due to the same 
> prefix. 
> Default sorting would solve this issue. 
> It would be great if default sorter can be specified for *FileConsumer* in 
> the pollDirectory method:
> {code:java}
>   log.trace("Polling directory: {}", directory.getPath());
> File[] dirFiles = directory.listFiles();
> if (dirFiles == null || dirFiles.length == 0) {
> // no files in this directory to poll
> if (log.isTraceEnabled()) {
> log.trace("No files found in directory: {}", 
> directory.getPath());
> }
> return true;
> } else {
> // we found some files
> if (log.isTraceEnabled()) {
> log.trace("Found {} in directory: {}", dirFiles.length, 
> directory.getPath());
> }
> }
> List files = Arrays.asList(dirFiles);
>// sort there?
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (CAMEL-11656) Support default directory sorter for FileConsumer

2017-11-10 Thread Claus Ibsen (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-11656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-11656:

Estimated Complexity: Novice  (was: Unknown)

> Support default directory sorter for FileConsumer
> -
>
> Key: CAMEL-11656
> URL: https://issues.apache.org/jira/browse/CAMEL-11656
> Project: Camel
>  Issue Type: Wish
>  Components: camel-core
>Affects Versions: 2.19.0
>Reporter: Viktor Khoroshko
>Priority: Minor
> Fix For: Future
>
>
> Hello,
> The current way of sorting consumed files isn't very flexible due to how it's 
> implemented:
> Files are sorted AFTER they're added to in progress repository what in 
> combination with *maxMessagesPerPoll* set to be > 0  and 
> *eagerLimitMaxMessagesPerPoll* set to false forces the 
> *removeExcessiveInProgressFiles* call - which in case of persistent 
> idempotent repository used causes redundant calls to a database. 
> This is not only the issue.
> In my case I have a logic in a custom file filter that a file shouldn't be 
> processed if a file with a same prefix is already in progress while still 
> those files should be processed in a specified order. 
> The issue is that since sorting is performed after each file is added to in 
> progress repository and before added there a file should be accepted by a 
> filter but it will be not  - as a previous file with a same prefix has 
> already been added to in progress repo.
> *Example*: files  - test.001, test.002, test.003
> If test.003 is first in a returned file list then it will be added to in 
> progress repository and next files will not be accepted due to the same 
> prefix. 
> Default sorting would solve this issue. 
> It would be great if default sorter can be specified for *FileConsumer* in 
> the pollDirectory method:
> {code:java}
>   log.trace("Polling directory: {}", directory.getPath());
> File[] dirFiles = directory.listFiles();
> if (dirFiles == null || dirFiles.length == 0) {
> // no files in this directory to poll
> if (log.isTraceEnabled()) {
> log.trace("No files found in directory: {}", 
> directory.getPath());
> }
> return true;
> } else {
> // we found some files
> if (log.isTraceEnabled()) {
> log.trace("Found {} in directory: {}", dirFiles.length, 
> directory.getPath());
> }
> }
> List files = Arrays.asList(dirFiles);
>// sort there?
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (CAMEL-11656) Support default directory sorter for FileConsumer

2017-08-10 Thread Claus Ibsen (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-11656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-11656:

Priority: Minor  (was: Major)

> Support default directory sorter for FileConsumer
> -
>
> Key: CAMEL-11656
> URL: https://issues.apache.org/jira/browse/CAMEL-11656
> Project: Camel
>  Issue Type: Wish
>  Components: camel-core
>Affects Versions: 2.19.0
>Reporter: Viktor Khoroshko
>Priority: Minor
> Fix For: Future
>
>
> Hello,
> The current way of sorting consumed files isn't very flexible due to how it's 
> implemented:
> Files are sorted AFTER they're added to in progress repository what in 
> combination with *maxMessagesPerPoll* set to be > 0  and 
> *eagerLimitMaxMessagesPerPoll* set to false forces the 
> *removeExcessiveInProgressFiles* call - which in case of persistent 
> idempotent repository used causes redundant calls to a database. 
> This is not only the issue.
> In my case I have a logic in a custom file filter that a file shouldn't be 
> processed if a file with a same prefix is already in progress while still 
> those files should be processed in a specified order. 
> The issue is that since sorting is performed after each file is added to in 
> progress repository and before added there a file should be accepted by a 
> filter but it will be not  - as a previous file with a same prefix has 
> already been added to in progress repo.
> *Example*: files  - test.001, test.002, test.003
> If test.003 is first in a returned file list then it will be added to in 
> progress repository and next files will not be accepted due to the same 
> prefix. 
> Default sorting would solve this issue. 
> It would be great if default sorter can be specified for *FileConsumer* in 
> the pollDirectory method:
> {code:java}
>   log.trace("Polling directory: {}", directory.getPath());
> File[] dirFiles = directory.listFiles();
> if (dirFiles == null || dirFiles.length == 0) {
> // no files in this directory to poll
> if (log.isTraceEnabled()) {
> log.trace("No files found in directory: {}", 
> directory.getPath());
> }
> return true;
> } else {
> // we found some files
> if (log.isTraceEnabled()) {
> log.trace("Found {} in directory: {}", dirFiles.length, 
> directory.getPath());
> }
> }
> List files = Arrays.asList(dirFiles);
>// sort there?
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (CAMEL-11656) Support default directory sorter for FileConsumer

2017-08-10 Thread Claus Ibsen (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-11656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-11656:

Fix Version/s: Future

> Support default directory sorter for FileConsumer
> -
>
> Key: CAMEL-11656
> URL: https://issues.apache.org/jira/browse/CAMEL-11656
> Project: Camel
>  Issue Type: Wish
>  Components: camel-core
>Affects Versions: 2.19.0
>Reporter: Viktor Khoroshko
> Fix For: Future
>
>
> Hello,
> The current way of sorting consumed files isn't very flexible due to how it's 
> implemented:
> Files are sorted AFTER they're added to in progress repository what in 
> combination with *maxMessagesPerPoll* set to be > 0  and 
> *eagerLimitMaxMessagesPerPoll* set to false forces the 
> *removeExcessiveInProgressFiles* call - which in case of persistent 
> idempotent repository used causes redundant calls to a database. 
> This is not only the issue.
> In my case I have a logic in a custom file filter that a file shouldn't be 
> processed if a file with a same prefix is already in progress while still 
> those files should be processed in a specified order. 
> The issue is that since sorting is performed after each file is added to in 
> progress repository and before added there a file should be accepted by a 
> filter but it will be not  - as a previous file with a same prefix has 
> already been added to in progress repo.
> *Example*: files  - test.001, test.002, test.003
> If test.003 is first in a returned file list then it will be added to in 
> progress repository and next files will not be accepted due to the same 
> prefix. 
> Default sorting would solve this issue. 
> It would be great if default sorter can be specified for *FileConsumer* in 
> the pollDirectory method:
> {code:java}
>   log.trace("Polling directory: {}", directory.getPath());
> File[] dirFiles = directory.listFiles();
> if (dirFiles == null || dirFiles.length == 0) {
> // no files in this directory to poll
> if (log.isTraceEnabled()) {
> log.trace("No files found in directory: {}", 
> directory.getPath());
> }
> return true;
> } else {
> // we found some files
> if (log.isTraceEnabled()) {
> log.trace("Found {} in directory: {}", dirFiles.length, 
> directory.getPath());
> }
> }
> List files = Arrays.asList(dirFiles);
>// sort there?
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (CAMEL-11656) Support default directory sorter for FileConsumer

2017-08-10 Thread Claus Ibsen (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-11656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Claus Ibsen updated CAMEL-11656:

Component/s: camel-core

> Support default directory sorter for FileConsumer
> -
>
> Key: CAMEL-11656
> URL: https://issues.apache.org/jira/browse/CAMEL-11656
> Project: Camel
>  Issue Type: Wish
>  Components: camel-core
>Affects Versions: 2.19.0
>Reporter: Viktor Khoroshko
>
> Hello,
> The current way of sorting consumed files isn't very flexible due to how it's 
> implemented:
> Files are sorted AFTER they're added to in progress repository what in 
> combination with *maxMessagesPerPoll* set to be > 0  and 
> *eagerLimitMaxMessagesPerPoll* set to false forces the 
> *removeExcessiveInProgressFiles* call - which in case of persistent 
> idempotent repository used causes redundant calls to a database. 
> This is not only the issue.
> In my case I have a logic in a custom file filter that a file shouldn't be 
> processed if a file with a same prefix is already in progress while still 
> those files should be processed in a specified order. 
> The issue is that since sorting is performed after each file is added to in 
> progress repository and before added there a file should be accepted by a 
> filter but it will be not  - as a previous file with a same prefix has 
> already been added to in progress repo.
> *Example*: files  - test.001, test.002, test.003
> If test.003 is first in a returned file list then it will be added to in 
> progress repository and next files will not be accepted due to the same 
> prefix. 
> Default sorting would solve this issue. 
> It would be great if default sorter can be specified for *FileConsumer* in 
> the pollDirectory method:
> {code:java}
>   log.trace("Polling directory: {}", directory.getPath());
> File[] dirFiles = directory.listFiles();
> if (dirFiles == null || dirFiles.length == 0) {
> // no files in this directory to poll
> if (log.isTraceEnabled()) {
> log.trace("No files found in directory: {}", 
> directory.getPath());
> }
> return true;
> } else {
> // we found some files
> if (log.isTraceEnabled()) {
> log.trace("Found {} in directory: {}", dirFiles.length, 
> directory.getPath());
> }
> }
> List files = Arrays.asList(dirFiles);
>// sort there?
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)


[jira] [Updated] (CAMEL-11656) Support default directory sorter for FileConsumer

2017-08-09 Thread Viktor Khoroshko (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-11656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Viktor Khoroshko updated CAMEL-11656:
-
Description: 
Hello,

The current way of sorting consumed files isn't very flexible due to how it's 
implemented:

Files are sorted AFTER they're added to in progress repository what in 
combination with *maxMessagesPerPoll* set to be > 0  and 
*eagerLimitMaxMessagesPerPoll* set to false forces the 
*removeExcessiveInProgressFiles* call - which in case of persistent idempotent 
repository used causes redundant calls to a database. 

This is not only the issue.

In my case I have a logic in a custom file filter that a file shouldn't be 
processed if a file with a same prefix is already in progress while still those 
files should be processed in a specified order. 

The issue is that since sorting is performed after each file is added to in 
progress repository and before added there a file should be accepted by a 
filter but it will be not  - as a previous file with a same prefix has already 
been added to in progress repo.

*Example*: files  - test.001, test.002, test.003
If test.003 is first in a returned file list then it will be added to in 
progress repository and next files will not be accepted due to the same prefix. 
Default sorting would solve this issue. 

It would be great if default sorter can be specified for *FileConsumer* in the 
pollDirectory method:

{code:java}
  log.trace("Polling directory: {}", directory.getPath());
File[] dirFiles = directory.listFiles();
if (dirFiles == null || dirFiles.length == 0) {
// no files in this directory to poll
if (log.isTraceEnabled()) {
log.trace("No files found in directory: {}", 
directory.getPath());
}
return true;
} else {
// we found some files
if (log.isTraceEnabled()) {
log.trace("Found {} in directory: {}", dirFiles.length, 
directory.getPath());
}
}
List files = Arrays.asList(dirFiles);
   // sort there?
{code}





  was:
Hello,

The current way of sorting consumed files isn't very flexible due to how it's 
implemented:

Files are sorted AFTER they're added to in progress repository what in 
combination with *maxMessagesPerPoll* set to be > 0  and 
*eagerLimitMaxMessagesPerPoll* set to false forces the 
*removeExcessiveInProgressFiles* call - which in case of persistent idempotent 
repository used causes redundant calls to a database. 

This is not only the issue.

In my case I have a logic in a custom file filter that a file shouldn't be 
processed if a file with a same prefix is already in process while still those 
files should be processed in a specified order. 

The issue is that since sorting is performed after each file is added to in 
progress repository and before added there a file should be accepted by a 
filter but it will be not  - as a previous file with a same prefix has already 
been added to in progress repo.

*Example*: files  - test.001, test.002, test.003
If test.003 is first in a returned file list then it will be added to in 
progress repository and next files will not be accepted due to the same prefix. 
Default sorting would solve this issue. 

It would be great if default sorter can be specified for *FileConsumer* in the 
pollDirectory method:

{code:java}
  log.trace("Polling directory: {}", directory.getPath());
File[] dirFiles = directory.listFiles();
if (dirFiles == null || dirFiles.length == 0) {
// no files in this directory to poll
if (log.isTraceEnabled()) {
log.trace("No files found in directory: {}", 
directory.getPath());
}
return true;
} else {
// we found some files
if (log.isTraceEnabled()) {
log.trace("Found {} in directory: {}", dirFiles.length, 
directory.getPath());
}
}
List files = Arrays.asList(dirFiles);
   // sort there?
{code}






> Support default directory sorter for FileConsumer
> -
>
> Key: CAMEL-11656
> URL: https://issues.apache.org/jira/browse/CAMEL-11656
> Project: Camel
>  Issue Type: Wish
>Affects Versions: 2.19.0
>Reporter: Viktor Khoroshko
>
> Hello,
> The current way of sorting consumed files isn't very flexible due to how it's 
> implemented:
> Files are sorted AFTER they're added to in progress repository what in 
> combination with *maxMessagesPerPoll* set to be > 0  and 
> *eagerLimitMaxMessagesPerPoll* set to false forces the 
> *removeExcessiveInProgressFiles* call - which in case of persistent 
> idempotent repository used causes redundant calls to a database. 
> This is not only the issue.
> In my case I have a logic in a custom file filter th

[jira] [Updated] (CAMEL-11656) Support default directory sorter for FileConsumer

2017-08-09 Thread Viktor Khoroshko (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-11656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Viktor Khoroshko updated CAMEL-11656:
-
Description: 
Hello,

The current way of sorting consumed files isn't very flexible due to how it's 
implemented:

Files are sorted AFTER they're added to in progress repository what in 
combination with *maxMessagesPerPoll* set to be > 0  and 
*eagerLimitMaxMessagesPerPoll* set to false forces the 
*removeExcessiveInProgressFiles* call - which in case of persistent idempotent 
repository used causes redundant calls to a database. 

This is not only the issue.

In my case I have a logic in a custom file filter that a file shouldn't be 
processed if a file with a same prefix is already in process while still those 
files should be processed in a specified order. 

The issue is that since sorting is performed after each file is added to in 
progress repository and before added there a file should be accepted by a 
filter but it will be not  - as a previous file with a same prefix has already 
been added to in progress repo.

*Example*: files  - test.001, test.002, test.003
If test.003 is first in a returned file list then it will be added to in 
progress repository and next files will not be accepted due to the same prefix. 
Default sorting would solve this issue. 

It would be great if default sorter can be specified for *FileConsumer* in the 
pollDirectory method:

{code:java}
  log.trace("Polling directory: {}", directory.getPath());
File[] dirFiles = directory.listFiles();
if (dirFiles == null || dirFiles.length == 0) {
// no files in this directory to poll
if (log.isTraceEnabled()) {
log.trace("No files found in directory: {}", 
directory.getPath());
}
return true;
} else {
// we found some files
if (log.isTraceEnabled()) {
log.trace("Found {} in directory: {}", dirFiles.length, 
directory.getPath());
}
}
List files = Arrays.asList(dirFiles);
   // sort there?
{code}





  was:
Hello,

The current way of sorting consumed files isn't very flexible due to how it's 
implemented:

Files are sorted AFTER they're added to in progress repository what in 
combination with *maxMessagesPerPoll* set to be > 0  and 
*eagerLimitMaxMessagesPerPoll* set to false forces the 
*removeExcessiveInProgressFiles* call - which in case of persistent idempotent 
repository used causes redundant calls to a database. 

This is not only the issue.

In my case I have a logic in a custom file filter that a file shouldn't be 
processed if a file with a same prefix is already in process while still those 
files should be processed in a specified order. 

The issue is that since sorting is performed after each file is added to in 
progress repository and before added there a file should be accepted by a 
filter but it will be not  - as a previous file with a same prefix has already 
been added to in progress repo.

*Example*: files  - test.001, test.002, test.003
If test.003 is first in a returned file list then it will be added to in 
progress repository and next files will not be accepted due to the same prefix. 
Default sorting would solve this issue. 

It would be great if default sorter can be specified for *FileConsumer* in the 
pollDirectory method:

{code:java}
  log.trace("Polling directory: {}", directory.getPath());
File[] dirFiles = directory.listFiles();
if (dirFiles == null || dirFiles.length == 0) {
// no files in this directory to poll
if (log.isTraceEnabled()) {
log.trace("No files found in directory: {}", 
directory.getPath());
}
return true;
} else {
// we found some files
if (log.isTraceEnabled()) {
log.trace("Found {} in directory: {}", dirFiles.length, 
directory.getPath());
}
}
List files = Arrays.asList(dirFiles);
{code}






> Support default directory sorter for FileConsumer
> -
>
> Key: CAMEL-11656
> URL: https://issues.apache.org/jira/browse/CAMEL-11656
> Project: Camel
>  Issue Type: Wish
>Affects Versions: 2.19.0
>Reporter: Viktor Khoroshko
>
> Hello,
> The current way of sorting consumed files isn't very flexible due to how it's 
> implemented:
> Files are sorted AFTER they're added to in progress repository what in 
> combination with *maxMessagesPerPoll* set to be > 0  and 
> *eagerLimitMaxMessagesPerPoll* set to false forces the 
> *removeExcessiveInProgressFiles* call - which in case of persistent 
> idempotent repository used causes redundant calls to a database. 
> This is not only the issue.
> In my case I have a logic in a custom file filter that a file shouldn't be 

[jira] [Updated] (CAMEL-11656) Support default directory sorter for FileConsumer

2017-08-09 Thread Viktor Khoroshko (JIRA)

 [ 
https://issues.apache.org/jira/browse/CAMEL-11656?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Viktor Khoroshko updated CAMEL-11656:
-
Description: 
Hello,

The current way of sorting consumed files isn't very flexible due to how it's 
implemented:

Files are sorted AFTER they're added to in progress repository what in 
combination with *maxMessagesPerPoll* set to be > 0  and 
*eagerLimitMaxMessagesPerPoll* set to false forces the 
*removeExcessiveInProgressFiles* call - which in case of persistent idempotent 
repository used causes redundant calls to a database. 

This is not only the issue.

In my case I have a logic in a custom file filter that a file shouldn't be 
processed if a file with a same prefix is already in process while still those 
files should be processed in a specified order. 

The issue is that since sorting is performed after each file is added to in 
progress repository and before added there a file should be accepted by a 
filter but it will be not  - as a previous file with a same prefix has already 
been added to in progress repo.

*Example*: files  - test.001, test.002, test.003
If test.003 is first in a returned file list then it will be added to in 
progress repository and next files will not be accepted due to the same prefix. 
Default sorting would solve this issue. 

It would be great if default sorter can be specified for *FileConsumer* in the 
pollDirectory method:

{code:java}
  log.trace("Polling directory: {}", directory.getPath());
File[] dirFiles = directory.listFiles();
if (dirFiles == null || dirFiles.length == 0) {
// no files in this directory to poll
if (log.isTraceEnabled()) {
log.trace("No files found in directory: {}", 
directory.getPath());
}
return true;
} else {
// we found some files
if (log.isTraceEnabled()) {
log.trace("Found {} in directory: {}", dirFiles.length, 
directory.getPath());
}
}
List files = Arrays.asList(dirFiles);
{code}





  was:
Hello,

The current way of sorting consumed files isn't very flexible due to how it's 
implemented:

Files are sorted AFTER they're added to in progress repository what in 
combination with *maxMessagesPerPoll* set to be > 0  and 
*eagerLimitMaxMessagesPerPoll* set to false forces the 
*removeExcessiveInProgressFiles* call - which in case of persistent idempotent 
repository used causes redundant calls to a database. 

This is not only the issue.

In my case I have a logic in a custom file filter that a file shouldn't be 
processed if a file with a same prefix is already in process while still those 
files should be processed in a specified order. 

The issue is that since sorting is performed after each file is added to in 
progress repository and before added there a file should be accepted by a 
filter but it will be not  - as a previous file with a same prefix has already 
been added to in progress repo.

Default sorting would solve this issue. 

It would be great if default sorter can be specified for *FileConsumer* in the 
pollDirectory method:

{code:java}
  log.trace("Polling directory: {}", directory.getPath());
File[] dirFiles = directory.listFiles();
if (dirFiles == null || dirFiles.length == 0) {
// no files in this directory to poll
if (log.isTraceEnabled()) {
log.trace("No files found in directory: {}", 
directory.getPath());
}
return true;
} else {
// we found some files
if (log.isTraceEnabled()) {
log.trace("Found {} in directory: {}", dirFiles.length, 
directory.getPath());
}
}
List files = Arrays.asList(dirFiles);
{code}






> Support default directory sorter for FileConsumer
> -
>
> Key: CAMEL-11656
> URL: https://issues.apache.org/jira/browse/CAMEL-11656
> Project: Camel
>  Issue Type: Wish
>Affects Versions: 2.19.0
>Reporter: Viktor Khoroshko
>
> Hello,
> The current way of sorting consumed files isn't very flexible due to how it's 
> implemented:
> Files are sorted AFTER they're added to in progress repository what in 
> combination with *maxMessagesPerPoll* set to be > 0  and 
> *eagerLimitMaxMessagesPerPoll* set to false forces the 
> *removeExcessiveInProgressFiles* call - which in case of persistent 
> idempotent repository used causes redundant calls to a database. 
> This is not only the issue.
> In my case I have a logic in a custom file filter that a file shouldn't be 
> processed if a file with a same prefix is already in process while still 
> those files should be processed in a specified order. 
> The issue is that since sorting is performed after each file is added to in 
> progress re