Hi guys,
Having looked through the architecture of the Human-Task module in
the last month or so, I've become fairly pessimistic about it.
The biggest problem I'm seeing is that the "wheel is reinvented" a
couple times -- and the "reinvented wheels" that are present in
the Human-Task service will be a pain to maintain/troubleshoot.
The "reinvented wheels" are things like the following:
- The server logic
- BaseJMSTaskServer, TaskServerHandler, etc.
- The client logic
- TaskClientHandler, the ResponseHandler and all it's
children classes)
- The asynchronous/concurrency logic
- AbstractBlockingResponseHandler{.waitTillDone(long) } and
every class that uses that method (and every class that uses
the class that uses that method.. etc.)
I think my frustration with this can best be expressed by the
fact that jBPM is a process engine project -- it's not a server
project, it's not a (service) client project, and it certainly
isn't a project that supports asynchronous communication. And yet,
we're implementing all 3 in the module. :/
Lastly, the human-task module code is the reason that the jbpm
builds (on hudson.jboss.org) have been failing for the last month
or so. And the tests are not failing because
the tests are wrong: the tests are failing because there's
a race condition in the code, and it occurs when you run the
human-task code on a 1. heavily loaded server that's experiencing
2. lots of network traffic. Which is what the hudson.jboss.org is.
I guess I'm wondering what other people's opinions about this are!
Thanks,
Marco
--
jBPM/Drools developer
Utrecht, the Netherlands
_______________________________________________
jbpm-dev mailing list
jbpm-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbpm-dev