date:20121217


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

Dawid Weiss commented on SOLR-4205:
---

This definitely looks like a bug in the runner although I have no idea how to 
reproduce this or what may be causing it. The symptoms are: truncated events 
file:
{code}
[
  SUITE_FAILURE
{code}

and the main test thread gone. This is very weird.

 Clover runs on ASF Jenkins idle dead without a test or any thread running in 
 main() loop waiting for file descriptor
 

 Key: SOLR-4205
 URL: https://issues.apache.org/jira/browse/SOLR-4205
 Project: Solr
  Issue Type: Bug
  Components: Tests
 Environment: FreeBSD Jenkins
Reporter: Uwe Schindler
Assignee: Dawid Weiss

 I had to kill ASF Jenkins Clover builds two times after several 10 hours of 
 inactivity in a random Solr test. I requested a stack trace before killing 
 the only running JVM (clover runs with one JVM only, because clover does not 
 like multiple processes writing the same clover metrics file).
 In both cases (4.x and trunk) the stack trace was looking identical after 
 sending kill -3...
 https://builds.apache.org/job/Lucene-Solr-Clover-trunk/76/consoleFull 
 (yesterday):
 {noformat}
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:01:00, stalled for 28447s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:02:00, stalled for 28507s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:03:00, stalled for 28567s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] JVM J0: stdout was not empty, see: 
 /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Clover-trunk/solr/build/solr-core/test/temp/junit4-J0-20121216_044733_583.sysout
 [junit4:junit4]  JVM J0: stdout (verbatim) 
 [junit4:junit4] 2012-12-16 13:03:49
 [junit4:junit4] Full thread dump OpenJDK 64-Bit Server VM (20.0-b12 mixed 
 mode):
 [junit4:junit4] 
 [junit4:junit4] searcherExecutor-2577-thread-1 prio=5 
 tid=0x00085eb67000 nid=0x61c105b waiting on condition [0x70b0d000]
 [junit4:junit4]java.lang.Thread.State: WAITING (parking)
 [junit4:junit4]   at sun.misc.Unsafe.park(Native Method)
 [junit4:junit4]   - parking to wait for  0x0008178c9c40 (a 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 [junit4:junit4]   at 
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 [junit4:junit4]   at 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 [junit4:junit4]   at 
 java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:386)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 [junit4:junit4]   at java.lang.Thread.run(Thread.java:679)
 [junit4:junit4] 
 [junit4:junit4] RMI TCP Accept-0 daemon prio=5 tid=0x000840ce2800 
 nid=0x61c0aa2 runnable [0x79496000]
 [junit4:junit4]java.lang.Thread.State: RUNNABLE
 [junit4:junit4]   at java.net.PlainSocketImpl.socketAccept(Native Method)
 [junit4:junit4]   at 
 java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:375)
 [junit4:junit4]   at 
 java.net.ServerSocket.implAccept(ServerSocket.java:470)
 [junit4:junit4]   at java.net.ServerSocket.accept(ServerSocket.java:438)
 [junit4:junit4]   at 
 sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:387)
 [junit4:junit4]   at 
 sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:359)
 [junit4:junit4]   at java.lang.Thread.run(Thread.java:679)
 [junit4:junit4] 
 [junit4:junit4] RMI Scheduler(0) daemon prio=5 tid=0x000840ce1000 
 nid=0x61c0969 waiting on condition [0x70f11000]
 [junit4:junit4]java.lang.Thread.State: WAITING (parking)
 [junit4:junit4]   at sun.misc.Unsafe.park(Native Method)
 [junit4:junit4]   - parking to wait for  0x000814f12f88 (a 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 [junit4:junit4]   at 
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 [junit4:junit4]   at 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 [junit4:junit4]   at

[jira] [Commented] (SOLR-4205) Clover runs on ASF Jenkins idle dead without a test or any thread running in main() loop waiting for file descriptor


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

Uwe Schindler commented on SOLR-4205:
-

Do you flush the event file?

 Clover runs on ASF Jenkins idle dead without a test or any thread running in 
 main() loop waiting for file descriptor
 

 Key: SOLR-4205
 URL: https://issues.apache.org/jira/browse/SOLR-4205
 Project: Solr
  Issue Type: Bug
  Components: Tests
 Environment: FreeBSD Jenkins
Reporter: Uwe Schindler
Assignee: Dawid Weiss

 I had to kill ASF Jenkins Clover builds two times after several 10 hours of 
 inactivity in a random Solr test. I requested a stack trace before killing 
 the only running JVM (clover runs with one JVM only, because clover does not 
 like multiple processes writing the same clover metrics file).
 In both cases (4.x and trunk) the stack trace was looking identical after 
 sending kill -3...
 https://builds.apache.org/job/Lucene-Solr-Clover-trunk/76/consoleFull 
 (yesterday):
 {noformat}
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:01:00, stalled for 28447s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:02:00, stalled for 28507s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:03:00, stalled for 28567s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] JVM J0: stdout was not empty, see: 
 /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Clover-trunk/solr/build/solr-core/test/temp/junit4-J0-20121216_044733_583.sysout
 [junit4:junit4]  JVM J0: stdout (verbatim) 
 [junit4:junit4] 2012-12-16 13:03:49
 [junit4:junit4] Full thread dump OpenJDK 64-Bit Server VM (20.0-b12 mixed 
 mode):
 [junit4:junit4] 
 [junit4:junit4] searcherExecutor-2577-thread-1 prio=5 
 tid=0x00085eb67000 nid=0x61c105b waiting on condition [0x70b0d000]
 [junit4:junit4]java.lang.Thread.State: WAITING (parking)
 [junit4:junit4]   at sun.misc.Unsafe.park(Native Method)
 [junit4:junit4]   - parking to wait for  0x0008178c9c40 (a 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 [junit4:junit4]   at 
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 [junit4:junit4]   at 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 [junit4:junit4]   at 
 java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:386)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 [junit4:junit4]   at java.lang.Thread.run(Thread.java:679)
 [junit4:junit4] 
 [junit4:junit4] RMI TCP Accept-0 daemon prio=5 tid=0x000840ce2800 
 nid=0x61c0aa2 runnable [0x79496000]
 [junit4:junit4]java.lang.Thread.State: RUNNABLE
 [junit4:junit4]   at java.net.PlainSocketImpl.socketAccept(Native Method)
 [junit4:junit4]   at 
 java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:375)
 [junit4:junit4]   at 
 java.net.ServerSocket.implAccept(ServerSocket.java:470)
 [junit4:junit4]   at java.net.ServerSocket.accept(ServerSocket.java:438)
 [junit4:junit4]   at 
 sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:387)
 [junit4:junit4]   at 
 sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:359)
 [junit4:junit4]   at java.lang.Thread.run(Thread.java:679)
 [junit4:junit4] 
 [junit4:junit4] RMI Scheduler(0) daemon prio=5 tid=0x000840ce1000 
 nid=0x61c0969 waiting on condition [0x70f11000]
 [junit4:junit4]java.lang.Thread.State: WAITING (parking)
 [junit4:junit4]   at sun.misc.Unsafe.park(Native Method)
 [junit4:junit4]   - parking to wait for  0x000814f12f88 (a 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 [junit4:junit4]   at 
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 [junit4:junit4]   at 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 [junit4:junit4]   at 
 java.util.concurrent.DelayQueue.take(DelayQueue.java:189)
 [junit4:junit4]   at 
 java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:688)
 [junit4:junit4]   at

[jira] [Commented] (SOLR-4205) Clover runs on ASF Jenkins idle dead without a test or any thread running in main() loop waiting for file descriptor


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

Dawid Weiss commented on SOLR-4205:
---

Sure.

 Clover runs on ASF Jenkins idle dead without a test or any thread running in 
 main() loop waiting for file descriptor
 

 Key: SOLR-4205
 URL: https://issues.apache.org/jira/browse/SOLR-4205
 Project: Solr
  Issue Type: Bug
  Components: Tests
 Environment: FreeBSD Jenkins
Reporter: Uwe Schindler
Assignee: Dawid Weiss

 I had to kill ASF Jenkins Clover builds two times after several 10 hours of 
 inactivity in a random Solr test. I requested a stack trace before killing 
 the only running JVM (clover runs with one JVM only, because clover does not 
 like multiple processes writing the same clover metrics file).
 In both cases (4.x and trunk) the stack trace was looking identical after 
 sending kill -3...
 https://builds.apache.org/job/Lucene-Solr-Clover-trunk/76/consoleFull 
 (yesterday):
 {noformat}
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:01:00, stalled for 28447s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:02:00, stalled for 28507s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:03:00, stalled for 28567s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] JVM J0: stdout was not empty, see: 
 /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Clover-trunk/solr/build/solr-core/test/temp/junit4-J0-20121216_044733_583.sysout
 [junit4:junit4]  JVM J0: stdout (verbatim) 
 [junit4:junit4] 2012-12-16 13:03:49
 [junit4:junit4] Full thread dump OpenJDK 64-Bit Server VM (20.0-b12 mixed 
 mode):
 [junit4:junit4] 
 [junit4:junit4] searcherExecutor-2577-thread-1 prio=5 
 tid=0x00085eb67000 nid=0x61c105b waiting on condition [0x70b0d000]
 [junit4:junit4]java.lang.Thread.State: WAITING (parking)
 [junit4:junit4]   at sun.misc.Unsafe.park(Native Method)
 [junit4:junit4]   - parking to wait for  0x0008178c9c40 (a 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 [junit4:junit4]   at 
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 [junit4:junit4]   at 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 [junit4:junit4]   at 
 java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:386)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 [junit4:junit4]   at java.lang.Thread.run(Thread.java:679)
 [junit4:junit4] 
 [junit4:junit4] RMI TCP Accept-0 daemon prio=5 tid=0x000840ce2800 
 nid=0x61c0aa2 runnable [0x79496000]
 [junit4:junit4]java.lang.Thread.State: RUNNABLE
 [junit4:junit4]   at java.net.PlainSocketImpl.socketAccept(Native Method)
 [junit4:junit4]   at 
 java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:375)
 [junit4:junit4]   at 
 java.net.ServerSocket.implAccept(ServerSocket.java:470)
 [junit4:junit4]   at java.net.ServerSocket.accept(ServerSocket.java:438)
 [junit4:junit4]   at 
 sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:387)
 [junit4:junit4]   at 
 sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:359)
 [junit4:junit4]   at java.lang.Thread.run(Thread.java:679)
 [junit4:junit4] 
 [junit4:junit4] RMI Scheduler(0) daemon prio=5 tid=0x000840ce1000 
 nid=0x61c0969 waiting on condition [0x70f11000]
 [junit4:junit4]java.lang.Thread.State: WAITING (parking)
 [junit4:junit4]   at sun.misc.Unsafe.park(Native Method)
 [junit4:junit4]   - parking to wait for  0x000814f12f88 (a 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 [junit4:junit4]   at 
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 [junit4:junit4]   at 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 [junit4:junit4]   at 
 java.util.concurrent.DelayQueue.take(DelayQueue.java:189)
 [junit4:junit4]   at 
 java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:688)
 [junit4:junit4]   at

[jira] [Commented] (SOLR-4205) Clover runs on ASF Jenkins idle dead without a test or any thread running in main() loop waiting for file descriptor


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

Dawid Weiss commented on SOLR-4205:
---

I pushed yet another minor release (it's damn hard to test against third party 
libraries with ivy...) -- 2.0.7. It just contains an explicit flush but I don't 
think this will make a difference. 

Uwe, could you upgrade the ivy files and enable the build again? we'll see if 
this helps or changes the behavior anyhow. I'm busy for the rest of the day but 
I'll take a look at the results in the evening.

 Clover runs on ASF Jenkins idle dead without a test or any thread running in 
 main() loop waiting for file descriptor
 

 Key: SOLR-4205
 URL: https://issues.apache.org/jira/browse/SOLR-4205
 Project: Solr
  Issue Type: Bug
  Components: Tests
 Environment: FreeBSD Jenkins
Reporter: Uwe Schindler
Assignee: Dawid Weiss

 I had to kill ASF Jenkins Clover builds two times after several 10 hours of 
 inactivity in a random Solr test. I requested a stack trace before killing 
 the only running JVM (clover runs with one JVM only, because clover does not 
 like multiple processes writing the same clover metrics file).
 In both cases (4.x and trunk) the stack trace was looking identical after 
 sending kill -3...
 https://builds.apache.org/job/Lucene-Solr-Clover-trunk/76/consoleFull 
 (yesterday):
 {noformat}
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:01:00, stalled for 28447s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:02:00, stalled for 28507s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:03:00, stalled for 28567s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] JVM J0: stdout was not empty, see: 
 /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Clover-trunk/solr/build/solr-core/test/temp/junit4-J0-20121216_044733_583.sysout
 [junit4:junit4]  JVM J0: stdout (verbatim) 
 [junit4:junit4] 2012-12-16 13:03:49
 [junit4:junit4] Full thread dump OpenJDK 64-Bit Server VM (20.0-b12 mixed 
 mode):
 [junit4:junit4] 
 [junit4:junit4] searcherExecutor-2577-thread-1 prio=5 
 tid=0x00085eb67000 nid=0x61c105b waiting on condition [0x70b0d000]
 [junit4:junit4]java.lang.Thread.State: WAITING (parking)
 [junit4:junit4]   at sun.misc.Unsafe.park(Native Method)
 [junit4:junit4]   - parking to wait for  0x0008178c9c40 (a 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 [junit4:junit4]   at 
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 [junit4:junit4]   at 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 [junit4:junit4]   at 
 java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:386)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 [junit4:junit4]   at java.lang.Thread.run(Thread.java:679)
 [junit4:junit4] 
 [junit4:junit4] RMI TCP Accept-0 daemon prio=5 tid=0x000840ce2800 
 nid=0x61c0aa2 runnable [0x79496000]
 [junit4:junit4]java.lang.Thread.State: RUNNABLE
 [junit4:junit4]   at java.net.PlainSocketImpl.socketAccept(Native Method)
 [junit4:junit4]   at 
 java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:375)
 [junit4:junit4]   at 
 java.net.ServerSocket.implAccept(ServerSocket.java:470)
 [junit4:junit4]   at java.net.ServerSocket.accept(ServerSocket.java:438)
 [junit4:junit4]   at 
 sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:387)
 [junit4:junit4]   at 
 sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:359)
 [junit4:junit4]   at java.lang.Thread.run(Thread.java:679)
 [junit4:junit4] 
 [junit4:junit4] RMI Scheduler(0) daemon prio=5 tid=0x000840ce1000 
 nid=0x61c0969 waiting on condition [0x70f11000]
 [junit4:junit4]java.lang.Thread.State: WAITING (parking)
 [junit4:junit4]   at sun.misc.Unsafe.park(Native Method)
 [junit4:junit4]   - parking to wait for  0x000814f12f88 (a 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 [junit4:junit4]   at 
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 [junit4:junit4]   at

[jira] [Commented] (SOLR-4205) Clover runs on ASF Jenkins idle dead without a test or any thread running in main() loop waiting for file descriptor


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

Uwe Schindler commented on SOLR-4205:
-

Updated in trunk revision: 1422836, 4.x revision: 1422837

 Clover runs on ASF Jenkins idle dead without a test or any thread running in 
 main() loop waiting for file descriptor
 

 Key: SOLR-4205
 URL: https://issues.apache.org/jira/browse/SOLR-4205
 Project: Solr
  Issue Type: Bug
  Components: Tests
 Environment: FreeBSD Jenkins
Reporter: Uwe Schindler
Assignee: Dawid Weiss

 I had to kill ASF Jenkins Clover builds two times after several 10 hours of 
 inactivity in a random Solr test. I requested a stack trace before killing 
 the only running JVM (clover runs with one JVM only, because clover does not 
 like multiple processes writing the same clover metrics file).
 In both cases (4.x and trunk) the stack trace was looking identical after 
 sending kill -3...
 https://builds.apache.org/job/Lucene-Solr-Clover-trunk/76/consoleFull 
 (yesterday):
 {noformat}
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:01:00, stalled for 28447s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:02:00, stalled for 28507s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:03:00, stalled for 28567s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] JVM J0: stdout was not empty, see: 
 /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Clover-trunk/solr/build/solr-core/test/temp/junit4-J0-20121216_044733_583.sysout
 [junit4:junit4]  JVM J0: stdout (verbatim) 
 [junit4:junit4] 2012-12-16 13:03:49
 [junit4:junit4] Full thread dump OpenJDK 64-Bit Server VM (20.0-b12 mixed 
 mode):
 [junit4:junit4] 
 [junit4:junit4] searcherExecutor-2577-thread-1 prio=5 
 tid=0x00085eb67000 nid=0x61c105b waiting on condition [0x70b0d000]
 [junit4:junit4]java.lang.Thread.State: WAITING (parking)
 [junit4:junit4]   at sun.misc.Unsafe.park(Native Method)
 [junit4:junit4]   - parking to wait for  0x0008178c9c40 (a 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 [junit4:junit4]   at 
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 [junit4:junit4]   at 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 [junit4:junit4]   at 
 java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:386)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 [junit4:junit4]   at java.lang.Thread.run(Thread.java:679)
 [junit4:junit4] 
 [junit4:junit4] RMI TCP Accept-0 daemon prio=5 tid=0x000840ce2800 
 nid=0x61c0aa2 runnable [0x79496000]
 [junit4:junit4]java.lang.Thread.State: RUNNABLE
 [junit4:junit4]   at java.net.PlainSocketImpl.socketAccept(Native Method)
 [junit4:junit4]   at 
 java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:375)
 [junit4:junit4]   at 
 java.net.ServerSocket.implAccept(ServerSocket.java:470)
 [junit4:junit4]   at java.net.ServerSocket.accept(ServerSocket.java:438)
 [junit4:junit4]   at 
 sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:387)
 [junit4:junit4]   at 
 sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:359)
 [junit4:junit4]   at java.lang.Thread.run(Thread.java:679)
 [junit4:junit4] 
 [junit4:junit4] RMI Scheduler(0) daemon prio=5 tid=0x000840ce1000 
 nid=0x61c0969 waiting on condition [0x70f11000]
 [junit4:junit4]java.lang.Thread.State: WAITING (parking)
 [junit4:junit4]   at sun.misc.Unsafe.park(Native Method)
 [junit4:junit4]   - parking to wait for  0x000814f12f88 (a 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 [junit4:junit4]   at 
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 [junit4:junit4]   at 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 [junit4:junit4]   at 
 java.util.concurrent.DelayQueue.take(DelayQueue.java:189)
 [junit4:junit4]   at 
 java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:688)

