You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by "David Poon (JIRA)" <ji...@apache.org> on 2007/12/12 07:13:43 UTC
[jira] Created: (AXIS2-3400) AxisService name not unique enough
AxisService name not unique enough
----------------------------------
Key: AXIS2-3400
URL: https://issues.apache.org/jira/browse/AXIS2-3400
Project: Axis 2.0 (Axis2)
Issue Type: Improvement
Components: kernel
Affects Versions: 1.3
Reporter: David Poon
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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Updated: (AXIS2-3400) AxisService name not unique enough
Posted by "David Poon (JIRA)" <ji...@apache.org>.
[ 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Resolved: (AXIS2-3400) AxisService name not unique enough
Posted by "Amila Chinthaka Suriarachchi (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Amila Chinthaka Suriarachchi resolved AXIS2-3400.
-------------------------------------------------
Resolution: Fixed
fixed the issue. added a static counter to generate unique service names
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Reopened: (AXIS2-3400) AxisService name not unique enough
Posted by "David Poon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Poon reopened AXIS2-3400:
-------------------------------
We applied the revision 606114 to InterfaceImplementationTemplate.xsl and inserted the revised xsl into axis2-codegen-1.3.jar and axis2-1.3.jar. We regenerated our stubs with the revised jars; and repeated our performance and stress tests.
The change made by revision 606114 actually made the problem *worse* - we encountered more occurrences of the "duplicate name error". To recheck, we reverted the change (ie gone back to Object.hashCode) and ran the tests again, the occurrences of the error reduced considerably (the error of course, still occurs).
The this issue is actually not fixed.
When I originally mentioned the use of a counter by way of an example, I meant using Object.hashCode concatenated with a counter; not removing the use of Object.hashCode altogether as what revision 606114 has done.
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Issue Comment Edited: (AXIS2-3400) AxisService name not
unique enough
Posted by "David Poon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12558468#action_12558468 ]
dpoon edited comment on AXIS2-3400 at 1/13/08 3:27 PM:
------------------------------------------------------------
We applied the revision 606114 to InterfaceImplementationTemplate.xsl and inserted the revised xsl into axis2-codegen-1.3.jar and axis2-1.3.jar. We regenerated our stubs with the revised jars; and repeated our performance and stress tests.
The change made by revision 606114 actually made the problem *worse* - we encountered more occurrences of the "duplicate name error". To recheck, we reverted the change (ie gone back to Object.hashCode) and ran the tests again, the occurrences of the error reduced considerably (the error of course, still occurs).
Thus, this issue is actually not fixed.
When I originally mentioned the use of a counter by way of an example, I meant using Object.hashCode concatenated with a counter; not removing the use of Object.hashCode altogether as what revision 606114 has done.
was (Author: dpoon):
We applied the revision 606114 to InterfaceImplementationTemplate.xsl and inserted the revised xsl into axis2-codegen-1.3.jar and axis2-1.3.jar. We regenerated our stubs with the revised jars; and repeated our performance and stress tests.
The change made by revision 606114 actually made the problem *worse* - we encountered more occurrences of the "duplicate name error". To recheck, we reverted the change (ie gone back to Object.hashCode) and ran the tests again, the occurrences of the error reduced considerably (the error of course, still occurs).
The this issue is actually not fixed.
When I originally mentioned the use of a counter by way of an example, I meant using Object.hashCode concatenated with a counter; not removing the use of Object.hashCode altogether as what revision 606114 has done.
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Assigned: (AXIS2-3400) AxisService name not unique enough
Posted by "Deepal Jayasinghe (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Deepal Jayasinghe reassigned AXIS2-3400:
----------------------------------------
Assignee: Amila Chinthaka Suriarachchi
> 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
> Assignee: Amila Chinthaka Suriarachchi
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Resolved: (AXIS2-3400) AxisService name not unique enough
Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Davanum Srinivas resolved AXIS2-3400.
-------------------------------------
Resolution: Fixed
Fixed in svn revision 627925
> 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
> Assignee: Amila Chinthaka Suriarachchi
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Updated: (AXIS2-3400) AxisService name not unique enough
Posted by "David Poon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Poon updated AXIS2-3400:
------------------------------
Priority: Blocker (was: Critical)
We are now getting this error with 8 concurrent users.
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Updated: (AXIS2-3400) AxisService name not unique enough
Posted by "David Poon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Poon updated AXIS2-3400:
------------------------------
We have implemented our own local fix to InterfaceImplementationTemplate.xsl. Performance and stress test runs on a multi-cpu Solaris 8 host indictate that we have solved this issue; i.e., we do not get "duplicate service name" errors anymore.
We are now proposing to the Axis2 team that the fix to InterfaceImplementationTemplate.xsl should be as follows (note that the getUniqueSuffix method is *static* and *synchronized*):
===
private static int counter = 0;
private static synchronized int getUniqueSuffix() {
// reset the counter if it is greater than 99999
if (counter > 99999) {
counter = 0;
}
counter = counter + 1;
return counter;
}
private String getCurrentTime() {
return (Long.toString(System.currentTimeMillis()) + "_");
}
private void populateAxisService() throws org.apache.axis2.AxisFault {
//creating the Service with a unique name
_service = new org.apache.axis2.description.AxisService("<xsl:value-of select="@servicename"/>" + getCurrentTime() + Integer.toString(getUniqueSuffix()));
> 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
> Assignee: Amila Chinthaka Suriarachchi
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org
[jira] Updated: (AXIS2-3400) AxisService name not unique enough
Posted by "David Poon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AXIS2-3400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David Poon updated AXIS2-3400:
------------------------------
Priority: Critical (was: Major)
Issue Type: Bug (was: Improvement)
I have changed the issue type from Improvement to Bug and the priority from Major to Critical. This issue affects our environment since we are reusing the same configuration context across multiple generated Stubs in a multi-user and multithreaded environment.
> 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: Critical
>
> 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: axis-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-dev-help@ws.apache.org