Re: Strange error when I try to copy....

[Bruno Mannina]

Le 09/09/2016 à 17:57, Shawn Heisey a écrit :

On 9/8/2016 9:41 AM, Bruno Mannina wrote:

- I stop SOLR 5.4 on Ubuntu 14.04LTS - 16Go - i3-2120 CPU @ 3.30Ghz

- I do a simple directory copy /data to my HDD backup (from 2To SATA
to 2To SATA directly connected to the Mothercard).

All files are copied fine but one not ! the biggest (~65Go) failed.

I have the message : "Error splicing file: Input/output error"

This isn't a Solr issue, which is easy to determine by the fact that
you've stopped Solr and it's not even running.  It's a problem with the
filesystem, probably the destination filesystem.

The most common reason that I have found for this error is a destination
filesystem that is incapable of holding a large file -- which can happen
when the disk is formatted fat32 instead of ntfs or a Linux filesystem.
You can have a 2TB filesystem with fat32, but no files larger than 4GB
-- so your 65GB file won't fit.

I think you're going to need to reformat that external drive with
another filesystem.  If you choose NTFS, you'll be able to use the disk
on either Linux or Windows.

Thanks,
Shawn



Hi Shawn,

First thanks for your answer, effectively it's a little bit clear.
Tonight I will check the file system of my hdd.

And sorry for this question out of solr subject.

Cdlt,
Bruno



---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

Re: Strange error when I try to copy....

[Shawn Heisey]

On 9/8/2016 9:41 AM, Bruno Mannina wrote:
> - I stop SOLR 5.4 on Ubuntu 14.04LTS - 16Go - i3-2120 CPU @ 3.30Ghz
>
> - I do a simple directory copy /data to my HDD backup (from 2To SATA
> to 2To SATA directly connected to the Mothercard).
>
> All files are copied fine but one not ! the biggest (~65Go) failed.
>
> I have the message : "Error splicing file: Input/output error"

This isn't a Solr issue, which is easy to determine by the fact that
you've stopped Solr and it's not even running.  It's a problem with the
filesystem, probably the destination filesystem.

The most common reason that I have found for this error is a destination
filesystem that is incapable of holding a large file -- which can happen
when the disk is formatted fat32 instead of ntfs or a Linux filesystem. 
You can have a 2TB filesystem with fat32, but no files larger than 4GB
-- so your 65GB file won't fit.

I think you're going to need to reformat that external drive with
another filesystem.  If you choose NTFS, you'll be able to use the disk
on either Linux or Windows.

Thanks,
Shawn

Strange error when I try to copy....

[Bruno Mannina]

Dear Solr Users,

I use since several years SOLR and since two weeks, I have a problem
when I try to copy my solr index.

My solr index is around 180Go (~100 000 000 docs, 1 doc ~ 3ko)

My method to save my index every Sunday:

- I stop SOLR 5.4 on Ubuntu 14.04LTS - 16Go - i3-2120 CPU @ 3.30Ghz

- I do a simple directory copy /data to my HDD backup (from 2To SATA to
2To SATA directly connected to the Mothercard).

All files are copied fine but one not ! the biggest (~65Go) failed.

I have the message : "Error splicing file: Input/output error"

I tried also on windows (I have a dualboot), I have "redondance error".

I check my HDD, no error, I check the file "_k46.fdt" no error, I can
delete docs, add docs, my database can be reach and works fine.

Is someone have an idea to backup my database ? or why I have this error ?

Many thanks for your help,

Sincerely,

Bruno





---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel 
antivirus Avast.
https://www.avast.com/antivirus

strange error on closing server

[Ziqi Zhang]

Hi all

