[jira] Resolved: (SOLR-1479) Disable Polling only appears in replication control page when replication is going on

[Noble Paul (JIRA)]

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

Noble Paul resolved SOLR-1479.
--

Resolution: Fixed

committed r820544

> Disable Polling only appears in replication control page when replication is 
> going on
> -
>
> Key: SOLR-1479
> URL: https://issues.apache.org/jira/browse/SOLR-1479
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 1.4
> Environment: Solr nightly 9/28/09
>Reporter: Artem Russakovskii
>Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1479.patch
>
>
> Using the Java replication with polling, the /replication page on the slave 
> only seems to show the Disable Polling button when replication is going on, 
> i.e. it's downloading the files. As soon as replication finishes, the Disable 
> Polling button disappears and the only button that remains is Replicate Now.

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

[jira] Updated: (SOLR-1479) Disable Polling only appears in replication control page when replication is going on

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-1479:
-

Attachment: SOLR-1479.patch

> Disable Polling only appears in replication control page when replication is 
> going on
> -
>
> Key: SOLR-1479
> URL: https://issues.apache.org/jira/browse/SOLR-1479
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 1.4
> Environment: Solr nightly 9/28/09
>Reporter: Artem Russakovskii
>Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1479.patch
>
>
> Using the Java replication with polling, the /replication page on the slave 
> only seems to show the Disable Polling button when replication is going on, 
> i.e. it's downloading the files. As soon as replication finishes, the Disable 
> Polling button disappears and the only button that remains is Replicate Now.

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

[jira] Updated: (SOLR-1479) Disable Polling only appears in replication control page when replication is going on

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-1479:
-

Fix Version/s: 1.4

> Disable Polling only appears in replication control page when replication is 
> going on
> -
>
> Key: SOLR-1479
> URL: https://issues.apache.org/jira/browse/SOLR-1479
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 1.4
> Environment: Solr nightly 9/28/09
>Reporter: Artem Russakovskii
>Assignee: Noble Paul
> Fix For: 1.4
>
> Attachments: SOLR-1479.patch
>
>
> Using the Java replication with polling, the /replication page on the slave 
> only seems to show the Disable Polling button when replication is going on, 
> i.e. it's downloading the files. As soon as replication finishes, the Disable 
> Polling button disappears and the only button that remains is Replicate Now.

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

[jira] Assigned: (SOLR-1479) Disable Polling only appears in replication control page when replication is going on

[Noble Paul (JIRA)]

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

Noble Paul reassigned SOLR-1479:


Assignee: Noble Paul

> Disable Polling only appears in replication control page when replication is 
> going on
> -
>
> Key: SOLR-1479
> URL: https://issues.apache.org/jira/browse/SOLR-1479
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 1.4
> Environment: Solr nightly 9/28/09
>Reporter: Artem Russakovskii
>Assignee: Noble Paul
>
> Using the Java replication with polling, the /replication page on the slave 
> only seems to show the Disable Polling button when replication is going on, 
> i.e. it's downloading the files. As soon as replication finishes, the Disable 
> Polling button disappears and the only button that remains is Replicate Now.

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

[jira] Created: (SOLR-1479) Disable Polling only appears in replication control page when replication is going on

[Artem Russakovskii (JIRA)]

Disable Polling only appears in replication control page when replication is 
going on
-

 Key: SOLR-1479
 URL: https://issues.apache.org/jira/browse/SOLR-1479
 Project: Solr
  Issue Type: Bug
Affects Versions: 1.4
 Environment: Solr nightly 9/28/09
Reporter: Artem Russakovskii


Using the Java replication with polling, the /replication page on the slave 
only seems to show the Disable Polling button when replication is going on, 
i.e. it's downloading the files. As soon as replication finishes, the Disable 
Polling button disappears and the only button that remains is Replicate Now.

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

Re: unit test stability

[Yonik Seeley]

I'm still getting test failures... it seems like Jetty doesn't come up
- even after waiting 2 minutes.  Still not sure if it's a Solr or
Jetty bug.

