Shouldn't there be a setting in DBCP configs?
paul
Le 18-janv.-10 à 13:44, Anca Luca a écrit :
> Hi Sergiu,
>
> On 01/18/2010 02:06 PM, Sergiu Dumitriu wrote:
>> On 01/18/2010 10:15 AM, Anca Luca wrote:
>>> Hi Flavius,
>>>
>>> On 01/17/2010 05:23 PM, Flavius Olaru wrote:
>>>> Hi,
>>>>
>>>> I've done a installation on my localhost (Windows XP machine) of XE
>>>> 2.1.1, Tomcat 6 and MySQL 5.1.
>>>> After this i wrote a bad hql query and executed it which brought
>>>> MySQL
>>>> to spyke the CPU usage to 100% and even more rendering both the
>>>> localhost and database unusable.
>>>>
>>>> {{velocity}}
>>>> #set($badhql = ", BaseObject obj, StringProperty stringprop,
>>>> LargeStringProperty largestringprop where (doc.name like '%$text
>>>> %' or
>>>> doc.content like '%$text%') or (obj.name=doc.fullName and
>>>> stringprop.id.id=obj.id and stringprop.value like '%$text%') or
>>>> (obj.name=doc.fullName and largestringprop.id.id=obj.id and
>>>> largestringprop.value like '%$text%')")
>>>
>>> as we already discussed (but logging here for posterity), I don't
>>> see why this
>>> would be called a "bad hql". It highly depends on the specific
>>> instance, the
>>> data in it, etc. Any query which is 'good' on one instance can be
>>> 'bad' on
>>> another one.
>>
>> This one IS bad, no matter how you try to look at it. It joins all
>> documents with all possible objects, and all possible string and
>> largestring properties, since the link between them is OR-ed, not
>> AND-ed. It should be a left(or right?)-join relationship, but
>> frankly in
>> my early, hasty tests with this kinds of joins in HQL, I never got
>> it to
>> work, since there are 4 tables to join. So, another approach would
>> be to
>> put the property test in an "or exists(...)", which is not as
>> performant
>> as a left join, but at least it selects properly matched objects and
>> properties.
>
> agreed for this particular case, but the discussion was about hqls
> which take
> too much time. To the limit, somebody might _actually_ need all
> these tables
> joined, and we wouldn't call that "bad", wouldn't we?
>
> If we put the problem like this, then we have a conversation about
> how to
> enforce people to join tables only by foreign keys (which we don't
> even have set
> in xwiki iirc), which is another discussion.
>
> Thanks,
> Anca
>
>>
>>>
>>> Also, the responsiveness / unresponsiveness of the server depends
>>> on the
>>> configuration of the machine, but I agree that there can be
>>> queries& instances
>>> that would render any machine (build with current technologies)
>>> unusable.
>>>
>>> I personally prefer to be able to write whatever I want, even if
>>> it renders the
>>> machine unusable, I needed it in some situations and I prefer this
>>> to _not_ be
>>> enforced: if I want a query to take longer, I should be able to do
>>> it and setup
>>> my own safety nets (warn user, etc). After all, it's an
>>> application platform and
>>> the application developers are (anyway, should be, in an ideal
>>> world)
>>> responsible of what they're writing.
>>>
>>>> #set($ok = $list.addAll(0, $xwiki.searchDocuments("$badhql")))
>>>>
>>>> {{include document="XWiki.Results"/}}
>>>> {{/velocity}}
>>>>
>>>> The bad thing is that $xwiki.searchDocuments brought me to this
>>>> state
>>>> (no programming rights.).
>>>
>>> If there would be a possibility to allow 'bad queries' only for
>>> programming APIs
>>> (considering that all other calls should be "safe"), then this
>>> could be a decent
>>> middle way, otherwise I'm for no limits.
>>>
>>>> Now my question is: Are there any remedies against this? MySQL
>>>> configuration statements that prevent this kind of behaviour?
>>>
>>> as Oana was remarking earlier in a conversation, the settings
>>> could be done on
>>> database server side, regardless of xwiki, and depending on what
>>> your specific
>>> needs on an instance are.
>>>
>>> Thanks,
>>> Anca
>>
> _______________________________________________
> users mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/users
_______________________________________________
users mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/users