I am having a strange error whenever I close my index (calling server.close()
The error is shown below. I am not sure where I should look - the configuration 
file? The code? Or index fragments? Or else? The code causing the error is very 
simple, just the “close()” method.

Many thanks!


CachingDirectoryFactory:184 - Timeout waiting for all directory ref counts to 
be released - gave up waiting on CachedDir<>
2016-02-21 11:09:33 ERROR CachingDirectoryFactory:150 - Error closing 
directory:org.apache.solr.common.SolrException: Timeout waiting for all 
directory ref counts to be released - gave up waiting on 
CachedDir<>
at 
org.apache.solr.core.CachingDirectoryFactory.close(CachingDirectoryFactory.java:187)
at org.apache.solr.core.SolrCore.close(SolrCore.java:1257)
at org.apache.solr.core.SolrCores.close(SolrCores.java:124)
at org.apache.solr.core.CoreContainer.shutdown(CoreContainer.java:562)
at 
org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.shutdown(EmbeddedSolrServer.java:263)
at 
org.apache.solr.client.solrj.embedded.EmbeddedSolrServer.close(EmbeddedSolrServer.java:268)
at uk.ac.shef.dcs.jate.app.App.extract(App.java:276)
at uk.ac.shef.dcs.jate.app.AppTermEx.main(AppTermEx.java:35)


Line 276 of App class is:

solrServer.close();

Strange error message in Solr 5.2.1 log

[Shawn Heisey]

Below is a very large error message and associated stacktrace that I can
see in the Solr log on a Linux system running version 5.2.1 with Oracle
JDK 8u60.  This message appeared a bunch of times over the weekend, but
does not appear to be happening now.

This looks like a low level Lucene error, the sort of thing that
shouldn't ever happen.  I have a manually started monitoring process
that retrieves certain Solr APIs that include the size of the index, and
this appears to match up with the stacktrace.

It looks like Upayavira noticed the same thing a couple of months ago --
SOLR-7785.

Should I be worried by this?  It appears to only have happened on two of
my build cores, not the live cores.  This is a dev server that is not
being used for queries right now, but I did have plans to migrate at
least one of the production indexes to 5.2.1 with the same config that's
on this system.

ERROR - 2015-09-08 16:09:39.981; [   s3build]
org.apache.solr.common.SolrException; java.lang.IllegalStateException:
file: MMapDirectory@/index/solr5/data/data/spark3_1/index
lockFactory=org.apache.lucene.store.NativeFSLockFactory@71ee2ee7 appears
both in delegate and in cache: cache=[_jb.fnm,​ _jc.tvd,​ _j9.tvd,​
_j9.fdx,​ _ja.fnm,​ _jc.tvx,​ _j9.fdt,​ _j9.tvx],​
delegate=[_ib_Lucene50_0.pos,​ _gq_Lucene50_0.pos,​ _gu_Lucene50_0.tim,​
_ig_Lucene50_0.tim,​ _im.si,​ _ft.si,​ _hq.nvd,​ _j9_Lucene50_0.dvm,​
_hw_Lucene50_0.dvd,​ _hp.cfs,​ _e1.tvx,​ _e0.tvd,​ _j2_Lucene50_0.doc,​
_je_Lucene50_0.tim,​ _i5.nvm,​ _en_Lucene50_0.tim,​ _j3_Lucene50_0.dvd,​
_dg.fdt,​ _it_Lucene50_0.doc,​ _ir_Lucene50_0.dvm,​ _ik.tvd,​
_ja_Lucene50_0.doc,​ _hs_Lucene50_0.tim,​ _j4_Lucene50_0.tim,​
_iu_Lucene50_0.pos,​ _iq_Lucene50_0.doc,​ _i0_Lucene50_0.tim,​ _j2.fnm,​
_fs_Lucene50_0.tip,​ _ia_Lucene50_0.pos,​ _eu_Lucene50_0.dvm,​ _cr.tvx,​
_is.nvd,​ _ey_Lucene50_0.pos,​ _jd.tvd,​ _i6_Lucene50_0.dvm,​
_im_Lucene50_0.tip,​ _hx.nvm,​ _it.nvd,​ _i7.fdx,​ _iw.fnm,​ _ia.fdx,​
_ix.fnm,​ _e1_Lucene50_0.pos,​ _ey.nvd,​ _j5.fdt,​ _iy_Lucene50_0.tim,​
_hj_Lucene50_0.doc,​ _i9.nvm,​ _g2.si,​ _hu.tvd,​ _cr.tvd,​ _i1.nvd,​
_iz_Lucene50_0.doc,​ _eu_Lucene50_0.pos,​ _fd_Lucene50_0.dvm,​
_ih_Lucene50_0.dvm,​ _in.fdx,​ _ig_Lucene50_0.dvd,​ _hq.tvx,​ _eu.nvd,​
_j4.fdx,​ _i4.nvm,​ _ir.tvd,​ _fk.tvx,​ _hr_Lucene50_0.tip,​ _jb.nvm,​
_ft.nvd,​ _ix.fdx,​ _j1_Lucene50_0.dvd,​ _g8_Lucene50_0.dvm,​
_g7_Lucene50_0.tim,​ _hz.nvm,​ _iz.nvd,​ _hy_Lucene50_0.dvm,​ _iy.tvx,​
_ha_Lucene50_0.tip,​ _fl.tvx,​ _j2.nvm,​ _i1_Lucene50_0.dvd,​
_h1_Lucene50_0.doc,​ _fv_Lucene50_0.pos,​ _dl_Lucene50_0.dvm,​
_hv_Lucene50_0.tim,​ _in_Lucene50_0.pos,​ _ie_Lucene50_0.tim,​ _ha.nvm,​
_dg_Lucene50_0.dvm,​ _ir.fnm,​ _e6.tvd,​ _hs.tvd,​ _hu_Lucene50_0.tip,​
_it_Lucene50_0.pos,​ _g7.fdt,​ _fk_Lucene50_0.doc,​ _j8.fnm,​
_im_Lucene50_0.tim,​ _in_Lucene50_0.tim,​ _en_Lucene50_0.tip,​
_it_Lucene50_0.dvm,​ _ib.tvx,​ _e0_Lucene50_0.tip,​ _fl.nvm,​
_iy_Lucene50_0.tip,​ _e0.tvx,​ _fd.fnm,​ _fs.fnm,​ _ia.nvm,​ _gm.tvx,​
_i5.tvd,​ _j2.nvd,​ _fe.fdt,​ _ik.si,​ _du_Lucene50_0.tip,​
_hy_Lucene50_0.tim,​ _cr.fnm,​ _h1.si,​ _hq.tvd,​ _jb.tvd,​ _du.tvd,​
_im.tvx,​ _iz_Lucene50_0.pos,​ _gm_Lucene50_0.pos,​ _hq.fdx,​
_i4_Lucene50_0.tip,​ _j7.nvd,​ _eb.fdt,​ _hq_Lucene50_0.dvm,​
_gc_Lucene50_0.dvd,​ _i0.tvd,​ _f5.nvm,​ _fk.nvm,​ _i2.nvm,​
_i0_Lucene50_0.dvd,​ _iz.tvx,​ _it.fdx,​ _if.fdt,​ _ex.tvd,​ _eb.tvd,​
_et.si,​ _gd.fdx,​ _eh_Lucene50_0.doc,​ _eh.nvd,​ _gd.si,​ _eh.nvm,​
_ij.tvx,​ _i5.tvx,​ _fb_Lucene50_0.doc,​ _jc.nvd,​ _ha.tvx,​ _eb.fnm,​
_gq_Lucene50_0.tip,​ _hy_Lucene50_0.tip,​ _j3.tvx,​ _j9_Lucene50_0.tip,​
_hu.fnm,​ _ho.nvm,​ _eu_Lucene50_0.tim,​ _i8.tvx,​ _jc.fdx,​ _gd.tvd,​
_hq.fnm,​ _fe_Lucene50_0.dvd,​ _g1.nvm,​ _iu.si,​ _iw.tvd,​
_dg_Lucene50_0.dvd,​ _jb_Lucene50_0.pos,​ _j7.fdt,​ _iy.si,​ _j5.nvd,​
_hw.tvx,​ _jb_Lucene50_0.dvd,​ _ik.fdx,​ _ey.nvm,​ _fd.tvx,​ _i4.fnm,​
_dg.nvm,​ _ia.fnm,​ _ix.nvd,​ _ie.nvd,​ _g7.fnm,​ _dg_Lucene50_0.pos,​
_fe.tvd,​ _fs.tvd,​ _j2.si,​ _ie_Lucene50_0.dvm,​ _i4_Lucene50_0.dvd,​
_je_Lucene50_0.doc,​ _iu_Lucene50_0.dvd,​ _e1_Lucene50_0.tip,​ _ja.nvd,​
_jd.fdt,​ _eb.tvx,​ _fb.nvd,​ _j2_Lucene50_0.pos,​ _in_Lucene50_0.tip,​
_gu_Lucene50_0.dvd,​ _ii_Lucene50_0.pos,​ _hw_Lucene50_0.doc,​ _ja.nvm,​
_i6_Lucene50_0.pos,​ _g8.si,​ _i0.fdx,​ _i6.tvx,​ _j1.fdt,​
_is_Lucene50_0.dvd,​ _ho_Lucene50_0.dvm,​ _iu.tvx,​ _eh.si,​
_if_Lucene50_0.dvd,​ _fv.tvx,​ _fv.tvd,​ _jc.tvd,​ _f5.fdt,​ _e1.fdx,​
_i9.fdt,​ _gq.fdx,​ _is.fnm,​ _ij_Lucene50_0.doc,​ _i5_Lucene50_0.doc,​
_ii_Lucene50_0.tip,​ _g2_Lucene50_0.dvm,​ _eu_Lucene50_0.dvd,​ _fl.tvd,​
_fv_Lucene50_0.dvd,​ _it.tvx,​ _f5_Lucene50_0.doc,​ _jf.fdt,​ _iu.fdt,​
_j7.tvx,​ _ey_Lucene50_0.doc,​ _fk.si,​ _ic.fdt,​ _j7_Lucene50_0.tip,​
_i5.fnm,​ _iy.nvm,​ _hw_Lucene50_0.pos,​ _ig_Lucene50_0.dvm,​
_j4_Lucene50_0.tip,​ _j6.nvm,​ _je.si,​ _j3.fnm,​ _im.fdx,​ _g7.nvm,​
_e0_Lucene50_0.dvd,​ _hq.nvm,​ _ha_Lucene50_0.dvd,​ _j9.nvm,​ _ih.nvm,​
_ic.fdx,​ _ik.fdt,​ _if.si,​ _iv_Lucene50_0.tim,​ _i0.nvm,​ _gd.nvm,​
_i2.nvd,​ _j6_Lucene50_0.pos,​ _ik.tvx,​ _eh.tvd

Strange Error Message while Full Import

[Peter Sch�tt]

Hallo,

when I do a full import of a SOLR index I become a strange error 
message:

org.apache.solr.handler.dataimport.DataImportHandlerException: 
java.sql.SQLRecoverableException: Closed Resultset: next

It is only a simple query 

select FIRMEN_ID, FIRMIERUNG, FIRMENKENNUNG,
 PZN, DEBITORNUMMER, ADRESS_ID from DAT_FIRMA

This error seems to be a subsequent error but there is no other cause in 
the stacktrace.

Thanks for any hints.

Ciao
  Peter Schütt

P.S. The error stacktrace


Feb 03, 2014 2:11:01 PM org.apache.solr.common.SolrException log
SEVERE: getNext() failed for query 'select FIRMEN_ID, FIRMIERUNG, 
FIRMENKENNUNG,
 PZN, DEBITORNUMMER, ADRESS_ID from 
DAT_FIRMA':org.apache.solr.handler.dataimport.DataImportHandlerException
: java.sql.SQLRecoverableException: Closed Resultset: next
at 
org.apache.solr.handler.dataimport.DataImportHandlerException.wrapAnd
Throw(DataImportHandlerException.java:63)
at 
org.apache.solr.handler.dataimport.PreparedStatementJdbcDataSource$Re
sultSetIterator.hasnext(PreparedStatementJdbcDataSource.java:404)
at 
org.apache.solr.handler.dataimport.PreparedStatementJdbcDataSource$Re
sultSetIterator.access$600(PreparedStatementJdbcDataSource.java:256)
at 
org.apache.solr.handler.dataimport.PreparedStatementJdbcDataSource$Re
sultSetIterator$1.hasNext(PreparedStatementJdbcDataSource.java:324)
at 
org.apache.solr.handler.dataimport.EntityProcessorBase.getNext(Entity
ProcessorBase.java:116)
at 
org.apache.solr.handler.dataimport.PreparedStatementSqlEntityProcesso
r.handleQuery(PreparedStatementSqlEntityProcessor.java:119)
at 
org.apache.solr.handler.dataimport.PreparedStatementSqlEntityProcesso
r.nextRow(PreparedStatementSqlEntityProcessor.java:124)
at 
org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(Ent
ityProcessorWrapper.java:243)
at org.apache.solr.handler.dataimport.DocBuilder.buildDocument
(DocBuilde
r.java:465)
at org.apache.solr.handler.dataimport.DocBuilder.buildDocument
(DocBuilde
r.java:404)
at org.apache.solr.handler.dataimport.DocBuilder.doFullDump
(DocBuilder.j
ava:319)
at org.apache.solr.handler.dataimport.DocBuilder.execute
(DocBuilder.java
:227)
at org.apache.solr.handler.dataimport.DataImporter.doFullImport
(DataImpo
rter.java:422)
at org.apache.solr.handler.dataimport.DataImporter.runCmd
(DataImporter.j
ava:487)
at org.apache.solr.handler.dataimport.DataImporter$1.run
(DataImporter.ja
va:468)
Caused by: java.sql.SQLRecoverableException: Closed Resultset: next
at oracle.jdbc.driver.OracleResultSetImpl.next
(OracleResultSetImpl.java:
214)
at org.apache.tomcat.dbcp.dbcp.DelegatingResultSet.next
(DelegatingResult
Set.java:207)
at org.apache.tomcat.dbcp.dbcp.DelegatingResultSet.next
(DelegatingResult
Set.java:207)
at 
org.apache.solr.handler.dataimport.PreparedStatementJdbcDataSource$Re
sultSetIterator.hasnext(PreparedStatementJdbcDataSource.java:396)
... 13 more

Re: Strange error in Solr 4.2

[skp]

I fixed it by setting JVM properties in glassfish.

-Djavax.net.ssl.keyStorePassword=changeit 



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Strange-error-in-Solr-4-2-tp4047386p4051159.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Strange error in Solr 4.2

[Mark Miller]

On Mar 14, 2013, at 1:27 PM, Shawn Heisey  wrote:

> I have been told that it is possible to override the handleError method to 
> fix this

I'd say mitigate more than fix. I think the real fix requires some dev work. 

- Mark

Re: Strange error in Solr 4.2

[Shawn Heisey]

On 3/14/2013 9:24 AM, Uwe Klosa wrote:

This exception occurs in this part

new ConcurrentUpdateSolrServer("http://solr.diva-portal.org:8080/search";,
5, 50)


Side comment, unrelated to your question:

If you're already aware that ConcurrentUpdateSolrServer has no built-in 
error handling and you're OK with that, then you don't need to be 
concerned with this message.


ConcurrentUpdateSolrServer swallows any exception that happens during 
its operation.  Errors get logged, but are not passed back to the 
calling application.  Update requests always succeed, even if Solr is 
completely down.


I have been told that it is possible to override the handleError method 
to fix this, but I don't know what code to actually use.


Thanks,
Shawn

Re: Strange error in Solr 4.2

[Stefan Matheis]

On Thursday, March 14, 2013 at 4:57 PM, Uwe Klosa wrote:

> I found the answer myself. Thanks for the pointer.


Would you mind sharing you answer, Uwe? 

Re: Strange error in Solr 4.2

[Uwe Klosa]

I found the answer myself. Thanks for the pointer.

Cheers
Uwe


On 14 March 2013 16:48, Uwe Klosa  wrote:

> Thanks, but nobody has tempered with keystores. I have tested the
> application on different machines. Always the same exception is thrown.
>
> Do we have to set some system property to fix this?
>
> /Uwe
>
>
>
>
> On 14 March 2013 16:36, Mark Miller  wrote:
>
>> Perhaps as a result of https://issues.apache.org/jira/browse/SOLR-4451 ?
>>
>> Just a guess.
>>
>> The root cause looks to be:
>>
>> > Caused by: java.io.IOException: Keystore was tampered with, or password
>> was
>> > incorrect
>>
>>
>> - Mark
>>
>> On Mar 14, 2013, at 11:24 AM, Uwe Klosa  wrote:
>>
>> > Hi
>> >
>> > We have been using Solr 4.0 for a while now and wanted to upgrade to
>> 4.2.
>> > But our application stopped working. When we tried 4.1 it was working as
>> > expected.
>> >
>> > Here is a  description of the situation.
>> >
>> > We deploy a Solr web application under java 7 on a Glassfish 3.1.2.2
>> > server. We added some classes to the standard Solr webapp which are
>> > listening to a jms service and update the index according to the message
>> > content, which can be fetch the document with this id from that URL and
>> add
>> > it to the index. The documents are fetched via SSL from a repository
>> server.
>> >
>> > This has been working well since Solr 1.2 for about 6 years now. With
>> Solr
>> > 4.2 we suddenly get the following error:
>> >
>> > javax.ejb.CreateException: Initialization failed for Singleton
>> > IndexMessageClientFactory
>> >at
>> >
>> com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:547)
>> > ...
>> > Caused by: org.apache.http.conn.ssl.SSLInitializationException: Failure
>> > initializing default system SSL context
>> >at
>> >
>> org.apache.http.conn.ssl.SSLSocketFactory.createSystemSSLContext(SSLSocketFactory.java:368)
>> >at
>> >
>> org.apache.http.conn.ssl.SSLSocketFactory.getSystemSocketFactory(SSLSocketFactory.java:204)
>> >at
>> >
>> org.apache.http.impl.conn.SchemeRegistryFactory.createSystemDefault(SchemeRegistryFactory.java:82)
>> >at
>> >
>> org.apache.http.impl.client.SystemDefaultHttpClient.createClientConnectionManager(SystemDefaultHttpClient.java:118)
>> >at
>> >
>> org.apache.http.impl.client.AbstractHttpClient.getConnectionManager(AbstractHttpClient.java:466)
>> >at
>> >
>> org.apache.solr.client.solrj.impl.HttpClientUtil.setMaxConnections(HttpClientUtil.java:179)
>> >at
>> >
>> org.apache.solr.client.solrj.impl.HttpClientConfigurer.configure(HttpClientConfigurer.java:33)
>> >at
>> >
>> org.apache.solr.client.solrj.impl.HttpClientUtil.configureClient(HttpClientUtil.java:115)
>> >at
>> >
>> org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:105)
>> >at
>> >
>> org.apache.solr.client.solrj.impl.HttpSolrServer.(HttpSolrServer.java:155)
>> >at
>> >
>> org.apache.solr.client.solrj.impl.HttpSolrServer.(HttpSolrServer.java:132)
>> >at
>> >
>> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer.(ConcurrentUpdateSolrServer.java:101)
>> >at
>> >
>> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer.(ConcurrentUpdateSolrServer.java:93)
>> >at
>> >
>> diva.commons.search.cdi.SolrServerFactory.init(SolrServerFactory.java:56)
>> >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> >at
>> >
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> >at
>> >
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> >at java.lang.reflect.Method.invoke(Method.java:601)
>> >at
>> >
>> com.sun.ejb.containers.interceptors.BeanCallbackInterceptor.intercept(InterceptorManager.java:1009)
>> >at
>> >
>> com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:65)
>> >at
>> >
>> com.sun.ejb.containers.interceptors.CallbackInvocationContext.proceed(CallbackInvocationContext.java:113)
>> >at
>> >
>> com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCallback(SystemInterceptorProxy.java:138)
>> >at
>> >
>> com.sun.ejb.containers.interceptors.SystemInterceptorProxy.init(SystemInterceptorProxy.java:120)
>> >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> >at
>> >
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>> >at
>> >
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> >at java.lang.reflect.Method.invoke(Method.java:601)
>> >at
>> >
>> com.sun.ejb.containers.interceptors.CallbackInterceptor.intercept(InterceptorManager.java:964)
>> >at
>> >
>> com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:65)
>> >at
>> >
>> com.sun.e