I also saw an NPE that didn't cause a test failure - looks like a Jetty bug.

SEVERE: handle failed
java.lang.NullPointerException
at org.mortbay.io.ByteArrayBuffer.readFrom(ByteArrayBuffer.java:168)
at org.mortbay.io.bio.StreamEndPoint.fill(StreamEndPoint.java:99)
at 
org.mortbay.jetty.bio.SocketConnector$Connection.fill(SocketConnector.java:196)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:281)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:202)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
at 
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
at 
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)

-Yonik
http://www.lucidimagination.com



On Wed, Sep 30, 2009 at 9:26 AM, Yonik Seeley
 wrote:
> Getting better and better.
> I had to up the amount of time from 20 sec to 2 min to wait for jetty
> to launch - not sure if there's a bug in jetty or solr that would
> sometimes cause such a long launch time.
>
> The last failure was in TestLBHttpSolrServer (address already in use),
> and I just committed a fix.
> Remember to let Jetty pick the ports! (i.e. pass 0 as the port to jetty 
> runner)
>
> -Yonik
> http://www.lucidimagination.com
>
>
> On Tue, Sep 29, 2009 at 9:53 AM, Yonik Seeley
>  wrote:
>> OK, I think our unit tests are slowly getting in better shape.
>> They were failing at least 10% of the time, even on my fast box...
>> after the last fixups committed, I got up to 32 in a row before
>> failure.
>>
>> Going forward, it would be nice to keep on top of these a little more,
>> otherwise the tests become like the little boy who cried wolf.
>>
>> As to the failure in run#32: here it is.
>>     at
>> org.apache.solr.handler.dataimport.TestEvaluatorBag.testGetDateFormatEvaluator(TestEvaluatorBag.java:120)
>> 
>>
>> -Yonik
>> http://www.lucidimagination.com
>>
>

[jira] Commented: (SOLR-1477) Search on local cores

[Jason Rutherglen (JIRA)]

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

Jason Rutherglen commented on SOLR-1477:


Is there a lurking issue that prevents a chained distributed queries from 
working?  I setup a "proxy" core that queries local cores, which when called by 
another distributed request, fails with:

{code}
SEVERE: java.lang.NullPointerException
at 
org.apache.solr.handler.component.ShardFieldSortedHitQueue$1.compare(ShardDoc.java:210)
at 
org.apache.solr.handler.component.ShardFieldSortedHitQueue.lessThan(ShardDoc.java:134)
at org.apache.lucene.util.PriorityQueue.upHeap(PriorityQueue.java:255)
at org.apache.lucene.util.PriorityQueue.put(PriorityQueue.java:114)
at 
org.apache.lucene.util.PriorityQueue.insertWithOverflow(PriorityQueue.java:156)
at org.apache.lucene.util.PriorityQueue.insert(PriorityQueue.java:141)
at 
org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:445)
at 
org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:298)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:290)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316)
{code}

> Search on local cores
> -
>
> Key: SOLR-1477
> URL: https://issues.apache.org/jira/browse/SOLR-1477
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Jason Rutherglen
>Priority: Trivial
> Fix For: 1.5
>
> Attachments: SOLR-1477.patch, SOLR-1477.patch, SOLR-1477.patch
>
>
> Search on cores in the container, using distributed search.

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

[jira] Commented: (SOLR-1395) Integrate Katta

[Jason Venner (at ning) (JIRA)]

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

Jason Venner (at ning) commented on SOLR-1395:
--

I was unable to separate them cleanly, so no.





> Integrate Katta
> ---
>
> Key: SOLR-1395
> URL: https://issues.apache.org/jira/browse/SOLR-1395
> Project: Solr
>  Issue Type: New Feature
>Affects Versions: 1.4
>Reporter: Jason Rutherglen
>Priority: Minor
> Fix For: 1.5
>
> Attachments: hadoop-core-0.19.0.jar, katta-core-0.6-dev.jar, 
> katta.node.properties, katta.zk.properties, log4j-1.2.13.jar, 
> solr-1395-1431-3.patch, solr-1395-1431.patch, SOLR-1395.patch, 
> SOLR-1395.patch, SOLR-1395.patch, test-katta-core-0.6-dev.jar, 
> zkclient-0.1-dev.jar, zookeeper-3.2.1.jar
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> We'll integrate Katta into Solr so that:
> * Distributed search uses Hadoop RPC
> * Shard/SolrCore distribution and management
> * Zookeeper based failover
> * Indexes may be built using Hadoop

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

