[jira] Created: (SOLR-1490) URLDataSource should be able to handle HTTP authentication
URLDataSource should be able to handle HTTP authentication -- Key: SOLR-1490 URL: https://issues.apache.org/jira/browse/SOLR-1490 Project: Solr Issue Type: Improvement Components: contrib - DataImportHandler Reporter: Adam Foltzer Right now, there seems to be no way to provide HTTP authentication (username/password) to the URLDataSource. This makes any password-protected data sources inaccessible for indexing. I would try and add support myself, but with all things security-related, I'm fearful of shooting myself in the foot with systems I don't fully understand. Thanks for your time/feedback! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (SOLR-1489) A UTF-8 character is output twice (Bug in Jetty)
[ https://issues.apache.org/jira/browse/SOLR-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi reassigned SOLR-1489: Assignee: Koji Sekiguchi > A UTF-8 character is output twice (Bug in Jetty) > > > Key: SOLR-1489 > URL: https://issues.apache.org/jira/browse/SOLR-1489 > Project: Solr > Issue Type: Bug > Environment: Jetty-6.1.3 > Jetty-6.1.21 > Jetty-7.0.0RC6 >Reporter: Jun Ohtani >Assignee: Koji Sekiguchi >Priority: Critical > Attachments: error_utf8-example.xml, jettybugsample.war > > > A UTF-8 character is output twice under particular conditions. > Attach the sample data.(error_utf8-example.xml) > Registered only sample data, click the following URL. > http://localhost:8983/solr/select?q=*%3A*&version=2.2&start=0&rows=10&omitHeader=true&fl=attr_json&wt=json > Sample data is only "Ｂ", but response is "ＢＢ". > When wt=phps, error occurs in PHP unsrialize() function. > This bug is like a bug in Jetty. > jettybugsample.war is the simplest one to reproduce the problem. > Copy example/webapps, and start Jetty server, and click the following URL. > http://localhost:8983/jettybugsample/filter/hoge > Like earlier, B is output twice. Sysout only B once. > I have tested this on Jetty 6.1.3 and 6.1.21, 7.0.0rc6. > (When testing with 6.1.21or 7.0.0rc6, change "bufsize" from 128 to 512 in > web.xml. ) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1475) Java-based replication doesn't properly reserve its commit point during backups
[
https://issues.apache.org/jira/browse/SOLR-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761976#action_12761976
]
Mark Miller commented on SOLR-1475:
---
New patch coming soon -
cleans up some of what I mention and fixes what appears to be a little bug -
you can't get stats about the backup details unless tempSnapPuller != null - so
if you don't do a fetch first, and just ask for a backup, that means you can't
get the details on your backup's success and whatnot. So I have moved that out
of the if block that prevents it.
> Java-based replication doesn't properly reserve its commit point during
> backups
> ---
>
> Key: SOLR-1475
> URL: https://issues.apache.org/jira/browse/SOLR-1475
> Project: Solr
> Issue Type: Bug
> Components: replication (java)
>Affects Versions: 1.4
>Reporter: Chris Harris
> Fix For: 1.4
>
> Attachments: SOLR-1475.patch, SOLR-1475.patch
>
>
> The issue title reflects Mark Miller's initial diagnosis of the problem.
> Here are my symptoms:
> This is regarding the backup feature of replication, as opposed to
> replication. Backups seem to work fine on toy indexes. When trying backups
> out on a copy of my production index (300GB-ish), though, I'm getting
> FileNotFoundExceptions. These cancel the backup, and delete the
> snapshot.mmdd* directory. It seems reproducible, in that every time I try
> to make a backup of my large index it will fail the same way.
> This is Solr r815830. I'm not sure if this is something that would
> potentially be addressed by SOLR-1458? (That patch is from after r815830.)
> For now I'm not using any event-based backup triggers; instead I'm manually
> hitting
> http://master_host:port/solr/replication?command=backup
> This successfully sets off a snapshot, as seen in a thread dump. However,
> after a while the snapshot fails. I'll paste in a couple of stack traces
> below.
> I haven't seen any other evidence that my index is corrupt; in particular,
> searching the index and Java-based replication seem to be working fine, and
> the Lucene CheckIndex tool did not report any problems with the index.
>
> {code}
> Sep 28, 2009 9:32:18 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\_y0w.fnm' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> Sep 28, 2009 10:39:43 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\segments_by' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> Sep 28, 2009 11:52:08 AM org.apache.solr.handler.SnapShooter createSnapshot
> SEVERE: Exception while creating snapshot
> java.io.FileNotFoundException: Source
> 'E:\tomcat\solrstuff\solr\filingcore\data\index\_yby.nrm' does not
> exist
>at org.apache.commons.io.FileUtils.copyFile(FileUtils.java:637)
>at
> org.apache.commons.io.FileUtils.copyFileToDirectory(FileUtils.java:587)
>at
> org.apache.solr.handler.SnapShooter.createSnapshot(SnapShooter.java:83)
>at org.apache.solr.handler.SnapShooter$1.run(SnapShooter.java:61)
> {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-1294) SolrJS/Javascript client fails in IE8!
[ https://issues.apache.org/jira/browse/SOLR-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761964#action_12761964 ] Grant Ingersoll commented on SOLR-1294: --- Eric, perhaps put up your patch now even though it may not work. Maybe someone else can help. > SolrJS/Javascript client fails in IE8! > -- > > Key: SOLR-1294 > URL: https://issues.apache.org/jira/browse/SOLR-1294 > Project: Solr > Issue Type: Bug >Affects Versions: 1.4 >Reporter: Eric Pugh >Assignee: Ryan McKinley > Fix For: 1.4 > > Attachments: SOLR-1294-IE8.patch, SOLR-1294.patch, > solrjs-ie8-html-syntax-error.patch > > > SolrJS seems to fail with "'jQuery.solrjs' is null or not an object" errors > under IE8. I am continuing to test if this occurs in IE 6 and 7 as well. > This happens on both the Sample online site at > http://solrjs.solrstuff.org/test/reuters/ as well as the > /trunk/contrib/javascript library. Seems to be a show stopper from the > standpoint of really using this library! > I have posted a screenshot of the error at > http://img.skitch.com/20090717-jejm71u6ghf2dpn3mwrkarigwm.png > The error is just a whole bunch of repeated messages in the vein of: > Message: 'jQuery.solrjs' is null or not an object > Line: 24 > Char: 1 > Code: 0 > URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/QueryItem.js > Message: 'jQuery.solrjs' is null or not an object > Line: 37 > Char: 1 > Code: 0 > URI: file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/Manager.js > Message: 'jQuery.solrjs' is null or not an object > Line: 24 > Char: 1 > Code: 0 > URI: > file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractSelectionView.js > Message: 'jQuery.solrjs' is null or not an object > Line: 27 > Char: 1 > Code: 0 > URI: > file:///C:/dev/projects/lib/solr/contrib/javascript/src/core/AbstractWidget.js -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1139) SolrJ TermsComponent Query and Response Support
[ https://issues.apache.org/jira/browse/SOLR-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Weber updated SOLR-1139: - Attachment: SOLR-1139.patch Updated test to use EmbeddedSolrServer and not depend on "example" as Yonik suggested. > SolrJ TermsComponent Query and Response Support > --- > > Key: SOLR-1139 > URL: https://issues.apache.org/jira/browse/SOLR-1139 > Project: Solr > Issue Type: New Feature > Components: clients - java >Affects Versions: 1.4 >Reporter: Matt Weber >Priority: Minor > Attachments: SOLR-1139-WITH_SORT_SUPPORT.patch, SOLR-1139.patch, > SOLR-1139.patch, SOLR-1139.patch, SOLR-1139.patch, SOLR-1139.patch > > > SolrJ should support the new TermsComponent that was introduced in Solr 1.4. > It should be able to: > - set TermsComponent query parameters via SolrQuery > - parse the TermsComponent response -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1319) Upgrade custom Solr Highlighter classes to new Lucene Highlighter API
[ https://issues.apache.org/jira/browse/SOLR-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761949#action_12761949 ] Mark Miller commented on SOLR-1319: --- Right - I don't think its a big deal either. But the Highlighter framework has things like protected methods that are not overridden internally - seems to suggest that users could/might override them - whether we know they do or not, I think thats worth a mention in Changes on the break. Certainly easy enough to do anyway. The break itself is even less likely to be an issue than a custom highlighter in general - I like the completeness myself though. Its an extendable public class and Solr allows for plugins. > Upgrade custom Solr Highlighter classes to new Lucene Highlighter API > - > > Key: SOLR-1319 > URL: https://issues.apache.org/jira/browse/SOLR-1319 > Project: Solr > Issue Type: Task > Components: highlighter >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 1.4 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1469) TestReplicationHandler failure
[ https://issues.apache.org/jira/browse/SOLR-1469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761947#action_12761947 ] Yonik Seeley commented on SOLR-1469: Jetty still fails to come up occasionally, even after waiting 2 minutes. I also tested with the latest Jetty 6.1.21 - same results. At this point, it could still be a Solr bug or a Jetty bug. > TestReplicationHandler failure > -- > > Key: SOLR-1469 > URL: https://issues.apache.org/jira/browse/SOLR-1469 > Project: Solr > Issue Type: Bug >Reporter: Yonik Seeley > Attachments: TestReplicationHandler.FAILED.210743 > > > TestReplicationHandler seems to fail often. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1319) Upgrade custom Solr Highlighter classes to new Lucene Highlighter API
[ https://issues.apache.org/jira/browse/SOLR-1319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761946#action_12761946 ] Yonik Seeley commented on SOLR-1319: if I'm reading this correctly, the back compat break is for those providing their own custom highlighter? That's gotta be almost no one... doesn't seem like a big deal as it seems more like internal implementation than interface. > Upgrade custom Solr Highlighter classes to new Lucene Highlighter API > - > > Key: SOLR-1319 > URL: https://issues.apache.org/jira/browse/SOLR-1319 > Project: Solr > Issue Type: Task > Components: highlighter >Reporter: Mark Miller >Assignee: Mark Miller > Fix For: 1.4 > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1139) SolrJ TermsComponent Query and Response Support
[ https://issues.apache.org/jira/browse/SOLR-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761944#action_12761944 ] Yonik Seeley commented on SOLR-1139: A couple of points about testing: - we should avoid making tests depend on "example" so that it's easier to change in the future when we want - we should avoid creating entire jetty instances unless necessary - EmbeddedSolrServer should work to test basic SolrJ functionallity > SolrJ TermsComponent Query and Response Support > --- > > Key: SOLR-1139 > URL: https://issues.apache.org/jira/browse/SOLR-1139 > Project: Solr > Issue Type: New Feature > Components: clients - java >Affects Versions: 1.4 >Reporter: Matt Weber >Priority: Minor > Attachments: SOLR-1139-WITH_SORT_SUPPORT.patch, SOLR-1139.patch, > SOLR-1139.patch, SOLR-1139.patch, SOLR-1139.patch > > > SolrJ should support the new TermsComponent that was introduced in Solr 1.4. > It should be able to: > - set TermsComponent query parameters via SolrQuery > - parse the TermsComponent response -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1139) SolrJ TermsComponent Query and Response Support
[ https://issues.apache.org/jira/browse/SOLR-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Weber updated SOLR-1139: - Attachment: SOLR-1139.patch Updating patch to work with latest trunk since SOLR-1156 has been committed. Any chance of this making it into 1.4 since it is fairly trivial and the fact TermsComponent is in 1.4? > SolrJ TermsComponent Query and Response Support > --- > > Key: SOLR-1139 > URL: https://issues.apache.org/jira/browse/SOLR-1139 > Project: Solr > Issue Type: New Feature > Components: clients - java >Affects Versions: 1.4 >Reporter: Matt Weber >Priority: Minor > Attachments: SOLR-1139-WITH_SORT_SUPPORT.patch, SOLR-1139.patch, > SOLR-1139.patch, SOLR-1139.patch, SOLR-1139.patch > > > SolrJ should support the new TermsComponent that was introduced in Solr 1.4. > It should be able to: > - set TermsComponent query parameters via SolrQuery > - parse the TermsComponent response -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1485) PayloadTermQuery support
[ https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761931#action_12761931 ] Bill Au commented on SOLR-1485: --- I am +0 on including/excluding this from 1.4. FYI, Solr 1.4 already has a DelimitedPayloadTokenFilterFactory which uses the DelimitedPayloadTokenFIlter in Lucene. If we include this, I think we should also include a Similarity class for payload, either as part of this JIRA or a separate one. There is also a similar JIRA on query support: https://issues.apache.org/jira/browse/SOLR-1337 > PayloadTermQuery support > > > Key: SOLR-1485 > URL: https://issues.apache.org/jira/browse/SOLR-1485 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Erik Hatcher > Attachments: PayloadTermQueryPlugin.java > > > Solr currently has no support for Lucene's PayloadTermQuery, yet it has > support for indexing payloads. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1449) solrconfig.xml syntax to add classpath elements from outside of instanceDir
[ https://issues.apache.org/jira/browse/SOLR-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761925#action_12761925 ] Hoss Man commented on SOLR-1449: bq. Noble has been refactoring SolrConfig in SOLR-1198 with the end goal being pluggable loading of SolrConfig I understand Noble's goal(s) .. i'm actually really stoked to be moving in that direction and look forward to people being able to provide/reuse their own SolrConfig implementations which may not use XML at all... bq. So we need to ask now what is the function of SolrConfig? Do we want it to load/modify SolrResourceLoader objects or just be a representation of configuration? I disagree that we need to ask that question "now", in this issue ... that is an important question for other issues (which you and Noble have already referenced). Those issues are going to face tough decisions about how to deal with the existing contracts of Solr config like all the methods it inherits from Config (including getResourceLoader(), and openResource()) or the fact that all of it's public constructors are expected to initialize a new SolrResourceLoader. When the time comes to make those tough decisions, we will have to make non-back-compat changes to the contracts of SolrConfig and SolrResourceLoader, and document a 'new' contract for how to properly initialize them. *THAT* is the appropriate time (in my opinion) to worry about how we should refactoring all the SolrResourceLoader initialization code -- but today, on the trunk, SolrConfig is still responsible for initializing SolrResourceLoader in many cases. The patch as i wrote it ensures that no matter how a SolrResourceLoader is instantiated, or who instantiates it, if a SolrConfig instance is told to use it, then it gets a class loader based on the options in that SolrConfig. This is the simplest possible patch I could think of to make the change desired. I deliberately avoided making any public API changes to SolrCOnfig or SolrResourceLoader because i didn't want to commit to who/how the ClassLoader would get those changes -- so in the future (when we have to make/advertise big API changes to SolrConfig to eliminate direct references to SOlrResourceLoader anyway) it will be easy to refactor it (the logic in initLibs) to someplace else and document exactly how the SolrResourceLoader should be initialized cleanly. At this point, i personally have no interest in trying to "guess" what the right decisions will be down the road, nor am i interested in writing a more complicated patch that would commit us to that guess with modifications SolrConfig's public API. As i said in a previous comment... bq. if you have any specific suggested improvements for the patch that you think will make eventual work on SOLR-919 easier, then i'm all ears ...but to be more explicit: attach an alternate patch, and i'll review it. > solrconfig.xml syntax to add classpath elements from outside of instanceDir > --- > > Key: SOLR-1449 > URL: https://issues.apache.org/jira/browse/SOLR-1449 > Project: Solr > Issue Type: Improvement >Reporter: Hoss Man >Assignee: Hoss Man > Fix For: 1.4 > > Attachments: SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch, > SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch, SOLR-1449.patch > > > the idea has been discussed numerous times that it would be nice if there was > a way to configure a core to load plugins from specific jars (or "classes" > style directories) by path w/o needing to copy them to the "./lib" dir in > the instanceDir. > The current workaround is "symlinks" but that doesn't really help the > situation of the Solr Release artifacts, where we wind up making numerous > copies of jars to support multiple example directories (you can't have > reliable symlinks in zip files) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1485) PayloadTermQuery support
[ https://issues.apache.org/jira/browse/SOLR-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-1485: --- Fix Version/s: (was: 1.4) Moving out of 1.4 since this is a new feature that isn't ready to commit. As written, it looks more like "rawpayload" or something since no analysis is done on the input. > PayloadTermQuery support > > > Key: SOLR-1485 > URL: https://issues.apache.org/jira/browse/SOLR-1485 > Project: Solr > Issue Type: New Feature > Components: search >Reporter: Erik Hatcher > Attachments: PayloadTermQueryPlugin.java > > > Solr currently has no support for Lucene's PayloadTermQuery, yet it has > support for indexing payloads. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1458) Java Replication error: NullPointerException SEVERE: SnapPull failed on 2009-09-22 nightly
[
https://issues.apache.org/jira/browse/SOLR-1458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761916#action_12761916
]
Yonik Seeley commented on SOLR-1458:
Seems like if you want to replicate only optimized indexes, we should recommend
the user configure SolrDeletionPolicy to always keep an optimized commit point
around.
If you rely on the replication handler to reserve it, it won't work across a
reboot, right?
Although I see no reason for custom delete policies, I'm not really against
adding support for that in the replication handler as long as people are
confident the changes don't introduce any new bugs.
Regardless, I think the separate count for optimized commit points that I added
to SolrDeletionPolicy should remain (esp since it fixed other bugs too).
> Java Replication error: NullPointerException SEVERE: SnapPull failed on
> 2009-09-22 nightly
> --
>
> Key: SOLR-1458
> URL: https://issues.apache.org/jira/browse/SOLR-1458
> Project: Solr
> Issue Type: Bug
> Components: replication (java)
>Affects Versions: 1.4
> Environment: CentOS x64
> 8GB RAM
> Tomcat, running with 7G max memory; memory usage is <2GB, so it's not the
> problem
> Host a: master
> Host b: slave
> Multiple single core Solr instances, using JNDI.
> Java replication
>Reporter: Artem Russakovskii
>Assignee: Yonik Seeley
> Fix For: 1.4
>
> Attachments: SOLR-1458.patch, SOLR-1458.patch, SOLR-1458.patch,
> SOLR-1458.patch, SOLR-1458.patch, SolrDeletionPolicy.patch,
> SolrDeletionPolicy.patch
>
>
> After finally figuring out the new Java based replication, we have started
> both the slave and the master and issued optimize to all master Solr
> instances. This triggered some replication to go through just fine, but it
> looks like some of it is failing.
> Here's what I'm getting in the slave logs, repeatedly for each shard:
> {code}
> SEVERE: SnapPull failed
> java.lang.NullPointerException
> at
> org.apache.solr.handler.SnapPuller.fetchLatestIndex(SnapPuller.java:271)
> at
> org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:258)
> at org.apache.solr.handler.SnapPuller$1.run(SnapPuller.java:159)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at
> java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> {code}
> If I issue an optimize again on the master to one of the shards, it then
> triggers a replication and replicates OK. I have a feeling that these
> SnapPull failures appear later on but right now I don't have enough to form a
> pattern.
> Here's replication.properties on one of the failed slave instances.
> {code}
> cat data/replication.properties
> #Replication details
> #Wed Sep 23 19:35:30 PDT 2009
> replicationFailedAtList=1253759730020,1253759700018,1253759670019,1253759640018,1253759610018,1253759580022,1253759550019,1253759520016,1253759490026,1253759460016
> previousCycleTimeInSeconds=0
> timesFailed=113
> indexReplicatedAtList=1253759730020,1253759700018,1253759670019,1253759640018,1253759610018,1253759580022,1253759550019,1253759520016,1253759490026,1253759460016
> indexReplicatedAt=1253759730020
> replicationFailedAt=1253759730020
> lastCycleBytesDownloaded=0
> timesIndexReplicated=113
> {code}
> and another
> {code}
> cat data/replication.properties
> #Replication details
> #Wed Sep 23 18:42:01 PDT 2009
> replicationFailedAtList=1253756490034,1253756460169
> previousCycleTimeInSeconds=1
> timesFailed=2
> indexReplicatedAtList=1253756521284,1253756490034,1253756460169
> indexReplicatedAt=1253756521284
> replicationFailedAt=1253756490034
> lastCycleBytesDownloaded=22932293
> timesIndexReplicated=3
> {code}
> Some relevant configs:
> In solrconfig.xml:
> {code}
>
>
>
> ${enable.master:false}
> optimize
> optimize
> 00:00:20
>
>
> ${enable.slave:false}
>
> ${master.url}
>
> 00:00:30
>
>
[jira] Updated: (SOLR-1488) autoCommit when idle
[ https://issues.apache.org/jira/browse/SOLR-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-1488: --- Affects Version/s: (was: 1.4) Fix Version/s: (was: 1.4) Pushing this out of this release... it's non-trivial since it interacts with current autocommit code, and we need to stop adding features and get 1.4 out! > autoCommit when idle > > > Key: SOLR-1488 > URL: https://issues.apache.org/jira/browse/SOLR-1488 > Project: Solr > Issue Type: Improvement >Reporter: Matt Weber >Priority: Minor > Attachments: SOLR-1488.patch > > > Enable autoCommit to execute after a given amount of idle time (no documents > submitted). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1488) autoCommit when idle
[ https://issues.apache.org/jira/browse/SOLR-1488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761910#action_12761910 ] Matt Weber commented on SOLR-1488: -- Forgot to mention, the new parameter used to configure this feature is called idleTime. Here is an example that will commit every 100k docs or after 10 seconds of idle time: 10 1 > autoCommit when idle > > > Key: SOLR-1488 > URL: https://issues.apache.org/jira/browse/SOLR-1488 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Matt Weber >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-1488.patch > > > Enable autoCommit to execute after a given amount of idle time (no documents > submitted). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1489) A UTF-8 character is output twice (Bug in Jetty)
[ https://issues.apache.org/jira/browse/SOLR-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761900#action_12761900 ] Koji Sekiguchi commented on SOLR-1489: -- Good catch, Otani-san! I can reproduce the problem with the data and the filter you attached when running it on Jetty. And thank you for opening the JIRA ticket in Jetty. Now we are closing to releasing 1.4, I don't want this to be a blocker because this is not a Solr bug as you said. You can run Solr on arbitrary servlet containers other than Jetty if you'd like. I'd like to keep this opening, and watching http://jira.codehaus.org/browse/JETTY-1122 . Thanks. > A UTF-8 character is output twice (Bug in Jetty) > > > Key: SOLR-1489 > URL: https://issues.apache.org/jira/browse/SOLR-1489 > Project: Solr > Issue Type: Bug > Environment: Jetty-6.1.3 > Jetty-6.1.21 > Jetty-7.0.0RC6 >Reporter: Jun Ohtani >Priority: Critical > Attachments: error_utf8-example.xml, jettybugsample.war > > > A UTF-8 character is output twice under particular conditions. > Attach the sample data.(error_utf8-example.xml) > Registered only sample data, click the following URL. > http://localhost:8983/solr/select?q=*%3A*&version=2.2&start=0&rows=10&omitHeader=true&fl=attr_json&wt=json > Sample data is only "Ｂ", but response is "ＢＢ". > When wt=phps, error occurs in PHP unsrialize() function. > This bug is like a bug in Jetty. > jettybugsample.war is the simplest one to reproduce the problem. > Copy example/webapps, and start Jetty server, and click the following URL. > http://localhost:8983/jettybugsample/filter/hoge > Like earlier, B is output twice. Sysout only B once. > I have tested this on Jetty 6.1.3 and 6.1.21, 7.0.0rc6. > (When testing with 6.1.21or 7.0.0rc6, change "bufsize" from 128 to 512 in > web.xml. ) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1489) A UTF-8 character is output twice (Bug in Jetty)
[ https://issues.apache.org/jira/browse/SOLR-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761884#action_12761884 ] Jun Ohtani commented on SOLR-1489: -- Report Jetty's JIRA. http://jira.codehaus.org/browse/JETTY-1122 > A UTF-8 character is output twice (Bug in Jetty) > > > Key: SOLR-1489 > URL: https://issues.apache.org/jira/browse/SOLR-1489 > Project: Solr > Issue Type: Bug > Environment: Jetty-6.1.3 > Jetty-6.1.21 > Jetty-7.0.0RC6 >Reporter: Jun Ohtani >Priority: Critical > Attachments: error_utf8-example.xml, jettybugsample.war > > > A UTF-8 character is output twice under particular conditions. > Attach the sample data.(error_utf8-example.xml) > Registered only sample data, click the following URL. > http://localhost:8983/solr/select?q=*%3A*&version=2.2&start=0&rows=10&omitHeader=true&fl=attr_json&wt=json > Sample data is only "Ｂ", but response is "ＢＢ". > When wt=phps, error occurs in PHP unsrialize() function. > This bug is like a bug in Jetty. > jettybugsample.war is the simplest one to reproduce the problem. > Copy example/webapps, and start Jetty server, and click the following URL. > http://localhost:8983/jettybugsample/filter/hoge > Like earlier, B is output twice. Sysout only B once. > I have tested this on Jetty 6.1.3 and 6.1.21, 7.0.0rc6. > (When testing with 6.1.21or 7.0.0rc6, change "bufsize" from 128 to 512 in > web.xml. ) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-1489) A UTF-8 character is output twice (Bug in Jetty)
[ https://issues.apache.org/jira/browse/SOLR-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jun Ohtani updated SOLR-1489: - Attachment: jettybugsample.war error_utf8-example.xml Attached sample data and Jetty bug sample program. > A UTF-8 character is output twice (Bug in Jetty) > > > Key: SOLR-1489 > URL: https://issues.apache.org/jira/browse/SOLR-1489 > Project: Solr > Issue Type: Bug > Environment: Jetty-6.1.3 > Jetty-6.1.21 > Jetty-7.0.0RC6 >Reporter: Jun Ohtani >Priority: Critical > Attachments: error_utf8-example.xml, jettybugsample.war > > > A UTF-8 character is output twice under particular conditions. > Attach the sample data.(error_utf8-example.xml) > Registered only sample data, click the following URL. > http://localhost:8983/solr/select?q=*%3A*&version=2.2&start=0&rows=10&omitHeader=true&fl=attr_json&wt=json > Sample data is only "Ｂ", but response is "ＢＢ". > When wt=phps, error occurs in PHP unsrialize() function. > This bug is like a bug in Jetty. > jettybugsample.war is the simplest one to reproduce the problem. > Copy example/webapps, and start Jetty server, and click the following URL. > http://localhost:8983/jettybugsample/filter/hoge > Like earlier, B is output twice. Sysout only B once. > I have tested this on Jetty 6.1.3 and 6.1.21, 7.0.0rc6. > (When testing with 6.1.21or 7.0.0rc6, change "bufsize" from 128 to 512 in > web.xml. ) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-1489) A UTF-8 character is output twice (Bug in Jetty)
A UTF-8 character is output twice (Bug in Jetty) Key: SOLR-1489 URL: https://issues.apache.org/jira/browse/SOLR-1489 Project: Solr Issue Type: Bug Environment: Jetty-6.1.3 Jetty-6.1.21 Jetty-7.0.0RC6 Reporter: Jun Ohtani Priority: Critical A UTF-8 character is output twice under particular conditions. Attach the sample data.(error_utf8-example.xml) Registered only sample data, click the following URL. http://localhost:8983/solr/select?q=*%3A*&version=2.2&start=0&rows=10&omitHeader=true&fl=attr_json&wt=json Sample data is only "Ｂ", but response is "ＢＢ". When wt=phps, error occurs in PHP unsrialize() function. This bug is like a bug in Jetty. jettybugsample.war is the simplest one to reproduce the problem. Copy example/webapps, and start Jetty server, and click the following URL. http://localhost:8983/jettybugsample/filter/hoge Like earlier, B is output twice. Sysout only B once. I have tested this on Jetty 6.1.3 and 6.1.21, 7.0.0rc6. (When testing with 6.1.21or 7.0.0rc6, change "bufsize" from 128 to 512 in web.xml. ) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-1437) DIH: Enhance XPathRecordReader to deal with //tagname and other improvments.
[ https://issues.apache.org/jira/browse/SOLR-1437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761838#action_12761838 ] Fergus McMenemie commented on SOLR-1437: OK! * I have a better method of dealing with //* searches. * I think I know how to only emitting fields associated with the current record. * PutNulls: I can see what it is doing but I still dont know why it is needed. I could understand if there was a requirement that every valid hasText node for a record must be defined or null; but I dont think that is what it id doing? Can you help? > DIH: Enhance XPathRecordReader to deal with //tagname and other improvments. > > > Key: SOLR-1437 > URL: https://issues.apache.org/jira/browse/SOLR-1437 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler >Affects Versions: 1.4 >Reporter: Fergus McMenemie >Assignee: Noble Paul >Priority: Minor > Fix For: 1.5 > > Attachments: SOLR-1437.patch, SOLR-1437.patch > > Original Estimate: 672h > Remaining Estimate: 672h > > As per > http://www.nabble.com/Re%3A-Extract-info-from-parent-node-during-data-import-%28redirect%3A%29-td25471162.html > it would be nice to be able to use expressions such as //tagname when > parsing XML documents. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
