JGroups Shared Transport support in JBC
by Brian Stansberry
In JGroups 2.6.2, the JGroups team is introducing the shared transport
as a (superior) alternative to the multiplexer. Want to touch off a
discussion of how to take advantage of that in JBC.
Currently in JBC, user can inject a ChannelFactory into their cache
configuration, and configure a MultiplexerStack (string). If both are
set, JBC calls ChannelFactory.createMultiplexerChannel(), which returns
a MuxChannel.
So, how can JBC get a regular JChannel w/ a shared transport instead of
a MuxChannel? Couple solutions come to mind:
1) Add a configuration property ChannelStack to the JBC config. If
present, JBC calls JChannelFactory.createChannel(String) instead of
ChannelFactory.createMultiplexerChannel(). Basically, the user
indicates what they want by how they configure. This IMHO is the
cleanest and simplest.
Problem is the createChannel(String) method is not exposed in the
ChannelFactory interface; it's only in the JChannelFactory
implementation. JBC needs to use the interface. Bela, can this method
be added to the interface in 2.6.2?
If it can be, any thoughts switching JBC 2.1 to use 2.6.2 and adding the
property?[1]
2) A hackier alternative is to override the behavior of
createMulitiplexerChannel so it checks the specified protocol stack
config and returns a regular JChannel if the stack uses a shared
transport; a MuxChannel otherwise. AS 5 already uses a custom
ChannelFactory impl (for other reasons); doing this is how I plan to get
shared transport support in AS 5. I suppose doing the same thing in the
standard org.jgroups.JChannelFactory class is possible, although I don't
advocate it at all; it seems hacky. Better IMO to adapt channel factory
users to call the correct method.
[1] Note that the hacky #2 approach is very likely to remain in AS 5
since JBM has the same usage as current JBC. So, getting this in JBC 2.1
is not a requirement for AS 5, just a "nice to have", something that if
done now can avoid future compatibility issues, etc.
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
16 years, 1 month
- 2
- 5
JBoss serialization - does anyone still use this?
by Manik Surtani
Does anyone still use the JBoss serialization flag with JBoss Cache?
Can support for this be ditched now? The reason I ask is I have
implemented a new set of input and output streams for the marshaller
to use, and these are based on the JDK OOS/OIS.
I *could* make these work with JBoss serialization as well, but that
is unnecessary code I'd rather not have to maintain.
Thoughts?
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
16 years, 2 months
- 2
- 3
Config files
by Manik Surtani
From the conf call yesterday:
Currently the XML config parser looks for a <mbean ../> element, under
which it pulls out more specific JBoss Cache elements.
I could easily change the parser to accept this, or on failing to do
so, to pick up a <jbosscache ... /> container element. Perhaps even
log a deprecation warning when using the old <mbean ... /> container
tag.
This would affect a few things though:
1) We ought to then update all sample configs and docs to reflect this
"new" element
2) Document how the configuration will still accept old <mbean ... />
tags
3) Document how the <mbean ... /> tag can cause problems with AS 5
(unintentional deployment), and how this can be done properly with the
MC.
The question is, is this something we ought to defer for 3.0? Or is
this critical enough to move to 2.1? In terms of effort, this isn't
that great; in terms of risk, we already have a simple solution to
overcome unintentional deployment (don't package the sample configs
with jbosscache-core.jar, but package them in jbosscache-core-
tests.jar for PojoCache)
Thoughts?
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org
16 years, 2 months
- 2
- 2
- ← Newer
- 1
- Older →