date:20130318


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

Mark Miller updated SOLR-4605:
--

Attachment: SOLR-4605.patch

patch attatched

 SolrException: Error opening new searcher
 -

 Key: SOLR-4605
 URL: https://issues.apache.org/jira/browse/SOLR-4605
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.1, 4.2
 Environment: Ubuntu 12.04.2 LTS
Reporter: Mark S
Assignee: Mark Miller
  Labels: solrj
 Fix For: 4.3, 5.0

 Attachments: SOLR-4605.patch


 http://lucene.472066.n3.nabble.com/Solr-4-1-4-2-SolrException-Error-opening-new-searcher-td4046543.html
 I wrote a simple test to reproduce a very similar stack trace to the above 
 issue, where only some line numbers differences due to Solr 4.1 vs Solr 4.2.
 *Source of Exception*
 * 
 [http://svn.apache.org/viewvc/lucene/dev/tags/lucene_solr_4_1_0/solr/core/src/java/org/apache/solr/core/SolrCore.java?view=markup]
 * 
 [http://svn.apache.org/viewvc/lucene/dev/tags/lucene_solr_4_2_0/solr/core/src/java/org/apache/solr/core/SolrCore.java?view=markup]
 {code:java} 
 catch (Exception e) {
 throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, Error 
 opening new searcher, e);
 }
 {code}
 Any ideas as to why the following happens?  Any help would be very 
 appreciated.
 * *The test case:*
 {code:java}
 @Test
 public void documentCommitAndRollbackTest() throws Exception {
 // Fix:  SolrException: Error opening new searcher
 server.rollback();
 server.commit();
 }
 {code}
 * *The similar stack trace (Which is repeated twice):*
 {quote}
 Mar 15, 2013 3:48:09 PM org.apache.solr.common.SolrException log
 SEVERE: org.apache.solr.common.SolrException: Error opening new searcher
 at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:1415)
 at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1527)
 at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1304)
 at 
 org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:570)
 at 
 org.apache.solr.update.processor.RunUpdateProcessor.processCommit(RunUpdateProcessorFactory.java:95)
 at 
 org.apache.solr.update.processor.UpdateRequestProcessor.processCommit(UpdateRequestProcessor.java:64)
 at 
 org.apache.solr.update.processor.DistributedUpdateProcessor.processCommit(DistributedUpdateProcessor.java:1055)
 at 
 org.apache.solr.update.processor.LogUpdateProcessor.processCommit(LogUpdateProcessorFactory.java:157)
 at 
 org.apache.solr.handler.RequestHandlerUtils.handleCommit(RequestHandlerUtils.java:69)
 at 
 org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
 at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
 at org.apache.solr.core.SolrCore.execute(SolrCore.java:1797)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:637)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:141)
 at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
 at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
 at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
 at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
 at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
 at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
 at 
 org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
 at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
 at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
 at 
 org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
 at 
 org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
 at 
 org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:722)
 Caused by: org.apache.lucene.store.AlreadyClosedException: this IndexWriter 
 is closed
 at

[jira] [Commented] (SOLR-4604) UpdateLog#init is over called on SolrCore#reload


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

Commit Tag Bot commented on SOLR-4604:
--

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

SOLR-4604: remove previous init code


 UpdateLog#init is over called on SolrCore#reload
 

 Key: SOLR-4604
 URL: https://issues.apache.org/jira/browse/SOLR-4604
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.3, 5.0


 I think this is why I have occasionally not been able to remove tlogs on 
 Windows.

--
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-4604) UpdateLog#init is over called on SolrCore#reload


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

Commit Tag Bot commented on SOLR-4604:
--

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

SOLR-4604: UpdateLog#init is over called on SolrCore#reload



 UpdateLog#init is over called on SolrCore#reload
 

 Key: SOLR-4604
 URL: https://issues.apache.org/jira/browse/SOLR-4604
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.3, 5.0


 I think this is why I have occasionally not been able to remove tlogs on 
 Windows.

--
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-4604) UpdateLog#init is over called on SolrCore#reload


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

Commit Tag Bot commented on SOLR-4604:
--

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

SOLR-4604: remove previous init code


 UpdateLog#init is over called on SolrCore#reload
 

 Key: SOLR-4604
 URL: https://issues.apache.org/jira/browse/SOLR-4604
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.3, 5.0


 I think this is why I have occasionally not been able to remove tlogs on 
 Windows.

--
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-3706) Ship setup to log with log4j.

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

Mark Miller commented on SOLR-3706:
---

Sorry Ryan - fell off my radar this weekend. I'll try and look at this sometime
after I wake up today.

Ship setup to log with log4j.
-

Key: SOLR-3706
URL: https://issues.apache.org/jira/browse/SOLR-3706
Project: Solr
Issue Type: Improvement
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
Fix For: 4.3, 5.0

Attachments: SOLR-3706-solr-log4j.patch, SOLR-3706-solr-log4j.patch

Currently we default to java util logging and it's terrible in my opinion.
*It's simple built in logger is a 2 line logger.
*You have to jump through hoops to use your own custom formatter with jetty -
either putting your class in the start.jar or other pain in the butt
solutions.
*It can't roll files by date out of the box.
I'm sure there are more issues, but those are the ones annoying me now. We
should switch to log4j - it's much nicer and it's easy to get a nice single
line format and roll by date, etc.
If someone wants to use JUL they still can - but at least users could start
with something decent.

--
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] [Reopened] (SOLR-4597) CachingDirectoryFactory#remove should not attempt to empty/remove the index right away but flag for removal after close.


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

Mark Miller reopened SOLR-4597:
---


Need to deal with a Windows problem here still.

 CachingDirectoryFactory#remove should not attempt to empty/remove the index 
 right away but flag for removal after close.
 

 Key: SOLR-4597
 URL: https://issues.apache.org/jira/browse/SOLR-4597
 Project: Solr
  Issue Type: Bug
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.3, 5.0




--
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-4577) The collections API should return responses (sucess or failure) for each node it attempts to work with.

2013-03-18 Thread Per Steffensen (JIRA)


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

Per Steffensen commented on SOLR-4577:
--

I provided my attempt at a holistic solution in SOLR-3178, with a separate 
issue SOLR-3382 on the part of response-includes-response-for-each-subrequest. 
Unfortunately it is merged in with all the other improvements in SOLR-3178. I 
would like to try to dig out the parts related to exception-propagation and 
inclusion of sub-request results/exceptions. If you want?

 The collections API should return responses (sucess or failure) for each node 
 it attempts to work with.
 ---

 Key: SOLR-4577
 URL: https://issues.apache.org/jira/browse/SOLR-4577
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.3, 5.0


 This is when the command itself is successful on the node, but then we need a 
 report of the sub command result on each node.
 There is some code that sort of attempts to do this that came in with the 
 collection api response contribution, but it's not really working currently.

--
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-trunk-Linux-Java7-64-test-only - Build # 27192 - Failure!

Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/27192/

1 tests failed.
REGRESSION:  org.apache.lucene.util.TestSorterTemplate.testAscending

Error Message:
0

Stack Trace:
java.lang.ArrayIndexOutOfBoundsException: 0
at 
__randomizedtesting.SeedInfo.seed([1471A490A9CAE875:665F7356C5C46990]:0)
at 
org.apache.lucene.util.TestSorterTemplate.testAscending(TestSorterTemplate.java:122)
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 
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 
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)




Build Log:
[...truncated 1203 lines...]
[junit4:junit4] Suite: org.apache.lucene.util.TestSorterTemplate
[junit4:junit4]   2 NOTE: reproduce with: ant test  
-Dtestcase=TestSorterTemplate -Dtests.method=testAscending 
-Dtests.seed=1471A490A9CAE875 -Dtests.slow=true -Dtests.locale=sr_BA_#Latn 
-Dtests.timezone=Asia/Yakutsk -Dtests.file.encoding=UTF-8
[junit4:junit4] ERROR   0.02s J4 | TestSorterTemplate.testAscending 
[junit4:junit4] Throwable #1: java.lang.ArrayIndexOutOfBoundsException: 0
[junit4:junit4]at 
__randomizedtesting.SeedInfo.seed([1471A490A9CAE875:665F7356C5C46990]:0)
[junit4:junit4]at

[jira] [Assigned] (LUCENE-4848) Add Directory implementations using NIO2 APIs

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

Uwe Schindler reassigned LUCENE-4848:
-

Assignee: Uwe Schindler

Hi Michael,
thank you very much for the directory implementations.

I already thought about that a while before, but I was not aware, that the
WindowsFileChannelFactory
(http://www.docjar.com/html/api/sun/nio/fs/WindowsChannelFactory.java.html)
automatically passes FILE_SHARE_DELETE by default to the windows open syscall.
So this is indeed an improvement, because it allows to delete files that are
opened like that. I have not yet verified this, but I trust you and will take
it under consideration. But be warned: FILE_SHARE_DELETE does *not* completely
emulate delete-after-last-close semantics from POSIX. It looks like the file
keeps valid and disappears from the directory, but in contrast to POSIX, you
cannot delete the directory the file is in, nor can you create a new file with
the same name as the still open, but deleted one. This should not be an issue
for Lucene, as it never recreates files with the same name which it keept open
before.

About your classes in general. The *new* directory implementation (the Async
one), could go into Lucene 5.0, once we moved to Java 7, so this would be a
start in the direction on doing the move. We had a discussion on the
mailinglist and all committers +1.

About the NIOFSDirectory and MMapDirectory: Those are 100% clones of the
originals and we dont want to have 100% clones of same classes in Lucene core,
so I would restructure them. The good thing here is: The really only change in
those clones is the part that opens a FileChannel from a file name. And that
involves only 3 calls to Java 7 APIs. My idea was to simply insert that code
(using reflection for Lucene 4.x into the original MMapDirectory and
NIOFSDirectory) into a helper function for opening (File in, FileChannel out)
that creates a RAF on Java 6 and directly allocates FileChannel on Java 7 -
Problem solved. Introducting new Java 7 symbols like Path into Lucene makes
no sense at the moment, so its hidden as implementation detail.

I will provide a patch for NIOFS and MMap later.

Thanks in any case, this issue brought me to the right track of maybe solving
the delete on windows problem - I am still not sure if this really helps and
does not break the semantics Lucene expects from the underlying FS.

Add Directory implementations using NIO2 APIs
-

Key: LUCENE-4848
URL: https://issues.apache.org/jira/browse/LUCENE-4848
Project: Lucene - Core
Issue Type: Task
Reporter: Michael Poindexter
Assignee: Uwe Schindler
Priority: Minor
Attachments: jdk7directory.zip

I have implemented 3 Directory subclasses using NIO2 API's (available on
JDK7). These may be suitable for inclusion in a Lucene contrib module.
See the mailing list at http://lucene.markmail.org/thread/lrv7miivzmjm3ml5
for more details about this code and the advantages it provides.
The code is attached as a zip to this issue. I'll be happy to make any
changes requested. I've included some minimal smoke tests, but any help in
how to use the normal Lucene tests to perform more thorough testing would be
appreciated.

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

[jira] [Commented] (LUCENE-4848) Add Directory implementations using NIO2 APIs

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

Uwe Schindler commented on LUCENE-4848:
---

bq. These may be suitable for inclusion in a Lucene contrib module.

There are no more cntrib modules and we want all normal modules use the same
JDK version, as we had major problems for the release manager to build and test
the realease when multiple JDK versions are involved. So this can only go into
Lucene 5.0 (which will use Java 7). Parts of if MMap and NIOFS changes may go
into Lucene 4, too - as the changes are minimal and could be solved by
reflection (see above).

Add Directory implementations using NIO2 APIs
-

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

Re: StoredField

2013-03-18 Thread Adrien Grand

On Sun, Mar 17, 2013 at 5:56 PM, eksdev eks...@googlemail.com wrote:
 Hi Adrian,

Hi eksdev,

 I cannot tell if such thing would make it less or more robust, just thinking 
 aloud  :)

 I am thinking of it as a way to somehow postpone byte-type conversion to the 
 moment where it is really needed.  Simply, keep byte[] around as long as 
 possible.
 *Theoretically*, this should improve gc() and memory footprint for some types 
 of downstream processing. It all depends how easy would something like that 
 be.

 There is already a way to achieve this by using binary field type, …  hmmm, 
 maybe some lucene.expert hack to make Lucene think every field is binary wold 
 be simple and robust enough?
 e.g. Visitor.transportOnlySerializedValuesWithoutTypeConversion()

Sorry, but I think it would do more harm than good:
 - Stored fields encoding is an implementation detail so someone could
write a StoredFieldsFormat that serializes strings in UTF-16 to avoid
decoding overhead at read time, how
would.transportOnlySerializedValuesWithoutTypeConversion know the
actual encoding used by the underlying StoredFieldsFormat?
 - It would make users think that this kind of optimization is
valuable performance-wise while I think it's unnoticeable.

-- 
Adrien

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

