date:20120905

I don't think I changed by solrconfig.xml file from the default that
was provided in the example folder for solr 4.0.

On Tue, Sep 4, 2012 at 3:40 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:

 :   core name=MYCORE_test instanceDir=MYCORE dataDir=MYCORE_test /

 I'm pretty sure what you hav above tells solr that core MYCORE_test it
 should use the instanceDir MYCORE but ignore the dataDir/ in that
 solrconfig.xml and use the one you specified.

 This on the other hand...

 :core name=MYCORE_test instanceDir=MYCORE
 :  property name=dataDir value=MYCORE_test /
 : /core

 ...tells solr that the MYCORE_test SolrCore should use the instanceDir
 MYCORE, and when parsing that solrconfig.xml file it should set the
 variable ${dataDir} to be MYCORE_test -- but if your solconfig.xml file
 does not ever refer to the  ${dataDir} variable, it would have any effect.

 so the question becomes -- what does your solrconfig.xml look like?


 -Hoss

Re: AW: AW: auto completion search with solr using NGrams in SOLR

2012-09-05 Thread Ahmet Arslan

 i want to search with title and empname both. 

I know, I give that URL just to get the idea here.
If you try 
suggest/?q=michael bdf=titledefType=lucenefl=title
you will see that your interested will in results section not lst 
name=spellcheck section.

 or title or song...). Here (*suggest/?q=michael
 bdf=titledefType=lucene*) we are specifying the
 title type search. 

q=title:michael b OR empname:michael bfl=title,empname would the trick.


 I removed said configurations in solrconfig.xml file, got
 result like below.

If you removed it, then there shouldn't be spellcheck response. And you are 
still looking results in the wrong place.

Still see document after delete with commit in solr 4.0

I've recently upgraded to solr 4.0 from solr 3.5 and I think my delete
statement used to work, but now it doesn't seem to be deleting. I've
been experimenting around, and it seems like this should be the URL
for deleting the document with the uri of network_24.

In a browser, I first go here:

http://localhost:8983/solr/MYCORE/update?stream.body=%3Cdelete%3E%3Cquery%3Euri%3Anetwork_24%3C%2Fquery%3E%3C%2Fdelete%3Ecommit=true

I get this response:

response
  lst name=responseHeader
int name=status0/int
int name=QTime5/int
  /lst
/response

And this is in the log file:

(timestamp) org.apache.solr.update.DirectUpdateHandler2 commit
INFO: start 
commit{flags=0,_version_=0,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false}
(timestamp) org.apache.solr.search.SolrIndexSearcher init
INFO: Opening Searcher@646dd60e main
(timestamp) org.apache.solr.update.DirectUpdateHandler2 commit
INFO: end_commit_flush
(timestamp) org.apache.solr.core.QuerySenderListener newSearcher
INFO: QuerySenderListener sending requests to Searcher@646dd60e
main{StandardDirectoryReader(segments_2v:447 _4p(4.0.0.1):C3244)}
(timestamp) org.apache.solr.core.QuerySenderListener newSearcher
INFO: QuerySenderListener done.
S(timestamp) org.apache.solr.core.SolrCore registerSearcher
INFO: [MYCORE] Registered new searcher Searcher@646dd60e
main{StandardDirectoryReader(segments_2v:447 _4p(4.0.0.1):C3244)}
(timestamp) org.apache.solr.update.processor.LogUpdateProcessor finish
INFO: [MYCORE] webapp=/solr path=/update
params={commit=truestream.body=deletequeryuri:network_24/query/delete}
{deleteByQuery=uri:network_24,commit=} 0 5

But if I then go to this URL:

http://localhost:8983/solr/MYCORE/select?q=uri%3Anetwork_24wt=xml

I get this response:

response
  lst name=responseHeader
int name=status0/int
int name=QTime1/int
lst name=params
  str name=wtxml/str
  str name=quri:network_24/str
/lst
  /lst
  result name=response numFound=1 start=0
doc
  str name=namenetwork24/str
  str name=urinetwork_24/str
/doc
  /result
/response

Why didn't that document disappear?

Re: Still see document after delete with commit in solr 4.0

Check to make sure that you are not stumbling into SOLR-3432: deleteByQuery 
silently ignored if updateLog is enabled, but {{_version_}} field does not 
exist in schema.


See:
https://issues.apache.org/jira/browse/SOLR-3432

-- Jack Krupansky

-Original Message- 
From: Paul

Sent: Wednesday, September 05, 2012 10:05 AM
To: solr-user
Subject: Still see document after delete with commit in solr 4.0

I've recently upgraded to solr 4.0 from solr 3.5 and I think my delete
statement used to work, but now it doesn't seem to be deleting. I've
been experimenting around, and it seems like this should be the URL
for deleting the document with the uri of network_24.

In a browser, I first go here:

http://localhost:8983/solr/MYCORE/update?stream.body=%3Cdelete%3E%3Cquery%3Euri%3Anetwork_24%3C%2Fquery%3E%3C%2Fdelete%3Ecommit=true

I get this response:

response
 lst name=responseHeader
   int name=status0/int
   int name=QTime5/int
 /lst
/response

And this is in the log file:

(timestamp) org.apache.solr.update.DirectUpdateHandler2 commit
INFO: start 
commit{flags=0,_version_=0,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false}

