Archived

This forum has been archived. Please start a new discussion on GitHub.

Multiple incoming connections on same proxy

Hi,


I wonder what happens if the following situation occurs:
* at the server i create a proxy
* I send it to a (icephp) client
* this client saves it somewhere (for example in $_SESSION) with ice_proxyToString()
* ANOTHER client starts operating simultaneously on the proxy returned from ice_stringToProxy();


Please correct my thinkings if they are wrong:
* every proxy points to exactly 1 handle, multiple proxies can point to the same handler
* every connection is handled by a seperate thread (up to Ice.ThreadPool), if no thread is available: Ice::ConnectionRefusedException
* no 'sequentialling' is done for accessing functions (what I mean is if i have 2 threads accessing the same proxy, the same function, it COULD cause problems if I don't put my own Mutex in there to sequentialize access to the functions).


Could someone tell me if those observations are correct or not?


Thanks,

Comments

  • bernard
    bernard Jupiter, FL
    Hi Steven,
    g00fy wrote:
    Please correct my thinkings if they are wrong:
    * every proxy points to exactly 1 handle, multiple proxies can point to the same handler

    The proxy is really a handle to a remote object. This object may be replicated (instantiated by several servers), but in any case, a proxy is a handle to just one object in the Ice object model.

    Several proxies (handles) can point to the same object.
    * every connection is handled by a seperate thread (up to Ice.ThreadPool), if no thread is available: Ice::ConnectionRefusedException

    If you use the thread-per-connection model, yes, every connection is handled by a separate thread. In this case, there is no thread pool and no limit on the number of threads (other than OS/memory etc. limits).

    If you use the thread-pool model (the default), and you try to establish a connection while all the threads in the server thread pool (or object adapter thread pool) are busy serving requests from other clients, the connection establishment will block, and will eventually timeout with a timeout exception if you've set a timeout and no thread becomes available within this timeout. Threads are not tied to connections with this model.

    You get a ConnectionRefusedException when your server's object adapter is not activated (or your proxy's endpoint refers to a bogus port).
    * no 'sequentialling' is done for accessing functions (what I mean is if i have 2 threads accessing the same proxy, the same function, it COULD cause problems if I don't put my own Mutex in there to sequentialize access to the functions).

    No, you don't need to serialize access to a proxy. The Ice runtime in general, and proxies in particular, are thread-safe.

    Best regards,
    Bernard
  • Thanks for the extended answer Bernard!
    I really start to like ICE! Simple and powerfull!
    bernard wrote:
    No, you don't need to serialize access to a proxy. The Ice runtime in general, and proxies in particular, are thread-safe.

    So to be entirely sure... If I have multiple proxies, pointing towards the same handler (ice object) on the server, and I execute via the proxy a function which runs like 1 hour (other proxies start the same function in the run of this hour). What I understand then from your answer is that the function will run thread-safe?
    But what is 'thread-safe'? If I have a variable in this ICE-object, which is accessed by this function, should I serialize access? Probably yes, because it's the same object, but then it's not my interpretation of 'thread-safe'...


    Greetings,
  • marc
    marc Florida
    Proxies are thread safe, meaning that you can have multiple threads using the same proxy without any thread synchronization. However, this has nothing to do with your servant (which implements your Ice object). If you have more than one invocation on an Ice object at the same time, then you must either serialize access to your Ice object, or make your servant thread safe. You can serialize access to your Ice object by using the thread pool model with only one thread (which is the default setting). Otherwise, you must implement your servant in a thread-safe manner, such as mutex-protecting the servant's state.
  • Thanks for confirming what my intuition told me :D!


    Greetings,