date:20091008

DIH: Setting rows= on full-import has no effect
---

 Key: SOLR-1501
 URL: https://issues.apache.org/jira/browse/SOLR-1501
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler
Reporter: Noble Paul
Assignee: Noble Paul
Priority: Minor
 Fix For: 1.4


DIH: Setting rows= on full-import has no effect

http://markmail.org/thread/omzkm2x52dsuzomy

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (SOLR-1500) Jdbc datasource fails with Oracle driver


 [ 
https://issues.apache.org/jira/browse/SOLR-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Noble Paul resolved SOLR-1500.
--

Resolution: Fixed

committed r823398

> Jdbc datasource fails with Oracle driver
> 
>
> Key: SOLR-1500
> URL: https://issues.apache.org/jira/browse/SOLR-1500
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Reporter: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1500.patch
>
>
> A user has reported an issue
> http://markmail.org/thread/63gz6jsrhw64xoja
> Caused by: java.sql.SQLException: Unsupported feature
>at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
>at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:179)
>at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:269)
>at
> oracle.jdbc.dbaccess.DBError.throwUnsupportedFeatureSqlException(DBError.java:689)
>at
> oracle.jdbc.driver.OracleConnection.setHoldability(OracleConnection.java:3065)
>at
> org.apache.solr.handler.dataimport.JdbcDataSource$1.call(JdbcDataSource.java:191)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1500) Jdbc datasource fails with Oracle driver


 [ 
https://issues.apache.org/jira/browse/SOLR-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Noble Paul updated SOLR-1500:
-

Attachment: SOLR-1500.patch

the fix

> Jdbc datasource fails with Oracle driver
> 
>
> Key: SOLR-1500
> URL: https://issues.apache.org/jira/browse/SOLR-1500
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Reporter: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1500.patch
>
>
> A user has reported an issue
> http://markmail.org/thread/63gz6jsrhw64xoja
> Caused by: java.sql.SQLException: Unsupported feature
>at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
>at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:179)
>at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:269)
>at
> oracle.jdbc.dbaccess.DBError.throwUnsupportedFeatureSqlException(DBError.java:689)
>at
> oracle.jdbc.driver.OracleConnection.setHoldability(OracleConnection.java:3065)
>at
> org.apache.solr.handler.dataimport.JdbcDataSource$1.call(JdbcDataSource.java:191)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SOLR-1500) Jdbc datasource fails with Oracle driver

Jdbc datasource fails with Oracle driver


 Key: SOLR-1500
 URL: https://issues.apache.org/jira/browse/SOLR-1500
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler
Reporter: Noble Paul
 Fix For: 1.4


A user has reported an issue

http://markmail.org/thread/63gz6jsrhw64xoja

Caused by: java.sql.SQLException: Unsupported feature
   at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
   at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:179)
   at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:269)
   at
oracle.jdbc.dbaccess.DBError.throwUnsupportedFeatureSqlException(DBError.java:689)
   at
oracle.jdbc.driver.OracleConnection.setHoldability(OracleConnection.java:3065)
   at
org.apache.solr.handler.dataimport.JdbcDataSource$1.call(JdbcDataSource.java:191)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1499) SolrEntityProcessor - DIH EntityProcessor that queries an external Solr via SolrJ


[ 
https://issues.apache.org/jira/browse/SOLR-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763804#action_12763804
 ] 

Noble Paul commented on SOLR-1499:
--

Lance , could you have a usecase for this? 

> SolrEntityProcessor - DIH EntityProcessor that queries an external Solr via 
> SolrJ
> -
>
> Key: SOLR-1499
> URL: https://issues.apache.org/jira/browse/SOLR-1499
> Project: Solr
>  Issue Type: New Feature
>  Components: contrib - DataImportHandler
>Reporter: Lance Norskog
> Attachments: SOLR-1499.patch
>
>
> The SolrEntityProcessor queries an external Solr instance. The Solr documents 
> returned are unpacked and emitted as DIH fields.
> The SolrEntityProcessor uses the following attributes:
> * solr='http://localhost:8983/solr/sms'
> ** This gives the URL of the target Solr instance.
> *** Note: the connection to the target Solr uses the binary SolrJ format.
> * query='Jefferson&sort=id+asc'
> ** This gives the base query string use with Solr. It can include any 
> standard Solr request parameter. This attribute is processed under the 
> variable resolution rules and can be driven in an inner stage of the indexing 
> pipeline.
> * rows='10'
> ** This gives the number of rows to fetch per request..
> ** The SolrEntityProcessor always fetches every document that matches the 
> request..
> * fields='id,tag'
> ** This selects the fields to be returned from the Solr request.
> ** These must also be declared as  elements.
> ** As with all fields, template processors can be used to alter the contents 
> to be passed downwards.
> * timeout='30'
> ** This limits the query to 5 seconds. This can be used as a fail-safe to 
> prevent the indexing session from freezing up. By default the timeout is 5 
> minutes.
> Limitations:
> * Solr errors are not handled correctly.
> * Loop control constructs have not been tested.
> * Multi-valued returned fields have not been tested.
> The unit tests give examples of how to use it as the root entity and an inner 
> entity.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1499) SolrEntityProcessor - DIH EntityProcessor that queries an external Solr via SolrJ

2009-10-08 Thread Lance Norskog (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lance Norskog updated SOLR-1499:


Attachment: SOLR-1499.patch

First release of SolrEntityProcessor + three unit tests.

> SolrEntityProcessor - DIH EntityProcessor that queries an external Solr via 
> SolrJ
> -
>
> Key: SOLR-1499
> URL: https://issues.apache.org/jira/browse/SOLR-1499
> Project: Solr
>  Issue Type: New Feature
>  Components: contrib - DataImportHandler
>Reporter: Lance Norskog
> Attachments: SOLR-1499.patch
>
>
> The SolrEntityProcessor queries an external Solr instance. The Solr documents 
> returned are unpacked and emitted as DIH fields.
> The SolrEntityProcessor uses the following attributes:
> * solr='http://localhost:8983/solr/sms'
> ** This gives the URL of the target Solr instance.
> *** Note: the connection to the target Solr uses the binary SolrJ format.
> * query='Jefferson&sort=id+asc'
> ** This gives the base query string use with Solr. It can include any 
> standard Solr request parameter. This attribute is processed under the 
> variable resolution rules and can be driven in an inner stage of the indexing 
> pipeline.
> * rows='10'
> ** This gives the number of rows to fetch per request..
> ** The SolrEntityProcessor always fetches every document that matches the 
> request..
> * fields='id,tag'
> ** This selects the fields to be returned from the Solr request.
> ** These must also be declared as  elements.
> ** As with all fields, template processors can be used to alter the contents 
> to be passed downwards.
> * timeout='30'
> ** This limits the query to 5 seconds. This can be used as a fail-safe to 
> prevent the indexing session from freezing up. By default the timeout is 5 
> minutes.
> Limitations:
> * Solr errors are not handled correctly.
> * Loop control constructs have not been tested.
> * Multi-valued returned fields have not been tested.
> The unit tests give examples of how to use it as the root entity and an inner 
> entity.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SOLR-1499) SolrEntityProcessor - DIH EntityProcessor that queries an external Solr via SolrJ

