Hi ,
I have a process which is running state, does the redeployement of the war going to change the state of the process running.
Please provide how can we solve this
Regards,
Sridhar
Sridhar, I think we have an answer to this. It appears that you must increment the version of the war file as well as make a material change to the workflow to get Camunda to recognize it as a new version.
Properly implemented, a hot upgrade should not drop inbound requests. Existing process instances will run under the version of the process they were started under. New requests will start under the new version unless they were started with an explicit version requested.
Removal of the old process version war files should probably not take place until all processes running under that version have completed. Although, I can’t say definitively whether its acceptable to do this. What I wouldn’t want is for the WildFly server to get clogged up with hundreds of different files.
Michael
Hi @mppfor_manu, @sridhar_akella,
undeployment of a war will affect your process. Engine is capable of handling versioning but you should first deploy a new war, then migrate instances, then undeploy old war.
You may implement custom versioning of the process definitions. If your process definition does not explicitly assign version, then engine will assign new version number itself.
Does that help you?
Askar.
Hi @sridhar_akella ,
no the redeployment of a war will not change the state of a running process.
The process definition is either-way persisted in the database, so there should no problems occur.
Bests,
Chris
will depend on isDeleteUponUndeploy I guess.
Cheers,
Askar.
So…if I use “Replace” in Widlflly to do redployment of the existing war… Does this going to affect existing running process.
if so, please suggest
Thanks,
Sridhar
@aakhmerov: As the your suggestion, “You may implement custom versioning of the process definitions. If your process definition does not explicitly assign version, then engine will assign new version number itself.”
- which camunda version is supporting the above versioning. please suggest
- Also, “If your process definition does not explicitly assign version, then engine will assign new version number itself” …So if deploy the process does this been taken care by camunda itself, please help if there is any exisiting example.
Thanks,
Sridhar
@Zelldon
If I use “Replace” in Widlflly to do redployment of the existing war… Does this going to affect existing running process.
if so, please suggest …
Thanks,
Sridhar
Testing indicates that the proper way to do this is to add the updated war file to the WildFly server. Camunda will recognize the new version and new process start requests will use it. I have confirmed this with tests where an external script was sending start requests to the server for a process that printed a number into the logs. Each iteration of the external script incremented this number and printed it with the version of the process that was executed.
I started the external script and it started to print out the version with the number of the current loop. I then deployed an updated workflow with a new version number. The log shows that the new process was then invoked and I could see the new version number with the next consecutive loop number. In other words, none of the inbound start requests were dropped. This is how we would expect it to behave.
What we don’t know is, when can we remove the old war file from the WildFly server? That doesn’t mean we remove the deployment from Camunda, only that we remove the war file so that the number of deployments seen by WildFly doesn’t become unmanageable.
Hi @aakhmerov.
do we have small working example for versioning.
- using @ProcessApplication for this
- without using @ProcessApplication
Please suggest. if they are any
Regards,
Sridhar Akella
as @Zelldon mentioned, as long as isDeleteUponUndeploy is not set to true in your processes.xml, nothing should happen to your process definitions on undeploy action. I.e. you can remove your .war’s as soon as you want. If you enable this option, then the version corresponding to this specific deployment will be deleted on undeployment. I.e. when you have 2 versions and deploy a .war file with isDeleteUponUndeploy=true, version 3 will get created. When you undeploy your .war, version 3 will be deleted, versions 1 and 2 will still remain in the system.
Does that help you?
Askar
The issue here is not persistence of the BPMN code stored in the database. It is the associated Java classes.
I think part of the “disconnect” is the fact that we (Sridhar and I work for the same company) are using the Eclipse plugin (now, sadly, deprecated) and so we think of a deployment as an entire Eclipse project that includes all BPMN, scripts, Java classes, and dependencies as the “deployment”. As such, if a deployment is removed, the associated BPMN code still remains in the database as Camunda doesn’t recognize removal of a deployment in the Java container. This removal takes with it the necessary Java classes required by the BPMN code.
Therefore, if you remove a deployment from WildFly, Camunda still maintains the BPMN code. When it tries to execute the code, the Java classes are no longer there, and you get an exception. The only way around this is to deploy a new version of the project that contains the necessary Java classes. If the BPMN code has changed, then Camunda will recognize that and use the new version of BPMN code. The Java classes will also be available because of the deployment.
The standalone Camunda modeler doesn’t support development of external Java classes and so deployment from it consists exclusively of BPMN and/or DMN code, all of which are persisted in the database and thus are unaffected by undeployment from Java container.
ok, I think we are not getting anywhere like that.
Could you please take code from here https://github.com/camunda/camunda-bpm-platform/tree/master/examples/invoice
do the redeployment and tell me if all is working for you as expected?
Or do the fork from it and adjust the code to illustrate what you are trying to do.
Cheers,
Askar
Askar, this is a result of misunderstanding the deployment process on our end.
Sorry for the confusion.
Michael
Hi mppfor_manu,
I don’t know the requirements to your throughput time, but I recommend to consider to mark the start event as ‘async after’. Then you can suspend the job definition in cockpit for deployment time and continue after the deployment is finished. All Java classes are back again and the processes, that are started during the deployment, can execute further.
Hope this helps, Ingo