[jira] Created: (SOLR-1176) slowness when use elevate
slowness when use elevate - Key: SOLR-1176 URL: https://issues.apache.org/jira/browse/SOLR-1176 Project: Solr Issue Type: Improvement Components: search Affects Versions: 1.3 Reporter: realx.lu When I use the elevation component ,system cost much memory and slow. the elevation component maintains a FieldCache entry for id, to translate docid to uniqueKey to do a HashMap lookup. The HashMap lookup could be the cause of a little slowness, but the main culprit is probably the memory used by the FieldCache entry. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (SOLR-1106) Pluggable CoreAdminHandler (Action ) architecture that allows for custom handler access to CoreContainer / request-response
[ https://issues.apache.org/jira/browse/SOLR-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar reopened SOLR-1106: - It seems that the call to core.setProperties was removed in this refactoring and therefore, implicit properties are not being set on cores created through CoreAdminHandler. Pluggable CoreAdminHandler (Action ) architecture that allows for custom handler access to CoreContainer / request-response - Key: SOLR-1106 URL: https://issues.apache.org/jira/browse/SOLR-1106 Project: Solr Issue Type: New Feature Components: search Environment: Java 5, Tomcat 6 Reporter: Kay Kay Assignee: Shalin Shekhar Mangar Fix For: 1.4 Attachments: SOLR-1106.patch, SOLR-1106.patch, SOLR-1106.patch, SOLR-1106.patch, SOLR-1106.patch Original Estimate: 3h Remaining Estimate: 3h Currently there are certain default actions implemented in CoreAdminHandler ( CREATE , SWAP, RELOAD , ALIAS etc.) . For the purpose of in-house monitoring tools that needs to interact with multiple cores at a given solr instance - we need custom handlers that has access to CoreContainer and the req, resp of the same. So - the proposed way of injecting handlers is as follows. In solr.xml - we add a new schema - solr cores adminPath=/cores/admin adminActionHandler action=newaction handlerType=com.mydomain.myclass / /cores /solr New abstract class - CoreAdminActionRequestHandler added - that com.mydomain.myclass would need to inherit from. Following action handlers registered by default - registerCustomAdminHandler(create, new AdminCreateActionRequestHandler()); registerCustomAdminHandler(rename, new AdminRenameActionRequestHandler()); registerCustomAdminHandler(alias, new AdminAliasActionRequestHandler()); registerCustomAdminHandler(unload, new AdminUnloadActionRequestHandler()); registerCustomAdminHandler(status, new AdminStatusActionRequestHandler()); registerCustomAdminHandler(persist, new AdminPersistActionRequestHandler()); registerCustomAdminHandler(reload, new AdminReloadActionRequestHandler()); registerCustomAdminHandler(swap, new AdminSwapActionRequestHandler()); Trying to register a handler with one that already exists would result in an error ( Hence - the above mentioned defaults would not be overridden). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-883) Cores created through Admin do not have the implicit properties set
[ https://issues.apache.org/jira/browse/SOLR-883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-883: Attachment: SOLR-883.patch this got removed somehow Cores created through Admin do not have the implicit properties set --- Key: SOLR-883 URL: https://issues.apache.org/jira/browse/SOLR-883 Project: Solr Issue Type: Bug Reporter: Noble Paul Assignee: Shalin Shekhar Mangar Fix For: 1.4 Attachments: SOLR-883.patch, SOLR-883.patch When a core is present in the solr.xml , the core has all the implicit properties set. But when it is created through the REST API. It is not set -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (SOLR-883) Cores created through Admin do not have the implicit properties set
[ https://issues.apache.org/jira/browse/SOLR-883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reopened SOLR-883: - SOLR-943 removed the fix Cores created through Admin do not have the implicit properties set --- Key: SOLR-883 URL: https://issues.apache.org/jira/browse/SOLR-883 Project: Solr Issue Type: Bug Reporter: Noble Paul Assignee: Shalin Shekhar Mangar Fix For: 1.4 Attachments: SOLR-883.patch, SOLR-883.patch When a core is present in the solr.xml , the core has all the implicit properties set. But when it is created through the REST API. It is not set -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-883) Cores created through Admin do not have the implicit properties set
[ https://issues.apache.org/jira/browse/SOLR-883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul reassigned SOLR-883: --- Assignee: Noble Paul (was: Shalin Shekhar Mangar) Cores created through Admin do not have the implicit properties set --- Key: SOLR-883 URL: https://issues.apache.org/jira/browse/SOLR-883 Project: Solr Issue Type: Bug Reporter: Noble Paul Assignee: Noble Paul Fix For: 1.4 Attachments: SOLR-883.patch, SOLR-883.patch When a core is present in the solr.xml , the core has all the implicit properties set. But when it is created through the REST API. It is not set -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1106) Pluggable CoreAdminHandler (Action ) architecture that allows for custom handler access to CoreContainer / request-response
[ https://issues.apache.org/jira/browse/SOLR-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-1106. - Resolution: Fixed Oops, wrong call. That call was actually removed by SOLR-943. Pluggable CoreAdminHandler (Action ) architecture that allows for custom handler access to CoreContainer / request-response - Key: SOLR-1106 URL: https://issues.apache.org/jira/browse/SOLR-1106 Project: Solr Issue Type: New Feature Components: search Environment: Java 5, Tomcat 6 Reporter: Kay Kay Assignee: Shalin Shekhar Mangar Fix For: 1.4 Attachments: SOLR-1106.patch, SOLR-1106.patch, SOLR-1106.patch, SOLR-1106.patch, SOLR-1106.patch Original Estimate: 3h Remaining Estimate: 3h Currently there are certain default actions implemented in CoreAdminHandler ( CREATE , SWAP, RELOAD , ALIAS etc.) . For the purpose of in-house monitoring tools that needs to interact with multiple cores at a given solr instance - we need custom handlers that has access to CoreContainer and the req, resp of the same. So - the proposed way of injecting handlers is as follows. In solr.xml - we add a new schema - solr cores adminPath=/cores/admin adminActionHandler action=newaction handlerType=com.mydomain.myclass / /cores /solr New abstract class - CoreAdminActionRequestHandler added - that com.mydomain.myclass would need to inherit from. Following action handlers registered by default - registerCustomAdminHandler(create, new AdminCreateActionRequestHandler()); registerCustomAdminHandler(rename, new AdminRenameActionRequestHandler()); registerCustomAdminHandler(alias, new AdminAliasActionRequestHandler()); registerCustomAdminHandler(unload, new AdminUnloadActionRequestHandler()); registerCustomAdminHandler(status, new AdminStatusActionRequestHandler()); registerCustomAdminHandler(persist, new AdminPersistActionRequestHandler()); registerCustomAdminHandler(reload, new AdminReloadActionRequestHandler()); registerCustomAdminHandler(swap, new AdminSwapActionRequestHandler()); Trying to register a handler with one that already exists would result in an error ( Hence - the above mentioned defaults would not be overridden). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-883) Cores created through Admin do not have the implicit properties set
[ https://issues.apache.org/jira/browse/SOLR-883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-883. - Resolution: Fixed committed revision 776578 Cores created through Admin do not have the implicit properties set --- Key: SOLR-883 URL: https://issues.apache.org/jira/browse/SOLR-883 Project: Solr Issue Type: Bug Reporter: Noble Paul Assignee: Noble Paul Fix For: 1.4 Attachments: SOLR-883.patch, SOLR-883.patch When a core is present in the solr.xml , the core has all the implicit properties set. But when it is created through the REST API. It is not set -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1170) Java replication replicates lucene lock file
[ https://issues.apache.org/jira/browse/SOLR-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711034#action_12711034 ] Noble Paul commented on SOLR-1170: -- even if the lock is present it can be removed if the attribute mainIndex/unlockOnStartup is present in the solrconfig.xml. But if it does not get removed automatically there could be a problem Java replication replicates lucene lock file Key: SOLR-1170 URL: https://issues.apache.org/jira/browse/SOLR-1170 Project: Solr Issue Type: Bug Components: replication (java) Affects Versions: 1.4 Environment: linux Reporter: Bryan Talbot Assignee: Noble Paul Priority: Minor Attachments: SOLR-1170.patch When using solr 1.4 replication, I see that the lucene-write.lock file is being replicated to slaves. I'm importing data from a db every 5 minutes using cron to trigger a DIH delta-import. Replication polls every 60 seconds and the master is configured to take a snapshot (replicateAfter) commit. Why should the lock file be replicated to slaves? The lock file isn't stale on the master and is absent unless the delta-import is in process. I've not tried it yet, but with the lock file replicated, it seems like promotion of a slave to a master in a failure recovery scenario requires the manual removal of the lock file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1123) Change the JSONResponseWriter content type
[ https://issues.apache.org/jira/browse/SOLR-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-1123: Affects Version/s: (was: 1.3) Fix Version/s: (was: 1.3.1) 1.5 Marking for 1.5 I'm -0 on this. I'm not sure if this inconvenience is big enough to warrant adding a request parameter. I'll let others decide this one. Change the JSONResponseWriter content type -- Key: SOLR-1123 URL: https://issues.apache.org/jira/browse/SOLR-1123 Project: Solr Issue Type: Improvement Reporter: Uri Boness Fix For: 1.5 Attachments: JSON_contentType_incl_tests.patch Currently the jSON content type is not used. Instead the palin/text content type is used. The reason for this as I understand is to enable viewing the json response as as text in the browser. While this is valid argument, I do believe that there should at least be an option to configure this writer to use the JSON content type. According to [RFC4627|http://www.ietf.org/rfc/rfc4627.txt] the json content type needs to be application/json (and not text/x-json). The reason this can be very helpful is that today you have plugins for browsers (e.g. [JSONView|http://brh.numbera.com/software/jsonview]) that can render any page with application/json content type in a user friendly manner (just like xml is supported). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1123) Change the JSONResponseWriter content type
[
https://issues.apache.org/jira/browse/SOLR-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711075#action_12711075
]
Uri Boness commented on SOLR-1123:
--
Indeed this is just for convenience and should not be in a high priority, but I
definitely see it as a nice to have one. Just to clarify, the suggestion is not
to have another request parameter (that would probably be too much as you
mentioned) but instead add a configuration parameter in solrconfig. So you'll
be able to define the json response writer as follows:
{code:xml}
queryResponseWriter name=json
class=org.apache.solr.request.JSONResponseWriter
bool name=useJsonContentTypetrue/bool
/queryResponseWriter
{code}
Change the JSONResponseWriter content type
--
Key: SOLR-1123
URL: https://issues.apache.org/jira/browse/SOLR-1123
Project: Solr
Issue Type: Improvement
Reporter: Uri Boness
Fix For: 1.5
Attachments: JSON_contentType_incl_tests.patch
Currently the jSON content type is not used. Instead the palin/text content
type is used. The reason for this as I understand is to enable viewing the
json response as as text in the browser. While this is valid argument, I do
believe that there should at least be an option to configure this writer to
use the JSON content type. According to
[RFC4627|http://www.ietf.org/rfc/rfc4627.txt] the json content type needs to
be application/json (and not text/x-json). The reason this can be very
helpful is that today you have plugins for browsers (e.g.
[JSONView|http://brh.numbera.com/software/jsonview]) that can render any page
with application/json content type in a user friendly manner (just like xml
is supported).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1116) Add a Binary FieldType
[ https://issues.apache.org/jira/browse/SOLR-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711081#action_12711081 ] Andrzej Bialecki commented on SOLR-1116: - bq. No browser accepts the image data as Base64. your front-end will have to read the string and send it out as a byte[]. Please see http://en.wikipedia.org/wiki/Data_URI_scheme - this is the use case I was referring to, and indeed you can send base64 encoded content directly to any modern browser. Add a Binary FieldType -- Key: SOLR-1116 URL: https://issues.apache.org/jira/browse/SOLR-1116 Project: Solr Issue Type: New Feature Components: search Affects Versions: 1.3 Reporter: Noble Paul Assignee: Noble Paul Fix For: 1.4 Attachments: SOLR-1116.patch, SOLR-1116.patch Lucene supports binary data for field but Solr has no corresponding field type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1116) Add a Binary FieldType
[ https://issues.apache.org/jira/browse/SOLR-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711087#action_12711087 ] Noble Paul commented on SOLR-1116: -- silly me :) Add a Binary FieldType -- Key: SOLR-1116 URL: https://issues.apache.org/jira/browse/SOLR-1116 Project: Solr Issue Type: New Feature Components: search Affects Versions: 1.3 Reporter: Noble Paul Assignee: Noble Paul Fix For: 1.4 Attachments: SOLR-1116.patch, SOLR-1116.patch Lucene supports binary data for field but Solr has no corresponding field type. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1123) Change the JSONResponseWriter content type
[ https://issues.apache.org/jira/browse/SOLR-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711122#action_12711122 ] Yonik Seeley commented on SOLR-1123: Is there perhaps a more general feature we could turn this into? An expert level ability or parameter to set a custom content-type? Change the JSONResponseWriter content type -- Key: SOLR-1123 URL: https://issues.apache.org/jira/browse/SOLR-1123 Project: Solr Issue Type: Improvement Reporter: Uri Boness Fix For: 1.5 Attachments: JSON_contentType_incl_tests.patch Currently the jSON content type is not used. Instead the palin/text content type is used. The reason for this as I understand is to enable viewing the json response as as text in the browser. While this is valid argument, I do believe that there should at least be an option to configure this writer to use the JSON content type. According to [RFC4627|http://www.ietf.org/rfc/rfc4627.txt] the json content type needs to be application/json (and not text/x-json). The reason this can be very helpful is that today you have plugins for browsers (e.g. [JSONView|http://brh.numbera.com/software/jsonview]) that can render any page with application/json content type in a user friendly manner (just like xml is supported). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1123) Change the JSONResponseWriter content type
[
https://issues.apache.org/jira/browse/SOLR-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711133#action_12711133
]
Uri Boness commented on SOLR-1123:
--
I think that would be the best option. The problem right now is in the current
class hierarchy of the response writers. Basically, I think the
QueryResponseWriter interface should change to:
{code}
public interface QueryResponseWriter extends NamedListInitializedPlugin {
public void write(OutputStream out, SolrQueryRequest request,
SolrQueryResponse response) throws IOException;
public String getContentType(SolrQueryRequest request, SolrQueryResponse
response);
}
{code}
Note: this interface will play nicer with the binary response writer
Then we can have an AbstractTextResponseWriter which will serve as a parent for
all non-binary response writers:
{code}
public abstract class AbstractTextResponseWriter extends
NamedListInitializedPlugin {
public final static String CONTENT_TYPE_PARAM = contentType;
public static String DEFAULT_CONTENT_TYPE=text/plain; charset=UTF-8;
private final String contentType;
protected AbstractTextResponseWriter() {
this(DEFAULT_CONTENT_TYPE);
}
protected AbstractTextResponseWriter(String defaultContentType) {
this.contentType = defaultContentType;
}
public void init(NamedList args) {
String configuredContentType = (String) args.get(CONTENT_TYPE_PARAM);
if (configuredContentType != null) {
contentType = configuredContentType;;
}
}
public String getContentType(SolrQueryRequest request, SolrQueryResponse
response) {
return contentType;
}
public final void write(OutputStream out, SolrQueryRequest request,
SolrQueryResponse response) throws IOException {
OutputStreamWriter writer = new OutputStreamWriter(out, UTF-8);
write(writer, request, response);
}
protected abstract void write(Writer writer, SolrQueryRequest request,
SolrQueryResponse response) throws IOException;
}
{code}
This will make it easy for every response writer to define its default content
type, yet it will still allow to override this default using the contentType
parameter in solrconfig. (I assume here that there's no need to customize the
content type for the binary response writer as it's internal and specific for
the current implementation).
Change the JSONResponseWriter content type
--
Key: SOLR-1123
URL: https://issues.apache.org/jira/browse/SOLR-1123
Project: Solr
Issue Type: Improvement
Reporter: Uri Boness
Fix For: 1.5
Attachments: JSON_contentType_incl_tests.patch
Currently the jSON content type is not used. Instead the palin/text content
type is used. The reason for this as I understand is to enable viewing the
json response as as text in the browser. While this is valid argument, I do
believe that there should at least be an option to configure this writer to
use the JSON content type. According to
[RFC4627|http://www.ietf.org/rfc/rfc4627.txt] the json content type needs to
be application/json (and not text/x-json). The reason this can be very
helpful is that today you have plugins for browsers (e.g.
[JSONView|http://brh.numbera.com/software/jsonview]) that can render any page
with application/json content type in a user friendly manner (just like xml
is supported).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1123) Change the JSONResponseWriter content type
[ https://issues.apache.org/jira/browse/SOLR-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711136#action_12711136 ] Shalin Shekhar Mangar commented on SOLR-1123: - Or we could just add a request parameter and SolrDispatchFilter can set the value of the param if it is present. Change the JSONResponseWriter content type -- Key: SOLR-1123 URL: https://issues.apache.org/jira/browse/SOLR-1123 Project: Solr Issue Type: Improvement Reporter: Uri Boness Fix For: 1.5 Attachments: JSON_contentType_incl_tests.patch Currently the jSON content type is not used. Instead the palin/text content type is used. The reason for this as I understand is to enable viewing the json response as as text in the browser. While this is valid argument, I do believe that there should at least be an option to configure this writer to use the JSON content type. According to [RFC4627|http://www.ietf.org/rfc/rfc4627.txt] the json content type needs to be application/json (and not text/x-json). The reason this can be very helpful is that today you have plugins for browsers (e.g. [JSONView|http://brh.numbera.com/software/jsonview]) that can render any page with application/json content type in a user friendly manner (just like xml is supported). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-1123) Change the JSONResponseWriter content type
[ https://issues.apache.org/jira/browse/SOLR-1123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711136#action_12711136 ] Shalin Shekhar Mangar edited comment on SOLR-1123 at 5/20/09 6:17 AM: -- Or we could just add a request parameter and SolrDispatchFilter can set the value of the param as the content type. was (Author: shalinmangar): Or we could just add a request parameter and SolrDispatchFilter can set the value of the param if it is present. Change the JSONResponseWriter content type -- Key: SOLR-1123 URL: https://issues.apache.org/jira/browse/SOLR-1123 Project: Solr Issue Type: Improvement Reporter: Uri Boness Fix For: 1.5 Attachments: JSON_contentType_incl_tests.patch Currently the jSON content type is not used. Instead the palin/text content type is used. The reason for this as I understand is to enable viewing the json response as as text in the browser. While this is valid argument, I do believe that there should at least be an option to configure this writer to use the JSON content type. According to [RFC4627|http://www.ietf.org/rfc/rfc4627.txt] the json content type needs to be application/json (and not text/x-json). The reason this can be very helpful is that today you have plugins for browsers (e.g. [JSONView|http://brh.numbera.com/software/jsonview]) that can render any page with application/json content type in a user friendly manner (just like xml is supported). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-769) Support Document and Search Result clustering
[ https://issues.apache.org/jira/browse/SOLR-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711137#action_12711137 ] Grant Ingersoll commented on SOLR-769: -- Committed revision 776692. Support Document and Search Result clustering - Key: SOLR-769 URL: https://issues.apache.org/jira/browse/SOLR-769 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Assignee: Grant Ingersoll Priority: Minor Fix For: 1.4 Attachments: clustering-libs.tar, clustering-libs.tar, SOLR-769-lib.zip, SOLR-769.patch, SOLR-769.patch, SOLR-769.patch, SOLR-769.patch, SOLR-769.patch, SOLR-769.patch, SOLR-769.patch, SOLR-769.patch, SOLR-769.patch, SOLR-769.patch, SOLR-769.patch, SOLR-769.tar, SOLR-769.zip Clustering is a useful tool for working with documents and search results, similar to the notion of dynamic faceting. Carrot2 (http://project.carrot2.org/) is a nice, BSD-licensed, library for doing search results clustering. Mahout (http://lucene.apache.org/mahout) is well suited for whole-corpus clustering. The patch I lays out a contrib module that starts off w/ an integration of a SearchComponent for doing clustering and an implementation using Carrot. In search results mode, it will use the DocList as the input for the cluster. While Carrot2 comes w/ a Solr input component, it is not the same as the SearchComponent that I have in that the Carrot example actually submits a query to Solr, whereas my SearchComponent is just chained into the Component list and uses the ResponseBuilder to add in the cluster results. While not fully fleshed out yet, the collection based mode will take in a list of ids or just use the whole collection and will produce clusters. Since this is a longer, typically offline task, there will need to be some type of storage mechanism (and replication??) for the clusters. I _may_ push this off to a separate JIRA issue, but I at least want to present the use case as part of the design of this component/contrib. It may even make sense that we split this out, such that the building piece is something like an UpdateProcessor and then the SearchComponent just acts as a lookup mechanism. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-769) Support Document and Search Result clustering
[ https://issues.apache.org/jira/browse/SOLR-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711137#action_12711137 ] Grant Ingersoll edited comment on SOLR-769 at 5/20/09 6:42 AM: --- Committed revision 776692. Thanks to everyone who helped out, especially Carrot2 creators Dawid and Stanislaw. was (Author: gsingers): Committed revision 776692. Support Document and Search Result clustering - Key: SOLR-769 URL: https://issues.apache.org/jira/browse/SOLR-769 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Assignee: Grant Ingersoll Priority: Minor Fix For: 1.4 Attachments: clustering-libs.tar, clustering-libs.tar, SOLR-769-lib.zip, SOLR-769.patch, SOLR-769.patch, SOLR-769.patch, SOLR-769.patch, SOLR-769.patch, SOLR-769.patch, SOLR-769.patch, SOLR-769.patch, SOLR-769.patch, SOLR-769.patch, SOLR-769.patch, SOLR-769.tar, SOLR-769.zip Clustering is a useful tool for working with documents and search results, similar to the notion of dynamic faceting. Carrot2 (http://project.carrot2.org/) is a nice, BSD-licensed, library for doing search results clustering. Mahout (http://lucene.apache.org/mahout) is well suited for whole-corpus clustering. The patch I lays out a contrib module that starts off w/ an integration of a SearchComponent for doing clustering and an implementation using Carrot. In search results mode, it will use the DocList as the input for the cluster. While Carrot2 comes w/ a Solr input component, it is not the same as the SearchComponent that I have in that the Carrot example actually submits a query to Solr, whereas my SearchComponent is just chained into the Component list and uses the ResponseBuilder to add in the cluster results. While not fully fleshed out yet, the collection based mode will take in a list of ids or just use the whole collection and will produce clusters. Since this is a longer, typically offline task, there will need to be some type of storage mechanism (and replication??) for the clusters. I _may_ push this off to a separate JIRA issue, but I at least want to present the use case as part of the design of this component/contrib. It may even make sense that we split this out, such that the building piece is something like an UpdateProcessor and then the SearchComponent just acts as a lookup mechanism. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Help Writing a Distributed Component
Matt, Perhaps you can post your patch even in it's current state on a JIRA issue and then we can work through it? Also, how are you configuring your shards? I started that Wiki page as a way to make sure I understood what was going on in distributed. I'm not 100% sure it is correct, so it would be good if others review/edit as well. -Grant On May 20, 2009, at 1:36 AM, Matt Weber wrote: Hi all, I am working on a patch to get TermsComponent distributed and have run into a problem. I have overridden the prepare, process, modifyRequest, handleResponses, and finishStage methods as described at http://wiki.apache.org/solr/WritingDistributedSearchComponents. My problem is that only the prepare and process methods are called just as if it was non-distributed. It looks like the shards parameter is not being honored for this handler. For some reason rb.shards is always null. I looked though all the other distributed components code (facets, stats, highlighting, etc) and did not notice them doing anything special that my handler is not. Is there some setting I need to enable for the shards parameter to be honored?
[jira] Updated: (SOLR-1147) Updating configuration files through HTTP
[
https://issues.apache.org/jira/browse/SOLR-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Pastorino updated SOLR-1147:
Description:
*Current behaviour* :
If one wants to update a configuration file placed in Solr's conf dir, direct
edition of the file is mandatory. Currently the process is :
# Replace the concerned configuration file in Solr's conf dir
# Commit.
A commit triggers a reload of the configurations files, as long as their
associated components are registered to this event. This can be achieved for a
searchComponent as follows :
{noformat}
str name=refreshOnCommmittrue/str
{noformat}
_Side question : how to register other types of components to the commit event
?_
*Use case* :
As a system using Solr, i would find handy to be able to push an updated
configuration file through HTTP.
This would remove the currently mandatory requirement of having a direct access
to configuration files, allowing more distributed architectures. This would
also increase the components' added value by making them dynamic,
configuration-wise.
*Possible design* :
A new requestHandler, taking as parameter :
* the name of the file to update
* optionnally if a backup of the previous version of the file is to be done (
cf replicationHandler )
*Open questions* :
* Should reloading the new configuration keep using the reload on commit
feature ?
was:
If one wants to update the configuration file for the QueryElevationComponent,
direct edition of the file is mandatory. Currently the process seems to be :
# Replace elevate.xml in Solr's dataDir
# Commit. It appears that when having elevate.xml in Solr's dataDir, and solely
in this case, commiting triggers a reload of elevate.xml. This does not happen
when elevate.xml is stored in Solr's conf dir.
As a system using Solr, i would find handy to be able to push an updated
elevate.xml file/XML through HTTP, with an automatic reload of it. This would
remove the currently mandatory requirement of having a direct access to the
elevate.xml file, allowing more distributed architectures. This would also
increase the Query Elevation system's added value by making it dynamic,
configuration-wise.
Summary: Updating configuration files through HTTP (was:
QueryElevationComponent : updating elevate.xml through HTTP)
Updating configuration files through HTTP
-
Key: SOLR-1147
URL: https://issues.apache.org/jira/browse/SOLR-1147
Project: Solr
Issue Type: Improvement
Affects Versions: 1.3, 1.4, 1.5
Environment: Any
Reporter: Nicolas Pastorino
Priority: Minor
Attachments: QueryElevationAdministrationRequestHandler.java,
QueryElevationAdministrationRequestHandler.java
*Current behaviour* :
If one wants to update a configuration file placed in Solr's conf dir, direct
edition of the file is mandatory. Currently the process is :
# Replace the concerned configuration file in Solr's conf dir
# Commit.
A commit triggers a reload of the configurations files, as long as their
associated components are registered to this event. This can be achieved for
a searchComponent as follows :
{noformat}
str name=refreshOnCommmittrue/str
{noformat}
_Side question : how to register other types of components to the commit
event ?_
*Use case* :
As a system using Solr, i would find handy to be able to push an updated
configuration file through HTTP.
This would remove the currently mandatory requirement of having a direct
access to configuration files, allowing more distributed architectures. This
would also increase the components' added value by making them dynamic,
configuration-wise.
*Possible design* :
A new requestHandler, taking as parameter :
* the name of the file to update
* optionnally if a backup of the previous version of the file is to be done (
cf replicationHandler )
*Open questions* :
* Should reloading the new configuration keep using the reload on commit
feature ?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Help Writing a Distributed Component
On May 20, 2009, at 12:07 PM, Matt Weber wrote: Hey Grant, I have opened a new ticket with the current version of my patch at https://issues.apache.org/jira/browse/SOLR-1177 . What do you mean by configuring my shards? I implemented the distributed methods (prepare, process, modifyRequest, etc) as is done in the other distributed components, then I just specify a shards parameter in the query. I looked though the other distributed components and did not see them doing any special shard configuration other than modifying the query that is sent to the shards. I must be missing something, but I can't seem to figure out due to my lack of knowledge on distributed components and the solr codebase in general. Thanks for your help! No, nothing special. Just wanted to make sure your query had a shards parameter in it (or configured in the solrconfig defaults). Basically, I was assuming nothing. I'll take a look at the patch, hopefully tonight or tomorrow morning.
Re: Compile error from new contrib clustering?
Hmm, checking. I know it spit out warnings on that stuff, but didn't think it would cause an error. On May 20, 2009, at 12:21 PM, Eric Pugh wrote: Hi all, Anyone else getting a compile error from the new contrib/clustering stuff? On OSX with Java 1.5: budapest:asf_solr_src epugh$ java -version java version 1.5.0_16 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16- b06-284) Java HotSpot(TM) Client VM (build 1.5.0_16-133, mixed mode, sharing) I am getting: compile: [javac] Compiling 7 source files to /trunk/asf_solr_src/contrib/ clustering/build/classes [javac] An exception has occurred in the compiler (1.5.0_16). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport ) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. [javac] com.sun.tools.javac.code.Symbol$CompletionFailure: file org/simpleframework/xml/Root.class not found Eric - Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com Free/Busy: http://tinyurl.com/eric-cal -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using Solr/Lucene: http://www.lucidimagination.com/search
Re: Help Writing a Distributed Component
Hey Grant, I have opened a new ticket with the current version of my patch at https://issues.apache.org/jira/browse/SOLR-1177 . What do you mean by configuring my shards? I implemented the distributed methods (prepare, process, modifyRequest, etc) as is done in the other distributed components, then I just specify a shards parameter in the query. I looked though the other distributed components and did not see them doing any special shard configuration other than modifying the query that is sent to the shards. I must be missing something, but I can't seem to figure out due to my lack of knowledge on distributed components and the solr codebase in general. Thanks for your help! For my testing, I have 2 instances of Solr running in tomcat called solr1 and solr2. My test query looks like: http://localhost:8080/solr1/terms?shards=localhost:8080/solr1,localhost:8080/solr2terms=trueterms.fl=spellterms.prefix=fterms.lower=f Thanks, Matt Weber eSr Technologies http://www.esr-technologies.com On May 20, 2009, at 7:24 AM, Grant Ingersoll wrote: Matt, Perhaps you can post your patch even in it's current state on a JIRA issue and then we can work through it? Also, how are you configuring your shards? I started that Wiki page as a way to make sure I understood what was going on in distributed. I'm not 100% sure it is correct, so it would be good if others review/edit as well. -Grant On May 20, 2009, at 1:36 AM, Matt Weber wrote: Hi all, I am working on a patch to get TermsComponent distributed and have run into a problem. I have overridden the prepare, process, modifyRequest, handleResponses, and finishStage methods as described at http://wiki.apache.org/solr/WritingDistributedSearchComponents . My problem is that only the prepare and process methods are called just as if it was non-distributed. It looks like the shards parameter is not being honored for this handler. For some reason rb.shards is always null. I looked though all the other distributed components code (facets, stats, highlighting, etc) and did not notice them doing anything special that my handler is not. Is there some setting I need to enable for the shards parameter to be honored?
[jira] Updated: (SOLR-1177) Distributed TermsComponent
[ https://issues.apache.org/jira/browse/SOLR-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Weber updated SOLR-1177: - Attachment: SOLR-1177.patch Here is my first attempt at a patch that is not currently working. For some reason only the prepare and process methods are being called. It seems that the shards parameter is not being honored like it is in the other distributed components because rb.shards is always null. I have looked at the other distributed components and did not notice them doing anything special with the shards parameter. I have based this code on the information from http://wiki.apache.org/solr/WritingDistributedSearchComponents and looking though the FacetComponent, DebugComponent, StatsComponent, and HighlightComponent code. Any help figuring out why the other methods are not being called is greatly appreciated. Please ignore the println statments, they are for debug only and will be removed in the finalized, working patch. Thanks! Distributed TermsComponent -- Key: SOLR-1177 URL: https://issues.apache.org/jira/browse/SOLR-1177 Project: Solr Issue Type: Improvement Affects Versions: 1.4 Reporter: Matt Weber Priority: Minor Fix For: 1.5 Attachments: SOLR-1177.patch TermsComponent should be distributed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1177) Distributed TermsComponent
Distributed TermsComponent -- Key: SOLR-1177 URL: https://issues.apache.org/jira/browse/SOLR-1177 Project: Solr Issue Type: Improvement Affects Versions: 1.4 Reporter: Matt Weber Priority: Minor Fix For: 1.5 TermsComponent should be distributed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1178) Retrieve CoreContainer from EmbeddedSolrServer
Retrieve CoreContainer from EmbeddedSolrServer -- Key: SOLR-1178 URL: https://issues.apache.org/jira/browse/SOLR-1178 Project: Solr Issue Type: Improvement Affects Versions: 1.4 Reporter: Eric Pugh Priority: Minor Submitting the patch suggested by Paul Noble to deal with this issue: Hi all, I notice that when I use EmbeddedSolrServer I have to use Control C to stop the process. I think the way to shut it down is by calling coreContainer.shutdown(). However, is it possible to get the coreContainer from a SolrServer object? Right now it is defined as protected final CoreContainer coreContainer;. I wanted to do: ((EmbeddedSolrServer)solr)getCoreContainer.shutdown(); But is seem I need to keep my own reference to the coreContainer? Is changing this worth a patch? Eric -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1169) SortedIntDocSet
[ https://issues.apache.org/jira/browse/SOLR-1169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley resolved SOLR-1169. Resolution: Fixed committed. SortedIntDocSet --- Key: SOLR-1169 URL: https://issues.apache.org/jira/browse/SOLR-1169 Project: Solr Issue Type: Improvement Reporter: Yonik Seeley Assignee: Yonik Seeley Fix For: 1.4 Attachments: SOLR-1169.patch A DocSet type that can skip to support SOLR-1165 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Compile error from new contrib clustering?
Okay... I've commented it out by tweaking the contrib-crawl macrodef and adding an ignores in common-build.xml: fileset dir=. includes=contrib/*/build.xml excludes=**/clustering/build.xml / Does anyone have a link to Java 1.6 for OSX? I see references to some sort of Update 2 for Java, but haven't found a download link. Eric On May 20, 2009, at 2:07 PM, Grant Ingersoll wrote: I confirm it's there. For now, the work around is to use 1.6. Can anyone reproduce on Windows or Linux? -Grant On May 20, 2009, at 1:43 PM, Grant Ingersoll wrote: Hmm, checking. I know it spit out warnings on that stuff, but didn't think it would cause an error. On May 20, 2009, at 12:21 PM, Eric Pugh wrote: Hi all, Anyone else getting a compile error from the new contrib/ clustering stuff? On OSX with Java 1.5: budapest:asf_solr_src epugh$ java -version java version 1.5.0_16 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16- b06-284) Java HotSpot(TM) Client VM (build 1.5.0_16-133, mixed mode, sharing) I am getting: compile: [javac] Compiling 7 source files to /trunk/asf_solr_src/contrib/ clustering/build/classes [javac] An exception has occurred in the compiler (1.5.0_16). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport ) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. [javac] com.sun.tools.javac.code.Symbol$CompletionFailure: file org/simpleframework/xml/Root.class not found Eric - Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com Free/Busy: http://tinyurl.com/eric-cal -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using Solr/Lucene: http://www.lucidimagination.com/search -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using Solr/Lucene: http://www.lucidimagination.com/search - Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com Free/Busy: http://tinyurl.com/eric-cal
Re: Compile error from new contrib clustering?
I confirm it's there. For now, the work around is to use 1.6. Can anyone reproduce on Windows or Linux? -Grant On May 20, 2009, at 1:43 PM, Grant Ingersoll wrote: Hmm, checking. I know it spit out warnings on that stuff, but didn't think it would cause an error. On May 20, 2009, at 12:21 PM, Eric Pugh wrote: Hi all, Anyone else getting a compile error from the new contrib/clustering stuff? On OSX with Java 1.5: budapest:asf_solr_src epugh$ java -version java version 1.5.0_16 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16- b06-284) Java HotSpot(TM) Client VM (build 1.5.0_16-133, mixed mode, sharing) I am getting: compile: [javac] Compiling 7 source files to /trunk/asf_solr_src/contrib/ clustering/build/classes [javac] An exception has occurred in the compiler (1.5.0_16). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport ) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. [javac] com.sun.tools.javac.code.Symbol$CompletionFailure: file org/simpleframework/xml/Root.class not found Eric - Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com Free/Busy: http://tinyurl.com/eric-cal -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using Solr/Lucene: http://www.lucidimagination.com/search -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using Solr/Lucene: http://www.lucidimagination.com/search
Compile error from new contrib clustering?
Hi all, Anyone else getting a compile error from the new contrib/clustering stuff? On OSX with Java 1.5: budapest:asf_solr_src epugh$ java -version java version 1.5.0_16 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16- b06-284) Java HotSpot(TM) Client VM (build 1.5.0_16-133, mixed mode, sharing) I am getting: compile: [javac] Compiling 7 source files to /trunk/asf_solr_src/contrib/ clustering/build/classes [javac] An exception has occurred in the compiler (1.5.0_16). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport ) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. [javac] com.sun.tools.javac.code.Symbol$CompletionFailure: file org/simpleframework/xml/Root.class not found Eric - Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com Free/Busy: http://tinyurl.com/eric-cal
[jira] Updated: (SOLR-1178) Retrieve CoreContainer from EmbeddedSolrServer
[ https://issues.apache.org/jira/browse/SOLR-1178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh updated SOLR-1178: Attachment: embedded_solr_container.patch Patch file, and I added a really stupidly simple test. I added it to TestSolrProperties.java just cause it didn't seem worth creating another .java file, and I don't know if we need it. Retrieve CoreContainer from EmbeddedSolrServer -- Key: SOLR-1178 URL: https://issues.apache.org/jira/browse/SOLR-1178 Project: Solr Issue Type: Improvement Affects Versions: 1.4 Reporter: Eric Pugh Priority: Minor Attachments: embedded_solr_container.patch Submitting the patch suggested by Paul Noble to deal with this issue: Hi all, I notice that when I use EmbeddedSolrServer I have to use Control C to stop the process. I think the way to shut it down is by calling coreContainer.shutdown(). However, is it possible to get the coreContainer from a SolrServer object? Right now it is defined as protected final CoreContainer coreContainer;. I wanted to do: ((EmbeddedSolrServer)solr)getCoreContainer.shutdown(); But is seem I need to keep my own reference to the coreContainer? Is changing this worth a patch? Eric -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Help Writing a Distributed Component
Thanks Grant, that will really help me out. Thanks, Matt Weber eSr Technologies http://www.esr-technologies.com On May 20, 2009, at 11:16 AM, Grant Ingersoll wrote: On May 20, 2009, at 12:07 PM, Matt Weber wrote: Hey Grant, I have opened a new ticket with the current version of my patch at https://issues.apache.org/jira/browse/SOLR-1177 . What do you mean by configuring my shards? I implemented the distributed methods (prepare, process, modifyRequest, etc) as is done in the other distributed components, then I just specify a shards parameter in the query. I looked though the other distributed components and did not see them doing any special shard configuration other than modifying the query that is sent to the shards. I must be missing something, but I can't seem to figure out due to my lack of knowledge on distributed components and the solr codebase in general. Thanks for your help! No, nothing special. Just wanted to make sure your query had a shards parameter in it (or configured in the solrconfig defaults). Basically, I was assuming nothing. I'll take a look at the patch, hopefully tonight or tomorrow morning.
Re: Compile error from new contrib clustering?
Thanks! I don't know that I have ever see the Java Preferences app before. At any rate, now I have: budapest:asf_solr_src epugh$ java -version java version 1.6.0_07 Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153) Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode) but still getting the same: An exception has occurred in the compiler (1.5.0_16). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport ) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. [javac] com.sun.tools.javac.code.Symbol$CompletionFailure: file org/simpleframework/xml/Root.class not found I ran ant -diagnostics and saw it was still using 1.5. Turns out that JAVA_HOME was pointed to /Library/Java/Home and I needed it to point to /usr/bin/java. So I did export JAVA_HOME=/usr and it seems to work. The cluster code all compiled. Hopefully this helps out anyone else on OSX Eric On May 20, 2009, at 3:11 PM, Matt Weber wrote: Java 1.6 is only available for Leopard. It should be installed by default, use the java preferences app to make it your default. Thanks, Matt Weber eSr Technologies http://www.esr-technologies.com On May 20, 2009, at 12:04 PM, Eric Pugh wrote: Okay... I've commented it out by tweaking the contrib-crawl macrodef and adding an ignores in common-build.xml: fileset dir=. includes=contrib/*/build.xml excludes=**/clustering/build.xml / Does anyone have a link to Java 1.6 for OSX? I see references to some sort of Update 2 for Java, but haven't found a download link. Eric On May 20, 2009, at 2:07 PM, Grant Ingersoll wrote: I confirm it's there. For now, the work around is to use 1.6. Can anyone reproduce on Windows or Linux? -Grant On May 20, 2009, at 1:43 PM, Grant Ingersoll wrote: Hmm, checking. I know it spit out warnings on that stuff, but didn't think it would cause an error. On May 20, 2009, at 12:21 PM, Eric Pugh wrote: Hi all, Anyone else getting a compile error from the new contrib/ clustering stuff? On OSX with Java 1.5: budapest:asf_solr_src epugh$ java -version java version 1.5.0_16 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16- b06-284) Java HotSpot(TM) Client VM (build 1.5.0_16-133, mixed mode, sharing) I am getting: compile: [javac] Compiling 7 source files to /trunk/asf_solr_src/contrib/ clustering/build/classes [javac] An exception has occurred in the compiler (1.5.0_16). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport ) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. [javac] com.sun.tools.javac.code.Symbol$CompletionFailure: file org/simpleframework/xml/Root.class not found Eric - Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com Free/Busy: http://tinyurl.com/eric-cal -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/ Droids) using Solr/Lucene: http://www.lucidimagination.com/search -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/Droids) using Solr/Lucene: http://www.lucidimagination.com/search - Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com Free/Busy: http://tinyurl.com/eric-cal - Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com Free/Busy: http://tinyurl.com/eric-cal
Re: Compile error from new contrib clustering?
Actually, here is the correct JAVA_HOME: export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/ 1.6.0/Home/ Thanks, Matt Weber eSr Technologies http://www.esr-technologies.com On May 20, 2009, at 12:31 PM, Eric Pugh wrote: Thanks! I don't know that I have ever see the Java Preferences app before. At any rate, now I have: budapest:asf_solr_src epugh$ java -version java version 1.6.0_07 Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153) Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode) but still getting the same: An exception has occurred in the compiler (1.5.0_16). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport ) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. [javac] com.sun.tools.javac.code.Symbol$CompletionFailure: file org/simpleframework/xml/Root.class not found I ran ant -diagnostics and saw it was still using 1.5. Turns out that JAVA_HOME was pointed to /Library/Java/Home and I needed it to point to /usr/bin/java. So I did export JAVA_HOME=/usr and it seems to work. The cluster code all compiled. Hopefully this helps out anyone else on OSX Eric On May 20, 2009, at 3:11 PM, Matt Weber wrote: Java 1.6 is only available for Leopard. It should be installed by default, use the java preferences app to make it your default. Thanks, Matt Weber eSr Technologies http://www.esr-technologies.com On May 20, 2009, at 12:04 PM, Eric Pugh wrote: Okay... I've commented it out by tweaking the contrib-crawl macrodef and adding an ignores in common-build.xml: fileset dir=. includes=contrib/*/build.xml excludes=**/clustering/build.xml / Does anyone have a link to Java 1.6 for OSX? I see references to some sort of Update 2 for Java, but haven't found a download link. Eric On May 20, 2009, at 2:07 PM, Grant Ingersoll wrote: I confirm it's there. For now, the work around is to use 1.6. Can anyone reproduce on Windows or Linux? -Grant On May 20, 2009, at 1:43 PM, Grant Ingersoll wrote: Hmm, checking. I know it spit out warnings on that stuff, but didn't think it would cause an error. On May 20, 2009, at 12:21 PM, Eric Pugh wrote: Hi all, Anyone else getting a compile error from the new contrib/ clustering stuff? On OSX with Java 1.5: budapest:asf_solr_src epugh$ java -version java version 1.5.0_16 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b06-284) Java HotSpot(TM) Client VM (build 1.5.0_16-133, mixed mode, sharing) I am getting: compile: [javac] Compiling 7 source files to /trunk/asf_solr_src/contrib/ clustering/build/classes [javac] An exception has occurred in the compiler (1.5.0_16). Please file a bug at the Java Developer Connection (http://java.sun.com/webapps/bugreport ) after checking the Bug Parade for duplicates. Include your program and the following diagnostic in your report. Thank you. [javac] com.sun.tools.javac.code.Symbol$CompletionFailure: file org/simpleframework/xml/Root.class not found Eric - Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com Free/Busy: http://tinyurl.com/eric-cal -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/ Droids) using Solr/Lucene: http://www.lucidimagination.com/search -- Grant Ingersoll http://www.lucidimagination.com/ Search the Lucene ecosystem (Lucene/Solr/Nutch/Mahout/Tika/ Droids) using Solr/Lucene: http://www.lucidimagination.com/search - Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com Free/Busy: http://tinyurl.com/eric-cal - Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com Free/Busy: http://tinyurl.com/eric-cal
Re: Compile error from new contrib clustering?
Thanks! On May 20, 2009, at 3:40 PM, Matt Weber wrote: export JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/ Versions/1.6.0/Home/ - Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | http://www.opensourceconnections.com Free/Busy: http://tinyurl.com/eric-cal
[jira] Commented: (SOLR-1164) BinaryUpdateRequestHandler and JavaBinUpdateRequestCodec do not maintain order of the commands as serialized in the binary format
[ https://issues.apache.org/jira/browse/SOLR-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711318#action_12711318 ] Jayson Minard commented on SOLR-1164: - So I need to take this patch, then fix SOLR-1162 over the top of it, correct? I'll see what changed across the two and make sure SOLR-1162 depends on this patch and is only the changes beyond it. BinaryUpdateRequestHandler and JavaBinUpdateRequestCodec do not maintain order of the commands as serialized in the binary format - Key: SOLR-1164 URL: https://issues.apache.org/jira/browse/SOLR-1164 Project: Solr Issue Type: Improvement Components: update Affects Versions: 1.3 Reporter: Jayson Minard Assignee: Noble Paul Attachments: SOLR-1164.patch, SOLR-1164.patch When sending commands in the Java binary format to the BinaryUpdateRequestHandler it does not process them in the order received. It processes all add/updates then delete by id then delete by query regardless of what is sent. See SOLR-1162 for related issue and patch that covers both issues (they are intertwined since some classes are shared on both sides of the wire) I wanted a separate issue covering this so that it is seen from the server viewpoint and not just as a client API issue as other clients writing the binary form would be unable to maintain order of commands as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Compile error from new contrib clustering?
On Wed, May 20, 2009 at 11:37 PM, Grant Ingersoll gsing...@apache.orgwrote: I confirm it's there. For now, the work around is to use 1.6. Can anyone reproduce on Windows or Linux? I see this as well on Fedora 10 with JDK 1.5.0_12 -- Regards, Shalin Shekhar Mangar.
Re: Compile error from new contrib clustering?
What about on 1.6? I think I will comment out the build as Eric suggested and put a placeholder note that it requires 1.6. I'll also do some searching to see if this is a known issue. On May 20, 2009, at 5:35 PM, Shalin Shekhar Mangar wrote: On Wed, May 20, 2009 at 11:37 PM, Grant Ingersoll gsing...@apache.orgwrote: I confirm it's there. For now, the work around is to use 1.6. Can anyone reproduce on Windows or Linux? I see this as well on Fedora 10 with JDK 1.5.0_12 -- Regards, Shalin Shekhar Mangar.
[jira] Commented: (SOLR-1164) BinaryUpdateRequestHandler and JavaBinUpdateRequestCodec do not maintain order of the commands as serialized in the binary format
[ https://issues.apache.org/jira/browse/SOLR-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711460#action_12711460 ] Noble Paul commented on SOLR-1164: -- yes. apply SOLR-1162 over this patch.if any changes are required for this issue we can do it Another suggestion for 1162 you may not need so many new classes for each type of request. Just keep one NamedList in the UpdateRequest object and keep adding items to that with proper names. say docs,deleteByid,DeleteByQ etc. that can make it very simple BinaryUpdateRequestHandler and JavaBinUpdateRequestCodec do not maintain order of the commands as serialized in the binary format - Key: SOLR-1164 URL: https://issues.apache.org/jira/browse/SOLR-1164 Project: Solr Issue Type: Improvement Components: update Affects Versions: 1.3 Reporter: Jayson Minard Assignee: Noble Paul Attachments: SOLR-1164.patch, SOLR-1164.patch When sending commands in the Java binary format to the BinaryUpdateRequestHandler it does not process them in the order received. It processes all add/updates then delete by id then delete by query regardless of what is sent. See SOLR-1162 for related issue and patch that covers both issues (they are intertwined since some classes are shared on both sides of the wire) I wanted a separate issue covering this so that it is seen from the server viewpoint and not just as a client API issue as other clients writing the binary form would be unable to maintain order of commands as well. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Compile error from new contrib clustering?
On Thu, May 21, 2009 at 3:49 AM, Grant Ingersoll gsing...@apache.orgwrote: What about on 1.6? Compiles fine with JDK 1.6.0_13 on the same box. -- Regards, Shalin Shekhar Mangar.
[jira] Updated: (SOLR-1153) deltaImportQuery should be honored on child entities as well
[ https://issues.apache.org/jira/browse/SOLR-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1153: - Attachment: SOLR-1153.patch The fix ,I shall commmit this shortly deltaImportQuery should be honored on child entities as well Key: SOLR-1153 URL: https://issues.apache.org/jira/browse/SOLR-1153 Project: Solr Issue Type: Improvement Components: contrib - DataImportHandler Reporter: Noble Paul Assignee: Noble Paul Priority: Minor Fix For: 1.4 Attachments: SOLR-1153.patch currently , only the root-entity can have this attribute -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-1153) deltaImportQuery should be honored on child entities as well
[ https://issues.apache.org/jira/browse/SOLR-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul resolved SOLR-1153. -- Resolution: Fixed committed revision: 776958 deltaImportQuery should be honored on child entities as well Key: SOLR-1153 URL: https://issues.apache.org/jira/browse/SOLR-1153 Project: Solr Issue Type: Improvement Components: contrib - DataImportHandler Reporter: Noble Paul Assignee: Noble Paul Priority: Minor Fix For: 1.4 Attachments: SOLR-1153.patch currently , only the root-entity can have this attribute -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
