[jbosscache-dev] Re: [javagroups-users] Considering migrating to jboss cache from DistributedTree
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(a)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.
Attachments:
- patch.txt (text/plain — 5.3 KB)
- attachment.html (text/html — 4.0 KB)