-
1. Re: Refactoring out jgroups
buzzheavyyear Oct 3, 2005 10:40 AM (in response to buzzheavyyear)Sorry - forgot to mention that we're quite intested in using the remoting framework with this.
Buzz -
2. Re: Refactoring out jgroups
belaban Oct 3, 2005 12:26 PM (in response to buzzheavyyear)You mean JBossCache, not JCache... :-)
Yes, we're looking into refactoring the ReplicationInterceptor, so that the JChannel will be moved into it from TreeCache.
Then you can simply subclass the ReplicationInterceptor. -
3. Re: Refactoring out jgroups
buzzheavyyear Oct 3, 2005 12:34 PM (in response to buzzheavyyear)Oops, yes, JBossCache
Excellent ... I shouldn't ask, but any idea of timeframe? -
4. Re: Refactoring out jgroups
belaban Oct 3, 2005 12:54 PM (in response to buzzheavyyear)In order to do Buddy Replication (http://jira.jboss.com/jira/browse/JBCACHE-61), we will need to move JChannel from TreeCache into the ReplicationInterceptor.
Once we have this done, we can think of providing a neutral transport.
Although: IMO Remoting is not the best approach for multipoint message distribution, Remoting is point-to-point. -
5. Re: Refactoring out jgroups
buzzheavyyear Oct 3, 2005 1:06 PM (in response to buzzheavyyear)Agreed, but in some cases, and we have a couple of cases, multicast isn't feasible.
It would be nice if you came up with something that provided an interface for any form of transport ... sorry, I'm stating the obvious! Remoting itself is a point in case as we have been able to provide a number of transports (most of them homebrewed) when ip multicast wasn't available.
.... and finding a solution, even point2point, when nothing else is permissible, keeps the bosses happy! -
6. Re: Refactoring out jgroups
manik Oct 3, 2005 1:21 PM (in response to buzzheavyyear)Hi,
There are no plans at the moment to remove the direct dependency on JGroups, either by switching to another transport layer or adding an interface layer to allow such switching.
To the best of my knowledge, there are no such plans in the future either, although if there is enough community interest in having the transport layer abstracted away, this may happen.
I do see the value in having in abstracted though, so that people could write alternate transports if they have such a need. I'd recommend making a feature request on JBossCache's JIRA http://jira.jboss.com/jira/browse/JBCACHEand see where that goes. -
7. Re: Refactoring out jgroups
manik Oct 3, 2005 1:24 PM (in response to buzzheavyyear)Just to add, what I see is a TransportProvider interface that the existing ReplicationInterceptor would use, and this would default to a JGroupsTransportProvider. You would then just have to create a new TransportProvider rather than subclass the ReplicationInterceptor.
-
8. Re: Refactoring out jgroups
buzzheavyyear Oct 3, 2005 1:39 PM (in response to buzzheavyyear)Yes, agreed.
Would you like me to make the request, or should somebody that is a little more knowledgable about the JBossCache internals make the request? -
9. Re: Refactoring out jgroups
manik Oct 3, 2005 1:49 PM (in response to buzzheavyyear)Go ahead and make the request; like I said though I cannot promise when this may be scheduled to be done.
-
10. Re: Refactoring out jgroups
belaban Oct 4, 2005 1:15 AM (in response to buzzheavyyear)"buzzheavyyear" wrote:
Agreed, but in some cases, and we have a couple of cases, multicast isn't feasible.
It would be nice if you came up with something that provided an interface for any form of transport ... sorry, I'm stating the obvious!
JGroups :-) You can use JGroups without IP multicast, check out www.jgroups.org for details.
Remoting itself is a point in case as we have been able to provide a number of transports (most of them homebrewed) when ip multicast wasn't available.
.... and finding a solution, even point2point, when nothing else is permissible, keeps the bosses happy!
Write a transport in JGroups then... -
11. Re: Refactoring out jgroups
aubergine Oct 4, 2005 3:30 AM (in response to buzzheavyyear)We have a number of transports already which are part of different framworks. We are also contrained to use transports/frameworks in some projects which aren't ours and it's simply not possible to use JGroups (sorry)
This is the reason why I originally started this topic, otherwise we would be quite happy to use JGroups.