[JBoss JIRA] (WFLY-7075) proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization)
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-7075:
------------------------------------
>From JPA 2.1 SPEC section 7.6.1:
{quote}
If an extended persistence context of type SynchronizationType.UNSYNCHRONIZED has not been joined to the current JTA transaction, rollback of the JTA transaction will have no effect upon the persistence context. In general, it is recommended that a non-JTA datasource be specified for use by the persistence provider for a persistence context of type SynchronizationType.UNSYNCHRONIZED that has not been joined to a JTA transaction in order to alleviate the risk of integrating uncommitted changes into the persistence context in the event that the transaction is later rolled back.
{quote}
> proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization)
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7075
> URL: https://issues.jboss.org/browse/WFLY-7075
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 10.1.0.Final
> Environment: *AppServer:* WildFly 10.1.0.Final
> *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar
> Reporter: Viacheslav Astapkovich
> Assignee: Scott Marlow
> Attachments: kitchensink-ear.rar
>
>
> As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution.
>
> *The obtained defect:*
> A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final.
> The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar)
> *FIX:*
> We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
> Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e...
> _Changes_: The method getSynchronizationType returns declared synchronization type.
> *Consequences:*
> We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction.
> Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call.
> It requires a declaration of synchronize persistence context.
> We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans.
> However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check.
> *Our actions:*
> We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization).
> This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false.
> _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d...
> *Example for reproduction:*
> I modified quickstart example: [^kitchensink-ear.rar]
> MemberRepository begin Extended UNSYNCHRONIZED Persistence Context.
> MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED.
> MemberRepository also perform join Transaction.
> Questions from [~smarlow]:
> - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it.
> We decided to use Container-managed EntityManager, because
> - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components
> - The container makes our job
> We want to use the existing mechanism
> *In Addition:*
> Formally, this is out of JPA SPEC, but we have the following reasons:
> - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?".
> But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given.
> ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... )
> - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1774) Use core-service=capability-registry to provide tab completion suggestions for model reference attributes
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1774:
----------------------------------------
Summary: Use core-service=capability-registry to provide tab completion suggestions for model reference attributes
Key: WFCORE-1774
URL: https://issues.jboss.org/browse/WFCORE-1774
Project: WildFly Core
Issue Type: Enhancement
Components: CLI
Reporter: Brian Stansberry
Assignee: Alexey Loubyansky
A "model reference" attribute is one whose value points to some other aspect of the model, e.g. "socket-binding" => "http". With the capability and requirement function we are rolling out in the server[1] we have the ability for clients to understand what values are valid for the reference. This should be used in CLI tab completion.
[~claudio4j] has utitlized this for UI suggestions in HAL so he or Harald can be a resource for the exact algorithm that has worked best. Here's the basics though:
1) This applies to attributes or operation params where the read-resource-description or read-operation-description includes a "capability-reference" field. The value of the field shows the static portion of the capability name. For example an attribute that's used for a socket binding name would show "org.wildfly.network.socket-binding".
2) The [/host=*]/core-service=capability resource shows information about what capabilities are available on the system. This includes 2 attributes "capabilities" and "possible-capabilities". The former shows the specific capabilities that are actually present; i.e. the resources that provide the capability are part of the configuration. The latter shows capabilities that could be present, given the installed extensions, if the relevant resources were added.
That resource includes two operations "get-capability" and "get-provider-points" that can show more details about what resources provide a capability:
{code}
[standalone@embedded core-service=capability-registry] :get-provider-points(name=org.wildfly.network.socket-binding)
{
"outcome" => "success",
"result" => ["/socket-binding-group=*/socket-binding=*"]
}
{code}
That tells you that capabilities of type org.wildfly.network.socket-binding are registered by resources using address pattern /socket-binding-group=*/socket-binding=*
3) With that information the CLI can see what resources actually exist on the system and use the value portion of the final element of their address as the suggestion list for tab completion.
HAL may be doing something slightly different from what I describe; they have concrete experience.
It may be possible for the API exposed by core-service=capability-registry to be enhanced to make this easier. If you want something, please don't hesitate to ask Tomaz Cerar or myself.
[1] https://docs.jboss.org/author/display/WFLY/Working+with+WildFly+Capabilities
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1774) Use core-service=capability-registry to provide tab completion suggestions for model reference attributes
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1774?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1774:
----------------------------------------
Assignee: Jean-Francois Denise (was: Alexey Loubyansky)
> Use core-service=capability-registry to provide tab completion suggestions for model reference attributes
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1774
> URL: https://issues.jboss.org/browse/WFCORE-1774
> Project: WildFly Core
> Issue Type: Enhancement
> Components: CLI
> Reporter: Brian Stansberry
> Assignee: Jean-Francois Denise
>
> A "model reference" attribute is one whose value points to some other aspect of the model, e.g. "socket-binding" => "http". With the capability and requirement function we are rolling out in the server[1] we have the ability for clients to understand what values are valid for the reference. This should be used in CLI tab completion.
> [~claudio4j] has utitlized this for UI suggestions in HAL so he or Harald can be a resource for the exact algorithm that has worked best. Here's the basics though:
> 1) This applies to attributes or operation params where the read-resource-description or read-operation-description includes a "capability-reference" field. The value of the field shows the static portion of the capability name. For example an attribute that's used for a socket binding name would show "org.wildfly.network.socket-binding".
> 2) The [/host=*]/core-service=capability resource shows information about what capabilities are available on the system. This includes 2 attributes "capabilities" and "possible-capabilities". The former shows the specific capabilities that are actually present; i.e. the resources that provide the capability are part of the configuration. The latter shows capabilities that could be present, given the installed extensions, if the relevant resources were added.
> That resource includes two operations "get-capability" and "get-provider-points" that can show more details about what resources provide a capability:
> {code}
> [standalone@embedded core-service=capability-registry] :get-provider-points(name=org.wildfly.network.socket-binding)
> {
> "outcome" => "success",
> "result" => ["/socket-binding-group=*/socket-binding=*"]
> }
> {code}
> That tells you that capabilities of type org.wildfly.network.socket-binding are registered by resources using address pattern /socket-binding-group=*/socket-binding=*
> 3) With that information the CLI can see what resources actually exist on the system and use the value portion of the final element of their address as the suggestion list for tab completion.
> HAL may be doing something slightly different from what I describe; they have concrete experience.
> It may be possible for the API exposed by core-service=capability-registry to be enhanced to make this easier. If you want something, please don't hesitate to ask Tomaz Cerar or myself.
> [1] https://docs.jboss.org/author/display/WFLY/Working+with+WildFly+Capabilities
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6127) Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
by Viacheslav Astapkovich (JIRA)
[ https://issues.jboss.org/browse/WFLY-6127?page=com.atlassian.jira.plugin.... ]
Viacheslav Astapkovich commented on WFLY-6127:
----------------------------------------------
"We have WildFly 10.1.0.Final contains the fix for the reported issue.":
Unfortunately, in *wildfly-jpa-10.1.0.Final* we still always get SYNCHRONIZE when get Synchronization Type of _ExtendedEntityManager_. Even if we have UNSYNCHRONIZED EntityManager.
*Example for reproduce:* https://issues.jboss.org/secure/attachment/12409264/12409264_kitchensink-... from WFLY-7075 (modified quickstart example).
+MemberRepository+ create UNSYNCHRONIZE EntityManager, but we still get SYNCHRONIZED (printed as sysout).
> Throw IllegalStateException if JTA tx has an unsynchronized persistence context and the target is synchronized persistence context
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6127
> URL: https://issues.jboss.org/browse/WFLY-6127
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Affects Versions: 9.0.2.Final, 10.0.0.Final
> Reporter: Mazen Mahmoud
> Assignee: Scott Marlow
> Priority: Blocker
> Fix For: 10.1.0.CR1, 10.1.0.Final
>
> Attachments: server-log.txt
>
>
> SPEC: If a component is called and the JTA transaction is propagated into that component:
> If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED
> associated with the JTA transaction and the target component specifies a persistence context of type SynchronizationType.SYNCHRONIZED, the IllegalStateException is thrown by the container
> We have a stateful session bean (SFB1) / PC: TRANSACTION/UNSYNCHRONIZED)
> stateful session bean (SFB2) / PC: TRANSACTION/SYNCHRONIZED)
> SFB1 method M1 (REQUIRED) calls SFB2 Method 2 (REQUIRED):
> PC is propagated from SFB1 to SFB2 without any exception.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-7075) proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization)
by kostd kostd (JIRA)
[ https://issues.jboss.org/browse/WFLY-7075?page=com.atlassian.jira.plugin.... ]
kostd kostd commented on WFLY-7075:
-----------------------------------
[~smarlow] in JPA 2.2(if this will ever be). we like to read:
{quote}
If there is a persistence context of type SynchronizationType.UNSYNCHRONIZED
associated *and not yet joined* with the JTA transaction and the target component specifies a persistence context of
type SynchronizationType.SYNCHRONIZED, the IllegalStateException is
thrown by the container.
{quote}
Great thank for your time and advice :)
> proposal (Extension): Adding ability of check testForMixedSynchronizationTypes by isJoinToTransaction (as current state of synchronization)
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-7075
> URL: https://issues.jboss.org/browse/WFLY-7075
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Affects Versions: 10.1.0.Final
> Environment: *AppServer:* WildFly 10.1.0.Final
> *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar
> Reporter: Viacheslav Astapkovich
> Assignee: Scott Marlow
> Attachments: kitchensink-ear.rar
>
>
> As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution.
>
> *The obtained defect:*
> A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final.
> The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar)
> *FIX:*
> We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127
> Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e...
> _Changes_: The method getSynchronizationType returns declared synchronization type.
> *Consequences:*
> We use own realisation of Martin Fowler pattern "Unit of Work". We initialize UNSYNCHRONIZED Extended Persistence Context and our UnitOfWork realisation manages the synchronization with transaction.
> Our Beans could be controlled by UnitOfWork, but also could be used as part of WebService call.
> It requires a declaration of synchronize persistence context.
> We catch IllegalStateException after we fixed defect of synchronization type determination, because we initialize UNSYNCHRONIZED persistence context, but we use declare SYNCHRONIZED persistence context in our beans.
> However, our UnitOfWork realisation control synchronization of persistence context and we can synchronize context before synchronization type check.
> *Our actions:*
> We add ability to check synchronization type in the method testForMixedSynchronizationTypes of class TransactionScopedEntityManager by isJoinToTransaction method (i.e. the actual type of synchronization).
> This ability realized by property "jboss.as.jpa.syncasjoin" in persistence.xml file. Only if this property setted to true - we perform testForMixedSynchronizationTypes by isJoinToTransaction method. We work as usual if this property not defined or setted to false.
> _Commit_: https://github.com/wildfly/wildfly/commit/195a8a65a9fae006ad603e425f6a16d...
> *Example for reproduction:*
> I modified quickstart example: [^kitchensink-ear.rar]
> MemberRepository begin Extended UNSYNCHRONIZED Persistence Context.
> MemberFinder.find called from MemberRepository. MemberFinder declared "SYNCHRONIZED", but MemberRepository declared UNSYNCHRONIZED.
> MemberRepository also perform join Transaction.
> Questions from [~smarlow]:
> - whether you could instead use an application-managed entity manager instead (which is similar to extended persistence context except the app controls it.
> We decided to use Container-managed EntityManager, because
> - Application-managed entity managers don’t automatically propagate the JTA transaction context. With application-managed entity managers the persistence context is not propagated to application components
> - The container makes our job
> We want to use the existing mechanism
> *In Addition:*
> Formally, this is out of JPA SPEC, but we have the following reasons:
> - In the development process of the JPA specification got a question: "Should we relax this if the PC has been joined to the transaction?".
> But unfortunately, Linda DeMichiel decided to leave as current behavior because no feedback was given.
> ( https://java.net/projects/jpa-spec/lists/jsr338-experts/archive/2011-08/m... )
> - We found JIRA task https://java.net/jira/browse/JPA_SPEC-6 but it was closed because "No feedback in favor of changing current approach"
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-7076) Elytron introduces SSL/TLS protocol constraints
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7076?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-7076:
----------------------------------------
[~honza889] The subsystem is using the underscore as I think we are currently using the enum for validation, we need to allow the standard names to use. Also need to double check the level of validation we need, we can hard code a list of accepted Strings but need to see how that compares with our current filter.
> Elytron introduces SSL/TLS protocol constraints
> -----------------------------------------------
>
> Key: WFLY-7076
> URL: https://issues.jboss.org/browse/WFLY-7076
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Jan Kalina
>
> {noformat}
> "protocols" => {
> "type" => LIST,
> "description" => "The enabled protocols.",
> "expressions-allowed" => true,
> "nillable" => false,
> "allowed" => [
> "SSLv2",
> "SSLv3",
> "TLSv1",
> "TLSv1_1",
> "TLSv1_2",
> "TLSv1_3"
> ],
> "value-type" => STRING,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> },
> {noformat}
> Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values?
> Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value.
> IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java.
> Note, IBM java already today defines little bit different protocols set [2]
> I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place.
> [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardN...
> [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-7076) Elytron introduces SSL/TLS protocol constraints
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7076?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-7076:
--------------------------------------
Assignee: Jan Kalina (was: Darran Lofthouse)
> Elytron introduces SSL/TLS protocol constraints
> -----------------------------------------------
>
> Key: WFLY-7076
> URL: https://issues.jboss.org/browse/WFLY-7076
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Jan Kalina
>
> {noformat}
> "protocols" => {
> "type" => LIST,
> "description" => "The enabled protocols.",
> "expressions-allowed" => true,
> "nillable" => false,
> "allowed" => [
> "SSLv2",
> "SSLv3",
> "TLSv1",
> "TLSv1_1",
> "TLSv1_2",
> "TLSv1_3"
> ],
> "value-type" => STRING,
> "access-type" => "read-write",
> "storage" => "configuration",
> "restart-required" => "resource-services"
> },
> {noformat}
> Why elytron on this place is going to validate user input and map standard java values [1] into proprietary values?
> Whereas on other similar places (KeyManager algorithm, TrustManager algorithm, Keystore types) it leaves up to user to set proper value.
> IMO, with such mapping another place, where bugs can raise was introduced. EAP will be here always one step back compared to java.
> Note, IBM java already today defines little bit different protocols set [2]
> I wonder, where is that mapping "TLSv1_2 -> TLSv1.2" acually performed? I couldn't find that place.
> [1] https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardN...
> [2] http://www.ibm.com/support/knowledgecenter/SSYKE2_8.0.0/com.ibm.java.secu...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1127) SocketBindingManagerImpl$UnnamedRegistryImpl is overly picky about unbound sockets
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1127?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1127:
------------------------------------------
[~pferraro] ^^^
> SocketBindingManagerImpl$UnnamedRegistryImpl is overly picky about unbound sockets
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-1127
> URL: https://issues.jboss.org/browse/WFCORE-1127
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.1.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.2.Final
>
>
> A failure like this isn't necessary:
> {code}
> 08:02:23,475 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.jgroups.channel.ee.connector: org.jboss.msc.service.StartException in service jboss.jgroups.channel.ee.connector: java.lang.IllegalStateException
> at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:96)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.IllegalStateException
> at org.jboss.as.network.SocketBindingManagerImpl$UnnamedRegistryImpl.unregisterBinding(SocketBindingManagerImpl.java:501)
> at org.jboss.as.network.ManagedDatagramSocketBinding.close(ManagedDatagramSocketBinding.java:73)
> at org.jboss.as.clustering.jgroups.ManagedSocketFactory.close(ManagedSocketFactory.java:148)
> at org.jgroups.protocols.UDP.closeUnicastSocket(UDP.java:577)
> at org.jgroups.protocols.UDP.destroySockets(UDP.java:429)
> at org.jgroups.protocols.UDP.start(UDP.java:274)
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:965)
> at org.jgroups.JChannel.startStack(JChannel.java:890)
> at org.jgroups.JChannel._preConnect(JChannel.java:553)
> at org.jgroups.JChannel.connect(JChannel.java:288)
> at org.jgroups.JChannel.connect(JChannel.java:279)
> at org.wildfly.clustering.jgroups.spi.service.ChannelConnectorBuilder.start(ChannelConnectorBuilder.java:94)
> ... 5 more
> {code}
> If there's no socket address, it should just move on.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-1773) SynchServerOperation pulls down more config than necessary during slave reconnection to DC
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1773?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-1773:
------------------------------------------
[~luck3y] Another thing to look at (also probably a separate issue) is why in that diff you showed me the original version of the cached-remote domain config had empty profile elements:
{code}
<profile name="full"/>
<profile name="full-ha"/>
{code}
A slave should either have the profile or ignore it. It shouldn't have it but in an incomplete form.
> SynchServerOperation pulls down more config than necessary during slave reconnection to DC
> ------------------------------------------------------------------------------------------
>
> Key: WFCORE-1773
> URL: https://issues.jboss.org/browse/WFCORE-1773
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Ken Wills
> Assignee: Ken Wills
>
> When a slave disconnects and reconnects to the DC for the first time, a complete copy of the domain config is sent. If the slave is using the default ignore-unused-configuration semantics, it still adds all of the additional configuration.
> An additional side issue is the full-ha subsystems are being added in reverse order.
> More detail in comments here https://github.com/wildfly/wildfly-core/pull/1754.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months