Re: Require java 8 upgrade
Hi Akhila, Here is the related documentation: https://lucene.apache.org/solr/5_3_1/SYSTEM_REQUIREMENTS.html which says: "Apache Solr runs of Java 7 or greater, Java 8 is verified to be compatible and may bring some performance improvements. When using Oracle Java 7 or OpenJDK 7, be sure to not use the GA build 147 or update versions u40, u45 and u51! We recommend using u55 or later." Kind Regards, Furkan KAMACI On Fri, May 22, 2020 at 4:26 AM Akhila John wrote: > Hi Team, > > We use solr 5.3.1 for sitecore 8.2. > We require to upgrade Java version to 'Java 8 Update 251' and remove / > Upgrade Wireshark to 3.2.3 in our application servers. > Could you please advise if this would have any impact on the solr. Does > solr 5.3.1 support Java 8. > > Thanks and regards, > > Akhila > > Bupa A email disclaimer: The information contained in this email and > any attachments is confidential and may be subject to copyright or other > intellectual property protection. If you are not the intended recipient, > you are not authorized to use or disclose this information, and we request > that you notify us by reply mail or telephone and delete the original > message from your mail system. >
Re: Welcome Atri Sharma as Lucene/Solr committer
Hi, Congrats Atri! Kind Regards, Furkan KAMACI On Thu, Sep 19, 2019 at 5:47 PM Atri Sharma wrote: > Thank you! > > On Thu, Sep 19, 2019 at 2:04 PM Uwe Schindler wrote: > > > > Welcome! > > > > Congratulations and I hope to work together with you in the future > (although I am a bit busy at the moment, so I have not much time). > > > > Uwe > > > > - > > Uwe Schindler > > Achterdiek 19, D-28357 Bremen > > https://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > > -Original Message- > > > From: Adrien Grand > > > Sent: Wednesday, September 18, 2019 9:12 AM > > > To: Lucene Dev > > > Subject: Welcome Atri Sharma as Lucene/Solr committer > > > > > > Hi all, > > > > > > Please join me in welcoming Atri Sharma as Lucene/ Solr committer! > > > > > > If you are following activity on Lucene, this name will likely sound > > > familiar to you: Atri has been very busy trying to improve Lucene over > > > the past months. In particular, Atri recently started improving our > > > top-hits optimizations like early termination on sorted indexes and > > > WAND, when indexes are searched using multiple threads. > > > > > > Congratulations and welcome! It is a tradition to introduce yourself > > > with a brief bio. > > > > > > -- > > > Adrien > > > > > > - > > > 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 > > > > > -- > Regards, > > Atri > Apache Concerted > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
[jira] [Created] (SOLR-13705) Double-checked Locking Should Not be Used
Furkan KAMACI created SOLR-13705: Summary: Double-checked Locking Should Not be Used Key: SOLR-13705 URL: https://issues.apache.org/jira/browse/SOLR-13705 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 8.2 Reporter: Furkan KAMACI Fix For: 8.3 Using double-checked locking for the lazy initialization of any other type of primitive or mutable object risks a second thread using an uninitialized or partially initialized member while the first thread is still creating it, and crashing the program. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13680) Close Resources Properly
[ https://issues.apache.org/jira/browse/SOLR-13680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903939#comment-16903939 ] Furkan KAMACI commented on SOLR-13680: -- Thanks for the review [~munendrasn] > Close Resources Properly > > > Key: SOLR-13680 > URL: https://issues.apache.org/jira/browse/SOLR-13680 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.2 > Reporter: Furkan KAMACI >Assignee: Munendra S N >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13680.patch, SOLR-13680.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Files, streams or connections which implements Closeable or AutoCloseable > interface should be closed after use. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13680) Close Resources Properly
[ https://issues.apache.org/jira/browse/SOLR-13680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16903901#comment-16903901 ] Furkan KAMACI commented on SOLR-13680: -- Sure, I'll! > Close Resources Properly > > > Key: SOLR-13680 > URL: https://issues.apache.org/jira/browse/SOLR-13680 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.2 > Reporter: Furkan KAMACI >Assignee: Munendra S N >Priority: Major > Fix For: 8.3 > > Attachments: SOLR-13680.patch, SOLR-13680.patch > > Time Spent: 10m > Remaining Estimate: 0h > > Files, streams or connections which implements Closeable or AutoCloseable > interface should be closed after use. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13680) Close Resources Properly
[ https://issues.apache.org/jira/browse/SOLR-13680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16900430#comment-16900430 ] Furkan KAMACI commented on SOLR-13680: -- [~munendrasn] is there anything to update at my PR? > Close Resources Properly > > > Key: SOLR-13680 > URL: https://issues.apache.org/jira/browse/SOLR-13680 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: 8.2 > Reporter: Furkan KAMACI >Assignee: Munendra S N >Priority: Major > Fix For: 8.3 > > Time Spent: 10m > Remaining Estimate: 0h > > Files, streams or connections which implements Closeable or AutoCloseable > interface should be closed after use. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-13680) Close Resources Properly
Furkan KAMACI created SOLR-13680: Summary: Close Resources Properly Key: SOLR-13680 URL: https://issues.apache.org/jira/browse/SOLR-13680 Project: Solr Issue Type: Bug Security Level: Public (Default Security Level. Issues are Public) Affects Versions: 8.2 Reporter: Furkan KAMACI Fix For: 8.3 Files, streams or connections which implements Closeable or AutoCloseable interface should be closed after use. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Michael Sokolov as Lucene/ Solr committer
Congrats Michael! 14 May 2019 Sal, saat 05:37 tarihinde Robert Muir şunu yazdı: > Welcome! > > On Mon, May 13, 2019 at 3:12 PM Dawid Weiss wrote: > > > > Hello everyone, > > > > Please join me in welcoming Michael Sokolov as Lucene/ Solr committer! > > > > Many of you probably know Mike as he's been around for quite a while > > -- answering questions, reviewing patches, providing insight and > > actively working on new code. > > > > Congratulations and welcome! It is a tradition to introduce yourself > > with a brief bio, Mike. > > > > Dawid > > > > - > > 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: [VOTE] Release Lucene/Solr 8.0.0 RC4
Hi, +1! Kind Regards, Furkan KAMACI On Fri, Mar 8, 2019 at 10:08 PM Tomás Fernández Löbbe wrote: > SUCCESS! [1:13:11.720840] > > +1 > > Thanks Jim! > > On Fri, Mar 8, 2019 at 9:38 AM Uwe Schindler wrote: > >> Hi, >> >> >> >> I did the same tests like last time. Here the results: >> >> >> >> https://jenkins.thetaphi.de/job/Lucene-Solr-Release-Tester/18/console >> >> SUCCESS! [2:36:19.284235] >> >> >> >> The testing was done with Java 8 and Java 9 (this is why it took longer). >> >> >> >> I also checked Changes.txt, looks fine! >> >> >> >> I also checked the ZIP files of Lucene and Solr. Lucene looks as usual, >> MIGRATE.txt is also fine – thanks for adding recent information! JAR files >> also look fine, compiled with correct version of Java and patches >> multi-release class files are there. >> >> >> >> Apache Solr was unzipped and quickly tested on Windows: Startup with Java >> 8 and Java 11 worked without any problems from a directory with whitespace >> in path. I was able to do a HTTP/2 request with CURL (non-TLS) on both O/S >> (as ALPN is not available without TLS, the curl client needed to upgrade >> the request, so you see “101 Switching Protocols”): >> >> >> >> *Uwe Schindler@VEGA:*~ > curl -I --http2 localhost:8983/solr/ >> >> HTTP/1.1 101 Switching Protocols >> >> >> >> HTTP/2 200 >> >> x-frame-options: DENY >> >> content-type: text/html;charset=utf-8 >> >> content-length: 14662 >> >> >> >> So, it worked. In the webbrowser it did not use HTTP/2, as browsers >> require SSL and ALPN for that (by default). >> >> >> >> Next I enabled TLS support by creating a keystore. This time it was >> possible to start Solr on Java 8 and Java 11 – bug fixed. With Solr running >> in Java 8, CURL was only able to do a HTTP/1.1 request because ALPN told >> this to the curl client: >> >> >> >> *Uwe Schindler@VEGA:*~ > curl -k -I --http2 https://localhost:8983/solr/ >> >> HTTP/1.1 200 OK >> >> X-Frame-Options: DENY >> >> Content-Type: text/html;charset=utf-8 >> >> Content-Length: 14662 >> >> >> >> With Java 11, my curl test worked with HTTP/2, this time no protocol >> switch needed as ALPN is active: >> >> >> >> *Uwe Schindler@VEGA:*~ > curl -k -I --http2 https://localhost:8983/solr/ >> >> HTTP/2 200 >> >> x-frame-options: DENY >> >> content-type: text/html;charset=utf-8 >> >> content-length: 14662 >> >> >> >> I also checked in Chrome browser, this time it uses HTTP/2 to communicate >> with the admin interface. Fine! >> >> >> >> *+1 to release Lucene/Solr 8.0.0 (RC4).* >> >> >> >> Uwe >> >> >> >> - >> >> Uwe Schindler >> >> Achterdiek 19, D-28357 Bremen >> >> http://www.thetaphi.de >> >> eMail: u...@thetaphi.de >> >> >> >> *From:* jim ferenczi >> *Sent:* Friday, March 8, 2019 1:43 PM >> *To:* dev@lucene.apache.org >> *Subject:* [VOTE] Release Lucene/Solr 8.0.0 RC4 >> >> >> >> Please vote for release candidate 4 for Lucene/Solr 8.0.0 >> >> The artifacts can be downloaded from >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC4-rev2ae4746365c1ee72a0047ced7610b2096e438979/ >> You can run the smoke tester directly with this command: >> python3 -u dev-tools/scripts/smokeTestRelease.py >> *https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC4-rev2ae4746365c1ee72a0047ced7610b2096e438979 >> <https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC4-rev2ae4746365c1ee72a0047ced7610b2096e438979>* >> >> >> >> Here's my +1 >> >> SUCCESS! [1:19:23.500783] >> >
Solr/Lucene Mail Groups
Hi All, Solr/Lucene @dev mail list includes both @dev conversations, GitHub notifications, and Jira notifications. This may not be a problem and I know that it is possible to filter such e-mails but what do you think about to have such e-mail groups i.e. [issues@, builds@ | notifications@]? Kind Regards, Furkan KAMACI
Re: [VOTE] Release Lucene/Solr 8.0.0 RC3
Hi, Sorry, but I also think that we should respin it if we can instead of running a release of 8.0.1. Kind Regards, Furkan KAMACI On Fri, Mar 8, 2019 at 10:24 AM Anshum Gupta wrote: > Having done these releases more than a few times, I completely understand > the frustration caused by such delays but I think that SOLR-13285 is > something that really breaks Solr in a major version release. We can always > have a 8.0.1 release that fixes it but I feel like it would not be a good > thing to offer an 8.0.0 version to end-users knowing that it would cause > issues for anyone using enum fields. > > I am sorry that it would require more time and effort at the end of the RM > but In my opinion, this is worth a respin. > > Anshum > > On Thu, Mar 7, 2019 at 10:52 PM Ishan Chattopadhyaya < > ichattopadhy...@gmail.com> wrote: > >> In case we go through with this RC, I can volunteer to release a 8.0.1 >> (with SOLR-13285) immediately after 8.0.0 release. >> @Adrien, Jim, I really understand the frustrations of an RM, and I also >> apologize for the delay I caused to this release due to the intermediate >> 7.7.1 release where I didn't do it as quickly as I could have (delay in >> building the RC, delay in backporting the backward compatibility indexes >> etc). >> >> >> On Fri, Mar 8, 2019 at 10:52 AM Tomás Fernández Löbbe < >> tomasflo...@gmail.com> wrote: >> >>> I understand the frustration with the delay and the number of respins, >>> and I don't want to be disrespectful of Jim's time as RC, but from what I >>> can see, SOLR-13285 would prevent anyone with enum fields to use Solr 8.0, >>> and the fix is already available. >>> >>> -0 >>> >>> On Thu, Mar 7, 2019 at 2:14 PM Nhat Nguyen >>> wrote: >>> >>>> +1 SUCCESS! [0:54:05.261238] >>>> >>>> > On Mar 7, 2019, at 4:44 PM, Adrien Grand wrote: >>>> > >>>> > +1 SUCCESS! [1:25:54.239684] >>>> > >>>> > On Thu, Mar 7, 2019 at 5:53 PM jim ferenczi >>>> wrote: >>>> >> >>>> >> Please vote for release candidate 3 for Lucene/Solr 8.0.0 >>>> >> >>>> >> The artifacts can be downloaded from >>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC3-reva9d80bf18af04850ea21dcf88a40367559fb246e >>>> >> You can run the smoke tester directly with this command: >>>> >> python3 -u dev-tools/scripts/smokeTestRelease.py >>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC3-reva9d80bf18af04850ea21dcf88a40367559fb246e >>>> >> >>>> >> Here’s my +1 >>>> >> SUCCESS! [1:14:08.843490] >>>> > >>>> > >>>> > >>>> > -- >>>> > Adrien >>>> > >>>> > - >>>> > 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: VOTE: Release Apache Solr Ref Guide for 7.7
Hi, +1 Thanks for doing this! Kind Regards, Furkan KAMACI On Fri, Mar 8, 2019 at 9:03 AM Tomás Fernández Löbbe wrote: > +1 > > On Thu, Mar 7, 2019 at 11:14 AM Anshum Gupta > wrote: > >> +1 >> >> Thanks for doing this, Jason! >> >> * *Anshum >> >> >> On Mar 4, 2019, at 7:28 AM, Jason Gerlowski >> wrote: >> >> Please vote to release the Solr Ref Guide for 7.7. >> >> The PDF artifacts can be downloaded from: >> >> https://dist.apache.org/repos/dist/dev/lucene/solr/ref-guide/apache-solr-ref-guide-7.7-RC0/ >> >> $ cat apache-solr-ref-guide-7.7.pdf.sha512 >> >> a4a89cf56c90a2f05874e4770726cf3635bbbde3c8e7dace92b51bd01e08d486754de06f753c0c1a6d7fab63068898e991d9bfeb024e945b2f898cce18ee8d3d >> apache-solr-ref-guide-7.7.pdf >> >> >> The PDF is up to 1431 pages! >> >> The online version is available at: >> http://lucene.apache.org/solr/guide/7_7/ >> >> Here's my +1. >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >>
Re: Welcome Ignacio Vera to the PMC
Congrats! On Wed, Mar 6, 2019 at 12:09 AM Anshum Gupta wrote: > Congratulations and welcome, Ignacio! > > Anshum > > > On Mar 4, 2019, at 4:37 AM, Jason Gerlowski > wrote: > > > > Congrats Ignacio! > > > >> On Mon, Mar 4, 2019 at 7:17 AM Martin Gainty > wrote: > >> > >> ¡Bienvenidos Ignacio! > >> > >> > >> From: Dawid Weiss > >> Sent: Monday, March 4, 2019 6:45 AM > >> To: dev@lucene.apache.org > >> Subject: Re: Welcome Ignacio Vera to the PMC > >> > >> Welcome, Ignacio! > >> > >>> On Mon, Mar 4, 2019 at 10:09 AM Adrien Grand > wrote: > >>> > >>> I am pleased to announce that Ignacio Vera has accepted the PMC's > >>> invitation to join. > >>> > >>> Welcome Ignacio! > >>> > >>> -- > >>> Adrien > >>> > >>> - > >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >>> For additional commands, e-mail: dev-h...@lucene.apache.org > >>> > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: dev-h...@lucene.apache.org > >> > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: subscribe
Hi Ken, You should send an e-mail to dev-subscr...@lucene.apache.org instead of this one to subscribe dev mail list. You can find more info here: http://lucene.apache.org/solr/community.html#mailing-lists-irc Kind Regards, Furkan KAMACI On Fri, Mar 1, 2019 at 6:42 PM Ken LaPorte wrote: > >
[jira] [Comment Edited] (SOLR-8793) Fix stale commit files' size computation in LukeRequestHandler
[
https://issues.apache.org/jira/browse/SOLR-8793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15695911#comment-15695911
]
Furkan KAMACI edited comment on SOLR-8793 at 11/25/16 1:51 PM:
---
I get that warning:
{code}
WARN - 2016-11-25 14:45:53.587; [ x:gettingstarted]
org.apache.solr.handler.admin.LukeRequestHandler; Error getting file length for
[segments_5]
java.nio.file.NoSuchFileException:
/solr-5.5.2/example/schemaless/solr/gettingstarted/data/index/segments_5
at
sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at
sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
at
sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144)
at java.nio.file.Files.readAttributes(Files.java:1737)
at java.nio.file.Files.size(Files.java:2332)
at org.apache.lucene.store.FSDirectory.fileLength(FSDirectory.java:210)
at
org.apache.lucene.store.NRTCachingDirectory.fileLength(NRTCachingDirectory.java:124)
at
org.apache.solr.handler.admin.LukeRequestHandler.getFileLength(LukeRequestHandler.java:604)
at
org.apache.solr.handler.admin.LukeRequestHandler.getIndexInfo(LukeRequestHandler.java:592)
at
org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:137)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2102)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:499)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
at
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:745)
{code}
with Solr 5.5.2 with default schemaless example.
was (Author: kamaci):
I get that error:
{code}
WARN - 2016-11-25 14:45:53.587; [ x:gettingstarted]
org.apache.solr.handler.admin.LukeRequestHandler; Error getting file length for
[segments_5]
java.nio.file.NoSuchFileException:
/Users/kamaci/Desktop/search_product/solr-5.5.2/example/schemaless/solr/gettingstarted/data/index/segments_5
at
sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at
sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
at
sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144)
at java.nio.file.Files.readAttributes(Files.java:1737)
at java.nio.file.Files.size(Files.java:2332)
at org.apache.lucene.store.FSDirectory.fileLength(FSDirectory.java:210
[jira] [Commented] (SOLR-8793) Fix stale commit files' size computation in LukeRequestHandler
[
https://issues.apache.org/jira/browse/SOLR-8793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15695911#comment-15695911
]
Furkan KAMACI commented on SOLR-8793:
-
I get that error:
{code}
WARN - 2016-11-25 14:45:53.587; [ x:gettingstarted]
org.apache.solr.handler.admin.LukeRequestHandler; Error getting file length for
[segments_5]
java.nio.file.NoSuchFileException:
/Users/kamaci/Desktop/search_product/solr-5.5.2/example/schemaless/solr/gettingstarted/data/index/segments_5
at
sun.nio.fs.UnixException.translateToIOException(UnixException.java:86)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
at
sun.nio.fs.UnixFileAttributeViews$Basic.readAttributes(UnixFileAttributeViews.java:55)
at
sun.nio.fs.UnixFileSystemProvider.readAttributes(UnixFileSystemProvider.java:144)
at java.nio.file.Files.readAttributes(Files.java:1737)
at java.nio.file.Files.size(Files.java:2332)
at org.apache.lucene.store.FSDirectory.fileLength(FSDirectory.java:210)
at
org.apache.lucene.store.NRTCachingDirectory.fileLength(NRTCachingDirectory.java:124)
at
org.apache.solr.handler.admin.LukeRequestHandler.getFileLength(LukeRequestHandler.java:604)
at
org.apache.solr.handler.admin.LukeRequestHandler.getIndexInfo(LukeRequestHandler.java:592)
at
org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:137)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:155)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:2102)
at org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:460)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:257)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:208)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:499)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
at
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
at java.lang.Thread.run(Thread.java:745)
{code}
with Solr 5.5.2 with default schemaless example.
> Fix stale commit files' size computation in LukeRequestHandler
> --
>
> Key: SOLR-8793
> URL: https://issues.apache.org/jira/browse/SOLR-8793
> Project: Solr
> Issue Type: Bug
> Components: Server
>Affects Versions: 5.5
>Reporter: Shai Erera
>Assignee: Shai Erera
>Priority: Minor
> Fix For: 5.5.1, 6.0
>
> Attachments: SOLR-8793.patch
>
>
> SOLR-8587 added segments file information and its size to core admin status
> API. However in case of stale commits, calling that API may result on
> {{FileNotFoundException}} or {{NoSuchFileException}}, if the segments file no
> longer exists due to a new commit. We should fix that by returning a proper
> value for the file's length in this case, maybe -1.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Google Summer of Code 2016
Hi; I've participated at GSoC 2015 and successfully finished my project at Apache Gora. You can check my contribution from here: https://issues.apache.org/jira/browse/GORA-386 After that period, I've been a committer and PMC for Apache Gora: http://gora.apache.org/credits.html I am very very interested at Apache Solr/Lucene. I want to ask that is there any issue which is labeled for GSoC and has a volunteer mentor but nobody is applied? Because I see that there are comments at some issues which asks about volunteer mentors. If there is any issue I will be appreciated to work on it. Thanks; Furkan KAMACI
[jira] [Commented] (LUCENE-4100) Maxscore - Efficient Scoring
[ https://issues.apache.org/jira/browse/LUCENE-4100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15192554#comment-15192554 ] Furkan KAMACI commented on LUCENE-4100: --- I would like to apply this issue as aGSoC project if someone is volunteer for being a mentor. > Maxscore - Efficient Scoring > > > Key: LUCENE-4100 > URL: https://issues.apache.org/jira/browse/LUCENE-4100 > Project: Lucene - Core > Issue Type: Improvement > Components: core/codecs, core/query/scoring, core/search >Affects Versions: 4.0-ALPHA >Reporter: Stefan Pohl > Labels: api-change, gsoc2014, patch, performance > Fix For: 4.9, master > > Attachments: contrib_maxscore.tgz, maxscore.patch > > > At Berlin Buzzwords 2012, I will be presenting 'maxscore', an efficient > algorithm first published in the IR domain in 1995 by H. Turtle & J. Flood, > that I find deserves more attention among Lucene users (and developers). > I implemented a proof of concept and did some performance measurements with > example queries and lucenebench, the package of Mike McCandless, resulting in > very significant speedups. > This ticket is to get started the discussion on including the implementation > into Lucene's codebase. Because the technique requires awareness about it > from the Lucene user/developer, it seems best to become a contrib/module > package so that it consciously can be chosen to be used. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2026) Refactoring of IndexWriter
[ https://issues.apache.org/jira/browse/LUCENE-2026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15192552#comment-15192552 ] Furkan KAMACI commented on LUCENE-2026: --- I would like to apply this issue as aGSoC project if someone is volunteer for being a mentor. > Refactoring of IndexWriter > -- > > Key: LUCENE-2026 > URL: https://issues.apache.org/jira/browse/LUCENE-2026 > Project: Lucene - Core > Issue Type: Improvement > Components: core/index >Reporter: Michael Busch >Assignee: Michael Busch >Priority: Minor > Fix For: 4.9, master > > > I've been thinking for a while about refactoring the IndexWriter into > two main components. > One could be called a SegmentWriter and as the > name says its job would be to write one particular index segment. The > default one just as today will provide methods to add documents and > flushes when its buffer is full. > Other SegmentWriter implementations would do things like e.g. appending or > copying external segments [what addIndexes*() currently does]. > The second component's job would it be to manage writing the segments > file and merging/deleting segments. It would know about > DeletionPolicy, MergePolicy and MergeScheduler. Ideally it would > provide hooks that allow users to manage external data structures and > keep them in sync with Lucene's data during segment merges. > API wise there are things we have to figure out, such as where the > updateDocument() method would fit in, because its deletion part > affects all segments, whereas the new document is only being added to > the new segment. > Of course these should be lower level APIs for things like parallel > indexing and related use cases. That's why we should still provide > easy to use APIs like today for people who don't need to care about > per-segment ops during indexing. So the current IndexWriter could > probably keeps most of its APIs and delegate to the new classes. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5152) EdgeNGramFilterFactory deletes token
[
https://issues.apache.org/jira/browse/SOLR-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14909451#comment-14909451
]
Furkan KAMACI commented on SOLR-5152:
-
Thanks [~urusha] :) [~thetaphi] I think that this patch should be merged to
source code.
> EdgeNGramFilterFactory deletes token
>
>
> Key: SOLR-5152
> URL: https://issues.apache.org/jira/browse/SOLR-5152
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 4.4
>Reporter: Christoph Lingg
> Attachments: SOLR-5152-v5.0.0.patch, SOLR-5152.patch
>
>
> I am using EdgeNGramFilterFactory in my schema.xml
> {code:xml} positionIncrementGap="100">
>
>
> maxGramSize="10" side="front" />
>
> {code}
> Some tokens in my index only consist of one character, let's say {{R}}.
> minGramSize is set to 2 and is bigger than the length of the token. I
> expected the NGramFilter to left {{R}} unchanged but in fact it is deleting
> the token.
> For my use case this interpretation is undesirable, and probably for most use
> cases too!?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-5152) EdgeNGramFilterFactory deletes token
[
https://issues.apache.org/jira/browse/SOLR-5152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14909451#comment-14909451
]
Furkan KAMACI edited comment on SOLR-5152 at 9/26/15 8:04 PM:
--
Thanks [~urusha] :) [~thetaphi] I think that my implementation should be merged
to source code.
was (Author: kamaci):
Thanks [~urusha] :) [~thetaphi] I think that this patch should be merged to
source code.
> EdgeNGramFilterFactory deletes token
>
>
> Key: SOLR-5152
> URL: https://issues.apache.org/jira/browse/SOLR-5152
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 4.4
>Reporter: Christoph Lingg
> Attachments: SOLR-5152-v5.0.0.patch, SOLR-5152.patch
>
>
> I am using EdgeNGramFilterFactory in my schema.xml
> {code:xml} positionIncrementGap="100">
>
>
> maxGramSize="10" side="front" />
>
> {code}
> Some tokens in my index only consist of one character, let's say {{R}}.
> minGramSize is set to 2 and is bigger than the length of the token. I
> expected the NGramFilter to left {{R}} unchanged but in fact it is deleting
> the token.
> For my use case this interpretation is undesirable, and probably for most use
> cases too!?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5840) UpdateRequest does not check lastCommitWithin and commitWithin properly
[
https://issues.apache.org/jira/browse/SOLR-5840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14550873#comment-14550873
]
Furkan KAMACI commented on SOLR-5840:
-
[~thetaphi] could you check my patch?
UpdateRequest does not check lastCommitWithin and commitWithin properly
---
Key: SOLR-5840
URL: https://issues.apache.org/jira/browse/SOLR-5840
Project: Solr
Issue Type: Bug
Affects Versions: 4.6.1, 4.7
Reporter: Furkan KAMACI
Fix For: 4.9, Trunk
Attachments: SOLR-5840.patch
{code}
...
Integer lastCommitWithin = -1;
...
Integer commitWithin = null;
...
if (overwrite != lastOverwrite || commitWithin != lastCommitWithin ||
docLists.size() == 0) {
docList = new LinkedHashMapSolrInputDocument,MapString,Object();
docLists.add(docList);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5841) getSolrConfigFromZk May Not Work As Intended also May Produce a Null Pointer Exception
[
https://issues.apache.org/jira/browse/SOLR-5841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14550880#comment-14550880
]
Furkan KAMACI commented on SOLR-5841:
-
[~thetaphi] could you check my patch?
getSolrConfigFromZk May Not Work As Intended also May Produce a Null Pointer
Exception
--
Key: SOLR-5841
URL: https://issues.apache.org/jira/browse/SOLR-5841
Project: Solr
Issue Type: Bug
Affects Versions: 4.6.1, 4.7
Reporter: Furkan KAMACI
Fix For: 4.9, Trunk
Attachments: SOLR-5841.patch
getSolrConfigFromZk method at ZkContainer is as follows:
{code}
public SolrConfig getSolrConfigFromZk(String zkConfigName, String
solrConfigFileName,
SolrResourceLoader resourceLoader) {
SolrConfig cfg = null;
try {
byte[] config = zkController.getConfigFileData(zkConfigName,
solrConfigFileName);
InputSource is = new InputSource(new ByteArrayInputStream(config));
is.setSystemId(SystemIdResolver
.createSystemIdFromResourceName(solrConfigFileName));
cfg = solrConfigFileName == null ? new SolrConfig(resourceLoader,
SolrConfig.DEFAULT_CONF_FILE, is) : new SolrConfig(resourceLoader,
solrConfigFileName, is);
} catch (Exception e) {
throw new SolrException(SolrException.ErrorCode.SERVER_ERROR,
getSolrConfigFromZK failed for + zkConfigName +
+ solrConfigFileName, e);
}
return cfg;
}
{code}
createSystemIdFromResourceName method has that line:
{code}
name = name.replace(File.separatorChar, '/');
{code}
and there is a check condition for solrConfigFileName getSolrConfigFromZk so
createSystemIdFromResourceName may throw a null pointer exception. On the
other hand if solrConfigFileName is null this line will not work as expected:
{code}
byte[] config = zkController.getConfigFileData(zkConfigName,
solrConfigFileName);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5332) Add preserve original setting to the EdgeNGramFilterFactory
[ https://issues.apache.org/jira/browse/SOLR-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14345260#comment-14345260 ] Furkan KAMACI commented on SOLR-5332: - [~simon.endele] You can check my patch at SOLR-5152. I've applied a patch there and this issue become a duplicate. Add preserve original setting to the EdgeNGramFilterFactory - Key: SOLR-5332 URL: https://issues.apache.org/jira/browse/SOLR-5332 Project: Solr Issue Type: Wish Affects Versions: 4.4, 4.5, 4.5.1, 4.6 Reporter: Alexander S. Fix For: 5.1 Hi, as described here: http://lucene.472066.n3.nabble.com/Help-to-figure-out-why-query-does-not-match-td4086967.html the problem is in that if you have these 2 strings to index: 1. facebook.com/someuser.1 2. facebook.com/someveryandverylongusername and the edge ngram filter factory with min and max gram size settings 2 and 25, search requests for these urls will fail. But search requests for: 1. facebook.com/someuser 2. facebook.com/someveryandverylonguserna will work properly. It's because first url has 1 at the end, which is lover than the allowed min gram size. In the second url the user name is longer than the max gram size (27 characters). Would be good to have a preserve original option, that will add the original string to the index if it does not fit the allowed gram size, so that 1 and someveryandverylongusername tokens will also be added to the index. Best, Alex -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Unrelated Features within Data at Solr
Hi;
As you know that commitWithin is a nice feature for Solr. You can either
use it via URL as a query parameter or within documents to index. As like:
{add:{ doc:{id:change.me,title:change.me
},boost:1.0,overwrite:true,commitWithin:1000}}
However I think that is is not a feature of data and it should not be
permitted within data to index.
I have a use case for it: I have designed an infrastructure that drops url
parameters that is not related to data (as like commit or commitWithin).
However as Solr supports a non-data related feature within data as a meta
data I could not drop it and I have to analyze all data or customize Solr.
What do you think about that? Does it a good design to allow something like
that within data as meta data?
Thanks;
Furkan KAMACI
Re: Unrelated Features within Data at Solr
By the way, I think that I can drop that parameter within a custom
UpdateRequestProcessor?
2014-05-22 17:32 GMT+03:00 Furkan KAMACI furkankam...@gmail.com:
Hi Alexandre;
Actually I do not want to skip them. I just want to drop commitWithin
parameter. It seems that I have to customize Solr for it. I think that it
would be nice if commitWithin had been only query parameter instead of
sending such kind of information within data too.
Thanks;
Furkan KAMACI
2014-05-22 17:02 GMT+03:00 Alexandre Rafalovitch arafa...@gmail.com:
Can you have a custom UpdateRequestProcessor in the chain that just
skips processing such requests?
Regards,
Alex.
Personal website: http://www.outerthoughts.com/
Current project: http://www.solr-start.com/ - Accelerating your Solr
proficiency
On Thu, May 22, 2014 at 6:34 PM, Furkan KAMACI furkankam...@gmail.com
wrote:
Hi;
As you know that commitWithin is a nice feature for Solr. You can
either use
it via URL as a query parameter or within documents to index. As like:
{add:{
doc:{id:change.me,title:change.me
},boost:1.0,overwrite:true,commitWithin:1000}}
However I think that is is not a feature of data and it should not be
permitted within data to index.
I have a use case for it: I have designed an infrastructure that drops
url
parameters that is not related to data (as like commit or commitWithin).
However as Solr supports a non-data related feature within data as a
meta
data I could not drop it and I have to analyze all data or customize
Solr.
What do you think about that? Does it a good design to allow something
like
that within data as meta data?
Thanks;
Furkan KAMACI
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Unrelated Features within Data at Solr
Hi Alexandre;
Actually I do not want to skip them. I just want to drop commitWithin
parameter. It seems that I have to customize Solr for it. I think that it
would be nice if commitWithin had been only query parameter instead of
sending such kind of information within data too.
Thanks;
Furkan KAMACI
2014-05-22 17:02 GMT+03:00 Alexandre Rafalovitch arafa...@gmail.com:
Can you have a custom UpdateRequestProcessor in the chain that just
skips processing such requests?
Regards,
Alex.
Personal website: http://www.outerthoughts.com/
Current project: http://www.solr-start.com/ - Accelerating your Solr
proficiency
On Thu, May 22, 2014 at 6:34 PM, Furkan KAMACI furkankam...@gmail.com
wrote:
Hi;
As you know that commitWithin is a nice feature for Solr. You can either
use
it via URL as a query parameter or within documents to index. As like:
{add:{
doc:{id:change.me,title:change.me
},boost:1.0,overwrite:true,commitWithin:1000}}
However I think that is is not a feature of data and it should not be
permitted within data to index.
I have a use case for it: I have designed an infrastructure that drops
url
parameters that is not related to data (as like commit or commitWithin).
However as Solr supports a non-data related feature within data as a meta
data I could not drop it and I have to analyze all data or customize
Solr.
What do you think about that? Does it a good design to allow something
like
that within data as meta data?
Thanks;
Furkan KAMACI
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3538) fix java7 warnings in the source code
[ https://issues.apache.org/jira/browse/LUCENE-3538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13975928#comment-13975928 ] Furkan KAMACI commented on LUCENE-3538: --- [~joecabrera] I've fixed some other issues and I'will take into account it soon. fix java7 warnings in the source code - Key: LUCENE-3538 URL: https://issues.apache.org/jira/browse/LUCENE-3538 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Labels: Java7, newdev Now that oracle has fixed java7 bugs, I imagine some users will want to use it. Currently if you compile lucene's code with java7 you get a ton of warnings... lets clean this up -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Exception while unmarshalling response in SolrJ
Hi; I've answered a similar question at mail list. Please check it and give your feedbacks. If I have time I will check it with a Play App. Thanks; Furkan KAMACI 13 Nis 2014 19:00 tarihinde Shawn Heisey s...@elyograg.org yazdı: On 4/12/2014 11:46 PM, Prathik Puthran wrote: Hi, I am using SolrJ client to send request to Solr. But instead of calling Solr directly SolrJ communicates with my proxy server which in turn calls Solr and gets the response in javabin format and returns back the response to the client in the same format. The proxy server is written using play framework and just sends request to Solr and returns the HTTP response to client. Below is the exception I get in SolrJ client library when it tries to unmarshall the javabin response. I'm using Solrj 4.7.0. How can I fix this? Exception Stack trace: *Exception in thread main org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:477) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:199) at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:90) at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:301) at com.br.solr.Main.main(Main.java:20) Caused by: java.lang.NullPointerException at org.apache.solr.common.util.JavaBinCodec.readExternString(JavaBinCodec.java:769) at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:192) at org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:116) at org.apache.solr.client.solrj.impl.BinaryResponseParser.processResponse(BinaryResponseParser.java:43) at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:475) ... 4 more This started as a thread on the user list where someone else put up the same information, but there they said that the Solr and SolrJ versions were 4.3.0. The line numbers in the exception on the user list match up to 4.3.0, and the line numbers here match up to 4.7.0, which is good. In the user list discussion the poster indicated that the production application cannot be changed, but can you set up a testing version and send the request directly to Solr, bypassing the play framework? If you do that and it works, then you'll need to look for help with your play framework code on one of their support venues. They'll need to tell you how to relay the response without changing it. If the request direct to Solr doesn't work, then we can troubleshoot that part of it. The user list is a more appropriate venue. Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Solr Ref Guide vs. Wiki
| I think an interesting side-effect issue here is user perception. I | feel that ElasticSearch (yet, them) get a lot of points not only | because of features (not discussing that here) but because they | actually have taken time to put a polish on the SEO, onboarding and | other human perception aspects. that is exactly true. Search that on Google: solr search parameters and have a look at the results. Then search that: elasticsearch search parameters. You can feel that there has been done a work for SEO at elasticsearch side. When I started to learn Solr I read every thing, every thing that I can find. These include Solr wiki, books, websites about Solr and every e-mail at mail list. However is it usual that there were still some pages at wiki that I've not seen it before. I've clicked every link at wiki but there was some hidden(!) pages that I could not achieve to see it. For example every body knows that Shawn has a page tells something about GC tunning for Solr. Do you know that how to reach that page when you start to read the wiki? Reference guide is pretty good. It is like a book for Solr. You start to read and when you finish it you get a good knowledge about Solr. My suggestion is that: We can rich the Solr guide with links to some external pages if it is necessary. On the other hand we can design a nice web site that explains Solr feautures as like elasticsearch. I personally separate people into four main categories who works with Solr: First category: He uses Solr, wants to improve search performance, tunning etc. etc. but do not know the implementation details very much. Second category: He is interesting about scalability, tunning etc. of Solr. Third category: He is interesting about linguistic/search part of Solr (Lucene). Forth category: He is interesting about developing Solr. So, a wiki should point to the people who uses it, who wants to operate it, who wants to improve search benefit and who wants to develop it. My personal idea is that: first category is very important too. When you read the guide of Elasticsearch it is simple and explains the main things (i.e. you can compare the analyzer page at Elasticsearch and Solr). People want to startup a system and do not want to do much more thing (I know it is impossible). We can help address to such kind of audience too (I know that Solr and Elasticsearch audince are not same). I mean a web page explains Solr as like elasticsearch and a guide (with links to other resources) that addresses to both four category would be nice. All in all I would want to help Solr for such kind of documentation (I can work with Alexandre collaboratively). It would be nice if we have something like that. Thanks; Furkan KAMACI 2014-04-05 6:21 GMT+03:00 Alexandre Rafalovitch arafa...@gmail.com: +1 on consolidating to the Reference Guide and figuring out the way to make wiki a lot less visible. But for a completely different set of reasons than discussed already. [[rant-start]] I think an interesting side-effect issue here is user perception. I feel that ElasticSearch (yet, them) get a lot of points not only because of features (not discussing that here) but because they actually have taken time to put a polish on the SEO, onboarding and other human perception aspects. Solr's messaging is - like many of Apache projects - deeply technical, self-referential and on the main path puts Development before Use (literally, by the order of the wiki sections). Which is _no longer_ representative of the users' needs. Reference guide is a large step in the right direction. Commercial distributions also do their best to do the messaging right, even if often at the expense of pushing Solr into an implementation detail (Cloudera!). But I think this is a case of the tide raising all (Solr-based) boats. Somebody with UX skills can probably deconstruct and reconstruct the user experience and the same information will have a lot more impact. This even applies to technical issues as well. Elastic Search has great success talking about schema-less design and Solr relegates its equivalence to a small section deep in the Wiki/Guide. Same with real-time updates. That's because the site/documentation is organized from the implementation rather than impact points of view. If somebody has resources to throw at this, I would start from the UX and user-onboarding part. Maybe even do that for both Lucene and Solr to emphasize common links. And I would be happy to work with someone on that too. Maybe, there is even a need for a separate super-duper-happy-solr-path mailing group to specialize on that. Something that commercial companies can temporarily throw other non-dev resources at, when required. [[rant-end]] Regards, Alex. P.s. There is a LOT more to the rant, with specific suggestions. And I am walking my talk too (book, solr-start, my nascent mailing list, and a ToDo list to last me next several years of fun projects
Compilation Error at Trunk
Hi; Trunk fails at compile. Here is a similar conversation: http://mail-archives.apache.org/mod_mbox/stanbol-dev/201304.mbox/%3CCAA7LAO2kxNZ=xfq-ejma5d9zyqvok2mays6vewizhrgsjtu...@mail.gmail.com%3E I think that same kind of problem has occurred again. Thanks; Furkan KAMACI
Re: Compilation Error at Trunk
Don't mind, mail sent to wrong mail list. 2014-03-29 16:58 GMT+02:00 Furkan KAMACI furkankam...@gmail.com: Hi; Trunk fails at compile. Here is a similar conversation: http://mail-archives.apache.org/mod_mbox/stanbol-dev/201304.mbox/%3CCAA7LAO2kxNZ=xfq-ejma5d9zyqvok2mays6vewizhrgsjtu...@mail.gmail.com%3E I think that same kind of problem has occurred again. Thanks; Furkan KAMACI
Re: solr 4.7 index time
Hi; You should give us more information. On the other hand you can ask your question at user list. Thanks; Furkan KAMACI 27 Mar 2014 03:31 tarihinde Pradeep Pujari prade...@rocketmail.com yazdı: Hi All, I am using DIH to index data 600K solr docs. This data is in taxonomy like structure. All set up solr and db is in same subnet and in cloud. It takes 10 hours for indexing. DIH opens 3 db connections for 3 entities. 8 Gig RAM dual core bu not SSD. Any pointers? Thanks, Pradeep
[jira] [Commented] (SOLR-5852) Add CloudSolrServer helper method to connect to a ZK ensemble
[
https://issues.apache.org/jira/browse/SOLR-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13943613#comment-13943613
]
Furkan KAMACI commented on SOLR-5852:
-
bq. Yeah, I can live with that 'cause it doesn't require regexes, or really any
complex logic.
I think so. I tried to explain same idea that we should pass it to Zookeeper
class. Because if any logic changes within Zookeeper class we have to change
our constructor too.
bq. (String chroot, ListString hosts)
this is a nice signature for us.
It is not important but: (ListString hosts, String chroot) maybe good
because of chroot is not mandatory and it seems me more human readeble not to
pass a null value at first paramater. Also there may be a signature as like
(ListString hosts) too for whom does not use a chroot parameter.
Add CloudSolrServer helper method to connect to a ZK ensemble
-
Key: SOLR-5852
URL: https://issues.apache.org/jira/browse/SOLR-5852
Project: Solr
Issue Type: Improvement
Reporter: Varun Thacker
Attachments: SOLR-5852-SH.patch, SOLR-5852-SH.patch, SOLR-5852.patch,
SOLR-5852_FK.patch, SOLR-5852_FK.patch
We should have a CloudSolrServer constructor which takes a list of ZK servers
to connect to.
Something Like
{noformat}
public CloudSolrServer(String... zkHost);
{noformat}
- Document the current constructor better to mention that to connect to a ZK
ensemble you can pass a comma-delimited list of ZK servers like
zk1:2181,zk2:2181,zk3:2181
- Thirdly should getLbServer() and getZKStatereader() be public?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5852) Add CloudSolrServer helper method to connect to a ZK ensemble
[
https://issues.apache.org/jira/browse/SOLR-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13941576#comment-13941576
]
Furkan KAMACI commented on SOLR-5852:
-
[~elyograg] Actually I tried to mention different approaches at my comment I
and attached a patch for first style. User can pass chroot as a parameter at
constructor and so there will be no need to pass chroot at the end of ever
Host:Port pair and need to check it at constructor.
Add CloudSolrServer helper method to connect to a ZK ensemble
-
Key: SOLR-5852
URL: https://issues.apache.org/jira/browse/SOLR-5852
Project: Solr
Issue Type: Improvement
Reporter: Varun Thacker
Attachments: SOLR-5852-SH.patch, SOLR-5852.patch, SOLR-5852_FK.patch,
SOLR-5852_FK.patch
We should have a CloudSolrServer constructor which takes a list of ZK servers
to connect to.
Something Like
{noformat}
public CloudSolrServer(String... zkHost);
{noformat}
- Document the current constructor better to mention that to connect to a ZK
ensemble you can pass a comma-delimited list of ZK servers like
zk1:2181,zk2:2181,zk3:2181
- Thirdly should getLbServer() and getZKStatereader() be public?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3122) Cascaded grouping
[ https://issues.apache.org/jira/browse/LUCENE-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13941727#comment-13941727 ] Furkan KAMACI commented on LUCENE-3122: --- [~mikemccand] Could you explain this issue a bit more? Cascaded grouping - Key: LUCENE-3122 URL: https://issues.apache.org/jira/browse/LUCENE-3122 Project: Lucene - Core Issue Type: Improvement Components: modules/grouping Reporter: Michael McCandless Labels: gsoc2014 Fix For: 4.8 Similar to SOLR-2526, in that you are grouping on 2 separate fields, but instead of treating those fields as a single grouping by a compound key, this change would let you first group on key1 for the primary groups and then secondarily on key2 within the primary groups. Ie, the result you get back would have groups A, B, C (grouped by key1) but then the documents within group A would be grouped by key 2. I think this will be important for apps whose documents are the product of denormalizing, ie where the Lucene document is really a sub-document of a different identifier field. Borrowing an example from LUCENE-3097, you have doctors but each doctor may have multiple offices (addresses) where they practice and so you index doctor X address as your lucene documents. In this case, your identifier field (that which counts for facets, and should be grouped for presentation) is doctorid. When you offer users search over this index, you'd likely want to 1) group by distance (ie, 0.1 miles, 0.2 miles, etc., as a function query), but 2) also group by doctorid, ie cascaded grouping. I suspect this would be easier to implement than it sounds: the per-group collector used by the 2nd pass grouping collector for key1's grouping just needs to be another grouping collector. Spookily, though, that collection would also have to be 2-pass, so it could get tricky since grouping is sort of recursing on itself once we have LUCENE-3112, though, that should enable efficient single pass grouping by the identifier (doctorid). -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Google Summer of Code
Hi; I want to apply for Google Summer of Code if I can catch up the deadline. I've checked the issues. I want to ask that is there any issue which is labeled for GSoC and has a volunteer mentor but nobody is applied? Because I see that there are comments at some issues which asks about volunteer mentors. If there is any issue I will be appreciated to work on it. Thanks; Furkan KAMACI
Re: Google Summer of Code
Hi Michael; Thanks for the explanation. Furkan KAMACI 2014-03-20 17:12 GMT+02:00 Michael McCandless luc...@mikemccandless.com: Unfortunately, the only two GSoC mentors we seem to have this year is David Smiley and myself, and we each are already signed up to mentor one student, and there's at least two other students expressing interest in different issues. So it looks like we have too many students and too few mentors. Mike McCandless http://blog.mikemccandless.com On Thu, Mar 20, 2014 at 9:50 AM, Furkan KAMACI furkankam...@gmail.com wrote: Hi; I want to apply for Google Summer of Code if I can catch up the deadline. I've checked the issues. I want to ask that is there any issue which is labeled for GSoC and has a volunteer mentor but nobody is applied? Because I see that there are comments at some issues which asks about volunteer mentors. If there is any issue I will be appreciated to work on it. Thanks; Furkan KAMACI - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5852) Add CloudSolrServer helper method to connect to a ZK ensemble
[
https://issues.apache.org/jira/browse/SOLR-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13942046#comment-13942046
]
Furkan KAMACI commented on SOLR-5852:
-
[~erickerickson] could you check my comments and my patch?
Add CloudSolrServer helper method to connect to a ZK ensemble
-
Key: SOLR-5852
URL: https://issues.apache.org/jira/browse/SOLR-5852
Project: Solr
Issue Type: Improvement
Reporter: Varun Thacker
Attachments: SOLR-5852-SH.patch, SOLR-5852-SH.patch, SOLR-5852.patch,
SOLR-5852_FK.patch, SOLR-5852_FK.patch
We should have a CloudSolrServer constructor which takes a list of ZK servers
to connect to.
Something Like
{noformat}
public CloudSolrServer(String... zkHost);
{noformat}
- Document the current constructor better to mention that to connect to a ZK
ensemble you can pass a comma-delimited list of ZK servers like
zk1:2181,zk2:2181,zk3:2181
- Thirdly should getLbServer() and getZKStatereader() be public?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Reducing the number of warnings in the codebase
Hi; As being adviser of using Sonar I want to add some more points. First of all such kind of tools shows some metrics other than code warnings and we should show that metrics even we don't use them. In example *sometimes *code complexity is a good measure to review your code. I should mention that code warnings are not listed directly at Sonar. They are separated into categories. Major is an important category to take care on. You can ignore the minor warnings if you want. When I use Sonar and check the codes of my team sometimes I realize that there are false positive warnings. These rules can easily be dropped from Sonar. My idea is that: whether we care Sonar outputs or not we should integrate our project to Sonar instance available at Apache. I've opened a Jira issue for it: https://issues.apache.org/jira/browse/SOLR-5869 and *I'm volunteer to work for it.* All in all I think that these tools (as like PMD or etc.) sometimes really helpful. Try to search for the reasons of every fired bugs and at the end you can see that you've finished Effective Java because of references to items. I know that there are false positives but such things can be discard easily. Other point is that: these tools produces nice graphics that you can see the direction of your project even you don't use its bug warnings, code coverage metrics or something like that. I've created issues about bugs (I've checked all the major ones) and *I've applied patch for them* previously. Some of them are: SOLR-5836, SOLR-5838, SOLR-5839, SOLR-5840, SOLR-5841, LUCENE-5506, LUCENE-5508, LUCENE-5509 Thanks; Furkan KAMACI 2014-03-16 23:34 GMT+02:00 Benson Margulies bimargul...@gmail.com: I think we avoid bikeshed by making incremental changes. If you offer a commit to turn off serial version UID whining, I'll +1 it. And then we iterate, in small doses, agreeing to either spike the warning or change the code. In passing, I will warn you that the IDEs can be very stubborn; in some cases, there is no way to avoid some amount of whining. Eclipse used to insist on warning on every @SuppressWarnings that it didn't understand. It might still. On Sun, Mar 16, 2014 at 5:29 PM, Shawn Heisey s...@elyograg.org wrote: A starting comment: We could bikeshed for *years*. General thought: The more I think about it, the more I like the notion of confining most of the cleanup to trunk. Actual bug fixes and changes that are relatively non-invasive should be backported. On 3/16/2014 2:48 PM, Uwe Schindler wrote: Just because some tool expresses distaste, doesn't imply that everyone here agrees that it's a problem we should fix. Yes that is my biggest problem. Lots of warnings by Eclipse are just bullshit because of the code style in Lucene and for example the way we do things - e.g., it complains about missing close() all the time, just because we use IOUtils.closeWhileHandlingExceptions() for that. My original thought on this was that we should use a combination of SuppressWarnings and actual code changes to eliminate most of the warnings that show up in the well-supported IDEs when they are configured with *default* settings. Uwe brings up a really good point that there are a number of completely useless warnings, but I think there's still value in looking through EVERY default IDE warning and evaluating each one on a case-by-case basis to decide whether that specific warning should be fixed or ignored. It could be a sort of background task with an open Jira for tracking commits. It could also be something that we decide isn't worth the effort. In my experience, the default Sonar rulesets contain many things that people here are prone to disagree with. Start with serialVersionUID: do we care? Why would we care? In what cases to we really believe that a sane person would be using Java serialization with a Lucene/Solr class? We officially don't support serialization, so all warnings are useless. It's just Eclipse that complains for no reason. Project-specific IDE settings for errors/warnings (set by the ant build target) will go a long way towards making the whole situation better. For the current stable branch, we should include settings for anything that we want to ignore on trunk, but only a subset of those problems that get elevated to error status. Sonar can also be a bit cranky; it arranges for various tools to run via mechanisms that sometimes conflict with the ways you might run them yourself. So I'd suggest a process like: 1. Someone proposes a set of (e.g.) checkstyle rules to live by. 2. That ruleset is refined by experiment. 3. We make violations fail the build. Then lather, rinse, repeat for other tools. Yes I agree. I am strongly against PMD or CheckStyle without our own rules. Forbiddeen-apis was invented because of the brokenness of PMD and CheckStyle to detect default Locale/Charset/Timezone violations
[jira] [Commented] (SOLR-5852) Add CloudSolrServer helper method to connect to a ZK ensemble
[
https://issues.apache.org/jira/browse/SOLR-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937853#comment-13937853
]
Furkan KAMACI commented on SOLR-5852:
-
[~elyograg] ConnectStringParser at Zookeeper checks chroot and other invalid
situations. We can give that checking responsibility to Zookeeper. If anything
changes within Zookeeper check condition our CloudSolrServer will not be
affected from it because we will pass that check to Zookeeper and it will
handle it.
I think that we can handle chroot with current situation too. Zookeeper.java
works like that: 127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002/app/a so I can
improve the javadoc and include that: if there is a chroot add it to the end of
the last host string (this is how original Zookeeper code works). All in all if
anybody sends multiple chroot definitions or anything else Zookeeper will
return an error.
Another approach is accepting like that:
127.0.0.1:3000/app/a,127.0.0.1:3001/app/a,127.0.0.1:3002/app/a so parsing if
there any chroot and valid for all hosts etc.
Add CloudSolrServer helper method to connect to a ZK ensemble
-
Key: SOLR-5852
URL: https://issues.apache.org/jira/browse/SOLR-5852
Project: Solr
Issue Type: Improvement
Reporter: Varun Thacker
Attachments: SOLR-5852.patch, SOLR-5852_FK.patch
We should have a CloudSolrServer constructor which takes a list of ZK servers
to connect to.
Something Like
{noformat}
public CloudSolrServer(String... zkHost);
{noformat}
- Document the current constructor better to mention that to connect to a ZK
ensemble you can pass a comma-delimited list of ZK servers like
zk1:2181,zk2:2181,zk3:2181
- Thirdly should getLbServer() and getZKStatereader() be public?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5852) Add CloudSolrServer helper method to connect to a ZK ensemble
[
https://issues.apache.org/jira/browse/SOLR-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Furkan KAMACI updated SOLR-5852:
Attachment: SOLR-5852_FK.patch
I've improved the javadoc. We can use whether SOLR-4620 or this. On the other
hand I can implement another patch according to second approach at my previous
comment.
Add CloudSolrServer helper method to connect to a ZK ensemble
-
Key: SOLR-5852
URL: https://issues.apache.org/jira/browse/SOLR-5852
Project: Solr
Issue Type: Improvement
Reporter: Varun Thacker
Attachments: SOLR-5852.patch, SOLR-5852_FK.patch, SOLR-5852_FK.patch
We should have a CloudSolrServer constructor which takes a list of ZK servers
to connect to.
Something Like
{noformat}
public CloudSolrServer(String... zkHost);
{noformat}
- Document the current constructor better to mention that to connect to a ZK
ensemble you can pass a comma-delimited list of ZK servers like
zk1:2181,zk2:2181,zk3:2181
- Thirdly should getLbServer() and getZKStatereader() be public?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5852) Add CloudSolrServer helper method to connect to a ZK ensemble
[
https://issues.apache.org/jira/browse/SOLR-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937060#comment-13937060
]
Furkan KAMACI commented on SOLR-5852:
-
[~elyograg] I'will improve the patch as you said.
Add CloudSolrServer helper method to connect to a ZK ensemble
-
Key: SOLR-5852
URL: https://issues.apache.org/jira/browse/SOLR-5852
Project: Solr
Issue Type: Improvement
Reporter: Varun Thacker
Attachments: SOLR-5852.patch, SOLR-5852_FK.patch
We should have a CloudSolrServer constructor which takes a list of ZK servers
to connect to.
Something Like
{noformat}
public CloudSolrServer(String... zkHost);
{noformat}
- Document the current constructor better to mention that to connect to a ZK
ensemble you can pass a comma-delimited list of ZK servers like
zk1:2181,zk2:2181,zk3:2181
- Thirdly should getLbServer() and getZKStatereader() be public?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Reducing the number of warnings in the codebase
Hi; I've run FindBugs for Lucene/Solr project. If you use Intellij IDEA you can group the warnings according to their importance. I've opened issues and attached patches for top level warnings/errors (and some others) that FindBugs found. On the other hand I have another suggestion for Lucene/Solr project. When I develop or lead projects I use Sonar. It's so good and it runs really nice open source projects to analyze your code. FindBugs, PMD, Jacoco are just some of them. It also calculates the method complexities, LoC and etc. You can see a live example from here: https://sonar.springsource.org/dashboard/index/4824 I can be volunteer to integrate Sonar into Lucene/Solr project. Thanks; Furkan KAMACI 2014-03-16 11:01 GMT+02:00 Shawn Heisey s...@elyograg.org: With the default settings in Eclipse, the Lucene/Solr codebase shows over 6000 warnings. This is the case for both branch_4x and trunk. I'm no expert, but this does seem a little excessive. If I were to take on the task of reducing this number, what advice can the group give me? Is there someone in particular that I should consider a resource for inevitable dumb questions? I haven't done an exhaustive survey, but I would imagine that most of them can be eliminated fairly easily. I'm fully aware that we may not be able to eliminate them all. One problem with fixing warnings is that the resulting patch(es) would be just as invasive as the recent work to move branch_4x to Java 7. This would complicate any ongoing work, especially large-scale work that is happening onchange-specific branches. A similar topic that may require a separate discussion: FindBugs. Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Reducing the number of warnings in the codebase
hİ; Thanks Michael. I will open a Jira issue for it. Thanks; Furkan KAMACI 2014-03-16 13:35 GMT+02:00 Michael McCandless luc...@mikemccandless.com: On Sun, Mar 16, 2014 at 6:09 AM, Furkan KAMACI furkankam...@gmail.com wrote: I've run FindBugs for Lucene/Solr project. If you use Intellij IDEA you can group the warnings according to their importance. I've opened issues and attached patches for top level warnings/errors (and some others) that FindBugs found. On the other hand I have another suggestion for Lucene/Solr project. When I develop or lead projects I use Sonar. It's so good and it runs really nice open source projects to analyze your code. FindBugs, PMD, Jacoco are just some of them. It also calculates the method complexities, LoC and etc. You can see a live example from here: https://sonar.springsource.org/dashboard/index/4824 +1, Sonar looks really nice! I can be volunteer to integrate Sonar into Lucene/Solr project. Thank you Furkan. Mike McCandless http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Reducing the number of warnings in the codebase
Hi; Here is Apache projects that is analyzed via Sonar: https://analysis.apache.org/all_projects?qualifier=TRK Thanks; Furkan KAMACI 2014-03-16 15:37 GMT+02:00 Furkan KAMACI furkankam...@gmail.com: hİ; Thanks Michael. I will open a Jira issue for it. Thanks; Furkan KAMACI 2014-03-16 13:35 GMT+02:00 Michael McCandless luc...@mikemccandless.com: On Sun, Mar 16, 2014 at 6:09 AM, Furkan KAMACI furkankam...@gmail.com wrote: I've run FindBugs for Lucene/Solr project. If you use Intellij IDEA you can group the warnings according to their importance. I've opened issues and attached patches for top level warnings/errors (and some others) that FindBugs found. On the other hand I have another suggestion for Lucene/Solr project. When I develop or lead projects I use Sonar. It's so good and it runs really nice open source projects to analyze your code. FindBugs, PMD, Jacoco are just some of them. It also calculates the method complexities, LoC and etc. You can see a live example from here: https://sonar.springsource.org/dashboard/index/4824 +1, Sonar looks really nice! I can be volunteer to integrate Sonar into Lucene/Solr project. Thank you Furkan. Mike McCandless http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5869) Analyze Lucene/Solr Project Via Sonar
Furkan KAMACI created SOLR-5869: --- Summary: Analyze Lucene/Solr Project Via Sonar Key: SOLR-5869 URL: https://issues.apache.org/jira/browse/SOLR-5869 Project: Solr Issue Type: Task Affects Versions: 4.7, 4.6.1 Reporter: Furkan KAMACI Fix For: 4.8 Sonar is an open platform used to manage code quality. You can check it from here: http://www.sonarqube.org/ It would be nice if we analyze Lucene/Solr project with Sonar. You can find a list of Apache Projects that's analyzed via Sonar: https://analysis.apache.org/all_projects?qualifier=TRK We should add our project to Sonar instance available at Apache -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5869) Analyze Lucene/Solr Project Via Sonar
[ https://issues.apache.org/jira/browse/SOLR-5869?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13937165#comment-13937165 ] Furkan KAMACI commented on SOLR-5869: - I'll implement a patch for this issue. Analyze Lucene/Solr Project Via Sonar - Key: SOLR-5869 URL: https://issues.apache.org/jira/browse/SOLR-5869 Project: Solr Issue Type: Task Affects Versions: 4.6.1, 4.7 Reporter: Furkan KAMACI Fix For: 4.8 Sonar is an open platform used to manage code quality. You can check it from here: http://www.sonarqube.org/ It would be nice if we analyze Lucene/Solr project with Sonar. You can find a list of Apache Projects that's analyzed via Sonar: https://analysis.apache.org/all_projects?qualifier=TRK We should add our project to Sonar instance available at Apache -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: JIRA SPAM HELP IN GMAIL
Hi Yonik; I use Gmail too and I've divided dev e-mails with filters and assigned them labels. I have dev(includes everything), dev-jira, and dev-filtered (does not include jira e-mails). Also you can filter for VOTE, CONF, JENKINS or etc too. So it is easy to focus on what you want. Thanks; Furkan KAMACI 2014-03-16 15:51 GMT+02:00 Yonik Seeley yo...@heliosearch.com: Forgive the caps... I figured it might show up better amongst the flood of JIRA messages. If you're a gmail user and want to clean up your inbox from the latest flood: - go to settings, then the general tab, and select conversation view off - do a search for Fix Version/s: (was: 4.7)(use the quotes!) - select all, then press select all messages that match this search - archive or delete the messages - return to your inbox and the messages should be gone (the search view will continue displaying the messages even after they have been archived) - go back to settings and restore conversation view on if that's what you started with Any gmail gurus out there know how to select messages (as opposed to entire conversations) when in conversation mode? (basically, any way to skip step #1?) -Yonik http://heliosearch.org - solve Solr GC pauses with off-heap filters and fieldcache - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5032) Implement tool and/or API for moving a replica to a specific node
[ https://issues.apache.org/jira/browse/SOLR-5032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Furkan KAMACI updated SOLR-5032: Attachment: SOLR-5032.patch This is first patch. I will improved code for Overseer.java and OverseerCollectionProcessor.java too but I'll attach that patch later. I've changed handleAddReplica() and handleRemoveReplica() methods. I think that there may be methods wrapper methods for such kind of things that accepts SolrParams as parameter. So I've implemented that wrappers and I could easily write a method that wraps existing actions. I've tested it and works (not for cases which tests Overseer actions). Implement tool and/or API for moving a replica to a specific node - Key: SOLR-5032 URL: https://issues.apache.org/jira/browse/SOLR-5032 Project: Solr Issue Type: New Feature Reporter: Otis Gospodnetic Priority: Minor Attachments: SOLR-5032.patch See http://search-lucene.com/m/Sri8gFljGw -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5130) Implement addReplica Collections API
[ https://issues.apache.org/jira/browse/SOLR-5130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933093#comment-13933093 ] Furkan KAMACI commented on SOLR-5130: - [~shalinmangar] [~noble.paul] is this issue resolved? Implement addReplica Collections API Key: SOLR-5130 URL: https://issues.apache.org/jira/browse/SOLR-5130 Project: Solr Issue Type: Sub-task Components: SolrCloud Reporter: Shalin Shekhar Mangar Assignee: Shalin Shekhar Mangar Fix For: 4.7, 5.0 Attachments: SOLR-5130.patch addReplica API will add a node to a given collection/shard. Parameters: # node # collection # shard (optional) # _route_ (optional) (see SOLR-4221) If shard or _route_ is not specified then physical shards will be created on the node for the given collection using the persisted values of maxShardsPerNode and replicationFactor. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5312) Add a remove node collection admin command
[ https://issues.apache.org/jira/browse/SOLR-5312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933947#comment-13933947 ] Furkan KAMACI commented on SOLR-5312: - [~noble.paul] This issue can be set to Resolved because of its link issues are resolved? Add a remove node collection admin command -- Key: SOLR-5312 URL: https://issues.apache.org/jira/browse/SOLR-5312 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Noble Paul Assignee: Noble Paul If a node goes down or is taken out of the cluster the replicas of the node would still hang around. This command would remove all the replicas where this node is a part of -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5032) Implement tool and/or API for moving a replica to a specific node
[ https://issues.apache.org/jira/browse/SOLR-5032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13933981#comment-13933981 ] Furkan KAMACI commented on SOLR-5032: - [~shalinmangar] I've implemented a solution as a wrapper of that methods. I'll attach initial patch so we can talk about it. Implement tool and/or API for moving a replica to a specific node - Key: SOLR-5032 URL: https://issues.apache.org/jira/browse/SOLR-5032 Project: Solr Issue Type: New Feature Reporter: Otis Gospodnetic Priority: Minor See http://search-lucene.com/m/Sri8gFljGw -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5506) Ignoring the Return Values Of Immutable Objects
[
https://issues.apache.org/jira/browse/LUCENE-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931701#comment-13931701
]
Furkan KAMACI commented on LUCENE-5506:
---
[~mikemccand] I've debugged the code and I see that optimize() method at
Reduce.java has bug (I think so). Right now args[0] is not upper cased properly
so optimize (removing the holes in the rows of the given trie) did not into
take count. Because of optimize() method never runs the bug is not realized. If
the bug is resolved stemmer may work faster. I will open a new Jira for it.
Ignoring the Return Values Of Immutable Objects
---
Key: LUCENE-5506
URL: https://issues.apache.org/jira/browse/LUCENE-5506
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.6.1, 4.7
Reporter: Furkan KAMACI
Priority: Minor
Fix For: 4.8, 5.0
Attachments: LUCENE-5506.patch
I was checking the source code of Lucene and I realized that return values of
immutable objects are ignored at CSVUtil.java and Compile.java as follows:
*CSVUtil.java*:
{code}
/**
* Quote and escape input value for CSV
*/
public static String quoteEscape(String original) {
String result = original;
if (result.indexOf('\') = 0) {
result.replace(\, ESCAPED_QUOTE);
}
if(result.indexOf(COMMA) = 0) {
result = \ + result + \;
}
return result;
}
{code}
*Compile.java*
{code}
if (args.length 1) {
return;
}
args[0].toUpperCase(Locale.ROOT);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5521) Egothor Stemmer Bug for Optimizing (removing holes in the rows) for the given Trie
Furkan KAMACI created LUCENE-5521:
-
Summary: Egothor Stemmer Bug for Optimizing (removing holes in the
rows) for the given Trie
Key: LUCENE-5521
URL: https://issues.apache.org/jira/browse/LUCENE-5521
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.6.1, 4.7
Reporter: Furkan KAMACI
Priority: Minor
Fix For: 4.8
main method at Compile.java has that lines:
{code}
args[0].toUpperCase(Locale.ROOT);
{code}
I've fixed it with LUCENE-5506 However optimize method does not work correctly
and TestCompile.java throws error.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5419) Solr Admin UI Query Result Does Nothing at Error
[ https://issues.apache.org/jira/browse/SOLR-5419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Furkan KAMACI updated SOLR-5419: Description: When you make a query into Solr via Solr Admin Page and if an error occurs there writes Loading.. and nothing happens. i.e. if you write an invalid Request Handler at Query page even response is 404 Not Found Loading... is still there. was: When you make a query into Solr via Solr Admin Page and if error occurs there writes Loading.. and does nothing. i.e. if you write an invalid Request Handler at Query page even response is 404 Not Found Loading... is still there. Solr Admin UI Query Result Does Nothing at Error Key: SOLR-5419 URL: https://issues.apache.org/jira/browse/SOLR-5419 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.5.1, 4.6, 4.6.1, 4.7 Reporter: Furkan KAMACI Priority: Minor Fix For: 4.8 Attachments: SOLR-5419.patch When you make a query into Solr via Solr Admin Page and if an error occurs there writes Loading.. and nothing happens. i.e. if you write an invalid Request Handler at Query page even response is 404 Not Found Loading... is still there. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5419) Solr Admin UI Query Result Does Nothing at Error
[ https://issues.apache.org/jira/browse/SOLR-5419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Furkan KAMACI updated SOLR-5419: Description: When you make a query into Solr via Solr Admin Page and if an error occurs there writes Loading.. and nothing happens. i.e. if you write an invalid Request Handler (something like /select instead of /select) at Query page and even response is 404 Not Found you will see that Loading... is still there and you will not able to understand whether an error occurred or the response is so slow at first glance. was: When you make a query into Solr via Solr Admin Page and if an error occurs there writes Loading.. and nothing happens. i.e. if you write an invalid Request Handler at Query page even response is 404 Not Found Loading... is still there. Solr Admin UI Query Result Does Nothing at Error Key: SOLR-5419 URL: https://issues.apache.org/jira/browse/SOLR-5419 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.5.1, 4.6, 4.6.1, 4.7 Reporter: Furkan KAMACI Priority: Minor Fix For: 4.8 Attachments: SOLR-5419.patch When you make a query into Solr via Solr Admin Page and if an error occurs there writes Loading.. and nothing happens. i.e. if you write an invalid Request Handler (something like /select instead of /select) at Query page and even response is 404 Not Found you will see that Loading... is still there and you will not able to understand whether an error occurred or the response is so slow at first glance. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Solr Admin UI Query Result Does Nothing at Error
Hi; When you make a query into Solr via Solr Admin Page and if an error occurs there writes Loading.. and nothing happens. i.e. if you write an invalid Request Handler (something like /select instead of /select) at Query page and even response is 404 Not Found you will see that Loading... is still there and you will not able to understand whether an error occurred or the response is so slow at first glance. I've resolved that issue with SOLR-5419 and you can check it. Thanks; Furkan KAMACI
[jira] [Commented] (LUCENE-2298) Polish Analyzer
[ https://issues.apache.org/jira/browse/LUCENE-2298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931793#comment-13931793 ] Furkan KAMACI commented on LUCENE-2298: --- I've detected a bug related to this issue. You can check it from here: LUCENE-5521 Polish Analyzer --- Key: LUCENE-2298 URL: https://issues.apache.org/jira/browse/LUCENE-2298 Project: Lucene - Core Issue Type: New Feature Components: modules/analysis Affects Versions: 3.1 Reporter: Robert Muir Assignee: Robert Muir Fix For: 3.1, 4.0-ALPHA Attachments: LUCENE-2298.patch, LUCENE-2298.patch, LUCENE-2298.patch, stemmer_2.7z Andrzej Bialecki has written a Polish stemmer and provided stemming tables for it under Apache License. You can read more about it here: http://www.getopt.org/stempel/ In reality, the stemmer is general code and we could use it for more languages too perhaps. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5512) Remove redundant typing (diamond operator) in trunk
[ https://issues.apache.org/jira/browse/LUCENE-5512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931815#comment-13931815 ] Furkan KAMACI commented on LUCENE-5512: --- You're welcome. I know that reviewing takes a little time :) I also planning to apply a patch for LUCENE-3538 whenever I have time. Remove redundant typing (diamond operator) in trunk --- Key: LUCENE-5512 URL: https://issues.apache.org/jira/browse/LUCENE-5512 Project: Lucene - Core Issue Type: Improvement Reporter: Robert Muir Attachments: LUCENE-5512.patch, LUCENE-5512.patch, LUCENE-5512.patch -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Deleted] (LUCENE-5512) Remove redundant typing (diamond operator) in trunk
[ https://issues.apache.org/jira/browse/LUCENE-5512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Furkan KAMACI updated LUCENE-5512: -- Comment: was deleted (was: [~thetaphi] I can backport it to 4.x I will make a patch for it too.) Remove redundant typing (diamond operator) in trunk --- Key: LUCENE-5512 URL: https://issues.apache.org/jira/browse/LUCENE-5512 Project: Lucene - Core Issue Type: Improvement Reporter: Robert Muir Attachments: LUCENE-5512.patch, LUCENE-5512.patch, LUCENE-5512.patch -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5512) Remove redundant typing (diamond operator) in trunk
[ https://issues.apache.org/jira/browse/LUCENE-5512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13931830#comment-13931830 ] Furkan KAMACI commented on LUCENE-5512: --- [~thetaphi] I can backport it to 4.x I will make a patch for it too. Remove redundant typing (diamond operator) in trunk --- Key: LUCENE-5512 URL: https://issues.apache.org/jira/browse/LUCENE-5512 Project: Lucene - Core Issue Type: Improvement Reporter: Robert Muir Attachments: LUCENE-5512.patch, LUCENE-5512.patch, LUCENE-5512.patch -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5852) Add CloudSolrServer helper method to connect to a ZK ensemble
[
https://issues.apache.org/jira/browse/SOLR-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932233#comment-13932233
]
Furkan KAMACI commented on SOLR-5852:
-
[~varunthacker] I think that getLbServer() may be restricted but
getZKStatereader() can be used to access cluster state for client APIs.
Add CloudSolrServer helper method to connect to a ZK ensemble
-
Key: SOLR-5852
URL: https://issues.apache.org/jira/browse/SOLR-5852
Project: Solr
Issue Type: Improvement
Reporter: Varun Thacker
Attachments: SOLR-5852.patch
We should have a CloudSolrServer constructor which takes a list of ZK servers
to connect to.
Something Like
{noformat}
public CloudSolrServer(String... zkHost);
{noformat}
- Document the current constructor better to mention that to connect to a ZK
ensemble you can pass a comma-delimited list of ZK servers like
zk1:2181,zk2:2181,zk3:2181
- Thirdly should getLbServer() and getZKStatereader() be public?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-5852) Add CloudSolrServer helper method to connect to a ZK ensemble
[
https://issues.apache.org/jira/browse/SOLR-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13932233#comment-13932233
]
Furkan KAMACI edited comment on SOLR-5852 at 3/12/14 7:40 PM:
--
[~varunthacker] I think that getLbServer() may be restricted (if errors are
resolved at test classes) but getZKStatereader() can be used to access cluster
state for client APIs.
was (Author: kamaci):
[~varunthacker] I think that getLbServer() may be restricted but
getZKStatereader() can be used to access cluster state for client APIs.
Add CloudSolrServer helper method to connect to a ZK ensemble
-
Key: SOLR-5852
URL: https://issues.apache.org/jira/browse/SOLR-5852
Project: Solr
Issue Type: Improvement
Reporter: Varun Thacker
Attachments: SOLR-5852.patch
We should have a CloudSolrServer constructor which takes a list of ZK servers
to connect to.
Something Like
{noformat}
public CloudSolrServer(String... zkHost);
{noformat}
- Document the current constructor better to mention that to connect to a ZK
ensemble you can pass a comma-delimited list of ZK servers like
zk1:2181,zk2:2181,zk3:2181
- Thirdly should getLbServer() and getZKStatereader() be public?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5852) Add CloudSolrServer helper method to connect to a ZK ensemble
[
https://issues.apache.org/jira/browse/SOLR-5852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Furkan KAMACI updated SOLR-5852:
Attachment: SOLR-5852_FK.patch
[~varunthacker] I've improved your patched and attached. You can check it.
Add CloudSolrServer helper method to connect to a ZK ensemble
-
Key: SOLR-5852
URL: https://issues.apache.org/jira/browse/SOLR-5852
Project: Solr
Issue Type: Improvement
Reporter: Varun Thacker
Attachments: SOLR-5852.patch, SOLR-5852_FK.patch
We should have a CloudSolrServer constructor which takes a list of ZK servers
to connect to.
Something Like
{noformat}
public CloudSolrServer(String... zkHost);
{noformat}
- Document the current constructor better to mention that to connect to a ZK
ensemble you can pass a comma-delimited list of ZK servers like
zk1:2181,zk2:2181,zk3:2181
- Thirdly should getLbServer() and getZKStatereader() be public?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5512) Remove redundant typing (diamond operator) in trunk
[ https://issues.apache.org/jira/browse/LUCENE-5512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Furkan KAMACI updated LUCENE-5512: -- Attachment: LUCENE-5512.patch I've finished removing redundant typing for trunk. 1221 files has affected from my patch. I've done it for both Lucene and Solr modules. I didn't use any automated tools for it and I've changed even the commented codes to avoid confusion. After I finished removing redundant typing I have reviewed all my changes inside 1221 files and everything seems OK. Code is compiled successfully and all tests are passed. My suggestion is that: if the voting ends up and result is OK to support Java 7 we should apply this patch into trunk as soon as possible. Because it includes many changes and it make Lucene/Solr code much more readable. On the other hand I don't think that it will cause conflict (at least any real conflict) for people who develops code right now. All in all I could have a chance to check nearly all classes of project and it was really good for me. I've noted some issues about project noted some good tips for me when I was checking all the Lucene/Solr project. [~rcmuir] you can check the code and apply the patch if vote passes. Remove redundant typing (diamond operator) in trunk --- Key: LUCENE-5512 URL: https://issues.apache.org/jira/browse/LUCENE-5512 Project: Lucene - Core Issue Type: Improvement Reporter: Robert Muir Attachments: LUCENE-5512.patch, LUCENE-5512.patch, LUCENE-5512.patch -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5419) Solr Admin UI Query Result Does Nothing at Error
[ https://issues.apache.org/jira/browse/SOLR-5419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13930624#comment-13930624 ] Furkan KAMACI commented on SOLR-5419: - I've changed Fix Version/s and Modified Affects Version/s. Solr Admin UI Query Result Does Nothing at Error Key: SOLR-5419 URL: https://issues.apache.org/jira/browse/SOLR-5419 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.5.1, 4.6, 4.6.1, 4.7 Reporter: Furkan KAMACI Priority: Minor Fix For: 4.8 Attachments: SOLR-5419.patch When you make a query into Solr via Solr Admin Page and if error occurs there writes Loading.. and does nothing. i.e. if you write an invalid Request Handler at Query page even response is 404 Not Found Loading... is still there. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5419) Solr Admin UI Query Result Does Nothing at Error
[ https://issues.apache.org/jira/browse/SOLR-5419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Furkan KAMACI updated SOLR-5419: Fix Version/s: (was: 4.7) 4.8 Solr Admin UI Query Result Does Nothing at Error Key: SOLR-5419 URL: https://issues.apache.org/jira/browse/SOLR-5419 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.5.1, 4.6, 4.6.1, 4.7 Reporter: Furkan KAMACI Priority: Minor Fix For: 4.8 Attachments: SOLR-5419.patch When you make a query into Solr via Solr Admin Page and if error occurs there writes Loading.. and does nothing. i.e. if you write an invalid Request Handler at Query page even response is 404 Not Found Loading... is still there. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5419) Solr Admin UI Query Result Does Nothing at Error
[ https://issues.apache.org/jira/browse/SOLR-5419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Furkan KAMACI updated SOLR-5419: Affects Version/s: 4.7 4.6 4.6.1 Solr Admin UI Query Result Does Nothing at Error Key: SOLR-5419 URL: https://issues.apache.org/jira/browse/SOLR-5419 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.5.1, 4.6, 4.6.1, 4.7 Reporter: Furkan KAMACI Priority: Minor Fix For: 4.8 Attachments: SOLR-5419.patch When you make a query into Solr via Solr Admin Page and if error occurs there writes Loading.. and does nothing. i.e. if you write an invalid Request Handler at Query page even response is 404 Not Found Loading... is still there. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5032) Implement tool and/or API for moving a replica to a specific node
[ https://issues.apache.org/jira/browse/SOLR-5032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13930724#comment-13930724 ] Furkan KAMACI commented on SOLR-5032: - [~otis] Could you explian the workflow here? I can work on this issue. Implement tool and/or API for moving a replica to a specific node - Key: SOLR-5032 URL: https://issues.apache.org/jira/browse/SOLR-5032 Project: Solr Issue Type: New Feature Reporter: Otis Gospodnetic Priority: Minor See http://search-lucene.com/m/Sri8gFljGw -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4904) Send internal doc ids and index version in distributed faceting to make queries more compact
[ https://issues.apache.org/jira/browse/SOLR-4904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13930732#comment-13930732 ] Furkan KAMACI commented on SOLR-4904: - [~dmitry_key] is this issue still valid? I can work for this issue? Send internal doc ids and index version in distributed faceting to make queries more compact Key: SOLR-4904 URL: https://issues.apache.org/jira/browse/SOLR-4904 Project: Solr Issue Type: Improvement Components: search Affects Versions: 3.4, 4.3 Reporter: Dmitry Kan This is suggested by [~ab] at bbuzz conf 2013. This makes a lot of sense and works nice with fixing the root cause of issue SOLR-4903. Basically QueryComponent could send internal lucene ids along with the index version number so that in subsequent queries to other solr components, like FacetComponent, the internal ids would be sent. The index version is required to ensure we deal with the same index. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Solr4.7 DataImport 500 Error please help
Hi;
May be you are mixing some jars because of using different versions? On the
other hand you can ask such kind of questions at user mail list instead of
dev.
Thanks;
Furkan KAMACI
2014-03-11 20:05 GMT+02:00 Pradeep Pujari prade...@rocketmail.com:
It looks to me solr_home is not properly defined.
--
*From:* steben 513441...@qq.com
*To:* dev@lucene.apache.org
*Sent:* Tuesday, March 11, 2014 2:34 AM
*Subject:* Solr4.7 DataImport 500 Error please help
HTTP Status 500 - {msg=SolrCore 'collection1' is not available due to init
failure: severeErrors,trace=org.apache.solr.common.SolrException: SolrCore
'collection1' is not available due to init failure: severeErrors at
org.apache.solr.core.CoreContainer.getCore(CoreContainer.java:827) at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:317)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217)
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:225)
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:999)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:565)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at
java.lang.Thread.run(Unknown Source) Caused by:
org.apache.solr.common.SolrException: severeErrors at
org.apache.solr.core.SolrCore.init(SolrCore.java:844) at
org.apache.solr.core.SolrCore.init(SolrCore.java:630) at
org.apache.solr.core.CoreContainer.createFromLocal(CoreContainer.java:562)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:597) at
org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:258) at
org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:250) at
java.util.concurrent.FutureTask.run(Unknown Source) at
java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at
java.util.concurrent.FutureTask.run(Unknown Source) ... 3 more Caused by:
java.lang.NoSuchFieldError: severeErrors at
org.apache.solr.handler.dataimport.DataImportHandler.inform(DataImportHandler.java:121)
at
org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.java:631)
at org.apache.solr.core.SolrCore.init(SolrCore.java:835) ... 11 more
,code=500}
type Status report
message {msg=SolrCore 'collection1' is not available due to init failure:
severeErrors,trace=org.apache.solr.common.SolrException: SolrCore
'collection1' is not available due to init failure: severeErrors at
org.apache.solr.core.CoreContainer.getCore(CoreContainer.java:827) at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:317)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217)
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:225)
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:999)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:565)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:307)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at
java.lang.Thread.run(Unknown Source) Caused by:
org.apache.solr.common.SolrException: severeErrors
[jira] [Commented] (SOLR-5762) SOLR-5658 broke backward compatibility of Javabin format
[
https://issues.apache.org/jira/browse/SOLR-5762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13925623#comment-13925623
]
Furkan KAMACI commented on SOLR-5762:
-
bq. If this is true please open a ticket
Yes of course, it can be easily tested. I will open a Jira issue for it.
SOLR-5658 broke backward compatibility of Javabin format
Key: SOLR-5762
URL: https://issues.apache.org/jira/browse/SOLR-5762
Project: Solr
Issue Type: Bug
Affects Versions: 4.6.1, 4.7
Reporter: Noble Paul
Fix For: 4.7, 4.8, 5.0
Attachments: SOLR-5672.patch, SOLR-5762-test.patch, SOLR-5762.patch,
updateReq_4_5.bin
In SOLR-5658 the docsMap entry was changed from a Map to ListMap this broke
back compat of older clients with 4.6.1 and later
{noformat}
ERROR - 2014-02-20 21:28:36.332; org.apache.solr.common.SolrException;
java.lang.ClassCastException: java.util.LinkedHashMap cannot be cast to
java.util.List
at
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:188)
at
org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:106)
at
org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:58)
at
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:92)
at
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:721)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:417)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:201)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
at
org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:953)
at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1014)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:953)
at
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
at
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
at
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:744)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5844) Backward Compatibility Has Broken For deleteById() at Solrj
Furkan KAMACI created SOLR-5844: --- Summary: Backward Compatibility Has Broken For deleteById() at Solrj Key: SOLR-5844 URL: https://issues.apache.org/jira/browse/SOLR-5844 Project: Solr Issue Type: Bug Affects Versions: 4.6.1, 4.6, 4.7 Reporter: Furkan KAMACI Fix For: 4.8 I have started up a SolrCloud of 4.5.1 * When I use deleteById method of CloudSolrServer via 4.5.1 Solrj it works. * When I use deleteById method of CloudSolrServer via 4.6.0 Solrj it does not work and does not throw error. * When I use deleteById method of CloudSolrServer via 4.6.1 Solrj it does not work and does not throw error. * When I use deleteById method of CloudSolrServer via 4.7.0 Solrj it does not work and does not throw error. So it seems that backward compatibility has broken since 4.6.0 -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5844) Backward Compatibility Has Broken For deleteById() at Solrj
[ https://issues.apache.org/jira/browse/SOLR-5844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13925630#comment-13925630 ] Furkan KAMACI commented on SOLR-5844: - This issue may related to SOLR-5762. Backward Compatibility Has Broken For deleteById() at Solrj --- Key: SOLR-5844 URL: https://issues.apache.org/jira/browse/SOLR-5844 Project: Solr Issue Type: Bug Affects Versions: 4.6, 4.6.1, 4.7 Reporter: Furkan KAMACI Fix For: 4.8 I have started up a SolrCloud of 4.5.1 * When I use deleteById method of CloudSolrServer via 4.5.1 Solrj it works. * When I use deleteById method of CloudSolrServer via 4.6.0 Solrj it does not work and does not throw error. * When I use deleteById method of CloudSolrServer via 4.6.1 Solrj it does not work and does not throw error. * When I use deleteById method of CloudSolrServer via 4.7.0 Solrj it does not work and does not throw error. So it seems that backward compatibility has broken since 4.6.0 -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5506) Ignoring the Return Values Of Immutable Objects
[
https://issues.apache.org/jira/browse/LUCENE-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13925642#comment-13925642
]
Furkan KAMACI commented on LUCENE-5506:
---
[~mikemccand] I'll check the test case.
Ignoring the Return Values Of Immutable Objects
---
Key: LUCENE-5506
URL: https://issues.apache.org/jira/browse/LUCENE-5506
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.6.1, 4.7
Reporter: Furkan KAMACI
Priority: Minor
Fix For: 4.8, 5.0
Attachments: LUCENE-5506.patch
I was checking the source code of Lucene and I realized that return values of
immutable objects are ignored at CSVUtil.java and Compile.java as follows:
*CSVUtil.java*:
{code}
/**
* Quote and escape input value for CSV
*/
public static String quoteEscape(String original) {
String result = original;
if (result.indexOf('\') = 0) {
result.replace(\, ESCAPED_QUOTE);
}
if(result.indexOf(COMMA) = 0) {
result = \ + result + \;
}
return result;
}
{code}
*Compile.java*
{code}
if (args.length 1) {
return;
}
args[0].toUpperCase(Locale.ROOT);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5512) Remove redundant typing (diamond operator) in trunk
[ https://issues.apache.org/jira/browse/LUCENE-5512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13925730#comment-13925730 ] Furkan KAMACI commented on LUCENE-5512: --- I'm running tests for Lucene for last time. If all tests pass I will add patch. When I finish Solr part I will start to try-with resources. Remove redundant typing (diamond operator) in trunk --- Key: LUCENE-5512 URL: https://issues.apache.org/jira/browse/LUCENE-5512 Project: Lucene - Core Issue Type: Improvement Reporter: Robert Muir Attachments: LUCENE-5512.patch -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5512) Remove redundant typing (diamond operator) in trunk
[ https://issues.apache.org/jira/browse/LUCENE-5512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Furkan KAMACI updated LUCENE-5512: -- Attachment: LUCENE-5512.patch Lucene part is OK. I will appy same procedure to the Solr module too. Remove redundant typing (diamond operator) in trunk --- Key: LUCENE-5512 URL: https://issues.apache.org/jira/browse/LUCENE-5512 Project: Lucene - Core Issue Type: Improvement Reporter: Robert Muir Attachments: LUCENE-5512.patch, LUCENE-5512.patch -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5512) Remove redundant typing (diamond operator) in trunk
[ https://issues.apache.org/jira/browse/LUCENE-5512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13925900#comment-13925900 ] Furkan KAMACI commented on LUCENE-5512: --- Solr module is OK. I will test it and attach whole patch. Remove redundant typing (diamond operator) in trunk --- Key: LUCENE-5512 URL: https://issues.apache.org/jira/browse/LUCENE-5512 Project: Lucene - Core Issue Type: Improvement Reporter: Robert Muir Attachments: LUCENE-5512.patch, LUCENE-5512.patch -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Move to Java 7 in Lucene/Solr 4.8, use Java 8 in trunk (once officially released)
Hi All; I am not a committer yet but I want share my thoughts as a contributor and a Solr user to give an example from real life. I use SolrCloud for one year (our product is at pre-prod step) and I have hundreds of servers at my company and nearly half of them are SolrCloud. We also have an Hadoop cluster which runs Map/Reduce jobs. We also use and test Ambari and Hortonworks and we also use Giraph at our Hadoop side. Just a few weeks ago we've faced with an issue that some of projects that we use was not compatible with Java 7 (yes its weird.) So we had to change the Java version of our servers until we maintain it (I've updated a project from Java 7 to Java 6 just because of that.) I've separated the SolrCloud nodes from other parts of our ecosystem as usual and I've never faced with a problem as like that with my management. I use Java 1.7 u25 as recommended and because of it is stable. However I see that even it is more logical to upgrade to new versions of Java (if it is stable) sometimes there maybe some limitations for companies. If I could generate Solr indexes via Map/Reduce at my current architecture I was not able to use it because of that Java 6 problem. I'm currently reviewing Java 8 book of Manning and I know that Java 8 has great features. However my thought is that: Java 6 might be considered as outdated and it is applicable that if we don't support it. However I think that Java 7 will be used for a long time within companies and trunk should support Java 7 too at least until Java 8 has a common usage or until the end of life of Java 7 support (it seems that it will be supported at least until March 2015). Thanks; Furkan KAMACI 2014-03-09 16:07 GMT+02:00 Erick Erickson erickerick...@gmail.com: Solr/Lucene 4.8 - Java 7 +1 Solr/Lucene 5.0 - Java8 -1 for now. +1 as we get closer to releasing 5.0. There's still plenty of cruft in trunk that's there only because of needing to support Java6 in the 4.x code line, I think having a period when we can freely clean up some of the Java 6 leftovers in trunk and 4.8+ without having to _additionally_ deal with Java 8 changes that only apply to trunk would be useful. Wouldn't it be nice to have just a few months where one didn't have to even think about it ;) As far as 5.0 is concerned... The point that organizations move much more slowly than we do in terms of adopting new Java releases is well taken. I suspect that, no matter what, if we move 5.0 to Java 8, we'll have quite a long period (3 years as a wild guess) where some people will be unable to use 5.x because of organizational (not technical) issues. IMO, it's perfectly legitimate to say that Solr development shouldn't be held up because organization X is unwilling to use Java8 thus I think we should go forward with 5x and Java8, just not quite yet. Just don't be surprised by people saying that they can't use Java8 in 2016 and would someone backport fix/improvements X, Y, and Z :)... On Sun, Mar 9, 2014 at 9:31 AM, Tommaso Teofili tommaso.teof...@gmail.com wrote: 2014-03-08 17:17 GMT+01:00 Uwe Schindler u...@thetaphi.de: Hi all, Java 8 will get released (hopefully, but I trust the release plan!) on March 18, 2014. Because of this, lots of developers will move to Java 8, too. This makes maintaining 3 versions for developing Lucene 4.x not easy anymore (unless you have cool JAVA_HOME cmd launcher scripts using StExBar available for your Windows Explorer - or similar stuff in Linux/Mäc). We already discussed in another thread about moving to release trunk as 5.0, but people disagreed and preferred to release 4.8 with a minimum of Java 7. This is perfectly fine, as nobody should run Lucene or Solr on an unsupported platform anymore. If they upgrade to 4.8, they should also upgrade their infrastructure - this is a no-brainer. In Lucene trunk we switch to Java 8 as soon as it is released (in 10 days). Now the good things: We don't need to support JRockit anymore, no need to support IBM J9 in trunk (unless they release a new version based on Java 8). So the vote here is about: [.] Move Lucene/Solr 4.8 (means branch_4x) to Java 7 and backport all Java 7-related issues (FileChannel improvements, diamond operator,...). +1 [.] Move Lucene/Solr trunk to Java 8 and allow closures in source code. This would make some APIs much nicer. Our infrastructure mostly supports this, only ECJ Javadoc linting is not yet possible, but forbidden-apis supports Java 8 with all its crazy new stuff. -1 I think a move to Java 8 is worth only if and when Java 8 has proven to be stable, also I don't think (that's another thread though) we're (and should be) moving fast towards release 5, so there's likely plenty of time for having Java 8 out for some time before we have 5.0 out. Tommaso You can vote separately for both items! Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213
[jira] [Commented] (LUCENE-5512) Remove redundant typing (diamond operator) in trunk
[ https://issues.apache.org/jira/browse/LUCENE-5512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13925242#comment-13925242 ] Furkan KAMACI commented on LUCENE-5512: --- Currently I've found 1542 usage for it at trunk. I can work for this issue. Remove redundant typing (diamond operator) in trunk --- Key: LUCENE-5512 URL: https://issues.apache.org/jira/browse/LUCENE-5512 Project: Lucene - Core Issue Type: Improvement Reporter: Robert Muir -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5512) Remove redundant typing (diamond operator) in trunk
[ https://issues.apache.org/jira/browse/LUCENE-5512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13925247#comment-13925247 ] Furkan KAMACI commented on LUCENE-5512: --- I'll not use an automated tool because of it is an important thing so we should be careful. Remove redundant typing (diamond operator) in trunk --- Key: LUCENE-5512 URL: https://issues.apache.org/jira/browse/LUCENE-5512 Project: Lucene - Core Issue Type: Improvement Reporter: Robert Muir -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5843) No way to clear error state of a core that doesn't even exist any more
[ https://issues.apache.org/jira/browse/SOLR-5843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13925316#comment-13925316 ] Furkan KAMACI commented on SOLR-5843: - Could you write down a scenario that I can produce it? I can work on this issue. No way to clear error state of a core that doesn't even exist any more -- Key: SOLR-5843 URL: https://issues.apache.org/jira/browse/SOLR-5843 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.6.1 Reporter: Nathan Neulinger Labels: cloud, failure, initialization Created collections with missing configs - this is known to create a problem state. Those collections have all since been deleted -- but one of my nodes still insists that there are initialization errors. There are no references to those 'failed' cores in any of the cloud tabs, or in ZK, or in the directories on the server itself. There should be some easy way to refresh this state or to clear them out without having to restart the instance. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5512) Remove redundant typing (diamond operator) in trunk
[ https://issues.apache.org/jira/browse/LUCENE-5512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13925325#comment-13925325 ] Furkan KAMACI commented on LUCENE-5512: --- When I finish it I will attach the patch file. Remove redundant typing (diamond operator) in trunk --- Key: LUCENE-5512 URL: https://issues.apache.org/jira/browse/LUCENE-5512 Project: Lucene - Core Issue Type: Improvement Reporter: Robert Muir Attachments: LUCENE-5512.patch -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5512) Remove redundant typing (diamond operator) in trunk
[ https://issues.apache.org/jira/browse/LUCENE-5512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13925373#comment-13925373 ] Furkan KAMACI commented on LUCENE-5512: --- I've finished it. Compilation and tests did not give any error. I will check it one more time and attach the patch. On the other hand I will apply changes for lucene module. Will anybody open a Jira issue for Solr module too or I can apply same things for Solr module too? [~erickerickson] you are right. I've touched many many files in the code base. However I think that it will not cause any conflict (at least any real conflict) for anybody who is working on any issue. I think that the source code of Lucene became cleaner. [~rcmuir] if you want I can do same thing for try-with resources at another Jira issue? Remove redundant typing (diamond operator) in trunk --- Key: LUCENE-5512 URL: https://issues.apache.org/jira/browse/LUCENE-5512 Project: Lucene - Core Issue Type: Improvement Reporter: Robert Muir Attachments: LUCENE-5512.patch -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5762) SOLR-5658 broke backward compatibility of Javabin format
[
https://issues.apache.org/jira/browse/SOLR-5762?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13924861#comment-13924861
]
Furkan KAMACI commented on SOLR-5762:
-
When I use a Solrj version greater than 4.5.1 and use deleteById via
CloudSolrServer for my SolrCloud 4.5.1 I get an error. I think that this bug is
still exists. On the other hand I want to ask a question about applied patch.
What is it for because docMap is not used at anywhere else?
SOLR-5658 broke backward compatibility of Javabin format
Key: SOLR-5762
URL: https://issues.apache.org/jira/browse/SOLR-5762
Project: Solr
Issue Type: Bug
Affects Versions: 4.6.1, 4.7
Reporter: Noble Paul
Fix For: 4.7, 4.8, 5.0
Attachments: SOLR-5672.patch, SOLR-5762-test.patch, SOLR-5762.patch,
updateReq_4_5.bin
In SOLR-5658 the docsMap entry was changed from a Map to ListMap this broke
back compat of older clients with 4.6.1 and later
{noformat}
ERROR - 2014-02-20 21:28:36.332; org.apache.solr.common.SolrException;
java.lang.ClassCastException: java.util.LinkedHashMap cannot be cast to
java.util.List
at
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:188)
at
org.apache.solr.handler.loader.JavabinLoader.parseAndLoadDocs(JavabinLoader.java:106)
at
org.apache.solr.handler.loader.JavabinLoader.load(JavabinLoader.java:58)
at
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:92)
at
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:721)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:417)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:201)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
at
org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:953)
at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1014)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:953)
at
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240)
at
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
at
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:744)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5836) CSVConfig Invalid Check For Equals
Furkan KAMACI created SOLR-5836:
---
Summary: CSVConfig Invalid Check For Equals
Key: SOLR-5836
URL: https://issues.apache.org/jira/browse/SOLR-5836
Project: Solr
Issue Type: Bug
Affects Versions: 4.6.1, 4.7
Reporter: Furkan KAMACI
Priority: Minor
Fix For: 4.8
Attachments: SOLR-5836.patch
When I was checking the source code of Solr I realized that equals method at
CSVConfig.java does an unnecessary or invalid checking as follows:
{code}
/**
* TODO..
* @see java.lang.Object#equals(java.lang.Object)
*/
@Override
public boolean equals(Object obj) {
if (obj == null !(obj instanceof CSVConfig)) {
return false;
}
return super.equals(obj);
//CSVConfig config = (CSVConfig) obj;
//getFill() == config.getFill()
//getFields().equals(config.getFields())
}
{code}
if obj is null it can not be an instance of CSVConfig so it is unnecessary. On
the other hand it does not make a valid check so I have changed the equals
criteria to OR.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5836) CSVConfig Invalid Check For Equals
[
https://issues.apache.org/jira/browse/SOLR-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Furkan KAMACI updated SOLR-5836:
Attachment: SOLR-5836.patch
I've added the patch file.
CSVConfig Invalid Check For Equals
--
Key: SOLR-5836
URL: https://issues.apache.org/jira/browse/SOLR-5836
Project: Solr
Issue Type: Bug
Affects Versions: 4.6.1, 4.7
Reporter: Furkan KAMACI
Priority: Minor
Fix For: 4.8
Attachments: SOLR-5836.patch
When I was checking the source code of Solr I realized that equals method at
CSVConfig.java does an unnecessary or invalid checking as follows:
{code}
/**
* TODO..
* @see java.lang.Object#equals(java.lang.Object)
*/
@Override
public boolean equals(Object obj) {
if (obj == null !(obj instanceof CSVConfig)) {
return false;
}
return super.equals(obj);
//CSVConfig config = (CSVConfig) obj;
//getFill() == config.getFill()
//getFields().equals(config.getFields())
}
{code}
if obj is null it can not be an instance of CSVConfig so it is unnecessary.
On the other hand it does not make a valid check so I have changed the equals
criteria to OR.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5506) Ignoring the Return Values Of Immutable Objects
Furkan KAMACI created LUCENE-5506:
-
Summary: Ignoring the Return Values Of Immutable Objects
Key: LUCENE-5506
URL: https://issues.apache.org/jira/browse/LUCENE-5506
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.6.1, 4.7
Reporter: Furkan KAMACI
Priority: Minor
Fix For: 4.8
I was checking the source code of Lucene and I realized that return values of
immutable objects are ignored at CSVUtil.java and Compile.java as follows:
*CSVUtil.java*:
{code}
/**
* Quote and escape input value for CSV
*/
public static String quoteEscape(String original) {
String result = original;
if (result.indexOf('\') = 0) {
result.replace(\, ESCAPED_QUOTE);
}
if(result.indexOf(COMMA) = 0) {
result = \ + result + \;
}
return result;
}
{code}
*Compile.java*
{code}
if (args.length 1) {
return;
}
args[0].toUpperCase(Locale.ROOT);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5506) Ignoring the Return Values Of Immutable Objects
[
https://issues.apache.org/jira/browse/LUCENE-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Furkan KAMACI updated LUCENE-5506:
--
Attachment: LUCENE-5506.patch
Ignoring the Return Values Of Immutable Objects
---
Key: LUCENE-5506
URL: https://issues.apache.org/jira/browse/LUCENE-5506
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.6.1, 4.7
Reporter: Furkan KAMACI
Priority: Minor
Fix For: 4.8
Attachments: LUCENE-5506.patch
I was checking the source code of Lucene and I realized that return values of
immutable objects are ignored at CSVUtil.java and Compile.java as follows:
*CSVUtil.java*:
{code}
/**
* Quote and escape input value for CSV
*/
public static String quoteEscape(String original) {
String result = original;
if (result.indexOf('\') = 0) {
result.replace(\, ESCAPED_QUOTE);
}
if(result.indexOf(COMMA) = 0) {
result = \ + result + \;
}
return result;
}
{code}
*Compile.java*
{code}
if (args.length 1) {
return;
}
args[0].toUpperCase(Locale.ROOT);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5506) Ignoring the Return Values Of Immutable Objects
[
https://issues.apache.org/jira/browse/LUCENE-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13924905#comment-13924905
]
Furkan KAMACI commented on LUCENE-5506:
---
I've added patch file.
Ignoring the Return Values Of Immutable Objects
---
Key: LUCENE-5506
URL: https://issues.apache.org/jira/browse/LUCENE-5506
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.6.1, 4.7
Reporter: Furkan KAMACI
Priority: Minor
Fix For: 4.8
Attachments: LUCENE-5506.patch
I was checking the source code of Lucene and I realized that return values of
immutable objects are ignored at CSVUtil.java and Compile.java as follows:
*CSVUtil.java*:
{code}
/**
* Quote and escape input value for CSV
*/
public static String quoteEscape(String original) {
String result = original;
if (result.indexOf('\') = 0) {
result.replace(\, ESCAPED_QUOTE);
}
if(result.indexOf(COMMA) = 0) {
result = \ + result + \;
}
return result;
}
{code}
*Compile.java*
{code}
if (args.length 1) {
return;
}
args[0].toUpperCase(Locale.ROOT);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5836) CSVConfig Invalid Check For Equals
[
https://issues.apache.org/jira/browse/SOLR-5836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Furkan KAMACI resolved SOLR-5836.
-
Resolution: Fixed
CSVConfig Invalid Check For Equals
--
Key: SOLR-5836
URL: https://issues.apache.org/jira/browse/SOLR-5836
Project: Solr
Issue Type: Bug
Affects Versions: 4.6.1, 4.7
Reporter: Furkan KAMACI
Priority: Minor
Fix For: 4.8
Attachments: SOLR-5836.patch
When I was checking the source code of Solr I realized that equals method at
CSVConfig.java does an unnecessary or invalid checking as follows:
{code}
/**
* TODO..
* @see java.lang.Object#equals(java.lang.Object)
*/
@Override
public boolean equals(Object obj) {
if (obj == null !(obj instanceof CSVConfig)) {
return false;
}
return super.equals(obj);
//CSVConfig config = (CSVConfig) obj;
//getFill() == config.getFill()
//getFields().equals(config.getFields())
}
{code}
if obj is null it can not be an instance of CSVConfig so it is unnecessary.
On the other hand it does not make a valid check so I have changed the equals
criteria to OR.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5506) Ignoring the Return Values Of Immutable Objects
[
https://issues.apache.org/jira/browse/LUCENE-5506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Furkan KAMACI resolved LUCENE-5506.
---
Resolution: Fixed
Ignoring the Return Values Of Immutable Objects
---
Key: LUCENE-5506
URL: https://issues.apache.org/jira/browse/LUCENE-5506
Project: Lucene - Core
Issue Type: Bug
Affects Versions: 4.6.1, 4.7
Reporter: Furkan KAMACI
Priority: Minor
Fix For: 4.8
Attachments: LUCENE-5506.patch
I was checking the source code of Lucene and I realized that return values of
immutable objects are ignored at CSVUtil.java and Compile.java as follows:
*CSVUtil.java*:
{code}
/**
* Quote and escape input value for CSV
*/
public static String quoteEscape(String original) {
String result = original;
if (result.indexOf('\') = 0) {
result.replace(\, ESCAPED_QUOTE);
}
if(result.indexOf(COMMA) = 0) {
result = \ + result + \;
}
return result;
}
{code}
*Compile.java*
{code}
if (args.length 1) {
return;
}
args[0].toUpperCase(Locale.ROOT);
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Invalid Tooltip for Jira Workflow
Hi; I've opened an issue an applied a patch for it. Then I've resolved it. Tooltip says that: A resolution has been taken, and it is awaiting verification by reporter However reporter is me :) What is the appropriate workflow for such kind of things at Lucene/Solr project? Thanks; Furkan KAMACI
Re: Invalid Tooltip for Jira Workflow
Hi Uwe; I will file a bug report. On the other hand I am not a committer yet but I can resolve an issue if I am the reporter of it. Is this applicable? Thanks; Furkan KAMACI 2014-03-08 18:19 GMT+02:00 Uwe Schindler u...@thetaphi.de: Hi Furkan, File a bug report at Atlassian who develops JIRA! I think, there is nothing we can do about that. We can only globally change the description message for the resolved status - but this would apply for all Apache projects. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de *From:* Furkan KAMACI [mailto:furkankam...@gmail.com] *Sent:* Saturday, March 08, 2014 5:13 PM *To:* dev@lucene.apache.org *Subject:* Invalid Tooltip for Jira Workflow Hi; I've opened an issue an applied a patch for it. Then I've resolved it. Tooltip says that: A resolution has been taken, and it is awaiting verification by reporter However reporter is me :) What is the appropriate workflow for such kind of things at Lucene/Solr project? Thanks; Furkan KAMACI
Re: Invalid Tooltip for Jira Workflow
Also I think that this should a globally change. If a reporter is not a committer and resolved an issue message should be different. If it is not an easy task we can write a generic message for it (i.e. A resolution has been taken, and it is awaiting verification) Thanks; Furkan KAMACI 2014-03-08 18:25 GMT+02:00 Furkan KAMACI furkankam...@gmail.com: Hi Uwe; I will file a bug report. On the other hand I am not a committer yet but I can resolve an issue if I am the reporter of it. Is this applicable? Thanks; Furkan KAMACI 2014-03-08 18:19 GMT+02:00 Uwe Schindler u...@thetaphi.de: Hi Furkan, File a bug report at Atlassian who develops JIRA! I think, there is nothing we can do about that. We can only globally change the description message for the resolved status - but this would apply for all Apache projects. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de *From:* Furkan KAMACI [mailto:furkankam...@gmail.com] *Sent:* Saturday, March 08, 2014 5:13 PM *To:* dev@lucene.apache.org *Subject:* Invalid Tooltip for Jira Workflow Hi; I've opened an issue an applied a patch for it. Then I've resolved it. Tooltip says that: A resolution has been taken, and it is awaiting verification by reporter However reporter is me :) What is the appropriate workflow for such kind of things at Lucene/Solr project? Thanks; Furkan KAMACI
Re: Invalid Tooltip for Jira Workflow
I've opened an issue at Infra. 2014-03-08 18:32 GMT+02:00 Furkan KAMACI furkankam...@gmail.com: Also I think that this should a globally change. If a reporter is not a committer and resolved an issue message should be different. If it is not an easy task we can write a generic message for it (i.e. A resolution has been taken, and it is awaiting verification) Thanks; Furkan KAMACI 2014-03-08 18:25 GMT+02:00 Furkan KAMACI furkankam...@gmail.com: Hi Uwe; I will file a bug report. On the other hand I am not a committer yet but I can resolve an issue if I am the reporter of it. Is this applicable? Thanks; Furkan KAMACI 2014-03-08 18:19 GMT+02:00 Uwe Schindler u...@thetaphi.de: Hi Furkan, File a bug report at Atlassian who develops JIRA! I think, there is nothing we can do about that. We can only globally change the description message for the resolved status - but this would apply for all Apache projects. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de *From:* Furkan KAMACI [mailto:furkankam...@gmail.com] *Sent:* Saturday, March 08, 2014 5:13 PM *To:* dev@lucene.apache.org *Subject:* Invalid Tooltip for Jira Workflow Hi; I've opened an issue an applied a patch for it. Then I've resolved it. Tooltip says that: A resolution has been taken, and it is awaiting verification by reporter However reporter is me :) What is the appropriate workflow for such kind of things at Lucene/Solr project? Thanks; Furkan KAMACI
[jira] [Created] (SOLR-5838) Relative SolrHome Path Bug At AbstractFullDistribZkTestBase
Furkan KAMACI created SOLR-5838:
---
Summary: Relative SolrHome Path Bug At
AbstractFullDistribZkTestBase
Key: SOLR-5838
URL: https://issues.apache.org/jira/browse/SOLR-5838
Project: Solr
Issue Type: Bug
Reporter: Furkan KAMACI
getRelativeSolrHomePath method at AbstractFullDistribZkTestBase has a control
like that:
{code}
if (base.startsWith(.));
base.replaceFirst(\\., new File(.).getName());
{code}
if statement does nothing and result of replaceFirst is ignored.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5838) Relative SolrHome Path Bug At AbstractFullDistribZkTestBase
[
https://issues.apache.org/jira/browse/SOLR-5838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Furkan KAMACI updated SOLR-5838:
Attachment: SOLR-5838.patch
I've applied a patch. Also changed that:
{code}
p.append(.. + File.separator);
{code}
to this:
{code}
p.append(..).append(File.separator);
{code}
Relative SolrHome Path Bug At AbstractFullDistribZkTestBase
Key: SOLR-5838
URL: https://issues.apache.org/jira/browse/SOLR-5838
Project: Solr
Issue Type: Bug
Affects Versions: 4.6.1, 4.7
Reporter: Furkan KAMACI
Fix For: 4.8
Attachments: SOLR-5838.patch
getRelativeSolrHomePath method at AbstractFullDistribZkTestBase has a control
like that:
{code}
if (base.startsWith(.));
base.replaceFirst(\\., new File(.).getName());
{code}
if statement does nothing and result of replaceFirst is ignored.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5838) Relative SolrHome Path Bug At AbstractFullDistribZkTestBase
[
https://issues.apache.org/jira/browse/SOLR-5838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Furkan KAMACI updated SOLR-5838:
Fix Version/s: 4.8
Relative SolrHome Path Bug At AbstractFullDistribZkTestBase
Key: SOLR-5838
URL: https://issues.apache.org/jira/browse/SOLR-5838
Project: Solr
Issue Type: Bug
Affects Versions: 4.6.1, 4.7
Reporter: Furkan KAMACI
Fix For: 4.8
Attachments: SOLR-5838.patch
getRelativeSolrHomePath method at AbstractFullDistribZkTestBase has a control
like that:
{code}
if (base.startsWith(.));
base.replaceFirst(\\., new File(.).getName());
{code}
if statement does nothing and result of replaceFirst is ignored.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
