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]
