[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jacorb-bugs
Subject:    [jacorb-bugs] [Bug 204] New: POA.deactivate_object() hangs
From:       bugzilla-daemon () inf ! fu-berlin ! de
Date:       2002-06-12 1:16:25
Message-ID: E17HwkL-0001hb-00 () berners
[Download RAW message or body]

http://www.jacorb.org/cgi-bin/bugzilla/show_bug.cgi?id=204

           Summary: POA.deactivate_object() hangs
           Product: JacORB
           Version: 1.4.0
          Platform: Sun
        OS/Version: SunOS
            Status: NEW
          Severity: normal
          Priority: P3
         Component: POA
        AssignedTo: tie@xtradyne.de
        ReportedBy: dmitri@airmail.net
         QAContact: jacorb-bugs@lists.spline.inf.fu-berlin.de


When the POA.deactivate_object(oid) is called within the context of invocation
where oid is the object id of the called servant, it never returns. This worked
in 1.4 betas. For example, in the following typical case:

interface MyInterface {
  ...
  void close();
}

and the servant code:

public void close() {
 ...
 byte[] oid = myPOA.servant_to_id(this);
 myPOA.deactivate_object(oid);
}

Here's what I've dug out so far:
In the org.jacorb.poa.POA.deactivate_object() code, a call to
RequestController.waitForDeactivationStart() was added since 1.4beta4. This
method appears to be waiting on oid (oid.wait()). But it also appears that the
code that is supposed to "oid.notify()" - in org.jacorb.poa.AOM.remove() - is
waiting in RequestController.waitForObjectCompletion() which will not return
until the active operation (MyInterface::close in the example above) completes.

Currently, the workaround is to call the deactivate_object in another thread.



------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

[prev in list] [next in list] [prev in thread] [next in thread]