Re: [JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 27192 - Failure!

2013-03-18 Thread Adrien Grand

I'll have a look.

-- 
Adrien

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

[jira] [Commented] (LUCENE-4752) Merge segments to sort them


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

Shai Erera commented on LUCENE-4752:


Ok I see that IW needs to access OneMerge.readers for various other reasons, so 
let's leave it like that. Maybe just put a comment in IW where it calls 
merge.getReaders() why we don't access the readers list directly here and go 
through the method?

 Merge segments to sort them
 ---

 Key: LUCENE-4752
 URL: https://issues.apache.org/jira/browse/LUCENE-4752
 Project: Lucene - Core
  Issue Type: New Feature
  Components: core/index
Reporter: David Smiley
Assignee: Adrien Grand
 Attachments: LUCENE-4752.patch, LUCENE-4752.patch, LUCENE-4752.patch, 
 LUCENE-4752.patch


 It would be awesome if Lucene could write the documents out in a segment 
 based on a configurable order.  This of course applies to merging segments 
 to. The benefit is increased locality on disk of documents that are likely to 
 be accessed together.  This often applies to documents near each other in 
 time, but also spatially.

--
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-4844) Remove TaxonomyReader.getParent(ord)


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

Commit Tag Bot commented on LUCENE-4844:


[trunk commit] Shai Erera
http://svn.apache.org/viewvc?view=revisionrevision=1457674

LUCENE-4844: remove TaxonomyReader.getParent


 Remove TaxonomyReader.getParent(ord)
 

 Key: LUCENE-4844
 URL: https://issues.apache.org/jira/browse/LUCENE-4844
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Reporter: Shai Erera
Assignee: Shai Erera
 Attachments: LUCENE-4844.patch


 This should have been gone when we introduced .getParallelArrays(). The 
 method simply calls getParallelArrays().parents()[ord], and that's what 
 callers should do. Except one test, no other code in facets calls this method.

--
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] [Resolved] (LUCENE-4844) Remove TaxonomyReader.getParent(ord)


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

Shai Erera resolved LUCENE-4844.


   Resolution: Fixed
Fix Version/s: 4.3
   5.0

Committed to trunk and 4x.

 Remove TaxonomyReader.getParent(ord)
 

 Key: LUCENE-4844
 URL: https://issues.apache.org/jira/browse/LUCENE-4844
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Reporter: Shai Erera
Assignee: Shai Erera
 Fix For: 5.0, 4.3

 Attachments: LUCENE-4844.patch


 This should have been gone when we introduced .getParallelArrays(). The 
 method simply calls getParallelArrays().parents()[ord], and that's what 
 callers should do. Except one test, no other code in facets calls this method.

--
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-4844) Remove TaxonomyReader.getParent(ord)


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

Commit Tag Bot commented on LUCENE-4844:


[branch_4x commit] Shai Erera
http://svn.apache.org/viewvc?view=revisionrevision=1457675

LUCENE-4844: remove TaxonomyReader.getParent


 Remove TaxonomyReader.getParent(ord)
 

 Key: LUCENE-4844
 URL: https://issues.apache.org/jira/browse/LUCENE-4844
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Reporter: Shai Erera
Assignee: Shai Erera
 Fix For: 5.0, 4.3

 Attachments: LUCENE-4844.patch


 This should have been gone when we introduced .getParallelArrays(). The 
 method simply calls getParallelArrays().parents()[ord], and that's what 
 callers should do. Except one test, no other code in facets calls this method.

--
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-4848) Add Directory implementations using NIO2 APIs

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

Uwe Schindler commented on LUCENE-4848:
---

Hi Michael, one request to you:

Would it be possible to create a *patch* that does not add new classes prefixed
with JDK7 (which should be Java7 btw), but instead directly modify the
existing classes in Lucene 5 (aka trunk)? Of course the new Async variant would
be a new class, but for includion in Lucene 5, a real patch without code
duplication would be fine. And please try to keep the logic changes as
minimal as possible in the existing classes.

I am working on MMapDirectory at the moment to make a patch that also works
with Lucene 4 using reflection.

Add Directory implementations using NIO2 APIs
-

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

[jira] [Commented] (SOLR-4489) StringIndexOutOfBoundsException in SpellCheckComponent


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

Artem Lukanin commented on SOLR-4489:
-

The same issue with wordbreak in Solr 4.1:

params={spellcheck=trueindent=trueq=calvin\+harris\+feat\+ne\+yospellcheck.q=calvin\+harris\+feat\+ne\+yowt=xml}

SEVERE: null:java.lang.StringIndexOutOfBoundsException: String index out of 
range: 25
at 
java.lang.AbstractStringBuilder.charAt(AbstractStringBuilder.java:174)
at java.lang.StringBuilder.charAt(StringBuilder.java:55)
at 
org.apache.solr.spelling.SpellCheckCollator.getCollation(SpellCheckCollator.java:164)
at 
org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:75)
at 
org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:203)
at 
org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:180)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:208)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1816)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:448)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:269)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at 
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)
at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
at 
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)

If I set
str name=combineWordsfalse/str
the exception disappears.

 StringIndexOutOfBoundsException in SpellCheckComponent 
 ---

 Key: SOLR-4489
 URL: https://issues.apache.org/jira/browse/SOLR-4489
 Project: Solr
  Issue Type: Bug
  Components: spellchecker
Affects Versions: 4.0
 Environment: all
Reporter: venkata marrapu
Priority: Critical

 My SOLR request params are as shown below.
 spellcheck=trueenableElevation=truefacet=truespellcheck.q=minecraftspellcheck.extendedResults=truespellcheck.maxCollations=10spellcheck.collate=truewt=javabindefType=edismaxspellcheck.onlyMorePopular=true
   etc.
 Note: this work fine many use cases, however it fails for some query terms.
 Feb 22, 2013 11:06:04 AM org.apache.solr.common.SolrException log
 SEVERE: null:java.lang.StringIndexOutOfBoundsException: String index out of 
 range: -5
   at 
 java.lang.AbstractStringBuilder.replace(AbstractStringBuilder.java:797)
   at java.lang.StringBuilder.replace(StringBuilder.java:271)
   at 
 org.apache.solr.spelling.SpellCheckCollator.getCollation(SpellCheckCollator.java:190)
   at 
 org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:75)
   at 
 org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:203)
   at 
 org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:180)
   at 
 org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:206)
   at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
   at org.apache.solr.core.SolrCore.execute(SolrCore.java:1699)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:455)
   at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:276)
   at

[jira] [Updated] (LUCENE-4713) SPI: Allow fallback to default ClassLoader if Thread#getContextClassLoader fails


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

Uwe Schindler updated LUCENE-4713:
--

Fix Version/s: 4.2.1

 SPI: Allow fallback to default ClassLoader if Thread#getContextClassLoader 
 fails
 

 Key: LUCENE-4713
 URL: https://issues.apache.org/jira/browse/LUCENE-4713
 Project: Lucene - Core
  Issue Type: Improvement
Affects Versions: 4.0, 4.1, 4.2
Reporter: Christian Kohlschütter
Assignee: Uwe Schindler
Priority: Minor
  Labels: ClassLoader, Thread
 Fix For: 5.0, 4.3, 4.2.1

 Attachments: LUCENE-4713.patch, LUCENE-4713.patch, LUCENE-4713.patch, 
 LUCENE-4713.patch, LUCENE-4713.patch, LUCENE-4713.patch, LUCENE-4713.patch, 
 LuceneContextClassLoader.patch


 NOTE: This issue has been renamed from:
 Replace calls to Thread#getContextClassLoader with the ClassLoader of the 
 current class
 because the revised patch provides a clean fallback path.
 I am not sure whether it is a design decision or if we can indeed consider 
 this a bug:
 In core and analysis-common some classes provide on-demand class loading 
 using SPI. In NamedSPILoader, SPIClassIterator, ClasspathResourceLoader and 
 AnalysisSPILoader there are constructors that use the Thread's context 
 ClassLoader by default whenever no particular other ClassLoader was specified.
 Unfortunately this does not work as expected when the Thread's ClassLoader 
 can't see the required classes that are instantiated downstream with the help 
 of Class.forName (e.g., Codecs, Analyzers, etc.).
 That's what happened to us here. We currently experiment with running Lucene 
 2.9 and 4.x in one JVM, both being separated by custom ClassLoaders, each 
 seeing only the corresponding Lucene version and the upstream classpath.
 While NamedSPILoader and company get successfully loaded by our custom 
 ClassLoader, their instantiation fails because our Thread's 
 Context-ClassLoader cannot find the additionally required classes.
 We could probably work-around this by using Thread#setContextClassLoader at 
 construction time (and quickly reverting back afterwards), but I have the 
 impression this might just hide the actual problem and cause further trouble 
 when lazy-loading classes later on, and potentially from another Thread.
 Removing the call to Thread#getContextClassLoader would also align with the 
 behavior of AttributeSource.DEFAULT_ATTRIBUTE_FACTORY, which in fact uses 
 Attribute#getClass().getClassLoader() instead.
 A simple patch is attached. 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] (LUCENE-4713) SPI: Allow fallback to default ClassLoader if Thread#getContextClassLoader fails


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

Uwe Schindler commented on LUCENE-4713:
---

As Lucene 4.2.1 is coming, I backported to 4.2 branch in revision: 1457695

 SPI: Allow fallback to default ClassLoader if Thread#getContextClassLoader 
 fails
 

 Key: LUCENE-4713
 URL: https://issues.apache.org/jira/browse/LUCENE-4713
 Project: Lucene - Core
  Issue Type: Improvement
Affects Versions: 4.0, 4.1, 4.2
Reporter: Christian Kohlschütter
Assignee: Uwe Schindler
Priority: Minor
  Labels: ClassLoader, Thread
 Fix For: 5.0, 4.3, 4.2.1

 Attachments: LUCENE-4713.patch, LUCENE-4713.patch, LUCENE-4713.patch, 
 LUCENE-4713.patch, LUCENE-4713.patch, LUCENE-4713.patch, LUCENE-4713.patch, 
 LuceneContextClassLoader.patch


 NOTE: This issue has been renamed from:
 Replace calls to Thread#getContextClassLoader with the ClassLoader of the 
 current class
 because the revised patch provides a clean fallback path.
 I am not sure whether it is a design decision or if we can indeed consider 
 this a bug:
 In core and analysis-common some classes provide on-demand class loading 
 using SPI. In NamedSPILoader, SPIClassIterator, ClasspathResourceLoader and 
 AnalysisSPILoader there are constructors that use the Thread's context 
 ClassLoader by default whenever no particular other ClassLoader was specified.
 Unfortunately this does not work as expected when the Thread's ClassLoader 
 can't see the required classes that are instantiated downstream with the help 
 of Class.forName (e.g., Codecs, Analyzers, etc.).
 That's what happened to us here. We currently experiment with running Lucene 
 2.9 and 4.x in one JVM, both being separated by custom ClassLoaders, each 
 seeing only the corresponding Lucene version and the upstream classpath.
 While NamedSPILoader and company get successfully loaded by our custom 
 ClassLoader, their instantiation fails because our Thread's 
 Context-ClassLoader cannot find the additionally required classes.
 We could probably work-around this by using Thread#setContextClassLoader at 
 construction time (and quickly reverting back afterwards), but I have the 
 impression this might just hide the actual problem and cause further trouble 
 when lazy-loading classes later on, and potentially from another Thread.
 Removing the call to Thread#getContextClassLoader would also align with the 
 behavior of AttributeSource.DEFAULT_ATTRIBUTE_FACTORY, which in fact uses 
 Attribute#getClass().getClassLoader() instead.
 A simple patch is attached. 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] [Updated] (LUCENE-4847) Sorter API: Fully reuse docs enums

2013-03-18 Thread Adrien Grand (JIRA)


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

Adrien Grand updated LUCENE-4847:
-

Attachment: LUCENE-4847.patch

Patch.

 Sorter API: Fully reuse docs enums
 --

 Key: LUCENE-4847
 URL: https://issues.apache.org/jira/browse/LUCENE-4847
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: 4.3

 Attachments: LUCENE-4847.patch


 SortingAtomicReader reuses the filtered docs enums but not the wrapper. In 
 the case of SortingAtomicReader this can be a problem because the wrappers 
 are heavyweight (they load the whole postings list into memory), so an index 
 with many terms with high freqs will make the JVM allocate a lot of memory 
 when browsing the postings lists.

--
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-4489) StringIndexOutOfBoundsException in SpellCheckComponent


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

Artem Lukanin commented on SOLR-4489:
-

with combineWords=false I have another exception for the query 
'рики\-тики\-тави':

