Hi Martin,
just two points:
- If the hanging finalizer really is the problem, than one dedicated
thread for releasing/finalizing mapped UNO objects should do the trick,
no thread pool needed. The Java finalizer just needs to pass these
objects to the releaser thread.
- How does you ensure that your thread pool threads finalize the
objects? AFAIK there is no way to explicitly dispose mapped UNO objects.
Kay
Martin Gallwey wrote:
The java uno bridge need to create also a fresh thread for each
release (or at least for each concurrent release). It can't be a
single thread doing the releases, because this would end in the same
problem.
Because the JVM finalizer garbage collects many many objects at a time
(in the scenario where I ran into this bug, the high water mark was >
10000), it is not possible to create a thread per release. What I did
instead was turn on '-Xincgc' for incremental garbage collection, and
implement a thread pool of ten threads to share out the releasing of the
objects.
I will create a child workspace for this issue. In the mean time, I
created an issue (i#57753#) with the patches attached to it. With the
attached patches, my java filter batch job ran perfectly for 8000
documents, whereas without the patches it used to crash after 20 or so.
I'll create a reduced test case to demonstrate the crash. It seems the
'access violation exception' was a result of the
java.lang.OutOfMemoryError as with the patches applied, I get neither
error.
Have a good weekend, everyone!
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