Re: Strange error in Solr 4.2

[Uwe Klosa]

Thanks, but nobody has tempered with keystores. I have tested the
application on different machines. Always the same exception is thrown.

Do we have to set some system property to fix this?

/Uwe




On 14 March 2013 16:36, Mark Miller  wrote:

> Perhaps as a result of https://issues.apache.org/jira/browse/SOLR-4451 ?
>
> Just a guess.
>
> The root cause looks to be:
>
> > Caused by: java.io.IOException: Keystore was tampered with, or password
> was
> > incorrect
>
>
> - Mark
>
> On Mar 14, 2013, at 11:24 AM, Uwe Klosa  wrote:
>
> > Hi
> >
> > We have been using Solr 4.0 for a while now and wanted to upgrade to 4.2.
> > But our application stopped working. When we tried 4.1 it was working as
> > expected.
> >
> > Here is a  description of the situation.
> >
> > We deploy a Solr web application under java 7 on a Glassfish 3.1.2.2
> > server. We added some classes to the standard Solr webapp which are
> > listening to a jms service and update the index according to the message
> > content, which can be fetch the document with this id from that URL and
> add
> > it to the index. The documents are fetched via SSL from a repository
> server.
> >
> > This has been working well since Solr 1.2 for about 6 years now. With
> Solr
> > 4.2 we suddenly get the following error:
> >
> > javax.ejb.CreateException: Initialization failed for Singleton
> > IndexMessageClientFactory
> >at
> >
> com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:547)
> > ...
> > Caused by: org.apache.http.conn.ssl.SSLInitializationException: Failure
> > initializing default system SSL context
> >at
> >
> org.apache.http.conn.ssl.SSLSocketFactory.createSystemSSLContext(SSLSocketFactory.java:368)
> >at
> >
> org.apache.http.conn.ssl.SSLSocketFactory.getSystemSocketFactory(SSLSocketFactory.java:204)
> >at
> >
> org.apache.http.impl.conn.SchemeRegistryFactory.createSystemDefault(SchemeRegistryFactory.java:82)
> >at
> >
> org.apache.http.impl.client.SystemDefaultHttpClient.createClientConnectionManager(SystemDefaultHttpClient.java:118)
> >at
> >
> org.apache.http.impl.client.AbstractHttpClient.getConnectionManager(AbstractHttpClient.java:466)
> >at
> >
> org.apache.solr.client.solrj.impl.HttpClientUtil.setMaxConnections(HttpClientUtil.java:179)
> >at
> >
> org.apache.solr.client.solrj.impl.HttpClientConfigurer.configure(HttpClientConfigurer.java:33)
> >at
> >
> org.apache.solr.client.solrj.impl.HttpClientUtil.configureClient(HttpClientUtil.java:115)
> >at
> >
> org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:105)
> >at
> >
> org.apache.solr.client.solrj.impl.HttpSolrServer.(HttpSolrServer.java:155)
> >at
> >
> org.apache.solr.client.solrj.impl.HttpSolrServer.(HttpSolrServer.java:132)
> >at
> >
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer.(ConcurrentUpdateSolrServer.java:101)
> >at
> >
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer.(ConcurrentUpdateSolrServer.java:93)
> >at
> > diva.commons.search.cdi.SolrServerFactory.init(SolrServerFactory.java:56)
> >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> >at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >at java.lang.reflect.Method.invoke(Method.java:601)
> >at
> >
> com.sun.ejb.containers.interceptors.BeanCallbackInterceptor.intercept(InterceptorManager.java:1009)
> >at
> >
> com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:65)
> >at
> >
> com.sun.ejb.containers.interceptors.CallbackInvocationContext.proceed(CallbackInvocationContext.java:113)
> >at
> >
> com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCallback(SystemInterceptorProxy.java:138)
> >at
> >
> com.sun.ejb.containers.interceptors.SystemInterceptorProxy.init(SystemInterceptorProxy.java:120)
> >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> >at
> >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> >at
> >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> >at java.lang.reflect.Method.invoke(Method.java:601)
> >at
> >
> com.sun.ejb.containers.interceptors.CallbackInterceptor.intercept(InterceptorManager.java:964)
> >at
> >
> com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:65)
> >at
> >
> com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:393)
> >at
> >
> com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:376)
> >at
> >
> com.sun.ejb.containers.AbstractSingl

