Re: CHANGES.txt
I've created client/ruby/CHANGES.txt to care for both solr-ruby and flare. Koji Erik Hatcher wrote: On Aug 14, 2008, at 10:40 PM, Koji Sekiguchi wrote: > the ruby client has its own changelog. Oops. I wasn't aware of it's existence. But it's name is CHANGES.yml, not CHANGES.txt, and the contents look like gem update info maintained by Erik. If Solrj and DIH have their own CHANGES.txt, should solr-ruby have its CHANGES.txt? CHANGES.yml was just me being different and having a structured usable change log, just showing off. it's manually maintained and isn't being used for gems per se (other than manually copying/pasting the log over into rubyforge's form when pushing a new gem). i dunno, i kinda like CHANGES.yml myself, but i'm not doing near as much Ruby as I'd like these days so whoever has a scratch to itch down there, go for it. Erik
Re: svn commit: r685497 - in /lucene/solr/trunk: ./ client/java/solrj/ contrib/dataimporthandler/ lib/
On Fri, Aug 15, 2008 at 11:37 AM, Chris Hostetter <[EMAIL PROTECTED]>wrote: > I know it's only 3 new files, but it's 3 file that can really live > anywhere, which means it's 3 more then we *need* in the root dir ... every > time we add something there it increases the clutter people see when > getting the source, and distracts from the files people should be looking > at first (README.txt, CHANGES.txt, build.xml, etc...) > > (i'm not a fan of Lucene-Java having them in the root either) Makes sense. Done. -- Regards, Shalin Shekhar Mangar.
[jira] Updated: (SOLR-647) Do SolrCore.close() in a refcounted way
[ https://issues.apache.org/jira/browse/SOLR-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-647: -- Attachment: solr-647.patch Here's an updated patch: - cores is a Map - no prohibition of adding a SolrCore to the CoreContainer multiple times (to be able to access it from multiple URLs, for back compatible migration for example) I was going to remove the SolrCore name altogether but things like JMX and logging use it. That's a weakness in both the way multicore worked (core swap wouldn't swap JMX) and the current patch (core name is independent of how it's mapped via CoreContainer). One resolution would be to have a callback on SolrCore whenever it's name is changed, so JMX and logging strings could be appropriately adjusted. > Do SolrCore.close() in a refcounted way > --- > > Key: SOLR-647 > URL: https://issues.apache.org/jira/browse/SOLR-647 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Noble Paul >Assignee: Yonik Seeley > Fix For: 1.3 > > Attachments: refcount_example.patch, solr-647.patch, solr-647.patch, > solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch, > solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch, > SOLR-647.patch, SOLR-647.patch > > > The method _SolrCore.close()_ directly closes the core . It can cause > Exceptions for in-flight requests. The _close()_ method should just do a > decrement on refcount and the actual close must happen when the last request > being processed by that core instance is completed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-647) Do SolrCore.close() in a refcounted way
[ https://issues.apache.org/jira/browse/SOLR-647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-647: -- Attachment: solr-647.patch > Do SolrCore.close() in a refcounted way > --- > > Key: SOLR-647 > URL: https://issues.apache.org/jira/browse/SOLR-647 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Noble Paul >Assignee: Yonik Seeley > Fix For: 1.3 > > Attachments: refcount_example.patch, solr-647.patch, solr-647.patch, > solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch, > solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch, > solr-647.patch, SOLR-647.patch, SOLR-647.patch > > > The method _SolrCore.close()_ directly closes the core . It can cause > Exceptions for in-flight requests. The _close()_ method should just do a > decrement on refcount and the actual close must happen when the last request > being processed by that core instance is completed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: CHANGES.txt
On Aug 16, 2008, at 7:45 AM, Koji Sekiguchi wrote: I've created client/ruby/CHANGES.txt to care for both solr-ruby and flare. What?! No rake task to generate it from the YAML? ;) just teasin... Erik
[jira] Commented: (SOLR-647) Do SolrCore.close() in a refcounted way
[ https://issues.apache.org/jira/browse/SOLR-647?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12623173#action_12623173 ] Ryan McKinley commented on SOLR-647: bq. I was going to remove the SolrCore name altogether but things like JMX and logging use it. Can we remove it and always access the name via the CoreDescriptor? Having a name on the core made sense before we added the descriptor... > Do SolrCore.close() in a refcounted way > --- > > Key: SOLR-647 > URL: https://issues.apache.org/jira/browse/SOLR-647 > Project: Solr > Issue Type: Bug >Affects Versions: 1.3 >Reporter: Noble Paul >Assignee: Yonik Seeley > Fix For: 1.3 > > Attachments: refcount_example.patch, solr-647.patch, solr-647.patch, > solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch, > solr-647.patch, solr-647.patch, solr-647.patch, solr-647.patch, > solr-647.patch, SOLR-647.patch, SOLR-647.patch > > > The method _SolrCore.close()_ directly closes the core . It can cause > Exceptions for in-flight requests. The _close()_ method should just do a > decrement on refcount and the actual close must happen when the last request > being processed by that core instance is completed -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: CHANGES.txt
>> I've created client/ruby/CHANGES.txt to care for both solr-ruby and flare. > What?! No rake task to generate it from the YAML? ;) After all, I'd like to maintain client/ruby/solr-ruby/CHANGES.yml rather than client/ruby/CHANGES.txt. Now I delete CHANGES.txt: $ svn commit Deleting client/ruby/CHANGES.txt Sendingclient/ruby/solr-ruby Committed revision 686583. BTW, latest solr-ruby version is v0.0.6. How about v1.0 or v1.3 when solr 1.3 is released? Koji
