date:20081118


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

Shalin Shekhar Mangar updated SOLR-868:
---

Affects Version/s: (was: 1.3.1)
   1.4
Fix Version/s: (was: 1.3.1)
   1.4

Since this is a new feature, marking it for 1.4

 Prepare solrjs trunk to be integrated into contrib
 --

 Key: SOLR-868
 URL: https://issues.apache.org/jira/browse/SOLR-868
 Project: Solr
  Issue Type: Task
Affects Versions: 1.4
Reporter: Matthias Epheser
Assignee: Ryan McKinley
 Fix For: 1.4

 Attachments: solrjs.zip


 This patch includes a zipfile snapshot of current solrjs trunk. The folder 
 structure is applied to standard solr layout.  It can be extracted to 
 contrib/javascript.
 it includes a build.xml:
 * ant dist - creates a single js file and a jar that holds velocity 
 templates.
 * ant docs - creates js docs. test in browser: doc/index.html
 * ant example-init - (depends ant dist on solr root) copies the current 
 built of solr.war and solr-velocity.jar to example/testsolr/..
 * ant example-start - starts the testsolr server on port 8983
 * ant example-import - imports 3000 test data rows (requires a started 
 testserver)
 Point your browser to example/testClientside.html 
 ,example/testServerSide.html or test/reuters/index.html to see it working.

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

Build failed in Hudson: Solr-trunk #628

2008-11-18 Thread Apache Hudson Server

See http://hudson.zones.apache.org/hudson/job/Solr-trunk/628/changes

Changes:

[ryan] add empty 'build' target so ant generate-maven-artifacts works

[ryan] SOLR-803, not sure how this got removed from CHANGES.txt

[ryan] SOLR-868 -- adding some missing files.  add dist to ignore list

[ryan] SOLR-868: Adding solrjs as a contrib package: contrib/javascript.
(Matthias Epheser via ryan)

[ryan] SOLR-867 move getParsedResponse utility

[shalin] SOLR-864 -- DataImportHandler does not catch and log Errors