Re: Strange error in Solr 4.2

[Mark Miller]

Perhaps as a result of https://issues.apache.org/jira/browse/SOLR-4451 ?

Just a guess.

The root cause looks to be:

> Caused by: java.io.IOException: Keystore was tampered with, or password was
> incorrect


- Mark

On Mar 14, 2013, at 11:24 AM, Uwe Klosa  wrote:

> Hi
> 
> We have been using Solr 4.0 for a while now and wanted to upgrade to 4.2.
> But our application stopped working. When we tried 4.1 it was working as
> expected.
> 
> Here is a  description of the situation.
> 
> We deploy a Solr web application under java 7 on a Glassfish 3.1.2.2
> server. We added some classes to the standard Solr webapp which are
> listening to a jms service and update the index according to the message
> content, which can be fetch the document with this id from that URL and add
> it to the index. The documents are fetched via SSL from a repository server.
> 
> This has been working well since Solr 1.2 for about 6 years now. With Solr
> 4.2 we suddenly get the following error:
> 
> javax.ejb.CreateException: Initialization failed for Singleton
> IndexMessageClientFactory
>at
> com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:547)
> ...
> Caused by: org.apache.http.conn.ssl.SSLInitializationException: Failure
> initializing default system SSL context
>at
> org.apache.http.conn.ssl.SSLSocketFactory.createSystemSSLContext(SSLSocketFactory.java:368)
>at
> org.apache.http.conn.ssl.SSLSocketFactory.getSystemSocketFactory(SSLSocketFactory.java:204)
>at
> org.apache.http.impl.conn.SchemeRegistryFactory.createSystemDefault(SchemeRegistryFactory.java:82)
>at
> org.apache.http.impl.client.SystemDefaultHttpClient.createClientConnectionManager(SystemDefaultHttpClient.java:118)
>at
> org.apache.http.impl.client.AbstractHttpClient.getConnectionManager(AbstractHttpClient.java:466)
>at
> org.apache.solr.client.solrj.impl.HttpClientUtil.setMaxConnections(HttpClientUtil.java:179)
>at
> org.apache.solr.client.solrj.impl.HttpClientConfigurer.configure(HttpClientConfigurer.java:33)
>at
> org.apache.solr.client.solrj.impl.HttpClientUtil.configureClient(HttpClientUtil.java:115)
>at
> org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:105)
>at
> org.apache.solr.client.solrj.impl.HttpSolrServer.(HttpSolrServer.java:155)
>at
> org.apache.solr.client.solrj.impl.HttpSolrServer.(HttpSolrServer.java:132)
>at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer.(ConcurrentUpdateSolrServer.java:101)
>at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer.(ConcurrentUpdateSolrServer.java:93)
>at
> diva.commons.search.cdi.SolrServerFactory.init(SolrServerFactory.java:56)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.lang.reflect.Method.invoke(Method.java:601)
>at
> com.sun.ejb.containers.interceptors.BeanCallbackInterceptor.intercept(InterceptorManager.java:1009)
>at
> com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:65)
>at
> com.sun.ejb.containers.interceptors.CallbackInvocationContext.proceed(CallbackInvocationContext.java:113)
>at
> com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCallback(SystemInterceptorProxy.java:138)
>at
> com.sun.ejb.containers.interceptors.SystemInterceptorProxy.init(SystemInterceptorProxy.java:120)
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>at java.lang.reflect.Method.invoke(Method.java:601)
>at
> com.sun.ejb.containers.interceptors.CallbackInterceptor.intercept(InterceptorManager.java:964)
>at
> com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:65)
>at
> com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:393)
>at
> com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:376)
>at
> com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:538)
>... 103 more
> Caused by: java.io.IOException: Keystore was tampered with, or password was
> incorrect
>at
> sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:772)
>at
> sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:55)
>at java.security.KeyStore.load(KeyStore.java:1214)
>at
> org.apache.http.conn.ssl.SSLSocketFactory.createSystemSSLContext(SSLS

Strange error in Solr 4.2

[Uwe Klosa]

Hi

We have been using Solr 4.0 for a while now and wanted to upgrade to 4.2.
But our application stopped working. When we tried 4.1 it was working as
expected.

Here is a  description of the situation.

We deploy a Solr web application under java 7 on a Glassfish 3.1.2.2
server. We added some classes to the standard Solr webapp which are
listening to a jms service and update the index according to the message
content, which can be fetch the document with this id from that URL and add
it to the index. The documents are fetched via SSL from a repository server.

This has been working well since Solr 1.2 for about 6 years now. With Solr
4.2 we suddenly get the following error:

javax.ejb.CreateException: Initialization failed for Singleton
IndexMessageClientFactory
at
com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:547)
...
Caused by: org.apache.http.conn.ssl.SSLInitializationException: Failure
initializing default system SSL context
at
org.apache.http.conn.ssl.SSLSocketFactory.createSystemSSLContext(SSLSocketFactory.java:368)
at
org.apache.http.conn.ssl.SSLSocketFactory.getSystemSocketFactory(SSLSocketFactory.java:204)
at
org.apache.http.impl.conn.SchemeRegistryFactory.createSystemDefault(SchemeRegistryFactory.java:82)
at
org.apache.http.impl.client.SystemDefaultHttpClient.createClientConnectionManager(SystemDefaultHttpClient.java:118)
at
org.apache.http.impl.client.AbstractHttpClient.getConnectionManager(AbstractHttpClient.java:466)
at
org.apache.solr.client.solrj.impl.HttpClientUtil.setMaxConnections(HttpClientUtil.java:179)
at
org.apache.solr.client.solrj.impl.HttpClientConfigurer.configure(HttpClientConfigurer.java:33)
at
org.apache.solr.client.solrj.impl.HttpClientUtil.configureClient(HttpClientUtil.java:115)
at
org.apache.solr.client.solrj.impl.HttpClientUtil.createClient(HttpClientUtil.java:105)
at
org.apache.solr.client.solrj.impl.HttpSolrServer.(HttpSolrServer.java:155)
at
org.apache.solr.client.solrj.impl.HttpSolrServer.(HttpSolrServer.java:132)
at
org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer.(ConcurrentUpdateSolrServer.java:101)
at
org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrServer.(ConcurrentUpdateSolrServer.java:93)
at
diva.commons.search.cdi.SolrServerFactory.init(SolrServerFactory.java:56)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
com.sun.ejb.containers.interceptors.BeanCallbackInterceptor.intercept(InterceptorManager.java:1009)
at
com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:65)
at
com.sun.ejb.containers.interceptors.CallbackInvocationContext.proceed(CallbackInvocationContext.java:113)
at
com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doCallback(SystemInterceptorProxy.java:138)
at
com.sun.ejb.containers.interceptors.SystemInterceptorProxy.init(SystemInterceptorProxy.java:120)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
com.sun.ejb.containers.interceptors.CallbackInterceptor.intercept(InterceptorManager.java:964)
at
com.sun.ejb.containers.interceptors.CallbackChainImpl.invokeNext(CallbackChainImpl.java:65)
at
com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:393)
at
com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:376)
at
com.sun.ejb.containers.AbstractSingletonContainer.createSingletonEJB(AbstractSingletonContainer.java:538)
... 103 more
Caused by: java.io.IOException: Keystore was tampered with, or password was
incorrect
at
sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:772)
at
sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:55)
at java.security.KeyStore.load(KeyStore.java:1214)
at
org.apache.http.conn.ssl.SSLSocketFactory.createSystemSSLContext(SSLSocketFactory.java:281)
at
org.apache.http.conn.ssl.SSLSocketFactory.createSystemSSLContext(SSLSocketFactory.java:366)
... 134 more
Caused by: java.security.UnrecoverableKeyException: Password verification
failed
at
sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:770)


