New Topic
CommunityTopicProblemChart Builder
Properties
Category Chart Builder
Product Version 7.4

Filter refresh error :: Custom query error on 'Cached Values' fliter

Ryan Navratil shared this problem 4 years ago
Resolved

When i attempt to refresh Cached Value filters, the report returns the error I'd typically associate with a custom query filter:


/3b1f24c0085bda7e2a868ebaf51b920a


All report filters are set to Cached Values:

/158d2b24987cec79ab3acb026e384828


I've tried to set an automatic filter refresh and actually created a custom query to try and address this, but nothing is working.


Currently all filters are blank and do not automatically refresh in the background. Thanks for your help in solving this problem

1 The same problem 0  

Replies (2)

photo
1
Ryan Navratil ● 4 years ago

If it's helpful, the filter refresh action is throwing an NPE error (below), but i do not know how to diagnose the root cause. We did not make any changes to the report or filters that i'm aware of. The issue is in the manual filter refresh 


YF:2020-11-05 06:28:14:ERROR (AjaxAction:processActionPerform) - Error caught: java.lang.NullPointerException
java.lang.NullPointerException
	at com.hof.mi.web.viewmodels.ReportLevelFilterDisplayViewModel.B(ReportLevelFilterDisplayViewModel.java:48)
	at com.hof.mi.web.viewmodels.ReportLevelFilterDisplayViewModel.<init>(ReportLevelFilterDisplayViewModel.java:35)
	at com.hof.mi.models.report.FilterFormatModelImpl.<init>(FilterFormatModelImpl.java:103)
	at com.hof.mi.data.ReportWrapperBean.createFilterFormatModel(ReportWrapperBean.java:7682)
	at com.hof.mi.web.action.FilterFormatAjaxAction.A(FilterFormatAjaxAction.java:318)
	at com.hof.mi.web.action.FilterFormatAjaxAction.runAction(FilterFormatAjaxAction.java:106)
	at com.hof.web.action.AjaxAction.execute(AjaxAction.java:155)
	at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:425)
	at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:229)
	at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913)
	at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:449)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:635)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
	at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
	at com.hof.servlet.BrowserHeaderFilter.doFilter(BrowserHeaderFilter.java:43)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:478)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:80)
	at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:624)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:342)
	at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:799)
	at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
	at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
	at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1455)
	at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
	at java.lang.Thread.run(Thread.java:748)

Reply
photo
1
Mike Sheehan ● 4 years ago

Hi Ryan,

Thanks for reaching out. The stack trace seems to indicate some sort of issue getting the filter ID from the View. Let's try simply pulling out the field you're trying to cache, then reinserting it into the report, then re-attempt caching.

If this doesn't work, can you please confirm this is the very first log entry for when you see the 'Oh no!...' error? It's important we have the very first trace. If this is definitely the first trace and removing and reinserting the field doesn't help, I'll have to dig further into the code to try and determine next steps, so please let me know.

Regards,

Mike

Reply
photo
1
Ryan Navratil ● 4 years ago

Thanks Mike- yes this is the first log entry.


I've tried removing all filters, adding them back one by one, and refreshing each time. Same result (takes between 3 and 5 min for the filter refresh to complete, then throws the same error).


This occurs whether or not the access filter is enabled.

The filters do not have parent/child relationships

Filters do not reference any field produced via subquery in the view


Anything else i can provide for context?


Thanks!

photo
1
Mike Sheehan ● 4 years ago

Hi Ryan,

If it's taking 3-5 mins before it completes and errors out, that sounds like Yellowfin is doing something during that time, and may ultimately be hitting a timeout. How many values are being cached here?

We can see which queries are executing behind the scenes via DEBUG logging. Can you please follow these steps to enable DEBUG logging, click to reattempt the cache, while taking note of timestamp for when the process started and when you see the 'Oh no!...' error, then subsequently supply said logs along with the two timestamps?

Also, please disable DEBUG after supplying this as they generate a lot of noise and generally aren't needed. I think it's possible all 10 log files will fill up assuming it's running queries the entire 3-5 minutes, meaning we may lose the initial click, so it may be good to save a single copy of the yellowfin.log from moments after clicking to start the cache as well. Then just supply the whole logs folder (whatever's there) after seeing the error in the UI.

Thanks,

Mike

photo
1
Ryan Navratil ● 4 years ago

Additional screenshots:


Location filter present and set to 'cached values':


/6b6c1a924f9132c0f2998c455e4e4c17


with the Location Filter removed:

/307951f963acdd0046d4ecebf23762c4

photo
1
Ryan Navratil ● 4 years ago

All other filters are set to Cached Values

photo
1
Mike Sheehan ● 4 years ago

Hi Ryan,

Thanks for the additional info. However, I'd still like DEBUG logs and to know how many values are expected to be returned.

Regards,

Mike

photo
1
Ryan Navratil ● 4 years ago

Will do Mike- It's not that many values, since we were able to run this report in the past without any trouble in the past. Also that log file i sent pretty strongly indicates an NPE that is causing the issue.


Across the entirety of the organization, these filters will return only 1-500 values.

photo
1
Mike Sheehan ● 4 years ago

Hi Ryan,

Thanks for clarifying that aspect! I look forward to the DEBUG logs.

Regards,

Mike

photo
1
Ryan Navratil ● 4 years ago

Thanks Mike- while my team is working on getting log files, is there something i should be investigating re: the Access filter on the view?

/a30a9cd1cec64dc110e767e0d54975ac


Each time i've gotten an error, it references the Access filter field, though i do not have any other parent/child filter relationships specified? thanks!

photo
1
Mike Sheehan ● 4 years ago

Hi Ryan,

The Access Filter settings are stored in the Admin Console > Data Sources > choose Data Source > Access Filters section. It looks like your report is referencing a CLIENTREFID Access Filter. One other recommendation I can make is, without caching the values, if you create a report with just this field in it does it work? If not, can you click to View SQL in the bottom right hand corner of the report builder and see if the SQL query executes directly in your RDBMS?

Regards,

Mike

photo
1
Mike Sheehan ● 4 years ago

Hi Ryan,

I just wanted to check in and see how things are going with this.

Regards,

Mike

photo
1
Mike Sheehan ● 3 years ago

Hi Ryan,

I'm going to go ahead and mark this one as Resolved since I haven't heard back from you, but if you have further questions or concerns on this, if you respond, it will re-open the case and put it back in my queue and I'll be happy to help.

Regards,

Mike

photo
Leave a Comment
 
Attach a file