[ 
https://issues.apache.org/jira/browse/ODE-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12651248#action_12651248
 ] 

Matthieu Riou commented on ODE-262:
-----------------------------------

A couple issues I can see:

 1. There are a few corner cases where we'll deny valid messages. Hopefully it 
won't  be too common.

 2. I'm not sure we can implement this without pretty much serializing new 
instance creation, to avoid race conditions. We can try to commit asap and rely 
on the route lock for non-instantiating but the throughput is still going to be 
impacted.

For more on 1. consider the following case where correlations are declared 
unique:

sequence {
  ...
  receive(pl, op, foo initiate=true, baz initiate=false);  // foo is the 
correlation
  ...
  receive(pl, op, bar initiate=true, baz initiate=false); // same partner link 
and operation, different correlation
  ...
}

When we receive a message, we only have the partner link and the operation. So 
to route we have to use all correlations on this pl/op tuple. Therefore on the 
first receive, we'll also have to check the bar correlation. If the message 
happens to contain an element that matches bar with a non unique value, we'll 
have to reject it. Even though it could be, strictly speaking, valid.

> Duplicated correlation set values is accepted and creates a second instance 
> instead of throwing an exception
> ------------------------------------------------------------------------------------------------------------
>
>                 Key: ODE-262
>                 URL: https://issues.apache.org/jira/browse/ODE-262
>             Project: ODE
>          Issue Type: Bug
>          Components: BPEL Runtime
>    Affects Versions: 1.1.1
>         Environment: Apache ODE 1.1.1 or 1.2
> Tomcat
> The counter example of infoq.
>            Reporter: Amin Anjomshoaa
>            Assignee: Karthick Sankarachary
>             Fix For: 2.0
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> The classical counter example of infoq 
> (http://www.infoq.com/articles/paul-brown-ode) can be used. Sending the 
> "init" message for the second (third, fourth, ... ) time with the value "foo" 
> will create a new instance. I was expecting a CorrelationViolation exception 
> when the second init message is arriving.
> All upcoming messages are then correlated with the last instance only. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to