date:20130817

2013-08-17 Thread ASF subversion and git services (JIRA)


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

Han Jiang commented on LUCENE-5179:
---

Thanks! I'll commit.

 Refactoring on PostingsWriterBase for delta-encoding
 

 Key: LUCENE-5179
 URL: https://issues.apache.org/jira/browse/LUCENE-5179
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Han Jiang
Assignee: Han Jiang
 Fix For: 5.0, 4.5

 Attachments: LUCENE-5179.patch


 A further step from LUCENE-5029.
 The short story is, previous API change brings two problems:
 * it somewhat breaks backward compatibility: although we can still read old 
 format,
   we can no longer reproduce it;
 * pulsing codec have problem with it.
 And long story...
 With the change, current PostingsBase API will be like this:
 * term dict tells PBF we start a new term (via startTerm());
 * PBF adds docs, positions and other postings data;
 * term dict tells PBF all the data for current term is completed (via 
 finishTerm()),
   then PBF returns the metadata for current term (as long[] and byte[]);
 * term dict might buffer all the metadata in an ArrayList. when all the term 
 is collected,
   it then decides how those metadata will be located on disk.
 So after the API change, PBF no longer have that annoying 'flushTermBlock', 
 and instead
 term dict maintains the term, metadata list.
 However, for each term we'll now write long[] blob before byte[], so the 
 index format is not consistent with pre-4.5.
 like in Lucne41, the metadata can be written as longA,bytesA,longB, but now 
 we have to write as longA,longB,bytesA.
 Another problem is, pulsing codec cannot tell wrapped PBF how the metadata is 
 delta-encoded, after all
 PulsingPostingsWriter is only a PBF.
 For example, we have terms=[a, a1, a2, b, b1 b2] and 
 itemsInBlock=2, so theoretically
 we'll finally have three blocks in BTTR: [a b]  [a1 a2]  [b1 b2], 
 with this
 approach, the metadata of term b is delta encoded base on metadata of a. 
 but when term dict tells
 PBF to finishTerm(b), it might silly do the delta encode base on term a2.
 So I think maybe we can introduce a method 'encodeTerm(long[], DataOutput 
 out, FieldInfo, TermState, boolean absolute)',
 so that during metadata flush, we can control how current term is written? 
 And the term dict will buffer TermState, which
 implicitly holds metadata like we do in PBReader side.
 For example, if we want to reproduce old lucene41 format , we can simple set 
 longsSize==0, then PBF
 writes the old format (longA,bytesA,longB) to DataOutput, and the compatible 
 issue is solved.
 For pulsing codec, it will also be able to tell lower level how to encode 
 metadata.

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

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

[jira] [Commented] (LUCENE-5179) Refactoring on PostingsWriterBase for delta-encoding


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

ASF subversion and git services commented on LUCENE-5179:
-

Commit 1514978 from [~billy] in branch 'dev/branches/lucene3069'
[ https://svn.apache.org/r1514978 ]

LUCENE-5179: refactoring on PostingsWriterBase for delta-encoding

 Refactoring on PostingsWriterBase for delta-encoding
 

 Key: LUCENE-5179
 URL: https://issues.apache.org/jira/browse/LUCENE-5179
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Han Jiang
Assignee: Han Jiang
 Fix For: 5.0, 4.5

 Attachments: LUCENE-5179.patch


 A further step from LUCENE-5029.
 The short story is, previous API change brings two problems:
 * it somewhat breaks backward compatibility: although we can still read old 
 format,
   we can no longer reproduce it;
 * pulsing codec have problem with it.
 And long story...
 With the change, current PostingsBase API will be like this:
 * term dict tells PBF we start a new term (via startTerm());
 * PBF adds docs, positions and other postings data;
 * term dict tells PBF all the data for current term is completed (via 
 finishTerm()),
   then PBF returns the metadata for current term (as long[] and byte[]);
 * term dict might buffer all the metadata in an ArrayList. when all the term 
 is collected,
   it then decides how those metadata will be located on disk.
 So after the API change, PBF no longer have that annoying 'flushTermBlock', 
 and instead
 term dict maintains the term, metadata list.
 However, for each term we'll now write long[] blob before byte[], so the 
 index format is not consistent with pre-4.5.
 like in Lucne41, the metadata can be written as longA,bytesA,longB, but now 
 we have to write as longA,longB,bytesA.
 Another problem is, pulsing codec cannot tell wrapped PBF how the metadata is 
 delta-encoded, after all
 PulsingPostingsWriter is only a PBF.
 For example, we have terms=[a, a1, a2, b, b1 b2] and 
 itemsInBlock=2, so theoretically
 we'll finally have three blocks in BTTR: [a b]  [a1 a2]  [b1 b2], 
 with this
 approach, the metadata of term b is delta encoded base on metadata of a. 
 but when term dict tells
 PBF to finishTerm(b), it might silly do the delta encode base on term a2.
 So I think maybe we can introduce a method 'encodeTerm(long[], DataOutput 
 out, FieldInfo, TermState, boolean absolute)',
 so that during metadata flush, we can control how current term is written? 
 And the term dict will buffer TermState, which
 implicitly holds metadata like we do in PBReader side.
 For example, if we want to reproduce old lucene41 format , we can simple set 
 longsSize==0, then PBF
 writes the old format (longA,bytesA,longB) to DataOutput, and the compatible 
 issue is solved.
 For pulsing codec, it will also be able to tell lower level how to encode 
 metadata.

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

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

[jira] [Updated] (LUCENE-5179) Refactoring on PostingsWriterBase for delta-encoding


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

Han Jiang updated LUCENE-5179:
--

Issue Type: Sub-task  (was: Improvement)
Parent: LUCENE-3069

 Refactoring on PostingsWriterBase for delta-encoding
 

 Key: LUCENE-5179
 URL: https://issues.apache.org/jira/browse/LUCENE-5179
 Project: Lucene - Core
  Issue Type: Sub-task
Reporter: Han Jiang
Assignee: Han Jiang
 Fix For: 5.0, 4.5

 Attachments: LUCENE-5179.patch


 A further step from LUCENE-5029.
 The short story is, previous API change brings two problems:
 * it somewhat breaks backward compatibility: although we can still read old 
 format,
   we can no longer reproduce it;
 * pulsing codec have problem with it.
 And long story...
 With the change, current PostingsBase API will be like this:
 * term dict tells PBF we start a new term (via startTerm());
 * PBF adds docs, positions and other postings data;
 * term dict tells PBF all the data for current term is completed (via 
 finishTerm()),
   then PBF returns the metadata for current term (as long[] and byte[]);
 * term dict might buffer all the metadata in an ArrayList. when all the term 
 is collected,
   it then decides how those metadata will be located on disk.
 So after the API change, PBF no longer have that annoying 'flushTermBlock', 
 and instead
 term dict maintains the term, metadata list.
 However, for each term we'll now write long[] blob before byte[], so the 
 index format is not consistent with pre-4.5.
 like in Lucne41, the metadata can be written as longA,bytesA,longB, but now 
 we have to write as longA,longB,bytesA.
 Another problem is, pulsing codec cannot tell wrapped PBF how the metadata is 
 delta-encoded, after all
 PulsingPostingsWriter is only a PBF.
 For example, we have terms=[a, a1, a2, b, b1 b2] and 
 itemsInBlock=2, so theoretically
 we'll finally have three blocks in BTTR: [a b]  [a1 a2]  [b1 b2], 
 with this
 approach, the metadata of term b is delta encoded base on metadata of a. 
 but when term dict tells
 PBF to finishTerm(b), it might silly do the delta encode base on term a2.
 So I think maybe we can introduce a method 'encodeTerm(long[], DataOutput 
 out, FieldInfo, TermState, boolean absolute)',
 so that during metadata flush, we can control how current term is written? 
 And the term dict will buffer TermState, which
 implicitly holds metadata like we do in PBReader side.
 For example, if we want to reproduce old lucene41 format , we can simple set 
 longsSize==0, then PBF
 writes the old format (longA,bytesA,longB) to DataOutput, and the compatible 
 issue is solved.
 For pulsing codec, it will also be able to tell lower level how to encode 
 metadata.

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

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

[jira] [Commented] (SOLR-5170) Spatial multi-value distance sort via DocValues

2013-08-17 Thread Robert Muir (JIRA)


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

Robert Muir commented on SOLR-5170:
---

Err, that conversation is both wrong and totally irrelevant. Its based on some 
bogus apples and oranges faceting benchmarks those guys did before: where they 
spent lots of time optimizing that silly facet vint decode, whereas sortedset 
is the simplest thing that can work and was done in like 2 days.

Ive said it before, I think its good to reinvestigate removing the BINARY type 
completely. If i have to go optimize some loops somewhere in order to make that 
happen, fine, its worth it to me to remove this useless shit. 