[jira] [Commented] (SOLR-4205) Clover runs on ASF Jenkins idle dead without a test or any thread running in main() loop waiting for file descriptor


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

Commit Tag Bot commented on SOLR-4205:
--

[trunk commit] Uwe Schindler
http://svn.apache.org/viewvc?view=revisionrevision=1422836

SOLR-4205: Update randomized-testing framework to 2.0.7


 Clover runs on ASF Jenkins idle dead without a test or any thread running in 
 main() loop waiting for file descriptor
 

 Key: SOLR-4205
 URL: https://issues.apache.org/jira/browse/SOLR-4205
 Project: Solr
  Issue Type: Bug
  Components: Tests
 Environment: FreeBSD Jenkins
Reporter: Uwe Schindler
Assignee: Dawid Weiss

 I had to kill ASF Jenkins Clover builds two times after several 10 hours of 
 inactivity in a random Solr test. I requested a stack trace before killing 
 the only running JVM (clover runs with one JVM only, because clover does not 
 like multiple processes writing the same clover metrics file).
 In both cases (4.x and trunk) the stack trace was looking identical after 
 sending kill -3...
 https://builds.apache.org/job/Lucene-Solr-Clover-trunk/76/consoleFull 
 (yesterday):
 {noformat}
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:01:00, stalled for 28447s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:02:00, stalled for 28507s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:03:00, stalled for 28567s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] JVM J0: stdout was not empty, see: 
 /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Clover-trunk/solr/build/solr-core/test/temp/junit4-J0-20121216_044733_583.sysout
 [junit4:junit4]  JVM J0: stdout (verbatim) 
 [junit4:junit4] 2012-12-16 13:03:49
 [junit4:junit4] Full thread dump OpenJDK 64-Bit Server VM (20.0-b12 mixed 
 mode):
 [junit4:junit4] 
 [junit4:junit4] searcherExecutor-2577-thread-1 prio=5 
 tid=0x00085eb67000 nid=0x61c105b waiting on condition [0x70b0d000]
 [junit4:junit4]java.lang.Thread.State: WAITING (parking)
 [junit4:junit4]   at sun.misc.Unsafe.park(Native Method)
 [junit4:junit4]   - parking to wait for  0x0008178c9c40 (a 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 [junit4:junit4]   at 
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 [junit4:junit4]   at 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 [junit4:junit4]   at 
 java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:386)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 [junit4:junit4]   at java.lang.Thread.run(Thread.java:679)
 [junit4:junit4] 
 [junit4:junit4] RMI TCP Accept-0 daemon prio=5 tid=0x000840ce2800 
 nid=0x61c0aa2 runnable [0x79496000]
 [junit4:junit4]java.lang.Thread.State: RUNNABLE
 [junit4:junit4]   at java.net.PlainSocketImpl.socketAccept(Native Method)
 [junit4:junit4]   at 
 java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:375)
 [junit4:junit4]   at 
 java.net.ServerSocket.implAccept(ServerSocket.java:470)
 [junit4:junit4]   at java.net.ServerSocket.accept(ServerSocket.java:438)
 [junit4:junit4]   at 
 sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:387)
 [junit4:junit4]   at 
 sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:359)
 [junit4:junit4]   at java.lang.Thread.run(Thread.java:679)
 [junit4:junit4] 
 [junit4:junit4] RMI Scheduler(0) daemon prio=5 tid=0x000840ce1000 
 nid=0x61c0969 waiting on condition [0x70f11000]
 [junit4:junit4]java.lang.Thread.State: WAITING (parking)
 [junit4:junit4]   at sun.misc.Unsafe.park(Native Method)
 [junit4:junit4]   - parking to wait for  0x000814f12f88 (a 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 [junit4:junit4]   at 
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 [junit4:junit4]   at 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 [junit4:junit4]   at 
 java.util.concurrent.DelayQueue.take(DelayQueue.java:189)
 [junit4:junit4]   at

[jira] [Commented] (SOLR-4205) Clover runs on ASF Jenkins idle dead without a test or any thread running in main() loop waiting for file descriptor


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

Uwe Schindler commented on SOLR-4205:
-

I triggered a new trunk clover build.

 Clover runs on ASF Jenkins idle dead without a test or any thread running in 
 main() loop waiting for file descriptor
 

 Key: SOLR-4205
 URL: https://issues.apache.org/jira/browse/SOLR-4205
 Project: Solr
  Issue Type: Bug
  Components: Tests
 Environment: FreeBSD Jenkins
Reporter: Uwe Schindler
Assignee: Dawid Weiss

 I had to kill ASF Jenkins Clover builds two times after several 10 hours of 
 inactivity in a random Solr test. I requested a stack trace before killing 
 the only running JVM (clover runs with one JVM only, because clover does not 
 like multiple processes writing the same clover metrics file).
 In both cases (4.x and trunk) the stack trace was looking identical after 
 sending kill -3...
 https://builds.apache.org/job/Lucene-Solr-Clover-trunk/76/consoleFull 
 (yesterday):
 {noformat}
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:01:00, stalled for 28447s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:02:00, stalled for 28507s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:03:00, stalled for 28567s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] JVM J0: stdout was not empty, see: 
 /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Clover-trunk/solr/build/solr-core/test/temp/junit4-J0-20121216_044733_583.sysout
 [junit4:junit4]  JVM J0: stdout (verbatim) 
 [junit4:junit4] 2012-12-16 13:03:49
 [junit4:junit4] Full thread dump OpenJDK 64-Bit Server VM (20.0-b12 mixed 
 mode):
 [junit4:junit4] 
 [junit4:junit4] searcherExecutor-2577-thread-1 prio=5 
 tid=0x00085eb67000 nid=0x61c105b waiting on condition [0x70b0d000]
 [junit4:junit4]java.lang.Thread.State: WAITING (parking)
 [junit4:junit4]   at sun.misc.Unsafe.park(Native Method)
 [junit4:junit4]   - parking to wait for  0x0008178c9c40 (a 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 [junit4:junit4]   at 
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 [junit4:junit4]   at 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 [junit4:junit4]   at 
 java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:386)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 [junit4:junit4]   at java.lang.Thread.run(Thread.java:679)
 [junit4:junit4] 
 [junit4:junit4] RMI TCP Accept-0 daemon prio=5 tid=0x000840ce2800 
 nid=0x61c0aa2 runnable [0x79496000]
 [junit4:junit4]java.lang.Thread.State: RUNNABLE
 [junit4:junit4]   at java.net.PlainSocketImpl.socketAccept(Native Method)
 [junit4:junit4]   at 
 java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:375)
 [junit4:junit4]   at 
 java.net.ServerSocket.implAccept(ServerSocket.java:470)
 [junit4:junit4]   at java.net.ServerSocket.accept(ServerSocket.java:438)
 [junit4:junit4]   at 
 sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:387)
 [junit4:junit4]   at 
 sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:359)
 [junit4:junit4]   at java.lang.Thread.run(Thread.java:679)
 [junit4:junit4] 
 [junit4:junit4] RMI Scheduler(0) daemon prio=5 tid=0x000840ce1000 
 nid=0x61c0969 waiting on condition [0x70f11000]
 [junit4:junit4]java.lang.Thread.State: WAITING (parking)
 [junit4:junit4]   at sun.misc.Unsafe.park(Native Method)
 [junit4:junit4]   - parking to wait for  0x000814f12f88 (a 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 [junit4:junit4]   at 
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 [junit4:junit4]   at 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 [junit4:junit4]   at 
 java.util.concurrent.DelayQueue.take(DelayQueue.java:189)
 [junit4:junit4]   at 
 java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:688)
 [junit4:junit4]   at

[jira] [Commented] (SOLR-4205) Clover runs on ASF Jenkins idle dead without a test or any thread running in main() loop waiting for file descriptor


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

Commit Tag Bot commented on SOLR-4205:
--

[branch_4x commit] Uwe Schindler
http://svn.apache.org/viewvc?view=revisionrevision=1422837

Merged revision(s) 1422836 from lucene/dev/trunk:
SOLR-4205: Update randomized-testing framework to 2.0.7


 Clover runs on ASF Jenkins idle dead without a test or any thread running in 
 main() loop waiting for file descriptor
 

 Key: SOLR-4205
 URL: https://issues.apache.org/jira/browse/SOLR-4205
 Project: Solr
  Issue Type: Bug
  Components: Tests
 Environment: FreeBSD Jenkins
Reporter: Uwe Schindler
Assignee: Dawid Weiss

 I had to kill ASF Jenkins Clover builds two times after several 10 hours of 
 inactivity in a random Solr test. I requested a stack trace before killing 
 the only running JVM (clover runs with one JVM only, because clover does not 
 like multiple processes writing the same clover metrics file).
 In both cases (4.x and trunk) the stack trace was looking identical after 
 sending kill -3...
 https://builds.apache.org/job/Lucene-Solr-Clover-trunk/76/consoleFull 
 (yesterday):
 {noformat}
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:01:00, stalled for 28447s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:02:00, stalled for 28507s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:03:00, stalled for 28567s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] JVM J0: stdout was not empty, see: 
 /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Clover-trunk/solr/build/solr-core/test/temp/junit4-J0-20121216_044733_583.sysout
 [junit4:junit4]  JVM J0: stdout (verbatim) 
 [junit4:junit4] 2012-12-16 13:03:49
 [junit4:junit4] Full thread dump OpenJDK 64-Bit Server VM (20.0-b12 mixed 
 mode):
 [junit4:junit4] 
 [junit4:junit4] searcherExecutor-2577-thread-1 prio=5 
 tid=0x00085eb67000 nid=0x61c105b waiting on condition [0x70b0d000]
 [junit4:junit4]java.lang.Thread.State: WAITING (parking)
 [junit4:junit4]   at sun.misc.Unsafe.park(Native Method)
 [junit4:junit4]   - parking to wait for  0x0008178c9c40 (a 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 [junit4:junit4]   at 
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 [junit4:junit4]   at 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 [junit4:junit4]   at 
 java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:386)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 [junit4:junit4]   at java.lang.Thread.run(Thread.java:679)
 [junit4:junit4] 
 [junit4:junit4] RMI TCP Accept-0 daemon prio=5 tid=0x000840ce2800 
 nid=0x61c0aa2 runnable [0x79496000]
 [junit4:junit4]java.lang.Thread.State: RUNNABLE
 [junit4:junit4]   at java.net.PlainSocketImpl.socketAccept(Native Method)
 [junit4:junit4]   at 
 java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:375)
 [junit4:junit4]   at 
 java.net.ServerSocket.implAccept(ServerSocket.java:470)
 [junit4:junit4]   at java.net.ServerSocket.accept(ServerSocket.java:438)
 [junit4:junit4]   at 
 sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:387)
 [junit4:junit4]   at 
 sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:359)
 [junit4:junit4]   at java.lang.Thread.run(Thread.java:679)
 [junit4:junit4] 
 [junit4:junit4] RMI Scheduler(0) daemon prio=5 tid=0x000840ce1000 
 nid=0x61c0969 waiting on condition [0x70f11000]
 [junit4:junit4]java.lang.Thread.State: WAITING (parking)
 [junit4:junit4]   at sun.misc.Unsafe.park(Native Method)
 [junit4:junit4]   - parking to wait for  0x000814f12f88 (a 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 [junit4:junit4]   at 
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 [junit4:junit4]   at 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 [junit4:junit4]   at 
 java.util.concurrent.DelayQueue.take(DelayQueue.java:189)

[jira] [Commented] (SOLR-3925) Expose SpanFirst in eDismax

2012-12-17 Thread Vlado Kurelec (JIRA)


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

Vlado Kurelec commented on SOLR-3925:
-

Hi, at first, thanks a lot for this patch. 
I've built it on a rev. 1406758 and found following issues:
- edismax query throws an exception when there's no sf parameter
- SpanFirst doesn't process the search term through the query anayzer defined 
on that field
- if search term is enclosed in (), they are not striped but passed as part of 
the term
How come it is not included in night build? Is there another way to do boost by 
position?



 Expose SpanFirst in eDismax
 ---

 Key: SOLR-3925
 URL: https://issues.apache.org/jira/browse/SOLR-3925
 Project: Solr
  Issue Type: Improvement
  Components: query parsers
Affects Versions: 4.0-BETA
 Environment: solr-spec 5.0.0.2012.10.09.19.29.59
 solr-impl 5.0-SNAPSHOT 1366361:1396116M - markus - 2012-10-09 19:29:59 
Reporter: Markus Jelsma
 Fix For: 4.1, 5.0

 Attachments: SOLR-3925-trunk-1.patch, SOLR-3925-trunk-2.patch


 Expose Lucene's SpanFirst capability in Solr's extended Dismax query parser. 
 This issue adds the SF-parameter (SpanFirst) and takes a FIELD~DISTANCE^BOOST 
 formatted value.
 For example, sf=title~5^2 will give a boost of 2 if one of the normal 
 clauses, originally generated for automatic phrase queries, is located within 
 five positions from the field's start.
 Unit test is included and all tests pass.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-3925) Expose SpanFirst in eDismax

2012-12-17 Thread Vlado Kurelec (JIRA)

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

Vlado Kurelec edited comment on SOLR-3925 at 12/17/12 2:01 PM:
---

Hi, at first, thanks a lot for this patch.
I've built it on a rev. 1406758 and found following issues:
- edismax query throws an exception when there's no sf parameter
- SpanFirst doesn't process the search term through the query anayzer defined
on that field
- if search term is enclosed in (), they are not striped but passed as part of
the term
p.s. how come it is not included in night build? Is there another way to do
boost by position?

was (Author: celeruk):
Hi, at first, thanks a lot for this patch.
I've built it on a rev. 1406758 and found following issues:
- edismax query throws an exception when there's no sf parameter
- SpanFirst doesn't process the search term through the query anayzer defined
on that field
- if search term is enclosed in (), they are not striped but passed as part of
the term
How come it is not included in night build? Is there another way to do boost by
position?

Expose SpanFirst in eDismax
---

Key: SOLR-3925
URL: https://issues.apache.org/jira/browse/SOLR-3925
Project: Solr
Issue Type: Improvement
Components: query parsers
Affects Versions: 4.0-BETA
Environment: solr-spec 5.0.0.2012.10.09.19.29.59
solr-impl 5.0-SNAPSHOT 1366361:1396116M - markus - 2012-10-09 19:29:59
Reporter: Markus Jelsma
Fix For: 4.1, 5.0

Attachments: SOLR-3925-trunk-1.patch, SOLR-3925-trunk-2.patch

Expose Lucene's SpanFirst capability in Solr's extended Dismax query parser.
This issue adds the SF-parameter (SpanFirst) and takes a FIELD~DISTANCE^BOOST
formatted value.
For example, sf=title~5^2 will give a boost of 2 if one of the normal
clauses, originally generated for automatic phrase queries, is located within
five positions from the field's start.
Unit test is included and all tests pass.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.7.0_09) - Build # 2202 - Failure!

2012-12-17 Thread Policeman Jenkins Server

Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows/2202/
Java: 64bit/jdk1.7.0_09 -XX:+UseParallelGC

1 tests failed.
REGRESSION:  
org.apache.solr.spelling.SpellCheckCollatorTest.testContextSensitiveCollate

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at 
__randomizedtesting.SeedInfo.seed([AAE77DE58B4DA823:A82E76185711F752]:0)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:515)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:482)
at 
org.apache.solr.spelling.SpellCheckCollatorTest.testContextSensitiveCollate(SpellCheckCollatorTest.java:380)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at java.lang.Thread.run(Thread.java:722)
Caused by: java.lang.RuntimeException: REQUEST FAILED:

[jira] [Commented] (SOLR-4143) setRequestHandler - option to not set qt parameter


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

Yonik Seeley commented on SOLR-4143:


bq. I think the right way to go about this would be to have a method that 
will change the URL path but just leave out the query parameter entirely

This seems like the right approach (as opposed to adding more parameters).
Isn't the fix for this entirely on the client side (i.e. if qt starts with 
slash, remove it and set the URL path)?

 setRequestHandler - option to not set qt parameter
 --

 Key: SOLR-4143
 URL: https://issues.apache.org/jira/browse/SOLR-4143
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Affects Versions: 4.0
 Environment: solr-impl4.1-SNAPSHOT 1416639M - ncindex - 
 2012-12-03 12:54:38