This exception occurs in this part

new ConcurrentUpdateSolrServer("http://solr.diva-portal.org:8080/search

Re: Strange Error

[Erick Erickson]

did you re-index everything after you changed from date to tdate? Looks to
me like you had some data already in your index, changed the defs, added a
few more docs and blew up.

I'd just blow away your entire index directory and re-index from scratch...

Best
Erick


On Tue, Mar 5, 2013 at 11:02 PM, Eric Myers  wrote:

> |
>
> I am getting the following error when I try to use a stats.facet for a
> date field. Anyone know how to fix this?
>
> Invalid Date String:' #1;#0;#0;#0;oT$#0;'
>
> ||I have checked the values of the date and they are all fine.
> I am not sure where this is coming from.
>
> The really odd thing is that this worked fine, and then all of a sudden
> went crazy. I tried both date and tdate (it worked with date for a while).
>
> |the query string
>
> http://hidden/solr/activity/select?q=*%3A*&wt=xml&indent=true&stats=true&stats.field=amount&stats.facet=date_facet
>
> field data
> 2013-03-05T05:00:00Z
>
> schema
>
>
>  positionIncrementGap="0"/>
>  positionIncrementGap="0"/>
>
>

Strange Error

[Eric Myers]

|

I am getting the following error when I try to use a stats.facet for a date 
field. Anyone know how to fix this?

Invalid Date String:' #1;#0;#0;#0;oT$#0;'

||I have checked the values of the date and they are all fine.  
I am not sure where this is coming from. 

The really odd thing is that this worked fine, and then all of a sudden went 
crazy. I tried both date and tdate (it worked with date for a while).

|the query string
http://hidden/solr/activity/select?q=*%3A*&wt=xml&indent=true&stats=true&stats.field=amount&stats.facet=date_facet

field data
2013-03-05T05:00:00Z

schema 
   

Strange Error - org.apache.solr.response.XMLWriter.writePrim(XMLWriter.java:778)

[Rohit]

Hi,

 

I delete some data from Solr, post the deletion I am getting truncated XML
when I run q=*:* query,  in all other cases the queries execute fine. The
following error is shown in the log files,

 

May 25, 2012 7:10:36 PM org.apache.solr.common.SolrException log

SEVERE: java.lang.NullPointerException

at
org.apache.solr.response.XMLWriter.writePrim(XMLWriter.java:778)

at
org.apache.solr.response.XMLWriter.writeStr(XMLWriter.java:687)

at org.apache.solr.schema.StrField.write(StrField.java:45)

at
org.apache.solr.schema.SchemaField.write(SchemaField.java:131)

at
org.apache.solr.response.XMLWriter.writeDoc(XMLWriter.java:370)

at
org.apache.solr.response.XMLWriter$3.writeDocs(XMLWriter.java:546)

at
org.apache.solr.response.XMLWriter.writeDocuments(XMLWriter.java:483)

at
org.apache.solr.response.XMLWriter.writeDocList(XMLWriter.java:520)

at
org.apache.solr.response.XMLWriter.writeVal(XMLWriter.java:583)

at
org.apache.solr.response.XMLWriter.writeResponse(XMLWriter.java:132)

 

I gather that this is related to

https://issues.apache.org/jira/browse/SOLR-1903,   is there any other fix to
solve this problem. I am currently using solr 3.6.

 

Regards,

Rohit

 

 

Re: Strange error with shards

[Shalin Shekhar Mangar]

On Wed, Aug 19, 2009 at 6:44 PM, ahammad  wrote:

>
> Each core has a different database as a datasource, which means that they
> have different DB structures and fields. That is why the schemas are
> different.


> > If all the shards should have the same schema, then what is the point of
> > sharding in the first place? I thought that it was used to combine
> > different cores with different index structures...Right now, every core I
> > have is unique, and every schema is different...
> >
>

Index is sharded when it becomes too much for one box to keep the whole
index. Distributed Search in Solr can merge these multiple indexes running
on different boxes into one result set. It is not meant for combining
different cores or different schemas. If many shards have a document with
the same uniqueKey value, any one can be returned. Typically, shards have
the same schema, with each having a disjoint subset of the complete set of
documents.

-- 
Regards,
Shalin Shekhar Mangar.

Re: Strange error with shards

[ahammad]

Each core has a different database as a datasource, which means that they
have different DB structures and fields. That is why the schemas are
different.

I figured out the cause of this problem. You were right, it was the
uniqueKey field. All of my cores have that field set to "id" but for this
new core, it is set to "threadID". Changing that to id fixed the problem.




Shalin Shekhar Mangar wrote:
> 
> On Tue, Aug 18, 2009 at 9:01 PM, ahammad  wrote:
> 
>> HTTP Status 500 - null java.lang.NullPointerException at
>>
>> org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:437)
>> at
>>
>> The way I created this shard was to copy an existing one, erasing all the
>> data files/folders, and modifying my schema/data-config files. So the
>> core
>> settings are pretty much the same.
>>
> 
> What did you modify in the schema? All the shards should have the same
> schema. That exception can come if the uniqueKey is missing/null.
> 
> If all the shards should have the same schema, then what is the point of
> sharding in the first place? I thought that it was used to combine
> different cores with different index structures...Right now, every core I
> have is unique, and every schema is different...
> 
> -- 
> Regards,
> Shalin Shekhar Mangar.
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Strange-error-with-shards-tp25027486p25043859.html
Sent from the Solr - User mailing list archive at Nabble.com.

