[
https://issues.apache.org/jira/browse/CAMEL-16084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17273448#comment-17273448
]
Claus Ibsen commented on CAMEL-16084:
-------------------------------------
Okay for such use case you may consider
a)
splitting up into 2 legs (routes) where you can store the aggregated into a
single file
read CSV
split CSV
aggreagate
save aggregate to disk
read aggregate from disk
to salesforce
Then the file reader is single threaded and wont slammer salesforce
Or b)
Use a seda queue where you can limit the size of the queue, and make the
producer block if full to avoid pushing too many pending tasks on the internal
seda queue while waiting for the consumer to catch up,
Or c)
We introduce synchronous=true|false on the direct component, then we can force
it to use sync mode which would automatic block in this situation.
> salesforce: Out of order execution
> ----------------------------------
>
> Key: CAMEL-16084
> URL: https://issues.apache.org/jira/browse/CAMEL-16084
> Project: Camel
> Issue Type: Bug
> Components: camel-salesforce
> Affects Versions: 3.7.1
> Reporter: Jeremy Ross
> Assignee: Jeremy Ross
> Priority: Major
>
> When using a salesforce operation after an aggregator, control seems to
> return to the aggregate caller immediately instead of proceeding with
> processors downstream from the salesforce operation. This is the behavior I'd
> expect if using the aggregator with parallelProcessing.
> I believe this is longstanding behavior, however with the removal of the
> `synchronous` option from the salesforce component (CAMEL-14138), we've
> removed a workaround to this issue.
> I'm seeing the same behavior with a salesforce operation via a wiretap with a
> threadpool with poolsize, maxsize and queuesize of 1, which should
> effectively behave in a synchronous manner.
> Test case: https://gist.github.com/jeremyross/4d7d14a33452edf236faefda77ad3e3d
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