[jira] Commented: (SOLR-1395) Integrate Katta

[Jason Rutherglen (JIRA)]

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

Jason Rutherglen commented on SOLR-1395:


Jason, Can you upload a SOLR-1395 only patch?  That will help in seeing the 
SOLR-1395 specific changes.

I think the next step is to remove the dependency on separate property files, 
as I find these hard to manage (they are too numerous).

> Integrate Katta
> ---
>
> Key: SOLR-1395
> URL: https://issues.apache.org/jira/browse/SOLR-1395
> Project: Solr
>  Issue Type: New Feature
>Affects Versions: 1.4
>Reporter: Jason Rutherglen
>Priority: Minor
> Fix For: 1.5
>
> Attachments: hadoop-core-0.19.0.jar, katta-core-0.6-dev.jar, 
> katta.node.properties, katta.zk.properties, log4j-1.2.13.jar, 
> solr-1395-1431-3.patch, solr-1395-1431.patch, SOLR-1395.patch, 
> SOLR-1395.patch, SOLR-1395.patch, test-katta-core-0.6-dev.jar, 
> zkclient-0.1-dev.jar, zookeeper-3.2.1.jar
>
>   Original Estimate: 336h
>  Remaining Estimate: 336h
>
> We'll integrate Katta into Solr so that:
> * Distributed search uses Hadoop RPC
> * Shard/SolrCore distribution and management
> * Zookeeper based failover
> * Indexes may be built using Hadoop

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

[jira] Updated: (SOLR-1477) Search on local cores

[Jason Rutherglen (JIRA)]

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

Jason Rutherglen updated SOLR-1477:
---

Attachment: SOLR-1477.patch

Added Apache license headers

> Search on local cores
> -
>
> Key: SOLR-1477
> URL: https://issues.apache.org/jira/browse/SOLR-1477
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 1.4
>Reporter: Jason Rutherglen
>Priority: Trivial
> Fix For: 1.5
>
> Attachments: SOLR-1477.patch, SOLR-1477.patch, SOLR-1477.patch
>
>
> Search on cores in the container, using distributed search.

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

[jira] Updated: (SOLR-1478) Enable sort by docid

[Erik Hatcher (JIRA)]

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

Erik Hatcher updated SOLR-1478:
---

Attachment: SOLR-1478.patch

This patch adds a special sort field (like "score" is implemented) to enable 
sorting by docid.  

The character "#" was used simply to avoid any potential field name overlap, 
but this requires URL encoding it to %23, so maybe some other string should be 
used?  

Here's an example URL: 
http://localhost:8983/solr/select?q=*:*&sort=%23%20desc&fl=id

Seems like score and docid sorting should avoid using normal field name 
strings, so maybe _score_ and _docid_ or something.

I marked this for 1.4, because it's a trivial patch.  Discussion welcome.

> Enable sort by docid
> 
>
> Key: SOLR-1478
> URL: https://issues.apache.org/jira/browse/SOLR-1478
> Project: Solr
>  Issue Type: New Feature
>  Components: search
>Reporter: Erik Hatcher
>Priority: Minor
> Fix For: 1.4
>
> Attachments: SOLR-1478.patch
>
>
> Lucene allows sorting by docid, but Solr currently does not provide a way to 
> specify it. 

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

Re: Upgrade POI?

[Grant Ingersoll]

It's in the POM.

On Sep 30, 2009, at 9:51 AM, Mark Miller wrote:


Grant Ingersoll wrote:

I think we should stick w/ Tika releases and it's dependencies.

On Sep 30, 2009, at 3:57 AM, Shalin Shekhar Mangar wrote:


Shall we upgrade to POI 3.5 final for Solr Cell?

--
Regards,
Shalin Shekhar Mangar.




Does Tika have those? When I looked at their site I couldn't find jar
downloads or version info.

--
- Mark

http://www.lucidimagination.com

[jira] Created: (SOLR-1478) Enable sort by docid

[Erik Hatcher (JIRA)]

Enable sort by docid


 Key: SOLR-1478
 URL: https://issues.apache.org/jira/browse/SOLR-1478
 Project: Solr
  Issue Type: New Feature
  Components: search
Reporter: Erik Hatcher
Priority: Minor
 Fix For: 1.4


Lucene allows sorting by docid, but Solr currently does not provide a way to 
specify it. 

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

Re: Upgrade POI?

[Mark Miller]

Grant Ingersoll wrote:
> I think we should stick w/ Tika releases and it's dependencies.
>
> On Sep 30, 2009, at 3:57 AM, Shalin Shekhar Mangar wrote:
>
>> Shall we upgrade to POI 3.5 final for Solr Cell?
>>
>> -- 
>> Regards,
>> Shalin Shekhar Mangar.
>
>
Does Tika have those? When I looked at their site I couldn't find jar
downloads or version info.

-- 
- Mark

http://www.lucidimagination.com

Re: Upgrade POI?

[Grant Ingersoll]

I think we should stick w/ Tika releases and it's dependencies.

On Sep 30, 2009, at 3:57 AM, Shalin Shekhar Mangar wrote:


Shall we upgrade to POI 3.5 final for Solr Cell?

--
Regards,
Shalin Shekhar Mangar.

Re: unit test stability

[Yonik Seeley]

Getting better and better.
I had to up the amount of time from 20 sec to 2 min to wait for jetty
to launch - not sure if there's a bug in jetty or solr that would
sometimes cause such a long launch time.

The last failure was in TestLBHttpSolrServer (address already in use),
and I just committed a fix.
Remember to let Jetty pick the ports! (i.e. pass 0 as the port to jetty runner)

-Yonik
http://www.lucidimagination.com


On Tue, Sep 29, 2009 at 9:53 AM, Yonik Seeley
 wrote:
> OK, I think our unit tests are slowly getting in better shape.
> They were failing at least 10% of the time, even on my fast box...
> after the last fixups committed, I got up to 32 in a row before
> failure.
>
> Going forward, it would be nice to keep on top of these a little more,
> otherwise the tests become like the little boy who cried wolf.
>
> As to the failure in run#32: here it is.
>     at
> org.apache.solr.handler.dataimport.TestEvaluatorBag.testGetDateFormatEvaluator(TestEvaluatorBag.java:120)
> 
>
> -Yonik
> http://www.lucidimagination.com
>

[jira] Updated: (SOLR-1437) DIH: Enhance XPathRecordReader to deal with //tagname and other improvments.

[Fergus McMenemie (JIRA)]

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

Fergus McMenemie updated SOLR-1437:
---

Attachment: (was: SOLR-1437.patch)

> DIH: Enhance XPathRecordReader to deal with //tagname and other improvments.
> 
>
> Key: SOLR-1437
> URL: https://issues.apache.org/jira/browse/SOLR-1437
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler
>Affects Versions: 1.4
>Reporter: Fergus McMenemie
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1437.patch
>
>   Original Estimate: 672h
>  Remaining Estimate: 672h
>
> As per 
> http://www.nabble.com/Re%3A-Extract-info-from-parent-node-during-data-import-%28redirect%3A%29-td25471162.html
>  it would be nice to be able to use expressions such as //tagname when 
> parsing XML documents.

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

[jira] Updated: (SOLR-1437) DIH: Enhance XPathRecordReader to deal with //tagname and other improvments.

[Fergus McMenemie (JIRA)]

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

Fergus McMenemie updated SOLR-1437:
---

Attachment: (was: SOLR-1437.patch)