2009-10-08 Thread Lance Norskog (JIRA)

SolrEntityProcessor - DIH EntityProcessor that queries an external Solr via 
SolrJ
-

 Key: SOLR-1499
 URL: https://issues.apache.org/jira/browse/SOLR-1499
 Project: Solr
  Issue Type: New Feature
  Components: contrib - DataImportHandler
Reporter: Lance Norskog


The SolrEntityProcessor queries an external Solr instance. The Solr documents 
returned are unpacked and emitted as DIH fields.

The SolrEntityProcessor uses the following attributes:

* solr='http://localhost:8983/solr/sms'
** This gives the URL of the target Solr instance.
*** Note: the connection to the target Solr uses the binary SolrJ format.

* query='Jefferson&sort=id+asc'
** This gives the base query string use with Solr. It can include any standard 
Solr request parameter. This attribute is processed under the variable 
resolution rules and can be driven in an inner stage of the indexing pipeline.

* rows='10'
** This gives the number of rows to fetch per request..
** The SolrEntityProcessor always fetches every document that matches the 
request..

* fields='id,tag'
** This selects the fields to be returned from the Solr request.
** These must also be declared as  elements.
** As with all fields, template processors can be used to alter the contents to 
be passed downwards.

* timeout='30'
** This limits the query to 5 seconds. This can be used as a fail-safe to 
prevent the indexing session from freezing up. By default the timeout is 5 
minutes.

Limitations:
* Solr errors are not handled correctly.
* Loop control constructs have not been tested.
* Multi-valued returned fields have not been tested.

The unit tests give examples of how to use it as the root entity and an inner 
entity.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (SOLR-1449) solrconfig.xml syntax to add classpath elements from outside of instanceDir

2009-10-08 Thread Hoss Man (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man updated SOLR-1449:
---

Fix Version/s: (was: 1.4)
   1.5

Moving to 1.5 due to lack of both testing and consensus on approach.

> solrconfig.xml syntax to add classpath elements from outside of instanceDir
> ---
>
> Key: SOLR-1449
> URL: https://issues.apache.org/jira/browse/SOLR-1449
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 1.5
>
> Attachments: SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch, 
> SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch, 
> SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch
>
>
> the idea has been discussed numerous times that it would be nice if there was 
> a way to configure a core to load plugins from specific jars (or "classes" 
> style directories) by path  w/o needing to copy them to the "./lib" dir in 
> the instanceDir.
> The current workaround is "symlinks" but that doesn't really help the 
> situation of the Solr Release artifacts, where we wind up making numerous 
> copies of jars to support multiple example directories (you can't have 
> reliable symlinks in zip files)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1449) solrconfig.xml syntax to add classpath elements from outside of instanceDir

2009-10-08 Thread Hoss Man (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763767#action_12763767
 ] 

Hoss Man commented on SOLR-1449:


bq. My current plan is to make the changes as soon as t 1.4 is released. So the 
refactoring is going to happen 'now' .


"now" is pre 1.4 ... whatever changes we anticipate making after 1.4 are 
"later" that was a big part of my point: we can easily refactor all of this 
after 1.4 is released, we can even do it an hour after 1.4 is released, but i 
was trying to minimize the number of changes needed to make this work prior to 
1.4.

bq. a simpler patch. SolrConfig is agnostic of SolrResourceLoader

How can you even remotely attempt to make that claim? Nothing in your patch 
does anything to make SolrConfig agnostic of SolrResourceLoader -- SolrConfig 
still constructs, maintains a refrence to, and provides the a public getter for 
the SolrResourceLoader.

To summarize the main differnces i can see between your patch and mine:
   * you move the FileFiltering out of SolrResourceLoader - i have no opinion 
about that, as i said it would be easy to refactor, i don't really care where 
that logic is
   * you've add a protected getPaths method to SolrConfig which exposes a 
NamedList of FileFilter objects -- this feels very hackish to me, not just 
because the method name is very vague, and not just because it uses NamedList 
in an odd way, but because it changes made to the contents of the directory at 
runtime would be returned by anyone attempting to use these FileFilters later, 
but that won't accurately express the state of the paths when the 
SolrResourceLoader (that SolrConfig still has a refrence to) was initialized.  
Since it's not certain if this is really what should hapen if/when people 
re-use a SolrConfig, this may have to change anyway, and illustrates why i felt 
like it was better not to try and get ahead of ourselves now.
   * You've moved the responsibility of modifying the classpath (and 
completeling the initialization of SolrResourceLoader) to SolrCore...

...this last change  demonstrates the *exact* bug i explained i was trying to 
avoid:  An embedded Solr user who constructs their own SolrConfig object will 
then have an incomplete SolrResourceLoader (with a Classpath that hasn't been 
fully intialized yet) which they might use prior to passing that SolrConfig 
object to hte constructor of SolrCore.

This may be an esoteric example, and not likely to cause problems for anyone in 
practice -- but why risk introducing a bug at all when it's *EASIER* to make it 
work for _everyone_ by letting SolrConfig be responsible for initializing it?

Nothing in your patch is going to save work down the road when it comes time to 
*actually* decouple SolrConfig from SolrResourceLoader ... all you've done here 
is make it harder to use SolrConifg today.  At somepoint, to reuse SolrConfigs, 
we're going to need to break the existing public SolrConfig constructors, and 
force legacy embedded Solr users to change the way they construct their 
SolrCore + SolrConfig + SolrResourceLoader, so why not wait until then to worry 
about this bullshit so we can fix SolrResourceLoader initialization the _right_ 
way by making people construct a SolrConfig _before_ constructing a 
SolrResourceLoader and passing the jar paths in to the SolrResourceLoader 
constructor?!

-

Honestly though, it's a waste of time to keep arguing about any of this now, 
because it's really just a moot fucking issue at this point.


I posted this patch almost 3 weeks ago, hoping I could get at least one other 
person to test it within a few days, so I could commit it and we could smoke 
test it on the trunk for at least a week or two before starting the release 
process for 1.4.  But at this point only Noble and Miller have acknowledged 
reading the patch -- miller hasn't acknowledged running/testing it, and noble 
and I can't agree on how it should be implemented.  Grant's goal (last I heard) 
was to start the release early next week, and even if we all magically agreed 
on what the best patch looked like, and one or two people stepped up and said 
they tested it, I still wouldn't feel comfortable commiting a change to 
existing functionality like this so close to the release date.

I think we need to postpone this to 1.5.