org.apache.solr.spelling.SpellCheckCollator collate
WARNING: Exception trying to re-query to check if a spell check possibility 
would return any hits.
org.apache.solr.common.SolrException: org.apache.solr.search.SyntaxError: 
Cannot parse 'рики\-таки\(-т -а -ви)': Encountered  ) )  at line 1, 
column 21.
Was expecting one of:
EOF 
AND ...
OR ...
NOT ...
+ ...
- ...
BAREOPER ...
( ...
* ...
^ ...
QUOTED ...
TERM ...
FUZZY_SLOP ...
PREFIXTERM ...
WILDTERM ...
REGEXPTERM ...
[ ...
{ ...
LPARAMS ...
NUMBER ...

at 
org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:147)
at 
org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:111)
at 
org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:203)
at 
org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:180)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:208)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1816)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:448)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:269)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at 
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)
at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
at 
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: org.apache.solr.search.SyntaxError: Cannot parse 'рики\-таки\(-т -а 
-ви)': Encountered  ) )  at line 1, column 21.
Was expecting one of:
EOF 
AND ...
OR ...
NOT ...
+ ...
- ...
BAREOPER ...
( ...
* ...
^ ...
QUOTED ...
TERM ...
FUZZY_SLOP ...
PREFIXTERM ...
WILDTERM ...
REGEXPTERM ...
[ ...
{ ...
LPARAMS ...
NUMBER ...

at 
org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:164)
at 
org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:72)
at org.apache.solr.search.QParser.getQuery(QParser.java:142)
at 
org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:117)
... 23 more
Caused by: org.apache.solr.parser.ParseException: Encountered  ) )  at 
line 1, column 21.
Was expecting one of:
EOF 
AND ...
OR ...
NOT ...
+ ...
- ...
BAREOPER ...
( ...
* ...
^ ...
QUOTED ...
TERM ...
FUZZY_SLOP ...
PREFIXTERM ...
WILDTERM ...
REGEXPTERM ...
[ ...
{ ...
LPARAMS ...
NUMBER ...

at 
org.apache.solr.parser.QueryParser.generateParseException(QueryParser.java:651)
at 
org.apache.solr.parser.QueryParser.jj_consume_token(QueryParser.java:533)
at org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:98)
at 
org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:160)
... 26 more


So, SpellCheckCollator generates a corrupted query for the original escaped 
query.
I have
solrQueryParser defaultOperator=AND/
in the schema, as well.

 StringIndexOutOfBoundsException in SpellCheckComponent

[jira] [Comment Edited] (SOLR-4489) StringIndexOutOfBoundsException in SpellCheckComponent


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

Artem Lukanin edited comment on SOLR-4489 at 3/18/13 10:22 AM:
---

with combineWords=false I have another exception for the query 
codeрики\-тики\-тави/code
:

code
org.apache.solr.spelling.SpellCheckCollator collate
WARNING: Exception trying to re-query to check if a spell check possibility 
would return any hits.
org.apache.solr.common.SolrException: org.apache.solr.search.SyntaxError: 
Cannot parse 'рики\-таки\(-т -а -ви)': Encountered  ) )  at line 1, 
column 21.
Was expecting one of:
EOF 
AND ...
OR ...
NOT ...
+ ...
- ...
BAREOPER ...
( ...
* ...
^ ...
QUOTED ...
TERM ...
FUZZY_SLOP ...
PREFIXTERM ...
WILDTERM ...
REGEXPTERM ...
[ ...
{ ...
LPARAMS ...
NUMBER ...

at 
org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:147)
at 
org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:111)
at 
org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:203)
at 
org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:180)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:208)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1816)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:448)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:269)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at 
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)
at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
at 
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: org.apache.solr.search.SyntaxError: Cannot parse 'рики\-таки\(-т -а 
-ви)': Encountered  ) )  at line 1, column 21.
Was expecting one of:
EOF 
AND ...
OR ...
NOT ...
+ ...
- ...
BAREOPER ...
( ...
* ...
^ ...
QUOTED ...
TERM ...
FUZZY_SLOP ...
PREFIXTERM ...
WILDTERM ...
REGEXPTERM ...
[ ...
{ ...
LPARAMS ...
NUMBER ...

at 
org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:164)
at 
org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:72)
at org.apache.solr.search.QParser.getQuery(QParser.java:142)
at 
org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:117)
... 23 more
Caused by: org.apache.solr.parser.ParseException: Encountered  ) )  at 
line 1, column 21.
Was expecting one of:
EOF 
AND ...
OR ...
NOT ...
+ ...
- ...
BAREOPER ...
( ...
* ...
^ ...
QUOTED ...
TERM ...
FUZZY_SLOP ...
PREFIXTERM ...
WILDTERM ...
REGEXPTERM ...
[ ...
{ ...
LPARAMS ...
NUMBER ...

at 
org.apache.solr.parser.QueryParser.generateParseException(QueryParser.java:651)
at 
org.apache.solr.parser.QueryParser.jj_consume_token(QueryParser.java:533)
at org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:98)
at 
org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:160)
... 26 more
/code

So, SpellCheckCollator generates a corrupted query for the original escaped 
query.
I have
code
solrQueryParser defaultOperator=AND/
/code
in the schema, as well.

  was (Author:

[jira] [Comment Edited] (SOLR-4489) StringIndexOutOfBoundsException in SpellCheckComponent


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

Artem Lukanin edited comment on SOLR-4489 at 3/18/13 10:24 AM:
---

with combineWords=false I have another exception for the query 
{code}рики\-тики\-тави{code}
:

{code}
org.apache.solr.spelling.SpellCheckCollator collate
WARNING: Exception trying to re-query to check if a spell check possibility 
would return any hits.
org.apache.solr.common.SolrException: org.apache.solr.search.SyntaxError: 
Cannot parse 'рики\-таки\(-т -а -ви)': Encountered  ) )  at line 1, 
column 21.
Was expecting one of:
EOF 
AND ...
OR ...
NOT ...
+ ...
- ...
BAREOPER ...
( ...
* ...
^ ...
QUOTED ...
TERM ...
FUZZY_SLOP ...
PREFIXTERM ...
WILDTERM ...
REGEXPTERM ...
[ ...
{ ...
LPARAMS ...
NUMBER ...

at 
org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:147)
at 
org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:111)
at 
org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:203)
at 
org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:180)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:208)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1816)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:448)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:269)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at 
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)
at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
at 
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: org.apache.solr.search.SyntaxError: Cannot parse 'рики\-таки\(-т -а 
-ви)': Encountered  ) )  at line 1, column 21.
Was expecting one of:
EOF 
AND ...
OR ...
NOT ...
+ ...
- ...
BAREOPER ...
( ...
* ...
^ ...
QUOTED ...
TERM ...
FUZZY_SLOP ...
PREFIXTERM ...
WILDTERM ...
REGEXPTERM ...
[ ...
{ ...
LPARAMS ...
NUMBER ...

at 
org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:164)
at 
org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:72)
at org.apache.solr.search.QParser.getQuery(QParser.java:142)
at 
org.apache.solr.handler.component.QueryComponent.prepare(QueryComponent.java:117)
... 23 more
Caused by: org.apache.solr.parser.ParseException: Encountered  ) )  at 
line 1, column 21.
Was expecting one of:
EOF 
AND ...
OR ...
NOT ...
+ ...
- ...
BAREOPER ...
( ...
* ...
^ ...
QUOTED ...
TERM ...
FUZZY_SLOP ...
PREFIXTERM ...
WILDTERM ...
REGEXPTERM ...
[ ...
{ ...
LPARAMS ...
NUMBER ...

at 
org.apache.solr.parser.QueryParser.generateParseException(QueryParser.java:651)
at 
org.apache.solr.parser.QueryParser.jj_consume_token(QueryParser.java:533)
at org.apache.solr.parser.QueryParser.TopLevelQuery(QueryParser.java:98)
at 
org.apache.solr.parser.SolrQueryParserBase.parse(SolrQueryParserBase.java:160)
... 26 more
{code}

So, SpellCheckCollator generates a corrupted query for the original escaped 
query.
I have
{code}
solrQueryParser defaultOperator=AND/
{code}
in the schema, as well.

  was (Author:

[jira] [Comment Edited] (SOLR-4489) StringIndexOutOfBoundsException in SpellCheckComponent


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

Artem Lukanin edited comment on SOLR-4489 at 3/18/13 10:24 AM:
---

The same issue with wordbreak in Solr 4.1:

{code}params={spellcheck=trueindent=trueq=calvin\+harris\+feat\+ne\+yospellcheck.q=calvin\+harris\+feat\+ne\+yowt=xml}

SEVERE: null:java.lang.StringIndexOutOfBoundsException: String index out of 
range: 25
at 
java.lang.AbstractStringBuilder.charAt(AbstractStringBuilder.java:174)
at java.lang.StringBuilder.charAt(StringBuilder.java:55)
at 
org.apache.solr.spelling.SpellCheckCollator.getCollation(SpellCheckCollator.java:164)
at 
org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:75)
at 
org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:203)
at 
org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:180)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:208)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1816)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:448)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:269)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at 
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)
at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
at 
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}

If I set
str name=combineWordsfalse/str
the exception disappears.

  was (Author: alukanin):
The same issue with wordbreak in Solr 4.1:

params={spellcheck=trueindent=trueq=calvin\+harris\+feat\+ne\+yospellcheck.q=calvin\+harris\+feat\+ne\+yowt=xml}

SEVERE: null:java.lang.StringIndexOutOfBoundsException: String index out of 
range: 25
at 
java.lang.AbstractStringBuilder.charAt(AbstractStringBuilder.java:174)
at java.lang.StringBuilder.charAt(StringBuilder.java:55)
at 
org.apache.solr.spelling.SpellCheckCollator.getCollation(SpellCheckCollator.java:164)
at 
org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:75)
at 
org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:203)
at 
org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:180)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:208)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1816)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:448)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:269)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at

[jira] [Comment Edited] (SOLR-4489) StringIndexOutOfBoundsException in SpellCheckComponent


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

Artem Lukanin edited comment on SOLR-4489 at 3/18/13 10:24 AM:
---

The same issue with wordbreak in Solr 4.1:

{code}params={spellcheck=trueindent=trueq=calvin\+harris\+feat\+ne\+yospellcheck.q=calvin\+harris\+feat\+ne\+yowt=xml}

SEVERE: null:java.lang.StringIndexOutOfBoundsException: String index out of 
range: 25
at 
java.lang.AbstractStringBuilder.charAt(AbstractStringBuilder.java:174)
at java.lang.StringBuilder.charAt(StringBuilder.java:55)
at 
org.apache.solr.spelling.SpellCheckCollator.getCollation(SpellCheckCollator.java:164)
at 
org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:75)
at 
org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:203)
at 
org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:180)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:208)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1816)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:448)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:269)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at 
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1002)
at 
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:585)
at 
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
{code}

If I set
{code}
str name=combineWordsfalse/str
{code}
the exception disappears.

  was (Author: alukanin):
The same issue with wordbreak in Solr 4.1:

{code}params={spellcheck=trueindent=trueq=calvin\+harris\+feat\+ne\+yospellcheck.q=calvin\+harris\+feat\+ne\+yowt=xml}

SEVERE: null:java.lang.StringIndexOutOfBoundsException: String index out of 
range: 25
at 
java.lang.AbstractStringBuilder.charAt(AbstractStringBuilder.java:174)
at java.lang.StringBuilder.charAt(StringBuilder.java:55)
at 
org.apache.solr.spelling.SpellCheckCollator.getCollation(SpellCheckCollator.java:164)
at 
org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:75)
at 
org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:203)
at 
org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:180)
at 
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:208)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1816)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:448)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:269)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at

[jira] [Commented] (LUCENE-4713) SPI: Allow fallback to default ClassLoader if Thread#getContextClassLoader fails


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

Commit Tag Bot commented on LUCENE-4713:


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

 LUCENE-4713: Move changes entry


 SPI: Allow fallback to default ClassLoader if Thread#getContextClassLoader 
 fails
 

 Key: LUCENE-4713
 URL: https://issues.apache.org/jira/browse/LUCENE-4713
 Project: Lucene - Core
  Issue Type: Improvement
Affects Versions: 4.0, 4.1, 4.2
Reporter: Christian Kohlschütter
Assignee: Uwe Schindler
Priority: Minor
  Labels: ClassLoader, Thread
 Fix For: 5.0, 4.3, 4.2.1

 Attachments: LUCENE-4713.patch, LUCENE-4713.patch, LUCENE-4713.patch, 
 LUCENE-4713.patch, LUCENE-4713.patch, LUCENE-4713.patch, LUCENE-4713.patch, 
 LuceneContextClassLoader.patch


 NOTE: This issue has been renamed from:
 Replace calls to Thread#getContextClassLoader with the ClassLoader of the 
 current class
 because the revised patch provides a clean fallback path.
 I am not sure whether it is a design decision or if we can indeed consider 
 this a bug:
 In core and analysis-common some classes provide on-demand class loading 
 using SPI. In NamedSPILoader, SPIClassIterator, ClasspathResourceLoader and 
 AnalysisSPILoader there are constructors that use the Thread's context 
 ClassLoader by default whenever no particular other ClassLoader was specified.
 Unfortunately this does not work as expected when the Thread's ClassLoader 
 can't see the required classes that are instantiated downstream with the help 
 of Class.forName (e.g., Codecs, Analyzers, etc.).
 That's what happened to us here. We currently experiment with running Lucene 
 2.9 and 4.x in one JVM, both being separated by custom ClassLoaders, each 
 seeing only the corresponding Lucene version and the upstream classpath.
 While NamedSPILoader and company get successfully loaded by our custom 
 ClassLoader, their instantiation fails because our Thread's 
 Context-ClassLoader cannot find the additionally required classes.
 We could probably work-around this by using Thread#setContextClassLoader at 
 construction time (and quickly reverting back afterwards), but I have the 
 impression this might just hide the actual problem and cause further trouble 
 when lazy-loading classes later on, and potentially from another Thread.
 Removing the call to Thread#getContextClassLoader would also align with the 
 behavior of AttributeSource.DEFAULT_ATTRIBUTE_FACTORY, which in fact uses 
 Attribute#getClass().getClassLoader() instead.
 A simple patch is attached. 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] (LUCENE-4713) SPI: Allow fallback to default ClassLoader if Thread#getContextClassLoader fails


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

Commit Tag Bot commented on LUCENE-4713:


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

Merged revision(s) 1457697 from lucene/dev/trunk:
LUCENE-4713: Move changes entry


 SPI: Allow fallback to default ClassLoader if Thread#getContextClassLoader 
 fails
 

 Key: LUCENE-4713
 URL: https://issues.apache.org/jira/browse/LUCENE-4713
 Project: Lucene - Core
  Issue Type: Improvement
