[JBoss JIRA] (WFLY-12486) Memory leak in OpenTracing when deployment is redeployed multiple times
by Jan Stourac (Jira)
Jan Stourac created WFLY-12486:
----------------------------------
Summary: Memory leak in OpenTracing when deployment is redeployed multiple times
Key: WFLY-12486
URL: https://issues.jboss.org/browse/WFLY-12486
Project: WildFly
Issue Type: Bug
Components: MP OpenTracing
Affects Versions: 17.0.1.Final, 17.0.0.Final
Reporter: Jan Stourac
Assignee: Jeff Mesnil
Attachments: memory-leak-bad.png, memory-leak-good.png
There seems to be a memory leak when a deployment is redeployed multiple times (100 times in our test). This is very similar to what has been described in WFLY-10991. Also first commit this started to happen is [this one|https://github.com/wildfly/wildfly/commit/74170b5f49dd83f6b9ebd489f85...] - JaegerTracing and Apache Thrift dependencies update. Thus I selected MP OpenTracing component for this issue.
Test and deployment is same as is described in WFLY-10991.
Size of the extra heap in use is about 27MB plus when compared to the initial size before multiple redeploy operations.
I've tried to check manually via [visualVM|https://visualvm.github.io/] tool. Screenshot with suspicious jaegertracing instances are attached - there are much more jaegertracing class instances with new version of Jager Tracing and Apache Thrift dependencies, which is suspicious.
Interesting thing is that when microprofile-opentracing-smallrye subsystem is removed via:
{code}
/subsystem=microprofile-opentracing-smallrye:remove()
{code}
the memory leak is still present. This is kind of confusing to me.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-12462) Incompatible conflicting binding Exception and EJB naming
by Alexey Usharovski (Jira)
[ https://issues.jboss.org/browse/WFLY-12462?page=com.atlassian.jira.plugin... ]
Alexey Usharovski commented on WFLY-12462:
------------------------------------------
[~jaikiran] thanks a lot! Going to try that ASAP.
> Incompatible conflicting binding Exception and EJB naming
> ---------------------------------------------------------
>
> Key: WFLY-12462
> URL: https://issues.jboss.org/browse/WFLY-12462
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Affects Versions: 17.0.1.Final
> Environment: MacOS High Sierra
> Reporter: Alexey Usharovski
> Assignee: Cheng Fang
> Priority: Minor
> Attachments: server.log.zip, simplewebapp-lesson-6-ejb.zip, war-content.txt.zip
>
>
> Wired exception for very simple EJB with @Remote annotated interface in time of deploy to WildFly 17.0.1.Final
> {code:java}
> @Stateless
> public class UserServiceImpl implements UserServiceRemote {
> @Override
> public List<UserRepr> getAllUsers() {
> return null;
> }
> }
> @Remote
> public interface UserServiceRemote {
> List<UserRepr> getAllUsers();
> }
> {code}
> The exception is
> {code}
> Caused by: java.lang.IllegalArgumentException: WFLYEE0047: Incompatible conflicting binding at java:jboss/exported/simple-webapp/UserServiceImpl!ru.geekbrains.jsf.UserServiceRemote
> source: org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor$2@6aba1c4b"},
> "WFLYCTL0412: Required services that are not installed:" => [ "jboss.deployment.unit.\"simple-webapp.war\".beanmanager", "jboss.deployment.unit.\"simple-webapp.war\".WeldStartService" ],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => [ "jboss.deployment.unit.\"simple-webapp.war\".batch.artifact.factory is missing [jboss.deployment.unit.\"simple-webapp.war\".beanmanager]",
> "jboss.deployment.unit.\"simple-webapp.war\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"simple-webapp.war\".beanmanager, jboss.deployment.unit.\"simple-webapp.war\".WeldStartService]" ] }
> {code}
> Notice that problem could be resolved by undeploy and Wildfly server restart. May be something wrong with JNDI content?
> I've tried to look through the web console but found nothing interesting.
> Full application code on GitHub https://github.com/usharik/simplewebapp/tree/lesson-6-ejb
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-12462) Incompatible conflicting binding Exception and EJB naming
by Jaikiran Pai (Jira)
[ https://issues.jboss.org/browse/WFLY-12462?page=com.atlassian.jira.plugin... ]
Jaikiran Pai commented on WFLY-12462:
-------------------------------------
[~usharik], I have followed almost the exact steps that you mention with the application that you shared. I haven't used maven WildFly plugin for deployment, but I have manually copied the war into the standalone/deployments directory when the server was up and running. I haven't see any issues. I don't think the Maven WildFly plugin is playing a role in this.
So I went and looked in a bit more detail, the WildFly code where this java:jboss/exported bindings are done for the EJBs (it's in org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor). Unlike other bindings, this one has some special code to handle the binding, so it's one hint that there might really be a potential issue here. The code here uses a "wrapped" binding depending on whether or not "request-controller" subsystem is active. Default installations of WildFly have that subsystem active. Then, there's another piece of code (org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor) where there's a check for equality for the "source" of these bindings and that's where this check is failing and logging the exception for you:
{quote}
Caused by: java.lang.IllegalArgumentException: WFLYEE0047: Incompatible conflicting binding at java:jboss/exported/simple-webapp/UserServiceImpl!ru.geekbrains.jsf.UserServiceRemote source: org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor$2@73fbe2f8
at org.jboss.as.ee@17.0.1.Final//org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.addJndiBinding(ModuleJndiBindingProcessor.java:298)
at org.jboss.as.ee@17.0.1.Final//org.jboss.as.ee.component.deployers.ModuleJndiBindingProcessor.deploy(ModuleJndiBindingProcessor.java:122)
at org.jboss.as.server@9.0.2.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:176)
... 8 more
{quote}
It's been a while since I have looked into this code so I have more than one question (for myself) to understand what this code is doing and why, but there seem to be enough hints to suggest that you might indeed be running into some sort of a bug.
We might need your help to debug this further. Is this consistently reproducible for you? If yes, it's a good sign. In that case, can you edit your standalone-full.xml file which currently will have something like this:
{code}
<subsystem xmlns="urn:jboss:domain:request-controller:1.0"/>
{code}
As a first step, stop your server, then edit this file and delete that line from that file. Then start your server and deploy the application. Let us know what happens and whether or not your application deployment succeeds. Try it a few times to get some consistent results.
It won't solve anything but will give us enough hints to focus in the right place.
> Incompatible conflicting binding Exception and EJB naming
> ---------------------------------------------------------
>
> Key: WFLY-12462
> URL: https://issues.jboss.org/browse/WFLY-12462
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EJB
> Affects Versions: 17.0.1.Final
> Environment: MacOS High Sierra
> Reporter: Alexey Usharovski
> Assignee: Cheng Fang
> Priority: Minor
> Attachments: server.log.zip, simplewebapp-lesson-6-ejb.zip, war-content.txt.zip
>
>
> Wired exception for very simple EJB with @Remote annotated interface in time of deploy to WildFly 17.0.1.Final
> {code:java}
> @Stateless
> public class UserServiceImpl implements UserServiceRemote {
> @Override
> public List<UserRepr> getAllUsers() {
> return null;
> }
> }
> @Remote
> public interface UserServiceRemote {
> List<UserRepr> getAllUsers();
> }
> {code}
> The exception is
> {code}
> Caused by: java.lang.IllegalArgumentException: WFLYEE0047: Incompatible conflicting binding at java:jboss/exported/simple-webapp/UserServiceImpl!ru.geekbrains.jsf.UserServiceRemote
> source: org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor$2@6aba1c4b"},
> "WFLYCTL0412: Required services that are not installed:" => [ "jboss.deployment.unit.\"simple-webapp.war\".beanmanager", "jboss.deployment.unit.\"simple-webapp.war\".WeldStartService" ],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => [ "jboss.deployment.unit.\"simple-webapp.war\".batch.artifact.factory is missing [jboss.deployment.unit.\"simple-webapp.war\".beanmanager]",
> "jboss.deployment.unit.\"simple-webapp.war\".weld.weldClassIntrospector is missing [jboss.deployment.unit.\"simple-webapp.war\".beanmanager, jboss.deployment.unit.\"simple-webapp.war\".WeldStartService]" ] }
> {code}
> Notice that problem could be resolved by undeploy and Wildfly server restart. May be something wrong with JNDI content?
> I've tried to look through the web console but found nothing interesting.
> Full application code on GitHub https://github.com/usharik/simplewebapp/tree/lesson-6-ejb
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFWIP-188) [Galleon] Exisiting EAP templates are not able to use chained builds
by Jean Francois Denise (Jira)
[ https://issues.jboss.org/browse/WFWIP-188?page=com.atlassian.jira.plugin.... ]
Jean Francois Denise commented on WFWIP-188:
--------------------------------------------
[~brian.stansberry], that is resolvable. We could add the extra build step to all templates. The side effect is to create 2 builds and 2 images in all cases. Is it something we want?
As an example, helloworld-rs qs sizing:
* Built using existing template: 946MB
* Built using chained build: 755MB
* Built using chained build and galleon layers (cdi,jaxrs): 590MB
A note on using galleon. Using galleon with existing templates (except started one) fails. Some env var are set in the template for subsystems that are not present in the set of Galleon layers. For example, basic and https templates contains JGROUPS_CLUSTER_PASSWORD that breaks launch of server if jgroups is not provisioned. So we need a new template that doesn't set any env var by default. That is the reason of the new template with a parameter used to provide galleon layers.
If we decide to include chained builds in some existing templates, then the starter template could be evolved to contain a Galleon Layers parameter and remove the new template.
> [Galleon] Exisiting EAP templates are not able to use chained builds
> --------------------------------------------------------------------
>
> Key: WFWIP-188
> URL: https://issues.jboss.org/browse/WFWIP-188
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Michal Jurc
> Assignee: Jean Francois Denise
> Priority: Critical
>
> It's not possible to trigger a chained build with existing EAP templates. This kind of hinders the usability since the existing templates already cover a lot of useful test cases.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (JGRP-2372) LeaveTest fails frequently
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2372?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2372 at 9/4/19 7:44 AM:
--------------------------------------------------------
An attempt to fix this issue was to get rid of GMS.leave_timeout and have a member simply wait (on a graceful leave) until a LEAVE response was received from the coord, or until stop() was called.
However, this introduces the following problem:
* In ASYM_ENCRYPT, if we have \{A,B,C\} and C is excluded by A and B, then we have view \{A,B\} in A and B, and view \{A,B,C\} in C
* C keeps sending the LEAVE request to A, but A discards it, as C is not a member
* MERGE3 will not be able to help, as A and C won't be able to decrypt each other's messages because view \{A,B\} installed a new shared group key
* C will therefore block forever in {{JChannel.disconnect()}}!
Perhaps we should add GMS.leave_timeout back!
was (Author: belaban):
An attempt to fix this issue was to get rid of GMS.leave_timeout and have a member simply wait (on a graceful leave) until a LEAVE response was received from the coord, or until stop() was called.
However, this introduces the following problem:
* In ASYM_ENCRYPT, if we have \{A,B,C\} and C is excluded by A and B, then we have view \{A,B\} in A and B, and view \{A,B,C\} in C
* C keeps sending the LEAVE request to A, but A discards it, as C is not a member
* MERGE3 will not be able to help, as A and C won't be able to decrypt each other's messages because view \{A,B\} installed a new shared group key
* C will therefore block forever in {{JChannel.disconnect()}!
Perhaps we should add GMS.leave_timeout back!
> LeaveTest fails frequently
> --------------------------
>
> Key: JGRP-2372
> URL: https://issues.jboss.org/browse/JGRP-2372
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.5
>
>
> Ditto for ASYM_ENCRYPT_LeaveTest and ASYM_ENCRYPT_LeaveTestKeyExchange. Multiple members leaving seems to leave some members behind; the view is never correct.
> This happens only when running the entire test suite; running a test individually, or running all encryption tests ({{ant encrypt}}) almost never reproduces the errors.
> This is possibly caused by the high load of running a lot of tests concurrently, and the subsequent delays resulting from it. Nevertheless, these tests should not fail.
> Error message:
> {noformat}
> Timeout 30000 kicked in, views are: 9: [7|15] (4) [7, 8, 9, 10] 10: [7|15] (4) [7, 8, 9, 10]
> java.util.concurrent.TimeoutException
> at org.jgroups.util.Util.waitUntilAllChannelsHaveSameView(Util.java:293)
> at org.jgroups.tests.BaseLeaveTest.testConcurrentLeaves(BaseLeaveTest.java:189)
> at org.jgroups.tests.BaseLeaveTest.testLeaveOfFirstNMembers(BaseLeaveTest.java:214)
> at org.jgroups.tests.BaseLeaveTest.testLeaveOfCoordAndNext8(BaseLeaveTest.java:146)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:124)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:583)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:719)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:989)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (JGRP-2372) LeaveTest fails frequently
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2372?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-2372 at 9/4/19 7:43 AM:
--------------------------------------------------------
An attempt to fix this issue was to get rid of GMS.leave_timeout and have a member simply wait (on a graceful leave) until a LEAVE response was received from the coord, or until stop() was called.
However, this introduces the following problem:
* In ASYM_ENCRYPT, if we have \{A,B,C\} and C is excluded by A and B, then we have view \{A,B\} in A and B, and view \{A,B,C\} in C
* C keeps sending the LEAVE request to A, but A discards it, as C is not a member
* MERGE3 will not be able to help, as A and C won't be able to decrypt each other's messages because view \{A,B\} installed a new shared group key
* C will therefore block forever in {{JChannel.disconnect()}!
Perhaps we should add GMS.leave_timeout back!
was (Author: belaban):
An attempt to fix this issue was to get rid of GMS.leave_timeout and have a member simply wait (on a graceful leave) until a LEAVE response was received from the coord, or until stop() was called.
However, this introduces the following problem:
* In ASYM_ENCRYPT, if we have \{A,B,C\} and C is excluded by A and B, then we have view \{A,B\} in A and B, and view \{A,B,C\} in C
* C keeps sending the LEAVE request to A, but A discards it, as C is not a member
* MERGE3 will not be able to help, as A and C won't be able to decrypt each other's messages because view \{A,B\} installed a new shared group key
* C will therefore block forever!
Perhaps we should add GMS.leave_timeout back!
> LeaveTest fails frequently
> --------------------------
>
> Key: JGRP-2372
> URL: https://issues.jboss.org/browse/JGRP-2372
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.5
>
>
> Ditto for ASYM_ENCRYPT_LeaveTest and ASYM_ENCRYPT_LeaveTestKeyExchange. Multiple members leaving seems to leave some members behind; the view is never correct.
> This happens only when running the entire test suite; running a test individually, or running all encryption tests ({{ant encrypt}}) almost never reproduces the errors.
> This is possibly caused by the high load of running a lot of tests concurrently, and the subsequent delays resulting from it. Nevertheless, these tests should not fail.
> Error message:
> {noformat}
> Timeout 30000 kicked in, views are: 9: [7|15] (4) [7, 8, 9, 10] 10: [7|15] (4) [7, 8, 9, 10]
> java.util.concurrent.TimeoutException
> at org.jgroups.util.Util.waitUntilAllChannelsHaveSameView(Util.java:293)
> at org.jgroups.tests.BaseLeaveTest.testConcurrentLeaves(BaseLeaveTest.java:189)
> at org.jgroups.tests.BaseLeaveTest.testLeaveOfFirstNMembers(BaseLeaveTest.java:214)
> at org.jgroups.tests.BaseLeaveTest.testLeaveOfCoordAndNext8(BaseLeaveTest.java:146)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:124)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:583)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:719)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:989)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (JGRP-2372) LeaveTest fails frequently
by Bela Ban (Jira)
[ https://issues.jboss.org/browse/JGRP-2372?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2372:
--------------------------------
An attempt to fix this issue was to get rid of GMS.leave_timeout and have a member simply wait (on a graceful leave) until a LEAVE response was received from the coord, or until stop() was called.
However, this introduces the following problem:
* In ASYM_ENCRYPT, if we have \{A,B,C\} and C is excluded by A and B, then we have view \{A,B\} in A and B, and view \{A,B,C\} in C
* C keeps sending the LEAVE request to A, but A discards it, as C is not a member
* MERGE3 will not be able to help, as A and C won't be able to decrypt each other's messages because view \{A,B\} installed a new shared group key
* C will therefore block forever!
Perhaps we should add GMS.leave_timeout back!
> LeaveTest fails frequently
> --------------------------
>
> Key: JGRP-2372
> URL: https://issues.jboss.org/browse/JGRP-2372
> Project: JGroups
> Issue Type: Task
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.1.5
>
>
> Ditto for ASYM_ENCRYPT_LeaveTest and ASYM_ENCRYPT_LeaveTestKeyExchange. Multiple members leaving seems to leave some members behind; the view is never correct.
> This happens only when running the entire test suite; running a test individually, or running all encryption tests ({{ant encrypt}}) almost never reproduces the errors.
> This is possibly caused by the high load of running a lot of tests concurrently, and the subsequent delays resulting from it. Nevertheless, these tests should not fail.
> Error message:
> {noformat}
> Timeout 30000 kicked in, views are: 9: [7|15] (4) [7, 8, 9, 10] 10: [7|15] (4) [7, 8, 9, 10]
> java.util.concurrent.TimeoutException
> at org.jgroups.util.Util.waitUntilAllChannelsHaveSameView(Util.java:293)
> at org.jgroups.tests.BaseLeaveTest.testConcurrentLeaves(BaseLeaveTest.java:189)
> at org.jgroups.tests.BaseLeaveTest.testLeaveOfFirstNMembers(BaseLeaveTest.java:214)
> at org.jgroups.tests.BaseLeaveTest.testLeaveOfCoordAndNext8(BaseLeaveTest.java:146)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:124)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:583)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:719)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:989)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:109)
> at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months
[JBoss JIRA] (WFLY-12485) Galleon layers for embedded infinispan-based web clustering and JPA with a distributed 2nd level cache
by Brian Stansberry (Jira)
Brian Stansberry created WFLY-12485:
---------------------------------------
Summary: Galleon layers for embedded infinispan-based web clustering and JPA with a distributed 2nd level cache
Key: WFLY-12485
URL: https://issues.jboss.org/browse/WFLY-12485
Project: WildFly
Issue Type: Enhancement
Components: Build System, Clustering
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Make it easier to create configuration profiles supporting common clustering web cases:
1) web session clustering using in-process infinispan for the caching.
2) JPA with a distributed 2nd level cache.
The former is more urgent, so narrowing scope to that is fine if there are any problems with the JPA bit.
Web clustering using hotrod is a good thing to do but isn't part of this.
This is basically a matter of factoring out some of the config chunks Galleon uses to generate our standard configs into separate feature-groups, and then composing those into layers.
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 8 months