Re: CachedSqlEntityProcessor's purpose
Hi Noble Paul, thanks for your quick response. Noble Paul നോബിള് नोब्ळ् wrote: > > What i expect to happen is when you run the query > SELECT manufacturer,id FROM product_data WHERE type='manu' > > you must get all the rows from the DB in the table product_data > Unfortunately, that's not the case. Taken from a real project, verbose mode: (names replaced) # run 1 - no cache processor Config: Result: SELECT data FROM data2productid WHERE productid='6' AND isdeleted=0 0:0:0.25 --- row #1- SM224950 - --- row #2- 04138D01 - # run 2 - cache processor Config: Result: SELECT data,productid FROM data2productid WHERE isdeleted=0 0:0:0.249 It seems like the processor is unable to associate the cached rows with the matching documents and therefore won't add any cached entity data to my documents. Or did I make any mistakes? :( > So it is likely that you get an OOM if the DB table has a lot of rows. > Yes, that at least indicates, that the rows are loaded into memory. So far it seems to work for me. > processor="CachedSQLEntityProcessor" is wrong > processor="CachedSqlEntityProcessor" is right > Uh, little typo. My bad. > counter intuitive? which part is counter-intuitive ? the where part? > > The cache store the entire data with id value as the key > Yes, I wouldn't call the cache PK-attribute "where", as there can be another "WHERE" inside the query, too, and because it isn't actually an SQL-WHERE that's executed with that attribute value, right? Maybe "cacheid" or "cachekey" would be clearer? And an additional check for whether the chosen cachekey is in the result-set could minimize problems, because right now omitting the primary key column inside the query doesn't yield any errors. -- View this message in context: http://www.nabble.com/CachedSqlEntityProcessor%27s-purpose-tp20676874p20699494.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: CachedSqlEntityProcessor's purpose
I've been discussing this topic with Amit and also have some questions...
Noble Paul നോബിള് नोब्ळ् wrote:
>
> On Tue, Nov 25, 2008 at 11:35 PM, Amit Nithian <[EMAIL PROTECTED]> wrote:
>> 2) In the example, there were two use cases, one that is like
>> query="select
>> * from Y where xid=${X.ID}" and another where it's query="select * from
>> Y"
>> where="xid=${x.ID}. Is there any difference in how
>> CachedSQLEntityPRocessor
>> behaves? Does it know to strip off the WHERE clause and simply cache the
>> "select * from Y"?
> It fetches all the rows using the 'query' first.
>
> he where="xid=x.id" (see no ${} here )
> is evaluated in the map. In the map all the xid values will be kept as
> keys and the lookup is done on the map after evaluating the value of
> 'x.id' as ${x.ID}
>
If I'm not mistaken, this behaviour would require that the query I use
returns the column I want to match on, too. Without the
CachedSQLEntityProcessor, my entity for fetching multi-valued manufacturers
could look like this: ("product" is the parent entity)
Now if I wanted to use the cache, what would the query look like...? I tried
this:
That seems to be a pretty counter-intuitive change, which isn't explained at
all in the Wiki. =| Also, it didn't work for me, the query that is executed
returns zero rows, when I debug it with the dataimport.jsp-tool. The cache
seems to get filled though, as I encountered some JVM out-of-memory errors
when trying to cache huge tables... ;)
--
View this message in context:
http://www.nabble.com/CachedSqlEntityProcessor%27s-purpose-tp20676874p20698724.html
Sent from the Solr - User mailing list archive at Nabble.com.
PHPResponseWriter problem with (de)serialization (spellchecker)
Hi everyone,
maybe it's just me, but whenever I try to deserialize a Solr response that
contains the spellchecker with spellcheck.extendedResults, it fails. I'm
using PHP5 and everthing is pretty much up-to-date.
true
will be converted to
[...]
s:10:"spellcheck";a:1:{s:11:"suggestions";a:1:{s:16:"correctlySpelled";true}}}
which is not deserializeable with unserialize():
Notice: unserialize() [function.unserialize]: Error at offset 305 of 312
bytes in /Solr/Client.php on line 131
PHP, on the other hand, serializes an array this way:
echo
serialize(array("spellcheck"=>array("suggestions"=>array("correctlySpelled"=>true;
to
a:1:{s:10:"spellcheck";a:1:{s:11:"suggestions";a:1:{s:16:"correctlySpelled";b:1;}}}
So there are obviously differences in the way boolean vars are converted,
though I'm not sure if it's a problem with the PHPResponseWriter or with my
setup. Can anyone confirm this behaviour?
--
View this message in context:
http://www.nabble.com/PHPResponseWriter-problem-with-%28de%29serialization-%28spellchecker%29-tp20703677p20703677.html
Sent from the Solr - User mailing list archive at Nabble.com.
Re: CachedSqlEntityProcessor's purpose
Noble Paul നോബിള് नोब्ळ् wrote: > > I suspect only one thing > are the data types same for productid and product.id > in the db? > Good point. I just checked and they are both int(11). Could the problem be caused by the different column names, id in the products table and productid in the data-table? >> Yes, I wouldn't call the cache PK-attribute "where", as there can be >> another >> "WHERE" inside the query, too, and because it isn't actually an SQL-WHERE >> that's executed with that attribute value, right? Maybe "cacheid" or >> "cachekey" would be clearer? And an additional check for whether the >> chosen >> cachekey is in the result-set could minimize problems, because right now >> omitting the primary key column inside the query doesn't yield any >> errors. > true. that check would be helpful > > as to the configuration, any changes can break back compat > Then why not support both? "where" and "cachekey"? =) Thanks for your help! Steffen -- View this message in context: http://www.nabble.com/CachedSqlEntityProcessor%27s-purpose-tp20676874p20703855.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: PHPResponseWriter problem with (de)serialization (spellchecker)
No, this issue is new. But there was a general PHPResponseWriter task...
I opened a new one: https://issues.apache.org/jira/browse/SOLR-892
Feel free to move / edit / merge it. ;) I hope I made the problem clear.
~ Steffen
Yonik Seeley wrote:
>
> On Tue, Dec 2, 2008 at 6:39 AM, Steffen B. <[EMAIL PROTECTED]>
> wrote:
>> Little update: this behaviour can be easily reproduced with the example
>> configuration that comes with Solr:
>> After uncommenting line 733 in
>> apache-solr-nightly/example/solr/conf/solrconfig.xml (which activates the
>> PHPS queryResponseWriter) loading this URL on the example index shows the
>> same problem:
>> http://localhost:8983/solr/spellCheckCompRH?cmd=&q=ipod&spellcheck=true&spellcheck.extendedResults=true&spellcheck.onlyMorePopular=true&wt=phps
>>
>> [...]s:10:"spellcheck";a:1:{s:11:"suggestions";a:1:{s:16:"correctlySpelled";true}}}
>>
>> As I'm no Java crack and have neither time nor knowledge to debug the
>> class
>> myself, I can only offer to (re)open a task in Jira. Any opinions on
>> this?
>
> Hi Steffen, was there previosly JIRA issue already open specifically
> for this issue? If not, please do open a new issue.
>
> -Yonik
>
>
--
View this message in context:
http://www.nabble.com/PHPResponseWriter-problem-with-%28de%29serialization-%28spellchecker%29-tp20703677p20792680.html
Sent from the Solr - User mailing list archive at Nabble.com.
Re: PHPResponseWriter problem with (de)serialization (spellchecker)
Little update: this behaviour can be easily reproduced with the example
configuration that comes with Solr:
After uncommenting line 733 in
apache-solr-nightly/example/solr/conf/solrconfig.xml (which activates the
PHPS queryResponseWriter) loading this URL on the example index shows the
same problem:
http://localhost:8983/solr/spellCheckCompRH?cmd=&q=ipod&spellcheck=true&spellcheck.extendedResults=true&spellcheck.onlyMorePopular=true&wt=phps
[...]s:10:"spellcheck";a:1:{s:11:"suggestions";a:1:{s:16:"correctlySpelled";true}}}
As I'm no Java crack and have neither time nor knowledge to debug the class
myself, I can only offer to (re)open a task in Jira. Any opinions on this?
~ Steffen
Steffen B. wrote:
>
> Hi everyone,
> maybe it's just me, but whenever I try to deserialize a Solr response that
> contains the spellchecker with spellcheck.extendedResults, it fails. I'm
> using PHP5 and everthing is pretty much up-to-date.
>
>
> true
>
>
> will be converted to
> [...]
> s:10:"spellcheck";a:1:{s:11:"suggestions";a:1:{s:16:"correctlySpelled";true}}}
> which is not deserializeable with unserialize():
> Notice: unserialize() [function.unserialize]: Error at offset 305 of 312
> bytes in /Solr/Client.php on line 131
>
> PHP, on the other hand, serializes an array this way:
> echo
> serialize(array("spellcheck"=>array("suggestions"=>array("correctlySpelled"=>true;
> to
> a:1:{s:10:"spellcheck";a:1:{s:11:"suggestions";a:1:{s:16:"correctlySpelled";b:1;}}}
>
> So there are obviously differences in the way boolean vars are converted,
> though I'm not sure if it's a problem with the PHPResponseWriter or with
> my setup. Can anyone confirm this behaviour?
>
>
--
View this message in context:
http://www.nabble.com/PHPResponseWriter-problem-with-%28de%29serialization-%28spellchecker%29-tp20703677p20790504.html
Sent from the Solr - User mailing list archive at Nabble.com.
Re: Nwebie Question on boosting
Hi, ayyanar wrote: > > Thanks Rob. Can you plz provide some sample documents (lucene) for title > bassed boosting? > I'm not sure about the Lucene part (this is the Solr mailing list after all), but if you want index time boosting of certain fields, you have to add documents like this: 123 My boosted field Here goes the text, yadda yadda In this document the title-field will be boosted with a factor of 2, if it has norms enabled. (omitNorms = false) You can read more about this here: http://wiki.apache.org/solr/UpdateXmlMessages#head-63c170cad521de8d1e9be0d76025774cf3b66dfc -- View this message in context: http://www.nabble.com/Nwebie-Question-on-boosting-tp20950286p20953736.html Sent from the Solr - User mailing list archive at Nabble.com.
Highlighting broken? String index out of range: 35
Hi everyone, it seems that I've run into another problem with my Solr setup. :/ The highlighter just won't highlight anything, no matter which fragmenter or config params I use. Here's an example, taken straight out of the example solrconfig.xml: dismax explicit 0.01 text^0.5 features^1.0 name^1.2 sku^1.5 id^10.0 manu^1.1 cat^1.4 text^0.2 features^1.1 name^1.5 manu^1.4 manu_exact^1.9 ord(popularity)^0.5 recip(rord(price),1,1000,1000)^0.3 id,name,price,score 2<-1 5<-2 6<90% 100 *:* text features name 0 name regex Whenever I try to activate the highlighter, it produces an error: http://localhost:8983/solr/select/?q=ipod&version=2.2&start=0&rows=10&indent=on&qt=dismax&hl=true HTTP ERROR: 500 String index out of range: 35 java.lang.StringIndexOutOfBoundsException: String index out of range: 35 at java.lang.String.substring(Unknown Source) at org.apache.lucene.search.highlight.Highlighter.getBestTextFragments(Highlighter.java:239) at org.apache.solr.highlight.DefaultSolrHighlighter.doHighlighting(DefaultSolrHighlighter.java:310) at org.apache.solr.handler.component.HighlightComponent.process(HighlightComponent.java:83) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:171) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1313) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:303) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:232) 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) That's what happens with the example setup - on my project it simply won't highlight anything at all, no matter what I try. :| Can anyone shed some light on this? -- View this message in context: http://www.nabble.com/Highlighting-broken--String-index-out-of-range%3A-35-tp21073102p21073102.html Sent from the Solr - User mailing list archive at Nabble.com.
Re: Highlighting broken? String index out of range: 35
Alright, I pinned it down, I think...
The cause of the error seems to be the "features" field, which has
termVectors="true", termPositions="true" and termOffsets="true". The other 2
fields ("name" and "text") work, they have the same type but lack the
term*-attributes. When you overwrite the default hl.fl with something like
"name text" it works, but add "features" to it and you get the error.
Steffen B. wrote:
>
> Hi everyone,
> it seems that I've run into another problem with my Solr setup. :/ The
> highlighter just won't highlight anything, no matter which fragmenter or
> config params I use.
> Here's an example, taken straight out of the example solrconfig.xml:
>
>
> dismax
> explicit
> 0.01
>
> text^0.5 features^1.0 name^1.2 sku^1.5 id^10.0 manu^1.1 cat^1.4
>
>
> text^0.2 features^1.1 name^1.5 manu^1.4 manu_exact^1.9
>
>
> ord(popularity)^0.5 recip(rord(price),1,1000,1000)^0.3
>
>
> id,name,price,score
>
>
> 2<-1 5<-2 6<90%
>
> 100
> *:*
>
> text features name
>
> 0
>
> name
> regex
>
>
>
> Whenever I try to activate the highlighter, it produces an error:
> http://localhost:8983/solr/select/?q=ipod&version=2.2&start=0&rows=10&indent=on&qt=dismax&hl=true
>
> HTTP ERROR: 500
>
> String index out of range: 35
>
> java.lang.StringIndexOutOfBoundsException: String index out of range: 35
> at java.lang.String.substring(Unknown Source)
> at
> org.apache.lucene.search.highlight.Highlighter.getBestTextFragments(Highlighter.java:239)
> at
> org.apache.solr.highlight.DefaultSolrHighlighter.doHighlighting(DefaultSolrHighlighter.java:310)
> at
> org.apache.solr.handler.component.HighlightComponent.process(HighlightComponent.java:83)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:171)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1313)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:303)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:232)
> 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)
>
> That's what happens with the example setup - on my project it simply won't
> highlight anything at all, no matter what I try. :| Can anyone shed some
> light on this?
>
--
View this message in context:
http://www.nabble.com/Highlighting-broken--String-index-out-of-range%3A-35-tp21073102p21073356.html
Sent from the Solr - User mailing list archive at Nabble.com.
DIH full-import with clean=true fails and rollback empties index
Hi there, I've got a pretty simple question regarding the DIH full-import command. I have a SOLR server running that has a full index with lots of documents in it. Once a day, a full-import is run, which uses the default parameters (clean=true, because it's not an incremental index). When I run a full-import, the first step is cleaning up the whole index: Feb 7, 2009 2:12:01 AM org.apache.solr.update.DirectUpdateHandler2 deleteAll INFO: [] REMOVING ALL DOCUMENTS FROM INDEX After that, suppose the import suddenly fails for one reason or another (ie. SQL error), which initiates a rollback: Feb 7, 2009 2:12:02 AM org.apache.solr.handler.dataimport.DataImporter doFullImport SEVERE: Full Import failed [...] Feb 7, 2009 2:12:02 AM org.apache.solr.update.DirectUpdateHandler2 rollback INFO: start rollback Feb 7, 2009 2:12:02 AM org.apache.solr.update.DirectUpdateHandler2 rollback INFO: end_rollback Feb 7, 2009 2:12:02 AM org.apache.solr.update.DirectUpdateHandler2 commit INFO: start commit(optimize=false,waitFlush=false,waitSearcher=true) Unfortunately, this rollback does not "refill" the index with the old data, and neither keeps the old index from being overwritten with the new, erroneous index. Now my question is: is there anything I can do to keep Solr from trashing my index on a full-import when there is a problem with the database? Or should I use clean=false, even though 99% of the imported documents are not incremental but the same documents that already were in the index, only with new data? Any tips will be greatly appreciated! :) - Steffen -- View this message in context: http://www.nabble.com/DIH-full-import-with-clean%3Dtrue-fails-and-rollback-empties-index-tp22055065p22055065.html Sent from the Solr - User mailing list archive at Nabble.com.
NPE in dataimport.DebugLogger.peekStack (DIH Development Console)
Hi,
I'm trying to debug my DI config on my Solr server and it constantly fails
with a NullPointerException:
Jun 2, 2009 4:20:46 PM org.apache.solr.handler.dataimport.DataImportHandler
processConfiguration
INFO: Processing configuration from solrconfig.xml: {config=dataconfig.xml}
Jun 2, 2009 4:20:46 PM org.apache.solr.handler.dataimport.DataImporter
loadDataConfig
INFO: Data Configuration loaded successfully
Jun 2, 2009 4:20:46 PM org.apache.solr.handler.dataimport.DataImporter
verifyWithSchema
INFO: id is a required field in SolrSchema . But not found in DataConfig
Jun 2, 2009 4:20:46 PM org.apache.solr.handler.dataimport.SolrWriter
readIndexerProperties
INFO: Read dataimport.properties
Jun 2, 2009 4:20:46 PM org.apache.solr.handler.dataimport.DataImporter
doFullImport
INFO: Starting Full Import
Jun 2, 2009 4:20:46 PM org.apache.solr.handler.dataimport.SolrWriter
readIndexerProperties
INFO: Read dataimport.properties
Jun 2, 2009 4:20:46 PM org.apache.solr.handler.dataimport.DataImporter
doFullImport
SEVERE: Full Import failed
java.lang.NullPointerException
at
org.apache.solr.handler.dataimport.DebugLogger.peekStack(DebugLogger.java:78)
at
org.apache.solr.handler.dataimport.DebugLogger.log(DebugLogger.java:98)
at
org.apache.solr.handler.dataimport.SolrWriter.log(SolrWriter.java:248)
at
org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:304)
at
org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:224)
at
org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:167)
at
org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:316)
at
org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:376)
at
org.apache.solr.handler.dataimport.DataImportHandler.handleRequestBody(DataImportHandler.java:187)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1328)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:341)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:244)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
at
org.apache.catalina.valves.RequestFilterValve.process(RequestFilterValve.java:276)
at
org.apache.catalina.valves.RemoteHostValve.invoke(RemoteHostValve.java:81)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
at
org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:834)
at
org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:640)
at
org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1286)
at java.lang.Thread.run(Thread.java:619)
Running a normal full-import works just fine, but whenever I try to run the
debugger, it gives me this error. I'm using the most recent Solr nightly
build (2009-06-01) and the method in question is:
private DebugInfo peekStack() {
return debugStack.isEmpty() ? null : debugStack.peek();
}
I'm using a DI config that has been working fine in for several previous
builds, so that shouldn't be the problem... any ideas what the problem could
be?
Thanks in advance,
Steffen
--
View this message in context:
http://www.nabble.com/NPE-in-dataimport.DebugLogger.peekStack-%28DIH-Development-Console%29-tp23833878p23833878.html
Sent from the Solr - User mailing list archive at Nabble.com.
Re: NPE in dataimport.DebugLogger.peekStack (DIH Development Console)
Glad to hear that it's not a problem with my setup.
Thanks for taking care of it! :)
Shalin Shekhar Mangar wrote:
>
> On Tue, Jun 2, 2009 at 8:06 PM, Steffen B.
> wrote:
>
>>
>> I'm trying to debug my DI config on my Solr server and it constantly
>> fails
>> with a NullPointerException:
>> Jun 2, 2009 4:20:46 PM org.apache.solr.handler.dataimport.DataImporter
>> doFullImport
>> SEVERE: Full Import failed
>> java.lang.NullPointerException
>>at
>>
>> org.apache.solr.handler.dataimport.DebugLogger.peekStack(DebugLogger.java:78)
>>at
>> org.apache.solr.handler.dataimport.DebugLogger.log(DebugLogger.java:98)
>>at
>> org.apache.solr.handler.dataimport.SolrWriter.log(SolrWriter.java:248)
>>at...
>>
>> Running a normal full-import works just fine, but whenever I try to run
>> the
>> debugger, it gives me this error. I'm using the most recent Solr nightly
>> build (2009-06-01) and the method in question is:
>> private DebugInfo peekStack() {
>>return debugStack.isEmpty() ? null : debugStack.peek();
>> }
>> I'm using a DI config that has been working fine in for several previous
>> builds, so that shouldn't be the problem... any ideas what the problem
>> could
>> be?
>
>
>
> A previous commit to change the EntityProcessor API broke this
> functionality. I'll open an issue and give a patch.
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
>
--
View this message in context:
http://www.nabble.com/NPE-in-dataimport.DebugLogger.peekStack-%28DIH-Development-Console%29-tp23833878p23835897.html
Sent from the Solr - User mailing list archive at Nabble.com.