> solrconfig.xml syntax to add classpath elements from outside of instanceDir
> ---
>
> Key: SOLR-1449
> URL: https://issues.apache.org/jira/browse/SOLR-1449
> Project: Solr
>  Issue Type: Improvement
>Reporter: Hoss Man
>Assignee: Hoss Man
> Fix For: 1.4
>
> Attachments: SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch, 
> SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch, 
> SOLR-1449.patch,

Re: Down to 5

2009-10-08 Thread Jason Rutherglen

I haven't had any time to verify this, we're not currently
recording the HTML that failed which I'd use to reproduce with a
test case. Though when I do, it should be fairly comprehensive,
though I'm not sure I'd be able to fit it all in an actual unit
test unless the HTML was in files which probably shouldn't be in
a patch.

Though to confirm, I am still seeing multiple errors from this
bug. Perhaps on the weekend I'll work on it?

On Thu, Oct 8, 2009 at 3:54 PM, Yonik Seeley  wrote:
> One further issue... should we commit the changes to the HTMLStripReader?
> https://issues.apache.org/jira/browse/SOLR-1394
>
> -Yonik
> http://www.lucidimagination.com
>
> On Thu, Oct 8, 2009 at 6:47 PM, Yonik Seeley  
> wrote:
>> On Sun, Oct 4, 2009 at 6:13 PM, Grant Ingersoll  wrote:
>>> Coming along:
>>>  https://issues.apache.org/jira/secure/BrowseVersion.jspa?id=12310230&versionId=12313351&showOpenIssuesOnly=true
>>>
>>> If we can finish these up this week, I can generate RCs next week.
>>
>> Down to 4!  We're still planning on a code freeze at the end of this
>> week, right?  I think all of the targeted issues are just waiting for
>> the final commits?
>>
>> SOLR-1458        Java Replication error: NullPointerException SEVERE:
>> SnapPull failed on 2009-09-22 nightly
>> SOLR-1449       solrconfig.xml syntax to add classpath elements from
>> outside of instanceDir
>> SOLR-1497       Remove solrjs from svn -- point docs to AJAX Solr
>> SOLR-1475       Java-based replication doesn't properly reserve its commit
>> point during backups
>>
>> Other issues:
>>  - Do we just bag chinese for now and force people to write their own
>> factories? SOLR-1336
>>  - Does the Lucene 2.9 bugfix branch have anything warranting upgrading to 
>> it?
>>
>> -Yonik
>> http://www.lucidimagination.com
>>
>

[jira] Updated: (SOLR-792) Tree Faceting Component

2009-10-08 Thread Jeremy Hinegardner (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hinegardner updated SOLR-792:


Attachment: SOLR-792.patch

Update to apply cleanly against trunk.

> Tree Faceting Component
> ---
>
> Key: SOLR-792
> URL: https://issues.apache.org/jira/browse/SOLR-792
> Project: Solr
>  Issue Type: New Feature
>Reporter: Erik Hatcher
>Assignee: Erik Hatcher
>Priority: Minor
> Attachments: SOLR-792.patch, SOLR-792.patch, SOLR-792.patch, 
> SOLR-792.patch
>
>
> A component to do multi-level faceting.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Down to 5

2009-10-08 Thread Yonik Seeley

One further issue... should we commit the changes to the HTMLStripReader?
https://issues.apache.org/jira/browse/SOLR-1394

-Yonik
http://www.lucidimagination.com

On Thu, Oct 8, 2009 at 6:47 PM, Yonik Seeley  wrote:
> On Sun, Oct 4, 2009 at 6:13 PM, Grant Ingersoll  wrote:
>> Coming along:
>>  https://issues.apache.org/jira/secure/BrowseVersion.jspa?id=12310230&versionId=12313351&showOpenIssuesOnly=true
>>
>> If we can finish these up this week, I can generate RCs next week.
>
> Down to 4!  We're still planning on a code freeze at the end of this
> week, right?  I think all of the targeted issues are just waiting for
> the final commits?
>
> SOLR-1458        Java Replication error: NullPointerException SEVERE:
> SnapPull failed on 2009-09-22 nightly
> SOLR-1449       solrconfig.xml syntax to add classpath elements from
> outside of instanceDir
> SOLR-1497       Remove solrjs from svn -- point docs to AJAX Solr
> SOLR-1475       Java-based replication doesn't properly reserve its commit
> point during backups
>
> Other issues:
>  - Do we just bag chinese for now and force people to write their own
> factories? SOLR-1336
>  - Does the Lucene 2.9 bugfix branch have anything warranting upgrading to it?
>
> -Yonik
> http://www.lucidimagination.com
>

Re: Down to 5

2009-10-08 Thread Yonik Seeley

On Sun, Oct 4, 2009 at 6:13 PM, Grant Ingersoll  wrote:
> Coming along:
>  https://issues.apache.org/jira/secure/BrowseVersion.jspa?id=12310230&versionId=12313351&showOpenIssuesOnly=true
>
> If we can finish these up this week, I can generate RCs next week.

Down to 4!  We're still planning on a code freeze at the end of this
week, right?  I think all of the targeted issues are just waiting for
the final commits?

SOLR-1458Java Replication error: NullPointerException SEVERE:
SnapPull failed on 2009-09-22 nightly
SOLR-1449   solrconfig.xml syntax to add classpath elements from
outside of instanceDir
SOLR-1497   Remove solrjs from svn -- point docs to AJAX Solr
SOLR-1475   Java-based replication doesn't properly reserve its commit
point during backups

Other issues:
 - Do we just bag chinese for now and force people to write their own
factories? SOLR-1336
 - Does the Lucene 2.9 bugfix branch have anything warranting upgrading to it?

-Yonik
http://www.lucidimagination.com

[jira] Updated: (SOLR-433) MultiCore and SpellChecker replication

2009-10-08 Thread Jeremy Hinegardner (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-433?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy Hinegardner updated SOLR-433:


Attachment: SOLR-433.patch

I've updated the patch to apply cleanly against trunk.

> MultiCore and SpellChecker replication
> --
>
> Key: SOLR-433
> URL: https://issues.apache.org/jira/browse/SOLR-433
> Project: Solr
>  Issue Type: Improvement
>  Components: replication (scripts), spellchecker
>Affects Versions: 1.3
>Reporter: Otis Gospodnetic
> Fix For: 1.5
>
> Attachments: RunExecutableListener.patch, SOLR-433-r698590.patch, 
> SOLR-433.patch, SOLR-433.patch, SOLR-433.patch, SOLR-433.patch, 
> solr-433.patch, SOLR-433_unified.patch, spellindexfix.patch
>
>
> With MultiCore functionality coming along, it looks like we'll need to be 
> able to:
>   A) snapshot each core's index directory, and
>   B) replicate any and all cores' complete data directories, not just their 
> index directories.
> Pulled from the "spellchecker and multi-core index replication" thread - 
> http://markmail.org/message/pj2rjzegifd6zm7m
> Otis:
> I think that makes sense - distribute everything for a given core, not just 
> its index.  And the spellchecker could then also have its data dir (and only 
> index/ underneath really) and be replicated in the same fashion.
> Right?
> Ryan:
> Yes, that was my thought.  If an arbitrary directory could be distributed, 
> then you could have
>   /path/to/dist/index/...
>   /path/to/dist/spelling-index/...
>   /path/to/dist/foo
> and that would all get put into a snapshot.  This would also let you put 
> multiple cores within a single distribution:
>   /path/to/dist/core0/index/...
>   /path/to/dist/core0/spelling-index/...
>   /path/to/dist/core0/foo
>   /path/to/dist/core1/index/...
>   /path/to/dist/core1/spelling-index/...
>   /path/to/dist/core1/foo

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1483) Example schema is confusing with int, tint and pint fields