Re: Strange error with shards

[Shalin Shekhar Mangar]

On Tue, Aug 18, 2009 at 9:01 PM, ahammad  wrote:

> HTTP Status 500 - null java.lang.NullPointerException at
>
> org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:437)
> at
>
> The way I created this shard was to copy an existing one, erasing all the
> data files/folders, and modifying my schema/data-config files. So the core
> settings are pretty much the same.
>

What did you modify in the schema? All the shards should have the same
schema. That exception can come if the uniqueKey is missing/null.

-- 
Regards,
Shalin Shekhar Mangar.

Re: Strange error with shards

[Licinio Fernández Maurelo]

Looks like the index is corrupted, try restoring it

2009/8/18 ahammad :
>
> Hello,
>
> I have been using multicore/shards for the past 5 months or so with no
> problems at all. I just added another core to my Solr server, but for some
> reason I can never get the shards working when that specific core is
> anywhere in the URL (either in the shards list or the base URL).
>
> HTTP Status 500 - null java.lang.NullPointerException at
> org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:437)
> at
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:281)
> at
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:290)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1330) at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:303)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:232)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
> at
> org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:859)
> at
> org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:574)
> at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1527)
> at java.lang.Thread.run(Thread.java:619)
>
> The way I created this shard was to copy an existing one, erasing all the
> data files/folders, and modifying my schema/data-config files. So the core
> settings are pretty much the same.
>
> If I try the shard parameter with any of the other 7 cores that I have, it
> works fine. It's only when this specific one is in the URL...
>
> Cheers
> --
> View this message in context: 
> http://www.nabble.com/Strange-error-with-shards-tp25027486p25027486.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>
>



-- 
Lici

Strange error with shards

[ahammad]

Hello,

I have been using multicore/shards for the past 5 months or so with no
problems at all. I just added another core to my Solr server, but for some
reason I can never get the shards working when that specific core is
anywhere in the URL (either in the shards list or the base URL).

HTTP Status 500 - null java.lang.NullPointerException at
org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:437)
at
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:281)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:290)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1330) at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:303)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:232)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at
org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:859)
at
org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:574)
at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1527)
at java.lang.Thread.run(Thread.java:619) 

The way I created this shard was to copy an existing one, erasing all the
data files/folders, and modifying my schema/data-config files. So the core
settings are pretty much the same.

If I try the shard parameter with any of the other 7 cores that I have, it
works fine. It's only when this specific one is in the URL...

Cheers
-- 
View this message in context: 
http://www.nabble.com/Strange-error-with-shards-tp25027486p25027486.html
Sent from the Solr - User mailing list archive at Nabble.com.