[jira] Commented: (SOLR-924) Solr: Making finalizers call super.finalize() wrapped in try..finally block
[ https://issues.apache.org/jira/browse/SOLR-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657702#action_12657702 ] Hoss Man commented on SOLR-924: --- What Kay is suggesting is a pretty well established "best practice" .. even if you *know* the super class has an empty finalize method it's still a good idea to call super.finalize() in a finally block because you have no garuntee someone else won't modify the implementation of the super class in a future version. even when you subclass Object, super.finalize() is a good idea to protect yourself against yourself: future refactoring could inject a new super class (which could then gain a non-trivial finalize method) i really see no downside to the patch > Solr: Making finalizers call super.finalize() wrapped in try..finally block > > > Key: SOLR-924 > URL: https://issues.apache.org/jira/browse/SOLR-924 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler, replication (java) > Environment: Tomcat 6, JRE 6 >Reporter: Kay Kay >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-924.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > There are some occurences of finalizers in the code base. While the presence > of them is debatable and discussed in a separate JIRA - the ones that are > retained are better off wrapped around a try .. finally block to recursively > call the finalizer of the super class for proper resource usage unwinding , > (in case finalizers get invoked ). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-912) org.apache.solr.common.util.NamedList - Typesafe efficient variant - ModernNamedList introduced - implementing the same API as NamedList
[
https://issues.apache.org/jira/browse/SOLR-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657692#action_12657692
]
Yonik Seeley commented on SOLR-912:
---
While we're going down the micro-benchmarking path, I tried eliminating
ArrayList and got an additional 15-25% gain on common operations (create new,
add between 5 and 15 elements, and then iterate over those elements later).
This was with Java 1.6. -Xbatch improved the results even more... ~40% - but
this is just a micro-benchmark.
{code}
class NamedList2 implements INamedList {
protected NamedListEntry[] nvPairs;
protected int size;
public NamedList2() {
nvPairs = new NamedListEntry[10];
size = 0;
}
@Override
public int size() {
return size;
}
@Override
public String getName(int idx) {
if (idx >= size) throw new ArrayIndexOutOfBoundsException();
return nvPairs[idx].key;
}
@Override
public T getVal(int idx) {
if (idx >= size) throw new ArrayIndexOutOfBoundsException();
return nvPairs[idx].value;
}
private void resize() {
NamedListEntry[] arr = new NamedListEntry[nvPairs.length << 1];
System.arraycopy(nvPairs, 0, arr, 0, size);
nvPairs = arr;
}
@Override
public void add(String name, T val) {
if (size >= nvPairs.length) {
resize();
}
nvPairs[size++] = new NamedListEntry(name, val);
}
[...]
{code}
> org.apache.solr.common.util.NamedList - Typesafe efficient variant -
> ModernNamedList introduced - implementing the same API as NamedList
>
>
> Key: SOLR-912
> URL: https://issues.apache.org/jira/browse/SOLR-912
> Project: Solr
> Issue Type: Improvement
> Components: Analysis
>Affects Versions: 1.4
> Environment: Tomcat 6, JRE 6, Solr 1.3+ nightlies
>Reporter: Kay Kay
>Priority: Minor
> Fix For: 1.3.1
>
> Attachments: NLProfile.java, SOLR-912.patch
>
> Original Estimate: 72h
> Remaining Estimate: 72h
>
> The implementation of NamedList - while being fast - is not necessarily
> type-safe. I have implemented an additional implementation of the same -
> ModernNamedList (a type-safe variation providing the same interface as
> NamedList) - while preserving the semantics in terms of ordering of elements
> and allowing null elements for key and values (keys are always Strings ,
> while values correspond to generics ).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-885) Generify NamedListCodec
[ https://issues.apache.org/jira/browse/SOLR-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657691#action_12657691 ] Noble Paul commented on SOLR-885: - bq.So instead of this big patch, simply change the signature of the method: bq.public NamedList unmarshal(InputStream is) bq.To bq.public Object unmarshal(InputStream is) This is fine .No need to make it generic But renaming the class to JavabinCodec makes sense right? > Generify NamedListCodec > --- > > Key: SOLR-885 > URL: https://issues.apache.org/jira/browse/SOLR-885 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-885.patch, SOLR-885.patch, SOLR-885.patch > > > * make NamedListCodec a generic class which may be able to write any of the > supported object > * Deprecate NamedList and use only SimpleOrderedMap. (Yes it is backward > compatible) > * Ideally I wish to call this JavabinCodec because it should be able to be > used to write any kind of supported objects -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-885) Generify NamedListCodec
[ https://issues.apache.org/jira/browse/SOLR-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657681#action_12657681 ] Yonik Seeley commented on SOLR-885: --- bq. NamedListCodec dictates the root Object to be a NamedList Agreed, but theType parameter is only used to cast the final root Object to the Type. So instead of this big patch, simply change the signature of the method: public NamedList unmarshal(InputStream is) To public Object unmarshal(InputStream is) > Generify NamedListCodec > --- > > Key: SOLR-885 > URL: https://issues.apache.org/jira/browse/SOLR-885 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-885.patch, SOLR-885.patch, SOLR-885.patch > > > * make NamedListCodec a generic class which may be able to write any of the > supported object > * Deprecate NamedList and use only SimpleOrderedMap. (Yes it is backward > compatible) > * Ideally I wish to call this JavabinCodec because it should be able to be > used to write any kind of supported objects -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-922) Solr WebApp wide Executor for better efficient management of threads , separating the logic in the thread from the launch of the same.
[ https://issues.apache.org/jira/browse/SOLR-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657679#action_12657679 ] Noble Paul commented on SOLR-922: - Kay. Go ahead and give a patch anyway > Solr WebApp wide Executor for better efficient management of threads , > separating the logic in the thread from the launch of the same. > --- > > Key: SOLR-922 > URL: https://issues.apache.org/jira/browse/SOLR-922 > Project: Solr > Issue Type: Improvement > Components: clients - java > Environment: Tomcat 6, JRE 6 >Reporter: Kay Kay >Priority: Minor > > For a different jira - when we were discussing bringing in parallelism > through threads and using Executors - encountered a case of using a webapp > wide Executor for reusing thread pools for better use of thread resources , > instead of thread.start() . > pros: Custom Request Handlers and other plugins to the Solr App server can > use this Executor API to retrieve the executor and just submit the Runnable / > Callable impls to get the job done while getting the benefits of a thread > pool . This might be necessary as we continue to write plugins to the core > architecture and centralizing the threadpools might make it easy to control / > prevent global Executor objects across the codebase / recreating them locally > ( as they might be expensive ). > $ find . -name *.java | xargs grep -nr 'start()' | grep "}" > ./contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/XPathEntityProcessor.java:377: > }.start(); > ./contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/DataImporter.java:368: > }.start(); > ./src/java/org/apache/solr/handler/SnapPuller.java:382:}.start(); > ./src/java/org/apache/solr/handler/SnapShooter.java:52:}.start(); > ./src/java/org/apache/solr/handler/ReplicationHandler.java:134: > }.start(); > ./src/common/org/apache/solr/common/util/ConcurrentLRUCache.java:112: > }.start(); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-922) Solr WebApp wide Executor for better efficient management of threads , separating the logic in the thread from the launch of the same.
[ https://issues.apache.org/jira/browse/SOLR-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657677#action_12657677 ] Kay Kay commented on SOLR-922: -- | But, the problem is that means defining an extra API and may be having an extra configuration in say solrconfig.xml Selecting the number of threads in the thread pools / specifying the queuing policy for an even distribution of tasks , are some of the various customizations that could be implemented for the ExecutorService implementation. Since DIH and other parts of the solr application server live in the same jvm process - I am not sure why we would like to exclude the same since that would mean multiple resource managers ( thread pools ) in the same process - that would be hard to change / modify if we encounter an OutOfMemoryError (very much possible when there are multiple ExecutorService impls locally ) etc. > Solr WebApp wide Executor for better efficient management of threads , > separating the logic in the thread from the launch of the same. > --- > > Key: SOLR-922 > URL: https://issues.apache.org/jira/browse/SOLR-922 > Project: Solr > Issue Type: Improvement > Components: clients - java > Environment: Tomcat 6, JRE 6 >Reporter: Kay Kay >Priority: Minor > > For a different jira - when we were discussing bringing in parallelism > through threads and using Executors - encountered a case of using a webapp > wide Executor for reusing thread pools for better use of thread resources , > instead of thread.start() . > pros: Custom Request Handlers and other plugins to the Solr App server can > use this Executor API to retrieve the executor and just submit the Runnable / > Callable impls to get the job done while getting the benefits of a thread > pool . This might be necessary as we continue to write plugins to the core > architecture and centralizing the threadpools might make it easy to control / > prevent global Executor objects across the codebase / recreating them locally > ( as they might be expensive ). > $ find . -name *.java | xargs grep -nr 'start()' | grep "}" > ./contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/XPathEntityProcessor.java:377: > }.start(); > ./contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/DataImporter.java:368: > }.start(); > ./src/java/org/apache/solr/handler/SnapPuller.java:382:}.start(); > ./src/java/org/apache/solr/handler/SnapShooter.java:52:}.start(); > ./src/java/org/apache/solr/handler/ReplicationHandler.java:134: > }.start(); > ./src/common/org/apache/solr/common/util/ConcurrentLRUCache.java:112: > }.start(); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-924) Solr: Making finalizers call super.finalize() wrapped in try..finally block
[ https://issues.apache.org/jira/browse/SOLR-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657675#action_12657675 ] Kay Kay commented on SOLR-924: -- | DataSource is just an interface defined as an abstract class. For others it may be worth it. I believe we might as well be consistent when making changes instead of excluding based on specific super class implementation. > Solr: Making finalizers call super.finalize() wrapped in try..finally block > > > Key: SOLR-924 > URL: https://issues.apache.org/jira/browse/SOLR-924 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler, replication (java) > Environment: Tomcat 6, JRE 6 >Reporter: Kay Kay >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-924.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > There are some occurences of finalizers in the code base. While the presence > of them is debatable and discussed in a separate JIRA - the ones that are > retained are better off wrapped around a try .. finally block to recursively > call the finalizer of the super class for proper resource usage unwinding , > (in case finalizers get invoked ). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-922) Solr WebApp wide Executor for better efficient management of threads , separating the logic in the thread from the launch of the same.
[ https://issues.apache.org/jira/browse/SOLR-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657670#action_12657670 ] Noble Paul commented on SOLR-922: - As I have already mentioned , I am supportive of the idea of having a common pool of threads shared across various services But, the problem is that means defining an extra API and may be having an extra configuration in say solrconfig.xml Let us leave aside the contribs (I mean DIH) .In the core there are a few common usecases . You can go ahead and propose an API and let us see how to use it best > Solr WebApp wide Executor for better efficient management of threads , > separating the logic in the thread from the launch of the same. > --- > > Key: SOLR-922 > URL: https://issues.apache.org/jira/browse/SOLR-922 > Project: Solr > Issue Type: Improvement > Components: clients - java > Environment: Tomcat 6, JRE 6 >Reporter: Kay Kay >Priority: Minor > > For a different jira - when we were discussing bringing in parallelism > through threads and using Executors - encountered a case of using a webapp > wide Executor for reusing thread pools for better use of thread resources , > instead of thread.start() . > pros: Custom Request Handlers and other plugins to the Solr App server can > use this Executor API to retrieve the executor and just submit the Runnable / > Callable impls to get the job done while getting the benefits of a thread > pool . This might be necessary as we continue to write plugins to the core > architecture and centralizing the threadpools might make it easy to control / > prevent global Executor objects across the codebase / recreating them locally > ( as they might be expensive ). > $ find . -name *.java | xargs grep -nr 'start()' | grep "}" > ./contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/XPathEntityProcessor.java:377: > }.start(); > ./contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/DataImporter.java:368: > }.start(); > ./src/java/org/apache/solr/handler/SnapPuller.java:382:}.start(); > ./src/java/org/apache/solr/handler/SnapShooter.java:52:}.start(); > ./src/java/org/apache/solr/handler/ReplicationHandler.java:134: > }.start(); > ./src/common/org/apache/solr/common/util/ConcurrentLRUCache.java:112: > }.start(); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-924) Solr: Making finalizers call super.finalize() wrapped in try..finally block
[ https://issues.apache.org/jira/browse/SOLR-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657669#action_12657669 ] Noble Paul commented on SOLR-924: - DataSource is just an interface defined as an abstract class. For others it may be worth it. We do not have to be religious about this. if the superclass is doing something in the finalize then it is worth adding this or else we can drop it > Solr: Making finalizers call super.finalize() wrapped in try..finally block > > > Key: SOLR-924 > URL: https://issues.apache.org/jira/browse/SOLR-924 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler, replication (java) > Environment: Tomcat 6, JRE 6 >Reporter: Kay Kay >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-924.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > There are some occurences of finalizers in the code base. While the presence > of them is debatable and discussed in a separate JIRA - the ones that are > retained are better off wrapped around a try .. finally block to recursively > call the finalizer of the super class for proper resource usage unwinding , > (in case finalizers get invoked ). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-885) Generify NamedListCodec
[ https://issues.apache.org/jira/browse/SOLR-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657667#action_12657667 ] Noble Paul commented on SOLR-885: - NamedListCodec dictates the root Object to be a NamedList . It is useful if we can write other supported types as the root object. say Map, List Why give a special status to NamedList when the implementation has no such constraints? > Generify NamedListCodec > --- > > Key: SOLR-885 > URL: https://issues.apache.org/jira/browse/SOLR-885 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-885.patch, SOLR-885.patch, SOLR-885.patch > > > * make NamedListCodec a generic class which may be able to write any of the > supported object > * Deprecate NamedList and use only SimpleOrderedMap. (Yes it is backward > compatible) > * Ideally I wish to call this JavabinCodec because it should be able to be > used to write any kind of supported objects -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-918) Thread safety issue in SolrCore.infoRegistry
[ https://issues.apache.org/jira/browse/SOLR-918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657661#action_12657661 ] Shalin Shekhar Mangar commented on SOLR-918: It was a HashMap in the SOLR-256 commit but I think it was changed (by me?) to a LinkedHashMap because some users complained that the order of things in stats pages is not the same anymore. Is it ok to let it be a ConcurrentHashMap or should we make it a synchronized LinkedHashMap? > Thread safety issue in SolrCore.infoRegistry > > > Key: SOLR-918 > URL: https://issues.apache.org/jira/browse/SOLR-918 > Project: Solr > Issue Type: Bug >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-918.patch > > > SolrCore.infoRegistry is used for keeping a reference to the SolrInfoMBean > objects. When JMX is disabled, it is initialized to a LinkedHashMap which is > not synchronized. > We can change this to a ConcurrentHashMap instead of a LinkedHashMap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-84) Logo Contests
[ https://issues.apache.org/jira/browse/SOLR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-84. -- Resolution: Fixed The Logo Contest has been concluded, congrats to Michiel for his winning entry... https://issues.apache.org/jira/secure/attachment/12394264/apache_solr_a_red.jpg > Logo Contests > - > > Key: SOLR-84 > URL: https://issues.apache.org/jira/browse/SOLR-84 > Project: Solr > Issue Type: Improvement >Reporter: Bertrand Delacretaz >Priority: Minor > Attachments: apache-solr-004.png, apache_soir_001.ai.zip, > apache_soir_001.jpg, apache_solr_a_blue.jpg, apache_solr_a_red.jpg, > apache_solr_b_blue.jpg, apache_solr_b_red.jpg, apache_solr_burning.png, > apache_solr_c_blue.jpg, apache_solr_c_blue_shirt.jpg, apache_solr_c_red.jpg, > apache_solr_c_red.jpg, apache_solr_contour.png, apache_solr_sun.png, > logo-grid.jpg, logo-solr-d.jpg, logo-solr-e.jpg, > logo-solr-source-files-take2.zip, logo_remake.jpg, logo_remake.svg, > solr-84-source-files.zip, solr-circle-grad.png, solr-f.jpg, > solr-greyscale.png, solr-logo-20061214.jpg, solr-logo-20061218.JPG, > solr-logo-20070124.JPG, solr-logo.jpg, solr-logo.png, solr-nick.gif, > solr-solid-R.png, solr-solid.png, solr.jpg, solr.png, solr.s1.jpg, > solr.s2.jpg, solr.s3.jpg, solr.s4.jpg, solr.s5.jpg, solr.s7.jpg, solr.svg, > solr2_maho-vote.png, solr2_maho.png, solr2_maho_impression.png, > solr3_maho.png, solr_attempt.jpg, solr_attempt2.jpg, solr_logo.rar, > solr_sp.png, solrlogo.jpg, solrlogo2.jpg, sslogo-solr-70s.png, > sslogo-solr-classic.png, sslogo-solr-dance.png, sslogo-solr-fiesta.png, > sslogo-solr-finder2.0.png > > > This issue was original a scratch pad for various ideas for new Logos. It is > now being used as a repository for submissions for the Solr Logo Contest... >http://wiki.apache.org/solr/LogoContest > Note that many of the images currently attached are not eligible for the > contest since they do not meet the official guidelines for new Apache project > logos (in particular that the full project name "Apache Solr" must be > included in the Logo). Only eligible attachments will be included in the > official voting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] LOGO
On Dec 17, 2008, at 7:05 PM, Chris Hostetter wrote: : > Ok, all votes are cast (except Grant who is abstaining) : : Thanks for tallying the votes, Ryan. You're too damn quick for me! It loks like Michiel attached a rar filecontaining some eps variants of the winning entry to SOLR-84 (did someone email him off list asking for that?) so i think this is all official (the eps files seem to contain vector versions, but i don't have my good graphics tools on this machine so i'm not 100% positive) i asked him off list... Ryan: you've done most of the sheperding of this contest ... do you want to do the honors and announce the winner on the solr-user list? (i got the impression you were planning to do this the other day, but maybe it's one of those emails never left your computer) Hoss - can you go ahead and post something? I'm heading out... but could post tomorrow. ryan
[jira] Commented: (SOLR-912) org.apache.solr.common.util.NamedList - Typesafe efficient variant - ModernNamedList introduced - implementing the same API as NamedList
[ https://issues.apache.org/jira/browse/SOLR-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657630#action_12657630 ] Kay Kay commented on SOLR-912: -- Additional Info: JRE 6, Linux 2.6.27-9 , 3.2GB Memory, Dual-core Intel @ 2.53 Ghz. > org.apache.solr.common.util.NamedList - Typesafe efficient variant - > ModernNamedList introduced - implementing the same API as NamedList > > > Key: SOLR-912 > URL: https://issues.apache.org/jira/browse/SOLR-912 > Project: Solr > Issue Type: Improvement > Components: Analysis >Affects Versions: 1.4 > Environment: Tomcat 6, JRE 6, Solr 1.3+ nightlies >Reporter: Kay Kay >Priority: Minor > Fix For: 1.3.1 > > Attachments: NLProfile.java, SOLR-912.patch > > Original Estimate: 72h > Remaining Estimate: 72h > > The implementation of NamedList - while being fast - is not necessarily > type-safe. I have implemented an additional implementation of the same - > ModernNamedList (a type-safe variation providing the same interface as > NamedList) - while preserving the semantics in terms of ordering of elements > and allowing null elements for key and values (keys are always Strings , > while values correspond to generics ). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] LOGO
: > Ok, all votes are cast (except Grant who is abstaining) : : Thanks for tallying the votes, Ryan. You're too damn quick for me! It loks like Michiel attached a rar filecontaining some eps variants of the winning entry to SOLR-84 (did someone email him off list asking for that?) so i think this is all official (the eps files seem to contain vector versions, but i don't have my good graphics tools on this machine so i'm not 100% positive) Ryan: you've done most of the sheperding of this contest ... do you want to do the honors and announce the winner on the solr-user list? (i got the impression you were planning to do this the other day, but maybe it's one of those emails never left your computer) -Hoss
[jira] Commented: (SOLR-912) org.apache.solr.common.util.NamedList - Typesafe efficient variant - ModernNamedList introduced - implementing the same API as NamedList
[ https://issues.apache.org/jira/browse/SOLR-912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657627#action_12657627 ] Kay Kay commented on SOLR-912: -- | ModernNamedList is being suggested as an alternate implementation of NamedList ... ideally the internals of NamedLIst would be replaced with the internals of ModernNamedList, but in this patch they are seperate classes so they can be compared. | INamedList is included in the patch as a way to demonstrate that ModernNamedList fulfills the same contract as NamedList (for the purposes of testing etc) True. Attached herewith is: NLProfile.java - that contains sample benchmarking against the 2 implementations (will work with the previous page on the page). Some results: addAll / getAll(): increase in performance is almost [1-10]% range. add: increase in performance by around 30% , probably because of the additional growth in the List implementation when size approaches capacity. And since, in NamedList - we insert 2 elements as opposed to one, ( as done in ModernNamedList) - it might be more pronounced. iterator: ~70% increase in performance in favor of the new implementation since it just reuses the iterator for the internal data structure. The numbers should be present as comments in the corresponding methods - testAdd() , testAddAll(), testGetAll(), testIterator() . I will attach the final patch once we are convinced with the benchmark methodology and the numbers. > org.apache.solr.common.util.NamedList - Typesafe efficient variant - > ModernNamedList introduced - implementing the same API as NamedList > > > Key: SOLR-912 > URL: https://issues.apache.org/jira/browse/SOLR-912 > Project: Solr > Issue Type: Improvement > Components: Analysis >Affects Versions: 1.4 > Environment: Tomcat 6, JRE 6, Solr 1.3+ nightlies >Reporter: Kay Kay >Priority: Minor > Fix For: 1.3.1 > > Attachments: NLProfile.java, SOLR-912.patch > > Original Estimate: 72h > Remaining Estimate: 72h > > The implementation of NamedList - while being fast - is not necessarily > type-safe. I have implemented an additional implementation of the same - > ModernNamedList (a type-safe variation providing the same interface as > NamedList) - while preserving the semantics in terms of ordering of elements > and allowing null elements for key and values (keys are always Strings , > while values correspond to generics ). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-912) org.apache.solr.common.util.NamedList - Typesafe efficient variant - ModernNamedList introduced - implementing the same API as NamedList
[ https://issues.apache.org/jira/browse/SOLR-912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kay Kay updated SOLR-912: - Attachment: NLProfile.java a sample benchmarking program that works with the previous patch submitted. > org.apache.solr.common.util.NamedList - Typesafe efficient variant - > ModernNamedList introduced - implementing the same API as NamedList > > > Key: SOLR-912 > URL: https://issues.apache.org/jira/browse/SOLR-912 > Project: Solr > Issue Type: Improvement > Components: Analysis >Affects Versions: 1.4 > Environment: Tomcat 6, JRE 6, Solr 1.3+ nightlies >Reporter: Kay Kay >Priority: Minor > Fix For: 1.3.1 > > Attachments: NLProfile.java, SOLR-912.patch > > Original Estimate: 72h > Remaining Estimate: 72h > > The implementation of NamedList - while being fast - is not necessarily > type-safe. I have implemented an additional implementation of the same - > ModernNamedList (a type-safe variation providing the same interface as > NamedList) - while preserving the semantics in terms of ordering of elements > and allowing null elements for key and values (keys are always Strings , > while values correspond to generics ). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-918) Thread safety issue in SolrCore.infoRegistry
[ https://issues.apache.org/jira/browse/SOLR-918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657606#action_12657606 ] Yonik Seeley commented on SOLR-918: --- Hmmm, it used to be a synchronized map. Looks like this bug was introduced back in one of those mega-changes, SOLR-215 > Thread safety issue in SolrCore.infoRegistry > > > Key: SOLR-918 > URL: https://issues.apache.org/jira/browse/SOLR-918 > Project: Solr > Issue Type: Bug >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-918.patch > > > SolrCore.infoRegistry is used for keeping a reference to the SolrInfoMBean > objects. When JMX is disabled, it is initialized to a LinkedHashMap which is > not synchronized. > We can change this to a ConcurrentHashMap instead of a LinkedHashMap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-927) remove synchronization from lazy loaded handlers
[ https://issues.apache.org/jira/browse/SOLR-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley resolved SOLR-927. --- Resolution: Fixed Fix Version/s: 1.4 committed. > remove synchronization from lazy loaded handlers > > > Key: SOLR-927 > URL: https://issues.apache.org/jira/browse/SOLR-927 > Project: Solr > Issue Type: Improvement >Reporter: Yonik Seeley >Priority: Trivial > Fix For: 1.4 > > Attachments: SOLR-927.patch > > > A synchronized method is called to get the wrapped handler - this can be > changed to a volatile. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-911) multi-select facets
[ https://issues.apache.org/jira/browse/SOLR-911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley resolved SOLR-911. --- Resolution: Fixed Committed. I don't believe there are changes suggested to the API, just possible additions. We can iterate or improve before 1.4. > multi-select facets > --- > > Key: SOLR-911 > URL: https://issues.apache.org/jira/browse/SOLR-911 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Yonik Seeley > Fix For: 1.4 > > Attachments: SOLR-911.patch, SOLR-911.patch, SOLR-911.patch > > > plumbing to support the selection of multiple constraints in a facet -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-885) Generify NamedListCodec
[ https://issues.apache.org/jira/browse/SOLR-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657487#action_12657487 ] Yonik Seeley commented on SOLR-885: --- What is gained by making NamedListCodec a generic? > Generify NamedListCodec > --- > > Key: SOLR-885 > URL: https://issues.apache.org/jira/browse/SOLR-885 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-885.patch, SOLR-885.patch, SOLR-885.patch > > > * make NamedListCodec a generic class which may be able to write any of the > supported object > * Deprecate NamedList and use only SimpleOrderedMap. (Yes it is backward > compatible) > * Ideally I wish to call this JavabinCodec because it should be able to be > used to write any kind of supported objects -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-84) Logo Contests
[ https://issues.apache.org/jira/browse/SOLR-84?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michiel updated SOLR-84: Attachment: solr_logo.rar > Logo Contests > - > > Key: SOLR-84 > URL: https://issues.apache.org/jira/browse/SOLR-84 > Project: Solr > Issue Type: Improvement >Reporter: Bertrand Delacretaz >Priority: Minor > Attachments: apache-solr-004.png, apache_soir_001.ai.zip, > apache_soir_001.jpg, apache_solr_a_blue.jpg, apache_solr_a_red.jpg, > apache_solr_b_blue.jpg, apache_solr_b_red.jpg, apache_solr_burning.png, > apache_solr_c_blue.jpg, apache_solr_c_blue_shirt.jpg, apache_solr_c_red.jpg, > apache_solr_c_red.jpg, apache_solr_contour.png, apache_solr_sun.png, > logo-grid.jpg, logo-solr-d.jpg, logo-solr-e.jpg, > logo-solr-source-files-take2.zip, logo_remake.jpg, logo_remake.svg, > solr-84-source-files.zip, solr-circle-grad.png, solr-f.jpg, > solr-greyscale.png, solr-logo-20061214.jpg, solr-logo-20061218.JPG, > solr-logo-20070124.JPG, solr-logo.jpg, solr-logo.png, solr-nick.gif, > solr-solid-R.png, solr-solid.png, solr.jpg, solr.png, solr.s1.jpg, > solr.s2.jpg, solr.s3.jpg, solr.s4.jpg, solr.s5.jpg, solr.s7.jpg, solr.svg, > solr2_maho-vote.png, solr2_maho.png, solr2_maho_impression.png, > solr3_maho.png, solr_attempt.jpg, solr_attempt2.jpg, solr_logo.rar, > solr_sp.png, solrlogo.jpg, solrlogo2.jpg, sslogo-solr-70s.png, > sslogo-solr-classic.png, sslogo-solr-dance.png, sslogo-solr-fiesta.png, > sslogo-solr-finder2.0.png > > > This issue was original a scratch pad for various ideas for new Logos. It is > now being used as a repository for submissions for the Solr Logo Contest... >http://wiki.apache.org/solr/LogoContest > Note that many of the images currently attached are not eligible for the > contest since they do not meet the official guidelines for new Apache project > logos (in particular that the full project name "Apache Solr" must be > included in the Logo). Only eligible attachments will be included in the > official voting. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-927) remove synchronization from lazy loaded handlers
remove synchronization from lazy loaded handlers Key: SOLR-927 URL: https://issues.apache.org/jira/browse/SOLR-927 Project: Solr Issue Type: Improvement Reporter: Yonik Seeley Priority: Trivial Attachments: SOLR-927.patch A synchronized method is called to get the wrapped handler - this can be changed to a volatile. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-927) remove synchronization from lazy loaded handlers
[ https://issues.apache.org/jira/browse/SOLR-927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-927: -- Attachment: SOLR-927.patch > remove synchronization from lazy loaded handlers > > > Key: SOLR-927 > URL: https://issues.apache.org/jira/browse/SOLR-927 > Project: Solr > Issue Type: Improvement >Reporter: Yonik Seeley >Priority: Trivial > Attachments: SOLR-927.patch > > > A synchronized method is called to get the wrapped handler - this can be > changed to a volatile. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SOLR-711) SimpleFacets: Performance Boost for Tokenized Fields for smaller DocSet using Term Vectors
[
https://issues.apache.org/jira/browse/SOLR-711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fuad Efendi closed SOLR-711.
Resolution: Fixed
Thanks Shalin for pointing to SOLR-475 which is very advanced solution to term
counting approach.
> SimpleFacets: Performance Boost for Tokenized Fields for smaller DocSet using
> Term Vectors
> --
>
> Key: SOLR-711
> URL: https://issues.apache.org/jira/browse/SOLR-711
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 1.3
>Reporter: Fuad Efendi
> Fix For: 1.4
>
> Original Estimate: 1680h
> Remaining Estimate: 1680h
>
> From
> [http://www.nabble.com/SimpleFacets%3A-Performance-Boost-for-Tokenized-Fields-td19033760.html]:
> Scenario:
> - 10,000,000 documents in the index;
> - 5-10 terms per document;
> - 200,000 unique terms for a tokenized field.
> _Obviously calculating sizes of 200,000 intersections with FilterCache is 100
> times slower than traversing 10 - 20,000 documents for smaller DocSets and
> counting frequencies of Terms._
> Not applicable if size of DocSet is close to total number of unique tokens
> (200,000 in our scenario).
> See SimpleFacets.java:
> {code}
> public NamedList getFacetTermEnumCounts(
> SolrIndexSearcher searcher,
> DocSet docs, ...
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-922) Solr WebApp wide Executor for better efficient management of threads , separating the logic in the thread from the launch of the same.
[ https://issues.apache.org/jira/browse/SOLR-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657432#action_12657432 ] Kay Kay commented on SOLR-922: -- | But the risk is that we will never know that which consumer is eating up the threads and some other consumers will be starved for threads. These things become hard to debug. Sure. Suppose - we have multiple plugins to the Solr system and consumers are starved for threads, (assuming a uniform ExecutorService) , we can load the number of threads in the thread pool configurable from a property in the Solr System or change the policy of creation ( FixedSize / CachedPools etc. ) at one point and experiment with the same. On the other hand - having local ExecutorServices for modules would mean optimizing the problem locally in that module / creating multiple static thread pools , adding to the global memory usage quickly when in reality they cannot be used interchangeably ( A local ExecutorService in DIH - would probably not be accessible to SnapPuller, say). Having a central control over the resources might be more beneficial in this case. > Solr WebApp wide Executor for better efficient management of threads , > separating the logic in the thread from the launch of the same. > --- > > Key: SOLR-922 > URL: https://issues.apache.org/jira/browse/SOLR-922 > Project: Solr > Issue Type: Improvement > Components: clients - java > Environment: Tomcat 6, JRE 6 >Reporter: Kay Kay >Priority: Minor > > For a different jira - when we were discussing bringing in parallelism > through threads and using Executors - encountered a case of using a webapp > wide Executor for reusing thread pools for better use of thread resources , > instead of thread.start() . > pros: Custom Request Handlers and other plugins to the Solr App server can > use this Executor API to retrieve the executor and just submit the Runnable / > Callable impls to get the job done while getting the benefits of a thread > pool . This might be necessary as we continue to write plugins to the core > architecture and centralizing the threadpools might make it easy to control / > prevent global Executor objects across the codebase / recreating them locally > ( as they might be expensive ). > $ find . -name *.java | xargs grep -nr 'start()' | grep "}" > ./contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/XPathEntityProcessor.java:377: > }.start(); > ./contrib/dataimporthandler/src/main/java/org/apache/solr/handler/dataimport/DataImporter.java:368: > }.start(); > ./src/java/org/apache/solr/handler/SnapPuller.java:382:}.start(); > ./src/java/org/apache/solr/handler/SnapShooter.java:52:}.start(); > ./src/java/org/apache/solr/handler/ReplicationHandler.java:134: > }.start(); > ./src/common/org/apache/solr/common/util/ConcurrentLRUCache.java:112: > }.start(); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-916) CoreContainer :: register(String, SolrCore, boolean) documentation clarification about returnPrev argument
[ https://issues.apache.org/jira/browse/SOLR-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657425#action_12657425 ] Kay Kay commented on SOLR-916: -- Can somebody familiar with this part - confirm / add more light on what the third argument supposedly is intended to do (as compared to what it is doing today ). > CoreContainer :: register(String, SolrCore, boolean) documentation > clarification about returnPrev argument > --- > > Key: SOLR-916 > URL: https://issues.apache.org/jira/browse/SOLR-916 > Project: Solr > Issue Type: Improvement > Components: documentation >Affects Versions: 1.3 > Environment: Tomcat 6, JRE 6 >Reporter: Kay Kay >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-916.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > In CoreContainer.java :: register(name, core, returnPrev) - the documentation > says > it would return a previous core having the same name if it existed *and > returnPrev = true*. > * @return a previous core having the same name if it existed and > returnPrev==true > */ > public SolrCore register(String name, SolrCore core, boolean returnPrev) .. > But as per the code towards the end - the previous core is returned anyway, > irrespective of the value of returnPrev. The difference, though, seems to be > that when returnPrev is false, the previous core (of the same name, if > exists) is closed. > Which one of them is correct . If the code were correct , would the variable > be better renamed as closePrevious , as opposed to returnPrevious. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-924) Solr: Making finalizers call super.finalize() wrapped in try..finally block
[ https://issues.apache.org/jira/browse/SOLR-924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657421#action_12657421 ] Kay Kay commented on SOLR-924: -- Not all of them seems to inherit from Object ( JdbcDataSource inherits from DataSource ). SolrIndexWriter from IndexWriter etc. So - to ensure proper cleanup of resources - we need to be having the try .. finally block around finalizers. > Solr: Making finalizers call super.finalize() wrapped in try..finally block > > > Key: SOLR-924 > URL: https://issues.apache.org/jira/browse/SOLR-924 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler, replication (java) > Environment: Tomcat 6, JRE 6 >Reporter: Kay Kay >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-924.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > There are some occurences of finalizers in the code base. While the presence > of them is debatable and discussed in a separate JIRA - the ones that are > retained are better off wrapped around a try .. finally block to recursively > call the finalizer of the super class for proper resource usage unwinding , > (in case finalizers get invoked ). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-885) Generify NamedListCodec
[ https://issues.apache.org/jira/browse/SOLR-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657384#action_12657384 ] Noble Paul commented on SOLR-885: - My second last patch and the latest patch has only this one difference (the rename) > Generify NamedListCodec > --- > > Key: SOLR-885 > URL: https://issues.apache.org/jira/browse/SOLR-885 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-885.patch, SOLR-885.patch, SOLR-885.patch > > > * make NamedListCodec a generic class which may be able to write any of the > supported object > * Deprecate NamedList and use only SimpleOrderedMap. (Yes it is backward > compatible) > * Ideally I wish to call this JavabinCodec because it should be able to be > used to write any kind of supported objects -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-885) Generify NamedListCodec
[ https://issues.apache.org/jira/browse/SOLR-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657383#action_12657383 ] Shalin Shekhar Mangar commented on SOLR-885: This looks good Noble. Let us do the rename as another patch/commit. It is difficult to figure out the changes with the renamed source file. We also need to update the Javadocs. > Generify NamedListCodec > --- > > Key: SOLR-885 > URL: https://issues.apache.org/jira/browse/SOLR-885 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-885.patch, SOLR-885.patch, SOLR-885.patch > > > * make NamedListCodec a generic class which may be able to write any of the > supported object > * Deprecate NamedList and use only SimpleOrderedMap. (Yes it is backward > compatible) > * Ideally I wish to call this JavabinCodec because it should be able to be > used to write any kind of supported objects -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-885) Generify NamedListCodec
[ https://issues.apache.org/jira/browse/SOLR-885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-885: Attachment: SOLR-885.patch NamedListCodec is renamed as JavabinCodec over and above the previous patch > Generify NamedListCodec > --- > > Key: SOLR-885 > URL: https://issues.apache.org/jira/browse/SOLR-885 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-885.patch, SOLR-885.patch, SOLR-885.patch > > > * make NamedListCodec a generic class which may be able to write any of the > supported object > * Deprecate NamedList and use only SimpleOrderedMap. (Yes it is backward > compatible) > * Ideally I wish to call this JavabinCodec because it should be able to be > used to write any kind of supported objects -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-885) Generify NamedListCodec
[ https://issues.apache.org/jira/browse/SOLR-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657381#action_12657381 ] noble.paul edited comment on SOLR-885 at 12/17/08 5:29 AM: --- NamedListCodec is renamed as JavabinCodec over and above the previous patch NamedListCodec now extends JavabinCodec and it is also marked as deprected was (Author: noble.paul): NamedListCodec is renamed as JavabinCodec over and above the previous patch > Generify NamedListCodec > --- > > Key: SOLR-885 > URL: https://issues.apache.org/jira/browse/SOLR-885 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-885.patch, SOLR-885.patch, SOLR-885.patch > > > * make NamedListCodec a generic class which may be able to write any of the > supported object > * Deprecate NamedList and use only SimpleOrderedMap. (Yes it is backward > compatible) > * Ideally I wish to call this JavabinCodec because it should be able to be > used to write any kind of supported objects -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-917) RequestHandlers#handlers is a synchronizedMap()
[
https://issues.apache.org/jira/browse/SOLR-917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar resolved SOLR-917.
Resolution: Fixed
Assignee: Shalin Shekhar Mangar
Committed revision 727372.
Thanks Noble!
> RequestHandlers#handlers is a synchronizedMap()
> ---
>
> Key: SOLR-917
> URL: https://issues.apache.org/jira/browse/SOLR-917
> Project: Solr
> Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 1.4
>
> Attachments: SOLR-917.patch, SOLR-917.patch
>
>
> {code}
> private final Map handlers =
> Collections.synchronizedMap(
> new HashMap() );
> {code}
> this map is queried for every request and it can easily be made
> ConcurrentHashMap
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-918) Thread safety issue in SolrCore.infoRegistry
[ https://issues.apache.org/jira/browse/SOLR-918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-918. Resolution: Fixed Assignee: Shalin Shekhar Mangar Committed revision 727370. > Thread safety issue in SolrCore.infoRegistry > > > Key: SOLR-918 > URL: https://issues.apache.org/jira/browse/SOLR-918 > Project: Solr > Issue Type: Bug >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-918.patch > > > SolrCore.infoRegistry is used for keeping a reference to the SolrInfoMBean > objects. When JMX is disabled, it is initialized to a LinkedHashMap which is > not synchronized. > We can change this to a ConcurrentHashMap instead of a LinkedHashMap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-918) Thread safety issue in SolrCore.infoRegistry
[ https://issues.apache.org/jira/browse/SOLR-918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-918: --- Attachment: SOLR-918.patch Patch to change LinkedHashMap to ConcurrentHashMap. I plan to commit shortly. > Thread safety issue in SolrCore.infoRegistry > > > Key: SOLR-918 > URL: https://issues.apache.org/jira/browse/SOLR-918 > Project: Solr > Issue Type: Bug >Reporter: Shalin Shekhar Mangar >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-918.patch > > > SolrCore.infoRegistry is used for keeping a reference to the SolrInfoMBean > objects. When JMX is disabled, it is initialized to a LinkedHashMap which is > not synchronized. > We can change this to a ConcurrentHashMap instead of a LinkedHashMap. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-926) Exception in Replication
[ https://issues.apache.org/jira/browse/SOLR-926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-926: Component/s: replication (java) > Exception in Replication > > > Key: SOLR-926 > URL: https://issues.apache.org/jira/browse/SOLR-926 > Project: Solr > Issue Type: Bug > Components: replication (java) >Reporter: Noble Paul > Fix For: 1.4 > > > While running the replication testcase (TestReplicationHandler) > I get an exception > Dec 17, 2008 6:22:12 PM org.apache.solr.common.SolrException log > SEVERE: java.util.concurrent.RejectedExecutionException > at > java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1477) > at > java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:384) > at > java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:856) > at > java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:45) > at > java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:606) > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1175) > at > org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:350) > at org.apache.solr.handler.SnapPuller.doCommit(SnapPuller.java:369) > at org.apache.solr.handler.SnapPuller.fetchLatestIndex(SnapPuller.java:278) > at > org.apache.solr.handler.ReplicationHandler.doSnapPull(ReplicationHandler.java:211) > at org.apache.solr.handler.SnapPuller$1.run(SnapPuller.java:138) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417) > at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:280) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:135) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:65) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:142) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:166) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) > at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-926) Exception in Replication
Exception in Replication Key: SOLR-926 URL: https://issues.apache.org/jira/browse/SOLR-926 Project: Solr Issue Type: Bug Reporter: Noble Paul Fix For: 1.4 While running the replication testcase (TestReplicationHandler) I get an exception Dec 17, 2008 6:22:12 PM org.apache.solr.common.SolrException log SEVERE: java.util.concurrent.RejectedExecutionException at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1477) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:384) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:856) at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:45) at java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:606) at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1175) at org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:350) at org.apache.solr.handler.SnapPuller.doCommit(SnapPuller.java:369) at org.apache.solr.handler.SnapPuller.fetchLatestIndex(SnapPuller.java:278) at org.apache.solr.handler.ReplicationHandler.doSnapPull(ReplicationHandler.java:211) at org.apache.solr.handler.SnapPuller$1.run(SnapPuller.java:138) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417) at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:280) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:135) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:65) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:142) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:166) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iván de Prado updated SOLR-236: --- Attachment: collapsing-patch-to-1.3.0-ivan_3.patch Karsten Sperling was right. Seems that there was a wrong bounds initialization for the OpenBitSet. I have solved it and attached a new patch. Stephen Weiss, can you test if now the error has disappeared? Thanks. > Field collapsing > > > Key: SOLR-236 > URL: https://issues.apache.org/jira/browse/SOLR-236 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Emmanuel Keller > Fix For: 1.4 > > Attachments: collapsing-patch-to-1.3.0-ivan.patch, > collapsing-patch-to-1.3.0-ivan_2.patch, > collapsing-patch-to-1.3.0-ivan_3.patch, > field-collapsing-extended-592129.patch, field_collapsing_1.1.0.patch, > field_collapsing_1.3.patch, field_collapsing_dsteigerwald.diff, > field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, > SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, > SOLR-236-FieldCollapsing.patch, solr-236.patch > > > This patch include a new feature called "Field collapsing". > "Used in order to collapse a group of results with similar value for a given > field to a single entry in the result set. Site collapsing is a special case > of this, where all results for a given web site is collapsed into one or two > entries in the result set, typically with an associated "more documents from > this site" link. See also Duplicate detection." > http://www.fastsearch.com/glossary.aspx?m=48&amid=299 > The implementation add 3 new query parameters (SolrParams): > "collapse.field" to choose the field used to group results > "collapse.type" normal (default value) or adjacent > "collapse.max" to select how many continuous results are allowed before > collapsing > TODO (in progress): > - More documentation (on source code) > - Test cases > Two patches: > - "field_collapsing.patch" for current development version > - "field_collapsing_1.1.0.patch" for Solr-1.1.0 > P.S.: Feedback and misspelling correction are welcome ;-) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-886) DataImportHandler should rollback when an import fails or is aborted
[ https://issues.apache.org/jira/browse/SOLR-886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-886. Resolution: Fixed Committed revision 727357. > DataImportHandler should rollback when an import fails or is aborted > > > Key: SOLR-886 > URL: https://issues.apache.org/jira/browse/SOLR-886 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.4 >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Fix For: 1.4 > > Attachments: SOLR-886.patch, SOLR-886.patch > > > DataImportHandler should call rollback when an import fails or is aborted. > This will make sure that uncommitted changes are not committed when the > IndexWriter is closed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-886) DataImportHandler should rollback when an import fails or is aborted
[ https://issues.apache.org/jira/browse/SOLR-886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-886: --- Attachment: SOLR-886.patch Attached patch fixes the issue. I plan to commit shortly. > DataImportHandler should rollback when an import fails or is aborted > > > Key: SOLR-886 > URL: https://issues.apache.org/jira/browse/SOLR-886 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.4 >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > Fix For: 1.4 > > Attachments: SOLR-886.patch, SOLR-886.patch > > > DataImportHandler should call rollback when an import fails or is aborted. > This will make sure that uncommitted changes are not committed when the > IndexWriter is closed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-711) SimpleFacets: Performance Boost for Tokenized Fields for smaller DocSet using Term Vectors
[
https://issues.apache.org/jira/browse/SOLR-711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657362#action_12657362
]
Shalin Shekhar Mangar commented on SOLR-711:
With the new performance changes in faceting with SOLR-475, is this issue still
relevant?
> SimpleFacets: Performance Boost for Tokenized Fields for smaller DocSet using
> Term Vectors
> --
>
> Key: SOLR-711
> URL: https://issues.apache.org/jira/browse/SOLR-711
> Project: Solr
> Issue Type: Improvement
> Components: search
>Affects Versions: 1.3
>Reporter: Fuad Efendi
> Fix For: 1.4
>
> Original Estimate: 1680h
> Remaining Estimate: 1680h
>
> From
> [http://www.nabble.com/SimpleFacets%3A-Performance-Boost-for-Tokenized-Fields-td19033760.html]:
> Scenario:
> - 10,000,000 documents in the index;
> - 5-10 terms per document;
> - 200,000 unique terms for a tokenized field.
> _Obviously calculating sizes of 200,000 intersections with FilterCache is 100
> times slower than traversing 10 - 20,000 documents for smaller DocSets and
> counting frequencies of Terms._
> Not applicable if size of DocSet is close to total number of unique tokens
> (200,000 in our scenario).
> See SimpleFacets.java:
> {code}
> public NamedList getFacetTermEnumCounts(
> SolrIndexSearcher searcher,
> DocSet docs, ...
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-913) org/apache/solr/handler/SnapPuller.java - Expensive Pattern object made static (HttpClient object too )
[ https://issues.apache.org/jira/browse/SOLR-913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-913. Resolution: Fixed Committed revision 727354. Thanks Kay! > org/apache/solr/handler/SnapPuller.java - Expensive Pattern object made > static (HttpClient object too ) > - > > Key: SOLR-913 > URL: https://issues.apache.org/jira/browse/SOLR-913 > Project: Solr > Issue Type: Improvement > Components: replication (java) > Environment: Tomcat 6, JRE 6 >Reporter: Kay Kay >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-913.patch, SOLR-913.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > In the class - org.apache.solr.handler.SnapPuller - there seems to be an > expensive Pattern object created locally in the method > static Integer readInterval(String interval) ; > Pattern instances are better created as static objects and reused. > The same is true for HttpClient instances. These are one per core right now. > We can make that static too. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-925) Highlighter doesn't work on a field which is multiValued="true" and termOffsets="true"
Highlighter doesn't work on a field which is multiValued="true" and
termOffsets="true"
--
Key: SOLR-925
URL: https://issues.apache.org/jira/browse/SOLR-925
Project: Solr
Issue Type: Bug
Components: highlighter
Affects Versions: 1.3
Reporter: Koji Sekiguchi
Priority: Minor
This seems to be introduced at r674677.
{panel}
java.lang.StringIndexOutOfBoundsException: String index out of range: 15
at java.lang.String.substring(Unknown Source)
at
org.apache.lucene.search.highlight.Highlighter.getBestTextFragments(Highlighter.java:239)
at
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlighting(DefaultSolrHighlighter.java:310)
at
org.apache.solr.handler.component.HighlightComponent.process(HighlightComponent.java:83)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:171)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:131)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1313)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:303)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:232)
at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)
at
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405)
at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:211)
at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)
at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:285)
at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502)
at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:821)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378)
at
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226)
at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
{panel}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-821) replication must allow copying conf file in a different name to slave
[
https://issues.apache.org/jira/browse/SOLR-821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar resolved SOLR-821.
Resolution: Fixed
Committed revision 727319.
Thanks Akshay and Noble!
> replication must allow copying conf file in a different name to slave
> -
>
> Key: SOLR-821
> URL: https://issues.apache.org/jira/browse/SOLR-821
> Project: Solr
> Issue Type: Improvement
>Reporter: Noble Paul
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 1.4
>
> Attachments: SOLR-821.patch, SOLR-821.patch, SOLR-821.patch,
> SOLR-821.patch, SOLR-821.patch
>
>
> It is likely that a file is different in master and slave. for instance
> replicating solrconfig.xml is not possible with the current config if master
> and slave has diffferent solrconfig.xml (which is always true)
> We can add an alias feature in the confFiles as
> {code}
> name="confFiles">slave_solrconfig.xml:solrconfig.xml,slave_schema.xml:schema.xml
> {code}
> This means that the file slave_solrconfig.xml should be copied to the slave
> as solrconfig.xml and slave_schema.xml must be saved to slave as schema.xml
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Hudson build is back to normal: Solr-trunk #657
See http://hudson.zones.apache.org/hudson/job/Solr-trunk/657/changes