Affects Versions: 4.0, 4.1, 4.2
Reporter: Christian Kohlschütter
Assignee: Uwe Schindler
Priority: Minor
  Labels: ClassLoader, Thread
 Fix For: 5.0, 4.3, 4.2.1

 Attachments: LUCENE-4713.patch, LUCENE-4713.patch, LUCENE-4713.patch, 
 LUCENE-4713.patch, LUCENE-4713.patch, LUCENE-4713.patch, LUCENE-4713.patch, 
 LuceneContextClassLoader.patch


 NOTE: This issue has been renamed from:
 Replace calls to Thread#getContextClassLoader with the ClassLoader of the 
 current class
 because the revised patch provides a clean fallback path.
 I am not sure whether it is a design decision or if we can indeed consider 
 this a bug:
 In core and analysis-common some classes provide on-demand class loading 
 using SPI. In NamedSPILoader, SPIClassIterator, ClasspathResourceLoader and 
 AnalysisSPILoader there are constructors that use the Thread's context 
 ClassLoader by default whenever no particular other ClassLoader was specified.
 Unfortunately this does not work as expected when the Thread's ClassLoader 
 can't see the required classes that are instantiated downstream with the help 
 of Class.forName (e.g., Codecs, Analyzers, etc.).
 That's what happened to us here. We currently experiment with running Lucene 
 2.9 and 4.x in one JVM, both being separated by custom ClassLoaders, each 
 seeing only the corresponding Lucene version and the upstream classpath.
 While NamedSPILoader and company get successfully loaded by our custom 
 ClassLoader, their instantiation fails because our Thread's 
 Context-ClassLoader cannot find the additionally required classes.
 We could probably work-around this by using Thread#setContextClassLoader at 
 construction time (and quickly reverting back afterwards), but I have the 
 impression this might just hide the actual problem and cause further trouble 
 when lazy-loading classes later on, and potentially from another Thread.
 Removing the call to Thread#getContextClassLoader would also align with the 
 behavior of AttributeSource.DEFAULT_ATTRIBUTE_FACTORY, which in fact uses 
 Attribute#getClass().getClassLoader() instead.
 A simple patch is attached. 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] (LUCENE-4848) Add Directory implementations using NIO2 APIs

2013-03-18 Thread Michael Poindexter (JIRA)

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

Michael Poindexter commented on LUCENE-4848:

No problem, I'll produce a patch against trunk that just changes the existing
directory implementations as little as possible.

Two questions:
1.) Since this changes the file writing behavior for NIOFSDirectory and
MMapDirectory (writes can now throw a ClosedChannelException if the thread is
interrupted, where I believe they couldn't before) should the changes be
controllable via a flag? Or should I just not change how writes are done for
these two classes (since it shouldn't be necessary to delete a file while it is
open for write, only if it is open read)

2.) I was using a Path instead of a File internally to represent the directory
location. This is somewhat nice in that it works with the Java 7 pluggable
filesystems implementation (i.e. to zip up an index one could just use the zip
filesystem provider with a directory and then do a Directory.copyTo). I assume
you want to not add a dependency on using a Path since that would change the
return type of FSDirectory.getDirectory()?

Add Directory implementations using NIO2 APIs
-

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

[jira] [Commented] (LUCENE-4848) Add Directory implementations using NIO2 APIs

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

Uwe Schindler commented on LUCENE-4848:
---

About 2: I am fine with using Path. When we are on Java 7, Path is fine to hold
the pointer to the directory. Of course FSDirectory could add another ctor, but
not replace the File-based ones. I think you current code does the right thing.

About writing: I know, you changed the whole FSDirectory base class to use
Channel. Maybe keep the base class mostly as it is (with a generic descriptor
parameter, that can be a RAF or Channel). I would prefer to make writing for
now use the RAF as before, but provide a channel-based impl, too?

About 1: The problem with interruptions is a bigger one - we should avoid that
any Directory implementation in Lucene is reacting to interruptions and produce
failures. We had lots of bug reports (regards a bug in Sun's original
implementation, that auto-closed a channel when interrupted). So in general,
interrupted file io in lucene should be repeated.

I will now setup Java 7 build for trunk and after short confirmation from the
mailing lists, I will move Lucene trunk's build to require Java 7!

Add Directory implementations using NIO2 APIs
-

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

[jira] [Assigned] (LUCENE-4747) java7 as a minimum requirement for lucene 5


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

Uwe Schindler reassigned LUCENE-4747:
-

Assignee: Uwe Schindler

 java7 as a minimum requirement for lucene 5
 ---

 Key: LUCENE-4747
 URL: https://issues.apache.org/jira/browse/LUCENE-4747
 Project: Lucene - Core
  Issue Type: Task
Affects Versions: 5.0
Reporter: Robert Muir
Assignee: Uwe Schindler
 Fix For: 5.0

 Attachments: LUCENE-4747.patch


 Spinoff from LUCENE-4746. 
 I propose we make this change on trunk only. 

--
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-4747) java7 as a minimum requirement for lucene 5


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

Uwe Schindler commented on LUCENE-4747:
---

We have the first issue with FSDirectpry implementations that makes the move to 
Java 7 needed: LUCENE-4848

I took this issue and will setup the basic Java 7 support with Robert's patch.

 java7 as a minimum requirement for lucene 5
 ---

 Key: LUCENE-4747
 URL: https://issues.apache.org/jira/browse/LUCENE-4747
 Project: Lucene - Core
  Issue Type: Task
Affects Versions: 5.0
Reporter: Robert Muir
Assignee: Uwe Schindler
 Fix For: 5.0

 Attachments: LUCENE-4747.patch


 Spinoff from LUCENE-4746. 
 I propose we make this change on trunk only. 

--
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-4847) Sorter API: Fully reuse docs enums


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

Shai Erera commented on LUCENE-4847:


looks good!

 Sorter API: Fully reuse docs enums
 --

 Key: LUCENE-4847
 URL: https://issues.apache.org/jira/browse/LUCENE-4847
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: 4.3

 Attachments: LUCENE-4847.patch


 SortingAtomicReader reuses the filtered docs enums but not the wrapper. In 
 the case of SortingAtomicReader this can be a problem because the wrappers 
 are heavyweight (they load the whole postings list into memory), so an index 
 with many terms with high freqs will make the JVM allocate a lot of memory 
 when browsing the postings lists.

--
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] (LUCENE-4747) java7 as a minimum requirement for lucene 5


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

Uwe Schindler updated LUCENE-4747:
--

Attachment: LUCENE-4747.patch

Updated patch (the build fails now when java 6 is used before even compiling). 
This is now possible by the new Java detection added in Lucene trunk/4.x after 
this issue was opened and the initial patch was submitted:

{noformat}
BUILD FAILED
C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr3\build.xml:249: The 
following error occurred while executing this line:
C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr3\lucene\build.xml:23: The 
following error occurred while executing this line:
C:\Users\Uwe 
Schindler\Projects\lucene\trunk-lusolr3\lucene\common-build.xml:285: Minimum 
supported Java version is 1.7.

Total time: 0 seconds
{noformat}

 java7 as a minimum requirement for lucene 5
 ---

 Key: LUCENE-4747
 URL: https://issues.apache.org/jira/browse/LUCENE-4747
 Project: Lucene - Core
  Issue Type: Task
Affects Versions: 5.0
Reporter: Robert Muir
Assignee: Uwe Schindler
 Fix For: 5.0

 Attachments: LUCENE-4747.patch, LUCENE-4747.patch


 Spinoff from LUCENE-4746. 
 I propose we make this change on trunk only. 

--
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] (LUCENE-4258) Incremental Field Updates through Stacked Segments

2013-03-18 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.branch.2.patch

Updated patch over branch after merging with trunk. New tests, still with bugs 
in handling replacements.

 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
 Fix For: 4.3

 Attachments: IncrementalFieldUpdates.odp, 
 LUCENE-4258-API-changes.patch, LUCENE-4258.branch.1.patch, 
 LUCENE-4258.branch.2.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] [Commented] (LUCENE-4848) Add Directory implementations using NIO2 APIs

2013-03-18 Thread Michael Poindexter (JIRA)

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

Michael Poindexter commented on LUCENE-4848:

OK, I will use Path, and produce 2 IndexInputs, one that uses a RAF (used by
default), and another that uses a Channel that share most of their code (I will
just do one super class with hooks for every place that depends on the actual
descriptor parameter and two subclasses).

I'll see if there is existing code in 5.x that is calling
FSDirectory.getDirectory() that depends on that being a File. If so, I will
not change it to return a Path, but rather introduce a new method
getDirectoryPath().

I think it's not a bug that the channel is auto-closed when interrupted, but
rather documented behavior (in InterruptibleChannel). Not trying to nitpick,
but just point out that this behavior is unlikely to change in the future since
it's how it's intended to work.

We could pretty easily retry when we get a ClosedByInterruptException, but do
you want that to happen as part of this patch or as another issue? I think
maybe that should go in as a separate patch since I think to make it work
properly you would have to make FSIndexInput.clone() open a new FileChannel
(essentially duplicating the file descriptor per-thread...that way when the
descriptor is closed due to an interrupt you only have to worry about reopening
that thread's FD, not all threads sharing the same FD).

Add Directory implementations using NIO2 APIs
-

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

[JENKINS] Lucene-Solr-trunk-Windows ([[ Exception while replacing ENV. Please report this as a bug. ]]

2013-03-18 Thread Policeman Jenkins Server

{{ java.lang.NullPointerException }})
 - Build # 2666 - Still Failing!
MIME-Version: 1.0
Content-Type: multipart/mixed; 
boundary==_Part_0_281965659.1363607066525
X-Jenkins-Job: Lucene-Solr-trunk-Windows
X-Jenkins-Result: FAILURE
Precedence: bulk

--=_Part_0_281965659.1363607066525
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/2666/
Java: [[ Exception while replacing ENV. Please report this as a bug. ]]
{{ java.lang.NullPointerException }}

No tests ran.

Build Log:
[...truncated 9 lines...]
FATAL: hudson.remoting.RequestAbortedException: java.net.SocketException: 
Connection reset
hudson.remoting.RequestAbortedException: 
hudson.remoting.RequestAbortedException: java.net.SocketException: Connection 
reset
at hudson.remoting.Request.call(Request.java:174)
at hudson.remoting.Channel.call(Channel.java:672)
at hudson.FilePath.act(FilePath.java:854)
at hudson.FilePath.act(FilePath.java:838)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:843)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:781)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1353)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:689)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:594)
at hudson.model.Run.execute(Run.java:1567)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:237)
Caused by: hudson.remoting.RequestAbortedException: java.net.SocketException: 
Connection reset
at hudson.remoting.Request.abort(Request.java:299)
at hudson.remoting.Channel.terminate(Channel.java:732)
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:69)
Caused by: java.net.SocketException: Connection reset
at java.net.SocketInputStream.read(SocketInputStream.java:168)
at java.io.FilterInputStream.read(FilterInputStream.java:116)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
at 
java.io.ObjectInputStream$PeekInputStream.peek(ObjectInputStream.java:2248)
at 
java.io.ObjectInputStream$BlockDataInputStream.peek(ObjectInputStream.java:2541)
at 
java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2551)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1296)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)
at hudson.remoting.Command.readFrom(Command.java:92)
at 
hudson.remoting.ClassicCommandTransport.read(ClassicCommandTransport.java:59)
at 
hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48)


--=_Part_0_281965659.1363607066525--

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

[jira] [Commented] (LUCENE-4848) Add Directory implementations using NIO2 APIs


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

Robert Muir commented on LUCENE-4848:
-

{quote}
We could pretty easily retry when we get a ClosedByInterruptException, but do 
you want that to happen as part of this patch or as another issue?
{quote}

please no!


 Add Directory implementations using NIO2 APIs
 -

 Key: LUCENE-4848
 URL: https://issues.apache.org/jira/browse/LUCENE-4848
 Project: Lucene - Core
  Issue Type: Task
Reporter: Michael Poindexter
Assignee: Uwe Schindler
Priority: Minor
 Attachments: jdk7directory.zip


 I have implemented 3 Directory subclasses using NIO2 API's (available on 
 JDK7).  These may be suitable for inclusion in a Lucene contrib module.
 See the mailing list at http://lucene.markmail.org/thread/lrv7miivzmjm3ml5 
 for more details about this code and the advantages it provides.
 The code is attached as a zip to this issue.  I'll be happy to make any 
 changes requested.  I've included some minimal smoke tests, but any help in 
 how to use the normal Lucene tests to perform more thorough testing would be 
 appreciated.

--
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-4747) java7 as a minimum requirement for lucene 5


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

Uwe Schindler commented on LUCENE-4747:
---

I changed all Jenkins instances I had access to. Currently Simonw should 
disable the flonkins Java 6 Job for Lucene trunk.

I will commit the patch soon!

 java7 as a minimum requirement for lucene 5
 ---

 Key: LUCENE-4747
 URL: https://issues.apache.org/jira/browse/LUCENE-4747
 Project: Lucene - Core
  Issue Type: Task
Affects Versions: 5.0
Reporter: Robert Muir
Assignee: Uwe Schindler
 Fix For: 5.0

 Attachments: LUCENE-4747.patch, LUCENE-4747.patch


 Spinoff from LUCENE-4746. 
 I propose we make this change on trunk only. 

--
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-4848) Add Directory implementations using NIO2 APIs


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

