[rules-users] Re: Drools Multithreading issues

[Mark Proctor]

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.

patches welcome.

Mark


Bhasin, Navaljit S wrote:
> Hi Mark,
>  
> 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 
> scaling up.
> 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 
> issue.
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.
>  
>
> /-Nav Bhasin/
>
> Navaljit Bhasin
> Applications Architect
> Quest Diagnostics Reporting Services
> phone number:201-729-7868
>
>  
>  
>  
>
> ------------------------------------------
> 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. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/rules-users/attachments/20080217/b5955010/attachment.html