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 <[EMAIL PROTECTED]> 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:
> > [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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
