lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <>
Subject Re: need help in understating solr cloud stats data
Date Mon, 03 Feb 2014 19:28:20 GMT

It outlines how to get the code, how to work with patches, how to set
up IntelliJ and Eclipse IDEs (links near the bottom?). There are
formatting files for both IntelliJ and Eclipse that'll do the right
thing in terms of indents and such.

Legal issues aside, you don't to be very compulsive about cleaning up
the code before posting the first patch! Just let people know you
don't consider it ready to commit. You'll want to open a JIRA to
attach it to. People often put in //nocommit in places they especially
don't like, and the "precommit" ant target takes care of keeping these
from getting into the code.

People are quite happy to see hack, first-cut patches. You'll often
get suggestions on approaches that may be easier and nobody will
complain about "bad code" when they know that _you_ don't consider it
submittable. Google for "Yonik's law of half-baked patches".

One thing that escapes people often... When attaching a patch to a
JIRA, just call it SOLR-####.patch, where #### is the JIRA number.
Successive versions of the patch should have the _same_ name, they'll
all be listed and the newest one will be "live". It's easier to know
what is the right patch that way. No big deal either way.


On Mon, Feb 3, 2014 at 8:25 AM, Greg Walters <> wrote:
> The code I wrote is currently a bit of an ugly hack so I'm a bit reluctant to share it
and there's some legal concerns with open-sourcing code within my company. That being said,
I wouldn't mind rewriting it on my own time. Where can I find a starter kit for contributors
with coding guidelines and the like? Spruced up some I'd be OK with submitting a patch.
> Thanks,
> Greg
> On Feb 3, 2014, at 10:08 AM, Mark Miller <> wrote:
>> You should contribute that and spread the dev load with others :)
>> We need something like that at some point, it's just no one has done it. We currently
expect you to aggregate in the monitoring layer and it's a lot to ask IMO.
>> - Mark
>> On Feb 3, 2014, at 10:49 AM, Greg Walters <> wrote:
>>> I've had some issues monitoring Solr with the per-core mbeans and ended up writing
a custom "request handler" that gets loaded then registers itself as an mbean. When called
it polls all the per-core mbeans then adds or averages them where appropriate before returning
the requested value. I'm not sure if there's a better way to get jvm-wide stats via jmx but
it is *a* way to get it done.
>>> Thanks,
>>> Greg
>>> On Feb 3, 2014, at 1:33 AM, adfel70 <> wrote:
>>>> I'm sending all solr stats data to graphite.
>>>> I have some questions:
>>>> 1. query_handler/select requestTime -
>>>> if i'm looking at some metric, lets say 75thPcRequestTime - I see that each
>>>> core in a single collection has different values.
>>>> Is each value of each core is the time that specific core spent on a
>>>> request?
>>>> so to get an idea of total request time, I should summarize all the values
>>>> of all the cores?
>>>> 2.update_handler/commits - does this include auto_commits? becuaste I'm
>>>> pretty sure I'm not doing any manual commits and yet I see a number there.
>>>> 3. update_handler/docs pending - what does this mean? pending for what? for
>>>> flush to disk?
>>>> thanks.
>>>> --
>>>> View this message in context:
>>>> Sent from the Solr - User mailing list archive at

View raw message