[
https://issues.apache.org/jira/browse/ODE-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jayant Vaish updated ODE-1010:
------------------------------
Attachment: ODE_1010.patch
To solve this issue we need to commit the transaction so the response is send
immediately and for further processing we should hand-over the work to new-job.
In existing code: we saw, to retry any activity we register a TIMER job which
executes the failure activity and from their the work is carry forwarded.
Using the same approach, to solve scenario 1 and 2 we after REPLY is executed
we are registering a timer job with no-wait so current transaction is committed
and all the work from here is picked by timer job immediately without any delay.
And for scenario 3, for one way invocation we are dong the same by registering
the timer job after the one-way invocation is done. Patch is also attached for
this solution.
> MEX response is sent with delay
> -------------------------------
>
> Key: ODE-1010
> URL: https://issues.apache.org/jira/browse/ODE-1010
> Project: ODE
> Issue Type: Bug
> Components: BPEL Runtime
> Reporter: Jayant Vaish
> Attachments: ODE_1010.patch
>
>
> In all the message exchanges where the response is send this issue comes
> which can be explained by following scenarios.
> Scenario 1: Synchronous messages exchange via wsdl call.
> When process is invoked and reply is send in "response" activity after that
> one forEach loop is their.Process is invoked by INVOKE_INTERNAL job and with
> the same job with REPLY, response is set and moves to forEach without sending
> the response, which is expected as response will be send after the
> transaction is committed (following code illustrates).
> _engine._contexts.scheduler.registerSynchronizer(new Scheduler.Synchronizer()
> {
> public void afterCompletion(boolean success) {
> __log.debug("Received myrole mex response callback");
> if( success ) {
> ResponseCallback callback = _waitingCallbacks.remove(cid);
> if (callback != null) callback.responseReceived();
> } else {
> __log.warn("Transaction is rolled back on sending back
> the response.");
> }
> }
> public void beforeCompletion() {
> }
> });
> So, the response is send after the forEach (there can be other scenarios as
> well other than forEach) which delays the response.
> Scenario 2: Synchronous messages exchange via template call.
> Instead of invoking process with wsdl call (as done in scenario 1) we do by
> template call (receive-reply two-way invocation) then also same issue comes
> as described in scenario 1.
> Scenario 3: Asynchronously sending response via template approach.
> Response is send by INVOKE_INTERNAL job and that job is not committed until
> forEach is executed.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