(timestamp) org.apache.solr.search.SolrIndexSearcher init
INFO: Opening Searcher@646dd60e main
(timestamp) org.apache.solr.update.DirectUpdateHandler2 commit
INFO: end_commit_flush
(timestamp) org.apache.solr.core.QuerySenderListener newSearcher
INFO: QuerySenderListener sending requests to Searcher@646dd60e
main{StandardDirectoryReader(segments_2v:447 _4p(4.0.0.1):C3244)}
(timestamp) org.apache.solr.core.QuerySenderListener newSearcher
INFO: QuerySenderListener done.
S(timestamp) org.apache.solr.core.SolrCore registerSearcher
INFO: [MYCORE] Registered new searcher Searcher@646dd60e
main{StandardDirectoryReader(segments_2v:447 _4p(4.0.0.1):C3244)}
(timestamp) org.apache.solr.update.processor.LogUpdateProcessor finish
INFO: [MYCORE] webapp=/solr path=/update
params={commit=truestream.body=deletequeryuri:network_24/query/delete}
{deleteByQuery=uri:network_24,commit=} 0 5

But if I then go to this URL:

http://localhost:8983/solr/MYCORE/select?q=uri%3Anetwork_24wt=xml

I get this response:

response
 lst name=responseHeader
   int name=status0/int
   int name=QTime1/int
   lst name=params
 str name=wtxml/str
 str name=quri:network_24/str
   /lst
 /lst
 result name=response numFound=1 start=0
   doc
 str name=namenetwork24/str
 str name=urinetwork_24/str
   /doc
 /result
/response

Why didn't that document disappear?

RE: exception in highlighter when using phrase search

2012-09-05 Thread Yoni Amir

I think I found the cause for this. It is partially my fault, because I sent 
solr a field with empty value, but this is also a configuration problem.

https://issues.apache.org/jira/browse/SOLR-3792


-Original Message-
From: Yoni Amir [mailto:yoni.a...@actimize.com] 
Sent: Tuesday, September 04, 2012 3:53 PM
To: solr-user@lucene.apache.org
Subject: exception in highlighter when using phrase search

I got this problem with solr 4 beta and the highlighting component.

When I search for a phrase, such as foo bar, everything works ok.
When I add highlighting, I get this exception below.
You can see according to the first log line that I am searching only one field  
(all_text), but what is not visible in the log is that I am highlighting on all 
fields in the document, with hl.requireFieldMatch=false and hl.fl=*.

INFO  (SolrCore.java:1670) - [rcmCore] webapp=/solr path=/select 
params={fq={!edismax}module:Alerts+and+bu:abcd+Region1qf=attachmentqf=all_textversion=2rows=20wt=javabinstart=0q=foo
 bar} hits=103 status=500 QTime=38 ERROR (SolrException.java:104) - 
null:java.lang.NullPointerException
   at 
org.apache.lucene.analysis.util.CharacterUtils$Java5CharacterUtils.fill(CharacterUtils.java:191)
   at 
org.apache.lucene.analysis.util.CharTokenizer.incrementToken(CharTokenizer.java:152)
   at 
org.apache.lucene.analysis.miscellaneous.WordDelimiterFilter.incrementToken(WordDelimiterFilter.java:209)
   at 
org.apache.lucene.analysis.util.FilteringTokenFilter.incrementToken(FilteringTokenFilter.java:50)
   at 
org.apache.lucene.analysis.miscellaneous.RemoveDuplicatesTokenFilter.incrementToken(RemoveDuplicatesTokenFilter.java:54)
   at 
org.apache.lucene.analysis.core.LowerCaseFilter.incrementToken(LowerCaseFilter.java:54)
   at 
org.apache.solr.highlight.TokenOrderingFilter.incrementToken(DefaultSolrHighlighter.java:629)
   at 
org.apache.lucene.analysis.CachingTokenFilter.fillCache(CachingTokenFilter.java:78)
   at 
org.apache.lucene.analysis.CachingTokenFilter.incrementToken(CachingTokenFilter.java:50)
   at 
org.apache.lucene.search.highlight.Highlighter.getBestTextFragments(Highlighter.java:225)
   at 
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingByHighlighter(DefaultSolrHighlighter.java:510)
   at 
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlighting(DefaultSolrHighlighter.java:401)
   at 
org.apache.solr.handler.component.HighlightComponent.process(HighlightComponent.java:136)
   at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:206)
   at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1656)
   at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:454)
   at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:275)
   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.Http11Processor.process(Http11Processor.java:849)
   at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
   at 
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
   at java.lang.Thread.run(Thread.java:736)

Any idea?

Thanks,
Yoni

Re: Solr 4.0 BETA Replication problems on Tomcat

2012-09-05 Thread Ravi Solr

Wow, That was quick. Thank you very much Mr. Siren. I shall remove the
compression node in the solrconfig.xml and let you know how it went.

Thanks,

Ravi Kiran Bhaskar