[ 
https://issues.apache.org/jira/browse/SOLR-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763665#action_12763665
 ] 

Mark Miller commented on SOLR-1483:
---

Yeah - I was basing my comment purely on the conversation with Shalin - hadn't 
looked.

> Example schema is confusing with int, tint and pint fields
> --
>
> Key: SOLR-1483
> URL: https://issues.apache.org/jira/browse/SOLR-1483
> Project: Solr
>  Issue Type: Bug
>  Components: documentation
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
> Attachments: SOLR-1483.patch, SOLR-1483.patch, SOLR-1483.patch
>
>
> Example schema defines int (TrieIntField), tint (TrieIntField) and pint 
> (IntField) which is confusing. In particular, the comments for int fields 
> tell users to use tint types (which is the same thing).
> Let us remove tint, tlong, tdouble, tdate types from example schemas and fix 
> the comments - carefully noting the things trie fields do not work with.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1483) Example schema is confusing with int, tint and pint fields


[ 
https://issues.apache.org/jira/browse/SOLR-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763657#action_12763657
 ] 

Yonik Seeley commented on SOLR-1483:


bq. considering it unsupported without saying such is not very helpful to a 
user...

We currently list exactly the types that support sortMissingLast... that's good 
enough, right?

> Example schema is confusing with int, tint and pint fields
> --
>
> Key: SOLR-1483
> URL: https://issues.apache.org/jira/browse/SOLR-1483
> Project: Solr
>  Issue Type: Bug
>  Components: documentation
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
> Attachments: SOLR-1483.patch, SOLR-1483.patch, SOLR-1483.patch
>
>
> Example schema defines int (TrieIntField), tint (TrieIntField) and pint 
> (IntField) which is confusing. In particular, the comments for int fields 
> tell users to use tint types (which is the same thing).
> Let us remove tint, tlong, tdouble, tdate types from example schemas and fix 
> the comments - carefully noting the things trie fields do not work with.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (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
 ]

Yonik Seeley resolved SOLR-1145.


Resolution: Fixed

committed changes to example, as well as a NPE fix for files without a parent 
specified.

> 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
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1145.patch, SOLR-1145.patch, SOLR-1145.patch, 
> 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-1145) Patch to set IndexWriter.defaultInfoStream from solr.xml


[ 
https://issues.apache.org/jira/browse/SOLR-1145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763633#action_12763633
 ] 

Yonik Seeley commented on SOLR-1145:


OK, I found it... the example has infoStream in the indexDefaults section and 
not the mainIndex section.
 
Not sure if intoStream should be supported as a default or not.
Perhaps just move the example to mainIndex for now?

> 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
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1145.patch, SOLR-1145.patch, SOLR-1145.patch, 
> 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] Reopened: (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
 ]

Yonik Seeley reopened SOLR-1145:



Reopening... I can't get it to work either.
http://search.lucidimagination.com/search/document/9cd31d75526236f1/indexwriter_infostream_in_solrconfig_not_working

