[jira] Created: (SOLR-1143) Return partial results when a connection to a shard is refused
Return partial results when a connection to a shard is refused -- Key: SOLR-1143 URL: https://issues.apache.org/jira/browse/SOLR-1143 Project: Solr Issue Type: Improvement Components: search Reporter: Nicolas Dessaigne If any shard is down in a distributed search, a ConnectException it thrown. Here's a little patch that change this behaviour: if we can't connect to a shard (ConnectException), we get partial results from the active shards. As for TimeOut parameter (https://issues.apache.org/jira/browse/SOLR-502), we set the parameter partialResults at true. This patch also adresses a problem expressed in the mailing list about a year ago (http://www.nabble.com/partialResults,-distributed-search---SOLR-502-td19002610.html) We have a use case that needs this behaviour and we would like to know your thougths about such a behaviour? Should it be the default behaviour for distributed search? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1143) Return partial results when a connection to a shard is refused
[ https://issues.apache.org/jira/browse/SOLR-1143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Dessaigne updated SOLR-1143: Attachment: SOLR-1143.patch Return partial results when a connection to a shard is refused -- Key: SOLR-1143 URL: https://issues.apache.org/jira/browse/SOLR-1143 Project: Solr Issue Type: Improvement Components: search Reporter: Nicolas Dessaigne Attachments: SOLR-1143.patch If any shard is down in a distributed search, a ConnectException it thrown. Here's a little patch that change this behaviour: if we can't connect to a shard (ConnectException), we get partial results from the active shards. As for TimeOut parameter (https://issues.apache.org/jira/browse/SOLR-502), we set the parameter partialResults at true. This patch also adresses a problem expressed in the mailing list about a year ago (http://www.nabble.com/partialResults,-distributed-search---SOLR-502-td19002610.html) We have a use case that needs this behaviour and we would like to know your thougths about such a behaviour? Should it be the default behaviour for distributed search? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-929) error in admin interface for dynamicField name=* type=ignored
[
https://issues.apache.org/jira/browse/SOLR-929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi reassigned SOLR-929:
---
Assignee: Koji Sekiguchi
error in admin interface for dynamicField name=* type=ignored
-
Key: SOLR-929
URL: https://issues.apache.org/jira/browse/SOLR-929
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 1.3
Environment: java version 1.5.0_16, Mac OS 10.5.5, Jetty example
server. Also see the same bug on linux with tomcat.
Reporter: Peter Wolanin
Assignee: Koji Sekiguchi
Priority: Minor
Fix For: 1.4
Attachments: schema.xml, SOLR-929.patch, Solr-admin-page.jpg
There appears to be an error in the admin interface (/solr/admin/schema.jsp)
when using a '*' field in a schema. In the example
schema.xml, there is a commented out sample:
{code}
!-- uncomment the following to ignore any fields that don't
already match an existing
field name or dynamic field, rather than reporting them as an error.
alternately, change the type=ignored to some other type e.g.
text if you want
unknown fields indexed and/or stored by default --
!--dynamicField name=* type=ignored /--
{code}
We have this un-commented, and in the schema browser via the admin interface
I see that all non-dynamic fields get a type of ignored.
for example, I see this in the Solr admin interface:
Field: uid
Dynamically Created From Pattern: *
Field Type: ignored
though the field definition is:
{code}
field name=uid type=integer indexed=true stored=true/
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1138) Query Elevation Component should gracefully handle empty queries
[
https://issues.apache.org/jira/browse/SOLR-1138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12705559#action_12705559
]
Grant Ingersoll commented on SOLR-1138:
---
Committed revision 771268.
Query Elevation Component should gracefully handle empty queries
Key: SOLR-1138
URL: https://issues.apache.org/jira/browse/SOLR-1138
Project: Solr
Issue Type: Bug
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
Attachments: SOLR-1138.patch
From http://www.lucidimagination.com/search/document/3b50cd3506952f7 :
{quote}
In the QueryElevComponent (QEC) it currently throws an exception if
the input Query is null (line 329).Additionally, I've seen cases
where it's possible that the Query is not null (q is not set, but
q.alt is *:*), but the rb.getQueryString() is null, which causes an
NPE on line 300 or so.
I'd like to suggest that if the Query is empty/null, the QEC should
just go on it's merry way as if there is nothing to do. I don't think
a lack of query means that the QEC is improperly configured, as the
exception message implies:
The QueryElevationComponent needs to be registered 'after' the query
component
We should be making sure the QEC is properly registered during
initialization time.
Thoughts?
-Grant{quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-929) error in admin interface for dynamicField name=* type=ignored
[
https://issues.apache.org/jira/browse/SOLR-929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Koji Sekiguchi resolved SOLR-929.
-
Resolution: Fixed
Committed revision 771270.
error in admin interface for dynamicField name=* type=ignored
-
Key: SOLR-929
URL: https://issues.apache.org/jira/browse/SOLR-929
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 1.3
Environment: java version 1.5.0_16, Mac OS 10.5.5, Jetty example
server. Also see the same bug on linux with tomcat.
Reporter: Peter Wolanin
Assignee: Koji Sekiguchi
Priority: Minor
Fix For: 1.4
Attachments: schema.xml, SOLR-929.patch, Solr-admin-page.jpg
There appears to be an error in the admin interface (/solr/admin/schema.jsp)
when using a '*' field in a schema. In the example
schema.xml, there is a commented out sample:
{code}
!-- uncomment the following to ignore any fields that don't
already match an existing
field name or dynamic field, rather than reporting them as an error.
alternately, change the type=ignored to some other type e.g.
text if you want
unknown fields indexed and/or stored by default --
!--dynamicField name=* type=ignored /--
{code}
We have this un-commented, and in the schema browser via the admin interface
I see that all non-dynamic fields get a type of ignored.
for example, I see this in the Solr admin interface:
Field: uid
Dynamically Created From Pattern: *
Field Type: ignored
though the field definition is:
{code}
field name=uid type=integer indexed=true stored=true/
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1141) NullPointException during creating snapshot
[
https://issues.apache.org/jira/browse/SOLR-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-1141:
Attachment: SOLR-1141.patch
Changes
# Replaced usage of ReplicationHandler.closeNoExp with IOUtils.closeQuietly
# Added statistics for Snapshooter -- displays start time, end time and number
of file in last snapshot
NullPointException during creating snapshot
---
Key: SOLR-1141
URL: https://issues.apache.org/jira/browse/SOLR-1141
Project: Solr
Issue Type: Bug
Components: replication (java)
Affects Versions: 1.3
Reporter: Noble Paul
Assignee: Shalin Shekhar Mangar
Fix For: 1.4
Attachments: SOLR-1141.patch, SOLR-1141.patch, SOLR-1141.patch
If there is no new document added since the last snapshot is created, the
request solr/replication?command=snapshoot
a NPE is thrown
{code:xml}
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeader
int name=status0/int
int name=QTime8/int
/lst
str
name=exceptionjava.lang.NullPointerException:java.lang.NullPointerException/str
/response
{code}
mail thread: http://markmail.org/thread/kthwzs7kgd3ino5t
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1141) NullPointException during creating snapshot
[
https://issues.apache.org/jira/browse/SOLR-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar resolved SOLR-1141.
-
Resolution: Fixed
Committed revision 771378.
I also removed the custom file copy method with FileUtils.copyFileToDirectory
method.
NullPointException during creating snapshot
---
Key: SOLR-1141
URL: https://issues.apache.org/jira/browse/SOLR-1141
Project: Solr
Issue Type: Bug
Components: replication (java)
Affects Versions: 1.3
Reporter: Noble Paul
Assignee: Shalin Shekhar Mangar
Fix For: 1.4
Attachments: SOLR-1141.patch, SOLR-1141.patch, SOLR-1141.patch
If there is no new document added since the last snapshot is created, the
request solr/replication?command=snapshoot
a NPE is thrown
{code:xml}
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeader
int name=status0/int
int name=QTime8/int
/lst
str
name=exceptionjava.lang.NullPointerException:java.lang.NullPointerException/str
/response
{code}
mail thread: http://markmail.org/thread/kthwzs7kgd3ino5t
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1141) Fix NPE during creating snapshot and clean up code
[
https://issues.apache.org/jira/browse/SOLR-1141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar updated SOLR-1141:
Summary: Fix NPE during creating snapshot and clean up code (was:
NullPointException during creating snapshot)
Editing the name of the issue because it has many more changes rather than just
a NPE fix.
Fix NPE during creating snapshot and clean up code
--
Key: SOLR-1141
URL: https://issues.apache.org/jira/browse/SOLR-1141
Project: Solr
Issue Type: Bug
Components: replication (java)
Affects Versions: 1.3
Reporter: Noble Paul
Assignee: Shalin Shekhar Mangar
Fix For: 1.4
Attachments: SOLR-1141.patch, SOLR-1141.patch, SOLR-1141.patch
If there is no new document added since the last snapshot is created, the
request solr/replication?command=snapshoot
a NPE is thrown
{code:xml}
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeader
int name=status0/int
int name=QTime8/int
/lst
str
name=exceptionjava.lang.NullPointerException:java.lang.NullPointerException/str
/response
{code}
mail thread: http://markmail.org/thread/kthwzs7kgd3ino5t
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1144) replication hang
replication hang Key: SOLR-1144 URL: https://issues.apache.org/jira/browse/SOLR-1144 Project: Solr Issue Type: Bug Reporter: Yonik Seeley It seems that replication can sometimes hang. http://www.lucidimagination.com/search/document/403305a3fda18599 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1145) Patch to set IndexWriter.defaultInfoStream from solr.xml
Patch to set IndexWriter.defaultInfoStream from solr.xml Key: SOLR-1145 URL: https://issues.apache.org/jira/browse/SOLR-1145 Project: Solr Issue Type: Improvement Reporter: Chris Harris Lucene IndexWriters use an infoStream to log detailed info about indexing operations for debugging purpose. This patch is an extremely simple way to allow logging this info to a file from within Solr: After applying the patch, set the new defaultInfoStreamFilePath attribute of the solr element in solr.xml to the path of the file where you'd like to save the logging information. Note that, in a multi-core setup, all cores will end up logging to the same infoStream log file. This may not be desired. (But it does justify putting the setting in solr.xml rather than solrconfig.xml.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1145) Patch to set IndexWriter.defaultInfoStream from solr.xml
[ https://issues.apache.org/jira/browse/SOLR-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Harris updated SOLR-1145: --- Attachment: SOLR-1145.patch Patch to set IndexWriter.defaultInfoStream from solr.xml Key: SOLR-1145 URL: https://issues.apache.org/jira/browse/SOLR-1145 Project: Solr Issue Type: Improvement Reporter: Chris Harris Attachments: SOLR-1145.patch Lucene IndexWriters use an infoStream to log detailed info about indexing operations for debugging purpose. This patch is an extremely simple way to allow logging this info to a file from within Solr: After applying the patch, set the new defaultInfoStreamFilePath attribute of the solr element in solr.xml to the path of the file where you'd like to save the logging information. Note that, in a multi-core setup, all cores will end up logging to the same infoStream log file. This may not be desired. (But it does justify putting the setting in solr.xml rather than solrconfig.xml.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1144) replication hang
[ https://issues.apache.org/jira/browse/SOLR-1144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12705891#action_12705891 ] Noble Paul commented on SOLR-1144: -- isn't this same as SOLR-1096 ? replication hang Key: SOLR-1144 URL: https://issues.apache.org/jira/browse/SOLR-1144 Project: Solr Issue Type: Bug Reporter: Yonik Seeley It seems that replication can sometimes hang. http://www.lucidimagination.com/search/document/403305a3fda18599 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1146) DIH ConcurrentModificationException in getStatus
DIH ConcurrentModificationException in getStatus Key: SOLR-1146 URL: https://issues.apache.org/jira/browse/SOLR-1146 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Reporter: Noble Paul Priority: Minor Fix For: 1.4 the status messages map is not synchronized. see mail thread: http://markmail.org/thread/2m5akintzvxc2utf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1146) DIH ConcurrentModificationException in getStatus
[ https://issues.apache.org/jira/browse/SOLR-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1146: - Attachment: SOLR-1146.patch DIH ConcurrentModificationException in getStatus Key: SOLR-1146 URL: https://issues.apache.org/jira/browse/SOLR-1146 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Reporter: Noble Paul Priority: Minor Fix For: 1.4 Attachments: SOLR-1146.patch the status messages map is not synchronized. see mail thread: http://markmail.org/thread/2m5akintzvxc2utf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
