writeUnshared is new in jdk1.4 I guess we'll have to reset after each send. This basically just clears the stream's cache which we don't want to use anyway, I think.
Here's the 1.3 javadoc: http://java.sun.com/j2se/1.3/docs/api/java/io/ObjectOutputStream.html#reset() --- Aaron Smuts <[EMAIL PROTECTED]> wrote: > I think the output stream must think that the object > is the same as the one previously written. Calling > reset everytime, or using the writeUnshared method > should work. I think writeUnshared will be better. > > http://java.sun.com/j2se/1.4.2/docs/api/java/io/ObjectOutputStream.html#writeUnshared(java.lang.Object) > > Aaron Smuts > > > > --- Aaron Smuts <[EMAIL PROTECTED]> wrote: > > > This is strange. > > > > Can you try on jdk1.4 or above and see if you get > > the > > same problem? > > > > Does it happen every time? > > > > Aaron > > > > --- Benjamin Foo <[EMAIL PROTECTED]> wrote: > > > > > Hi JCS developers, > > > > > > Recently, I've encountered a wierd behaviour > > > regarding the synchronising of data across > lateral > > > caches. The problem occurs when a given > > LateralCache > > > begins streaming the LateralElementDescriptor > > object > > > to other laterals. It is discovered that the > > > CacheElement.val property tends to reuse the > value > > > of a previously sent led (where the keys are the > > > same). Following is an example of how caches > will > > > become unsynchornised: > > > > > > LateralCache1 sends led (key="MyKey", > > > value="MyValue1") > > > > > > LateralCache2 received led (key="MyKey", > > > value="MyValue1") > > > > > > LateralCache1 sends led (key="MyKey", > > > value="MyValue1,MyValue2") > > > > > > LateralCache2 received led (key="MyKey", > > > value="MyValue1") > > > > > > > > > I attempted to address this behaviour by adding > in > > > some debugging code: > > > > > > In the try-catch block just before > > > ObjectOutputStream writes the object > > > > > > oos.writeObject( led ); > > > > > > I added some debugging code at the send method > > > > > > //** Ben DEBUG Code (09/11/2005) > > > if ( log.isDebugEnabled() ) > > > { > > > log.debug( "BEN: Sending > > > LateralElementDescriptor to other laterals " + > > "led > > > = " + led + ", led.command = " + led.command + > ", > > > led.ce = " + led.ce ); > > > } > > > > > > Output is: > > > <Nov 9, 2005 3:52:07 PM ICT> <DEBUG> > > > <LateralTCPSender> BEN: Sending > > > LateralElementDescriptor to other laterals led = > > > > > > [EMAIL PROTECTED] > > > > > > <mailto:[EMAIL PROTECTED]> > > > , led.command = 1, led.ce = > > > [cacheName=DSMSDataCache, > key=LoginValue-GROUPKEY, > > > val=[74398d770ac5c563005ae9d6c8b00087, > > > 7436cea60ac5c563005ae9d6a093a373], attr = [ > > > IS_LATERAL = true, IS_SPOOL = true, IS_REMOTE = > > > true, IS_ETERNAL = false, MaxLifeSeconds = -1, > > > IdleTime = -1, CreateTime = 1131526327671, > > > LastAccessTime = 1131526327671, > > > getTimeToLiveSeconds() = -1, createTime = > > > 1131526327671 ]] > > > > > > > > > To my surprise, before writing the object, the > led > > > value is correct, but at the receiving end at > the > > > LateralTCPListener, in the Thread's run method, > > the > > > ObjectInputStream reads a stale value: > > > > > > led = (LateralElementDescriptor) > ois.readObject(); > > > > > > Output is: > > > <Nov 9, 2005 3:52:08 PM ICT> <DEBUG> > > > <LateralTCPListener> receiving > > > LateralElementDescriptor from anotherled = > > > > > > [EMAIL PROTECTED] > > > > > > <mailto:[EMAIL PROTECTED]> > > > , led.command = 1, led.ce = > > > [cacheName=DSMSDataCache, > key=LoginValue-GROUPKEY, > > > val=[7436cea60ac5c563005ae9d6a093a373], attr = [ > > > IS_LATERAL = true, IS_SPOOL = true, IS_REMOTE = > > > true, IS_ETERNAL = false, MaxLifeSeconds = -1, > > > IdleTime = -1, CreateTime = 1131526327671, > > > LastAccessTime = 1131526327671, > > > getTimeToLiveSeconds() = 16, createTime = > > > 1131526327671 ]] > > > > > > > > > I decided to change the constant value for > > > RESET_FREQUENCY of the LateralTCPSender class to > 1 > > > (reset after every send), and the LateralCaches > no > > > longer have unsynchornised values. > > > > > > Is there any impact to the performance of JCS by > > > doing this? Could this be a minor fault with the > > JDK > > > (I'm running on JDK131)? > > > > > > > > > > > > Benjamin Foo > > > Technical Lead > > > Kasikornbank CMAS Corporate Project > > > > > > On-site Project Address > > > 9th Floor (Special Projects Department) > > > Kasikornbank PCL > > > 1 Soi Kasikornthai > > > Ratburana Road > > > 10140 Bangkok > > > Thailand > > > > > > Head Office Address > > > eBworx Berhad > > > 7th Floor Menara Merais > > > 1 Jalan 19/3 > > > 46300 Petaling Jaya > > > Selangor DE > > > Malaysia > > > > > > Tel: (+6)03-7956 9822 > > > Fax: (+6)03-7957 2661 > > > Mobile: (+6)016-330 0565 (Malaysia) > > > Mobile: (+66)4-656 1719 (Thailand) > > > Email: [EMAIL PROTECTED] > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: > > > [EMAIL PROTECTED] > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > === message truncated === --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
