[JBoss JIRA] (WFLY-8720) Fix and unignore tests for switching identities in Elytron
by Josef Cacek (JIRA)
Josef Cacek created WFLY-8720:
---------------------------------
Summary: Fix and unignore tests for switching identities in Elytron
Key: WFLY-8720
URL: https://issues.jboss.org/browse/WFLY-8720
Project: WildFly
Issue Type: Bug
Components: Test Suite, Security
Reporter: Josef Cacek
Assignee: Darran Lofthouse
Priority: Critical
Regression tests for WFCORE-2392 has to be unignored and updated (fixed) - {{org/wildfly/test/integration/elytron/ejb/AuthenticationTestCase.java}}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (WFLY-8719) Address DeploymentUnitProcessor leaks in the codebase
by Radoslav Husar (JIRA)
Radoslav Husar created WFLY-8719:
------------------------------------
Summary: Address DeploymentUnitProcessor leaks in the codebase
Key: WFLY-8719
URL: https://issues.jboss.org/browse/WFLY-8719
Project: WildFly
Issue Type: Task
Affects Versions: 11.0.0.Alpha1
Reporter: Radoslav Husar
Assignee: Radoslav Husar
In order to get singleton deployments fully working, we need to address the numerous {{org.jboss.as.server.deployment.DeploymentUnitProcessor#undeploy}} implementation leaks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (WFLY-8706) Singleton deployments does not work in domain mode
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-8706?page=com.atlassian.jira.plugin.... ]
Radoslav Husar closed WFLY-8706.
--------------------------------
Resolution: Rejected
> Singleton deployments does not work in domain mode
> --------------------------------------------------
>
> Key: WFLY-8706
> URL: https://issues.jboss.org/browse/WFLY-8706
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Environment: Centos
> Wildfly 10.1.0.Final (two instances and one domain controller)
> Java 8
> Reporter: Ariel Carrera
> Assignee: Paul Ferraro
>
> In a domain mode, when a deployment is a "singleton deployment" (with a singleton- deployment.xml descriptor), it is working fine if the server nodes are started sequently but fails if it is started from domain console.
> When a deployments needs to be updated, a race condition happens and two instances of the deployment are started.
> From logs:
> node1:
> 12:39:48,434 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 133) WFLYCLINF0002: Started default cache from server container
> 12:39:48,436 INFO [org.wildfly.clustering.server] (notification-thread--p84-t1) WFLYCLSV0003: node1:one *elected as the singleton provider of the jboss.deployment.unit."my-deployment.jar"*.FIRST_MODULE_USE service
> 12:39:48,440 INFO [org.wildfly.clustering.server] (notification-thread--p84-t1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."my-deployment.jar".FIRST_MODULE_USE service
> node2:
> 12:39:48,370 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 122) WFLYCLINF0002: Started default cache from server container
> 12:39:48,372 INFO [org.wildfly.clustering.server] (notification-thread--p193-t1) WFLYCLSV0003: node2:two *elected as the singleton provider of the jboss.deployment.unit."my-deployment.jar"*.FIRST_MODULE_USE service
> 12:39:48,372 INFO [org.wildfly.clustering.server] (notification-thread--p193-t1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."my-deployment.jar".FIRST_MODULE_USE service
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (WFLY-8706) Singleton deployments does not work in domain mode
by Ariel Carrera (JIRA)
[ https://issues.jboss.org/browse/WFLY-8706?page=com.atlassian.jira.plugin.... ]
Ariel Carrera commented on WFLY-8706:
-------------------------------------
I'm sorry, I forgot, you're right.
Closed, it was a problem with jgroups configuration and there is not a bug.
> Singleton deployments does not work in domain mode
> --------------------------------------------------
>
> Key: WFLY-8706
> URL: https://issues.jboss.org/browse/WFLY-8706
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Environment: Centos
> Wildfly 10.1.0.Final (two instances and one domain controller)
> Java 8
> Reporter: Ariel Carrera
> Assignee: Paul Ferraro
>
> In a domain mode, when a deployment is a "singleton deployment" (with a singleton- deployment.xml descriptor), it is working fine if the server nodes are started sequently but fails if it is started from domain console.
> When a deployments needs to be updated, a race condition happens and two instances of the deployment are started.
> From logs:
> node1:
> 12:39:48,434 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 133) WFLYCLINF0002: Started default cache from server container
> 12:39:48,436 INFO [org.wildfly.clustering.server] (notification-thread--p84-t1) WFLYCLSV0003: node1:one *elected as the singleton provider of the jboss.deployment.unit."my-deployment.jar"*.FIRST_MODULE_USE service
> 12:39:48,440 INFO [org.wildfly.clustering.server] (notification-thread--p84-t1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."my-deployment.jar".FIRST_MODULE_USE service
> node2:
> 12:39:48,370 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 122) WFLYCLINF0002: Started default cache from server container
> 12:39:48,372 INFO [org.wildfly.clustering.server] (notification-thread--p193-t1) WFLYCLSV0003: node2:two *elected as the singleton provider of the jboss.deployment.unit."my-deployment.jar"*.FIRST_MODULE_USE service
> 12:39:48,372 INFO [org.wildfly.clustering.server] (notification-thread--p193-t1) WFLYCLSV0001: This node will now operate as the singleton provider of the jboss.deployment.unit."my-deployment.jar".FIRST_MODULE_USE service
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (WFLY-8718) JDBC driver's xa-datasource-class vs. driver-xa-datasource-class-name in the datasources subsystem
by Ladislav Thon (JIRA)
Ladislav Thon created WFLY-8718:
-----------------------------------
Summary: JDBC driver's xa-datasource-class vs. driver-xa-datasource-class-name in the datasources subsystem
Key: WFLY-8718
URL: https://issues.jboss.org/browse/WFLY-8718
Project: WildFly
Issue Type: Bug
Components: JCA
Affects Versions: 10.1.0.Final
Reporter: Ladislav Thon
Assignee: Stefano Maestri
The {{jdbc-driver=*}} management resources in the {{datasources}} subsystem has two attributes, {{xa-datasource-class}} and {{driver-xa-datasource-class-name}}, whose difference isn't clear. Per wildfly-dev discussion \[1\], the {{xa-datasource-class}} has actually no meaning. IMHO, at the very least, it should be marked as deprecated with an explanation of something like "ignored" or so. Ultimately, removal is IMHO a good idea.
I'd also like to note that this actually caused a bug in WildFly Swarm: SWARM-1215
\[1\] http://lists.jboss.org/pipermail/wildfly-dev/2017-May/005913.html
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (WFCORE-2620) Add ability to read computed runtime values of IO subsystem buffer-pool attributes
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2620?page=com.atlassian.jira.plugi... ]
Romain Pelisse edited comment on WFCORE-2620 at 5/8/17 6:29 AM:
----------------------------------------------------------------
[~ctomc] following your comment (and Brian's) on my [PR|https://github.com/wildfly/wildfly-core/pull/2330] for [WFCORE-2620|https://issues.jboss.org/browse/WFCORE-2620], I've looked at how you achieved a proper runtime computed value of the workers. AFAIU, you simply used the [MBean|https://github.com/wildfly/wildfly-core/blob/master/io/subsystem/sr...], provided by Xnio(1) to get the proper value. However, afaiu, there is no value related to buffer in this MBean.
There is an other MBean, java.nio, providing info in the BufferPool(2), however the attributes available there (TotalCapacity and Count) does not provides us with the metrics we need here (buffer-size and buffers-per-slice).
AFAIU, the metrics associated to those are computer in the [BufferPoolResourceDefinition class|https://github.com/wildfly/wildfly-core/blob/master/io/subsystem/sr...], and maybe override using the subsystem configuration in [the standalone.xm|https://github.com/wildfly/wildfly-core/blob/master/io/subs...].
My naive approach here - that I want to double check with you, is : Should I create a MBean for the buffer attribute - to mimic the approach of the worker ? If so I assume we'll move the [buffers "default computation"|https://github.com/wildfly/wildfly-core/blob/master/io/subsystem/src/main/java/org/wildfly/extension/io/BufferPoolResourceDefinition.java#L62] into the MBean (right?). Or am I misunderstanding or missing something here ?
Let me know what you think about this (and if my analysis is correct)
MX object names:
* (1) ObjectName: org.xnio:tyep=Xnio.provider="nio,work"="default"
* (2) ObjectName: java.nio:type=BufferPool,name=direct]
was (Author: rpelisse):
[~ctomc] following your comment (and Brian's) on my [PR|https://github.com/wildfly/wildfly-core/pull/2330] for [WFCORE-2620|https://issues.jboss.org/browse/WFCORE-2620], I've looked at you achieved a proper runtime computed value of the workers. AFAIU, you simply used the [MBean|https://github.com/wildfly/wildfly-core/blob/master/io/subsystem/sr...], provided by Xnio(1) to get the proper value. However, there is no value related to buffer in this MBean.
There is an other MBean, java.nio, providing info in the BufferPool(2), however the attributes available there (TotalCapacity and Count) does not provides us with the metrics we need here (buffer-size and buffers-per-slice). AFAIU, the metrics associated to those are computer in the [BufferPoolResourceDefinition class|https://github.com/wildfly/wildfly-core/blob/master/io/subsystem/sr...], and maybe override using the subsystem configuration in [the standalone.xm|https://github.com/wildfly/wildfly-core/blob/master/io/subs...].
My naive approach here - that I want to double check with you, is : Should I create a MBean for the buffer attribute - to mimic the approach of the worker ? If so I assume we'll move the [buffers "default computation"|https://github.com/wildfly/wildfly-core/blob/master/io/subsystem/src/main/java/org/wildfly/extension/io/BufferPoolResourceDefinition.java#L62] into the MBean (right?). Or am I misunderstanding or missing something here ?
Let me know what you think about this (and if my analysis is correct)
MX object names:
* (1) ObjectName: org.xnio:tyep=Xnio.provider="nio,work"="default"
* (2) ObjectName: java.nio:type=BufferPool,name=direct]
> Add ability to read computed runtime values of IO subsystem buffer-pool attributes
> ----------------------------------------------------------------------------------
>
> Key: WFCORE-2620
> URL: https://issues.jboss.org/browse/WFCORE-2620
> Project: WildFly Core
> Issue Type: Enhancement
> Affects Versions: 3.0.0.Beta13
> Reporter: Romain Pelisse
> Assignee: Romain Pelisse
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> In IO subsystem there are some attributes which are calculated based on available system resources if not explicitly specified. These attributes are:
> * worker
> ** io-threads
> ** task-max-threads
> * buffer-pool
> ** buffer-size
> ** buffers-per-slice
> ** direct-buffers
> Currently these computed values are not visible for user in the subsystem configuration even with include-runtime=true.
> To show these runtime values would definitely improve UX.
> Worker attributes are covered by EAP7-616 .
> This issue is about buffer-pool attributes.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months
[JBoss JIRA] (ELY-1142) Add an NSS database to the testsuite and selection of smoke tests to use it.
by Darran Lofthouse (JIRA)
Darran Lofthouse created ELY-1142:
-------------------------------------
Summary: Add an NSS database to the testsuite and selection of smoke tests to use it.
Key: ELY-1142
URL: https://issues.jboss.org/browse/ELY-1142
Project: WildFly Elytron
Issue Type: Task
Components: SSL, Testsuite
Reporter: Darran Lofthouse
Fix For: 2.0.0.Alpha1
Due to NSS not being available in all environments testing will likely need to be conditional on the OS, this should however at the very least assist in flagging regressions in the PR process.
Originally creating thinking about SSL but we could possibly cover credential store as well.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 8 months