Build problems
by Brian Stansberry
Can't compile jbc core; maybe something didn't get checked in?
[INFO] Compiling 300 source files to
/home/bes/dev/jbc/core/trunk/target/classes
[INFO]
------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO]
------------------------------------------------------------------------
[INFO] Compilation failure
/home/bes/dev/jbc/core/trunk/src/main/java/org/jboss/cache/util/CachePrinter.java:[6,43]
package org.jboss.cache.factories.injection does not exist
/home/bes/dev/jbc/core/trunk/src/main/java/org/jboss/cache/util/CachePrinter.java:[60,61]
package ComponentFactory does not exist
/home/bes/dev/jbc/core/trunk/src/main/java/org/jboss/cache/util/CachePrinter.java:[69,75]
package ComponentFactory does not exist
/home/bes/dev/jbc/core/trunk/src/main/java/org/jboss/cache/util/CachePrinter.java:[75,27]
package ComponentFactory does not exist
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
18 years, 9 months
Releasing 2.1.0.GA
by Manik Surtani
Guys,
I've created a JBQA JIRA to release 2.1.0.GA - both core and pojo
editions, simultaneously.
http://jira.jboss.org/jira/browse/JBQA-1197
I will tag this in the next hour or so and put the tag on the JIRA.
Jason, once I have done this I presume you'd be tagging PojoCache as
well? Once you have done this, could you please ping Ryan/QE so they
can run with it.
Brian, could you please make a note of which version of JBoss AS you
want QE to regression-test this against. I'm assuming none, given the
issues you mentioned wrt. JBM and JGroups 2.6 yesterday...
Cheers,
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
18 years, 10 months
Notifications during state transfer WAS: [JBossCache] - Replication and notifications
by Manik Surtani
Not sure if this is a feature or a bug. Brian/Vladimir, do you recall
whether Node Modified notifications were specifically suppressed
during state transfer, and if so, why?
Cheers
Manik
Begin forwarded message:
> From: aditsu <do-not-reply(a)jboss.com>
> Date: 13 November 2007 09:14:11 GMT
> To: manik.surtani(a)jboss.com
> Subject: [JBossCache] - Replication and notifications
>
> Hi, I'm using JBC 2.0.0.GA (core)
> I set up 2 caches with REPL_SYNC and memory state fetching, and I
> added a listener to the 2nd cache before starting it.
> It looks like when fetching the memory state, the cache only fires
> NODE_CREATED notifications, which contain no data. However, when I
> put a new node afterwards, in either cache instance, I get a
> NODE_CREATED followed by a NODE_MODIFIED with the node data map.
> Is there a way to get the data while it is being fetched from a
> replicated cache?
>
> Thanks
> Adrian
>
> View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4103974#4103974
>
> Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4103974
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
18 years, 10 months
Critical CacheMarshaller issue
by Manik Surtani
A nasty bug, spotted by someone in the user forum (initially as a CCE)
http://jira.jboss.org/jira/browse/JBCACHE-1211
Copying from the JIRA:
"This is a nasty. What started life as an optimisation for certain
types of objects in a marshalled stream (Fqn, GlobalTransactio, String
and Serializable) has become a major limitation in that a single
stream can only hold up to 32767 different (not equal()) instances of
such objects.
Basically the optimisation was, for example, instead of writing
"hello" to a stream twice, just write it once and use a reference for
all subsequent times. Unfortunately this reference was encoded as a
short, hence the limitation of 32767.
Fixing this will definitely break wire compatibility with JBoss Cache
2.0.0, although JBC does allow backward compatibility by specifying
replication version in your configuration, thanks to the
VersionAwareMarshaller. "
So I guess this mandates the need for a CacheMarshaller210. The
question is how do we fix this. The obvious thing is to replace the
short references with integers. The 2 ^ 31 - 1 number of references
this would allow should be plenty! The drawback though, is larger
streams. 4-byte refs instead of 2-byte refs can be an unnecessary
overhead especially if objects aren't repeated much.
One thing we could do is just limit ref counting to Fqn and
GlobalTransaction types, of which we know can often be repeated in a
modification list, and where the optimisation can benefit, and assume
it isn't worth optimising in the same way for user data (Strings and
Serializables).
Or maybe we should drop the ref counting altogether, save a few more
bytes' worth of payload.
Thoughts?
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
18 years, 10 months
JBCACHE-1156 - configuration profiles
by Manik Surtani
Brian,
I had a look at what you checked in for this; it looks pretty good,
but why a package called 'registry'? This tends to make me think of
other things, like a component registry, perhaps something related to
DI even.
Regarding the methods you have, around getCacheNames, getCache,
releaseCache, etc., I wonder whether this should be a part of the
DefaultCacheFactory.
The bit on profiles - the ConfigurationRegistry as you called it -
makes sense to be separate though, since this is where profiles can be
saved/shared.
Thoughts?
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
18 years, 10 months
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 as
:
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.
18 years, 10 months