What means "No such channel"-Exception in Apache ODE?

Question

I have multiple BPEL-processes which runs fine on WSO2 (version 2.0.1). But after some time, there appears following exception in the log. I have no clue, what they means nor how to get rid of them.

Here is a snippet of the stacktrace:

[2011-10-05 11:28:26,541] ERROR -  Method "run" in class "org.apache.ode.bpel.rtrep.v2.RuntimeInstanceImpl$3" threw an unexpected exception. {org.apache.ode.jacob.vpu.JacobVPU}
java.lang.IllegalArgumentException: No such channel; id=71
at org.apache.ode.jacob.vpu.ExecutionQueueImpl.findChannelFrame(ExecutionQueueImpl.java:205)
at org.apache.ode.jacob.vpu.ExecutionQueueImpl.consumeExport(ExecutionQueueImpl.java:232)
at org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.importChannel(JacobVPU.java:369)
at org.apache.ode.jacob.JacobObject.importChannel(JacobObject.java:47)
at org.apache.ode.bpel.rtrep.v2.RuntimeInstanceImpl$3.run(RuntimeInstanceImpl.java:627)
at sun.reflect.GeneratedMethodAccessor41.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.ode.jacob.vpu.JacobVPU$JacobThreadImpl.run(JacobVPU.java:451)
at org.apache.ode.jacob.vpu.JacobVPU.execute(JacobVPU.java:139)
at org.apache.ode.bpel.rtrep.v2.RuntimeInstanceImpl.execute(RuntimeInstanceImpl.java:639)
at org.apache.ode.bpel.engine.BpelRuntimeContextImpl.execute(BpelRuntimeContextImpl.java:618)
at org.apache.ode.bpel.engine.ODEProcess.executeContinueInstanceTimerReceived(ODEProcess.java:476)
at org.apache.ode.bpel.engine.ODEProcess.execInstanceEvent(ODEProcess.java:684)
at org.apache.ode.bpel.engine.ODEProcess.access$000(ODEProcess.java:105)
at org.apache.ode.bpel.engine.ODEProcess$4.run(ODEProcess.java:619)
at org.apache.ode.bpel.engine.Contexts$1.call(Contexts.java:86)
at org.apache.ode.bpel.engine.Contexts$1.call(Contexts.java:85)
at org.apache.ode.bpel.engine.Contexts.execTransaction(Contexts.java:106)
at org.apache.ode.bpel.engine.Contexts.execTransaction(Contexts.java:83)
at org.apache.ode.bpel.engine.BpelServerImpl$TransactedRunnable.run(BpelServerImpl.java:893)
at org.apache.ode.bpel.engine.BpelInstanceWorker$2.call(BpelInstanceWorker.java:143)
at org.apache.ode.bpel.engine.BpelInstanceWorker$2.call(BpelInstanceWorker.java:142)
at org.apache.ode.bpel.engine.BpelInstanceWorker.doInstanceWork(BpelInstanceWorker.java:174)
at org.apache.ode.bpel.engine.BpelInstanceWorker.run(BpelInstanceWorker.java:141)
at org.apache.ode.bpel.engine.ODEProcess$ProcessRunnable.run(ODEProcess.java:1290)
at org.apache.ode.bpel.engine.BpelServerImpl$ServerRunnable.run(BpelServerImpl.java:839)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)

This the complete stacktrace from one of these exceptions. The errors seems to have no influence on the actual running processes, because the all do what the should. Can this be a configuration problem of my WSO2/ODE-Instance? Maybe it is a thread-pool-problem?!

Any help or hint would be great, thanks!

A larger log output would be helpful. It is definitely not a thread-pool issue. Did the engine die and has been restarted before showing this error? Can you reproduce it? — vanto, Oct 05 '11 at 17:06
thanks for you comment, i have updated the exception-log, so now you can see the full message. the engine did not die, all processes worked fine, even after this message, other and new processes are being handled correctly. i can reproduce it only so far, that the message comes always after some time of my last execution of a bpel-process. — oleh, Oct 06 '11 at 10:14

score 1 · Accepted Answer · edited Feb 21 '13 at 05:09

1

We were able to identify one issue that was causing the java.lang.IllegalArgumentException: No such channel; You can find the from following jira. https://wso2.org/jira/browse/BPS-218

These will be incorporated into the new releases.

edited Feb 21 '13 at 05:09

Andrew Barber

39,603
20
94
123

answered Feb 21 '13 at 05:00

Nandika

36
1

score 1 · Answer 2 · answered Oct 06 '11 at 14:47

1

From the logs, this is not a configuration issue but rather an internal bug. For some reason, the navigator receives a timer event (did you use <pick>s with onAlarm and/or event handlers?) but the callback channel for this timer does not exist (anymore). I could imagine such timers are scheduled but not removed when when the process instance is completed. Later when the timer is triggered the path to target activity is not available. This is just guess work but fits to your description. I only know the ODE and ODE 2.0-experimental code base and not much about WSO2's customizations so I'd suggest to file a bug in their JIRA.

answered Oct 06 '11 at 14:47

vanto

3,134
18
28

thanks vanto! i do have `pick`s with `onAlarm`s and `onMessage`s. is that the problem? my point is, that the processes should wait for the request only a limited time. after that it should do something else and not wait anymore. but that should not be something exotic for a bpel-process!? are there guidelines for this requirement? if it is a problem in a regular bpel-execution, i find it strange, that no one else have this. i searched for this for some time, but have not found one with the same issue. – oleh Oct 07 '11 at 06:43
No, it's rather a common practice than exotic. I'd do it the same way. What you could do to nail the issue down is to find a minimal example (e.g. just a pick with createInstance=true and a timeout). The instance will complete immediately and if later (after the timeout duration) the exception comes up, it is pretty clear that the outstanding timer has not been cancelled after the completion. Such an example will surely help the WSO2 and/or ODE team to reproduce the issue. All in all I don't think this is an exception to worry about. – vanto Oct 07 '11 at 09:21

score 0 · Answer 3 · edited Jan 18 '12 at 11:58

we ran into the same problem. We could nail it down and explore it with a small process example. See thread 17451 on the forum of wso2.org (http://wso2.org/forum/thread/17451).

A workaround might be to use a Timer instead of onAlarm. Remove the onAlarm and put a Timer activity in parallel to the pick activity. Wrap the pick and timer activity into a Scope and attach an exception handler to it. There's nothing to do in the exception handler, it just causes the engine to cancel all activities within the scope, including the timer (unfortunatley, an onAlarm is not cancelled).

Throw an exception whenever you want to cancel the timer and also in the activity-path of the timer to make the bpel engine get out of the (parallel) pick activity. A problem that might happen: The timer (i.e. the former onAlarm) could fire while the engine is not waiting in the pick-activity, but executing a regular onMessage before the exception fired...

Hi Folks, Can you try this distribution [BPS - SNAPSHOT](http://people.wso2.com/~waruna/wso2bps-2.1.0-SNAPSHOT.zip). This is a build from the trunk. I tried to reproduce your scenarios, but I failed. I used MySQL as the database. Let me know, if you can reproduce. — warunapww, Mar 12 '12 at 11:20

What means "No such channel"-Exception in Apache ODE?

3 Answers3