ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tammo van Lessen <tvanles...@gmail.com>
Subject Re: Raising Fault and halting the process when an one-way invocation fails
Date Wed, 18 Sep 2013 16:26:42 GMT
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 <jayawark@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 <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
> >
>



-- 
Tammo van Lessen - http://www.taval.de

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