On Wed, Sep 5, 2012 at 2:54 AM, Sami Siren ssi...@gmail.com wrote:
 I opened SOLR-3789. As a workaround you can remove str
 name=compressioninternal/str from the config and it should work.

 --
  Sami Siren

 On Wed, Sep 5, 2012 at 5:58 AM, Ravi Solr ravis...@gmail.com wrote:
 Hello,
 I have a very simple setup one master and one slave configured
 as below, but replication keeps failing with stacktrace as shown
 below. Note that 3.6 works fine on the same machines so I am thinking
 that Iam missing something in configuration with regards to solr
 4.0...can somebody kindly let me know if Iam missing something ? I am
 running SOLR 4.0 on Tomcat-7.0.29 with Java6. FYI I never has any
 problem with SOLR on glassfish, this is the first time Iam using it on
 Tomcat

 On Master

 requestHandler name=/replication class=solr.ReplicationHandler
  lst name=master
   str name=replicateAftercommit/str
   str name=replicateAfteroptimize/str
   str name=confFilesschema.xml,stopwords.txt,synonyms.txt/str
   str name=commitReserveDuration00:00:10/str
   /lst
 /requestHandler

 On Slave

 requestHandler name=/replication class=solr.ReplicationHandler 
  lst name=slave
 str 
 name=masterUrlhttp://testslave:8080/solr/mycore/replication/str

 str name=pollInterval00:00:50/str
 str name=compressioninternal/str
 str name=httpConnTimeout5000/str
 str name=httpReadTimeout1/str
  /lst
 /requestHandler


 Error

 22:44:10WARNING SnapPuller  Error in fetching packets

 java.util.zip.ZipException: unknown compression method
 at 
 java.util.zip.InflaterInputStream.read(InflaterInputStream.java:147)
 at 
 org.apache.solr.common.util.FastInputStream.readWrappedStream(FastInputStream.java:79)
 at 
 org.apache.solr.common.util.FastInputStream.refill(FastInputStream.java:88)
 at 
 org.apache.solr.common.util.FastInputStream.read(FastInputStream.java:124)
 at 
 org.apache.solr.common.util.FastInputStream.readFully(FastInputStream.java:149)
 at 
 org.apache.solr.common.util.FastInputStream.readFully(FastInputStream.java:144)
 at 
 org.apache.solr.handler.SnapPuller$FileFetcher.fetchPackets(SnapPuller.java:1024)
 at 
 org.apache.solr.handler.SnapPuller$FileFetcher.fetchFile(SnapPuller.java:985)
 at 
 org.apache.solr.handler.SnapPuller.downloadIndexFiles(SnapPuller.java:627)
 at 
 org.apache.solr.handler.SnapPuller.fetchLatestIndex(SnapPuller.java:331)
 at 
 org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:297)
 at org.apache.solr.handler.SnapPuller$1.run(SnapPuller.java:175)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
 at 
 java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
 at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:662)

 22:44:10SEVERE  ReplicationHandler  SnapPull failed
 :org.apache.solr.common.SolrException: Unable to download
 _3_Lucene40_0.tip completely. Downloaded 0!=170 at
 org.apache.solr.handler.SnapPuller$FileFetcher.cleanup(SnapPuller.java:1115)
 at 
 org.apache.solr.handler.SnapPuller$FileFetcher.fetchFile(SnapPuller.java:999)
 at org.apache.solr.handler.SnapPuller.downloadIndexFiles(SnapPuller.java:627)
 at org.apache.solr.handler.SnapPuller.fetchLatestIndex(SnapPuller.java:331)
 at 
 org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:297)
 at org.apache.solr.handler.SnapPuller$1.run(SnapPuller.java:175) at
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
 at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
 at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) at
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
 at

Website (crawler for) indexing

2012-09-05 Thread Lochschmied, Alexander

This may be a bit off topic: How do you index an existing website and control 
the data going into index?

We already have Java code to process the HTML (or XHTML) and turn it into a 
SolrJ Document (removing tags and other things we do not want in the index). We 
use SolrJ for indexing.
So I guess the question is essentially which Java crawler could be useful.

We used to use wget on command line in our publishing process, but we do no 
longer want to do that.

Thanks,
Alexander

RE: Website (crawler for) indexing

2012-09-05 Thread Markus Jelsma

Please take a look at the Apache Nutch project.  
http://nutch.apache.org/

-Original message-
 From:Lochschmied, Alexander alexander.lochschm...@vishay.com
 Sent: Wed 05-Sep-2012 17:09
 To: solr-user@lucene.apache.org
 Subject: Website (crawler for) indexing

 This may be a bit off topic: How do you index an existing website and control 
 the data going into index?

 We already have Java code to process the HTML (or XHTML) and turn it into a 
 SolrJ Document (removing tags and other things we do not want in the index). 
 We use SolrJ for indexing.
 So I guess the question is essentially which Java crawler could be useful.

 We used to use wget on command line in our publishing process, but we do no 
 longer want to do that.

 Thanks,
 Alexander

Re: Website (crawler for) indexing

2012-09-05 Thread Rafał Kuć

Hello!

