Heavy multi-threading and proxy clients

(estebanp) #1


Delphi Tokyo, VS2018, RODA Using Olympia over SuperTCP channel. (Indy Delphi)

The situation is as follows, we have heavy multi-threaded services that use other services.

We have one service that authenticates an app (windows service) and passes a session id that will be use by the other services to make sure they are considered valid sessions.

Due to threading safety issues we are now creating all proxy generated clients dynamically. The only item we used to consider as a singleton was a connection object which will include a TransportChannel and a Message for each service and this object will be injected to the dynamically (Service Builder) created proxies.

After conversations on this forum it seems that the only thread safe item on all platforms will be the TransportChannel (which makes sense, we want to keep only one connection open per service) and the message now has to be generated per proxy client.

This takes me to the entire ClientID thing. If the only item that will be consistently thread safe and marked as a singleton is the channel, it makes sense to use the ClientID stored in the channel as the id to identify the client session in Olympia.

So, after the creation process of the channel, I’m assigning a ClientID to the channel on its ClientID property and thats where I hit the first wall. The base class TROBaseSuperChannel has the property but it is protected, so I have to cast to the object class created based on the URI provided, thats fine for TROBaseSuperTCPChannel, but then if the object is a SuperHTTPChannel, the clientid is protected again.

Now in some locations of the code (Delphi) and in the future on .Net we are grabbing the ClientID from the Message and assigning it to the Channel, but because the Message is not thread safe and needs to be instantiated on each client proxy generation that will be changing.

So my thought was to set the clientid on the only thread safe item that can be shared among dynamically created proxies but then I can not edit that value on their base class and/or all their independent implementations.

Any idea on how to proceed? Is there a problem in normalizing the behavior of the ClientId property on the transport classes?

Thank you.


(estebanp) #2

We also use TROLocalChannel when the service uses itself internally. TROLocalChannel offers the ClientID property as a read/write option just like TROBaseSuperTCPChannel.

Talked too soon, the documentation says it does, but the implementation doesnt have it.


Ok, now im lost.


(EvgenyK) #3

for TROBaseSuperHTTPChannel, you can use SessionID property. this is the same as ClientID in TROBaseSuperTCPChannel. for backward compatibility, it wasn’t changed but for v10 we can deprecate SessionID and introduce ClientID.

Documentation was updated for 9.6 RTM.
you are using 9.4 but ClientID was added into TROLocalChannel in 9.6.
See more at https://talk.remobjects.com/t/remoting-sdk-for-delphi-vnext-new-features/18354/2

1 Like