[JBoss JIRA] (WFLY-9454) SecurityContext not injected
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-9454?page=com.atlassian.jira.plugin.... ]
Martin Kouba reassigned WFLY-9454:
----------------------------------
Assignee: (was: Martin Kouba)
> SecurityContext not injected
> ----------------------------
>
> Key: WFLY-9454
> URL: https://issues.jboss.org/browse/WFLY-9454
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, EE
> Affects Versions: 11.0.0.CR1
> Reporter: Mike Kachalov
>
> 11:49:28,341 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."foo-1.0.ear".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."foo-1.0.ear".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type SecurityContext with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private com.foo.bar.facade.impl.UserRegisterFacadeImpl.securityContext
> it's copy issue WELD-2437
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFLY-9454) SecurityContext not injected
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-9454?page=com.atlassian.jira.plugin.... ]
Martin Kouba updated WFLY-9454:
-------------------------------
Component/s: Security
(was: EE)
> SecurityContext not injected
> ----------------------------
>
> Key: WFLY-9454
> URL: https://issues.jboss.org/browse/WFLY-9454
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld, Security
> Affects Versions: 11.0.0.CR1
> Reporter: Mike Kachalov
>
> 11:49:28,341 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."foo-1.0.ear".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."foo-1.0.ear".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1978)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type SecurityContext with qualifiers @Default
> at injection point [BackedAnnotatedField] @Inject private com.foo.bar.facade.impl.UserRegisterFacadeImpl.securityContext
> it's copy issue WELD-2437
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFLY-9456) High non heap memory consumption
by Klaus Erber (JIRA)
[ https://issues.jboss.org/browse/WFLY-9456?page=com.atlassian.jira.plugin.... ]
Klaus Erber updated WFLY-9456:
------------------------------
Description:
After a clean install of WF11CR1 without any configuration changes and startup with standalone.sh we see a high memory usage on the system side (about 800 MB).
Wenn we do the same with WF10Final we see a memory usage of about 210 MB.
Her are the output auf ps aux:
wf11
ke4 1652 14.0 22.1 2863404 *801620* pts/3 Sl+ 14:01 0:07 java -D[Standalone] -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
wf10
ke4 1836 42.1 5.7 2687744 *209204* pts/2 Sl+ 14:02 0:06 java -D[Standalone] -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
The result is, that we can only start 3 instances of wildfly 11 on a 3.75 GB VM. The 4th instance crashes the system. In our real scenario (Wildfly instances in docker containers hosting the REST interface for our application) we see about 1 GB memory consumption per backend node.
The heap and other memory pools not seems to be the reason for this behaviour - see the attached native memory tracking results.
was:
After a clean install of WF11CR1 without any configuration changes and startup with standalone.sh we see a high memory usage on the system side (about 800 MB).
Wenn we do the same with WF10Final we see a memory usage of about 210 MB.
Her are the output auf ps aux:
wf11
ke4 1652 14.0 22.1 2863404 *801620 *pts/3 Sl+ 14:01 0:07 java -D[Standalone] -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
wf10
ke4 1836 42.1 5.7 2687744 *209204 *pts/2 Sl+ 14:02 0:06 java -D[Standalone] -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
The result is, that we can only start 3 instances of wildfly 11 on a 3.75 GB VM. The 4th instance crashes the system. In our real scenario (Wildfly instances in docker containers hosting the REST interface for our application) we see about 1 GB memory consumption per backend node.
The heap and other memory pools not seems to be the reason for this behaviour - see the attached native memory tracking results.
> High non heap memory consumption
> --------------------------------
>
> Key: WFLY-9456
> URL: https://issues.jboss.org/browse/WFLY-9456
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 11.0.0.CR1
> Environment: CentOS 7 on Google compute engine VM
> openjdk version "1.8.0_144"
> OpenJDK Runtime Environment (build 1.8.0_144-b01)
> OpenJDK 64-Bit Server VM (build 25.144-b01, mixed mode)
> Reporter: Klaus Erber
> Assignee: David Lloyd
> Attachments: wf10-nmt.txt, wf11-nmt.txt
>
>
> After a clean install of WF11CR1 without any configuration changes and startup with standalone.sh we see a high memory usage on the system side (about 800 MB).
> Wenn we do the same with WF10Final we see a memory usage of about 210 MB.
> Her are the output auf ps aux:
> wf11
> ke4 1652 14.0 22.1 2863404 *801620* pts/3 Sl+ 14:01 0:07 java -D[Standalone] -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
> wf10
> ke4 1836 42.1 5.7 2687744 *209204* pts/2 Sl+ 14:02 0:06 java -D[Standalone] -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
> The result is, that we can only start 3 instances of wildfly 11 on a 3.75 GB VM. The 4th instance crashes the system. In our real scenario (Wildfly instances in docker containers hosting the REST interface for our application) we see about 1 GB memory consumption per backend node.
> The heap and other memory pools not seems to be the reason for this behaviour - see the attached native memory tracking results.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFCORE-3367) Add note to elytron attributes that affects EAP configuration globally
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3367?page=com.atlassian.jira.plugi... ]
Jan Kalina moved JBEAP-13554 to WFCORE-3367:
--------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-3367 (was: JBEAP-13554)
Issue Type: Feature Request (was: Documentation)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: 3.0.6.Final
(was: 7.1.0.DR19)
> Add note to elytron attributes that affects EAP configuration globally
> ----------------------------------------------------------------------
>
> Key: WFCORE-3367
> URL: https://issues.jboss.org/browse/WFCORE-3367
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Security
> Affects Versions: 3.0.6.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
> Priority: Minor
>
> There are some attributes in elytron subsystem which have global effect on EAP server state even in case elytron security is not utilized in any way. Those are (at least):
> * disallowed-providers
> * final-providers
> * initial-providers
> We should put some note in description of those attributes that they have global effect on EAP server and take effect even in cases elytron security is not utilized anyhow. Reason is that it might be a little confusing for customers to find and configure these attributes in elytron subsystem even in case they use just legacy security-realm. One would expect that when something is configured in elytron subsystem it has not take effect unless explicitely referenced or used (because we still have also legacy security-realm based security). It is not a perfect state/UX but as Elytron is supposed to become a common and only place for server security configuration it is understandable that all new security related things are being put there.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFLY-9456) High non heap memory consumption
by Klaus Erber (JIRA)
[ https://issues.jboss.org/browse/WFLY-9456?page=com.atlassian.jira.plugin.... ]
Klaus Erber updated WFLY-9456:
------------------------------
Description:
After a clean install of WF11CR1 without any configuration changes and startup with standalone.sh we see a high memory usage on the system side (about 800 MB).
Wenn we do the same with WF10Final we see a memory usage of about 210 MB.
Her are the output auf ps aux:
wf11
ke4 1652 14.0 22.1 2863404 *801620 *pts/3 Sl+ 14:01 0:07 java -D[Standalone] -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
wf10
ke4 1836 42.1 5.7 2687744 *209204 *pts/2 Sl+ 14:02 0:06 java -D[Standalone] -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
The result is, that we can only start 3 instances of wildfly 11 on a 3.75 GB VM. The 4th instance crashes the system. In our real scenario (Wildfly instances in docker containers hosting the REST interface for our application) we see about 1 GB memory consumption per backend node.
The heap and other memory pools not seems to be the reason for this behaviour - see the attached native memory tracking results.
was:
After a clean install of WF11CR1 without any configuration changes and startup with standalone.sh we see a high memory usage on the system side (about 800 MB).
Wenn we do the same with WF10Final we see a memory usage of about 210 MB.
Her are the output auf ps aux:
wf11
ke4 1652 14.0 22.1 2863404 801620 pts/3 Sl+ 14:01 0:07 java -D[Standalone] -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
wf10
ke4 1836 42.1 5.7 2687744 209204 pts/2 Sl+ 14:02 0:06 java -D[Standalone] -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
The result is, that we can only start 3 instances of wildfly 11 on a 3.75 GB VM. The 4th instance crashes the system. In our real scenario (Wildfly instances in docker containers hosting the REST interface for our application) we see about 1 GB memory consumption per backend node.
The heap and other memory pools not seems to be the reason for this behaviour - see the attached native memory tracking results.
> High non heap memory consumption
> --------------------------------
>
> Key: WFLY-9456
> URL: https://issues.jboss.org/browse/WFLY-9456
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 11.0.0.CR1
> Environment: CentOS 7 on Google compute engine VM
> openjdk version "1.8.0_144"
> OpenJDK Runtime Environment (build 1.8.0_144-b01)
> OpenJDK 64-Bit Server VM (build 25.144-b01, mixed mode)
> Reporter: Klaus Erber
> Assignee: David Lloyd
> Attachments: wf10-nmt.txt, wf11-nmt.txt
>
>
> After a clean install of WF11CR1 without any configuration changes and startup with standalone.sh we see a high memory usage on the system side (about 800 MB).
> Wenn we do the same with WF10Final we see a memory usage of about 210 MB.
> Her are the output auf ps aux:
> wf11
> ke4 1652 14.0 22.1 2863404 *801620 *pts/3 Sl+ 14:01 0:07 java -D[Standalone] -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
> wf10
> ke4 1836 42.1 5.7 2687744 *209204 *pts/2 Sl+ 14:02 0:06 java -D[Standalone] -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
> The result is, that we can only start 3 instances of wildfly 11 on a 3.75 GB VM. The 4th instance crashes the system. In our real scenario (Wildfly instances in docker containers hosting the REST interface for our application) we see about 1 GB memory consumption per backend node.
> The heap and other memory pools not seems to be the reason for this behaviour - see the attached native memory tracking results.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFLY-9456) High non heap memory consumption
by Klaus Erber (JIRA)
Klaus Erber created WFLY-9456:
---------------------------------
Summary: High non heap memory consumption
Key: WFLY-9456
URL: https://issues.jboss.org/browse/WFLY-9456
Project: WildFly
Issue Type: Bug
Components: Class Loading
Affects Versions: 11.0.0.CR1
Environment: CentOS 7 on Google compute engine VM
openjdk version "1.8.0_144"
OpenJDK Runtime Environment (build 1.8.0_144-b01)
OpenJDK 64-Bit Server VM (build 25.144-b01, mixed mode)
Reporter: Klaus Erber
Assignee: David Lloyd
Attachments: wf10-nmt.txt, wf11-nmt.txt
After a clean install of WF11CR1 without any configuration changes and startup with standalone.sh we see a high memory usage on the system side (about 800 MB).
Wenn we do the same with WF10Final we see a memory usage of about 210 MB.
Her are the output auf ps aux:
wf11
ke4 1652 14.0 22.1 2863404 801620 pts/3 Sl+ 14:01 0:07 java -D[Standalone] -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
wf10
ke4 1836 42.1 5.7 2687744 209204 pts/2 Sl+ 14:02 0:06 java -D[Standalone] -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m
The result is, that we can only start 3 instances of wildfly 11 on a 3.75 GB VM. The 4th instance crashes the system. In our real scenario (Wildfly instances in docker containers hosting the REST interface for our application) we see about 1 GB memory consumption per backend node.
The heap and other memory pools not seems to be the reason for this behaviour - see the attached native memory tracking results.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months
[JBoss JIRA] (WFLY-9455) WFLYTX0001: Unable to roll back active transaction thrown for EJB bridge transactions
by Ondra Chaloupka (JIRA)
Ondra Chaloupka created WFLY-9455:
-------------------------------------
Summary: WFLYTX0001: Unable to roll back active transaction thrown for EJB bridge transactions
Key: WFLY-9455
URL: https://issues.jboss.org/browse/WFLY-9455
Project: WildFly
Issue Type: Bug
Components: XTS
Affects Versions: 11.0.0.CR1
Reporter: Ondra Chaloupka
Assignee: Ondra Chaloupka
It happens to get exception
{code}
ERROR [org.jboss.as.txn] (default task-12) WFLYTX0003: APPLICATION ERROR: transaction still active in request with status 0
ERROR [org.jboss.as.txn] (default task-12) WFLYTX0001: Unable to roll back active transaction: javax.transaction.SystemException: WFTXN0032: Rollback not allowed on imported transaction
at org.wildfly.transaction.client.LocalTransaction.rollbackAndDissociate(LocalTransaction.java:100)
at org.wildfly.transaction.client.ContextTransactionManager.rollback(ContextTransactionManager.java:83)
at org.jboss.as.txn.deployment.TransactionRollbackSetupAction.checkTransactionStatus(TransactionRollbackSetupAction.java:137)
at org.jboss.as.txn.deployment.TransactionRollbackSetupAction.teardown(TransactionRollbackSetupAction.java:67)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1510)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
when using XTS transactions bridged to JTA for EJB handling. This happens on change of integration layer for WFTC in WFLY11.
The integration issues were already discussed as part of the JBTM-2853.
Here I hit a trouble of having log filled with the exception mentioned above. This does not cause a functionality trouble but the log is ugly filled with ERRORs.
The trouble seems to be caused by the fact that transaction is imported on ivocation of WS
https://github.com/wildfly/wildfly/blob/master/webservices/server-integra...
but as it was suspended in the integration code before
https://github.com/jbosstm/narayana/blob/master/txbridge/src/main/java/or...
now the WFTC holds the notion about the transaction even on call of
https://github.com/wildfly/wildfly/blob/master/transactions/src/main/java...
and such transaction is tried to be rollback which is forbidden on WFTC for imported ones and thus at least ERROR msg is written to the log.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 9 months