[prev in list] [next in list] [prev in thread] [next in thread] 

List:       rhq-devel
Subject:    =?ISO-8859-2?Q?Re=3A_R=E3spuns=3A_AS7_plugin=3A_Hibernate_Query_Cache_reso?= =?ISO-8859-2?Q?urce_typ
From:       Van Dillon <vandillon () gmail ! com>
Date:       2013-12-03 17:58:07
Message-ID: CAB4ARSC7=EZPi0igQvTwes17D3gwpJM98vVnEeV3cd5009Un7Q () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


Can you discern between JMS temporary queues and regular queues?  I have
seen temporary queues show up as resources only to become unavailable.

-Van


On Tue, Dec 3, 2013 at 12:10 PM, Thomas Segismont <tsegismo@redhat.com>wrot=
e:

> My opinion is that Query Cache resources should not be auto discovered
> whereas JMS queues should be.
>
> Waiting for more input before taking action.
>
> Le 29/11/2013 12:49, Michael Burman a =E9crit :
>
>> Hi,
>>
>> Costel, on the other hand, JMS queues and their changing sizes are the
>> only thing we really monitor in our environment. That's a quick way to
>> find out if something is wrong, when queue's message amounts keep
>> growing (or a certain service shows such behaviour).
>>
>> There's no silver bullet to keep just certain resources.
>>
>>    - Micke
>>
>>
>> On Fri, Nov 29, 2013 at 1:17 PM, Costel Cosman <costelcsmn@yahoo.ro
>> <mailto:costelcsmn@yahoo.ro>> wrote:
>>
>>     Hi Thomas,
>>
>>     I was thinking the same thing with other resources too, like the
>>     EJBs, JMS queues, etc.
>>
>>     In our company we use RHQ to monitor production JBoss servers with a
>>     lot of EJBs but no one is really interested to monitor these EJBs or
>>     at least they are interested in monitoring only some of them.
>>     These useless resources bring unnecessary load on both RHQ server
>>     and agent. By default they are checked for the availability and have
>>     some metrics enabled.
>>
>>     An idea would be to have a lazy discovery for these resources - at
>>     request, maybe some configuration in the Connection Settings of the
>>     parent resource to enable the discovery of such child resources,
>>     maybe define a regexp pattern for the resource names we are
>>     interested in.
>>
>>
>>     Regards,
>>     Costel
>>
>>
>>     ------------------------------------------------------------
>> ------------
>>     *De la:* Thomas Segismont <tsegismo@redhat.com
>>     <mailto:tsegismo@redhat.com>>
>>     *C=E3tre:* rhq-devel@lists.fedorahosted.org
>>     <mailto:rhq-devel@lists.fedorahosted.org>
>>     *Trimis:* Vineri, 29 Noiembrie 2013 12:27:48
>>     *Subiect:* AS7 plugin: Hibernate Query Cache resource type
>>
>>
>>     Hi everyone,
>>
>>     I fixed "Bug 1033130 - [AS7] Exception during discovery of Query Cac=
he
>>     resources of RHQ Server resource" this week.
>>
>>     So what? Well now if you inventory RHQ server resource you get more
>>     than
>>     2000 query cache resources showing up. Which of course costs you CPU
>>     and
>>     memory.
>>
>>     You can of course just ignore this resource type (via the admin
>> pages).
>>
>>     So I was wondering: shouldn't we change such resource types to no
>>     longer
>>     auto discover them but only allow manual add?
>>
>>     Opinions?
>>
>>     Thanks,
>>     Thomas
>>     _______________________________________________
>>     rhq-devel mailing list
>>     rhq-devel@lists.fedorahosted.org
>>     <mailto:rhq-devel@lists.fedorahosted.org>
>>
>>     https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>>
>>
>>
>>     _______________________________________________
>>     rhq-devel mailing list
>>     rhq-devel@lists.fedorahosted.org
>>     <mailto:rhq-devel@lists.fedorahosted.org>
>>
>>     https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>>
>>
>>
>>
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel@lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>>
>>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel@lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>

