[VOTE] Include event_handler_1x.patch into ODE-1.X

[Rafal Rusin]

Let's vote to include event_handler_1x.patch patch from here into ODE-1.X:
https://issues.apache.org/jira/browse/ODE-634

It may break some old instances during upgrade (but only those which 2
way message exchanges, which were not completed), But I think it's
worth committing.

Regards,
--
Rafał Rusin
http://www.touk.pl
http://top.touk.pl
http://people.apache.org/~rr/

[Rafal Rusin]

+1 from me

2009/11/6 Rafal Rusin <rafal.rusin@...>:

> Let's vote to include event_handler_1x.patch patch from here into ODE-1.X:
> https://issues.apache.org/jira/browse/ODE-634
>
> It may break some old instances during upgrade (but only those which 2
> way message exchanges, which were not completed), But I think it's
> worth committing.
>
> Regards,
> --
> Rafał Rusin
> http://www.touk.pl
> http://top.touk.pl
> http://people.apache.org/~rr/
>

--
Rafał Rusin
http://www.touk.pl
http://top.touk.pl
http://people.apache.org/~rr/

[Rafal Rusin]

Voting will remain open for 72 hours.

2009/11/6 Rafal Rusin <rafal.rusin@...>:

> Let's vote to include event_handler_1x.patch patch from here into ODE-1.X:
> https://issues.apache.org/jira/browse/ODE-634
>
> It may break some old instances during upgrade (but only those which 2
> way message exchanges, which were not completed), But I think it's
> worth committing.
>
> Regards,
> --
> Rafał Rusin
> http://www.touk.pl
> http://top.touk.pl
> http://people.apache.org/~rr/
>

--
Rafał Rusin
http://www.touk.pl
http://top.touk.pl
http://people.apache.org/~rr/

[Rafal Rusin]

Sorry guys, I forgot include weekend.
So the vote will remain open until 11 OCT 2009 00:00 GMT.

2009/11/6 Rafal Rusin <rafal.rusin@...>:

> Voting will remain open for 72 hours.
>
> 2009/11/6 Rafal Rusin <rafal.rusin@...>:
>> Let's vote to include event_handler_1x.patch patch from here into ODE-1.X:
>> https://issues.apache.org/jira/browse/ODE-634
>>
>> It may break some old instances during upgrade (but only those which 2
>> way message exchanges, which were not completed), But I think it's
>> worth committing.
>>
>> Regards,
>> --
>> Rafał Rusin
>> http://www.touk.pl
>> http://top.touk.pl
>> http://people.apache.org/~rr/
>>
>
>
>
> --
> Rafał Rusin
> http://www.touk.pl
> http://top.touk.pl
> http://people.apache.org/~rr/
>

--
Rafał Rusin
http://www.touk.pl
http://top.touk.pl
http://people.apache.org/~rr/

[Rafal Rusin]

11 NOV 2009 00:00 GMT.

2009/11/6 Rafal Rusin <rafal.rusin@...>:

> Sorry guys, I forgot include weekend.
> So the vote will remain open until 11 OCT 2009 00:00 GMT.
>
> 2009/11/6 Rafal Rusin <rafal.rusin@...>:
>> Voting will remain open for 72 hours.
>>
>> 2009/11/6 Rafal Rusin <rafal.rusin@...>:
>>> Let's vote to include event_handler_1x.patch patch from here into ODE-1.X:
>>> https://issues.apache.org/jira/browse/ODE-634
>>>
>>> It may break some old instances during upgrade (but only those which 2
>>> way message exchanges, which were not completed), But I think it's
>>> worth committing.
>>>
>>> Regards,
>>> --
>>> Rafał Rusin
>>> http://www.touk.pl
>>> http://top.touk.pl
>>> http://people.apache.org/~rr/
>>>
>>
>>
>>
>> --
>> Rafał Rusin
>> http://www.touk.pl
>> http://top.touk.pl
>> http://people.apache.org/~rr/
>>
>
>
>
> --
> Rafał Rusin
> http://www.touk.pl
> http://top.touk.pl
> http://people.apache.org/~rr/
>