You can implement your own crawler using Droids
(http://incubator.apache.org/droids/) or use Apache Nutch
(http://nutch.apache.org/), which is very easy to integrate with Solr
and is very powerful crawler.

-- 
Regards,
 Rafał Kuć
 Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch - ElasticSearch

 This may be a bit off topic: How do you index an existing website
 and control the data going into index?

 We already have Java code to process the HTML (or XHTML) and turn
 it into a SolrJ Document (removing tags and other things we do not
 want in the index). We use SolrJ for indexing.
 So I guess the question is essentially which Java crawler could be useful.

 We used to use wget on command line in our publishing process, but we do no 
 longer want to do that.

 Thanks,
 Alexander

Re: Delete all documents in the index

Check to make sure that you are not stumbling into SOLR-3432: deleteByQuery 
silently ignored if updateLog is enabled, but {{_version_}} field does not 
exist in schema.


See:
https://issues.apache.org/jira/browse/SOLR-3432

This could happen if you kept the new 4.0 solrconfig.xml, but copied in your 
pre-4.0 schema.xml.


-- Jack Krupansky

-Original Message- 
From: Rohit Harchandani

Sent: Wednesday, September 05, 2012 12:48 PM
To: solr-user@lucene.apache.org
Subject: Delete all documents in the index

Hi,
I am having difficulty deleting documents from the index using curl. The
urls i tried were:
curl http://localhost:9020/solr/core1/update/?stream.body=
deletequery*:*/query/deletecommit=true
curl http://localhost:9020/solr/core1/update/?commit=true; -H
Content-Type: text/xml --data-binary 'deletequeryid:[* TO
*]/query/delete'
curl http://localhost:9020/solr/core1/update/?commit=true; -H
Content-Type: text/xml --data-binary 'deletequery*:*/query/delete'
I also tried:
curl 
http://localhost:9020/solr/core1/update/?stream.body=%3Cdelete%3E%3Cquery%3E*:*%3C/query%3E%3C/delete%3Ecommit=true

as suggested on some forums. I get a response with status=0 in all cases,
but none of the above seem to work.
When I run
curl http://localhost:9020/solr/core1/select?q=*:*rows=0wt=xml;
I still get a value for numFound.

I am currently using solr 4.0 beta version.

Thanks for your help in advance.
Regards,
Rohit

Re: Delete all documents in the index

2012-09-05 Thread Michael Della Bitta

Rohit:

If it's easy, the easiest thing to do is to turn off your servlet
container, rm -r * inside of the data directory, and then restart the
container.

Michael Della Bitta


Appinions | 18 East 41st St., Suite 1806 | New York, NY 10017
www.appinions.com
Where Influence Isn’t a Game


On Wed, Sep 5, 2012 at 12:56 PM, Jack Krupansky j...@basetechnology.com wrote:
 Check to make sure that you are not stumbling into SOLR-3432: deleteByQuery
 silently ignored if updateLog is enabled, but {{_version_}} field does not
 exist in schema.

 See:
 https://issues.apache.org/jira/browse/SOLR-3432

 This could happen if you kept the new 4.0 solrconfig.xml, but copied in your
 pre-4.0 schema.xml.

 -- Jack Krupansky

 -Original Message- From: Rohit Harchandani
 Sent: Wednesday, September 05, 2012 12:48 PM
 To: solr-user@lucene.apache.org
 Subject: Delete all documents in the index


 Hi,
 I am having difficulty deleting documents from the index using curl. The
 urls i tried were:
 curl http://localhost:9020/solr/core1/update/?stream.body=
 deletequery*:*/query/deletecommit=true
 curl http://localhost:9020/solr/core1/update/?commit=true; -H
 Content-Type: text/xml --data-binary 'deletequeryid:[* TO
 *]/query/delete'
 curl http://localhost:9020/solr/core1/update/?commit=true; -H
 Content-Type: text/xml --data-binary 'deletequery*:*/query/delete'
 I also tried:
 curl 
 http://localhost:9020/solr/core1/update/?stream.body=%3Cdelete%3E%3Cquery%3E*:*%3C/query%3E%3C/delete%3Ecommit=true
 
 as suggested on some forums. I get a response with status=0 in all cases,
 but none of the above seem to work.
 When I run
 curl http://localhost:9020/solr/core1/select?q=*:*rows=0wt=xml;
 I still get a value for numFound.

 I am currently using solr 4.0 beta version.

 Thanks for your help in advance.
 Regards,
 Rohit

Solr index on Amazon S3

2012-09-05 Thread Nicolas de Saint-Aubert

Hi,

We currently share a single solr read index on an nfs accessed by
various solr instances from various devices which gives us a high
performant cluster framework. We would like to migrate to Amazon or
other cloud. Is there any way (compatibility) to have solr index on
Amazon S3 file cloud system, so that we could access a single index
form various solr as we currently do ?

Thanks for helping !

EdgeNgramTokenFilter and positions

2012-09-05 Thread Walter Underwood

In the analysis page, the n-grams produced by EdgeNgramTokenFilter are at 
sequential positions. This seems wrong, because an n-gram is associated with a 
source token at a specific position. It also really messes up phrase matches.

With the source text fleen, these positions and tokens are generated:

1,fl
2,fle
3,flee
4,fleen

Is this a known bug? Fixed? I'm running 3.3.

wunder
--
Walter Underwood
Search Guy
wun...@chegg.commailto:wun...@chegg.com

Re: Delete all documents in the index

2012-09-05 Thread Rohit Harchandani

Thanks everyone. Adding the _version_ field in the schema worked.
Deleting the data directory works for me, but was not sure why deleting
using curl was not working.

On Wed, Sep 5, 2012 at 1:49 PM, Michael Della Bitta
michael.della.bi...@appinions.com wrote:

Rohit:

If it's easy, the easiest thing to do is to turn off your servlet
container, rm -r * inside of the data directory, and then restart the
container.

Michael Della Bitta

Appinions | 18 East 41st St., Suite 1806 | New York, NY 10017
www.appinions.com
Where Influence Isn’t a Game

On Wed, Sep 5, 2012 at 12:56 PM, Jack Krupansky j...@basetechnology.com
wrote:
Check to make sure that you are not stumbling into SOLR-3432:
deleteByQuery
silently ignored if updateLog is enabled, but {{_version_}} field does
not
exist in schema.

See:
https://issues.apache.org/jira/browse/SOLR-3432

This could happen if you kept the new 4.0 solrconfig.xml, but copied in
your
pre-4.0 schema.xml.

-- Jack Krupansky

-Original Message- From: Rohit Harchandani
Sent: Wednesday, September 05, 2012 12:48 PM
To: solr-user@lucene.apache.org
Subject: Delete all documents in the index

Hi,
I am having difficulty deleting documents from the index using curl. The
urls i tried were:
curl http://localhost:9020/solr/core1/update/?stream.body=
deletequery*:*/query/deletecommit=true
curl http://localhost:9020/solr/core1/update/?commit=true; -H
Content-Type: text/xml --data-binary 'deletequeryid:[* TO
*]/query/delete'
curl http://localhost:9020/solr/core1/update/?commit=true; -H
Content-Type: text/xml --data-binary
'deletequery*:*/query/delete'
I also tried:
curl

http://localhost:9020/solr/core1/update/?stream.body=%3Cdelete%3E%3Cquery%3E*:*%3C/query%3E%3C/delete%3Ecommit=true

as suggested on some forums. I get a response with status=0 in all cases,
but none of the above seem to work.
When I run
curl http://localhost:9020/solr/core1/select?q=*:*rows=0wt=xml;
I still get a value for numFound.

