I can't replicate the problem in jdk 1.4.2 or in 1.3.1. I suspect that the stream my be checking object equality with a a cache of previously serialized object in the stream.
Did you overwrite the equals method on the objects that you are putting in the cache? Aaron --- Aaron Smuts <[EMAIL PROTECTED]> wrote: > 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 > > > > > === message truncated === --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