Reporter: Shawn Heisey
 Fix For: 4.1, 5.0

 Attachments: SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch, 
 SOLR-4143.patch, SOLR-4143.patch


 The setRequestHandler method does what I expect in one way - it changes the 
 URL path from /select to the String argument.  It is however doing something 
 that I did not expect, which is setting the qt parameter on the query as 
 well.  Here is the code:
 private static final String PING_HANDLER = /admin/ping;
 query.setRequestHandler(PING_HANDLER);
 This is resulting in the following exception being logged in my Solr 3.5.0 
 servers.  I am not including the whole exception, because this issue is for 
 SolrJ 4, not Solr 3.5, and the 3.5 version is working as it was designed.
 {code}
 Dec 3, 2012 4:04:01 PM org.apache.solr.common.SolrException log
 SEVERE: org.apache.solr.common.SolrException: Cannot execute the 
 PingRequestHandler recursively
 at 
 org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:60)
 at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:208)
 {code}
 I believe it would be useful to include an alternate setRequestHandler method 
 that includes a boolean option deciding whether or not to also set the qt 
 parameter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2592) Custom Hashing

2012-12-17 Thread Markus Jelsma (JIRA)


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

Markus Jelsma commented on SOLR-2592:
-

Additional note for anyone: you will also see a similar exception with an older 
SolrJ application:
{code}
java.lang.ClassCastException: java.lang.String cannot be cast to java.util.Map
at org.apache.solr.common.cloud.ClusterState.load(ClusterState.java:291)
at org.apache.solr.common.cloud.ClusterState.load(ClusterState.java:263)
at 
org.apache.solr.common.cloud.ZkStateReader.createClusterStateWatchersAndUpdate(ZkStateReader.java:274)
at 
org.apache.solr.client.solrj.impl.CloudSolrServer.connect(CloudSolrServer.java:142)
at 
org.apache.nutch.indexer.solr.SolrUtils.getCloudServer(SolrUtils.java:107)
at 
org.apache.nutch.indexer.solr.SolrUtils.getSolrServers(SolrUtils.java:65)
at org.apache.nutch.indexer.solr.SolrWriter.open(SolrWriter.java:65)
at 
org.apache.nutch.indexer.IndexerOutputFormat.getRecordWriter(IndexerOutputFormat.java:42)
at 
org.apache.hadoop.mapred.ReduceTask$OldTrackingRecordWriter.init(ReduceTask.java:448)
at 
org.apache.hadoop.mapred.ReduceTask.runOldReducer(ReduceTask.java:490)
at org.apache.hadoop.mapred.ReduceTask.run(ReduceTask.java:420)
at 
org.apache.hadoop.mapred.LocalJobRunner$Job.run(LocalJobRunner.java:260)
{code}

 Custom Hashing
 --

 Key: SOLR-2592
 URL: https://issues.apache.org/jira/browse/SOLR-2592
 Project: Solr
  Issue Type: New Feature
  Components: SolrCloud
Affects Versions: 4.0-ALPHA
Reporter: Noble Paul
Assignee: Yonik Seeley
 Fix For: 4.1

 Attachments: dbq_fix.patch, pluggable_sharding.patch, 
 pluggable_sharding_V2.patch, SOLR-2592_collectionProperties.patch, 
 SOLR-2592_collectionProperties.patch, SOLR-2592.patch, 
 SOLR-2592_progress.patch, SOLR-2592_query_try1.patch, 
 SOLR-2592_r1373086.patch, SOLR-2592_r1384367.patch, SOLR-2592_rev_2.patch, 
 SOLR_2592_solr_4_0_0_BETA_ShardPartitioner.patch


 If the data in a cloud can be partitioned on some criteria (say range, hash, 
 attribute value etc) It will be easy to narrow down the search to a smaller 
 subset of shards and in effect can achieve more efficient search.  

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-4207) Links to lucene in wiki are broken

2012-12-17 Thread Aldo Stracquadanio (JIRA)

Aldo Stracquadanio created SOLR-4207:


 Summary: Links to lucene in wiki are broken
 Key: SOLR-4207
 URL: https://issues.apache.org/jira/browse/SOLR-4207
 Project: Solr
  Issue Type: Bug
  Components: documentation
Reporter: Aldo Stracquadanio


Since 4.0.0 has been released there are all links pointing to the 
lucene.apache.org domain are broken. Some examples:

On the SolrQuerySyntax page selecting a link to any function or to either 
DateField or DateMath will result in a 404.

On the SearchComponent page selecting any link to a specific component in the 
first list wil result in a 404.


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4157) Add more conventional search functionality to the Admin UI

2012-12-17 Thread Ryan McKinley (JIRA)

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

Ryan McKinley commented on SOLR-4157:
-

bq. It'd be really cool to have JSON and XML be formatted in the pane by
default, they're ugly as it stands. But only if it's really, really easy.

What about using something like:

http://google-code-prettify.googlecode.com/svn/trunk/tests/prettify_test.html#xml
http://google-code-prettify.googlecode.com/svn/trunk/tests/prettify_test.html#javascript

Add more conventional search functionality to the Admin UI
--

Key: SOLR-4157
URL: https://issues.apache.org/jira/browse/SOLR-4157
Project: Solr
Issue Type: Improvement
Components: web gui
Reporter: Upayavira
Priority: Minor
Attachments: SOLR-4157.patch

The admin UI has a 'query' pane which allows searching the index. However,
this is currently an 'expert' level feature, as you must specify exact
request parameters and interpret output XML or JSON.
I suggest we add simple versions of each. A simple query pane would give a
more conventional search interface for running queries. A simple results pane
would give HTML formatted results with features to nicely display
hightlighting, explains, etc.
To give an idea of what this might look like, I've attached a rudimentary
patch that gives an HTML option for wt which formats the query results as
(somewhat minimal) HTML.
The challenge will be in producing a search interface that is schema
agnostic, as to be really useful, it should work with any index, and not just
with the fields in the default schema (perhaps Erik Hatcher is right, this
should be backed by the velocityResponseWriter).
Thoughts welcome.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

DocsEnum.freq()

2012-12-17 Thread Shai Erera

Hi

While migrating code to Lucene 4.0, I noticed that I have an assert on a
field that is indexed with DOCS_ONLY that DocsEnum.freq() == 1. This got me
thinking ... why?

If you index w/ DOCS_ONLY, or ask for DocsEnum with FLAG_NONE, why do we
lie to the consumer? Rather, we could just return 0 or -1?

I personally don't mind if we continue to return 1, if there's a real
reason to. I don't think that anyone should call freq() if he asked for
DocsEnum with FLAG_NONE. But if we do keep the current behavior, can we at
least document it?

E.g., something like this patch:

Index: lucene/core/src/java/org/apache/lucene/index/DocsEnum.java
===
--- lucene/core/src/java/org/apache/lucene/index/DocsEnum.java  (revision
1422804)
+++ lucene/core/src/java/org/apache/lucene/index/DocsEnum.java  (working
copy)
@@ -47,10 +47,16 @@
   protected DocsEnum() {
   }

-  /** Returns term frequency in the current document.  Do
-   *  not call this before {@link #nextDoc} is first called,
-   *  nor after {@link #nextDoc} returns NO_MORE_DOCS.
-   **/
+  /**
+   * Returns term frequency in the current document, or 1 if the
+   * {@link DocsEnum} was obtained with {@link #FLAG_NONE}. Do not call
this
+   * before {@link #nextDoc} is first called, nor after {@link #nextDoc}
returns
+   * {@link DocIdSetIterator#NO_MORE_DOCS}.
+   *
+   * p
+   * bNOTE:/b if the {@link DocsEnum} was obtain with {@link
#FLAG_NONE},
+   * this method returns 1.
+   */
   public abstract int freq() throws IOException;

   /** Returns the related attributes. */

Shai

[jira] [Commented] (SOLR-4143) setRequestHandler - option to not set qt parameter

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

Shawn Heisey commented on SOLR-4143:

bq. This seems like the right approach (as opposed to adding more parameters).
Isn't the fix for this entirely on the client side (i.e. if qt starts with
slash, remove it and set the URL path)?

I do like that idea. It would be a lot cleaner than my fix, as it wouldn't
involve any new methods or parameters. A quick mental review doesn't find
anything wrong with it, but my knowledge may not be deep enough. If you also
don't see any potential fallout, I can make a new patch that would just nuke
CommonParams.QT from the final request whenever it starts with slash.

My current fix is also entirely on the client side. This latest version of
setRequestHandler adds qt.pathonly=true as a parameter to the request if you
pass it a true boolean. If that parameter is present when the request is
actually made by implementations of SolrServer, then it is removed, along with
qt, after the request path is set. As far as I can tell, nothing behaves any
differently on the server side in the latest patch version. With earlier
versions, the server side did behave differently, which is bad.

setRequestHandler - option to not set qt parameter
--

Key: SOLR-4143
URL: https://issues.apache.org/jira/browse/SOLR-4143
Project: Solr
Issue Type: Improvement
Components: clients - java
Affects Versions: 4.0
Environment: solr-impl4.1-SNAPSHOT 1416639M - ncindex -
2012-12-03 12:54:38
Reporter: Shawn Heisey
Fix For: 4.1, 5.0

Attachments: SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch,
SOLR-4143.patch, SOLR-4143.patch

The setRequestHandler method does what I expect in one way - it changes the
URL path from /select to the String argument. It is however doing something
that I did not expect, which is setting the qt parameter on the query as
well. Here is the code:
private static final String PING_HANDLER = /admin/ping;
query.setRequestHandler(PING_HANDLER);
This is resulting in the following exception being logged in my Solr 3.5.0
servers. I am not including the whole exception, because this issue is for
SolrJ 4, not Solr 3.5, and the 3.5 version is working as it was designed.
{code}
Dec 3, 2012 4:04:01 PM org.apache.solr.common.SolrException log
SEVERE: org.apache.solr.common.SolrException: Cannot execute the
PingRequestHandler recursively
at
org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:60)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:208)
{code}
I believe it would be useful to include an alternate setRequestHandler method
that includes a boolean option deciding whether or not to also set the qt
parameter.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: DocsEnum.freq()

2012-12-17 Thread Robert Muir

On Mon, Dec 17, 2012 at 11:24 AM, Shai Erera ser...@gmail.com wrote:
 Hi

 While migrating code to Lucene 4.0, I noticed that I have an assert on a
 field that is indexed with DOCS_ONLY that DocsEnum.freq() == 1. This got me
 thinking ... why?

1 is pretty intuitive i think. i think of omitting freqs for things
like super-short fields where the frequency is expected to be 1
anyway.

I see your point about lying, but if we change this, we have to
change all code using it like TermQuery to not call freqs if they are
unavailable: i think this makes the apis pretty difficult to use.


 But if we do keep the current behavior, can we at least
 document it?

 E.g., something like this patch:


+1 to the patch.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4143) setRequestHandler - option to not set qt parameter

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

Shawn Heisey commented on SOLR-4143:

bq. This seems like the right approach (as opposed to adding more parameters).
Isn't the fix for this entirely on the client side (i.e. if qt starts with
slash, remove it and set the URL path)?

setRequestHandler - option to not set qt parameter
--

Attachments: SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch,
SOLR-4143.patch, SOLR-4143.patch

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4143) setRequestHandler - option to not set qt parameter

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

Shawn Heisey commented on SOLR-4143:

bq. This seems like the right approach (as opposed to adding more parameters).
Isn't the fix for this entirely on the client side (i.e. if qt starts with
slash, remove it and set the URL path)?

setRequestHandler - option to not set qt parameter
--

Attachments: SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch,
SOLR-4143.patch, SOLR-4143.patch

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4258) Incremental Field Updates through Stacked Segments

2012-12-17 Thread Sivan Yogev (JIRA)


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

Sivan Yogev updated LUCENE-4258:


Attachment: LUCENE-4258.r1423010.patch

New patch, concurrency bugs fixed. All tests pass.

 Incremental Field Updates through Stacked Segments
 --

 Key: LUCENE-4258
 URL: https://issues.apache.org/jira/browse/LUCENE-4258
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/index
Reporter: Sivan Yogev
 Attachments: IncrementalFieldUpdates.odp, 
 LUCENE-4258-API-changes.patch, LUCENE-4258.r1410593.patch, 
 LUCENE-4258.r1412262.patch, LUCENE-4258.r1416438.patch, 
 LUCENE-4258.r1416617.patch, LUCENE-4258.r1422495.patch, 
 LUCENE-4258.r1423010.patch

   Original Estimate: 2,520h
  Remaining Estimate: 2,520h

 Shai and I would like to start working on the proposal to Incremental Field 
 Updates outlined here (http://markmail.org/message/zhrdxxpfk6qvdaex).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-4110) Configurable Content-Type headers for PHPResponseWriters and PHPSerializedResponseWriter

2012-12-17 Thread Dominik Siebel (JIRA)


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

Dominik Siebel updated SOLR-4110:
-

Attachment: SOLR-4110_trunk.patch
SOLR-4110_branch_4x.patch

Patch to make Content-Type header configurable in PHPResponseWriters.

Had to add two patches for trunk and branch_4x separately, due to changes in 
trunk (missing @Overrides).

 Configurable Content-Type headers for PHPResponseWriters and 
 PHPSerializedResponseWriter
 

 Key: SOLR-4110
 URL: https://issues.apache.org/jira/browse/SOLR-4110
 Project: Solr
  Issue Type: Improvement
  Components: Response Writers
Affects Versions: 4.0
Reporter: Dominik Siebel
Assignee: Mark Miller
Priority: Minor
  Labels: 4.0.1_Candidate
 Fix For: 4.1, 5.0

 Attachments: SOLR-4110_branch_4x.patch, SOLR-4110.patch, 
 SOLR-4110_trunk.patch


 The *PHPResponseWriter* and *PHPSerializedResponseWriter* currently send a 
 hard coded Content-Type header of _text/plain; charset=UTF-8_ although there 
 are constants defining _text/x-php;charset=UTF-8_ and 
 _text/x-php-serialized;charset=UTF-8_ which remain unused. This makes content 
 type guessing on the client side quite complicated.
 I already created a patch (from the branch_4x github branch) to use the 
 respective constants and also added the possibility to configure the 
 Content-Type header via solrconfig.xml (like in JSONResponseWriter).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-4110) Configurable Content-Type headers for PHPResponseWriters and PHPSerializedResponseWriter

2012-12-17 Thread Dominik Siebel (JIRA)


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

Dominik Siebel updated SOLR-4110:
-

Attachment: SOLR-4110_trunk.patch
SOLR-4110_branch_4x.patch

Patch to make Content-Type header configurable in PHPResponseWriters.

Had to add two patches for trunk and branch_4x separately, due to changes in 
trunk (missing @Overrides).

 Configurable Content-Type headers for PHPResponseWriters and 
 PHPSerializedResponseWriter
 

 Key: SOLR-4110
 URL: https://issues.apache.org/jira/browse/SOLR-4110
 Project: Solr
  Issue Type: Improvement
  Components: Response Writers
Affects Versions: 4.0
Reporter: Dominik Siebel
Assignee: Mark Miller
Priority: Minor
  Labels: 4.0.1_Candidate
 Fix For: 4.1, 5.0

 Attachments: SOLR-4110_branch_4x.patch, SOLR-4110.patch, 
 SOLR-4110_trunk.patch


 The *PHPResponseWriter* and *PHPSerializedResponseWriter* currently send a 
 hard coded Content-Type header of _text/plain; charset=UTF-8_ although there 
 are constants defining _text/x-php;charset=UTF-8_ and 
 _text/x-php-serialized;charset=UTF-8_ which remain unused. This makes content 
 type guessing on the client side quite complicated.
 I already created a patch (from the branch_4x github branch) to use the 
 respective constants and also added the possibility to configure the 
 Content-Type header via solrconfig.xml (like in JSONResponseWriter).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: DocsEnum.freq()

2012-12-17 Thread Michael McCandless

I think the FLAG_NONE (I don't need/want freqs when reading the
index) and the DOCS_ONLY (Do not index freqs) are two different
cases?

I think for DOCS_ONLY it makes sense that we lie (say freq=1 when we
don't know): lots of places would otherwise have to be special cased
for when they consume DOCS_ONLY vs DOCS_AND_POSITIONS.

But, for FLAG_NONE, when the caller passes this it means they have no
intention of using/calling freq() right?  Eg
MultiTermQueryWrapperFilter would pass this.  For that case I'm not
sure we should promise / require that codecs return 1 always?  EG what
if the index does has freqs?  I think in that case the codec shouldn't
be required to go out of its way and return 1?  I'm also not sure that
all codecs return 1 today if the fields was indexed with DOCS_ONLY ...

Mike McCandless

http://blog.mikemccandless.com

On Mon, Dec 17, 2012 at 11:24 AM, Shai Erera ser...@gmail.com wrote:
 Hi

 While migrating code to Lucene 4.0, I noticed that I have an assert on a
 field that is indexed with DOCS_ONLY that DocsEnum.freq() == 1. This got me
 thinking ... why?

 If you index w/ DOCS_ONLY, or ask for DocsEnum with FLAG_NONE, why do we
 lie to the consumer? Rather, we could just return 0 or -1?

 I personally don't mind if we continue to return 1, if there's a real reason
 to. I don't think that anyone should call freq() if he asked for DocsEnum
 with FLAG_NONE. But if we do keep the current behavior, can we at least
 document it?

 E.g., something like this patch:

 Index: lucene/core/src/java/org/apache/lucene/index/DocsEnum.java
 ===
 --- lucene/core/src/java/org/apache/lucene/index/DocsEnum.java  (revision
 1422804)
 +++ lucene/core/src/java/org/apache/lucene/index/DocsEnum.java  (working
 copy)
 @@ -47,10 +47,16 @@
protected DocsEnum() {
}

 -  /** Returns term frequency in the current document.  Do
 -   *  not call this before {@link #nextDoc} is first called,
 -   *  nor after {@link #nextDoc} returns NO_MORE_DOCS.
 -   **/
 +  /**
 +   * Returns term frequency in the current document, or 1 if the
 +   * {@link DocsEnum} was obtained with {@link #FLAG_NONE}. Do not call
 this
 +   * before {@link #nextDoc} is first called, nor after {@link #nextDoc}
 returns
 +   * {@link DocIdSetIterator#NO_MORE_DOCS}.
 +   *
 +   * p
 +   * bNOTE:/b if the {@link DocsEnum} was obtain with {@link
 #FLAG_NONE},
 +   * this method returns 1.
 +   */
public abstract int freq() throws IOException;

/** Returns the related attributes. */

 Shai

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4111) Context-Sensitive SpellCheck Collation is not really being tested on IndexBasedSpellChecker


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