I am currently using solr 4.0 beta version.

Thanks for your help in advance.
Regards,
Rohit

Re: Solr index on Amazon S3

2012-09-05 Thread Michael Della Bitta

Amazon doesn't have a prebuilt network filesystem that's mountable on
multiple hosts out of the box. The closest thing would be setting up
NFS among your hosts yourself, but at that point it'd probably be
easier to set up Solr replication.

Michael Della Bitta


Appinions | 18 East 41st St., Suite 1806 | New York, NY 10017
www.appinions.com
Where Influence Isn’t a Game


On Wed, Sep 5, 2012 at 1:26 PM, Nicolas de Saint-Aubert
dsanico...@gmail.com wrote:
 Hi,

 We currently share a single solr read index on an nfs accessed by
 various solr instances from various devices which gives us a high
 performant cluster framework. We would like to migrate to Amazon or
 other cloud. Is there any way (compatibility) to have solr index on
 Amazon S3 file cloud system, so that we could access a single index
 form various solr as we currently do ?

 Thanks for helping !

Re: Still see document after delete with commit in solr 4.0

That was exactly it. I added the following line to schema.xml and it now works.

field name=_version_ type=long indexed=true stored=true/


On Wed, Sep 5, 2012 at 10:13 AM, Jack Krupansky j...@basetechnology.com wrote:
 Check to make sure that you are not stumbling into SOLR-3432: deleteByQuery
 silently ignored if updateLog is enabled, but {{_version_}} field does not
 exist in schema.

 See:
 https://issues.apache.org/jira/browse/SOLR-3432

 -- Jack Krupansky

 -Original Message- From: Paul
 Sent: Wednesday, September 05, 2012 10:05 AM
 To: solr-user
 Subject: Still see document after delete with commit in solr 4.0


 I've recently upgraded to solr 4.0 from solr 3.5 and I think my delete
 statement used to work, but now it doesn't seem to be deleting. I've
 been experimenting around, and it seems like this should be the URL
 for deleting the document with the uri of network_24.

 In a browser, I first go here:

 http://localhost:8983/solr/MYCORE/update?stream.body=%3Cdelete%3E%3Cquery%3Euri%3Anetwork_24%3C%2Fquery%3E%3C%2Fdelete%3Ecommit=true

 I get this response:

 response
  lst name=responseHeader
int name=status0/int
int name=QTime5/int
  /lst
 /response

 And this is in the log file:

 (timestamp) org.apache.solr.update.DirectUpdateHandler2 commit
 INFO: start
 commit{flags=0,_version_=0,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false}
 (timestamp) org.apache.solr.search.SolrIndexSearcher init
 INFO: Opening Searcher@646dd60e main
 (timestamp) org.apache.solr.update.DirectUpdateHandler2 commit
 INFO: end_commit_flush
 (timestamp) org.apache.solr.core.QuerySenderListener newSearcher
 INFO: QuerySenderListener sending requests to Searcher@646dd60e
 main{StandardDirectoryReader(segments_2v:447 _4p(4.0.0.1):C3244)}
 (timestamp) org.apache.solr.core.QuerySenderListener newSearcher
 INFO: QuerySenderListener done.
 S(timestamp) org.apache.solr.core.SolrCore registerSearcher
 INFO: [MYCORE] Registered new searcher Searcher@646dd60e
 main{StandardDirectoryReader(segments_2v:447 _4p(4.0.0.1):C3244)}
 (timestamp) org.apache.solr.update.processor.LogUpdateProcessor finish
 INFO: [MYCORE] webapp=/solr path=/update
 params={commit=truestream.body=deletequeryuri:network_24/query/delete}
 {deleteByQuery=uri:network_24,commit=} 0 5

 But if I then go to this URL:

 http://localhost:8983/solr/MYCORE/select?q=uri%3Anetwork_24wt=xml

 I get this response:

 response
  lst name=responseHeader
int name=status0/int
int name=QTime1/int
lst name=params
  str name=wtxml/str
  str name=quri:network_24/str
/lst
  /lst
  result name=response numFound=1 start=0
doc
  str name=namenetwork24/str
  str name=urinetwork_24/str
/doc
  /result
 /response

 Why didn't that document disappear?

Re: Solr index on Amazon S3

2012-09-05 Thread Erik Hatcher

Nicolas -

Can you elaborate on your use and configuration of Solr on NFS?What lock 
factory are you using?  (you had to change from the default, right?)

And how are you coordinating updates/commits to the other servers?   Where does 
indexing occur and then how are commits sent to the NFS mounted servers?

Thanks for sharing anything you can about this.

Erik

On Sep 5, 2012, at 13:26 , Nicolas de Saint-Aubert wrote:

 Hi,
 
 We currently share a single solr read index on an nfs accessed by
 various solr instances from various devices which gives us a high
 performant cluster framework. We would like to migrate to Amazon or
 other cloud. Is there any way (compatibility) to have solr index on
 Amazon S3 file cloud system, so that we could access a single index
 form various solr as we currently do ?
 
 Thanks for helping !

Re: Still see document after delete with commit in solr 4.0


: That was exactly it. I added the following line to schema.xml and it now 
works.
: 
: field name=_version_ type=long indexed=true stored=true/

Just to be clear: how exactly did you upgraded to solr 4.0 from solr 3.5 
-- did you throw out your old solrconfig.xml and use the example 
solrconfig.xml from 4.0, but keep your 3.5 schema.xml?  Do you in fact 
have an updateLog ... / in your solrconfig.xml?

(if so: then this is all known as part of SOLR-3432, and won't affect any 
users of 4.0-final -- but i want to be absolutely sure there isn't some 
other edge case of this bug)


-Hoss

