[openorb-commits] CVS: OpenORB WHATSNEW,1.227,1.228

[Michael R. <mr...@us...>]

Update of /cvsroot/openorb/OpenORB
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv6600/OpenORB

Modified Files:
	WHATSNEW 
Log Message:
Various improvements, see WHATSNEW for details

Index: WHATSNEW
===================================================================
RCS file: /cvsroot/openorb/OpenORB/WHATSNEW,v
retrieving revision 1.227
retrieving revision 1.228
diff -u -d -r1.227 -r1.228
--- WHATSNEW	29 Jul 2004 09:48:12 -0000	1.227
+++ WHATSNEW	12 Aug 2004 12:54:23 -0000	1.228
@@ -1,6 +1,73 @@
 OpenORB
 -------
 
+- Fixed some typos and improved some exception messages.
+
+- Added general method isGIOPHeaderOK to the Trace class.
+  This method gets called from StorageBuffer.writeTo()
+  method to make sure that we do not send buffers that
+  will be rejected by the client.
+
+- Added documentation to the Scrap class to clarify its pupose.
+
+- Calls to MarshalBuffer.Listener instances have been wrapped
+  with try-finally blocks in order to get the flags reset
+  correctly in case of a problem in the listener code.
+
+- Fixed a bug in StorageBuffer.linearize() that seems to have
+  existed for quite some time now. At least the file has not
+  been changed since our code takeover of the Exolab codebase.
+  The linearize() method is called from the Trace class only
+  when debugging has been enabled. A call to linearize() was
+  creating one huge buffer in the head Scrap element instead
+  of having a lot of smaller buffers distributed over many
+  Scrap instances in the singly linked Scrap list.
+  When the last fragment was sent the buffer created had the
+  size of the whole message, because the call to
+  MarshalBuffer.lastFragment() was passing a wrong length
+  to the StorageBuffer instance created by this method.
+  The linearize() method was using the wrong offset for
+  consolidating the small arrays into the large so that
+  the 'GIOP' started at the overall position of all fragments.
+  The client receives the message and sees that the first four
+  do not have the 'GIOP' pattern and thus was throwing a
+  "Bad Magic" MARSHAL exception.
+  In most of the cases when debugging was enabled the linearize()
+  method was just returning null because of an internal
+  ArrayIndexOutOfBoundsException that had not been shown.
+  The problem in this case was that the IIOP message buffer was
+  not shown in debug output.
+
+- Improved logging and exception messages for the MarshalBuffer
+  and some related classes.
+  The problem is that the MarshalBuffer class is a critical
+  component and no logging should slow down its operation.
+  Therefore I added a new flag: 'openorb.debug.enabled'
+  It can be used by performance critical classes to make the JIT
+  completely remove the logging statements at runtime.
+  The flag must be set like this:
+
+     private static final boolean DEBUG_ENABLED =
+            Boolean.getBoolean( System.getProperty(
+               "openorb.debug.enabled" ) );
+
+  A logger statement can then be wrapped like this:
+
+    if ( DEBUG_ENABLED
+          && getLogger().isDebugEnabled() && Trace.isMedium() )
+    {
+        getLogger().debug( "Blablabla" );
+    }
+
+  The consequence of this mechanism is that the JIT can completely
+  remove the logging statement as it is clear that the if statement
+  can never become true.
+  The downside is that we have another debug flag that must be set
+  in order to see the debug messages.
+
+- Added a test case for a fragmentation bug. Contributed by
+  Michael C. Macaluso (michael _dot_ macaluso _at_ wavecorp _dot_ com)
+
 Version 1.4.0 BETA2 - July, 29 2004 - OpenORB_1_4_0_BETA2
 
 - Fixed bug #955143. The problem of marshaling the array type