Commit Tag Bot commented on SOLR-4111:
--

[trunk commit] James Dyer
http://svn.apache.org/viewvc?view=revisionrevision=1423067

SOLR-4111: fix occasional failures


 Context-Sensitive SpellCheck Collation is not really being tested on 
 IndexBasedSpellChecker
 ---

 Key: SOLR-4111
 URL: https://issues.apache.org/jira/browse/SOLR-4111
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Tomás Fernández Löbbe
Assignee: James Dyer
Priority: Trivial
 Fix For: 4.1, 5.0

 Attachments: SOLR-4111.patch


 Looks like a typo in the code. 
 SpellCheckCollatorTest.testContextSensitiveCollate() has:
 {code:java}
 // DirectSolrSpellChecker   IndexBasedSpellChecker
 String[] dictionary = {direct,default_teststop };
 for(int i=0 ; i1 ; i++) {
 ... test stuff using dictionary[i]...
 }
 {code}
 where it should be
 {code:java}
 // DirectSolrSpellChecker   IndexBasedSpellChecker
 String[] dictionary = {direct,default_teststop };
 for(int i=0 ; i=1 ; i++) {
 ... test stuff using dictionary[i]...
 }
 {code}
 due to this, the tests are not being run with a IndexBasedSpellChecker.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [Solr Wiki] Update of SolrCloud by EricPugh


On Dec 17, 2012, at 1:02 PM, Apache Wiki wikidi...@apache.org wrote:

 Should I say this is a Solr 4.1 change? 

I really think we need to version the SolrCloud page.

I think we need to version our docs in general, but the SolrCloud page already 
needs to be broken up I think. I'm just waiting until we start on a better docs 
route. But until then, it seems to crazy to litter it with if(thisversion) then.

I think we should make a 4.0 version and then copy it and tweak to a 4.1 
version.

There are tradeoffs to this, but in my opinion its the only way to keep things 
sane.

- Mark
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [Solr Wiki] Update of SolrCloud by EricPugh

2012-12-17 Thread Eric Pugh

I agree with the SolrCloud page specifically.  SolrCloud has so many changes 
between 4.0 and 4.1.  I am guessing that by the time we get to 4.2 or 4.3 that 
it will all be much more stable and then going back to marking it with a 
revision will work like the other wiki pages have.


On Dec 17, 2012, at 1:46 PM, Mark Miller wrote:

 
 On Dec 17, 2012, at 1:02 PM, Apache Wiki wikidi...@apache.org wrote:
 
 Should I say this is a Solr 4.1 change? 
 
 I really think we need to version the SolrCloud page.
 
 I think we need to version our docs in general, but the SolrCloud page 
 already needs to be broken up I think. I'm just waiting until we start on a 
 better docs route. But until then, it seems to crazy to litter it with 
 if(thisversion) then.
 
 I think we should make a 4.0 version and then copy it and tweak to a 4.1 
 version.
 
 There are tradeoffs to this, but in my opinion its the only way to keep 
 things sane.
 
 - Mark
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 

-
Eric Pugh | Principal | OpenSource Connections, LLC | 434.466.1467 | 
http://www.opensourceconnections.com
Co-Author: Apache Solr 3 Enterprise Search Server available from 
http://www.packtpub.com/apache-solr-3-enterprise-search-server/book
This e-mail and all contents, including attachments, is considered to be 
Company Confidential unless explicitly stated otherwise, regardless of whether 
attachments are marked as such.














-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4111) Context-Sensitive SpellCheck Collation is not really being tested on IndexBasedSpellChecker


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

Commit Tag Bot commented on SOLR-4111:
--

[branch_4x commit] James Dyer
http://svn.apache.org/viewvc?view=revisionrevision=1423093

SOLR-4111: fix occasional failures


 Context-Sensitive SpellCheck Collation is not really being tested on 
 IndexBasedSpellChecker
 ---

 Key: SOLR-4111
 URL: https://issues.apache.org/jira/browse/SOLR-4111
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Tomás Fernández Löbbe
Assignee: James Dyer
Priority: Trivial
 Fix For: 4.1, 5.0

 Attachments: SOLR-4111.patch


 Looks like a typo in the code. 
 SpellCheckCollatorTest.testContextSensitiveCollate() has:
 {code:java}
 // DirectSolrSpellChecker   IndexBasedSpellChecker
 String[] dictionary = {direct,default_teststop };
 for(int i=0 ; i1 ; i++) {
 ... test stuff using dictionary[i]...
 }
 {code}
 where it should be
 {code:java}
 // DirectSolrSpellChecker   IndexBasedSpellChecker
 String[] dictionary = {direct,default_teststop };
 for(int i=0 ; i=1 ; i++) {
 ... test stuff using dictionary[i]...
 }
 {code}
 due to this, the tests are not being run with a IndexBasedSpellChecker.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4207) Links to lucene in wiki are broken

2012-12-17 Thread Steven Rowe (JIRA)


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

Steven Rowe commented on SOLR-4207:
---

Hi Aldo,

The wiki can be edited by anybody - when you see broken links like this, please 
go ahead and fix them yourself.

Until recently, the Solr API docs hosted on the website were not versioned - 
they were changed to reflect the latest release.  Now that they are versioned, 
links will need to be repaired to go to a specific version. 

For example, the DateField link on the SolrQuerySyntax page is currently

{noformat}
http://lucene.apache.org/solr/api/org/apache/solr/schema/DateField.html
{noformat}

but should be 

{noformat}
http://lucene.apache.org/solr/4_0_0/solr-core/org/apache/solr/schema/DateField.html
{noformat}

Just replace {{api/}} with {{4_0_0/solr-core/}}.  See 
http://lucene.apache.org/solr/4_0_0/ for other modules' base URLs.

 Links to lucene in wiki are broken
 --

 Key: SOLR-4207
 URL: https://issues.apache.org/jira/browse/SOLR-4207
 Project: Solr
  Issue Type: Bug
  Components: documentation
Reporter: Aldo Stracquadanio
  Labels: documentation

 Since 4.0.0 has been released there are all links pointing to the 
 lucene.apache.org domain are broken. Some examples:
 On the SolrQuerySyntax page selecting a link to any function or to either 
 DateField or DateMath will result in a 404.
 On the SearchComponent page selecting any link to a specific component in the 
 first list wil result in a 404.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-2894) Implement distributed pivot faceting

2012-12-17 Thread Chris Russell (JIRA)


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

Chris Russell commented on SOLR-2894:
-

Thanks Shahar.

In regard to #1, there is (count) and there are tests that cover that in 
DistributedFacetPivotTest.java.  Are you sure the patch applied correctly to 
your version of solr?

In regard to #2, that is correct.  Does per field sorting work with 
non-distributed pivots?  I guess it was never implemented by the original 
author.

 Implement distributed pivot faceting
 

 Key: SOLR-2894
 URL: https://issues.apache.org/jira/browse/SOLR-2894
 Project: Solr
  Issue Type: Improvement
Reporter: Erik Hatcher
 Fix For: 4.1

 Attachments: SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, 
 SOLR-2894-reworked.patch


 Following up on SOLR-792, pivot faceting currently only supports 
 undistributed mode.  Distributed pivot faceting needs to be implemented.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4207) Links to lucene in wiki are broken


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

Yonik Seeley commented on SOLR-4207:


I brought this up a while back:
http://lucene.472066.n3.nabble.com/links-to-javadoc-are-broken-td4020294.html

This isn't due to a lack of versioning (there's a redirect from api currently), 
but that the redirect no longer works because of a change of the structure of 
the javadocs (inserting a solr-core in the middle of the path).  That 
redirect needs to be fixed.  If I knew where it was, I'd do it.


 Links to lucene in wiki are broken
 --

 Key: SOLR-4207
 URL: https://issues.apache.org/jira/browse/SOLR-4207
 Project: Solr
  Issue Type: Bug
  Components: documentation
Reporter: Aldo Stracquadanio
  Labels: documentation

 Since 4.0.0 has been released there are all links pointing to the 
 lucene.apache.org domain are broken. Some examples:
 On the SolrQuerySyntax page selecting a link to any function or to either 
 DateField or DateMath will result in a 404.
 On the SearchComponent page selecting any link to a specific component in the 
 first list wil result in a 404.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-4207) Links to lucene in wiki are broken


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

Yonik Seeley edited comment on SOLR-4207 at 12/17/12 8:01 PM:
--

I brought this up a while back:
http://lucene.472066.n3.nabble.com/links-to-javadoc-are-broken-td4020294.html

This isn't due to a lack of versioning (there's a redirect from api currently), 
but that the redirect no longer works because of a change of the structure of 
the javadocs (inserting a solr-core in the middle of the path).  That 
redirect needs to be fixed.  If I knew where it was, I'd do it.

edit: I just found it (I hadn't realized it was under the cms).  I'll try a fix.

  was (Author: ysee...@gmail.com):
I brought this up a while back:
http://lucene.472066.n3.nabble.com/links-to-javadoc-are-broken-td4020294.html

This isn't due to a lack of versioning (there's a redirect from api currently), 
but that the redirect no longer works because of a change of the structure of 
the javadocs (inserting a solr-core in the middle of the path).  That 
redirect needs to be fixed.  If I knew where it was, I'd do it.

  
 Links to lucene in wiki are broken
 --

 Key: SOLR-4207
 URL: https://issues.apache.org/jira/browse/SOLR-4207
 Project: Solr
  Issue Type: Bug
  Components: documentation
Reporter: Aldo Stracquadanio
  Labels: documentation

 Since 4.0.0 has been released there are all links pointing to the 
 lucene.apache.org domain are broken. Some examples:
 On the SolrQuerySyntax page selecting a link to any function or to either 
 DateField or DateMath will result in a 404.
 On the SearchComponent page selecting any link to a specific component in the 
 first list wil result in a 404.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-4143) setRequestHandler - option to not set qt parameter


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

Shawn Heisey updated SOLR-4143:
---

Attachment: SOLR-4143-alternate-testsfailing.patch

Alternate patch as discussed (against branch_4x) with a test.  This one no 
longer does extensive code reformatting.  The changes turned up a problem in 
BasicDistributedZkTest, where qt was being used for additional parameters:

params.set(qt, /admin/mbeans?key=updateHandlerstats=true);

I fixed that in the patch by assigning the parameters separately.

There is still one test failing for sure (actually failing to fail) with this 
alternate patch, and I'm not sure how to fix it.  I am doing a run where I 
force this test to pass, to see if there are any other failures.

Test that's failing:
-Dtestcase=TestRemoteStreaming -Dtests.method=testQtUpdateFails

Is there a way to examine the response to determine that it did not update any 
documents?  If the qt=/update were to successfully override the /select, would 
numFound be in the response?  I had the test add echoParams=all and print out 
the response as a string:
{noformat}
{responseHeader={status=0,QTime=5,handler=org.apache.solr.handler.StandardRequestHandler,params={stream.body=deletequery*:*/query/delete,echoParams=all,q=*:*,echoHandler=true,wt=javabin,version=2}},response={numFound=1,start=0,docs=[SolrDocument{id=1234,
 range_facet_si=1234, range_facet_l=[1234], range_facet_sl=[1234], 
timestamp=Tue Dec 18 06:01:24 KOST 2012, multiDefault=[muLti-Default], 
intDefault=42}]}}
{noformat}

 setRequestHandler - option to not set qt parameter
 --

 Key: SOLR-4143
 URL: https://issues.apache.org/jira/browse/SOLR-4143
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Affects Versions: 4.0
 Environment: solr-impl4.1-SNAPSHOT 1416639M - ncindex - 
 2012-12-03 12:54:38
Reporter: Shawn Heisey
 Fix For: 4.1, 5.0

 Attachments: SOLR-4143-alternate-testsfailing.patch, SOLR-4143.patch, 
 SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch


 The setRequestHandler method does what I expect in one way - it changes the 
 URL path from /select to the String argument.  It is however doing something 
 that I did not expect, which is setting the qt parameter on the query as 
 well.  Here is the code:
 private static final String PING_HANDLER = /admin/ping;
 query.setRequestHandler(PING_HANDLER);
 This is resulting in the following exception being logged in my Solr 3.5.0 
 servers.  I am not including the whole exception, because this issue is for 
 SolrJ 4, not Solr 3.5, and the 3.5 version is working as it was designed.
 {code}
 Dec 3, 2012 4:04:01 PM org.apache.solr.common.SolrException log
 SEVERE: org.apache.solr.common.SolrException: Cannot execute the 
 PingRequestHandler recursively
 at 
 org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:60)
 at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:208)
 {code}
 I believe it would be useful to include an alternate setRequestHandler method 
 that includes a boolean option deciding whether or not to also set the qt 
 parameter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4143) setRequestHandler - option to not set qt parameter


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

Shawn Heisey commented on SOLR-4143:


If the alternate patch is fixed and deemed the right way to go, this issue 
should be renamed:

setRequestHandler - remove qt parameter from final request when it starts with 
slash


 setRequestHandler - option to not set qt parameter
 --

 Key: SOLR-4143
 URL: https://issues.apache.org/jira/browse/SOLR-4143
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Affects Versions: 4.0
 Environment: solr-impl4.1-SNAPSHOT 1416639M - ncindex - 
 2012-12-03 12:54:38
Reporter: Shawn Heisey
 Fix For: 4.1, 5.0

 Attachments: SOLR-4143-alternate-testsfailing.patch, SOLR-4143.patch, 
 SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch


 The setRequestHandler method does what I expect in one way - it changes the 
 URL path from /select to the String argument.  It is however doing something 
 that I did not expect, which is setting the qt parameter on the query as 
 well.  Here is the code:
 private static final String PING_HANDLER = /admin/ping;
 query.setRequestHandler(PING_HANDLER);
 This is resulting in the following exception being logged in my Solr 3.5.0 
 servers.  I am not including the whole exception, because this issue is for 
 SolrJ 4, not Solr 3.5, and the 3.5 version is working as it was designed.
 {code}
 Dec 3, 2012 4:04:01 PM org.apache.solr.common.SolrException log
 SEVERE: org.apache.solr.common.SolrException: Cannot execute the 
 PingRequestHandler recursively
 at 
 org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:60)
 at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:208)
 {code}
 I believe it would be useful to include an alternate setRequestHandler method 
 that includes a boolean option deciding whether or not to also set the qt 
 parameter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4110) Configurable Content-Type headers for PHPResponseWriters and PHPSerializedResponseWriter


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

Commit Tag Bot commented on SOLR-4110:
--

[trunk commit] Mark Robert Miller
http://svn.apache.org/viewvc?view=revisionrevision=1423121

SOLR-4110: Configurable Content-Type headers for PHPResponseWriters and 
PHPSerializedResponseWriter.


 Configurable Content-Type headers for PHPResponseWriters and 
 PHPSerializedResponseWriter
 

 Key: SOLR-4110
 URL: https://issues.apache.org/jira/browse/SOLR-4110
 Project: Solr
  Issue Type: Improvement
  Components: Response Writers
Affects Versions: 4.0
Reporter: Dominik Siebel
Assignee: Mark Miller
Priority: Minor
  Labels: 4.0.1_Candidate
 Fix For: 4.1, 5.0

 Attachments: SOLR-4110_branch_4x.patch, SOLR-4110.patch, 
 SOLR-4110_trunk.patch


 The *PHPResponseWriter* and *PHPSerializedResponseWriter* currently send a 
 hard coded Content-Type header of _text/plain; charset=UTF-8_ although there 
 are constants defining _text/x-php;charset=UTF-8_ and 
 _text/x-php-serialized;charset=UTF-8_ which remain unused. This makes content 
 type guessing on the client side quite complicated.
 I already created a patch (from the branch_4x github branch) to use the 
 respective constants and also added the possibility to configure the 
 Content-Type header via solrconfig.xml (like in JSONResponseWriter).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4110) Configurable Content-Type headers for PHPResponseWriters and PHPSerializedResponseWriter


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

Commit Tag Bot commented on SOLR-4110:
--

[branch_4x commit] Mark Robert Miller
http://svn.apache.org/viewvc?view=revisionrevision=1423123

SOLR-4110: Configurable Content-Type headers for PHPResponseWriters and 
PHPSerializedResponseWriter.


 Configurable Content-Type headers for PHPResponseWriters and 
 PHPSerializedResponseWriter
 

 Key: SOLR-4110
 URL: https://issues.apache.org/jira/browse/SOLR-4110
 Project: Solr
  Issue Type: Improvement
  Components: Response Writers
Affects Versions: 4.0
Reporter: Dominik Siebel
Assignee: Mark Miller
Priority: Minor
  Labels: 4.0.1_Candidate
 Fix For: 4.1, 5.0

 Attachments: SOLR-4110_branch_4x.patch, SOLR-4110.patch, 
 SOLR-4110_trunk.patch


 The *PHPResponseWriter* and *PHPSerializedResponseWriter* currently send a 
 hard coded Content-Type header of _text/plain; charset=UTF-8_ although there 
 are constants defining _text/x-php;charset=UTF-8_ and 
 _text/x-php-serialized;charset=UTF-8_ which remain unused. This makes content 
 type guessing on the client side quite complicated.
 I already created a patch (from the branch_4x github branch) to use the 
 respective constants and also added the possibility to configure the 
 Content-Type header via solrconfig.xml (like in JSONResponseWriter).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4205) Clover runs on ASF Jenkins idle dead without a test or any thread running in main() loop waiting for file descriptor


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

