Solr
  1. Solr
  2. SOLR-6892

Improve the way update processors are used and make it simpler

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 5.1, 6.0
    • Component/s: None
    • Labels:
      None

      Description

      The current update processor chain is rather cumbersome and we should be able to use the updateprocessors without a chain.

      The scope of this ticket is

      • A new tag <updateProcessor> becomes a toplevel tag and it will be equivalent to the <processor> tag inside <updateRequestProcessorChain> . The only difference is that it should require a name attribute. The <updateProcessorChain> tag will continue to exist and it should be possible to define <processor> inside as well . It should also be possible to reference a named URP in a chain.
      • processors will be added in the request with their names . Example processor=a,b,c , post-processor=x,y,z . This creates an implicit chain of the named URPs the order they are specified
      • There are multiple request parameters supported by update request
        • processor : This chain is executed executed at the leader right before the LogUpdateProcessorFactory + DistributedUpdateProcessorFactory . The replicas will not execute this.
        • post-processor : This chain is executed right before the RunUpdateProcessor in all replicas , including the leader
      • What happens to the update.chain parameter ? update.chain will be honored . The implicit chain is created by merging both the update.chain and the request params. post-processor will be inserted right before the RunUpdateProcessorFactory in the chain. and processor will be inserted right before the LogUpdateProcessorFactory,DistributedUpdateProcessorFactory

        Issue Links

          Activity

          Hide
          Erik Hatcher added a comment -

          While this does open up some potential custom power, I'm curious what use cases you see with being able for the indexing client to specify the processors? It is good that processors become their own first class component such that they can be composed into update processor chains when (eventually) creating a chain with API, but I can see using individual processors from the /update call being a possible problem, such as not using the log processor and then not being able to see what happened exactly.

          Show
          Erik Hatcher added a comment - While this does open up some potential custom power, I'm curious what use cases you see with being able for the indexing client to specify the processors? It is good that processors become their own first class component such that they can be composed into update processor chains when (eventually) creating a chain with API, but I can see using individual processors from the /update call being a possible problem, such as not using the log processor and then not being able to see what happened exactly.
          Hide
          Noble Paul added a comment -

          The configuration is complex today. We need to make this less of vodoo . Let's look at what is the purpose of an update processor. It is just a transformer for incoming documents. Let's apply the transformers in the order they are specified and let the system take care of the rest and avoid surprises.

          Show
          Noble Paul added a comment - The configuration is complex today. We need to make this less of vodoo . Let's look at what is the purpose of an update processor. It is just a transformer for incoming documents. Let's apply the transformers in the order they are specified and let the system take care of the rest and avoid surprises.
          Hide
          Alexandre Rafalovitch added a comment -

          This use case does not feel strong enough to be Major. Are there specific business use-cases that really cannot be solved with pre-defined chains?

          Also, a lot of URPs take parameters. The proposal above does not seem to allow that. And then what about DistributedUpdateProcessor and that the chains allow to specify items both before and after it.

          Also consider troubleshooting. It needs to be very clear what applied to the content as it came in. How would one find out if a chain was applied incorrectly.

          Finally, what are "built update processors"? "Built-in?" So far, vast majority of them are built-in, as in shipped with Solr. And have their own class names. Do you means some standard chains could be pre-built and named? Do you have a good example? I would say these arguments apply a lot more to the analyzer chains (I'd love to see those built-in), but I am not sure about URPs.

          Show
          Alexandre Rafalovitch added a comment - This use case does not feel strong enough to be Major . Are there specific business use-cases that really cannot be solved with pre-defined chains? Also, a lot of URPs take parameters. The proposal above does not seem to allow that. And then what about DistributedUpdateProcessor and that the chains allow to specify items both before and after it. Also consider troubleshooting. It needs to be very clear what applied to the content as it came in. How would one find out if a chain was applied incorrectly. Finally, what are "built update processors"? "Built-in?" So far, vast majority of them are built-in, as in shipped with Solr. And have their own class names. Do you means some standard chains could be pre-built and named? Do you have a good example? I would say these arguments apply a lot more to the analyzer chains (I'd love to see those built-in), but I am not sure about URPs.
          Hide
          Alexandre Rafalovitch added a comment -

          > Let's apply the transformers in the order they are specified and let the system take care of the rest and avoid surprises

          Actually, having a code hidden somewhere inside the system to do the non-trivial thing is what will create surprises. Right now, the user can look at the XML file and step through the cross-references to see what actually happened. Moving away into on-the-fly and case-by-case will increase the surprises. So, the proposal and the reasoning are not quite aligned here.

          Things like pre-defined names for standard components could decrease surprises. The rest of the proposal does not.

          Show
          Alexandre Rafalovitch added a comment - > Let's apply the transformers in the order they are specified and let the system take care of the rest and avoid surprises Actually, having a code hidden somewhere inside the system to do the non-trivial thing is what will create surprises. Right now, the user can look at the XML file and step through the cross-references to see what actually happened. Moving away into on-the-fly and case-by-case will increase the surprises. So, the proposal and the reasoning are not quite aligned here. Things like pre-defined names for standard components could decrease surprises. The rest of the proposal does not.
          Hide
          Noble Paul added a comment -

          The configuration is not going away. we will have the individuals URP specified and configured. The point is , the chain does nothing extra.
          Specifying the URP list at request time is no more complex than deciding the chain name. It is not taking the power away but adding the power to mix and match stuff at request time

          Show
          Noble Paul added a comment - The configuration is not going away. we will have the individuals URP specified and configured. The point is , the chain does nothing extra. Specifying the URP list at request time is no more complex than deciding the chain name. It is not taking the power away but adding the power to mix and match stuff at request time
          Hide
          Alexandre Rafalovitch added a comment -

          So, would the better explanation be then is that you have an option of pre-configuring and naming individual items on the stack and then composing them either in pre-existing stack (effectively with aliases) or dynamically on the fly.

          So, the addressable unit becomes an individual pre-configured URP (atom) as opposed to the full stack (molecule)?

          That would make more sense, though you still need to be super-clear on what becomes hidden from the XML file. For example, there should be an easy way to query all the pre-configured components. One of the issues with ElasticSearch is that it is hard to tell what those symbolic (analyzer chains) names correspond too, as it is hardcoded somewhere deep with it.

          Show
          Alexandre Rafalovitch added a comment - So, would the better explanation be then is that you have an option of pre-configuring and naming individual items on the stack and then composing them either in pre-existing stack (effectively with aliases) or dynamically on the fly. So, the addressable unit becomes an individual pre-configured URP (atom) as opposed to the full stack (molecule)? That would make more sense, though you still need to be super-clear on what becomes hidden from the XML file. For example, there should be an easy way to query all the pre-configured components. One of the issues with ElasticSearch is that it is hard to tell what those symbolic (analyzer chains) names correspond too, as it is hardcoded somewhere deep with it.
          Hide
          Noble Paul added a comment -

          If there are components that need little or no configuration, it can be made implicitly available with a well known name. Other components which require configuration will have to be configured in xml .
          But your explanation is correct. We are changing the atomic unit from a chain to a URP

          Show
          Noble Paul added a comment - If there are components that need little or no configuration, it can be made implicitly available with a well known name. Other components which require configuration will have to be configured in xml . But your explanation is correct. We are changing the atomic unit from a chain to a URP
          Hide
          Yonik Seeley added a comment -

          We shouldn't let too much implementation leak into the interface. DistribUpdateProcessor, etc, are much more implementation than interface. For example, should one need to know that DistribUpdateProcessor is needed for atomic updates? What if it's split into two processors in the future? Likewise for schemaless - it's currently implemented as a whole bunch of processors, but I could see it moving to a single processor in the future. It's implementation. People should not be specifying this stuff on requests.

          For example, there should be an easy way to query all the pre-configured components.

          Perhaps that's all this feature should be... a way to add additional named processors to the chain. That should be relatively safe.

          Show
          Yonik Seeley added a comment - We shouldn't let too much implementation leak into the interface. DistribUpdateProcessor, etc, are much more implementation than interface. For example, should one need to know that DistribUpdateProcessor is needed for atomic updates? What if it's split into two processors in the future? Likewise for schemaless - it's currently implemented as a whole bunch of processors, but I could see it moving to a single processor in the future. It's implementation. People should not be specifying this stuff on requests. For example, there should be an easy way to query all the pre-configured components. Perhaps that's all this feature should be... a way to add additional named processors to the chain. That should be relatively safe.
          Hide
          Noble Paul added a comment -

          Yes yonik . The default urp chain must be immutable . This is about adding URP s before that chain .

          Show
          Noble Paul added a comment - Yes yonik . The default urp chain must be immutable . This is about adding URP s before that chain .
          Hide
          Alexandre Rafalovitch added a comment -

          q. The default urp chain must be immutable

          Careful with that one. There are sometimes valid reasons with putting an URP after DistributedUpdateProcessor. I believe it is usually connected with accessing stored content during the atomic update. We don't want to completely loose that flexibility.

          Also, Debugging URP may want to be the last items in the chain too.

          Show
          Alexandre Rafalovitch added a comment - q. The default urp chain must be immutable Careful with that one. There are sometimes valid reasons with putting an URP after DistributedUpdateProcessor. I believe it is usually connected with accessing stored content during the atomic update. We don't want to completely loose that flexibility. Also, Debugging URP may want to be the last items in the chain too.
          Hide
          Yonik Seeley added a comment -

          This is about adding URP s before that chain .

          Dude, I'm not psychic I didn't see that anywhere in this issue before now.

          Show
          Yonik Seeley added a comment - This is about adding URP s before that chain . Dude, I'm not psychic I didn't see that anywhere in this issue before now.
          Hide
          Jack Krupansky added a comment -

          Issue type should be "Improvement", not "Bug", right?

          Show
          Jack Krupansky added a comment - Issue type should be "Improvement", not "Bug", right?
          Hide
          Jack Krupansky added a comment -

          It might be instructive to look at how the search handler deals with search components and possibly consider rationalizing the two handlers so that there is a little more commonality in how lists of components/processors are specified. For example, consider a "first", "last", and full processor list. IOW, be able to specify a list of processors to apply before the solrconfig-specified list, after, or to completely replace the solrconfig-specified list of processors.

          Show
          Jack Krupansky added a comment - It might be instructive to look at how the search handler deals with search components and possibly consider rationalizing the two handlers so that there is a little more commonality in how lists of components/processors are specified. For example, consider a "first", "last", and full processor list. IOW, be able to specify a list of processors to apply before the solrconfig-specified list, after, or to completely replace the solrconfig-specified list of processors.
          Hide
          Noble Paul added a comment -

          Thanks everyone. Currently the ticket is short on details. I hope to update this with finer details soon.

          Show
          Noble Paul added a comment - Thanks everyone. Currently the ticket is short on details. I hope to update this with finer details soon.
          Hide
          Noble Paul added a comment -

          I've updated the description with more meat this time. Please comment

          Show
          Noble Paul added a comment - I've updated the description with more meat this time. Please comment
          Hide
          Jack Krupansky added a comment -

          Thanks for the description updates. Comments...

          1. We need to be explicit about how and when the hard-wired processors are invoked. In particular the "run update" processor. The "log update" processor is somewhat special in that it is not mandatory, but a lot of people are not explicitly aware of it, so if they leave it out, they will be wondering why they don't get logging of updates.

          2. I suggest three parameters: "pre.processors" to specify processors before the default chain, "post.processors" to specify processors after the default chain (before or after "run update" and "log update"??), and "processors" to specify a processor list to completely replace the default chain.

          3. Make "log update" be automatically added at the end unless a "nolog" processor is specified.

          4. Make "run update" be automatically added at the end unless a "norun" processor is specified.

          5. Discuss "processor" vs. "processors" - I prefer the latter since it is explicit, but maybe allow both since the singular/plural can be confusing.

          6. Consider supporting both a single parameter with a csv list as well as multiple parameters each with a single value. I prefer having the choice. Having a separate parameter for each processor can be more explicit sometimes.

          7. Consider a single-processor parameter with the option to specify the parameters for that processor. That would make it possible to invoke the various field mutating update processors, which would be especially cool and convenient.

          Show
          Jack Krupansky added a comment - Thanks for the description updates. Comments... 1. We need to be explicit about how and when the hard-wired processors are invoked. In particular the "run update" processor. The "log update" processor is somewhat special in that it is not mandatory, but a lot of people are not explicitly aware of it, so if they leave it out, they will be wondering why they don't get logging of updates. 2. I suggest three parameters: "pre.processors" to specify processors before the default chain, "post.processors" to specify processors after the default chain (before or after "run update" and "log update"??), and "processors" to specify a processor list to completely replace the default chain. 3. Make "log update" be automatically added at the end unless a "nolog" processor is specified. 4. Make "run update" be automatically added at the end unless a "norun" processor is specified. 5. Discuss "processor" vs. "processors" - I prefer the latter since it is explicit, but maybe allow both since the singular/plural can be confusing. 6. Consider supporting both a single parameter with a csv list as well as multiple parameters each with a single value. I prefer having the choice. Having a separate parameter for each processor can be more explicit sometimes. 7. Consider a single-processor parameter with the option to specify the parameters for that processor. That would make it possible to invoke the various field mutating update processors, which would be especially cool and convenient.
          Hide
          Noble Paul added a comment -

          Jack Krupansky
          A lot of your suggestions are not realy in the scope of this ticket and should be addressed separately

          Consider supporting both a single parameter with a csv list as well as multiple parameters each with a single value. I prefer having the choice.

          I think having choices is not really good if it doesn't offer anything better.

          Consider a single-processor parameter with the option to specify the parameters for that processor.

          This is just too complex to handle with the flat http parameter structure. Again beyond the scope

          URPs are really powerful but they are a bit hard to configure and use. I wish to make it easier and more widely used. That is the objective of this ticket

          Show
          Noble Paul added a comment - Jack Krupansky A lot of your suggestions are not realy in the scope of this ticket and should be addressed separately Consider supporting both a single parameter with a csv list as well as multiple parameters each with a single value. I prefer having the choice. I think having choices is not really good if it doesn't offer anything better. Consider a single-processor parameter with the option to specify the parameters for that processor. This is just too complex to handle with the flat http parameter structure. Again beyond the scope URPs are really powerful but they are a bit hard to configure and use. I wish to make it easier and more widely used. That is the objective of this ticket
          Hide
          Noble Paul added a comment - - edited

          We have a fairly complex system in the URP chain. It has ported very badly from the standalone to solrcloud The problem is the current configuration is not capable of capturing the various usecases

          We have most of the logic hidden behind the scenes and not possible for users to manipulate.

          In short there are three kind of URPs possible.

          • pre processor : The chain that is executed at the node where the request is received. This is particularly useful if there is some heavy lifting to be done and you don't wish to overwhelm the leader.
          • processor : Invoked at the leader before the DistributedUpdateProcessor is invoked
          • post processor : Invoked in all replicas before the RunUpdateProcessor is invoked

          All these can be separate chains passed on the the UpdateRequestHandlers .

          Show
          Noble Paul added a comment - - edited We have a fairly complex system in the URP chain. It has ported very badly from the standalone to solrcloud The problem is the current configuration is not capable of capturing the various usecases We have most of the logic hidden behind the scenes and not possible for users to manipulate. In short there are three kind of URPs possible. pre processor : The chain that is executed at the node where the request is received. This is particularly useful if there is some heavy lifting to be done and you don't wish to overwhelm the leader. processor : Invoked at the leader before the DistributedUpdateProcessor is invoked post processor : Invoked in all replicas before the RunUpdateProcessor is invoked All these can be separate chains passed on the the UpdateRequestHandlers .
          Hide
          Shalin Shekhar Mangar added a comment -

          processor : Invoked at the leader before the DistributedUpdateProcessor is invoked
          post processor : Invoked in all replicas before the RunUpdateProcessor is invoked

          Just to clarify this a bit more:

          • processor : Invoked at the leader before the DistributedUpdateProcessor is invoked and not at all on the replicas
          • post processor : Invoked in all replicas before the RunUpdateProcessor is invoked including the leader

          I agree that the current model is broken. Also see SOLR-2822, SOLR-3473 and SOLR-4016 for more history and related issues.

          Show
          Shalin Shekhar Mangar added a comment - processor : Invoked at the leader before the DistributedUpdateProcessor is invoked post processor : Invoked in all replicas before the RunUpdateProcessor is invoked Just to clarify this a bit more: processor : Invoked at the leader before the DistributedUpdateProcessor is invoked and not at all on the replicas post processor : Invoked in all replicas before the RunUpdateProcessor is invoked including the leader I agree that the current model is broken. Also see SOLR-2822 , SOLR-3473 and SOLR-4016 for more history and related issues.
          Hide
          Alexandre Rafalovitch added a comment -

          Two questions:

          1. How do these three stages express themselves in the current URP chain? I thought there were only two stages (pre- and post- DistributedUpdateProcessor. Not sure where the third stage happens.

          2. How does this work with atomic updates. My understand was that it is possible to run URP on sent-only version of the document or on sent-and-loaded version. So, the URP can update a field based on some other field that may or may not have been updated in the update request. But I am not clear whether this boundary is the same or different from one of the 3 boundaries mentioned in this JIRA.

          Show
          Alexandre Rafalovitch added a comment - Two questions: 1. How do these three stages express themselves in the current URP chain? I thought there were only two stages (pre- and post- DistributedUpdateProcessor. Not sure where the third stage happens. 2. How does this work with atomic updates. My understand was that it is possible to run URP on sent-only version of the document or on sent-and-loaded version. So, the URP can update a field based on some other field that may or may not have been updated in the update request. But I am not clear whether this boundary is the same or different from one of the 3 boundaries mentioned in this JIRA.
          Hide
          Shalin Shekhar Mangar added a comment -

          How do these three stages express themselves in the current URP chain? I thought there were only two stages (pre- and post- DistributedUpdateProcessor. Not sure where the third stage happens.

          I think Noble is talking about the concept of URP and not actual existing implementations. The current URP chains are carried over from the non-cloud Solr days and it was modified to support pre/post processing by making DistribUpdateProcessor as a special marker processor. We should try to re-imagine this feature as a fresh one and try to accommodate all use-cases and make them easy to use as well.

          Show
          Shalin Shekhar Mangar added a comment - How do these three stages express themselves in the current URP chain? I thought there were only two stages (pre- and post- DistributedUpdateProcessor. Not sure where the third stage happens. I think Noble is talking about the concept of URP and not actual existing implementations. The current URP chains are carried over from the non-cloud Solr days and it was modified to support pre/post processing by making DistribUpdateProcessor as a special marker processor. We should try to re-imagine this feature as a fresh one and try to accommodate all use-cases and make them easy to use as well.
          Hide
          Noble Paul added a comment -

          I thought there were only two stages (pre- and post- DistributedUpdateProcessor

          The "pre processor" mentioned above is not possible in the current URP chain. This is a new feature only

          How do these three stages express themselves in the current URP chain

          I'm not sure we should have the new features added to the old syntax and it does not fit very well there.

          Show
          Noble Paul added a comment - I thought there were only two stages (pre- and post- DistributedUpdateProcessor The "pre processor" mentioned above is not possible in the current URP chain. This is a new feature only How do these three stages express themselves in the current URP chain I'm not sure we should have the new features added to the old syntax and it does not fit very well there.
          Hide
          Shalin Shekhar Mangar added a comment -

          How does this work with atomic updates. My understand was that it is possible to run URP on sent-only version of the document or on sent-and-loaded version. So, the URP can update a field based on some other field that may or may not have been updated in the update request. But I am not clear whether this boundary is the same or different from one of the 3 boundaries mentioned in this JIRA.

          Good point. I guess the pre-processor and processor chains as Noble outlined can only apply on sent-only versions. The post-processor applies on sent-and-loaded documents.

          Show
          Shalin Shekhar Mangar added a comment - How does this work with atomic updates. My understand was that it is possible to run URP on sent-only version of the document or on sent-and-loaded version. So, the URP can update a field based on some other field that may or may not have been updated in the update request. But I am not clear whether this boundary is the same or different from one of the 3 boundaries mentioned in this JIRA. Good point. I guess the pre-processor and processor chains as Noble outlined can only apply on sent-only versions. The post-processor applies on sent-and-loaded documents.
          Hide
          Alexandre Rafalovitch added a comment -

          I don't mind the new approach to be a super-set of the old one with a new and better syntax. I just was asking the questions to ensure I understand how the old use cases map to this new approach.

          Is the plan for this to go into 5? Or trunk only?

          Show
          Alexandre Rafalovitch added a comment - I don't mind the new approach to be a super-set of the old one with a new and better syntax. I just was asking the questions to ensure I understand how the old use cases map to this new approach. Is the plan for this to go into 5? Or trunk only?
          Hide
          Noble Paul added a comment -

          Alexandre Rafalovitch I'm glad that you are asking the right questions

          This is not a 5.0 feature. This will only be taken up post 5.0. I'm just getting the design right

          Show
          Noble Paul added a comment - Alexandre Rafalovitch I'm glad that you are asking the right questions This is not a 5.0 feature. This will only be taken up post 5.0. I'm just getting the design right
          Hide
          Alexandre Rafalovitch added a comment -

          For post 5.0 (with more time) I would also check what the other methods in the updates are doing. I have a feeling they are super dark-arts somehow. Especially with SolrCloud.

          As a test, it would be really nice to have a Debug URP that would actually be able to trace changes happening through each step of URP. Similar to the Analysis screen of Admin UI.

          Show
          Alexandre Rafalovitch added a comment - For post 5.0 (with more time) I would also check what the other methods in the updates are doing. I have a feeling they are super dark-arts somehow. Especially with SolrCloud. As a test, it would be really nice to have a Debug URP that would actually be able to trace changes happening through each step of URP. Similar to the Analysis screen of Admin UI.
          Hide
          Ramkumar Aiyengar added a comment -

          +1 especially for having separate interfaces for the distrib (leader) and non-distrib (replica) cases, currently the two are entangled in too many places leading to lot of inefficiencies and inflexibility. I am trying to do this off and on for SearchComponent and realising how big a mess it currently is..

          Show
          Ramkumar Aiyengar added a comment - +1 especially for having separate interfaces for the distrib (leader) and non-distrib (replica) cases, currently the two are entangled in too many places leading to lot of inefficiencies and inflexibility. I am trying to do this off and on for SearchComponent and realising how big a mess it currently is..
          Hide
          Alexandre Rafalovitch added a comment -

          We better have the debugging statements explaining exactly what the final chain is. The mailing list is already starting to see people getting confused by chains defined as "default" being ignored because there is another declaration somewhere in the initParams section. It's a hell to troubleshoot.

          So, please make sure that there is a debug level log statement that at least names the classes in the sequence created.

          Show
          Alexandre Rafalovitch added a comment - We better have the debugging statements explaining exactly what the final chain is. The mailing list is already starting to see people getting confused by chains defined as "default" being ignored because there is another declaration somewhere in the initParams section. It's a hell to troubleshoot. So, please make sure that there is a debug level log statement that at least names the classes in the sequence created.
          Hide
          ASF subversion and git services added a comment -

          Commit 1666436 from Noble Paul in branch 'dev/trunk'
          [ https://svn.apache.org/r1666436 ]

          SOLR-6892: Improve the way update processors are used and make it simpler

          Show
          ASF subversion and git services added a comment - Commit 1666436 from Noble Paul in branch 'dev/trunk' [ https://svn.apache.org/r1666436 ] SOLR-6892 : Improve the way update processors are used and make it simpler
          Hide
          Noble Paul added a comment -

          I have added info level logging which says exactly the order of Updateprocessors used

          Show
          Noble Paul added a comment - I have added info level logging which says exactly the order of Updateprocessors used
          Hide
          ASF subversion and git services added a comment -

          Commit 1667134 from Noble Paul in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1667134 ]

          SOLR-6892: Improve the way update processors are used and make it simpler

          Show
          ASF subversion and git services added a comment - Commit 1667134 from Noble Paul in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1667134 ] SOLR-6892 : Improve the way update processors are used and make it simpler
          Hide
          Yonik Seeley added a comment -
          Show
          Yonik Seeley added a comment - https://svn.apache.org/viewvc/lucene/dev/trunk/solr/CHANGES.txt?r1=1666436&r2=1666435&pathrev=1666436 More descriptive CHANGES entries would be much appreciated!
          Hide
          ASF subversion and git services added a comment -

          Commit 1667587 from Noble Paul in branch 'dev/trunk'
          [ https://svn.apache.org/r1667587 ]

          SOLR-6892: better description in CHANGES.txt

          Show
          ASF subversion and git services added a comment - Commit 1667587 from Noble Paul in branch 'dev/trunk' [ https://svn.apache.org/r1667587 ] SOLR-6892 : better description in CHANGES.txt
          Hide
          ASF subversion and git services added a comment -

          Commit 1667588 from Noble Paul in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1667588 ]

          SOLR-6892: better description in CHANGES.txt

          Show
          ASF subversion and git services added a comment - Commit 1667588 from Noble Paul in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1667588 ] SOLR-6892 : better description in CHANGES.txt
          Hide
          Timothy Potter added a comment -

          Bulk close after 5.1 release

          Show
          Timothy Potter added a comment - Bulk close after 5.1 release

            People

            • Assignee:
              Noble Paul
              Reporter:
              Noble Paul
            • Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development