[jboss-cvs] JBossAS SVN: r89484 - projects/docs/enterprise/4.3.5/readme/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Thu May 28 01:23:43 EDT 2009
Author: irooskov at redhat.com
Date: 2009-05-28 01:23:43 -0400 (Thu, 28 May 2009)
New Revision: 89484
Modified:
projects/docs/enterprise/4.3.5/readme/en-US/Release_Notes_CP05.xml
Log:
updated release notes with new JIRA
Modified: projects/docs/enterprise/4.3.5/readme/en-US/Release_Notes_CP05.xml
===================================================================
--- projects/docs/enterprise/4.3.5/readme/en-US/Release_Notes_CP05.xml 2009-05-28 04:51:27 UTC (rev 89483)
+++ projects/docs/enterprise/4.3.5/readme/en-US/Release_Notes_CP05.xml 2009-05-28 05:23:43 UTC (rev 89484)
@@ -89,11 +89,11 @@
JBoss Messaging 1.4.0.SP3-CP08
</para>
</listitem>
- <!-- <listitem>
+ <listitem>
<para>
- JBoss Remoting 2.2.2.SP11
+ JBoss Remoting 2.2.3
</para>
- </listitem> -->
+ </listitem>
<listitem>
<para>
JBoss Transactions 4.2.3.SP5.CP05
@@ -473,18 +473,66 @@
</itemizedlist>
</para>
</formalpara>
- <!-- <formalpara>
+ <formalpara>
<title>JBoss Remoting</title>
<para>
<itemizedlist>
<listitem>
<para>
-
+ <ulink url="http://jira.jboss.com/jira/browse/JBPAPP-1996">JBPAPP-1996</ulink>: The JBoss Remoting component of the Enterprise Application Platform has been upgraded to version 2.2.3. A list of the included fixes is as follows:
</para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1125">JBREM-1125</ulink>:
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1121">JBREM-1121</ulink>: Functionality has been added to the client <classname>SocketFactory</classname> that allows it to be configurable by the <classname>InvokerLocator</classname> so that all the parameters from the <classname>InvokerLocator</classname> are avaliable instead of only those in the configuration map.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1119">JBREM-1119</ulink>: If the application called the <methodname>org.jboss.remoting.Client.removeListener()</methodname> method, then <classname>ServerInvoker</classname> would remove references to <classname>ServerInvokerCallbackHandler</classname>, and it would call the <methodname>ServerInvocationHandler.removeListener()</methodname> method, granting the application a chance to remove the reference it held. An issue arose if the connection from the client was to break as that would cause none of the above to be executed, leading to a memory leak in the program. To fix the problem, <classname>ConnectionNotifier</classname> now uses copies of lists in order to avoid a <exceptionname>ConcurrentModificationException</exceptionname>, a <methodname>shutdown()</methodname> method has been added to the <classname>ServerInvokerCallbackHandler</classname>, and within the <classname>ServerInvoker</classname> the <metho!
dname>removeCallbackHandler()</methodname> method has been made public and a <methodname>shutdownCallbackHandler()</methodname> method has been added. These changes mean that the <methodname>shutdown()</methodname> method within the <classname>ServerInvokerCallbackHandler</classname> can be used by the application to remove the necessary references by utilizing the <classname>ServerInvoker</classname> and the applications <classname>ServerInvocationHandler</classname>.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1112">JBREM-1112</ulink>: Upon a connection failure there was occurances of a race condition occuring between the <classname>ConnectionValidator</classname> and <classname>ConnectionListener</classname> as <classname>ConnectionValidator</classname> may be able to execute the <methodname>Client.getDisconnectTImeout()</methodname> method before a <classname>ConnectionListener</classname> executes <methodname>Client.setDisconnectTimeout()</methodname>, causing the program to behave unexpectenly. This issue has been fixed by introducing a new parameter called <property>ConnectionValidator.FAILURE_DISCONNECT_TIMEOUT</property> (with the actual value of <varname>failureDisconnectTimeout</varname>). If the <property>org.jboss.remoting.Client.USE_ALL_PARAMS</property> property (with the actual value of <varname>useAllParams</varname>) is set to <emphasis>true</emphasis>, this parameter can be set in the <classname>Invoker!
Locator</classname>, the client's configuration map, or the metadata map passed to the <methodname>Client.addConnectionListener()</methodname> method. If <emphasis>failureDisconnectTimeout</emphasis> is set to an integer value other than -1, then <classname>ConnectionValidator</classname> will use that value when it calls the <methodname>ClientInvoker.terminateLease()</methodname> method, otherwise the value returned by the <methodname>Client.getDisconnectTimeout()</methodname> method is used.
+
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1111">JBREM-1111</ulink>: In <classname>LeasePinger</classname> when all the <classname>TimerTasks</classname> that ran in <classname>java.util.TimerTask</classname> were shut down the <classname>Timer</classname> would also shut down and will not accept any further <classname>TimerTasks</classname>. If a new <classname>Timer</classname> was to be created and a <classname>TimerTask</classname> scheduled for it, an exception would occur. In order to successfully replace the <classname>Timer</classname> if it has shut down, the <methodname>Wrapped timer.schedule()</methodname> is now utilized.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1109">JBREM-1109</ulink>: Within the <methodname>org.jboss.remoting.MicroRemoteClientInvoker.getDataType()</methodname> method when the <varname>dataType</varname> variable was set to the value of the <methodname>getDataType(getLocator())</methodname> method, the variable would temporarily be set to null if the <classname>InvokerLocator</classname> had no datatype parameter. This caused issues because another thread may use the <varname>dataType</varname> variable and return a value of null. Correting this bug has lead to using a local variable called <varname>localDataType</varname> while a check occurs to see if <classname>InvokerLocator</classname> contains a datatype value. The number of threads has also been reduced to 1000 in order to avoid an <exceptionname>OutOfMemoryError</exceptionname> taht may have occured.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1099">JBREM-1099</ulink>: The multicast detector did not work correctly in environments where many JBoss Remoting invokers were being used. The <methodname>org.jboss.remoting.detection.AbstractDetector.createDetection()</methodname> method would create a detection message based on the number of server inokers registered locally. In the JBoss Enterprise Application Server this would cause an error as the message size would exceed the 4000 limit. A <property>buffersize</property> attribute has been created for <classname>org.jboss.remoting.detection.multicast.MulticastDetector</classname> and <classname>org.jboss.remoting.detection.multicast.MulticastDetectorMBean</classname> that defaults to a value of 10000.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1088">JBREM-1088</ulink>: If the server hostname DNS mapping was not available at the client during a <methodname>org.jboss.remoting.Client.connect()</methodname> call, the <methodname>org.jboss.remoting.transport.socket.MicroSocketClientInvoker.setup() getAddressByName</methodname> produces a <exceptionname>java.net.UnknownHostException</exceptionname> in relation to the hostname. However when the method <methodname>org.jboss.remoting.transport.socket.MicroSocketClientInvoker(InvokerLocator locator, Map configuration)</methodname> is called the exception is captured and then displayed using <methodname>throw new RuntimeException(ex.getMessage())</methodname>. By displaying the exception in this way, information important in understanding the cause of the exception, is lost. This has been rectified by changing <methodname>throw new RuntimeException(ex.getMessage());</methodname> to <methodname>throw new RuntimeExc!
eption(ex.getMessage(), ex);</methodname>, enabeling the actual exception content to be displayed to the user.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <ulink url="http://jira.jboss.com/jira/browse/JBREM-1081">JBREM-1081</ulink>: When the method <methodname>ServerInvokerCallbackHandler.destroy()</methodname> shut down <classname>When org.jboss.remoting.callback.ServerInvokerCallback</classname>, the variables <varname>callBackClient</varname> and <varname>callbackStore</varname> were set to null. If the <methodname>ServerInvokerCallbackHandler.handleCallback()</methodname> is then called a <exceptionname>NullPointerException</exceptionname> arises because that variables <varname>callBackClient</varname> and <varname>callbackStore</varname> are set to null. This bug has been corrected in this latest release by the <methodname>ServerInvokerCallbackHandler.destroy()</methodname> method no longer assigning a value of null to the variables <varname>callBackClient</varname> and <varname>callbackStore</varname>.
+ </para>
+ </listitem>
+ </itemizedlist>
</listitem>
</itemizedlist>
</para>
- </formalpara> -->
+ </formalpara>
<formalpara>
<title>JBoss Web</title>
<para>
More information about the jboss-cvs-commits
mailing list