[
https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747456#action_12747456
]
Enrico Levesque edited comment on ODE-483 at 8/31/09 1:58 PM:
--------------------------------------------------------------
I'm a graduate student in computer science and we've been thinking a bit on
this issue of migrating process instances. We've published an article on the
subject in 2008 (http://portal.acm.org/citation.cfm?id=1397774). Although it
was only the beginning of our thinking, we did came up with a sort of a replay
for solution. We added the complexity of having to migrate also the
collaborating processes, that's why we saw the replay as a possible solution,
with the idea of a synchronization with the other processes.
We were looking for an engine to use to implement our approach and when I saw
this Replayer I thought it would be good to give it a try for a start. I
applied the patch and tried it out on my own processes. It didn't work right
away, I had to fix the getCurrentEventDateTime in BpelRuntimeContextImpl so
that I could use getCommunication on my own processes. I have another problem
when I try to replay an incoming message that is suppose to be associated with
the instance through correlation. I noticed that it doesn't find the routing
info for the instance while it's looking into the database. Do you have any
idea of what could cause the problem?
was (Author: enricolds):
I'm a graduate student in computer science and we've been thinking a bit on
this issue of migrating process instances. We've published an article on the
subject in 2008 (http://portal.acm.org/citation.cfm?id=1397774). Although it
was only the beginning of our thinking, we did came up with a sort of a replay
for solution. We added the complexity of having to migrate also the
collaborating processes, that's why we saw the replay as a possible solution,
with the idea of a synchronization with the other processes.
This summer I was looking for an engine to work with and I saw that ODE came
with some functionality to suspend instances for migration. I started to look
up on migration in the forums, I followed some of the discussions on the
subject and I was directed to this Replayer of yours. I was very delighted to
see that the idea of replaying the exchanges between processes was thought of
something worth to try. It's not an easy thing to achieve, I agree with the
comments on the subject that it's probably not a task to fully automatize, but
there are some things we can automatize.
Anyhow, I applied the patch and tried it out on my own processes. It didn't
work right away, I had to fix the getCurrentEventDateTime in
BpelRuntimeContextImpl so that I could use getCommunication on my own
processes. I have another problem when I try to replay an incoming message that
is suppose to be associated with the instance through correlation. I noticed
that it doesn't find the routing info for the instance while it's looking into
the database. Do you have any idea of what could cause the problem?
> Instance replayer
> -----------------
>
> Key: ODE-483
> URL: https://issues.apache.org/jira/browse/ODE-483
> Project: ODE
> Issue Type: New Feature
> Affects Versions: Wishlist
> Reporter: Rafal Rusin
> Fix For: Wishlist
>
> Attachments: Khriss-AdaptabilitySupport.pdf, replayer-example.zip,
> replayer-proposal.diff
>
>
> Imagine situation when client has deployed a process with a lot of active,
> long running instances. Then he finds there's a bug in this process and a
> simple bugfix is needed. But with current versioning rules, new version is
> only used when new instances are created. So there's no simple way for doing
> such bufixes (which are usually possible with eg. java application using
> database connection). It is a blocking argument for deploying ODE Bpel
> solution instead of a regular java application.
> I think the best way to deal with such situations is to add
> serialize/deserialize to/from xml operations for process instances in
> management API. Also pause/resume ODE operations would be useful.
> Then, a bugfix procedure would look like this;
> -pause ode
> -serialize instances
> -deploy newer version
> -deserialize instances and fix manually any import errors
> -resume ODE
> It would also be a benefit of being able to do migration from older to newer
> ODE and between Hibernate/JPA DAOs, which I saw already in some bug reports.
> What do you think about it?
> Regards
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
