Reload KIE Deployments on app restart

[jay.guidos-bidstrading.com]

Hi All,

When I re-deploy my JEE app with an embedded KIE processing engine my KModuleDeploymentService deployments are gone.  It looks like they are not persisted in any way.

The deployments are still deployed - what is the best way to rebuild the deployments list?  Or should I just persist them myself and reload the deployment map on restart?

Jay

[swiderski.maciej]

deployments are not stored as part of the DeploymentService but fires events whenever units are deployed and undeployed and based on them you should implement storage that is preferred for your use case. kie-wb uses git repository for that. In the future we might provide data base storage for deployments with some monitoring agent to support clustering.

HTH

[jay.guidos-bidstrading.com]

Hi Maciej

I can and I have hooked into deployment events and persisted various deployment facts via my JPA module. My problem is that I need to reacquire handles to the RuntimeEngine on app restart and I have no idea how to do that.  I see that something in KIE knows about active deployments and restarts them during start up but I don't know how to participate in that, or find those re-started runtimes after the fact. 

In fact, I can't find anywhere a discussion on the 'right' way to stop and start JBoss (or even recover from failure) while deployments are deployed and processes are processing and Work Items are work-iteming. The docs are stubbornly vague, with only oblique references to what might need to be done and plenty of assurances that it is all possible. I would LOVE to see an entire chapter on the topic, complete with examples.

I am about ready to push to you my EJB-based KIE example project. Once I can:

1. Deploy a Project
2. Start a process with a long running work item
3. Stop and/or kill JBoss
4. Restart JBoss, restart long running process and see it finish
5. Start a second process on the original deployment and see it finish

Then my example project is complete and I will submit it.  Any hints you could provide would be appreciated!

Jay

[swiderski.maciej]

kie-wb uses CDI initialization phase to fetch deployments that were active when application was running and deploys them again. Deployments are stored in system repository of kie-wb. Since you have stored them in data base you should do simliar and actually you have quite few options:

- use CDI as we do in kie-wb, for that you can use jBPM CDI extension that will be invoked on cdi init phases, so you need to annotate your bean with this and declare extension in services file like this

- use servlet contenxt listener that will be invoked as soon as application is started

- use some ejb mechanisms like singleton with the post construct callback

Looking forward to see the application. Keep up the good work!

HTH

[jay.guidos-bidstrading.com]

Hi Maciej,

These are excellent tips, thanks very much. 

I am looking at code, and it seems that making a new RuntimeManager instance singleton gracefully handles finding a pre-existing ksession and all other persistent resources. That's great, but it seems that KModuleDeploymentService is only useful for deploying/undeploying units that were started while JBoss was running.  Once I have done a restart I have no way to undeploy without repeating all the code in KModuleDeploymentService, and all the other handy CDI helpers (eg. RuntimeDataService) again are not useful in a restart scenario.

It seems that a fertile approach would be to patch KModuleDeploymentService to allow a 'redeploy' or more accurately a 'restart'.  All the deploy eventing can be triggered and all non-persistent data will be rehydrated for both KModuleDeployment service and associated deployment listeners. The class annotated with @BootOnLoad would be responsible for calling the 'restart' method with all required info (unit identifier etc).

If you think this is a good approach I will again patch KModuleDeploymentService to include restart support. It looks like the underlying class (AbstractDeploymentService) already at least partially supports a restart anyway. If I am totally on the wrong track I would appreciate some pointers!

Jay

[swiderski.maciej]

Jay Guidos wrote:

Hi Maciej,

These are excellent tips, thanks very much.

I am looking at code, and it seems that making a new RuntimeManager instance singleton gracefully handles finding a pre-existing ksession and all other persistent resources. That's great, but it seems that KModuleDeploymentService is only useful for deploying/undeploying units that were started while JBoss was running.  Once I have done a restart I have no way to undeploy without repeating all the code in KModuleDeploymentService, and all the other handy CDI helpers (eg. RuntimeDataService) again are not useful in a restart scenario.

why would you like to undeploy RuntimeManager that actually does not exists? Since Jboss server was restarted all runtime managers are cleared from the memory so you need to recreated them again - recreate means deploy it once again. That's all that is needed during application start.

Jay Guidos wrote:

It seems that a fertile approach would be to patch KModuleDeploymentService to allow a 'redeploy' or more accurately a 'restart'.  All the deploy eventing can be triggered and all non-persistent data will be rehydrated for both KModuleDeployment service and associated deployment listeners. The class annotated with @BootOnLoad would be responsible for calling the 'restart' method with all required info (unit identifier etc).

I don't think you need to patch the KModuleDeploymentService at all. DeploymentService in general is only runtime resource that allows you to create executable representation of your deployment units. So imagine following scenario:

• first start of an application - no deployments available - so on startup nothing happens
• then you deploy single deployment unit, which in turn uses KModuleDeploymentService that does its thing and first an event that deployment happened
• then you observes such events and store information about deployments in data base for example
• next you shutdown the server, and start again, here on application startup some sort of a listener (see previous post about possible options) reads what is in the data base and finds single deployment unit
• found deployment unit is directly deployed on the deployment service and the RuntimeManager is created for it

same procedure you should apply for undeploy events, remove entires from the data base.

Does that make sense?

HTH

[swiderski.maciej]

btw, just created jira for data base store and will try to do it for 6.1.0 [JBPM-4225] Provide data base backed storage for deployments - JBoss Issue Tracker

HTH

[jay.guidos-bidstrading.com]

Cool!  Although redeploying via the methods you described above are really quite easy.  I was distracted by the language of KModuleDeploymentService and thought that "deploy" was a bigger process that just re-establishing runtime information.

BTW I could not get @BootOnLoad to work, when I gave that annotation to my CDI start up bean I got many deep mysterious exceptions, apparently by other CDI beans that also have the same annotation.  But a standard CDI @Startup bean worked fine.

Jay