Loading ...
Sorry, an error occurred while loading the content.

objects_by_reference garbage collection

Expand Messages
  • Steve Fink
    I am wondering why the objects_by_reference mechanism uses time-based garbage collection for references. Unless a SOAP client also doubles as a server for its
    Message 1 of 3 , Jul 8, 2003
    • 0 Attachment
      I am wondering why the objects_by_reference mechanism uses time-based
      garbage collection for references. Unless a SOAP client also doubles
      as a server for its SOAP server, it seems to me that no server-side
      objects will ever have pointers to client-side objects, so it ought to
      be possible for the client side to inform the server exactly when it
      no longer needs an object. Or am I misunderstanding what is happening?

      I am imagining that all client-side proxy objects' DESTROY methods
      would immediately send a 'refcount_dec' over the SOAP link to tell the
      server to discard the object reference from its cache. This might be
      too expensive, but perhaps the DESTROYs could be enqueued and sent
      with the next connection?

      Or perhaps I should ask about what really concerns me: it seems to me
      that with the existing mechanism (as I understand it), it would be
      possible for a server-side object to be discarded while a client-side
      proxy object was still in use. If so, the next time that proxy object
      was accessed, the server would have no record of it and the
      application would fail. Am I misunderstanding what is happening? I
      admit that I am relying on the documentation, since the necessary
      brain cells dissolved and ran out my ear while I was trying to figure
      out the line

      while (@_) { @alive{shift()} = ref $_[0] ? shift : sub { $_[1]-$_[$_[5] ? 5 : 4] > 600 } }
    • Steve Fink
      I am wondering why the objects_by_reference mechanism uses time-based garbage collection for references. Unless a SOAP client also doubles as a server for its
      Message 2 of 3 , Jul 8, 2003
      • 0 Attachment
        I am wondering why the objects_by_reference mechanism uses time-based
        garbage collection for references. Unless a SOAP client also doubles
        as a server for its SOAP server, it seems to me that no server-side
        objects will ever have pointers to client-side objects, so it ought to
        be possible for the client side to inform the server exactly when it
        no longer needs an object. Or am I misunderstanding what is happening?

        I am imagining that all client-side proxy objects' DESTROY methods
        would immediately send a 'refcount_dec' over the SOAP link to tell the
        server to discard the object reference from its cache. This might be
        too expensive, but perhaps the DESTROYs could be enqueued and sent
        with the next connection?

        Or perhaps I should ask about what really concerns me: it seems to me
        that with the existing mechanism (as I understand it), it would be
        possible for a server-side object to be discarded while a client-side
        proxy object was still in use. If so, the next time that proxy object
        was accessed, the server would have no record of it and the
        application would fail. Am I misunderstanding what is happening? I
        admit that I am relying on the documentation, since the necessary
        brain cells dissolved and ran out my ear while I was trying to figure
        out the line

        while (@_) { @alive{shift()} = ref $_[0] ? shift : sub { $_[1]-$_[$_[5] ? 5 : 4] > 600 } }
      • fhew@canada.com
        ... No, thats my interpretation too. I ended up adding my own garbage collector routine to replace the time based default routine. Thats why/how I discovered
        Message 3 of 3 , Jul 16, 2003
        • 0 Attachment
          On Tue, 8 Jul 2003 15:06:00 -0700, Steve Fink wrote:

          >
          > I am wondering why the objects_by_reference mechanism uses time-based
          > garbage collection for references. Unless a SOAP client also doubles
          > as a server for its SOAP server, it seems to me that no server-side
          > objects will ever have pointers to client-side objects, so it ought to
          > be possible for the client side to inform the server exactly when it
          > no longer needs an object. Or am I misunderstanding what is happening?

          No, thats my interpretation too.

          I ended up adding my own garbage collector routine to replace the time based
          default routine. Thats why/how I discovered the bug mentioned below.

          > I am imagining that all client-side proxy objects' DESTROY methods
          > would immediately send a 'refcount_dec' over the SOAP link to tell the
          > server to discard the object reference from its cache. This might be
          > too expensive, but perhaps the DESTROYs could be enqueued and sent
          > with the next connection?

          Yup. I added a stooith() routine. (a take off on the 'high availability'
          kernel software for stonith() 'shoot the other node in the head')
          Mine is 'shoot the other object...')

          > Or perhaps I should ask about what really concerns me: it seems to me
          > that with the existing mechanism (as I understand it), it would be
          > possible for a server-side object to be discarded while a client-side
          > proxy object was still in use. If so, the next time that proxy object
          > was accessed, the server would have no record of it and the
          > application would fail. Am I misunderstanding what is happening?

          No, that appears to be exactly what is happenning.

          > I admit that I am relying on the documentation, since the necessary
          > brain cells dissolved and ran out my ear while I was trying to figure
          > out the line
          >
          > while (@_) { @alive{shift()} = ref $_[0] ? shift : sub { $_[1]-$_[$_[5] ? 5 :
          > 4] > 600 } }

          It took me a while to figure it out. Especially since it has a race
          condition. I sware I submitted a fix/patch for it in Feb,
          but it never got into the subsequent 'latest' release since then.
          Here is the fix.

          while (@_) {
          my $key = shift;
          @alive{$key} = ref $_[0] ? shift : sub { $_[1]-$_[$_[5] ? 5 : 4] > 600 } }
          }


          The original line assumed that the left hand side of the equals is evaluated
          before the right hand side, and hence assuming the order of the 'shift's that
          are happening. Most of the time (perl implementation specific) evaluates
          the shift on the right hand side first... messing up the code. Extracting
          it explicitly... first... solves that bug.
        Your message has been successfully submitted and would be delivered to recipients shortly.