I don't think you should refactor solr around broken assumptions and misleading 
benchmarks.

 Spatial multi-value distance sort via DocValues
 ---

 Key: SOLR-5170
 URL: https://issues.apache.org/jira/browse/SOLR-5170
 Project: Solr
  Issue Type: New Feature
  Components: spatial
Reporter: David Smiley
Assignee: David Smiley
 Attachments: SOLR-5170_spatial_multi-value_sort_via_docvalues.patch


 The attached patch implements spatial multi-value distance sorting.  In other 
 words, a document can have more than one point per field, and using a 
 provided function query, it will return the distance to the closest point.  
 The data goes into binary DocValues, and as-such it's pretty friendly to 
 realtime search requirements, and it only uses 8 bytes per point.

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

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

[jira] [Closed] (LUCENE-5179) Refactoring on PostingsWriterBase for delta-encoding


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

Han Jiang closed LUCENE-5179.
-


 Refactoring on PostingsWriterBase for delta-encoding
 

 Key: LUCENE-5179
 URL: https://issues.apache.org/jira/browse/LUCENE-5179
 Project: Lucene - Core
  Issue Type: Sub-task
Reporter: Han Jiang
Assignee: Han Jiang
 Fix For: 5.0, 4.5

 Attachments: LUCENE-5179.patch


 A further step from LUCENE-5029.
 The short story is, previous API change brings two problems:
 * it somewhat breaks backward compatibility: although we can still read old 
 format,
   we can no longer reproduce it;
 * pulsing codec have problem with it.
 And long story...
 With the change, current PostingsBase API will be like this:
 * term dict tells PBF we start a new term (via startTerm());
 * PBF adds docs, positions and other postings data;
 * term dict tells PBF all the data for current term is completed (via 
 finishTerm()),
   then PBF returns the metadata for current term (as long[] and byte[]);
 * term dict might buffer all the metadata in an ArrayList. when all the term 
 is collected,
   it then decides how those metadata will be located on disk.
 So after the API change, PBF no longer have that annoying 'flushTermBlock', 
 and instead
 term dict maintains the term, metadata list.
 However, for each term we'll now write long[] blob before byte[], so the 
 index format is not consistent with pre-4.5.
 like in Lucne41, the metadata can be written as longA,bytesA,longB, but now 
 we have to write as longA,longB,bytesA.
 Another problem is, pulsing codec cannot tell wrapped PBF how the metadata is 
 delta-encoded, after all
 PulsingPostingsWriter is only a PBF.
 For example, we have terms=[a, a1, a2, b, b1 b2] and 
 itemsInBlock=2, so theoretically
 we'll finally have three blocks in BTTR: [a b]  [a1 a2]  [b1 b2], 
 with this
 approach, the metadata of term b is delta encoded base on metadata of a. 
 but when term dict tells
 PBF to finishTerm(b), it might silly do the delta encode base on term a2.
 So I think maybe we can introduce a method 'encodeTerm(long[], DataOutput 
 out, FieldInfo, TermState, boolean absolute)',
 so that during metadata flush, we can control how current term is written? 
 And the term dict will buffer TermState, which
 implicitly holds metadata like we do in PBReader side.
 For example, if we want to reproduce old lucene41 format , we can simple set 
 longsSize==0, then PBF
 writes the old format (longA,bytesA,longB) to DataOutput, and the compatible 
 issue is solved.
 For pulsing codec, it will also be able to tell lower level how to encode 
 metadata.

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

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

[jira] [Resolved] (LUCENE-5179) Refactoring on PostingsWriterBase for delta-encoding


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

Han Jiang resolved LUCENE-5179.
---

   Resolution: Fixed
Lucene Fields: New,Patch Available  (was: New)

 Refactoring on PostingsWriterBase for delta-encoding
 

 Key: LUCENE-5179
 URL: https://issues.apache.org/jira/browse/LUCENE-5179
 Project: Lucene - Core
  Issue Type: Sub-task
Reporter: Han Jiang
Assignee: Han Jiang
 Fix For: 5.0, 4.5

 Attachments: LUCENE-5179.patch


 A further step from LUCENE-5029.
 The short story is, previous API change brings two problems:
 * it somewhat breaks backward compatibility: although we can still read old 
 format,
   we can no longer reproduce it;
 * pulsing codec have problem with it.
 And long story...
 With the change, current PostingsBase API will be like this:
 * term dict tells PBF we start a new term (via startTerm());
 * PBF adds docs, positions and other postings data;
 * term dict tells PBF all the data for current term is completed (via 
 finishTerm()),
   then PBF returns the metadata for current term (as long[] and byte[]);
 * term dict might buffer all the metadata in an ArrayList. when all the term 
 is collected,
   it then decides how those metadata will be located on disk.
 So after the API change, PBF no longer have that annoying 'flushTermBlock', 
 and instead
 term dict maintains the term, metadata list.
 However, for each term we'll now write long[] blob before byte[], so the 
 index format is not consistent with pre-4.5.
 like in Lucne41, the metadata can be written as longA,bytesA,longB, but now 
 we have to write as longA,longB,bytesA.
 Another problem is, pulsing codec cannot tell wrapped PBF how the metadata is 
 delta-encoded, after all
 PulsingPostingsWriter is only a PBF.
 For example, we have terms=[a, a1, a2, b, b1 b2] and 
 itemsInBlock=2, so theoretically
 we'll finally have three blocks in BTTR: [a b]  [a1 a2]  [b1 b2], 
 with this
 approach, the metadata of term b is delta encoded base on metadata of a. 
 but when term dict tells
 PBF to finishTerm(b), it might silly do the delta encode base on term a2.
 So I think maybe we can introduce a method 'encodeTerm(long[], DataOutput 
 out, FieldInfo, TermState, boolean absolute)',
 so that during metadata flush, we can control how current term is written? 
 And the term dict will buffer TermState, which
 implicitly holds metadata like we do in PBReader side.
 For example, if we want to reproduce old lucene41 format , we can simple set 
 longsSize==0, then PBF
 writes the old format (longA,bytesA,longB) to DataOutput, and the compatible 
 issue is solved.
 For pulsing codec, it will also be able to tell lower level how to encode 
 metadata.

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

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

[jira] [Commented] (SOLR-5168) BJQParserTest reproducible failures

2013-08-17 Thread Mikhail Khludnev (JIRA)


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

Mikhail Khludnev commented on SOLR-5168:


ok. checked it again. I propose either apply that one-liner patch or trigger 
forceMerge() in test. After that testGrandChildren() still fails and it's 
fairly reasonable, though gives a subject for considerations:

right now BJQParserTest.addGrandChildren() places _grand children_ before 
_their parents_ (i.e children). It sounds like user is aware of physical layout 
which is necessary for bjq and enforces it. Unfortunately, 
AddUpdateCommand.flatten(SolrInputDocument) reverses docs in a block quite 
unreasonably. 
So, there might be two vision on it:
* we can allow users to be aware about physical layout of docs, and need to 
remove useless reverse in AddUpdateCommand.flatten() - not a big deal;
* we don't want users to rely, and oblige them to nest grand children into 
children as well as children are nested into parents. (in this case, how to 
prevent them from relying on reversing?)
Please raise a separate issue for testGrandChildren(). it can be temporarily 
ignored for a while. 

Thanks. 

 BJQParserTest reproducible failures
 ---

 Key: SOLR-5168
 URL: https://issues.apache.org/jira/browse/SOLR-5168
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man
Assignee: Yonik Seeley
 Attachments: BJQTest.patch


 two recent Jenkins builds have uncovered some test seeds that cause failures 
 in multiple test methods in BJQParserTest.  These seeds reproduce reliably 
 (as of trunk r1514815) ...
 {noformat}
 ant test  -Dtestcase=BJQParserTest -Dtests.seed=7A613F321CE87F5B 
 -Dtests.multiplier=3 -Dtests.slow=true
 ant test  -Dtestcase=BJQParserTest -Dtests.seed=1DC8055F837E437E 
 -Dtests.multiplier=2 -Dtests.nightly=true -Dtests.slow=true 
 {noformat}

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

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

[jira] [Commented] (SOLR-4909) Solr and IndexReader Re-opening on Replication Slave

2013-08-17 Thread Robert Muir (JIRA)


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

Robert Muir commented on SOLR-4909:
---

Hi Michael: 

So the idea here is an explicit option that allows to not reopen from 
indexwriter for these replication slaves (because a new IW is created when 
replication happens?)

This piece one concerns me:
{quote}
There is logic in SolrCore.openNewSearcher to open a new reader rather than 
re-open should the underlying directory instance in the current reader not 
match that of the new index writer as that means that a full copy of the index 
was downloaded into a new directory, as would happen during replication if the 
slave's version was ahead of the master's.
{quote}