> DIH: Enhance XPathRecordReader to deal with //tagname and other improvments.
> 
>
> Key: SOLR-1437
> URL: https://issues.apache.org/jira/browse/SOLR-1437
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler
>Affects Versions: 1.4
>Reporter: Fergus McMenemie
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1437.patch, SOLR-1437.patch
>
>   Original Estimate: 672h
>  Remaining Estimate: 672h
>
> As per 
> http://www.nabble.com/Re%3A-Extract-info-from-parent-node-during-data-import-%28redirect%3A%29-td25471162.html
>  it would be nice to be able to use expressions such as //tagname when 
> parsing XML documents.

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

[jira] Updated: (SOLR-1437) DIH: Enhance XPathRecordReader to deal with //tagname and other improvments.

[Fergus McMenemie (JIRA)]

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

Fergus McMenemie updated SOLR-1437:
---

Attachment: (was: SOLR-1437.patch)

> DIH: Enhance XPathRecordReader to deal with //tagname and other improvments.
> 
>
> Key: SOLR-1437
> URL: https://issues.apache.org/jira/browse/SOLR-1437
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler
>Affects Versions: 1.4
>Reporter: Fergus McMenemie
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1437.patch, SOLR-1437.patch
>
>   Original Estimate: 672h
>  Remaining Estimate: 672h
>
> As per 
> http://www.nabble.com/Re%3A-Extract-info-from-parent-node-during-data-import-%28redirect%3A%29-td25471162.html
>  it would be nice to be able to use expressions such as //tagname when 
> parsing XML documents.

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

[jira] Updated: (SOLR-1437) DIH: Enhance XPathRecordReader to deal with //tagname and other improvments.

[Fergus McMenemie (JIRA)]

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

Fergus McMenemie updated SOLR-1437:
---

Attachment: (was: SOLR-1437.patch)

> DIH: Enhance XPathRecordReader to deal with //tagname and other improvments.
> 
>
> Key: SOLR-1437
> URL: https://issues.apache.org/jira/browse/SOLR-1437
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler
>Affects Versions: 1.4
>Reporter: Fergus McMenemie
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1437.patch, SOLR-1437.patch
>
>   Original Estimate: 672h
>  Remaining Estimate: 672h
>
> As per 
> http://www.nabble.com/Re%3A-Extract-info-from-parent-node-during-data-import-%28redirect%3A%29-td25471162.html
>  it would be nice to be able to use expressions such as //tagname when 
> parsing XML documents.

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

[jira] Updated: (SOLR-1437) DIH: Enhance XPathRecordReader to deal with //tagname and other improvments.

[Fergus McMenemie (JIRA)]

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

Fergus McMenemie updated SOLR-1437:
---

Attachment: (was: SOLR-1437.patch)

> DIH: Enhance XPathRecordReader to deal with //tagname and other improvments.
> 
>
> Key: SOLR-1437
> URL: https://issues.apache.org/jira/browse/SOLR-1437
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler
>Affects Versions: 1.4
>Reporter: Fergus McMenemie
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1437.patch, SOLR-1437.patch
>
>   Original Estimate: 672h
>  Remaining Estimate: 672h
>
> As per 
> http://www.nabble.com/Re%3A-Extract-info-from-parent-node-during-data-import-%28redirect%3A%29-td25471162.html
>  it would be nice to be able to use expressions such as //tagname when 
> parsing XML documents.

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

[jira] Updated: (SOLR-1437) DIH: Enhance XPathRecordReader to deal with //tagname and other improvments.

[Fergus McMenemie (JIRA)]

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

Fergus McMenemie updated SOLR-1437:
---

Attachment: SOLR-1437.patch

regenerated patch against latest trunk

> DIH: Enhance XPathRecordReader to deal with //tagname and other improvments.
> 
>
> Key: SOLR-1437
> URL: https://issues.apache.org/jira/browse/SOLR-1437
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler
>Affects Versions: 1.4
>Reporter: Fergus McMenemie
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1437.patch, SOLR-1437.patch
>
>   Original Estimate: 672h
>  Remaining Estimate: 672h
>
> As per 
> http://www.nabble.com/Re%3A-Extract-info-from-parent-node-during-data-import-%28redirect%3A%29-td25471162.html
>  it would be nice to be able to use expressions such as //tagname when 
> parsing XML documents.

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

