Refactoring out jgroups

[buzzheavyyear]

Hi

We're looking at JCache to use it standalone in a number of projects.

This is just a question to ask if JGroups will ever be factored out and replaced with a
'transport' interface so that other transports can be used instead.

Thanks in advance for any feedback on this

Sincerely

Buzz

[buzzheavyyear]

Sorry - forgot to mention that we're quite intested in using the remoting framework with this.

Buzz

[belaban]

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.

[buzzheavyyear]

Oops, yes, JBossCache

Excellent ... I shouldn't ask, but any idea of timeframe?

[belaban]

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.

[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!

[manik]

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.

[manik]

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.

[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?

[manik]

Go ahead and make the request; like I said though I cannot promise when this may be scheduled to be done.

[belaban]

"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...

[aubergine]

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.