Dawid Weiss commented on SOLR-4205:
---

There is definitely a bug -- something I don't fully comprehend at the moment. 
It seems it may be related to running in very low-memory conditions (permgen 
exhausted, memory exhausted). I'll keep digging but I have some urgent stuff to 
do -- can we increase permgen limits, at least temporarily, on nightlies and 
clover builds?

 Clover runs on ASF Jenkins idle dead without a test or any thread running in 
 main() loop waiting for file descriptor
 

 Key: SOLR-4205
 URL: https://issues.apache.org/jira/browse/SOLR-4205
 Project: Solr
  Issue Type: Bug
  Components: Tests
 Environment: FreeBSD Jenkins
Reporter: Uwe Schindler
Assignee: Dawid Weiss

 I had to kill ASF Jenkins Clover builds two times after several 10 hours of 
 inactivity in a random Solr test. I requested a stack trace before killing 
 the only running JVM (clover runs with one JVM only, because clover does not 
 like multiple processes writing the same clover metrics file).
 In both cases (4.x and trunk) the stack trace was looking identical after 
 sending kill -3...
 https://builds.apache.org/job/Lucene-Solr-Clover-trunk/76/consoleFull 
 (yesterday):
 {noformat}
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:01:00, stalled for 28447s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:02:00, stalled for 28507s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:03:00, stalled for 28567s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] JVM J0: stdout was not empty, see: 
 /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Clover-trunk/solr/build/solr-core/test/temp/junit4-J0-20121216_044733_583.sysout
 [junit4:junit4]  JVM J0: stdout (verbatim) 
 [junit4:junit4] 2012-12-16 13:03:49
 [junit4:junit4] Full thread dump OpenJDK 64-Bit Server VM (20.0-b12 mixed 
 mode):
 [junit4:junit4] 
 [junit4:junit4] searcherExecutor-2577-thread-1 prio=5 
 tid=0x00085eb67000 nid=0x61c105b waiting on condition [0x70b0d000]
 [junit4:junit4]java.lang.Thread.State: WAITING (parking)
 [junit4:junit4]   at sun.misc.Unsafe.park(Native Method)
 [junit4:junit4]   - parking to wait for  0x0008178c9c40 (a 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 [junit4:junit4]   at 
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 [junit4:junit4]   at 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 [junit4:junit4]   at 
 java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:386)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 [junit4:junit4]   at java.lang.Thread.run(Thread.java:679)
 [junit4:junit4] 
 [junit4:junit4] RMI TCP Accept-0 daemon prio=5 tid=0x000840ce2800 
 nid=0x61c0aa2 runnable [0x79496000]
 [junit4:junit4]java.lang.Thread.State: RUNNABLE
 [junit4:junit4]   at java.net.PlainSocketImpl.socketAccept(Native Method)
 [junit4:junit4]   at 
 java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:375)
 [junit4:junit4]   at 
 java.net.ServerSocket.implAccept(ServerSocket.java:470)
 [junit4:junit4]   at java.net.ServerSocket.accept(ServerSocket.java:438)
 [junit4:junit4]   at 
 sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:387)
 [junit4:junit4]   at 
 sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:359)
 [junit4:junit4]   at java.lang.Thread.run(Thread.java:679)
 [junit4:junit4] 
 [junit4:junit4] RMI Scheduler(0) daemon prio=5 tid=0x000840ce1000 
 nid=0x61c0969 waiting on condition [0x70f11000]
 [junit4:junit4]java.lang.Thread.State: WAITING (parking)
 [junit4:junit4]   at sun.misc.Unsafe.park(Native Method)
 [junit4:junit4]   - parking to wait for  0x000814f12f88 (a 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 [junit4:junit4]   at 
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 [junit4:junit4]   at

[jira] [Commented] (SOLR-4205) Clover runs on ASF Jenkins idle dead without a test or any thread running in main() loop waiting for file descriptor


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

Uwe Schindler commented on SOLR-4205:
-

I will look into this!

 Clover runs on ASF Jenkins idle dead without a test or any thread running in 
 main() loop waiting for file descriptor
 

 Key: SOLR-4205
 URL: https://issues.apache.org/jira/browse/SOLR-4205
 Project: Solr
  Issue Type: Bug
  Components: Tests
 Environment: FreeBSD Jenkins
Reporter: Uwe Schindler
Assignee: Dawid Weiss

 I had to kill ASF Jenkins Clover builds two times after several 10 hours of 
 inactivity in a random Solr test. I requested a stack trace before killing 
 the only running JVM (clover runs with one JVM only, because clover does not 
 like multiple processes writing the same clover metrics file).
 In both cases (4.x and trunk) the stack trace was looking identical after 
 sending kill -3...
 https://builds.apache.org/job/Lucene-Solr-Clover-trunk/76/consoleFull 
 (yesterday):
 {noformat}
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:01:00, stalled for 28447s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:02:00, stalled for 28507s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:03:00, stalled for 28567s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] JVM J0: stdout was not empty, see: 
 /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Clover-trunk/solr/build/solr-core/test/temp/junit4-J0-20121216_044733_583.sysout
 [junit4:junit4]  JVM J0: stdout (verbatim) 
 [junit4:junit4] 2012-12-16 13:03:49
 [junit4:junit4] Full thread dump OpenJDK 64-Bit Server VM (20.0-b12 mixed 
 mode):
 [junit4:junit4] 
 [junit4:junit4] searcherExecutor-2577-thread-1 prio=5 
 tid=0x00085eb67000 nid=0x61c105b waiting on condition [0x70b0d000]
 [junit4:junit4]java.lang.Thread.State: WAITING (parking)
 [junit4:junit4]   at sun.misc.Unsafe.park(Native Method)
 [junit4:junit4]   - parking to wait for  0x0008178c9c40 (a 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 [junit4:junit4]   at 
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 [junit4:junit4]   at 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 [junit4:junit4]   at 
 java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:386)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 [junit4:junit4]   at java.lang.Thread.run(Thread.java:679)
 [junit4:junit4] 
 [junit4:junit4] RMI TCP Accept-0 daemon prio=5 tid=0x000840ce2800 
 nid=0x61c0aa2 runnable [0x79496000]
 [junit4:junit4]java.lang.Thread.State: RUNNABLE
 [junit4:junit4]   at java.net.PlainSocketImpl.socketAccept(Native Method)
 [junit4:junit4]   at 
 java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:375)
 [junit4:junit4]   at 
 java.net.ServerSocket.implAccept(ServerSocket.java:470)
 [junit4:junit4]   at java.net.ServerSocket.accept(ServerSocket.java:438)
 [junit4:junit4]   at 
 sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:387)
 [junit4:junit4]   at 
 sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:359)
 [junit4:junit4]   at java.lang.Thread.run(Thread.java:679)
 [junit4:junit4] 
 [junit4:junit4] RMI Scheduler(0) daemon prio=5 tid=0x000840ce1000 
 nid=0x61c0969 waiting on condition [0x70f11000]
 [junit4:junit4]java.lang.Thread.State: WAITING (parking)
 [junit4:junit4]   at sun.misc.Unsafe.park(Native Method)
 [junit4:junit4]   - parking to wait for  0x000814f12f88 (a 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 [junit4:junit4]   at 
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 [junit4:junit4]   at 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 [junit4:junit4]   at 
 java.util.concurrent.DelayQueue.take(DelayQueue.java:189)
 [junit4:junit4]   at 
 java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:688)
 [junit4:junit4]   at

[jira] [Updated] (SOLR-4143) setRequestHandler - option to not set qt parameter


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

Shawn Heisey updated SOLR-4143:
---

Attachment: SOLR-4143-alternate.patch

From what I can tell, a response to an update request will be missing the 
entire results section.  Looking at QueryResponse.java, when that is missing, 
getResults() will return null.  I believe I have a fully functioning patch now.

 setRequestHandler - option to not set qt parameter
 --

 Key: SOLR-4143
 URL: https://issues.apache.org/jira/browse/SOLR-4143
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Affects Versions: 4.0
 Environment: solr-impl4.1-SNAPSHOT 1416639M - ncindex - 
 2012-12-03 12:54:38
Reporter: Shawn Heisey
 Fix For: 4.1, 5.0

 Attachments: SOLR-4143-alternate.patch, 
 SOLR-4143-alternate-testsfailing.patch, SOLR-4143.patch, SOLR-4143.patch, 
 SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch


 The setRequestHandler method does what I expect in one way - it changes the 
 URL path from /select to the String argument.  It is however doing something 
 that I did not expect, which is setting the qt parameter on the query as 
 well.  Here is the code:
 private static final String PING_HANDLER = /admin/ping;
 query.setRequestHandler(PING_HANDLER);
 This is resulting in the following exception being logged in my Solr 3.5.0 
 servers.  I am not including the whole exception, because this issue is for 
 SolrJ 4, not Solr 3.5, and the 3.5 version is working as it was designed.
 {code}
 Dec 3, 2012 4:04:01 PM org.apache.solr.common.SolrException log
 SEVERE: org.apache.solr.common.SolrException: Cannot execute the 
 PingRequestHandler recursively
 at 
 org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:60)
 at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:208)
 {code}
 I believe it would be useful to include an alternate setRequestHandler method 
 that includes a boolean option deciding whether or not to also set the qt 
 parameter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: DocsEnum.freq()

2012-12-17 Thread Shai Erera

How do these two go together?

I think for DOCS_ONLY it makes sense that we lie (say freq=1 when we
 don't know): lots of places would otherwise have to be special cased
 for when they consume DOCS_ONLY vs DOCS_AND_POSITIONS.


and

I'm also not sure that
 all codecs return 1 today if the fields was indexed with DOCS_ONLY ...


 That just makes it even worse right? I.e., we have code today that relies
no that behavior, but we're not sure it works w/ all Codecs?

Remember that DocIdSetIterator.nextDoc() was loosely specified? It was very
hard to write a decent DISI consumer. Sometimes calling nextDoc() returned
MAX_VAL, sometimes -1, sometimes who knows. When we hardened the spec, it
actually made consumers' life easier, I think?

It's ok if we say that for DOCS_ONLY you have to return 1. That's even
99.9% of the time the correct value to return (unless someone adds e.g. the
same StringField twice to the document).

And it's also ok to say that if you passed FLAG_NONE, freq()'s value is
unspecified. I think it would be wrong to lie here .. not sure if the
consumer always knows how DocsEnum was requested. Not sure if this happens
in real life though (consuming a DocsEnum that you didn't obtain yourself),
so I'm willing to ignore that case.

These two together sound like a reasonable spec to me?

Shai


On Mon, Dec 17, 2012 at 7:16 PM, Michael McCandless 
luc...@mikemccandless.com wrote:

 I think the FLAG_NONE (I don't need/want freqs when reading the
 index) and the DOCS_ONLY (Do not index freqs) are two different
 cases?

 I think for DOCS_ONLY it makes sense that we lie (say freq=1 when we
 don't know): lots of places would otherwise have to be special cased
 for when they consume DOCS_ONLY vs DOCS_AND_POSITIONS.

 But, for FLAG_NONE, when the caller passes this it means they have no
 intention of using/calling freq() right?  Eg
 MultiTermQueryWrapperFilter would pass this.  For that case I'm not
 sure we should promise / require that codecs return 1 always?  EG what
 if the index does has freqs?  I think in that case the codec shouldn't
 be required to go out of its way and return 1?  I'm also not sure that
 all codecs return 1 today if the fields was indexed with DOCS_ONLY ...

 Mike McCandless

 http://blog.mikemccandless.com

 On Mon, Dec 17, 2012 at 11:24 AM, Shai Erera ser...@gmail.com wrote:
  Hi
 
  While migrating code to Lucene 4.0, I noticed that I have an assert on a
  field that is indexed with DOCS_ONLY that DocsEnum.freq() == 1. This got
 me
  thinking ... why?
 
  If you index w/ DOCS_ONLY, or ask for DocsEnum with FLAG_NONE, why do we
  lie to the consumer? Rather, we could just return 0 or -1?
 
  I personally don't mind if we continue to return 1, if there's a real
 reason
  to. I don't think that anyone should call freq() if he asked for DocsEnum
  with FLAG_NONE. But if we do keep the current behavior, can we at least
  document it?
 
  E.g., something like this patch:
 
  Index: lucene/core/src/java/org/apache/lucene/index/DocsEnum.java
  ===
  --- lucene/core/src/java/org/apache/lucene/index/DocsEnum.java  (revision
  1422804)
  +++ lucene/core/src/java/org/apache/lucene/index/DocsEnum.java  (working
  copy)
  @@ -47,10 +47,16 @@
 protected DocsEnum() {
 }
 
  -  /** Returns term frequency in the current document.  Do
  -   *  not call this before {@link #nextDoc} is first called,
  -   *  nor after {@link #nextDoc} returns NO_MORE_DOCS.
  -   **/
  +  /**
  +   * Returns term frequency in the current document, or 1 if the
  +   * {@link DocsEnum} was obtained with {@link #FLAG_NONE}. Do not call
  this
  +   * before {@link #nextDoc} is first called, nor after {@link #nextDoc}
  returns
  +   * {@link DocIdSetIterator#NO_MORE_DOCS}.
  +   *
  +   * p
  +   * bNOTE:/b if the {@link DocsEnum} was obtain with {@link
  #FLAG_NONE},
  +   * this method returns 1.
  +   */
 public abstract int freq() throws IOException;
 
 /** Returns the related attributes. */
 
  Shai

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3925) Expose SpanFirst in eDismax

2012-12-17 Thread David Smiley (JIRA)


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

David Smiley commented on SOLR-3925:


Cool!

 Expose SpanFirst in eDismax
 ---

 Key: SOLR-3925
 URL: https://issues.apache.org/jira/browse/SOLR-3925
 Project: Solr
  Issue Type: Improvement
  Components: query parsers
Affects Versions: 4.0-BETA
 Environment: solr-spec 5.0.0.2012.10.09.19.29.59
 solr-impl 5.0-SNAPSHOT 1366361:1396116M - markus - 2012-10-09 19:29:59 
Reporter: Markus Jelsma
 Fix For: 4.1, 5.0

 Attachments: SOLR-3925-trunk-1.patch, SOLR-3925-trunk-2.patch


 Expose Lucene's SpanFirst capability in Solr's extended Dismax query parser. 
 This issue adds the SF-parameter (SpanFirst) and takes a FIELD~DISTANCE^BOOST 
 formatted value.
 For example, sf=title~5^2 will give a boost of 2 if one of the normal 
 clauses, originally generated for automatic phrase queries, is located within 
 five positions from the field's start.
 Unit test is included and all tests pass.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4197) EDismax allows end users to use local params in q= to override global params

2012-12-17 Thread David Smiley (JIRA)


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

David Smiley commented on SOLR-4197:


This sounds like a serious problem, although admittedly I can't think of how an 
attacker could subvert security rules (e.g. an 'fq') or otherwise spy on 
information that is otherwise concealed.  Can you think of something Peter?

 EDismax allows end users to use local params in q= to override global params
 

 Key: SOLR-4197
 URL: https://issues.apache.org/jira/browse/SOLR-4197
 Project: Solr
  Issue Type: Bug
Affects Versions: 3.5, 3.6, 4.0
Reporter: Peter Wolanin

 Edismax is advertised as suitable to be used to process advanced user input 
 directly.  Thus, it would seem reasonable to have an application directly 
 pass user input in the q= parameter to a back-end Solr server.
 However, it seems that users can enter local params at the start of q= which 
 override the global params that the application (e.g. website) may have set 
 on the query string.  Confirmed with Erik Hatcher that this is somewhat 
 unexpected behavior (though one could argue it's an expected feature of any 
 query parser)
 Proposed fix - add a parameter (e.g. that can be used as an invariant) that 
 can be passed to inhibit Solr from using local params from the q= parameter.
 This is somewhat related to SOLR-1687

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: DocsEnum.freq()

2012-12-17 Thread Michael McCandless

On Mon, Dec 17, 2012 at 4:02 PM, Shai Erera ser...@gmail.com wrote:
 How do these two go together?

 I think for DOCS_ONLY it makes sense that we lie (say freq=1 when we
 don't know): lots of places would otherwise have to be special cased
 for when they consume DOCS_ONLY vs DOCS_AND_POSITIONS.


 and

 I'm also not sure that
 all codecs return 1 today if the fields was indexed with DOCS_ONLY ...


  That just makes it even worse right? I.e., we have code today that relies
 no that behavior, but we're not sure it works w/ all Codecs?

Sorry, for my last sentence above I think I meant I'm also not sure
that all codecs return 1 today if you ask for FLAG_NONE.

 Remember that DocIdSetIterator.nextDoc() was loosely specified? It was very
 hard to write a decent DISI consumer. Sometimes calling nextDoc() returned
 MAX_VAL, sometimes -1, sometimes who knows. When we hardened the spec, it
 actually made consumers' life easier, I think?

Right, locking down the API makes total sense in general.

 It's ok if we say that for DOCS_ONLY you have to return 1. That's even 99.9%
 of the time the correct value to return (unless someone adds e.g. the same
 StringField twice to the document).

Right.

 And it's also ok to say that if you passed FLAG_NONE, freq()'s value is
 unspecified. I think it would be wrong to lie here .. not sure if the
 consumer always knows how DocsEnum was requested. Not sure if this happens
 in real life though (consuming a DocsEnum that you didn't obtain yourself),
 so I'm willing to ignore that case.

+1: I think FLAG_NONE should remain undefined.  I think we have codecs
today that will return 1, 0, the actual doc freq (when the field was
indexed as = DOCS_AND_FREQS).

 These two together sound like a reasonable spec to me?

+1

So I think just change your javadocs patch to say that FLAG_NONE means
freq is not defined, and if field was indexed as DOCS_ONLY and you
asked for FLAG_FREQS then we promise to lie and say freq=1?

Mike McCandless

http://blog.mikemccandless.com

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4197) EDismax allows end users to use local params in q= to override global params


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

Yonik Seeley commented on SOLR-4197:


bq. Apparently adding a space at the beginning is not a complete solution - I 
then get an exception when it's the standard lucene parser:

A complete solution to what?  You *should* get an error since it's not valid 
lucene syntax.  The space did it's job and prevented the localParams from being 
interpreted as localParams.  That's what you were trying to do, right?


 EDismax allows end users to use local params in q= to override global params
 

 Key: SOLR-4197
 URL: https://issues.apache.org/jira/browse/SOLR-4197
 Project: Solr
  Issue Type: Bug
Affects Versions: 3.5, 3.6, 4.0
Reporter: Peter Wolanin

 Edismax is advertised as suitable to be used to process advanced user input 
 directly.  Thus, it would seem reasonable to have an application directly 
 pass user input in the q= parameter to a back-end Solr server.
 However, it seems that users can enter local params at the start of q= which 
 override the global params that the application (e.g. website) may have set 
 on the query string.  Confirmed with Erik Hatcher that this is somewhat 
 unexpected behavior (though one could argue it's an expected feature of any 
 query parser)
 Proposed fix - add a parameter (e.g. that can be used as an invariant) that 
 can be passed to inhibit Solr from using local params from the q= parameter.
 This is somewhat related to SOLR-1687

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4197) EDismax allows end users to use local params in q= to override global params

2012-12-17 Thread Markus Jelsma (JIRA)


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

Markus Jelsma commented on SOLR-4197:
-

I think it's more graceful to ignore or strip local params per configuration 
instead of throwing an error, even for the user that for some crazy reason 
inputs a series of characters that is recognized as local params.

If edismax is to be advertized as be able to handle direct end-user input it 
should never throw an error, but to do so developers must either strip it from 
the input before sending it to Solr or configure Solr to ignore or strip it.

I would opt for an option to strip it completely. Right now we have to 
externally strip everything that looks like \{!.*\}

 EDismax allows end users to use local params in q= to override global params
 

 Key: SOLR-4197
 URL: https://issues.apache.org/jira/browse/SOLR-4197
 Project: Solr
  Issue Type: Bug
Affects Versions: 3.5, 3.6, 4.0
Reporter: Peter Wolanin

 Edismax is advertised as suitable to be used to process advanced user input 
 directly.  Thus, it would seem reasonable to have an application directly 
 pass user input in the q= parameter to a back-end Solr server.
 However, it seems that users can enter local params at the start of q= which 
 override the global params that the application (e.g. website) may have set 
 on the query string.  Confirmed with Erik Hatcher that this is somewhat 
 unexpected behavior (though one could argue it's an expected feature of any 
 query parser)
 Proposed fix - add a parameter (e.g. that can be used as an invariant) that 
 can be passed to inhibit Solr from using local params from the q= parameter.
 This is somewhat related to SOLR-1687

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-4258) Incremental Field Updates through Stacked Segments