[jira] Commented: (SOLR-1437) DIH: Enhance XPathRecordReader to deal with //tagname and other improvments.

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-1437:
--

Fergus can you give the patch updated to trunk?

> DIH: Enhance XPathRecordReader to deal with //tagname and other improvments.
> 
>
> Key: SOLR-1437
> URL: https://issues.apache.org/jira/browse/SOLR-1437
> Project: Solr
>  Issue Type: Improvement
>  Components: contrib - DataImportHandler
>Affects Versions: 1.4
>Reporter: Fergus McMenemie
>Assignee: Noble Paul
>Priority: Minor
> Fix For: 1.5
>
> Attachments: SOLR-1437.patch, SOLR-1437.patch, SOLR-1437.patch, 
> SOLR-1437.patch, SOLR-1437.patch
>
>   Original Estimate: 672h
>  Remaining Estimate: 672h
>
> As per 
> http://www.nabble.com/Re%3A-Extract-info-from-parent-node-during-data-import-%28redirect%3A%29-td25471162.html
>  it would be nice to be able to use expressions such as //tagname when 
> parsing XML documents.

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

[jira] Reopened: (SOLR-1458) Java Replication error: NullPointerException SEVERE: SnapPull failed on 2009-09-22 nightly

[Noble Paul (JIRA)]

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

Noble Paul reopened SOLR-1458:
--


isn't this a wrong fix.? It removes an existing functionality (one can't set a 
custom deletion policy when replicateAfterCOmmit is set)

What was wrong with my latest patch?

> Java Replication error: NullPointerException SEVERE: SnapPull failed on 
> 2009-09-22 nightly
> --
>
> Key: SOLR-1458
> URL: https://issues.apache.org/jira/browse/SOLR-1458
> Project: Solr
>  Issue Type: Bug
>  Components: replication (java)
>Affects Versions: 1.4
> Environment: CentOS x64
> 8GB RAM
> Tomcat, running with 7G max memory; memory usage is <2GB, so it's not the 
> problem
> Host a: master
> Host b: slave
> Multiple single core Solr instances, using JNDI.
> Java replication
>Reporter: Artem Russakovskii
>Assignee: Yonik Seeley
> Fix For: 1.4
>
> Attachments: SOLR-1458.patch, SOLR-1458.patch, SOLR-1458.patch, 
> SOLR-1458.patch, SOLR-1458.patch, SolrDeletionPolicy.patch, 
> SolrDeletionPolicy.patch
>
>
> After finally figuring out the new Java based replication, we have started 
> both the slave and the master and issued optimize to all master Solr 
> instances. This triggered some replication to go through just fine, but it 
> looks like some of it is failing.
> Here's what I'm getting in the slave logs, repeatedly for each shard:
> {code} 
> SEVERE: SnapPull failed 
> java.lang.NullPointerException
> at 
> org.apache.solr.handler.SnapPuller.fetchLatestIndex(SnapPuller.java:271)
> at 
> org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:258)
> at org.apache.solr.handler.SnapPuller$1.run(SnapPuller.java:159)
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at 
> java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> {code} 
> If I issue an optimize again on the master to one of the shards, it then 
> triggers a replication and replicates OK. I have a feeling that these 
> SnapPull failures appear later on but right now I don't have enough to form a 
> pattern.
> Here's replication.properties on one of the failed slave instances.
> {code}
> cat data/replication.properties 
> #Replication details
> #Wed Sep 23 19:35:30 PDT 2009
> replicationFailedAtList=1253759730020,1253759700018,1253759670019,1253759640018,1253759610018,1253759580022,1253759550019,1253759520016,1253759490026,1253759460016
> previousCycleTimeInSeconds=0
> timesFailed=113
> indexReplicatedAtList=1253759730020,1253759700018,1253759670019,1253759640018,1253759610018,1253759580022,1253759550019,1253759520016,1253759490026,1253759460016
> indexReplicatedAt=1253759730020
> replicationFailedAt=1253759730020
> lastCycleBytesDownloaded=0
> timesIndexReplicated=113
> {code}
> and another
> {code}
> cat data/replication.properties 
> #Replication details
> #Wed Sep 23 18:42:01 PDT 2009
> replicationFailedAtList=1253756490034,1253756460169
> previousCycleTimeInSeconds=1
> timesFailed=2
> indexReplicatedAtList=1253756521284,1253756490034,1253756460169
> indexReplicatedAt=1253756521284
> replicationFailedAt=1253756490034
> lastCycleBytesDownloaded=22932293
> timesIndexReplicated=3
> {code}
> Some relevant configs:
> In solrconfig.xml:
> {code}
> 
>   
> 
> ${enable.master:false}
> optimize
> optimize
> 00:00:20
> 
> 
> ${enable.slave:false}
> 
> ${master.url}
> 
> 00:00:30
> 
>   
> {code}
> The slave then has this in solrcore.properties:
> {code}
> enable.slave=true
> master.url=URLOFMASTER/replication
> {code}
> and the master has
> {code}
> enable.master=true
> {code}
> I'd be glad to provide more details but I'm not sure what else I can do.  
> SOLR-926 may be relevant.
> Thanks.

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

