[JBoss JIRA] (WFCORE-218) wildfly web management console hangs during deploy from cli
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-218?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-218:
-----------------------------------------
I briefly considered not holding any long lasting topology lock and simply getting the set of hosts under a short lived lock. But that is not reliable:
1) T1 is doing a domain-wide write, on DC OperationCoordinatorStepHandler gathers the registered servers and creates DomainSlaveHandler to do the HC rollout.
2) New HC starts, connects, gets exclusive lock, starts registration stuff.
3) T1 gets to the Stage.MODEL handler that detects a write, tries to get exclusive lock, blocks
4) New HC reg is completed, exclusive lock released
5) T1 gets lock, proceeds
6) T1 gets to DomainSlaveHandler, rolls out the change to the set of slaves provided in 1) above, which does not include New HC.
7) New HC misses the update.
The situation with servers I believe is simpler. There the set of host and server proxies is the complete set. Which servers get called depends on the rollout plan. The rollout plan is created after Stage.MODEL, so the exclusive lock will be held when it is created. So any "New Server" joining in a race with the change will either a) block in registration acquiring the exclusinve lock until after the change is complete or b) cause the change to block in Stage.MODEL until reg is complete, with New Server then being picked up by DomainRolloutStepHandler the same as if it had been registered before the change op even began.
The way the server case is handled by DomainRolloutStepHandler suggests a possible easy fix for the host case as well. DomainSlaveHandler should be constructed with a ref to the dynamically changing map of host proxies (the way DomainRolloutStepHandler is). It should also be given the set of host names to update, or null if the update is global. If the list of host names is not null, that means the op only targets particular hosts, with no possibility of that set being added to in the course of execution. So, if if the change is global, the write lock in a Stage.MODEL step will ensure that any new host is either registered before DomainSlaveHandler executes, or is blocking waiting for the change op to complete. If the change is not global, the registration of a new slave is irrelevant to DomainSlaveHandler; it just works with the set of hosts it knows about.
> wildfly web management console hangs during deploy from cli
> -----------------------------------------------------------
>
> Key: WFCORE-218
> URL: https://issues.jboss.org/browse/WFCORE-218
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha1
> Reporter: Ian Kent
> Attachments: threaddump-1415735255304.tdump
>
>
> We are running wildfly in domain mode with the following configuration.
> host A running domain controlller
> host B running host controller with one app sever
> host C running host controller with one app server
> host D running host controller with one app server
> When we deloy war using jboss-cli the web console is blocked for usage until deploy completes. I have run jvisualvm and it does not appear that domain controller process is starved for resources (cpu, memory, threads).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2046) KeyManager synchronization issue when using IBM JDK
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2046?page=com.atlassian.jira.plugi... ]
Darran Lofthouse reassigned WFCORE-2046:
----------------------------------------
Assignee: Darran Lofthouse (was: Brian Stansberry)
> KeyManager synchronization issue when using IBM JDK
> ---------------------------------------------------
>
> Key: WFCORE-2046
> URL: https://issues.jboss.org/browse/WFCORE-2046
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> We hit a {{KeyManagerFactory}} related synchronization issue in {{org.jboss.as.domain.management.security.AbstractKeyManagerService.createKeyManagers(boolean)}} method on IBM JDK. The issue occurs if there are more security realms with SSL identities in EAP and they have keystores with different passwords.
> As the ApplicationRealm (in EAP 7.1) has preconfigured ssl identity configuration, the risk customers will hit this when they add their own security realm with a ssl identity is big. The frequency we hit this issue is more than 10% cases on our machines.
> Our debugging suggests the problem is located in IBM JDK implementation of {{javax.net.ssl.KeyManagerFactorySpi}} (class {{com.ibm.jsse2.ae$a}}).
> The workflow:
> # user calls {{keyManagerFactory.init(keyStore, keystorePassword)}} which invokes {{com.ibm.jsse2.ae$a.engineInit(Keystore keyStore, char[] password)}}
> # the password (from the second method parameter) is stored into static field {{com.ibm.jsse2.ae.d}} and in the next step the field is used as parameter for creating new object {{new com.ibm.jsse2.aw(keyStore, d)}}
> # the previous step is not synchronized and when more threads call {{keyManagerFactory.init()}} with different passwords, wrong password may be used for retrieving a key from keystore.
> *Possible workaround*
> We could workaround this issue on EAP side (until it's fixed in the JDK) by synchronizing {{keyManagerFactory.init()}} call in {{AbstractKeyManagerService.createKeyManagers(boolean)}} when IBM JDK is used.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2046) KeyManager synchronization issue when using IBM JDK
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2046?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-2046:
-------------------------------------
Component/s: (was: Domain Management)
> KeyManager synchronization issue when using IBM JDK
> ---------------------------------------------------
>
> Key: WFCORE-2046
> URL: https://issues.jboss.org/browse/WFCORE-2046
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Josef Cacek
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> We hit a {{KeyManagerFactory}} related synchronization issue in {{org.jboss.as.domain.management.security.AbstractKeyManagerService.createKeyManagers(boolean)}} method on IBM JDK. The issue occurs if there are more security realms with SSL identities in EAP and they have keystores with different passwords.
> As the ApplicationRealm (in EAP 7.1) has preconfigured ssl identity configuration, the risk customers will hit this when they add their own security realm with a ssl identity is big. The frequency we hit this issue is more than 10% cases on our machines.
> Our debugging suggests the problem is located in IBM JDK implementation of {{javax.net.ssl.KeyManagerFactorySpi}} (class {{com.ibm.jsse2.ae$a}}).
> The workflow:
> # user calls {{keyManagerFactory.init(keyStore, keystorePassword)}} which invokes {{com.ibm.jsse2.ae$a.engineInit(Keystore keyStore, char[] password)}}
> # the password (from the second method parameter) is stored into static field {{com.ibm.jsse2.ae.d}} and in the next step the field is used as parameter for creating new object {{new com.ibm.jsse2.aw(keyStore, d)}}
> # the previous step is not synchronized and when more threads call {{keyManagerFactory.init()}} with different passwords, wrong password may be used for retrieving a key from keystore.
> *Possible workaround*
> We could workaround this issue on EAP side (until it's fixed in the JDK) by synchronizing {{keyManagerFactory.init()}} call in {{AbstractKeyManagerService.createKeyManagers(boolean)}} when IBM JDK is used.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-6854) Upgrade Hibernate ORM to 5.1.3
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6854?page=com.atlassian.jira.plugin.... ]
Scott Marlow commented on WFLY-6854:
------------------------------------
Thanks [~lafr] + [~kabirkhan] for getting this change in!
> Upgrade Hibernate ORM to 5.1.3
> -------------------------------
>
> Key: WFLY-6854
> URL: https://issues.jboss.org/browse/WFLY-6854
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Reporter: Emmanuel Bernard
> Assignee: Scott Marlow
> Fix For: 11.0.0.Alpha1
>
>
> This is a follow up on WFLY-6682.
> After looking at the list of potential incompatibilities, we decided to not upgrade to 5.2 but instead to 5.1 to provide a smoother experience to users.
> We can consider adding a 5.2 optional switch via Jipijapa if bandwidth permit but let's treat it as a second issue and have [~smarlow] lead it.
> PS: I put v11Alpha1 but feel free to adjust it to any WF 11 version that fits best.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-6854) Upgrade Hibernate ORM to 5.1.3
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-6854?page=com.atlassian.jira.plugin.... ]
Scott Marlow closed WFLY-6854.
------------------------------
> Upgrade Hibernate ORM to 5.1.3
> -------------------------------
>
> Key: WFLY-6854
> URL: https://issues.jboss.org/browse/WFLY-6854
> Project: WildFly
> Issue Type: Feature Request
> Components: JPA / Hibernate
> Reporter: Emmanuel Bernard
> Assignee: Scott Marlow
> Fix For: 11.0.0.Alpha1
>
>
> This is a follow up on WFLY-6682.
> After looking at the list of potential incompatibilities, we decided to not upgrade to 5.2 but instead to 5.1 to provide a smoother experience to users.
> We can consider adding a 5.2 optional switch via Jipijapa if bandwidth permit but let's treat it as a second issue and have [~smarlow] lead it.
> PS: I put v11Alpha1 but feel free to adjust it to any WF 11 version that fits best.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7689) Test DeploymentDescriptorTestCase Not Handling Own Clean Up
by James Perkins (JIRA)
James Perkins created WFLY-7689:
-----------------------------------
Summary: Test DeploymentDescriptorTestCase Not Handling Own Clean Up
Key: WFLY-7689
URL: https://issues.jboss.org/browse/WFLY-7689
Project: WildFly
Issue Type: Bug
Components: Batch, Test Suite
Reporter: Darran Lofthouse
Assignee: James Perkins
Fix For: 11.0.0.Alpha1
The test DeploymentDescriptorTestCase appears to be assuming it will only be run after 'mvn clean'.
If I run the test manually I get the failure: -
{noformat}
Running org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.763 sec <<< FAILURE! - in org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase
namedJdbcTest(org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase) Time elapsed: 0.127 sec <<< FAILURE!
java.lang.AssertionError: expected:<1> but was:<6>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase.testCompletion(DeploymentDescriptorTestCase.java:127)
at org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase.namedJdbcTest(DeploymentDescriptorTestCase.java:115)
{noformat}
Next time I run it I get: -
{noformat}
Running org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.986 sec <<< FAILURE! - in org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase
namedJdbcTest(org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase) Time elapsed: 0.129 sec <<< FAILURE!
java.lang.AssertionError: expected:<1> but was:<7>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase.testCompletion(DeploymentDescriptorTestCase.java:127)
at org.jboss.as.test.integration.batch.deployment.DeploymentDescriptorTestCase.namedJdbcTest(DeploymentDescriptorTestCase.java:115)
{noformat}
So the execution IDs are not getting set back to 0 before the test starts.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (JBAS-9472) Improve the processing time of a request with a large number of parameters.
by amine amghar (JIRA)
[ https://issues.jboss.org/browse/JBAS-9472?page=com.atlassian.jira.plugin.... ]
amine amghar commented on JBAS-9472:
------------------------------------
Hello,
We have the same problem in production.
Can you gives as a version of jboss modified with a patch ?
Thx.
> Improve the processing time of a request with a large number of parameters.
> ---------------------------------------------------------------------------
>
> Key: JBAS-9472
> URL: https://issues.jboss.org/browse/JBAS-9472
> Project: Application Server 3 4 5 and 6
> Issue Type: Enhancement
> Components: Web (Tomcat) service
> Affects Versions: JBossAS-5.1.0.GA
> Environment: Linux, Windows
> Reporter: Toshio Oya
> Assignee: Remy Maucherat
> Attachments: modified-5.1.0.GA.zip, sample-app.zip
>
>
> We ported an existing business application from Tomcat 5.5.x to JBoss AS 5.1.0.GA.
> When running the application on JBoss AS, we found that the processing of a POST request with a large number of parameters takes longer than doing it on Tomcat.
> We investigated the cause, it occurred in the processing of org.apache.tomcat.util.http.Parameters class in JBossAS/JBossWeb.
> So, we've created a patch for JBoss AS to improve it.
> We applied this patch to JBoss AS, then the processing time of 10,000 parameters in a POST request is now as follows.
> - Time of processing request.getParameterMap().
> Before:
> 22,635.0 msec (average of 3 times)
> After:
> 2.3 msec (average of 3 times)
> We want to incorporate this patch in JBoss AS.
> Using our sample application:
> 1. Build
> $ cd /tmp
> $ unzip sample-app.zip
> $ cd sample-app
> $ mvn package
> 2. Deploy
> Please copy the test_war-1.0.war to your deploy directory for your JBossAS.
> $ cd blank_war/target/
> $ cp test_war-1.0.war $JBOSS_HOME/server/<profile>/deploy
> 3. Test
> Access the url - http://server:port/test_war-1.0/ via a web browser.
> Press the "click" button in the page.
> And, press "OK" button on a dialog.
> The time of processing request.getParameters() is logged to CONSOLE and log/server.log.
> ex)
> 13:42:43,084 FATAL [SampleTestAction] request.getParameterMap() taken 20467 msec.
> About patch.
> modified-5.1.0.GA.zip
> - B2CConverter.java ... replacement of org.apache.tomcat.util.buf.B2BConverter
> - Parameters.java ... replacement of org.apache.tomcat.util.http.Parameters
> - LocalStrings.properties
> ... added a new property file to org.apache.tomcat.util.http.
> Best regards,
> Team.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2055) Direct end user mods of a slave-HC-managed domain server's config are possible if included in a composite op
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2055?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-2055:
-------------------------------------
Summary: Direct end user mods of a slave-HC-managed domain server's config are possible if included in a composite op (was: Direct end users mods of a slave-HC-managed domain server's config are possible if included in a composite op)
> Direct end user mods of a slave-HC-managed domain server's config are possible if included in a composite op
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2055
> URL: https://issues.jboss.org/browse/WFCORE-2055
> Project: WildFly Core
> Issue Type: Bug
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
>
> Once WFCORE-2053 is fixed, CoreResourceManagementTestCase.testCannotInvokeManagedSlaveServerOperationsInDomainComposite will fail. This test involves doing two ops in a composite, with the composite addressed to the domain root, while the steps are addressed to a subsystem on an individual server, where the server is managed by a slave HC. The first op is a read, the second is a write.
> The op should fail as the write is not allowed.
> Test is currently only passing because the WFCORE-2053 problem is producing false positives.
> Problem is likely (but not certainly) due to changes made to OperationRouting as part of https://github.com/wildfly/wildfly-core/pull/597
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2055) Direct end users mods of a slave-HC-managed domain server's config are possible if included in a composite op
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-2055:
----------------------------------------
Summary: Direct end users mods of a slave-HC-managed domain server's config are possible if included in a composite op
Key: WFCORE-2055
URL: https://issues.jboss.org/browse/WFCORE-2055
Project: WildFly Core
Issue Type: Bug
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Once WFCORE-2053 is fixed, CoreResourceManagementTestCase.testCannotInvokeManagedSlaveServerOperationsInDomainComposite will fail. This test involves doing two ops in a composite, with the composite addressed to the domain root, while the steps are addressed to a subsystem on an individual server, where the server is managed by a slave HC. The first op is a read, the second is a write.
The op should fail as the write is not allowed.
Test is currently only passing because the WFCORE-2053 problem is producing false positives.
Problem is likely (but not certainly) due to changes made to OperationRouting as part of https://github.com/wildfly/wildfly-core/pull/597
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months