{noformat}
+// during a replication that pulls the complete index into a new 
physical directory
+// the reader cannot be reopened and must be newly opened using 
the same directory as the writer
+if(writer != null  
!currentReader.directory().equals(writer.get().getDirectory())) {
{noformat}

Are you sure this really does what you want? I don't think anybody 
implements/tests equals() on Directory implementations, and if so I'm not sure 
what the semantics would be. Looking at other stuff around this code that tries 
to do similar things, it seems they are comparing strings (representing the 
directory path).

 Solr and IndexReader Re-opening on Replication Slave
 

 Key: SOLR-4909
 URL: https://issues.apache.org/jira/browse/SOLR-4909
 Project: Solr
  Issue Type: Improvement
  Components: replication (java), search
Affects Versions: 4.3
Reporter: Michael Garski
 Fix For: 4.5, 5.0

 Attachments: SOLR-4909-demo.patch, SOLR-4909_fix.patch, 
 SOLR-4909_v2.patch


 I've been experimenting with caching filter data per segment in Solr using a 
 CachingWrapperFilter  FilteredQuery within a custom query parser (as 
 suggested by [~yo...@apache.org] in SOLR-3763) and encountered situations 
 where the value of getCoreCacheKey() on the AtomicReader for each segment can 
 change for a given segment on disk when the searcher is reopened. As 
 CachingWrapperFilter uses the value of the segment's getCoreCacheKey() as the 
 key in the cache, there are situations where the data cached on that segment 
 is not reused when the segment on disk is still part of the index. This 
 affects the Lucene field cache and field value caches as well as they are 
 cached per segment.
 When Solr first starts it opens the searcher's underlying DirectoryReader in 
 StandardIndexReaderFactory.newReader by calling 
 DirectoryReader.open(indexDir, termInfosIndexDivisor), and the reader is 
 subsequently reopened in SolrCore.openNewSearcher by calling 
 DirectoryReader.openIfChanged(currentReader, writer.get(), true). The act of 
 reopening the reader with the writer when it was first opened without a 
 writer results in the value of getCoreCacheKey() changing on each of the 
 segments even though some of the segments have not changed. Depending on the 
 role of the Solr server, this has different effects:
 * On a SolrCloud node or free-standing index and search server the segment 
 cache is invalidated during the first DirectoryReader reopen - subsequent 
 reopens use the same IndexWriter instance and as such the value of 
 getCoreCacheKey() on each segment does not change so the cache is retained. 
 * For a master-slave replication set up the segment cache invalidation occurs 
 on the slave during every replication as the index is reopened using a new 
 IndexWriter instance which results in the value of getCoreCacheKey() changing 
 on each segment when the DirectoryReader is reopened using a different 
 IndexWriter instance.
 I can think of a few approaches to alter the re-opening behavior to allow 
 reuse of segment level caches in both cases, and I'd like to get some input 
 on other ideas before digging in:
 * To change the cloud node/standalone first commit issue it might be possible 
 to create the UpdateHandler and IndexWriter before the DirectoryReader, and 
 use the writer to open the reader. There is a comment in the SolrCore 
 constructor by [~yo...@apache.org] that the searcher should be opened before 
 the update handler so that may not be an acceptable approach. 
 * To change the behavior of a slave in a replication set up, one solution 
 would be to not open a writer from the SnapPuller when the new index is 
 retrieved if the core is enabled as a slave only. The writer is needed on a 
 server configured as a master  slave that is functioning as a replication 
 repeater so downstream slaves can see the changes in the index and retrieve 
 them.
 I'll attach a unit test that demonstrates the behavior of reopening the

[jira] [Created] (SOLR-5171) Unmatched tags in SOLR Admin gui, breaks in IE10.

Joseph L Howard created SOLR-5171:
-

 Summary: Unmatched tags in SOLR Admin gui, breaks in IE10.
 Key: SOLR-5171
 URL: https://issues.apache.org/jira/browse/SOLR-5171
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.4
 Environment: Windows7 and 8, IE10 Browser, Windows Server, Centos 
Reporter: Joseph L Howard
Priority: Minor
 Fix For: 4.5


Solr Admin gui has invalid tags, and unmatched tags that break the page in IE 
10. New to solr, so I haven't fixed this yet. 


Do you run a validator on the pages? I use total validator. 

The line numbers refer to lines in the original source.
Any with a line number of '0' are implicit tags added by Total Validator:
   1 !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01//EN 
http://www.w3.org/TR/html4/strict.dtd;
   2 next problemprevious problemW864 [WCAG 2.0 3.1.1 (A)] Use the 'lang' or 
'xml:lang' attribute to denote the primary language of the 
  document:
 html
  21   head
  23 title
  23   Solr Admin
  23 /title
  25 link rel=icon type=image/ico href=img/favicon.ico?_=4.4.0
  27 link rel=stylesheet type=text/css 
href=css/styles/common.css?_=4.4.0
  28 link rel=stylesheet type=text/css 
href=css/styles/analysis.css?_=4.4.0
  29 link rel=stylesheet type=text/css 
href=css/styles/cloud.css?_=4.4.0
  30 link rel=stylesheet type=text/css 
href=css/styles/cores.css?_=4.4.0
  31 link rel=stylesheet type=text/css 
href=css/styles/dashboard.css?_=4.4.0
  32 link rel=stylesheet type=text/css 
href=css/styles/dataimport.css?_=4.4.0
  33 link rel=stylesheet type=text/css 
href=css/styles/index.css?_=4.4.0
  34 link rel=stylesheet type=text/css 
href=css/styles/java-properties.css?_=4.4.0
  35 link rel=stylesheet type=text/css 
href=css/styles/logging.css?_=4.4.0
  36 link rel=stylesheet type=text/css 
href=css/styles/menu.css?_=4.4.0
  37 link rel=stylesheet type=text/css 
href=css/styles/plugins.css?_=4.4.0
  38 link rel=stylesheet type=text/css 
href=css/styles/documents.css?_=4.4.0
  39 link rel=stylesheet type=text/css 
href=css/styles/query.css?_=4.4.0
  40 link rel=stylesheet type=text/css 
href=css/styles/replication.css?_=4.4.0
  41 link rel=stylesheet type=text/css 
href=css/styles/schema-browser.css?_=4.4.0
  42 link rel=stylesheet type=text/css 
href=css/styles/threads.css?_=4.4.0
  43 link rel=stylesheet type=text/css href=css/chosen.css?_=4.4.0
  45 script type=text/javascript
  52 /script
  54   /head
  55   body
  57 div id=wrapper
  59   div id=header
  61 a href=./ id=solr
  61   span
  61 Apache SOLR
  61   /span
  61 /a
  63 p id=environment
  63   nbsp;
  63 /p
  65   /div
  67   div id=main class=clearfix
  69 div id=init-failures
  71 next problemprevious problemP883 [WCAG 2.0 1.3.1 (A)] Nest headings 
properly (H1  H2  H3):
   h2
  71 SolrCore Initialization Failures
  71   /h2
  72 next problemprevious problemP892 [WCAG 2.0 1.3.1 (A)] Use CSS for 
presentation effects:
   ul
  72 next problemprevious problemE610 One or more of the following tags are 
missing from within the enclosing tag: li 
   /ul
  73   p
  73 Please check your logs for more information
  73   /p
  75 /div
  77 div id=content-wrapper
  78   div id=content
  79 nbsp;
  82   /div
  83 /div
  85 div id=menu-wrapper
  86   div
  88 ul id=menu
  90   li id=index class=global
  90 p
  90 next problemprevious problemE049 No matching anchor name:
   a href=#/
  90 Dashboard
  90   /a
  90 /p
  90   /li
  92   li id=logging class=global
  92 p
  92 next problemprevious problemE049 No matching anchor name:
   a href=#/~logging
  92 Logging
  92   /a
  92 /p
  93 ul
  94   li class=level
  94 next problemprevious problemE049 No matching anchor name:
 a href=#/~logging/level
  94   Level
  94 /a
  94   /li
  95 /ul
  96   /li
  98   li id=cloud class=global optional
  98 p
  98 next problemprevious problemE049 No matching anchor name:
   a href=#/~cloud
  98 Cloud
  98   /a
  98 /p
  99 ul
 100   li class=tree
 100 next problemprevious problemE049 No matching anchor name:

[jira] [Commented] (SOLR-4909) Solr and IndexReader Re-opening on Replication Slave

2013-08-17 Thread Robert Muir (JIRA)


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

Robert Muir commented on SOLR-4909:
---

By the way (since i now look at your new config variable and i feel i somewhat 
made this situation worse/more confusing with SOLR-4764), i think its not ideal 
to have two config variables:
1. reopenReaders 
2. createReaderFromWriter

otherwise this would create 4 possibilities of behavior and I dont see a use 
case for 2 of them. (even if you are not using NRT and opening straight from 
the directory, why would you not want to reuse same segments when its possible)

I think it would be much easier if there was just a single config variable like 
nrt=true/false and this determines if new readers are opened from the 
directory or indexwriter (IndexReaderFactory.newReader(Directory) vs 
IndexReaderFactory.newReader(IndexWriter), and otherwise 
DirectoryReader.doOpenIfChanged(existingReader) is always called (which does 
the right thing because it remembers its 'type').

This could also prevent further user confusion: e.g. if nrt=false, errors 
should be issued if someone tries to do softcommit or configure autosoftcommit 
in solrconfig.xml. 


 Solr and IndexReader Re-opening on Replication Slave
 

 Key: SOLR-4909
 URL: https://issues.apache.org/jira/browse/SOLR-4909
 Project: Solr
  Issue Type: Improvement
  Components: replication (java), search
Affects Versions: 4.3
Reporter: Michael Garski
 Fix For: 4.5, 5.0

 Attachments: SOLR-4909-demo.patch, SOLR-4909_fix.patch, 
 SOLR-4909_v2.patch


 I've been experimenting with caching filter data per segment in Solr using a 
 CachingWrapperFilter  FilteredQuery within a custom query parser (as 
 suggested by [~yo...@apache.org] in SOLR-3763) and encountered situations 
 where the value of getCoreCacheKey() on the AtomicReader for each segment can 
 change for a given segment on disk when the searcher is reopened. As 
 CachingWrapperFilter uses the value of the segment's getCoreCacheKey() as the 
 key in the cache, there are situations where the data cached on that segment 
 is not reused when the segment on disk is still part of the index. This 
 affects the Lucene field cache and field value caches as well as they are 
 cached per segment.
 When Solr first starts it opens the searcher's underlying DirectoryReader in 
 StandardIndexReaderFactory.newReader by calling 
 DirectoryReader.open(indexDir, termInfosIndexDivisor), and the reader is 
 subsequently reopened in SolrCore.openNewSearcher by calling 
 DirectoryReader.openIfChanged(currentReader, writer.get(), true). The act of 
 reopening the reader with the writer when it was first opened without a 
 writer results in the value of getCoreCacheKey() changing on each of the 
 segments even though some of the segments have not changed. Depending on the 
 role of the Solr server, this has different effects:
 * On a SolrCloud node or free-standing index and search server the segment 
 cache is invalidated during the first DirectoryReader reopen - subsequent 
 reopens use the same IndexWriter instance and as such the value of 
 getCoreCacheKey() on each segment does not change so the cache is retained. 
 * For a master-slave replication set up the segment cache invalidation occurs 
 on the slave during every replication as the index is reopened using a new 
 IndexWriter instance which results in the value of getCoreCacheKey() changing 
 on each segment when the DirectoryReader is reopened using a different 
 IndexWriter instance.
 I can think of a few approaches to alter the re-opening behavior to allow 
 reuse of segment level caches in both cases, and I'd like to get some input 
 on other ideas before digging in:
 * To change the cloud node/standalone first commit issue it might be possible 
 to create the UpdateHandler and IndexWriter before the DirectoryReader, and 
 use the writer to open the reader. There is a comment in the SolrCore 
 constructor by [~yo...@apache.org] that the searcher should be opened before 
 the update handler so that may not be an acceptable approach. 
 * To change the behavior of a slave in a replication set up, one solution 
 would be to not open a writer from the SnapPuller when the new index is 
 retrieved if the core is enabled as a slave only. The writer is needed on a 
 server configured as a master  slave that is functioning as a replication 
 repeater so downstream slaves can see the changes in the index and retrieve 
 them.
 I'll attach a unit test that demonstrates the behavior of reopening the 
 DirectoryReader and it's effects on the value of getCoreCacheKey. My 
 assumption is that the behavior of Lucene during the various reader reopen 
 operations is correct and that

[jira] [Updated] (LUCENE-3849) position increments should be implemented by TokenStream.end()

2013-08-17 Thread Michael McCandless (JIRA)


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

Michael McCandless updated LUCENE-3849:
---

Attachment: LUCENE-3849.patch

New patch, syncing up to trunk, and fixing various tokenizers that had bugs ... 
tests pass.

 position increments should be implemented by TokenStream.end()
 --

 Key: LUCENE-3849
 URL: https://issues.apache.org/jira/browse/LUCENE-3849
 Project: Lucene - Core
  Issue Type: Bug
Affects Versions: 3.6, 4.0-ALPHA
Reporter: Robert Muir
 Attachments: LUCENE-3849.patch, LUCENE-3849.patch, LUCENE-3849.patch


 if you have pages of a book as multivalued fields, with the default position 
 increment gap
 of analyzer.java (0), phrase queries won't work across pages if one ends with 
 stopword(s).
 This is because the 'trailing holes' are not taken into account in end(). So 
 I think in
 TokenStream.end(), subclasses of FilteringTokenFilter (e.g. stopfilter) 
 should do:
 {code}
 super.end();
 posIncAtt += skippedPositions;
 {code}
 One problem is that these filters need to 'add' to the posinc, but currently 
 nothing clears
 the attributes for end() [they are dirty, except offset which is set by the 
 tokenizer].
 Also the indexer should be changed to pull posIncAtt from end().

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

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

[jira] [Commented] (SOLR-5171) Unmatched tags in SOLR Admin gui, breaks in IE10.

2013-08-17 Thread Stefan Matheis (steffkes) (JIRA)


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

Stefan Matheis (steffkes) commented on SOLR-5171:
-

[~howardj] and which exactly does not break the UI using IE10? Sounds all like 
nice, if you would do .. things. anchors on the same site can't match (taken 
only the html into account) .. empty tags are there to be filled via javascript 
.. and {{data-*}} should be fine, perhaps we should give the UI10 another 
doctype, but normal browser-behaviour would be ignore what you don't know.

so, to ask again .. how exactly does the UI break? can you use the (however 
they call it now) developer tools, javascript console, .. to provide more 
information?

 Unmatched tags in SOLR Admin gui, breaks in IE10.
 -

 Key: SOLR-5171
 URL: https://issues.apache.org/jira/browse/SOLR-5171
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.4
 Environment: Windows7 and 8, IE10 Browser, Windows Server, Centos 
Reporter: Joseph L Howard
Priority: Minor
  Labels: patch
 Fix For: 4.5


 Solr Admin gui has invalid tags, and unmatched tags that break the page in IE 
 10. New to solr, so I haven't fixed this yet. 
 Do you run a validator on the pages? I use total validator. 
 The line numbers refer to lines in the original source.
 Any with a line number of '0' are implicit tags added by Total Validator:
1 !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01//EN 
 http://www.w3.org/TR/html4/strict.dtd;
2 next problemprevious problemW864 [WCAG 2.0 3.1.1 (A)] Use the 'lang' or 
 'xml:lang' attribute to denote the primary language of the 
   document:
  html
   21   head
   23 title
   23   Solr Admin
   23 /title
   25 link rel=icon type=image/ico href=img/favicon.ico?_=4.4.0
   27 link rel=stylesheet type=text/css 
 href=css/styles/common.css?_=4.4.0
   28 link rel=stylesheet type=text/css 
 href=css/styles/analysis.css?_=4.4.0
   29 link rel=stylesheet type=text/css 
 href=css/styles/cloud.css?_=4.4.0
   30 link rel=stylesheet type=text/css 
 href=css/styles/cores.css?_=4.4.0
   31 link rel=stylesheet type=text/css 
 href=css/styles/dashboard.css?_=4.4.0
   32 link rel=stylesheet type=text/css 
 href=css/styles/dataimport.css?_=4.4.0
   33 link rel=stylesheet type=text/css 
 href=css/styles/index.css?_=4.4.0
   34 link rel=stylesheet type=text/css 
 href=css/styles/java-properties.css?_=4.4.0
   35 link rel=stylesheet type=text/css 
 href=css/styles/logging.css?_=4.4.0
   36 link rel=stylesheet type=text/css 
 href=css/styles/menu.css?_=4.4.0
   37 link rel=stylesheet type=text/css 
 href=css/styles/plugins.css?_=4.4.0
   38 link rel=stylesheet type=text/css 
 href=css/styles/documents.css?_=4.4.0
   39 link rel=stylesheet type=text/css 
 href=css/styles/query.css?_=4.4.0
   40 link rel=stylesheet type=text/css 
 href=css/styles/replication.css?_=4.4.0
   41 link rel=stylesheet type=text/css 
 href=css/styles/schema-browser.css?_=4.4.0
   42 link rel=stylesheet type=text/css 
 href=css/styles/threads.css?_=4.4.0
   43 link rel=stylesheet type=text/css href=css/chosen.css?_=4.4.0
   45 script type=text/javascript
   52 /script
   54   /head
   55   body
   57 div id=wrapper
   59   div id=header
   61 a href=./ id=solr
   61   span
   61 Apache SOLR
   61   /span
   61 /a
   63 p id=environment
   63   nbsp;
   63 /p
   65   /div
   67   div id=main class=clearfix
   69 div id=init-failures
   71 next problemprevious problemP883 [WCAG 2.0 1.3.1 (A)] Nest headings 
 properly (H1  H2  H3):
h2
   71 SolrCore Initialization Failures
   71   /h2
   72 next problemprevious problemP892 [WCAG 2.0 1.3.1 (A)] Use CSS for 
 presentation effects:
ul
   72 next problemprevious problemE610 One or more of the following tags are 
 missing from within the enclosing tag: li 
/ul
   73   p
   73 Please check your logs for more information
   73   /p
   75 /div
   77 div id=content-wrapper
   78   div id=content
   79 nbsp;
   82   /div
   83 /div
   85 div id=menu-wrapper
   86   div
   88 ul id=menu
   90   li id=index class=global
   90 p
   90 next problemprevious problemE049 No matching anchor name:
a href=#/
   90 Dashboard
   90   /a
   90 /p
   90   /li
   92   li id=logging

[jira] [Updated] (SOLR-5162) Implicit core properties are no longer available


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

Alan Woodward updated SOLR-5162:


Attachment: SOLR-5162.patch

Patch with test.  The test setup is a bit complicated, because the standard 
TestHarness setup doesn't use a CoreContainer or CoreDescriptor to set up its 
cores, so substitutions won't work.  Which is less than ideal, but that's for 
another issue.

[~elyograg], does this fix your setup?

 Implicit core properties are no longer available
 

 Key: SOLR-5162
 URL: https://issues.apache.org/jira/browse/SOLR-5162
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.5
Reporter: Alan Woodward
Assignee: Alan Woodward
Priority: Minor
 Fix For: 4.5

 Attachments: SOLR-5162.patch, SOLR-5162.patch


 As noted by ~elyograg on IRC, implicit property substitution doesn't work any 
 more in 4.5.

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

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

[jira] [Commented] (SOLR-5171) Unmatched tags in SOLR Admin gui, breaks in IE10.


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

Joseph L Howard commented on SOLR-5171:
---

1) Workaround in IE10... Hit F12 key and select the IE9 DOCUMENT mode (caps to 
emphasize). Simply selecting IE9 compatibility browser mode will not work. The 
Admin GUI will work only if the document mode is IE9 in iE10. Note There are 
two types modes here... Browser modes and document standard modes. Still not 
sure why...
2) In HTML5, even dynamic tags should be closed (closed expressions).  

 Unmatched tags in SOLR Admin gui, breaks in IE10.
 -

 Key: SOLR-5171
 URL: https://issues.apache.org/jira/browse/SOLR-5171
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.4
 Environment: Windows7 and 8, IE10 Browser, Windows Server, Centos 
