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

Reply via email to