[JBoss JIRA] Updated: (JBCACHE-311) Refactor jbosscache to provide an interface for transport
by Manik Surtani (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-311?page=all ]
Manik Surtani updated JBCACHE-311:
----------------------------------
Fix Version/s: 3.0.0
(was: 2.2.0.GA)
Affects: [Documentation (Ref Guide, User Guide, etc.), Compatibility/Configuration] (was: [Compatibility/Configuration, Documentation (Ref Guide, User Guide, etc.)])
Priority: Major (was: Minor)
> Refactor jbosscache to provide an interface for transport
> ---------------------------------------------------------
>
> Key: JBCACHE-311
> URL: http://jira.jboss.com/jira/browse/JBCACHE-311
> Project: JBoss Cache
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Nick Betteridge
> Assigned To: Manik Surtani
> Fix For: 3.0.0
>
>
> There are many different transports available (jgroups, jboss remoting etc) which are available and which already exist within commnissioned systems. Further, clients requirements/project specification sometimes stipulates a specific transport to be used. JBossCache currently has JGroups embedded as the transport used. If BossCache was refactored to provide a generic transport interface, it would make JBossCache more 'user friendly' so that the features of JBossCache can be used within a greater variety of projects.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years
[JBoss JIRA] Commented: (JBCACHE-311) Refactor jbosscache to provide an interface for transport
by Manik Surtani (JIRA)
[ http://jira.jboss.com/jira/browse/JBCACHE-311?page=comments#action_12392319 ]
Manik Surtani commented on JBCACHE-311:
---------------------------------------
Approach:
1) Remove API dependencies on JGroups classes (see dependent JIRA)
2) RPCManager interface may need further fleshing out, RPCManagerImpl to be renamed to JGroupsRPCManager
3) Move callRemoteMethods and channel ownership to the RPCManager
4) Move all callbacks and remote RPC calls to the RPCManager which will then delegate to the actual cache.
> Refactor jbosscache to provide an interface for transport
> ---------------------------------------------------------
>
> Key: JBCACHE-311
> URL: http://jira.jboss.com/jira/browse/JBCACHE-311
> Project: JBoss Cache
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Reporter: Nick Betteridge
> Assigned To: Manik Surtani
> Priority: Minor
> Fix For: 2.2.0.GA
>
>
> There are many different transports available (jgroups, jboss remoting etc) which are available and which already exist within commnissioned systems. Further, clients requirements/project specification sometimes stipulates a specific transport to be used. JBossCache currently has JGroups embedded as the transport used. If BossCache was refactored to provide a generic transport interface, it would make JBossCache more 'user friendly' so that the features of JBossCache can be used within a greater variety of projects.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years
[JBoss JIRA] Created: (JBCACHE-1240) Option to create another copy of backup data if data owner dies
by Brian Stansberry (JIRA)
Option to create another copy of backup data if data owner dies
---------------------------------------------------------------
Key: JBCACHE-1240
URL: http://jira.jboss.com/jira/browse/JBCACHE-1240
Project: JBoss Cache
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Buddy Replication
Reporter: Brian Stansberry
Assigned To: Manik Surtani
With BR, if a data owner dies, the number of copies of the data it owns is reduced by one. If the data is accessed, another node becomes owner and the number of backups returns to normal. But if the data isn't accessed, the number of backups remains reduced.
Besides the general problem of lesser reliability for this data, this can be a problem with things like rolling upgrades, where all the backup nodes could be restarted before the data is accessed, leading to data loss.
Downside to making another copy of the backup data when the owner dies is it adds stress to the system by replicating more data. So, this should be configurable.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
17 years