If you have it, please send me a test case the exposes the problem. I made a test that looked like what you specified and i didn't see the problem.
See the last two tests here: http://svn.apache.org/viewcvs.cgi/jakarta/jcs/trunk/src/test/org/apache/jcs/auxiliary/lateral/socket/tcp/TestTCPLateral.java?rev=332196&view=markup Or send me a bit more of the actual code. Also can you give me the specific jdk that you are running on. At the bare minimum, I'll make that reest count variable configurable. Aaron --- Benjamin Foo <[EMAIL PROTECTED]> wrote: > Hi Aaron, > > Thanks for your help at this. On my part, the object > that is set in the val property is nothing more than > a simple java.lang.String. Haha. We did not override > that equals method (in fact I would punish anyone in > my team who does that) as there is no need to. > > Regards > > 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]> > > > > ________________________________ > > From: Aaron Smuts [mailto:[EMAIL PROTECTED] > Sent: Thu 10/11/2005 08:33 > To: JCS Developers List > Subject: Spam:Re: Lateral Cache Problems due to > ObjectOutputStream Reset frequency > > > > 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 ]] > > > > > > > > > > > === message truncated ===> --------------------------------------------------------------------- > 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]
