jBPM Concerns
ejimenez Sep 26, 2005 11:21 AMHi All,
I'm working on a rather complex project with jBPM and would like to see what other contributors think of some concerns I have. I will address them if necessary by customizing jBPM and would like to contribute changes. That way I also win because the project I'm working on can get other updates as jBPM continues to be improved in other areas. I should say up front I've looked at jBPM 3.0.1 and 3.0 so if some of these items are included in 3.02 or 3.1, let me know.
Basically, I'm working on a system that requires execution of about 300k workflows/day. Each workflow will have between 40-60 steps, most of them asynchronous. I am concerned about the following:
1) Number of relationships in schema. Its great that the model seems to be completely normalized, but it might make sense to denormalize just a little bit to ensure good performance. Anyone has had issues with performance in this sense? Anyone interested in proposals?
2) Not having looked at hibernate too much yet and how it is used within jBPM, this might sound silly but can hibernate's cache be turned off for most runtime process information and be turned on only for configuration and process definitions?
3) The size of the log table is of concern. With 300k workflows a day, it is going to be huge. Anyone interested in a built-in archiving mechanism so that old data can be taken to a two stage (online/offline) archive? The idea would be to also add capabilities to the API to search and return information on archived process instances. Another idea is to add the ability to reduce the logging level. Is this possible? I'm concerned about possible side effects of doing this and I kind of like keeping that information handy but recognize that the storage requirements for my production environment would be inmense.
4) Error handling: I know there are open issues about this, but would like to get opinions as to what your thoughts have been on revamping exception management in jBPM. There are two issues: fixing point cases where exceptions are not being trown-up and overall wrapping exception in jBPM-specific classes rather than using java.lang.RuntimeException, et al.
5) As I mentioned before, we will require asynchronous execution so we will add the capability to jBPM somehow. Would be interested in what Tom an others think about what the best way to accomplish that is.
Some of these are not issues in JIRA, if you would like to add them, its fine by me as long as someone has them assigned so that there is little work duplication. I will begin work on some parts of these enhancements sometime soon.
Thanks a lot for your time.
Eduardo