ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nandika Jayawardana <jayaw...@gmail.com>
Subject Re: Raising Fault and halting the process when an one-way invocation fails
Date Wed, 18 Sep 2013 11:02:43 GMT
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 <tvanlessen@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 <jayawark@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 <tvanlessen@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 <
> > jayawark@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.bp@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 <
> > > tvanlessen@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.gallaba@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 <tvanlessen@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.gallaba@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message