Re: Setting up two cores in solr.xml for Solr 4.0


: I don't think I changed by solrconfig.xml file from the default that
: was provided in the example folder for solr 4.0.

ok ... well the Solr 4.0-BETA example solrconfig.xml has this in it...

  dataDir${solr.data.dir:}/dataDir

So if you want to override the dataDir using a property like your second 
example, it should be something like...

   core name=MYCORE_test instanceDir=MYCORE   
 property name=solr.data.dir value=MYCORE_test /
   /core

...the property name used in the solrconfig.xml has to match the property 
name you use when declaring the core, or it won't get used and you'll get 
the default behavior.  solr.data.dir isn't special here -- you could use 
any umber of properties in your solrconfig.xml, and declare them when 
defining your individual cores.

that's very differnet from your other example...

   core name=MYCORE_test instanceDir=MYCORE dataDir=MYCORE_test /

...which doesn't use properties at all, and says this is waht the dataDir 
should be, regardless of what the dataDir.../dataDir looks like in the 
solrconfig.xml


(at least: i'm pretty sure that's how it works)



-Hoss

Re: Still see document after delete with commit in solr 4.0

Actually, I didn't technically upgrade. I downloaded the new
version, grabbed the example, and pasted in the fields from my schema
into the new one. So the only two files I changed from the example are
schema.xml and solr.xml.

Then I reindexed everything from scratch so there was no old index
involved, either.

On Wed, Sep 5, 2012 at 2:42 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:

 : That was exactly it. I added the following line to schema.xml and it now 
 works.
 :
 : field name=_version_ type=long indexed=true stored=true/

 Just to be clear: how exactly did you upgraded to solr 4.0 from solr 3.5
 -- did you throw out your old solrconfig.xml and use the example
 solrconfig.xml from 4.0, but keep your 3.5 schema.xml?  Do you in fact
 have an updateLog ... / in your solrconfig.xml?

 (if so: then this is all known as part of SOLR-3432, and won't affect any
 users of 4.0-final -- but i want to be absolutely sure there isn't some
 other edge case of this bug)


 -Hoss

Re: EdgeNgramTokenFilter and positions

I don't see a Jira for it, but I do see the bad behavior in both Solr 3.6 
and 4.0-BETA in Solr admin analysis.


Interestingly, the screen shot for LUCENE-3642 does in fact show the 
(improperly) incremented positions for successive ngrams.


See:
https://issues.apache.org/jira/browse/LUCENE-3642

I'm surprised that nobody noticed the bogus positions back then.

Technically, this is a Lucene issue.

-- Jack Krupansky

-Original Message- 
From: Walter Underwood

Sent: Wednesday, September 05, 2012 1:51 PM
To: solr-user@lucene.apache.org
Subject: EdgeNgramTokenFilter and positions

In the analysis page, the n-grams produced by EdgeNgramTokenFilter are at 
sequential positions. This seems wrong, because an n-gram is associated with 
a source token at a specific position. It also really messes up phrase 
matches.


With the source text fleen, these positions and tokens are generated:

1,fl
2,fle
3,flee
4,fleen

Is this a known bug? Fixed? I'm running 3.3.

wunder
--
Walter Underwood
Search Guy
wun...@chegg.commailto:wun...@chegg.com

Re: Still see document after delete with commit in solr 4.0

And when you pasted your 3.5 fields into the 4.0 schema, did you delete the 
existing fields (including _version_) at the same time?


-- Jack Krupansky

-Original Message- 
From: Paul

Sent: Wednesday, September 05, 2012 4:32 PM
To: solr-user@lucene.apache.org
Subject: Re: Still see document after delete with commit in solr 4.0

Actually, I didn't technically upgrade. I downloaded the new
version, grabbed the example, and pasted in the fields from my schema
into the new one. So the only two files I changed from the example are
schema.xml and solr.xml.

Then I reindexed everything from scratch so there was no old index
involved, either.

On Wed, Sep 5, 2012 at 2:42 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:


: That was exactly it. I added the following line to schema.xml and it now 
works.

:
: field name=_version_ type=long indexed=true stored=true/

Just to be clear: how exactly did you upgraded to solr 4.0 from solr 3.5
-- did you throw out your old solrconfig.xml and use the example
solrconfig.xml from 4.0, but keep your 3.5 schema.xml?  Do you in fact
have an updateLog ... / in your solrconfig.xml?

(if so: then this is all known as part of SOLR-3432, and won't affect any
users of 4.0-final -- but i want to be absolutely sure there isn't some
other edge case of this bug)


-Hoss

Re: Still see document after delete with commit in solr 4.0


: Actually, I didn't technically upgrade. I downloaded the new
: version, grabbed the example, and pasted in the fields from my schema
: into the new one. So the only two files I changed from the example are
: schema.xml and solr.xml.

ok -- so with the fix for SOLR-3432, anyone who tries similar steps with 
4.0-final will get a clear error on startup -- that was my main concern.  
thanks for clarifying.


-Hoss

Re: use of filter queries in Lucene/Solr Alpha40 and Beta4.0


: Subject: Re: use of filter queries in Lucene/Solr Alpha40 and Beta4.0

Günter, This is definitely strange

The good news is, i can reproduce your problem. 
The bad news is, i can reproduce your problem - and i have no idea what's 
causing it.

I've opened SOLR-3793 to try to get to the bottom of this, and included 
some basic steps to demonstrate the bug using the Solr 4.0-BETA example 
data, but i'm really not sure what the problem might be...

https://issues.apache.org/jira/browse/SOLR-3793


-Hoss

Re: Solr 4.0 BETA Replication problems on Tomcat

2012-09-05 Thread Ravi Solr

The replication finally worked after I removed the compression setting
from the solrconfig.xml on the slave. Thanks for providing the
workaround.

