[
https://issues.apache.org/jira/browse/AXIS2-3400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Poon updated AXIS2-3400:
------------------------------
Revision 606114 applied to InterfaceImplementationTemplate.xsl does *not* work
because the getUniqueSuffix() in the generated stub class was not defined as a
*static* method. Hence, synchronization was done against the stub instances
rather than the stub class - so duplicate suffixes (counter values) are being
generated.
Although the easy fix is to delare the method as static (as well as
synchronized), the solution is still fragile. We notice that Axis2 relies on
finalize() methods on its Stub and ServiceClient class (say) to call their
respective cleanUp methods. Since the timeliness of finalize methods being
called is not guaranteed, service names registered in the AxisConfiguration may
still be registered even after a Stub instance has been deferenced in the
application. So, in accordance with Revision 606114, the counter suffix could
rollover back to zero after 10,000 and it is conceivable that a duplicate
service name could be generated because a previous Stub with the same counter
suffix value hasn't been clean up yet.
In our tests, we have also found that both the IBM JVM on Windows XP and
Solaris JVM reuse hash codes for Object.hashCode() - that is, they can assign
the same hash code value to multiple live objects. So concatenating
Object.hashCode() to getUniqueSuffix() would also be a fragile solution.
We are now investigating another option - concatenating
Long.toString(System.currentTimeMillis()) to getUniqueSuffix() - where
getUniqueSuffix() would rollover the counter at 99,999 instead of 10,000. We
think that it would be safe to assume that an application would not create more
than 99,999 stubs for the same service within 1 millisecond (or in the case of
Windows, 10ms due to its resolution).
> AxisService name not unique enough
> ----------------------------------
>
> Key: AXIS2-3400
> URL: https://issues.apache.org/jira/browse/AXIS2-3400
> Project: Axis 2.0 (Axis2)
> Issue Type: Bug
> Components: kernel
> Affects Versions: 1.3
> Reporter: David Poon
> Priority: Blocker
>
> The generated (client) stub implementation's populateAxisService() method
> creates the AxisService name using Object.hashCode() as a means to "ensure"
> uniqueness, for example:
> //creating the Service with a unique name
> _service = new org.apache.axis2.description.AxisService("IsisLocation" +
> this.hashCode());
> In our performance and stress test runs, we find that from time to time,
> "duplicate name found" errors would occur. We reuse the same configuration
> context instance over multiple client service invocations. The javadoc of
> java.lang.Object.hashCode() states that:
> "... It is not required that if two objects are unequal according to the
> java.lang.Object.equals(java.lang.Object) method, then calling the hashCode
> method on each of the two objects must produce distinct integer results. ...
> As much as is reasonably practical, the hashCode method defined by class
> Object does return distinct integers for distinct objects. (This is typically
> implemented by converting the internal address of the object into an integer,
> but this implementation technique is not required by the JavaTM programming
> language.)"
> In essence uniqueness is not guaranteed.
> Even though the Stub's finalize() method calls its own cleanup() method
> (which would remove the AxisService name), it is still possible for a
> duplicate name being generated whilst the other Stub is still in use (by
> another thread).
> Perhaps in addition to using hashCode(), a static incrementing counter could
> be appended to the generated name as well?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
