on anymore . The CoreContainer is
> already synchronizing in the getCore() method
>
> On Wed, Apr 8, 2009 at 4:50 PM, Henrib wrote:
>>
>> It is synchronized due to 1.2 singleton core compatibility:
>> public static SolrCore getSolrCore() {
>> synchronized( SolrCore
It is synchronized due to 1.2 singleton core compatibility:
public static SolrCore getSolrCore() {
synchronized( SolrCore.class ) {
...
It would require a lot of simultaneous core creations (and/or deprecated
getSolrCore calls) to have a noticeable performance effect.
Noble Paul നോബിള് नो
Erik Hatcher wrote:
>
> I like how you summarized my post :)
>
Trying to get to the gist of it. ;)
Erik Hatcher wrote:
>
> I haven't given any consideration to exactly what kind of API changes
> are needed, but certainly being able to build an IndexSchema without
> XML being involved wo
Now, that's clearer! :-)
Erik Hatcher wrote:
>
>>> actually, configuration _should_ be code :)
> The above shows a way to programmatically create ...
> ...affect settings could be done without resorting to XML gymnastics.
> ... dynamic configuration...
> it's that XML middleman that annoys
What about moving SolrCore & a few other key classes to Lucene then?
That would make the distinction between library versus product clearer.
--
View this message in context:
http://www.nabble.com/Configuration-features%2C-Solr2-Spring---Solr1.x-future-tp19435196p19444718.html
Sent from the Solr
Erik Hatcher wrote:
>
>
> actually, configuration _should_ be code :)
>
> there is currently too much code to parse and manage various schemes
> of loading a configuration, making things less easily dynamic and fun.
>
> Erik
>
>
Are you saying Guice versus Spring ? Like no XML con
> ... keep developing more of our own way of doing configuration when large
> parts of it overlap so
> heavily with more standard ways (Spring, etc).
>
I agree that striving to avoid technical/implementation standards overlap is
a *good* thing. Although besides Ioc/DI, I wonder what the etc c
I appreciate your answer; a hint that your personal interest is nowhere close
to the configuration/integration/deployment feature set.
Do you think there is value in it ?
--
View this message in context:
http://www.nabble.com/Configuration-features%2C-Solr2-Spring---Solr1.x-future-tp19435196p19
Dear committers,
I understand why Solr2 will use Spring at least to ease the configuration
burden wrt plugins & various factories.
There is another set of useful configuration features orthogonal to those,
the ones that make integrating/deploying/using Solr in easier ways; these
could be injected
No, it's not a bug.
Yes, the pb is solved.
Grant Ingersoll-6 wrote:
>
> So, is this a bug or not? It sounds like it was resolved, right?
>
> On Aug 28, 2008, at 8:31 AM, Henri Biestro (JIRA) wrote:
>
>>
>>[
>> https://issues.apache.org/jira/browse/SOLR-734?page=com.atlassian.jira.plugin.
Noble Paul നോബിള് नोब्ळ् wrote:
>
> I am not much worried about where we store it. CoreContainer just
> occurred me as an easy place . The problem we are trying to solve is
> non-availability of this information anywhere .
>
We are in no functional disagreement and I'm merely trying to point
Might be irrelevant but do we have to store this information in the
CoreContainer ?
Couldn't we use core-container (master) & core properties (slave) to store
that information ?
These would be filled from the servlet filter (on the master side) in the
core-container properties.
To make them widel
l we have some upwards compatiblity on the XML config/schema files or
will Solr 2.0 become a 'lucene-for-spring' ? Isn't there anything we could
do to ease the pain in the mean time or is it worthless ?
Regards
Henrib
--
View this message in context:
http://www.nabble.com/Rena
Grant Ingersoll-6 wrote:
>
>
> I see that we have 13 issues:
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310230&fixfor=12312486
>
>
The URL shows 12 now but solr-647 has no assignee yet.
May be
>> SOLR-545: Remove Default core in multicore. No patch available.
Not sure how much should be added to this - I've added comment in the issue
itself.
>> SOLR-646: Config. props in multicore.xml Seems really useful, but is
currently unassigned.
Feel free to bug me as much as needed if I ca
I posted a new patch in solr-350 (solr-350-properties.patch) that allows
defining properties in multicore.xml and using them in expressions in config
& schema files. This brings a lot of flexibility to configuration.
I apologize for doubling the JIRA post; Solr-350 being closed, I just wanted
to
ryantxu wrote:
>
> I'm trying to write a search component that queries another core.
>
With Solr-561 core.getCoreDescriptor().getMultiCore() , we also avoid
reintroducing a singleton and keep an easier way to derive from Multicore &
instantiate.
Out of scope but does this relate to your prev
[ ] Keep solr logging as is. (JUL)
[X] Convert solr logging to SLF4J
--
View this message in context:
http://www.nabble.com/Solr-Logging-tp16836646p17027714.html
Sent from the Solr - Dev mailing list archive at Nabble.com.
Configuring JUL to fit your needs *requires* that you get people in charge
of the container to cooperate.
If you can not, you are screwed no matter what.
Some of us are just not in a position to negotiate with them on this issue.
--
View this message in context:
http://www.nabble.com/logging-t
Erik Hatcher wrote:
>
> It seems to me Sun left it wide open for a thousand implementations
> to flourish, actually. What's to prevent a ClassLoader specific
> LogManagerManager from being put into the mix? Nothing - that's what
> JULI does.
>
Being able to override the default impleme
David Smiley @MITRE.org wrote:
>
> (A) jul-log4j-bridge plus the "apache-log4j-component" library seems
> unmaintained
> (C) I had to update the log4j-boot.jar of JBoss to the latest Log4j-1.2.15
>
I went more or less through the same path; I did "custom" build the bridge
by stripping the need
Erik Hatcher wrote:
>
> JUL is the substrate that we (Java developers) should be logging to.
> Practically speaking, I'd like the world to look like this:
>App -> JUL -> Log4J adapter
>
Agreed.
Erik Hatcher wrote:
>
> the rant is on the containers not doing the
> right thing by incorpo
The fact remains, there is still no solution available for those of us trying
to embed/deploy Solr in log4j-aware apps/environments besides
developing/deploying container-specific code. I still hope this community
can propose a better compromise.
If I had found the
http://people.apache.org/~psmit
ryantxu wrote:
>
> As long as there is strong opposition, I think we can deal with JUL...
>
We can; an attempt to mitigate JUL & the functional need is
https://issues.apache.org/jira/browse/SOLR-549 SOLR-549 .
It does respect the JUL choice and is a practical compromise that noone
seems to s
I agree, slf4j is a better solution; I was just trying to mitigate the
functional need (hooking log4j) & the strong (op)positions against changing
the logging API, thus the mildly disgusting solr-549 strawman. :-)
David Smiley @MITRE.org wrote:
>
> Whenever I see a project with some home-grow
Actually, Tomcat does use commons in their code, at least that's what they
state here:
http://tomcat.apache.org/tomcat-6.0-doc/logging.html:
Tomcat 6.0 uses Commons Logging throughout its internal code.
They also state the core issue quite clearly:
> The default implemenatation of java.util.lo
I've no opinion on the respective merits of logging frameworks but not
having the choice causes deployment difficulties.
IMHO, the core issue is that JUL configuration is container dependant
(Tomcat JULI allows per-webapp logging.properties configuration, what about
Websphere ?), not application/
I've been fiddling with java.util.logging from jul-to-log4j bridge to the
idea of implementing a LogManager.
In the latter case there are a lot of deployability caveats, in particular
the fact that there is no common way of configuring them between servlet
containers. Trying to tame Websphere on t
I've been searching a little the Web & Lucene threads about a BM25 similarity
(or any "better" one than tf/idf) but I can't tell whether/when it has
been/will be implemented (lucene-965).
One of the difficulties for BM25 itself seems to lie in its in need for the
average document length (length
Andy,
The code in the trunk is not the latest-greatest functionality wise, it
reflects what we believe is stable enough to be made globally available -
ie, a strong commitment that the APIs & functionality will not change; to
get the latest level of functionality, the current development state, yo
Andy,
Having your code will certainly help.
Regarding patch production, I can only suggest you use either cygwin if on
Windows or diff/patch on Unix.
I usually post patches this way:
svn diff --diff-cmd /usr/local/bin/diff -x "-w -B -b -E -d -N -u" >
~/solr-350.patch
Which can be applied with:
/
Indeed, I reworded (plagiarized) your original proposal; sorry it took me a
full thread loop to grasp it & realize that...
About "comfort", it feels like having one name and multiple aliases per core
would be "easier" to work with than using a path-based identification; since
the path is depende
May be a bit late and not strictly about the Multicore "default" discussion
but trying to aggregate the ideas;
What about an "alias/unalias" feature that would allow managing multiple
aliases (at least one) for each core?
In the 'multiple index versions' scenario where someone would like to
reind
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 again (& passes the
I second that; it's always difficult to maintain documentation but having a
good looking end result always seem to reduce the amount of effort... Plus,
using Confluence, there are certainly a few things that could be nicely
linked to Jira (both being Atlassian products with a nice license for Ope
You both convinced me this is the right functional approach -and that no
(mostly) technical trick alone would meet those (the last one was not
working btw, some class loading security errors, ugh...).
Note for self: Clear constraints are better than a 'free for all' feature
that will ultimately g
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). I
also remembered that things were easier before solr-215 because the core &
config were singletons. How could we get some sort of singletons back?
Yes, I'm ok with it, please do.
ryantxu wrote:
>
> ...
> If you feel ok with 414, I will commit it.
> ...
>
--
View this message in context:
http://www.nabble.com/Initializing---break-init%28%29-API-compatibility--tf4808463.html#a13839870
Sent from the Solr - Dev mailing list archive at Na
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.
I've got a 414 + 350 + 409 working but I don't know where to upload it.
Should we f
The Compatiblity package:
http://www.nabble.com/file/p13797408/Compatibility.java Compatibility.java
--
View this message in context:
http://www.nabble.com/Initializing---break-init%28%29-API-compatibility--tf4808463.html#a13797408
Sent from the Solr - Dev mailing list archive at Nabble.com.
On the premise that no API change would/will be allowed in the current
version, I've pursued experimentation and reached a solution.
Of course, if we were to change the API in 1.3, that makes what follows a
moot point.
So, let's assume we can only change the API in 1.4 after we deprecated in
1.3.
Forget my previous message; the experimentation proved to require more
modifications than anticipated and a lot of added complexity.
The only thing that came out of it is that I (finally) understood your idea
of using ThreadLocal to implement a workaround in case the APIs can not
move.
--
View t
I may have an alternative that would preserve the existing 1.2 'init' APIs
and still keep (hopefully all) the solr-399 features.
To instantiate a core, we need a schema and config; to instantiate a schema,
we need a config - and the core config & schema config should be the same.
I'm experimenti
I'm in a situation where Solr is embedded in a webapp (ie using solr.jar).
Other modules of this app are using log4j and I'm looking for a way to make
the logging configuration consistent (aka through log4.xml).
Can anyone who solved the same kind of issue share his/her experience?
After much bro
ryantxu wrote:
>
> but I fear we are turning the initialization into a jumbled spaghetti of
> interface looparounds, callbacks and pending lists
> of soon-to-be-initialized stuff.
> (not just this patch - but the combination of requirements we have had for
> all the plugin stuff)
>
I agree thi
My apologies for generating confusion.
The original solr-215 has a small blurb about its intentions that still
remain true today that I'll try to beef up and make more comprehensible (in
solr-350 most probably). There are 2 functional axis; one axis is about
easing deployment in IT constrained e
ryantxu wrote:
>
> Is the patch ready for a serious review? or are you still working on it?
>
Not sure if this I'm supposed to answer but anyway, I was expecting comments
before 'generalizing' the patch. Right now, it only applies to filter &
tokenizer factories. The foundation should be soli
Created solr-409 as a sub-task of solr-215 to track and post patch.
I took the shareable library directory path (ie you can specify the library
directory used by a given core and whether it is shared or not); if 2 cores
specify the same directory and they are shared, there will be only one
instan
It seems to me multicore should avoid replicating (or restricting itself to)
features what we can get with multiple web apps; I advocate allowing tighter
couplings between cores in the former which seems to me closer to user
expectations (at least Walter's). If we keep one class loader per core
in
ead of per core.
Hope this helps
Henrib
Walter Ferrara-2 wrote:
>
> I'm currently using latest solr + SOLR350 in a multicore solr.
> I've a ConnectionPool, which use a singleton design, it has been tested
> and it really works as singleton.
> Every cores have an h
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).
--
View this message in context:
http://www.nabble.com/SolrConfig.Initializable-tf46650
Updated the patch which is now functional (solr-399).
--
View this message in context:
http://www.nabble.com/SolrConfig.Initializable-tf4665036.html#a13470794
Sent from the Solr - Dev mailing list archive at Nabble.com.
I took the liberty of creating solr-399 to track this (and allow posting a
patch).
hossman wrote:
>
>
> The SolrConfig.Initializable interface was introduced as part of SOLR-215
> to give Token(izer|Filter)Factories access to the SolrConfig (i believe
> just because StopFilter and SynonymFi
On the functional side, it might be beneficial to keep the newInstance as is
but introduce an initInstance.
We might want instances to be initialized with some of their current
arguments before we set the core.
This way, we may unify all plugin & factory like functionality under one
hood; the sequ
other opinion
on that solution though.
Cheers
Henrib
Doug Daniels wrote:
>
> Hi,
>
> I'm working on a request handler pluging that needs to use a DocSet filter
> (for distance limiting) as well as a list of filter queries to filter down
> a search. I'm trying to figure
I agree that the core being accessible whilst not being fully initialized is
not very "comfortable".
We could either add a status to the core and have each high-level core
method check this status before running (which would also allow to have
cores logically stopped -or marked under reload/backup
init. The remnant shows in
SolrCore.createInstance.
The SolrConfig.Initializable was introduced to reduce the change scope of
the patch.
Any reason to (re)introduce SolrCore.Initializable instead of constructors
that can take a SolrCore as a parameter?
Henrib
hossman wrote:
>
esult"...
Cheers
Daniel Naber-10 wrote:
>
> On Thursday 18 October 2007 14:16, Henrib wrote:
>
>> 1/ Anyone with the same kind of functional requirements? Is using
>> multiple cores a bad idea for this need ?
>
> Are documents sorted by relevance? Then this approa
We have an application where we index documents that can exist in many (at
least 2) languages.
We have 1 SolrCore per language using the same field names in their schemas
(different stopwords , synonyms & stemmers), the benefits for content
maintenance overweighting (at least) complexity.
Using EN
You're absolutely right. I went too fast.
We can access the http request parameters from the servlet filter though, so
this "quick fix" might be possible.
Henri
Yonik Seeley wrote:
>
> On 7/11/07, Henrib <[EMAIL PROTECTED]> wrote:
>> Passing the core name as an
Yonik Seeley wrote:
>
> On 7/11/07, Will Johnson <[EMAIL PROTECTED]> wrote:
>> I think it would be nice to have the core name
>> specified as a CGI param instead of (or in addition to) a url path.
>> Otherwise, large section of client code (such as solrj/solr#) will need
>> to be changed.
>
> O
versus a 'Solr
cluster management' application...
At this point, Solr-215 just looks like a solution to my problem...
My apologies for the clutter & waste of community resources.
Yonik Seeley wrote:
>
> On 6/27/07, Henrib <[EMAIL PROTECTED]> wrote:
>> This http://
This http://www.nabble.com/multiple-indices-tf3982573.html thread triggers
the question again.
Solr-215 makes it easier to deploy multiple indexes than using multiple web
applications; but is "easier" enough for not being just a superfluous
feature?
Henrib wrote:
>
>
>
and continue work on 1.3 with less
constraints, this would give everyone more time; if I were to do so, would
it be better to base on 1.2.dev or 1.2.1 branch?
Henrib
hossman_lucene wrote:
>
>
> : Do you have any recommendation to ease keeping the patch 'up to date'
> with
>
It's a relief to know this is not out of the project scope.
Do you have any recommendation to ease keeping the patch 'up to date' with
the trunk?
What else can/should I do to help the review?
Yonik Seeley wrote:
>
> On 6/15/07, Henrib <[EMAIL PROTECTED]> wrote:
The idea of the multiple core/indexes feature has been discussed in many
threads and it seems/seemed it has/had some functional value; how do we
ensure this value is generic enough for the issue (& patch) to ever be
solved? More importantly, is there an issue in the first place?
For all use cas
66 matches
Mail list logo
