. The CoreContainer is
already synchronizing in the getCore() method
On Wed, Apr 8, 2009 at 4:50 PM, Henrib hbies...@gmail.com wrote:
It is synchronized due to 1.2 singleton core compatibility:
public static SolrCore getSolrCore() {
synchronized( SolrCore.class ) {
...
It would require a lot
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 നോബിള്
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 me.
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 would be
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:
[
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
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 an
Grant Ingersoll-6 wrote:
I see that we have 13 issues:
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=12310230fixfor=12312486
The URL shows 12 now but solr-647 has no assignee yet.
May be Ryan since
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 can
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
[ ] 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.
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
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
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 incorporating
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
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
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 as
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:
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,
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 dependent
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
reindex
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
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
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?
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
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
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.
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.
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
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 this is
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
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
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 solid
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
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
.
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 handler, responsible for update that will eventually
use
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:
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 SynonymFilter
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
. 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
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
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 approach is problematic as
you
cannot compare the result's score across
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.
Only if you
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:
The idea of the multiple
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://www.nabble.com/multiple-indices-tf3982573.html thread
triggers
the question again.
Solr-215 makes it easier to deploy multiple
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
: the trunk?
One trick i've seen people talk about but haven't had
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
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
51 matches
Mail list logo