2012-12-17 Thread David Smiley (JIRA)

[
https://issues.apache.org/jira/browse/LUCENE-4258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13534352#comment-13534352
]

David Smiley commented on LUCENE-4258:
--

Its exciting to see progress here! I too live in the world that Shai speaks
of -- DOCS_ONLY (w/ no norms). I don't need to update a title field, I need to
update ACLs and various categorical tag fields that will subsequently
influence faceting or filtering.

Hey Rob, early on you made this excellent point:
{quote}A second problem (not solved by the above) is that many people are using
scoring factors with a variety
of signals and these are changing often. I think unfortunately, people are
often putting these in
a normal indexed field and uninverting these on the fieldcache, requiring the
whole document to
be reindexed just because of how they implemented the scoring factor. People
could instead solve this
by putting their apps primary key into a docvalues field, allowing them to keep
these scoring factors
completely external to lucene (e.g. their own array or whatever), indexed by
their own primary key. But
the problem is I think people want lucene to manage this, they don't want to
implement themselves whats
necessary to make it consistent with commits etc.{quote}

So true. What if Lucene had more hooks to make it easier to manage
commit-consistency with side-car data? I have no clue what's needed exactly,
only that I don't dare do this without such hooks because I fear the
complexity. With hooks and documentation, it can become clear how to maintain
data alongside Lucene's index, and this opens doors. Like making it easier to
store data in something custom (e.g. a DB) instead of stored-fields (won't have
to pay needless merge cost), or putting metrics that influence scoring
somewhere as you hinted at above.

Incremental Field Updates through Stacked Segments
--

Key: LUCENE-4258
URL: https://issues.apache.org/jira/browse/LUCENE-4258
Project: Lucene - Core
Issue Type: Improvement
Components: core/index
Reporter: Sivan Yogev
Attachments: IncrementalFieldUpdates.odp,
LUCENE-4258-API-changes.patch, LUCENE-4258.r1410593.patch,
LUCENE-4258.r1412262.patch, LUCENE-4258.r1416438.patch,
LUCENE-4258.r1416617.patch, LUCENE-4258.r1422495.patch,
LUCENE-4258.r1423010.patch

Original Estimate: 2,520h
Remaining Estimate: 2,520h

Shai and I would like to start working on the proposal to Incremental Field
Updates outlined here (http://markmail.org/message/zhrdxxpfk6qvdaex).

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3925) Expose SpanFirst in eDismax

2012-12-17 Thread Markus Jelsma (JIRA)


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

Markus Jelsma commented on SOLR-3925:
-

Thanks for your comments Vlado. I haven't yet uploaded the patch that doesn't 
throw an error if it is not configured and haven't come to passing it through 
the analyzer yet or ignoring special characters. I'm not yet sure if we want to 
strip parens, i think it's the job of the analyzer.

It is not included in a nightly build because it is not committed, for good 
reasons ;)

 Expose SpanFirst in eDismax
 ---

 Key: SOLR-3925
 URL: https://issues.apache.org/jira/browse/SOLR-3925
 Project: Solr
  Issue Type: Improvement
  Components: query parsers
Affects Versions: 4.0-BETA
 Environment: solr-spec 5.0.0.2012.10.09.19.29.59
 solr-impl 5.0-SNAPSHOT 1366361:1396116M - markus - 2012-10-09 19:29:59 
Reporter: Markus Jelsma
 Fix For: 4.1, 5.0

 Attachments: SOLR-3925-trunk-1.patch, SOLR-3925-trunk-2.patch


 Expose Lucene's SpanFirst capability in Solr's extended Dismax query parser. 
 This issue adds the SF-parameter (SpanFirst) and takes a FIELD~DISTANCE^BOOST 
 formatted value.
 For example, sf=title~5^2 will give a boost of 2 if one of the normal 
 clauses, originally generated for automatic phrase queries, is located within 
 five positions from the field's start.
 Unit test is included and all tests pass.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4197) EDismax allows end users to use local params in q= to override global params


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

Yonik Seeley commented on SOLR-4197:


bq. I think it's more graceful to ignore or strip local params per 
configuration instead of throwing an error,

Yes, that's what edismax is for.  I think in Peter's example he was using 
lucene qparser, which has a strict syntax.



 EDismax allows end users to use local params in q= to override global params
 

 Key: SOLR-4197
 URL: https://issues.apache.org/jira/browse/SOLR-4197
 Project: Solr
  Issue Type: Bug
Affects Versions: 3.5, 3.6, 4.0
Reporter: Peter Wolanin

 Edismax is advertised as suitable to be used to process advanced user input 
 directly.  Thus, it would seem reasonable to have an application directly 
 pass user input in the q= parameter to a back-end Solr server.
 However, it seems that users can enter local params at the start of q= which 
 override the global params that the application (e.g. website) may have set 
 on the query string.  Confirmed with Erik Hatcher that this is somewhat 
 unexpected behavior (though one could argue it's an expected feature of any 
 query parser)
 Proposed fix - add a parameter (e.g. that can be used as an invariant) that 
 can be passed to inhibit Solr from using local params from the q= parameter.
 This is somewhat related to SOLR-1687

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4197) EDismax allows end users to use local params in q= to override global params


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

Yonik Seeley commented on SOLR-4197:


Options for forcing edismax and prohibiting changing the query type or adding 
other parameters via localParams (as opposed to just defaulting):
1) prepend a space to the user query
2) prepend {!edismax} to the user query
3) use a different parameter:  q={!edismax v=$qq}qq=user_query

If you do any of these and get a syntax error back, then it's an edismax 
escaping bug that we need to handle.

 EDismax allows end users to use local params in q= to override global params
 

 Key: SOLR-4197
 URL: https://issues.apache.org/jira/browse/SOLR-4197
 Project: Solr
  Issue Type: Bug
Affects Versions: 3.5, 3.6, 4.0
Reporter: Peter Wolanin

 Edismax is advertised as suitable to be used to process advanced user input 
 directly.  Thus, it would seem reasonable to have an application directly 
 pass user input in the q= parameter to a back-end Solr server.
 However, it seems that users can enter local params at the start of q= which 
 override the global params that the application (e.g. website) may have set 
 on the query string.  Confirmed with Erik Hatcher that this is somewhat 
 unexpected behavior (though one could argue it's an expected feature of any 
 query parser)
 Proposed fix - add a parameter (e.g. that can be used as an invariant) that 
 can be passed to inhibit Solr from using local params from the q= parameter.
 This is somewhat related to SOLR-1687

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-4197) EDismax allows end users to use local params in q= to override global params


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

Yonik Seeley edited comment on SOLR-4197 at 12/17/12 10:19 PM:
---

Options for forcing edismax and prohibiting changing the query type or adding 
other parameters via localParams (as opposed to just defaulting):
{code}
1) prepend a space to the user query
2) prepend {!edismax} to the user query
3) use a different parameter:  q={!edismax v=$qq}qq=user_query
{code}
If you do any of these and get a syntax error back, then it's an edismax 
escaping bug that we need to handle.

  was (Author: ysee...@gmail.com):
Options for forcing edismax and prohibiting changing the query type or 
adding other parameters via localParams (as opposed to just defaulting):
1) prepend a space to the user query
2) prepend {!edismax} to the user query
3) use a different parameter:  q={!edismax v=$qq}qq=user_query

If you do any of these and get a syntax error back, then it's an edismax 
escaping bug that we need to handle.
  
 EDismax allows end users to use local params in q= to override global params
 

 Key: SOLR-4197
 URL: https://issues.apache.org/jira/browse/SOLR-4197
 Project: Solr
  Issue Type: Bug
Affects Versions: 3.5, 3.6, 4.0
Reporter: Peter Wolanin

 Edismax is advertised as suitable to be used to process advanced user input 
 directly.  Thus, it would seem reasonable to have an application directly 
 pass user input in the q= parameter to a back-end Solr server.
 However, it seems that users can enter local params at the start of q= which 
 override the global params that the application (e.g. website) may have set 
 on the query string.  Confirmed with Erik Hatcher that this is somewhat 
 unexpected behavior (though one could argue it's an expected feature of any 
 query parser)
 Proposed fix - add a parameter (e.g. that can be used as an invariant) that 
 can be passed to inhibit Solr from using local params from the q= parameter.
 This is somewhat related to SOLR-1687

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-4208) Refactor edismax query parser

2012-12-17 Thread JIRA

Tomás Fernández Löbbe created SOLR-4208:
---

 Summary: Refactor edismax query parser
 Key: SOLR-4208
 URL: https://issues.apache.org/jira/browse/SOLR-4208
 Project: Solr
  Issue Type: Improvement
Reporter: Tomás Fernández Löbbe
Priority: Minor
 Fix For: 4.1, 5.0


With successive changes, the edismax query parser has become more complex. It 
would be nice to refactor it to reduce code complexity, also to allow better 
extension and code reuse.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-4208) Refactor edismax query parser

2012-12-17 Thread JIRA

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

Tomás Fernández Löbbe updated SOLR-4208:

Attachment: SOLR-4208.patch

A possible refactor:
* I separated the ExtendedDismaxQParser so it can be extended.
* I broke the parse method into smaller methods, easier to read.
* Separated the configuration (parsing and all the actual fields) to a
different class. DismaxQParser has too many configuration options, I think it's
going to be clear if we keep those separately.
* Using factory methods for the configuration and the ExtendedSolrQueryParser
so that an extending class could change the implementation of those classes.
* other minor changes.

Thoughts?

Refactor edismax query parser
-

Key: SOLR-4208
URL: https://issues.apache.org/jira/browse/SOLR-4208
Project: Solr
Issue Type: Improvement
Reporter: Tomás Fernández Löbbe
Priority: Minor
Fix For: 4.1, 5.0

Attachments: SOLR-4208.patch

With successive changes, the edismax query parser has become more complex. It
would be nice to refactor it to reduce code complexity, also to allow better
extension and code reuse.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-4110) Configurable Content-Type headers for PHPResponseWriters and PHPSerializedResponseWriter

2012-12-17 Thread Mark Miller (JIRA)


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

Mark Miller resolved SOLR-4110.
---

Resolution: Fixed

Thanks Dominik!

 Configurable Content-Type headers for PHPResponseWriters and 
 PHPSerializedResponseWriter
 

 Key: SOLR-4110
 URL: https://issues.apache.org/jira/browse/SOLR-4110
 Project: Solr
  Issue Type: Improvement
  Components: Response Writers
Affects Versions: 4.0
Reporter: Dominik Siebel
Assignee: Mark Miller
Priority: Minor
  Labels: 4.0.1_Candidate
 Fix For: 4.1, 5.0

 Attachments: SOLR-4110_branch_4x.patch, SOLR-4110.patch, 
 SOLR-4110_trunk.patch


 The *PHPResponseWriter* and *PHPSerializedResponseWriter* currently send a 
 hard coded Content-Type header of _text/plain; charset=UTF-8_ although there 
 are constants defining _text/x-php;charset=UTF-8_ and 
 _text/x-php-serialized;charset=UTF-8_ which remain unused. This makes content 
 type guessing on the client side quite complicated.
 I already created a patch (from the branch_4x github branch) to use the 
 respective constants and also added the possibility to configure the 
 Content-Type header via solrconfig.xml (like in JSONResponseWriter).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3083) all JMX Mbeans are identified as java.lang.String even if numeric

2012-12-17 Thread Ryan Josal (JIRA)


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

Ryan Josal commented on SOLR-3083:
--

I applied this patch to Solr 3.6 - I noticed it missed the hitratio mbean 
attribute from [Fast]LRUCache.  Looks like that attribute is actually 
calculated into a String and so would have to be fixed by itself.  I'm not sure 
if this is still present in the latest builds though.

 all JMX Mbeans are identified as java.lang.String even if numeric
 -

 Key: SOLR-3083
 URL: https://issues.apache.org/jira/browse/SOLR-3083
 Project: Solr
  Issue Type: Bug
  Components: SearchComponents - other
Affects Versions: 4.0-ALPHA
Reporter: Tagged Siteops
Assignee: Ryan McKinley
Priority: Minor
  Labels: interoperability,, jmx, monitoring, statistics
 Fix For: 4.0-ALPHA

 Attachments: Screen shot 2012-01-31 at 2.19.06 PM.png, 
 SOLR-3083-Made-JMX-Mbean-information-use-numeric-typ.patch


 When trying to monitor our Solr instances with JMXtrans 
 (https://github.com/lookfirst/jmxtrans), we discovered that all the Mbeans 
 were identifying themselves as java.lang.String.   This breaks the 
 GangliaWriter in JMXtrans because the software decides it's a string instead 
 of a numeric values and you can't graph a string.   Other software we are 
 monitoring with JMXtrans (e.g. Kafka) correctly identify their numeric values 
 as numbers (doubles in this case).
 For example, avgTimePerRequest in Solr is identified as a string which makes 
 no sense.  This behavior makes Solr less interoperable with the rest of the 
 Java ecosystem.
 The problem code is in JmxMonitoredMap.java
 NamedList dynamicStats = infoBean.getStatistics();
 if (dynamicStats != null) {
   for (int i = 0; i  dynamicStats.size(); i++) {
 String name = dynamicStats.getName(i);
 if (!staticStats.contains(name))
   attrInfoList.add(new MBeanAttributeInfo(dynamicStats.getName(i),
   String.class.getName(), null, true, false, false));
   }
 I will try to attach a screenshot. 
 Thanks for Solr!  We use the heck out of it, it's awesome.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.7.0_09) - Build # 2203 - Failure!


On Dec 17, 2012, at 7:31 PM, Mark Miller markrmil...@gmail.com wrote:

 Socket read timeouts. I'll raise it for this case.

Nevermind - it's already at 60 seconds. What's odd is that the commit is taking 
that long.

One of the threads is waiting in the rate limiter - which is weird - I thought 
I put it absurdly high for tests. I'll dig into it when I get a chance:

[junit4:junit4]   1 Thread[qtp29204452-1358,5,TGRP-ShardRoutingTest]
[junit4:junit4]   1 java.lang.Thread.sleep(Native Method)
[junit4:junit4]   1 java.lang.Thread.sleep(Thread.java:338)
[junit4:junit4]   1 
org.apache.lucene.store.RateLimiter$SimpleRateLimiter.pause(RateLimiter.java:111)
[junit4:junit4]   1 
org.apache.lucene.store.RateLimitedIndexOutput.flushBuffer(RateLimitedIndexOutput.java:45)
[junit4:junit4]   1 
org.apache.lucene.store.BufferedIndexOutput.flushBuffer(BufferedIndexOutput.java:90)
[junit4:junit4]   1 
org.apache.lucene.store.BufferedIndexOutput.flush(BufferedIndexOutput.java:79)
[junit4:junit4]   1 
org.apache.lucene.store.RateLimitedIndexOutput.flush(RateLimitedIndexOutput.java:69)
[junit4:junit4]   1 
org.apache.lucene.store.BufferedIndexOutput.close(BufferedIndexOutput.java:103)
[junit4:junit4]   1 
org.apache.lucene.store.RateLimitedIndexOutput.close(RateLimitedIndexOutput.java:78)
[junit4:junit4]   1 
org.apache.lucene.store.ChecksumIndexOutput.close(ChecksumIndexOutput.java:61)
[junit4:junit4]   1 
org.apache.lucene.index.SegmentInfos.finishCommit(SegmentInfos.java:927)
[junit4:junit4]   1 
org.apache.lucene.index.IndexWriter.finishCommit(IndexWriter.java:2826)
[junit4:junit4]   1 
org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2815)
[junit4:junit4]   1 
org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2788)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.7.0_09) - Build # 2203 - Failure!

