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

Ryan Navratil shared this problem 20 days ago
Awaiting Reply

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

Comments (2)

photo
1

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)

photo
1

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

photo
1

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

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

Additional screenshots:


Location filter present and set to 'cached values':


/6b6c1a924f9132c0f2998c455e4e4c17


with the Location Filter removed:

/307951f963acdd0046d4ecebf23762c4

photo
1

All other filters are set to Cached Values

photo
1

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

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

Hi Ryan,

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

Regards,

Mike

photo
1

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

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

Hi Ryan,

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

Regards,

Mike

photo