I'm cc'ing in the user community for feedback on this. Personally I
don't think this is the case, I have google alerts for drools and jboss
rules and have yet to see people complaining about our unsatisfactory
community support. In fact I hear the exact opposite, the Drools core
devs make themselves extremely available to the community, more so than
my production managers would like. If you think can get this type of
available/response from other rule engine companies, or better, then
please go with them. However the feedback I've heard on other vendors
indicates you will be opening yourself up to a whole world of new hurt.
We tend to put out bug fix releases every two to three months. We do not
constantly work on and reviewing bugs in JIRAs, as we also have to work
on our main releases - so we tend to work on bug fixes in phases. The
only time this is not the case is for paying customers, where SLAs
obligate us to meet their needs in given time frames. We don't tend to
respond to "we aren't paying customers now, but if you fix X then we
might be" as every other free loader tries to tempt us with this carrot
and most do not fulfill on this once they have what they want - so
seriously that isn't going to prioritise your JIRAs higher than any
other JIRA, we've been doing this a long time and we just aren't that
nieve any more. Unless you are a paying customer JIRAs with
unit/integration tests tend to get picked up first which is why Edson
responded to JBRULES-1392 first before your JBRULES-1330. I might also
add that JIRAs must be kept brief but detailed, 1330 is full of waffle
when reviewing all the JIRAs, during a bug fixing session, I would have
read the first two lines and then moved yours to the back of the pile -
because 1) there was no unit/integration test 2) it was waffle and thus
hard to read 3) You aren't a paying customer thus no SLA.
Also lets look at 1392. We have Jan working with us creating tests and
providing valuable feedback. We just have you asking repeatedly for us
to give you the binaries because you can't get it to compile. Think on
that and then you'll see why Jan gets responses as he knows how to work
productively in an open source environment. Maybe you can try contacting
Jan directly and pooling your resources with him and learning from him,
he might also be able to help you get things compiling, as the core
developers just don't have the time for that.
I'd like to also remind you that there is no guarantee for community
response, anything that you get is a "gift", this is true of all open
source projects - please remember and appreciate this, not just the core
devs response, but also the rest of the community. If you want 2 hour
response times, then pay for it, where we do guarantee responses and to
fix any reasonable production stoppers. Also it is open source, you are
welcome to roll up your sleaves and fix these problems yourselves.
Bhasin, Navaljit S wrote:
We used Drools in an internal application. However we are running into
scalability issues, since drools cannot support a multithreaded
environment. We deploy rules as a service behind MessaeDrivenBeans.
Though all these MDB's create separate instances of Rulesbase, they
data still gets mixed up. It doesn't matter if we are using Stateless
or Stateful Session. We are virtually left with option of configuring
one instance of MDB for the entire application. No further room for
This bug is noticeable on UNIX/Linux servers which are truly multi
cpu. Works fine on single cpu windows desktops.
This seems a show stopper to me. I am not sure if this was previously
reported to you.
I opened a bug a few months ago, but nobody seemed to be willing to
fix it until recently when Edson Tirelli started working on related
The other one attached a test, yours did not. If you want something that
complicated fixed you need to invest your time in creating a
reproducable unit/integration test like Jan did from 1330. We have
already fixed many things from 1330 but it seems there are still a few
more things to fix. Edson is working on this as a priority with Jan and
we will release 4.0.5 once we are sure this is good.
There are many others on various blogs who are frustrated with no
response on drools multithreading issues. Needles to say, drools need
to support multithreading to scale.
We are even ready to subscribe to commercial support, but we will like
to get this bug resolved first. So far the response has been far from
satisfactory. This is a show stopper for us. We are beginning to
evaluate JESS. We really want to continue with Drools, since the
developers are already working on this.This needs be resolved sooner.
Thanks for reading this email.
Quest Diagnostics Reporting Services
The contents of this message, together with any attachments, are
intended only for the use of the person(s) to which they are addressed
and may contain confidential and/or privileged information. Further,
any medical information herein is confidential and protected by law.
It is unlawful for unauthorid persons to use, review, copy, disclose,
or disseminate confidential medical information. If you are not the
intended recipient, immediately advise the sender and delete this
message and any attachments. Any distribution, or copying of this
message, or any attachment, is prohibited.