Re: Welcome Chris Hegarty as Lucene committer

[Koji Sekiguchi]

Welcome and congratulations!

Koji

On 2022/06/01 16:04, Adrien Grand wrote:

I'm pleased to announce that Chris Hegarty has accepted the PMC's
invitation to become a committer.

Chris, the tradition is that new committers introduce themselves with a
brief bio.

Congratulations and welcome!

--
Adrien


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

Re: Welcome Lu Xugang as Lucene committer

[Koji Sekiguchi]

Welcome and congratulations!

Koji

On 2022/06/01 16:07, Adrien Grand wrote:

I'm pleased to announce that Lu Xugang has accepted the PMC's
invitation to become a committer.

Xugang, the tradition is that new committers introduce themselves with a
brief bio.

Congratulations and welcome!

--
Adrien


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

Re: Welcome Guo Feng as Lucene committer

[Koji Sekiguchi]

Welcome, Feng!

Koji


On 2022/01/25 18:09, Adrien Grand wrote:

I'm pleased to announce that Guo Feng has accepted the PMC's
invitation to become a committer.

Feng, the tradition is that new committers introduce themselves with a
brief bio.

Congratulations and welcome!



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

Re: Can we fix timeout exceptions at the bottom of jenkins logs?

[Koji Sekiguchi]

Hi Dawid,

I think I'm not the right person to be asked. I'm sorry for being not useful on 
this...

Koji

On 2021/12/09 17:50, Dawid Weiss wrote:


Hi Koji,

Sorry for addressing you directly here, I thought you may know off the top of 
your head... :)

In many Jenkins builds we have an exception and stack trace at the bottom of 
the build. Like this one:

BUILD SUCCESSFUL in 4h 19m 45s
195 actionable tasks: 195 executed
Build step 'Invoke Gradle script' changed build result to SUCCESS
Archiving artifacts
java.lang.InterruptedException: no matches found within 1
         at hudson.FilePath$ValidateAntFileMask.hasMatch(FilePath.java:3069)
...
No artifacts found that match the file pattern "**/*.events,heapdumps/**,**/hs_err_pid*". 
Configuration error?


I looked at the code and see this is configurable via system properties -

https://www.jenkins.io/doc/book/managing/system-properties/#hudson-filepath-validate_ant_file_mask_bound 



Can we increase this limit per build or somehow on Apache build servers (and on Uwe's machine)? It's 
mildly annoying to see those stack traces in e-mails. I don't think this is configurable in per-job 
plugin settings [1].


Dawid

[1] Screenshot of the config of the archiving plugin.

image.png


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

Re: Welcome Julie Tibshirani to the Lucene PMC

[Koji Sekiguchi]

Congrats and welcome Julie!

Koji

On 2021/12/01 6:49, Adrien Grand wrote:

I'm pleased to announce that Julie Tibshirani has accepted an invitation to 
join the Lucene PMC!

Congratulations Julie, and welcome aboard!

--
Adrien



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

Re: [ANNOUNCE] Apache Lucene 8.11.0 released

[Koji Sekiguchi]

Thank you for your work, Adrien!

> Further details of changes are available in the change log available at:
> http://lucene.apache.org/core/8_11/changes/Changes.html

I got 404 Not Found due to missing "_0" of "8_11_0" in the link for Changes.

Koji

On 2021/11/16 21:59, Adrien Grand wrote:

The Lucene PMC is pleased to announce the release of Apache Lucene 8.11.

Apache Lucene is a high-performance, full-featured text search engine library written entirely in 
Java. It is a technology suitable for nearly any application that requires full-text search, 
especially cross-platform.


This release contains numerous bug fixes, features, optimizations, and improvements, some of which 
are highlighted below. The release is available for immediate download at:

https://lucene.apache.org/core/downloads.html 


Lucene 8.11 Release Highlights
  - Facets now properly ignore deleted documents when accumulating facet counts 
for all documents.
  - CheckIndex can run concurrently.

Further details of changes are available in the change log available at: 
http://lucene.apache.org/core/8_11/changes/Changes.html 



Please report any feedback to the mailing lists (http://lucene.apache.org/core/discussion.html 
).


--
Adrien


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

Re: Welcome Michael Gibney as Lucene committer

[Koji Sekiguchi]

Congratulations and welcome, Michael!

Koji

On 2021/10/06 22:33, Dawid Weiss wrote:

Hello everyone!

Please welcome Michael Gibney as the latest Lucene committer. Michael
- it's a tradition for you to introduce yourself, even if we've been
seeing you for quite a while! :)

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: Welcome Mayya Sharipova to the Lucene PMC

[Koji Sekiguchi]

Congrats and welcome Mayya!

Koji

On 2021/06/28 22:16, Robert Muir wrote:

I am pleased to announce that Mayya has accepted an invitation to join
the Lucene PMC!

Congratulations, and welcome aboard!

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



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

Re: Welcome Greg Miller as Lucene committer

[Koji Sekiguchi]

Congrats Greg!

Koji

On 2021/05/30 4:47, Adrien Grand wrote:

I'm pleased to announce that Greg Miller has accepted the PMC's invitation to 
become a committer.

Greg, the tradition is that new committers introduce themselves with a brief 
bio.

Congratulations and welcome!

--
Adrien


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

Re: Congratulations to the new Apache Solr PMC Chair, Jan Høydahl!

[Koji Sekiguchi]

Congratulations Jan!

Koji

On 2021/02/19 3:55, Anshum Gupta wrote:

Hi everyone,

I’d like to inform everyone that the newly formed Apache Solr PMC nominated and elected Jan Høydahl 
for the position of the Solr PMC Chair and Vice President. This decision was approved by the board 
in its February 2021 meeting.


Congratulations Jan!

--
Anshum Gupta


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

Re: Congratulations to the new Lucene PMC Chair, Michael Sokolov!

[Koji Sekiguchi]

Congratulations Mike!

Koji

On 2021/02/18 6:31, Anshum Gupta wrote:

Every year, the Lucene PMC rotates the Lucene PMC chair and Apache Vice 
President position.

This year we nominated and elected Michael Sokolov as the Chair, a decision that the board approved 
in its February 2021 meeting.


Congratulations, Mike!

--
Anshum Gupta


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

Re: Welcome Namgyu Kim to the PMC

[Koji Sekiguchi]

Welcome, Namgyu!

Koji

On 2020/08/03 8:18, Ishan Chattopadhyaya wrote:

I am pleased to announce that Namgyu Kim has accepted the PMC's invitation to 
join.

Congratulations and welcome, Namgyu!


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

Re: Welcome Munendra SN to the PMC

[Koji Sekiguchi]

Welcome, Munendra!

Koji

On 2020/08/03 8:19, Ishan Chattopadhyaya wrote:

I am pleased to announce that Munendra SN has accepted the PMC's invitation to 
join.

Congratulations and welcome, Munendra!


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

Re: Welcome Gus Heck to the PMC

[Koji Sekiguchi]

Welcome, Gus!

Koji

On 2020/08/03 8:20, Ishan Chattopadhyaya wrote:

I am pleased to announce that Gus Heck has accepted the PMC's invitation to 
join.

Congratulations and welcome, Gus!


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

Re: Welcome Tomoko Uchida to the PMC

[Koji Sekiguchi]

Welcome and Congrats, Uchida-san!

Koji


On 2020/07/04 15:26, Adrien Grand wrote:

I am pleased to announce that Tomoko Uchida has accepted the PMC's invitation 
to join.

Welcome Tomoko!

--
Adrien


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

Re: Welcome Ilan Ginzburg as Lucene/Solr committer

[Koji Sekiguchi]

Congrats and welcome, Ilan!

Koji

On 2020/06/21 18:46, Noble Paul wrote:

Hi all,

Please join me in welcoming Ilan Ginzburg as the latest Lucene/Solr committer.
Ilan, it's tradition for you to introduce yourself with a brief bio.

Congratulations and Welcome!
Noble


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

Re: Welcome Mayya Sharipova as Lucene/Solr committer

[Koji Sekiguchi]

Congratulations and welcome, Mayya!

Koji

On 2020/06/09 1:58, jim ferenczi wrote:

Hi all,

Please join me in welcoming Mayya Sharipova as the latest Lucene/Solr committer.
Mayya, it's tradition for you to introduce yourself with a brief bio.

Congratulations and Welcome!

Jim


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

Re: [VOTE] Solr to become a top-level Apache project (TLP)

[Koji Sekiguchi]

+1

Koji

On 2020/05/12 16:36, Dawid Weiss wrote:

Dear Lucene and Solr developers!

According to an earlier [DISCUSS] thread on the dev list [2], I am
calling for a vote on the proposal to make Solr a top-level Apache
project (TLP) and separate Lucene and Solr development into two
independent entities.

To quickly recap the reasons and consequences of such a move: it seems
like the reasons for the initial merge of Lucene and Solr, around 10
years ago, have been achieved. Both projects are in good shape and
exhibit signs of independence already (mailing lists, committers,
patch flow). There are many technical considerations that would make
development much easier if we move Solr out into its own TLP.

We discussed this issue [2] and both PMC members and committers had a
chance to review all the pros and cons and express their views. The
discussion showed that there are clearly different opinions on the
matter - some people are in favor, some are neutral, others are
against or not seeing the point of additional labor. Realistically, I
don't think reaching 100% level consensus is going to be possible --
we are a diverse bunch with different opinions and personalities. I
firmly believe this is the right direction hence the decision to put
it under the voting process. Should something take a wrong turn in the
future (as some folks worry it may), all blame is on me.

Therefore, the proposal is to separate Solr from under Lucene TLP, and
make it a TLP on its own. The initial structure of the new PMC,
committer base, git repositories and other managerial aspects can be
worked out during the process if the decision passes.

Please indicate one of the following (see [1] for guidelines):

[ ] +1 - yes, I vote for the proposal
[ ] -1 - no, I vote against the proposal

Please note that anyone in the Lucene+Solr community is invited to
express their opinion, though only Lucene+Solr committers cast binding
votes (indicate non-binding votes in your reply, please).

The vote will be active for a week to give everyone a chance to read
and cast a vote.

Dawid

[1] https://www.apache.org/foundation/voting.html
[2] 
https://lists.apache.org/thread.html/rfae2440264f6f874e91545b2030c98e7b7e3854ddf090f7747d338df%40%3Cdev.lucene.apache.org%3E

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



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

Re: Welcome Nhat Nguyen to the PMC

[Koji Sekiguchi]

Congratulations and welcome, Nhat!

Koji


On 2020/03/04 1:34, Adrien Grand wrote:

I am pleased to announce that Nhat Nguyen has accepted the PMC's invitation to 
join.

Welcome Nhat!

--
Adrien


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

Re: Welcome Kevin Risden to the PMC

[Koji Sekiguchi]

Welcome Kevin!

Koji

On 2019/06/27 21:04, Jan Høydahl wrote:

I am pleased to announce that Kevin Risden has accepted the PMC's invitation to 
join.

Welcome Kevin!

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


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


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

Re: Welcome Munendra S N as Lucene/Solr committer

[Koji Sekiguchi]

Welcome Munendra!

Koji


On 2019/06/21 18:41, Ishan Chattopadhyaya wrote:

Hi all,

Please join me in welcoming Munendra as a Lucene/Solr committer!

Munendra has been working on bug fixes and improvements in various
parts of Solr.

Congratulations and welcome! It is a tradition to introduce yourself
with a brief bio, Munendra.

Ishan

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


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

Re: Welcome Michael Sokolov as Lucene/ Solr committer

[Koji Sekiguchi]

Congratulations and welcome, Michael!

Koji

On 2019/05/14 4:11, 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: [jira] [Commented] (SOLR-11795) Add Solr metrics exporter for Prometheus

[Koji Sekiguchi]

Hi Ishan,

I'm sorry for the late reply.

I think it makes sense. But can you open a new ticket because SOLR-11795 has 
been closed already.

Thank you for letting me know this!

Koji


On 2019/04/11 19:31, Ishan Chattopadhyaya (JIRA) wrote:


 [ 
https://issues.apache.org/jira/browse/SOLR-11795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16815301#comment-16815301
 ]

Ishan Chattopadhyaya commented on SOLR-11795:
-

Does it make sense to add a link about this exporter in the metrics reporting 
page? I've attached a patch for the same. [~ctargett] / [~koji], can you please 
review?


Add Solr metrics exporter for Prometheus


 Key: SOLR-11795
 URL: https://issues.apache.org/jira/browse/SOLR-11795
 Project: Solr
  Issue Type: Improvement
  Security Level: Public(Default Security Level. Issues are Public)
  Components: metrics
Affects Versions: 7.2
Reporter: Minoru Osuka
Assignee: Koji Sekiguchi
Priority: Minor
 Fix For: 7.3, 8.0

 Attachments: SOLR-11795-10.patch, SOLR-11795-11.patch, 
SOLR-11795-2.patch, SOLR-11795-3.patch, SOLR-11795-4.patch, SOLR-11795-5.patch, 
SOLR-11795-6.patch, SOLR-11795-7.patch, SOLR-11795-8.patch, SOLR-11795-9.patch, 
SOLR-11795-dev-tools.patch, SOLR-11795-doc.patch, SOLR-11795-ref-guide.patch, 
SOLR-11795.patch, solr-dashboard.png, solr-exporter-diagram.png

  Time Spent: 20m
  Remaining Estimate: 0h

I 'd like to monitor Solr using Prometheus and Grafana.
I've already created Solr metrics exporter for Prometheus. I'd like to 
contribute to contrib directory if you don't mind.
!solr-exporter-diagram.png|thumbnail!
!solr-dashboard.png|thumbnail!




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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




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

Re: Welcome Tomoko Uchida as Lucene/Solr committer

[Koji Sekiguchi]

Welcome and congrats Tomoko!

Koji

On 2019/04/09 0:20, Uwe Schindler wrote:

Hi all,

Please join me in welcoming Tomoko Uchida as the latest Lucene/Solr committer!

She has been working on https://issues.apache.org/jira/browse/LUCENE-2562 for 
several years with awesome progress and finally we got the fantastic Luke as a 
branch on ASF JIRA: 
https://gitbox.apache.org/repos/asf?p=lucene-solr.git;a=shortlog;h=refs/heads/jira/lucene-2562-luke-swing-3
Looking forward to the first release of Apache Lucene 8.1 with Luke bundled in 
the distribution. I will take care of merging it to master and 8.x branches 
together with her once she got the ASF account.

Tomoko also helped with the Japanese and Korean Analyzers.

Congratulations and Welcome, Tomoko! Tomoko, it's traditional for you to 
introduce yourself with a brief bio.

Uwe & Robert (who nominated Tomoko)

-
Uwe Schindler
Achterdiek 19, D-28357 Bremen
https://www.thetaphi.de
eMail: u...@thetaphi.de



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





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

Re: Welcome Jason Gerlowski to the PMC

[Koji Sekiguchi]

Welcome, Jason!

Koji

On 2019/02/23 0:21, Jan Høydahl wrote:

I am pleased to announce that Jason Gerlowski has accepted the PMC's invitation 
to join.

Welcome Jason!

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


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





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

Re: Welcome Tim Allison as a Lucene/Solr committer

[Koji Sekiguchi]

Welcome Tim!

Koji


On 2018/11/03 1:20, Erick Erickson wrote:

Hi all,

Please join me in welcoming Tim Allison as the latest Lucene/Solr committer!

Congratulations and Welcome, Tim!

It's traditional for you to introduce yourself with a brief bio.

Erick

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




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

Re: Welcome Gus Heck as Lucene/Solr committer

[Koji Sekiguchi]

Welcome Gus!

Koji

On 2018/11/01 21:22, David Smiley wrote:

Hi all,

Please join me in welcoming Gus Heck as the latest Lucene/Solr committer!

Congratulations and Welcome, Gus!

Gus, it's traditional for you to introduce yourself with a brief bio.

~ David
--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
http://www.solrenterprisesearchserver.com


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

Re: [VOTE] Release Lucene/Solr 7.5.0 RC1

[Koji Sekiguchi]

+1
SUCCESS! [1:32:09.928470]

Koji

On 2018/09/19 1:09, jim ferenczi wrote:

Please vote for release candidate 1 for Lucene/Solr 7.5.0

The artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-7.5.0-RC1-revb5bf70b7e32d7ddd9742cc821d471c5fabd4e3df

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-7.5.0-RC1-revb5bf70b7e32d7ddd9742cc821d471c5fabd4e3df

Here's my +1
SUCCESS! [1:33:42.884535]


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

[jira] [Resolved] (SOLR-12570) OpenNLPExtractNamedEntitiesUpdateProcessor cannot support multi fields because pattern replacement doesn't work correctly

[Koji Sekiguchi (JIRA)]

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

Koji Sekiguchi resolved SOLR-12570.
---
   Resolution: Fixed
 Assignee: Koji Sekiguchi
Fix Version/s: 7.4.1

> OpenNLPExtractNamedEntitiesUpdateProcessor cannot support multi fields 
> because pattern replacement doesn't work correctly
> -
>
> Key: SOLR-12570
> URL: https://issues.apache.org/jira/browse/SOLR-12570
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UpdateRequestProcessors
>Affects Versions: 7.3, 7.3.1, 7.4
>Reporter: Koji Sekiguchi
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: master (8.0), 7.5, 7.4.1
>
> Attachments: SOLR-12570.patch
>
>
> Because of the following code, if resolvedDest is "body_{EntityType}_s" and 
> becomes "body_PERSON_s" by replacement, but once it is replaced, as 
> placeholder ({EntityType}) is overwritten, the destination is always 
> "body_PERSON_s".
> {code}
> resolvedDest = resolvedDest.replace(ENTITY_TYPE, entityType);
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (LUCENE-8420) Upgrade OpenNLP to 1.9.0

[Koji Sekiguchi (JIRA)]

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

Koji Sekiguchi resolved LUCENE-8420.

Resolution: Fixed
  Assignee: Koji Sekiguchi

> Upgrade OpenNLP to 1.9.0
> 
>
> Key: LUCENE-8420
> URL: https://issues.apache.org/jira/browse/LUCENE-8420
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/analysis
>Affects Versions: 7.4
>    Reporter: Koji Sekiguchi
>    Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: master (8.0), 7.5
>
> Attachments: LUCENE-8420.patch
>
>
> OpenNLP 1.9.0 generates new format model file which 1.8.x cannot read. 1.9.0 
> can read the previous format for back-compat.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-12570) OpenNLPExtractNamedEntitiesUpdateProcessor cannot support multi fields because pattern replacement doesn't work correctly

[Koji Sekiguchi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551521#comment-16551521
 ] 

Koji Sekiguchi commented on SOLR-12570:
---

I posted a patch in LUCENE-8420. It includes the new ner model which can 
predict LOCATION in addition to PERSON. I think we can add the test for this 
after LUCENE-8420 committed, I haven't tried the new model file to predict 
LOCATION, though.

> OpenNLPExtractNamedEntitiesUpdateProcessor cannot support multi fields 
> because pattern replacement doesn't work correctly
> -
>
> Key: SOLR-12570
> URL: https://issues.apache.org/jira/browse/SOLR-12570
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UpdateRequestProcessors
>Affects Versions: 7.3, 7.3.1, 7.4
>Reporter: Koji Sekiguchi
>Priority: Minor
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-12570.patch
>
>
> Because of the following code, if resolvedDest is "body_{EntityType}_s" and 
> becomes "body_PERSON_s" by replacement, but once it is replaced, as 
> placeholder ({EntityType}) is overwritten, the destination is always 
> "body_PERSON_s".
> {code}
> resolvedDest = resolvedDest.replace(ENTITY_TYPE, entityType);
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (LUCENE-8420) Upgrade OpenNLP to 1.9.0

[Koji Sekiguchi (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-8420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16551519#comment-16551519
 ] 

Koji Sekiguchi commented on LUCENE-8420:


I created model files for 1.9.0 by executing ant train-test-models under 
lucene/analysis/opennlp/. As for the training data, I renamed ner_flashman.txt 
to ner.txt and let the file have location type for SOLR-12570.

I deleted opennlp-maxent which is never used (and I think it's old; 
opennlp-tools package includes maxent).

> Upgrade OpenNLP to 1.9.0
> 
>
> Key: LUCENE-8420
> URL: https://issues.apache.org/jira/browse/LUCENE-8420
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/analysis
>Affects Versions: 7.4
>    Reporter: Koji Sekiguchi
>Priority: Minor
> Fix For: master (8.0), 7.5
>
> Attachments: LUCENE-8420.patch
>
>
> OpenNLP 1.9.0 generates new format model file which 1.8.x cannot read. 1.9.0 
> can read the previous format for back-compat.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (LUCENE-8420) Upgrade OpenNLP to 1.9.0

[Koji Sekiguchi (JIRA)]

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

Koji Sekiguchi updated LUCENE-8420:
---
Attachment: LUCENE-8420.patch

> Upgrade OpenNLP to 1.9.0
> 
>
> Key: LUCENE-8420
> URL: https://issues.apache.org/jira/browse/LUCENE-8420
> Project: Lucene - Core
>  Issue Type: Task
>  Components: modules/analysis
>Affects Versions: 7.4
>    Reporter: Koji Sekiguchi
>Priority: Minor
> Fix For: master (8.0), 7.5
>
> Attachments: LUCENE-8420.patch
>
>
> OpenNLP 1.9.0 generates new format model file which 1.8.x cannot read. 1.9.0 
> can read the previous format for back-compat.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (SOLR-12571) Upgrade OpenNLP to 1.9.0

[Koji Sekiguchi (JIRA)]

Koji Sekiguchi created SOLR-12571:
-

 Summary: Upgrade OpenNLP to 1.9.0
 Key: SOLR-12571
 URL: https://issues.apache.org/jira/browse/SOLR-12571
 Project: Solr
  Issue Type: Task
  Security Level: Public (Default Security Level. Issues are Public)
  Components: contrib - LangId, update
Affects Versions: 7.4
Reporter: Koji Sekiguchi
 Fix For: master (8.0), 7.5


OpenNLP 1.9.0 generates new format model file which 1.8.x cannot read. 1.9.0 
can read the previous format for back-compat.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Updated] (SOLR-12570) OpenNLPExtractNamedEntitiesUpdateProcessor cannot support multi fields because pattern replacement doesn't work correctly

[Koji Sekiguchi (JIRA)]

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

Koji Sekiguchi updated SOLR-12570:
--
Attachment: SOLR-12570.patch

> OpenNLPExtractNamedEntitiesUpdateProcessor cannot support multi fields 
> because pattern replacement doesn't work correctly
> -
>
> Key: SOLR-12570
> URL: https://issues.apache.org/jira/browse/SOLR-12570
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UpdateRequestProcessors
>Affects Versions: 7.3, 7.3.1, 7.4
>Reporter: Koji Sekiguchi
>Priority: Minor
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-12570.patch
>
>
> Because of the following code, if resolvedDest is "body_{EntityType}_s" and 
> becomes "body_PERSON_s" by replacement, but once it is replaced, as 
> placeholder ({EntityType}) is overwritten, the destination is always 
> "body_PERSON_s".
> {code}
> resolvedDest = resolvedDest.replace(ENTITY_TYPE, entityType);
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Created] (SOLR-12570) OpenNLPExtractNamedEntitiesUpdateProcessor cannot support multi fields because pattern replacement doesn't work correctly

[Koji Sekiguchi (JIRA)]

Koji Sekiguchi created SOLR-12570:
-

 Summary: OpenNLPExtractNamedEntitiesUpdateProcessor cannot support 
multi fields because pattern replacement doesn't work correctly
 Key: SOLR-12570
 URL: https://issues.apache.org/jira/browse/SOLR-12570
 Project: Solr
  Issue Type: Bug
  Security Level: Public (Default Security Level. Issues are Public)
  Components: UpdateRequestProcessors
Affects Versions: 7.4, 7.3.1, 7.3
Reporter: Koji Sekiguchi
 Fix For: master (8.0), 7.5


Because of the following code, if resolvedDest is "body_{EntityType}_s" and 
becomes "body_PERSON_s" by replacement, but once it is replaced, as placeholder 
({EntityType}) is overwritten, the destination is always "body_PERSON_s".

{code}
resolvedDest = resolvedDest.replace(ENTITY_TYPE, entityType);
{code}




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: Welcome Nhat Nguyen as Lucene/Solr committer

[Koji Sekiguchi]

Congratulations and Welcome!

Koji

On 2018/06/19 5:41, Adrien Grand wrote:

Hi all,

Please join me in welcoming Nhat Nguyen as the latest Lucene/Solr committer.
Nhat, it's tradition for you to introduce yourself with a brief bio.

Congratulations and Welcome!

Adrien


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

[jira] [Resolved] (SOLR-12202) failed to run solr-exporter.cmd on Windows platform

[Koji Sekiguchi (JIRA)]

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

Koji Sekiguchi resolved SOLR-12202.
---
   Resolution: Fixed
Fix Version/s: master (8.0)
   7.4
   7.3

Thanks!

> failed to run solr-exporter.cmd on Windows platform
> ---
>
> Key: SOLR-12202
> URL: https://issues.apache.org/jira/browse/SOLR-12202
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Major
> Fix For: 7.3, 7.4, master (8.0)
>
> Attachments: SOLR-12202.patch, SOLR-12202_branch_7_3.patch
>
>
> failed to run solr-exporter.cmd on Windows platform due to following:
> - incorrect main class name.
> - incorrect classpath specification.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (SOLR-12202) failed to run solr-exporter.cmd on Windows platform

[Koji Sekiguchi (JIRA)]

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

Koji Sekiguchi reassigned SOLR-12202:
-

Assignee: Koji Sekiguchi

> failed to run solr-exporter.cmd on Windows platform
> ---
>
> Key: SOLR-12202
> URL: https://issues.apache.org/jira/browse/SOLR-12202
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.3
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Major
> Attachments: SOLR-12202.patch
>
>
> failed to run solr-exporter.cmd on Windows platform due to following:
> - incorrect main class name.
> - incorrect classpath specification.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: Welcome Cao Mạnh Đạt to the PMC

[Koji Sekiguchi]

Welcome Đạt!

Koji

On 2018/04/03 4:50, Adrien Grand wrote:

Fixing the subject of the email.

Le lun. 2 avr. 2018 à 21:48, Adrien Grand > a écrit :

I am pleased to announce that Cao Mạnh Đạt has accepted the PMC's 
invitation to join.

Welcome Đạt!



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

[jira] [Resolved] (SOLR-11795) Add Solr metrics exporter for Prometheus

[Koji Sekiguchi (JIRA)]

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

Koji Sekiguchi resolved SOLR-11795.
---
Resolution: Fixed

Mark as resolved. Thanks everyone!

> Add Solr metrics exporter for Prometheus
> 
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: 7.3, master (8.0)
>
> Attachments: SOLR-11795-10.patch, SOLR-11795-11.patch, 
> SOLR-11795-2.patch, SOLR-11795-3.patch, SOLR-11795-4.patch, 
> SOLR-11795-5.patch, SOLR-11795-6.patch, SOLR-11795-7.patch, 
> SOLR-11795-8.patch, SOLR-11795-9.patch, SOLR-11795-dev-tools.patch, 
> SOLR-11795-ref-guide.patch, SOLR-11795.patch, solr-dashboard.png, 
> solr-exporter-diagram.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Reopened] (SOLR-11795) Add Solr metrics exporter for Prometheus

[Koji Sekiguchi (JIRA)]

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

Koji Sekiguchi reopened SOLR-11795:
---

Thanks. I'll apply the additional patch soon.

> Add Solr metrics exporter for Prometheus
> 
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11795-10.patch, SOLR-11795-11.patch, 
> SOLR-11795-2.patch, SOLR-11795-3.patch, SOLR-11795-4.patch, 
> SOLR-11795-5.patch, SOLR-11795-6.patch, SOLR-11795-7.patch, 
> SOLR-11795-8.patch, SOLR-11795-9.patch, SOLR-11795-dev-tools.patch, 
> SOLR-11795-ref-guide.patch, SOLR-11795.patch, solr-dashboard.png, 
> solr-exporter-diagram.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: [VOTE] Release Lucene/Solr 6.6.3 RC1

[Koji Sekiguchi]

+1

SUCCESS! [1:20:25.158491]

Koji

On 2018/03/05 16:36, Shalin Shekhar Mangar wrote:

+1

SUCCESS! [1:08:00.711198]

On Sat, Mar 3, 2018 at 3:39 AM, Steve Rowe > wrote:

Please vote for release candidate 1 for Lucene/Solr 6.6.3.

The artifacts can be downloaded from:


https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-6.6.3-RC1-revd1e9bbd333ea55cfa0c75d324424606e857a775b



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-6.6.3-RC1-revd1e9bbd333ea55cfa0c75d324424606e857a775b



Here's my +1, smoke tester says SUCCESS! [0:34:...] (from memory - terminal 
scrollback is
uncooperative...)

--
Steve
www.lucidworks.com 



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 

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





--
Regards,
Shalin Shekhar Mangar.


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

[jira] [Resolved] (SOLR-11795) Add Solr metrics exporter for Prometheus

[Koji Sekiguchi (JIRA)]

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

Koji Sekiguchi resolved SOLR-11795.
---
Resolution: Fixed

Yes, thanks Uwe and all!

> Add Solr metrics exporter for Prometheus
> 
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11795-10.patch, SOLR-11795-11.patch, 
> SOLR-11795-2.patch, SOLR-11795-3.patch, SOLR-11795-4.patch, 
> SOLR-11795-5.patch, SOLR-11795-6.patch, SOLR-11795-7.patch, 
> SOLR-11795-8.patch, SOLR-11795-9.patch, SOLR-11795-dev-tools.patch, 
> SOLR-11795.patch, solr-dashboard.png, solr-exporter-diagram.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-11795) Add Solr metrics exporter for Prometheus

[Koji Sekiguchi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16385552#comment-16385552
 ] 

Koji Sekiguchi commented on SOLR-11795:
---

Uwe's suggestion helped us to check this patch working on various platforms 
without causing someone trouble. Actually, Java 9 Jenkins found that SnakeYAML 
stuff uses reflection in illegal ways, which we couldn't notice before 
committing.

... and the results look good so far. I'd like to commit this to master and 
branch_7x soon.

> Add Solr metrics exporter for Prometheus
> 
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11795-10.patch, SOLR-11795-11.patch, 
> SOLR-11795-2.patch, SOLR-11795-3.patch, SOLR-11795-4.patch, 
> SOLR-11795-5.patch, SOLR-11795-6.patch, SOLR-11795-7.patch, 
> SOLR-11795-8.patch, SOLR-11795-9.patch, SOLR-11795-dev-tools.patch, 
> SOLR-11795.patch, solr-dashboard.png, solr-exporter-diagram.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Comment Edited] (SOLR-11795) Add Solr metrics exporter for Prometheus

[Koji Sekiguchi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16383080#comment-16383080
 ] 

Koji Sekiguchi edited comment on SOLR-11795 at 3/2/18 3:02 AM:
---

Hi Uwe,

I created the following branches:

* SOLR-11795 (for master)
* branch_7x-SOLR-11795 (for branch_7x)

Sorry to put you to the trouble but can you setup the Linux and Windows 
Policeman Jenkins jobs that you kindly suggested a week ago? Thank you very 
much in advance!


was (Author: koji):
Hi Uwe,

I created the following branches:

* SOLR-1175 (for master)
* branch_7x-SOLR-1175 (for branch_7x)

Sorry to put you to the trouble but can you setup the Linux and Windows 
Policeman Jenkins jobs that you kindly suggested a week ago? Thank you very 
much in advance!

> Add Solr metrics exporter for Prometheus
> 
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11795-10.patch, SOLR-11795-11.patch, 
> SOLR-11795-2.patch, SOLR-11795-3.patch, SOLR-11795-4.patch, 
> SOLR-11795-5.patch, SOLR-11795-6.patch, SOLR-11795-7.patch, 
> SOLR-11795-8.patch, SOLR-11795-9.patch, SOLR-11795-dev-tools.patch, 
> SOLR-11795.patch, solr-dashboard.png, solr-exporter-diagram.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-11795) Add Solr metrics exporter for Prometheus

[Koji Sekiguchi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16383080#comment-16383080
 ] 

Koji Sekiguchi commented on SOLR-11795:
---

Hi Uwe,

I created the following branches:

* SOLR-1175 (for master)
* branch_7x-SOLR-1175 (for branch_7x)

Sorry to put you to the trouble but can you setup the Linux and Windows 
Policeman Jenkins jobs that you kindly suggested a week ago? Thank you very 
much in advance!

> Add Solr metrics exporter for Prometheus
> 
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11795-10.patch, SOLR-11795-11.patch, 
> SOLR-11795-2.patch, SOLR-11795-3.patch, SOLR-11795-4.patch, 
> SOLR-11795-5.patch, SOLR-11795-6.patch, SOLR-11795-7.patch, 
> SOLR-11795-8.patch, SOLR-11795-9.patch, SOLR-11795-dev-tools.patch, 
> SOLR-11795.patch, solr-dashboard.png, solr-exporter-diagram.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-11795) Add Solr metrics exporter for Prometheus

[Koji Sekiguchi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16375582#comment-16375582
 ] 

Koji Sekiguchi commented on SOLR-11795:
---

Thanks for the kind suggestion. I'd like to create a branch for this and let 
you know the name.

> Add Solr metrics exporter for Prometheus
> 
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11795-2.patch, SOLR-11795-3.patch, 
> SOLR-11795-4.patch, SOLR-11795-5.patch, SOLR-11795-6.patch, 
> SOLR-11795-7.patch, SOLR-11795-8.patch, SOLR-11795-9.patch, 
> SOLR-11795-dev-tools.patch, SOLR-11795.patch, solr-dashboard.png, 
> solr-exporter-diagram.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-11795) Add Solr metrics exporter for Prometheus

[Koji Sekiguchi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16375195#comment-16375195
 ] 

Koji Sekiguchi commented on SOLR-11795:
---

I can't apologize enough for this. :(

> Now we have XML, JSON, properties files and now YAML. Why not use one that's 
> already used by other places in Solr?

As for using yaml, I asked the contributor why using it rather than json and I 
just accepted the reason (more readable and understandable, able to include 
comment etc.) but I should gain favor with committers about importing new 
config format.

> Or much simpler: Get rid of YAML!

I'd like to talk to him that we could use json for config but it'll take time 
to apply.

I'm going to revert this soon.


> Add Solr metrics exporter for Prometheus
> 
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11795-2.patch, SOLR-11795-3.patch, 
> SOLR-11795-4.patch, SOLR-11795-5.patch, SOLR-11795-6.patch, 
> SOLR-11795-7.patch, SOLR-11795-8.patch, SOLR-11795-9.patch, 
> SOLR-11795-dev-tools.patch, SOLR-11795.patch, solr-dashboard.png, 
> solr-exporter-diagram.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Resolved] (SOLR-11795) Add Solr metrics exporter for Prometheus

[Koji Sekiguchi (JIRA)]

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

Koji Sekiguchi resolved SOLR-11795.
---
Resolution: Fixed

Thanks Minoru and everyone! 

> Add Solr metrics exporter for Prometheus
> 
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11795-2.patch, SOLR-11795-3.patch, 
> SOLR-11795-4.patch, SOLR-11795-5.patch, SOLR-11795-6.patch, 
> SOLR-11795-7.patch, SOLR-11795-8.patch, SOLR-11795-9.patch, 
> SOLR-11795-dev-tools.patch, SOLR-11795.patch, solr-dashboard.png, 
> solr-exporter-diagram.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-11795) Add Solr metrics exporter for Prometheus

[Koji Sekiguchi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16373596#comment-16373596
 ] 

Koji Sekiguchi commented on SOLR-11795:
---

Thanks for letting us know it. Yes, we discussed about the problem last night 
as we were paying careful attention to Jenkins. I think we can fix it soon.

> Add Solr metrics exporter for Prometheus
> 
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: master (8.0), 7.3
>
> Attachments: SOLR-11795-2.patch, SOLR-11795-3.patch, 
> SOLR-11795-4.patch, SOLR-11795-5.patch, SOLR-11795-6.patch, 
> SOLR-11795-7.patch, SOLR-11795-8.patch, SOLR-11795-9.patch, SOLR-11795.patch, 
> solr-dashboard.png, solr-exporter-diagram.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Reopened] (SOLR-11795) Add Solr metrics exporter for Prometheus

[Koji Sekiguchi (JIRA)]

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

Koji Sekiguchi reopened SOLR-11795:
---

Reopening this. We're still working on this.

> Add Solr metrics exporter for Prometheus
> 
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: 7.3
>
> Attachments: SOLR-11795-2.patch, SOLR-11795-3.patch, 
> SOLR-11795-4.patch, SOLR-11795-5.patch, SOLR-11795-6.patch, 
> SOLR-11795-7.patch, SOLR-11795-8.patch, SOLR-11795.patch, solr-dashboard.png, 
> solr-exporter-diagram.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: [1/7] lucene-solr:master: SOLR-11795: Add Solr metrics exporter for Prometheus

[Koji Sekiguchi]

Thanks for letting me know this. I'll fix it in the next patch...


On 2018/02/20 23:55, Cassandra Targett wrote:

Ref Guide builds are also failing due to duplicate section headings on two 
pages.

https://builds.apache.org/job/Solr-reference-guide-master/5499/console:

build-site:
  [java] ID occurs multiple times: configuration
  [java]  ... 
file:/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/html-site/monitoring-solr-with-prometheus-and-grafana.html
  [java]  ... 
file:/home/jenkins/jenkins-slave/workspace/Solr-reference-guide-master/solr/build/solr-ref-guide/html-site/parallel-sql-interface.html


This will cause links between sections of the PDF to go to the wrong place, so each section must be 
unique. I'd suggest in this case possibly changing the new page section heading "Configuration" to 
"solr-exporter Configuration" or something similar.



On Tue, Feb 20, 2018 at 7:34 AM, Koji Sekiguchi <koji.sekigu...@rondhuit.com 
<mailto:koji.sekigu...@rondhuit.com>> wrote:


I'm sorry. Let me check...


On 2018/02/20 20:50, Andrzej Białecki wrote:

Builds on jenkins are failing due to precommit failures in this code...

On 20 Feb 2018, at 09:47, k...@apache.org <mailto:k...@apache.org>
<mailto:k...@apache.org <mailto:k...@apache.org>> wrote:

Repository: lucene-solr
Updated Branches:
  refs/heads/master dfc0fe86e -> 4bfcbc5c6



http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/4bfcbc5c/solr/contrib/prometheus-exporter/src/test/org/apache/solr/prometheus/scraper/config/SolrQueryConfigTest.java

<http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/4bfcbc5c/solr/contrib/prometheus-exporter/src/test/org/apache/solr/prometheus/scraper/config/SolrQueryConfigTest.java>

--
diff --git

a/solr/contrib/prometheus-exporter/src/test/org/apache/solr/prometheus/scraper/config/SolrQueryConfigTest.java

b/solr/contrib/prometheus-exporter/src/test/org/apache/solr/prometheus/scraper/config/SolrQueryConfigTest.java
new file mode 100644
index 000..c62d354
--- /dev/null
+++

b/solr/contrib/prometheus-exporter/src/test/org/apache/solr/prometheus/scraper/config/SolrQueryConfigTest.java
@@ -0,0 +1,121 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or 
more
+ * contributor license agreements.  See the NOTICE file 
distributed with
+ * this work for additional information regarding copyright 
ownership.
+ * The ASF licenses this file to You under the Apache License, 
Version 2.0
+ * (the "License"); you may not use this file except in compliance 
with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0 
<http://www.apache.org/licenses/LICENSE-2.0>
+ *
+ * Unless required by applicable law or agreed to in writing, 
software
+ * distributed under the License is distributed on an "AS IS" 
BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 
implied.
+ * See the License for the specific language governing permissions 
and
+ * limitations under the License.
+ */
+package org.apache.solr.prometheus.scraper.config;
+
+import org.apache.solr.SolrTestCaseJ4;
+import org.junit.Test;
+
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.LinkedHashMap;
+import java.util.List;
+
+/**
+ * Unit test for SolrQueryConfig.
+ */
+public class SolrQueryConfigTest extends SolrTestCaseJ4 {
+  @Test
+  public void testQueryConfig() throws Exception {
+    SolrQueryConfig queryConfig = new SolrQueryConfig();
+
+    assertNotNull(queryConfig);
+  }
+
+  @Test
+  public void testGetCollection() throws Exception {
+    SolrQueryConfig queryConfig = new SolrQueryConfig();
+
+    String expected = "";
+    String actual = queryConfig.getCollection();
+    assertEquals(expected, actual);
+  }
+
+  @Test
+  public void testSetCollection() throws Exception {
+    SolrQueryConfig queryConfig = new SolrQueryConfig();
+
+    queryConfig.setCollection("collection1");
+
   

Re: [1/7] lucene-solr:master: SOLR-11795: Add Solr metrics exporter for Prometheus

[Koji Sekiguchi]

Before committing this, I did ant precommit and I saw a message "Source checkout is dirty..." but I 
passed over it because I thought I should accept it as solr/contrib/prometheus-exporter is a new 
directory.


I fixed some failures but it still has errors that inform "MISSING sha1 checksum file for 
solr/contrib/prometheus-exporter/lib/*.jar"


I think I don't have time to fix them now. I'll revert SOLR-11795 and try it in 
the later of this week.

I deeply apologize for the inconvenience.


On 2018/02/20 22:34, Koji Sekiguchi wrote:

I'm sorry. Let me check...


On 2018/02/20 20:50, Andrzej Białecki wrote:

Builds on jenkins are failing due to precommit failures in this code...


On 20 Feb 2018, at 09:47, k...@apache.org <mailto:k...@apache.org> wrote:

Repository: lucene-solr
Updated Branches:
 refs/heads/master dfc0fe86e -> 4bfcbc5c6


http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/4bfcbc5c/solr/contrib/prometheus-exporter/src/test/org/apache/solr/prometheus/scraper/config/SolrQueryConfigTest.java 


--
diff --git 
a/solr/contrib/prometheus-exporter/src/test/org/apache/solr/prometheus/scraper/config/SolrQueryConfigTest.java 
b/solr/contrib/prometheus-exporter/src/test/org/apache/solr/prometheus/scraper/config/SolrQueryConfigTest.java 


new file mode 100644
index 000..c62d354
--- /dev/null
+++ 
b/solr/contrib/prometheus-exporter/src/test/org/apache/solr/prometheus/scraper/config/SolrQueryConfigTest.java 


@@ -0,0 +1,121 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.prometheus.scraper.config;
+
+import org.apache.solr.SolrTestCaseJ4;
+import org.junit.Test;
+
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.LinkedHashMap;
+import java.util.List;
+
+/**
+ * Unit test for SolrQueryConfig.
+ */
+public class SolrQueryConfigTest extends SolrTestCaseJ4 {
+  @Test
+  public void testQueryConfig() throws Exception {
+    SolrQueryConfig queryConfig = new SolrQueryConfig();
+
+    assertNotNull(queryConfig);
+  }
+
+  @Test
+  public void testGetCollection() throws Exception {
+    SolrQueryConfig queryConfig = new SolrQueryConfig();
+
+    String expected = "";
+    String actual = queryConfig.getCollection();
+    assertEquals(expected, actual);
+  }
+
+  @Test
+  public void testSetCollection() throws Exception {
+    SolrQueryConfig queryConfig = new SolrQueryConfig();
+
+    queryConfig.setCollection("collection1");
+
+    String expected = "collection1";
+    String actual = queryConfig.getCollection();
+    assertEquals(expected, actual);
+  }
+
+  @Test
+  public void testGetPath() throws Exception {
+    SolrQueryConfig queryConfig = new SolrQueryConfig();
+
+    String expected = "";
+    String actual = queryConfig.getPath();
+    assertEquals(expected, actual);
+  }
+
+  @Test
+  public void testSetPath() throws Exception {
+    SolrQueryConfig queryConfig = new SolrQueryConfig();
+
+    queryConfig.setPath("/select");
+
+    String expected = "/select";
+    String actual = queryConfig.getPath();
+    assertEquals(expected, actual);
+  }
+
+  @Test
+  public void testGetParams() throws Exception {
+    SolrQueryConfig queryConfig = new SolrQueryConfig();
+
+    List<LinkedHashMap<String, String>> expected = new ArrayList<>();
+    List<LinkedHashMap<String, String>> actual = queryConfig.getParams();
+    assertEquals(expected, actual);
+  }
+
+  @Test
+  public void testSetParams() throws Exception {
+    SolrQueryConfig queryConfig = new SolrQueryConfig();
+
+    LinkedHashMap<String,String> param1 = new LinkedHashMap<>();
+    param1.put("q", "*:*");
+
+    LinkedHashMap<String,String> param2 = new LinkedHashMap<>();
+    param2.put("facet", "on");
+
+    queryConfig.setParams(Arrays.asList(param1, param2));
+
+    List<LinkedHashMap<String, String>> expected = Arrays.asList(param1, 
param2);
+    List<LinkedHashMap<String, String>> actual = queryConfig.getParams();
+ 

Re: [1/7] lucene-solr:master: SOLR-11795: Add Solr metrics exporter for Prometheus

[Koji Sekiguchi]

I'm sorry. Let me check...


On 2018/02/20 20:50, Andrzej Białecki wrote:

Builds on jenkins are failing due to precommit failures in this code...


On 20 Feb 2018, at 09:47, k...@apache.org  wrote:

Repository: lucene-solr
Updated Branches:
 refs/heads/master dfc0fe86e -> 4bfcbc5c6


http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/4bfcbc5c/solr/contrib/prometheus-exporter/src/test/org/apache/solr/prometheus/scraper/config/SolrQueryConfigTest.java
--
diff --git 
a/solr/contrib/prometheus-exporter/src/test/org/apache/solr/prometheus/scraper/config/SolrQueryConfigTest.java 
b/solr/contrib/prometheus-exporter/src/test/org/apache/solr/prometheus/scraper/config/SolrQueryConfigTest.java

new file mode 100644
index 000..c62d354
--- /dev/null
+++ 
b/solr/contrib/prometheus-exporter/src/test/org/apache/solr/prometheus/scraper/config/SolrQueryConfigTest.java

@@ -0,0 +1,121 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.solr.prometheus.scraper.config;
+
+import org.apache.solr.SolrTestCaseJ4;
+import org.junit.Test;
+
+import java.util.ArrayList;
+import java.util.Arrays;
+import java.util.LinkedHashMap;
+import java.util.List;
+
+/**
+ * Unit test for SolrQueryConfig.
+ */
+public class SolrQueryConfigTest extends SolrTestCaseJ4 {
+  @Test
+  public void testQueryConfig() throws Exception {
+    SolrQueryConfig queryConfig = new SolrQueryConfig();
+
+    assertNotNull(queryConfig);
+  }
+
+  @Test
+  public void testGetCollection() throws Exception {
+    SolrQueryConfig queryConfig = new SolrQueryConfig();
+
+    String expected = "";
+    String actual = queryConfig.getCollection();
+    assertEquals(expected, actual);
+  }
+
+  @Test
+  public void testSetCollection() throws Exception {
+    SolrQueryConfig queryConfig = new SolrQueryConfig();
+
+    queryConfig.setCollection("collection1");
+
+    String expected = "collection1";
+    String actual = queryConfig.getCollection();
+    assertEquals(expected, actual);
+  }
+
+  @Test
+  public void testGetPath() throws Exception {
+    SolrQueryConfig queryConfig = new SolrQueryConfig();
+
+    String expected = "";
+    String actual = queryConfig.getPath();
+    assertEquals(expected, actual);
+  }
+
+  @Test
+  public void testSetPath() throws Exception {
+    SolrQueryConfig queryConfig = new SolrQueryConfig();
+
+    queryConfig.setPath("/select");
+
+    String expected = "/select";
+    String actual = queryConfig.getPath();
+    assertEquals(expected, actual);
+  }
+
+  @Test
+  public void testGetParams() throws Exception {
+    SolrQueryConfig queryConfig = new SolrQueryConfig();
+
+    List> expected = new ArrayList<>();
+    List> actual = queryConfig.getParams();
+    assertEquals(expected, actual);
+  }
+
+  @Test
+  public void testSetParams() throws Exception {
+    SolrQueryConfig queryConfig = new SolrQueryConfig();
+
+    LinkedHashMap param1 = new LinkedHashMap<>();
+    param1.put("q", "*:*");
+
+    LinkedHashMap param2 = new LinkedHashMap<>();
+    param2.put("facet", "on");
+
+    queryConfig.setParams(Arrays.asList(param1, param2));
+
+    List> expected = Arrays.asList(param1, 
param2);
+    List> actual = queryConfig.getParams();
+    assertEquals(expected, actual);
+  }
+
+  @Test
+  public void testGetParamsString() throws Exception {
+    SolrQueryConfig queryConfig = new SolrQueryConfig();
+
+    LinkedHashMap param1 = new LinkedHashMap<>();
+    param1.put("q", "*:*");
+    param1.put("fq", "manu:apple");
+
+    LinkedHashMap param2 = new LinkedHashMap<>();
+    param2.put("facet", "on");
+
+    queryConfig.setParams(Arrays.asList(param1, param2));
+
+    String expected = "q=*:*=manu:apple=on";
+    String actual = queryConfig.getParamsString();
+    assertEquals(expected, actual);
+  }
+}

http://git-wip-us.apache.org/repos/asf/lucene-solr/blob/4bfcbc5c/solr/contrib/prometheus-exporter/src/test/org/apache/solr/prometheus/scraper/config/SolrScraperConfigTest.java

[jira] [Resolved] (SOLR-11795) Add Solr metrics exporter for Prometheus

[Koji Sekiguchi (JIRA)]

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

Koji Sekiguchi resolved SOLR-11795.
---
   Resolution: Fixed
Fix Version/s: 7.3

> Add Solr metrics exporter for Prometheus
> 
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: 7.3
>
> Attachments: SOLR-11795-2.patch, SOLR-11795-3.patch, 
> SOLR-11795-4.patch, SOLR-11795-5.patch, SOLR-11795-6.patch, 
> SOLR-11795-7.patch, SOLR-11795.patch, solr-dashboard.png, 
> solr-exporter-diagram.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-11795) Add Solr metrics exporter for Prometheus

[Koji Sekiguchi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369692#comment-16369692
 ] 

Koji Sekiguchi commented on SOLR-11795:
---

I can still see several UpdateRequestProcessors in solrconfig.xml for test. Are 
they necessary? And I'm sorry if I'm wrong but do you need 
test-files/exampledocs/*.xml files?

As for schema settings, existing all Solr contribs use schema.xml, not 
managed-schema. Why don't you follow them?

> Add Solr metrics exporter for Prometheus
> 
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Minor
> Attachments: SOLR-11795-2.patch, SOLR-11795-3.patch, 
> SOLR-11795-4.patch, SOLR-11795-5.patch, SOLR-11795-6.patch, 
> SOLR-11795-7.patch, SOLR-11795.patch, solr-dashboard.png, 
> solr-exporter-diagram.png
>
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-11795) Add Solr metrics exporter for Prometheus

[Koji Sekiguchi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369645#comment-16369645
 ] 

Koji Sekiguchi commented on SOLR-11795:
---

Thank you for updating the patch. I can see hard coded luceneMatchVersion in 
the patch:

{code}
7.1.0
{code}

You can rephrase it like this:

{code}
${tests.luceneMatchVersion:LATEST}
{code}

And I think your solrconfig.xml for test is still fat... Please consult 
solr/contrib/langid for making test config more compact.

> Add Solr metrics exporter for Prometheus
> 
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Minor
> Attachments: SOLR-11795-2.patch, SOLR-11795-3.patch, 
> SOLR-11795-4.patch, SOLR-11795-5.patch, SOLR-11795-6.patch, SOLR-11795.patch, 
> solr-dashboard.png, solr-exporter-diagram.png
>
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-11795) Add Solr metrics exporter for Prometheus

[Koji Sekiguchi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16366903#comment-16366903
 ] 

Koji Sekiguchi commented on SOLR-11795:
---

Today I had a meeting with Minoru, the contributor of this patch. We discussed 
in detail about this contribution and I found this is very nice!

There is a similar ticket SOLR-10654, which implements ResponseWriter for 
Prometheus and is called thru wt parameter, but I prefer Minoru's way.  Why I 
prefer this is because:

* This is highly independent from Solr main unit. He just makes 
contrib/prometheus-exporter directory and provides everything under it, 
including SolrExporter for Prometheus in this patch. This patch doesn't change 
Solr main source.
* Implementing an exporter looks mainstream in Prometheus field, such as MySQL, 
Memcached, Mesos, etc. See https://prometheus.io/docs/instrumenting/exporters/
* Solrj is used to implement SolrExporter in this patch. It can be used on 
SolrCloud environment.
* It allows users to monitor not only Solr metrics which come from 
/admin/metrics but also facet counts which come from /select (see config.yml in 
the patch).

I requested him to update the patch in terms of providing Ref Guide (he already 
wrote README.md so just move its contents to Ref Guide) and adding more tests 
so that we can know the change of the response format of /admin/metrics if it 
happens.

I'll wait for his next patch. Once I got it and nobody objects, I'd like to 
commit this in the next week.

> Add Solr metrics exporter for Prometheus
> 
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Minor
> Attachments: SOLR-11795-2.patch, SOLR-11795-3.patch, 
> SOLR-11795-4.patch, SOLR-11795-5.patch, SOLR-11795.patch, solr-dashboard.png, 
> solr-exporter-diagram.png
>
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: Welcome Jason Gerlowski as committer

[Koji Sekiguchi]

Welcome Jason!

Koji

On 2018/02/09 2:02, David Smiley wrote:

Hello everyone,

It's my pleasure to announce that Jason Gerlowski is our latest committer for Lucene/Solr in 
recognition for his contributions to the project!  Please join me in welcoming him. Jason, it's 
tradition for you to introduce yourself with a brief bio.


Congratulations and Welcome!
--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
http://www.solrenterprisesearchserver.com


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

[jira] [Updated] (SOLR-11592) add another language detector using OpenNLP

[Koji Sekiguchi (JIRA)]

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

Koji Sekiguchi updated SOLR-11592:
--
Affects Version/s: (was: 7.1)
   7.2

> add another language detector using OpenNLP
> ---
>
> Key: SOLR-11592
> URL: https://issues.apache.org/jira/browse/SOLR-11592
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LangId
>Affects Versions: 7.2
>    Reporter: Koji Sekiguchi
>Assignee: Steve Rowe
>Priority: Minor
> Attachments: SOLR-11592.patch, SOLR-11592.patch
>
>
> We already have two language detectors, lang-detect and Tika's lang detect. 
> This is a ticket that gives users third option using OpenNLP. :)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Assigned] (SOLR-11592) add another language detector using OpenNLP

[Koji Sekiguchi (JIRA)]

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

Koji Sekiguchi reassigned SOLR-11592:
-

Assignee: Steve Rowe

> add another language detector using OpenNLP
> ---
>
> Key: SOLR-11592
> URL: https://issues.apache.org/jira/browse/SOLR-11592
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LangId
>Affects Versions: 7.1
>    Reporter: Koji Sekiguchi
>Assignee: Steve Rowe
>Priority: Minor
> Attachments: SOLR-11592.patch, SOLR-11592.patch
>
>
> We already have two language detectors, lang-detect and Tika's lang detect. 
> This is a ticket that gives users third option using OpenNLP. :)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (SOLR-11592) add another language detector using OpenNLP

[Koji Sekiguchi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16328494#comment-16328494
 ] 

Koji Sekiguchi commented on SOLR-11592:
---

Looks good to me. :) 

> add another language detector using OpenNLP
> ---
>
> Key: SOLR-11592
> URL: https://issues.apache.org/jira/browse/SOLR-11592
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LangId
>Affects Versions: 7.1
>    Reporter: Koji Sekiguchi
>Priority: Minor
> Attachments: SOLR-11592.patch, SOLR-11592.patch
>
>
> We already have two language detectors, lang-detect and Tika's lang detect. 
> This is a ticket that gives users third option using OpenNLP. :)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: Welcome Ignacio Vera as Lucene/Solr committer

[Koji Sekiguchi]

Welcome Ignacio!

Koji

On 2018/01/12 1:35, Adrien Grand wrote:

Hi all,

Please join me in welcoming Ignacio Vera as the latest Lucene/Solr committer.
Ignacio, it's tradition for you to introduce yourself with a brief bio.

Congratulations and Welcome!


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

[jira] [Assigned] (SOLR-11795) Add Solr metrics exporter for Prometheus

[Koji Sekiguchi (JIRA)]

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

Koji Sekiguchi reassigned SOLR-11795:
-

Assignee: Koji Sekiguchi

> Add Solr metrics exporter for Prometheus
> 
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Assignee: Koji Sekiguchi
>Priority: Minor
> Attachments: SOLR-11795.patch, solr-dashboard.png, 
> solr-exporter-diagram.png
>
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Welcome Karl Wright to the PMC

[Koji Sekiguchi]

Welcome Karl!

Koji

On 2017/12/28 23:08, Adrien Grand wrote:

I am pleased to announce that Karl Wright has accepted the PMC's invitation to 
join.

Welcome Karl!


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

Re: Welcome Dennis Gove to the PMC

[Koji Sekiguchi]

Welcome Dennis!

Koji

On 2017/12/26 22:12, Joel Bernstein wrote:

I am pleased to announce that Dennis Gove has accepted the PMC's invitation to 
join.

Welcome Dennis!


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

[jira] [Commented] (SOLR-11795) Add Solr metrics exporter for Prometheus to contrib directory

[Koji Sekiguchi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16304127#comment-16304127
 ] 

Koji Sekiguchi commented on SOLR-11795:
---

+1 looks nice!

> Add Solr metrics exporter for Prometheus to contrib directory
> -
>
> Key: SOLR-11795
> URL: https://issues.apache.org/jira/browse/SOLR-11795
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>Affects Versions: 7.2
>Reporter: Minoru Osuka
>Priority: Minor
> Fix For: master (8.0)
>
> Attachments: solr-dashboard.png, solr-exporter-diagram.png
>
>
> I 'd like to monitor Solr using Prometheus and Grafana.
> I've already created Solr metrics exporter for Prometheus. I'd like to 
> contribute to contrib directory if you don't mind.
> !solr-exporter-diagram.png|thumbnail!
> !solr-dashboard.png|thumbnail!



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Welcome Jim Ferenczi to the PMC

[Koji Sekiguchi]

Welcome Jim!

Koji

On 2017/12/20 19:18, Adrien Grand wrote:

I am pleased to announce that Jim Ferenczi has accepted the PMC's invitation to 
join.

Welcome Jim!


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

Re: Welcome Ahmet Arslan as Lucene/Solr committer

[Koji Sekiguchi]

Welcome Ahmet!

Koji

On 2017/12/17 19:15, Adrien Grand wrote:

Hi all,

Please join me in welcoming Ahmet Arslan as the latest Lucene/Solr committer.
Ahmet, it's tradition for you to introduce yourself with a brief bio.

Congratulations and Welcome!

Adrien


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

Re: By pass text processing

[Koji Sekiguchi]

Hi Klaus,

Don't you use clustering and quantize vectors to make visual bag of words?
If you do these, I don't think you need to worry about overhead to store 
vectors to Lucene
because the number of clusters can be the ceiling of the number of words.

I used this technique in Apache alike which is a part of Apache Labs[1].
Apache alike uses Mahout for clustering of visual descriptors and Lucene for 
searching
similar pictures. The architecture can be found at [2].

Koji

[1] http://labs.apache.org/labs.html
[2] http://svn.apache.org/repos/asf/labs/alike/trunk/alike-architecture.pptx


On 2017/12/13 18:28, Klaus Schaefers wrote:

Hi,

I would like to build an extension to use lucene for image retrieval. I would present each image as 
a binary vector (visual bag of words). For now I can construct a string like "F1 F2 F10..." to 
insert my bit vector into lucene. Off course this adds quite some overhead, so I was wondering if I 
can directly write into the underlying storage engines...?


Cheers,

Klaus

--
“Overfitting” is not about an excessive amount of physical exercise...


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

Re: Welcome Ishan Chattopadhyaya to the PMC

[Koji Sekiguchi]

Welcome Ishan!

Koji

On 2017/12/08 22:47, Adrien Grand wrote:

I am pleased to announce that Ishan Chattopadhyaya has accepted the PMC's 
invitation to join.

Welcome Ishan!


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

Re: Welcome Noble Paul to the PMC

[Koji Sekiguchi]

Welcome Noble!

Koji

On 2017/11/20 5:02, Adrien Grand wrote:

I am pleased to announce that Noble Paul has accepted the PMC's invitation to 
join.

Welcome Noble!


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

[jira] [Commented] (SOLR-11592) add another language detector using OpenNLP

[Koji Sekiguchi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16243314#comment-16243314
 ] 

Koji Sekiguchi commented on SOLR-11592:
---

Hi Steve,

Thank you for reviewing the patch. You're right! I'll do them later, after 
finishing my project. Or, if Steve or someone can implement this, please take. 
I think I can review. :)

> add another language detector using OpenNLP
> ---
>
> Key: SOLR-11592
> URL: https://issues.apache.org/jira/browse/SOLR-11592
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LangId
>Affects Versions: 7.1
>    Reporter: Koji Sekiguchi
>Priority: Minor
> Attachments: SOLR-11592.patch
>
>
> We already have two language detectors, lang-detect and Tika's lang detect. 
> This is a ticket that gives users third option using OpenNLP. :)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Comment Edited] (SOLR-11592) add another language detector using OpenNLP

[Koji Sekiguchi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16233857#comment-16233857
 ] 

Koji Sekiguchi edited comment on SOLR-11592 at 11/2/17 12:55 AM:
-

OpenNLP's model covers 103 languages. 
https://svn.apache.org/repos/bigdata/opennlp/tags/langdetect-183_RC3/leipzig/resources/README.txt


was (Author: koji):
OpenNLP's model covers 103 languages.

> add another language detector using OpenNLP
> ---
>
> Key: SOLR-11592
> URL: https://issues.apache.org/jira/browse/SOLR-11592
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LangId
>Affects Versions: 7.1
>    Reporter: Koji Sekiguchi
>Priority: Minor
> Attachments: SOLR-11592.patch
>
>
> We already have two language detectors, lang-detect and Tika's lang detect. 
> This is a ticket that gives users third option using OpenNLP. :)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Commented] (SOLR-11592) add another language detector using OpenNLP

[Koji Sekiguchi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16233857#comment-16233857
 ] 

Koji Sekiguchi commented on SOLR-11592:
---

OpenNLP's model covers 103 languages.

> add another language detector using OpenNLP
> ---
>
> Key: SOLR-11592
> URL: https://issues.apache.org/jira/browse/SOLR-11592
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LangId
>Affects Versions: 7.1
>    Reporter: Koji Sekiguchi
>Priority: Minor
> Attachments: SOLR-11592.patch
>
>
> We already have two language detectors, lang-detect and Tika's lang detect. 
> This is a ticket that gives users third option using OpenNLP. :)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Updated] (SOLR-11592) add another language detector using OpenNLP

[Koji Sekiguchi (JIRA)]

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

Koji Sekiguchi updated SOLR-11592:
--
Attachment: SOLR-11592.patch

patch. it doesn't have any tests yet.

> add another language detector using OpenNLP
> ---
>
> Key: SOLR-11592
> URL: https://issues.apache.org/jira/browse/SOLR-11592
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: contrib - LangId
>Affects Versions: 7.1
>    Reporter: Koji Sekiguchi
>Priority: Minor
> Attachments: SOLR-11592.patch
>
>
> We already have two language detectors, lang-detect and Tika's lang detect. 
> This is a ticket that gives users third option using OpenNLP. :)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

[jira] [Created] (SOLR-11592) add another language detector using OpenNLP

[Koji Sekiguchi (JIRA)]

Koji Sekiguchi created SOLR-11592:
-

 Summary: add another language detector using OpenNLP
 Key: SOLR-11592
 URL: https://issues.apache.org/jira/browse/SOLR-11592
 Project: Solr
  Issue Type: New Feature
  Security Level: Public (Default Security Level. Issues are Public)
  Components: contrib - LangId
Affects Versions: 7.1
Reporter: Koji Sekiguchi
Priority: Minor


We already have two language detectors, lang-detect and Tika's lang detect. 
This is a ticket that gives users third option using OpenNLP. :)



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

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

Re: Welcome Hrishikesh Gadre as Lucene/Solr committer

[Koji Sekiguchi]

Welcome Hrishikesh!

Koji

On 2017/09/30 2:23, Yonik Seeley wrote:

Hi All,

Please join me in welcoming Hrishikesh Gadre as the latest Lucene/Solr
committer.
Hrishikesh, it's tradition for you to introduce yourself with a brief bio.

Congrats and Welcome!
-Yonik

-
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: is omitNorms still valid?

[Koji Sekiguchi]

Hi Adrien,

Thank you for the great explanation!

Koji


On 2017/08/22 19:36, Adrien Grand wrote:

Yes, LUCENE-7730 is the issue.

Le mar. 22 août 2017 à 12:00, Koji Sekiguchi <koji.sekigu...@rondhuit.com 
<mailto:koji.sekigu...@rondhuit.com>> a écrit :


I thought LUCENE-6819 removed the single byte float as well because to 
describe the background of
the ticket, you mentioned it was poor precision. So I thought the ticket 
solved it (from the
context).

So the field length is still stored in the single byte and the precision of 
the float still not
good? And the point of the LUCENE-6819 is that we can set more precise 
boost value if we want
because it no longer depends on the poor precision single byte for field 
length?


We still use a single byte in order to store the norm. The difference is that before we used to 
store ${index-boost} * ${length-norm}. Because index-boosts could take any positive value, we could 
not make any assumptions about this quantity that could have helped make storage more efficient. 
More concretely, length-norm was always between 0 and 1, so if you did not use index boosts like 
most Lucene users, then the final normalization factor would be in 0-1 as well. Yet only 125 out of 
the 256 bytes that the SmallFloat encoding that we used represent values between 0 and 1. So this 
feature was trading accuracy of the length normalization factor in favor of a feature that was only 
used by a minority and could be easily replaced by a doc-value field.


We actually went a bit further and started storing the document length rather than the precomputed 
length-normalization factor in the norms field. It is easier to reason about since we know all 
values are integers, positive, and that we want to have better accuracy for lower values. This 
allowed to encode lengths accurately up to 40, while the previous encoding that we used considered 3 
and 4 to be the same lengths for instance. Then accuracy degrades progressively as you can notice on 
the LUCENE-7730 ticket.





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

Re: is omitNorms still valid?

[Koji Sekiguchi]

LUCENE-7730 solved this?


On 2017/08/22 18:59, Koji Sekiguchi wrote:

Hi Adrien,

Thank you for your explanation!

I thought LUCENE-6819 removed the single byte float as well because to describe the background of 
the ticket, you mentioned it was poor precision. So I thought the ticket solved it (from the context).


So the field length is still stored in the single byte and the precision of the float still not 
good? And the point of the LUCENE-6819 is that we can set more precise boost value if we want 
because it no longer depends on the poor precision single byte for field length?


Thanks,

Koji


On 2017/08/22 18:10, Adrien Grand wrote:

Hi Koji,

OmitNorms is still valid. It used to store a scoring factor that depended on both the field length 
and an index-time boost. The only difference that LUCENE-6819 made is that norms now only store a 
number that depends on the field length since index-time boosts have been removed.


Le mar. 22 août 2017 à 10:30, Koji Sekiguchi <koji.sekigu...@rondhuit.com 
<mailto:koji.sekigu...@rondhuit.com>> a écrit :


    Hi,

    After LUCENE-6819 committed, I think omitNorms was removed but it seems it 
is still alive.

    Deprecate index-time boosts?
    https://issues.apache.org/jira/browse/LUCENE-6819

    Is it still valid or is there a ticket to delete it?

    Thanks,

    Koji

    -
    To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
<mailto:dev-unsubscr...@lucene.apache.org>

    For additional commands, e-mail: dev-h...@lucene.apache.org 
<mailto:dev-h...@lucene.apache.org>



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





--
最新ブログ記事〜Solr でランキング学習を体験する
http://lucene.jugem.jp/?eid=484
==
株式会社 ロンウイット
関口宏司
105-0003 東京都港区西新橋1-18-6
クロスオフィス内幸町 11階
TEL 03-5288-5927
FAX 03-5288-5928
http://www.rondhuit.com/
ブログ http://lucene.jugem.jp/

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

Re: is omitNorms still valid?

[Koji Sekiguchi]

Hi Adrien,

Thank you for your explanation!

I thought LUCENE-6819 removed the single byte float as well because to describe the background of 
the ticket, you mentioned it was poor precision. So I thought the ticket solved it (from the context).


So the field length is still stored in the single byte and the precision of the float still not 
good? And the point of the LUCENE-6819 is that we can set more precise boost value if we want 
because it no longer depends on the poor precision single byte for field length?


Thanks,

Koji


On 2017/08/22 18:10, Adrien Grand wrote:

Hi Koji,

OmitNorms is still valid. It used to store a scoring factor that depended on both the field length 
and an index-time boost. The only difference that LUCENE-6819 made is that norms now only store a 
number that depends on the field length since index-time boosts have been removed.


Le mar. 22 août 2017 à 10:30, Koji Sekiguchi <koji.sekigu...@rondhuit.com 
<mailto:koji.sekigu...@rondhuit.com>> a écrit :


Hi,

After LUCENE-6819 committed, I think omitNorms was removed but it seems it 
is still alive.

Deprecate index-time boosts?
https://issues.apache.org/jira/browse/LUCENE-6819

Is it still valid or is there a ticket to delete it?

Thanks,

Koji

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



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

is omitNorms still valid?

[Koji Sekiguchi]

Hi,

After LUCENE-6819 committed, I think omitNorms was removed but it seems it is 
still alive.

Deprecate index-time boosts?
https://issues.apache.org/jira/browse/LUCENE-6819

Is it still valid or is there a ticket to delete it?

Thanks,

Koji

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

Re: setMinimumNumberShouldMatch() for SynonymQuery

[Koji Sekiguchi]

Indeed!

After I posted the question, I thought same thing. :) I withdraw it but let me explain the 
background of the issue.


In a project, we've been using NGramTokenFilter since Solr 5.5 and the field which uses the 
TokenFilter is used from edismax. The problem I mentioned became actual when we moved to 6.3.0.


After SynonymQuery was introduced in LUCENE-6789, query string which is analyzed by NGramTokenFilter 
produces SynonymQuery and hence mm parameter for edismax couldn't be set to it.


By seeing branch_6x, I'm not sure it's been improved, but I think that tokens which are produced by 
NGramTokenFilter shouldn't be converted to SynonymQuery because they are not synonyms.


I'll check the latest branch and if it still produces SynonymQuery, I'll open a 
ticket.

Thanks,

Koji



On 2017/05/23 23:43, David Smiley wrote:

Koji,
I'm unconvinced it makes sense for SynonymQuery to have minShouldMatch.  Shouldn't the scenario of 
synonyms be a pure disjunction?  If you don't think so can you give a practical counter-example?

~ David

On Tue, May 23, 2017 at 6:01 AM Koji Sekiguchi <koji.sekigu...@rondhuit.com 
<mailto:koji.sekigu...@rondhuit.com>> wrote:


Hi,

Can we implement setMinimumNumberShouldMatch() for SynonymQuery, like 
BooleanQuery?

SynonymQuery was introduced in this ticket before I was aware:
https://issues.apache.org/jira/browse/LUCENE-6789

By this, analyzeBoolean() of QueryBuilder no longer creates BooleanQuery 
but SynonymQuery
instead, and then precision of certain queries decreased because mm 
parameter cannot be set.

First, I thought we should revert analyzeBoolean() so it uses BooleanQuery 
just like it used to be,
but we are already in 6.6, I think it is better for us to implement 
setMinimumNumberShouldMatch()
for SynonymQuery so we can set mm parameter for it.

Thought?

Thanks,

Koji

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

--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
http://www.solrenterprisesearchserver.com


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

setMinimumNumberShouldMatch() for SynonymQuery

[Koji Sekiguchi]

Hi,

Can we implement setMinimumNumberShouldMatch() for SynonymQuery, like 
BooleanQuery?

SynonymQuery was introduced in this ticket before I was aware:
https://issues.apache.org/jira/browse/LUCENE-6789

By this, analyzeBoolean() of QueryBuilder no longer creates BooleanQuery but 
SynonymQuery
instead, and then precision of certain queries decreased because mm parameter 
cannot be set.

First, I thought we should revert analyzeBoolean() so it uses BooleanQuery just 
like it used to be,
but we are already in 6.6, I think it is better for us to implement 
setMinimumNumberShouldMatch()
for SynonymQuery so we can set mm parameter for it.

Thought?

Thanks,

Koji

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

Re: Welcome Mike Drob as Lucene/Solr committer

[Koji Sekiguchi]

Welcome Mike!

Koji


On 2017/05/09 0:42, Mark Miller wrote:

I'm pleased to announce that Mike Drob has accepted the PMC's
invitation to become acommitter.

Mike, it's tradition that you introduce yourself with a brief bio /
origin story, explaining how you arrived here.

Your existing Apache handle has already added to the “lucene" LDAP group, so you now have commit 
privileges.


Please celebrate this rite of passage, and confirm that the right
karma has in fact enabled, by embarking on the challenge of adding
yourself to thecommitterssection of the Who We Are page on the
website:http://lucene.apache.org/whoweare.html 
(use the ASF CMS
bookmarklet
at the bottom of the page here:https://cms.apache.org/#bookmark-
more info herehttp://www.apache.org/dev/cms.html).

Congratulations andwelcome!
--
- Mark
about.me/markrmiller 


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

[jira] [Resolved] (SOLR-9184) Add convenience method to ModifiableSolrParams

[Koji Sekiguchi (JIRA)]

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

Koji Sekiguchi resolved SOLR-9184.
--
   Resolution: Fixed
Fix Version/s: 6.6

Thanks, Jörg!

> Add convenience method to ModifiableSolrParams
> --
>
> Key: SOLR-9184
> URL: https://issues.apache.org/jira/browse/SOLR-9184
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Reporter: Jörg Rathlev
>    Assignee: Koji Sekiguchi
>Priority: Minor
> Fix For: 6.6
>
> Attachments: SOLR-9184.patch, SOLR-9184.patch
>
>
> Add a static convenience method {{ModifiableSolrParams#of(SolrParams)}} which 
> returns the same instance if it already is modifiable, otherwise creates a 
> new {{ModifiableSolrParams}} instance.
> Rationale: when writing custom SearchComponents, we find that we often need 
> to ensure that the SolrParams are modifiable. The copy constructor of 
> ModifiableSolrParams always creates a copy, even if the SolrParms already are 
> modifiable.
> Alternatives: The method could also be added as a convenience method in 
> SolrParams itself, which already has static helper methods for wrapDefaults 
> and wrapAppended.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Assigned] (SOLR-9184) Add convenience method to ModifiableSolrParams

[Koji Sekiguchi (JIRA)]

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

Koji Sekiguchi reassigned SOLR-9184:


Assignee: Koji Sekiguchi

> Add convenience method to ModifiableSolrParams
> --
>
> Key: SOLR-9184
> URL: https://issues.apache.org/jira/browse/SOLR-9184
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Reporter: Jörg Rathlev
>    Assignee: Koji Sekiguchi
>Priority: Minor
> Attachments: SOLR-9184.patch
>
>
> Add a static convenience method {{ModifiableSolrParams#of(SolrParams)}} which 
> returns the same instance if it already is modifiable, otherwise creates a 
> new {{ModifiableSolrParams}} instance.
> Rationale: when writing custom SearchComponents, we find that we often need 
> to ensure that the SolrParams are modifiable. The copy constructor of 
> ModifiableSolrParams always creates a copy, even if the SolrParms already are 
> modifiable.
> Alternatives: The method could also be added as a convenience method in 
> SolrParams itself, which already has static helper methods for wrapDefaults 
> and wrapAppended.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Commented] (SOLR-9184) Add convenience method to ModifiableSolrParams

[Koji Sekiguchi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15935705#comment-15935705
 ] 

Koji Sekiguchi commented on SOLR-9184:
--

I think this is almost ready. How about adding assertNotSame for the first test?

> Add convenience method to ModifiableSolrParams
> --
>
> Key: SOLR-9184
> URL: https://issues.apache.org/jira/browse/SOLR-9184
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrJ
>Reporter: Jörg Rathlev
>Priority: Minor
> Attachments: SOLR-9184.patch
>
>
> Add a static convenience method {{ModifiableSolrParams#of(SolrParams)}} which 
> returns the same instance if it already is modifiable, otherwise creates a 
> new {{ModifiableSolrParams}} instance.
> Rationale: when writing custom SearchComponents, we find that we often need 
> to ensure that the SolrParams are modifiable. The copy constructor of 
> ModifiableSolrParams always creates a copy, even if the SolrParms already are 
> modifiable.
> Alternatives: The method could also be added as a convenience method in 
> SolrParams itself, which already has static helper methods for wrapDefaults 
> and wrapAppended.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

[jira] [Closed] (SOLR-2867) Problem Wtih solr Score Display

[Koji Sekiguchi (JIRA)]

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

Koji Sekiguchi closed SOLR-2867.

Resolution: Invalid

Please ask about your problem in the solr-user mailing list.

> Problem Wtih solr Score Display
> ---
>
> Key: SOLR-2867
> URL: https://issues.apache.org/jira/browse/SOLR-2867
> Project: Solr
>  Issue Type: Bug
>  Components: SearchComponents - other
>Affects Versions: 3.1
> Environment: Linux and Mysql
>Reporter: Pragyanjeet Rout
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> We are firing a solr query and checking its relevancy score.
> But problem with relevancy score is that for some results the value for score 
> is been truncated.
> Example:-I have a query as below
> http://localhost:8983/solr/mywork/select/?q=( contractLength:12 speedScore:[4 
> TO 7] dataScore:[2 TO *])=( ( connectionType:"Cable" 
> connectionType:"Naked")AND ( monthlyCost:[* TO *])AND ( speedScore:[4 TO 
> *])AND ( dataScore:[2 TO 
> *]))=2.2=0=500=on=score desc, planType asc, 
> monthlyCost1 asc, monthlyCost2  asc
> The below mentioned is my xml returned from solr :-
> 
> 3.6897283
> 12
> 3
> ABC
> 120.9
> 7
> 
> 
> 3.689728
> 12
> 2
> DEF
> 49.95
> 6
> 
> I have used the "debugQuery=true" in query and I saw solr is calculating the 
> correct score(PSB) but somehow is it truncating the lastdigit i.e "3" from 
> the second result.
> Because of this my ranking order gets disturbed and I get wrong results while 
> displaying 
> 
> 3.6897283 = (MATCH) sum of:3.1476827 = (MATCH) weight(contractLength:€#0;#12; 
> in 51), product of:0.92363054 = queryWeight(contractLength:€#0;#12;), product 
> of:3.4079456 = idf(docFreq=8, maxDocs=100)  0.27102268 = queryNorm 3.4079456 
> = (MATCH) fieldWeight(contractLength:€#0;#12; in 51), product of:1.0 = 
> tf(termFreq(contractLength:€#0;#12;)=1) 3.4079456 = idf(docFreq=8, 
> maxDocs=100)
>   1.0 = fieldNorm(field=contractLength, doc=51)  0.27102268 = (MATCH) 
> ConstantScore(speedScore:[€#0;#4; TO *]), product of:
> 1.0 = boost  0.27102268 = queryNorm  0.27102268 = (MATCH) 
> ConstantScore(dataScore:[€#0;#2; TO *]), product of: 1.0 = boost   0.27102268 
> = queryNorm
> 
> 
> 3.6897283 = (MATCH) sum of: 3.1476827 = (MATCH) 
> weight(contractLength:€#0;#12; in 97), product of: 0.92363054 = 
> queryWeight(contractLength:€#0;#12;), product of: 3.4079456 = idf(docFreq=8, 
> maxDocs=100)  0.27102268 = queryNorm 3.4079456 = (MATCH) 
> fieldWeight(contractLength:€#0;#12; in 97), product of: 1.0 = 
> tf(termFreq(contractLength:€#0;#12;)=1) 3.4079456 = idf(docFreq=8, 
> maxDocs=100)  1.0 = fieldNorm(field=contractLength, doc=97)  0.27102268 = 
> (MATCH) ConstantScore(speedScore:[€#0;#4; TO *]), product of: 1.0 = boost
> 0.27102268 = queryNorm  0.27102268 = (MATCH) 
> ConstantScore(dataScore:[€#0;#2; TO *]), product of:1.0 = boost
> 0.27102268 = queryNorm
> 
> Please educate me for the above behaviour from solr.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

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

Re: Welcome Toke Eskildsen as a Lucene/Solr committer

[Koji Sekiguchi]

Welcome Toke!

koji

On 2017/02/14 21:09, Jan Høydahl wrote:

I'm pleased to announce that Toke Eskildsen has accepted the Lucene
PMC's invitation to become a committer.

Toke, it's tradition that you introduce yourself with a brief bio.

Your account "toke" has been added to the “lucene" LDAP group, so you
now have commit privileges. Please test this by adding yourself to the
committers section of the Who We Are page on the website:
 (instructions here
).

The ASF dev page also has lots of useful links: .

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

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






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

[jira] [Resolved] (SOLR-9918) An UpdateRequestProcessor to skip duplicate inserts and ignore updates to missing docs

[Koji Sekiguchi (JIRA)]

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

Koji Sekiguchi resolved SOLR-9918.
--
   Resolution: Fixed
Fix Version/s: 6.4
   master (7.0)

Thanks, Tim!

> An UpdateRequestProcessor to skip duplicate inserts and ignore updates to 
> missing docs
> --
>
> Key: SOLR-9918
> URL: https://issues.apache.org/jira/browse/SOLR-9918
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Reporter: Tim Owen
>Assignee: Koji Sekiguchi
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-9918.patch, SOLR-9918.patch
>
>
> This is an UpdateRequestProcessor and Factory that we have been using in 
> production, to handle 2 common cases that were awkward to achieve using the 
> existing update pipeline and current processor classes:
> * When inserting document(s), if some already exist then quietly skip the new 
> document inserts - do not churn the index by replacing the existing documents 
> and do not throw a noisy exception that breaks the batch of inserts. By 
> analogy with SQL, {{insert if not exists}}. In our use-case, multiple 
> application instances can (rarely) process the same input so it's easier for 
> us to de-dupe these at Solr insert time than to funnel them into a global 
> ordered queue first.
> * When applying AtomicUpdate documents, if a document being updated does not 
> exist, quietly do nothing - do not create a new partially-populated document 
> and do not throw a noisy exception about missing required fields. By analogy 
> with SQL, {{update where id = ..}}. Our use-case relies on this because we 
> apply updates optimistically and have best-effort knowledge about what 
> documents will exist, so it's easiest to skip the updates (in the same way a 
> Database would).
> I would have kept this in our own package hierarchy but it relies on some 
> package-scoped methods, and seems like it could be useful to others if they 
> choose to configure it. Some bits of the code were borrowed from 
> {{DocBasedVersionConstraintsProcessorFactory}}.
> Attached patch has unit tests to confirm the behaviour.
> This class can be used by configuring solrconfig.xml like so..
> {noformat}
>   
> 
>  class="org.apache.solr.update.processor.SkipExistingDocumentsProcessorFactory">
>   true
>   false 
> 
> 
> 
>   
> {noformat}
> and initParams defaults of
> {noformat}
>   skipexisting
> {noformat}



--
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-9918) An UpdateRequestProcessor to skip duplicate inserts and ignore updates to missing docs

[Koji Sekiguchi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15813849#comment-15813849
 ] 

Koji Sekiguchi commented on SOLR-9918:
--

I think this is ready.

> An UpdateRequestProcessor to skip duplicate inserts and ignore updates to 
> missing docs
> --
>
> Key: SOLR-9918
> URL: https://issues.apache.org/jira/browse/SOLR-9918
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Reporter: Tim Owen
>Assignee: Koji Sekiguchi
> Attachments: SOLR-9918.patch, SOLR-9918.patch
>
>
> This is an UpdateRequestProcessor and Factory that we have been using in 
> production, to handle 2 common cases that were awkward to achieve using the 
> existing update pipeline and current processor classes:
> * When inserting document(s), if some already exist then quietly skip the new 
> document inserts - do not churn the index by replacing the existing documents 
> and do not throw a noisy exception that breaks the batch of inserts. By 
> analogy with SQL, {{insert if not exists}}. In our use-case, multiple 
> application instances can (rarely) process the same input so it's easier for 
> us to de-dupe these at Solr insert time than to funnel them into a global 
> ordered queue first.
> * When applying AtomicUpdate documents, if a document being updated does not 
> exist, quietly do nothing - do not create a new partially-populated document 
> and do not throw a noisy exception about missing required fields. By analogy 
> with SQL, {{update where id = ..}}. Our use-case relies on this because we 
> apply updates optimistically and have best-effort knowledge about what 
> documents will exist, so it's easiest to skip the updates (in the same way a 
> Database would).
> I would have kept this in our own package hierarchy but it relies on some 
> package-scoped methods, and seems like it could be useful to others if they 
> choose to configure it. Some bits of the code were borrowed from 
> {{DocBasedVersionConstraintsProcessorFactory}}.
> Attached patch has unit tests to confirm the behaviour.
> This class can be used by configuring solrconfig.xml like so..
> {noformat}
>   
> 
>  class="org.apache.solr.update.processor.SkipExistingDocumentsProcessorFactory">
>   true
>   false 
> 
> 
> 
>   
> {noformat}
> and initParams defaults of
> {noformat}
>   skipexisting
> {noformat}



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

Re: Welcome Cao Manh Dat as a Lucene/Solr committer

[Koji Sekiguchi]

Welcome and congrats Dat!

Koji

On 2017/01/10 0:57, Joel Bernstein wrote:

I'm pleased to announce that Cao Manh Dat has accepted the Lucene
PMC's invitation to become a committer.

Dat, it's tradition that you introduce yourself with a brief bio.

Your account has been added to the “lucene" LDAP group, so you
now have commit privileges. Please test this by adding yourself to the
committers section of the Who We Are page on the website:
> (instructions here
>).

The ASF dev page also has lots of useful links: .


Joel Bernstein
http://joelsolr.blogspot.com/




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

[jira] [Commented] (SOLR-9918) An UpdateRequestProcessor to skip duplicate inserts and ignore updates to missing docs

[Koji Sekiguchi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15806603#comment-15806603
 ] 

Koji Sekiguchi commented on SOLR-9918:
--

Thank you for giving the great explanation which is more than I expected. :)

> An UpdateRequestProcessor to skip duplicate inserts and ignore updates to 
> missing docs
> --
>
> Key: SOLR-9918
> URL: https://issues.apache.org/jira/browse/SOLR-9918
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Reporter: Tim Owen
>Assignee: Koji Sekiguchi
> Attachments: SOLR-9918.patch, SOLR-9918.patch
>
>
> This is an UpdateRequestProcessor and Factory that we have been using in 
> production, to handle 2 common cases that were awkward to achieve using the 
> existing update pipeline and current processor classes:
> * When inserting document(s), if some already exist then quietly skip the new 
> document inserts - do not churn the index by replacing the existing documents 
> and do not throw a noisy exception that breaks the batch of inserts. By 
> analogy with SQL, {{insert if not exists}}. In our use-case, multiple 
> application instances can (rarely) process the same input so it's easier for 
> us to de-dupe these at Solr insert time than to funnel them into a global 
> ordered queue first.
> * When applying AtomicUpdate documents, if a document being updated does not 
> exist, quietly do nothing - do not create a new partially-populated document 
> and do not throw a noisy exception about missing required fields. By analogy 
> with SQL, {{update where id = ..}}. Our use-case relies on this because we 
> apply updates optimistically and have best-effort knowledge about what 
> documents will exist, so it's easiest to skip the updates (in the same way a 
> Database would).
> I would have kept this in our own package hierarchy but it relies on some 
> package-scoped methods, and seems like it could be useful to others if they 
> choose to configure it. Some bits of the code were borrowed from 
> {{DocBasedVersionConstraintsProcessorFactory}}.
> Attached patch has unit tests to confirm the behaviour.
> This class can be used by configuring solrconfig.xml like so..
> {noformat}
>   
> 
>  class="org.apache.solr.update.processor.SkipExistingDocumentsProcessorFactory">
>   true
>   false 
> 
> 
> 
>   
> {noformat}
> and initParams defaults of
> {noformat}
>   skipexisting
> {noformat}



--
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] [Assigned] (SOLR-9918) An UpdateRequestProcessor to skip duplicate inserts and ignore updates to missing docs

[Koji Sekiguchi (JIRA)]

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

Koji Sekiguchi reassigned SOLR-9918:


Assignee: Koji Sekiguchi

> An UpdateRequestProcessor to skip duplicate inserts and ignore updates to 
> missing docs
> --
>
> Key: SOLR-9918
> URL: https://issues.apache.org/jira/browse/SOLR-9918
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Reporter: Tim Owen
>Assignee: Koji Sekiguchi
> Attachments: SOLR-9918.patch, SOLR-9918.patch
>
>
> This is an UpdateRequestProcessor and Factory that we have been using in 
> production, to handle 2 common cases that were awkward to achieve using the 
> existing update pipeline and current processor classes:
> * When inserting document(s), if some already exist then quietly skip the new 
> document inserts - do not churn the index by replacing the existing documents 
> and do not throw a noisy exception that breaks the batch of inserts. By 
> analogy with SQL, {{insert if not exists}}. In our use-case, multiple 
> application instances can (rarely) process the same input so it's easier for 
> us to de-dupe these at Solr insert time than to funnel them into a global 
> ordered queue first.
> * When applying AtomicUpdate documents, if a document being updated does not 
> exist, quietly do nothing - do not create a new partially-populated document 
> and do not throw a noisy exception about missing required fields. By analogy 
> with SQL, {{update where id = ..}}. Our use-case relies on this because we 
> apply updates optimistically and have best-effort knowledge about what 
> documents will exist, so it's easiest to skip the updates (in the same way a 
> Database would).
> I would have kept this in our own package hierarchy but it relies on some 
> package-scoped methods, and seems like it could be useful to others if they 
> choose to configure it. Some bits of the code were borrowed from 
> {{DocBasedVersionConstraintsProcessorFactory}}.
> Attached patch has unit tests to confirm the behaviour.
> This class can be used by configuring solrconfig.xml like so..
> {noformat}
>   
> 
>  class="org.apache.solr.update.processor.SkipExistingDocumentsProcessorFactory">
>   true
>   false 
> 
> 
> 
>   
> {noformat}
> and initParams defaults of
> {noformat}
>   skipexisting
> {noformat}



--
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-9918) An UpdateRequestProcessor to skip duplicate inserts and ignore updates to missing docs

[Koji Sekiguchi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15803344#comment-15803344
 ] 

Koji Sekiguchi commented on SOLR-9918:
--

Thank you for your additional explanation. I agree with you on the Confluence 
page is the best place to put that kind of guideline notes. I just wanted to 
see such information in the ticket, not javadoc, because I think it helps 
committers to understand the requirement and importance of this proposal.

As for SignatureUpdateProcessor, I thought it skipped to add the doc if the 
signature is same, but when I looked into the patch on SOLR-799, I noticed that 
it always updates the existing document even if the doc has the same signature.

> An UpdateRequestProcessor to skip duplicate inserts and ignore updates to 
> missing docs
> --
>
> Key: SOLR-9918
> URL: https://issues.apache.org/jira/browse/SOLR-9918
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Reporter: Tim Owen
> Attachments: SOLR-9918.patch, SOLR-9918.patch
>
>
> This is an UpdateRequestProcessor and Factory that we have been using in 
> production, to handle 2 common cases that were awkward to achieve using the 
> existing update pipeline and current processor classes:
> * When inserting document(s), if some already exist then quietly skip the new 
> document inserts - do not churn the index by replacing the existing documents 
> and do not throw a noisy exception that breaks the batch of inserts. By 
> analogy with SQL, {{insert if not exists}}. In our use-case, multiple 
> application instances can (rarely) process the same input so it's easier for 
> us to de-dupe these at Solr insert time than to funnel them into a global 
> ordered queue first.
> * When applying AtomicUpdate documents, if a document being updated does not 
> exist, quietly do nothing - do not create a new partially-populated document 
> and do not throw a noisy exception about missing required fields. By analogy 
> with SQL, {{update where id = ..}}. Our use-case relies on this because we 
> apply updates optimistically and have best-effort knowledge about what 
> documents will exist, so it's easiest to skip the updates (in the same way a 
> Database would).
> I would have kept this in our own package hierarchy but it relies on some 
> package-scoped methods, and seems like it could be useful to others if they 
> choose to configure it. Some bits of the code were borrowed from 
> {{DocBasedVersionConstraintsProcessorFactory}}.
> Attached patch has unit tests to confirm the behaviour.
> This class can be used by configuring solrconfig.xml like so..
> {noformat}
>   
> 
>  class="org.apache.solr.update.processor.SkipExistingDocumentsProcessorFactory">
>   true
>   false 
> 
> 
> 
>   
> {noformat}
> and initParams defaults of
> {noformat}
>   skipexisting
> {noformat}



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

Re: Welcome Jim Ferenczi as a Lucene/Solr committer

[Koji Sekiguchi]

Congratulations and welcome Jim!

koji

On 2017/01/01 19:04, Michael McCandless wrote:

I'm pleased to announce that Jim Ferenczi has accepted the Lucene
PMC's invitation to become a committer.

Jim, it's tradition that you introduce yourself with a brief bio.

Your handle "jimczi" has been added to the “lucene" LDAP group, so you
now have commit privileges. Please test this by adding yourself to the
committers section of the Who We Are page on the website:
 (instructions here
).

The ASF dev page also has lots of useful links: .

Congratulations and welcome and Happy New Year,

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






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

[jira] [Commented] (SOLR-9918) An UpdateRequestProcessor to skip duplicate inserts and ignore updates to missing docs

[Koji Sekiguchi (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15796928#comment-15796928
 ] 

Koji Sekiguchi commented on SOLR-9918:
--

I believe the proposal is very useful for users who need this function, but it 
is better for users if there is an additional explanation of the difference 
from the existing one that gives similar function.

How do users decide which UpdateRequestProcessor to use for their use cases as 
compared to SignatureUpdateProcessor?

> An UpdateRequestProcessor to skip duplicate inserts and ignore updates to 
> missing docs
> --
>
> Key: SOLR-9918
> URL: https://issues.apache.org/jira/browse/SOLR-9918
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: update
>Reporter: Tim Owen
> Attachments: SOLR-9918.patch
>
>
> This is an UpdateRequestProcessor and Factory that we have been using in 
> production, to handle 2 common cases that were awkward to achieve using the 
> existing update pipeline and current processor classes:
> * When inserting document(s), if some already exist then quietly skip the new 
> document inserts - do not churn the index by replacing the existing documents 
> and do not throw a noisy exception that breaks the batch of inserts. By 
> analogy with SQL, {{insert if not exists}}. In our use-case, multiple 
> application instances can (rarely) process the same input so it's easier for 
> us to de-dupe these at Solr insert time than to funnel them into a global 
> ordered queue first.
> * When applying AtomicUpdate documents, if a document being updated does not 
> exist, quietly do nothing - do not create a new partially-populated document 
> and do not throw a noisy exception about missing required fields. By analogy 
> with SQL, {{update where id = ..}}. Our use-case relies on this because we 
> apply updates optimistically and have best-effort knowledge about what 
> documents will exist, so it's easiest to skip the updates (in the same way a 
> Database would).
> I would have kept this in our own package hierarchy but it relies on some 
> package-scoped methods, and seems like it could be useful to others if they 
> choose to configure it. Some bits of the code were borrowed from 
> {{DocBasedVersionConstraintsProcessorFactory}}.
> Attached patch has unit tests to confirm the behaviour.
> This class can be used by configuring solrconfig.xml like so..
> {noformat}
>   
> 
>  class="org.apache.solr.update.processor.SkipExistingDocumentsProcessorFactory">
>   true
>   false 
> 
> 
> 
>   
> {noformat}
> and initParams defaults of
> {noformat}
>   skipexisting
> {noformat}



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

Re: Welcome Varun Thacker to the Apache Lucene/Solr PMC

[Koji Sekiguchi]

Welcome Varun!

Koji

On 2016/12/13 6:33, Anshum Gupta wrote:

I am pleased to announce that Varun Thacker has accepted the PMC's invitation 
to join.

Welcome Varun!

-Anshum



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