|
From: Michael R. <mr...@us...> - 2004-08-12 12:54:32
|
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 |