Re: unit test stability

[Shalin Shekhar Mangar]

On Tue, Sep 29, 2009 at 7:23 PM, Yonik Seeley wrote:

>
> Going forward, it would be nice to keep on top of these a little more,
> otherwise the tests become like the little boy who cried wolf.
>
> As to the failure in run#32: here it is.
> at
>
> org.apache.solr.handler.dataimport.TestEvaluatorBag.testGetDateFormatEvaluator(TestEvaluatorBag.java:120)
> 
>

Thanks for pointing out this one. I've changed it to use a fixed date
instead of new Date() which caused failures.

-- 
Regards,
Shalin Shekhar Mangar.

[jira] Resolved: (SOLR-1473) Unable to use last_index_time in FileListEntityProcessor newerThan/olderThan attributes

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar resolved SOLR-1473.
-

Resolution: Fixed

Committed revision 820237.

Thanks for noticing this Bill!

> Unable to use last_index_time in FileListEntityProcessor newerThan/olderThan 
> attributes
> ---
>
> Key: SOLR-1473
> URL: https://issues.apache.org/jira/browse/SOLR-1473
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 1.3
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
> Attachments: SOLR-1473.patch, SOLR-1473.patch
>
>
> Reported by Bill Dueber:
> http://www.lucidimagination.com/search/document/fdcbcb1360a92057/dataimporter_last_index_time_as_an_argument_to_newerthan_in_filelistentityprocessor
> The root cause is that when last_index_time is not available (first import), 
> FileListEntityProcessor will throw a ParseException.

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

[jira] Updated: (SOLR-1473) Unable to use last_index_time in FileListEntityProcessor newerThan/olderThan attributes

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-1473:


Attachment: SOLR-1473.patch

Returning null if variable is not resolved is not necessary now. Since 
last_index_time is always set (either to epoch or last index time), no changes 
to FileListEntityProcessor is needed. If a variable cannot be resolved then 
that is a valid point of failure.

I'll commit the tests shortly.

> Unable to use last_index_time in FileListEntityProcessor newerThan/olderThan 
> attributes
> ---
>
> Key: SOLR-1473
> URL: https://issues.apache.org/jira/browse/SOLR-1473
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 1.3
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
> Attachments: SOLR-1473.patch, SOLR-1473.patch
>
>
> Reported by Bill Dueber:
> http://www.lucidimagination.com/search/document/fdcbcb1360a92057/dataimporter_last_index_time_as_an_argument_to_newerthan_in_filelistentityprocessor
> The root cause is that when last_index_time is not available (first import), 
> FileListEntityProcessor will throw a ParseException.

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

