Hi Mikhail, I put all my calls in an XCallback except for the startup connect upto getting the XDesktop and the final aurevoir XDesktop.terminate. It works, after some fussing about, and is about 30% quicker than the implementation I had before (uses more CPU cycles though).
A few side issues: 1 - the api documentation says thet the aData argument of the notify method is An Any but the java implementation of Xcallable.notify requires an Object. The addCallback method also takes an Object as second argument. However, I tried using an Object and this threw an exception so an Any is really what is required. The implementation of XCallable should probably reflect the documentation and be notify( Any aData ) rather than notify( Object aData )? 2 - the problem with a XComponentLoader.loadFromUrl not closing the previous model also seems to affect Xdesktop.terminate because if I just terminate without Closing the old Model there is a .~lock file that stays around whereas if I Close the xModel after the terminate the .~lock file is no longer there. 3 - I have noticed that when I do not Close the old model after a new loadFromUrl, the memory usage of soffice rises rather rapidly and even after my connection closes the memory usage does not go down. So, every time I run the application, the memory usage of soffice increases. For example, the first time I run the application, soffice will use 70 MB. After 5 runs of the application soffice uses 500 MB. If I Close the old Model after a new loadFromUrl then the memory usage of soffice does not rise as much, but it rises nontheless, going from 70 MB to 75 MB after 5 runs. I suspect that when there is a new loadFromUrl into an old Frame, more than the old Model needs to be cleaned up. I noticed for example that the new Model's Controller is different from the old Model's Controller (UnoRuntime.areSame) so the old Controller might not be deleted. But even when I Close the old Controller, memory still rises, again more slowly. So something else is hanging around. Thank you very much for your help, Daniel > -----Original Message----- > From: Daniel Brosseau [mailto:[email protected]] > Sent: February 25, 2009 11:19 AM > To: [email protected] > Subject: [api-dev] Do all calls into Office require the XCallback > > 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]