Reporter: Joseph L Howard
Priority: Minor
  Labels: patch
 Fix For: 4.5


 Solr Admin gui has invalid tags, and unmatched tags that break the page in IE 
 10. New to solr, so I haven't fixed this yet. 
 Do you run a validator on the pages? I use total validator. 
 The line numbers refer to lines in the original source.
 Any with a line number of '0' are implicit tags added by Total Validator:
1 !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01//EN 
 http://www.w3.org/TR/html4/strict.dtd;
2 next problemprevious problemW864 [WCAG 2.0 3.1.1 (A)] Use the 'lang' or 
 'xml:lang' attribute to denote the primary language of the 
   document:
  html
   21   head
   23 title
   23   Solr Admin
   23 /title
   25 link rel=icon type=image/ico href=img/favicon.ico?_=4.4.0
   27 link rel=stylesheet type=text/css 
 href=css/styles/common.css?_=4.4.0
   28 link rel=stylesheet type=text/css 
 href=css/styles/analysis.css?_=4.4.0
   29 link rel=stylesheet type=text/css 
 href=css/styles/cloud.css?_=4.4.0
   30 link rel=stylesheet type=text/css 
 href=css/styles/cores.css?_=4.4.0
   31 link rel=stylesheet type=text/css 
 href=css/styles/dashboard.css?_=4.4.0
   32 link rel=stylesheet type=text/css 
 href=css/styles/dataimport.css?_=4.4.0
   33 link rel=stylesheet type=text/css 
 href=css/styles/index.css?_=4.4.0
   34 link rel=stylesheet type=text/css 
 href=css/styles/java-properties.css?_=4.4.0
   35 link rel=stylesheet type=text/css 
 href=css/styles/logging.css?_=4.4.0
   36 link rel=stylesheet type=text/css 
 href=css/styles/menu.css?_=4.4.0
   37 link rel=stylesheet type=text/css 
 href=css/styles/plugins.css?_=4.4.0
   38 link rel=stylesheet type=text/css 
 href=css/styles/documents.css?_=4.4.0
   39 link rel=stylesheet type=text/css 
 href=css/styles/query.css?_=4.4.0
   40 link rel=stylesheet type=text/css 
 href=css/styles/replication.css?_=4.4.0
   41 link rel=stylesheet type=text/css 
 href=css/styles/schema-browser.css?_=4.4.0
   42 link rel=stylesheet type=text/css 
 href=css/styles/threads.css?_=4.4.0
   43 link rel=stylesheet type=text/css href=css/chosen.css?_=4.4.0
   45 script type=text/javascript
   52 /script
   54   /head
   55   body
   57 div id=wrapper
   59   div id=header
   61 a href=./ id=solr
   61   span
   61 Apache SOLR
   61   /span
   61 /a
   63 p id=environment
   63   nbsp;
   63 /p
   65   /div
   67   div id=main class=clearfix
   69 div id=init-failures
   71 next problemprevious problemP883 [WCAG 2.0 1.3.1 (A)] Nest headings 
 properly (H1  H2  H3):
