[
https://issues.apache.org/jira/browse/SOLR-439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-439.
Resolution: Fixed
Fix Version/s: 1.3
Assignee: Ryan McKinley
committed in rev 604951
Remove xpp jars and XppUpdateRequestHandler
---
Key: SOLR-437
URL: https://issues.apache.org/jira/browse/SOLR-437
Project: Solr
Issue Type: Task
Affects Versions: 1.3
Reporter: Ryan
Chris Hostetter wrote:
: To get that going, it looks like a Project PMC needs to file a ticket with
: infrastructure.
I can do this (or ask Doug to do it if they really want it to be the
chair) but just to clarify
: o Also specify the key name for the Space. The key name cannot be
Chris Hostetter wrote:
: Javadocs aren't appropriate for documenting configuration and RequestHandler
: parameters/usage. These are used by many non-java folks and should have
: nothing to do with the java class structure/methods/etc
i agree that the generated javadocs are not very freindly
/corename
And '@' is not a friendly URL character
--Noble
On Dec 11, 2007 8:05 PM, Ryan McKinley [EMAIL PROTECTED] wrote:
Henrib wrote:
To be honest, I am not a big fan of the '/@corename' syntax ; I feel the
'?core=corename' syntax carries less surprise and may be extended more
easily (Stu's
Yonik Seeley wrote:
On Dec 11, 2007 9:29 AM, Ryan McKinley [EMAIL PROTECTED] wrote:
Do we feel ok about moving forward with step #0? That is request a
cwiki site and evaluate it.
+1
To get that going, it looks like a Project PMC needs to file a ticket
with infrastructure.
From the wiki
[
https://issues.apache.org/jira/browse/SOLR-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12551058
]
Ryan McKinley commented on SOLR-281:
Sabyasachi - check that your patch does not comment out the loading line
[
https://issues.apache.org/jira/browse/SOLR-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-265.
Resolution: Fixed
SOLR-350 lets you RELOAD a core. this will reload the IndexSchema also
Make
[
https://issues.apache.org/jira/browse/SOLR-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-435:
---
Description:
Each QParser should check if q exists or not. For some it will be required
others
Affects Versions: 1.3
Reporter: Ryan McKinley
Fix For: 1.3
Each QParser should check if q exists or not. For some it will be required
others not.
currently it throws a null pointer:
{code}
java.lang.NullPointerException
[
https://issues.apache.org/jira/browse/SOLR-350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-350:
---
Attachment: SOLR-350-Naming.patch
patch to get rid of the @corename syntax and force things
Thoughts?
I like this idea. The more we reuse stuff, the better it should get.
If/when we figure a faster way to transmit request/response data (JSON?
RMI?), it would be good to have this cooked into distributed search easily.
One downside is that SolrJ would need to be moved into the
Henrib wrote:
To be honest, I am not a big fan of the '/@corename' syntax ; I feel the
'?core=corename' syntax carries less surprise and may be extended more
easily (Stu's comment in solr-350).
I've uploaded a small patch to solr-350 (solr-350.patch) so the core as a
request parameter works
Chris Hostetter wrote:
Forgive me if i'm off base with some stuff here ... i'm still trying to
wrap my head arround some of the new multicore stuff.
No forgiveness here! The more comments/questions/clarification, the
better for everyone. Especially for something as substantial as this.
I just committed a simple fix for the admin pages (rev 603269)
?core=core1 will work for /admin pages, but not for handleres.
Assuming we go with the route saying if multi-core support is
avaliable, all requests must include the core name It would make sense
to have:
[
https://issues.apache.org/jira/browse/SOLR-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-418:
---
Attachment: SOLR-418-QueryBoosting.patch
Updated patch for trunk. This also
1. renames the component
[
https://issues.apache.org/jira/browse/SOLR-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-418:
---
Attachment: SOLR-418-QueryBoosting.patch
updated to work with trunk. added 'forceBoosting=true
[
https://issues.apache.org/jira/browse/SOLR-428?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549667
]
Ryan McKinley commented on SOLR-428:
first: just to clarify the restriction is that a handler name can't start
If someone wants to investigate what it would take to switch to use
Confluence for the main site and/or the wiki i say great ... but it's
important to keep in mind that:
a) we need to be able to include official docs in releases
b) wiki pages editable by anyone can't be included in
Mike Klaas wrote:
Both the wiki and the homepages look much nicer than the lucene/solr
ones. More professional too, FWIW.
Obviously the main issue here is manpower to convert everything. An
easier solution might be to install a MoinMoin theme. see
[
https://issues.apache.org/jira/browse/SOLR-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12549538
]
Ryan McKinley commented on SOLR-418:
I would like to commit most of this patch under SOLR-281. I will leave out
[
https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-414.
Resolution: Fixed
I added some docs to the wiki and will resolve this issue. If we need to relax
Restrict valid RequestHandler names
---
Key: SOLR-428
URL: https://issues.apache.org/jira/browse/SOLR-428
Project: Solr
Issue Type: Improvement
Affects Versions: 1.3
Reporter: Ryan McKinley
ug! remind me never to compose docs in the HTML text area! Just
lost a bunch of stuff... now i'll try again...
Apache Wiki wrote:
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Solr Wiki for change
notification.
The following page has been changed by ryan:
I think its safe to say we that the solr wiki is not nearly as complete
as it could/should be. I've added a ton of stuff to 1.3 that needs some
documentation. Beyond the normal, 'I dislike writing docs' thing, I
find writing things in MoinMoin disappointing and even less fun then it
needs to
The default solrconfig.xml defines:
HashDocSet maxSize=3000 loadFactor=0.75/
the SolrConfig loader uses:
hashDocSetMaxSize= getInt(//HashDocSet/@maxSize,-1);
If no HashDocSet is set, you get -1, then an exception in
DocSetHitCollector: scratch = new int[HASHDOCSET_MAXSIZE];
Can we set:
[
https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548925
]
Ryan McKinley commented on SOLR-414:
Koji, are you able to get what you need working with hoss' suggestion?
If so
[
https://issues.apache.org/jira/browse/SOLR-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-409:
---
Attachment: solr-350_409.patch
This adds solrj support for multicore and uses it to run a bunch
[
https://issues.apache.org/jira/browse/SOLR-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548337
]
Ryan McKinley commented on SOLR-418:
To be clear, this respects filter queries. For:
http://localhost:8983/solr
[
https://issues.apache.org/jira/browse/SOLR-418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548347
]
Ryan McKinley commented on SOLR-418:
Is there a way to specify that the file is in the index directory (so
Reporter: Ryan McKinley
Priority: Minor
Attachments: SOLR-425-SpellCheckerParams.patch
The static final String parameter options for SpellCheckerRequestHandler should
be in a common class so they can be (easily) used from solrj etc
--
This message is automatically
[
https://issues.apache.org/jira/browse/SOLR-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-425:
---
Attachment: SOLR-425-SpellCheckerParams.patch
SpellCheckerRequestHandler should use common
[
https://issues.apache.org/jira/browse/SOLR-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley reassigned SOLR-421:
--
Assignee: Ryan McKinley
Make SolrParams serializable
[
https://issues.apache.org/jira/browse/SOLR-421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-421.
Resolution: Fixed
Fix Version/s: 1.3
commited in rev 600589
Make SolrParams serializable
Yonik Seeley wrote:
On Dec 3, 2007 12:44 AM, Ryan McKinley [EMAIL PROTECTED] wrote:
In trunk, check:
http://localhost:8983/solr/select
or
http://localhost:8983/solr/select?q=
In 1.2, this returns 400, Missing required parameter: q
Fix could be easy -- add a check in QueryComponent.prepare
[
https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12548044
]
Ryan McKinley commented on SOLR-303:
Are you suggesting changing the main control loop from:
{code
[
https://issues.apache.org/jira/browse/SOLR-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12547683
]
Ryan McKinley commented on SOLR-421:
Do you just mean, change SolrParams.java to:
{code:java}
public abstract
In trunk, check:
http://localhost:8983/solr/select
or
http://localhost:8983/solr/select?q=
In 1.2, this returns 400, Missing required parameter: q
Fix could be easy -- add a check in QueryComponent.prepare(), the hitch
is that for qt=dismax, q is *not* a required param.
ryan
Britske wrote:
Hi,
when constructing a resultquery using SOlrJ the method addFacetField
overwrites the value set with setFacetMinCount to 1.
Is this intentional or a small bug?
Looks like it was intentional, but I agree it is a bad idea. I'll
change it in sec
ryan
[
https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546772
]
Ryan McKinley commented on SOLR-414:
I am ok with relaxing the constraints.
As implemented, we could change
[
https://issues.apache.org/jira/browse/SOLR-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-418:
---
Attachment: SOLR-418-QueryBoosting.patch
Here is an updated patch that implements sorting. Rather
[
https://issues.apache.org/jira/browse/SOLR-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-423:
---
Attachment: SOLR-423-CloseHook.patch
This version adds a CloseHook to SolrCore. The test now looks
[
https://issues.apache.org/jira/browse/SOLR-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546851
]
Ryan McKinley commented on SOLR-423:
That then got me thinking that instead of a CloseHook we should probably
-
java.lang.RuntimeException: java.io.FileNotFoundException: no
segments* file found in
org.apache.lucene.store.FSDirectory@/usr/local/apache-solr-1.2.0/slando/solr/data/index:
files:
The configuration is identical to a working
Aaron Trevena wrote:
On 28/11/2007, Ryan McKinley [EMAIL PROTECTED] wrote:
-
java.lang.RuntimeException: java.io.FileNotFoundException: no
segments* file found in
org.apache.lucene.store.FSDirectory@/usr/local/apache-solr-1.2.0
[
https://issues.apache.org/jira/browse/SOLR-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley reassigned SOLR-417:
--
Assignee: Ryan McKinley
Move SortSpec to top level class and cleanup
[
https://issues.apache.org/jira/browse/SOLR-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-417.
Resolution: Fixed
committed in #599071
Move SortSpec to top level class and cleanup
I'm trying to write some tests for SOLR-418 and I can't tell if this is
a real error or that I'm using the TestHarness incorrectly. I don't see
this error running the site normally.
The test is setup like this:
1. add docs and commit
2. query check results
3. query check results
...
The
[
https://issues.apache.org/jira/browse/SOLR-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546427
]
Ryan McKinley commented on SOLR-423:
Aaaah that freaking interface! So far, we have not broken API compatibility
'] );
// Using legacy ';' param
args.remove( CommonParams.SORT );
Ryan McKinley wrote:
I'm trying to write some tests for SOLR-418 and I can't tell if this is
a real error or that I'm using the TestHarness incorrectly. I don't see
this error running the site normally.
The test
[
https://issues.apache.org/jira/browse/SOLR-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-281:
---
Attachment: SOLR-281-ComponentInit.patch
This patch uses SOLR-414 Initialization strategy
[
https://issues.apache.org/jira/browse/SOLR-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545938
]
Ryan McKinley commented on SOLR-281:
The problem first/last is trying to solve is to let a custom handler
[
https://issues.apache.org/jira/browse/SOLR-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-418:
---
Attachment: SOLR-418-QueryBoosting.patch
Here is a first draft that includes recent changes to SOLR
URL: https://issues.apache.org/jira/browse/SOLR-418
Project: Solr
Issue Type: New Feature
Components: search
Reporter: Ryan McKinley
Fix For: 1.3
Attachments: SOLR-418-QueryBoosting.patch
For a given query string, a human
Henrib wrote:
It may be too late but just for the sake of argument, Hoss's idea about a
ResourceLoader triggered more thinking...(sorry, I'm not as fast as Hoss).
nonsense! of course its not too late. Its great to get feedback and new
ideas anytime - the goal is to make sure that we like
[
https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544600
]
Ryan McKinley commented on SOLR-414:
it hadn't occurred to be that ResourceLoader could be a super class
[
https://issues.apache.org/jira/browse/SOLR-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-399.
Resolution: Duplicate
SOLR-414 takes care of the problems this patch solves
[
https://issues.apache.org/jira/browse/SOLR-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley reopened SOLR-281:
The SearchComponent framework needs to allow for custom component
initialization -- I previously
Editorial Query Boosting Component
--
Key: SOLR-418
URL: https://issues.apache.org/jira/browse/SOLR-418
Project: Solr
Issue Type: New Feature
Components: search
Reporter: Ryan McKinley
since 99% of hte use cases are pulling sort, rows, and start from some
SOlrParams, that use case should probably be refactored into a utility
method as well.
While we are at it, we should limit consolidate the null sort checking.
See:
...the only thing slightly non-standard about calling these methods
setters is that they aren't expected to jsut be POJO style setters ...
the expectation is that the class will do some work when they are called
-- hence my tell (or maybe notify or inform is a better verb)
suggestion.
[
https://issues.apache.org/jira/browse/SOLR-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544016
]
Ryan McKinley commented on SOLR-409:
I agree with everything you say above.
Lets take the approach in #1
I started implementing this suggestion and am running into one hitch.
The cleanest solution is to have a single place manage Aware/Inform.
The cleanest place for this is in ResourceLoader (refactored Config
superclass)
public Object newInstance(String cname, String... subpackages) {
...
[
https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-414:
---
Attachment: SOLR-414-Initialization.patch
Updated patch to reflect ideas discussed in:
http
Reporter: Ryan McKinley
Priority: Minor
Fix For: 1.3
Move SortSpec from within IndexSchema.
see discussion: http://www.nabble.com/QueryParsing.SortSpec-tf4840762.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment
[
https://issues.apache.org/jira/browse/SOLR-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-417:
---
Attachment: SOLR-417-SortSpec.patch
Moves SortSpec to its own class and cleans up lots of null
[
https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-414:
---
Attachment: SOLR-414-Initialization.patch
sorry - I uploaded the wrong one
Coherent plugin
Henrib wrote:
Definitely a simpler more practical route - it avoids all previously
inelegant lately unorthodox pitfalls :-)
The only thing that this leaves behind is solr-399; I guess it's ok, we can
revive this after 1.3.
Yes, this leaves behind the 399 post core initialization callback.
...Did i get that all right?
wow! you are good!
The one key point you did not mention is that the ThreadLocal approach
is proposed as a stop-gap measure until we have an API breaking release.
In the 2.0 release, the init() method signature will change and the
ThreadLocal hack will go
[
https://issues.apache.org/jira/browse/SOLR-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543787
]
Ryan McKinley commented on SOLR-409:
Yes #1, not #2
{code:xml}
multicore enabled=true adminpath=/admin/multicore
The bit of magic is in using some controlled Duck Typing to find the correct
method if it exists in the instance.
I'll try uploading the raw code for the Compatiblity package in case this
leaves you wondering.
Uggg. this is an impressive option! But it feels like a HUGE hammer
for a small
McKinley
Assignee: Ryan McKinley
Fix For: 1.3
We currently load many plugins with a Map or NamedList -- since SOLR-215, the
current core is not available through SolrCore.getSolrCore() and may need to be
used for initialization.
Ideally, we could change the init() methods
[
https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-414:
---
Attachment: SOLR-414-Initialization.patch
This patch maintains 1.2 API compatibility and gives access
[
https://issues.apache.org/jira/browse/SOLR-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-414:
---
Attachment: SOLR-414-Initialization.patch
sorry, last patch was missing new files
Coherent plugin
So, how do we proceed now ?
How do we reach closure on the topic ?
I just posted SOLR-414, I think this is our best 1.2 compatible
solution. We will need to document the deprecation path well.
Does this look ok?
Since this patch does not suggest new API changes (it rolls back
SOLR-215
[
https://issues.apache.org/jira/browse/SOLR-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543408
]
Ryan McKinley commented on SOLR-373:
What do you see as the value for a JDBC driver? Are there good examples
[
https://issues.apache.org/jira/browse/SOLR-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543410
]
Ryan McKinley commented on SOLR-404:
I don't think there are any solr commiters with access to coldfusion, so
[
https://issues.apache.org/jira/browse/SOLR-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12543411
]
Ryan McKinley commented on SOLR-402:
It looks like this patch is not really a JSON parser, it is more like a raw
[
https://issues.apache.org/jira/browse/SOLR-314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-314.
Resolution: Won't Fix
The functionality I was trying to get can now be achieved with a custom
[
https://issues.apache.org/jira/browse/SOLR-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-295.
Resolution: Fixed
In SOLR-281, DisMaxRequestHandler became a subclass of StandardRequestHandler
[
https://issues.apache.org/jira/browse/SOLR-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-404.
Resolution: Fixed
Check for the latest updates on http://solcoldfusion.riaforge.org/
This is linked
Instead of changing 'init' ( keeping the 1.2 version), we can either make
classes take a solrSystem as (first) constructor parameter (but I know this
is not the current nor preferred usage)
Are you saying 'if a constructor exists that takes a solrSystem, it will
use that - otherwise, just
For people not following:
http://www.nabble.com/SolrConfig.Initializable-tf4665036.html
In looking at how initialization throughout solr, I think the cleanest
and best approach to move forward is to break the existing init() method
for:
1. TokenFilterFactory.init( MapString,String args )
2.
[
https://issues.apache.org/jira/browse/SOLR-411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12542245
]
Ryan McKinley commented on SOLR-411:
+1 standard naming conventions are good
Solr JAR Packaging Names
[
https://issues.apache.org/jira/browse/SOLR-399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-399:
---
Attachment: solr-399.patch
updated to work with trunk.
I'll post my comments on the mailing list
Henrib wrote:
Just pinging on the subject and the related solr-399 patch; I understand the
priority for this is low, just seeking some comment to determine whether
this is the expected track (and how low the priority is).
I started working on adding configuration to the search components in
[
https://issues.apache.org/jira/browse/SOLR-176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-176.
Resolution: Fixed
Committed as part of SOLR-281
Add detailed timing data to query response output
[
https://issues.apache.org/jira/browse/SOLR-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-281:
---
Component/s: search
Fix Version/s: 1.3
Assignee: Ryan McKinley
Affects
[
https://issues.apache.org/jira/browse/SOLR-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-110.
Resolution: Fixed
SOLR-281 moves common search operation into reusable 'components'
Factor out
[
https://issues.apache.org/jira/browse/SOLR-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-281.
Resolution: Fixed
Lets track ResponseBuilder issues with SOLR-410
Search Components (plugins
Yonik Seeley commented on SOLR-410:
---
Ongoing review + changes also applies to search components in general
(SearchComponent class, etc).
Yes, of course!
What is your thought on resolving vs keeping open issues that need
further review/changes?
Keeping
I agree we don't want to replicate the servlet container.
If we were to create class loaders not per instance but per 'lib' directory
(not per instance dir as I mentioned earlier but per library directory),
what about the very standard use case where I want to 'reload' a core?
In this case,
[
https://issues.apache.org/jira/browse/SOLR-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-281:
---
Attachment: SOLR-281-SearchComponents.patch
Here is an updated version of your patch that converts
perhaps. it depends largely on what the long term goals of multi-core
support are ... if we're striving for dynamicly creating solr contexts
independently of servlet contexts then the current behavior is probably
ideal ... we're protecting the plugins of each SolrCore from
corrupting
Is there a way to bypass that, and to use singletons in a singleton
fashion between cores?
Btw: Cores do see MultiCore as a singleton, i.e. all handler see the
same object, so I could get around this problem using MultiCore to get
cores..., but I would like to understand why cores doesn't
Chris Hostetter wrote:
: Just pinging on the subject and the related solr-399 patch; I understand the
: priority for this is low, just seeking some comment to determine whether
: this is the expected track (and how low the priority is).
It's in my mailbox of things to look at but there are
[
https://issues.apache.org/jira/browse/SOLR-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-408.
Resolution: Fixed
Fix Version/s: 1.3
thanks Karsten
PingRequestHandler
[
https://issues.apache.org/jira/browse/SOLR-335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-335.
Resolution: Fixed
Fix Version/s: 1.3
Assignee: Ryan McKinley
SOLR-408 adds
Erik Hatcher wrote:
anybody compared/contrasted the two? seems like yonik's noggit parser
might have a performance edge on xml parsing ?!
an early version of solrj used JSON but not noggit.
I have not messed with noggit, but the one major downside to JSON (in my
opinion) is how it deals
It is not related to the singleton, AFAIK, as I tested it with a simple
multhread app, and I always got the object created one time
(singletonObject = new getInstance()), while other calls just receive
the already created object.
While if the handler try to call getInstance(), the first time
701 - 800 of 1482 matches
Mail list logo
