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]
