I realize I'm going to say something dumb, but bear with me. We have a large number of .cfr reports created with the aged and decayed CF Report Builder tool. (never time to pay down tech debt). Recently we started getting intermittent errors like this from various reports. We're not able to reproduce and only get a small number of these errors per day, but they're annoying, so I wanted to see if anyone had any ideas of what to try. type: Expression message: Report compilation error. detail: Error at line 4 char 162: net.sf.jasperreports.engine.xml.JasperDesignFactory near as I can tell, feeding the same data into the same report will not consistently reproduce the error. It's like a true little phantom, flitting around setting fire in a non-deterministic way.

My suggestons: • Make sure you're testing with the same data that's causing the errors. If you're not exactly sure what that is, start logging the input so you have it so you can re-create the error. • If the exact input is not triggering the problem, try throwing load at the request. Sometimes bugs are only triggered under load (could be unscoped variables leading to bugs, problems in the underlying Java libs, etc). I found sometimes a bug is only visible under load (but it is rare).

Thanks for the suggestions. I will add some logging to ensure we capture the exact data in the event of the error. So far we've just captured some db record ids and fed what we believed was the data it would've passed to the report based on those, but nabbing the actual data going in can help rule out that if we can feed it back in and see it not error.

Does re-running the report usually work? Or do you need to restart the server or CF? We get "malformed report" errors intermittently, which usually go away if we just re-run it. So I created a wrapper function for the cfreport tag that automatically re-runs it.

@*mithlond Over the past few years, others have reported this problem you raise and that they have solved it by removing CF's "presentation" package (as that and the report package for cfreport seem to have some conflict). If you show that presentation package being installed on the CF Admin "package manager" list of installed packages, try removing it. It supported the cfpresentation tag, which virtually no one uses.* If that doesn't work, let us know. In that case, let us know what specific CF version and update you are on. See the "settings summary" page in the CF Admin. There was a hotfix in the 2021-2023 timeframe that also helped, but it should be included in more recent updates (cf2021 u11 and cf2023 u5, both from Oct 2023).

@carehart thanks for the info and for following up. I just barely saw your responses. I will pass that along to our ops/admin people and see if we can try that 👍

Ok, though if I can offer a tip that may help you or others: it sounds like your only way to test things is in some central environment that someone else controls (whether prod or test or central dev). When you're dealing with challenges like this, it can sure be helpful to have a local dev setup also. Even without "running all the code", you can find with a small demo that sometimes a thing acts differently between the two environments, or they're the same but you can more safely test a solution--without waiting for anyone. :-) I only clarify this because some people don't realize you can install CF locally for free, as the free developer edition (with no expiration). Or of course, one can use Commandbox also (and start a CF engine), also free.

We are doing our primary development with commandbox/docker locally - just that whenever we try to repro the report bug locally it never errors. It's a tiny fraction of the reports being run on prod that run into the error, so I'm not too surprised though. Most of the time it Just Works ™️

OK on that. And you may mean that a given cfr sometimes works and sometimes does not, or you may mean that one always works while another never does. Each are useful clues. Assuming it's the former (which is what it sounds like), you may need to go further, and "clear the cfclasses folder" and "clear the felix-cache". As you may already understand that, I won't bother to elaborate. Adobe has mentioned it in various resources they've written, in helping folks with problems like this. I would do that AFTER removing the presentation package, and while CF was down.

Ah, that's good info to have also. I will mention that to our ops people as well. As for reproducibility, yes, it kind of wanders all over our many .cfr reports. A given one will run just fine dozens or hundreds of times during a day and only error once or twice. My understanding right now is that when we log an error we capture the user's id and try running it w/ what we believe is the exact data that would've been passed to the report and can't get it to break. I think on production they can even re-run the report for someone it failed on, and it works there the 2nd time.

I appreciate how challenging that makes it to recreate locally. In that case, let's see what they may find/report.

Sure thing. Concurrency issues that only seem to happen under high load are a bear to diagnose and test fixes for on a lowly developer laptop w/ 1 user 😄 Someday I hope we add load/stress testing to our toolbox.

Understood, but it's possible this is not so much a concurrency or load-based issue. That's why I proposed at least trying locally. But I get that it's hard to recreate, for whatever reason. And either way, sure, being setup for load/stress testing is a great idea.

Yeah - just mostly leaning that way myself. I'm not positive it's concurrency/load related. I'm pretty sure we're not using cfpresentation, so hopefully amputating that CF package will do the trick.

@mithlond - I am conducting a user study for building a business case for report builder revamp. Could you please take a few minutes to take the survey - https://forms.office.com/r/Qe8z2ADadX

Survey filled out :)