Build failed in Hudson: Solr-Nightly #227
See http://lucene.zones.apache.org:8080/hudson/job/Solr-Nightly/227/changes -- [...truncated 1000 lines...] AUclient/ruby/solr-ruby/test/unit/data_mapper_test.rb AUclient/ruby/solr-ruby/test/unit/util_test.rb A client/ruby/solr-ruby/test/functional A client/ruby/solr-ruby/test/functional/test_solr_server.rb A client/ruby/solr-ruby/test/functional/server_test.rb A client/ruby/solr-ruby/test/conf AUclient/ruby/solr-ruby/test/conf/schema.xml A client/ruby/solr-ruby/test/conf/protwords.txt A client/ruby/solr-ruby/test/conf/stopwords.txt AUclient/ruby/solr-ruby/test/conf/solrconfig.xml A client/ruby/solr-ruby/test/conf/scripts.conf A client/ruby/solr-ruby/test/conf/admin-extra.html A client/ruby/solr-ruby/test/conf/synonyms.txt A client/ruby/solr-ruby/LICENSE.txt A client/ruby/solr-ruby/Rakefile A client/ruby/solr-ruby/script AUclient/ruby/solr-ruby/script/setup.rb AUclient/ruby/solr-ruby/script/solrshell A client/ruby/solr-ruby/lib A client/ruby/solr-ruby/lib/solr AUclient/ruby/solr-ruby/lib/solr/util.rb A client/ruby/solr-ruby/lib/solr/document.rb A client/ruby/solr-ruby/lib/solr/exception.rb AUclient/ruby/solr-ruby/lib/solr/indexer.rb AUclient/ruby/solr-ruby/lib/solr/response.rb AUclient/ruby/solr-ruby/lib/solr/connection.rb A client/ruby/solr-ruby/lib/solr/importer AUclient/ruby/solr-ruby/lib/solr/importer/delimited_file_source.rb AUclient/ruby/solr-ruby/lib/solr/importer/solr_source.rb AUclient/ruby/solr-ruby/lib/solr/importer/array_mapper.rb AUclient/ruby/solr-ruby/lib/solr/importer/mapper.rb AUclient/ruby/solr-ruby/lib/solr/importer/xpath_mapper.rb A client/ruby/solr-ruby/lib/solr/importer/hpricot_mapper.rb A client/ruby/solr-ruby/lib/solr/xml.rb AUclient/ruby/solr-ruby/lib/solr/importer.rb A client/ruby/solr-ruby/lib/solr/field.rb AUclient/ruby/solr-ruby/lib/solr/solrtasks.rb A client/ruby/solr-ruby/lib/solr/request A client/ruby/solr-ruby/lib/solr/request/ping.rb A client/ruby/solr-ruby/lib/solr/request/spellcheck.rb A client/ruby/solr-ruby/lib/solr/request/select.rb AUclient/ruby/solr-ruby/lib/solr/request/optimize.rb AUclient/ruby/solr-ruby/lib/solr/request/standard.rb A client/ruby/solr-ruby/lib/solr/request/delete.rb AUclient/ruby/solr-ruby/lib/solr/request/index_info.rb A client/ruby/solr-ruby/lib/solr/request/update.rb A client/ruby/solr-ruby/lib/solr/request/dismax.rb AUclient/ruby/solr-ruby/lib/solr/request/modify_document.rb A client/ruby/solr-ruby/lib/solr/request/add_document.rb A client/ruby/solr-ruby/lib/solr/request/commit.rb A client/ruby/solr-ruby/lib/solr/request/base.rb AUclient/ruby/solr-ruby/lib/solr/request.rb A client/ruby/solr-ruby/lib/solr/response A client/ruby/solr-ruby/lib/solr/response/ping.rb A client/ruby/solr-ruby/lib/solr/response/spellcheck.rb AUclient/ruby/solr-ruby/lib/solr/response/select.rb AUclient/ruby/solr-ruby/lib/solr/response/optimize.rb A client/ruby/solr-ruby/lib/solr/response/standard.rb A client/ruby/solr-ruby/lib/solr/response/xml.rb A client/ruby/solr-ruby/lib/solr/response/ruby.rb A client/ruby/solr-ruby/lib/solr/response/delete.rb AUclient/ruby/solr-ruby/lib/solr/response/index_info.rb A client/ruby/solr-ruby/lib/solr/response/dismax.rb AUclient/ruby/solr-ruby/lib/solr/response/modify_document.rb A client/ruby/solr-ruby/lib/solr/response/add_document.rb A client/ruby/solr-ruby/lib/solr/response/commit.rb A client/ruby/solr-ruby/lib/solr/response/base.rb AUclient/ruby/solr-ruby/lib/solr.rb A client/ruby/solr-ruby/CHANGES.yml A client/ruby/solr-ruby/README A client/ruby/solr-ruby/examples A client/ruby/solr-ruby/examples/marc AUclient/ruby/solr-ruby/examples/marc/marc_importer.rb A client/ruby/solr-ruby/examples/delicious_library A client/ruby/solr-ruby/examples/delicious_library/sample_export.txt AUclient/ruby/solr-ruby/examples/delicious_library/dl_importer.rb A client/ruby/solr-ruby/examples/tang AUclient/ruby/solr-ruby/examples/tang/tang_importer.rb U At revision 583741 no change for http://svn.apache.org/repos/asf/lucene/solr/trunk since the previous build [trunk] $ /export/home/hudson/tools/ant/apache-ant-1.6.5/bin/ant -Dversion=$BUILD_ID -Dtest.junit.output.format=xml nightly Buildfile: build.xml init-forrest-entities: [mkdir] Created dir: http://lucene.zones.apache.org:8080/hudson/job/Solr-Nightly/ws/trunk/build compile-common: [mkdir] Created dir: http://lucene.zones.ap
[jira] Updated: (SOLR-370) Add a STX stream transform update handler
[ https://issues.apache.org/jira/browse/SOLR-370?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Peuss updated SOLR-370: -- Attachment: StxUpdateRequestHandler.patch Some minor fixes (I was using a deprecated class) and some extra logging. > Add a STX stream transform update handler > - > > Key: SOLR-370 > URL: https://issues.apache.org/jira/browse/SOLR-370 > Project: Solr > Issue Type: New Feature > Components: update >Affects Versions: 1.3 >Reporter: Thomas Peuss >Priority: Minor > Attachments: example-stx.zip, joost-20070718-bin.zip, > StxUpdateRequestHandler.patch, StxUpdateRequestHandler.patch > > > Here is a patch that adds a STX stream transform update handler. This allows > to feed custom XML formats to Solr. It is based on the STX transformation > engine Joost (http://joost.sourceforge.net/). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-378) Increase connectionTimeout so SolrExampleTest doesn't timeout when trying to connect to SolrServer instance
Increase connectionTimeout so SolrExampleTest doesn't timeout when trying to connect to SolrServer instance --- Key: SOLR-378 URL: https://issues.apache.org/jira/browse/SOLR-378 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 1.3 Environment: Nightly build box Reporter: Yousef Ourabi Priority: Trivial Fix For: 1.3 The SolrExampleJettyTest is timing out, the default timeout on the SolrServer instance is set to 5. The attached patch adds a system property to the junit task (build.xml line 395) that increases this to 30, and also tweaks line 72 of SolrExampleJettyTest to read the system property. http://lucene.zones.apache.org:8080/hudson/job/Solr-Nightly/ws/trunk/build/test-results/TEST-org.apache.solr.client.solrj.embedded.SolrExampleJettyTest.xml Thanks, Yousef Ourabi -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-378) Increase connectionTimeout so SolrExampleTest doesn't timeout when trying to connect to SolrServer instance
[ https://issues.apache.org/jira/browse/SOLR-378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yousef Ourabi updated SOLR-378: --- Attachment: build.patch Patch for build.xml and org.apache.solr.client.solrj.SolrExampleTests > Increase connectionTimeout so SolrExampleTest doesn't timeout when trying to > connect to SolrServer instance > --- > > Key: SOLR-378 > URL: https://issues.apache.org/jira/browse/SOLR-378 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 1.3 > Environment: Nightly build box >Reporter: Yousef Ourabi >Priority: Trivial > Fix For: 1.3 > > Attachments: build.patch > > > The SolrExampleJettyTest is timing out, the default timeout on the SolrServer > instance is set to 5. The attached patch adds a system property to the junit > task (build.xml line 395) that increases this to 30, and also tweaks line 72 > of SolrExampleJettyTest to read the system property. > http://lucene.zones.apache.org:8080/hudson/job/Solr-Nightly/ws/trunk/build/test-results/TEST-org.apache.solr.client.solrj.embedded.SolrExampleJettyTest.xml > Thanks, > Yousef Ourabi -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
RE: Solr nightly build failure
https://issues.apache.org/jira/browse/SOLR-378 I created a quick and dirty patch that adds a sysproperty to the junit task, and tweaked SolrExampleJettyTest Per Yonik's law of patches of course, so if there is a better way, just let me know and I'll tweak the patch. Thanks. Yousef -Original Message- From: Chris Hostetter [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 10, 2007 4:30 PM To: solr-dev@lucene.apache.org Subject: Re: Solr nightly build failure : For the jetty based tests, perhaps we should just give a warning if it tries : to bind a port and can't -- in that case the tests are not called, but we : still have them for the normal dev case where we can bind the port. according to the hudson failure logs,the problem hasn't been binding to the port (as in: the server starting up) it's the client not being able to onnect to the port in 5ms. (at least: that's hte cause of hte last 6 failures) given that these tests are running on a virtual server with *lots* of other virtual servers, it doesn't seem that odd that it might take 5ms before the connection is initialized i seem to recall some discussion about increasing that timeout, and deciding that it was a bad idea because in the "normal" case it's usually short, but at the very least lets make it a config option or something so the test can specify a large value. (it doesn't even have to be an easy to chnge config option, it could even be a system property for now, just so we can try chaning it in the nightly build environment and see if it makes things better. i'd rather not kill a "good" test just because it fails in some situations -- that tells me that either the test or the code being tested doesn't handle that situation very well. if the test isn't waiting long enough for the server to start up before sending requests, then we should fix the test -- if the client isn't waiting long enough fortheserver to connect, we should improve the client. -Hoss
Deprecations and SolrConfig patch
The SolrConfig patch changed the interface for creating a token
filter factory:
@Deprecated
public void init(Map args) {
log.warning("calling the deprecated form of init; should be
calling init(SolrConfig solrConfig, Map args)");
this.args=args;
}
The analyzer creation chain now calls public void init(SolrConfig
solrConfig, Map args) instead.
This is very bad from a backward compatibility point of view. For
most extensions, their analyzers will just stop working in mysterious
ways (since they will not get the correct parameters). The above log
WARNING will not be generated, because that method is not called by
Solr. The only hint that something is amiss is
[javac] Note: XXFilterFactor.java uses or overrides a deprecated
API.
which should not be an indication that the code in question will not
function correctly. Also, there isn't a peep of warning in CHANGES.txt
The problem seems to stem from leaving in the old method. Since we
are breaking backward compatibility, it would be better to break hard
and prevent Solr from compiling, or to actually provide backward
compatiblity.
grumpy,
-Mike
[jira] Commented: (SOLR-303) Federated Search over HTTP
[ https://issues.apache.org/jira/browse/SOLR-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534213 ] Stu Hood commented on SOLR-303: --- I really like where you are headed with the 'componentized' version of the patch: it much more elegant. But: I'm still having the problem where multi-valued fields only get one value returned. During AuxiliaryQPhaseComponent.merge(SolrQueryResponse rsp, SolrQueryResponse auxPhaseRes), you check whether the field already exists before adding it, but multi-value fields can exist multiple times. Also, I'm considering disabling the AuxiliaryQPhase and just letting the MainQPhase fetch the document fields. All of my documents are small ( < 1k on average with 10ish fields), so I think making another call across the network to fetch the remaining fields is probably a waste for our indexes. What do you think? Thanks! > Federated Search over HTTP > -- > > Key: SOLR-303 > URL: https://issues.apache.org/jira/browse/SOLR-303 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Sharad Agarwal >Priority: Minor > Attachments: fedsearch.patch, fedsearch.patch, fedsearch.patch, > fedsearch.patch, fedsearch.stu.patch, fedsearch.stu.patch > > > Motivated by http://wiki.apache.org/solr/FederatedSearch > "Index view consistency between multiple requests" requirement is relaxed in > this implementation. > Does the federated search query side. Update not yet done. > Tries to achieve:- > > - The client applications are totally agnostic to federated search. The > federated search and merging of results are totally behind the scene in Solr > in request handler . Response format remains the same after merging of > results. > The response from individual shard is deserialized into SolrQueryResponse > object. The collection of SolrQueryResponse objects are merged to produce a > single SolrQueryResponse object. This enables to use the Response writers as > it is; or with minimal change. > - Efficient query processing with highlighting and fields getting generated > only for merged documents. The query is executed in 2 phases. First phase > gets the doc unique keys with sort criteria. Second phase brings all > requested fields and highlighting information. This saves lot of CPU in case > there are good number of shards and highlighting info is requested. > Should be easy to customize the query execution. For example: user can > specify to execute query in just 1 phase itself. (For some queries when > highlighting info is not required and number of fields requested are small; > this can be more efficient.) > - Ability to easily overwrite the default Federated capability by appropriate > plugins and request parameters. As federated search is performed by the > RequestHandler itself, multiple request handlers can easily be pre-configured > with different federated search settings in solrconfig.xml > - Global weight calculation is done by querying the terms' doc frequencies > from all shards. > - Federated search works on Http transport. So individual shard's VIP can be > queried. Load-balancing and Fail-over taken care by VIP as usual. > -Sub-searcher response parsing as a plugin interface. Different > implementation could be written based on JSON, xml SAX etc. Current one based > on XML DOM. > HOW: > --- > A new RequestHandler called MultiSearchRequestHandler does the federated > search on multiple sub-searchers, (referred as "shards" going forward). It > extends the RequestHandlerBase. handleRequestBody method in > RequestHandlerBase has been divided into query building and execute methods. > This has been done to calculate global numDocs and docFreqs; and execute the > query efficiently on multiple shards. > All the "search" request handlers are expected to extend > MultiSearchRequestHandler class in order to enable federated capability for > the handler. StandardRequestHandler and DisMaxRequestHandler have been > changed to extend this class. > > The federated search kicks in if "shards" is present in the request > parameter. Otherwise search is performed as usual on the local index. eg. > shards=local,host1:port1,host2:port2 will search on the local index and 2 > remote indexes. The search response from all 3 shards are merged and serviced > back to the client. > The search request processing on the set of shards is performed as follows: > STEP 1: The query is built, terms are extracted. Global numDocs and docFreqs > are calculated by requesting all the shards and adding up numDocs and > docFreqs from each shard. > STEP 2: (FirstQueryPhase) All shards are queried. Global numDocs and docFreqs > are passed as request parameters. All document fields are NOT requested, only > document uniqFields and sort fields are
