I want to translate solr wiki to Korean.

2014-11-11 Thread Jeon Woosung 
In Korea, only few people can read English well. Thus, it is difficult to
use solr. But I want solr to spread out . So I would like to translate solr
wiki to Korean. Is there any good ways to translate it?

Re: DIH Blob data

2014-11-12 Thread Jeon Woosung 
How about this?

First, define a field for filter query. It should be multivalued.

Second, implements transformer to extract json dynamic fields, and put the
dynamic fields into the solr field.

For example,



Data : {a:1,b:2,c:3}

You can split the data to "a:1", "b:2", "c:3", and put them into terms.

And then you can use filter query like "fq=terms:a:1"
2014. 11. 13. 오전 3:59에 "Michael Sokolov" 님이
작성:

> We routinely store images and pdfs in Solr. There *is* a benefit, since
> you don't need to manage another storage system, you don't have to worry
> about Solr getting out of sync with the other system, you can use Solr
> replication for all your assets, etc.
>
> I don't use DIH, so personally I don't care whether it handles blobs, but
> it does seem like a natural extension for a system that indexes data from
> SQL in Solr.
>
> -Mike
>
>
> On 11/12/2014 01:31 PM, Anurag Sharma wrote:
>
>> BLOB is non-searchable field so there is no benefit of storing it into
>> Solr. Any external key-value store can be used to store the blob and
>> reference of this blob can be stored as a string field in Solr.
>>
>> On Wed, Nov 12, 2014 at 5:56 PM, stockii 
>> wrote:
>>
>>  I had a similar problem and didnt find any solution to use the fields in
>>> JSON
>>> Blob for a filter ... Not with DIH.
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://lucene.472066.n3.nabble.com/DIH-Blob-data-tp4168896p4168925.html
>>> Sent from the Solr - User mailing list archive at Nabble.com.
>>>
>>>
>

Re: Problems after upgrade 4.10.1 -> 4.10.2

2014-11-12 Thread Jeon Woosung 
you can migrate zookeeper data manually.

1. connect zookeeper.
- zkCli.sh -server host:port
2. check old data
- get /collections/"your collection
name"/leader_initiated_recovery/"your shard name"


[zk: localhost:3181(CONNECTED) 25] get
/collections/collection1/leader_initiated_recovery/shard1
*down*
cZxid = 0xe4
ctime = Thu Nov 13 13:38:53 KST 2014
mZxid = 0xe4
mtime = Thu Nov 13 13:38:53 KST 2014
pZxid = 0xe4
cversion = 0
dataVersion = 0
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 4
numChildren = 0


i guess that there is only single word which is "down"

3. delete the data.
- remove /collections/"your collection
name"/leader_initiated_recovery/"your shard name"

4. create new data.
- create /collections/"your collection
name"/leader_initiated_recovery/"your shard name" {state:down}

5. restart the server.



On Thu, Nov 13, 2014 at 7:42 AM, Anshum Gupta 
wrote:

> Considering the impact, I think we should put this out as an announcement
> on the 'news' section of the website warning people about this.
>
> On Wed, Nov 12, 2014 at 12:33 PM, Shalin Shekhar Mangar <
> shalinman...@gmail.com> wrote:
>
> > I opened https://issues.apache.org/jira/browse/SOLR-6732
> >
> > On Wed, Nov 12, 2014 at 12:29 PM, Shalin Shekhar Mangar <
> > shalinman...@gmail.com> wrote:
> >
> > > Hi Thomas,
> > >
> > > You're right, there's a back-compat break here. I'll open an issue.
> > >
> > > On Wed, Nov 12, 2014 at 9:37 AM, Thomas Lamy 
> > wrote:
> > >
> > >> Am 12.11.2014 um 15:29 schrieb Thomas Lamy:
> > >>
> > >>> Hi there!
> > >>>
> > >>> As we got bitten by https://issues.apache.org/jira/browse/SOLR-6530
> on
> > >>> a regular basis, we started upgrading our 7 mode cloud from 4.10.1 to
> > >>> 4.10.2.
> > >>> The first node upgrade worked like a charm.
> > >>> After upgrading the second node, two cores no longer come up and we
> get
> > >>> the following error:
> > >>>
> > >>> ERROR - 2014-11-12 15:17:34.226;
> > org.apache.solr.cloud.RecoveryStrategy;
> > >>> Recovery failed - trying again... (16) core=cams_shard1_replica4
> > >>> ERROR - 2014-11-12 15:17:34.230;
> org.apache.solr.common.SolrException;
> > >>> Error while trying to recover. core=onlinelist_shard1_
> > >>> replica7rg.noggit.JSONParser$ParseException: JSON Parse Error:
> > >>> char=d,position=0 BEFORE='d' AFTER='own'
> > >>> at org.noggit.JSONParser.err(JSONParser.java:223)
> > >>> at org.noggit.JSONParser.next(JSONParser.java:622)
> > >>> at org.noggit.JSONParser.nextEvent(JSONParser.java:663)
> > >>> at org.noggit.ObjectBuilder.(ObjectBuilder.java:44)
> > >>> at org.noggit.ObjectBuilder.getVal(ObjectBuilder.java:37)
> > >>> at org.apache.solr.common.cloud.ZkStateReader.fromJSON(
> > >>> ZkStateReader.java:129)
> > >>> at
> > org.apache.solr.cloud.ZkController.getLeaderInitiatedRecoveryStat
> > >>> eObject(ZkController.java:1925)
> > >>> at
> > org.apache.solr.cloud.ZkController.getLeaderInitiatedRecoveryStat
> > >>> e(ZkController.java:1890)
> > >>> at org.apache.solr.cloud.ZkController.publish(
> > >>> ZkController.java:1071)
> > >>> at org.apache.solr.cloud.ZkController.publish(
> > >>> ZkController.java:1041)
> > >>> at org.apache.solr.cloud.ZkController.publish(
> > >>> ZkController.java:1037)
> > >>> at org.apache.solr.cloud.RecoveryStrategy.doRecovery(
> > >>> RecoveryStrategy.java:355)
> > >>> at org.apache.solr.cloud.RecoveryStrategy.run(
> > >>> RecoveryStrategy.java:235)
> > >>>
> > >>> Any hint on how to solve this? Google didn't reveal anything
> useful...
> > >>>
> > >>>
> > >>> Kind regards
> > >>> Thomas
> > >>>
> > >>>  Just switched to INFO loglevel:
> > >>
> > >> INFO  - 2014-11-12 15:30:31.563;
> org.apache.solr.cloud.RecoveryStrategy;
> > >> Publishing state of core onlinelist_shard1_replica7 as recovering,
> > leader
> > >> is http://solr-bc1-blade2:8080/solr/onlinelist_shard1_replica2/ and I
> > am
> > >> http://solr-bc1-blade3:8080/solr/onlinelist_shard1_replica7/
> > >> INFO  - 2014-11-12 15:30:31.563;
> org.apache.solr.cloud.RecoveryStrategy;
> > >> Publishing state of core cams_shard1_replica4 as recovering, leader is
> > >> http://solr-bc1-blade2:8080/solr/cams_shard1_replica2/ and I am
> > >> http://solr-bc1-blade3:8080/solr/cams_shard1_replica4/
> > >> INFO  - 2014-11-12 15:30:31.563; org.apache.solr.cloud.ZkController;
> > >> publishing core=onlinelist_shard1_replica7 state=recovering
> > >> collection=onlinelist
> > >> INFO  - 2014-11-12 15:30:31.563; org.apache.solr.cloud.ZkController;
> > >> publishing core=cams_shard1_replica4 state=recovering collection=cams
> > >> ERROR - 2014-11-12 15:30:31.564; org.apache.solr.common.SolrException;
> > >> Error while trying to recover. core=cams_shard1_replica4rg.
> > >> noggit.JSONParser$ParseException: JSON Parse Error: char=d,position=0

Re: fl rename of unique key in solrcloud

2014-11-14 Thread Jeon Woosung 
Could you let me know version of the solr?

On Sat, Nov 15, 2014 at 5:05 AM, Suchi Amalapurapu 
wrote:

> Hi
> Getting the following exception when using fl renaming with unique key in
> the schema.
> http:///solr//select?q=dress&fl=a1:p1
>
> where p1 is the unique key for 
> For collections with single shard, this works flawlessly but results in the
> following exception in case of multiple shards.
>
> How do we fix this? Stack trace below.
> Suchi
>
> error": {"trace": "java.lang.NullPointerException\n\tat
>
> org.apache.solr.handler.component.QueryComponent.returnFields(QueryComponent.java:998)\n\tat
>
> org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:653)\n\tat
>
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:628)\n\tat
>
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:311)\n\tat
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)\n\tat
> org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:721)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:417)\n\tat
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:201)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)\n\tat
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)\n\tat
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)\n\tat
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)\n\tat
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)\n\tat
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)\n\tat
>
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)\n\tat
> org.eclipse.jetty.server.Server.handle(Server.java:368)\n\tat
>
> org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)\n\tat
>
> org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)\n\tat
>
> org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)\n\tat
>
> org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)\n\tat
> org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)\n\tat
> org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)\n\tat
>
> org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)\n\tat
>
> org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)\n\tat
>
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)\n\tat
> java.lang.Thread.run(Thread.java:662)\n","code": 500
>



-- 
*God bless U*

Re: fl rename of unique key in solrcloud

2014-11-15 Thread Jeon Woosung 
I guess that I caused by shard which return renamed field.

following code is source code of solr 4.6

===
986:if ((sreq.purpose & ShardRequest.PURPOSE_GET_FIELDS) != 0) {
987:  boolean returnScores = (rb.getFieldFlags() &
SolrIndexSearcher.GET_SCORES) != 0;
988:
989:  assert(sreq.responses.size() == 1);
990:  ShardResponse srsp = sreq.responses.get(0);
991:  SolrDocumentList docs =
(SolrDocumentList)srsp.getSolrResponse().getResponse().get("response");
992:
993:  String keyFieldName =
rb.req.getSchema().getUniqueKeyField().getName();
994:  boolean removeKeyField =
!rb.rsp.getReturnFields().wantsField(keyFieldName);
995:
996:  for (SolrDocument doc : docs) {
997:Object id = doc.getFieldValue(keyFieldName);
998:ShardDoc sdoc = rb.resultIds.get(id.toString());


If each shard return renamed field name instead of keyFieldName(UniqueKey),
"id" of 998 line could be null. Because the doc of 996 line wouldn't have
"keyFieldName"


So if you are urgent or you can not wait for patch, you can add unique
field like this.
eg) http:///solr//select?q=dress&fl=a1:p1&fl=p1




On Sat, Nov 15, 2014 at 11:26 PM, Garth Grimm <
garthgr...@averyranchconsulting.com> wrote:

> https://issues.apache.org/jira/browse/SOLR-6744 created.
>
> And hopefully correctly, since that’s my first.
> On Nov 15, 2014, at 9:12 AM, Garth Grimm <
> garthgr...@averyranchconsulting.com garthgr...@averyranchconsulting.com>> wrote:
>
> I see the same issue on 4.10.1.
>
> I’ll open a JIRA if I don’t see one.
>
> I guess the best immediate work around is to copy the unique field, and
> use that field for renaming?
> On Nov 15, 2014, at 3:18 AM, Suchi Amalapurapu  <mailto:su...@bloomreach.com>> wrote:
>
> Solr version:4.6.1
>
> On Sat, Nov 15, 2014 at 12:24 PM, Jeon Woosung  <mailto:jeonwoos...@gmail.com>>
> wrote:
>
> Could you let me know version of the solr?
>
> On Sat, Nov 15, 2014 at 5:05 AM, Suchi Amalapurapu  <mailto:su...@bloomreach.com>>
> wrote:
>
> Hi
> Getting the following exception when using fl renaming with unique key in
> the schema.
> http:///solr//select?q=dress&fl=a1:p1
>
> where p1 is the unique key for 
> For collections with single shard, this works flawlessly but results in
> the
> following exception in case of multiple shards.
>
> How do we fix this? Stack trace below.
> Suchi
>
> error": {"trace": "java.lang.NullPointerException\n\tat
>
>
>
> org.apache.solr.handler.component.QueryComponent.returnFields(QueryComponent.java:998)\n\tat
>
>
>
> org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:653)\n\tat
>
>
>
> org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:628)\n\tat
>
>
>
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:311)\n\tat
>
>
>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)\n\tat
> org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)\n\tat
>
>
>
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:721)\n\tat
>
>
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:417)\n\tat
>
>
>
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:201)\n\tat
>
>
>
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)\n\tat
>
>
>
> org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)\n\tat
>
>
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)\n\tat
>
>
>
> org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)\n\tat
>
>
>
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)\n\tat
>
>
>
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)\n\tat
>
>
>
> org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)\n\tat
>
>
>
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)\n\tat
>
>
>
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)\n\tat
>
>
>
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)\n\tat
>
>
>
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)\n\tat
>
>
&g

