SOLR-13360, spellcheck generates ArrayIndexOutOfBounds
I’ve verified that the error happens, and it’s rather strange how. I won’t be able to pursue it, but if anybody who like spell checking wants to... - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Solr Admin UI Refresh 2020
Gus, SIP sounds good. I will share. Marcus On Mon, Apr 13, 2020 at 09:13 Gus Heck wrote: > Maybe start collecting Design and Design choices in a SIP? This discussion > has been good and there seems to be consensus that we want a new UI, we > want it to be a package and we want the package to be available by default > and well tested. "Package" seems to imply that it can be added or removed > or replaced or an alternative UI installed along side of it. If we got all > of those things done this would be amazingly awesome :) > > Another thing that would be valuable is a good doc that explains "how to > edit and maintain the UI", written for an audience that is experienced in > SW dev but not UI development (probably including some basics around > framework chosen). This could be in a README or in the "dev docs" that has > been mentioned elsewhere. > > The SIP would be a great place to elaborate on technology choices & supply > a link to things like the video :) > > On Mon, Apr 13, 2020 at 10:35 AM Mike Drob wrote: > >> Hi Marcus, >> >> The mailing list strips attachments for some folks, can you upload the >> video somewhere else and link to it for us poor unfortunate souls? Thanks >> for your work! Excited to see the progress as it happens. >> >> Mike >> >> On Mon, Apr 13, 2020 at 5:30 AM Marcus Eagan >> wrote: >> >>> In general, I asked for some degree of trouble when I volunteered for >>> this work. Don't beat me too hard. My primary goal is to achieve three >>> things: >>> >>> 1) Improve security when using Solr Admin UI by removing EOL, >>> unsupported code. >>> 2) Make it easier or more welcoming for new developers to try the >>> project and even become contributors in all areas of the project because >>> the UI looks and functions as slightly more contemporary. >>> 3) Give back more substantially to a community from which I have >>> received so much with a testable and perrty UI. >>> >>> I've added another (4) which is contribute to help make the package >>> manager a first-class citizen in the minds of many Solr users around the >>> world via the UI package. I will need some help from someone in this list >>> on deploying this UI with a jar in Gradle if we want to offer an >>> alternative option to install the UI in Solr 9. I've attached where I'm at. >>> It's a nights and weekends project, but I will always be available for >>> bug fixes or discussions, unless i'm in a meeting or reading a book >>> >>> I won't solicit a ton of feedback prior to the the first PR, which I >>> will leave open for a few weeks or even a couple months while I put some >>> lipstick on it and improve performance of the application >>> >>> *<<< Over the weekend read lots of documentation, wrote a bunch of >>> code when it wasn't holidays, built the services, and stumbled through the >>> logic of rendering all these data points so you can watch the attached >>> video if you want to check it out. * >>> >>> . There's definitely some areas where I didn't do the TypeScript thing >>> because I'm still trying to grok it a bit.The two areas of the that I am >>> looking to somewhat overhaul in potentially controversial ways are the >>> *queries >>> page* and actual flow of the collections experience, which at the >>> moment are sort of linked, yet disconnected at the same time. The >>> Collections page tab today is really an Alias page. It won't have its own >>> tab in the new application is the plan, unless someone can give me a good >>> reason. Almost everything else will stay the same. >>> >>> For that reason, I'd like to solicit feedback if anyone has any examples >>> or ideas they'd like to share, I would greatly appreciate it. I'm somewhat >>> far along with the Admin UI as of now. Short weekend because of holiday >>> activities and general quarantine craziness, but I'm maybe 25-35% of the >>> way to completion, depending on how much care I devote to the query >>> screen. >>> >>> Even though there are some big problems with Angular — some major ones — >>> I think this was the right way to go for many reasons. I'm about a quarter >>> as fast in Angular as I am in React, but this is the right decision for the >>> long haul. I can elaborate if anyone really cares. Most importantly, this >>> app will be a lot easier to maintain. >>> >>> But now I have a handle on TypeScript. Many optimizations and >>> improvements coming to Solr as a result. TypeScript can be pretty >>> opinionated about APIs for someone thinking that they are back in the wild >>> wild west. >>> >>> Sending big air hugs, >>> Marcus >>> >>> On Fri, Apr 10, 2020 at 16:20 Noble Paul wrote: >>> +1 to David Smiley On Sat, Apr 11, 2020, 8:12 AM Marcus Eagan wrote: > I don't see admin UI as non-core. I think that an application UI for > end-users of an application consumes Solr non-core. I have to resign from > arguing, though. > > I don't consider myself a UI expert. I can do the work. > >
Re: Solr Admin UI Refresh 2020
Maybe start collecting Design and Design choices in a SIP? This discussion has been good and there seems to be consensus that we want a new UI, we want it to be a package and we want the package to be available by default and well tested. "Package" seems to imply that it can be added or removed or replaced or an alternative UI installed along side of it. If we got all of those things done this would be amazingly awesome :) Another thing that would be valuable is a good doc that explains "how to edit and maintain the UI", written for an audience that is experienced in SW dev but not UI development (probably including some basics around framework chosen). This could be in a README or in the "dev docs" that has been mentioned elsewhere. The SIP would be a great place to elaborate on technology choices & supply a link to things like the video :) On Mon, Apr 13, 2020 at 10:35 AM Mike Drob wrote: > Hi Marcus, > > The mailing list strips attachments for some folks, can you upload the > video somewhere else and link to it for us poor unfortunate souls? Thanks > for your work! Excited to see the progress as it happens. > > Mike > > On Mon, Apr 13, 2020 at 5:30 AM Marcus Eagan > wrote: > >> In general, I asked for some degree of trouble when I volunteered for >> this work. Don't beat me too hard. My primary goal is to achieve three >> things: >> >> 1) Improve security when using Solr Admin UI by removing EOL, unsupported >> code. >> 2) Make it easier or more welcoming for new developers to try the project >> and even become contributors in all areas of the project because the UI >> looks and functions as slightly more contemporary. >> 3) Give back more substantially to a community from which I have received >> so much with a testable and perrty UI. >> >> I've added another (4) which is contribute to help make the package >> manager a first-class citizen in the minds of many Solr users around the >> world via the UI package. I will need some help from someone in this list >> on deploying this UI with a jar in Gradle if we want to offer an >> alternative option to install the UI in Solr 9. I've attached where I'm at. >> It's a nights and weekends project, but I will always be available for >> bug fixes or discussions, unless i'm in a meeting or reading a book >> >> I won't solicit a ton of feedback prior to the the first PR, which I will >> leave open for a few weeks or even a couple months while I put some >> lipstick on it and improve performance of the application >> >> *<<< Over the weekend read lots of documentation, wrote a bunch of >> code when it wasn't holidays, built the services, and stumbled through the >> logic of rendering all these data points so you can watch the attached >> video if you want to check it out. * >> >> . There's definitely some areas where I didn't do the TypeScript thing >> because I'm still trying to grok it a bit.The two areas of the that I am >> looking to somewhat overhaul in potentially controversial ways are the >> *queries >> page* and actual flow of the collections experience, which at the moment >> are sort of linked, yet disconnected at the same time. The Collections page >> tab today is really an Alias page. It won't have its own tab in the new >> application is the plan, unless someone can give me a good reason. Almost >> everything else will stay the same. >> >> For that reason, I'd like to solicit feedback if anyone has any examples >> or ideas they'd like to share, I would greatly appreciate it. I'm somewhat >> far along with the Admin UI as of now. Short weekend because of holiday >> activities and general quarantine craziness, but I'm maybe 25-35% of the >> way to completion, depending on how much care I devote to the query >> screen. >> >> Even though there are some big problems with Angular — some major ones — >> I think this was the right way to go for many reasons. I'm about a quarter >> as fast in Angular as I am in React, but this is the right decision for the >> long haul. I can elaborate if anyone really cares. Most importantly, this >> app will be a lot easier to maintain. >> >> But now I have a handle on TypeScript. Many optimizations and >> improvements coming to Solr as a result. TypeScript can be pretty >> opinionated about APIs for someone thinking that they are back in the wild >> wild west. >> >> Sending big air hugs, >> Marcus >> >> On Fri, Apr 10, 2020 at 16:20 Noble Paul wrote: >> >>> +1 to David Smiley >>> >>> On Sat, Apr 11, 2020, 8:12 AM Marcus Eagan >>> wrote: >>> I don't see admin UI as non-core. I think that an application UI for end-users of an application consumes Solr non-core. I have to resign from arguing, though. I don't consider myself a UI expert. I can do the work. On Fri, Apr 10, 2020 at 11:42 AM Ishan Chattopadhyaya < ichattopadhy...@gmail.com> wrote: > David, you capture my thoughts well. > > Having a UI as a package gives users more choice and
Re: Solr Admin UI Refresh 2020
Hi Marcus, The mailing list strips attachments for some folks, can you upload the video somewhere else and link to it for us poor unfortunate souls? Thanks for your work! Excited to see the progress as it happens. Mike On Mon, Apr 13, 2020 at 5:30 AM Marcus Eagan wrote: > In general, I asked for some degree of trouble when I volunteered for this > work. Don't beat me too hard. My primary goal is to achieve three things: > > 1) Improve security when using Solr Admin UI by removing EOL, unsupported > code. > 2) Make it easier or more welcoming for new developers to try the project > and even become contributors in all areas of the project because the UI > looks and functions as slightly more contemporary. > 3) Give back more substantially to a community from which I have received > so much with a testable and perrty UI. > > I've added another (4) which is contribute to help make the package > manager a first-class citizen in the minds of many Solr users around the > world via the UI package. I will need some help from someone in this list > on deploying this UI with a jar in Gradle if we want to offer an > alternative option to install the UI in Solr 9. I've attached where I'm at. > It's a nights and weekends project, but I will always be available for > bug fixes or discussions, unless i'm in a meeting or reading a book > > I won't solicit a ton of feedback prior to the the first PR, which I will > leave open for a few weeks or even a couple months while I put some > lipstick on it and improve performance of the application > > *<<< Over the weekend read lots of documentation, wrote a bunch of > code when it wasn't holidays, built the services, and stumbled through the > logic of rendering all these data points so you can watch the attached > video if you want to check it out. * > > . There's definitely some areas where I didn't do the TypeScript thing > because I'm still trying to grok it a bit.The two areas of the that I am > looking to somewhat overhaul in potentially controversial ways are the > *queries > page* and actual flow of the collections experience, which at the moment > are sort of linked, yet disconnected at the same time. The Collections page > tab today is really an Alias page. It won't have its own tab in the new > application is the plan, unless someone can give me a good reason. Almost > everything else will stay the same. > > For that reason, I'd like to solicit feedback if anyone has any examples > or ideas they'd like to share, I would greatly appreciate it. I'm somewhat > far along with the Admin UI as of now. Short weekend because of holiday > activities and general quarantine craziness, but I'm maybe 25-35% of the > way to completion, depending on how much care I devote to the query > screen. > > Even though there are some big problems with Angular — some major ones — I > think this was the right way to go for many reasons. I'm about a quarter as > fast in Angular as I am in React, but this is the right decision for the > long haul. I can elaborate if anyone really cares. Most importantly, this > app will be a lot easier to maintain. > > But now I have a handle on TypeScript. Many optimizations and improvements > coming to Solr as a result. TypeScript can be pretty opinionated about APIs > for someone thinking that they are back in the wild wild west. > > Sending big air hugs, > Marcus > > On Fri, Apr 10, 2020 at 16:20 Noble Paul wrote: > >> +1 to David Smiley >> >> On Sat, Apr 11, 2020, 8:12 AM Marcus Eagan wrote: >> >>> I don't see admin UI as non-core. I think that an application UI for >>> end-users of an application consumes Solr non-core. I have to resign from >>> arguing, though. >>> >>> I don't consider myself a UI expert. I can do the work. >>> >>> >>> On Fri, Apr 10, 2020 at 11:42 AM Ishan Chattopadhyaya < >>> ichattopadhy...@gmail.com> wrote: >>> David, you capture my thoughts well. Having a UI as a package gives users more choice and gives our users more flexibility. 1. Users would be able to use a latter version of the UI with an older version of Solr, or vice versa. 2. Users should be able to install multiple types of UI, from different publishers, at once. 3. Contributors should be able to contribute to the UI more easily, since collaboration can be less bureaucratic. Experts like Marcus won't need to depend on preoccupied committers like us. 4. A UI (not the default one) can use libraries that aren't even Apache 2.0 compatible. 5. We can setup and use UI test frameworks for test automation (selenium etc), that would be challenging to setup and maintain with ASF Jenkins. List goes on.. Whether the package is a first party or third party can be a separate discussion. There should be an extremely easy and well defined way (support in the script itself) to start Solr with the packaged UI enabled. In any case, I don't think it is
BadApple report
We’re backsliding a bit. Note that over the last two weeks we’ve had successively more failures, HdfsSyncSliceTest is failing over half the time! Can we just nuke it? Here’s the short form aw fail count by week totals, most recent week first (corresponds to bits): Week: 0 had 117 failures Week: 1 had 99 failures Week: 2 had 69 failures Week: 3 had 65 failures Failures in Hoss' reports for the last 4 rollups. There were 252 unannotated tests that failed in Hoss' rollups. Ordered by the date I downloaded the rollup file, newest->oldest. See above for the dates the files were collected These tests were NOT BadApple'd or AwaitsFix'd Failures in the last 4 reports.. Report Pct runsfails test 0123 59.4 195 92 HdfsSyncSliceTest.test 0123 0.5 1697 10 HttpPartitionWithTlogReplicasTest.test 0123 6.1 133 12 ShardSplitTest.testSplitWithChaosMonkey 0123 1.8 1712 20 SyncSliceTest.test 0123 2.5 1754 49 SystemCollectionCompatTest.testBackCompat 0123 0.5 1706 26 TestPackages.testPluginLoading 0123 0.2 1676 4 TestSolrConfigHandlerCloud.test DO NOT ENABLE LIST: MoveReplicaHDFSTest.testFailedMove MoveReplicaHDFSTest.testNormalFailedMove TestControlledRealTimeReopenThread.testCRTReopen TestICUNormalizer2CharFilter.testRandomStrings TestICUTokenizerCJK TestImpersonationWithHadoopAuth.testForwarding TestLTRReRankingPipeline.testDifferentTopN TestRandomChains DO NOT ANNOTATE LIST CdcrBidirectionalTest.testBiDir IndexSizeTriggerTest.testMergeIntegration IndexSizeTriggerTest.testMixedBounds IndexSizeTriggerTest.testSplitIntegration IndexSizeTriggerTest.testTrigger InfixSuggestersTest.testShutdownDuringBuild ShardSplitTest.test ShardSplitTest.testSplitMixedReplicaTypes ShardSplitTest.testSplitWithChaosMonkey Test2BPostings.test TestLatLonShapeQueries.testRandomBig TestPackedInts.testPackedLongValues TestRandomChains.testRandomChainsWithLargeStrings TestTriggerIntegration.testSearchRate Processing file (History bit 3): HOSS-2020-04-13.csv Processing file (History bit 2): HOSS-2020-04-06.csv Processing file (History bit 1): HOSS-2020-03-30.csv Processing file (History bit 0): HOSS-2020-03-24.csv Number of AwaitsFix: 41 Number of BadApples: 4 **Annotated tests that didn't fail in the last 4 weeks. **Tests removed from the next two lists because they were specified in 'doNotEnable' in the properties file MoveReplicaHDFSTest.testNormalFailedMove **Annotations can be removed from the following tests because they haven't failed in the last 4 rollups. **Methods: 0 Raw fail count by week totals, most recent week first (corresponds to bits): Week: 0 had 117 failures Week: 1 had 99 failures Week: 2 had 69 failures Week: 3 had 65 failures Failures in Hoss' reports for the last 4 rollups. There were 252 unannotated tests that failed in Hoss' rollups. Ordered by the date I downloaded the rollup file, newest->oldest. See above for the dates the files were collected These tests were NOT BadApple'd or AwaitsFix'd Failures in the last 4 reports.. Report Pct runsfails test 0123 59.4 195 92 HdfsSyncSliceTest.test 0123 0.5 1697 10 HttpPartitionWithTlogReplicasTest.test 0123 6.1 133 12 ShardSplitTest.testSplitWithChaosMonkey 0123 1.8 1712 20 SyncSliceTest.test 0123 2.5 1754 49 SystemCollectionCompatTest.testBackCompat 0123 0.5 1706 26 TestPackages.testPluginLoading 0123 0.2 1676 4 TestSolrConfigHandlerCloud.test Failures over the last 4 weeks, but not every week. Ordered most-recent first: 0120.5 1286 8 CdcrVersionReplicationTest.testCdcrDocVersions 0123.7 83 5 HdfsBasicDistributedZkTest.test 0121.1 1290 8 HttpPartitionTest.test 0129.4 95 11 Test2BPostings.test 0123.7 81 3 TestDuelingCodecsAtNight.testBigEquals 0120.5 1281 10 TestInPlaceUpdatesDistrib.test 0120.5 1285 5 TestQueryingOnDownCollection.testQueryToDownCollectionShouldFailFast 0120.5 1281 6 TestSolrDeletionPolicy1.testNumCommitsConfigured 0120.7 1299 13 TestStressLiveNodes.testStress 01 3 1.4 1316 14 RollingRestartTest.test 01 3 0.5 1295 5 SearchRateTriggerTest.testWaitForElapsed 01 3 2.5 1316 23 TestRandomChains.testRandomChains 01 0.5 872 3 CloudHttp2SolrClientTest.testRetryUpdatesWhenClusterStateIsStale 01 0.5
