What about opening a ticket and attaching the XMP in question
BR
Maruan
> Am 07.09.2022 um 23:19 schrieb Tim Allison <talli...@apache.org>:
>
> All,
> This issue is ringing a bell. I'm sorry if there's an open issue or
> you/we've decided long ago that this is not an issue.
> One of the timeouts in the most recent run was caused by Jempbox's
> handling of the history in the media management schema. There are 32000
> elements in the history. :(
> On the Tika side, we limit history elements to 1024. However, Jempbox
> still has to load the full list, and on this xmp, it takes a long, long
> time (I was never patient enough to let it finish).
> If I do enough subclassing and limit getEventSequenceList to 1024, all
> is good. [0]
> Is it worth spending time to fix the underlying performance issue in
> Jempboxx, or is this type of hack on the Tika side the best option?
>
> Best,
>
> Tim
>
> [0] int length = items.getLength();
> length = 1024;
> for(int i = 0; i < length; ++i) {
>
> Element li = (Element)items.item(i);
> retval.add(new ResourceEvent(li));
> }
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org
For additional commands, e-mail: dev-h...@pdfbox.apache.org
