[
https://issues.apache.org/jira/browse/ODE-644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868539#action_12868539
]
Phil commented on ODE-644:
--------------------------
Hi,
I just stumpled upon this issue using ODE 2.0 beta2. So I guess this not fixed
there yet, or have I found a new problem?
In my case, the error occurs after a receive from the outside, but
unfortunately not always. A second message with the same content then usually
works.
DEBUG - GeronimoLog.debug(66) | handleWorkEvent: MYROLE_INVOKE event for
process instance 152
FATAL - GeronimoLog.fatal(116) | INTERNAL ERROR: No ENTRY for RESPONSE CHANNEL
180
ERROR - GeronimoLog.error(108) | Work for instance
{http://www.example.com/exampleProcess}ExampleProcess-1#152 in thread
Thread[ODEServerImpl-10,5,main] resulted in an exception.
org.apache.ode.bpel.iapi.BpelEngineException:
java.lang.IllegalArgumentException: INTERNAL ERROR: No ENTRY for RESPONSE
CHANNEL 180
at org.apache.ode.bpel.engine.Contexts.execTransaction(Contexts.java:92)
The instance mentioned (152) is in fact the wrong one; it has already
terminated.
What is the status of this bug?
Thanks.
Phil
> INTERNAL ERROR: No ENTRY for RESPONSE CHANNEL [xy]
> --------------------------------------------------
>
> Key: ODE-644
> URL: https://issues.apache.org/jira/browse/ODE-644
> Project: ODE
> Issue Type: Bug
> Components: BPEL Runtime
> Affects Versions: 1.3.2, 2.0
> Reporter: William McCusker
> Fix For: 1.3.3, 2.0
>
> Attachments: responsechannel_hib_1x.diff,
> responsechannel_hib_trunk.diff, responsechannel_jpa_1x.diff,
> responsechannel_trunk_jpa.diff
>
>
> When a receive activity is repeated for the same partner link and operation
> (for example a pick activity inside of a while loop) the second message with
> often result inINTERNAL ERROR: No ENTRY for RESPONSE CHANNEL [xy] where xy
> ends up being the id of the old channel used for the first receive. In the
> JPA case this is because org.apache.ode.dao.jpa.CorrelatorDAOImpl
> removeLocalRoutes calls EntityManager remove but since it is using managed
> transactions these changes are not necessarily committed immediately.
> The mem dao should be unaffected by this, still need to test hibernate but it
> appears safe.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
