[jira] Commented: (SOLR-614) Allow components to read any kind of XML from solrconfig
[ https://issues.apache.org/jira/browse/SOLR-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615146#action_12615146 ] Noble Paul commented on SOLR-614: - The scope of this bug is not same as http://www.nabble.com/lesser-noise-in-solrconfig.xml-td18253180.html#a18253180 I descoped it. It *WILL NOT* make any changes to the _solrconfig.xml_. The intend is to enable new components to take advantage of a flexible format. When I say new components the components written by users after 1.3 (intended to run on top of 1.3) We use our own custom components in our organization. I am sure there are a lot of other users who do that. There is no harm in enabling them to choose their format (if they wish to do so) If we plan to change the configuration in any which way in the future , how can this affect any of our plans? The implementation does not have to be the same (or even the scope) . But we should allow more flexibility in the API for component writers > Allow components to read any kind of XML from solrconfig > > > Key: SOLR-614 > URL: https://issues.apache.org/jira/browse/SOLR-614 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Noble Paul >Assignee: Shalin Shekhar Mangar >Priority: Trivial > Fix For: 1.3 > > Attachments: SOLR-614.patch, SOLR-614.patch > > > All the components initialized by Solr have an init(NamedList args) > initializer. This leads us to writing the configuration needed for the > component in the NamedList xml format. People familiar with Solr may know the > format but most of what is written is noise than information. For users who > are not familiar w/ the format find it too difficult to understand why they > have to write it this way. Moreover , it is not a very efficient way to > configure . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Build failed in Hudson: Solr-trunk #502
See http://hudson.zones.apache.org/hudson/job/Solr-trunk/502/changes -- Failed to access build log java.io.InterruptedIOException at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:199) at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264) at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.readLine(BufferedReader.java:299) at java.io.BufferedReader.readLine(BufferedReader.java:362) at hudson.model.Run.getLog(Run.java:892) at hudson.tasks.MailSender.createFailureMail(MailSender.java:185) at hudson.tasks.MailSender.getMail(MailSender.java:90) at hudson.tasks.MailSender.execute(MailSender.java:58) at hudson.tasks.Mailer._perform(Mailer.java:74) at hudson.tasks.Mailer.perform(Mailer.java:68) at hudson.tasks.BuildStepCompatibilityLayer.perform(BuildStepCompatibilityLayer.java:33) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:302) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:290) at hudson.model.Build$RunnerImpl.post2(Build.java:136) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:275) at hudson.model.Run.run(Run.java:769) at hudson.model.Build.run(Build.java:103) at hudson.model.ResourceController.execute(ResourceController.java:70) at hudson.model.Executor.run(Executor.java:77)
solr http 500 look
What about commenting out this piece of outdated code in SolrServlet:
} catch (Throwable e) {
SolrException.log(log,e);
sendErr(500, SolrException.toStr(e), request, response);
}
For instance, SUN Java 5 not necessarily has resources to output
OutOfMemoryError including stack trace; only JRockit can do it... I
understand that historically SOLR developers tried to implement full power
of HTTP, but let's be more pragmatic...
P.S.
It didn't reach SOLR-DEV. Forwarding to SOLR-USER.
Sent: Sunday, July 20, 2008 7:34 PM
To: solr-dev@lucene.apache.org
Subject: solr http 500 look
...
solr http 500 look
What about commenting out this piece of outdated code in SolrServlet:
} catch (Throwable e) {
SolrException.log(log,e);
sendErr(500, SolrException.toStr(e), request, response);
}
For instance, SUN Java 5 not necessarily has resources to output
OutOfMemoryError including stack trace; only JRockit can do it... I
understand that historically SOLR developers tried to implement full power
of HTTP, but let's be more pragmatic...
Re: Welcom Shalin Shekhar Mangar
Welcome aboard, Shalin! -Mike On 19-Jul-08, at 12:01 PM, Shalin Shekhar Mangar wrote: Thanks! I work at AOL in Bangalore as part of a small team which gets to work on a variety of (very cool!) stuff. Though my involvement started when we decided to contribute part of our work to Solr (DataImportHandler), it soon became a personal passion and has remained so since. AOL continues to encourage and support me for which I'm thankful. I'm very happy to be a part of this community and I'm looking forward to working more closely with you all. On Sat, Jul 19, 2008 at 1:12 AM, Grant Ingersoll <[EMAIL PROTECTED]> wrote: I am pleased to announce that the Lucene PMC has named Shalin Shekhar Mangar as a Solr committer. Shalin has already contributed numerous patches to the community as well as answers and help on the user list. Shalin, tradition has it that new committers introduce themselves a little bit, so feel free to drop a note about where you work, etc. if you are so inclined. Thanks, Grant -- Regards, Shalin Shekhar Mangar.
Re: Too many open files with DirectUpdateHandlerOptimizeTest
Does it happen on a fresh checkout? I use windows (and cygwin for the familiar command line interface), which has higher limits. Also watch out for the system-wide limit: http://www.cs.wisc.edu/condor/condorg/linux_scalability.html If it happens with a fresh checkout, perhaps we could lower the merge factor for that test. -Yonik On Sun, Jul 20, 2008 at 2:59 PM, Shalin Shekhar Mangar <[EMAIL PROTECTED]> wrote: > Hi, > > The DirectUpdateHandlerOptimizeTest fails on my local box due to too many > open files. The nightly build does not fail so I'm assuming it must be > something specific to my setup. Has anyone else seen this problem on their > local environment? > > ulimit -n gives 1024 on my Ubuntu Hardy Heron. > > name="testOptimize" time="5.687"> > type="java.lang.RuntimeException">java.lang.RuntimeException: > java.io.FileNotFoundException: > /tmp/org.apache.solr.update.DirectUpdateHandlerOptimizeTest-1216580007333/index/_9u.tii > (Too many open files) >at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:806) >at > org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:368) >at > org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testOptimize(DirectUpdateHandlerOptimizeTest.java:62) > Caused by: java.io.FileNotFoundException: > /tmp/org.apache.solr.update.DirectUpdateHandlerOptimizeTest-1216580007333/index/_9u.tii > (Too many open files) >at java.io.RandomAccessFile.open(Native Method) >at java.io.RandomAccessFile.(RandomAccessFile.java:212) >at > org.apache.lucene.store.FSDirectory$FSIndexInput$Descriptor. (FSDirectory.java:539) >at > org.apache.lucene.store.FSDirectory$FSIndexInput. (FSDirectory.java:569) >at > org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:478) >at > org.apache.lucene.index.TermInfosReader. (TermInfosReader.java:80) >at > org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:319) >at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:264) >at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:199) >at > org.apache.lucene.index.MultiSegmentReader. (MultiSegmentReader.java:55) >at > org.apache.lucene.index.DirectoryIndexReader$1.doBody(DirectoryIndexReader.java:93) >at > org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:649) >at > org.apache.lucene.index.DirectoryIndexReader.open(DirectoryIndexReader.java:81) >at org.apache.lucene.index.IndexReader.open(IndexReader.java:209) >at org.apache.lucene.index.IndexReader.open(IndexReader.java:173) >at > org.apache.solr.search.SolrIndexSearcher. (SolrIndexSearcher.java:93) >at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:797) > > > > > -- > Regards, > Shalin Shekhar Mangar. >
[jira] Commented: (SOLR-614) Allow components to read any kind of XML from solrconfig
[ https://issues.apache.org/jira/browse/SOLR-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615122#action_12615122 ] Ryan McKinley commented on SOLR-614: If I understood the discussion on the dev list properly, we would put off any syntax changes until 2.0, and then hopefully use some configuration standards that we don't maintain (spring) http://www.nabble.com/lesser-noise-in-solrconfig.xml-td18253180.html#a18253180 Yes, the new format is cleaner and more clear, but I fear compatibility/clarity issues with existing 1.x setups and multiple syntaxs for the same thing seems problematic. I think we should mark this as "won't fix", and save the configuration cleanup till we can do it well -- ie, spring. > Allow components to read any kind of XML from solrconfig > > > Key: SOLR-614 > URL: https://issues.apache.org/jira/browse/SOLR-614 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Noble Paul >Assignee: Shalin Shekhar Mangar >Priority: Trivial > Fix For: 1.3 > > Attachments: SOLR-614.patch, SOLR-614.patch > > > All the components initialized by Solr have an init(NamedList args) > initializer. This leads us to writing the configuration needed for the > component in the NamedList xml format. People familiar with Solr may know the > format but most of what is written is noise than information. For users who > are not familiar w/ the format find it too difficult to understand why they > have to write it this way. Moreover , it is not a very efficient way to > configure . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-561) Solr replication by Solr (for windows also)
[ https://issues.apache.org/jira/browse/SOLR-561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar reassigned SOLR-561: -- Assignee: Shalin Shekhar Mangar > Solr replication by Solr (for windows also) > --- > > Key: SOLR-561 > URL: https://issues.apache.org/jira/browse/SOLR-561 > Project: Solr > Issue Type: New Feature > Components: replication >Affects Versions: 1.3 > Environment: All >Reporter: Noble Paul >Assignee: Shalin Shekhar Mangar > Attachments: deletion_policy.patch, SOLR-561-core.patch, > SOLR-561.patch, SOLR-561.patch, SOLR-561.patch, SOLR-561.patch > > > The current replication strategy in solr involves shell scripts . The > following are the drawbacks with the approach > * It does not work with windows > * Replication works as a separate piece not integrated with solr. > * Cannot control replication from solr admin/JMX > * Each operation requires manual telnet to the host > Doing the replication in java has the following advantages > * Platform independence > * Manual steps can be completely eliminated. Everything can be driven from > solrconfig.xml . > ** Adding the url of the master in the slaves should be good enough to enable > replication. Other things like frequency of > snapshoot/snappull can also be configured . All other information can be > automatically obtained. > * Start/stop can be triggered from solr/admin or JMX > * Can get the status/progress while replication is going on. It can also > abort an ongoing replication > * No need to have a login into the machine > This issue can track the implementation of solr replication in java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-617) Allow configurable deletion policy
[
https://issues.apache.org/jira/browse/SOLR-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar reassigned SOLR-617:
--
Assignee: Shalin Shekhar Mangar
> Allow configurable deletion policy
> --
>
> Key: SOLR-617
> URL: https://issues.apache.org/jira/browse/SOLR-617
> Project: Solr
> Issue Type: New Feature
> Components: search, update
>Affects Versions: 1.3
>Reporter: Noble Paul
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
>
> Lucene API provides means to configure deletion policy. Solr should be able
> to expose it through configuration in solrconfig.xml. Moreover the new
> replication (SOLR-561) strategy is going to rely on this .
> I propose the configuration go into the section
> sample configuration
> {code:xml|title=solrconfig.xml}
>
>
>
>
> true
>
>
>
>
>
>
>
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-551) SOlr replication should include the schema also
[ https://issues.apache.org/jira/browse/SOLR-551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar reassigned SOLR-551: -- Assignee: Shalin Shekhar Mangar > SOlr replication should include the schema also > --- > > Key: SOLR-551 > URL: https://issues.apache.org/jira/browse/SOLR-551 > Project: Solr > Issue Type: Improvement > Components: replication >Affects Versions: 1.3 >Reporter: Noble Paul >Assignee: Shalin Shekhar Mangar > > The current Solr replication just copy the data directory . So if the > schema changes and I do a re-index it will blissfully copy the index > and the slaves will fail because of incompatible schema. > So the steps we follow are > * Stop rsync on slaves > * Update the master with new schema > * re-index data > * forEach slave > ** Kill the slave > ** clean the data directory > ** install the new schema > ** restart > ** do a manual snappull > The amount of work the admin needs to do is quite significant > (depending on the no:of slaves). These are manual steps and very error > prone > The solution : > Make the replication mechanism handle the schema replication also. So > all I need to do is to just change the master and the slaves synch > automatically > What is a good way to implement this? > We have an idea along the following lines > This should involve changes to the snapshooter and snappuller scripts > and the snapinstaller components > Everytime the snapshooter takes a snapshot it must keep the timestamps > of schema.xml and elevate.xml (all the files which might affect the > runtime behavior in slaves) > For subsequent snapshots if the timestamps of any of them is changed > it must copy the all of them also for replication. > The snappuller copies the new directory as usual > The snapinstaller checks if these config files are present , > if yes, > * It can create a temporary core > * install the changed index and configuration > * load it completely and swap it out with the original core -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-614) Allow components to read any kind of XML from solrconfig
[ https://issues.apache.org/jira/browse/SOLR-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar reassigned SOLR-614: -- Assignee: Shalin Shekhar Mangar > Allow components to read any kind of XML from solrconfig > > > Key: SOLR-614 > URL: https://issues.apache.org/jira/browse/SOLR-614 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Noble Paul >Assignee: Shalin Shekhar Mangar >Priority: Trivial > Fix For: 1.3 > > Attachments: SOLR-614.patch, SOLR-614.patch > > > All the components initialized by Solr have an init(NamedList args) > initializer. This leads us to writing the configuration needed for the > component in the NamedList xml format. People familiar with Solr may know the > format but most of what is written is noise than information. For users who > are not familiar w/ the format find it too difficult to understand why they > have to write it this way. Moreover , it is not a very efficient way to > configure . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: solr admin look
On Sun, Jul 20, 2008 at 10:33 PM, Mark Miller <[EMAIL PROTECTED]> wrote: > What do people feel of the current Solr admin look? Personally I think its > a bit on the rough side. Are people interested in improving it? > > http://issues.apache.org/jira/browse/SOLR-84 > > Those logo's prove there are some talented designers in the community. > Anyone willing to take a shot at bringing the solr look up to the level of > the solr code? Or does the majority of the community think the current look > is good? > +1 for a new logo. It's a new release, let's have a new logo too! First step is to decide which one of these is more Solr-ish. > > In the spirit of starting a search for an improved look, here is an > admittedly amateurish attempt at doing something a little more modern: > > http://myhardshadow.com/img/NewSolrAdminPage.jpg > I like this one. The white background is a welcome change. -- Regards, Shalin Shekhar Mangar.
[jira] Assigned: (SOLR-622) SpellCheckComponent should build or load indices on startup and commits
[ https://issues.apache.org/jira/browse/SOLR-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar reassigned SOLR-622: -- Assignee: Shalin Shekhar Mangar > SpellCheckComponent should build or load indices on startup and commits > --- > > Key: SOLR-622 > URL: https://issues.apache.org/jira/browse/SOLR-622 > Project: Solr > Issue Type: Improvement > Components: spellchecker >Affects Versions: 1.3 >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 1.3 > > > SpellCheckComponent must be able to build/load spell check index on startup > and commits. With SOLR-605, SpellCheckComponent can register an event > listener for firstSearcher and newSearcher events and rebuild/reload indices > as appropriate. > * If index uses a FSDirectory and exists on disk then just reload it or else > build it on firstSearcher event. > * If index is built from a Solr field then re-build it on newSearcher event. > This will help avoid having to add QuerySenderListener in configuration and > will not force people to issue build on first query. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-616) FileBasedSpellChecker does not apply accuracy configuration
[ https://issues.apache.org/jira/browse/SOLR-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-616. Resolution: Fixed > FileBasedSpellChecker does not apply accuracy configuration > --- > > Key: SOLR-616 > URL: https://issues.apache.org/jira/browse/SOLR-616 > Project: Solr > Issue Type: Bug > Components: spellchecker >Affects Versions: 1.3 >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-616.patch > > > The spellchecker accuracy specified in configuration is set only inside > IndexBasedSpellChecker#init but not in FileBasedSpellChecker#init method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Too many open files with DirectUpdateHandlerOptimizeTest
Hi, The DirectUpdateHandlerOptimizeTest fails on my local box due to too many open files. The nightly build does not fail so I'm assuming it must be something specific to my setup. Has anyone else seen this problem on their local environment? ulimit -n gives 1024 on my Ubuntu Hardy Heron. java.lang.RuntimeException: java.io.FileNotFoundException: /tmp/org.apache.solr.update.DirectUpdateHandlerOptimizeTest-1216580007333/index/_9u.tii (Too many open files) at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:806) at org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:368) at org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testOptimize(DirectUpdateHandlerOptimizeTest.java:62) Caused by: java.io.FileNotFoundException: /tmp/org.apache.solr.update.DirectUpdateHandlerOptimizeTest-1216580007333/index/_9u.tii (Too many open files) at java.io.RandomAccessFile.open(Native Method) at java.io.RandomAccessFile.(RandomAccessFile.java:212) at org.apache.lucene.store.FSDirectory$FSIndexInput$Descriptor. (FSDirectory.java:539) at org.apache.lucene.store.FSDirectory$FSIndexInput. (FSDirectory.java:569) at org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:478) at org.apache.lucene.index.TermInfosReader. (TermInfosReader.java:80) at org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:319) at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:264) at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:199) at org.apache.lucene.index.MultiSegmentReader. (MultiSegmentReader.java:55) at org.apache.lucene.index.DirectoryIndexReader$1.doBody(DirectoryIndexReader.java:93) at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:649) at org.apache.lucene.index.DirectoryIndexReader.open(DirectoryIndexReader.java:81) at org.apache.lucene.index.IndexReader.open(IndexReader.java:209) at org.apache.lucene.index.IndexReader.open(IndexReader.java:173) at org.apache.solr.search.SolrIndexSearcher. (SolrIndexSearcher.java:93) at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:797) -- Regards, Shalin Shekhar Mangar.
[jira] Assigned: (SOLR-616) FileBasedSpellChecker does not apply accuracy configuration
[ https://issues.apache.org/jira/browse/SOLR-616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar reassigned SOLR-616: -- Assignee: Shalin Shekhar Mangar > FileBasedSpellChecker does not apply accuracy configuration > --- > > Key: SOLR-616 > URL: https://issues.apache.org/jira/browse/SOLR-616 > Project: Solr > Issue Type: Bug > Components: spellchecker >Affects Versions: 1.3 >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 1.3 > > Attachments: SOLR-616.patch > > > The spellchecker accuracy specified in configuration is set only inside > IndexBasedSpellChecker#init but not in FileBasedSpellChecker#init method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: solr admin look
On Sun, Jul 20, 2008 at 1:03 PM, Mark Miller <[EMAIL PROTECTED]> wrote: > What do people feel of the current Solr admin look? Personally I think its a > bit on the rough side. Are people interested in improving it? I'm interested in seeing it improved... It would be great if someone could work toward generating a consensus. -Yonik > http://issues.apache.org/jira/browse/SOLR-84 > > Those logo's prove there are some talented designers in the community. > Anyone willing to take a shot at bringing the solr look up to the level of > the solr code? Or does the majority of the community think the current look > is good? > > In the spirit of starting a search for an improved look, here is an > admittedly amateurish attempt at doing something a little more modern: > > http://myhardshadow.com/img/NewSolrAdminPage.jpg > > And a slightly different direction: > > http://myhardshadow.com/img/NewSolrAdminPage2.jpg > That's a two minute session with the css - someone with some real talent > willing to give it a go? > > - Mark >
[jira] Updated: (SOLR-593) Solr hangs at QueryElevationComponent.inform() if elevate.xml is in data directory
[ https://issues.apache.org/jira/browse/SOLR-593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-593: -- Attachment: SOLR-593.patch This patch implements a getNewestSearcher() method, and keeps a list of searchers that are currently open. Keeping a list like this opens a race condition in that someone could aquire a reference from the list just as close is being called. To protect against this, the list is only accessed when searcherLock is held, and the close() of RefCounted aquires searcherLock and checks the referece count again. If it's greater than 0, it aborts the close. Having the list will also be useful for using Lucene's new reopen, as well as other future admin actions. All tests pass, but I'm going to do some ad-hoc testing to make sure this hasn't introduced any new issues. > Solr hangs at QueryElevationComponent.inform() if elevate.xml is in data > directory > -- > > Key: SOLR-593 > URL: https://issues.apache.org/jira/browse/SOLR-593 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.3 >Reporter: Koji Sekiguchi > Fix For: 1.3 > > Attachments: SOLR-593.patch > > > The thread dump is: > "main" prio=6 tid=0x003f81d8 nid=0x10e4 in Object.wait() > [0x0006f000..0x0006fc20] > at java.lang.Object.wait(Native Method) > - waiting on <0x23dd0188> (a java.lang.Object) > at java.lang.Object.wait(Object.java:474) > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:685) > - locked <0x23dd0188> (a java.lang.Object) > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:624) > at > org.apache.solr.handler.component.QueryElevationComponent.inform(QueryElevationComponent.java:185) > - locked <0x23e51ee0> (a java.util.WeakHashMap) > at > org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.java:264) > at org.apache.solr.core.SolrCore.(SolrCore.java:396) > - locked <0x27b44b60> (a java.lang.Class) > at > org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:90) > at > org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:99) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:594) > at org.mortbay.jetty.servlet.Context.startContext(Context.java:139) > at > org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1218) > at > org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:500) > at > org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:448) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147) > at > org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:161) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117) > at org.mortbay.jetty.Server.doStart(Server.java:210) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:929) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.mortbay.start.Main.invokeMain(Main.java:183) > at org.mortbay.start.Main.start(Main.java:497) > at org.mortbay.start.Main.main(Main.java:115) > The cause is that accessing reader during SolrCoreAware.inform(). Shalin > pointed out same thing at: > http://www.nabble.com/Accessing-IndexReader-during-core-initialization-hangs-init-td17259235.html#a17259235 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
solr admin look
What do people feel of the current Solr admin look? Personally I think its a bit on the rough side. Are people interested in improving it? http://issues.apache.org/jira/browse/SOLR-84 Those logo's prove there are some talented designers in the community. Anyone willing to take a shot at bringing the solr look up to the level of the solr code? Or does the majority of the community think the current look is good? In the spirit of starting a search for an improved look, here is an admittedly amateurish attempt at doing something a little more modern: http://myhardshadow.com/img/NewSolrAdminPage.jpg And a slightly different direction: http://myhardshadow.com/img/NewSolrAdminPage2.jpg That's a two minute session with the css - someone with some real talent willing to give it a go? - Mark
[jira] Commented: (SOLR-593) Solr hangs at QueryElevationComponent.inform() if elevate.xml is in data directory
[ https://issues.apache.org/jira/browse/SOLR-593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615102#action_12615102 ] Yonik Seeley commented on SOLR-593: --- bq. Can we introduce getColdSearcher() method so that SolrCoreAware components can call it to get searcher That could work. We could also try to do something more generic like getNewestSearcher() that could be called in any context. That could also be used internally to use the new lucene reopen() for better efficiency. But the implementation would be a little tricky. > Solr hangs at QueryElevationComponent.inform() if elevate.xml is in data > directory > -- > > Key: SOLR-593 > URL: https://issues.apache.org/jira/browse/SOLR-593 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.3 >Reporter: Koji Sekiguchi > Fix For: 1.3 > > > The thread dump is: > "main" prio=6 tid=0x003f81d8 nid=0x10e4 in Object.wait() > [0x0006f000..0x0006fc20] > at java.lang.Object.wait(Native Method) > - waiting on <0x23dd0188> (a java.lang.Object) > at java.lang.Object.wait(Object.java:474) > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:685) > - locked <0x23dd0188> (a java.lang.Object) > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:624) > at > org.apache.solr.handler.component.QueryElevationComponent.inform(QueryElevationComponent.java:185) > - locked <0x23e51ee0> (a java.util.WeakHashMap) > at > org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.java:264) > at org.apache.solr.core.SolrCore.(SolrCore.java:396) > - locked <0x27b44b60> (a java.lang.Class) > at > org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:90) > at > org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:99) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:594) > at org.mortbay.jetty.servlet.Context.startContext(Context.java:139) > at > org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1218) > at > org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:500) > at > org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:448) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147) > at > org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:161) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117) > at org.mortbay.jetty.Server.doStart(Server.java:210) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:929) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.mortbay.start.Main.invokeMain(Main.java:183) > at org.mortbay.start.Main.start(Main.java:497) > at org.mortbay.start.Main.main(Main.java:115) > The cause is that accessing reader during SolrCoreAware.inform(). Shalin > pointed out same thing at: > http://www.nabble.com/Accessing-IndexReader-during-core-initialization-hangs-init-td17259235.html#a17259235 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-84) New Solr logo?
[ https://issues.apache.org/jira/browse/SOLR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615086#action_12615086 ] Mark Miller commented on SOLR-84: - Some of these logos are awesome, and all of them are (IMHO) better than the current one - why not update to one? > New Solr logo? > -- > > Key: SOLR-84 > URL: https://issues.apache.org/jira/browse/SOLR-84 > Project: Solr > Issue Type: Improvement >Reporter: Bertrand Delacretaz >Priority: Minor > Attachments: logo-grid.jpg, logo-solr-d.jpg, logo-solr-e.jpg, > logo-solr-source-files-take2.zip, solr-84-source-files.zip, solr-f.jpg, > solr-logo-20061214.jpg, solr-logo-20061218.JPG, solr-logo-20070124.JPG, > solr-nick.gif, solr.jpg, sslogo-solr-flare.jpg, sslogo-solr.jpg, > sslogo-solr2-flare.jpg, sslogo-solr2.jpg, sslogo-solr3.jpg > > > Following up on SOLR-76, our trainee Nicolas Barbay (nicolas (put at here) > sarraux-dessous.ch) has reworked his logo proposal to be more "solar". > This can either be the start of a logo contest, or if people like it we could > adopt it. The gradients can make it a bit hard to integrate, not sure if this > is really a problem. > WDYT? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-593) Solr hangs at QueryElevationComponent.inform() if elevate.xml is in data directory
[ https://issues.apache.org/jira/browse/SOLR-593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12615082#action_12615082 ] Koji Sekiguchi commented on SOLR-593: - Can we introduce getColdSearcher() method so that SolrCoreAware components can call it to get searcher, instead of getSearcher(), to avoid this deadlock? getColdSearcher() always returns a cold searcher regardless of useColdSearcher setting... > Solr hangs at QueryElevationComponent.inform() if elevate.xml is in data > directory > -- > > Key: SOLR-593 > URL: https://issues.apache.org/jira/browse/SOLR-593 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.3 >Reporter: Koji Sekiguchi > Fix For: 1.3 > > > The thread dump is: > "main" prio=6 tid=0x003f81d8 nid=0x10e4 in Object.wait() > [0x0006f000..0x0006fc20] > at java.lang.Object.wait(Native Method) > - waiting on <0x23dd0188> (a java.lang.Object) > at java.lang.Object.wait(Object.java:474) > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:685) > - locked <0x23dd0188> (a java.lang.Object) > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:624) > at > org.apache.solr.handler.component.QueryElevationComponent.inform(QueryElevationComponent.java:185) > - locked <0x23e51ee0> (a java.util.WeakHashMap) > at > org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.java:264) > at org.apache.solr.core.SolrCore.(SolrCore.java:396) > - locked <0x27b44b60> (a java.lang.Class) > at > org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:90) > at > org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:99) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:594) > at org.mortbay.jetty.servlet.Context.startContext(Context.java:139) > at > org.mortbay.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1218) > at > org.mortbay.jetty.handler.ContextHandler.doStart(ContextHandler.java:500) > at > org.mortbay.jetty.webapp.WebAppContext.doStart(WebAppContext.java:448) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147) > at > org.mortbay.jetty.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:161) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.handler.HandlerCollection.doStart(HandlerCollection.java:147) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at > org.mortbay.jetty.handler.HandlerWrapper.doStart(HandlerWrapper.java:117) > at org.mortbay.jetty.Server.doStart(Server.java:210) > at > org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:40) > at org.mortbay.xml.XmlConfiguration.main(XmlConfiguration.java:929) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.mortbay.start.Main.invokeMain(Main.java:183) > at org.mortbay.start.Main.start(Main.java:497) > at org.mortbay.start.Main.main(Main.java:115) > The cause is that accessing reader during SolrCoreAware.inform(). Shalin > pointed out same thing at: > http://www.nabble.com/Accessing-IndexReader-during-core-initialization-hangs-init-td17259235.html#a17259235 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-614) Allow components to read any kind of XML from solrconfig
[ https://issues.apache.org/jira/browse/SOLR-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-614: Comment: was deleted > Allow components to read any kind of XML from solrconfig > > > Key: SOLR-614 > URL: https://issues.apache.org/jira/browse/SOLR-614 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Noble Paul >Priority: Trivial > Fix For: 1.3 > > Attachments: SOLR-614.patch, SOLR-614.patch > > > All the components initialized by Solr have an init(NamedList args) > initializer. This leads us to writing the configuration needed for the > component in the NamedList xml format. People familiar with Solr may know the > format but most of what is written is noise than information. For users who > are not familiar w/ the format find it too difficult to understand why they > have to write it this way. Moreover , it is not a very efficient way to > configure . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-614) Allow components to read any kind of XML from solrconfig
[ https://issues.apache.org/jira/browse/SOLR-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-614: Attachment: SOLR-614.patch The new patch for the changes proposed > Allow components to read any kind of XML from solrconfig > > > Key: SOLR-614 > URL: https://issues.apache.org/jira/browse/SOLR-614 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Noble Paul >Priority: Trivial > Fix For: 1.3 > > Attachments: SOLR-614.patch, SOLR-614.patch > > > All the components initialized by Solr have an init(NamedList args) > initializer. This leads us to writing the configuration needed for the > component in the NamedList xml format. People familiar with Solr may know the > format but most of what is written is noise than information. For users who > are not familiar w/ the format find it too difficult to understand why they > have to write it this way. Moreover , it is not a very efficient way to > configure . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-614) Allow components to read any kind of XML from solrconfig
[
https://issues.apache.org/jira/browse/SOLR-614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610468#action_12610468
]
noble.paul edited comment on SOLR-614 at 7/20/08 3:19 AM:
--
If the configuration of a handler is as follows
{code:xml}
some-name
solr.MyClass
{code}
The values can be read from the iniArgs as follows
{code:java}
NamedList defaults = (NamedList )initArgs.get("default");
String name = (String)defaults.get("name");
String classname = (String)defaults.get("classname");
{code}
Even attributes can be read as in the following config
{code:xml}
{code}
The values can be read from the iniArgs as follows
{code:java}
NamedList defaults = (NamedList )initArgs.get("default");
String name = (String)defaults.get("@name");
String classname = (String)defaults.get("@classname");
{code}
was (Author: noble.paul):
This patch can automatically make these representations equivalent. This is
fully backward compitible.
* NamedList format: 1
{code:xml}
default
solr.IndexBasedSpellChecker
spell
./spellchecker
jarowinkler
lowerfilt
solr.JaroWinklerDistance
./spellchecker
{code}
* NamedList Format : 2
{code:xml}
default
solr.IndexBasedSpellChecker
spell
./spellchecker
jarowinkler
lowerfilt
solr.JaroWinklerDistance
./spellchecker
{code}
*NamedList format :3
{code:xml}
{code}
> Allow components to read any kind of XML from solrconfig
>
>
> Key: SOLR-614
> URL: https://issues.apache.org/jira/browse/SOLR-614
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 1.3
>Reporter: Noble Paul
>Priority: Trivial
> Fix For: 1.3
>
> Attachments: SOLR-614.patch
>
>
> All the components initialized by Solr have an init(NamedList args)
> initializer. This leads us to writing the configuration needed for the
> component in the NamedList xml format. People familiar with Solr may know the
> format but most of what is written is noise than information. For users who
> are not familiar w/ the format find it too difficult to understand why they
> have to write it this way. Moreover , it is not a very efficient way to
> configure .
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-614) Allow components to read any kind of XML from solrconfig
[ https://issues.apache.org/jira/browse/SOLR-614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-614: Comment: was deleted > Allow components to read any kind of XML from solrconfig > > > Key: SOLR-614 > URL: https://issues.apache.org/jira/browse/SOLR-614 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Noble Paul >Priority: Trivial > Fix For: 1.3 > > Attachments: SOLR-614.patch > > > All the components initialized by Solr have an init(NamedList args) > initializer. This leads us to writing the configuration needed for the > component in the NamedList xml format. People familiar with Solr may know the > format but most of what is written is noise than information. For users who > are not familiar w/ the format find it too difficult to understand why they > have to write it this way. Moreover , it is not a very efficient way to > configure . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
