[
https://issues.apache.org/jira/browse/ODE-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12717963#action_12717963
]
Rafal Rusin commented on ODE-483:
---------------------------------
Here's a proposal for interface and implementation (includes proper timers
support).
The basic use cases for replayer are:
1. migrate existing log running instances to newest process version
given their communication (incoming and outgoing requests)
2. reproduce error scenarios between two instances of ODE (eg.
production and development)
Interface:
Extends management api by 2 operations: replay and getCommunication.
In order to do 1, you invoke:
<pmap:replay>
<replay>
<ns:upgradeInstance>1234</ns:upgradeInstance>
</replay>
</pmap:replay>
You get a new instance in the newest process version. The old one is deleted.
To do 2, you need to retrieve exchanges from instance (or instances) by:
<pmap:getCommunication>
<getCommunication>
<ns:iid>1234</ns:iid>
</getCommunication>
</pmap:getCommunication>
Then, you execute replay on the other ODE installation to replicate instance:
<pmap:replay xmlns:ns="http://www.apache.org/ode/pmapi/types/2006/08/02/";>
<replay>
<ns:restoreInstance>
<ns:processType
xmlns:p="http://sample.bpel.org/bpel/sample";>p:OnEventCorrelation</ns:processType>
... exchanges
</ns:restoreInstance>
</replay>
</pmap:replay>
To have control over time in bpel process, I introduced a variable
$ode:currentEventDateTime. It's equivalent to $fn:current-dateTime()
during live session and it's set to corresponding time in past during
replaying.
I think this interface is quite simple and solves it's job well.
Implementation notes:
- It works in one transaction.
You can migrate a few instances at once and get an error, which will
roll back all work if an error occurrs in some case.
- It extends BpelRuntimeContextImpl by ReplayerBpelRuntimeContextImpl
class, which overrides methods like invoke and registerTimer to mock
up communication
- It implements ReplayerScheduler, which executes actions from past in
time sorted order (exchanges given to replayer have createTime field,
which is used for sorting)
- jobs from past are processed in ReplayerScheduler and jobs in
future are registered in engine's scheduler.
- In order to make integrity constraints, replaying returns error if:
- a first incoming request is routed to an existing instance instead
of creating a new one
- next incoming request is routed to other instance or creates a new instance
- there is some unprocessed communication while finishing replaying
(for example if there is some outgoing exchange for service, which did
not have INVOKE from replayed instance)
- It extends bpel-compiler and xpath evaluation by
$ode:currentEventDateTime variable
- It adds currentEventDateTime property to BpelRuntimeContext
- It adds replayer package to bpel engine in bpel-runtime module
- It changes visibility of some fields and methods in bpel engine from
private to protected and from optional to public.
Attached are:
- replayer-proposal.diff - an implementation applicable for ODE1X
branch, rev. 777412
- test process for axis2 distro with soapui 2.5.2 test case
demonstrating usage of replayer.
Limitations:
- It currently works only with hibernate DAO, on Axis2 and JBI distros.
> Add serialize/deserialize process instances in Management API
> -------------------------------------------------------------
>
> 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
>
>
> 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.
