<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Oh and I nearly forgot:<br>
Rule number 4 on "How to have your emails ignored"<br>
<a class="moz-txt-link-freetext" href="http://labs.jboss.com/drools/">http://labs.jboss.com/drools/</a><br>
"Send emails directly to mailing list members, especially the
developers."<br>
<br>
Why send this email directly to me, instead of the user mailing list.
If you send it to me it only gets reviewed by me, or most likely
dev>null, if you send it to the mailing list it gets reviewed by
everyone. If every user did this when they needed/wanted something, can
you imagine how unproductive my life would become?<br>
<br>
Mark<br>
<br>
Mark Proctor wrote:
<blockquote cite="mid:47B83C25.9070208@codehaus.org" type="cite">
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
patches welcome.<br>
<br>
Mark<br>
<br>
<br>
Bhasin, Navaljit S wrote:
<blockquote
cite="mid:47219DA960243E46B94F26043713A3CB1B687E@TBRWS0033.us.qdx.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta content="MSHTML 6.00.2800.1607" name="GENERATOR">
<div><font face="Arial"><span class="820181403-17022008">Hi Mark,</span></font></div>
<div><font face="Arial" size="2"><span class="820181403-17022008"></span></font> </div>
<div><font face="Arial"><span class="820181403-17022008">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.</span></font></div>
<div><font face="Arial"><span class="820181403-17022008">This bug
is
noticeable on UNIX/Linux servers which are truly multi cpu. Works fine
on single cpu windows desktops.</span></font></div>
<div><font face="Arial"><span class="820181403-17022008">This seems
a
show stopper to me. I am not sure if this was previously reported to
you.</span></font></div>
<div><font face="Arial"><span class="820181403-17022008">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. </span></font></div>
</blockquote>
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.<br>
<blockquote
cite="mid:47219DA960243E46B94F26043713A3CB1B687E@TBRWS0033.us.qdx.com"
type="cite">
<div><font face="Arial"><span class="820181403-17022008">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.</span></font></div>
<div><font face="Arial"><span class="820181403-17022008">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.</span></font><font size="-0"><span
class="820181403-17022008"><font face="Arial">This needs be resolved
sooner.</font></span></font></div>
<div><font face="Arial"><span class="820181403-17022008"></span></font> </div>
<div><font face="Arial"><span class="820181403-17022008">Thanks for
reading this email.</span></font></div>
<div><font face="Arial"><span class="820181403-17022008"></span></font> </div>
<div><font face="Arial"><span class="820181403-17022008"><!-- Converted from text/rtf format -->
<p><i><span lang="en-us"><font color="#000080"
face="Monotype Corsiva">-Nav
Bhasin</font></span></i> </p>
<p><span lang="en-us"><font color="#008080" face="Monotype Corsiva">Navaljit
Bhasin</font> </span><br>
<span lang="en-us"><font color="#008080" face="Monotype Corsiva">Applications
Architect</font></span> <br>
<span lang="en-us"><font color="#008080" face="Batang">Quest
Diagnostics Reporting Services</font></span> <br>
<span lang="en-us"><font color="#008080" face="Tahoma" size="2">phone
number</font><font color="#008080" face="Tahoma" size="2">:201-729-7868</font></span>
</p>
</span></font></div>
<div><font face="Arial"><span class="820181403-17022008"></span></font> </div>
<div><font face="Arial" size="2"><span class="820181403-17022008"></span></font> </div>
<div><font face="Arial" size="2"><span class="820181403-17022008"></span></font> </div>
<br>
------------------------------------------ <br>
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.
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>