Hi Daniel,
please see my comments inline.
On 02/26/09 06:16, Daniel Brosseau wrote:
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).
Yes, since the most office related operation happen in the main thread,
there are no unnecessary waitings I assume.
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 )?
According to the documentation the scenario you have mentioned should work.
http://wiki.services.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Java/Type_Mappings
Please check that the Object represents a type known by the office. The
bridge converts the object internally to Any type, but it is only
possible if there is corresponding office type for it.
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.
Yes, if a model is not closed it just dies with the process without
proper termination and file closing. The owner of the model ( in this
case the controller ) must close it. So the workaround is necessary
until the bug is fixed.
Could you please open a new bug for the controller problem and send it
to me ( [email protected] ).
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.
The problem with the model is clear, until it is closed it holds the memory.
As for the additional memory, as first I would suspect that the java
garbage collector does not free the dead references in time. In this
case the related objects on the office side stay alive until they are
released.
Hope that helps.
Best regards,
Mikhail.
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
