Build failed in Hudson: Solr-trunk #717
See http://hudson.zones.apache.org/hudson/job/Solr-trunk/717/changes -- started Building remotely on lucene.zones.apache.org (Solaris 10) ERROR: svn: timed out waiting for server svn: OPTIONS request failed on '/repos/asf/lucene/solr/trunk' org.tmatesoft.svn.core.SVNException: svn: timed out waiting for server svn: OPTIONS request failed on '/repos/asf/lucene/solr/trunk' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:103) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:87) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:601) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:257) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:245) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:454) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:97) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:664) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.testConnection(DAVRepository.java:96) at hudson.scm.SubversionSCM$DescriptorImpl.checkRepositoryPath(SubversionSCM.java:1344) at hudson.scm.SubversionSCM.repositoryLocationsExist(SubversionSCM.java:1410) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:382) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:345) at hudson.model.AbstractProject.checkout(AbstractProject.java:666) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:264) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:238) at hudson.model.Run.run(Run.java:823) at hudson.model.Build.run(Build.java:88) at hudson.model.ResourceController.execute(ResourceController.java:70) at hudson.model.Executor.run(Executor.java:90) Caused by: java.net.SocketTimeoutException: connect timed out at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) at java.net.Socket.connect(Socket.java:519) at org.tmatesoft.svn.core.internal.util.SVNSocketFactory.createPlainSocket(SVNSocketFactory.java:53) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.connect(HTTPConnection.java:167) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:307) ... 17 more Publishing Javadoc Recording test results Publishing Clover coverage report... Publishing Clover coverage results...
[jira] Commented: (SOLR-1010) Relative instanceDir is evaluated relative to current working directory
[
https://issues.apache.org/jira/browse/SOLR-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674221#action_12674221
]
Alexey Serba commented on SOLR-1010:
{quote}
If a relative instanceDir is provided in solr.xml, it should be evaluated
relative to solr.home instead of the current working directory.
{quote}
This is the behavior I expected from solr multicore.
Added my vote.
Relative instanceDir is evaluated relative to current working directory
---
Key: SOLR-1010
URL: https://issues.apache.org/jira/browse/SOLR-1010
Project: Solr
Issue Type: Bug
Affects Versions: 1.3
Reporter: Shalin Shekhar Mangar
Priority: Minor
Fix For: 1.4
If a relative instanceDir is provided in solr.xml, it should be evaluated
relative to solr.home instead of the current working directory.
I guess people work around this bug right now by using absolute paths for
instanceDir.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1022) suggest multiValued for ignored field
suggest multiValued for ignored field - Key: SOLR-1022 URL: https://issues.apache.org/jira/browse/SOLR-1022 Project: Solr Issue Type: Improvement Components: update Affects Versions: 1.3 Environment: Mac OS 10.5 java 1.5 Reporter: Peter Wolanin Priority: Minor Fix For: 1.4 We are sing the suggested ignored field in the schema. I have found, however, that Solr still throws a error 400 if I send in an unmatched multi-valued field. It seems that if I set this ignored field to be multiValued than a document with unrecognized single or multiple value fields is sucessfully indexed. Attached patch alters this suggested item in the schema. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1022) suggest multiValued for ignored field
[ https://issues.apache.org/jira/browse/SOLR-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Wolanin updated SOLR-1022: Attachment: SOLR-1022.patch suggest multiValued for ignored field - Key: SOLR-1022 URL: https://issues.apache.org/jira/browse/SOLR-1022 Project: Solr Issue Type: Improvement Components: update Affects Versions: 1.3 Environment: Mac OS 10.5 java 1.5 Reporter: Peter Wolanin Priority: Minor Fix For: 1.4 Attachments: SOLR-1022.patch Original Estimate: 1h Remaining Estimate: 1h We are sing the suggested ignored field in the schema. I have found, however, that Solr still throws a error 400 if I send in an unmatched multi-valued field. It seems that if I set this ignored field to be multiValued than a document with unrecognized single or multiple value fields is sucessfully indexed. Attached patch alters this suggested item in the schema. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1022) suggest multiValued for ignored field
[ https://issues.apache.org/jira/browse/SOLR-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Wolanin updated SOLR-1022: Description: We are actually using the suggested ignored field in the schema. I have found, however, that Solr still throws a error 400 if I send in an unmatched multi-valued field. It seems that if I set this ignored field to be multiValued than a document with unrecognized single or multiple value fields is sucessfully indexed. Attached patch alters this suggested item in the schema. was: We are sing the suggested ignored field in the schema. I have found, however, that Solr still throws a error 400 if I send in an unmatched multi-valued field. It seems that if I set this ignored field to be multiValued than a document with unrecognized single or multiple value fields is sucessfully indexed. Attached patch alters this suggested item in the schema. suggest multiValued for ignored field - Key: SOLR-1022 URL: https://issues.apache.org/jira/browse/SOLR-1022 Project: Solr Issue Type: Improvement Components: update Affects Versions: 1.3 Environment: Mac OS 10.5 java 1.5 Reporter: Peter Wolanin Priority: Minor Fix For: 1.4 Attachments: SOLR-1022.patch Original Estimate: 1h Remaining Estimate: 1h We are actually using the suggested ignored field in the schema. I have found, however, that Solr still throws a error 400 if I send in an unmatched multi-valued field. It seems that if I set this ignored field to be multiValued than a document with unrecognized single or multiple value fields is sucessfully indexed. Attached patch alters this suggested item in the schema. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-977) version=2.2 is not necessary for wt=javabin
[ https://issues.apache.org/jira/browse/SOLR-977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-977. Resolution: Fixed Committed revision 745392. version=2.2 is not necessary for wt=javabin --- Key: SOLR-977 URL: https://issues.apache.org/jira/browse/SOLR-977 Project: Solr Issue Type: Improvement Components: clients - java Reporter: Noble Paul Assignee: Shalin Shekhar Mangar Priority: Trivial Fix For: 1.4 Attachments: SOLR-977.patch CommonsHttpSolrServer can drop the version=2.2 if the wt=javabin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-921) SolrResourceLoader must cache short name vs fully qualified name
[ https://issues.apache.org/jira/browse/SOLR-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-921: --- Summary: SolrResourceLoader must cache short name vs fully qualified name (was: SolrResourceLoader must cache name vs class) SolrResourceLoader must cache short name vs fully qualified name Key: SOLR-921 URL: https://issues.apache.org/jira/browse/SOLR-921 Project: Solr Issue Type: Improvement Reporter: Noble Paul Assignee: Shalin Shekhar Mangar Fix For: 1.4 Attachments: SOLR-921.patch, SOLR-921.patch, SOLR-921.patch, SOLR-921.patch every class that is loaded through SolrResourceLoader does a Class.forName() and when if it is not found a ClassNotFoundExcepton is thrown Then , it looks up with the various packages and finds the right class if the name starts with solr. Considering the fact that we usually use this solr.classname format we pay too much of a price for this. After every lookup the result can be cached in a MapString,Class and can be shared across all the cores and this Map can be stored at the CoreContainer level -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-921) SolrResourceLoader must cache short name vs fully qualified name
[ https://issues.apache.org/jira/browse/SOLR-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-921: --- Description: every class that is loaded through SolrResourceLoader does a Class.forName() and when if it is not found a ClassNotFoundExcepton is thrown Then , it looks up with the various packages and finds the right class if the name starts with solr. Considering the fact that we usually use this solr.classname format we pay too much of a price for this. After every lookup the result can be cached in a static MapString, String with short name as keys and fully qualified name as values and can be shared across all the cores and this Map can be stored at the CoreContainer level. was: every class that is loaded through SolrResourceLoader does a Class.forName() and when if it is not found a ClassNotFoundExcepton is thrown Then , it looks up with the various packages and finds the right class if the name starts with solr. Considering the fact that we usually use this solr.classname format we pay too much of a price for this. After every lookup the result can be cached in a MapString,Class and can be shared across all the cores and this Map can be stored at the CoreContainer level SolrResourceLoader must cache short name vs fully qualified name Key: SOLR-921 URL: https://issues.apache.org/jira/browse/SOLR-921 Project: Solr Issue Type: Improvement Reporter: Noble Paul Assignee: Shalin Shekhar Mangar Fix For: 1.4 Attachments: SOLR-921.patch, SOLR-921.patch, SOLR-921.patch, SOLR-921.patch every class that is loaded through SolrResourceLoader does a Class.forName() and when if it is not found a ClassNotFoundExcepton is thrown Then , it looks up with the various packages and finds the right class if the name starts with solr. Considering the fact that we usually use this solr.classname format we pay too much of a price for this. After every lookup the result can be cached in a static MapString, String with short name as keys and fully qualified name as values and can be shared across all the cores and this Map can be stored at the CoreContainer level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-921) SolrResourceLoader must cache short name vs fully qualified name
[ https://issues.apache.org/jira/browse/SOLR-921?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-921. Resolution: Fixed Committed revision 745394. Thanks Noble and Hoss! SolrResourceLoader must cache short name vs fully qualified name Key: SOLR-921 URL: https://issues.apache.org/jira/browse/SOLR-921 Project: Solr Issue Type: Improvement Reporter: Noble Paul Assignee: Shalin Shekhar Mangar Fix For: 1.4 Attachments: SOLR-921.patch, SOLR-921.patch, SOLR-921.patch, SOLR-921.patch every class that is loaded through SolrResourceLoader does a Class.forName() and when if it is not found a ClassNotFoundExcepton is thrown Then , it looks up with the various packages and finds the right class if the name starts with solr. Considering the fact that we usually use this solr.classname format we pay too much of a price for this. After every lookup the result can be cached in a static MapString, String with short name as keys and fully qualified name as values and can be shared across all the cores and this Map can be stored at the CoreContainer level. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1004) Optimizing the abort command in delta import
[
https://issues.apache.org/jira/browse/SOLR-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-1004:
Attachment: SOLR-1004.patch
Changes
# Check for abort in nextModifiedRow detection
# Check for abort in nextDeletedRow
# Check in doDelta
# Check getModifiedParentRowKey
Marc, can you see the patch to ensure all your changes got in?
Optimizing the abort command in delta import
Key: SOLR-1004
URL: https://issues.apache.org/jira/browse/SOLR-1004
Project: Solr
Issue Type: Improvement
Components: contrib - DataImportHandler
Affects Versions: 1.3
Environment: Java - Lucene - Solr - DataImportHandler
Reporter: Marc Sturlese
Assignee: Shalin Shekhar Mangar
Priority: Minor
Fix For: 1.4
Attachments: SOLR-1004.patch
Original Estimate: 0.5h
Remaining Estimate: 0.5h
I have seen that when abort command is called in a deltaImport, in
DocBuilder.java, at doDelta functions it's just checked for abortion at the
begining of collectDelta, after that function and at the end of collectDelta.
The problem I have found is that if there is a big number of documents to
modify and abort is called in the middle of delta collection, it will not
take effect until all data is collected.
Same happens when we start deleteting or updating documents. In updating
case, there is an abortion check inside buildDocument but, as it is called
inside a while for all docs to update, it will keep going throw all docs of
the bucle and skipping them.
I propose to do an abortion check inside every loop of data collection and
after calling build document in doDelta function.
In the case of modifing documents, the code in DocBuilder.java would look
like:
while (pkIter.hasNext()) {
MapString, Object map = pkIter.next();
vri.addNamespace(DataConfig.IMPORTER_NS + .delta, map);
buildDocument(vri, null, map, root, true, null);
pkIter.remove();
//check if abortion
if (stop.get())
{
allPks = null ;
pkIter = null ;
return;
}
}
In the case of document deletion (deleteAll function in DocBuilder): Just
if (stop.get()){ break ; } at the end of every loop and call this just
after deleteAll is called (in doDelta)
if (stop.get())
{
allPks = null;
deletedKeys = null;
return;
}
Finally in collect delta:
while (true) {
//check for abortion
if (stop.get()){ return myModifiedPks; }
MapString, Object row = entityProcessor.nextModifiedRowKey();
if (row == null)
break;
...
And the same for delete-query collection and parent-delta-query collection
I didn't atach de patch because is the first time I open an issue and don't
know if you want to code it as I do. Just wanted to explain the idea and how
I solved, I think it can be useful for other users.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-844) A SolrServer impl to front-end multiple urls
[
https://issues.apache.org/jira/browse/SOLR-844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674498#action_12674498
]
Shalin Shekhar Mangar commented on SOLR-844:
Hoss, did you get a chance to see the latest patch?
A SolrServer impl to front-end multiple urls
Key: SOLR-844
URL: https://issues.apache.org/jira/browse/SOLR-844
Project: Solr
Issue Type: New Feature
Components: clients - java
Affects Versions: 1.3
Reporter: Noble Paul
Assignee: Shalin Shekhar Mangar
Fix For: 1.4
Attachments: SOLR-844.patch, SOLR-844.patch, SOLR-844.patch,
SOLR-844.patch, SOLR-844.patch
Currently a {{CommonsHttpSolrServer}} can talk to only one server. This
demands that the user have a LoadBalancer or do the roundrobin on their own.
We must have a {{LBHttpSolrServer}} which must automatically do a
Loadbalancing between multiple hosts. This can be backed by the
{{CommonsHttpSolrServer}}
This can have the following other features
* Automatic failover
* Optionally take in a file /url containing the the urls of servers so that
the server list can be automatically updated by periodically loading the
config
* Support for adding removing servers during runtime
* Pluggable Loadbalancing mechanism. (round-robin, weighted round-robin,
random etc)
* Pluggable Failover mechanisms
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-993) VariableResolverImpl addNamespace overwrites entire namespace instead of adding
[ https://issues.apache.org/jira/browse/SOLR-993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674497#action_12674497 ] Shalin Shekhar Mangar commented on SOLR-993: Jared, did you get a chance to see the latest patch? VariableResolverImpl addNamespace overwrites entire namespace instead of adding --- Key: SOLR-993 URL: https://issues.apache.org/jira/browse/SOLR-993 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 1.4 Reporter: Jared Flatow Assignee: Shalin Shekhar Mangar Fix For: 1.4 Attachments: SOLR-993.patch, SOLR-993.patch, SOLR-993b.patch, SOLR-993c.patch, SOLR-993c.patch, SOLR-993c.patch Original Estimate: 0.08h Remaining Estimate: 0.08h The addNamespace method in VariableResolverImpl does not so much add the namespace as overwrite it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1022) suggest multiValued for ignored field
[ https://issues.apache.org/jira/browse/SOLR-1022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674507#action_12674507 ] Otis Gospodnetic commented on SOLR-1022: I must have missed some releated thread on the ML... but can you explan what you mean by an unmatched multi-valued field? And what does ignored field mean? Thanks. suggest multiValued for ignored field - Key: SOLR-1022 URL: https://issues.apache.org/jira/browse/SOLR-1022 Project: Solr Issue Type: Improvement Components: update Affects Versions: 1.3 Environment: Mac OS 10.5 java 1.5 Reporter: Peter Wolanin Priority: Minor Fix For: 1.4 Attachments: SOLR-1022.patch Original Estimate: 1h Remaining Estimate: 1h We are actually using the suggested ignored field in the schema. I have found, however, that Solr still throws a error 400 if I send in an unmatched multi-valued field. It seems that if I set this ignored field to be multiValued than a document with unrecognized single or multiple value fields is sucessfully indexed. Attached patch alters this suggested item in the schema. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
