2:08 p.m.
Fix DistributedStateImpl.nodeRemove
-----------------------------------
Key: JBAS-3473
URL: http://jira.jboss.com/jira/browse/JBAS-3473
Project: JBoss Application Server
Issue Type: Task
Security Level: Public (Everyone can see)
Components: Clustering
Reporter: Brian Stansberry
Assigned To: Brian Stansberry
Fix For: JBossAS-5.0.0.Beta
AFAICT, this is not correct. Key/value pairs are stored in the category node's data
map; nodeRemoved treats things as if each key is its own node.
Actually, I think the node per key approach is correct, until TreeCacheListener can
provide info on what data was changed.
Also, remove() itself notifies listeners of a removal, and then the listener does as well.
Needs to be one or the other; probably nodeRemoved() as that gets called for both local
and remote removes.
--
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
12:08 p.m.
New subject: [JBoss JIRA] Assigned: (JBAS-3473) Fix DistributedStateImpl.nodeRemove
[ http://jira.jboss.com/jira/browse/JBAS-3473?page=all ]
Jerry Gauthier reassigned JBAS-3473:
------------------------------------
Assignee: Jerry Gauthier (was: Brian Stansberry)
Fix DistributedStateImpl.nodeRemove
-----------------------------------
Key: JBAS-3473
URL: http://jira.jboss.com/jira/browse/JBAS-3473
Project: JBoss Application Server
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Clustering
Reporter: Brian Stansberry
Assigned To: Jerry Gauthier
Fix For: JBossAS-5.0.0.Beta
AFAICT, this is not correct. Key/value pairs are stored in the category node's data
map; nodeRemoved treats things as if each key is its own node.
Actually, I think the node per key approach is correct, until TreeCacheListener can
provide info on what data was changed.
Also, remove() itself notifies listeners of a removal, and then the listener does as
well. Needs to be one or the other; probably nodeRemoved() as that gets called for both
local and remote removes.
--
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
2:16 p.m.
New subject: [JBoss JIRA] Commented: (JBAS-3473) Fix DistributedStateImpl.nodeRemove
[ http://jira.jboss.com/jira/browse/JBAS-3473?page=comments#action_12346033 ]
Jerry Gauthier commented on JBAS-3473:
--------------------------------------
I've modified DistributedStateImpl so that it no longer issues duplicate
notifications. This change has been checked in.
This issue remains open due to problems with listeners that broadcast modification and
removal events from remote nodes. Final resolution of these issues depends on how
JBossCache handles JBCACHE-388. Currently JBossCache only broadcasts changes to Nodes and
the cache-based DistributedState implementation maps Nodes to categories. The JBossCache
notifications don't specify what changes have been made to Nodes so
DistributedStateImpl can't determine what keys have been modified or removed. Since
DistributedStateImpl relies on JBossCache to notify it of changes on remote cluster nodes,
it's unable to broadcast events properly.
There are three possible solutions here.
1) JBossCache 2.0 *may* specify what's changed when a node is modified. See
JBCACHE-388 for further details on this. If this information is available,
DistributedState can simply rebroadcast the notifications received from JBossCache.
2) JBossCache provides "pre" and "post" event notifications.
DistributedState could retrieve the two maps and differentiate them to determine what data
elements have been modified or removed.
3) DistributedState currently stores categories as nodes in JBossCache. Keys are then
stored as data elements in maps associated with the nodes. Keys could alternatively be
stored as nodes with each key having a map with the key and value stored in it. This
would be a less efficient use of JBossCache but it would ensure that DistributedState can
identify key changes made on remote nodes.
Note that this issue only applies to notifications related to changes made on remote
nodes. Changes made on a local node are broadcast directly from DistributedSate and any
local events received from JBossCache are simply ignored.
Fix DistributedStateImpl.nodeRemove
-----------------------------------
Key: JBAS-3473
URL: http://jira.jboss.com/jira/browse/JBAS-3473
Project: JBoss Application Server
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Clustering
Reporter: Brian Stansberry
Assigned To: Jerry Gauthier
Fix For: JBossAS-5.0.0.Beta
AFAICT, this is not correct. Key/value pairs are stored in the category node's data
map; nodeRemoved treats things as if each key is its own node.
Actually, I think the node per key approach is correct, until TreeCacheListener can
provide info on what data was changed.
Also, remove() itself notifies listeners of a removal, and then the listener does as
well. Needs to be one or the other; probably nodeRemoved() as that gets called for both
local and remote removes.
--
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
10:30 a.m.
New subject: [JBoss JIRA] Updated: (JBAS-3473) Fix DistributedStateImpl.nodeRemove
[ http://jira.jboss.com/jira/browse/JBAS-3473?page=all ]
Dimitris Andreadis updated JBAS-3473:
-------------------------------------
Fix Version/s: JBossAS-5.0.0.Beta2
(was: JBossAS-5.0.0.Beta1)
Fix DistributedStateImpl.nodeRemove
-----------------------------------
Key: JBAS-3473
URL: http://jira.jboss.com/jira/browse/JBAS-3473
Project: JBoss Application Server
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Clustering
Reporter: Brian Stansberry
Assigned To: Jerry Gauthier
Fix For: JBossAS-5.0.0.Beta2
AFAICT, this is not correct. Key/value pairs are stored in the category node's data
map; nodeRemoved treats things as if each key is its own node.
Actually, I think the node per key approach is correct, until TreeCacheListener can
provide info on what data was changed.
Also, remove() itself notifies listeners of a removal, and then the listener does as
well. Needs to be one or the other; probably nodeRemoved() as that gets called for both
local and remote removes.
--
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
1:29 p.m.
New subject: [JBoss JIRA] Closed: (JBAS-3473) Fix DistributedStateImpl.nodeRemove
[ http://jira.jboss.com/jira/browse/JBAS-3473?page=all ]
Jerry Gauthier closed JBAS-3473.
--------------------------------
Fix DistributedStateImpl.nodeRemove
-----------------------------------
Key: JBAS-3473
URL: http://jira.jboss.com/jira/browse/JBAS-3473
Project: JBoss Application Server
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Clustering
Reporter: Brian Stansberry
Assigned To: Jerry Gauthier
Fix For: JBossAS-5.0.0.Beta2
AFAICT, this is not correct. Key/value pairs are stored in the category node's data
map; nodeRemoved treats things as if each key is its own node.
Actually, I think the node per key approach is correct, until TreeCacheListener can
provide info on what data was changed.
Also, remove() itself notifies listeners of a removal, and then the listener does as
well. Needs to be one or the other; probably nodeRemoved() as that gets called for both
local and remote removes.
--
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
1:29 p.m.
New subject: [JBoss JIRA] Resolved: (JBAS-3473) Fix DistributedStateImpl.nodeRemove
[ http://jira.jboss.com/jira/browse/JBAS-3473?page=all ]
Jerry Gauthier resolved JBAS-3473.
----------------------------------
Resolution: Done
Fixed based upon changes in JBCACHE-595
Fix DistributedStateImpl.nodeRemove
-----------------------------------
Key: JBAS-3473
URL: http://jira.jboss.com/jira/browse/JBAS-3473
Project: JBoss Application Server
Issue Type: Task
Security Level: Public(Everyone can see)
Components: Clustering
Reporter: Brian Stansberry
Assigned To: Jerry Gauthier
Fix For: JBossAS-5.0.0.Beta2
AFAICT, this is not correct. Key/value pairs are stored in the category node's data
map; nodeRemoved treats things as if each key is its own node.
Actually, I think the node per key approach is correct, until TreeCacheListener can
provide info on what data was changed.
Also, remove() itself notifies listeners of a removal, and then the listener does as
well. Needs to be one or the other; probably nodeRemoved() as that gets called for both
local and remote removes.
--
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
6488
days inactive
6653
days old
5 comments
3 participants
participants (3)
-
Brian Stansberry (JIRA) -
Dimitris Andreadis (JIRA)
-
Jerry Gauthier (JIRA)