Hi,

Thanks for your inputs.

We tried attaching incrementing a counter, however the counter does not
remain in sync becasue of the special queryInterface/release methods which
is either called exclusively on client side or server side.

We are thinking on the following steps.
1. IIntroduce our own IPC(like shared memory). The client will write to the
shared memeory(a unique i)d and server will read through the same shared
memeory. However, we can see that this solution might cause problem in multi
processes scenario and complex syncronization will be requried
2. We are investigating on introducing an extra variable(which stores unique
id) in the class Marshall and UnMarshall. Let us know if anyone has an idea
whether this approach is feasible? Or is there any other way to send an
unique id through URP bridge itself?

Thanks,
Sudeep K

On Wed, Dec 15, 2010 at 3:55 PM, Stephan Bergmann <
stephan.bergm...@oracle.com> wrote:

> On 12/15/10 10:15, Sudeep Krishnadasan wrote:
>
>> Does the current implementation of uno urp maintain unique identifier
>> for each method calls?
>> If no then, could you please share your ideas on, How to maintain
>> unique id for each method calls processed through uno urp bridge and
>> log the same on client as well as server side?
>>
>
> First of all, note that <
> http://qa.openoffice.org/issues/show_bug.cgi?id=116038> will completely
> change the code of the URP implementation.
>
> The URP implementation does not assign unique IDs to calls.  However, if
> you want to attach an incrementing counter to the calls, you obviously need
> to do so consistently (e.g., attaching it to the special queryInterface
> calls on either both ends or on none).  See <
> http://wiki.services.openoffice.org/wiki/Uno/Remote/Specifications/Uno_Remote_Protocol#Special_Messages>
> for all the special calls involved in URP.
>
> -Stephan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
> For additional commands, e-mail: dev-h...@openoffice.org
>
>

Reply via email to