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 <[email protected]>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 <[email protected] > >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 < > [email protected] > > >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 < > [email protected] > > > >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 < > > > [email protected] > > > > >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 < > [email protected]> > > > > > 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 < > > > > [email protected] > > > > > > >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 < > > > > > > > [email protected] > > > > > > > > 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 <[email protected] > > > > > > 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 < > > > > > > > > > [email protected]> 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
