Hi Manik,
 
Thanks for your reply.
Yes, the tomcat clustering is enabled and works fine. Does tomcat also use JGroups ?
 
The tomcat's clustering is on say 228.8.8.8 and port 4554. What I have done is, configured replSync-service.xml that comes with JBossCache and pointed the UDP/mcastaddr  to the same addr and port as in Tomcat. Is there something wrong here ? What I have udnerstood from the documetns of JBossCAche is that, it leverages on JGroups which is capable of discovering an existing multicast group, in that case is'nt this configuration enough ? If the answer is no then what is the role of replSync-service.xml ? Is there a separate xml that is to be configured for automatic discovery ? Or the mping.xml found in jgroups.jar has to be modified ?
 
Have not found any information on configuring for automatic discovery in the JBoss user guide.
 
Best Regards,
Jigyaasa_Jbosscache
 

From: Manik Surtani [mailto:manik@jboss.org]
Sent: Monday, November 12, 2007 7:03 PM
To: Mamta, Jain
Cc: jbosscache-users@lists.jboss.org
Subject: Re: [jbosscache-users] Issue with JBC on Tomcat 5.5 

 
Have you enabled Tomcat clustering as well?  By the look of that stack trace Tomcat clustering is enabled, and it may use a different version of JGroups.  If you want to use TOmcat clustering as well, make sure your multicast address and ports don't overlap.

http://wiki.jboss.org/wiki/Wiki.jsp?page=PromiscuousTraffic


On 12 Nov 2007, at 05:17, Mamta, Jain wrote:

Hi All,
 
We are having trouble using JBC Habanero version 2.0.0.0 GA for enabling Distributed Caching. The error encountered as appearing in the log is :
 
Nov 2, 2007 6:00:07 AM org.jgroups.protocols.TP$IncomingPacket run
WARNING: packet from a.b.c.d:45564 has different version (0.0.0) from ours (2.5.0). Packet is discarded
 
Environment :
Tomcat 5.5.20, Multicast
Starting Catalina with the following option to avoid the "Problem creating sockets" :
    -Djava.net.preferIPv4Stack=true
 
What I am trying to do is, use JBC for distributing cache over the Tomcats cluster established with multicasting. The steps followed were :
 
    1. modified ip address & port for the UDP/mcastaddr and port in replSync-service.xml
    2. commented off transaction manager tag in the xml, as we dont have the requirement for Transactional Caching
    3. created a client that would enable/initialize the JBC caching :
 
        CacheFactory factory = DefaultCacheFactory.getInstance();
        cache = factory.createCache(<url of the replSync-service.xml>);
 
Whats happening is :
 
    1. JGroups seems to be doing whats required as I see the following in the log :
 
        INFO: JGroups version: 2.5.0
        -------------------------------------------------------
        GMS: address is a.b.c.d:32838

    2. And further the following is logged :
 
    INFO: viewAccepted(): [a.b.c.d:32838|0] [a.b.c.d:32838]
    Nov 2, 2007 6:00:06 AM org.jboss.cache.CacheImpl internalStart
    INFO: CacheImpl local address is a.b.c.d:32838
    Nov 2, 2007 6:00:06 AM org.jboss.cache.CacheImpl internalStart
    INFO: JBoss Cache version: JBossCache 'Habanero' 2.0.0.GA[ $Id: Version.java,v 1.35 2007/08/01 16:52:13 msurtani Exp $]
    Nov 2, 2007 6:00:07 AM org.apache.catalina.cluster.mcast.McastServiceImpl$ReceiverThread run
    WARNING: Error receiving mcast package. Sleeping 500ms
        java.lang.ArrayIndexOutOfBoundsException
         at java.lang.System.arraycopy(Native Method)
         at org.apache.catalina.cluster.mcast.McastMember.getMember(McastMember.java:174)
         at org.apache.catalina.cluster.mcast.McastServiceImpl.receive(McastServiceImpl.java:210)
         at org.apache.catalina.cluster.mcast.McastServiceImpl$ReceiverThread.run(McastServiceImpl.java:254)
    Nov 2, 2007 6:00:07 AM org.jgroups.protocols.TP$IncomingPacket run
    WARNING: packet from a.b.c.d:45564 has different version (0.0.0) from ours (2.5.0). Packet is discarded
    3. Is the observed error ignorable ?
    4. I have not started the other node in the cluster as there are hundreds of lines appearing in the log with Packet discarded message.
 
Have I done enough, or missing something obvious as the documents do direct us to do just the above.
Best Regards,
Jigyaasa_Jbosscache
This email is confidential. If you are not the addressee tell the sender immediately and destroy this email
without using, sending or storing it. Emails are not secure and may suffer errors, viruses, delay,
interception and amendment. Standard Chartered PLC and subsidiaries ("SCGroup") do not accept liability for
damage caused by this email and may monitor email traffic.
_______________________________________________
jbosscache-users mailing list
jbosscache-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-users

--
Manik Surtani
Lead, JBoss Cache






This email is confidential. If you are not the addressee tell the sender immediately and destroy this email
without using, sending or storing it. Emails are not secure and may suffer errors, viruses, delay,
interception and amendment. Standard Chartered PLC and subsidiaries ("SCGroup") do not accept liability for
damage caused by this email and may monitor email traffic.