RE: Solr fact response strange behaviour
Hi Mikhail,
Here is the code, where basically we are trying to retrieve the value of facet
counts, that sometimes returned as Integer and sometime as Long,
where we've got the ClassCast exception, until the W/A of Numeric casting was
applied.
if (resList != null) {
List terms = new ArrayList();
resList.stream().forEach(entry -> {
String term =
entry.get(BUCKET_VAL).toString().replace("_",SPACE);
terms.add(new Term(term, (Long)entry.get(BUCKET_COUNT))); //
line 170
});
Regards,
Adi
-Original Message-
From: Mikhail Khludnev
Sent: Thursday, January 30, 2020 8:35 AM
To: solr-user
Subject: Re: Solr fact response strange behaviour
What's happen at AutoCompleteAPI.java:170 ?
On Wed, Jan 29, 2020 at 9:28 PM Kaminski, Adi
mailto:adi.kamin...@verint.com>>
wrote:
> Sure, thanks for the guidance and the assistance anyway.
>
> Here is the stack trace:
> Here is the stack trace:
> [29/01/20 08:09:41:041 IST] [http-nio-8080-exec-2] ERROR api.BaseAPI:
> There was an Exception calling Solr
> java.lang.ClassCastException: java.lang.Integer cannot be cast to
> java.lang.Long at
> com.productcore.analytics.api.AutoCompleteAPI.lambda$mapSolrResponse$0
> (AutoCompleteAPI.java:170)
> ~[classes/:?]
> at
> java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.ja
> va:1382)
> ~[?:1.8.0_201]
> at
> java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java
> :580)
> ~[?:1.8.0_201]
> at
> com.productcore.analytics.api.AutoCompleteAPI.mapSolrResponse(AutoComp
> leteAPI.java:167)
> ~[classes/:?]
> at com.productcore.analytics.api.BaseAPI.execute(BaseAPI.java:48)
> [classes/:?]
> at
> com.productcore.analytics.controllers.DalController.getAutocomplete(Da
> lController.java:205)
> [classes/:?]
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> ~[?:1.8.0_201] at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
> ava:62)
> ~[?:1.8.0_201]
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
> orImpl.java:43)
> ~[?:1.8.0_201]
> at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_201] at
> org.springframework.web.method.support.InvocableHandlerMethod.doInvoke
> (InvocableHandlerMethod.java:189)
> [spring-web-5.1.6.RELEASE.jar:5.1.6.RELEASE]
> at
> org.springframework.web.method.support.InvocableHandlerMethod.invokeFo
> rRequest(InvocableHandlerMethod.java:138)
> [spring-web-5.1.6.RELEASE.jar:5.1.6.RELEASE]
> at
> org.springframework.web.servlet.mvc.method.annotation.ServletInvocable
> HandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:102)
> [spring-webmvc-5.1.6.RELEASE.jar:5.1.6.RELEASE]
> at
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHa
> ndlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:892
> ) [spring-webmvc-5.1.6.RELEASE.jar:5.1.6.RELEASE]
> at
> org.springframework.web.servlet.mvc.method.annotation.RequestMappingHa
> ndlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:797)
> [spring-webmvc-5.1.6.RELEASE.jar:5.1.6.RELEASE]
> at
> org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapte
> r.handle(AbstractHandlerMethodAdapter.java:87)
> [spring-webmvc-5.1.6.RELEASE.jar:5.1.6.RELEASE]
> at
> org.springframework.web.servlet.DispatcherServlet.doDispatch(Dispatche
> rServlet.java:1038) [spring-webmvc-5.1.6.RELEASE.jar:5.1.6.RELEASE]
> at
> org.springframework.web.servlet.DispatcherServlet.doService(Dispatcher
> Servlet.java:942) [spring-webmvc-5.1.6.RELEASE.jar:5.1.6.RELEASE]
> at
> org.springframework.web.servlet.FrameworkServlet.processRequest(Framew
> orkServlet.java:1005) [spring-webmvc-5.1.6.RELEASE.jar:5.1.6.RELEASE]
> at
> org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServl
> et.java:908) [spring-webmvc-5.1.6.RELEASE.jar:5.1.6.RELEASE]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:660)
> [tomcat-embed-core-9.0.17.jar:9.0.17]
> at
> org.springframework.web.servlet.FrameworkServlet.service(FrameworkServ
> let.java:882) [spring-webmvc-5.1.6.RELEASE.jar:5.1.6.RELEASE]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
> [tomcat-embed-core-9.0.17.jar:9.0.17]
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
> cationFilterChain.java:231)
> [tomcat-embed-core-9.0.17.jar:9.0.17]
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
> lterChain.java:166)
> [tomcat-embed-core-9.0.17.jar:9.0.17]
> at
> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
> [
Re: Solr fact response strange behaviour
9.0.17] > at > org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99) > [spring-web-5.1.6.RELEASE.jar:5.1.6.RELEASE] > at > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) > [spring-web-5.1.6.RELEASE.jar:5.1.6.RELEASE] > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) > [tomcat-embed-core-9.0.17.jar:9.0.17] > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) > [tomcat-embed-core-9.0.17.jar:9.0.17] > at > org.springframework.web.filter.FormContentFilter.doFilterInternal(FormContentFilter.java:92) > [spring-web-5.1.6.RELEASE.jar:5.1.6.RELEASE] > at > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) > [spring-web-5.1.6.RELEASE.jar:5.1.6.RELEASE] > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) > [tomcat-embed-core-9.0.17.jar:9.0.17] > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) > [tomcat-embed-core-9.0.17.jar:9.0.17] > at > org.springframework.web.filter.HiddenHttpMethodFilter.doFilterInternal(HiddenHttpMethodFilter.java:93) > [spring-web-5.1.6.RELEASE.jar:5.1.6.RELEASE] > at > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) > [spring-web-5.1.6.RELEASE.jar:5.1.6.RELEASE] > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) > [tomcat-embed-core-9.0.17.jar:9.0.17] > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) > [tomcat-embed-core-9.0.17.jar:9.0.17] > at > org.springframework.boot.actuate.metrics.web.servlet.WebMvcMetricsFilter.filterAndRecordMetrics(WebMvcMetricsFilter.java:117) > [spring-boot-actuator-2.1.4.RELEASE.jar:2.1.4.RELEASE] > at > org.springframework.boot.actuate.metrics.web.servlet.WebMvcMetricsFilter.doFilterInternal(WebMvcMetricsFilter.java:106) > [spring-boot-actuator-2.1.4.RELEASE.jar:2.1.4.RELEASE] > at > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) > [spring-web-5.1.6.RELEASE.jar:5.1.6.RELEASE] > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) > [tomcat-embed-core-9.0.17.jar:9.0.17] > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) > [tomcat-embed-core-9.0.17.jar:9.0.17] > at > org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:200) > [spring-web-5.1.6.RELEASE.jar:5.1.6.RELEASE] > at > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) > [spring-web-5.1.6.RELEASE.jar:5.1.6.RELEASE] > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) > [tomcat-embed-core-9.0.17.jar:9.0.17] > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) > [tomcat-embed-core-9.0.17.jar:9.0.17] > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:200) > [tomcat-embed-core-9.0.17.jar:9.0.17] > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) > [tomcat-embed-core-9.0.17.jar:9.0.17] > at > org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:490) > [tomcat-embed-core-9.0.17.jar:9.0.17] > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139) > [tomcat-embed-core-9.0.17.jar:9.0.17] > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92) > [tomcat-embed-core-9.0.17.jar:9.0.17] > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74) > [tomcat-embed-core-9.0.17.jar:9.0.17] > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) > [tomcat-embed-core-9.0.17.jar:9.0.17] > at > org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408) > [tomcat-embed-core-9.0.17.jar:9.0.17] > at > org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) > [tomcat-embed-core-9.0.17.jar:9.0.17] > at > org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:834) > [tomcat-embed-core-9.0.17.jar:9.0.17] > at > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1415) > [tomcat-embed-core-9.0.17.jar:9.0.17] > at > org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) > [tomcat-embed-core-9.0.17.jar:9.0.17] &g
Re: Solr fact response strange behaviour
5) > [tomcat-embed-core-9.0.17.jar:9.0.17] > at > org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) > [tomcat-embed-core-9.0.17.jar:9.0.17] > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > [?:1.8.0_201] > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > [?:1.8.0_201] > at > org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) > [tomcat-embed-core-9.0.17.jar:9.0.17] > at java.lang.Thread.run(Thread.java:748) [?:1.8.0_201] > > -Original Message- > From: Jason Gerlowski > Sent: Wednesday, January 29, 2020 5:40 PM > To: solr-user@lucene.apache.org > Subject: Re: Solr fact response strange behaviour > > Hey Adi, > > There was a separate JIRA for this on the SolrJ objects it sounds like you're > using: SOLR-13780. That JIRA was fixed, apparently in 8.3, so I'm surprised > you're still seeing the issue. If you include the full stacktrace and a > snippet of code to reproduce, I'm curious to take a look. > > That won't help you in the short term though. For that, yes, you'll have to > use ((Number)count).longValue() in the interim. > > Best, > > Jason > > On Tue, Jan 28, 2020 at 2:20 AM Kaminski, Adi wrote: > > > > Thanks Mikhail ! > > > > In issue comments that you have shared it seems that Yonik S doesn't agree > > it's a defect...so probably will remain opened for a while. > > > > > > > > So meanwhile, is it recommended to perform casting > > ((Number)count).longValue() to our relevant logic ? > > > > > > > > Thanks, > > Adi > > > > > > > > -Original Message----- > > From: Mikhail Khludnev > > Sent: Tuesday, January 28, 2020 9:14 AM > > To: solr-user > > Subject: Re: Solr fact response strange behaviour > > > > > > > > https://issues.apache.org/jira/browse/SOLR-11775 > > > > > > > > On Tue, Jan 28, 2020 at 10:00 AM Kaminski, Adi > > mailto:adi.kamin...@verint.com>> > > > > wrote: > > > > > > > > > Is it existing issue and tracked for future fix consideration ? > > > > > > > > > > What's the suggestion as W/A until fix - to case every related > > > > > response with ((Number)count).longValue() ? > > > > > > > > > > -Original Message- > > > > > From: Mikhail Khludnev mailto:m...@apache.org>> > > > > > Sent: Tuesday, January 28, 2020 8:53 AM > > > > > To: solr-user > > > mailto:solr-user@lucene.apache.org>> > > > > > Subject: Re: Solr fact response strange behaviour > > > > > > > > > > I suppose there's an issue, which no one ever took a look. > > > > > > > > > > https://lucene.472066.n3.nabble.com/JSON-facets-count-a-long-or-an-i > > > nt > > > > > eger-in-cloud-and-non-cloud-modes-td4265291.html > > > > > > > > > > > > > > > On Mon, Jan 27, 2020 at 11:47 PM Kaminski, Adi > > > > > mailto:adi.kamin...@verint.com>> > > > > > wrote: > > > > > > > > > > > SolrJ client is used of SolrCloud of Solr 8.3 version for JSON > > > > > > Facets requests...any idea why not consistent ? > > > > > > > > > > > > Sent from Workspace ONE Boxer > > > > > > > > > > > > On Jan 27, 2020 22:13, Mikhail Khludnev > > > > mailto:m...@apache.org>> wrote: > > > > > > Hello, > > > > > > It might be different between SolrCloud and standalone mode. No > > > > data > > > > > > enough to make a conclusion. > > > > > > > > > > > > On Mon, Jan 27, 2020 at 5:40 PM Rudenko, Artur > > > > > > mailto:artur.rude...@verint.com>> > > > > > > wrote: > > > > > > > > > > > > > I'm trying to parse facet response, but sometimes the count > > > > > > > returns as Long type and sometimes as Integer type(on different > > > > > > > environments), The error is: > > > > > > > "java.lang.ClassCastException: java.lang.Integer cannot be cast > > > > > to > > > > > > > java.lang.Long" > > > > > > > > > > > > > > Can you please explain why this happenes? Why it not consistent? &g
RE: Solr fact response strange behaviour
) [tomcat-embed-core-9.0.17.jar:9.0.17] at org.springframework.web.filter.FormContentFilter.doFilterInternal(FormContentFilter.java:92) [spring-web-5.1.6.RELEASE.jar:5.1.6.RELEASE] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) [spring-web-5.1.6.RELEASE.jar:5.1.6.RELEASE] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) [tomcat-embed-core-9.0.17.jar:9.0.17] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [tomcat-embed-core-9.0.17.jar:9.0.17] at org.springframework.web.filter.HiddenHttpMethodFilter.doFilterInternal(HiddenHttpMethodFilter.java:93) [spring-web-5.1.6.RELEASE.jar:5.1.6.RELEASE] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) [spring-web-5.1.6.RELEASE.jar:5.1.6.RELEASE] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) [tomcat-embed-core-9.0.17.jar:9.0.17] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [tomcat-embed-core-9.0.17.jar:9.0.17] at org.springframework.boot.actuate.metrics.web.servlet.WebMvcMetricsFilter.filterAndRecordMetrics(WebMvcMetricsFilter.java:117) [spring-boot-actuator-2.1.4.RELEASE.jar:2.1.4.RELEASE] at org.springframework.boot.actuate.metrics.web.servlet.WebMvcMetricsFilter.doFilterInternal(WebMvcMetricsFilter.java:106) [spring-boot-actuator-2.1.4.RELEASE.jar:2.1.4.RELEASE] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) [spring-web-5.1.6.RELEASE.jar:5.1.6.RELEASE] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) [tomcat-embed-core-9.0.17.jar:9.0.17] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [tomcat-embed-core-9.0.17.jar:9.0.17] at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:200) [spring-web-5.1.6.RELEASE.jar:5.1.6.RELEASE] at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) [spring-web-5.1.6.RELEASE.jar:5.1.6.RELEASE] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) [tomcat-embed-core-9.0.17.jar:9.0.17] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) [tomcat-embed-core-9.0.17.jar:9.0.17] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:200) [tomcat-embed-core-9.0.17.jar:9.0.17] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) [tomcat-embed-core-9.0.17.jar:9.0.17] at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:490) [tomcat-embed-core-9.0.17.jar:9.0.17] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139) [tomcat-embed-core-9.0.17.jar:9.0.17] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92) [tomcat-embed-core-9.0.17.jar:9.0.17] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74) [tomcat-embed-core-9.0.17.jar:9.0.17] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) [tomcat-embed-core-9.0.17.jar:9.0.17] at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:408) [tomcat-embed-core-9.0.17.jar:9.0.17] at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) [tomcat-embed-core-9.0.17.jar:9.0.17] at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:834) [tomcat-embed-core-9.0.17.jar:9.0.17] at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1415) [tomcat-embed-core-9.0.17.jar:9.0.17] at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) [tomcat-embed-core-9.0.17.jar:9.0.17] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:1.8.0_201] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:1.8.0_201] at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) [tomcat-embed-core-9.0.17.jar:9.0.17] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_201] -Original Message- From: Jason Gerlowski Sent: Wednesday, January 29, 2020 5:40 PM To: solr-user@lucene.apache.org Subject: Re: Solr fact response strange behaviour Hey Adi, There was a separate JIRA for this on the SolrJ objects it sounds like you're using: SOLR-13780. That JIRA was fixed, apparently in 8.3, so I'm surprised you're still seeing the issue. If you include the full stacktrace and a snippet of code to reproduce, I'm curious to take a look. That won't help you in the short term though. For that, yes, you'll have to use ((Number)count).longValue() in the interim. Best
Re: Solr fact response strange behaviour
Hey Adi, There was a separate JIRA for this on the SolrJ objects it sounds like you're using: SOLR-13780. That JIRA was fixed, apparently in 8.3, so I'm surprised you're still seeing the issue. If you include the full stacktrace and a snippet of code to reproduce, I'm curious to take a look. That won't help you in the short term though. For that, yes, you'll have to use ((Number)count).longValue() in the interim. Best, Jason On Tue, Jan 28, 2020 at 2:20 AM Kaminski, Adi wrote: > > Thanks Mikhail ! > > In issue comments that you have shared it seems that Yonik S doesn't agree > it's a defect...so probably will remain opened for a while. > > > > So meanwhile, is it recommended to perform casting > ((Number)count).longValue() to our relevant logic ? > > > > Thanks, > Adi > > > > -Original Message- > From: Mikhail Khludnev > Sent: Tuesday, January 28, 2020 9:14 AM > To: solr-user > Subject: Re: Solr fact response strange behaviour > > > > https://issues.apache.org/jira/browse/SOLR-11775 > > > > On Tue, Jan 28, 2020 at 10:00 AM Kaminski, Adi > mailto:adi.kamin...@verint.com>> > > wrote: > > > > > Is it existing issue and tracked for future fix consideration ? > > > > > > What's the suggestion as W/A until fix - to case every related > > > response with ((Number)count).longValue() ? > > > > > > -Original Message- > > > From: Mikhail Khludnev mailto:m...@apache.org>> > > > Sent: Tuesday, January 28, 2020 8:53 AM > > > To: solr-user > > mailto:solr-user@lucene.apache.org>> > > > Subject: Re: Solr fact response strange behaviour > > > > > > I suppose there's an issue, which no one ever took a look. > > > > > > https://lucene.472066.n3.nabble.com/JSON-facets-count-a-long-or-an-int > > > eger-in-cloud-and-non-cloud-modes-td4265291.html > > > > > > > > > On Mon, Jan 27, 2020 at 11:47 PM Kaminski, Adi > > > mailto:adi.kamin...@verint.com>> > > > wrote: > > > > > > > SolrJ client is used of SolrCloud of Solr 8.3 version for JSON > > > > Facets requests...any idea why not consistent ? > > > > > > > > Sent from Workspace ONE Boxer > > > > > > > > On Jan 27, 2020 22:13, Mikhail Khludnev > > > mailto:m...@apache.org>> wrote: > > > > Hello, > > > > It might be different between SolrCloud and standalone mode. No data > > > > enough to make a conclusion. > > > > > > > > On Mon, Jan 27, 2020 at 5:40 PM Rudenko, Artur > > > > mailto:artur.rude...@verint.com>> > > > > wrote: > > > > > > > > > I'm trying to parse facet response, but sometimes the count > > > > > returns as Long type and sometimes as Integer type(on different > > > > > environments), The error is: > > > > > "java.lang.ClassCastException: java.lang.Integer cannot be cast to > > > > > java.lang.Long" > > > > > > > > > > Can you please explain why this happenes? Why it not consistent? > > > > > > > > > > I know the workaround to use Number class and longValue method but > > > > > I want to to the root cause before using this workaround > > > > > > > > > > Artur Rudenko > > > > > > > > > > > > > > > > > > > > This electronic message may contain proprietary and confidential > > > > > information of Verint Systems Inc., its affiliates and/or subsidiaries. > > > > The > > > > > information is intended to be for the use of the individual(s) or > > > > > entity(ies) named above. If you are not the intended recipient (or > > > > > authorized to receive this e-mail for the intended recipient), you > > > > > may > > > > not > > > > > use, copy, disclose or distribute to anyone this message or any > > > > information > > > > > contained in this message. If you have received this electronic > > > > > message > > > > in > > > > > error, please notify us by replying to this e-mail. > > > > > > > > > > > > > > > > > -- > > > > Sincerely yours > > > > Mikhail Khludnev > > > > > > > > > > > > This electronic message may contain proprietary and confidential > > > > information of Verint Systems
RE: Solr fact response strange behaviour
Thanks Mikhail ! In issue comments that you have shared it seems that Yonik S doesn't agree it's a defect...so probably will remain opened for a while. So meanwhile, is it recommended to perform casting ((Number)count).longValue() to our relevant logic ? Thanks, Adi -Original Message- From: Mikhail Khludnev Sent: Tuesday, January 28, 2020 9:14 AM To: solr-user Subject: Re: Solr fact response strange behaviour https://issues.apache.org/jira/browse/SOLR-11775 On Tue, Jan 28, 2020 at 10:00 AM Kaminski, Adi mailto:adi.kamin...@verint.com>> wrote: > Is it existing issue and tracked for future fix consideration ? > > What's the suggestion as W/A until fix - to case every related > response with ((Number)count).longValue() ? > > -Original Message- > From: Mikhail Khludnev mailto:m...@apache.org>> > Sent: Tuesday, January 28, 2020 8:53 AM > To: solr-user > mailto:solr-user@lucene.apache.org>> > Subject: Re: Solr fact response strange behaviour > > I suppose there's an issue, which no one ever took a look. > > https://lucene.472066.n3.nabble.com/JSON-facets-count-a-long-or-an-int > eger-in-cloud-and-non-cloud-modes-td4265291.html > > > On Mon, Jan 27, 2020 at 11:47 PM Kaminski, Adi > mailto:adi.kamin...@verint.com>> > wrote: > > > SolrJ client is used of SolrCloud of Solr 8.3 version for JSON > > Facets requests...any idea why not consistent ? > > > > Sent from Workspace ONE Boxer > > > > On Jan 27, 2020 22:13, Mikhail Khludnev > > mailto:m...@apache.org>> wrote: > > Hello, > > It might be different between SolrCloud and standalone mode. No data > > enough to make a conclusion. > > > > On Mon, Jan 27, 2020 at 5:40 PM Rudenko, Artur > > mailto:artur.rude...@verint.com>> > > wrote: > > > > > I'm trying to parse facet response, but sometimes the count > > > returns as Long type and sometimes as Integer type(on different > > > environments), The error is: > > > "java.lang.ClassCastException: java.lang.Integer cannot be cast to > > > java.lang.Long" > > > > > > Can you please explain why this happenes? Why it not consistent? > > > > > > I know the workaround to use Number class and longValue method but > > > I want to to the root cause before using this workaround > > > > > > Artur Rudenko > > > > > > > > > > > > This electronic message may contain proprietary and confidential > > > information of Verint Systems Inc., its affiliates and/or subsidiaries. > > The > > > information is intended to be for the use of the individual(s) or > > > entity(ies) named above. If you are not the intended recipient (or > > > authorized to receive this e-mail for the intended recipient), you > > > may > > not > > > use, copy, disclose or distribute to anyone this message or any > > information > > > contained in this message. If you have received this electronic > > > message > > in > > > error, please notify us by replying to this e-mail. > > > > > > > > > -- > > Sincerely yours > > Mikhail Khludnev > > > > > > This electronic message may contain proprietary and confidential > > information of Verint Systems Inc., its affiliates and/or > > subsidiaries. The information is intended to be for the use of the > > individual(s) or > > entity(ies) named above. If you are not the intended recipient (or > > authorized to receive this e-mail for the intended recipient), you > > may not use, copy, disclose or distribute to anyone this message or > > any information contained in this message. If you have received this > > electronic message in error, please notify us by replying to this e-mail. > > > > > -- > Sincerely yours > Mikhail Khludnev > > > This electronic message may contain proprietary and confidential > information of Verint Systems Inc., its affiliates and/or > subsidiaries. The information is intended to be for the use of the > individual(s) or > entity(ies) named above. If you are not the intended recipient (or > authorized to receive this e-mail for the intended recipient), you may > not use, copy, disclose or distribute to anyone this message or any > information contained in this message. If you have received this > electronic message in error, please notify us by replying to this e-mail. > -- Sincerely yours Mikhail Khludnev This electronic message may contain proprietary and confidential information of Verint Systems Inc., its affiliates and/or subsidiaries. The information is intended to be for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient (or authorized to receive this e-mail for the intended recipient), you may not use, copy, disclose or distribute to anyone this message or any information contained in this message. If you have received this electronic message in error, please notify us by replying to this e-mail.
Re: Solr fact response strange behaviour
https://issues.apache.org/jira/browse/SOLR-11775 On Tue, Jan 28, 2020 at 10:00 AM Kaminski, Adi wrote: > Is it existing issue and tracked for future fix consideration ? > > What's the suggestion as W/A until fix - to case every related response > with ((Number)count).longValue() ? > > -Original Message- > From: Mikhail Khludnev > Sent: Tuesday, January 28, 2020 8:53 AM > To: solr-user > Subject: Re: Solr fact response strange behaviour > > I suppose there's an issue, which no one ever took a look. > > https://lucene.472066.n3.nabble.com/JSON-facets-count-a-long-or-an-integer-in-cloud-and-non-cloud-modes-td4265291.html > > > On Mon, Jan 27, 2020 at 11:47 PM Kaminski, Adi > wrote: > > > SolrJ client is used of SolrCloud of Solr 8.3 version for JSON Facets > > requests...any idea why not consistent ? > > > > Sent from Workspace ONE Boxer > > > > On Jan 27, 2020 22:13, Mikhail Khludnev wrote: > > Hello, > > It might be different between SolrCloud and standalone mode. No data > > enough to make a conclusion. > > > > On Mon, Jan 27, 2020 at 5:40 PM Rudenko, Artur > > > > wrote: > > > > > I'm trying to parse facet response, but sometimes the count returns > > > as Long type and sometimes as Integer type(on different > > > environments), The error is: > > > "java.lang.ClassCastException: java.lang.Integer cannot be cast to > > > java.lang.Long" > > > > > > Can you please explain why this happenes? Why it not consistent? > > > > > > I know the workaround to use Number class and longValue method but I > > > want to to the root cause before using this workaround > > > > > > Artur Rudenko > > > > > > > > > > > > This electronic message may contain proprietary and confidential > > > information of Verint Systems Inc., its affiliates and/or subsidiaries. > > The > > > information is intended to be for the use of the individual(s) or > > > entity(ies) named above. If you are not the intended recipient (or > > > authorized to receive this e-mail for the intended recipient), you > > > may > > not > > > use, copy, disclose or distribute to anyone this message or any > > information > > > contained in this message. If you have received this electronic > > > message > > in > > > error, please notify us by replying to this e-mail. > > > > > > > > > -- > > Sincerely yours > > Mikhail Khludnev > > > > > > This electronic message may contain proprietary and confidential > > information of Verint Systems Inc., its affiliates and/or > > subsidiaries. The information is intended to be for the use of the > > individual(s) or > > entity(ies) named above. If you are not the intended recipient (or > > authorized to receive this e-mail for the intended recipient), you may > > not use, copy, disclose or distribute to anyone this message or any > > information contained in this message. If you have received this > > electronic message in error, please notify us by replying to this e-mail. > > > > > -- > Sincerely yours > Mikhail Khludnev > > > This electronic message may contain proprietary and confidential > information of Verint Systems Inc., its affiliates and/or subsidiaries. The > information is intended to be for the use of the individual(s) or > entity(ies) named above. If you are not the intended recipient (or > authorized to receive this e-mail for the intended recipient), you may not > use, copy, disclose or distribute to anyone this message or any information > contained in this message. If you have received this electronic message in > error, please notify us by replying to this e-mail. > -- Sincerely yours Mikhail Khludnev
RE: Solr fact response strange behaviour
Is it existing issue and tracked for future fix consideration ? What's the suggestion as W/A until fix - to case every related response with ((Number)count).longValue() ? -Original Message- From: Mikhail Khludnev Sent: Tuesday, January 28, 2020 8:53 AM To: solr-user Subject: Re: Solr fact response strange behaviour I suppose there's an issue, which no one ever took a look. https://lucene.472066.n3.nabble.com/JSON-facets-count-a-long-or-an-integer-in-cloud-and-non-cloud-modes-td4265291.html On Mon, Jan 27, 2020 at 11:47 PM Kaminski, Adi wrote: > SolrJ client is used of SolrCloud of Solr 8.3 version for JSON Facets > requests...any idea why not consistent ? > > Sent from Workspace ONE Boxer > > On Jan 27, 2020 22:13, Mikhail Khludnev wrote: > Hello, > It might be different between SolrCloud and standalone mode. No data > enough to make a conclusion. > > On Mon, Jan 27, 2020 at 5:40 PM Rudenko, Artur > > wrote: > > > I'm trying to parse facet response, but sometimes the count returns > > as Long type and sometimes as Integer type(on different > > environments), The error is: > > "java.lang.ClassCastException: java.lang.Integer cannot be cast to > > java.lang.Long" > > > > Can you please explain why this happenes? Why it not consistent? > > > > I know the workaround to use Number class and longValue method but I > > want to to the root cause before using this workaround > > > > Artur Rudenko > > > > > > > > This electronic message may contain proprietary and confidential > > information of Verint Systems Inc., its affiliates and/or subsidiaries. > The > > information is intended to be for the use of the individual(s) or > > entity(ies) named above. If you are not the intended recipient (or > > authorized to receive this e-mail for the intended recipient), you > > may > not > > use, copy, disclose or distribute to anyone this message or any > information > > contained in this message. If you have received this electronic > > message > in > > error, please notify us by replying to this e-mail. > > > > > -- > Sincerely yours > Mikhail Khludnev > > > This electronic message may contain proprietary and confidential > information of Verint Systems Inc., its affiliates and/or > subsidiaries. The information is intended to be for the use of the > individual(s) or > entity(ies) named above. If you are not the intended recipient (or > authorized to receive this e-mail for the intended recipient), you may > not use, copy, disclose or distribute to anyone this message or any > information contained in this message. If you have received this > electronic message in error, please notify us by replying to this e-mail. > -- Sincerely yours Mikhail Khludnev This electronic message may contain proprietary and confidential information of Verint Systems Inc., its affiliates and/or subsidiaries. The information is intended to be for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient (or authorized to receive this e-mail for the intended recipient), you may not use, copy, disclose or distribute to anyone this message or any information contained in this message. If you have received this electronic message in error, please notify us by replying to this e-mail.
Re: Solr fact response strange behaviour
I suppose there's an issue, which no one ever took a look. https://lucene.472066.n3.nabble.com/JSON-facets-count-a-long-or-an-integer-in-cloud-and-non-cloud-modes-td4265291.html On Mon, Jan 27, 2020 at 11:47 PM Kaminski, Adi wrote: > SolrJ client is used of SolrCloud of Solr 8.3 version for JSON Facets > requests...any idea why not consistent ? > > Sent from Workspace ONE Boxer > > On Jan 27, 2020 22:13, Mikhail Khludnev wrote: > Hello, > It might be different between SolrCloud and standalone mode. No data enough > to make a conclusion. > > On Mon, Jan 27, 2020 at 5:40 PM Rudenko, Artur > wrote: > > > I'm trying to parse facet response, but sometimes the count returns as > > Long type and sometimes as Integer type(on different environments), The > > error is: > > "java.lang.ClassCastException: java.lang.Integer cannot be cast to > > java.lang.Long" > > > > Can you please explain why this happenes? Why it not consistent? > > > > I know the workaround to use Number class and longValue method but I want > > to to the root cause before using this workaround > > > > Artur Rudenko > > > > > > > > This electronic message may contain proprietary and confidential > > information of Verint Systems Inc., its affiliates and/or subsidiaries. > The > > information is intended to be for the use of the individual(s) or > > entity(ies) named above. If you are not the intended recipient (or > > authorized to receive this e-mail for the intended recipient), you may > not > > use, copy, disclose or distribute to anyone this message or any > information > > contained in this message. If you have received this electronic message > in > > error, please notify us by replying to this e-mail. > > > > > -- > Sincerely yours > Mikhail Khludnev > > > This electronic message may contain proprietary and confidential > information of Verint Systems Inc., its affiliates and/or subsidiaries. The > information is intended to be for the use of the individual(s) or > entity(ies) named above. If you are not the intended recipient (or > authorized to receive this e-mail for the intended recipient), you may not > use, copy, disclose or distribute to anyone this message or any information > contained in this message. If you have received this electronic message in > error, please notify us by replying to this e-mail. > -- Sincerely yours Mikhail Khludnev
Re: Solr fact response strange behaviour
SolrJ client is used of SolrCloud of Solr 8.3 version for JSON Facets requests...any idea why not consistent ? Sent from Workspace ONE Boxer On Jan 27, 2020 22:13, Mikhail Khludnev wrote: Hello, It might be different between SolrCloud and standalone mode. No data enough to make a conclusion. On Mon, Jan 27, 2020 at 5:40 PM Rudenko, Artur wrote: > I'm trying to parse facet response, but sometimes the count returns as > Long type and sometimes as Integer type(on different environments), The > error is: > "java.lang.ClassCastException: java.lang.Integer cannot be cast to > java.lang.Long" > > Can you please explain why this happenes? Why it not consistent? > > I know the workaround to use Number class and longValue method but I want > to to the root cause before using this workaround > > Artur Rudenko > > > > This electronic message may contain proprietary and confidential > information of Verint Systems Inc., its affiliates and/or subsidiaries. The > information is intended to be for the use of the individual(s) or > entity(ies) named above. If you are not the intended recipient (or > authorized to receive this e-mail for the intended recipient), you may not > use, copy, disclose or distribute to anyone this message or any information > contained in this message. If you have received this electronic message in > error, please notify us by replying to this e-mail. > -- Sincerely yours Mikhail Khludnev This electronic message may contain proprietary and confidential information of Verint Systems Inc., its affiliates and/or subsidiaries. The information is intended to be for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient (or authorized to receive this e-mail for the intended recipient), you may not use, copy, disclose or distribute to anyone this message or any information contained in this message. If you have received this electronic message in error, please notify us by replying to this e-mail.
Re: Solr fact response strange behaviour
Hello, It might be different between SolrCloud and standalone mode. No data enough to make a conclusion. On Mon, Jan 27, 2020 at 5:40 PM Rudenko, Artur wrote: > I'm trying to parse facet response, but sometimes the count returns as > Long type and sometimes as Integer type(on different environments), The > error is: > "java.lang.ClassCastException: java.lang.Integer cannot be cast to > java.lang.Long" > > Can you please explain why this happenes? Why it not consistent? > > I know the workaround to use Number class and longValue method but I want > to to the root cause before using this workaround > > Artur Rudenko > > > > This electronic message may contain proprietary and confidential > information of Verint Systems Inc., its affiliates and/or subsidiaries. The > information is intended to be for the use of the individual(s) or > entity(ies) named above. If you are not the intended recipient (or > authorized to receive this e-mail for the intended recipient), you may not > use, copy, disclose or distribute to anyone this message or any information > contained in this message. If you have received this electronic message in > error, please notify us by replying to this e-mail. > -- Sincerely yours Mikhail Khludnev
Solr fact response strange behaviour
I'm trying to parse facet response, but sometimes the count returns as Long type and sometimes as Integer type(on different environments), The error is: "java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long" Can you please explain why this happenes? Why it not consistent? I know the workaround to use Number class and longValue method but I want to to the root cause before using this workaround Artur Rudenko This electronic message may contain proprietary and confidential information of Verint Systems Inc., its affiliates and/or subsidiaries. The information is intended to be for the use of the individual(s) or entity(ies) named above. If you are not the intended recipient (or authorized to receive this e-mail for the intended recipient), you may not use, copy, disclose or distribute to anyone this message or any information contained in this message. If you have received this electronic message in error, please notify us by replying to this e-mail.
