See http://lucene.zones.apache.org:8080/hudson/job/Solr-Nightly/117/changes
--
[...truncated 652 lines...]
A client/ruby/flare/app/controllers/application.rb
A client/ruby/flare/app/controllers/browse_controller.rb
AUclient/ruby/flare
>i haven't read anything in the jira issue this refrences, but in
instances
>where reliability and uptime are of high concern, you'll typically have
a
>master/multi-slave setup with the slaves sitting behind a load balancer
>-- in that configuration, you can deploy any change to your schema by:
>t
requestsPerSecond and averageResponseTime were added to statistics for
each response handler. Are these statistics really useful enough to
keep as-is?
averageResponseTime is cumulative since the server started, so it's
not useful for monitoring purposes, but only benchmarking purposes (it
won't
Would it be better to have an option to record traffic for the last 'x
minutes/seconds/hours' configurable on a per handler basis? The goal is
to have hooks for nagios/cacti/etc to be able to pull live status info
for monitoring purposes. If you want fine grained performance history
then log file
Hi,
I was wondering what the general consensus is on when Lucene upgrades
are made available in Solr? From the looks of [1] and [2], it seems
to be fairly ad hoc. I am considering doing some work in Lucene that
I would then like to make available in Solr. Is the best way to do
this to
On 6/19/07, Will Johnson <[EMAIL PROTECTED]> wrote:
Would it be better to have an option to record traffic for the last 'x
minutes/seconds/hours' configurable on a per handler basis? The goal is
to have hooks for nagios/cacti/etc to be able to pull live status info
for monitoring purposes. If y
On 6/19/07, Grant Ingersoll <[EMAIL PROTECTED]> wrote:
I was wondering what the general consensus is on when Lucene upgrades
are made available in Solr? From the looks of [1] and [2], it seems
to be fairly ad hoc.
Yes, I'm generally in favor of keeping flexible and agile.
I am considering d
For the record nagios and/or cacti could both keep track of 'in the last
x' type of statistics based on totals but having solr compute that
automatically would be nice.
That's a good point about totals... totalResponseTime is actually more
powerful than averageResponseTime in that a monitoring
[
https://issues.apache.org/jira/browse/SOLR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506267
]
Hoss Man commented on SOLR-264:
---
Uhh, guys ... this code violates the contract of Comparator (which is
admittedly not an
>Has anyone tried to get solr statistics with cacti/nagios? If it isn't
>too difficult, I would like to set this up.
>Can cacti read & parse a file?
Generally speaking nagios/cacti are as powerful as you are with bash.
We haven't done it yet but it's a requirement at my company to integrate
the
[
https://issues.apache.org/jira/browse/SOLR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506274
]
Ryan McKinley commented on SOLR-264:
Dooh. I was worried about this at first, but it did not seem to matter.
Per
[
https://issues.apache.org/jira/browse/SOLR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506273
]
Yonik Seeley commented on SOLR-264:
---
Yeah, I briefly thought of that... but decided it might be OK (won't cause an
i
[
https://issues.apache.org/jira/browse/SOLR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506280
]
Yonik Seeley commented on SOLR-264:
---
Hold up a minute... I have a better way... gotta run to a meeting thoughj
> Sup
[
https://issues.apache.org/jira/browse/SOLR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506284
]
Hoss Man commented on SOLR-264:
---
the only clean way to do this that i know of i to build aFieldCache-esque rray
of size
That's pretty much how do it; it try an update and if it seems "very" broken,
I just get a fresh copy of the trunk and apply the patch. Less than ideal
since it's trial & error though but can't think of anything better.
I'm might backport to 1.2 instead and continue work on 1.3 with less
constrai
[
https://issues.apache.org/jira/browse/SOLR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-264:
--
Attachment: RandomSortField.java
> Support 'random' sort order
> ---
>
>
[
https://issues.apache.org/jira/browse/SOLR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506309
]
Yonik Seeley commented on SOLR-264:
---
I just attached a draft approach (completely untested, uncommented, etc)
The ap
[
https://issues.apache.org/jira/browse/SOLR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506315
]
Yonik Seeley commented on SOLR-264:
---
Of course this could also implement a ValueSource if someone really wanted to
t
[
https://issues.apache.org/jira/browse/SOLR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506316
]
Hoss Man commented on SOLR-264:
---
wow.
why is it whenever i read a patch from yonik that starts with a bunch of
bitshift
[
https://issues.apache.org/jira/browse/SOLR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-264:
--
Attachment: RandomSortField.java
Just for the fun of it, added prototype (read: completely untested) Valu
[
https://issues.apache.org/jira/browse/SOLR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506321
]
Yonik Seeley commented on SOLR-264:
---
> we wouldn't even have to require that the field name match any sort of
> patt
: You'll have to let me know the reference to the girl and the well stuff
sometime ;-)
http://imdb.com/title/tt0298130/plotsummary
http://www.youtube.com/watch?v=IlhZCDlEmh0
-Hoss
[
https://issues.apache.org/jira/browse/SOLR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-264:
---
Attachment: RandomSortField.java
wow.
Here is an updated version that uses the field name hash for t
Will Johnson wrote:
Has anyone tried to get solr statistics with cacti/nagios? If it isn't
too difficult, I would like to set this up.
Can cacti read & parse a file?
Generally speaking nagios/cacti are as powerful as you are with bash.
We haven't done it yet but it's a requirement at my
[
https://issues.apache.org/jira/browse/SOLR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-264:
--
Attachment: RandomSortField.java
If we want the comparator to be transitive, a subtraction doesn't work w
[
https://issues.apache.org/jira/browse/SOLR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506344
]
Yonik Seeley commented on SOLR-264:
---
Might be nice to check cache statistics to see that the same seed results in a
I've been working on a tool to parse log files to get some of this kind
of information as well
it's really alpha, but if your curious the dummy system is here:
http://pyro.holsman.net:9081/top/ -- slightly obfuscated queries (to
roll them up)
http://pyro.holsman.net:9081/overall/?period=5m&hou
[
https://issues.apache.org/jira/browse/SOLR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506347
]
Hoss Man commented on SOLR-264:
---
i was kind of wondering about the negative overflow (isn't that underflow) but
i was tr
[
https://issues.apache.org/jira/browse/SOLR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506352
]
Yonik Seeley commented on SOLR-264:
---
> i guess it's okay because the overflow is the same regardless of whether it's
[
https://issues.apache.org/jira/browse/SOLR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12506353
]
Yonik Seeley commented on SOLR-264:
---
LOL... I'm obviously too tired for more coding tonight. Could the next person
[
https://issues.apache.org/jira/browse/SOLR-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-264:
---
Attachment: RandomSortField.java
changed to use:
"return key >>> 1;"
and
seed ^ reader.getVersion()
: SOLR-133: Adding StaxUpdateRequestHandler.java and mapping it to:
: http://localhost:8983/solr/admin/update/stax
: in the example solrconfig.xml
:
: We should test and evaluate this in comparison to the
: XmlUpdateRequestHandler before replacing it.
an easy way to sanity check this might be to
Chris Hostetter wrote:
: SOLR-133: Adding StaxUpdateRequestHandler.java and mapping it to:
: http://localhost:8983/solr/admin/update/stax
: in the example solrconfig.xml
:
: We should test and evaluate this in comparison to the
: XmlUpdateRequestHandler before replacing it.
an easy way to sanit
: Perhaps it is just configuration fatigue, but I was reluctant to make
: another registry ;) As I had pictured it, an UpdateRequestHandler would
: have a single 'processor' - but i suppose with invariant params, it
: could also pick a shared ProcessorFactory.
oh no no no ... don't get me wrong,
I am not sure, didn't have a time to check all details...
Simply: old version of an application tried to send "" request, and
could not parse response due to (possible) schema changes and hardcoded
"tag" values... I am not using version number in URL for POSTs...
Thanks
-Original Message-
I don't know if this is your issue, but in 1.2, we unified the response
format for /update and /select
Check the last paragraph in CHANGES.txt on "Upgrading from Solr 1.1"
To get the old behavior, make sure there is nothing in solrconfig.xml
mapped to "/update"
Fuad Efendi wrote:
I am not
36 matches
Mail list logo