> 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
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1145.patch, SOLR-1145.patch, SOLR-1145.patch, 
> 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] Resolved: (SOLR-1448) Addition of weblogic.xml required for solr to run under weblogic 10.3


 [ 
https://issues.apache.org/jira/browse/SOLR-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yonik Seeley resolved SOLR-1448.


Resolution: Fixed

Thanks Ilan, I just committed this.

> Addition of weblogic.xml required for solr to run under weblogic 10.3
> -
>
> Key: SOLR-1448
> URL: https://issues.apache.org/jira/browse/SOLR-1448
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 1.4
> Environment: Weblogic 10.3
>Reporter: Ilan Rabinovitch
>Assignee: Yonik Seeley
>Priority: Minor
> Fix For: 1.4
>
> Attachments: weblogic.xml
>
>
> Weblogic appears to have filters enabled even on FORWARD, which is listed as 
> something that will not function properly in the Solr documentation. As a 
> result, the administrative application generates a StackOverflow when 
> accessed. 
> This can be resolved by adding the attached weblogic.xml file to solr.  No 
> other changes are required.
> 
>  xmlns="http://www.bea.com/ns/weblogic/90";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 
> http://www.bea.com/ns/weblogic/90/weblogic-web-app.xsd";>
> 
> 
> false
> 
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (SOLR-1448) Addition of weblogic.xml required for solr to run under weblogic 10.3


 [ 
https://issues.apache.org/jira/browse/SOLR-1448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yonik Seeley reassigned SOLR-1448:
--

Assignee: Yonik Seeley

> Addition of weblogic.xml required for solr to run under weblogic 10.3
> -
>
> Key: SOLR-1448
> URL: https://issues.apache.org/jira/browse/SOLR-1448
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 1.4
> Environment: Weblogic 10.3
>Reporter: Ilan Rabinovitch
>Assignee: Yonik Seeley
>Priority: Minor
> Fix For: 1.4
>
> Attachments: weblogic.xml
>
>
> Weblogic appears to have filters enabled even on FORWARD, which is listed as 
> something that will not function properly in the Solr documentation. As a 
> result, the administrative application generates a StackOverflow when 
> accessed. 
> This can be resolved by adding the attached weblogic.xml file to solr.  No 
> other changes are required.
> 
>  xmlns="http://www.bea.com/ns/weblogic/90";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://www.bea.com/ns/weblogic/90 
> http://www.bea.com/ns/weblogic/90/weblogic-web-app.xsd";>
> 
> 
> false
> 
> 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: archive solrjs and point to AJAX Solr?

2009-10-08 Thread James McKinney

(sent this from the wrong address, sorry if it double-posts)
Based on the feedback from other members of the mailing list, it seems
like AJAX Solr has become the "blessed" JavaScript client, inheriting
that status from SolrJS. I'm not aware of other Solr JavaScript
clients. In any case, I support the creation of a wiki page dedicated
to JavaScript clients generally, as opposed to any JavaScript client
specifically, if only to prevent confusion as to what the status of
each of the libraries is.

On Thu, Oct 8, 2009 at 11:57 AM, Eric Pugh
wrote:

> So one thing that I think is key to minimizing confusion is to write up
> some sort of "State of the JavaScript Clients" section on the Solr wiki.
>  Either as part of this page: http://wiki.apache.org/solr/SolrJS, or
> create a http://wiki.apache.org/solr/SolrJavascriptClients page.  And try
> and get everyone (solrstuff.org, AjaxSolr) to point to it as the master
> "status" page for all the libraries.  Otherwise we may continue to see
> rampant confusion among all the JS libraries.
>
> I always found the various widgets for jQuery quite confusing because some
> are hosted on jQuery.org, while others are called things like "jQuery
> Calender Widget", but aren't official jQuery widgets!
>
> If we want to do this, I'll volunteer to take a crack at the State of the
> Javascript Clients page, and lay it out in a way that lists
> pros/cons/status, so that as other libraries are created, others can fill it
> out.  Think somewhat like the CI Feature Matrix page (
> http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix).
>
>
>
> Eric
>
>
>
>
> On Oct 7, 2009, at 9:59 PM, Grant Ingersoll wrote:
>
>
>> On Oct 7, 2009, at 7:04 PM, James McKinney wrote:
>>
>>  I've just now changed the licensing of AJAX Solr to just be ASL, as
>>> tri-licensing was confusing.
>>> If I were to distribute the code on drupal.org, it would have to be GPL,
>>> but
>>> drupal.org prohibits distribution of code that is available elsewhere,
>>> so I
>>> can't distribute it there, and so don't need to make it GPL after all.
>>>
>>
>> So, we've come full circle...  At any rate, good luck!
>>
>>
>>> On Wed, Oct 7, 2009 at 5:26 PM, Grant Ingersoll 
>>> wrote:
>>>
>>>  Doing this effectively means it isn't likely to ever come back to Solr.
  If
 it did, it would likely have to go through Software Grant/Incubation,
 since
 they are allowing people to contribute pretty freely via git.  I
 personally
 don't care either way, but people should be aware of the implications.

 I also personally don't know what it means to have something be licensed
 3
 different ways.  Why not just make it public domain?  I was under the
 impression GNU doesn't think the ASL is compatible, but maybe that has
 changed.  At any rate, I don't want to start a licensing debate.

 So, if the two people responsible for putting the code in (Ryan and
 Matthias) are +1, then so am I.  I personally don't see myself ever
 working
 to maintain it, but who knows.

 -Grant


 On Oct 7, 2009, at 1:24 AM, Ryan McKinley wrote:

 I don't think solrjs should hold up the 1.4 release.

>
> Since this issue was last discussed, James McKinney has licensed AJAX
> Solr
> (a solrjs fork) under Apache & MIT
> http://github.com/evolvingweb/AJAX-Solr/blob/master/COPYRIGHT.txt
>
> It seems like this has good support and gets the on-going attention it
> deserves.
>
> I suggest we archive solrjs -- remove it from the 1.4 release -- and
> point
> javascript client lovers to AJAX-Solr.
>
> If we do "archive" solrjs, what do you think the best method is?
> 1. svn copy it to /sandbox?
> 2. make a zip and place it on an external site, remove it entirely from
> solr svn
>
> I lean towards option 1.
>
> thoughts
> ryan
>
>


>> --
>> 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
> Co-Author: Solr 1.4 Enterprise Search Server available from
> http://www.packtpub.com/solr-1-4-enterprise-search-server
> Free/Busy: http://tinyurl.com/eric-cal
>
>
>
>
>
>
>
>
>

[jira] Commented: (SOLR-1475) Java-based replication doesn't properly reserve its commit point during backups


[ 
https://issues.apache.org/jira/browse/SOLR-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763571#action_12763571
 ] 

Mark Miller commented on SOLR-1475:
---

Grrr - NM - at first blush it appears that chunking kills the cpu win - makes 
sense - before it uses cpu at the start, then stops using - I guess now there 
are lots of starts. Not seeing a win at all anymore.

> Java-based replication doesn't properly reserve its commit point during 
> backups
> ---
>
> Key: SOLR-1475
> URL: https://issues.apache.org/jira/browse/SOLR-1475
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java)
>Affects Versions: 1.4
>Reporter: Chris Harris
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1475.patch, SOLR-1475.patch, SOLR-1475.patch
>
>
> The issue title reflects Mark Miller's initial diagnosis of the problem.
> Here are my symptoms:
> This is regarding the backup feature of replication, as opposed to 
> replication. Backups seem to work fine on toy indexes. When trying backups 
> out on a copy of my production index (300GB-ish), though, I'm getting 
> FileNotFoundExceptions. These cancel the backup, and delete the 
> snapshot.mmdd* directory. It seems reproducible, in that every time I try 
> to make a backup of my large index it will fail the same way.
> This is Solr r815830. I'm not sure if this is something that would 
> potentially be addressed by SOLR-1458? (That patch is from after r815830.)
> For now I'm not using any event-based backup triggers; instead I'm manually 
> hitting
> http://master_host:port/solr/replication?command=backup
> This successfully sets off a snapshot, as seen in a thread dump.  However, 
> after a while the snapshot fails. I'll paste in a couple of stack traces 
> below.
> I haven't seen any other evidence that my index is corrupt; in particular, 
> searching the index and Java-based replication seem to be working fine, and 
> the Lucene CheckIndex tool did not report any problems with the index.
> 
> {code}
> Sep 28, 2009 9:32:18 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\_y0w.fnm' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at 
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at 
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> Sep 28, 2009 10:39:43 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\segments_by' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at 
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at 
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> Sep 28, 2009 11:52:08 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\_yby.nrm' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at 
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at 
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> {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-1475) Java-based replication doesn't properly reserve its commit point during backups


[ 
https://issues.apache.org/jira/browse/SOLR-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763541#action_12763541
 ] 

Yonik Seeley commented on SOLR-1475:


Hmmm, maybe it's trying to set up a DMA for the complete thing or something, 
and the unflushed write buffers are in the way (and hence need to be flushed).

> Java-based replication doesn't properly reserve its commit point during 
> backups
> ---
>
> Key: SOLR-1475
> URL: https://issues.apache.org/jira/browse/SOLR-1475
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java)
>Affects Versions: 1.4
>Reporter: Chris Harris
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1475.patch, SOLR-1475.patch, SOLR-1475.patch
>
>
> The issue title reflects Mark Miller's initial diagnosis of the problem.
> Here are my symptoms:
> This is regarding the backup feature of replication, as opposed to 
> replication. Backups seem to work fine on toy indexes. When trying backups 
> out on a copy of my production index (300GB-ish), though, I'm getting 
> FileNotFoundExceptions. These cancel the backup, and delete the 
> snapshot.mmdd* directory. It seems reproducible, in that every time I try 
> to make a backup of my large index it will fail the same way.
> This is Solr r815830. I'm not sure if this is something that would 
> potentially be addressed by SOLR-1458? (That patch is from after r815830.)
> For now I'm not using any event-based backup triggers; instead I'm manually 
> hitting
> http://master_host:port/solr/replication?command=backup
> This successfully sets off a snapshot, as seen in a thread dump.  However, 
> after a while the snapshot fails. I'll paste in a couple of stack traces 
> below.
> I haven't seen any other evidence that my index is corrupt; in particular, 
> searching the index and Java-based replication seem to be working fine, and 
> the Lucene CheckIndex tool did not report any problems with the index.
> 
> {code}
> Sep 28, 2009 9:32:18 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\_y0w.fnm' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at 
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at 
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> Sep 28, 2009 10:39:43 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\segments_by' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at 
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at 
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> Sep 28, 2009 11:52:08 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\_yby.nrm' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at 
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at 
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> {code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: archive solrjs and point to AJAX Solr?

2009-10-08 Thread Eric Pugh

So one thing that I think is key to minimizing confusion is to write
up some sort of "State of the JavaScript Clients" section on the Solr
wiki. Either as part of this page: http://wiki.apache.org/solr/
SolrJS, or create a http://wiki.apache.org/solr/SolrJavascriptClients
page. And try and get everyone (solrstuff.org, AjaxSolr) to point to
it as the master "status" page for all the libraries. Otherwise we
may continue to see rampant confusion among all the JS libraries.

I always found the various widgets for jQuery quite confusing because
some are hosted on jQuery.org, while others are called things like
"jQuery Calender Widget", but aren't official jQuery widgets!

If we want to do this, I'll volunteer to take a crack at the State of
the Javascript Clients page, and lay it out in a way that lists pros/
cons/status, so that as other libraries are created, others can fill
it out. Think somewhat like the CI Feature Matrix page (http://confluence.public.thoughtworks.org/display/CC/CI+Feature+Matrix
).

Eric

On Oct 7, 2009, at 9:59 PM, Grant Ingersoll wrote:

On Oct 7, 2009, at 7:04 PM, James McKinney wrote:

I've just now changed the licensing of AJAX Solr to just be ASL, as
tri-licensing was confusing.
If I were to distribute the code on drupal.org, it would have to be
GPL, but
drupal.org prohibits distribution of code that is available
elsewhere, so I
can't distribute it there, and so don't need to make it GPL after
all.

So, we've come full circle... At any rate, good luck!

On Wed, Oct 7, 2009 at 5:26 PM, Grant Ingersoll
wrote:

Doing this effectively means it isn't likely to ever come back to
Solr. If
it did, it would likely have to go through Software Grant/
Incubation, since
they are allowing people to contribute pretty freely via git. I
personally
don't care either way, but people should be aware of the
implications.

I also personally don't know what it means to have something be
licensed 3
different ways. Why not just make it public domain? I was under
the
impression GNU doesn't think the ASL is compatible, but maybe that
has

changed. At any rate, I don't want to start a licensing debate.

So, if the two people responsible for putting the code in (Ryan and
Matthias) are +1, then so am I. I personally don't see myself
ever working

to maintain it, but who knows.

-Grant

On Oct 7, 2009, at 1:24 AM, Ryan McKinley wrote:

I don't think solrjs should hold up the 1.4 release.

Since this issue was last discussed, James McKinney has licensed
AJAX Solr

(a solrjs fork) under Apache & MIT
http://github.com/evolvingweb/AJAX-Solr/blob/master/COPYRIGHT.txt

It seems like this has good support and gets the on-going
attention it

deserves.

I suggest we archive solrjs -- remove it from the 1.4 release --
and point

javascript client lovers to AJAX-Solr.

If we do "archive" solrjs, what do you think the best method is?
1. svn copy it to /sandbox?
2. make a zip and place it on an external site, remove it
entirely from

solr svn

I lean towards option 1.

thoughts
ryan

--
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
Co-Author: Solr 1.4 Enterprise Search Server available from
http://www.packtpub.com/solr-1-4-enterprise-search-server
Free/Busy: http://tinyurl.com/eric-cal

[jira] Commented: (SOLR-1475) Java-based replication doesn't properly reserve its commit point during backups


[ 
https://issues.apache.org/jira/browse/SOLR-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763528#action_12763528
 ] 

Mark Miller commented on SOLR-1475:
---

bq. transferTo to a different file, not the same one, right?

Yes - different files first with the stream, then Channel on the 2 gig large 
file - but it turned out to be because I was transfering the whole thing in one 
go (some bad advice I read). Chunking by 10 MB removes the issue.

bq. hmmm, so transferTo causes the write buffers to be flushed or something?

Certainly does something you don't want to do ;) Takes a while for my system to 
recover after that as well. But like I said, chunking appears to solve.

> Java-based replication doesn't properly reserve its commit point during 
> backups
> ---
>
> Key: SOLR-1475
> URL: https://issues.apache.org/jira/browse/SOLR-1475
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java)
>Affects Versions: 1.4
>Reporter: Chris Harris
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1475.patch, SOLR-1475.patch, SOLR-1475.patch
>
>
> The issue title reflects Mark Miller's initial diagnosis of the problem.
> Here are my symptoms:
> This is regarding the backup feature of replication, as opposed to 
> replication. Backups seem to work fine on toy indexes. When trying backups 
> out on a copy of my production index (300GB-ish), though, I'm getting 
> FileNotFoundExceptions. These cancel the backup, and delete the 
> snapshot.mmdd* directory. It seems reproducible, in that every time I try 
> to make a backup of my large index it will fail the same way.
> This is Solr r815830. I'm not sure if this is something that would 
> potentially be addressed by SOLR-1458? (That patch is from after r815830.)
> For now I'm not using any event-based backup triggers; instead I'm manually 
> hitting
> http://master_host:port/solr/replication?command=backup
> This successfully sets off a snapshot, as seen in a thread dump.  However, 
> after a while the snapshot fails. I'll paste in a couple of stack traces 
> below.
> I haven't seen any other evidence that my index is corrupt; in particular, 
> searching the index and Java-based replication seem to be working fine, and 
> the Lucene CheckIndex tool did not report any problems with the index.
> 
> {code}
> Sep 28, 2009 9:32:18 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\_y0w.fnm' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at 
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at 
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> Sep 28, 2009 10:39:43 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\segments_by' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at 
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at 
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> Sep 28, 2009 11:52:08 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\_yby.nrm' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at 
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at 
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> {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-1475) Java-based replication doesn't properly reserve its commit point during backups


