Re: [VOTE] Release PyLucene 8.8.1

2021-03-04 Thread Phil 
+1 from me

Tested the extension args output in JCC 3.9 - looks good!

Thanks,
Phil.

Andi Vajda writes:

> The PyLucene 8.8.1 (rc1) release tracking the recent release of
> Apache Lucene 8.8.1 is ready.
>
> A release candidate is available from:
>https://dist.apache.org/repos/dist/dev/lucene/pylucene/8.8.1-rc1/
>
> PyLucene 8.8.1 is built with JCC 3.9, included in these release artifacts.
>
> JCC 3.9 supports Python 3.3 up to Python 3.9 (in addition to Python 2.3+).
> PyLucene may be built with Python 2 or Python 3.
>
> Please vote to release these artifacts as PyLucene 8.8.1.
> Anyone interested in this release can and should vote !
>
> Thanks !
>
> Andi..
>
> ps: the KEYS file for PyLucene release signing is at:
> https://dist.apache.org/repos/dist/release/lucene/pylucene/KEYS
> https://dist.apache.org/repos/dist/dev/lucene/pylucene/KEYS
>
> pps: here is my +1

Re: jcc - Output unbuilt package

2021-03-01 Thread Phil 
Hi Andi,

Great - I've attached a one-line change that outputs the missing info to
stdout.  I haven't added a command line switch at this stage as there is
no functional change to the output - just an extra line of logging.

Note this is necessary because although the program already outputs the
setup args which are also required, the Extension class doesn't render
its args as text on printing the setup args, so I also need to output
the inputs to the Extension so that I can capture all the inputs to setup().

This would be hugely useful for me if we could even this simple change.

I will look at automating the full generation of a source package, and
adding an optional switch to control this - but this is a larger undertaking,
so I'll have to add it to the to-do list.  I'll let you know when I have
had a chance to implement this.

Cheers,
Phil.




Index: python.py
===
--- python.py	(revision 1887057)
+++ python.py	(working copy)
@@ -1870,6 +1870,7 @@
 i += 1
 config_vars['CFLAGS'] = ' '.join(cflags)
 
+print("extension args = %s" % args)
 extensions = [Extension('.'.join([moduleName, extname]), **args)]
 script_args.extend(extra_setup_args)
 

Andi Vajda writes:

>  Hi Phil,
>
> Excellent !
>
> Yes, I'd accept a patch that makes your feature available via a new
> command line flag to JCC (don't forget to document it in __main__.py).
>
> It's ok to only send in a patch for the python3 version (under
> jcc3). The python2 version (under jcc2) is maintenance only, don't
> bother.
>
> Thanks !
>
> Andi..
>
> On Sun, 28 Feb 2021, Phil wrote:
>
>>
>> Thanks very much for the reply Andi.
>>
>> I've done a bit more digging and the short answer is you can't do what I
>> wanted with the current JCC. but, it turns out it was fairly
>> straightforward to tweak JCC to provide me with the all details I needed.
>>
>> I successfully made this work today with Guix with the project
>> that previously used JCC to build a wheel.
>>
>> Do you accept patches onto the subversion source trunk? - I could
>> prepare a very simple, optional extension to dump out the data I needed.
>> If I have time I also could write something which would fully automate
>> the entire process in the future.
>>
>> Some more details below.
>>
>> Andi Vajda writes:
>>
>>> I did not write the bdist nor the wheel support, they were contributed
>>> and I don't now that --wheel makes a binary wheel, specifically.
>>> Note that you have binaries in whatever you distribute, if you
>>> consider that the JAR files or the .class files are binaries. They are
>>> required (.class files are) for JCC to operate as it uses reflection
>>> to do its job.
>>
>> Yes the --wheel switch implies that the C++ build will be performed.
>>
>> I agree the JAR/.class files will always be binaries, but it is
>> possible to distribute a package which contains only the JARs as
>> binaries, along with python API and unbuilt C/C++, with a setup.py,
>> describing the build process.
>>
>> This delays the calling of setuptools, and thus the building the C++ to
>> package install time rather than wheel creation time - and allows us to
>> create a regular setup.py file.
>>
>>>
>>> If you don't invoke JCC with --wheel, --bdist, --build or --compile,
>>> you get just source files (not countng .jar).
>>
>> Almost - you get the C++, but no setup.py or python wrapper generated.
>> At least this was the case for me.
>>
>> However, if you build the wheel the build directories do contain
>> everything you need apart from the setup.py - you just need to lift the
>> right files out and put them into the right directory structure.
>>
>> To create a setup.py you need both the setup and extension arguments
>> generated by JCC.  Normally these are fed straight into setuptools by
>> JCC, but we can leak them out instead.
>>
>> JCC already ouputs the setup arguments to stdout, so the only change I
>> had to do to the source was to also output the extension args
>> dictionary to stdout too, towards the end of:
>> https://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc/jcc3/python.py
>>
>> extensions = [Extension('.'.join([moduleName, extname]), **args)]
>>
>> print("extensions args = %s" % args) # I added this
>>
>>
>> Then at the bottom the setuptools args are already output to stdout:
>>
>> print("setup args = %s" % args)
>>
>> setup(**args)
>>
>>
>> My setup.py then contains

Re: jcc - Output unbuilt package

2021-02-28 Thread Phil 


Thanks very much for the reply Andi.

I've done a bit more digging and the short answer is you can't do what I
wanted with the current JCC. but, it turns out it was fairly
straightforward to tweak JCC to provide me with the all details I needed.

I successfully made this work today with Guix with the project
that previously used JCC to build a wheel.

Do you accept patches onto the subversion source trunk? - I could
prepare a very simple, optional extension to dump out the data I needed.
If I have time I also could write something which would fully automate
the entire process in the future.

Some more details below.

Andi Vajda writes:

> I did not write the bdist nor the wheel support, they were contributed
> and I don't now that --wheel makes a binary wheel, specifically.
> Note that you have binaries in whatever you distribute, if you
> consider that the JAR files or the .class files are binaries. They are
> required (.class files are) for JCC to operate as it uses reflection
> to do its job.

Yes the --wheel switch implies that the C++ build will be performed.

I agree the JAR/.class files will always be binaries, but it is
possible to distribute a package which contains only the JARs as
binaries, along with python API and unbuilt C/C++, with a setup.py,
describing the build process.

This delays the calling of setuptools, and thus the building the C++ to
package install time rather than wheel creation time - and allows us to
create a regular setup.py file.

>
> If you don't invoke JCC with --wheel, --bdist, --build or --compile,
> you get just source files (not countng .jar).

Almost - you get the C++, but no setup.py or python wrapper generated.
At least this was the case for me.

However, if you build the wheel the build directories do contain
everything you need apart from the setup.py - you just need to lift the
right files out and put them into the right directory structure.

To create a setup.py you need both the setup and extension arguments
generated by JCC.  Normally these are fed straight into setuptools by
JCC, but we can leak them out instead.

JCC already ouputs the setup arguments to stdout, so the only change I
had to do to the source was to also output the extension args
dictionary to stdout too, towards the end of:
https://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc/jcc3/python.py

extensions = [Extension('.'.join([moduleName, extname]), **args)]

print("extensions args = %s" % args) # I added this


Then at the bottom the setuptools args are already output to stdout:

print("setup args = %s" % args)

setup(**args)


My setup.py then contains a call to setuptools.setup() providing same
**args structure generated by the script (I'd link it here to demonstrate this,
but the repo is behind the a firewall, alas).

This plus a tiny bit of tweaking and boilerplate gives me exactly what I want.


> Maybe what you actually want is to implement 'sdist' support for JCC ?
> (again, not familiar with wheels, so I may not be making sense here).

I thought this too - but I couldn't get it to work.

I tried passing '--extra-setup-arg sdist' into JCC, but this got the
same result as not passing --build or --wheel as discussed above.  Only
C++ is generated.

> As long as GUIX knows how to drive a C++ compiler and linker, build
> python extensions (and knows how to build the libjcc shared library),
> you should be fine.

Yep this all works perfectly in Guix once we have a regular python repo
containing the source with the setup.py as described.

The only downside is the whole thing is rather manual now - I'd like to
tweak JCC to make this more streamlined - let me know if a patch
interests you?

jcc - Output unbuilt package

2021-02-27 Thread Phil 
Hi,

I currently use jcc to wrap a Java library for use in Python - it works
great.

The project I'm working on is moving it's package management from
traditional pip installs to Guix:
https://guix.gnu.org/

Guix handles python packages pretty well, and I have jcc running nicely on
there.

The problem I have is that Guix expects as an input a Python source
repo, but the jcc outputs a binary wheel.

What I'd like is for jcc to put together a source package, complete with
jars, C/C++, and python wrapper and a setup.py that is called to
generate the wheel.  But to stop short of generating the wheel for me.
I've had a look at the gnerated build directory - I could see the C/C++
source and jars, but there didn't seem to be a setup.py to trigger an install?

Such a directory could be then be fed into Guix who would happily build the 
package
and install it using the standard setup.py provided.

As a crude workaround I can try to unzip the contents of the produced wheel and 
stick the contents
into a repo, with a new setup.py, and MANIFEST.in file that would simply
copy across the jars and the previously build C/C++ library.  However
having the setup.py building the library and installing it is a more elegant 
solution.

Any ideas?

Thanks,
Phil.

RE: 8.5 release

2020-03-12 Thread Staley, Phil R - DCF 
What is the estimated ETA for 8.5 download?

From: Alan Woodward 
Sent: Thursday, March 12, 2020 11:25 AM
To: dev@lucene.apache.org
Subject: Re: 8.5 release

While I wait for the smoke tester to finish, I’ve been working on release 
notes.  The ReleaseTodo still refers to the old wiki, and release notes are on 
CWiki now, so I’m flying slightly blind.  Looking at what was done for the 
previous release, I’ve created a draft note for lucene which can be inspected 
and edited here:

https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641343=d4d3acb9-0dd6-4d40-903c-b16f2bb68415=shareui=1584025014586

For Solr, the 8.4 release note on CWiki points to a section on 
https://lucene.apache.org/solr/news.html
  but it’s not entirely clear where this section has come from or where it 
should be drafted.  Can anybody enlighten me?


On 11 Mar 2020, at 09:20, Alan Woodward 
mailto:romseyg...@gmail.com>> wrote:

Sure, go ahead


On 10 Mar 2020, at 19:22, David Smiley 
mailto:david.w.smi...@gmail.com>> wrote:

Can I assume it's no big deal to post a solr-ref-guide documentation 
improvement on the release branch irrespective of whenever you precisely do the 
RC?

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Tue, Mar 10, 2020 at 9:15 AM Joel Bernstein 
mailto:joels...@gmail.com>> wrote:
I just updated solr/CHANGES.txt as I missed something. If you've already 
created the RC then it will be there in case of a respin.



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


On Tue, Mar 10, 2020 at 5:45 AM Ignacio Vera 
mailto:iver...@gmail.com>> wrote:
done. Thank you!

On Tue, Mar 10, 2020 at 10:43 AM Alan Woodward 
mailto:romseyg...@gmail.com>> wrote:
Go ahead, I’ll start the release build once it’s in.


On 10 Mar 2020, at 07:26, Ignacio Vera 
mailto:iver...@gmail.com>> wrote:

Hi Alanm

Is it  possible to backport 
https://issues.apache.org/jira/browse/LUCENE-9263
 for the 8.5 release, I push it tester day and CI is happy.

Thanks,

On Tue, Mar 10, 2020 at 2:35 AM Joel Bernstein 
mailto:joels...@gmail.com>> wrote:

Finished the backport for 
https://issues.apache.org/jira/browse/SOLR-14073.

Thanks!


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


On Mon, Mar 9, 2020 at 8:44 AM Joel Bernstein 
mailto:joels...@gmail.com>> wrote:
Ok, I'll do the backport today. Thanks!

Joel Bernstein

SOLR version 8 bug???

2020-03-09 Thread Staley, Phil R - DCF 
We recently upgraded to our Drupal 8 sites to SOLR 8.3.1.  We are now getting 
reports of certain patterns of search terms resulting in an error that reads, 
"The website encountered an unexpected error. Please try again later."

Below is a list of example terms that always result in this error and a similar 
list that works fine.  The problem pattern seems to be a search term that 
contains 2 or 3 characters followed by a space, followed by additional text.

To confirm that the problem is version 8 of SOLR, I have updated our local and 
UAT sites with the latest Drupal updates that did include an update to the 
Search API Solr module and tested the terms below under SOLR 7.7.2, 8.3.1, and 
8.4.1.  Under version 7.7.2  everything works fine. Under either of the version 
8, the problem returns.

Thoughts?

 Search terms that result in error

* w-2 agency directory

* agency w-2 directory

* w-2 agency

* w-2 directory

* w2 agency directory

* w2 agency

* w2 directory

 Search terms that do not result in error

* w-22 agency directory

* agency directory w-2

* agency w-2directory

* agencyw-2 directory

* w-2

* w2

* agency directory

* agency * directory

* -2 agency directory

* 2 agency directory

* w-2agency directory

* w2agency directory

RE: Inconsistent query results in Lucene 8.1.0

2020-03-06 Thread Staley, Phil R - DCF 
We recently upgraded to our Drupal 8 sites to SOLR 8.3.1.  We are now getting 
reports of certain patterns of search terms resulting in an error that reads, 
“The website encountered an unexpected error. Please try again later.”



Below is a list of example terms that always result in this error and a similar 
list that works fine.  The problem pattern seems to be a search term that 
contains 2 or 3 characters followed by a space, followed by additional text.



To confirm that the problem is version 8 of SOLR, I have updated our local and 
UAT sites with the latest Drupal updates that did include an update to the 
Search API Solr module and tested the terms below under SOLR 7.7.2, 8.3.1, and 
8.4.1.  Under version 7.7.2  everything works fine. Under either of the version 
8, the problem returns.



Thoughts?



Search terms that result in error

• w-2 agency directory

• agency w-2 directory

• w-2 agency

• w-2 directory

• w2 agency directory

• w2 agency

• w2 directory



Search terms that do not result in error • w-22 agency directory • agency 
directory w-2 • agency w-2directory • agencyw-2 directory • w-2 • w2 • agency 
directory • agency • directory • -2 agency directory • 2 agency directory • 
w-2agency directory • w2agency directory


From: Michele Palmia 
Sent: Friday, March 6, 2020 9:50 AM
To: dev@lucene.apache.org
Subject: Re: Inconsistent query results in Lucene 8.1.0

Hi all,

I looked into this today. I can reproduce it and I believe it's a bug.
This is caused by the following working together:
- 
LUCENE-7386
 Flatten nested disjunctions
- 
LUCENE-7925
 Deduplicate SHOULD and MUST clauses in BooleanQuery

Blended term queries modify the df/ttf of their terms to make sure all terms 
produce identical scores. In this case, two blended term queries contain a few 
terms each, only some of which overlap. The two queries calculate different 
df/ttf for their terms respectively, since the two sets are different. During 
the rewrite process,

  1.  the two Blended queries get rewritten as Boolean queries themselves, with 
each (modified) TermQuery as a SHOULD clause
  2.  the nested Boolean queries get flattened, since they are nested 
disjunctions
  3.  the Term queries (some of which are actually Boost queries) are 
deduplicated, with one of the two TermQuery and its modified TermStates being 
picked at random (the randomness is due to the HashSet underlying Lucene's 
MultiSet).
I haven't managed to create a failing test yet, I'll share it when I have one 
ready.
If anybody has suggestions or pointers on how this should be fixed, I'm also 
happy to provide a patch - I'm just a bit clueless what the right thing to do 
would be here: I have a feeling (2.) should not happen for (rewritten) Blended 
Queries?

Cheers,
Michele


On Tue, Mar 3, 2020 at 7:55 PM Fiona Hasanaj 
mailto:fi...@basistech.com>> wrote:
Hello,

I’m Fiona with Basis Technology. We’re investigating what we believe to be a 
bug involving inconsistent query results. We have binary searched this issue 
and found that it specifically appears when flattening nested disjunctions was 
introduced with the merge of 
LUCENE-7386.
 In order to reproduce the issue, I have attached a Lucene index built in 
Lucene 8.1.0 as names_index.tar.gz and if you run the attached Java class 
(LuceneSearchIndex.java) multiple times against Lucene 8.0.0 you'll see the 
max_score is the same between runs whereas if you run it against Lucene 8.1.0 
you'll see inconsistent max_score between runs (try a max of 10 runs and you 
should be able to see that sometimes it returns max_score of 1.8651859 and 
sometimes 2.1415303).

From debugging in Lucene 8.1.0, the query against the name index before 
flattening its nested disjunctions looks like below:



(((bt_rni_name_encoded_1:ALFR)^0.75 bt_rni_name_encoded_1:ALTR 
(bt_rni_name_encoded_1:ANTR)^0.75

Re: strange behavior of solr query parser

2020-03-02 Thread Staley, Phil R - DCF 
I believe we are experiencing the same thing.


We recently upgraded to our Drupal 8 sites to SOLR 8.3.1.  We are now getting 
reports of certain patterns of search terms resulting in an error that reads, 
“The website encountered an unexpected error. Please try again later.”



Below is a list of example terms that always result in this error and a similar 
list that works fine.  The problem pattern seems to be a search term that 
contains 2 or 3 characters followed by a space, followed by additional text.



To confirm that the problem is version 8 of SOLR, I have updated our local and 
UAT sites with the latest Drupal updates that did include an update to the 
Search API Solr module and tested the terms below under SOLR 7.7.2, 8.3.1, and 
8.4.1.  Under version 7.7.2  everything works fine. Under either of the version 
8, the problem returns.



Thoughts?



Search terms that result in error

  *   w-2 agency directory
  *   agency w-2 directory
  *   w-2 agency
  *   w-2 directory
  *   w2 agency directory
  *   w2 agency
  *   w2 directory



Search terms that do not result in error

  *   w-22 agency directory
  *   agency directory w-2
  *   agency w-2directory
  *   agencyw-2 directory
  *   w-2
  *   w2
  *   agency directory
  *   agency
  *   directory
  *   -2 agency directory
  *   2 agency directory
  *   w-2agency directory
  *   w2agency directory





From: Hongtai Xue 
Sent: Monday, March 2, 2020 3:45 AM
To: solr_user lucene_apache 
Cc: dev@lucene.apache.org 
Subject: strange behavior of solr query parser


Hi,



Our team found a strange behavior of solr query parser.

In some specific cases, some conditional clauses on unindexed field will be 
ignored.



for query like, q=A:1 OR B:1 OR A:2 OR B:2

if field B is not indexed(but docValues="true"), "B:1" will be lost.



but if you write query like, q=A:1 OR A:2 OR B:1 OR B:2,

it will work perfect.



the only difference of two queries is that they are wrote in different orders.

one is ABAB, another is AABB,



■reproduce steps and example explanation

you can easily reproduce this problem on a solr collection with _default 
configset and exampledocs/books.csv data.



1. create a _default collection

bin/solr create -c books -s 2 -rf 2



2. post books.csv.

bin/post -c books example/exampledocs/books.csv



3. run following query.

http://localhost:8983/solr/books/select?q=%2B%28name_str%3AFoundation+OR+cat%3Abook+OR+name_str%3AJhereg+OR+cat%3Acd%29=query





I printed query parsing debug information.

you can tell "name_str:Foundation" is lost.



query: "name_str:Foundation OR cat:book OR name_str:Jhereg OR cat:cd"

(please note "Jhereg" is "4a 68 65 72 65 67" and "Foundation" is "46 6f 75 6e 
64 61 74 69 6f 6e")



  "debug":{

"rawquerystring":"+(name_str:Foundation OR cat:book OR name_str:Jhereg OR 
cat:cd)",

"querystring":"+(name_str:Foundation OR cat:book OR name_str:Jhereg OR 
cat:cd)",

"parsedquery":"+(cat:book cat:cd (name_str:[[4a 68 65 72 65 67] TO [4a 68 
65 72 65 67]]))",

"parsedquery_toString":"+(cat:book cat:cd name_str:[[4a 68 65 72 65 67] TO 
[4a 68 65 72 65 67]])",

"QParser":"LuceneQParser"}}





but for query: "name_str:Foundation OR name_str:Jhereg OR cat:book OR cat:cd",

everything is OK. "name_str:Foundation" is not lost.



  "debug":{

"rawquerystring":"+(name_str:Foundation OR name_str:Jhereg OR cat:book OR 
cat:cd)",

"querystring":"+(name_str:Foundation OR name_str:Jhereg OR cat:book OR 
cat:cd)",

"parsedquery":"+(cat:book cat:cd ((name_str:[[46 6f 75 6e 64 61 74 69 6f 
6e] TO [46 6f 75 6e 64 61 74 69 6f 6e]]) (name_str:[[4a 68 65 72 65 67] TO [4a 
68 65 72 65 67]])))",

"parsedquery_toString":"+(cat:book cat:cd (name_str:[[46 6f 75 6e 64 61 74 
69 6f 6e] TO [46 6f 75 6e 64 61 74 69 6f 6e]] name_str:[[4a 68 65 72 65 67] TO 
[4a 68 65 72 65 67]]))",

"QParser":"LuceneQParser"}}



http://localhost:8983/solr/books/select?q=%2B%28name_str%3AFoundation+OR+name_str%3AJhereg+OR+cat%3Abook+OR+cat%3Acd%29=query



we did a little bit research, and we wander if it is a bug of SolrQueryParser.

more specifically, we think if statement here might be wrong.

https://github.com/apache/lucene-solr/blob/branch_8_4/solr/core/src/java/org/apache/solr/parser/SolrQueryParserBase.java#L711



Could you please tell us if it is a bug, or it's just a wrong query statement.



Thanks,

Hongtai Xue

[jira] [Commented] (SOLR-7090) Cross collection join

2016-11-19 Thread Phil Phillips (JIRA) 

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

Phil Phillips commented on SOLR-7090:
-

Aha, I didn't have the fields set with docValues. It's working a lot better 
with that.

> Cross collection join
> -
>
> Key: SOLR-7090
> URL: https://issues.apache.org/jira/browse/SOLR-7090
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
> Fix For: 5.2, 6.0
>
> Attachments: SOLR-7090-fulljoin.patch, SOLR-7090.patch
>
>
> Although SOLR-4905 supports joins across collections in Cloud mode, there are 
> limitations, (i) the secondary collection must be replicated at each node 
> where the primary collection has a replica, (ii) the secondary collection 
> must be singly sharded.
> This issue explores ideas/possibilities of cross collection joins, even 
> across nodes. This will be helpful for users who wish to maintain boosts or 
> signals in a secondary, more frequently updated collection, and perform query 
> time join of these boosts/signals with results from the primary collection.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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

[jira] [Comment Edited] (SOLR-7090) Cross collection join

2016-11-18 Thread Phil Phillips (JIRA) 

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

Phil Phillips edited comment on SOLR-7090 at 11/18/16 11:42 PM:


The "fulljoin" patch seems to do the trick for me.  One thing I noticed is that 
in the facet query, I had to add {{facet.limit=-1}} to get it to return all the 
results (this was for a larger index). So far, it's performing reasonably well. 
I can report back once I add in more documents.

As Erick suggested, I did try streaming as well. I was able to get what I 
wanted with a stream expression (with {{sort}} and {{innerJoin}}).  However, I 
could only get it to work the way I wanted if I stored the fields that I was 
joining/sorting on. That wouldn't be ideal in my scenario.


was (Author: irphilli):
The "fulljoin" patch seems to do the trick for me.  One thing I noticed is that 
in the facet query, I had to add {{facet.limit=-1}} to get it to return all the 
results (this was for a larger index). So far, it's performing reasonably well. 
I can report back once I add in more documents.

As Erick suggested, I did try a streaming as well. I was able to get what I 
wanted with a stream expression (with {{sort}} and {{innerJoin}}).  However, I 
could only get it to work the way I wanted if I stored the fields that I was 
joining/sorting on. That wouldn't be ideal in my scenario.

> Cross collection join
> -
>
> Key: SOLR-7090
> URL: https://issues.apache.org/jira/browse/SOLR-7090
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
> Fix For: 5.2, 6.0
>
> Attachments: SOLR-7090-fulljoin.patch, SOLR-7090.patch
>
>
> Although SOLR-4905 supports joins across collections in Cloud mode, there are 
> limitations, (i) the secondary collection must be replicated at each node 
> where the primary collection has a replica, (ii) the secondary collection 
> must be singly sharded.
> This issue explores ideas/possibilities of cross collection joins, even 
> across nodes. This will be helpful for users who wish to maintain boosts or 
> signals in a secondary, more frequently updated collection, and perform query 
> time join of these boosts/signals with results from the primary collection.



--
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-7090) Cross collection join

2016-11-18 Thread Phil Phillips (JIRA) 

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

Phil Phillips commented on SOLR-7090:
-

The "fulljoin" patch seems to do the trick for me.  One thing I noticed is that 
in the facet query, I had to add {{facet.limit=-1}} to get it to return all the 
results (this was for a larger index). So far, it's performing reasonably well. 
I can report back once I add in more documents.

As Erick suggested, I did try a streaming as well. I was able to get what I 
wanted with a stream expression (with {{sort}} and {{innerJoin}}).  However, I 
could only get it to work the way I wanted if I stored the fields that I was 
joining/sorting on. That wouldn't be ideal in my scenario.

> Cross collection join
> -
>
> Key: SOLR-7090
> URL: https://issues.apache.org/jira/browse/SOLR-7090
> Project: Solr
>  Issue Type: New Feature
>Reporter: Ishan Chattopadhyaya
> Fix For: 5.2, 6.0
>
> Attachments: SOLR-7090-fulljoin.patch, SOLR-7090.patch
>
>
> Although SOLR-4905 supports joins across collections in Cloud mode, there are 
> limitations, (i) the secondary collection must be replicated at each node 
> where the primary collection has a replica, (ii) the secondary collection 
> must be singly sharded.
> This issue explores ideas/possibilities of cross collection joins, even 
> across nodes. This will be helpful for users who wish to maintain boosts or 
> signals in a secondary, more frequently updated collection, and perform query 
> time join of these boosts/signals with results from the primary collection.



--
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-4449) Enable backup requests for the internal solr load balancer

2016-10-21 Thread Phil Hoy (JIRA) 

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

Phil Hoy commented on SOLR-4449:


I no longer work at Findmypast. Thank you.


> Enable backup requests for the internal solr load balancer
> --
>
> Key: SOLR-4449
> URL: https://issues.apache.org/jira/browse/SOLR-4449
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: philip hoy
>Priority: Minor
>  Labels: patch, patch-available
> Attachments: SOLR-4449.patch, SOLR-4449.patch, SOLR-4449.patch, 
> patch-4449.txt, solr-back-request-lb-plugin.jar
>
>
> Add the ability to configure the built-in solr load balancer such that it 
> submits a backup request to the next server in the list if the initial 
> request takes too long. Employing such an algorithm could improve the latency 
> of the 9xth percentile albeit at the expense of increasing overall load due 
> to additional requests. 



--
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] [Created] (SOLR-8641) Core Deleted After Failed Index Fetch When Replication Disabled

2016-02-04 Thread phil watson (JIRA) 
phil watson created SOLR-8641:
-

 Summary: Core Deleted After Failed Index Fetch When Replication 
Disabled
 Key: SOLR-8641
 URL: https://issues.apache.org/jira/browse/SOLR-8641
 Project: Solr
  Issue Type: Bug
  Components: replication (java)
Affects Versions: 5.1
 Environment: Windows Server 2008 R2
Reporter: phil watson


I am getting occasional Index Fetch Failures (due to server overloading I 
suspect). This is appearing in my log file as

Master at: http://MOTOSOLR01:9000/solr/ShowcaseData is not available. Index 
fetch failed. Exception: Server refused connection at: 
http://MOTOSOLR01:9000/solr/ShowcaseData

At the point of the failure the master version of the core has replication 
disabled (but still contains data) and it appears that on the next replication 
cycle that the slave version of the core is being emptied. Once replication is 
enabled everything works as expected.

Having looked at the source code I suspect that lines 311-327 in 
indexfetcher.java are at fault. What I think is happening is that the failed 
IndexFetch is setting forcereplication to true, and this cause a forced delete 
of the core before reloading the core (which then doesn't happen as replication 
is disabled)






--
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: IndexReader.removeReaderClosedListener

2014-08-20 Thread Phil Herold 
Bingo. ensureOpen() should not be called from this method. Thanks.

--
Phil


On Wed, Aug 20, 2014 at 4:55 AM, Uwe Schindler u...@thetaphi.de wrote:

 Hi,

 In my opinion, removing the listener before close looks wrong. Because you
 would not get the listener events for the explicit close of the
 DirectoryReader.

 I would just remove the ensureOpen(). We should open issue.

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


  -Original Message-
  From: Michael McCandless [mailto:luc...@mikemccandless.com]
  Sent: Wednesday, August 20, 2014 9:53 AM
  To: Lucene/Solr dev; Phil Herold
  Subject: Re: IndexReader.removeReaderClosedListener
 
  Hmm, you should call this method before closing the IndexReader, to
  remove a listener you previously added.
 
  Mike McCandless
 
  http://blog.mikemccandless.com
 
 
  On Tue, Aug 19, 2014 at 11:27 AM, Phil Herold herold.p...@gmail.com
  wrote:
   The implementation of this final method (latest 4.9 code) calls
   ensureOpen(), which fails, since the reader is closed. As a result,
   this method doesn't work. It seems as if this is therefore a potential
   memory leak,  not being able to remove the listener. Or am I missing
  something?
  
   --
   Phil
 
  -
  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: IndexReader.removeReaderClosedListener

2014-08-20 Thread Phil Herold 
Fine. I'm sure you've got a good reason for this. But it is totally
un-intuitive, and introduces a potential memory leak, IMO. The
implementation of this pattern is definitely different than just about any
other library I can think of.

Given that having a listener for index closed doesn't really solve the
issue I was having that I was hoping it would, it doesn't much matter to me
at this point.

Thanks.

--
Phil


On Wed, Aug 20, 2014 at 8:37 AM, Robert Muir rcm...@gmail.com wrote:

 I don't agree. Operations like this shouldnt be performed on closed
 readers.

 the ensureOpen is correct.

 On Wed, Aug 20, 2014 at 8:27 AM, Phil Herold pher...@nc.rr.com wrote:
  Bingo. ensureOpen() should not be called from this method. Thanks.
 
  --
  Phil
 
 
 
  On Wed, Aug 20, 2014 at 4:55 AM, Uwe Schindler u...@thetaphi.de wrote:
 
  Hi,
 
  In my opinion, removing the listener before close looks wrong. Because
 you
  would not get the listener events for the explicit close of the
  DirectoryReader.
 
  I would just remove the ensureOpen(). We should open issue.
 
  Uwe
  -
  Uwe Schindler
  H.-H.-Meier-Allee 63, D-28213 Bremen
  http://www.thetaphi.de
  eMail: u...@thetaphi.de
 
 
   -Original Message-
   From: Michael McCandless [mailto:luc...@mikemccandless.com]
   Sent: Wednesday, August 20, 2014 9:53 AM
   To: Lucene/Solr dev; Phil Herold
   Subject: Re: IndexReader.removeReaderClosedListener
  
   Hmm, you should call this method before closing the IndexReader, to
   remove a listener you previously added.
  
   Mike McCandless
  
   http://blog.mikemccandless.com
  
  
   On Tue, Aug 19, 2014 at 11:27 AM, Phil Herold herold.p...@gmail.com
   wrote:
The implementation of this final method (latest 4.9 code) calls
ensureOpen(), which fails, since the reader is closed. As a result,
this method doesn't work. It seems as if this is therefore a
 potential
memory leak,  not being able to remove the listener. Or am I missing
   something?
   
--
Phil
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
 additional
   commands, e-mail: dev-h...@lucene.apache.org
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
  For additional commands, e-mail: dev-h...@lucene.apache.org
 
 

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

Re: IndexReader.removeReaderClosedListener

2014-08-20 Thread Phil Herold 
If the IndexReader is still holding a reference to the listener in its
collection, I don't see how it could be GC'ed. This is a pretty classic
memory leak case.

--
Phil


On Wed, Aug 20, 2014 at 11:15 AM, Uwe Schindler u...@thetaphi.de wrote:

 Yeah,



 I dont see the memory leak, too. After you closed the IndexReader its free
 for garbage collection. So it should no longer block the listener to be
 GCed.



 Uwe



 -

 Uwe Schindler

 H.-H.-Meier-Allee 63, D-28213 Bremen

 http://www.thetaphi.de

 eMail: u...@thetaphi.de



 *From:* Shai Erera [mailto:ser...@gmail.com]
 *Sent:* Wednesday, August 20, 2014 5:10 PM
 *To:* dev@lucene.apache.org
 *Subject:* Re: IndexReader.removeReaderClosedListener



 I don't understand something -- you add a ReaderClosedListener to get a
 notification when IR.close() is called (actually, when it's actually being
 closed). Why removing the listener after the reader has been closed? Don't
 apps usually nullify their IR member after it's been closed?

 Shai



 On Wed, Aug 20, 2014 at 5:51 PM, Phil Herold pher...@nc.rr.com wrote:

 Fine. I'm sure you've got a good reason for this. But it is totally
 un-intuitive, and introduces a potential memory leak, IMO. The
 implementation of this pattern is definitely different than just about any
 other library I can think of.



 Given that having a listener for index closed doesn't really solve the
 issue I was having that I was hoping it would, it doesn't much matter to me
 at this point.



 Thanks.



 --

 Phil



 On Wed, Aug 20, 2014 at 8:37 AM, Robert Muir rcm...@gmail.com wrote:

 I don't agree. Operations like this shouldnt be performed on closed
 readers.

 the ensureOpen is correct.


 On Wed, Aug 20, 2014 at 8:27 AM, Phil Herold pher...@nc.rr.com wrote:
  Bingo. ensureOpen() should not be called from this method. Thanks.
 
  --
  Phil
 
 
 
  On Wed, Aug 20, 2014 at 4:55 AM, Uwe Schindler u...@thetaphi.de wrote:
 
  Hi,
 
  In my opinion, removing the listener before close looks wrong. Because
 you
  would not get the listener events for the explicit close of the
  DirectoryReader.
 
  I would just remove the ensureOpen(). We should open issue.
 
  Uwe
  -
  Uwe Schindler
  H.-H.-Meier-Allee 63, D-28213 Bremen
  http://www.thetaphi.de
  eMail: u...@thetaphi.de
 
 
   -Original Message-
   From: Michael McCandless [mailto:luc...@mikemccandless.com]
   Sent: Wednesday, August 20, 2014 9:53 AM
   To: Lucene/Solr dev; Phil Herold
   Subject: Re: IndexReader.removeReaderClosedListener
  
   Hmm, you should call this method before closing the IndexReader, to
   remove a listener you previously added.
  
   Mike McCandless
  
   http://blog.mikemccandless.com
  
  
   On Tue, Aug 19, 2014 at 11:27 AM, Phil Herold herold.p...@gmail.com
   wrote:
The implementation of this final method (latest 4.9 code) calls
ensureOpen(), which fails, since the reader is closed. As a result,
this method doesn't work. It seems as if this is therefore a
 potential
memory leak,  not being able to remove the listener. Or am I missing
   something?
   
--
Phil
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
 additional
   commands, e-mail: dev-h...@lucene.apache.org
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
  For additional commands, e-mail: dev-h...@lucene.apache.org
 
 

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

IndexReader.removeReaderClosedListener

2014-08-19 Thread Phil Herold 
The implementation of this final method (latest 4.9 code) calls ensureOpen(),
which fails, since the reader is closed. As a result, this method doesn't
work. It seems as if this is therefore a potential memory leak,  not being
able to remove the listener. Or am I missing something?

--
Phil

[jira] [Commented] (SOLR-5027) Field Collapsing PostFilter

2013-12-21 Thread Phil John (JIRA) 

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

Phil John commented on SOLR-5027:
-

Hi Joel,

Thanks for the clarification - I wondered if it would be in the expander, but 
came away a bit confused as to what that would end up doing.

Nice to know it'll come, and as a workaround we can just query for counts from 
our DB grouped by collapse key until it lands in trunk.

Thanks,

Phil.

 Field Collapsing PostFilter
 ---

 Key: SOLR-5027
 URL: https://issues.apache.org/jira/browse/SOLR-5027
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: 5.0
Reporter: Joel Bernstein
Assignee: Joel Bernstein
Priority: Minor
 Fix For: 4.6, 5.0

 Attachments: SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch, 
 SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch, 
 SOLR-5027.patch, SOLR-5027.patch


 This ticket introduces the *CollapsingQParserPlugin* 
 The *CollapsingQParserPlugin* is a PostFilter that performs field collapsing. 
 This is a high performance alternative to standard Solr field collapsing 
 (with *ngroups*) when the number of distinct groups in the result set is high.
 For example in one performance test, a search with 10 million full results 
 and 1 million collapsed groups:
 Standard grouping with ngroups : 17 seconds.
 CollapsingQParserPlugin: 300 milli-seconds.
 Sample syntax:
 Collapse based on the highest scoring document:
 {code}
 fq=(!collapse field=field_name}
 {code}
 Collapse based on the min value of a numeric field:
 {code}
 fq={!collapse field=field_name min=field_name}
 {code}
 Collapse based on the max value of a numeric field:
 {code}
 fq={!collapse field=field_name max=field_name}
 {code}
 Collapse with a null policy:
 {code}
 fq={!collapse field=field_name nullPolicy=null_policy}
 {code}
 There are three null policies:
 ignore : removes docs with a null value in the collapse field (default).
 expand : treats each doc with a null value in the collapse field as a 
 separate group.
 collapse : collapses all docs with a null value into a single group using 
 either highest score, or min/max.
 The CollapsingQParserPlugin also fully supports the QueryElevationComponent
 *Note:*  The July 16 patch also includes and ExpandComponent that expands the 
 collapsed groups for the current search result page. This functionality will 
 be moved to it's own ticket.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

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

[jira] [Commented] (SOLR-5027) Field Collapsing PostFilter

2013-12-20 Thread Phil John (JIRA) 

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

Phil John commented on SOLR-5027:
-

The one thing this doesn't seem to do, which the current field collapsing 
solution does, is say how many items there are in each group - which is useful 
if you want to display the top result, but also have a link saying X other 
available. Our use case is collapsing down multiple manifestations of a 
bibliographic work (i.e. multiple editions of the same work), so with the 
grouping feature we get a count back of the size of the group and can go 5 
other editions also available and then link to a search on the key we 
collapsed by.

Is this planned, or will that come in the more generic aggregation support 
planned for 5.0?

 Field Collapsing PostFilter
 ---

 Key: SOLR-5027
 URL: https://issues.apache.org/jira/browse/SOLR-5027
 Project: Solr
  Issue Type: New Feature
  Components: search
Affects Versions: 5.0
Reporter: Joel Bernstein
Assignee: Joel Bernstein
Priority: Minor
 Fix For: 4.6, 5.0

 Attachments: SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch, 
 SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch, SOLR-5027.patch, 
 SOLR-5027.patch, SOLR-5027.patch


 This ticket introduces the *CollapsingQParserPlugin* 
 The *CollapsingQParserPlugin* is a PostFilter that performs field collapsing. 
 This is a high performance alternative to standard Solr field collapsing 
 (with *ngroups*) when the number of distinct groups in the result set is high.
 For example in one performance test, a search with 10 million full results 
 and 1 million collapsed groups:
 Standard grouping with ngroups : 17 seconds.
 CollapsingQParserPlugin: 300 milli-seconds.
 Sample syntax:
 Collapse based on the highest scoring document:
 {code}
 fq=(!collapse field=field_name}
 {code}
 Collapse based on the min value of a numeric field:
 {code}
 fq={!collapse field=field_name min=field_name}
 {code}
 Collapse based on the max value of a numeric field:
 {code}
 fq={!collapse field=field_name max=field_name}
 {code}
 Collapse with a null policy:
 {code}
 fq={!collapse field=field_name nullPolicy=null_policy}
 {code}
 There are three null policies:
 ignore : removes docs with a null value in the collapse field (default).
 expand : treats each doc with a null value in the collapse field as a 
 separate group.
 collapse : collapses all docs with a null value into a single group using 
 either highest score, or min/max.
 The CollapsingQParserPlugin also fully supports the QueryElevationComponent
 *Note:*  The July 16 patch also includes and ExpandComponent that expands the 
 collapsed groups for the current search result page. This functionality will 
 be moved to it's own ticket.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)

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

[jira] [Commented] (SOLR-4629) Stronger standard replication testing.

2013-03-22 Thread Phil John (JIRA) 

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

Phil John commented on SOLR-4629:
-

Just to add, I'm seeing this as well on our setup (1 master, 2 slaves, 
traditional replication setup rather than solrcloud).



 Stronger standard replication testing.
 --

 Key: SOLR-4629
 URL: https://issues.apache.org/jira/browse/SOLR-4629
 Project: Solr
  Issue Type: Test
  Components: replication (java)
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.3, 5.0, 4.2.1


 I added to these tests recently, but there is a report on the list indicating 
 we may still be missing something. Most reports have been positive so far 
 after the 4.2 fixes, but I'd feel better after adding some more testing.

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

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

[jira] [Issue Comment Deleted] (SOLR-4629) Stronger standard replication testing.

2013-03-22 Thread Phil John (JIRA) 

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

Phil John updated SOLR-4629:


Comment: was deleted

(was: Just to add, I'm seeing this as well on our setup (1 master, 2 slaves, 
traditional replication setup rather than solrcloud).

)

 Stronger standard replication testing.
 --

 Key: SOLR-4629
 URL: https://issues.apache.org/jira/browse/SOLR-4629
 Project: Solr
  Issue Type: Test
  Components: replication (java)
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.3, 5.0, 4.2.1


 I added to these tests recently, but there is a report on the list indicating 
 we may still be missing something. Most reports have been positive so far 
 after the 4.2 fixes, but I'd feel better after adding some more testing.

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

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

[jira] [Commented] (SOLR-4573) oejh.HttpGenerator:Ignoring extra content when accessing Solr HTTP Admin Console in Solr Cloud example

2013-03-16 Thread Phil John (JIRA) 

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

Phil John commented on SOLR-4573:
-

You're welcome.

 oejh.HttpGenerator:Ignoring extra content when accessing Solr HTTP Admin 
 Console in Solr Cloud example
 --

 Key: SOLR-4573
 URL: https://issues.apache.org/jira/browse/SOLR-4573
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud, web gui
Affects Versions: 4.2
 Environment: Windows x64
 java version 1.7.0_11
 Java(TM) SE Runtime Environment (build 1.7.0_11-b21)
 Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)
Reporter: Phil John
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.3, 5.0


 When running the example config included in the Solr distribution based on 
 the instructions here:
 http://wiki.apache.org/solr/SolrCloud#Example_A:_Simple_two_shard_cluster
 Any requests to pages in the web gui cause a warning log message to be raised 
 on Jetty's STDOUT
 2013-03-13 19:52:45.827:WARN:oejh.HttpGenerator:Ignoring extra content
 followed by the content of the file being served.

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

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

[jira] [Commented] (SOLR-4573) oejh.HttpGenerator:Ignoring extra content when accessing Solr HTTP Admin Console in Solr Cloud example

2013-03-14 Thread Phil John (JIRA) 

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

Phil John commented on SOLR-4573:
-

There's a thread on jetty-users that seems to describe this issue: 
http://dev.eclipse.org/mhonarc/lists/jetty-users/msg02355.html

 oejh.HttpGenerator:Ignoring extra content when accessing Solr HTTP Admin 
 Console in Solr Cloud example
 --

 Key: SOLR-4573
 URL: https://issues.apache.org/jira/browse/SOLR-4573
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud, web gui
Affects Versions: 4.2
 Environment: Windows x64
 java version 1.7.0_11
 Java(TM) SE Runtime Environment (build 1.7.0_11-b21)
 Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)
Reporter: Phil John
Priority: Minor

 When running the example config included in the Solr distribution based on 
 the instructions here:
 http://wiki.apache.org/solr/SolrCloud#Example_A:_Simple_two_shard_cluster
 Any requests to pages in the web gui cause a warning log message to be raised 
 on Jetty's STDOUT
 2013-03-13 19:52:45.827:WARN:oejh.HttpGenerator:Ignoring extra content
 followed by the content of the file being served.

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

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

[jira] [Created] (SOLR-4573) oejh.HttpGenerator:Ignoring extra content when accessing Solr HTTP Admin Console in Solr Cloud example

2013-03-13 Thread Phil John (JIRA) 
Phil John created SOLR-4573:
---

 Summary: oejh.HttpGenerator:Ignoring extra content when accessing 
Solr HTTP Admin Console in Solr Cloud example
 Key: SOLR-4573
 URL: https://issues.apache.org/jira/browse/SOLR-4573
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud, web gui
Affects Versions: 4.2
 Environment: Windows x64

java version 1.7.0_11
Java(TM) SE Runtime Environment (build 1.7.0_11-b21)
Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode)

Reporter: Phil John
Priority: Minor


When running the example config included in the Solr distribution based on the 
instructions here:

http://wiki.apache.org/solr/SolrCloud#Example_A:_Simple_two_shard_cluster

Any requests to pages in the web gui cause a warning log message to be raised 
on Jetty's STDOUT

2013-03-13 19:52:45.827:WARN:oejh.HttpGenerator:Ignoring extra content

followed by the content of the file being served.

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

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

[jira] [Created] (SOLR-2869) IllegalStateException when requesting multiple pages.

2011-11-01 Thread Phil Scadden (Created) (JIRA) 
IllegalStateException when requesting multiple pages. 
--

 Key: SOLR-2869
 URL: https://issues.apache.org/jira/browse/SOLR-2869
 Project: Solr
  Issue Type: Bug
  Components: search
Affects Versions: 3.4
 Environment: Tomcat 5.5.15 on ubuntu linux server, Solr 3.4
Reporter: Phil Scadden
Priority: Minor


IllegalStateException
Seems to happen when I ask for more pages of results, but solr 
essentially stops working. Half an hour later it was working okay. Solr 
3.4 on tomcat 5.5.15
Logs look like: (example of one of many...)
Any ideas very welcome. However, the bug is intermittant. I cant find a way to 
reliably reproduce the problem.

1/11/2011 12:00:14 org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet SolrServer threw exception
java.lang.IllegalStateException
 at 
org.apache.catalina.connector.ResponseFacade.sendError(ResponseFacade.java:404)
 at 
org.apache.solr.servlet.SolrDispatchFilter.sendError(SolrDispatchFilter.java:380)
 at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:283)
 at sun.reflect.GeneratedMethodAccessor101.invoke(Unknown Source)
 at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at 
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:243)
 at java.security.AccessController.doPrivileged(Native Method)
 at javax.security.auth.Subject.doAsPrivileged(Subject.java:517)
 at 
org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:275)
 at 
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:217)
 at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:197)
 at 
org.apache.catalina.core.ApplicationFilterChain.access$000(ApplicationFilterChain.java:50)
 at 
org.apache.catalina.core.ApplicationFilterChain$1.run(ApplicationFilterChain.java:156)
 at java.security.AccessController.doPrivileged(Native Method)
 at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:152)
 at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
 at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
 at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
 at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
 at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541)
 at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
 at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
 at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
 at 
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667)
 at 
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
 at 
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
 at 
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
 at java.lang.Thread.run(Thread.java:619)


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] Created: (SOLR-1993) SolrJ binary update erro when commitWithin is set.

2010-07-08 Thread Phil Bingley (JIRA) 
SolrJ binary update erro when commitWithin is set.
--

 Key: SOLR-1993
 URL: https://issues.apache.org/jira/browse/SOLR-1993
 Project: Solr
  Issue Type: Bug
  Components: clients - java
Affects Versions: 1.4.1, 1.4
Reporter: Phil Bingley
Priority: Minor


Solr server is unable to unmarshall a binary update request where the 
commitWithin property is set on the UpdateRequest class.

The client marshalls the request with the following code
if (updateRequest.getCommitWithin() != -1) {
  params.add(commitWithin, updateRequest.getCommitWithin());
}

The property is an int and when the server unmarshalls, the following error 
happens (can't cast to ListString due to an Integer element)

SEVERE: java.lang.ClassCastException: java.lang.Integer cannot be cast to 
java.util.List
at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.namedListToSolrParams(JavaBinUpdateRequestCodec.java:213)
at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.access$100(JavaBinUpdateRequestCodec.java:40)
at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$2.readOuterMostDocIterator(JavaBinUpdateRequestCodec.java:131)
at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$2.readIterator(JavaBinUpdateRequestCodec.java:126)
at 
org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:210)
at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec$2.readNamedList(JavaBinUpdateRequestCodec.java:112)
at 
org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:175)
at 
org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:101)
at 
org.apache.solr.client.solrj.request.JavaBinUpdateRequestCodec.unmarshal(JavaBinUpdateRequestCodec.java:141)
at 
org.apache.solr.handler.BinaryUpdateRequestHandler.parseAndLoadDocs(BinaryUpdateRequestHandler.java:68)
at 
org.apache.solr.handler.BinaryUpdateRequestHandler.access$000(BinaryUpdateRequestHandler.java:46)
at 
org.apache.solr.handler.BinaryUpdateRequestHandler$1.load(BinaryUpdateRequestHandler.java:55)
at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:54)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1316)
at 
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:338)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:241)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at 
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at 
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at 
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at 
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at 
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:567)
at 
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at 
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at 
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
at 
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at 
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
at java.lang.Thread.run(Thread.java:619)

Workaround is to set the parameter manually as a string value instead of 
setting using the property on the UpdateRequest class.





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


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

Re: Lucene index got corrupted

2006-05-24 Thread Phil W 
Stas Chetvertkov schetvertkov at oilspace.com writes:
 
 Hi All,
 
 We are using lucene for indexing realtime news, and everything was working
 fine until now. I have found that one of our lucene indexes is corrupted,
 all attempts to search in it / optimize it or merge it to another index
 results in 'read past EOF' exception.
 
 My investigation showed that one of segments in index seems invalid. Its
 field index file, '_4lvd.fdx', has length equal to 24 bytes, while all field
 normalization factor files (_4lvd.f?) are 2 bytes long. Since number of
 documents is determined as length('_4lvd.fdx')/8, lucene tries to read 3rd
 byte from normalization factor files and fails.
 
 Does anyone have any ideas how this index corruption could occur and how I
 can fix it? Any advise would be extremely helpful.

Did you ever get anywhere with this? We seem to be having issues with some
character data causing corruptions in a similar manner (we haven't tracked it
down or verified which characters cause this, though a tab character might be
one of the offendees).



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]