[jira] Created: (SOLR-1308) Cache docsets and docs at the SegmentReader level
Cache docsets and docs at the SegmentReader level - Key: SOLR-1308 URL: https://issues.apache.org/jira/browse/SOLR-1308 Project: Solr Issue Type: Improvement Affects Versions: 1.4 Reporter: Jason Rutherglen Priority: Minor Fix For: 1.5 Solr caches docsets and documents at the top level Multi*Reader level. After a commit, the caches are flushed. Reloading the caches in near realtime (i.e. commits every 1s - 2min) unnecessarily consumes IO resources, especially for largish indexes. We can cache docsets and documents at the SegmentReader level. The cache settings in SolrConfig can be applied to the individual SR caches. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1299) In distributed search cannot search on any schema field in ascending order (descending is OK)
[ https://issues.apache.org/jira/browse/SOLR-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12734822#action_12734822 ] Yonik Seeley commented on SOLR-1299: Perhaps we should use FieldComparatorSource/FieldComparator since ScoreDocComparator will be going away in 3.0? Hard coding to missingStringLast probably won't work for everything either. Perhaps we could do fcomp = FieldComparator.newComparator(String fieldname, int numHits=1, int sortPos=1, boolean reversed=false) then to get the values, do something like // whenever reader changes fcomp.setNextReader(IndexReader reader, int docBase, int numSlotsFull=1?) fcomp.copy(int slot=0, int doc=docToGetValueOf) Comparable val = fcomp.value(slot=0) This is closest to how the existing method works. Longer term, the right way may be to record the sort field values when the search is done (via FieldDoc) > In distributed search cannot search on any schema field in ascending order > (descending is OK) > - > > Key: SOLR-1299 > URL: https://issues.apache.org/jira/browse/SOLR-1299 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.4 >Reporter: David Bowen > Fix For: 1.4 > > Attachments: SOLR-1299.patch > > > Using the example with some of the exampledocs posted, the url: > http://localhost:8983/solr/select/?q=*:*&sort=timestamp+desc&fsv=true > works correctly, but change "desc" to "asc" and you get: > HTTP ERROR: 500 > null > java.lang.NullPointerException > at > org.apache.solr.handler.component.QueryComponent.getComparator(QueryComponent.java:284) > at > org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:229) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:195) > at > com.proquest.magnolia.solr.plugins.SummonSearchHandler.handleRequestBody(SummonSearchHandler.java:19) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1299) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) > at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) > at org.mortbay.jetty.Server.handle(Server.java:285) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378) > at > org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226) > at > org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1283) Mark Invalid error on indexing
[
https://issues.apache.org/jira/browse/SOLR-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12734815#action_12734815
]
solrize commented on SOLR-1283:
---
I now have a workaround. The documents I'm indexing don't actually have html
in them, but the schema was set up to use HTMLStripReader anyway. I switched
to the standard analyzer and the problem went away, and indexing also seems to
be running faster than before. I do still think the issue needs fixing since
I'm sure some people use solr to index large web pages which do need html
stripping. Anyway, thanks to Erik H. for advice about this.
> Mark Invalid error on indexing
> --
>
> Key: SOLR-1283
> URL: https://issues.apache.org/jira/browse/SOLR-1283
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
> Environment: Ubuntu 8.04, Sun Java 6
>Reporter: solrize
>
> When indexing large (1 megabyte) documents I get a lot of exceptions with
> stack traces like the below. It happens both in the Solr 1.3 release and in
> the July 9 1.4 nightly. I believe this to NOT be the same issue as SOLR-42.
> I found some further discussion on solr-user:
> http://www.nabble.com/IOException:-Mark-invalid-while-analyzing-HTML-td17052153.html
>
> In that discussion, Grant asked the original poster to open a Jira issue, but
> I didn't see one so I'm opening one; please feel free to merge or close if
> it's redundant.
> My stack trace follows.
> Jul 15, 2009 8:36:42 AM org.apache.solr.core.SolrCore execute
> INFO: [] webapp=/solr path=/update params={} status=500 QTime=3
> Jul 15, 2009 8:36:42 AM org.apache.solr.common.SolrException log
> SEVERE: java.io.IOException: Mark invalid
> at java.io.BufferedReader.reset(BufferedReader.java:485)
> at
> org.apache.solr.analysis.HTMLStripReader.restoreState(HTMLStripReader.java:171)
> at
> org.apache.solr.analysis.HTMLStripReader.read(HTMLStripReader.java:728)
> at
> org.apache.solr.analysis.HTMLStripReader.read(HTMLStripReader.java:742)
> at java.io.Reader.read(Reader.java:123)
> at
> org.apache.lucene.analysis.CharTokenizer.next(CharTokenizer.java:108)
> at org.apache.lucene.analysis.StopFilter.next(StopFilter.java:178)
> at
> org.apache.lucene.analysis.standard.StandardFilter.next(StandardFilter.java:84)
> at
> org.apache.lucene.analysis.LowerCaseFilter.next(LowerCaseFilter.java:53)
> at
> org.apache.solr.analysis.WordDelimiterFilter.next(WordDelimiterFilter.java:347)
> at
> org.apache.lucene.index.DocInverterPerField.processFields(DocInverterPerField.java:159)
> at
> org.apache.lucene.index.DocFieldConsumersPerField.processFields(DocFieldConsumersPerField.java:36)
> at
> org.apache.lucene.index.DocFieldProcessorPerThread.processDocument(DocFieldProcessorPerThread.java:234)
> at
> org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:765)
> at
> org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:748)
> at
> org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:2512)
> at
> org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:2484)
> at
> org.apache.solr.update.DirectUpdateHandler2.addDoc(DirectUpdateHandler2.java:240)
> at
> org.apache.solr.update.processor.RunUpdateProcessor.processAdd(RunUpdateProcessorFactory.java:61)
> at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:140)
> at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:69)
> at
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:54)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1292)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
> at
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
> at
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
> at
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
> at
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
> at
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
> at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
> at
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
> at
> org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
> at
> org.mortbay.jetty.handler.Hand
[jira] Updated: (SOLR-1299) In distributed search cannot search on any schema field in ascending order (descending is OK)
[ https://issues.apache.org/jira/browse/SOLR-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-1299: Attachment: SOLR-1299.patch Here's a patch which adds a fix and a test which fails without the change. I added a new comparator method which mimics the MissingStringLastComparatorSource before SOLR-. I don't know much about distributed search to know if this is the "right" fix. I wouldn't commit this until Yonik reviews and approves. > In distributed search cannot search on any schema field in ascending order > (descending is OK) > - > > Key: SOLR-1299 > URL: https://issues.apache.org/jira/browse/SOLR-1299 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.4 >Reporter: David Bowen > Fix For: 1.4 > > Attachments: SOLR-1299.patch > > > Using the example with some of the exampledocs posted, the url: > http://localhost:8983/solr/select/?q=*:*&sort=timestamp+desc&fsv=true > works correctly, but change "desc" to "asc" and you get: > HTTP ERROR: 500 > null > java.lang.NullPointerException > at > org.apache.solr.handler.component.QueryComponent.getComparator(QueryComponent.java:284) > at > org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:229) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:195) > at > com.proquest.magnolia.solr.plugins.SummonSearchHandler.handleRequestBody(SummonSearchHandler.java:19) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1299) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) > at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) > at org.mortbay.jetty.Server.handle(Server.java:285) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378) > at > org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226) > at > org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1299) In distributed search cannot search on any schema field in ascending order (descending is OK)
[ https://issues.apache.org/jira/browse/SOLR-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12734681#action_12734681 ] Jayson Minard commented on SOLR-1299: - Shalin, Are you picking this one up, or should we try to dig into it? Not an area I'm familiar with but can start tracing through... > In distributed search cannot search on any schema field in ascending order > (descending is OK) > - > > Key: SOLR-1299 > URL: https://issues.apache.org/jira/browse/SOLR-1299 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.4 >Reporter: David Bowen > Fix For: 1.4 > > > Using the example with some of the exampledocs posted, the url: > http://localhost:8983/solr/select/?q=*:*&sort=timestamp+desc&fsv=true > works correctly, but change "desc" to "asc" and you get: > HTTP ERROR: 500 > null > java.lang.NullPointerException > at > org.apache.solr.handler.component.QueryComponent.getComparator(QueryComponent.java:284) > at > org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:229) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:195) > at > com.proquest.magnolia.solr.plugins.SummonSearchHandler.handleRequestBody(SummonSearchHandler.java:19) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1299) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) > at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) > at org.mortbay.jetty.Server.handle(Server.java:285) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378) > at > org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226) > at > org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Add replication push support?
On Thu, Jul 23, 2009 at 5:58 PM, Grant Ingersoll wrote: > If you bring into play the ZooKeeper work I started, then I think this > becomes easier. Masters can put out notifications on ZooKeeper that slaves > can subscribe to and everyone knows when everyone is up and happy. +1 w/o a central repository (like zk) this is going to be tricky > > -Grant > > > On Jul 23, 2009, at 1:18 AM, Noble Paul നോബിള് नोब्ळ् wrote: > >> There is an issue already created for realtime replication >> https://issues.apache.org/jira/browse/SOLR-982 >> >> In general push based replication is more error prone because the >> master has to be aware of the state of each slave . it is difficault >> because a slave may go down at any time and may come up later or new >> slaves get added randomly. In a pull based replication the master is >> agnostic of the slaves and a slave can easily know his current state >> and take appropriate action. >> >> We can take a middle path. The slaves can register with the master for >> notifications for availability of new snapshots. This can be as good >> as a push based replication without the complexities associated with >> it. >> I have raised as issue already >> https://issues.apache.org/jira/browse/SOLR-1305 >> >> On Thu, Jul 23, 2009 at 2:58 AM, Jason >> Rutherglen wrote: >>> >>> It would be useful to push snapshots as they are created from >>> the master to the slaves. I prefer this approach to constant >>> polling by slaves. Partially because the timing could be off on >>> the slave servers, the data is replicated, and the user sees >>> different snapshots? >>> >>> Something like a virtual 2 phase commit, where phase 1 is >>> replicate the new snapshots and load the searcher, phase two is >>> all slaves synchronously expose the new searcher. I'm also >>> wondering how we'll handle synchronous slaves with near realtime >>> search. >>> >> >> >> >> -- >> - >> Noble Paul | Principal Engineer| AOL | http://aol.com > > -- > Grant Ingersoll > http://www.lucidimagination.com/ > > Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using > Solr/Lucene: > http://www.lucidimagination.com/search > > -- - Noble Paul | Principal Engineer| AOL | http://aol.com
Re: Add replication push support?
If you bring into play the ZooKeeper work I started, then I think this becomes easier. Masters can put out notifications on ZooKeeper that slaves can subscribe to and everyone knows when everyone is up and happy. -Grant On Jul 23, 2009, at 1:18 AM, Noble Paul നോബിള് नोब्ळ् wrote: There is an issue already created for realtime replication https://issues.apache.org/jira/browse/SOLR-982 In general push based replication is more error prone because the master has to be aware of the state of each slave . it is difficault because a slave may go down at any time and may come up later or new slaves get added randomly. In a pull based replication the master is agnostic of the slaves and a slave can easily know his current state and take appropriate action. We can take a middle path. The slaves can register with the master for notifications for availability of new snapshots. This can be as good as a push based replication without the complexities associated with it. I have raised as issue already https://issues.apache.org/jira/browse/SOLR-1305 On Thu, Jul 23, 2009 at 2:58 AM, Jason Rutherglen wrote: It would be useful to push snapshots as they are created from the master to the slaves. I prefer this approach to constant polling by slaves. Partially because the timing could be off on the slave servers, the data is replicated, and the user sees different snapshots? Something like a virtual 2 phase commit, where phase 1 is replicate the new snapshots and load the searcher, phase two is all slaves synchronously expose the new searcher. I'm also wondering how we'll handle synchronous slaves with near realtime search. -- - Noble Paul | Principal Engineer| AOL | http://aol.com -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using Solr/Lucene: http://www.lucidimagination.com/search
Hudson build is back to normal: Solr-trunk #873
See http://hudson.zones.apache.org/hudson/job/Solr-trunk/873/
[jira] Updated: (SOLR-1299) In distributed search cannot search on any schema field in ascending order (descending is OK)
[ https://issues.apache.org/jira/browse/SOLR-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-1299: Summary: In distributed search cannot search on any schema field in ascending order (descending is OK) (was: In distributed search cannot search on a date field in ascending order (descending is OK)) This affects all schema fields (not just date) > In distributed search cannot search on any schema field in ascending order > (descending is OK) > - > > Key: SOLR-1299 > URL: https://issues.apache.org/jira/browse/SOLR-1299 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.4 >Reporter: David Bowen > Fix For: 1.4 > > > Using the example with some of the exampledocs posted, the url: > http://localhost:8983/solr/select/?q=*:*&sort=timestamp+desc&fsv=true > works correctly, but change "desc" to "asc" and you get: > HTTP ERROR: 500 > null > java.lang.NullPointerException > at > org.apache.solr.handler.component.QueryComponent.getComparator(QueryComponent.java:284) > at > org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:229) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:195) > at > com.proquest.magnolia.solr.plugins.SummonSearchHandler.handleRequestBody(SummonSearchHandler.java:19) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1299) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) > at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) > at org.mortbay.jetty.Server.handle(Server.java:285) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378) > at > org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226) > at > org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1299) In distributed search cannot search on a date field in ascending order (descending is OK)
[ https://issues.apache.org/jira/browse/SOLR-1299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-1299: Fix Version/s: 1.4 Confirming that it is a bug. I guess the problem is that after SOLR-, MissingStringLastComparatorSource extends FieldComparatorSource instead of SortComparatorSource, therefore SortField#getFactory returns null. This causes NPE when doing a custom sort in distributed search. > In distributed search cannot search on a date field in ascending order > (descending is OK) > - > > Key: SOLR-1299 > URL: https://issues.apache.org/jira/browse/SOLR-1299 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.4 >Reporter: David Bowen > Fix For: 1.4 > > > Using the example with some of the exampledocs posted, the url: > http://localhost:8983/solr/select/?q=*:*&sort=timestamp+desc&fsv=true > works correctly, but change "desc" to "asc" and you get: > HTTP ERROR: 500 > null > java.lang.NullPointerException > at > org.apache.solr.handler.component.QueryComponent.getComparator(QueryComponent.java:284) > at > org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:229) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:195) > at > com.proquest.magnolia.solr.plugins.SummonSearchHandler.handleRequestBody(SummonSearchHandler.java:19) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1299) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) > at > org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) > at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) > at org.mortbay.jetty.Server.handle(Server.java:285) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378) > at > org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226) > at > org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442) -- 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-1305) Notification based replication instead of polling
[ https://issues.apache.org/jira/browse/SOLR-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12734510#action_12734510 ] Noble Paul edited comment on SOLR-1305 at 7/23/09 1:09 AM: --- bq.With a little help from Zookeeper, is that the plan? not yet. Please help with details on how we can incorporate zookeeper into this. I guess it should be a pluggable was (Author: noble.paul): bq.With a little help from Zookeeper, is that the plan? not yet. Please help me with details on how we can incorporate zookeeper into this. I guess it should be a pluggable > Notification based replication instead of polling > - > > Key: SOLR-1305 > URL: https://issues.apache.org/jira/browse/SOLR-1305 > Project: Solr > Issue Type: New Feature > Components: replication (java) >Reporter: Noble Paul > Fix For: 1.5 > > > Currently the only way for the slave to know about the availability of of new > commit points is by polling. This means slaves should 'poll' very frequently > to ensure that it gets the commit point immediately. if the changes to the > master is less frequent, then this can be an unnecessary overhead. If would > be nice if the slave can register itself with the master for notification on > availability of new changes. After receiving the notification , the slave can > trigger a poll and do what it does now. This may require SOLR-727 so that > the slave can register its url with the master -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1305) Notification based replication instead of polling
[ https://issues.apache.org/jira/browse/SOLR-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12734510#action_12734510 ] Noble Paul commented on SOLR-1305: -- bq.With a little help from Zookeeper, is that the plan? not yet. Please help me with details on how we can incorporate zookeeper into this. I guess it should be a pluggable > Notification based replication instead of polling > - > > Key: SOLR-1305 > URL: https://issues.apache.org/jira/browse/SOLR-1305 > Project: Solr > Issue Type: New Feature > Components: replication (java) >Reporter: Noble Paul > Fix For: 1.5 > > > Currently the only way for the slave to know about the availability of of new > commit points is by polling. This means slaves should 'poll' very frequently > to ensure that it gets the commit point immediately. if the changes to the > master is less frequent, then this can be an unnecessary overhead. If would > be nice if the slave can register itself with the master for notification on > availability of new changes. After receiving the notification , the slave can > trigger a poll and do what it does now. This may require SOLR-727 so that > the slave can register its url with the master -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1305) Notification based replication instead of polling
[ https://issues.apache.org/jira/browse/SOLR-1305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12734498#action_12734498 ] Otis Gospodnetic commented on SOLR-1305: With a little help from Zookeeper, is that the plan? > Notification based replication instead of polling > - > > Key: SOLR-1305 > URL: https://issues.apache.org/jira/browse/SOLR-1305 > Project: Solr > Issue Type: New Feature > Components: replication (java) >Reporter: Noble Paul > Fix For: 1.5 > > > Currently the only way for the slave to know about the availability of of new > commit points is by polling. This means slaves should 'poll' very frequently > to ensure that it gets the commit point immediately. if the changes to the > master is less frequent, then this can be an unnecessary overhead. If would > be nice if the slave can register itself with the master for notification on > availability of new changes. After receiving the notification , the slave can > trigger a poll and do what it does now. This may require SOLR-727 so that > the slave can register its url with the master -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