Re: Solrcloud and remote Zookeeper ensemble

2014-11-19 Thread Jeon Woosung 
did you set solr.solrxml.location in catalina.sh and how did you specify
zkhost?

-Dsolr.solrxml.location=zookeeper

On Wed, Nov 19, 2014 at 9:54 PM, Robert Kent  wrote:

> Hi,
>
> I'm experiencing some odd behaviour with Solrcloud and Zookeeper.  I am
> running Solrcloud on one host and am running three Zookeepers on another
> three hosts.  The Zookeeper part of things works correctly, I can
> add/remove/etc nodes from Zookeeper.  I am running, or rather trying to
> run, Solrcloud on top of Hadoop.  Again, the Hadoop side of things works
> correctly, I can create/remove/etc dirs/files under Hadoop.
>
> Unfortunately, the solrctl utility bundled with Solrcloud doesn't appear
> to work correctly.  Depending on how or where I set the Zookeeper ensemble
> details I get different results.  My Zookeeper instances are used by other
> services, so I am trying to force the Solrcloud configuration to be created
> under /solr - from reading the documentation this appears to be the
> recommended appraoch.
>
> I have set the Zookeeper ensemble and Hadoop configuration in
> /etc/default/solr:
>
>
> SOLR_ZK_ENSEMBLE=zookeeper1:2181/solr,zookeeper2:2181/solr,zookeeper3:2181/solr
> SOLR_HDFS_HOME=hdfs://zookeeper1:8020/solr
> SOLR_HDFS_CONFIG=/etc/hadoop/conf
> SOLR_HDFS_HOME=hdfs://3xNodeHA:8020/solr
>
> If I do not specify any Zookeeper parameters for solrctl it creates it
> Zookeeper configuration under '/solr,zookeeper2:2181' and under that is
> creates  '/solr,zookeeper3:2181/solr/configs/my-data'.  This also occurs if
> I specify --zk
> zookeeper1:2181/solr,zookeeper2:2181/solr,zookeeper3:2181/solr.  I suspect
> that something somewhere is not treating the SOLR_ZK_ENSEMBLE variable
> correctly and believes it is a single connection (eg zookeeper1:2181) and
> the path is /solr,zookeeper2:2181,zookeeper3:2181/solr.
>
> If I run solrctl with --zk zookeeper1:2181, it creates its configuration
> under / (eg /solr.xml /configs).
>
> If I run solrctl with --zk zookeeper1:2181/solr, it creates the
> configuration under /solr
>
>
> If I completely ignore the Zookeeper configuration Solr works correctly,
> but as I'm using Lily I need Solr's configuration to exist under Zookeeper.
>
> What am I missing?  How can I specify a multi-node Zookeeper ensemble and
> have all of the configuration nodes created under /solr?  How do I point
> Tomcat towards the Solr configuration under /solr?
>
> If you would like more details, please look at the attachment as this
> explains what I did at each step and the results of that step.
>
>
> I'm using Cloudera's packages throughout.
>
> thanks
>
> Rob
>
> Registered name: In Practice Systems Ltd.
> Registered address: The Bread Factory, 1a Broughton Street, London, SW8 3QJ
> Registered Number: 1788577
> Registered in England
> Visit our Internet Web site at www.inps.co.uk
> The information in this internet email is confidential and is intended
> solely for the addressee. Access, copying or re-use of information in it by
> anyone else is not authorised. Any views or opinions presented are solely
> those of the author and do not necessarily represent those of INPS or any
> of its affiliates. If you are not the intended recipient please contact
> is.helpd...@inps.co.uk
>
>


-- 
*God bless U*