Hi Daniel,
The assumptions look to be reasonable.
Generally any operation that affects UI ( even if it is invisible )
might have problem while running in a thread different from the office
main thread. Thus for example in case of XCloseable.close() call, it
depends from the objects that implements the interface. If the method
affects UI ( a frame, or a model that has a frame ) it might need the
workaround depending from circumstances.
Best regards,
Mikhail.
On 02/25/09 17:18, Daniel Brosseau wrote:
Hi Mikhail,
I make many calls to Office and I am wondering if they all need to be
called from the Xcallback.notify() method.
N - No
Y - Yes
O - Optional for logging
? - Don't know
These are my best quesses
Method Needs Needs Listener
Callback Listener
XComponentLoader from Desktop
.loadComponentFromUrl Y N doc.XEventListener
?? OnLoadFinished
?? OnLoadDone
XDesktop.terminate Y O XTerminateListener
XComponentLoader from Frame
.loadComponentFromUrl Y N doc.XEventListener
?? OnLoadFinished
?? OnLoadClosed
XDocumentInsertable
.insertDocumentFromURL Y N doc.XEventListener
?? OnInsertDone
?? OnLoadDone
?? OnLoadFinished
XDocumentIndex.update Y ? ???
XRefreshable.refresh Y Y XRefreshListener
XPrintable.print (with Wait) Y N XPrintListener
XStorable.storeToURL Y Y doc.XEventListener
?? OnSaveDone
?? OnSaveAsDone
?? OnSaveFinished
XCloseable.close ? O lang.XEventListener
XComponent.dispose ? O lang.XEventListener
UnoRuntime.queryInterface N N
XComponent.addEventListener N N
XComponentContext.getServiceManager N N
XMultiComponentFactory
.createInstanceWithContext N N
XDesktop.addTerminateListener N N
XModel.getCurrentController N N
XController.getFrame N N
XTextDocument.getText N N
XText.createTextCursor N N
XModifiable.setModified N N
XDocumentIndexesSupplier
.getDocumentIndexes N N
XServiceInfo.supportsService N N
XRefreshable.addRefreshListener N N
XRefreshable.removeRefreshListener N N
XPrintable.setPrinter N N
XPrintJobBroadcaster
.addPrintJobListener N N
XPrintJobBroadcaster
.removePrintJobListener N N
Is this correct?
Thank you very much,
Daniel
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: February 25, 2009 2:56 AM
To: [email protected]
Subject: Re: [api-dev] Xstorable.storeToUrl locks soffice.bin
Hi Daniel,
Sorry, but this is not exactly what I mean.
First of all the main idea of the callback is to call the
office API method from it. Thus the OOoWaitCallback should call
XComponentLoader.loadComponentFromURL() and etc from notify()
call. To reach this, the information about kind of call and
about arguments should be provided in constructor in this case.
Just to explain the mechanics for better understanding. When
java application calls an UNO API method through a bridge, a
new thread is created on Office side and the method is
executed in this thread.
When the XRequestCallback.addCallback() is called it sends a
notification with arguments to the main office thread and
returns. After a while the main thread calls
XCallback::notify(), and if this method does a call to the
office back, the call is handled in the office main thread.
Second, I assume that it is not necessary in your
implementation to check the thread name. In the example I
have mentioned the thread name was used to mark the thread
that was called from office thread, and thus needed no
workaround. In your case it is not possible I assume, so I
would just remove the check and use the callback workaround always.
As for the listeners, I do not know details of
XDocumentIndex.update() implementation. But at least
XComponentLoader.loadComponentFromURL() and
XStorable.storeToURL() should be synchronous, and thus do not
really need any kind of listener usually.
Although there is a problem in case of
XComponent.loadComponentFromURL(). In case a html filter is
used to load a document, the filter does some actions
asynchronously. This is already recognized as a wrong
behavior, but I am not sure whether it was completely fixed.
Hope that helps.
Best regards,
Mikhail.
On 02/24/09 21:55, Daniel Brosseau wrote:
Hi again Mikhail,
This is what I did using the AsyncCallback:
I created a class on the model of the MainThreadDialogExecutor.java
you pointed me to:
public class OooWaitCallback implements XCallback {
private boolean m_bCalled = false;
static public boolean WaitOnOoo( XComponentContext xContext )
{
OooWaitCallback aExecutor = new OooWaitCallback();
return GetCallback( xContext, aExecutor );
}
static private boolean GetCallback
( XComponentContext xContext, OooWaitCallback aExecutor )
{
try
{
if ( aExecutor != null )
{
String aThreadName = null;
Thread aCurThread = Thread.currentThread();
if ( aCurThread != null )
aThreadName = aCurThread.getName();
if ( aThreadName != null && aThreadName.equals( "main" ) )
{
// the main thread should be accessed asynchronously
XMultiComponentFactory xFactory =
xContext.getServiceManager();
if ( xFactory == null )
throw new com.sun.star.uno.RuntimeException();
XRequestCallback xRequest =
(XRequestCallback)UnoRuntime.queryInterface(
XRequestCallback.class,
xFactory.createInstanceWithContext
( "com.sun.star.awt.AsyncCallback", xContext ) );
if ( xRequest != null )
{
xRequest.addCallback( aExecutor, Any.VOID );
do
{
Thread.yield();
}
while( !aExecutor.m_bCalled );
}
}
else
{
// handle it as a main thread
aExecutor.notify( Any.VOID );
}
}
}
catch( Exception e )
{
e.printStackTrace();
}
return true;
}
public void notify( Object aData )
{
m_bCalled = true;
}
};
Immediately after each call to openOffice.org in my main
program such
as
xCloseable.close() or xComponentLoader.loadFromUrl() or
xDocumentIndex.update() etc
I make a call to OooWaitCallback.WaitOnOoo().
I have now tested the program several times and where
before without
the WaitOnOoo calls it would consistently hang, it has not
hung once.
What I understand is happening is the callback request is
being placed
in the job queue that soffice.bin has been requested to
handle. This
callback request will be honored once soffice.bin has finished its
previous business as everything is happening synchronously.
Until soffice calls the callback, my main thread is yielding.
Does it make sens that as I have implemented it, this would resolve
the problem? Also, Because everything is happening synchronously, I
really should not need any listeners?
Regards,
Daniel
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: February 24, 2009 4:19 AM
To: [email protected]
Subject: Re: [api-dev] Xstorable.storeToUrl locks soffice.bin
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]
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
