#29378

Any decent Java developer knows that using thread-unsafe methods on an instance from multiple threads will lead to inconsistent behavior. In this case, it makes sense to instantiate a new instance, and I think developers know this already. It just comes with the territory of parallel programming.

However, why would you intentionally design the API around the parallel use case when the serial use case is just as valid and probably used just as often? For instance, if the developer wants to set up a PD4ML instance with the same options and footers and headers for a large batch of documents that they plan to render in serial, why would you have them instantiate a new PD4ML object and set these options every time? That’s unnecessary and time consuming.

I appreciate that you’re reviewing your API and making it consistent. I’m just requesting that the API be considered from several use cases. Not just the most complicated one.

#28898

I am also seeing this issue on pd4ml version 3.8.0fx3 pro
Seems to have to do with heavy amounts of CSS.

Unfortunately for me, the actual CSS is generally out of my control, so trimming it is not an option.

It is not a server issue. Please benchmark and see for yourselves.

Additionally: It seems to work very fast on a Windows Desktop, but is very noticeably slower on a multi-server Linux Machine. I’m using this through the provided jar, so this shouldn’t be an issue.

[Author]

Posts