[ 
https://issues.apache.org/jira/browse/SOLR-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763525#action_12763525
 ] 

Yonik Seeley commented on SOLR-1475:


interesting... I guess we should be safe and just use the old stream copying 
for now.

Just out of curiosity though:
bq.  if you do a bunch of stream copying first - and then use transfer

transferTo to a different file, not the same one, right?

bq. - its a dog - the more copying first, the worse it appears to be.

hmmm, so transferTo causes the write buffers to be flushed or something?

> Java-based replication doesn't properly reserve its commit point during 
> backups
> ---
>
> Key: SOLR-1475
> URL: https://issues.apache.org/jira/browse/SOLR-1475
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java)
>Affects Versions: 1.4
>Reporter: Chris Harris
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1475.patch, SOLR-1475.patch, SOLR-1475.patch
>
>
> The issue title reflects Mark Miller's initial diagnosis of the problem.
> Here are my symptoms:
> This is regarding the backup feature of replication, as opposed to 
> replication. Backups seem to work fine on toy indexes. When trying backups 
> out on a copy of my production index (300GB-ish), though, I'm getting 
> FileNotFoundExceptions. These cancel the backup, and delete the 
> snapshot.mmdd* directory. It seems reproducible, in that every time I try 
> to make a backup of my large index it will fail the same way.
> This is Solr r815830. I'm not sure if this is something that would 
> potentially be addressed by SOLR-1458? (That patch is from after r815830.)
> For now I'm not using any event-based backup triggers; instead I'm manually 
> hitting
> http://master_host:port/solr/replication?command=backup
> This successfully sets off a snapshot, as seen in a thread dump.  However, 
> after a while the snapshot fails. I'll paste in a couple of stack traces 
> below.
> I haven't seen any other evidence that my index is corrupt; in particular, 
> searching the index and Java-based replication seem to be working fine, and 
> the Lucene CheckIndex tool did not report any problems with the index.
> 
> {code}
> Sep 28, 2009 9:32:18 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\_y0w.fnm' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at 
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at 
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> Sep 28, 2009 10:39:43 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\segments_by' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at 
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at 
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> Sep 28, 2009 11:52:08 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\_yby.nrm' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at 
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at 
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> {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-1475) Java-based replication doesn't properly reserve its commit point during backups


