[
https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12747456#action_12747456
]
Enrico Levesque commented on ODE-483:
-------------------------------------
Hi Rafal (and others interested in the subject),
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.
Is it possible that because the replay is done into a unique transaction, when
it tries to retrieve the routing info into the database, it fails because the
changes have not been commited yet? If this is the case, what would be the best
approach to save the changes at each step? I'm guessing that to suspend and
migrate the instances at play would be the right approach to take, so if
migration fails, I can restore instances to what it was prior to the replay. Is
the migration functionality of ODE ready to use? If yes, can someone direct me
to some more info on how it works? I'm still not quite familiar with all the
guts of ODE but I'll be working on this in the next few months, so any hints
would be welcome.
I also noticed that the idea of replaying has been let down for complexity
reasons, indeed it is very complexe. Try to add the collaborated processes into
the picture... it makes it even harder just to modelize the problem. We've
spent the winter playing with different scenarios of change and trying to
visualize what would happen during a collaborated migration.
We've decided to go with ODE for implementing our approach. I'll let you know
how it went. Thanks for this Replayer. It really helps for a good start in
implementing our ideas. I attached our article for consultation, it's really
just the beginning of our approach, we should submit another as soon as we have
some interesting results with ODE.
> 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: 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.