h2
   71 SolrCore Initialization Failures
   71   /h2
   72 next problemprevious problemP892 [WCAG 2.0 1.3.1 (A)] Use CSS for 
 presentation effects:
ul
   72 next problemprevious problemE610 One or more of the following tags are 
 missing from within the enclosing tag: li 
/ul
   73   p
   73 Please check your logs for more information
   73   /p
   75 /div
   77 div id=content-wrapper
   78   div id=content
   79 nbsp;
   82   /div
   83 /div
   85 div id=menu-wrapper
   86   div
   88 ul id=menu
   90   li id=index class=global
   90 p
   90 next problemprevious problemE049 No matching anchor name:
a href=#/
   90 Dashboard
   90   /a
   90 /p
   90   /li
   92   li id=logging class=global
   92 p
   92 next problemprevious problemE049 No matching anchor name:
a href=#/~logging
   92 Logging

[jira] [Commented] (SOLR-5099) The core.properties not created during collection creation


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

Alan Woodward commented on SOLR-5099:
-

Thanks Mark!

 The core.properties not created during collection creation
 --

 Key: SOLR-5099
 URL: https://issues.apache.org/jira/browse/SOLR-5099
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.5, 5.0
Reporter: Herb Jiang
Assignee: Mark Miller
Priority: Critical
 Fix For: 4.5, 5.0

 Attachments: CorePropertiesLocator.java.patch


 When using the new solr.xml structure. The core auto discovery mechanism 
 trying to find core.properties. 
 But I found the core.properties cannot be create when I dynamically create a 
 collection.
 The root issue is the CorePropertiesLocator trying to create properties 
 before the instanceDir is created. 
 And collection creation process will done and looks fine at runtime, but it 
 will cause issues (cores are not auto discovered after server restart).

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

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

[jira] [Commented] (SOLR-5171) Unmatched tags in SOLR Admin gui, breaks in IE10.

2013-08-17 Thread ASF subversion and git services (JIRA)


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

Joseph L Howard commented on SOLR-5171:
---

Still looking into it. 
In page default standards mode. 
SCRIPT5009: 'app' is undefined 
main.js, line 56 character 5
SCRIPT5022: Load timeout for modules: lib/order!scripts/threads 
http://requirejs.org/docs/errors.html#timeout 
require.js, line 1659 character 9

Not sure why ... 



 Unmatched tags in SOLR Admin gui, breaks in IE10.
 -

 Key: SOLR-5171
 URL: https://issues.apache.org/jira/browse/SOLR-5171
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.4
 Environment: Windows7 and 8, IE10 Browser, Windows Server, Centos 
Reporter: Joseph L Howard
Priority: Minor
  Labels: patch
 Fix For: 4.5


 Solr Admin gui has invalid tags, and unmatched tags that break the page in IE 
 10. New to solr, so I haven't fixed this yet. 
 Do you run a validator on the pages? I use total validator. 
 The line numbers refer to lines in the original source.
 Any with a line number of '0' are implicit tags added by Total Validator:
1 !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01//EN 
 http://www.w3.org/TR/html4/strict.dtd;