[ 
https://issues.apache.org/jira/browse/SOLR-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763523#action_12763523
 ] 

Mark Miller commented on SOLR-1475:
---

I see the issue - I read somewhere that you don't want/need to chunk the 
transfer - but you certainly do. That mostly takes care of it. It still appears 
a bit slower after a lot of IO, but not really enough to matter and probably 
worth the lower cpu.

The windows server results are still scary though - perhaps we should only use 
transfer on when detecting non windows?

> Java-based replication doesn't properly reserve its commit point during 
> backups
> ---
>
> Key: SOLR-1475
> URL: https://issues.apache.org/jira/browse/SOLR-1475
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java)
>Affects Versions: 1.4
>Reporter: Chris Harris
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1475.patch, SOLR-1475.patch, SOLR-1475.patch
>
>
> The issue title reflects Mark Miller's initial diagnosis of the problem.
> Here are my symptoms:
> This is regarding the backup feature of replication, as opposed to 
> replication. Backups seem to work fine on toy indexes. When trying backups 
> out on a copy of my production index (300GB-ish), though, I'm getting 
> FileNotFoundExceptions. These cancel the backup, and delete the 
> snapshot.mmdd* directory. It seems reproducible, in that every time I try 
> to make a backup of my large index it will fail the same way.
> This is Solr r815830. I'm not sure if this is something that would 
> potentially be addressed by SOLR-1458? (That patch is from after r815830.)
> For now I'm not using any event-based backup triggers; instead I'm manually 
> hitting
> http://master_host:port/solr/replication?command=backup
> This successfully sets off a snapshot, as seen in a thread dump.  However, 
> after a while the snapshot fails. I'll paste in a couple of stack traces 
> below.
> I haven't seen any other evidence that my index is corrupt; in particular, 
> searching the index and Java-based replication seem to be working fine, and 
> the Lucene CheckIndex tool did not report any problems with the index.
> 
> {code}
> Sep 28, 2009 9:32:18 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\_y0w.fnm' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at 
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at 
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> Sep 28, 2009 10:39:43 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\segments_by' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at 
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at 
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> Sep 28, 2009 11:52:08 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\_yby.nrm' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at 
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at 
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> {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-1475) Java-based replication doesn't properly reserve its commit point during backups


[ 
https://issues.apache.org/jira/browse/SOLR-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763518#action_12763518
 ] 

Mark Miller commented on SOLR-1475:
---

transfer does use less cpu -

it appears to work like this:

if you just load up the JVM and transfer the 2 gig test file I am using, 
transfer is actually a bit faster to roughly similar. Generally a bit faster.

*but*

if you do a bunch of stream copying first - and then use transfer - its a *dog* 
- the more copying first, the worse it appears to be.

But stream copying does not appear to degrade like that ...

I'm using a 1 gig heap for these tests.

> Java-based replication doesn't properly reserve its commit point during 
> backups
> ---
>
> Key: SOLR-1475
> URL: https://issues.apache.org/jira/browse/SOLR-1475
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java)
>Affects Versions: 1.4
>Reporter: Chris Harris
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1475.patch, SOLR-1475.patch, SOLR-1475.patch
>
>
> The issue title reflects Mark Miller's initial diagnosis of the problem.
> Here are my symptoms:
> This is regarding the backup feature of replication, as opposed to 
> replication. Backups seem to work fine on toy indexes. When trying backups 
> out on a copy of my production index (300GB-ish), though, I'm getting 
> FileNotFoundExceptions. These cancel the backup, and delete the 
> snapshot.mmdd* directory. It seems reproducible, in that every time I try 
> to make a backup of my large index it will fail the same way.
> This is Solr r815830. I'm not sure if this is something that would 
> potentially be addressed by SOLR-1458? (That patch is from after r815830.)
> For now I'm not using any event-based backup triggers; instead I'm manually 
> hitting
> http://master_host:port/solr/replication?command=backup
> This successfully sets off a snapshot, as seen in a thread dump.  However, 
> after a while the snapshot fails. I'll paste in a couple of stack traces 
> below.
> I haven't seen any other evidence that my index is corrupt; in particular, 
> searching the index and Java-based replication seem to be working fine, and 
> the Lucene CheckIndex tool did not report any problems with the index.
> 
> {code}
> Sep 28, 2009 9:32:18 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\_y0w.fnm' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at 
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at 
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> Sep 28, 2009 10:39:43 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\segments_by' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at 
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at 
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> Sep 28, 2009 11:52:08 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\_yby.nrm' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at 
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at 
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> {code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (SOLR-1498) RegexTransformer: sourceColName version not handling multiValued fields correctly

2009-10-08 Thread Chantal Ackermann (JIRA)

RegexTransformer: sourceColName version not handling multiValued fields 
correctly
-

 Key: SOLR-1498
 URL: https://issues.apache.org/jira/browse/SOLR-1498
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler
Affects Versions: 1.4
 Environment: Windows XP, JDK 6, Tomcat 6
Linux (RedHat), JDK, Tomcat 5
Reporter: Chantal Ackermann


Versions in use/compared:
Solr 1.3
(Nightly 5th August)
Nightly 22nd September

As RegexTransformer is not different between the two nightlies, the
issue probably appeared before.

ISSUE:
Using RegexTransformer with the 'sourceColName' notation will not populate
multiValued (actually containing multiple values) fields with a list but
instead add only one value per document.

The version with 'groupNames' does.

worked for 1.3 (regression):




works for nightly 22nd Sept:


(Both fields are of type solr.StrField and multiValued.)


Comparing the source code of RegexTransformer 1.3 vs. 22nd Sept, I found:

for (Object result : results)
 row.put(col, result);

(lines 106-107 of transformRow() 22nd of Sept)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1475) Java-based replication doesn't properly reserve its commit point during backups