--
Rafał Rusin
http://www.touk.pl
http://top.touk.pl
http://people.apache.org/~rr/

[Bill McCusker]

+1 from me

Rafal Rusin wrote:
> Let's vote to include event_handler_1x.patch patch from here into ODE-1.X:
> https://issues.apache.org/jira/browse/ODE-634
>
> It may break some old instances during upgrade (but only those which 2
> way message exchanges, which were not completed), But I think it's
> worth committing.
>
> Regards,
>  

[Karthick Sankarachary-3]

Rafal,

To mitigate against any potential compatibility issues, I suggest that you
write the OutstandingRequestManager such that it works even if the new field
that you added (i.e. _replyRid) has not been initialized. Specifically, if
that field is null you probably want to assume that there's no reply
corresponding to the entry in question. This sanity check will help ensure
that instances started prior to the upgrade do not break down due to this
change in the process model.

I will hold off on my vote until after I've had a chance to review the patch
completely.

Best Regards,
Karthick Sankarachary


On Fri, Nov 6, 2009 at 8:55 AM, Bill McCusker <wmccusker@...>wrote:

> +1 from me
>
>
> Rafal Rusin wrote:
>
>> Let's vote to include event_handler_1x.patch patch from here into ODE-1.X:
>> https://issues.apache.org/jira/browse/ODE-634
>>
>> It may break some old instances during upgrade (but only those which 2
>> way message exchanges, which were not completed), But I think it's
>> worth committing.
>>
>> Regards,
>>
>>
>
>

[Ciaran-3]

That branch currently has a rather large memory leak in it, I'd
definitely consider addressing that before
merging in substantial changes ! :)  (See my mail of 2 days ago in the
user list)
-cj.


On Fri, Nov 6, 2009 at 7:53 PM, Karthick Sankarachary
<sankarachary@...> wrote:

> Rafal,
>
> To mitigate against any potential compatibility issues, I suggest that you
> write the OutstandingRequestManager such that it works even if the new field
> that you added (i.e. _replyRid) has not been initialized. Specifically, if
> that field is null you probably want to assume that there's no reply
> corresponding to the entry in question. This sanity check will help ensure
> that instances started prior to the upgrade do not break down due to this
> change in the process model.
>
> I will hold off on my vote until after I've had a chance to review the patch
> completely.
>
> Best Regards,
> Karthick Sankarachary
>
>
> On Fri, Nov 6, 2009 at 8:55 AM, Bill McCusker <wmccusker@...>wrote:
>
>> +1 from me
>>
>>
>> Rafal Rusin wrote:
>>
>>> Let's vote to include event_handler_1x.patch patch from here into ODE-1.X:
>>> https://issues.apache.org/jira/browse/ODE-634
>>>
>>> It may break some old instances during upgrade (but only those which 2
>>> way message exchanges, which were not completed), But I think it's
>>> worth committing.
>>>
>>> Regards,
>>>
>>>
>>
>>
>

[Rafal Rusin]

2009/11/6 Karthick Sankarachary <sankarachary@...>:
> Rafal,
>
> To mitigate against any potential compatibility issues, I suggest that you
> write the OutstandingRequestManager such that it works even if the new field
> that you added (i.e. _replyRid) has not been initialized. Specifically, if
> that field is null you probably want to assume that there's no reply
> corresponding to the entry in question. This sanity check will help ensure
> that instances started prior to the upgrade do not break down due to this
> change in the process model.

OK, this sanity check looks easy to do. I can add that. But handling
all potentially broken cases in modified OutstandingRequestManager or
adding new class OutstandingRequestManager2 + iffs around code, would
be bad I think.

What I want to achieve with this vote is to see committers' and users'
opinions on backward compatibility for instances. Because I don't
believe that users care much for upgrading ODE from 1.3 to 1.4 with
holding their old binary instances.
As for me, I prefer more clean code, which is quite messy in some
places for now in ODE. And as for migration, I think it may be solved
some time in future by implementing export/import to/from xml
mechanism.
Similar thing is for ODE trunk. There are two packages for runtimes v1
and v2. I think it's a very bad solution for providing backward
compatibility, because it's a full duplication of code. I would prefer
to not provide backward compatibility and have only one runtime.

