[
https://issues.apache.org/jira/browse/SOLR-6547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14175888#comment-14175888
]
Shawn Heisey commented on SOLR-6547:
------------------------------------
There's merit either way.
Integer.MAX_VALUE in milliseconds is a little more than 24 days. I doubt you
would ever run into a query that would actually take that long and still have
enough resources to actually finish, so an int has plenty of capacity to handle
QTime. The difference is tiny for a single value, but a long does take up
twice as much memory. If most of the existing code uses an int, I am inclined
to stick with that and change the deviating code.
On the other hand ... everything else related to time in Java *is* represented
as a long, as [~anuragsharma] mentioned. If the value is ever used for
calculation with any of those other numbers, it might save a tiny bit of CPU
time if Java doesn't have to convert.
Switching everything to a long is likely to involve quite a bit of effort to
locate and change every place that it's used, which is a big part of why I
suggest sticking with int. I don't think we would ever *need* a long for
relative times.
> CloudSolrServer query getqtime Exception
> ----------------------------------------
>
> Key: SOLR-6547
> URL: https://issues.apache.org/jira/browse/SOLR-6547
> Project: Solr
> Issue Type: Bug
> Components: SolrJ
> Affects Versions: 4.10
> Reporter: kevin
>
> We are using CloudSolrServer to query ,but solrj throw Exception ;
> java.lang.ClassCastException: java.lang.Long cannot be cast to
> java.lang.Integer at
> org.apache.solr.client.solrj.response.SolrResponseBase.getQTime(SolrResponseBase.java:76)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
