[jbosscache-dev] Re: [javagroups-users] Considering migrating to jboss cache from DistributedTree
Bill Middleton
utvikler at gmail.com
Sun Apr 8 17:31:36 EDT 2007
Thanks for the encouraging reply, Brian. My followup is inline, and there's
a proposed patch at the end.
Bill
On 4/6/07, Brian Stansberry <brian.stansberry at redhat.com> wrote:
>
> Bill Middleton wrote:
> > A cursory (and likely naive) inspection of DefaultCacheFactory and
> > CacheImpl seems to indicate that providing my own channel should be
> > fairly easy to implement, even if an extension won't quite get the job
> > done, since channel is private. The intimidating part is the binding
> > between the "official" multiplexed channel (mbean) and other
> > functionality which implies a full app-server, such as the
> > TransactionManager.
>
> Not sure what you mean here by "binding". Passing a JChannelFactoryMBean
> to the RuntimeConfig doesn't carry with it a requirement to pass in a
> TransactionManager. Think of RuntimeConfig as basically being a
> placeholder through which the external environment can pass in complex
> objects the cache may need and through which callers can get access to a
> few of the cache internals.
Every test I run does insist upon looking for a TransactionManager, if one
isn't found then a DummyTransactionManager is the "fall back" solution.
Granted though, it's not bound to an app server.
> If I were to pass in a channel to CacheImpl,
> > whether multiplexed or not, I don't think I'll mess with
> > setUsingMultiplexer() and friends in the Configuration. Since I'm going
> > to manage the muliplexer functionality myself I guess it makes sense to
> > let Cache think that it's just a simple channel. This seems safe
> > enough, I hope.
> >
>
> Sure, as long as in reality it's a multiplexed channel, so the cache
> doesn't get messages it won't understand. If you're writing your own
> extensions, then presumably you know how the code will be used and can
> guard against misuse. So, the barrier for what's considered "safe" can
> be a lot lower. :)
My proposed patch doesn't require a multiplexed channel be passed in. The
implementation can pass in either an ordinary JChannel (via new JChannel())
or one that's created via createMultiplexerChannel(). All of the state
transfer tests pass in either case. In neither case is the Configuration
set using setUsingMultiplexer(true). isUsingMultiplexer is always false.
Seems to work ok - all tests pass using an adapted
StateTransferCompatibilityTest.java, anyhow.
Generally, my patch adds a new constructor, CacheImpl(Channel c). This is
called by a new createChannel() method in the DefaultChannelFactory which
accepts a channel, configuration, and boolean. If the new constructor is
used to construct a ChannelImpl, then a global boolean is set which makes
the create() method do the right thing at init-time.
Is this approach way too simple minded? It's not providing any additional
access to the internals of the cache per se, but yes, one must be careful in
configuring the channel. Whats still missing here is the ability to fetch
the entire Element <protocol_stacks> from the Configuration and pass it
directly to the JChannelFactory(Element) constructor, so that the external
JGroups stack would be guaranteed to match the one which is specified in the
config.
Bill
PS - sorry about the indentation in the patch, Eclipse cant quite figure
out the scheme that jbosscache is using.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbosscache-dev/attachments/20070408/9874e966/attachment.html
-------------- next part --------------
? patch
Index: CacheFactory.java
===================================================================
RCS file: /cvsroot/jboss/JBossCache/src/org/jboss/cache/CacheFactory.java,v
retrieving revision 1.7
diff -r1.7 CacheFactory.java
11a12
> import org.jgroups.Channel;
111a113,131
>
> /**
> * Creates {@link Cache} instance, by passing in a pre-configured {@link org.jgroups.JChannel}
> * and optionally starts it based on the boolean start value. The new cache's configuration
> * will be based on a {@link org.jboss.cache.config.Configuration} passed in.
> * <p/>
> * Ensure that the Configuration you pass in is not used by another cache instance in the same JVM,
> * as it may be concurrently modified. Clone the configuration, if shared, using
> * {@link org.jboss.cache.config.Configuration#clone()}.
> *
> * @param configuration the {@link org.jgroups.JChannel} to use (cast to simple channel).
> * @param configuration the {@link Configuration} object that is passed in to setCache the {@link Cache}.
> * @param start if true, the cache is started before returning.
> * @return an optionally running {@link Cache} instance
> * @throws org.jboss.cache.config.ConfigurationException
> * if there are problems with the configuration
> */
> Cache<K, V> createCache(Channel ch, Configuration configuration, boolean start) throws ConfigurationException;
>
Index: CacheImpl.java
===================================================================
RCS file: /cvsroot/jboss/JBossCache/src/org/jboss/cache/CacheImpl.java,v
retrieving revision 1.57
diff -r1.57 CacheImpl.java
238c238,245
<
---
>
> /**
> * Have we gotten a channel passed in from the
> * implementation? We set this to false in the
> * constructor if so. Ordinarily isMyChannel is always true.
> */
> private boolean isMyChannel = true;
>
260a268,282
> /**
> * Constructs an uninitialized CacheImpl with a provided channel
> */
> protected CacheImpl(Channel ch) throws Exception
> {
> isMyChannel = false;
> if(ch instanceof JChannel){
> channel = (JChannel)ch;
> }
> else{
> throw new Exception("Not a JChannel!");
> }
> notifier = new Notifier(this);
> regionManager = new RegionManager(this);
> }
643c665,669
< if (channel != null)
---
>
> // We have to test both the channel and disp here, in
> // case we've passed in our own channel. The dispatcher
> // must be created in either case.
> if ((channel != null) && (disp != null))
649,653c675,686
< // Try to create a multiplexer channel
< channel = getMultiplexerChannel();
<
< if (channel != null)
< {
---
> // Try to create a multiplexer channel if we didnt get a channel passed in
> if(isMyChannel){
> channel = getMultiplexerChannel();
> }
>
> if ((channel != null) && isMyChannel)
> {
>
> // Success creating the multiplexer channel.
> // Now we have to let the config know about our joy.
> // Note that we never do this if we've passed in a channel,
> // even if that channel is multiplexed.
676,680c709,712
< try
< {
< channel = new JChannel(configuration.getClusterConfig());
< }
< catch (Exception e)
---
>
> // If we've not passed in a channel
> // we need to create a non-multiplexed one now
> if (isMyChannel)
682,683c714,720
< throw new CacheException("Unable to create JGroups channel", e);
< }
---
> try {
> channel = new JChannel(configuration.getClusterConfig());
> } catch (Exception e) {
> throw new CacheException(
> "Unable to create JGroups channel", e);
> }
> }
Index: DefaultCacheFactory.java
===================================================================
RCS file: /cvsroot/jboss/JBossCache/src/org/jboss/cache/DefaultCacheFactory.java,v
retrieving revision 1.6
diff -r1.6 DefaultCacheFactory.java
11a12
> import org.jgroups.Channel;
102a104,135
> /**
> * This implementation clones the configuration passed in before using it.
> * It also allows the client to pass in its own channel.
> *
> * @param ch the pre-configured JChannel to use
> * @param configuration to use. We assume that the channel has been setup using this
> * @param start whether to start the cache
> * @return a cache
> * @throws ConfigurationException if there are problems with the cfg
> */
> public Cache<K, V> createCache(Channel ch, Configuration configuration, boolean start) throws ConfigurationException
> {
> try
> {
> CacheImpl<K, V> cache = new CacheImpl<K, V>(ch);
> cache.setConfiguration(configuration);
> if (start) cache.start();
> return cache;
> }
> catch (ConfigurationException ce)
> {
> throw ce;
> }
> catch (RuntimeException re)
> {
> throw re;
> }
> catch (Exception e)
> {
> throw new RuntimeException(e);
> }
> }
More information about the jbosscache-dev
mailing list