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]
