[
https://issues.apache.org/jira/browse/CAMEL-16084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17273846#comment-17273846
]
Jeremy Ross commented on CAMEL-16084:
-------------------------------------
Thanks Claus. B seems viable for my case, and I think C would be nice long-term
also. However, when using seda to achieve a synchronous effect:
{code:java}
from("seda:query?size=1&blockWhenFull=true")
{code}
I get: {{Cannot use existing queue seda://query as the existing queue size 1000
does not match given queue size 1}}
I haven't dug into this yet. I may have to set the queue size on the component
at the global level. Not sure why the {{size}} query option doesn't work.
I still have lingering questions:
* Why is Aggregate operating as if parallelProcessing=true? Should the docs
mention that the out leg of aggregate is always asynchronous?
* This was one of my attempted workarounds. It also sends unlimited number of
concurrent requests to salesforce. Shouldn't it only send one at a time?
{code:java}
.wireTap("direct:sendToSalesforce").executorService(
new
ThreadPoolBuilder(context).maxPoolSize(1).maxQueueSize(1).poolSize(1).build());
{code}
> 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)
