sergio Software, Support, and Training for Apache Cassandra en-US Sat, 25 May 2013 18:00:59 +0000 http://bbpress.org/?v=1.0.3 q http://www.datastax.com/support-forums/search.php http://www.datastax.com/support-forums/topic/changing-the-jetty-port#post-11334 Sat, 25 May 2013 11:00:00 +0000 sergio 11334@http://www.datastax.com/support-forums/ <p>Hi Ioan,</p> <p>you should be able to specify the jetty port by passing the -Djetty.port=_port_ JVM startup parameter.</p> <p>Cheers,</p> <p>Sergio B. </p> http://www.datastax.com/support-forums/topic/changing-the-jetty-port#post-11332 Sat, 25 May 2013 03:01:56 +0000 Ion Olaru 11332@http://www.datastax.com/support-forums/ <p>Hi</p> <p>I am trying to deploy 2 instances of Cassandra 1.2.5 + their respective agents + 1 opscenter on the same box, my local development box, I know this is weird, but I would like to have this configured locally before I move forward.</p> <p><strong>WARN [Jetty] 2013-05-24 23:02:46,794 FAILED org.eclipse.jetty.server.Server@4c18e99: java.net.BindException: Address already in use<br /> </strong></p> <p>My error now is the Jetty server Exception coming form the 2nd agent on start:<br /> I was wondering if I have any control on what port jetty should run.</p> <p>Thanks </p> http://www.datastax.com/support-forums/topic/dse-30-with-solr-support-for-integer-type#post-11193 Fri, 17 May 2013 22:01:34 +0000 Jack Krupansky 11193@http://www.datastax.com/support-forums/ <p>Patricia,</p> <p>Simply ignore that irrelevant phrase, ", Solr fields must be strings". The intent is simply that a Solr schema field can only be associated with a simple, non-composite Cassandra column. DSE does in fact support all the common types, as shown in that table, although you need 3.0.1 for the best type support; 3.0 mapped the Solr trie numeric types to UTF8Type, for example, as shown in the legacy type mapping table. </p> http://www.datastax.com/support-forums/topic/dse-30-with-solr-support-for-integer-type#post-11192 Fri, 17 May 2013 21:14:34 +0000 pgorla 11192@http://www.datastax.com/support-forums/ <p>Matt,</p> <p>I was also confused by this syntax. This sentence comes from this context:</p> <pre><code>Unsupported Features: &lt;...&gt; Cassandra composite columns, Solr fields must be strings.</code></pre> <p>The phrase "Solr fields must be strings" actually refers to the fact that each field must be of the same type. This means that composite columns are not supported, because composite columns actually contain two different data types. Solr requires that all values of a field share a type definition.</p> <p>So, DSE *does* support other types, such as int, date (see <a href="http://www.datastax.com/docs/datastax_enterprise3.0/solutions/dse_search_schema#solr-type-mapping)" rel="nofollow">http://www.datastax.com/docs/datastax_enterprise3.0/solutions/dse_search_schema#solr-type-mapping)</a> </p> http://www.datastax.com/support-forums/topic/dse-30-reindexing-is-not-working-for-solr-copyfield#post-11030 Wed, 15 May 2013 00:59:46 +0000 jwlee 11030@http://www.datastax.com/support-forums/ <p>Sergio,</p> <p>All right. Good to hear it is in the plan.<br /> We'll do the workaround in the meantime.</p> <p>Thanks!<br /> Regards,<br /> JW </p> http://www.datastax.com/support-forums/topic/dse-30-reindexing-is-not-working-for-solr-copyfield#post-11007 Tue, 14 May 2013 07:24:59 +0000 sergio 11007@http://www.datastax.com/support-forums/ <p>Hi,</p> <p>the reason we don't currently support reindexing of *new* copy fields is that we always store them in Cassandra (that is, we always assume stored=true), hence we need the copy field value to be known upfront at ingestion time.</p> <p>We are planning to support non-stored mode too (that is, stored=false): this will not store any copy fields in Cassandra, but will allow for them to be reindexed post-ingestion, even new ones.</p> <p>In the meantime, you can use the workaround provided above.</p> <p>Hope that helps.<br /> Cheers,</p> <p>Sergio B. </p> http://www.datastax.com/support-forums/topic/dse-30-reindexing-is-not-working-for-solr-copyfield#post-10999 Tue, 14 May 2013 03:35:59 +0000 jwlee 10999@http://www.datastax.com/support-forums/ <p>Thanks to all for your replies.<br /> Just want to add that the copyfield is an important feature for us.<br /> We are frequently changing the Solr schema to suit the search behaviors required by our users.<br /> Really do hope that the reindexing for the copyfields are automatically applied.<br /> After all, isn't it suppose to be ETL free? </p> http://www.datastax.com/support-forums/topic/dse-30-reindexing-is-not-working-for-solr-copyfield#post-10976 Mon, 13 May 2013 16:28:44 +0000 rockbrain 10976@http://www.datastax.com/support-forums/ <p>Tristan,</p> <p>The following contains the examples necessary to use the CopyFieldInputTransformer.</p> <p><a href="http://pastebin.com/bi7cLQud" rel="nofollow">http://pastebin.com/bi7cLQud</a></p> <p><a href="http://pastebin.com/MpbnCNsH" rel="nofollow">http://pastebin.com/MpbnCNsH</a> </p> http://www.datastax.com/support-forums/topic/dse-30-reindexing-is-not-working-for-solr-copyfield#post-10975 Mon, 13 May 2013 15:39:10 +0000 tristanls 10975@http://www.datastax.com/support-forums/ <p>Jack, that's good to hear. My main concern was that this might get dropped, but that's been alleviated.</p> <p>Also, I only get to complain on these forums, but overall it's been a pretty easy and good experience so far. So keep up the good work. </p> http://www.datastax.com/support-forums/topic/dse-30-reindexing-is-not-working-for-solr-copyfield#post-10974 Mon, 13 May 2013 15:19:33 +0000 Jack Krupansky 10974@http://www.datastax.com/support-forums/ <p>Tristan, thanks for the detailed justification - it will help fuel our internal discussions.</p> <p>Why not do it? Timeframe, priorities, compatibility, perceived importance, architectural complexity - the usual bane of software engineering. It sometimes just takes some time to work through it all. But, rest assured, it is on our radar. copyField is a very important Solr feature.</p> <p>Workarounds are, by definition, never good architecture. They're simply temporary, stopgap measures. </p> http://www.datastax.com/support-forums/topic/dse-30-reindexing-is-not-working-for-solr-copyfield#post-10970 Mon, 13 May 2013 15:09:53 +0000 tristanls 10970@http://www.datastax.com/support-forums/ <p>rockbrain, yes, it would be great to know even if it's brittle right now and might change </p> http://www.datastax.com/support-forums/topic/dse-30-reindexing-is-not-working-for-solr-copyfield#post-10968 Mon, 13 May 2013 14:42:45 +0000 rockbrain 10968@http://www.datastax.com/support-forums/ <p>Tristan, 3.0.1 has a way to do copy fields, however at this point we are still changing the implementation so it is undocumented, are you interested in how to do this? </p> http://www.datastax.com/support-forums/topic/dse-30-reindexing-is-not-working-for-solr-copyfield#post-10967 Mon, 13 May 2013 14:38:28 +0000 tristanls 10967@http://www.datastax.com/support-forums/ <p>Hey Jack,</p> <p>Why would you not change this? Consider a workflow for improving an autosuggest feature (since you've indicated fixing this is only barely under consideration):</p> <p>1. create a copyField to copy someField to someField_autosuggest with different analyzers<br /> 2. index stuff</p> <p>Or another:</p> <p>1. create dynamic field "*_autosuggest" which does autosuggest analyzing<br /> 2. deploy<br /> 3. business guy: "hey I need this other thing to autosuggest also"<br /> 4. I add a copyField to copy with "_autosuggest" extension<br /> 5. reindex (broken!)</p> <p>I expect to upload a schema, reload, and reindex. Copy fields not being applied breaks this workflow and is unexpected.</p> <p>Let's be honest, "simply read each Cassandra row (or Solr document)" isn't simple nor is it good architecture, especially if I'm doing it over a network.</p> <p>Cheers,</p> <p>Tristan </p> http://www.datastax.com/support-forums/topic/dse-30-reindexing-is-not-working-for-solr-copyfield#post-10966 Mon, 13 May 2013 13:40:46 +0000 Jack Krupansky 10966@http://www.datastax.com/support-forums/ <p>Sorry, but in DSE the Solr copy fields are only applied when the data is inserted into Cassandra ("insert time"), and NOT when data is reindexed ("index time"). We are considering whether to change this, but at the present time, this is the way it is.</p> <p>One workaround is to simply read each Cassandra row (or Solr document) and update it with the same values. This should then invoke the "insert time" copy field processing, with the new copy fields. </p> http://www.datastax.com/support-forums/topic/dse-30-reindexing-is-not-working-for-solr-copyfield#post-10963 Mon, 13 May 2013 08:36:48 +0000 cybc16 10963@http://www.datastax.com/support-forums/ <p>I am facing the same issue. Does anyone have any idea?</p> <p>Please help me if you have solve this.</p> <p>Thanks. </p>