[jira] [Commented] (SOLR-13457) Managing Timeout values in Solr
[ https://issues.apache.org/jira/browse/SOLR-13457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16905806#comment-16905806 ] Anindita Gupta commented on SOLR-13457: --- In FacetStream.java, open() method Socket timeout 30 seconds & connection timeout 15 seconds has been added in Version #7.7 onward which is hard-coded and not configurable. These numbers are very low when dealing with large number of documents for complex Streaming facet query and if we try to retrieve large number of records or starting Offset value is high, Timeout exception is occurring while waiting response from server. How can we deal with this issue? > Managing Timeout values in Solr > --- > > Key: SOLR-13457 > URL: https://issues.apache.org/jira/browse/SOLR-13457 > Project: Solr > Issue Type: Improvement >Affects Versions: master (9.0) >Reporter: Gus Heck >Priority: Major > > Presently, Solr has a variety of timeouts for various connections or > operations. These timeouts have been added, tweaked and refined and in some > cases made configurable in an ad-hoc manner by the contributors of individual > features. Throughout the history of the project. This is all well and good > until one experiences a timeout during an otherwise valid use case and needs > to adjust it. > This has also made managing timeouts in unit tests "interesting" as noted in > SOLR-13389. > Probably nobody has the spare time to do a tour de force through the code and > coordinate every single timeout, so in this ticket I'd like to establish a > framework for categorizing time outs, a standard for how we make each > category configurable, and then add sub-tickets to address individual > timeouts. > The intention is that eventually, there will be no "magic number" timeout > values in code, and one can predict where to find the configuration for a > timeout by determining it's category. > Initial strawman categories (feel free to knock down or suggest alternatives): > # *Feature-Instance Timeout*: Timeouts that relate to a particular > instantiation of a feature, for example a database connection timeout for a > connection to a particular database by DIH. These should be set in the > configuration of that instance. > # *Optional Feature Timeout*: A timeout that only has meaning in the context > of a particular feature that is not required for solr to function... i.e. > something that can be turned on or off. Perhaps a timeout for communication > with an external ldap for authentication purposes. These should be configured > in the same configuration that enables this feature. > # *Global System Timeout*: A timeout that will always be an active part of > Solr these should be configured in a new section of solr.xml. For > example the Jetty thread idle timeout, or the default timeout for http calls > between nodes. > # *Node Specific Timeout*: A timeout which may differ on different nodes. I > don't know of any of these, but I'll grant the possibility. These (and only > these) should be set by setting system properties. If we don't have any of > these, that's just fine :). > # *Client Timeout*: These are timeouts in solrj code that are active in code > running outside the server. They should be configurable via java api, and via > a config file of some sort from a single location defined in a sysprop or > sourced from classpath (in that order). When run on the server, the solrj > code should look for a *Global System Timeout* setting before consulting > sysprops or classpath. > *Note that in no case is a hard-coded value the correct solution.* > If we get a consensus on categories and their locations, then the next step > is to begin adding sub tickets to bring specific timeouts into compliance. > Every such ticket should include an update to the section of the ref guide > documenting the configuration to which the timeout has been added (e.g. docs > for solr.xml for Global System Timeouts) describing what exactly is affected > by the timeout, the maximum allowed value and how zero and negative numbers > are handled. > It is of course true that some of these values will have the potential to > destroy system performance or integrity, and that should be mentioned in the > update to documentation. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13457) Managing Timeout values in Solr
[
https://issues.apache.org/jira/browse/SOLR-13457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16878183#comment-16878183
]
Hoss Man commented on SOLR-13457:
-
SOLR-13605 shows some more of the madness involved in how these settings are
borked -- even if you just focus on the the SolrJ APIs for specifying things
(notably {{HttpSolrClient.Builder.withHttpClient}}) w/o even considering how
*solr* should use those SolrJ APIs based on the things like {{solr.xml}}
> Managing Timeout values in Solr
> ---
>
> Key: SOLR-13457
> URL: https://issues.apache.org/jira/browse/SOLR-13457
> Project: Solr
> Issue Type: Improvement
>Affects Versions: master (9.0)
>Reporter: Gus Heck
>Priority: Major
>
> Presently, Solr has a variety of timeouts for various connections or
> operations. These timeouts have been added, tweaked and refined and in some
> cases made configurable in an ad-hoc manner by the contributors of individual
> features. Throughout the history of the project. This is all well and good
> until one experiences a timeout during an otherwise valid use case and needs
> to adjust it.
> This has also made managing timeouts in unit tests "interesting" as noted in
> SOLR-13389.
> Probably nobody has the spare time to do a tour de force through the code and
> coordinate every single timeout, so in this ticket I'd like to establish a
> framework for categorizing time outs, a standard for how we make each
> category configurable, and then add sub-tickets to address individual
> timeouts.
> The intention is that eventually, there will be no "magic number" timeout
> values in code, and one can predict where to find the configuration for a
> timeout by determining it's category.
> Initial strawman categories (feel free to knock down or suggest alternatives):
> # *Feature-Instance Timeout*: Timeouts that relate to a particular
> instantiation of a feature, for example a database connection timeout for a
> connection to a particular database by DIH. These should be set in the
> configuration of that instance.
> # *Optional Feature Timeout*: A timeout that only has meaning in the context
> of a particular feature that is not required for solr to function... i.e.
> something that can be turned on or off. Perhaps a timeout for communication
> with an external ldap for authentication purposes. These should be configured
> in the same configuration that enables this feature.
> # *Global System Timeout*: A timeout that will always be an active part of
> Solr these should be configured in a new section of solr.xml. For
> example the Jetty thread idle timeout, or the default timeout for http calls
> between nodes.
> # *Node Specific Timeout*: A timeout which may differ on different nodes. I
> don't know of any of these, but I'll grant the possibility. These (and only
> these) should be set by setting system properties. If we don't have any of
> these, that's just fine :).
> # *Client Timeout*: These are timeouts in solrj code that are active in code
> running outside the server. They should be configurable via java api, and via
> a config file of some sort from a single location defined in a sysprop or
> sourced from classpath (in that order). When run on the server, the solrj
> code should look for a *Global System Timeout* setting before consulting
> sysprops or classpath.
> *Note that in no case is a hard-coded value the correct solution.*
> If we get a consensus on categories and their locations, then the next step
> is to begin adding sub tickets to bring specific timeouts into compliance.
> Every such ticket should include an update to the section of the ref guide
> documenting the configuration to which the timeout has been added (e.g. docs
> for solr.xml for Global System Timeouts) describing what exactly is affected
> by the timeout, the maximum allowed value and how zero and negative numbers
> are handled.
> It is of course true that some of these values will have the potential to
> destroy system performance or integrity, and that should be mentioned in the
> update to documentation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13457) Managing Timeout values in Solr
[ https://issues.apache.org/jira/browse/SOLR-13457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16837569#comment-16837569 ] Gus Heck commented on SOLR-13457: - I'm also thinking that maybe instead of invoking start.jar directly it will be time to put a thin wrapper around that invocation so we can influence what jetty does from our own configs & set a System property to let ourselves know if we are a solr server, or if we've been run inside someone else's code, and if a server if we are in cloud or classic mode, because we'll obviously want to load stuff from zk when we're a cloud, but that option is not available in the other two cases. > Managing Timeout values in Solr > --- > > Key: SOLR-13457 > URL: https://issues.apache.org/jira/browse/SOLR-13457 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Gus Heck >Priority: Major > > Presently, Solr has a variety of timeouts for various connections or > operations. These timeouts have been added, tweaked and refined and in some > cases made configurable in an ad-hoc manner by the contributors of individual > features. Throughout the history of the project. This is all well and good > until one experiences a timeout during an otherwise valid use case and needs > to adjust it. > This has also made managing timeouts in unit tests "interesting" as noted in > SOLR-13389. > Probably nobody has the spare time to do a tour de force through the code and > coordinate every single timeout, so in this ticket I'd like to establish a > framework for categorizing time outs, a standard for how we make each > category configurable, and then add sub-tickets to address individual > timeouts. > The intention is that eventually, there will be no "magic number" timeout > values in code, and one can predict where to find the configuration for a > timeout by determining it's category. > Initial strawman categories (feel free to knock down or suggest alternatives): > # *Feature-Instance Timeout*: Timeouts that relate to a particular > instantiation of a feature, for example a database connection timeout for a > connection to a particular database by DIH. These should be set in the > configuration of that instance. > # *Optional Feature Timeout*: A timeout that only has meaning in the context > of a particular feature that is not required for solr to function... i.e. > something that can be turned on or off. Perhaps a timeout for communication > with an external ldap for authentication purposes. These should be configured > in the same configuration that enables this feature. > # *Global System Timeout*: A timeout that will always be an active part of > Solr these should be configured in a new section of solr.xml. For > example the Jetty thread idle timeout, or the default timeout for http calls > between nodes. > # *Node Specific Timeout*: A timeout which may differ on different nodes. I > don't know of any of these, but I'll grant the possibility. These (and only > these) should be set by setting system properties. If we don't have any of > these, that's just fine :). > # *Client Timeout*: These are timeouts in solrj code that are active in code > running outside the server. They should be configurable via java api, and via > a config file of some sort from a single location defined in a sysprop or > sourced from classpath (in that order). When run on the server, the solrj > code should look for a *Global System Timeout* setting before consulting > sysprops or classpath. > *Note that in no case is a hard-coded value the correct solution.* > If we get a consensus on categories and their locations, then the next step > is to begin adding sub tickets to bring specific timeouts into compliance. > Every such ticket should include an update to the section of the ref guide > documenting the configuration to which the timeout has been added (e.g. docs > for solr.xml for Global System Timeouts) describing what exactly is affected > by the timeout, the maximum allowed value and how zero and negative numbers > are handled. > It is of course true that some of these values will have the potential to > destroy system performance or integrity, and that should be mentioned in the > update to documentation. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13457) Managing Timeout values in Solr
[ https://issues.apache.org/jira/browse/SOLR-13457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16837563#comment-16837563 ] Gus Heck commented on SOLR-13457: - Ah thx for the link to that issue. It occurs to me that my thinking is somewhat biased towards cloud... so there's that cloud/classic variability to account for too. > Managing Timeout values in Solr > --- > > Key: SOLR-13457 > URL: https://issues.apache.org/jira/browse/SOLR-13457 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Gus Heck >Priority: Major > > Presently, Solr has a variety of timeouts for various connections or > operations. These timeouts have been added, tweaked and refined and in some > cases made configurable in an ad-hoc manner by the contributors of individual > features. Throughout the history of the project. This is all well and good > until one experiences a timeout during an otherwise valid use case and needs > to adjust it. > This has also made managing timeouts in unit tests "interesting" as noted in > SOLR-13389. > Probably nobody has the spare time to do a tour de force through the code and > coordinate every single timeout, so in this ticket I'd like to establish a > framework for categorizing time outs, a standard for how we make each > category configurable, and then add sub-tickets to address individual > timeouts. > The intention is that eventually, there will be no "magic number" timeout > values in code, and one can predict where to find the configuration for a > timeout by determining it's category. > Initial strawman categories (feel free to knock down or suggest alternatives): > # *Feature-Instance Timeout*: Timeouts that relate to a particular > instantiation of a feature, for example a database connection timeout for a > connection to a particular database by DIH. These should be set in the > configuration of that instance. > # *Optional Feature Timeout*: A timeout that only has meaning in the context > of a particular feature that is not required for solr to function... i.e. > something that can be turned on or off. Perhaps a timeout for communication > with an external ldap for authentication purposes. These should be configured > in the same configuration that enables this feature. > # *Global System Timeout*: A timeout that will always be an active part of > Solr these should be configured in a new section of solr.xml. For > example the Jetty thread idle timeout, or the default timeout for http calls > between nodes. > # *Node Specific Timeout*: A timeout which may differ on different nodes. I > don't know of any of these, but I'll grant the possibility. These (and only > these) should be set by setting system properties. If we don't have any of > these, that's just fine :). > # *Client Timeout*: These are timeouts in solrj code that are active in code > running outside the server. They should be configurable via java api, and via > a config file of some sort from a single location defined in a sysprop or > sourced from classpath (in that order). When run on the server, the solrj > code should look for a *Global System Timeout* setting before consulting > sysprops or classpath. > *Note that in no case is a hard-coded value the correct solution.* > If we get a consensus on categories and their locations, then the next step > is to begin adding sub tickets to bring specific timeouts into compliance. > Every such ticket should include an update to the section of the ref guide > documenting the configuration to which the timeout has been added (e.g. docs > for solr.xml for Global System Timeouts) describing what exactly is affected > by the timeout, the maximum allowed value and how zero and negative numbers > are handled. > It is of course true that some of these values will have the potential to > destroy system performance or integrity, and that should be mentioned in the > update to documentation. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13457) Managing Timeout values in Solr
[ https://issues.apache.org/jira/browse/SOLR-13457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16837559#comment-16837559 ] Shawn Heisey commented on SOLR-13457: - I've been putting some thought (but unfortunately not any actual *time*) into an overhaul of Solr's configuration system as a whole. It would be awesome if we could have a sane way of setting config at various levels - node and core would be the most obvious. We would need to decide whether node config would include SolrJ settings, or if that needs its own level ... would we want different cores/collections to be able to have different settings? It would be important to make sure inheritance works properly, and to only exclude things from one or more levels when it really makes no sense for it to be there. In cloud mode, the addition of ZK means there can also be cluster-level config and collection-level config (distinct from core-level) and if we want to get really fancy with Solr existing as two applications, some of the node-level config might be in ZK too. There are also things like the DIH properties file that would be nice to bring into a single configuration umbrella. Some of my ideas for this have been mentioned on SOLR-6733 and SOLR-6734. > Managing Timeout values in Solr > --- > > Key: SOLR-13457 > URL: https://issues.apache.org/jira/browse/SOLR-13457 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Gus Heck >Priority: Major > > Presently, Solr has a variety of timeouts for various connections or > operations. These timeouts have been added, tweaked and refined and in some > cases made configurable in an ad-hoc manner by the contributors of individual > features. Throughout the history of the project. This is all well and good > until one experiences a timeout during an otherwise valid use case and needs > to adjust it. > This has also made managing timeouts in unit tests "interesting" as noted in > SOLR-13389. > Probably nobody has the spare time to do a tour de force through the code and > coordinate every single timeout, so in this ticket I'd like to establish a > framework for categorizing time outs, a standard for how we make each > category configurable, and then add sub-tickets to address individual > timeouts. > The intention is that eventually, there will be no "magic number" timeout > values in code, and one can predict where to find the configuration for a > timeout by determining it's category. > Initial strawman categories (feel free to knock down or suggest alternatives): > # *Feature-Instance Timeout*: Timeouts that relate to a particular > instantiation of a feature, for example a database connection timeout for a > connection to a particular database by DIH. These should be set in the > configuration of that instance. > # *Optional Feature Timeout*: A timeout that only has meaning in the context > of a particular feature that is not required for solr to function... i.e. > something that can be turned on or off. Perhaps a timeout for communication > with an external ldap for authentication purposes. These should be configured > in the same configuration that enables this feature. > # *Global System Timeout*: A timeout that will always be an active part of > Solr these should be configured in a new section of solr.xml. For > example the Jetty thread idle timeout, or the default timeout for http calls > between nodes. > # *Node Specific Timeout*: A timeout which may differ on different nodes. I > don't know of any of these, but I'll grant the possibility. These (and only > these) should be set by setting system properties. If we don't have any of > these, that's just fine :). > # *Client Timeout*: These are timeouts in solrj code that are active in code > running outside the server. They should be configurable via java api, and via > a config file of some sort from a single location defined in a sysprop or > sourced from classpath (in that order). When run on the server, the solrj > code should look for a *Global System Timeout* setting before consulting > sysprops or classpath. > *Note that in no case is a hard-coded value the correct solution.* > If we get a consensus on categories and their locations, then the next step > is to begin adding sub tickets to bring specific timeouts into compliance. > Every such ticket should include an update to the section of the ref guide > documenting the configuration to which the timeout has been added (e.g. docs > for solr.xml for Global System Timeouts) describing what exactly is affected > by the timeout, the maximum allowed value and how zero and negative numbers > are handled. > It is of course true that some of these values will
[jira] [Commented] (SOLR-13457) Managing Timeout values in Solr
[ https://issues.apache.org/jira/browse/SOLR-13457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16836612#comment-16836612 ] Gus Heck commented on SOLR-13457: - Also as I think about this more, we may need an additional type for solrj client timeout settings, and since solrj is used in core, something fancy to distinguish the two cases. > Managing Timeout values in Solr > --- > > Key: SOLR-13457 > URL: https://issues.apache.org/jira/browse/SOLR-13457 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Gus Heck >Priority: Major > > Presently, Solr has a variety of timeouts for various connections or > operations. These timeouts have been added, tweaked and refined and in some > cases made configurable in an ad-hoc manner by the contributors of individual > features. Throughout the history of the project. This is all well and good > until one experiences a timeout during an otherwise valid use case and needs > to adjust it. > This has also made managing timeouts in unit tests "interesting" as noted in > SOLR-13389. > Probably nobody has the spare time to do a tour de force through the code and > coordinate every single timeout, so in this ticket I'd like to establish a > framework for categorizing time outs, a standard for how we make each > category configurable, and then add sub-tickets to address individual > timeouts. > The intention is that eventually, there will be no "magic number" timeout > values in code, and one can predict where to find the configuration for a > timeout by determining it's category. > Initial strawman categories (feel free to knock down or suggest alternatives): > # *Feature-Instance Timeout*: Timeouts that relate to a particular > instantiation of a feature, for example a database connection timeout for a > connection to a particular database by DIH. These should be set in the > configuration of that instance. > # *Optional Feature Timeout*: A timeout that only has meaning in the context > of a particular feature that is not required for solr to function... i.e. > something that can be turned on or off. Perhaps a timeout for communication > with an external ldap for authentication purposes. These should be configured > in the same configuration that enables this feature. > # *Global System Timeout*: A timeout that will always be an active part of > Solr these should be configured in a new section of solr.xml. For > example the Jetty thread idle timeout, or the default timeout for http calls > between nodes. > # *Node Specific Timeout*: A timeout which may differ on different nodes. I > don't know of any of these, but I'll grant the possibility. These (and only > these) should be set by setting system properties. If we don't have any of > these, that's just fine :). > *Note that in no case is a hard-coded value the correct solution.* > If we get a consensus on categories and their locations, then the next step > is to begin adding sub tickets to bring specific timeouts into compliance. > Every such ticket should include an update to the section of the ref guide > documenting the configuration to which the timeout has been added (e.g. docs > for solr.xml for Global System Timeouts) describing what exactly is affected > by the timeout, the maximum allowed value and how zero and negative numbers > are handled. > It is of course true that some of these values will have the potential to > destroy system performance or integrity, and that should be mentioned in the > update to documentation. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-13457) Managing Timeout values in Solr
[ https://issues.apache.org/jira/browse/SOLR-13457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16836590#comment-16836590 ] Erick Erickson commented on SOLR-13457: --- Finding them all will be a challenge, I count over 2,300 mentions of "timeout" in the source code. The overwhelming majority of them are fine (e.g. variable names, method names, default values. declarations of the TimeOut class). And no doubt even many/most of the ones that look potentially problematic are legit I suppose insuring that we have them _all_ is secondary to finding what we can. > Managing Timeout values in Solr > --- > > Key: SOLR-13457 > URL: https://issues.apache.org/jira/browse/SOLR-13457 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) >Affects Versions: master (9.0) >Reporter: Gus Heck >Priority: Major > > Presently, Solr has a variety of timeouts for various connections or > operations. These timeouts have been added, tweaked and refined and in some > cases made configurable in an ad-hoc manner by the contributors of individual > features. Throughout the history of the project. This is all well and good > until one experiences a timeout during an otherwise valid use case and needs > to adjust it. > This has also made managing timeouts in unit tests "interesting" as noted in > SOLR-13389. > Probably nobody has the spare time to do a tour de force through the code and > coordinate every single timeout, so in this ticket I'd like to establish a > framework for categorizing time outs, a standard for how we make each > category configurable, and then add sub-tickets to address individual > timeouts. > The intention is that eventually, there will be no "magic number" timeout > values in code, and one can predict where to find the configuration for a > timeout by determining it's category. > Initial strawman categories (feel free to knock down or suggest alternatives): > # *Feature-Instance Timeout*: Timeouts that relate to a particular > instantiation of a feature, for example a database connection timeout for a > connection to a particular database by DIH. These should be set in the > configuration of that instance. > # *Optional Feature Timeout*: A timeout that only has meaning in the context > of a particular feature that is not required for solr to function... i.e. > something that can be turned on or off. Perhaps a timeout for communication > with an external ldap for authentication purposes. These should be configured > in the same configuration that enables this feature. > # *Global System Timeout*: A timeout that will always be an active part of > Solr these should be configured in a new section of solr.xml. For > example the Jetty thread idle timeout, or the default timeout for http calls > between nodes. > # *Node Specific Timeout*: A timeout which may differ on different nodes. I > don't know of any of these, but I'll grant the possibility. These (and only > these) should be set by setting system properties. If we don't have any of > these, that's just fine :). > *Note that in no case is a hard-coded value the correct solution.* > If we get a consensus on categories and their locations, then the next step > is to begin adding sub tickets to bring specific timeouts into compliance. > Every such ticket should include an update to the section of the ref guide > documenting the configuration to which the timeout has been added (e.g. docs > for solr.xml for Global System Timeouts) describing what exactly is affected > by the timeout, the maximum allowed value and how zero and negative numbers > are handled. > It is of course true that some of these values will have the potential to > destroy system performance or integrity, and that should be mentioned in the > update to documentation. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
