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.