Hi Tammo,
I created the patch and attached to the jira.
However, when i executed the tests, TestConcurrentSyncMex and TestIMA
failed.
TestIMA test case failed with error
"Unexpected final message exchange status; got FAULT: {
http://docs.oasis-open.org/wsbpel/2.0/process/executable}conflictingRequest|
null, expected RESPONSE"
I think this is happening because, the FAILURE status is not reset as
before to ASYNC status.
Is there a way to handle this scenario
Thanks
Nandika
On Wed, Sep 18, 2013 at 9:56 PM, Tammo van Lessen <tvanles...@gmail.com>wrote:
> Hi Nandika,
>
> I'd treat it similar to the two-way invoke, which IMO does not send any
> special events, no?
>
> Looking forward to a patch, thanks!
>
> Cheers,
> Tammo
>
>
> On Wed, Sep 18, 2013 at 1:02 PM, Nandika Jayawardana <jayaw...@gmail.com
> >wrote:
>
> > Hi Tammo,
> >
> > I removed the break in the async case and added following ASYNC case to
> > invocationResponse2 method to call onResponse() on InvokeResponseChannel.
> >
> > switch (status) {
> > case FAULT:
> > evt.setAspect(ProcessMessageExchangeEvent.PARTNER_FAULT);
> > responseChannel.onFault();
> > break;
> > case RESPONSE:
> >
> evt.setAspect(ProcessMessageExchangeEvent.PARTNER_OUTPUT);
> > responseChannel.onResponse();
> > break;
> > case FAILURE:
> >
> evt.setAspect(ProcessMessageExchangeEvent.PARTNER_FAILURE);
> > responseChannel.onFailure();
> > break;
> > case ASYNC:
> > if(responseChannel != null)
> > responseChannel.onResponse();
> > break;
> > default:
> > __log.error("Invalid response state for mex " + mexid +
> ":
> > " + status);
> > }
> >
> >
> > Now It works fine and the ASYNC status of the mex is retained as well. So
> > when a failure happens, mex status would be FAILURE and otherwise ASYNC.
> > When the FAILURE is properly handled, it would return to ASYNC status.
> >
> > I am not sure which event should be fired though.
> >
> > I will create a patch and attach to issue [1]
> > https://issues.apache.org/jira/browse/ODE-714.
> >
> > Thanks for the help.
> >
> > Regards
> > Nandika
> >
> >
> > On Tue, Sep 17, 2013 at 2:30 PM, Tammo van Lessen <tvanles...@gmail.com
> > >wrote:
> >
> > > HI Nandika,
> > >
> > > I guess I'd need to dive deeper into this, but from what I looked at
> > right
> > > now, couldn't you just leave it ASYNC but remove the break in the ASYNC
> > > case of the switch:
> > >
> > > switch (mex.getStatus()) {
> > > case NEW:
> > > throw new AssertionError("Impossible!");
> > > case ASYNC:
> > > break;
> > > case RESPONSE:
> > > case FAULT:
> > > case FAILURE:
> > > invocationResponse(mex);
> > > break;
> > > default:
> > > __log.error("Partner did not acknowledge message
> > exchange:
> > > " + mex);
> > > mex.setFailure(FailureType.NO_RESPONSE, "Partner did
> not
> > > acknowledge.", null);
> > > invocationResponse(mex);
> > > }
> > >
> > > If this works, the meaning of the status would remain the same.
> > > WDYT?
> > >
> > > Tammo
> > >
> > >
> > > On Tue, Sep 17, 2013 at 10:15 AM, Nandika Jayawardana <
> > jayaw...@gmail.com
> > > >wrote:
> > >
> > > > Hi Tammo,
> > > >
> > > > Thanks for the reply.
> > > >
> > > > At BpelRuntimeContext.invoke, it was setting the ASYNC status despite
> > the
> > > > status is FAILURE in case of one way request. Now, I am not setting
> the
> > > > ASYNC status at all. I changed it to RESPONSE if there is no FAILURE
> > > status
> > > > so that InvokeResponseChannel onResponse is hit for the default
> > > successful
> > > > one way request and onFailure will be hit for the FAILURE scenario.
> > > >
> > > > I am concerned whether this has any impact on the other
> functionality.
> > I
> > > > tested with a sample process and it worked fine.
> > > >
> > > > Regards
> > > > Nandika
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, Sep 17, 2013 at 5:12 AM, Tammo van Lessen <
> > tvanles...@gmail.com
> > > > >wrote:
> > > >
> > > > > Hi Nandika,
> > > > >
> > > > > in general it looks good IMO, but I have the same concern about the
> > > > changed
> > > > > mex status. My educated guess is that it is fine,
> > > > > https://issues.apache.org/jira/browse/ODE-54 says that the ONE_WAY
> > mex
> > > > has
> > > > > been dropped in favor of ASYNC + REQUEST_ONLY, based on that I
> would
> > > > follow
> > > > > that a failed ONE_WAY would then be FAILURE + REQUEST_ONLY, which
> is
> > > > > exactly what you did, isn't it?
> > > > >
> > > > > Cheers,
> > > > > Tammo
> > > > >
> > > > >
> > > > > On Mon, Sep 16, 2013 at 12:27 PM, Nandika Jayawardana <
> > > > jayaw...@gmail.com
> > > > > >wrote:
> > > > >
> > > > > > I modified the following code sections of ode to make it work.
> > > > > >
> > > > > > For the one way invoke, when the service endpoint is down, then
> > axis2
> > > > > will
> > > > > > show the error message,
> > > > > > "INFO {org.apache.axis2.transport.http.HTTPSender} - Unable to
> > > > > sendViaPost
> > > > > > to url".
> > > > > > This exception is captured captured and sent to ode and is
> > available
> > > at
> > > > > > mex.
> > > > > >
> > > > > > At BpelRuntimeContextImpl.invoke method there is a comparison to
> > > check
> > > > > the
> > > > > > message exchange pattern and i changed that code as follows.
> > > > > >
> > > > > > Before change :
> > > > > > if
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> (mexDao.getPattern().equals(MessageExchangePattern.REQUEST_ONLY.toString()))
> > > > > > {
> > > > > >
> > > > mexDao.setStatus(MessageExchange.Status.ASYNC.toString());
> > > > > >
> > > > > > After change:
> > > > > > if
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> (mexDao.getPattern().equals(MessageExchangePattern.REQUEST_ONLY.toString()))
> > > > > > {
> > > > > > if(mex.getStatus() != MessageExchange.Status.FAILURE)
> > > > > >
> > > > > > mexDao.setStatus(MessageExchange.Status.RESPONSE.toString());
> > > > > >
> > > > > > and Then I added an InvokeResponseChannel at one way invoke
> > handling
> > > > > logic
> > > > > > as follows to INVOKE class.
> > > > > >
> > > > > > if (!isTwoWay) {
> > > > > > FaultData faultData = null;
> > > > > > InvokeResponseChannel invokeResponseChannel =
> > > > > > newChannel(InvokeResponseChannel.class);
> > > > > >
> > > > > > final String mexId =
> > > > > > getBpelRuntimeContext().invoke(_oinvoke.getId(),
> > > > > >
> _scopeFrame.resolve(_oinvoke.partnerLink),
> > > > > > _oinvoke.operation, outboundMsg,
> > > > > > invokeResponseChannel);
> > > > > >
> > > > > >
> > > > > > object(false, new
> > > > > > InvokeResponseChannelListener(invokeResponseChannel) {
> > > > > > public void onResponse() {
> > > > > > _self.parent.completed(null,
> > > > > > CompensationHandler.emptySet());
> > > > > > }
> > > > > >
> > > > > > public void onFault() {
> > > > > >
> > > > > > }
> > > > > >
> > > > > > public void onFailure() {
> > > > > > String reason =
> > > > > > getBpelRuntimeContext().getPartnerFaultExplanation(mexId);
> > > > > > __log.error("Failure during invoke:
> " +
> > > > > > reason);
> > > > > > try {
> > > > > > Element el =
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> DOMUtils.stringToDOM("<invokeFailure><![CDATA["+reason+"]]></invokeFailure>");
> > > > > > _self.parent.failure(reason, el);
> > > > > > } catch (Exception e) {
> > > > > > _self.parent.failure(reason,
> null);
> > > > > > }
> > > > > >
> > > > > > }
> > > > > > });
> > > > > > }
> > > > > >
> > > > > > I tested this logic and its propagating the one way invocation
> > > failure
> > > > to
> > > > > > bpel process correctly. Is this the correct way to solve this
> > > problem.
> > > > Is
> > > > > > there any impact in changing the mex status to RESPONSE from
> ASYNC.
> > > > > >
> > > > > > Regards
> > > > > > Nandika
> > > > > >
> > > > > >
> > > > > > On Tue, Jul 16, 2013 at 11:24 PM, Sathwik B P <
> > sathwik...@gmail.com>
> > > > > > wrote:
> > > > > >
> > > > > > > Keheliya,
> > > > > > >
> > > > > > > Would you be able to attach the error logs.
> > > > > > > What's the behavior with a sync call?
> > > > > > >
> > > > > > > regards,
> > > > > > > sathwik
> > > > > > >
> > > > > > > On Wed, Jul 10, 2013 at 9:45 PM, Tammo van Lessen <
> > > > > tvanles...@gmail.com
> > > > > > > >wrote:
> > > > > > >
> > > > > > > > Hi Keheliya,
> > > > > > > >
> > > > > > > > there is no workaround yet, it is probably a bit tricky as
> you
> > > will
> > > > > > need
> > > > > > > to
> > > > > > > > use an InvokeResponseChannel like in the two-way case but use
> > it
> > > > only
> > > > > > for
> > > > > > > > ACKing that the invoke was successful or NACKing if it was
> not.
> > > > > Should
> > > > > > > not
> > > > > > > > be too hard though.
> > > > > > > >
> > > > > > > > HTH,
> > > > > > > > Tammo
> > > > > > > >
> > > > > > > >
> > > > > > > > On Tue, Jul 9, 2013 at 2:17 PM, Keheliya Gallaba <
> > > > > > > > keheliya.gall...@gmail.com
> > > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > Hi Tammo,
> > > > > > > > >
> > > > > > > > > Yes. That looks like the same issue. Is there any other
> work
> > > > around
> > > > > > to
> > > > > > > > find
> > > > > > > > > out in the BPEL process when an one-way invoke fails due
> to a
> > > > > > transport
> > > > > > > > > error?
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Keheliya
> > > > > > > > >
> > > > > > > > > On 9 July 2013 17:27, Tammo van Lessen <
> tvanles...@gmail.com
> > >
> > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi Keheliya,
> > > > > > > > > >
> > > > > > > > > > If I understand you correctly, this is sort of a known
> > issue.
> > > > > Could
> > > > > > > you
> > > > > > > > > > verify that its related to
> > > > > > > > https://issues.apache.org/jira/browse/ODE-714
> > > > > > > > > ?
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > > Tammo
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Tue, Jul 9, 2013 at 12:15 PM, Keheliya Gallaba <
> > > > > > > > > > keheliya.gall...@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > > Hi devs,
> > > > > > > > > > >
> > > > > > > > > > > In ODE, when an invoke of the BPEL has an one-way call,
> > if
> > > > the
> > > > > > > > endpoint
> > > > > > > > > > is
> > > > > > > > > > > not reachable, it just prints the 'Unable to
> sendViaPost'
> > > > error
> > > > > > in
> > > > > > > > the
> > > > > > > > > > > console and continues to execute the rest of the
> process
> > > > > without
> > > > > > > > > raising
> > > > > > > > > > a
> > > > > > > > > > > fault or halting it. As described here[1] we can set
> > > > > > > 'faultOnFailure'
> > > > > > > > > to
> > > > > > > > > > > true. But it gets activated only when a TimeOut occurs
> > or a
> > > > > Fault
> > > > > > > > comes
> > > > > > > > > > in
> > > > > > > > > > > the response of a two-way message (so doesn't apply to
> > the
> > > > > > one-way
> > > > > > > > > > invoke)
> > > > > > > > > > > Am I missing something here? The requirement is to
> raise
> > a
> > > > > fault
> > > > > > > and
> > > > > > > > > halt
> > > > > > > > > > > the process flow when the back end service is
> unavailable
> > > or
> > > > > > > network
> > > > > > > > > > > failure in an one-way call. Is there any other way to
> > > achieve
> > > > > > this?
> > > > > > > > > > >
> > > > > > > > > > > Thanks,
> > > > > > > > > > > Keheliya
> > > > > > > > > > >
> > > > > > > > > > > [1]
> > > > > > > > >
> > > > >
> http://ode.apache.org/extensions/activity-failure-and-recovery.html
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Keheliya Gallaba
> > > > > > > > > > > More about me: http://about.me/keheliya
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Tammo van Lessen - http://www.taval.de
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Keheliya Gallaba
> > > > > > > > > More about me: http://about.me/keheliya
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Tammo van Lessen - http://www.taval.de
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Tammo van Lessen - http://www.taval.de
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Tammo van Lessen - http://www.taval.de
> > >
> >
>
>
>
> --
> Tammo van Lessen - http://www.taval.de
>
