Hi,
Stephan Bergmann wrote:
the Nagle algorithm is sensible for strict request/response protocols. It can have quite disastrous effects, when when you leave this pattern. (typically when one side writes on a socket and flushes it and afterwards it writes a second message. When the remote counterpart does not react on the first message (e.g. because it is a oneway call), the second message will reach the remote counterpart only after 100ms).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.)
I learned this from debugging a situation, where it lead to a 10 calls per second (compared to a 500 calls per secoond with this option) call frequency. This was a callback situation where a parameter was passed, that was not used. I'll try to recode this. I would have thought, that this situation may occur more often with a dummy parameter passed always, but let's wait for my example to discuss this.
Also, the Nagle algorithm is there for a reason, so disabling it by default might be debatable.IMHO the connection services should create a default socket, as they can be used independently of the urp bridge, so it doesn't make sense to optimize them for one application imho.
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.)
Ok, nice :-).
It seems, that I have overlooked this. How about other scripting languages (ole, basic) ? I can add very simple native runtime functions to pyuno to allow the access (wrappers arrount get/setCurrentContext() functions).
BTW, do you know whether PyUNO and the bridge between PyUNO and binary UNO already support the current context?
Could it be another option to add a CurrentContextHolder property to the component context ? The property would be an uno object with just one property (currentContext), which simply delegates to the C++ get/setCurrentContext() runtime functions. Such a functionality could be used by all scripting languages.
But errors in script code (not layering the context correctly) can easily generate very strange and difficult to debug side effects, so I am not 100% sure, that this a gread idea.
Bye,
Joerg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