2 next problemprevious problemW864 [WCAG 2.0 3.1.1 (A)] Use the 'lang' or 
 'xml:lang' attribute to denote the primary language of the 
   document:
  html
   21   head
   23 title
   23   Solr Admin
   23 /title
   25 link rel=icon type=image/ico href=img/favicon.ico?_=4.4.0
   27 link rel=stylesheet type=text/css 
 href=css/styles/common.css?_=4.4.0
   28 link rel=stylesheet type=text/css 
 href=css/styles/analysis.css?_=4.4.0
   29 link rel=stylesheet type=text/css 
 href=css/styles/cloud.css?_=4.4.0
   30 link rel=stylesheet type=text/css 
 href=css/styles/cores.css?_=4.4.0
   31 link rel=stylesheet type=text/css 
 href=css/styles/dashboard.css?_=4.4.0
   32 link rel=stylesheet type=text/css 
 href=css/styles/dataimport.css?_=4.4.0
   33 link rel=stylesheet type=text/css 
 href=css/styles/index.css?_=4.4.0
   34 link rel=stylesheet type=text/css 
 href=css/styles/java-properties.css?_=4.4.0
   35 link rel=stylesheet type=text/css 
 href=css/styles/logging.css?_=4.4.0
   36 link rel=stylesheet type=text/css 
 href=css/styles/menu.css?_=4.4.0
   37 link rel=stylesheet type=text/css 
 href=css/styles/plugins.css?_=4.4.0
   38 link rel=stylesheet type=text/css 
 href=css/styles/documents.css?_=4.4.0
   39 link rel=stylesheet type=text/css 
 href=css/styles/query.css?_=4.4.0
   40 link rel=stylesheet type=text/css 
 href=css/styles/replication.css?_=4.4.0
   41 link rel=stylesheet type=text/css 
 href=css/styles/schema-browser.css?_=4.4.0
   42 link rel=stylesheet type=text/css 
 href=css/styles/threads.css?_=4.4.0
   43 link rel=stylesheet type=text/css href=css/chosen.css?_=4.4.0
   45 script type=text/javascript
   52 /script
   54   /head
   55   body
   57 div id=wrapper
   59   div id=header
   61 a href=./ id=solr
   61   span
   61 Apache SOLR
   61   /span
   61 /a
   63 p id=environment
   63   nbsp;
   63 /p
   65   /div
   67   div id=main class=clearfix
   69 div id=init-failures
   71 next problemprevious problemP883 [WCAG 2.0 1.3.1 (A)] Nest headings 
 properly (H1  H2  H3):
h2
   71 SolrCore Initialization Failures
   71   /h2
   72 next problemprevious problemP892 [WCAG 2.0 1.3.1 (A)] Use CSS for 
 presentation effects:
ul
   72 next problemprevious problemE610 One or more of the following tags are 
 missing from within the enclosing tag: li 
/ul
   73   p
   73 Please check your logs for more information
   73   /p
   75 /div
   77 div id=content-wrapper
   78   div id=content
   79 nbsp;
   82   /div
   83 /div
   85 div id=menu-wrapper
   86   div
   88 ul id=menu
   90   li id=index class=global
   90 p
   90 next problemprevious problemE049 No matching anchor name:
a href=#/
   90 Dashboard
   90   /a
   90 /p
   90   /li
   92   li id=logging class=global
   92 p
   92 next problemprevious problemE049 No matching anchor name:
a href=#/~logging
   92 Logging
   92   /a
   92 /p
   93 ul
   94   li class=level

[jira] [Commented] (SOLR-5162) Implicit core properties are no longer available


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

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

Commit 1515032 from [~romseygeek] in branch 'dev/trunk'
[ https://svn.apache.org/r1515032 ]

SOLR-5162: Add back core implicit properties

 Implicit core properties are no longer available
 

 Key: SOLR-5162
 URL: https://issues.apache.org/jira/browse/SOLR-5162
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.5
Reporter: Alan Woodward
Assignee: Alan Woodward
Priority: Minor
 Fix For: 4.5

 Attachments: SOLR-5162.patch, SOLR-5162.patch


 As noted by ~elyograg on IRC, implicit property substitution doesn't work any 
 more in 4.5.

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

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

[jira] [Commented] (SOLR-4799) SQLEntityProcessor for zipper join

2013-08-17 Thread Mikhail Khludnev (JIRA)

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

Mikhail Khludnev commented on SOLR-4799:

James,
I don't really understand. I wanted to add a tiny plugin into DIH, but
bq. I mean, make zipperjoin an option for any entity processor as opposed to
its own new variant on SqlE.P.
and after I went this way after heavy doubts
bq. As I said, I do not feel it wise to add features that won't neatly plug-in
the current DIH infrastructure until we improve the code.
Anyway, I absolutely share your concerns - DIH is a great idea, but it's worth
to revamp an engine. I have no experience with Flume, but I consider it as some
kind of transport. I want to look at Pentaho Kettle (kind of old school ETL
tool), Cloudera Morphlines.

SQLEntityProcessor for zipper join
--

Key: SOLR-4799
URL: https://issues.apache.org/jira/browse/SOLR-4799
Project: Solr
Issue Type: New Feature
Components: contrib - DataImportHandler
Reporter: Mikhail Khludnev
Priority: Minor
Labels: dih
Attachments: SOLR-4799.patch

DIH is mostly considered as a playground tool, and real usages end up with
SolrJ. I want to contribute few improvements target DIH performance.
This one provides performant approach for joining SQL Entities with miserable
memory at contrast to
http://wiki.apache.org/solr/DataImportHandler#CachedSqlEntityProcessor
The idea is:
* parent table is explicitly ordered by it’s PK in SQL
* children table is explicitly ordered by parent_id FK in SQL
* children entity processor joins ordered resultsets by ‘zipper’ algorithm.
Do you think it’s worth to contribute it into DIH?
cc: [~goksron] [~jdyer]

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

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

[jira] [Commented] (SOLR-5162) Implicit core properties are no longer available

2013-08-17 Thread ASF subversion and git services (JIRA)


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

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

Commit 1515034 from [~romseygeek] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1515034 ]

SOLR-5162: Add back core implicit properties

 Implicit core properties are no longer available
 

 Key: SOLR-5162
 URL: https://issues.apache.org/jira/browse/SOLR-5162
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.5
Reporter: Alan Woodward
Assignee: Alan Woodward
Priority: Minor
 Fix For: 4.5

 Attachments: SOLR-5162.patch, SOLR-5162.patch


 As noted by ~elyograg on IRC, implicit property substitution doesn't work any 
 more in 4.5.

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

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

[jira] [Commented] (SOLR-5162) Implicit core properties are no longer available

2013-08-17 Thread ASF subversion and git services (JIRA)


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

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

Commit 1515036 from [~romseygeek] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1515036 ]

SOLR-5162: ...with the right license header this time

 Implicit core properties are no longer available
 

 Key: SOLR-5162
 URL: https://issues.apache.org/jira/browse/SOLR-5162
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.5
Reporter: Alan Woodward
Assignee: Alan Woodward
Priority: Minor
 Fix For: 4.5

 Attachments: SOLR-5162.patch, SOLR-5162.patch


 As noted by ~elyograg on IRC, implicit property substitution doesn't work any 
 more in 4.5.

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

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

[jira] [Commented] (SOLR-5162) Implicit core properties are no longer available

2013-08-17 Thread ASF subversion and git services (JIRA)


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

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

