[JBoss JIRA] (WFLY-7728) Increased Memory footprint in recent builds
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-7728?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar moved JBEAP-7625 to WFLY-7728:
------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7728 (was: JBEAP-7625)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Server
(was: Performance)
(was: Server)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR7)
(was: 7.1.0.DR8)
(was: 7.1.0.DR9)
> Increased Memory footprint in recent builds
> -------------------------------------------
>
> Key: WFLY-7728
> URL: https://issues.jboss.org/browse/WFLY-7728
> Project: WildFly
> Issue Type: Bug
> Components: Server
> Affects Versions: 11.0.0.Alpha1
> Reporter: Tomaz Cerar
> Assignee: Tomaz Cerar
> Priority: Critical
>
> In our test scenario (see below) memory footprint has been increased between EAP 7.0.0.GA and current EAP 7.1.0.DR7 for more than 8% (~8MB) for Full profile and more than 9% (~6.5MB) for web profile. Could you please comment whether this is intended.
> Test scenario:
> # Start EAP instance.
> # Measure its memory footprint - try to get the lowest possible footprint, that means force garbage collection a few times right before measuring. We enforce GC 10 times.
> We see an increase both in heap size (~ 29 vs. 34 MB) and the metaspace size (~ 64 vs. 68 MB) - these numbers are for standalone-full profile.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7729) Increased Memory footprint in recent builds
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFLY-7729:
---------------------------------
Summary: Increased Memory footprint in recent builds
Key: WFLY-7729
URL: https://issues.jboss.org/browse/WFLY-7729
Project: WildFly
Issue Type: Bug
Components: Server
Affects Versions: 11.0.0.Alpha1
Reporter: Tomaz Cerar
Assignee: Tomaz Cerar
Priority: Critical
In our test scenario (see below) memory footprint has been increased between EAP 7.0.0.GA and current EAP 7.1.0.DR7 for more than 8% (~8MB) for Full profile and more than 9% (~6.5MB) for web profile. Could you please comment whether this is intended.
Test scenario:
# Start EAP instance.
# Measure its memory footprint - try to get the lowest possible footprint, that means force garbage collection a few times right before measuring. We enforce GC 10 times.
We see an increase both in heap size (~ 29 vs. 34 MB) and the metaspace size (~ 64 vs. 68 MB) - these numbers are for standalone-full profile.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2082) Outdated deployment-scanner xml snippet in deployments readme.txt
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2082?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet moved JBEAP-7624 to WFCORE-2082:
--------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2082 (was: JBEAP-7624)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Deployment Scanner
(was: Deployment Scanner)
(was: User Experience)
Affects Version/s: 3.0.0.Alpha14
(was: 7.1.0.DR7)
> Outdated deployment-scanner xml snippet in deployments readme.txt
> -----------------------------------------------------------------
>
> Key: WFCORE-2082
> URL: https://issues.jboss.org/browse/WFCORE-2082
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner
> Affects Versions: 3.0.0.Alpha14
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
> Priority: Trivial
>
> $JBOSS_HOME/standalone/deployments/README.txt contains following configuration XML snippet:
> {code:xml}
> <deployment-scanner scan-interval="5000" relative-to="jboss.server.base.dir" path="deployments" auto-deploy-zipped="true" auto-deploy-exploded="false"/>
> {code}
> but actual snippet from standalone.xml config file is
> {code:xml}
> <deployment-scanner path="deployments" relative-to="jboss.server.base.dir" scan-interval="5000" runtime-failure-causes-rollback="${jboss.deployment.scanner.rollback.on.failure:false}"/>
> {code}
> This might be confusing.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFCORE-2081) Confusing description of scan-enabled attribute in deployment scanner XSD
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2081?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet moved JBEAP-7623 to WFCORE-2081:
--------------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-2081 (was: JBEAP-7623)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Deployment Scanner
(was: Deployment Scanner)
(was: User Experience)
Affects Version/s: 3.0.0.Alpha14
(was: 7.1.0.DR7)
> Confusing description of scan-enabled attribute in deployment scanner XSD
> -------------------------------------------------------------------------
>
> Key: WFCORE-2081
> URL: https://issues.jboss.org/browse/WFCORE-2081
> Project: WildFly Core
> Issue Type: Bug
> Components: Deployment Scanner
> Affects Versions: 3.0.0.Alpha14
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
> Priority: Optional
>
> Documentation of *scan-enabled* attribute in $JBOSS_HOME/docs/schema/jboss-as-deployment-scanner_2_0.xsd is
> _Flag indicating that all *scanning* (including initial scanning at startup) should be *disabled*._
> This is confusing. Please change it to something like
> _Flag indicating if all scanning (including initial scanning at startup) should be enabled or disabled._
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7623) Multiple CredentialStores with ONE backed credential store file can rewrite values each other.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/WFLY-7623?page=com.atlassian.jira.plugin.... ]
Hynek Švábek updated WFLY-7623:
-------------------------------
Priority: Blocker (was: Major)
> Multiple CredentialStores with ONE backed credential store file can rewrite values each other.
> ----------------------------------------------------------------------------------------------
>
> Key: WFLY-7623
> URL: https://issues.jboss.org/browse/WFLY-7623
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
> Priority: Blocker
>
> Multiple CredentialStores with ONE backed credential store file can rewrite values each other.
> *How to reproduce*
> {code}
> /subsystem=elytron/credential-store=credStore001:add(uri="cr-store://test/cs001.jceks?store.password=pass123;create.storage=true")
> /subsystem=elytron/credential-store=credStore001/alias="alias1":add(secret-value=Elytron)
> {code}
> {code}
> /subsystem=elytron/credential-store=credStore002:add(uri="cr-store://test/cs001.jceks?store.password=pass123")
> {code}
> check CS file
> there is "alias1" entry
> {code}
> /subsystem=elytron/credential-store=credStore001/alias="alias2":add(secret-value=Elytron)
> {code}
> check CS file
> there are "alias1" and "alias2" entries
> {code}
> /subsystem=elytron/credential-store=credStore002/alias="alias123":add(secret-value=Elytron)
> {code}
> check CS file
> there are "alias1" and "alias123" entries".
> *NOTE*
> It is problem, because we have one backed file. In memory we have right values for all Credential Stores, but after restart we can lost new entries.
> In my opinion reason for this behaviour is:
> We have CS loaded in memory and when we add new alias to CS then we save whole CS from memory to file.
> We can set CS as non-modifiable when we use same backed file for CredentialStore but we must find better default behaviour.
> *My suggestion for default behaviour*
> When we want to add new alias to CredentialStore we can do this:
> # refresh CS from file (and this file lock)
> # add new alias to CS
> # save CS to file
> # unlock file
> *But there is posible problem with performance....*
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (ELY-652) There isn't possibility set entry-type for new entry in Credential Store.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/ELY-652?page=com.atlassian.jira.plugin.sy... ]
Hynek Švábek updated ELY-652:
-----------------------------
Priority: Critical (was: Major)
> There isn't possibility set entry-type for new entry in Credential Store.
> -------------------------------------------------------------------------
>
> Key: ELY-652
> URL: https://issues.jboss.org/browse/ELY-652
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
> Priority: Critical
>
> There isn't possibility set entry-type for new entry in Credential Store
> This CLI command
> {code}
> /subsystem=elytron/credential-store=testCS/alias=aliasEntryType:add(secret-value=secretVALUE, entry-type=org.wildfly.security.credential.PasswordCredential)
> {code}
> ends with
> {code}
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0158: Operation handler failed: java.lang.IllegalArgumentException: WFLYELY00909: Credential store 'testCS' does not support given credential store entry type 'org.wildfly.security.credential.PasswordCredential'",
> "rolled-back" => true
> }
> {code}
> *Server log:*
> {code}
> 10:30:39,074 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 18) WFLYCTL0013: Operation ("add") failed - address: ([
> ("subsystem" => "elytron"),
> ("credential-store" => "testCS"),
> ("alias" => "aliasEntryType")
> ]): java.lang.IllegalArgumentException: WFLYELY00909: Credential store 'testCS' does not support given credential store entry type 'org.wildfly.security.credential.PasswordCredential'
> at org.wildfly.extension.elytron.CredentialStoreAliasDefinition$AddHandler.performRuntime(CredentialStoreAliasDefinition.java:166)
> at org.jboss.as.controller.AbstractAddStepHandler$1.execute(AbstractAddStepHandler.java:151)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:940)
> at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:683)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:382)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1363)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:410)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:232)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:213)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:136)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:153)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:149)
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:153)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (ELY-676) There isn't possible change value for given alias in Credential Store over CLI.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/ELY-676?page=com.atlassian.jira.plugin.sy... ]
Hynek Švábek updated ELY-676:
-----------------------------
Priority: Critical (was: Major)
> There isn't possible change value for given alias in Credential Store over CLI.
> -------------------------------------------------------------------------------
>
> Key: ELY-676
> URL: https://issues.jboss.org/browse/ELY-676
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Credential Store
> Affects Versions: 1.1.0.Beta10
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
> Priority: Critical
>
> There isn't possible change value for given alias in Credential Store over CLI.
> I expected something like this
> {code}
> /subsystem=elytron/credential-store=credStore/alias=entryAlias:update(secret-value=newSecretValue)
> {code}
> Write-attribute operation doesn't work too. Operation pass but any changes are not propagated to Credential Store.
> {code}
> /subsystem=elytron/credential-store=credStore/alias=entryAlias:write-attribute(name="secret-value" value="newSecretValue")
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (ELY-718) Problems with creating CredentialStore from scratch when directory path doesn't exist.
by Hynek Švábek (JIRA)
[ https://issues.jboss.org/browse/ELY-718?page=com.atlassian.jira.plugin.sy... ]
Hynek Švábek updated ELY-718:
-----------------------------
Priority: Critical (was: Major)
> Problems with creating CredentialStore from scratch when directory path doesn't exist.
> --------------------------------------------------------------------------------------
>
> Key: ELY-718
> URL: https://issues.jboss.org/browse/ELY-718
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
> Priority: Critical
>
> There are problems with creating CredentialStore from scratch when directory path doesn't exist.
> *How to reproduce*
> * /subsystem=elytron/credential-store=cs007:add(uri="cr-store://test/folderNotExist/keystorecs007.jceks?store.password=pass123;create.storage=true")
> * /subsystem=elytron/credential-store=cs007/alias=newCs007:add(secret-value=Elytron)
> *You can see this error message*
> {code}
> {
> "outcome" => "failed",
> "failure-description" => "WFLYELY00009: Unable to complete operation. 'ELY09504: Cannot write storage file '/home/hsvabek/securityworkspace/AAA_prezentace/jboss-eap-7.1.0.DR7/standalone/data/folderNotExist/keystorecs007.jceks' for the store 'cs007''",
> "rolled-back" => true
> }
> {code}
> When you execute repeatedly last command /subsystem=elytron/credential-store=cs007/alias=newCs007:add(secret-value=Elytron)
> you get information about duplicate resource. It's mean the entry is in Credential Store (in memory) but not in file...
> {code}
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0212: Duplicate resource [
> (\"subsystem\" => \"elytron\"),
> (\"credential-store\" => \"cs123\"),
> (\"alias\" => \"newCs007\")
> ]",
> "rolled-back" => true
> }
> {code}
> *My suggestion solutions of this two problems:*
> * try to create directory path
> * when fails creating of CredentialStore file then we remove entry from memory too. It can be confusing have entry only in memory.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months
[JBoss JIRA] (WFLY-7721) Support module slots for foreign JMS bridges
by Robert Lee (JIRA)
[ https://issues.jboss.org/browse/WFLY-7721?page=com.atlassian.jira.plugin.... ]
Robert Lee commented on WFLY-7721:
----------------------------------
[~jmesnil] That's great news; thanks!
> Support module slots for foreign JMS bridges
> --------------------------------------------
>
> Key: WFLY-7721
> URL: https://issues.jboss.org/browse/WFLY-7721
> Project: WildFly
> Issue Type: Feature Request
> Components: JMS
> Affects Versions: 10.0.0.Final
> Reporter: Robert Lee
> Assignee: Jeff Mesnil
> Labels: artemis, bridge, jmsbridge, modules, slot
>
> It would be nice to specify the slot, along with the module, for a JMS bridge.
> *Use case*:
> When setting up a JMS bridge with a foreign JMS system, the "module" option can be used (as a CLI parameter or an XML attribute) to specify the library code for the foreign JMS system, as a JBoss Module.
> We have a number of different versions of a legacy messaging API. We have previously set up modules for direct use within our deployed application code, using different slots for different versions of the foreign JMS system.
> We are now trying to migrate away from our different messaging systems towards Wildfly/Artemis, and have tried to set up JMS bridges to connect with the different systems.
> Unfortunately, it is not possible to use any module slot other than "main" with a JMS bridge. There is no "slot" attribute in the XML, and if we try to use "modulename:slot" notation, then we get an error saying that the module could not be loaded. Turning up debugging shows it is looking for "modulename\:slot:main".
> This seems like an omission, and is causing us to have to rework code to avoid the use of slots for different versions of the same library, which seems like a step backwards.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 5 months