Ravi Kiran

On Wed, Sep 5, 2012 at 10:23 AM, Ravi Solr ravis...@gmail.com wrote:
 Wow, That was quick. Thank you very much Mr. Siren. I shall remove the
 compression node in the solrconfig.xml and let you know how it went.

 Thanks,

 Ravi Kiran Bhaskar

 On Wed, Sep 5, 2012 at 2:54 AM, Sami Siren ssi...@gmail.com wrote:
 I opened SOLR-3789. As a workaround you can remove str
 name=compressioninternal/str from the config and it should work.

 --
  Sami Siren

 On Wed, Sep 5, 2012 at 5:58 AM, Ravi Solr ravis...@gmail.com wrote:
 Hello,
 I have a very simple setup one master and one slave configured
 as below, but replication keeps failing with stacktrace as shown
 below. Note that 3.6 works fine on the same machines so I am thinking
 that Iam missing something in configuration with regards to solr
 4.0...can somebody kindly let me know if Iam missing something ? I am
 running SOLR 4.0 on Tomcat-7.0.29 with Java6. FYI I never has any
 problem with SOLR on glassfish, this is the first time Iam using it on
 Tomcat

 On Master

 requestHandler name=/replication class=solr.ReplicationHandler
  lst name=master
   str name=replicateAftercommit/str
   str name=replicateAfteroptimize/str
   str name=confFilesschema.xml,stopwords.txt,synonyms.txt/str
   str name=commitReserveDuration00:00:10/str
   /lst
 /requestHandler

 On Slave

 requestHandler name=/replication class=solr.ReplicationHandler 
  lst name=slave
 str 
 name=masterUrlhttp://testslave:8080/solr/mycore/replication/str

 str name=pollInterval00:00:50/str
 str name=compressioninternal/str
 str name=httpConnTimeout5000/str
 str name=httpReadTimeout1/str
  /lst
 /requestHandler


 Error

 22:44:10WARNING SnapPuller  Error in fetching packets

 java.util.zip.ZipException: unknown compression method
 at 
 java.util.zip.InflaterInputStream.read(InflaterInputStream.java:147)
 at 
 org.apache.solr.common.util.FastInputStream.readWrappedStream(FastInputStream.java:79)
 at 
 org.apache.solr.common.util.FastInputStream.refill(FastInputStream.java:88)
 at 
 org.apache.solr.common.util.FastInputStream.read(FastInputStream.java:124)
 at 
 org.apache.solr.common.util.FastInputStream.readFully(FastInputStream.java:149)
 at 
 org.apache.solr.common.util.FastInputStream.readFully(FastInputStream.java:144)
 at 
 org.apache.solr.handler.SnapPuller$FileFetcher.fetchPackets(SnapPuller.java:1024)
 at 
 org.apache.solr.handler.SnapPuller$FileFetcher.fetchFile(SnapPuller.java:985)
 at 
 org.apache.solr.handler.SnapPuller.downloadIndexFiles(SnapPuller.java:627)
 at 
 org.apache.solr.handler.SnapPuller.fetchLatestIndex(SnapPuller.java:331)
 at 
 org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:297)
 at org.apache.solr.handler.SnapPuller$1.run(SnapPuller.java:175)
 at 
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
 at 
 java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
 at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
 at 
 java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
 at java.lang.Thread.run(Thread.java:662)

 22:44:10SEVERE  ReplicationHandler  SnapPull failed
 :org.apache.solr.common.SolrException: Unable to download
 _3_Lucene40_0.tip completely. Downloaded 0!=170 at
 org.apache.solr.handler.SnapPuller$FileFetcher.cleanup(SnapPuller.java:1115)
 at 
 org.apache.solr.handler.SnapPuller$FileFetcher.fetchFile(SnapPuller.java:999)
 at 
 org.apache.solr.handler.SnapPuller.downloadIndexFiles(SnapPuller.java:627)
 at org.apache.solr.handler.SnapPuller.fetchLatestIndex(SnapPuller.java:331)
 at 
 org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:297)
 at org.apache.solr.handler.SnapPuller$1.run(SnapPuller.java:175) at
 java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
 at 
 java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
 at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) at

Duplicates in the suggester.

2012-09-05 Thread sharath jagannath

Not sure whether it is a duplicate question. Did try to browse through the
archive and did not find anything specific to what I was looking for.
I see duplicates in the dictionary if I update the document concurrently.

I am using Solr 3.6.1 with the following configurations for suggester:

Solr Config:
   searchComponent name=suggest class=solr.SpellCheckComponent
str name=queryAnalyzerFieldTypetext_auto_suggest/str
lst name=spellchecker
str name=namesuggest/str
str
name=classnameorg.apache.solr.spelling.suggest.Suggester/str
str
name=lookupImplorg.apache.solr.spelling.suggest.tst.TSTLookup/str
str name=fieldname_auto/str
str name=buildOnCommittrue/str
/lst
/searchComponent
requestHandler name=/suggest
class=org.apache.solr.handler.component.SearchHandler
lst name=defaults
str name=spellchecktrue/str
str name=spellcheck.dictionarysuggest/str
str name=spellcheck.count10/str
/lst
arr name=components
strsuggest/str
/arr
/requestHandler

Schema:
fieldType name=text_auto_suggest class=solr.TextField
omitNorms=true
analyzer type=index
tokenizer class=solr.KeywordTokenizerFactory /
!-- tokenizer class=solr.KeywordTokenizerFactory / --
!-- filter class=solr.LowerCaseFilterFactory /  --
filter class=solr.ClassicFilterFactory /
!-- filter class=solr.LengthFilterFactory min=2 / --
/analyzer