[Attachment #5 (text/html)]

<div dir="ltr">Can you discern between JMS temporary queues and regular queues?  I \
have seen temporary queues show up as resources only to become \
unavailable.<div><br></div><div>-Van<br><div class="gmail_extra"><br><br><div \
class="gmail_quote">


On Tue, Dec 3, 2013 at 12:10 PM, Thomas Segismont <span dir="ltr">&lt;<a \
href="mailto:tsegismo@redhat.com" target="_blank">tsegismo@redhat.com</a>&gt;</span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex">


My opinion is that Query Cache resources should not be auto discovered whereas JMS \
queues should be.<br> <br>
Waiting for more input before taking action.<br>
<br>
Le 29/11/2013 12:49, Michael Burman a écrit :<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div> Hi,<br>
<br>
Costel, on the other hand, JMS queues and their changing sizes are the<br>
only thing we really monitor in our environment. That&#39;s a quick way to<br>
find out if something is wrong, when queue&#39;s message amounts keep<br>
growing (or a certain service shows such behaviour).<br>
<br>
There&#39;s no silver bullet to keep just certain resources.<br>
<br>
   - Micke<br>
<br>
<br>
On Fri, Nov 29, 2013 at 1:17 PM, Costel Cosman &lt;<a \
href="mailto:costelcsmn@yahoo.ro" \
target="_blank">costelcsmn@yahoo.ro</a><br></div><div> &lt;mailto:<a \
href="mailto:costelcsmn@yahoo.ro" target="_blank">costelcsmn@yahoo.ro</a>&gt;&gt; \
wrote:<br> <br>
    Hi Thomas,<br>
<br>
    I was thinking the same thing with other resources too, like the<br>
    EJBs, JMS queues, etc.<br>
<br>
    In our company we use RHQ to monitor production JBoss servers with a<br>
    lot of EJBs but no one is really interested to monitor these EJBs or<br>
    at least they are interested in monitoring only some of them.<br>
    These useless resources bring unnecessary load on both RHQ server<br>
    and agent. By default they are checked for the availability and have<br>
    some metrics enabled.<br>
<br>
    An idea would be to have a lazy discovery for these resources - at<br>
    request, maybe some configuration in the Connection Settings of the<br>
    parent resource to enable the discovery of such child resources,<br>
    maybe define a regexp pattern for the resource names we are<br>
    interested in.<br>
<br>
<br>
    Regards,<br>
    Costel<br>
<br>
<br></div>
    ------------------------------<u></u>------------------------------<u></u>------------<br>
                
    *De la:* Thomas Segismont &lt;<a href="mailto:tsegismo@redhat.com" \
target="_blank">tsegismo@redhat.com</a><br>  &lt;mailto:<a \
                href="mailto:tsegismo@redhat.com" \
                target="_blank">tsegismo@redhat.com</a>&gt;&gt;<br>
    *Către:* <a href="mailto:rhq-devel@lists.fedorahosted.org" \
target="_blank">rhq-devel@lists.fedorahosted.<u></u>org</a><br>  &lt;mailto:<a \
href="mailto:rhq-devel@lists.fedorahosted.org" \
                target="_blank">rhq-devel@lists.<u></u>fedorahosted.org</a>&gt;<br>
    *Trimis:* Vineri, 29 Noiembrie 2013 12:27:48<br>
    *Subiect:* AS7 plugin: Hibernate Query Cache resource type<div><br>
<br>
    Hi everyone,<br>
<br>
    I fixed &quot;Bug 1033130 - [AS7] Exception during discovery of Query Cache<br>
    resources of RHQ Server resource&quot; this week.<br>
<br>
    So what? Well now if you inventory RHQ server resource you get more<br>
    than<br>
    2000 query cache resources showing up. Which of course costs you CPU<br>
    and<br>
    memory.<br>
<br>
    You can of course just ignore this resource type (via the admin pages).<br>
<br>
    So I was wondering: shouldn&#39;t we change such resource types to no<br>
    longer<br>
    auto discover them but only allow manual add?<br>
<br>
    Opinions?<br>
<br>
    Thanks,<br>
    Thomas<br>
    ______________________________<u></u>_________________<br>
    rhq-devel mailing list<br>
    <a href="mailto:rhq-devel@lists.fedorahosted.org" \
target="_blank">rhq-devel@lists.fedorahosted.<u></u>org</a><br></div>  &lt;mailto:<a \
href="mailto:rhq-devel@lists.fedorahosted.org" \
target="_blank">rhq-devel@lists.<u></u>fedorahosted.org</a>&gt;<div><br>  <a \
href="https://lists.fedorahosted.org/mailman/listinfo/rhq-devel" \
target="_blank">https://lists.fedorahosted.<u></u>org/mailman/listinfo/rhq-devel</a><br>
 <br>
<br>
<br>
    ______________________________<u></u>_________________<br>
    rhq-devel mailing list<br>
    <a href="mailto:rhq-devel@lists.fedorahosted.org" \
target="_blank">rhq-devel@lists.fedorahosted.<u></u>org</a><br></div>  &lt;mailto:<a \
href="mailto:rhq-devel@lists.fedorahosted.org" \
target="_blank">rhq-devel@lists.<u></u>fedorahosted.org</a>&gt;<div><br>  <a \
href="https://lists.fedorahosted.org/mailman/listinfo/rhq-devel" \
target="_blank">https://lists.fedorahosted.<u></u>org/mailman/listinfo/rhq-devel</a><br>
 <br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
rhq-devel mailing list<br>
<a href="mailto:rhq-devel@lists.fedorahosted.org" \
target="_blank">rhq-devel@lists.fedorahosted.<u></u>org</a><br> <a \
href="https://lists.fedorahosted.org/mailman/listinfo/rhq-devel" \
target="_blank">https://lists.fedorahosted.<u></u>org/mailman/listinfo/rhq-devel</a><br>
 <br>
</div></blockquote><div><div>
<br>
______________________________<u></u>_________________<br>
rhq-devel mailing list<br>
<a href="mailto:rhq-devel@lists.fedorahosted.org" \
target="_blank">rhq-devel@lists.fedorahosted.<u></u>org</a><br> <a \
href="https://lists.fedorahosted.org/mailman/listinfo/rhq-devel" \
target="_blank">https://lists.fedorahosted.<u></u>org/mailman/listinfo/rhq-devel</a><br>
 </div></div></blockquote></div><br></div></div></div>


[Attachment #6 (text/plain)]

_______________________________________________
rhq-devel mailing list
rhq-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic