[jira] [Commented] (SOLR-5590) SolrJ is still on httpcomponents/httpclient version 4.2.x, which has some problems

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-5590:
---

Commit 1555022 from [~elyograg] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1555022 ]

SOLR-5590: Upgrade HttpClient/HttpComponents to 4.3.x. (merge trunk r1555004)

> SolrJ is still on httpcomponents/httpclient version 4.2.x, which has some 
> problems
> --
>
> Key: SOLR-5590
> URL: https://issues.apache.org/jira/browse/SOLR-5590
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 4.5.1
>Reporter: Karl Wright
>Assignee: Shawn Heisey
> Attachments: SOLR-5590.patch
>
>
> SolrJ depends on HttpClient 4.2.x right now, but HttpClient 4.2.x has issues 
> that the ManifoldCF team encountered with handling of form data encoding - 
> issues which are addressed in HttpClient 4.3.x.  We developed a local patch, 
> but Solr will eventually need to go to the new client.  (ManifoldCF would 
> plan to follow shortly thereafter).
> I tried to get Oleg (PMC chair of HttpComponents) to agree to port the fixed 
> code to the 4.2.x stream but he did not want to do that.  So I believe that 
> that avenue is closed.
> See CONNECTORS-623 for a detailed description of the problem.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5590) SolrJ is still on httpcomponents/httpclient version 4.2.x, which has some problems

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-5590:


It only took a couple of test runs on trunk to get the tests to pass, but I had 
to run it a bunch of times on branch_4x.  It was a semi-repeatable failure that 
you can see with the following commandline (tested on Linux):

ant test Dtestcase=CollectionsAPIDistributedZkTest 
-Dtests.method=testDistribSearch

The same failure happens on a clean 4x checkout with similar frequency, so I 
don't think this change has caused any new problems.  The precommit passed on 
the first try.  I'll go ahead and commit.


> SolrJ is still on httpcomponents/httpclient version 4.2.x, which has some 
> problems
> --
>
> Key: SOLR-5590
> URL: https://issues.apache.org/jira/browse/SOLR-5590
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 4.5.1
>Reporter: Karl Wright
>Assignee: Shawn Heisey
> Attachments: SOLR-5590.patch
>
>
> SolrJ depends on HttpClient 4.2.x right now, but HttpClient 4.2.x has issues 
> that the ManifoldCF team encountered with handling of form data encoding - 
> issues which are addressed in HttpClient 4.3.x.  We developed a local patch, 
> but Solr will eventually need to go to the new client.  (ManifoldCF would 
> plan to follow shortly thereafter).
> I tried to get Oleg (PMC chair of HttpComponents) to agree to port the fixed 
> code to the 4.2.x stream but he did not want to do that.  So I believe that 
> that avenue is closed.
> See CONNECTORS-623 for a detailed description of the problem.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[JENKINS] Lucene-Solr-4.x-MacOSX (64bit/jdk1.7.0) - Build # 1156 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/1156/
Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseParallelGC

All tests passed

Build Log:
[...truncated 10523 lines...]
   [junit4] JVM J0: stderr was not empty, see: 
/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-core/test/temp/junit4-J0-20140103_050744_652.syserr
   [junit4] >>> JVM J0: stderr (verbatim) 
   [junit4] java(609,0x13bd7a000) malloc: *** error for object 0x13bd69108: 
pointer being freed was not allocated
   [junit4] *** set a breakpoint in malloc_error_break to debug
   [junit4] <<< JVM J0: EOF 

[...truncated 1 lines...]
   [junit4] ERROR: JVM J0 ended with an exception, command line: 
/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/bin/java 
-XX:-UseCompressedOops -XX:+UseParallelGC -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/heapdumps 
-Dtests.prefix=tests -Dtests.seed=99CFD837754F6EF4 -Xmx512M -Dtests.iters= 
-Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random 
-Dtests.postingsformat=random -Dtests.docvaluesformat=random 
-Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random 
-Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=4.7 
-Dtests.cleanthreads=perClass 
-Djava.util.logging.config.file=/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/tools/junit4/logging.properties
 -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true 
-Dtests.asserts.gracious=false -Dtests.multiplier=1 -DtempDir=. 
-Djava.io.tmpdir=. 
-Djunit4.tempDir=/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-core/test/temp
 
-Dclover.db.dir=/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/clover/db
 -Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Djava.security.policy=/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/tools/junit4/tests.policy
 -Dlucene.version=4.7-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 
-Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
-Djava.awt.headless=true -Djdk.map.althashing.threshold=0 
-Dtests.disableHdfs=true -Dfile.encoding=UTF-8 -classpath 
/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-core/classes/test:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-test-framework/classes/java:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/solr/test-framework/lib/junit4-ant-2.0.13.jar:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-core/test-files:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/test-framework/classes/java:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/codecs/classes/java:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-solrj/classes/java:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-core/classes/java:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/analysis/common/lucene-analyzers-common-4.7-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/analysis/kuromoji/lucene-analyzers-kuromoji-4.7-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/analysis/phonetic/lucene-analyzers-phonetic-4.7-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/codecs/lucene-codecs-4.7-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/highlighter/lucene-highlighter-4.7-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/memory/lucene-memory-4.7-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/misc/lucene-misc-4.7-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/spatial/lucene-spatial-4.7-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/expressions/lucene-expressions-4.7-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/suggest/lucene-suggest-4.7-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/grouping/lucene-grouping-4.7-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/queries/lucene-queries-4.7-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/queryparser/lucene-queryparser-4.7-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/join/lucene-join-4.7-SNAPSHOT.jar:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/solr/core/lib/antlr-runtime-3.5.jar:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/solr/core/lib/asm-4.1.jar:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/solr/core/lib/asm-commons-4.1.jar:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/solr/core/lib/commons-cli-1.2.jar:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/solr/core/lib/commons-codec-1.7.jar:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/solr/core/lib/commons-configuration-1.6.jar:/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/solr/core/lib/commons-fileupload-1.2.1.jar:/Users/jenkins/workspace/Lucene-Solr-4

[jira] [Commented] (SOLR-5601) NPE in OverseerCollectionProcessor.migrateKey - inconsistent failure from MigrateRouteKeyTest

[Anshum Gupta (JIRA)]

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

Anshum Gupta commented on SOLR-5601:


I tried running the test 50 times over but didn't yet run into it.

Looks like it had issues at one of the 2 spots considering that it never seemed 
to have asked the source leader to split the index:
# While constructing the WaitForState call i.e. waiting for the replicas to be 
seen as active on temp source leader (More likely as I couldn't spot any logs 
from there)
# During the above mentioned WaitForState call.



> NPE in OverseerCollectionProcessor.migrateKey - inconsistent failure from 
> MigrateRouteKeyTest
> -
>
> Key: SOLR-5601
> URL: https://issues.apache.org/jira/browse/SOLR-5601
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> Encountered a weird _semi-reproducible_ failure from MigrateRouteKeyTest 
> {code}
> ant test  -Dtestcase=MigrateRouteKeyTest -Dtests.method=testDistribSearch 
> -Dtests.seed=26F9FF92782251B6 -Dtests.slow=true -Dtests.locale=sr_CS 
> -Dtests.timezone=Europe/Zaporozhye -Dtests.file.encoding=UTF-8
> {code}
> Attempting to reproduce with that line caused failures the first 2 times i 
> tried, and then succeeded every time after that.
> Details of failure to follow in comment.
> (NOTE: this may be related to some recent jenkins failures due to thread 
> leaks from this test)



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5590) SolrJ is still on httpcomponents/httpclient version 4.2.x, which has some problems

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on SOLR-5590:
---

Commit 1555004 from [~elyograg] in branch 'dev/trunk'
[ https://svn.apache.org/r1555004 ]

SOLR-5590: Upgrade HttpClient/HttpComponents to 4.3.x.

> SolrJ is still on httpcomponents/httpclient version 4.2.x, which has some 
> problems
> --
>
> Key: SOLR-5590
> URL: https://issues.apache.org/jira/browse/SOLR-5590
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 4.5.1
>Reporter: Karl Wright
>Assignee: Shawn Heisey
> Attachments: SOLR-5590.patch
>
>
> SolrJ depends on HttpClient 4.2.x right now, but HttpClient 4.2.x has issues 
> that the ManifoldCF team encountered with handling of form data encoding - 
> issues which are addressed in HttpClient 4.3.x.  We developed a local patch, 
> but Solr will eventually need to go to the new client.  (ManifoldCF would 
> plan to follow shortly thereafter).
> I tried to get Oleg (PMC chair of HttpComponents) to agree to port the fixed 
> code to the 4.2.x stream but he did not want to do that.  So I believe that 
> that avenue is closed.
> See CONNECTORS-623 for a detailed description of the problem.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5590) SolrJ is still on httpcomponents/httpclient version 4.2.x, which has some problems

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-5590:


Tests and precommit passed on trunk.  Committing there.  Will merge to 4x and 
verify.


> SolrJ is still on httpcomponents/httpclient version 4.2.x, which has some 
> problems
> --
>
> Key: SOLR-5590
> URL: https://issues.apache.org/jira/browse/SOLR-5590
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 4.5.1
>Reporter: Karl Wright
>Assignee: Shawn Heisey
> Attachments: SOLR-5590.patch
>
>
> SolrJ depends on HttpClient 4.2.x right now, but HttpClient 4.2.x has issues 
> that the ManifoldCF team encountered with handling of form data encoding - 
> issues which are addressed in HttpClient 4.3.x.  We developed a local patch, 
> but Solr will eventually need to go to the new client.  (ManifoldCF would 
> plan to follow shortly thereafter).
> I tried to get Oleg (PMC chair of HttpComponents) to agree to port the fixed 
> code to the 4.2.x stream but he did not want to do that.  So I believe that 
> that avenue is closed.
> See CONNECTORS-623 for a detailed description of the problem.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

Re: The Old Git Discussion

[Robert Muir]

It happens with 1.8 too. I'm not really concerned what the technical
explanation is (i'm sure someone will say: you are holding it wrong).

one of the most important things about version control is being able
to track changes. if 'status' tells me my working directory is clean,
but then 'push' does something, that tells me its not ready for prime
time :)

step 1: make a commit to branch A

rmuir@beast:~/bogus$ git checkout master
Switched to branch 'master'
rmuir@beast:~/bogus$ ls
foo
rmuir@beast:~/bogus$ touch bar
rmuir@beast:~/bogus$ git add bar
rmuir@beast:~/bogus$ git commit -m "blahblah"
[master 1463733] blahblah
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 bar
rmuir@beast:~/bogus$ git push origin master
Counting objects: 3, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 241 bytes | 0 bytes/s, done.
Total 2 (delta 0), reused 0 (delta 0)
To g...@github.com:rmuir/bogus.git
   9f54f3b..1463733  master -> master


step 2: merge to branch B
rmuir@beast:~/bogus$ git checkout feature
Switched to branch 'feature'
rmuir@beast:~/bogus$ git merge master
Updating 9f54f3b..1463733
Fast-forward
 bar | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 bar
rmuir@beast:~/bogus$ git status
# On branch feature
nothing to commit, working directory clean

^^^ see that shit? it says the words 'working directory clean' but it lies.

rmuir@beast:~/bogus$ git push origin feature
Total 0 (delta 0), reused 0 (delta 0)
To g...@github.com:rmuir/bogus.git
   9f54f3b..1463733  feature -> feature
rmuir@beast:~/bogus$ git --version
git version 1.8.3.2


On Thu, Jan 2, 2014 at 9:09 PM, Benson Margulies  wrote:
> On Thu, Jan 2, 2014 at 7:22 PM, Robert Muir  wrote:
>> is 1.7.10.2 considered old? It still happens to me with that. I use
>> git at work every day.
>
> i honestly wouldn't have called that ancient, but I can't recall when
> I used a version before 1.8.
>
> i have no quick answer to the phenomenon that afflicts you. Feel free
> to ping me off-list on the off chance that I can think of something
> useful by asking you 20 questions that the rest of this list doesn't
> want to read.
>
>>
>> I think there are two reasons why i see this:
>> 1) I always like to run 'svn status' (actually followed by svn diff,
>> too), before committing as a final review to make sure i'm changing
>> what i'm thinking i'm changing. I must be able to do this with git
>> too.
>>
>> 2) After a merge, I like to run tests to ensure I won't actually break
>> things. I do this with svn too (e.g. run all tests after merge
>> --reintegrate). Tests can take some time. The phone might ring, i
>> might have to walk the dog, i might go get a beer. When i come back,
>> god forbid I run step 1 again to see what my current state is, or
>> re-run tests too.
>>
>>
>> On Thu, Jan 2, 2014 at 7:04 PM, Benson Margulies  
>> wrote:
>>> I've never seen anything like this with any modern version of git. We
>>> use it at work, we have many branches.
>>>
>>> On Thu, Jan 2, 2014 at 6:46 PM, Robert Muir  wrote:
 My final biggest complaint with git is the bugginess of 'git status'. After
 operations like merging (which can get complex), it will lie to you and 
 tell
 you your checkout is clean, when in fact its not: if you then type git push
 it will push lots of commits. This is a real problem if you work on many
 repositories, it means you must fall back to using patches and such
 anyway... Aka... Git does not really work

 On Jan 2, 2014 3:52 PM, "Mark Miller"  wrote:
>
> bzr is dying; Emacs needs to move
>
>
> http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg5.html
>
> Interesting thread.
>
> For similar reasons, I think that Lucene and Solr should eventually move
> to Git. It's not GitHub, but it's a lot closer. The new Apache projects I
> see are all choosing Git. It's the winners road I think. I don't know that
> there is a big hurry right now, but I think it's inevitable that we should
> switch.
>
> --
> - Mark
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>
> -
> 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: The Old Git Discussion

[Benson Margulies]

On Thu, Jan 2, 2014 at 7:22 PM, Robert Muir  wrote:
> is 1.7.10.2 considered old? It still happens to me with that. I use
> git at work every day.

i honestly wouldn't have called that ancient, but I can't recall when
I used a version before 1.8.

i have no quick answer to the phenomenon that afflicts you. Feel free
to ping me off-list on the off chance that I can think of something
useful by asking you 20 questions that the rest of this list doesn't
want to read.

>
> I think there are two reasons why i see this:
> 1) I always like to run 'svn status' (actually followed by svn diff,
> too), before committing as a final review to make sure i'm changing
> what i'm thinking i'm changing. I must be able to do this with git
> too.
>
> 2) After a merge, I like to run tests to ensure I won't actually break
> things. I do this with svn too (e.g. run all tests after merge
> --reintegrate). Tests can take some time. The phone might ring, i
> might have to walk the dog, i might go get a beer. When i come back,
> god forbid I run step 1 again to see what my current state is, or
> re-run tests too.
>
>
> On Thu, Jan 2, 2014 at 7:04 PM, Benson Margulies  
> wrote:
>> I've never seen anything like this with any modern version of git. We
>> use it at work, we have many branches.
>>
>> On Thu, Jan 2, 2014 at 6:46 PM, Robert Muir  wrote:
>>> My final biggest complaint with git is the bugginess of 'git status'. After
>>> operations like merging (which can get complex), it will lie to you and tell
>>> you your checkout is clean, when in fact its not: if you then type git push
>>> it will push lots of commits. This is a real problem if you work on many
>>> repositories, it means you must fall back to using patches and such
>>> anyway... Aka... Git does not really work
>>>
>>> On Jan 2, 2014 3:52 PM, "Mark Miller"  wrote:

 bzr is dying; Emacs needs to move


 http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg5.html

 Interesting thread.

 For similar reasons, I think that Lucene and Solr should eventually move
 to Git. It's not GitHub, but it's a lot closer. The new Apache projects I
 see are all choosing Git. It's the winners road I think. I don't know that
 there is a big hurry right now, but I think it's inevitable that we should
 switch.

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

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

[jira] [Commented] (SOLR-5602) Solr DIH shows in-consistent status

[Liu Xiang (JIRA)]

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

Liu Xiang commented on SOLR-5602:
-

some investigation from myself.
The status from DIH is decided by DataImporter.importLock which is a 
ReentrantLock.
In the log, the last record is "Time taken = xxx" which occurs at end of 
DocBuilder.execute()
After that, at the end of DataImporter.runCmd(RequestInfo reqParams, SolrWriter 
sw), importLock is unlock in finally block.
I don't see any reason that statement is not executed.
Could it be ReentrantLock can not release lock immediately for some reason?

Hope it helps to bootstrap.

> Solr DIH shows in-consistent status
> ---
>
> Key: SOLR-5602
> URL: https://issues.apache.org/jira/browse/SOLR-5602
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - DataImportHandler
>Affects Versions: 4.2
>Reporter: Liu Xiang
>
> I have one DIH index job which takes about 4 hr to finish.
> The job was launched at 11:28 am and completed at 15:10 pm.
> However, in DIH response, although "statusMessages" showed correct 
> information, "status" kept showing "busy" until 16:40 pm.
> After that, it became "idle". 
> This index job is one step of our data pipeline, we are using both "status" 
> and statusMessages" to decide should the job move to next step, I would like 
> to know the reason causing the in-consistent status.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Created] (SOLR-5602) Solr DIH shows in-consistent status

[Liu Xiang (JIRA)]

Liu Xiang created SOLR-5602:
---

 Summary: Solr DIH shows in-consistent status
 Key: SOLR-5602
 URL: https://issues.apache.org/jira/browse/SOLR-5602
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler
Affects Versions: 4.2
Reporter: Liu Xiang


I have one DIH index job which takes about 4 hr to finish.
The job was launched at 11:28 am and completed at 15:10 pm.
However, in DIH response, although "statusMessages" showed correct information, 
"status" kept showing "busy" until 16:40 pm.
After that, it became "idle". 

This index job is one step of our data pipeline, we are using both "status" and 
statusMessages" to decide should the job move to next step, I would like to 
know the reason causing the in-consistent status.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.7.0_45) - Build # 3633 - Still Failing!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/3633/
Java: 64bit/jdk1.7.0_45 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.core.TestSolrDeletionPolicy2

Error Message:
Suite timeout exceeded (>= 720 msec).

Stack Trace:
java.lang.Exception: Suite timeout exceeded (>= 720 msec).
at __randomizedtesting.SeedInfo.seed([912397CD528AFEA9]:0)




Build Log:
[...truncated 10415 lines...]
   [junit4] Suite: org.apache.solr.core.TestSolrDeletionPolicy2
   [junit4]   2> 1144295 T4005 oas.SolrTestCaseJ4.initCore initCore
   [junit4]   2> Creating dataDir: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test\J0\.\solrtest-TestSolrDeletionPolicy2-1388700732563
   [junit4]   2> 1144299 T4005 oasc.SolrResourceLoader. new 
SolrResourceLoader for directory: 
'C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test-files\solr\collection1\'
   [junit4]   2> 1144299 T4005 oasc.SolrResourceLoader.replaceClassLoader 
Adding 
'file:/C:/Users/JenkinsSlave/workspace/Lucene-Solr-trunk-Windows/solr/build/solr-core/test-files/solr/collection1/lib/classes/'
 to classloader
   [junit4]   2> 1144299 T4005 oasc.SolrResourceLoader.replaceClassLoader 
Adding 
'file:/C:/Users/JenkinsSlave/workspace/Lucene-Solr-trunk-Windows/solr/build/solr-core/test-files/solr/collection1/lib/README'
 to classloader
   [junit4]   2> 1144402 T4005 oasc.SolrConfig. Using Lucene 
MatchVersion: LUCENE_50
   [junit4]   2> 1144472 T4005 oasc.SolrConfig. Loaded SolrConfig: 
solrconfig-delpolicy2.xml
   [junit4]   2> 1144473 T4005 oass.IndexSchema.readSchema Reading Solr Schema 
from schema.xml
   [junit4]   2> 1144483 T4005 oass.IndexSchema.readSchema [null] Schema 
name=test
   [junit4]   2> 1145195 T4005 oass.OpenExchangeRatesOrgProvider.init 
Initialized with rates=open-exchange-rates.json, refreshInterval=1440.
   [junit4]   2> 1145205 T4005 oass.IndexSchema.readSchema default search field 
in schema is text
   [junit4]   2> 1145209 T4005 oass.IndexSchema.readSchema unique key field: id
   [junit4]   2> 1145217 T4005 oass.FileExchangeRateProvider.reload Reloading 
exchange rates from file currency.xml
   [junit4]   2> 1145224 T4005 oass.FileExchangeRateProvider.reload Reloading 
exchange rates from file currency.xml
   [junit4]   2> 1145228 T4005 oass.OpenExchangeRatesOrgProvider.reload 
Reloading exchange rates from open-exchange-rates.json
   [junit4]   2> 1145228 T4005 
oass.OpenExchangeRatesOrgProvider$OpenExchangeRates. WARN Unknown key 
IMPORTANT NOTE
   [junit4]   2> 1145231 T4005 
oass.OpenExchangeRatesOrgProvider$OpenExchangeRates. WARN Expected key, 
got STRING
   [junit4]   2> 1145231 T4005 oass.OpenExchangeRatesOrgProvider.reload 
Reloading exchange rates from open-exchange-rates.json
   [junit4]   2> 1145232 T4005 
oass.OpenExchangeRatesOrgProvider$OpenExchangeRates. WARN Unknown key 
IMPORTANT NOTE
   [junit4]   2> 1145233 T4005 
oass.OpenExchangeRatesOrgProvider$OpenExchangeRates. WARN Expected key, 
got STRING
   [junit4]   2> 1145233 T4005 oasc.SolrResourceLoader.locateSolrHome JNDI not 
configured for solr (NoInitialContextEx)
   [junit4]   2> 1145233 T4005 oasc.SolrResourceLoader.locateSolrHome using 
system property solr.solr.home: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test-files\solr
   [junit4]   2> 1145234 T4005 oasc.SolrResourceLoader. new 
SolrResourceLoader for directory: 
'C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test-files\solr\'
   [junit4]   2> 1145258 T4005 oasc.SolrResourceLoader.locateSolrHome JNDI not 
configured for solr (NoInitialContextEx)
   [junit4]   2> 1145258 T4005 oasc.SolrResourceLoader.locateSolrHome using 
system property solr.solr.home: 
C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test-files\solr
   [junit4]   2> 1145259 T4005 oasc.SolrResourceLoader. new 
SolrResourceLoader for deduced Solr Home: 
'C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test-files\solr\'
   [junit4]   2> 1145360 T4005 oasc.CoreContainer. New CoreContainer 
1441072813
   [junit4]   2> 1145362 T4005 oasc.CoreContainer.load Loading cores into 
CoreContainer 
[instanceDir=C:\Users\JenkinsSlave\workspace\Lucene-Solr-trunk-Windows\solr\build\solr-core\test-files\solr\]
   [junit4]   2> 1145363 T4005 oashc.HttpShardHandlerFactory.getParameter 
Setting socketTimeout to: 0
   [junit4]   2> 1145363 T4005 oashc.HttpShardHandlerFactory.getParameter 
Setting urlScheme to: http://
   [junit4]   2> 1145363 T4005 oashc.HttpShardHandlerFactory.getParameter 
Setting connTimeout to: 0
   [junit4]   2> 1145363 T4005 oashc.HttpShardHandlerFactory.getParameter 
Setting maxConnectionsPerHost to: 20
   [junit4]   2> 1145363 T4005 oashc.HttpShardHandlerFactory.getParameter 
Setting corePoolSize to: 0
   [junit4]   2> 1145364 T4005 oashc.HttpShardHandlerFact

[jira] [Updated] (SOLR-5463) Provide cursor/token based "searchAfter" support that works with arbitrary sorting (ie: "deep paging")

[Hoss Man (JIRA)]

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

Hoss Man updated SOLR-5463:
---

Attachment: SOLR-5463.patch

Improvements in this patch...

 * Moved cursor param constants to .commons.params.CursorMarkParams
 * Added QueryResponse.getNextCursorMark
 * switch cloud tests to use QueryResponse.getNextCursorMark
 * fixed a small ordering inconsistency between the single core response and 
the cloud response 
 * fix TestCursorMarkWithoutUniqueKey's lifecycle so it plays nicely with 
multiple run
 * add a custom sorting field type into the tests, leveraging sarowe's work in 
SOLR-5354


> Provide cursor/token based "searchAfter" support that works with arbitrary 
> sorting (ie: "deep paging")
> --
>
> Key: SOLR-5463
> URL: https://issues.apache.org/jira/browse/SOLR-5463
> Project: Solr
>  Issue Type: New Feature
>Reporter: Hoss Man
>Assignee: Hoss Man
> Attachments: SOLR-5463.patch, SOLR-5463.patch, SOLR-5463.patch, 
> SOLR-5463.patch, SOLR-5463.patch, SOLR-5463.patch, 
> SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch, 
> SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch, 
> SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch, 
> SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch, 
> SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch, 
> SOLR-5463__straw_man__MissingStringLastComparatorSource.patch
>
>
> I'd like to revist a solution to the problem of "deep paging" in Solr, 
> leveraging an HTTP based API similar to how IndexSearcher.searchAfter works 
> at the lucene level: require the clients to provide back a token indicating 
> the sort values of the last document seen on the previous "page".  This is 
> similar to the "cursor" model I've seen in several other REST APIs that 
> support "pagnation" over a large sets of results (notable the twitter API and 
> it's "since_id" param) except that we'll want something that works with 
> arbitrary multi-level sort critera that can be either ascending or descending.
> SOLR-1726 laid some initial ground work here and was commited quite a while 
> ago, but the key bit of argument parsing to leverage it was commented out due 
> to some problems (see comments in that issue).  It's also somewhat out of 
> date at this point: at the time it was commited, IndexSearcher only supported 
> searchAfter for simple scores, not arbitrary field sorts; and the params 
> added in SOLR-1726 suffer from this limitation as well.
> ---
> I think it would make sense to start fresh with a new issue with a focus on 
> ensuring that we have deep paging which:
> * supports arbitrary field sorts in addition to sorting by score
> * works in distributed mode



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

Re: The Old Git Discussion

[Robert Muir]

is 1.7.10.2 considered old? It still happens to me with that. I use
git at work every day.

I think there are two reasons why i see this:
1) I always like to run 'svn status' (actually followed by svn diff,
too), before committing as a final review to make sure i'm changing
what i'm thinking i'm changing. I must be able to do this with git
too.

2) After a merge, I like to run tests to ensure I won't actually break
things. I do this with svn too (e.g. run all tests after merge
--reintegrate). Tests can take some time. The phone might ring, i
might have to walk the dog, i might go get a beer. When i come back,
god forbid I run step 1 again to see what my current state is, or
re-run tests too.


On Thu, Jan 2, 2014 at 7:04 PM, Benson Margulies  wrote:
> I've never seen anything like this with any modern version of git. We
> use it at work, we have many branches.
>
> On Thu, Jan 2, 2014 at 6:46 PM, Robert Muir  wrote:
>> My final biggest complaint with git is the bugginess of 'git status'. After
>> operations like merging (which can get complex), it will lie to you and tell
>> you your checkout is clean, when in fact its not: if you then type git push
>> it will push lots of commits. This is a real problem if you work on many
>> repositories, it means you must fall back to using patches and such
>> anyway... Aka... Git does not really work
>>
>> On Jan 2, 2014 3:52 PM, "Mark Miller"  wrote:
>>>
>>> bzr is dying; Emacs needs to move
>>>
>>>
>>> http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg5.html
>>>
>>> Interesting thread.
>>>
>>> For similar reasons, I think that Lucene and Solr should eventually move
>>> to Git. It's not GitHub, but it's a lot closer. The new Apache projects I
>>> see are all choosing Git. It's the winners road I think. I don't know that
>>> there is a big hurry right now, but I think it's inevitable that we should
>>> switch.
>>>
>>> --
>>> - Mark
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

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

Re: The Old Git Discussion

[Benson Margulies]

I've never seen anything like this with any modern version of git. We
use it at work, we have many branches.

On Thu, Jan 2, 2014 at 6:46 PM, Robert Muir  wrote:
> My final biggest complaint with git is the bugginess of 'git status'. After
> operations like merging (which can get complex), it will lie to you and tell
> you your checkout is clean, when in fact its not: if you then type git push
> it will push lots of commits. This is a real problem if you work on many
> repositories, it means you must fall back to using patches and such
> anyway... Aka... Git does not really work
>
> On Jan 2, 2014 3:52 PM, "Mark Miller"  wrote:
>>
>> bzr is dying; Emacs needs to move
>>
>>
>> http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg5.html
>>
>> Interesting thread.
>>
>> For similar reasons, I think that Lucene and Solr should eventually move
>> to Git. It's not GitHub, but it's a lot closer. The new Apache projects I
>> see are all choosing Git. It's the winners road I think. I don't know that
>> there is a big hurry right now, but I think it's inevitable that we should
>> switch.
>>
>> --
>> - Mark

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

Re: The Old Git Discussion

[Wolfgang Hoschek]

+1

On Jan 2, 2014, at 10:53 PM, Simon Willnauer wrote:

> +1
> 
> On Thu, Jan 2, 2014 at 9:51 PM, Mark Miller  wrote:
>> bzr is dying; Emacs needs to move
>> 
>> 
>> http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg5.html
>> 
>> Interesting thread.
>> 
>> For similar reasons, I think that Lucene and Solr should eventually move to
>> Git. It's not GitHub, but it's a lot closer. The new Apache projects I see
>> are all choosing Git. It's the winners road I think. I don't know that there
>> is a big hurry right now, but I think it's inevitable that we should switch.
>> 
>> --
>> - Mark
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

[jira] [Created] (SOLR-5601) NPE in OverseerCollectionProcessor.migrateKey - inconsistent failure from MigrateRouteKeyTest

[Hoss Man (JIRA)]

Hoss Man created SOLR-5601:
--

 Summary: NPE in OverseerCollectionProcessor.migrateKey - 
inconsistent failure from MigrateRouteKeyTest
 Key: SOLR-5601
 URL: https://issues.apache.org/jira/browse/SOLR-5601
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man


Encountered a weird _semi-reproducible_ failure from MigrateRouteKeyTest 

{code}
ant test  -Dtestcase=MigrateRouteKeyTest -Dtests.method=testDistribSearch 
-Dtests.seed=26F9FF92782251B6 -Dtests.slow=true -Dtests.locale=sr_CS 
-Dtests.timezone=Europe/Zaporozhye -Dtests.file.encoding=UTF-8
{code}

Attempting to reproduce with that line caused failures the first 2 times i 
tried, and then succeeded every time after that.

Details of failure to follow in comment.

(NOTE: this may be related to some recent jenkins failures due to thread leaks 
from this test)




--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5601) NPE in OverseerCollectionProcessor.migrateKey - inconsistent failure from MigrateRouteKeyTest

[Hoss Man (JIRA)]

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

Hoss Man commented on SOLR-5601:


The initial start of trouble seened to me an NPE in 
OverseerCollectionProcessor.migrateKey...

{noformat}
   [junit4]   2> 324502 T1186 oasc.ZkController.checkRecovery I am the leader, 
no recovery necessary
   [junit4]   2> 324502 T1186 oasc.ZkController.publish publishing 
core=split_shard2_temp_shard1_shard1_replica1 state=active
   [junit4]   2> 324514 T1228 C220 P42114 oasup.LogUpdateProcessor.finish 
[collection1] webapp=/tr_/xq path=/update 
params={distrib.from=http://127.0.0.1:47570/tr_/xq/collection1/&version=2&wt=javabin&update.distrib=FROMLEADER}
 {add=[m/1!116 (1456162963872284672)]} 0 0
   [junit4]   2> 324515 T1189 C221 P47570 oasup.LogUpdateProcessor.finish 
[collection1] webapp=/tr_/xq path=/update params={version=2&wt=javabin} 
{add=[m/1!116 (1456162963872284672)]} 0 3
   [junit4]   2> 324526 T1186 oascc.ZkStateReader.updateClusterState Updating 
cloud state from ZooKeeper... 
   [junit4]   2> 324527 T1186 oasc.SolrXMLCoresLocator.doPersist Persisted core 
descriptions to 
/home/hossman/lucene/dev/solr/build/solr-core/test/J2/../../../../../../../../../home/hossman/lucene/dev/solr/build/solr-core/test/J2/./org.apache.solr.cloud.MigrateRouteKeyTest-jetty1-1388705195623/solr.xml
   [junit4]   2> 324527 T1186 oass.SolrDispatchFilter.handleAdminRequest 
[admin] webapp=null path=/admin/cores 
params={numShards=1&collection.configName=conf1&version=2&wt=javabin&name=split_shard2_temp_shard1_shard1_replica1&shard=shard1&collection=split_shard2_temp_shard1&qt=/admin/cores&action=CREATE}
 status=0 QTime=1656 
   [junit4]   2> 324528 T1174 oasc.OverseerCollectionProcessor.createCollection 
Finished create command on all shards for collection: split_shard2_temp_shard1
   [junit4]   2> 324528 T1174 oasc.OverseerCollectionProcessor.migrateKey 
Asking source leader to wait for: split_shard2_temp_shard1_shard1_replica1 to 
be alive on: 127.0.0.1:47570_tr_%2Fxq
   [junit4]   2> 324528 T1174 oasc.SolrException.log ERROR Collection migrate 
of migrate failed:java.lang.NullPointerException
   [junit4]   2>at 
org.apache.solr.cloud.OverseerCollectionProcessor.migrateKey(OverseerCollectionProcessor.java:1208)
   [junit4]   2>at 
org.apache.solr.cloud.OverseerCollectionProcessor.migrate(OverseerCollectionProcessor.java:1102)
   [junit4]   2>at 
org.apache.solr.cloud.OverseerCollectionProcessor.processMessage(OverseerCollectionProcessor.java:252)
   [junit4]   2>at 
org.apache.solr.cloud.OverseerCollectionProcessor.run(OverseerCollectionProcessor.java:176)
   [junit4]   2>at java.lang.Thread.run(Thread.java:724)
   [junit4]   2>
   [junit4]   2> 324551 T1217 oasc.DistributedQueue$LatchChildWatcher.process 
LatchChildWatcher fired on path: /overseer/collection-queue-work/qnr-02 
state: SyncConnected type NodeDataChanged
   [junit4]   2> 324552 T1172 oasc.DistributedQueue$LatchChildWatcher.process 
LatchChildWatcher fired on path: /overseer/queue state: SyncConnected type 
NodeChildrenChanged
   [junit4]   2> 324552 T1172 oasc.DistributedQueue$LatchChildWatcher.process 
LatchChildWatcher fired on path: /overseer/queue state: SyncConnected type 
NodeChildrenChanged
   [junit4]   2> 324559 T1172 oasc.DistributedQueue$LatchChildWatcher.process 
LatchChildWatcher fired on path: /overseer/collection-queue-work state: 
SyncConnected type NodeChildrenChanged
   [junit4]   2> 324559 T1174 oasc.OverseerCollectionProcessor.run Overseer 
Collection Processor: Message id:/overseer/collection-queue-work/qn-02 
complete, 
response:{success={null={responseHeader={status=0,QTime=0},core=migrate_multipleshardtest_targetCollection_shard1_replica1,status=BUFFERING},null={responseHeader={status=0,QTime=1656},core=split_shard2_temp_shard1_shard1_replica1}},Operation
 migrate caused 
exception:=java.lang.NullPointerException,exception={msg=null,rspCode=-1}}
   [junit4]   2> 324568 T1173 oascc.ZkStateReader.updateClusterState Updating 
cloud state from ZooKeeper... 
   [junit4]   2> 324569 T1173 oasc.Overseer$ClusterStateUpdater.updateState 
Update state numShards=1 message={
   [junit4]   2>  "operation":"state",
   [junit4]   2>  "state":"active",
   [junit4]   2>  "base_url":"http://127.0.0.1:47570/tr_/xq";,
   [junit4]   2>  "core":"split_shard2_temp_shard1_shard1_replica1",
   [junit4]   2>  "roles":null,
   [junit4]   2>  "node_name":"127.0.0.1:47570_tr_%2Fxq",
   [junit4]   2>  "shard":"shard1",
   [junit4]   2>  "shard_range":null,
   [junit4]   2>  "shard_state":"active",
   [junit4]   2>  "shard_parent":null,
   [junit4]   2>  "collection":"split_shard2_temp_shard1",
   [junit4]   2>  "numSha

Re: The Old Git Discussion

[Robert Muir]

My final biggest complaint with git is the bugginess of 'git status'. After
operations like merging (which can get complex), it will lie to you and
tell you your checkout is clean, when in fact its not: if you then type git
push it will push lots of commits. This is a real problem if you work on
many repositories, it means you must fall back to using patches and such
anyway... Aka... Git does not really work
On Jan 2, 2014 3:52 PM, "Mark Miller"  wrote:

> bzr is dying; Emacs needs to move
>
> http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg5.html
>
> Interesting thread.
>
> For similar reasons, I think that Lucene and Solr should eventually move
> to Git. It's not GitHub, but it's a lot closer. The new Apache projects I
> see are all choosing Git. It's the winners road I think. I don't know that
> there is a big hurry right now, but I think it's inevitable that we should
> switch.
>
> --
> - Mark
>

Re: The Old Git Discussion

[Robert Muir]

Also its pretty depressing that git doesn't have revision numbers like svn
and hg. I thought I heard they were going to fix this... Does anyone know?
These are incredibly useful.
On Jan 2, 2014 3:52 PM, "Mark Miller"  wrote:

> bzr is dying; Emacs needs to move
>
> http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg5.html
>
> Interesting thread.
>
> For similar reasons, I think that Lucene and Solr should eventually move
> to Git. It's not GitHub, but it's a lot closer. The new Apache projects I
> see are all choosing Git. It's the winners road I think. I don't know that
> there is a big hurry right now, but I think it's inevitable that we should
> switch.
>
> --
> - Mark
>

Re: The Old Git Discussion

[Robert Muir]

It's hard to say +1 without all the details. If we want to dropin git for
svn, then what existing stuff breaks? For example, I think its pretty
important that commit notifications work correctly, so people can see what
changed. If they break because someone caused a fastforward, that's no
good. And asking devs to use obscure options like -no-ff will work about as
well as asking customers to rewind VHS tapes.
On Jan 2, 2014 3:52 PM, "Mark Miller"  wrote:

> bzr is dying; Emacs needs to move
>
> http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg5.html
>
> Interesting thread.
>
> For similar reasons, I think that Lucene and Solr should eventually move
> to Git. It's not GitHub, but it's a lot closer. The new Apache projects I
> see are all choosing Git. It's the winners road I think. I don't know that
> there is a big hurry right now, but I think it's inevitable that we should
> switch.
>
> --
> - Mark
>

RE: The Old Git Discussion

[Uwe Schindler]

As you might expect:

 

-1

 

Uwe

 

-

Uwe Schindler

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

  http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Mark Miller [mailto:markrmil...@gmail.com] 
Sent: Thursday, January 02, 2014 9:52 PM
To: dev@lucene.apache.org
Subject: The Old Git Discussion

 


bzr is dying; Emacs needs to move


 

http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg5.html


 

Interesting thread.

 

For similar reasons, I think that Lucene and Solr should eventually move to 
Git. It's not GitHub, but it's a lot closer. The new Apache projects I see are 
all choosing Git. It's the winners road I think. I don't know that there is a 
big hurry right now, but I think it's inevitable that we should switch.

 

-- 
- Mark 

Re: The Old Git Discussion

[Shawn Heisey]

On 1/2/2014 1:51 PM, Mark Miller wrote:
For similar reasons, I think that Lucene and Solr should eventually 
move to Git. It's not GitHub, but it's a lot closer. The new Apache 
projects I see are all choosing Git. It's the winners road I think. I 
don't know that there is a big hurry right now, but I think it's 
inevitable that we should switch.


+1

I can't make any cogent arguments about whether git is superior to 
subversion at the basic job of version control, whether it produces 
better workflows, or any similar argument. Generally speaking, I do 
think it's a good idea for projects like Apache to eat their own 
dogfood, which currently we do because we use subversion.


That said, I do have to agree with ESR's general conclusion that git has 
won the current mindshare war.  Open source projects are flocking to it 
en masse, and it's not just the little guys.  I don't think that would 
happen if there weren't a good reason.


We're even using it in-house at work.  My Solr install on Linux consists 
of two git repositories - one for configs (the solr home) and one for 
binaries.


For people like me who are relatively new to version control, there's 
little difference from one system to another.  For others, there is a 
wealth of documentation and quick HOWTO information available.


Thanks,
Shawn


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

Re: The Old Git Discussion

[Mark Miller]

Just to note - I don't mean to compare SVN to bzr. It's not the same
situation. Many of the points have interesting equivalents with our project
though.


On Thu, Jan 2, 2014 at 3:51 PM, Mark Miller  wrote:

> bzr is dying; Emacs needs to move
>
> http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg5.html
>
> Interesting thread.
>
> For similar reasons, I think that Lucene and Solr should eventually move
> to Git. It's not GitHub, but it's a lot closer. The new Apache projects I
> see are all choosing Git. It's the winners road I think. I don't know that
> there is a big hurry right now, but I think it's inevitable that we should
> switch.
>
> --
> - Mark
>



-- 
- Mark

Re: The Old Git Discussion

[Simon Willnauer]

+1

On Thu, Jan 2, 2014 at 9:51 PM, Mark Miller  wrote:
> bzr is dying; Emacs needs to move
>
>
> http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg5.html
>
> Interesting thread.
>
> For similar reasons, I think that Lucene and Solr should eventually move to
> Git. It's not GitHub, but it's a lot closer. The new Apache projects I see
> are all choosing Git. It's the winners road I think. I don't know that there
> is a big hurry right now, but I think it's inevitable that we should switch.
>
> --
> - Mark

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

The Old Git Discussion

[Mark Miller]

bzr is dying; Emacs needs to move

http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg5.html

Interesting thread.

For similar reasons, I think that Lucene and Solr should eventually move to
Git. It's not GitHub, but it's a lot closer. The new Apache projects I see
are all choosing Git. It's the winners road I think. I don't know that
there is a big hurry right now, but I think it's inevitable that we should
switch.

-- 
- Mark

[jira] [Commented] (SOLR-3583) Percentiles for facets, pivot facets, and distributed pivot facets

[Terrance A. Snyder (JIRA)]

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

Terrance A. Snyder commented on SOLR-3583:
--

[~solrup] The posted project on github is not related to source code found in 
this ticket. Apologies for any confusion there. If you are looking for 
percentiles that work with 4.5 and 4.6 see the github source. You dont have to 
recompile SOLR with this release. I will be adding distributed pivot to that 
project in the next week.

> Percentiles for facets, pivot facets, and distributed pivot facets
> --
>
> Key: SOLR-3583
> URL: https://issues.apache.org/jira/browse/SOLR-3583
> Project: Solr
>  Issue Type: Improvement
>Reporter: Chris Russell
>Priority: Minor
>  Labels: newbie, patch
> Fix For: 4.6
>
> Attachments: SOLR-3583.patch, SOLR-3583.patch, SOLR-3583.patch, 
> SOLR-3583.patch
>
>
> Built on top of SOLR-2894, this patch adds percentiles and averages to 
> facets, pivot facets, and distributed pivot facets by making use of range 
> facet internals.  



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5590) SolrJ is still on httpcomponents/httpclient version 4.2.x, which has some problems

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-5590:


[~markrmil...@gmail.com], I take your comment to mean that this should not be 
backported to 4.6.1.  I'm OK with that - httpclient is a pretty important 
component.  The change seems pretty harmless, but users are a creative bunch, 
if there's even a remote chance for something to go wrong, someone will find it!


> SolrJ is still on httpcomponents/httpclient version 4.2.x, which has some 
> problems
> --
>
> Key: SOLR-5590
> URL: https://issues.apache.org/jira/browse/SOLR-5590
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 4.5.1
>Reporter: Karl Wright
>Assignee: Shawn Heisey
> Attachments: SOLR-5590.patch
>
>
> SolrJ depends on HttpClient 4.2.x right now, but HttpClient 4.2.x has issues 
> that the ManifoldCF team encountered with handling of form data encoding - 
> issues which are addressed in HttpClient 4.3.x.  We developed a local patch, 
> but Solr will eventually need to go to the new client.  (ManifoldCF would 
> plan to follow shortly thereafter).
> I tried to get Oleg (PMC chair of HttpComponents) to agree to port the fixed 
> code to the 4.2.x stream but he did not want to do that.  So I believe that 
> that avenue is closed.
> See CONNECTORS-623 for a detailed description of the problem.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5311) Avoid registering replicas which are removed

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-5311:
---

Shalin has captured previous discussions really well in this issue SOLR-5128. 
We need a new "ZooKeeper is Truth" mode. In that mode, we can start building 
this feature set out.

> Avoid registering replicas which are removed 
> -
>
> Key: SOLR-5311
> URL: https://issues.apache.org/jira/browse/SOLR-5311
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Noble Paul
>Assignee: Noble Paul
> Fix For: 4.6, 5.0
>
> Attachments: SOLR-5311.patch, SOLR-5311.patch, SOLR-5311.patch, 
> SOLR-5311.patch, SOLR-5311.patch, SOLR-5311.patch, SOLR-5311.patch
>
>
> If a replica is removed from the clusterstate and if it comes back up it 
> should not be allowed to register. 
> Each core ,when comes up, checks if it was already registered and if yes is 
> it still there. If not ,throw an error and do an unregister . If such a 
> request come to overseer it should ignore such a core



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5128) Improve SolrCloud cluster management capabilities

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-5128:
---

Nice!

> Improve SolrCloud cluster management capabilities
> -
>
> Key: SOLR-5128
> URL: https://issues.apache.org/jira/browse/SOLR-5128
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud
>Reporter: Shalin Shekhar Mangar
>Assignee: Shalin Shekhar Mangar
> Fix For: 5.0, 4.7
>
>
> This is a master issue to track things that we need to do to make cluster 
> management easier.
> # Introduce a new mode to disallow creation of collections by configuration 
> and use the collection API instead
> # New addNode/removeNode APIs to add/remove nodes to/from a collection/shard
> # New modifyCollection API to change replicationFactor, maxShardsPerNode 
> configurations
> # Update Solr Admin UI for the new APIs
> # Longer term, optionally enforce the replicationFactor to add/remove nodes 
> automatically
> Some features have already been committed as part of other issues:
> # SOLR-4693 added a deleteShard API
> # SOLR-5006 added a createShard API
> # SOLR-4808 persisted replicationFactor and maxShardsPerNode parameters in 
> cluster state



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5600) Don't perisist replicationFactor by default.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-5600:
---

When we should persist could become more complicated perhaps. If you can 
eventually do everything through the Collections API, it may make sense to 
persist it because it can be kept in line with reality as a possibility (update 
it based on the Collection API calls?).

Currently, it should not be persisted IMO.

> Don't perisist replicationFactor by default.
> 
>
> Key: SOLR-5600
> URL: https://issues.apache.org/jira/browse/SOLR-5600
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Mark Miller
>Priority: Minor
>
> It seems this should not be persisted by default as it can quickly stop 
> matching reality.
> Once we have the "ZooKeeper is Truth" mode for SolrCloud, we should add an 
> option to enforce the replication factor for a collection - but only if that 
> option is on should we persist replicationFactor.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Updated] (SOLR-5600) Don't perisist replicationFactor by default.

[Mark Miller (JIRA)]

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

Mark Miller updated SOLR-5600:
--

Priority: Minor  (was: Major)

> Don't perisist replicationFactor by default.
> 
>
> Key: SOLR-5600
> URL: https://issues.apache.org/jira/browse/SOLR-5600
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Reporter: Mark Miller
>Priority: Minor
>
> It seems this should not be persisted by default as it can quickly stop 
> matching reality.
> Once we have the "ZooKeeper is Truth" mode for SolrCloud, we should add an 
> option to enforce the replication factor for a collection - but only if that 
> option is on should we persist replicationFactor.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Created] (SOLR-5600) Don't perisist replicationFactor by default.

[Mark Miller (JIRA)]

Mark Miller created SOLR-5600:
-

 Summary: Don't perisist replicationFactor by default.
 Key: SOLR-5600
 URL: https://issues.apache.org/jira/browse/SOLR-5600
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Mark Miller


It seems this should not be persisted by default as it can quickly stop 
matching reality.

Once we have the "ZooKeeper is Truth" mode for SolrCloud, we should add an 
option to enforce the replication factor for a collection - but only if that 
option is on should we persist replicationFactor.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-3583) Percentiles for facets, pivot facets, and distributed pivot facets

[Fang Xu (JIRA)]

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

Fang Xu commented on SOLR-3583:
---

i'ts not comparable with the solr version 4.6.0, epsecially in the 
org.apache.solr.request.SimpleFacets.java file,  the interface for those 
getTermCounts*. methods  changed. Could you checked it? or tell me where i can 
find trunk 1297102?

Sincerely

   Dummy me

> Percentiles for facets, pivot facets, and distributed pivot facets
> --
>
> Key: SOLR-3583
> URL: https://issues.apache.org/jira/browse/SOLR-3583
> Project: Solr
>  Issue Type: Improvement
>Reporter: Chris Russell
>Priority: Minor
>  Labels: newbie, patch
> Fix For: 4.6
>
> Attachments: SOLR-3583.patch, SOLR-3583.patch, SOLR-3583.patch, 
> SOLR-3583.patch
>
>
> Built on top of SOLR-2894, this patch adds percentiles and averages to 
> facets, pivot facets, and distributed pivot facets by making use of range 
> facet internals.  



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0-ea-b121) - Build # 8929 - Failure!

[Dawid Weiss]

I don't recall seing this one before.

D.

On Thu, Jan 2, 2014 at 5:37 PM, Robert Muir  wrote:
> this is new i think?
>
> On Thu, Jan 2, 2014 at 11:35 AM, Policeman Jenkins Server
>  wrote:
>> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/8929/
>> Java: 32bit/jdk1.8.0-ea-b121 -server -XX:+UseConcMarkSweepGC
>>
>> All tests passed
>>
>> Build Log:
>> [...truncated 1183 lines...]
>>[junit4] JVM J1: stdout was not empty, see: 
>> /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/temp/junit4-J1-20140102_162350_507.sysout
>>[junit4] >>> JVM J1: stdout (verbatim) 
>>[junit4] #
>>[junit4] # A fatal error has been detected by the Java Runtime 
>> Environment:
>>[junit4] #
>>[junit4] #  SIGSEGV (0xb) at pc=0xf6f19411, pid=27661, tid=3875535680
>>[junit4] #
>>[junit4] # JRE version: Java(TM) SE Runtime Environment (8.0-b121) (build 
>> 1.8.0-ea-b121)
>>[junit4] # Java VM: Java HotSpot(TM) Server VM (25.0-b63 mixed mode 
>> linux-x86 )
>>[junit4] # Problematic frame:
>>[junit4] # V  [libjvm.so+0x6d9411]  
>> ObjArrayKlass::oop_oop_iterate_nv(oopDesc*, 
>> ParScanWithoutBarrierClosure*)+0x61
>>[junit4] #
>>[junit4] # Failed to write core dump. Core dumps have been disabled. To 
>> enable core dumping, try "ulimit -c unlimited" before starting Java again
>>[junit4] #
>>[junit4] # An error report file with more information is saved as:
>>[junit4] # 
>> /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/J1/hs_err_pid27661.log
>>[junit4] #
>>[junit4] # If you would like to submit a bug report, please visit:
>>[junit4] #   http://bugreport.sun.com/bugreport/crash.jsp
>>[junit4] #
>>[junit4] <<< JVM J1: EOF 
>>
>> [...truncated 423 lines...]
>>[junit4] ERROR: JVM J1 ended with an exception, command line: 
>> /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b121/jre/bin/java -server 
>> -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError 
>> -XX:HeapDumpPath=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/heapdumps
>>  -Dtests.prefix=tests -Dtests.seed=9E085C3DBEC84015 -Xmx512M -Dtests.iters= 
>> -Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random 
>> -Dtests.postingsformat=random -Dtests.docvaluesformat=random 
>> -Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random 
>> -Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=5.0 
>> -Dtests.cleanthreads=perMethod 
>> -Djava.util.logging.config.file=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/junit4/logging.properties
>>  -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true 
>> -Dtests.asserts.gracious=false -Dtests.multiplier=3 -DtempDir=. 
>> -Djava.io.tmpdir=. 
>> -Djunit4.tempDir=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/temp
>>  
>> -Dclover.db.dir=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/clover/db
>>  -Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
>> -Djava.security.policy=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/junit4/tests.policy
>>  -Dlucene.version=5.0-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 
>> -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
>> -Djava.awt.headless=true -Djdk.map.althashing.threshold=0 
>> -Dtests.disableHdfs=true -Dfile.encoding=US-ASCII -classpath 
>> /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/codecs/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/test-framework/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/test-framework/lib/junit-4.10.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/test-framework/lib/randomizedtesting-runner-2.0.13.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/classes/test:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-launcher.jar:/var/lib/jenkins/.ant/lib/ivy-2.3.0.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jai.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-swing.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-oro.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jmf.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-xalan2.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-javamail.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-resolver.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-testutil.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-commons-logging.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-log4j.jar:/var/li

Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0-ea-b121) - Build # 8929 - Failure!

[Robert Muir]

this is new i think?

On Thu, Jan 2, 2014 at 11:35 AM, Policeman Jenkins Server
 wrote:
> Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/8929/
> Java: 32bit/jdk1.8.0-ea-b121 -server -XX:+UseConcMarkSweepGC
>
> All tests passed
>
> Build Log:
> [...truncated 1183 lines...]
>[junit4] JVM J1: stdout was not empty, see: 
> /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/temp/junit4-J1-20140102_162350_507.sysout
>[junit4] >>> JVM J1: stdout (verbatim) 
>[junit4] #
>[junit4] # A fatal error has been detected by the Java Runtime Environment:
>[junit4] #
>[junit4] #  SIGSEGV (0xb) at pc=0xf6f19411, pid=27661, tid=3875535680
>[junit4] #
>[junit4] # JRE version: Java(TM) SE Runtime Environment (8.0-b121) (build 
> 1.8.0-ea-b121)
>[junit4] # Java VM: Java HotSpot(TM) Server VM (25.0-b63 mixed mode 
> linux-x86 )
>[junit4] # Problematic frame:
>[junit4] # V  [libjvm.so+0x6d9411]  
> ObjArrayKlass::oop_oop_iterate_nv(oopDesc*, 
> ParScanWithoutBarrierClosure*)+0x61
>[junit4] #
>[junit4] # Failed to write core dump. Core dumps have been disabled. To 
> enable core dumping, try "ulimit -c unlimited" before starting Java again
>[junit4] #
>[junit4] # An error report file with more information is saved as:
>[junit4] # 
> /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/J1/hs_err_pid27661.log
>[junit4] #
>[junit4] # If you would like to submit a bug report, please visit:
>[junit4] #   http://bugreport.sun.com/bugreport/crash.jsp
>[junit4] #
>[junit4] <<< JVM J1: EOF 
>
> [...truncated 423 lines...]
>[junit4] ERROR: JVM J1 ended with an exception, command line: 
> /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b121/jre/bin/java -server 
> -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError 
> -XX:HeapDumpPath=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/heapdumps 
> -Dtests.prefix=tests -Dtests.seed=9E085C3DBEC84015 -Xmx512M -Dtests.iters= 
> -Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random 
> -Dtests.postingsformat=random -Dtests.docvaluesformat=random 
> -Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random 
> -Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=5.0 
> -Dtests.cleanthreads=perMethod 
> -Djava.util.logging.config.file=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/junit4/logging.properties
>  -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true 
> -Dtests.asserts.gracious=false -Dtests.multiplier=3 -DtempDir=. 
> -Djava.io.tmpdir=. 
> -Djunit4.tempDir=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/temp
>  
> -Dclover.db.dir=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/clover/db
>  -Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
> -Djava.security.policy=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/junit4/tests.policy
>  -Dlucene.version=5.0-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 
> -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
> -Djava.awt.headless=true -Djdk.map.althashing.threshold=0 
> -Dtests.disableHdfs=true -Dfile.encoding=US-ASCII -classpath 
> /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/codecs/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/test-framework/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/test-framework/lib/junit-4.10.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/test-framework/lib/randomizedtesting-runner-2.0.13.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/classes/test:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-launcher.jar:/var/lib/jenkins/.ant/lib/ivy-2.3.0.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jai.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-swing.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-oro.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jmf.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-xalan2.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-javamail.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-resolver.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-testutil.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-commons-logging.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-log4j.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-junit.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jsch.jar:/var/li

[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0-ea-b121) - Build # 8929 - Failure!

[Policeman Jenkins Server]

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/8929/
Java: 32bit/jdk1.8.0-ea-b121 -server -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 1183 lines...]
   [junit4] JVM J1: stdout was not empty, see: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/temp/junit4-J1-20140102_162350_507.sysout
   [junit4] >>> JVM J1: stdout (verbatim) 
   [junit4] #
   [junit4] # A fatal error has been detected by the Java Runtime Environment:
   [junit4] #
   [junit4] #  SIGSEGV (0xb) at pc=0xf6f19411, pid=27661, tid=3875535680
   [junit4] #
   [junit4] # JRE version: Java(TM) SE Runtime Environment (8.0-b121) (build 
1.8.0-ea-b121)
   [junit4] # Java VM: Java HotSpot(TM) Server VM (25.0-b63 mixed mode 
linux-x86 )
   [junit4] # Problematic frame:
   [junit4] # V  [libjvm.so+0x6d9411]  
ObjArrayKlass::oop_oop_iterate_nv(oopDesc*, ParScanWithoutBarrierClosure*)+0x61
   [junit4] #
   [junit4] # Failed to write core dump. Core dumps have been disabled. To 
enable core dumping, try "ulimit -c unlimited" before starting Java again
   [junit4] #
   [junit4] # An error report file with more information is saved as:
   [junit4] # 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/J1/hs_err_pid27661.log
   [junit4] #
   [junit4] # If you would like to submit a bug report, please visit:
   [junit4] #   http://bugreport.sun.com/bugreport/crash.jsp
   [junit4] #
   [junit4] <<< JVM J1: EOF 

[...truncated 423 lines...]
   [junit4] ERROR: JVM J1 ended with an exception, command line: 
/var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b121/jre/bin/java -server 
-XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/heapdumps 
-Dtests.prefix=tests -Dtests.seed=9E085C3DBEC84015 -Xmx512M -Dtests.iters= 
-Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random 
-Dtests.postingsformat=random -Dtests.docvaluesformat=random 
-Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random 
-Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=5.0 
-Dtests.cleanthreads=perMethod 
-Djava.util.logging.config.file=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/junit4/logging.properties
 -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true 
-Dtests.asserts.gracious=false -Dtests.multiplier=3 -DtempDir=. 
-Djava.io.tmpdir=. 
-Djunit4.tempDir=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/temp
 
-Dclover.db.dir=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/clover/db
 -Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Djava.security.policy=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/junit4/tests.policy
 -Dlucene.version=5.0-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 
-Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
-Djava.awt.headless=true -Djdk.map.althashing.threshold=0 
-Dtests.disableHdfs=true -Dfile.encoding=US-ASCII -classpath 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/codecs/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/test-framework/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/test-framework/lib/junit-4.10.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/test-framework/lib/randomizedtesting-runner-2.0.13.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/classes/test:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-launcher.jar:/var/lib/jenkins/.ant/lib/ivy-2.3.0.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jai.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-swing.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-oro.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jmf.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-xalan2.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-javamail.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-resolver.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-testutil.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-commons-logging.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-log4j.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-junit.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jsch.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-commons-net.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-bsf.jar:/var/lib/jenkins/tools/hudson.tasks.

[jira] [Commented] (SOLR-5599) SolrCloud Admin UI Cluster Table View

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-5599:
---

We also discussed removing the mostly unusable radial graphical view.

> SolrCloud Admin UI Cluster Table View
> -
>
> Key: SOLR-5599
> URL: https://issues.apache.org/jira/browse/SOLR-5599
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud, web gui
>Reporter: Mark Miller
>
> A new table view for viewing the cluster layout. Sortable by field would be 
> best.
> I talked a bit about this with Stefan in Dublin. We really need a better view 
> for large scale clusters. A sortable table view seems like a great option to 
> have.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5599) SolrCloud Admin UI Cluster Table View

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-5599:
---

Though it is very pretty on a large cluster :)

> SolrCloud Admin UI Cluster Table View
> -
>
> Key: SOLR-5599
> URL: https://issues.apache.org/jira/browse/SOLR-5599
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud, web gui
>Reporter: Mark Miller
>
> A new table view for viewing the cluster layout. Sortable by field would be 
> best.
> I talked a bit about this with Stefan in Dublin. We really need a better view 
> for large scale clusters. A sortable table view seems like a great option to 
> have.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5599) SolrCloud Admin UI Cluster Table View

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-5599:
---

[~steffkes], have any further thoughts on this?

> SolrCloud Admin UI Cluster Table View
> -
>
> Key: SOLR-5599
> URL: https://issues.apache.org/jira/browse/SOLR-5599
> Project: Solr
>  Issue Type: New Feature
>  Components: SolrCloud, web gui
>Reporter: Mark Miller
>
> A new table view for viewing the cluster layout. Sortable by field would be 
> best.
> I talked a bit about this with Stefan in Dublin. We really need a better view 
> for large scale clusters. A sortable table view seems like a great option to 
> have.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Created] (SOLR-5599) SolrCloud Admin UI Cluster Table View

[Mark Miller (JIRA)]

Mark Miller created SOLR-5599:
-

 Summary: SolrCloud Admin UI Cluster Table View
 Key: SOLR-5599
 URL: https://issues.apache.org/jira/browse/SOLR-5599
 Project: Solr
  Issue Type: New Feature
  Components: SolrCloud, web gui
Reporter: Mark Miller


A new table view for viewing the cluster layout. Sortable by field would be 
best.

I talked a bit about this with Stefan in Dublin. We really need a better view 
for large scale clusters. A sortable table view seems like a great option to 
have.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Resolved] (SOLR-5581) Give ZkCLI the ability to get files

[Mark Miller (JIRA)]

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

Mark Miller resolved SOLR-5581.
---

Resolution: Fixed

Thanks Greg!

> Give ZkCLI the ability to get files
> ---
>
> Key: SOLR-5581
> URL: https://issues.apache.org/jira/browse/SOLR-5581
> Project: Solr
>  Issue Type: Improvement
>  Components: SolrCloud
>Affects Versions: 5.0, 4.7
>Reporter: Gregory Chanan
>Assignee: Mark Miller
>Priority: Minor
> Fix For: 5.0, 4.7
>
> Attachments: SOLR-5581.patch
>
>
> Today, the ZkCli has the ability to put files to Zk (via put or putfile), but 
> not get files.  This would be useful for me along with SOLR-5556, i.e. I 
> could save the old solr.xml and replace it with a new one.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5590) SolrJ is still on httpcomponents/httpclient version 4.2.x, which has some problems

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-5590:
---

Thanks Karl! We should do this for 4.7.

> SolrJ is still on httpcomponents/httpclient version 4.2.x, which has some 
> problems
> --
>
> Key: SOLR-5590
> URL: https://issues.apache.org/jira/browse/SOLR-5590
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 4.5.1
>Reporter: Karl Wright
>Assignee: Shawn Heisey
> Attachments: SOLR-5590.patch
>
>
> SolrJ depends on HttpClient 4.2.x right now, but HttpClient 4.2.x has issues 
> that the ManifoldCF team encountered with handling of form data encoding - 
> issues which are addressed in HttpClient 4.3.x.  We developed a local patch, 
> but Solr will eventually need to go to the new client.  (ManifoldCF would 
> plan to follow shortly thereafter).
> I tried to get Oleg (PMC chair of HttpComponents) to agree to port the fixed 
> code to the 4.2.x stream but he did not want to do that.  So I believe that 
> that avenue is closed.
> See CONNECTORS-623 for a detailed description of the problem.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Comment Edited] (SOLR-5580) SOLR-5311 was done without full understanding of the system and must be reverted.

[Mark Miller (JIRA)]

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

Mark Miller edited comment on SOLR-5580 at 1/2/14 3:45 PM:
---

Like I've said in SOLR-5311, autoCreated is illegal in the current system. 
Cores created by the Collections API must currently be the same as those 
created by the Core Admin API or preconfigured.

autoCreated cannot exist yet, and when it can, it can't be used by default, it 
must be a new mode. 


was (Author: markrmil...@gmail.com):
Like I've said in SOLR-5311, Created is illegal in the current system. Cores 
created by the Collections API must currently be the same as those created by 
the Core Admin API or preconfigured.

autoCreated cannot exist yet, and when it can, it can't be used by default, it 
must be a new mode. 

> SOLR-5311 was done without full understanding of the system and must be 
> reverted.
> -
>
> Key: SOLR-5580
> URL: https://issues.apache.org/jira/browse/SOLR-5580
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.6
> Environment: OS:Red Hat Enterprise Linux Server release 6.4 (Santiago)
> Software:solr 4.6,
>jdk:OpenJDK Runtime Environment (rhel-2.3.4.1.el6_3-x86_64)
> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
>Reporter: YouPeng Yang
>Assignee: Mark Miller
>  Labels: core
> Fix For: 5.0, 4.7, 4.6.1
>
> Attachments: SOLR-5580.patch
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> In class org.apache.solr.cloud.Overseer the Line 360:
> -
>   if (sliceName !=null && collectionExists &&  
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice.getReplica(coreNodeName) == null) {
>   log.info("core_deleted . Just return");
>   return state;
> }
>   }
> -
> the slice needs to be checked null .because when create a new core with both 
> explicite shard and coreNodeName, the state.getSlice(collection, sliceName)  
> may return a null.So it needs to be checked ,or there will be an 
> NullpointException
> -
>   if (sliceName !=null && collectionExists &&  
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice != null && slice.getReplica(coreNodeName) == null) {
>   log.info("core_deleted . Just return");
>   return state;
> }
>   }
> -



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5580) SOLR-5311 was done without full understanding of the system and must be reverted.

[Mark Miller (JIRA)]

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

Mark Miller commented on SOLR-5580:
---

Like I've said in SOLR-5311, autoCommit is illegal in the current system. Cores 
created by the Collections API must currently be the same as those created by 
the Core Admin API or preconfigured.

autoCreated cannot exist yet, and when it can, it can't be used by default, it 
must be a new mode. 

> SOLR-5311 was done without full understanding of the system and must be 
> reverted.
> -
>
> Key: SOLR-5580
> URL: https://issues.apache.org/jira/browse/SOLR-5580
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.6
> Environment: OS:Red Hat Enterprise Linux Server release 6.4 (Santiago)
> Software:solr 4.6,
>jdk:OpenJDK Runtime Environment (rhel-2.3.4.1.el6_3-x86_64)
> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
>Reporter: YouPeng Yang
>Assignee: Mark Miller
>  Labels: core
> Fix For: 5.0, 4.7, 4.6.1
>
> Attachments: SOLR-5580.patch
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> In class org.apache.solr.cloud.Overseer the Line 360:
> -
>   if (sliceName !=null && collectionExists &&  
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice.getReplica(coreNodeName) == null) {
>   log.info("core_deleted . Just return");
>   return state;
> }
>   }
> -
> the slice needs to be checked null .because when create a new core with both 
> explicite shard and coreNodeName, the state.getSlice(collection, sliceName)  
> may return a null.So it needs to be checked ,or there will be an 
> NullpointException
> -
>   if (sliceName !=null && collectionExists &&  
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice != null && slice.getReplica(coreNodeName) == null) {
>   log.info("core_deleted . Just return");
>   return state;
> }
>   }
> -



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Comment Edited] (SOLR-5580) SOLR-5311 was done without full understanding of the system and must be reverted.

[Mark Miller (JIRA)]

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

Mark Miller edited comment on SOLR-5580 at 1/2/14 3:44 PM:
---

Like I've said in SOLR-5311, Created is illegal in the current system. Cores 
created by the Collections API must currently be the same as those created by 
the Core Admin API or preconfigured.

autoCreated cannot exist yet, and when it can, it can't be used by default, it 
must be a new mode. 


was (Author: markrmil...@gmail.com):
Like I've said in SOLR-5311, autoCommit is illegal in the current system. Cores 
created by the Collections API must currently be the same as those created by 
the Core Admin API or preconfigured.

autoCreated cannot exist yet, and when it can, it can't be used by default, it 
must be a new mode. 

> SOLR-5311 was done without full understanding of the system and must be 
> reverted.
> -
>
> Key: SOLR-5580
> URL: https://issues.apache.org/jira/browse/SOLR-5580
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.6
> Environment: OS:Red Hat Enterprise Linux Server release 6.4 (Santiago)
> Software:solr 4.6,
>jdk:OpenJDK Runtime Environment (rhel-2.3.4.1.el6_3-x86_64)
> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
>Reporter: YouPeng Yang
>Assignee: Mark Miller
>  Labels: core
> Fix For: 5.0, 4.7, 4.6.1
>
> Attachments: SOLR-5580.patch
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> In class org.apache.solr.cloud.Overseer the Line 360:
> -
>   if (sliceName !=null && collectionExists &&  
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice.getReplica(coreNodeName) == null) {
>   log.info("core_deleted . Just return");
>   return state;
> }
>   }
> -
> the slice needs to be checked null .because when create a new core with both 
> explicite shard and coreNodeName, the state.getSlice(collection, sliceName)  
> may return a null.So it needs to be checked ,or there will be an 
> NullpointException
> -
>   if (sliceName !=null && collectionExists &&  
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice != null && slice.getReplica(coreNodeName) == null) {
>   log.info("core_deleted . Just return");
>   return state;
> }
>   }
> -



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5590) SolrJ is still on httpcomponents/httpclient version 4.2.x, which has some problems

[Karl Wright (JIRA)]

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

Karl Wright commented on SOLR-5590:
---

Hi Shawn,

Correct, I am not a committer for Solr, but I am involved in a downstream 
project (ManifoldCF) that has a Solr integration via SolrJ, so I have an 
interest in getting this stuff working.

My suggestion, for now, is to create a separate ticket to work on the use of 
deprecated httpclient classes, but do this as a later step.  For now, though, 
it would be great to just list them.  I'll likely have a similar situation to 
deal with in ManifoldCF.


> SolrJ is still on httpcomponents/httpclient version 4.2.x, which has some 
> problems
> --
>
> Key: SOLR-5590
> URL: https://issues.apache.org/jira/browse/SOLR-5590
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 4.5.1
>Reporter: Karl Wright
>Assignee: Shawn Heisey
> Attachments: SOLR-5590.patch
>
>
> SolrJ depends on HttpClient 4.2.x right now, but HttpClient 4.2.x has issues 
> that the ManifoldCF team encountered with handling of form data encoding - 
> issues which are addressed in HttpClient 4.3.x.  We developed a local patch, 
> but Solr will eventually need to go to the new client.  (ManifoldCF would 
> plan to follow shortly thereafter).
> I tried to get Oleg (PMC chair of HttpComponents) to agree to port the fixed 
> code to the 4.2.x stream but he did not want to do that.  So I believe that 
> that avenue is closed.
> See CONNECTORS-623 for a detailed description of the problem.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Updated] (SOLR-5580) SOLR-5311 was done without full understanding of the system and must be reverted.

[Noble Paul (JIRA)]

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

Noble Paul updated SOLR-5580:
-

Attachment: SOLR-5580.patch

The 'autoCreated' attribute was missing .

> SOLR-5311 was done without full understanding of the system and must be 
> reverted.
> -
>
> Key: SOLR-5580
> URL: https://issues.apache.org/jira/browse/SOLR-5580
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.6
> Environment: OS:Red Hat Enterprise Linux Server release 6.4 (Santiago)
> Software:solr 4.6,
>jdk:OpenJDK Runtime Environment (rhel-2.3.4.1.el6_3-x86_64)
> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
>Reporter: YouPeng Yang
>Assignee: Mark Miller
>  Labels: core
> Fix For: 5.0, 4.7, 4.6.1
>
> Attachments: SOLR-5580.patch
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> In class org.apache.solr.cloud.Overseer the Line 360:
> -
>   if (sliceName !=null && collectionExists &&  
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice.getReplica(coreNodeName) == null) {
>   log.info("core_deleted . Just return");
>   return state;
> }
>   }
> -
> the slice needs to be checked null .because when create a new core with both 
> explicite shard and coreNodeName, the state.getSlice(collection, sliceName)  
> may return a null.So it needs to be checked ,or there will be an 
> NullpointException
> -
>   if (sliceName !=null && collectionExists &&  
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice != null && slice.getReplica(coreNodeName) == null) {
>   log.info("core_deleted . Just return");
>   return state;
> }
>   }
> -



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Assigned] (SOLR-5590) SolrJ is still on httpcomponents/httpclient version 4.2.x, which has some problems

[Shawn Heisey (JIRA)]

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

Shawn Heisey reassigned SOLR-5590:
--

Assignee: Shawn Heisey

> SolrJ is still on httpcomponents/httpclient version 4.2.x, which has some 
> problems
> --
>
> Key: SOLR-5590
> URL: https://issues.apache.org/jira/browse/SOLR-5590
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 4.5.1
>Reporter: Karl Wright
>Assignee: Shawn Heisey
> Attachments: SOLR-5590.patch
>
>
> SolrJ depends on HttpClient 4.2.x right now, but HttpClient 4.2.x has issues 
> that the ManifoldCF team encountered with handling of form data encoding - 
> issues which are addressed in HttpClient 4.3.x.  We developed a local patch, 
> but Solr will eventually need to go to the new client.  (ManifoldCF would 
> plan to follow shortly thereafter).
> I tried to get Oleg (PMC chair of HttpComponents) to agree to port the fixed 
> code to the 4.2.x stream but he did not want to do that.  So I believe that 
> that avenue is closed.
> See CONNECTORS-623 for a detailed description of the problem.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5590) SolrJ is still on httpcomponents/httpclient version 4.2.x, which has some problems

[Shawn Heisey (JIRA)]

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

Shawn Heisey commented on SOLR-5590:


I checked the committer list for the project, and [~kwri...@metacarta.com] 
didn't show up there.  I'm willing to work with Karl and get this change 
committed.  I need a few hours before I can work on it, so if someone else has 
the time right now, feel free to take over.

Another potential reason for someone else to take over, unless Karl already 
knows what to do:  This change definitely means that SolrJ is using deprecated 
classes.  I'd like to eliminate the deprecated classes, but that might require 
a completely new issue.  I already tried once to use the new Builder classes in 
my own SolrJ code, but found that SolrJ didn't like it for some reason.


> SolrJ is still on httpcomponents/httpclient version 4.2.x, which has some 
> problems
> --
>
> Key: SOLR-5590
> URL: https://issues.apache.org/jira/browse/SOLR-5590
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 4.5.1
>Reporter: Karl Wright
> Attachments: SOLR-5590.patch
>
>
> SolrJ depends on HttpClient 4.2.x right now, but HttpClient 4.2.x has issues 
> that the ManifoldCF team encountered with handling of form data encoding - 
> issues which are addressed in HttpClient 4.3.x.  We developed a local patch, 
> but Solr will eventually need to go to the new client.  (ManifoldCF would 
> plan to follow shortly thereafter).
> I tried to get Oleg (PMC chair of HttpComponents) to agree to port the fixed 
> code to the 4.2.x stream but he did not want to do that.  So I believe that 
> that avenue is closed.
> See CONNECTORS-623 for a detailed description of the problem.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Reopened] (SOLR-1578) Geocoding Spatial Query Parser

[David Smiley (JIRA)]

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

David Smiley reopened SOLR-1578:



> Geocoding Spatial Query Parser
> --
>
> Key: SOLR-1578
> URL: https://issues.apache.org/jira/browse/SOLR-1578
> Project: Solr
>  Issue Type: New Feature
>  Components: spatial
>Reporter: Grant Ingersoll
>
> Given all the work around spatial, it would be beneficial if Solr had a query 
> parser for dealing with spatial queries.  For starters, something that used 
> geonames data or maybe even Google Maps API would be really useful.  Longer 
> term, a spatial grammar that can robustly handle all the vagaries of 
> addresses, etc. would be really cool.
> Refs: 
> [1] http://www.geonames.org/export/client-libraries.html (note the Java 
> client is ASL)
> [2] Data from geo names: http://download.geonames.org/export/dump/



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Updated] (SOLR-1578) Geocoding Spatial Query Parser

[David Smiley (JIRA)]

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

David Smiley updated SOLR-1578:
---

Summary: Geocoding Spatial Query Parser  (was: Develop a Spatial Query 
Parser)

> Geocoding Spatial Query Parser
> --
>
> Key: SOLR-1578
> URL: https://issues.apache.org/jira/browse/SOLR-1578
> Project: Solr
>  Issue Type: New Feature
>  Components: spatial
>Reporter: Grant Ingersoll
>
> Given all the work around spatial, it would be beneficial if Solr had a query 
> parser for dealing with spatial queries.  For starters, something that used 
> geonames data or maybe even Google Maps API would be really useful.  Longer 
> term, a spatial grammar that can robustly handle all the vagaries of 
> addresses, etc. would be really cool.
> Refs: 
> [1] http://www.geonames.org/export/client-libraries.html (note the Java 
> client is ASL)
> [2] Data from geo names: http://download.geonames.org/export/dump/



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-1578) Develop a Spatial Query Parser

[David Smiley (JIRA)]

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

David Smiley commented on SOLR-1578:


[~gsingers] had this to say about this issue:

bq. FWIW, my intent behind SOLR-1578, was a geocoding query parser (i.e. put in 
addresses, POIs, etc.), not more spatial QP operators.  I'm fine w/ marking it 
as a duplicate, but at least wanted to capture that the issue was trying to 
achieve something different than what this is.

The issue title here should be renamed to include "geocoding" -- a key intended 
distinction. I'll rename it and even re-open it.  But that said... it's hard to 
imagine Solr shipping with geocoding unless perhaps it ended up as a contrib 
module.  I saw [~ichattopadhyaya]'s [Lucene Revolution presentation on 
geocoding|http://lanyrd.com/2013/lucenesolrrev/scqxyr/] and it is very 
non-trivial and requires large data files to resolve against.

> Develop a Spatial Query Parser
> --
>
> Key: SOLR-1578
> URL: https://issues.apache.org/jira/browse/SOLR-1578
> Project: Solr
>  Issue Type: New Feature
>  Components: spatial
>Reporter: Grant Ingersoll
>
> Given all the work around spatial, it would be beneficial if Solr had a query 
> parser for dealing with spatial queries.  For starters, something that used 
> geonames data or maybe even Google Maps API would be really useful.  Longer 
> term, a spatial grammar that can robustly handle all the vagaries of 
> addresses, etc. would be really cool.
> Refs: 
> [1] http://www.geonames.org/export/client-libraries.html (note the Java 
> client is ASL)
> [2] Data from geo names: http://download.geonames.org/export/dump/



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Updated] (SOLR-5590) SolrJ is still on httpcomponents/httpclient version 4.2.x, which has some problems

[Karl Wright (JIRA)]

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

Karl Wright updated SOLR-5590:
--

Attachment: SOLR-5590.patch

Patch that updates to the latest httpclient.

Note that this does NOT yet include any changes needed to specify UTF-8 
encoding for multipart form elements; looking into how that is done now.


> SolrJ is still on httpcomponents/httpclient version 4.2.x, which has some 
> problems
> --
>
> Key: SOLR-5590
> URL: https://issues.apache.org/jira/browse/SOLR-5590
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 4.5.1
>Reporter: Karl Wright
> Attachments: SOLR-5590.patch
>
>
> SolrJ depends on HttpClient 4.2.x right now, but HttpClient 4.2.x has issues 
> that the ManifoldCF team encountered with handling of form data encoding - 
> issues which are addressed in HttpClient 4.3.x.  We developed a local patch, 
> but Solr will eventually need to go to the new client.  (ManifoldCF would 
> plan to follow shortly thereafter).
> I tried to get Oleg (PMC chair of HttpComponents) to agree to port the fixed 
> code to the 4.2.x stream but he did not want to do that.  So I believe that 
> that avenue is closed.
> See CONNECTORS-623 for a detailed description of the problem.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5590) SolrJ is still on httpcomponents/httpclient version 4.2.x, which has some problems

[Karl Wright (JIRA)]

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

Karl Wright commented on SOLR-5590:
---

Tests pass too.  Since they include a fair number of solr cloud tests, I 
believe this means it is probably safe to commit the update to the latest 
httpclient.  Will attach a patch.



> SolrJ is still on httpcomponents/httpclient version 4.2.x, which has some 
> problems
> --
>
> Key: SOLR-5590
> URL: https://issues.apache.org/jira/browse/SOLR-5590
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 4.5.1
>Reporter: Karl Wright
>
> SolrJ depends on HttpClient 4.2.x right now, but HttpClient 4.2.x has issues 
> that the ManifoldCF team encountered with handling of form data encoding - 
> issues which are addressed in HttpClient 4.3.x.  We developed a local patch, 
> but Solr will eventually need to go to the new client.  (ManifoldCF would 
> plan to follow shortly thereafter).
> I tried to get Oleg (PMC chair of HttpComponents) to agree to port the fixed 
> code to the 4.2.x stream but he did not want to do that.  So I believe that 
> that avenue is closed.
> See CONNECTORS-623 for a detailed description of the problem.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Updated] (SOLR-5598) LanguageIdentifierUpdateProcessor ignores all but the first value of multiValued string fields

[Andreas Hubold (JIRA)]

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

Andreas Hubold updated SOLR-5598:
-

Attachment: SOLR-5598.patch

> LanguageIdentifierUpdateProcessor ignores all but the first value of 
> multiValued string fields
> --
>
> Key: SOLR-5598
> URL: https://issues.apache.org/jira/browse/SOLR-5598
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - LangId
>Affects Versions: 4.5.1
>Reporter: Andreas Hubold
> Attachments: SOLR-5598.patch
>
>
> The LanguageIdentifierUpdateProcessor just uses the first value of the 
> multiValued field to detect the language. 
> Method {{concatFields}} calls {{doc.getFieldValue(fieldName)}} but should 
> instead iterate over {{doc.getFieldValues(fieldName)}}.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Updated] (SOLR-5598) LanguageIdentifierUpdateProcessor ignores all but the first value of multiValued string fields

[Andreas Hubold (JIRA)]

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

Andreas Hubold updated SOLR-5598:
-

Attachment: (was: SOLR-5598.patch)

> LanguageIdentifierUpdateProcessor ignores all but the first value of 
> multiValued string fields
> --
>
> Key: SOLR-5598
> URL: https://issues.apache.org/jira/browse/SOLR-5598
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - LangId
>Affects Versions: 4.5.1
>Reporter: Andreas Hubold
> Attachments: SOLR-5598.patch
>
>
> The LanguageIdentifierUpdateProcessor just uses the first value of the 
> multiValued field to detect the language. 
> Method {{concatFields}} calls {{doc.getFieldValue(fieldName)}} but should 
> instead iterate over {{doc.getFieldValues(fieldName)}}.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5590) SolrJ is still on httpcomponents/httpclient version 4.2.x, which has some problems

[Karl Wright (JIRA)]

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

Karl Wright commented on SOLR-5590:
---

Updating the httpclient version in the ivy versions file does not break 
compilation, at least on the 4x branch.  Running all tests now.

> SolrJ is still on httpcomponents/httpclient version 4.2.x, which has some 
> problems
> --
>
> Key: SOLR-5590
> URL: https://issues.apache.org/jira/browse/SOLR-5590
> Project: Solr
>  Issue Type: Improvement
>Affects Versions: 4.5.1
>Reporter: Karl Wright
>
> SolrJ depends on HttpClient 4.2.x right now, but HttpClient 4.2.x has issues 
> that the ManifoldCF team encountered with handling of form data encoding - 
> issues which are addressed in HttpClient 4.3.x.  We developed a local patch, 
> but Solr will eventually need to go to the new client.  (ManifoldCF would 
> plan to follow shortly thereafter).
> I tried to get Oleg (PMC chair of HttpComponents) to agree to port the fixed 
> code to the 4.2.x stream but he did not want to do that.  So I believe that 
> that avenue is closed.
> See CONNECTORS-623 for a detailed description of the problem.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5580) SOLR-5311 was done without full understanding of the system and must be reverted.

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-5580:
--

bq.You said that I need to create a slice first which I think is not convenient

No I didn't say that. Not creating the slice was fine. I'm saying if you used 
the collection create api it would create the slices upfront.

bq.The last thing ,what is the purpose of the autocreated check 

The autoCreated flag was added to differentiate between a collection created 
using collections API and another one created automatically as a part of a core 
creation

bq. Oh, even there are no any information about the change.
It was designed to work for your usecases . This is a regression . I need to 
test it with your usecase before I can comment further



> SOLR-5311 was done without full understanding of the system and must be 
> reverted.
> -
>
> Key: SOLR-5580
> URL: https://issues.apache.org/jira/browse/SOLR-5580
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.6
> Environment: OS:Red Hat Enterprise Linux Server release 6.4 (Santiago)
> Software:solr 4.6,
>jdk:OpenJDK Runtime Environment (rhel-2.3.4.1.el6_3-x86_64)
> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
>Reporter: YouPeng Yang
>Assignee: Mark Miller
>  Labels: core
> Fix For: 5.0, 4.7, 4.6.1
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> In class org.apache.solr.cloud.Overseer the Line 360:
> -
>   if (sliceName !=null && collectionExists &&  
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice.getReplica(coreNodeName) == null) {
>   log.info("core_deleted . Just return");
>   return state;
> }
>   }
> -
> the slice needs to be checked null .because when create a new core with both 
> explicite shard and coreNodeName, the state.getSlice(collection, sliceName)  
> may return a null.So it needs to be checked ,or there will be an 
> NullpointException
> -
>   if (sliceName !=null && collectionExists &&  
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice != null && slice.getReplica(coreNodeName) == null) {
>   log.info("core_deleted . Just return");
>   return state;
> }
>   }
> -



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5580) SOLR-5311 was done without full understanding of the system and must be reverted.

[YouPeng Yang (JIRA)]

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

YouPeng Yang commented on SOLR-5580:


It needs to make clear that ,I create a collection with the new solr 4.6. 
We deploy the new solr 4.6 in tomcat, and just create a new collection and a 
new core with the same request URL. 
Collections can created when we create a new with no explicit corenodename , I 
can not find the autocreated property in the collection information on 
zookeeper.

Convenient to manage the core,we would like to identify core with explicit 
custom shard name, core name ,collection and corecodename.

  You said that I need to create a slice first which I think is not convenient. 
As all things go well in the old version. I think with no defend your work 
maybe make the lose of solr flexibility and the smooth. 
   
 Anyway , we do hope your work keeps the good feature of solr. 
  Another suggestion ,if you make any change about the good charecter of solr 
,please give some hints in the reference doc or CHANGES.

  The last thing ,what is the purpose of the autocreated check . The 
autocreated property can not be find in solr. I have checked the data in 
zookeeper.  



Oh, even there are no any information about the change. 


发自我的 iPhone

在 2014-1-2，20:04，"Noble Paul (JIRA)"  写道：



> SOLR-5311 was done without full understanding of the system and must be 
> reverted.
> -
>
> Key: SOLR-5580
> URL: https://issues.apache.org/jira/browse/SOLR-5580
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.6
> Environment: OS:Red Hat Enterprise Linux Server release 6.4 (Santiago)
> Software:solr 4.6,
>jdk:OpenJDK Runtime Environment (rhel-2.3.4.1.el6_3-x86_64)
> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
>Reporter: YouPeng Yang
>Assignee: Mark Miller
>  Labels: core
> Fix For: 5.0, 4.7, 4.6.1
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> In class org.apache.solr.cloud.Overseer the Line 360:
> -
>   if (sliceName !=null && collectionExists &&  
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice.getReplica(coreNodeName) == null) {
>   log.info("core_deleted . Just return");
>   return state;
> }
>   }
> -
> the slice needs to be checked null .because when create a new core with both 
> explicite shard and coreNodeName, the state.getSlice(collection, sliceName)  
> may return a null.So it needs to be checked ,or there will be an 
> NullpointException
> -
>   if (sliceName !=null && collectionExists &&  
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice != null && slice.getReplica(coreNodeName) == null) {
>   log.info("core_deleted . Just return");
>   return state;
> }
>   }
> -



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Updated] (SOLR-5598) LanguageIdentifierUpdateProcessor ignores all but the first value of multiValued string fields

[Andreas Hubold (JIRA)]

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

Andreas Hubold updated SOLR-5598:
-

Attachment: SOLR-5598.patch

> LanguageIdentifierUpdateProcessor ignores all but the first value of 
> multiValued string fields
> --
>
> Key: SOLR-5598
> URL: https://issues.apache.org/jira/browse/SOLR-5598
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - LangId
>Affects Versions: 4.5.1
>Reporter: Andreas Hubold
> Attachments: SOLR-5598.patch
>
>
> The LanguageIdentifierUpdateProcessor just uses the first value of the 
> multiValued field to detect the language. 
> Method {{concatFields}} calls {{doc.getFieldValue(fieldName)}} but should 
> instead iterate over {{doc.getFieldValues(fieldName)}}.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Updated] (SOLR-5598) LanguageIdentifierUpdateProcessor ignores all but the first value of multiValued string fields

[Andreas Hubold (JIRA)]

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

Andreas Hubold updated SOLR-5598:
-

Attachment: (was: SOLR-5598.patch)

> LanguageIdentifierUpdateProcessor ignores all but the first value of 
> multiValued string fields
> --
>
> Key: SOLR-5598
> URL: https://issues.apache.org/jira/browse/SOLR-5598
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - LangId
>Affects Versions: 4.5.1
>Reporter: Andreas Hubold
> Attachments: SOLR-5598.patch
>
>
> The LanguageIdentifierUpdateProcessor just uses the first value of the 
> multiValued field to detect the language. 
> Method {{concatFields}} calls {{doc.getFieldValue(fieldName)}} but should 
> instead iterate over {{doc.getFieldValues(fieldName)}}.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Updated] (SOLR-5598) LanguageIdentifierUpdateProcessor ignores all but the first value of multiValued string fields

[Andreas Hubold (JIRA)]

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

Andreas Hubold updated SOLR-5598:
-

Attachment: SOLR-5598.patch

patch with simple fix attached

> LanguageIdentifierUpdateProcessor ignores all but the first value of 
> multiValued string fields
> --
>
> Key: SOLR-5598
> URL: https://issues.apache.org/jira/browse/SOLR-5598
> Project: Solr
>  Issue Type: Bug
>  Components: contrib - LangId
>Affects Versions: 4.5.1
>Reporter: Andreas Hubold
> Attachments: SOLR-5598.patch
>
>
> The LanguageIdentifierUpdateProcessor just uses the first value of the 
> multiValued field to detect the language. 
> Method {{concatFields}} calls {{doc.getFieldValue(fieldName)}} but should 
> instead iterate over {{doc.getFieldValues(fieldName)}}.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Created] (SOLR-5598) LanguageIdentifierUpdateProcessor ignores all but the first value of multiValued string fields

[Andreas Hubold (JIRA)]

Andreas Hubold created SOLR-5598:


 Summary: LanguageIdentifierUpdateProcessor ignores all but the 
first value of multiValued string fields
 Key: SOLR-5598
 URL: https://issues.apache.org/jira/browse/SOLR-5598
 Project: Solr
  Issue Type: Bug
  Components: contrib - LangId
Affects Versions: 4.5.1
Reporter: Andreas Hubold


The LanguageIdentifierUpdateProcessor just uses the first value of the 
multiValued field to detect the language. 

Method {{concatFields}} calls {{doc.getFieldValue(fieldName)}} but should 
instead iterate over {{doc.getFieldValues(fieldName)}}.



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Comment Edited] (SOLR-5580) SOLR-5311 was done without full understanding of the system and must be reverted.

[Noble Paul (JIRA)]

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

Noble Paul edited comment on SOLR-5580 at 1/2/14 12:18 PM:
---

OK, Now I see it. 
(Not the solution , but the diagnosis)
For your usecase,  the collection was created with an older version of Solr. So 
the , property 'autoCreated' is absent from the collection. 

slice would have never been null in a normal case. if you created the system 
with numShards=x the system would have created shard1 to shardx right away. If 
it was a custom collection it would have expected you to create the slice first
 
Do you have multiple replicas or do you just keep one copy of the index? 
How did naming the coreNodeName "Test1" help you instead of "core_node1" ?  I'm 
assuming you somehow encode the data dir in the coreNodeName

If you could encode the data location in coreName itself , it would still work 
, right?


was (Author: noble.paul):
OK, Now I see it. 
(Not the solution , but the diagnosis)
For your usecase,  the collection was created with an older version of Solr. So 
the , property 'autoCreated' is absent from the collection. 

slice would have never been null in a normal case. if you created the system 
with numShards=x the system would have created shard1 to shardx right away. If 
it was a custom collection it would have expected you to create the slice first
 
Do you have multiple replicas or do you just keep one copy of the index? 
How did naming the coreNodeName "Test1" help you instead of "core_node1" ?  I'm 
assuming you somehow encode the data dir in the coreNodeName

> SOLR-5311 was done without full understanding of the system and must be 
> reverted.
> -
>
> Key: SOLR-5580
> URL: https://issues.apache.org/jira/browse/SOLR-5580
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.6
> Environment: OS:Red Hat Enterprise Linux Server release 6.4 (Santiago)
> Software:solr 4.6,
>jdk:OpenJDK Runtime Environment (rhel-2.3.4.1.el6_3-x86_64)
> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
>Reporter: YouPeng Yang
>Assignee: Mark Miller
>  Labels: core
> Fix For: 5.0, 4.7, 4.6.1
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> In class org.apache.solr.cloud.Overseer the Line 360:
> -
>   if (sliceName !=null && collectionExists &&  
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice.getReplica(coreNodeName) == null) {
>   log.info("core_deleted . Just return");
>   return state;
> }
>   }
> -
> the slice needs to be checked null .because when create a new core with both 
> explicite shard and coreNodeName, the state.getSlice(collection, sliceName)  
> may return a null.So it needs to be checked ,or there will be an 
> NullpointException
> -
>   if (sliceName !=null && collectionExists &&  
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice != null && slice.getReplica(coreNodeName) == null) {
>   log.info("core_deleted . Just return");
>   return state;
> }
>   }
> -



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5580) SOLR-5311 was done without full understanding of the system and must be reverted.

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-5580:
--

OK, Now I see it. 
(Not the solution , but the diagnosis)
For your usecase,  the collection was created with an older version of Solr. So 
the , property 'autoCreated' is absent from the collection. 

slice would have never been null in a normal case. The reason being if you 
created the system with numShards=x the system would have created shard1 to 
shardx right away. If it was a custom collection it would have expected you to 
create the slice first
 
Do you have multiple replicas or do you just keep one copy of the index? 
How did naming the coreNodeName "Test1" help you instead of "core_node1" ?  I'm 
assuming you somehow encode the data dir in the coreNodeName

> SOLR-5311 was done without full understanding of the system and must be 
> reverted.
> -
>
> Key: SOLR-5580
> URL: https://issues.apache.org/jira/browse/SOLR-5580
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.6
> Environment: OS:Red Hat Enterprise Linux Server release 6.4 (Santiago)
> Software:solr 4.6,
>jdk:OpenJDK Runtime Environment (rhel-2.3.4.1.el6_3-x86_64)
> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
>Reporter: YouPeng Yang
>Assignee: Mark Miller
>  Labels: core
> Fix For: 5.0, 4.7, 4.6.1
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> In class org.apache.solr.cloud.Overseer the Line 360:
> -
>   if (sliceName !=null && collectionExists &&  
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice.getReplica(coreNodeName) == null) {
>   log.info("core_deleted . Just return");
>   return state;
> }
>   }
> -
> the slice needs to be checked null .because when create a new core with both 
> explicite shard and coreNodeName, the state.getSlice(collection, sliceName)  
> may return a null.So it needs to be checked ,or there will be an 
> NullpointException
> -
>   if (sliceName !=null && collectionExists &&  
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice != null && slice.getReplica(coreNodeName) == null) {
>   log.info("core_deleted . Just return");
>   return state;
> }
>   }
> -



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Comment Edited] (SOLR-5580) SOLR-5311 was done without full understanding of the system and must be reverted.

[Noble Paul (JIRA)]

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

Noble Paul edited comment on SOLR-5580 at 1/2/14 12:04 PM:
---

OK, Now I see it. 
(Not the solution , but the diagnosis)
For your usecase,  the collection was created with an older version of Solr. So 
the , property 'autoCreated' is absent from the collection. 

slice would have never been null in a normal case. if you created the system 
with numShards=x the system would have created shard1 to shardx right away. If 
it was a custom collection it would have expected you to create the slice first
 
Do you have multiple replicas or do you just keep one copy of the index? 
How did naming the coreNodeName "Test1" help you instead of "core_node1" ?  I'm 
assuming you somehow encode the data dir in the coreNodeName


was (Author: noble.paul):
OK, Now I see it. 
(Not the solution , but the diagnosis)
For your usecase,  the collection was created with an older version of Solr. So 
the , property 'autoCreated' is absent from the collection. 

slice would have never been null in a normal case. The reason being if you 
created the system with numShards=x the system would have created shard1 to 
shardx right away. If it was a custom collection it would have expected you to 
create the slice first
 
Do you have multiple replicas or do you just keep one copy of the index? 
How did naming the coreNodeName "Test1" help you instead of "core_node1" ?  I'm 
assuming you somehow encode the data dir in the coreNodeName

> SOLR-5311 was done without full understanding of the system and must be 
> reverted.
> -
>
> Key: SOLR-5580
> URL: https://issues.apache.org/jira/browse/SOLR-5580
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.6
> Environment: OS:Red Hat Enterprise Linux Server release 6.4 (Santiago)
> Software:solr 4.6,
>jdk:OpenJDK Runtime Environment (rhel-2.3.4.1.el6_3-x86_64)
> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
>Reporter: YouPeng Yang
>Assignee: Mark Miller
>  Labels: core
> Fix For: 5.0, 4.7, 4.6.1
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> In class org.apache.solr.cloud.Overseer the Line 360:
> -
>   if (sliceName !=null && collectionExists &&  
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice.getReplica(coreNodeName) == null) {
>   log.info("core_deleted . Just return");
>   return state;
> }
>   }
> -
> the slice needs to be checked null .because when create a new core with both 
> explicite shard and coreNodeName, the state.getSlice(collection, sliceName)  
> may return a null.So it needs to be checked ,or there will be an 
> NullpointException
> -
>   if (sliceName !=null && collectionExists &&  
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice != null && slice.getReplica(coreNodeName) == null) {
>   log.info("core_deleted . Just return");
>   return state;
> }
>   }
> -



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5580) SOLR-5311 was done without full understanding of the system and must be reverted.

[YouPeng Yang (JIRA)]

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

YouPeng Yang commented on SOLR-5580:


Hi

   The create core URL:
http://10.7.23.122:8080/solr/admin/cores?action=CREATE&name=Test1&shard=Test&collection.configName=myconf&schema=schema.xml&config=solrconfigLocal_default.xml&collection=defaultcol&coreNodeName=Test1
We do not have the collection created first. Just create a new collection 
when create the first core of  a collection.
We use the corecodename to make distinguish the cores. As I said,the auto 
created corenodename make it hard to identify which core the datadir belongs to 
. Especially ,there are a lot of cores.

  When a core crashed,as only as the data still exists, we can create a new 
core use the same datadir. It is important when you have a shared storage,such 
as NSF,even hdfs.

 The failover we suppose that we can force multi core to share the same 
data directory. At last , we give up after the some tests . Also, Mr mark 
miller suggests we should not do that.
  

发自我的 iPhone

在 2014-1-2，19:05，"Noble Paul (JIRA)"  写道：



> SOLR-5311 was done without full understanding of the system and must be 
> reverted.
> -
>
> Key: SOLR-5580
> URL: https://issues.apache.org/jira/browse/SOLR-5580
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.6
> Environment: OS:Red Hat Enterprise Linux Server release 6.4 (Santiago)
> Software:solr 4.6,
>jdk:OpenJDK Runtime Environment (rhel-2.3.4.1.el6_3-x86_64)
> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
>Reporter: YouPeng Yang
>Assignee: Mark Miller
>  Labels: core
> Fix For: 5.0, 4.7, 4.6.1
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> In class org.apache.solr.cloud.Overseer the Line 360:
> -
>   if (sliceName !=null && collectionExists &&  
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice.getReplica(coreNodeName) == null) {
>   log.info("core_deleted . Just return");
>   return state;
> }
>   }
> -
> the slice needs to be checked null .because when create a new core with both 
> explicite shard and coreNodeName, the state.getSlice(collection, sliceName)  
> may return a null.So it needs to be checked ,or there will be an 
> NullpointException
> -
>   if (sliceName !=null && collectionExists &&  
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice != null && slice.getReplica(coreNodeName) == null) {
>   log.info("core_deleted . Just return");
>   return state;
> }
>   }
> -



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5580) SOLR-5311 was done without full understanding of the system and must be reverted.

[Noble Paul (JIRA)]

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

Noble Paul commented on SOLR-5580:
--

[~stanleyyang] what is your normal workflow?

* how do you create  your collection? I mean what is a typical command to 
create a collection?
* what is your typical coreNodeName? How does your specific coreNodeName help 
you failover quickly? 
* What will happen if a core comes up after you replace it with another? it 
should be replacing your new core with the old core in that case. How do you 
deal with that?

How about just creating a new core w/o a coreNodeName (only collection name and 
slice name) ? In that case you never need to worry about coreNodeName at all


> SOLR-5311 was done without full understanding of the system and must be 
> reverted.
> -
>
> Key: SOLR-5580
> URL: https://issues.apache.org/jira/browse/SOLR-5580
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.6
> Environment: OS:Red Hat Enterprise Linux Server release 6.4 (Santiago)
> Software:solr 4.6,
>jdk:OpenJDK Runtime Environment (rhel-2.3.4.1.el6_3-x86_64)
> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
>Reporter: YouPeng Yang
>Assignee: Mark Miller
>  Labels: core
> Fix For: 5.0, 4.7, 4.6.1
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> In class org.apache.solr.cloud.Overseer the Line 360:
> -
>   if (sliceName !=null && collectionExists &&  
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice.getReplica(coreNodeName) == null) {
>   log.info("core_deleted . Just return");
>   return state;
> }
>   }
> -
> the slice needs to be checked null .because when create a new core with both 
> explicite shard and coreNodeName, the state.getSlice(collection, sliceName)  
> may return a null.So it needs to be checked ,or there will be an 
> NullpointException
> -
>   if (sliceName !=null && collectionExists &&  
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice != null && slice.getReplica(coreNodeName) == null) {
>   log.info("core_deleted . Just return");
>   return state;
> }
>   }
> -



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5580) SOLR-5311 was done without full understanding of the system and must be reverted.

[YouPeng Yang (JIRA)]

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

YouPeng Yang commented on SOLR-5580:


By the way. We use the corenodename since the solr 4.4. However things go wrong 
when we decide to upgrade to 4.6.  
   It troubles me for a long time. No one gives any help,neither the reference 
doc nor the CHANGES of solr 4.6 do no make any announcement about the change 
,which is bad for users. 

   I even am not clear about what your autocreated check aim at.


发自我的 iPhone

在 2014-1-1，22:40，"Noble Paul (JIRA)"  写道：



> SOLR-5311 was done without full understanding of the system and must be 
> reverted.
> -
>
> Key: SOLR-5580
> URL: https://issues.apache.org/jira/browse/SOLR-5580
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.6
> Environment: OS:Red Hat Enterprise Linux Server release 6.4 (Santiago)
> Software:solr 4.6,
>jdk:OpenJDK Runtime Environment (rhel-2.3.4.1.el6_3-x86_64)
> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
>Reporter: YouPeng Yang
>Assignee: Mark Miller
>  Labels: core
> Fix For: 5.0, 4.7, 4.6.1
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> In class org.apache.solr.cloud.Overseer the Line 360:
> -
>   if (sliceName !=null && collectionExists &&  
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice.getReplica(coreNodeName) == null) {
>   log.info("core_deleted . Just return");
>   return state;
> }
>   }
> -
> the slice needs to be checked null .because when create a new core with both 
> explicite shard and coreNodeName, the state.getSlice(collection, sliceName)  
> may return a null.So it needs to be checked ,or there will be an 
> NullpointException
> -
>   if (sliceName !=null && collectionExists &&  
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice != null && slice.getReplica(coreNodeName) == null) {
>   log.info("core_deleted . Just return");
>   return state;
> }
>   }
> -



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Commented] (SOLR-5580) SOLR-5311 was done without full understanding of the system and must be reverted.

[YouPeng Yang (JIRA)]

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

YouPeng Yang commented on SOLR-5580:


Hi
   The auto created corenodename can not be easy distinguished. We create many 
cores whose datadir is on hdfs. We need the clear corenodename to make failover 
quickly when a core was down. . 


发自我的 iPhone

在 2014-1-1，22:40，"Noble Paul (JIRA)"  写道：



> SOLR-5311 was done without full understanding of the system and must be 
> reverted.
> -
>
> Key: SOLR-5580
> URL: https://issues.apache.org/jira/browse/SOLR-5580
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 4.6
> Environment: OS:Red Hat Enterprise Linux Server release 6.4 (Santiago)
> Software:solr 4.6,
>jdk:OpenJDK Runtime Environment (rhel-2.3.4.1.el6_3-x86_64)
> OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
>Reporter: YouPeng Yang
>Assignee: Mark Miller
>  Labels: core
> Fix For: 5.0, 4.7, 4.6.1
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> In class org.apache.solr.cloud.Overseer the Line 360:
> -
>   if (sliceName !=null && collectionExists &&  
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice.getReplica(coreNodeName) == null) {
>   log.info("core_deleted . Just return");
>   return state;
> }
>   }
> -
> the slice needs to be checked null .because when create a new core with both 
> explicite shard and coreNodeName, the state.getSlice(collection, sliceName)  
> may return a null.So it needs to be checked ,or there will be an 
> NullpointException
> -
>   if (sliceName !=null && collectionExists &&  
> !"true".equals(state.getCollection(collection).getStr("autoCreated"))) {
> Slice slice = state.getSlice(collection, sliceName);
> if (slice != null && slice.getReplica(coreNodeName) == null) {
>   log.info("core_deleted . Just return");
>   return state;
> }
>   }
> -



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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

[jira] [Created] (SOLR-5597) ClassCastException occurs when importing CLOB-fields using SqlEntityProcessor and SortedMapBackedCache

[Henrik Wingerei (JIRA)]

Henrik Wingerei created SOLR-5597:
-

 Summary: ClassCastException occurs when importing CLOB-fields 
using SqlEntityProcessor and SortedMapBackedCache
 Key: SOLR-5597
 URL: https://issues.apache.org/jira/browse/SOLR-5597
 Project: Solr
  Issue Type: Bug
  Components: contrib - DataImportHandler
Affects Versions: 4.6
Reporter: Henrik Wingerei


Using the SqlEntityProcessor with the SortedMapBackedCache as cache 
implementation, gives the following ClassCastException when trying to import a 
field of type oracle.sql.CLOB.

2014-01-02 09:32:19,143 [ERROR] [Thread-54] Exception in entity : 
:java.lang.ClassCastException: oracle.sql.CLOB cannot be cast to 
java.lang.Comparable
at java.util.TreeMap.getEntry(TreeMap.java:325)
at java.util.TreeMap.get(TreeMap.java:255)
at 
org.apache.solr.handler.dataimport.SortedMapBackedCache.add(SortedMapBackedCache.java:61)
at 
org.apache.solr.handler.dataimport.DIHCacheSupport.populateCache(DIHCacheSupport.java:124)
at 
org.apache.solr.handler.dataimport.DIHCacheSupport.getSimpleCacheData(DIHCacheSupport.java:199)
at 
org.apache.solr.handler.dataimport.DIHCacheSupport.getCacheData(DIHCacheSupport.java:147)
at 
org.apache.solr.handler.dataimport.EntityProcessorBase.getNext(EntityProcessorBase.java:129)
at 
org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:75)
at 
org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:243)
at 
org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:469)
at 
org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:495)
at 
org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:408)
at 
org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:323)
at 
org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:231)
at 
org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:411)
at 
org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:476)
at 
org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:457)
-- org.apache.solr.handler.dataimport.EntityProcessorWrapper

It seems that this occurs because the SortedMapBackedCache uses a 
java.util.TreeMap as the underlying cache, and TreeMap requires that all 
elements implements the java.lang.Comparable interface. However oracle.sql.CLOB 
does not implement Comparable and the import fails when the TreeMap 
implementation tries to cast the element to a Comparable (this occurs on line 
325 in TreeMap.java - java version 1.6.0_33).



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)

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