[jira] Resolved: (SOLR-1474) DataImportHandler tests leave dataimport.properties after finish

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar resolved SOLR-1474.
-

Resolution: Fixed

Committed revision 820235.

> DataImportHandler tests leave dataimport.properties after finish
> 
>
> Key: SOLR-1474
> URL: https://issues.apache.org/jira/browse/SOLR-1474
> Project: Solr
>  Issue Type: Test
>  Components: contrib - DataImportHandler
>Affects Versions: 1.3
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
> Attachments: SOLR-1474.patch, SOLR-1474.patch
>
>
> DataImportHandler tests leave dataimport.properties after finish. A lot of 
> tests which use last_index_time fail if dataimport.properties is removed in 
> tearDown. Either the tests are wrong or there is a bug lurking somewhere. 
> This needs to be fixed before 1.4 release.

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

[jira] Updated: (SOLR-1474) DataImportHandler tests leave dataimport.properties after finish

[Shalin Shekhar Mangar (JIRA)]

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

Shalin Shekhar Mangar updated SOLR-1474:


Attachment: SOLR-1474.patch

There was a shortcut in DIH to do a full-import if last_index_time is not 
available even if a delta-import is requested. I believe we added that so that 
empty last_index_time doesn't give errors

# Removed last_index_time from DataImporter since DocBuilder reads it anyway
# If last_index_time is not present, use epoch

All tests pass. I'll commit this shortly.

> DataImportHandler tests leave dataimport.properties after finish
> 
>
> Key: SOLR-1474
> URL: https://issues.apache.org/jira/browse/SOLR-1474
> Project: Solr
>  Issue Type: Test
>  Components: contrib - DataImportHandler
>Affects Versions: 1.3
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 1.4
>
> Attachments: SOLR-1474.patch, SOLR-1474.patch
>
>
> DataImportHandler tests leave dataimport.properties after finish. A lot of 
> tests which use last_index_time fail if dataimport.properties is removed in 
> tearDown. Either the tests are wrong or there is a bug lurking somewhere. 
> This needs to be fixed before 1.4 release.

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

Hudson build is back to normal: Solr-trunk #941

[Apache Hudson Server]

See 

Upgrade POI?

[Shalin Shekhar Mangar]

Shall we upgrade to POI 3.5 final for Solr Cell?

-- 
Regards,
Shalin Shekhar Mangar.

Re: [Solr Wiki] Update of "DataImportHandler" by ShalinMangar

[Shalin Shekhar Mangar]

On Wed, Sep 30, 2009 at 12:22 PM, Shalin Shekhar Mangar <
shalinman...@gmail.com> wrote:

> On Wed, Sep 30, 2009 at 5:51 AM, Chris Hostetter  > wrote:
>
>>
>> : The "DataImportHandler" page has been changed by ShalinMangar:
>> :
>> http://wiki.apache.org/solr/DataImportHandler?action=diff&rev1=210&rev2=211
>>
>> This edit looks very odd ... the diff is pretty confusing, but it looks
>> like way more got deleted then probably should have been (i'm guessing
>> either an artifact of the syntax chagnes from the MoinMOin upgrade, or an
>> inadvertane "cut" during editing)
>>
>> Shalin: can you spot check this page ... it looks like several sub
>> sections on the types of entity processors were removed.
>>
>>
> That was definitely not intended. I remember Noble having a similar problem
> a week earlier. Perhaps the new MoinMoin has problems with very large wiki
> pages such as DIH's.
>
> I'll fix that.
>

This has been fixed. Thanks!

-- 
Regards,
Shalin Shekhar Mangar.

Re: No mails for trivial wiki edits

[Shalin Shekhar Mangar]

On Tue, Sep 29, 2009 at 12:24 PM, Shalin Shekhar Mangar <
shalinman...@gmail.com> wrote:

> It seems that after the MoinMoin update, trivial edits do not generate a
> mail to solr-commits. Does anybody know how to re-enable them?
>

Wiki reverts are also not generating an email. Does anybody who have wiki
admin karma look into this?

-- 
Regards,
Shalin Shekhar Mangar.