Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1358838 - [GSS](6.4.z) jboss-web.xml <replication-config> and the default cache setting in the EAP HA xml config file
Summary: [GSS](6.4.z) jboss-web.xml <replication-config> and the default cache settin...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Infinispan
Version: 6.4.6
Hardware: Unspecified
OS: Unspecified
unspecified
urgent
Target Milestone: ---
: ---
Assignee: Petr Jurak
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-21 15:06 UTC by Shay Matasaro
Modified: 2016-08-22 19:12 UTC (History)
6 users (show)

Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-08-22 19:12:03 UTC
Type: Bug


Attachments (Terms of Use)
test war file (deleted)
2016-07-21 15:07 UTC, Shay Matasaro
no flags Details

Description Shay Matasaro 2016-07-21 15:06:40 UTC
When using jboss-web.xml to override cache settings, the cache name is not used and  likely other custom cache settings are not being processed.


I tested both 6.4. and 6.1.0 and the issue exists in both 

reproducible every time


Steps to Reproduce:
1. adjust the web cache container in standalone-ha.xml to the following :
<cache-container name="web" aliases="standard-session-cache" default-cache="repl" module="org.jboss.as.clustering.web.infinispan">
                <transport lock-timeout="60000"/>
                <replicated-cache name="repl" mode="ASYNC" batching="true">
                    <file-store relative-to="jboss.home.dir" path="noaccess/foo" shared="false" passivation="true" purge="true"/>
                </replicated-cache>
                <replicated-cache name="sso" mode="SYNC" batching="true"/>
                <distributed-cache name="dist" l1-lifespan="0" mode="ASYNC" batching="true">
                    <file-store/>
                </distributed-cache>
            </cache-container>

2. create a directory in jboss-home called 'noaccess'
3. chmod 0 noacess
4. deploy the attached war file which includes a jboss-web with settings for web.dist


Actual results:
The deploy fails because the default cache(repl) is being started instead of the one pointed to by the war('dist')


Expected results:
the repl cache should not be started , only the dist cache should be used

Comment 1 Shay Matasaro 2016-07-21 15:07:36 UTC
Created attachment 1182553 [details]
test war file

Comment 6 Shay Matasaro 2016-08-17 13:40:45 UTC
Sorry for the delay in responding, I was out of office .

According to your testing the the settings from jboss-web.xml do not actually overwrite the cache that is defined in standalone-ha, they are used to define and create a new cache , but the cache that is defined in standalone is still started.

What is the standalone-ha cache used for ?
Should it even be started ?

Comment 8 Shay Matasaro 2016-08-18 19:22:34 UTC
We need either to open a a new bug report to discuss the default cache , or simply change the title and the focus for this one , since a new bug wasn't created we can continue the discussion here.

I'll revise the title of this bug to avoid confusion.


The main items are :
- If each <distributable> application gets its own cache instance , what is the "default" cache used for ? if anything at all?

- If the default cache is not used, why is it being started? (bug?)

Based on the above , we should also update and fix any documentation that  relates to <replication-settings> since none of them discuss and explain these aspects.

Comment 11 Brad Maxwell 2016-08-22 19:12:03 UTC
Closing, the issue was misidentified, so closing this bz, if there is a new issue identified we will open a new bz


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