These are the MB/s values I have - I didn't think they would kick in during our 
tests?

double name=maxWriteMBPerSecDefault100/double
double name=maxWriteMBPerSecFlush200/double
double name=maxWriteMBPerSecMerge300/double
double name=maxWriteMBPerSecRead400/double

Mark

On Dec 17, 2012, at 7:35 PM, Mark Miller markrmil...@gmail.com wrote:

 
 On Dec 17, 2012, at 7:31 PM, Mark Miller markrmil...@gmail.com wrote:
 
 Socket read timeouts. I'll raise it for this case.
 
 Nevermind - it's already at 60 seconds. What's odd is that the commit is 
 taking that long.
 
 One of the threads is waiting in the rate limiter - which is weird - I 
 thought I put it absurdly high for tests. I'll dig into it when I get a 
 chance:
 
 [junit4:junit4]   1 Thread[qtp29204452-1358,5,TGRP-ShardRoutingTest]
 [junit4:junit4]   1 java.lang.Thread.sleep(Native Method)
 [junit4:junit4]   1 java.lang.Thread.sleep(Thread.java:338)
 [junit4:junit4]   1 
 org.apache.lucene.store.RateLimiter$SimpleRateLimiter.pause(RateLimiter.java:111)
 [junit4:junit4]   1 
 org.apache.lucene.store.RateLimitedIndexOutput.flushBuffer(RateLimitedIndexOutput.java:45)
 [junit4:junit4]   1 
 org.apache.lucene.store.BufferedIndexOutput.flushBuffer(BufferedIndexOutput.java:90)
 [junit4:junit4]   1 
 org.apache.lucene.store.BufferedIndexOutput.flush(BufferedIndexOutput.java:79)
 [junit4:junit4]   1 
 org.apache.lucene.store.RateLimitedIndexOutput.flush(RateLimitedIndexOutput.java:69)
 [junit4:junit4]   1 
 org.apache.lucene.store.BufferedIndexOutput.close(BufferedIndexOutput.java:103)
 [junit4:junit4]   1 
 org.apache.lucene.store.RateLimitedIndexOutput.close(RateLimitedIndexOutput.java:78)
 [junit4:junit4]   1 
 org.apache.lucene.store.ChecksumIndexOutput.close(ChecksumIndexOutput.java:61)
 [junit4:junit4]   1 
 org.apache.lucene.index.SegmentInfos.finishCommit(SegmentInfos.java:927)
 [junit4:junit4]   1 
 org.apache.lucene.index.IndexWriter.finishCommit(IndexWriter.java:2826)
 [junit4:junit4]   1 
 org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2815)
 [junit4:junit4]   1 
 org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2788)


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS-MAVEN] Lucene-Solr-Maven-trunk #710: POMs out of sync

2012-12-17 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/710/

No tests ran.

Build Log:
[...truncated 11065 lines...]



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4143) setRequestHandler - option to not set qt parameter


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

Shawn Heisey commented on SOLR-4143:


Going back to the OverseerTest that I noted was failing before -- I have been 
having a lot of nearly identical failures in a lot of programs lately, OOMs 
when trying to create a thread.  One of the programs that is having this 
failure is a very small servlet (SolrJ-based) that cycles between 15 and 25MB 
of heap usage, then suddenly it crashes with an OOM, with no changes in access.

I am suspecting that the OOM problem might actually be in the jdk 1.7.0_09 
(linux x64) that I was using.  I have upgraded that to 1.7.0_10 to see if it 
gets better.

 setRequestHandler - option to not set qt parameter
 --

 Key: SOLR-4143
 URL: https://issues.apache.org/jira/browse/SOLR-4143
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Affects Versions: 4.0
 Environment: solr-impl4.1-SNAPSHOT 1416639M - ncindex - 
 2012-12-03 12:54:38
Reporter: Shawn Heisey
 Fix For: 4.1, 5.0

 Attachments: SOLR-4143-alternate.patch, 
 SOLR-4143-alternate-testsfailing.patch, SOLR-4143.patch, SOLR-4143.patch, 
 SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch


 The setRequestHandler method does what I expect in one way - it changes the 
 URL path from /select to the String argument.  It is however doing something 
 that I did not expect, which is setting the qt parameter on the query as 
 well.  Here is the code:
 private static final String PING_HANDLER = /admin/ping;
 query.setRequestHandler(PING_HANDLER);
 This is resulting in the following exception being logged in my Solr 3.5.0 
 servers.  I am not including the whole exception, because this issue is for 
 SolrJ 4, not Solr 3.5, and the 3.5 version is working as it was designed.
 {code}
 Dec 3, 2012 4:04:01 PM org.apache.solr.common.SolrException log
 SEVERE: org.apache.solr.common.SolrException: Cannot execute the 
 PingRequestHandler recursively
 at 
 org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:60)
 at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:208)
 {code}
 I believe it would be useful to include an alternate setRequestHandler method 
 that includes a boolean option deciding whether or not to also set the qt 
 parameter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-4143) setRequestHandler - option to not set qt parameter


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

Shawn Heisey edited comment on SOLR-4143 at 12/18/12 2:15 AM:
--

Going back to the OverseerTest that I noted was failing before -- I have been 
having a lot of nearly identical failures in a lot of programs lately, OOMs 
when trying to create a thread.  One of the programs that is having this 
failure is a very small servlet (SolrJ-based) that cycles between 15 and 25MB 
of heap usage, then suddenly it crashes with an OOM, with no changes in access. 
 The JVM has a 1GB max heap, and jconsole shows no growth pattern in memory 
usage, then at the crash point it goes down to zero.

I am suspecting that the OOM problem might actually be in the jdk 1.7.0_09 
(linux x64) that I was using.  I have upgraded that to 1.7.0_10 to see if it 
gets better.

  was (Author: elyograg):
Going back to the OverseerTest that I noted was failing before -- I have 
been having a lot of nearly identical failures in a lot of programs lately, 
OOMs when trying to create a thread.  One of the programs that is having this 
failure is a very small servlet (SolrJ-based) that cycles between 15 and 25MB 
of heap usage, then suddenly it crashes with an OOM, with no changes in access.

I am suspecting that the OOM problem might actually be in the jdk 1.7.0_09 
(linux x64) that I was using.  I have upgraded that to 1.7.0_10 to see if it 
gets better.
  
 setRequestHandler - option to not set qt parameter
 --

 Key: SOLR-4143
 URL: https://issues.apache.org/jira/browse/SOLR-4143
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Affects Versions: 4.0
 Environment: solr-impl4.1-SNAPSHOT 1416639M - ncindex - 
 2012-12-03 12:54:38
Reporter: Shawn Heisey
 Fix For: 4.1, 5.0

 Attachments: SOLR-4143-alternate.patch, 
 SOLR-4143-alternate-testsfailing.patch, SOLR-4143.patch, SOLR-4143.patch, 
 SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch


 The setRequestHandler method does what I expect in one way - it changes the 
 URL path from /select to the String argument.  It is however doing something 
 that I did not expect, which is setting the qt parameter on the query as 
 well.  Here is the code:
 private static final String PING_HANDLER = /admin/ping;
 query.setRequestHandler(PING_HANDLER);
 This is resulting in the following exception being logged in my Solr 3.5.0 
 servers.  I am not including the whole exception, because this issue is for 
 SolrJ 4, not Solr 3.5, and the 3.5 version is working as it was designed.
 {code}
 Dec 3, 2012 4:04:01 PM org.apache.solr.common.SolrException log
 SEVERE: org.apache.solr.common.SolrException: Cannot execute the 
 PingRequestHandler recursively
 at 
 org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:60)
 at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:208)
 {code}
 I believe it would be useful to include an alternate setRequestHandler method 
 that includes a boolean option deciding whether or not to also set the qt 
 parameter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #710: POMs out of sync

2012-12-17 Thread Steve Rowe

I committed a fix for this (missing SHA1 file for randomizedtesting-runner 
dependency): upgraded to v2.0.7 in trunk and on branch_4x.

On Dec 17, 2012, at 8:34 PM, Apache Jenkins Server jenk...@builds.apache.org 
wrote:

 Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/710/
 
 No tests ran.
 
 Build Log:
 [...truncated 11065 lines...]
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4205) Clover runs on ASF Jenkins idle dead without a test or any thread running in main() loop waiting for file descriptor


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

Commit Tag Bot commented on SOLR-4205:
--

[trunk commit] Steven Rowe
http://svn.apache.org/viewvc?view=revisionrevision=1423252

SOLR-4205: Maven configuration: upgrade randomizedtesting-runner to v2.0.7


 Clover runs on ASF Jenkins idle dead without a test or any thread running in 
 main() loop waiting for file descriptor
 

 Key: SOLR-4205
 URL: https://issues.apache.org/jira/browse/SOLR-4205
 Project: Solr
  Issue Type: Bug
  Components: Tests
 Environment: FreeBSD Jenkins
Reporter: Uwe Schindler
Assignee: Dawid Weiss

 I had to kill ASF Jenkins Clover builds two times after several 10 hours of 
 inactivity in a random Solr test. I requested a stack trace before killing 
 the only running JVM (clover runs with one JVM only, because clover does not 
 like multiple processes writing the same clover metrics file).
 In both cases (4.x and trunk) the stack trace was looking identical after 
 sending kill -3...
 https://builds.apache.org/job/Lucene-Solr-Clover-trunk/76/consoleFull 
 (yesterday):
 {noformat}
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:01:00, stalled for 28447s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:02:00, stalled for 28507s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:03:00, stalled for 28567s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] JVM J0: stdout was not empty, see: 
 /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Clover-trunk/solr/build/solr-core/test/temp/junit4-J0-20121216_044733_583.sysout
 [junit4:junit4]  JVM J0: stdout (verbatim) 
 [junit4:junit4] 2012-12-16 13:03:49
 [junit4:junit4] Full thread dump OpenJDK 64-Bit Server VM (20.0-b12 mixed 
 mode):
 [junit4:junit4] 
 [junit4:junit4] searcherExecutor-2577-thread-1 prio=5 
 tid=0x00085eb67000 nid=0x61c105b waiting on condition [0x70b0d000]
 [junit4:junit4]java.lang.Thread.State: WAITING (parking)
 [junit4:junit4]   at sun.misc.Unsafe.park(Native Method)
 [junit4:junit4]   - parking to wait for  0x0008178c9c40 (a 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 [junit4:junit4]   at 
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 [junit4:junit4]   at 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 [junit4:junit4]   at 
 java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:386)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 [junit4:junit4]   at java.lang.Thread.run(Thread.java:679)
 [junit4:junit4] 
 [junit4:junit4] RMI TCP Accept-0 daemon prio=5 tid=0x000840ce2800 
 nid=0x61c0aa2 runnable [0x79496000]
 [junit4:junit4]java.lang.Thread.State: RUNNABLE
 [junit4:junit4]   at java.net.PlainSocketImpl.socketAccept(Native Method)
 [junit4:junit4]   at 
 java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:375)
 [junit4:junit4]   at 
 java.net.ServerSocket.implAccept(ServerSocket.java:470)
 [junit4:junit4]   at java.net.ServerSocket.accept(ServerSocket.java:438)
 [junit4:junit4]   at 
 sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:387)
 [junit4:junit4]   at 
 sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:359)
 [junit4:junit4]   at java.lang.Thread.run(Thread.java:679)
 [junit4:junit4] 
 [junit4:junit4] RMI Scheduler(0) daemon prio=5 tid=0x000840ce1000 
 nid=0x61c0969 waiting on condition [0x70f11000]
 [junit4:junit4]java.lang.Thread.State: WAITING (parking)
 [junit4:junit4]   at sun.misc.Unsafe.park(Native Method)
 [junit4:junit4]   - parking to wait for  0x000814f12f88 (a 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 [junit4:junit4]   at 
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 [junit4:junit4]   at 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 [junit4:junit4]   at 
 java.util.concurrent.DelayQueue.take(DelayQueue.java:189)
 [junit4:junit4]   at

[jira] [Commented] (SOLR-4205) Clover runs on ASF Jenkins idle dead without a test or any thread running in main() loop waiting for file descriptor


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

Commit Tag Bot commented on SOLR-4205:
--

[branch_4x commit] Steven Rowe
http://svn.apache.org/viewvc?view=revisionrevision=1423253

SOLR-4205: Maven configuration: upgrade randomizedtesting-runner to v2.0.7 
(merge trunk r1423252)


 Clover runs on ASF Jenkins idle dead without a test or any thread running in 
 main() loop waiting for file descriptor
 

 Key: SOLR-4205
 URL: https://issues.apache.org/jira/browse/SOLR-4205
 Project: Solr
  Issue Type: Bug
  Components: Tests
 Environment: FreeBSD Jenkins
Reporter: Uwe Schindler
Assignee: Dawid Weiss

 I had to kill ASF Jenkins Clover builds two times after several 10 hours of 
 inactivity in a random Solr test. I requested a stack trace before killing 
 the only running JVM (clover runs with one JVM only, because clover does not 
 like multiple processes writing the same clover metrics file).
 In both cases (4.x and trunk) the stack trace was looking identical after 
 sending kill -3...
 https://builds.apache.org/job/Lucene-Solr-Clover-trunk/76/consoleFull 
 (yesterday):
 {noformat}
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:01:00, stalled for 28447s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:02:00, stalled for 28507s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] HEARTBEAT J0 PID(81...@lucene.zones.apache.org): 
 2012-12-16T13:03:00, stalled for 28567s at: 
 TestFunctionQuery.testBooleanFunctions
 [junit4:junit4] JVM J0: stdout was not empty, see: 
 /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Clover-trunk/solr/build/solr-core/test/temp/junit4-J0-20121216_044733_583.sysout
 [junit4:junit4]  JVM J0: stdout (verbatim) 
 [junit4:junit4] 2012-12-16 13:03:49
 [junit4:junit4] Full thread dump OpenJDK 64-Bit Server VM (20.0-b12 mixed 
 mode):
 [junit4:junit4] 
 [junit4:junit4] searcherExecutor-2577-thread-1 prio=5 
 tid=0x00085eb67000 nid=0x61c105b waiting on condition [0x70b0d000]
 [junit4:junit4]java.lang.Thread.State: WAITING (parking)
 [junit4:junit4]   at sun.misc.Unsafe.park(Native Method)
 [junit4:junit4]   - parking to wait for  0x0008178c9c40 (a 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 [junit4:junit4]   at 
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 [junit4:junit4]   at 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 [junit4:junit4]   at 
 java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:386)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1043)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1103)
 [junit4:junit4]   at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
 [junit4:junit4]   at java.lang.Thread.run(Thread.java:679)
 [junit4:junit4] 
 [junit4:junit4] RMI TCP Accept-0 daemon prio=5 tid=0x000840ce2800 
 nid=0x61c0aa2 runnable [0x79496000]
 [junit4:junit4]java.lang.Thread.State: RUNNABLE
 [junit4:junit4]   at java.net.PlainSocketImpl.socketAccept(Native Method)
 [junit4:junit4]   at 
 java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:375)
 [junit4:junit4]   at 
 java.net.ServerSocket.implAccept(ServerSocket.java:470)
 [junit4:junit4]   at java.net.ServerSocket.accept(ServerSocket.java:438)
 [junit4:junit4]   at 
 sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:387)
 [junit4:junit4]   at 
 sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:359)
 [junit4:junit4]   at java.lang.Thread.run(Thread.java:679)
 [junit4:junit4] 
 [junit4:junit4] RMI Scheduler(0) daemon prio=5 tid=0x000840ce1000 
 nid=0x61c0969 waiting on condition [0x70f11000]
 [junit4:junit4]java.lang.Thread.State: WAITING (parking)
 [junit4:junit4]   at sun.misc.Unsafe.park(Native Method)
 [junit4:junit4]   - parking to wait for  0x000814f12f88 (a 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
 [junit4:junit4]   at 
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 [junit4:junit4]   at 
 java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
 [junit4:junit4]   at 
 java.util.concurrent.DelayQueue.take(DelayQueue.java:189)

[jira] [Comment Edited] (SOLR-3180) ChaosMonkey test failures


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

Yonik Seeley edited comment on SOLR-3180 at 12/18/12 3:35 AM:
--

Unfortunately, the chaos monkey tests have gathered some rust due to not being 
run regularly.

I've added some instrumentation for one particular type of fail (number of docs 
mismatch between control and collection) and ran into something peculiar.

selected lines from test_report_1.txt
{code}
6952 T39 oasc.ZkController.register Register shard - core:c
ollection1 address:http://127.0.0.1:60440/ij/pf shardId:shard1

9734 T56 oasc.ZkController.register Register shard - core:c
ollection1 address:http://127.0.0.1:48048/ij/pf shardId:shard1