Uwe Schindler commented on LUCENE-4848:
---

Same here. In my opinion writing should use RAF as this is most compatible.

 Add Directory implementations using NIO2 APIs
 -

 Key: LUCENE-4848
 URL: https://issues.apache.org/jira/browse/LUCENE-4848
 Project: Lucene - Core
  Issue Type: Task
Reporter: Michael Poindexter
Assignee: Uwe Schindler
Priority: Minor
 Attachments: jdk7directory.zip


 I have implemented 3 Directory subclasses using NIO2 API's (available on 
 JDK7).  These may be suitable for inclusion in a Lucene contrib module.
 See the mailing list at http://lucene.markmail.org/thread/lrv7miivzmjm3ml5 
 for more details about this code and the advantages it provides.
 The code is attached as a zip to this issue.  I'll be happy to make any 
 changes requested.  I've included some minimal smoke tests, but any help in 
 how to use the normal Lucene tests to perform more thorough testing would be 
 appreciated.

--
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-4848) Add Directory implementations using NIO2 APIs

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

Uwe Schindler commented on LUCENE-4848:
---

bq. I think maybe that should go in as a separate patch since I think to make
it work properly you would have to make FSIndexInput.clone() open a new
FileChannel (essentially duplicating the file descriptor per-thread...that way
when the descriptor is closed due to an interrupt you only have to worry about
reopening that thread's FD, not all threads sharing the same FD).

We cannot do this, as Lucene *never* closes clones. This would be the grave for
file handles! Lucene would eat up all file handles in milliseconds :-)

Add Directory implementations using NIO2 APIs
-

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

[jira] [Commented] (LUCENE-4848) Add Directory implementations using NIO2 APIs

2013-03-18 Thread Michael Poindexter (JIRA)

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

Michael Poindexter commented on LUCENE-4848:

That would be bad :) I was under the impression that clones were actually
closed, but the close method just checked if it was a clone and if so didn't
actually do anything. Thanks for pointing this out.

In that case there's really not much that can be done to avoid
ClosedByInterruptExceptions. We have one FD that's shared across threads, the
JDK closed it, and it we were to open a new one there's no place to release the
resource. IMO, this would indicate that perhaps clones should in fact be
closed, but I don't know enough about why they are not to have a good opinion
:-)

Add Directory implementations using NIO2 APIs
-

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

[jira] [Commented] (LUCENE-4848) Add Directory implementations using NIO2 APIs

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

Robert Muir commented on LUCENE-4848:
-

I would be against it myself. It seems users cannot even manage open/close on
IndexReader and IndexWriter today. So its too much that they would have to
close() scorers, docsenum, and so on.

Personally i'm not worried about ClosedByInterruptExceptions: just dont
interrupt threads doing searches. I'm also not willing to pay the cost of
additional file handles if i'm not interrupt()'ing...why should i?

But to me this is all unrelated to this issue, its been discussed over and over
elsewhere and the problem already exists today.

Add Directory implementations using NIO2 APIs
-

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

[jira] [Commented] (LUCENE-4848) Add Directory implementations using NIO2 APIs


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

Uwe Schindler commented on LUCENE-4848:
---

You see.

So I wait for a minimal patch! I just want as a first step:
- minimal changes (no changes at all to SimpleFSDir)
- MMapDir changes are the simpliest
- NIOFSDir need more changes, because it curretntly relies on FSDir's stpid RAF 
(Robert Muir already has a patch to not rely on RAF in NIOFSDir already), have 
to lookup the issue
- Only use Path in the impl details for now - more changes should be separete!
- Add a separate new class for the fake-ASYNC one

 Add Directory implementations using NIO2 APIs
 -

 Key: LUCENE-4848
 URL: https://issues.apache.org/jira/browse/LUCENE-4848
 Project: Lucene - Core
  Issue Type: Task
Reporter: Michael Poindexter
Assignee: Uwe Schindler
Priority: Minor
 Attachments: jdk7directory.zip


 I have implemented 3 Directory subclasses using NIO2 API's (available on 
 JDK7).  These may be suitable for inclusion in a Lucene contrib module.
 See the mailing list at http://lucene.markmail.org/thread/lrv7miivzmjm3ml5 
 for more details about this code and the advantages it provides.
 The code is attached as a zip to this issue.  I'll be happy to make any 
 changes requested.  I've included some minimal smoke tests, but any help in 
 how to use the normal Lucene tests to perform more thorough testing would be 
 appreciated.

--
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] (LUCENE-4848) Add Directory implementations using NIO2 APIs


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

Uwe Schindler edited comment on LUCENE-4848 at 3/18/13 12:14 PM:
-

You see.

So I wait for a minimal patch! I just want as a first step:
- minimal changes (no changes at all to SimpleFSDir)
- MMapDir changes are the simpliest
- NIOFSDir need more changes, because it curretntly relies on FSDir's stupid 
RAF (Robert Muir already has a patch to not rely on RAF in NIOFSDir already), 
have to lookup the issue
- Only use Path in the impl details for now - more changes should be separate!
- Add a separate new class for the fake-ASYNC one

  was (Author: thetaphi):
You see.

So I wait for a minimal patch! I just want as a first step:
- minimal changes (no changes at all to SimpleFSDir)
- MMapDir changes are the simpliest
- NIOFSDir need more changes, because it curretntly relies on FSDir's stpid RAF 
(Robert Muir already has a patch to not rely on RAF in NIOFSDir already), have 
to lookup the issue
- Only use Path in the impl details for now - more changes should be separete!
- Add a separate new class for the fake-ASYNC one
  
 Add Directory implementations using NIO2 APIs
 -

 Key: LUCENE-4848
 URL: https://issues.apache.org/jira/browse/LUCENE-4848
 Project: Lucene - Core
  Issue Type: Task
Reporter: Michael Poindexter
Assignee: Uwe Schindler
Priority: Minor
 Attachments: jdk7directory.zip


 I have implemented 3 Directory subclasses using NIO2 API's (available on 
 JDK7).  These may be suitable for inclusion in a Lucene contrib module.
 See the mailing list at http://lucene.markmail.org/thread/lrv7miivzmjm3ml5 
 for more details about this code and the advantages it provides.
 The code is attached as a zip to this issue.  I'll be happy to make any 
 changes requested.  I've included some minimal smoke tests, but any help in 
 how to use the normal Lucene tests to perform more thorough testing would be 
 appreciated.

--
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

2013-03-18 Thread Shahar Davidson (JIRA)


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

Shahar Davidson commented on SOLR-2894:
---

Hi Andrew (and Chris), I just wanted to report a problem that we found in the 
patch from Jan 14th.

In short, the problem seems to be related to facet.limit and the symptom is 
that a distributed pivot returns less terms than expected.

Here's a simple scenario:
If I run a (non-distributed) pivot such as:
{noformat}http://myHost:8999/solr/core-A/select?q=*:*wt=xmlfacet=truefacet.pivot=field_A,field_Brows=0facet.limit=-1facet.sort=count{noformat}
then I would get N terms for field_A. (where, in my case, N is in the thousands)

BUT, if I run a distributed pivot such as:
{noformat}http://myHost:8999/solr/core-B/select?shards=myHost:8999/solr/core-Aq=*:*wt=xmlfacet=truefacet.pivot=field_A,field_Brows=0facet.limit=-1facet.sort=count{noformat}
then I would get _at most_ 160 terms for field_A.
(Why exactly 160?? I have no idea)

On the other hand, if I use f.field_name.facet.limit=-1 then things work as 
expected. For example:
{noformat}http://myHost:8999/solr/core-B/select?shards=myHost:8999/solr/core-Aq=*:*wt=xmlfacet=truefacet.pivot=field_A,field_Brows=0f.field_A.facet.limit=-1f.field_B.facet.limit=-1facet.sort=count{noformat}
This will return exactly N terms for field_A as expected.

I'll appreciate your help with this.

Shahar.

 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.3

 Attachments: SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, 
 SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, 
 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

[JENKINS] Lucene-trunk-Linux-Java6-64-test-only - Build # 27230 - Failure!

Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java6-64-test-only/27230/

No tests ran.

Build Log:
[...truncated 57 lines...]
BUILD FAILED
/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java6-64-test-only/checkout/lucene/build.xml:23:
 The following error occurred while executing this line:
/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java6-64-test-only/checkout/lucene/common-build.xml:285:
 Minimum supported Java version is 1.7.

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure




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

[jira] [Commented] (LUCENE-4747) java7 as a minimum requirement for lucene 5


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

Commit Tag Bot commented on LUCENE-4747:


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

LUCENE-4747: Move to Java 7 in trunk


 java7 as a minimum requirement for lucene 5
 ---

 Key: LUCENE-4747
 URL: https://issues.apache.org/jira/browse/LUCENE-4747
 Project: Lucene - Core
  Issue Type: Task
Affects Versions: 5.0
Reporter: Robert Muir
Assignee: Uwe Schindler
 Fix For: 5.0

 Attachments: LUCENE-4747.patch, LUCENE-4747.patch


 Spinoff from LUCENE-4746. 
 I propose we make this change on trunk only. 

--
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-trunk-Linux-Java6-64-test-only - Build # 27231 - Still Failing!

Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java6-64-test-only/27231/

No tests ran.

Build Log:
[...truncated 16 lines...]
BUILD FAILED
/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java6-64-test-only/checkout/lucene/build.xml:23:
 The following error occurred while executing this line:
/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java6-64-test-only/checkout/lucene/common-build.xml:285:
 Minimum supported Java version is 1.7.

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure




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

[JENKINS] Lucene-trunk-Linux-Java6-64-test-only - Build # 27232 - Still Failing!

Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java6-64-test-only/27232/

No tests ran.

Build Log:
[...truncated 15 lines...]
BUILD FAILED
/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java6-64-test-only/checkout/lucene/build.xml:23:
 The following error occurred while executing this line:
/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java6-64-test-only/checkout/lucene/common-build.xml:285:
 Minimum supported Java version is 1.7.

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure




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

Re: Welcome Tommaso Teofili to the PMC

Welcome!

On Sun, Mar 17, 2013 at 11:04 AM, Steve Rowe sar...@gmail.com wrote:
 I'm pleased to announce that Tommaso Teofili has accepted the PMC's 
 invitation to join.

 Welcome Tommaso!

 - Steve
 -
 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

[JENKINS] Lucene-trunk-Linux-Java6-64-test-only - Build # 27233 - Still Failing!

Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java6-64-test-only/27233/

No tests ran.

Build Log:
[...truncated 15 lines...]
BUILD FAILED
/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java6-64-test-only/checkout/lucene/build.xml:23:
 The following error occurred while executing this line:
/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java6-64-test-only/checkout/lucene/common-build.xml:285:
 Minimum supported Java version is 1.7.

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure




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

[JENKINS] Lucene-trunk-Linux-Java6-64-test-only - Build # 27234 - Still Failing!

Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java6-64-test-only/27234/

No tests ran.

Build Log:
[...truncated 15 lines...]
BUILD FAILED
/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java6-64-test-only/checkout/lucene/build.xml:23:
 The following error occurred while executing this line:
/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java6-64-test-only/checkout/lucene/common-build.xml:285:
 Minimum supported Java version is 1.7.

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure




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

[JENKINS] Lucene-trunk-Linux-Java6-64-test-only - Build # 27235 - Still Failing!

Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java6-64-test-only/27235/

No tests ran.

Build Log:
[...truncated 15 lines...]
BUILD FAILED
/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java6-64-test-only/checkout/lucene/build.xml:23:
 The following error occurred while executing this line:
/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java6-64-test-only/checkout/lucene/common-build.xml:285:
 Minimum supported Java version is 1.7.

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure




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

Re: Welcome Tommaso Teofili to the PMC

2013-03-18 Thread Jan Høydahl

Welcome Tommaso!

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
Solr Training - www.solrtraining.com

17. mars 2013 kl. 16:04 skrev Steve Rowe sar...@gmail.com:

 I'm pleased to announce that Tommaso Teofili has accepted the PMC's 
 invitation to join.
 
 Welcome Tommaso!
 
 - Steve
 -
 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

Re: svn commit: r1457734 - in /lucene/dev/trunk: ./ dev-tools/eclipse/dot.settings/ dev-tools/maven/ dev-tools/scripts/ lucene/ lucene/core/src/java/org/apache/lucene/util/ lucene/tools/javadoc/ lucen

On Mon, Mar 18, 2013 at 8:28 AM,  uschind...@apache.org wrote:
 Modified: 
 lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/impl/XMLResponseParser.java
 URL: 
 http://svn.apache.org/viewvc/lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/impl/XMLResponseParser.java?rev=1457734r1=1457733r2=1457734view=diff
 ==
 --- 
 lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/impl/XMLResponseParser.java
  (original)
 +++ 
 lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/impl/XMLResponseParser.java
  Mon Mar 18 12:28:52 2013
 @@ -55,6 +55,7 @@ public class XMLResponseParser extends R
