That's great new Mridul.
Thanks for your work and performance memory test !
Nicolas
Le 12/09/2026 à 17:13, Mridul Pathak a écrit :
Hi all,
Quick follow-up: I tightened up the load test methodology (the first pass
was silently capped at 10k rows by an unrelated widget pagination limit
that applies to both screenxls and screenxlsx equally, now corrected) and
re-ran it with continuous memory sampling, comparing screenxlsx directly
against screenxls on the same dataset.
Results hold up well: screenxlsx is 4-11x faster than screenxls at every
row count I tested (10k up to 500k rows, and under 5 concurrent users), and
uses less peak memory at every tier - including at 500k rows, where
screenxls came within about 8% of a 1 GB heap ceiling while screenxlsx had
comfortable headroom. Full numbers are on the JIRA ticket (OFBIZ-13567).
This confirms screenxlsx handles the volumes screenxls was built for, so
I'll go ahead with deprecating screenxls as discussed.
Thanks again for flagging this - good to have it properly verified.
Regards,
Mridul Pathak
On Fri, Sep 11, 2026 at 7:05 PM Mridul Pathak<[email protected]>
wrote:
Hi Nicolas,
Following up on this — I ran load tests on the new screenxlsx
implementation to evaluate memory behavior at scale.
The new implementation is built on Apache POI's streaming extension,
SXSSFWorkbook (rather than the standard in-memory XSSFWorkbook). Because it
flushes rows beyond a small sliding window to temporary storage, it avoids
the heap exhaustion and OOMs traditionally associated with POI.
In testing up to 500k rows (and across concurrent sessions), heap
consumption remained virtually flat (< 30 MB delta), and 100k rows exported
cleanly in ~5 seconds.
I have posted the detailed benchmark results, memory profiling metrics,
and comparative analysis directly on the ticket:
https://issues.apache.org/jira/browse/OFBIZ-13567
Given these results confirm large-volume streaming is well-handled, we can
safely proceed with retiring the legacy screenxls implementation.
Regards,
Mridul Pathak
On Fri, Sep 11, 2026 at 3:28 PM Mridul Pathak<[email protected]>
wrote:
Hi Nicolas,
Thanks for providing the context regarding the screenxls implementation.
I'll load test the new POI based implementation and see if it can address
high volumes. If not, it definitely makes sense to keep the original
implementation intact.
Regards,
Mridul Pathak
On Fri, Sep 11, 2026 at 2:38 PM nicolas.malin.nereide.fr via dev <
[email protected]> wrote:
Hello,
Thanks for your work on this renderer. It's nice.
Just for the screenxls, it was created to support massive export for
than 100k lines. The reason that it use macro ftl to open continuous
string stream instead of load a java object like Apache POI did.
By the past, when I used Apache POI to did that, the lib failed with out
of memory due to huge memory consumption. If you implementation fix that
it's really good and we can set screenxls as deprecated, otherwise it
would be good to keep it and add a description on each case to use
screenxls and screenxlsx
Nicolas
Le 08/09/2026 à 15:04, Mridul Pathak a écrit :
Hi all,
I've opened two PRs adding a new screenxlsx view-handler type that
produces
genuine binary .xlsx workbooks via Apache POI:
https://github.com/apache/ofbiz-framework/pull/1899 for the core
mechanism,
andhttps://github.com/apache/ofbiz-plugins/pull/395 wiring it into the
example plugin's demo screens alongside a couple of new UI entry
points.
Both PRs are purely additive and don't touch any existing behavior,
tracked
as OFBIZ-13567.
The motivation is that the existing screenxls view-handler type doesn't
actually produce a real Excel file: its FreeMarker macros just emit a
plain
HTML table, and it only opens in Excel because Excel is lenient about
mismatched file extensions and content types, while tools like
LibreOffice
and Google Sheets are far less forgiving. The new screenxlsx handler
builds
a real OOXML workbook directly from the same widget form/grid data,
with
typed cells for currency and date fields, and has been verified
end-to-end
against a running instance producing files that open cleanly
everywhere.
This makes screenxls obsolete. If there are no objections, I'll file a
follow-up ticket to remove it once OFBIZ-13567 lands.
Reviews and feedback on the PRs are very welcome.
Thanks,
Mridul Pathak
