NOTE: This is a bit long-winded, and it definitely needs review by someone who understands this stuff better than me. Symptom - we deadlocked a server where object A had two synchronized methods (a1 and a2). A client made an A.a1() call, which called B.b1(), which in turn called A.a2(), which deadlocked. We expected the B.b1() call to occur in the same thread, since it was a local object call, but it did not, the stub was calling _invoke() because it thought !this._is_local(). The problem appears to be that when A got the object for B, B had been extracted from an Any, and the (new) delegate lost its association with the original poa. When the object is extract()'ed it goes thru its read(), which in turn goes thru the Helper.read(): return narrow(in.read_Object()); The 'in' is a org.omg.CORBA.portable.InputStream, implemented by org/jacorb/orb/CDRInputStream.java, whose read_Object() does a: return ((org.jacorb.orb.ORB)orb)._getObject( pior ); In the org/jacorb/orb/ORB.java class, the _getObject() method (towards the end) new's up a org.jacorb.orb.Delegate, calls configure() on it, and then calls d.getReference(null), which has the effect of never getting the poa set for the Delegate. So later, when delegate.is_really_local() is called, it has poa == null, so it calls resolvePOA() to find it's poa. The resolvePOA() doesn't find and set 'poa' either, because orb.findPOA() returns null if the refImplName doesn't match the implName (which defaults to "" if jacorb.implName is not set), but the refImplName from the object was "standardImplName". NOTE: I THINK(?) THE FOLLOWING IS A PROBLEM: However in POA.java, the implName will be set to "standardImplName" in the configure() if jacorb.implName is not set. This is wrong (??) and should default to "" like in org/jacorb/config/Configuration.java and org/jacorb/orb/ORB.java. So resolvePOA() gets back a null poa from orb.findPOA(), so it never sets 'poa', so is_really_local() returns false, when it should return true. If POA.java is modified to default jacorb.implName to "", then is_really_local () returns true like it should. Presumably, I could have avoided this problem by specifying -Djacorb.implName on the original server process(???) but I didn't think this was required - is it? Hope that makes sense.
I agree that this default looks iffy - I think that due to defaulting this to StandardImplName will mean that transient servers will never get serverId set (See getPOAId). If the server is persistent the implname property should be set to a unique value; possibly StandardImplName should only be an example not the default and checks should be made if its persistent and implname isn't set. Probably related to bug 473 and bug 378. For now, specify jacorb.implName to be a unique value.
*** This bug has been marked as a duplicate of 378 ***
This bug is not fixed in JacORB_2.2.4. In 2.2 the problem was the default used for 'implName' in POA.java and ORB.java. When patched to default implName to the same thing (eg "") then the Delegate.is_really_local() would work. However it was true that in 2.2 the 'serverId' in POA.java wasn't actually ever used, since 'implName' could never be null. The "fix" in 2.2.4 uses the POA serverId if jacorb.implname isn't specified, so that in POA.getImplName() the serverId is used if no implName is specified *OR* if !isPersistent() (both of which are true for my case). However the same fix was not made in ORB.java, so there the 'implName' member is still defaulted to "". This means that when the Delegate.is_really_local() is called and the poa has to be resolved, then orb.findPOA() is called, and it is going to return null because "refImplName" is some random number (dug out of the delegate object key) and 'implName' is "". This is going to make the Delegate.is_really_local() return false instead of true, which is wrong. This causes exactly the same deadlock described in the original bug report. It appears the 2.2.4 solution isn't taking non-persistent and non- "jacorb.implname" cases into account. This is a 2+ year old issue now - can a knowledgable person take a look at this? I think there are enough details for someone to go on, but I can try to provide more if neeeded. Thanks, Richard G. Hash
its fixed in the CVS (and in the next release). to be sure i've added another test: test/regression/src/org/jacorb/test/bugs/bug503/Bug503Test.java. please retest and close the ticket if appropiate
This bug does seem to be fixed (yeah!) in 2.3.0_beta2. Alphonse - Thanks a bunch