RE: [jbosscache-users] Issue with JBC on Tomcat 5.5
by Mamta, Jain
Hi Manik,
My questions still remain unanswered on automatic discovery of a
multicast group by JBossCache ( in turn Jgroups/Channel ). Would like to
know :
1. How to configure JBossCache for automatic discovery of an existing
multicast group on which the Tomcat cluster is setup ? Have looked at
the JBossCache on this, did not find much information, hence asking help
from this group.
2. Do I have to modify the Jgroups xmls to achieve the requirement of
automatic discovery ?
Best Regards,
Jigyaasa_jbosscache
-----Original Message-----
From: Manik Surtani [mailto:manik@jboss.org]
Sent: Tuesday, November 13, 2007 8:24 PM
To: Brian Stansberry
Cc: Mamta, Jain; jbosscache-users(a)lists.jboss.org
Subject: Re: [jbosscache-users] Issue with JBC on Tomcat 5.5
On 13 Nov 2007, at 14:52, Brian Stansberry wrote:
> Manik Surtani wrote:
>> On 13 Nov 2007, at 10:30, Mamta, Jain wrote:
>>> Hi Manik,
>>> Thanks for your reply.
>>> Yes, the tomcat clustering is enabled and works fine. Does tomcat
>>> also use JGroups ?
>> Yes, although potentially not the same version as shipped with JBoss
>> Cache.
>
> Just a clarification -- Tomcat clustering does not use JGroups. If
> does use multicast though, and as Manik said if you try to configure
> the same multicast address and port for both it and JBoss Cache's
> channel, it won't work.
Thanks for the clarification, Brian. :-)
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
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.
17 years, 11 months
- 2
- 1
RE: [jbosscache-users] Issue with JBC on Tomcat 5.5
by Mamta, Jain
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(a)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(McastServiceI
mpl.java:210)
at
org.apache.catalina.cluster.mcast.McastServiceImpl$ReceiverThread.run(Mc
astServiceImpl.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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jbosscache-users
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
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.
17 years, 11 months
- 3
- 3
Issue with JBC on Tomcat 5.5
by Mamta, Jain
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(McastServiceI
mpl.java:210)
at
org.apache.catalina.cluster.mcast.McastServiceImpl$ReceiverThread.run(Mc
astServiceImpl.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.
17 years, 11 months
- 2
- 1
Cache Consistency following transient Network Outage?
by Bill Doster
I'm hoping that JBoss Cache can recover cache consistency following a
transient network outage. From my readings of both Cache and JGroups,
I've ended up thinking that it's JGroups that notices begin-and-end
of network partitions and that JGroups then notifies dependent classes
so that they know that they need to deal with the potential merging of
any higher-level state changes in each sub-cluster during the network
partition.
This seems consistent with a recent response from Bela Ban (2007.0914):
http://sourceforge.net/mailarchive/message.php?
msg_id=46EA2BA0.9090508%40yahoo.com
But from my understanding of JBoss Cache (the dependent class I'm
considering) via:
"JBoss Cache TreeCache: A Structured, Replicated, Transactional Cache"
(http://labs.jboss.com/file-access/default/members/jbosscache/
freezone/docs/1.4.1.SP4/TreeCache/en/html_single/index.html)
I can't identify anything as directly addressing JBoss Cache's
"application-data" healing from a network partition...
Here's a particular test scenario that would need to handle the
situation I'm thinking of:
JBoss Cache ClusterName="A-B" with two members ("A" and "B") is
started.
"A" and "B" both view "A" as "coordinator".
To keep things simple, let's have only a single region.
No Cache Loaders are used -- thus all Cache state exists only in-
memory (no back-end data store).
Time passes peacefully and "A-B" builds up some amount of Cache
state, all of it consistent across A and B.
Then, a network partition occurs (perhaps a backbone router is
powered down for 10-15 minutes to add an additional card).
After some amount of time, both A and B finally end-up marking each
other "dead" and themselves
as JGroup coordinator for their sub-cluster.
During this partition, both A and B can continue to accept updates to
their Cache state, right?
And this would result in the now-independent Caches becoming distinct
from each other.
So, once the result of the network partition is resolved, JGroups
will realize this and notify JBoss Cache
via a ViewChange.
My question is:
does JBoss Cache itself somehow merge the during-partition state
changes together?
Since neither member was itself down and both could potentially have
partition-related state changes,
causing either to simply dump their in-memory state and ask for a
full state-transfer will result in a
loss of information.
17 years, 12 months
- 2
- 1
- ← Newer
- 1
- Older →