Bug 793705 (JBEPP-780) - PicketLink should use separate cache cluster names for apiCacheConfig and storeCacheConfig
Summary: PicketLink should use separate cache cluster names for apiCacheConfig and sto...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: JBEPP-780
Product: JBoss Enterprise Portal Platform 5
Classification: JBoss
Component: Portal
Version: 5.1.0.GA
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 5.1.1.DEV03
Assignee: hfnukal@redhat.com
QA Contact:
URL: http://jira.jboss.org/jira/browse/JBE...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-01-26 21:32 UTC by Martin Weiler
Modified: 2011-10-26 08:53 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-24 08:44:28 UTC
Type: Task


Attachments (Terms of Use)
JBEPP-780.patch (2.31 KB, text/x-patch)
2011-04-19 15:12 UTC, Martin Weiler
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 793658 0 high CLOSED Leverage the EAP parameter jboss.default.jgroups.stack to make switching to TCP easier 2021-02-22 00:41:40 UTC
Red Hat Issue Tracker JBEPP-780 0 Major Closed PicketLink should use separate cache cluster names for apiCacheConfig and storeCacheConfig 2014-07-17 15:10:43 UTC

Internal Links: 793658

Description Martin Weiler 2011-01-26 21:32:17 UTC
Help Desk Ticket Reference: https://na7.salesforce.com/500A0000005ezKT
project_key: JBEPP

The two JBoss Cache instances created by PicketLink are using the same cluster names, as they are both pointing to the same config file in idm-configuration.xml:

      <value-param profiles="cluster">
        <name>apiCacheConfig</name>
        <value>war:/conf/organization/picketlink-idm/jboss-cache-cluster.xml</value>
      </value-param>

      <value-param profiles="cluster">
        <name>storeCacheConfig</name>
        <value>war:/conf/organization/picketlink-idm/jboss-cache-cluster.xml</value>
      </value-param>

This can lead to conflicts as the same JBoss instance is joining the same channel twice, so either two different config files are provided, or a different 'clusterName' attribute is being used in the jboss-cache-cluster.xml config file.

Comment 1 Martin Weiler 2011-01-26 21:33:03 UTC
Link: Added: This issue related JBEPP-736


Comment 2 boleslaw.dawidowicz 2011-04-06 13:36:17 UTC
Link: Added: This issue depends GTNPORTAL-1853


Comment 3 hfnukal@redhat.com 2011-04-14 14:25:45 UTC
Resolved with JBEPP-779

Comment 4 Martin Weiler 2011-04-19 15:11:28 UTC
Reopening as the jboss-cache-api-cluster.xml and jboss-cache-store-cluster.xml files are missing from EPP_5_1_Branch

Comment 5 Martin Weiler 2011-04-19 15:12:49 UTC
Attaching patch proposal to add the two missing *cluster.xml files for IDM.

Comment 6 Martin Weiler 2011-04-19 15:12:49 UTC
Attachment: Added: JBEPP-780.patch


Comment 7 hfnukal@redhat.com 2011-04-22 10:55:45 UTC
Release Notes Docs Status: Added: Documented as Known Issue
Release Notes Text: Added: Two JBoss Cache instances used single config file. Two config files were created and configurationn was customized.


Comment 8 Scott Mumford 2011-04-29 02:16:32 UTC
Should this still be marked as a Known Issue?
The problem causing the issue seems to have been corrected and the JIRA re-opened for a different reason
(if I'm understanding the comments correctly) 

Comment 9 Scott Mumford 2011-04-29 02:16:32 UTC
Release Notes Text: Removed: Two JBoss Cache instances used single config file. Two config files were created and configurationn was customized. Added: Cause: The two JBoss Cache instances created by PicketLink were calling on the same configuration file in idm-configuration.xml and, as a result, were using the same cluster names.
Consequence: This could lead to conflicts as the same JBoss Cache instance could join the same channel twice.
Fix: Two configuration files were created and added to the distribution package and the Portal configuration was customized to call on the different files. 
Result: JBoss Cache instances can now run simultaneously without conflict.


Comment 10 Scott Mumford 2011-05-03 04:04:01 UTC
Release Notes Docs Status: Removed: Documented as Known Issue Added: Documented as Resolved Issue


Comment 11 Scott Mumford 2011-05-04 04:05:58 UTC
Release Notes Text: Removed: Cause: The two JBoss Cache instances created by PicketLink were calling on the same configuration file in idm-configuration.xml and, as a result, were using the same cluster names.
Consequence: This could lead to conflicts as the same JBoss Cache instance could join the same channel twice.
Fix: Two configuration files were created and added to the distribution package and the Portal configuration was customized to call on the different files. 
Result: JBoss Cache instances can now run simultaneously without conflict. Added: The two JBoss Cache instances created by PicketLink were calling on the same configuration file in idm-configuration.xml and, as a result, were using the same cluster names. This could lead to conflicts as the same JBoss Cache instance could join the same channel twice. Separate configuration files were added to the distribution package and the Portal configuration was customized to call on the different files. JBoss Cache instances can now run simultaneously without conflict.


Comment 12 mposolda 2011-05-06 13:18:54 UTC
What about removing the file web/portal/src/main/webapp/WEB-INF/conf/organization/picketlink-idm/jboss-cache-cluster.xml ?
I think this can be removed because not-cluster profile is using "jboss-cache.xml" and cluster profile is using two mentioned  files "jboss-cache-api-cluster.xml" and "jboss-cache-store-cluster.xml" .

I am not reopening since it is only a minor thing.

Comment 13 mposolda 2011-05-10 11:50:15 UTC
Reopening as discussed with Honza. More info in previous comment.

Comment 14 hfnukal@redhat.com 2011-06-24 08:44:28 UTC
Remove unused file

Comment 15 mposolda 2011-10-26 08:53:12 UTC
Link: Added: This issue is related to GTNPORTAL-2234



Note You need to log in before you can comment on or make changes to this bug.