[JBoss JIRA] Created: (JBCACHE-1226) State transfer doesn't clean out persistent store if size of transferred persistent state is 0
by Brian Stansberry (JIRA)
State transfer doesn't clean out persistent store if size of transferred persistent state is 0
----------------------------------------------------------------------------------------------
Key: JBCACHE-1226
URL: http://jira.jboss.com/jira/browse/JBCACHE-1226
Project: JBoss Cache
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Cache loaders
Affects Versions: 1.4.1.SP7
Reporter: Brian Stansberry
Assigned To: Manik Surtani
Priority: Minor
StateTransferIntegrator_140.integratePersistentState() is a no-op if the size of the provided persistent state is 0. So, if persistent state transfer is enabled but the provider doesn't have any persistent state to transfer, any stale persistent state laying around on the recipient will not get cleaned up.
A fix for this needs to properly discriminate between the above case and one where no persistent state is available because persistent state transfer is disabled.
Manik, I found this when a solution to an EJB3 bug didn't work as expected. I can tweak my solution to get around it, so this isn't urgent for me. Feel free to assign to me, although I likely won't get to it for a long time.
This likely affects all releases in the 1.x series. A *quick* look at how this works leads me to expect it's not an issue in 2.x.
--
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
18 years, 4 months
[JBoss JIRA] Created: (JBBUILD-378) Research options for testing dependency version ranges
by Paul Gier (JIRA)
Research options for testing dependency version ranges
------------------------------------------------------
Key: JBBUILD-378
URL: http://jira.jboss.com/jira/browse/JBBUILD-378
Project: JBoss Build System
Issue Type: Task
Components: Maven
Reporter: Paul Gier
Fix For: MavenBuild 2007
It would be helpful to be able to automatically run a maven build with each of the valid combinations of dependency versions. For example, if a dependency includes a version range of 1.1, 1.2, and 1.3. We would want to build and test the project using each of these versions to make sure that they all work correctly.
Sherriff on the maven forum has worked on something like this for continuum. When we move our automated builds to hudson, maybe we could create something similar to this.
--
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
18 years, 4 months
[JBoss JIRA] Created: (JGRP-628) Discovery: add cluster name to discovery request to be able to discard responses from different clusters
by Bela Ban (JIRA)
Discovery: add cluster name to discovery request to be able to discard responses from different clusters
--------------------------------------------------------------------------------------------------------
Key: JGRP-628
URL: http://jira.jboss.com/jira/browse/JGRP-628
Project: JGroups
Issue Type: Feature Request
Reporter: Bela Ban
Assigned To: Bela Ban
Fix For: 2.6.1, 2.7
When we have 2 groups ONE and TWO:
ONE: 228.8.8.8:7500 and
TWO: 228.1.2.3:7500
In some cases, they will receive each other's traffic (http://wiki.jboss.org/wiki/Wiki.jsp?page=PromiscuousTraffic).
Assume ONE has members {A,B,C} and TWO has no members yet. When D (in cluster TWO) starts up and sends out a discovery request, it might also receive discovery responses from ONE (A,B,C). D might now identify A as coordinator and send a JOIN-REQ to A. However, A will discard that request as the group name of D's request is TWO rather than ONE !
Result: D's JOIN-REQ will hang !
Note that the transport (TP) does drop messages from different clusters, but this happens only after the new member has joined the group, so discovery requests/responses from different groups are *not* discarded.
Tasks:
- Verify that the transport-name matching algorithm in TP is correct
- Confirm that - on initial discovery - discovery requests and responses are not matched
--
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
18 years, 4 months