Hi,
I have been busy lately adding support for UNO's current context concept (see <http://udk.openoffice.org/common/man/concept/uno_contexts.html#current_context>) to URP (on CWS sb23, not targeted for OOo 2.0, but probably OOo 2.0.1).
fine :-).
That this feature is currently missing has been noticed by the initiative to make OOo multi-thread safe when accessed via UNO.
This was a known limitation, wasn't it ?
Yes, just nobody else seemed to have any demand for it.
Now, to make a thread's current context available via URP: The only working scheme that I came up with is also the most primitive one---send the current context along with every URP request (i.e., every invocation of a UNO interface method;
Agreed, at least heavily thinking this through some years ago lead me to the same single solution.
the current context is not sent along with URP "release" requests).
This is needed (otherwise one would have an endless loop as every uno call now needs also a release call for the current context).
C++, one Java) from the testtools module on my local Linux box: (a) on a plain SRC680m88 (i.e., without support for current context); (b) on CWS sb23 (i.e., with support for current context), but using a null current context in the active thread; and (c) on CWS sb23 (i.e., with support for current context), and using a non-null current context instance in the active thread. (Also, I changed the bridgetest_xxx scripts to use TCP connections with tcpnodelay=1, see the Developer's Guide for details.)
What does happen, when you don't give this option ? In case, a current context is transported you probably get disastrous results (the additional release calls for the current context trigger this problem, bit I don't remember the exact circumstances anymore). As most people don't use tcpdelay right now, introducing this feature will create some noise, I think (depending on how much currenct contexts are use currently). One just needs to keep this in mind. It's a little sad, that the standard connection string needs to be extended by this option, but I don't see another solution here.
For the testtools/bridgetest measurements, tcpnodelay=0/1 actually made no difference. (The reason probably is that both the binary UNO and the Java URP bridge implementations try to avoid "asynchronous" data packets; I improved the behaviour of the Java URP bridge implementation in this regard on CWS sb23. The tcpnodelay=0/1 difference was noticable, however, with the new testtools/perftest tests, before I did those Java improvements.)
Also, the Nagle algorithm is there for a reason, so disabling it by default might be debatable.
Timings for three sample runs each are below, and indicate that the changes are tolerable (esp. if you consider that those brdigetest tests have an URP call density that is quite high, higher probably than that of the typical application). However, if you have any concerns about these changes, feel free to discuss them here.
No more other concerns, except that it needs to be said, that this change will be incompatible (meaning that a 2.0.0 Office won't be able to talk to 2.0.1 office), won't it ?
No, this is fully backward compatible. (There is a new URP protocol property CurrentContext that is automatically negotiated when connecting two bridge endpoints. I will update the URP specification in time before the changes on CWS sb23 hit the master.)
BTW, do you know whether PyUNO and the bridge between PyUNO and binary UNO already support the current context?
-Stephan
Bye,
Joerg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