analyzer type=query
tokenizer class=solr.KeywordTokenizerFactory /
filter class=solr.LowerCaseFilterFactory /
filter class=solr.TrimFilterFactory /
filter class=solr.ClassicFilterFactory /
!-- filter class=solr.LengthFilterFactory min=2 / --
/analyzer
/fieldType


field name=name_auto type=text_auto_suggest indexed=true
stored=true multiValued=false /

Example text I would be indexing for suggester:
foo_bar %|4%|1%|food

%| - used as a combiner,
Part 1: foo_bar, Name of the entity
Part 2: number of activities(application specific) on the entity.
Part 3: id of the document.
Part 4: food, category of the entity.

As I mentioned earlier, I saw duplicates in the spellcheck index documents
when I updated the concurrently.

arr name=suggestion
strfoo_bar %|4%|1%|food/str
strfoo_bar %|1%|1%|food/str
strfoo_bar %|2%|1%|food/str
strfoo_bar %|3%|1%|food/str
/arr

I do not see duplicates when I update the documents sequentially. I have a
strong doubt this is happening because of the way I am combining multiple
fields using %|.
Would appreciate if somebody could suggest any suitable changes that would
help me with this issue.


-- 
Thanks,
Sharath

Re: Delete all documents in the index

2012-09-05 Thread Mark Mandel

Thanks for posting this!

I ran into exactly this issue yesterday, and ended up felting the files to
get around it.

Mark

Sent from my mobile doohickey.
On Sep 6, 2012 4:13 AM, Rohit Harchandani rhar...@gmail.com wrote:

Thanks everyone. Adding the _version_ field in the schema worked.
Deleting the data directory works for me, but was not sure why deleting
using curl was not working.

On Wed, Sep 5, 2012 at 1:49 PM, Michael Della Bitta
michael.della.bi...@appinions.com wrote:

Rohit:

If it's easy, the easiest thing to do is to turn off your servlet
container, rm -r * inside of the data directory, and then restart the
container.

Michael Della Bitta

Appinions | 18 East 41st St., Suite 1806 | New York, NY 10017
www.appinions.com
Where Influence Isn’t a Game

On Wed, Sep 5, 2012 at 12:56 PM, Jack Krupansky j...@basetechnology.com

wrote:
Check to make sure that you are not stumbling into SOLR-3432:
deleteByQuery
silently ignored if updateLog is enabled, but {{_version_}} field does
not
exist in schema.

See:
https://issues.apache.org/jira/browse/SOLR-3432

This could happen if you kept the new 4.0 solrconfig.xml, but copied in
your
pre-4.0 schema.xml.

-- Jack Krupansky

-Original Message- From: Rohit Harchandani
Sent: Wednesday, September 05, 2012 12:48 PM
To: solr-user@lucene.apache.org
Subject: Delete all documents in the index

Hi,
I am having difficulty deleting documents from the index using curl.
The
urls i tried were:
curl http://localhost:9020/solr/core1/update/?stream.body=
deletequery*:*/query/deletecommit=true
curl http://localhost:9020/solr/core1/update/?commit=true; -H
Content-Type: text/xml --data-binary 'deletequeryid:[* TO
*]/query/delete'
curl http://localhost:9020/solr/core1/update/?commit=true; -H
Content-Type: text/xml --data-binary
'deletequery*:*/query/delete'
I also tried:
curl

http://localhost:9020/solr/core1/update/?stream.body=%3Cdelete%3E%3Cquery%3E*:*%3C/query%3E%3C/delete%3Ecommit=true

as suggested on some forums. I get a response with status=0 in all
cases,
but none of the above seem to work.
When I run
curl http://localhost:9020/solr/core1/select?q=*:*rows=0wt=xml;
I still get a value for numFound.

I am currently using solr 4.0 beta version.

Thanks for your help in advance.
Regards,
Rohit

Solr not allowing persistent HTTP connections

2012-09-05 Thread Aleksey Vorona


Hi,

Running example Solr from the 3.6.1 distribution I can not make it to 
keep persistent HTTP connections:


$ ab -c 1 -n 100 -k 'http://localhost:8983/solr/select?q=*:*' | grep 
Keep-Alive

Keep-Alive requests:0

What should I change to fix that?

P.S. We have the same issue in production with Jetty 7, but I thought it 
would be better to ask about Solr example, since it is easier for anyone 
to reproduce the issue.


-- Aleksey

Re: Solr not allowing persistent HTTP connections

2012-09-05 Thread Aleksey Vorona

Some extra information. If I use curl and force it to use HTTP 1.0, it 
is more visible that Solr doesn't allow persistent connections:


$ curl -v -0 'http://localhost:8983/solr/select?q=*:*' -H'Connection: 
Keep-Alive'* About to connect() to localhost port 8983 (#0)

*   Trying ::1... connected
 GET /solr/select?q=*:* HTTP/1.0
 User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 
OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3

 Host: localhost:8983
 Accept: */*
 Connection: Keep-Alive

 HTTP/1.1 200 OK
 Content-Type: application/xml; charset=UTF-8
* no chunk, no close, no size. Assume close to signal end

?xml version=1.0 encoding=UTF-8?
response
...removed the rest of the response body...

-- Aleksey

On 12-09-05 03:54 PM, Aleksey Vorona wrote:

Hi,

Running example Solr from the 3.6.1 distribution I can not make it to
keep persistent HTTP connections:

$ ab -c 1 -n 100 -k 'http://localhost:8983/solr/select?q=*:*' | grep
Keep-Alive
Keep-Alive requests:0

What should I change to fix that?

P.S. We have the same issue in production with Jetty 7, but I thought it
would be better to ask about Solr example, since it is easier for anyone
to reproduce the issue.

-- Aleksey

Re: Problem with verifying signature ?