static {
  factory = XMLInputFactory.newInstance();
  try {
 +  // nocommit: still true for 1.7?
// The java 1.6 bundled stax parser (sjsxp) does not currently have a 
 thread-safe
// XMLInputFactory, as that implementation tries to cache and reuse the
// XMLStreamReader.  Setting the parser-specific reuse-instance 
 property to false


Thanks for taking the issue Uwe. There were still some nocommits in
the patch, for xml-policeman review:

* 
solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimport/XPathRecordReader.java
* solr/core/src/java/org/apache/solr/handler/DocumentAnalysisRequestHandler.java
* solr/core/src/java/org/apache/solr/handler/loader/XMLLoader.java
* solr/solrj/src/java/org/apache/solr/client/solrj/impl/XMLResponseParser.java

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

[JENKINS] Lucene-trunk-Linux-Java6-64-test-only - Build # 27236 - Still Failing!

Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java6-64-test-only/27236/

No tests ran.

Build Log:
[...truncated 15 lines...]
BUILD FAILED
/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java6-64-test-only/checkout/lucene/build.xml:23:
 The following error occurred while executing this line:
/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java6-64-test-only/checkout/lucene/common-build.xml:285:
 Minimum supported Java version is 1.7.

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure




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

Re: JIRA cleanup inactive issues?

2013-03-18 Thread Jan Høydahl

Hey

Great spring cleaning work going on here :) I think it's the right approach.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
Solr Training - www.solrtraining.com

16. mars 2013 kl. 20:28 skrev Erick Erickson erickerick...@gmail.com:

 Jan:
 
 I've hit on a new policy when I closed a bunch of things today. For those 
 JIRAs that we decide NOT to close, I'm adding a comment explaining why I 
 didn't close it and/or inviting comment. That has the effect of removing the 
 JIRA from the query you provided and poking anyone still interested in it.
 
 FWIW,
 Erick
 
 
 On Thu, Feb 28, 2013 at 8:15 AM, Jan Høydahl jan@cominvent.com wrote:
 I did a really small bulk-change for the 10 oldest LUCENE/SOLR issues without 
 activity, and tagged them SPRING_CLEANING_2013
 
 That should spin off some activity, probably some will be closed due to 
 various reasons, and perhaps some will be revived?
 
 If this proves effective, I'll do a new bulk in a week or so for the 25 
 issues never touched since 2008. I think that portioning THIS out in time in 
 smaller chunks will gain more attention than a big bang thing.
 
 I'll probably also do some more manual inspection on some of the oldest which 
 are obviously not relevant any more.
 
 --
 Jan Høydahl, search solution architect
 Cominvent AS - www.cominvent.com
 Solr Training - www.solrtraining.com
 
 15. feb. 2013 kl. 01:24 skrev Jan Høydahl jan@cominvent.com:
 
  but arbitrarily deciding an issue should be closed just becuase it's old
  doesn't really make sense to me to me.
 
  That was never the suggestion either. More to get rid of all the noise 
  which is no longer relevant, neither to the issue creator or anyone else, 
  then it's easier to browse through open issues knowing that someone 
  actually care about those issues being fixed.
 
  It's great that Erick and others will contribute, but we save a lot of work 
  distributing it to stakeholders first, then those interested can manually 
  go through the remaining based on the tag.
 
  The real number of irrelevant Open issues is probably larger, since some 
  issues are Updated last year, but those updates are also Bulk fix-version 
  change or similar, not real activity. But that's for another day...
 
  The bulk update process is fairly simple. I'll volunteer. I propose to 
  simply add a Comment to those 739 issues (Unfortunately there seems to be 
  no way to bulk ADD a Label, it would delete all existing ones, so that's 
  why it's in the comment text):
 
 
  This issue has been inactive for more than a year. Please close if it's no 
  longer relevant/needed, or bring it up to date if you intend to work on it. 
  INACTIVITY_REMINDER_20130215
 
 
  Uwe, if it's simple to disconnect the mailinglist temporarily then that 
  would be great.
 
  --
  Jan Høydahl, search solution architect
  Cominvent AS - www.cominvent.com
  Solr Training - www.solrtraining.com
 
  14. feb. 2013 kl. 19:33 skrev Chris Hostetter hossman_luc...@fucit.org:
 
 
  : Why should an issue be closed just because it's been open for N years?
   ...
  : Why do we care about the number of open issues?  Who is using this 
  metric?
 
  +1
 
  Using a filter of has not been modified in X days to help find issues
  that are *likeley* no longer relevant seems fine, and then they can
  quickly be reviewed/closed if they are about code that no longer exists,
  or have already been implemented/fixed in another way.
 
  but arbitrarily deciding an issue should be closed just becuase it's old
  doesn't really make sense to me to me.
 
 
  -Hoss
 
  -
  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

GSoC 2013

2013-03-18 Thread Raimon Bosch

Hi all,

I would be interested in doing a Google Summer of Code this year with
Lucene or Solr. My master thesis topic is about Sentiment analysis, there
is any research in this direction inside Solr and Lucene? If there is any
other interesting topic I would be open to discuss.

Thanks in advance,
Raimon Bosch.

[JENKINS] Lucene-trunk-Linux-Java6-64-test-only - Build # 27237 - Still Failing!

Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java6-64-test-only/27237/

No tests ran.

Build Log:
[...truncated 18 lines...]
BUILD FAILED
/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java6-64-test-only/checkout/lucene/build.xml:23:
 The following error occurred while executing this line:
/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java6-64-test-only/checkout/lucene/common-build.xml:285:
 Minimum supported Java version is 1.7.

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure




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

[jira] [Commented] (LUCENE-4747) java7 as a minimum requirement for lucene 5


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

Commit Tag Bot commented on LUCENE-4747:


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

LUCENE-4747: Fix nocommits


 java7 as a minimum requirement for lucene 5
 ---

 Key: LUCENE-4747
 URL: https://issues.apache.org/jira/browse/LUCENE-4747
 Project: Lucene - Core
  Issue Type: Task
Affects Versions: 5.0
Reporter: Robert Muir
Assignee: Uwe Schindler
 Fix For: 5.0

 Attachments: LUCENE-4747.patch, LUCENE-4747.patch


 Spinoff from LUCENE-4746. 
 I propose we make this change on trunk only. 

--
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: svn commit: r1457734 - in /lucene/dev/trunk: ./ dev-tools/eclipse/dot.settings/ dev-tools/maven/ dev-tools/scripts/ lucene/ lucene/core/src/java/org/apache/lucene/util/ lucene/tools/javadoc/ lucen

My fault, fixed.

I also removed reflection in IOUtils, as we are now on Java 7.

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de


 -Original Message-
 From: Robert Muir [mailto:rcm...@gmail.com]
 Sent: Monday, March 18, 2013 2:03 PM
 To: dev@lucene.apache.org
 Cc: comm...@lucene.apache.org
 Subject: Re: svn commit: r1457734 - in /lucene/dev/trunk: ./ dev-
 tools/eclipse/dot.settings/ dev-tools/maven/ dev-tools/scripts/ lucene/
 lucene/core/src/java/org/apache/lucene/util/ lucene/tools/javadoc/
 lucene/tools/javadoc/java6/ lucene/tools/javadoc/java7/ solr
 
 On Mon, Mar 18, 2013 at 8:28 AM,  uschind...@apache.org wrote:
  Modified:
  lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/impl
  /XMLResponseParser.java
  URL:
  http://svn.apache.org/viewvc/lucene/dev/trunk/solr/solrj/src/java/org/
 
 apache/solr/client/solrj/impl/XMLResponseParser.java?rev=1457734r1=14
  57733r2=1457734view=diff
 
 ==
 
  
  ---
  lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/impl
  /XMLResponseParser.java (original)
  +++ lucene/dev/trunk/solr/solrj/src/java/org/apache/solr/client/solrj/
  +++ impl/XMLResponseParser.java Mon Mar 18 12:28:52 2013
  @@ -55,6 +55,7 @@ public class XMLResponseParser extends R
 static {
   factory = XMLInputFactory.newInstance();
   try {
  +  // nocommit: still true for 1.7?
 // The java 1.6 bundled stax parser (sjsxp) does not currently have a
 thread-safe
 // XMLInputFactory, as that implementation tries to cache and reuse
 the
 // XMLStreamReader.  Setting the parser-specific
  reuse-instance property to false
 
 
 Thanks for taking the issue Uwe. There were still some nocommits in the
 patch, for xml-policeman review:
 
 *
 solr/contrib/dataimporthandler/src/java/org/apache/solr/handler/dataimpo
 rt/XPathRecordReader.java
 *
 solr/core/src/java/org/apache/solr/handler/DocumentAnalysisRequestHand
 ler.java
 * solr/core/src/java/org/apache/solr/handler/loader/XMLLoader.java
 *
 solr/solrj/src/java/org/apache/solr/client/solrj/impl/XMLResponseParser.jav
 a
 
 -
 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] (LUCENE-4747) java7 as a minimum requirement for lucene 5


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

Commit Tag Bot commented on LUCENE-4747:


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

LUCENE-4747: Remove reflection from IOUtils for supressing caughth Exceptions


 java7 as a minimum requirement for lucene 5
 ---

 Key: LUCENE-4747
 URL: https://issues.apache.org/jira/browse/LUCENE-4747
 Project: Lucene - Core
  Issue Type: Task
Affects Versions: 5.0
Reporter: Robert Muir
Assignee: Uwe Schindler
 Fix For: 5.0

 Attachments: LUCENE-4747.patch, LUCENE-4747.patch


 Spinoff from LUCENE-4746. 
 I propose we make this change on trunk only. 

--
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-trunk-Linux-Java6-64-test-only - Build # 27238 - Still Failing!

Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java6-64-test-only/27238/

No tests ran.

Build Log:
[...truncated 16 lines...]
BUILD FAILED
/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java6-64-test-only/checkout/lucene/build.xml:23:
 The following error occurred while executing this line:
/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java6-64-test-only/checkout/lucene/common-build.xml:285:
 Minimum supported Java version is 1.7.

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure




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

[JENKINS] Lucene-trunk-Linux-Java6-64-test-only - Build # 27239 - Still Failing!

Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java6-64-test-only/27239/

No tests ran.

Build Log:
[...truncated 18 lines...]
BUILD FAILED
/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java6-64-test-only/checkout/lucene/build.xml:23:
 The following error occurred while executing this line:
/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java6-64-test-only/checkout/lucene/common-build.xml:285:
 Minimum supported Java version is 1.7.

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure




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

[jira] [Created] (SOLR-4606) Let test-framework provide random seed to HttpShardHandlerFactory

Robert Muir created SOLR-4606:
-

 Summary: Let test-framework provide random seed to 
HttpShardHandlerFactory
 Key: SOLR-4606
 URL: https://issues.apache.org/jira/browse/SOLR-4606
 Project: Solr
  Issue Type: Test
  Components: Tests
Reporter: Robert Muir


Currently this uses new Random(): I think this hurts the reproducibility of any 
distributed test failures.

--
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-4544) Allow HttpShardHandler to be reused better by subclasses of HttpShardHandlerFactory


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

Commit Tag Bot commented on SOLR-4544:
--

[trunk commit] Robert Muir
http://svn.apache.org/viewvc?view=revisionrevision=1457754

SOLR-4544: Refactor HttpShardHandlerFactory so load-balancing logic can be 
customized


 Allow HttpShardHandler to be reused better by subclasses of 
 HttpShardHandlerFactory
 ---

 Key: SOLR-4544
 URL: https://issues.apache.org/jira/browse/SOLR-4544
 Project: Solr
  Issue Type: Improvement
Reporter: Ryan Ernst
 Attachments: SOLR-4544.patch, SOLR-4544.patch


 I would like to have a custom ShardHandlerFactory, which has my own special 
 load balancing logic (among other things).  The HttpShardHandler is what 
 currently handles the parallelization of shard requests.  I would like to 
 reuse it, but it expects package private variables in HttpShardHandlerFactory 
 which it can reach back into for making load balancer requests and a 
 completion service.

--
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-trunk-Linux-Java6-64-test-only - Build # 27240 - Still Failing!

Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java6-64-test-only/27240/

No tests ran.

Build Log:
[...truncated 15 lines...]
BUILD FAILED
/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java6-64-test-only/checkout/lucene/build.xml:23:
 The following error occurred while executing this line:
/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java6-64-test-only/checkout/lucene/common-build.xml:285:
 Minimum supported Java version is 1.7.

Total time: 0 seconds
Build step 'Invoke Ant' marked build as failure
Archiving artifacts
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure




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

[jira] [Commented] (SOLR-3706) Ship setup to log with log4j.

2013-03-18 Thread Satheesh Akkinepally (JIRA)

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

Satheesh Akkinepally commented on SOLR-3706:

We got logback working on our jetty/solr installation. logBack also provides
configurable http access logs (log4j does not have this for jetty) out of the
box and it works great with jetty and solr. But yes for this to work, we had to
unwar the solr.war remove the native jdk logging jar and place the logBack
implementation in the war.
It would be good if we dont have to unwar and war and can use the solr.war out
of the box for any custom logging implementation that we want to use. Also, the
web app class loader seems to ignore the log4j implementation found in the
jetty lib if slf4j is available within the war.

Ship setup to log with log4j.
-

Key: SOLR-3706
URL: https://issues.apache.org/jira/browse/SOLR-3706
Project: Solr
Issue Type: Improvement
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
Fix For: 4.3, 5.0

Attachments: SOLR-3706-solr-log4j.patch, SOLR-3706-solr-log4j.patch

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

[jira] [Commented] (LUCENE-4847) Sorter API: Fully reuse docs enums


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

Commit Tag Bot commented on LUCENE-4847:


[trunk commit] Adrien Grand
http://svn.apache.org/viewvc?view=revisionrevision=1457760

LUCENE-4847: Sorter API: Fully reuse docs enums.



 Sorter API: Fully reuse docs enums
 --

 Key: LUCENE-4847
 URL: https://issues.apache.org/jira/browse/LUCENE-4847
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: 4.3

 Attachments: LUCENE-4847.patch


 SortingAtomicReader reuses the filtered docs enums but not the wrapper. In 
 the case of SortingAtomicReader this can be a problem because the wrappers 
 are heavyweight (they load the whole postings list into memory), so an index 
 with many terms with high freqs will make the JVM allocate a lot of memory 
 when browsing the postings lists.

--
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-4747) java7 as a minimum requirement for lucene 5


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

Uwe Schindler commented on LUCENE-4747:
---

The move is done.

Before resolving the issue I wanted the confirmation by Steven Rowe, if the 
Maven build is setup correctly (e.g. maven-enforcer-plugin,...).

 java7 as a minimum requirement for lucene 5
 ---

 Key: LUCENE-4747
 URL: https://issues.apache.org/jira/browse/LUCENE-4747
 Project: Lucene - Core
  Issue Type: Task
Affects Versions: 5.0
Reporter: Robert Muir
Assignee: Uwe Schindler
 Fix For: 5.0

 Attachments: LUCENE-4747.patch, LUCENE-4747.patch


 Spinoff from LUCENE-4746. 
 I propose we make this change on trunk only. 

--
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-trunk-Linux-Java6-64-test-only - Build # 27240 - Still Failing!

The Job was disabled by Simon, thanks!

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de


 -Original Message-
 From: buil...@flonkings.com [mailto:buil...@flonkings.com]
 Sent: Monday, March 18, 2013 2:28 PM
 To: dev@lucene.apache.org; sim...@apache.org
 Subject: [JENKINS] Lucene-trunk-Linux-Java6-64-test-only - Build # 27240 -
 Still Failing!
 
 Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java6-64-test-
 only/27240/
 
 No tests ran.
 
 Build Log:
 [...truncated 15 lines...]
 BUILD FAILED
 /var/lib/jenkins/workspace/Lucene-trunk-Linux-Java6-64-test-
 only/checkout/lucene/build.xml:23: The following error occurred while
 executing this line:
 /var/lib/jenkins/workspace/Lucene-trunk-Linux-Java6-64-test-
 only/checkout/lucene/common-build.xml:285: Minimum supported Java
 version is 1.7.
 
 Total time: 0 seconds
 Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording
 test results Email was triggered for: Failure Sending email for trigger: 
 Failure
 
 



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

[jira] [Commented] (LUCENE-4747) java7 as a minimum requirement for lucene 5


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

Uwe Schindler commented on LUCENE-4747:
---

I have to also investigate the clover build. The version of Clover we 
currently use is not compatible with Java 7, so we might need to upgrade.

 java7 as a minimum requirement for lucene 5
 ---

 Key: LUCENE-4747
 URL: https://issues.apache.org/jira/browse/LUCENE-4747
 Project: Lucene - Core
  Issue Type: Task
Affects Versions: 5.0
Reporter: Robert Muir
Assignee: Uwe Schindler
 Fix For: 5.0

 Attachments: LUCENE-4747.patch, LUCENE-4747.patch


 Spinoff from LUCENE-4746. 
 I propose we make this change on trunk only. 

--
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-4747) java7 as a minimum requirement for lucene 5

