Picon
Favicon

[jira] [Created] (SOLR-3083) all JMX Mbeans are identified as java.lang.String even if numeric

all JMX Mbeans are identified as java.lang.String even if numeric
-----------------------------------------------------------------

                 Key: SOLR-3083
                 URL: https://issues.apache.org/jira/browse/SOLR-3083
             Project: Solr
          Issue Type: Bug
          Components: SearchComponents - other
    Affects Versions: 3.5
            Reporter: Tagged Siteops
            Priority: Minor

When trying to monitor our Solr instances with JMXtrans (https://github.com/lookfirst/jmxtrans), we
discovered that all the Mbeans were identifying themselves as java.lang.String.   This breaks the
GangliaWriter in JMXtrans because the software decides it's a string instead of a numeric values and you
can't graph a string.   Other software we are monitoring with JMXtrans (e.g. Kafka) correctly identify
their numeric values as numbers (doubles in this case).

For example, avgTimePerRequest in Solr is identified as a string which makes no sense.  This behavior makes
Solr less interoperable with the rest of the Java ecosystem.

The problem code is in JmxMonitoredMap.java

NamedList dynamicStats = infoBean.getStatistics();
if (dynamicStats != null) {
  for (int i = 0; i < dynamicStats.size(); i++) {
    String name = dynamicStats.getName(i);
    if (!staticStats.contains(name))
      attrInfoList.add(new MBeanAttributeInfo(dynamicStats.getName(i),
              String.class.getName(), null, true, false, false));
(Continue reading)

Picon
Favicon

[jira] [Updated] (SOLR-3083) all JMX Mbeans are identified as java.lang.String even if numeric


     [
https://issues.apache.org/jira/browse/SOLR-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tagged Siteops updated SOLR-3083:
---------------------------------

    Attachment: Screen shot 2012-01-31 at 2.19.06 PM.png

Screenshot showing all beans as strings despite being obviously numeric.

> all JMX Mbeans are identified as java.lang.String even if numeric
> -----------------------------------------------------------------
>
>                 Key: SOLR-3083
>                 URL: https://issues.apache.org/jira/browse/SOLR-3083
>             Project: Solr
>          Issue Type: Bug
>          Components: SearchComponents - other
>    Affects Versions: 4.0
>            Reporter: Tagged Siteops
>            Priority: Minor
>              Labels: interoperability,, jmx, monitoring, statistics
>         Attachments: Screen shot 2012-01-31 at 2.19.06 PM.png
>
>
> When trying to monitor our Solr instances with JMXtrans (https://github.com/lookfirst/jmxtrans), we
discovered that all the Mbeans were identifying themselves as java.lang.String.   This breaks the
GangliaWriter in JMXtrans because the software decides it's a string instead of a numeric values and you
can't graph a string.   Other software we are monitoring with JMXtrans (e.g. Kafka) correctly identify
(Continue reading)

Picon
Favicon

[jira] [Updated] (SOLR-3083) all JMX Mbeans are identified as java.lang.String even if numeric


     [
https://issues.apache.org/jira/browse/SOLR-3083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tagged Siteops updated SOLR-3083:
---------------------------------

    Affects Version/s:     (was: 3.5)
                       4.0

> all JMX Mbeans are identified as java.lang.String even if numeric
> -----------------------------------------------------------------
>
>                 Key: SOLR-3083
>                 URL: https://issues.apache.org/jira/browse/SOLR-3083
>             Project: Solr
>          Issue Type: Bug
>          Components: SearchComponents - other
>    Affects Versions: 4.0
>            Reporter: Tagged Siteops
>            Priority: Minor
>              Labels: interoperability,, jmx, monitoring, statistics
>         Attachments: Screen shot 2012-01-31 at 2.19.06 PM.png
>
>
> When trying to monitor our Solr instances with JMXtrans (https://github.com/lookfirst/jmxtrans), we
discovered that all the Mbeans were identifying themselves as java.lang.String.   This breaks the
GangliaWriter in JMXtrans because the software decides it's a string instead of a numeric values and you
can't graph a string.   Other software we are monitoring with JMXtrans (e.g. Kafka) correctly identify
their numeric values as numbers (doubles in this case).
(Continue reading)

Picon
Favicon

[jira] [Created] (LUCENE-3743) LuceneTestCase's uncaught exceptions handler should check for AssumptionViolatedExceptions and then not trigger test failure

LuceneTestCase's uncaught exceptions handler should check for AssumptionViolatedExceptions and then
not trigger test failure
----------------------------------------------------------------------------------------------------------------------------

                 Key: LUCENE-3743
                 URL: https://issues.apache.org/jira/browse/LUCENE-3743
             Project: Lucene - Java
          Issue Type: Bug
          Components: general/test
    Affects Versions: 3.5
            Reporter: Steven Rowe
            Assignee: Steven Rowe
            Priority: Minor

As in single-threaded tests, {{LuceneTestCase}} should not trigger test failures for
{{AssumptionViolatedException}}'s when they occur in multi-threaded tests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Picon
Favicon

[jira] [Updated] (LUCENE-3743) LuceneTestCase's uncaught exceptions handler should check for AssumptionViolatedExceptions and then not trigger test failure


     [
https://issues.apache.org/jira/browse/LUCENE-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Rowe updated LUCENE-3743:
--------------------------------

    Affects Version/s: 4.0

> LuceneTestCase's uncaught exceptions handler should check for AssumptionViolatedExceptions and
then not trigger test failure
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-3743
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3743
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: general/test
>    Affects Versions: 3.5, 4.0
>            Reporter: Steven Rowe
>            Assignee: Steven Rowe
>            Priority: Minor
>         Attachments: LUCENE-3743.patch
>
>
> As in single-threaded tests, {{LuceneTestCase}} should not trigger test failures for
{{AssumptionViolatedException}}'s when they occur in multi-threaded tests.

--
This message is automatically generated by JIRA.
(Continue reading)

Picon
Favicon

[jira] [Updated] (LUCENE-3743) LuceneTestCase's uncaught exceptions handler should check for AssumptionViolatedExceptions and then not trigger test failure


     [
https://issues.apache.org/jira/browse/LUCENE-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steven Rowe updated LUCENE-3743:
--------------------------------

    Attachment: LUCENE-3743.patch

Patch addressing the problem

> LuceneTestCase's uncaught exceptions handler should check for AssumptionViolatedExceptions and
then not trigger test failure
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-3743
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3743
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: general/test
>    Affects Versions: 3.5, 4.0
>            Reporter: Steven Rowe
>            Assignee: Steven Rowe
>            Priority: Minor
>         Attachments: LUCENE-3743.patch
>
>
> As in single-threaded tests, {{LuceneTestCase}} should not trigger test failures for
{{AssumptionViolatedException}}'s when they occur in multi-threaded tests.

(Continue reading)

Picon
Favicon

[jira] [Commented] (LUCENE-3743) LuceneTestCase's uncaught exceptions handler should check for AssumptionViolatedExceptions and then not trigger test failure


    [
https://issues.apache.org/jira/browse/LUCENE-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197414#comment-13197414
] 

Robert Muir commented on LUCENE-3743:
-------------------------------------

definitely a bug... patch looks good to me.

                
> LuceneTestCase's uncaught exceptions handler should check for AssumptionViolatedExceptions and
then not trigger test failure
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-3743
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3743
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: general/test
>    Affects Versions: 3.5, 4.0
>            Reporter: Steven Rowe
>            Assignee: Steven Rowe
>            Priority: Minor
>         Attachments: LUCENE-3743.patch
>
>
> As in single-threaded tests, {{LuceneTestCase}} should not trigger test failures for
{{AssumptionViolatedException}}'s when they occur in multi-threaded tests.

(Continue reading)

Picon
Favicon

[jira] [Commented] (LUCENE-3743) LuceneTestCase's uncaught exceptions handler should check for AssumptionViolatedExceptions and then not trigger test failure


    [
https://issues.apache.org/jira/browse/LUCENE-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197418#comment-13197418
] 

Uwe Schindler commented on LUCENE-3743:
---------------------------------------

I am not sure, if this is really a bug... Why would one do an assume in a thread, you would d this at the beginning
of your test to check preconditions, but if its inside a thread its in my opinion somehow too late?

> LuceneTestCase's uncaught exceptions handler should check for AssumptionViolatedExceptions and
then not trigger test failure
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-3743
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3743
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: general/test
>    Affects Versions: 3.5, 4.0
>            Reporter: Steven Rowe
>            Assignee: Steven Rowe
>            Priority: Minor
>         Attachments: LUCENE-3743.patch
>
>
> As in single-threaded tests, {{LuceneTestCase}} should not trigger test failures for
{{AssumptionViolatedException}}'s when they occur in multi-threaded tests.

(Continue reading)

Chris Hostetter | 1 Feb 01:21

Re: [DISCUSS] New Website


: So, I'd suggest everyone give it a pass through, fix items as they see 
: them and/or otherwise pitch in and help, because I'm tired of our 
: current site and how poor it makes us look.

Grant: my one concern is how the Solr tutorial currently looks, 
particularly related to inline code and bulk code blocks...

http://lucene.staging.apache.org/solr/tutorial.html

to clarify: i think ultimatley the tutorial shouldn't be part of the site 
itself, because i think that should remain "unversioned" and the tutorial 
should move into "version specific" documentation of some kind (ie: maybe 
just a javadoc doc-files or some other file under the solr dev tree). ... 
but we can worry about that seperately.

my real concern is that the tutorial serves as a good indicator of how 
inline and block code elements seem to be handled by the new CMS markup 
and our templates -- and that worries me for our ability to move 
forward writing docs/news/examples in the CMS given how poorly it seems to 
be handled in the tutorial right now.

places where there should be inlined 'code' in a fixed width 
font, ie...

> Begin by unziping the Solr release and changing your working directory
> to be the "<code>example</code>" directory.  (Note that the base 
> directory name may vary with the version of Solr downloaded.)  For 
> example, with a shell in UNIX, Cygwin, or MacOS:

(Continue reading)

Picon
Favicon

[jira] [Commented] (LUCENE-3743) LuceneTestCase's uncaught exceptions handler should check for AssumptionViolatedExceptions and then not trigger test failure


    [
https://issues.apache.org/jira/browse/LUCENE-3743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13197421#comment-13197421
] 

Robert Muir commented on LUCENE-3743:
-------------------------------------

I think you can have a situation where you want to assume in another thread...

it doesnt have to be a precondition... in fact the whole handling of assume doesnt
even work best as a precondition [in setUp] because you get no messages about it if you do that.
try it... its because the TestWatchMan does not intercept anything coming from setUp :)

anyway I think we should do the patch for consistency, and for those rare, crazy
situations where you want to make an assumption that isnt a precondition.

> LuceneTestCase's uncaught exceptions handler should check for AssumptionViolatedExceptions and
then not trigger test failure
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-3743
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3743
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: general/test
>    Affects Versions: 3.5, 4.0
>            Reporter: Steven Rowe
>            Assignee: Steven Rowe
>            Priority: Minor
(Continue reading)


Gmane