Hi Daniel,
First of all what do you name the main thread?
As I understood you use own java application that connects the office
using UNO API. The main thread of the java application does not
correspond to the main thread of the office process it connects ( at
least it was so before ).
As I have written in one of my previous answers, please try to use
"com.sun.star.awt.AsyncCallback" service to get a callback from the
office main thread. In this case you can use the callback to do your API
call in the office main thread.
The remaining lock file looks in this case like a result of non-closed
model. The model is the object that creates lock file on document
opening and closes it on closing. The office never waits for a document
lock file to continue, except the case of error/query message shown
during document opening/storing.
Anyway, the stack of the deadlock would be very interesting.
Best regards,
Mikhail.
On 02/24/09 07:05, Daniel Brosseau wrote:
Hi,
In everything done in one main thread with no GUI, my program loadsFromUrl
from the
Frame a first ODT file and then appends one or more ODT files to this
through a
XTextCursor and XDocumentInsertable. After all files are appended I do a
XRefreshable.refresh().
I then move to the beginning of the XTextDocument and insert a Table of
Contents, do
another XRefreshable.refresh() and a XDocumentIndex.update which I retreived
through
a XServiceInfo.
At this point I can do one of two things:
i) print the document through a XPrintable with a property "Wait" of true
and
for belts and suspenders a XPrintJobListener and XPrintJobBroadcaster
(I do not think I need this with "Wait")
Or ii) storeToUrl through a XStorable using the PDF filter
"writer_pdf_Export",
Asynchron of false and Overwrite true.
The program then loops back to the beginning and loadsFromUrl/Append/etc for
another
set of files ... (after the load I close the released Xmodel, but am I
leaking a
Controller which I should also close?)
If all I do is print, the the program can handle several sets of files
without a problem
but if I storeToUrl then soffice.bin will typically hang after 1 to 5
stores.
The specific set of loaded files that causes soffice.bin to hang varies from
run to run
but inevitably soffice.bin hangs. In the directory from which the files are
loaded, I see
Appear a file .~lock.fileName.ODT# where the fileName is the name of first
file of the set
that was loaded through loadFromUrl which corresponds to the XModel's URL
property.
Evidently, having soffice.bin hang is a problem. What I don't know is if
i) it is a threading issue relating to synchronization of the store, the
refresh or
the update
Or ii) their is a file lock taken out that soffice.bin is waiting to have
released before
continuing.
Really what I would like to know is how to avoid the hanging soffice.bin.
When soffice.bin
hangs, it just sits there consumming around 20% of the CPU with no change to
memory usage,
bytes read or anything else.
Any hints?
Thank you,
Daniel Brosseau
---------------------------------------------------------------------
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]
