I did not look at it at all! An uphill battle to understand that test so I thought to ask you guys to have a look. Question to ask: why is it that only that particular test in the class with 3 other tests, out of total of almost 600 tests fails.... On 6/3/09 7:39 PM, Manik Surtani wrote:

JGroups seems to be dropping the message directed to a node that is up and this leads to a replication timeout. The test starts 3 cache instances: 2009-06-04 11:36:38,771 4278 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (main:) Received new cluster view: [localhost.localdomain-23373|2] [localhost.localdomain-23373, localhost.localdomain-4344, localhost.localdomain-15374] Then adds some data to one of the, cache[0] (localhost.localdomain-23373), and stops it. This is the new view installed: 2009-06-04 11:36:39,047 4554 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-2,Infinispan-Cluster,localhost.localdomain-15374:) Received new cluster view: [localhost.localdomain-4344|3] [localhost.localdomain-4344, localhost.localdomain-15374] The test now takes cache[1] and adds some data there but JGroups is dropping data that needs to be replicated to cache[2] as shown by these WARN messages: 2009-06-04 11:36:44,765 10272 WARN [org.jgroups.protocols.TCP] (Timer-2,Infinispan-Cluster,localhost.localdomain-4344:) no physical address for localhost.localdomain-15374, dropping message 2009-06-04 11:36:50,766 16273 WARN [org.jgroups.protocols.TCP] (Timer-1,Infinispan-Cluster,localhost.localdomain-4344:) no physical address for localhost.localdomain-15374, dropping message I don't know why JGroups is doing this but enabling TRACE on org.jgroups should clarify it. Vladimir, can you look to why JGroups throws these WARN messages? localhost.localdomain-15374 is still up and running, it's localhost.localdomain-23373 that was stopped. Looks like JGroups might be confusing both? Galder Zamarreno wrote: -- Galder Zamarreño Sr. Software Maintenance Engineer JBoss, a division of Red Hat