Thanks Stephan for your reply.
Overview - our system is for newspapers. We have a Java application
which rives OpenOffice. The ad taker uses our Java application, which
has multiple tabs. On one tab is OpenOffice, we size and move OpenOffice
so it stays within our window. The user enters the ad text in
OpenOffice. On the other tabs (Java panes) the user enters customer
info, billing, credit info etc. When the user first opens/creates an ad
we:
We add ourselves to XEventListener. We setup our own service to talk to OO and for OO to talk to the Java side. We get the following interfaces XTextDocument XMultiServiceFactory XTextFieldsSupplier XDrawPageSupplier XStyleFamiliesSupplier XPrintable XModifiable XStorable XRefreshable XNameAccess XWordCursor XParagraphCursor XViewCursor XLineCursor
We use these same interfaces during the session of the ad. We do a lot of getPropertySet and setPropertyValue. We make calls from Java into OO macros, we respond to events, and we save the document via an OO macro. This all works fine most of the time.
There seems to be cases (especially when the computer is busy) when we get the exceptions. Once we start getting the exceptions, we do not recover.
---
Regarding, "What requests are you sending exactly?"
For com.sun.star.lib.uno.protocols.urp.Unmarshal.readboolean - unexpected:java.io.EOFException We called XModifiable.isModified ()
For com.sun.star.io.IOException: java.net.SocketException: Socket closed
XPropertySet pagePropertySet =
getPropertySet(pageStyles.getByName("Standard"));
pagePropertySet.setPropertyValue("Width", pageWidth);
For java_remote_bridge
[EMAIL PROTECTED] is
disposed
We called XModifiable.isModified ()
Regarding, "Do you have an idea how many synchronous UNO requests from your local Java side are outstanding," no but there could be several.
Regarding, "...remote side of the bridge is closing the connection," this is very interesting. Why is it closing the connection? Is there a way to keep the connection open until we are finished?
The typical reason for either side to close the connection is when that side is asked to do something outside the URP specification; asked either by the other side of the connection, or by the client code. An OOo 1.1.x example would be Java client code that asks the URP bridge to send a
void f([in] string s);
UNO method request, but supplies a null Java string as argument.
However, that would not explain for example the EOFException during Unmarshal.readboolean above, which rather suggests that the internal state of either side of the URP bridge is hopelessly garbled. The question that remains is---how can that happen?
The OOo application is known to have problems when accessed by multiple threads simultaneously. But those problems manifest themselves in deadlocks or corrupted application data, not in a corrupted URP bridge (i.e., the URP bridge within OOo is itself thread-safe, modulo any yet unknown errors).
I have to confess I'm rather clueless at the moment, -Stephan
Bob
-----Original Message-----
From: Stephan Bergmann [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 16, 2005 11:39 PM
To: [email protected]
Subject: Re: [api-dev] How to protect from disposed exception?
Bob Crothers wrote:
Hi,
We have a multi-threaded Java environment. We are using OpenOffice.org
1.1.3. There are times when we make a series of UNO calls (mostly setting properties, save, and call macros) and also get a series of exceptions. The exceptions follow:
com.sun.star.lib.uno.protocols.urp.Unmarshal.readboolean - unexpected:java.io.EOFException
com.sun.star.io.IOException: java.net.SocketException: Socket closed
java_remote_bridge [EMAIL PROTECTED] is disposed
Hm, this means the remote side of the bridge is closing the connection while the local side of the bridge thinks it still has to read data. Do
you have an idea how many synchronous UNO requests from your local Java side are outstanding (have not yet received a reply from the remote OOo side) when the exception occurs---none, one (i.e., on a single Java thread), or multiple (i.e., on multiple Java threads simultaneously)? What requests are you sending exactly?
-Stephan
How can we defend against these exceptions?
Thanks
Bob Crothers
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