Well, if your opinion is opposite, please don't hesitate to vote -1.
It's just a simple voting, no offense at all.

Regards,
--
Rafał Rusin
http://www.touk.pl
http://top.touk.pl
http://people.apache.org/~rr/

[Karthick Sankarachary-3]

Rafal,

Here's the real reason why process model compatibility is such a thorny
problem. The fact is that we serialize and persist the process instance
state, which comprises instances of the process object model, every time the
process instance goes into a wait mode and has to be  dehydrated. If we
rehydrate the state of a process instance using a process object model that
is not compatible (i.e., whose classes no longer match the ones used at the
time of dehydration), then chances are the instance will fail, unless we
take measures to protect against the compatibility issue. The bottomline is
that it is hard to write a migration script (XML-based or not) that will
"fix" the process state for you. That was the motivation for forking
multiple versions of the process object model in the ODE trunk.

To simplify your sanity check, I would write a getter for the _replyRid
field, which in turn would initialize it to an empty hash, if it happens to
be null, which is what it'll be if you're dealing with an older instance.

Best Regards,
Karthick Sankarachary


On Fri, Nov 6, 2009 at 1:07 PM, Rafal Rusin <rafal.rusin@...> wrote:

> 2009/11/6 Karthick Sankarachary <sankarachary@...>:
> > Rafal,
> >
> > To mitigate against any potential compatibility issues, I suggest that
> you
> > write the OutstandingRequestManager such that it works even if the new
> field
> > that you added (i.e. _replyRid) has not been initialized. Specifically,
> if
> > that field is null you probably want to assume that there's no reply
> > corresponding to the entry in question. This sanity check will help
> ensure
> > that instances started prior to the upgrade do not break down due to this
> > change in the process model.
>
> OK, this sanity check looks easy to do. I can add that. But handling
> all potentially broken cases in modified OutstandingRequestManager or
> adding new class OutstandingRequestManager2 + iffs around code, would
> be bad I think.
>
> What I want to achieve with this vote is to see committers' and users'
> opinions on backward compatibility for instances. Because I don't
> believe that users care much for upgrading ODE from 1.3 to 1.4 with
> holding their old binary instances.
> As for me, I prefer more clean code, which is quite messy in some
> places for now in ODE. And as for migration, I think it may be solved
> some time in future by implementing export/import to/from xml
> mechanism.
> Similar thing is for ODE trunk. There are two packages for runtimes v1
> and v2. I think it's a very bad solution for providing backward
> compatibility, because it's a full duplication of code. I would prefer
> to not provide backward compatibility and have only one runtime.
>
> Well, if your opinion is opposite, please don't hesitate to vote -1.
> It's just a simple voting, no offense at all.
>
> Regards,
> --
> Rafał Rusin
> http://www.touk.pl
> http://top.touk.pl
> http://people.apache.org/~rr/ <http://people.apache.org/%7Err/>
>

[Greg Lucas-3]

+1 (non-binding) - this seems worth getting in.

On Fri, 06 Nov 2009 11:11:14 -0500, Rafal Rusin <rafal.rusin@...>  
wrote:

> Let's vote to include event_handler_1x.patch patch from here into  
> ODE-1.X:
> https://issues.apache.org/jira/browse/ODE-634
>
> It may break some old instances during upgrade (but only those which 2
> way message exchanges, which were not completed), But I think it's
> worth committing.
>
> Regards,


--
Greg Lucas

[Daniel Dominguez]

+1 - ditto

Greg Lucas wrote:

> +1 (non-binding) - this seems worth getting in.
>
> On Fri, 06 Nov 2009 11:11:14 -0500, Rafal Rusin
> <rafal.rusin@...> wrote:
>
>> Let's vote to include event_handler_1x.patch patch from here into
>> ODE-1.X:
>> https://issues.apache.org/jira/browse/ODE-634
>>
>> It may break some old instances during upgrade (but only those which 2
>> way message exchanges, which were not completed), But I think it's
>> worth committing.
>>
>> Regards,
>
>