Commit 1515035 from [~romseygeek] in branch 'dev/trunk'
[ https://svn.apache.org/r1515035 ]

SOLR-5162: ...with the right license header this time

 Implicit core properties are no longer available
 

 Key: SOLR-5162
 URL: https://issues.apache.org/jira/browse/SOLR-5162
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.5
Reporter: Alan Woodward
Assignee: Alan Woodward
Priority: Minor
 Fix For: 4.5

 Attachments: SOLR-5162.patch, SOLR-5162.patch


 As noted by ~elyograg on IRC, implicit property substitution doesn't work any 
 more in 4.5.

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

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

[jira] [Commented] (SOLR-5171) Unmatched tags in SOLR Admin gui, breaks in IE10.

2013-08-17 Thread Jack Krupansky (JIRA)


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

Jack Krupansky commented on SOLR-5171:
--

I just confirmed that the Solr Admin UI (4.4) is totally unusable on IE10, 
unless you go in and force IE to run in IE9 compatibility mode.

I get these errors on the IE developer's console:

{code}
SCRIPT5009: 'app' is undefined 
main.js, line 56 character 5
SCRIPT5022: Load timeout for modules: lib/order!lib/d3 
http://requirejs.org/docs/errors.html#timeout 
require.js, line 1659 character 9
{code}

Chrome runs fine.

No dashboard status is displayed and the core selection button is not displayed 
properly and does not offer collection1 to select - just an empty selection box 
pops up.

I'll attach a screenshot.

I'll suggest a revision to the Solr release process: At least two weeks before 
a proposed RC, somebody needs to at least try the Solr Admin UI on the most 
recent release of IE so that there is time to upgrade it so that we don't run 
into this kind of situation again (like, as soon as IE11 comes out!).


 Unmatched tags in SOLR Admin gui, breaks in IE10.
 -

 Key: SOLR-5171
 URL: https://issues.apache.org/jira/browse/SOLR-5171
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.4
 Environment: Windows7 and 8, IE10 Browser, Windows Server, Centos 
Reporter: Joseph L Howard
Priority: Minor
  Labels: patch
 Fix For: 4.5


 Solr Admin gui has invalid tags, and unmatched tags that break the page in IE 
 10. New to solr, so I haven't fixed this yet. 
 Do you run a validator on the pages? I use total validator. 
 The line numbers refer to lines in the original source.
 Any with a line number of '0' are implicit tags added by Total Validator:
1 !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01//EN 
 http://www.w3.org/TR/html4/strict.dtd;
2 next problemprevious problemW864 [WCAG 2.0 3.1.1 (A)] Use the 'lang' or 
 'xml:lang' attribute to denote the primary language of the 
   document:
  html
   21   head
   23 title
   23   Solr Admin
   23 /title
   25 link rel=icon type=image/ico href=img/favicon.ico?_=4.4.0
   27 link rel=stylesheet type=text/css 
 href=css/styles/common.css?_=4.4.0
   28 link rel=stylesheet type=text/css 
 href=css/styles/analysis.css?_=4.4.0
   29 link rel=stylesheet type=text/css 
 href=css/styles/cloud.css?_=4.4.0
   30 link rel=stylesheet type=text/css 
 href=css/styles/cores.css?_=4.4.0
   31 link rel=stylesheet type=text/css 
 href=css/styles/dashboard.css?_=4.4.0
   32 link rel=stylesheet type=text/css 
 href=css/styles/dataimport.css?_=4.4.0
   33 link rel=stylesheet type=text/css 
 href=css/styles/index.css?_=4.4.0
   34 link rel=stylesheet type=text/css 
 href=css/styles/java-properties.css?_=4.4.0
   35 link rel=stylesheet type=text/css 
 href=css/styles/logging.css?_=4.4.0
   36 link rel=stylesheet type=text/css 
 href=css/styles/menu.css?_=4.4.0
   37 link rel=stylesheet type=text/css 
 href=css/styles/plugins.css?_=4.4.0
   38 link rel=stylesheet type=text/css 
 href=css/styles/documents.css?_=4.4.0
   39 link rel=stylesheet type=text/css 
 href=css/styles/query.css?_=4.4.0
   40 link rel=stylesheet type=text/css 
 href=css/styles/replication.css?_=4.4.0
   41 link rel=stylesheet type=text/css 
 href=css/styles/schema-browser.css?_=4.4.0
   42 link rel=stylesheet type=text/css 
 href=css/styles/threads.css?_=4.4.0
   43 link rel=stylesheet type=text/css href=css/chosen.css?_=4.4.0
   45 script type=text/javascript
   52 /script
   54   /head
   55   body
   57 div id=wrapper
   59   div id=header
   61 a href=./ id=solr
   61   span
   61 Apache SOLR
   61   /span
   61 /a
   63 p id=environment
   63   nbsp;
   63 /p
   65   /div
   67   div id=main class=clearfix
   69 div id=init-failures
   71 next problemprevious problemP883 [WCAG 2.0 1.3.1 (A)] Nest headings 
 properly (H1  H2  H3):
h2
   71 SolrCore Initialization Failures
   71   /h2
   72 next problemprevious problemP892 [WCAG 2.0 1.3.1 (A)] Use CSS for 
 presentation effects:
ul
   72 next problemprevious problemE610 One or more of the following tags are 
 missing from within the enclosing tag: li 
/ul
   73   p
   73 Please check your logs for more information
   73   /p
   75 /div
   77 div id=content-wrapper
   78   div id=content
   79 nbsp;
   82   /div
   83 /div
   85 div id=menu-wrapper
   86

[jira] [Resolved] (SOLR-5162) Implicit core properties are no longer available


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

Alan Woodward resolved SOLR-5162.
-

Resolution: Fixed

 Implicit core properties are no longer available
 

 Key: SOLR-5162
 URL: https://issues.apache.org/jira/browse/SOLR-5162
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.5
Reporter: Alan Woodward
Assignee: Alan Woodward
Priority: Minor
 Fix For: 4.5

 Attachments: SOLR-5162.patch, SOLR-5162.patch


 As noted by ~elyograg on IRC, implicit property substitution doesn't work any 
 more in 4.5.

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

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

[jira] [Updated] (SOLR-5171) Unmatched tags in SOLR Admin gui, breaks in IE10.

2013-08-17 Thread Jack Krupansky (JIRA)


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

Jack Krupansky updated SOLR-5171:
-

Attachment: screenshot-1.jpg

 Unmatched tags in SOLR Admin gui, breaks in IE10.
 -

 Key: SOLR-5171
 URL: https://issues.apache.org/jira/browse/SOLR-5171
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.4
 Environment: Windows7 and 8, IE10 Browser, Windows Server, Centos 
Reporter: Joseph L Howard
Priority: Minor
  Labels: patch
 Fix For: 4.5

 Attachments: screenshot-1.jpg


 Solr Admin gui has invalid tags, and unmatched tags that break the page in IE 
 10. New to solr, so I haven't fixed this yet. 
 Do you run a validator on the pages? I use total validator. 
 The line numbers refer to lines in the original source.
 Any with a line number of '0' are implicit tags added by Total Validator:
1 !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01//EN 
 http://www.w3.org/TR/html4/strict.dtd;
2 next problemprevious problemW864 [WCAG 2.0 3.1.1 (A)] Use the 'lang' or 
 'xml:lang' attribute to denote the primary language of the 
   document:
  html
   21   head
   23 title
   23   Solr Admin
   23 /title
   25 link rel=icon type=image/ico href=img/favicon.ico?_=4.4.0
   27 link rel=stylesheet type=text/css 
 href=css/styles/common.css?_=4.4.0
   28 link rel=stylesheet type=text/css 
 href=css/styles/analysis.css?_=4.4.0
   29 link rel=stylesheet type=text/css 
 href=css/styles/cloud.css?_=4.4.0
   30 link rel=stylesheet type=text/css 
 href=css/styles/cores.css?_=4.4.0
   31 link rel=stylesheet type=text/css 
 href=css/styles/dashboard.css?_=4.4.0
   32 link rel=stylesheet type=text/css 
 href=css/styles/dataimport.css?_=4.4.0
   33 link rel=stylesheet type=text/css 
 href=css/styles/index.css?_=4.4.0
   34 link rel=stylesheet type=text/css 
 href=css/styles/java-properties.css?_=4.4.0
   35 link rel=stylesheet type=text/css 
 href=css/styles/logging.css?_=4.4.0
   36 link rel=stylesheet type=text/css 
 href=css/styles/menu.css?_=4.4.0
   37 link rel=stylesheet type=text/css 
 href=css/styles/plugins.css?_=4.4.0
   38 link rel=stylesheet type=text/css 
 href=css/styles/documents.css?_=4.4.0
   39 link rel=stylesheet type=text/css 
 href=css/styles/query.css?_=4.4.0
   40 link rel=stylesheet type=text/css 
 href=css/styles/replication.css?_=4.4.0
   41 link rel=stylesheet type=text/css 
 href=css/styles/schema-browser.css?_=4.4.0
   42 link rel=stylesheet type=text/css 
 href=css/styles/threads.css?_=4.4.0
   43 link rel=stylesheet type=text/css href=css/chosen.css?_=4.4.0
   45 script type=text/javascript
   52 /script
   54   /head
   55   body
   57 div id=wrapper
   59   div id=header
   61 a href=./ id=solr
   61   span
   61 Apache SOLR
   61   /span
   61 /a
   63 p id=environment
   63   nbsp;
   63 /p
   65   /div
   67   div id=main class=clearfix
   69 div id=init-failures
   71 next problemprevious problemP883 [WCAG 2.0 1.3.1 (A)] Nest headings 
 properly (H1  H2  H3):
h2
   71 SolrCore Initialization Failures
   71   /h2
   72 next problemprevious problemP892 [WCAG 2.0 1.3.1 (A)] Use CSS for 
 presentation effects:
ul
   72 next problemprevious problemE610 One or more of the following tags are 
 missing from within the enclosing tag: li 
/ul
   73   p
   73 Please check your logs for more information
   73   /p
   75 /div
   77 div id=content-wrapper
   78   div id=content
   79 nbsp;
   82   /div
   83 /div
   85 div id=menu-wrapper
   86   div
   88 ul id=menu
   90   li id=index class=global
   90 p
   90 next problemprevious problemE049 No matching anchor name:
a href=#/
   90 Dashboard
   90   /a
   90 /p
   90   /li
   92   li id=logging class=global
   92 p
   92 next problemprevious problemE049 No matching anchor name:
a href=#/~logging
   92 Logging
   92   /a
   92 /p
   93 ul
   94   li class=level
   94 next problemprevious problemE049 No matching anchor name:
  a href=#/~logging/level
   94   Level
   94 /a
   94   /li
   95 /ul
   96   /li
   98   li

[jira] [Created] (SOLR-5172) Start embedded zk servers before CoreContainer loads

Alan Woodward created SOLR-5172:
---

 Summary: Start embedded zk servers before CoreContainer loads
 Key: SOLR-5172
 URL: https://issues.apache.org/jira/browse/SOLR-5172
 Project: Solr
  Issue Type: Improvement
Reporter: Alan Woodward
Priority: Minor


In SOLR-4718 we allowed solr.xml to be read from Zookeeper in cloud setups.  
However, this doesn't work with an embedded ZK server because it doesn't start 
until CoreContainer.load() is called, by which time solr.xml has already been 
loaded.  We should move the embedded ZK startup/shutdown logic out of 
CoreContainer and into SolrDispatchFilter.

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

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

[jira] [Commented] (SOLR-5172) Start embedded zk servers before CoreContainer loads

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

Alan Woodward commented on SOLR-5172:
-

One problem here is that embedded ZK currently expects to start on solrport +
1000, but we don't know the solr port until we've parsed solr.xml. Maybe we
should just expect to start on 9983, or allow the zk port to be set as a
sysprop?

A couple more ideas:
* Do we need to support a distributed ZK setup in embedded mode? It's only
supposed to be for use in development, and it adds a *lot* of complication to
the code.
* We also have a separate ZkTestServer, for use in running tests. We can
probably remove this and just re-use SolrZkServer.

Start embedded zk servers before CoreContainer loads

Key: SOLR-5172
URL: https://issues.apache.org/jira/browse/SOLR-5172
Project: Solr
Issue Type: Improvement
Reporter: Alan Woodward
Priority: Minor

In SOLR-4718 we allowed solr.xml to be read from Zookeeper in cloud setups.
However, this doesn't work with an embedded ZK server because it doesn't
start until CoreContainer.load() is called, by which time solr.xml has
already been loaded. We should move the embedded ZK startup/shutdown logic
out of CoreContainer and into SolrDispatchFilter.

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

[jira] [Commented] (SOLR-3592) After reloading a SolrCore, some IndexWriter 'settings' changes will not take effect. Instead, you must restart Solr.

2013-08-17 Thread Jack Krupansky (JIRA)


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

Jack Krupansky commented on SOLR-3592:
--

If this was fixed in 4.3, then the wiki and refguide should note that:

Refguide:

https://cwiki.apache.org/confluence/display/solr/CoreAdminHandler+Parameters+and+Usage
{quote}
As of Solr 4.0, REALOAD performs live reloads of SolrCore, reusing some 
existing objects. Some configuration options, such as the DataDir location and 
IndexWriter related settings in solrconfig.xml can not be changed and made 
active with a simple RELOAD action.
{quote}

wiki:
http://wiki.apache.org/solr/CoreAdmin#Important_Note_About_Some_Configuration_Changes
{quote}
Starting with Solr4.0, the RELOAD command is implemented in a way that results 
a live reloads of the SolrCore, reusing the existing various objects such as 
the SolrIndexWriter. As a result, some configuration options can not be changed 
and made active with a simple RELOAD...

IndexWriter related settings in indexConfig
dataDir location
See SOLR-3592 for more background.
{quote}

I would also note that the wiki page is another candidate for full migration to 
the new refguide since the refguide is essentially a cut and paste of the wiki 
page.


 After reloading a SolrCore, some IndexWriter 'settings' changes will not take 
 effect. Instead, you must restart Solr.
 -

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


 This is a known tradeoff that was made to more properly support our SolrCore 
 model - there is a TODO: in the code in SolrCore#reload about it.

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

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

[jira] [Commented] (SOLR-5171) Unmatched tags in SOLR Admin gui, breaks in IE10.


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

Joseph L Howard commented on SOLR-5171:
---

Workaround... Adding a microsoft IE9 Document Type meta tag will allow SOLR to 
work  meta http-equiv=x-ua-compatible content=IE=9 in admin.html is a 
workaround. 
 

 Unmatched tags in SOLR Admin gui, breaks in IE10.
 -

 Key: SOLR-5171
 URL: https://issues.apache.org/jira/browse/SOLR-5171
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.4
 Environment: Windows7 and 8, IE10 Browser, Windows Server, Centos 
Reporter: Joseph L Howard
Priority: Minor
  Labels: patch
 Fix For: 4.5

 Attachments: screenshot-1.jpg


 Solr Admin gui has invalid tags, and unmatched tags that break the page in IE 
 10. New to solr, so I haven't fixed this yet. 
 Do you run a validator on the pages? I use total validator. 
 The line numbers refer to lines in the original source.
 Any with a line number of '0' are implicit tags added by Total Validator:
1 !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01//EN 
 http://www.w3.org/TR/html4/strict.dtd;
2 next problemprevious problemW864 [WCAG 2.0 3.1.1 (A)] Use the 'lang' or 
 'xml:lang' attribute to denote the primary language of the 
   document:
  html
   21   head
   23 title
   23   Solr Admin
   23 /title
   25 link rel=icon type=image/ico href=img/favicon.ico?_=4.4.0
   27 link rel=stylesheet type=text/css 
 href=css/styles/common.css?_=4.4.0
   28 link rel=stylesheet type=text/css 
 href=css/styles/analysis.css?_=4.4.0
   29 link rel=stylesheet type=text/css 
 href=css/styles/cloud.css?_=4.4.0
   30 link rel=stylesheet type=text/css 
 href=css/styles/cores.css?_=4.4.0
   31 link rel=stylesheet type=text/css 
 href=css/styles/dashboard.css?_=4.4.0
   32 link rel=stylesheet type=text/css 
 href=css/styles/dataimport.css?_=4.4.0
   33 link rel=stylesheet type=text/css 
 href=css/styles/index.css?_=4.4.0
   34 link rel=stylesheet type=text/css 
 href=css/styles/java-properties.css?_=4.4.0
   35 link rel=stylesheet type=text/css 
 href=css/styles/logging.css?_=4.4.0
   36 link rel=stylesheet type=text/css 
 href=css/styles/menu.css?_=4.4.0
   37 link rel=stylesheet type=text/css 
 href=css/styles/plugins.css?_=4.4.0
   38 link rel=stylesheet type=text/css 
 href=css/styles/documents.css?_=4.4.0
   39 link rel=stylesheet type=text/css 
 href=css/styles/query.css?_=4.4.0
   40 link rel=stylesheet type=text/css 
 href=css/styles/replication.css?_=4.4.0
   41 link rel=stylesheet type=text/css 
 href=css/styles/schema-browser.css?_=4.4.0
   42 link rel=stylesheet type=text/css 
 href=css/styles/threads.css?_=4.4.0
   43 link rel=stylesheet type=text/css href=css/chosen.css?_=4.4.0
   45 script type=text/javascript
   52 /script
   54   /head
   55   body
   57 div id=wrapper
   59   div id=header
   61 a href=./ id=solr
   61   span
   61 Apache SOLR
   61   /span
   61 /a
   63 p id=environment
   63   nbsp;
   63 /p
   65   /div
   67   div id=main class=clearfix
   69 div id=init-failures
   71 next problemprevious problemP883 [WCAG 2.0 1.3.1 (A)] Nest headings 
 properly (H1  H2  H3):
h2
   71 SolrCore Initialization Failures
   71   /h2
   72 next problemprevious problemP892 [WCAG 2.0 1.3.1 (A)] Use CSS for 
 presentation effects:
ul
   72 next problemprevious problemE610 One or more of the following tags are 
 missing from within the enclosing tag: li 
/ul
   73   p
   73 Please check your logs for more information
   73   /p
   75 /div
   77 div id=content-wrapper
   78   div id=content
   79 nbsp;
   82   /div
   83 /div
   85 div id=menu-wrapper
   86   div
   88 ul id=menu
   90   li id=index class=global
   90 p
   90 next problemprevious problemE049 No matching anchor name:
a href=#/
   90 Dashboard
   90   /a
   90 /p
   90   /li
   92   li id=logging class=global
   92 p
   92 next problemprevious problemE049 No matching anchor name:
a href=#/~logging
   92 Logging
   92   /a
   92 /p
   93 ul
   94   li class=level
   94 next problemprevious problemE049 No matching anchor name:

[jira] [Commented] (SOLR-5172) Start embedded zk servers before CoreContainer loads