Kay,
Thanks for answer.
In my case (OOo calls embedded in a servlet), System.exit() is obviously
not possible and System.gc() seems to not always work as expected.
So as a workaround, I do not use UnoUrlResolver anymore, and I have
access to the actual Bridge via the XConnector interface, which resolves
my problems, and is not as complicated as it seemed to be.
Maybe this workaround have to be explicitly put in the API doc ?
The doc tells that UnoUrlResolver doesn't give access to the bridge, but
doesn't tell that the Java developper can encounter problems with that :-)
Anyway, another thanks for your quick answer
C�dric
Kay Ramme - Sun Germany - Hamburg a �crit :
C�dric,
the "MessageDispatcher" lives as long as there are objects mapped,
that means Java objects being reachable from the remote side or remote
objects being referenced from the Java side. Unfortunately, this can
still be the case, even if you already cleared all references because
of a not invoked garbage collector / finalyzer.
If the remote side for example is Bin-UNO (e.g. the office), it may
help to call the garbage collector some times to free these references.
IMHO, there is no real alternative to this concept:
- Switching to a daemon thread for message dispatching would allow the
JVM to terminate in case the main thread dies. This is not wanted as
the JVM process needs to stay alive until all remote reachable objects
are released.
- Only other solution I see, is to introduce (explicit) object owner
ship, ensuring that every proxy becomes disposed/destructed after
usage. This is IMHO tedious, error prone and not programmable in real
life (and would mainly render Java-UNO being kind of a C like language).
- Only correct solution is to introduce a "reliable" GC/finalyzer for
Java, which probably will not happen in the near future.
- The only workarounds are, to fix 27216 and to kill remote
transparency in the client code, to call System.exit or to let the
process life until everything has been released (which unfortunately
does not necessarily work reliable, because the GC only becoming
invoked on increasing memory pressure, which is actually not happening
in an idle JVM).
Kay
C�dric Damioli wrote:
Hi udk guys,
I'm facing the issue numbered 27216 : i'm using the XUnoUrlResolver
through the Java bridge and, once i've called
XUnoUrlResolver.resolve(), the Thread named "MessageDispatcher"
appears and never ends, event at the end of application when the main
Thread exits. This causes the JVM to stay live, and this is if course
not wanted.
This MessageDispatcher Thread is actually a non-daemon thread
listening on a opened socket.
As the UnoUrlResolver does not give access to the Bridge, I cannot
directly close the connection.
Is there any known workaround ?
Thanks in advance for replies.
Best Regards,
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
C�dric Damioli
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
