Mailing-List: contact jcs-users-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "JCS Users List" <jcs-users@jakarta.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Subject: Re: Lateral Cache UDP Discovery Implementation Question
From: Randy Watler <watler@wispertel.net>
To: JCS Users List <jcs-users@jakarta.apache.org>
In-Reply-To: <1162830595.2830.13.camel@localhost.localdomain>
References: <20061106152342.52014.qmail@web38714.mail.mud.yahoo.com>
	 <1162830595.2830.13.camel@localhost.localdomain>
Content-Type: text/plain
Date: Mon, 06 Nov 2006 12:33:16 -0700
Message-Id: <1162841596.2830.29.camel@localhost.localdomain>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

Aaron,

FYI... setting startNow to true as below seemed to do the trick. I will
be running that configuration for a bit here, so I will let you know if
I run into any problems along the way.

Thanks for your help!

Randy

On Mon, 2006-11-06 at 09:29 -0700, Randy Watler wrote:
> Aaron,
> 
> Cool. I can understand that it could be messy conceptually to respond to
> one's own broadcast request. How about an explicit broadcast on a
> startup... why wait for 30 seconds in that case?
> 
> Seems to me that we should set startNow flag to true in the ClockDaemon
> executePeriodically() invocation. Any reason not to make this change in
> your mind? Modify line 129 in UDPDiscoveryService.java from:
> 
>         senderDaemon.executePeriodically( 30 * 1000, sender, false );
> 
> to
> 
>         senderDaemon.executePeriodically( 30 * 1000, sender, true );
> 
> As you can see on this thread, the issue I have is that my test cases do
> not get a lateral cache configured properly on start up. Since our tests
> run as part of our maven build, I do try not to have them take 30
> seconds if I can help it... this is most certainly why I see this as an
> issue and others don't.
> 
> Again, thanks for hanging in there with me.
> 
> Randy
> 
> On Mon, 2006-11-06 at 07:23 -0800, Aaron Smuts wrote:
> > A passive braodcast should go out every 30 seconds. 
> > If not, then something is wrong.  It should never
> > respond to itself.  That's very messy.  
> > 
> > Aaron
> > 
> > --- Randy Watler <watler@wispertel.net> wrote:
> > 
> > > A quick followup on this issue:
> > > 
> > > I have verified that lateral cache clients do manage
> > > to get configured
> > > correctly most of the time if all clients attempt to
> > > discover each other
> > > simultaneously. However, my results still suggest
> > > that any client that
> > > is started later than others will not be discovered
> > > by the other caches.
> > > 
> > > I believe that a client should actively broadcast
> > > its lateral cache
> > > listener upon start up one way or another...
> > > something I do not see
> > > happening. As noted below, one way to accomplish
> > > this would be to allow
> > > a lateral cache to respond to its own broadcast
> > > request.
> > > 
> > > Anyone else notice the same issue with UDP
> > > Discovery?
> > > 
> > > Randy
> > > 
> > > On Thu, 2006-11-02 at 22:54 -0700, Randy Watler
> > > wrote:
> > > > I have a test case for our integration of JCS
> > > 1.2.7.9 using a TCP
> > > > Lateral Cache with UDP Discovery that verifies the
> > > lateral cache is
> > > > fully active upon start up. However, it seems that
> > > the discovery
> > > > mechanism is not locating all test case processes
> > > that are trying to be
> > > > members of the lateral cache.
> > > > 
> > > > In this test, we create 3 processes that all
> > > employ the lateral cache
> > > > using sequential tcp listener ports. Here is the
> > > test case
> > > > configuration:
> > > > 
> > > >
> > >
> > jcs.auxiliary.LC=org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPCacheFactory
> > > >
> > >
> > jcs.auxiliary.LC.attributes=org.apache.jcs.auxiliary.lateral.socket.tcp.TCPLateralCacheAttributes
> > > >
> > > jcs.auxiliary.LC.attributes.TcpListenerPort=599[567]
> > > >
> > >
> > jcs.auxiliary.LC.attributes.UdpDiscoveryAddr=225.0.0.1
> > > > jcs.auxiliary.LC.attributes.UdpDiscoveryPort=5994
> > > >
> > > jcs.auxiliary.LC.attributes.UdpDiscoveryEnabled=true
> > > > jcs.auxiliary.LC.attributes.Receive=true
> > > > jcs.auxiliary.LC.attributes.AllowGet=false
> > > > jcs.auxiliary.LC.attributes.IssueRemoveOnPut=true
> > > >
> > >
> > jcs.auxiliary.LC.attributes.FilterRemoveByHashCode=false
> > > > 
> > > > With debugging on, I can see that lateral cache
> > > senders are not being
> > > > created symmetrically:
> > > > 
> > > > Process1 14:11:45,082 DEBUG  [Thread-4]:
> > >
> > org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPService
> > > - Created sender to [127.0.0.1:5995]
> > > > Process0 14:11:56,597 DEBUG  [Thread-4]:
> > >
> > org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPService
> > > - Created sender to [127.0.0.1:5996]
> > > > Process2 14:11:57,371 DEBUG  [Thread-4]:
> > >
> > org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPService
> > > - Created sender to [127.0.0.1:5996]
> > > > Process2 14:11:57,380 DEBUG  [Thread-4]:
> > >
> > org.apache.jcs.auxiliary.lateral.socket.tcp.LateralTCPService
> > > - Created sender to [127.0.0.1:5995]
> > > > 
> > > > First, Process0 was started. Then Process1 was
> > > started at 11:45.
> > > > Process1 Discovery properly found Process0 at
> > > 5995, but Process0 did not
> > > > notice that Process1 at 5996 was started.
> > > > 
> > > > Process2 was then started at 11:56. When Process1
> > > responded to the
> > > > broadcast request from Process2, both Process0 and
> > > Process2 then saw
> > > > Process1 at 5996. As one would expect, Process2
> > > also located Process0 at
> > > > 5995.
> > > > 
> > > > Notice that each time the starting process
> > > remained invisible to the
> > > > other instances in the lateral cache cluster.
> > > After looking at the logs
> > > > in more detail, it seems that a PASSIVE_BROADCAST
> > > for the new process is
> > > > not sent on start up:
> > > > 
> > > > Process0 14:11:45,022 DEBUG  [Thread-4]:
> > >
> > org.apache.jcs.auxiliary.lateral.socket.tcp.discovery.UDPDiscoverySender
> > > - sending passiveBroadcast
> > > > Process0 14:11:56,546 DEBUG  [Thread-4]:
> > >
> > org.apache.jcs.auxiliary.lateral.socket.tcp.discovery.UDPDiscoverySender
> > > - sending passiveBroadcast
> > > > Process1 14:11:56,539 DEBUG  [Thread-4]:
> > >
> > org.apache.jcs.auxiliary.lateral.socket.tcp.discovery.UDPDiscoverySender
> > > - sending passiveBroadcast
> > > > 
> > > > After looking at the code, I noticed that in
> > > UDPDiscoveryReceiver.run()
> > > > messages "from self" are ignored by a test on line
> > > 278. I was surprised
> > > > to see this since I would expect a
> > > REQUEST_BROADCAST from self, if
> > > > processed, would allow the process starting to
> > > broadcast its listener...
> > > > something that appears to be missing. Furthermore,
> > > I found no other
> > > > mechanisms that would allow a PASSIVE_BROADCAST to
> > > be sent.
> > > > 
> > > > Have I misconfigured the cache or read the
> > > code/logs incorrectly? Or, is
> > > > there a reason that the "from self"
> > > REQUEST_BROADCAST messages are not
> > > > processed in UDPDiscoveryReceiver.run() lines
> > > 280-283 by invoking
> > > > UDPDiscoveryService.serviceRequestBroadcast() as
> > > is done on line 301?
> > > > 
> > > > Thanks for any help in advance,
> > > > 
> > > > Randy
> > > > 
> > > > 
> > > > 
> > > >
> > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail:
> > > jcs-users-unsubscribe@jakarta.apache.org
> > > > For additional commands, e-mail:
> > > jcs-users-help@jakarta.apache.org
> > > > 
> > > > 
> > > 
> > > 
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail:
> > > jcs-users-unsubscribe@jakarta.apache.org
> > > For additional commands, e-mail:
> > > jcs-users-help@jakarta.apache.org
> > > 
> > > 
> > 
> > 
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: jcs-users-help@jakarta.apache.org
> > 
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jcs-users-help@jakarta.apache.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: jcs-users-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jcs-users-help@jakarta.apache.org