Archived

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

glacier2 bug

Andrew
Andrew
in Bug Reports
I found a bug on glacier:

environment:
adapter1: id reciver-1 (with object test/00001)

adapter2: id reciver-2

glacier2 (configured with default Session Manager)

Client connected by Glacier2

if the client create a proxy by a string an then ping, it go right, then if I create a proxy with the same ice id but different adapter it go right too, but it will fail, it's true?

ex 
proxyStr = "test/00001 -t @ reciverService-1"
proxyFake = "test/00001 -t @ reciverService-2"

self.__router Glacier2.RouterPrx.checkedCast(self.communicator().getDefaultRouter())
self.__router.createSession("test", "test")

try:
      proxy = self.communicator().stringToProxy(proxyStr)
      print "ice_ping",proxy
      proxy.ice_ping()
except Exception as ex:
      print ex

try:
      proxy2 = self.communicator().stringToProxy(proxyFake)
      print "ice_ping",proxy2
      proxy2.ice_ping()
except Exception as ex:
      print ex

then if I close/open the session and try to ping the fake proxy the clinet go to loop

I attach an example

Comments

  • bernard
    bernard Jupiter, FL
    Hi Andrea,

    With Ice, each object ID is supposed to be unique (within the scope of a given application/deployment). You can't / shouldn't have two separate objects with the same ID, and if you do, sometimes your application may work, sometimes you will get unexpected and hard-to-figure out results.

    Within a Glacier2 session, you are actually assigning a proxy to an object ID the first time you make a call on a given object. So the expected behavior with your little test is: 
       proxy = self.communicator().stringToProxy(proxyStr)
   proxy.ice_ping()
    The Glacier2 router forwards this ice_ping to the test/00001 object, and to do so Glacier2 resolves the provided adapter-ID using its configured Ice locator.
       proxy2 = self.communicator().stringToProxy(proxyFake)
   proxy2.ice_ping()
    The Glacier2 router forwards this ice_ping to the same (first) test/00001 object, because the previous called associated a proxy to this object ID.

    Then, if you want to test session closing and reestablishment, please upgrade to Ice 3.4.1; Ice 3.4.1 incorporates a number of bug fixes and enhancements in this area.

    All the best,
    Bernard
  • Andrew
    Andrew
    bernard wrote: »
    Hi Andrea,

    With Ice, each object ID is supposed to be unique (within the scope of a given application/deployment). You can't / shouldn't have two separate objects with the same ID, and if you do, sometimes your application may work, sometimes you will get unexpected and hard-to-figure out results.

    Within a Glacier2 session, you are actually assigning a proxy to an object ID the first time you make a call on a given object. So the expected behavior with your little test is: 
       proxy = self.communicator().stringToProxy(proxyStr)
   proxy.ice_ping()
    The Glacier2 router forwards this ice_ping to the test/00001 object, and to do so Glacier2 resolves the provided adapter-ID using its configured Ice locator.
       proxy2 = self.communicator().stringToProxy(proxyFake)
   proxy2.ice_ping()
    The Glacier2 router forwards this ice_ping to the same (first) test/00001 object, because the previous called associated a proxy to this object ID.

    Then, if you want to test session closing and reestablishment, please upgrade to Ice 3.4.1; Ice 3.4.1 incorporates a number of bug fixes and enhancements in this area.

    All the best,
    Bernard

    the same test without glacer don't have the same behaviour, I test that application with Ice 3.4.1.
  • paolo
    paolo
    In Andrew application he is not assigning one Object Identity to 2 different objects, he just ask create 2 stringified proxy:

    "test/00001 -t @ reciverService-1"
    and
    "test/00001 -t @ reciverService-2"

    The first one is the correct one cause test/00001 Object is registered on reciverService-1 Adapter.

    The problem is that if he is behind glacier2 and try to resolve the first stringified proxy and after the second one, both Proxy can reach the object, if he try in reverse order both Proxy can't reach the object.

    The expected behaviour would be in both case to be able to reach the object always through the first Proxy("test/00001 -t @ reciverService-1" ) and never through the second one ("test/00001 -t @ reciverService-2" )
  • bernard
    bernard Jupiter, FL
    Which behavior is expected depends on your perspective.

    My perspective is the Ice routing facility on which Glacier2 is built.

    As I mentioned earlier, the Glacier2 router maintains a table object ID to proxy (for each session), with the help of the Ice client runtime. When you first call an operation on a "routed proxy", the Ice client runtime first registers this proxy with the router's table, and then sends the request to the router, which in turns forwards it to the actual target (using the provided proxy).

    The size of this per-session table is Glacier2.RoutingTable.MaxSize, set to 1,000 by default. So, with your first example, you could do:
    - invoke on good routed proxy (success)
    - invoke on 1,000 other routed proxies
    - invoke on fake proxy (fails, since the good routed proxy is no longer cached in the Glacier routing table).

    Your second example shows that the Glacier2 router keeps your bad proxy, even after a request on this bad proxy returns an exception. This behavior is currently not documented, and I agree that it should be. One related question is if/when the Glacier2 router should drop a proxy that returned an exception: for any system exception, or just a few exceptions like ObjectNotExistException or ConnectionRefused?

    I see that your own expectation is that Glacier2 is totally transparent to the application--that everything behaves like with direct client-server communications, but that's quite true:
    paolo wrote: »

    The expected behaviour would be in both case to be able to reach the object always through the first Proxy("test/00001 -t @ reciverService-1" ) and never through the second one ("test/00001 -t @ reciverService-2" )

    I hope this is clearer now.

    Naturally, the larger question is what are you trying to achieve here? An application should definitely never use a pair of proxies like "test/00001 -t @ reciverService-1" and "test/00001 -t @ reciverService-2"; if this object is replicated on several servers, you should use a single proxy like "test/00001 @ replicatedService".

    Best regards,
    Bernard
  • Andrew
    Andrew
    Andrew wrote: »
    I found a bug on glacier:

    environment:
    adapter1: id reciver-1 (with object test/00001)

    adapter2: id reciver-2

    glacier2 (configured with default Session Manager)

    Client connected by Glacier2

    if the client create a proxy by a string an then ping, it go right, then if I create a proxy with the same ice id but different adapter it go right too, but it will fail, it's true?

    ex 
    proxyStr = "test/00001 -t @ reciverService-1"
proxyFake = "test/00001 -t @ reciverService-2"

self.__router Glacier2.RouterPrx.checkedCast(self.communicator().getDefaultRouter())
self.__router.createSession("test", "test")

try:
      proxy = self.communicator().stringToProxy(proxyStr)
      print "ice_ping",proxy
      proxy.ice_ping()
except Exception as ex:
      print ex

try:
      proxy2 = self.communicator().stringToProxy(proxyFake)
      print "ice_ping",proxy2
      proxy2.ice_ping()
except Exception as ex:
      print ex

then if I close/open the session and try to ping the fake proxy the clinet go to loop

    I attach an example

    The example is only to reproduce and explain the kind of issue, nothing more. (I don't try to archive something)
  • bernard
    bernard Jupiter, FL
    Hi Andrea,

    We looked at your test-case, and it does indeed show a bug: when you reuse a proxy after closing/reopening a session, an invocation on this proxy blocks forever. We'll investigate.

    This bug also appears unrelated to the behavior of Ice+Glacier2 when using two proxies with the same object-id, which is in fact expected, as I described earlier in this thread.

    Thank you for this bug report.

    Bernard

Categories