12184 T71 oasc.ZkController.register Register shard - core:
collection1 address:http://127.0.0.1:33264/ij/pf shardId:shard2

59069 T27 C12 P60440 /update {wt=javabinversion=2} {add=[50067 
(1421643212854919168)]} 0 3

89123 T48 C1 P48048 /update {wt=javabinversion=2} {add=[50067 
(1421643244360433664)]} 0 10

89354 T25 C12 P60440 /update {wt=javabinversion=2} {delete=[50067 
(-1421643244613140480)]} 0 1

89364 T47 C1 P48048 /update {wt=javabinversion=2} {delete=[50067 
(-1421643244618383360)]} 0 6

90114 T63 C3 P33264 /update {wt=javabinversion=2} {add=[50067]} 0 31041

217860 T10 oasc.AbstractFullDistribZkTestBase.checkShardConsistency SEVERE 
document count mismatch.  control=1460 sum(shards)=1461 cloudClient=1461
[junit4:junit4]

## Only in cloudDocList: [{id=50067}]
{code}

The only updates we see from the logs for id 50067 are to collection1 (none to 
the control shard).

Further, grepping for Register shard shows that they are all for collection1 
and none for the control collection.  Not sure how that's possible and only be 
off by 1, so I'm probably mis-interpreting the logging somehow...

  was (Author: ysee...@gmail.com):
Unfortunately, the chaos monkey tests have gathered some rust due to not 
being run regularly.

I've added some instrumentation for one particular type of fail (number of docs 
mismatch between control and collection) and ran into something peculiar.

selected lines from test_report_1.txt
{code}
6952 T39 oasc.ZkController.register Register shard - core:c
ollection1 address:http://127.0.0.1:60440/ij/pf shardId:shard1

9734 T56 oasc.ZkController.register Register shard - core:c
ollection1 address:http://127.0.0.1:48048/ij/pf shardId:shard1

12184 T71 oasc.ZkController.register Register shard - core:
collection1 address:http://127.0.0.1:33264/ij/pf shardId:shard2

59069 T27 C12 P60440 /update {wt=javabinversion=2} {add=[50067 
(1421643212854919168)]} 0 3

89123 T48 C1 P48048 /update {wt=javabinversion=2} {add=[50067 
(1421643244360433664)]} 0 10

89354 T25 C12 P60440 /update {wt=javabinversion=2} {delete=[50067 
(-1421643244613140480)]} 0 1

89364 T47 C1 P48048 /update {wt=javabinversion=2} {delete=[50067 
(-1421643244618383360)]} 0 6

90114 T63 C3 P33264 /update {wt=javabinversion=2} {add=[50067]} 0 31041

217860 T10 oasc.AbstractFullDistribZkTestBase.checkShardConsistency SEVERE 
document count mismatch.  control=1460 sum(shards)=1461 cloudClient=1461
[junit4:junit4]   2 ## Only in cloudDocList: [{id=50067}]
{code}

The only updates we see from the logs for id 50067 are to collection1 (none to 
the control shard).

Further, grepping for Register shard shows that they are all for collection1 
and none for the control collection.  Not sure how that's possible and only be 
off by 1, so I'm probably mis-interpreting the logging somehow...
  
 ChaosMonkey test failures
 -

 Key: SOLR-3180
 URL: https://issues.apache.org/jira/browse/SOLR-3180
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Reporter: Yonik Seeley
 Attachments: test_report_1.txt


 Handle intermittent failures in the ChaosMonkey tests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-3180) ChaosMonkey test failures


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

Yonik Seeley updated SOLR-3180:
---

Attachment: test_report_1.txt

Unfortunately, the chaos monkey tests have gathered some rust due to not being 
run regularly.

I've added some instrumentation for one particular type of fail (number of docs 
mismatch between control and collection) and ran into something peculiar.

selected lines from test_report_1.txt
{code}
6952 T39 oasc.ZkController.register Register shard - core:c
ollection1 address:http://127.0.0.1:60440/ij/pf shardId:shard1

9734 T56 oasc.ZkController.register Register shard - core:c
ollection1 address:http://127.0.0.1:48048/ij/pf shardId:shard1

12184 T71 oasc.ZkController.register Register shard - core:
collection1 address:http://127.0.0.1:33264/ij/pf shardId:shard2

59069 T27 C12 P60440 /update {wt=javabinversion=2} {add=[50067 
(1421643212854919168)]} 0 3

89123 T48 C1 P48048 /update {wt=javabinversion=2} {add=[50067 
(1421643244360433664)]} 0 10

89354 T25 C12 P60440 /update {wt=javabinversion=2} {delete=[50067 
(-1421643244613140480)]} 0 1

89364 T47 C1 P48048 /update {wt=javabinversion=2} {delete=[50067 
(-1421643244618383360)]} 0 6

90114 T63 C3 P33264 /update {wt=javabinversion=2} {add=[50067]} 0 31041

217860 T10 oasc.AbstractFullDistribZkTestBase.checkShardConsistency SEVERE 
document count mismatch.  control=1460 sum(shards)=1461 cloudClient=1461
[junit4:junit4]   2 ## Only in cloudDocList: [{id=50067}]
{code}

The only updates we see from the logs for id 50067 are to collection1 (none to 
the control shard).

Further, grepping for Register shard shows that they are all for collection1 
and none for the control collection.  Not sure how that's possible and only be 
off by 1, so I'm probably mis-interpreting the logging somehow...

 ChaosMonkey test failures
 -

 Key: SOLR-3180
 URL: https://issues.apache.org/jira/browse/SOLR-3180
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Reporter: Yonik Seeley
 Attachments: test_report_1.txt


 Handle intermittent failures in the ChaosMonkey tests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.7.0_09) - Build # 2203 - Failure!

2012-12-17 Thread Yonik Seeley

This test only brings servers up at the beginning and that's it (i.e.
any recovery would be of an empty index).

It feels like we're throwing too many random elements into higher
level tests here - introducing too many variables at once (i.e. the
random Directory implementations).

-Yonik
http://lucidworks.com


On Mon, Dec 17, 2012 at 7:57 PM, Mark Miller markrmil...@gmail.com wrote:
 These are the MB/s values I have - I didn't think they would kick in during 
 our tests?

 double name=maxWriteMBPerSecDefault100/double
 double name=maxWriteMBPerSecFlush200/double
 double name=maxWriteMBPerSecMerge300/double
 double name=maxWriteMBPerSecRead400/double

 Mark

 On Dec 17, 2012, at 7:35 PM, Mark Miller markrmil...@gmail.com wrote:


 On Dec 17, 2012, at 7:31 PM, Mark Miller markrmil...@gmail.com wrote:

 Socket read timeouts. I'll raise it for this case.

 Nevermind - it's already at 60 seconds. What's odd is that the commit is 
 taking that long.

 One of the threads is waiting in the rate limiter - which is weird - I 
 thought I put it absurdly high for tests. I'll dig into it when I get a 
 chance:

 [junit4:junit4]   1 Thread[qtp29204452-1358,5,TGRP-ShardRoutingTest]
 [junit4:junit4]   1 java.lang.Thread.sleep(Native Method)
 [junit4:junit4]   1 java.lang.Thread.sleep(Thread.java:338)
 [junit4:junit4]   1 
 org.apache.lucene.store.RateLimiter$SimpleRateLimiter.pause(RateLimiter.java:111)
 [junit4:junit4]   1 
 org.apache.lucene.store.RateLimitedIndexOutput.flushBuffer(RateLimitedIndexOutput.java:45)
 [junit4:junit4]   1 
 org.apache.lucene.store.BufferedIndexOutput.flushBuffer(BufferedIndexOutput.java:90)
 [junit4:junit4]   1 
 org.apache.lucene.store.BufferedIndexOutput.flush(BufferedIndexOutput.java:79)
 [junit4:junit4]   1 
 org.apache.lucene.store.RateLimitedIndexOutput.flush(RateLimitedIndexOutput.java:69)
 [junit4:junit4]   1 
 org.apache.lucene.store.BufferedIndexOutput.close(BufferedIndexOutput.java:103)
 [junit4:junit4]   1 
 org.apache.lucene.store.RateLimitedIndexOutput.close(RateLimitedIndexOutput.java:78)
 [junit4:junit4]   1 
 org.apache.lucene.store.ChecksumIndexOutput.close(ChecksumIndexOutput.java:61)
 [junit4:junit4]   1 
 org.apache.lucene.index.SegmentInfos.finishCommit(SegmentInfos.java:927)
 [junit4:junit4]   1 
 org.apache.lucene.index.IndexWriter.finishCommit(IndexWriter.java:2826)
 [junit4:junit4]   1 
 org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2815)
 [junit4:junit4]   1 
 org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2788)


 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

OOM failures caused by java 1.7.0_09?

2012-12-17 Thread Shawn Heisey

I have been seeing a bunch of random failures, both in Solr tests and my 
own SolrJ programs.  They all start with the following in the stacktrace:


java.lang.OutOfMemoryError: unable to create new native thread

at java.lang.Thread.start0(Native Method)

at java.lang.Thread.start(Thread.java:691)


Common elements: 1) SolrJ/Solr 4.1-SNAPSHOT.  2) G1 garbage collector.  
3) Built and run with oracle jdk 1.7.0_09 on CentOS 6 x64, using RPMs 
created with the following guide:


http://www.city-fan.org/tips/OracleJava7OnFedora

One of the programs consistently uses less than 25MB of heap, because it 
uses idle moments to do garbage collection.  I have watched the heap 
with jconsole to verify this.  It has been configured with a max heap of 
1GB, so I am very sure that there is no actual memory pressure.


Since rebooting and upgrading to 1.7.0_10, I have not seen any further 
OOM problems despite pounding on everything repeatedly. Has anyone else 
seen anything similar?


Thanks,
Shawn

Re: [JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.7.0_09) - Build # 2203 - Failure!

The rate limited dir is not random - its being used in most tests as most tests 
use the std solrconfig.xml - it's hard coded but it's just using really high 
values with the idea it would not do any limiting. This was done so I could see 
it didn't have a bad affect and test that the settings matched what was in the 
config.

The settings are so high I don't think it should ever be sleeping like it is.

- Mark

On Dec 17, 2012, at 10:45 PM, Yonik Seeley yo...@lucidworks.com wrote:

 This test only brings servers up at the beginning and that's it (i.e.
 any recovery would be of an empty index).
 
 It feels like we're throwing too many random elements into higher
 level tests here - introducing too many variables at once (i.e. the
 random Directory implementations).
 
 -Yonik
 http://lucidworks.com
 
 
 On Mon, Dec 17, 2012 at 7:57 PM, Mark Miller markrmil...@gmail.com wrote:
 These are the MB/s values I have - I didn't think they would kick in during 
 our tests?
 
double name=maxWriteMBPerSecDefault100/double
double name=maxWriteMBPerSecFlush200/double
double name=maxWriteMBPerSecMerge300/double
double name=maxWriteMBPerSecRead400/double
 
 Mark
 
 On Dec 17, 2012, at 7:35 PM, Mark Miller markrmil...@gmail.com wrote:
 
 
 On Dec 17, 2012, at 7:31 PM, Mark Miller markrmil...@gmail.com wrote:
 
 Socket read timeouts. I'll raise it for this case.
 
 Nevermind - it's already at 60 seconds. What's odd is that the commit is 
 taking that long.
 
 One of the threads is waiting in the rate limiter - which is weird - I 
 thought I put it absurdly high for tests. I'll dig into it when I get a 
 chance:
 
 [junit4:junit4]   1 Thread[qtp29204452-1358,5,TGRP-ShardRoutingTest]
 [junit4:junit4]   1 java.lang.Thread.sleep(Native Method)
 [junit4:junit4]   1 java.lang.Thread.sleep(Thread.java:338)
 [junit4:junit4]   1 
 org.apache.lucene.store.RateLimiter$SimpleRateLimiter.pause(RateLimiter.java:111)
 [junit4:junit4]   1 
 org.apache.lucene.store.RateLimitedIndexOutput.flushBuffer(RateLimitedIndexOutput.java:45)
 [junit4:junit4]   1 
 org.apache.lucene.store.BufferedIndexOutput.flushBuffer(BufferedIndexOutput.java:90)
 [junit4:junit4]   1 
 org.apache.lucene.store.BufferedIndexOutput.flush(BufferedIndexOutput.java:79)
 [junit4:junit4]   1 
 org.apache.lucene.store.RateLimitedIndexOutput.flush(RateLimitedIndexOutput.java:69)
 [junit4:junit4]   1 
 org.apache.lucene.store.BufferedIndexOutput.close(BufferedIndexOutput.java:103)
 [junit4:junit4]   1 
 org.apache.lucene.store.RateLimitedIndexOutput.close(RateLimitedIndexOutput.java:78)
 [junit4:junit4]   1 
 org.apache.lucene.store.ChecksumIndexOutput.close(ChecksumIndexOutput.java:61)
 [junit4:junit4]   1 
 org.apache.lucene.index.SegmentInfos.finishCommit(SegmentInfos.java:927)
 [junit4:junit4]   1 
 org.apache.lucene.index.IndexWriter.finishCommit(IndexWriter.java:2826)
 [junit4:junit4]   1 
 org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2815)
 [junit4:junit4]   1 
 org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2788)
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3180) ChaosMonkey test failures


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

Commit Tag Bot commented on SOLR-3180:
--

[trunk commit] Yonik Seeley
http://svn.apache.org/viewvc?view=revisionrevision=1423275

SOLR-3180: improve logging


 ChaosMonkey test failures
 -

 Key: SOLR-3180
 URL: https://issues.apache.org/jira/browse/SOLR-3180
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Reporter: Yonik Seeley
 Attachments: test_report_1.txt


 Handle intermittent failures in the ChaosMonkey tests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3180) ChaosMonkey test failures


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

Commit Tag Bot commented on SOLR-3180:
--

[branch_4x commit] Yonik Seeley
http://svn.apache.org/viewvc?view=revisionrevision=1423276

SOLR-3180: improve logging


 ChaosMonkey test failures
 -

 Key: SOLR-3180
 URL: https://issues.apache.org/jira/browse/SOLR-3180
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Reporter: Yonik Seeley
 Attachments: test_report_1.txt


 Handle intermittent failures in the ChaosMonkey tests.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-4143) setRequestHandler - option to not set qt parameter


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

Shawn Heisey updated SOLR-4143:
---

Attachment: SOLR-4143-alternate-trunk.patch
SOLR-4143-alternate-4x.patch

Patches that are completely up to date with newest revisions of 4x and trunk.

 setRequestHandler - option to not set qt parameter
 --

 Key: SOLR-4143
 URL: https://issues.apache.org/jira/browse/SOLR-4143
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Affects Versions: 4.0
 Environment: solr-impl4.1-SNAPSHOT 1416639M - ncindex - 
 2012-12-03 12:54:38
Reporter: Shawn Heisey
 Fix For: 4.1, 5.0

 Attachments: SOLR-4143-alternate-4x.patch, SOLR-4143-alternate.patch, 
 SOLR-4143-alternate-testsfailing.patch, SOLR-4143-alternate-trunk.patch, 
 SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch, SOLR-4143.patch, 
 SOLR-4143.patch


 The setRequestHandler method does what I expect in one way - it changes the 
 URL path from /select to the String argument.  It is however doing something 
 that I did not expect, which is setting the qt parameter on the query as 
 well.  Here is the code:
 private static final String PING_HANDLER = /admin/ping;
 query.setRequestHandler(PING_HANDLER);
 This is resulting in the following exception being logged in my Solr 3.5.0 
 servers.  I am not including the whole exception, because this issue is for 
 SolrJ 4, not Solr 3.5, and the 3.5 version is working as it was designed.
 {code}
 Dec 3, 2012 4:04:01 PM org.apache.solr.common.SolrException log
 SEVERE: org.apache.solr.common.SolrException: Cannot execute the 
 PingRequestHandler recursively
 at 
 org.apache.solr.handler.PingRequestHandler.handleRequestBody(PingRequestHandler.java:60)
 at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:208)
 {code}
 I believe it would be useful to include an alternate setRequestHandler method 
 that includes a boolean option deciding whether or not to also set the qt 
 parameter.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-4209) asm-3.1.jar is missing

2012-12-17 Thread Shinichiro Abe (JIRA)

Shinichiro Abe created SOLR-4209:


 Summary: asm-3.1.jar is missing
 Key: SOLR-4209
 URL: https://issues.apache.org/jira/browse/SOLR-4209
 Project: Solr
  Issue Type: Bug
  Components: contrib - Solr Cell (Tika extraction)
Affects Versions: 4.0
Reporter: Shinichiro Abe
Priority: Minor


One of Tika dependency file is missing on Solr 4.0. 
When posting java class files into Solr via SolrCell, those files can't be 
indexed without asm-3.1.jar.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-4209) asm-3.1.jar is missing

2012-12-17 Thread Shinichiro Abe (JIRA)


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

Shinichiro Abe updated SOLR-4209:
-

Attachment: SOLR-4209.patch

Here is a patch. Please apply this.

 asm-3.1.jar is missing
 --

 Key: SOLR-4209
 URL: https://issues.apache.org/jira/browse/SOLR-4209
 Project: Solr
  Issue Type: Bug
  Components: contrib - Solr Cell (Tika extraction)
Affects Versions: 4.0
Reporter: Shinichiro Abe
Priority: Minor
 Attachments: SOLR-4209.patch


 One of Tika dependency file is missing on Solr 4.0. 
 When posting java class files into Solr via SolrCell, those files can't be 
 indexed without asm-3.1.jar.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4205) Clover runs on ASF Jenkins idle dead without a test or any thread running in main() loop waiting for file descriptor