--
[...truncated 1874 lines...]
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.37 sec
[junit] Running org.apache.solr.core.TestQuerySenderListener
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.449 sec
[junit] Running org.apache.solr.core.TestSolrDeletionPolicy1
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 11.878 sec
[junit] Running org.apache.solr.core.TestSolrDeletionPolicy2
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.437 sec
[junit] Running org.apache.solr.handler.AnalysisRequestHandlerTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.117 sec
[junit] Running org.apache.solr.handler.MoreLikeThisHandlerTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.397 sec
[junit] Running org.apache.solr.handler.SpellCheckerRequestHandlerTest
[junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 4.843 sec
[junit] Running org.apache.solr.handler.StandardRequestHandlerTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.317 sec
[junit] Running org.apache.solr.handler.TestCSVLoader
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 8.236 sec
[junit] Running org.apache.solr.handler.TestReplicationHandler
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 22.364 sec
[junit] Running org.apache.solr.handler.XmlUpdateRequestHandlerTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.104 sec
[junit] Running org.apache.solr.handler.admin.SystemInfoHandlerTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.442 sec
[junit] Running 
org.apache.solr.handler.component.QueryElevationComponentTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 5.752 sec
[junit] Running org.apache.solr.handler.component.SearchHandlerTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.713 sec
[junit] Running org.apache.solr.handler.component.SpellCheckComponentTest
[junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 14.22 sec
[junit] Running org.apache.solr.handler.component.TermVectorComponentTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 6.368 sec
[junit] Running org.apache.solr.highlight.HighlighterConfigTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.761 sec
[junit] Running org.apache.solr.highlight.HighlighterTest
[junit] Tests run: 17, Failures: 0, Errors: 0, Time elapsed: 23.575 sec
[junit] Running org.apache.solr.request.JSONWriterTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.509 sec
[junit] Running org.apache.solr.request.SimpleFacetsTest
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 10.852 sec
[junit] Running org.apache.solr.request.TestWriterPerf
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.952 sec
[junit] Running org.apache.solr.schema.BadIndexSchemaTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.239 sec
[junit] Running org.apache.solr.schema.DateFieldTest
[junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.496 sec
[junit] Running org.apache.solr.schema.IndexSchemaTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 5.875 sec
[junit] Running org.apache.solr.schema.LegacyDateFieldTest
[junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.431 sec
[junit] Running org.apache.solr.schema.NotRequiredUniqueKeyTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.82 sec
[junit] Running org.apache.solr.schema.RequiredFieldsTest
[junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 5.075 sec
[junit] Running org.apache.solr.schema.UUIDFieldTest
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.698 sec
[junit] Running org.apache.solr.search.TestDocSet
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.864 sec
[junit] Running org.apache.solr.search.TestFastLRUCache
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.414 sec
[junit] Running org.apache.solr.search.TestQueryTypes
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.549 sec
[junit] Running org.apache.solr.search.TestQueryUtils
[junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.552 sec
[junit]

[jira] Commented: (SOLR-868) Prepare solrjs trunk to be integrated into contrib

2008-11-18 Thread Matthias Epheser (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12648534#action_12648534
 ] 

Matthias Epheser commented on SOLR-868:
---

Just noticed that we need an (empty) test target in the build.xml in order to 
get a successful build of solr trunk. 

 Prepare solrjs trunk to be integrated into contrib
 --

 Key: SOLR-868
 URL: https://issues.apache.org/jira/browse/SOLR-868
 Project: Solr
  Issue Type: Task
Affects Versions: 1.4
Reporter: Matthias Epheser
Assignee: Ryan McKinley
 Fix For: 1.4

 Attachments: solrjs.zip


 This patch includes a zipfile snapshot of current solrjs trunk. The folder 
 structure is applied to standard solr layout.  It can be extracted to 
 contrib/javascript.
 it includes a build.xml:
 * ant dist - creates a single js file and a jar that holds velocity 
 templates.
 * ant docs - creates js docs. test in browser: doc/index.html
 * ant example-init - (depends ant dist on solr root) copies the current 
 built of solr.war and solr-velocity.jar to example/testsolr/..
 * ant example-start - starts the testsolr server on port 8983
 * ant example-import - imports 3000 test data rows (requires a started 
 testserver)
 Point your browser to example/testClientside.html 
 ,example/testServerSide.html or test/reuters/index.html to see it working.

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

[jira] Updated: (SOLR-807) UUIDField type cannot be recognized when wt=javabin is used


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

Shalin Shekhar Mangar updated SOLR-807:
---

Attachment: SOLR-807.patch

# Added a set of FieldTypes supported by NamedListCodec (the ones that we know 
how to read).
# BinaryResponseWriter writes fieldType.toExternal if it is not a supported 
type, otherwise it writes fieldType.toObject

Note -- UUID is not a supported type so it is written as toExternal.

Need to add a test for this.

 UUIDField type cannot be recognized when wt=javabin is used
 ---

 Key: SOLR-807
 URL: https://issues.apache.org/jira/browse/SOLR-807
 Project: Solr
  Issue Type: Bug
  Components: clients - java, search
Affects Versions: 1.3
Reporter: Koji Sekiguchi
Priority: Trivial
 Fix For: 1.3.1

 Attachments: SOLR-807.patch, SOLR-807.patch, SOLR-807.patch


 I'm using UUID via Solrj in my project. When I use javabin (default), I got:
 *java.util.UUID:* 391e3214-4f8e-4abd-aa6b-4f12be79534f
 as the uuid value. But if I use xml, I got:
 391e3214-4f8e-4abd-aa6b-4f12be79534f
 I think the both of them should return same string.
 program for reproducing the problem:
 {code:java}
   public static void main(String[] args) throws Exception {
 CommonsHttpSolrServer server = new CommonsHttpSolrServer( 
 http://localhost:8983/solr; );
 SolrQuery query = new SolrQuery().setQuery( *:* );
 //server.setParser( new XMLResponseParser() );   // uncomment for wt=xml
 System.out.println( =  + 
 server.getParser().getClass().getSimpleName() +  = );
 QueryResponse rsp = server.query( query );
 SolrDocumentList docs = rsp.getResults();
 for( SolrDocument doc : docs ){
   Object id = doc.getFieldValue( id );
   System.out.println( type =  + id.getClass().getName() + , id =  + 
 id );
   Object timestamp = doc.getFieldValue( timestamp );
   System.out.println( type =  + timestamp.getClass().getName() + , 
 timestamp =  + timestamp );
 }
   }
 {code}
 result for wt=javabin
 {code:title=javabin}
 = BinaryResponseParser =
 type = java.lang.String, id = 
 java.util.UUID:391e3214-4f8e-4abd-aa6b-4f12be79534f
 type = java.util.Date, timestamp = Wed Oct 15 00:20:50 JST 2008
 {code}
 result for wt=xml
 {code:title=xml}
 = XMLResponseParser =
 type = java.lang.String, id = 391e3214-4f8e-4abd-aa6b-4f12be79534f
 type = java.util.Date, timestamp = Wed Oct 15 00:20:50 JST 2008
 {code}

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

[jira] Assigned: (SOLR-807) UUIDField type cannot be recognized when wt=javabin is used


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

Shalin Shekhar Mangar reassigned SOLR-807:
--

Assignee: Shalin Shekhar Mangar

 UUIDField type cannot be recognized when wt=javabin is used
 ---

 Key: SOLR-807
 URL: https://issues.apache.org/jira/browse/SOLR-807
 Project: Solr
  Issue Type: Bug
  Components: clients - java, search
Affects Versions: 1.3
Reporter: Koji Sekiguchi
Assignee: Shalin Shekhar Mangar
Priority: Trivial
 Fix For: 1.3.1

 Attachments: SOLR-807.patch, SOLR-807.patch, SOLR-807.patch


 I'm using UUID via Solrj in my project. When I use javabin (default), I got:
 *java.util.UUID:* 391e3214-4f8e-4abd-aa6b-4f12be79534f
 as the uuid value. But if I use xml, I got:
 391e3214-4f8e-4abd-aa6b-4f12be79534f
 I think the both of them should return same string.
 program for reproducing the problem:
 {code:java}
   public static void main(String[] args) throws Exception {
 CommonsHttpSolrServer server = new CommonsHttpSolrServer( 
 http://localhost:8983/solr; );
 SolrQuery query = new SolrQuery().setQuery( *:* );
 //server.setParser( new XMLResponseParser() );   // uncomment for wt=xml
 System.out.println( =  + 
 server.getParser().getClass().getSimpleName() +  = );
 QueryResponse rsp = server.query( query );
 SolrDocumentList docs = rsp.getResults();
 for( SolrDocument doc : docs ){
   Object id = doc.getFieldValue( id );
   System.out.println( type =  + id.getClass().getName() + , id =  + 
 id );
   Object timestamp = doc.getFieldValue( timestamp );
   System.out.println( type =  + timestamp.getClass().getName() + , 
 timestamp =  + timestamp );
 }
   }
 {code}
 result for wt=javabin
 {code:title=javabin}
 = BinaryResponseParser =
 type = java.lang.String, id = 
 java.util.UUID:391e3214-4f8e-4abd-aa6b-4f12be79534f
 type = java.util.Date, timestamp = Wed Oct 15 00:20:50 JST 2008
 {code}
 result for wt=xml
 {code:title=xml}
 = XMLResponseParser =
 type = java.lang.String, id = 391e3214-4f8e-4abd-aa6b-4f12be79534f
 type = java.util.Date, timestamp = Wed Oct 15 00:20:50 JST 2008
 {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-868) Prepare solrjs trunk to be integrated into contrib

2008-11-18 Thread Erik Hatcher (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12648548#action_12648548
 ] 

Erik Hatcher commented on SOLR-868:
---

Matthias, could you detail build / demo instructions a bit more.  The 
example-start and example-import targets are commented out in what got 
committed to contrib/javascript.  Thanks!

The wiki would be a good place to lay out how to run this stuff.

 Prepare solrjs trunk to be integrated into contrib
 --

 Key: SOLR-868
 URL: https://issues.apache.org/jira/browse/SOLR-868
 Project: Solr
  Issue Type: Task
Affects Versions: 1.4
Reporter: Matthias Epheser
Assignee: Ryan McKinley
 Fix For: 1.4

 Attachments: solrjs.zip


 This patch includes a zipfile snapshot of current solrjs trunk. The folder 
 structure is applied to standard solr layout.  It can be extracted to 
 contrib/javascript.
 it includes a build.xml:
 * ant dist - creates a single js file and a jar that holds velocity 
 templates.
 * ant docs - creates js docs. test in browser: doc/index.html
 * ant example-init - (depends ant dist on solr root) copies the current 
 built of solr.war and solr-velocity.jar to example/testsolr/..
 * ant example-start - starts the testsolr server on port 8983
 * ant example-import - imports 3000 test data rows (requires a started 
 testserver)
 Point your browser to example/testClientside.html 
 ,example/testServerSide.html or test/reuters/index.html to see it working.

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

[jira] Commented: (SOLR-620) Velocity Response Writer

2008-11-18 Thread Erik Hatcher (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-620?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12648577#action_12648577
 ] 

Erik Hatcher commented on SOLR-620:
---

I have added in the json escaping/wrapping feature, renamed all parameters 
(including template overrides) to use the v. prefix.  But I did not add the 
rawResponse feature yet.  It needs more thought, and no known example is using 
it yet.  I'd prefer that SolrJ's SolrQuery and SolrResponse objects be put into 
the Velocity context - making this portable between embedded and HTTP Solr 
calls.  Using the SolrJ API will alleviate the need that rawResponse was 
filling, I believe.  

 Velocity Response Writer
 

 Key: SOLR-620
 URL: https://issues.apache.org/jira/browse/SOLR-620
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: 1.3
Reporter: Erik Hatcher
Assignee: Erik Hatcher
Priority: Minor
 Attachments: SOLR-620.patch, SOLR-620.patch, SOLR-620.patch, 
 SOLR-620.patch, SOLR-620.patch, SOLR-620.zip, SOLR-620.zip


 Add a Velocity - http://velocity.apache.org - response writer, making it 
 possible to generate a decent search UI straight from Solr itself.  Designed 
 to work standalone or in conjunction with the JSON response writer (or 
 SolrJS) for Ajaxy things.

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

[jira] Updated: (SOLR-84) Logo Contests


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

Kevin Richard updated SOLR-84:
--

Attachment: solr-logo.png

 Logo Contests
 -

 Key: SOLR-84
 URL: https://issues.apache.org/jira/browse/SOLR-84
 Project: Solr
  Issue Type: Improvement
Reporter: Bertrand Delacretaz
Priority: Minor
 Attachments: apache-solr-004.png, apache_solr_burning.png, 
 apache_solr_contour.png, apache_solr_sun.png, logo-grid.jpg, logo-solr-d.jpg, 
 logo-solr-e.jpg, logo-solr-source-files-take2.zip, logo_remake.jpg, 
 logo_remake.svg, solr-84-source-files.zip, solr-f.jpg, solr-greyscale.png, 
 solr-logo-20061214.jpg, solr-logo-20061218.JPG, solr-logo-20070124.JPG, 
 solr-logo.jpg, solr-logo.png, solr-nick.gif, solr.jpg, solr.png, solr.s1.jpg, 
 solr.s2.jpg, solr.s3.jpg, solr.svg, solr_attempt.jpg, solr_attempt2.jpg, 
 sslogo-solr-70s.png, sslogo-solr-classic.png, sslogo-solr-dance.png, 
 sslogo-solr-fiesta.png, sslogo-solr-finder2.0.png


 This issue was original a scratch pad for various ideas for new Logos.  It is 
 now being used as a repository for submissions for the Solr Logo Contest...
http://wiki.apache.org/solr/LogoContest
 Note that many of the images currently attached are not eligible for the 
 contest since they do not meet the official guidelines for new Apache project 
 logos (in particular that the full project name Apache Solr must be 
 included in the Logo).  Only eligible attachments will be included in the 
 official voting.

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

[jira] Updated: (SOLR-84) Logo Contests


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

Kevin Richard updated SOLR-84:
--

Attachment: (was: solr-logo.png)

 Logo Contests
 -

 Key: SOLR-84
 URL: https://issues.apache.org/jira/browse/SOLR-84
 Project: Solr
  Issue Type: Improvement
Reporter: Bertrand Delacretaz
Priority: Minor
 Attachments: apache-solr-004.png, apache_solr_burning.png, 
 apache_solr_contour.png, apache_solr_sun.png, logo-grid.jpg, logo-solr-d.jpg, 
 logo-solr-e.jpg, logo-solr-source-files-take2.zip, logo_remake.jpg, 
 logo_remake.svg, solr-84-source-files.zip, solr-f.jpg, solr-greyscale.png, 
 solr-logo-20061214.jpg, solr-logo-20061218.JPG, solr-logo-20070124.JPG, 
 solr-logo.jpg, solr-logo.png, solr-nick.gif, solr.jpg, solr.png, solr.s1.jpg, 
 solr.s2.jpg, solr.s3.jpg, solr.svg, solr_attempt.jpg, solr_attempt2.jpg, 
 sslogo-solr-70s.png, sslogo-solr-classic.png, sslogo-solr-dance.png, 
 sslogo-solr-fiesta.png, sslogo-solr-finder2.0.png


 This issue was original a scratch pad for various ideas for new Logos.  It is 
 now being used as a repository for submissions for the Solr Logo Contest...
http://wiki.apache.org/solr/LogoContest
 Note that many of the images currently attached are not eligible for the 
 contest since they do not meet the official guidelines for new Apache project 
 logos (in particular that the full project name Apache Solr must be 
 included in the Logo).  Only eligible attachments will be included in the 
 official voting.

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

[jira] Updated: (SOLR-84) Logo Contests


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

Kevin Richard updated SOLR-84:
--

Attachment: solr-logo.png

 Logo Contests
 -

 Key: SOLR-84
 URL: https://issues.apache.org/jira/browse/SOLR-84
 Project: Solr
  Issue Type: Improvement
Reporter: Bertrand Delacretaz
Priority: Minor
 Attachments: apache-solr-004.png, apache_solr_burning.png, 
 apache_solr_contour.png, apache_solr_sun.png, logo-grid.jpg, logo-solr-d.jpg, 
 logo-solr-e.jpg, logo-solr-source-files-take2.zip, logo_remake.jpg, 
 logo_remake.svg, solr-84-source-files.zip, solr-f.jpg, solr-greyscale.png, 
 solr-logo-20061214.jpg, solr-logo-20061218.JPG, solr-logo-20070124.JPG, 
 solr-logo.jpg, solr-logo.png, solr-nick.gif, solr.jpg, solr.png, solr.s1.jpg, 
 solr.s2.jpg, solr.s3.jpg, solr.svg, solr_attempt.jpg, solr_attempt2.jpg, 
 sslogo-solr-70s.png, sslogo-solr-classic.png, sslogo-solr-dance.png, 
 sslogo-solr-fiesta.png, sslogo-solr-finder2.0.png


 This issue was original a scratch pad for various ideas for new Logos.  It is 
 now being used as a repository for submissions for the Solr Logo Contest...
http://wiki.apache.org/solr/LogoContest
 Note that many of the images currently attached are not eligible for the 
 contest since they do not meet the official guidelines for new Apache project 
 logos (in particular that the full project name Apache Solr must be 
 included in the Logo).  Only eligible attachments will be included in the 
 official voting.

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

[jira] Updated: (SOLR-84) Logo Contests


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

Kevin Richard updated SOLR-84:
--

Attachment: (was: solr-logo.png)

 Logo Contests
 -

 Key: SOLR-84
 URL: https://issues.apache.org/jira/browse/SOLR-84
 Project: Solr
  Issue Type: Improvement
Reporter: Bertrand Delacretaz
Priority: Minor
 Attachments: apache-solr-004.png, apache_solr_burning.png, 
 apache_solr_contour.png, apache_solr_sun.png, logo-grid.jpg, logo-solr-d.jpg, 
 logo-solr-e.jpg, logo-solr-source-files-take2.zip, logo_remake.jpg, 
 logo_remake.svg, solr-84-source-files.zip, solr-f.jpg, solr-greyscale.png, 
 solr-logo-20061214.jpg, solr-logo-20061218.JPG, solr-logo-20070124.JPG, 
 solr-logo.jpg, solr-logo.png, solr-nick.gif, solr.jpg, solr.png, solr.s1.jpg, 
 solr.s2.jpg, solr.s3.jpg, solr.svg, solr_attempt.jpg, solr_attempt2.jpg, 
 sslogo-solr-70s.png, sslogo-solr-classic.png, sslogo-solr-dance.png, 
 sslogo-solr-fiesta.png, sslogo-solr-finder2.0.png


 This issue was original a scratch pad for various ideas for new Logos.  It is 
 now being used as a repository for submissions for the Solr Logo Contest...
http://wiki.apache.org/solr/LogoContest
 Note that many of the images currently attached are not eligible for the 
 contest since they do not meet the official guidelines for new Apache project 
 logos (in particular that the full project name Apache Solr must be 
 included in the Logo).  Only eligible attachments will be included in the 
 official voting.

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

[jira] Updated: (SOLR-84) Logo Contests


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

Mark Miller updated SOLR-84:


Attachment: solrlogo.jpg

 Logo Contests
 -

 Key: SOLR-84
 URL: https://issues.apache.org/jira/browse/SOLR-84
 Project: Solr
  Issue Type: Improvement
Reporter: Bertrand Delacretaz
Priority: Minor
 Attachments: apache-solr-004.png, apache_solr_burning.png, 
 apache_solr_contour.png, apache_solr_sun.png, logo-grid.jpg, logo-solr-d.jpg, 
 logo-solr-e.jpg, logo-solr-source-files-take2.zip, logo_remake.jpg, 
 logo_remake.svg, solr-84-source-files.zip, solr-f.jpg, solr-greyscale.png, 
 solr-logo-20061214.jpg, solr-logo-20061218.JPG, solr-logo-20070124.JPG, 
 solr-logo.jpg, solr-logo.png, solr-nick.gif, solr.jpg, solr.png, solr.s1.jpg, 
 solr.s2.jpg, solr.s3.jpg, solr.svg, solr_attempt.jpg, solr_attempt2.jpg, 
 solrlogo.jpg, sslogo-solr-70s.png, sslogo-solr-classic.png, 
 sslogo-solr-dance.png, sslogo-solr-fiesta.png, sslogo-solr-finder2.0.png


 This issue was original a scratch pad for various ideas for new Logos.  It is 
 now being used as a repository for submissions for the Solr Logo Contest...
http://wiki.apache.org/solr/LogoContest
 Note that many of the images currently attached are not eligible for the 
 contest since they do not meet the official guidelines for new Apache project 
 logos (in particular that the full project name Apache Solr must be 
 included in the Logo).  Only eligible attachments will be included in the 
 official voting.

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

[jira] Commented: (SOLR-84) Logo Contests

[
https://issues.apache.org/jira/browse/SOLR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12648601#action_12648601
]

Mark Miller commented on SOLR-84:
-

Whats up with this vector rule? Only vector logos? Weak.

Logo Contests
-

Key: SOLR-84
URL: https://issues.apache.org/jira/browse/SOLR-84
Project: Solr
Issue Type: Improvement
Reporter: Bertrand Delacretaz
Priority: Minor
Attachments: apache-solr-004.png, apache_solr_burning.png,
apache_solr_contour.png, apache_solr_sun.png, logo-grid.jpg, logo-solr-d.jpg,
logo-solr-e.jpg, logo-solr-source-files-take2.zip, logo_remake.jpg,
logo_remake.svg, solr-84-source-files.zip, solr-f.jpg, solr-greyscale.png,
solr-logo-20061214.jpg, solr-logo-20061218.JPG, solr-logo-20070124.JPG,
solr-logo.jpg, solr-logo.png, solr-nick.gif, solr.jpg, solr.png, solr.s1.jpg,
solr.s2.jpg, solr.s3.jpg, solr.svg, solr_attempt.jpg, solr_attempt2.jpg,
solrlogo.jpg, sslogo-solr-70s.png, sslogo-solr-classic.png,
sslogo-solr-dance.png, sslogo-solr-fiesta.png, sslogo-solr-finder2.0.png

This issue was original a scratch pad for various ideas for new Logos. It is
now being used as a repository for submissions for the Solr Logo Contest...
http://wiki.apache.org/solr/LogoContest
Note that many of the images currently attached are not eligible for the
contest since they do not meet the official guidelines for new Apache project
logos (in particular that the full project name Apache Solr must be
included in the Logo). Only eligible attachments will be included in the
official voting.

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

[jira] Assigned: (SOLR-853) Make DIH API friendly


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

Shalin Shekhar Mangar reassigned SOLR-853:
--

Assignee: Shalin Shekhar Mangar

 Make DIH API friendly
 -

 Key: SOLR-853
 URL: https://issues.apache.org/jira/browse/SOLR-853
 Project: Solr
  Issue Type: Improvement
  Components: contrib - DataImportHandler
Reporter: Noble Paul
Assignee: Shalin Shekhar Mangar
 Attachments: SOLR-853.patch


 DIH currently can only be run inside Solr. But the core of DIH is quite 
 independent of Solr. There are only a few points where it requires Solr core 
 classes.They can be isolated out and we have an API in hand. If we limit the 
 dependency down to common util then DIH can be used by 
  * Lucene users directly
  * Run DIH remotely with SolrJ
  * By any other tools using Lucene as their underlying  datastore

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

JdbcDataSource synchronization

2008-11-18 Thread Mark Miller

JdbcDataSource looks like it has a little funkiness going on. Why is 
there a synchronize block there? Can multiple threads call getConnection 
concurrently? If they can, this is not thread safe anyway. If they 
can't, why is factory.call (or is it the close?) being protected with a 
sync?


private Connection getConnection() throws Exception {
   long currTime = System.currentTimeMillis();
   if (currTime - connLastUsed  CONN_TIME_OUT) {
 synchronized (this) {
   Connection tmpConn = factory.call();
   close();
   connLastUsed = System.currentTimeMillis();
   return conn = tmpConn;
 }

   } else {
 connLastUsed = currTime;
 return conn;
   }
 }

[jira] Created: (SOLR-869) public ListString getLines(String resource, Charset charset) should close its reader

public ListString getLines(String resource, Charset charset) should close its 
reader
--

 Key: SOLR-869
 URL: https://issues.apache.org/jira/browse/SOLR-869
 Project: Solr
  Issue Type: Bug
Affects Versions: 1.3
Reporter: Mark Miller
Priority: Trivial
 Fix For: 1.4


public ListString getLines(String resource, Charset charset) should close its 
reader, preferably in a finally block.

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

[jira] Updated: (SOLR-870) FastInputStream makes 3 DataInputStream/DataOutputStreams that it does not close

2008-11-18 Thread Noble Paul നോബിള്‍ नोब्ळ्


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

Mark Miller updated SOLR-870:
-

Priority: Trivial  (was: Major)

 FastInputStream makes 3 DataInputStream/DataOutputStreams that it does not 
 close
 

 Key: SOLR-870
 URL: https://issues.apache.org/jira/browse/SOLR-870
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Priority: Trivial

 FastInputStream makes 3 DataInputStream/DataOutputStreams that it does not 
 close. Possible file descriptor leaks.

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

Re: JdbcDataSource synchronization

one JdbcDataSource has only one connection the connection object/the
connLastUsed etc needs to be protected.



On Tue, Nov 18, 2008 at 9:24 PM, Mark Miller [EMAIL PROTECTED] wrote:
 JdbcDataSource looks like it has a little funkiness going on. Why is there a
 synchronize block there? Can multiple threads call getConnection
 concurrently? If they can, this is not thread safe anyway. If they can't,
 why is factory.call (or is it the close?) being protected with a sync?

 private Connection getConnection() throws Exception {
   long currTime = System.currentTimeMillis();
   if (currTime - connLastUsed  CONN_TIME_OUT) {
 synchronized (this) {
   Connection tmpConn = factory.call();
   close();
   connLastUsed = System.currentTimeMillis();
   return conn = tmpConn;
 }

   } else {
 connLastUsed = currTime;
 return conn;
   }
  }




-- 
--Noble Paul

Re: JdbcDataSource synchronization

2008-11-18 Thread Mark Miller

But if your going to sync a variable, you can't read/write it outside of 
proper synchronization. Maybe I am just not following the code...


Noble Paul ??? ?? wrote:

one JdbcDataSource has only one connection the connection object/the
connLastUsed etc needs to be protected.



On Tue, Nov 18, 2008 at 9:24 PM, Mark Miller [EMAIL PROTECTED] wrote:
  

JdbcDataSource looks like it has a little funkiness going on. Why is there a
synchronize block there? Can multiple threads call getConnection
concurrently? If they can, this is not thread safe anyway. If they can't,
why is factory.call (or is it the close?) being protected with a sync?

private Connection getConnection() throws Exception {
  long currTime = System.currentTimeMillis();
  if (currTime - connLastUsed  CONN_TIME_OUT) {
synchronized (this) {
  Connection tmpConn = factory.call();
  close();
  connLastUsed = System.currentTimeMillis();
  return conn = tmpConn;
}

  } else {
connLastUsed = currTime;
return conn;
  }
 }

Re: JdbcDataSource synchronization

2008-11-18 Thread Noble Paul നോബിള്‍ नोब्ळ्

it is not . conn is protected throughout

On Tue, Nov 18, 2008 at 9:48 PM, Mark Miller [EMAIL PROTECTED] wrote:
 But if your going to sync a variable, you can't read/write it outside of
 proper synchronization. Maybe I am just not following the code...

 Noble Paul ??? ?? wrote:

 one JdbcDataSource has only one connection the connection object/the
 connLastUsed etc needs to be protected.



 On Tue, Nov 18, 2008 at 9:24 PM, Mark Miller [EMAIL PROTECTED]
 wrote:


 JdbcDataSource looks like it has a little funkiness going on. Why is
 there a
 synchronize block there? Can multiple threads call getConnection
 concurrently? If they can, this is not thread safe anyway. If they can't,
 why is factory.call (or is it the close?) being protected with a sync?

 private Connection getConnection() throws Exception {
  long currTime = System.currentTimeMillis();
  if (currTime - connLastUsed  CONN_TIME_OUT) {
synchronized (this) {
  Connection tmpConn = factory.call();
  close();
  connLastUsed = System.currentTimeMillis();
  return conn = tmpConn;
}

  } else {
connLastUsed = currTime;
return conn;
  }
  }











-- 
--Noble Paul

[jira] Created: (SOLR-870) FastInputStream makes 3 DataInputStream/DataOutputStreams that it does not close

FastInputStream makes 3 DataInputStream/DataOutputStreams that it does not close


 Key: SOLR-870
 URL: https://issues.apache.org/jira/browse/SOLR-870
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller


FastInputStream makes 3 DataInputStream/DataOutputStreams that it does not 
close. Possible file descriptor leaks.

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

Re: JdbcDataSource synchronization

2008-11-18 Thread Mark Miller


Okay. Lets agree to disagree on the connection protection.

How about conLastUsed? If multiple threads can enter that method (the 
only reason you would need synchronization) then all of the threads will 
access the same instance field 'conLastUsed' outside of synchronization, 
possibly as both writes and reads. You can't share memory like that - 
its unsafe.


Noble Paul നോബിള്‍ नोब्ळ् wrote:

it is not . conn is protected throughout

On Tue, Nov 18, 2008 at 9:48 PM, Mark Miller [EMAIL PROTECTED] wrote:
  

But if your going to sync a variable, you can't read/write it outside of
proper synchronization. Maybe I am just not following the code...

Noble Paul ??? ?? wrote:


one JdbcDataSource has only one connection the connection object/the
connLastUsed etc needs to be protected.



On Tue, Nov 18, 2008 at 9:24 PM, Mark Miller [EMAIL PROTECTED]
wrote:

  

JdbcDataSource looks like it has a little funkiness going on. Why is
there a
synchronize block there? Can multiple threads call getConnection
concurrently? If they can, this is not thread safe anyway. If they can't,
why is factory.call (or is it the close?) being protected with a sync?

private Connection getConnection() throws Exception {
 long currTime = System.currentTimeMillis();
 if (currTime - connLastUsed  CONN_TIME_OUT) {
   synchronized (this) {
 Connection tmpConn = factory.call();
 close();
 connLastUsed = System.currentTimeMillis();
 return conn = tmpConn;
   }

 } else {
   connLastUsed = currTime;
   return conn;
 }
 }

[jira] Created: (SOLR-871) remove dependency on stax-utils.jar

2008-11-18 Thread Ryan McKinley (JIRA)

remove dependency on stax-utils.jar 


 Key: SOLR-871
 URL: https://issues.apache.org/jira/browse/SOLR-871
 Project: Solr
  Issue Type: Improvement
Reporter: Ryan McKinley
 Fix For: 1.4


Currently we we use a custom library to make a XMLInputFactory -- we can use 
the standard one.
{code}
-inputFactory = BaseXMLInputFactory.newInstance();
+inputFactory = XMLInputFactory.newInstance();
{code}

This will remove a dependency on stax-util.jar and let people running java6 
package solr without any stax libraries.

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

[jira] Commented: (SOLR-84) Logo Contests

2008-11-18 Thread Doug Cutting (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12648645#action_12648645
 ] 

Doug Cutting commented on SOLR-84:
--

 I'm liking 
 https://issues.apache.org/jira/secure/attachment/12393951/sslogo-solr-classic.png

Me too.



 Logo Contests
 -

 Key: SOLR-84
 URL: https://issues.apache.org/jira/browse/SOLR-84
 Project: Solr
  Issue Type: Improvement
Reporter: Bertrand Delacretaz
Priority: Minor
 Attachments: apache-solr-004.png, apache_solr_burning.png, 
 apache_solr_contour.png, apache_solr_sun.png, logo-grid.jpg, logo-solr-d.jpg, 
 logo-solr-e.jpg, logo-solr-source-files-take2.zip, logo_remake.jpg, 
 logo_remake.svg, solr-84-source-files.zip, solr-f.jpg, solr-greyscale.png, 
 solr-logo-20061214.jpg, solr-logo-20061218.JPG, solr-logo-20070124.JPG, 
 solr-logo.jpg, solr-logo.png, solr-nick.gif, solr.jpg, solr.png, solr.s1.jpg, 
 solr.s2.jpg, solr.s3.jpg, solr.svg, solr_attempt.jpg, solr_attempt2.jpg, 
 solrlogo.jpg, sslogo-solr-70s.png, sslogo-solr-classic.png, 
 sslogo-solr-dance.png, sslogo-solr-fiesta.png, sslogo-solr-finder2.0.png


 This issue was original a scratch pad for various ideas for new Logos.  It is 
 now being used as a repository for submissions for the Solr Logo Contest...
http://wiki.apache.org/solr/LogoContest
 Note that many of the images currently attached are not eligible for the 
 contest since they do not meet the official guidelines for new Apache project 
 logos (in particular that the full project name Apache Solr must be 
 included in the Logo).  Only eligible attachments will be included in the 
 official voting.

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

Re: JdbcDataSource synchronization

2008-11-18 Thread Yonik Seeley

I took a very quick peek... looks like Mark is right, there are some
non-thread-safe practices going on there with both conn and
connLastUsed.  Prob also want another check inside the sync block so
multiple threads don't pile up at that sync block and all open a new
connection in turn (or just put the check inside the sync block).

Is a finalizer really needed?  If so, hopefully the connection is
resistant to close() being called on it more than once?

-Yonik


On Tue, Nov 18, 2008 at 11:27 AM, Noble Paul നോബിള്‍ नोब्ळ्
[EMAIL PROTECTED] wrote:
 it is not . conn is protected throughout

 On Tue, Nov 18, 2008 at 9:48 PM, Mark Miller [EMAIL PROTECTED] wrote:
 But if your going to sync a variable, you can't read/write it outside of
 proper synchronization. Maybe I am just not following the code...

 Noble Paul ??? ?? wrote:

 one JdbcDataSource has only one connection the connection object/the
 connLastUsed etc needs to be protected.



 On Tue, Nov 18, 2008 at 9:24 PM, Mark Miller [EMAIL PROTECTED]
 wrote:


 JdbcDataSource looks like it has a little funkiness going on. Why is
 there a
 synchronize block there? Can multiple threads call getConnection
 concurrently? If they can, this is not thread safe anyway. If they can't,
 why is factory.call (or is it the close?) being protected with a sync?

 private Connection getConnection() throws Exception {
  long currTime = System.currentTimeMillis();
  if (currTime - connLastUsed  CONN_TIME_OUT) {
synchronized (this) {
  Connection tmpConn = factory.call();
  close();
  connLastUsed = System.currentTimeMillis();
  return conn = tmpConn;
}

  } else {
connLastUsed = currTime;
return conn;
  }
  }











 --
 --Noble Paul

Re: JdbcDataSource synchronization

2008-11-18 Thread Shalin Shekhar Mangar

Hmm, the import operation in DIH is single threaded. Each entity has a
separate instance of DataSource for itself. I think that we may not need the
synchronization at all.

On Tue, Nov 18, 2008 at 10:22 PM, Yonik Seeley [EMAIL PROTECTED] wrote:

 I took a very quick peek... looks like Mark is right, there are some
 non-thread-safe practices going on there with both conn and
 connLastUsed.  Prob also want another check inside the sync block so
 multiple threads don't pile up at that sync block and all open a new
 connection in turn (or just put the check inside the sync block).

 Is a finalizer really needed?  If so, hopefully the connection is
 resistant to close() being called on it more than once?

 -Yonik


 On Tue, Nov 18, 2008 at 11:27 AM, Noble Paul നോബിള്‍ नोब्ळ्
 [EMAIL PROTECTED] wrote:
  it is not . conn is protected throughout
 
  On Tue, Nov 18, 2008 at 9:48 PM, Mark Miller [EMAIL PROTECTED]
 wrote:
  But if your going to sync a variable, you can't read/write it outside of
  proper synchronization. Maybe I am just not following the code...
 
  Noble Paul ??? ?? wrote:
 
  one JdbcDataSource has only one connection the connection object/the
  connLastUsed etc needs to be protected.
 
 
 
  On Tue, Nov 18, 2008 at 9:24 PM, Mark Miller [EMAIL PROTECTED]
  wrote:
 
 
  JdbcDataSource looks like it has a little funkiness going on. Why is
  there a
  synchronize block there? Can multiple threads call getConnection
  concurrently? If they can, this is not thread safe anyway. If they
 can't,
  why is factory.call (or is it the close?) being protected with a sync?
 
  private Connection getConnection() throws Exception {
   long currTime = System.currentTimeMillis();
   if (currTime - connLastUsed  CONN_TIME_OUT) {
 synchronized (this) {
   Connection tmpConn = factory.call();
   close();
   connLastUsed = System.currentTimeMillis();
   return conn = tmpConn;
 }
 
   } else {
 connLastUsed = currTime;
 return conn;
   }
   }
 
 
 
 
 
 
 
 
 
 
 
  --
  --Noble Paul
 




-- 
Regards,
Shalin Shekhar Mangar.

[jira] Commented: (SOLR-84) Logo Contests

2008-11-18 Thread Hoss Man (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12648650#action_12648650
]

Hoss Man commented on SOLR-84:
--

bq. Whats up with this vector rule? Only vector logos? Weak.

The PRC requires that there be a scalable vector format for official logos so
the can be reproduced at any size.

for the contest we're not requiring that people submit a vector version, but
if your entry is selected to be the new Solr Log you must provide the
scalable vector, print quality version of the logo prior to the selecting
being official.

Logo Contests
-

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

[jira] Commented: (SOLR-812) JDBC optimizations: setReadOnly, setMaxRows

2008-11-18 Thread Glen Newton (JIRA)

[
https://issues.apache.org/jira/browse/SOLR-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12648673#action_12648673
]

Glen Newton commented on SOLR-812:
--

You might also think about setting
setTransactionIsolation(Connection.TRANSACTION_READ_UNCOMMITTED)
(see:
http://media.datadirect.com/download/docs/ddxquery/allddxq/reference/wwhelp/wwhimpl/common/html/wwhelp.htm?context=Referencefile=grammarwrite7.html)

Only DB2 appears to support TRANSACTION_NONE

While from the previous comment JdbcDataSource it appears not to exclusively be
a source, you should still consider also setting:
setHoldability(ResultSet.CLOSE_CURSORS_AT_COMMIT)

It may reduce the driver resource usage.

Certainly exposing these and the above in JdbcDataSource via properties would
be more flexible to users. But sensible defaults should be set for read-only.

JDBC optimizations: setReadOnly, setMaxRows
---

Key: SOLR-812
URL: https://issues.apache.org/jira/browse/SOLR-812
Project: Solr
Issue Type: Improvement
Components: contrib - DataImportHandler
Affects Versions: 1.3
Reporter: David Smiley

I'm looking at the DataImport code as of Solr v1.3 and using it with Postgres
and very large data sets and there some improvement suggestions I have.
1. call setReadOnly(true) on the connection. DIH doesn't change the data so
this is obvious.
2. call setAutoCommit(false) on the connection. (this is needed by Postgres
to ensure that the fetchSize hint actually works)
3. call setMaxRows(X) on the statement which is to be used when the
dataimport.jsp debugger is only grabbing X rows. fetchSize is just a hint
and alone it isn't sufficient.

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

[jira] Commented: (SOLR-812) JDBC optimizations: setReadOnly, setMaxRows

2008-11-18 Thread Glen Newton (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12648685#action_12648685
 ] 

Glen Newton commented on SOLR-812:
--

This is a related issue, but since I just got involved with Solr yesterday and 
got a jira account today, I am reluctant to make a career-limiting error!  :-)

If it is indeed valid, perhaps someone else can make it a full-fledged separate 
issue!  

Perusing: JdbcDataSource  @version $Id: JdbcDataSource.java 696539 2008-09-18 
02:16:26Z ryan
Issue: MySQL fetchSize driver bug

Both my experience and according to:  
http://benjchristensen.wordpress.com/2008/05/27/mysql-jdbc-memory-usage-on-large-resultset/

MySQL does not handle properly any fetchSize  Integer.MIN_VALUE, and the 
entire ResultSet is transfered and loaded into memory, which for large 
ResultSets can result in an out of memory.

In JdbcDataSource.java:
 175:  stmt.setFetchSize(batchSize);

where 
 57:  private int batchSize = FETCH_SIZE;

and 
 326:private static final int FETCH_SIZE = 500;

Is is, this code will invoke this bug for MySQL for large ResultSets. 
Even for smaller ResultSets that do not cause an out of memory error, having 
all the ResultSet in memory will unnecessarily use up memory.

The work around for this MySQL issue is:
  stmt.setFetchSize(Integer.MIN_VALUE);

From the blog entry, see also:
* http://javaquirks.blogspot.com/2007/12/mysql-streaming-result-set.html
* 
http://dev.mysql.com/doc/refman/5.0/en/connector-j-reference-implementation-notes.html



 JDBC optimizations: setReadOnly, setMaxRows
 ---

 Key: SOLR-812
 URL: https://issues.apache.org/jira/browse/SOLR-812
 Project: Solr
  Issue Type: Improvement
  Components: contrib - DataImportHandler
Affects Versions: 1.3
Reporter: David Smiley

 I'm looking at the DataImport code as of Solr v1.3 and using it with Postgres 
 and very large data sets and there some improvement suggestions I have.
 1. call setReadOnly(true) on the connection.  DIH doesn't change the data so 
 this is obvious.
 2. call setAutoCommit(false) on the connection.   (this is needed by Postgres 
 to ensure that the fetchSize hint actually works)
 3. call setMaxRows(X) on the statement which is to be used when the 
 dataimport.jsp debugger is only grabbing X rows.  fetchSize is just a hint 
 and alone it isn't sufficient.

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

[jira] Commented: (SOLR-812) JDBC optimizations: setReadOnly, setMaxRows


[ 
https://issues.apache.org/jira/browse/SOLR-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12648724#action_12648724
 ] 

Shalin Shekhar Mangar commented on SOLR-812:


Thanks for going through this Glen. This bug and a workaround is documented in 
the FAQ page.

http://wiki.apache.org/solr/DataImportHandlerFaq

 JDBC optimizations: setReadOnly, setMaxRows
 ---

 Key: SOLR-812
 URL: https://issues.apache.org/jira/browse/SOLR-812
 Project: Solr
  Issue Type: Improvement
  Components: contrib - DataImportHandler
Affects Versions: 1.3
Reporter: David Smiley

 I'm looking at the DataImport code as of Solr v1.3 and using it with Postgres 
 and very large data sets and there some improvement suggestions I have.
 1. call setReadOnly(true) on the connection.  DIH doesn't change the data so 
 this is obvious.
 2. call setAutoCommit(false) on the connection.   (this is needed by Postgres 
 to ensure that the fetchSize hint actually works)
 3. call setMaxRows(X) on the statement which is to be used when the 
 dataimport.jsp debugger is only grabbing X rows.  fetchSize is just a hint 
 and alone it isn't sufficient.

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

Re: Deadlock with DirectUpdateHandler2

2008-11-18 Thread Mike Klaas



On 18-Nov-08, at 8:54 AM, Mark Miller wrote:


Mark Miller wrote:

Toby Cole wrote:
Has anyone else experienced a deadlock when the  
DirectUpdateHandler2 does an autocommit?
I'm using a recent snapshot from hudson (apache- 
solr-2008-11-12_08-06-21), and quite often when I'm loading data  
the server (tomcat 6) gets stuck at line 469 of  
DirectUpdateHandler2:


 // Check if there is a commit already scheduled for longer  
then this time

 if( pending != null 
 pending.getDelay(TimeUnit.MILLISECONDS) = commitMaxTime )

Anyone got any enlightening tips?



There is some inconsistent synchronization I think. Especially  
involving pending. Yuck g
I would say there are problems with pending, autoCommitCount, and  
lastAddedTime. That alone could probably cause a deadlock (who  
knows), but it also seems somewhat possible that there is an issue  
with the heavy intermingling of locks (there a bunch of locks to be  
had in that class). I havn't looked for evidence of that though -  
prob makes sense to fix those 3 guys and see if you get reports from  
there.



autoCommitCount is written in a CommitTracker.synchronized block  
only.  It is read to print stats in an unsynchronized fashion, which  
perhaps could be fixed, though I can't see how it could cause a problem


lastAddedTime is only written in a call path within a  
DirectUpdateHandler2.synchronized block.  It is only read in a  
CommitTracker.synchronized block.  It could read the wrong value, but  
I also don't see this causing a problem (a commit might fail to be  
scheduled).  This could probably also be improved, but doesn't seem  
important.


pending seems to be the issue.  As long as commit are only triggered  
by autocommit, there is no issue as manipulation of pending is always  
performed inside CommitTracker.synchronized.  But didCommit()/ 
didRollback() could be called via manual commit, and pending is  
directly manipulated during DUH2.close().  I'm having trouble coming  
up with a plausible deadlock scenario, but this needs to be fixed.  It  
isn't as easy as synchronizing didCommit/didRollback, though--this  
would introduce definite deadlock scenarios.


Mark, is there any chance you could post the thread dump for the  
deadlocked process?  Do you issue manual commits during insertion?


-Mike

[jira] Updated: (SOLR-84) Logo Contests

2008-11-18 Thread Noble Paul നോബിള്‍ नोब्ळ्


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

Mark Miller updated SOLR-84:


Attachment: solrlogo2.jpg

 Logo Contests
 -

 Key: SOLR-84
 URL: https://issues.apache.org/jira/browse/SOLR-84
 Project: Solr
  Issue Type: Improvement
Reporter: Bertrand Delacretaz
Priority: Minor
 Attachments: apache-solr-004.png, apache_solr_burning.png, 
 apache_solr_contour.png, apache_solr_sun.png, logo-grid.jpg, logo-solr-d.jpg, 
 logo-solr-e.jpg, logo-solr-source-files-take2.zip, logo_remake.jpg, 
 logo_remake.svg, solr-84-source-files.zip, solr-f.jpg, solr-greyscale.png, 
 solr-logo-20061214.jpg, solr-logo-20061218.JPG, solr-logo-20070124.JPG, 
 solr-logo.jpg, solr-logo.png, solr-nick.gif, solr.jpg, solr.png, solr.s1.jpg, 
 solr.s2.jpg, solr.s3.jpg, solr.svg, solr_attempt.jpg, solr_attempt2.jpg, 
 solrlogo.jpg, solrlogo2.jpg, sslogo-solr-70s.png, sslogo-solr-classic.png, 
 sslogo-solr-dance.png, sslogo-solr-fiesta.png, sslogo-solr-finder2.0.png


 This issue was original a scratch pad for various ideas for new Logos.  It is 
 now being used as a repository for submissions for the Solr Logo Contest...
http://wiki.apache.org/solr/LogoContest
 Note that many of the images currently attached are not eligible for the 
 contest since they do not meet the official guidelines for new Apache project 
 logos (in particular that the full project name Apache Solr must be 
 included in the Logo).  Only eligible attachments will be included in the 
 official voting.

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

Re: JdbcDataSource synchronization

As shalin says threadsafety is not given importance because DIH is
singlethreaded. But eventually we may move there .
But we indeed tried once w/ multithreaded indexing for around 3million
records and the performance gain we observed was 10% . We realized
that it was bound by Lucene's ability to  index documents rather than
DIH's ability to produce it. So we dropped it in favor of simplicity

--Noble

On Tue, Nov 18, 2008 at 10:28 PM, Shalin Shekhar Mangar
[EMAIL PROTECTED] wrote:
 Hmm, the import operation in DIH is single threaded. Each entity has a
 separate instance of DataSource for itself. I think that we may not need the
 synchronization at all.

 On Tue, Nov 18, 2008 at 10:22 PM, Yonik Seeley [EMAIL PROTECTED] wrote:

 I took a very quick peek... looks like Mark is right, there are some
 non-thread-safe practices going on there with both conn and
 connLastUsed.  Prob also want another check inside the sync block so
 multiple threads don't pile up at that sync block and all open a new
 connection in turn (or just put the check inside the sync block).

 Is a finalizer really needed?  If so, hopefully the connection is
 resistant to close() being called on it more than once?

 -Yonik


 On Tue, Nov 18, 2008 at 11:27 AM, Noble Paul നോബിള്‍ नोब्ळ्
 [EMAIL PROTECTED] wrote:
  it is not . conn is protected throughout
 
  On Tue, Nov 18, 2008 at 9:48 PM, Mark Miller [EMAIL PROTECTED]
 wrote:
  But if your going to sync a variable, you can't read/write it outside of
  proper synchronization. Maybe I am just not following the code...
 
  Noble Paul ??? ?? wrote:
 
  one JdbcDataSource has only one connection the connection object/the
  connLastUsed etc needs to be protected.
 
 
 
  On Tue, Nov 18, 2008 at 9:24 PM, Mark Miller [EMAIL PROTECTED]
  wrote:
 
 
  JdbcDataSource looks like it has a little funkiness going on. Why is
  there a
  synchronize block there? Can multiple threads call getConnection
  concurrently? If they can, this is not thread safe anyway. If they
 can't,
  why is factory.call (or is it the close?) being protected with a sync?
 
  private Connection getConnection() throws Exception {
   long currTime = System.currentTimeMillis();
   if (currTime - connLastUsed  CONN_TIME_OUT) {
 synchronized (this) {
   Connection tmpConn = factory.call();
   close();
   connLastUsed = System.currentTimeMillis();
   return conn = tmpConn;
 }
 
   } else {
 connLastUsed = currTime;
 return conn;
   }
   }
 
 
 
 
 
 
 
 
 
 
 
  --
  --Noble Paul
 




 --
 Regards,
 Shalin Shekhar Mangar.




-- 
--Noble Paul

[jira] Updated: (SOLR-84) Logo Contests


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

Danny Marsh updated SOLR-84:


Attachment: solr-solid.png

 Logo Contests
 -

 Key: SOLR-84
 URL: https://issues.apache.org/jira/browse/SOLR-84
 Project: Solr
  Issue Type: Improvement
Reporter: Bertrand Delacretaz
Priority: Minor
 Attachments: apache-solr-004.png, apache_solr_burning.png, 
 apache_solr_contour.png, apache_solr_sun.png, logo-grid.jpg, logo-solr-d.jpg, 
 logo-solr-e.jpg, logo-solr-source-files-take2.zip, logo_remake.jpg, 
 logo_remake.svg, solr-84-source-files.zip, solr-f.jpg, solr-greyscale.png, 
 solr-logo-20061214.jpg, solr-logo-20061218.JPG, solr-logo-20070124.JPG, 
 solr-logo.jpg, solr-logo.png, solr-nick.gif, solr-solid.png, solr.jpg, 
 solr.png, solr.s1.jpg, solr.s2.jpg, solr.s3.jpg, solr.svg, solr_attempt.jpg, 
 solr_attempt2.jpg, solrlogo.jpg, solrlogo2.jpg, sslogo-solr-70s.png, 
 sslogo-solr-classic.png, sslogo-solr-dance.png, sslogo-solr-fiesta.png, 
 sslogo-solr-finder2.0.png


 This issue was original a scratch pad for various ideas for new Logos.  It is 
 now being used as a repository for submissions for the Solr Logo Contest...
http://wiki.apache.org/solr/LogoContest
 Note that many of the images currently attached are not eligible for the 
 contest since they do not meet the official guidelines for new Apache project 
 logos (in particular that the full project name Apache Solr must be 
 included in the Logo).  Only eligible attachments will be included in the 
 official voting.

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

[jira] Updated: (SOLR-84) Logo Contests


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

Danny Marsh updated SOLR-84:


Attachment: (was: solr-circle-grad.png)

 Logo Contests
 -

 Key: SOLR-84
 URL: https://issues.apache.org/jira/browse/SOLR-84
 Project: Solr
  Issue Type: Improvement
Reporter: Bertrand Delacretaz
Priority: Minor
 Attachments: apache-solr-004.png, apache_solr_burning.png, 
 apache_solr_contour.png, apache_solr_sun.png, logo-grid.jpg, logo-solr-d.jpg, 
 logo-solr-e.jpg, logo-solr-source-files-take2.zip, logo_remake.jpg, 
 logo_remake.svg, solr-84-source-files.zip, solr-f.jpg, solr-greyscale.png, 
 solr-logo-20061214.jpg, solr-logo-20061218.JPG, solr-logo-20070124.JPG, 
 solr-logo.jpg, solr-logo.png, solr-nick.gif, solr-solid.png, solr.jpg, 
 solr.png, solr.s1.jpg, solr.s2.jpg, solr.s3.jpg, solr.svg, solr_attempt.jpg, 
 solr_attempt2.jpg, solrlogo.jpg, solrlogo2.jpg, sslogo-solr-70s.png, 
 sslogo-solr-classic.png, sslogo-solr-dance.png, sslogo-solr-fiesta.png, 
 sslogo-solr-finder2.0.png


 This issue was original a scratch pad for various ideas for new Logos.  It is 
 now being used as a repository for submissions for the Solr Logo Contest...
http://wiki.apache.org/solr/LogoContest
 Note that many of the images currently attached are not eligible for the 
 contest since they do not meet the official guidelines for new Apache project 
 logos (in particular that the full project name Apache Solr must be 
 included in the Logo).  Only eligible attachments will be included in the 
 official voting.

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

[jira] Updated: (SOLR-84) Logo Contests


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

Danny Marsh updated SOLR-84:


Attachment: solr-circle-grad.png

 Logo Contests
 -

 Key: SOLR-84
 URL: https://issues.apache.org/jira/browse/SOLR-84
 Project: Solr
  Issue Type: Improvement
Reporter: Bertrand Delacretaz
Priority: Minor
 Attachments: apache-solr-004.png, apache_solr_burning.png, 
 apache_solr_contour.png, apache_solr_sun.png, logo-grid.jpg, logo-solr-d.jpg, 
 logo-solr-e.jpg, logo-solr-source-files-take2.zip, logo_remake.jpg, 
 logo_remake.svg, solr-84-source-files.zip, solr-f.jpg, solr-greyscale.png, 
 solr-logo-20061214.jpg, solr-logo-20061218.JPG, solr-logo-20070124.JPG, 
 solr-logo.jpg, solr-logo.png, solr-nick.gif, solr-solid.png, solr.jpg, 
 solr.png, solr.s1.jpg, solr.s2.jpg, solr.s3.jpg, solr.svg, solr_attempt.jpg, 
 solr_attempt2.jpg, solrlogo.jpg, solrlogo2.jpg, sslogo-solr-70s.png, 
 sslogo-solr-classic.png, sslogo-solr-dance.png, sslogo-solr-fiesta.png, 
 sslogo-solr-finder2.0.png


 This issue was original a scratch pad for various ideas for new Logos.  It is 
 now being used as a repository for submissions for the Solr Logo Contest...
http://wiki.apache.org/solr/LogoContest
 Note that many of the images currently attached are not eligible for the 
 contest since they do not meet the official guidelines for new Apache project 
 logos (in particular that the full project name Apache Solr must be 
 included in the Logo).  Only eligible attachments will be included in the 
 official voting.

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

[jira] Updated: (SOLR-84) Logo Contests


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

Danny Marsh updated SOLR-84:


Attachment: solr-circle-grad.png

 Logo Contests
 -

 Key: SOLR-84
 URL: https://issues.apache.org/jira/browse/SOLR-84
 Project: Solr
  Issue Type: Improvement
Reporter: Bertrand Delacretaz
Priority: Minor
 Attachments: apache-solr-004.png, apache_solr_burning.png, 
 apache_solr_contour.png, apache_solr_sun.png, logo-grid.jpg, logo-solr-d.jpg, 
 logo-solr-e.jpg, logo-solr-source-files-take2.zip, logo_remake.jpg, 
 logo_remake.svg, solr-84-source-files.zip, solr-circle-grad.png, solr-f.jpg, 
 solr-greyscale.png, solr-logo-20061214.jpg, solr-logo-20061218.JPG, 
 solr-logo-20070124.JPG, solr-logo.jpg, solr-logo.png, solr-nick.gif, 
 solr-solid.png, solr.jpg, solr.png, solr.s1.jpg, solr.s2.jpg, solr.s3.jpg, 
 solr.svg, solr_attempt.jpg, solr_attempt2.jpg, solrlogo.jpg, solrlogo2.jpg, 
 sslogo-solr-70s.png, sslogo-solr-classic.png, sslogo-solr-dance.png, 
 sslogo-solr-fiesta.png, sslogo-solr-finder2.0.png


 This issue was original a scratch pad for various ideas for new Logos.  It is 
 now being used as a repository for submissions for the Solr Logo Contest...
http://wiki.apache.org/solr/LogoContest
 Note that many of the images currently attached are not eligible for the 
 contest since they do not meet the official guidelines for new Apache project 
 logos (in particular that the full project name Apache Solr must be 
 included in the Logo).  Only eligible attachments will be included in the 
 official voting.

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

[jira] Updated: (SOLR-667) Alternate LRUCache implementation


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

Noble Paul updated SOLR-667:


Attachment: SOLR-667.patch

made CacheEntry non static 

 Alternate LRUCache implementation
 -

 Key: SOLR-667
 URL: https://issues.apache.org/jira/browse/SOLR-667
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: 1.3
Reporter: Noble Paul
Assignee: Yonik Seeley
 Fix For: 1.4

 Attachments: ConcurrentLRUCache.java, ConcurrentLRUCache.java, 
 ConcurrentLRUCache.java, SOLR-667-alternate.patch, SOLR-667-alternate.patch, 
 SOLR-667-updates.patch, SOLR-667.patch, SOLR-667.patch, SOLR-667.patch, 
 SOLR-667.patch, SOLR-667.patch, SOLR-667.patch, SOLR-667.patch, 
 SOLR-667.patch, SOLR-667.patch, SOLR-667.patch, SOLR-667.patch, SOLR-667.patch


 The only available SolrCache i.e LRUCache is based on _LinkedHashMap_ which 
 has _get()_ also synchronized. This can cause severe bottlenecks for faceted 
 search. Any alternate implementation which can be faster/better must be 
 considered. 

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

[jira] Updated: (SOLR-872) better error message for missing copyField destination


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

Noble Paul updated SOLR-872:


Attachment: SOLR-872.patch

throws exception with appropriate message

 better error message for missing copyField destination 
 ---

 Key: SOLR-872
 URL: https://issues.apache.org/jira/browse/SOLR-872
 Project: Solr
  Issue Type: Improvement
  Components: search
Reporter: Noble Paul
Priority: Trivial
 Fix For: 1.4

 Attachments: SOLR-872.patch


 When the copyField destination is wrong the message is not clear as to what 
 the error is
 http://markmail.org/message/l3pxrxeneq3vjfor

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

[jira] Updated: (SOLR-872) better error message for missing copyField destination


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

Noble Paul updated SOLR-872:


Priority: Trivial  (was: Major)
 Summary: better error message for missing copyField destination   (was: 
better error message for copyField)

 better error message for missing copyField destination 
 ---

 Key: SOLR-872
 URL: https://issues.apache.org/jira/browse/SOLR-872
 Project: Solr
  Issue Type: Improvement
  Components: search
Reporter: Noble Paul
Priority: Trivial
 Fix For: 1.4

 Attachments: SOLR-872.patch


 When the copyField destination is wrong the message is not clear as to what 
 the error is
 http://markmail.org/message/l3pxrxeneq3vjfor

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

[jira] Created: (SOLR-872) better error message for copyField