2009-10-08 Thread Noble Paul നോബിള്‍ नोब्ळ्


[ 
https://issues.apache.org/jira/browse/SOLR-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763503#action_12763503
 ] 

Yonik Seeley commented on SOLR-1475:


bq. streams is looking much better on multi gig files

Grrr... sun messed this up too?
Related: LUCENE-1121 HADOOP-3164

Do you see a CPU consumption difference when using transferTo?

> Java-based replication doesn't properly reserve its commit point during 
> backups
> ---
>
> Key: SOLR-1475
> URL: https://issues.apache.org/jira/browse/SOLR-1475
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java)
>Affects Versions: 1.4
>Reporter: Chris Harris
>Assignee: Mark Miller
> Fix For: 1.4
>
> Attachments: SOLR-1475.patch, SOLR-1475.patch, SOLR-1475.patch
>
>
> The issue title reflects Mark Miller's initial diagnosis of the problem.
> Here are my symptoms:
> This is regarding the backup feature of replication, as opposed to 
> replication. Backups seem to work fine on toy indexes. When trying backups 
> out on a copy of my production index (300GB-ish), though, I'm getting 
> FileNotFoundExceptions. These cancel the backup, and delete the 
> snapshot.mmdd* directory. It seems reproducible, in that every time I try 
> to make a backup of my large index it will fail the same way.
> This is Solr r815830. I'm not sure if this is something that would 
> potentially be addressed by SOLR-1458? (That patch is from after r815830.)
> For now I'm not using any event-based backup triggers; instead I'm manually 
> hitting
> http://master_host:port/solr/replication?command=backup
> This successfully sets off a snapshot, as seen in a thread dump.  However, 
> after a while the snapshot fails. I'll paste in a couple of stack traces 
> below.
> I haven't seen any other evidence that my index is corrupt; in particular, 
> searching the index and Java-based replication seem to be working fine, and 
> the Lucene CheckIndex tool did not report any problems with the index.
> 
> {code}
> Sep 28, 2009 9:32:18 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\_y0w.fnm' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at 
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at 
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> Sep 28, 2009 10:39:43 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\segments_by' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at 
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at 
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> Sep 28, 2009 11:52:08 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\_yby.nrm' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at 
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at 
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> {code}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: RegexTransformer's sourceColName version broken for multiValued fields?

You can open as issue describing the problem

On Thu, Oct 8, 2009 at 6:43 PM, Chantal Ackermann
 wrote:
> Hi there,
>
>
> (sorry for maybe posting twice.)
>
> This might be a bug - I couldn't find anything on Jira or Google.
>
>
>
> Versions in use/compared:
> Solr 1.3
> (Nightly 5th August)
> Nightly 22nd September
>
> As RegexTransformer is not different between the two nightlies, the
> issue probably appeared before.
>
> ISSUE:
> Using RegexTransformer with the sourceColName notation will not populate
> multiValued (actually containing multiple values) fields with a list but
> instead add only one value per document.
>
> WORKAROUND/WORKING CONFIG:
> I've just rerun the index with the only difference between the reruns
> being those following two different usages of RegexTransformer:
>
> (Both fields are of type solr.StrField and multiValued.)
>
>
> was working with 1.3, but not with nightly 22nd Sept:
> 
>  regex="[^\|]+\|\d+,\d+,\d+,(.*)" />
>
>
> this works with the nightly from 22nd Sept:
>  regex="([^\|]+)\|\d+,\d+,\d+,(.*)" />
>
>
> Comparing the source code of RegexTransformer 1.3 vs. 22nd Sept, I found:
>
> for (Object result : results)
>        row.put(col, result);
>
> (lines 106-107 of transformRow() 22nd of Sept)
> This looks like the list items are added using the same key over and
> over again which would explain that there is no list but only one item
> left in the end.
>
>
> Cheers!
> Chantal
>
>
>



-- 
-
Noble Paul | Principal Engineer| AOL | http://aol.com

RegexTransformer's sourceColName version broken for multiValued fields?

2009-10-08 Thread Chantal Ackermann


Hi there,


(sorry for maybe posting twice.)

This might be a bug - I couldn't find anything on Jira or Google.



Versions in use/compared:
Solr 1.3
(Nightly 5th August)
Nightly 22nd September

As RegexTransformer is not different between the two nightlies, the
issue probably appeared before.

ISSUE:
Using RegexTransformer with the sourceColName notation will not populate
multiValued (actually containing multiple values) fields with a list but
instead add only one value per document.

WORKAROUND/WORKING CONFIG:
I've just rerun the index with the only difference between the reruns
being those following two different usages of RegexTransformer:

(Both fields are of type solr.StrField and multiValued.)


was working with 1.3, but not with nightly 22nd Sept:




this works with the nightly from 22nd Sept:



Comparing the source code of RegexTransformer 1.3 vs. 22nd Sept, I found:

for (Object result : results)
row.put(col, result);

(lines 106-107 of transformRow() 22nd of Sept)
This looks like the list items are added using the same key over and
over again which would explain that there is no list but only one item
left in the end.


Cheers!
Chantal

[jira] Commented: (SOLR-1483) Example schema is confusing with int, tint and pint fields


[ 
https://issues.apache.org/jira/browse/SOLR-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12763487#action_12763487
 ] 

Mark Miller commented on SOLR-1483:
---

bq. The doubling memory issue for p-types should still be noted somewhere though

Agreed - if you can do it, considering it unsupported without saying such is 
not very helpful to a user...

> Example schema is confusing with int, tint and pint fields
> --
>
> Key: SOLR-1483
> URL: https://issues.apache.org/jira/browse/SOLR-1483
> Project: Solr
>  Issue Type: Bug
>  Components: documentation
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
> Attachments: SOLR-1483.patch, SOLR-1483.patch, SOLR-1483.patch
>
>
> Example schema defines int (TrieIntField), tint (TrieIntField) and pint 
> (IntField) which is confusing. In particular, the comments for int fields 
> tell users to use tint types (which is the same thing).
> Let us remove tint, tlong, tdouble, tdate types from example schemas and fix 
> the comments - carefully noting the things trie fields do not work with.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (SOLR-1475) Java-based replication doesn't properly reserve its commit point during backups