2013-03-18 Thread Adrien Grand (JIRA)


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

Adrien Grand commented on LUCENE-4747:
--

Maybe we should fix all places that should use Integer.compare/Long.compare/... 
too?

 java7 as a minimum requirement for lucene 5
 ---

 Key: LUCENE-4747
 URL: https://issues.apache.org/jira/browse/LUCENE-4747
 Project: Lucene - Core
  Issue Type: Task
Affects Versions: 5.0
Reporter: Robert Muir
Assignee: Uwe Schindler
 Fix For: 5.0

 Attachments: LUCENE-4747.patch, LUCENE-4747.patch


 Spinoff from LUCENE-4746. 
 I propose we make this change on trunk only. 

--
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-4605) Rollback does not work correctly.


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

Mark Miller updated SOLR-4605:
--

Summary: Rollback does not work correctly.  (was: SolrException: Error 
opening new searcher)

 Rollback does not work correctly.
 -

 Key: SOLR-4605
 URL: https://issues.apache.org/jira/browse/SOLR-4605
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.1, 4.2
 Environment: Ubuntu 12.04.2 LTS
Reporter: Mark S
Assignee: Mark Miller
  Labels: solrj
 Fix For: 4.3, 5.0

 Attachments: SOLR-4605.patch


 http://lucene.472066.n3.nabble.com/Solr-4-1-4-2-SolrException-Error-opening-new-searcher-td4046543.html
 I wrote a simple test to reproduce a very similar stack trace to the above 
 issue, where only some line numbers differences due to Solr 4.1 vs Solr 4.2.
 *Source of Exception*
 * 
 [http://svn.apache.org/viewvc/lucene/dev/tags/lucene_solr_4_1_0/solr/core/src/java/org/apache/solr/core/SolrCore.java?view=markup]
 * 
 [http://svn.apache.org/viewvc/lucene/dev/tags/lucene_solr_4_2_0/solr/core/src/java/org/apache/solr/core/SolrCore.java?view=markup]
 {code:java} 
 catch (Exception e) {
 throw new SolrException(SolrException.ErrorCode.SERVER_ERROR, Error 
 opening new searcher, e);
 }
 {code}
 Any ideas as to why the following happens?  Any help would be very 
 appreciated.
 * *The test case:*
 {code:java}
 @Test
 public void documentCommitAndRollbackTest() throws Exception {
 // Fix:  SolrException: Error opening new searcher
 server.rollback();
 server.commit();
 }
 {code}
 * *The similar stack trace (Which is repeated twice):*
 {quote}
 Mar 15, 2013 3:48:09 PM org.apache.solr.common.SolrException log
 SEVERE: org.apache.solr.common.SolrException: Error opening new searcher
 at org.apache.solr.core.SolrCore.openNewSearcher(SolrCore.java:1415)
 at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1527)
 at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1304)
 at 
 org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:570)
 at 
 org.apache.solr.update.processor.RunUpdateProcessor.processCommit(RunUpdateProcessorFactory.java:95)
 at 
 org.apache.solr.update.processor.UpdateRequestProcessor.processCommit(UpdateRequestProcessor.java:64)
 at 
 org.apache.solr.update.processor.DistributedUpdateProcessor.processCommit(DistributedUpdateProcessor.java:1055)
 at 
 org.apache.solr.update.processor.LogUpdateProcessor.processCommit(LogUpdateProcessorFactory.java:157)
 at 
 org.apache.solr.handler.RequestHandlerUtils.handleCommit(RequestHandlerUtils.java:69)
 at 
 org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:68)
 at 
 org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
 at org.apache.solr.core.SolrCore.execute(SolrCore.java:1797)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:637)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343)
 at 
 org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:141)
 at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
 at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
 at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
 at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
 at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
 at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
 at 
 org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
 at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
 at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
 at 
 org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:987)
 at 
 org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579)
 at 
 org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
 at 
 java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
 at 
 java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
 at java.lang.Thread.run(Thread.java:722)
 Caused by: org.apache.lucene.store.AlreadyClosedException: this IndexWriter 
 is closed
 at

[jira] [Updated] (LUCENE-4832) Unbounded getTopGroups for ToParentBlockJoinCollector

2013-03-18 Thread Aleksey Aleev (JIRA)


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

Aleksey Aleev updated LUCENE-4832:
--

Attachment: LUCENE-4832.patch

Hi Michael! I've updated the patch with introducing a method instead of class 
and Integer.MAX_VALUE fix. Please have a look and tell what do you think about 
it. Thank you.

 Unbounded getTopGroups for ToParentBlockJoinCollector
 -

 Key: LUCENE-4832
 URL: https://issues.apache.org/jira/browse/LUCENE-4832
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/join
Reporter: Aleksey Aleev
 Attachments: LUCENE-4832.patch, LUCENE-4832.patch


 _ToParentBlockJoinCollector#getTopGroups_ method takes several arguments:
 {code:java}
 public TopGroupsInteger getTopGroups(ToParentBlockJoinQuery query, 
Sort withinGroupSort,
int offset,
int maxDocsPerGroup,
int withinGroupOffset,
boolean fillSortFields)
 {code}
 and one of them is {{maxDocsPerGroup}} which specifies upper bound of child 
 documents number returned within each group. 
 {{ToParentBlockJoinCollector}} collects and caches all child documents 
 matched by given {{ToParentBlockJoinQuery}} in {{OneGroup}} objects during 
 search so it is possible to create {{GroupDocs}} with all matched child 
 documents instead of part of them bounded by {{maxDocsPerGroup}}.
 When you specify {{maxDocsPerGroup}} new queues(I mean 
 {{TopScoreDocCollector}}/{{TopFieldCollector}}) will be created for each 
 group with {{maxDocsPerGroup}} objects created within each queue which could 
 lead to redundant memory allocation in case of child documents number within 
 group is less than {{maxDocsPerGroup}}.
 I suppose that there are many cases where you need to get all child documents 
 matched by query so it could be nice to have ability to get top groups with 
 all matched child documents without unnecessary memory allocation. 
 Possible solution is to pass negative {{maxDocsPerGroup}} in case when you 
 need to get all matched child documents within each group and check 
 {{maxDocsPerGroup}} value: if it is negative then we need to create queue 
 with size of matched child documents number; otherwise create queue with size 
 equals to {{maxDocsPerGroup}}. 

--
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-4544) Allow HttpShardHandler to be reused better by subclasses of HttpShardHandlerFactory


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

Commit Tag Bot commented on SOLR-4544:
--

[branch_4x commit] Robert Muir
http://svn.apache.org/viewvc?view=revisionrevision=1457762

SOLR-4544: Refactor HttpShardHandlerFactory so load-balancing logic can be 
customized.


 Allow HttpShardHandler to be reused better by subclasses of 
 HttpShardHandlerFactory
 ---

 Key: SOLR-4544
 URL: https://issues.apache.org/jira/browse/SOLR-4544
 Project: Solr
  Issue Type: Improvement
Reporter: Ryan Ernst
 Attachments: SOLR-4544.patch, SOLR-4544.patch


 I would like to have a custom ShardHandlerFactory, which has my own special 
 load balancing logic (among other things).  The HttpShardHandler is what 
 currently handles the parallelization of shard requests.  I would like to 
 reuse it, but it expects package private variables in HttpShardHandlerFactory 
 which it can reach back into for making load balancer requests and a 
 completion service.

--
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] (LUCENE-4849) Make ParallelTaxonomyArrays abstract

Shai Erera created LUCENE-4849:
--

 Summary: Make ParallelTaxonomyArrays abstract
 Key: LUCENE-4849
 URL: https://issues.apache.org/jira/browse/LUCENE-4849
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Reporter: Shai Erera
Assignee: Shai Erera


ParallelTaxonomyArrays, while appearing on TaxonomyReader, actually support 
only one implementation, that of DirectoryTaxonomyReader. I'd like to make it 
abstract (perhaps share the children/siblings arrays computation) to allow for 
other taxonomy reader implementations.

--
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

JSON parser/utility

2013-03-18 Thread Shai Erera

Hi

Do we have in Lucene (or Solr) a JSON parser? If not, is there a preferred
open source? Think if we had in Lucene a module that depends on JSON, which
of the various tools out there you think would make sense to be included
with Lucene.

Shai

[jira] [Commented] (LUCENE-4849) Make ParallelTaxonomyArrays abstract


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

Shai Erera commented on LUCENE-4849:


In fact, ParallelTaxonomyArrays exists under o.a.l.facet.taxonomy.directory 
package, while it should be under the *.taxonomy one.

 Make ParallelTaxonomyArrays abstract
 

 Key: LUCENE-4849
 URL: https://issues.apache.org/jira/browse/LUCENE-4849
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/facet
Reporter: Shai Erera
Assignee: Shai Erera

 ParallelTaxonomyArrays, while appearing on TaxonomyReader, actually support 
 only one implementation, that of DirectoryTaxonomyReader. I'd like to make it 
 abstract (perhaps share the children/siblings arrays computation) to allow 
 for other taxonomy reader implementations.

--
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: JSON parser/utility

2013-03-18 Thread Erik Hatcher

Solr uses Noggit http://svn.apache.org/repos/asf/labs/noggit/.  It's inlined 
in Solr's source code, for some reason 
https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/solrj/src/java/org/apache/noggit/

Erik


On Mar 18, 2013, at 06:58 , Shai Erera wrote:

 Hi
 
 Do we have in Lucene (or Solr) a JSON parser? If not, is there a preferred 
 open source? Think if we had in Lucene a module that depends on JSON, which 
 of the various tools out there you think would make sense to be included with 
 Lucene.
 
 Shai


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

[jira] [Commented] (LUCENE-4747) java7 as a minimum requirement for lucene 5


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

Uwe Schindler commented on LUCENE-4747:
---

+1, go ahead!

 java7 as a minimum requirement for lucene 5
 ---

 Key: LUCENE-4747
 URL: https://issues.apache.org/jira/browse/LUCENE-4747
 Project: Lucene - Core
  Issue Type: Task
Affects Versions: 5.0
Reporter: Robert Muir
Assignee: Uwe Schindler
 Fix For: 5.0

 Attachments: LUCENE-4747.patch, LUCENE-4747.patch


 Spinoff from LUCENE-4746. 
 I propose we make this change on trunk only. 

--
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

Welcome David Smiley to the PMC

2013-03-18 Thread Steve Rowe

I'm pleased to announce that David Smiley has accepted the PMC's invitation to 
join.

Welcome David!

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

[jira] [Resolved] (SOLR-4544) Allow HttpShardHandler to be reused better by subclasses of HttpShardHandlerFactory


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

Robert Muir resolved SOLR-4544.
---

   Resolution: Fixed
Fix Version/s: 5.0
   4.3

Thanks Ryan!

 Allow HttpShardHandler to be reused better by subclasses of 
 HttpShardHandlerFactory
 ---

 Key: SOLR-4544
 URL: https://issues.apache.org/jira/browse/SOLR-4544
 Project: Solr
  Issue Type: Improvement
Reporter: Ryan Ernst
 Fix For: 4.3, 5.0

 Attachments: SOLR-4544.patch, SOLR-4544.patch


 I would like to have a custom ShardHandlerFactory, which has my own special 
 load balancing logic (among other things).  The HttpShardHandler is what 
 currently handles the parallelization of shard requests.  I would like to 
 reuse it, but it expects package private variables in HttpShardHandlerFactory 
 which it can reach back into for making load balancer requests and a 
 completion service.

--
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-4747) java7 as a minimum requirement for lucene 5

2013-03-18 Thread Steve Rowe (JIRA)


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

Steve Rowe commented on LUCENE-4747:


bq. Before resolving the issue I wanted the confirmation by Steven Rowe, if the 
Maven build is setup correctly (e.g. maven-enforcer-plugin,...).

Enforcer seems to work fine.  forbiddenapis, compilation and enforcer all use 
the ${java.compat.version} property that you changed to 1.7, so I think the 
Maven build is all set.

When I attempt {{mvn install}} with Java6, I see this:

{noformat}
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.RequireJavaVersion failed 
with message:
Java 1.7+ is required.

...

[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 3.053s
[INFO] Finished at: Mon Mar 18 10:21:11 EDT 2013
[INFO] Final Memory: 17M/81M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-enforcer-plugin:1.2:enforce 
(enforce-java-compat-version-and-maven-2.2.1) on project 
lucene-solr-grandparent: Some Enforcer rules have failed. Look above for 
specific messages explaining why the rule failed. - [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
{noformat}

 java7 as a minimum requirement for lucene 5
 ---

 Key: LUCENE-4747
 URL: https://issues.apache.org/jira/browse/LUCENE-4747
 Project: Lucene - Core
  Issue Type: Task
Affects Versions: 5.0
Reporter: Robert Muir
Assignee: Uwe Schindler
 Fix For: 5.0

 Attachments: LUCENE-4747.patch, LUCENE-4747.patch


 Spinoff from LUCENE-4746. 
 I propose we make this change on trunk only. 

--
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] (LUCENE-4850) Update Clover dependency and License to allow processing Java 7 source code

Uwe Schindler created LUCENE-4850:
-

 Summary: Update Clover dependency and License to allow processing 
Java 7 source code
 Key: LUCENE-4850
 URL: https://issues.apache.org/jira/browse/LUCENE-4850
 Project: Lucene - Core
  Issue Type: Bug
  Components: general/build
Affects Versions: 5.0
Reporter: Uwe Schindler
Assignee: Uwe Schindler


We moved to Java 7 in LUCENE-4747. But Clover 2.6.3 only allows Java 6. We 
should upgrade clover to the latest version (at least in trunk) and make ant 
run-clover work again. We have to replace the ASF License File with a new one 
for this to work.

--
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: Welcome David Smiley to the PMC

2013-03-18 Thread Smiley, David W.

Thanks Steve, and to the rest of the PMC members!  I hope to see many of
you at Lucene/Solr Revolution in May.

~ David

On 3/18/13 10:13 AM, Steve Rowe sar...@gmail.com wrote:

I'm pleased to announce that David Smiley has accepted the PMC's
invitation to join.

Welcome David!

- Steve
-
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] [Comment Edited] (LUCENE-4747) java7 as a minimum requirement for lucene 5

2013-03-18 Thread Steve Rowe (JIRA)


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

Steve Rowe edited comment on LUCENE-4747 at 3/18/13 2:28 PM:
-

bq. Before resolving the issue I wanted the confirmation by Steven Rowe, if the 
Maven build is setup correctly (e.g. maven-enforcer-plugin,...).

Enforcer seems to work fine.  forbiddenapis, compilation and enforcer all use 
the {{$\{java.compat.version}}} property that you changed to 1.7, so I think 
the Maven build is all set.

When I attempt {{mvn install}} with Java6, I see this:

{noformat}
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.RequireJavaVersion failed 
with message:
Java 1.7+ is required.

...

[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 3.053s
[INFO] Finished at: Mon Mar 18 10:21:11 EDT 2013
[INFO] Final Memory: 17M/81M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-enforcer-plugin:1.2:enforce 
(enforce-java-compat-version-and-maven-2.2.1) on project 
lucene-solr-grandparent: Some Enforcer rules have failed. Look above for 
specific messages explaining why the rule failed. - [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
{noformat}

  was (Author: steve_rowe):
bq. Before resolving the issue I wanted the confirmation by Steven Rowe, if 
the Maven build is setup correctly (e.g. maven-enforcer-plugin,...).

Enforcer seems to work fine.  forbiddenapis, compilation and enforcer all use 
the ${java.compat.version} property that you changed to 1.7, so I think the 
Maven build is all set.

When I attempt {{mvn install}} with Java6, I see this:

{noformat}
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.RequireJavaVersion failed 
with message:
Java 1.7+ is required.

...

[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 3.053s
[INFO] Finished at: Mon Mar 18 10:21:11 EDT 2013
[INFO] Final Memory: 17M/81M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-enforcer-plugin:1.2:enforce 
(enforce-java-compat-version-and-maven-2.2.1) on project 
lucene-solr-grandparent: Some Enforcer rules have failed. Look above for 
specific messages explaining why the rule failed. - [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
{noformat}
  
 java7 as a minimum requirement for lucene 5
 ---

 Key: LUCENE-4747
 URL: https://issues.apache.org/jira/browse/LUCENE-4747
 Project: Lucene - Core
  Issue Type: Task
Affects Versions: 5.0
Reporter: Robert Muir
Assignee: Uwe Schindler
 Fix For: 5.0

 Attachments: LUCENE-4747.patch, LUCENE-4747.patch


 Spinoff from LUCENE-4746. 
 I propose we make this change on trunk only. 

--
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: Welcome David Smiley to the PMC

2013-03-18 Thread Tommaso Teofili

Welcome David!

Tommaso


2013/3/18 Smiley, David W. dsmi...@mitre.org

 Thanks Steve, and to the rest of the PMC members!  I hope to see many of
 you at Lucene/Solr Revolution in May.

 ~ David

 On 3/18/13 10:13 AM, Steve Rowe sar...@gmail.com wrote:

 I'm pleased to announce that David Smiley has accepted the PMC's
 invitation to join.
 
 Welcome David!
 
 - Steve
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-4606) Let test-framework provide random seed to HttpShardHandlerFactory


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

Robert Muir updated SOLR-4606:
--

Attachment: SOLR-4606.patch

patch: a parameter might seem cleaner than the sysprop I used here, but I tried 
this, it still leaves tons of tests with nondeterministic behavior (e.g. ones 
using the example config).


 Let test-framework provide random seed to HttpShardHandlerFactory
 -

 Key: SOLR-4606
 URL: https://issues.apache.org/jira/browse/SOLR-4606
 Project: Solr
  Issue Type: Test
  Components: Tests
Reporter: Robert Muir
 Attachments: SOLR-4606.patch


 Currently this uses new Random(): I think this hurts the reproducibility of 
 any distributed test failures.

--
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: Welcome David Smiley to the PMC

2013-03-18 Thread Mark Miller

Welcome David!

- Mark

On Mar 18, 2013, at 10:13 AM, Steve Rowe sar...@gmail.com wrote:

 I'm pleased to announce that David Smiley has accepted the PMC's invitation 
 to join.
 
 Welcome David!
 
 - Steve
 -
 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] (LUCENE-4747) java7 as a minimum requirement for lucene 5


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

Uwe Schindler commented on LUCENE-4747:
---

Thanks!
I'll close this issue now and we should open followup issues for the remaining 
tasks.

 java7 as a minimum requirement for lucene 5
 ---

 Key: LUCENE-4747
 URL: https://issues.apache.org/jira/browse/LUCENE-4747
 Project: Lucene - Core
  Issue Type: Task
Affects Versions: 5.0
Reporter: Robert Muir
Assignee: Uwe Schindler
 Fix For: 5.0

 Attachments: LUCENE-4747.patch, LUCENE-4747.patch


 Spinoff from LUCENE-4746. 
 I propose we make this change on trunk only. 

--
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] [Resolved] (LUCENE-4747) java7 as a minimum requirement for lucene 5


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

Uwe Schindler resolved LUCENE-4747.
---

Resolution: Fixed

 java7 as a minimum requirement for lucene 5
 ---

 Key: LUCENE-4747
 URL: https://issues.apache.org/jira/browse/LUCENE-4747
 Project: Lucene - Core
  Issue Type: Task
Affects Versions: 5.0
Reporter: Robert Muir
Assignee: Uwe Schindler
 Fix For: 5.0

 Attachments: LUCENE-4747.patch, LUCENE-4747.patch


 Spinoff from LUCENE-4746. 
 I propose we make this change on trunk only. 

--
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: JSON parser/utility

2013-03-18 Thread Mark Miller


On Mar 18, 2013, at 10:05 AM, Erik Hatcher erik.hatc...@gmail.com wrote:

 for some reason 

Probably ivy/maven stuff if I remember right. I think Yonik had it downloading 
from GitHub for a while but then they dropped their downloads feature.

- Mark


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

Re: Welcome David Smiley to the PMC

Welcome!

On Mon, Mar 18, 2013 at 10:13 AM, Steve Rowe sar...@gmail.com wrote:
 I'm pleased to announce that David Smiley has accepted the PMC's invitation 
 to join.

 Welcome David!

 - Steve
 -
 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

RE: Welcome David Smiley to the PMC

Welcome!

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de


 -Original Message-
 From: Steve Rowe [mailto:sar...@gmail.com]
 Sent: Monday, March 18, 2013 3:14 PM
 To: dev@lucene.apache.org
 Cc: gene...@lucene.apache.org
 Subject: Welcome David Smiley to the PMC
 
 I'm pleased to announce that David Smiley has accepted the PMC's invitation
 to join.
 
 Welcome David!
 
 - Steve=


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

Re: JSON parser/utility

Its in maven now: lets use that one so it can be used elsewhere and so
we dont have our own fork.

http://search.maven.org/#search|ga|1|a%3A%22noggit%22

On Mon, Mar 18, 2013 at 10:34 AM, Mark Miller markrmil...@gmail.com wrote:

 On Mar 18, 2013, at 10:05 AM, Erik Hatcher erik.hatc...@gmail.com wrote:

 for some reason

 Probably ivy/maven stuff if I remember right. I think Yonik had it 
 downloading from GitHub for a while but then they dropped their downloads 
 feature.

 - Mark


 -
 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

Re: Welcome David Smiley to the PMC

2013-03-18 Thread Stefan Matheis

Welcome David :)



On Monday, March 18, 2013 at 3:35 PM, Uwe Schindler wrote:

 Welcome!
 
 -
 Uwe Schindler
 H.-H.-Meier-Allee 63, D-28213 Bremen
 http://www.thetaphi.de
 eMail: u...@thetaphi.de (mailto:u...@thetaphi.de)
 
 
  -Original Message-
  From: Steve Rowe [mailto:sar...@gmail.com]
  Sent: Monday, March 18, 2013 3:14 PM
  To: dev@lucene.apache.org (mailto:dev@lucene.apache.org)
  Cc: gene...@lucene.apache.org (mailto:gene...@lucene.apache.org)
  Subject: Welcome David Smiley to the PMC
  
  I'm pleased to announce that David Smiley has accepted the PMC's invitation
  to join.
  
  Welcome David!
  
  - Steve=
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
 (mailto:dev-unsubscr...@lucene.apache.org)
 For additional commands, e-mail: dev-h...@lucene.apache.org 
 (mailto:dev-h...@lucene.apache.org)




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

Re: JSON parser/utility

2013-03-18 Thread Shai Erera

Yes, at least according to this thread, Solr seems to have it because of
build issues:
http://mail-archives.apache.org/mod_mbox/labs-labs/201203.mbox/%3CCAAqLGLPtyMQ0-xNHsS=iFctix=ixjvefhyqaxgsq_qht9vn...@mail.gmail.com%3E

I read that Jackson is pretty fast and handles JSON streaming well. It also
seems to be very popular. But Jackson is dual-licensed (GPL and Apache
2.0), anyone knows if that could cause us issues?

What's Solr's experience with Noggit? Is it fast? Fast enough? Convenient
to work with?

Shai


On Mon, Mar 18, 2013 at 4:34 PM, Mark Miller markrmil...@gmail.com wrote:


 On Mar 18, 2013, at 10:05 AM, Erik Hatcher erik.hatc...@gmail.com wrote:

  for some reason

 Probably ivy/maven stuff if I remember right. I think Yonik had it
 downloading from GitHub for a while but then they dropped their downloads
 feature.

 - Mark


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

RE: JSON parser/utility